O-RAN Overview, Architecture, near-Real-Time RIC and Use Cases

Currently, one of the hot topics in the telecoms world is Open RAN. This post gathers the extracts from a series of blog posts on this topic provided on our web. The first section provides an introduction to O-RAN, followed by architecture discussion, RAN-intelligent controller description, and overview of use cases. First of all, to avoid misunderstandings, the thing that we are going to discuss is the O-RAN with the “dash”. This is the Open RAN as defined by O-RAN Alliance, an entity, which mission is?“to re-shape the RAN industry towards more intelligent, open, virtualized and fully interoperable mobile networks”?[1].

Introduction to O-RAN

Fig. 1, shows the transformation of the Radio Access Network (RAN) when moving from the traditional approach to the Open RAN. The tradiotional way of providing RAN is that there is a single black box and the internal interfaces within that box are closed and are in hands of one vendor. Moving towards Open RAN (O-RAN), we are splitting the different functions of the base station into the following entities with open interfaces between them: a centralized unit (CU), a distributed unit (DU), and a radio unit (RU). A similar architecture is defined within 3GPP, but with the O-RAN approach, those entities can be developed by different vendors due to the open interfaces between them (including Open Fronthaul, Open FH). In addition to that, the important part is that the orange box, i.e. RAN intelligent controller (RIC) is extracted from the processing units and allows to reach the management interfaces, like radio resource management (RRM) or self-organizing networks (SON) functions, which control the radio resources and network operation. In the O-RAN concept, this is where the intelligence sits, by the means of artificial intelligence (AI) models for radio network automation.

Fig. 1. RAN Transformation

The claimed characteristics of the O-RAN concept (claimed by the entities involved in the specification and driving the O-RAN) are also shown in Fig. 1 and include:

• Disaggregation of the RAN into the mentioned functions (i.e. CU, DU, RU, RIC), decoupling of software from hardware (virtualization), and opening of internal RAN interfaces.
• This allows creating an open ecosystem where there will be different vendors, like CU/DU vendors, RIC vendors, as well as the functionality developers (i.e. xApp developers), integrators who will need to provide the whole system to the operator. Due to all this, there is also a need for an entity that will allow testing interoperability between the different vendors.
• Intelligent management – this is enabled by the already mentioned RIC, where the intelligence shall be natively embedded within the O-RAN using AI models and various specialized RRM functions, like Traffic Steering, Mobility Management, Interference Management, etc.

Let’s now take a look at the 5G RAN architecture with the management entities and interfaces brought by the O-RAN Alliance definition (see Fig. 2).

Fig. 2. O-RAN-based Radio Access Network (D/A – digital to analog, RFE – RF Frontend, SDAP – Service Data Adaptation Protocol, AMF – Access and Mobility Function, UPF – User Plane Function, PDCP – Packet Data Convergence Protocol, RLC – Radio Link Control, MAC – Medium Access Control, PHY – Physical Layer, Sched. – Scheduler)

What we see here is a simplified protocol stack of the radio interface between the base station (BS) and the user equipment (UE), where we have lower layer processing, MAC layer with a scheduler, and other layer-2 protocols (PDCP, RLC), and finally, RRC controlling the connection and different parameters of lower-layer protocols (L3). In 5G there are two defined entities in the CU, namely CU-CP (Control Plane – for connection management) and CU-UP (User Plane – for UP data processing). In 5G, compared to LTE, additionally, there is an SDAP protocol in the UP path for QoS mapping. Nothing new so far. Now, when getting to O-RAN the CU-UP, CU-CP, DU, and RU, gets the “O-” in front, meaning that they are adapted to the O-RAN Alliance definition and architecture (e.g. to support E2 interface and O-RAN defined functionality). Due to being connected to the E2 interface, they are called E2 nodes in the O-RAN Alliance specifications.

Note: You can find a full blog post that also describes entities involved in the O-RAN developments and O-RAN Alliance specifications under this link 1. Introduction to O-RAN: Concept and Entities

O-RAN Architecture

Fig.3 shows the overall O-RAN architecture (Fig. 3), as per O-RAN Alliance specification [2].

Fig. 3. Overall O-RAN Architecture

The blue elements are 3GPP defined and adapted by O-RAN specifications (thus the “O-” is added), while the orange ones are O-RAN defined elements. The individual elements are the following:

• O-Cloud:?a Cloud Computing platform comprising physical infrastructure nodes to host O-RAN functions, like near RT-RIC, O-DU, etc.; supporting software components (e.g. OS, VM monitoring, container runtime), management, and orchestration functions.
• O-RU?(O-RAN Radio Unit): a logical node hosting a low-PHY layer (e.g. FFT/IFFT, PRACH) and RF-based on LLS (Lower-Layer Split);
• O-DU?(O-RAN Distributed Unit): a logical node hosting RLC (Radio Link Control) / MAC (Medium Access Control) / high-PHY layers based on LLS;
• O-CU-CP?(O-RAN Central Unit-Control Plane): a logical node hosting RRC (Radio Resource Control) and CP (Control Plane) part of PDCP (Packet Data Convergence Protocol);
• O-CU-UP?(O-RAN Central Unit-User Plane): a logical node hosting SDAP (Service Data Adaptation Protocol) and UP (User Plane) part of PDCP;
• near-RT RIC?(near Real-Time RAN Intelligent Controller or nRT RIC): a logical node enabling near-RT control/optimization of RAN elements and resources via fine-grained data collection and actions over E2. nRT RIC may include AI/ML workflow.
• Non-RT RIC?(Non-Real-Time RAN Intelligent Controller or NRT RIC): a logical node enabling Non-RT control/optimization of RAN elements and resources, capturing AI/ML workflow, and policy-based guidance of applications/features in nRT RIC;
• xApp: an application designed to run on nRT RIC, likely to consist of one or more microservices, that identifies data to consume and provide. xApp is independent of nRT RIC and may be provided by a third party.
• SMO?(Service and Management Orchestration): a system supporting orchestration of O-RAN components that includes NRT RIC.

Regarding the interfaces. Again the “blue” interfaces are specified by the 3GPP (like F1 and E1), while “orange” interfaces are specified by O-RAN Alliance. Let’s now focus on the “orange” interfaces:

• A1 interface?is defined between NRT RIC and nRT RIC, through which NRT RIC provides nRT RIC with policies, enrichment info, and ML model updates, while from the other hand, nRT RIC provides back the policy feedback (i.e. how the policy set by NRT RIC works)
• E2 interface?actually touches and gets into the specific entities within the base station, i.e. O-RU, O-DU, O-CU. Therefore, e.g. from one side we can control what is happening within that BS, using monitor, suspend, override, control messages, and execute actions coming from by xApps/nRT RIC, and gets data collection and feedback from those entities.
• O1 and Open-Fronthaul M-plane interfaces?– a regular FCAPS (Fault, Configuration, Accounting, Performance, Security) interface with configuration, reconfiguration, registration, security, performance, monitoring aspects exchange with individual nodes, like O-CU-UP, O-CU-CP, O-DU, O-RU, as well as nRT RIC.
• O2 interface?– to manage the platform resources and workload (like resource scaling and FCAPS).

Note: You can find a full blog post that also describes implementation options under this link 2. O-RAN Architecture, Nodes, and Interfaces

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.

O-RAN Alliance specified the near-RT RIC internal architecture and building blocks as shown in Fig. 4, as per [3].

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

The individual elements shown in the figure are as follows (as per [3]):

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

Note: you can find a full blog post that also describes RIC implementation options and discusses deployment flexibility under this link 3. O-RAN near-Real-Time RIC

O-RAN Use Cases

One of the key elements of having RIC (and the overall O-RAN concept for the management of radio networks) is to be able to efficiently manage and optimize the radio network. By using the concept of open interfaces and xApps, O-RAN enables tailored algorithms for specific use cases. O-RAN Alliance [1] specifies preliminary use cases [4, 5] and defines the policy framework by which the algorithms to support the use cases can be controlled.

Fig. 5, shows the different use cases that are defined by O-RAN Alliance [5] and which are split into two phases as per the organization members’ preference [5]. This means that the use cases specified within Phase I shall be developed earlier to solve the most immediate needs of the operators.

Fig. 5. O-RAN Use Cases

The split between phases is rather natural. Phase I use cases deal mostly with the relatively generic items like white box hardware, traffic steering or QoS/QoE optimization, or massive MIMO. Those are of high priority, as they are related to most of the scenarios that will be treated by most operators. Phase II, in turn, is related to specialized applications, like slicing/RAN sharing or UAV (Unmanned Aerial Vehicles)/V2X (Vehicular to Anything) aspects that require specific requirements (which are highly demanding) for some networks that serve specific/rare type of applications.

Note: You can find a full blog post that also describes traffic steering use case detailed description with the elaboration of the O-RAN entities operation under this link 4. O-RAN Use Cases: Traffic Steering

Summary

Closing the bracket of our O-RAN discussion with respect to the architecture, design, and application scenarios, the conclusions, are that using O-RAN allows:

• adding intelligence to network with external entities, namely xApps and both RICs;
• control of RAN behavior by declarative policies;
• combination of various applications (like xApps/rApps) to realize certain objectives of network performance optimization;
• a hierarchical and modular approach to resource management;
• defining RRM applications (xApps) on per use case basis.

To check all our posts on wireless-related topics see:?https://www.rimedolabs.com/blog/

Other resources on O-RAN

• Blog posts:?Check out blog posts in this series:?1. Introduction to O-RAN: Concept and Entities ,?2. O-RAN Architecture, Nodes, and Interfaces ,?3. O-RAN near-Real-Time RIC , 4. O-RAN Use Cases: Traffic Steering
• Webinar:?A video recording from a webinar discussing the above aspects, and architecture, RIC internals, use cases, with a special focus on traffic steering:?O-RAN Architecture and Use Cases – YouTube
• Slides:?Sign up for our newsletter to get a free copy of?slides on O-RAN Architecture and Use Cases
• Training:?Sign up for our?O-RAN System Overview ?Course.
• Poster?(High quality, printer-friendly, A3):?Subscribe to get your O-RAN Poster copy .

References

[1]?O-RAN ALLIANCE (o-ran.org)

[2] O-RAN.WG1.O RAN Architecture Description v03.00, “O-RAN Architecture Description”, November 2020

[3] O-RAN.WG3.RICARCH-v01.01, “Near-Real-time RAN Intelligent Controller (Near-RT RIC) Architecture”, O-RAN Alliance, November 2020

[4] O-RAN.WG2.Use-Case-Requirements-v02.01, “Non-RT RIC & A1 Interface: Use Cases and Requirements”, O-RAN Alliance, Nov. 2020

[5] “O-RAN Use Cases and Deployment Scenarios”, O-RAN Alliance Whitepaper

[6]?3GPP

[7]?Open Networking Foundation

[8]?SD-RAN – Open Networking Foundation

[9]?Telecom Infra Project | Global Community Connectivity collaboration

[10]?OpenRAN – Telecom Infra Project

[11]?Home – Open RAN Policy Coalition

[12]?O-RAN Software Community

[13]?O-RAN Virtual Exhibition

[14]?Open RAN Small Cell Forum

About RIMEDO Labs

RIMEDO Labs specializes in providing high-quality and substantive consulting, implementation, and R&D services in the field of modern wireless systems. We implement this through an individual and open approach to the client, constantly improving the team operationally and substantively, updating knowledge and a unique combination of science and business applications. RIMEDO Labs is a spin-off from the Poznan University of Technology, Poland from the Institute of Radiocommunications. In addition to the industrial and implementation projects using a licensed know-how solution in the field of effective allocation of resources in wireless networks, RIMEDO Labs also provides consulting and education in the field of O-RAN. The company’s clients and partners are and can be both domestic and foreign entities with various profiles.

Recently, RIMEDO Labs has joined the?Open Networking Foundation (ONF) , where as a member works within the?Software-Defined Radio Access Network (SD-RAN?) project ?community comprised of leading operators and technology companies focusing on building open-source components for the Open RAN space in compliance with the O-RAN Alliance’s architecture and specifications.?Read the full?press release .