no PDU Session establishment between GNB and UE

[tilldroemmer]

Issue Description

[Describe the issue in detail] When running the GNB and UE, an RRC connection is established, but no PDU session is established, therefore no ip address is assigned to the UE. I get the same result with wireless and wired connection, I also tried using a GPSDO, both didn't have any impact on the result.

I tried to confirm that the core is running as intended by using UERANSIM (logs and configs below): When running UERANSIM, GNB and UE start as intended and an PDU session is established for the UE. An ip address is assigned to the UE.

Setup Details

[Specify details of the test setup. This would help us reproduce the problem reliably] e.g. Network configuration, Operation System, Hardware, RF front-end, library and driver versions

• I ran the performance script.
• uhd_usrp_probe works on all used devices as it should

UE: B200mini Ubuntu 20.04 UHD 4.4 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 4.4 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 Ubuntu 20.04 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

Expected Behavior

[What you expect to happen] PDU session establishment and ip address asignment like in the tutorial here

Actual Behaviour

[What happens instead e.g. error message] Core is starting and connecting to AMF, UE is starting and Connecting to the GNB, but no PDU session is established. In the Core no registration of the UE can be seen. Logs, configs and traffic captured with wireshark below.

Steps to reproduce the problem

[Tell us how to reproduce this issue e.g. RF setup, application config files] As stated above, UE, GNB and Core run on seperate machines, the config files can be found below. I am using the srsRAN_Project GNB and the srsRAN_4G UE. core.zip gnb.zip ue.zip UERANSIM.zip

Additional Information

[Any additional information, configuration or data that might be necessary to reproduce the issue]

[brendan-mcauliffe]

Hi @tilldroemmer your gNB config is wrong. Have a look at the example config for the gNB here. Your cell_cfg should be configured like so:

  dl_arfcn: 368500                  # ARFCN of the downlink carrier (center frequency).
  band: 3                           # The NR band.
  channel_bandwidth_MHz: 10         # Bandwith in MHz. Number of PRBs will be automatically derived.
  common_scs: 15                    # Subcarrier spacing in kHz used for data.
  plmn: "00101"                     # PLMN broadcasted by the gNB.
  tac: 7                            # Tracking area code (needs to match the core configuration).
  pdcch:
    dedicated:
      ss2_type: common              # Search Space type, has to be set to common
      dci_format_0_1_and_1_1: false # Set correct DCI format (fallback)
  prach:
    prach_config_index: 1

Your gain values are also quite low for both the UE and gNB, you could try increasing them. Other than that your configuration looks to be OK. Check against the example configs, making sure to use above parameters for the gNB cell_cfg.

[tilldroemmer]

Hi @brendan-mcauliffe thank you for your fast response. I tried using a similar config you suggested before, but when running the gNB it shows the error: INI was not able to parse cell_cfg.pdcch.dedicated.++

Can you help me with this issue?

[herlesupreeth]

I tried using a similar config you suggested before, but when running the gNB it shows the error: INI was not able to parse cell_cfg.pdcch.dedicated.++

This indicates that you are using srsRAN_Project gNB from older release/commit. Please update to latest release, re-compile and give it a try.

[tilldroemmer]

I did git pull origin main and it seems to be up to date

[herlesupreeth]

In the logs attached above I see the following message in gNB log, which is not the latest commit in main branch.

2023-10-16T12:36:17.252123 [GNB ] [I] Built in Release mode using commit 56a771dfe on branch main

Dont forget to re-compile.

[tilldroemmer]

I totally forgot to re-compile. The config works now, still no PUD session, but I have a Problem with my PDU socket. I will try to fix this tomorrow

[brendan-mcauliffe]

@tilldroemmer can you let us know if you have rectified your issue so that we can close the issue? If you are still running into problems feel free to update this thread.

[tilldroemmer]

@brendan-mcauliffe I didn't manage to get rid of the Problem Failed to bind UDP socket

The result is the same as in the orignial Problem, no PDU session is established

[herlesupreeth]

@tilldroemmer That UDP socket error you get if there are multiple application trying to get hold of that port 2152. e.g. running 5GC on the same machine as gNB or running multiple instances of gNB etc

[tilldroemmer]

@herlesupreeth that is what I thought as well, but my Core runs on a separate physical machine and on my gnb machnine only one gnb is running. I get the same result after rebooting.

Im using two different interfaces, one for the connection to the USRP X310 and one for the basic internet connection.

[herlesupreeth]

Can you send me the output of the below command on that gNB machine??

sudo netstat -tupln | grep 2152

[tilldroemmer]

@herlesupreeth thank you for your help.

[herlesupreeth]

Looks like open5gs SMF is running. Looks like you would have to uninstall open5gs installed via apt/ppa.

[tilldroemmer]

thank you, this helped indeed. Sadly I still dont get a PDU Session establishment

[herlesupreeth]

Please attach the gNB and UE logs and I can take a look

[tilldroemmer]

ue2.log.txt gnb3.log.txt

@herlesupreeth thank you so much for your support

[herlesupreeth]

I see that you are using an old commit for srsUE. There was a fix in the recent commits pushed to srsRAN_4G repo. So I would suggest to pull latest changes for srsUE and re-compile and give it a try.

2023-10-30T11:00:30.872595 [UE     ] [I] Using binary srsue with arguments: ue_miniforx310_cable.conf 
2023-10-30T11:00:30.915746 [UE     ] [I] Built in Release mode using commit af4b9589b on branch master.

[tilldroemmer]

I got the new commit and got the following logs now new logs.zip

[herlesupreeth]

I believe you dont have this commit in srsUE - https://github.com/srsran/srsRAN_4G/commit/79e1230a651841b95bc1b62889a69a382d0daa2d . Ensure that you have that commit and re-compile

[tilldroemmer]

ok, i will try this. Sadly I can not try this before next Monday.

Thank you and have a great Week

[tilldroemmer]

Hi @herlesupreeth , I made sure to run the right commit, but I still got no PDU session. Do you have an idea what I can change?

newlog2.zip

[brendan-mcauliffe]

Hi @tilldroemmer can you try enabling IP-forwarding? This is outlined here in the Open5GS Docs.

[tilldroemmer]

Hi @brendan-mcauliffe, thank you for your response. IP-forwarding is enabled at the Core, I ran the commands again, but got the same output.

I'm currently trying to set a new computer for my gNB, I thought that maybe the computer resources are to limited. Do you have any other tips?

[brendan-mcauliffe]

@tilldroemmer, double-check that your core and UE configurations match. Normally you see this type of issue when there is a problem with the APN configuration, or how the UE is registered in the core. I would be surprised if it has to do with the available resources.

[tilldroemmer]

@brendan-mcauliffe ok, I will do this once again. Just to make sure, I will especially look for the following:

1. plmn/IMSI in online configurator and in the config files of the AMF and UPF same as in UE
2. Tac in the config files
3. key and opc in the online configuration
4. ngap and gtpu adresses in the core config files
5. use of the same apn in UE and Core

[herlesupreeth]

@tilldroemmer I took a look at the logs. Can you please set log level of UE to warning and see if that helps? I see in gNB the its not receiving RRCSetupComplete and Random Access Procedure is timing out.

Or it could be that you may have to adjust the timing advance since you are using two USRPs rather than ZMQ

[tilldroemmer]

I actually managed to establish a PDU Session. It seems like the problem was indeed somewhere in the configs. I will continue to change small things in the configs and will keep you updated in where the mistake was. The PDU session does not yet work reliable, but im confident, that the reliability will increase by tweaking the parameters. Thank you so much for your help.

Here are the configs of all Units, I hope it helps. I only changed the files attached. functional Setup.zip

[tilldroemmer]

I will close this issue, thank you all for the help

[pgawlowicz]

@bijancse please do not open multiple discussions on the same issue