Session getting instantly released when using real gNB and UE (Semantic error in the QoS operation)

Q/A
#1

Hello,
We are using free5gc (built from sources) and gtp5g latest versions (4.0.1 & 0.9.14).
UPF is instantiated in a different VM from the core. (Ubuntu 20 for UPF, Ubuntu 22 for core)
When using UERANSIM everything works as expected.
However when using real equipment, while gNB successfully connects to the AMF and while there is no reachability error between the gNB and the core or the upf, the UE trying to register, always gets its session released.
As you can see from the logs, the SMF assigns an IP, and the UPF getting prepared for the tunnel. After that a PFCP session modification request is applied and the session gets released.
There is no error indication from the core side, just a pcfp modification request that releases the session. gNB states in one of the NGAP messages “Semantic error in the QoS operation”. We believe this is related to https://github.com/free5gc/free5gc/issues/627 which was supposed to be solved in v3.4.5.
The UE still retries to establish a session but its the same all over again.
I have tried with qos and sequence number settings set to all combinations of 0/1 (gtp5g).
I have used amarisoft, srsRAN and OpenAir for gNB and Huawei P40 pro 5G, Oneplus nord N10 5G and OPPO Find X5 pro COTS UEs (and some more).
The following logs were generated using amarisoft gnb and OPPO UE
I attach the logs and pcaps of UPF and core and the logs of the amarisoft gnb.

Thanks in advance!

Logs.zip (210.9 KB)

#11

I have identified the root cause of the issue — it lies within the PCC rule processing procedure.
I’m working on a fix and will apply it as soon as possible. However, since it involves the ULCL (Uplink Classifier) feature, it requires additional consideration and may take some time.
I will provide an update here once the fix is completed.

#2

Hi,

Thank you for the detailed post and for providing the logs and pcap file.

image
image1783×151 108 KB

In packet 534 of free5gc.pcap, the UplinkNASTransport message is clearly identified by Wireshark as an Authentication failure.

The error indicates that there is a synchronization problem with the security context between the UE and AMF. The ngKSI already in use message means the UE tried to use a Key Set Identifier (KSI) that the AMF considers to be already active from a previous session. This causes the AMF to reject the authentication attempt outright.

Authentication is a mandatory first step for the UE to register on the network. Since the authentication fails, the AMF rejects the registration, and the entire procedure is aborted, leading to the immediate release of the session.

Here are a few things you could try:

  • Reboot the UE to clear the UE’s security context
  • Clear the subscriber data in free5GC DB

Hope this helps you resolve the issue.

#3

Hello and thanks for your answer.
While this might have happened at some point where the UE tried to reconnect after many session releases, it is not the issue. However we did try your solution with the same result.
As you can see from the packets and the logs, the authentication stage is successfully passed mutliple times. Even the PDU session is established from the core side (SMF assigns an IP and the smContext is set up).
There is a PFCP message to modify the PDU session where it gets released / deleted. Reviewing the NAS over NGAP messages there is the “Semantic error in the QoS operation” which probably inititates the session release.
The UE reports “connecting…”, never receiving the SMF provisioned IP, the signal bars are full, but there’s no 5G icon showing (the case where you are accepted into the network but not yet have data connection / IP).
Do we need to configure any PCC rule in PCF? It seems like the UE doesnt like a QoS setting and rejects the Session Establishment. We only have default rules in the DB and have tried with and without flow rules, while charging mode is offline.

#4

We have found an illegal QFI value that probably causes the session release. There is a 2nd QoS rule on the NAS Downlink message.

Protocol discriminator = 0x7e (5GS Mobility Management)
Security header = 0x2 (Integrity protected and ciphered)
Auth code = 0x28e7e3b8
Sequence number = 0x03
Protocol discriminator = 0x7e (5GS Mobility Management)
Security header = 0x0 (Plain 5GS NAS message, not security protected)
Message type = 0x68 (DL NAS transport)
Payload container type = 1 (N1 SM information)
Payload container:
Protocol discriminator = 0x2e (5GS Session Management)
PDU session identity = 1
Procedure transaction identity = 57
Message type = 0xc2 (PDU session establishment accept)
Selected PDU session type = 0x1 (IPv4)
Selected SSC mode = 0x1 (1)
Authorized QoS rules:
QoS rule 1:
QoS rule identifier = 1
Rule operation code = 1 (create new QoS rule)
DQR = 1 (the QoS rule is the default QoS rule)
Number of packet filters = 1
Packet filter identifier = 1
Packet filter direction = 3 (bidirectional)
Match-all
QoS rule precedence = 255
QFI = 1
QoS rule 2:
QoS rule identifier = 2
Rule operation code = 1 (create new QoS rule)
DQR = 0 (the QoS rule is not the default QoS rule)
Number of packet filters = 1
Packet filter identifier = 1
Packet filter direction = 3 (bidirectional)
Match-all
QoS rule precedence = 255
QFI = 0
Session AMBR:
Session-AMBR for downlink = 1000 Mbps
Session-AMBR for uplink = 1000 Mbps
PDU address:
SI6LLA = 0
PDU session type = 1 (IPv4)
IPv4 = 10.60.0.6
S-NSSAI:
Length of S-NSSAI contents = 4 (SST and SD)
SST = 0x01
SD = 0x00000a
Authorized QoS flow descriptions:
QoS flow description 1:
QFI = 1
Operation code = 1 (create new QoS flow description)
E = 1 (parameters list is included)
Number of parameters = 1
5QI = 9
Extended protocol configuration options:
Ext = 1
Configuration protocol = 0
Protocol ID = 0x000d (DNS Server IPv4 Address)
Data = 8.8.8.8
Protocol ID = 0x0010 (IPv4 Link MTU)
Data = 1400
DNN = “internet”
PDU session ID = 1

After that UL NAS informs that the UE rejects the settings probably because QFI = 0 is illegal (semantically incorrect).

Protocol discriminator = 0x7e (5GS Mobility Management)
Security header = 0x2 (Integrity protected and ciphered)
Auth code = 0xb65f69e6
Sequence number = 0x03
Protocol discriminator = 0x7e (5GS Mobility Management)
Security header = 0x0 (Plain 5GS NAS message, not security protected)
Message type = 0x67 (UL NAS transport)
Payload container type = 1 (N1 SM information)
Payload container:
Protocol discriminator = 0x2e (5GS Session Management)
PDU session identity = 1
Procedure transaction identity = 58
Message type = 0xd1 (PDU session release request)
5GSM cause = 0x53 (Semantic error in the QoS operation)
PDU session ID = 1

#5

Hi, I’ve tried to create two QoS rule in one PDU session. But I didn’t get into this problem.

Maybe I need your webconsole configuration and the full pcap files to find what’s wrong at here.

Thanks a lot!

#6

Hello,
We do not attempt to create any additional rules in the PDU session. It should have been only the default rule with QFI=1.
I remind you, we are using commercial UEs. UERANSIM works fine.
There was the suspicion that the UE requests IMS too and that we would need to handle this too, but the only dnn requested in the logs is “internet”.
There is no configured pcc rule in the pcf.yaml.
I attach 2 screenshots of the current webui config.
If the pcap files of my first post are not enough (generated by the run.sh script), tell me exactly what you need.

Thanks in advance!

screen1
screen11122×652 21.9 KB
screen2
screen21131×785 19.1 KB

#7

Update:
By commenting out the line of code that appends new QFIs, the problem disappears and COTS UEs successfully establish sessions and have internet connectivity. However this is a dirty workaround since now only the default QFI will spawn, thus limiting the QoS capabilities.
The illegal QFI=0 also appears when using UERANSIM, but since its a simulator, it doesnt complain and probably ignores the QoS settings altogether.
I attach 2 pcaps on the N2 interface of gNB (UERANSIM), one for each case.
nas_qfi_off.pcap (3.9 KB) nas_qfi_on.pcap (3.0 KB)

We still don’t understand how does a 2nd rule appears.
I also provide a part of the logs during the process for PCF and SMF:
2025-07-24T14:54:24.434993028Z [INFO][SMF][PduSess][pdu_session_id:1][supi:imsi-001010000000001] Allocated PDUAdress[10.60.0.1]
2025-07-24T14:54:24.455112524Z [INFO][PCF][SMpolicy] Handle CreateSmPolicy
2025-07-24T14:54:24.455186178Z [TRAC][PCF][SMpolicy] Handle Create SM Policy Request
2025-07-24T14:54:24.455225445Z [DEBU][PCF][Proc] Request SUPI:[imsi-001010000000001], SNSSAI:[&{1 }]
2025-07-24T14:54:24.471237754Z [TRAC][PCF][SMpolicy] put ratingGroup[1] for [imsi-001010000000001] to MongoDB
2025-07-24T14:54:24.472604590Z [TRAC][PCF][SMpolicy] FlowRules for ueId: imsi-001010000000001 snssai: 01
2025-07-24T14:54:24.485281821Z [INFO][PCF][SMpolicy] Matched [0] trafficInfluDatas from UDR
2025-07-24T14:54:24.494765497Z [DEBU][PCF][Consumer] Influence Data Subscription ID: d310416f
2025-07-24T14:54:24.503611021Z [TRAC][PCF][SMpolicy] SMPolicy PduSessionId[1] Create
2025-07-24T14:54:24.506379814Z [INFO][PCF][GIN] | 201 | 127.0.0.1 | POST | /npcf-smpolicycontrol/v1/sm-policies |
2025-07-24T14:54:24.509269639Z [INFO][SMF][PduSess] CHF Selection for SMContext SUPI[imsi-001010000000001] PDUSessionID[1]
2025-07-24T14:54:24.517417399Z [INFO][SMF][Charging] Handle SendConvergedChargingRequest
2025-07-24T14:54:24.543899956Z [INFO][SMF][Charging] Send Charging Data Request[Init] successfully
2025-07-24T14:54:24.543978213Z [DEBU][SMF][PduSess][pdu_session_id:1][supi:imsi-001010000000001] Install SessionRule[SessRuleId-1]: &{AuthSessAmbr:0xc0001c7
660 AuthDefQos:0xc000441420 SessRuleId:SessRuleId-1 RefUmData: RefUmN3gData: RefCondData:}
2025-07-24T14:54:24.544025608Z [TRAC][SMF][CTX] In GetDefaultUserPlanePathByDNN
2025-07-24T14:54:24.544157835Z [TRAC][SMF][CTX] selection: Dnn: internet
Sst: 1, Sd:
2025-07-24T14:54:24.544184561Z [TRAC][SMF][CTX] Find UPF with DNN[internet] S-NSSAI[sst: 1 sd: ] DNAI[]
2025-07-24T14:54:24.544296635Z [TRAC][SMF][PduSess][pdu_session_id:1][supi:imsi-001010000000001] CreatePccRuleDataPath: pcc rule: &{PccRule:0xc0000f4d80 QFI
:0 Datapath:}
2025-07-24T14:54:24.544329016Z [TRAC][SMF][PduSess] In AllocateLocalSEIDForDataPath
2025-07-24T14:54:24.544351089Z [TRAC][SMF][PduSess] NodeIDtoIP: 10.1.6.193
2025-07-24T14:54:24.544374433Z [TRAC][SMF][PduSess] In ActivateTunnelAndPDR
2025-07-24T14:54:24.544403245Z [TRAC][SMF][PduSess] DataPath Meta Information
Activated: false
IsDefault Path: true
Has Braching Point: false
Destination IP:
Destination Port:
DataPath Routing Information
1th Node in the Path
Current UPF IP: 10.1.6.193
Current UPF ID: 5276c6a0-9d82-4a7d-8716-454a2c092958
Previous UPF IP: None
Next UPF IP: None
2025-07-24T14:54:24.544446508Z [TRAC][SMF][PduSess] Current DP Node IP: 10.1.6.193
2025-07-24T14:54:24.544475963Z [TRAC][SMF][CTX] In ActivateUpLinkTunnel
2025-07-24T14:54:24.544537133Z [TRAC][SMF][PduSess][pdu_session_id:1][supi:imsi-001010000000001] PutPDRtoPFCPSession [&{PDRID:1 Precedence:0 PDI:{SourceInterface:{InterfaceValue:0} LocalFTeid: NetworkInstance: UEIPAddress: SDFFilter: ApplicationID:} OuterHeaderRemoval: FAR:0xc00033a330 URR:[] QER:[] State:0}]
2025-07-24T14:54:24.544569973Z [TRAC][SMF][CTX] In ActivateDownLinkTunnel
2025-07-24T14:54:24.544597687Z [TRAC][SMF][PduSess][pdu_session_id:1][supi:imsi-001010000000001] PutPDRtoPFCPSession [&{PDRID:2 Precedence:0 PDI:{SourceInte
rface:{InterfaceValue:0} LocalFTeid: NetworkInstance: UEIPAddress: SDFFilter: ApplicationID:} OuterHeaderRemoval: FAR:0xc00033a810
URR:[] QER:[] State:0}]
2025-07-24T14:54:24.544637173Z [TRAC][SMF][PduSess] Create URR: UrrReportTime [30s], UrrReportThreshold: [500000]
2025-07-24T14:54:24.544666347Z [TRAC][SMF][CTX] Calculate 10.1.6.193:8805
2025-07-24T14:54:24.544689458Z [TRAC][SMF][PduSess] Current DP Node IP: 10.1.6.193
2025-07-24T14:54:24.544709243Z [TRAC][SMF][PduSess] Before DLPDR OuterHeaderCreation
2025-07-24T14:54:24.544783990Z [TRAC][SMF][Charging] AddChargingRules: type[0], data:[&{ChgId:ChgId-1 MeteringMethod:VOLUME Offline:true Online:false SdfHan
dl:false RatingGroup:1 ReportingLevel:RAT_GR_LEVEL ServiceId:0 SponsorId: AppSvcProvId: AfChargingIdentifier:0 AfChargId:}]
2025-07-24T14:54:24.544814480Z [TRAC][SMF][PduSess] Successfully add URR 7 for Rating group 1
2025-07-24T14:54:24.544836430Z [TRAC][SMF][PduSess] UpLinkTunnel add URR for node 5276c6a0-9d82-4a7d-8716-454a2c092958 &{PDRID:1 Precedence:255 PDI:{SourceI
nterface:{InterfaceValue:0} LocalFTeid:0xc0001b2bc0 NetworkInstance:0xc000011fb0 UEIPAddress:0xc0001b2c40 SDFFilter: ApplicationID:} OuterHeaderRemoval
:0xc00020626f FAR:0xc00033a330 URR:[0xc000440b60 0xc000440c40 0xc0002fd730] QER:[0xc00033b8f0 0xc00033b4d0] State:0}
2025-07-24T14:54:24.544873273Z [TRAC][SMF][PduSess] DownLinkTunnel add URR for node 5276c6a0-9d82-4a7d-8716-454a2c092958 &{PDRID:2 Precedence:255 PDI:{Sourc
eInterface:{InterfaceValue:1} LocalFTeid: NetworkInstance:0xc000011fe0 UEIPAddress:0xc0001b2d00 SDFFilter: ApplicationID:} OuterHeaderRemoval:<nil

FAR:0xc00033a810 URR:[0xc000440b60 0xc000440c40 0xc0002fd730] QER:[0xc00033b8f0 0xc00033b4d0] State:0}
2025-07-24T14:54:24.544901936Z [INFO][SMF][PduSess][pdu_session_id:1][supi:imsi-001010000000001] Install PCCRule[PccRuleId-1]
2025-07-24T14:54:24.544928541Z [INFO][SMF][PduSess][pdu_session_id:1][supi:imsi-001010000000001] No srcTcData and tgtTcData. Nothing to do
2025-07-24T14:54:24.544982777Z [INFO][SMF][PduSess][pdu_session_id:1][supi:imsi-001010000000001] Has default path
2025-07-24T14:54:24.546986286Z [TRAC][SMF][PduSess][pdu_session_id:1][supi:imsi-001010000000001] In ActivateUPFSession
2025-07-24T14:54:24.547132063Z [INFO][SMF][PduSess] Sending PFCP Session Establishment Request
2025-07-24T14:54:24.547204211Z [TRAC][SMF][PduSess] [SMF] Send SendPfcpSessionEstablishmentRequest
2025-07-24T14:54:24.547230378Z [TRAC][SMF][PduSess] Send to addr 10.1.6.193:8805
2025-07-24T14:54:24.555432053Z [INFO][SMF][PduSess] Received PFCP Session Establishment Accepted Response

#8

Sorry for late reply.

I’ve check the SMF. In current implementation, it actually processes a QoS with QFI=0. That’s because one of the rule from PCF does not include QoS data.

So, in the function of processing these rules, if it doesn’t contain the QoS data, the QFI will not be assigned and this QoS rule will not be stored. Then it should not be sent to UE via NAS message.

Do you use the latest free5GC version?
And, maybe I need you pcap file with turn off the NAS encryption to identify what happen with QFI.

#9

No worries,

We use version 4.0.1 built from sources. We have also tried the docker-compose solution again with QFI = 0 appearing the the NAS messages, using either UERANSIM or COTS UE and physical gNB.

Encryption is off (NEA0), however you still need to enable wireshark’s decoding setting, in order to view the plain NAS 5GS message (https://github.com/free5gc/free5gc/issues/403). (edit -> preferences -> protocols -> NAS-5GS -> Try to detect and decode 5G-EA0 ciphered messages)

I attach again the pcap file of N2 interface (without our patch). You see successful session establishment because its UERANSIM. COTS UEs reject the QoS settings and never connect unless we modify the source code.
nas_qfi_on.pcap (3.0 KB)

We also appllied a different patch, where we re-enabled appending of QFIs and added a condition to not append if QFI = 0. It seems to work, QFI 0 doesnt exist in the message. Flow rules get assigned correct QFI values (like before).
Testing with UERANSIM shows that they also get enforced and are present in the GTP headers.
Uplink GTP holds QFI=1 even if a rule is matched (should have been QFI=2), probably a limitation of UERANSIM (bandwidth rules either uplink or downlink get enforced correctly though).
I will provide an update when we test this patch in our 5G testbed.

#10

Okay, I’ll keep trace the bug.

If I got any outcome, I will update at here too.

#12

Hi
I was seeing the same symptoms here but I’m pleased to say the latest HEAD (25 Aug) seems to work. For interest and in case it’s useful as a reference to anyone else, the environment here is:
i7-10700 (low power 8 physical cores)
X520-2 dual SFP+ NIC
Ubuntu 24.04.2 LTS (desktop) with kernel 6.14.0-28-generic
bare metal installation of…
gtp5g 0.9.14
free5gc built from yesterday’s head
Common IP address for N2 and N3
Commercial gNodeB based on SageRAN protocol stack
Mediatek-based data-centric UE
The UE is successfully setting up two sessions with DNNs internet and oam (we use for TR-069 etc) with no slicing (sd settings commented out) and has been stable overnight.
I’ve seen two problems that may be just down to too many restarts:

  • gtp5g not passing any packets although appears to be properly set up and cleared when checking with gtp5g-tunnel list pdr/far. This was resolved by restarting the machine.
  • Authorisation synch failures after re-starts resolved by changing SQN in the data-base (I don’t quite understand how this is managed/automated - I’ll do some more reading!).

Exciting times!

#13

Sorry - I got carried away. I have two UEs, one Qualcomm and one Mediatek. The Mediatek does now attach but the Qualcomm does not, same problem (QFI: 0). Interestingly I think the Qualcomm is making duplicate session requests…