# SURROGATES: Virtual OBUs to Foster 5G Vehicular Services
## 5 Evaluation
### Testbed Set-Up  
The deployment considered in the testbed is depicted in Figure 3. The vehicular network used to collect data from vehicles is the one presented in [25]. It supports two communication channels using 3G/4G and 802.11 OCB, although only the 3G/4G one is used in these tests, as can be seen in Figure 3. All traffic generated during the trials within the platform was IPv6 and, given that the telecom operator does not support it, an OpenVPN tunnel was established with a router in our laboratory at UMU premises. This is the router in charge of managing IPv6 network mobility, although this function is not used in this evaluation for the sake of clarity. The employed OBU was a Laguna LGN-20 unit from Commsignia (Budapest, Hungary), running the communication stack described in [25] and provided with a TP-LINK MA-180 modem for 3G/4G (fully high-speed packet access (HSPA) compliant) connectivity. It was connected to the in-vehicle Control Area Network (CAN) bus using an On-Board Diagnosis (OBD)-II interface to gather vehicle state data. The used car was a Renault Clio 4 th generation (Boulogne-Billancourt, France), while the OBD-II interface was an OBDLink SX with a USB connector. The virtualization infrastructure ran on a Dell Poweredge R430 server (Round Rock, TX, USA) with Dual Socket Intel(R) Xeon(R) CPU E5-2630 v4 (Santa Clara, CA, USA) at 2.20 GHz. It ran CentOS 7 (GPL), using OSM version 4 (ETSI, Sophia Antipolis, France) and OpenStack Pike (OpenStack Foundation). OSM was configured with four cores and 24 GB RAM, while OpenStack was provided with eight cores and 24 GB RAM. This virtualization server was physically installed next to the mobility server, in the UMU laboratory. VNFs have been described and provided with a proper software image, all of them using a base Debian 9 operating system (GNU). In order to make easier the software configuration and upgrade, the base images instantiated onto the OpenStack by OSM were provided and configured with their software depending on their kind by means of Ansible scripts. Four VNF types have been on-boarded in the platform according to the roles described previously:  
Figure 3: Deployment carried out in the testbed. vOBU, provided with 1 CPUs, 1 GB RAM and 5 GB HD. * OBU manager, provided with 2 CPUs, 1 GB RAM and 5 GB HD. * Data analytics, provided with 2 CPUs, 1 GB RAM and 10 GB HD. * Vehicle monitoring service, provided with 2 CPUs, 2 GB RAM and 40 GB HD. Several instances of vOBU can be launched as described above, however, during the tests a single vehicle was used. Moreover, as aforementioned, vOBUs are deployed in an individual OpenStack virtualization domain, while the rest of VNFs operate in a different one to be deployed usually in a data center. In our deployment, both virtualization domains have been set-up in the virtualization server. Hence, the data path between the cloud and edge layers is reduced to a virtual connectivity between VNFs running on the same server. This means that our performance results have much more room for improvement when edge and cloud planes are deployed at different and distant locations. Vehicle data is maintained by vOBUs, while the data analytics module aggregates data from all vehicles and feed the monitoring software service. The data analytics module saves all collected data, calculates parameters, and stores them in a MySQL database. In turn, the monitoring service is powered by Grafana version 5.3.1, which is a web service configured to show several vehicle parameters using plots. This VNF generates periodic data requests gathering vehicle data as explained above. Additionally, the VNF for data analytics is also capable of processing vehicle data requests coming from outside. In our case, we have implemented an Android application to also access vehicle data from a mobile device. In the testbed, this application ran on a Galaxy S7 (Samsung, Seoul, Korea) with Android Nougat.