QFI is hard-coded to 9

[yoursunny]

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:

PDUSessionResourceSetupListSUReq: 1 item
    Item 0
        PDUSessionResourceSetupItemSUReq
            pDUSessionID: 10
            pDUSessionNAS-PDU: 7e02d63eeb7f037e006801005b2e0a01c211000901000631310101ff01060606d60604e22905010a0100012204010000007900060120410101097b000d80000d040101010100100205b0251c08696e7465726e6574066d6e63303031066d63633030310467707273120a
            s-NSSAI
            pDUSessionResourceSetupRequestTransfer: 0000050082000a0c684ee180304a817c80008b000a01f0ac19c40510000001007f00010000860001000088000700010000090400
                PDUSessionResourceSetupRequestTransfer
                    protocolIEs: 5 items
                        Item 0: id-PDUSessionAggregateMaximumBitRate
                        Item 1: id-UL-NGU-UP-TNLInformation
                        Item 2: id-DataForwardingNotPossible
                        Item 3: id-PDUSessionType
                        Item 4: id-QosFlowSetupRequestList
                            ProtocolIE-Field
                                id: id-QosFlowSetupRequestList (136)
                                criticality: reject (0)
                                value
                                    QosFlowSetupRequestList: 1 item
                                        Item 0
                                            QosFlowSetupRequestItem
                                                qosFlowIdentifier: 1
                                                qosFlowLevelQosParameters

However, it is 9 in the GTP-U header:

Frame 42: 134 bytes on wire (1072 bits), 134 bytes captured (1072 bits) on interface br-n3, id 1
Ethernet II, Src: 52:de:ac:19:c4:0d (52:de:ac:19:c4:0d), Dst: 52:de:ac:19:c4:05 (52:de:ac:19:c4:05)
Internet Protocol Version 4, Src: 172.25.196.13, Dst: 172.25.196.5
User Datagram Protocol, Src Port: 2152, Dst Port: 2152
GPRS Tunneling Protocol
    Flags: 0x34
    Message Type: T-PDU (0xff)
    Length: 84
    TEID: 0x10000001 (268435457)
    Next extension header type: PDU Session container (0x85)
    Extension header (PDU Session container)
        Extension Header Length: 1
        PDU Session Container
            0001 .... = PDU Type: UL PDU SESSION INFORMATION (1)
            .... 0000 = Spare: 0x0
            00.. .... = Spare: 0x0
            ..00 1001 = QoS Flow Identifier (QFI): 9
        Next extension header type: No more extension headers (0x00)
Internet Protocol Version 4, Src: 10.1.0.1, Dst: 172.25.193.2
Internet Control Message Protocol

---

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