YOU ARE AT:FundamentalsOpen RAN automation 101. Part 2: Network components enabling automation (Reader Forum)

Open RAN automation 101. Part 2: Network components enabling automation (Reader Forum)

Operators are looking for cost reduction in both CAPEX and OPEX — and RAN is one of the biggest cost factors for operators. It is also one of the most challenging areas when introducing new features and services. Tackling the RAN will have the biggest impact on optimizing cost and delivering innovation with more agility in the solution. With traditional legacy solutions, however, operators must often wait several months to receive feedback on newer services which hinders innovation.

Figure 1. O-RAN Alliance Architecture. Source: O-RAN Alliance

RAN Intelligent Controller

The RAN Intelligent Controller (RIC) helps operators to optimize and launch new services by allowing them to make the most of network resources. It also helps operators to ease network congestion. The RAN Intelligent Controller (RIC) is cloud-native, and a central component of an open and virtualized RAN network. See a summary of the use cases in the table below.

A key part of the RIC is its ability to support non-real-time apps (rApps) and near-real-time apps (xApps). Both types of applications help optimize network performance by controlling network responses of varying latencies with rApps handling latencies of over one second, and xApps controlling functions requiring latency of less than one second.

Non-real-time RIC takes one second or more to execute and as a result, guides the near-real-time RIC. Non-RT RIC exists in the service management and orchestration (SMO) framework and houses the policies that are reinforced the near-RT RIC. It also manages ML models for the near-RT RIC to use for decision-making based on the network’s condition. Non-RT RIC provides the policies, data, and machine learning models necessary for RAN optimization by the near-RT RIC.

Near-Real-Time RIC executes functions between 10 milliseconds and one and communicates between 1. the application layer, 2. the non-RT RIC, and 3. the infrastructure layer (O-CU &O-DU) where O-CU has disaggregated control and user planes to add flexibility to the architecture. Near-RT RIC directly controls and optimizes the lower levels of the RAN and uses AI and ML to automate the RAN and enforce policies that control routing and quality of service (QoS).

The RIC host microservices-based applications, they are 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 solution.

The RIC provides advanced control functionality, which delivers increased efficiency and better radio resource management. These control functionalities leverage analytics and data-driven approaches including advanced Machine Learning and Artificial Intelligence (ML/AI) tools to improve resource management capabilities.

RIC enables a vendor agnostic platform to handle control and management planes. Through control and management planes, RICs access the RAN as a whole: elements, connections, and functions.

There are 3 controls loops available for MNOs to exploit, depending on the needs of the application or service:

  • MNO can use non-RT RIC Control loop (rApps) for services/apps with execution time: 1 second or more.
  • MNOs can use near-RT RIC Control loop (xApps) for apps with execution time: between 10 ms to 1 second.
  • And use O-DU scheduler loop for apps requiring decision and execution time: below 10 ms.

This allows the RIC to make intelligent decisions about the RAN to optimize performance, from resource and service optimization, energy optimization and sustainability, and network slice assurance. Many use cases within the network as optimized media, game streaming, AR/VR and metaverse can be enabled with efficient spectrum utilization.

For efficiency and cost-effectiveness, the underlying hardware platform for RIC functions must be optimized for AI/ML-based learning and inferencing, as well as also efficiently run all the other usual workloads at the node.

AI models fall into two categories: supervised and unsupervised learning. Being a real-time cellular network, it prefers models that are unsupervised learners to eliminate the model and training challenge continuously.

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

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 and adjust network health to provide the appropriate RAN resources for the optimal subscriber experience.

AI/ML algorithms are responsible for:

•          Forecasting parameters

•          Detecting anomalies

•          Predicting failures

•          Projecting heat maps

•          Classifying components into groups

AI/Machine Learning: enables intelligent operation leveraging automation to the fullest extent eliminating the human element. It’s a huge change for our industry. The architecture and the applications are the platform upon which you can implement AI & ML concepts.

As a result, this will enable proactive action and the ability to predict the future with certain accuracy. Based on prediction a preventative action can be taken to avoid a similar situation in the future.

Many mobile operators plan to use AI to automate network operations. AI coupled with ML will be the main tools to guarantee the quality of network performance and the quality of the resulting end-user experience across all Gs.

Figure 1. RIC Use cases and applications. Source: O-RAN Alliance

AI will be responsible for analyzing data and using ML algorithms to adjust network conditions, provide proper load balancing, and manage handoffs seamlessly — all to ensure the subscriber has the best experience possible.

All data sources, as in Big Data, will need to be considered to first classify the data, then secondly recognize the pattern of abnormality, then thirdly predict the behavior. As time progresses, ML algorithms will evolve and become better at predicting and helping AI to make real-time network decisions. This will be critical for 5G when humans and things will be connected.  

Any AI can only be as good as the data that goes into it. The data will need to cover different use cases and will include data from different vendors across not only all components of the RAN, but the overall network. This is where openness will play a critical role and where the ecosystem must be created.

Analytics

Analytics is a tool to see and understand what’s going on in the network and how those changes affect the subscriber experience. Analytics will provide a visual representation of patterns or abnormalities and will help a mobile operator to understand what needs to be corrected to improve network performance for a better subscriber experience. It’s an opportunity to review the AI data and see reports on how ML is improving the network.

Analytics will be deployed as rAPPs as part of the non-RT RIC and will utilize Big Data to provide an overall view of the network conditions. There will be a need for more openness and better APIs between vendors that enable data mining.

Summary

In April 2022, the O-RAN Alliance released its second set of specifications for OpenRAN with a major focus on open intelligence.

That included the R1 interface between an rAPP and the non-RT RIC and SMO, and the A1 interface that connects non-RT RIC functions in the SMO layer with the near-real time RIC.

This release also included specifications for traffic steering, quality of service and experience, slicing, SMO, and the first version of physical layer acceleration abstraction and security specifications.

This is bringing O-RAN-based components a step closer to wider deployments to open and automate the RAN.

ABOUT AUTHOR