OCUDU Ecosystem Developer Summit

This session reviews recently implemented physical layer (PHY) features, including extended downlink MIMO and TTI bundling.

I will present the key engineering challenges encountered during development and the practical solutions we deployed to overcome them.

The talk concludes with a forward-looking overview of upcoming PHY enhancements, outlining anticipated implementation hurdles and our proposed technical roadmap.

This technical talk presents AMD’s work running and optimizing the OCUDU software stack on AMD EPYC-based hardware platforms. It will cover benchmark methodology, CPU performance characterization, software and library optimization opportunities, and a forward-looking proposal for an AMD GPU acceleration backend for selected OCUDU processing paths.

Configuration schema is a recent addition to the OCUDU codebase that provides a standardized description of the apps configuration in the JSON Schema format – generated directly by the apps themselves, so it’s always up-to-date. This allows for other tools to interpret, process and interact with the OCUDU configuration in a deterministic and repeatable manner.

This session explains how OCUDU apps handle its configuration, discusses the technical challenges that still remain and also shows the benefits unlocked with OCUDU configuration schema:
- external configuration validation with standard off-the-shelf tools,
- configuration auto-completion,
- up-to-date documentation generation,
- new tools for config conversions,
- better hints for AI tools,
and many others.

The session is presented by the developer of the schema generation code and may contain some technical parts – however, OCUDU users who don’t interact with the code directly can still benefit and learn about the new tooling provided.

OCUDU gives you a working CU/DU. It does not give you something you can deploy, operate, and hand to someone else. Those are different problems, and the second is not solved by hardening the first.

This is a report from the integrator's side of that line. Building a downstream distribution, we found the missing pieces fall mostly into two classes: runtime configuration/management, and deployment/integration.

We will take examples from each and show what we changed in the codebase and why they are necessary for productizing OCUDU. Examples include runtime command surfaces for parameters that could only be set at startup, a cell-safe shutdown mechanism that is a necessity for operators when managing a live system, a v1 of an M-plane client to simplify RU integration, and a look at how CNS uses these new contributions to integrate AI-native intelligence with the OCUDU stack.

OCUDU has earned the title “Linux kernel of RAN”: an open, carrier-grade CU/DU. But the Linux kernel alone never shipped a router. OpenWrt did – by turning the kernel into an opinionated, deployable appliance with configuration, lifecycle management, UI, packaging, upgrades, and extensibility.

OCUDU is at the same point. It provides the RAN core, but teams moving from lab to field still rebuild the same surrounding layers: SMO/orchestration, zero-touch O-RU onboarding, timing automation, multi-vendor radio profiles, upgrade/rollback, security/compliance, application infrastructure, and air-gapped packaging.

This talk proposes an “OpenWrt for RAN”: a community-maintained, batteries-included distribution around unmodified OCUDU that can be deployed as a ready-made appliance, while remaining open to extension and customization. Drawing on hands-on integration of upstream OCUDU with an open-source packet core and multi-vendor O-RUs, I will present a practical reference architecture and the minimum platform services needed to turn CU/DU software into a secure, compliant, field-deployable private 5G system.

The OCUDU O1 adapter today uses a 1:1 sidecar pattern: NETCONF server, O1 adapter, single monolithic gNB config file, full restart. No per-RU addressing, no differential config push, no RU identity abstraction. Any change disrupts all connected RUs — blocking production multi-RU deployments.
This talk presents Phase 1 Multi-RU enablement: six new modules within the existing K8s sidecar, without forking the core — Multi-Instance YANG Datastore (/ru-inventory/ru[id]/config), RU Registry for device identity and DU mapping, Config Router for 1:N NETCONF dispatch, Per-RU Config Generator for device-specific fragments, Reload Orchestrator for scoped per-cell restart, and Multi-O-FH Endpoints for independent fronthaul addressing.
The adapter transforms from a stateless single-target passthrough into a stateful N-target dispatcher — enabling SMO to address individual RUs via standard NETCONF. I will compare current vs. proposed call flows, detail seven key design changes, and outline the Phase 2 FCAPS roadmap covering fault, performance, security, and AI/ML-driven optimization.

What if every OCUDU developer — from a hobbyist or first-time contributor on a laptop to a researcher training AI for 6G networks — could test the stack over realistic radio conditions, without owning any RF hardware?

Today, OCUDU's ZMQ radio path is a perfect loopback: great for functional tests, but it never fades, never interferes, never moves. Real radio behaviour stays locked behind commercial channel emulators and lab testbeds most of the community can hardly touch.

ocudu-gpu-channel is an open-source (MIT) attempt to change that. It slots between OCUDU and srsRAN and replays standard 3GPP channel models — fading, mobility, interference — in real time on a gaming GPU, fast enough to keep up with the live stack (~180x faster than CPU on the heaviest standard profile).

When realistic radio conditions run on a graphics card a student already owns, the distance between curiosity and experiment collapses: a newcomer can watch a connection fight through fading on day one, and AI can learn from a living network instead of a recording. As radio networks move onto GPUs, this is ground the community can own — knowing how OCUDU behaves over the air before anyone touches the air.