Introduction to O-RAN

Published in

rimedolabs

7 min readMar 10, 2021

Currently, one of the hot topics in the telecoms world is Open RAN. I’d like to start a series of posts to discuss the technicalities in this field. This post is providing an introduction to O-RAN which will be followed by two or three more. 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 legacy 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 remote 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.

The claimed characteristics of O-RAN concept (i.e. 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.

Radio Access Network using O-RAN concept

Let’s now take a look at the 5G RAN architecture with the management entities and interfaces brought by 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.

On the other end of the E2 interface, there is the RIC, which is split onto “near-Real Time RIC” (nRT RIC) and “Non-Real Time RIC” (NRT RIC), which can be provided by a third party. (Note that the small “n” is for near-RT, whereas the capital “N” is for Non-RT. They are used in purpose to distinguish those entities.) The former one is responsible for handling the near-RT radio resource management functions (on a timescale of >10ms and <1s), like Mobility Management, Interference Management, etc. The latter one is handling the more high-level functions, SON-like, and provides policies to nRT RIC over the A1 interface. An important aspect to mention here is that the Real-Time (RT) RRM is still there, embedded in O-DU (like MAC scheduler or power control). Summarizing, we have three control loops: RT (<10ms) handled by O-DU, near RT (>10ms, <1s) handled by nRT RIC, and Non-RT (>1s) handled by NRT RIC. This is a hierarchical design, which allows separating the resource management aspects depending on the time scale.

Entities involved in the O-RAN developments

Fig. 3 shows the relevant entities involved in O-RAN definitions and developments and relations between them.

First, we have the 3GPP [2] that defines the 5G standard including architecture, radio interface, operation of RAN, UE, core network. In regards to open RAN, only part of those goes further in our path, while others (like CN) are out of the scope of O-RAN. In this context, the relevant parts include CU, DU, management, and orchestration (MANO), and interfaces like E1, F1, etc.

Secondly, we have the O-RAN Alliance [1], which takes the 3GPP defined elements of RAN and builds upon them with E2 and A1 interfaces, both RICs, lower layer split (LLS), a fronthaul solution, the Service and Management Orchestration (SMO), etc. Doing so, O-RAN Alliance creates the O-RAN open architecture.

Later, an important player is the Open Networking Foundation (ONF) [3] with its software-defined RAN (SD-RAN) [4]. O-RAN Alliance specifications are input to the ONF’s SD-RAN, but not all of them are taken into account. SD-RAN is focusing on building an exemplar platform for O-RAN-based design choices called “micronos-RIC”. The aim is to provide open-source RIC with emulators to allow xApp developers to test their solutions and allows operators to test the different xApps. Additionally, O-RAN Alliance together with Linux Foundation created the O-RAN Software Community (OSC) [8] that aims at creating an open-source software reference design for the whole O-RAN (See the relevant projects within OSC in Fig. 4).

The next important player is Telecom Infra Project (TIP) [5] within the O-RAN area [6]. Specifically, within the RRM part, TIP defines the RAN Intelligence and Automation subgroup (RIA) aiming to use the “micronos-RIC” (or OSCs, or other RICs) to develop and deploy AI-based xApps for use cases like SON, RRM, MMIMO, etc.

So, summing up, from the left side we have the reference design architectures, interfaces, and nodes, then there are exemplar platforms and finally, use case development, where e.g. the operators are setting up priorities for developments. There are also other entities as well, e.g. Open RAN Policy Coalition [7] to promote the Open RAN concept adoption within the governments and ecosystem players. In terms of commercial developments, O-RAN Alliance is also providing a virtual exhibition platform [9] where implementations of various elements of O-RAN are provided and are constantly updated. Small Cell Forum is also being active in the Open RAN developments by means of adapting Small Cell interfaces and the nFAPI interface [10]. This configuration may also be expanded in the near future further by e.g. cloud platform providers for interoperability testing, “xApp stores” and alike.

O-RAN Alliance Specifications

O-RAN Alliance specifies the overal architecture, the management and orchestration, RICs, E2, A1, O1 interfaces, use cases, etc. The table below provides an extract of the key specifications.

Please note that the above provides a non-exhaustive list of the specifications. For full list, please go to O-RAN Alliance website [1]

Summary

This post provided an introduction to O-RAN, where we set up the scene and showed basics like characteristics of O-RAN, the basic building blocks as well as entities involved in the development of this concept. The next posts in this series will be providing more insights into specific aspects, like architecture, RIC design, and use cases. To close the considerations, Fig. 5 below provides the abbreviation list for the O-RAN-related terms and nomenclature.

RIMEDO Labs Resources

Blog posts: O-RAN is closely related to the private mobile networks topic. See our other posts on this: Private 5G Networks — Technology, Architecture, and Deployment and Private Mobile Networks and 5G Era.
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.