# Predictive Migration Performance in Vehicular Edge Computing Environments
## 3 Proactive Approach to MEC Resource Management
### Edge Service Migration Performance

When the MEC service starts in an MEC coverage area and the vehicle moves according to a specific trajectory through the geographical area, changing its connection from one base station to another, the edge service that is firstly allocated in the MEC system is, then, migrated to a host of the MEC datacentre that is attached to the new base station, i.e., local MEC datacentre. This migration can be considered as an \"optimal\" association, as the \begin{table}
\begin{tabular}{c c} \hline
**Parameter** & **Value** \\ \hline Virtual resource usage & space sharing \\ MEC network & 3 layer 1 Gb fat tree \\ MEC network switches & 9 edge, 3 access, 2 core \\ MEC network latencies & 1.57 ms, 2.45 ms, 2.85 ms \\ Number of server hosts & 45, 63, 81, 99, and 113 hosts \\ Server host type: & 2–6 cores, 12 GB RAM, 100 Mbps \\ Initial placement policy & hierarchical communities \\ Migration policy & follow-me \\ VM characteristics & 2 cores, 2 GB RAM, 100 Mbps \\ Cloudlet complexity & 100\% of CPU time used \\ \hline \end{tabular}
\end{table} 
Table 2: CloudSim simulation parameters. delay obtained is the smallest possible delay. In case the service migration to the local MEC datacentre cannot be performed because there are not enough resources, then the MEC service remains behind, so we consider this situation as a \"1 hop\" or \"2 hops\" connection based on the number of hops of the fat tree network topology. The failed migration process is reattempted every time the \"keep-alive\" service poll runs, so it might happen that the service is finally migrated to the local MEC datacentre at some point. If the service has just started or the vehicle enters the MEC coverage area and there are not available resources in the local MEC datacentre, then the service is allocated to the cloud, and the migration is periodically reattempted. In Figure 6, we show the average number of migrations performed throughout the simulation time, considering 5, 7, 9, 11, or 13 MEC hosts per MEC datacentre and, thus, a pool of 45, 63, 81, or 117 hosts in the whole MEC system. The number of services run in the simulation is in the range of 8600 and 8700 (they vary depending on the simulation run); therefore, we can observe that the migration information presented in Figure 6 is linked to the maximum workload considered in this study. The graphical analysis shows how, with 45 hosts (see Figure 5(a)), the number of failed migrations, which are represented with the \"1 hop\" and \"2 hops\" metrics, is significantly high compared to the number of successful migrations, which are represented as the \"optimal\" migrations in dark red. We added a yellow dotted line showing the migrations that are reattempted and end up being successful in the next service poll. We also show the reattempts that fail to be optimal with a white dotted line. When increasing the number of MEC hosts to 63 (see Figure 5(b)), the number of failed migrations decreases, and this trend continues downward, as it is inversely proportional to the MEC host pool increase (Figure 5(c),d). The results show that it is imperative to have enough resources in the MEC infrastructure to be able to support the projected number of services and their dynamics. The peaks that are present in the middle of the simulation are a representation of a situation wherein a large number of vehicles change their current base stations, requiring a corresponding MEC service migration. This is a situation where the MEC resource usage hits a peak because of the double resource reservation during the migration process. Figure 5: Number of allocations of edge services considering their distance to the MEC host that is providing the service. ### Edge Service Delay Analysis

The service delay experienced by each vehicle when accessing the application in the MEC datacentre can be computed in many different ways that consider all the possible latencies that affect the final response time.