## 6 Challenges and Solutions for Next Generation of SDN
Furthermore, the separate configuration of both types of devices and accessing the configuration correctness and statistical decision of the controller placement near devices are also next challenges. New SDN solutions supporting multi-layer, multi-vendor operations, ideally with a level of legacy support through open APIs, should be designed to help network providers start adjusting their network to the SDN architecture. Moreover, SDN solutions ideally need to be developed using a cloud-native software base to leverage elastically scalable cloud resources (CPU, memory, and connectivity). * Government policy adaption: Governments will likely introduce in the future further restrictions for network providers in terms of carbon emission and privacy protection, which also need to be addressed. As an example of IoV, especially in the fog-based 6G networks, is that a vehicle may handover through several small cells that may be untrusted or even compromised, and it is a serious challenge. Here, one of the solutions is preventing linking the vehicle identity with the information of its owner [72]. * Meeting slicing requirement for 6G: As regards 6G, slicing can be considered to be one of the important enabling technologies. As discussed in this paper, network slicing needs to be upgraded for 6G. NFV and SDN as enabler technologies for network slicing should be upgraded in parallel to network slicing upgrade. The controller of NFV and SDN should be upgraded to leverage cognitive services. This enables the scheduling of the network and network functions being integrated into a cognitive service architecture. Moreover, the virtualization of NFV and SDN should be realized with finer granularity to guarantee flexible resource scheduling. * Resilience and fault tolerance of the control plane: The most vulnerable aspect of SDN architectures is the control plane, in particular the SDN controller, as the network is at the behest of the SDN controller, which must be protected. The research efforts on resiliency support for SDN (e.g., [PERSON] et al. in [73]) categorized them into different planes of the SDN architecture. The most classical solution to provide fault tolerance is redundancy. In SDN, the authors foresaw three potential usages of redundancy: (i) protecting the SDN controller from failures, (ii) protecting the forwarding devices and communication links from link disruption, and lastly (iii) protecting the SDN applications from misconfigurations. There are replication mechanisms ([PERSON] et al. in [74]) to protect the control plane from faults and ensure the availability of the SDN controller. [PERSON] et al. in [75] proposed a fast failure recovery technique for centralized SDN infrastructures, based on a traffic restoration scheme that allows the SDN controller to circumvent faults on certain links at the data plane by proactively sending a set of protection paths. Other works focus on the controller placement, which is tightly linked to ensure SDN controller availability. For instance, [PERSON] et al. in [76] demonstrated that the latency is reduced when the number of controllers is augmented. [PERSON] et al. in [77] combined the placement of the controller with path diversity and recovery mechanisms to ensure the fault tolerance properties in SDN. [PERSON] et al. in [78] studied the controller placement problem from a reliability perspective. The authors provided metrics based on the probability that at least an operational path is available and solved the controller placement problem by imposing as the constraint these path availability metrics. * Geographically scalability and reliability: The fact that the control plane is logically centralized and often based on the SDN single controller often can cause a single point control channel failure. Nevertheless, the scalability of SDN can be improved by using multi-controller architectures. Multiple SDN controllers can be connected in a flat or hierarchical manner via west-east-bound APIs [9].