Toward Next Generation Open Radio Access Network--What O-RAN Can and Cannot Do!

• O-RAN provides virtualization, intelligence, flexibility, and open interfaces to support service heterogeneity, coordination, and on-demand deployments.Source: §I · p. 1
• Its open architecture replaces vendor-specific interfaces and establishes modules for data collection, distribution, and processing in increasingly data-driven network management.Source: §I · p. 1
• Prior studies explore AI-based radio resource management, renewable-energy deployment, dynamic function splitting, and closed-loop RAN optimization.Source: §I · p. 1
• The paper uses community feedback to identify security, latency, real-time control, and testing as critical O-RAN components needing specification and R&D attention.Source: §I · p. 1
• The survey invited about 150 advanced wireless communications and networking experts, with 95 participants from 65 institutions responding.Source: §II · p. 1

• The survey asked which O-RAN capabilities participants wanted to explore, develop, or use for advanced wireless and networking R&D.Source: §6 · p. 2
• A majority agreed that O-RAN will be the foundation of future cellular networks.Source: §6 · p. 2
• Around 38% wanted access to in-phase and quadrature data across time and frequency domains using different functional split options.Source: §6 · p. 2
• Sixteen percent wanted support for dynamic functional splitting, while programmable PHY and MAC layers, MIMO, scheduling, and resource allocation ranked highly.Source: §6 · p. 2
• Respondents prioritized data collection, realistic large-scale experimentation, novel networking features, and implementation and verification of AI-enabled controllers.Source: §6 · p. 2
• The survey findings motivate studying O-RAN’s capabilities and limitations and developing complementary architectural elements and processes.Source: §6 · p. 2

• The architecture encompasses the RAN, operations support systems, and open interfaces, with O-DU functions including higher-PHY, MAC, and RLC processing.Source: §III · p. 3
• The O-CU provides RRC, PDCP, and SDAP layers and supports simultaneous LTE and 5G NR O-DUs through multi-RAT operation.Source: §III · p. 3
• The E2 interface carries measurements from O-DU and O-CU to the near-RT RIC and returns configuration commands for near-real-time control through xApps.Source: §III · p. 3
• The OSS performs radio planning, testing, service management, orchestration, monitoring, and lifecycle operations for softwarized O-RAN components.Source: §III · pp. 3–4
• A1, O1, and O2 support AI-related parameter exchange, RAN fault and performance management, and NFVI resource management, respectively.Source: §III · p. 4

• Opening RAN interfaces enables new developers and vendors to contribute innovations while potentially reducing maintenance costs and accelerating new services.Source: §IV · p. 4
• O-RAN adopts functional split Option 2 for F1 between O-DU and O-CU and Option 7-2x for the fronthaul between O-DU and O-RU.Source: A. RAN Disaggregation, Open… · p. 4
• Open interfaces allow operators to combine vendors’ strengths, share RAN functions, and deploy interoperable, flexible, independently fault-tolerant systems.Source: A. RAN Disaggregation, Open… · p. 4
• O-CU, O-DU, and near-RT RIC functions can be deployed centrally or at the edge depending on bandwidth and latency requirements.Source: A. RAN Disaggregation, Open… · p. 4
• Virtual-machine and container implementations on commercial off-the-shelf hardware support scalability, diverse network support, and interoperability.Source: A. RAN Disaggregation, Open… · p. 4

• 5G RAN operations require timescales as fine as sub-millisecond granularity, while O-RAN distributes control across RICs operating at different timescales.The architecture defines non-RT and near-RT control loops for heterogeneous service requirements.Source: B. Support for Different Timescales · p. 4
• The non-RT control loop operates at least 1 s through A1 and O1 for slice orchestration, infrastructure resource allocation, and policy guidance.Its decisions may occur over seconds, hours, or days.Source: B. Support for Different Timescales · p. 4
• The near-RT control loop operates between 10 ms and 1 s through E2 for scheduling, beamforming, load balancing, and handover.xApps use user-session, MAC-layer, and PHY-layer data to control time-sensitive services.Source: B. Support for Different Timescales · p. 4
• Combining near-RT fast processing with non-RT larger-timescale analysis is a distinctive O-RAN capability.This combination supports RAN operations across the architecture’s different control-loop timescales.Source: B. Support for Different Timescales · p. 4

• The non-RT RIC manages policies, AI models, and enriched data for the near-RT RIC, which performs analytics and management functions.AI models can be transferred and updated periodically or when triggered.Source: C. AI Integration and xApps/rApps · p. 5
• O-RAN enables per-UE performance enhancement using long-term traffic, coverage, and observed interference information.Near-RT resource management can reduce core-network burden and data-transfer overhead, improving system efficiency and latency.Source: C. AI Integration and xApps/rApps · p. 5
• AI control use cases include load balancing, resource allocation, fault detection, and security across RAN layers.The use cases specify the implementing layer, AI operation, and training-data requirements.Source: C. AI Integration and xApps/rApps · p. 5
• xApps support network slicing, deep-reinforcement-learning resource scheduling, and traffic steering based on traffic predictions.A traffic-steering xApp demonstrates dynamic user handover between cells.Source: C. AI Integration and xApps/rApps · p. 5
• Non-RT RIC rApps can provide AI-based network-slice orchestration and data-driven policy management for RAN resources and xApps.Source: C. AI Integration and xApps/rApps · pp. 5–6

• The section identifies major limitations of current O-RAN specifications and outlines R&D directions for overcoming them.The stated aim is to spur O-RAN’s evolution as an architectural framework for next-generation wireless deployments.Source: §V · p. 6

• Dynamic disaggregation, new interfaces, and the lower-layer split expand O-RAN’s threat surface beyond that of the 3GPP architecture.Source: A. End-to-End Security · p. 6
• The six security-threat classes cover new functions, unprotected interfaces, the 7-2x split, multi-vendor decoupling, virtualization, and open-source software.Risks include misconfiguration, missing authentication or ciphering, decision conflicts, absent root of trust, insufficient virtualization security, and attack discovery through open-source inspection.Source: A. End-to-End Security · p. 6
• O-RAN’s open interfaces and O-Cloud deployment introduce risks from unprotected communication, misconfiguration, poor isolation, and insufficient access management.Source: A. End-to-End Security · p. 6
• Functional decoupling can leave hardware and software without a shared root of trust, motivating bottom-up trust chains and zero-trust security.The proposed zero-trust approach assumes no implicit trust and continuously evaluates risks.Source: A. End-to-End Security · p. 6
• Security research directions include mutual authentication, trusted xApps and AI models, and cryptographic key generation, storage, rotation, and revocation.Source: A. End-to-End Security · p. 6

Latency challenge

• Open interfaces and multi-vendor support make data- and control-plane latency harder to control and optimize.The O-RAN latency model is based on the eCPRI reference model for delay management.Source: B. Deterministic Latency · p. 6
• O-RAN timing requirements cannot be guaranteed when communicating with systems that do not follow its delay specifications.Packets arriving before or after their permitted windows should be discarded.Source: B. Deterministic Latency · p. 6
• The specification does not prevent processing packets that arrive too early or too late, potentially disturbing control- or user-plane timing.Source: B. Deterministic Latency · p. 7
• CPRI uses strictly periodic scheduling with a k28.5 time marker, whereas eCPRI relies on statistical synchronization without a fixed marker.The comparison concerns determinism in latency and delay measurement.Source: B. Deterministic Latency · p. 7

R&D direction

• Dynamic functional splitting varies network-function placement based on network feedback to satisfy latency requirements.The proposed architecture supports multiple functional splits through a single near-RT RIC for different timing requirements.Source: B. Deterministic Latency · p. 7

Control gap

• The near-RT RIC operates at 10 ms–1 s, making it difficult to control many PHY-layer processes.A sub-millisecond real-time controller hosted at the O-CU or O-DU is therefore needed.Source: C. PHY Layer RT Control · p. 7

RT control loop

• The proposed RT RIC adds a third, real-time control loop that may reside in the O-CU, O-DU, or O-RU.It can host lower-layer RAN control applications called zApps.Source: C. PHY Layer RT Control · p. 7
• AI-based RT control faces constraints from node compute power, energy efficiency, sub-millisecond decision latency, and low-level PHY signaling overhead.These factors may adversely affect low-latency next-generation cellular networks.Source: C. PHY Layer RT Control · p. 7

R&D directions

• Near-constant-time zApps, subject-matter-expert validation, lightweight AI models, and RAN hardware acceleration are proposed as solutions.Echo state networks are given as an example of less data-intensive lightweight AI algorithms.Source: C. PHY Layer RT Control · p. 7

AI control risks

• Unpredictable closed-loop AI behavior can produce unstable configurations and performance losses, while incompatible xApps, rApps, and zApps may make conflicting decisions.Source: D. Testing of AI-Driven O-RAN… · p. 7
• AI control requires stability, robustness, predeployment certification, and online testing against unfamiliar data and operational conditions.Testing should address noise, interference, unexpected signals, conflicting messages, and incomplete or uncertain training data.Source: D. Testing of AI-Driven O-RAN… · pp. 7–8
• Testing should cover both AI models and their data, supported by workflow validation services and high-fidelity live representations of deployed RAN functions.O-CU, O-DU, and O-RU configurations may differ within and across operators.Source: D. Testing of AI-Driven O-RAN… · p. 8

Conclusion

• The survey identifies security, latency, real-time control, and AI-based RAN-control testing as critical limitations of current O-RAN specifications.Source: §VI · p. 8
• The paper outlines technologies and R&D opportunities intended to overcome these limitations and extend O-RAN’s architectural capabilities.Source: §VI · p. 8