LiVeR: Lightweight Vehicle Detection and Classification in Real-Time

Many of the preceding constraints highly conflict with each other. For example, a solution to be able to accurately detect and classify the vehicles may need to employ more analysis of the recorded data and may depend on high-end cloud servers so that outdoor implementation remains simpler. Similarly, accurate detection and maintaining anonymity may also demand the collection of more sophisticated data per vehicle, which would require complex settings as well as an adequate supply of power. Balancing all preceding requirements together is possible only when the basic logic behind a solution is very simple and it is implemented in a very simple but efficient way by minimizing the computing requirements so that the tasks can be executed fully by the edge devices, and also can live on battery power for a long time.

Most of the existing solutions fail to meet a significant fraction of the features described previously. A comprehensive summary is provided in the following. We refer to the three types of solutions—camera-based, sensor-based, and RF-based, as briefed in Section 1.

Cost-effectiveness. There have been immense advancements in the design and development of lightweight object-detection strategies, such as YOLOv7 [51] and YOLACT++ [4], which are being used for efficient application of computer vision in vehicle detection and classification. These works [4, 5, 13, 24, 36, 51] use costly image capturing equipment for recording the vehicles. Some recent works [6, 7, 27, 54] also exploit sophisticated stereo cameras for capturing 3D vision to achieve superior performance. Moreover, at minimum, they need a GPU system for analysis of the image-data on-the-fly or a costly high-end cloud service. Sensor-assisted solutions also mostly need to depend on the installation of ccostly infrastructure [26] for the appropriate functioning of the sensors. In principle, RF-based solutions ideally do not need any such costly equipment [2, 18, 23]. However, the way RF has been employed so far involves a high cost per unit for the necessary setup to achieve controlled measurement of the PHY parameters (e.g., RSS) [44, 49, 52, 53]. The use of ML/AI-based on-the-fly analysis of the collected data, either by cloud or high-end computing facility, also adds to the overall cost. This results in high-cost algorithms for their analysis. In contrast, in our current work, we use low-power RF communication between off-the-shelf low-cost IoT-devices and in-device recording, as well as lightweight analysis of the data, which by default minimizes the cost per unit.

Flexibility/Infrastructure. Unlike a friendly indoor environment, outdoor space is considered to be quite hostile and dynamic. Thus, flexibility and easy re-installation support for a solution are very important. Camera-based solutions need special installation of the costly cameras and their proper maintenance too. Sensor-assisted solutions also need specialized installation of the sensors. For instance, intrusive sensors such as the acoustic sensor [40], light sensor [46], magnetometer [47, 48], loop detector [20], piezoelectric sensor [35], and vibration [37, 45] first need to be appropriately installed on the pavement surfaces. High installation costs, traffic disruption during installation, maintenance, and so forth are some of the disadvantages of this approach. In contrast, in our current work, we use off-the-shelf, battery-operated, small-size IoT devices to serve the purpose. The IoT device can be installed at any suitable location beside the road, such as roadside trees and lampposts. It does not need any specialized installation support and hence is highly portable.

Energy Requirement/Power Supply. In general, all the existing works assume the availability of an adequate and uninterrupted source of power (e.g., wall power) for carrying out the job [5, 13, 24]. In contrast, our design exploits low-power IoT-systems and hence largely relaxes this requirement. In particular, our compact and efficient communication protocol enables the solution to sustain itself for a substantial amount of time solely based on battery power.

Moreover, the system can be appropriately tuned to run over battery power for a much longer duration.

Cloud Assistance/Computation Cost. The camera-based solutions [4, 5, 13, 24, 33, 36, 51] need to run complex algorithms in the back-end for processing the image and video data for which constant cloud connectivity is inevitable. Frequent communication with the cloud with large amounts of data creates a serious bottleneck in the mass application of such solutions over a large area. To address this common issue, the recent design trend is to minimize the interaction between the cloud and the edge [55]. The IoT-assisted approach proposed in this work uses very simple strategies and ensures that the low-power small-sized IoT devices can carry out all the required analysis tasks without explicit support from the cloud.

Wide-Area Synchronized Measurement. Existing works deal with the detection and classification of the vehicles at a single place [2, 52]. However, in the context of smart city/intelligent transportation, the solution needs to be replicated at multiple locations, and the measurements collected from these locations need to be time-correlated for a system-wide behavioral study. None of the existing camera-based, sensor-based, or even RF-based solutions talks about this issue. Our proposed IoT-based framework, apart from being cost-effective and easy to use, takes care of these vital issues, which are largely missing in the existing works. Intrinsically, our proposed framework does not depend on the conventional 3G/4G/LTE network. Rather, it is designed as an ST-based stand-alone IoT system that connects all its base units using low-power communication technology and supports seamless time correlation among them.

System-Wide Analysis. The primary goal of wide-area detection and classification is to enable on-the-fly behavioral study, anomaly detection, and quick decision-making in traffic management and control. Most of the existing solutions depend on the computation and analysis of the raw data with the help of a cloud server. However, conveying data to the cloud at every epoch from every Measurement Unit (MU) installed over a large area naturally consumes a huge bandwidth, causing network congestion as well as performance degradation [2, 49, 52]. The proposed IoT-based solution in our current work, in contrast, by the virtue of the existing rich IoT-protocol base [15, 21], can carry out in-network data processing to support on-the-fly end-to-end collaborative decision-making in real-time without any active help from the cloud.

Privacy. With the increasing use of technology, the privacy of users has become one of the prime concerns. Camera-based solutions are prone to breaches of privacy and hence are not suitable for all applications [19]. BLE/WiFi-based solutions can also work in a privacy-preserving fashion but need a prior coupling between vehicles and the detection/classification system—for example, the transmission of any special signal from the vehicles for their detection and classification [30]. Similarly, sensor-based solutions are also mostly not prone to any such breach of privacy [28, 45]. However, the requirement for special infrastructure and dependence on the cloud for necessary analysis make their ubiquitous and widespread use difficult. In our current work, we fundamentally use a low-power RF transceiver as a special type of sensor that directly categorizes a vehicle under a class without the requirement of any further detailing of the actual vehicle and hence maintains privacy.

Discussion. RF-based solutions tend to meet many of the expected features which are quite hard by the other two possible approaches. However, the existing works exploit RF in a mostly brute-force way. The role of an efficient protocol for supervising the whole process is extremely important to balance all the goals together, which is missing in the existing works. The approach taken in the work of Sliwa et al. [44] is the closest to that of ours. Swila et al. [44] use an AT-based protocol similar to token ring [14] where six active devices exchange RF packets across the road at a very high rate. The protocol measures the RSSI values at the receiving devices and checks for any attenuation due to the passage of the vehicles. Support Vector Machine (SVM) is used for on-the-fly detection and classification. However, the use of uncontrolled communication among the active devices makes this strategy highly energy-hungry. Moreover, the solution acts blindly—that is, it does not adapt based on the traffic and hence constantly drains the energy from the low-power devices at a very high rate. In addition, the work is quite ignorant about the issue of efficient wide-area coverage. In contrast, our current work, LiVeR, demonstrates an adaptive mechanism that achieves the goal of spending approximately one-third of the RF packets compared to the work of Swila et al. [44] without compromising accuracy. Section 8 provides a detailed comparison.

Table 2 summarizes the existing works w.r.t. the expected features (in the columns). The advantages of a solution are highlighted with a gray background.

Most of the traditional protocols in WSN/IoT are based on AT. The nodes/devices in these protocols behave in a highly independent fashion. However, energy preservation is one of the primary issues in any such protocol. The RF transceiver happens to be the most energy-hungry unit in a device. Therefore, for sustained low-power operation, any protocol tries to duty-cycle (periodic ON and OFF) their RF transceiver (radio). In addition, to minimize the use of the RF units, the nodes in an AT-based protocol try to understand each others’ duty cycles, and subsequently make necessary mutual adjustments so that one can easily communicate with the other nodes as necessary by the application. For instance, in the well-known data-collection protocol CTP [16], a source node syncs its duty cycle with its immediate parent node (i.e., the node that is assigned the responsibility to forward the data from a certain set of source nodes toward the sink node). However, due to such special pairwise tying up, during any temporal link disturbances caused by vehicular obstacles, when the quality (e.g., PRR) of a certain set of links degrades, it affects the performance of the overall system. In other words, although the communication hindrance happens in a specific direction (or location) affecting only a specific set of links at a time, the AT-based protocols fail to take advantage of the omnidirectional connectivity of the underlying wireless communication medium to prevent performance degradation at the system level.

Synchronous Transmission. In contrast, ST-based strategies are organized differently. Broadcast-based nature of any wireless communication makes it inherently vulnerable to cascaded collisions, which is a common problem under AT-based protocols. However, ST-based strategies employ an in-network time-synchronization strategy that enables them to exploit special PHY phenomena, such as Constructive Interference (CI) or Capture Effect (CE) [22] to avoid collisions among multiple RF packets [56]. In particular, when a number of RF packets attempt to approach a single receiver at the same time, an ST-based strategy cleverly exploits the special capability of the underlying radio to accept the strongest packet and discard the others on-the-fly. Although the basic concept of ST was invented earlier, the protocol Glossy [15] for the first time showed how ST can be exploited in a systematic way for the purpose of system-wide flooding. Appropriate use of synchronized transmissions makes the one-to-many dissemination protocols such as Glossy, RoF [25], and BlueFlood [32] extremely robust in nature [15, 32]. In particular, logically it is quite hard for even a set of temporal/localized and uncorrelated link disturbances caused by the vehicles to affect the performance of an ST-based flooding protocol. In this work, we use the protocol Glossy as the foundation. It is briefly described next.

Glossy. The pioneering protocol Glossy [15] shows how to efficiently achieve quick and reliable one-to-all dissemination (i.e., flooding under ST). Glossy starts with a single node (initiator) broadcasting its data packet. The packet is received at the same time by all the first-hop neighbors of the initiator. Through appropriate time adjustment, Glossy arranges the re-transmissions of the received packets from each of these nodes in such a way that it results in CI/CE in the second-hop neighbors of the initiator which enables them to successfully decode the received packets. The process cascades this way until it covers the full network. Systematic exploitation of CI/CE thus enables Glossy (in general, an ST-based flooding protocol) to successfully exploit the strength of the redundant but synchronized transmissions of the packets from multiple different source nodes. This also makes ST inherently much more resilient to the degradation of the links caused by vehicular obstructions or any such temporal and localized communication hindrance compared to the AT-based strategies.

Glossy is executed in sensing mode and wrapping mode to achieve our goal in this work. Glossy is meant for a network-wide dissemination of data. However, in sensing mode, we use it between a pair of IoT devices (referred to as a Measurement Point (MP), described later) installed by the two sides of a road. The whole concept is hence centered around the controlled measurement of the characteristics of the degradation of the performance of Glossy due to dynamic obstructions caused by the vehicles when they pass through an MP (see Figure 8(i)). A similar approach was adopted in prior work [41] for lightweight measurement of traffic volume where the target is only the detection of the vehicles. However, the current work aims to classify the vehicles too. Thus, the sensitivity of Glossy w.r.t. to different categories of vehicles is important. To allo Glossy to become affected by vehicular disturbances, we reduce the Transmission Power (TXP) level appropriately in such a way that it works normally when there is no traffic but degrades gracefully while fruitfully capturing the category of a vehicle passing through an MP.

PHY parameters such as RSSI and LQI have been used in several prior works [18, 23, 38, 43] to characterize the RF communication during the passage of the vehicles. Most of these works show controlled measurements of these PHY parameters analyzed using costly devices/settings. To carry out the same job in a lightweight and easier manner, as well as analyze the measurement data directly in the resource-constrained off-the-shelf IoT devices, in this work, we capture the DLL parameters instead of the raw PHY parameters. Although disturbances in the DLL parameters are fundamentally an artifact of the same in the PHY parameters, the higher layer in the network stack provides natural filtering of various complex effects which in turn makes the process of analysis simpler, lightweight, and quicker. The DLL performance metrics which we use as a set of features in this study are detailed next.

NTX. To ensure complete network coverage, every node in Glossy repeats the transmission of a packet a pre-decided number of times which is known as the Number of Transmission (NTX), where each transmission is followed by a reception. NTX is a quite common parameter used in most of the existing ST-based protocols. We use NTX as one of the prime design parameters:

While we mainly focus on the DLL metrics, the two primary PHY metrics RSSI and LQI are also captured for preliminary study. Under our proposed framework, we successfully capture the discrete values of RSSI and LQI from each packet communicated to the receiver. We calculate the average and standard deviation of these RSSI and LQI values over all the packets during the Detection and Classification Phase (DCPhase). We refer to these as RSSI-avg, RSSI-stddev, LQI-avg, and LQI-stddev.

The major issue in SCPhase is a system-wide time synchronization which is achieved by an instance of Glossy. The algorithm of Glossy is highly scalable. The time it takes depends on the diameter of the network instead of the exact number of nodes. Apart from that, owing to the modular design of the proposed solution, SCPhase can be also implemented based on recently invented advanced solutions [29]. However, considering that the proposed solution is an ST-based one, periodic execution of the SCPhase is an important issue. The following two parameters come into the picture in this context.

Glossy Period. The three-phase process runs in a periodic fashion with a defined period and defined duration for each of the three phases. Figure 5(i)(b) pictorially depicts this arrangement in the form of a time diagram. The Glossy Period (GP) is the period set for the process (i.e., one instance of both SCPhase and DCPhase, along with one instance of IPhase when needed). GP is set only for the SCPhase and is decided very carefully, as explained in Section 6.3. The value of GP partially determines both the energy consumption in each device as well as the value of Glossy Duration (GD), as discussed next.

Glossy Duration. GD is known as the part of the period where the actual data communication takes place. By virtue of ST, the execution of Glossy is completed very quickly. For instance, to cover a 100-node 5-hop ZigBee network, Glossy takes about 10 to 20 ms for a complete network-wide time synchronization as well as one-to-all dissemination of small data. Thus, in SCPhase, GD is decided based on the size of the full network (we refer to this as GD \(_\text{s}\) ). In DCPhase, the duration of the protocol is set based on the expected/planned nature of the interaction of the protocol with the vehicles passing through an MP. We experiment with three possible variations, as described in the following.

The primary intention is to let the vehicles pass through the installed MPs and collide with the RF packets during DCPhase in such a way that can bring enough variations in the metrics (discussed in the preceding section) which can be exploited through a lightweight ML strategy for vehicle detection and classification. We focus on the following four metrics: TC, LT, RO, and RXCT. For example, the metric TC reflects how many times the initiator had to retry to make a successful communication with the receiver. Therefore, the expectation is to have the values of TC be quite proportional to the size of the vehicles for easy classification. However, to meet this intuition, there are two primary bottlenecks, which are discussed next.

Lack of Persistent Communication. Let us assume that DCPhase runs a normal instance of Glossy in low TXP mode with two nodes (MP, i.e., an initiator and a receiver). Since there is no control over the dynamics that govern the collision of a Glossy packet with a vehicle, it is always good to have a sufficient number of such collision instances, even for a single vehicle. To make this happen, the transmissions from the initiator node have to be persistent—that is, the initiator should keep sending a sufficient number of packets in a short interval even in case it detects that the last packet was lost. However, note that the original design of Glossy is meant for efficient one-to-all dissemination of data over a network. To support safe multi-hop operation, such persistent behavior is implemented only for the very first packet transmitted from the initiator. After the transmission of the first packet, when nothing is heard back, from an initiator’s perspective, there can be two possibilities:

To cope with the first possibility, the initiator can safely re-transmit the packet as soon as a certain safe time has passed. However, under the second possibility, the initiator already lost time synchronization because of lack of packet reception and hence should not re-transmit the packet. Unfortunately, when the initiator finds that there is no reply to its initial transmission, it cannot distinguish these two possibilities on its own. Therefore, it needs to wait for a safe period called initiator-time-out after which it can re-transmit the same packet. Moreover, once the first packet successfully goes through, the same mechanism cannot be repeated for the other packets. When we directly use the Plain Glossy (PG) protocol for intra-MU communication in an MP in the DCPhase, these restrictions ultimately reduce the frequency of the transmission from the initiator and hence proportionately reduce the chance of the collision of the RF packets with the vehicles too.

Solution. The dynamics of Glossy in a two-node setting (intra-MP), which we use in the DCPhase of our proposed framework, is different from the dynamics of the protocol in a general multi-hop setting. In particular, in a purely two-node setting, the only reason for no reply for the first packet from the initiator is the loss of the first packet or its reply from the receiver. Hence, each of the NTX transmissions can safely operate in a persistent mode. To systematically realize this and enhance the scope of the collision of the RF packets further (as explained next), we split a Glossy instance into NTX of persistent Glossy instances each having NTX=1. Each instance is set with a very short value of initiator-time-out, and two consecutive instances are separated by a certain small gap (a few milliseconds).

Interaction between DCPhase and Vehicles. The span of time a vehicle gets for interaction with the packets in a DCPhase is a very important issue, and it depends on the size as well as the speed of the vehicles. It has been studied that under low-power communication, the main disturbance happens when a vehicle crosses the Line-of-Sight (LoS) between the sender and the receiver [39, 43]. Let us define the quantity Contact Period (CP) as the span of time a vehicle takes to cross the LoS in an MP. Thus, it is the responsibility of the DCPhase to increase the scope of the interaction of the communication protocol with vehicles irrespective of different possible values of the CP. It is done as follows.

Solution. Splitting a single Glossy instance into multiple instances, as is used for systematically enhancing the frequency of communication between the initiator and the receiver, also provides a way to solve the aforementioned problem. However, along with splitting, the scheduling of shorter instances is also an important issue in this regard. In particular, the individual instances of Glossy should be scheduled in such a way that the vehicles having even the minimum size as well as maximum speed (i.e., the minimum possible CP) should also get at least one scope of interaction with the Glossy packets.

Based on the aforementioned observations and solution approaches, we design the DCPhase in three possible ways, as described next:

Algorithm 1 describes Persistent \(\_\) Glossy—that is, the persistent version of Glossy which is used as a unit of operation for both MPG and DMPG. Algorithm 2 shows the details of MPG where Persistent \(\_\) Glossy is invoked at regular intervals for a certain number of times. PG and DMPG are not shown explicitly through the algorithm since PG is the same as the Glossy protocol, whereas DMPG is quite similar to MPG where the instances of the persistent Glossy are invoked more closely based on the time of the first vehicle detected. Timers are used for setting the initiator timeout and scheduling the instances of the persistent Glossy. Algorithms 3 and 4 demonstrate the interrupt service routines used to handle the timer events. Figure 2 provides an overall flow diagram of the complete process. Figure 3 pictorially demonstrates the communication components of all three strategies (PG, MPG, and DMPG) through a time diagram.

A small computation step is introduced just after the communication steps inside DCPhase where the extracted features are processed through a lightweight ML-assisted detection and classification mechanism (SVM) as shown in Figure 2. It is described in detail in Section 7.

The IPhase section is quite flexible. Various other possible many-to-many or many-to-one data-sharing strategies can be employed in this phase to serve the targeted function. In Section 9, we show one case study by integrating Chaos for all-to-all data-sharing among the MPs. In Section 9.3, we show a possible practical application of the same.

The low-power communication in DCPhase is affected differently by different types of vehicles. For instance, the passage of a truck results in more rise in LT and TC, and more drop in RXCT, than a car. In general, the disturbances in almost all the metrics vary with the size/volume of the vehicle that collides with the inter-MU communications during the DCPhase. Based on the size of the vehicles, we define three classes as follows:

To maintain uniformity in the description, we also consider the presence of no vehicles as a class denoted by Type-N.

We derive a set of constraints that are used as a guideline for scheduling the Glossy instances inside a DCPhase as part of MPG/DMPG. CP (i.e., the time for which DCPhase can interact with the vehicle) is one of the key factors. Let us consider \(t_{\text{CP-min}}\) to be the minimum possible CP. As shown in Figure 4(i), considering two consecutive instances of Glossy with NTX=1 ( \(\text{N}_1\) and \(\text{N}_2\) ), each having duration of \(t_{\text{dc}}\) , the gap between them (i.e., \(t_{\text{dc-gap}}\) ) should be set in a way so that it meets the following constraint:

A similar constraint can be applied for the gap between SCPhase and the first Glossy instance in DCPhase (i.e., \(t_{\text{scdc-gap}}\) ) aswhere \(t_{\text{sc}}\) is the duration of Glossy in SCPhase.

From Equations (1) and (2), we can conclude that

Considering a complete period of SCPhase, all the constraints can be summarized as follows:

Effect of Heading Angle. Considering possible heading directions, let us assume that a vehicle moves over the road with some heading angle \(\theta\) (as shown in Figure 4(ii)). For any positive non-zero value of \(\theta\) , the CP of the vehicle will decrease compared to the case when \(\theta\) =0. However, due to lane restrictions and other traffic rules, \(\theta\) cannot be larger than a certain value. Even a vehicle cannot sustain a heading angle for a long time. Therefore, the corresponding measurements of the metrics captured by DCPhase will not cross their boundaries. Therefore, it will not let the classification system to get confused. In particular, our strategy would support up to a certain heading angle which would be enough for the correct classification of the vehicles.

LiVeR is supposed to carry out on-the-spot detection and classification of the vehicles at the edge devices at every regular interval of GP. Thus, the minimum time taken for a detection/classification will be lower bound by GP. The sole motivation behind the design of LiVeR has been to keep it as computationally simple as possible. There are two places where computation is involved in LiVeR, as summarized next.

Communication Step. Inside the communication part of DCPhase, the four metrics (TC, LT, RXCT, and RO) are computed through simple increment and subtraction operations as the RF packets succeed or fail in crossing the road being monitored. Fundamentally, the number of computations in terms of elementary addition/subtraction/increment/decrement operations carried out during the communication step dynamically varies with the type of vehicle it encounters. In other words, the number of such computation steps increases with the size of the vehicle the communication process interferes with. In the best case, for a typical small-size (Type-S) vehicle, approximately 5 numbers, and in the worst case, for a typical large-size vehicle (Type-L) approximately 30 numbers of additions/subtractions are executed per GP.

Computation Step. Just after the communication step, an SVM is used for recalling purposes (see the flow diagram in Figure 2). Since we use the one-vs-rest strategy for the SVM, the prediction complexity is O(C*d), where C is the number of classes and d is the number of features. The value of both C and d in our case is 4.

Furthermore, IPhase can be used for fine-grained classification of the vehicles by considering the outcomes of multiple consecutive MPs together. In such cases, the minimum number of MPs to be considered together will define the time complexity as their outcomes will be derived at different GPs. However, such analysis is beyond the scope of this work.

Energy consumption in a low-power communication-based protocol is directly proportional to the number of RF packets it involves in a unit of operation. In contrast, the design of LiVeR is quite self-adaptive. When there is no traffic, LiVeR runs with a minimum number of RF packets. As the traffic intensity increases, it employs a higher number of packets. All calculations in LiVeR happen in the unit of GP. Let us assume that, based on traffic intensity, a GP encounters a vehicle with probability x. Let \(V_{S}\) , \(V_{M}\) , \(V_{L}\) be the fractions representing the number of Type-S, Type-M, and Type-L vehicles w.r.t. the total number of vehicles N encountered in a given span of time \(T_d\) . When there is no traffic, every GP is filled up with the NI number of instances of Glossy where each instance employs just one packet transmission between the initiator and the receiver. Let us assume that when a Type-S, Type-M, or Type-L vehicle is encountered, the NTX involved in each such instance is \(\alpha\) , \(\beta\) , and \(\gamma\) , respectively. Thus, the total number of packets transmitted per GP can be calculated as follows:

Section 8.4 provides a comparative study of the LiVeR and one state-of-the-art strategy w.r.t. energy consumption.

Hence, the total number of packets employed for detection and classification in LiVeR within the span of \(T_{d}\) , can be calculated as follows:

An MP is composed of two MUs which are installed at the two opposite sides of a road, as shown in Figure 5(ii)(b). The outer look of an MU is shown in Figure 5(ii)(a). We construct it in two ways. Ideally, both MUs (i.e., the transmitter and the receiver) are constructed by a single off-the-shelf IoT device (we use TelosB) along with a couple of batteries packed inside a waterproof box for uninterrupted outdoor operation (see Figure 5(ii)(e)). However, to facilitate easy accessibility of the data from several MPs for further analysis, we use a special arrangement (see Figure 5(ii)(c)) for the transmitter-side MU so that the recorded data directly gets logged in a central machine. Figure 5(ii)(d) shows this internal construction. In particular, we connect an IoT device to an RPi which internally records the data and later communicates the same through a WiFi network to a central server in our lab. An MU is connected to three LEDs which are appropriately programmed to roughly depict the internal operations. The proposed framework is implemented in the Contiki 3.0 operating system. For most of the stand-alone measurement studies, we use the centralized data-logging facility. We demonstrate a sample application of the proposed vehicle detection and classification mechanism inside an academic institute in Section 9.3 where we use the bare-bone simplest possible implementation of the MUs as shown in Figure 5(ii)(d).

Extensive measurement experiments are conducted at several places in Bhubaneswar city. The experimental setup is shown in Figure 5(i)(c). For each experiment, a video of the whole measurement process is recorded as a Ground Truth (GT). Figure 6 plots all four raw DLL metrics and two PHY metrics over a 7-minute period of measurement data. For an overall understanding, we also measure the R of the Glossy instance in the DCPhase as shown in Figure 6(d).

We annotate the collected data based on GT. The readings of all the metrics are found to be quite correlating with the passage of the vehicles through the MP. Several such cases are shown using dashed rectangles in Figure 6. Whereas LT and TC both are found to be exhibiting a variation with the occurrences of different types of vehicles, RO exhibits mostly a binary pattern: a high value indicating the presence of the vehicles and a low value indicating the absence of vehicles. RXCT behaves in exactly the opposite way. When there is no vehicle, all the NTX transmissions and receptions complete quickly, which makes the RXCT quite high. However, the presence of the vehicles makes RXCT low.

It can be observed that whereas RSSI-avg hardly shows any correlation with the disturbances, RSSI-stddev demonstrates a good match and also mostly correlates with TC. The same nature is visible in LQI-stddev too. However, from a visual inspection of the difference between the patterns produced by PHY metrics and DLL metrics w.r.t. GT, it can be clearly understood that PHY metrics change in a more continuous form, whereas changes in the DLL metrics are more discrete, which happens to be instrumental in simplifying the process of classification in resource-constrained devices.

Appropriate tuning of different vital parameters of the underlying communication protocol is a significant issue in the measurement study as well as collection of the necessary data for real-time analysis. In the following, we study these issues in detail.

Glossy Period. Figure 7(a) shows the approximate values of the CP for different types of vehicles at different speeds. On the one hand, a larger GP may increase the cases of false negatives, as the vehicles may pass through the gaps between instances of DCPhase which results in a fall in detection accuracy as shown in Figure 7(b). On the other hand, a smaller GP is also not a good solution, as it would increase the energy consumption in low-power devices due to the frequent execution of RF-based communication tasks. It can be seen that the minimum CP considering all the realistic cases is about 256 ms (considering 802.15.4-based intra-MP communication). This implies that the period of SCPhase (i.e., GP) must be at least 256 ms.

Transmission Power. Setting an appropriate TXP level plays a very important role in developing a noise-free training dataset as well as accurate testing. The detection efficiency of the proposed framework strongly depends on the sensitivity of the DCPhase w.r.t. the passage of the vehicles. Intuitively, a low-strength signal becomes more affected due to vehicular obstructions, whereas a higher-strength signal acquires the ability to completely tolerate the vehicular disturbance. Thus, although low signal strength goes in our favor, setting too low TXP in the DCPhase may have various undesired effects. In particular, the packet may either be completely abolished or it may result in too low residue signal strength to be successfully detected by the receiver radio. Environmental noise or other CTI-related RF interferences may also be an issue with too low TXP. In other words, on the one hand, setting a low TXP may result in a rise in false positives due to an increase in random packet drops. On the other hand, setting a higher value of TXP may either result in a false negative or even cause a wrong prediction where a vehicle of a specific class is categorized as belonging to some other class of larger size. To get a clear understanding of the dynamics, we repeat the measurement study under different TXPs in both off-road (without traffic) and on-road (over a moderately busy road with approximately 300 vehicles/hour). In general, the target is to make DCPhase sensitive and SCPhase resilient to the passage of vehicles. In the measurement experiments reported in the previous section, we set the TXP in DCPhase and SCPhase as 15 (i.e., low) and 31 (i.e., high), respectively. These values are reported w.r.t. the TXP levels of CC2420 (802.15.4 compatible radio used in TelosB). It allows 32 different TXP levels starting from 0 to 31, where 31 represents the highest power level of 0 dBm.

Packet Size. Packet size is also an important issue in the current context. Packets with larger sizes are more sensitive to the passage of vehicles, whereas packets with smaller sizes may have quite low sensitivity. Prior work [43] shows a detailed study on this topic. To maintain a balance, we keep a moderate packet size of 30 bytes throughout all our experiments.

The distance between the transmitter and the receivers (i.e., inter-MU distance) in all these experiments is set at 8 m.

Off-Road vs On-Road Study. All the metrics, reported in Section 7.1, are measured over iterations with TXP starting from 3 up to 31. RSSI values at the receiver end are shown in Figure 8(i)(c). To obtain a reference, we also execute the plain Glossy protocol at different TXP in the same setting in both off-road and on-road settings. Figure 8(i)(a) shows the plot of R obtained from plane Glossy. In off-road settings, a drastic drop is visible in R below TXP 11. However, under on-road settings, due to the presence of the vehicles, a minimum TXP of 25 is necessary to achieve an R of Glossy above 99%. We carry out several experiments with the proposed detection strategy in the same setup under different TXP values between 11 and 25. Figure 8(ii) shows the plots of average LT, TC, RO, and RXCT and their standard deviation over all of these experiments in both on-road and off-road. As is visible from the results, at TXP above 11, all the metrics are quite stable in off-road settings and do not show any variation. However, all of them are found to be widely varying under on-road settings (as visible through the standard deviation/error bars in Figure 8(ii)). In general, the lower the TXP, the wider the variation. It can be inferred from the study that any TXP above 11, but below 25, is quite good for the vehicle-detection purpose.

We carry out measurement experiments with PG, MPG, and DMPG at multiple different places in the city of Bhubaneswar. Considering the value of \(t_{\text{CP-min}}\) as 265 ms, we set the values of GP, NI, and \(d_x\) (for MPG) as 256 ms, 5, and 16 ms, respectively. All four metrics (TC, RO, RXCT, and LT) are used together as a feature set to characterize and label the events in each GP. The datasets and their characteristics are summarized in Table 3(a). Headway distribution is a very important characteristic of traffic [8]. It reflects the average spatial gap between the vehicles. We roughly calculate the headway distribution from GT for each dataset as shown in Table 3(a). The datasets can be categorized into three types. Datasets D1 and D2 are collected in the morning hours when the intensity of traffic (single lane) is quite low (approximately 120 vehicles/hour) and headway is quite high. Datasets D3, D4, D5, D6, and D7 are collected under moderate intensity and multi-lane traffic (approximately 400 vehicles/hour) with moderate headway. Dataset D8 is collected under multi-lane and high-intensity traffic (approximately 1,000 vehicles/hour) with the lowest headway. Datasets D4, D5, and D9 are collected specifically to understand the performance of LiVeR under adverse weather conditions.

With the help of the GT of the collected dataset, we try to understand the variations in the pattern of interactions of the vehicles of different classes on different strategies used in the DCPhase (i.e., PG, MPG, and DMPG). We obtain the distribution of the values of each of the four metrics (i.e., TC, LT, RO, and RXCT) over all the classes as shown in Figures 9 through 11 for PG, MPG, and DMPG, respectively. For a quick comparison, we group the obtained values for each of the different metrics and calculate the number of iterations of DCPhase in the corresponding experiment that satisfies each of these groups for each of the four different classes of vehicles. From Figure 9, it can be seen that although the distribution of the values approximately correlates with the type of vehicles, there are many cases where the metrics show similar behavior for different classes of vehicles. For instance, the metric TC reflects how many times the initiator had tried to make a successful communication with the receiver. Therefore, ideally, the expectation is to have the values of TC be quite proportional to the size of the vehicles. However, in reality, the distribution shown in Figure 9 does not reflect it. Rather, the values are found to be more or less spread over the possible range of TC. A similar effect is visible in most of the metrics. It indicates that the automation of the classification process by the devices on-the-fly is not straightforward using PG.

In contrast, the distributions of the metrics for DMPG and MPG exhibit more deterministic behavior with fewer deviations. Figure 10(a) through (d) show the distribution of TC in MPG for all the four different classes. Figure 11(a) through (d) depict the same for DMPG. The differences between the same distributions obtained from PG, as shown in Figure 9(a) through (d), are very clearly visible. In MPG, most of the vehicles get at least one chance to collide with the inter-MU communication, and hence the ambiguities in the values of the metrics among the classes drastically drop. In the case of DMPG, the ambiguities are even lesser as the vehicles get more chances for collisions, and hence more instances are obtained to produce a better average. In particular, it can be seen that the metric TC is quite efficient in determining the type of vehicle in DMPG. In MPG, the behavior is also almost predictable, whereas in PG, it appears quite difficult due to the higher chances for the vehicles to pass through without colliding. A similar effect can be observed in the distribution of all three other metrics.

Minute study and observations on the distributions of the metrics indicate that a lightweight ML tool like SVM would be quite good enough for carrying out the job of on-the-spot detection and classification of the vehicles on the edge itself. Next, we provide further details on the training of the SVM.

The detectability and observability of the proposed networked sensor model largely depend on the appropriate training of the employed ML tool. The SVM used for detection and classification is trained using the dataset demonstrated in Table 3(a). For training, we use a machine with an Intel i7 processor and 8 GB of RAM. To keep the size of the trained model low, as well as to have computationally efficient testing, we use a one-vs-rest strategy and a liner kernel for training. The four metrics LT, TC, RXCT, and RO are used as four features. The three categories of vehicles, along with the absence of any vehicle (i.e., Type-N), are used as the target class for training. This results in a quite small size of the trained model (approximately 150 bytes) which we port to TelosB for carrying out the job at the edge itself.

For each of the four metrics (LT, TC, RO, and RXCT), 80% of the collected data are used for training the SVM. The rest of the data are used for recalling/testing. Figure 8(i)(b) shows the accuracy (w.r.t. GT) results while recalling at different TXP based on the metric LT. The accuracy is found to be quite high in the range of TXP 11 to 21. Tallying with the collected GT, we find that for TXP higher than 21, due to sufficient signal strength, medium- and lower-size vehicles fail to make enough impact.

The appropriate TXP for DCPhase also depends on the inter-MU distance. To understand the dynamics, we repeat all the experiments for an inter-MU distance of 12 m. RSSI at the receiver for an inter-MU distance of 12 m is shown in 8(i)(f). Figure 8(i)(d) shows that at least a TXP of 15 is needed for the plain Glossy to function reliably under this setting. Accuracy obtained from SVM (based on LT) (as shown in Figure 8(i)(d)) is found to be quite high in the range of TXP 15 to 28. Due to the higher distance between MUs, at TXP beyond 28, medium and smaller vehicles fail to make enough impact.

From all of these results, it can be observed that although the exact values differ for different inter-MU distances, the overall pattern remains the same. Moreover, for all other metrics (RO, RXCT, and TC), we also find almost similar behavior. In this work, we primarily focus on single-lane traffic. Hence, for all the rest of the experiments, we set the inter-MU distance at 8 m. Accordingly, for SCPhase, we set TXP above 25 to keep the system running despite vehicular obstructions, whereas for DCPhase, we set TXP between 11 and 25 to induce controlled sensitivity.

The pattern of the distribution of the metrics obtained from different classes through the measurement studies demonstrates the applicability of the lightweight and comparatively simpler ML tool SVM as the primary means. We use a combination of all four metrics for accurate predictions.

For each of the datasets shown in Table 3(a), we first train the SVM using 80% of the labeled data and use the rest for testing purposes. Significantly high accuracy in classification can be seen with dataset D1 in Table 4(a). Dataset D2 also shows quite similar values. We further experiment with the datasets having higher traffic intensity (D3–D7) and find that LiVeR shows quite good performance with an average accuracy of 92.5%. For cross validation, we train the model using one dataset and test it using another dataset. We carry this out for several combinations of the datasets as summarized in Table 3(b). The rising intensity of traffic can be seen to cause degradation in the performance of LiVeR. Overlapping occurrences of the vehicles are one of the prime reasons which are explicitly studied in Section 8.3.

Systematic use of RF as a sensor for detecting and classifying vehicles enables LiVeR to perform almost without any degradation during even adverse weather conditions or nighttime, which is quite hard for vision-based approaches to accomplish. Results based on datasets D4, D5, and D9 depict this fact as shown in Table 4.

Table 5 summarizes the performance of the existing RF-based strategies for both detection and classification. The WiFi-based work [52] also addresses multi-lane traffic. However, to avoid complexity, it deals with only rural traffic, which is quite simple compared to the city traffic considered for the testing of LiVeR. Evaluation of LiVeR under multi-lane city traffic is studied in Section 8.3.

Almost all the studies on vehicle detection and classification done so far, especially those based on RF, deal with only single-lane traffic [44]. None of the works even demonstrate how their solution behaves under multi-lane and high-intensity traffic. In particular, the effect of overlap or very low inter-vehicle distance, which is formally described with the help of headway distribution [8], has not been shown in almost any of the existing works.

Low headway can generally confuse any vehicle classification strategy. However, although accurate classification is hard, an approximate idea regarding the type of vehicles or the resulting level of congestion over the road can also make quite good sense and become useful in carrying out behavioral studies of traffic. In the following, we note three issues in LiVeR that enable it to get such an approximate idea in multi-lane traffic:

Low Headway in the Camera-Based Approach. Note that low headway has also been a serious problem due to occlusion in camera-based solutions, despite the use of heavy-weight equipment, computing systems, cloud assistance, and sophisticated computer vision strategies. Low light as well as adverse weather conditions (e.g., fog or rain) have an additional impact on such issues. In contrast, the lightweight and low-cost solution proposed by LiVeR performs considerably better even under low headway amidst all such adverse situations. In the following, we provide a quantitative study of the accuracy of LiVeR under low headway.

To study the behavior under inter-vehicle overlap or low headway, we introduce three more classes: L-mix, M-mix, and S-mix. These are defined considering the shading effect. For example, the presence of one Type-L vehicle can shade the presence of vehicles of Type-S and Type-M. The class L-mix thus represents a mixed situation where all types of vehicles may be present with at least one Type-L vehicle. M-mix represents the mix of Type-S and Type-M vehicles with at least one Type-M but no Type-L vehicle. S-mix denotes the cases where only multiple Type-S vehicles are present.

Dataset. We collect dataset D8 from multi-lane traffic in a similar way as explained in Section 8. The detailed characteristics of D8 are shown in the second to last row of Table 3(a). We label D8 considering a total of seven classes (including Type-N) and train an SVM accordingly.

Table 6(a) summarizes the average accuracy values when training is done on seven classes over the complete dataset D8, whereas testing is done on the dataset D4 for each of the four basic classes. We observe that several cases of Type-S are wrongly classified as S-mix. Similarly, some occurrences of Type-M are classified as M-mix. We also observe that two overlapping occurrences of Type-M are sometimes classified as Type-L, and two overlapping occurrences of Type-S vehicles are sometimes classified as Type-M, as discussed previously. The mean accuracy of the overall classification thus degrades due to the overlapping occurrences of the vehicles. For a complete understanding, we derive the headway distribution and its average from different segments of our collected data with the help of GT. Figure 14(i) shows the accuracy obtained in vehicle classification for different mean headway. It can be seen that classification accuracy gracefully degrades with lower mean headway (i.e., under higher traffic intensity). Conversely, the proposed solution would still be able to bring forth an approximate idea regarding the classes of the vehicles under quite low headway/heavy multi-lane traffic.

A recent RF-based strategy [44] adopts a similar RF-based approach for vehicle detection and classification, as briefed in Section 2. However, it fundamentally employs a blind flow of packets with an inter-packet gap of 8 ms which is fixed irrespective of the presence of traffic or even its intensity. The lack of an efficient protocol and dependence on raw RSSI make the strategy quite energy-hungry. In the following, we demonstrate a comparative study in terms of energy consumption and longevity of LiVeR and prior work [44] in terms of battery life.

From the collected dataset, we find that in a single NI in LiVeR for Type-S, Type-M, and Type-L vehicles, it results in the transmission of 3, 4, and 6 packets on average. For a generic calculation, we set the values of \(\alpha\) , \(\beta\) , and \(\gamma\) of Equation (5) accordingly. Considering high traffic over a span of 1 hour, and assuming the value of x to be 0.8, we calculate the total number of packets transmitted under two distinct cases with the values of the fractions \(V_{S}\) , \(V_{M}\) , \(V_{L}\) as (0.2, 0.3, 0.5) and (0.5, 0.3, and 0.2), referred to as Case-1 and Case-2, respectively. It can be calculated from Equation (6) that LiVeR employs approximately 167,625 packets under Case-1 and 155,000 packets under Case-2, whereas prior [44] employs 450,000 packets under both the cases. Figure 13(i) shows the comparison of the number of packets used in LiVeR and prior work [44] over a span of 1 hour. In both cases, it can be observed that LiVeR employs approximately one-third the number of RF packets while achieving similar accuracy in the detection and classification of the vehicles.

We further study the consumption of energy by the TelosB devices during the execution of different phases of LiVeR. The study is conducted using Monsoon power meter. SCPhase works at TXP of 31 to maintain the robustness of the protocol. DCPhase runs under quite a low TXP based on the inter-MU distance. We measure the lifetime of the battery under different values of GP and different TXP for different capacities of the battery. The energy consumption pattern of a single GP in the initiator and the receiver MU are shown in Figure 13(ii)(c) and Figure 13(ii)(d), respectively. The average lifetime of the MUs under different battery capacities as obtained from the assessment made by the power meter is shown in Figure 13(ii)(a) and (b) for two different GP values. It can be observed that LiVeR can sustain on battery for at least 145 days under a GP of 256 ms, whereas it can sustain even for more than 1 year (500 days) when the GP is set at 2 seconds.

We use the Contiki network simulator Cooja [34] for all of these wide-area simulation-based experiments. Two simulation scenarios, referred to as ES-1 and ES-2 (shown in Figure 14(ii)), are created to mimic two different types of physical arrangements of the roads. ES-1 and ES-2 employ a total of 100 TelosB devices forming a 2D-grid-like structure over an area of 2,000 \(\times\) 2,000 m² and 1000 \(\times\) 1000 m², respectively. Inter-MP distance is set as 50 m and 75 m in ES-1 and ES-2, respectively.

We explore the roles of the FNs and their interactions with the MPs in accomplishing a wide-area operation. Since under the simulation setting we do not have real vehicles to obstruct the communication links, for the DCPhase we use the simplest possible design framework (i.e., PG). In the IPhase, we integrate the protocol Chaos [21] for all-to-all data sharing. The metrics LT, RO, and RXCT as defined in Section 3.1 are also used for the evaluation of IPhase. However, instead of TC, we use Hop Count (HC) as described next.

Hop-Count. In an instance of Glossy, the parameter Relay Count (RC) is used by a node to keep track of the number of times a packet has been transmitted/forwarded [15]. It is both maintained as a variable in the node as well as communicated through all the transmissions. The value of the RC that a node obtains from the reception of the very first Glossy packet indicates an approximate hop position of the node w.r.t. the initiator. We use this value as the HC in this study.

Each experiment is executed for at least 1,000 iterations. The metrics are measured in each node and presented as an average over all the nodes and iterations along with the standard deviation.

Effect of the Number of MPs. First we experiment with a skeleton network created solely by the MPs (i.e., no FNs). Figure 15(i) shows the plots of HC, RXCT, LT, and RO for both SCPhase and DCPhase (in PG) for varying numbers of MPs under ES-1. The higher the number of MPs, the higher the diameter of the network which is reflected in almost linear rise in RO, LT, and HC. RXCT remains the same implying a smooth functioning of the system. Note that the change in the number of MPs affects only the results obtained from the SCPhase but has no impact on the DCPhase, as it faces no change while getting executed (DCPhase is inscribed inside SCPhase).

Effect of FNs. To understand the effect of the FNs, we start with a setting with 20 MPs and gradually keep on adding the FNs in different ways. Figure 15(ii) shows the average HC, RO, RXCT, and LT in each of these cases in both SCPhase and DCPhase in ES-1. It can be observed that there is almost no effect on the system performance as long as the MPs are installed maintaining a proper inter-MP distance so that the network remains connected. Glossy, being a highly robust protocol, is quite able to sustain even with a skeletal setting of the MPs with no FN.

IPhase. Figure 15(iii)(a) through (d) show the LT and RO in IPhase for varying numbers of MPs and FNs under ES-1 and ES-2, respectively. It can be observed that RO and LT in IPhase almost linearly rise with the number of MPs in both settings but do not show any significant effect with the rise in the number of FNs. Note that only the MPs act as the source of data, whereas FNs only act as forwarding devices.

The framework proposed in LiVeR is quite capable of binding a large number of MPs under the same hood. However, due to the installation of the MPs only over the roads, the inter-MP network may look minimally connected. The experiments described previously show that the ST-based framework used in LiVeR, despite having such a minimally connected structure, can carry out its job without support from even a single extra FN.

It is quite interesting to note that the wide-area monitoring capability of LiVeR provides it with a special capability of combining the results obtained from multiple MPs and using it for fine-grained classification of the vehicles as noted in Section 8.3. Let us consider the scenario depicted in Figure 12. There are three MPs installed over a road. Let us also consider three vehicles, namely one large bus and two cars passing over the road. Due to differences and variations in the speeds of the vehicles, there is a high chance that the MPs will have different views at different time points, as shown in the figure as well as summarized in Table 6(b).

However, by virtue of the IPhase, when the data from the MPs get disseminated among each other or collected at a dedicated sink node, doing a simple analysis based on a timestamp can bring forth a better picture of the scenario, as shown in Table 6. A simple union of the timestamped information obtained from all the MPs can serve the purpose.

Experimental Study. To evaluate the proposed strategy, we carried out an experiment with three MPs installed over a moderately busy road and one sink node in the junction point (endpoint). By using the protocol Chaos in the IPhase, we collect data in the sink node. The experiment is conducted for 30 minutes. The average headway was found to be 20 seconds, which indicates a setting where several instances were found where vehicles overlapped with each other. An SVM was trained using datasets D1 and D2 (see Table 3(a)), and it is used for on-the-spot testing in the current experiment. Figure 16 shows the results. Due to very low headway, the accuracy obtained in the individual MPs is found to be comparatively lower, as is also found for other similar datasets (see Table 3(a)). However, it can be observed that the predictions at the sink node obtained based on a timestamp-based analysis and union of the outcomes from the three MPs are up to 20% more accurate than the predictions obtained at the individual MPs for the classification of the vehicles.

Experiment-based studies reported in Section 6 show some failures in LiVeR under high traffic where there are overlaps among the vehicles. However, the performance of LiVeR is much better in single-lane settings where overlapping cases are negligible. In general, the proposed strategy can be quite effective in privacy-preserving detection and classification of vehicles in places where the traffic is low or moderate. For example, understanding the dynamics of the vehicles moving inside a large campus area or inside a certain locality, or residential area inside a city, can be quite crucial for automated and continuous detection of anomalous situation, flow analysis, automatic controls of the gates based on inflow and outflow, automated maintenance of vehicular statistics, and several other similar objectives. Keeping such applications in mind, we carry out experimental studies to explore how LiVeR performs in real stand-alone applications inside the campus of IIT Bhubaneswar. We build a setup consisting of 12 MPs near the main gate and its surrounding area inside the campus. Figure 17(a) shows the installation of a single MP, whereas Figure 17(b) shows the placement of all the 12 MPs over the target area. In the following, we discuss our studies based on the measurements obtained from these MPs.

Independent Measurement. MP1 is installed near the main entrance to the campus of IIT Bhubaneswar. It is installed in a way so that all inbound traffic (i.e., all vehicles that are entering the campus) go through MP1. We carry out the recording using MP1 continuously for a period of 5 hours. Due to installation near the main entry, each and every vehicle is made to enter one by one through the MP. All the measurements done in MP1 are communicated and logged in a central server through the attached RPi (see the device setting in Figure 5(ii)). Video recording of the experiment is done to collect GT. A comparison of the on-the-spot classification of the vehicles by MP1 and the same obtained through the GT is shown in Figure 18(i). Due to sequential entries of the vehicles with sufficient headway, MP1 is found to be quite accurately detecting and classifying almost all the vehicles that enter the campus.

Very little public transport (buses) is allowed to enter the campus. Thus, the number of Type-L vehicles inside the campus is comparatively low. It includes school buses, local conveyances (traveler), and a few trucks due to the ongoing construction works. However, trucks are not usually allowed much in the morning hours due to movement of the students. During our experiments, we therefore found the number of Type-L vehicles detected to be quite low. Hourly measurement data of MP1 is also shown in Figure 18(i)(b). It can be seen that during the morning hours, inbound traffic (vehicles entering through MP1) is quite high, and it decreases gradually with time. Total and hourly measurement data of all the MPs are shown in Figure 18(ii)(a) and Figure 18(ii)(b), respectively. However, note that it is not feasible to record the video (for GT) simultaneously at each of the MPs. The accuracy of these measured data therefore cannot be checked directly as is done for MP1. Figure 18(ii) shows only the number of vehicles detected by the MPs and their hourly decomposition. To indirectly assess the accuracy of all the MPs, we exploit the correlated measurements over different MPs throughout the experiment, as explained next.

Coordinated Monitoring. For automated data collection and coordinated learning by the MPs, we activate the IPhase of the protocol where we use the protocol Chaos in all-to-all data-sharing mode as studied in Section 9. The area selected for the experiment is fundamentally a region that connects three different important places of the campus, namely the academic area, administrative building, and residential area. The directions of these places are shown in Figure 17(b). From the placement of the MPs, it can be observed that if any vehicle passes through MP1, it is supposed to be detected by MP7, followed by either MP9 in case it goes toward the academic area, or by MP6 in case it goes toward the administrative building, or by MP4 in case it goes toward the residential area. Some possible paths emerging from MP1 are shown in Table 7(a). Similarly, if something is detected to be passing through MP3, the same vehicle should be also detected by MP2 if it goes outside the campus, or by MP7 and MP9 in case it enters the academic area, or by MP6 in case it goes toward the administrative building. If some vehicle is detected by MP8, it may be subsequently detected also by MP6 or MP4 in case it goes toward the administrative building or outside the campus, respectively. From the preceding trajectories, it can be understood that local measurements obtained from different MPs should have an approximate correlation with each other. In this context, we study the following two types of correlations:

Results. Figure 18(iii) shows the comparison between the RHS and LHS of the equations shown in Table 7(b). It especially demonstrates how the comparisons evolve through accumulation over different time spans. For a vehicle to move across all the MPs associated with a given equation takes a finite amount of time. For a bigger junction (e.g., for the equation shown in the first row of Table 7(b)), it involves several possible trajectories and hence takes comparatively longer time for the vehicles to cover all the components associated with the inflow and outflow of the junction. Therefore, it can be observed that for accumulation, even over 30 seconds or below the match between the LHS and RHS of the equation is quite poor (see Figure 18(iii)(a)). However, for accumulation beyond 5 minutes, the match is found to substantially improve. With an accumulation of 30 minutes or more, an almost perfect match between LHS and RHS can be observed. These results provide enough evidence that the detection at each and every MP has been as accurate as expected.

Discussion. The capability of LiVeR in the detection and counting of vehicles is quite evident from the experimental results, as explained previously. From the dynamic information obtained from different MPs, various useful inferences can also be drawn. For example, MP6 and MP5 in Figure 17(b) yield an approximate inflow and outflow w.r.t. the admin area, respectively. Thus, the values of MP5 and MP6 at any point in time can give an approximate idea regarding the number of vehicles that are currently inside the admin area. Several similar inferences can be drawn based on different MPs and their combinations. ST-based framework enables LiVeR to efficiently use the shared ISM frequency band through lightweight strategies [9, 11] for in-parallel measurements in multiple nearby MPs. Moreover, in the IPhase, LiVeR can exploit advanced ST-based data-sharing strategies [10, 12] for efficient inter-MP collaboration. LiVeR can exploit these facilities to verify the cumulative behavior of the vehicles. In general, it can be fed with a set of pre-defined equations. For the detection or identification of different possible anomalous situations, LiVeR can keep checking the overall status through the evaluation of the equations at regular intervals. Study of such applications is one of our future goals in this direction.