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, and have observed significant upper-bound constraints 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.

[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 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.

[ismagom]

Hi @rcbarke ,

Just a quick follow up on your questions that haven't been answered yet.

First of all, you are right in that srsUE is not the best tool for large scale simulations. Furthermore, the way you are running it with ZMQ will not allow you to scale up. ZMQ should be used as a single channel per cell-UE pair, that is connecting 1 cell and 1 UE instance. If you want to simulate multiple UE, each UE instance should emulate them. It is true in this tutorial we explain how to connect 3 UEs using ZMQ and a GNURadio broker, but that's already beyond what ZMQ is designed for. We are sorry if this created some confusion or too high of an expectation. We will add a disclaimer to that tutorial emphasizing the limitations of the setup.

If your goal is to simulate one gNB with multiple UEs, I would recommend to use Amarisoft UE Simulator. We use it on a daily basis to simulate 1000 UEs attached to our gNB with ZMQ, doing diverse channel models and traffic patterns. You will see most of the issues you mention disappear. If you do it, make sure you use the correct gNB configuration (see configs/ folder).

Digital twins is a very interesting topic. We have some partners who are successfully building digital-twin-style simulations using our software, but certainly they are not using ZMQ in the way you are using it. I would love to hear more about what you are trying to achieve and discuss how we can help. The optimal solution differs depending on your objectives. Please contact me at ismael@srs.io and we can arrange a discussion.

Couple more things:

• Path loss: you can't simulate the pathloss the way you are doing it. If you reduce the signal 20 dB, the amplitude level will be so small that quantization error will dominate (we use 16-bit integer processing in the receiver, sometimes 32-bit but that has limits). In a real-world receiver, you would typically have an LNA that amplifies the signal in such a way that thermal/interference dominates. If you want to simulate a single large cell with the UE far from the tower, you need to first attenuate the signal, then add the noise PSD based on the reciever NF and then amplify the combined signal + noise back again so that the amplitude is close to 1. However note that in a more realistic scenario the performance will be limited by interference. In that case, the added noise power would be a function of the distance to the neighbour cell.

• Frequency offset: you are right srsUE has strong performance limitations. You are simulating a speed of 345 km/h which is beyond what we designed the 5G receiver in srsUE. The 4G srsUE can support that, it is actually being used commercially in airplanes flying at higher speeds than that.

• Time offset: you need to be careful how you apply the time offset, the UE performs synchronization every SSB transmission, but it assumes the jumps in time are realistic in a real-world scenario.

• Power Scaling Issue: this only works with a real radio and is intended to adjust the amplitude of the signal to avoid clipping. For your usecase, you should use GNURadio to scale amplitudes.

Hope that helps

[rcbarke]

@ismagom @frankist

Hello Francisco and Ismael,

Thank you both for your thorough and detailed follow-up regarding our use of srsUE and srsGNB in a software-only environment. We truly appreciate the clarifications—especially as we explore digital-twin scenarios that stretch beyond srsUE’s original scope. Our goal thus far was to communicate our experiments clearly, test hypotheses, and pinpoint where constraints arise. I apologize if any of this came across as defensive; my intention was solely to reconcile our observations with documented functionality. This conversation has been extremely useful in that regard.

Below are some key takeaways from your recent messages:

1. ZMQ Usage and Scaling

   • We understand now that ZeroMQ was designed for a single cell–UE pair rather than multi-UE concurrency, which clarifies why our tutorial-based approach with multiple software UEs saturates ZMQ.
   • Thank you for noting your plan to add a disclaimer about the limitations of that tutorial so others avoid these same issues.

2. AmarisoftUE for Multi-UE

   • We appreciate the recommendation to switch to AmarisoftUE for large-scale simulations. It’s reassuring to know you routinely handle hundreds or thousands of UEs with srsGNB plus external simulators. We look forward to testing that approach and validating it in our digital-twin context.

3. Digital Twin Collaborations

• It’s great to hear you have partners successfully building digital-twin setups with srsRAN. We’d love to learn from their methods—particularly if they rely on advanced channel modeling or high-UE concurrency.

4. Path Loss & Power Scaling

• Your insights on amplitude scaling and integer quantization in srsUE are extremely valuable. We’ll shift to a more realistic path-loss model in future channel modeling endeavors.
• We also appreciate why setting Tx/Rx gains in the software config alone doesn’t achieve the desired effect. Moving that functionality into a dedicated GNU Radio block should help us avoid integer clipping and maintain a more accurate link budget.

5. Frequency & Time Offset

   • For clarification, 345 km/h was only an upper test boundary used in about 50 channel models. In live experiments, we have reduced this value to reduce PHY layer stress.
   • We see how sudden time offsets can make srsUE lose sync. We’ll keep them realistic for SSB-based synchronization.

6. Metric Accumulation & E2 Interface Latency

   • Thank you for highlighting that scheduling changes may be applied in under a second, and our delays might be from Grafana’s buffering rather than the scheduler itself.
   • Our resource management RL agent at the OSC RIC relies on metrics fed over E2. If srsGNB is aggregating these metrics before sending them, similar to Grafana’s UI, that can cause delays for real-time features like URLLC. We’ll dig deeper into logging at the DU level to confirm.

Moving Forward

• Collaboration: I discussed it with our lab, who would love to meet and discuss best practices for larger scale digital twins. I will send you an email to set it up. We can present our use case and work thus far, and would love to see a demo of srsRAN and Amarisoft integrated together. If commercial or alternative srsRAN builds apply here, we’d be keen to learn how concurrency or ZeroMQ constraints have been overcome.

• Adjustments: We will investigate replacing srsUE with AmarisoftUE for better scalability. Adding amplitude scaling in GNU Radio for more realistic path-loss emulation should be straight forward in this architecture. I’m highly curious to learn more about a 1 cell–1 UE pairing for ZMQ as you mentioned. The SRS+Amarisoft documentation we’ve seen is for a single UE

• Documentation: We’re grateful you’ll add disclaimers about srsUE’s software-only limitations. This will help other researchers set realistic expectations and choose the correct pipeline for their RAN experiments. I appreciate your willingness to address this; I’ve already seen multiple universities publish work intending for hundreds of UEs resulting with only 3–4 UEs, likely after hitting the same misunderstanding.

In closing, we’re grateful for your prompt and informative responses. The suggestions on how to adapt our setup are greatly appreciated. We value srsRAN’s openness and all your clarifications on better aligning it with our digital-twin research goals.

Thank you again for your support and insights.

Best,
Ryan
Clemson University
IS-WiN Laboratory