Open RAN RIC: Open RAN Intelligent Controller

5G Technology: NSA & SA modes

What is the RAN Intelligent Controller (RIC) used in Open RAN (ORAN) Networks?

History: from 2G to now

From the era of 2G and 3G, mobile architectures had specific controllers that were responsible for RAN orchestration and management. Then from 4G, overall network architecture became flatter and the expectation was that, to enable optimal subscriber experience, base stations would use the X2 interface to communicate with each other to handle resource allocation. This scenario created the proverbial vendor lock-in as different RAN vendors had their own flavor of X2, and it became difficult for an Operator/MNO to have more than one RAN vendor in a particular location. The O-RAN Alliance went back to the controller concept to enable best-of-breed Open RAN.  

5G Technology: Open RAN Intelligent Controller (RIC)
Open RAN Intelligent Controller (RIC) used in modern wireless networks

Why is RIC needed?

As many 5G experiences require low latency, 5G specifications like Control and User Plane Separation (CUPS), functional RAN splits and network slicing, require advanced RAN virtualization combined with SDN. This combination of virtualization (NFV and containers) and SDN is necessary to enable configuration, optimization and control of the RAN infrastructure at the edge before any aggregation points. This is how the RAN Intelligent Controller (RIC) for Open RAN was born – to enable eNB/gNB functionalities as X-Apps on northbound interfaces. Applications like mobility management, admission control, and interference management are available as apps on the controller, which enforces network policies via a southbound interface toward the radios. RIC provides advanced control functionality, which delivers increased efficiency and better radio resource management. These control functionalities leverage analytics and data-driven approaches including advanced ML/AI tools to improve resource management capabilities.

The separation of functionalities on southbound and northbound interfaces enables more efficient and cost-effective radio resource management for real-time and non-real-time functionalities as the RIC customizes network optimization for each network environment and use case.

Virtualization (NVF or containers) creates software app infrastructure and a cloud-native environment for RIC, and SDN enables those apps to orchestrate and manage networks to deliver network automation for ease of deployment.

Though originally RIC was defined for 5G OpenRAN only, the industry realizes that for network modernization scenarios with Open RAN, RIC needs to support 2G 3G 4G Open RAN in addition to 5G. 

Open RAN :  RIC
Source: O-RAN Alliance

Working group 1 looks after overall use cases and architecture across not only the architecture itself, but across all of the working groups. 

Working group 2 is responsible for the Non-real-time RAN Intelligent Controller and A1 interface, with the primary goal that Non-RT RIC is to support non-real-time intelligent radio resource management, higher layer procedure optimization, policy optimization in RAN, and providing AI/ML models to near-RT RIC. 

Working group 3 is responsible for the Near-real-time RIC and E2 interfaces, with the focus to define an architecture based on Near-Real-Time Radio Intelligent Controller (RIC), which enables near-real-time control and optimization of RAN elements and resources via fine-grained data collection and actions over the E2 interface. 

Working group 5 defines the Open F1/W1/E1/X2/Xn interfaces to provide fully operable, multi-vendor profile specifications that are compliant with 3GPP specifications.

The RAN Intelligent Controller consists of a Non-Real-time Controller (supporting tasks that require > 1s latency) and a Near-Real Time controller (latency of <1s). Non-RT functions include service and policy management, RAN analytics and model-training for the Near-RT RAN. 

A Near Real-Time RAN Intelligent Controller (Near-RT RIC) is a near‐real‐time, micro‐service‐based software platform for hosting micro-service-based applications called xApps. They run on the near-RT RIC platform. The near-RT RIC software platform provides xApps cloud-based infrastructure for controlling a distributed collection of RAN infrastructure (eNB, gNB, CU, DU) in an area via the O-RAN Alliance’s E2 protocol (“southbound”). As part of this software infrastructure, it also provides “northbound” interfaces for operators: the A1 and O1 interfaces to the Non-RT RIC for the management and optimization of the RAN. The self-optimization is responsible for necessary optimization-related tasks across different RANs, utilizing available RAN data from all RAN types (macros, Massive MIMO, small cells). This improves user experience and increases network resource utilization, key for consistent experience on data-intensive 5G networks.

 Source: O-RAN Alliance

The Near-RT RIC leverages embedded intelligence and is responsible for per-UE controlled load-balancing, RB management, interference detection and mitigation. This provides QoS management, connectivity management and seamless handover control. Deployed as a VNF, a set of VMs, or CNF, it becomes a scalable platform to on-board third-party control applications. It leverages a Radio-Network Information Base (R-NIB) database which captures the near real-time state of the underlying network and feeds RAN data to train the AI/ML models, which are then fed to the Near-RT RIC to facilitate radio resource management for subscriber. Near-RT RIC interacts with Non-RT RIC via the A1 interface to receive the trained models and execute them to improve the network conditions.

The Near-RT RIC can be deployed in a centralized of distributed model, depending on network topology.

Source: O-RAN Alliance

RIC Summary

The RIC platform provides a set of functions via xApps and using predefined interfaces that allow for increased optimizations in Near-RT RIC through policy-driven, closed loop automation, which leads to faster and more flexible service deployments and programmability within the RAN. It also helps strengthen a multi-vendor open ecosystem of interoperable components for a disaggregated and truly open RAN.

For Further Information

Please Contact Us

OpenRAN (O-RAN) for 5G explained:

What is a 5G Open Radio Access Network (O-RAN)?

An Open Radio Access Network (O-RAN) is a disaggregated approach to deploying mobile fronthaul and midhaul networks built entirely on cloud native principles. O-RAN underscores streamlined 5G RAN performance objectives through the common attributes of efficiency, intelligence and versatility. Open RAN deployed at the network edge will benefit 5G applications such as autonomous vehicles and the IoT, support network slicing use cases effectively, and enable secure and efficient over-the-air firmware upgrades.

O-RAN is an evolution of the Next Generation RAN (NG-RAN) architecture, first introduced by the GSMA’s 3GPP in their release 15 (5G version 1) technical specification TS 38.401. The O-RAN Alliance formed to undertake the advancement of NG-RAN philosophies, expanding on the scope of what was originally outlined by the 3GPP. Comprising over 1601 member companies, the O-RAN alliance issues specifications and releases open source software under the auspices of the Linux Foundation.

O-Ran (OpenRAN) 5G Radio Network Architecture
O-RAN Logical Architecture Diagram. Picture courtesy Metaswitch

TS 38.401 decomposed the existing Baseband Unit (BBU) into two functional components, a Distributed Unit (DU) and Central Unit (CU). Conforming to modern control user plane separation (CUPS) constructs, the Central Unit can be further decoupled into distinct control plane (CU-CP) and user plane (CU-UP) functions. Replacing the monolithic BBU with the CU/DU allows for new deployment models which feature centralized packet processing functions, while laying the groundwork for separating baseband functions from the (remote) radio unit (RRU/RU).

CableFree OpenRAN (O-Ran) disaggregated Radio Access Network
for 5G and 4G and beyond
ORAN explained: Picture courtesy VIAVI solutions

O-Ran Benefits

Operational efficiencies have been realized through past RAN innovations such as cloud RAN (cRAN), but previous advancements did not free operators from vendor lock-in. By enabling an open, multi-vendor RAN ecosystem, O-RAN introduces cloud-scale economies and competition to the RAN. Marketplace factors, combined with a more elastic and flexible RAN architecture that is already taking shape through virtualization, can enable much faster time to market (TTM) than was previously possible.

Moving away from the vendor-specific RAN paradigm not only enables more flexibility for operators, it also minimizes the “secret sauce” that leaves them reliant on a single vendor for all aspects of RAN implementation and optimization.

Competition and proliferation resulting from of new entrants can potentially drive down O-RAN equipment costs. The inter-carrier, interoperability aspects of Open RAN can also be used to increase efficiencies for existing LTE networks as they continue to incorporate the virtualization and disaggregation that are prerequisite 5G RAN deployment.

A CableFree Remote Radio Head (RRH) used for O-RAN network
A CableFree Remote Radio Head (RRH) used for O-RAN networks

This affords numerous technical and operational advantages, regardless of whether the RRU, DU and CU remain co-located within a 5GNodeB (gNB), like existing NodeB RRU/BBU implementations, or the CU is physically deployed to a more centralized location. The centralization of the CU in an aggregation site reduces costs and accelerates the implementation of dynamic and highly automated multiaccess edge compute (MEC) clouds for the RAN (aka C-RAN). This functional decoupling will also enable the adoption of modern transport protocols which can also align with the 5G core user plane (i.e. SRv6) while easing the addition of new latency, high-bandwidth, AI/ML-driven applications.

The deployment of NG-RAN components is defined as being with or between the fronthaul, midhaul and backbone network. Open interfaces are described as either lower-layer splits (LLS), in the case of the RU to DU connection, or higher-layer splits (HLS) as with the link between the DU and CU. This nomenclature is descriptive of the OSI layer (i.e. L1/L2/L3) exposed by the interface and handled by the NG-RAN function. Where components are instantiated will depend on the requirements of the service slice. A low latency service might demand a CU be co-located with the DU in the access layer while a slice supporting a simple machine to machine communications application would scale more cost effectively with a CU within the network core.

NG-RAN clearly defines the DU and CU plus the F1, E1, Xn and NG between them and the core network but stops short of outlining the service management framework and interfaces required for the RAN to operate within an orchestrated and automated cloud environment. TS 38.401 also fails to address the RU-DU interface. Without further definition, it would be logical to adopt the exiting Common Public Radio Interface (CPRI) defined between the RRU-BBU. Although theoretically a standard, this interface has been heavily modified by individual vendors, effectively locking their RRU to their BBU.

While CPRI is a high-speed serial interface, the bandwidth demands of 5G will stretch the limits of local fiber and increase the need for more radio units. Current implementations do not allow for the DU to reduce this burden by offloading some of its functionality to the RU. While the enhanced CPRI (eCPRI) interface was originally proposed as an alternative, this specification was also developed by just four2 large vendors. The O-RAN Alliance has therefore taking on the task of defining new Open Fronthaul user and management plane interfaces between the DU and RU.

To ensure openness, O-RAN decouples hardware and software into 3 layers: The commercial off the shelf (COTS) merchant silicon (including x86), a hardware abstraction layer and an application layer, where the RAN functions reside. Ensuring each layer is vendor agnostic, the O-RAN alliance has specified a list of requirements for a cloud platform which supports the execution of O-RAN network functions. This is referred to as the O-RAN Cloud Platform, or O-Cloud. Deploying O-RAN functions on x86 hardware in cloud native environments using lightweight (OS virtualization) containers demands a strong emphasis on data plane acceleration. This must be achieved at the application level, as these functions will not have access to the Kernel. As such, solutions may be specific to each O-RAN CNF but leverage standard techniques such as DPDK and FD.io or employ more advanced techniques.

O-RAN challenges

Creating seamless interoperability in a multi-vendor, open ecosystem introduces new test, management and integration challenges that require diligence and cooperation to overcome. In the single-vendor model, accountability is a foregone conclusion and problem isolation and troubleshooting are managed through an established command structure.

Dispersion of vendors could potentially lead to finger pointing when root cause identification is inconclusive. These same complications could plague on-time launch schedules and revenue growth by diluting management and orchestration responsibilities across an array of new O-RAN players.

The enticing Open RAN concept of flexible interoperability also brings challenges for test and integration. To fulfill the O-RAN promise of reduced OPEX and total cost of ownership (TCO), operators must take responsibility for multi-vendor, disaggregated elements and make sure they perform together to maintain QoE standards.

With Open RAN reducing the barrier to entry for dozens of new players, interoperability is a paramount concern for both the O-RAN ALLIANCE and OpenRAN group. An Open Test and Integration Center (OTIC) has been established as a collaborative hub for commercial Open RAN development and interoperability testing. The operator led initiative benefits from the support of global telecom organizations with a shared commitment to verification, integration testing, and validation of disaggregated RAN components. 

Summary

Traditional RAN designs and architectures will still persist in being used. Some operators will prefer Open RAN designs and architecture. Many operators will allow for both options in their network evolution and planning.

For Further Information

Please Contact Us