Connection between UE and GNB with delay

[Leon1da]

Issue Description

I'm trying to connecting the UE and GNB via radio following the documentation and the connection seems to working fine!
I already solved the issue of unstuble connection by tuning the rx/tx gains parameters in both UE and GNB, following the recently opened issues respones. srsRAN_Project: #343
I tested the UE/GNB connection in my university lab using a channel emulator using increasing delay. After ~1us, I noticed that the connection started to be unstable again, so I opted to tuning again the tx/rx gains in both applications and also the timing advance of the UE according. srsRAN_4G: #805
Now, I would like to known how the timing_advance_nsamples parameter is related to the tx/rx gains and how the system manages the delays. Is there some upper bound on the communication delay that should be keep into account when the connection is estabilished ? What is the maximum delay that the system can support and for which it is supposed to work ?
Thank you.

Setup Details

I'm updated with the last release of both srsRAN_4G (UE) and srsRAN_Project (GNB)
Operating System: Ubuntu 22.04
SDRs: USRP B210

Expected Behavior

I suppose that until a certain delay (~100us) the radio connection should work fine.

Actual Behaviour

After a delay of about 2/3us UE and GNB cannot connect each other.

[pgawlowicz]

Hi,

the purpose of the timing_advance_nsamples parameter is to balance the offset between TX and RX paths at the UE. If there is such an offset, the DL and UL frame structures are not synchronized (i.e., they are shifted in time a bit). As a result, a PRACH preamble could arrive at gNB before the start of the reception window. This will result in incorrect TA estimation, which will be sent to UE in a RAR message. If the UE decodes the RAR, it will try to correct its timing by the incorrectly estimated TA value, which will make the situation even worse. But it might also happen that the UE is not able to decode RAR.

You need to start with some reasonable rx/tx gain configuration so that the gNB can detect the PRACH preamble, but then you need to tune timing_advance_nsamples to achieve a correct preamble detection with TA in the range of 2-10us.
Only then you can fine-tune rx/tx gains to maximize SNR values.

It should be possible to operate with a delay of up to 10s us, but this also depends on the PRACH configuration (format + ZCZ + CP).

Do you add the delay in both directions (i.e., DL and UL) or only one direction? Do you add a delay after the UE is connected or before the connection?

[Leon1da]

Hi @pgawlowicz, thank you for your support. Your explanation is very precise.
I have added the delay in both directions (DL and UL) before the connection.

Update: I navigated through the project code and found a formula to compute the time_adv_nsamples by interpolation as follows:

nsamples = uhd_default_tx_adv_samples + (cur_tx_srate * uhd_default_tx_adv_offset_sec)

where:

• uhd_default_tx_adv_samples = 98
• cur_tx_srate = 23.04*e6
• uhd_default_tx_adv_offset_sec = I assume it to be the total delay (in sec) that I'm introducing

As mentioned earlier, I used the resulting value nsamples as the time_adv_nsamples in the UE configuration file. This way, I successfully connected the UE and GNB (obtaining the UE IP address and TA = 4) considering a delay of 20 microseconds in each direction (40 microseconds total UL + DL delay). However, after such a delay value, the system stopped working (no connection).

Keep in mind that I only set the time_adv_nsamples value as above while the rx/tx gains remain the same. The noise value with this delay seems reasonable, according to the values obtained with less delay. What do you suggest for connecting UE/GNB with a higher delay? Do you think I should modify the code, or can I improve the results by fine-tuning the tx/rx gains or something else? Thank you for your time.

[pgawlowicz]

By default, the prach_config_index = 1 [1] in gnb config file, therefore the PRACH Format 0 is used. PRACH Format 0 has a guard period of 96us, so introducing the one-way delay of 96/2=48us should be possible. However, I have talked with our PHY expert, and he believes that half of it is more realistic.
You might try to check the impact of the prach.zero_correlation_zone in the gnb config file. By default, it is set to 0, and it should give you the best results. But you might also try values like 12, 13 or 14.

Could you clarify when the TA=4? Is it already with a 20us extra one-way delay, or is it the baseline scenario (without the extra delay)?
Could you share what is the final time_adv_nsamples value that you put into srsUE config?

Unfortunately, the srsUE supports only the PRACH format 0, so if you want to test different formats you need to use COTS phone or Amarisoft UE. Or add the support for PRACH format 1 in srsUE what should allow for 4-5x bigger delay.

[1] https://www.sharetechnote.com/html/5G/5G_RACH.html#Random_Access_Configuration

[Leon1da]

Good evening @pgawlowicz,

1. I'm trying to quantify the impact of prach.zero_correlation_zone with your values but the performance seems to be the same with differents levels of dalay. I will let you know if in some tests I will notice relevant differences.
2. TA=4 is obtained whenever the UE is connected to the GNB. In particular, using the formula that I mentioned in the previous comment, I successully connect the UE with the GNB with differents levels of delay (reported in table).
   In the following table, I reported the one-way delay (UL/DL), the total delay (UL+DL) and, the time_adv_nsamples used in the UE's configuration file (computed as above) with some notes. I hope that it could help you and the community for testing purposes.

LabTest_2024_01_31.xlsx

As you can see, the system seems to work even with higher delays (200/500/1000 us ...).
In that cases the level of snr in the UE is 23/24 and the level of pusch in the GNB is 25/30. I think they are reasonable, so I think that no fine-tuning of rx/tx gains is required. Can you confirm it ?

Thank you

[Lab1R531]

Hi @Leon1da, have you solved the issue?
I'm experiencing the same problem with higher delays, there are some updates related to different values for prach_config_index on UE side ? @pgawlowicz
I have read this publication https://arxiv.org/pdf/2106.15439.pdf concerning the Random Access Procedure on NTN and I believe that the high delays introduced by satellite comunication fall into this case.
Can you provide me some tips to solve this problem?

[pgawlowicz]

@Lab1R531, the long delays in NTN deployments require NTN extensions to the gnb. Those are already implemented.

To run in a GEO satellite scenario, you just need to apply this config on top of your default one: https://github.com/srsran/srsRAN_Project/blob/main/configs/geo_ntn.yml, i.e., sudo ./gnb -c config1.conf -c geo_ntn.yml

Note that the UE also has to be updated with the NTN extensions. Currently, srsUE does not support NTN, but we have tested with AmarisoftUE (with NTN extensions) and it works pretty well. In the GEO scenario, one just needs to emulate a long delay between UE and gNB. For the LEO scenario, a more advanced channel emulator is needed (changing delay and Doppler freq).

[Lab1R531]

Thank you for your answer @pgawlowicz !
The fact that your gNB version is already NTN is great news!
For my PhD in non-terrestrial communication protocols, I am studying 5G NTN and I would like to test the capabilities of gNB in srsRAN_Project. Can you suggest open source alternatives to your UE compatible with this gNB?
The only valid solutions I've found are OpenAirInterface's UE and yours in srsRAN_4G. The OAI code seems to be very chaotic so I would like to work on the 5G UE in srsRAN_4G to make it compatible with your NTN gNB. I know it could be a very burdensome job but I think it could have positive implications for the community if successful.
Do you have any suggestions for me to approach development? I read that the UE in srsRAN_4G has already been modified to make it 5G, please let me know what you think about this possible development and if you think that support from your side is possible to identify the necessary changes! Thank you