# SURROGATES: Virtual OBUs to Foster 5G Vehicular Services
## 5 Evaluation
### Performance Analysis  
The results collected in the first experiment, which evaluates the request RTT under different vOBU hit rates, are included in Figure 7. With the aim of removing the impact of the mobile network used by the Android phone, the RTT measurements are taken from the data analytics module. The overall request RTT trend shows that, as the request hit ratio increases, the delay is greatly reduced, given that less data requests are sent to the physical OBU and are solved directly by the vOBU. The variability of results also diminish when the hit rate is higher, attending to the confidence intervals. This is due to the connection with the vOBU at the infrastructure is far more stable than using the wireless channel to reach the OBU. When a hit rate of 0% is employed, no RTT values are included for vOBU, given that in this case all requests are sent to the OBU. On the contrary, when a hit rate of 100% is considered, no RTT values from the OBU are reported, since all requests are solved by the vOBU. The overall RTT results when vOBU answers data requests is stable through all configurations, but the ones obtained when accessing the OBU tend to slightly improve when higher hit rates are used. This is attributed to the reduction of requests queued for OBU resolution. With the aim of highlighting the impact of the wireless medium, we have analyzed the time spent by requests on each network segment in this first experiment. Figure 8 shows the overall request RTT values broken down into the time the transactions spent on each part of the network. It can be seen in the plot that the time the request is present in the infrastructure (i.e., from the network analytics module to vOBU) is maintained at around 230 ms, while the time consumed by the OBU ranges from 400 ms, when a hit rate of 0% is used, to 22 ms, when a hit rate of 100% is used. Of course, these values embrace the whole transactions, including the processing time needed by each node, but it is evident that the vOBU proposal is able to soften the impact of the wireless last mile when accessing the OBU. The results of the second experiment about the ratio of request losses are plotted in Figure 9. Here, the vOBU hit ratio has been fixed to 0%, hence all requests are addressed to the OBU. In this analysis, the losses are represented by those requests processed by the vOBU after waiting for a response from the OBU for a parametrized time. It can be seen that a timeout of 300 ms implies that nearly 90% of the requests are solved by the vOBU. When increasing the timeout, the increase of requests successfully processed by the OBU is noticeable, at the expense of a greater delay, as explained above. The application of this timeout is needed in order to assure a proper operation of the system, since TCP transactions with default connection timeouts imply large waiting times when the OBU connection fails. In this case, the vOBU gives a good second choice to provide a cached data from the OBU and allow applications to receive sensor data although the OBU is not available. A time stamp is provided together with the replies, in order to make the application aware of the age of the data. Figure 7: Round-trip delay time (RTT) values for requests when the vOBU hit rate varies from 0% to 100%. Regarding the time needed for the registration of a new vOBU, Figure 10 includes the mean time involved by the process when using the 4G connection. It can be seen that the registration involves near 400 ms in our testbed, and this value is independent from the number of already assigned vOBUs, since the VNFs are pre-loaded and maintained in a pool beforehand. Figure 8: Request RTT per vOBU hit rate attending the network segment involved. Figure 10: OBU registration delay. Figure 9: Requests solved by OBU and vOBU as the response timeout varies. The performance results clearly indicate the delay improvements and the expected request delivery ratio when the SURROGATES proposal is used. The speedup depends on the amount of requests solved by the VNF nodes.