RAN architecture

Overview

The radio access network (RAN) is the part of a Cellular system that connects user equipment to the rest of the network over the air interface. In a 5G system, the RAN sits between devices and the 5G core network, handling radio transmission, scheduling, mobility at the network edge, and transport toward the core.

RAN Evolution

RAN architecture has evolved from D-RAN (traditional RAN) to C-RAN (Cloud RAN) to vRAN (Virtual RAN) to Open RAN.

The common direction of this evolution is increased disaggregation:

• D-RAN keeps most processing tightly integrated at the cell site
• C-RAN centralizes more baseband functionality
• vRAN virtualizes those functions on general-purpose compute
• Open RAN adds standardized open interfaces and multivendor interoperability goals

Open-RAN (O-RAN)

Open RAN, often written as O-RAN in the context of the O-RAN Alliance, extends the idea of vRAN (Virtual RAN) by trying to reduce vendor lock-in through open interfaces and clearer functional splits.

In a traditional closed deployment, major RAN components such as the Radio Unit (RU), Distributed Unit (DU), and Central Unit (CU) often come from the same vendor. Open RAN reframes these as O-RU, O-DU, and O-CU and aims to let operators mix components that conform to common specifications.

This matters because Open RAN is not just a hardware split. It is an architectural and operational model built around:

• disaggregated RU, DU, and CU functions
• open interfaces between components
• software control and automation
• support for multivendor integration

Open-Source RAN Projects

In practice, three open-source RAN software stacks often come up in labs and testbeds:

• srsRAN
• OpenAirInterface (OAI)
• OCUDU

These projects matter because they provide concrete software implementations of disaggregated RAN ideas rather than only architecture diagrams.

• srsRAN is widely used for practical 5G gNB experimentation, CU/DU deployment, and interoperability work in labs and private-network environments.
• OpenAirInterface (OAI) is a major research-oriented open RAN platform with strong relevance to CU/DU separation, O-RAN-style deployment, and end-to-end experimentation.
• OCUDU is another open-source disaggregated RAN option centered on split-RAN deployment and O-RAN-style software decomposition.

Taken together, these projects make the abstract ideas in RAN architecture easier to study in real systems:

• how CU, DU, and RU are separated
• how split options affect deployment design
• how open interfaces and multivendor integration behave in practice

O-RAN Functional Context

Important O-RAN-related building blocks include:

• SMO (Service Management and Orchestration)
• Near real-time RIC
• Radio Unit (RU)
• O-RAN Alliance Split Architecture

In practical terms, the RAN handles radio access while the core handles subscriber management, policy, and connectivity to external data networks. Open RAN focuses on how the radio-side system is decomposed, managed, and opened to interoperable implementations.

O-RAN Alliance Split Architecture

The O-RAN split model describes how radio-access functions are partitioned across the radio unit, distributed unit, and central unit. These splits matter because they determine:

• where real-time processing happens
• what latency and bandwidth the transport network must support
• how much functionality can be centralized
• how easily operators can mix vendors and scale parts of the RAN independently

How to Read the Splits

At a high level:

• moving more functions toward the RU reduces transport demands but leaves more processing at the edge
• moving more functions toward the DU or CU increases centralization but usually tightens timing and fronthaul requirements
• no split is universally “best”; the choice depends on transport constraints, hardware availability, synchronization, and operational goals

For quick orientation:

Split	Main boundary	Typical takeaway
7.2	lower PHY / higher PHY style boundary	common in O-RAN and vRAN because it balances flexibility and transport feasibility
6	MAC / PHY style boundary	pushes more processing toward the edge and can fit smaller or more localized deployments
2	CU / DU boundary over F1	popular higher-layer disaggregation point with more relaxed transport constraints
E1	CU-CP / CU-UP boundary	separates control and user plane inside the CU for independent scaling

Disaggregation

split 7.2 (vRAN model)

Split 7.2 is one of the most common O-RAN deployment models. In this arrangement, the RU keeps RF and low-PHY work close to the antenna, while the DU takes higher-PHY and other lower-layer processing. The CU remains responsible for upper-layer functions.

It is widely used because it offers a practical balance:

• more disaggregation than a tightly integrated base station
• more realistic transport requirements than pushing every function centrally
• good alignment with current O-RAN and vRAN implementations

split 6 (small cell model)

Split 6 places more functionality on the distributed side than higher-layer splits and is often discussed around small-cell-style deployments. Conceptually, it keeps less centralized coordination than split 2 while relaxing some of the tighter transport demands seen in lower-layer disaggregation.

The tradeoff is straightforward:

• less dependence on very demanding fronthaul
• more compute and implementation complexity closer to the cell site

split 2 (F1 split)

Split 2 is the CU/DU boundary commonly associated with the F1 interface. It separates higher-layer CU functions from DU functions and is widely used in disaggregated RAN systems where CU and DU can be placed independently.

This split is attractive because:

• transport requirements are generally easier than lower-layer splits
• it allows CU functions to be centralized across multiple DUs
• it fits well with practical multi-site deployments

E1 split (CU-CP and CU-UP)

The E1 split separates the CU control-plane and user-plane functions into CU-CP and CU-UP. This improves flexibility by allowing control and user-plane processing to scale or be placed independently.

This matters when an operator wants:

• separate scaling of signaling and user traffic handling
• cleaner control/user-plane decomposition inside the RAN
• more flexible placement of CU functions

Components

Radio Unit (RU)

The Radio Unit handles low-level radio work such as RF processing, beamforming, filtering, amplification, and conversion between radio-frequency signals and baseband-oriented data streams. Operationally, it sits near the antenna and strongly influences the coverage characteristics of the cell.

ns-O-RAN

RRU: Remote Radio Unit interfaces with an antenna on one end and BBU-side processing on the other. It connects toward centralized or distributed processing through fronthaul technologies such as CPRI and handles RF conversion, filtering, and amplification.

• 5G NR frequency bands

• O-RU Products

  • Benetel

Distributed Unit (DU)

The Distributed Unit handles time-sensitive lower-layer work, commonly including RLC, MAC, and parts of the PHY layer. It is usually deployed closer to the Radio Unit (RU) to keep latency and transport demands manageable.

In practice, the DU is where operators often balance:

• edge placement for timing-sensitive functions
• pooling efficiency across multiple cells
• interoperability with RU implementations and selected split options

Central Unit (CU)

The Central Unit handles higher-layer protocol functions such as RRC and PDCP, and SDAP in 5G deployments. A single CU can connect to multiple DUs, and it may be colocated with the DU or placed farther away depending on the transport and deployment model.

The CU is the part most naturally centralized when the goal is:

• coordination across multiple DUs
• simplified higher-layer management
• independent scaling of control-plane and user-plane functions when E1 is used

Reference List

1. https://telcocloudbridge.com/blog/c-ran-vs-cloud-ran-vs-vran-vs-o-ran/
2. https://www.redhat.com/architect/mobile-architecture-cloud-ran
3. Polese, M., Bonati, L., D’Oro, S., Basagni, S., & Melodia, T. (2022). Understanding O-RAN: Architecture, interfaces, algorithms, security, and research challenges. arXiv preprint arXiv:2202.01032.
4. https://orandownloadsweb.azurewebsites.net/specifications
5. https://www.radisys.com/blog/open-ran-functional-splits-explained