srsUE connection with srsRAN gNB fails on Msg3

[MarkusKluegel]

Hello,

I'm following the tutorial on connecting an srsRAN gNB with srsUE, but I keep getting stuck at the Random Access. The log files tell me that Msg3 is not received by the gNB, for whatever reason. I've tried numerous configurations (described below) but without success and I'm running out of ideas what the reason could be. At the beginning I was quite sure that it would be a timing or frequency offset issue (that the Msg3 does not hit the targeted PRB with sufficient accuracy) but I could more or less rule that out by now, as I have very low reported CFO and TA values. Anyhow, the gNB ceases to even see the signal from Msg3. Any help is welcome.

Regards,
Markus

---

Edit:
I'll provide a short summary of the solution here, as the discussion below became a little longer. In the end, there were two problems: (i) A power issue and (ii) a timing issue.
The power issue (i) is caused by the setup being connected over cable without attenuators (I have none spare). It required some thorough adaptation of TX and RX gains, ending with the values of

• X310 (gNB): TX Gain: 1, RX Gain: 15
• B210 (UE): TX Gain: 20, RX Gain: 20

Note the particularly low TX gains, which were the key "trick" - my working assumption is that there is a cross-coupling between the TX and RX chain through the cables. The impact of changing the gains can be observed on the SNR value reported in the gnb log file during PRACH attempt.
The timing issue (ii) is due to a misaligned timing on the B210, the solution for this is given in issue #805.

---

My Setup:
gNB on USRP x300 <--> UE on USRP b210
PC: Thinkstation p350 with 8x core i9 @ 3500 MHz and 32 GB RAM
Software: Ubuntu 22.04.3 LTS; UHD 4.5

• The PC is connected to both SDRs for convenience; I am aware that this can cause performance issues but am positive that this is not the reason, as I don't see any significant over/underflows and was able reproduce the same results on a two PC setup.
• gNB and UE are connected by cable
• gNB and UE are synchronized by a 10MHz and PPS signal
• I've carefully taken all steps to ensure PC performance (e.g., disabling CPU C/P states; setting the governor; adapting buffer sizes; running the srsran_performance script,... )
• I'm using the proposed 10 MHz FDD configuration in band 3, with some slight adaptations to connect to my core network (see attached)

gnb_x300_10MHz_FDD_band3.txt
ue_conf.txt

---

Result:

• The gNB registers at the core correctly and sends PSS/SSS
• The UE sees the gNB and decodes SIB1
• The UE starts RAP, which succeeds on Msg1&2
• However, Msg3 is not received by the gNB
• The UE tries RACH for the full configured 7 times, then it goes into IDLE mode

gnb_log.txt
ue_log.txt

---

Things I've tried so far:

• Changing the TX/RX gains (verified the output power with spectrum analyzer; input is not critical at this stage from my experience)
• Changing the frequency offset until it was in an acceptable range from the logs
• Playing with the time_alignment_calibration and time_adv_nsamples parameters --> no effect
• Verifying the performance with UHD tools
  • benchmark_rate --> successful
  • rx_samples_to_file, tx_samples_from_file --> successful
  • test_pps_input --> successful
• Changing between UHD 3.15 and UHD 4.5 --> no effect
• Changing the setup with an extra PC to rule out performance issues --> no effect
• Trying different synchronization sources for 10MHz/PPS --> no effect
  • In the attached config, I use the Ref & PPS output of x310 to synchronize the b210

[andrepuschmann]

Hey Markus,
your issue is a signal power issues - please note the very low snr of even the PRACH. It is very difficult to decode the PUSCH in such conditions.

2023-10-27T06:32:34.970118 [UL-PHY0 ] [I] [ 289.4] PRACH: rssi=+23.2dB detected_preambles=[{idx=0 ta=13.28us power=+1.6dB snr=1.6dB}] t=126.9us

You have to adjust the gain settings. Since you're using a X300 I suspect your Rx gains are too high. But definitely increase the Tx gain on the UE to e.g. 80. The B210 required high gains while the X300 rather low values. You need to play a bit around to find good values.

Hope that helps.

[MarkusKluegel]

Andre,

Thank you for the quick response. I reduced the rx gain and indeed got a short glimpse of RRC connected, which is a good sign. What is the SNR range that typically should be received?

I had played with the gains before as well but did not want to go into the 80's regime for TX because I don't have any attenuators in my setup. The tx gains are such that signal peaks reach ~-20dBm power level, which I verified with the spectrum analyzer (see attached images with black lines in max-hold mode). Can you give a short comment whether such signal powers are sufficient?

Another option could of course be that the RX path of the X300 is broken. I wanted to rule this out before, as I don't fully trust the device, but found no way to map the gNB to the second subdevice. Is there a way to do it?

Thanks & Regards,
Markus

Uplink RACH Measurement:

Downlink Spectrum:

[MarkusKluegel]

Andre,
I know that I'll need to set the subdevice B:0 (on channel "1" by default). But I see no way how to pass this through srsRAN down to the USRP. What is the required syntax for this? When I look it seems to me that the device arguments are forwarded to the USRP at this point in the usrp_make() function. However, channel or subdevice specifications are not forwarded, they are simply omitted. Can you verify this?
BR,
Markus

[andrepuschmann]

You're right. I didn't look at the code before but currently setting the tx/rx_subdev isn't exposed. What you can do is to use the key in the device args and then after making the USRP object you can use the UHD API to pass your string and select the device.

[MarkusKluegel]

Ok. So I added the following lines to radio_uhd_device.h:

---

index df77ab7be..1f7a7881c 100644
--- a/lib/radio/uhd/radio_uhd_device.h
+++ b/lib/radio/uhd/radio_uhd_device.h
@@ -150,10 +150,16 @@ public:
}
}
}
-
+
fmt::print("Making USRP object with args '{}'\n", device_addr.to_string());

- return safe_execution([this, &device_addr]() { usrp = uhd::usrp::multi_usrp::make(device_addr); });
+ return safe_execution([this, &device_addr]() {
+ usrp = uhd::usrp::multi_usrp::make(device_addr);
+ if (device_addr.has_key("subdev_spec")) {
+ usrp->set_tx_subdev_spec(device_addr.get("subdev_spec"));
+ usrp->set_rx_subdev_spec(device_addr.get("subdev_spec"));
+ }
+ });
}
bool is_connection_valid()
{

---

And now I can choose the second subdevice with an arguments string in the ru_sdr section such as:

device_args: type=x300,subdev_spec=B:0

However, the result is the same on the second subdevice, so my theory of a broken RX chain is unvalidated. In some cases the RACH proceeds and I get an RRC connect, however it seems that then the UE is not able to send an aknowledgement for a DL message, which in turn causes a connection release.

Honestly, I'm running out of ideas at this point. Any further thoughts what I could try?

[MarkusKluegel]

@andrepuschmann I played some more with the setup, including amplifiers and changing the gains a lot. I am now able to get a short RRC connect stably. However, now I observe behavior similar to the one reported in issue #805, i.e., the first scheduling request fails. A closer look at the logs shows that in particular, the ACK from UE to gNB is not received (e.g., TTI 228.6 in the gnb log), which makes it turn down the connection. Was there any useful conclusion on issue #805? Could you please give a short comment on the attached logs?

ue.log.txt
gnb.log.txt

[ismagom]

Hi @MarkusKluegel , see my response in #805 issue: srsran/srsRAN_4G#805 (comment)