RIC

O-RAN has had a lot of buzz over the past couple of years. The heart of the buzz is how a 5G network can be divided and made more interoperable. On top of that, the O-RAN architecture provides a mechanism allowing additional functionality to be added more efficiently. One of the key ways that value-added functionality can be added is via the RAN Intelligent Controllers or RICs.

Before we dive into the RICs, let's start with a high-level overview of the O-RAN architecture. The key interfaces of the O-RAN architecture include the A1, O1, Open Fronthaul Management Plane, and O2 interfaces. O-RAN network functions can be Virtualized Network Functions (VNFs), Cloud Native or Containerized Network Functions (CNFs), and/or Physical Network Functions (PNFs). The O1 interface provides Fault, Configuration, Accounting, Performance, and Security (FCAPS) support for O-RAN network functions. The Service Management and Orchestration (SMO) framework is connected to an external server that provides data enrichment information for improving RAN traffic management. The O2 interface connects the SMO framework to O-Cloud, and the open fronthaul management Plane (M-Plane) facilitates the O-RU's initialization, configuration, and management.

 

O-RAN architecture

 

RAN Intelligent Controller

The RAN Intelligent Controller is an open platform that can host RAN control applications. There are two types of control applications. They are referred to as non-real-time and near-real-time. The near-real-time RIC hosts control applications that are more sensitive to delay, whereas the non-real-time RIC hosts applications that operate over a larger time scale.
The non-real-time RIC supports decision-making that is more than one second. The non-real-time RIC can be thought of as consisting of two parts. The first is the non-real-time RIC framework that manages communication between the various control applications and the RAN equipment. The other aspect of the non-real-time RIC is called an rApp, the control application that works with the non-real-time RIC to exert control over various RAN equipment.

The Near-real-time RIC supports decision-making that is less than one second. Just like we saw with the non-real-time RIC, the near-real-time RIC comprises two parts: the framework and the xApps. The framework talks to the various RAN elements using the E2 interface. The xApps work with the near-real-time RIC to control aspects of the RAN equipment.

Because of the difference in timing requirements, the non-real-time RIC can be deployed more centrally, and the near-real-time RIC can be deployed very near the RAN equipment it's expected to control.

Some examples of RIC Services can include:

  • Handover management
  • Traffic steering
  • Radio resource allocation
  • QoS-based resource allocation
  • Multi-vendor slice performance management
  • RAN slice resource allocation and optimization

 

Key Interfaces

O-RAN interfaces

 

The RICs use several important interfaces. The Non-RT RIC uses the A1 interface to send policy and enrichment information to the Near-RT RIC. The A1 is also used to provide Artificial Intelligence/Machine Learning models that can be used to provide value-added functions.

The Near-RT RIC uses the E2 interface to communicate with the various RAN elements. The generic term for a RAN element that supports the E2 interface is an E2 Node. Some of the communication supported by the E2 interface are event and periodic data notification, E2-node parameter control, and setting triggers and policies.

The RICs may use two other interfaces: the O1 and O2 interfaces. The O1 supports typical element management functions. The O2 interface supports instantiation, life cycle management, and FCAPS of functions on a virtualization layer referred to as an O-Cloud.

Many use cases have been described within the O-RAN specifications for the RICs. The key is that with this architecture, we can have one set of vendors that produce O-RAN capable Radio Access Network equipment, another that produces the RICs, and a third set of vendors that produce the xApps and rApps. The hope is that all of these functions will work together.