Reducing data communication overhead with uplink data traffic assistance information

Abstract

A distributed unit (DU) of a distributed base station that also includes a central unit (CU) obtains (1226) an uplink (UL) data traffic assistance information for a UE; generates (1228) a configuration based on the UL data traffic assistance information; and transmits (1230) the configuration to the UE, via the CU.

Description

REDUCING DATA COMMUNICATION OVERHEAD WITH UPLINK DATA TRAFFIC ASSISTANCE INFORMATIONCROSS-REFERENCE TO RELATED APPLICATION

[0001] This application claims priority to and the benefit of the filing date of provisional U.S. Patent Application No. 63 / 502,067 entitled “Reducing Data Communication Overhead with Uplink Data Traffic Assistance Information,” filed on May 12, 2023. The entire content of the provisional application is hereby expressly incorporated herein by referenceFIELD OF THE DISCLOSURE

[0002] This disclosure relates to wireless communications and, more particularly, to improving efficiency of data communication with uplink data traffic assistance information.BACKGROUND

[0003] This background description is provided for the purpose of generally presenting the context of the disclosure. Work of the presently named inventors, to the extent it is described in this background section, as well as aspects of the description that may not otherwise qualify as prior art at the time of filing, are neither expressly nor impliedly admitted as prior art against the present disclosure.

[0004] Generally speaking, a base station operating a cellular radio access network (RAN) communicates with a user equipment (UE) using a certain radio access technology (RAT) and multiple layers of a protocol stack. For example, the physical layer (PHY) of a RAT provides transport channels to the Medium Access Control (MAC) sublayer, which 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. The Radio Resource Control (RRC) sublayer is disposed above the PDCP sublayer. A core network communicates data with the UE via the RAN using multiple layers of a protocol stack.

[0005] Some of the services fifth-generation systems (5GS) require a high data rate and low- latency transmissions. One example of such services is extended Reality (XR), which includes Augmented Reality (AR), Virtual Reality (VR), and Mixed Reality (MR). In virtual reality applications, the user is fully immersed in a virtual environment that fully replaces the real, physical environment, typically by wearing a head-mounted device. In augmented reality, anapplication augments the perception of the real environment by overlaying virtual elements on the perception of the real environment. Augmented reality recently became the foundation of a widely popular game in which players seek out and interact with virtual creatures superimposed onto a real-time video stream of the real world. Finally, mixed reality is an extension of AR, where real and virtual elements can interact in real time.

[0006] In some situations, an application generates data traffic that fluctuates relative to a perfectly periodic pulse train. This fluctuation or "timing jitter" can be due to a non-ideal clock signal, phase noise, or oscillator deviations. For example, XR applications generate uplink (UL) data with timing jitter, which causes inefficiencies in UL scheduling (e.g., configured grant scheduling). Additionally, some applications (e.g., UL video streaming, XR applications, or cloud gaming) have relatively large UL packet sizes, while other applications (e.g., voice service, messaging, web browsing, and downlink-centric applications) have relatively small UL packet sizes. This can lead to quantization errors in buffer status reporting, which are more pronounced for large buffer sizes than for small buffer sizes.

[0007] For example, a certain UE has 123,456 bytes available for transmission in its buffer. Based on a buffer size level Table 6.1.3.1-1 in 3GPP specification 38.321, the UE transmits a buffer status report including index 30, corresponding to BS value (corresponding to the size <= 150,000) to a base station. Index 29 corresponds to the size <= 107,669. Thus, the base station can determine that the UE has between 107,669 and 150,000 bytes for transmission in its buffer. The base station prepares radio resources for the UE to transmit 150,000 bytes because the base station is configured to consider the maximum volume. This causes a waste of resources because the UE only has 123,456 bytes to transmit.BRIEF DESCRIPTION OF THE DRAWINGS

[0008] Fig. 1 A is a block diagram of an example system in which one or more base stations and / or a user equipment (UE) can implement the techniques of this disclosure for managing data communication for power saving between the UE and a radio access network (RAN);

[0009] Fig. IB is a block diagram of an example base station including a central unit (CU) and a distributed unit (DU) that can operate in the system of Fig. 1A;

[0010] Fig. 2A is a block diagram of an example protocol stack according to which the UE of Fig. 1A communicates with base stations;

[0011] Fig. 2B is a block diagram of an example protocol stack according to which the UE of Fig. 1 A communicates with a CU and a DU;

[0012] Fig. 3A is a messaging diagram of an example scenario in which a DU of a distributed base station receives buffer status reports and data traffic assistance information to reduce timing jiter;

[0013] Fig. 3B is a messaging diagram of an example scenario similar to Fig. 3A, but in which the UE transmits the data traffic assistance information to the CU rather than the DU;

[0014] Fig. 3C is a messaging diagram of an example scenario similar to Fig. 3 A, but in which the CU transmits data traffic assistance information to the DU;

[0015] Fig. 4 is a flow diagram of an example method implemented in a DU for obtaining UL data traffic assistance information and generating a configuration for a UE based on the UL data traffic assistance information;

[0016] Fig. 5 is a flow diagram of an example method implemented in a CU for transmitting data traffic assistance information to a DU and receiving a configuration based on the information for a UE from the DU;

[0017] Fig. 6 is a flow diagram of an example method implemented in a DU for generating a configuration for communicating with a UE based on received UL data traffic information and transmitting the configuration to a CU and the UE;

[0018] Fig. 7 is a flow diagram of an example method implemented in a UE for receiving a configuration enabling the UE to transmit UL data traffic assistance information to a RAN;

[0019] Fig. 8A is a flow diagram of an example method implemented in a base station for determining whether to transmit a configuration to enable a UE transmit UL data traffic assistance information based on whether the UE is capable of reporting the UL data traffic assistance information;

[0020] Fig. 8B is a flow diagram of a method similar to Fig. 8A, but in which the determination is further based on whether the base station receives PDU Set-related information for the UE;

[0021] Fig. 9 is a flow diagram of an example method implemented in a base station for determining whether to transmit a configuration to configure a UE perform buffer status reporting based on whether the base station receives PDU Set-related information for the UE;

[0022] Fig. 10A is a flow diagram of an example method implemented in a base station for transmitting a configuration to a UE to configure and activate a buffer size table and deriving a buffer size value from a received index value;

[0023] Fig. 10B is a flow diagram of an example method similar to Fig. 10 A, but in which the base station receives an ID along with the index value from the UE and identifies the buffer size table based on a received ID

[0024] Fig. 10C is a flow diagram of an example method similar to Fig. 10A, but in which the base station configures the buffer size table and receives a logical channel ID from the UE, which the base station uses to identify the buffer size table;

[0025] Fig. 11 A is a flow diagram of an example method implemented in a UE for receiving a configuration from a RAN, configuring a buffer size table, obtaining an index value indexing a buffer size value, and transmitting a buffer status report including the index value;

[0026] Fig. 1 IB is a flow diagram of an example method similar to Fig. 11 A, but in which the buffer status report that the UE transmits to the RAN includes the first ID alongside the index value; and

[0027] Fig. 12 is a flow diagram of an example method for configuring a UE, which can be implemented in a DU of this disclosure.SUMMARY

[0028] An example embodiment of the techniques of this disclosure is a method implemented in a distributed unit (DU) of a distributed base station that also includes a central unit (CU). The method comprises obtaining an uplink (UL) data traffic assistance information for a UE;generating a configuration based on the UL data traffic assistance information; and transmitting the configuration to the UE, via the CU.

[0029] Another example embodiment of these techniques is a method implemented in a central unit (CU) of a distributed base station that also includes at least one distributed unit (DU). The method comprises obtaining an uplink (UE) data traffic assistance information for a UE; obtaining a configuration based on the UL data traffic assistance information; and transmitting the configuration to the UE.

[0030] Yet another example embodiment of these techniques is a radio access network (RAN) node comprising processing hardware and configured to implement one of the methods above.DETAILED DESCRIPTION OF THE DRAWINGS

[0031] Fig. 1 A depicts an example wireless communication system 100 in which communication devices can implement the power saving techniques of this disclosure. The wireless communication system 100 includes a UE 102, a base station 104 (source BS 104), a base station 106 (operating in the handover scenarios discussed below as the target BS 106, and a core network (CN) 110. The UE 102 initially connects to the base station 104. The base stations 104 and 106 can operate in a RAN 105 connected to the CN 110. The CN 110 can be implemented as an evolved packet core (EPC) 111 or a fifth generation (5G) core (5GC), 160, for example.

[0032] Among other components, the EPC 111 can include a Serving Gateway (SGW) 112, a Mobility Management Entity (MME) 114, and a Packet Data Network Gateway (PGW) 116. Generally speaking, the SGW 112 is configured to transfer user-plane packets related to audio calls, video calls, Internet traffic, etc., and the MME 114 is configured to manage authentication, registration, paging, and other related functions. The PGW 116 provides connectivity from the UE to external packet data networks including Internet network and / or an Internet Protocol (IP) Multimedia Subsystem (IMS) network by being the point of exit and entry of traffic for the UE. The 5GC 160 includes a User Plane Function (UPF) 162, an Access and Mobility Management Function (AMF) 164, and / or Session Management Function (SMF) 166. Generally speaking, the UPF 162 is configured to transfer user-plane packets related to audio calls, video calls, Internettraffic, etc., the AMF 164 is configured to manage authentication, registration, paging, and other related functions, and the SMF 166 is configured to manage PDU sessions.

[0033] As illustrated in Fig. 1A, the base station 104 supports a cell 124, and the base station 106 supports a cell 126. The baes statin 104 can additionally supports a cell 125. The cells 124 and 125 can partially overlap, so that while communicating with the UE 102 via the cell 124, the base station 104 hands over the UE 102 to the cell 125. The cells 124 and 126 can partially overlap, so that while communicating with the UE 102 via the cell 124, the base station 104 hands over the UE 102 to the base station 106 operating as a target base station. To directly exchange messages during handover scenarios discussed below, the base station 104 and the base station 106 can support an X2 or Xn interface. In general, the CN 110 can connect to any suitable number of base stations supporting NR cells and / or EUTRA cells.

[0034] In general, the wireless communication network 100 can include any suitable number of base stations supporting NR cells and / or EUTRA cells. More particularly, the EPC 111 or the 5GC 160 can be connected to any suitable number of base stations supporting NR cells and / or EUTRA cells. Although the examples below refer specifically to specific CN types (EPC, 5GC) and RAT types (5GNR and EUTRA), in general the techniques of this disclosure also can apply to other suitable radio access and / or core network technologies such as sixth generation (6G) radio access and / or 6G core network.

[0035] With continued reference to Fig. 1A, the base station 104 is equipped with processing hardware 130 that can include one or more general-purpose processors (e.g., CPUs) and a non- transitory computer-readable memory storing instructions that the one or more general-purpose processors execute. Additionally or alternatively, the processing hardware 130 can include special-purpose processing units. The processing hardware 130 can include a PHY controller 132 configured to transmit data and control signal on physical downlink (DL) channels and DL reference signals with one or more user devices (e.g., UE 102) via one or more cells and / or one or more TRPs. The PHY controller 132 is also configured to receive data and control signal on physical uplink (UL) channels and / or UL reference signals with the one or more user devices via one or more cells and / or one or more TRPs. The processing hardware 130 in an example implementation includes a MAC controller 134 configured to perform MAC functions with one or more user devices. The MAC functions include a random access (RA) procedure, managingUL timing advance for the one or more user devices, and / or communicating UL / DL MAC PDUs with the one or more user devices. The processing hardware 130 can further include an RLC controller (not show in Fig. 1 A) configured to perform RLC functions with one or more user devices. The processing hardware 130 can further include a PDCP controller (not show in Fig. 1A) configured to perform PDCP functions with one or more user devices. The processing hardware 130 can further include an RRC controller 136 to implement procedures and messaging at the RRC sublayer of the protocol communication stack. For example, the RRC controller 132 may be configured to support RRC messaging associated with resource configuration, measurement configuration procedure and reconfiguration procedure and / or handover procedures. The base station 106 can include processing hardware 140 that is similar to processing hardware 130. In particular, components 142, 144, and 146 can be similar to the components 132, 134, and 136, respectively.

[0036] The UE 102 is equipped with processing hardware 150 that can include one or more general -purpose processors such as CPUs and non-transitory computer-readable memory storing machine-readable instructions executable on the one or more general-purpose processors, and / or special-purpose processing units. The PHY controller 152 is also configured to receive data and control signal on physical DL channels and / or DL reference signals with the base station 104 or 106 via one or more cells and / or one or more TRPs. The PHY controller 152 is also configured to transmit data and control signal on physical UL channels and / or UL reference signals with the base station 104 or 106 via one or more cells and / or one or more TRPs. The processing hardware 150 in an example implementation includes a MAC controller 154 configured to perform MAC functions with base station 104 or 106. For example, the MAC functions include a random-access procedure, managing UL timing for communication with the base station 104 or 106, and communicating UL / DL MAC PDUs with the base station 104 or 106. The processing hardware 150 can further include an RRC controller 156 to implement procedures and messaging at the RRC sublayer of the protocol communication stack. The processing hardware 150 can further include an RLC controller (not show in Fig. 1 A) configured to perform RLC functions with the base station 104 or 106. The processing hardware 150 can further include a PDCP controller (not show in Fig. 1A) configured to perform PDCP functions with the base station 104 or 106.

[0037] Fig. IB depicts an example distributed or disaggregated implementation of any one or more of the base stations 104, 106. In this implementation, the base station 104, 106 includes a central unit (CU) 172 and one or more DUs 174. Each of the DU(s) can operate one or more cells. For example, the base station 104 includes a DU operating the cell 124 and / or cell 125. In another example, the base station 104 includes a DU 174A and a DU 174B that operate the cell 124 and the cell 125, respectively. The CU 172 includes processing hardware, such as one or more general -purpose processors (e.g., CPUs) and a computer-readable memory storing machine-readable instructions executable on the general-purpose processor(s), and / or specialpurpose processing units. For example, the CU 172 can include an RRC controller such as RRC controller 136, 146. The CU 172 can a PDCP controller and / or a Service Data Adaptation Protocol (SDAP) controller.

[0038] Each of the DUs 174 also includes processing hardware that can include one or more general-purpose processors (e.g., CPUs) and computer-readable memory storing machine- readable instructions executable on the one or more general-purpose processors, and / or specialpurpose processing units. For example, the processing hardware can include a MAC controller (e.g., MAC controller 132, 142) configured to manage or control one or more MAC operations or procedures (e.g., a random access procedure), and / or an RLC controller configured to manage or control one or more RLC operations or procedures. The process hardware can also include a physical layer controller configured to manage or control one or more physical layer operations or procedures.

[0039] In some implementations, the CU 172 can include a logical node CU-CP 172A that hosts the control plane part of the PDCP protocol of the CU 172. The CU 172 can also include logical node(s) CU-UP 172B that hosts the user plane part of the PDCP protocol and / or SDAP protocol of the CU 172. The CU-CP 172A can transmit control information (e.g., RRC messages, F l application protocol messages), and the CU-UP 172B can transmit the data packets (e.g., SDAP PDUs or Internet Protocol packets).

[0040] The CU-CP 172 A can be connected to multiple CU-UP 172B through the El interface. The CU-CP 172A selects the appropriate CU-UP 172B for the requested services for the UE 102. In some implementations, a single CU-UP 172B can be connected to multiple CU-CP 172A through the El interface. The CU-CP 172A can be connected to one or more DU 174s throughan Fl-C or Wl-C interface. The CU-UP 172B can be connected to one or more DU 174 through an Fl-U or Wl-U interface under the control of the same CU-CP 172A. In some implementations, one DU 174 can be connected to multiple CU-UP 172B under the control of the same CU-CP 172A. In such implementations, the connectivity between a CU-UP 172B and a DU 174 is established by the CU-CP 172A using Bearer Context Management functions.

[0041] Fig. 2A illustrates, in a simplified manner, an example protocol stack 200 according to which the UE 102 can communicate with an eNB / ng-eNB 230 or a gNB 232 (e.g., one or more of the base stations 104, 106).

[0042] In the example stack 200, a physical layer (PHY) 202A of EUTRA provides transport channels to the EUTRA MAC sublayer 204A, which in turn provides logical channels to the EUTRA RLC sublayer 206A. The EUTRA RLC sublayer 206A in turn provides RLC channels to an EUTRA PDCP sublayer 208 and, in some cases, to an NR PDCP sublayer 210. Similarly, the NR PHY 202B provides transport channels to the NR MAC sublayer 204B, which in turn provides logical channels to the NR RLC sublayer 206B. The NR RLC sublayer 206B in turn provides data transfer services to the NR PDCP sublayer 210. The NR PDCP sublayer 210 in turn can provide data transfer services to Service Data Adaptation Protocol (SDAP) 212 or a radio resource control (RRC) sublayer (not shown in Fig. 2A). The UE 102, in some implementations, supports both the EUTRA and the NR stack as shown in Fig. 2A, to support handover between EUTRA and NR base stations and / or to support DC over EUTRA and NR interfaces. Further, as illustrated in Fig. 2A, the UE 102 can support layering of NR PDCP 210 over EUTRA RLC 206A, and SDAP sublayer 212 over the NR PDCP sublayer 210.

[0043] The EUTRA PDCP sublayer 208 and the NR PDCP sublayer 210 receive packets (e.g., from an Internet Protocol (IP) layer, layered directly or indirectly over the PDCP layer 208 or 210) that can be referred to as service data units (SDUs), and output packets (e.g., to the RLC layer 206A or 206B) that can be referred to as protocol data units (PDUs). Except where the difference between SDUs and PDUs is relevant, this disclosure for simplicity refers to both SDUs and PDUs as “packets.”

[0044] On a control plane, the EUTRA PDCP sublayer 208 and the NR PDCP sublayer 210 can provide signaling radio bearers (SRBs) or RRC sublayer (not shown in Fig. 2A) to exchange RRC messages or non-access-stratum (NAS) messages, for example. On a user plane, theEUTRA PDCP sublayer 208 and the NR PDCP sublayer 210 can provide DRBs to support data exchange. Data exchanged on the NR PDCP sublayer 210 can be SDAP PDUs, Internet Protocol (IP) packets or Ethernet packets.

[0045] Fig. 2B illustrates, in a simplified manner, an example protocol stack 250 which the UE 102 can communicate with a DU (e.g., DU 174) and a CU (e.g., CU 172). The radio protocol stack 200 is functionally split as shown by the radio protocol stack 250 in Fig. 2B. The CU at any of the base stations 104 or 106 can hold all the control and upper layer functionalities (e.g., RRC 214, SDAP 212, NR PDCP 210), while the lower layer operations (e.g., NR RLC 206B, NR MAC 204B, and NR PHY 202B) are delegated to the DU. To support connection to a 5GC, NR PDCP 210 provides SRBs to RRC 214, and NR PDCP 210 provides DRBs to SDAP 212 and SRBs to RRC 214.

[0046] Next, several example scenarios in which the base station operating in the system of Fig. 1A and Fig. IB communicates data with the UE 102. Generally speaking, events in Figs. 3- 3C that are similar are labeled with similar reference numbers e.g., event 313 in Fig. 3A is similar to event 313 of Figs. 3B and 3C), with differences discussed below where appropriate. With the exception of the differences shown in the figures and discussed below, any of the alternative implementations discussed with respect to a particular event (e.g., for messaging and processing) may apply to events labeled with similar reference numbers in other figures.

[0047] Referring first to Fig. 3A, in a scenario 300A, the base station 104 includes a CU-CP 172A, a CU-UP 172B, and a DU 174. Initially, the UE 102 performs 302 a PDU Session Establishment procedure or a PDU Session Modification procedure with the CN 110 via the base station 104 (e.g., CU-CP 172A and DU 174) or the base station 106 (not shown in Fig. 3) to establish or modify a PDU session for performing one or more services. In some implementations, the service(s) function with a high data rate and low-latency transmission, such as XR services and / or cloud games. In some implementations, the UE 102 performs 302 the PDU Session Establishment procedure or PDU Session Modification procedure with the SMF 166 via the AMF 164 and the base station 104 or 106.

[0048] During the PDU Session Establishment procedure, the UE 102 transmits a PDU Session Establishment Request message to the CN 110 via the base station (e.g., the baes station 104 or 106). In some implementations, in response, the CN 110 sends a PDU SessionEstablishment Accept message to the CN 110 via the base station. In response to the PDU Session Establishment Accept message, the UE 102 transmits a. PDU Session Establishment Complete message to the CN 110 via the base station. During the PDU Session Modification procedure, the UE 102 transmits a PDU Session Modification Request message to the CN 110 via the base station. In some implementations, in response, the CN 110 sends a PDU Session Modification Command message to the CN 110 via the base station. In response to the PDU Session Modification Command message, the UE 102 then transmits a PDU Session Modification Complete message to the CN 110 via the base station.

[0049] In some implementations, the UE 102 includes, in the PDU Session Establishment Request message or PDU Session Modification Request message, a PDU session ID identifying the PDU session, the slice information, and / or a particular data network name (DNN). In some implementations, the CN 110 includes the PDU session ID in the PDU Session Establishment Accept message o PDU Session Modification Command message to indicate that the PDU session is established or modified successfully. In some implementations, the slice information indicates a specific slice configured for the service(s). For example, depending on the implementation, the slice information is a Single Network Slice Selection Assistance Information (S-NSSAI) or includes a portion of the S-NSSAI. In other implementations, the UE 102 includes, in the PDU Session Establishment Request message or PDU Session Modification Request message, UE-requested quality of service (QoS) parameters that the UE 102 uses to perform the service(s).

[0050] After performing 302 the PDU Session Establishment procedure, the UE 102 communicates 304 with the CN 110 via the base station 104 (e.g., the CU-CP 172A, CU-UP 172B and DU 174). Depending on the implementation, before, during, or after the procedure 302 or while communicating with the UE 102, the CU-CP 172A receives 306 a CN-to-BS message including UE capabilities of the UE 102 from the CN 110. For example, the CN-to-BS message can be a next generation application protocol (NGAP) message. In another example, the CN-to-BS message is an interface message for 6G. In some implementations, the CU-CP 172A transmits a CU-to-DU message including the UE capabilities to the DU 174. In some implementations, the CU-to-DU message is an Fl Application Protocol (F1AP) message, a UE Context Setup Request message, or a UE Context Modification Request message.

[0051] Alternatively, the CU-CP 172A transmits 308 a UE capability enquiry message to the UE 102 via the DU 174 to inquire regarding the UE capabilities. In response, the UE 102 transmits 310 a UE capability information message including the UE capabilities to the CU-CP 172A via the DU 174. In some implementations, the UE capabilities include new capabilities indicating support of one or more functions / features for enhancing communication of data utilizing high data rate and low latency, such as XR data or cloud gaming data. For example, the function(s) / feature(s) include multiple configured grant (CG) Physical Uplink Shared Channel (PUSCH) transmission occasions in a period of a single CG PUSCH configuration, an indication of unused CG PUSCH occasion(s) using UL control information (UCI), buffer status reporting (BSR) enhancements including at least new buffer status table(s), delay reporting of buffered data in uplink, provision of XR traffic assistance information for DL and UL (e.g., periodicity), and / or PDU Set-based QoS handling (e.g., discard operation of PDU Set(s)). A PDU Set includes one or more PDUs carrying a payload of a unit of information generated at the application level (e.g., frame(s), video slice(s), etc. for a XR services).

[0052] During or after the procedure 302 or during the communication 304, the CN 110 transmits 312 a PDU Session Resource Request message to the CU-CP 172 A to request the CU- CP 172A to assign resources for the PDU session and / or one or more QoS flows for the UE 102. The QoS flow(s) are associated with the PDU session. In some implementations, the CN 110 includes QoS parameters for the PDU session and / or QoS flow(s) in the PDU Session Resource Request message. For example, the CN 110 incudes a first set of PDU Set QoS parameters for the PDU session or the QoS flow(s) in the PDU Session Resource Request message. In one implementation, the CN 110 includes a first set of PDU Set QoS parameters to request or configure PDU Set-based QoS handling for the PDU session or the QoS flow(s). After (e.g., in response to) receiving the PDU Session Resource Request message, the CU-CP 172A transmits 313 a UE Context Request message for the PDU session or QoS flow(s) to the DU 174. In some implementations, the CU-CP 172A includes a second set of PDU Set QoS parameters in the UE Context Request message to request or configure PDU Set-based QoS handling for the PDU session or the QoS flow(s). In some implementations, the second set of PDU Set QoS parameters is the same as the first set of PDU Set QoS parameters. In other implementations, the second set of PDU Set QoS parameters is different from the first set of PDU Set QoS parameters. In some implementations, the CU-CP 172A determines the second set of PDU Set QoSparameters based on the first set of PDU Set QoS parameters. In such cases, the CU-CP 172A ensures that the second set of PDU Set QoS parameters satisfies the first set of PDU Set QoS parameters. For example, the CU-CP 172A determines the second set of PDU Set QoS parameters more stringent than the first set of PDU Set QoS parameters, considering latency in an Fl-U connection between the CU-UP 172B and DU 174, data processing time at the CU-UP 172B, and / or data processing time at the DU 174.

[0053] In some implementations, the CU-CP 172A determines to include or includes the second set of PDU Set QoS parameters in the UE Context Request message if the CU-CP 172A, the CU-UP 172B, and / or DU 174 support(s) PDU Set-based QoS handling. If the CU-CP 172A, CU-UP 172B, and / or DU 174 do not support PDU Set-based QoS handling, the CU-CP 172A does not include PDU Set QoS parameters (e g., the second set of PDU Set QoS parameters) in the UE Context Request message. In other implementations, the CU-CP 172A determines to include or includes the second set of PDU Set QoS parameters in response to receiving at least one of the new capabilities. In some such implementations, if the UE capabilities do not include the new capability / capabilities, the CU-CP 172A does not include the second set of PDU Set QoS parameters in the UE Context Request message.

[0054] In some implementations, the CN 110 includes a corresponding set of PDU Set QoS parameters for each of the QoS flow(s) indicated in the PDU Session Resource Request message. In some such cases, the CU-CP 172A includes a corresponding set of PDU Set QoS parameters in the UE Context Request message. In some implementations, for each of the QoS flow(s), the corresponding set of PDU Set QoS parameters in the UE Context Request message is the same as the corresponding set of PDU Set QoS parameters in the PDU Session Resource Request message. In other implementations, for each of the QoS flow(s), the CU-CP 172A 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.

[0055] In some implementations, the CN 110 includes, in the PDU Session Resource Request message, a first set of non-PDU Set QoS parameters (i.e., QoS parameter(s) not related to a PDU Set). In some such cases, the CU-CP 172A includes a second set of non-PDU Set QoS parameters in the UE Context Request message. In some implementations, the second set ofnon-PDU Set QoS parameters is the same as the first set of non-PDU Set QoS parameters. In other implementations, the CU-CP 172A determines the second set of non-PDU Set QoS based on the first set of non-PDU Set QoS parameters. In some implementations, the CN 110 includes a corresponding set of non-PDU Set QoS parameter(s) for each of the QoS flow(s) in the PDU Session Resource Request message. In some such cases, the CU-CP 172A includes a corresponding set of non-PDU Set QoS parameters for each of the QoS flow(s) in the UE Context Request message. In some implementations, for each of the QoS flow(s), the corresponding set of non-PDU Set QoS parameters in the UE Context Request message is the same as the corresponding set of non-PDU Set QoS parameters in the PDU Session Resource Request message. In other implementations, for each of the QoS flow(s), the CU-CP 172A 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 implementations, the CN 110 does not include, in the PDU Session Resource Request message, non-PDU Set QoS parameters for the PDU session or QoS flow(s). In some such cases, the CU-CP 172A does not include, in the UE Context Request message, non-PDU Set QoS parameters for the PDU session or QoS flow(s).

[0056] In some implementations, a set of non-PDU Set QoS parameters (e.g., as described above) include(s) a QoS identifier descriptor, a maximum flow bit rate for DL, a maximum flow bit rate for UE, a guaranteed flow bit rate for DL, and / or a guaranteed flow bit rate for UL.

[0057] In some implementations, the CN 110 includes a PDU Session ID identifying the PDU session in the PDU Session Resource Request message. In some implementations, the CN 110 includes one or more QoS flow identifiers identifying the QoS flow(s) in the PDU Session Resource Request message. Each of the QoS flow identifier(s) identifies a particular QoS flow of the QoS flow(s). In some implementations, the CU-CP 172A includes the QoS flow identifier(s) in the UE Context Request message and associates the QoS flow identifier(s) with the sets of the PDU Set QoS parameters and / or non-PDU Set QoS parameters.

[0058] In response to receiving 313 the UE Context Request message, the DU 174 transmits 314 a UE Context Response message to the CU-CP 172A. In some implementations, the DU 174 assigns resources for the PDU Session or QoS flow(s), generates DU configuration parameters for communicating data associated with the PDU session or QoS flow(s), andincludes the DU configuration parameters in the UE Context Response message. In some implementations, the DU 174 includes DL transport layer information in the UE Context Response message. In further implementations, the DL transport layer information configures a tunnel (e.g., GTP-U tunnel) for the CU-UP 172B to transmit DL PDUs for the UE 102 to the DU 174 in the DL data communication 324.

[0059] In some implementations, if the DU 174 supports PDU Set-based QoS handling or the second set of PDU Set QoS parameters, the DU 174 includes, in the UE Context Response message, confirmation information indicating that the DU 174 applies (e.g., performs) PDU Setbased QoS handling (e.g., for the PDU session or QoS flow(s)), based on the second set of PDU Set QoS parameters. In other implementations, if the DU 174 does not support PDU Set-based QoS handling or the second set of PDU Set QoS parameters, the DU 174 includes unsupported information (e.g., a cause (value)) in the UE Context Response message to indicate that the DU 174 does not support PDU Set-based QoS handling or the second set of PDU Set QoS parameters. In some alternative implementations, the DU 174 implicitly indicates that the DU 174 supports PDU Set-based QoS handling or the second set of PDU Set QoS parameters, by excluding the unsupported information in the UE Context Response message.

[0060] In some implementations, if the DU 174 supports the second set of PDU Set QoS parameters or PDU Set-based QoS handling, the DU 174 assigns resources for 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 implementations, if the UE 102 and / or DU 174 support(s) the second set of PDU Set QoS parameters or PDU Set-based QoS handling, the DU 174 may enable PDU Set-based QoS handling (e.g., for the PDU session or QoS flow(s)). In some implementations, the DU 174 enables PDU Set-based QoS handling after (e.g., in response to) receiving the second set of PDU Set QoS parameters or the UE Context Request message. In further implementations, the DU 174 enables PDU Set-based QoS handling (e.g., for the PDU session or QoS flow(s)), regardless of when the DU 174 receives the second set of PDU Set QoS parameters or the UE Context Request message.

[0061] In some implementations, the DU 174 includes a first CG configuration in the DU configuration parameters. The first CG configuration configures multiple CG PUSCH transmission occasions in a CG period. Depending on the implementation, the DU 174 does sobecause the UE capabilities include a first capability indicating that the UE 102 supports multiple CG PUSCH transmission occasions in a CG period in a single CG configuration. If the UE capabilities do not include the first capability, the DU 174 refrains from transmitting, to the UE 102, a CG configuration configuring multiple CG PUSCH transmission occasions in a CG period. In such cases, the DU 174 refrains from including the first CG configuration in the DU configuration parameters. In some implementations, the DU 174 includes, in the DU configuration parameters, a first configuration enabling indication of unused CG PUSCH occasion(s) using UCI. In some implementation, the DU 174 does so because the UE capabilities include a second capability indicating that the UE 102 supports indication of unused CG PUSCH occasion(s) using UCI. If the UE capabilities do not include the second capability, the DU 174 refrains from transmitting the first configuration to the UE 102. In such cases, the DU 174 refrains from including the first configuration in the DU configuration parameters.

[0062] In some implementations, if the UE 102 and / or DU 174 support(s) PDU Set-based QoS handling and / or the UE Context Request message includes PDU Set QoS parameters (e.g., the second set of PDU Set QoS parameters), the DU 174 includes, in the DU configuration parameters, at least one configuration parameter for PDU Set-based QoS handling. In some implementations, the DU 174 additionally accounts for the second set of non-PDU Set QoS parameters when configuring the configuration parameters and / or assigning resources for the UE 102. In other implementations, the DU 174 ignores the second set of non-PDU Set QoS parameters when configuring the configuration parameters and / or assigning resources for the UE 102. By properly assigning resources for the UE 102 and / or configuring the configuration parameters, the DU 174 ensures that data associated with the PDU session or QoS flow(s) is communicated with the UE 102 in compliance with the second set of PDU Set QoS parameters and / or the second set of non-PDU Set QoS parameters in the data communication 324. In some implementations, if the UE 102 and / or DU 174 support(s) PDU Set-based QoS handling and / or the UE Context Request message includes PDU Set QoS parameters (e.g., the second set of PDU Set QoS parameters), the DU 174 configures the at least one configuration parameter.Otherwise, if the UE 102 and / or DU 174 do not support PDU Set-based QoS handling and / or the UE Context Request message does not include PDU Set QoS parameters, the DU 174 does not include the at least one configuration parameter in the configuration parameters 314. In suchcases, the UE 102 disables or does not enable PDU Set-based QoS handling in response to receiving the configuration parameters excluding the at least one configuration parameter.

[0063] In other implementations, if the UE 102 and / or DU 174 do not support the second set of PDU Set QoS parameters or PDU Set-based QoS handling, the DU 174 assigns resources for the PDU Session or QoS flow(s) and / or generates the configuration parameters based on the second set of non-PDU Set QoS parameters. If the UE 102 and / or DU 174 do not support the 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, the DU 174 assigns resources for the PDU Session or QoS flow(s) and / or generates the configuration parameters based on predefined QoS parameters. In such implementations, the configuration parameters exclude the at least one configuration parameter for PDU Set-based QoS handling. By properly assigning resources and / or configuring the configuration parameters for the UE 102, the DU 174 ensures that data associated with the PDU session or QoS flow(s) is communicated with the UE 102 in compliance with the second set of non-PDU Set QoS parameters or predefined QoS parameters in the data communication 324.

[0064] In some implementations, the CU-CP 172A includes the UE capabilities in the UE Context Request message 313. In other implementations, the CU-CP 172A transmits another CU-to-DU message, including the UE capabilities, to the DU 174. In response, the DU transmits a DU-to-CU message to the CU-CP 172A. In some implementations, the CU-to-DU message and DU-to-CU message are a UE Context Setup Request message and a UE Context Setup Response message, respectively. Thus, the DU 174 can determine whether the UE 102 supports PDU Set-based QoS handling based on the UE capabilities.

[0065] The UE Context Request message and UE Context Response message form a UE Context procedure (e.g., a UE Context Setup procedure or a UE Context Modification procedure). In some implementations, the UE Context Request message and the UE Context Response message are a UE Context Setup Request message and a UE Context Setup Response message, respectively. In other implementations, the UE Context Request message and the UE Context Response message are a UE Context Modification Request message and a UE Context Modification Response message, respectively. In some alternative implementations, the DU 174 includes the configuration parameters in a UE Context Modification Required message instead ofthe UE Context Response message and transmits the UE Context Modification Required message to the CU-CP 172A. In some such cases, the CU-CP 172 A transmits a UE Context Modification Confirm message to the DU 174 in response to the UE Context Modification Required message.

[0066] After receiving 312 the PDU Session Resource Request message, transmitting 313 the UE Context Request message, or receiving 314 UE Context Response message, the CU-CP 172A performs a Bearer Context procedure with the CU-UP 172B to establish or modify a bearer context for the UE 102. In the Bearer Context procedure, the CU-CP 172A transmits 315 a Bearer Context Request message for the UE 102 (e.g., for the PDU session or QoS flow(s)) to the CU-UP 172B and, in response, the CU-UP 172B transmits 317 a Bearer Context Response message to the CU-CP 172A. In some implementations, the CU-UP 172B includes UL transport layer information in the Bearer Context Response message. The UL transport layer information configures a tunnel (e.g., GTP-U tunnel) for the DU 174 to transmit UL PDUs received from the UE 102 to the CU-UP 172B in the UL data communication (e.g., events 336, 342A). The CU- CP 172A then includes the UL transport layer information in the UE Context Request message 313. In some implementations, after receiving 314 UE Context Response message, the CU-CP 172A performs a Bearer Context Modification procedure with the CU-UP 172B to provide the DL transport layer information received in the UE Context Response message. In the Bearer Context Modification procedure, the CU-CP 172A transmits a Bearer Context Modification Request message including the DL transport layer information to the CU-UP 172B and, in response, the CU-UP 172B transmits a Bearer Context Modification Response message.

[0067] In some implementations, the Bearer Context procedure is a Bearer Context Setup procedure, and the Bearer Context Request message and the Bearer Context Response message are a Bearer Context Set Request message and a Bearer Context Setup Response message, respectively. In other implementations, the Bearer Context procedure is a Bearer Context Modification procedure, and the Bearer Context Request message and the Bearer Context Response message are a Bearer Context Modification Request message and a Bearer Context Modification Response message, respectively. In some such cases, the CU-CP 172A includes the DL transport layer information in the Bearer Context Modification Request message.

[0068] In some implementations, the CU-CP 172 A includes a third set of PDU Set QoS parameters for the UE 102 (e.g., for the PDU session or QoS flow(s)) in the Bearer ContextRequest message to request or configure PDU Set-based QoS handling for the PDU session or QoS flow(s). In some implementations, the third set of PDU Set QoS parameters is the same as the first or second set of PDU Set QoS parameters. In other implementations, the third set of PDU Set QoS parameters is different from the first set of PDU Set QoS parameters and / or the second set of PDU Set QoS parameters. In some implementations, the CU-CP 172 A determines the third set of PDU Set QoS parameters based on the first set of PDU Set QoS parameters. In such cases, the CU-CP 172A ensures that the third set of PDU Set QoS parameters satisfies the first set of PDU Set QoS parameters. For example, the CU-CP 172A determines the third set of PDU Set QoS parameters more stringently than the first set of PDU Set QoS parameters by considering latency in an Fl-U connection between the CU-UP 172B and DU 174, data processing time at the CU-UP 172B, and / or data processing time at the DU 174. In some implementations, the third set of PDU Set QoS parameters are the same as the second set of PDU Set QoS parameters.

[0069] In some implementations, the CU-CP 172A determines to include or includes the third set of PDU Set QoS parameters in the Bearer Context Request message if the CU-CP 172A and / or CU-UP 172B support(s) PDU Set-based QoS handling. If the CU-CP 172A and / or CU- UP 172B do not support PDU Set-based QoS handling, the CU-CP 172A does not include PDU Set QoS parameters (e.g., the third set of PDU Set QoS parameters) in the Bearer Context Request message. In other implementations, the CU-CP 172 A determines to include or includes the third set of PDU Set QoS parameters in the Bearer Context Request message in response to receiving at least one of the new capabilities. In some implementations, if the UE capabilities do not include the new capability / capabilities, the CU-CP 172A does not include the third set of PDU Set QoS parameters in the Bearer Context Request message.

[0070] In some such cases where the CN 110 includes a corresponding set of PDU Set QoS parameters for each of the QoS flow(s) indicated in the PDU Session Resource Request message, the CU-CP 172 A includes a corresponding set of PDU Set QoS parameters in the Bearer Context Request message. In some implementations, for each of the QoS flow(s), the corresponding set of PDU Set QoS parameters in the Bearer Context Request message is the same as the corresponding set of PDU Set QoS parameters in the PDU Session Resource Request message. In other implementations, for each of the QoS flow(s), the CU-CP 172A determines thecorresponding set of PDU Set QoS parameters in the Bearer Context Request message based on the corresponding set of PDU Set QoS parameters in the PDU Session Resource Request message, similar to determining the third set of PDU Set QoS parameters as described above.

[0071] In some cases where the CN 110 includes, in the PDU Session Resource Request message, the first set of non-PDU Set QoS parameters (i.e., QoS parameter(s) not related to a PDU Set), the CU-CP 172A includes a third set of non-PDU Set QoS parameters in the Bearer Context Request message. In some implementations, the third set of non-PDU Set QoS parameters is the same as the first set of non-PDU Set QoS parameters. In other implementations, the CU 172 determines the third set of non-PDU Set QoS based on the first set of non-PDU Set QoS parameters. In some implementations, the CN 110 includes a corresponding set of non-PDU Set QoS parameter(s) for each of the QoS flow(s) in the PDU Session Resource Request message. In some such cases, the CU 172 includes a corresponding set of non-PDU Set QoS parameters for each of the QoS flow(s) in the Bearer Context Request message. In some implementations, for each of the QoS flow(s), the corresponding set of non- PDU Set QoS parameters in the Bearer Context Request message is the same as the corresponding set of non-PDU Set QoS parameters in the PDU Session Resource Request message. In other implementations, for each of the QoS flow(s), the CU-CP 172 A determines the corresponding set of non-PDU Set QoS parameters in the Bearer Context Request message based on the corresponding set of non-PDU Set QoS parameters in the PDU Session Resource Request message. In other implementations, the CN 110 does not include, in the PDU Session Resource Request message, non-PDU Set QoS parameters for the PDU session or QoS flow(s). In some such cases, the CU 172 does not include, in the Bearer Context Request message, non- PDU Set QoS parameters for the PDU session or QoS flow(s).

[0072] In some implementations, a set of non-PDU Set QoS parameters (e.g., as described above) includes a QoS identifier descriptor, a maximum flow bit rate for DL, a maximum flow bit rate for UL, a guaranteed flow bit rate for DL, and / or a guaranteed flow bit rate for UL. In some implementations, the CU-CP 172A includes the QoS flow identifier(s) in the Bearer Context Request message and associates the QoS flow identifier(s) with the corresponding set of the PDU Set QoS parameters and / or non-PDU Set QoS parameters. In some implementations, the CU-CP 172A includes the PDU Session ID in the Bearer Context Request message.

[0073] In some implementations, the CU-UP 172B assigns resources for the PDU Session or QoS flow(s) in accordance with the Bearer Context Request message. In some implementations, the CU-UP 172B applies one or more configurations in the Bearer Context Request message to communicate data with the DU 174 and UE 102, where the data is associated with the PDU session or QoS flow(s). In some implementations, if the CU-UP 172B supports PDU Set-based QoS handling or the third set of PDU Set QoS parameters, the CU-UP 172B includes, in the Bearer Context Response message, confirmation information indicating that the CU-UP 172B applies PDU Set-based QoS handling based on the third set of PDU Set QoS parameters. In other implementations, if the CU-UP 172B does not support PDU Set-based QoS handling or the third set of PDU Set QoS parameters, the CU-UP 172B includes unsupported information (e.g., a cause (value)) in the Bearer Context Response message to indicate that the CU-UP 172B does not support PDU Set-based QoS handling or the third set of PDU Set QoS parameters. In some alternative implementations, the CU-UP 172B implicitly indicates that the CU-UP 172B supports PDU Set-based QoS handling or the third set of PDU Set QoS parameters by excluding the unsupported information in the Bearer Context Response message.

[0074] In some implementations, if the CU-UP 172B supports the third set of PDU Set QoS parameters or PDU Set-based QoS handling, the CU-UP 172B assigns resources for the PDU session or QoS flow(s) based on the third set of PDU Set QoS parameters. In some implementations, if the CU-UP 172B supports the third set of PDU Set QoS parameters or PDU Set-based QoS handling, the CU-UP 172B enables PDU Set-based QoS handling. In some implementations, the CU-UP 172B enables PDU Set-based QoS handling for the UE 102 (e.g., for the PDU session or QoS flow(s)) after (e.g., in response to) receiving the third set of PDU Set QoS parameters or the Bearer Context Request message. In other implementations, the CU-UP 172B enables PDU Set-based QoS handling regardless of when the CU-UP 172B receives the third set of PDU Set QoS parameters or the Bearer Context Request message. In some implementations, the CU-UP 172B additionally accounts for the third set of non-PDU Set QoS parameters when configuring the configuration parameters and / or assigning resources for the UE 102. In other implementations, the CU-UP 172B ignores the third set of non-PDU Set QoS parameters. By properly assigning resources for the UE 102 and / or configuring the configuration parameters, the CU-UP 172B ensures that data associated with the PDU session or QoS flow(s) is communicated with the DU 174 and / or the UE 102 in compliance with thethird / corresponding set of PDU Set QoS parameters and / or the third / corresponding set of non- PDU Set QoS parameters in the data communication 324.

[0075] In other implementations, if the CU-UP 172B does not support the third set of PDU Set QoS parameters or PDU Set-based QoS handling, the CU-UP 172B assigns resources for the PDU Session or QoS flow(s) based on the third set of non-PDU Set QoS parameters. If the CU- UP 172B does not support the third set of PDU Set QoS parameters or PDU Set-based QoS handling, and the Bearer Context Request message does not include non-PDU Set QoS parameters, the CU-UP 172B assigns resources for the PDU Session or QoS flow(s) based on predefined QoS parameters (e.g., non-PDU Set QoS parameters). By properly assigning resources for the UE 102, the CU-UP 172B ensures that data associated with the PDU session or QoS flow(s) is communicated with the DU 174 and / or the UE 102 in compliance with the third set of non-PDU Set QoS parameters and / or the predefined QoS parameters in the data communication 324.

[0076] In some implementations, the first, second, and / or third set(s) of PDU Set QoS parameters include(s) PDU Set Delay Budget (PSDB), PDU Set Error Rate (PSER), and / or PDU Set Integrated Handling Information (PSIHI). Depending on the implementation, the PSDB defines an upper bound for a delay time that a PDU Set experiences for the transfer between the UE 102 and the CN 110 (e.g., the UPF 162). In some implementations, for DL, the delay time is a time duration between the reception time of the first PDU of a DL PDU Set at the CN 110 (e.g., the UPF 162) and the time when the UE successfully receives all PDUs of the DL PDU Set. In further implementations, for UL, the delay time is a time duration between the reception time of the first PDU of a UL PDU Set at the UE 102 (e.g., the reception time where a protocol layer of the UE 102 receives the first PDU from an application) and the time when the CN 110 (e.g., the UPF 162) successfully receives all PDUs of the UL PDU Set. Depending on the implementation, the protocol layer is the SDAP 212, PDCP 210, RLC 206, or MAC 204 protocol layer. In some implementations, the application is an operating system (e.g., Android, iOS, Windows or Linux). In some implementations, the PSDB applies to a DL PDU Set for the UE 102 received by the CN 110 (e.g., the UPF 162), and applies to the UL PDU Set sent by the UE 102. The PSER defines an upper bound for a rate of PDU Sets that have been processed by a sender (e.g., the UE 102, CU 172 or DU 174) of a link layer protocol (e.g., RLC 206) but that arenot successfully delivered by a corresponding receiver to an upper layer (e.g., PDCP 210) of the receiver. Thus, the PSER defines an upper bound for a rate of non-congestion related PDU Set losses. The PSER allows for appropriate link layer protocol configurations (e.g., PDCP configuration, RLC bearer configuration, MAC configuration, and / or HARQ configuration) in the configuration parameters. The PSIHI indicates whether all PDUs (e.g., data packets) of a PDU Set are to be used by the PDU Set by the application layer in a receiver. If the PDU Set is a DL PDU Set, the receiver is the UE 102. If the PDU Set is a UL PDU Set, the receiver is the DU 174, CU-UP 172B, or CN 110. In some implementations, the CU-UP 172B or DU 174 determines whether to discard a PDU Set associated with the PDU session or QoS flow(s) based on the PSIHI and PSDB. In some examples, if the CU-UP 172B or DU 174 determines that transmission of a PDU Set exceeds the PSDB, and the PSIHI indicates that all PDUs of a PDU Set are to be used by the PDU Set by the application layer in the UE 102, the CU-UP 172B, or DU 174 discards the PDU Set. Otherwise, the CU-UP 172B or DU 174 does not discard the PDU Set and transmits the PDU Set to the DU 174 or UE 102.

[0077] After (e.g., in response to) receiving the UE Context Response message or UE Context Modification Required message, the CU-CP 172A transmits 316 an RRC reconfiguration message to the UE 102 via the DU 174. In response, the UE 102 transmits 318 an RRC reconfiguration complete message to the CU-CP 172A via the DU 174. If the CU-CP 172A receives the DU configuration parameters, the CU-CP 172A includes the DU configuration parameters in the RRC reconfiguration message. In some implementations, if the UE 102 and / or base station 104 (e.g., the CU-CP 172A, CU-UP 172B, and / or DU 174) support(s) PDU Setbased QoS handling and / or the PDU Session Resource Request message includes PDU Set QoS parameters (e.g., the first set of PDU Set QoS parameters), the CU-CP 172A includes at least one configuration for PDU Set-based QoS handling in the RRC reconfiguration message. In some implementations, the UE 102 enables PDU Set-based QoS handling in response to receiving the RRC reconfiguration message, configuration(s) for PDU Set-based QoS handling, and / or the configuration parameters(s) in the DU configuration parameters. Otherwise, if the UE 102 and / or base station 104 do not support PDU Set-based QoS handling and / or the PDU Session Resource Request message does not include PDU Set QoS parameters, the CU-CP 172A does not include configuration parameter(s) for PDU Set-based QoS handling in the RRCreconfiguration message. Thus, the UE 102 refrains from enabling or disables PDU Set-based QoS handling in response to receiving the RRC reconfiguration message.

[0078] In some implementations, the CU-CP 172A includes a measurement configuration and / or one or more DRB configurations in the RRC reconfiguration message. The measurement configuration configures the UE 102 to measure a reference signal on a carrier frequency and report measurement results that the UE obtains from the measurement of the reference signal. The DRB configuration(s) configure one or more DRBs associated with the PDU session and / or QoS flow(s). Depending on the implementation, each of the DRB configuration(s) includes a PDCP configuration and / or a SDAP configuration. In some implementations, the CU-CP 172A includes the configuration parameter(s) for PDU Set-based QoS handling in the DRB configuration(s), PDCP configuration(s), and / or SDAP configuration(s). In some implementations, the DU configuration parameters include one or more REC bearer configurations, each configuring an RLC bearer for a particular DRB, and / or include MAC configuration parameters and / or physical layer configuration parameters. In some implementations, the CU-CP 172A determines or configures the PDCP configuration(s) and / or SDAP configuration(s) based on the first set of PDU Set QoS parameters, second set of PDU Set QoS parameters, or third set of PDU Set QoS parameters.

[0079] Before or after receiving the UE Context Response message or receiving the RRC reconfiguration complete message, the CU-CP 172A transmits 320 a PDU Session Resource Response message to the CN 110 in response to receiving the PDU Session Resource Request message. In some implementations, if the base station 104 supports PDU Set-based QoS handling as described above, the CU-CP 172A includes, in the PDU Session Resource Response message, confirmation information indicating that the base station 104 applies PDU Set-based QoS handling based on the first set of PDU Set QoS parameters. In other implementations, if the base station 104 does not support PDU Set-based QoS handling (e.g., based on the first set of PDU Set QoS parameters), the CU-CP 172A includes unsupported information (e.g., a cause (value)) in the PDU Session Resource Response message to indicate that the base station 104 does not support PDU Set-based QoS handling or the first set of PDU Set QoS parameters. In some alternative implementations, if the base station 104 supports PDU Set-based QoS handling as described above, the CU-CP 172A implicitly indicates that the base station 104 supports thefirst set of PDU Set QoS parameters or PDU Set-based QoS handling by excluding the unsupported information in the PDU Session Resource Response message.

[0080] In some implementations, the PDU Session Resource Request message and the PDU Session Resource Response message are a PDU Session Resource Setup Request message and a PDU Session Resource Setup Response message, respectively. In other implementations, the PDU Session Resource Request message and the PDU Session Resource Response message are a PDU Session Resource Modify Request message and a PDU Session Resource Modify Response message, respectively.

[0081] After receiving the PDU Session Resource Response message, the CN 110 (e.g., the UPF 162) performs 324 data communication with the UE 102 via the base station 104. For example, the CN 110 transmits 324 DL data packets 1, . .. , N associated with the PDU session or QoS flow(s) to the UE 102 via the CU-UP 172B and DU 174. N is an integer and larger than zero. In some implementations, the CN 110 receives the DL data packets 1, . . ., N from a packet data network (e.g., a cloud server or an application server). The CN 110 generates CN-to-CU- UP packets 1 , .. . , N including the DL data packets 1 , . .. , N, respectively. Each of the CN-to- CU-UP packets 1, . .. , N includes one or more protocol headers. The CN 110 transmits the CN- to-CU-UP packets 1, ..., N to the CU-UP 172B. In some implementations, the CN-to-CU-UP packet are General Packet Radio System (GPRS) Tunneling Protocol User Plane (GTP-U) packets. The protocol header(s) include an Internet Protocol (IP) header, a User Datagram Protocol (UDP) header, and / or a GTP-U header. The CU-UP 172B retrieves the DL data packets 1, . .., N from the CN-to-CU-UP packets 1, .. ., N; generates DL PDUs 1, . .., N including the DL data packets 1, . .. , N; and transmits the CU-UP-to-DU packets 1, . . . , N to the DU 174. Each of the CU-UP-to-DU packets 1, . .. , N includes one or more protocol headers. In some implementations, the CU-UP-to-DU packets are GTP-U packets. The protocol header(s) include an IP header, a UDP header, and / or a GTP-U header. The DU 174 retrieves the DL PDUs 1 , . .. , N from the CU-UP-to-DU packets. The DU 174 transmits the DL PDU 1, . . . , N to the UE 102 via protocol layers (e.g., NR RLC 206B, NR MAC 204B, and NR PHY 202B). The transmission is based on the configuration parameters 316 and uses resources assigned to the UE 102.

[0082] After receiving the RRC reconfiguration complete message, the UE 102 transmits 324 UL data packets 1, . . ., M associated with the PDU session or QoS flow(s) to the base station 104via protocols (e.g., NR PDCP 208, NR RLC 206B, NR MAC 204B, and NR PHY 202B). M is an integer and larger than zero. The transmission is based on the configuration parameters 316 and uses resources assigned to the UE 102. The UE 102 generates UL PDUs (e.g., PDCP PDU or SDAP PDU) 1, . .. , M, including the UL data packets 1, . .. , M, respectively. The UE 102 transmits the UL PDUs 1, . . . , M via protocol layers (e.g., NR RLC 206B, NR MAC 204B, and NR PHY 202B) to the DU 174. The DU 174 generates DU-to-CU-UP packets 1, .. ., M including the UL PDUs 1, .. . , M, respectively. The DU 174 transmits the DU-to-CU-UP packets 1, . .. , M to the CU-UP 172B. Each of the CN-to-CU-UP packets 1, . . . , M includes one or more protocol headers. For example, the DU-to-CU-UP packets are GTP-U packets. The protocol header(s) include an IP header, a UDP header, and / or a GTP-U header. The CU-UP 172B retrieves UL data packets 1, .. . , M from the UL PDUs 1, . .. , M; generates CU-UP -to-CN packets including the UL data packets 1, . . ., M; and transmits the CU-UP -to-CN packets 1, . . ., M to the CN 110 (e g., the UPF 162). For example, the CU-UP -to-CN packets are GTP-U packets. The protocol header(s) include an IP header, a UDP header, and / or a GTP-U header. In some implementations, the CN 110 retrieves the UL data packets 1, . . ., N from the CU-UP -to-CN packets and transmits the UL data packets to the packet data network.

[0083] In some implementations, while the UE 102 communicates with the DU 174 in the data communication 324, the UE 102 performs discontinuous reception (DRX) periodically with DU 174 in accordance with a first DRX configuration. The first DRX configuration configures a first DRX cycle consisting of a start offset, an on-duration, an off-duration, and / or a DRX cycle length. The first DRX cycle periodically occurs according to the first DRX configuration. In some implementations, the UE 102 receives the first DRX configuration in a message from the base station 104 (e.g., the CU-CP 172A) or base station 106. For example, the message is an RRC reconfiguration message 316 or another RRC reconfiguration message. In another example, the message is an RRC resume message. The CU-CP 172A receives the first DRX configuration from the DU 174.

[0084] During or before the data communication 324, the UE 102 transmits 322 at least one first buffer status report (BSR) to report buffer status to the DU 174. In each BSR, the UE 102 includes a buffer size index that indicates a buffer size range. In some implementations, the UE 102 generates the index based on a first buffer size table (e.g., as depicted in Appendix A) andthe size of data available for transmission at the time of the BSR being triggered. During the data communication 324, the DU 174 transmits uplink grants to the UE 102, to accommodate UL data available for transmission, based on the buffer size index / indexes. The UE 102 transmits the UL data packets to the DU 174 using the uplink grants in the data communication 324. In some implementations, the first buffer size table is predefined in a 3GPP specification (e.g., Table 6.1.3.1-2 in 3GPP specification 38.321). In other implementations, the base station 104 transmits a first buffer size table configuration configuring the first buffer size table to the UE 102 before the event 322. For example, the CU-CP 172A receives the first buffer size table configuration from the DU 174 in a DU-to-CU-CP message and transmits an RRC message, including the first buffer size table configuration, to the UE 102. In some implementations, the DU 174 generates the first buffer size table configuration in response to receiving the QoS parameters and / or UE Capabilities received in the UE Context Request message 313. In some implementations, the DU-to-CU-CP message is the UE Context Response message 314. In other implementations, the DU-to-CU-CP message is another UE Context Response message in response to another UE Context Request message sent by the CU-CP 172 A. In yet other implementations, the DU-to-CU-CP message is a UE Context Modification Required message. In some implementations, the RRC message is an RRC reconfiguration message 316, another RRC reconfiguration message, or an RRC resume message.

[0085] In some implementations, the UE 102 transmits 326 first UL data traffic assistance information to the DU 174 during the data communication 324. In some implementations, the UE 102 includes the first UL data traffic assistance information in a MAC control element (CE) and transmits 326 a UL MAC PDU including the MAC CE to the DU 174. In other implementations, the DU 174 obtains the first UL data traffic assistance information based on monitoring UL PDUs received from the UE 102 in the data communication 324. Based on the first UL data traffic assistance information, the DU 174 generates a DU configuration (e.g., a CellGroupConfig E) and transmits 328 a UE Context Modification Required message including the DU configuration. After receiving 328 the DU configuration, the CU-CP 172A transmits 330 an RRC reconfiguration message, including the DU configuration 330, to the UE 102 via the DU 174. In response, the UE 102 applies the DU configuration to communicate with the DU 174 and transmits 332 an RRC reconfiguration complete message to the CU-CP 172A via the DU 174.

[0086] In some implementations, the first UL data traffic assistance information includes first UL timing jitter information. In some implementations, the first UL timing jitter information includes a jitter value indicating a time duration relative to a reference time point known by the UE 102 and / or DU 174. In some implementations, the jitter value is a filtered jitter value as described below. Depending on the implementation, the jitter value is a positive value, a zero value, or a negative value. Similarly, depending on the implementation, time duration has a unit of symbols, slots, or milliseconds. In some implementations, the first UL data traffic assistance information or the first UL timing jitter information includes reference time point information for the DU 174 to derive the reference time point. For example, the reference time point information includes a symbol number, a slot number, a system frame number, and / or a periodicity to indicate the reference time point. In further implementations, the UE 102 and / or the DU 174 derives the reference time point in each period based on the symbol number, slot number, system frame number, and / or periodicity. In other implementations, the reference time point is the Xth slot in the on-duration in each occurrence of the first DRX cycle, where X > 0. In yet other implementations, the reference time point is the Yth symbol in the Xth slot in the on-duration in each occurrence of the first DRX cycle, where X > 0 and Y > 0. The positive value indicates that UL data arrives at the UE 102 (e.g., a buffer of the UE 102) or the DU 174 later than the reference time point. The negative value indicates that UL data arrives at the UE 102 or the DU 174 earlier than the reference time point. Value zero indicates that UL data arrives at the UE 102 or the DU 174 on the reference time point.

[0087] In some implementations, the UE 102 or DU 174 applies the following filtering to obtain a filtered jitter value: In= (1-Alpha)* Jn-i + Alpha *jn, where n > 0, jnis the latest obtained (e.g., calculated) jitter value, Jnis an updated filtered jitter value, and Io is set to ji when the first jitter value is obtained. Similarly, Alpha is a weighting parameter with a value between 0 and 1. In some implementations, Alpha is a predefined value (e.g., predefined in a 3GPP specification (e.g., 38.331 or 38.133)). In other implementations, the base station 104 (e.g., the CU-CP 172A or DU 174) transmits Alpha to the UE 102.

[0088] In some implementations, the UE 102 includes a maximum jitter value and / or a minimum jitter value of the jitter values j i, .. . , jnin the first UL data traffic assistance information in addition to the filtered jitter value. In some implementations, the UE 102 roundsthe unfiltered jitter value(s) (e.g., jitter values j i, .. . , jn) and / or the filtered jitter value to a defmed / configured step size in units of milliseconds, OFDM symbols, or slots. In other implementations, the UE 102 maps the unfiltered jitter value(s) (e.g., jitter values ji, . .., jn) and / or the filtered jitter value to an index or indices based on a jitter reporting table and includes the index or indices in the first UL data traffic assistance information.

[0089] In some implementations, the CU-CP 172A transmits a configuration to the UE 102, enabling transmission of UL data traffic assistance information. For example, the CU-CP 172A includes the configuration in the RRC reconfiguration message 316 or another RRC reconfiguration message transmitted to the UE 102. In other implementations, the DU 174 transmits the configuration to the UE 102 via the CU-CP 172A, similar to the events 314 and 316. The UE 102 enables reporting of UL data traffic assistance information in response to receiving the configuration. In some implementations, after or when enabling reporting UL data traffic assistance information, the UE 102 transmits UL data traffic assistance information (e.g., the first UL data traffic assistance information). In some implementations, the configuration enables transmission of UL timing jitter information. In some implementations, the configuration configures the UE 102 to transmit UL timing jitter information when a jitter value (e.g., jk, 1 < k < n) or the filtered jitter value is larger than or equal to a threshold. The configuration configures a value of the threshold. When the UE 102 detects that a jitter value (e.g., jk, 1 < k < n) or a filtered jitter value is larger than or equal to the threshold, the UE 102 transmits UL timing jitter information including the filtered jitter value and / or the jitter value. In other implementations, the configuration configures periodic reporting of UL timing jitter information. The UE 102 periodically transmits UL timing jitter information to the DU 174 in accordance with the configuration. For example, the configuration includes a timer value for the periodic reporting. The UE 102 starts or restarts a timer for the periodic reporting with the timer value. When the timer expires, the UE transmits UL timing jitter information (e.g., the first UL timing jitter information) to the DU 174, where the UL timing jitter information includes the maximum jitter value and / or the minimum jitter value of obtained jitter values and / or a filtered value based on the obtained jitter values. The UE 102 restarts the timer when the timer expires or when transmitting the UL timing jitter information. When the timer expires again, the UE 102 transmits UL timing jitter information to the DU 174 as described above. If the UE 102 does not receive the configuration, the UE 102 refrains from enabling reporting UL data traffic assistanceinformation or refrains from transmitting UL data traffic assistance information (e.g., the first UL data traffic assistance information).

[0090] In some implementations, the DU configuration (i.e., the first DU configuration) includes a second DRX configuration updating (e.g., modifying or replacing) the first DRX configuration. The DU 174 generates the second DRX configuration to accommodate UL jitter indicated in the first UL timing jitter information. In other implementations, the DU configuration includes a second CG configuration updating (e.g., modifying or replacing) the first CG configuration. The DU 174 generates the second CG configuration to accommodate UL jitter indicated in the first UL timing jitter information. In some implementations, after applying the DU configuration, the UE 102 transmits second UL timing jitter information to the DU 174 in a similar way as described for the first UL timing jitter information. Depending on the implementation, based on the second UL timing jitter information, the DU 174 generates a second DU configuration to the UE 102 and transmits the second DU configuration via the CU- CP172A to the UE 102, as described for the first DU configuration.

[0091] In some implementations, the first UL data traffic assistance information includes an indication that indicates a buffer size table preferred by the UE 102. In some implementations, the UE 102 prefers the buffer size table that minimizes the quantization error between the buffer size indices and buffer sizes in the table. Based on the preferred buffer size table indicated in the first UE data traffic assistance information, the DU 174 generates a buffer size table configuration to configure the preferred buffer size table. In one implementation, the first UL data traffic assistance information includes an ID identifying the buffer size table. For example, multiple buffer size tables are predefined (e.g., in 3GPP specification 38.321) and each of the tables is identifiable according to a predefined ID. The UE 102 prefers a buffer size table from the multiple buffer size tables and includes a predefined ID identifying the preferred buffer size table in the first UL data traffic assistance information. In some implementations, when receiving the predefined ID, the DU 174 generates a buffer size table configuration including the predefined ID and includes the buffer size table configuration in the DU configuration. In some implementations, when the UE 102 receives the buffer size table configuration, the UE 102 identifies a buffer size table in accordance with the predefined ID and applies the buffer size table to transmit a BSR. In other implementations, the DU 174 transmits a buffer size tableactivation command to the UE 102 to activate the buffer size table. Depending on the implementation, the activation command includes the predefined ID or an indication (e.g., a bit) indicating the predefined ID. The UE 102 applies the buffer size table in response to receiving the activation command. After applying the buffer size table, the UE 102 transmits 334 a BSR using the buffer size table. Based on the buffer size table, the UE 102 generates a buffer size index and includes the index in the BSR 334, similar to generating and transmitting the BSR 322.

[0092] In another implementation, the DU 174 transmits one or more buffer size table configurations to the UE 102 to configure multiple buffer size tables and IDs, each identifying a particular one of the tables. The UE 102 prefers a buffer size table from the multiple buffer size tables and includes a configured ID identifying the preferred buffer size table in the first UL data traffic assistance information. In some implementations, when receiving the predefined ID, the DU 174 generates a buffer size table configuration including the configured ID and includes the buffer size table configuration in the DU configuration. In some implementations, when the UE 102 receives the buffer size table configuration, the UE 102 identifies a buffer size table in accordance with the configured ID and applies the buffer size table to transmit a BSR. In other implementations, the DU 174 transmits a buffer size table activation command to the UE 102 to activate the buffer size table. Depending on the implementation, the activation command includes the configured ID or an indication (e.g., a bit) indicating the configured ID. The UE 102 applies the buffer size table in response to receiving the activation command. After applying the buffer size table, the UE 102 transmits 334 a BSR using the buffer size table. Based on the buffer size table, the UE 102 generates a buffer size index and includes the index in the BSR 334, similar to generating and transmitting the BSR 322.

[0093] In yet another implementation, the UE 102 includes, in the first UL data traffic assistance information, one or more parameters for generating a preferred buffer size table based on a formula or equation. The DU 174 includes the one or more parameters in a buffer size table configuration and includes the buffer size configuration in the DU configuration. In some implementations, when the UE 102 receives the buffer size table configuration, the UE 102 applies the buffer size table generated from the one or more parameters, formulae, and / or equations. In other implementations, the DU 174 transmits a buffer size table activation command to the UE 102 to activate the buffer size table. Depending on the implementation, theactivation command includes an ID identifying the parameter(s) or an indication (e.g., a bit) indicating the ID. The UE 102 applies the buffer size table in response to receiving the activation command. After applying the buffer size table, the UE 102 transmits 334 a BSR using the generated buffer size table. Based on the buffer size table, the UE 102 generates a buffer size index and includes the index in the BSR 334, similar to generating and transmitting the BSR 322.

[0094] In some implementations, the CU-CP 172A transmits a configuration to the UE 102, enabling transmission of a preferred buffer size table. For example, the CU-CP 172A includes the configuration in the RRC reconfiguration message 316 or another RRC reconfiguration message transmitted to the UE 102. In other implementations, the DU 174 transmits the configuration to the UE via the CU-CP 172A, similar to the events 314 and 316. The UE 102 enables transmission of a preferred buffer size table in response to receiving the configuration. In some implementations, after or when enabling transmission of a preferred buffer size table, the UE 102 transmits a preferred buffer size table as described above. In some implementations, the configuration configures the UE 102 to transmit a preferred buffer size table when the UE 102 detects that a quantization error between the buffer size indices and buffer sizes in the table currently being used by the UE 102 is larger than or equal to a threshold. If the UE 102 detects that a quantization error between the buffer size indexes and buffer sizes in the table currently being used by the UE 102 is larger than or equal to a threshold, the UE 102 transmits, to the DU 174, UL data traffic assistance information (e.g., the first UL data traffic assistance information) indicating a preferred buffer size table that minimizes the quantization error between the buffer size indices and buffer sizes.

[0095] Fig. 3B illustrates an example scenario 300B similar to the scenario 300A illustrated in Fig. 3A. The differences between the scenarios 300A and 300B are described below. In particular, in the scenario 300B, the UE 102 transmits 325 the first UL data traffic assistance information to the CU-CP 172A via the DU 174, and the CU-CP 172A forwards 327 the first UL data traffic assistance information to the DU 174. In some implementations, the first UL data traffic assistance information is an RRC IE.

[0096] Fig. 3C illustrates an example scenario 300C similar to the scenarios 300A and 300B illustrated in Figs. 3A and 3B. The differences among the scenarios 300A, 300B, and 300C are described below. In particular, in the scenario 300C, the CU-UP 172B generates or obtains ULdata traffic assistance information for the UE 102, similar to the first UL data traffic assistance information described for Fig. 3A and transmits 323 the UL data traffic assistance information to the CU-CP 172A. In turn, the CU-CP 172A transmits 327 the UL data traffic assistance information to the DU 174.

[0097] Next, several example methods that can be implemented in the components discussed herein are discussed with reference to Figs. 4-1 IB. Generally speaking, similar events in Figs. 4- 1 IB are labeled with the similar reference numbers that share two least significant digits, with differences discussed below where appropriate (e.g., event 404 is similar to events 604A, 604B). Each of these methods can be implemented using processing hardware such as one or more processors to execute instructions stored on a non-transitory computer-readable medium such as computer memory.

[0098] Fig. 4 illustrates an example method 400, implemented by a DU (e.g., the DU 174) communicating with a CU (e.g., the CU 172) and a UE (e.g., the UE 102), for reducing data communication overhead with UL data traffic assistance information.

[0099] The method 400 begins at block 426A, where the DU obtains first UL data traffic assistance information for the UE (e.g., events 326, 327). At block 431 A, the DU generates at least one first configuration based on the first UL data traffic assistance information (e.g., event 328). At block 428A, the DU transmits the at least one first configuration to the UE via the CU (e.g., event 328). At block 433A, the DU communicates with the UE in accordance with the at least one first configuration. At block 426B, the DU obtains second UL data traffic assistance information for the UE (e.g., events 326, 327). At block 43 IB, the DU generates at least one second configuration based on the second UL data traffic assistance information (e.g., event 328). At block 428B, the DU transmits the at least one second configuration to the UE via the CU (e.g., event 328). At block 433B, the DU communicates with the UE in accordance with the at least one second configuration.

[0100] Fig. 5 illustrates an example method 500, implemented by a CU (e.g., the CU 172 or CU-CP 172A) communicating with a UE (e.g., the UE 102) via at least one DU (e.g., the DU 174), another CU, or a base station (e.g., base station 104) of a RAN (e.g., RAN 105), for reducing data communication overhead with UL data traffic assistance information.

[0101] The method 500 begins at block 525A, where the CU receives first UL data traffic assistance information for a UE (e.g., event 325). At block 527A, the CU transmits a CU-to-DU message including the first UL data traffic information to a first DU (e.g., event 327). At block 528A, the CU receives a DU-to-CU message, including at least one first configuration, from the first DU (e.g., event 328). At block 530A, the CU transmits the at least one first configuration to the UE via a RAN node (e.g., the first DU, a second DU, a second CU, or a base station) (e.g., event 330). At block 525B, the CU receives second UL data traffic assistance information of the UE (e.g., event 325). At block 527B, the CU transmits a CU-to-DU message, including the second UL data traffic information, to the first DU (e.g., event 327). At block 528B, the CU receives a DU-to-CU message, including at least one second configuration, from the first DU (e.g., event 328). At block 53OB, the CU transmits at least one second configuration to the UE via the RAN node (e.g., event 330).

[0102] Fig. 6 illustrates an example method 600, implemented by a DU (e.g., the DU 174) communicating with a CU (e.g., the CU 172) and a UE (e.g., the UE 102), for reducing data communication overhead with UL data traffic assistance information.

[0103] The method 600 begins at block 627A, where the DU receives a CU-to-DU message including the first UL data traffic information for a UE from CU (e.g., event 327). At block 629A, the DU generates at least one first configuration based on the first UL data traffic information (e.g., event 328). At block 628A, the DU transmits a DU-to-CU message, including the at least one first configuration, to the CU (e.g., event 328). At block 630A, the DU transmits at least one first configuration to the UE (e.g., event 330). At block 633A, the DU communicates with the UE in accordance with the at least one first configuration. At block 627B, the DU receives a CU-to-DU message, including the second UL data traffic information for the UE, from the CU (e.g., event 327). At block 629B, the DU generates at least one second configuration based on the second UL data traffic information (e.g., event 328). At block 628B, the DU transmits a DU-to-CU message, including the at least one second configuration, to the CU (e.g., event 328). At block 630B, the DU transmits the at least one second configuration to the UE (e.g., event 330). At block 633B, the DU communicates with the UE in accordance with the at least one second configuration.

[0104] Fig. 7 illustrates an example method 700, implemented by a UE (e.g., the UE 102), for transmitting UL data traffic assistance information to a RAN (e.g., the RAN 105).

[0105] The method 700 begins at block 710, where the UE transmits a capability indicating support for reporting UL data traffic assistance information to the RAN (e.g., event 310). At block 704, the UE receives a configuration from the RAN, enabling the UE to transmit UL data traffic assistance information (e.g., event 304 or 316). At block 725A, the UE transmits first UL data traffic assistance information to the RAN in accordance with the configuration (e.g., event 325 or 326). At block 730A, the UE receives at least one first configuration from the RAN after transmitting the first UL data traffic assistance information (e.g., event 330). At block 733A, the UE communicates with the RAN in accordance with the at least one first configuration and at least a portion of the configuration parameters. At block 725B, the UE transmits second UL data traffic assistance information to the RAN in accordance with the configuration (e g., event 325 or 326). At block 730B, the UE receives at least one second configuration from the RAN after transmitting the second UL data traffic assistance information (e.g., event 330). At block 733B, the UE communicates with the RAN in accordance with the at least one second configuration and at least a portion of the configuration parameters.

[0106] In some implementations, the UE detects at least one first condition is met and transmits the first UL data traffic information in response to the detection. In some implementations, the UE detects at least one second condition is met and transmits the second UL data traffic information in response to the detection. Depending on the implementation, the at least one first condition and the at least one second condition are the same or different. In further implementations, the at least one first condition and the at least one second condition are partially the same. In some implementations, the configuration at block 704 includes one or more parameters configuring the at least one first condition and / or the at least one second condition.

[0107] Fig. 8A illustrates an example method 800A, implemented by a base station (e.g., the base station 104, CU 172 or CU-CP 172A) communicating with a UE (e.g., the UE 102), for reducing data communication overhead with UL data traffic assistance information.

[0108] The method 800A begins at block 810, where the base station receives UE capabilities of a UE (e.g., event 310). At block 840, the base station determines whether the UE capabilities include a capability that indicates support for reporting UL data traffic assistance information. If the base station determines that the UE capabilities include a capability indicating support for reporting UL data traffic assistance information, the flow proceeds to block 816, where, the base station transmits a configuration to the UE, to configure the UE to transmit UL data traffic assistance information (e.g., event 304 or 316). Otherwise, if the base station determines at block 840 that the UE capabilities do not include a capability indicating support for reporting UL data traffic assistance information, the flow proceeds to block 819, the base station refrains transmitting the configuration to the UE.

[0109] Fig. 8B is a flow diagram of an example method 800B similar to the method 800A, except that the method 800B includes block 841 instead of block 840. At block 841, the base station determines whether (i) the base station receives PDU Set-related information for the UE and (ii) the UE capabilities include a capability indicating support for reporting UL data traffic assistance information. If the base station determines that the base station receives PDU Set- related information for the UE and the UE capabilities include a capability indicating support for reporting UL data traffic assistance information at block 841, the flow proceeds to 816. Otherwise, if the base station determines that the base station does not receive PDU Set-related information for the UE and / or the UE capabilities do not include a capability indicating support for reporting UL data traffic assistance information at block 841, the flow proceeds to block 819.

[0110] Fig. 9 illustrates an example method 900, implemented by a base station (e.g., the base station 104, CU 172 or CU-CP 172A), for reducing overhead in data communication with a UE (e.g., the UE 102).

[0111] The method 900 begins at block 904, where the base station communicates with a UE (e.g., events 302, 304, 308, 310). At block 941, the base station determines whether the base station receives PDU Set-related information for the UE. If the base station determines that the base station receives PDU Set-related information for the UE, the flow proceeds to block 916. In some implementations, the base station receives the PDU Set-related information from a CN(e.g., event 312) or another base station. In some implementations, the PDU Set-related information includes PDU Set QoS parameters. At block 916, the base station transmits a configuration to the UE, configuring the UE to perform buffer status reporting based on a first buffer size table (e.g., event 316). Otherwise, if the base station determines at block 941 that the base station does not receive PDU Set-related information for the UE, the flow proceeds to block 919, where, the base station refrains from transmitting the configuration to the UE.

[0112] Fig. 10A illustrates an example method 1000A, implemented by a base station (e.g., the base station 104 or DU 174), for reducing overhead in data communication for a UE (e.g., the UE 102).

[0113] The method 1000A begins at block 1016A, where the base station transmits a configuration to the UE, configuring a first buffer size table and including a first ID identifying the first buffer size table (e.g., event 304, 316, 324). At block 1021, the base station transmits, to the UE, a buffer size table activation command, including the first ID, to activate the first buffer size table. At block 1022, the base station receives a buffer status report including an index value from the UE (e.g., events 322, 334). At block 1050, the base station derives a buffer size value from the index value and the first buffer size table.

[0114] In some implementations, the base station transmits a release configuration including the first ID to release the first buffer size table (i.e., configuring the UE not to use the first buffer size table). In response to the release configuration, the UE releases the first buffer size table or stops using the first buffer size table.

[0115] In some implementations, the base station configures the first ID in an implicit manner in the configuration. In other implementations, the base station configures the first ID in an explicit manner by including the first ID in the configuration. In some implementations, the index value is a buffer size index value.

[0116] Fig. 10B illustrates an example method 1000B, implemented by a base station (e.g., the base station 104 or DU 174), for reducing overhead in data communication for a UE (e.g., the UE 102).

[0117] The method 1000B begins at block 1016B, where the base station transmits a configuration to the UE, configuring a first buffer size table and including a first ID identifying the first buffer size table (e.g., event 304, 316, or 324). At block 1022, the base station receives a buffer status report, including the first ID and an index value, from the UE (e.g., events 322, 324). At block 1049, the base station identifies the first buffer size table in accordance with the first ID. At block 1050, the base station derives a buffer size value from the index value and the first buffer size table.

[0118] Fig. 10C illustrates a method 1000C, implemented by a base station (e.g., the base station 104), for configuring and activating a fast serving cell configuration with a RAN (e.g., the DU 174, CU 172, base station 104 or 106, or RAN 105).

[0119] The method 1000C begins at block 1016C, where the base station transmits a configuration to the UE, configuring a first buffer size table (e.g., event 304, 316, or 324). At block 1024, the base station receives a buffer status report, including a first logical channel ID and an index value (e.g., buffer size index), from the UE (e.g., events 324, 334). At block 1029, the base station identifies the first buffer size table in accordance with the first logical channel ID. At block 1008, the base station derives a buffer size value from the index value and the first buffer size table.

[0120] Fig. 11 A illustrates an example method 1100A, implemented by a UE (e g., the UE 102), for reducing overhead in communication with a RAN (e.g., the RAN 105).

[0121] The method 1100A begins at block 1116, where the UE receives a configuration from a RAN, configuring a first buffer size table and including a first ID identifying the first buffer size table (e.g., event 304, 316, or 324). At block 1135, the UE receives, from the RAN, a buffer size table activation command including the first ID to activate the first buffer size table. At block 1137, the UE obtains an index value indexing a buffer size value, indicating a volume of data available for transmission, in accordance with the first buffer size table. At block 1124A, the UE transmits a buffer status report including the index value to the RAN (e.g., events 324, 334).

[0122] In some implementations, the base station configures the first ID in an implicit manner in the configuration. In other implementations, the base station configures the first ID in an explicit manner by including the first ID in the configuration. In some implementations, the index value is a buffer size index value.

[0123] Fig. 1 IB is a flow diagram of an example method 1100B similar to the method 1100A, except that method 1100B includes block 1124B instead of blocks 1135 and 11081124 A At block 1124B, the UE transmits a buffer status report, including the first ID and the index value, to the RAN (e.g., events 324, 334).

[0124] Fig. 12 illustrates an example method 1200, which can be implemented in a DU, such as the DU 174. At block 1226, the DU obtains UL data traffic assistance information for a UE (e.g., events 326, 327, blocks 426A, 426B, 627A, 627B). At block 1228, the DU generates a configuration based on the UL data traffic assistance information (event 328, blocks 431 A, 43 IB, 629A, 629B). At block 1230, the DU transmits the configuration to the UE, via a CU (event 328, 330, blocks 428 A, 428B, 630A, 630B).

[0125]

[0126] The following list of examples reflects a variety of the embodiments explicitly contemplated by the present disclosure.

[0127] Example 1. A method implemented in a distributed unit (DU) of a distributed base station that also includes a central unit (CU), the method comprising: obtaining an uplink (UL) data traffic assistance information for a UE; generating a configuration based on the UL data traffic assistance information; and transmitting the configuration to the UE, via the CU.

[0128] Example 2. The method of example 1, further comprising: communicating with the UE according to the configuration.

[0129] Example 3. The method of example 1, wherein the obtaining of the UL data traffic assistance information includes: receiving the UL data traffic assistance information directly from the UE.

[0130] Example 4. The method of example 3, wherein: the UL data traffic assistance information is included in an uplink (UL) medium access control (MAC) control element (CE).

[0131] Example 5. The method of example 1, wherein the obtaining of the UL data traffic assistance information includes: receiving the UL data traffic assistance information from the CU.

[0132] Example 6. The method of example 5, wherein the UL data traffic assistance information is included in a Radio Resource Control (RRC) information element (IE).

[0133] Example 7. The method of example 1, wherein the obtaining of the UL data traffic assistance information is based on monitoring UL protocol data units (PDUs), transmitted from the UE to a core network (CN) via the distributed base station.

[0134] Example 8. The method of any of the preceding examples, wherein the UL data traffic assistance information includes an indication of a buffer size table preferred by the UE.

[0135] Example 9. The method of claim 8, wherein the indication of the buffer size table includes an identifier (ID) of the buffer size table to identify the buffer size table from among a predefined set of buffer size tables.

[0136] Example 10. The method of any of claims 1-7, wherein the UL data traffic assistance information includes one or more parameters for generating, using a predefined formula, a buffer size table preferred by the UE.

[0137] Example 11. The method of any of the preceding examples, wherein the UL data traffic assistance information includes UL jitter information.

[0138] Example 12. The method of claim 11, wherein the UL jitter information includes a jitter value indicating a time duration relative to a reference time point.

[0139] Example 13. The method of example 12, wherein the UL jitter information further includes reference time point information for the deriving the reference time point.

[0140] Example 14. The method of example 12 or 13, wherein: the jitter value is a filtered jitter value; and the UL jitter information further includes: a maximum jitter value, and a minimum jitter value.

[0141] Example 16. The method of example 10, wherein the generating of the configuration includes: generating a buffer size table configuration based on the buffer size table preferred by the UE.

[0142] Example 17. The method of any of the preceding examples, wherein the configuration includes a CellGroupConfig IE.

[0143] Example 18. The method of example 1, 16, or 17 wherein the transmitting of the configuration to the UE via the CU includes transmitting the configuration in a UE Context Modification Requirement message.

[0144] Example 19. The method of any of the preceding examples , further comprising: receiving, prior to the obtaining of the UL data traffic assistance information, a first buffer state report (BSR); and receiving, subsequently to the transmitting of the configuration to the UE, a second BSR based on the configuration.

[0145] Example 20. A method implemented in a central unit (CU) of a distributed base station that also includes at least one distributed unit (DU), the method comprising: obtaining an uplink (UL) data traffic assistance information for a UE; obtaining a configuration based on the UL data traffic assistance information; and transmitting the configuration to the UE.

[0146] Example 21. The method of example 20, wherein: the DU is a first DU; and the transmitting the configuration to the UE includes transmitting the configuration via a second DU.

[0147] Example 22. The method of example 20, wherein the obtaining of the UL data traffic assistance information includes: receiving the UL data traffic assistance information from the DU, in a UE Context Modification Required message.

[0148] Example 23. The method of example 20, wherein the obtaining of the UL data traffic assistance information includes: receiving the UL data traffic assistance information from the UE via the DU, in an RRC IE.

[0149] Example 24. The method of example 20, wherein the obtaining of the UL data traffic assistance information includes: generating the UL data traffic assistance information at a user plane entity of the CU (CU-UP); and transmitting, from the CU-UP, the UL data traffic assistance information to a control plane entity of the CU (CU-CP).

[0150] Example 25. The method of example 20 or 24, further comprising: receiving an indication of capabilities of the UE; and in response to determining that the UE supports UL data traffic assistance information reporting, configuring the UE to report the UL data traffic assistance information.

[0151] Example 26. The method of example 20 or 24, further comprising: in response to determining that the distributed base station received PDU Set related information for the UE, configuring the UE to report the UL data traffic assistance information.

[0152] Example 27. The method of example 26, further comprising: receiving an indication of capabilities of the UE; wherein: the configuring of the UE to report the UL data traffic assistance information is further in response to determining that the UE supports UL data traffic assistance information reporting.

[0153] Example 28. The method of example 26, further comprising: in response to the determining that the distributed base station received the PDU Set related information for the UE, configuring the UE to perform buffer status reporting.

[0154] Example 29. A radio access network (RAN) node comprising processing hardware and configured to implement a method of any of the preceding examples.

[0155] The following additional considerations apply to the foregoing discussion.

[0156] Generally speaking, description for one of the above figures can apply to another of the above figures. Examples, implementations and methods described above can be combined, if there is no conflict. An event or block described above can be optional or omitted. For example, an event or block with dashed lines in the figures can be optional. In some implementations, “message” is used and can be replaced by “information element (IE)”, and vice versa. In some implementations, “IE” is used and can be replaced by “field”, and vice versa. In some implementations, “configuration” can be replaced by “configurations” or “configuration parameters”, and vice versa. In some implementations, “at least one” means “one or more”. In some implementations, “PDU Set-based QoS handling” can be replaced by “PDU Set handling”.

[0157] A user device in which the techniques of this disclosure can be implemented (e.g., the UE 102) can be any suitable device capable of wireless communications such as a smartphone, a tablet computer, a laptop computer, a mobile gaming console, a point-of-sale (POS) terminal, ahealth monitoring device, a drone, a camera, a media-streaming dongle or another personal media device, a wearable device such as a smartwatch, a wireless hotspot, a femtocell, or a broadband router. Further, the user device in some cases is embedded in an electronic system such as the head unit of a vehicle or an advanced driver assistance system (ADAS). Still further, the user device can operate as an internet-of-things (loT) device or a mobile-internet device (MID). Depending on the type, the user device can include one or more general-purpose processors, a computer-readable memory, a user interface, one or more network interfaces, one or more sensors, etc.

[0158] Certain embodiments are described in this disclosure as including logic or a number of components or modules. Modules can be software modules (e.g., code stored on non-transitory machine-readable medium) or hardware modules. A hardware module is a tangible unit capable of performing certain operations and may be configured or arranged in a certain manner. A hardware module can comprise dedicated circuitry or logic that is permanently configured (e.g., as a special-purpose processor, such as a field programmable gate array (FPGA) or an application-specific integrated circuit (ASIC)) to perform certain operations. A hardware module may also comprise programmable logic or circuitry (e.g., as encompassed within a general-purpose processor or other programmable processor) that is temporarily configured by software to perform certain operations. The decision to implement a hardware module in dedicated and permanently configured circuitry, or in temporarily configured circuitry (e.g., configured by software) may be driven by cost and time considerations.

[0159] As used herein, the terms “comprises,” “comprising,” “includes,” “including,” “has,” “having” or any other variation thereof, are intended to cover a non-exclusive inclusion. For example, a process, method, article, or apparatus that comprises a list of elements is not necessarily limited to only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Further, unless expressly stated to the contrary, “or” refers to an inclusive or and not to an exclusive or. For example, a condition A or B is satisfied by any one of the following: A is true (or present) and B is false (or not present), A is false (or not present) and B is true (or present), and both A and B are true (or present).

[0160] When implemented in software, the techniques can be provided as part of the operating system, a library used by multiple applications, a particular software application, etc. Thesoftware can be executed by one or more general-purpose processors or one or more specialpurpose processors.

Claims

What is claimed is:

1. A method implemented in a distributed unit (DU) of a distributed base station that also includes a central unit (CU), the method comprising: obtaining an uplink (UL) data traffic assistance information for a UE; generating a configuration based on the UL data traffic assistance information; and transmitting the configuration to the UE, via the CU.

2. The method of claim 1, wherein the obtaining of the UL data traffic assistance information includes: receiving the UL data traffic assistance information directly from the UE.

3. The method of claim 1, wherein the obtaining of the UL data traffic assistance information includes: receiving the UL data traffic assistance information from the CU.

4. The method of claim 1, wherein: the obtaining of the UL data traffic assistance information is based on monitoring UL protocol data units (PDUs), transmitted from the UE to a core network (CN) via the distributed base station.

5. The method of any of the preceding claims, wherein the UL data traffic assistance information includes an indication of a buffer size table preferred by the UE.

6. The method of any of claims 1-4, wherein the UL data traffic assistance information includes one or more parameters for generating, using a predefined formula, a buffer size table preferred by the UE.

7. The method of any of the preceding claims, wherein the UL data traffic assistance information includes UL jitter information.

8. The method of claim 5, wherein the generating of the configuration includes:generating a buffer size table configuration based on the buffer size table preferred by theUE.

9. The method of any of the preceding claims, further comprising: receiving, prior to the obtaining of the UL data traffic assistance information, a first buffer state report (BSR); and receiving, subsequently to the transmitting of the configuration to the UE, a second BSR based on the configuration .

10. A method implemented in a central unit (CU) of a distributed base station that also includes at least one distributed unit (DU), the method comprising: obtaining an uplink (UL) data traffic assistance information for a UE; obtaining a configuration based on the UL data traffic assistance information; and transmitting the configuration to the UE.

11. The method of claim 10, wherein the obtaining of the UL data traffic assistance information includes: generating the UL data traffic assistance information at a user plane entity of the CU (CU-UP); and transmitting, from the CU-UP, the UL data traffic assistance information to a control plane entity of the CU (CU-CP).

12. The method of claim 10 or 11, further comprising: receiving an indication of capabilities of the UE; and in response to determining that the UE supports UL data traffic assistance information reporting, configuring the UE to report the UL data traffic assistance information.

13. The method of 10 or 11, further comprising: in response to determining that the distributed base station received PDU Set related information for the UE, configuring the UE to report the UL data traffic assistance information.

14. The method of claim 13, further comprising: in response to the determining that the distributed base station received the PDU Set related information for the UE, configuring the UE to perform buffer status reporting.

15. A radio access network (RAN) node comprising processing hardware and configured to implement a method of any of the preceding claims.

Images