MME rejected gNB registration

[bocob]

Hi,

I am trying to integrate gNB with magma5g core, but I got the following in mme.log indicated AMF setup failure. the gNB ID, TAC were matched with the org8r provisioned. gNB is unmanaged. any insight what might be the problem?

No Common PLMN with gNB, generate_ng_setup_failure : -1

thanks.

[panyogesh]

@bocob : Can you please share the pcap of generated packet & output of /var/opt/magma/tmp/mme.conf

[bocob]

@panyogesh thanks for your reply. here are the logs.
logs.zip

[panyogesh]

15260-Comparision-Working-NonWorking.xlsx

[panyogesh]

Hi @bocob : Pcap shared looks interesting. It does not have a PLMN (MCC/MNC) during the setup Request. I am attaching an excel comparing Non-Working& Working pcap back to back.

We have tested 5G with simulators and real equipment and somehow all of them sends the PLMN in Initial Setup.

Can you please check and let us know little bit more about the tool you are using.

[bocob]

Hi @panyogesh , there was PLMN in the setup request message. please see the attached pic for your reference.

[panyogesh]

@bocob : The issue seems to be in Slice Differentiator configuration

{ MCC="001" ; MNC="01"; AMF_DEFAULT_SLICE_SERVICE_TYPE="1" ; AMF_DEFAULT_SLICE_DIFFERENTIATOR="ffffff"; }

If we make Slice Diffrentiator same (ffffff -> 000000) it should go through. Can you plese check and confirm.

[bocob]

Hi @panyogesh, thanks! I got much farther now. UE attached, but 5G core was not assigning IP due to " DNN is not Supported or not Subscribed, reject with a cause: 27". from wireshark log, "DNN: internet" was sent to 5gcore. UE subscriber has "internet". what else is missing? thanks.

[Radula76]

Ue might be requesting ipv4v6 APN?

[bocob]

the UE was requesting ipv4.

[panyogesh]

@bocob I have tested the configuration on new builds. Seems to be ok. Can you please share the pcap and mme.log

[panyogesh]

[bocob]

hi @panyogesh, after restarting the AGW, UE was able to attach and got IP. I see another issue that after inactivity timer expired, UE would not re-establish the session. 5gcore keeps release the session. have you seen this before?

[bocob]

logs-2023-07-19.zip

[panyogesh]

@bocob : I will check and update.

[panyogesh]

@bocob : By chance do you have the syslog for this failure. I am suspecting some pending cleanup.

[bocob]

@panyogesh here are the mme.log. the gNB is a real gNB. the gNB was working fine with other OEM 5g core.
mme.log.tar.gz

[Radula76]

There are a lot of cleanup issues on magma currently. when the Ue goes idle we need to make sure the proper 5G states are maintained. it is very different to LTE. some radio's allow you to extend the Ue idle timer which is helpful during testing. The core can receive a new session request and then tries to remove the old session information but it is in the wrong state, it will get into a loop. we can use the command "sudo config_stateless_agw.py flushall_redis" to clear redis and restart the core application, the Ue connection request will be rejected and a fresh session setup will work (as well as sctp reset).

[bocob]

@Radula76 thanks for your info. is that mean currently magma would not support session re-establishment? when would this fix(cleanup)? thanks.

[Radula76]

are you using magma 1.8 or the latest mater build (1.9)? 1.9 should be working in terms of idle to active session re-establishment.
the 5G states are different to LTE: http://howltestuffworks.blogspot.com/2019/09/5g-nr-ue-rrc-states-and-state.html
the 2nd half of the page explains the mobility management.
active to idle and back again should be working. if the gNB powers off its a bit harder for the AGW to clear out the active sessions. the idle sessions can be cleared out, but there are a few longer timers on the AGW to try and hold onto the active Ue session. if the Ue comes back with old session id's the core can get confused.

[bocob]

thanks @Radula76

I was using 1.8

[panyogesh]

1. Regarding the Slice-Differentiator Value set to 0 and NgSETUp not working as expected.
   <Response> As per the specs the default value of Slice Differentiator is 0xffff. If testing is done with SD=0, it needs to be set in
   AMF. It can be done via NMS or Swagger snapshots attached in Zip. Refer SD-0.zip.

2. Issue with Idle mode translation
   <Response> Logs for the Testcase similar to working idle mode is attached (Idle-Timeout-Logs)

3. The issue reported : I see another issue that after inactivity timer expired, UE would not re-establish the session. 5gcore keeps release the session. have you seen this before?
   <Response> The packet 35444 highlighted seems to be normal release. I guess once the Slice-Differentiator being 0 issue is resolved please share the pcaps, mme.log and syslog for checking the issue. The older logs send seems little out of sync.
   Idle-Timeout-Logs.zip
   SD-0.zip

[bocob]

@panyogesh since July 19 post, UE was able to do initial attach. SD was updated to "0"(otherwise UE was not able to do initial attach). as @Radula76 explained, ver 1.8 does not support RRC-idle to RRC-connect. any idea when is going to support gNB reset and 5gcore cleanup properly? thanks.

[panyogesh]

@bocob: Idle mode support is already part of 1.8 release. The tested logs with real equipment is attached in 1.8 release linkrelease link .
Under 5G-SA: Test-Logs.
Inside that in the real equipment section logs.

When compared to the pcaps you shared there seems to be 2 issues:

1. GNB is not sending context response (might be UE is not confirming)
2. Second service request is not accepted by AGW,

For issue 1: If you can compare the working & non-working pcap of packet 35601 on your setup and share the details it will be great.
Some UEs are slightly touchy about few IE.
For issue 2: It will be great if you can share the mme.log, syslog and pcap when the issue occurred.

For both I am attaching the comparison snapshot.
Uploading IDLE-MODE-FEATURE.zip…

[bocob]

hi @shashidhar-patil,
the problem that I was facing was not registration; initial registration was fine, but after UE went to RRC-inactive, UE failed to re-establish(resume) the session again, so RRC-inactive to RRC-active was failing.

[shashidhar-patil]

Hi @bocob,
We have reproduced the sevice request scenario. We have attached a complete pcap from registration flow to successful service request.
At packet number: 59 Ue moves to inactive state.
At packet number: 63 Ue sends a service request, and core successfully responds to this request. Here Ue moves from rrc-inactive to rrc-active state.

[bocob]

hi @shashidhar-patil, is there an upgrade that I can do to resolve my problem from rrc-inactive to rrc-active?

[panyogesh]

@bocob : We will update you shortly.

[mickymkumar]

Hi @bocob,

Please let us know if you still need upgrade steps for rrc-inactive to rrc-active or any other Support?

Thank you and regards,
Micky Kumar