-
Notifications
You must be signed in to change notification settings - Fork 140
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
No stable connection between GNB and UE #412
Comments
PDSCH seems to be ok, but there is a lot of CRC=KO reported in gnb log for PUSCH. Please try to tune the |
@pgawlowicz we have tried to change the time_adv_nsample several times between 20 and 300, but it didn't solve the problem. |
hmm, so if you go back to BW=10MHz it works and with 20MHz it does not work? |
@pgawlowicz in both cases it doesn't work, but with BW=10MHz we get RRC Connection for few seconds. With BW=20MHz we don't get an RRC connection at all. |
could you connect both gnb and ue USPRs to the same clock source? |
@pgawlowicz We are sadly In a room that is almost shielded by metal. We do not have the capabilities yet to sync them in this room. However we might be able to try connecting them to the Leo Bodnar clock this afternoon. What is confusing to us, is that the RRC connection was really stable in the mentioned case before #269 and now it is not anymore. |
Could you revert to the previous srsUE release (commit: fa56836) and check? |
Hi @dhiaboujebha, we had the same error yesterday. Did you updated the open5gs core network? If it is the case, check the config files, their structure have been changed. In particular the /etc/open5gs/nrf.yaml config has been added. We still have some connection issues, but fine-tuning the time_adv_nsamples parameter in the srsue_conf file allowed us to connect the two radios. The connection does not seem to be stable; we establish the PDU session, obtaining the UE IP address, but after a few seconds, the connection appears to be lost. |
@Rinelli96 Thanks for your comment. |
open5gs verions: 2.7.0 BR |
@pgawlowicz sorry for responding a bit late. |
The problem still persists. So we switched to another setup, where we deployed the hardware devices with an external clock. Also in the new one we are facing some problems #442 . |
I tried to analyze the logs of the gnb and the ue, so i've found out that the Scheduling Request failure that we get directly after the RRC Connected message is because of this: 2024-02-21T09:32:45.194542 [RRC ] [W] ue=0 "RRC Setup Procedure" timed out after 720ms Here are the gnb.log and the ue.log. ue_b200mini.conf.txt Any explanation? |
I see the rrc Setup message not being ACKed:
And no rrcSetupComplete is ever sent back to the UE. It is strange, because I can see the UE sending back positive CSI reports:
So, it seems that the UE is struggling with PUCCH Format 1. |
@frankist Thanks for your comment! working_setup_X310_B200mini.zip Open5GS Core: v2.7.0-86-g41d8934 Steps to get this result:
=> Then i updated the core to v2.7.0 and changed the USRP X310 with another one (i think it's an older device), and it worked. Trying 3* X310 with the same configuration (with adjusting the addr in the device_agr) but only one of them worked (the one with the address 192.168.11.2) and 2* B200mini and only one of them worked. Do you have any explanation for that? The connection now lasts between 10 seconds and ~ 1 minute. The next challenge is to make it stable and reliable. What can i change to get a stronger connection? |
Hey, your latest logs show a slightly different story. I see many underflows in the gnb log (e.g. |
We only have 4 Cores available, as you can see here in the specs: GNB: In the beginning we also thought our problems might be related to the limited physical resources. But we were told it is most likely not a problem.
Originally posted by @brendan-mcauliffe in #269 (comment) We neither could find any minimal resource requirements in the specs. Can you help us with the resource requirements? |
We are working on HW recommendations. Something similar to what we have for srsRAN-4G project: https://docs.srsran.com/projects/4g/en/latest/app_notes/source/hw_packs/source/index.html Regarding your setup, the 4 cores seem to be not enough. By default, we use 8 threads - please see the You might try to reduce BW and then add the following section to your gnb config:
But still, I am not sure whether this setup will work correctly. |
@pgawlowicz we upgraded the gNB computer to a robuster one with 8 cores. After that we got a better behavior of the setup, but it is still not reliable, because it takes some tries to establish a PDU session, but we always can get an RRC connection. Yesterday we installed a new network card on the gNB computer to connect the X310 with a 10Gbit to the computer. So now we use the full MTU size 8000. After some tests this doesn't seem to bring a big difference. |
@dhiaboujebha could you provide the output of the console trace from both the gnb and srsUE? You need to press You might be also interested in checking this discussion and it was a similar issue: #489 (comment) |
@pgawlowicz here are the traces of the gnb and the ue. |
hmm, could you try to reduce the TX gain of the gnb and try again? It seems that the signal received at UE is very good (snr>30dB). But the signal from UE at gnb is bad. Then you might try to increase srsUE tx_gain |
@pgawlowicz we tried to reduce the Tx gains of the gNB and we kept the Tx gains of the UE at the maximum. Here you can find the traces of the tests done. |
PDSCH SNR around 20dB looks good. Now you need to also improve uplink. I have seen that the rx_gain in gnb is already 30 and tx_gain in srsUE is 80. Maybe it is already too much and the link is saturated. Could you try to reduce both a bit and see if PUSCH SNR increases? |
@dhiaboujebha any update on this issue? |
@pgawlowicz sorry for the delay. We made some changes in the tx gains of ue and rx gains of gnb as you said. Here are the traces: |
Issue Description
When running the GNB and UE, an RRC connection is established, but it works sporadically. There is always no PDU session established, therefore no ip address is assigned to the UE. I get the same result with wireless and wired connection (using 30db cable attenuator).
Using previous versions of srsRAN_Project, srsRAN_4G and the same setup, we got a stable RRC connection and a PDU Session #269 .
Following the new instructions in the tutorial of srsRAN_Project (srate:23.04 and channel_bandwidth_Mhz: 20) the UE can not even find the GNB and build a connection.
All configuration files and logs are attached below.
Setup Details
srsRAN_Project Commit: 0b2702c
srsRAN_4G Commit: eea87b1d8
UE:
B200mini
Ubuntu 20.04
UHD 3.15.0.0
Intel(R) Core(TM) i7-7700T CPU @ 2.90GHz
Thread(s) per core: 1
Core(s) per socket: 4
Socket(s): 1
NUMA node(s): 1
GNB:
X310
Ubuntu 20.04
UHD 3.15.0.0
Intel(R) Core(TM) i7-7700T CPU @ 2.90GHz
Thread(s) per core: 1
Core(s) per socket: 4
Socket(s): 1
NUMA node(s): 1
Core:
Open5GS v2.6.6
Ubuntu 20.04
Intel(R) Core(TM) i5-3470 CPU @ 3.20GHz
Thread(s) per core: 1
Core(s) per socket: 4
Socket(s): 1
NUMA node(s): 1
Expected Behavior
PDU session establishment and ip address asignment like in the tutorial
Actual Behaviour
Core is starting and connecting to AMF, UE is starting and Connecting to the GNB, the connection lasts less than 1 second and then it directly gets lost, also there is no PDU session established. In the Core no registration of the UE can be seen.
Steps to reproduce the problem
As stated above, UE, GNB and Core run on seperate machines, the config files can be found below.
We are using the srsRAN_Project GNB and the srsRAN_4G UE.
ue.zip
core(2).zip
gnb.zip
Additional Information
[Any additional information, configuration or data that might be necessary to reproduce the issue]
The text was updated successfully, but these errors were encountered: