A community-maintainable CUDA backend for OCUDU gives operators and system integrators a faster, more efficient open 5G stack and the execution foundation for an AI-native RAN.
Operators need more capacity, lower latency, and better energy efficiency from their existing RAN infrastructure, while creating a practical path toward AI-RAN and 6G. That requires an open, commercially deployable software platform, grounded in 3GPP and O-RAN interfaces, that runs both real-time radio processing and AI on efficient hardware and can be customized without rebuilding the distributed unit (DU). A shared open CU/DU (OCUDU) also makes vendor diversity practical across national, private 5G, and defense networks.
OCUDU is the open-source CU/DU project the industry now calls the Linux of RAN. DeepSig contributed a GPU/CUDA-accelerated backend for the compute-intensive parts of OCUDU’s physical layer and the O-RAN fronthaul that feeds it. Built for community maintenance, the backend operates behind OCUDU’s existing interfaces and configuration. When a supported GPU is available, selected functions run on it; otherwise, OCUDU continues to use its existing CPU implementation. The immediate result is faster physical-layer processing. The broader opportunity is a shared execution foundation for AI-native RAN applications that must operate directly within the radio’s real-time path.
Why Layer 1 decides what a software RAN can do
In any virtualized or Open RAN deployment, Layer 1 — the physical layer, or L1 — is the major compute bottleneck: the real-time signal processing that moves information on and off the air, plus the O-RAN fronthaul compression between the radio unit and DU. It sets the ceiling on what a software DU can do: how many sectors and users it can support, how much bandwidth a server can serve, how reliably it meets slot-time deadlines that a live network cannot miss, and how much power and hardware it requires. Spectral efficiency, energy per bit, and cell-edge reliability are physical-layer problems first and foremost. If AI cannot participate in real time, it can advise the network after the fact, but it cannot change what the radio does with the slot in front of it.
GPUs are a natural fit. They execute thousands of operations at once, which is how both 5G baseband processing and modern AI are structured. But moving one function to a GPU does not guarantee a better network: each CPU-GPU transfer takes time. What matters is a pipeline, not a kernel catalog, so intermediate results stay resident on the accelerator. That residency is the speedup, and it is what makes the same GPU useful for an AI-Native RAN: the data a neural receiver or learned estimator needs is already where the model runs.
An architecture the community can adopt
Acceleration only helps the industry if the Open RAN and OCUDU communities converge on the interfaces and the architecture that carry it. A private GPU path that only one company understands will not be widely deployed, so the backend is built inside OCUDU’s existing architecture.
OCUDU already assembles its modem through factories: configuration-driven builders that choose a concrete implementation behind a stable interface when the software starts. Acceleration is selected through the same factories and configuration that the CPU path already uses. Every accelerated function falls back to the CPU when no GPU is present, or when an operator leaves a given block on the host. CUDA is the first backend. The contracts in the middle of the stack do not name CUDA, so other accelerators can plug in through the same architecture as the community agrees on.
Figure 1. Acceleration is selected through OCUDU’s existing configuration. Neutral contracts carry data between stages. CUDA stays behind the API, so other hardware can use the same architecture.
In practice, that means keeping the whole pipeline resident. In a split-7.2 deployment, compressed radio data is decompressed by CUDA kernels directly into the resource grid that the uplink receiver, channel estimator, and random-access detector read from; in a split-8 deployment, lower-PHY transforms write that same grid; downlink encoding populates a device-visible grid that is then compressed for fronthaul or turned back into samples. Intermediate results do not shuttle to the CPU between stages.
Figure 2. Solid paths stay on the GPU. In a split-7.2 deployment, incoming radio data is decompressed directly into the grid that the uplink receiver, channel estimator, and random-access detector read from.
The foundation an AI-native RAN actually needs
AI-native RAN needs more than models. It needs an open platform that those models can run on, inside the radio, in time to change the slot. Applications that run next to the modem and consume exported metrics still have their place. What a GPU-resident L1 adds is the other half: when an AI function must participate in the real-time chain itself, such as a neural receiver reading the same grid the uplink uses, the data does not have to be shipped to a second system first.
That is how RAN efficiencies become operational rather than theoretical: better receivers raise spectral efficiency and cell-edge reliability, fewer servers lower energy per bit, and learned 6G air-interface ideas can be tried inside a standards-compliant open stack. This CUDA backend is how those functions have somewhere to run in real time.
What the early numbers show
DeepSig added preliminary benchmarks comparing OCUDU’s CPU and GPU implementations on the same NVIDIA DGX Spark system. They show large latency and throughput gains for the functions that dominate a live DU, often enough to meet real-time deadlines that are difficult to meet on the CPU path alone.
Five of the six accelerated blocks were faster on the GPU across all configurations tested. The largest measured speedups were in O-RAN fronthaul decompression, random-access detection, batched lower-physical-layer processing, and the end-to-end uplink receiver. Downlink encoding is already competitive and pulls ahead as transport blocks grow and more layers are in flight, and the region a loaded commercial cell occupies.
Figure 3. Preliminary GPU speedups versus OCUDU’s CPU path on the same NVIDIA DGX Spark system. Bars show the range across configurations; the large dot indicates the best-measured result.
In a separate test using OCUDU’s simulated radio environment, a single system supported six full-rate sectors at an average GPU utilization of 21 percent. Although the test didn’t include physical radio hardware or all fronthaul packet handling, the 21 percent average GPU utilization indicates substantial compute headroom for additional RAN and AI workloads.
Commercial products on an open platform
DeepSig is building its commercial AI-native products on this architecture, including OmniPHY-5G neural-receiver software, OmniPHY Axon air-interface software, and OmniSIG spectrum-awareness software, because these products must run within the real-time path of a production RAN. Contributing the acceleration backend to OCUDU does not replace that work. It puts the same substrate under a platform that the rest of the industry can use.
The opportunity is not only a faster open RAN. It is an open foundation on which vendors can innovate, operators can customize, and AI-Native radio capabilities can run without rebuilding the stack. As with Linux, an open foundation does not eliminate the need for commercial vendors; it gives them a shared platform on which to deliver integrated, production-ready solutions and support.
The full architecture, methodology, and per-block results are in the companion technical paper. The open-source implementation is available through OCUDU Working Group 1.
This work was supported in part by the U.S. DoD OUSD(R&E) FutureG Office through the National Spectrum Consortium.
