Source-linked AI summary
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
TL;DR
Open RAN dApps need sub-millisecond access to PHY- and MAC-layer signals, but OCUDU lacked a comparable E3 path. This paper introduces a sidecar E3Controller for OCUDU and validates it with Spectrum and L1 service models. The reported E3 data path delivers I/Q streams without measurable throughput impact on the RAN.
Problem
OCUDU lacked a dApp-facing E3 path for sub-millisecond access to PHY- and MAC-layer signals that E2 cannot carry.
Source: §1 · p. 1Method
An open-source sidecar E3Controller for OCUDU uses lightweight hooks and Spectrum and L1 reference service models to connect RAN data to dApps.
Source: §1 · p. 2Results
The E3 data path delivered high-rate I/Q streams without measurable impact on OCUDU RAN throughput.
Source: §1 · p. 2, §4.1 · p. 6Takeaways & Limitations
The evaluation demonstrates a real-time dApp/RAN interface on production-grade open RAN software without measurable throughput penalty.
Source: §5 · p. 7The current Spectrum and L1 service models support reporting only; E3 control actions remain under development.
Source: §1 · p. 2
Abstract
from arXiv · showhide
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.
1 Introduction
The introduction motivates sub-millisecond dApps as a complement to RIC control loops and identifies OCUDU’s lack of a dApp-facing E3 path. It presents a sidecar E3Controller for OCUDU, validated with reference service models and reported to add no measurable throughput overhead.
1 Introduction
- Sub-slot use cases need PHY- and MAC-layer signals that E2 cannot carry because they are data-intensive or too sensitive to expose outside the RAN node.Examples include spectrum sensing, beam tracking, integrated sensing, and per-slot scheduling.Source: §1 · p. 1
- E3 standardizes dApp subscriptions, indications, and control actions, separating exchanged information from how each RAN exposes it.This separation supports dApp portability across stacks and multiple dApps on one RAN.Source: §1 · p. 1
- OCUDU lacked a comparable E3 path, while existing telemetry efforts provided low-latency instrumentation without a well-defined dApp-facing interface.E3 had been implemented on OpenAirInterface and NVIDIA Aerial.Source: §1 · pp. 1–2
- The E3Controller brings E3 to OCUDU through an external sidecar and delivers high-rate I/Q streams without measurable RAN throughput impact.The integration uses lightweight instrumentation and is validated with a commercial O-RAN 7.2x deployment.Source: §1 · p. 2
- The controller decouples E3 from the RAN stack, using dynamic codelet loading, a core-pinnable three-stage pipeline, and stream-multiplexed zero-copy dispatch.The dispatcher supports one codelet’s data reaching many dApps and multiple data types reaching one dApp through per-RAN-function subscriptions.Source: §1 · p. 2
- Two jbpf hooks attach Spectrum and L1 service models to OCUDU; the hooks compile to no-ops when jbpf is disabled and require no OCUDU core changes.Spectrum operates per fronthaul section with sample decompression, while L1 operates per slot across all receive antennas.Source: §1 · p. 2
2 Related Work
Prior work explores E3-enabled dApps, real-time controllers, fronthaul extraction, and eBPF-based RAN programmability, but the paper identifies no prior end-to-end E3 implementation for OCUDU. Its contribution combines these elements through a sidecar architecture that leaves the core protocol stack unchanged.
2 Related Work
- Prior work also includes E3 implementations on OAI, NVIDIA Aerial, and Radisys, plus WebAssembly-based portable, sandboxed RAN functions.These efforts establish related approaches but do not, in the authors’ positioning, combine them into end-to-end E3 for OCUDU.Source: §2 · pp. 2–3
- Related real-time control systems use architectures distinct from the emerging O-RAN E3 model, including external EdgeRIC and base-station-embedded TinyRIC.OAIC provides an open-source platform for developing and evaluating AI-driven RAN-management algorithms.Source: §2 · p. 2
- RANBooster captures I/Q through an external fronthaul middlebox, whereas this work captures uplink I/Q in-process at OFH receive and upper-PHY hooks.Hooks at multiple processing stages allow access to different I/Q classes and placement at an appropriate pipeline point.Source: §2 · pp. 2–3
- Other work uses eBPF-style codelets for RAN instrumentation, while this system deploys E3 protocol logic outside the RAN implementation.Janus uses a bespoke control plane tightly coupled to the RAN; this work builds on jbpf and a jbpf-enabled srsRAN fork.Source: §2 · p. 3
- The paper positions its work as the first end-to-end E3 implementation for OCUDU, combining jbpf instrumentation with standardized E3 procedures in a minimal-touch sidecar.It reports interoperability with the same dApps used for NVIDIA Aerial and OAI.Source: §2 · p. 3
3 An E3 Controller for Real-Time Open RAN Intelligence
The section describes an E3Controller that separates E3 management from OCUDU and supports service models, data distribution, and minimal RAN-side changes.
3.1 Sidecar Architecture
- The sidecar runs E3 management outside the OCUDU gNB, using shared-memory IPC for data and LCM IPC to load and unload codelets.Only hook macros and jbpf agent initialization remain inside OCUDU; the rest of the protocol and application pipeline can evolve independently.Source: §3.1 · p. 3
3.2 Dispatcher and Three-Stage Pipeline
- A lightweight dispatcher routes buffers by stream_id to pipelines, whose workers process data before publisher threads serialize and transmit indications.The dispatcher can transfer ownership of large buffers to avoid an extra payload copy.Source: §3.2 · pp. 3–4
3.3 Service Models: Spectrum and L1
- Spectrum exports pre-decompression, per-section samples for controller-side decompression and remapping, while L1 exports post-decompression, per-slot resource grids by shared-memory reference.The L1 helper converts bf16 to fp16 and writes the grid in one copy; only a roughly 64 B descriptor travels through the jbpf output channel.Source: §3.3 · p. 4
3.4 Subscriptions and Data Distribution
- A subscription loads its codelet and the last unsubscribe unloads it; per-sample processing is independent of subscriber count, while distinct RAN functions use separate pipelines.Codelets on the same hook execute serially, so hook placement determines their execution isolation.Source: §3.4 · pp. 4–5
3.5 Minimal Footprint in OCUDU
- Two conditionally compiled jbpf hooks, agent initialization, helper registration, and a configuration section add the OCUDU integration; disabled hooks compile out without runtime overhead.The implementation is in a public OCUDU fork based on OCUDU 26.042.Source: §3.5 · p. 5
4 E3Controller Validation and Evaluation
The evaluation compares OCUDU baselines with the E3Controller under high traffic and measures throughput, resource cost, and RAN-to-dApp latency.
4.1 Throughput and Energy Cost
- All four configurations achieve approximately 490 Mbps DL and 72 Mbps UL, with throughput distributions indistinguishable from the baselines.The results indicate no measurable throughput impact from enabling the hooks, exporting I/Q samples, or choosing ASN.1 versus JSON.Source: Figure 5 · p. 6, §4.1 · p. 6
- The E3Controller adds roughly two CPU cores; stack power is 14 W DL versus 11 W baseline and 11 W UL versus 10 W baseline.The pinned threads poll continuously for deterministic real-time performance, making CPU occupancy the dominant framework cost rather than energy.Source: §4.1 · p. 6
4.2 E3Controller Latency
- Across all four configurations, median RAN-to-dApp latency is approximately 115–120 µs, with an interquartile range of about 10 µs.These latencies remain below the sub-millisecond budget required by real-time dApps.Source: Figure 6 · p. 7, §4.2 · p. 7
- Grid transfer and shared-memory write dominate at approximately 69 µs; the publisher adds about 24 µs, while JSON encoding takes 3.6 µs versus 1.2 µs for ASN.1.The four pipeline stages account for approximately 106 µs; the residual relative to Figure 6 is attributed to queueing in libE3.Source: Figure 7 · p. 7, §4.2 · p. 7, Figure 8 · p. 7
5 Conclusion and Future Work
The conclusion presents the E3Controller as a way to expose real-time OCUDU RAN data to dApps, and outlines a future role as a platform for programmable RAN services.
5 Conclusion and Future Work
- Future work envisions dApps dynamically injecting logic into selected RAN functions to extend scheduling, PHY processing, and other components without modifying or redeploying the underlying RAN software.The proposed direction targets optimization, sensing, and AI-driven applications.Source: §5 · p. 7