RAN Intelligent Controller (RIC): Overview, xApps, and rApps

RAN Intelligent Controller (RIC) is to enable abstracting out part of functionality from the eNB or gNB that was traditionally hosted at the base station in the form of xApps or rApps in the O-RAN architecture. The functions, to which we relate here in the RAN domain include e.g., mobility management or interference management. The decisions are made in the xApps, and RIC then enforces policies towards the RAN elements and controls them using the open interface, namely E2. In this post, we elaborate on the RIC, its functional split, xApps, and rApps.

Note: If you are interested in the overall O-RAN topic, or O-RAN architecture, see the following posts: Introduction to O-RAN: Concept and EntitiesO-RAN Architecture, Nodes, and Interfaces.

RAN Intelligent Controller

RAN Intelligent Controller (RIC) is split onto Non-Real Time RIC (Non-RT RIC) and Near-RT RIC as shown in Fig. 1. Non-RT RIC provides configuration management, analytics and takes a helicopter view on the network, gets the AI-based feeds, and provides the recommendations to Near-RT RIC over the A1 interface. Its general task is to support non-real-time optimization of the network and procedures. A1 interface is used to provide policies, enrichment information, Machine Learning (ML) model management towards Near-RT RIC, and to get the policy feedback back to the Non-RT RIC.

Near-RT RIC in turn is a software platform to allow the xApps to control the RAN through it. It enables near real-time control optimization of the RAN elements (called E2 Nodes) via actions sent over the E2 interface. Example xApps include handover optimization, radio link monitoring, mobility management, load balancing, slicing policy updates, traffic steering, and interference management. E2 interface is a closed loop within the RAN domain, used to send the RIC control and policy towards E2 Nodes and to obtain the feedback from E2 Nodes to the Near-RT RIC.

Speaking of the functional split, in the Non-RT RIC there are the rApps, AI/ML model training, along with service and policy management, which creates the policies to be sent over the A1 interface. Also, as an input to the Non-RT RIC, there is enrichment data, i.e. additional information from the network functions, and from external non-network functions, like user priority. The Near-RT RIC is equipped with xApps, together with the RAN and UE database storing the network state, along with xApp management and security functions.

Fig. 1. O-RAN RIC: Functional Split and Control Loops

Below there is a summary of the main elements, as per the above figure:

Non-Real-Time RIC:

  • provides configuration, management and analytics (visibility into network, AI-based feeds, recommendations to near-RT RIC);
  • supports non-RT intelligent radio resource management, higher layer procedure optimization, policy optimization in RAN, and provides AI/ML models to near-RT RIC.

Near-Real-Time RIC:

  • a software platform for a set of xApps for the RAN;
  • enables near-RT control and optimization of RAN elements and resources via fine-grained data collection and actions over E2 interface;
  • example use cases: network intelligence (policy enforcement, HO optimization), resource assurance (radio-link monitoring, advanced SON), resource control (load balancing, slicing policy).

A1 interface:

  • intent based interface;
  • policy feedback to non-RT RIC;
  • policy, enrichment info and ML model mgmt for near-RT RIC.

E2 interface:

  • RAN closed loop;
  • RIC control and policy towards RAN;
  • data collection and feedback to near-RT RIC.

Control Loops

Fig. 1, also shows the three control loops that are considered in the O-RAN context. The first one is called a non-real-time control loop and is directly related to the Non-RT RIC with the latency much larger than one second (>> 1s). This is where the policies are set, the RAN analytics are gathered, and the AI/ML models are trained based on long data sets. In this context, the time is used to deduct the trends in the network (e.g., traffic pattern over an hour, over a day, over a week, etc.)

The Near-RT RIC closes the near real-time control loop of larger than ten milliseconds and less than a one-second timescale (> 10ms, < 1s). This is the timeframe (i.e. granularity of 10s or 10s of milliseconds) within which the xApps are operating, producing policy updates or control actions, and gathering the feedback information. It is related to aspects like connection management, where e.g., an xApp decides if the user shall be moved from one cell to another.

Finally, there is a real-time control loop with a timescale of less than 10 milliseconds (< 10ms). This is where real-time resource management happens, like resource scheduling, power control, HARQ, beamforming decisions, etc. It’s being executed within the MAC layer at O-DU (O-RAN Distributed Unit). Here, Near-RT RIC may influence the overall operation of these functions, e.g. allocating/reallocating the number of PRBs for a specific slice, based on measurements or policies from Non-RT RIC. However, the actual PRB allocation to individual UE on a per-TTI basis is left to the scheduler.

xApps and rApps

xApps (left side of Fig. 2.) sit in the RAN domain. They are applications designed to run on Near-RT RIC, requiring to follow the specified API definition for Near-RT RIC. Each xApp could be designed as one or more microservices. At the point of onboarding, an xApp needs to identify itself and provide the information to the Near-RT RIC about the data types it wants to consume and about outputs it will produce. It’s independent of the Near-RT RIC and may be provided by a third party. The E2 interface provides the direct association between an individual xApp and corresponding RAN functionality.

rApp (right side of Fig. 2.) is a modular application designed to run on Non-RT RIC and therefore sit in the management plane. Their aim is to provide value-added services related to RAN optimization and procedure optimization through Non-RT RIC. Examples of those services include providing policy-based guidance and enrichment information across the A1 interface; performing data analytics, AI/ML training, and inference for RAN optimization or for use by other rApps; providing recommendations on configuration management actions over the O1 interface.

Fig. 2. xApps vs rApps

If we compare both, an xApp is slightly different from rApp, but the concept is similar: they are working as independent applications at the Near-RT RIC or Non-RT RIC respectively; they need to fulfill the requirements for the open API to be able to communicate with the other part of the RIC. The important difference, though is that an xApp directly controls an actual function within the RAN element, while an rApp is used within the Non-RT RIC framework helping to create policies (i.e. indirectly influence particular function). Another difference is that xApps and rApps work on different time scales.

Near-RT RIC and Non-RT RIC Details

If you are interested in details on Non-RT RIC and rApps, check out this post: O-RAN Non-RT RIC: Architecture and rApps.

If you are interested in details on Near-RT RIC and xApps, check out those posts: O-RAN near-Real-Time RIC (RAN Intelligent Controller)xApp Implementation: O-RAN Traffic Steering Use Case.


[1] O-RAN ALLIANCE (o-ran.org)
[2] O-RAN.WG3.RICARCH-v02.00, „Near-Real-time RAN Intelligent Controller (Near-RT RIC) Architecture”, O-RAN Alliance
[3] O-RAN.WG1.O RAN Architecture Description v03.00, “O-RAN Architecture Description”, O-RAN Alliance
[4] O-RAN.WG2.Non-RT-RIC-ARCH-TR-v01.00, „Non-RT RIC Architecture”, O-RAN Alliance
[5] O-RAN.WG3.E2GAP-v01.01, „Near-Real-time RAN Intelligent Controller Architecture & E2 General Aspects and Principles”, O-RAN Alliance

Rimedo Labs Resources

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

Add a comment

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *

Witryna jest chroniona przez reCAPTCHA i Google Politykę Prywatności oraz obowiązują Warunki Korzystania z Usługi.