O-RAN Near-Real-Time RIC

After looking into an overview in Introduction to O-RAN: Concept and Entities, and discussing the architecture in O-RAN Architecture, Nodes, and Interfaces, now we’re digging a bit more into the details of the O-RAN concept. The topic is RAN Intelligent Controller (RIC), which provides the possibility to manage the radio resources and radio network and is designed within O-RAN architecture as a separate entity. As we know from the previous post, RIC is split into near-Real-Time RIC (O-RAN near-RT RIC) and Non-Real-Time RIC. Today, we are dealing with the former one.

O-RAN Near-RT RIC

Near-RT RIC is a microservice-based software platform for hosting microservice-based applications – xApps. xApps are used to control a distributed collection of RAN infrastructure (eNB, gNB, CU, DU) in an area via E2 protocol (“southbound”). Near-RT RIC provides “northbound” interfaces for A1 and O1 to Non-RT RIC for the management and optimization of the RAN and is responsible for necessary optimization-related tasks across different RANs, utilizing available RAN data from all RAN types (macro/small cells, Massive MIMO). xApps use the E2 interface to collect near RT information (on a UE or cell basis). Near-RT RIC control over the E2 nodes is steered via the policies and data provided via A1 from Non-RT RIC. E2 node shall be able to function independently of Near-RT RIC when and if the E2 interface and/or Near-RT RIC fails. Near-RT RIC leverages embedded intelligence and is responsible for per-UE controlled load-balancing, RB management, interference management, and HO control. Radio-Network Information Base (R-NIB) captures near RT state of the underlying network and feeds RAN data to train AI/ML models, which are then fed to Near-RT RIC to facilitate RRM for a subscriber. Near-RT RIC interacts with Non-RT RIC via the A1 interface to receive trained models and execute them to improve network conditions.

As the name suggests, near-RT RIC operates in near-real-time (i.e. in the timeframe >10 ms and <1 s) and is responsible for RAN control and optimization, incorporates xApps to realize RRM , and bases its operation on UE and cell-specific metrics.

The requirements for the near-RT RIC as provided by O-RAN Alliance in [2] are that the near-RT RIC shall:

• provide a database function that stores the configurations relating to E2 nodes, Cells, Bearers, Flows, UEs, and the mappings between them;
• provide ML (machine learning) tools that support data pipelining;
• provide a messaging infrastructure;
• provide logging, tracing, and metrics collection from near-RT RIC framework and xApps to SMO (service and management orchestration system);
• provide security functions;
• support conflict resolution to resolve the potential conflicts or overlaps which may be caused by the requests from xApps.

Based on the above requirements O-RAN Alliance specified the near-RT RIC internal architecture and building blocks as shown in Fig. 1, as per [2].

The individual elements shown in the figure are as follows (as per [2]):

• Functions hosted by xApps allow services (i.e. RRM control functionalities) to be executed at the near-RT RIC and the outcomes sent to the E2 Nodes (i.e. enforced in the E2 Nodes) via E2 interface;
• Database together with shared data layer allows reading and writing of RAN/UE information;
• Conflict mitigation function resolves potentially overlapping or conflicting requests from multiple xApps;
• Messaging infrastructure function enables message interaction amongst near-RT RIC internal functions;
• xApp subscription management function merges subscriptions from different xApps and provides unified data distribution to xApps;
• Security function provides security scheme for the xApps;
• Management services function element is used for: fault, configuration management, and performance management; Life-cycle management of xApps; Logging, tracing, and metrics collection and transfer to an external system for evaluation.

To have an overview of the different entities’ operations: xApp subscription management is required to be able to identify the new xApps and to allow data distribution among all of them that subscribe to the data collection and provide awareness of the xApps that are onboarded. To distribute the information among those entities we need the message bus, thus the messaging infrastructure is included. Conflict mitigation, in turn, is needed to resolve e.g. overlapping requests. For example, we may have one function, being mobility load balancing (MLB) and another one, like mobility robustness optimization (MRO) – both well-known from potential conflicts within self-organizing networks (SON) framework. Both of them can have an adversarial impact on the actual user behavior. E.g. one may say that the user needs to be moved from one cell to another due to high traffic load, while the other at the same time may want to move the user back as the handover boundary change due to a high handover failure rate. In such a case the individual user will be „ping-ponged” between the two cells if we don’t have a conflict mitigation function that looks at what’s happening in the network and what impact the potential action may have on the network operation if being executed in the E2-Node. In such an example the conflict mitigation function’s job is to align the potential actions to avoid such undesired behavior.

near-RT RIC Implementation Options

Let’s now take a look at the two different implementation options for near-RT RIC as per the O-RAN Alliance definition (see Fig. 2) [3].

The left side of Fig. 2 shows the centralized near-RT RIC, where the whole gNB (by means of O-CUs and O-DU) or eNB, or both are handled by the same near-RT RIC that allows to take unified decisions for an individual base station and globally/holistically optimize its operations. On the contrary, the right side of Fig. 2. shows a fully distributed near-RT RIC, where each E2-Node type is handled by a specialized logical entity of near-RT RIC that allows optimizing of the individual type of the managed entity (i.e., specific E2-Node).

near-RT RIC Deployment Flexibility

The implementation options, as discussed in the previous section, allowed by O-RAN Alliance specifications have their advantages and disadvantages. The advantage is that it allows flexibility, where we may combine the entities or split them and allow being deployed and delivered by different companies. The price to pay, however, is the design of the E2 interface, which is responsible for providing measurements and controlling certain functions, where we need to know which actual E2-Node are we talking to and thus needs overhead to account for this. This is mainly done by encapsulation of the information elements which need those different options.

An example is shown in Fig. 3. (based on [4]) where the Performance Measurements Indicator provided by E2-Node to the near-RT RIC is nested through three levels of encapsulation (Performance Management (PM) container -> O-DU PM container -> O-DU Measurement format for 5GC). The example accounts for a situation, where the E2-Node sending the measurement is an O-DU node with 5G in standalone mode (SA) of operation (i.e. gNB connected to 5GC). If the same O-DU would be sending measurements in a configuration, where it’s connected to EPC (i.e. non-standalone mode, NSA), a different format would have been used.

E2 Interface

E2 interface provides the connectivity between Near-RT RIC and E2 nodes exposing the E2 Node data to the Near-RT RIC and enabling the control of the E2 Nodes through E2 services, including REPORT, INSERT, CONTROL, and POLICY. The Near-RT RIC, and more precisely xApps control certain functions within the E2 nodes which require E2 Agent to be implemented at the E2 Node. Through the E2 interface, the E2 Nodes inform Near-RT RIC about the functions, which can be controlled by xApps.

According to [5], the E2 interface shall facilitate:

• Connectivity between Near-RT RIC and E2 Node supplied by different vendors;
• Exposure of selected E2 Node data (e.g. configuration information (cell configuration, supported slices, PLMNs, etc.), network measurements, context information, etc.) towards the Near-RT RIC;
• Enables the Near-RT RIC to control selected functions on the E2 Node.

E2 interface functions categories [5] include:

• Near-RT RIC Services
  • REPORT, INSERT, CONTROL, and POLICY
• NEAR-RT RIC support functions:
  • Interface Management (E2 Setup, E2 Reset, E2 Node Configuration Update, Reporting of General Error Situations)
  • Near-RT RIC Service Update, i.e. an E2 Node initiated procedure to inform Near-RT RIC of changes to list of supported Near-RT RIC services and mapping of services to functions.

Summary

near-RT RIC is one of the key elements in the O-RAN architecture, which allows feeding an „external” intelligence into the operations of the radio network. It creates a platform to which the vendors (either software vendors or telco vendors or xApp developers) could provide per-use case RRM algorithms to allow adaptation/optimization radio resources usage for specific scenarios. It will be interesting to see how the creation of the ecosystem for those applications will play out. Will there be Google Plays and xApp Stores for the telco world?

RIMEDO Labs Resources

• The O-RAN Whitepaper: Sign up for our newsletter to download: The O-RAN Whitepaper
• Blog posts: Check out other blog posts in this series: 1. Introduction to O-RAN: Concept and Entities, 2. O-RAN Architecture, Nodes, and Interfaces, 4. O-RAN Use Cases: Traffic Steering
• Webinar: A video recording from a webinar discussing the above aspects, and architecture, RIC internals, use cases, with a special focus on traffic steering: O-RAN Architecture and Use Cases – YouTube
• Slides: Sign up for our newsletter to get a free copy of slides on O-RAN Architecture and Use Cases
• Training: Sign up for our O-RAN System Overview Course.
• Poster (High quality, printer-friendly, A3): Subscribe to get your O-RAN Poster copy.

References

[1] O-RAN ALLIANCE (o-ran.org)
[2] O-RAN.WG3.RICARCH-v01.01, „Near-Real-time RAN Intelligent Controller (Near-RT RIC) Architecture”, O-RAN Alliance, November 2020
[3] O-RAN.WG1.O RAN Architecture Description v03.00, “O-RAN Architecture Description”, O-RAN Alliance, November 2020
[4] ORAN-WG3.E2SM-KPM-v01.00.00, „O-RAN Near-Real-time RAN Intelligent Controller E2 Service Model (E2SM) KPM”, O-RAN Alliance, February 2020
[5] O-RAN.WG3.E2GAP-v01.01, „Near-Real-time RAN Intelligent Controller Architecture & E2 General Aspects and Principles”, O-RAN Alliance

Author Bio