# Predictive Migration Performance in Vehicular Edge Computing Environments
## 3 Proactive Approach to MEC Resource Management
```
``` intServiceMigration(Services,BaseStationnewBS,Community[]com){ intnewSlocation=-1;//nolocationfound,migrationiscancel if(isInCloud(s))//trytomigrateinedgeinfrastructure//equalsallocationattempt newSlocation=initialPlacement(s,newBS,com) else{//handoverpredicted,trytomoretothenewcommunity Communities[]potentialCom=getSSmallestCommunityWithBS(com,newBS); if(resourcesAreAvailable(s,potentialCom))//activateslowerplacementalgorithm newSlocation=chooseEdgeServer(s,potentialCom); } returnnewSlocation; }
```

Listing 2: Service migration pseudocode. The proposed approach to service migration supports the use of different modules/techniques that provide the function of predictive handovers, i.e., the function call predictUserLocation() in Listing 1. This means that the functional block that forecasts the next community, as given in Figure 3, can be implemented using regressive approaches, such as ARIMA, neural network approaches, deep learning techniques, etc. Incorrect handover prediction is the result of the imperfections of the probabilistic or AI-based learning algorithms that supply the information about its prediction. As already mentioned, the typical mobility prediction algorithms today [15] have different rates of accuracy in their prediction depending on the size of the time window, size of the available training dataset, and level of knowledge. Formally, accuracy in this context can be defined as the fraction of predictions that are correct, or accuracy = number of correctly predicted handovers/total number of handovers. Both false positives and false negatives have a deteriorating impact on the MEC service migration performance. In the case of a false positive, the handover event is falsely predicted and migration is triggered, thus taking up unnecessary resources in the MEC infrastructure. However, from the point of view of latency, this type of error does not have an effect because the service continues to be delivered with the minimum latency to the end-user equipment, and once the false positive is detected, the migration that was started can be cancelled and the resources freed. On the other hand, false negatives include handover events that the prediction module does not report on, in which case the migration occurs as a reaction to the handover, involving a time period when there is suboptimal service delivery with increased latency perceived by the end-user equipment. The main goal of this paper is to analyse the service migration performance in terms of latency experienced in the presence of different prediction error rates compared to a perfect prediction. ## 4 Simulation Description and Details

For the purposes of creating a realistic--yet dense--simulation scenario with autonomous driving as an example MEC service, we studied service-level requirements that were defined for the examples and use cases described by the 5 GAA in its white paper [17]. Autonomous driving is considered as a separate use-case group by the 5 GAA, and is related to the self-driving levels 4 and 5, as seen by the Society of Automotive Engineers. The described use-case examples include assistance for intersection movement, emergency break warning, hazardous location warning, speed harmonisation, sensor sharing, etc. There are different user stories that are related to these use cases, such as exchange of projected trajectories between vehicles, software updates, tele-operated driving, automated parking, map collection and sharing, etc. The typical service-level requirements for these examples include: vehicle range of around 350 m, max velocity of 50 km/h in urban areas, vehicle density of 1500 vehicles/km\({}^{2}\), and max latency of around 120 ms. The simulation parameters' tables presented below show that the chosen values have been tuned to cor respond to the parameters defined by the 5 GAA. Although the latency presented in the results is well below 120 ms, please note that the service latency analysed in this part is the MEC-specific latency, which is one segment of the overall latency experienced by the endpoint.