Methods and devices for QFI-specific error processing related to a GTP-u tunnel

Abstract

A method performed by a first tunnel endpoint (501), the method comprising: maintaining a General Packet Radio System Tunnelling Protocol User Plane (GTP-U) tunnel to a second tunnel endpoint; receiving from the second tunnel endpoint a G-PDU message (520), which includes a GTP-U header (521) followed by an encapsulated T-PDU data packet (522), wherein the GTP-U header includes a tunnel endpoint identifier (TEID) identifying a PDU Session and a QoS Flow Identifier (QFI) identifying which QoS Flow within the PDU Session the G-PDU message relates to; determining that the QFI is unknown to the first tunnel endpoint; and in response to identifying the unknown QFI, transmitting to the second tunnel endpoint a GTP Error Indication (530), which indicates the TEID and the unknown QFI. This allows the second tunnel endpoint to release the QFI indicated in the GTP Error Indication while leaving other QFIs within the PDU Session active.

Description

METHODS AND DEVICES FOR QFI-SPECIFIC ERROR PROCESSING RELATED TO A GTP-U TUNNELTECHNICAL FIELD

[0001] The present disclosure relates to improvements to the General Packet Radio System (GPRS) Tunnelling Protocol. Targeting a PDU Session with multiple active QoS Flow Identifiers (QFIs), the disclosure proposes a novel GTP Error Indication message that could allow the PDU Session to be upheld in the event of a QFI mismatch.BACKGROUND

[0002] The General Packet Radio System (GPRS) Tunnelling Protocol User Plane (GTP-U) is used in past and current cellular 3GPP radio access technologies, from GSM onwards. GTP-U is expected to be used for tunneling datap in future technologies as well, including 6G.

[0003] GTP-U Tunnels are used to carry encapsulated protocol data units,T-PDUs, and signaling messages between a given pair of GTP-U tunnel endpoints. A node in the access network or the core network may act as a tunnel endpoint. The Tunnel Endpoint Identifier (TEID) which is present in the GTP header shall indicate which tunnel a particular T-PDU belongs to. In this manner, packets are multiplexed and de-multiplexed by GTP-U between a given pair of Tunnel Endpoints. The TEID value to be used in the TEID field shall be signaled to the peer GTP-U entity using a control plane protocol like GTPvi-C, GTPv2-C, RANAP, Si-AP, or NG-AP.

[0004] In detail, as specified in 3GPP TS 29.281, “3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; General Packet Radio System (GPRS) Tunnelling Protocol User Plane (GTPvi-U)”, V19.0.0 (2024-09), a GTP-U tunnel is identified in each endpoint with- a TEID,- an Internet Protocol (IP) address, and- a User Datagram Protocol (UDP) port number.The TEID, which may occupy 4 octets, unambiguously identifies a tunnel endpoint in the receiving GTP-U protocol entity for a given UDP / IP endpoint. The receiving endside of a GTP tunnel locally assigns the TEID value the transmitting side has to use. A GTP Protocol Data Unit (GTP-PDU) is a GTP-U message, which may be either a G-PDU or a signaling message, both being sent between GTP network nodes. The G-PDU comprises the T-PDU and a GTP-U header, whereas the signaling message may be a Path Management message or Tunnel Management message.

[0005] A GTP-U tunnel endpoint identifies a user plane context for which a received GTP-U packet is intended, wherein the context may be an Evolved Packet System (EPS) bearer, a PDU session or a Radio Access Bearer (RAB). Clause 7.3.1 of 3GPP TS 29.281 specifies that, when a GTP-U endpoint receives a G-PDU for which no EPS Bearer context, PDP context, PDU Session, MBMS Bearer context or RAB exists, the GTP-U endpoint shall discard the G-PDU. When such discarding takes place and if additionally the TEID of the incoming G-PDU is different from the value ‘all zeros’, then the GTP-U endpoint shall also return the message GTP Error Indication to the transmitting GTP-U endpoint. In the special case of a 3GPP NR system, the GTP-U context is a PDU Session identified by the TEID. The transmitting GTP-U endpoint is expected to release the PDU session’s resources when it receives the GTP Error Indication.

[0006] In the 3GPP NR quality of service (QoS) model, the QoS Flow is the finest granularity of QoS differentiation in the PDU Session. User Plane traffic with the same QFI within a PDU Session receives the same traffic forwarding treatment with respect to scheduling, admission threshold etc., as governed by one or more QoS rules. A 3-bit QFI is used to identify a QoS Flow in the 5G System. The QFI is carried in an encapsulation header on the N3 and N9 user plane interfaces, without any changes to the end-to-end packet header. QFI shall be used for all PDU Session Types.

[0007] In a G-PDU message according to recent releases of 3GPP TS 29.281, it is possible to indicate the QFI in an Extension Header field, so that the receiving GTP-U endpoint may apply the QoS rules which are relevant to that QoS flow. However, a single faulty QoS flow could lead to the release of the full PDU Session, including any further QoS flows that are still functioning, which the transmitting GTP-U endpoint will have to establish anew.SUMMARY

[0008] In the context of a GTP-U tunnel, one objective of the present disclosure is to make available methods and devices that allow a PDU Session to be maintained also in situation where the receiving tunnel endpoint does not recognize the indicated QFI. Another objective is to propose more efficient failure detection, which considers QFI-level failure only in situations where this is meaningful. A further objective is to provide a computer program with these abilities.

[0009] In a first aspect of the present disclosure, there is provided a method performed by a first tunnel endpoint. The method comprises: maintaining a General Packet Radio System Tunnelling Protocol User Plane (GTP-U) tunnel to a second tunnel endpoint; and receiving from the second tunnel endpoint a G-PDU message, which includes a GTP-U header followed by an encapsulated T-PDU data packet. The GTP-U header includes a tunnel endpoint identifier (TEID) identifying a PDU Session, and a QoS Flow Identifier (QFI) identifying which QoS Flow within the PDU Session the G-PDU message relates to. The method further comprises: determining that the QFI is unknown to the first tunnel endpoint; and, in response to identifying the unknown QFI, transmitting to the second tunnel endpoint a GTP Error Indication, which indicates the TEID and the unknown QFI.

[0010] It is appreciated that any G-PDU message carrying a valid TEID and a known QFI can be handled by a state-of-the-art procedure, which is outside the scope of the above method.

[0011] In a second aspect of the present disclosure, there is provided a method performed by a tunnel endpoint corresponding to the “second tunnel endpoint” discussed just above. The method comprises: maintaining a General Packet Radio System Tunnelling Protocol User Plane, GTP-U, tunnel to a further tunnel endpoint (“first tunnel endpoint”); and transmitting to the first tunnel endpoint a G-PDU message, which includes a GTP-U header followed by an encapsulated T-PDU data packet. Again, the GTP-U header includes a TEID identifying a PDU Session, and a QFI identifying which QoS Flow within the PDU Session the G-PDU message relates to. The method further comprises: receiving from the first tunnel endpoint a GTP Error Indication, which indicates the TEID and the QFIs; and, in response to receiving the GTP Error Indication, releasing the QFI within the PDU Session.

[0012] In a third aspect of the disclosure, there is provided a tunnel endpoint (first tunnel endpoint) with processing circuitry configured to carry out the method according to the first aspect.

[0013] In a fourth aspect of the disclosure, there is provided a tunnel endpoint(second tunnel endpoint) with processing circuitry configured to carry out the method according to the second aspect.

[0014] The fact that the novel GTP Error Indication message indicates not only the TEID but also the unknown QFI, as is common to all of the above aspects, provides a form of QFI-specific error signaling. This allows the second tunnel endpoint to take QoS-flow specific action rather than releasing the full PDU Session. For example, the second tunnel endpoint may release the QFI indicated in the GTP Error Indication message while letting some - or all - of the further QFIs in the PDU Session remain active. Traffic pertaining to these further QFIs is unaffected and may continue while the released QFI is being reestablished.

[0015] It is appreciated that, within a single PDU Session, the second tunnel endpoint may be transmitting a plurality of G-PDU messages relating to different QoS Flows, and that the latency of the error signaling mechanism is so great, or so non-deterministic, that a received GTP Error Indication message cannot be unambiguously traced to a transmitted G-PDU message. The explicit QFI indication in the novel GTP Error Indication message therefore represents a valuable piece of information, for which no apparent substitute is available to the second tunnel endpoint.

[0016] In some embodiments of the method of the first aspect, a QFI shall be considered unknown to the first tunnel endpoint if it is absent from a local table of QFIs which are active within the PDU session. A local table of this kind may be established and / or updated by the first tunnel endpoint based on past PDU Session configuration messages that the first tunnel endpoint has received from the second tunnel endpoint.

[0017] In some embodiments, the method of the first aspect (method in first tunnel endpoint) comprises a further step of assessing whether the TEID is valid. The mentioned assessment of whether the QFI is unknown to the first tunnel endpoint is performed only if the TEID has been found valid. Because TEID invalidity is a majorfailure which implies that none of its QFIs can be possibly be known to the first tunnel endpoint, a meaningless processing step is avoided.

[0018] The present disclosure further relates to a computer program containing instructions for causing a computer to carry out the above methods. In particular, the computer program may be suitable for execution in a network node acting as the first or second tunnel endpoint. The computer program may be stored or distributed on a data carrier. As used herein, a “data carrier” may be a transitory data carrier, such as modulated electromagnetic or optical waves, or a non-transitory data carrier. Non- transitory data carriers include volatile and non-volatile memories, such as permanent and non-permanent storage media of magnetic, optical or solid-state type. Still within the scope of “data carrier”, such memories may be fixedly mounted or portable.

[0019] Generally, all terms used in the claims are to be interpreted according to their ordinary meaning in the technical field, unless explicitly defined otherwise herein. All references to “a / an / the element, apparatus, component, means, step, etc.” are to be interpreted openly as referring to at least one instance of the element, apparatus, component, means, step, etc., unless explicitly stated otherwise. The steps of any method disclosed herein do not have to be performed in the exact order disclosed, unless explicitly stated.BRIEF DESCRIPTION OF THE DRAWINGS

[0020] Aspects and embodiments are now described, by way of example, with reference to the accompanying drawings, on which: figure 1 shows an example of a communication system in accordance with some embodiments; figure 2 shows a core network node and an access network node which exchange encapsulated protocol data units and signaling messages over a GTP-U tunnel; figure 3 is a flowchart of a method performed by a first GTP-U tunnel endpoint; figure 4 is a flowchart of a method performed by a second GTP-U tunnel endpoint; and figure 5 is a sequence diagram showing messages exchanged over a GTP-U tunnel.DETAILED DESCRIPTION

[0021] The aspects of the present disclosure will now be described more fully hereinafter with reference to the accompanying drawings, on which certain embodiments of the invention are shown. These aspects may, however, be embodied in many different forms and should not be construed as limiting; rather, these embodiments are provided by way of example so that this disclosure will be thorough and complete, and to fully convey the scope of all aspects of the invention to those skilled in the art. Like numbers refer to like elements throughout the description.System overview

[0022] Figure 1 shows an example of a communication system 100 in accordance with some embodiments. In the example, the communication system 100 includes a telecommunication network 102 that includes an access network 104, such as a radio access network (RAN), and a core network 106, which includes one or more core network nodes 108. The access network 104 includes one or more access network nodes, such as network nodes 110a and 110b (one or more of which may be generally referred to as network nodes 110), or any other similar 3rdGeneration Partnership Project (3GPP) access nodes or non-3GPP access points. Moreover, as will be appreciated by those of skill in the art, a network node is not necessarily limited to an implementation in which a radio portion and a baseband portion are supplied and integrated by a single vendor. Thus, it will be understood that network nodes include disaggregated implementations or portions thereof. For example, in some embodiments, the telecommunication network 102 includes one or more Open- RAN (ORAN) network nodes. An ORAN network node is a node in the telecommunication network 102 that supports an ORAN specification (e.g., a specification published by the O-RAN Alliance, or any similar organization) and may operate alone or together with other nodes to implement one or more functionalities of any node in the telecommunication network 102, including one or more network nodes 110 and / or core network nodes 108.

[0023] Examples of an ORAN network node include an open radio unit (O-RU), an open distributed unit (O-DU), an open central unit (O-CU), including an O-CU control plane (O-CU-CP) or an O-CU user plane (O-CU-UP), a RAN intelligent controller (near-real time or non-real time) hosting software or software plug-ins, such as a near-real time control application (e.g., xApp) or a non-real time controlapplication (e.g., rApp), or any combination thereof (the adjective “open” designating support of an ORAN specification). The network node may support a specification by, for example, supporting an interface defined by the ORAN specification, such as an Al, Fl, Wi, El, E2, X2, Xn interface, an open fronthaul user plane interface, or an open fronthaul management plane interface. Moreover, an ORAN access node may be a logical node in a physical node. Furthermore, an ORAN network node may be implemented in a virtualization environment (described further below) in which one or more network functions are virtualized. For example, the virtualization environment may include an O-Cloud computing platform orchestrated by a Service Management and Orchestration Framework via an 0-2 interface defined by the O- RAN Alliance or comparable technologies. The network nodes no facilitate direct or indirect connection of user equipment (UE), such as by connecting UEs 112a, 112b, 112c, and ii2d (one or more of which may be generally referred to as UEs 112) to the core network 106 over one or more wireless connections.

[0024] Example wireless communications over a wireless connection include transmitting and / or receiving wireless signals using electromagnetic waves, radio waves, infrared waves, and / or other types of signals suitable for conveying information without the use of wires, cables, or other material conductors. Moreover, in different embodiments, the communication system 100 may include any number of wired or wireless networks, network nodes, UEs, and / or any other components or systems that may facilitate or participate in the communication of data and / or signals whether via wired or wireless connections. The communication system 100 may include and / or interface with any type of communication, telecommunication, data, cellular, radio network, and / or other similar type of system.

[0025] The UEs 112 may be any of a wide variety of communication devices, including wireless devices arranged, configured, and / or operable to communicate wirelessly with the network nodes 110 and other communication devices. Similarly, the network nodes 110 are arranged, capable, configured, and / or operable to communicate directly or indirectly with the UEs 112 and / or with other network nodes or equipment in the telecommunication network 102 to enable and / or provide network access, such as wireless network access, and / or to perform other functions, such as administration in the telecommunication network 102.

[0026] In the depicted example, the core network 106 connects the network nodes 110 to one or more hosts, such as host 116. These connections may be direct or indirect via one or more intermediary networks or devices. In other examples, network nodes may be directly coupled to hosts. The core network 106 includes one more core network nodes (e.g., core network node 108) that are structured with hardware and software components. Features of these components maybe substantially similar to those described with respect to the UEs, network nodes, and / or hosts, such that the descriptions thereof are generally applicable to the corresponding components of the core network node 108. Example core network nodes include functions of one or more of a Mobile Switching Center (MSC), Mobility Management Entity (MME), Home Subscriber Server (HSS), Access and Mobility Management Function (AMF), Session Management Function (SMF), Authentication Server Function (AUSF), Subscription Identifier De-concealing function (SIDF), Unified Data Management (UDM), Security Edge Protection Proxy (SEPP), Network Exposure Function (NEF), and / or a User Plane Function (UPF).

[0027] The host 116 may be under the ownership or control of a service provider other than an operator or provider of the access network 104 and / or the telecommunication network 102, and may be operated by the service provider or on behalf of the service provider. The host 116 may host a variety of applications to provide one or more service. Examples of such applications include live and prerecorded audio / video content, data collection services such as retrieving and compiling data on various ambient conditions detected by a plurality of UEs, analytics functionality, social media, functions for controlling or otherwise interacting with remote devices, functions for an alarm and surveillance center, or any other such function performed by a server.

[0028] As a whole, the communication system 100 of Figure 1 enables connectivity between the UEs, network nodes, and hosts. In that sense, the communication system may be configured to operate according to predefined rules or procedures, such as specific standards that include, but are not limited to: Global System for Mobile Communications (GSM); Universal Mobile Telecommunications System (UMTS); Long Term Evolution (LTE); New Radio (NR), and / or other suitable 2G, 3G, 4G, 5G standards, or any applicable future generation standard (e.g., 6G).

[0029] In some examples, the telecommunication network 102 is a cellular network that implements 3GPP standardized features. Accordingly, the telecommunications network 102 may support network slicing to provide different logical networks to different devices that are connected to the telecommunication network 102. For example, the telecommunications network 102 may provide Ultra Reliable Low Latency Communication (URLLC) services to some UEs, while providing Enhanced Mobile Broadband (eMBB) services to other UEs, and / or Massive Machine Type Communication (mMTC) / Massive loT services to yet further UEs.

[0030] In some examples, the UEs 112 are configured to transmit and / or receive information without direct human interaction. For instance, a UE may be designed to transmit information to the access network 104 on a predetermined schedule, when triggered by an internal or external event, or in response to requests from the access network 104. Additionally, a UE may be configured for operating in single- or multi- RAT or multi-standard mode. For example, a UE may operate with any one or combination of Wi-Fi, NR (New Radio) and LTE, i.e. being configured for multi-radio dual connectivity (MR-DC), such as E-UTRAN (Evolved-UMTS Terrestrial Radio Access Network) New Radio - Dual Connectivity (EN-DC).

[0031] In the example, a hub 114 communicates with the access network 104 to facilitate indirect communication between one or more UEs (e.g., UE 112c and / or ii2d) and network nodes (e.g., network node 110b). In some examples, the hub 114 may be a controller, router, content source and analytics, or any of the other communication devices described herein regarding UEs. For example, the hub 114 may be a broadband router enabling access to the core network 106 for the UEs. As another example, the hub 114 may be a controller that sends commands or instructions to one or more actuators in the UEs. Commands or instructions may be received from the UEs, network nodes 110, or by executable code, script, process, or other instructions in the hub 114. As another example, the hub 114 may be a data collector that acts as temporary storage for UE data and, in some embodiments, may perform analysis or other processing of the data. As another example, the hub 114 may be a content source. For example, for a UE that is a VR headset, display, loudspeaker or other media delivery device, the hub 114 may retrieve VR assets, video, audio, or other media or data related to sensory information via a network node, which the hub 114 then provides to the UE either directly, after performinglocal processing, and / or after adding additional local content. In still another example, the hub 114 acts as a proxy server or orchestrator for the UEs, in particular if one or more of the UEs are low energy loT devices.

[0032] The hub 114 may have a constant / persistent or intermittent connection to the network node 110b. The hub 114 may also allow for a different communication scheme and / or schedule between the hub 114 and UEs (e.g., UE 112c and / or ii2d), and between the hub 114 and the core network 106. In other examples, the hub 114 is connected to the core network 106 and / or one or more UEs via a wired connection. Moreover, the hub 114 may be configured to connect to an M2M service provider over the access network 104 and / or to another UE over a direct connection. In some scenarios, UEs may establish a wireless connection with the network nodes 110 while still connected via the hub 114 via a wired or wireless connection. In some embodiments, the hub 114 may be a dedicated hub - that is, a hub whose primary function is to route communications to / from the UEs from / to the network node 110b. In other embodiments, the hub 114 may be a non-dedicated hub - that is, a device which is capable of operating to route communications between the UEs and network node 110b, but which is additionally capable of operating as a communication start and / or end point for certain data channels.

[0033] Figure 2 shows an access network node 110 and a core network node 108 which exchange encapsulated protocol data units and signaling messages over a GTP-U tunnel 250.

[0034] As used herein, network node refers to equipment capable, configured, arranged and / or operable to communicate directly or indirectly with a UE and / or with other network nodes or equipment, in a telecommunication network. Examples of network nodes include, but are not limited to, access points (APs) (e.g., radio access points), base stations (BSs) (e.g., radio base stations, Node Bs, evolved Node Bs (eNBs) and NRNodeBs (gNBs)), Mobile Switching Center (MSC), Mobility Management Entity (MME), Home Subscriber Server (HSS), Access and Mobility Management Function (AMF), Session Management Function (SMF), Authentication Server Function (AUSF), Subscription Identifier De-concealing function (SIDF), Unified Data Management (UDM), Security Edge Protection Proxy (SEPP), Network Exposure Function (NEF), and / or a User Plane Function (UPF), O-RAN nodes or components of an O-RAN node (e.g., O-RU, O-DU, O-CU).

[0035] Base stations may be categorized based on the amount of coverage they provide (or, stated differently, their transmit power level) and so, depending on the provided amount of coverage, may be referred to as femto base stations, pico base stations, micro base stations, or macro base stations. A base station may be a relay node or a relay donor node controlling a relay. A network node may also include one or more (or all) parts of a distributed radio base station such as centralized digital units, distributed units (e.g., in an O-RAN access node) and / or remote radio units (RRUs), sometimes referred to as Remote Radio Heads (RRHs). Such remote radio units may or may not be integrated with an antenna as an antenna integrated radio. Parts of a distributed radio base station may also be referred to as nodes in a distributed antenna system (DAS).

[0036] Other examples of network nodes include multiple transmission point (multi-TRP) 5G access nodes, multi-standard radio (MSR) equipment such as MSR BSs, network controllers such as radio network controllers (RNCs) or base station controllers (BSCs), base transceiver stations (BTSs), transmission points, transmission nodes, multi-cell / multicast coordination entities (MCEs), Operation and Maintenance (O&M) nodes, Operations Support System (OSS) nodes, SelfOrganizing Network (SON) nodes, positioning nodes (e.g., Evolved Serving Mobile Location Centers (E-SMLCs)), and / or Minimization of Drive Tests (MDTs).

[0037] The access network node 110 depicted in figure 2 includes a processing circuitry 222, a memory 224, a communication interface 226, and a power source 228. The access network node 110 may be composed of multiple physically separate components (e.g., a NodeB component and a RNC component, or a BTS component and a BSC component, etc.), which may each have their own respective components. In certain scenarios in which the access network node 110 comprises multiple separate components (e.g., BTS and BSC components), one or more of the separate components may be shared among several access network nodes. For example, a single RNC may control multiple NodeBs. In such a scenario, each unique NodeB and RNC pair, may in some instances be considered a single separate access network node. In some embodiments, the access network node 110 may be configured to support multiple radio access technologies (RATs). In such embodiments, some components may be duplicated (e.g., separate memory 224 for different RATs) and some components maybe reused (e.g., a same antenna 230 maybe shared bydifferent RATs). The access network node no may also include multiple sets of the various illustrated components for different wireless technologies integrated into access network node no, for example GSM, WCDMA, LTE, NR, WiFi, Zigbee, Z-wave, LoRaWAN, Radio Frequency Identification (RFID) or Bluetooth wireless technologies. These wireless technologies may be integrated into the same or different chip or set of chips and other components within access network node no.

[0038] The processing circuitry 222 may comprise a combination of one or more of a microprocessor, controller, microcontroller, central processing unit, digital signal processor, application-specific integrated circuit, field programmable gate array, or any other suitable computing device, resource, or combination of hardware, software and / or encoded logic operable to provide, either alone or in conjunction with other access network node 110 components, such as the memory 224, to provide access network node no functionality.

[0039] In some embodiments, the processing circuitry 222 includes a system on a chip (SOC). In some embodiments, the processing circuitry 222 includes one or more of radio frequency (RF) transceiver circuitry 232 and baseband processing circuitry 234. In some embodiments, the radio frequency (RF) transceiver circuitry 232 and the baseband processing circuitry 234 may be on separate chips (or sets of chips), boards, or units, such as radio units and digital units. In alternative embodiments, part or all of RF transceiver circuitry 232 and baseband processing circuitry 234 may be on the same chip or set of chips, boards, or units.

[0040] The memory 224 may comprise any form of volatile or non-volatile computer-readable memory including, without limitation, persistent storage, solid- state memory, remotely mounted memory, magnetic media, optical media, random access memory (RAM), read-only memory (ROM), mass storage media (for example, a hard disk), removable storage media (for example, a flash drive, a Compact Disk (CD) or a Digital Video Disk (DVD)), and / or any other volatile or non-volatile, non- transitory device-readable and / or computer-executable memory devices that store information, data, and / or instructions that may be used by the processing circuitry 222. The memory 224 may store any suitable instructions, data, or information, including a computer program, software, an application including one or more of logic, rules, code, tables, and / or other instructions capable of being executed by the processing circuitry 222 and utilized by the access network node 110. The memory224 may be used to store any calculations made by the processing circuitry 222 and / or any data received via the communication interface 226. In some embodiments, the processing circuitry 222 and memory 224 are integrated.

[0041] The communication interface 226 is used in wired or wireless communication of signaling and / or data with a core network node, another access network node, and / or UE. As illustrated, the communication interface 226 comprises port(s) / terminal(s) to send and receive data, for example to and from a network over a wired connection. The communication interface 226 also includes radio front-end circuitry 238 that may be coupled to, or in certain embodiments a part of, the antenna 230. Radio front-end circuitry 238 comprises filters 240 and amplifiers 242. The radio front-end circuitry 238 may be connected to an antenna 230 and processing circuitry 222. The radio front-end circuitry may be configured to condition signals communicated between antenna 230 and processing circuitry 222. The radio front-end circuitry 238 may receive digital data that is to be sent out to other access network nodes or UEs via a wireless connection. The radio front-end circuitry 238 may convert the digital data into a radio signal having the appropriate channel and bandwidth parameters using a combination of filters 240 and / or amplifiers 242. The radio signal may then be transmitted via the antenna 230. Similarly, when receiving data, the antenna 230 may collect radio signals which are then converted into digital data by the radio front-end circuitry 238. The digital data may be passed to the processing circuitry 222. In other embodiments, the communication interface may comprise different components and / or different combinations of components.

[0042] In certain alternative embodiments, the access network node 110 does not include separate radio front-end circuitry 238, instead, the processing circuitry 222 includes radio front-end circuitry and is connected to the antenna 230. Similarly, in some embodiments, all or some of the RF transceiver circuitry 232 is part of the communication interface 226. In still other embodiments, the communication interface 226 includes one or more ports or terminals, the radio front-end circuitry 238, and the RF transceiver circuitry 232, as part of a radio unit (not shown), and the communication interface 226 communicates with the baseband processing circuitry 234, which is part of a digital unit (not shown).

[0043] The antenna 230 may include one or more antennas, or antenna arrays, configured to send and / or receive wireless signals. The antenna 230 may be coupledto the radio front-end circuitry 238 and may be any type of antenna capable of transmitting and receiving data and / or signals wirelessly. In certain embodiments, the antenna 230 is separate from the access network node 110 and connectable to the access network node 110 through an interface or port.

[0044] The antenna 230, communication interface 226, and / or the processing circuitry 222 may be configured to perform any receiving operations and / or certain obtaining operations described herein as being performed by the access network node. Any information, data and / or signals may be received from a UE, another access network node and / or any other network equipment. Similarly, the antenna 230, the communication interface 226, and / or the processing circuitry 222 maybe configured to perform any transmitting operations described herein as being performed by the access network node. Any information, data and / or signals may be transmitted to a UE, another access network node and / or any other network equipment.

[0045] The power source 228 provides power to the various components of access network node 110 in a form suitable for the respective components (e.g., at a voltage and current level needed for each respective component). The power source 228 may further comprise, or be coupled to, power management circuitry to supply the components of the access network node 110 with power for performing the functionality described herein. For example, the access network node 110 maybe connectable to an external power source (e.g., the power grid, an electricity outlet) via an input circuitry or interface such as an electrical cable, whereby the external power source supplies power to power circuitry of the power source 228. As a further example, the power source 228 may comprise a source of power in the form of a battery or battery pack which is connected to, or integrated in, power circuitry. The battery may provide backup power should the external power source fail.

[0046] Embodiments of the access network node 110 may include additional components beyond those shown in figure 2 for providing certain aspects of the access network node’s functionality, including any of the functionality described herein and / or any functionality necessary to support the subject matter described herein. For example, the access network node 110 may include user interface equipment to allow input of information into the access network node 110 and to allow output of information from the access network node 110. This may allow a userto perform diagnostic, maintenance, repair, and other administrative functions for the access network node no.

[0047] Still with reference to figure 2, the core network node 108 comprises processing circuitry 202, a memory 204, a communication interface 206, and a power source 208.

[0048] The processing circuitry 202 may comprise a combination of one or more of a microprocessor, controller, microcontroller, central processing unit, digital signal processor, application-specific integrated circuit, field programmable gate array, or any other suitable computing device, resource, or combination of hardware, software and / or encoded logic operable to provide, either alone or in conjunction with other core network node 108 components, such as the memory 204, to provide core network node 108 functionality. In some embodiments, the processing circuitry 202 includes a system on a chip (SOC).

[0049] The memory 204 may comprise any form of volatile or non-volatile computer-readable memory including, without limitation, persistent storage, solid- state memory, remotely mounted memory, magnetic media, optical media, random access memory (RAM), read-only memory (ROM), mass storage media (for example, a hard disk), removable storage media (for example, a flash drive, a Compact Disk (CD) or a Digital Video Disk (DVD)), and / or any other volatile or non-volatile, non- transitory device-readable and / or computer-executable memory devices that store information, data, and / or instructions that may be used by the processing circuitry 202. The memory 204 may store any suitable instructions, data, or information, including a computer program, software, an application including one or more of logic, rules, code, tables, and / or other instructions capable of being executed by the processing circuitry 202 and utilized by the core network node 108. The memory 204 may be used to store any calculations made by the processing circuitry 202 and / or any data received via the communication interface 206. In some embodiments, the processing circuitry 202 and memory 204 are integrated.

[0050] The communication interface 206 is used in communication of signaling and / or data with another core network node, an access network node, and / or UE. As illustrated, the communication interface 206 comprises port(s) / terminal(s) to send and receive data, for example to and from a network over a wired connection. The communication interface 206 is preferably configured for wired communication.

[0051] The power source 208 provides power to the various components of the core network node 108 in a form suitable for the respective components (e.g., at a voltage and current level needed for each respective component). The power source 208 may further comprise, or be coupled to, power management circuitry to supply the components of the core network node 108 with power for performing the functionality described herein. For example, the core network node 108 maybe connectable to an external power source (e.g., the power grid, an electricity outlet) via an input circuitry or interface such as an electrical cable, whereby the external power source supplies power to power circuitry of the power source 208. As a further example, the power source 208 may comprise a source of power in the form of a battery or battery pack which is connected to, or integrated in, power circuitry. The battery may provide backup power should the external power source fail.

[0052] Embodiments of the core network node 108 may include additional components beyond those shown in figure 2 for providing certain aspects of the core network node’s functionality, including any of the functionality described herein and / or any functionality necessary to support the subject matter described herein. For example, the core network node 108 may include user interface equipment to allow input of information into the core network node 108 and to allow output of information from the core network node 108. This may allow a user to perform diagnostic, maintenance, repair, and other administrative functions for the core network node 108.

[0053] Although the computing devices (e.g., core network node 108, access network node 110) described herein may include the illustrated combination of hardware components, other embodiments may comprise computing devices with different combinations of components. It is to be understood that these computing devices may comprise any suitable combination of hardware and / or software needed to perform the tasks, features, functions and methods disclosed herein. Determining, calculating, obtaining or similar operations described herein may be performed by processing circuitry, which may process information by, for example, converting the obtained information into other information, comparing the obtained information or converted information to information stored in the network node, and / or performing one or more operations based on the obtained information or converted information, and as a result of said processing making a determination. Moreover, whilecomponents are depicted as single boxes located within a larger box, or nested within multiple boxes, in practice, computing devices may comprise multiple different physical components that make up a single illustrated component, and functionality maybe partitioned between separate components. For example, a communication interface may be configured to include any of the components described herein, and / or the functionality of the components may be partitioned between the processing circuitry and the communication interface. In another example, non- computationally intensive functions of any of such components may be implemented in software or firmware and computationally intensive functions may be implemented in hardware.

[0054] In certain embodiments, some or all of the functionality described herein may be provided by processing circuitry executing instructions stored on in memory, which in certain embodiments may be a computer program product in the form of a non-transitory computer-readable storage medium. In alternative embodiments, some or all of the functionality may be provided by the processing circuitry without executing instructions stored on a separate or discrete device-readable storage medium, such as in a hard-wired manner. In any of those particular embodiments, whether executing instructions stored on a non-transitory computer-readable storage medium or not, the processing circuitry can be configured to perform the described functionality. The benefits provided by such functionality are not limited to the processing circuitry alone or to other components of the computing device, but are enjoyed by the computing device as a whole, and / or by end users and a wireless network generally.

[0055] The core network node 108 and access network node 110 hold software instructions for implementing the General Packet Radio System (GPRS) Tunnelling Protocol User Plane (GTP-U). As shown in figure 2, the two network nodes 108, 110 maintain a GTP-U tunnel 250 between themselves and they thus act as GTP-U tunnel endpoints. Reference is made to the detailed introduction of GTP-U in an earlier section of the present disclosure. In particular, the two network nodes 108, 110 are configured to exchange G-PDU messages.

[0056] Figure 5 illustrates an example G-PDU message structure 520 suitable for a 3GPP NR system. Although the G-PDU message 520 is depicted while travelling from the second tunnel endpoint 502 to the first tunnel endpoint 501, a given GTP-Utunnel generally allows a bidirectional exchange of G-PDU messages. The G-PDU message 520 includes a GTP-U header 521 followed by an encapsulated T-PDU data packet 522 containing payload data. The GTP-U header includes a tunnel endpoint identifier (TEID) and a QoS Flow Identifier (QFI). More precisely, the QFI may be contained in an Extension Header field 521.1 within the GTP-U header 521, as specified in clause 5.2.1 of 3GPP TS 29.281. The QFI may be represented by three binary bits, corresponding to the integers o, 1, 2, ..., 7. In a 3GPP NR system, the TEID is interpreted as an identifier of a PDU Session, and the QFI indicates which QoS Flow within the PDU Session the G-PDU message 520 relates to.

[0057] In accordance with the teachings presented herein, the core network node 108 and access network node 110 perform internal bookkeeping of active TEIDs (which indicate PDU sessions) and active QFIs within each TEID. The bookkeeping may be supported by a suitable data structure, such as a list, vector, array or database, in which items representing TEIDs and QFIs can be entered and deleted, whenever the network node 108, 110 becomes aware of their activation or release, and which the network node 108, 110 can consult to determine whether a TEID or QFI in an incoming G-PDU message 520 is known or unknown. For example, the data structure may have the form of a table where each column includes a TEID value (4 octets) followed by eight Boolean values corresponding to the eight possible QFI values.Boolean true may indicate that this QFI is active, while Boolean false indicates that the QFI is inactive.

[0058] Activating a new PDU Session may be reflected in bookkeeping by appending a new column to the table, whereas releasing an existing PDU Session may correspond to deleting the corresponding column from the table. Activation and release of a QFI within a PDU Session may correspond to setting the corresponding Boolean entries items in the column with the corresponding TEID to true and false, respectively.

[0059] In an alternative bookkeeping format, the table has a constant number of columns. Then, the activation may be reflected by entering the new PDU Session’s TEID in the top line of an existing column in the table and setting the first known QFI within the PDU Session to Boolean true; release may correspond to deleting the TEID from the first line of the column and setting the eight QFI entries to Boolean false.

[0060] For simplicity, the data structure used for such bookkeeping will be referred to as a local table. As suggested by figure 2, the local table 216, 236 may be implemented in memory in the communication interface 206, 226. A GTP-U tunnel endpoint which activates or releases a TEID or QFI (this is a PDU Session configuration decision) may be configured to notify the other GTP-U tunnel endpoint of the same GTP-U tunnel 250 by transmitting to it a PDU Session configuration message. The GTP-U tunnel endpoint may be configured to update its local table 216, 236 based on the PDU Session configuration messages transmitted to the first tunnel endpoint and / or based on the tunnel endpoint’s PDU Session configuration decisions. It is appreciated that said other GTP-U tunnel endpoint may be configured to make the necessary updates to its local table 216, 236 whenever it receives such a PDU Session configuration message indicating that a TEID or QFI has been activated or released.

[0061] Example PDU Session configuration messages in this sense include PDU Session Resource Setup Request, PDU Session Resource Release Command, PDU Sesson Resource Modify Request, PDU Sesson Resource Modify Indication, PDUSession Resource Notify. At least messages 510 and 540 in figure 5 are PDU Session configuration messages.QFI-specific error processing method

[0062] Shifting the focus now to the flowchart in figure 3, though with continued attention to the sequence diagram in figure 5, there will be described a method 300 performed by a first GTP-U tunnel endpoint 501. The first tunnel endpoint 501 may be a core network node 108 or an access network node 110. It is noted that some embodiments of the method 300 may include fewer than the full number of steps drawn in figure 3.

[0063] In a first step 301 of the method 300, the first tunnel endpoint 501 maintains a GTP-U tunnel 250 to a second tunnel endpoint 502. As mentioned above, this may optionally include receiving one or more PDU Session configuration messages 510 from the second tunnel endpoint 502 and updating a local table 216, 236 of QFIs accordingly. The GTP-U tunnel 250 may be maintained throughout the execution of the method 300, i.e., the execution of step 301 does not terminate when step 302 is entered.

[0064] In a second step 302, the first tunnel endpoint 501 receives a G-PDU message 520, which includes a TEID and a QFI. The G-PDU message 520 is processed as specified in 3GPP TS 29.281. For example, the first tunnel endpoint 501 may extract the T-PDU from the G-PDU message 520 and hand it over to a different protocol layer for processing.

[0065] In a subsequent step 304, the first tunnel endpoint 501 determines whether the QFI in the G-PDU message 520 is unknown to the first tunnel endpoint. This may imply, in more detail, that the first tunnel endpoint 501 determines, based on its current state of knowledge, whether this QFI is active in the PDU Session indicated by the G-PDU message’s 520 TEID. In particular, the current state of knowledge of the first tunnel endpoint 501 may correspond to the content of the local table 216, 236 maintained by the first tunnel endpoint 501, so that, accordingly, step 304 includes a substep 304.1 of consulting the local table 216, 236. Although the state of knowledge is nominally identical at both ends of an GTP-U tunnel 250 in error-free operation, discrepancies between the tunnel endpoints 501, 502 in this regard may nevertheless arise due to such factors as undelivered PDU Sessionconfiguration messages 510, unprocessed PDU Session configuration messages 510, intervention by overriding safety or QoS mechanisms, implementation errors, software execution errors, and the like. This confirms the usefulness of error signaling in connection with a GTP-U tunnel 250.

[0066] The further steps of the method are executed only if step 304 has a negative outcome, i.e., when it is determined that the QFI in the G-PDU message 520 is unknown to the first tunnel endpoint 501. More precisely, in a step 305 which is performed in response to identifying the unknown QFI, the first tunnel endpoint 501 transmits to the second tunnel endpoint 502 a GTP Error Indication 530, which indicates the TEID and the unknown QFI. As explained above, the fact that the GTP Error Indication message 530 indicates not only the TEID but also the unknown QFI allows the second tunnel endpoint 502 to take action specifically relating to the QoS flow concerned, rather than releasing the full PDU Session indicated by the TEID. For example, the second tunnel endpoint 502 may release the QFI indicated in the GTP Error Indication message while letting some or all of the further QFIs in the PDU Session remain active. Traffic associated with these further QFIs is unaffected and may continue while the released QFI is being reestablished.

[0067] In the GTP Error Indication 530 message, the indicated QFI may be carried in the information element “Private Extension”; see Table 7.3.1-1 of 3GPP TS 29.281 V19.0.0. In future versions of this specification, a dedicated information element for QFI may be defined, and this information element is preferably used in step 305.

[0068] After sending the GTP Error Indication 530, the first tunnel endpoint 501 may optionally receive a message confirming that the unknown QFI has been released. This is illustrated in figure 3 as a step 306 of the method 300. If the second tunnel endpoint 502 is an access network node 110 and the first tunnel endpoint 501 is a core network node 108, the first tunnel endpoint may expect to receive a PDU Session Resource Notify message 540 from the second tunnel endpoint 502, which confirms that the second tunnel endpoint 502 has released the QFI. Conversely, if the second tunnel endpoint 502 is a core network node 108, the first tunnel endpoint 501 may expect to receive a PDU Session Resource Release Command message or a PDU Session Resource Modify Request message. In some implementations, these messages are sent, not by the second tunnel endpoint 502 itself (e.g., UPF in 5GC)but by another core network node. The other core network node in 5GC may be an AMF, which the UPF notifies through the intermediary of the SMF, and according to the procedure in clause 5.3.2 of 3GPP TS 23.527, “3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; 5G System; Restoration Procedures”, V18.5.0 (2024-09). Likewise, the actual release of the QFI is not necessarily performed by the second tunnel endpoint 502. Yet the transmission of the PDU Session Resource Release Command message or PDU Session Resource Modify Request message results from a causal chain of events initiated by the second tunnel endpoint 502. In this sense, the PDU Session Resource Release Command and PDU Session Resource Modify Request are messages concerning release of the unknown QFI, and they are ordered by the second tunnel endpoint 502.

[0069] By monitoring receipt (step 306) of the PDU Session Resource Notify message, the PDU Session Resource Release Command message or the PDU Session Resource Modify Request message, as the case may be, the first tunnel endpoint 501 is able to confirm that the transmitted GTP Error Indication 530 has had the intended effects.

[0070] In some embodiments of the method 300, step 304 (determining QFI is unknown) is conditional upon having first established that the TEID is valid. Accordingly, as shown in figure 3, the first tunnel endpoint 501 assesses, in a step 303, whether the TEID of the received a G-PDU message 520 is valid, and only in the case of a positive outcome (Y branch from step 303), it proceeds to step 304. The TEID may be considered valid if it appears in the local table 216, 236. In the case of a negative outcome of step 303 (N branch from step 303), the first tunnel endpoint 501 executes a step 307, in which the invalid TEID is handled according to clause 7.3.1 of 3GPP TS 29.281 (“G-PDU for which no [...] PDU Session [...] exists”). Such handling may include discarding the G-PDU and further returning a GTP Error Indication to the second tunnel endpoint 502 unless the TEID is all zeros.

[0071] Turning now to figure 4, a method 400 performed by a second GTP-U tunnel endpoint 502 will be described. The second tunnel endpoint 502 may be a core network node 108 or an access network node 110. It is understood that the methods 300 and 400 are performed by two cooperating tunnel endpoints, referred to as first and second tunnel endpoints 501, 502 herein.

[0072] In a first step 401 of the method 400, the second tunnel endpoint 502 maintains a GTP-U tunnel 250 to the first tunnel endpoint 502. As mentioned above, this may optionally include transmitting one or more PDU Session configuration messages 510 to the first tunnel endpoint 501, for thereby allowing the first tunnel endpoint 501 to update a local table 216, 236 of QFIs accordingly. The second tunnel endpoint 502 may update 401.1 its own local table 216, 236 in a manner consistent with the PDU Session configuration messages 510 transmitted to the first tunnel endpoint 501 and / or with the second tunnel endpoint’s 520 own PDU Session configuration decisions.

[0073] In a second step 402, the second tunnel endpoint 502 transmits one or more G-PDU messages 520, each having the structure described above (see figure 5 and step 302 in method 300), to the first tunnel endpoint 501.

[0074] If the second tunnel endpoint 502 receives, in a third step 403, a GTPError Indication 530 indicating a TEID and a QFI, the second tunnel endpoint 502 may conclude that, based on the state of knowledge of the first tunnel endpoint 501, the indicated TEID is valid (i.e., it corresponds to an active PDU Session) but the indicated QFI is unknown. It is appreciated that the indicated TEID and QFI may correspond to the TEID and QFI of a different G-PDU message 520 than the most recently transmitted one. As mentioned above, the indicated QFI may be carried in the information element “Private Extension” (Table 7.3.1-1 of 3GPP TS 29.281) or in a dedicated information element for QFI.

[0075] After concluding from the received GTP Error Indication 530 that the TEID is valid but the QFI is unknown, the second tunnel endpoint 502 proceeds to a step 404 of releasing said QFI within the PDU Session indicated by the TEID. Preferably, the second tunnel endpoint 502 refrains to act in respect of the further QFIs in the PDU Session; said further QFIs which are not acted upon may instead remain active, so that the corresponding traffic flows may continue substantially without interruption. Nor does the receiving of the GTP Error Indication 530 trigger any action from the second tunnel endpoint 502 outside the concerned PDU Session, whether in any other PDU Session or in other aspects of the operation of the 3GPP NR system.

[0076] Step 404 may be described as QFI-specific action or QoS-flow specific action occasioned by the received GTP Error Indication 530. The releasing of the QFImay follow one of the procedures described in clause 5.3.2 of 3GPP TS 23.527 (if the first tunnel endpoint 501 is an access network node 110 and the second tunnel endpoint 502 is a core network node 108) or the procedures described in clause 5.3.3 of 3GPP TS 23.527 (if the first tunnel endpoint 501 is a core network node 108 and the second tunnel endpoint 502 is an access network node 110), respectively.

[0077] As regards internal bookkeeping, step 404 may include an optional substep 404.1 in such embodiments where the second tunnel endpoint 502 maintains a local table 216, 236 of QFIs which are active within the PDU session. The substep 404.1 includes erasing the indicated QFI from said local table 216, 236.

[0078] In an optional step 405 of the method 400, an access network node 110 acting as the second tunnel endpoint 502 transmits to the first tunnel endpoint 501 a PDU Session Resource Notify message 540 indicating release of the indicated QFI. In the optional step 405, alternatively, a core network node 108 (e.g., UPF in 5GC) acting as the second tunnel endpoint 502 orders transmission to the first tunnel endpoint 501 of a PDU Session Resource Release Command message or a PDU Session Resource Modify Request message concerning release of the unknown QFI; for example, the PDU Session Resource Release Command message or PDU Session Resource Modify Request message may be transmitted by an AMF. As described above, the first tunnel endpoint 501 may rely on this message as a confirmation that the GTP Error Indication 530 has been processed as intended by the second tunnel endpoint 502.

[0079] The aspects of the present disclosure have mainly been described above with reference to a few embodiments. However, as is readily appreciated by a person skilled in the art, other embodiments than the ones disclosed above are equally possible within the scope of the invention, as defined by the appended patent claims.

Claims

CLAIMS1. A method (300) performed by a first tunnel endpoint (501), the method comprising: maintaining (301) a General Packet Radio System Tunnelling Protocol User Plane, GTP-U, tunnel (250) to a second tunnel endpoint (502); receiving (302) from the second tunnel endpoint a G-PDU message (520), which includes a GTP-U header (521) followed by an encapsulated T-PDU data packet (522), wherein the GTP-U header includes: a tunnel endpoint identifier, TEID, identifying a PDU Session, and a QoS Flow Identifier, QFI, identifying which QoS Flow within the PDU Session the G-PDU message relates to; determining (304) that the QFI is unknown to the first tunnel endpoint; and in response to identifying the unknown QFI, transmitting (305) to the second tunnel endpoint a GTP Error Indication (530), which indicates the TEID and the unknown QFI.

2. The method (300) of claim 1, wherein the QFI shall be determined (304) to be unknown if it is absent from a local table (216, 236) of QFIs which are active within the PDU session.

3. The method (300) of claim 2, wherein maintaining (301) the GTP-U tunnel comprises updating (301.1) the local table (216, 236) based on PDU Session configuration messages (510) received from the second tunnel endpoint.

4. The method (300) of any of claims 1 to 3, further comprising: assessing (303) whether the TEID is valid, wherein the step of determining (304) is performed only if the TEID has been found valid.

5. The method (300) of any of claims 1 to 4, further comprising: receiving (306) from the second tunnel endpoint a PDU Session Resource Notify message (540) indicating release of the unknown QFI; or receiving (306) a PDU Session Resource Release Command message or a PDU Session Resource Modify Request message concerning release of the unknown QFI.

6. A method (400) performed by a second tunnel endpoint (502), the method comprising: maintaining (401) a General Packet Radio System Tunnelling Protocol User Plane, GTP-U, tunnel to a first tunnel endpoint (501); transmitting (402) to the first tunnel endpoint a G-PDU message (520), which includes a GTP-U header (521) followed by an encapsulated T-PDU data packet (522), wherein the GTP-U header includes: a tunnel endpoint identifier, TEID, identifying a PDU Session, and a QoS Flow Identifier, QFI, identifying which QoS Flow within the PDU Session the G-PDU message relates to; receiving (403) from the first tunnel endpoint a GTP Error Indication (530), which indicates the TEID and the QFI; and in response to receiving the GTP Error Indication, releasing (404) the QFI within the PDU Session.

7. The method (400) of claim 6, wherein releasing (404) comprises erasing (404.1) the indicated QFI from a local table (216, 236) of QFIs which are active within the PDU session.

8. The method (400) of claim 7, wherein maintaining (401) the GTP-U tunnel comprises updating (401.1) the local table (216, 236) based on PDU Session configuration messages transmitted to the first tunnel endpoint and / or based on the second tunnel endpoint’s PDU Session configuration decisions.

9. The method (400) of any of claims 6 to 8, further comprising: transmitting (405) to the first tunnel endpoint a PDU Session Resource Notify message (540) indicating release of the indicated QFI; or ordering transmission (405) of a PDU Session Resource Release Command message or a PDU Session Resource Modify Request message concerning release of the unknown QFI.

10. The method (300, 400) of any of the preceding claims, wherein the first tunnel endpoint (501) is an access network node (110) and the second tunnel endpoint (502) is a core network node (108).

11. The method (300, 400) of any of the preceding claims, wherein the first tunnel endpoint is a core network node (108) and the second tunnel endpoint is an access network node (110).

12. The method (300, 400) of any of the preceding claims, wherein the GTP-U header (521) of the G-PDU messages includes an Extension Header field (521.1) containing the QFI.

13. The method (300, 400) of any of the preceding claims, wherein the GTP Error Indication (530) includes a three-bit information element by which the identified unknown QFI is indicated.

14. A first tunnel endpoint (501) comprising processing circuitry configured to: maintain a General Packet Radio System Tunnelling Protocol User Plane, GTP-U, tunnel (250) to a second tunnel endpoint (502); receive from the second tunnel endpoint a G-PDU message (520), which includes a GTP-U header (521) followed by an encapsulated T-PDU data packet (522), wherein the GTP-U header includes: a tunnel endpoint identifier, TEID, identifying a PDU Session, and a QoS Flow Identifier, QFI, identifying which QoS Flow within the PDU Session the G-PDU message relates to; determine that the QFI is unknown to the first tunnel endpoint; and in response to identifying the unknown QFI, transmit to the second tunnel endpoint a GTP Error Indication (530), which indicates the TEID and the unknown QFI.

15. A second tunnel endpoint (502) comprising processing circuitry configured to: maintain a General Packet Radio System Tunnelling Protocol User Plane, GTP-U, tunnel to a first tunnel endpoint (501); transmit to the first tunnel endpoint a G-PDU message (520), which includes a GTP-U header (521) followed by an encapsulated T-PDU data packet (522), wherein the GTP-U header includes: a tunnel endpoint identifier, TEID, identifying a PDU Session, and a QoS Flow Identifier, QFI, identifying which QoS Flow within the PDU Session the G-PDU message relates to;receive from the first tunnel endpoint a GTP Error Indication (530), which indicates the TEID and the QFIs; and in response to receiving the GTP Error Indication, release the QFI within the PDU Session.

16. A computer program, comprising instructions that, when executed by processing circuitry (202, 222), cause the processing circuitry to carry out the method according to any of claims 1 to 13.

17. A computer-readable medium storing the computer program of claim 16.

Images