Telecom networks can use automation to push software upgrades into the field without the need for human intervention.

Just as manufacturing has moved from an entirely manual process to one that’s highly automated, so too is automation making inroads to telecom and datacom networks. Automating operations such as software updates no longer disrupt the network. Automation is becoming the key to scaling, testing, and allocating software and underlying hardware resources.

While many network functions can benefit from automation (Figure 1), let’s focus on automating updates to the Radio Access Network (RAN). We will first discuss the automation enablers, then steps where RAN automation can happen. Finally, we will look at each enabler.

Automation enablers such as Zero Touch Provisioning (ZTP), Continuous Integration/Continuous Development (CI/CD) and Artificial Intelligence/Machine Learning (AI/ML) are important enablers for software-based cloud-native networks across all stages of network deployment (Figure 1).

Network Automation in Steps
The stages of the network deployment to automate are as follows:

1. Cloudification is the foundation for the initial stage of setting up the network environment. RAN architecture needs to be cloud native for automation to take place. Cloudification through cloud-native functions (containers and microservices) is the foundation of Open RAN and will help with effective automation.

To optimize performance, in the enterprise example, software implementation went from monolithic, self-contained applications running on dedicated servers to a new model built on webscale models. It eventually evolved to microservices. A microservice is decomposition of an application into separate parts, each running in a lightweight “container” environment such as Docker, rkt, or Linux LXD. Virtual machines (VMs) – burdened with a whole OS – are simply too bulky to host microservices. By deconstructing a RAN service into microservices, you can address any performance issue by spinning up multiple instances of the RAN microservice that might create a performance issue. Figure 2 shows how virtualization has evolved.

Different RAN function components can be implemented as separate microservices rather than as one monolithic VM. Thus, they can scale up to optimize the RAN function’s performance. 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 service level agreements (SLAs). A microservices architecture also lets mobile operators push out RAN upgrades to as many sites as needed, as testing a microservice involves few test cases.

In addition, a microservices architecture supports an agile DevOps model. DevOps combines software development (Dev) and information-technology operations (Ops). Its goal is to shorten the systems development lifecycle and provide continuous delivery with high software quality. The DevOps movement, which inspired large, enterprise organizations with agile practices, let developers make quick changes. It was, however, difficult to get full benefit because their legacy development process could not support short software development delivery cycles and frequent production releases. The DevOps movement developed the CI/CD methodology to release software into production quickly, reliably, and repeatably. Figure 3 shows the software distribution process.

DevOps processes let mobile operators push out RAN upgrades without taking down the entire site or sites, as testing a microservice involves a very few test cases. Testing an entire monolithic (though virtualized) application takes many days.

A RAN function cannot be automated unless it’s containerized and based on microservices. With that in place, the network deployment automation can move to the next step.

2. Bringing up a radio site, which includes commissioning and provisioning services. ZTP is best utilized at this stage. With ZTP, a mobile operator need not perform any manual tasks to configure the cell sites.

3. Once sites are configured, you can apply CI/CD to automate updates and reduce onsite or data center manual labor. By reducing or eliminating the need to send engineers on-site, mobile operators can reduce costs. CI/CD is a key enabler for automating network testing and upgrades.

4. Fourth is the optimization stage, which involves intelligent automated optimization of the network, providing services to the subscribers. AI/ML plays an important role here. Open RAN networks natively include an AI/ML framework into the RAN architecture with Near-RT RIC & Non-RT RAN Intelligence Controller Functions. The RIC hosts microservices-based applications called xApps for Near-RT RIC and rApps for Non-Real-time RIC. With the help of rApps and xApps, Open RAN integrates AI/ML based decision making into the network.

AI models fall into two categories: supervised and unsupervised learning. Being real-time, cellular networks prefer unsupervised learner models to eliminate continuous model and training.

The Near RT RIC should include AI as an xAPP responsible for predicting, preventing, and mitigating situations (i.e. handover) that affect customer experience. AI needs to be in the near-real-time RIC because it will drive time-sensitive decisions for network performance. All xAPPs should use unsupervised learning mode.

AI software will use algorithms created by ML running as an rAPP in the non-real time RIC. Any algorithms and training can be built in non-real time. The reinforcement of those decisions needs to happen in real-time by AI. An ML rAPP from the non-real-time RIC will help the AI xAPP in the real-time RIC to recognize traffic patterns and abnormalities. The rAPP can then adjust network health, provisioning the appropriate RAN resources for optimal subscriber experience.

AI/ML algorithms will be responsible for:

• forecasting parameters;
• detecting anomalies;
• predicting failures;
• projecting heat maps;
• classifying components into groups.

AI/ML will enable proactive action and the ability to accurately predict the future. Based on prediction, the network can take preventative action to avoid future similar situations.

Automation enablers
ZTP ensures that sites are configured quickly and automatically. Such automation reduces or eliminates the need to send engineers on-site. ZTP will be critical for dense 5G deployments when network operators need to configure hundreds of sites.

Once sites are configured, CI/CD can automate updates and reduce manual labor on-site or in the data center through automated software upgrade distribution. IT and enterprise industries have used CI/CD frameworks for years and how it’s coming to the telecom sector.

There are two important factors to keep in mind when adopting CI/CD for Open RAN. The first factor is the disaggregation itself, as hardware and software components are coming from different vendors. The second consideration is around physical components such as servers and radios in the RAN.

When applying CI/CD models to RAN upgrades, they need to holistically feed into the overall CI/CD strategy across all network segments — RAN, transport, and core. So, in addition to creating a cohesive RAN CI/CD strategy, a mobile operator needs to create an overall network CI/CD strategy.

DevOps and CI/CD enable fast software changes. The updates delivered to sites can be monitored to evaluate how they impact end users, and whether they are achieving the pre-determined business goals.

The integration, software upgrades, and lifecycle management of these disaggregated software components running on COTS hardware enables a new testing model. Testing software from the different groups within an organization need not take place in silos, but rather under an overall CI/CD umbrella. Thus, CI/CD can reduce development time from hours to minutes, eliminating most of the manual tasks.

This approach will help with creating CI/CD blueprints for future deployments resulting in:

A more interconnected ecosystem of Open RAN vendors. By implementing CI/CD, mobile operators embrace greater collaboration among different ecosystem members. Such an ecosystem supports multi-vendor, cloud-native network function onboarding and lifecycle management. This approach minimizes risk through frequent delivery of new features and new optimizations while increasing efficiency via automation that leads to the faster introduction of new services. These open automation tools enable access to vendor-neutral sets of applications.

The combined power of containers and CI/CD. Agile DevOps simplifies automation by providing validated stack templates for containers to host microservices. These upgrades will be automated with CI/CD. The combination of software being pushed via CI/CD to containers allows MNOs to easily define their own architecture and make Open RAN easier and more cost-effective to deploy and maintain. The main benefit will be in sites running as a service with software updates being pushed to hundreds of sites automatically instead of scheduling them for upgrades when a crew is available to go on site and upgrade manually.

CI/CD can also automate testing and upgrades. Implementing a CI/CD model in the telecoms industry helps to migrate the testing, integration, software release, and actual software deployment of the RAN from manual fieldwork to automated and remote deployment. Manual on-site upgrades are subject to mistakes and the maintenance window is short. With automation, mistakes are eliminated, and the time window is expanded.

If there is an issue with infrastructure, automation will enable moving the application to another data center or the edge, depending on the application. Rollbacks for application or container failing are automated, so the latest stable version is always available, minimizing downtime and any impact to the end-user.

A clear automation strategy, utilizing the RIC and defined processes across CI/CD, ZTP, AI/ML, and Analytics will help mobile operators to move into a fully automated RAN world, which is key when RAN components come from different vendors as with Open RAN. (See next page, “What is a RIC?)

The scope of work is the same as with legacy RAN; the difference is the number of suppliers that will be a part of the Open RAN ecosystem. Automation of configuration with ZTP and automation of ongoing maintenance with CI/CD, AI/ ML will help mobile operators to realize the promise of Open RAN, avoiding vendor lock-in, while Increasing efficiency, providing better resource utilization, and driving down overall total cost of ownership.