Bringing dApps to OCUDU: An E3 Controller for Real-Time Open RAN Intelligence

This paper has been accepted for publication at the 20th ACM Workshop on Wireless Network Testbeds, Experimental evaluation & Characterization (WiNTECH ’26), co-located with ACM MobiCom 2026, Austin, TX, USA, October 30, 2026. © 2026 Copyright held by the owner/author(s). This work is licensed under a Creative Commons Attribution 4.0 International License (CC BY 4.0). The definitive version is: A. Feraudo, R. Shirkhani, S. Maxenti, A. Lacava, M. Polese, and T. Melodia, “Bringing dApps to OCUDU: An E3 Controller for Real-Time Open RAN Intelligence,” in Proc. 20th ACM Workshop on Wireless Network Testbeds, Experimental evaluation & Characterization (WiNTECH ’26), ACM, New York, NY, USA, pp. 1–6.

Bringing dApps to OCUDU: An E3 Controller for Real-Time Open RAN Intelligence Angelo Feraudo, Ravis Shirkhani, Stefano Maxenti, Andrea Lacava, Michele Polese, Tommaso Melodia Institute for Intelligent Networked Systems, Northeastern University, Boston, MA, U.S.A.

arXiv:2609.03162v1 [cs.NI] 2 Sep 2026

Abstract Real-time control loops in Open RAN are increasingly colocated with the gNB, where dApps, i.e., programmable applications with sub-millisecond access to PHY- and MAC-layer signals, enable latency-critical use cases such as spectrum sharing, channel-aware scheduling, and integrated sensing. What turns dApps from a per-vendor mechanism into a portable component of the emerging AI-RAN ecosystem is the E3 interface: this interface defines how a dApp subscribes to RAN telemetry, receives indications, and issues control actions back to the RAN. To date, E3 has been implemented on OpenAirInterface and on NVIDIA Aerial; OCUDU, i.e., the Linux Foundation’s open-source CU/DU project, has lacked a comparable E3 path. We close that gap with an open-source E3Controller for OCUDU, designed as a sidecar daemon so the E3 protocol stack, service-model logic, and dApp interactions live entirely outside RAN core processing, which is touched only through well-defined instrumentation hooks. We validate the controller with two reference service models, Spectrum and L1, that deliver O-RAN fronthaul I/Q samples to a spectrum-sensing dApp over a Foxconn RPQN 4800 radio unit. Our evaluation shows that the E3 path imposes no measurable throughput penalty on the OCUDU RAN, demonstrating that a real-time dApp/RAN interface is feasible on production-grade open RAN software.

CCS Concepts • Networks → In-network processing; Network experimentation; Network measurement.

Keywords O-RAN, dApp, E3, jbpf, real-time RAN control, OCUDU ACM Reference Format: Angelo Feraudo, Ravis Shirkhani, Stefano Maxenti, Andrea Lacava, Michele Polese, Tommaso Melodia . 2026. Bringing dApps

This work is licensed under a Creative Commons Attribution 4.0 International License. WiNTECH ’26, Austin, TX, USA © 2026 Copyright held by the owner/author(s). ACM ISBN 979-8-4007-2879-2/2026/10 https://doi.org/10.1145/3831662.3844165

to OCUDU: An E3 Controller for Real-Time Open RAN Intelligence. In 20th ACM Workshop on Wireless Network Testbeds, Experimental evaluation & Characterization (WiNTECH ’26), October 26–30, 2026, Austin, TX, USA. ACM, New York, NY, USA, 8 pages. https://doi.org/10.1145/3831662.3844165

1

Introduction

The Open RAN architecture, as defined by the O-RAN ALLIANCE, promotes programmable, multi-vendor cellular networks. Its programmability is anchored on two RAN Intelligent Controllers (RICs): the Near-Real-Time (RT) RIC hosts xApps, which apply control loops on the order of 101000 ms over the E2 interface, while the Non-RT RIC hosts rApps for longer-horizon policies. A growing set of use cases [1, 2, 4, 16], however, sits below this latency floor: spectrum sensing, AI-driven channel estimation, beam tracking, integrated sensing, and per-slot scheduling all need access to PHY- and MAC-layer signals at the slot or symbol granularity. The E2 interface cannot carry these signals, either because they are too data-intensive or because operators consider them too sensitive to expose outside the RAN node. To close this gap, dApps were introduced as an extension of the O-RAN architecture [4, 14]: lightweight applications co-located with the RAN node that read internal data directly and react in the hundreds-of-microseconds regime. What distinguishes a dApp from an ad-hoc RAN extension, however, is the E3 interface, a well-defined protocol for interacting with RAN components. This interface defines how a dApp subscribes to a class of telemetry, receives indications carrying the requested data, and issues control actions back to the RAN. By cleanly separating what dApps exchange from how a given RAN exposes it, E3 lets the same dApp run across stacks and the same RAN serve different dApps, turning dApps from per-vendor add-ons into an open layer of the emerging AI-RAN ecosystem. To date, E3 has been implemented on OpenAirInterface, where the reference dApp framework was first introduced [10], and on the NVIDIA Aerial GPU stack [21]. OCUDU [15] (old srsRAN), formerly srsRAN and increasingly common target for production-grade Open RAN trials, has, by contrast, lacked a comparable E3 path. Existing efforts that bring RAN-side telemetry to srsRAN/OCUDU, including the jbpfenabled srsRAN fork from Microsoft [6], deliver low-latency

© 2026 Copyright held by the owner/author(s). This work is licensed under a Creative Commons Attribution 4.0 International License. Published in the Proceedings of the 20th ACM Workshop on Wireless Network Testbeds, Experimental evaluation & Characterization (WiNTECH ’26), Austin, TX, USA, October 30, 2026. ACM, New York, NY, USA. https://doi.org/10.1145/3831662.3844165

WiNTECH ’26, October 26–30, 2026, Austin, TX, USA

Non-RT RIC

OCUDU gNB (RAN software)

Near-RT RIC

A1

O1

Feraudo et al.

E2

IPC

E3Controller (sidecar)

E3

dApp(s)

RAN node

Figure 1: Deployment overview of the E3Controller. instrumentation but do not expose it through a well-defined, dApp-facing interface. This paper closes that gap by presenting E3Controller, an open-source framework that brings the E3 interface to OCUDU through a sidecar architecture. Figure 1 provides an overview of the deployment: the E3Controller runs as a sidecar process on the same edge host as the OCUDU Next Generation Node Base (gNB), and E3 is the interface it exposes to one or more co-located dApps. The E3 protocol stack, service-model logic, dApp interactions, and dApps all execute outside the OCUDU process, requiring lightweight instrumentation hooks in the RAN software stacks. In our deployment, we added two hooks to the OCUDU gNB: one in the Fronthaul (FH) receive path and one at the upper Physical (PHY) level. These hooks serve as attachment points for jbpf [7] codelets, leveraging Microsoft’s open-source eBPF framework for instrumenting network functions, and compile to no-ops when the feature is disabled. To interact with dApps, the E3Controller uses the open-source libE3 agent [23] for E3 Application Protocol (E3AP) session management and communication. We demonstrate the framework using two reference E3 Service Models (E3SMs), Spectrum and L1. The Spectrum service model supports both information reporting and E3 control actions, whereas the L1 service model streams O-RAN fronthaul I/Q samples. In the current E3Controller implementation, both service models support only the reporting interface, while E3 control actions remain under development. The experimental evaluation focuses on the L1 service model, as it represents the most demanding data path currently supported by the E3Controller, delivering high-rate fronthaul I/Q samples through shared memory. The experiments are performed on the X5G testbed [22], using a commercial Foxconn RPQN4800 radio unit, and a Samsung S23 User Equipment (UE). The results show that the proposed E3 data path introduces no measurable throughput overhead to the OCUDU RAN. Contributions. This paper makes the following contributions: (1) The first end-to-end integration of the E3 interface with OCUDU, designed around a minimal-touch, sidecar architecture.

(2) An E3Controller that decouples the E3 interface from the underlying RAN software stack, enabling its adoption across different implementations. It features (i) dynamic codelet loading on dApp subscription via jbpf’s Lifecycle Management (LCM) Inter-Process Communication (IPC), (ii) a three-stage pipeline with each stage pinnable to a dedicated core to bound tail latency, and (iii) a streammultiplexed dispatcher with a zero-copy buffer hand-off that fans one codelet’s data out to many dApps and serves many data types to one dApp through per-RAN-function subscriptions. (3) An extension of the OCUDU RAN with two jbpf hooks that compile to no-ops when jbpf is disabled and require no changes to the OCUDU core. We pair them with two reference service models, Spectrum (per-FH-section, with sample decompression) and L1 (per-slot, all RX antennas), and validate the full path on a commercial O-RAN 7.2x Radio Unit (RU).

2

Related Work

dApps and the E3 interface. The dApp concept was introduced to extend Open RAN control beyond the latency limits of the Near-RT RIC, first as a vision for co-located RAN applications [4] and later as a complete architectural framework powered by a new O-RAN logical interface called E3 with a reference implementation on OpenAirInterface (OAI) [10]. dApps and E3 are implemented in NVIDIA Aerial [21] and in the Radisys stack [19]. A complementary line of work replaces the dApp execution substrate with WebAssembly to provide portable, sandboxed RAN functions [5]. Moreover, several systems address the sub-10 ms control gap by introducing dedicated real-time controllers rather than co-located applications. EdgeRIC deploys a real-time RIC external to the RAN and supports reinforcement-learningbased scheduling through a custom low-latency interface [9], while TinyRIC embeds a lightweight controller and its tApps directly within the base station using an in-memory messaging framework [11]. At a different layer of the ecosystem, OAIC provides an open-source platform for developing and evaluating AI-driven RAN-management algorithms [20]. These efforts highlight the need for sub-millisecond application to RAN interaction, while relying on architectures distinct from the emerging O-RAN E3 model [3, 18, 19]. Fronthaul interception and sensing use cases. RANBooster obtains the same I/Q-level data by interposing a kernel-bypass middlebox (DPDK/XDP) on the O-RAN fronthaul, which is external and transparent to the RAN [8]. We instead capture the same uplink I/Q in-process at the OFH receive and upper-PHY hooks, avoiding a separate packetprocessing path while still exporting the data over a standardized interface. Moreover, hooks at multiple processing stages enable dApps to access and process different classes

Bringing dApps to OCUDU: An E3 Controller for Real-Time Open RAN Intelligence OCUDU gNB Process

OCUDU (jbpf hook)

WiNTECH ’26, October 26–30, 2026, Austin, TX, USA

E3Controller Daemon hook fires

jbpf codelet

jbpf shared memory

poll

JbpfDispatcher (poll thread)

LCM load (dynamic)

Service Model (worker thread)

libe3 publisher (APER / JSON)

E3 Ind

dApp

Control Action

Figure 2: End-to-end data flow from the OCUDU gNB to a subscribed dApp through the E3Controller sidecar. of I/Q data depending on the application, facilitating the isolation of specific signals and allowing instrumentation to be placed at the most appropriate point in the RAN pipeline. eBPF-based RAN programmability. Janus [7] pioneered the use of eBPF-style codelets to instrument and control a running RAN by dynamically injecting verified bytecode into a 5G base station to enable low-latency analytics and control. Janus exposes programmability through a bespoke control plane tightly coupled with the underlying RAN implementation. In this work, we build on the jbpf userspace framework and the jbpf-enabled srsRAN fork [6], extending a newer version of OCUDU with jbpf support while deploying the E3Controller as a sidecar process. This architecture enables the E3 interface without embedding its protocol logic into the RAN implementation. Positioning of this work. Existing efforts have independently explored E3-enabled dApps, eBPF-based RAN programmability, real-time control frameworks, and fronthaullevel data extraction. However, to the best of our knowledge, no prior work combines these elements into an end-to-end E3 implementation for OCUDU. This paper fills that gap by extending OCUDU with the E3Controller, a component independent of the protocol stack that enables interoperability with the same dApps that work for NVIDIA Aerial and OAI. The design bridges jbpf-based instrumentation to standardized E3 procedures through a minimal-touch sidecar architecture, requiring only lightweight hook points within the RAN while leaving the core protocol stack unchanged. The resulting platform exposes fronthaul- and PHY-level data streams to E3-compliant dApps and is validated on a commercial O-RAN 7.2x deployment.

3

An E3 Controller for Real-Time Open RAN Intelligence

This section describes the design choices and the architecture behind our E3Controller.1 It provides an overview of how the E3 interface has been designed in the OCUDU context, the various service models supported by this version, how data is distributed among several dApps, and finally, how

1 https://github.com/wineslab/E3Controller

this introduction may impact the overall performance of the OCUDU RAN software.

3.1

Sidecar Architecture

To reduce the impact on the RAN software implementation and make it reusable across other RAN software stacks [7, 13], we decided to separate E3 interface management from the RAN implementation itself. We designed a controller that manages the encoding/decoding of E3-related information (E3AP and E3SM), dApp subscriptions and controls, and message dispatching as a separate process that runs alongside the RAN software stacks. The integration follows a sidecar architecture where the E3Controller runs as a separate process alongside the OCUDU gNB. It communicates with the RAN via jbpf’s shared-memory IPC for data, and via jbpf’s LCM IPC socket for codelet lifecycle management. Consequently, only the hook macros and the jbpf agent initialization need to live inside OCUDU, while the rest of the pipeline (E3 protocol stack, Abstract Syntax Notation One (ASN.1)/JavaScript Object Notation (JSON) codecs, service models, dApps) sits behind a clean IPC boundary and can evolve independently. Figure 2 summarizes the end-to-end flow. When a dApp subscribes to a service model, the E3Controller dynamically allocates the corresponding jbpf codelet into the running gNB through the LCM IPC interface. When the hook is called, the codelet extracts the E3-relevant information and sends it to the jbpf output channel identified by a unique stream_id. The data is exported through POSIX shared memory to the E3Controller, which is the IPC primary. Inside the controller, a service model encodes the data as an Indication message, in ASN.1 APER, or JSON, selectable per subscription, and the E3 agent delivers it to subscribers over ZMQ. The matching unload request is issued when the last subscriber leaves.

3.2

Dispatcher and Three-Stage Pipeline

The E3Controller is organized as a three-stage pipeline comprising a poll, worker, and publisher stage, each executed on a dedicated thread to minimize latency along the RANto-dApp data path. Poll. A single JbpfDispatcher thread routes each output jbpf buffer to a data-plane pipeline associated with one or more

WiNTECH ’26, October 26–30, 2026, Austin, TX, USA

Service Models (SMs), using the buffer’s stream_id as the lookup key. To support high-throughput operation, the dispatcher is deliberately designed as a lightweight component that performs only stream demultiplexing, leaving all payload processing to the pipelines. Worker. Each codelet stream is served by a dedicated pipeline, which acts as the shared data plane for one or more service models. The pipeline drains its single-producer/singleconsumer (SPSC) queue, applies any service-model-specific processing, and forwards the resulting data by reference to the subscribed service models. Each service model then constructs the corresponding Indication and passes it to libE3 for transmission (Figure 2). The amount of work performed at this stage is service-model-specific. For instance, the Spectrum SM decompresses and remaps each fronthaul section, whereas in the L1 SM the worker validates the shared-memory data descriptors and fills in the Indication. In the latter case, the pipeline is a pure metadata path, and the E3Controller never touches I/Q samples. To maximize throughput, the dispatcher normally releases each jbpf buffer immediately after dispatching it. However, for large payloads from codelets, it may transfer ownership of the buffer to the worker thread, which releases it only after all subscribed service models have consumed the data. This allows to eliminate an extra copy of payload while preserving synchronous delivery to all consumers. Publisher. Finally, the libE3 publisher thread performs the outer E3AP serialization (ASN.1 APER or JSON) and transmits the resulting message over ZMQ.

3.3

Service Models: Spectrum and L1

Each SM leverages the libE3::ServiceModel interface provided by libE3 to leverage the library’s SM lifecycle management and to expose SM-specific metadata, i.e., the RAN function definition and its telemetry and control identifiers, to the dApps over the E3AP. Upon the first dApp subscription, the service model issues an LCM load request to attach its codelet to the appropriate gNB hook. Conversely, when the last dApp unsubscribes, the service model unloads the codelet, ensuring that instrumentation remains active only when needed. This version of the E3Controller supports two reference service models, Spectrum [10] and L1 [21], which instrument the same uplink I/Q stream at different stages of the gNB pipeline while adopting different datadelivery strategies. Spectrum hooks the pipeline before the upper-PHY’s decompression and exports the captured samples through ASN.1-encoded E3 messages. In contrast, L1 operates after decompression, where the payloads are substantially larger, and therefore delivers the sample buffers via shared memory to avoid the overhead of encoding them in ASN.1. Together, they represent two complementary points in the hook-placement and service-model design space.

Feraudo et al.

Spectrum SM (per-section, pre-decompression). The Spectrum SM loads a codelet that attaches to the FH UPlane Uplink (UL) hook. For each received fronthaul section, the codelet extracts the eCPRI/U-Plane metadata (frame, subframe, slot, symbol, and Physical Resource Block (PRB) range) and writes the compressed I/Q payload to jbpf shared memory. On the E3Controller, the pipeline worker then decompresses each section into int16 I/Q samples, maps subcarriers to FFT bins following the 3GPP convention (guard-band zero-padded), and encodes the Indication messages. L1 SM (per-slot, post-decompression). The L1 SM loads a codelet that attaches to the upper-PHY hook after the gNB has assembled the per-slot resource grid for demodulation. The hook triggers once per slot, on the last symbol, and provides the codelet with a read-only pointer to the complete resource grid. To avoid embedding the large I/Q payload in every E3 Indication, the L1 SM stores each captured slot in a shared-memory region, /e3_ran_buffers [21] allocated by the E3Controller, and sends an Indication containing only a reference to the corresponding slot. This allows multiple dApps to access the same I/Q data without duplicating or re-encoding the payload. To transfer the samples into shared memory, the codelet invokes a jbpf helper function, registered by the gNB during agent initialization. The helper converts the resource grid from bf16 to the fp16 row format required by the dApp and writes it to /e3_ran_buffers in a single copy, leaving only a ∼64 B descriptor on the jbpf output channel. This delegation reflects the eBPF execution model: the conversion is not expressible in bytecode, while the copy is substantially more efficient when performed by a native routine. The codelet supplies only the source window and a selector, while the helper derives the target row from the buffer geometry maintained by the E3Controller. Thus, the payload bypasses the jbpf ring, which carries only the descriptor containing the slot identity, row indices, and timestamps used in Section 4.

3.4

Subscriptions and Data Distribution

Figure 3 summarizes the life cycle of a single dApp subscription, consisting of three phases. First, the E3Controller loads the codelet associated with the requested RAN function through the jbpf LCM IPC channel and acknowledges the subscription. During operation, each codelet writes data to jbpf shared memory, which the E3Controller dispatcher drains and delivers as an E3 Indication to the dApp via libE3. Finally, when the last subscriber unsubscribes, the E3Controller unloads the corresponding codelet. Within this life cycle, the E3Controller scales independently along two orthogonal dimensions: the number of dApps subscribed to a given RAN function and the number of distinct RAN functions served concurrently.

Bringing dApps to OCUDU: An E3 Controller for Real-Time Open RAN Intelligence OCUDU gNB (jbpf agent + codelet)

E3Controller (sidecar)

dApp

1. Subscription E3AP Subscribe(ranFunctionId) LCM load(codelet)

WiNTECH ’26, October 26–30, 2026, Austin, TX, USA

ZMQ TCP/IPC ASN.1/JSON

dApp

LCM ack (codelet attached to hook)

E3 Controller

OCUDU jbpf Agent

E3 Agent (libe3)

CU Midhaul

ecpri_iq_collects SMs

uplink_slot_collect

DU

Dispatcher

SubscribeResponse

Foxconn RPQN 48

jbpf shared memory

2. Data path (loop, per fire)

Data Shared memory (e.g., libE3 IPC, /e3_ran_buffers)

hook fires; codelet → jbpf SHM dispatcher drain (jbpf SHM) SM worker: process / encode libe3 publisher: emit E3 Indication 3. Unsubscription E3AP Unsubscribe

LCM unload (last subscriber)

UnsubscribeResponse

Figure 3: Life-cycle of a Single dApp Subscription. Many dApps, one data type. The capture chain executes once per codelet invocation, while the service-model-specific processing performed by the pipeline worker is likewise applied only once to each captured sample, regardless of the number of subscribed dApps. The only cost that scales with the number of subscribers is outbound fan-out, whose behavior depends on the service model’s indication strategy, as described in the previous section. Thus, in both strategies, in-RAN instrumentation and per-sample processing remain independent of subscriber count. They differ only in whether the publisher replicates the payload itself or distributes a reference to the shared data. One dApp, many data types. Each data type is exposed as an independent E3 RAN function, implemented through a dedicated codelet, stream_id, pipeline, service model tuple. Consequently, a dApp requiring multiple data types (e.g., uplink I/Q samples and decoded PDUs) establishes separate subscriptions, one for each RAN function. The libE3 runtime demultiplexes indications based on the corresponding ranFunctionId, while each service model publishes independently and asynchronously. The dApp correlates across data types using the common identifier carried by all indications. Furthermore, each pipeline is instantiated only when the first subscriber arrives and deleted when the last subscriber unsubscribes, ensuring that inactive RAN functions incur no steady-state overhead. This design naturally decouples scalability with respect to the number of exported RAN functions from scalability with respect to the number of subscribers. At the jbpf layer, codelets attached to the same hook execute serially within the invoking RAN thread. Therefore, distinct data types are exported via separate hooks at appropriate stages of the gNB processing pipeline. Because different RAN threads invoke these hooks, their associated codelets execute independently and do not interfere with one another. Only multiple codelets

Fronthaul 7.2

Figure 4: Testbed used for the evaluation. attached to the same hook are serialized, making hook placement the primary determinant of execution isolation.

3.5

Minimal Footprint in OCUDU

Enabling the E3Controller on OCUDU requires three modifications to the gNB codebase, all of which are conditionally compiled. First, we introduce two jbpf instrumentation hooks into the data path. The first, located in the OFH receive path, is ported from Microsoft’s jbpf-enabled srsRAN fork [6]. The second, introduced in this work, is placed in the upper-PHY symbol handler, where it exposes a read-only view of the resource grid and triggers a hook invocation on the last symbol of each slot. When jbpf support is disabled, both hooks are compiled out and introduce no runtime overhead. Second, the jbpf agent is initialized as an IPC secondary process during gNB startup, while the LCM IPC server is enabled to allow the E3Controller to dynamically load and unload codelets at runtime. The same initialization procedure registers the two helper functions used by the L1 SM, namely region attachment and slot publication. These constitute the only RAN-side components that access I/Q samples, and both reuse the conversion routine of the E3Controller without modification, ensuring that the two writers produce byteidentical rows. Finally, the gNB configuration is extended with a dedicated jbpf: YAML section, parsed at startup, that specifies the IPC namespace, the LCM socket path, and the hugepage allocation size. We have implemented these modifications in a public OCUDU fork based on OCUDU 26.042 .

4

E3Controller Validation and Evaluation

In this section, we compare the performance of the OCUDU gNB with and without the E3Controller. Moreover, given the low-latency requirements of the dApp-based scenarios, we analyze the latency introduced by the E3Controller and its components when delivering data to a dApp under high traffic loads. Figure 4 depicts the O-RAN 7.2x experimental setup, built on the X5G testbed [22] and the AutoRAN framework [12], used to evaluate the E3Controller. An OCUDU gNB, deployed as a pod on OpenShift, is connected to a Foxconn 2 https://github.com/wineslab/ocudu-e3

WiNTECH ’26, October 26–30, 2026, Austin, TX, USA Standard

Asn1

JSON

1 0.75 0.5 0.25 0

Official

CDF

CDF

Official

Feraudo et al.

420

440

460 480 Throughput [Mbps]

500

(a) Downlink (DL) throughput

Standard

Asn1

JSON

1 0.75 0.5 0.25 0 60

65

70 Throughput [Mbps]

75

80

(b) UL throughput

Figure 5: Empirical CDF of the UDP throughput for the OCUDU baseline with and without the E3Controller. RPQN 4800 RU through a switch. The cell operates in band n78 with 30 kHz subcarrier spacing and 100 MHz channel bandwidth, corresponding to 273 PRBs. The Time Division Duplexing (TDD) configuration follows a 7DS2U pattern, while the fronthaul transports BFP-9 compressed I/Q samples on both the UL and DL, using 4 DL and 4 UL antenna ports. We use one Samsung S23 phone as the UE, and keep the phone’s location constant throughout all experiments. The E3Controller executes within the same pod as the OCUDU process, with its polling, worker, and publisher threads pinned to dedicated CPU cores to minimize scheduling interference. The evaluation focuses on the L1 SM, as it exercises the E3Controller at its highest sustained data rate. We compare four configurations: the OCUDU 26.04 baseline (Official); our fork, synchronized with the corresponding official OCUDU commit and including the two jbpf hooks described in Section 3.3, but with the hooks excluded from the build (Standard); and our full implementation, including both the jbpf hooks and the E3Controller, with the latter streaming I/Q samples to a spectrum-sensing dApp using either ASN.1 or JSON for indication encoding. For each, we measure (a) end-to-end throughput with and without the E3Controller and dApp attached alongside the overhead compute and energy cost of the framework, and (b) per-stage latency along the RAN-to-dApp path.

4.1

Throughput and Energy Cost

We drive User Datagram Protocol (UDP) traffic with iperf3 for 60 s at a target rate of 500 Mbps in the DL and 100 Mbps in the UL, repeating each run five times. Figure 5 reports the empirical Cumulative Distribution Function (CDF) of the per-second throughput pooled across the five runs. In the DL direction, all four configurations achieve approximately 490 Mbps, with nearly identical distributions. Similarly, in the UL direction, all configurations sustain approximately 72 Mbps. The throughput distributions of both the ASN.1 and JSON configurations are indistinguishable from the Official and Standard baselines, indicating that enabling the controller hooks, exporting fronthaul I/Q samples to dApps through the E3 interface, and encoding choice introduces no measurable impact on OCUDU RAN throughput.

The reference dApp served by our E3Controller performs spectrum sensing, introducing a concurrent computational workload whose power consumption is relevant to the evaluation. While the E3Controller and dApp leave throughput unaffected, they consume CPU and energy by processing fronthaul I/Q. We measure the container’s power consumption using Kepler, following an energy-profiling methodology for Open RAN deployments [17]. We report dynamic power (the traffic-attributable term isolated from the static platform draw) and CPU occupancy in cores, averaged over the duration of Over-The-Air (OTA) experiments. Table 1 summarizes the results. The Dynamic power column is the average Kepler dynamic component. The CPU column is the container’s aggregate CPU occupancy in cores, where each core represents a fully utilized CPU. The last row is the pod floor (gNB off); the remaining rows report the four configurations under the 500/100 Mbps DL/UL iperf3 load. Compared with the OCUDU baselines, the E3Controller adds roughly two CPU cores through its polling, worker, and publisher threads, with the dApp contributing a smaller, traffic-gated share on top. These threads are statically pinned and poll continuously to guarantee deterministic real-time performance, avoiding context switches and scheduling latency along the critical data path. Because these threads poll rather than compute, the dominant cost of the framework is therefore CPU occupancy, not energy. The stack draws only 14 W in the DL and 11 W in the UL, against 11 and 10 W for the baselines, an overhead of a few watts, and its resident memory grows from 3.5 to 4.4 GB, about 0.4 GB each for the E3Controller and the dApp. The cost is also directionindependent. The stack occupies 4 cores in both the DL and UL, and the small power difference between them follows the RAN’s own load rather than the sensing pipeline. This matches the expected behavior of an Integrated Sensing and Communication (ISAC) workload, whose footprint tracks the sensed bandwidth rather than the served traffic. The two indication encodings are near-equivalent. They deliver the same throughput (Figure 5) and draw comparable CPU and dynamic power, differing by about 1 W in either direction.

Bringing dApps to OCUDU: An E3 Controller for Real-Time Open RAN Intelligence

Table 1: Average dynamic power and CPU occupancy across operating states. Values are reported as mean ± standard deviation.

WiNTECH ’26, October 26–30, 2026, Austin, TX, USA Grid + SHM write

E3SM encode

Emit

Publish (libE3)

80

100

JSON UL JSON DL

Configuration

Dynamic power [W]

CPU [cores]

DL 500 Mbps

Official Standard E3+dApp (ASN.1) E3+dApp (JSON)

12.4 ± 1.1 11.0 ± 1.0 13.9 ± 1.2 14.3 ± 0.7

2.12 ± 0.18 2.05 ± 0.30 4.09 ± 0.15 4.28 ± 0.40

UL 100 Mbps

Official Standard E3+dApp (ASN.1) E3+dApp (JSON)

10.5 ± 0.1 9.7 ± 0.8 11.3 ± 1.4 10.5 ± 0.3

1.97 ± 0.09 1.85 ± 0.19 3.72 ± 0.57 3.72 ± 0.22

Pod floor (gNB off)

—

0.96 ± 0.01

0.05 ± 0.01

Latency [µs]

Asn1

UL

Figure 6: RAN to dApp latency in the L1 SM, for ASN.1 and JSON indication encodings in DL and UL.

4.2

Asn1 DL

0

E3Controller Latency

A real-time E3 data path must deliver RAN data to the dApp within the sub-millisecond control-loop budget that motivates co-locating dApps with the RAN. To evaluate this requirement, we instrument the complete L1 SM pipeline, timestamping every indication from the instant the jbpf hook fires inside OCUDU until its transmission through libE3. We split the end-to-end latency into two components: (i) the RAN-to-controller transfer, including the L1 SM processing, and (ii) the publisher-side transmission through libE3. As shown in Figure 6, across all four configurations (ASN.1 DL/UL and JSON DL/UL), the median latency remains between approximately 115 and 120 µs, with an interquartile range of only about 10 µs. These values remain well below the sub-millisecond latency budget required by real-time dApps under heavy traffic. Latency is largely insensitive to traffic direction and encoding, with nearly identical results across configurations. To identify the main contributors, Figure 7 decomposes the data path in Figure 2 into the median duration of four stages. The grid transfer (RAN to codelet) and shared-memory write, which convert the resource grid and write it to buffers, are the only stages handling the I/Q payload and dominate at approximately 69 µs, primarily due to memory bandwidth and data conversion rather than codelet logic. The E3SM encode and the SM emit each add only a few microseconds, while the publisher, which performs E3AP encoding and transmission through libE3, adds about 24 µs. The intermediate codelet message poller (JbpfDispatcher) stays sub-microsecond and is omitted. The four stages account for approximately 106 µs.

20

40

60 Time [µs]

Figure 7: E3Controller L1 SM pipeline latency for ASN.1/JSON encodings in DL/UL.

JSON

140 120 100 DL

Asn1 UL

Encoding latency [µs]

State

Asn1

JSON

6 4 2 DL

UL

Figure 8: E3SM encoding latency in the L1 SM for ASN.1 and JSON indication encodings in DL and UL. The residual latency relative to Figure 6 is attributable to queueing in libE3 prior to indication dequeueing. Figure 8 isolates the E3SM encoding stage, the only component that differs between ASN.1 and JSON. JSON encodes in about 3.6 µs against 1.2 µs for ASN.1, roughly three times slower, yet remains negligible relative to the overall pipeline. Thus, encoding has no measurable impact on throughput (Figure 5) or energy (Table 1), which are dominated by resourcegrid transfer.

5

Conclusion and Future Work

This paper presented the first integration of the E3 interface with OCUDU, enabling E3AP-compliant dApps to access real-time RAN data through a well-defined interface. The proposed architecture combines lightweight in-RAN instrumentation with an external E3Controller, preserving the modularity of the RAN implementation while exposing PHYand fronthaul-level information to external applications. Experimental evaluation demonstrated that the platform delivers high-rate I/Q streams to latency-sensitive dApps without measurable impact on RAN throughput, while maintaining end-to-end latencies well within the sub-millisecond budget required by real-time control applications. Looking ahead, we envision the E3Controller as a general execution platform for programmable RAN services rather than solely a data-export mechanism. Enabling dApps to dynamically inject logic into selected RAN functions would allow runtime extension of scheduling, PHY processing, and other protocol-stack components without modifying or redeploying the underlying RAN software. Such a capability would transform dApps into active extensions of the RAN processing pipeline, enabling ultra-low-latency optimization, sensing, and AI-driven applications.

WiNTECH ’26, October 26–30, 2026, Austin, TX, USA

Acknowledgments This work was supported by OUSW(R&E) through Army Research Laboratory Cooperative Agreement Number W911NF24-2-0065. The views and conclusions contained in this document are those of the authors and should not be interpreted as representing the official policies, either expressed or implied, of the Army Research Laboratory or the U.S. Government. The U.S. Government is authorized to reproduce and distribute reprints for Government purposes notwithstanding any copyright notation herein.

References [1] 3GPP. 2025. Study on Integrated Sensing And Communication (ISAC) for NR. Technical Report TR 38.765. 3rd Generation Partnership Project (3GPP). https://www.3gpp.org/dynareport/38765.htm Release 20. [2] AI-RAN Alliance. 2024. AI-RAN Alliance Vision and Mission White Paper. Technical Report. AI-RAN Alliance. https://ai-ran.org/documents/ AI-RAN-Alliance-Whitepaper.pdf Accessed: 2026-06-15. [3] Salvatore D’Oro. 2026. ISAC in Open RAN with dApps. Presented at the O-RAN ALLIANCE IEFG ISAC Workshop, co-located with the O-RAN F2F Meeting, Seattle, WA, USA. Video recording available at https://mediastorage.o-ran.org/events/isac-workshopseattle-2026-06/14-isac-workshop-salvatore-d-oro.mp4. Slides available at https://mediastorage.o-ran.org/events/isac-workshop-seattle2026-06/14-neu-dapps-o-ran-f2f-seattle.pdf. [4] Salvatore D’Oro, Michele Polese, Leonardo Bonati, Hai Cheng, and Tommaso Melodia. 2022. dApps: Distributed Applications for RealTime Inference and Control in O-RAN. IEEE Communications Magazine 60, 11 (2022), 52–58. doi:10.1109/MCOM.002.2200079 [5] João Paulo Esper, Yure Freitas, Pedro Souza, Bruno Silvestre, Joao F Santos, Alexandre Huff, Cristiano Both, and Kleber Cardoso. 2026. Enabling Real-Time Programmability for RAN Functions: A Wasm-Based Approach for Robust and High-Performance dApps. arXiv:2603.17880 [6] Xenofon Foukas. 2025. srsRAN Project with jbpf Integration. https: //github.com/xfoukas/srsRAN_Project_jbpf. Fork of srsRAN Project integrated with Microsoft’s jbpf userspace eBPF framework for dynamic RAN telemetry and real-time control, part of Project Janus. Accessed: 2026-06-15. [7] Xenofon Foukas, Bozidar Radunovic, Matthew Balkwill, and Zhihua Lai. 2023. Taking 5G RAN Analytics and Control to a New Level. In Proceedings of the 29th Annual International Conference on Mobile Computing and Networking (Madrid, Spain) (ACM MobiCom ’23). Association for Computing Machinery, New York, NY, USA, Article 1, 16 pages. doi:10.1145/3570361.3592493 [8] Xenofon Foukas, Tenzin Samten Ukyab, Bozidar Radunovic, Sylvia Ratnasamy, and Scott Shenker. 2025. RANBooster: Democratizing advanced cellular connectivity through fronthaul middleboxes. In Proceedings of the ACM SIGCOMM 2025 Conference (São Francisco Convent, Coimbra, Portugal) (SIGCOMM ’25). Association for Computing Machinery, New York, NY, USA, 742–757. doi:10.1145/3718958.3754349 [9] Woo-Hyun Ko, Ushasi Ghosh, Ujwal Dinesha, Raini Wu, Srinivas Shakkottai, and Dinesh Bharadia. 2024. EdgeRIC: Empowering Realtime Intelligent Optimization and Control in NextG Cellular Networks. In 21st USENIX Symposium on Networked Systems Design and Implementation (NSDI 24). USENIX Association, Santa Clara, CA, 1315–1330. https://www.usenix.org/conference/nsdi24/presentation/ko [10] Andrea Lacava, Leonardo Bonati, Niloofar Mohamadi, Rajeev Gangula, Florian Kaltenberger, Pedram Johari, Salvatore D’Oro, Francesca Cuomo, Michele Polese, and Tommaso Melodia. 2025. dApps: Enabling real-time AI-based Open RAN control. Computer Networks 269 (2025),

Feraudo et al. 111342. doi:10.1016/j.comnet.2025.111342 [11] Chang Liu, Gopalasingham Aravinthan, Ahan Kak, and Nakjung Choi. 2023. TinyRIC: Supercharging O-RAN Base Stations with Real-time Control. In Proceedings of the 29th Annual International Conference on Mobile Computing and Networking (Madrid, Spain) (ACM MobiCom ’23). Association for Computing Machinery, New York, NY, USA, Article 136, 3 pages. doi:10.1145/3570361.3615743 [12] Stefano Maxenti, Ravis Shirkhani, Maxime Elkael, Leonardo Bonati, Salvatore D’Oro, Tommaso Melodia, and Michele Polese. 2026. AutoRAN: Automated and Zero-Touch Open RAN Systems. IEEE Transactions on Mobile Computing 25, 7 (2026), 10112–10129. doi:10.1109/TMC.2026. 3656056 [13] Navid Nikaein, Mahesh K. Marina, Saravana Manickam, Alex Dawson, Raymond Knopp, and Christian Bonnet. 2014. OpenAirInterface: A Flexible Platform for 5G Research. SIGCOMM Comput. Commun. Rev. 44, 5 (Oct. 2014), 33–38. doi:10.1145/2677046.2677053 [14] O-RAN Alliance next Generation Research Group (nGRG). 2024. dApps for Real-Time RAN Control: Use Cases and Requirements. Technical Report nGRG-RR-2024-10. O-RAN Alliance. https://www.o-ran.org/research-reports/dapps-for-real-time-rancontrol-use-cases-and-requirements [15] OCUDU Ecosystem Foundation. 2026. OCUDU Ecosystem Foundation. https://ocudu.org/. Accessed: 2026-06-15. [16] Michele Polese, Leonardo Bonati, Salvatore D’Oro, Stefano Basagni, and Tommaso Melodia. 2023. Understanding O-RAN: Architecture, Interfaces, Algorithms, Security, and Research Challenges. IEEE Communications Surveys & Tutorials 25, 2 (2023), 1376–1411. doi:10.1109/ COMST.2023.3239220 [17] Ravis Shirkhani, Stefano Maxenti, Leonardo Bonati, Niloofar Mohamadi, Maxime Elkael, Umair Hashmi, Jeebak Mitra, Michele Polese, Tommaso Melodia, and Salvatore D’Oro. 2026. TENORAN: Automating Fine-grained Energy Efficiency Profiling in Open RAN Systems. arXiv:2602.13085 [cs.NI] https://arxiv.org/abs/2602.13085 [18] Prakash Siva. 2026. RAN Solution with E3 Support for ISAC Sensing Applications. Presented at the O-RAN ALLIANCE IEFG ISAC Workshop, co-located with the O-RAN F2F Meeting, Seattle, WA, USA. Video recording available at https://mediastorage.o-ran.org/events/isacworkshop-seattle-2026-06/12-isac-workshop-prakash-siva.mp4. [19] Nishant Tiwari. 2026. ISAC over Open RAN: Enabling Drone and LowAltitude Economy Use Cases with dApps, rApps, and xApps. Presented at the O-RAN ALLIANCE IEFG ISAC Workshop, co-located with the O-RAN F2F Meeting, Seattle, WA, USA. Video recording available at https://mediastorage.o-ran.org/events/isac-workshop-seattle-202606/13-isac-workshop-nishant-tiwari.mp4. [20] Pratheek S. Upadhyaya, Nishith Tripathi, Joseph Gaeddert, and Jeffrey H. Reed. 2023. Open AI Cellular (OAIC): An Open Source 5G O-RAN Testbed for Design and Testing of AI-Based RAN Management Algorithms. IEEE Network 37, 5 (Sept. 2023), 7–15. doi:10.1109/MNET. 2023.3320933 [21] Davide Villa, Mauro Belgiovine, Nicholas Hedberg, Michele Polese, Chris Dick, and Tommaso Melodia. 2026. Programmable and GPUAccelerated Edge Inference for Real-Time ISAC on NVIDIA Aerial Testbed. arXiv:2512.06493 [cs.NI] [22] Davide Villa, Imran Khan, Florian Kaltenberger, Nicholas Hedberg, Rúben Soares da Silva, Stefano Maxenti, Leonardo Bonati, Anupa Kelkar, Chris Dick, Eduardo Baena, Josep M. Jornet, Tommaso Melodia, Michele Polese, and Dimitrios Koutsonikolas. 2025. X5G: An Open, Programmable, Multi-Vendor, End-to-End, Private 5G O-RAN Testbed With NVIDIA ARC and OpenAirInterface. IEEE Transactions on Mobile Computing 24, 11 (2025), 11305–11322. doi:10.1109/TMC.2025.3580764 [23] WiNES Lab, Northeastern University. 2025. libe3: Reference C++ E3 Agent for dApps. https://github.com/wineslab/libe3.

Related documents

• Real-Time dApps for AI-RAN: Measured Interface Requirements for Inline PHY and Slot-Level Control#667944
• Towards an AI Software Factory for Data Systems#1131165
• Towards an AI Software Factory for Data Systems#1122377
• The OCUDU dApp Platform: An Open Runtime and E3 Interface for Real-Time AI-RAN#984736
• Real-Time dApps for AI-RAN: Measured Interface Requirements for Inline PHY and Slot-Level Control#984700