SDVC security and privacy concerns have yet to be addressed. IEEE 1609.2 specifies the use of public key infrastructure (PKI) in traditional VANETs. The PKI employs public key and private key pairs. The PKI, on the other hand, cannot guarantee privacy because SDVC uses a different network architecture than VANETs. In order to improve security, Kim et al. in ^[31][62] proposed a security mechanism for SDVC that would satisfy fundamental security requirements such as authentication, message integrity, non-repudiation, confidentiality, and privacy. The SDVC proposed for security mechanism includes the control plane.

4.1.4. Serving Broker

VCC envisions a wide range of services. To support various QoS, responsive resource management solutions are required. In fact, dynamic resource management solutions involve RSUs. They act as event subscriber and publisher broker among the moving vehicles. The deployment of RSUs acting as broker should be maximized by effectively optimizing their placement. The physical factors to RSU placement are traffic patterns and mobility of moving vehicles. On the other hand, cyber factors are communication protocols and messaging.

4.1.5. IoV Network Measurement

Intelligent traffic management, dynamic information services, and intelligent vehicle control, among others, are part of the ITS services offered in VCC. However, the high mobility of RP vehicles affects resource sharing. Network disconnection and wireless bottlenecks in various geographical locations are reasons for issues. For ITS applications involving IoV, the validation of the IoV network measurement method is important because it characterizes its measurement performance for different controllers established in the control plane layer.

4.1.6. Distributing Software Updates

Vehicle manufacturers frequently need to perform software updates on vehicles. Software updates can be pushed out by the manufacturer to fix bugs requested by vehicle owners to improve functionality [13]. On-demand network programmability based on SDN and cloud computing is deployed for distributing software updates on vehicles. This SDVC architecture increases the flexibility of deploying software updates on vehicles. The SDN architecture leverages solutions for modeling vehicular networks as connectivity graphs that can be fed into the control plane.

4.2. Software-Defined Control Technique in SDVC

4.2.1. Use Virtual Network Functions

Wang et al. in ^[32][65] proposed an intelligent application based on VNF technique. The design involves different modules. They proposed a traffic identification module that uses deep neural networks (DNNs) and multi-grained cascade forest (gcForest) to distinguish service behaviors. The trained model fits the QoS for various VC services. The proposed ESDVC includes VNF layers. It also implements a scheduler function that selects which layer to host the next VNF for the incoming packets in the proposed architecture.

4.2.2. Software-Defined Pseudonym System

A third-party entity is involved in SDVC management and operations. Therefore, privacy is one of the critical security issues in VCC. For instance, an anonymous vehicle-to-infrastructure (V2I) cloud management system may request vehicles’ identity and location privacy data. To enhance security in SDVC, NFV technology has been investigated. NFV in SDVC provides NFs that are customized to the security management system ^[33][66]. The formation of VNFs is hierarchically managed on different entities from the vehicle to the application plane in the cloud. The distributed pseudonym pools are scheduled and elastically managed through a software-defined pseudonym system ^[34][67]. The software-defined pseudonym system exploits SDN by significantly improving the flexibility and programmability of pseudonym functions in SDVC. The distributed pseudonym pools are NFs linked to provide end-to-end security service. They are generally scheduled and elastically delivered on demand wherever numerous anonymous V2I access breaches the privacy in SDVC.

4.2.3. Traffic and Connectivity Management

The V2X traffic and connectivity services in VCC are supported through vehicle-to-vehicle (V2V) and vehicle-to-infrastructure (V2I) communication. However, allocating available resources to V2X users weakens the computation of V2X collaborative tasks because vehicles often fail to fetch updated road traffic conditions in order to reduce time to consolidate the pool of resources required ^[35][69]. During heavily congested situations, both drivers and passengers may become bored and connect their devices to access entertainment programs offered by the city cloud, such as games, video, social media, and so on. While accessing those services, hazardous driving would cause road accidents. Consequently, frequent access to cloud-based services increased network traffic in the closest RSU nodes.

4.2.4. Network Reconfiguration

Changes to VC service hosts and data flows degrade not only offered services but also increase costs to VC service providers. A highly adaptive SDN controller can address the above-mentioned challenges. Important techniques in SDVC have been proposed, such as RSU cloud resource management (CRM), which is used to address the issue of network failure and network configuration to effectively update the topology of SDVC. The RSU cloud resource management (CRM) model reduces reconfiguration overhead, service deployment costs, and infrastructure routing delays. Inconsistent configuration updates produce incorrect network behaviors. On the other hand, long reconfiguration times between current and target configurations may degrade undesired network performance ^[36][71]. In order to reduce network reconfiguration time, the CRM uses consistent updates between current and target configurations through SDN technology in the proposed architecture. The deep programmability of SDN ^[37][72] involves the SDN RSU cloud framework to dynamically reconfigure network hosting services and their data forwarding information in order to meet the needs of basic shared mobility applications in vehicles.

4.3. Data Plane for SDVC

VC architecture includes an application unit (AU) deployed inside vehicles to facilitate routing and communication functions. Therefore, the research dimension of VC communication caused research to mainly focus on designing VC architectures that handle efficiently network traffic with higher QoS.

Data Plane for IoV PLATFORM

VC networks strive for higher data rates, seamless connectivity, scalability, security, and improved QoS. They are the key enablers for IoVs. Research in SDVC proposed various solutions on how to design a unified data plane such that communication is allowed between heterogeneous VC network architectures with multiple wireless interfaces (e.g., wireless access in vehicular environment (WAVE), long-range wireless fidelity (WiFi), and fourth generation/long-term evolution (4G/LTE)). The SDIoV architecture proposed in ^[38][73] includes a VC application and communication units to provide context-aware network connectivity. In IoVs, RSUs, connected vehicles, pedestrian devices, utilities, and charging points generate massive amounts of data that must be efficiently transmitted from one location to another. However, the volume of data brought new computing architectures to the edge where data are generated to reduce computation decisions on network management. To achieve that, the redesign of the data plane based on SDVC plays an important role. The data plane in the architecture presented in ^[39][74] is managed through the control plane. It collects the network’s dynamic nature, then updates network policies on a regular basis. In the case of electric vehicles with smart grids, the authors proposed a data plane that allows communication between charging stations and electric vehicles. Since those charging stations are geographically distributed across a large area, the SDN controller implements the recommended network policy to update the driving path. Virtual private mobile networks (VPMN) have been proposed in SDVC. This technique enhanced stable connectivity when the vehicle moves from one RSU to another [1]. By leveraging the SDN paradigm, an SDVC architecture based on VANET, cloudlet unit, and the VPMNs dynamically creates private, resource-isolated, end-to-end mobile networks. The proposed architecture solves the patch selection and channel selection issue in delivering IoV applications. The SDN controller in that architecture allows the establishment of a global view of the network. In turn, the routing rules applied to any closest cloudlet as RSU improves the overall network management.

5. Lessons Learned and Open Challenges

5.1. More Promising Techniques in VC Network Slicing

If VC network slicing and VCC are profitably integrated, they can offer great implementation of innovative V2X applications ^[20][40][21,75]. There are still many areas to be explored to provide intelligent VC applications and allow access to network third party suppliers or developers with new business opportunities. For example, with more SD techniques designed in emerged cloud-native architectures, VC network slicing would reduce the network latency computation cost observed in VCC. Storage and computing resources at the network edge still challenge VCC applications. Edge computing techniques such as edge caching and intelligent edge computing-based AI in MEC are foreseen to complement the cloud framework services in SDVC to form ESDVC. Furthermore, a cloud-native baseband base unit (BBU) server demands softwarization of its functions to run as logical VNFs such that a separate VC network slicing would fully support different requirements in implementing VCC applications at the network edge. By leveraging a cloud-native approach, the reconfiguration on demand of VC network slicing would take less effort and cost. Therefore, the VC network slicing services would involve the implementation of virtualized radio access network(RAN) (vRAN) services (with NFV) together with MEC applications to enable advanced IoV applications (e.g., autonomous driving, mapping, high-density platooning) that require low end-to-end latency. 

5.2. Open Challenges and Future Research Directions

5.2.1. Improvement of Key Performance Metrics

For VC network slicing service for a specific VC task, there are usually a series of VC control planes that can accomplish the VC task. However, it is difficult for network service providers to choose the right NFV for each VC network slicing service. Due to the uncertain characteristics of VC networks, commonly used standard performance indicators (such as slice runtime operations as well as slice life-cycle operations) cannot reflect the runtime performance of VC network slicing in the VCC. For VC slicing services, besides network slice availability, the end-to-end latency, application-specific performance, and resource elasticity are also key indicators.

5.2.2. Generalization of VC Network Slicing Controller

Currently, communication between the control plane and forwarding plane in VC network slicing takes place through the SDN control protocol, but there is no generalized solution for the VC network slicing controller for a wide range of cooperative VC applications. Furthermore, in order to build intelligent VC network slicing and support VC applications, not only NFV but also the possibility of co-locating the NFV and MEC techniques (edge caching), quality of service, and VC provisioning as a result of the VC virtualization software implementations should be explored. For instance, applying deep reinforcement learning (DRL) to the VC network slicing controller would enhance real-time resource management for SDVC.

5.2.3. Hybrid NFs for VC Network Slicing Reconfiguration

Coordination issues with respect to NFs on VCC deployment, VNFs, MEC running on BBU servers at BSs or radio access points along the RSU should be thought over. These customized VC network slicing are often used independently to enable vehicular–edge–fog–cloud collaboration. Diversified service requirements will impose one network slicing infrastructure to provide low-security, low-bandwidth services, while another slice can provide high-security, high-reliability services (such as for URLLC). VC network slicing customization, such as cloud-native architecture based on 5G and MEC may impose running on the network edge sides, but because of sufficient computation resources, the cloud will store permanent information data or other metadata information related to VC network slicing policies.