# Predictive Migration Performance in Vehicular Edge Computing Environments
## 3 Proactive Approach to MEC Resource Management
Thus, to be able to work under the restriction of 120 ms, it is imperative that the MEC networking latency that is added to the 5G wireless communication latency is as low as possible. This is of critical importance for special emergency use-cases example, where the service level requirement for latency can drop down to a maximum of 10 ms for the overall communication. A large-scale urban simulation environment was created using the CloudSim simulator for the MEC infrastructure and SUMO for the simulation of the vehicular network. The urban simulation scenario was defined over a geographical coverage area of 1.8 \(\times\) 2 km\({}^{2}\), which corresponds to the city centre of Alicante, Spain. The real OpenStreetMaps information, which includes traffic lights, roundabouts, pedestrian crossings, speed limits, street priority, maximum speed, and all the necessary information of traffic regulations, was used to describe the scenario in SUMO. Different traffic densities were considered when configuring the SUMO simulation in order to study the performance of our proactive MEC resource management approach with different congestion levels, which range from light-density traffic to dense traffic without jams. In Table 1, we included the numerical input data that were configured in the SUMO simulations. Vehicles randomly show up in the simulation area during the simulation time of 10,000 s, and each car must go through at least 500 m before it randomly leaves the simulation area. An MEC service is requested at the moment the vehicle appears and is destroyed when it exits the simulation. During the simulation, the density of the vehicles in the urban area remains constant. All simulations were repeated with different seeds to increase the quality of the sample's representation. The output of SUMO was post-processed by a transformation engine as an intermediate step (please see Figure 4) in order to add information about the 5G cells defined by the Voronoi tessellation of the coverage area and, hence, to associate the active base station that covers the area wherein each vehicle is located. This information entered CloudSim, which showed a high-level design of the integrated simulation environment with a description of the interface connections between both simulators and the transformation engine. This process is described in detail in [20]. \begin{table}
\begin{tabular}{l c} \hline
**Parameter** & **Value** \\ \hline OpenStreetMap area & 1.8 \(\times\) 2 km\({}^{2}\) \\ Simulation time & 10,000 s \\ Min path length & 500 m \\ max velocity & 50 km/h \\ \hline  & (1) [4900, 5000] vehicles \(\sim\) 1375 vehicles/km\({}^{2}\) \\ Vehicle density ranges & (2) [5700, 5800] vehicles \(\sim\) 1600 vehicles/km\({}^{2}\) \\  & (3) [6900, 7000] vehicles \(\sim\) 1930 vehicles/km\({}^{2}\) \\  & (4) [8600, 8700] vehicles \(\sim\) 2400 vehicles/km\({}^{2}\) \\ \hline MEC services requested per vehicle & 1 \\ Vehicle type & passenger car \\ Pause time & 0 \\ Range & 300 m \\ Number of base stations & 9 \\ Number of hosts per base station & 5, 7, 9 11, or 13 \\ \hline \end{tabular}
\end{table} 
Table 1: SUMO simulation parameters. Regarding the underlying network topology that was configured, our scenario set up consisted of a 5G telecommunications network with nine base stations connected through a 1 Gb network supported by a hierarchical fat tree topology with three layers, which were: edge, distribution, and core. Depending on where the service was allocated in the MEC system, the MEC delay between the base station and the service provided would include more or fewer hops through the network topology, as the service data might have to go through the distribution layer or even through the core layer. We used the standard delays for edge, distribution, and core layer links that were provided by CloudSim. Each base station had a homogeneous MEC datacentre connected with some MEC hosts.