Skip to content

O-RAN near-Real-Time RIC

O-RAN 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

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].

Fig. 1. O-RAN near-RT RIC – Internal Architecture

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 provides 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 in the same time may want to move the user back as the handover boundary change due to high handover failure rate. In such a case the individual user will be “ping-ponged” between the two cells if we don’t have conflict mitigation function that looks on 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 O-RAN Alliance definition (see Fig. 2) [3].

O-RAN near RT RIC implementation-options
Fig. 2. near-RT RIC implementation options

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.

oran_ric_e2
Fig. 3. E2 Key Performance Measurements – O-DU Measurement format for 5GC Example

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

o-ran-poster

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

Author Bio

Marcin Dryjanski received his Ph.D. (with distinction) from the Poznan University of Technology in September 2019. Over the past 12 years, Marcin served as an R&D engineer and consultant, technical trainer, technical leader, advisor, and board member. Marcin has been involved in 5G design since 2012 when he was a work-package leader in the FP7 5GNOW project. Since 2018, he is a Senior IEEE Member. He is a co-author of many articles on 5G and LTE-Advanced Pro and a co-author of the book „From LTE to LTE-Advanced Pro and 5G” (M. Rahnema, M. Dryjanski, Artech House 2017). From October 2014 to October 2017, he was an external advisor at Huawei Technologies Sweden AB, working on algorithms and architecture of the RAN network for LTE-Advanced Pro and 5G systems.​ Marcin is co-founder of Grandmetric, where he served as a board member and wireless architect between 2015 and 2020. Currently, he serves as CEO and principal consultant at RIMEDO Labs.
You can reach Marcin at marcin.dryjanski@rimedolabs.com

Subscribe to RIMEDO Labs newsletter to stay updated with our top notch content

No comment yet, add your voice below!


Add a Comment

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *

We’d love to help

Contact form