Source-linked AI summary
dApps: Distributed Applications for Real-time Inference and Control in O-RAN
Salvatore D'Oro, Michele Polese, Leonardo Bonati, Hai Cheng, Tommaso Melodia
TL;DR
Current O-RAN RIC control lacks a practical approach for loops below 10 ms, limiting support for time-critical inference and control. The paper proposes dApps at CUs/DUs, complementing xApps/rApps with real-time RAN data and near-RT RIC enrichment information. In the low-latency use case, the best scheduling choice depends on the share of resources reserved for URLLC, with RR reaching 4 ms end-to-end latency when more PRBs are reserved.
Problem
Current RIC control lacks a practical approach to real-time loops below 10 ms, despite use cases requiring tighter timing.
Source: §I · p. 2Method
The paper proposes dApps at CUs/DUs that complement xApps/rApps by using real-time RAN data and near-RT RIC enrichment information for lower-layer inference and control.
Source: §I · p. 2Results
When less than 30% of resources are reserved for URLLC traffic, PF gives the lowest latency; with more PRBs reserved for URLLC, RR works best, with end-to-end latency as low as 4 ms.
Source: B. Supporting Low-latency Applications · p. 7Takeaways & Limitations
For tolerable end-to-end latency under rapidly changing channel and network conditions, ultra-low-latency use cases still require decisions made directly at DUs via dApps.
Source: B. Supporting Low-latency Applications · p. 7dApps must not halt or delay real-time gNB functionality, making hardware acceleration pivotal to reliable, fast execution.
Source: §III · p. 3
Abstract
from arXiv · showhide
The Open Radio Access Network (Open RAN)-which is being standardized, among others, by the O-RAN Alliance-is bringing a radical transformation to the cellular ecosystem through the notions of disaggregation and RAN Intelligent Controllers (RICs). The latter enable closed-loop control through custom logic applications, namely xApps and rApps, supporting control decisions at different timescales. However, the current O-RAN specifications lack of a practical approach to execute real-time control loops operating at timescales below 10ms. In this paper, we propose the notion of dApps, distributed applications that complement existing xApps/rApps by allowing operators to implement fine-grained data-driven management and control in real-time at the Central Units (CUs)/Distributed Units (DUs). dApps receive real-time data from the RAN, as well as enrichment information from the near-real-time RIC, and execute inference and control of lower-layer functionalities, thus enabling use cases with stricter timing requirements than those considered by the RICs, such as beam management and user scheduling. We propose feasible ways to integrate dApps in the O-RAN architecture by leveraging and extending interfaces and components already present therein. Finally, we discuss challenges specific to dApps, and provide preliminary results that show the benefits of executing network intelligence through dApps.
I. INTRODUCTION
Open RAN disaggregates and softwarizes the RAN, with RIC applications supporting control at near-real-time and non-real-time timescales. The paper proposes dApps for lower-layer inference and control when those timescales are too slow, while addressing latency, data access, and flexibility constraints.
I. INTRODUCTION
- Open RAN combines softwarization, disaggregation, open interfaces, and programmable hardware to support more agile, multi-vendor cellular networks.Its architecture separates base-station functions across CUs, DUs, and RUs, while RICs use xApps and rApps for near-RT and non-RT control.Source: §I · p. 1
- Near-RT control loops support windows down to 10 ms, while scheduling can require sub-ms decisions and beam-sweeping bursts can last 5 ms.These timing requirements make user scheduling and beam management examples of use cases beyond current RIC control timescales.Source: §I · pp. 1–2
- Moving low-level information to the RIC can add delay and overhead, while sensitive I/Q samples raise privacy and security concerns.Direct DU/RU implementations can meet timing requirements but are often closed and proprietary, and hardware or firmware upgrades can limit flexibility.Source: §I · p. 2
- dApps complement xApps/rApps by bringing data-driven real-time inference and control to CUs/DUs for use cases outside current RIC timescales.They use real-time RAN data and KPMs, alongside enrichment information from the near-RT RIC, to control lower-layer functionalities.Source: §I · p. 2
- The paper proposes integrating dApps by extending existing O-RAN components with minimal specification changes, and discusses dApp-specific challenges and preliminary Colosseum results.The authors report that dApps can support edge inference tasks and reduce control overhead.Source: §I · p. 2
II. WHY DAPPS?
dApps move time-critical control and access to lower-layer data to the CUs/DUs, while offering software-based alternatives to less flexible hardware implementations. The paper identifies reduced latency and overhead, real-time MAC/PHY control, and access to UE-specific data as benefits.
Reduced Latency and Overhead
- Executing real-time procedures at CUs/DUs via dApps substantially reduces latency and E2-interface overhead; the paper reports a 3.57× overhead reduction.The near-RT RIC executes in cloud facilities, so data and inference outputs still travel between it and the DUs/RUs.Source: §II · p. 2
Access DU/CU Data and Functionalities in Real Time
- dApps can access control- and user-plane data unavailable to the near-RT RIC or not available there with sub-ms latency.Examples include I/Q samples, data packets, mobility information, and dual-connectivity data.Source: §II · p. 3
Controlling MAC- and PHY-layer Functionalities
- dApps can execute MAC- and PHY-layer procedures such as scheduling and beamforming that require sub-ms real-time decisions.xApps may select a scheduling policy, but cannot allocate resource elements at the DU in real time for procedures such as URLLC puncturing and preemption.Source: §II · p. 3
Extensibility and Reconfigurability
- Software-based dApps offer a more extensible and reconfigurable alternative to hardware-based MAC/PHY implementations.The O-RAN Alliance is developing standardized interfaces to support hardware acceleration in O-RAN.Source: §II · p. 3
III. CHALLENGES AND OPEN ISSUES
dApps introduce resource, platform, interface, orchestration, dataset, and vendor-ecosystem challenges. Their deployment must support reliable inference without disrupting gNB timing or interoperability.
Resource management
- DUs need enough computing capacity for concurrent dApps without resource starvation or added latency from their instantiation and execution.GPUs, CPUs, FPGAs, hardware acceleration, and efficient resource virtualization and allocation are identified as relevant resources and mechanisms.Source: §III · p. 3
Softwarized ecosystem
- CUs/DUs need a container-based platform that supports dApp lifecycle management while avoiding delays to real-time gNB execution.The paper describes containers as a tradeoff among platform-independent deployment, portable lightweight development, and rapid instantiation and execution; hardware acceleration is pivotal to reliable speed.Source: §III · p. 3
Standardized interfaces for DUs/CUs; Orchestration of the intelligence
- dApps require northbound and southbound interfaces for platform-independent interaction, plus orchestration that assigns tasks by data, timing, geography, workload, and operator intent.Orchestration must also avoid conflicts among multiple O-RAN applications controlling RAN components.Source: §III · p. 3
Dataset availability
- Reliable and robust real-time AI depends on diverse, heterogeneous datasets, which Colosseum and digital twins can help generate for training, testing, and validation.Source: §III · p. 3
Friction from vendors
- Third-party dApps may reduce the value of vendors’ intellectual property and face friction from monolithic development, though the authors say these are not road blockers.They point to the xApp paradigm and data-center SDN solutions as precedents for separating RAN state and enabling reprogrammability.Source: §III · pp. 3–4
IV. PROPOSED ARCHITECTURE
The proposed architecture aims to support dApps with minimal changes to the existing O-RAN architecture.
IV. PROPOSED ARCHITECTURE
- The proposed dApp-supporting architecture is designed to require minimal changes to the existing O-RAN architecture.Source: §IV · p. 4
A. dApps as Softwarized Containers
dApps use containers to manage application lifecycles and support software updates, hardware-independent deployment, and AI-based lower-layer functionality. The architecture also provides abstractions for tailoring dApps to node capabilities and a resource manager for sharing physical resources.
A. dApps as Softwarized Containers
- Containerization manages dApp deployment, execution, and termination while facilitating software updates for newly released O-RAN functionality.The architecture also provides hardware-independent implementations that can be offered as standalone O-RAN applications.Source: A. dApps as Softwarized Containers · p. 4
- CUs, DUs, and RUs advertise tunable parameters and functionalities so dApps can be tailored to control specific parameters.This provides an abstraction level similar to what is envisioned for xApps and the E2 interface.Source: A. dApps as Softwarized Containers · p. 4
- A resource manager lets containers access and share RAN-node resources, including CPUs, GPUs, and memory, while containerization facilitates AI solutions for lower protocol layers.The proposed standalone-app marketplace is intended to foster innovation and competition through openness.Source: A. dApps as Softwarized Containers · p. 4
B. Leveraging O-RAN Interfaces
The proposed integration adapts O-RAN interfaces and E2 Service Models to provide dApps with real-time RAN data and enrichment information from the near-RT RIC. Some required southbound interfaces are not yet available.
B. Leveraging O-RAN Interfaces
- Proposed southbound E2-like KPM Service Models would support dApp execution within 10 ms, although the required interfaces are not currently available.The authors propose adapting and extending E2 Service Models to support user-plane data-driven control.Source: B. Leveraging O-RAN Interfaces · p. 4
- DU dApps need RU frequency-domain waveform samples and locally available transport blocks or RLC packets, while CU dApps use local PDCP and SDAP data.The current O-RAN specifications do not envision data-driven control based on inference over user-plane data such as I/Q samples and packets.Source: B. Leveraging O-RAN Interfaces · p. 4
- Near-RT RIC enrichment information can reach dApps through E2, and dApps can be dispatched through O1.xApps process data from one or more gNBs and send enrichment information that dApps use for control decisions, such as scheduling, MCS, and beamforming.Source: B. Leveraging O-RAN Interfaces · pp. 4–5
C. Extending Conflict Mitigation to dApps
dApps require conflict mitigation across rApps, xApps, and dApps, alongside orchestration that selects applications and deployment locations according to operator intent, data timing, control capabilities, and available resources.
C. Extending Conflict Mitigation to dApps
- Pre-action resolution can prevent directly observable conflicts, while post-action verification can detect implicit conflicts through their impact on shared KPMs.The conflict-management scope includes interactions among rApps, xApps, and dApps; pre-action resolution is exemplified by the near-RT RIC approach [1].Source: C. Extending Conflict Mitigation to… · p. 5
D. Intent-based O-RAN Apps Orchestrator
- The non-RT RIC orchestration module translates operator goals and requirements into a set of cooperating O-RAN applications and dispatches them from a catalog to RAN locations.It may run as an rApp or as a standalone SMO component.Source: D. Intent-based O-RAN Apps Orchestrator · p. 5
- Orchestration selects applications and locations where input data meets timing needs, required controls are available, and physical resources suffice.For beam detection and traffic forecasting, the example places a dApp at the DU for I/Q samples and an xApp at the near-RT RIC for CU traffic KPMs.Source: D. Intent-based O-RAN Apps Orchestrator · p. 5
E. dApp Controller and Monitor
A near-RT RIC component monitors and controls dApps against QoS and operator intent. The paper also reports preliminary results showing reduced O-RAN interface overhead while supporting AI-based real-time RAN control.
E. dApp Controller and Monitor
- A near-RT RIC component controls and monitors gNB dApps to ensure they meet desired QoS levels and align with operator intent.As a possible extension, it could convert an xApp into atomic dApps for finer control, with non-RT RIC coordination and O1 dispatch.Source: E. dApp Controller and Monitor · p. 5
V. USE CASES AND RESULTS
- Preliminary results indicate that dApps can reduce overhead over O-RAN interfaces while supporting AI solutions for real-time RAN control.The section introduces relevant use cases but this passage supplies no numerical result.Source: §V · p. 5
A. Beam Management
dApps can run custom beam-management logic at the DU, where real-time access to I/Q samples supports inference that cannot readily be moved to the RIC. The cited E2 transfer analysis reports latency above the 10 ms real-time requirement in most cases.
A. Beam Management
- dApps can select which beams to use or explore, while xApps and rApps can provide higher-level guidance such as selecting and deploying an RU codebook.Source: A. Beam Management · p. 5
- DeepBeam uses deep learning on I/Q samples to infer Angle of Arrival and the transmitter's beam in a codebook, making it a candidate for DU-based dApp deployment.The DU can expose frequency-domain waveform samples in real time; transferring them elsewhere raises latency, privacy, and interface-traffic concerns.Source: A. Beam Management · pp. 5–6
- In most cases, E2 latency for I/Q-based beam management exceeds 10 ms; transferring the required samples can also exceed 100 Gbps in some configurations.The analysis assumes NR SRS parameters, including 3300 subcarriers, two symbols, 9-bit I/Q samples, and three monitored uplink beams per UE.Source: Figure 3 · p. 6, A. Beam Management · p. 6
B. Supporting Low-latency Applications
The examples show why real-time DU control matters: URLLC latency depends on the joint choice of slicing and scheduling, while running intelligence as dApps can reduce E2 traffic. The study compares DRL agents and forecasting models placed at either the near-RT RIC or DUs.
B. Supporting Low-latency Applications
- DU access to UE-specific buffer, MCS, and instantaneous SINR information supports real-time slicing and resource-allocation decisions based on QoS requirements and network conditions.Source: B. Supporting Low-latency Applications · p. 6
- Two DRL agents use buffer occupancy, throughput, and traffic demand to control scheduling and slicing for eMBB, MTC, and URLLC objectives.Two forecasting models predict UE traffic demand and transmission-buffer occupancy.Source: B. Supporting Low-latency Applications · p. 6
- dApps halve E2 traffic, with reductions up to 3.57× versus an xApps-only configuration.Two or more xApps can share the same E2 input, so traffic does not increase linearly with the number of xApps.Source: B. Supporting Low-latency Applications · p. 6, Figure 4 · p. 6
- The evaluation places the agents and forecasters either at the near-RT RIC as xApps, receiving E2 data, or at DUs as dApps, where data is locally available.OrchestRAN is used to distribute and dispatch the network intelligence according to operator intents.Source: B. Supporting Low-latency Applications · p. 6
- 4 ms end-to-end latency is reported for URLLC when more PRBs are reserved; PF gives the lowest latency below 30% reservation, while RR works best at higher reservations.The results support joint slicing and scheduling control under changing channel and network conditions.Source: Figure 5 · p. 6, B. Supporting Low-latency Applications · p. 7
VI. CONCLUSIONS
The paper proposes dApps at CUs and DUs to complement xApps and rApps with real-time control for parameters outside existing RIC timescales. It outlines an architectural extension and use cases, while identifying integration and vendor issues for further analysis.
VI. CONCLUSIONS
- dApps execute at DUs and CUs to complement xApps and rApps with real-time control for parameters that near-RT and non-RT control loops cannot otherwise optimize.Source: §VI · p. 7
- The paper discusses dApp benefits and challenges, proposes an architectural extension, and illustrates two use cases.Challenges include standardization, resources and softwarized platforms, and orchestration.Source: §VI · p. 7
- Further analysis is needed on data factories and digital twins for reliable AI, well-defined CU/DU interfaces, and reducing vendor friction.Source: §VI · p. 7