CN119698872A

CN119698872A - Impact of higher layers on QoS flow to DRB mapping

Info

Publication number: CN119698872A
Application number: CN202380058661.7A
Authority: CN
Inventors: R·罗斯巴赫; B·约瑟; P·努格哈利; V·文卡塔拉曼
Original assignee: Apple Inc
Current assignee: Apple Inc
Priority date: 2022-08-08
Filing date: 2023-08-08
Publication date: 2025-03-25
Also published as: WO2024035697A1

Abstract

A User Equipment (UE) configured to establish a Protocol Data Unit (PDU) session including one or more quality of service (QoS) flows and a plurality of Data Radio Bearers (DRBs) for communicating with a network, to decode from signaling received from the network or determine an initial mapping table for QoS flow to DRB mapping based on a network configuration of mapping parameters, to decode from signaling received from the network or determine information about current or upcoming traffic on the one or more QoS flows or one or more DRBs, to determine to map or remap a first QoS flow from a first DRB to a second DRB or to shift packets for the first QoS flow from the first DRB to the second DRB based on the information about current or upcoming traffic, and to configure transceiver circuitry to transmit one or more packets for the first QoS flow on the second DRB.

Description

Impact of higher layers on QoS flow to DRB mapping

Priority/incorporation by reference

The present application claims priority from U.S. provisional application serial No. 63/370,754, filed 8/2022, and entitled "higher layer impact on QoS mapping (HIGHER LAYER Influence on QoS Mapping)", the entire contents of which are incorporated herein by reference.

Background

A User Equipment (UE) may establish a connection with at least one of a plurality of different networks or different types of networks, such as a 5G New Radio (NR) Radio Access Technology (RAT). The UE may access an external Data Network (DN), such as an extended reality (XR) or industrial internet of things (IIoT) service, via a 5GNR Radio Access Network (RAN) and a 5G core (5 GC). During operation, some services may utilize multiple parallel data streams in the Uplink (UL) and/or Downlink (DL). For example, in XR, there may be video, audio, and/or other data streams in DL, and control, gesture, and/or other data streams in UL. These data flows may be associated with multiple parallel QoS flows. For these data streams sent in parallel, some traffic may have high throughput and low latency requirements, while other traffic may have more relaxed requirements.

According to the current specifications, only the network/gNB can trigger the update of QoS flows to DRB mapping for UL and DL traffic. However, depending on the mapping of QoS flows to logical channels, the data queues on the UE side may be filled very fast. Delays on one or more DRBs may result in degradation of service and/or user experience when some packets do not arrive within latency bounds.

In some scenarios, the UE is better equipped than the network in order to analyze current or upcoming traffic usage, e.g. for application data on UL. It would be useful for a UE to influence the selection of DRB resources for traffic flows and/or to provide information to the network to better inform the network of the selection of DRB resources for traffic flows.

Disclosure of Invention

Some example embodiments relate to an apparatus of a User Equipment (UE) having processing circuitry configured to establish a Protocol Data Unit (PDU) session including one or more quality of service (QoS) flows and a plurality of Data Radio Bearers (DRBs) for communicating with a network, determine an initial mapping table for QoS flows to DRB mapping or decode an initial mapping table for QoS flows to DRB mapping based on network configuration of mapping parameters according to signaling received from the network, decode or determine information about current or upcoming traffic on the one or more QoS flows or one or more DRBs according to signaling received from the network, determine to map or remap a first QoS flow from a first DRB to a second DRB or to shift packets for the first QoS flow from the first DRB to the second DRB based on the information about current or upcoming traffic, and configure transceiver circuitry to transmit one or more packets for the first QoS flow on the second DRB.

Other example embodiments relate to a processor configured to establish a Protocol Data Unit (PDU) session including one or more quality of service (QoS) flows and a plurality of Data Radio Bearers (DRBs) for communicating with a network, determine an initial mapping table for QoS flows to DRB mapping or decode an initial mapping table for QoS flows to DRB mapping based on network configuration of mapping parameters according to signaling received from the network, decode or determine information about current or upcoming traffic on the one or more QoS flows or one or more DRBs according to signaling received from the network, determine to map or remap a first QoS flow from a first DRB to a second DRB or shift packets for the first QoS flow from the first DRB to the second DRB based on the information about current or upcoming traffic, and configure transceiver circuitry to transmit one or more packets for the first QoS flow on the second DRB.

Still further exemplary embodiments relate to an apparatus of a base station having processing circuitry configured to establish a Protocol Data Unit (PDU) session including one or more quality of service (QoS) flows and a plurality of Data Radio Bearers (DRBs) for communication with a User Equipment (UE), instruct the UE to determine mapping parameters for an initial mapping table for QoS flow to DRB mapping, configure the UE for a packet shift or QoS flow remapping feature, wherein the packet shift or QoS flow remapping feature allows the UE to receive or determine information about current or upcoming traffic on the one or more QoS flows or one or more DRBs and determine to map or remap a first QoS flow from a first DRB to a second DRB or to shift a packet for the first QoS flow from the first DRB to the second DRB based on the information about current or upcoming traffic, and decode one or more packets for the first QoS flow on the second DRB according to a signal received from the UE.

Additional exemplary embodiments relate to a processor configured to establish a Protocol Data Unit (PDU) session including one or more quality of service (QoS) flows and a plurality of Data Radio Bearers (DRBs) for communication with a User Equipment (UE), to instruct the UE to determine mapping parameters for an initial mapping table for QoS flow to DRB mapping, to configure the UE for a packet shift or QoS flow remapping feature, wherein the packet shift or QoS flow remapping feature allows the UE to receive or determine information about current or upcoming traffic on the one or more QoS flows or one or more DRBs and to determine to map or remap a first QoS flow from a first DRB to a second DRB based on the information about current or upcoming traffic or to shift packets for the first QoS flow from the first DRB to the second DRB, and to decode one or more packets for the first QoS flow on the second DRB according to a signal received from the UE.

Drawings

Fig. 1 illustrates an exemplary network arrangement according to various exemplary embodiments.

Fig. 2 illustrates an exemplary User Equipment (UE) in accordance with various exemplary embodiments.

Fig. 3 illustrates an exemplary base station in accordance with various exemplary embodiments.

Fig. 4 illustrates an exemplary network arrangement for QoS flows and DRB mapping in accordance with various exemplary embodiments.

Fig. 5a shows a diagram of QoS flow mapping for an SDAP layer according to various exemplary embodiments.

Fig. 5b illustrates a DL SDAP header according to various exemplary embodiments.

Fig. 5c illustrates a UL SDAP header according to various exemplary embodiments.

Fig. 5d illustrates a DL SDAP data PDU format with a DL SDAP header according to various exemplary embodiments.

Fig. 5e illustrates a UL SDAP data PDU format with a UL SDAP header, according to various exemplary embodiments.

Fig. 6a illustrates an exemplary diagram for a UE to remap one or more packets from a first DRB to a second DRB based on a buffer status, according to various exemplary embodiments.

Fig. 6b illustrates a method for a UE to remap packets from a first DRB to a second DRB based on a buffer status, according to various example embodiments.

Fig. 6c illustrates an exemplary diagram for a UE to shift one or more packets from a first DRB to a second DRB based on a critical state of the packets, in accordance with various exemplary embodiments.

Fig. 6d illustrates a method for a UE to shift one or more packets from a first DRB to a second DRB based on a critical state of the packets, in accordance with various exemplary embodiments.

Fig. 7 illustrates a method for UE-initiated operations for QoS flow-to-DRB remapping or packet shifting in accordance with various exemplary embodiments.

Detailed Description

Example embodiments may be further understood with reference to the following description and the appended drawings, wherein like elements are provided with the same reference numerals. The example embodiments relate to initiating operations for a User Equipment (UE) to remap or shift packets for quality of service (QoS) flows to Data Radio Bearers (DRBs) based on information determined or received by the UE. In particular, the UE may consider information/commands received from the application layer and/or events detected at the UE regarding current or expected upcoming data usage. Based on this information, the UE may initiate QoS flow remapping, packet shifting (to another DRB), or UE assistance information for the network to make QoS flow or DRB related decisions. Alternatively, the UE may also consider information/commands/configurations received from the network when initiating QoS flow to DRB remapping or packet shifting. Furthermore, packet shifting may be combined with Active Queue Management (AQM) principles.

In some scenarios, including Internet Protocol (IP) and/or ethernet data traffic for an extended reality (XR) or industrial internet of things (IIoT) service, multiple QoS flows with different throughput and/or latency requirements may be sent in parallel on multiple DRBs. The delay of one DRB may negatively impact the user experience. In some scenarios, it may be more efficient for the UE to initiate or request QoS flow remapping and/or to shift packets to different DRBs.

According to some aspects, the UE may receive information/commands from the application layer regarding current or upcoming traffic to/from the application. In other aspects, the UE (lower layers, e.g., service Data Adaptation Protocol (SDAP), packet Data Convergence Protocol (PDCP), radio Link Control (RLC), or Medium Access Control (MAC)) may detect events including, e.g., a high buffer status of DRB/LCH, high Round Trip Time (RTT), bulk retransmissions (on RLC or HARQ level), the UE approaching a Packet Delay Budget (PDB) for a given data flow (e.g., based on a PDCP discard timer or according to new parameters configured by the network, or based on an estimate internal to the UE and related to the PDB for 5 QI/QFI), PDU group delay threshold, packet error rate, PDU group error rate, UE has entered a time-to-live state, and other events related to the transmission time or delay time of packets on DRB/LCH. The UE may determine to initiate remapping of the QoS flow to a different DRB or to shift some packets to a different DRB without remapping the QoS flow. In still other aspects, the UE may provide assistance information to the network in, for example, UL transmission (UL SDAP PDU) or UL RRC signaling, which may affect network operation with respect to QoS flows or DRBs. In one example, the UE may determine and indicate that the connection to the application has been closed and that no additional traffic should be expected on the particular QoS flow and/or DRB.

Exemplary embodiments relate to enhancements for augmented reality (XR) or industrial internet of things (IIoT) applications. Those skilled in the art will appreciate that XR is a realistic umbrella term of different types and may refer generally to both real and virtual combined environments and associated human-machine interactions generated by computer technology and wearable devices. To provide some examples, the term XR may encompass Augmented Reality (AR), mixed Reality (MR), and Virtual Reality (VR). However, any reference to XR specific to a particular flow use case or type is provided for illustrative purposes only. Those skilled in the art will appreciate that IIoT relates to industrial applications, including, for example, production, robotics, and/or medical, which may be implemented in Time Sensitive Networks (TSNs) with low latency requirements. Although some of the exemplary embodiments are described with respect to enhancements for XR and/or IIoT services, the exemplary embodiments are not limited to XR or IIoT services and may be applicable to any type of NR traffic that may be affected by processing requirements imposed by external applications.

During operation, some services may utilize multiple data streams in the Uplink (UL) and/or Downlink (DL). From a physical channel perspective, there may be different control channels and shared channels for each stream, or multiple streams may share one control channel and/or shared channel. In some configurations, each flow may have different quality of service (QoS) requirements (e.g., block error rate (BLER) requirements, latency requirements, etc.). Additionally, the UE may send data on the UL that is forwarded to another UE on the DL or directly via, for example, a Side Link (SL) or WiFi.

Furthermore, the exemplary embodiments are described with respect to a UE. Those skilled in the art will appreciate that a UE may be any type of electronic component configured to communicate via a network, such as a mobile phone, tablet computer, desktop computer, smart phone, tablet, embedded device, wearable apparatus, internet of things (IoT) device, etc. Regarding XR, in some configurations, the UE may be paired with a wearable device (e.g., a Head Mounted Display (HMD), AR glasses, etc.). In this type of configuration, the UE may communicate directly with the network and then relay the data to a wearable device (e.g., AR, VR, MR, etc.) that presents the XR content to the user. In other configurations, the UE may be a wearable device that communicates directly with the network and presents XR content to the user. Thus, a UE as described herein is used to represent any electronic component that communicates directly with a network.

Fig. 1 illustrates an exemplary network arrangement 100 according to various exemplary embodiments. The exemplary network arrangement 100 includes a UE 110. Those skilled in the art will appreciate that UE 110 may be any type of electronic component configured to communicate via a network, such as a mobile phone, tablet computer, desktop computer, smart phone, tablet, embedded device, wearable apparatus (e.g., HMD, AR glasses, etc.), internet of things (IoT) device, industrial IoT (IIoT) device, etc. It should also be appreciated that an actual network arrangement may include any number of UEs used by any number of users. Thus, the example of a single UE 110 is provided for illustrative purposes only.

UE 110 may be configured to communicate with one or more networks. In an example of network configuration 100, the network with which UE 110 may wirelessly communicate is a 5G NR Radio Access Network (RAN) 120. However, UE 110 may also communicate with other types of networks (e.g., a 5G cloud RAN, a next generation RAN (NG-RAN), a Long Term Evolution (LTE) RAN, a legacy cellular network, a WLAN, etc.), and UE 110 may also communicate with the network through a wired connection. Referring to the exemplary embodiment, UE 110 may establish a connection with 5g NR RAN 120. Thus, UE 110 may have a 5G NR chipset to communicate with NR RAN 120.

The 5g NR RAN 120 may be part of a cellular network that may be deployed by a network operator (e.g., verizon, AT & T, T-Mobile, etc.). The 5g NR RAN 120 may comprise, for example, a cell or base station (node B, eNodeB, heNB, eNB, gNB, gNodeB, macrocell, microcell, femtocell, etc.) configured to transmit and receive traffic from UEs equipped with an appropriate cellular chipset.

UE 110 may connect to 5G NR-RAN 120 via gNB 120A. Those skilled in the art will appreciate that any association procedure may be performed for connecting UE 110 to 5G NR-RAN 120. For example, as described above, 5G NR-RAN 120 may be associated with a particular cellular provider where UE 110 and/or its users have protocol and credential information (e.g., stored on a SIM card). Upon detecting the presence of 5G NR-RAN 120, UE 110 may send corresponding credential information to associate with 5G NR-RAN 120. More specifically, UE 110 may be associated with a particular base station (e.g., gNB 120A). However, as noted above, reference to the 5G NR-RAN 120 is for illustrative purposes only and any suitable type of RAN may be used.

The network arrangement 100 further comprises a cellular core network 130, the internet 140, an IP Multimedia Subsystem (IMS) 150 and a network service backbone 160. The cellular core network 130 may be considered an interconnected set of components that manage the operation and traffic of the cellular network. The cellular core network 130 also manages traffic flowing between the cellular network and the internet 140. IMS150 may be generally described as an architecture for delivering multimedia services to UE 110 using IP protocols. IMS150 may communicate with cellular core network 130 and internet 140 to provide multimedia services to UE 110. The network services backbone 160 communicates with the internet 140 and the cellular core network 130, either directly or indirectly. Network services backbone 160 may generally be described as a collection of components (e.g., servers, network storage arrangements, etc.) that implement a set of services that may be used to extend the functionality of UE 110 in communication with various networks.

Fig. 2 illustrates an exemplary UE 110 in accordance with various exemplary embodiments. UE 110 will be described with respect to network arrangement 100 of fig. 1. UE 110 may include a processor 205, a memory arrangement 210, a display device 215, an input/output (I/O) device 220, a transceiver 225, and other components 230. Other components 230 may include, for example, audio input devices, audio output devices, power supplies, data acquisition devices, ports for electrically connecting UE 110 to other electronic devices, and the like.

Processor 205 may be configured to execute multiple engines of UE 110. For example, the engine may include a packet handling engine 235 for performing various operations related to receiving or determining information related to current or expected upcoming data usage of one or more applications, as will be described in detail below. The packet handling engine 235 may also perform operations related to initiating QoS flow to DRB remapping or packet shifting and providing the network with assistance information regarding current or anticipated upcoming data usage, as will be described in detail below.

The above-referenced engine 235 is provided for illustrative purposes only as an application (e.g., program) that is executed by the processor 205. The functionality associated with engine 235 may also be represented as a separate combined component of UE 110, or may be a modular component coupled to UE 110, e.g., an integrated circuit with or without firmware. For example, the integrated circuit may include input circuitry for receiving signals and processing circuitry for processing signals and other information. The engine may also be embodied as one application or as a plurality of separate applications. Furthermore, in some UEs, the functionality described for processor 205 is split between two or more processors (such as a baseband processor and an application processor). The exemplary embodiments may be implemented in any of these or other configurations of the UE.

Memory arrangement 210 may be a hardware component configured to store data related to operations performed by UE 110. The display device 215 may be a hardware component configured to display data to a user, while the I/O device 220 may be a hardware component that enables a user to enter input. The display device 215 and the I/O device 220 may be separate components or may be integrated together (such as a touch screen).

The transceiver 225 may be a hardware component configured to establish a connection with the 5G NR-RAN 120 and/or any other suitable type of network. Thus, transceiver 225 may operate on a variety of different frequencies or channels (e.g., a set of consecutive frequencies). The transceiver 225 may cover advanced receivers (e.g., E-MMSE-RC, R-ML, etc.) for MU-MIMO. The transceiver 225 includes circuitry configured to transmit and/or receive signals (e.g., control signals, data signals). Such signals may be encoded with information implementing any of the methods described herein. The processor 205 may be operably coupled to the transceiver 225 and configured to receive signals from and/or transmit signals to the transceiver 225. The processor 205 may be configured to encode and/or decode signals (e.g., signaling from a base station of a network) for implementing any of the methods described herein.

Fig. 3 illustrates an exemplary base station 300 in accordance with various exemplary embodiments. Base station 300 may represent any access node (e.g., gNB 120A, etc.) that UE 110 may use to establish a connection and manage network operations.

The base station 300 may include a processor 305, a memory arrangement 310, an input/output (I/O) device 315, a transceiver 320, and other components 325. Other components 325 may include, for example, a battery, a data acquisition device, a port for electrically connecting the base station 300 to other electronic devices, and the like.

The processor 305 may be configured to execute a plurality of engines of the base station 300. For example, the engine may include a packet handling engine 330 for performing operations related to configuring the UE to perform various UE-initiated operations with respect to QoS flow to DRB remapping or packet shifting, as will be described in detail below. The packet handling engine 330 may also perform operations related to receiving UE-initiated remapping requests and/or assistance information, granting packets that have been remapped to different DRBs, and performing actions in accordance therewith, as will be described in detail below.

The above-described engine 330 is merely exemplary as an application (e.g., program) that is executed by the processor 305. The functionality associated with the engine 330 may also be represented as a separate combined component of the base station 300 or may be a modular component coupled to the base station 300, e.g., an integrated circuit with or without firmware. For example, the integrated circuit may include input circuitry for receiving signals and processing circuitry for processing signals and other information. Further, in some base stations, the functionality described for the processor 305 is split between multiple processors (e.g., baseband processor, application processor, etc.). The exemplary embodiments may be implemented in any of these or other configurations of base stations.

Memory 310 may be a hardware component configured to store data related to operations performed by base station 300. The I/O device 315 may be a hardware component or port that enables a user to interact with the base station 300.

Transceiver 320 may be a hardware component configured to exchange data with UE 110 and any other UE in system 100. Transceiver 320 may operate on a variety of different frequencies or channels (e.g., a set of consecutive frequencies). Accordingly, transceiver 320 may include one or more components (e.g., radios) to enable data exchange with various networks and UEs. Transceiver 320 includes circuitry configured to transmit and/or receive signals (e.g., control signals, data signals). Such signals may be encoded with information implementing any of the methods described herein. The processor 305 may be operably coupled to the transceiver 320 and configured to receive signals from and/or transmit signals to the transceiver 320. The processor 305 may be configured to encode and/or decode signals (e.g., signaling from a UE) for implementing any of the methods described herein.

In XR (and/or cloud gaming), application traffic on the Downlink (DL) may include encoded video or scene information. Some XR applications may require a minimum granularity of application data available at the client before performing the next level of processing. For example, in some configurations, client processing of application data may only begin when all or some percentage of the bits of a video frame are available to a client device. The application data may be, for example, video frames that may be grouped into a plurality of IP payloads.

This minimum information granularity required for a given application may be referred to as an "application data unit" (ADU) or set of PDUs. XR (and/or cloud gaming) traffic includes bursts of traffic that may carry one or more ADUs or collections of PDUs. Each ADU or PDU set may comprise several PDUs or packets, e.g. 3 or 4 IP packets. The number of packets included in an ADU or PDU set may vary within a given application and between different applications, depending on the data included therein. Thus, depending on the XR application, the size of the ADU or PDU set may vary. It should be appreciated that three or four IP packets are examples, and that the ADU or PDU set may include any number of IP packets, ethernet packets, or other types of packets. Packets belonging to a particular ADU or PDU set may be sent across multiple data streams or in the same data stream. The exemplary embodiments are not limited to XR or IIoT services and provide enhancements common to 5G user planes applicable to any type of service. Furthermore, the exemplary embodiments are not limited to IP traffic and may be applied to any type of packet including at least ethernet packets, see TS23.501, clause 5.7.6.

The 5G-RAN and 5GC ensure quality of service (QoS) by mapping packets to the appropriate QoS flows and DRBs. Entities involved in packet handling of Downlink (DL) data and Uplink (UL) data for a UE typically include a 5GC User Plane Function (UPF) (e.g., an instance of UPF), a base station (gNB), and the UE. Each of these entities identifies certain information about the packet prior to processing the packet. Some Access Stratum (AS) packet processing functions are performed at the Service Data Adaptation Protocol (SDAP) layer of the gNB/UE.

The UPF serves as an external PDU session point interconnected with the DN and may perform packet routing and forwarding, perform packet inspection, perform a user plane part of policy rules, lawful interception packets (UP collection), perform traffic usage reporting, perform QoS handling (e.g., packet filtering, gating, UL/DL rate execution) on the user plane, perform uplink traffic verification (e.g., SDF to QoS flow mapping), send level packet marking in the uplink and downlink, and perform downlink packet buffering and downlink data notification triggering.

Fig. 4 illustrates an exemplary network arrangement 400 for QoS flows and DRB mapping in accordance with various exemplary embodiments. The network arrangement 400 includes a UE 405, a gNB 410, and a UPF 415. QoS flows and DRB mappings for downlink traffic flows including multiple data flows are described herein. However, those skilled in the art will appreciate that similar supplemental procedures may also occur on the uplink.

In a first step of DL packet handling, at the non-access stratum (NAS) level, the UPF 415 receives an IP data flow 420 from a Data Network (DN) via one or more PDU sessions. Each PDU session may correspond to a connection with a different Data Network (DN) and/or the internet. In the example of fig. 4, UPF 415 receives a first IP flow (IP 1), a second IP flow (IP 2), a third IP flow (IP 3), and a fourth IP flow (IP 4) via a first set of PDU sessions (PDU 1). The first set of PDU sessions may comprise, for example, an Internet PDU session, and IP flows 1-4 may correspond to video flows, such as YouTube or Skype video flows. The UPF 415 receives the fifth IP stream (IP 5) via a second set of PDU sessions (PDU 2) (e.g., streaming service PDU session), and IP5 may correspond to a video stream, such as a Netflix stream. The UPF 415 receives the sixth IP flow (IP 6) and the seventh IP flow (IP 7) via a third set of PDU sessions (PDU 3). The third set of PDU sessions may comprise, for example, IMS PDU sessions, where IP6 corresponds to a voice stream and IP7 corresponds to a video stream. It should be understood that each of these streams is merely exemplary and that these streams are not limited to any particular type of data stream.

UPF 415 processes received packets using Service Data Flow (SDF) traffic filter templates (e.g., packet filters). UPF 415 maps IP flows to QoS flows based on Packet Detection Rules (PDR) configured by 5 GC. UPF 415 associates the QoS Flow Identifier (QFI) with the IP flow by inserting the QFI into the packet (step 425) and sending the packet to the gNB 410 over the N3 interface via, for example, a GTP-U tunnel. In the example of fig. 4, IP1 maps to a first QoS flow (qfi=1), IP2 and IP3 maps to a second QoS flow (qfi=2), IP4 maps to a third QoS flow (qfi=3), IP5 maps to a fourth QoS flow (qfi=4), IP6 maps to a fifth QoS flow (qfi=5), and IP7 maps to a sixth QoS flow (qfi=6).

In a second step, at the AS level, the gNB 410 receives QoS flows from the UPF 415 via N3 and maps QoS flows to DRBs via one or more instances of the SDAP layer based on the QoS profile/mapping configured by the network. The DRB defines packet processing on the radio interface (Uu) and provides the same packet forwarding processing services for the packet. The QoS flow-to-DRB mapping by the gNB 410 is based on QFI configured by the 5GC and the associated QoS profile (i.e., qoS parameters and QoS characteristics). The QoS profile for the corresponding QFI is provided by the AMF to the 5G-RAN (gNB 410).

Separate DRBs may be established for QoS flows requiring different packet forwarding processes, or several QoS flows belonging to the same PDU session may be multiplexed in the same DRB. The gNB 410 associates the DRB ID with the QoS flow and sends the packet to the UE 405 over the air interface (Uu). In the example of fig. 4, a first QoS flow is mapped to a first DRB (drb=1), a second QoS flow and a third QoS flow are mapped to a second DRB (drb=2), a fourth QoS flow is mapped to a third DRB (drb=3), a fifth QoS flow is mapped to a fourth DRB (DRB-4), and a sixth QoS flow is mapped to a fifth DRB (drb=5). Several QoS flows belonging to the same PDU session may be mapped to the same DRB, whereas QoS flows belonging to different PDU sessions cannot be mapped to the same DRB.

In a third step, at the UE level, the UE 405 receives data in the DRB over the air interface via one or more instances of the SDAP layer. QoS flows are mapped to IP flows by the 5GSM layer according to packet filters contained in QoS rules configured by the 5 GC. The PDR at the UPF 415 and the QoS rules at the UE 405 may include similar and complementary packet filters. Thus, the original IP packet is extracted and delivered to higher layers. It should be appreciated that when the UE 405 generates an IP flow for UL transmission, the 5GSM layer similarly maps the IP flow to the QoS flow according to the packet filters contained in the QoS rules.

AS described above, qoS flow to DRB mapping is performed at the RAN/gNB (access stratum (AS)) of the SDAP layer. Several QoS flows belonging to the same PDU session may be mapped to the same DRB, whereas QoS flows belonging to different PDU sessions cannot be mapped to the same DRB. The RAN may add a new DRB with a corresponding QFI mapping to satisfy the QoS characteristics of the QoS flow. The UE determines the UL data QoS binding via explicit RRC signaling or via reflected QoS (RQoS) based on DL data QoS markers, as will be described in more detail below.

The exemplary embodiments relate to extensions of the QoS flow to DRB mapping step described above. Exemplary techniques may enable more dynamic QoS adaptation and associated user plane enhancements. Some techniques may also facilitate better processing of groups of packets featuring PDU sets or ADU-based QoS.

The mapping between QoS flows and DRBs may be determined by the gNB and may include explicit signaling or reflected QoS (RQoS). In explicit mapping techniques, the gNB uses RRC signaling (e.g., explicit QoS signaling) to indicate which QoS flows are communicated for which DRB for the UE's UL traffic. In the reflective QoS technique, the gNB includes an indication, e.g., RDI bit, in the DL packet that triggers the UE to update its UL mapping table based on the QFI and DRB for the DL packet. The UE monitors DL traffic to determine on which DRB QoS flows are received and after receiving RDI bits and QFI/PQFI and the UE updates its mapping table, the UE transmits UL traffic over the same DRB and with the same QoS flows. These techniques allow the network to transmit DL data for a single QoS flow in different DRBs. This provides a useful tool for the gNB to provide different packet forwarding or priority handling for some packets with a single QoS flow.

As described above, one SDAP entity is established at the UE and the gNB for each individual PDU session. The SDAP layer performs mapping between QoS flows and DRBs. When explicit RRC signaling is used, the UE SDAP is configured with QFI-to-DRB mapping rules to indicate which QoS flows are transmitted over which DRBs, including DL and UL mapping rules. When using the reflected UL mapping, the UE SDAP updates its UL mapping table based on the QFI of the received DL packet, which will be described below. If the mapping rule is not defined, the UE uses a default DRB for the QoS flows. The SDAP of the transmitting entity (UE or gNB) may add an SDAP header to mark QFI in the UL or DL data packets for various reasons as described below.

Fig. 5a illustrates a diagram 500 of QoS flow mapping for an SDAP layer according to various exemplary embodiments. Diagram 500 includes a transmitting SDAP entity 502 (e.g., UE or gNB) receiving QoS flows from higher layers (e.g., application layer (for UL traffic at UE) or UPF (for DL traffic at gNB)) and mapping QoS flows to DRBs based on QoS flow mapping configuration. If the SDAP header is configured for a DRB, the transmitting SDAP entity 502 adds the SDAP header before transmitting over the Uu interface. The SDAP header is configured on the UL or DL DRB whenever reflective QoS is enabled, and is configured on the UL DRB when more than one QoS flows are mapped to the same DRB. The receiving SDAP entity 504 (e.g., UE or gNB) processes the packet and if an SDAP header is configured, performs a reflected QoS flow to DRB mapping, removes the SDAP header, and sends the QoS flow to UPF (for UL traffic at gNB) or 5GSM (for DL traffic at UE).

On DL, the gNB may add QFI (QoS flow indication) and RQI (reflection QoS indication) and/or RDI (reflection QoS flow to DRB mapping indication) in the DL SDAP header. The DL header is only needed when a reflection map is used, which is optional for the gNB.

Fig. 5b illustrates a DL SDAP header 510 according to various exemplary embodiments. The DL SDAP header 510 includes octets (one byte) with a QFI field (6 bits), an RQI bit, and an RDI bit. The RQI bit may instruct the UE NAS to update its reflection mapping table for Service Data Flows (SDFs) to QoS flows and the RDI bit instructs the UE AS to update its reflection mapping table for QoS flows to DRBs.

On the UL, the UE may add QFI and D/C (data/control) in the UL SDAP header. When mapping more than one QoS flow to a DRB, a UL header is required (to indicate which QoS flow the DRB carries).

Fig. 5c shows a UL SDAP header 515 in accordance with various exemplary embodiments. UL SDAP header 530 includes octets (one byte) with QFI field (6 bits), D/C bits, and reserved (R) bits. The D/C bit may indicate whether the SDAP header carries a UL SDAP control PDU or a UL SDAP data PDU. One bit of the UL SDAP header is not currently allocated to a parameter (reservation (R) bit).

UL SDAP data PDUs may carry traffic with QFI that is marked to distinguish between multiple QoS flows mapped to a single DRB. After the gNB has remapped the QoS flow to a different DRB and indicated/configured a new mapping rule, the UL SDAP control PDU (e.g., the SDAP header without data) is used as the UL end marker for the data flow (DRB).

TS 37.324 defines UL SDAP end-marker control PDU. The SDAP end-marker control PDU is directed to SDAP and is only applied to Access Stratum (AS) level QoS. There is no associated timer. The end-marker may be used when the QoS flow to DRB mapping changes and is applicable to both reflection and RRC configured QoS mapping (see TS 38.300, TS 37.324, TS 38.331).

The reflection QoS (RQoS) at the AS level allows the network to use the RDI field to direct a particular QoS flow from one DRB to another, e.g., enhance QoS handling in a time window.

Fig. 5d illustrates a DL SDAP data PDU format 520 with a DL SDAP header 510 according to various exemplary embodiments. When the RDI bit is set in the DL SDAP header 510, the UE receiving the PDU 520 may update its mapping table for UL transmission for the same QFI.

UL packets belonging to the same QFI are directed by the UE to the same DRB that receives DL packet 520. To complete the remapping, the UE also transmits an SDAP end-marker control PDU 515 on the old DRB as the last packet associated with QFI. UL control PDU 515 indicates to the network that no more packets belonging to (remapped) QFI will be sent forward from this point over the old DRB.

Fig. 5e illustrates a UL SDAP data PDU format 525 with a UL SDAP header 515, according to various exemplary embodiments. When QFI is set in UL SDAP header 515, the gNB can distinguish between multiple QoS flows mapped to a single DRB.

As described above, traffic consisting of multiple modalities (e.g., video, data, control, audio, etc.) typically requires data transmission in multiple parallel QoS flows. Some of the traffic flows may have high throughput and low latency requirements, while other traffic flows may have more relaxed requirements. Examples include XR or IIoT related use cases. Depending on the mapping of QoS flows to logical channels, the UE-side queues (buffers) may then be filled very quickly. Furthermore, the delay of one DRB may lead to a reduced user experience, since the processing of the packets is out of acceptable latency range.

For these reasons, it may be beneficial for the UE to influence the selection of DRB resources. As described above, according to the current specification, only the gNB/network side can trigger the update of QoS flow to DRB mapping by using explicit signaling or reflected QoS as described above.

Those skilled in the art will appreciate that the mapping of QoS flows may become more flexible in the future. For example, the UE may be capable of requesting or initiating remapping of QoS flows to DRBs, e.g., according to techniques outside the scope of the present disclosure, and briefly discussed herein. In another example, one QoS flow may be mapped to multiple DRBs (the restriction that one QoS flow can only be mapped to one DRB may be removed). For example, the UE will be able to initiate QoS flow mapping or remapping to flexibly direct packets from one DRB to another if necessary. Assuming some future enhancements to the QoS mapping framework, the UE may be able to trigger mapping of QoS flows within the network with input from higher layers and/or optimize periods with data inactivity to prevent over-use of system resources.

According to various exemplary embodiments described herein, a UE (e.g., application layer, SDAP, PDCP, RLC, MAC, RRC) may affect the QoS to DRB mapping for a PDU session and trigger/control dynamic QoS adaptation. In some embodiments, the UE (lower layer) receives information/commands from the application layer regarding current or expected upcoming data usage. In other embodiments, a current or expected upcoming delay on one DRB, or a UE not meeting QoS requirements, may trigger the UE to remap one or more UL packets for a QoS flow to a different DRB than the DRB mapped for that QoS flow based on, for example, the LCH buffer status for the DRB. In some implementations, active Queue Management (AQM) techniques may be used, for example, to alert UEs of the cache state (or cache residence time) of DRBs/LCHs. In some implementations, packets may be shifted to different DRBs based on, for example, buffer status, buffer residence time, qoS mismatch, or receipt of time sensitive (critical) packets without initiating complete remapping of QoS flows. In still other implementations, the end of traffic indicator and/or the data inactivity timer indicator may be used to suggest that the network performs QoS adaptation.

Compared to the network, the UE has more accurate information about its currently active applications and typical data traffic activities. Thus, the UE may better predict whether a higher or lower QoS is required for a particular QFI at a given point in time (which may be associated with a different DRB). The UE may further predict how long QoS remapping should last (e.g., in a temporary short sequence of data activity on other common bearers), whether traffic patterns are bursty or one-time activity, etc.

In these embodiments, it is assumed that future UEs may be able to influence the mapping of QoS flows to DRBs. The actual method for QoS remapping at the Access Stratum (AS) level is basically outside the scope of the present disclosure, but this mechanism is assumed to be available. In some of the presently described embodiments, certain types of UE-initiated remapping mechanisms are contemplated. In one example, the UE may initiate UL reflected QoS, wherein the UE sends the QoS flow and the remapping indication (e.g., RDI bit) on a different DRB than the currently mapped DRB. In another example, the UE may temporarily shift the packet to another DRB without initiating a full remapping. In another example, the UE may request remapping using UL RRC signaling (e.g., a UE assistance information message).

Furthermore, current 5G QoS models do not allow the same QoS flow across multiple DRBs. To make the solution described herein more efficient, the network restriction that one QoS flow can be mapped to one and only one DRB can be eliminated. The 5G advanced version may allow one-to-many mapping of QoS flows to DRBs (one QoS flow is mapped to multiple DRBs).

According to one aspect of these exemplary embodiments, the application layer may provide information, suggestions, or commands to lower layers (e.g., SDAP, RRC) regarding current or upcoming traffic on a particular QoS flow. Information received from the application layer may affect QoS flow remapping decisions for lower layers.

In some examples, the UE may have application information related to a real-time video application, where the video is created in real-time, an electronic game live streaming application, or a real-time broadcast player game application. In another example, the live streaming application Twitch and MOB (multiplayer mobile online combat game) are two applications with a QoS-free (e.g., over common bearer/QFI/QCI) traffic pattern, characterized by a large packet size and a specific UL/DL packet interval distribution. MOB is particularly sensitive to delay and jitter.

In some embodiments, the application may indicate to lower layers of the UE (e.g., SDAP, RRC) current or upcoming changes to QoS requirements for different traffic flows by providing metrics and/or related metadata directly to the modem. In other embodiments, the AT (e.g., "attention") command specified in TS27.007 may be used to direct the modem to take some action. A specific Application Programming Interface (API) may be provided to the application developer to leverage UE capabilities to initiate dynamic remapping of QoS flows to DRBs.

Together with the enhanced QoS flow-to-DRB mapping methods discussed above (e.g., UE-initiated remapping and/or allowing one-to-many QoS flows to DRB mapping), and in view of information/commands received from the application layer, the UE may utilize foreground and background traffic and more dynamically put some of the background traffic on best effort bearers (or another bearer with lower QoS). These embodiments allow for fast remapping (allocation) of QoS flows to DRBs according to application layer impact and/or changing application requirements.

In another aspect of these exemplary embodiments, the UE lower layer (e.g., SDAP, PDCP, RLC or MAC) may detect events that may trigger QoS flow to DRB remapping and/or packet shifting from one DRB to another. In some embodiments, an event such as a cache state or cache residence time may be detected on the DRB/LCH that triggers remapping of QoS flows to different DRBs/LCHs. In other embodiments, certain packets may be shifted in a temporary or disposable manner. These embodiments may relate to Active Queue Management (AQM) techniques implemented at SDAP, PDCP, RLC or MAC layers. As described above, the SDAP maps QoS flows to DRBs. The RLC maps the DRBs received from the SDAP/PDCP to Logical Channels (LCHs) for transmission to a Medium Access Control (MAC) layer. When packets are received at (or generated by) these entities of a UE on the UL for transmission to lower layers and/or networks, the packets enter one or more transmit queues or buffers. From the queues/buffers, packets may be sequentially/progressively submitted to lower layers for further processing and transmission to the network.

In some embodiments, the UE (e.g., at the L2 layer) may detect events including, for example, a high buffer status, a high buffer residence time, a high retransmission rate, a high Round Trip Time (RTT), the UE approaching a Packet Delay Budget (PDB) for a given flow (e.g., based on a PDCP discard timer or according to new parameters configured by the network, or based on an estimate internal to the UE and related to the PDB for 5 QI/QFI), a PDU group delay threshold, a packet error rate, a PDU group error rate, or the UE has entered a time-to-live state to obtain packets on a particular Logical Channel (LCH) (for DRB). The UE may receive packets from higher layers that enter LCH/DRB queues or lower layer queues per DRB. If the UE detects a specific event with respect to a received packet, e.g., a high buffer status for a given LCH, the UE may provide feedback to higher layers (e.g., SDAP, RRC) that triggers remapping of QoS flows to different DRBs and/or shifting of packets/PDUs to different DRBs/LCHs without requiring complete remapping of QoS flows. LCHs to which packets are shifted may be associated with lower buffer states or delays.

Various thresholds (e.g., buffer, dwell time, retransmission, and/or RTT thresholds) that may trigger feedback to the SDAP or RRC may be configured by the network. The network may further configure packet shifting and/or QoS flow remapping parameters for the UE including, for example, DRBs that qualify for packet shifting, particular DRBs to which packets should be shifted, and the like.

Fig. 6a illustrates an exemplary diagram 600 for a UE 601 to remap one or more packets from a first DRB to a second DRB based on a buffer status, according to various exemplary embodiments. Diagram 600 shows a higher layer queue 602 and a lower layer queue 603 of a UE 601. Note that queues may be associated with one or more different layers depending on how the memory is organized, based on UE or gNB implementation. In some embodiments, the lower layer queue 603 may be associated with a PDCP layer, may be a Logical Channel (LCH) associated with an RLC layer or a DRB queue or may be associated with a MAC layer, for example. In some implementations, the higher layer queue 602 may be associated with an application layer or an SDAP layer, for example. Those skilled in the art will recognize that the higher layer queue 602 and lower layer queue 603 may be connected to different actual layers (or layers) in different implementations. In some cases, the higher layer queues may be in PDCP performing ciphering, while the lower layer queues may be RLC or MAC, where the packets are remapped. In this case, the receiver will decrypt the packet using the count value of PDCP from another DRB, that is, unless the packet shift occurs before ciphering. In yet another case, implementations may use a common queue for both higher and lower layers.

The first higher layer queue 602a corresponds to a first DRB (DRB 1) and the second higher layer queue 602b corresponds to a second DRB (DRB 2). According to the currently configured QoS flow to DRB mapping table, packets/PDUs on DRB 1 include QoS flow 7 (QFI 7) and packets/PDUs on DRB 2 include QoS flows 3 and 5 (QFI 3, 5). Packets for QFI 7 in the first higher layer queue 602a are mapped to DRB 1 and are submitted to lower layers (e.g., PDCP or lower) of the first lower layer queue 603a, and packets for QFI 3, 5 in the second higher layer queue 602b are mapped to DRB 2 and are submitted to lower layers of the second lower layer queue 603 b. From the lower layer queue 603, the packet is sent to the gNB 604 where the QoS flows are identified and sent to the UPF.

The lower layer queues 603 are configured with corresponding buffer thresholds or thresholds representing buffer residence times. If the buffer size of the queue 603 exceeds a threshold, a cached state may be detected at the UE 601. In this example, the first lower layer queue 603a has a high buffer status that triggers an alarm or feedback message from the lower layer to the higher layer. In response, a higher layer (e.g., SDAP or higher layer) determines to shift one or more packets for QFI 7 from a first higher layer queue 602a (DRB 1) to a second higher layer queue 602b (DRB 2), e.g., to meet a packet delay budget or to mitigate packet starvation. The second higher layer queue 602b may have a low buffer status within its respective threshold. The buffer status of the second queue 602b may be checked before DRB 2 is selected as the destination of one or more packets of QFI 7.

In this example, UE 601 determines that QoS flows of QFI 7 should be remapped from DRB 1 to DRB 2. In other embodiments, the UE may shift one or more packets to DRB 2 without requesting remapping. The UE 601 sends packets according to a UE-initiated remapping technique, which will be described in more detail below. The gNB 602 grants QFI 7 packets on DRB 2 and remaps the QoS flows from DRB 1 to DRB 2.

To request remapping, the UE may include a bit (e.g., RDI bit) in the UL SDAP header indicating the UE-initiated remapping request, and send the packet over a different DRB. Alternatively, the UE may simply update the QFI in the current queue and send the packet over a different DRB. An "incorrect" QFI serves as a trigger for remapping the QFI to the DRB that conveys the packet. Before transmitting the actual packet, the UE may transmit a PDU containing dummy data (e.g., a PDU with unexpected QFI is set to be discarded at the network), or may transmit an SDAP control PDU. A dummy packet refers to a transmission in which the SDAP header is correct and valid, but the payload only indicates dummy data (such as padding data).

These embodiments assume that the gNB accepts all QFIs (or configured DRB sets, or specific ranges or subsets of QFIs). The gNB supporting this function should not discard the received PDU (due to unexpected DRB to QoS flow mapping, if any). Local breakout (local break) refers to the case where the gNB is locally connected to a nearby internet gateway, such as some explained in TS 23.501. Local UPF refers to edge computation (where in some configurations, the gNB and UPF may be collocated). The gNB may employ a validity check of the received packet. If the QFI does not match the QoS flow-to-DRB mapping configured for the DRB, some gnbs may discard the packet. However, this depends on the gNB implementation. In other cases, the gNB may simply route packets to the output link based on the received QFI and not check the QoS flow to DRB mapping. Furthermore, such checking is typically associated with the gNB-CU (where PDCP and SDAP are located). A similar check is also possible for the gNB-DU, but this is unlikely or not necessarily the case, since the SDAP header should not be checked. Assuming that the gNB-CU does not run such a check, for example, when the UPF is located far away and there is one (or little) output link to the N3 interface, such a check needs to be done somewhere if the gNB is combined with a local UPF or local split. The level (where to make which part of the check) is part of the gNB/UPF implementation.

Fig. 6b illustrates a method 620 for a UE 601 to remap packets from a first DRB to a second DRB based on a buffer status, according to various example embodiments. The method 620 of fig. 6b is described with reference to diagram 600 of fig. 6 a.

In 625, a high buffer status is detected in a first lower layer queue of a first DRB carrying a first QoS flow (QFI 1) and the higher layer is notified, e.g., via an alert or feedback message. In other embodiments, the feedback message may relate to different types of event detection, such as high delay (round trip time), buffer dwell time, or retransmission rate of packets in the first lower layer queue. These event detection thresholds may be configured by the network for a particular DRB/LCH or all DRBs/LCHs.

In 630, the UE 601 (e.g., SDAP) determines to remap the first QoS flow (QFI 1) from DRB 1 to DRB 2. Before selecting DRB 2, the UE 601 may first determine that the buffer size of the second lower layer queue of DRB 2 is within a predetermined threshold, or the UE 601 may assume this, for example, because no alert about the second lower layer queue was received. Alternatively, the remapping to DRB 2 may be configured by the network.

In 635, the UE 601 (e.g., SDAP) initiates remapping of QFI 1 from DRB 1 to DRB 2. In some embodiments, in the SDAP header of at least one packet of the packets, the UE 601 includes an RDI bit indicating that the UE requests remapping of QFI 1 from DRB 1 to DRB 2. In other embodiments, the RDI bit is not used. UL SDAP data PDUs (with data or with dummy data) or control PDUs may be used. The request is sent on DRB 2.

At 640, the gNB 602 receives the packet (e.g., with RDI bits), grants the packet based on the gNB implementation, and remaps QFI 1 to DRB 2.

In other exemplary embodiments, the UE may shift one or more packets to a different DRB without requesting or initiating remapping. For example, in some cases, some packets (e.g., control data) may be eligible to be remapped to a different DRB. In these embodiments, the RDI bit may indicate the presence of a non-matching QFI in a one-time fashion, wherein rerouting of the packet is considered an exception or special case.

In some embodiments, certain packets may be identified as critical packets within the QoS flow itself (e.g., at the SDAP layer) and shifted to different DRBs, e.g., to carry traffic with different QoS requirements. In some examples, multiple QoS flows with different QoS requirements may be mapped to the same DRB, where in some cases some packets may be temporarily shifted to different DRBs.

The identification of critical packets may be defined by the network configuration or in the specification. The network may further configure packet shifting and/or QoS flow remapping parameters for the UE including, for example, DRBs that qualify for packet shifting, particular DRBs to which packets should be shifted, and the like.

Fig. 6c illustrates an exemplary diagram 650 for a UE 601 to shift one or more packets from a first DRB to a second DRB based on a critical state of the packets, according to various exemplary embodiments. The diagram 650 is arranged in a similar manner to the diagram 600 of fig. 6 a.

In this example, no feedback is received from the RLC/MAC regarding the lower layer queues 603, which relates to the buffer size or any other parameter (but the method may be combined with feedback where critical packets are eligible for remapping only after receiving the feedback as a trigger). Instead, in this example, a particular packet 655 to QFI 7 in the first higher layer queue 602a (DRB 1) is identified as a critical packet. Critical packets may have time sensitive requirements and/or priorities associated therewith relative to other packets having QFI 7. For example, QFI 7 may carry both real-time transport protocol (RTP) and RTP control protocol (RTCP) packets. When certain conditions are met based on the network configuration, some packets (e.g., control data) may be eligible to be remapped to a different DRB.

When a critical packet is detected in the first queue 602a, the higher layer determines to shift the packet for QFI 7 from the first higher layer queue 602a (DRB 1) to the second higher layer queue 602b (DRB 2). The second higher layer queue 602b (DRB 2) may be, for example, a default destination for certain types of packets.

In another option, the UE 601 may shift the critical packets to a lower position in the first buffer 602a so that the critical packets may be sent faster on the mapped DRB 1.

In this example, UE 601 does not remap QoS flows of QFI 7 to DRB 2, e.g., does not include RDI bits. The gNB grants time critical QFI 7 packets on DRB 2.

Fig. 6d illustrates a method 670 for a UE 601 to shift one or more packets from a first DRB to a second DRB based on a critical state of the packets, in accordance with various exemplary embodiments. The method 670 of FIG. 6d is described with reference to diagram 650 of FIG. 6 c.

In 675, a packet (QoS flow), e.g., with QFI 1, is received in a first higher layer queue for the first (mapped) DRB and identified as a critical packet. Different types of critical packets, such as time sensitive and/or priority packets, may be identified.

In 680, the UE 601 (e.g., SDAP) determines to shift critical packets for the first QoS flow (QFI 1) from DRB 1 to DRB 2. The UE 601 may determine the packet shift based on the type of critical packet, configuration from the network, predefined rules, buffer status, etc. In other embodiments, the UE may shift the critical packet to a lower position in the current queue (DRB 1) instead of shifting to DRB 2.

In 685, UE 601 (e.g., SDAP) shifts critical packets for QFI 1 from DRB 1 to DRB 2. In this example, UE 601 does not include RDI bits indicating that the UE requests to remap QFI 1 from DRB 1 to DRB 2. In another option, the R bit is indicated to identify the presence of a mismatch QFI in a one-time fashion. In other words, the rerouting of QFI 1 on DRB 2 is considered an exception or special case.

In 690, UE 601 sends a packet for QFI 1 on DRB 2. The gNB 602 receives the packet and grants the packet based on the gNB policy rules. No remapping of QFI 1 is performed.

In yet another aspect of these exemplary embodiments, the UE may indicate the end of traffic indicator to the network. The end of traffic indicator may include an UL SDAP header with, for example, qfi=0 or qfi=0x3f (63) values. As shown in fig. 5e and 5c, the end of traffic indicator may be included in the UL SDAP data PDU or UL SDAP control PDU.

According to NAS specification TS24.501, the network should not set QFI 0, and thus qfi=0 is not allocated to the UE. In 5G NAS, QFI 0 is currently considered "syntax error" except for the PDU session modification procedure requested by the UE, in which if the QoS flow description is newly created, the UE shall set the QFI value to "unassigned QoS flow identifier" in the requested QoS flow description IE. Any QFI value between 0 and 63 is considered a valid QFI in accordance with the RAN3 and SA2 specifications. Note that the SDAP carries user plane Data (DRB) and the NAS carries control plane traffic (SRB) that configures QoS rules for PDU sessions, e.g., associated with the DRB.

According to another aspect of the exemplary embodiment, a particular QFI value may be declared a "special value" that may be used as an end-of-flow indicator for one or more qfs (after the QFI is dispensed). In a first option, the UE sets QFI to all 0 (or all 1) and sets the reserved bit to 1 (for data PDUs or control PDUs) in the UL SDAP header. The reserved bits are used as (optional) additional identifiers to represent the presence of a special QFI value or the presence of an end of traffic indication. This indicates that the UE no longer has new UL data in the foreseeable future and the network can use this data to immediately release the connection. In current operation, the network typically waits for a duration of inactivity, for example, about 10 seconds.

In this option, no new header field is introduced and only the QFI field is modified so that one or more QFI values are specified as "special" values indicating the end of the flow. That is, the detection of the flow end indication is based only on the QFI value. The reserved bit "R" in the SDAP header remains unchanged (0).

The UE may use the application or higher layer impact to determine or declare an end of traffic. For example, the UE may use this option immediately after receiving a TCP FIN from the application layer or after a socket (connection) is closed. Whether to release the connection is a network decision, but here the UE may provide advice to the network.

The UL SDAP header may be used to indicate the end of traffic for one or more DRBs. In the first option, the UE indicates the end of traffic (qfi=0 or 0x 3F) in any SDAP uplink packet, which is then valid for all DRBs. In a second option, the indication is defined on a per DRB basis. Some DRBs may be configured to use QFI 0 or qfi=0x3f as an end of traffic indicator, which applies to DRBs configured with this feature. In a third option, the R bit may be used, for example, in combination with a special QFI value or alone.

Some threshold regarding the frequency at which the end of traffic indicator may be transmitted may be configured at the UE side to avoid fluctuations between the end of traffic indicator and the Scheduling Request (SR) being transmitted continuously for a short time. In another option, UE assistance information may be sent via UL RRC to indicate to the network the intention to release the connection.

In other embodiments, the auxiliary information may be related to network implementation DATAINACTIVITYTIMER. The network may use this timer to trigger the release of the connection (and subsequent remapping of QoS flows/DRBs for the connection). The UE may share assistance information with the network to properly set DATAINACTIVITYTIMER based on the UE's knowledge of the data traffic characteristics. For example, in use cases such as periodic streaming, some content is typically acquired periodically (e.g., every "x" seconds). Different DATAINACTIVITYTIMER timers may be set for different DRBs.

Based on the assistance information provided by the UE, the network may determine to shorten or lengthen DATAINACTIVITYTIMER to avoid releasing the connection with, for example, infrequent periodic traffic. The network may further determine to shorten the timer to save power, optimize the effective system capacity in the cell, or set the timer to the most appropriate value from the UE's point of view.

In these example embodiments, the UE may indicate a suggested value or any update to DATAINACTIVITYTIMER of the gNB usage in the RRC UE assistance information based on the UE's knowledge of the traffic characteristics.

Fig. 7 illustrates a method 700 for UE-initiated operations for QoS flow-to-DRB remapping or packet shifting in accordance with various exemplary embodiments.

In 705, the UE receives or determines information related to current or expected upcoming data usage for one or more applications. As described above, in some embodiments, the UE modem may receive information (e.g., metrics, metadata) or commands (e.g., AT commands) from the application layer regarding current or upcoming changes to QoS requirements for different traffic flows. In other embodiments, the UE (SDAP/PDCP/RLC/MAC layer) may detect events such as a cache state or arrival of critical packets.

In 710, the UE determines, based on the received/determined information, that at least one packet of the QoS flow should be mapped/remapped or shifted to a new DRB. This may be in response to information from the application layer (e.g., application metrics, metadata, AT commands, etc.), packet detection by the application/SDAP layer (e.g., critical packets), indications from the RLC layer (e.g., higher buffering for LCH, high residence time, etc.), and/or buffer status, as described above. The UE actions are based on the type of information/event. For example, based on information from the application layer (e.g., expected upcoming high data usage on the first DRB), the SDAP may determine to remap QoS flows from the first DRB to the second DRB. In another example, if a high buffer status is triggered at a lower layer queue of a first DRB, the SDAP may determine to remap the QoS flow from the first DRB to a second DRB. In yet another example, if a critical packet is received at the SDAP, the SDAP may shift the critical packet from the first DRB to the second DRB without remapping the QoS flows of the critical packet.

In 715, the UE sends a request or otherwise initiates QoS flow remapping/shifting for one or more packets in the QoS flow and/or for the entire QoS flow. The UE may initiate the remapping request by sending the QFI on a different DRB than the current mapped DRB for the QFI. In some embodiments, the request may indicate an RDI bit (e.g., a reserved bit) in the UL SDAP header. The request may include UL SDAP data PDU (with UL data), UL SDAP data PDU (with dummy data), UL SDAP control PDU, UL RRC message, etc. In other embodiments, the UE may indicate QoS flow remapping for a particular packet in a one-time fashion (without requesting complete remapping).

The gNB may grant transmissions based on the gNB implementation. The gNB may configure the UE for certain UE-initiated QoS flow remapping/shifting operations based on the UE capabilities, and implement the gNB admission rules accordingly. The gNB may reconfigure the UE with a new QoS to DRB mapping table or simply update its own (shadow) mapping table. In some embodiments, the gNB may grant packets on different DRBs in a one-time fashion and not remap QoS flows for the packets.

In some embodiments, the UE may share assistance information with the network regarding current or upcoming traffic, either together with or separately from the QoS remapping described above. For example, the UE may determine to transmit an end of traffic indicator to the network. The end of traffic indicator may be associated with all currently configured DRBs or a subset of these DRBs. The end of flow indicator may include, for example, UL transmissions with QFI set to a particular value (e.g., qfi=0 or qfi=0x3f (63)). Reserved bits (e.g., RDI bits) in the UL SDAP header may also be used to indicate the end of the traffic (possibly in combination with a "special" QFI value if the RDI bits are used for a different purpose). Some thresholds regarding the frequency at which the end of traffic indicator may be transmitted may be configured at the UE side. The end of traffic indicator may also include a UE assistance message (e.g., UL RRC).

In other embodiments, the auxiliary information may be related to network implementation DATAINACTIVITYTIMER. The UE may share assistance information with the network to properly set DATAINACTIVITYTIMER based on the UE's knowledge of the data traffic characteristics. The UE may indicate the recommended value or any update to DATAINACTIVITYTIMER in UL RRC UE assistance information. Based on the assistance information provided by the UE, the network may determine to shorten or lengthen DATAINACTIVITYTIMER.

The UE may share this assistance information at any time and does not need to follow QoS flow remapping/shifting such as steps 710-715 described above.

Examples

In a first embodiment, a method is performed by a User Equipment (UE) that includes establishing a Protocol Data Unit (PDU) session including one or more quality of service (QoS) flows and a plurality of Data Radio Bearers (DRBs) for communicating with a network, determining an initial mapping table for QoS flows to DRBs mapping or receiving an initial mapping table for QoS flows to DRBs mapping based on a network configuration of mapping parameters, receiving or determining information about current or upcoming traffic on the one or more QoS flows or one or more DRBs, determining to map or remap a first QoS flow from a first DRB to a second DRB or to shift packets for the first QoS flow from the first DRB to the second DRB based on the information about current or upcoming traffic, and transmitting one or more packets for the first QoS flow on the second DRB.

In a second embodiment, the method of the first embodiment, wherein the information about current or upcoming traffic is determined at or received from an application layer of the UE.

In a third embodiment, the method of the second embodiment, wherein the information comprises metrics or metadata about traffic patterns for the current or upcoming traffic on the one or more QoS flows or one or more DRBs.

In a fourth embodiment, the method of the second embodiment, wherein the information comprises an Attention (AT) command indicating a current or upcoming change of QoS requirements for different traffic flows or requesting the UE to map or remap the first QoS flow from the first DRB to the second DRB or to shift packets for the first QoS flow from the first DRB to the second DRB.

In a fifth embodiment, the method of the second embodiment, wherein the first QoS flow comprises background traffic and the second DRB comprises a DRB having a lower QoS than the first DRB.

In a sixth embodiment, the method of the first embodiment, wherein the information about current or upcoming traffic is determined at or received from a Packet Data Convergence Protocol (PDCP) layer, a Radio Link Control (RLC) layer, a Medium Access Control (MAC) layer, or a Service Data Adaptation Protocol (SDAP) layer of the UE.

In a seventh embodiment, the method of the sixth embodiment further comprising receiving a configuration for a packet shift or QoS flow remapping feature from the network.

In an eighth embodiment, the method of the seventh embodiment, wherein the packet shift or QoS flow remapping feature comprises at least a buffer status threshold, a dwell time threshold, a Round Trip Time (RTT) threshold, a packet delay threshold, a PDU group delay threshold, a packet error rate, a PDU group error rate, a time-to-live event, or a retransmission threshold of the first DRB or a first lower layer first buffer associated with the first DRB, wherein an event is detected when one of the thresholds is exceeded.

In a ninth embodiment, the method of the eighth embodiment, wherein a lower layer provides feedback to the SDAP layer when the event for the first DRB or the first buffer is detected.

In a tenth embodiment, the method of the ninth embodiment, wherein based on the feedback, the SDAP layer determines to map or remap the first QoS flow from the first DRB to the second DRB.

In an eleventh embodiment, the method of the ninth embodiment, wherein based on the feedback, the SDAP layer determines to temporarily shift packets for the first QoS flow from the first DRB to the second DRB.

In a twelfth embodiment, the method of the seventh embodiment, wherein the packet shift or QoS flow remapping feature comprises an identification parameter of a critical packet or a special packet within the first QoS flow, wherein an event is detected at the SDAP layer when the critical packet or special packet is received at the SDAP layer.

In a thirteenth embodiment, the method of the twelfth embodiment, wherein when the event is detected at the SDAP layer, the SDAP layer determines to shift the critical or special packets within the first QoS flow from the first DRB to the second DRB, wherein the UE does not remap the first QoS flow to the second DRB, and continues to send other packets that are not the critical or special packets on the first DRB.

In a fourteenth embodiment, the method of the seventh embodiment, wherein the configuration for a packet shift or QoS flow remapping feature from the network further indicates a subset of DRBs that meet a configuration of the packet shift or QoS flow remapping feature condition.

In a fifteenth embodiment, the method of the seventh embodiment further comprising requesting the network to map or remap the first QoS flow from the first DRB to the second DRB using an Uplink (UL) SDAP header indicating a reserved bit, wherein the UL SDAP header is included with UL SDAP data PDUs, UL SDAP data PDUs including padding data, or UL SDAP control PDUs.

In a sixteenth embodiment, the method of the seventh embodiment further comprising shifting the packets for the first QoS flow from the first DRB to the second DRB using an Uplink (UL) SDAP header indicating a first QoS Flow Identifier (QFI) for the first QoS flow on the second DRB and sending the packets, wherein the network grants the first QFI on the second DRB based on the packet shift or QoS flow remapping characteristics.

In a seventeenth embodiment, the method of the first embodiment further comprises determining to shift packets for the first QoS flow from a current position in a higher layer queue to a lower position in the higher layer queue based on the information about current or upcoming traffic.

In an eighteenth embodiment, a processor is configured to perform any one of the methods according to the first to seventeenth embodiments.

In a nineteenth embodiment, a User Equipment (UE) includes a transceiver configured to communicate with a network and a processor communicatively coupled to the transceiver and configured to perform any of the methods according to the first through seventeenth embodiments.

In a twentieth embodiment, a method performed by a base station includes establishing a Protocol Data Unit (PDU) session including one or more quality of service (QoS) flows and a plurality of Data Radio Bearers (DRBs) for communication with a User Equipment (UE), indicating mapping parameters for the UE to determine an initial mapping table for QoS flow to DRB mapping, configuring the UE for a packet shift or QoS flow remapping feature, wherein the packet shift or QoS flow remapping feature allows the UE to receive or determine information about current or upcoming traffic on the one or more QoS flows or one or more DRBs and to determine to map or remap a first QoS flow from a first DRB to a second DRB or to shift packets for the first QoS flow from the first DRB to the second DRB based on the information about current or upcoming traffic, and receiving one or more packets for the first QoS flow on the second DRB.

In a twenty-first embodiment, the method of the twentieth embodiment, wherein the configuration for a packet shift or QoS flow remapping feature further indicates a subset of DRBs that meet a configuration of the packet shift or QoS flow remapping feature condition.

In a twenty-second embodiment, the method of the twentieth embodiment further comprises receiving a request from the UE to map or remap the first QoS flow from the first DRB to the second DRB using an Uplink (UL) SDAP header indicating a reservation bit, wherein the UL SDAP header is included with UL SDAP data PDUs, UL SDAP data PDUs including padding data, or UL SDAP control PDUs, and remapping the first QoS flow from the first DRB to the second DRB in response to the request.

In a twenty-third embodiment, the method of the twentieth embodiment further comprises receiving a packet with an Uplink (UL) SDAP header indicating a first QoS Flow Identifier (QFI) for the first QoS flow on the second DRB and granting the first QFI on the second DRB based on the packet shift or QoS flow remapping features.

In a twenty-fourth embodiment, a processor is configured to perform any of the methods according to the twentieth to twenty-third embodiments.

In a twenty-fourth embodiment, a base station comprises a transceiver configured to communicate with a User Equipment (UE), and a processor communicatively coupled to the transceiver and configured to perform any of the methods of the twentieth to twenty-third embodiments.

Those skilled in the art will appreciate that the exemplary embodiments described above may be implemented in any suitable software configuration or hardware configuration or combination thereof. Exemplary hardware platforms for implementing the exemplary embodiments may include, for example, intel x86 based platforms with compatible operating systems, ARM based platforms, AMD based platforms, windows OS, LINUX based OS, mac platforms and MAC OS, mobile devices with operating systems such as iOS, android, and the like. The exemplary embodiments of the above-described methods may be embodied as a program comprising code lines stored on a non-transitory computer readable storage medium, which when compiled, may be executed on a processor or microprocessor.

While the application has been described in terms of various embodiments each having different features in various combinations, those of skill in the art will recognize that any feature of one embodiment may be combined with features of other embodiments in any manner not specifically negated or functionally or logically inconsistent with the operation of the apparatus or the prescribed functionality of the disclosed embodiments.

It is well known that the use of personally identifiable information should follow privacy policies and practices that are recognized as meeting or exceeding industry or government requirements for maintaining user privacy. In particular, personally identifiable information data should be managed and handled to minimize the risk of inadvertent or unauthorized access or use, and the nature of authorized use should be specified to the user.

It will be apparent to those skilled in the art that various modifications can be made to the present disclosure without departing from the spirit or scope of the disclosure. Accordingly, it is intended that the present disclosure cover modifications and variations of this disclosure provided they come within the scope of the appended claims and their equivalents.

Claims

1. An apparatus of a user equipment (UE), the apparatus comprising a processing circuit, the processing circuit being configured to:

establishing a protocol data unit (PDU) session, the PDU session comprising a plurality of data radio bearers (DRBs) and one or more quality of service (QoS) flows for communicating with a network;

determining, according to signaling received from the network, an initial mapping table for QoS flow to DRB mapping based on a network configuration of mapping parameters or decoding an initial mapping table for QoS flow to DRB mapping;

decoding or determining information about current or upcoming traffic on the one or more QoS flows or one or more DRBs based on signaling received from the network;

Determining, based on the information about current or upcoming traffic, to map or remap a first QoS flow from a first DRB to a second DRB or to shift packets for the first QoS flow from the first DRB to the second DRB; and

The transceiver circuitry is configured to transmit one or more packets for the first QoS flow on the second DRB.

2 . The apparatus according to claim 1 , wherein the information about the current or upcoming traffic is determined at an application layer of the UE or received from the application layer.

3. The apparatus of claim 2, wherein the information comprises metrics or metadata regarding traffic patterns for the current or upcoming traffic on the one or more QoS flows or one or more DRBs.

4. An apparatus according to claim 2, wherein the information includes an attention (AT) command, which indicates a current or upcoming change in QoS requirements for different traffic flows or requests the UE to map or remap the first QoS flow from the first DRB to the second DRB or shift packets for the first QoS flow from the first DRB to the second DRB.

5. The apparatus of claim 2, wherein the first QoS flow comprises background traffic, and the second DRB comprises a DRB having a lower QoS than the first DRB.

6. The apparatus of claim 1 , wherein the information about current or upcoming traffic is determined at or received from one of: a Service Data Adaptation Protocol (SDAP) layer, a Packet Data Convergence Protocol (PDCP) layer, a Radio Link Control (RLC) layer, or a Medium Access Control (MAC) layer of the UE.

7. The apparatus of claim 6, wherein the processing circuit is further configured to:

Configuration for packet shifting or QoS flow remapping features is decoded from signaling received from the network.

8. An apparatus according to claim 7, wherein the packet shift or QoS flow remapping feature includes a retransmission threshold, a buffer status threshold, a residence time threshold, a round-trip time (RTT) threshold, a packet delay threshold, a PDU group delay threshold, a packet error rate, a PDU group error rate or a survival time event for a first buffer of at least the first DRB or a first lower layer associated with the first DRB, wherein an event is detected when one of the thresholds is exceeded.

9 . The apparatus of claim 8 , wherein when the event for the first DRB or the first buffer is detected, a lower layer provides feedback to the SDAP layer.

10. The apparatus of claim 9, wherein based on the feedback, the SDAP layer determines to map or remap the first QoS flow from the first DRB to the second DRB.

11. The apparatus of claim 9, wherein based on the feedback, the SDAP layer determines to temporarily shift packets for the first QoS flow from the first DRB to the second DRB.

12. The apparatus of claim 7, wherein the packet shift or QoS flow remapping feature comprises an identification parameter of a critical packet or a special packet within the first QoS flow, wherein an event is detected at the SDAP layer when the critical packet or the special packet is received at the SDAP layer.

13. An apparatus according to claim 12, wherein when the event is detected at the SDAP layer, the SDAP layer determines to shift the critical packet or special packet within the first QoS flow from the first DRB to the second DRB, wherein the UE does not remap the first QoS flow to the second DRB and continues to send other packets that are not the critical packet or special packet on the first DRB.

14. The apparatus of claim 7, wherein the configuration from the network for a packet shift or QoS flow remapping feature further indicates a subset of configured DRBs that qualify for the packet shift or QoS flow remapping feature.

15. The apparatus of claim 7, wherein the processing circuit is further configured to:

The transceiver circuit is configured to send a request to the network to map or remap the first QoS flow from the first DRB to the second DRB using an uplink (UL) SDAP header indicating a reserved bit, wherein the UL SDAP header is included together with a UL SDAP data PDU, a UL SDAP data PDU including padding, or a UL SDAP control PDU.

16. The apparatus of claim 7, wherein the processing circuit is further configured to:

shifting the packets for the first QoS flow from the first DRB to the second DRB; and

The transceiver circuit is configured to send the packet using an uplink (UL) SDAP header indicating a first QoS flow identifier (QFI) for the first QoS flow on the second DRB, wherein the network grants the first QFI on the second DRB based on the packet shift or QoS flow remapping feature.

17. The apparatus of claim 1, wherein the processing circuit is further configured to:

A determination is made based on the information about current or upcoming traffic to shift packets for the first QoS flow from a current position in a higher layer queue to a lower position in the higher layer queue.

18. A base station device, the device comprising a processing circuit, the processing circuit being configured to:

establishing a protocol data unit (PDU) session comprising a plurality of data radio bearers (DRBs) and one or more quality of service (QoS) flows for communicating with a user equipment (UE);

Indicating a mapping parameter for the UE to determine an initial mapping table for QoS flow to DRB mapping;

configuring the UE for a packet shift or QoS flow remapping feature, wherein the packet shift or QoS flow remapping feature enables the UE to receive or determine information about current or upcoming traffic on the one or more QoS flows or one or more DRBs and determine, based on the information about the current or upcoming traffic, to map or remap a first QoS flow from a first DRB to a second DRB or to shift packets for the first QoS flow from the first DRB to the second DRB; and

One or more packets for the first QoS flow on the second DRB are decoded based on the signal received from the UE.

19. The apparatus of claim 18, wherein the configuration for a packet shift or QoS flow remapping feature further indicates a subset of the configured DRBs that are eligible for the packet shift or QoS flow remapping feature.

20. The apparatus of claim 19, wherein the processing circuit is further configured to:

decoding, according to a signal received from the UE, a request for mapping or remapping the first QoS flow from the first DRB to the second DRB using an uplink (UL) SDAP header indicating a reserved bit, wherein the UL SDAP header is included with a UL SDAP data PDU, a UL SDAP data PDU including padding, or a UL SDAP control PDU; and

The first QoS flow is remapped from the first DRB to the second DRB in response to the request.

21. The apparatus of claim 19, wherein the processing circuit is further configured to:

decoding a packet having an uplink (UL) SDAP header indicating a first QoS flow identifier (QFI) for the first QoS flow on the second DRB based on a signal received from the UE; and

The first QFI on the second DRB is granted based on the packet shift or QoS flow remapping characteristics.