## 5 Experimental Evaluation  
We have assessed the benefits of our proposed combination of VTLs and urban platoons via simulation. The scenario consisted of a Manhattan grid urban environment of 7 \(\times\) 7 intersections and 1375 \(\times\) 1375 m with two lanes per road (one in each direction) and a maximum speed of 50 Km/h. To simulate an application in which the exchange of information among the vehicles may affect their movements, we resorted to VEINS [33], a tool that combines an event-based network simulator (OMNeT++) and a road traffic simulator (SUMO). The architecture, including the modules from our own works, is shown in Figure 6.  
Our goal was to compare the performance of four different configurations:  
* **Configuration 0 (traditional traffic lights only)** provides the performance baseline, managing no platoons and no VTLs. Rather, there are 12 intersections governed by traditional traffic lights (Twelve intersections is nearly one quarter, in line with what we explained is common for big cities in Section 2). We implemented a SUMO module to provide three different policies for these traffic lights: a fixed-time policy (FT), the _Max-Pressure_ (MP) feedback control of [34] and the _Adaptive Max-Pressure_ (AMP) of [35]. Their operation was completely autonomous, not informed of the existence of platoons or any other communications. * **Configuration 1 (One-hop VTLs)** is representative of the state-of-the-art, with no platoon management, but with VTLs running in each intersection according to the algorithm proposed in [14], with the implementation and parameterization of [20]. All communications among the vehicles are one-hop, implemented directly on top of IEEE 802.11p. * **Configuration 2 (traditional traffic lights + platoons)** incorporates our proposal for platoon management only, with traditional traffic lights as in configuration 0. Nearby vehicles steadily exchange information about their routes (via one-hop broadcasting), and a platoon is formed (and announced in multiple hops, as presented in Section 4.1) wherever two consecutive cars find that they will be one in front of the other for 3 subsequent intersections or more. Any other vehicles consider joining a platoon if they will be in it for 2 road segments or more, but no one considers deviations from its intended route. * **Configuration 3 (VTLs + platoons)** represents the complete proposal of this paper, with the same platoon joining policy of configuration 2 and the platoon-aware VTL management procedures of Sections 4.2 and 4.3. For configurations 2 and 3, we developed the VTL & platoon management procedures within VEINS, and reused implementations of the VaNetLayer and VNIBR protocols as OMNeT++ modules (The space between intersections in the simulation scenario allowed two L2 VNs and one L3 VN along each road segment). The _Platooning Extension for VEINS_[36] was used to implement the platooning operations, with precise control on the vehicles' speeds and distances. As an alternative to VNIBR for routing, we wrote an OMNeT++ implementation of VNAODV (_Ad hoc On-Demand Distance Vector on Virtual Nodes_), an algorithm proposed in [37] to demonstrate the capabilities of the virtualization layer  
Figure 6: Architecture of our VEINS-based simulator. that preceded the VaNetLayer (see [38]). The comparison between VNAODV and the different flavors of VNIBR serves to highlight the gains from a purely intersection-based routing approach. We ran simulations of configurations 0, 1, 2 and 3 with three different vehicular densities: low (512 vehicles), medium (1024 vehicles) and high (2048 vehicles). The sets of routes for the vehicles were generated randomly, but each set would be used under the four configurations to ensure fair comparisons. Within these settings, we were interested in measuring travel times and fuel consumption for all the vehicles, as well as for those that had been in a platoon (at the head of it or not) at least once. The fuel consumption estimations were made according to the HBEFA 3 model [39].