# Error Resilient Coding Techniques for Video Delivery over Vehicular Networks
## 5 Real Scenarios Evaluation
### Test Framework  
For the evaluation of error resilience proposals, we have used three main software blocks (see Figure 9). The first one is formed by an open-source vehicular traffic simulator: Simulation of Urban MObility (SUMO) [23], which models the behavior of vehicles on routes, interacting with other vehicles, junctions, multi-lane roads, traffic lights, etc. The second one is in charge of the simulation of vehicular network communications, particularly those based on the IEEE 802.11p protocol and the IEEE 1609 family of standards (WAVE). For this task, we have selected Objective Modular Network Testbed in C++ (OMNeT++) [24] together with VEhicles In Network Simulation (Veins) [25], which is based on MIxed slMulator (MiXiM) project [26]. The vehicular simulator and the network simulator blocks are connected by TRAffic Control Interface (TraCI) [27]. TraCI creates a TCP connection to allow the communication between the two simulators. The last block deals with video processing. It prepares the encoded bit streams for the tests and also evaluates the quality of the final recovered/reconstructed versions of the streamed video sequences. The encoded bit streams are used to generate video trace files which are injected into the simulations. For this purpose, we developed a new module in OMNeT++. This module provides a new traffic source (video sender) which reads packets from a trace file to deliver them through a vehicular network scenario. Vehicles tagged as video receivers get video packets and write both a file with the correctly received packets and a file with several network statistics. The scenario for the simulations is an area of 2000 m \(\times\) 2000 m in the city of Kiev (Ukraine). Figure 10a shows an orthophoto of the selected region. At the bottom of the picture, the Olympic National Sports Complex can be clearly seen. To obtain the data for the vehicular scenario (lanes, building, etc. ), the OpenStreetMap (OSM) [28] project has been used, as it provides free maps from all around the world. The data obtained from OSM has been converted into SUMO compliant format. Figure 9: Test framework. The map zone selected for the tests, loaded in OMNeT++/MiXiM/Veins, is displayed in Figure 10b. Red drawings represent the buildings imported from OSM. Veins uses a file with polygons to sketch the obstacles and to calculate the visibility between two wireless network interface cards. There is a long avenue that crosses this area from north to south. Along the avenue, three Road Side Units (RSUs) have been positioned, tagged A, B, and C in the figure. They are around 1 km apart from each other. The coverage radius of all the wireless devices is 500 m, with a maximum data rate of 6 Mbps. There is a small area between RSUs A and B that is not covered by either of them, so a shaded area appears. There is also a small area halfway between RSUs B and C that is covered by both of them (where their signals overlap). Therefore, we have three different types of areas regarding transmission: (a) areas where a vehicle receives data from only one RSU (Zone I); (b) one area where the signal is momentarily lost (between the A and B coverage areas)(Zone II); and (c) one area where the vehicle receives the signal from two RSUs (B and C)(Zone III). The three RSUs transmit the same video sequence simultaneously in a synchronized and cyclic way. A total of 450 vehicles are inserted into the scenario, driving in different routes, which come and go from the simulation area. At every moment, there are simultaneously around 80 vehicles in the cited area. The maximum allowed speed is 50.4 km/h. Vehicles send ten beacons per second through the control channel (following the IEEE 1609.4 multi-channel operations). RSUs send periodically, through the control channel, advertisements of the video service that they offer, indicating the service channel used for the video stream. The video client vehicle (labeled in the figure as *) receives that invitation and commutes to the specified service channel in order to receive the video stream.