Bringing AI directly into 5G physical-layer processing means operating in fractions of a millisecond, and DeepSig is helping address that challenge through the OCUDU dApp platform. Thousands of times per second, a base station’s distributed unit (DU) assesses radio conditions, decodes incoming data, allocates radio resources, and selects data rates. The platform lets independently developed AI applications participate directly in these functions, enabling more reliable decoding, smarter scheduling, and better adaptation to changing radio conditions.
Today, the OCUDU AI-RAN Working Group is releasing an open-source preview of the OCUDU dApp platform as part of the Linux Foundation’s OCUDU project. This post walks through the architectural requirements and empirical measurements behind the release, detailed in two companion papers: “The OCUDU dApp Platform: An Open Runtime and E3 Interface for Real-Time AI-RAN” (arXiv:2609.07843) and “Real-Time dApps for AI-RAN: Measured Interface Requirements for Inline PHY and Slot-Level Control” (arXiv:2609.07805).
Where the existing app tiers stop
O-RAN today gives operators two places to plug in software: rApps for decisions at the second level and above, and xApps down to roughly 10 milliseconds. Everything faster has stayed sealed inside each vendor’s DU. Northeastern proposed dApps to fill that gap; NVIDIA built a second framework, and they both published a report with Softbank on the approach — both export the DU’s data to a separate process, compute, and send a control message back, well suited to spectrum sensing and advisory use cases, a clean standard wire-protocol, E3, to enable interoperability which works well down to the 500us or 1ms range. We have work to build on this and extend it further into lower-latency territory.
Three timing contracts for AI-RAN
Different AIs require different levels of speed, trust, and assurance, so the OCUDU dApp runtime offers three contracts (Figure 1). Each dApp declares one:
Figure 1. Where each kind of RAN application acts. O-RAN’s controllers stop at about 10 ms; the OCUDU dApp platform covers the band below it with three timing contracts.
The three classes at a glance:
| Class | Timing target | Target use cases | Execution model |
| A — inline on GPU | Sub-slot, zero-copy | Neural channel estimation, equalizers, full neural receivers | GPU-resident replacement inside the signal-processing pipeline; zero host copies |
| B — bounded control | < 100 µs strict deadline | Learned scheduling, slot-level link adaptation | Direct in-process call at the scheduler’s decision point; range-checked output, operator-gated authority |
| C — observe & advise | Asynchronous, non-blocking | Spectrum sensing, ISAC, telemetry, data recording | In-process lease, supervised worker on the same host, or external E3 client |
The conventional non-dApp processing path remains alongside every dApp and is never displaced. A module that faults or misses its deadline eight times in a row is automatically routed around. Every package ships as a signed artifact with a software bill of materials under a trust policy the operator holds, and one management interface, E3, covers every class, whether the dApp is a shared object inside the DU or a container on another server.
What the measurements showed
We audited 39 real-time use cases proposed for dApps across O-RAN research reports and academic literature against strict 5G timing deadlines:
- 22 of 39 use cases (56%) cannot be served across an external process boundary.
- 13 use cases have no return path: data is exported from the radio, but there is no mechanism to return a control decision to the same slot.
- 9 use cases have a return path with unacceptable latency: under live traffic, worst-case IPC/network delays consistently breach the scheduler deadline.
We benchmarked each framework’s mechanisms on the same GB10 host the cell runs on. Idle, every path meets the 100 µs deadlines. On the air, any path that wakes another process misses it — at P99.9 (a critical measure for near worst-case latency during operation), SCTP hit 181 µs and ZeroMQ 787, versus 5.22 for the in-process call (Figure 2). The fallback keeps the cell up, but the answer arrives too late to use.
Figure 2. One scheduling request over four of the six boundaries measured, 20,000 requests each. Every path fits the deadline on an idle host. With a cell on the air, only the paths that never wake another process keep their tails.
Asynchronous sensing turns on behavior under load. The ring and ZeroMQ both publish a 68 KB slot in ~2 µs when idle; when a consumer falls behind, the ring bounds staleness and counts every drop, while a slow ZeroMQ subscriber silently discarded 10,000+ slots. For critical inline physical-layer processing, such as a neural receiver, we measured round-trip latencies on a class-A dApp with a mean as low as 50 µs, opening a new frontier for AI-RAN performance.
It runs on a live cell
On a single GB10 host with a split-8 SDR RU and three commercial handsets, we ran four dApps simultaneously from all three classes on a live, over-the-air n78 cell — with results that go beyond simulation and help prove out the platform.
Highlights from this test:
- 260,000+ uplink transmissions with the Class A neural equalizer replacing the conventional stage, zero fallbacks.
- Live model swapping — two equalizer variants compared over the air using E3 lifecycle commands alone, no redeploy.
- LLM-driven control — an agent read cell health, proposed a link-adaptation change over MCP tools, and validated it in a dry run before an operator applied it.
Help define the tier
The platform, SDK, and quickstart are public under the BSD-3-Clause-Clear license, and the quickstart runs every tutorial against a loopback E3 agent — no radio or GPU required. The benchmark suite, audited corpus, and raw traces are public as well, so anyone can test alternative interfaces or improvements against ours and help improve the OCUDU Ecosystem.
The dApp tier was born as an observer looking in from the outside — the right first step, but one that left the highest-value AI-RAN use cases, such as the neural receiver and the learned scheduler, on the wrong side of the glass. OCUDU moves them inside, with real-time guarantees, without forking anyone’s stack and enabling a whole new multi-vendor ecosystem to insert their ideas. Where the industry draws the line between AI and the radio will shape the next decade of RAN — and measured performance should help guide and evolve it as we seek to enable new value and use cases in RAN building on and extending the E3 foundation.
Build a dApp against the SDK, contribute performance and capability improvements, or bring a use case to expand enabled AI-RAN applications and interfaces—it’s all public, and the working group decides the tier.
Get the code and quickstart for OCUDU AI-RAN Working Group 2 on GitLab, and join future working group calls to discuss where OCUDU should go from here.
