You are currently viewing Open RAN – An Open and Disaggregated Network Design for the Future of Mobile Cellular Systems

Open RAN – An Open and Disaggregated Network Design for the Future of Mobile Cellular Systems

In this short blog, Marcin Dryjanski [SM’18], shares his expertise on Open RAN. He received his PhD (with distinction) in technical sciences, discipline: technical computer science and telecommunications at the Poznan University of Technology in September 2019. Since 2020 he serves as CEO and principal consultant at RIMEDO Labs, focusing on Open RAN and beyond 5G concepts. Over the past 12 years, Marcin served as an R&D engineer and consultant, technical trainer, technical leader, co-founder and board member. He was responsible for software solutions and training architecture in Open RAN, 5G, LTE / LTE-Advanced / LTE-Advanced Pro, SON, radio interface design, MIMO, OFDMA, and radio protocols.

Marcin has been involved in 5G design since 2012 when he was the leader of the work package in the FP7 5GNOW and FP7 SOLDER projects. Since 2018, he has been 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 consultant at Huawei Technologies Sweden AB, working on algorithms and architecture of the RAN network for LTE-Advanced Pro and 5G systems.


Recently, one of the important topics in the telecom’s area is Open RAN. This post discusses several aspects related to this topic, namely, architecture, RAN Intelligent Controller and use cases. However, before we dig into it, I’d like to start with a small clarification. If you are looking for an Open RAN topic, you’ll find references in the literature and Internet to various names, like “Open RAN”, “OpenRAN”, “ORAN”, and “O-RAN” (see, e.g., [1, 2, 3, 4]). To shortly explain those, the term “Open RAN” refers to the overall movement of opening up the RAN by disaggregating hardware and software and creating open interfaces between them. “OpenRAN” is used by Telecom Infra Project; the O-RAN Alliance uses O-RAN with a “dash”. To avoid misunderstandings, we discuss here is the “O-RAN”, which is the Open RAN as defined by O-RAN Alliance, an entity whose mission is “to re-shape the RAN industry towards more intelligent, open, virtualized and fully interoperable mobile networks” [1].

Key O-RAN Elements

In O-RAN (see Figure below), 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), with the following functional description:

  • O-RU (O-RAN Remote 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;
  • A1 interface is defined between Non-RT RIC and near-RT RIC, through which Non-RT RIC provides near-RT RIC with policies, enrichment info, and ML model updates, while on the other hand, near-RT RIC provides back the policy feedback;
  • E2 interface touches and gets into the specific entities within the base station, i.e., O-DU, O-CU. Therefore, 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/near-RT RIC, and gets data collection and feedback from those entities.

Please note that all of those have “O-” in front, adapted by the O-RAN Alliance definitions and architecture (e.g., to support the 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.

RAN Intelligent Controller (RIC)

On the other end of the E2 interface, there is the RIC (RAN intelligent controller), which is abstracted out from the processing units and allows introducing RRM/SON applications in the form of xApps/rApps to control the radio resources and network operation. In the O-RAN concept, this is where the intelligence sits, employing artificial intelligence (AI) models for radio network automation. We split RIC into “near-Real Time RIC” and “Non-Real Time RIC”. The former handles the near-RT radio resource management functions (on a timescale of >10ms and <1s), like Mobility Management, Interference Management, etc., and sits within the RAN domain. The latter one is handling the more high-level functions, SON-like, and provides policies to near-RT RIC over the A1 interface and sits within the management plane. The following figure shows the functional decomposition of the RIC onto Near-RT and Non-RT operations.

Near-RT RIC is one of the key elements in the O-RAN architecture, creating a platform for the vendors (either software vendors, telco vendors, or xApp developers) to provide per-use case RRM algorithms. Such platforms allow adaptation/optimization of radio resources usage for specific scenarios.

O-RAN Use Cases

The figure below shows the different use cases defined by O-RAN Alliance [5] and have two phases as per the members’ preference. Use cases from Phase I got developed earlier to solve the more immediate needs of the operators. The split between phases is instead natural. Use cases from Phase I deal with generic items like white box hardware, traffic steering, QoS/QoE optimization, or massive MIMO. Those are of high priority, as they are related to most of the scenarios that most operators will treat. Use cases from Phase II are related to specialized applications, like slicing/RAN sharing or UAV (Unmanned Aerial Vehicles)/V2X (Vehicular to Anything) aspects that are more specific or highly complex/demanding.


To summarize, the key characteristics of O-RAN include:

  • Disaggregation of the RAN into several functions as discussed below (i.e., CU, DU, RU, RIC);
  • Decoupling of software from hardware via virtualization;
  • Opening of internal RAN interfaces;
  • Intelligent management enabled by the RIC, where the intelligence is natively embedded within the O-RAN using AI models and various specialized RRM functions, like Traffic Steering, Mobility Management, Interference Management, etc.
  • Creating an open ecosystem with different vendors, like CU/DU vendors, RIC vendors, xApp vendors, and system integrators.

[2] OpenRAN – Telecom Infra Project
[3] Home – Open RAN Policy Coalition
[4] Open RAN Small Cell Forum
[5] “O-RAN Use Cases and Deployment Scenarios”, O-RAN Alliance Whitepaper

Marcin’s Linkedin profile: Marcin Dryjanski | LinkedIn

Marcin’s Blog posts: Marcin Dryjanski @ RIMEDO Labs

**Statements and opinions given in this blog are the expressions of the contributor(s). Responsibility for the content of published articles rests upon the contributor(s), not on the IEEE Communication Society or the IEEE Communications Society Young Professionals