## 3 Our Original Traffic Surveillance Solution for Low Penetration Rate Scenarios
In finer details, each RSU updates its traffic status indicators by periodically broadcasting request messages and exploring every road leading to its controlled intersection in a round-robin way. A request message sent by the RSU contains two data items: (i) the road that is currently being polled and in what direction (approaching or leaving the intersection), (ii) the time allotted by the RSU for the replies from the activated nodes. To identify a road, RSUs and nodes can potentially use many different conventions: from the cardinal direction of the road with regards to the intersection, to the actual name of the road, from pre-defined raw unique identifiers to increasing counters starting from the north direction and clockwise, etc. In our prototype and in the following experiments, for the sake of clarity and simplicity, we used road-name-based identifiers. When a request is received, the receiving node checks if it is traveling on the \"currently investigated\" road: if so, it will reply to the message on a random instant inside the time windows specified by the message to reduce the chance of transmission overlapping with other nodes; otherwise, it will discard the message. The reply sent by a node contains the node identifier, its current position, speed, and acceleration, and its mean speed and acceleration over a selectable (configurable) interval. Each request message defines a reply window within which targeted vehicles have to send their updated status to further minimize the chance of interference among nodes that travel on different roads: this time allotted for the replies is dynamically adapted according to the specific road network and/or to the current traffic status, e.g., by allowing more time for the streets with multiple lanes and in case of heavy traffic. To practically show the primary idea behind our TraSLowPeR protocol, Figure 1 depicts a sample execution of it over a simple road topology and for a single intersection. The most relevant information extracted by the RSU from the messages exchanged through our protocol is the number of vehicles and their average speed for every road in the considered intersection and the aggregated values for the entire area controlled. TraSLowPeR is also able to distinguish the flows of vehicles in every street as divided between the traffic leading to and departing from the intersection. The total number of vehicles inside the coverage area of the RSU is obtained by considering any vehicle replaying to a request message on the current round of requests. These indicators have demonstrated to be sufficient and the most relevant ones for the specific purpose we had, i.e., optimization of traffic lights to reduce traffic congestion, but we have also experimented employing all the monitoring data collected by TraSLowPeR to extract additional higher-level performance metrics, such as estimation of queue length or number of stops required by a vehicle to pass the surveillance intersection [21]. Let us conclude this section by noting that in the reminder of the paper we will deliberately not consider security and privacy issues because the focus of the present work is on the performance evaluation of traffic surveillance solutions while considering communication aspects only and adopting a simulation-based approach. At the same time, by recognizing the importance of that aspect, we briefly note that the TraSLowPeR protocol itself is completely local and requires maintaining at the RSUonly a soft state (stored for a very limited time span) about wireless network identity of the cars in the surroundings. As for other solutions and protocols considered in our performance comparison, instead, all of them completely neglect security/privacy, by considering related aspects as to be targeted in a second step.