# Software-Defined Vehicular Cloud Networks: Architecture, Applications and Virtual Machine Migration
## 2 Background of Technologies behind SDVC
### Virtual Machine Service in Vehicular Cloud Computing Network  
A MEC cloud is accessible only by the nearby vehicles, i.e. those located within the radio coverage area. This fact helps us recall the concept of an RSU cloudlet [4]. An RSU cloudlet refers to a small-scale RSU cloud site that offers RSU service to the closest vehicles. A vehicle can select a nearby RSU cloudlet and customize a transient RSU service for use. Here, we consider the customized RSU service as a transient RSU service because the RSU can only serve the vehicle for a while [4; 6].  
Figure 3 shows the dynamic VM synthesis approach to deliver a VM state to infrastructure [6]. A vehicle selects a nearby MEC server. The latter customizes a transitory cloud service to be used for a while by the vehicle. This transitory cloud service is offered as virtual resources in terms of VM. The vehicles are considered mobile nodes that have a VM, named VM-overlay, from the MEC infrastructure that already possesses the VM-base. The VM at the MEC server is named VM-base [4]. A VM-base is a resource template recording the basic structure of a VM, while a VM-overlay mainly keeps the concrete resource requirements of the customized VM [4]. The customization of of VM to serve the vehicle is explained as follows. The vehicle sends the VM-overlay to the MEC server that already possesses the VM-base. The MEC server reloads the VM-base and applies the VM-overlay to VM-base. Finally, the MEC server completes the customization to deliver the dedicated VM. The MEC server executes the dedicated VM to allow the vehicle to use it to run transient cloud service. During the cloud service, as the vehicle moves along the RSU, it switches between different MEC infrastructures. During the handover to the next MEC infrastructure, the vehicle needs to wait for a short time before the next MEC server resumes the dedicated VM. This process of migrating the dedicated VM to the next MEC is referred to as VM migration. During the re-initiation time of the cloud service, the dedicated VM might disconnect temporarily. In the case the vehicle drives out of radio coverage of MEC infrastructure, only a minimum delay will be experienced as long as the vehicle remains out  
Figure 2: V2X services based on two working modes of cellular network.  
of the radio communication range. In addition, the issue of loss of connectivity closes the Transport Communication Protocol (TCP) established with the next MEC infrastructure; consequently, the next MEC server would not resume the dedicated VM. After the vehicle completes the cloud service running through the dedicated VM, it alerts the MEC server, which in turn discards the VM.  
MEC computing should be able to keep cloud service by leveraging VM migration strategy. VM migration decision-making based enables MEC computation resources to keep the dedicated VM one hope distance from their owners (vehicles). These VM migration techniques reduce latencies and downtime when the VM resume at the next MEC infrastructure. For instance, [PERSON] et al. proposed a VM migration strategy based on Multi-Path TCP (MPTCP) approach to keep the VM hosts using the same Internet Protocol (IP) to follow the movements of the users [28]. Establishing a MPTCP [29] is a method for performing a single Internet protocol between communication nodes in wireless communication. The authors of [28] used the MPTCP transport layer to enable the connection to remain established after a Mobile Device (MD) changes its IP address during handover. MPTCP reduces significantly the delay. However, MPTCP technology cannot solve the issue of a single IP address except advanced VM techniques such as live migration of the dedicated VM or Markov decision process-based service migration [30].