), and Radio Resource Control (RRC) layers are implemented. Based on the use case and availability of transport bandwidth and latency, these nodes could be in a separate location or at the same location. Some or all of them may be virtualized and mapped to different components of a virtualized NG-RAN platform, as we describe below. Figure 6.2.8 shows a representative gNB-DU container platform, which is assumed to be connected to RU, CU-CP, and CU-UP network nodes. The virtualized gNB-DU (vDU) CNF runs the high-PHY, MAC, RLC, and scheduler portions of the protocol stack in software. The operations, administration and management (OAM) interface is used for configuration and reporting/logging and connects to the network management system of the operator. Accelerators are used as required mostly for physical layer offload for functions such as forward error correction coding (FEC), which are compute intensive and latency sensitive. The vDU microservice architecture needs to be designed carefully owing to strict timing requirements. The splitting of vDU functions into multiple microservices may impact the latency budget for features such as Hybrid ARQ (HARQ) and needs to be evaluated carefully based on processing power and the timing budget available. A tim- ing/sync module (not shown) is also required to manage timing and synchronize the RU with the vDU. The timing/sync could come from GPS or from another timing/master clock that is transported to the vDU via IEEE 1588 (Precision Time Protocol [PTP]). PTP is also used to distribute timing from the vDU to all the RUs connected to the Figure 6.2.9 shows a representative gNB-CU container platform, which is connected to a DU, user-plane function (UPF), and access and mobility management function (AMF). The CU container platform involves the control plane (CP) and user plane (UP) functions, which are separated. These may be on the same server or may be on different server loca- tions via the E1 interface. The need for accelerators is reduced compared with the gNB-DU since