# SURROGATES: Virtual OBUs to Foster 5G Vehicular Services
## 4 Deployment and Operation of the Solution  
The SURROGATES solution has been implemented in a real testbed using Open Source MANO (OSM) ([[https://osm.etsi.org](https://osm.etsi.org)]([https://osm.etsi.org](https://osm.etsi.org))) and OpenStack ([[https://www.openstack.org](https://www.openstack.org)]([https://www.openstack.org](https://www.openstack.org))), as MANO and VIM, respectively. As it is shown in Figure 2, a single instance of OSM is used for the management of platform VNFs, while two OpenStack domains have been deployed. The one including MEC capabilities hosts vOBU VNFs, while the cloud OpenStack domain contains the rest of modules. Three network services (NS) have been deployed for the vOBUs, management of the platform and final services.  
The bootstrapping of the vOBUs is depicted in Figure 2 on the left (orange color). Upon starting up the physical OBU, if it is the first time that the unit connects with the platform, a _vOBUrequest_ is sent to the well-known address or domain name of the OBU manager (1). Considering that there is not a vOBU allocated for the OBU, a new one is required to OSM using its northbound interface (2). Then, OSM instantiates a new vOBU (3) and sends the details of the NFV to the OBU manager (4), which, in turn, provides the vOBU access details to the physical OBU (5). From now on, all data extracted from vehicle sensors are collected by the vOBU (6). Given the localized nature of MEC processing, the physical OBU will launch a new vOBU request when the vehicle drives outside the area covered by the edge domain.  
Figure 1: Overall architecture of the virtualization infrastructure.  
Given that vOBUs are deployed in more powerful servers in relation to OBUs, they do not only offer more processing throughput, but also the capability to run a wider variety of software by using x86_64 (CISC) equipment. This inherent point in NFV is highly relevant in the transport ecosystem and, in general, the embedded hardware field, since most of the OBUs are usually low powered ARM (RISC) architectures. In addition, these elements are usually vendor blocked and limited in terms of library upgrades and integration by closed firmware, while VNFs can evolve their software independently, easily adopting new technological trends or applying new software development techniques.  
Data requests from final services can be resolved at three layers in the platform, as shown on the right of Figure 2 (purple color). When a service VNF requires data from the vehicular platform, it launches a _Datasetset_ message that is processed by the data analytics module (7). If the data had been fetched previously or comply processed values, the request is locally resolved (8a). However, if data from a particular vehicle is necessary and it is not cached, the involved vOBU is searched through the OBU manager (8b, 9), and the request is forwarded to it (10). The vOBU can locally resolve the request most of the times (11a), since the monitoring middleware collects data continuously from the vehicles (6). However, if an instantaneous data about a particular information source is needed, the request could be forwarded to the physical OBU (11b).  
The way data is accessed and processed reduces the request resolution delay, saves wireless resources in the last mile network segment, and deals with the issue of several services wanting data from the same vehicles. Additionally, it is important to bear in mind that vehicles are connected through a mobile network that can suffer from eventual disconnections and can be an expensive channel in terms of cost and energy, above all when considering two-wheel vehicles.  
Figure 2: Operation of the system for virtual OBU (vOBU) bootstrapping (**left**) and data gathering (**right**).