ner bypassing the kernel. One such example is the Multus plugin for the K8S framework. Since there is a large range of deployment types for RAN with varying acceleration requirements, there needs to be a way to provide acceleration in a scalable manner. Accelerators typically operate in poll mode (as opposed to interrupt-driven software) and some of them need to respond in ten to hundreds of microseconds. The usage of multiple accelerators by multiple VNF instances in a single platform creates additional challenges, for example, in terms of accelerator sharing. Multiple accelerator models may need to be supported in the virtualized platform such as inline or lookaside models (see Figure 6.2.11). As of now, there is no uniform approach to the usage of hardware accelerators in virtualized RAN. 6 Enabling Technologies Container 1 Container 2 VM VM VM VM VM VM CPU Interface CPU Interface Accelerator Look-aside Accelerator Ethernet MAC Accelerator Network Interface In-line (eg. i/pNIC) Look-Aside Figure 6.2.11 Accelerator models for containers. 6.2.7.2 Timing and Synchronization Most current (e.g. cloud and enterprise) workloads running on virtualized platform servers do not have as stringent real-time requirements as the RAN workloads. In order to for example run parts of the gNB-DU in a cloud infrastructure, accurate timing needs to be transported in the network. This is typically achieved via the PTP, which distributes tim- ing from a centralized location to all radios where the timing accuracy of 100 ns or better is required. PTP provides frequency, phase, and timing accuracy. However, many traditional Network Interface Cards (NICs) do not support the hardware time stamping needed for PTP. In addition, many operators may also require synchronous Ethernet (SyncE) as a backup timing solution for holdover and to enable faster locking, which is again not very prevalent in data center solutions. The PTP accuracy can also vary on software-based implementa- tions based on workload. The O-RAN specifications define timing 