PaperlayerView exact revision on arXiv

Source-linked AI summary

dApps: Enabling Real-Time AI-Based Open RAN Control

Andrea Lacava, Leonardo Bonati, Niloofar Mohamadi, Rajeev Gangula, Florian Kaltenberger, Pedram Johari, Salvatore D'Oro, Francesca Cuomo, Michele Polese, Tommaso Melodia

arXiv:2501.16502v2cs.NI

TL;DR

O-RAN’s RIC-based loops lack user-plane access and sub-10 ms control, motivating dApps deployed alongside RAN nodes. The paper specifies their architecture and interfaces, then demonstrates OAI-based real-time positioning and spectrum sharing with control loops below 450 microseconds.

  • Problem

    Existing O-RAN xApps and rApps lack user-plane programmability and control loops faster than 10 ms, limiting lower-layer real-time applications.

  • Method

    The paper proposes a dApp reference architecture with lifecycle management, E3 and E2SM-DAPP interfaces, and an open-source OAI framework for real-time RAN control.

  • Results

    The OAI framework demonstrates real-time positioning and spectrum sharing, with average control loops slightly below 400 µs and loops under 450 µs overall.

  • Takeaways & Limitations

    dApps enable real-time control and user-plane interaction in O-RAN while coordinating with existing RIC-based control.

  • Takeaways & Limitations

    The evaluated spectrum-sharing implementation uses a type 1 scheduler that can unnecessarily reduce the PRBs available for data transmission.

Abstract

from arXiv · show

Open Radio Access Networks (RANs) leverage disaggregated and programmable RAN functions and open interfaces to enable closed-loop, data-driven radio resource management. This is performed through custom intelligent applications on the RAN Intelligent Controllers (RICs), optimizing RAN policy scheduling, network slicing, user session management, and medium access control, among others. In this context, we have proposed dApps as a key extension of the O-RAN architecture into the real-time and user-plane domains. Deployed directly on RAN nodes, dApps access data otherwise unavailable to RICs due to privacy or timing constraints, enabling the execution of control actions within shorter time intervals. In this paper, we propose for the first time a reference architecture for dApps, defining their life cycle from deployment by the Service Management and Orchestration (SMO) to real-time control loop interactions with the RAN nodes where they are hosted. We introduce a new dApp interface, E3, along with an Application Protocol (AP) that supports structured message exchanges and extensible communication for various service models. By bridging E3 with the existing O-RAN E2 interface, we enable dApps, xApps, and rApps to coexist and coordinate. These applications can then collaborate on complex use cases and employ hierarchical control to resolve shared resource conflicts. Finally, we present and open-source a dApp framework based on OpenAirInterface (OAI). We benchmark its performance in two real-time control use cases, i.e., spectrum sharing and positioning in a 5th generation (5G) Next Generation Node Base (gNB) scenario. Our experimental results show that standardized real-time control loops via dApps are feasible, achieving average control latency below 450 microseconds and allowing optimal use of shared spectral resources.

1. Introduction

O-RAN RIC applications support data-driven control but are limited by control-plane focus and 10 ms timescales. The paper introduces dApps as a practical extension for real-time, user-plane-aware control and evaluates an OAI framework.

  • Current O-RAN capabilities: O-RAN xApps and rApps adapt RAN operations across use cases such as slicing, traffic steering, beamforming, mobility, and spectrum allocation.They use RAN data and control interfaces to respond to changing channels, traffic, mobility, and utilization.
  • Current O-RAN limitations: Control-plane focus and the 10 ms lower timescale limit access to user-plane data and lower-layer applications.The limitations affect use cases including RF fingerprinting, beam steering, anomaly detection, and spectrum sensing.
  • dApp motivation: dApps colocated with CUs and DUs bring user-plane data and below-10 ms AI/ML routines directly to RAN nodes.They can execute real-time operations without involving RICs and support lightweight lifecycle management.
  • Architecture and interfaces: The paper defines a reference architecture and lifecycle management for dApps, integrating them with O-RAN through E2SM-DAPP and the novel E3 interface.E3 supports real-time data and control exchange with DUs and CUs, while E2 enables interaction with the Near-RT RIC.
  • Framework evaluation: dApps operate within real-time intervals, processing vector and scalar data in loops below 450 microseconds in the OAI framework.The framework was evaluated on Colosseum and Arena and released as open source.
  • Demonstrated use cases: The framework demonstrates positioning from UE uplink CIR data and spectrum sharing through real-time incumbent detection at a 5G gNB.Both use cases use customizable processing routines deployed through the proposed dApp framework.

2. Related Work and Comparison with Real-time RIC

Prior work explored real-time RAN control through real-time RICs, zApps, tApps, and codelets. This paper instead provides a complete dApp architecture and interoperability design, compared with those alternatives and Janus.

  • Position relative to prior dApp work: The paper advances prior dApp work from motivating tighter control loops to specifying a complete reference architecture and interoperable interfaces.It focuses on practical integration with the rest of O-RAN and demonstrates use cases relevant to Open RAN.
  • Real-time RIC alternatives: Real-time RIC proposals embed or colocate CU/DU functions and host specialized applications such as zApps and tApps.These proposals provide alternative ways to bring inference and control closer to RAN functions.
  • Comparison with Janus: Janus loads real-time codelets directly on CUs and DUs, whereas dApps interface with the protocol stack rather than requiring direct stack access.The distinction can reduce the need for vendors to host third-party code inside the CU/DU implementation.
  • Comparison framework: Table 1 summarizes differences between dApps, real-time RIC-based solutions, and Janus.The comparison is presented as a synthesis of architectural distinctions and proposal advantages.

3. The Role of dApps in the Hierarchical O-RAN Control Architecture

O-RAN currently combines non-real-time and near-real-time control but lacks sub-10 ms loops and user-plane programmability. dApps extend this hierarchy with secure, lightweight access to RAN-node data and control.

  • Architectural limitations: Existing loops lack control faster than 10 ms and interaction with user-plane data such as waveforms, PDUs, transport blocks, RLC packets, and PDCP packets.These limitations constrain fine-grained inference and control across lower protocol layers.
  • Why dApps are needed: Transferring I/Q samples through E2 can take seconds under rate limitations, making xApp/rApp loops unsuitable for real-time user-data control.Security, privacy, timing, and bandwidth constraints prevent efficient extraction of such data from the RAN.
  • dApp role: dApps provide lightweight, plug-and-play services with secure real-time access to the RAN stack without the overhead of an additional real-time RIC.They bring programmability and observability directly to RAN nodes.
  • Supported use cases: dApps support use cases spanning waveform and PDU processing, real-time scheduling and beam management, node and fronthaul configuration, and sensing or channel estimation.Examples include spectrum sensing, CPU configuration, CSI compression, positioning, and custom channel-estimation models.

4. dApp Service-based Architecture and Integration with RAN Nodes

The architecture extends O-RAN with dApps as pluggable RAN-node microservices connected through E3, while E2SM-DAPP bridges their data and inference with xApps. E3 supports real-time data access, subscriptions, control actions, and coordination across dApps and RAN functions.

  • 4. dApp Service-based Architecture and Integration with RAN Nodes: E3 integrates dApps with DU/CU RAN nodes and bridges them to E2 for cooperation with xApps.The E3 API and E3 Agent provide the software and communication components for this integration.
  • 4.1. dApps Data, Telemetry, and Control Flows: dApps can access RAN telemetry and user-plane data, including I/Q samples, buffer reports, channel-quality information, transport blocks, and protocol data units.Data can be streamed or polled with configurable periodicity, granularity, and policies.
  • 4.1. dApps Data, Telemetry, and Control Flows: dApps provide short-interval control actions for RAN functions, including configurable aspects of the DU MAC scheduler.The architecture specifies control application within intervals such as 0.5 ms after a configuration is selected.
  • 4.1. dApps Data, Telemetry, and Control Flows: The E3 Agent consolidates RAN-data access and manages pairing, subscriptions, de-registration, resource monitoring, and coordination among multiple dApps.Multiple dApps may interact with one RAN function when their actions do not conflict.
  • 4.3. dApp and RAN interactions over E3: E3AP establishes dApp associations through setup and subscription procedures that authenticate, pair, and expose supported data and control functionality.E3 service models define indication messages for RAN-to-dApp data and APIs for delivering dApp-generated control to RAN functions.
  • 4.4. E2SM-DAPP: a service model for managing interactions between dApps and xApps: E2SM-DAPP allows xApps to discover dApps and receive their inference results over E2, including spectrum-sensing, channel-estimation, and scheduling information.dApps collect real-time RAN data, perform near-real-time inference, and transmit results through the E3 Report API and E2 indications.

5. dApp Lifecycle and Interaction with Near-RT RIC, Non-RT RIC, and SMO

dApp lifecycle management extends O-RAN application practices across development, onboarding, and operations, with deployment directly on CU/DU nodes through the SMO and O-Cloud. The lifecycle also supports xApp-triggered deployment, although the required O-RAN procedures are not yet available.

  • 5. dApp Lifecycle and Interaction with Near-RT RIC, Non-RT RIC, and SMO: dApp lifecycle management follows development, onboarding, and operations phases, with Fig. 6 emphasizing onboarding and production management.The process extends O-RAN lifecycle specifications for application cloudification and orchestration.
  • 5.2. Onboarding: Onboarding verifies the dApp package, stores its components in the SMO catalog, and publishes certified configurations to a runtime library.Digital signatures and checksums support package integrity during transitions between environments.
  • 5.2. Onboarding: xApp-initiated onboarding is not explicitly represented because the required ad-hoc service models, procedures, and functionalities are absent from current O-RAN specifications.The paper identifies these mechanisms as future research.
  • 5.3. Deployment: dApps are deployed as Cloud-Native Functions directly on DU/CU nodes rather than through the Near-RT or Non-RT RICs.The SMO and O-Cloud use the O2 interface to communicate with CU/DU Deployment Management Services.
  • 5.3. Deployment: The SMO decomposes deployment requests, determines parameters, retrieves the dApp descriptor, allocates resources through the DMS, and monitors the resulting instance.After instantiation, the dApp reads its configuration and begins operation while the SMO tracks lifecycle status and performance.
  • 5.2. Onboarding: xApps can request SMO deployment and connection of a dApp when real-time control is needed.This extends the deployment procedure beyond operator- or SMO-initiated onboarding.

6. A Reference Open-Source dApp Framework

The paper presents an open-source Python dApp framework based on OAI, with modular classes, configurable connectivity, structured messaging, and real-time control benchmarking.

  • Framework architecture: The framework defines DApp, E3Interface, and E3Connector classes for implementing diverse dApp functions and use cases.The DApp abstraction supports use-case-specific child classes, including SpectrumSharingDApp and PositiningDApp.
  • Connectivity and messaging: E3Connector manages pairing and message exchange between dApps and RAN nodes through dedicated sockets for setup, subscription, indication, and control operations.The framework uses ASN.1-defined PDUs for structured RAN message formatting.
  • Connectivity and messaging: The framework implements POSIXConnector and ZMQConnector variants with TCP, IPC, and SCTP transport options for local and remote communication.The transport implementations prioritize reliable delivery, while IPC targets low-overhead same-host control.
  • Transport evaluation: IPC eliminates transport overhead for same-host communication, whereas TCP adds 20% overhead and SCTP can increase latency and reduce goodput.The comparison motivates IPC as the preferred option for real-time control over the same host.
  • Messaging design: The framework uses a minimalist extensible ASN.1 E3AP-SM design with Setup, Subscription, Indication, and Control PDUs, encoded using PER to reduce overhead.The implementation balances structured messaging for dApp-RAN interactions against ASN.1 padding and structure overhead.
  • Real-time benchmarking: 400 µs average aggregated latency, consistently below 450 µs, demonstrates real-time control loops in the dApp prototype.The benchmark evaluates the complete control loop, with ZeroMQ-based IPC reducing socket-operation impact.

7. Empowering RAN control through dApps: use cases

The paper demonstrates dApp-based real-time control for spectrum sharing and positioning, using RAN-local data to support sensing, inference, and control actions. In spectrum sharing, PRB blacklisting enables coexistence with incumbents while preserving throughput, whereas positioning uses uplink channel measurements for ranging.

  • Spectrum sharing: The spectrum-sharing dApp detects incumbent activity from sensed I/Q samples and blocks affected PRBs so 5G communication can coexist with the incumbent.The control action is delivered to the RAN scheduler, vacating the interfered spectrum.
  • Spectrum sharing: The OAI type 1 scheduler can unnecessarily block rightmost PRBs because each UE allocation must remain contiguous, leaving evaluation of type 0 allocation for future work.Type 0 allocation would allow noncontiguous PRBs but was not implemented in OAI at the time of writing.
  • Spectrum sharing: 71.34 Mbps without the dApp versus 71.53 Mbps with it in Colosseum shows throughput parity when no incumbent is present.The reported confidence intervals indicate minimal dApp overhead and performance within the same confidence range.
  • Spectrum sharing: Nearly 50% lower UE throughput occurs without spectrum sharing when an incumbent is present, while the dApp prevents disruptive interference by blacklisting affected PRBs.The paper attributes the improvement to reduced errors and retransmissions after interfered PRBs are excluded.
  • Positioning: The positioning dApp extracts uplink channel impulse responses for ranging, evaluating distance-error CDFs from 48,000 measurements at an uplink SNR of −20 dB.Measurements cover UE positions from 3 to 10 meters, with 6,000 samples collected at each 1-meter increment.

8. Conclusions

The paper presents dApps as an O-RAN extension for real-time RAN control and user-plane interaction, with an OAI-based open-source implementation. Its use cases demonstrate spectrum sharing and sub-millisecond positioning control, while future work extends the framework to additional open stacks and continuous testing.

  • Architecture and framework: The dApp architecture enables real-time RAN control and user-plane interaction through lightweight services co-located with CUs and DUs.The architecture includes APIs coordinated by an E3 agent and lifecycle procedures involving the RICs and SMO.
  • Use cases: The open-source OAI framework supports spectrum sensing, PRB avoidance, and UE ranging through dApp-driven real-time control loops.The spectrum-sharing dApp coordinates with the DU scheduler, while the positioning dApp processes uplink reference signals.
  • Performance: Slightly less than 400 µs average control-loop duration demonstrates sub-millisecond real-time operation in the implementation.The reported positioning workflow processes uplink reference signals to extract the channel response and perform ranging.
  • Future work: Future work extends the framework to NVIDIA ARC-OTA and continuous integration, deployment, and testing on an up-to-date gNB protocol stack.

Appendix A. dApp Deployment Process

The appendix defines dApp deployment as an SMO-managed lifecycle in which validated packages are configured and instantiated on CU/DU hosts. Deployment services maintain inventory and status, with failure notifications triggering corrective action.

  • Roles and lifecycle: The SMO orchestrates dApp deployment, configuration, and lifecycle management, while CU and DU nodes provide hosting resources.
  • Prerequisites: Deployment assumes operational SMO and CU/DU components, a validated package in the SMO runtime library, and a pre-configured DU ready to host dApps.
  • Deployment process: The SMO receives a deployment request, decomposes it into dApp instances and ordering, and identifies the target CU or DU.
  • Deployment process: The SMO configures environment variables, network policies, and access parameters before DMS deploys the dApp containers and returns a Deployment ID.
  • Operational state: A successful deployment leaves the dApp running on the CU/DU with updated SMO inventory and lifecycle management, while failures are reported for corrective action.
Loading 2501.16502v2…