A new paper on open-source 5G RAN platforms puts OpenAirInterface (OAI) and srsRAN side by side and tests them with real application traffic. According to its alphaXiv listing, the study covers three workloads: Video on Demand (VoD), Live Streaming (LS) and Cloud Gaming (CG). The listing describes the work as a dual perspective on performance and capabilities, and it does not publish winner-by-winner numbers in the material available today.
That gap matters for how this story should be read. The design is confirmed, the headline results are not. Anyone claiming that OAI beat srsRAN, or the reverse, on cloud gaming latency is guessing. This analysis sticks to what the listing supports, explains why the test design is interesting, and lays out what to watch for once full figures surface.
For gamers, the interesting part is the third workload. Cloud gaming punishes weak radio links harder than almost any consumer app, so a RAN study that includes it speaks directly to the future of streamed play on private and campus 5G networks. Our cloud gaming services ranking covers the consumer side. This piece looks at the radio layer underneath.
What the OAI and srsRAN study sets out to measure
The paper compares two open-source 5G RAN platforms, OpenAirInterface and srsRAN. Both are software stacks that implement the radio access network, the part of a 5G system that talks to phones and other devices over the air. Researchers and small operators use them to build private networks and test ideas without buying a commercial base station.
The evaluation has two halves. The first is qualitative and looks at supported features and deployment flexibility. The second is quantitative and covers radio resource control (RRC) setup procedures, compliance with theoretical data rates, and real application workloads with different quality-of-service requirements. That structure gives readers both a feature checklist and a performance record.
The listing also names a gap in earlier work. Prior evaluations varied the Software-Defined Radios (SDRs), the RAN configurations, the user applications and the number of real user equipment (UEs), and they often stayed inside a single testbed. The authors say they want a comparison that closes that gap. Maria Katarine Santana Barbosa is among the listed authors.
Why open-source 5G RAN matters for gaming and streaming
Commercial 5G radio equipment is expensive and closed. Open-source stacks lower the entry price, which is why universities, enterprise labs and private-network builders keep adopting them. The alphaXiv abstract itself describes OAI and srsRAN as increasingly relevant for industry and academic research, rapid prototyping and low-cost private 5G deployments.
Private networks are where gaming and streaming workloads get interesting. Stadiums, campuses, esports venues and studios can run their own radio networks and tune them for a single job. If a venue wants to stream live video from dozens of cameras or host a cloud gaming lounge, it needs to know which open-source stack holds up under that traffic. Until now, that answer lived in scattered single-testbed reports.
We have seen the operator side of this push already. A recent report on KT and Samsung testing an AI network at a baseball stadium showed how much attention venue networks now draw. Open-source RAN research feeds the same market from below, giving smaller players tooling that large vendors once guarded.
The three workloads: VoD, live streaming and cloud gaming
The study uses VoD to judge data rate, and LS and CG to judge latency-sensitive behavior. The split is deliberate. A video download rewards sustained throughput and tolerates buffering. A live stream or a game session does not tolerate delay, so the same radio link can look healthy on one test and poor on another.
| Workload | Abbreviation | Role in the study | What it stresses |
|---|---|---|---|
| Video on Demand | VoD | Data-rate evaluation | Sustained downlink throughput |
| Live Streaming | LS | Latency-sensitive evaluation | Delay and stability of a continuous feed |
| Cloud Gaming | CG | Latency-sensitive evaluation | Round-trip responsiveness under input |
| RRC setup | n/a | Signalling procedure check | Connection establishment behavior |
| Theoretical data rates | n/a | Compliance check | Gap between expected and delivered rate |
Source for the table: the alphaXiv abstract. The “what it stresses” column reflects standard networking logic about each workload, not a measurement from the paper.
What is confirmed and what is not
Separating fact from inference is the core of responsible coverage here. The available material confirms the study design and the author list. It does not show throughput values, latency values, hardware configurations, prices, a precise publication date or any on-record quotation from the researchers.
| Item | Status | Basis |
|---|---|---|
| Platforms compared: OAI and srsRAN | Confirmed | alphaXiv listing |
| Qualitative feature and flexibility review | Confirmed | alphaXiv listing |
| RRC setup, data-rate compliance, app workloads | Confirmed | alphaXiv listing |
| VoD, LS and CG as the three workloads | Confirmed | alphaXiv listing |
| Which platform performed better | Not shown | No results in available material |
| Exact throughput and latency values | Not shown | No results in available material |
| Hardware, costs, deployment dates | Not shown | No results in available material |
| Researcher quotations | Not shown | None on record |
Treat any social post or aggregator summary that names a “winner” with suspicion unless it links to figures from the paper itself. Two tests with different SDRs can flip a ranking, and the abstract says as much by calling out SDR variation as a gap in earlier work.
Why RRC setup belongs in a streaming study
RRC setup looks like plumbing, and it is. It is the signalling exchange that gets a device from idle to a working connection. If a RAN stack is slow or flaky at that step, every later measurement inherits the problem. A cloud gaming session that starts after a slow attach already feels worse, even if steady-state throughput is fine.
Including setup procedures also tells you about robustness. Open-source stacks differ in how they handle edge cases, and real UEs behave differently from simulators. The listing stresses real UEs and real applications, which suggests the authors wanted to avoid the clean-room numbers that flatter any stack.
The role of real user equipment
The abstract flags the number of real UEs as a variable earlier studies handled inconsistently. A single phone on a quiet cell tells you little about scheduling fairness. Several devices competing for resources is where a RAN scheduler shows its quality. Readers should look for how many UEs the full paper used before trusting any cross-platform comparison.
Theoretical data rates versus what a video stream needs
One of the study’s checks is compliance with theoretical data rates. That is a useful sanity test. Every 5G configuration has a ceiling set by bandwidth, modulation and antenna setup. A software stack that lands far below that ceiling wastes spectrum, and the cause could be the scheduler, the host CPU or the radio driver.
Video is the traffic that makes this check matter. Ericsson’s Mobility Report data, as collected in its 2025 short-form video analysis, states: “Video traffic accounted for approximately 50% of mobile network traffic, with downlink video reaching up to 60% in sampled European networks.” If half of what a network carries is video, a RAN that cannot approach its theoretical downlink rate is failing at its main job.
VoD is therefore the right data-rate probe. It is the dominant real-world payload, and it exposes throughput shortfalls without the confounding effect of tight latency budgets. The interesting question is how far each platform sits from the theoretical line, and whether the gap changes with the SDR and configuration.
Cloud gaming is the hard case for any RAN
Cloud gaming sends controller input up, renders a frame on a remote server, and streams the encoded video back. Every step adds delay, and the radio link sits in the middle of the loop. A RAN that adds jitter or occasional stalls will show up in the player’s hands immediately. That is why the study’s choice of CG as a latency-sensitive workload deserves attention.
Ericsson’s 2020 Mobility Report piece on gaming on the move put numbers on the bandwidth side: “Fast-paced cloud games with complex graphics require an average throughput of 15 Mbps, with peaks of 25 Mbps or more.” That figure is six years old, and codecs have moved on, but it shows the order of magnitude. Throughput alone is easy for a decent 5G cell. Holding steady latency at those rates is the hard part.
Gaming’s share of network traffic is small but growing. Ericsson’s 2020 to 2024 traffic trends analysis reports: “Mobile gaming’s share of total network traffic increased by 8% and reached approximately 1.5% in 2024.” A 1.5% share looks minor, yet gaming traffic is far more sensitive to delay than the video that makes up most of the load. Networks tuned for bulk throughput can still fail a gamer.
Academic work on this class of traffic already exists. A Penn State publication on end-to-end characterization of game streaming applications on mobile platforms shows researchers treat game streaming as its own measurement category. The OAI and srsRAN study extends that thinking down to the open-source radio stack.
Home network effects still apply
Even a perfect RAN cannot fix a congested home router. Players who stream games over broadband can cut latency spikes with queue management, as we showed in our bufferbloat fix for free cloud gaming. Over 5G, the radio scheduler plays the role the home router plays on fixed lines.
OAI and srsRAN in context: other testbeds and prior evaluations
OpenAirInterface publishes its RAN software through the OpenAirInterface RAN project page, and the stack appears in many research testbeds. One example is the arXiv paper titled X5G, an open, programmable, multi-vendor, end-to-end private 5G O-RAN testbed with NVIDIA ARC and OpenAirInterface. That title alone shows how OAI gets combined with other vendors’ components in research builds.
Such testbeds tend to answer one question about one configuration. The new study’s pitch is different. By holding the application workloads constant and comparing two platforms, it aims to say something transferable. The abstract points to the missing combinations of SDRs, RAN configurations, applications and UE counts as the reason earlier results do not line up.
For readers who follow open-source infrastructure generally, the pattern is familiar. We covered a similar dynamic when OpenVDDK appeared as an open replacement for a closed VMware tool. Open implementations arrive first, then independent comparisons decide which one teams trust.
Market impact: who cares about an open-source RAN comparison
The direct audience is small: radio researchers, private-network integrators and lab engineers choosing a stack. The indirect audience is bigger. Cloud gaming providers, venue operators and enterprise IT teams all want cheaper ways to guarantee low latency on a site they control. A credible comparison of free software stacks helps them budget a pilot.
Ericsson’s 2020 report on mobile cloud gaming showed operators already tying gaming to premium plans. It found that among 106 communications service providers with commercial 5G offerings, 22 had announced mobile cloud gaming services as a separate subscription or part of a premium 5G plan. Commercial operators chase that revenue with carrier-grade equipment, but private networks chase it with open-source stacks, and that is where the OAI versus srsRAN question bites.
Regulators also pay attention to measured quality. Pakistan’s regulator, for example, has been running field checks, as in our report on the PTA inspecting 900 mobile sites. Independent measurement culture is spreading, and open-source RAN comparisons feed it with reproducible methods.
How to read OAI versus srsRAN once the numbers are public
When full results circulate, resist the urge to scan for a single champion. A stack can lead on one workload and trail on another. The table below lists the questions worth asking for each dimension the study covers. None of the right-hand cells contain findings, since none are available.
| Dimension | Question to ask of the paper | Why it matters |
|---|---|---|
| Feature support | Which 5G features does each stack expose? | Missing features limit what a deployment can do |
| Deployment flexibility | How many setups does each stack support? | Flexible stacks suit more venues |
| RRC setup | How reliable is connection establishment? | Setup failures wreck later results |
| Data-rate compliance | How close is delivered rate to theory? | Shows efficiency of the stack |
| VoD behavior | Is throughput steady under load? | Video dominates real traffic |
| LS and CG latency | How much jitter appears under load? | Interactive apps fail on jitter first |
| Test conditions | Which SDRs and how many UEs were used? | Conditions can reorder rankings |
The last row is the one that decides whether a result generalizes. The authors themselves identify SDR and UE variation as missing from prior work, so a fair reading of their conclusions will hinge on how widely they varied those inputs.
Historical context: from single testbeds to side-by-side tests
Open-source cellular software began as a lab curiosity. Early projects proved that a general-purpose computer plus a radio front end could act as a base station. Over time, OAI and srsRAN matured into stacks that research groups trust for 5G work, and that maturity created demand for neutral comparisons.
The abstract describes the prior art as individual testbed evaluations, end-to-end studies and partial comparisons. Each is useful. None settles which platform to pick for a specific job. The new paper tries to fill that hole by combining a feature review with measured results on three workloads.
Cloud gaming’s rise adds pressure. Our look at Ericsson and Nokia Q3 2026 results shows how much money flows into carrier radio. Open-source alternatives sit at the opposite end of the price range, which is why their credibility matters.
Five predictions for open-source 5G RAN testing
These are analyst judgments, not findings from the paper.
- No single winner. Expect a split result, with each stack stronger on some workload or configuration. Mixed outcomes are the norm when platforms target different use cases.
- Cloud gaming becomes a standard benchmark. Once one paper includes it, others will copy the approach, because latency-sensitive tests expose problems that throughput tests hide.
- Test-condition disclosure becomes the headline. Readers will judge follow-up studies by how clearly they report SDRs, configurations and UE counts.
- Private-network vendors cite the results. Integrators selling open-source-based networks will quote whichever findings help them, so check the context of every citation.
- Replication attempts follow. With open code and commodity radios, other labs can rerun the tests. Differences between replications will teach as much as the original.
What gamers and streamers should take away
Most players will never touch an open-source RAN. The study still matters because it shows what separates a good wireless game stream from a bad one. Throughput is the easy part. Stable latency under load is the real test, and any network built to host cloud gaming should be judged on it.
If you are choosing a streaming service for a mobile or home setup, price still plays a big role. Our GeForce NOW cost comparison over 36 months helps with that side. For more platform coverage, browse the gaming section.
The takeaway: this paper is a design to watch, not a verdict to quote. Wait for the figures, check the test conditions, and treat any claim of a clear OAI or srsRAN victory as unproven until the full results say otherwise.
FAQ: OAI vs srsRAN and the 5G RAN study
Which platforms does the study compare?
It compares two open-source 5G RAN platforms, OpenAirInterface (OAI) and srsRAN, according to the alphaXiv listing.
Which platform performed better?
That is not shown in the available material. No throughput or latency values for either platform are confirmed, so no ranking can be stated.
What workloads does the study use?
Video on Demand for data-rate evaluation, plus Live Streaming and Cloud Gaming as latency-sensitive applications.
What else does the evaluation measure?
It covers radio resource control setup procedures and compliance with theoretical data rates, and it adds a qualitative review of features and deployment flexibility.
What gap in earlier research does the paper target?
The listing says earlier work lacked evaluations that varied Software-Defined Radios, RAN configurations, user applications and numbers of real UEs.
Does the study name hardware, prices or costs?
Not in the available material. Hardware configurations, prices and deployment dates remain unconfirmed.
Why does cloud gaming matter in a RAN test?
Cloud gaming reacts to delay and jitter more sharply than video playback does. A radio stack that looks fine on a throughput test can still deliver a poor game session.