1.1 The Evolution of Mobile Networks

The story of mobile telecommunications is one of relentless acceleration. Each generation has delivered roughly a tenfold increase in peak data rates, a significant reduction in latency, and an expansion of the services the network can support. Yet beneath this evolution in air-interface technology, the radio access network (RAN) architecture has remained remarkably static in one crucial respect: it has been designed, built, and delivered as a vertically integrated, proprietary system controlled by a single vendor.

From the first-generation analogue systems of the early 1980s through to the 5G New Radio (NR) deployments of the 2020s, mobile operators have purchased their RAN equipment as monolithic stacks. A base station from Ericsson, Nokia, or Samsung contains purpose-built hardware, vendor-specific firmware, and proprietary internal interfaces. The radio unit, the baseband processor, and the management software are all tightly coupled. They are designed, tested, and optimised as a single system.

This pattern persisted because it worked. The tight integration between hardware and software allowed vendors to squeeze maximum performance from each generation’s silicon. Operators valued the simplicity of a single point of contact for design, deployment, and support. But the model came at a price that grew steeper with each generation.

1.2 The Vendor Lock-in Problem

Vendor lock-in in the traditional RAN manifests across multiple dimensions: technical, commercial, and strategic. Once an operator selects a RAN vendor for a given network domain, switching becomes prohibitively expensive. The vendor’s proprietary interfaces between the radio unit and the baseband unit, between the baseband and the core, and within the management plane mean that no component can be independently replaced.

The consequences are far-reaching:

• Inflated pricing: With limited alternatives available mid-contract, vendors can command premium pricing for capacity upgrades, software licences, and support contracts. Industry analyses suggest that operators pay 20–40% more for RAN equipment in heavily locked-in scenarios compared to competitive markets.
• Slow innovation cycles: Feature development is dictated by the vendor’s roadmap, not the operator’s needs. New capabilities arrive when the vendor chooses to release them, at the vendor’s price point.
• Supply chain fragility: Dependence on a single vendor concentrates geopolitical and commercial risk. The U.S. and European restrictions on Huawei equipment after 2019 forced operators who had deployed Huawei RAN to undertake multi-billion-dollar rip-and-replace programmes.
• Barrier to differentiation: If every operator in a market buys the same vendor’s product, the scope for network-level differentiation collapses to the vendor’s feature set.

1.3 The Case for Openness

The Open RAN movement is built on three foundational principles that directly address the deficiencies of the traditional model:

Disaggregation separates the RAN into distinct functional components—the radio unit (O-RU), the distributed unit (O-DU), the central unit (O-CU), and the RAN Intelligent Controller (RIC)—each of which can be sourced independently. This breaks the vendor monopoly at the architectural level.

Open interfaces define standardised protocols between these components, enabling interoperability. The Open Fronthaul interface between O-RU and O-DU, the E2 interface to the Near-RT RIC, and the A1/O1 interfaces to the SMO are all specified by the O-RAN Alliance with sufficient detail to achieve multi-vendor interoperability.

Cloud-native execution allows RAN software to run on commercial off-the-shelf (COTS) hardware and cloud infrastructure, eliminating dependence on vendor-specific silicon for baseband processing. This unlocks the economics of general-purpose computing—Moore’s Law, hyperscaler supply chains, and software-defined agility.

1.4 Open RAN Market Landscape

The business case for Open RAN has moved from theoretical to quantifiable. According to industry research, the global Open RAN market was valued at approximately $6.53 billion in 2025 and is projected to reach $45.09 billion by 2033, representing a compound annual growth rate (CAGR) of 26.8%. This trajectory is driven by operator demand for cost reduction, supply chain diversification, and programmable network intelligence.

Key market drivers include:

• Government funding programmes: The U.S. CHIPS and Science Act, the EU’s Open RAN research initiatives, and Japan’s NTT DOCOMO-led investment have injected billions into Open RAN R&D and deployment.
• Greenfield deployments: Operators like Rakuten Mobile (Japan), Dish Network (USA), and 1&1 (Germany) have built entire networks on Open RAN from day one, validating the architecture at commercial scale.
• Brownfield migration: Tier-1 operators including Deutsche Telekom, Vodafone, and Telefonica have committed to deploying Open RAN across significant portions of their existing networks over the next five years.

1.5 Key Stakeholders

The Open RAN ecosystem involves a diverse set of stakeholders, each with distinct motivations and contributions:

Mobile network operators (MNOs) are the demand side of the equation. Tier-1 operators such as Deutsche Telekom, NTT DOCOMO, AT&T, Vodafone, and Telefonica have been vocal advocates and early adopters. Their motivations range from cost reduction (TCO savings of 20–40% are frequently cited) to supply chain resilience and the strategic desire to differentiate through software-defined network intelligence.

Traditional RAN vendors—Ericsson, Nokia, and Samsung—have adopted varied stances. All three are O-RAN Alliance members and offer Open RAN-compliant products, but they also have strong commercial incentives to preserve the integrated model that has underpinned their revenues. Their participation is essential for credibility and scale, but the tension between openness and margin protection is real.

New entrant vendors are a defining feature of the Open RAN landscape. Companies like Mavenir, Parallel Wireless, Altiostar (now part of Rakuten Symphony), Airspan, and Commagility have built their businesses specifically around disaggregated RAN. These vendors typically focus on software, leveraging COTS hardware and cloud platforms rather than building proprietary silicon.

Hyperscalers and cloud providers—AWS, Microsoft Azure, Google Cloud—see Open RAN as an on-ramp to the telecom infrastructure market. By providing the cloud platforms on which virtualised RAN functions execute, they position themselves to capture a share of the $40+ billion annual RAN equipment market.

Governments and regulators have become active participants. The U.S., EU, Japan, India, and the UK have all published Open RAN strategies or funded R&D programmes, motivated by supply chain security, geopolitical resilience, and industrial policy objectives.

2.1 Traditional RAN Architecture

In a traditional RAN deployment, all base station functions reside in a single, co-located unit. In 2G, this was the Base Transceiver Station (BTS); in 3G, the NodeB; in 4G, the eNodeB (eNB); and in 5G, the gNodeB (gNB). Each of these integrated all radio and baseband processing within a single chassis, typically installed at the base of the cell tower or in an adjacent equipment shelter.

The traditional architecture has a deceptively simple topology: the base station connects to the core network through a standardised backhaul interface (S1 in LTE, NG in 5G NR), while all internal processing—RF conversion, digital front-end, PHY layer, MAC scheduling, RLC, PDCP, and RRC—is handled within the vendor’s proprietary hardware and software stack.

2.2 C-RAN and vRAN — Steps Toward Disaggregation

The first meaningful architectural departure from the integrated base station came with Centralised RAN (C-RAN), a concept pioneered by China Mobile in 2010. C-RAN separates the radio frequency (RF) front-end from the baseband processing, placing them in two distinct units:

• Remote Radio Head (RRH): Mounted at the tower top, close to the antenna. Handles RF conversion, power amplification, and digital front-end functions.
• Baseband Unit (BBU): Centralised in a data centre or central office. Performs all higher-layer processing (PHY, MAC, RLC, PDCP, RRC).

The two are connected by a fronthaul link, typically using the Common Public Radio Interface (CPRI) protocol over dedicated fibre. C-RAN delivered tangible benefits: reduced site footprint, centralised maintenance, and statistical multiplexing gains from pooling baseband resources. However, CPRI’s enormous bandwidth requirements (a single 20 MHz LTE carrier with 2x2 MIMO requires approximately 2.46 Gbps of CPRI capacity) and strict latency constraints (≤100 μs one-way) limited deployment to operators with abundant fibre.

Virtualised RAN (vRAN) took centralisation one step further by running baseband functions as software on general-purpose processors (x86, ARM) rather than purpose-built DSP hardware. This introduced the possibility of running RAN workloads on COTS servers, but early vRAN implementations still used proprietary software and lacked open interfaces between the virtualised components. vRAN proved the concept that RAN processing could escape bespoke silicon; Open RAN would build on this foundation by adding open interfaces and multi-vendor interoperability.

2.3 Open RAN Principles

Open RAN extends the centralisation and virtualisation concepts of C-RAN and vRAN with four defining principles:

1. Disaggregation: The monolithic base station is decomposed into discrete network functions—O-RU, O-DU, O-CU-CP, O-CU-UP, Near-RT RIC, and Non-RT RIC—each of which can be independently developed, deployed, and scaled.
2. Open interfaces: Standardised, publicly documented interfaces (Open Fronthaul, E2, A1, O1, O2) connect these functions, enabling equipment from different vendors to interoperate.
3. Multi-vendor interoperability: Operators can select best-of-breed components from different suppliers for each network function, breaking single-vendor dependency.
4. Cloud-native design: RAN functions are designed to execute on COTS hardware, in virtualised environments, or on cloud infrastructure, leveraging containerisation (Kubernetes), orchestration, and hyperscaler economics.

2.4 Functional Split Options

The question of where to split the base station’s protocol stack between the centralised and distributed units is perhaps the most consequential architectural decision in Open RAN. 3GPP defined eight split options in TR 38.801, numbered from Option 1 (PDCP/RRC split, highest in the stack) to Option 8 (RF split, lowest in the stack). Each represents a different trade-off between fronthaul bandwidth, latency requirements, and the distribution of processing load.

2.5 Total Cost of Ownership

The economic argument for Open RAN centres on total cost of ownership (TCO) reductions across both capital expenditure (CapEx) and operational expenditure (OpEx). Rakuten Mobile’s greenfield 4G/5G network in Japan—the world’s first fully virtualised, cloud-native mobile network—reported a 40% reduction in CapEx and a 30% reduction in OpEx compared to traditional RAN deployments of equivalent scale.

2.6 Challenges and Limitations

Open RAN is not without its challenges. A clear-eyed assessment of the current limitations is essential for any engineer or decision-maker evaluating the technology:

Integration complexity: Multi-vendor interoperability does not come for free. While open interfaces define the protocol, they do not guarantee seamless integration. Operators must invest in system integration capabilities—either building internal teams or engaging specialist integrators. The O-RAN Alliance’s TIFG (Testing and Integration Focus Group) and Global PlugFest events address this, but maturity is still developing.

Performance gap: Early Open RAN deployments have shown a performance delta compared to traditional integrated RAN, particularly in areas such as uplink throughput, latency-sensitive scheduling, and massive MIMO beamforming. The gap is narrowing with each release cycle—vendors like Mavenir, Fujitsu, and Nokia (with its Cloud RAN product) have demonstrated parity in controlled environments—but operators deploying in performance-critical urban macro scenarios should validate carefully.

Fronthaul requirements: The Open Fronthaul interface at Split 7.2x demands high-bandwidth, low-latency connectivity between O-DU and O-RU (approximately 25 Gbps for a 100 MHz NR carrier with 4T4R, with ≤100 μs one-way latency). This constrains deployment topologies and requires fibre or advanced ethernet solutions.

Ecosystem maturity: While the O-RAN Alliance has published extensive specifications, not all interfaces have reached the same level of maturity. The Open Fronthaul (WG4) and O1 management interface are the most advanced, while E2, A1, and O2 are still evolving.

3.1 The O-RAN Alliance

The O-RAN Alliance was formally established in February 2018 through the merger of the xRAN Forum (founded in 2016 by AT&T, Deutsche Telekom, NTT DOCOMO, SK Telecom, and Intel) and the C-RAN Alliance (led by China Mobile). As of 2025, the Alliance has grown to over 300 member companies spanning operators, vendors, system integrators, academic institutions, and research labs across 30+ countries.

The Alliance’s mission is unambiguous: to evolve RAN toward open, intelligent, virtualised, and fully interoperable architectures. Unlike 3GPP, which defines air-interface and core network standards, the O-RAN Alliance focuses specifically on the internal interfaces of the RAN—the connections between disaggregated components that 3GPP left vendor-proprietary.

The Alliance is governed by a Board of Directors composed of operator and vendor representatives, with day-to-day technical work managed by the Technical Steering Committee (TSC). The specification work is distributed across eleven Working Groups (WGs) and several Focus Groups (FGs):

3.2 Telecom Infra Project (TIP)

The Telecom Infra Project (TIP) was founded in 2016 by Facebook (now Meta), Deutsche Telekom, Intel, Nokia, and SK Telecom. Where the O-RAN Alliance is specifications-driven, TIP is deployment-driven. TIP’s mission is to accelerate the development and deployment of open, disaggregated telecom infrastructure through community collaboration, lab testing, and field trials.

TIP operates through Project Groups (PGs) and Community Labs. The most relevant to Open RAN is the OpenRAN Project Group, which focuses on disaggregated RAN solutions across 2G, 4G, and 5G. TIP does not write its own air-interface or internal RAN specifications; instead, it leverages O-RAN Alliance specs and 3GPP standards, adding value through:

• Requirements documents: TIP publishes operator-driven requirements that inform and influence O-RAN Alliance specification work.
• Testing and validation: TIP Community Labs in Berlin, Nashua (NH), Tokyo, and other locations provide multi-vendor integration testing environments.
• Badges and certification: TIP’s “TIP-Approved” badge programme validates that specific vendor solutions meet defined operator requirements.
• Field trials: TIP coordinates and funds Open RAN field trials with operators including Vodafone, Telefonica, and MTN.

3.3 Small Cell Forum (SCF)

The Small Cell Forum (SCF) has been advancing small cell and indoor coverage solutions since 2007 (originally as the Femto Forum). Its contribution to Open RAN is primarily through the FAPI (Functional Application Platform Interface) and nFAPI (network FAPI) specifications, which define the interface between the MAC scheduler and the PHY layer within a base station.

FAPI operates at a different level than the O-RAN Open Fronthaul interface. While Open Fronthaul (WG4) defines the interface between O-DU and O-RU (Split 7.2x), SCF FAPI defines the interface within the O-DU itself—between the MAC layer and the High-PHY layer. This is critically important because it enables different vendors to supply the L2 software stack and the L1 (PHY) software independently.

3.4 3GPP’s Role

The 3rd Generation Partnership Project (3GPP) remains the foundational standards body for all mobile network technologies. Every Open RAN deployment is built on 3GPP-standardised air interfaces (NR, LTE), protocols (RRC, PDCP, RLC, MAC), and inter-node interfaces (NG, Xn, F1, E1). The O-RAN Alliance does not redefine these; it builds on top of them.

3GPP’s specific contributions to the Open RAN ecosystem include:

• Functional split framework: TR 38.801 defines Options 1–8, providing the architectural basis for O-RAN’s Split 7.2x selection.
• F1, E1, and Xn interfaces: These inter-node interfaces (standardised in TS 38.470–38.475 for F1, TS 38.460–38.463 for E1) define the protocol between CU-CP, CU-UP, and DU. O-RAN WG5 profiles these for multi-vendor interoperability.
• Air interface specifications: TS 38.211–38.215 define the physical layer procedures that all O-RAN components must implement.
• Core network integration: The NG interface to the 5G Core is a 3GPP specification that remains unchanged in Open RAN deployments.

3.5 How They Work Together

The relationship between these organisations is complementary, not competitive. They operate at different layers of the standardisation and deployment stack, with formal liaison agreements ensuring alignment:

3.6 Choosing the Right Specifications

For an operator evaluating Open RAN, the multiplicity of organisations and specifications can be overwhelming. The practical guidance is straightforward:

1. Start with 3GPP: All Open RAN deployments must comply with 3GPP standards for air interface, protocol stacks, and core network interfaces. This is non-negotiable.
2. Adopt O-RAN Alliance specs for open interfaces: For disaggregation and multi-vendor interoperability, O-RAN WG4 (Open Fronthaul), WG3 (Near-RT RIC / E2), WG2 (Non-RT RIC / A1), and WG10 (O1/OAM) are the critical specifications.
3. Use SCF FAPI for L1/L2 disaggregation: If you intend to source MAC and PHY software independently within the O-DU, SCF FAPI provides the necessary interface definition.
4. Leverage TIP for deployment guidance: TIP’s operator requirements documents, community lab results, and field trial reports provide invaluable practical guidance for moving from specification to deployment.

4.1   O-RAN Alliance History and Mission

The O-RAN Alliance was formally established in February 2018 through the merger of two operator-driven initiatives: the xRAN Forum (founded 2016 by AT&T, SK Telecom, and Deutsche Telekom) and the C-RAN Alliance (led by China Mobile). Five founding operators signed the charter: AT&T, China Mobile, Deutsche Telekom, NTT DOCOMO, and Orange. The mission was unambiguous: drive the mobile industry toward open, intelligent, virtualized, and fully interoperable RAN.

By 2026, the Alliance has grown to over 340 member companies spanning operators, vendors, chipset makers, system integrators, cloud providers, and academic institutions across more than 30 countries. This breadth of membership is unprecedented for a telecom standards body and reflects the industry-wide consensus that proprietary, single-vendor RAN architectures are no longer sustainable.

The Alliance’s core mission revolves around four pillars:

1. Open interfaces — define standardized protocols between RAN components (fronthaul, midhaul, backhaul, management)
2. Intelligence — embed AI/ML into RAN operations through the RAN Intelligent Controller (RIC)
3. Virtualization — decouple software from hardware, enabling COTS deployments
4. Interoperability — ensure multi-vendor, mix-and-match deployments work in production

4.2   Governance Structure

The O-RAN Alliance operates through a layered governance model designed to balance strategic direction with deep technical execution. At the apex sits the Board of Directors, composed of senior executives from member operators. Below the Board, the Technical Steering Committee (TSC) coordinates all technical activities across the Work Groups and Focus Groups.

The membership structure defines three tiers, each with different rights and obligations:

4.3   Work Group 1 — Use Cases and Overall Architecture

WG1 is the foundational Work Group. It produces the O-RAN Architecture Description (OAD), which defines the overall logical architecture, network functions, interfaces, and deployment scenarios. WG1 also maintains the master use case document that drives requirements for all other WGs.

Key responsibilities of WG1 include:

• Defining the O-RAN logical architecture and functional decomposition
• Identifying and prioritizing use cases (traffic steering, QoE optimization, energy saving, etc.)
• Coordinating cross-WG alignment on architecture changes
• Publishing the O-RAN Architecture Description as the single source of truth

4.4   Work Group 2 — Non-RT RIC and A1 Interface

WG2 owns the Non-Real-Time RAN Intelligent Controller (Non-RT RIC) and the A1 interface connecting it to the Near-RT RIC. The Non-RT RIC operates on timescales greater than 1 second, handling policy-based guidance, ML model training and deployment, and enrichment information delivery.

WG2 specifications define the A1 interface with three services: A1 Policy Management (A1-P), A1 Enrichment Information (A1-EI), and A1 ML Model Management (A1-ML). The rApp framework for hosting applications on the Non-RT RIC is also under WG2 scope.

4.5   Work Group 3 — Near-RT RIC and E2 Interface

WG3 is responsible for the Near-Real-Time RIC platform and the E2 interface. The Near-RT RIC operates within a control loop of 10 ms to 1 second, enabling fine-grained radio resource management through xApps. WG3 defines the E2 Application Protocol (E2AP) and the E2 Service Models (E2SM) that expose RAN functions to xApps.

Key E2 Service Models include:

• E2SM-KPM — KPI Monitoring (performance data collection)
• E2SM-RC — RAN Control (parameter modification, handover control)
• E2SM-NI — Network Interface (message routing)
• E2SM-CCC — Connected Cell Configuration and Control

4.6   Work Group 4 — Open Fronthaul Interfaces

WG4 produces arguably the most commercially critical specifications: the Open Fronthaul interface between O-DU and O-RU. This covers both the Control/User/Synchronization Plane (CUS-Plane) and the Management Plane (M-Plane). WG4 defines the eCPRI-based transport, section types for IQ data, beamforming control, and timing synchronization requirements.

4.7   Work Group 5 — Open F1/W1/E1/X2/Xn Interface Profiles

WG5 creates multi-vendor profiles for 3GPP-defined interfaces. While 3GPP specifies F1, E1, X2, Xn, and W1 interfaces, the specifications contain numerous optional IEs (Information Elements) and behavioral choices. WG5 narrows these options to ensure two vendors implementing the same profile can interoperate without bilateral integration.

This is critical for separating O-CU-CP from O-CU-UP (via E1), and O-CU from O-DU (via F1-c/F1-u). WG5 profiles remove ambiguity that would otherwise require vendor-specific adaptation.

4.8   Work Group 6 — Cloudification and Orchestration

WG6 defines the O-Cloud platform and the O2 interface connecting it to the SMO. O-Cloud is the cloud computing platform hosting O-RAN network functions (O-CU, O-DU, Near-RT RIC) on COTS hardware. The O2 interface enables lifecycle management of infrastructure resources (IMS — Infrastructure Management Services) and deployment of workloads (DMS — Deployment Management Services).

4.9   Work Group 7 — White-box Hardware Reference Designs

WG7 produces reference designs for white-box hardware components: O-RU radio units, indoor small cells, and base station platforms based on commercial off-the-shelf (COTS) processors. These reference designs lower the barrier for new hardware vendors to enter the RAN market and provide operators with alternatives to proprietary, vertically integrated equipment.

Notable WG7 deliverables include reference designs for 7.2x-split O-RU hardware across different frequency bands (Sub-6 GHz, mmWave) and form factors (macro, small cell, indoor).

4.10   Work Group 8 — Stack Reference Design

WG8 provides software stack reference designs for O-CU and O-DU implementations. This includes reference architectures for the PHY, MAC, RLC, PDCP, and SDAP protocol stack layers, along with acceleration abstraction layers (AAL) for hardware offload of compute-intensive functions like LDPC encoding/decoding and FFT/iFFT processing.

4.11   Work Group 9 — Open X-haul Transport

WG9 addresses the transport network connecting O-RAN components: fronthaul, midhaul, and backhaul. It defines requirements for latency, jitter, synchronization, and bandwidth across these transport segments. WG9 works closely with WG4 (fronthaul timing) and external bodies like IEEE 802.1 (TSN) and ITU-T (synchronization).

4.12   Work Group 10 — OAM and O1 Interface

WG10 defines the O1 interface for Operations, Administration, and Maintenance between the SMO and all O-RAN managed elements. O1 leverages NETCONF/YANG for configuration management and VES (Virtual Event Streaming) for fault management and performance data collection. WG10 produces YANG models for every O-RAN network function.

4.13   Work Group 11 — Security

WG11 develops security specifications covering threat modeling, security protocols for all O-RAN interfaces, certificate management, and secure boot requirements. The open, multi-vendor nature of O-RAN introduces new attack surfaces compared to proprietary RAN, making WG11’s work essential for production deployments.

Key WG11 deliverables include security threat analysis documents, security protocols for O1/O2/A1/E2/Open Fronthaul interfaces, and the O-RAN Security Requirements specification.

4.14   Focus Groups

In addition to the eleven Work Groups, the O-RAN Alliance maintains several Focus Groups (FGs) that address cross-cutting concerns. Unlike Work Groups, Focus Groups do not typically produce normative specifications but instead create guidelines, test plans, liaison statements, and research reports.

5.1   Specification Naming Convention

Every O-RAN specification follows a structured naming format that encodes the originating Work Group, topic, and version. Understanding this convention is essential for navigating the specification library efficiently.

Key points about the naming convention:

• The major version (XX) increments for significant content changes or new release alignment
• The minor version (YY) increments for editorial corrections and clarifications
• The release tag (e.g., R003) groups specifications into coordinated releases for interoperability testing
• Some documents use descriptive suffixes like -Conformance-Test-Spec or -Technical-Report

5.2   Specification Categories

O-RAN specifications can be grouped into five functional categories. This taxonomy helps engineers focus their reading based on their role and the component they are implementing or integrating.

1. Architecture Specifications — Overall system architecture, functional decomposition, use case requirements (primarily WG1)
2. Interface Specifications — Protocol definitions for A1, E2, O1, O2, Open Fronthaul, and 3GPP profile documents (WG2–WG5, WG10)
3. Cloud & Platform Specifications — O-Cloud architecture, deployment management, infrastructure abstraction (WG6)
4. Security Specifications — Threat models, security protocols, certificate management for all interfaces (WG11)
5. Testing & Conformance Specifications — Conformance test specs, interoperability test plans, PlugFest profiles (TIFG, WG4)

5.3   Key Architecture Specifications

Two specifications from WG1 form the foundation that every O-RAN engineer must read:

5.4   Key Interface Specifications

The interface specifications are where implementation detail lives. Each O-RAN interface is covered by a General Aspects and Principles (GAP) document plus an Application Protocol (AP) document, and often additional service model or conformance test documents.

5.5   Release Cadence and Versioning

The O-RAN Alliance publishes specifications in coordinated releases, though the cadence differs significantly from 3GPP’s rigid release schedule. O-RAN releases are identified by their publication date and an internal release number. Since 2023, the Alliance has adopted a more structured semi-annual release rhythm, with major releases in Q1 and Q3.

Key milestones in the O-RAN release history:

• 2019 — First published specifications (Open Fronthaul CUS-Plane v1.0, A1 v1.0)
• 2020 — E2 interface initial specification, O-Cloud architecture introduced
• 2021 — Release 003 framework established, E2SM-KPM and E2SM-RC published
• 2022 — Major maturity milestone: WG4 conformance test specs, Y1 interface introduced
• 2023 — 100+ cumulative specifications; AI/ML framework formalized in WG2
• 2024–2025 — 74+ new specifications since July 2024; O-RAN-SC I release alignment
• 2026 — 150+ total specifications; Release 004 in development with 6G preparatory work

5.6   Relationship to 3GPP Specifications

O-RAN specifications do not replace 3GPP standards — they complement them. 3GPP defines the base station architecture (gNB), protocol stack (RRC, PDCP, RLC, MAC, PHY), radio interface (NR Uu), and core network interfaces. O-RAN adds open interfaces between disaggregated components, the RIC platform for AI/ML-driven optimization, and cloud-native deployment models.

The relationship is hierarchical: O-RAN specifications reference 3GPP specifications and either profile them (narrow options for interoperability) or extend them (define new interfaces not in 3GPP scope).

5.7   How to Access O-RAN Specifications

O-RAN specifications are available through the O-RAN Alliance portal at specifications.o-ran.org. Access levels depend on membership tier:

Since late 2023, the O-RAN Alliance has progressively opened more specifications to public access. The published release specifications (final, approved versions) are now freely downloadable from the ORAN-SC website and the O-RAN Alliance specification portal. This is a significant shift from the early years when nearly all documents were member-only.

5.8   Reading an O-RAN Specification

O-RAN specifications follow a consistent structure that becomes predictable once you have read two or three documents. A typical specification contains:

1. Scope and Introduction — What the document covers and its relationship to other specs
2. References — Normative (mandatory) and informative (background) references to 3GPP, IETF, IEEE, and other O-RAN specs
3. Definitions and Abbreviations — O-RAN-specific terminology
4. Architecture Overview — Logical/functional architecture relevant to this spec
5. Functional Description — Detailed behavior, procedures, message flows
6. Information Elements / Data Models — ASN.1 definitions (for E2), YANG models (for O1/M-Plane), or RESTful API schemas (for A1)
7. Procedures and Message Flows — Step-by-step protocol procedures with sequence diagrams
8. Annex sections — Examples, use case mappings, implementation guidelines

6.1   High-Level Architecture Overview

The O-RAN architecture disaggregates the traditional monolithic base station into a set of well-defined, interoperable components connected by open interfaces. At the highest level, the architecture comprises eight principal elements: the Service Management and Orchestration (SMO) framework, the Non-Real-Time RIC embedded within the SMO, the Near-Real-Time RIC operating as an independent platform, the O-CU-CP (control plane centralized unit), the O-CU-UP (user plane centralized unit), the O-DU (distributed unit), the O-RU (radio unit), and the O-Cloud infrastructure platform hosting the virtualized network functions.

This decomposition is not arbitrary. Each split point was chosen to enable independent scaling, multi-vendor sourcing, and placement flexibility across the network. The SMO provides the overarching management and orchestration umbrella, while the Non-RT RIC within it hosts rApps that operate on timescales greater than one second. The Near-RT RIC sits between the SMO and the RAN protocol stack elements, hosting xApps that act within 10 ms to 1 second control loops. Below the Near-RT RIC, the O-CU, O-DU, and O-RU implement the actual radio protocol stack from SDAP/PDCP down through RLC, MAC, PHY, and RF.

6.2   O-RAN Logical Architecture

The logical architecture maps every component to a specific set of interfaces, creating a mesh of standardized touchpoints. The interfaces fall into three categories: RAN-internal interfaces inherited from 3GPP (F1, E1), RAN-intelligence interfaces invented by O-RAN (A1, E2, R1), and management/cloud interfaces (O1, O2). Understanding which interface connects which pair of components is the single most important mental model in O-RAN engineering.

6.3   Control Loops — The Three-Tier Intelligence

The most architecturally significant innovation in O-RAN is the formalization of three nested control loops, each operating at a different timescale and hosted by a different controller. This tiered approach allows intelligence to be distributed across the network based on the latency requirements of each optimization function.

The Real-Time (RT) loop, operating below 10 ms, executes within the O-DU and O-RU themselves. Functions like HARQ retransmission, dynamic scheduling, link adaptation, and power control operate here. These are too latency-sensitive to be externalized to any RIC. The Near-Real-Time (Near-RT) loop, between 10 ms and 1 second, runs on the Near-RT RIC via xApps. This is the sweet spot for RAN optimization: traffic steering, load balancing, QoE-aware scheduling policy, interference management, and anomaly detection. The Non-Real-Time (Non-RT) loop, greater than 1 second, runs on the Non-RT RIC via rApps. This handles policy definition, ML model lifecycle management, network-wide analytics, and long-term configuration optimization.

6.4   User Plane, Control Plane, Management Plane Separation

O-RAN enforces a rigorous separation of three planes across the architecture, each with distinct data flows, protocols, and scaling characteristics.

The User Plane (U-Plane) carries subscriber data from the UE through O-RU, O-DU, and O-CU-UP to the 5G Core UPF. It is bandwidth-intensive and latency-sensitive. The key protocol chain is: RF → Low-PHY (O-RU) → High-PHY/MAC/RLC (O-DU) → PDCP-U/SDAP (O-CU-UP) → N3/GTP-U → UPF. The user plane must be optimized for throughput and low per-packet latency.

The Control Plane (C-Plane) handles signaling: RRC connection setup/release, mobility (handovers), security activation, and bearer management. It flows through O-CU-CP, which terminates RRC and PDCP-C. Control plane traffic is low-bandwidth but must be highly reliable. The separation of O-CU-CP from O-CU-UP via the E1 interface allows them to scale independently — a network with many idle-mode UEs needs more control plane capacity relative to user plane.

The Management Plane (M-Plane) provides FCAPS (Fault, Configuration, Accounting, Performance, Security) management for all O-RAN network functions. It uses the O1 interface (NETCONF/YANG for configuration, VES for event streaming, file-based PM for bulk performance data). The management plane operates out-of-band from subscriber data, connecting the SMO to every managed element. For the O-RU specifically, the M-Plane can be terminated either by the SMO directly (hierarchical model) or by the O-DU acting as proxy (hybrid model).

6.5   Multi-RAT Support

The O-RAN architecture natively supports multiple Radio Access Technologies within the same framework. While the primary focus is 5G NR, the architecture accommodates LTE (E-UTRA), and the design principles are extensible to future RATs including 6G. This multi-RAT support is critical for operators managing brownfield networks where LTE and NR coexist for years during migration.

In a multi-RAT deployment, the Near-RT RIC connects via E2 to both LTE eNB/en-gNB nodes and NR gNB nodes simultaneously. The xApps can implement cross-RAT optimization — for example, steering traffic between LTE and NR carriers based on load, signal quality, or service requirements. The Non-RT RIC similarly provides unified policy management across RATs via A1.

At the RAN protocol stack level, O-DU implementations may host both NR and LTE L2 stacks, while O-RU hardware can support multiple frequency bands spanning both technologies. The Open Fronthaul specification (WG4) defines section types that accommodate both NR and LTE IQ data transport, though the primary specification effort targets NR.

6.6   Deployment Topologies

The O-RAN architecture supports three canonical deployment topologies, each trading off different dimensions of latency, capacity, cost, and operational complexity.

Distributed Deployment

In the distributed topology, O-CU and O-DU are co-located at or near the cell site, typically in an edge cabinet or small shelter. The O-RU connects to the O-DU over short-reach fronthaul (dark fiber, typically <20 km). This topology minimizes transport costs and fronthaul latency but distributes compute across many sites, increasing operational complexity and limiting resource pooling gains.

Centralized Deployment

In the centralized topology, O-CU and O-DU are pooled in a centralized or regional data center. Only the O-RU remains at the cell site, connected via fronthaul transport that must meet strict latency and bandwidth requirements (typically <100 μs one-way for Category A O-RU). This topology maximizes resource pooling and simplifies software lifecycle management, but demands high-capacity, low-latency fronthaul transport.

Hybrid Deployment

The hybrid topology places O-CU in a regional data center while O-DU is located at an aggregation site closer to the cell sites. This balances the pooling benefits of centralization against the fronthaul constraints. The midhaul (F1 interface between O-CU and O-DU) is less demanding than fronthaul, allowing longer distances and more relaxed latency budgets (typically 1–10 ms). This is the most common topology in practice for macro network deployments.

6.7   O-RAN and 3GPP NG-RAN Alignment

The O-RAN architecture is not a replacement for 3GPP NG-RAN — it is a superset. Every 3GPP NG-RAN component and interface has a direct O-RAN counterpart, and O-RAN adds intelligence and management layers that 3GPP does not define.

3GPP TS 38.401 defines the NG-RAN architecture with gNB-CU-CP, gNB-CU-UP, gNB-DU, and the F1/E1 interfaces. O-RAN takes these as given and adds the “O-” prefix to indicate open-interface conformance. The critical additions are: the O-RU (3GPP does not standardize the RU or the fronthaul interface below the DU), the Near-RT RIC and E2 interface, the Non-RT RIC and A1 interface, and the O-Cloud with its O2 interface.

7.1   The gNB Disaggregation — From Monolithic to O-CU/O-DU/O-RU

In a traditional RAN deployment, the entire gNB protocol stack — from RRC at the top through PDCP, RLC, MAC, PHY, and down to the RF front-end — resides in a single monolithic unit. This was the dominant architecture for 2G, 3G, and early 4G deployments. The vendor controlled every layer, optimized the internal interfaces for performance, and delivered the base station as a vertically integrated product.

O-RAN disaggregates this monolith into three distinct network functions, each responsible for a specific subset of the protocol stack. The O-CU (Centralized Unit) handles the upper layers: RRC and PDCP (control plane), and SDAP and PDCP (user plane). The O-DU (Distributed Unit) handles the mid-layers: RLC, MAC, and the upper portion of the Physical layer (High-PHY). The O-RU (Radio Unit) handles the lowest layers: the lower portion of the Physical layer (Low-PHY) and the RF front-end including digital-to-analog conversion, power amplification, filtering, and antenna interfacing.

This three-way split is based on the 3GPP Option 7-2x functional split, where “7-2x” refers to the division point between High-PHY and Low-PHY within the Physical layer. The “x” denotes O-RAN’s specific refinement of the 3GPP Option 7-2 split, which precisely defines which PHY functions reside in the O-DU versus the O-RU.

7.2   O-RU — Radio Unit Functions

The O-RU is the only O-RAN component that remains at the cell site in all deployment topologies. It performs the functions closest to the air interface: converting digital baseband signals to/from analog RF signals, amplifying them, and coupling them to the antenna system. The O-RU’s processing scope in O-RAN is deliberately constrained to minimize intelligence at the remote site and maximize the functions that can be virtualized in the O-DU.

Core O-RU functions include:

• Low-PHY processing: FFT (Fast Fourier Transform) for uplink, iFFT (Inverse FFT) for downlink, cyclic prefix addition/removal, and resource element mapping/de-mapping
• Digital beamforming: Applying beamforming weights to antenna elements (in Category B O-RU, the O-RU performs precoding; in Category A, precoding is done in the O-DU)
• RF front-end: Digital-to-Analog Conversion (DAC), Analog-to-Digital Conversion (ADC), power amplification (PA), low-noise amplification (LNA), filtering, and duplexing
• Timing and synchronization: SyncE and IEEE 1588v2 (PTP) clock recovery for precise fronthaul synchronization
• M-Plane agent: NETCONF/YANG agent for configuration, fault, and performance management

7.3   O-DU — Distributed Unit

The O-DU hosts the most computationally intensive real-time functions in the RAN protocol stack. It is responsible for the High-PHY (LDPC encoding/decoding, rate matching, scrambling/descrambling, modulation/demodulation, layer mapping), the MAC layer (scheduling, HARQ management, multiplexing/demultiplexing, random access handling), and the RLC layer (segmentation/reassembly, ARQ for acknowledged mode, reordering).

The O-DU must process data within strict real-time deadlines. The MAC scheduler must produce scheduling decisions every TTI (Transmission Time Interval), which in 5G NR can be as short as 0.125 ms for a 120 kHz subcarrier spacing. HARQ feedback must be processed within a few milliseconds. LDPC decoding for a single 100 MHz NR carrier can require over 1 Tbps of decoding throughput. These requirements drive the need for hardware acceleration within the O-DU platform.

7.4   O-CU-CP — Control Plane

The O-CU-CP implements the RRC (Radio Resource Control) and PDCP-C (Packet Data Convergence Protocol, control plane) layers. It is the signaling brain of the gNB, responsible for all control-plane procedures: RRC connection setup and release, security activation (ciphering and integrity protection), measurement configuration and reporting, mobility management (handover decisions), RAN slicing admission, and bearer management.

Unlike the O-DU, the O-CU-CP is not subject to hard real-time constraints at the sub-millisecond level. RRC procedures operate on timescales of tens of milliseconds to seconds. This makes the O-CU-CP an excellent candidate for full virtualization on standard COTS compute without hardware acceleration. A single O-CU-CP instance can serve multiple O-DUs (and through them, multiple O-RUs), providing a natural aggregation point for centralized mobility management.

7.5   O-CU-UP — User Plane

The O-CU-UP implements the SDAP (Service Data Adaptation Protocol) and PDCP-U (user plane) layers. SDAP maps QoS flows from the 5G Core to DRBs (Data Radio Bearers), enforcing per-flow QoS marking. PDCP-U performs header compression (ROHC), ciphering, integrity protection (optional for user plane), sequence numbering, reordering, and duplicate detection.

The O-CU-UP is the primary user-plane data forwarding entity above the O-DU. It connects to the 5GC UPF via the N3 interface (GTP-U tunnels) and to the O-DU via F1-u (also GTP-U). It must handle high aggregate throughput — a single O-CU-UP may process data for thousands of UEs simultaneously. Unlike the O-DU, it does not require sub-millisecond processing, but it must sustain wire-rate forwarding with minimal per-packet latency.

7.6   Category A vs Category B O-RU

O-RAN defines two categories of O-RU that differ in where the precoding (beamforming weight application) function is performed. This has significant implications for fronthaul bandwidth requirements, O-RU complexity, and deployment suitability.

In a Category A O-RU, precoding is performed in the O-DU. The O-DU sends pre-weighted IQ data over the fronthaul — one stream per antenna element (or per antenna port group). The O-RU simply applies the pre-weighted data to its antenna elements. This means the fronthaul must carry data proportional to the number of antenna elements, resulting in higher fronthaul bandwidth but simpler O-RU hardware.

In a Category B O-RU, precoding is performed in the O-RU itself. The O-DU sends IQ data per spatial layer (typically 1–8 layers for MIMO) along with beamforming weight vectors. The O-RU applies the precoding matrix to map layers to antenna elements. This drastically reduces fronthaul bandwidth (data scales with layers, not antenna elements) but requires more processing power and memory in the O-RU.

7.7   O-RU White-box Reference Designs (WG7)

O-RAN Work Group 7 produces reference hardware designs for O-RU platforms that can be manufactured by any qualified ODM (Original Design Manufacturer). These white-box designs specify the complete hardware architecture: RF front-end design, FPGA/ASIC requirements, antenna interface, power supply, mechanical form factor, and thermal management. The goal is to commoditize O-RU hardware, reducing the barrier to entry for new radio vendors and giving operators alternatives to vertically integrated products.

WG7 reference designs cover multiple deployment scenarios:

• Outdoor macro O-RU: High-power (20–40W per port), multi-band capable, supporting 32T32R or 64T64R Massive MIMO, IP67-rated enclosure, tower/pole mount
• Indoor small cell O-RU: Low-power (typically <250 mW per port), 2T2R or 4T4R, compact form factor, ceiling/wall mount, PoE powered
• mmWave O-RU: FR2 (24.25–52.6 GHz), integrated antenna array with analog beamforming, smaller coverage radius, high-throughput density use case

7.8   Protocol Stack Mapping — Which Layer Runs Where

The following diagram and table provide the definitive mapping of every NR protocol layer to its hosting O-RAN component. This is the reference that every O-RAN engineer should internalize.

8.1 What is Fronthaul?

Fronthaul is the transport network segment that connects the baseband processing unit to the radio unit at the cell site. In traditional RAN architectures, where the baseband unit (BBU) and the remote radio head (RRH) are co-located in the same cabinet, fronthaul is simply an internal backplane connection. But as operators began centralising baseband processing into pools—first for capacity sharing and then for cloud-native deployments—fronthaul became a distinct, external network that must carry real-time radio data across distances of up to 20 kilometres with sub-microsecond timing precision.

The original fronthaul protocol was the Common Public Radio Interface (CPRI), standardised in 2003 by a consortium of Ericsson, Huawei, NEC, Nokia, and Samsung. CPRI carries digitised time-domain IQ samples between the BBU and the RRH over dedicated fibre links using a constant-bit-rate, TDM-like serial protocol. It served the industry well through 3G and 4G, but its fundamental design—streaming raw IQ data at rates proportional to antenna bandwidth and count—became untenable for 5G NR. A single 100 MHz NR carrier with 4T4R MIMO requires roughly 10 Gbps of CPRI bandwidth. Scale that to 64T64R Massive MIMO and the figure approaches 160 Gbps per cell—a physical impossibility for practical deployment.

The enhanced CPRI (eCPRI) specification, published in 2017, addressed the bandwidth crisis by shifting from time-domain to frequency-domain IQ transport and by adopting packet-switched Ethernet as the underlying transport. The O-RAN Alliance then built its Open Fronthaul specification (O-RAN.WG4.CUS.0) on top of eCPRI, adding multi-vendor interoperability semantics, management-plane definitions, and precise timing requirements. This is the interface that connects the O-DU to the O-RU in every O-RAN deployment.

8.2 3GPP Functional Split Options Review

Before the O-RAN Alliance settled on Split 7.2x, 3GPP TR 38.801 defined eight possible functional split points between the central unit and the distributed/radio unit, numbered Option 1 through Option 8. Each option places the boundary at a different layer of the protocol stack, creating a trade-off between fronthaul bandwidth requirements, latency sensitivity, and the complexity of the radio unit.

At one extreme, Option 1 (PDCP/RRC split) pushes nearly all processing to the radio unit, minimising fronthaul traffic to backhaul-like rates but requiring an expensive, fully featured radio unit. At the other extreme, Option 8 (the CPRI model) centralises all processing and sends raw RF samples over fronthaul, demanding extreme bandwidth but allowing a simple, inexpensive radio head.

8.3 Split 7.2x in Detail

Split 7.2x divides the physical layer processing chain at a precisely defined boundary within the PHY. Understanding this boundary requires tracing the downlink (DL) and uplink (UL) processing chains end to end.

Downlink (O-DU → O-RU): The O-DU performs channel coding (LDPC/Polar), rate matching, scrambling, modulation mapping (QPSK through 256QAM), layer mapping, and digital precoding. The output is a set of frequency-domain IQ samples—one complex value per subcarrier per MIMO layer—which are transmitted over the Open Fronthaul U-Plane to the O-RU. The O-RU then applies resource element mapping, iFFT to convert from frequency domain to time domain, adds the cyclic prefix, applies digital beamforming weights (received via the C-Plane), performs digital-to-analogue conversion, and transmits over the RF front-end.

Uplink (O-RU → O-DU): The O-RU receives the RF signal, performs analogue-to-digital conversion, removes the cyclic prefix, applies FFT to convert from time domain to frequency domain, and (optionally) performs uplink beamforming/combining. The resulting frequency-domain IQ samples are sent over the Open Fronthaul U-Plane to the O-DU, which performs channel estimation, equalisation, demodulation, descrambling, rate de-matching, and channel decoding.

8.4 Open Fronthaul Planes

The Open Fronthaul interface is not a single protocol but a collection of four distinct planes, each serving a different function. This separation of concerns allows independent evolution and simplifies multi-vendor interoperability testing.

8.4.1 Control Plane (C-Plane)

The C-Plane carries scheduling and beamforming commands from the O-DU to the O-RU. For every DL transmission, the O-DU sends a C-Plane message specifying which resource elements to use (section descriptors), the beamforming weights or beam IDs, and timing advance information. For UL reception, the O-DU instructs the O-RU on which PRBs to capture and how to apply combining. C-Plane messages are time-critical: they must arrive at the O-RU before the corresponding U-Plane data and within the timing window defined by the O-RAN T2a parameter.

8.4.2 User Plane (U-Plane)

The U-Plane transports the frequency-domain IQ sample data. In the downlink direction, the O-DU sends IQ data for each scheduled PRB; in the uplink direction, the O-RU sends received IQ data back to the O-DU. The IQ sample width is configurable (typically 14–16 bits per I and Q component), and O-RAN supports dynamic compression techniques (block floating point, mu-law) to further reduce bandwidth. U-Plane packets carry section headers that reference the corresponding C-Plane scheduling decisions.

8.4.3 Synchronization Plane (S-Plane)

The S-Plane ensures that the O-RU’s internal clock is synchronised to a common time reference with sub-microsecond accuracy. O-RAN mandates IEEE 1588 Precision Time Protocol (PTP) as the primary synchronization mechanism, with Synchronous Ethernet (SyncE) providing frequency synchronization. The S-Plane defines the O-RU’s role as a PTP slave (Telecom Time Slave Clock, T-TSC) in the synchronization chain.

8.4.4 Management Plane (M-Plane)

The M-Plane handles O-RU lifecycle management: initial bootstrap (DHCP-based discovery), software download and activation, configuration (transmit power, frequency, bandwidth), fault management, and performance monitoring. The M-Plane uses NETCONF with O-RAN-defined YANG models (O-RAN.WG4.MP.0) for configuration and supports both hierarchical mode (M-Plane traffic passes through the O-DU) and hybrid mode (M-Plane connects directly from the SMO to the O-RU).

8.5 eCPRI Transport

The eCPRI specification (CPRI Cooperation, v2.0) defines a packet-based transport protocol that can operate over standard Ethernet infrastructure. This is a fundamental departure from legacy CPRI, which required dedicated, circuit-switched serial links (typically 9.8304 Gbps line rates). eCPRI frames are standard Ethernet frames with an eCPRI-specific header, enabling transport over existing Ethernet switches, routers, and even multiplexed WDM optical networks.

Key properties of eCPRI transport over Ethernet include:

• Statistical multiplexing: Unlike CPRI’s constant-bit-rate streams, eCPRI packets can be statistically multiplexed across shared Ethernet infrastructure, improving utilisation efficiency.
• QoS via VLAN priority: C-Plane and U-Plane traffic are separated into different VLAN priority classes (typically PCP 7 for C-Plane and PCP 6 for U-Plane), ensuring scheduling commands arrive before IQ data.
• Jumbo frames: O-RAN recommends Ethernet MTU of at least 9000 bytes to reduce per-packet overhead when transporting large IQ payloads.
• Scalable line rates: eCPRI operates over 10GbE, 25GbE, or 100GbE interfaces, matching the required fronthaul bandwidth to the antenna configuration.

8.6 Fronthaul Bandwidth Requirements

One of the most critical engineering tasks in an O-RAN deployment is sizing the fronthaul link. The required bandwidth depends on carrier bandwidth, subcarrier spacing, number of PRBs, number of MIMO layers (antenna ports), IQ sample bit width, and the compression method applied.

The fundamental formula for Open Fronthaul (Split 7.2x) DL bandwidth per component carrier is:

BW = N_PRB × 12 × N_sym/slot × N_slot/s × N_layers × 2 × B_IQ

where N_PRB is the number of PRBs (273 for 100 MHz at 30 kHz SCS), 12 is subcarriers per PRB, N_sym/slot is symbols per slot (14 for normal CP), N_slot/s is slots per second (2000 for 30 kHz SCS), N_layers is MIMO layers, the factor 2 accounts for I and Q components, and B_IQ is bits per IQ component (typically 16 bits).

8.7 Timing and Synchronization

Timing is the most demanding aspect of Open Fronthaul engineering. The O-RU must transmit and receive at precisely defined time instants relative to the air-interface frame structure. Any timing error degrades signal quality, causes inter-symbol interference, and breaks MIMO coherence across antenna elements. O-RAN specifies a maximum time alignment error (TAE) of ±65 ns between antenna branches at the O-RU, and the end-to-end synchronization chain must deliver time accuracy within ±1.5 µs relative to the GNSS reference.

The synchronization architecture employs a hierarchical chain of clocks:

• T-GM (Telecom Grand Master): The reference clock, typically GNSS-disciplined, providing the absolute time reference for the entire network. Located at a central site or data centre.
• T-BC (Telecom Boundary Clock): An intermediate clock in transport switches and routers that recovers the PTP time from the upstream T-GM and re-distributes it downstream. Each T-BC adds a bounded amount of timing error.
• T-TSC (Telecom Time Slave Clock): The O-RU’s internal clock, which locks to the PTP time received from the nearest T-BC and uses it to synchronize the air-interface frame structure.

8.8 Fronthaul Security Considerations

The Open Fronthaul is inherently more exposed to security threats than legacy CPRI, which relied on point-to-point dark fibre and the obscurity of a proprietary protocol. eCPRI over Ethernet traverses shared switches and potentially shared fibre infrastructure, creating opportunities for eavesdropping, man-in-the-middle attacks, and denial-of-service.

O-RAN WG4 addresses fronthaul security through several mechanisms:

• M-Plane security: All NETCONF sessions use SSH with mutual authentication (X.509 certificates or pre-shared keys). The O-RU bootstrap sequence uses a call-home mechanism with TLS to establish the initial secure connection.
• C/U-Plane integrity: O-RAN specifies optional MACsec (IEEE 802.1AE) for hop-by-hop encryption of C-Plane and U-Plane traffic. However, the latency overhead of MACsec (typically 1–2 µs per hop) must be carefully budgeted within the already tight timing constraints.
• S-Plane security: PTP can be secured using the IEEE 1588 Annex P security mechanism or MACsec on the PTP transport links to prevent spoofed timing attacks.
• Physical security: Where fronthaul traverses untrusted physical paths (street cabinets, third-party fibre), operators should deploy fibre intrusion detection and VLAN isolation.

9.1 SMO Architecture Overview

The Service Management and Orchestration (SMO) framework is the highest-level management entity in the O-RAN architecture. It is responsible for the complete lifecycle management of the O-RAN network: from initial infrastructure provisioning and RAN software deployment, through configuration and performance optimisation, to fault management and decommissioning. In traditional RAN, these functions were scattered across vendor-specific Element Management Systems (EMS), Network Management Systems (NMS), and orchestration platforms with no standardised interfaces between them. The SMO unifies these functions under a single, open framework.

The SMO communicates with the O-RAN network elements through three primary interfaces:

• O1 interface: Connects the SMO to the O-RAN managed elements (O-CU-CP, O-CU-UP, O-DU, O-RU, Near-RT RIC) for configuration, performance monitoring, and fault management.
• O2 interface: Connects the SMO to the O-Cloud platform for infrastructure lifecycle management and RAN workload deployment.
• A1 interface: Connects the Non-RT RIC (within the SMO) to the Near-RT RIC for policy guidance and ML model deployment.

Internally, the SMO contains the Non-RT RIC as an embedded intelligence layer, along with FCAPS management services, a data collection and analytics framework, and orchestration engines for multi-domain service coordination.

9.2 FCAPS Management

FCAPS is the ISO/TMN management model that has governed telecommunications network management for decades. In the O-RAN context, each FCAPS function maps to specific interface protocols and data models:

Fault Management in O-RAN uses the VES (Virtual Event Streaming) protocol to collect alarm events from managed elements. VES events are JSON-formatted HTTP POST messages sent to a VES collector endpoint in the SMO. Each fault event contains the alarm type, probable cause, severity (critical, major, minor, warning, cleared), the affected managed object, and a timestamp. The SMO correlates alarms from multiple sources—for example, linking an O-RU RF power alarm with an O-DU scheduling failure—to identify root causes.

Configuration Management is the backbone of O-RAN operations. Every O-RAN managed element exposes a NETCONF interface with YANG data models that describe its configurable parameters. The SMO pushes configuration changes using NETCONF <edit-config> operations and validates the running configuration using <get-config>. For initial deployment, the SMO orchestrates a bootstrap sequence: DHCP for IP assignment, call-home for secure registration, followed by full YANG-based configuration.

Performance Management collects PM counter data at configurable intervals (typically 15 minutes for trending, 1 minute for real-time analytics). Counters include throughput, PRB utilisation, RACH success rate, handover statistics, and CQI distributions. This data feeds both the Non-RT RIC’s ML models and the operator’s business intelligence dashboards.

9.3 O1 Interface

The O1 interface is the primary management interface between the SMO and O-RAN managed elements. It is specified by O-RAN WG10 in coordination with 3GPP SA5 (which defines the underlying management data models). O1 combines two complementary protocol stacks:

NETCONF/YANG handles configuration and state retrieval. NETCONF (RFC 6241) is an XML-based protocol that operates over SSH, providing transactional configuration operations (edit-config, commit, rollback-on-error). The O-RAN YANG modules extend 3GPP’s NRM (Network Resource Model) data models with O-RAN-specific parameters—for example, beamforming configuration, fronthaul timing parameters, and xApp deployment descriptors.

VES (Virtual Event Streaming) handles asynchronous event reporting. VES is a RESTful protocol (HTTP POST with JSON payload) originally developed within the ONAP community. O-RAN adopted VES for fault notifications, PM counter streaming, heartbeat monitoring, and file-ready notifications (signalling that a bulk PM file is available for retrieval via SFTP/FTPS).

9.4 O2 Interface

While O1 manages the RAN network functions (O-CU, O-DU, O-RU, Near-RT RIC), the O2 interface manages the underlying cloud infrastructure on which those functions run. O2 is specified by O-RAN WG6 and connects the SMO to the O-Cloud platform. It provides two distinct service categories:

Infrastructure Management Service (IMS) handles the lifecycle of physical and virtual infrastructure resources: compute nodes (servers), storage, networking, and hardware accelerators (FPGAs, GPUs, DSP cards). IMS operations include resource discovery, inventory management, capacity monitoring, and infrastructure scaling. The SMO uses IMS to maintain a real-time view of available infrastructure across all O-Cloud deployment sites.

Deployment Management Service (DMS) handles the lifecycle of containerised RAN workloads: deploying Helm charts or Kubernetes manifests for O-CU, O-DU, Near-RT RIC, and xApps onto O-Cloud clusters. DMS operations include workload instantiation, scaling (horizontal and vertical), healing (auto-restart of failed pods), and termination. DMS abstracts the underlying container orchestration platform (typically Kubernetes) behind a standardised API.

9.5 Non-RT RIC as Part of SMO

The Non-RT RIC is architecturally embedded within the SMO, serving as its intelligence and automation layer. While the Near-RT RIC operates at sub-second timescales (10 ms–1 s control loops), the Non-RT RIC operates at timescales greater than one second—from seconds to hours—making decisions that require aggregated data, historical trends, and operator-defined policies.

The Non-RT RIC’s primary functions within the SMO include:

• A1 Policy Management: The Non-RT RIC defines and pushes A1 policies to the Near-RT RIC. These policies guide Near-RT RIC decision-making without prescribing exact actions. For example, an A1 policy might instruct the Near-RT RIC to “maintain DL throughput above 50 Mbps for premium users on cells with CQI > 8”—the Near-RT RIC’s xApps then determine the specific scheduling and handover actions to achieve this goal.
• ML Model Lifecycle Management: The Non-RT RIC trains, validates, and deploys AI/ML models that are consumed by both rApps (within the Non-RT RIC) and xApps (in the Near-RT RIC). The training pipeline uses historical PM data and network events collected via O1, producing models for traffic prediction, anomaly detection, and capacity forecasting.
• rApp Framework: rApps are applications that run within the Non-RT RIC to perform non-real-time RAN optimisation. Examples include cell capacity planning, coverage optimisation, energy saving algorithms, and RAN slice SLA monitoring. rApps access network data through the R1 interface and can trigger configuration changes via O1 or policy updates via A1.
• Network Data Analytics: The Non-RT RIC aggregates and analyses data from multiple sources (PM counters, alarms, traces, external feeds) to generate actionable insights. This analytics function underpins both automated rApp decisions and human-facing dashboards.

9.6 SMO and ONAP Integration

The Open Network Automation Platform (ONAP) is the Linux Foundation’s open-source platform for network automation and is the most widely referenced implementation framework for the O-RAN SMO. ONAP provides modular components that map to SMO functions:

The ONAP Software Defined Network Controller (SDNC) implements the O1 NETCONF/YANG interface to managed elements. It uses the Controller Design Studio (CDS) to define configuration templates and workflows that can be triggered automatically by ONAP’s policy engine or manually by operators. DCAE (Data Collection, Analytics, and Events) hosts the VES collector and provides the streaming analytics framework used by both ONAP’s internal analytics and the Non-RT RIC’s rApps.

9.7 Multi-domain Orchestration

A mobile network is not just the RAN. End-to-end service delivery requires coordinated management of three domains: the RAN (O-RAN managed elements), the Transport network (fronthaul, midhaul, backhaul), and the Core network (5GC or EPC). The SMO’s orchestration function must coordinate across all three domains to deliver network slices, manage SLAs, and handle cross-domain fault propagation.

Multi-domain orchestration is particularly critical for network slicing. A single network slice (for example, an URLLC slice for industrial automation) requires coordinated resource allocation across all three domains: dedicated PRBs and scheduler priority in the RAN, guaranteed bandwidth and low-jitter paths in the transport, and dedicated UPF instances with edge placement in the core. The SMO, acting as the RAN Network Sub-Slice Management Function (NSSMF), must honour the end-to-end SLA commitments communicated by the top-level Network Slice Management Function (NSMF).

9.8 SMO Vendor Implementations

The SMO market is fragmented, reflecting the framework’s intentional design as an integrable set of functions rather than a monolithic product. Key implementation approaches include:

• ONAP-based SMO (O-RAN Software Community): The OSC’s NONRTRIC project, combined with ONAP’s SDNC, DCAE, and SO, provides a reference open-source SMO. Operators including Deutsche Telekom, Orange, and NTT DOCOMO have contributed to and tested this stack. The primary challenge is operational complexity: ONAP has over 30 microservices and requires significant Kubernetes expertise to deploy and maintain.
• VMware/Broadcom RIC Platform: VMware (now Broadcom) offers a commercial SMO that integrates their RAN Intelligent Controller with VMware’s Telco Cloud Platform for O2 IMS/DMS functions. This approach appeals to operators who want a commercially supported, pre-integrated platform.
• Juniper Networks RIC/SMO: Juniper’s acquisition of 128 Technology and investment in Open RAN led to an SMO offering that emphasises transport-aware orchestration, leveraging Juniper’s strengths in network infrastructure management.
• Samsung and Ericsson hybrid approaches: Traditional RAN vendors offer SMO-compatible management platforms that integrate their existing EMS/NMS capabilities with O-RAN O1/O2 interfaces, providing a migration path for operators who want to adopt O-RAN management interfaces without replacing their entire OSS/BSS stack.
• Custom/hybrid deployments: Many Tier-1 operators build bespoke SMO stacks by integrating best-of-breed components: a commercial NETCONF controller for O1, ONAP DCAE for data collection, a proprietary ML platform for the Non-RT RIC, and an existing cloud management platform for O2. This approach maximises flexibility but increases integration burden.

10.1 Non-RT RIC Architecture

The Non-Real-Time RAN Intelligent Controller (Non-RT RIC) is a logical function within the Service Management and Orchestration (SMO) framework. It operates on control-loop timescales greater than one second—typically minutes, hours, or even days—providing strategic, policy-driven optimization of the RAN. Where the Near-RT RIC makes rapid, tactical decisions at the cell or UE level, the Non-RT RIC takes a broader view: analyzing network-wide trends, training and deploying AI/ML models, and issuing high-level policy guidance that shapes the behavior of the entire radio network.

Architecturally, the Non-RT RIC consists of two principal layers:

• The Non-RT RIC Framework (Platform): A set of platform services that provide common capabilities—data management, AI/ML model hosting, policy engine, security, and lifecycle management. These services are exposed to applications through the R1 interface, as defined in O-RAN.WG2.R1-Interface-v02.00.
• rApps (RAN Applications): Modular applications that consume platform services via R1 and implement specific optimization logic. An rApp might perform energy saving by analyzing traffic patterns and issuing sleep-mode policies, or it might train an ML model for coverage prediction and push it to the Near-RT RIC via A1.

10.2 R1 Interface

The R1 interface is the service exposure point between rApps and the Non-RT RIC platform. It is defined in O-RAN.WG2.R1-Interface-v02.00 and follows RESTful API design principles. Through R1, rApps can consume platform capabilities without needing to understand the underlying infrastructure—they interact with well-defined service endpoints for data access, AI/ML model operations, policy creation, and lifecycle events.

R1 provides the following categories of service access:

• A1 Policy Management Services: rApps create, read, update, and delete A1 policies. The platform handles serialization, transport over A1, and acknowledgement tracking.
• Data Management Services: Access to enrichment data, performance measurements (PM), configuration management (CM), and fault management (FM) data collected via O1 from managed network elements.
• AI/ML Model Management Services: Upload trained models, register model metadata, trigger model deployment to the Near-RT RIC, and monitor model performance.
• rApp Lifecycle Management Services: Register, instantiate, configure, scale, and terminate rApps.
• Authentication and Authorization Services: OAuth 2.0-based token management and role-based access control.

10.3 A1 Interface

The A1 interface is the southbound interface from the Non-RT RIC to the Near-RT RIC. It carries three distinct types of information, each serving a different purpose in the RAN intelligence hierarchy. The protocol is defined in O-RAN.WG2.A1AP-v03.00 and uses RESTful HTTP/JSON for message transport.

A1 Policy Management (A1-P) carries intent-based policies from the Non-RT RIC to the Near-RT RIC. A policy expresses a desired outcome—for example, “minimize handover failures for UEs in slice SST=1, SD=00001”—without prescribing the exact mechanism. The Near-RT RIC’s xApps interpret the policy and translate it into specific RAN control actions via E2. Policies have a type ID, scope, and set of parameters. The Near-RT RIC reports policy enforcement status back to the Non-RT RIC.

A1 Enrichment Information (A1-EI) delivers contextual data that the Near-RT RIC cannot obtain on its own. This includes UE mobility predictions computed from historical trajectory data, geolocation information from external positioning services, and application-layer context such as expected traffic surges for a live sports event. The subscription model allows the Near-RT RIC to register interest in specific enrichment data types and receive updates at the Non-RT RIC’s cadence.

A1 ML Model Management (A1-ML) handles the deployment of trained machine learning models from the Non-RT RIC to the Near-RT RIC. The Non-RT RIC trains models using historical data (collected via O1) and, once validated, pushes them to the Near-RT RIC where xApps use them for real-time inference. This separation of training (Non-RT) and inference (Near-RT) keeps computationally expensive training out of the latency-sensitive Near-RT RIC.

10.4 A1 Policy Types

10.5 rApp Framework

An rApp is a self-contained application packaged as a container image (or set of images) that runs within the Non-RT RIC platform. The rApp framework defines how these applications are onboarded, deployed, configured, monitored, and eventually terminated. This lifecycle is managed by the Non-RT RIC’s rApp Lifecycle Management (rAppLCM) service, which orchestrates container deployment on the underlying O-Cloud infrastructure.

The concept of an rApp marketplace is an emerging aspect of the Non-RT RIC ecosystem. Analogous to mobile app stores, the marketplace would allow operators to discover, evaluate, and deploy rApps from multiple vendors. The O-RAN Alliance’s rApp descriptor format includes metadata fields for certification status, compatibility, and performance benchmarks that support marketplace-style discovery.

10.6 Non-RT RIC Platform Services

10.7 Use Cases

Energy Saving

Energy consumption accounts for 20–40% of an operator’s total network operating expenditure. The Non-RT RIC’s energy saving rApp analyzes historical traffic patterns (collected via O1 PM counters) and external data (weather forecasts, event schedules) to determine when cells or carriers can be safely deactivated without degrading user experience.

RAN Slicing SLA Assurance

Network slicing enables operators to create logically isolated network partitions, each with its own performance guarantees. The Non-RT RIC’s slicing rApp monitors slice-level KPIs (throughput, latency, reliability) against SLA thresholds. When a slice approaches SLA violation, the rApp issues A1 policies to the Near-RT RIC that trigger resource rebalancing, admission control tightening, or traffic steering adjustments.

Coverage Optimization

Coverage optimization rApps consume Minimization of Drive Tests (MDT) data, user complaint records, and geo-spatial information to identify coverage gaps and overshooting cells. The rApp computes optimal antenna tilt and power settings, then pushes these as A1 policies or O1 configuration changes. Over time, the ML-based approach learns site-specific propagation characteristics and converges on configurations that outperform manual optimization.

10.8 Non-RT RIC and Near-RT RIC Coordination

The relationship between the Non-RT RIC and Near-RT RIC is hierarchical but collaborative. The Non-RT RIC provides strategic direction; the Near-RT RIC provides tactical execution. This division mirrors the temporal decomposition of RAN optimization: long-term trends require different algorithms and data than sub-second radio resource decisions.

11.1 Near-RT RIC Architecture

The Near-Real-Time RAN Intelligent Controller (Near-RT RIC) is the execution platform for fine-grained radio resource management within a 10 ms to 1 second control loop. It hosts xApps—modular applications that receive real-time data from E2 nodes (O-CU-CP, O-CU-UP, O-DU), perform analytics or inference, and issue control actions back to those nodes. The Near-RT RIC is specified in O-RAN.WG3.RICARCH-v03.00 and represents the most architecturally novel component of the O-RAN system.

The platform consists of several core components:

• E2 Termination: Terminates SCTP connections from E2 nodes and handles E2AP message encoding/decoding. Maintains the E2 node table tracking all connected RAN elements.
• Subscription Manager: Manages E2 subscriptions on behalf of xApps. Routes E2 Indications to the correct xApp based on subscription matching. Handles subscription merging when multiple xApps request the same data from the same E2 node.
• Conflict Mitigation: Resolves conflicting control actions from multiple xApps before they reach E2 nodes. Uses priority-based, policy-based, or ML-based arbitration strategies.
• Shared Data Layer (SDL): A high-performance, in-memory key-value store (typically Redis-based) shared across all xApps. Provides sub-millisecond read/write access for UE context, cell state, and xApp coordination data.
• RIC Message Router (RMR): A lightweight, low-latency message bus for inter-xApp communication and platform-to-xApp messaging. Uses message type routing rather than topic-based pub/sub for deterministic latency.
• A1 Termination: Receives policies, enrichment information, and ML models from the Non-RT RIC via A1 and makes them available to xApps through SDL and RMR.
• xApp Manager: Handles xApp lifecycle—onboarding, deployment, health monitoring, scaling, and termination.

11.2 E2 Interface Deep Dive

The E2 interface connects the Near-RT RIC to E2 nodes—O-CU-CP, O-CU-UP, and O-DU. It uses the E2 Application Protocol (E2AP), defined in O-RAN.WG3.E2AP-v03.00, which runs over SCTP for reliable, ordered message delivery. E2AP defines a set of elementary procedures for setup, subscription, control, and reporting.

11.3 E2 Service Models

E2 Service Models (E2SMs) define the semantics of what data the Near-RT RIC can subscribe to and what control actions it can issue. They are pluggable: an E2 node advertises which E2SMs it supports during E2 Setup, and xApps subscribe only to service models relevant to their function.

11.4 xApp Development

xApps are developed using the Near-RT RIC SDK, which provides libraries for RMR communication, SDL access, E2 subscription management, logging, and configuration. The O-RAN Software Community (OSC) provides reference SDKs in C, C++, Go, and Python.

11.5 xApp Lifecycle Management

The xApp lifecycle closely parallels the rApp lifecycle in the Non-RT RIC but operates at a different scale. xApps are packaged as Helm charts containing the container image, configuration, and an xApp descriptor that declares E2 subscriptions, RMR message types, and resource requirements. The xApp Manager handles onboarding (validating the descriptor and pushing the Helm chart to the chart repository), deployment (instructing Kubernetes to create pods), subscription registration (connecting the xApp to E2 data streams), and termination (gracefully removing subscriptions before pod deletion).

11.6 Conflict Mitigation

When multiple xApps issue control actions that affect the same E2 node, cell, or UE, conflicts can arise. For example, a traffic steering xApp might want to hand over UE X to Cell A, while a load balancing xApp simultaneously wants to prevent any new UEs from entering Cell A. The conflict mitigation module resolves such conflicts before the control actions reach the E2 node.

11.7 Use Cases

Traffic Steering: An xApp monitors per-UE throughput and load across neighboring cells via E2SM-KPM. When a UE experiences degraded service, the xApp issues a handover command via E2SM-RC to steer the UE to a less congested cell. The xApp uses ML models (deployed via A1-ML) to predict which target cell will provide the best post-handover experience. Field trials by Vodafone and Samsung have demonstrated 15–25% throughput improvements for cell-edge users.

Interference Management: In dense urban deployments with overlapping small cells, inter-cell interference is the primary throughput limiter. An interference management xApp subscribes to CQI and RSRP measurements via E2SM-KPM, identifies interferer-victim cell pairs, and uses E2SM-RC to coordinate power adjustments and scheduling constraints. This is particularly valuable for TDD networks where cross-slot interference from different cells can be catastrophic.

Handover Optimization: Traditional handover algorithms use fixed A3 event thresholds that do not adapt to dynamic conditions. An xApp can subscribe to E2SM-RC INSERT actions for handover decisions, evaluate each pending handover against ML-based predictions of target cell quality, and redirect handovers to optimal targets. This reduces ping-pong handovers by 30–50% in dense heterogeneous networks.

Load Balancing: A load balancing xApp monitors PRB utilization, connected UE counts, and throughput across a cluster of cells. When imbalance exceeds a threshold (e.g., one cell at 90% PRB utilization while a neighbor is at 40%), the xApp adjusts Cell Individual Offsets (CIO) or handover parameters via E2SM-RC to redistribute traffic.

11.8 Near-RT RIC Performance Requirements

The Near-RT RIC must operate within strict latency and scalability bounds to be effective. The O-RAN Alliance specifies the following performance targets:

• Control loop latency: End-to-end from E2 indication receipt to E2 control request transmission must be less than 10 ms for time-critical use cases (e.g., handover optimization) and less than 1 second for the general case.
• E2 indication throughput: The platform must process at minimum 10,000 indications per second per E2 node, scaling to millions per second for large-scale deployments.
• SDL access latency: Read and write operations to the shared data layer must complete within 1 ms (p99) to avoid becoming a bottleneck in the control loop.
• xApp density: The platform must support at least 10 concurrently running xApps, with isolation guarantees preventing a misbehaving xApp from impacting others.
• E2 node capacity: A single Near-RT RIC instance should support up to 1,000 E2 node connections, covering a metropolitan-scale deployment.

12.1 O-Cloud Concept

O-Cloud is the cloud computing platform that hosts O-RAN network functions—the O-CU-CP, O-CU-UP, O-DU, and Near-RT RIC—on commercial off-the-shelf (COTS) hardware. It represents the most fundamental departure from traditional RAN architecture: replacing purpose-built, vendor-specific hardware with general-purpose servers running containerized or virtualized workloads orchestrated by Kubernetes.

The O-Cloud concept is defined by O-RAN WG6 (Cloudification and Orchestration) and addresses three core challenges:

• Real-time performance on general-purpose hardware: RAN signal processing (particularly L1 PHY) has historically required custom ASICs or DSPs. O-Cloud must provide mechanisms to achieve comparable performance on x86/ARM servers through hardware acceleration and real-time kernel configurations.
• Multi-vendor workload hosting: O-Cloud must run network functions from different vendors simultaneously on shared infrastructure, with appropriate isolation, security, and resource guarantees.
• Lifecycle management at scale: A single operator may deploy thousands of O-Cloud nodes across cell sites, aggregation points, and data centers. Automated provisioning, monitoring, scaling, and healing are essential.

12.2 O-Cloud Architecture

The O-Cloud architecture is organized into layers and managed through two principal service interfaces:

12.3 Kubernetes for RAN

Standard Kubernetes was designed for IT workloads—web services, databases, batch processing—where microsecond-level jitter is irrelevant. RAN workloads, particularly the O-DU’s L1/L2 processing, have fundamentally different requirements: deterministic scheduling, memory pinning, CPU isolation, and direct hardware access for accelerators and high-speed NICs. Adapting Kubernetes for RAN requires several extensions:

• RT-PREEMPT kernel: The Linux PREEMPT_RT patch set provides deterministic scheduling with worst-case interrupt latencies below 10 µs, essential for meeting fronthaul timing deadlines.
• CPU Manager (static policy): Kubernetes CPU Manager with the static policy assigns exclusive CPUs to containers requesting guaranteed QoS, preventing context switches from disrupting real-time processing.
• Hugepages: 1 GB hugepages eliminate TLB misses for large memory allocations used by DPDK and L1 processing, reducing memory access latency by 50–80%.
• DPDK (Data Plane Development Kit): Bypasses the kernel network stack for user-space packet processing. Essential for fronthaul eCPRI packet handling at 25 Gbps line rate.
• SR-IOV (Single Root I/O Virtualization): Presents virtual functions (VFs) of a physical NIC directly to containers, achieving near-native network I/O performance without the overhead of virtual bridges.
• NUMA topology awareness: Ensures that containers are scheduled on the same NUMA node as their allocated CPUs, memory, and PCI devices to avoid cross-NUMA penalties (30–50% latency increase).
• PTP (Precision Time Protocol): IEEE 1588 PTP hardware timestamping provides sub-microsecond synchronization required by Open Fronthaul.

12.4 Hardware Acceleration

The most computationally intensive RAN function is L1 PHY processing—particularly forward error correction (FEC) encoding/decoding (LDPC for 5G NR) and FFT/iFFT for OFDM signal processing. On a pure-CPU implementation, a single 100 MHz 5G NR carrier with 4T4R MIMO can consume 8–12 CPU cores. Hardware acceleration offloads these operations to specialized silicon.

12.5 Container Network Functions (CNFs)

The evolution from VNFs (Virtual Network Functions running on VMs) to CNFs (Container Network Functions running in containers) represents a generational shift in RAN software packaging and deployment.

The advantages of CNFs over VNFs for RAN workloads include:

• Faster scaling: Container startup in seconds versus VM boot in minutes, enabling rapid capacity scaling during traffic spikes.
• Resource efficiency: No hypervisor overhead (typically 5–15% CPU and memory tax). Containers share the host kernel.
• Microservice decomposition: L1 PHY, L2 MAC/RLC, and L3 RRC/PDCP can be packaged as separate containers, enabling independent scaling and upgrade.
• CI/CD integration: Container images fit naturally into DevOps pipelines for continuous testing and deployment.
• Portability: OCI-compliant containers run identically across any O-Cloud node, from edge to central.

12.6 O2 Interface

The O2 interface, defined in O-RAN.WG6.O2-GA&P-v03.00, connects the O-Cloud to the SMO. It is divided into two service categories:

O2-IMS (Infrastructure Management Services) enables the SMO to discover, provision, monitor, and manage the physical and virtual infrastructure. This includes server inventory, resource pool management, firmware updates, alarm forwarding, and cluster lifecycle (creating and deleting Kubernetes clusters on bare-metal servers).

O2-DMS (Deployment Management Services) enables the SMO to deploy, scale, update, and terminate O-RAN NFs on the O-Cloud infrastructure. This is implemented through the Kubernetes API, with the O2-DMS acting as an abstraction layer that translates SMO deployment requests into Helm chart operations or native Kubernetes API calls.

12.7 Edge Computing

Edge computing pushes O-Cloud nodes closer to the radio site—into street cabinets, on rooftops, or in micro data centers within buildings. This is essential for the O-DU, which must maintain sub-millisecond fronthaul latency to the O-RU, and increasingly valuable for hosting Multi-access Edge Computing (MEC) applications alongside RAN functions.

12.8 O-Cloud Reference Designs (WG6/WG7)

O-RAN WG6 (Cloudification and Orchestration) and WG7 (White-box Hardware) jointly develop reference designs for O-Cloud infrastructure. These reference designs specify server hardware configurations, accelerator integration, OS and Kubernetes configurations, and performance benchmarks that serve as blueprints for O-Cloud deployments.

13.1 Introduction to Open Fronthaul

The Open Fronthaul interface connects the O-DU to the O-RU, replacing proprietary CPRI links with an open, multi-vendor specification. Defined primarily by WG4, it is the most technically demanding O-RAN interface because it must transport time-critical IQ sample data with sub-microsecond precision while simultaneously supporting management operations.

Functionality splits into two planes:

• CUS-Plane (Control, User, and Synchronization): Real-time IQ data, scheduling commands, and synchronization over eCPRI with 100–250 μs one-way latency requirements.
• M-Plane (Management Plane): O-RU configuration, software download, fault supervision, and performance monitoring via NETCONF/YANG over SSH.

13.2 eCPRI Transport Protocol

The enhanced Common Public Radio Interface (eCPRI) replaces legacy CPRI with a packet-based protocol over Ethernet (L2) or IP/UDP (L3), enabling statistical multiplexing and standard Ethernet switching in the fronthaul.

13.3 CUS-Plane Section Types

The C-Plane carries scheduling and beamforming commands structured as “sections”, each describing a contiguous PRB block:

13.4 Beamforming Weight Delivery

Massive MIMO arrays (32T32R, 64T64R) require per-PRB beamforming weights delivered in real time. Two approaches:

• Category A (Beam Index): O-DU sends a beam index referencing a pre-loaded weight table in the O-RU. Bandwidth-efficient but limited to codebook-based beamforming.
• Category B (Explicit Weights): O-DU sends complex weights via Section Extension extType=1. Fully adaptive but bandwidth-intensive.

13.5 IQ Sample Compression

Raw IQ samples at 16 bits per component produce substantial bandwidth requirements. Supported compression methods:

• Block Floating Point (BFP): 12 IQ samples share a common exponent. BFP-9 achieves ~2:1 compression with minimal EVM impact.
• Block Scaling: Scaling factor instead of exponent; lower O-RU complexity.
• Mu-law: Logarithmic companding for high dynamic range.
• Modulation Compression: Exploits known DL constellation. DL-only.

13.6 Timing and Synchronization

Two synchronization models:

• LLS-C1 (Category A): O-RU recovers clock from PTP (IEEE 1588v2) over fronthaul Ethernet. Requires PTP-aware switches.
• LLS-C2 (Category B): SyncE for frequency, PTP for phase. Better holdover during congestion.

13.7 M-Plane Operations

The M-Plane uses NETCONF (RFC 6241) with YANG data models. Two architectures:

• Hierarchical: O-DU acts as NETCONF client managing its O-RUs directly. Simpler but limited scope.
• Hybrid: SMO manages O-RUs via O1; O-DU handles time-sensitive M-Plane ops. Centralised visibility.

Key operations: software management (dual-bank firmware upgrades), carrier configuration, compression negotiation, delay management (T2a/Ta3 exchange), and supervision watchdog heartbeats.

14.1 E2 Interface Overview

The E2 interface is the southbound connection from the Near-RT RIC to E2 Nodes—the O-CU-CP, O-CU-UP, and O-DU. It enables the Near-RT RIC to monitor RAN conditions in near-real-time (10 ms to 1 s) and issue control actions that directly affect radio resource management. The E2 interface is defined by WG3 and consists of two layers: the E2 Application Protocol (E2AP) and E2 Service Models (E2SM).

This two-layer design is critical: E2AP provides the generic transport mechanism (subscribe, indicate, control), while E2SMs define what specific RAN information can be monitored or controlled. An xApp that needs KPI data uses E2SM-KPM; an xApp that needs to modify RAN parameters uses E2SM-RC. The E2AP procedures remain identical regardless of the service model.

14.2 E2AP Protocol

The E2 Application Protocol defines eight core procedures grouped into three categories:

All E2AP messages use ASN.1 with Packed Encoding Rules (PER), transported over SCTP. SCTP provides reliable, ordered, multi-stream delivery—critical for separating control and data streams on the same connection.

14.3 E2 Service Models

E2 Service Models define the semantics of what can be monitored or controlled through E2. Each E2SM specifies RAN Function descriptions, Event Triggers, Action Definitions, Indication Messages, and Control Messages. The major standardised E2SMs are:

14.4 E2SM-KPM: KPI Monitoring

E2SM-KPM (Key Performance Measurement) is the most widely implemented service model. It allows xApps to subscribe to RAN measurements at cell, UE, or bearer granularity. The subscription specifies a reporting period (e.g., every 100 ms) and a list of measurement IDs referencing 3GPP-defined counters (from TS 28.552). The E2 Node collects the requested measurements and delivers them via RIC Indication REPORT messages.

14.5 E2SM-RC: RAN Control

E2SM-RC gives xApps the ability to actively modify RAN behaviour. It supports four control styles:

• Radio Bearer Control: Modify QoS parameters for specific bearers or QoS flows.
• Radio Resource Allocation Control: Adjust PRB allocation, scheduling weights, and MCS strategies.
• Connected Mode Mobility Control: Override handover decisions—the xApp intercepts the handover event via INSERT indication and responds with the target cell.
• Radio Access Control: Manage RACH parameters, cell barring, and access control.

14.6 E2 Node Capabilities and Setup

During E2 Setup, each E2 Node advertises its capabilities to the Near-RT RIC: which E2SMs it supports, what RAN Functions it exposes, and the RAN Function definitions describing available measurements and control actions. The Near-RT RIC uses this information to route xApp subscription requests to the appropriate E2 Nodes.

14.7 xApp Design Patterns

Effective xApp development follows several patterns:

• Monitor-then-Act: Subscribe to E2SM-KPM for data, analyse patterns, then issue E2SM-RC controls. Most common pattern for traffic steering and load balancing.
• Interceptor: Use INSERT indications to intercept RAN decisions (handovers, bearer modifications) and override them. Requires tight latency budgets.
• Policy Executor: Receive A1 policies from the Non-RT RIC and translate them into E2 control actions. Bridges strategic intent to tactical execution.
• Conflict-Aware: Register with the Conflict Mitigation module in the Near-RT RIC to prevent contradictory control actions from multiple xApps targeting the same cell or UE.

15.1 A1 Interface Architecture

The A1 interface is the southbound interface from the Non-RT RIC to the Near-RT RIC. While Chapter 10 introduced A1 in the context of Non-RT RIC architecture, this chapter provides a deep dive into the protocol mechanics, policy lifecycle, and implementation considerations. A1 bridges the strategic intelligence layer (>1 s timescale) to the tactical execution layer (10 ms–1 s), making it the primary channel through which operator intent reaches the RAN control plane.

The A1 protocol uses RESTful HTTP/JSON for all three services. The Near-RT RIC exposes A1 endpoints that the Non-RT RIC (as client) invokes. This is notably different from E2, which uses ASN.1/SCTP—A1’s choice of REST reflects its longer timescales and simpler message semantics.

15.2 A1 Policy Lifecycle

An A1 policy goes through a well-defined lifecycle:

• Creation: The Non-RT RIC (on behalf of an rApp) sends a PUT request with the policy type ID, policy instance ID, and JSON policy body to the Near-RT RIC.
• Distribution: The Near-RT RIC’s A1 Mediator stores the policy in the Shared Data Layer (SDL/Redis) and notifies subscribed xApps.
• Enforcement: The responsible xApp reads the policy, translates it into E2 control actions, and begins enforcing it on the RAN.
• Status Reporting: The xApp reports enforcement status (ENFORCED, NOT_ENFORCED, or UNDEFINED) back through the A1 Mediator to the Non-RT RIC.
• Update: The Non-RT RIC can update the policy by sending a new PUT with the same instance ID but modified parameters.
• Deletion: DELETE request removes the policy; the xApp ceases enforcement and reverts to default behaviour.

15.3 Policy Type Schema

Each A1 policy type is identified by a numeric Policy Type ID and defined by a JSON Schema that specifies the allowed parameters, their types, ranges, and defaults. The schema is registered in both the Non-RT RIC and Near-RT RIC during deployment.