# Software-Defined Vehicular Cloud Networks: Architecture, Applications and Virtual Machine Migration
## 2 Background of Technologies behind SDVC
### Software-Defined Network and Its Concept for Vehicular Networks  
The basic logical structure of an SDN is shown in Figure 4. It consists of three planes: the application plane, the control plane, and the forwarding plane. The control plane includes an SDN controller cluster that is deployed as an independent device. The SDN controller communicates the control decisions to the forwarding plane (networking devices). Furthermore, the SDN controller also retrieves information from those network devices to make proper routing decisions. To enable communication with the forwarding devices, SDN uses protocols named SDN control protocol. The SDN control protocol is categorized in northbound and southbound protocols. The SDN controller interacts with the application plane using the northbound interface. The northbound protocols support application developers to manage the network through a program. Besides the northbound protocol, the southbound protocols enable communication from the control plane to the data plane. In addition,  
Figure 3: Dynamic VM synthesis approach to instantiate a VM for a cloud service at MEC cloud. network devices based on OpenFlow protocol [31] accept user-defined policies once installed to allow the routing algorithms to take place. The application plane communicates available actions by instructing new paths to the control plane. The control plane carries selected routing paths to update flow tables of data plane. Since the SDN puts the intelligence of the network into a central software-based control, programs and scripts that automatically react to expected and unexpected events can be built directly into the SDN controller. Communication between the control plane and forwarding plane in the SDN environment takes place through the SDN control protocol. In the SDN, because the control plane and forwarding plane are decoupled, a standard protocol with multivendor support was needed for communication between them. OpenFlow was developed for this purpose. OpenFlow was the first communication protocol that gives access to SDN controllers to program the rest of forwarding network devices [32]. OpenFlow maintains the flow table [31] on the device, which contains actions to be followed for each incoming packet [31]. The SDN controller can then use OpenFlow to program the forwarding plane of an OpenFlow-enabled switch by altering its flow table. Furthermore, the OpenFlow works in two modes to populate the flow tables: the reactive and proactive modes. The reactive mode is the default method of executing control signaling messages and assumes that OpenFlow does not have any prior knowledge of the control plane running on the network devices. In this mode, the first incoming packet of the network traffic received at any of the forwarding devices is forwarded to the SDN controller. Next, the SDN controller uses this information to generate new rules across the whole network. This creates the flow table on all subsequent forwarding devices in the path, and then forwards the network traffic according to new rules implemented in the Openflow switch of the forwarding devices. On the other hand, the proactive mode requires the SDN controller to be pre-configured with some default flow table values. In simple terms, the traffic flow is programmed preemptively as soon as the OpenFlow switch is rebooting. In addition, a secure channel, such as Secure Socket Layer (SSL) or Transport Layer Security (TLS), is used by the OpenFlow protocol to secure the communication between the SDN controller and OpenFlow switches [31]. The SDN is an imperative technology to address existing challenges in vehicular networks. The control logic for existing networks is integrated into every underlying On-board Unit (OBU) [33] hardware equipped in vehicles. The configuration of new routing algorithms is notably difficult because nearly every in-vehicle communication interface needs to be set up separately. Therefore, the solution is to extend the existing VCC by integrating SDN technology [9].