If you’ve been meaning to catch up on the OCUDU Ecosystem Foundation’s webinar series but haven’t found the time, this post is for you. Over three sessions, some of OCUDU’s echnical architects walked through an overview of the project, how to contribute to it, and how the codebase is structured. Here’s the recap.
First, what is OCUDU?
The first webinar gave an overview of OCUDU. The name of the OCUDU project hints at its origins as an open source code base that provided the functionality of the Open-RAN (O) Central Unit (CU) and Distributed Unit (DU) as defined by the O-RAN alliance. Nowadays, it is quickly evolving to provide a broader set of functionality related to control and data planes for AI-Native RAN. The OCUDU open source project builds the software stack required for 5G and 6G networks with the goal of deployment in production networks, not just labs.
It’s accomplishing two things at once:
- Provide a fully deployable commercial stack that can be fielded today.
- Provide researchers and engineers a real, open, standard compliant platform for building 6G enhancements, instead of starting from scratch, providing a direct path to validate and deploy.
The project grew out of srsRAN, which OCUDU Ecosystem Foundation member SRS had developed and maintained for over four years, building up more than 10,000 active users along the way. In December 2025, that codebase moved to the Linux Foundation, srsRAN was archived, and OCUDU took over as the vendor-neutral home for the work going forward. Two things changed in that move: the license went from the copyleft GPLv3 to a fully permissive BSD-3-Clause-Open-MPI license, and the governance moved out of a single company and into the Linux Foundation.
That second point is important: the OCUDU software stack isn’t run by any one vendor; it has a two-tier structure. The OCUDU Ecosystem Foundation sits on top and sets strategic direction, open to industry and research members, and may, in time, host additional, related software projects. Below that, the Technical Steering Committee provides oversight over the implementation of the OCUDU software itself. However, anyone can help influence the technical direction of the project through contributions. Code, docs, tests, anything – it’s all done in the open, in the project’s public repositories.
Who’s OCUDU actually for? Two main groups:
- Developers and researchers building or integrating Open RAN systems, or who want a production-quality platform for 5G/6G experimentation.
- Anyone deploying wireless networks – Public and Private network service providers evaluating disaggregated RAN, or system integrators combining a RAN stack with a 5G core and putting it into the field.
The technical shape of it
OCUDU implements the full Layer 1, 2, and 3 stack in software – including the physical layer, which is the compute-heavy part most projects farm out to third-party libraries. OCUDU doesn’t have hard dependencies there; it’s all built in-house, and it runs on regular commercial hardware, both x86 and ARM.
Because the interfaces between components (E1, F1, 7.2, and so on) are all standards-based, you’re not locked into an all-OCUDU deployment. You can run it as one monolithic binary (a full gNB in a single process – fast, since internal messages skip the network stack entirely), split it into separate CU and DU binaries, split further into CU-CP and CU-UP as defined by the O-RAN Alliance, or pair OCUDU’s physical layer with a third-party MAC/L2 (or vice versa) using the FAPI interface. Real examples of that last case include integrations with Intel FlexRAN and NVIDIA Aerial.
On the feature side, as of the 26.04 release, OCUDU supports FR1 and FR2, FDD and TDD, bandwidths up to 100 MHz (TDD) and 400 MHz (FR2), up to 4-layer MIMO, hardware acceleration via DPDK/BBDEV, and a growing list of handover and mobility features. The roadmap (releases twice a year, spring and autumn) is heading toward beamforming, massive MIMO, more NTN support, carrier aggregation, and eventually dual connectivity over the next three years. And because it’s genuinely community-governed now, that roadmap isn’t fixed – if there’s a feature you care about that isn’t on it, the invitation is to come build it.
How contributions actually work
The second webinar, “Working in the OCUDU Codebase,” was a practical walkthrough of the contribution process, and it’s worth summarizing because it answers the question everyone actually has: “okay, but how do I get my code merged?”
Where things live: everything happens at gitlab.com/ocudu. There’s a GitHub mirror too, but it’s read-only – no issues, no pull requests, just code you can fork if GitLab isn’t your thing.
Got an idea? There are two paths depending on size:
- Small stuff – a bug, a question, a minor tweak – just open an issue on the main repo.
- Bigger changes that touch multiple layers, break compatibility, or need real sign-off go through an OCUDU Improvement Proposal (OIP), a merge request against a dedicated proposals repo, discussed openly and, if it’s big enough, voted on by the TSC.
If you’re not sure which bucket you’re in, the advice from the team is simple: just open an issue and ask. It costs you nothing, and a maintainer will tell you if it needs to escalate to a full proposal.
Before you write code: build the project and run the existing tests first, so you know your setup actually works. There are install scripts for the mandatory dependencies, and the docs walk through build options in detail. Looking for something to start with? Issues tagged good first issue are curated for exactly that.
A few rules that trip people up:
- Every commit needs a Signed-off-by line (the Developer Certificate of Origin). It’s one flag (-s) in git, If you used an AI assistant to help write the code, say so, in a line at the bottom of the commit message. You’re still the one signing off on the license and correctness either way – “the AI did it” isn’t a valid excuse. For more guidance, check out our code contribution guide.
- Keep MRs small. Anything under 10 lines needs one approval; bigger changes need two, and anything that touches multiple layers may need manual and end-to-end validation on top of that.
- Make sure your fork has GitLab’s shared runners enabled, or your CI pipeline won’t have anywhere to run.
What happens after you open an MR: it gets triaged (daily, or within five working days at most), labeled, assigned a reviewer, reviewed, and – once it’s green and approved – merged by a maintainer. Merged code lands on the dev branch first; it’s promoted to main once nightly testing passes. Releases happen twice a year, in April and October, and by the time a release ships, the code has gone through unit and integration testing inside the main repo and end-to-end testing against real hardware and third-party components in a separate test infrastructure repo (also open source, if you want to replicate the test setup yourself).
One nice detail: inactive issues and MRs (30+ days with no activity) get auto-closed, but nobody’s trying to trip you up – just leave a comment or tag a maintainer if you’re still working on something.
How the codebase itself is organized
The third webinar went under the hood, and if you’re planning to actually touch the code, this is the one to watch in full. The short version: OCUDU is built around clean architecture – protocol logic sits in the innermost layer, and everything else (hardware, threading, I/O) lives further out and depends inward, never the other way around.
Why bother? Because multiple teams work on different layers (MAC, PHY, RLC, and so on) in parallel, and nobody wants a change to the physical layer accidentally breaking the scheduler. Keeping strict boundaries between layers means:
- Swapping in a new radio unit or hardware accelerator never touches the protocol code.
- The DU-high and DU-low can be developed and even deployed independently, talking to each other only through the FAPI interface — which is also how OCUDU can pair its own Layer 2/3 with a third-party physical layer, or vice versa.
- Unit tests can run in isolation, fast, without needing real hardware.
A few implementation details worth knowing about if you’re going to write code:
- It’s all C++17, with in-house libraries for coroutines, executors, and lock-free memory pools (the team wants C++20 coroutines eventually, but isn’t there yet).
- 3GPP procedures are implemented as coroutine-based async flows rather than callback soup – the code reads a lot like the spec’s message sequence charts, which makes it easier to follow and test.
- The DU’s real-time path (Layer 1/2, running on a strict slot budget – 500 microseconds for a typical TDD config) forbids dynamic memory allocation, mutexes, exceptions, and blocking I/O. Logging and pcap writes get pushed onto a separate low-priority thread via lock-free queues instead. A custom real-time sanitizer runs in CI nightly to catch violations before they land.
- Threading itself is abstracted away from the protocol code entirely – business logic submits tasks to executors and has no idea whether it’s running on a Raspberry Pi or a 200-core server. That’s a big part of why the same code scales across such different hardware.
If you want to actually find your way around, the repo structure is worth memorizing: include/ and lib/ hold public interfaces and their implementations per component (CU, DU-high, DU-low, and so on), and apps/ holds the different deployable binaries for each functional split.
Where to go next
OCUDU is a shared, neutral project. The roadmap is shaped by contributions – if you think a feature is missing, we encourage you to get involved and contribute! This is how you can get started:
- Code, issues, and discussions: gitlab.com/ocudu
- Docs: docs.ocudu.org
- OCUDU Ecosystem Foundation info: ocudu.org
The webinar series is taking a break over summer, with episodes resuming in September 2026. Make sure to watch the recordings on our youtube channel and follow the OCUDU Ecosystem Foundation on LinkedIn and/or X for updates on the next episode.
OCUDU Ecosystem Developer Summit, Alexandria, Virginia, October 20-22, 2026
OCUDU Ecosystem Foundation is also hosting its first ever developer summit! For three days, the OCUDU community will come together for technical collaboration, knowledge sharing, and hands-on discussion focused on advancing open, AI-native RAN infrastructure.
If you are a developer, operator, researcher, systems integrator or technology provider, this is the place to showcase new innovations, share deployment experiences, and collaborate on the project’s technical roadmap. Make sure to register and submit your CFP by August 17, 2026.