dApp Framework

dApps are real-time, 3^rd party applications that can analyze L1/L2 data from the RAN and use it to control RAN functionality. ACAR captures data using Data Lake and implements a dApp Framework through which dApps can register/deregister themselves, subscribe to and access Data Lake data, and send commands to control ACAR behavior (see Figure 1). dApps communicate with the dApp Framework using a pre-standard version of the E3 interface and E3 Application Protocol (E3AP).

Figure 1: dApp: High level operation

dApps run on the O-DU and extend its functionality. On GPUs that support MIG (Multi-Instance GPU), dApps and ACAR run in different MIG instances, providing process and memory isolation while maintaining low latency data exchange via CPU shared memory. Running on the same GPU-based HW as ACAR enables dApps to run low latency AI/ML inference to analyze data from Data Lake and to determine actions to be sent to control the RAN.

Figure 2: dApp hardware and software architecture

Software Components

dApp functionality is split among 4 main components in the O-DU, as shown in Figure 3.

1. DU-Low, which runs L1 pipelines, Data Lake and an E3 Agent

2. DU-High, which runs L2 and higher layer components. OpenAirInterface is used as an example L2+ stack

3. CPU Shared Memory (CPU SHM)

4. One or more co-located dApps

Figure 3: dApp components

DU-Low

DU-Low functionality is provided by ACAR. Figure 3 shows 3 main components:

1. CUDA Pipeline: The figure shows a single PUSCH L1 pipeline for simplicity, which receives FH (Fronthaul) data from an RU and processes it into CRC-checked data blocks.

2. Data Lake: Captures FH I/Q samples and other L1/L2 data from intermediate processing blocks and metadata. The data is captured in real time to memory. Data writes alternate between 2 buffers (ping and pong). When one buffer is full, writes begin to the other buffer and data from the full buffer is read out to a ClickHouse database configured in RAM tables or in SSD storage.

3. E3 Agent: Interfaces ACAR functionality with one or more dApps. It runs alongside the real-time data path in DU-Low, receives notifications when new uplink data is available, and exposes that data to subscribed dApps through the E3 interface. For small data items, it can send values directly in E3 indication messages; for larger data objects such as I/Q samples or channel estimates, it sends metadata and shared-memory references so the dApp can read the data efficiently. It also handles E3AP procedures such as setup, subscription, indication, and control, enabling dApps to discover data, receive real-time updates, and optionally send control commands back to the RAN.

CPU SHM (Shared Memory)

Shared memory is used to expose real-time RAN data to dApps with low latency and minimal overhead. Selected uplink data is copied from GPU memory into pinned host memory and organized in ping-pong buffers. Instead of sending large payloads through control messages, the framework sends dApps references to the relevant shared-memory location, including the data type, buffer, and offset. This lets dApps read large structures such as I/Q samples and channel estimates efficiently while keeping the critical PHY processing path decoupled from dApp execution.

DU-High

DU-High can interact with dApps through the E3 interface for data consumption and control actions similar to how they interact with DU-Low as long as it supports E3.

dApp Sub-Components

A dApp itself consists of 3 main sub-components (Figure 4):

• E3 Manager: The core engine that handles E3AP protocol, multi-agent communication, shared memory, and application dispatch.

• dApp Client: An external control interface for managing the dApp lifecycle: listing agents, subscribing to telemetry, unsubscribing, and querying status.

• dApp Logic: The application-specific processing logic (e.g., PRB power calculation) including inference engine. Each app has its own config, Dockerfile, models, and build system. Different inference engines are supported, such as Triton Inference Server, Python and TensorRT, and multiple models can be used, hosted in a model repository.

Figure 4: dApp reference implementation

E3 Agent-Manager Relationships

Figure 5 shows how multiple Agents can connect to multiple Managers.

Figure 5: Multiple Agent-Manager connections

It shows how a single E3 Agent can connect to multiple dApps (i.e., E3 Managers), each of which may subscribe to different data from the Agent and control different aspects of its behavior, likely based on different dApp logic.

Similarly, a single dApp (i.e., E3 Manager) may connect to different E3 Agents, accessing different data and controlling different behaviors, potentially based on different dApp logic.

Available Data Streams

The E3 Agent exposes the following uplink data streams through the NVIDIA KPM Service Model. dApps can subscribe to any combination of these to receive real-time RAN data for inference, analytics, or custom processing.

Indications are delivered on two independent paths, one per PUSCH slot and one per SRS slot, and each carries data for every UE scheduled in that slot.

Category	Data	Description
IQ & channel	Fronthaul I/Q, DMRS estimates, PUSCH data	Raw uplink I/Q, PUSCH DMRS channel estimates, decoded PUSCH bytes (shared memory)
SRS	SRS I/Q, SRS estimates, SNR, ToA, SRS config	Raw SRS I/Q and channel estimates (shared memory), wideband and per-RB SNR, time of arrival, SRS resource configuration
Frame info	SFN, Slot, Timestamps	System Frame Number, slot index, agent-side and TAI-aligned nanosecond timestamps
Cell & antenna	Cell ID, RX antennas, BS antennas	Physical cell ID, PUSCH and SRS antenna counts
Channel quality	RSRP, RSSI, CQI, SINR, MCS index, QAM order	PHY-layer measurements and modulation parameters, per UE
PUSCH decoding	TB CRC fail, CB errors, CB count, TB size, HARQ process, RV index	Transport and code block error indicators, transport block sizing, HARQ state
Resource allocation	RB start, RB size, Symbols, Subcarriers, MIMO layers	Frequency and time resource assignment
Timing & frequency	Timing advance, CFO	Per-UE timing advance estimate and carrier frequency offset in Hz

This list reflects the currently supported telemetry streams. Additional data streams and service models may be added in future releases. See the Application Development Guide for the full per-field telemetry ID table and shared memory layout details. Future releases of E3 Agents may also expose other Service Models with different RAN Function IDs, providing additional telemetry IDs and/or control IDs.

References

• NVIDIA Sample Apps repository: sample dApps showing how to build, install, configure, test and run low-latency, inference-capable dApps that collect and consume data in real time from ACAR. GitHub repo

• NVIDIA dApp Framework: D. Villa, M. Belgiovine, N. Hedberg, M. Polese, C. Dick, and T. Melodia, “Programmable and GPU-Accelerated Edge Inference for Real-Time ISAC on NVIDIA Aerial Testbed,” arXiv:2512.06493 [cs.NI], 2026. arXiv PDF

• dApps Concept: S. D’Oro, M. Polese, L. Bonati, H. Cheng, and T. Melodia, “dApps: Distributed Applications for Real-time Inference and Control in O-RAN,” IEEE Communications Magazine, 2022. arXiv PDF

• O-RAN nGRG First Research Report: Northeastern University, NVIDIA, Mavenir, MITRE, and Qualcomm, “dApps for Real-Time RAN Control: Use Cases and Requirements,” O-RAN next Generation Research Group (nGRG), Research Report, Oct 2024, report ID: RR-2024-10. Report PDF

• O-RAN nGRG Second Research Report: Northeastern University, NVIDIA, and Mavenir, “dApps Architecture and Interfaces,” O-RAN next Generation Research Group (nGRG), Research Report, 2025, report ID: RR-2025-05, v2.0. Report PDF

• E3 Interface: A. Lacava, L. Bonati, N. Mohamadi, R. Gangula, F. Kaltenberger, P. Johari, S. D’Oro, F. Cuomo, M. Polese, and T. Melodia, “dApps: Enabling Real-Time AI-Based Open RAN Control,” Computer Networks, vol. 269, pp. 111342, 2025. ScienceDirect