After PDU session establishment, USER-DATA-PACKET-GENERATION-PROCEDURE transmits an ICMP packet in GTP-U tunnel on the N3 interface.
This packet contains a hard-coded QoS Flow Identifier (QFI) value of 9.
If a UPF is checking QFI (e.g. Open5GCore), the packet would be rejected by the core network.
Consequently, the profile eventually times out.
Packet capture and gNBSim logs: gtp-qfi.zip
The uplink QFI 1 was assigned by the RAN in PDUSessionResourceSetupRequest packet:
After PDU session establishment, USER-DATA-PACKET-GENERATION-PROCEDURE transmits an ICMP packet in GTP-U tunnel on the N3 interface. This packet contains a hard-coded QoS Flow Identifier (QFI) value of 9. If a UPF is checking QFI (e.g. Open5GCore), the packet would be rejected by the core network. Consequently, the profile eventually times out. Packet capture and gNBSim logs: gtp-qfi.zip
The uplink QFI 1 was assigned by the RAN in PDUSessionResourceSetupRequest packet:
However, it is 9 in the GTP-U header:
I see the hard-coded value comes from here: https://github.com/omec-project/gnbsim/blob/b8819f1aa976443dd0bd85684663cb1c35e847a4/util/test/gtp.go#L225 It's invoked by: https://github.com/omec-project/gnbsim/blob/b8819f1aa976443dd0bd85684663cb1c35e847a4/gnodeb/worker/gnbupueworker/handler.go#L24-L25 The data structure does have a QFI field: https://github.com/omec-project/gnbsim/blob/b8819f1aa976443dd0bd85684663cb1c35e847a4/common/messages.go#L98-L102 But it wasn't assigned in the UE: https://github.com/omec-project/gnbsim/blob/b8819f1aa976443dd0bd85684663cb1c35e847a4/realue/worker/pdusessworker/handler.go#L84-L87