Empowering the 6G Cellular Architecture with Open RAN

I. INTRODUCTION

• 5G deployments lag finalized specifications, often use non-standalone mode, and commonly rely on global default configurations rather than tailored setups.Releases 16 and 17 were finalized while only a subset of Release 16 features was commonly deployed.Source: §I · p. 1
• High deployment and operational costs make it difficult to install, configure, optimize, and operate 5G equipment without a clear business strategy for return on investment.The paper argues that technical, architectural, and system-level solutions integrated into 6G could help accelerate cellular innovation.Source: §I · pp. 1–2
• The paper fills a gap in 6G architecture vision with a systematic review of cellular limitations and a tutorial on embedding Open RAN principles in 6G.It analyzes networks as complex systems and connects Open RAN principles to requirements including energy efficiency, ubiquitous coverage, resiliency, low cost, and complexity.Source: §I · p. 2
• The envisioned 6G networks apply AI to programmable protocol stacks and dynamically orchestrate virtualized network functions to meet use-case requirements.They are software-deployed, can use dedicated or shared spectrum and infrastructure, and can extend coverage through automated self-backhaul.Source: §I · p. 2

A. Access and Core Network

• The horizontal split assigns last-mile access to the RAN and support functions to the core network.Cellular systems provide centralized scheduling and spectrum access, but deployments have limited adaptability and rely partly on manual optimization.Source: A. Access and Core Network · p. 2, §II · p. 2
• RAN base stations contain a complex 3GPP protocol stack; they are generally monolithic in 4G and virtualized or cloudified in 5G.The stack includes physical-layer processing and data-link functions such as scheduling, buffering, encryption, QoS enforcement, and network-state management.Source: A. Access and Core Network · pp. 2–3
• The core network manages authentication, mobility, paging, and Internet routing; 4G typically uses monolithic servers, while 5G uses virtualized service-based network functions.The service-based architecture has not yet fully realized its potential.Source: A. Access and Core Network · p. 3

B. User and Control Plane

• The user plane processes traffic through network layers, while the control plane manages configuration, optimization, sessions, and mobility.In the RAN, RRC orchestrates control; core control elements authenticate users, manage billing, and track location.Source: B. User and Control Plane · p. 3

C. Limitations and Theory-Implementation Gap

• Production networks focus on well-tested mobile-broadband features because of complexity, scale, performance demands, and unclear monetizable use cases.Few operators have upgraded to 5G standalone, complicating support for different use cases on one public network.Source: C. Limitations and… · p. 3
• Cellular networks have mostly used licensed spectrum, limiting access to small, disaggregated bandwidth chunks below 6 GHz.The passage says more flexible radios and spectrum access systems could support more efficient spectrum use and greater available bandwidth.Source: C. Limitations and… · p. 3
• A small set of RAN vendors limits deployment options; further disaggregation could potentially foster innovation and supply-chain resiliency.Vendor interoperability is ensured through well-tested Xn interfaces.Source: C. Limitations and… · p. 3
• Stringent telco requirements have delayed general availability of production-grade cloud fabric despite 5G’s support for cloudified deployments.The section says complexity, limited adaptation, and flexibility may impede innovative services and new market entrants.Source: C. Limitations and… · pp. 3–4

III. EMPOWERING THE 6G CELLULAR ARCHITECTURE WITH OPEN RAN PRINCIPLES

• A system-level approach to 6G should connect standards for network functions, Open RAN support for cloudified deployment and closed-loop control, and actual deployments.The paper presents these as distinct parts of the transition from research and standardization into production.Source: §III · p. 4

A. 6G requirements and Open RAN principles

• Softwarization and disaggregation can improve energy efficiency when paired with dynamic resource scaling and RAN-component aggregation, while software-based functions can be replaced or transferred after compute-node failure.Disaggregation splits monolithic components into atomic functions, easing market access at the cost of additional integration testing.Source: A. 6G requirements and Open RAN… · p. 5
• Automation can reduce manual supervision, operating costs, and the time needed to apply configurations or restore services, while supporting remote deployments.Security remains an issue because automation increases the attack surface.Source: A. 6G requirements and Open RAN… · p. 5
• The example rural deployment combines low-cost radios, wireless backhaul, shared spectrum, generic compute, and centralized orchestration to serve heterogeneous mobile users.The network self-adapts resource use to traffic and usage patterns to minimize energy consumption.Source: A. 6G requirements and Open RAN… · p. 5
• Open RAN principles are presented as supporting 6G requirements including energy efficiency, lower cost and complexity, faster innovation, ubiquitous coverage, and resiliency.The paper calls for integrating these principles into next-generation cellular architecture.Source: §III · pp. 4–5, A. 6G requirements and Open RAN… · p. 6

• Softwarization in Ethernet and the 5G Core provides precedents, but 6G still needs a suitable way to disaggregate network functions.OpenFlow, network operating systems, and P4 are cited as wired-network milestones; the authors note that some core functions have limited purpose.Source: §IV · p. 6
• C-RAN helped establish software-based cellular systems by virtualizing some RAN computation in edge data centers for centralized control and dynamic compute scaling.The C-RAN Alliance later coalesced into the O-RAN Alliance with the xRAN initiative.Source: §IV · p. 6
• White-box servers and radios separate software from hardware, improving network programmability, supply-chain diversity, and the speed of prototyping and implementation.Software can move across domains more readily than hardware systems.Source: §IV · p. 6, Figure 3 · p. 6
• Cloud compute, microservices, and continuous testing, integration, and deployment bring software-industry practices to cellular networks.These practices support resilient, scalable platforms and faster deployment cycles.Source: §IV · p. 6
• Softwarization makes DSP implementation and performance tuning challenging, prompting work on white-box performance requirements and programmable accelerators.Examples include GPUs, FPGAs, and dedicated systems-on-a-chip, which combine reconfigurability with parallel signal processing.Source: §IV · p. 6

• O-RAN Working Groups 6 and 7 are developing an Acceleration Abstraction Layer and white-box hardware requirements for specific network functions.The layer provides standardized APIs connecting dedicated processors to the softwarized infrastructure for functions such as channel coding and forward error correction.Source: A. Implementation and Research… · p. 6
• Exposing GPUs, FPGAs, CPUs, and systems-on-chip through a shared API is difficult because their capabilities vary.Future abstractions could avoid tight coupling to specific physical-layer features and extend across generations.Source: A. Implementation and Research… · p. 6
• Maintaining compute, energy, and cost efficiency against optimized monolithic devices is a central implementation challenge.Statistical multiplexing, scaling, and optimization of software and telecom/DSP hardware are possible approaches.Source: A. Implementation and Research… · pp. 6–7

V. OPEN RAN PRINCIPLE #1: DISAGGREGATION AND OPEN INTERFACES

• The gNB is organized into CU, DU, and RU units, with protocol functions placed across them according to synchronization and processing needs.The DU handles RLC, MAC, and higher physical-layer functions; frequency-domain processing is split from time-domain and RF functions in the RU.Source: §V · p. 7
• 3GPP interfaces connect the CU and DU through E1 and F1, and link the CU to neighboring nodes and the core through Xn, X2, and NG.These interfaces support CU-to-CU, eNB, and core-network connectivity.Source: §V · p. 7
• E2 carries telemetry and control between the Near-RT RIC and RAN nodes, while O1 supports slower-scale data, configuration, and updates.O2 connects the SMO to the O-Cloud, and A1 carries policies from the Non-RT RIC to the Near-RT RIC.Source: §V · pp. 7–8

A. Implementation and Research Directions

• AI and natural-language tools could generate open-interface implementations and automate testing to find vendor incompatibilities and specification divergence.The authors identify integration and interoperability as risks in a disaggregated environment.Source: A. Implementation and Research… · p. 8
• Additional E2 service models are needed for functions such as spectrum sharing and IAB optimization, with vendor profiles defining baseline O-RAN compliance features.The service-model design must also work within 3GPP parameters for CUs and DUs.Source: A. Implementation and Research… · p. 8
• Fronthaul efficiency is a research challenge because its data rate should not scale linearly with wireless bandwidth for massive MIMO or carrier aggregation.The authors also call for models of latency and energy effects relative to monolithic architectures.Source: A. Implementation and Research… · p. 8

VI. OPEN RAN PRINCIPLE #2: TOWARD CLOUD-NATIVE APPROACHES FOR THE RAN

• The O-Cloud is a hybrid platform spanning compute, DSP and AI/ML accelerators, software, the SMO, and O2, and can span cell sites, edge, and regional data centers.It is designed to deploy O-RAN components and address virtualization challenges.Source: §VI · p. 8
• Cloud-native RAN makes most cellular functions software-driven, supporting automated provisioning, multi-tenant and neutral-host deployments, and shared abstraction across heterogeneous hardware.RF-related components such as antennas, RF chains, and data converters remain exceptions.Source: §VI · p. 8

A. Orchestration and Automation

• CI, CD, and CT automate software integration, deployment, and ongoing performance, security, and compliance evaluation.GitOps uses repositories as the authoritative source for network code and infrastructure configuration, with controllers synchronizing deployed state and reducing configuration drift.Source: A. Orchestration and Automation · pp. 8–9

B. Security

• Open interfaces, virtualization, softwarization, and AI/ML control expand the threat surface and security responsibilities beyond traditional RAN stakeholders.Identified risks span RICs, O-Cloud, open-source code, physical infrastructure, wireless functions, protocol stacks, and AI/ML components.Source: B. Security · p. 9
• Openness also permits operator audits, while SMO monitoring, continuous software testing and patching, and specified authentication and encryption procedures address security concerns.The SMO can use its global view of RAN infrastructure and performance to spot anomalies and weaknesses.Source: B. Security · p. 9

Cloud-Native Approaches to Energy Efficiency

• Virtualized RAN components and intelligent orchestration can adjust compute resources to meet user requirements, limiting power use to network functions in use.Closed-loop control with RAN virtualization can also support more precise and flexible sleep cycles for base stations and RF components.Source: C. Deployment and Research Directions · p. 9

An O-Cloud with Heterogeneous Compute and Devices

• O-Cloud design must span heterogeneous hardware platforms, with WG 7 criteria specifying white-box equipment parameters and attributes for varied nodes and use cases.The equipment includes indoor picocells, outdoor microcells and macrocells, integrated access and backhaul nodes, and fronthaul gateways.Source: C. Deployment and Research Directions · p. 9

Automated Security for the RAN

• Open RAN interfaces and the SMO and RICs’ privileged network view offer a basis for extending automated anomaly detection from wired networks to cellular systems.The passage calls for designing, developing, deploying, and testing the algorithms and infrastructure needed to realize this security potential.Source: C. Deployment and Research Directions · p. 9

Security for the AI/ML Control

• AI/ML control is vulnerable before and after deployment, motivating resilient solutions against data manipulation during training and inference [82].Examples include training-data tampering, model backdoors, adversarial machine learning, and corrupted inference inputs.Source: C. Deployment and Research Directions · p. 10

VII. OPEN RAN PRINCIPLE #3: AI-BASED CLOSED-LOOP CONTROL

• Programmable network stacks, open interfaces, and RICs support data-driven closed-loop control and optimization of RAN functions, a step toward autonomous networks.The O-RAN Alliance introduced a formal framework through near-real-time and non-real-time RICs and their interfaces.Source: §VII · p. 10
• A RAN function exposes telemetry, analytics, and KPMs to a controller, which infers status, predicts behavior, or selects configurations and returns control to close the loop.The controller may use classification, regression, prediction, reinforcement learning, optimization, or other data-driven techniques.Source: §VII · p. 10
• SMO and Non-RT RIC rApps manage global policies and service lifecycles over loops longer than 1 s, while Near-RT RIC xApps control clusters of RAN nodes over 10 ms to 1 s.dApps interface with individual RAN functions and are envisioned to control below 10 ms, a timescale not currently considered by O-RAN specifications.Source: §VII · p. 10
• 50% average improvement in throughput and spectral efficiency over traditional cell-based handover heuristics is reported for data-driven handover tuning to individual UE requirements.Open RAN primitives can adjust handover, load balancing, multi-connectivity, access barring, and beamforming parameters.Source: §VII · pp. 10–11
• Testbed demonstrations show xApps intelligently controlling base-station scheduling policies across eMBB, URLLC, and MTC slices with distinct optimization targets [99].Source: §VII · p. 11
• Closed-loop control also supports vehicular and industrial IoT applications, RAN deployment optimization, resource utilization, and security monitoring [103] [112] [113].For industrial IoT, the loop can adapt configurations to changing factory-floor conditions; proposed deployment approaches include zero-touch orchestration and fault-tolerant techniques.Source: §VII · p. 11

A. Implementation and Research Directions

• Research should align O-RAN operational capabilities with 3GPP functional standardization and refine future use cases, including non-terrestrial networks and AR/VR.The role of intelligent, data-driven closed-loop control in next-generation applications also needs evaluation.Source: A. Implementation and Research… · p. 11
• Reliable, deployable RAN control still requires solutions for offline training on dynamic systems, cross-deployment generalization, and explainability.The systems are sensitive to performance degradation, and traffic distributions vary across deployments.Source: A. Implementation and Research… · p. 11
• Hierarchical reinforcement learning can coordinate RIC timescales, but smoother information fusion and control remain open research needs.Some optimizations require fine- and coarse-grained data together, while RICs operate at different timescales.Source: A. Implementation and Research… · p. 11
• Future work must compare conflict-mitigation strategies for direct and indirect conflicts among xApps or rApps and determine whether the SMO, Near-RT RIC, or both should handle them.Strategies may be pre- or post-deployment and use declared policies, inferred conflict impacts, or both.Source: A. Implementation and Research… · p. 11

VIII. EMERGING SYSTEM REQUIREMENTS #1: AGILE SPECTRUM AND INFRASTRUCTURE SHARING

• Widespread multi-operator sharing still lacks fine-grained and dynamic mechanisms; CBRS spectrum access currently operates on timescales of minutes.Fine-grained sharing would let tenants share compute and spectrum slices on the same infrastructure; dynamic sharing would adjust resources to changing tenant needs.Source: §VIII · p. 12
• Open RAN programmability and virtualization can support automated, dynamic sharing pipelines intended to improve resource utilization and provide spectrum when users need it.The proposed pipelines are described as zero-touch, resilient, and fault-tolerant.Source: §VIII · p. 12
• Dynamic tenant coordination can avoid manual intervention and over-provisioning, while timely service-lifecycle management addresses the challenge of instantiating softwarized gNBs within seconds.O-RAN interfaces also support accountability and visibility through fine-grained spectrum control, and SLA enforcement through dynamic resource allocation.Source: §VIII · p. 12

A. Research Directions

• Open-RAN-driven sharing combines data- and ML-driven approaches, hierarchical decentralized and centralized control, and automation to pursue approaches deployable in 3GPP systems.The paper positions these approaches beyond capabilities discussed in cognitive radio literature, while noting that its lessons and algorithms may still inform Open RAN.Source: A. Research Directions · p. 12
• Practical spectrum sharing still needs methods to sense usage and allocate resources, including reactive and proactive adaptation across 3GPP and non-3GPP systems and licensed and unlicensed spectrum.The paper identifies real-time spectrum-sensing dApps as one possible O-RAN extension.Source: A. Research Directions · p. 12
• FR-3 spans 6–24 GHz and may offer more favorable propagation than FR-2 and wider channels than sub-6 GHz, but incumbent services make dynamic sharing necessary.The band is allocated to military, weather and Earth monitoring, and satellite uplinks and downlinks.Source: A. Research Directions · p. 12

IX. EMERGING SYSTEM REQUIREMENTS #2: SELF-RECONFIGURABLE WIRELESS BACKHAULING

• IAB multiplexes backhaul and UE access traffic over the same 5G NR air interface, connecting wireless relay IAB-Nodes to wired IAB-Donors.This can avoid fiber connections to every access point.Source: §IX · p. 13
• IAB management still needs better scheduling, interference reduction, and topology reconfiguration for link failures, traffic imbalances, and irregular user distributions.These procedures require control primitives beyond those specified by 3GPP.Source: §IX · p. 13
• Extending O-RAN interfaces such as E2, O1, and O2 through dedicated wireless-domain tunnels could let RICs and the SMO reach IAB-node DUs and MTs for data-driven control.The proposed extension is illustrated in Fig. 6.Source: §IX · p. 13, Figure 6 · p. 13

A. Research Directions

• Extending O-RAN-based IAB optimization to non-terrestrial networks remains open, including choices of gNB and IAB splits, cross-domain mobility, and NTN topology.Open RAN control and softwarization could support dynamic resource and topology optimization amid NTN mobility and dynamics.Source: A. Research Directions · p. 13
• Turning off a self-backhauled IAB node can break upstream and downstream links and trigger reallocation, handovers, and reconnections.Multi-radio nodes with low-power or wake-up radios are of interest for scaling resources in an IAB tree.Source: A. Research Directions · pp. 13–14

X. CONCLUSIONS

• The paper reviews Open RAN as an enabler of 6G innovation from a system-level and architectural perspective, connecting its principles to requirements including energy efficiency, coverage, resiliency, cost, and complexity.It also presents open challenges for developing and deploying the principles in commercial networks.Source: §X · p. 14
• The tutorial identifies intelligent-algorithm design and testing as open challenges to fully using Open RAN primitives for network efficiency and performance.It presents openness, virtualization, programmability, softwarization, scaling, spectrum sharing, self-backhaul, optimization, and automation as core components of future 6G systems.Source: §X · p. 14