Introduction to O-RAN

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, followed by three more discussing technical details. 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 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 (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.

Fig. 3. O-RAN-Related Entities

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

Fig. 4. O-RAN Software Community

O-RAN Alliance Specifications

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

Specification NameTitleContents
O-RAN.WG1.O RAN Architecture Description v02.00O-RAN Architecture DescriptionO-RAN definitions, architecture, interfaces, block diagrams
O-RAN.WG1.OAM Architecture v03.00O-RAN Operations and Maintenance ArchitectureOAM use cases, OAM architecture
O-RAN.WG3.RICARCH v01.00Near-RT RIC ArchitecturenRT RIC Architecture, APIs for xApps, requirements
O-RAN.WG1.Use Cases Detailed Specification v03.00Use Cases Detailed SpecificationUse cases background, entities involved, solutions, required data
O-RAN.WG3.E2GAP v01.01Near-Real-time RIC Architecture & E2 General Aspects and PrinciplesnRT RIC Functional allocation, architecture, and support functions, E2 principles and functions, service model
O-RAN WG2.A1GAP v02.00A1 interface: General Aspects and PrinciplesA1 service architecture and functions, A1 signaling procedures, protocol structure
O-RAN.WG2.A1AP v02.00A1 interface: Application ProtocolA1 services, API definitions, Open API specification, JSON objects (e.g. for TS
policy)
O-RAN.WG1.O1 Interface.0 v03.00O-RAN Operations and Maintenance Interface SpecificationManagement services (provisioning, fault supervision, performance assurance, etc.)
Table: Selected O-RAN Alliance Specifications (based on [1])

Please note that the above provides a non-exhaustive list of the specifications. For the full list, please go to the 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 are providing more insights into specific aspects, like architecture (2. O-RAN Architecture, Nodes, and Interfaces), RIC design (3. O-RAN near-Real-Time RIC), and use cases (4. O-RAN Use Cases: Traffic Steering). To close the considerations, Fig. 5 below provides the abbreviation list for the O-RAN-related terms and nomenclature.

Fig. 5. O-RAN Glossary

RIMEDO Labs Resources

poster-oran

References

[1] O-RAN ALLIANCE (o-ran.org)
[2] 3GPP
[3] Open Networking Foundation
[4] SD-RAN – Open Networking Foundation
[5] Telecom Infra Project | Global Community Connectivity collaboration
[6] OpenRAN – Telecom Infra Project
[7] Home – Open RAN Policy Coalition
[8] O-RAN Software Community
[9] O-RAN Virtual Exhibition
[10] Open RAN Small Cell Forum


Note: ETSI is the copyright holder of LTE, LTE-Advanced, LTE Advanced Pro, and 3GPP 5G Logos. LTE is a trademark of ETSI. RIMEDO Labs is authorized to use the LTE, LTE-Advanced, LTE-Advanced Pro, and 3GPP 5G logos and the acronyms LTE and 3GPP. Other logos’ copyrights are held by their respective owners.

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.

4 odpowiedzi na “Introduction to O-RAN”

Add a comment

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *

Witryna jest chroniona przez reCAPTCHA i Google Politykę Prywatności oraz obowiązują Warunki Korzystania z Usługi.