Open RAN dApp Architecture

• Open RAN dApp Architecture is a containerized, software-defined module that enables sub-millisecond closed-loop control of user-plane data in cellular networks.
• It leverages low-latency interfaces like E3 and orchestrates AI/ML inference at the DU/CU to implement real-time functionalities such as spectrum sharing and interference mitigation.
• The architecture supports diverse applications in 5G/6G by integrating secure, scalable control with hierarchical coordination via SMO, ensuring robust real-time performance.

Open RAN Distributed Application (dApp) Architecture

A Distributed Application (dApp) within the Open Radio Access Network (O-RAN) paradigm is a containerized, software-defined module designed for real-time operation at the Central Unit (CU) or Distributed Unit (DU) of next-generation cellular networks. dApps provide direct access to user-plane or physical-layer data (e.g., I/Q samples, channel state information, scheduling events), enabling programmable inference and closed-loop control at timescales (≪10 ms) well below those practical for xApps (near-real-time, 10–100 ms) and rApps (non-real-time, >1 s) hosted in RAN Intelligent Controllers (RICs). dApps leverage new southbound, low-latency interfaces such as E3 and high-bandwidth shared-memory brokers to implement functionalities including spectrum sharing, interference mitigation, real-time slicing, beam management, and integrated sensing and communication (ISAC). They are managed by the Service Management and Orchestration (SMO) layer, integrated with cloud-native O-RAN deployments, and support hierarchical control in coordination with xApps and rApps through standardized O-RAN interfaces (E1, F1, E2, A1, O1, O2) (Gangula et al., 2024, Polese et al., 31 Mar 2026, D'Oro et al., 2022, Lacava et al., 27 Jan 2025).

1. Motivation and Positioning of dApps in O-RAN

O-RAN disaggregates the Radio Access Network into RU (Radio Unit), DU (Distributed Unit), CU (Centralized Unit), and RICs (near-RT and non-RT). xApps and rApps have enabled closed-loop, data-driven network optimization but remain limited by their indirect access to user-plane data and by E2 interface latency constraints (>10 ms) (Polese et al., 2022). dApps address the need for sub-millisecond closed-loop operations—such as user scheduling, beamforming, spectrum sensing, and edge AI inference—by colocating executable logic adjacent to the real-time data path within the CU or DU (Lacava et al., 27 Jan 2025, Polese et al., 31 Mar 2026).

Key distinctions from xApps/rApps:

• dApps operate on raw, fine-granularity PHY/user-plane data (I/Q, CSI, SRS, RLC/PDCP buffers).
• dApps achieve deterministic, low-latency compute (Δt < 1 ms typical).
• dApps can directly actuate MAC/PHY parameters or influence real-time scheduling—unfeasible for control loops running via E2 from xApps.
• Hierarchical coordination ensures that policy and conflict-mitigation are enforced across all timescales (rApp/xApp/dApp).

2. Architecture: Components, Interfaces, and Data-Flow

A canonical dApp deployment comprises:

• RU (Radio Unit): Low-PHY, RF, and analog front-end.
• DU (Distributed Unit): High-PHY (e.g., OFDM, FFT/IFFT, channel estimation), MAC, RLC. Hosts the dApp alongside the protocol stack.
• E3 Agent: Sidecar or plugin to the DU, handling the E3 interface for dApp connectivity. Implements pub/sub for real-time metrics, I/Q sample transport (gRPC, shared memory), and control commands.
• dApp (Containerized): Executes AI/ML inference and closed-loop control on user-plane data at sub-frame intervals.
• CU (CP/UP split): Optionally hosts dApps for RRC/PDCP/SDAP or multi-DU control.
• RICs (Near-RT and Non-RT): xApps for network-scale, soft RT; rApps for management/policy intent.
• SMO (Service Management & Orchestration): AppPackage catalog, onboarding, deployment, scaling, lifecycle management. Manages resource allocation and conflict arbitration (Lacava et al., 27 Jan 2025, Polese et al., 31 Mar 2026).

Data-Flow Example (Spectrum Sharing) (Gangula et al., 2024):

1. OAI DU injects “sensing” symbols (0.35%) for background spectrum monitoring.
2. E3 agent extracts I/Q samples on trigger, transmits to dApp via gRPC/PROTOBUF.
3. dApp implements per-symbol or ML-based energy detection/inference.
4. dApp returns a list of PRBs to be barred; E3 agent updates scheduler in DU within TTI.
5. Reaction loop (I/Q → inference → control) executed in ≤1 ms.

Block Diagram (Representative):

$Δ_{p}$2

Interface Inventory (Lacava et al., 27 Jan 2025, Gangula et al., 2024, Polese et al., 31 Mar 2026):

Interface	Direction	Role
E3	DU↔dApp	Low-latency user-plane data/control
E2	DU/CU↔RIC (xApps)	KPI, control-plane exchange
A1	Non-RT RIC↔Near-RT	Policy/intent distribution
O1/O2	SMO↔All	Management, telemetry, lifecycle
F1/Xn	DU↔CU	Internal splits, transport

3. dApp Lifecycle, Real-Time Control, and Performance

Lifecycle Phases (Lacava et al., 27 Jan 2025, D'Oro et al., 2022):

1. Onboarding: SMO catalogues AppPackage, verifies digital signature, retains deployment descriptors.
2. Deployment & Configuration: SMO triggers O2 deployment, resources provisioned, dApp instantiated as a container.
3. Runtime Setup: dApp performs E3 Setup and Subscription for data and control primitives (setup, subscription, indication, control messages).
4. Real-Time Operation: At each sub-ms interval, E3 conveys I/Q samples; dApp executes inference and issues control (e.g., spectrum mask, scheduling weights).
5. Monitoring & Teardown: SMO and RIC monitor resource usage, KPIs, health; orchestrate upgrades or decommissions as needed.

Timing Constraints (Gangula et al., 2024, Lacava et al., 27 Jan 2025, Villa, 26 Jan 2026):

Let

• $T_{s}$: Sensing interval (e.g., 10 ms)
• $Δ_{p}$: Total dApp loop delay (extraction, inference, communication)
• $TTI$: Transmission Time Interval (1 ms or sub-ms)
• $Δ_{p} ≤ TTI$ for hard-real-time enforcement

Empirically, achievable $Δ_{p}$ is on the order of 0.4–3 ms, with commodity hardware and dedicated core pinning. Example: In X5G, total dApp loop $L_{total}$ is $400\,\mu$s for telemetry, inference, and action (Villa, 26 Jan 2026).

Performance Example (Villa, 26 Jan 2026):

• Static Throughput: 300 Mbps DL at short range
• Loop Latency: 0.4 ms for dApp+GPU RT control
• Multi-UE: 512 Mbps aggregate DL with four UEs under DDDSU TDD
• dApp Inference: 88% radar detection accuracy, $<0.2$ ms inference per batch

4. Programmability, Software Enablement, and Security

dApp execution environment requirements:

• Containerized deployment (Docker, Kubernetes), managed via O2 and O-Cloud resource orchestrators (Lacava et al., 27 Jan 2025).
• High-performance, sandboxed runtimes to isolate dApps from RAN core logic (e.g., WebAssembly with gas metering, memory sandboxing) (Esper et al., 18 Mar 2026).
• OS-level binding to kernel user-space APIs for fine-grained telemetry and actuation (e.g., perf_event, cgroups for CPU, cpufreq for DVFS) without kernel modifications (Crespo et al., 1 Aug 2025).
• GPU/FPGA/NPU support for low-latency AI inference in ISAC, positioning, and beam management (Villa, 26 Jan 2026, Polese et al., 31 Mar 2026).
• Hostcall limitations, digital signing, and modular isolation for robust security against denial-of-service or code injection (Esper et al., 18 Mar 2026).

Programmability Features:

• Rapid deployment pipeline: Python/C++/Go modules, containerized via Helm charts, onboarded to Cloud-Native Functions catalog (Santos et al., 2024).
• Dynamic subscription and control via E3 API, with comprehensive support for standardized data models (protobuf, ASN.1 for control/indication).
• Life-cycle hooks (startup, failure, upgrade) orchestrated via SMO, with monitoring through O1 for observability KPIs.

Isolation Overhead (empirical) (Esper et al., 18 Mar 2026):

Environment	Median Latency ($\mu$s)	CPU (%)	Memory (MB)
Bare-metal	105	12	25
Docker	113	20	72
Wasm Sandbox	149	16	94

The data indicate strong isolation with moderate overhead, preserving low-latency guarantees needed for dApp control loops.

5. Hierarchical and Collaborative Control: Integration with RICs and SMO

dApps are part of a multi-tier, hierarchically orchestrated O-RAN control architecture (Giannopoulos et al., 21 Mar 2026, Lacava et al., 27 Jan 2025):

• Layer 1: dApps (CU/DU, Δt <10 ms): Real-time control of user-plane, e.g., scheduling, interference avoidance, beam switching. Example: CollabORAN “FredApp” for proportional-fair scheduling based on xApp PRB compatibility constraints (Giannopoulos et al., 21 Mar 2026).
• Layer 2: xApps (Near-RT RIC, 10 ms–1 s): Higher-level optimizations—e.g., interference hypergraph coloring, mobility, slice-level resource control. xApps relay constraints and policies to dApps via extended E2SMs.
• Layer 3: rApps (Non-RT RIC/SMO, >1 s): Policy, AI/ML model updates, resource orchestration, intent distribution.

Arbitration/Conflict Management:

• Priority or weighted sharing enforced within the SMO or near-RT RIC, with explicit policies for resource contention on shared PRBs or scheduling actions (Lacava et al., 27 Jan 2025).
• dApps publish inference results and resource intents upstream for coordinated decision-making (e.g., slice, user, or traffic class based differentiation).

Closed-Loop Example (Polese et al., 31 Mar 2026):

1. DU emits I/Q to dApp via E3 ($T_{E3} \approx 50\,\mu$s).
2. dApp runs AI inference ($Δ_{p}$0 ms).
3. Post-process, emit event or control to xApp (E2).
4. xApp performs multi-node fusion, sends reconfig commands to DU/dApp (total $Δ_{p}$1 20 ms).

6. Use Cases and Experimental Demonstrations

Real-Time Spectrum Sharing (Gangula et al., 2024):

• dApp extracts background sensing symbols, executes energy- or ML-based incumbent detection.
• Barred PRB list enforced in the scheduler on detection, avoiding dedicated SAS/ESC infrastructure for CBRS.
• Sensing overhead ≤0.35%; throughput only impacted for PRBs assigned to incumbent protection.

ISAC and Positioning (Polese et al., 31 Mar 2026, Lacava et al., 27 Jan 2025):

• Edge-hosted dApps with direct I/Q and CSI access enable range/velocity estimation, target classification in 5G/6G.
• Uplink CIR-based dApp with subspace ML algorithms achieves sub-meter localization accuracy.

CPU/Energy-Aware RAN Orchestration (Crespo et al., 1 Aug 2025):

• dApp autonomously orchestrates DU thread-core mapping, CPU frequency, and isolation.
• Achieves up to 49% dynamic power savings in srsRAN without impacting throughput or violating 1 ms TTI deadlines.

Scalability and Interoperability (Villa, 26 Jan 2026):

• Multiple dApps per DU (demonstrated up to 4 per GPU in X5G), multi-vendor RAN elements (OAI, Foxconn RU, NVIDIA Aerial, OSC RIC) interconnected via open standards.
• Container orchestration allows elastic scaling and seamless upgrades.

7. Design Challenges, Lessons Learned, and Future Directions

Challenges and Solutions:

• Synchronization: Per-symbol buffer alignment solved via direct access to stack-internal ring-buffers (Gangula et al., 2024).
• Latency/bandwidth: Co-location and core pinning, high-performance IPC/gRPC, and GPU offload for inference are effective (Villa, 26 Jan 2026).
• Scheduler consistency: Guarding updates at slot boundaries, atomic PRB masking (Gangula et al., 2024).
• Scalability: Pub/sub architecture (E3), resource quotas, priority scheduling for dApp container instances (Lacava et al., 27 Jan 2025).
• Security: Strong isolation via sandboxing (Wasm), capability-limited hostcalls, module attestation, and memory bounds-checking (Esper et al., 18 Mar 2026).

Lessons and Guidelines:

• High-bandwidth, programmable DU-local interfaces (E3) are essential for sub-ms control and ISAC workloads (Polese et al., 31 Mar 2026).
• Modular, cloud-native dApp packaging enables rapid deployment, multi-vendor support, and robust lifecycle management (Lacava et al., 27 Jan 2025).
• Event-driven, asynchronous design meets tight control latency requirements.
• Emerging design patterns include hybrid AI workloads—AI-RAN Orchestrator manages cohabitation of connectivity and compute at AI-RAN sites via open interfaces and container orchestration (Polese et al., 9 Jul 2025).
• Future directions: accelerated ML inference at the DU, multi-tenancy with strong resource isolation, AI-native ISAC loops, and real-time device dApps for metaverse/AR/VR (Villa, 26 Jan 2026, Polese et al., 31 Mar 2026).

Use Case Generalization (Gangula et al., 2024):

• Real-time spectrum sharing, unlicensed band co-existence, radar sensing, uplink interference monitoring, dynamic RAN slicing.

Summary:

O-RAN dApps represent a critical evolution in programmable wireless infrastructure, bridging the gap between slow, control-plane-centric optimization and latency-critical real-time user-plane control. By embedding AI-native logic adjacent to the radio protocol stack and leveraging open, low-latency interfaces, dApps are poised to enable new network intelligence and responsiveness for 5G, 6G, and beyond (Gangula et al., 2024, Villa, 26 Jan 2026, Polese et al., 31 Mar 2026, Lacava et al., 27 Jan 2025, Esper et al., 18 Mar 2026, Crespo et al., 1 Aug 2025).