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
481 stars 163 forks source link

UE on usrp b210 not connecting to gNb on x310 #753

Open facundopedre opened 1 month ago

facundopedre commented 1 month ago

Issue Description

Hi. We are currently using srsRANProject as Core + gNb on an Ubuntu 22.04 PC with an USRP x310 and srsRAN4g as UE with a b210 on another one. We have carefully followed the steps on https://docs.srsran.com/projects/project/en/latest/tutorials/source/srsUE/source/index.html for over the air transmission, and have now even connected both USRPs via coaxial cable with -30db attenuators on the Tx ports, so there is no air interference. We have also tried using both two x310 and two b210 configurations, connected via coax, and have had no chance making the UE attach to the gNb. We have also downloaded the latest versions for both srsRANProject and srsRAN4G and the latest FPGAs for the USRPs. We are attaching our configurations as well as logs.

We don't have a GPSDO for synchronization available, but have tried to connect the UE sdr B210 to the "ref out" exported clock of the X310 sdr, with the same results as using internal clocks on both.

Setup Details

gNb: Ubuntu 22.04.4 LTS, 16 GB RAM, CPU i7 12700 usrp Ettus X310, fpga=39

gNb: Ubuntu 22.04.4 LTS, 16 GB RAM, CPU i7 12700 usrp Ettus B210

Expected Behavior

UE attaching to gNb and reachable by core.

Actual Behaviour

With sdr B210 in UE, we get this error repeatedly: Tx while waiting for EOB, timed out... ... Starting new burst... Trying other sample rates like in #732 has'nt worked.

Also, the gNb gives this error while starting, after setting up CU-UP and DU succesfully: Real-time failure in RF: Type=start-of-burst Source=tx Timestamp=4885080

Steps to reproduce the problem

The configuration files used are attached below.

Additional Information

Config files: gnb_x310_rf_fdd.yml.txt ue_rf.conf.txt open5gs.env.txt

Logs: logs_ue_1_8.log gnb_1_8.log gnb_mac.pcap.txt gnb_ngap.pcap.txt

Terminal outputs: gnb_terminal_output.txt ue_terminal_output.txt

pgawlowicz commented 1 month ago

Please set the cpu scaling governor to performance mode.

CFO seems to be very high:

2024-08-01T21:11:14.017966 [RRC-NR ] [I] Proc "Cell Selection" - Cell search found ARFCN=0 PCI=1 epre=-1.0 snr=+17.8 cfo=+5490.2 delay=+0.0  sfn=414 ssb_idx=0 hrf=n scs=15 ssb_offset=6 dmrs_typeA_pos=pos2 coreset0=12 ss0=0 barred=n intra_freq_reselection=n spare=0

so the ue cannot sync to the network. you might need to use an external clock for the usrps.

facundopedre commented 1 month ago

Hello, thanks for the input. We had already set the CPU governor to performance, using the command suggested in the documentation. Also, checking CPU usage using htop, the CPU doesn’t seem to be too stressed during the execution of either module.

Using the freq_offset parameter to fix the cfo manually, we did get the UE to attempt to connect, but after several prach attempts it seems to stop trying and hang while disconnected. We have attached the new logs as well as the output on the UE terminal below.

We do not have access to an external clock yet, but will try to get one to conduct further tests. Do you think it is absolutely necessary to have one anyway, or can it be compensated by configuring both ue and gnb appropiately? We have tried using the internal clock of the x310 as a reference for the b210 ue, but that doesn't seem to be recognized as a clock input when running said ue.

gnb.log gnb_x310_rf_fdd.yml.txt

ue_rf_06082024.conf.txt ue_terminal_output_06082024.txt ue_log_06082024.txt

pgawlowicz commented 1 month ago

seems that the gnb never receives the PRACH from srsUE. Could you try to tune srsUE txgain and gnb rx gain?