srsUE doesn't have PDU session when connecting to srsRAN gNB via ZMQ

[HaoxinSEU]

Hi community,

I'm trying to connect srsUE to srsRAN gNB via ZMQ. I'm using open5gs as the core network. I can successfully connect COTS UE to the network, but srsUE doesn't.

The trace of srsUE shows that there is no PDU session, and after a while the connection drops. I also observe that there is nothing in the SMF logs. Do you have any idea why this happens?

Here is the trace of srsUE and gNB:

root@srs-ue:/srsRAN_4G/build/srsue/src# ./srsue /opt/ue.conf 
Active RF plugins: libsrsran_rf_uhd.so libsrsran_rf_zmq.so
Inactive RF plugins: 
Reading configuration file /opt/ue.conf...

Built in Release mode using commit fa56836b1 on branch master.

Opening 1 channels in RF device=zmq with args=tx_port=tcp://127.0.0.1:2001,rx_port=tcp://127.0.0.1:2000,base_srate=11.52e6
Supported RF device list: UHD zmq file
CHx base_srate=11.52e6
Current sample rate is 1.92 MHz with a base rate of 11.52 MHz (x6 decimation)
CH0 rx_port=tcp://127.0.0.1:2000
CH0 tx_port=tcp://127.0.0.1:2001
Current sample rate is 11.52 MHz with a base rate of 11.52 MHz (x1 decimation)
Current sample rate is 11.52 MHz with a base rate of 11.52 MHz (x1 decimation)
Waiting PHY to initialize ... done!
Attaching UE...
Random Access Transmission: prach_occasion=0, preamble_index=0, ra-rnti=0x39, tti=334
Random Access Complete.     c-rnti=0x4601, ta=0
RRC Connected
Received RRC Release

root@srs-ue:/# gnb -c /opt/gnb.yaml 
Lower PHY in executor blocking mode.

--== srsRAN gNB (commit 374200dee) ==--

Connecting to AMF on 10.43.203.230:38412
Available radio types: uhd and zmq.
Cell pci=1, bw=10 MHz, dl_arfcn=368500 (n3), dl_freq=1842.5 MHz, dl_ssb_arfcn=368410, ul_freq=1747.5 MHz

==== gNodeB started ===
Type <t> to view trace

In open5gs, I add the SIM card via populate:

populate:
  enabled: true
  image:
    registry: docker.io
    repository: openverso/open5gs-dbctl
    tag: 0.10.2
    pullPolicy: IfNotPresent
  initCommands:
  # example of initCommands:
    - open5gs-dbctl add_ue_with_apn 001010123456730 5122250214c33e723a5dd523fc145fc0 981d464c7c52eb6e5036234984ad0bcf internet

And AMF logs:

11/06 11:07:19.467: [amf] INFO: gNB-N2 accepted[10.42.1.30]:54266 in ng-path module (../src/amf/ngap-sctp.c:113)
11/06 11:07:19.467: [amf] INFO: gNB-N2 accepted[10.42.1.30] in master_sm module (../src/amf/amf-sm.c:741)
11/06 11:07:19.467: [amf] INFO: [Added] Number of gNBs is now 1 (../src/amf/context.c:1178)
11/06 11:07:19.467: [amf] INFO: gNB-N2[10.42.1.30] max_num_of_ostreams : 30 (../src/amf/amf-sm.c:780)
11/06 11:07:30.867: [amf] INFO: InitialUEMessage (../src/amf/ngap-handler.c:372)
11/06 11:07:30.867: [amf] INFO: [Added] Number of gNB-UEs is now 1 (../src/amf/context.c:2502)
11/06 11:07:30.867: [amf] INFO:     RAN_UE_NGAP_ID[0] AMF_UE_NGAP_ID[2] TAC[1] CellID[0x930] (../src/amf/ngap-handler.c:533)
11/06 11:07:30.867: [amf] INFO: [suci-0-001-01-0000-0-0-0123456730] Unknown UE by SUCI (../src/amf/context.c:1776)
11/06 11:07:30.867: [amf] INFO: [Added] Number of AMF-UEs is now 1 (../src/amf/context.c:1563)
11/06 11:07:30.867: [gmm] INFO: Registration request (../src/amf/gmm-sm.c:985)
11/06 11:07:30.867: [gmm] INFO: [suci-0-001-01-0000-0-0-0123456730]    SUCI (../src/amf/gmm-handler.c:152)

My configurations files for gNB and srsUE are as below:
gnb_zmq.txt
ue_zmq.txt

Thanks for your help!

[brendan-mcauliffe]

Hi @HaoxinSEU your configs look fine. Have you tried enabling IP forwarding? You can follow the steps outlined here to do so.

[HaoxinSEU]

Hi,

Thanks for your reply! Actually when I use the COTS phone as UE, USRP as gNB SDR, it successfully connects over the air and gets the PDU session. So I guess the IP forwarding should be fine.

[HaoxinSEU]

Hello again,

For some more background information: I'm running both gNB and srsUE in one pod in a Kubernetes cluster. Is there any special configuration or step I need for this deployment?

Thanks!

[ninjab3s]

Hi,
regarding the missing PDU session. This can be caused by an APN mismatch in core or UE. Have you checked this?
Otherwise, I could imagine, since you are running in a container, that the interface the UE creates can be problematic as well. Can you rerun the experiment with running everything bare metal to see if your Kubernetes configuration is the problem? If the error persists on bare metal please provide logs of UE and gnb in debug.
Thanks!

[HaoxinSEU]

Hi,

Thanks for the information. After looking at the UE logs and its source code, we found the problem is the TAC list.

srsUE only supports one TAC, but in our open5gs AMF configuration, we have two TACs. As a result, srsUE cannot handle it correctly, and gets stuck.

Hope this information also helps others!