---
title: Open RAN dApp Architecture Overview
url: https://www.emergentmind.com/topics/open-ran-dapp-architecture
type: topic
---

# Open RAN dApp Architecture Overview

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 [2501.16502][2203.02370][2407.05027][2508.00629][2202.01032].

## 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 [2501.16502][2203.02370]:

```
[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) [2501.16502].
  - Sub-ms deterministic control loop suitable for per-TTI scheduling, spectrum sharing, or time-critical ML inferences [2407.05027][2501.16502][2203.02370].

- **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 [2205.13178].
  - Hierarchical coordination: xApps/rApps issue control policies/statistical summaries that may parameterize or resolve conflicts among dApps [2501.16502][2407.05027].

- **A1 and O1/O2 Interfaces:** Used for policy, ML, and management plane orchestrations. O1/O2 initiated dApp deployment, health/status, and resource package delivery [2508.00629][2501.16502].

## 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 [2501.16502][2508.00629][2205.13178].
- 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 [2508.00629][2501.16502].
  
## 4. Timing, Performance, and Optimization Formulations

- **Critical Timescales:**
  - dApp: T_loop ≤ 1 ms; empirical mean T_total ≈ 400 μs (I/Q spectrum dApp) [2501.16502][2407.05027].
  - Near-RT RIC xApps: 10 ms – 1 s [2205.13178][2407.09619]. 
  - 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 [2407.05027][2501.16502].
  - 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 [2508.00629].
- **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 [2501.16502].
- 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”)** [2407.05027][2501.16502]:
  - 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** [2508.00629]:
  - 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 [2203.02370][2501.16502].
- 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 [2205.13178][2501.16502].
- 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 [2501.16502][2203.02370][2508.00629].

Source: https://www.emergentmind.com/topics/open-ran-dapp-architecture