 these applications have less stringent real-time requirements. With the exception of encryption accelerators, it may be possible to implement a gNB-CU completely in software. It is also more feasible to break the CU into multiple microservices due to lower real-time constraints, enabling better scaling for the CU. H-PHY MAC/RLC Scheduler OS Kernel Orchestrator 11111 infrastructure 11111 CU-CP CU-UP Figure 6.2.8 DU container platform. 6 Enabling Technologies CU-CP CU-CP N2, N3 OS Kernel Orchestrator infrastructure Figure 6.2.9 CU container platform (assumes CU-CP and UP are co-located). 6.2.6.2 Standardization of Orchestration and Cloudification in O-RAN As we described in Chapter 4, one of the advantages of split NG-RAN architectures is that it makes it easier to deploy a gNB in a virtualized environment. For example, splitting gNB-DU functionality allows one to virtualize that network node as most of its functionality can be implemented in software. Having said that, while certain provisions have been made to enable that (e.g. a capability to add and remove SCTP associations on an NG-RAN control-plane interface to allow addition and removal of network and computational resources), 3GPP specifications do not explicitly define how NG-RAN can be virtualized. Given the complexities of RAN virtualization and the need for inter-vendor interoper- ability, O-RAN Alliance has taken substantial efforts to provide a standardized model for cloudification of the RAN, and the orchestration of the resulting cloudified RAN, where: 1. Software and hardware are decoupled, which allows: Multiple vendors of hardware platforms with CPU (e.g. x86, ARM), accelerators (e.g., FPGA, digital signal processor [DSP]/GPU), and abstraction layers which support the software providing RAN functionality. A given hardware platform can support RAN software (e.g. for DU, CU, RU) from multiple vendors. The mapping of software functions to hardware platforms can be done in multiple ways, and O-RAN is defining scenarios of interest, use cases within 