Influence of higher layers on QoS flow to DRB mapping

Abstract

A user equipment (UE) configured to establish a protocol data unit (PDU) session, the PDU session comprising one or more quality of service (QoS) flows and a plurality of data radio bearers (DRBs) for communication with a network; decoding according to the signaling received from the network or determining an initial mapping table for mapping from the QoS flow to the DRB based on the network configuration of the mapping parameters; decoding according to signaling received from the network or determining information about current or upcoming traffic on the one or more QoS flows or the one or more DRBs; determining to map or remap a first QoS flow from a first DRB to a second DRB or 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 configuring a transceiver circuit to transmit one or more packets for the first QoS flow on the second DRB.

Description

[0001] Priority / Incorporated by Reference

[0002] This application claims priority to U.S. Provisional Application Serial No. 63 / 370,754, filed on August 8, 2022, and entitled “Higher Layer Influence on QoS Mapping,” the entire contents of which are incorporated herein by reference. Background Art

[0003] 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 extended reality (XR) or industrial Internet of Things (IIoT) services via a 5G NR radio access network (RAN) and a 5G core (5GC). During operation, some services may utilize multiple parallel data streams in an uplink (UL) and / or downlink (DL). For example, in XR, there may be video streams, audio streams, and / or other data streams in the DL, and there may be control streams, gesture streams, and / or other data streams in the UL. These data streams may be associated with multiple parallel QoS streams. For these data streams sent in parallel, some flows may have high throughput and low latency requirements, while other flows may have more relaxed requirements.

[0004] According to the current specification, only the network / gNB can trigger the update of QoS flow to DRB mapping for UL and DL traffic. However, depending on the mapping of QoS flows to logical channels, the data queue on the UE side can be filled up very quickly. When some packets do not arrive within the latency bound, delays on one or more DRBs may lead to degradation of service and / or user experience.

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

[0006] Some exemplary embodiments relate to a device of a user equipment (UE) having a processing circuit configured to: establish a protocol data unit (PDU) session including one or more quality of service (QoS) flows and multiple data radio bearers (DRBs) for communicating with a network; determine an initial mapping table for QoS flow to DRB mapping or decode an initial mapping table for QoS flow to DRB mapping based on a 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 the current or upcoming traffic; and configure a transceiver circuit to send one or more packets for the first QoS flow on the second DRB.

[0007] Other exemplary embodiments relate to a processor configured to: establish a protocol data unit (PDU) session comprising one or more quality of service (QoS) flows and multiple data radio bearers (DRBs) for communicating with a network; determine an initial mapping table for QoS flow to DRB mapping or decode an initial mapping table for QoS flow to DRB mapping based on a network configuration of mapping parameters based on 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 based on 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 the current or upcoming traffic; and configure a transceiver circuit to send one or more packets for the first QoS flow on the second DRB.

[0008] Still another exemplary embodiment relates to a base station device having a processing circuit configured to: establish a protocol data unit (PDU) session including one or more quality of service (QoS) flows and multiple data radio bearers (DRBs) for communicating with a user equipment (UE); indicate mapping parameters for the UE to determine an initial mapping table for mapping QoS flows to DRBs; 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, 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 decode one or more packets for the first QoS flow on the second DRB based on a signal received from the UE.

[0009] Additional exemplary embodiments relate to a processor configured to: establish a protocol data unit (PDU) session comprising one or more quality of service (QoS) flows and multiple data radio bearers (DRBs) for communicating with a user equipment (UE); indicate mapping parameters for the UE to determine 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, 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 decode one or more packets for the first QoS flow on the second DRB based on a signal received from the UE. BRIEF DESCRIPTION OF THE DRAWINGS

[0010] Figure 1 Exemplary network arrangements are shown according to various exemplary embodiments.

[0011] Figure 2 An exemplary user equipment (UE) is shown in accordance with various exemplary embodiments.

[0012] Figure 3 An exemplary base station according to various exemplary embodiments is shown.

[0013] Figure 4Exemplary network arrangements for QoS flows and DRB mapping according to various exemplary embodiments are shown.

[0014] Figure 5a A diagram showing QoS flow mapping for the SDAP layer according to various exemplary embodiments is shown.

[0015] Figure 5b A DL SDAP header is shown according to various exemplary embodiments.

[0016] Figure 5c A UL SDAP header is shown according to various exemplary embodiments.

[0017] Figure 5d A DL SDAP data PDU format with a DL SDAP header according to various exemplary embodiments is shown.

[0018] Figure 5e A UL SDAP Data PDU format with a UL SDAP header according to various exemplary embodiments is shown.

[0019] Figure 6a An exemplary diagram is shown 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.

[0020] Figure 6b Methods for a UE to remap packets from a first DRB to a second DRB based on a buffer status according to various exemplary embodiments are shown.

[0021] Figure 6c An exemplary diagram is shown for a UE to shift one or more packets from a first DRB to a second DRB based on a critical status of the packets according to various exemplary embodiments.

[0022] Figure 6d Methods for a UE to shift one or more packets from a first DRB to a second DRB based on a critical status of the packets according to various exemplary embodiments are shown.

[0023] Figure 7 Methods of UE-initiated operations for QoS flow to DRB remapping or packet shifting according to various exemplary embodiments are shown. DETAILED DESCRIPTION

[0024] The exemplary embodiments may be further understood with reference to the following description and associated drawings, in which like elements are provided with like reference numerals. The exemplary embodiments relate to an operation for a user equipment (UE) to initiate a remapping or packet shifting of a quality of service (QoS) flow to a data radio bearer (DRB) based on information determined or received by the UE. In particular, the UE may take into account 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 a QoS flow remapping, a packet shift (to another DRB), or UE assistance information for the network to make a QoS flow or DRB-related decision. Alternatively, the UE may also take into account information / commands / configurations received from the network when initiating a QoS flow to DRB remapping or packet shifting. In addition, packet shifting may be combined with active queue management (AQM) principles.

[0025] In some scenarios, including Internet Protocol (IP) and / or Ethernet data traffic for extended reality (XR) or Industrial Internet of Things (IIoT) services, multiple QoS flows with different throughput and / or latency requirements may be sent in parallel on multiple DRBs. The latency 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 shift packets to different DRBs.

[0026] According to some aspects, the UE may receive information / commands from the application layer regarding current or upcoming traffic for / 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, for example, high buffer status of DRB / LCH, high round trip time (RTT), a large number of retransmissions (at the RLC or HARQ level), the UE is close to the packet delay budget (PDB) for a given data flow (e.g., based on the 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 5QI / QFI), PDU group delay threshold, packet error rate, PDU group error rate, the UE has entered a survival time state, and other events related to the transmission time or delay time of packets on the DRB / LCH. The UE may determine to initiate remapping of a QoS flow to a different DRB, or shift some packets to different DRBs without remapping the QoS flow. In still other aspects, the UE may provide auxiliary information to the network, for example, in 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 a particular QoS flow and / or DRB.

[0027] Exemplary embodiments relate to enhancements for extended reality (XR) or industrial internet of things (IIoT) applications. Those skilled in the art will understand that XR is an umbrella term for different types of reality, and may generally refer to real and virtual combined environments and associated human-computer interactions generated by computer technology and wearable devices. To provide some examples, the term XR may cover augmented reality (AR), mixed reality (MR), and virtual reality (VR). However, any reference to XR specific to a particular traffic use case or type is provided for illustrative purposes only. Those skilled in the art will understand that IIoT relates to industrial applications, including, for example, production, robotics, and / or medical, which may be implemented in a time-sensitive network (TSN) with low latency requirements. Although some embodiments in 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.

[0028] 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 stream may have different quality of service (QoS) requirements (e.g., block error rate (BLER) requirements, latency requirements, etc.). Additionally, a UE may send data on the UL, which is forwarded to another UE on the DL, or send data directly to another UE via, for example, a side link (SL) or WiFi.

[0029] In addition, the exemplary embodiments are described with respect to UE. Those skilled in the art will understand that the UE may be any type of electronic component configured to communicate via a network, such as a mobile phone, a tablet computer, a desktop computer, a smart phone, a tablet phone, an embedded device, a wearable device, an Internet of Things (IoT) device, etc. With regard to 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 data to a wearable device (e.g., AR, VR, MR, etc.) that presents 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. Therefore, the UE as described herein is used to represent any electronic component that communicates directly with the network.

[0030] Figure 1 An exemplary network arrangement 100 according to various exemplary embodiments is shown. The exemplary network arrangement 100 includes a UE 110. Those skilled in the art will appreciate that the UE 110 may be any type of electronic component configured to communicate via a network, such as a mobile phone, a tablet computer, a desktop computer, a smart phone, a tablet phone, an embedded device, a wearable device (e.g., HMD, AR glasses, etc.), an Internet of Things (IoT) device, an Industrial IoT (IIoT) device, etc. It should also be understood that an actual network arrangement may include any number of UEs used by any number of users. Therefore, the example of a single UE 110 is provided for illustrative purposes only.

[0031] UE 110 may be configured to communicate with one or more networks. In the 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., 5G cloud RAN, next generation RAN (NG-RAN), long term evolution (LTE) RAN, traditional cellular networks, WLAN, etc.), and UE 110 may also communicate with the network via a wired connection. Referring to the exemplary embodiment, UE 110 may establish a connection with 5G NR RAN 120. Therefore, UE 110 may have a 5G NR chipset to communicate with NR RAN 120.

[0032] The 5G NR RAN 120 may be part of a cellular network that may be deployed by a network operator such as Verizon, AT&T, T-Mobile, etc. The 5G NR RAN 120 may include, for example, cells or base stations (Node B, eNodeB, HeNB, eNB, gNB, gNodeB, macro cell, micro cell, small cell, femto cell, etc.) configured to transmit and receive traffic from UEs equipped with appropriate cellular chipsets.

[0033] 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 at which UE 110 and / or its user has 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 described above, reference to 5G NR-RAN 120 is for illustrative purposes only, and any suitable type of RAN may be used.

[0034] The network arrangement 100 also includes 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 can be viewed as an interconnected collection of components that manage the operation and traffic of the cellular network. The cellular core network 130 also manages the traffic flowing between the cellular network and the Internet 140. The IMS 150 can be generally described as an architecture for delivering multimedia services to the UE 110 using the IP protocol. The IMS 150 can communicate with the cellular core network 130 and the Internet 140 to provide multimedia services to the UE 110. The network service backbone 160 communicates directly or indirectly with the Internet 140 and the cellular core network 130. The network service backbone 160 can be generally described as a collection of components (e.g., servers, network storage arrangements, etc.) that implement a set of services that can be used to extend the functionality of the UE 110 to communicate with various networks.

[0035] Figure 2 FIG. 1 shows an exemplary UE 110 according to various exemplary embodiments. UE 110 sends information about Figure 1 100. 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, an audio input device, an audio output device, a power supply, a data acquisition device, a port for electrically connecting UE 110 to other electronic devices, etc.

[0036] The processor 205 may be configured to execute a plurality of engines of the UE 110. For example, the engines 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, which 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 auxiliary information about current or expected upcoming data usage to the network, which will be described in detail below.

[0037] The engine 235 referenced above is provided as an application (e.g., program) executed by the processor 205 for illustrative purposes only. The functionality associated with the engine 235 may also be represented as a separate combined component of the UE 110, or may be a modular component coupled to the UE 110, such as an integrated circuit with or without firmware. For example, the integrated circuit may include an input circuit system for receiving a signal and a processing circuit system for processing signals and other information. The engine may also be embodied as an application or multiple separate applications. In addition, in some UEs, the functionality described for the 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.

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

[0039] The transceiver 225 may be a hardware component configured to establish a connection with the 5G NR-RAN 120 and / or any other appropriate type of network. Thus, the transceiver 225 may operate on a variety of different frequencies or channels (e.g., a continuous frequency set). The transceiver 225 may include advanced receivers for MU-MIMO (e.g., E-MMSE-RC, R-ML, etc.). The transceiver 225 includes a circuit configured to send and / or receive signals (e.g., control signals, data signals). Such signals may be encoded with information for 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 send 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.

[0040] Figure 3 An exemplary base station 300 is shown 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.

[0041] Base station 300 may include processor 305, memory arrangement 310, input / output (I / O) devices 315, transceiver 320, and other components 325. Other components 325 may include, for example, batteries, data acquisition devices, ports for electrically connecting base station 300 to other electronic devices, and the like.

[0042] The processor 305 may be configured to execute a plurality of engines of the base station 300. For example, the engines 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, which 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 thereon, which will be described in detail below.

[0043] The engine 330 described above as an application (e.g., a program) executed by the processor 305 is merely exemplary. 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, such as an integrated circuit with or without firmware. For example, the integrated circuit may include an input circuit system for receiving signals and a processing circuit system for processing signals and other information. In addition, in some base stations, the functionality described for the processor 305 is split between multiple processors (e.g., a baseband processor, an application processor, etc.). The exemplary embodiments may be implemented in any of these or other configurations of the base station.

[0044] The memory 310 may be a hardware component configured to store data related to operations performed by the 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.

[0045] The transceiver 320 may be a hardware component configured to exchange data with the UE 110 and any other UE in the system 100. The transceiver 320 may operate on a variety of different frequencies or channels (e.g., a continuous frequency set). Therefore, the transceiver 320 may include one or more components (e.g., radio devices) to enable data exchange with various networks and UEs. The transceiver 320 includes a circuit configured to send and / or receive signals (e.g., control signals, data signals). Such signals may be encoded with information that implements any of the methods described herein. The processor 305 may be operably coupled to the transceiver 320 and configured to receive signals from the transceiver 320 and / or send signals to the transceiver. The processor 305 may be configured to encode and / or decode signals (e.g., signaling from the UE) for implementing any of the methods described herein.

[0046] In XR (and / or cloud gaming), application traffic on the downlink (DL) may include encoded video or scene information. Some XR applications may require application data to be available at a minimum granularity on the client side before performing the next level of processing. For example, in some configurations, client processing of application data may only begin when all bits of a video frame, or a certain percentage of those bits, are available to the client device. This application data may be, for example, a video frame, which may be grouped into multiple IP payloads.

[0047] This minimum information granularity required for a given application may be referred to as an "application data unit" (ADU) or PDU set. XR (and / or cloud gaming) traffic includes traffic bursts that may carry one or more ADU or PDU sets. Each ADU or PDU set may include several PDUs or packets, such as 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. Therefore, the size of an ADU or PDU set may vary depending on the XR application. It should be understood that three or four IP packets are examples, and an 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 embodiment is not limited to XR or IIoT services, and provides enhancements to the 5G user plane that are general and applicable to any type of service. In addition, the exemplary embodiment is 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.

[0048] 5G-RAN and 5GC ensure quality of service (QoS) by mapping packets to appropriate QoS flows and DRBs. The entities involved in the packet handling of downlink (DL) data and uplink (UL) data of the UE typically include the user plane function (UPF) of the 5GC (e.g., an instance of the UPF), the base station (gNB), and the UE. Each of these entities identifies certain information about the packet before processing it. Some access stratum (AS) packet processing functions are performed at the service data adaptation protocol (SDAP) layer of the gNB / UE.

[0049] The UPF acts as an external PDU session point interconnected with the DN and can perform packet routing and forwarding, perform packet inspection, enforce the user plane part of policy rules, lawfully intercept packets (UP collection), perform traffic usage reporting, perform QoS handling on the user plane (e.g., packet filtering, gating, UL / DL rate enforcement), perform uplink traffic validation (e.g., SDF to QoS flow mapping), send level packet marking in uplink and downlink, and perform downlink packet buffering and downlink data notification triggering.

[0050] Figure 4 An exemplary network arrangement 400 for QoS flows and DRB mapping according to various exemplary embodiments is shown. The network arrangement 400 includes a UE 405, a gNB 410, and a UPF 415. QoS flows and DRB mapping for downlink traffic flows including multiple data flows are described herein. However, those skilled in the art understand that similar supplementary processes may also occur on the uplink.

[0051] In the first step of DL packet handling, at the non-access stratum (NAS) level, the UPF 415 receives an IP data stream 420 from a data network (DN) via one or more PDU sessions. Each PDU session may correspond to a connection to a different data network (DN) and / or the Internet. Figure 4 In the example of , UPF 415 receives a first IP stream (IP1), a second IP stream (IP2), a third IP stream (IP3), and a fourth IP stream (IP4) via a first set (PDU 1) of PDU sessions. The first set of PDU sessions may include, for example, an Internet PDU session, and IP streams 1-4 may correspond to video streams, such as YouTube or Skype video streams. UPF 415 receives a fifth IP stream (IP5) via a second set (PDU 2) of PDU sessions (e.g., a streaming service PDU session), and IP5 may correspond to a video stream, such as a Netflix stream. UPF 415 receives a sixth IP stream (IP6) and a seventh IP stream (IP7) via a third set (PDU 3) of PDU sessions. The third set of PDU sessions may include, for example, an IMS PDU session, 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 the streams are not limited to any particular type of data stream.

[0052] The UPF 415 processes the received packets using a service data flow (SDF) traffic filter template (e.g., packet filter). The UPF 415 maps the IP flow to the QoS flow based on the packet detection rules (PDR) configured by the 5GC. The 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. Figure 4In the example, IP1 is mapped to the first QoS flow (QFI=1), IP2 and IP3 are mapped to the second QoS flow (QFI=2), IP4 is mapped to the third QoS flow (QFI=3), IP5 is mapped to the fourth QoS flow (QFI=4), IP6 is mapped to the fifth QoS flow (QFI=5), and IP7 is mapped to the sixth QoS flow (QFI=6).

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

[0054] Separate DRBs may be established for QoS flows that require different packet forwarding treatments, 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). Figure 4 In the example, the first QoS flow is mapped to the first DRB (DRB=1), the second QoS flow and the third QoS flow are mapped to the second DRB (DRB=2), the fourth QoS flow is mapped to the third DRB (DRB=3), the fifth QoS flow is mapped to the fourth DRB (DRB-4), and the sixth QoS flow is mapped to the fifth DRB (DRB=5). Several QoS flows belonging to the same PDU session can be mapped to the same DRB, while QoS flows belonging to different PDU sessions cannot be mapped to the same DRB.

[0055] In the third step, at the UE level, the UE 405 receives the data in the DRB via one or more instances of the SDAP layer over the air interface. The QoS flow is mapped to the IP flow by the 5GSM layer according to the packet filters contained in the QoS rules configured by the 5GC. The PDR at the UPF 415 and the QoS rules at the UE 405 may include similar and complementary packet filters. Therefore, the original IP packet is extracted and delivered to a higher layer. It should be understood 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.

[0056] As described above, QoS flow to DRB mapping is performed at the RAN / gNB (Access Stratum (AS)) at the SDAP layer. Several QoS flows belonging to the same PDU session can be mapped to the same DRB, while QoS flows belonging to different PDU sessions cannot be mapped to the same DRB. The RAN can add new DRBs with corresponding QFI mappings to meet the QoS characteristics of the QoS flows. The UE determines the UL data QoS bundling via explicit RRC signaling or via reflective QoS (RQoS) based on the DL data QoS marking, which will be described in more detail below.

[0057] Exemplary embodiments relate to extensions of the QoS flow to DRB mapping steps described above. Exemplary techniques may enable more dynamic QoS adaptation and related user plane enhancements. Some techniques may also facilitate better handling of groups of packets characterized by PDU aggregation or ADU-based QoS.

[0058] The mapping between QoS flows and DRBs may be determined by the gNB and may include explicit signaling or reflected QoS (RQoS). In the explicit mapping technique, the gNB uses RRC signaling (e.g., explicit QoS signaling) to indicate which QoS flow is transmitted over which DRB for the UE's UL traffic. In the reflected QoS technique, the gNB includes an indication, such as an RDI bit, in the DL packet that triggers the UE to update its UL mapping table based on the QFI and DRB used for the DL packet. The UE monitors the DL traffic to determine on which DRB the QoS flow is received, and after receiving the RDI bit and QFI / PQFI and the UE updates its mapping table, the UE transmits the UL traffic over the same DRB and with the same QoS flow. These techniques enable 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 treatment for some packets with a single QoS flow.

[0059] As described above, an SDAP entity is established at the UE and 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 flow is transmitted over which DRB, including DL and UL mapping rules. When reflective UL mapping is used, the UE SDAP updates its UL mapping table based on the QFI of the received DL packet, which will be described below. If no mapping rules are defined, the UE uses the default DRB for the QoS flow. The SDAP of the sending entity (UE or gNB) may add an SDAP header to mark the QFI in the UL or DL ​​data packet for various reasons as described below.

[0060] Figure 5aA diagram 500 of QoS flow mapping for the SDAP layer is shown according to various exemplary embodiments. The diagram 500 includes a sending SDAP entity 502 (e.g., a UE or a gNB) receiving a QoS flow from a higher layer (e.g., an application layer (for UL traffic at the UE) or a UPF (for DL ​​traffic at the gNB)) and mapping the QoS flow to a DRB based on a QoS flow mapping configuration. If the SDAP header is configured for the DRB, the sending SDAP entity 502 adds the SDAP header before sending over the Uu interface. Whenever reflective QoS is enabled, an SDAP header is configured on the UL or DL ​​DRB, and when more than one QoS flow is mapped to the same DRB, the SDAP header is configured on the UL DRB. The receiving SDAP entity 504 (e.g., a UE or a gNB) processes the packet and, if the SDAP header is configured, performs reflective QoS flow to DRB mapping, removes the SDAP header, and sends the QoS flow to the UPF (for UL traffic at the gNB) or 5GSM (for DL ​​traffic at the UE).

[0061] On DL, the gNB may add QFI (QoS Flow Indication) and RQI (Reflective QoS Indication) and / or RDI (Reflective QoS Flow to DRB Mapping Indication) in the DL SDAP header. The DL header is only required when reflective mapping is used, which is optional for the gNB.

[0062] Figure 5b A DL SDAP header 510 according to various exemplary embodiments is shown. The DL SDAP header 510 includes an octet (one byte) having 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.

[0063] On UL, the UE may add QFI and D / C (Data / Control) in the UL SDAP header. When more than one QoS flow is mapped to a DRB, a UL header is required (to indicate which QoS flow the DRB carries).

[0064] Figure 5c A UL SDAP header 515 is shown according to various exemplary embodiments. The UL SDAP header 530 includes an octet (one byte) having a QFI field (6 bits), a D / C bit, and a reserved (R) bit. The D / C bit may indicate whether the SDAP header carries a UL SDAP control PDU or a UL SDAP data PDU. Currently, one bit of the UL SDAP header is not allocated to a parameter (reserved (R) bit).

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

[0066] TS 37.324 defines the UL SDAP end marker control PDU. The SDAP end marker control PDU is for SDAP and applies only to QoS at the access layer (AS) level. There is no associated timer. The end marker can be used when the QoS flow to DRB mapping changes and is applicable to both reflective and RRC configured QoS mapping (see TS 38.300, TS 37.324, TS38.331).

[0067] Reflective QoS (RQoS) at the AS level allows the network to use the RDI field to steer specific QoS flows from one DRB to another, for example, to enhance QoS treatment in a time window.

[0068] Figure 5d A DL SDAP data PDU format 520 is shown with a DL SDAP header 510 according to various exemplary embodiments. When the RDI bit is set in the DL SDAP header 510, a UE receiving the PDU 520 may update its mapping table for UL transmissions for the same QFI.

[0069] UL packets belonging to the same QFI are directed by the UE to the same DRB where the DL packet 520 was received. 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 the QFI. The UL Control PDU 515 indicates to the network that no more packets belonging to the (remapped) QFI will be sent from this point forward over the old DRB.

[0070] Figure 5e A UL SDAP data PDU format 525 with a UL SDAP header 515 is shown according to various exemplary embodiments. When the QFI is set in the UL SDAP header 515, the gNB can distinguish multiple QoS flows mapped to a single DRB.

[0071] As mentioned above, traffic consisting of multiple modalities (e.g., video, data, control, audio, etc.) typically requires data to be sent 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 queues (buffers) on the UE side can then fill up very quickly. In addition, the delay of one DRB may result in a degraded user experience because the processing of packets exceeds the acceptable latency range.

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

[0073] 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 able to request or initiate remapping of QoS flows to DRBs, for example based on techniques outside the scope of the present disclosure and briefly discussed herein. In another example, a QoS flow may be mapped to multiple DRBs (the limitation that a 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 when necessary. Assuming some future enhancements to the QoS mapping framework, the UE may be able to utilize inputs from higher layers to trigger mapping of QoS flows within the network and / or optimize periods of data inactivity to prevent excessive usage of system resources.

[0074] According to various exemplary embodiments described herein, the 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 about current or expected upcoming data usage from the application layer. In other embodiments, a current or expected upcoming delay on a DRB, or the UE does not meet the QoS requirements, may trigger the UE to remap one or more UL packets for a QoS flow to a DRB different from the DRB mapped for the QoS flow based on, for example, the LCH buffer status for the DRB. In some embodiments, active queue management (AQM) techniques may be used, for example, to warn UEs of high buffer status (or high buffer residence time) of DRB / LCH. In some embodiments, packets may be shifted to different DRBs based on, for example, buffer status, buffer residence time, QoS mismatch, or the reception of time-sensitive (critical) packets, without initiating a complete remapping of the QoS flow. In still other embodiments, a traffic end indicator and / or a data inactivity timer indicator may be used to suggest that the network perform QoS adaptation.

[0075] The UE has more accurate information about its currently active applications and typical data traffic activity than the network. Therefore, the UE can better predict whether a particular QFI will require higher or lower QoS at a given point in time (which may be associated with different DRBs). The UE can further predict how long the QoS remapping should last (e.g., in a temporary short sequence of data activity on other common bearers), whether the traffic pattern is bursty or a one-off activity, etc.

[0076] 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 essentially outside the scope of the present disclosure, but it is assumed that such a mechanism is available. In some of the embodiments currently described, certain types of UE-initiated remapping mechanisms are considered. In one example, the UE may initiate UL reflective QoS, in which the UE sends a QoS flow and a remapping indication (e.g., an RDI bit) on a DRB different from the currently mapped DRB. In another example, the UE may temporarily shift the packet to another DRB without initiating a complete remapping. In another example, the UE may use UL RRC signaling (e.g., a UE assistance information message) to request remapping.

[0077] In addition, the current 5G QoS model does not allow the same QoS flow on multiple DRBs. In order to make the solution described in this article more efficient, the network restriction that a QoS flow can be mapped to one and only one DRB can be removed. 5G Advanced version can allow one-to-many mapping of QoS flows to DRBs (one QoS flow is mapped to multiple DRBs).

[0078] 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 the QoS flow remapping decisions of the lower layers.

[0079] In some examples, the UE may have application information related to a real-time video application, where the video is created in real time, a video 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 battle game) are two applications with traffic patterns without QoS (e.g., over common bearers / QFI / QCI), characterized by large packet sizes and specific UL / DL packet interval distribution. MOB is particularly sensitive to delay and jitter.

[0080] In some embodiments, the application may indicate to the 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") commands specified in TS 27.007 may be used to direct the modem to take certain actions. A specific application programming interface (API) may be provided to application developers to leverage the UE capabilities to initiate dynamic remapping of QoS flows to DRBs.

[0081] Together with the enhanced QoS flow to DRB mapping methods discussed above (e.g., UE initiated remapping and / or allowing one-to-many QoS flow to DRB mapping), and given the information / commands received from the application layer, the UE can utilize foreground and background traffic and more dynamically place some background traffic on a best effort bearer (or another bearer with lower QoS). These embodiments allow for fast remapping (assignment) of QoS flows to DRBs based on application layer influence and / or changing application requirements.

[0082] In another aspect of these exemplary embodiments, the UE lower layer (e.g., SDAP, PDCP, RLC, or MAC) may detect an event that may trigger a QoS flow to DRB remapping and / or a packet shift from one DRB to another DRB. In some embodiments, an event such as a high buffer state or a high buffer residence time may be detected on the DRB / LCH, which triggers the remapping of the QoS flow to a different DRB / LCH. In other embodiments, certain packets may be shifted in a temporary or one-time manner. These embodiments may involve active queue management (AQM) technology implemented at the SDAP, PDCP, RLC, or MAC layer. As described above, SDAP maps QoS flows to DRBs. RLC maps the DRBs received from SDAP / PDCP to a logical channel (LCH) for sending to the medium access control (MAC) layer. When packets are received at (or generated by) these entities of the UE on the UL to be sent to the lower layers and / or the network, the packets enter one or more send queues or buffers. From the queue / buffer, the packets may be sequentially / gradually submitted to the lower layers for further processing and sending to the network.

[0083] 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 is close to a packet delay budget (PDB) for a given flow (e.g., based on a PDCP discard timer or according to a new parameter configured by the network, or based on an estimate internal to the UE and related to the PDB for 5QI / 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 specific logical channel (LCH) (for DRBs). The UE may receive packets from higher layers that enter LCH / DRB queues or lower layer queues according to DRBs. If the UE detects a specific event regarding received packets, such as 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 completely remapping the QoS flow. The LCH to which the packets are shifted may be associated with a lower buffer status or delay.

[0084] Various thresholds (e.g., buffer, dwell time, retransmission, and / or RTT thresholds) that may trigger feedback to 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 eligible for packet shifting, specific DRBs to which packets should be shifted, etc.

[0085] Figure 6aAn 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 is shown. Diagram 600 shows a higher layer queue 602 and a lower layer queue 603 of the UE 601. It should be noted that based on the specific implementation of the UE or gNB, the queues may be associated with one or more different layers depending on how the memory is organized. In some embodiments, the lower layer queue 603 may be associated with the PDCP layer, for example, may be a logical channel (LCH) or DRB queue associated with the RLC layer, or may be associated with the MAC layer. In some embodiments, the higher layer queue 602 may be associated with the application layer or the SDAP layer, for example. Those skilled in the art will determine that in different specific implementations, the higher layer queue 602 and the lower layer queue 603 may be connected to different actual layers (or multiple layers). In some cases, the higher layer queue may be in the PDCP performing encryption, while the lower layer queue may be the RLC or MAC, where the packets are remapped. In this case, the receiver will use the count value of the PDCP from another DRB to decrypt the packet, that is, unless the packet shift occurs before encryption. In yet another case, a specific implementation may use a common queue for both higher and lower layers.

[0086] The first higher layer queue 602a corresponds to the first DRB (DRB 1), and the second higher layer queue 602b corresponds to the second DRB (DRB 2). According to the currently configured QoS flow to DRB mapping table, the packets / PDUs on DRB 1 include QoS flow 7 (QFI7), and the packets / PDUs on DRB 2 include QoS flows 3 and 5 (QFI 3, 5). Packets for QFI7 in the first higher layer queue 602a are mapped to DRB 1 and submitted to the lower layer (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 submitted to the lower layer of the second lower layer queue 603b. From the lower layer queue 603, the packets are sent to the gNB 604, where the QoS flow is identified and sent to the UPF.

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

[0088] In this example, UE 601 determines that the QoS flow 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 a remap. UE 601 sends packets according to the UE-initiated remapping technique, which is described in more detail below. gNB 602 grants the QFI 7 packet on DRB 2 and remaps the QoS flow from DRB 1 to DRB 2.

[0089] To request remapping, the UE may include a bit (e.g., an RDI bit) in the UL SDAP header indicating a UE-initiated remapping request and send the packet through a different DRB. Alternatively, the UE may simply update the QFI in the current queue and send the packet through a different DRB. The "incorrect" QFI acts as a trigger for remapping the QFI to the DRB for transmitting the packet. Before sending the actual packet, the UE may send a PDU containing dummy data (e.g., when the network is set to discard PDUs with unexpected QFIs), or may send 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).

[0090] These implementations assume that the gNB accepts all QFIs (or the configured set of DRBs, or a specific range or subset of QFIs). A gNB supporting this functionality should not discard received PDUs (due to unexpected DRB to QoS flow mapping, if there is such a check). Local breakout refers to the case where the gNB is locally connected to a nearby Internet gateway, such as some of the cases explained in TS23.501. Local UPF refers to edge computing (where in some configurations the gNB and UPF may be collocated). The gNB may employ a validity check on the received packet. Some gNBs may discard the packet if the QFI does not match the QoS flow to DRB mapping configured for the DRB. However, this depends on the specific implementation of the gNB. In other cases, the gNB may simply route the packet to the output link based on the received QFI and not check the QoS flow to DRB mapping. Again, this check is typically associated with the gNB-CU (where PDCP and SDAP are located). The gNB-DU may also have a similar check, but this is unlikely or not necessarily the case since the SDAP header should not be checked. Assuming that the gNB-CU will not run such checks, for example when the UPF is located far away and has one (or almost no) outgoing link to the N3 interface, such checks need to be done somewhere if the gNB is combined with a local UPF or local offload. The level (which part of the checks is done where) is part of the gNB / UPF specific implementation.

[0091] Figure 6b A method 620 for UE 601 to remap packets from a first DRB to a second DRB based on a buffer status according to various exemplary embodiments is shown. Figure 6a The diagram 600 depicts Figure 6b Method 620.

[0092] In 625, a high buffer state is detected in a first lower layer queue of a first DRB carrying a first QoS flow (QFI 1), and higher layers are notified, for example, via an alarm or feedback message. In other embodiments, the feedback message may relate to different types of event detections, such as high latency (round trip time), buffer residence time, or retransmission rate of packets in the first lower layer queue. These event detection thresholds may be configurable by the network for a specific DRB / LCH or for all DRBs / LCHs.

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

[0094] In 635, 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 of the packets, 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. A UL SDAP data PDU (with data or with dummy data) or a control PDU may be used. The request is sent on DRB 2.

[0095] In 640, gNB 602 receives the packet (e.g., with the RDI bit), grants the packet based on gNB specific implementation, and remaps QFI 1 to DRB 2.

[0096] In other exemplary embodiments, the UE may shift one or more packets to different DRBs without requesting or initiating a remapping. For example, in some cases, some packets (e.g., control data) may qualify to be remapped to different DRBs. In these embodiments, the RDI bit may indicate the presence of an unmatched QFI in a one-time manner, where the rerouting of packets is considered an exception or special case.

[0097] 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, for example, 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.

[0098] The identification of critical packets may be configured by the network or defined in the specification. The network may further configure packet shifting and / or QoS flow remapping parameters for the UE, including, for example, DRBs eligible for packet shifting, specific DRBs to which packets should be shifted, etc.

[0099] Figure 6c An exemplary diagram 650 is shown for UE 601 to shift one or more packets from a first DRB to a second DRB based on a critical status of the packets according to various exemplary embodiments. Figure 6a The diagram 600 is arranged in a similar manner.

[0100] In this example, no feedback is received from the RLC / MAC regarding the lower layer queues 603 regarding buffer size or any other parameters (although the approach may be combined with feedback, where critical packets are eligible for remapping only after feedback is received as a trigger). Instead, in this example, specific packets 655 for QFI 7 in the first higher layer queue 602a (DRB 1) are identified as critical packets. Critical packets may have time-sensitive requirements and / or priorities associated with them relative to other packets with QFI 7. For example, QFI 7 may carry both Real-time Transport Protocol (RTP) and RTP Control Protocol (RTCP) packets. Some packets (e.g., control data) may be eligible to be remapped to different DRBs when certain conditions are met based on the network configuration.

[0101] When a critical packet is detected in the first queue 602a, the higher layer determines to shift packets 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 (DRB2) may be, for example, a default destination for certain types of packets.

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

[0103] In this example, UE 601 does not remap the QoS flow of QFI 7 to DRB 2, e.g., does not include the RDI bit. The gNB grants the time-critical QFI 7 packet on DRB 2.

[0104] Figure 6d A method 670 for UE 601 to shift one or more packets from a first DRB to a second DRB based on a critical status of the packets according to various exemplary embodiments is shown. Figure 6c The diagram 650 depicts Figure 6d Method 670.

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

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

[0107] In 685, UE 601 (e.g., SDAP) shifts the critical packets for QFI 1 from DRB 1 to DRB 2. In this example, UE 601 does not include an RDI bit 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 an unmatched QFI in a one-time manner. In other words, the rerouting of QFI 1 on DRB 2 is considered an exception or special case.

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

[0109] In still another aspect of these exemplary embodiments, the UE may indicate a flow end indicator to the network. The flow end indicator may include a UL SDAP header having a value of, for example, QFI=0 or QFI=0x3F(63). Figure 5e and Figure 5c As shown, the end-of-flow indicator may be included in a UL SDAP data PDU or a UL SDAP control PDU.

[0110] According to NAS specification TS24.501, the network should not set QFI 0, so QFI=0 is not assigned to the UE. In 5G NAS, QFI 0 is currently considered a "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 should set the QFI value to "unassigned QoS flow identifier" in the requested QoS flow description IE. According to RAN3 and SA2 specifications, any QFI value between 0 and 63 is considered a valid QFI. Note that SDAP carries user plane data (DRB), while NAS carries control plane traffic (SRB), which configures, for example, QoS rules for the PDU session associated with the DRB.

[0111] According to another aspect of the exemplary embodiment, a particular QFI value may be declared as a "special value" that may be used as an end-of-traffic indicator for one or more QFIs (after the QFI is assigned). In a first option, the UE sets the QFI to all 0s (or all 1s) and sets the reserved bit to 1 in the UL SDAP header (for data PDUs or control PDUs). The reserved bit is used as an (optional) additional identifier to indicate the presence of a special QFI value or the presence of an end-of-traffic indication. This indicates to the UE that there will be no new UL data in the foreseeable future and that the network may use the data to release the connection immediately. In current operations, the network typically waits for a duration of inactivity, for example, about 10 seconds.

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

[0113] The UE may use the influence of the application or higher layers to determine or declare the 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 can provide suggestions to the network.

[0114] The UL SDAP header can 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 0x3F) in any SDAP uplink packet, and then this is valid for all DRBs. In the second option, the indication is defined on a per-DRB basis. Certain DRBs may be configured to use QFI 0 or QFI=0x3F as the end of traffic indicator, which applies to DRBs configured with this feature. In the third option, the R bit may be used, for example, in combination with a special QFI value or alone.

[0115] Some thresholds on the frequency with which the flow end indicator may be transmitted may be configured on the UE side to avoid fluctuations between consecutive transmissions of the flow end indicator and scheduling requests (SRs) within a short period of time. In another option, UE assistance information may be sent via UL RRC to indicate to the network the intention to release the connection.

[0116] In other embodiments, the assistance information may be associated with a dataInactivityTimer implemented by the network. 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 the assistance information with the network to correctly set the dataInactivityTimer based on the UE's understanding of the characteristics of the data traffic. 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.

[0117] Based on the assistance information provided by the UE, the network may determine to shorten or lengthen the 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 perspective.

[0118] In these example embodiments, the UE may indicate in the RRC UE Assistance Information a recommended value or any updates to the dataInactivityTimer used by the gNB based on the UE's understanding of the traffic characteristics.

[0119] Figure 7 A method 700 of UE-initiated operations for QoS flow to DRB remapping or packet shifting is shown according to various exemplary embodiments.

[0120] 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 in QoS requirements for different traffic flows. In other embodiments, the UE (SDAP / PDCP / RLC / MAC layer) may detect events such as high buffer status or arrival of critical packets.

[0121] In 710, the UE determines that at least one packet of the QoS flow should be mapped / remapped or shifted to a new DRB based on the received / determined information. This may be in response to information from the application layer (e.g., application metrics, metadata, AT commands, etc.); packet detection (e.g., critical packets) at the application / SDAP layer; indications from the RLC layer (e.g., higher buffering for LCH, high dwell time, etc.); and / or buffer status, as described above. The UE action is 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 the QoS flow from the first DRB to the second DRB. In another example, if a high buffering state is triggered at a lower layer queue of the first DRB, the SDAP may determine to remap the QoS flow from the first DRB to the second DRB. In still 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 flow of the critical packet.

[0122] In 715, the UE sends a request or otherwise initiates a QoS flow remapping / shift for one or more packets in the QoS flow and / or for the entire QoS flow. The UE may initiate a remapping request by sending a QFI on a DRB different from the currently 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 a UL SDAP data PDU (with UL data), a UL SDAP data PDU (with dummy data), a UL SDAP control PDU, a UL RRC message, etc. In other embodiments, the UE may indicate a QoS flow remapping for a specific packet in a one-time manner (without requesting a full remapping).

[0123] The gNB may grant transmissions based on gNB specific implementation. The gNB may configure the UE for certain UE initiated QoS flow remapping / shifting operations based on UE capabilities and implement 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 a packet on a different DRB in a one-time manner and not remap the QoS flow for that packet.

[0124] In some embodiments, together with or separately from the above-described QoS remapping, the UE may share auxiliary information about current or upcoming traffic with the network. 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-traffic indicator may include, for example, an UL transmission with the QFI set to a special value (e.g., QFI=0 or QFI=0x3F(63)). Reserved bits in the UL SDAP header (e.g., RDI bits) may also be used to indicate the end of traffic (possibly in combination with a "special" QFI value if the RDI bit is used for a different purpose). Some thresholds regarding the frequency with which the end-of-traffic indicator may be transmitted may be configured on the UE side. The end-of-traffic indicator may also include a UE assistance message (e.g., UL RRC).

[0125] In other embodiments, the assistance information may be related to the dataInactivityTimer implemented by the network. The UE may share the assistance information with the network to correctly set the dataInactivityTimer based on the UE's understanding of the data traffic characteristics. The UE may indicate the recommended value or any updates to the dataInactivityTimer in the UL RRC UE assistance information. Based on the assistance information provided by the UE, the network may determine to shorten or lengthen the dataInactivityTimer.

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

[0127] Example

[0128] In a first embodiment, a method is performed by a user equipment (UE), the method comprising: establishing a protocol data unit (PDU) session, the PDU session comprising one or more quality of service (QoS) flows and multiple data radio bearers (DRBs) for communicating with a network; determining an initial mapping table for QoS flow to DRB mapping based on a network configuration of mapping parameters or receiving an initial mapping table for QoS flow to DRB mapping; receiving or determining information about current or upcoming traffic on the one or more QoS flows or one or more DRBs; determining, 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 sending one or more packets for the first QoS flow on the second DRB.

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

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

[0131] In a fourth embodiment, the method of the second embodiment, wherein the information includes an attention (AT) command, the AT command indicating a current or upcoming change in 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 shift packets for the first QoS flow from the first DRB to the second DRB.

[0132] In a fifth embodiment, the method of the second embodiment, wherein the first QoS flow includes background traffic, and the second DRB includes a DRB with a lower QoS than the first DRB.

[0133] In a sixth embodiment, the method of the first embodiment, wherein the information about current or upcoming traffic is determined at 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 or received from the layer.

[0134] In a seventh embodiment, the method of the sixth embodiment further comprises: receiving a configuration for a packet shift or QoS flow remapping feature from the network.

[0135] In an eighth embodiment, the method of the seventh embodiment, wherein the packet shift or QoS flow remapping characteristics include a buffer status threshold of at least the first DRB or a first buffer of a first lower layer associated with the first DRB, 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, a survival time event or a retransmission threshold, wherein an event is detected when one of the thresholds is exceeded.

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

[0137] 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.

[0138] 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.

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

[0140] 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 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 the special packet on the first DRB.

[0141] In a fourteenth embodiment, the method of the seventh embodiment, wherein the configuration for packet shifting or QoS flow remapping feature from the network further indicates a subset of configured DRBs that meet the conditions of the packet shifting or QoS flow remapping feature.

[0142] In a fifteenth embodiment, the method of the seventh embodiment further includes: using an uplink (UL) SDAP header indicating a reserved bit to request the network to map or remap the first QoS flow from the first DRB to the second DRB, wherein the UL SDAP header is included together with a UL SDAP data PDU, a UL SDAP data PDU including padding data, or a UL SDAP control PDU.

[0143] In a sixteenth embodiment, the method of the seventh embodiment further includes: using an uplink (UL) SDAP header indicating a first QoS flow identifier (QFI) for the first QoS flow on the second DRB to shift the packet for the first QoS flow from the first DRB to the second DRB and sending the packet, wherein the network grants the first QFI on the second DRB based on the packet shifting or QoS flow remapping characteristics.

[0144] In a seventeenth embodiment, the method of the first embodiment further comprises: determining, based on the information about the 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.

[0145] In an eighteenth embodiment, a processor is provided, wherein the processor is configured to execute any one of the methods described in accordance with the first to seventeenth embodiments.

[0146] 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 described in the first to seventeenth embodiments.

[0147] In a twentieth embodiment, a method performed by a base station, the method comprising: establishing a protocol data unit (PDU) session, the PDU session comprising one or more quality of service (QoS) flows and multiple data radio bearers (DRBs) for communicating 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 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 receiving one or more packets for the first QoS flow on the second DRB.

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

[0149] In a twenty-second embodiment, the method of the twentieth embodiment further includes: receiving 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 together with a UL SDAP data PDU, a UL SDAP data PDU including padding data, or a UL SDAP control PDU; and remapping the first QoS flow from the first DRB to the second DRB in response to the request.

[0150] In a twenty-third embodiment, the method of the twentieth embodiment further includes: receiving a packet having 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 feature.

[0151] In a twenty-fourth embodiment, a processor is provided, wherein the processor is configured to execute any of the methods according to the twentieth to twenty-third embodiments.

[0152] 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 described in the twentieth to twenty-third embodiments.

[0153] Those skilled in the art will appreciate that the exemplary embodiments described above may be implemented with 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, 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, etc., with compatible operating systems. The exemplary embodiments of the above methods may be embodied as a program comprising lines of code stored on a non-transitory computer-readable storage medium, which, when compiled, may be executed on a processor or microprocessor.

[0154] Although this application describes various embodiments, each having different features in various combinations, those skilled in the art will understand that any feature of one embodiment may be combined with features of other embodiments in any manner that is not expressly negated or that is not functionally or logically inconsistent with the operation of the device or the prescribed function of the disclosed embodiment.

[0155] It is well known that the use of personally identifiable information should be subject to privacy policies and practices that are generally recognized to meet or exceed industry or government requirements for maintaining user privacy. Specifically, personally identifiable information data should be managed and disposed of to minimize the risk of unintentional or unauthorized access or use, and the nature of the authorized use should be clearly stated to users.

[0156] It will be apparent to those skilled in the art that various modifications may be made to the present disclosure without departing from the spirit or scope of the present disclosure. Therefore, it is intended that the present disclosure covers modifications and variations of the present disclosure as long as they fall 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 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; as well as 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; as well as 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.

Images