O-RAN Non-RT RIC: Architecture and rApps

The goal of Non-Real Time RAN Intelligent Controller (O-RAN Non-RT RIC) is to support intelligent RAN optimization by providing policy-based guidance, model management, and enrichment information to the Near-RT RIC function so that the RAN can be optimized. In contrary to Near-RT RIC, which sits in the RAN domain and works on a timescale of tens to hundreds of milliseconds, Non-RT RIC works within the management plane (and more particularly in Service Management and Orchestration, SMO) and operates on a timescale of seconds and minutes. In this post, we provide the architecture of the Non-RT RIC and discuss the example applications, called rApps.

Note: If you are interested in details of Near-RT RIC and xApps, see the following posts on our blog: O-RAN near-Real-Time RIC (RAN Intelligent Controller)xApp Implementation: O-RAN Traffic Steering Use Case.


The functionality of the Non-RT RIC includes configuration management, device management, fault management, performance management, and lifecycle management for all network (NW) elements within O-RAN architecture. It is similar to Element Management System (EMS) and Analytics and Reporting functionalities in the traditional NWs. All RAN elements are self-configured by the Non-RT RIC, reducing the need for manual intervention. By providing timely insights into NW operations, Mobile Network Operators (MNOs) may use Non-RT RIC to better understand and optimize NW by applying pre-determined service and policy parameters. Its functionality is internal to the SMO in the O-RAN architecture and provides an A1 interface to the Near-RT RIC. Non-RT RIC can use data analytics and Artificial Intelligence (AI)/Machine Learning (ML) training/inference to determine the RAN optimization actions for which it can leverage SMO services such as data collection and provisioning services of the O-RAN nodes. Trained models produced in the Non-RT RIC are distributed to the Near-RT RIC for runtime execution. Network slicing, security, role-based access control, and RAN sharing are example aspects that are enabled by the combined controller functions namely, Near-RT and non-RT [4].

O-RAN Non-RT RIC Architecture

Fig. 3 shows the internals of the SMO framework including the Non-RT RIC. Functionality inherent to the Non-RT RIC itself is colored in blue. Those functions are used basically for managing the rApps which are external to the Non-RT RIC framework accessible through an open Application Programming Interface (API), using R1 interface. Also, another set of „blue elements” include those that create the data to be transmitted over the A1 interface, namely: A1 policy functions, A1 enrichment information functions, A1 ML functions.

There are also parts in the SMO framework that are out of Non-RT RIC scope, marked with a „pink-ish” color. They are basically related to the O1/O2 termination as well as other SMO framework functions, e.g. for network slicing lifecycle management. Those are inherent to the SMO framework.

Finally, the green part refers to the functionality which implementation is flexible. Those functions could be part of Non-RT RIC and they could be also external to Non-RT RIC and sit in the SMO. They are not inherent to any of those. The example here is AI/ML workflow functions. In such light, AI/ML could be either part of Non-RT RIC, or it could be external, providing the information to the SMO service exposure functions.

Fig. 1. Detailed functional architecture (based on [4])

rApp Examples

rApps are applications designed to run on Non-RT RIC providing additional value-added services to help creation of policies that the Non-RT RIC framework delivers down to Near-RT RIC through the A1 interface. Fig. 2, shows Non-RT RIC with three example rApps, namely rApp R, rApp U, and rApp Q connected via R1 interface to the Non-RT RIC framework. Their inputs and outputs are as follows:

rApp R (RF signal predictor):

  • Consumes: O1 measurements of RF signal experienced by UE for serving/neighbor cells, measurements for UE location;
  • Outputs: future time prediction of the location of UE, prediction of RF signal at that location for serving/neighbor.

rApp U (Cell utilization predictor):

  • Consumes: cell utilization measurements regarding actual capacity utilization for a cell site over time;
  • Outputs: future time prediction of the cell site utilization based on the trend.

rApp Q (UE QoE predictor):

  • Consumes: measurements of UE RF signal (actual RAN measurement or prediction), measurement of cell site capacity utilization (actual or prediction)
  • Calculates: QoE experienced by particular UE, e.g.:
    • Estimates actual QoE based on actual RF signal and actual cell utilization.
    • Estimates QoE if in a neighbor cell based on actual RF signal relative to neighbor cell and actual neighbor cell utilization.
    • Estimates future QoE if connected to serving/neighbor cell-based predicted signal and predicted cell utilization.
Fig. 2. Example rApps (based on [4])

rApp R is an rApp which consumes the O1 measurements. It takes the information from the O1 interface for RF signal experienced by a UE on serving and neighboring cells, and UE location. Based on this input, it estimates/predicts the future UE location and RF signal level when the UE moves towards a certain direction. For example, based on the past information of UEs at a given location with particular values for received signal levels from serving and neighbor base stations, and on the current measurements, it predicts the most likely UE signal levels after it moves towards predicted location.

rApp U is a cell utilization predictor, which consumes the cell load utilization and amount of resources of a cell over time and outputs a future prediction of the cell load utilization, based on the trend. Doing so, it could deduct, e.g., that at the beginning of the day there is a lot of traffic in particular area, and then the traffic volume drops because all the people are moving to work so the traffic moves to the city center and thus predict the future cell load utilization.

rApp Q takes outputs from rApp R and rApp U, i.e. the predicted locations, signal levels, and cell utilization at a particular area and time, as well as the actual measurements and the actual cell utilization. Based on those it calculates the potential quality of experience (QoE). So, e.g., it could predict the future QoE if the user stays at a particular location or in different future location, for a scenario, where UE stays at the same cell or is handed over to another one.

Summing up

Finally, taking the above discussion on the three rApps, the RAN operation can be optimized as follows. Based on the operation and outputs of the rApps, the policy is created to be sent down to the Near-RT RIC, for example, defining that a particular user is going to have that particular QoE if it stays in a particular cell. If it’s not a satisfying QoE, the user should rather be moved to another cell to make sure that the QoE is assured in the near future. All this is prepared based on previous experience, actual situation, and contextual information. Taking those policies, the Near-RT RIC (or rather an xApp within Near-RT RIC) decides on actual actions to happen in the RAN elements.

If you are interested in an example operation where the policies are created and the Near-RT RIC takes actions, see our other post: O-RAN Use Cases: Traffic Steering.


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