Protocol data unit set-based quality of service handling in distributed base stations

Abstract

A centralized unit (CU) of a distributed base station, including distributed units (DUs), sends a request to the DU relating to the context of an UE communicating with the core network (CN) via the DU and CU (413), the request including a packet data unit (PDU) set quality of service (QoS) parameters for the QoS flow, the CU further receives a response to the request from the DU (414), and communicates the data packets of the QoS flow between the CN and the UE via the DU (426).

Description

Technical Field

[0001] Cross - reference to Related Applications This application claims priority to and the benefit of the filing date of Provisional U.S. Patent Application No. 63 / 497,704, filed on April 21, 2023, entitled "Enabling Protocol Data Unit Set Based Quality of Service Handling in a Distributed Base Station". The entire content of the provisional application is hereby expressly incorporated by reference herein.

[0002] This disclosure relates to wireless communication, and more particularly to enabling the setup or modification of a set of radio resources for high data rate and low latency services such as extended reality (XR) services and cloud gaming.

Background Art

[0003] This description of the background art is provided for the purpose of generally indicating the background of the present disclosure. The achievements of the inventors named herein, and aspects of this specification that may not meet the requirements of the prior art at the time of filing, are not admitted as prior art to the present disclosure, either expressly or implicitly, within the scope described in this section of the background art.

[0004] Generally speaking, base stations operating in a cellular radio access network (RAN) communicate with user equipment (UE) using a specific radio access technology (RAT) and multiple layers of a protocol stack. For example, the physical layer (PHY) of the RAT provides transport channels to the media access control (MAC) sublayer, and the MAC sublayer in turn provides logical channels to the radio link control (RLC) sublayer, and the RLC sublayer in turn provides data transfer services to the packet data convergence protocol (PDCP) sublayer.

[0005] The Packet Data Convergence Protocol (PDCP) sublayer provides services such as the transfer, encryption, and integrity protection of user plane data. For example, the PDCP layer defined for the Evolutionary Universal Terrestrial Radio Access (EUTRA) radio interface (see 3GPP® specification TS36.323) and New Radio (NR) (see 3GPP® specification TS38.323) provides the ordering of protocol data units (PDUs) in the uplink direction (from user devices, also known as user equipment (UEs), to base stations) and the downlink direction (from base stations to UEs). Furthermore, the PDCP sublayer provides signaling radio bearers (SRBs) and data radio bearers (DRBs) to the Radio Resource Control (RRC) sublayer. Generally speaking, UEs and base stations can use SRBs to exchange RRC messages and non-access layer (NAS) messages, and use DRBs to transport data on the user plane.

[0006] PDUs may, in some cases, transmit extended reality (XR) traffic, such as augmented reality (AR) traffic for overlaying virtual elements onto images of the real environment, virtual reality (VR) traffic for providing images, sounds, etc., in a fully virtual environment, and / or mixed reality (MR) traffic for environments where real and virtual elements interact in real time. Another example is that PDUs can transmit traffic for cloud gaming.

[0007] XR services and cloud gaming generally require high data rates and low latency transmissions. The Third Generation Partnership Project (3GPP®) recently defined new Quality of Service (QoS) requirements to support XR services and cloud gaming. However, it is unclear how the RAN should support the new QoS requirements for a set of protocol data units (PDUs) (which include one or more PDUs that transmit the payload of one unit of information generated at the application level) in a non-aggregated base station including centralized units (CUs) and distributed units (DUs). [Overview of the project]

[0008] Exemplary embodiments of these techniques are methods implemented in a centralized unit (CU) of a distributed base station including a distributed unit (DU). The method includes sending a request to the DU that relates to the context of a UE communicating with the core network (CN) via the DU and CU, the request including a packet data unit (PDU) set quality of service (QoS) parameters for a QoS flow, receiving a response to the request from the DU, and communicating data packets of the QoS flow between the CN and the UE via the DU.

[0009] Another exemplary embodiment of these techniques is a method implemented in distributed units (DUs) of a distributed base station including a central unit (CU). The method includes receiving a request from the CU relating to the context of a UE communicating with the core network (CN) via the DU and CU, wherein the request includes a packet data unit (PDU) set quality of service (QoS) parameters for a QoS flow; sending a response to the request from the CU; and communicating data packets of the QoS flow between the CN and the UE via the CU according to the PDU set QoS parameters.

[0010] Another exemplary embodiment of these techniques is a radio access network (RAN) node that includes processing hardware and is configured to implement one of the above methods. [Brief explanation of the drawing]

[0011] [Figure 1A] This is a block diagram of an exemplary wireless communication system in which a base station can implement the techniques of the present disclosure to support PDU set handling. [Figure 1B] This is a block diagram of an exemplary base station, including centralized units (CUs) and distributed units (DUs) that can operate in the system shown in Figure 1A. [Figure 2A] This is a block diagram of an exemplary protocol stack. The UE in Figure 1A communicates with the base station according to this protocol stack. [Figure 2B] This is a block diagram of an exemplary protocol stack. The UE in Figure 1A communicates with the CU and DU according to this protocol stack. [Figure 3] This is a message sequence diagram of an exemplary scenario in which the core network (CN) sends PDU set quality of service (QoS) parameters to the CU, and the CU then sends PDU set QoS parameters to the DU for PDU set-based QoS handling of specific traffic. [Figure 4A] This flowchart illustrates an exemplary method for configuring a DU using PDU set QoS parameters to support PDU set-based handling of traffic, which can be implemented in the CU of a distributed base station. [Figure 4B] This flowchart illustrates another exemplary method for configuring a DU using PDU set QoS parameters, based on whether the DU supports PDU set-based handling of traffic. [Figure 5A] This flowchart illustrates an exemplary method for implementing a distributed base station CU (Control Unit) and determining whether to configure the DU (Digital Unit) using PDU set QoS parameters based on the configuration provided by the CN (Control Unit). [Figure 5B] This flowchart is largely similar to the one in Figure 5A, but includes an additional decision on whether the CU and DU support PDU set-based handling of traffic, illustrating an exemplary method. [Figure 6A] This is a flowchart illustrating an exemplary method for implementing a distributed base station's DU (Digital Unit) and communicating data using PDU set information according to PDU set QoS parameters received from the CU (Control Unit). [Figure 6B] This flowchart illustrates another exemplary method for communicating data using PDU set information, based on whether the CU has provided the UE's PDU set QoS parameters to the DU. [Figure 6C] This flowchart illustrates other exemplary methods for communicating data using PDU set information, based on whether the UE supports PDU set-based handling of traffic. [Figure 7A] This is a flowchart of a method that can be implemented in the DU of a distributed base station to determine whether to enable PDU set QoS handling for UE data based on whether the CU has provided the UE's PDU set QoS parameters. [Figure 7B] This flowchart is largely similar to the one in Figure 7A, but includes an additional decision on whether the DU supports PDU set-based handling of traffic, illustrating an exemplary method. [Figure 8A] This flowchart illustrates a method that can be implemented in the DU of a distributed base station to determine whether to configure the UE using the PDU set QoS parameters, based on whether the CU has provided the UE's PDU set QoS parameters. [Figure 8B] This flowchart is largely similar to the one in Figure 8A, but includes an additional decision on whether the DU and / or UE support PDU set-based handling of traffic. [Figure 8C]It is a flowchart of another exemplary method that is generally similar to the flowchart of FIG. 8A, but the DU selects the value of the configuration parameter based on whether the CU provides the PDU set QoS parameters of the UE. [Figure 8D] It is a flowchart of another exemplary method that is generally similar to the flowchart of FIG. 8B, but the DU selects the value of the configuration parameter based on whether the CU provides the PDU set QoS parameters of the UE and whether the UE and / or the DU supports traffic PDU set-based handling. [Figure 9A] It is a flowchart of an exemplary method that can be implemented in the CU of a distributed base station to configure the DU using the parameters of the XR service. [Figure 9B] It is a flowchart of an exemplary method that can be implemented in the CU of a distributed base station to configure the DU using the parameters of the XR service based on whether the UE supports specific functions related to XR. [Figure 10A] It is a flowchart of an exemplary method that can be implemented in the DU of a distributed base station to communicate data using the configuration of XR received from the CU. [Figure 10B] It is a flowchart of another exemplary method to communicate data using the configuration of XR received from the CU, with an additional determination of whether the UE supports specific functions related to XR.

Embodiments for Carrying Out the Invention

[0012] A distributed base station may implement the techniques of this disclosure to support one or more PDU set QoS parameters for QoS flows within a PDU session and / or to support parameters for XR traffic. A PDU set includes one or more PDUs that carry a payload of one unit of information generated at the application level (e.g., a frame or video slice for an XR service). As described in more detail below, a CU receives PDU set QoS parameters from a CN and, depending on the embodiment or scenario, can configure a DU with these PDU set QoS parameters or associated PDU set QoS parameters and communicate traffic using the PDU set information that the CN may provide together with data packets. A DU receives one or more PDU set QoS parameters from a CU and can communicate traffic according to the PDU set QoS parameters.

[0013] Referring first to Figure 1A, the exemplary wireless communication system 100 can implement one or more of these techniques. The wireless communication system 100 includes a UE 102, a base station (BS) 104, a base station 106, and a core network (CN) 110. Base stations 104 and 106 operate on a radio access network (RAN) 105. The UE 102 initially connects to base station 104. In some scenarios, base station 104 can perform an SN addition and configure the UE 102 to operate in dual connection (DC) with base stations 104 and 106. Base stations 104 and 106 operate as the MN and SN of the UE 102, respectively.

[0014] In various configurations of the wireless communication system 100, the base station 104 can operate as a master eNB (MeNB) or a master gNB (MgNB), and the base station 106 can be implemented as a secondary gNB (SgNB). The UE 102 can communicate with the base station 104 and the base station 106 via the same RAT such as EUTRA or NR, or via different RATs. When the base station 104 is a MeNB and the base station 106 is an SgNB, the UE 102 can be in EUTRA-NR DC (EN-DC) with the MeNB and the SgNB.

[0015] In some cases, the MeNB or SeNB is implemented as an ng-eNB instead of an eNB. When the base station 104 is a master ng-eNB (Mng-eNB) and the base station 106 is an SgNB, the UE 102 can be in next-generation (NG) EUTRA-NR DC (NGEN-DC) with the Mng-eNB and the SgNB. When the base station 104 is a MgNB and the base station 106 is an SgNB, the UE 102 can be in NR-NR DC (NR-DC) with the MgNB and the SgNB. When the base station 104 is a MgNB and the base station 106 is a secondary ng-eNB (Sng-eNB), the UE 102 can be in NR-EUTRA DC (NE-DC) with the MgNB and the Sng-eNB.

[0016] In the scenario where the UE 102 handovers from the base station 104 to the base station 106, the base stations 104 and 106 operate as a source base station (S-BS) and a target base station (T-BS), respectively. The UE 102, for example, can operate in DC with the base station 104 and an additional base station (not shown in Figure 1A) before the handover. After completing the handover, the UE 102 can continue to operate in DC with the base station 106 and the additional base station, or can operate in a single connection (SC) with the base station 106. In this case, the base stations 104 and 106 operate as a source MN (S-MN) and a target MN (T-MN), respectively.

[0017] The core network (CN) 110 can be an evolved packet core (EPC) 111 or a fifth-generation core (5GC) 160, both shown in Figure 1A. The base station 104 can be an eNB supporting an S1 interface for communication with the EPC 111, an ng-eNB supporting an NG interface for communication with the 5GC 160, or a gNB supporting an NR radio interface and an NG interface for communication with the 5GC 160. To directly exchange messages during the scenarios described below, base stations 104 and 106 can support X2 or Xn interfaces. Among other components, the EPC 111 may include a serving gateway (SGW) 112, a mobility management entity (MME) 114, and a packet data network gateway (PGW) 116. The SGW 112 is typically configured to forward user plane packets related to voice calls, video calls, internet traffic, etc., while the MME 114 is configured to manage authentication, registration, paging, and other related functions. The PGW116 provides connectivity from the UE to one or more external packet data networks, such as the Internet network and / or an Internet Protocol (IP) Multimedia Subsystem (IMS) network. The 5GC160 includes User Plane Function (UPF)162, Access and Mobility Management (AMF)164, and / or Session Management Function (SMF)166. The UPF162 is generally configured to forward user plane packets related to voice calls, video calls, internet traffic, etc., the AMF164 is configured to manage authentication, registration, paging, and other related functions, and the SMF166 is configured to manage protocol data unit (PDU) sessions.

[0018] The SMF166 can establish a PDU session for routing traffic between the UE102 and the application server (AS) 170 operating outside the CN110. The traffic can include downlink traffic from AS170 to the UE102, uplink traffic from the UE102 to AS170, or both. In some scenarios, the traffic is typically XR traffic associated with low latency. In some scenarios, as described below, the CN110 generates PDU set information in the RAN105 to handle the PDUs as a set.

[0019] As shown in Figure 1A, base station 104 supports cell 124 and base station 106 supports cell 126. Since cells 124 and 126 can partially overlap, UE 102 can communicate with base stations 104 and 106 via DC. One of base stations 104 and 106 is MN and the other is SN. Base stations 104 and 106 can support additional cells (not shown in Figure 1A). Base station 104 can operate cell 124 and / or additional cells (multiple) via one or more transmit / receive points (TRPs).

[0020] In general, RAN105 may include any suitable number of base stations supporting NR cells and / or EUTRA cells. More specifically, EPC111 or 5GC160 may be connected to any suitable number of base stations supporting NR cells and / or EUTRA cells. In the following embodiments, specific CN types (EPC, 5GC) and RAT types (5G NR or EUTRA) are specifically referred to, but in general, the techniques of the present disclosure can also be applied to other suitable radio access and / or core network technologies such as sixth-generation (6G) radio access and / or 6G core networks or 5G NR-6G DC.

[0021] Continuing to refer to Figure 1A, the base station 104 comprises processing hardware 130, which may include one or more general-purpose processors (e.g., CPUs) and non-temporary computer-readable memory for storing instructions executed by the one or more general-purpose processors. Additionally or alternatively, the processing hardware 130 may include a special-purpose processing unit. The processing hardware 130 may include a PHY controller 132 configured to transmit data and control signals and DL reference signals on a physical downlink (DL) channel via one or more cells and / or one or more TRPs to one or more user devices (e.g., UE 102). The PHY controller 132 may also be configured to receive data and control signals and / or UL reference signals on a physical uplink (UL) channel via one or more cells and / or TRPs to one or more user devices. In an exemplary embodiment, the processing hardware 130 includes a MAC controller 134 configured to perform MAC functions on one or more user devices. The MAC function includes random access (RA) procedures for managing the UL timing advance of one or more user devices and / or communicating the UL / DL MAC PDU with one or more user devices. The processing hardware 130 may further include an RLC controller (not shown in Figure 1A) configured to perform RLC functions on one or more user devices. The processing hardware 130 may further include a PDCP controller (not shown in Figure 1A) configured to perform PDCP functions on one or more user devices. The processing hardware 130 may further include an RRC controller 136 for performing procedures and messaging in the RRC sublayer of the protocol communication stack. For example, the RRC controller 136 may be configured to support resource configuration and reconfiguration procedures, RRC messaging associated with handover procedures, and / or operations required when the base station 104 operates as an MN to an SN or as an SN to an MN.

[0022] The PDU set controller 138 manages PDU set QoS parameters, PDU set information, etc., and can support PDU set-based handling of traffic between the UE 102 and CN 110. When base station 104 is a distributed base station, the CU PDU set controller 138A can operate as a CU, and the DU PDU set controller 138B can operate as a DU (see Figure 1B). Base station 106 can include processing hardware similar to that of processing hardware 130 and can support similar functions.

[0023] UE102 comprises processing hardware 150, which may include one or more general-purpose processors such as CPUs, non-temporary computer-readable memory for storing machine-readable instructions executable by one or more general-purpose processors, and / or special-purpose processing units. PHY controller 152 is also configured to receive data and control signals on physical DL channels and / or DL ​​reference signals at base stations 104 or 106 via one or more cells and / or TRPs. PHY controller 152 is also configured to transmit data and control signals on physical UL channels and / or UL reference signals at base stations 104 or 106 via one or more cells and / or TRPs. Processing hardware 150 in an exemplary embodiment includes a MAC controller 154 configured to perform MAC functions at base stations 104 or 106. For example, MAC functions include random access procedures for managing UL timing for communication with base stations 104 or 106 and communicating UL / DL MAC PDUs with base stations 104 or 106. The processing hardware 150 may further include an RRC controller 156 to implement procedures and messaging in the RRC sublayer of the protocol communication stack. The processing hardware 130 may further include an RLC controller (not shown in Figure 1A) configured to perform RLC functions at base station 104 or 106. The processing hardware 130 may further include a PDCP controller (not shown in Figure 1A) configured to perform PDCP functions at base station 104 or 106. The PDU set controller 158 can support PDU set-based handling of traffic between UE 102 and CN 110.

[0024] During operation, UE102 in the DC may use radio bearers (e.g., DRB or SRB) that terminate at MN104 or SN106 at different times. UE102 may apply one or more security keys when communicating with the radio bearers in the uplink (UL) direction (from UE102 to the base station) and / or the downlink direction (from the base station to UE102).

[0025] Figure 1B shows one or more exemplary distributed or non-aggregated embodiments of base stations 104, 106. In these embodiments, base stations 104, 106 include a centralized unit (CU) 172 and one or more DUs 174. The CU 172 includes processing hardware such as one or more general-purpose processors (e.g., CPUs), computer-readable memory for storing machine-readable instructions executable by the general-purpose processors, and / or special-purpose processing units. For example, the CU 172 may include PDCP controllers, RRC controllers and / or RRC inactive controllers such as PDCP controllers 134, 144, RRC controllers 136, 146 and / or RRC inactive controllers 138, 148. In some embodiments, the CU 172 may include radio link control (RLC) controllers configured to manage or control one or more RLC operations or procedures. In other embodiments, the CU 172 does not include an RLC controller.

[0026] Each DU174 also includes processing hardware which may include one or more general-purpose processors (e.g., CPUs), computer-readable memory for storing machine-readable instructions executable by one or more general-purpose processors, and / or special-purpose processing units. For example, the processing hardware may include MAC controllers (e.g., MAC controllers 134, 142) configured to manage or control one or more MAC operations or procedures (e.g., random access procedures), and / or RLC controllers configured to manage or control one or more RLC operations or procedures. The process hardware may also include physical layer controllers configured to manage or control one or more physical layer operations or procedures.

[0027] In some embodiments, CU172 may include a logical node CU-CP172A that hosts the control plane portion of the CU172's PDCP protocol. CU172 may also include a logical node CU-UP172B that hosts the user plane portion of the CU172's PDCP protocol and / or Service Data Adaptive Protocol (SDAP) protocol. CU-CP172A can transmit control information (e.g., RRC messages, F1 application protocol messages), and CU-UP172B can transmit data packets (e.g., SDAP PDUs or Internet Protocol packets).

[0028] A CU-CP172A can connect to multiple CU-UP172Bs via the E1 interface. The CU-CP172A selects the appropriate CU-UP172B for the requested service of the UE102. In some embodiments, a single CU-UP172B can connect to multiple CU-CP172As via the E1 interface. A CU-CP172A can connect to one or more DU174s via the F1-C or W1-C interface. A CU-UP172B can connect to one or more DU174s via the F1-U or W1-U interface under the control of the same CU-CP172A. In some embodiments, a single DU174 can connect to multiple CU-UP172Bs under the control of the same CU-CP172A. In such embodiments, the connection between the CU-UP172B and the DU174 is established by the CU-CP172A using bearer context management functionality.

[0029] Figure 2A shows an exemplary protocol stack 200 in a simplified manner that allows UE102 to communicate with eNB / ng-eNB230 or gNB232 (e.g., one or more of base stations 104, 106).

[0030] In an exemplary stack 200, the EUTRA physical layer (PHY) 202A provides a transport channel to the EUTRA MAC sublayer 204A, which then provides a logical channel to the EUTRA RLC sublayer 206A. The EUTRA RLC sublayer 206A then provides an RLC channel to the EUTRA PDCP sublayer 208, and possibly to the NR PDCP sublayer 210. Similarly, the NR PHY 202B provides a transport channel to the NR MAC sublayer 204B, which then provides a logical channel to the NR RLC sublayer 206B. The NR RLC sublayer 206B then provides data transfer services to the NR PDCP sublayer 210. The NR PDCP sublayer 210 can then provide data transmission services to the Service Data Adaptive Protocol (SDAP) 212 or the Radio Resource Control (RRC) sublayer (not shown in Figure 2A). In some embodiments, the UE102 supports both EUTRA and NR stacks, as shown in Figure 2A, supports handover between EUTRA base stations and NR base stations, and / or supports DC via EUTRA and NR interfaces. Furthermore, as shown in Figure 2A, the UE102 can support layering of NR PDCP210 on EUTRA RLC206A and SDAP sublayer212 on NR PDCP sublayer210.

[0031] EUTRA PDCP sublayer 208 and NR PDCP sublayer 210 receive packets that may be referred to as Service Data Units (SDUs) (e.g., from the Internet Protocol (IP) layer, which is layered directly or indirectly on top of PDCP layer 208 or 210) and output packets that may be referred to as Protocol Data Units (PDUs) (e.g., to RLC layer 206A or 206B). For simplification, this disclosure refers to both SDUs and PDUs as “packets” unless the difference between SDUs and PDUs is relevant.

[0032] In the control plane, the EUTRA PDCP sublayer 208 and the NR PDCP sublayer 210 may provide, for example, a signaling radio bearer (SRB) or an RRC sublayer (not shown in Figure 2A) for exchanging RRC messages or non-access layer (NAS) messages. In the user plane, the EUTRA PDCP sublayer 208 and the NR PDCP sublayer 210 may provide a DRB to support data exchange. The data exchanged in the NR PDCP sublayer 210 may be SDAP PDUs, Internet Protocol (IP) packets, or Ethernet packets.

[0033] Figure 2B shows an exemplary protocol stack 250 in which UE102 can communicate with DU (e.g., DU174) and CU (e.g., CU172) in a simplified manner. The radio protocol stack 200 is functionally divided as shown by the radio protocol stack 250 in Figure 2B. The CU, located in either base station 104 or 106, can hold all control and higher-layer functions (e.g., RRC214, SDAP212, NR PDCP210), while lower-layer operations (e.g., NR RLC206B, NR MAC204B, and NR PHY202B) are delegated to the DU. To support connectivity to 5GC, NR PDCP210 provides an SRB to RRC214, and NR PDCP210 provides a DRB to SDAP212 and an SRB to RRC214.

[0034] First, referring to Figure 3, in Scenario 300, base station 104 includes CU172 and DU174, and UE102 first performs a PDU session establishment procedure or PDU session modification procedure at CN110 via base station 104 or base station 106 (not shown in Figure 3) (302) to establish or modify a PDU session for one or more services that require high data rate and low latency transmission. For example, the services(s) may include XR services and / or cloud gaming. During the PDU session establishment procedure, UE102 sends a PDU session establishment request message to CN110 via base station (e.g., base station 104 or 106). In response, CN110 may send a PDU session establishment acceptance message to UE102 via base station. In response to the PDU session establishment acceptance message, UE102 then sends a PDU session establishment complete message to CN110 via base station. In the PDU session change procedure, UE102 sends a PDU session change request message to CN110 via the base station. In response, CN110 can send a PDU session change command message to itself via the base station. In response to the PDU session change command message, UE102 then sends a PDU session change complete message to CN110 via the base station.

[0035] In some embodiments, UE102 may include a PDU session ID, slice information, and / or a specific data network name (DNN) that identifies the PDU session in a PDU session establishment request message or a PDU session modification request message. In some embodiments, CN110 may include a PDU session ID in a PDU session establishment acceptance message or a PDU session modification command message to indicate the successful establishment or modification of a PDU session. In some embodiments, the slice information indicates a specific slice configured for the service(s). For example, the slice information may be Single Network Slice Selection Assistance Information (S-NSSAI) and include a portion of the S-NSSAI. In other embodiments, UE102 may include UE requested quality of service (QoS) parameters required by UE102 to perform the service(s).

[0036] After performing step 302, UE102 communicates with CN110 via base station 104 (304). While communicating with UE102, CU172 may receive a CN-to-BS message from CN110 containing the UE capabilities of UE102 (306). CU172 may send a CU-to-DU message containing the UE capabilities to DU174 (not shown to avoid confusion). The CU-to-DU message may be an F1 Application Protocol (F1AP) message, a UE Context Setup Request message, or a UE Context Change Request message. Alternatively, CU172 may send a UE Capability Inquiry message to UE102 via DU174 to inquire about the UE capabilities (308). In response, UE102 sends a UE Capability Information message containing the UE capabilities to CU172 via DU174 (310).

[0037] In some embodiments, UE capabilities include instructions specifically for supporting one or more functions / features to enhance communication of data requiring high data rates and low latency, such as XR data or cloud gaming data. For example, functions / features may include multiple CG PUSCH transmission opportunities during the duration of a single configuration grant (CG) physical uplink shared channel (PUSCH) configuration, dynamic instructions by the UE for unused CG PUSCH opportunities based on UCI, Buffer Status Reporting (BSR) enhancements including at least one dedicated buffer status table, delay reporting of buffered data on the uplink, provisioning of XR traffic support information for DL ​​and UL (e.g., periodicity) and / or PDU set-based QoS handling (e.g., PDU set-based discarding behavior). A PDU set includes one or more PDUs that carry a payload of one unit of information generated at the application level (e.g., a frame or video slice for an XR service).

[0038] During or after step 302, or during step 304, CN110 sends a PDU session resource request message to CU172 to request CU172 to allocate resources for the PDU session and one or more QoS flows to UE102 (312). The QoS flows are associated with the PDU session. In some embodiments, CN110 may include a first set of PDU set QoS parameters for the PDU session or QoS flow(s) in the PDU session resource request message. In one embodiment, CN110 includes a first set of PDU set QoS parameters to request or configure PDU set-based QoS handling (e.g., for the PDU session or QoS flow(s)) for UE102. After receiving the PDU session resource request message (312) (e.g., in response to receipt), CU172 sends a UE context request message for the PDU session or QoS flow(s) to DU174 (313). In some embodiments, CU172 includes a second set of PDU set QoS parameters in the UE context request message to request or configure PDU set-based QoS handling (e.g., PDU session or QoS flow(s)) for UE102. In some embodiments, the second set of PDU set QoS parameters is the same as or identical to the first set of PDU set QoS parameters. In other embodiments, the second set of PDU set QoS parameters is different from the first set of PDU set QoS parameters. In some embodiments, CU172 determines the second set of PDU set QoS parameters based on the first set of PDU set QoS parameters. In such cases, CU172 ensures that the second set of PDU set QoS parameters satisfies the first set of PDU set QoS parameters.For example, taking into account the latency in the F1-U connection between CU172 and DU174, the data processing time on CU172, and / or the data processing time on DU174, CU172 may make the second set of PDU set QoS parameters stricter than the first set of PDU set QoS parameters.

[0039] In some embodiments, CU172 decides to include, or includes, a second set of PDU set QoS parameters in the UE context request message if CU172 and / or DU174 support PDU set-based QoS handling. If at least one of CU172 and DU174 does not support PDU set-based QoS handling, CU172 does not include the PDU set QoS parameters (e.g., a second set of PDU set QoS parameters) in the UE context request message. In other embodiments, CU172 decides to include, or includes, a second set of PDU set QoS parameters in response to receiving at least one of the capabilities specialized for high data rate and low latency. If the UE capability does not include these capabilities, CU172 may refrain from including the second set of PDU set QoS parameters in the UE context request message.

[0040] In some embodiments, CN110 may include in the PDU session resource request message a set of PDU set QoS parameters for each specified QoS flow (312). In such cases, CU172 may include each set of PDU set QoS parameters in the UE context request message (313). In some embodiments, for each of the QoS flow (or flow), the corresponding set of PDU set QoS parameters in the UE context request message is the same as, or identical to, the corresponding set of PDU set QoS parameters in the PDU session resource request message. In other embodiments, for each of the QoS flow (or flow), CU172 determines the corresponding set of PDU set QoS parameters in the UE context request message based on the corresponding set of PDU set QoS parameters in the PDU session resource request message.

[0041] In some embodiments, CN110 includes a first set of non-PDU set QoS parameters (i.e., QoS parameters(s) not associated with a PDU set) in the PDU session resource request message (312). In such cases, CU172 may include a second set of non-PDU set QoS parameters in the UE context request message (313). In some embodiments, the second set of non-PDU set QoS parameters is the same as, or identical to, the first set of non-PDU set QoS parameters. In other embodiments, CU172 determines the second set of non-PDU set QoS parameters based on the first set of non-PDU set QoS parameters. In some embodiments, CN110 may include a separate set of non-PDU set QoS parameters(s) for each QoS flow(s) in the PDU session resource request message (312). In such cases, CU172 may include a separate set of non-PDU set QoS parameters(s) for each QoS flow(s) in the UE context request message. In some embodiments, for each QoS flow(s), the corresponding set of non-PDU set QoS parameters in the UE context request message is the same as, or identical to, the corresponding set of non-PDU set QoS parameters in the PDU session resource request message. In other embodiments, for each QoS flow(s), CU172 determines the corresponding set of non-PDU set QoS parameters in the UE context request message based on the corresponding set of non-PDU set QoS parameters in the PDU session resource request message. In other embodiments, CN110 does not include non-PDU set QoS parameters for the PDU session or QoS flow(s) in the PDU session resource request message(312). In such cases, CU172 may refrain from including non-PDU set QoS parameters for the PDU session or QoS flow(s) in the UE context request message(313).

[0042] In some embodiments, a set of one or more non-PDU set QoS parameters (as described above) includes a QoS identification descriptor, the maximum flow bitrate of the DL, the maximum flow bitrate of the UL, the guaranteed flow bitrate of the DL, and / or the guaranteed flow bitrate of the UL.

[0043] In some embodiments, CN110 includes a PDU session ID that identifies the PDU session in the PDU session resource request message (312). In some embodiments, CN110 includes one or more QoS flow identifiers that identify the QoS flow(s) in the PDU session resource request message. Each QoS flow identifier(s) identifies a specific QoS flow(s) among the QoS flow(s). In some embodiments, CU172 includes the QoS flow identifier(s) in the UE context request message and associates each QoS flow identifier(s) with each set of PDU set QoS parameters and / or each non-PDU set QoS parameter.

[0044] In response to receiving a UE context request (313), DU174 sends a UE context request message to CU172 (314). In some embodiments, DU174 allocates resources to a PDU session or QoS flow(s), generates configuration parameters for communicating data associated with the PDU session or QoS flow(s), and includes the configuration parameters in the UE context response message. In some embodiments, if DU174 supports PDU set-based QoS handling or a second set of PDU set QoS parameters, DU174 includes confirmation in the UE context response message indicating that DU174 applies (e.g., does) PDU set-based QoS handling (e.g., PDU session or QoS flow(s)) based on the second set of PDU set QoS parameters. In at least some embodiments, the confirmation is explicit. In other embodiments, if DU174 does not support PDU set-based QoS handling or a second set of PDU set QoS parameters, DU174 includes unsupported information or instructions (e.g., a reason value) in the UE context response message to indicate that DU174 does not support PDU set-based QoS handling or a second set of PDU set QoS parameters. In other embodiments, DU174 implicitly indicates that DU174 supports PDU set-based QoS handling or a second set of PDU set QoS parameters by removing the unsupported information from the UE context response message.

[0045] In some embodiments, if DU174 supports a second set of PDU set QoS parameters or PDU set-based QoS handling, DU174 allocates resources to the PDU session or QoS flow(s) and / or generates some or all of the configuration parameters based on the second set of PDU set QoS parameters. In some embodiments, if DU174 supports a second set of PDU set QoS parameters or PDU set-based QoS handling, DU174 enables PDU set-based QoS handling (for example, for the PDU session or QoS flow(s)) (322). In one embodiment, DU174 enables PDU set-based QoS handling (322) after receiving (for example, in response to receiving) a second set of PDU set QoS parameters or a UE context request message (313). In other embodiments, DU174 enables PDU set-based QoS handling (for, for example, a PDU session or QoS flow) (322) regardless of, or before, receiving a second set of PDU set QoS parameters or a UE context request message (313).

[0046] In some embodiments, the configuration parameters include one or more configuration parameters for enabling PDU set-based QoS handling in UE 102, and UE 102 enables PDU set-based QoS handling in response to receiving (316) the configuration parameters (321). In some embodiments, DU 174 additionally considers a second set of non-PDU set QoS parameters when configuring the configuration parameters (or more) and / or allocating resources to UE 102. In other embodiments, DU 174 ignores the second set of non-PDU set QoS parameters. By appropriately allocating resources to UE 102 and / or configuring the configuration parameters (or more), DU 174 ensures that base station 104 communicates (326) data associated with PDU sessions or QoS flows (or more) with UE 102 according to the PDU set QoS parameters and / or non-PDU set QoS parameters.

[0047] In other embodiments, if DU174 does not support a second set of PDU set QoS parameters or PDU set-based QoS handling, DU174 allocates resources to the PDU session or QoS flow(s) and / or generates configuration parameters based on a second set of non-PDU set QoS parameters. If DU174 does not support a second set of PDU set QoS parameters or PDU set-based QoS handling, and the UE context request message does not include non-PDU set QoS parameters, DU174 allocates resources to the PDU session or QoS flow(s) and / or generates configuration parameters based on predefined non-PDU set QoS parameters or predefined rules. In such embodiments, the configuration parameters do not include configuration parameters that enable PDU set-based QoS handling in UE102. By appropriately allocating resources and / or configuring the configuration parameters(s) of UE102, DU174 ensures that base station 104 communicates data associated with the PDU session or QoS flow(s) with UE102 according to the non-PDU set QoS parameters (326).

[0048] In some embodiments, the UE context request message and UE context response message are the UE context setup request message and UE context setup response message, respectively. In other embodiments, the UE context request message and UE context response message are the UE context change request message and UE context change response message, respectively. In some other embodiments, DU174 includes the configuration parameters in the UE context change request message instead of the UE context response message and sends the UE context change request message to CU172. In this case, CU172 may send a UE context change confirmation message to DU174 in response to the UE context change request message.

[0049] In some embodiments, a first and / or second set of PDU set QoS parameters includes a PDU set delay budget (PSDB), a PDU set error rate (PSER), and / or PDU set integrated handling information (PSIHI). The PSDB can define an upper limit on the delay time that a PDU set may experience for transmission between the UE102 and the CN110 (e.g., UPF162). For DL, the delay time may be the time interval between the time the CN110 (e.g., UPF162) receives the first PDU of the DL PDU set and the time the UE successfully receives all PDUs of the DL PDU set. For UL, the delay time may be the time interval between the time the UE102 receives the first PDU of the UL PDU set (e.g., the time the protocol layer of the UE102 receives the first PDU from the application) and the time the CN110 (e.g., UPF162) successfully receives all PDUs of the UL PDU set. The protocol layer may be SDAP212, PDCP210, RLC206, or MAC204. In some embodiments, the application may be an operating system (e.g., Android, iOS, Windows, or Linux®).

[0050] In some embodiments, PSDB applies to DL PDU sets transmitted by UE102 from CN110 (e.g., UPF162) and to UL PDU sets transmitted by UE102. PSER defines an upper limit on the rate of PDU sets that have been processed by the sender (e.g., UE102, CU172, or DU174) of a link layer protocol (e.g., RLC206) but have not been successfully delivered to the higher layer of the receiver (e.g., PDCP210) by the corresponding receiver. Thus, PSER defines an upper limit on the rate of PDU set loss unrelated to congestion. The purpose of PSER is to enable appropriate link layer protocol configurations (e.g., PDCP configuration, RLC bearer configuration, MAC configuration, and / or HARQ configuration) with configuration parameters. PSIHI indicates whether all PDUs in a PDU set are required for the receiving application layer to use the PDU set.

[0051] After receiving a UE context response message or a UE context change request message (for example, in response to receipt), CU172 sends an RRC reconfiguration message containing configuration parameters to UE102 via DU174 (316). In response, UE102 sends an RRC reconfiguration complete message to CU172 via DU174 (318). In some embodiments, CU172 includes in the RRC reconfiguration message one or more DRB configurations that constitute one or more DRBs associated with a PDU session and / or QoS flow(s). Each of the DRB configuration(s) may include a PDCP configuration and / or an SDAP configuration. In some embodiments, the configuration parameters include one or more RLC bearer configurations, each constituting an RLC bearer for a particular DRB, and / or a MAC configuration. In some embodiments, CU172 configures the PDCP configuration(s) and / or SDAP configuration(s) based on PDU set QoS parameters.

[0052] Before or after receiving a UE context response message (314), or before or after receiving an RRC reconfiguration complete message, CU172 sends a PDU session resource response message to CN110 in response to receiving a PDU session resource request message (312) (320). In some embodiments, if CU172 and DU174 support PDU set-based QoS handling as described above, CU172 includes confirmation information in the PDU session resource response message indicating that base station 104 (e.g., CU172 and / or DU174) will apply (e.g., perform) PDU set-based QoS handling based on a first set of PDU set QoS parameters (320). In other embodiments, if CU172 does not support PDU set-based QoS handling (e.g., based on a first set of PDU set QoS parameters) and / or DU174 does not support PDU set-based QoS handling (e.g., based on a second set of PDU set QoS parameters), CU172 includes unsupported information (e.g., reason value) in the PDU session resource response message to indicate that base station 104 does not support PDU set-based QoS handling or the first set of PDU set QoS parameters. In some other embodiments, if CU172 and DU174 support PDU set-based QoS handling as described above, CU172 includes an implicit indication that base station 104 supports the first set of PDU set QoS parameters or PDU set-based QoS handling in the PDU session resource request message by removing unsupported information or indication from the PDU session resource response message (320).

[0053] In some embodiments, the PDU session resource request message and the PDU session resource response message are the PDU session resource setup request message and the PDU session resource setup response message, respectively. In other embodiments, the PDU session resource request message and the PDU session resource response message are the PDU session resource change request message and the PDU session resource change response message, respectively.

[0054] After receiving a PDU session resource response message, CN110 (e.g., UPF162) communicates data packets (e.g., data packets for XR or cloud gaming) with UE102 via base station 104 (326). For example, CN110 sends data packets associated with UE102's QoS flow to CU172 (326), CU172 then sends data packets to DU174 (326). DU174 sends data packets to UE102 based on configuration parameters 316 and the resources allocated to UE102 (326). After receiving an RRC reconfiguration complete message (316), UE102 sends data packets associated with QoS flow to DU174 using the configuration parameters (326). DU174 then sends data packets to CU172 (326). CU172 sends data packets to CN110 (326).

[0055] In some embodiments, CN110 transmits data packets associated with a QoS flow to CU172 using the GPRS Tunneling Protocol User Plane (GTP-U) protocol (326). In some embodiments, CN110 performs PDU set QoS handling to transmit data packets to CU172 (326) based, for example, on PDU set QoS parameters (e.g., a first set of PDU set QoS flow). To perform PDU set-based QoS handling, CN110 groups data packets to UE102 into PDU sets and determines PDU set information for each data packet in each PDU set. The PDU set information includes at least one of the following: PDU set sequence number, indication of the end PDU of the PDU set (i.e., the last data packet of the PDU set), PDU sequence number within the PDU set (i.e., the sequence number of the data packet), PDU set size in bytes, and / or PDU set importance that identifies the relative importance of the PDU set compared to other PDU sets in the QoS flow. For each (326) data packet that CN sends to UE102, CN110 generates a GTP-U packet containing the data packet and the PDU set information for the data packet.

[0056] In some embodiments, CN110 includes PDU set information in the GTP-U header of the GTP-U packet. CN110 sends the GTP-U packet to CU172 (326). Upon receiving the GTP-U packet, CU172 retrieves the data packet from the GTP-U packet. If CU172 supports PDU set-based QoS handling, CU172 performs PDU set-based QoS handling on the GTP-U data packet based on the PDU set information and PDU set QoS parameters (e.g., a first set, a second set, or a third set of PDU set QoS parameters). In some embodiments, CU172 sends the data packet to DU174 based on the GTP-U protocol (326). In some embodiments, CU172 generates a GTP-U packet containing the data packet and the PDU set information of the data packet, and sends the GTP-U packet to DU174. CU172 can include PDU set information in the GTP-U header of a GTP-U packet. In some embodiments, CU172 determines whether to include PDU set information in the GTP-U packet based on whether DU174 supports PDU set-based QoS handling. If DU174 supports PDU set-based QoS handling, CU172 includes PDU set information in the GTP-U packet. Otherwise, if DU174 does not support PDU set-based QoS handling, CU172 does not include PDU set information in the GTP-U packet.

[0057] In some embodiments, CU172 uses PDU set severity to discard PDU set level packets if congestion occurs at base station 104 (e.g., CU172 and / or DU174). In other embodiments, CU172 receives a first GTP-U packet and a second GTP-U packet from CN110, associated with the QoS flow of UE102. The first GTP-U packet includes first PDU set information and a first data packet. The first PDU set information includes a first PDU sequence number and a PDU set sequence number. CU172 also receives a second GTP-U packet associated with the QoS flow of UE102, the second GTP-U packet including second PDU set information and a second data packet. The second PDU set information includes a second PDU sequence number and a PDU set sequence number. CU172 prioritizes the transmission of the first data packet over the second data packet based on the first and second PDU sequence numbers. If the first PDU sequence number precedes the second PDU sequence number in order, CU172 sends the first data packet to DU174, and then sends the second data packet to DU174.

[0058] In some embodiments, DU174 schedules UE102 to send data packets associated with a QoS flow to DU174 (326) based on a second set of second PDU set QoS parameters and / or non-PDU set QoS parameters. DU174 ensures that data packets received from UE102 and sent to CU172 conform to the second set of PDU set QoS parameters and / or non-PDU set QoS parameters. In some embodiments, when DU174 receives data packets from UE102 (326), DU174 generates a GTP-U packet containing the data packets, but does not include PDU set information in the GTP-U packet. In one embodiment, UE102 does not send PDU set information for the data packets to DU174, so DU174 does not include PDU set information in the GTP-U packet. If UE102 sends PDU set information for the data packets to DU174, DU174 may include PDU set information in the GTP-U packet. For example, DU174 includes PDU set information in the GTP-U header of a GTP-U packet. Upon receiving a GTP-U packet, CU172 generates a GTP-U packet containing the data packet and sends the GTP-U packet to CN110. When DU174 includes PDU set information in the GTP-U packet it generates, CU172 also includes PDU set information in the GTP-U packet it generates (e.g., the GTP-U header of the GTP-U packet). In some embodiments, the PDU set information in a GTP-U packet generated by CU182 is the same as, or identical to, the PDU set information in a GTP-U packet generated by DU174. In other embodiments, the PDU set information in a GTP-U packet generated by CU172 is different from the PDU set information in a GTP-U packet generated by DU174. In some embodiments, CU172 generates PDU set information based on the PDU set information received from DU174.

[0059] In some embodiments, CN110 enables PDU set-based QoS handling for a PDU session or QoS flow (325) after receiving a PDU session resource response message (320) (for example, in response to receiving it). In other embodiments, CN110 enables PDU set-based QoS handling for a PDU session or QoS flow (325) regardless of, or before, receiving a PDU session resource response message (320). In some embodiments, CU172 enables PDU set-based QoS handling for a PDU session or QoS flow (324) in response to receiving a PDU session resource response message or a first set of PDU set QoS parameters (312). In some embodiments, if CU172 receives a PDU session resource release command message for a PDU session from CN110, CU172 disables PDU set-based QoS handling for the PDU session or QoS flow. In some embodiments, if CU172 receives a PDU session resource change request message from CN110 that releases a QoS flow, CU172 disables PDU set-based QoS handling for the QoS flow. In some embodiments, if CU172 receives a PDU session resource request message from CN110 for a PDU session or QoS flow of a UE (e.g., UE102 or another UE) that excludes PDU set QoS parameters (e.g., a PDU session resource setup request message or a PDU session resource change request message), CU172 disables or refrains from enabling PDU set-based QoS handling for the PDU session or QoS flow.

[0060] In some embodiments, if CU172 does not support PDU set-based QoS handling and receives GTP-U packets from CN110, each containing data packets and PDU set information (326), CU172 ignores the PDU set information. In some embodiments, if CN110 determines that base station 104 (e.g., CU172 and / or DU174) does not support PDU set-based QoS handling, CN110 refrains from including PDU set information in the GTP-U packets containing UE102's data packets.

[0061] Next, we will describe some exemplary ways in which DU or DU can be implemented, with reference to Figures 4A to 10B. Generally speaking, similar events in Figures 4A to 10B are labeled with similar reference numbers that share the last two digits, and the differences are described below as needed. For example, event 413 is similar to event 513, event 414 is similar to event 414, and event 426 is similar to event 526.

[0062] Figure 4A is a flowchart of exemplary method 400A for sending PDU set QoS parameters to a DU (e.g., DU174 of base station 104) for PDU set-based QoS handling, which can be implemented by a CU (e.g., CU172 of base station 104).

[0063] Method 400A begins in block 402, in which the CU initiates the (first) UE context procedure for the (first) UE (e.g., events 313, 314). In block 413, in response to the initiation, the CU sends a (first) UE context request message to the (first) DU (e.g., event 313) containing PDU set QoS parameters for the (first) UE (e.g., for the (first) PDU session or (first) QoS flow). In block 414, in response to the (first) UE context request message, the CU receives a (first) UE context response message from the (first) DU (e.g., event 314). In block 426, the CU communicates with the (first) DU (e.g., event 326) using the PDU set information to communicate data for the (first) UE (e.g., associated with the (first) PDU session or (first) QoS flow).

[0064] In some embodiments, the CU initiates the second UE context procedure of the second UE (e.g., events 313, 314). In response to the initiation, the CU sends a second UE context request message to the second DU for the second UE (e.g., event 313), excluding the PDU set QoS parameters for the second UE (e.g., for the second PDU session or second QoS flow). In response to the second UE context request message, the CU receives a second UE context response message from the second DU (e.g., event 314). The CU communicates with the second DU for data of the second UE (e.g., associated with the second PDU session or second QoS flow) without using the PDU set information (e.g., event 326).

[0065] In some embodiments, the first UE and the second UE are the same UE. In other embodiments, the first UE and the second UE are different UEs. In some embodiments, the first DU and the second DU are the same DU. In other embodiments, the first DU and the second DU are different DUs. In some embodiments, the first UE and the second UE are the same UE. In other embodiments, the first UE and the second UE are different UEs. In some embodiments, the first UE context request message and the second UE context request message are the same UE context request message, and the first UE context response message and the second UE context response message are the same UE context response message. In other embodiments, the first UE context request message and the second UE context request message are different UE context request messages, and the first UE context response message and the second UE context response message are different UE context response messages.

[0066] Figure 4B is an exemplary flowchart of Method 400B, similar to Method 400A except that Method 400B includes blocks 407 and 427. In block 407, the CU determines whether the DU applies the PDU set QoS parameters. If the CU determines in block 407 that the DU applies or supports the PDU set QoS parameters, the flow proceeds to block 426. Otherwise, if the CU determines in block 407 that the DU does not apply or support the PDU set QoS parameters, the flow proceeds to block 427. In block 427, the CU communicates the UE's data (e.g., associated with a PDU session or QoS flow) with the first DU without using the PDU set information (e.g., event 326).

[0067] In some embodiments, the UE context response message indicates whether the DU applies or supports the PDU set QoS parameters. If the CU determines from the UE context response message that the DU applies or supports the PDU set QoS parameters, the CU communicates the UE's data (e.g., associated with a PDU session or QoS flow) to the DU using the PDU set information (e.g., event 326). Otherwise, if the CU determines from the UE context response message that the DU does not apply or support the PDU set QoS parameters, the CU communicates the UE's data (e.g., associated with a PDU session or QoS flow) to the DU without using the PDU set information (e.g., event 326). In some embodiments, the UE context response message includes the reason why the DU does not apply or support the PDU set QoS parameters, but excludes the reason why the DU applies or supports the PDU set QoS parameters.

[0068] Figure 5A is a flowchart of an exemplary method 500A for sending PDU set QoS parameters to a DU (e.g., DU172 of base station 104) for PDU set-based QoS handling, which can be implemented by a CU (e.g., CU172 of base station 104).

[0069] Method 500A begins in block 502, where the CU initiates the UE context procedure for the UE (e.g., events 313, 314). In block 504A, the CU determines whether it has received PDU set QoS parameters for the UE (e.g., for a PDU session or QoS flow). If the CU determines in block 504A that it has received PDU set QoS parameters for the UE (e.g., for a PDU session or QoS flow), the flow proceeds to block 513. In block 513, the CU sends a UE context request message containing the PDU set QoS parameters to the DU (e.g., event 313). In block 514, the CU receives a UE context response message from the DU (e.g., event 314). In block 526, the CU uses the PDU set information to communicate data for the UE (e.g., associated with a PDU session or QoS flow) with the DU (e.g., event 326).

[0070] Otherwise, if the CU decides in block 504A that it will not receive PDU set QoS parameters for the UE (e.g., for a PDU session or QoS flow), the flow proceeds to block 515. In block 515, the CU sends a UE context request message to the DU, excluding the PDU set QoS parameters. In block 516, the CU receives a UE context response message from the DU. In block 527, the CU communicates with the DU data (e.g., associated with a PDU session or QoS flow) of the UE without using the PDU set information.

[0071] Figure 5B is an exemplary flow diagram of Method 500B, similar to Method 500A except that Method 500B includes block 504B instead of block 504A. In block 504B, the CU determines whether the CU receives PDU set QoS parameters for the UE (e.g., for a PDU session or QoS flow) and whether the UE and / or DU support PDU set handling. If the CU receives PDU set QoS parameters for the UE (e.g., for a PDU session or QoS flow) in block 504B and the CU determines that the UE, DU and / or CU support PDU set handling, the flow proceeds to blocks 513, 514, and 526. Otherwise, if the CU does not receive PDU set QoS parameters for the UE (e.g., for a PDU session or QoS flow) in block 504B and the CU determines that the UE, DU and / or CU do not support PDU set-based QoS handling, the flow proceeds to blocks 515, 516, and 527.

[0072] Figure 6A is a flowchart of an exemplary method 600A for performing PDU set-based QoS handling with data received from a CU (e.g., CU172 of base station 104), which can be implemented by a DU (e.g., DU174 of base station 104).

[0073] Method 600A begins in block 613, where the DU receives a (first) UE context request message from the CU (e.g., event 313) containing PDU set QoS parameters for the (first) UE (e.g., for the (first) PDU session or (first) QoS flow). In block 614, the DU sends a (first) UE context response message to the CU in response to the (first) UE context response message (e.g., event 314). In block 626, the DU communicates data for the (first) UE (e.g., associated with the (first) UE session or (first) QoS flow) with the CU using the PDU set information (e.g., event 326).

[0074] In some embodiments, the DU receives a second UE context request message from the CU for the second UE (e.g., for a second PDU session or a second QoS flow), excluding the PDU set QoS parameters. In response to the second UE context request message, the DU sends a second UE context response message to the CU. The DU communicates with the CU the data for the second UE (e.g., associated with a second PDU session or a second QoS flow) without using the PDU set information.

[0075] In some embodiments, the first UE and the second UE are the same UE. In other embodiments, the first UE and the second UE are different UEs. In some embodiments, the first UE and the second UE are the same UE. In other embodiments, the first UE and the second UE are different UEs. In some embodiments, the first UE context request message and the second UE context request message are the same UE context request message, and the first UE context response message and the second UE context response message are the same UE context response message. In other embodiments, the first UE context request message and the second UE context request message are different UE context request messages, and the first UE context response message and the second UE context response message are different UE context response messages.

[0076] Figure 6B is an exemplary flow diagram of Method 600B, which is largely similar to Method 600A. However, in block 613B, the DU receives a UE context request message for the UE (e.g., for a PDU session or QoS flow). In block 605B, the DU determines whether the UE context request message contains PDU set QoS parameters for the UE (e.g., for a PDU session or QoS flow). If the DU determines in block 605B that the UE context request message contains PDU set QoS parameters for the UE (e.g., for a PDU session or QoS flow), the flow proceeds to block 626. Otherwise, if the DU determines in block 605B that the UE context request message does not contain PDU set QoS parameters for the UE (e.g., for a PDU session or QoS flow), the flow proceeds to block 627. In block 627, the DU communicates the data of the UE (e.g., associated with a PDU session or QoS flow) with the CU without using the PDU set information.

[0077] Figure 6C is an exemplary flow diagram of Method 600C, similar to Method 600B, except that Method 600C includes block 605C instead of block 605B. In block 605C, the DU determines whether the UE context request message includes PDU set QoS parameters (e.g., for a PDU session or QoS flow) and whether the UE supports PDU set handling. If the DU determines in block 605C that the UE context request message includes PDU set QoS parameters (e.g., for a PDU session or QoS flow) and the UE supports PDU set-based QoS handling, the flow proceeds to block 626. Otherwise, if the DU determines in block 627 that the UE context request message does not include PDU set QoS parameters and / or the UE does not support PDU set-based QoS handling, the flow proceeds to block 627.

[0078] Figure 7A is a flowchart of an exemplary method 700A for determining whether to enable PDU set-based QoS handling for data from a DU (e.g., DU174 of base station 104) and which can be implemented by a DU (e.g., DU174 of base station 104).

[0079] Method 700A begins in block 713, where the DU receives a (first) UE context request message from the CU for the (first) UE (e.g., for the (first) PDU session or (first) QoS flow) (e.g., event 313). In some embodiments, the DU sends a (first) UE context response message to the CU in response to the (first) UE context request message (e.g., event 314). In block 704, the DU determines whether the (first) UE context request message contains PDU set QoS parameters for the (first) UE (e.g., for the (first) PDU session or (first) QoS flow). If the DU determines in block 704 that the (first) UE context request message contains PDU set QoS parameters for the (first) UE (e.g., for the PDU session or QoS flow), the flow proceeds to block 722. In block 722, the DU enables PDU set-based QoS handling for the data of the (first) UE (e.g., associated with the (first) PDU session or (first) QoS flow) (e.g., event 322). Otherwise, if the DU determines in block 704 that the (first) UE context request message does not contain PDU set QoS parameters for the (first) UE (e.g., for the PDU session or QoS flow), the flow proceeds to block 732. In block 732, the DU refrains from or disables PDU set-based QoS handling for the data of the (first) UE (e.g., associated with the (first) PDU session or (first) QoS flow).

[0080] In some embodiments, the DU receives a second UE context request message from the CU for a second UE (e.g., a second PDU session or a second QoS flow) (e.g., event 313). The DU sends a second UE context response message to the CU in response to the second UE context request message (e.g., event 314). The DU determines whether the second UE context request message contains PDU set QoS parameters for the second UE (e.g., a second PDU session or a second QoS flow). If the DU determines that the second UE context request message contains PDU set QoS parameters for the second UE (e.g., a second PDU session or a second QoS flow), the DU enables PDU set-based QoS handling for the data of the second UE (e.g., associated with the second PDU session or a second QoS flow) (e.g., event 322). Otherwise, if the DU determines that the second UE context request message does not include PDU set QoS parameters for the second UE (e.g., for the second PDU session or second QoS flow), the DU refrains from or disables PDU set-based QoS handling for the data of the second UE (e.g., associated with the second PDU session or second QoS flow).

[0081] Figure 7B is an exemplary flowchart of Method 700B, similar to Method 700A, except that Method 700B includes Block 705 instead of Block 704. In Block 705, the DU determines whether the UE context request message includes PDU set QoS parameters (e.g., for a (first) PDU session or (first) QoS flow) and whether the UE and / or DU support PDU set handling. If the DU determines in Block 705 that the UE context request message includes PDU set QoS parameters (e.g., for a PDU session or QoS flow) and that the UE and / or DU support PDU set-based handling, the flow proceeds to Block 722. Otherwise, if the DU determines in Block 705 that the UE context request message does not include PDU set QoS parameters and / or that the UE and / or DU do not support PDU set-based QoS handling, the flow proceeds to Block 732.

[0082] In some embodiments, the DU receives a second UE context request message from the CU for a second UE (e.g., for a second PDU session or a second QoS flow) (e.g., event 313). The DU sends a second UE context response message to the CU in response to the second UE context request message (e.g., event 314). The DU determines whether the second UE context request message contains PDU set QoS parameters for the second UE (e.g., for a second PDU session or a second QoS flow), and whether the second UE and / or the DU support PDU set-based QoS handling. If the second UE context request message includes PDU set QoS parameters for the second UE (e.g., for the second PDU session or second QoS flow), and the DU determines that the second UE and / or DU support PDU set-based QoS handling, the DU enables PDU set-based QoS handling for the data of the second UE (e.g., associated with the second PDU session or second QoS flow) (e.g., event 322). Otherwise, if the second UE context request message does not include PDU set QoS parameters for the second UE (e.g., for the second PDU session or second QoS flow), and the DU determines that the second UE and / or DU do not support PDU set-based QoS handling, the DU refrains from or disables PDU set-based QoS handling for the data of the second UE (e.g., associated with the second PDU session or second QoS flow).

[0083] Figure 8A is a flowchart of an exemplary method 800A for determining whether to configure one or more configuration parameters for PDU set-based QoS handling for a UE (e.g., UE102) which can be implemented by a DU (e.g., DU174 of base station 104).

[0084] Method 800A begins in block 813, where the DU receives a UE context request message for the UE (e.g., for a PDU session or QoS flow) from the CU (e.g., event 313). In block 817, the DU includes several configuration parameters for the UE in the UE context response message. In block 805A, the DU determines whether the UE context request message includes PDU set QoS parameters for the UE (e.g., for a PDU session or QoS flow). If the DU determines in block 805A that the UE context request message includes PDU set QoS parameters for the UE (e.g., for a PDU session or QoS flow), the flow proceeds to block 840. In block 840, the DU includes at least one configuration parameter for the UE in the UE context response message. Otherwise, if the DU determines in block 805A that the UE context request message does not include PDU set QoS parameters for the UE (e.g., for a PDU session or QoS flow), the flow proceeds to block 841. In block 841, the DU refrains from including at least one configuration parameter in the UE context response message. The flow proceeds from block 840 to block 814. In block 814, the DU sends a UE context response message to the CU in response to the UE context request message (e.g., event 314).

[0085] In some embodiments, after receiving multiple configuration parameters and / or at least one configuration parameter from the DU, the CU sends an RRC message containing the multiple configuration parameters and / or at least one configuration parameter to the UE via the DU (e.g., event 316).

[0086] Figure 8B is an exemplary flow diagram of Method 800B, similar to Method 800A except that Method 800B includes block 805B instead of block 805A. In block 805B, the DU determines whether the UE context request message includes PDU set QoS parameters for the UE (e.g., for a PDU session or QoS flow) and / or whether the UE and / or DU support PDU set-based QoS handling. If the DU determines in block 805B that the UE context request message includes PDU set QoS parameters for the UE (e.g., for a PDU session or QoS flow) and that the UE and / or DU support PDU set-based QoS handling, the flow proceeds to block 840. Otherwise, if the DU determines in block 805B that the UE context request message does not include PDU set QoS parameters for the UE (e.g., for a PDU session or QoS flow) and / or that the UE and / or DU do not support PDU set-based QoS handling, the flow proceeds to block 841.

[0087] Figure 8C is an exemplary flowchart of Method 800C, similar to Method 800A, except that Method 800C includes blocks 845 and 846 instead of blocks 808 and 810. If in block 805A the DU determines that the UE context request message includes a PDU set QoS parameter for the UE (e.g., for a PDU session or QoS flow), the flow proceeds to block 845. In block 845, the DU sets at least one configuration parameter of the UE to at least one first value. Otherwise, if in block 805A the DU determines that the UE context request message does not include a PDU set QoS parameter for the UE (e.g., for a PDU session or QoS flow), the flow proceeds to block 846. In block 846, the DU sets at least one configuration parameter of the UE to at least one second value. The flow proceeds from block 807 to block 847, where the DU includes at least one configuration parameter in the UE context response message.

[0088] Figure 8D is a flowchart of an exemplary method 800D, including specific steps of methods 800A to 800C.

[0089] Figure 9A is a flowchart of an exemplary method 900A for which a CU (e.g., CU172 of base station 104) can be implemented to generate configuration parameters for an XR service and send those configuration parameters to a UE (e.g., UE102) that performs the XR service.

[0090] Method 900A begins in block 902, in which the CU initiates the (first) UE context procedure for the (first) UE (e.g., events 313, 314). In block 913, the CU sends the (first) UE context request message to the (first) DU (e.g., event 313) containing one or more parameters for one or more XR services for the (first) UE. In block 914, the CU receives the (first) UE context response message from the (first) DU in response to the (first) UE context request message (e.g., event 314) containing at least one (first) configuration for the XR service(s). In block 916, the CU sends at least one (first) configuration to the (first) UE via the (first) DU (e.g., event 316).

[0091] In some embodiments, the CU initiates a second UE context procedure for the second UE (e.g., events 313, 314). In response to the initiation, the CU sends a second UE context request message to the second DU containing one or more parameters for a non-XR service for the second UE (e.g., event 313). In response to the second UE context request message, the CU receives a second UE context response message from the second DU containing at least one second configuration for an XR service (e.g., event 314). The CU sends at least one second configuration to the second UE via the second DU (e.g., event 316).

[0092] In some embodiments, the first UE and the second UE are the same UE. In other embodiments, the first UE and the second UE are different UEs. In some embodiments, the first DU and the second DU are the same DU. In other embodiments, the first DU and the second DU are different DUs. In some embodiments, the first UE and the second UE are the same UE. In other embodiments, the first UE and the second UE are different UEs. In some embodiments, the first UE context request message and the second UE context request message are the same UE context request message, and the first UE context response message and the second UE context response message are the same UE context response message. In other embodiments, the first UE context request message and the second UE context request message are different UE context request messages, and the first UE context response message and the second UE context response message are different UE context response messages.

[0093] Figure 9B is an exemplary flowchart of Method 900B, similar to Method 900A, except that Method 900B includes blocks 903, 905, 907, and 909. In block 903, the CU determines whether the UE supports one or more XR features / functions. If the CU determines in block 903 that the UE supports one or more XR features / functions, the flow proceeds to blocks 913, 914, and 916. Otherwise, if the CU determines in block 903 that the UE does not support one or more XR features / functions, the flow proceeds to block 970. In block 970, the CU sends a UE context request message to the DU, excluding one or more parameters for an XR service(s) for the UE. In block 972, the CU receives a UE context response message from the DU in response to the UE context request message, containing at least one configuration for a non-XR service. In block 916, the CU sends at least one configuration to the UE.

[0094] In some embodiments, one or more functions / features include provisioning for multiple CG PUSCH transmission opportunities during the duration of a single CG PUSCH configuration, dynamic indication of unused CG PUSCH opportunities(s) based on UCI by the UE, BSR enhancement including at least a new buffer status table(s), delay reporting of buffered data on the uplink, XR traffic assistance information for DL ​​and UL (e.g., periodicity), and / or PDU set-based QoS handling (e.g., discarding PDU set(s)).

[0095] Figure 10A is a flowchart of an exemplary method 1000A of one or more configuration parameters for an XR service for a UE (e.g., UE102) that can be implemented by a DU (e.g., DU174 of base station 104).

[0096] Method 1000A begins in block 1013, where the DU receives a (first) UE context request message from the CU containing XR parameters for the (first) UE (e.g., event 313). In block 1014, the DU sends at least one (first) configuration of one or more XR services to the (first) UE via the CU (e.g., events 314, 316). In block 1026, the DU communicates data with the (first) UE using at least one (first) configuration (e.g., event 326).

[0097] In some embodiments, the DU receives a second UE context request message from the CU containing parameters for a non-XR service for the second UE (e.g., event 313). The DU sends at least one second configuration of the non-XR service(s) to the second UE via the CU (e.g., events 314, 316). The DU communicates data with the second UE using at least one second configuration (e.g., event 326). In some embodiments, the first UE and the second UE are the same UE. In other embodiments, the first UE and the second UE are different UEs. In some embodiments, the first UE and the second UE are the same UE. In other embodiments, the first UE and the second UE are different UEs. In some embodiments, the first UE context request message and the second UE context request message are the same UE context request message, and the first UE context response message and the second UE context response message are the same UE context response message. In other embodiments, the first UE context request message and the second UE context request message are different UE context request messages, and the first UE context response message and the second UE context response message are different UE context response messages.

[0098] Figure 10B is a flowchart of an exemplary method 1000B, similar to method 1000A, except that method 1000B includes blocks 1008, 1080, 1081, and 1082. In block 1008, the DU determines whether the UE supports one or more functions / features of one or more XR services. If the DU determines that the UE supports one or more functions / features of one or more XR services, the flow proceeds to blocks 1013, 1014, and 1026. Otherwise, if the DU determines that the UE does not support one or more functions / features of one or more XR services, the flow proceeds to block 1080. In block 1080, the DU sends at least one configuration of a non-XR service to the UE via the CU. In block 1081, the DU sends at least one configuration to the UE. In block 1082, the DU communicates data with the UE using at least one configuration.

[0099] The following additional considerations apply to the above description.

[0100] Generally speaking, the explanation for one of the above figures can be applied to the other figures above. The above examples, embodiments, and methods can be combined, provided they do not conflict. The above events or blocks may be optional or omitted. For example, events or blocks with dashed lines in the figures may be optional. In some embodiments, “message” is used and can be replaced with “information element (IE)” and vice versa. In some embodiments, “IE” is used and can be replaced with “field” and vice versa. In some embodiments, “configuration (singular)” can be replaced with “configuration (plural)” or “configuration parameter” and vice versa. In some embodiments, “at least one” means “one or more”.

[0101] A user device (e.g., UE102) that can implement the technology of this disclosure may be any suitable wireless communication device, such as a smartphone, tablet computer, laptop computer, mobile game console, point-of-sale (POS) terminal, health management device, drone, camera, media streaming dongle or other personal media device, wearable device such as a smartwatch, wireless hotspot, femtocell, or broadband router. Furthermore, the user device may optionally be embedded in an electronic system such as a vehicle head unit or advanced driver-assistance system (ADAS). In addition, the user device may operate as an Internet of Things (IoT) device or a mobile internet device (MID). Depending on the type, the user device may include one or more general-purpose processors, computer-readable memory, a user interface, one or more network interfaces, one or more sensors, etc.

[0102] Certain embodiments described in this disclosure include logic, or several components or modules. A module may be a software module (e.g., code stored in a non-temporary machine-readable medium) or a hardware module. A hardware module is a tangible unit capable of performing a particular operation and may be configured or arranged in a particular manner. A hardware module may include dedicated circuitry or logic that is permanently configured to perform a particular operation (e.g., as a special-purpose processor such as a field-programmable gate array (FPGA) or application-specific integrated circuit (ASIC)). A hardware module may also include programmable logic or circuitry that is temporarily configured by software (e.g., contained within a general-purpose processor or other programmable processor) to perform a particular operation. The decision to implement a hardware module with dedicated, permanently configured circuitry or with temporarily configured circuitry (e.g., configured by software) may be made considering cost and time.

[0103] As used herein, “comprises,” “comprising,” “includes,” “including,” “has,” “having,” or any other variation thereof are intended to encompass non-exclusive inclusion. For example, a process, method, item, or apparatus that includes a list of elements is not necessarily limited to these elements alone, and may include other elements not expressly enumerated or inherent in such process, method, item, or apparatus. Furthermore, unless expressly stated otherwise, “or” refers to an inclusive or not an exclusive or. For example, condition A or B is satisfied by any one of the following: A is true (or exists) and B is false (or does not exist); A is false (does not exist) and B is true (or exists); and both A and B are true (or exist).

[0104] When implemented in software, techniques may be provided as part of an operating system, a library used by multiple applications, or a specific software application. The software can run on one or more general-purpose processors or one or more special-purpose processors.

Claims

1. A method implemented in a centralized unit (CU) of a distributed base station including a distributed unit (DU), wherein the method is Sending a request to the DU relating to the context of a UE communicating with the core network (CN) via the DU and CU, wherein the request includes Packet Data Unit (PDU) set Quality of Service (QoS) parameters for QoS flow, Receiving a response to the request from the DU, A method comprising communicating the QoS flow data packets between the CN and the UE via the DU.

2. The PDU set QoS parameters are: (i) PDU set delay budget (PSDB), (ii) PDU Set Error Rate (PSER), (iii) PDU Set Integrated Handling Information (PSIHI), The method according to claim 1, comprising at least one of the following.

3. The method according to claim 1 or 2, wherein the PDU set QoS parameters are uplink (UL) PDU set QoS parameters.

4. The method according to claim 1 or 2, wherein the PDU set QoS parameters are downlink (DL) PDU set QoS parameters.

5. The method according to any one of claims 1 to 4, wherein the request includes a UE context setup request message.

6. The method according to any one of claims 1 to 4, wherein the request includes a UE context change request message.

7. The method according to any one of claims 1 to 6, further comprising configuring the UE with a data radio bearer (DRB) associated with the QoS flow.

8. The method according to any one of claims 1 to 7, wherein the response to the request includes confirmation that the DU supports PDU set-based QoS handling.

9. The method according to any one of claims 1 to 8, wherein the transmission of the request including the PDU set QoS parameters is performed in response to the UE receiving an instruction that it supports PDU set-based QoS handling.

10. The method according to any one of claims 1 to 9, wherein the PDU set QoS parameters relate to a PDU set comprising a plurality of PDUs that transmit payloads of units of information generated at the application level.

11. The method according to any one of claims 1 to 10, further comprising receiving a request from the CN to allocate resources to a PDU session including the QoS flow, wherein the request includes the PDU set QoS parameters.

12. A method implemented in a distributed unit (DU) of a distributed base station including a central unit (CU), wherein the method is Receiving from the CU a request relating to the context of a UE communicating with the core network (CN) via the DU and the CU, wherein the request includes Packet Data Unit (PDU) set Quality of Service (QoS) parameters for QoS flow, Receiving a response to the request from the CU, A method comprising communicating data packets of the QoS flow between the CN and the UE via the CU according to the PDU set QoS parameters.

13. The method according to claim 12, further comprising determining that the DU supports PDU set-based QoS handling.

14. The method according to claim 12 or 13, wherein the request includes one of a UE context setup request message or a UE context change request message.

15. A wireless access network (RAN) comprising processing hardware and configured to implement the method according to any one of claims 1 to 14.

Images