# Predictive Migration Performance in Vehicular Edge Computing Environments
## 3 Proactive Approach to MEC Resource Management
In the second stage, the objective function is used to find \(\vec{H}_{h}\in Com_{j}\) such that the resource usage of the MEC hosts in the community \(Com_{j}\) is optimal and \(H_{h}^{-}(t)\leq\vec{S}_{i}(t_{s},t_{e})\). If there is no such \(h\) available, then there are not enough resources in the MEC, and the service is forwarded to be hosted in the cloud, which serves as a backup solution. Once the initial placement is done, the proactive status analysis starts based on the input from the mobility prediction module, which predicts the base station handover events for all current MEC users. The prediction information is used so that the user service is migrated to an optimal new location before the handover event actually occurs. In other words, the mobility prediction module should be able to predict a handover with a time of at least \(X\) before it actually happens, where \(X\) is the time needed to migrate the service, which depends on the bandwidth and service size, through the MEC network infrastructure. In this way, the user does not experience any additional service delay due to migration. Not all handover events require service migration, depending on the definition of the communities relative to the locations of base stations. Only if the change of base station entails a change in the MEC community is the attempt to migrate the service to a new MEC community made. The migration is only activated if there are enough resources to migrate the service to the new optimal MEC community. If not, the service remains at the old location. The new optimal MEC community is identified in the same way as described for the initial placement algorithm. Due to the fact that the migration process is based on live migration, during migration, the service will use double resources: at the old MEC host where it resided, and at the new MEC host where it is decided to be moved. If there are no available resources in the new optimal MEC community, then the migration cannot be performed preemptively, and the system regularly checks if the migration can  
Figure 2: Example service migration due to change in coverage area. be performed at some point later in time until it succeeds in migrating; otherwise, a new handover event is predicted and a new optimal MEC community destination is chosen, or the service end time is reached and the service is no longer needed. It is straightforward to conclude that a correct handover prediction done sufficiently in advance will yield the best results, enabling the best chances to migrate the service in order to maintain the minimum latency perceived by the end-user equipment. Suboptimal situations might occur due to two reasons: (1) As discussed previously, the handover prediction may be correct and available in time, but the lack of resources in the new community imposes a higher latency that is experienced at least temporarily until the situation changes; (2) the handover prediction is not correct, and thus, the service is not migrated or is migrated (see Figure 3). A more detailed implementation of the proactive migration check algorithm is provided in pseudocode in Listing 1, and the service migration function is given in Listing 2. The details of the implementation of the initial placement algorithm are out of the scope of this paper, and its pseudocode can be found in [18]. ```
voidProactiveMigration(Service[]S,Community[]Com,BaseStation[]BS){ inthandover=-1;//nhandoverpredicted for(inti=0;i<S.length();i++){ //callmobilitypredictionalgorithm Locationloc=predictUserLocation(S[i]); //checkforhandoverevent BaseStationbs=getBaseStationCoveringLocation(loc); Communityc=getCommunity(bs,BS,Com); if(c!=getCommunity(S[i])){ intc=ServiceMigration(S[i],bs,Com); if(c!=-1) //verifycorrectpredictioninXseconds Scheduler.add(MigrationCheck(S[i]),X); } //schedulenewproactivecheckeverysecond Scheduler.add(ProactiveMigration(S,Com,BS),1); }
```  
Figure 3: Proactive hierarchical community approach to service migration.