srsRAN and Digital Twin Emulation Constraints

[rcbarke]

Hello all,

I have been conducting O-RAN research for approximately ten months, with a specific focus on digital-twin-style emulation. This use case goes beyond traditional SDR-based lab setups, so I'd like to share some upper-bound constraints we've observed in srsRAN under these software-centric conditions.

We are currently in discussions with other researchers who assert that the commercial version of srsRAN can overcome many of these limitations. However, performance documentation on the commercial build appears sparse, and we remain skeptical that it fully addresses issues around radio/UE protocols—particularly given SRS's strong emphasis on SDR-based solutions.

For scaled digital-twin experiments, frameworks like OpenAirInterface often come up as a more suitable alternative, in part because its performance capabilities are well-documented and it was designed to accommodate modern mid-/high-band simulated scenarios. I’m interested in hearing SRS’s official stance on whether the commercial version can reliably handle the larger-scale or non-SDR-based constraints outlined below:

D. Workarounds and srsRAN PHY Layer Limitations
Although the overall srsRAN ecosystem provides a con-
venient 5G prototyping framework—particularly for SDR-
based, short-range experiments—the specific loop in our work
leverages srsGNB, srsUE, and ZeroMQ in a fully software-
driven setup, without any hardware SDR support. This usage
deviates from the originally intended approach and pushes
these components beyond their typical lightweight lab scenar-
ios. As a result, our investigations reveal several constraints
in srsUE’s PHY layer, the srsGNB E2 interface, and the
ZeroMQ transport that limit the viability of a purely software-
based digital twin for realistic O-RAN research. We highlight
key challenges below, focusing on scenarios where srsUE is
used as the simulated UE, rather than external third-party UEs
or SDR endpoints.

(1) PRACH Attach Delays
Simultaneous attachment can overwhelm ZeroMQ buffers
in srsGNB and cause crashes. To prevent this, each
srsUE delays its PRACH request by a random offset,
ensuring that only one attach attempt arrives at a time. A
lightweight script orchestrates up to 12 UEs in a staggered
manner. In effect, this brute-force approach resembles a
rudimentary collision-handling scheme and underscores
how srsUE does not provide a robust multi-UE contention
resolution in a software-only loop.

(2) Downlink-Only Scheduling
Because the E2 interface in srsGNB does not yet offer
stable per-UE uplink slicing (especially when srsUE is
used), our resource-allocation logic and RL-based schedul-
ing focus on downlink traffic only. While this design suf-
fices for downlink-centric use cases (e.g., video streaming,
digital signage), it does not represent the more stringent
uplink demands of URLLC or mMTC, which require
robust UL orchestration that the current software pipeline
cannot provide.

(3) Batching Active UEs
Even after the attachment phase, activating more than three
srsUE instances simultaneously often triggers throughput
collapse due to ZeroMQ saturation. We therefore limit
concurrency to sets of three “active” UEs at any given
time. The RL agent updates PRB allocations for that batch,
then cycles to the next group. While this strategy preserves
system stability in purely software-based scenarios, it
significantly reduces fidelity by artificially serializing UE
traffic.

(4) Limited Bandwidth & Duplexing
The srsUE code supports only certain FDD bandwidths
(5/10/15/20 MHz), excluding mid-band TDD deployments
(e.g., 3.5 GHz) that are dominant in modern 5G. Its
fixed 15 kHz subcarrier spacing (SCS) further constrains
throughput and per-UE PRB allocation. Wider channels
or advanced numerologies (e.g., 40–100 MHz, 30–60kHz
SCS) remain out of scope without a more robust UE
(e.g., AmarisoftUE) or hardware SDR solutions, lim-
iting software-only scenarios to narrowband, short-range
tests.

(5) Path Loss Constraints.
During our RL training experiments, srsUE became un-
stable when path loss values in GNU Radio exceeded 10–
20 dB, with most UEs failing to attach or disconnecting
quickly. Empirically, UEs operated most reliably around
10 dB—corresponding to distances of just a few centime-
ters (e.g., ≈ 4 cm at 10 dB in free space at 1.805 GHz). At
20 dB (≈ 13 cm), srsUE connected erratically and soon
dropped, while at or above 50 dB (≈ 4.2 m), all devices
failed to attach. These results highlight how the default
PHY-layer logic in the srsUE–srsGNB ZeroMQ pipeline
expects extremely short-range conditions. Larger path-loss
values, even on the order of a few meters, require extensive
customization or external amplification to maintain stable
connectivity.

(6) Power Scaling Issue
In further testing, we probed the I/Q sample power at the
gNB Tx and UE Rx ports. Despite raising nominal transmit
or receive gains in srsGNB/srsUE to extreme levels (e.g.,
105 dB, 1000 dB), measured magnitudes remained around
0.0 and 0.0093 in linear scale (≈ −20.3 dB). Periodic
spikes near 127 dB appear linked to buffer saturations
rather than real power changes. Consequently, adjusting
these software-configured gains has no meaningful effect
on the amplitude of transmitted waveforms, undermin-
ing attempts to emulate realistic link budgets or path-
loss margins in a software-only environment. Practical
workarounds include scaling samples manually (e.g., via
Multiply Const blocks in GNU Radio) or leveraging
hardware SDR pipelines where transmit/receive gains do
shape the I/Q signal.

(7) Fragile Multi-UE Scalability
While multiple srsUE instances can attach to one
srsGNB, purely software-driven concurrency remains un-
stable with more than three concurrent flows. ZeroMQ can
saturate and drop frames, leading to gNB crashes. Our
batching approach avoids immediate crashes but dimin-
ishes realism for large-scale O-RAN tests.

(8) Rudimentary E2 Interface & ASN1C Gaps
The E2 Service Node (E2SN) in srsGNB implements only
a partial subset of E2SM procedures. Its ASN1C code lacks
support for power control, HARQ reporting, or channel
estimation. Consequently, our RL agents must rely on
coarse KPI metrics, limiting the granularity of resource-
management strategies in a digital twin environment.

(9) Inconsistent UE Identification & Helper Scripts
By default, srsUE assigns local indices in the order
of successful PRACH attach, independent from the core
network ID. If multiple UEs attach nearly simultaneously,
collisions reorder or drop them. We mitigate this via a
custom script that sends brief traffic bursts in a known
sequence, matching E2SM IDs to the core IDs. Although
this unifies labeling across logs, it remains a manual
workaround to keep software-only multi-UE identification
consistent.

(10) Sensitivity to Complex Channels & ZMQ Overheads
Although srsUE and srsGNB handle modest AWGN
or single-tap fading, multi-tap or high-Doppler channels
often desynchronize the PHY. Even minor timing drift
(ϵ̸ = 1.0) at higher sample rates (e.g., 11.52 MSPS) can
break connectivity altogether. Moreover, ZeroMQ inflates
CPU load and buffering delays, undermining near-real-
time operation under heavier or more complex traffic. To
remain within practical limits:
• Taps: [0.85+0.25j, 0.4-0.1j, 0.2+0.1j] (reduced to miti-
gate QoS degradation).
• Noise Voltage: 0.01
• Frequency Offset: 0.00005 (96 m/s, constant velocity),
often lowered to 0.00000584 (≈ 40 km/h).
• Epsilon: 1.0

(11) Alternative Transport Protocols for Higher Bitrates
While ZeroMQ remains a convenient default in
srsUE–srsGNB loops, it often saturates under multi-
UE loads, causing latency spikes or outright crashes.
For advanced scenarios demanding higher throughput
and real-time concurrency, alternative protocols (e.g.,
gRPC, shared-memory pipelines, or other low-overhead
messaging) should be considered. These could better
sustain simultaneous flows and large data bursts,
mitigating ZeroMQ bottlenecks.

(12) Lack of Robust Uplink Slicing
Although srsGNB contains partial UL PRB-assignment
code, it is incomplete and often introduces multi-second
delays or system failures when paired with srsUE.
URLLC or IoT traffic thus cannot be orchestrated in real
time under the current implementation, undermining the
viability of truly dynamic uplink slicing in software-only
emulation.

Summary. In essence, the srsGNB and srsUE components
can provide a promising basis for lightweight 5G exper-
imentation—particularly when hardware SDRs or external
UEs are used for short-range tests. However, because our
project emphasizes a purely software-based workflow (i.e., the
srsUE–ZeroMQ–srsGNB pipeline) without SDR accelera-
tion, many of the internal constraints (e.g., narrow bandwidth,
minimal path-loss tolerance, limited concurrency) become far
more pronounced. As these limitations illustrate, the current
srsUE/srsGNB loop is not yet adequate for fully realistic,
large-scale, and time-critical O-RAN scenarios—especially
those requiring robust UL slicing, multi-UE concurrency, or
advanced slice coordination. Nevertheless, the openness and
modifiability of the srsRAN environment remain valuable
for prototyping AI-driven RAN features in controlled settings.
Researchers pursuing mid- to large-scale 5G/6G testbeds with
complex topologies and stronger uplink demands will likely
need complementary solutions (e.g., OpenAirInterface,
hardware-based testbeds) or significant custom extensions to
achieve higher fidelity and near-real-time performance.

Would appreciate any comments, feedback, or clarifications from the SRS team regarding whether a commercial variant significantly addresses these multi-UE, mid-/high-band, and path-loss constraints in software-only digital twin use cases.

Thank you!

[frankist]

It seems many things written here are either untrue, limitations of the old repository NR srsUE (!=srsRAN_project) which is not actively maintained, or related to the use of the zmq tool for something it was not intended for. Just so it is clear for everyone reading this post,

• srsGNB can handle more than 800 UEs per cell in real-time and with zmq (using third-party UE)
• srsGNB can handle all bandwidths (up to 100MHz), different numerologies, MIMO and so on all in real-time and zmq.
• srsGNB handles multiple simultaneous PRACHs with its RA mechanism in real-time and zmq. We test this every day.
• srsGNB supports long-range.
• I let others comment on some of the claims made in the original post that are more related to their area of expertise.

My suggestion about this text is to be more specific on where the limitations lie in the srsRAN ecosystem for digital-twin experimentations (namely the not-so-actively maintained srsUE or the zmq unsuitability for this kind of experiment), instead of saying srsRAN doesn't support X, which is untrue. srsRAN_project supports many of the things you said it didn't.

Regarding point (12) Lack of Robust Uplink Slicing, I am not aware of this issue in the scheduler. Can you open an issue with logs?

[rcbarke]

It seems many things written here are either untrue, limitations of the old repository NR srsUE (!=srsRAN_project) which is not actively maintained, or related to the use of the zmq tool for something it was not intended for. Just so it is clear for everyone reading this post,

• srsGNB can handle more than 800 UEs per cell in real-time and with zmq (using third-party UE)

• srsGNB can handle all bandwidths (up to 100MHz), different numerologies, MIMO and so on all in real-time and zmq.

• srsGNB handles multiple simultaneous PRACHs with its RA mechanism in real-time and zmq. We test this every day.

• srsGNB supports long-range.

• I let others comment on some of the claims made in the original post that are more related to their area of expertise.

My suggestion about this text is to be more specific on where the limitations lie in the srsRAN ecosystem for digital-twin experimentations (namely the not-so-actively maintained srsUE or the zmq unsuitability for this kind of experiment), instead of saying srsRAN doesn't support X, which is untrue. srsRAN_project supports many of the things you said it didn't.

Regarding point (12) Lack of Robust Uplink Slicing, I am not aware of this issue in the scheduler. Can you open an issue with logs?

Certainly, and thank you for the insights here. The predominant limitations we are experiencing are specifically regarding scenarios with simulated UE emulation, particularly, when leveraging srsUE. I pulled this section of text out of a larger text which makes this very apparent, though I will take another pass at this section to ensure the generalized srsRAN references are more specific.

I believe the uplink slicing issue is occurring due to the limited transport layer buffer in this architecture. We do observe the PRB changes are applied, though there is a significant amount of time elapsed between the control message posting on the E2 interface and the changes being observed via Grafana.

The software architecture leveraged is Open5GS 5GC -> OSC RIC -> srsGNB -> gnuradio -> srsUE

The goal of this exercise was to establish a simulated ORAN environment. srsUE was used since it is the simulated UE referenced across the vast majority of tutorials on the srsRAN project page, including the ORAN tutorial. If it is truly not being actively maintained, I'd recommend it be removed from these tutorials.

We explored the performance limitations of this specific architecture after multiple researchers ran into the same problem while following the guides.

We note that moving the RU layer to SDRs and physical UEs greatly improves the performance of srsGNB, removing all of these limitations. It is specifically when srsUE is leveraged where these issues occur as you stated.

[frankist]

I believe the uplink slicing issue is occurring due to the limited transport layer buffer in this architecture. We do observe the PRB changes are applied, though there is a significant amount of time elapsed between the control message posting on the E2 interface and the changes being observed via Grafana.

Are you sure that the delay is not on the metric accumulation + the grafana buffering? I would suggest having a look at the latency since the control message enters the DU and when it gets applied in the scheduler output. You will see that it is way lower than 1sec.

If it is truly not being actively maintained, I'd recommend it be removed from these tutorials.

I disagree. It is a useful opensource tool for small-scale experiments. I would suggest that you would consider other people's use-cases.