# Software-Defined Vehicular Cloud Networks: Architecture, Applications and Virtual Machine Migration
## 3 The Architecture of Software-Defined Vehicular Cloud
### The Components of SDVC  
The architecture for deploying cloud-based vehicular network based on software-defined networking, MEC cloud, and central cloud computing is described in [21; 22]. Cloud computing and SDN are intended to work together by leveraging the use of a VM to improve connectivity and increase bandwidth. In fact, the concept of using SDN offers several imperative networking paradigms. SDN provides on-demand network programmable functions and adds meaningful scalability for deploying cloud-based applications on vehicles. SDVC supports the V2V communication through the concept of sharing the computing resources available on both cloud and MEC according to the resource management strategies. SDVC allows cloud vehicles to share three types of resource: computing, storage, and bandwidth resources.  
Figure 5 shows SDVC architecture where vehicles are considered as SDN devices that are equipped with OpenFlow-enable software switches such as Open vSwitch [21]. The SDVC architecture in [21] supposes that SDN devices support virtualization technology and can host virtualization infrastructure (VI). VI will be able to install a cloud-based vehicular service on the vehicle. Here, a cloud-based application is considered as a service. When a vehicle requests the cloud-based vehicular service, the cloud instantiates a VM cluster and the MEC micro-data center located at the proximity of the vehicle loads the VM-Base. The VM cluster refers to a VI established in the central cloud [23]. The term MEC micro-data center means a batch of MEC servers that include virtualization infrastructure which provides computation, storage, and network resources for the cloud/edge-based vehicular applications. A dedicated VM (a customized VM-overlay) will be instantiated in the vehicle. The dedicated VM aims to provide computation resources of the cloud-based vehicular service. In the case the vehicle moves far away from the current MEC micro data center, the dedicated VM will be migrated to the nearest MEC micro-data center. This MEC micro-data center continuously offers that cloud-based  
vehicular service [4]. In addition, evolved Node Base (eNB) co-locates with RSUs, and other MEC equipment could host edge servers and radio access network computing in a cloud way. In fact, MEC computing is performed on a distributed topology [18] to deliver cloud-based vehicular services to vehicles. Certainly, MEC network resources could also be SDN devices or host SDN controllers. The VMs at the vehicle and MEC are named VM-overlay ( dedicated VM) and VM-base, respectively, as shown in Figure 3. A VM-overlay migrates and combines with the VM-Base hosted at other nearby MEC micro-data centers when it is time to move out of the communication range of the current MEC micro-data center. In addition, the VM cluster from the cloud resumes the VM-Base at the MEC micro-data center only when the vehicle cannot continue the trip due to an accident or any other barrier towards the destination direction.  
Fault tolerance of one SDN controller requires a hierarchical design with SDN-enabled core network, SDN-enabled computation resources, and SDN-enabled access network [34; 35]. Thus, in [21], the SDN controller is responsible for VM migration. The load balancing and routing decisions are abstracted through a central entity, referred to as the VC controller [22]. As shown on Figure 5, the SDN OpenFlow controller maintains a consistent view of the predicted trajectory to the destination. The SDN infrastructure communication controller preserves different VC established and allows VM services to resume at the next RSUs [22]. Allocation of virtualized resources pool and fault tolerance of a central controller influence the design of the SDVC with more than one central SDN controller. The active VM controller is responsible for managing the migration and replication of VM-overlay and VM-Base [21]. Here the management of VM includes replication, migration, and customization of a cloud-based vehicular service deployed as a dedicated VM.