Data packet handling in a wireless communication network
A flexible QoS model in wireless communication systems addresses the inefficiency of separate QoS flows by differentiating data flows within a single QoS flow, reducing signaling overhead and enhancing user experience through optimized resource allocation.
Patent Information
- Application Number
- PCT/EP2024/083622
- Authority / Receiving Office
- WO · WO
- Patent Type
- Applications
- Current Assignee / Owner
- Priority Date
- 2024-10-16
- Filing Date
- 2024-11-26
- Publication Date
- 2025-08-07
AI Technical Summary
Existing wireless communication systems face increased signaling overhead due to the establishment and maintenance of separate QoS flows for different data flows with varying traffic characteristics, leading to inefficient resource management and user experience.
Implementing a flexible QoS model that differentiates and adapts to multiple data flows within a single QoS flow by using differentiated handling and mapping techniques, such as Packet Detection Rules and Packet Marking, to apply specific QoS characteristics to individual data flows within a non-GBR QoS flow.
This approach reduces signaling overhead and enhances application and user experience by optimizing resource allocation and handling specific data flows within a single QoS flow, thereby improving network efficiency.
Smart Images

Figure EP2024083622_07082025_PF_FP_ABST
Abstract
Description
DATA PACKET HANDLING IN A WIRELESS COMMUNICATIONNETWORKTECHNICAL FIELD
[0001] The subject matter disclosed herein relates generally to the field of managing (e.g., processing, transmitting, receiving, obtaining, outputting) data packets. In particular, this document defines a first network entity and a method thereof.BACKGROUND
[0002] A wireless communications system may include one or multiple network communication devices, which may be otherwise known as network equipment (NE), supporting wireless communications for one or multiple user communication devices, which may be otherwise known as user equipment (UE), or other suitable terminology. The wireless communications system may support wireless communications with one or multiple user communication devices by utilizing resources of the wireless communication system (e.g., time resources (e.g., symbols, slots, subframes, frames, or the like) or frequency resources (e.g., subcarriers, carriers, or the like). Additionally, the wireless communications system may support wireless communications across various radio access technologies including third generation (3G) radio access technology, fourth generation (4G) radio access technology, fifth generation (5G) radio access technology, among other suitable radio access technologies beyond 5G (e.g., sixth generation (6G)).SUMMARY
[0003] An article “a” before an element is unrestricted and understood to refer to “at least one” of those elements or “one or more” of those elements. The terms “a,” “at least one,” “one or more,” and “at least one of one or more” may be interchangeable. As used herein, including in the claims, “or” as used in a list of items (e.g., a list of items prefaced by a phrase such as “at least one of’ or “one or more of’ or “one or both of’) indicates an inclusive list such that, for example, a list of at least one of A, B, or C means A or B or C or AB or AC or BC or ABC (i.e., A and B and C). Also, as used herein, the phrase “based on” shall not be construed as a reference to a closed set of conditions. For example, an examplestep that is described as “based on condition A” may be based on both a condition A and a condition B without departing from the scope of the present disclosure. In other words, as used herein, the phrase “based on” shall be construed in the same manner as the phrase “based at least in part on. Further, as used herein, including in the claims, a “set” may include one or more elements.
[0004] A wireless communication system (also referred to as a wireless communication network or simply a wireless network), such as, a 5G system (5GS) or a 6G system (6GS), may support higher throughput (e.g., bitrate), as well as greater network flexibility compared to other wireless communication systems, such as a 4G system. For example, in a 5GS, service providers can relocate (e.g., transfer, migrate, move) functions, applications, services, or the like between different networks, clouds, or the like environments. Furthermore, 5GS allows service providers to respond to changing demands and to implement different deployment strategies without interrupting services.
[0005] The main Quality of Service (QoS) model in 5GS is based on QoS flows. The QoS flow is the finest granularity of QoS differentiation in 5GS. Each QoS flow is associated with a type. The type may indicate that a guaranteed flow bit rate is required (e.g., a Guaranteed Bit Rate (GBR) QoS flow). Alternatively, the type may indicate that guaranteed flow bit rate is not required (e.g., non-GBR QoS flow). For a Packet Data Unit (PDU) Session, there may be at least a default QoS flow established during a PDU Session establishment and such default QoS flow may be a non-GBR QoS flow. Additionally, a dedicated QoS flow may be established within (e.g., for) the PDU Session, for example, for a data flow, such as a Service Data Flow (SDF).
[0006] An SDF may represent traffic (e.g., data) for an application session that may be characterized (e.g., defined, identified) by specific packet header parameters (e.g., a source Internet Protocol (IP) address, a destination IP address, a part number, a device identifier or an Ethernet addresses, etc.). An SDF filter may include a set of one or more packet flow header parameter values or ranges that may be used to identify one or more of packet flows (e.g., IP or Ethernet packet flows) constituting the SDF. For example, if a customer uses (e.g., utilizes, engages with) multiple different application servers for an offered application service, then the network may detect that downlink (DL) packets having a source IPaddress / prefix from one of the application servers is associated with the customer and can be identified as one or more SDFs. The network can assign one or more separate QoS flows to these SDFs. The terms SDF, data flow, traffic flow, sub-QoS flow, service flow, IP flow and / or application flow may be used interchangeably hereinafter.
[0007] A first network entity for wireless communication is described. The first network entity may be configured to, capable of, or operable to perform one or more operations as described herein. For example, the first network entity may include: at least one memory; and at least one processor coupled with the at least one memory and configured to cause the first network entity to: receive a DL data packet comprising an indication of a data flow; determine, based on the indication of the data flow and first configuration information, that the DL data packet is from the data flow in a QoS flow, wherein the first configuration information comprises a mapping between the indication of the data flow and a QoS parameter of the data flow; configure a data radio bearer (DRB) of the QoS flow according to the QoS parameter of the data flow; and transmit, to a UE, the DL data packet via the DRB of the QoS flow for the data flow.
[0008] A method performed by a first network entity is described. The method comprising: receiving a DL data packet comprising an indication of a data flow; determining, based on the indication of the data flow and first configuration information, that the DL data packet is from the data flow in a QoS flow, wherein the first configuration information comprises a mapping between the indication of the data flow and a QoS parameter of the data flow; configuring a DRB of the QoS flow according to the QoS parameter of the data flow; and transmitting, to a UE, the DL data packet via the DRB of the QoS flow for the data flow.
[0009] A processor for wireless communication is described. The processor may be configured to, capable of, or operable to receive a DL data packet comprising an indication of a data flow; determine, based on the indication of the data flow and first configuration information, that the DL data packet is from the data flow in a QoS flow, wherein the first configuration information comprises a mapping between the indication of the data flow and a QoS parameter of the data flow; configure a DRB of the QoS flow according to the QoSparameter of the data flow; and transmit, to a UE, the DL data packet via the DRB of the QoS flow for the data flow.BRIEF DESCRIPTION OF THE DRAWINGS
[0010] Figure 1 illustrates an example of a wireless communications system in accordance with aspects of the present disclosure.
[0011] Figure 2 illustrates an example of a framework for a QoS model in accordance with aspects of the present disclosure.
[0012] Figure 3 illustrates an example of a process flow for QoS establishment in accordance with aspects of the present disclosure.
[0013] Figure 4 illustrates a signalling diagram in accordance with aspects of the present disclosure.
[0014] Figure 5 illustrates an example of a framework for classifying data flow for a QoS model in accordance with aspects of the present disclosure.
[0015] Figure 6 illustrates an example of a UE in accordance with aspects of the present disclosure.
[0016] Figure 7 illustrates an example of a processor in accordance with aspects of the present disclosure.
[0017] Figure 8 illustrates an example of a NE in accordance with aspects of the present disclosure.
[0018] Figure 9 illustrates a flowchart of a method performed by a NE in accordance with aspects of the present disclosure.DETAILED DESCRIPTION
[0019] A QoS flow may include one or more data flows, where each data flow may be associated with a latency requirement (e.g., time sensitivity, time criticality) based on a data type associated with the data flow (i.e., a type of data provided by the data flow). Examples of data type may include, but is not limited to, audio streaming, video streaming, Simple Mail Transfer Protocol (SMTP) traffic for email exchange, Transmission Control Protocol(TCP) traffic for email exchange, or non-streaming Hypertext Transfer Protocol (HTTP) traffic (e.g., mapped on a same non-GBR QoS flow), or a combination thereof.
[0020] Some wireless communication systems may establish (e.g., setup) and maintain separate QoS flows for different data flows. For example, in some cases, separate QoS flows may be established and maintained for different data flows that have different traffic characteristics, resulting in a higher number of QoS flows. Traffic characteristics may include periodicity, data rate, maximum data burst volume changes. Additionally, QoS flow-related procedures, such as a QoS flow establishment procedure, a QoS flow modification procedure, and / or a QoS flow release procedure result in a PDU session modification procedure. The PDU session modification procedure may include N2 Session Management (SM) signalling (e.g., between a RAN node, such as a base station, and a Session Management Function (SMF)), N1 SM signalling (e.g., between a UE and an SMF), and N4 signalling (e.g., between an SMF and one or more User Plane Functions (UPFs)). Accordingly, establishment and maintenance (e.g., modification, release) of separate QoS flows for different data flows yields increased signalling overhead.
[0021] Examples described herein generally relate to data traffic differentiation for different SDFs associated with a same QoS flow. The data traffic differentiation may be referred to as flexible data traffic differentiation or adaptive data traffic differentiation hereinafter. The QoS flow may be a non-GBR QoS flow.
[0022] Aspects of the present disclosure are described in the context of a wireless communications system.
[0023] Figure 1 illustrates an example of a wireless communications system 100 in accordance with aspects of the present disclosure. The wireless communications system 100 may include one or more NE 102, one or more UE 104, and a core network (CN) 106. The wireless communications system 100 may support various radio access technologies. In some implementations, the wireless communications system 100 may be a 4G network, such as an LTE network or an LTE- Advanced (LIE- A) network. In some other implementations, the wireless communications system 100 may be a NR network, such as a 5G network, a 5G- Advanced (5G-A) network, or a 5G ultrawideband (5G-UWB) network. In other implementations, the wireless communications system 100 may be a combinationof a 4G network and a 5G network, or other suitable radio access technology including Institute of Electrical and Electronics Engineers (IEEE) 802.11 (Wi-Fi), IEEE 802.16 (WiMAX), IEEE 802.20. The wireless communications system 100 may support radio access technologies beyond 5G, for example, 6G. Additionally, the wireless communications system 100 may support technologies, such as time division multiple access (TDMA), frequency division multiple access (FDMA), or code division multiple access (CDMA), etc.
[0024] The one or more NE 102 may be dispersed throughout a geographic region to form the wireless communications system 100. One or more of the NE 102 described herein may be or include or may be referred to as a network node, a base station, a network element, a network function, a network entity, a radio access network (RAN), a NodeB, an eNodeB (eNB), a next-generation NodeB (gNB), or other suitable terminology. An NE 102 and a UE 104 may communicate via a communication link, which may be a wireless or wired connection. For example, an NE 102 and a UE 104 may perform wireless communication (e.g., receive signalling, transmit signalling) over a Uu interface.
[0025] An NE 102 may provide a geographic coverage area for which the NE 102 may support services for one or more UEs 104 within the geographic coverage area. For example, an NE 102 and a UE 104 may support wireless communication of signals related to services (e.g., voice, video, packet data, messaging, broadcast, etc.) according to one or multiple radio access technologies. In some implementations, an NE 102 may be moveable, for example, a satellite associated with a non-terrestrial network (NTN). In some implementations, different geographic coverage areas associated with the same or different radio access technologies may overlap, but the different geographic coverage areas may be associated with different NE 102.
[0026] The one or more UE 104 may be dispersed throughout a geographic region of the wireless communications system 100. A UE 104 may include or may be referred to as a remote unit, a mobile device, a wireless device, a remote device, a subscriber device, a transmitter device, a receiver device, or some other suitable terminology. In some implementations, the UE 104 may be referred to as a unit, a station, a terminal, or a client, among other examples. Additionally, or alternatively, the UE 104 may be referred to as anInternet-of-Things (loT) device, an Internet-of-Everything (loE) device, or machine-type communication (MTC) device, among other examples.
[0027] A UE 104 may be able to support wireless communication directly with other UEs 104 over a communication link. For example, a UE 104 may support wireless communication directly with another UE 104 over a device-to-device (D2D) communication link. In some implementations, such as vehicle-to-vehicle (V2V) deployments, vehicle-to-everything (V2X) deployments, or cellular-V2X deployments, the communication link may be referred to as a sidelink. For example, a UE 104 may support wireless communication directly with another UE 104 over a PC5 interface.
[0028] An NE 102 may support communications with the CN 106, or with another NE 102, or both. For example, an NE 102 may interface with other NE 102 or the CN 106 through one or more backhaul links (e.g., SI, N2, N2, or network interface). In some implementations, the NE 102 may communicate with each other directly. In some other implementations, the NE 102 may communicate with each other or indirectly (e.g., via the CN 106. In some implementations, one or more NE 102 may include subcomponents, such as an access network entity, which may be an example of an access node controller (ANC). An ANC may communicate with the one or more UEs 104 through one or more other access network transmission entities, which may be referred to as a radio heads, smart radio heads, or transmission-reception points (TRPs).
[0029] The CN 106 may support user authentication, access authorization, tracking, connectivity, and other access, routing, or mobility functions. The CN 106 may be an evolved packet core (EPC), or a 5G core (5GC), which may include a control plane entity that manages access and mobility (e.g., a mobility management entity (MME), an access and mobility management functions (AMF)) and a user plane entity that routes packets or interconnects to external networks (e.g., a serving gateway (S-GW), a Packet Data Network (PDN) gateway (P-GW), or a user plane function (UPF)). In some implementations, the control plane entity may manage non-access stratum (NAS) functions, such as mobility, authentication, and bearer management (e.g., data bearers, signal bearers, etc.) for the one or more UEs 104 served by the one or more NE 102 associated with the CN 106.
[0030] The CN 106 may communicate with a packet data network over one or more backhaul links (e.g., via an SI, N2, N2, or another network interface). The packet data network may include an application server. In some implementations, one or more UEs 104 may communicate with the application server. A UE 104 may establish a session (e.g., a protocol data unit (PDU) session, or the like) with the CN 106 via an NE 102. The CN 106 may route traffic (e.g., control information, data, and the like) between the UE 104 and the application server using the established session (e.g., the established PDU session). The PDU session may be an example of a logical connection between the UE 104 and the CN 106 (e.g., one or more network functions of the CN 106).
[0031] In the wireless communications system 100, the NEs 102 and the UEs 104 may use resources of the wireless communications system 100 (e.g., time resources (e.g., symbols, slots, subframes, frames, or the like) or frequency resources (e.g., subcarriers, carriers)) to perform various operations (e.g., wireless communications). In some implementations, the NEs 102 and the UEs 104 may support different resource structures. For example, the NEs 102 and the UEs 104 may support different frame structures. In some implementations, such as in 4G, the NEs 102 and the UEs 104 may support a single frame structure. In some other implementations, such as in 5 G and among other suitable radio access technologies, the NEs 102 and the UEs 104 may support various frame structures (i.e., multiple frame structures). The NEs 102 and the UEs 104 may support various frame structures based on one or more numerologies.
[0032] One or more numerologies may be supported in the wireless communications system 100, and a numerology may include a subcarrier spacing and a cyclic prefix. A first numerology (e.g., / r=0) may be associated with a first subcarrier spacing (e.g., 15 kHz) and a normal cyclic prefix. In some implementations, the first numerology (e.g., / r=0) associated with the first subcarrier spacing (e.g., 15 kHz) may utilize one slot per subframe. A second numerology (e.g., / r=l) may be associated with a second subcarrier spacing (e.g., 30 kHz) and a normal cyclic prefix. A third numerology (e.g., / r=2) may be associated with a third subcarrier spacing (e.g., 60 kHz) and a normal cyclic prefix or an extended cyclic prefix. A fourth numerology (e.g., / r=3) may be associated with a fourth subcarrier spacing(e.g., 120 kHz) and a normal cyclic prefix. A fifth numerology (e.g., / r=4) may be associated with a fifth subcarrier spacing (e.g., 240 kHz) and a normal cyclic prefix.
[0033] A time interval of a resource (e.g., a communication resource) may be organized according to frames (also referred to as radio frames). Each frame may have a duration, for example, a 10 millisecond (ms) duration. In some implementations, each frame may include multiple subframes. For example, each frame may include 10 subframes, and each subframe may have a duration, for example, a 1 ms duration. In some implementations, each frame may have the same duration. In some implementations, each subframe of a frame may have the same duration.
[0034] Additionally or alternatively, a time interval of a resource (e.g., a communication resource) may be organized according to slots. For example, a subframe may include a number (e.g., quantity) of slots. The number of slots in each subframe may also depend on the one or more numerologies supported in the wireless communications system 100. For instance, the first, second, third, fourth, and fifth numerologies (i.e., / r=0, jU=l , / r=2, jU=3, / r=4) associated with respective subcarrier spacings of 15 kHz, 30 kHz, 60 kHz, 120 kHz, and 240 kHz may utilize a single slot per subframe, two slots per subframe, four slots per subframe, eight slots per subframe, and 16 slots per subframe, respectively. Each slot may include a number (e.g., quantity) of symbols (e.g., OFDM symbols). In some implementations, the number (e.g., quantity) of slots for a subframe may depend on a numerology. For a normal cyclic prefix, a slot may include 14 symbols. For an extended cyclic prefix (e.g., applicable for 60 kHz subcarrier spacing), a slot may include 12 symbols. The relationship between the number of symbols per slot, the number of slots per subframe, and the number of slots per frame for a normal cyclic prefix and an extended cyclic prefix may depend on a numerology. It should be understood that reference to a first numerology (e.g., / r=0) associated with a first subcarrier spacing (e.g., 15 kHz) may be used interchangeably between subframes and slots.
[0035] In the wireless communications system 100, an electromagnetic (EM) spectrum may be split, based on frequency or wavelength, into various classes, frequency bands, frequency channels, etc. By way of example, the wireless communications system 100 may support one or multiple operating frequency bands, such as frequency range designationsFR1 (410 MHz - 7.125 GHz), FR2 (24.25 GHz - 52.6 GHz), FR3 (7.125 GHz - 24.25 GHz), FR4 (52.6 GHz - 114.25 GHz), FR4a or FR4-1 (52.6 GHz - 71 GHz), and FR5 (114.25 GHz - 300 GHz). In some implementations, the NEs 102 and the UEs 104 may perform wireless communications over one or more of the operating frequency bands. In some implementations, FR1 may be used by the NEs 102 and the UEs 104, among other equipment or devices for cellular communications traffic (e.g., control information, data). In some implementations, FR2 may be used by the NEs 102 and the UEs 104, among other equipment or devices for short-range, high data rate capabilities.
[0036] FR1 may be associated with one or multiple numerologies (e.g., at least three numerologies). For example, FR1 may be associated with a first numerology (e.g., / r=0), which includes 15 kHz subcarrier spacing; a second numerology (e.g., / r=l), which includes 30 kHz subcarrier spacing; and a third numerology (e.g., / r=2), which includes 60 kHz subcarrier spacing. FR2 may be associated with one or multiple numerologies (e.g., at least 2 numerologies). For example, FR2 may be associated with a third numerology (e.g., / r=2), which includes 60 kHz subcarrier spacing; and a fourth numerology (e.g., / r=3), which includes 120 kHz subcarrier spacing.
[0037] Figure 2 illustrates an example of a framework for a QoS model 200 in accordance with aspects of the present disclosure.
[0038] The QoS model 200 may include a PDU session 260, which may be established (e.g., setup) between a UE 210 and an anchor UPF 225, which may be examples of corresponding UE and NE as described herein. The anchor UPF 225 may be a designated node that "anchors" a user’s data session. The UPF 225 may be configured to, capable of, or operable to assign an IP address and IP configuration for the UE 210, and provide (e.g., output, transmit, forward) one or more of the IP address and IP configuration to the UE 210. For example, the UPF 225 may assign and provide the IP address and the IP configuration to the UE 210 based on (e.g., using, according to) the PDU session 260.
[0039] The PDU session 260 comprises at least one QoS flow 264 between the UE 210 and the UPF 225. The at least one QoS flow 264 may comprise a default QoS flow 264. The default QoS flow may be automatically assigned to a user session when the UE 210 connects to the network. In some examples, there can be one or more additional QoS flowsfor specific data flows. The PDU session 260 comprises an N3 tunnel 262 between the (R)AN 215 (or RAN node) and the anchor UPF 225. The N3 tunnel 262 may be a General Packet Radio Service (GPRS) Tunneling Protocol - User plane (GTP-U) tunnel. The N3 tunnel 262 may be a single N3 tunnel 262 for the PDU session 260.
[0040] The UE 210 and a (R)AN node 215 may configured to, capable of, or operable to establish a first DRB 266. For example, the UE 210 and the (R)AN node 215 may establish the first DRB 266 over a radio link (e.g., communication link, communication channel). The (R)AN node 215 may be an example of corresponding NE as described herein with reference to Figure 1. One or more QoS flows can be mapped to a single DRB. For example, the (R)AN node 215 may be configured to, capable of, or operable to map the QoS flow 264 to the first DRB 266.
[0041] The UPF 225 may be configured to, capable of, or operable to perform packet detection and mapping to the QoS flow 264. Additionally, the UPF 225 may configured to, capable of, or operable to perform N3 marking (e.g., including one or more indications in an N3 tunnel header). The N3 marking may relate to information for the network to apply a QoS.
[0042] In the example of Figure 2, a first application server 252 and a second application server 254 may each be configured to, capable of, or operable to provide an application data flow to a first application 256 and a second application 258 associated with the UE 210 (e.g., stored at the UE 210, executing at the UE 210, or both), respectively via the QoS flow 264.
[0043] Figure 3 illustrates an example of a process flow 300 for QoS establishment in accordance with aspects of the present disclosure. In the example of Figure 3, the process flow 300 may be for establishing (e.g., setting up) a QoS flow. The process flow 300 may implement aspects (e.g., embodiments, features) of the wireless communication system 100, or may be implemented by aspects of the wireless communication system 100. For example, the process flow 300 may illustrate operations between a UE 310, a RAN 315, an SMF 320, an AMF 322, a UPF 325, a Policy Control Function (PCF) 330, and an Application Function (AF) 340, which may be examples corresponding UE and NE described herein. In the following description of the process flow 30, the operationsbetween the one or more of the UE 310, the RAN 315, the SMF 320, the AMF 322, the UPF 325, the PCF 330, and the AF 340 may be transmitted and / or received in a different order than the example order shown, or the operations performed by the one or more of the UE 310, the RAN 315, the SMF 320, the AMF 322, the UPF 325, the PCF 330, and the AF 340 may be performed in different orders or at different times than the example order shown. Some operations may also be omitted from the process flow 300, and other operations may be added to the process flow 300.
[0044] In the example of Figure 3, in response to (e.g., if, based on) the SMF 320 and / or the PCF 330 determining or identifying (e.g., based on received information) that a specific data flow requires a QoS flow different from a default QoS flow, the SMF 320 and / or the PCF 330 may trigger a QoS establishment procedure, for example, to establish a dedicated QoS flow for the specific traffic flow. The terms SDF, data flow, traffic flow, sub-QoS flow, service flow, IP flow and / or application flow may be used interchangeably herein.
[0045] At step 371, the AF 340 may determine and output (e.g., transmit) one or more QoS requirements for a data flow associated with a specific service to the PCF 330. The one or more QoS requirements for the data flow associated with a specific service may be traffic requirements for an IP flow (5-tuple). The traffic requirements may comprise at least one of a packet delay or a data rate. In some examples, the specific service may be at least one of: video streaming, audio streaming, multimedia call (e.g., video call). The AF 340 may provide information for identifying the data flow (e.g. 5-tuple of IP packets or an application identifier) and classify (e.g., assign, define) the data flow characteristics (e.g., one or more traffic QoS requirements, such as a packet delay, a packet error rate, or a priority). In some examples, this provisioning of identification and classification information may be referred to as AF-requested QoS influence on the data flow. The data flow identification and associated QoS characteristics may be pre-configured, for example, in the PCF 330 or a Unified Data Repository (UDR).
[0046] At step 372, the PCF 330 may determine (e.g., derive) one or more Policy Control and Charging (PCC) rules for the data flow (e.g., an SDF), where a PCC rule may include (e.g., identify) the specific QoS requirements for the data flow. The PCC rule maycomprise a QoS rule. The QoS rule may comprise traffic classification information, information for mapping to the QoS flow, or QoS parameters. The PCC rule may include the data flow identification and corresponding QoS characteristics. The data flow identification may comprise a traffic detection filter, such as an IP packet filter (e.g., a 5- Tuple containing a source IP address, a source port, a destination IP address, a destination port, and / or a transport protocol). A 5-tuple may uniquely identify a User Datagram Protocol (UDP) session or a Transmission Control Protocol (TCP) session. The corresponding QoS characteristic may be a pre-defined 5G QoS Identifier (5 QI) or a QoS Flow Identifier (QFI), which may be associated with or specific to a network operator. The PCF 330 may provide (e.g., transmit, signal) the one or more PCC rules to the SMF 320. Additionally, or alternatively, the PCF 330 may provide (e.g., transmit, signal) one or more QoS rules to the SMF 320. One or more of the PCC rules or the QoS rules may comprise QoS requirements for 5-tuple. The QoS requirements may be PDU set related QoS requirements.
[0047] In some examples, the one or more PCC rules may be pre-configured at the SMF 320 and can be activated or deactivated by the PCF 330.
[0048] At step 373, the SMF 320 may determine a QoS profile of the QoS flow (e.g., one or more of a Packet Delay Budget (PDB) or a Packet Error Rate (PER)). The SMF 320 may establish the dedicated QoS flow according to the one or more PCC rules. The SMF 320 may provide (e.g., transmit, signal) to the UPF 325 one or more N4 rules, including configuration information. The configuration may be for routing packets of the data flow to a QoS flow. The one or more N4 rules may include traffic detection rules (e.g., Packet Detection Rules (PDRs)) and packet handling policies that includes at least one of: a QoS Enforcement rule (QER), a Forwarding Action Rule (FAR), or a Usage Report Rule (URR).
[0049] Additionally, the SMF 320 may provide (e.g., transmit, signal, output) the QoS profile including the QoS requirements to the RAN 315. For example, the SMF 320 may output the QoS profile including the QoS requirements to the RAN 315 in an N2 SM container via the AMF 322.
[0050] At step 374, the UPF 325 may process (e.g., inspect, analyse) data packets received (e.g., obtained) from a first application 356 and a second application 358, anddetermine whether the data packets are associated with (e.g., belong) a QoS flow. The UPF 325 may route incoming DL packets (e.g., DL data packets) from the first application 356 and the second application 358 to a corresponding QoS flow. For example, the UPF 325 may route a first set of DL data packets received from the first application 356 to a first QoS flow and route a second set of DL data packet received from the second application 358 to a second QoS flow. The UPF 325 uses the PDRs, which are received in the N4 rules from the SMF 320, in order to determine the forwarding of the DL packets to a corresponding QoS flow. Each QoS flow may be associated with a QFI. The UPF 325 may include the QFI in each DL packet. The DL packet may be a PDU. The QFI may be included in a tunnel encapsulation header (e.g., a GTP-U packet header) used for a PDU session. For example, the first QoS flow may be identified by QFI-1 and the second QoS flow may be identified by QFI -2 in a GTP-U header of a corresponding DL packet. In some examples, there is a single GTP-U tunnel for the PDU session between the UPF 325 and the RAN 315.
[0051] At step 375, the RAN 315 may identify one or more DL data packets associated with (e.g., belonging to) a QoS flow, for example, based at least in part on a GTP-U marking, and handle the DL data packets according to QoS requirements of the QoS profile provided directly by the SMF 320, or via the AMF 322, at step 373. GTP-U marking may include information in a header of a GTP-U data packet corresponding to the QOS requirement of the QoS profile. The RAN 315 may establish two DRBs for each of the QoS flows, as shown in Figure 3, “DRB QoS flow 1” and “DRB QoS flow 2”. The RAN 315 may determine (or select) a DRB configuration based at least in part on one or more QoS characteristics for the QoS flow. The RAN 315 may decide the DRB configuration. A QoS characteristic may be a QoS parameter. For example, if a PER is less than or equal to a threshold a different Modulation and Coding Scheme (MSC) or different Radio Link Control (RLC) retransmissions may be configured for a corresponding DRB compared to a DRB that is associated with a PER that is greater than the threshold. By way of example, if a PER is low (e.g., 10'6) a different MSC or different RLC retransmissions may be configured for the DRB compared to a DRB for which the PER is high (e.g., 10'3).
[0052] Each QoS flow may be associated with a resource type. For example, the resource type may be at least one of: a non-GBR QoS flow, a GBR QoS flow, or a Delay- critical GBR QoS flow. In some examples, QoS characteristics, such as for 5G may contribute to setting node specific parameters for each QoS Flow (e.g., for 3GPP radio access link layer protocol configurations). For non-GBR QoS flows, the QoS characteristics may comprise at least one of: a default Priority Level (PL), PDB, or PER. In contrast to the non-GBR QoS flow, for a GBR QoS flow the QoS characteristics may comprise at least one of: one or more parameters from non-GBR flows; a Guaranteed Flow Bit Rate (GFBR) (e.g., for uplink (UL) and / or DL), a Maximum Flow Bit Rate (MFBR) (e.g., for uplink (UL) and / or DL), or a Maximum Burst Data Volume (MBDV).
[0053] The following parameters may apply for a PDU session level (or a network slice level): a session Aggregated Maximum Bit Rate (AMBR) (e.g., applicable to non-GBR QoS flows), a per UE Aggregate Maximum Bit Rate (UE-AMBR) (e.g., applicable to non- GBR QoS flows), and a per UE per Slice MBR (UE-Slice-MBR) (e.g., applicable to GBR and non-GBR QoS flows).
[0054] The AMF 322 may output (e.g., transmit, signal) the one or more QoS rules to the UE 310, for example, via the RAN 315 using an N1 SM container. The AMF 322 may output (e.g., transmit, signal) the QoS profile to the RAN 315 using an N2 SM container.
[0055] Table 1 is a table of “Standardized 5QI to QoS characteristics mapping” as described in clause 5.7.4 in 3GPP TS 23.501, vl8.3.0. Specifically for non-GBR QoS flows identified by 5QI 6, 7, 8, 9 or 10, as shown in Table 1 various traffic types or SDFs may be transmitted in the same QoS flow.Table 1 Standardized 5QI to QoS characteristics mapping
[0056] Different data flows like streaming (video or audio; in UL or DL), SMTP / TCP traffic for email exchange, or non-streaming HTTP traffic are mapped on the same non- GBR QoS flow. Such a non-GBR QoS flow may have a 5QI=6 / 7 and can be a part of the so called “Internet” PDU Session. The following use cases may apply:• For Software (SW) download application, a TCP packet may be dropped by the RAN (due to queue overflow). A TCP retransmission may apply and the SW download is received correctly at the end. The TCP re-transmission is not time critical for the sending and receiving application.• For a video calling application or video DL streaming application, a Real-time Transport Protocol (RTP) / QUICK packet may be dropped at RAN, wherein the reason may be due to DL transmission queue overflow, or due to reached maximum DL data rate limit like UE / Session AMBR. An RTP re-transmission may occur on the application layer, but the re-transmitted packet will be received at the receiver after an increase delay (e.g. more than 300ms) and the received retransmitted packet may not be valid / needed anymore.
[0057] Therefore, some data flows in the QoS flow may be more time critical for the application layer than other data flows.
[0058] One target for a more flexible QoS model in future communication systems is to avoid setting up and maintaining separate QoS flows for different data flows having different traffic characteristics. If a separate QoS flow is setup for each data flow, it would result in high number of QoS flows. Each QoS flow setup, modification and release procedures may result in a PDU Session modification procedure. The PDU Session modification procedure may comprise N2 SM signalling (between RNA and SMF), N1 SM signalling (between UE and SMF) and N4 signalling to one or more UPFs. In other words, the setup and maintenance of many QoS flows tends to result in increased signalling to setup and release the QoS flows.
[0059] Examples described herein generally relate to a flexible (or adaptive) DL traffic differentiation (e.g., for multiple different SDFs) within the same QoS flow (e.g. non-GBR QoS flow).
[0060] In the past, the wireless communication network establishes a new QoS flow for each data flow having a different QoS characteristic compared to an existing QoS flow. However, in case of multiple SDFs, the establishment of multiple QoS flows tends to result in increased C-plane signalling. For example, a PDU Session may comprise 10-15 different data flows user over a default PDU Session.
[0061] Examples described herein generally relate to differentiated handling of specific data flows inside a QoS flow. Differentiated handling of specific data flows inside the QoS flow may comprise the following functionalities on a single QoS flow:• identifying packets belonging to the specific data flow inside the QoS flow; and• applying one or more QoS characteristics on the radio link transmission which are different from the QoS characteristics of the remaining traffic of the QoS flow.
[0062] Examples described herein tend to avoid to establishment of a separate QoS flow for each data flow (e.g. SDF), as this tends to result in increased signalling and many different QoS flows maintenance. Examples described herein may differentiate a specific traffic / data flow (mapping to one or more SDFs) and apply different handling of the data flow in the RAN. This tends to achieve higher application experience and user experience.
[0063] The QoS characteristics may be identified by the QoS parameters such as priority level (PL), PDB or packet error rate (PER). For example, a QoS flow may be setup with 5QI = 6. For this QoS flow, the default parameter values may be PL = 60, PDB = 300ms and PER = 10'6which may apply to all data flows. However, there may be two specific data flow(s) for which a higher priority for transmission is required. Such data flows may be identified by a Packet Filter Set (PFS) used in a QoS rule sent to UE over N1 SM for UL packet identification and by a Packet Detection Rule (PDR) used on N4 interface. The identification of the data flows and the corresponding action based on QoS characteristics (e.g. higher PL value) can be performed in the SMF / PCF. For DL packet handling, the SMF provides the DL packet filter (e.g. PDR) and corresponding information to the UPF. The corresponding information may be at least one of:• A new parameter to be included in the N3 tunnel packet header (e.g., a packet marking parameter) having a scalar value (e.g. from 1 to 16). Each scalar value may be associated with a one or more QoS characteristics or parameter. The scalar values may be different from the values of the QFI or 5QI of a QoS flow. Each scalar value may be a Data Flow Identifier (DFI) or a Data Flow Category (DFC).• A standardized (or existing) QoS parameter having a value different from the value of the 5 QI of the QoS flow. In one example, the PL parameter of a specific data flow may be different from the PL of the QoS flow. For example, a QoS flow with QFI / 5QI = 6, the PL = 60, whereas the PL for a data flow corresponding to SDF1 may be 40 and the PL for or a data flow corresponding to SDF2 may be 50.
[0064] The UPF uses the provided parameter and includes it in the N3 tunnel packet header. In one example of considering the differentiated flow identifier parameter, the following may apply:
[0065] Example 1 : For SDF1 of a video streaming (e.g. 3rd party App video call) traffic, the SMF may determine a DFI = 2 which translates into one or more QoS parameters corresponding to PL = 40 and / or PER =10'4. The PDB is the PDB of the QoS flow (e.g. PDB = 300ms).
[0066] Example 2: For SDF2 of an audio streaming (e.g. Spotify streaming) traffic, the SMF may determine a DFI = 3 which translates into one or more QoS parameters corresponding to PL = 50 and / or PER =10'3. The PDB is the PDB of the QoS flow (e.g. PDB = 300ms).
[0067] In examples described herein, the network (e.g. SMF, PCF or together) may identify a policy or requirement that a certain data flow (e.g., SDF) is to be handled with QoS characteristics different from the QoS characteristics of the current / established QoS flow. The SMF / PCF may create at least one of the following information:• SDF identification information, e.g. PFS for UL packets and or PDR for DL packets;• SDF QoS handling information (or QoS enforcement / action information) different from the default QoS characteristics of the QoS flow. This tends to result in different packet handling of the data flow’s packets compared to the rest of the packets of the QoS flow; and• The SMF decides that the certain data flow (e.g., SDF) is transmitted over the QoS flow with lower QoS characteristics because currently there are sufficient network resources (e.g. in the current serving cell) so that the actual achieved QoS parameters / characteristics are higher than the QoS flow QoS characteristics.
[0068] For the DL transport, the SMF may determine to apply one of the following alternative solutions:• (R)AN-based solution: the SMF configures the RAN (e.g. via the N2 SM protocol) with at least one of the following information: a list of one or more data flows identified by a PDR and for each data flow, and one or more QoS parameters having values different from the default QFI / 5QI values of the QoS low.• UPF-based solution: the SMF configures the UPF (e.g. via the N4 interface) with information for differentiated data flow (e.g., SDF) identification information and corresponding data flow (e.g., SDF) packet handling information. In addition, the SMF may provide to the (Radio) Access Network ((R)AN) corresponding information, e.g. how many differentiated data flows are configured for this QoS flow, and for each differentiated data flow the data flow packet handling information. The data flow packet handling information may include the mapping information between the DFI (or DFC) parameter and QoS parameters value (such as indicated in Example 1 or Example 2 above).
[0069] The UPF (for the DL transport) may perform packet header inspection and upon identification of a configured PDR inserts a new parameter (e.g. DFI) in the N3 tunnel header corresponding to this PDR.
[0070] The (R)AN may be arranged to perform at least one of the following functions:• receiving information about one or more data flows (e.g. identified by a packet filter in RAN-based solution or by DFI in UPF-based solution) and associated with QoS parameters different from the QoS parameters of the QoS flow;• for the RAN-based solution, the (R)AN may receive a DL flow packet filter (e.g. PDR) and a QoS characteristic. The (R)AN inspects the DL data packets to determine which packets belong to the data flow identified by the DL flow packet filter (e.g. PDR); and• for the UPF-based solution, the (R)AN may receive (e.g. via the N2 SM information) packet handling information which may include the mapping information between the DFI parameter and QoS parameter value. The (R)AN may receive (e.g. via a user plane N3 tunnel) the DFI in a GTP-U tunnel header to identify the packet for differentiated handling on the radio interface.• The (R)AN may handle the data flow (or SDF) in a differentiated way according to at least one of: the (R)AN may setup more than one DRBs associated with the QoS flow, wherein a DRB can be associated with a data flow (e.g. identified by a DFI). In other words, the DRB is associated with a QFI and a DFI. This association may be sent to the UE. The Service Data Adaptation Protocol (SDAP) in the RAN and in the UE may support the mapping of the DRB to both QFI and DFI. For example, the (R)AN may setup a DRB1 for the QoS flow with the default QoS parameters, DRB2 for the differentiated SDF-1 with DFI=2 and DRB 3 for the differentiated SDF -2 with DFI = 3.The (R)AN may use a single DRB for the transmission of all data flows of the QoS flow, however, the RAN may apply a scheduling mechanism to handle packets of the differentiated SDF(s) in a different way corresponding to the QoS characteristics of the SDFs (e.g. higher / lower PL, or higher / lower DRB, or lower / higher PER).
[0071] The UE may process the SDAP to support the mapping of the DRB to both QFI and DFI.
[0072] Examples described herein generally relate to 5GS. Thus, the names of the interfaces, protocols, functions and entities used in the examples described herein are in relation to 5GS. It will be understood that the examples described herein are also applicable to any future communication system, e.g. 6G System (6GS). It will also be understood that a future communication system may use different names for the same or similar interfaces, protocols, functions and entities described herein. Thus, adapting the examples described herein for future communication systems may comprise translating the names of the interfaces, protocols, functions and entities. For example, the N2 interface may be translated to a general interface between the (R)AN and the Core Network (CN) control plane, the N3 interface may be translated to a general interface between the (R)AN and the CN user plane, the N4 interface may be translated to a general interface between the Session management entity in the control plane and the user plane entity, etc. Furthermore, an SMF or UPF from 5GS may be correspondingly mapped to 6G-SMF or 6G-UPF in 6GS.
[0073] The SMF or UPF may implement a Charging Trigger Function (CTF) functionality which generates charging events to be sent to the Charging Function (CHF). The charging events may be enhanced with a new charging record identifying that differentiated traffic handling within the QoS flow is applied and the corresponding data amount of the data flows for which the differentiated traffic handling applied. The CTF may use the Nchf services exposed by the CHF to send the charging event to the CHF.
[0074] Figure 4 illustrates a signalling diagram 400 for configuring differentiated data flow handling within a QoS flow in DL in accordance with aspects of the present disclosure. The signalling diagram 400 may show the signalling flow for the procedure.
[0075] The signalling diagram 400 illustrates the signals and messages between a UE 410, a (R)AN 415, an SMF 420, a UPF 425, a PCF 430, a Unified Data Management (UDM) / Unified Data Repository (UDR) 435, an AF 440 and an Application Server (AS) 445.
[0076] The AF 440 may be an entity which is authorized to communicate with the 5GC control plane by using exposed Application Programming Interfaces (APIs). The AS 445 is the media or context server which sends and receives the service / application data to / from the application in the UE 410 via the user plane. The AF 440 and AS 445 may be the same physical node implementing different functionality to interface with the 5GC control plane and with the 5GC user plane.
[0077] The signalling diagram 400 starts with step 471, in which the UE 410 may send a PDU Session establishment request to establish a new PDU session or PDU Session modification request to modify an existing PDU Session. This request may be included in the N1 Session Management (SM) container to the session management function (SMF).
[0078] There are several alternative how the network control plane (e.g. SMF 420 and / or PCF 430) may determine to enable the differentiated packet handling within the QoS flow. One alternative “Alt-1” is presented in steps 472a and 472b:
[0079] In step 472a, the SMF 420 may request the Session Management (SM) subscription data from the data subscription data repository (e.g. UDM / UDR 435). The“session” may be identified by a Data Network Name (DNN) or Network Slice Identifier (S-NSSAI).
[0080] In step 472b, for the requested session, the UDM / UDR 435 may store information indicating that differentiated data flow handling within the (default) QoS flow of the PDU Session may or should be enabled. In other words, differentiated traffic handling is enabled for the PDU Session. The UDM / UDR 435 sends a reply which may include an indication of enabled differentiated packet handling.
[0081] The UDM / UDR 435 may also indicate the type of SM subscription (e.g. for gold type session or subscriber) and based on this the SMF 420 / PCF 430 may determine to activate / enable the differentiated traffic handling with a QoS flow.
[0082] Another alternative for the network control plane (e.g. SMF 420 and / or PCF 430) to determine to enable the differentiated packet handling within the QoS flow is presented in alternative “Alt-2” as steps 373a to 373e:
[0083] In step 473a, the 5GS / 6GS may expose a service / network API to the AF 440 wherein the API may be used by an authorised AF to request for specific service requirements (e.g. QoS requirements). The AF 440, which is associated with an application server transmitting service data, can request the communication network to handle the service data flow (or the service packets) with specific QoS requirements. For example, the AF 440 may perform provisioning of traffic characteristics for 1) the UE 410 or group of UEs or 2) for the traffic associated with the application (e.g. identified by data flow identification). The AF 440 sends a request to the UDM / UDR 435 which may include data flow information and QoS / QoE requirements.
[0084] The AF 440 may send this information to a Network Exposure Function (NEF). The NEF may store this information at the UDR as application subscription data, or as UE subscription data. The AF 440 sends to the NEF a request to reserve resources using Nnef AF Request QoS Create request message, e.g. including among other parameters at least one of the following: a Generic Public Subscription Identifier (GPSI) or External Group ID, AF Identifier, Flow description(s) (e.g. data flow packet filters) or External Application Identifier, QoS reference or individual QoS parameters, Alternative ServiceRequirements, and DNN, S-NSSAI. Specifically, the parameters for the data flow identification and the QoS / QoE requirements may be relevant for examples described herein.
[0085] In step 473b, the SMF 420 may send a policy association establishment request to the PCF 430, e.g. including the UE ID e.g. Subscription Permanent Identifier (SUPI)), DNN, S-NSSAI and other parameters.
[0086] In step 473c, the PCF 430 may request SM subscription data from the UDR 435. The PCF 430 may request subscription data associated with the SUPI, or policy data or application data from the UDR 435 by using the signalling keys SUPI, DNN, or S-NSSAI.
[0087] In step 473d, the UDR 435 sends a reply message which may include a new indication that the differentiated packet handling within the QoS flow is enabled for the UE 410 or for the specific PDU Session.
[0088] In step 473e, the PCF 430 creates one or more PCC rules for the PDU Session and sends them to the SMF 420, which is considered as a policy association establishment reply message to step 373b. The PCC rule may contain at least one of: Flow Description information (e.g. a set of service data flow filters or 5-tuples), a QoS requirement, and an indication for enabled differentiated packet data flow handling within a QoS flow. The reply message may comprise at least one of: an data flow filter, QoS requirements, and an indication on differentiated packet handling.
[0089] In step 473f, the SMF 420 may complete the PDU Session establishment procedure by setting up a default QoS flow for any traffic associated with the PDU Session. The SMF 420 may determine to allocate the traffic of all data flow flows on the default QoS flow if the network is underloaded. For example, if the network is underloaded and the data / service flows with higher QoS characteristics can be successfully transmitted over a QoS flow with lower QoS characteristics. In other words, the SMF 420 may determine to not set up a separate QoS flow for the SDF-1 but transmit the SDF-1 on the QoS flow with lower QoS characteristics based on the current available network resources.
[0090] Step 473g, shows another alternative for the network control plane (e.g. SMF 420 and / or PCF 430) to determine to enable the differentiated packet handling within theQoS flow; which is labelled as “Alt-3”. In Alt-3, the AF 440 may send a request for QoS handling for the UE 410 or group of UEs. The request may include at least one of the parameters: a service flow (e.g., SDF) description information and the traffic characteristics information (e.g., the QoS or QoE requirements). The AF 440 may send such a request to the PCF 430 and the PCF 430 may create a PCC rule which is sent to the UE 410. The AF 440 may also send such a request to the SMF 420.
[0091] In step 474, the SMF 420 stores in the PDU Session (or SM) context as per QoS flow information at least one of: an indication that differentiated data flow handling for the QoS flow is enabled; identification information (e.g. packet filter) of one or more data flows and 3) the QoS characteristics / parameters applicable for each data flow.
[0092] If the QoS traffic characteristics of one or more data flows (e.g. SDF-1 and SDF-2) are different from the default QFI / 5QI (e.g., the default QoS characteristics) assigned to the current (default) QoS flow of the PDU Session, the SMF can decide to establish the default QoS only. Such decision in the SMF 420 may be determined based on at least one of:• the traffic characteristics of the different data flows being similar. For example, if the SDF-1 has requirement of PDB 250ms and the current QoS flow has a PDB of 300ms, the SMF 420 can decide to not establish a separate QoS flow for SDF-1, but the SDF-1 traffic is transmitted over the current QoS flow with PDB = 300ms; and• the SMF 420 being aware that currently the network is underloaded, or the load conditions in the cell where the UE 410 is located are low, so that the data packets of the QoS flow will experience better QoS characteristics than the QFI parameters of the QoS flow. For example, the PDB of the assigned QFI is 300ms (e.g. as in case of 5QI = 6), but the actual packet delay is less than 100ms because the cell load is low. So, even if the QoS characteristics of the SDF-1 indicate that the PDB should be 100ms, the SMF 420 may decide to not establish a separate QoS flow for SDF-1, but the SDF-1 traffic is transmitted over the current QoS flow with PDB = 300ms.
[0093] In step 475, the storing of the SM context that differentiated data flow handling for the QoS flow does not necessarily mean that the SMF 420 will activate the differentiated data flow handling in the user plane. The SMF 420 may first determine to let the data flow to be transmitted over the existing (e.g. default) QoS flow. Later, upon certain conditions, the SMF 420 may determine to handle the data flow in differentiated way.
[0094] For example, the SMF 420 may rely on an event or condition detected in the network. The possible events may be based on at least one of:• the RAN 415 condition, which can be e.g. signalled from RAN 415 to SMF 420; as described in step 475a.• the network conditions (including both RAN 415 and CN), e.g. SMF 420 subscribes for analytics with Network Data Analytics Function (NWDAF). For example, the SMF 420 may subscribe for network performance analytics for certain service experience (e.g. video or audio streaming service experience). The NWDAF may create the analytics based on information from the AF 440 or AS 445. When the QoE or service analytics indicate that the service does not meet the application requirements, or is close to not meet the application requirements, the SMF 420 may determine to activate the differentiated data flow handling as described in steps 476 or 477.• determining at UPF 425 / RAN 415 that the DL data rate limit (e.g. AMBR for the UE 410, or DL Session AMBR or slice Maximum Bit Rate (MBR)) is about to be reached. For example, if the current aggregated data rate is above 80% of the data rate limit. Thus, there is a high probability of dropping a DL packet at the UPF 425 or RAN 415. Upon such determination, the RAN 415 or UPF 425 may inform the SMF 420. The SMF 420 may determine to activate the differentiated packet handling as described in step 475c in order to avoid dropping of more critical data flows. For example, assigning a higher QoS characteristic (e.g. PL or PDB) to a more time critical packets for voice / video streaming application may result in avoiding packet dropping of this traffic but dropping packets of other traffic (e.g.background file download). The user may not notice the increased file download time but may notice an interruption of the voice / video streaming.
[0095] In step 475a, based on step 474, the SMF 420 may store in the SM context an information that differentiated data flow handling for the QoS flow is enabled. The SMF 420 may send a request to the (R)AN 415 to subscribe for a notification when packets of the QoS flow may be potentially dropped from the queue (or a potential queue threshold is reached) for one or more of the currently established QoS flows of the PDU Session. The potential buffer / queue overflow for the QoS flow may happen due to a cell load. Another example of notification event can be that the data rate limit (e.g. AMBR or MBR) reaches a certain threshold, wherein the SMF 420 may also indicate the threshold, e.g. 90%. The RAN 415 sends an N2 SM Notification for load condition. The SMF 420 may have optionally subscribed for notifications. The RAN capabilities are exchanged.
[0096] The (R)AN 415 may send a N2 SM Notification to the SMF 420 indicating certain for load condition. There may be multiple meanings for the indication sent to the SMF 420. The indication may indicate congestion in the RAN 415. The indication may indicate the status of a specific QoS flow, e.g., that packets of a QoS flow identified by a QFI, e.g. non-GBR flow, are about to be dropped or were already dropped.
[0097] The SMF 420 may also request the (R)AN 415 capabilities with respect to the differentiated data flow handling in the user plane within the existing QoS flow. Such a request may be explicit signalling for capability exchange, or the (R)AN 415 capabilities may be exchanged implicitly during the signalling in step 476a or 477a, e.g., the (R)AN 415 capabilities may be part of the result indication sent from (R)AN 415 to the SMF 420.
[0098] In step 475b, the (R)AN 415 may send a notification to the UPF 425 (e.g. via the user plane) indicating 1) a certain load condition in the cell where the UE 410 is located, or 2) that the buffer status is about to reach the certain threshold or buffered packets are about to be discarded. Such an indication may be transmitted in the N3 tunnel header of the UL packets. The UPF 425 is arranged to receive and detect that the indication is associated with the specific QoS flow (e.g. the UL packet marked with the indication is part of a specific QoS flow). The indication may have one or more values wherein eachvalue may indicate a different reason for radio congestion. The UPF 425 provides the indication to the SMF 420 via the N4 interface.
[0099] The UPF 425 may determine that the DL data rate limit (e.g. AMBR for the UE 410, or DL Session AMBR or slice MBR) is about to be reached., as described in step 475. The SMF 420 may have subscribed with UPF 425 for notifications and may have indicated the threshold level for sending a notification, e.g. the threshold may be 90%. The UPF 425 sends a notification to the SMF 420 indicating the reached threshold level.
[0100] In step 475c, based on input as described above, the SMF 420 may determine to handle the specific data flow in a differentiated way and the SMF 420 may perform at least one of the following procedures:• based on a trigger event from step 475 / 475a, the SMF 420 may determine to set up a new QoS flow for the traffic with different QoS characteristics. The SMF 420 may not set up a new QoS for the data flow from the start of the data flow, but the SMF 420 triggers the new QoS flow establishment based on certain network conditions.• the SMF 420 may activate the differentiated data flow handling in the user plane within the existing QoS flow and decide to apply the RAN-based solution.• the SMF 420 may activate the differentiated data flow handling in the user plane within the existing QoS flow and decide to apply the UPF-based solution.
[0101] The determination whether to apply the RAN-based solution or the UPF-based solution may be based on the capabilities of the (R)AN node 415 serving the UE 410 or PDU Session. For example, if the (R)AN 415 does not support packet inspection, the SMF 420 may determine to apply the UPF-based solution.
[0102] The SMF 420 may learn the (R)AN node 415 capabilities either during step 475a, step 476a, step 477a, or during step PDU Session establishment procedure when the (R)AN 415 replies to the establishment of the default QoS flow (e.g. before step 474).
[0103] Step 476 (including 476a and 476b) shows one possible solution denoted as (R)AN-based solution.
[0104] In step 476a, if the SMF 420 determines to apply the RAN-based solution, the SMF 420 determines to activate differentiated packet handling for a QoS flow in the RAN 415. The SMF 420 sends a notification message (e.g. N2 SM Notification container) via the AMF to inform the RAN 415 that one or more data flows within the QoS flow may need to be handled differently than the other packets. For this purpose, the SMF 420 includes a list of one or more data flow filters (e.g. the identification information for the data flow(s) which can be PDRs) and the associated QoS parameters for each data flow.
[0105] For example, for a non-GBR QoS flow, the QFI for the (default) QoS flow may be a 5QI = 6 with the QoS parameters PL = 60, PDB = 300ms, PER = 10'6, and a specific data flow of SDF-1 for video streaming for which the SMF 420 may assign the QoS parameters PL = 50, PDB = 100 ms and PER =10'4. The SMF 420 sends a N2 SM message with a new QoS profile for the (default) QoS flow and a new container information to identify the SDF-1 (e.g. called “sub-QoS flow” information) including the packet data flow filter of SDF-1 (e.g. 3-tuple or 5-tuple of IP header information) and the QoS parameters for SDF-1.
[0106] The (R)AN 415 may send a reply containing a result indication of the request. For example, the result indication can be positive, meaning that the (R)AN 415 acknowledges the reception and handling of the request; or the result indication can be negative, meaning that the (R)AN 415 rejects the request. If the result indication is negative, the SMF may terminate the procedure here and does not perform steps 477b, 477c, etc.
[0107] In step 476b, the RAN 415 receives and stores “sub-QoS flow” information associated with the QFI of the QoS flow, wherein this can be stored in the UE’s 410 access stratum context, specifically in the PDU Session context. Based on the QoS parameters of the sub-QoS flow, the RAN 415 determines whether to establish a new DRB corresponding to the QoS parameters of the sub-QoS flow. This is described further in step 478.
[0108] The RAN node 415 receives DL data packets associated with the QFI in the N3 tunnel header. The RAN node 415 determines that for this QFI there is “sub-QoS flow” information stored and the RAN node 415 determines to apply (deep) packed inspection of the DL packets of the QoS flow. The RAN node 415 applies the sub-QoS flow filter (e.g.PDR) received from the SMF 420 in step 476a. By this, the RAN 415 may determine whether the DL packet corresponds to the sub-QoS flow packet filter, and this whether differentiated handling needs to apply as described in step 478.
[0109] Another alternative procedure to step 476 is shown in the step 477 including steps 477a - 477c. This alternative is denoted as a UPF -based solution and the details are as follows:
[0110] In step 477a, if the SMF 420 determines to apply the UPF-based solution, the SMF 420 may derive a (sub-QoS) data flow packet handling information which may comprise at least a data flow identifier (DFI, or data flow category, DFC) parameter which represents (or maps) to the QoS characteristics of the (sub-QoS) data flow. For example, the DFI is a scalar value which is associated with corresponding QoS parameters different from the QoS parameters of the default 5QI. The SMF 420 sends a N2 SM notification message to the RAN 415 which may include at least one of: QFI, and list of DFI with mapping to QoS parameters.
[0111] Optionally a DFI = 0 associated with default 5 QI may be assigned; DFI = 1 associated with PL = 60, PDB = 200ms (and wherein the remaining QoS parameters of the default 5QI apply); DFI = 2 associated with PL = 50 (and wherein the remaining QoS parameters of the default 5 QI apply).
[0112] The SMF 420 sends to the (R)AN 415 a N2 SM information container which may comprise a QoS flow modification request with the following additional information for the QoS flow: a list of one or more DFIs and the associated QoS parameters applicable for the (sub-QoS) data flow. This information is associated with the QoS flow, i.e. with the QFI.
[0113] The (R)AN 415 may send a reply containing a result indication of the request. For example, the result indication can be positive, meaning that the (R)AN 415 acknowledges the reception and handling of the request; or the result indication can be negative, meaning that the (R)AN 415 rejects the request. If the result indication is negative, the SMF 420 may terminate the procedure here and does not perform steps 477b, 477c, etc.
[0114] In step 477b, conditional, if the RAN 415 has accepted the request in step 477a, the SMF 420 may continue with step 477b. The SMF 420 sends an N4 modification request to the UPF 425. The request may include a modification for a current QoS flow including one or more of the following parameters: DL packet flow filter (e.g. DL PDR) and associated QFI and DFI.
[0115] For example, the SMF 420 may send multiple PDRs to UPF 425 for the same QoS flow as follows:• PDR#1 corresponds to any (or “match all”) traffic for this PDU Session. The 3-tuple may be set with “asterix“ which means “match all” traffic, the (default) QFI = 6 and optionally DFI= 0.• For the PDR#2 corresponding to the packet filter of the SDF-1, the QFI=6 and DFI=1. The value of DFI=1 is explained in step 477a.• For the PDR#3 corresponding to the packet filter of the SDF-2, the QFI=6 and DFI=2. The value of DFI=2 is explained in step 477a.
[0116] In step 477c, the UPF 425 applies the PDRs and packet marking received in step 477b. The UPF 425 performs (deep) packet inspection of the DU traffic and for DU packets matching to any of the PDRs, the UPF 425 creates N3 tunnel packet header including the parameters QFI and DFI as per step 477b. The N3 tunnel packet header may be a GTP-U packet header.
[0117] For example, if a DU packet matches the PDR#2 corresponding to packet filter of the SDF-1, the UPF 425 includes in the N3 tunnel packet header the QFI=6 and DFI=1.
[0118] The RAN 415 is able to receive and process the enhanced N3 tunnel packet header, especially the combination of QFI and DFI. When the (R)AN 415 receives a DFI (e.g. in the user plane N3 tunnel), the RAN 415 determines that for this packet a differentiated handling on the radio interface is to be applied, wherein the QoS parameters apply corresponding to the DFI as received in step 477a. The RAN packet handling is described further in step 478.
[0119] After any of the steps 476 (including 476a - 476b) or 477 (including 477a - 477c) the following applies:
[0120] In step 478, the (R)AN 415 applies different strategies to transmit the DL packets of the (default) QoS flow and the DL packets of the sub-QoS flow identified by the DFI (or the sub-QoF flow packet filter). Based on the QoS parameters of the sub-QoS flow, the RAN 415 determines whether to establish a new DRB corresponding to the QoS parameters of the sub-QoS flow, or whether to use enhanced scheduling / queueing mechanism insider the single DRB for the QoS flow. The RAN 415 applies differentiated DL transmission (e.g. multiple DRBs) and may consider also sending DFI to the UE 410 and mapping rules in SDAP.
[0121] The (R)AN 415 may setup more than one DRBs associated with the QoS flow, wherein each DRB is associated with one or more sub-QoS data flows (e.g. identified by a DFIs). In other words, the DRB is associated with QFI and DFI; and this association may be sent to the UE 410 correspondingly. In this case the Service Data Adaptation Protocol (SDAP) in the RAN 415 and in the UE 410 may be enhanced to support the mapping of DRB to both QFI and DFI. For example, the (R)AN 415 may setup a DRB1 for the QoS flow with the default QoS parameters using QFI = 6 and DFI=0, DRB2 for the differentiated SDF-1 with DFI=2 and DRB3 for the differentiated SDF-2 with DFI = 3. The RAN 415 may assign a DFI value to the sub-QoS flows and use this DFI value for each sub-QoS flow in the signalling with the UE 410 in the SDAP layer. For example, the RAN 415 assigns the following associations: DRB1 maps to the set [QFI=6 and DFI=0], DRB2 maps to the set [QFI=6, DFI=2], and DRB2 maps to the set [QFI=6, DFI=3],
[0122] Alternatively, the (R)AN 415 may continue to use a single DRB associated with the QoS flow, but the RAN 415 applies enhanced scheduling / queueing mechanism for the DRB. The enhanced scheduling / queueing mechanism means that the incoming packets in the DL buffer for the QoS flow are marked with different priorities and e.g. the packets belonging to the sub-QoS flow (i.e. the packets of the SDF-1) are treated with higher priority than the rest of the packets of the QoS flow. For example, when the DL packets enter the buffer, a timestamp and the PDB is associated with the packet. When the packet isabout to expire in the buffer (e.g. due to delay reaching 80% of the PDB), the RAN 415 may schedule the packet may jump the queue and be schedule for sooner transmission.
[0123] If the reflective QoS indication is set up in the DRB transmission, the UE 410 determines to apply the same DRB for the UL data packets.
[0124] Examples described herein tend to enable one or more data flows (or SDFs) with different QoS traffic characteristics to be transmitted over the same QoS flow using differentiated packet handling on the radio link. Especially in situations where many data flows with various QoS characteristics are to be transmitted, this tends to avoid setting up many QoS flows. Instead, differentiated packet handling is performed on a single QoS flow. The examples tend to enable a single QoS characteristic to be modified for a data flow. Furthermore, examples tend to offer a finer granular handling of data flows instead of establishing new QoS flows for each data flow.
[0125] Examples described herein may be applied to public networks, e.g., a Public Land Mobile Network (PLMN), or to private networks, e.g., Non-Public Network (NPN) or a Standalone NPN (SNPN).
[0126] Examples described herein generally relate to differentiated packet handling within a single QoS flow in the DL. Examples described herein may also be applied to multiple QoS flows in a PDU Session. In the case of multiple QoS flows, the SMF / PCF may determine to apply the differentiated packet handling for data flows in each QoS flow separately.
[0127] Figure 5 illustrates a diagram for data flow classification and user plane marking for a QoS model 500 in accordance with aspects of the present disclosure.
[0128] The diagram for the QoS model 500 illustrates a PDU Session 560 setup between a UE 510 and an anchor UPF 525. The PDU Session 560 is used to assign an IP address and IP configuration to the UE 510. The PDU Session 560 comprises at least one QoS flow 564 between the UPF 525 and UE 510. The at least one QoS flow 564 may comprise a default QoS flow 564. There can be also additional QoS flows established for specific service flows or application flows. The PDU Session 560 comprises the N3 tunnel 562 between the anchor UPF 525 and the (R)AN 515 (or RAN node). The N3 tunnel 562may be a GTP-U tunnel. The N3 tunnel 562 is a single N3 tunnel 562 for the PDU Session 560. Over a radio link, a first DRB 566 and a second DRB 567 is setup between the (R)AN node 515 and the UE 510. One or more QoS flows can be mapped to a single DRB.
[0129] A first App server 552 and a second App server 554 each provide an App data flow to a first App 556 and a second App 558 at the UE 510, respectively via the QoS flow 564.
[0130] The diagram for the QoS model 500 is an enhanced QoS model in the user plane to flow diagram for the QoS model 200 described above in relation to Figure 2. The term “enhanced” may mean that the traffic of a QoS flow is differentiated and 1) either mapped to different DRBs or 2) a different scheduling mechanism is applied in the RAN 515. The main difference to the flow diagram for the QoS model 200 is the use of two DRBs (first DRB 566 or the second DRB 567) within the same QoS flow 564. The RAN 515 maps the QoS flow 564 and DFI to the first DRB 566 or the second DRB 567; which corresponds to the RAN-based solution described herein. The UPF 525 performs packet detection and mapping to the QoS flow 564 and corresponding DFIs. The DFIs may be represented by a continuous arrow between the UPF 525 and the UE 510. One of the DFIs corresponds to the data flow from the first App server 552 and the other DFI corresponds to the data flow from the second App server 554 The UPF 525 performs N3 tunnel marking for the QoS flow and the DFI. This corresponds to the UPF -based solution described herein.
[0131] Figure 6 illustrates an example of a UE 600 in accordance with aspects of the present disclosure. The UE 600 may include a processor 602, a memory 604, a controller 606, and a transceiver 608. The processor 602, the memory 604, the controller 606, or the transceiver 608, or various combinations thereof or various components thereof may be examples of means for performing various aspects of the present disclosure as described herein. These components may be coupled (e.g., operatively, communicatively, functionally, electronically, electrically) via one or more interfaces.
[0132] The processor 602, the memory 604, the controller 606, or the transceiver 608, or various combinations or components thereof may be implemented in hardware (e.g., circuitry). The hardware may include a processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), or other programmable logic device, or anycombination thereof configured as or otherwise supporting a means for performing the functions described in the present disclosure.
[0133] The processor 602 may include an intelligent hardware device (e.g., a general- purpose processor, a DSP, a CPU, an ASIC, an FPGA, or any combination thereof). In some implementations, the processor 602 may be configured to operate the memory 604. In some other implementations, the memory 604 may be integrated into the processor 602. The processor 602 may be configured to execute computer-readable instructions stored in the memory 604 to cause the UE 600 to perform various functions of the present disclosure.
[0134] The memory 604 may include volatile or non-volatile memory. The memory 604 may store computer-readable, computer-executable code including instructions when executed by the processor 602 cause the UE 600 to perform various functions described herein. The code may be stored in a non-transitory computer-readable medium such the memory 604 or another type of memory. Computer-readable media includes both non- transitory computer storage media and communication media including any medium that facilitates transfer of a computer program from one place to another. A non-transitory storage medium may be any available medium that may be accessed by a general-purpose or special-purpose computer.
[0135] In some implementations, the processor 602 and the memory 604 coupled with the processor 602 may be configured to cause the UE 600 to perform one or more of the functions described herein (e.g., executing, by the processor 602, instructions stored in the memory 604). For example, the processor 602 may support wireless communication at the UE 600 in accordance with examples as disclosed herein. The UE 600 may be configured to support the arrangements described herein.
[0136] The controller 606 may manage input and output signals for the UE 600. The controller 606 may also manage peripherals not integrated into the UE 600. In some implementations, the controller 606 may utilize an operating system such as iOS®, ANDROID®, WINDOWS®, or other operating systems. In some implementations, the controller 606 may be implemented as part of the processor 602.
[0137] In some implementations, the UE 600 may include at least one transceiver 608. In some other implementations, the UE 600 may have more than one transceiver 608. The transceiver 608 may represent a wireless transceiver. The transceiver 608 may include one or more receiver chains 610, one or more transmitter chains 612, or a combination thereof.
[0138] A receiver chain 610 may be configured to receive signals (e.g., control information, data, packets) over a wireless medium. For example, the receiver chain 610 may include one or more antennas for receive the signal over the air or wireless medium. The receiver chain 610 may include at least one amplifier (e.g., a low-noise amplifier (LNA)) configured to amplify the received signal. The receiver chain 610 may include at least one demodulator configured to demodulate the receive signal and obtain the transmitted data by reversing the modulation technique applied during transmission of the signal. The receiver chain 610 may include at least one decoder for decoding the processing the demodulated signal to receive the transmitted data.
[0139] A transmitter chain 612 may be configured to generate and transmit signals (e.g., control information, data, packets). The transmitter chain 612 may include at least one modulator for modulating data onto a carrier signal, preparing the signal for transmission over a wireless medium. The at least one modulator may be configured to support one or more techniques such as amplitude modulation (AM), frequency modulation (FM), or digital modulation schemes like phase-shift keying (PSK) or quadrature amplitude modulation (QAM). The transmitter chain 612 may also include at least one power amplifier configured to amplify the modulated signal to an appropriate power level suitable for transmission over the wireless medium. The transmitter chain 612 may also include one or more antennas for transmitting the amplified signal into the air or wireless medium.
[0140] Figure 7 illustrates an example of a processor 700 in accordance with aspects of the present disclosure. The processor 700 may be an example of a processor configured to perform various operations in accordance with examples as described herein. The processor 700 may include a controller 702 configured to perform various operations in accordance with examples as described herein. The processor 700 may optionally include at least one memory 704, which may be, for example, an L1 / L2 / L3 cache. Additionally, or alternatively, the processor 700 may optionally include one or more arithmetic-logic units(ALUs) 706. One or more of these components may be in electronic communication or otherwise coupled (e.g., operatively, communicatively, functionally, electronically, electrically) via one or more interfaces (e.g., buses).
[0141] The processor 700 may be a processor chipset and include a protocol stack (e.g., a software stack) executed by the processor chipset to perform various operations (e.g., receiving, obtaining, retrieving, transmitting, outputting, forwarding, storing, determining, identifying, accessing, writing, reading) in accordance with examples as described herein. The processor chipset may include one or more cores, one or more caches (e.g., memory local to or included in the processor chipset (e.g., the processor 700) or other memory (e.g., random access memory (RAM), read-only memory (ROM), dynamic RAM (DRAM), synchronous dynamic RAM (SDRAM), static RAM (SRAM), ferroelectric RAM (FeRAM), magnetic RAM (MRAM), resistive RAM (RRAM), flash memory, phase change memory (PCM), and others).
[0142] The controller 702 may be configured to manage and coordinate various operations (e.g., signalling, receiving, obtaining, retrieving, transmitting, outputting, forwarding, storing, determining, identifying, accessing, writing, reading) of the processor 700 to cause the processor 700 to support various operations in accordance with examples as described herein. For example, the controller 702 may operate as a control unit of the processor 700, generating control signals that manage the operation of various components of the processor 700. These control signals include enabling or disabling functional units, selecting data paths, initiating memory access, and coordinating timing of operations.
[0143] The controller 702 may be configured to fetch (e.g., obtain, retrieve, receive) instructions from the memory 704 and determine subsequent instruction(s) to be executed to cause the processor 700 to support various operations in accordance with examples as described herein. The controller 702 may be configured to track memory address of instructions associated with the memory 704. The controller 702 may be configured to decode instructions to determine the operation to be performed and the operands involved. For example, the controller 702 may be configured to interpret the instruction and determine control signals to be output to other components of the processor 700 to cause the processor 700 to support various operations in accordance with examples as describedherein. Additionally, or alternatively, the controller 702 may be configured to manage flow of data within the processor 700. The controller 702 may be configured to control transfer of data between registers, arithmetic logic units (ALUs), and other functional units of the processor 700.
[0144] The memory 704 may include one or more caches (e.g., memory local to or included in the processor 700 or other memory, such RAM, ROM, DRAM, SDRAM, SRAM, MRAM, flash memory, etc. In some implementations, the memory 704 may reside within or on a processor chipset (e.g., local to the processor 700). In some other implementations, the memory 704 may reside external to the processor chipset (e.g., remote to the processor 700).
[0145] The memory 704 may store computer-readable, computer-executable code including instructions that, when executed by the processor 700, cause the processor 700 to perform various functions described herein. The code may be stored in a non-transitory computer-readable medium such as system memory or another type of memory. The controller 702 and / or the processor 700 may be configured to execute computer-readable instructions stored in the memory 704 to cause the processor 700 to perform various functions. For example, the processor 700 and / or the controller 702 may be coupled with or to the memory 704, the processor 700, the controller 702, and the memory 704 may be configured to perform various functions described herein. In some examples, the processor 700 may include multiple processors and the memory 704 may include multiple memories. One or more of the multiple processors may be coupled with one or more of the multiple memories, which may, individually or collectively, be configured to perform various functions herein.
[0146] The one or more ALUs 706 may be configured to support various operations in accordance with examples as described herein. In some implementations, the one or more ALUs 706 may reside within or on a processor chipset (e.g., the processor 700). In some other implementations, the one or more ALUs 706 may reside external to the processor chipset (e.g., the processor 700). One or more ALUs 706 may perform one or more computations such as addition, subtraction, multiplication, and division on data. For example, one or more ALUs 706 may receive input operands and an operation code, whichdetermines an operation to be executed. One or more ALUs 706 be configured with a variety of logical and arithmetic circuits, including adders, subtractors, shifters, and logic gates, to process and manipulate the data according to the operation. Additionally, or alternatively, the one or more ALUs 706 may support logical operations such as AND, OR, exclusive-OR (XOR), not-OR (NOR), and not- AND (NAND), enabling the one or more ALUs 706 to handle conditional operations, comparisons, and bitwise operations.
[0147] The processor 700 may support wireless communication in accordance with examples as disclosed herein. The processor 700 may be configured to or operable to support a means for receiving a DL data packet comprising an indication of a data flow; determining, based on the indication of the data flow and first configuration information, that the DL data packet is from the data flow in a QoS flow, wherein the first configuration information comprises a mapping between the indication of the data flow and a QoS parameter of the data flow; configuring a DRB of the QoS flow according to the QoS parameter of the data flow; and transmitting, to a user equipment, UE, the DL data packet via the DRB of the QoS flow for the data flow.
[0148] Figure 8 illustrates an example of a NE 800 in accordance with aspects of the present disclosure. The NE 800 may include a processor 802, a memory 804, a controller 806, and a transceiver 808. The processor 802, the memory 804, the controller 806, or the transceiver 808, or various combinations thereof or various components thereof may be examples of means for performing various aspects of the present disclosure as described herein. These components may be coupled (e.g., operatively, communicatively, functionally, electronically, electrically) via one or more interfaces.
[0149] The processor 802, the memory 804, the controller 806, or the transceiver 808, or various combinations or components thereof may be implemented in hardware (e.g., circuitry). The hardware may include a processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), or other programmable logic device, or any combination thereof configured as or otherwise supporting a means for performing the functions described in the present disclosure.
[0150] The processor 802 may include an intelligent hardware device (e.g., a general- purpose processor, a DSP, a CPU, an ASIC, an FPGA, or any combination thereof). Insome implementations, the processor 802 may be configured to operate the memory 804. In some other implementations, the memory 804 may be integrated into the processor 802. The processor 802 may be configured to execute computer-readable instructions stored in the memory 804 to cause the NE 800 to perform various functions of the present disclosure.
[0151] The memory 804 may include volatile or non-volatile memory. The memory 804 may store computer-readable, computer-executable code including instructions when executed by the processor 802 cause the NE 800 to perform various functions described herein. The code may be stored in a non-transitory computer-readable medium such the memory 804 or another type of memory. Computer-readable media includes both non- transitory computer storage media and communication media including any medium that facilitates transfer of a computer program from one place to another. A non-transitory storage medium may be any available medium that may be accessed by a general-purpose or special-purpose computer.
[0152] In some implementations, the processor 802 and the memory 804 coupled with the processor 802 may be configured to cause the NE 800 to perform one or more of the functions described herein (e.g., executing, by the processor 802, instructions stored in the memory 804). For example, the processor 802 may support wireless communication at the NE 800 in accordance with examples as disclosed herein. The NE 800 may be a first network entity. The NE 800 may be configured to support a means for receiving a DL data packet comprising an indication of a data flow; determining, based on the indication of the data flow and first configuration information, that the DL data packet is from the data flow in a QoS flow, wherein the first configuration information comprises a mapping between the indication of the data flow and a QoS parameter of the data flow; configuring a DRB of the QoS flow according to the QoS parameter of the data flow; and transmitting, to a user equipment, UE, the DL data packet via the DRB of the QoS flow for the data flow.
[0153] The controller 806 may manage input and output signals for the NE 800. The controller 806 may also manage peripherals not integrated into the NE 800. In some implementations, the controller 806 may utilize an operating system such as iOS®, ANDROID®, WINDOWS®, or other operating systems. In some implementations, the controller 806 may be implemented as part of the processor 802.
[0154] In some implementations, the NE 800 may include at least one transceiver 808. In some other implementations, the NE 800 may have more than one transceiver 808. The transceiver 808 may represent a wireless transceiver. The transceiver 808 may include one or more receiver chains 810, one or more transmitter chains 812, or a combination thereof.
[0155] A receiver chain 810 may be configured to receive signals (e.g., control information, data, packets) over a wireless medium. For example, the receiver chain 810 may include one or more antennas for receive the signal over the air or wireless medium. The receiver chain 810 may include at least one amplifier (e.g., a low-noise amplifier (LN A)) configured to amplify the received signal. The receiver chain 810 may include at least one demodulator configured to demodulate the receive signal and obtain the transmitted data by reversing the modulation technique applied during transmission of the signal. The receiver chain 810 may include at least one decoder for decoding the processing the demodulated signal to receive the transmitted data.
[0156] A transmitter chain 812 may be configured to generate and transmit signals (e.g., control information, data, packets). The transmitter chain 812 may include at least one modulator for modulating data onto a carrier signal, preparing the signal for transmission over a wireless medium. The at least one modulator may be configured to support one or more techniques such as amplitude modulation (AM), frequency modulation (FM), or digital modulation schemes like phase-shift keying (PSK) or quadrature amplitude modulation (QAM). The transmitter chain 812 may also include at least one power amplifier configured to amplify the modulated signal to an appropriate power level suitable for transmission over the wireless medium. The transmitter chain 812 may also include one or more antennas for transmitting the amplified signal into the air or wireless medium.
[0157] Figure 9 illustrates a flowchart of a method 900 in accordance with aspects of the present disclosure. The operations of the method 900 may be implemented by a NE as described herein. In some implementations, the NE may execute a set of instructions to control the function elements of the NE to perform the described functions.
[0158] At 902, the method 900 may include receiving a DL data packet comprising an indication of a data flow. The operations of 902 may be performed in accordance withexamples as described herein. In some implementations, aspects of the operations of 902 may be performed by a NE as described with reference to Figure 8.
[0159] At 904, the method 900 may include determining, based on the indication of the data flow and first configuration information, that the DL data packet is from the data flow in a QoS flow, wherein the first configuration information comprises a mapping between the indication of the data flow and a QoS parameter of the data flow. The operations of 904 may be performed in accordance with examples as described herein. In some implementations, aspects of the operations of 904 may be performed by a NE as described with reference to Figure 8.
[0160] At 906, the method 900 may include configuring a DRB of the QoS flow according to the QoS parameter of the data flow. The operations of 906 may be performed in accordance with examples as described herein. In some implementations, aspects of the operations of 906 may be performed a NE as described with reference to Figure 8.
[0161] At 908, the method 900 may include transmitting, to a UE, the DL data packet via the DRB of the QoS flow for the data flow. The operations of 908 may be performed in accordance with examples as described herein. In some implementations, aspects of the operations of 908 may be performed by a NE as described with reference to Figure 8.
[0162] There is provided a first network entity for wireless communication, comprising: at least one memory; and at least one processor coupled with the at least one memory and configured to cause the first network entity to: receive a DL data packet comprising an indication of a data flow; determine, based on the indication of the data flow and first configuration information, that the DL data packet is from the data flow in a QoS flow, wherein the first configuration information comprises a mapping between the indication of the data flow and a QoS parameter of the data flow; configure a DRB of the QoS flow according to the QoS parameter of the data flow; and transmit, to a user equipment, UE, the DL data packet via the DRB of the QoS flow for the data flow.
[0163] Such a first network entity tends to improve handling of DL data packets with different QoS parameters over a single QoS flow. The first network entity tends to negatethe need to establish separate QoS flows for each data flow. The first network entity therefore tends to reduce the signalling overhead.
[0164] The first network entity may be a Radio Access Network (RAN). The QoS parameter of the data flow may be a QoS characteristic of the data flow. The QoS parameter of the data flow may correspond to a Priority Level (PL) of the data flow. The QoS parameter of the data flow may correspond to a Packet Delay Budget (PDB) of the data flow. The QoS parameter of the data flow may correspond to a Packet Error Rate (PER) of the data flow. The QoS parameter of the data flow may correspond to a Quality of Experience (QoE) of the data flow. The data flow may be a Service Data Flow (SFD).
[0165] The indication of the data flow may be a DFI, which may be further associated with a QFI. The indication of the data flow being a DFI may correspond to a User Plane Function (UPF)-based solution. The indication of the data flow may be a packet header information, which may be further associated with a QFI. The packet header information may be used for forwarding of the DL data packet which may include at least the DL data packet’s source and destination address. The indication of the data flow being a packet header information may correspond to a RAN-based solution.
[0166] The method may further comprise inspecting the DL data packet for the indication of the data flow. Data flow may be a sub-QoS flow.
[0167] Determining, based on the indication of the data flow and first configuration information, that the DL data packet is from the data flow in the QoS flow may be based on the mapping between the indication of the data flow and the QoS parameter of the data flow.
[0168] The first configuration information may comprise at least one of: a DFI, a packet filter, a Packet Detection Rule (PDR) and QoS characteristics for the data flow. The first configuration information may be first configuration information of the data flow. The first configuration information may comprise a mapping between the indication of the data flow and one or more QoS parameter(s) of the data flow.
[0169] The at least one processor coupled with the at least one memory may be further configured to cause the first network entity to: receive, from a third network entity, a firstconfiguration message comprising the first configuration information. The third network entity may be a Session Management Function (SMF). The first configuration message may be received from the third network entity via an Access and Mobility Management Function (AMF). The first configuration message may be an N2 SM Notification container.
[0170] The at least one processor coupled with the at least one memory being configured to cause the first network entity to configure the DRB of the QoS flow may comprise the at least one processor coupled with the at least one memory being further configured to cause the first network entity to: establish the DRB of the QoS flow for the data flow based on the QoS parameter.
[0171] The DRB may be associated with the data flow. The DRB may be identified by the indication of the data flow. The DRB may map to the DFI. The DRB may map to a QoS Flow Identifier (QFI). The DRB may map to the DFI and the QFI. A Service Data Adaptation Protocol (SDAP) in the first network entity may support the mapping of the DRB to the DFI and / or the QFI.
[0172] The at least one processor coupled with the at least one memory being configured to cause the first network entity to configure the DRB of the QoS flow may comprise the at least one processor coupled with the at least one memory being further configured to cause the first network entity to: apply a scheduling mechanism to the DRB for handling the DL data packet differently from other data packets of the QoS flow.
[0173] Applying the scheduling mechanism to the DRB may comprise adjusting a PL of the DRB for the QoS parameter. Applying the scheduling mechanism to the DRB may comprise adjusting a PDB of the DRB for the QoS parameter. Applying the scheduling mechanism to the DRB may comprise adjusting a PER of the DRB for the QoS parameter.
[0174] The DL data packet may be an encapsulated DL data packet. The encapsulated DL data packet may be received via an N3 tunnel. The encapsulated DL data packet may be received via a user plane N3 tunnel. The encapsulated DL data packet may comprise an encapsulation protocol. The encapsulation protocol may be a General Packet Radio Service (GPRS) Tunnelling Protocol-User Plane (GTP-U) protocol. The encapsulation protocol may comprise an N3 tunnel. The encapsulated DL data packet may be a GTP-U packet.The encapsulated DL data packet may comprise a header. The header may be a GTP-U header. The header may be a GTP-U tunnel header. The header may be an N3 tunnel header. The header may comprise the indication of the data flow.
[0175] The indication of the data flow may be a DFI. The DFI may map to one of a plurality of scalar values. Each of the plurality of scalar values may correspond to a QoS parameter. The DFI may be a data flow category. The DFI may be a differentiated flow identifier. The DFI may be received from a second network entity. The second network entity may be a User Plane Function (UPF).
[0176] The indication of the data flow may be a packet header containing at least source and target packet address. The indication of the data flow may be the inner packet header of the encapsulated DL packet and may include at least source and target packet address (but may also include further 5-tupple parameters). The first network entity may store the first configuration information which may include DL flow packet filter that is used to identify whether the received DL packet belongs to the data flow. The DL flow packet filter may comprise a Packet Detection Rule (PDR). The DL data packet may be a DL packet. The DL packet may have intrinsic destination and source addresses (e.g. IP addresses) and the first network entity may use the stored PFS / PDR to determine that the DL packet belongs to the data flow.
[0177] The at least one processor coupled with the at least one memory may be further configured to cause the first network entity to: transmit, to a user equipment, UE, a second configuration message comprising second configuration information, wherein the second configuration information comprises the mapping between the indication of the data flow and the QoS parameter of the data flow. The second configuration message may be an SDAP message. The second configuration message may comprise an association between a QoS parameter of the DRB and the indication of the data flow. The QoS flow may be a non-guaranteed bit rate, non-GBR, QoS flow.
[0178] There is further provided method performed by a first network entity, the method comprising: receiving a DL data packet comprising an indication of a data flow; determining, based on the indication of the data flow and first configuration information, that the DL data packet is from the data flow in a QoS flow, wherein the first configurationinformation comprises a mapping between the indication of the data flow and a QoS parameter of the data flow; configuring a DRB of the QoS flow according to the QoS parameter of the data flow; and transmitting, to a user equipment, UE, the DL data packet via the DRB of the QoS flow for the data flow.
[0179] Such a method tends to improve handling of DL data packets with different QoS parameters over a single QoS flow. The method tends to negate the need to establish separate QoS flows for each data flow. The method therefore tends to reduce the signalling overhead.
[0180] The method may further comprise inspecting the DL data packet for the indication of the data flow. Data flow may be a sub-QoS flow. Determining, based on the indication of the data flow and first configuration information, that the DL data packet is from the data flow in the QoS flow may be based on the mapping between the indication of the data flow and the QoS parameter of the data flow.
[0181] The method may further comprise receiving, from a third network entity, a first configuration message comprising the first configuration information.
[0182] Configuring the DRB of the QoS flow may comprise establishing the DRB of the QoS flow for the data flow based on the QoS parameter. Configuring the DRB of the QoS flow may comprise applying a scheduling mechanism to the DRB for handling the DL data packet differently from other data packets of the QoS flow.
[0183] The DL data packet may be an encapsulated DL data packet. The encapsulated DL data packet may comprise a header. The header may comprise the indication of the data flow. The indication of the data flow may be a DFI. The indication of the data flow may be a packet header containing at least source and target packet address.
[0184] The method may further comprise transmitting, to a user equipment, UE, a second configuration message comprising second configuration information, wherein the second configuration information comprises the mapping between the indication of the data flow and the QoS parameter of the data flow. The QoS flow may be a non-guaranteed bit rate, non-GBR, QoS flow.
[0185] There is further provided a method performed by a third network entity, the method comprising: sending, to a first network entity, a first configuration message comprising first configuration information, wherein the first configuration information comprises a mapping between an indication of a data flow and a QoS parameter of the data flow.
[0186] Such a method tends to improve handling of DL data packets with different QoS parameters over a single QoS flow. The method tends to negate the need to establish separate QoS flows for each data flow. The method therefore tends to reduce the signalling overhead.
[0187] The method may further comprise receiving, from a fourth network entity, an indication to enable handling of a DL data packet in the data flow according to the QoS parameter. The fourth network entity may be a Unified Data Management (UDM). The fourth network entity may be a User Data Repository (UDR). The indication to enable handling of the DL data packet in the data flow according to the QoS parameter may be an indicator of differentiated packet handling within the QoS flow. Differentiated packet handling within the QoS flow may comprise handling the DL data packet in the data flow differently to a second data packet in a second data flow. The second data packet may be handled according to a second QoS parameter. The second QoS parameter may correspond to a second PL. The second QoS parameter may correspond to a second PDB. The second QoS parameter may correspond to a second PER. The second QoS parameter may correspond to a second QoE. Handling of the DL data packet in the data flow according to the QoS parameter may be according to the UPF-based solution. Handling of the DL data packet in the data flow according to the QoS parameter may be according to the RAN- based solution.
[0188] The method may further comprise storing the indication to enable handling of the DL data packet in the data flow according to the QoS parameter. The method may further comprise determining to enable handling of the DL data packet in the data flow according to the QoS parameter. Determining to enable handling of the DL data packet in the data flow according to the QoS parameter may be based on at least one of: an indication from a Policy Control Function (PCF) for specific handling of the data flow; an indicationfrom an Application Function (AF) about a required QoS for the data flow; an N2 SM notification from a RAN about a certain condition for the QoS flow; and an indication from an Operations, Administration and Maintenance (OAM) or Network Data Analytics Function (NWDAF) for a certain network condition.
[0189] There is further provided a method performed by a user equipment, UE, the method comprising: receiving, from a first network entity via a DRB of a QoS flow, a DL data packet comprising an indication of a data flow, wherein the DL data packet is from the data flow in the QoS flow, wherein the DRB of the QoS flow is configured according to first configuration information comprising a mapping between the indication of the data flow and a QoS parameter of the data flow.
[0190] Such a method tends to improve handling of DL data packets with different QoS parameters over a single QoS flow. The method tends to negate the need to establish separate QoS flows for each data flow. The method therefore tends to reduce the signalling overhead. An SDAP in the UE may support the mapping of the DRB to the DFI and / or the QFI.
[0191] In examples described herein, the SMF may be arranged to: receive and store in the SM context one or more indications (e.g. from PCF, UDM or AF) A) that differentiated data flow handling is enabled or allowed for a QoS flow, B) the data flow identification information (e.g. packet filter) and C) required QoS or QoE information.
[0192] The SMF may be further arranged to determine to activate the differentiated handling of the data flow packets from the handling of the other packets of the QoS flow.
[0193] In some examples described herein, for RAN-based solution, the SMF may be further arranged to send a configuration information to the (R)AN (e.g. using N2 SM signalling) including data flow identification information (e.g. packet filter, PDR) and associated QoS parameters.
[0194] In some examples described herein, for UPF-based solution, the SMF may be further arranged to send N4 configuration information to the UPF including data flow identification information (e.g. packet filter, PDR) and associated differentiated flow handling parameter, and configuration information to the (R)AN.
[0195] In some exampled described herein, the UPF may be arranged to receive N4 configuration information including data flow (e.g. SDF) identification and corresponding differentiated flow handling parameter to be included in the N3 tunnel encapsulation packet header. The data flow identification may include packet filter (or PDR).
[0196] The UPF may be further arranged to perform packet inspection and, when determining a DL packet to match the data flow identification, the UPF may include the differentiated flow handling parameter in the N3 tunnel encapsulation header.
[0197] In some examples described herein, in the SDAP layer, the UE is arranged to receive an association of the DRB to both QFI and DFI.
[0198] There is further provided a method of a first network function (e.g. SMF) in a communication network, the method comprising the following steps: receiving and storing one or more indications that differentiated data flow handling is enabled or allowed for a QoS flow, the data flow identification information (e.g. packet filter) and associated required QoS (or QoE) information for the data flow; determining to activate differentiated handling of the data flow packets from the handling of the other packets of the QoS flow, which includes at least one of: (for RAN-based solution); sending a configuration information to the (R)AN (e.g. using N2 SM signalling) including data flow identification information (e.g. data flow packet filter, PDR) and associated QoS parameters; or (for UPF- based solution); transmitting a first configuration information (e.g. via N4 interface) to the UPF including data flow identification information (e.g. data flow packet filter, PDR) and associated DFI parameter, and further transmitting a second configuration information (e.g. via N2 SM container) to the (R)AN.
[0199] The method may further comprise determining to enable the differentiated data flow handling for the QoS flow is based on at least one of the following trigger events: an indication from the PCF for the specific handling of the data flow (e.g. based on service requirements); an indication from an AF about the required QoS for the data flow; N2 SM notification from the (R)AN about a certain condition for the QoS flow (e.g. queue overflow); and an indication from the Operations Administration and Management (0AM) or NWDAF for certain network condition.
[0200] For the UPF-based solution, the second configuration information to the (R)AN may include a mapping information between the differentiated flow handling parameter and a set of one or more QoS parameters different from the QoS parameters of the QoS flow. The QoS flow may be a non-GBR QoS flow.
[0201] There is further provided a method of a (radio) access network entity in a communication network, the method comprising the following steps: receiving a first message including one or more data flows (e.g. identified by a data flow packet filter) and associated with QoS characteristics different from the QoS characteristics of the QoS flow; performing DL data packets inspection to determine which packets belong to the data flow identified by the (downlink) data flow packet filter; determining whether to A) setup a separate DRB to the UE for the one or more data flows within the QoS flow or B) use the existing DRB to transmit the DL packets over the radio link to the UE.
[0202] In case B), the (R)AN may implement enhanced functionality to apply scheduling mechanism to handle packets of the differentiated SDF(s) in a different way corresponding to the QoS characteristics of the SDFs, e.g. higher / lower PL, or higher / lower DRB, or lower / higher PER.
[0203] In case of UPF-based solution, the first message may include a DFI parameter which maps to one or more QoS parameters values different from the QoS parameters of the QoS flow.
[0204] The method may further comprise receiving the parameter (e.g. differentiated flow handling) in the N3 tunnel header and determining to associate the packet with the data flow based on the parameter.
[0205] The method may further comprise transmitting a configuration message to the UE to setup the association of the DRBs and the combination of data flows identifier and QoS flow identifier. The configuration message may be an SDAP message. The QoS flow may be a non-GBR QoS flow.
[0206] It should be noted that the method described herein describes a possible implementation, and that the operations and the steps may be rearranged or otherwise modified and that other implementations are possible.
[0207] The description herein is provided to enable a person having ordinary skill in the art to make or use the disclosure. Various modifications to the disclosure will be apparent to a person having ordinary skill in the art, and the generic principles defined herein may be applied to other variations without departing from the scope of the disclosure. Thus, the disclosure is not limited to the examples and designs described herein but is to be accorded the broadest scope consistent with the principles and novel features disclosed herein.
[0208] The following abbreviations are relevant in the field addressed by this document: 5GC / 5GS - 5th Generation Core network / 5th Generation System, 5QI - 5G QoS Identifier, AAA - Authentication, Authorization, and Accounting, AF - Application Function, AMBR - Aggregated maximum bitrate, AMF - Access and Mobility Management Function, AN - Access network, API - Application Programming Interface, AS - Application Server, BS - Base Station, CN - Core network, EC - Energy Consumption, ECF - Energy Consumption function, eNB - Evolved Node-B, EPC / EPS - Evolved packet core / Evolved packet system, GBR - Guaranteed Bitrate, gNB - 5G Node- B, ID - Identity, IE - Information Element, LTE - Long Term Evolution, NAS - Non Access Stratum, MM - Mobility Management, MO - Mobile Originated, MRU - Mobility Registration Update, MT - Mobile Terminated, NEF - Network Exposure Function, NF - Network Function, NPN - Non-Public Network, NR - New Radio, NRF - Network Repository Function, NS - Network Slice, NWDAF - Network Data Analytics Function, 0AM - Operations, Administration and Management, PCF - Policy Control Function, PDR - Packet Detection Rule, PDU - Protocol Data Unit, PLMN - Public Land Mobile Network, HPLMN - Home Public Land Mobile Network, VPLMN - Visited Public Land Mobile Network, QFI - QoS Flow ID, QoS - Quality of Service, QoE - Quality of Experience, RAN - Radio Access Network, RAT - Radio Access Technology / Type, SDAP - Service Data Adaptation Protocol, S-NSSAI - Single Network Slice Selection Assistance Information, SM - Session Management, SMF - Session Management Function, SNPN - Standalone Non-Public Network, SUPI - Subscription Permanent Identifier, TA - Tracking area, TRP - Transmit-Receive Points, UDM - Unified Data Management, UDR - Unified Data Repository, UE - User Equipment, UMTS - Universal Mobile Telecommunication System, UPF - User Plane Function, USIM - Universal Subscriber Identity Module, (E)- UTRAN - (Evolved) Universal Terrestrial Radio Access Network.
Claims
CLAIMSWhat is claimed is:
1. A first network entity for wireless communication, comprising: at least one memory; and at least one processor coupled with the at least one memory and configured to cause the first network entity to: receive a downlink data packet comprising an indication of a data flow; determine, based on the indication of the data flow and first configuration information, that the downlink data packet is from the data flow in a quality of service, QoS, flow, wherein the first configuration information comprises a mapping between the indication of the data flow and a QoS parameter of the data flow; configure a data radio bearer of the QoS flow according to the QoS parameter of the data flow; and transmit, to a user equipment, UE, the downlink data packet via the data radio bearer of the QoS flow for the data flow.
2. The first network entity of claim 1, wherein the at least one processor coupled with the at least one memory is further configured to cause the first network entity to: receive, from a third network entity, a first configuration message comprising the first configuration information.
3. The first network entity of any one of claims 1 or 2, wherein the at least one processor coupled with the at least one memory being configured to cause the first network entity to configure the data radio bearer of the QoS flow comprises the at least one processor coupled with the at least one memory being further configured to cause the first network entity to: establish the data radio bearer of the QoS flow for the data flow based on the QoS parameter.
4. The first network entity of any one of claims 1 to 3, wherein the at least one processor coupled with the at least one memory being configured to cause the first networkentity to configure the data radio bearer of the QoS flow comprises the at least one processor coupled with the at least one memory being further configured to cause the first network entity to: apply a scheduling mechanism to the data radio bearer for handling the downlink data packet differently from other data packets of the QoS flow.
5. The first network entity of any one of claims 1 to 4, wherein the downlink data packet is an encapsulated downlink data packet.
6. The first network entity of claim 5, wherein the encapsulated downlink data packet comprises a header.
7. The first network entity of claim 6, wherein the header comprises the indication of the data flow.
8. The first network entity of any one of claims 1 to 7, wherein the indication of the data flow is a data flow identifier.
9. The first network entity of any one of claims 1 to 7, wherein the indication of the data flow is a packet header containing at least source and target packet address.
10. The first network entity of any one of claims 1 to 9, wherein the at least one processor coupled with the at least one memory is further configured to cause the first network entity to: transmit, to a user equipment, UE, a second configuration message comprising second configuration information, wherein the second configuration information comprises the mapping between the indication of the data flow and the QoS parameter of the data flow.
11. The first network entity of any one of claims 1 to 10, wherein the QoS flow is a non-guaranteed bit rate, non-GBR, QoS flow.
12. A method performed by a first network entity, the method comprising: receiving a downlink data packet comprising an indication of a data flow; determining, based on the indication of the data flow and first configuration information, that the downlink data packet is from the data flow in a QoS flow, wherein the first configuration information comprises a mapping between the indication of the data flow and a QoS parameter of the data flow; configuring a data radio bearer of the QoS flow according to the QoS parameter of the data flow; and transmitting, to a user equipment, UE, the downlink data packet via the data radio bearer of the QoS flow for the data flow.
13. The method of claim 12, further comprising receiving, from a third network entity, a first configuration message comprising the first configuration information.
14. The method of any one of claims 12 or 13, wherein configuring the data radio bearer of the QoS flow comprises establishing the data radio bearer of the QoS flow for the data flow based on the QoS parameter.
15. The method of any one of claims 12 to 14, wherein configuring the data radio bearer of the QoS flow comprises applying a scheduling mechanism to the data radio bearer for handling the downlink data packet differently from other data packets of the QoS flow.
Citation Information
Patent Citations
Using SDAP headers for handling of as / NAS reflective QOS and to ensure in-sequence packet delivery during remapping in 5g communication systems
US20180324631A1
Communications associated with relative importance
WO2024163898A1