PaperlayerView exact revision on arXiv

Source-linked AI summary

Understanding O-RAN: Architecture, Interfaces, Algorithms, Security, and Research Challenges

Michele Polese, Leonardo Bonati, Salvatore D'Oro, Stefano Basagni, Tommaso Melodia

arXiv:2202.01032v2cs.NIeess.SP

TL;DR

Existing O-RAN literature introduces selected building blocks or summarizes particular architectural elements, while a detailed account connecting the specifications and broader research topics was lacking. This paper analyzes O-RAN specifications, architecture, interfaces, workflows, security, platforms, and early research, providing a comprehensive overview and identifying open research questions.

  • Problem

    Existing O-RAN papers focus on building blocks, architecture, or selected elements, leaving a detailed account connecting specifications, interfaces, use cases, security, deployment, and research absent.

    Source: §I · p. 2

  • Method

    The paper analyzes O-RAN specifications, architecture, interfaces, ML and closed-loop workflows, security, experimental platforms, recent research, and future issues.

    Source: §I · p. 2

  • Results

    The paper provides a comprehensive overview of O-RAN specifications, architectures, operations, workflows, use cases, security, standardization, platforms, and future research.

    Source: §XII · p. 25

  • Takeaways & Limitations

    Effective O-RAN deployment remains an open research question, including element distribution across edge and cloud and the ratio of RAN nodes to RIC elements.

    Source: §XI · p. 25

Abstract

from arXiv · show

The Open Radio Access Network (RAN) and its embodiment through the O-RAN Alliance specifications are poised to revolutionize the telecom ecosystem. O-RAN promotes virtualized RANs where disaggregated components are connected via open interfaces and optimized by intelligent controllers. The result is a new paradigm for the RAN design, deployment, and operations: O-RAN networks can be built with multi-vendor, interoperable components, and can be programmatically optimized through a centralized abstraction layer and data-driven closed-loop control. Therefore, understanding O-RAN, its architecture, its interfaces, and workflows is key for researchers and practitioners in the wireless community. In this article, we present the first detailed tutorial on O-RAN. We also discuss the main research challenges and review early research results. We provide a deep dive of the O-RAN specifications, describing its architecture, design principles, and the O-RAN interfaces. We then describe how the O-RAN RAN Intelligent Controllers (RICs) can be used to effectively control and manage 3GPP-defined RANs. Based on this, we discuss innovations and challenges of O-RAN networks, including the Artificial Intelligence (AI) and Machine Learning (ML) workflows that the architecture and interfaces enable, security and standardization issues. Finally, we review experimental research platforms that can be used to design and test O-RAN networks, along with recent research results, and we outline future directions for O-RAN development.

I. INTRODUCTION · II. O-RAN KEY ARCHITECTURAL PRINCIPLES · A. Disaggregation

The paper presents O-RAN as an open, disaggregated approach to making RANs more configurable and data-driven, and provides a detailed account of its architecture, interfaces, workflows, research platforms, and challenges.

I. INTRODUCTION

  • Rising network complexity and black-box, monolithic RANs constrain reconfiguration, coordination, and vendor choice, making real-time resource optimization difficult.Heterogeneous technologies and bands increase operators’ capital and operational costs, while closed implementations limit adaptation to deployments and traffic profiles.Source: §I · p. 1
  • Open RAN counters these limits with disaggregated, virtualized components and standardized interfaces, enabling flexible deployments, multi-vendor ecosystems, and data-driven closed-loop control.The paper describes O-RAN’s implementation over 3GPP LTE and NR, including the CU/DU/RU split and near-real-time and non-real-time RICs.Source: §I · p. 1
  • The article provides a detailed survey of O-RAN specifications, components, interfaces, AI/ML workflows, security, experimental platforms, research results, and future directions.It distinguishes itself by detailing the full RIC and interface specifications and how controller logic can control 3GPP-defined network elements.Source: §I · p. 2

II. O-RAN KEY ARCHITECTURAL PRINCIPLES

  • Open RAN’s four foundational principles are disaggregation, intelligent data-driven control with RICs, virtualization, and open interfaces.The paper situates these principles in a broader shift toward open and programmable wireless networks.Source: §II · pp. 2–3

A. Disaggregation

  • O-RAN disaggregates each gNB into CU, DU, and RU units, with the CU divided into control-plane and user-plane components deployable across different locations and hardware.CUs and DUs can run as virtualized software on edge white-box servers, while RUs are typically FPGA- or ASIC-based and located near antennas.Source: A. Disaggregation · p. 3
  • The selected 7.2x split balances RU simplicity against RU–DU interface data-rate and latency requirements.The RU performs FFT and cyclic-prefix addition or removal; the DU handles the remaining physical-layer functions plus MAC and RLC, whose operations are tightly synchronized.Source: A. Disaggregation · p. 3
  • The CU implements RRC, SDAP, and PDCP, covering connection lifecycle, traffic-flow QoS, and functions including reordering, packet duplication, and air-interface encryption.These higher-layer functions are separated from the DU’s physical, MAC, and RLC responsibilities.Source: A. Disaggregation · p. 3

B. RAN Intelligent Controllers and Closed-Loop Control · C. Virtualization · D. Open Interfaces

O-RAN uses RICs and open interfaces to enable data-driven control across disaggregated RAN components, while O-Cloud virtualization pools compute resources and supports flexible deployment and scaling.

B. RAN Intelligent Controllers and Closed-Loop Control

  • RICs use streamed RAN measurements and external context for AI/ML-driven closed-loop control; non-RT loops exceed 1 s, near-RT loops span 10 ms to 1 s, and faster loops remain future work.Future real-time extensions below 10 ms include scheduling and beam management, but are not part of the current O-RAN architecture.Source: B. RAN Intelligent Controllers and… · pp. 3–4
  • The non-RT RIC in the SMO provides guidance, enrichment information, and ML-model management to the near-RT RIC, and can influence thousands of devices through SMO operations.This broad reach presents scalability challenges requiring efficient process and software design.Source: B. RAN Intelligent Controllers and… · p. 4
  • At the network edge, the near-RT RIC controls DUs, CUs, and legacy eNBs through xApps, which process RAN data and send actions using shared data, messaging, open interfaces, and conflict resolution.A near-RT RIC can serve multiple RAN nodes and affect the QoS of hundreds or thousands of UEs.Source: B. RAN Intelligent Controllers and… · p. 4

C. Virtualization

  • O-Cloud pools datacenter computing, virtualization, software, and orchestration resources to decouple hardware and software, standardize capabilities, share hardware across tenants, and automate RAN-function deployment.O-Cloud can host all O-RAN architecture components.Source: C. Virtualization · p. 4
  • WG6 develops AAL APIs between dedicated processors and O-RAN software for coding and FEC, while WG7 specifies white-box node scenarios and hardware parameters; commercial accelerated virtualized RANs target NR use cases such as URLLC.The paper also notes FPGA-based physical-layer decoding tested with an OpenAirInterface prototype.Source: C. Virtualization · p. 4
  • Virtualization can dynamically scale compute to user requirements and, together with closed-loop control, enable refined base-station and RF-component sleep cycles to reduce power consumption.The paper identifies base stations and RF components as generally responsible for most cellular-network power consumption.Source: C. Virtualization · pp. 4–5

D. Open Interfaces

  • O-RAN open interfaces expose telemetry and analytics for RIC control and automation, complement DU–RU fronthaul and 3GPP intra-RAN interfaces, and help break vendor lock-in by enabling cross-vendor interoperability.Standardization also fosters competition, innovation, faster upgrade cycles, and introduction of softwarized RAN components.Source: D. Open Interfaces · p. 5
  • E2 carries RAN telemetry and near-RT control, A1 delivers policies and models, O1 manages RAN components, O2 links the SMO and non-RT RIC to O-Cloud, and fronthaul connects DUs and RUs.Open interfaces also permit different cloud, edge, and cell-site deployment arrangements, including co-located RICs and RAN nodes.Source: D. Open Interfaces · p. 5

III. NEAR-RT RIC, XAPPS, AND CONTROL OF THE RAN … IV. NON-RT RIC AND ORCHESTRATION FRAMEWORK

The near-RT RIC hosts xApps and interface terminations for RAN control, while the SMO hosts the non-RT RIC and provides orchestration, management, and automation. The sections describe their components, implementations, interfaces, and unresolved boundaries between SMO and non-RT RIC functions.

III. NEAR-RT RIC, XAPPS, AND CONTROL OF THE RAN

  • The near-RT RIC hosts O1, A1, and E2 terminations, xApps, and their management components; OSC provides a Kubernetes-based microservices reference implementation without prescribing implementation requirements.Specifications define component requirements and services, not implementation requirements.Source: §III · p. 5

A. Near-RT RIC Internal Components

  • Internal messaging supports endpoint registration and discovery, message routing, and point-to-point or publish/subscribe communication, while subscription management governs xApp access to E2 messages and merges identical requests.The specifications do not mandate a messaging technology; OSC uses RMR.Source: A. Near-RT RIC Internal Components · pp. 5–6
  • Conflict mitigation addresses xApps’ conflicting control actions: direct conflicts can be resolved before action, while indirect or implicit conflicts require post-action performance monitoring; OSC did not include this component at the time of writing.Conflicts can affect users, bearers, or cells and may degrade performance.Source: A. Near-RT RIC Internal Components · p. 6
  • The security subsystem aims to prevent malicious xApps from leaking sensitive RAN data or harming performance, while the R-NIB and UE-NIB store node and UE information accessible through SDL APIs.UE identities enable UE-specific control but can expose sensitive information and correlate a user across E2 nodes.Source: A. Near-RT RIC Internal Components · p. 6
  • Near-RT RIC services manage xApp onboarding, deployment, termination, tracing, and logging; OSC implements these functions through Kubernetes wrappers.Lifecycle termination can be triggered by the SMO, and tracing and logging cover FCAPS.Source: A. Near-RT RIC Internal Components · p. 6

B. Near-RT RIC xApps

  • xApps are plug-and-play components for RAN analysis and control that receive RAN data and telemetry and return control over E2; their descriptors specify deployment parameters, consumed data types, and control capabilities.In OSC, xApps are Docker images deployed on Kubernetes using a descriptor schema.Source: B. Near-RT RIC xApps · p. 6
  • Near-RT RIC specifications mandate only a limited xApp API set, while a broader SDK could improve portability across implementations; TIP RIA has promoted work in this direction.The mandated APIs include SDL and registration, discovery, and subscription APIs.Source: B. Near-RT RIC xApps · pp. 6–7

C. Open Source Near-RT RIC Implementations

  • Open-source implementations include OSC-based ColO-RAN, ONOS-based SD-RAN with an SDK, monolithic FlexRIC with specialized-controller tooling, and heterogeneous-RAN 5G-EmPOWER.Their capabilities include standard or custom service models, RAN monitoring and slicing, and Wi-Fi/cellular mobility management.Source: C. Open Source Near-RT RIC… · p. 7

A. Non-real-time RIC · B. Other SMO/Non-RT RIC functionalities · C. SMO Framework and Open Source SMO Implementations

The non-RT RIC and SMO provide higher-timescale RAN control, orchestration, data and AI/ML capabilities, while open-source platforms are being integrated to support O-RAN management and automation.

A. Non-real-time RIC

  • The non-RT RIC supports closed-loop RAN control above 1 s and hosts rApps that provide value-added services for RAN optimization and operations.These services include policy guidance, enrichment information, configuration management and data analytics.Source: A. Non-real-time RIC · p. 7
  • Through R1 and internal messaging, rApps access non-RT RIC services and interfaces, deriving higher-level policies for broader groups of users and network nodes than xApps.Examples include frequency and interference management, RAN sharing, performance diagnostics, SLA assurance and network slicing.Source: A. Non-real-time RIC · pp. 7–8
  • Intent-based management parses operator intents expressed in a high-level language into policies and the rApps and xApps needed to satisfy them.Intents may be formalized in YAML or XML configuration files.Source: A. Non-real-time RIC · p. 8
  • The non-RT RIC orchestrates network intelligence by selecting and placing suitable rApps and xApps, supplying relevant data, and preventing control conflicts.For example, near-real-time scheduling control requires selecting capable xApps at the appropriate near-RT RICs for the target base stations.Source: A. Non-real-time RIC · p. 8

B. Other SMO/Non-RT RIC functionalities

  • SMO internal messaging connects components and interface terminations, allowing policies from rApps to pass through R1 and reach the near-RT RIC via A1.The infrastructure lets SMO and non-RT RIC components access interfaces, data and functionalities across both domains.Source: B. Other SMO/Non-RT RIC functionalities · p. 8
  • SMO/non-RT RIC data services let producers publish data for consumer discovery and subscription, while supporting collection and AI/ML preprocessing and lifecycle oversight.Preprocessing may include analytics, labeling and normalization; the AI/ML workflow spans collection, training, validation, deployment and execution.Source: B. Other SMO/Non-RT RIC functionalities · p. 8

C. SMO Framework and Open Source SMO Implementations

  • The SMO manages the O-Cloud and other O-RAN components through O2 and O1, and provides FCAPS management, inventory, topology, configuration and policy management.These functions support network orchestration services.Source: C. SMO Framework and Open Source SMO… · p. 8
  • ONAP and OSM are open-source automation platforms being integrated with O-RAN; ONAP is the OSC’s preferred platform, while OSM integration remains early.ONAP offers broad native integrations in a more complex environment, whereas OSM provides similar services in a lighter framework; O-RAN SMO integration is still at an early stage.Source: C. SMO Framework and Open Source SMO… · pp. 8–9

V. THE O-RAN OPEN INTERFACES · A. E2 Interface

O-RAN interfaces enable RIC control loops through standardized services and procedures; E2 connects the near-RT RIC with RAN nodes for control and metric collection.

V. THE O-RAN OPEN INTERFACES

  • Standardized interface procedures exchange endpoint messages to provide services such as RAN telemetry reporting and E2 subscription and indication.The section frames these abstractions and procedures as enabling near-RT and non-RT RIC control loops.Source: §V · p. 9

A. E2 Interface

  • E2 connects the near-RT RIC to DUs, CUs, and O-RAN-compliant LTE eNBs, enabling RAN control and periodic or event-triggered metrics collection across cells, slices, QoS classes, or UEs.O-RAN uses 3GPP-based identifiers for gNBs, slices, and QoS classes, plus a common UE-ID that avoids exposing sensitive user information.Source: A. E2 Interface · p. 9
  • E2AP coordinates communication and carries E2 service-model payloads over SCTP, while E2 nodes publish supported RAN functions for xApps to subscribe to.E2 setup establishes SCTP, has the node advertise its functions and configuration, and receives a setup response from the near-RT RIC.Source: A. E2 Interface · p. 9
  • E2 report subscriptions configure periodic or trigger-based telemetry; E2 insert subscriptions notify xApps of events and can suspend a RAN procedure pending RIC response.Periodic reports follow a timer; inserts include a wait timer after which the E2-node procedure may resume or halt.Source: A. E2 Interface · pp. 9–10
  • E2 control uses a RIC Control Request and reciprocal Acknowledge to influence exposed E2-node RAN-function parameters; E2 policy subscriptions specify an event trigger and autonomous radio-resource-management policy.The service-model message is carried as payload in an E2AP message.Source: A. E2 Interface · p. 10
  • The standardized E2SMs include KPM for RAN performance reporting, NI for forwarding X2, Xn, and F1 interface messages, and RC for control functions.KPM subscriptions select metrics and reporting mode; Version 2 adds cell- and user-specific containers, while NI advertises supported interfaces during subscription.Source: A. E2 Interface · pp. 10–11
  • E2SM RC specifies radio-bearer, radio-resource-allocation, connected-mode mobility, radio-access, and idle-mobility control; actions generally carry values for 3GPP information elements, including a target-cell identifier for handover [94, 97, Section 9.2.3.25].It also provides UE identification and information reporting; resource allocation can target an E2 node, cell, slice, UE, or QoS class.Source: A. E2 Interface · p. 11
  • In an RC control loop, an xApp subscription can set a trigger or timer; an insert may suspend RAN management until the RIC denies or accepts control, while timeout permits autonomous continuation or halt.RC also supports asynchronous control and policies for autonomous actions or for offsetting 3GPP- or vendor-defined thresholds.Source: A. E2 Interface · p. 11, Figure 9 · p. 11

B. O1 Interface · O1 Interface

O1 connects O-RAN-managed components and RAN nodes to the SMO and non-RT RIC through an open interface for operations and maintenance. Its Management Services support component management, fault and performance reporting, and configuration and software management.

B. O1 Interface

O1 Interface

  • Figure 10 depicts the O1 Management Services payload encapsulated in HTTPS/TCP/IP packets.Source: Figure 10 · p. 12, O1 Interface · p. 12
  • O1 Management Services cover component life-cycle management, performance assurance, trace collection, and software and file management, with a node typically providing services to the SMO.The SMO is generally the MnS consumer and the managed node is the provider.Source: O1 Interface · p. 12
  • Provisioning services let the SMO push configurations and receive external configuration updates using REST/HTTPS APIs and NETCONF.Supported provisioning services include those defined in 3GPP specifications.Source: O1 Interface · p. 12
  • Fault Supervision reports errors and events to the SMO through REST APIs using standardized JSON payloads based on 3GPP-defined fault events.The SMO can query node alarms and acknowledge or clear them.Source: O1 Interface · p. 12
  • The SMO can provision heartbeats to monitor service and node status and availability, and O1 supports management of virtual and physical network functions.Source: O1 Interface · p. 12
  • Performance Assurance streams data in real time or reports it in bulk by file transfer, with the SMO selecting reported KPIs and reporting frequency.KPI reporting formats rely on 3GPP use cases and formats or VES; metrics may be 3GPP-based, vendor-specific, or O-RAN-standardized.Source: O1 Interface · p. 12

A1 Interface · C. A1 Interface · D. O-RAN Fronthaul

A1 connects the non-RT and near-RT RICs for policy guidance, ML-model management, and enrichment-information exchange, while O-RAN fronthaul splits PHY functions between the DU and RU and defines the planes that coordinate their data, control, synchronization, and management.

A1 Interface

  • A1 uses JSON payloads encapsulated in HTTPS/TCP/IP, and O1 supports file transfers, real-time streaming, and trace-based monitoring.O1 file operations can support software updates, beamforming configuration files, ML-model deployment, and security certificates.Source: Figure 11 · p. 12, A1 Interface · p. 12

C. A1 Interface

  • The non-RT RIC uses A1 to set high-level RAN intent, manage policies, and coordinate near-RT RIC ML models and enrichment information; A1-based ML-model management remains for further study.Policies can target individual UEs or groups, while policy status feedback can report only whether a policy is enforced. The non-RT RIC can update, delete, and query policies over their lifecycle.Source: C. A1 Interface · pp. 12–13
  • A1 policies use JSON schemas with identifiers, scopes, and statements defining resource conditions or QoS/KPI objectives, including use cases such as throughput maximization and traffic steering.Scopes can cover a UE, UE group, slice, cell, bearer, or application class.Source: C. A1 Interface · p. 13
  • A1 enrichment information supplies near-RT RIC xApps with information unavailable to the RAN, such as capacity forecasts and external data, either relayed by the non-RT RIC or fetched directly from sources.Source: C. A1 Interface · p. 13

D. O-RAN Fronthaul

  • The 7.2x fronthaul split places low-PHY processing in the RU and high-PHY processing in the DU, balancing interface simplicity, interoperability potential, and transport data rate.The RU performs OFDM phase compensation, FFT/IFFT, and cyclic-prefix operations; category B RUs can also precode, while category A RUs rely on DU precoding and must support at least eight data streams. The interface is designed for reliable, low-latency transport, with compression and network designs supporting URLLC flows.Source: D. O-RAN Fronthaul · p. 13, Figure 12 · p. 13
  • The fronthaul C-plane carries PHY control commands, including scheduling and beamforming configuration, while the U-plane transports frequency-domain I/Q samples and specifies their timing and digital gain.The C-plane can couple directives to U-plane packets; the DU can select advertised beams, select by attributes, specify weights, or provide CSI for RU-computed weights.Source: D. O-RAN Fronthaul · pp. 13–14
  • The fronthaul S-plane synchronizes DU and RU clocks in time, frequency, and phase, using profiles such as PLFS or PTP that can achieve sub-microsecond time accuracy.Synchronization can use a direct DU-RU link or an Ethernet-switch fabric.Source: D. O-RAN Fronthaul · p. 14
  • The M-plane manages RU initialization, configuration, updates, monitoring, and file transfers through NETCONF, with hierarchical or hybrid SMO/DU management options and end-to-end SSH and/or TLS encryption.It also manages RU registration, DU-RU link parameters, and beamforming-vector updates.Source: D. O-RAN Fronthaul · p. 14

E. Other Interfaces · VI. AI/ML WORKFLOWS

The merged sections describe O2 and 3GPP interfaces in disaggregated O-RAN, then set out a standardized but unfinished six-step AI/ML lifecycle from data preparation through continuous operations.

E. Other Interfaces

  • O2 enables the SMO to manage and provision O-Cloud network functions programmatically, while 3GPP interfaces connect RAN components, gNBs, UEs, and the 5G core.WG6 is considering ETSI NFV standards, 3GPP service-based interfaces, Kubernetes, OpenStack, and ONAP/OSM. E1 connects CU control and user functions, F1 connects CU and DU, Xn connects gNBs for handovers and dual connectivity, Uu connects a UE and gNB, and NG connects the gNB to the 5G core.Source: E. Other Interfaces · pp. 14–15

VI. AI/ML WORKFLOWS

  • O-RAN’s AI/ML workflow has six steps, from data collection and processing through continuous operations, and is being standardized by WG2, although some procedures remain under study.The lifecycle comprises data collection and processing, training, validation and publishing, deployment, execution and inference, and continuous operations.Source: §VI · p. 15
  • Data collected over O1, A1, and E2 is stored and prepared in model-specific formats for training and online inference.For slicing, inputs include PRB needs and slice metrics such as eMBB throughput, mMTC transmitted packets, and URLLC latency; processing may include normalization, scaling, reshaping, or autoencoders.Source: §VI · p. 15
  • O-RAN requires every data-driven model to be trained offline before deployment; online training is permitted only to fine-tune or update an offline-trained model.Operators can compare algorithms, architectures, and input formats to select models suited to a task.Source: §VI · p. 15
  • Trained models are tested for reliability, robustness, and effectiveness; successful models are published to the SMO/non-RT RIC catalog, while failures require redesign and retraining.Validation can use unseen data and varied traffic, users, bandwidth, and frequencies to identify suitable models and the network conditions for their use.Source: §VI · p. 15
  • Catalog models are deployed via O1 as containerized applications or standalone files; current model execution is limited to RICs, with CU/DU execution left for further study.Image-based models run as xApps or rApps; file-based models run in an inference environment outside the O-RAN application domain and forward outputs to O-RAN applications.Source: §VI · pp. 15–16
  • Deployed models perform online inference, derive policies via A1 and E2, and take management or control actions via O1 and E2.In the slicing example, a near-RT RIC xApp uses E2 KPMs to calculate near-real-time actions that assign PRBs to slices.Source: §VI · p. 16
  • Continuous operations monitor model outputs and network effects; detected poor performance can prompt refinement and retraining on new O1- and E2-collected data [135].The slicing example monitors the xApp for anomalies or inefficiencies and can retrain it using newly collected data.Source: §VI · p. 16

A. AI/ML deployment scenarios · B. Gathering inputs for online inference · VII. OPEN RAN USE CASES AND RESEARCH

O-RAN specifies flexible AI/ML deployment and data-gathering patterns, while RICs and open interfaces support closed-loop RAN control across diverse use cases. The paper surveys these patterns, use cases, and emerging research.

A. AI/ML deployment scenarios

  • O-RAN specifies five AI/ML deployment scenarios, but practical deployments may vary to meet operator- and application-specific requirements.The scenarios define where AI/ML workflow components are instantiated and executed; execution at CUs/DUs remains for further study.Source: A. AI/ML deployment scenarios · p. 16

B. Gathering inputs for online inference

  • O1, A1, and E2 gather or convey inference data across non-real-time and near-real-time control loops, including enrichment information and RAN measurements.O1 supports non-real-time optimization, A1 can deliver predicted KPI evolution to the near-RT RIC, and E2 supplies data such as KPMs for near-RT control.Source: B. Gathering inputs for online inference · p. 17
  • A data-access platform mediates applications’ sharing of a common repository, enabling chained models to consume forecasts, DU KPMs, and prior control outputs.In the example, an rApp forecasts traffic; one xApp produces a slicing profile, and another combines that profile with traffic data and KPMs to select a scheduling profile.Source: B. Gathering inputs for online inference · p. 17, Figure 15 · p. 17

VII. OPEN RAN USE CASES AND RESEARCH

  • RICs enable closed-loop mobility control using multi-base-station state and mobility predictions to tune handover, load balancing, multi-connectivity, access barring, and beamforming.The cited vehicle-routing study predicts load across base stations to help avoid congestion.Source: §VII · p. 17
  • Open RAN supports adaptive slicing, scheduling, and service provisioning; studies demonstrate xApp-based control, including reinforcement-learning control of URLLC sessions and resource allocation targeting URLLC quality of service [145].Reported work spans experimental platforms and real-world operator data, while flexible functional splits are shown to benefit slice placement relative to fixed splits.Source: §VII · p. 18
  • QoE/QoS control can combine application monitoring with heterogeneous RAN and external data, while RAN-sharing mechanisms support dynamic spectrum access and resource sharing.Examples include joint optimization of drone-video transmission directionality and drone location, and RIC-managed sharing between a 5G RAN and a satellite constellation.Source: §VII · p. 18
  • RICs can adapt beam groups and mobility parameters and guide MIMO user grouping, although dynamic, data-driven beamforming reconfiguration remains relatively unexplored.The use-case document describes non-RT RIC telemetry-driven beam-group adaptation and near-RT RIC optimization of beam-specific mobility offsets.Source: §VII · p. 19
  • Research also targets O-RAN deployment optimization and intelligence life-cycle management, while this paper distinguishes itself through a comprehensive review of specifications, workflows, use cases, and experimental platforms.Examples include zero-touch placement of network intelligence [160] and the RLOps framework for managing reinforcement-learning design, deployment, updates, safety, and security [135].Source: §VII · pp. 19–20

VIII. SECURITY IN THE OPEN RAN

O-RAN’s distributed, disaggregated architecture expands the attack surface and creates severe security threats, while its monitoring, intelligence, and cloud-native deployment also enable stronger threat defenses. The O-RAN Alliance has established a working group to develop threat models and security measures and policies toward a zero-trust model.

VIII. SECURITY IN THE OPEN RAN

  • O-RAN’s distributed and disaggregated infrastructure expands the attack surface, posing severe threats to networks and users.Source: §VIII · p. 20
  • O-RAN’s monitoring capabilities, intelligence, and cloud-native deployment provide tools to monitor, detect, prevent, and counteract threats.Source: §VIII · p. 20
  • The O-RAN Alliance created a working group to define threat models, security measures, and component policies toward a zero-trust model.Source: §VIII · p. 20

A. Security Stakeholders … IX. O-RAN STANDARDIZATION

O-RAN expands who is responsible for securing the RAN and broadens its threat surface, while openness and virtualization also enable new security controls. The Alliance coordinates its standardization, software-development, and testing work through working groups and focus groups.

A. Security Stakeholders

  • Operators gain a more prominent security role because openness and multivendor deployment let them customize infrastructure and vet components, alongside vendors, integrators, cloud and app providers, administrators, and SMO orchestrators.The O-RAN Security Focus Group was recently promoted to WG11.Source: A. Security Stakeholders · p. 20

B. Extended Threat Surface

  • New elements and interfaces expand risks to availability, integrity, confidentiality, and data; the unencrypted 7.2x control plane enables man-in-the-middle attacks, while S-Plane compromise can degrade performance.The described risks include data and infrastructure attacks and attacks on user data or configurations at the DU or RU endpoints.Source: B. Extended Threat Surface · p. 20
  • Threats also span O-Cloud virtual functions and isolation, open-source backdoors, physical infrastructure compromise, and RU or fronthaul jamming.Examples include exploiting the O2 interface, compromised libraries, physical access to hardware, and jamming data or synchronization signals.Source: B. Extended Threat Surface · pp. 20–21
  • AI/ML attacks can poison training data, inject synthetic online data, or alter models, causing wrong predictions or control decisions; SFG identified 30 interface/data assets and 12 logical-component assets.The resulting control errors may degrade performance or cause outages.Source: B. Extended Threat Surface · p. 21

C. O-RAN Security Principles and Opportunities

  • Openness and virtualization give operators visibility and control, rapid patching, and automated testing; disaggregation enables simpler testable functions, centralized CU deployment eases key protection, and specifications mandate authentication and encryption.These practices align O-RAN security with cloud-native deployment approaches.Source: C. O-RAN Security Principles and… · p. 21
  • E2 and O1 data can support RAN self-monitoring that detects unintended behavior and automatically triggers warnings and alarms.Source: C. O-RAN Security Principles and… · p. 21

IX. O-RAN STANDARDIZATION

  • The Alliance divides specification work among 10 WGs and also coordinates open-source software development and testing and integration of O-RAN solutions.The Alliance's remit also includes guidance for testing and integration of compliant solutions.Source: §IX · p. 21
  • Alliance-wide focus groups coordinate standardization with external bodies and testing; the OSFG's former work largely shifted to OSC, leaving it dormant, while the TSC guides Alliance activities and research.The TIFG coordinates testing, integration, verification, and PlugFests.Source: §IX · p. 22

X. EXPERIMENTAL WIRELESS PLATFORMS FOR O-RAN

Open-source protocol stacks and publicly available platforms make experimental O-RAN research more accessible, enabling virtualized network deployments and large-scale data collection in controlled, realistic wireless environments. Such experimentation supports development and validation of cellular-network use cases.

X. EXPERIMENTAL WIRELESS PLATFORMS FOR O-RAN

  • Open-source stacks such as srsRAN and OpenAirInterface let researchers instantiate 3GPP-compliant network elements on off-the-shelf devices and experiment with complete cellular networks.This softwarization makes experimental research more accessible than closed, hardware-based RAN implementations.Source: §X · pp. 22–23
  • Publicly available platforms virtualize cellular stacks and controllers at scale, support prototyping in commercially realistic deployments, and provide wireless data factories for AI/ML training and testing.The platforms provide tools for data collection at scale in controlled yet realistic wireless environments.Source: §X · p. 23
  • O-RAN experiments combine compute resources for virtualized components such as RICs with radio resources, often using SDR-fronted srsRAN or OpenAirInterface base stations.Users can connect through analogous protocol stacks or commercial smartphones; RAN-control research commonly uses a near-RT RIC, RAN, E2 interface, and custom xApps, with O-RAN software developed ad hoc or based on open-source frameworks.Source: §X · p. 23

A. Experimental Open RAN research with OpenRAN Gym · B. Colosseum and Arena · C. Other Experimental Research Platforms

OpenRAN Gym combines software-defined cellular stacks, a lightweight RIC, and an end-to-end AI/ML pipeline to support O-RAN experimentation. The section surveys Colosseum, Arena, and other platforms for prototyping and testing O-RAN systems.

A. Experimental Open RAN research with OpenRAN Gym

  • OpenRAN Gym combines software-defined cellular stacks, a lightweight RIC, E2 termination, and an end-to-end AI/ML pipeline deployable across multiple experimental platforms.The platform supports programmatic control and management of O-RAN experimental setups.Source: A. Experimental Open RAN research with… · p. 23

B. Colosseum and Arena

  • Colosseum provides hardware-in-the-loop experimentation at scale with 256 USRP X310 SDRs, 128 Standard Radio Nodes, FPGA channel emulation, and GPU resources for ML training.Its SRNs can host RICs, softwarized base stations, and users.Source: Figure 16 · p. 23, B. Colosseum and Arena · p. 24
  • After prototyping on Colosseum, users can port O-RAN solutions to Arena, whose 24 SDRs, 64-antenna ceiling grid, and 12 servers support MEC testing and private indoor cellular deployments.Arena comprises 16 USRPs N210 and 8 USRPs X310.Source: B. Colosseum and Arena · p. 24

C. Other Experimental Research Platforms

  • PAWR platforms POWDER, COSMOS, and AERPAW support O-RAN-compatible white-box base stations managed by RICs, but POWDER alone offered a ready-to-use O-RAN container image at writing.OpenRAN Gym had been tested on POWDER and COSMOS.Source: C. Other Experimental Research Platforms · p. 24
  • ARA was announced as a fourth PAWR platform focused on rural broadband, but was not yet operational at the time of writing.The paper notes this platform's announced scope and availability status.Source: C. Other Experimental Research Platforms · p. 24
  • The European 5GENESIS consortium is implementing 5G components and validating use cases across testbeds that are expected to become compatible with the O-RAN ecosystem.The planned testbeds cover edge-computing NFV-enabled heterogeneous radio infrastructure, orchestration and management, terrestrial and satellite communications, and ultra-dense networks.Source: C. Other Experimental Research Platforms · p. 24
  • Open AI Cellular (OAIC) integrates with O-RAN to manage cellular networks through AI-enabled controllers and interact with systems that locate implementation, system-level, and security flaws [188].The passage describes OAIC as an open-source initiative.Source: C. Other Experimental Research Platforms · p. 24

XI. FUTURE RESEARCH AND DEVELOPMENT DIRECTIONS

Although O-RAN’s foundational specifications enable some use cases, significant standardization, development, and research challenges remain. Future work must refine use cases and architecture while advancing interoperable, intelligent, secure, and efficient deployments.

Identification of key O-RAN use cases

  • Future O-RAN use cases need refinement as 3GPP RAN capabilities expand toward non-terrestrial networks and AR/VR, beyond current RIC-enabled applications such as handover, resource allocation, and QoE optimization.Researchers should evaluate the role of intelligent, data-driven closed-loop control in these future domains.Source: §XI · p. 24

Open RAN beyond public cellular networks—the private cellular use case

  • Private 5G deployments can use disaggregated, virtualized Open RAN to optimize network control and reduce costs, but require domain-specific optimization, edge integration, local breakouts, and constrained-environment connectivity.Relevant deployment settings include industrial automation, warehouses, healthcare, education, and entertainment.Source: §XI · p. 24

Service models development and implementation; Interoperability and testing

  • Comprehensive E2 service models and vendor implementation profiles are needed as use cases emerge, while compliant open interfaces, portable xApps and rApps, and standardized RIC APIs or SDKs remain interoperability priorities.Near-RT RIC effectiveness for RAN analysis and control depends on the E2 service models implemented in the RAN; scalable fronthaul is also a key deployment challenge.Source: §XI · pp. 24–25

O-RAN Architecture and its evolution; Multi-time-scale control

  • Open questions include how to distribute O-RAN components across edge and cloud and coordinate control loops, while dApps could enable real-time RAN-node control over data unsuitable for RIC analysis [197] [160].Research should address multi-loop instability and conflicts, and automate selection of loops suited to high-level intents.Source: §XI · p. 25

Effective AI/ML algorithm design, testing, and deployment

  • O-RAN AI/ML deployment needs representative heterogeneous datasets, safe online training and refinement that protects production performance, and algorithms robust to unreliable inputs and varied deployment conditions.The AI/ML workflow is being standardized, but these practical challenges remain.Source: §XI · p. 25

Spectrum sharing solutions enabled by Open RAN

  • Although O-RAN specifies LTE/NR dynamic spectrum sharing, algorithms and practical sensing, reactive, and proactive adaptation across 3GPP and non-3GPP systems remain open research directions [148].Sharing-related O-RAN architecture extensions are also a future research direction.Source: §XI · p. 25

Security in O-RAN

  • O-RAN’s expanded threat surface coexists with telemetry visibility and plug-in xApps and rApps for security analysis, creating opportunities to improve deployment integrity, resiliency, and availability.Developing security approaches that use these capabilities is important to making Open RAN a viable alternative to traditional RAN deployments.Source: §XI · p. 25

Energy efficiency with Open RAN

  • Further work should develop non-RT RIC/SMO orchestration and xApps or rApps that include energy-efficiency targets in optimization policies and control actions.Virtualization and closed-loop control provide primitives for dynamic network-function allocation and energy-efficiency maximization.Source: §XI · p. 25

XII. CONCLUSIONS

The paper surveys O-RAN specifications, architecture, interfaces, operations, and cross-cutting topics, then reviews standardization, research platforms, and future directions to support more open, programmable, virtualized, and efficient wireless networks.

XII. CONCLUSIONS

  • The paper details O-RAN’s architectural building blocks and design principles, RIC and SMO components, and interfaces including E2, O1, A1, fronthaul, and O2.It covers the near-RT and non-RT RICs and the SMO.Source: §XII · p. 25
  • It examines O-RAN’s AI and ML workflow, use cases and research, and security challenges and potential across components and interfaces.Source: §XII · p. 25
  • The paper reviews O-RAN Alliance structure and standardization, research platforms, and future directions, with insights intended to promote more open, programmable, virtualized, and efficient wireless networks.Source: §XII · p. 25

APPENDIX · A. Example of E2 Subscription Request Message · B. Example of E2 Indication (Report) Message.

The appendices provide examples of E2 subscription and report-indication messages, showing how E2AP fields are organized and how E2SM defines the semantics of selected indication fields. They also list acronyms used throughout the work.

APPENDIX

  • The appendices collect E2-interface subscription and report-indication message examples alongside a list of acronyms used throughout the work.Source: APPENDIX · p. 26

A. Example of E2 Subscription Request Message

  • An E2 subscription request is generated by the near-RT RIC, sent to an E2 node, described as XML fields, then ASN.1-encoded for SCTP transmission.Source: A. Example of E2 Subscription Request… · p. 26
  • The request identifies the RIC request and target RAN function, then specifies subscription actions; this example requests a report and continues after a 10 ms timer.The action definition is optional and depends on the supported RAN function.Source: A. Example of E2 Subscription Request… · p. 26

B. Example of E2 Indication (Report) Message.

  • An E2 node sends an E2AP Indication to the near-RT RIC when an event defined by the subscription is triggered, and the message is ASN.1-encoded.Source: B. Example of E2 Indication (Report)… · p. 26
  • The indication includes the message type and procedure code, RIC request and function identifiers, an action identifier, an optional sequence number, and an indication type; this example uses report.The possible indication types are insert or report.Source: B. Example of E2 Indication (Report)… · p. 28
  • The indication header, indication message, and call process identifier are encoded by E2AP, while their semantics are defined by the E2SM used to populate the message.E2SM KPM is one example.Source: B. Example of E2 Indication (Report)… · p. 28

Related papers

Loading 2202.01032v2…