search

srsran / srsRAN_Project

Open source O-RAN 5G CU/DU solution from Software Radio Systems (SRS) https://docs.srsran.com/projects/project
https://www.srsran.com
GNU Affero General Public License v3.0
520 stars 177 forks source link

srsUE cannot connect to srsGNB with USRP B210 #117

Closed LLiaang closed 8 months ago

LLiaang commented 1 year ago

Hello everyone!

Issue Description

I'm trying to connect srsue to the gnb using USRP B210, but there is something wrong and I don't know the reason.

I've followed the steps in the tutorial. I have built open5gs, srsRAN_Project and srsRAN_4G from sources. Each of them seems to work fine and apparently the gNB and open5gs connect with each other. However, the srsUE seems to fail in connecting.

I am also a little confused about the configuration of amf and upf in open5gs.

Details follow.

Setup Details

Network configuration:

  1. ue.conf: ue.conf.txt
  2. gnb.yaml: gnb.yaml.txt gnb
  3. amf.yaml: amf.yaml.txt amf
  4. upf.yaml: upf.yaml.txt upf
  5. open5gs: open5gs

Hardware:

  1. USRP B210 *2
  2. intel NUC i7-1165G7 with Ubuntu 20.04.6 LTS *1
  3. Legion Y9000P i9-12900H with Ubuntu 22.04.2 LTS *1

Operation System:

  1. open5gs and srsRAN_Project on Ubuntu 22.04.2 LTS
  2. srsRAN_4G on Ubuntu 20.04.6 LTS

library and driver versions:

  1. srsGNB: realease_23_5
  2. srsUE: https://github.com/srsran/srsRAN_4G/commit/fa56836b14dc6ad7ce0c3484a1944ebe2cdbe63b

Expected Behavior

I just want to let the srsUE connect to the GNB successfully, but it doesn't.

Actual Behaviour

GNB: gnb The terminal reported that: Failed to bind UDP socket to 10.32.164.176:2152. Address already in use. The IP '10.32.164.176' is my default route refer to issues#104, and I configured both AMF and bind_address with it(you can see it in "Setup Details"). I checked my ip with: sudo netstat -lnp | grep 2152, and I found that it's just the progress 'gnb' using the port 2152. After reading the code, I found that the port 2152 seems to be used by GTPU(/include/srsran/gtpu/gtpu/gtpu_config.h). GTPU'addr is configured in upf.yaml, but I didn't configured it with '10.32.164.176' but '10.11.0.7'. It's really confusing. I tried to kill thr progress 'gnb' but failed to kill it. So I wonder how to configure the IP of 'amf', 'bind_addr' in "gnb.yaml" and 'gtpu' in "upf.yaml" correctly?

UE: It seems that ue is searching for cell but cannot find. ue

Additional Information

The logs is here, but it seems that they have very little useful information. gnb.log: gnb.log gnb_ngap.pcap: gnb_ngap.pcap.txt ue.log: ue.log

Thanks!!

brendan-mcauliffe commented 1 year ago

Hi @2629788464,

First of all, try not to double up on issues and discussion posts for the same problem. We try to respond to issues as soon as we can. It is better to be patient instead of posting twice.

To connect the core and the gNB, you need to make sure that the ngap address in amf.yml and the gtpu address in upf.yml match the addr field in the gNB configuration. To see this illustrated clearly, take a look at the configuration section in this tutorial. This tutorial shows how to connect a COTS UE, but the core and gNB configuration steps are the same for your use case.

The bind_addr in the gNB config is simply a local IP that the gNB binds to for traffic from the AMF.

Double check how you have set the addresses in your amf.yml and upf.yml files, currently they are not correct. If you are still running into issues after changing them attach updated log files and I will take a look.

LLiaang commented 1 year ago

Hi @2629788464,

First of all, try not to double up on issues and discussion posts for the same problem. We try to respond to issues as soon as we can. It is better to be patient instead of posting twice.

To connect the core and the gNB, you need to make sure that the ngap address in amf.yml and the gtpu address in upf.yml match the addr field in the gNB configuration. To see this illustrated clearly, take a look at the configuration section in this tutorial. This tutorial shows how to connect a COTS UE, but the core and gNB configuration steps are the same for your use case.

The bind_addr in the gNB config is simply a local IP that the gNB binds to for traffic from the AMF.

Double check how you have set the addresses in your amf.yml and upf.yml files, currently they are not correct. If you are still running into issues after changing them attach updated log files and I will take a look.

I'm sorry for asking it twice! Thank you for your answer! I'll try again.

LLiaang commented 1 year ago

Hi @2629788464,

First of all, try not to double up on issues and discussion posts for the same problem. We try to respond to issues as soon as we can. It is better to be patient instead of posting twice.

To connect the core and the gNB, you need to make sure that the ngap address in amf.yml and the gtpu address in upf.yml match the addr field in the gNB configuration. To see this illustrated clearly, take a look at the configuration section in this tutorial. This tutorial shows how to connect a COTS UE, but the core and gNB configuration steps are the same for your use case.

The bind_addr in the gNB config is simply a local IP that the gNB binds to for traffic from the AMF.

Double check how you have set the addresses in your amf.yml and upf.yml files, currently they are not correct. If you are still running into issues after changing them attach updated log files and I will take a look.

Hi! @brendan-mcauliffe Thanks again for your advice! I have changed the IP address in my configuration files refer to this tutorial. I found that I didn't set the "tac" to "7" in "amf.yaml" before, it's a mistake. I think I should have set the configs correctly now. The print of the terminal is pretty much the same as before. Now I think I meet a new problem that the UE cannot sync according to ue.log. I wonder if I need a GPSDO, then I could set the "clock" and "sync" to "external" in "gnb.yaml" and avoid this problem(if it's a problem about "sync"). Sincerely hope you could give me some more advice!

Here are my configs: gnb.yaml: gnb.yaml.txt amf.yaml: amf.yaml.txt upf.yaml: upf.yaml.txt ue.config: ue_rf.conf.txt

Here are the logs: gnb: gnb.log amf: amf.log ue: ue.log

brendan-mcauliffe commented 1 year ago

The configs look fine.

From looking at the logs it is likely that the UE is unable to sync due to Lates and Underflows. This means that the UE machine is not allocating enough compute resources to the UE, and as a result the UE cannot sync to the gNB as it cannot process the info from gNB fast enough.

You should run the performance script found in the scripts folder of the srsRAN Project code base on both the UE and gNB machine. You can read more about configuring the CPU governor here.

I also suggest you set the log level to info, running in debug can be quite CPU intensive, and may not be helping. Do this for both the UE and gNB.

Once the above is done, try again. If you are still seeing issues let me know.

ismagom commented 1 year ago

Hi @2629788464 , it also seems there are some USB issues. Have you tried running the UHD benchmark in the UE computer with the same sampling rate and device arguments?

LLiaang commented 1 year ago

The configs look fine.

From looking at the logs it is likely that the UE is unable to sync due to Lates and Underflows. This means that the UE machine is not allocating enough compute resources to the UE, and as a result the UE cannot sync to the gNB as it cannot process the info from gNB fast enough.

You should run the performance script found in the scripts folder of the srsRAN Project code base on both the UE and gNB machine. You can read more about configuring the CPU governor here.

I also suggest you set the log level to info, running in debug can be quite CPU intensive, and may not be helping. Do this for both the UE and gNB.

Once the above is done, try again. If you are still seeing issues let me know.

Hi! @brendan-mcauliffe Thanks for your advice! I have run the performance script on both the UE and gNB machine and set the log level to "info". It works. But still there are something wrong. The UE' terminal could print "RRC connected", but cannot get to the next step and repeated "SYNC: detected out-of-sync... skipping slot ..." again and again. I check the "PRACH" in gNB'log and it seems that the PRACH didn't arrive early to the gNB The terminal's print are: gNB: gnb_1 gnb_2 UE: UE open5gs's website changed automaticly after I run the gNB(I think it's a good sign?): open5gs

The logs are here: gnb: gnb.log gnb_mac.pcap.txt gnb_ngap.pcap.txt open5gs: amf.log ue: ue.log ue_mac_nr.pcap.txt

LLiaang commented 1 year ago

Hi @2629788464 , it also seems there are some USB issues. Have you tried running the UHD benchmark in the UE computer with the same sampling rate and device arguments?

Hi! @ismagom Thanks for your advice! I tried running the UHD benchmark in the UE machine refer to this tutorial, with this command "sudo ./benchmark_rate --rx_rate 11.52e6 --tx_rate 11.52e6" and the print of terminal looks normal refer to the guide

dhiaboujebha commented 1 year ago

@2629788464 is your setup working now? If yes, can you please share the solution because i have the same problem?

LLiaang commented 1 year ago

@dhiaboujebha no, it doesn't work. This issue is still to be sloved.

dhiaboujebha commented 1 year ago

@dhiaboujebha no, it doesn't work. This issue is still to be sloved. Thank you for your fast response. Can you please let me know if you got any solution.

LLiaang commented 1 year ago

@dhiaboujebha no, it doesn't work. This issue is still to be sloved. Thank you for your fast response. Can you please let me know if you got any solution.

@dhiaboujebha Not any solution.

tilldroemmer commented 1 year ago

@2629788464 did you manage to get rid of the Failed to bind UDP socket?

LLiaang commented 1 year ago

@2629788464 did you manage to get rid of the Failed to bind UDP socket?

@tilldroemmer I did not, as you can see in the picture of July12's reply. Just the first run after booting my PC is fine. Anyway, I didn't run srsRAN_5G completely to let GNB connect to UE.

ismagom commented 1 year ago

There seems to be an issue with the unpacking of some message at the UE side: 

2023-07-12T03:08:40.886366 [ASN1   ] [E] [    0] unpack_bits: Buffer size limit was achieved
2023-07-12T03:08:40.886366 [ASN1   ] [E] [    0] unpack_bits: Buffer size limit was achieved
2023-07-12T03:08:40.886367 [ASN1   ] [E] [    0] unpack_bits: Buffer size limit was achieved
2023-07-12T03:08:40.886367 [ASN1   ] [E] [    0] unpack_bits: Buffer size limit was achieved
2023-07-12T03:08:40.886367 [ASN1   ] [E] [    0] [/home/nuc/workarea/srsRAN_4G/lib/src/asn1/rrc_nr.cc][9392] Decoding failure.
2023-07-12T03:08:40.886367 [ASN1   ] [E] [    0] [/home/nuc/workarea/srsRAN_4G/lib/src/asn1/rrc_nr.cc][9539] Decoding failure.
2023-07-12T03:08:40.886367 [ASN1   ] [E] [    0] [/home/nuc/workarea/srsRAN_4G/lib/src/asn1/rrc_nr.cc][9477] Decoding failure.
2023-07-12T03:08:40.886367 [ASN1   ] [E] [    0] [/home/nuc/workarea/srsRAN_4G/lib/src/asn1/rrc_nr.cc][9854] Decoding failure.
2023-07-12T03:08:40.886367 [ASN1   ] [E] [    0] [/home/nuc/workarea/srsRAN_4G/lib/src/asn1/rrc_nr.cc][9698] Decoding failure.
2023-07-12T03:08:40.886367 [ASN1   ] [E] [    0] [/home/nuc/workarea/srsRAN_4G/lib/src/asn1/rrc_nr.cc][9898] Decoding failure.
2023-07-12T03:08:40.886368 [RRC-NR ] [E] Failed to unpack DL-CCCH message (0 B)

Have you tried with the latest gNB release?