and synchronization models, protocols and topology (see Figure 6.2.12); however, as of now there is no well-defined approach for implementing this in a virtualized environment. 6.2.7.3 RAN Scaling with Workload 5G can be deployed in a wide variety of configurations, for example, in spectrum ranging from tens of MHz to hundreds of MHz, with number of antennae ranging from two to hun- dreds, in local (i.e. edge) sites deployments or cloud/data centers, etc. This requires RAN platforms to be sufficiently flexible and scalable. Commercially available CoTS servers have a finite number of physical cores (e.g. <25 physical cores per socket is typical) - if multi-socket and core count is increased, CPU frequency starts going down. A virtualized gNB-DU should scale with hardware - most pro- cessing can be parallel - for example, processing different cells can go to different servers. While this works well for parallel workloads, it is not clear how to scale the edge hardware, central site remote site Additional noise SyncE+PTP Local or remote T-TSC* filtering to meet master PRTC-traceable time source PTP/SyncE path Figure 6.2.12 Timing and synchronization (Source: Reproduced by permission of © O-RAN). 6.2 Virtualization especially for the gNB-DU, which has strict real-time requirements, where the latency does not allow scaling it to off-chip to multiple servers. Furthermore, the accelerators used for the L1 physical layer should scale as well; how- ever, it may not be practical to put accelerators in all servers. Additionally, virtualization of accelerators with stringent requirements on latency and bandwidth is not well supported in CoTS platforms. In many cases, it is possible to scale the gNB-DU within a server only with some fixed mapping of radios to servers. Another issue that has not been fully studied yet is live migration of the gNB-DU VNFs, which can be used for scalability as well as failure protection. At the gNB-CU, RAN scal- ing with workload is more feasible since the real-time requirements are less stringe