The Problem O-RAN Solves
Traditional RAN deployments are vertically integrated: the antenna, radio unit, baseband, and software all come from a single vendor (Ericsson, Nokia, Huawei, or Samsung). This creates vendor lock-in where an operator cannot swap the software without replacing the hardware, cannot introduce third-party optimization algorithms, and faces limited pricing leverage.
The O-RAN Alliance (founded 2018) defines open interfaces between RAN components, enabling multi-vendor interoperability. The architecture specifications are published separately from 3GPP, in the O-RAN Alliance's own specification series (O-RAN.WG1 through WG11).
O-RAN vs Traditional RAN
The fundamental shift is from a closed, monolithic system to a disaggregated, software-defined architecture.
| Aspect | Traditional RAN | O-RAN |
|---|---|---|
| Vendor model | Single vendor per site | Multi-vendor mix-and-match |
| Interfaces | Proprietary (CPRI fronthaul) | Open (eCPRI/O-RAN 7.2x fronthaul) |
| Intelligence | Embedded in vendor software | Externalized in RIC (xApps/rApps) |
| Hardware | Purpose-built (custom ASIC) | COTS servers + accelerators |
| Software | Monolithic, closed | Disaggregated, containerized (cloud-native) |
| Optimization | Vendor-controlled (SON) | Operator/3rd-party controlled (xApps) |
| Update cycle | Vendor release schedule (6-12 months) | Continuous deployment (weeks) |
| Cost structure | High CAPEX, vendor-dependent OPEX | Lower CAPEX (COTS), flexible OPEX |
| Deployment flexibility | Fixed configurations | Programmable, policy-driven |
| AI/ML integration | Limited, vendor-proprietary | Native, via rApps and xApps on RIC |
O-RAN Architecture Components
The O-RAN architecture disaggregates the RAN into four functional components plus two intelligent controllers.
O-RU (O-RAN Radio Unit): Handles the lower PHY layer -- OFDM, FFT/iFFT, beamforming weights application, and RF transmission/reception. Connected to the O-DU via the Open Fronthaul interface. O-DU (O-RAN Distributed Unit): Handles upper PHY (LDPC encoding/decoding, scrambling), MAC scheduling, and RLC. Runs on COTS hardware with hardware accelerators (FPGA or GPU) for PHY processing. O-CU (O-RAN Central Unit): Split into O-CU-CP (RRC, PDCP-C) and O-CU-UP (PDCP-U, SDAP). Handles higher-layer protocols and is typically deployed on edge cloud infrastructure. Near-RT RIC (Near-Real-Time RAN Intelligent Controller): Executes control loops with latency between 10 ms and 1 second. Hosts xApps -- third-party or operator-developed applications that optimize RAN behavior in near-real-time (e.g., traffic steering, interference management, QoS optimization). Non-RT RIC (Non-Real-Time RAN Intelligent Controller): Operates on timescales greater than 1 second. Hosts rApps that perform AI/ML model training, policy generation, and network-wide optimization. Part of the SMO (Service Management and Orchestration) framework.Interface Table
O-RAN defines a comprehensive set of interfaces, each with a specific protocol stack and function. These are specified across O-RAN Alliance working groups.
| Interface | Between | Protocol | Function | Timescale | O-RAN WG |
|---|---|---|---|---|---|
| E2 | Near-RT RIC <-> O-CU/O-DU | SCTP/ASN.1 | xApp control/monitoring of RAN nodes; REPORT, INSERT, CONTROL, POLICY | 10 ms - 1 s | WG3 |
| A1 | Non-RT RIC <-> Near-RT RIC | HTTP/2 (REST) | Policy guidance, ML model delivery, enrichment information | > 1 s | WG2 |
| O1 | SMO <-> O-CU/O-DU/O-RU | NETCONF/YANG | Configuration management, fault management, PM data collection | Minutes-hours | WG1 |
| O2 | SMO <-> O-Cloud | REST API | Infrastructure management, workload lifecycle management | Minutes-hours | WG6 |
| Open Fronthaul (M-plane) | SMO <-> O-RU | NETCONF/YANG | O-RU management, configuration, software upgrade | Minutes-hours | WG4 |
| Open Fronthaul (CUS-plane) | O-DU <-> O-RU | eCPRI over Ethernet | IQ sample transport (C/U-plane), synchronization (S-plane) | < 1 ms | WG4 |
| F1 | O-CU <-> O-DU | SCTP (F1-C), GTP-U (F1-U) | 3GPP-defined CU-DU split interface | ~ms | 3GPP |
| Xn/X2 | O-CU <-> O-CU (inter-gNB) | SCTP/GTP-U | Handover, dual connectivity | ~ms | 3GPP |
E2 Interface Deep Dive
The E2 interface is the most innovative O-RAN interface. It connects xApps on the Near-RT RIC to RAN nodes (E2 nodes) and supports four service models:
- E2SM-KPM (Key Performance Measurement): Subscribes to PM counter reports from RAN nodes
- E2SM-RC (RAN Control): Allows xApps to control RAN parameters (handover, scheduling priority)
- E2SM-NI (Network Interface): Mirrors/manipulates messages on 3GPP interfaces
- E2SM-CCC (Connected Cell Configuration): Configures cell parameters
Near-RT RIC vs Non-RT RIC
| Feature | Near-RT RIC | Non-RT RIC |
|---|---|---|
| Control loop | 10 ms - 1 s | > 1 s (typically minutes/hours) |
| Applications | xApps | rApps |
| Deployment | Edge cloud (near RAN) | Central cloud (SMO) |
| Interfaces | E2 (to RAN), A1 (from Non-RT RIC) | A1 (to Near-RT RIC), O1 (to RAN) |
| Use cases | Traffic steering, interference mgmt, QoS enforcement, beam optimization | ML model training, policy generation, network planning, energy saving |
| Data access | Real-time UE/cell metrics via E2 | Historical PM data, enrichment data |
| Platform examples | VMware RIC, Rimedo Labs, Capgemini | Ericsson rApps, Samsung Near-RT RIC, Wind River |
| Typical vendors | Mavenir, Parallel Wireless, HCL | Ericsson, Nokia, Accenture |
| Scalability | Per-cluster (thousands of cells) | Network-wide (millions of cells) |
xApp Example: Traffic Steering
A traffic steering xApp on the Near-RT RIC:
- Subscribes to E2SM-KPM reports from 50 cells (per-UE throughput, PRB utilization)
- Identifies UEs on congested cells that have coverage from underutilized neighbors
- Sends E2SM-RC control messages to modify A3 handover offset for specific UEs
- Monitors outcome via E2SM-KPM; ML model adjusts policy based on results
- Latency budget: 200-500 ms per decision cycle
7.2x Fronthaul Split: Bandwidth Calculation
The O-RAN Alliance adopted the 7.2x functional split (also called lower layer split or LLS) between O-DU and O-RU. In this split, the FFT/iFFT, cyclic prefix removal, and beamforming weight application happen in the O-RU, while resource element mapping, precoding matrix selection, and higher PHY functions happen in the O-DU.
This is a critical departure from the traditional CPRI split (Option 8), which transmits raw IQ samples and requires enormous fronthaul bandwidth. The 7.2x split transmits frequency-domain IQ samples after FFT, significantly reducing bandwidth.
Bandwidth Calculation: Option 8 (CPRI) vs Option 7.2x
Given:- Carrier: 100 MHz, 30 kHz SCS (273 PRBs)
- Antenna: 64T64R
- IQ sample width: 16 bits I + 16 bits Q = 32 bits per sample
- Sampling rate for 100 MHz = 122.88 Msps (per TS 38.211)
- CPRI overhead: 10/8 (line coding)
`
BW = 122.88 Msps x 32 bits x (10/8) = 4,915.2 Mbps per port
Total for 64T64R = 4,915.2 x 64 x 2 (UL+DL) = 629,145.6 Mbps
= ~629 Gbps (!)
`
This is completely impractical. No fronthaul network can carry 629 Gbps per cell.
Option 7.2x bandwidth:In 7.2x, only the occupied PRBs are transported (frequency domain), beamforming reduces 64 antenna ports to the number of spatial layers (e.g., 12), and compression (block floating point per O-RAN WG4) reduces sample width.
`
PRBs = 273, subcarriers per PRB = 12, symbols per slot = 14
Samples per slot = 273 x 12 x 14 = 45,864
Slots per second = 2000 (30 kHz SCS)
Bits per sample (compressed) = 9 bits I + 9 bits Q = 18 bits (BFP)
Layers = 12 (after beamforming at O-RU)
DL BW = 45,864 x 18 x 2000 x 12 = 19.8 Gbps
UL BW = 45,864 x 18 x 2000 x 4 (4 UL layers) = 6.6 Gbps
Control overhead ~15%: Total = (19.8 + 6.6) x 1.15 = 30.4 Gbps
`
Comparison
| Metric | Option 8 (CPRI) | Option 7.2x |
|---|---|---|
| Fronthaul bandwidth (64T64R, 100 MHz) | ~629 Gbps | ~30 Gbps |
| Reduction factor | Baseline | ~21x reduction |
| Transport technology | Dedicated fiber (dark fiber) | 25G/50G Ethernet (2-3 links) |
| Compression | Not applicable | BFP, mu-law (9-bit IQ) |
| Latency requirement | < 100 us | < 250 us |
| Beamforming location | O-DU | O-RU |
The 7.2x split makes Massive MIMO over open fronthaul practical. Three 25GbE links (75 Gbps total) provide sufficient capacity with headroom.
Real Operator Deployments
Rakuten Mobile (Japan)
Rakuten operates the world's first fully virtualized, cloud-native mobile network built on O-RAN principles. Key data:
- Deployment: 44,000+ base stations covering 98% of Japan's population (as of 2024)
- Vendors: Altiostar (now Rakuten Symphony) for software, NEC and Foxconn for O-RUs
- Architecture: Centralized O-CU/O-DU on Rakuten Symphony cloud platform, distributed O-RUs
- RIC: Rakuten Symphony RIC with traffic steering and energy management xApps
- Cost: Rakuten claims 40% lower CAPEX and 30% lower OPEX compared to traditional RAN
Dish Network (US)
Dish built a greenfield 5G SA network entirely on O-RAN:
- Deployment: Covering 70%+ of US population by 2024 on n70 (600 MHz) and n71
- Vendors: Mavenir (O-CU/O-DU software), Fujitsu and MTI (O-RUs), VMware RIC
- Cloud: AWS Outposts for edge computing (O-DU), AWS cloud for O-CU and core
- Innovation: First operator to demonstrate multi-vendor xApp deployment on a commercial network
Vodafone (Europe)
Vodafone has the largest O-RAN deployment in Europe:
- Deployment: 2,500+ Open RAN sites across UK and Europe by 2024, target 30% of European sites by 2030
- Vendors: Samsung, Dell, and NEC for O-RU/O-DU; partner ecosystem for xApps
- Performance: Vodafone reported that Open RAN sites achieve within 5% of traditional RAN KPIs (CSSR, drop rate, throughput) after optimization
- RIC deployment: Non-RT RIC for energy saving rApps, reducing per-site power by 15-20%
Challenges and Limitations
O-RAN is not without issues:
- Integration complexity: Multi-vendor integration testing is expensive. The O-RAN Alliance runs PlugFests, but field integration still requires extensive effort.
- Performance gap: Initial Open RAN deployments showed 10-15% lower throughput vs traditional RAN. The gap has narrowed to under 5% with hardware accelerators (Intel FlexRAN, Qualcomm X100).
- Fronthaul synchronization: The 7.2x split requires precise timing (< 1.5 us time alignment per O-RAN WG4) between O-DU and O-RU, which is challenging over shared Ethernet transport.
- Security surface: More interfaces mean more attack vectors. The E2 interface, if compromised, could allow an attacker to manipulate scheduling and handover decisions.
- Ecosystem maturity: The xApp/rApp ecosystem is still developing. Most commercial xApps focus on traffic steering and energy saving; advanced use cases (network slicing optimization, predictive maintenance) are emerging.
Key Takeaway: O-RAN disaggregates the RAN into open, interoperable components with intelligent controllers (Near-RT RIC and Non-RT RIC) that enable operator-controlled optimization through xApps and rApps. The 7.2x fronthaul split makes this practical by reducing bandwidth requirements by 20x compared to CPRI, and operators like Rakuten, Dish, and Vodafone are proving the architecture in production networks.