Open RAN dApp Architecture Overview

• Open RAN dApp Architecture is a framework integrating sub-10ms microservices within the CU/DU for direct, low-latency control using an E3 interface.
• It enables real-time inference and efficient spectrum sharing through containerized microservices and hierarchical coordination with xApps and rApps.
• Leveraging standards like ASN.1 PER coding and IPC mechanisms, dApps achieve deterministic control loops that enhance URLLC and optimize resource utilization.

Open RAN Distributed Application (dApp) Architecture defines the integration of sub-10 ms intelligent, user-plane–centric microservices directly within the O-RAN CU/DU stack, augmenting the RAN Intelligent Controller (RIC) model of xApps (near-real time) and rApps (non-real time) for fine-grained, low-latency control and inference tasks. dApps operate alongside, but below, the near-RT RIC, utilizing a purpose-built E3 interface to access real-time RAN internals such as I/Q samples, PDUs, and resource scheduling primitives while supporting hierarchical interaction (via the E2 interface) with higher-level xApps and rApps. The dApp architecture is designed for open, disaggregated RAN deployments and is enabled by advances in O-RAN containerization and open messaging standards (Lacava et al., 27 Jan 2025, D'Oro et al., 2022, Gangula et al., 6 Jul 2024, Crespo et al., 1 Aug 2025, Polese et al., 2022).

1. Architectural Overview and Key Elements

The canonical Open RAN dApp deployment consists of:

• The Service Management and Orchestration (SMO) controlling lifecycle, policy, and ML model distribution for all RAN functions (using O1 and O2 interfaces).
• The Non-RT RIC (part of SMO): orchestrates long-timescale intent, A1 policy, and ML models.
• The Near-RT RIC (hosted in edge clouds): executes xApps within 10 ms–1 s control windows and maintains E2 interfaces to O-DU/O-CU nodes.
• The Central Unit (CU) and Distributed Unit (DU): host the RAN protocol stack and instantiate dApp containers, each co-located for direct, low-latency access to user-plane data and real-time resource actuation.
• The Open Radio Unit (O-RU): digital front-end connected via split 7.2x fronthaul.
• The E3 Agent: exposes a service-based local API (E3-AP) to onboard, coordinate, and manage dApps in the user-plane domain.

Textual block layout for a typical dApp-enabled O-RAN system (Lacava et al., 27 Jan 2025, D'Oro et al., 2022):

[non-RT RIC/rApps/SMO] --A1--> [near-RT RIC/xApps] --E2--> [CU/DU <-> dApp(s)] --F1/Open Fronthaul--> [RU] | [E3-Agent/API] ^ [Local dApp(s)]

E3 and E2 interfaces are both grounded in ASN.1 PER-coded message schemas; E3, however, uses IPC/UNIX sockets for sub-ms latency, while E2 rides SCTP/ETH transport (>1 ms RTT typical).

2. Protocols, Interfaces, and Service Models

• E3 Interface: An intra-CU/DU, service-based IPC layer:
  • Primitives: Setup, Subscription, Indication, Control, Report.
  • ASN.1 PER-encoded messages for efficient, zero-copy transport:

  • E3ServiceMessage ::= SEQUENCE { procedureID INTEGER (0..255), transactionID INTEGER (0..65535), dAppID OCTET STRING (SIZE(16)), payload OCTET STRING }

  • Maximum observed round-trip <450 μs (for typical I/Q transfer/control cycles) (Lacava et al., 27 Jan 2025).
  • Sub-ms deterministic control loop suitable for per-TTI scheduling, spectrum sharing, or time-critical ML inferences (Gangula et al., 6 Jul 2024, Lacava et al., 27 Jan 2025, D'Oro et al., 2022).
• E2 Interface: RIC–RAN signaling supporting:
  • REPORT, CONTROL, INSERT, and POLICY services with per-RAN-function E2 Service Models (KPM, RC, etc.).
  • SCTP-based, typically 5 ms RTT lab baseline (Upadhyaya et al., 2022).
  • Hierarchical coordination: xApps/rApps issue control policies/statistical summaries that may parameterize or resolve conflicts among dApps (Lacava et al., 27 Jan 2025, Gangula et al., 6 Jul 2024).
• A1 and O1/O2 Interfaces: Used for policy, ML, and management plane orchestrations. O1/O2 initiated dApp deployment, health/status, and resource package delivery (Crespo et al., 1 Aug 2025, Lacava et al., 27 Jan 2025).

3. Software, Hardware, and Deployment Stack

• dApps are containerized microservices managed via Kubernetes and packaged as Docker/OCI images—deployed by the SMO/O-Cloud DMS, adhering to O-RAN WG10/6 (O1/O2) specifications (Lacava et al., 27 Jan 2025, Crespo et al., 1 Aug 2025, Upadhyaya et al., 2022).
• Each CU/DU node embeds:
  • E3 Agent/Connector (IPC API over UNIX sockets or ZeroMQ).
  • dApp containers (Python/C++/C/ONNX runtime as use-case dictates).
  • Standard RAN stack: srsRAN, OAI, or similar (srsRAN binaries: ENB/GNB/UE; SDR: USRP X310, N310, B210, etc.).
  • Typical server: Intel Core-i9 8–16 cores (SMT off for RAN, best real-time isolation, AVX-512 enabled).
• dApp orchestration/telemetry: automated by the near-RT RIC’s dApp Controller Monitor and DMS, with health monitored via O1 (Crespo et al., 1 Aug 2025, Lacava et al., 27 Jan 2025).

4. Timing, Performance, and Optimization Formulations

• Critical Timescales:
  • dApp: T_loop ≤ 1 ms; empirical mean T_total ≈ 400 μs (I/Q spectrum dApp) (Lacava et al., 27 Jan 2025, Gangula et al., 6 Jul 2024).
  • Near-RT RIC xApps: 10 ms – 1 s (Upadhyaya et al., 2022, Santos et al., 12 Jul 2024).
  • Non-RT RIC: >1 s (policy/ML training).
• Key Metrics (by dApp use-case):
  • Spectrum sharing: sub-ms latency from sensing to PRB nulling, >99% detection accuracy, precise throughput loss proportional to PRB mask (Gangula et al., 6 Jul 2024, Lacava et al., 27 Jan 2025).
  • CPU orchestration: Energy $E(\pi, \mathbf{f}, \mathbf{I}) = \sum_i P(f_i) u_i$, minimized subject to slot-level latency and throughput (TTI-constrained), yielding ≃49% power savings, +1.5 IPC, −60% context switches (Crespo et al., 1 Aug 2025).
• Control Loop Formulation:

  $$T_{\text{loop}} = T_{\text{collect}} + T_{\text{process}} + T_{\text{create}} + T_{\text{deliver}} \leq 450~\mu\text{s}$$

• User-Plane Data Paths: dApp measurement collectors subscribe to RAN telemetry (I/Q samples, KPM), ingest data via shared buffers, and submit control actions synchronously to the MAC/scheduler.

5. Hierarchical Integration, Conflict Resolution, and Lifecycle

• dApp, xApp, and rApp actions are managed in a strict temporal hierarchy:
  • Tier 1: rApp/SMO (>1 s) — global policy, slice/intent, ML model deployment.
  • Tier 2: xApp/near-RT RIC (10 ms–1 s) — mid-level RRM policies; orchestrates dApps via E2SM-DAPP.
  • Tier 3: dApp/CU-DU (<10 ms) — per-TTI/symbol actuation and user-plane inference.
• Control actions annotated by sourceID, priority; local E3 Agent arbitrates and merges (e.g., PRB nulling), resolving conflicts at execution; unresolved conflicts escalate via E2 Indication to xApps for higher-level policy intervention (Lacava et al., 27 Jan 2025).
• Lifecycle: dApp undergoes SMO onboarding, operator deployment via DMS/O2, configures E3 callbacks, and enters runtime loop. All management plane actions instrumented for roll-back, versioning, and security.

6. Use Cases: Spectrum Sharing and CPU Orchestration

• Spectrum Sharing (CBRS “listen-while-talking”) (Gangula et al., 6 Jul 2024, Lacava et al., 27 Jan 2025):
  • dApp subscribes to periodic reserved symbols on NR gNB TDD, collects I/Q, computes per-PRB energy

  $$E_p = \frac{1}{N} \sum_{n=1}^N (I_{p,n}^2 + Q_{p,n}^2)$$

  issues barred PRB set to gNB scheduler via E3, ensuring one-TTI spectrum vacation (<1 ms total path). - Measured: Sub-ms cycle, throughput impacted strictly according to PRB removal.

• Energy-Aware CPU Orchestration (Crespo et al., 1 Aug 2025):
  • dApp on O-DU uses Linux perf to monitor context switches, IPC, MPKI, core utilization.
  • Solves online optimization:

  $$\min_{\pi, \{f_i\}, \{I_i\}} E(\pi, \mathbf{f}, \mathbf{I})$$

  s.t. latency (per TTI) and throughput constraints. Implements thread pinning, dynamic DVFS, and isolation using standard Linux APIs (sched_setaffinity, cpufreq, isolcpus).

7. Comparison to xApps/rApps, Scalability, and Best Practices

Application Class	Timescale	Data/Control Access	Principal Interface(s)
rApp	>1 s	Policy/intent orchestration, ML model train	A1, O1, O2
xApp	10 ms–1 s	Near-RT RRM (KPM, handover, slicing)	E2 (KPM, RC)
dApp	sub-10 ms	Per-slot/symbol MAC/PHY, direct I/Q/CPU/UE	E3, E2SM-DAPP, IPC

• dApps complement, not replace, existing xApps/rApps, enabling ultra-fine control in URLLC, beam management, CPU scheduling, and spectrum sharing (D'Oro et al., 2022, Lacava et al., 27 Jan 2025).
• All dApps must conform to strict container security, signed package management, SMO-driven onboarding, and real-time OS resource isolation.
• Table-driven onboarding, descriptor/lifecycle management, versioned OIDs for service models, and standardized ASN.1 PER compilation are mandatory for cross-vendor operation (Upadhyaya et al., 2022, Lacava et al., 27 Jan 2025).
• Best practices include instrumenting end-to-end loop latency, conflict-aware policy merging, autoscaling based on resource telemetry, and leveraging “E2SM-DAPP” for seamless xApp–dApp collaboration.

---

Open RAN dApp architecture thus provides a framework for real-time, user-plane–aware, programmable control and inference in open, disaggregated cellular RANs, reaching timescales, use cases, and data domains inaccessible to higher-layer RAN controllers (Lacava et al., 27 Jan 2025, D'Oro et al., 2022, Crespo et al., 1 Aug 2025).