Issue with srsRAN Project

[roskeys]

Dear developers.

Thank you for open source this great application. Currently I have setup the environment containing srsRAN + open5GS running with n78 20MHz.
But I met some issue in using NR-Scope even to detect the phone connecting to the srsRAN project base station. From the log, I can see messages like SIB 1 Decoded..
Afterwards, I see the logs below, and then no mather how I toggle the airplane mode of the phone, NR-Scope does not show any other logs over there indicating it detects a new UE.

Workers are initializing, skip sf_rount: 0, sfn: 446, slot: 9
srsran_dft_replan
RACH decoder initialized..

Here's my srsRAN configuration.

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

ru_sdr:
  device_driver: uhd                                              # The RF driver name.
  device_args: type=b200                           # Optionally pass arguments to the selected RF driver.
  srate: 23.04                                                    # RF sample rate might need to be adjusted according to selected bandwidth.
  otw_format: sc12
  tx_gain: 80                                                     # Transmit gain of the RF might need to adjusted to the given situation.
  rx_gain: 40                                                     # Receive gain of the RF might need to adjusted to the given situation.

cell_cfg:
  dl_arfcn: 628500                                                # ARFCN of the downlink carrier (center frequency).
  band: 78                                                        # The NR band.
  channel_bandwidth_MHz: 20                                       # Bandwith in MHz. Number of PRBs will be automatically derived.
  common_scs: 30                                                  # 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).
  pci: 1                                                          # Physical cell ID.

And for NR-Scope config.yaml

nof_usrp_dev: 1
usrp_setting_0:
  ssb_freq: 3421920000 # Set to the ssb frequency of the cell, could be obtained with the cell scan function
  rf_args: "type=b200" # For B210
  # rf_args: "clock=external,type=x300,serial=32B0F2F,master_clock_rate=200000000,sampling_rate=25000000" ## For TwinRX daughterboard
  # rf_args: "clock=external,type=x300,sampling_rate=23040000" ## For CBX daughterboard
  rx_gain: 30 # for x310 CBX, max rx gain is 31.5, for b210, it's around 80, for x310 TwinRX, max rx gain is 90
  min_rx_gain: 0
  max_rx_gain: 40
  srate_hz: 23040000 # the sampling rate of USRP, integer division of 200MHz for TwinRX, and 5G sampling rate for CBX: 11520000 or 23040000
  srsran_srate_hz: 23040000 # the sampling for real signal processing, should be in 5G sampling rate, multiple of 1.92 MHz. 
  nof_carriers: 1 # srsRAN rf setting, always set to be 1 for now. 
  nof_antennas: 1 # srsRAN rf setting, always set to be 1 for now.
  scs_index: 1 #(0: 15kHz, 1: 30kHz, ..., the u in standard)
  rf_log_level: "debug"
  nof_rnti_worker_groups: 16 # number of of threads for DCI decoding, each will divide the UEs into small groups
  nof_bwps: 1 # number of BWP of the cell
  nof_workers: 16 # using worker pool to asynchronously process the slot data
  cpu_affinity: false # pin the worker's thread into CPU or not.

[WanHaoRan]

Hello, thanks for trying our tool. In the NR-Scope config file, could you change the rx_gain to 75 and max_rx_gain to 76.5, which is near the B210 maximum rx gain. Also, did you use the GSPDO on both sides? If not, the NR-Scope might lose synchronization with the srsRAN during the session.

For the srsRAN cell, could you remove the "pdsch_hl_cfg.mcs_table = srsran_mcs_table_256qam;" and "pusch_hl_cfg.mcs_table = srsran_mcs_table_256qam;" in the dci_decoder.cc and make again? This is empirically set according to commercial cells, as this information is sometimes sent through encrypted RRCReconfiguration.

[roskeys]

Thank you for your suggestions. I’ve updated the rx_gain to 75 and max_rx_gain to 76.5 as advised, but unfortunately, the issue still persists.

Regarding GPSDO, I’ve configured both the srsRAN base station and NR-Scope to use the same external 10 MHz OCTO clock. However, the issue remains and some times it cannot even decode the SIB1 message.

With this setup, I’ve attempted to connect the UE to the base station several times. Only a small number of connections are successfully detected, and in most cases, NR-Scope is unable to detect new UEs joining the network. May I kindly ask if there might be any misconfiguration on my part?

Additionally, if I intend to connect a total of three phones to the network, could you please advise on the appropriate values to set for nof_rnti_worker_groups and nof_workers?

Lastly, would it be possible for you to share the srsRAN gNB base station version, the specific srsRAN commit, and the NR-Scope configuration used during the evaluation session in the paper? I would greatly appreciate the opportunity to test using the same setup.

[WanHaoRan]

Hey roskeys, thanks for your update and trying the code with the GPSDO. I've been trying to use the srsRAN today, and I faced the same issue -- the NR-Scope can decode the SIB 1, but the UE connections seem hard to decode. This code was initially developed and tested on srsRAN, we also demoed the code at Mobicom with srsRAN. And the code runs smoothly with the commercial cells nearby me using the main and fixed_rnti branches. Check the stdout stdout.txt and the csv file a.csv.

Three phones in total should be OK; you don't need a large number of workers and threads. nof_rnti_worker_groups can be 1 or 2, and nof_workers can be 4.

I will keep trying with the srsRAN until I figure it out. Right now, I am running both NR-Scope and the srsRAN on the same desktop machine, which could be a problem. I will try to run them at two separate machines and see if anything could be improved. I will update if I find anything new. Thanks!

[WanHaoRan]

Hey, sorry I provided the wrong information. I used the wrong SIM card and the phone was connecting to another base station...
Running both srsRAN and NR-Scope on the same PC is fine. Here are my config files for the NR-Scope and the srsCU and srsDU. I think it's easy to migrate to srsgNB with these config files.

config.yaml for nrscope:

usrp_setting_0:
  ssb_freq: 3744480000 # Set to the ssb frequency of the cell, could be obtained with the cell scan function
  rf_args: "type=x300,serial=30A4446,clock=external" # For B210
  # rf_args: "clock=external,type=x300,serial=32B0F2F,master_clock_rate=200000000,sampling_rate=25000000" ## For TwinRX daughterboard
  # rf_args: "clock=external,type=x300,sampling_rate=23040000" ## For CBX daughterboard
  rx_gain: 30 # for x310 CBX, max rx gain is 31.5, for b210, it's around 80, for x310 TwinRX, max rx gain is 90
  min_rx_gain: 0
  max_rx_gain: 31.5
  srate_hz: 23040000 # the sampling rate of USRP, integer division of 200MHz for TwinRX, and 5G sampling rate for CBX: 11520000 or 23040000
  srsran_srate_hz: 23040000 # the sampling for real signal processing, should be in 5G sampling rate, multiple of 1.92 MHz. 
  nof_carriers: 1 # srsRAN rf setting, always set to be 1 for now. 
  nof_antennas: 1 # srsRAN rf setting, always set to be 1 for now.
  scs_index: 1 #(0: 15kHz, 1: 30kHz, ..., the u in standard)
  rf_log_level: "debug"
  nof_rnti_worker_groups: 4 # number of of threads for DCI decoding, each will divide the UEs into small groups
  nof_bwps: 1 # number of BWP of the cell
  nof_workers: 4 # using worker pool to asynchronously process the slot data
  cpu_affinity: false # pin the worker's thread into CPU or not.
  use_gpsdo: false # gpsdo not required but recommended, as the software synchronization on a higher bandwidth cell has overflows and missed DCIs

  log_name: "a.csv"
  google_dataset_id: "ngscope5g_dci_log_wanhr"

log_config:
  local_log: true
  push_to_google: false
  google_service_account_credential: "/home/wanhr/Downloads/nsf-2223556-222187-02b924918c95.json"

config for srsDU:

f1ap:
  cu_cp_addr: 127.0.10.1
  bind_addr: 127.0.10.3
nru:
  bind_addr: 127.0.10.3

ru_sdr:
  device_driver: uhd
  device_args: type=b200,clock=external
  srate: 23.04
  tx_gain: 70
  rx_gain: 70
  clock: external

cell_cfg:
  dl_arfcn: 650000
  band: 78
  channel_bandwidth_MHz: 20
  common_scs: 30
  plmn: "00101"
  tac: 7
  pci: 1

log:
  filename: /tmp/du.log
  all_level: debug

pcap:
  mac_enable: true
  mac_filename: /tmp/du_mac.pcap
  f1ap_enable: true
  f1ap_filename: /tmp/du_f1ap.pcap
  f1u_enable: true
  f1u_filename: /tmp/du_f1u.pcap
  rlc_filename: /tmp/gnb_rlc.pcap       # Optional TEXT (tmp/gnb_rlc.pcap). Path for RLC PCAPs.
  rlc_rb_type: all                      # Optional TEXT. Sets the RLC PCAP RB type. Supported: [all, srb, drb].
  rlc_enable: true                     # Optional BOOLEAN (false). Enable/disable RLC packet capture. Supported: [false, true]. 

Config for srsCU:

# Example config for a locally deployed CU listening on the localhost interface for a DU connection

cu_cp:
  amf:
    addr: 127.0.0.20
    port: 38412
    bind_addr: 127.0.10.2
    supported_tracking_areas:
      - tac: 7
        plmn_list:
          - plmn: "00101"
            tai_slice_support_list:
              - sst: 1
  f1ap:
    bind_addr: 127.0.10.1

cu_up:
  nru:
    bind_addr: 127.0.10.1

log:
  filename: /tmp/cu.log
  all_level: debug

pcap:
  ngap_filename: /tmp/cu_ngap.pcap
  ngap_enable: true
  f1u_filename: /tmp/gnb_f1u.pcap      # Optional TEXT (/tmp/gnb_f1u.pcap). Path for F1-U (NRU) PCAPs. 
  f1u_enable: true                     # Optional BOOLEAN (false). Enable/disable F1-U (NRU) packet capture. Supported: [false, true].
  n3_filename: /tmp/gnb_n3.pcap         # Optional TEXT (/tmp/gnb_n3.pcap). Path for N3 PCAPs. 
  n3_enable: true                      # Optional BOOLEAN (false). Enable/disable N3 packet capture. Supported: [false, true].

For the DU, I tried it with both B210 and X310, both can work very well. Please check the branch "srsran" of NR-Scope to work with srsRAN, basically, it just comment the lines I commented before. Thanks!

Perhaps, the key is to use X310 as the NR-Scope SDR? I worked with b210 to decode the 622.85MHz commercial cell, but overall it may perform worse as it has a worse rx signal quality.

Here are the csv and stdout files for your reference. a.csv stdout.txt

[roskeys]

Hi @WanHaoRan thank you for your suggestions. I’ve updated my setup accordingly. I’m now running the srsRAN base station using a B210 SDR on a separate desktop, and NR-Scope using an X310 SDR with the srsran branch you recommended. Both devices are synchronized using the same 10 MHz OCXO frequency standard.

However, I’m still encountering a few issues with this setup:

1. NR-Scope frequently fails to detect and decode the SIB1 message reliably.
2. When multiple UEs attempt to connect to the base station, NR-Scope typically detects only one or two of them. Even with the external clock, it seems NR-Scope continues to struggle with reliably detecting the RACH process.
3. A significant number of DCIs are missing—where after RACH is detected. The overall success rate for DCI detection appears to be around 40%.

I’m currently using the srsRAN project with the release_24_10 tag for the base station. Could the version of the base station potentially be contributing to the issues I'm observing? If possible, could you kindly share the specific srsRAN commit or version used in your setup?

Moreover, I often face the following logs even I specified nof_rnti_worker_groups: 4 and nof_workers: 8

PDCCH: si-rnti=0xffff, crst_id=0, ss_type=common0, ncce=6, al=0, EPRE=-22.89, RSRP=-29.01, corr=0.244; nof_bits=37; crc=KO;
PDCCH: si-rnti=0xffff, crst_id=0, ss_type=common0, ncce=7, al=0, EPRE=-23.35, RSRP=-34.42, corr=0.078; nof_bits=37; crc=KO;
PDCCH: si-rnti=0xffff, crst_id=0, ss_type=common0, ncce=0, al=1, EPRE=-24.82, RSRP=-39.09, corr=0.037; nof_bits=37; crc=KO;
/root/NRScope/nrscope/src/libs/task_scheduler.cc:435: No available worker, if this constantly happens not in the intialstage (SIBs, RACH, DCI decoders initialization), please consider increasing the number of workers.

I’d really appreciate any further suggestions or insights you might have to help improve the detection.

[WanHaoRan]

Hey roskeys, I am using the srsRAN with commit id 9d5dd742a70e82c0813c34f57982f9507f1b6d5d. I think the performance issue (unable to reliably decode SIB, RACH, or DCIs) is mainly caused by the poor signal quality, as the signal and 5G protocol stack processing are relatively fixed. Changing the antenna helped me greatly increase the cell detection rate sometimes.

May I ask what antenna you are using? Is it an antenna with a male SMA port? What is the distance between srsRAN and NR-Scope SDRs?

As for the No available worker error, do you see this message constantly throughout the session? If it only shows up occasionally, it's fine. If not, you may increase the nof_workers and decrease the nof_rnti_worker_groups.

[roskeys]

Thank you again for the additional information. It appears we are using the same srsRAN version, so that should help in narrowing down potential causes.

Yes, I’m using an antenna with a male SMA connector, and the distance between the srsRAN base station and NR-Scope is very short, as shown in the image below:

Following your advice, I also updated the configuration by setting nof_rnti_worker_groups to 2 and nof_workers to 8. The host machine is equipped with an AMD Ryzen 9 5950X, so I believe hardware performance should not be an issue.

Unfortunately, the problems still persist. I’ve attached logs that correspond to the following failure scenarios:

1. NR-Scope fails to detect the SIB1 message. cannot_find_sib1.log
2. SIB1 is detected, but no new UEs are detected afterward. During test I toggled the airplane mode of the UE more than 10 times, but non of the connection is being detected. found_sib1_but_not_detecting_rach.log
3. A UE is detected and proceeds to RRC Setup, but no further UEs are detected after that point. It seems the framework crashes but not given any error information. stopped_after_rrc_setup.log
4. I also have some cases that the UE is detected, but there's a lot of DCIs are missing, the missing rate is about 40%. This is the best performing one I observed. NR-Scope-with-srsran-log.zip

[WanHaoRan]

Thanks for your update, and sorry for your inconvenience. I just tried to run the code again with the same setup. I tried with 3 different receiving antennas, and the SIB DCI decoding signal strength (RSRP) varies from -31 dBFS to 16 dBFS. PDCCH: si-rnti=0xffff, crst_id=0, ss_type=common0, ncce=0, al=2, EPRE=+16.00, RSRP=+16.00, corr=0.999; nof_bits=37; crc=OK;

From your "cannot_find_sib1.log", I found an entry PDCCH: si-rnti=0xffff, crst_id=0, ss_type=common0, ncce=3, al=0, EPRE=-32.09, RSRP=-34.73, corr=0.544; nof_bits=37; crc=KO;. Normally, the code will proceed to decode DCI when the correlation value is bigger than 0.5, so there could be a DCI for the SIB1 behind this entry, but the RSRP is too low, which could be the cause that the code fails to get the SIB right.

From your "found_sib1_but_not_detecting_rach.log", there is an entry: PDCCH: si-rnti=0xffff, crst_id=0, ss_type=common0, ncce=0, al=2, EPRE=+1.25, RSRP=+1.24, corr=0.998; nof_bits=37; crc=OK;. In this case, the RSRP is slightly better, but is still relatively low.

I am not sure about the cause of the third issue. Does this happen very often? I sometimes observe some errors, and they seem to be quite random.

For the DCI missing issue, I tried with a similar setup (x310 for NR-Scope and b210 for srsRAN), and the code seems to also fail to detect some of the DCIs. Then I realize there are other cells operating on the similar center frequencies. So I changed the center frequency of the srsRAN to around 2.5 GHz and it seems to be better, but I am not sure if that your case. Could you check your radio environment or just try a different center frequency for the srsRAN?

[roskeys]

Hi @WanHaoRan thank you for your update. I’m currently using 3427.5 MHz as the center frequency, which is a relatively clean band without any nearby base stations broadcasting. Additionally, the srsRAN base station and NR-Scope are positioned very close to each other as shown in the graph. I’ve also tested the setup by directly connecting the base station’s TX port to NR-Scope’s RX port, but unfortunately, the issue still persists. Given this, I believe the signal power should be sufficiently strong. Otherwise a signal amplifier will be required.

In the paper, I noticed that both automatic gain control (AGC) and resampling were mentioned. Could the issue potentially be related to the implementation of one of these components?

[WanHaoRan]

Hey @roskeys, connecting the TX port directly to the RX port is not recommended, as the voltage would be too high and could burn the circuits. If all these things aren't the root cause, then I don't know what it could be. I think the only thing I can suggest now is to try different hardware (SDRs) and different center frequencies. I am using an Intel i7-13700K CPU instead of an AMD one, but I think this shouldn't be the cause.

The random factors should be in the over-the-air signals instead of the signal processing after receiving, right? If the signal quality is the same across the subcarriers and time, and there is no other interference, the detection possibility across the frequency should be the same.

Yeah, I know they are very close to each other, but the low RSRP readings are what I saw from your failed logs. In the logs that NR-Scope successfully detects the RACH and UE DCIs, the RSRP readings are better -- 6 dBFS and 31 dBFS respectively.

The resampling would only be enabled if you are using twinRX as your daughterboard and set different sampling rates in the config file, which is not the case. As for AGC, I think it would not make your signal worse. You can disable the AGC by commenting srsran_ue_sync_nr_start_agc(&ue_sync_nr, radio_set_rx_gain_wrapper, rf_args.rx_gain, min_rx_gain, max_rx_gain); in radio_nr.cc.

For more debugging information, you can uncomment lines 326 to 343 in rach_decoder.cc to print the RSRP and correlation results. Also, you could add the same things to the dci_decoder.cc.

[roskeys]

Alright, thank you for the reminder — there is an attenuator between the TX and RX ports, so I believe the signal level should be within a reasonable range.

One last question: does NR-Scope support reading IQ samples from a file as input? If so, I would greatly appreciate it if you could share a sample recording and the srsRAN debug log used during your experiments. Having access to the same signal would be extremely helpful for reproducing and debugging the issue on my side.

[WanHaoRan]

Yeah, the RACH could be easy to miss, as for each new UE, this message only apprears once. In my srsRAN settings, the code also sometimes misses the RACH.

The 40% DCI miss rate is a more serious issue, could you add these debugging information into the code and try again?

Also, the issues you mentioned in your latest reply, do you mean all 4 issues? Or some of them?

[WanHaoRan]

Reading from IQ samples from a file was supported during the early development stage. I can try to implement this again in the coming week. After that, I will share the raw samples and codes to you.

[roskeys]

Sure, I'll add the debug informations and test again. These 4 issues I mentioned all happend duing my test.

I would appreciate a lot if you can develop reading IQ samples from a file. Thanks a lot.

[diespondency]

Hello! I have a very similar issue, and the probleem indeed seems to be the RSRP. Even on my most successful capture (where the SIB1 was decoded multiple times), it reverts back to searching DCI's.

On all my other attempts, the RSRP fluctuates between -16 to +17 dBFS:
PDCCH: si-rnti=0xffff, crst_id=0, ss_type=common0, ncce=0, al=0, EPRE=+17.67, RSRP=+17.14, corr=0.885; nof_bits=37; crc=KO;
PDCCH: si-rnti=0xffff, crst_id=0, ss_type=common0, ncce=1, al=0, EPRE=+17.69, RSRP=+17.53, corr=0.965; nof_bits=37; crc=KO;
PDCCH: si-rnti=0xffff, crst_id=0, ss_type=common0, ncce=2, al=0, EPRE=+17.66, RSRP=+17.33, corr=0.927; nof_bits=37; crc=KO;
PDCCH: si-rnti=0xffff, crst_id=0, ss_type=common0, ncce=3, al=0, EPRE=+17.39, RSRP=+17.16, corr=0.949; nof_bits=37; crc=KO;
PDCCH: si-rnti=0xffff, crst_id=0, ss_type=common0, ncce=4, al=0, EPRE=-1.46, RSRP=-7.61, corr=0.242; nof_bits=37; crc=KO;
PDCCH: si-rnti=0xffff, crst_id=0, ss_type=common0, ncce=5, al=0, EPRE=+0.61, RSRP=-4.59, corr=0.302; nof_bits=37; crc=KO;
PDCCH: si-rnti=0xffff, crst_id=0, ss_type=common0, ncce=6, al=0, EPRE=-3.33, RSRP=-8.37, corr=0.313; nof_bits=37; crc=KO;
PDCCH: si-rnti=0xffff, crst_id=0, ss_type=common0, ncce=7, al=0, EPRE=-1.18, RSRP=-10.57, corr=0.115; nof_bits=37; crc=KO;
PDCCH: si-rnti=0xffff, crst_id=0, ss_type=common0, ncce=0, al=1, EPRE=+17.68, RSRP=+13.91, corr=0.420; nof_bits=37; crc=KO;
PDCCH: si-rnti=0xffff, crst_id=0, ss_type=common0, ncce=2, al=1, EPRE=+17.53, RSRP=+12.34, corr=0.303; nof_bits=37; crc=KO;
PDCCH: si-rnti=0xffff, crst_id=0, ss_type=common0, ncce=4, al=1, EPRE=-0.30, RSRP=-8.68, corr=0.145; nof_bits=37; crc=KO;
PDCCH: si-rnti=0xffff, crst_id=0, ss_type=common0, ncce=6, al=1, EPRE=-2.12, RSRP=-16.84, corr=0.034; nof_bits=37; crc=KO;
PDCCH: si-rnti=0xffff, crst_id=0, ss_type=common0, ncce=0, al=2, EPRE=+17.60, RSRP=+9.08, corr=0.141; nof_bits=37; crc=KO;
PDCCH: si-rnti=0xffff, crst_id=0, ss_type=common0, ncce=4, al=2, EPRE=-1.12, RSRP=-16.01, corr=0.032; nof_bits=37; crc=KO;
PDCCH: si-rnti=0xffff, crst_id=0, ss_type=common0, ncce=0, al=3, EPRE=+14.65, RSRP=+9.57, corr=0.310; nof_bits=37; crc=KO;

My current setup is one computer running both the srsRAN Project gNB and NR-Scope on 2 USRP B210's.

Tomorrow I will be able to test on a complete private gNB, I hope to get better results there.

I think that reading IQ samples could be a great addition indeed! I'm looking forward to try that out.

2025-04-29_09:26:44.txt