Title: Inside the AI-RAN and O-RAN Open-Source Stack: What the Stack Enables, Where It Blocks Us, and What Should Come Next
Authors: Sagar Rora、Mahesh Marina、Doug Nicely、Tim O’Shea
Scribe: Ying Yao (Xiamen University)
Introduction
This “non-paper session” focused on the recent evolution of the open-source ecosystem for cellular networks. Rather than showcasing a specific software project, the discussion centered on key questions: What open-source components are currently available for researchers to build end-to-end cellular networks? What research problems are these tools suited for? And what critical capabilities remain missing as we transition from simulation to real-world system experimentation?
The moderator began by outlining the fundamental components of the Radio Access Network (RAN). Responsible for the “last-mile” connectivity of cellular systems, the RAN encompasses both computing infrastructure and a variety of hardware and software elements—including the CU, DU, RU, UE, core network, and O-RAN controllers. While cellular network research historically relied on simulators or closed-source protocol stacks, the past decade has seen the maturation of an open-source ecosystem—exemplified by projects such as OpenAirInterface, Duranta, O-RAN RIC, and various Linux Foundation Networking initiatives. This evolution enables researchers to deploy increasingly complete networks on general-purpose computing platforms, Software-Defined Radios (SDRs), or software-based simulation environments.
Four panelists discussed this shift from the perspectives of open-source project maintainers, academic users, industry standards bodies, and AI-RAN R&D teams. A recurring theme was that the value of open-source RAN extends far beyond merely “accessing readable protocol stack code”; it immerses researchers in an environment where they can deploy, modify, measure, and validate real cellular systems end-to-end. At the same time, factors such as the learning curve, stability, scalability, data acquisition, hardware dependencies, system orchestration, and benchmarking remain pivotal in determining whether these platforms can truly serve as the infrastructure for the next phase of AI-native cellular research.
Key idea and contribution
- Open-source RAN has evolved from mere “research code” into end-to-end experimental platforms. Researchers can now run components—such as the UE, CU/DU, core network, RIC, and channel emulator—within a unified environment, allowing them to conduct experiments entirely in software before gradually integrating USRPs or other wireless hardware.
- The best way to get started is not to read the entire protocol stack first, but to get the system up and running. Sagar suggests that researchers first deploy the full link and observe—via logs from the UE, RAN, core network, and RIC—how a connection or service process traverses different protocol layers. Only then should they decide whether they wish to modify the PHY, MAC, scheduler, or control components like xApps/dApps.
- Platform selection should be driven by the specific innovation. Mahesh emphasizes that there is no single “best open-source stack” suitable for every research question. Requirements regarding baseline platforms, the depth of modification, and implementation costs vary depending on whether the goal is to propose a novel system design or simply to validate a new method within an end-to-end environment.
- AI has made experiments on real systems more critical than ever. Tim points out that machine learning methods rely heavily on data distribution and environmental realism. Results obtained solely in MATLAB or abstract simulators are increasingly insufficient to demonstrate how an algorithm performs in actual wireless systems; the ability to modify the protocol stack and conduct over-the-air or high-fidelity software experiments forms a vital foundation for AI-RAN research.
- Bottlenecks in the next phase lie not just in code, but in data, scale, and system integration. Panelists highlighted issues such as a lack of open datasets and low-level analytics, the difficulty of replicating large-scale Massive MIMO and multi-user scenarios, reliance on GPUs/accelerators, fragmentation of control frameworks, the complexity of cross-layer orchestration, and the absence of unified benchmarks.
- Open-source implementations are reshaping the relationship between standardization and academic research. In the 4G era, open-source protocol stacks typically emerged only after standards and commercial systems had matured; with 5G, this time lag has narrowed. Panelists believe that as we move toward 6G, new mechanisms may be prototyped and validated in open-source implementations before influencing standardization discussions, potentially positioning open-source software as a vehicle for experimentation prior to the formal standardization process.
Q&A
Q1: Where should researchers begin when first encountering open-source cellular protocol stacks like OpenAirInterface or Duranta?
A1: Sagar suggests performing an end-to-end deployment first, rather than diving straight into the code of a specific layer. Taking the Duranta/OpenAirInterface ecosystem as an example, researchers can simultaneously deploy the UE, CU/DU, core network, and near-real-time RIC, then use component logs to trace the events occurring during connection establishment and data transmission.
The value of this approach is that researchers can gain an understanding of the complete system before determining where their specific research problem fits in. If the goal is physical layer algorithms, they can delve into the PHY layer; if the focus is MAC or scheduling, they can modify the relevant modules; if they wish to study intelligent network control, they can concentrate on the RIC, xApps, dApps, or other pluggable control components. Mahesh adds that the choice of platform should depend on existing work and one’s own innovations, rather than selecting a tool first and then searching for a problem that fits it.
Q2: If a student wants to run their first experiment next week, what is the lowest-barrier “101-style” experiment?
A2: Both Tim and Sagar believe it is now possible to run a complete cellular system on a standard workstation or even a high-performance laptop. Researchers can launch multiple UEs, UE/channel simulators, DUs, CUs, and the core network simultaneously within a software environment, then run application-layer traffic to observe end-to-end behavior.
More importantly, this environment offers more than just the ability to “get things running.” Researchers can swap out channel models, modify algorithms related to error correction or modulation, change schedulers, or alter just the specific module that interests them. Tim also mentions AI-RAN-oriented reference designs, which aim to break down typical functions—such as channel estimation, equalization, decoding, and scheduling—into relatively independent, open templates. This allows researchers to plug in their own algorithms or learning models without having to rewrite the entire RAN.
Consequently, these platforms lower not only the barrier to deployment but also the gap between developing a specific algorithm and achieving end-to-end validation. Experiments that previously required extensive specialized hardware and systems engineering can now be conducted in software first, allowing researchers to decide later whether to integrate actual RF equipment. Q3: Are these open-source platforms mature enough? What are the most common challenges encountered in actual use?
A3: Mahesh offered a cautious assessment from a user’s perspective: while these platforms have matured significantly compared to a decade ago, they are still far from being truly “plug-and-play.” The first hurdle is the learning curve. Without prior experience experimenting with cellular protocol stacks, students can spend a vast amount of time simply understanding how to compile, configure, and connect the system, as well as how to troubleshoot issues.
The second hurdle lies in the experimental environment itself. Things are much simpler if an existing testbed or shared platform is available; however, building one from scratch adds the burdens of managing hardware, drivers, and RF/network configurations. A third issue is that open-source software inevitably contains bugs and stability problems; complex experiments often require researchers to identify and fix these issues themselves.
Furthermore, the cost of implementation depends heavily on the layer of the system being researched. If the RAN is treated as a “black box” while focusing on applications running on top of it, the required modifications may be minimal. Conversely, rewriting schedulers, physical layers, or cross-layer mechanisms demands a deep understanding of 3GPP specifications and the underlying code. Doug believes that future AI programming tools, pre-built configurations, specialized skills, and structured documentation could lower the cost of system deployment, though they cannot replace a genuine understanding of the research subject itself.
Q4: What capabilities are currently most lacking in the open-source AI-RAN/O-RAN ecosystem?
A4: The four panelists provided different yet interconnected answers. Doug emphasized the need for analytics and datasets. Training AI-RAN models requires real-world network data, yet operators and equipment vendors are often reluctant to release large-scale operational data. Consequently, if open-source networks, research testbeds, and real-world deployments could provide low-level measurement interfaces, logs, and reusable datasets, the scope for AI research would expand significantly.
Tim focused more on the issue of scale. While current platforms are suitable for small-scale end-to-end experiments, significant limitations remain regarding software stacks and available wireless hardware when researching 64T/128T Massive MIMO, massive multi-user scenarios, multi-cell coordination, or networks with thousands of terminals. High-fidelity channel models, ray tracing, and large-scale software simulations are helping to alleviate these issues, but there is still a gap compared to the scale of real-world operator networks. Mahesh highlighted two aspects: first, the reliance of AI-RAN on specific GPUs or accelerators, coupled with insufficient GPU virtualization capabilities; and second, the fragmentation of control systems. While cellular networks already feature SDN controllers, RICs, and various management components, they lack a sufficiently unified framework to ingest data, execute intelligent algorithms, and reliably perform closed-loop control.
Sagar further emphasized the importance of orchestration and benchmarking. Open systems allow users to freely mix and match CPUs, GPUs, radios, and software stacks, but this flexibility makes it difficult to determine which hardware-software combinations are best suited for specific workloads. Without standardized test scenarios and performance benchmarks, it is challenging for researchers and deployers to make fair comparisons between different systems.
Q5: What are the genuine points of contention within the community regarding open RAN?
A5: There is broad consensus among the panelists that open source is crucial and that AI will profoundly impact RAN; however, differing views persist regarding the specific path forward. Mahesh pointed out that the most immediate issue is choosing between various open-source stacks; relative maturity does not equate to ease of use, and different users may perceive platform maturity differently.
Tim raised a more fundamental question: will the open protocol stacks being built today remain merely research tools, or do they have a genuine chance of entering large-scale production networks? Transitioning from experimental platforms to carrier-grade infrastructure introduces a host of distinct challenges, including reliability, testing scale, intellectual property rights, maintenance responsibilities, and business models.
Another issue is how the industry reaches consensus. Traditional cellular systems rely heavily on standards bodies like 3GPP to define interfaces and functions, whereas open-source software enables a “build first, prove later” approach. The panelists suggested that certain functions could well be prototyped across multiple open-source stacks—generating experimental data—before being introduced into standards discussions. Consequently, future standardization processes might evolve in tandem with functional software prototypes, rather than being driven solely by documentation.
Doug also noted a more pragmatic constraint beyond technical pathways: cellular operations take place in a fiercely competitive industry with tight profit margins. No matter how advanced an AI-native network function might be, it is unlikely to see real-world adoption if the deployment costs cannot be justified by operational returns. Ultimately, open source, AI, and novel RAN architectures must all prove their economic viability.
Q6: Which trends in open cellular networks are most worth watching over the next 12 months? **
A6: Sagar mentioned that Duranta will continue to expand its support for open hardware architectures—including porting efforts for RISC-V—to enable components like CUs and DUs to run on a wider range of computing architectures. This aligns with the broader open-source ecosystem’s vision of “software portability and hardware choice.”
Tim is most looking forward to accelerated experimentation within AI-RAN. On one hand, open dApp/AI-RAN reference designs will make it easier for researchers to compare different learning algorithms; on the other, enhanced Massive MIMO capabilities and support for real-world measurements will facilitate the transition of AI models from offline experiments to system-level validation.
Mahesh focuses on two types of platform capabilities: AI-RAN infrastructure that allows RAN workloads to coexist with other AI or computing workloads, and more realistic, large-scale digital twins. The latter can provide a safe, repeatable sandbox that closely mimics real-world networks, serving as an environment for training and testing AI-driven control strategies.
Overall, the panelists do not believe the next breakthrough will stem from a single algorithm; rather, it is more likely to emerge from the progressive integration of an open protocol stack, data, AI control, digital twins, and scalable hardware. Only when these foundational capabilities mature in tandem can open-source RAN evolve from a useful research platform into infrastructure capable of reproducibility, comparability, and—ultimately—production-grade deployment.
Personal thoughts
The most valuable aspect of this discussion is that it elevates “open-source cellular networks” from a mere software engineering topic to a question of research methodology. In the past, wireless system research often involved a long implementation chain separating algorithms and protocols from real-world networks; consequently, much of the work remained confined to MATLAB, link-level simulations, or simplified system models. The ability to launch the UE, RAN, core network, and controller on a single machine now allows researchers to identify discrepancies between model assumptions and actual systems much earlier. This is particularly crucial for AI-RAN research, where training data, execution latency, hardware behavior, and protocol states directly determine the viability of learning-based approaches.
I also strongly agree with the panelists’ emphasis on “getting the system up and running first.” When faced with a protocol stack comprising hundreds of thousands of lines of code, attempting to read through 3GPP specifications and source code layer by layer from the start makes it easy to get bogged down in granular details. Establishing a minimal end-to-end deployment first—and then using logs to trace the path of a service process through various modules—allows for a faster understanding of the system architecture. Subsequently diving into the PHY, MAC, scheduler, RIC, or application layers based on specific research questions is far more effective than aimlessly reading through the entire codebase.
However, this session also highlighted that open-source code is not synonymous with open research infrastructure. While code may be public, high-quality real-world data, large-scale wireless hardware, stable testbeds, and unified benchmarks remain scarce. In AI-RAN research specifically, if different papers utilize varying protocol stack versions, CPUs/GPUs, wireless front-ends, channel models, and logging metrics, comparing results becomes difficult—even if all claim to have conducted “real-system experiments.” Therefore, the most valuable future endeavor is not merely building more robust open-source RANs, but establishing standardized experimental scenarios, measurement interfaces, data formats, and reproducible experimental workflows around them.
From a long-term perspective, open-source software could alter the sequence of innovation in cellular networks. Historically, the process followed a set order: standards were finalized, commercial equipment was implemented, and researchers finally gained access to a usable open-source version. If the 6G era enables the simultaneous development of standards and open prototypes, researchers could participate in protocol design using real code and experimental data, rather than simply conducting performance evaluations after the standards are already set. This shortens the path from “idea to prototype to standard to deployment,” yet simultaneously elevates the importance of software quality, test coverage, intellectual property, and community governance.
Overall, the core message conveyed by this SIGCOMM non-paper workshop is not simply that a more usable 5G open-source stack is now available; rather, it highlights that cellular network research is gaining a new experimental paradigm. Researchers can now start with fully functional end-to-end systems and validate algorithms, AI, hardware, and network control mechanisms within a unified environment. Ultimately, the future progress of AI-RAN and Open RAN will not hinge on whether a specific protocol stack is feature-complete, but rather on the ability to simultaneously address fundamental challenges such as data, scale, hardware abstraction, system orchestration, benchmarking, and the economics of real-world deployment.