# Software-Defined Vehicular Cloud Networks: Architecture, Applications and Virtual Machine Migration
## 1 Introduction  
Vehicular applications include safety, geo-advertising, and entertainment applications to make the vehicle's passengers journey more enjoyable. The European Transport and Telecommunication Information (ETSI) defines Cooperative-Intelligent Transport System (C-ITS) applications that provide emergency (safety) messages and reduce drastically car accidents [1]. In fact, C-ITS applications include, for instance, in-vehicle speed limit or emergency collision. Messages from C-ITS applications can be generated from different use cases such as an accident and are generally only one or two hops. In addition, geo-advertising constitutes a set of applications for advertising to vehicles within a specific zone area and direction. Furthermore, entertainment-based vehicular applications are mainly cloud-based applications which improve safety, comfort, and entertainment through the development of technology allowing for Internet equipped vehicles referred to as the Internet ofVehicles (IoV) [2]. IoV offers passengers the ability to access cloud resources anytime and pay as they use them. Therefore, the cloud computing helps to continuously perform other activities such as editing meeting presentation files or attending an important team meeting as long as the vehicle is connected to the Internet. However, the high mobility and frequent handover from serving Road Side Units (RSUs) increase network overload due to the number of re-connection requests and insufficient vehicle computing resources. Moreover, the issue of backhaul latency affects Quality of service (QoS) since many cloud-based vehicular applications are bandwidth-hungry. Thus, cloud computing provides considerable resources to enable cloud-based applications including IoV applications. The Vehicular Cloud (VC) architecture [3; 4] is in the progress of merging with the IoV as a fundamental platform for the Intelligent Transportation System (ITS). The cloud architecture for vehicular networks consists of three interacting layers: VC, RSU cloud, and central cloud [4]. Furthermore, the components of central and RSU cloud are described as a highly virtualized platform that provides the computation, storage, and network resources. In addition, Edge Computing (EC) is an extension of a central cloud to provide less delay and better computation performance [5]. An example of a similar system to EC, the cloudlet, is defined as cloud computing in s box [6]. Cloudlets are deployed at the RSU as a small-scale operational site that offers cloud services to the vehicles in the immediate vicinity of the cloudlets. These cloud services are generally initiated from central/edge cloud infrastructures and migrated to the vehicles through mobility management protocols. However, the dynamic topology of the vehicular networks and high mobility diminish data dissemination, which leads to the implementation of complex routing protocols. Thus, complex routing protocols limit the implementation of new vehicular applications, which would allow everything around the vehicle to communicate with the vehicles. Therefore, emergent network technologies were recently proposed to address existing issues in vehicular networks. Presently, the Software-Defined Network (SDN) is among the emergent network technologies for Vehicular Ad-hoc NETworks (VANETs) [7] and has drawn much attention from many academic researchers. The SDN is a growing networking concept in VANETs that brings better performance through Software-Defined (SD) Vehicular Network (SDVN). In SDVN, the vehicles and radio access at the RSU are considered as SDN devices (data plane). The SDN controller generates and maintains a database that includes network-wide knowledge such as network topology [8; 9]. In addition, the SDN concept together with EC is proposed as a prominent solution to existing challenges in vehicular networks. Both hierarchical and centralized SDVN architectures improve rapid packet delivery, low latency, and overhead communication [10; 11; 12; 13].