## 4 TraSLowPeR Implementation Experience over iTETRIS  
We have implemented our protocol to work over the iTETRIS framework, a platform specifically designed to simulate Intelligent Transportation Systems (ITS) scenarios by integrating, through a central component used for synchronization and coordination, two widespread and community-recognized simulators: the ns-3 communication network simulator [22] and the SUMO road traffic simulator [23]. The iTETRIS framework supports the development of user applications that can concurrently interact with both simulators, thus allowing a better evaluation of the implemented protocols thanks to the real-time feedback possible between network and road traffic simulations, at each simulation step, as described below. While developing our solution, we have also extended the general-purpose iTETRIS simulation framework, by adding an interface that can be used as the foundation for new user applications to facilitate the implementation of new protocols while avoiding most of the complexity of iTETRIS. In fact, notwithstanding its potential, iTETRIS is recognized to be scarcely usable by the community in the field, as also shown by its slow adoption. The main goal of the developed interface is the separation of all the iTETRIS-specific interactions from our protocol specification, thus also improving possible portability over different simulation platforms. Our original iTETRIS extension is available for download at [[http://lia.disi.unibo.it/Research/iTetrisUniboExt/](http://lia.disi.unibo.it/Research/iTetrisUniboExt/)]([http://lia.disi.unibo.it/Research/iTetrisUniboExt/](http://lia.disi.unibo.it/Research/iTetrisUniboExt/)), together with some additional implementation details, which are not central to the scope of this paper. In particular, our user application is organized into two layers: (i) a common layer shared by all the different protocols that manages the interactions with the framework and offers an API to send and receive messages; and (ii) a protocol layer that defines the logic of the specific protocol interacting with the API of the common layer. In iTETRIS, unlike in classic network simulators, the simulation is time-discrete, to allow the interaction between the various sub-simulator parts. At every time step, the central coordination component of iTETRIS sequentially commands the execution of the two sub-simulators and of the iTETRIS-based applications on top. This behavior exhibits significant advantages in terms of modularity and extensibility of the sub-simulator and the integrated framework, but introduces delays in the interaction between vehicles and RSUs, which can lead to degraded performance if compared with each of the sub-simulator separately. Figure 1: TraSLowPeR sample operation on a three way intersection. In (**a**) the RSU sends a request message limited to the road east arriving (E_a), with a reply windows of 200 ms. The nodes a, b, c, and d will then reply to the message. After the reply window elapses, the RSU will send a new request message, (**b**), for the road east leaving (E I). Next the RSU will probe the road north arriving, (**c**). The TraSLowPeR RSU will continue to sample all the roads converging in its intersection in a round robin fashion. To compare the performance of TraSLowPeR with the three protocols mentioned in Section 2 while running over similar conditions, we have originally implemented also MobSampling [17; 19] in iETRIS. While this implementation has maintained the protocols' logic exactly as presented in the related papers (as well as the same configuration parameters), the very few minor variations listed below were introduced to have a fair comparison with our solution. By focusing on our MobSampling protocol implementation in iETRIS, we assigned the sampler role to the RSU and centered the target area to its position: this eliminates the need of a starter node and of a role switching procedure.