Native CUDA Acceleration and a Multi-Vendor Foundation for AI-RAN dApps
AI-native RAN needs more than AI models. It needs an open platform to run them. The GPU-accelerated OCUDU L1 is now available in the open repositories, with the dApp/E3 framework following shortly. Together they establish an open, AI-native foundation for the RAN: a place where AI applications run inside the radio itself.
DeepSig helped build that foundation, and we are putting our own applications on it. OmniSIG, OmniPHY, and Axon are moving onto these interfaces as ordinary dApps, on the same terms as any other vendor, and we are releasing open reference designs against the same contracts. The goal is an ecosystem built on shared, open interfaces instead of private vendor hooks. This work arrives as AI-native RAN becomes an industry and national priority.
Figure 1. A GPU-accelerated OCUDU gNB at the AI-RAN Alliance: a compact desktop GPU, a software-defined radio, and a handset pulling live traffic.
A GPU-native L1, out in the open
Software RAN has always faced the same constraint: the physical layer is the most computationally demanding part of the stack and the least forgiving on latency. AI has therefore stayed outside the real-time core, confined to analytics and offline optimization.
OCUDU exists to change that, by making AI a native part of the RAN. The open CU/DU stack — BSD-3-licensed, neutrally governed under the Linux Foundation, built on srsRAN — reached v1.0 at MWC in March 2026 with 47 founding organizations, and the interfaces AI needs are designed in from the start.
The OCUDU Hardware Acceleration Working Group (WG-0001) has released a CUDA-accelerated OCUDU L1, and it is in the OCUDU GitLab today. The pipeline was written for the GPU from the start, not ported from CPU code, and is held to algorithmic parity with the reference implementation. It is GPU-resident: the uplink shared channel stays on the device from resource grid through LDPC decoding to transport block. The accelerated set covers PDSCH, PUSCH, SRS and PRACH, the split-8 lower PHY, and split-7.2 fronthaul compression.
It also matters where the code lives. The GPU paths sit behind OCUDU’s own component factories, with CPU fallback through identical APIs, and three memory models come from one codebase. A laptop CPU, an RTX 6000 under the desk, and a GB10 or GH200 rack all run the same code.
The gains are large. The heavy shared-channel blocks land in the several-fold to order-of-magnitude range, and fronthaul compression improves by roughly two orders of magnitude. One compact GPU sustains ten full-rate single-antenna sectors at 100 MHz. The companion paper, to be published soon, has the full matrices, measured on raw tails.
Figure 2. Per-block speed-up on a compact GB10 GPU against a production CPU baseline; all blocks are above 1× with no accuracy cost.
Block error rate holds within 0.06 dB of the CPU implementation. Parity was a design constraint from the outset. This is the same radio computed faster, with no accuracy traded for throughput.
The practical effect is one unified software architecture from L1 to L3. Learned processing in the PHY, learned policy in MAC and RRC, observational AI beside the stack, all reachable by native CUDA dApps without leaving the process.
dApps that run inside the loop
Earlier dApp and E3 work proved the concept on observational applications such as spectrum sensing, which are forgiving hosts for AI because nothing in the radio waits on the answer. But a learned receiver has to produce its output before the decoder needs it, and a scheduling policy has to return a decision while the allocator can still use it. These inline and real-time cases are where most of a network’s performance is decided.
DeepSig leads both working groups, and much of the engineering here is ours. We needed this foundation to exist before we could ship anything on it, so we built the acceleration before the applications and the interface before our own products.
The dApp / E3 framework — releasing shortly
WG-0002 inventoried 45 AI-RAN runtime use cases drawn from the AI-RAN Alliance, 3GPP TR 38.843 and the O-RAN nGRG, and let the deadlines classify them into three contracts, each with an overhead budget excluding inference time. Observe-and-advise may sit out of process because nothing waits on it. Inline and real-time control are invoked inside the DU process through a function table, with bulk data passed as a device pointer, so nothing is serialized while a slot is in flight.
| Contract | dApp overhead budget (target) | Representative use cases |
| Class A — Inline PHY | < 1 µs per call at P99.9 < 20 µs for a bulk-tensor handoff zero copies, zero slot-path allocation |
Neural receivers, channel estimation and equalization, neural SRS and PRACH, inline beamforming, PAPR/DPD, two-sided learned modems, ISAC waveform design |
| Class B — Real-time control | < 10 µs per decision at P99.9, including host-side validation of the returned intent |
MAC scheduling and resource allocation, per-slot power control, HARQ and link adaptation, beam selection and failure recovery, CSI decompression |
| Class C — Observe & advise | < 1 ms to publish at P99 exactly one copy out zero slot-path cost in the PHY |
Spectrum sensing and sharing, ISAC radar features, interference detection, RF fingerprinting, positioning, CSI prediction, cell-free clustering, RIS control |
The implementation already meets these budgets: the in-process call measures 0.42 µs at P99.9, and descriptor-mediated control of large payloads tops out at 14.8 µs. One cross-cutting target matters more than any single row: no measurable shift in P99.9 slot-processing time with dApps armed and active.
All three classes share one management plane: an embedded E3 agent inside the DU that admits, arms, activates and reports health on every application, and never runs on a slot path. Each moves through a signed lifecycle — manifest, artifact hash and SBOM, then arm, shadow, activate, drain, unload — atomic at a slot-safe boundary.
The interfaces ship with OCUDU; the applications ship separately. The dApp APIs, the versioned C ABI and the E3 management interface are part of OCUDU itself. What vendors build against them is a standalone module out of tree, so a proprietary model never needs to enter the open tree to run in it.
Figure 3. Left: dApp lifecycle management over E3 on a running gNB, instances activated and deactivated while traffic flows. Right: the Class A neural receiver, 256QAM PUSCH at 0.0% BLER.
Twenty-three reference packages ship across the open SDK and vendor example set, each climbing the same ladder from unit tests to live over the air. Three dApps run concurrently over the air today: a Class A neural equalizer, a Class B scheduler, and a Class C spectrum/SRS-ISAC sensor, all managed through E3 under live traffic. This reflects an early development build, with more detail on the reference dApps to come.
Built for where the industry and national policy are heading
AI-native RAN has moved quickly from research agenda to industry and national priority, and the foundations such a stack needs are being specified and, increasingly, funded. NTIA’s latest round of the Public Wireless Supply Chain Innovation Fund, focused on AI-Native RAN, is one signal among several: it calls for open, interoperable equipment meeting 3GPP and O-RAN specifications, security built into every layer, architectures that enable third-party services, and real-world demonstrations that generate measured data.
That list maps closely onto what is described above. A community-owned interface and a versioned C ABI are what open and interoperable means in practice; out-of-tree modules let third parties build without forking a DU; the signed lifecycle puts security in the layer itself; and live over-the-air operation with in-repo validation matrices is what demonstration data looks like when it is meant to be checked. None of this makes OCUDU the only way to build an AI-native stack, but a great deal of the foundation now exists in the open, under neutral governance, ready to be built on.
An interface worth sharing
If several RAN software stacks expose the same dApp interfaces, a dApp becomes portable. Stripped to essentials, the contracts are a versioned C ABI, a schema, a lifecycle and a set of overhead budgets, adoptable by any DU with equivalent substitution seams. An operator could then run the same neural receiver on two vendors’ DUs. Interoperability does not require anyone to adopt OCUDU, only agreement on the interface.
Reference designs in the open — and field-proven apps on the same contract
The first route is open source references. DeepSig will release AI-RAN reference designs for key dApp use cases through the AI-RAN Working Group, so that each of the three contracts has a complete, buildable implementation behind it, spanning inline PHY, scheduling policy and sensing, helping to accelerate usage in dApp development, deployment, management, and test.
The second is vendor-supplied dApps such as our own proven solutions. Vendors can embed new software and AI solutions in their own dApp modules which can be used interoperably. We bring our proven OmniSIG software for spectrum sensing and ISAC, OmniPHY for learned uplink reception, and Axon, our two-sided AI-native air interface, available as interoperable dApps on these same interfaces.
OmniSIG is fielded on hundreds of platforms; OmniPHY’s neural receiver measured uplink throughput and sensitivity improvements at the cell edge and under high interference in commercial 5G field trials. Axon highlights what a 6G Air Interface could be: a learned modem runs inside the loop, laying the foundation for two-sided semantic communications.
Figure 4. Open reference designs and existing field-proven applications, arriving on one common dApp interface.
The CUDA-accelerated L1 is in git now, and the dApp/E3 framework follows shortly. The AI-RAN Working Group’s next call is on 5 August and new participants are welcome — technical contributions, a use case you think the contracts handle badly, another stack or backend on the same interfaces, or feedback before they harden.
Where to find it
Hardware Acceleration Working Group (WG-0001) gitlab.com/ocudu/work_groups/wg1_hw_accel · charter
AI-RAN Working Group (WG-0002) gitlab.com/ocudu/work_groups/wg2_ai_ran · charter
CUDA-accelerated OCUDU L1, in git today gitlab.com/ocudu/work_groups/wg1_hw_accel/cuda_accelerated_ocudu
Next AI-RAN Working Group call — 5 August, new participants welcome joining details via the working group
The WG-0002 dApp/E3 framework and the companion papers from both working groups are being released shortly.
Acknowledgements
Built in open collaboration, with thanks to the Northeastern/WiNES and NVIDIA Aerial teams, whose published dApp work this builds on. Supported by the U.S. DoD OUSD(R&E) FutureG Office through the National Spectrum Consortium, funding complementary workstreams at SRS and DeepSig.
