The DevOps movement inspired large, enterprise organizations with agile practices to allow developers to make quick changes, but it was very difficult to get the full benefits, as their legacy development process was not designed for supporting short software development delivery cycles and frequent production releases. In order to release software into production quickly but reliably and - most importantly - repeatably, the DevOps movement developed the Continuous Integration/Continuous Delivery (CI/CD) methodology. Jez Humble and David Farley covered these principles and practices in their book “Continuous Delivery: Reliable Software Releases through Build.” Cloud-native data center technology, adopted by enterprises in 2000, offers the flexibility that paves the path forward to realize new services for mobile operators, but data center technologies introduce a level of operational complexity in the RAN. Implementation of this data center inspired approach is the next step in evolving legacy RAN to fully automated Open RAN.
VNFs and containers
VNFs are software versions of network services that used to reside on dedicated network appliances. Functions like vEPCs have been deployed as Virtual Machines (VMs) on COTS infrastructure for over a decade now. VMs are an abstraction of physical hardware, turning one server into many servers. The hypervisor allows multiple VMs (i.e. EPC, IMS) to run on a single machine. Each VM includes a full copy of an operating system, making them slow to boot; it also includes one or more apps, necessary binaries and libraries - taking up tens of GBs of storage.
The fact that something like vEPC is implemented as a monolithic software application on top of a VM may explain some of the performance issues. The RAN is the most transaction-intensive and time-sensitive area of the network and any performance issues will create havoc on the user experience. This is why Open RAN, which consists of many different components from different vendors, needs to adapt to a data center approach to develop, run and optimize software.
But Open RAN brings new problems, such as time and complexity of integrations and software upgrades between different vendors. The actual development of a suite of interoperability tests amongst Open RAN vendors is the main challenge. A special set of tests are needed to standardize the certification of software, whether it is hosted on cloud and/or bare-metal infrastructure. A second consideration is the diversity of RAN splits that can be implemented using different Open RAN vendors as a testing process, and cases for Split 7 will be different than for Split 8.
Current CI/CD frameworks have typically been used for IT and enterprise apps. As RAN has hardware components like radios that will remain physical, the suite of tests for CI/CD needs to take that into consideration, as the hardware and software in Open RAN will be coming from different vendors. The integration, software upgrades, and the lifecycle management of many vendors will be challenging. Vendors will need to adapt to a new testing model - wherein they are not testing their own products in silos, but rather under an overall CI/CD umbrella. This is especially important in test environments before going into field deployments. This approach will help with creating CI/CD blueprints for future deployments.
Microservices architecture
To optimize performance, in the enterprise example, software implementation went from monolithic, self-contained applications running on dedicated servers to a new model that was built on Webscale models. It eventually evolved to microservices. A microservice is a decomposition of an application into a multitude of separate parts, each one of them running in a lightweight “container”-like environment - for example, Docker or rkt or Linux LXD. VMs (with a whole OS to boot) are simply too heavyweight to host microservices. By deconstructing a RAN service into microservices, it’s easy to address any performance issue by spinning up multiple instances of the RAN microservice that might be creating a performance issue.
Open RAN software doesn’t have to be just *one* big monolithic service like a vEPC, as different RAN function components can be implemented as separate microservices and can be scaled up in any way required to optimize the RAN function’s performance.
A microservices architecture also has several other very important benefits. One of them is the ability to continuously innovate by embracing an agile DevOps model. A mobile operator can push out any RAN upgrades without taking down the entire site or sites, as testing a microservice involves very few test cases; testing an entire monolithic (though virtualized) application takes many days of testing.
Source: Parallel Wireless
Implementing the following four data center principles will help make Open RAN be responsive and high-performing. Principle 1 ensures that each RAN function component is deployed as a microservice. Principle 2 advocates for a very responsive container environment that should be used and not legacy-based infrastructure. Principle 3 promotes a DevOps method to be adopted for the software to be delivered frequently. And lastly, Principle 4 highlights that using CI/CD is key for automation: 1000 sites can be upgraded whenever desired.
Each microservice can be deployed, upgraded, scaled, and restarted independently of other microservices in the RAN application, using an automated system, enabling frequent updates to live applications without impacting end-user experience. Under the hood, a microservice is hosted in a container and exposing APIs to access the service it offers. A particular microservice runs in a container. Then Kubernetes orchestrates the dynamic instantiation of several of those containers in pods, according to performance, resilience and security requirements.
Source: Parallel Wireless
A container image is a lightweight, standalone, executable package of a piece of software that includes everything needed to run it: code, runtime, system tools, system libraries, environment. These capabilities are key for the ever-changing RAN environment. Multiple containers can run on the same machine and share the OS kernel with other containers. Containers take up less space than VMs (container images are typically tens of MBs in size), and containers can start almost instantly. Containers offer both efficiency and speed compared with standard virtual machines. Using operating system level virtualization, a single OS instance is dynamically divided among one or more isolated containers, each with a unique writable file system and resource quota.
In summary, as the Open RAN ecosystem evolves, the number of software upgrades will increase, and so will the importance of including these upgrades in the CI/CD environment that is specifically developed for Open RAN across many hardware and software vendors.
Implementing a CI/CD model in the telecoms industry will help to migrate the testing, integration, software release and actual software deployment RAN from manual field work to automated and remote development and software deployment as a software push to hundreds of sites. Enabling testing, software upgrades, and maintenance to occur off‑site helps operators to test software in live networks and have the ability to rollback while providing hands-free support. It would have particular applications in rural areas where maintenance makes infrastructure upgrades cost-prohibitive and in urban areas where upgrades will help manage the quality of service.
