ZMQ multi srsUE scenario stopped working !

[yassir63]

Issue on connecting multiple UEs — same as #758 (ZMQ, Open5GS) but solution doesn’t work on latest gNB

---

💬 Message:

Hi everyone,

I’m encountering kind of the same issue described in [#758 — “Issue on connecting multiple UEs”], originally discussed in August 2024, but the proposed solution there doesn’t solve it for me on the latest gNB build.

With the old gNB version (and its previous config format), I could easily attach up to 10 UEs simultaneously without any issues.
After updating to the latest gNB (commit 6a2f612, branch main) and migrating to the new configuration format (cu_cp, cu_up, ru_sdr), I can attach at most two UEs.
Any additional UEs remain stuck in repeated PRACH transmissions and never reach RRC setup — and sometimes only one connects intermittently.

Plus, If I connect only two ues, they connect with no problems but anything more doesn't work !

---

While deploying the scenario, we tried both running everything on one server or separating the Core and RAN part on two different servers to have enough ressources.

⚙️ Setup

•	Core: Open5GS (AMF at 10.10.3.200)
	•	gNB: srsRAN_Project (main branch, commit 6a2f612ba9)
	•	UEs: multiple srsUE instances (ZMQ-based)
	•	RF:

tx_port=tcp://10.10.3.231:2000
rx_port=tcp://10.10.3.232:2001
base_srate=23.04e6


	•	Environment: Kubernetes (UEs and gNB in separate pods sharing ZMQ sockets with multi-ue config found on the documentation) 

	•	Our deployment spans two physical servers in the cluster:
            •⁠  ⁠sopnode-f1 , each equipped with AMD EPYC 9374F CPUs and 192 GiB of RAM
            •⁠  ⁠sopnode-f3 server, featuring an Intel Xeon Platinum 8462Y+ processor and 512 GiB of RAM.

📄 Symptom

When launching more than two UEs, they show continuous PRACH activity and never complete attach:

Random Access Transmission: prach_occasion=0, preamble_index=0, ra-rnti=0x39, tti=174
Random Access Transmission: prach_occasion=0, preamble_index=0, ra-rnti=0x39, tti=334
Random Access Transmission: prach_occasion=0, preamble_index=0, ra-rnti=0x39, tti=494
...

The same setup, ports, and AMF configuration worked perfectly with the older gNB release (up to 10 UEs attached reliably).

⸻

✅ Old (working) gNB config

# This configuration file example shows how to configure the srsRAN Project gNB to allow srsUE to connect to it. 
# This specific example uses ZMQ in place of a USRP for the RF-frontend, and creates an FDD cell with 10 MHz bandwidth. 
# To run the srsRAN Project gNB with this config, use the following command: 
#   sudo ./gnb -c gnb_zmq.yaml

amf:
  addr: 10.10.3.200                  # The address or hostname of the AMF.
  bind_addr: 10.10.3.231             # A local IP that the gNB binds to for traffic from the AMF.

ru_sdr:
  device_driver: zmq                # The RF driver name.
  device_args: tx_port=tcp://10.10.3.231:2000,rx_port=tcp://10.10.3.232:2001,base_srate=23.04e6 # Optionally pass arguments to the selected RF driver.
  srate: 23.04                      # RF sample rate might need to be adjusted according to selected bandwidth.
  tx_gain: 75                       # Transmit gain of the RF might need to adjusted to the given situation.
  rx_gain: 75                       # Receive gain of the RF might need to adjusted to the given situation.

cell_cfg:
  dl_arfcn: 368500                  # ARFCN of the downlink carrier (center frequency).
  band: 3                           # The NR band.
  channel_bandwidth_MHz: 20         # Bandwith in MHz. Number of PRBs will be automatically derived.
  common_scs: 15                    # Subcarrier spacing in kHz used for data.
  plmn: "00101"                     # PLMN broadcasted by the gNB.
  tac: 1                            # Tracking area code (needs to match the core configuration).
  pdcch:
    common:
      ss0_index: 0                  # Set search space zero index to match srsUE capabilities
      coreset0_index: 12            # Set search CORESET Zero index to match srsUE capabilities
    dedicated:
      ss2_type: common              # Search Space type, has to be set to common
      dci_format_0_1_and_1_1: false # Set correct DCI format (fallback)
  prach:
    prach_config_index: 1           # Sets PRACH config to match what is expected by srsUE
    total_nof_ra_preambles: 63      # Sets number of available PRACH preambles

# log:
#   filename: /var/log/gnb.log            # Path of the log file.
#   all_level: info                   # Logging level applied to all layers.
#   hex_max_size: 0

# pcap:
#   mac_enable: false                 # Set to true to enable MAC-layer PCAPs.
#   mac_filename: /tmp/gnb_mac.pcap   # Path where the MAC PCAP is stored.
#   ngap_enable: false                # Set to true to enable NGAP PCAPs.
#   ngap_filename: /tmp/gnb_ngap.pcap # Path where the NGAP PCAP is stored.

slicing:
  - sst: 1
    sd: 000001
  - sst: 2
    sd: 000002

⸻

❌ New (failing) gNB config

cu_cp:
  amf:
    addr: 10.10.3.200
    port: 38412
    bind_addr: 10.10.3.231
    supported_tracking_areas:
      - tac: 1
        plmn_list:
          - plmn: "00101"
            tai_slice_support_list:
              - sst: 1
                sd: 000001
              - sst: 2
                sd: 000002

ru_sdr:
  device_driver: zmq                # The RF driver name.
  device_args: tx_port=tcp://10.10.3.231:2000,rx_port=tcp://10.10.3.232:2001,base_srate=23.04e6 # Optionally pass arguments to the selected RF driver.
  srate: 23.04                      # RF sample rate might need to be adjusted according to selected bandwidth.
  tx_gain: 75                       # Transmit gain of the RF might need to adjusted to the given situation.
  rx_gain: 75                       # Receive gain of the RF might need to adjusted to the given situation.

cell_cfg:
  dl_arfcn: 368500                  # ARFCN of the downlink carrier (center frequency).
  band: 3                           # The NR band.
  channel_bandwidth_MHz: 20         # Bandwith in MHz. Number of PRBs will be automatically derived.
  common_scs: 15                    # Subcarrier spacing in kHz used for data.
  plmn: "00101"                     # PLMN broadcasted by the gNB.
  tac: 1                            # Tracking area code (needs to match the core configuration).
  pdcch:
    common:
      ss0_index: 0                  # Set search space zero index to match srsUE capabilities
      coreset0_index: 12            # Set search CORESET Zero index to match srsUE capabilities
    dedicated:
      ss2_type: common              # Search Space type, has to be set to common
      dci_format_0_1_and_1_1: false # Set correct DCI format (fallback)
  prach:
    prach_config_index: 1           # Sets PRACH config to match what is expected by srsUE
    total_nof_ra_preambles: 64
    nof_ssb_per_ro: 1
    nof_cb_preambles_per_ssb: 64
  pdsch:
    mcs_table: qam64                # Sets PDSCH MCS to 64 QAM
  pusch:
    mcs_table: qam64     # Sets PUSCH MCS to 64 QAM
  slicing:
    -
      sst: 1
      sd: 000001
    -
      sst: 2
      sd: 000002         
log:
  filename: /tmp/gnb.log
  all_level: warning
  config_level: debug

metrics:
  enable_log: true
  autostart_stdout_metrics: true
  enable_json: true
  layers:
    enable_app_usage: true
    enable_e1ap: true
    enable_pdcp: true
    enable_cu_up_executor: true
    enable_sched: true
    enable_rlc: true            
    enable_mac: true            
    enable_executor: true
    enable_du_low: true
    enable_ru: true

pcap:
  mac_enable: false
  mac_filename: /tmp/gnb_mac.pcap
  ngap_enable: false
  ngap_filename: /tmp/gnb_ngap.pcap


remote_control:
  bind_addr: 0.0.0.0
  enabled: true
  port: 8001

You may also see the Dockerfile used to build the gNB which is ZMQ enabled :
Dockerfile.txt

---

In my case, I generate the ue_conf with the following script generate_ue_conf.py and handle the multi_ue scenario with the following script multi_ue_scenario.py giving the number of ues I would like to connect at once.

❓ Question

Has something changed in how the latest gNB handles PRACH or contention resolution when multiple UEs attempt access simultaneously over ZMQ?

The workaround suggested in #758 unfortunately doesn’t help in my case — the limit remains at two UEs, while the old gNB handled ten without issue.

Any insights or confirmation from others who have managed to connect more than two UEs on the latest main branch (ZMQ mode) would be greatly appreciated.

Thanks a lot!
Yassir

[Ziyad-Mabrouk]

Facing the same issue here :(
Any updates or suggestions on this?