ning them to run on a particular set of resources. The VM approach, which has been used by most virtualized platforms initially, is advan- tageous in that it does not require any changes in the operating system. Furthermore, it allows the running of different operating systems (e.g. Linux and Windows) on the same hardware. The disadvantage of this approach is that each VM runs both a full copy of an operating system (which can be different than that of the host) and a virtual copy of all the hardware that the operating system expects. This leads to significant overheads in terms of RAM and CPU, but provides extreme flexibility to the cloud provider. As virtualization has been maturing and performance has become more of a priority, the container approach has gained popularity. A container is a self-contained piece of software that packages everything required to run the application. A container image includes the application code, libraries and other dependencies, additional processes (if needed), con- figuration, etc. In contrast to a VM, a container does not include a full copy of an operating system. Therefore, containers are more suitable to RAN applications that have strict tim- ing requirements (especially in the case of gNB-distributed unit [DU]) and very conscious of memory, CPU, and storage load in order to optimize the cost of ownership and power consumption. This is different compared with the VM approach of using a hierarchy of multiple levels of operating systems, which can cause significant variation in the real-time processing at the gNB-DU and increased use of resources. In contrast, with the container approach there is a single operating system that is enhanced to support containers and provides essentially the same level of resource isolation to an application as in the VM approach, but without the overhead of running a whole operating system (for each application) to achieve that. This is particularly suitable for RAN applications in order to enable better real-time support as well as reduced me