WO2024173672A1 - Buffer status reporting enhancement for extended reality and cloud gaming services - Google Patents

Abstract

This disclosure provides systems, devices, apparatus, and methods, including computer programs encoded on storage media, for buffer status reporting enhancement for extended reality and cloud gaming services. A UE communicates (302), with a network entity (104), using a first configuration. The UE transmits (325), to the network entity (104), a DSR indicating a delay associated with an amount of data buffered at the UE using a second configuration. The DSR indicates a remaining time before an expiry of a PDCP discard timer associated to a data packet.

Description

BUFFER STATUS REPORTING ENHANCEMENT FOR EXTENDED REALITY AND CLOUD GAMING SERVICES

CROSS REFERENCE TO RELATED APPLICATIONS

[0001] This application claims the benefit of and priority to U.S. Provisional Application Serial No. 63/485,253, entitled “BUFFER STATUS REPORTING ENHANCEMENT FOR HIGH DATA RATES” and filed on February 15, 2023, and U.S. Provisional Application Senal No. 63/497,198, entitled “BUFFER STATUS REPORTING ENHANCEMENT FOR HIGH DATA RATES” and filed on April 19, 2023. both of which are expressly incorporated by reference herein in their entirety.

FIELD OF THE DISCLOSURE

[0002] This disclosure relates to wireless communications and, more particularly, to managing communication using enhanced Buffer Status Reporting (BSR) determination and reporting mechanisms for real time media services, e.g., extended Reality services (XR) and cloud gamming (CG) services, requiring high data rate and low latency. The disclosure proposes enhancement to the legacy BSR mechanisms to better support UL XR traffic and better optimize resource usage.

BACKGROUND

[0003] The background description provided herein is 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] XR stands for extended Reality, which is an umbrella term that covers Augmented Reality (AR), Virtual Reality (VR) and Mixed Reality (MR). In virtual reality, the user is fully immersed in a virtual environment that is totally substituting the real environment by wearing a head-mounted device. Augmented reality augments the perception of the real environment with some virtual elements, so some virtual elements are overlaid on the perception of the real environment. The game Pokemon Go is one famous example of an AR game. Mixed reality is an extension of AR where the real and virtual elements can interact in real time. Cloud gaming runs video games on remote servers without the need for a gaming console or a high spec CPU and GPU to play these games. Cloud gaming streams a game like streaming a video, and the game will respond to the gamer commands and controls in real time.

[0005] Wireless AR/VR and wireless Cloud gaming offer better freedom of movement as wireless eliminates the geographical or behavioural restrictions and allows VR and AR users to move freely. Wireless AR/VR also enables new applications like remote education in immersive environment for remote areas not connected with good DSU or Fiber. Multiple XR scenarios and applications are deployed. Offline sharing of 3D objects consists of sharing 3D models or objects and 3D mixed reality scenes amongst users, e.g., using a phone equipped with a depth camera to capture an image in 3D and then share it with a contact. XR conferencing is another use case and consist of people interacting in virtual environment and sharing a 3D experience with each other and even presenting some content and discuss it with other people in the same conference.

[0006] The XR traffic is a quasi-periodic traffic with the period equal to the inverse of the XR frame rate. Hence, if the frame rate is 60 frames per second (fps), the periodicity is 16.67 milliseconds (ms). The XR traffic suffers from jitter due to the delay variations at the codec to encode the video frames. The jitter was statistically modelled in 3GPP as truncated Gaussian distribution with 2ms standard deviation and +/-4 ms range. The XR packet sizes are also very large and variable due to the variability in the video frame content and were also statistically modelled in 3GPP as truncated Gaussian distribution. FIG. 1 shows an example of the XR traffic shape.

[0007] When UL data arrives at the UE (user equipment) L2 buffer, the UE sends a buffer status report (BSR) to the network to request for UL resources to schedule the UL data. The BSR helps the netw ork to provision and allocate the appropriate amount of UL resources to schedule the UL data. The UE transmits the BSR to the base station per LCG (Logical Channel Group) and the base station can configure the UE with up to eight LCGs. In general, an LCG is composed of logical channels of similar priority and the base station allocates each logical channel to an LCG using the RRC parameter logicalChamelGroup (TS 38.321) [0008] TS 38.321 specifies three types of BSR, the periodic BSR, the regular BSR and the padding BSR. The periodic BSR is sent periodically with an RRC configured periodicity. The BSR is transmitted even' time the timer periodicBSR-Timer expires and the timer is reset after each BSR transmission. Regular BSR is sent with the arrival of a new data belonging to a logical channel with higher priority' than the priority of any logical channel containing existing UL data which belong to any LCG. The regular BSR is also triggered when new UL data arrives and none of the logical channels which belong to an LCG contains any available UL data. The regular BSR is also triggered when the timer retxBSR-Timer has expired. This timer has been specified to avoid a deadlock situation where the base station has failed to receive the BSR transmitted by the UE and the UE thinks the base station has received the BSR and the UE is waiting for the UL scheduling to take place. The timer retxBSR-Timer resolves this situation by triggering a retransmission of the BSR. The third type is the padding BSR. The UE transmits the padding BSR when the UL resources are allocated and number of padding bits is equal to or larger than the size of the BSR MAC CE plus its sub-header. Hence, the UE transmits the BSR with the UL packet to take advantage of the unused resources and reduce the padding.

[0009] TS 38.321 specifies four formats of BSRs, long BSR. long truncated BSR, short BSR and short truncated BSR. The UE uses long and short BSRs when the periodic or regular types BSR triggering are in use. Long BSR accommodates multiple LCGs. The UE uses long BSR when multiple LCGs (more than 1) have UL data to be transmitted. The UE uses short BSR to send buffer information about the buffered data for a single LCG. If the UE triggers the BSR using the padding BSR type, then the selected BSR format depends on the available padding resources. The padding resources should be enough to accommodate at least a short BSR. If the padding resources are larger than a long BSR, then the UE uses long BSR, but if only a single LCG has data to be transmitted then the UE uses short BSR. If multiple LCGs have data to be transmitted, but the size of the padding resources is enough to only accommodate a short BSR, then a short truncated BSR is used to indicate the buffer status for the LCG with the highest priority. Otherwise, the UE generates a long truncated BSR for the LCG with the highest priority channels.

[0010] The structure and the size of short BSR and short truncated BSR is the same. The payload size of the MAC CE element is 1 byte, 5 bits (LSB: least significant bits) for the buffer status and 3 bits for the LCG ID. The UE transmits also an extra 1-byte sub-header to identify the MAC CE (for short BSR or short truncated BSR). The 5 bits are pointing to an index in a 32 indices look-table (Table 6. 1.3. 1-1: Buffer size levels (in bytes) for 5-bit Buffer Size field in TS 38.321). Each index represents a value in bytes.

[0011] The long BSR has a specific field for each LCG which has data to be transmitted. The long truncated BSR has fields for a subset of the LCGs which have data to be transmitted. And the subset is selected based on the priority of the logical channels belonging to each LCG. The UE transmits also an extra sub-header to identify the MAC CE (for long BSR or long truncated BSR). The long BSR and long truncated BSR use 8 bits to send the buffer size. This means a larger look-up table with 256 indices (Table 6.1.3. 1-2: Buffer size levels (in bytes) for 8-bit Buffer Size field)

[0012] The BSR look-up tables have coarse granularity at the top of the tables, which means the step size is small for the small indices and the steps get wider and larger for large indices. But since most of the XR traffic has large packet sizes, this means the resource allocation is not optimum as the BSR reporting is quantized with larger quantization errors for most XR traffic. Not addressing the very coarse BSR granularity at the top of the tables means overallocation of resources. The UE then needs to use padding bits to utilize all the allocated resources, which leads to resource inefficiency, hence lower system capacity but also increased UL interference. Hence to address this issue, 3GPP needs to define new BSR tables with finer granularity for larger BS values.

[0013] The base station 104 can configure the UE 102 with a CG configuration for the periodic XR traffic. However, the XR traffic has variable packet sizes. Configuring the CG resources for the largest XR packet size is very resource inefficient and can compromise the system capacity. The base station 104 can configure the CG configuration with smaller CG resources (e.g.. the average XR packet size or the smallest XR packet size). In this case, the base station needs to dynamically schedule any left-over if it doesn't fit in the CG allocated resources and cannot wait for the next CG cycle as this can compromise the traffic latency requirement. The UE 102 needs to quickly report a BSR to indicate the buffer status and assist the base station 104 in determining the extra resources required to schedule the leftover data. In that regard, new BSR mechanisms may be needed for XR traffic.

[0014] Also, the current BSR triggers are not enough for the XR traffic which is quasi- periodic with jitter. New BSR triggers for XR could also be needed. BRIEF SUMMARY

[0015] XR is a very demanding service. It has high data rates requirements and very' low latency and high reliability requirements. These stringent requirements although needed to guarantee good user QoE, they however limit the system capacity which makes the service not very attractive for deployment. BSR enhancements are needed to allow for better resource allocation, hence better spectral efficiency and system capacity. BSR enhancements can include defining new BSR tables but also enhancement to the existing tables and enhancements to the existing formats, types and triggers and delay awareness about the buffered data. Enhancements, to be efficient, need to take into consideration the specificities of the XR traffic (periodicities, packets sizes, jitter, . . . ) as shown in FIG. 1.

[0016] The following enhancements have been captured in TR 38.835, section 5.3.2 for BSR enhancement:

One or more additional BS table(s) to reduce the quantization errors in BSR reporting (e.g., for high bit rates);

Delay knowledge of buffered data, consisting of e.g.. remaining time, and distinguishing how much data is buffered for which delay. It is to be determined whether the delay information is reported as part of BSR or as a new' MAC CE. Also, how the delay information can be up to date considering e.g., scheduling and transmission delays needs to be investigated further.

- Additional BSR triggering conditions to allow timely availability of buffer status information can be investigated further.

[0017] Also, the following has been captured in TR 38.835 conclusion:

The following enhancements for XR services are recommended for Capacity Enhancements: o BSR enhancements including at least new BS Table(s);

[0018] In RAN2#119bis-e, the following agreement has been made during the Study Item phase:

Introduce new BS table(s) to reduce the quantisation errors (e g., for high bit rates). FFS how new' BSR tables are created and how' they impact BSR formats (can be discussed in WI phase). RAN2 considers a delay information is useful for XR. FFS if dynamic reporting from UE to network (e.g.. via BSR) is needed, or whether PSDB is sufficient. If we have delay information, it needs to distinguish how much data is buffered for which delay value. Stage-3 details (e.g., what’ s contained, how the triggering is done) can be discussed in the WI phase.

[0019] It is clear from the Rel-18 XR Study Item that enhancements to BSR are needed to reduce the quantization error, to report timing information and define any new triggers from XR traffic.

[0020] This disclosure belongs to the technical field of wireless communication and discloses enhancement to the BSR (Buffer Status Reporting) determination and reporting mechanism to support XR traffic with its stringent latency and reliability requirements. The XR traffic has large packets with variable sizes arriving quasi-periodically. The current BSR tables have exponential steps which are not suitable for the XR traffic characterized by large packet sizes. Also, new triggers could be defined for BSR reporting to adjust and align with the arrival of the XR traffic and to adapt to the XR traffic characteristics like the introduced concept of PDU-Sets and Data-Burst.

[0021] In some aspects, a UE and a network entity communicate, using a first configuration. The UE transmits, to the network entity (and the network entity receives, from the UE), a delay status report (DSR) indicating a delay associated with an amount of data buffered at the UE using a second configuration. The DSR indicates a remaining time before an expiry of a packet data convergence protocol (PDCP) discard timer associated with a data packet.

BRIEF DESCRIPTION OF THE DRAWINGS

[0022] FIG. 0 shows an example of the quasi-periodic XR traffic with the variable packet size and with the arrival time impacted by the jitter.

[0023] FIG. 1 A is a block diagram of an example system in which a distributed base station and/or a user equipment (UE) can implement the techniques of this disclosure for managing a radio connection of the UE. [0024] FIG. IB is a block diagram of an example base station including a central unit (CU) and a distributed unit (DU) of a distributed base station that can operate in the system of FIG. 1A.

[0025] FIGs. 2A-2B are block diagrams of examples of protocol stack according to which the UE of Figs. 1 A-B can communicate with base stations.

[0026] FIG. 3A shows an example of a BSR reporting mechanism.

[0027] FIG. 3B illustrates an example of a BSR reporting mechanism that includes a network-initiated change of the BSR table.

[0028] FIG. 3C illustrates an example of a BSR reporting mechanism that includes an activation of delay status reporting.

[0029] FIG. 4 shows an example of a new BSR table, where the base station can configure the UE with a specific range from the table to use for the BSR reporting

[0030] FIG. 5 shows a flow diagram where the UE modem can verify if XR traffic is transmitted in an uplink (UL) and enable new BSR tables for the BSR reporting.

[0031] FIG. 6A and FIG. 6B show examples of the indication of the BSR table in the BSR MAC CE sub-header for both fixed size MAC CE and variable size MAC CE.

[0032] FIG. 7 shows a flow diagram for the case where the base station configures the UE with a BSR table per LCG subset.

[0033] FIG. 8 shows a flow diagram for the selection of a BSR table based on a Buffer size threshold B_T.

[0034] FIG. 9 shows a flow diagram for the selection between a BSR table and a formula for the BSR report calculation based on a Buffer size threshold B_T.

[0035] FIG. 10 shows a flow diagram for the selection between an 8-bit BSR table and a 5- bit BSR table when data is available for UL transmission for one LCG and for multiple LCGs.

[0036] FIG. 11 shows new fields in the BSR MAC CE to indicate the priority of the data in each BSR report for each LCG.

[0037] FIG. 12A and FIG. 12B shows new fields in the MAC CE sub-header to indicate the priority of the data in the BSR report. [0038] FIG. 13 shows the triggering of a B SR report follow ing the arrival in the UE buffer of a high priority PDU-Set belonging to a logical channel which has already data in the buffer with lower priority.

[0039] FIG. 14 shows an example where the UE could be buffering two Data-Bursts or PDU-Sets simultaneously with possibly different priority/importance.

[0040] FIG. 15 shows an example of a periodic BSR-Timer to be set equal to the video traffic periodicities.

[0041] FIG. 16 shows an example of a quasi-periodic XR traffic with jitter and where the resetting of the periodicBSR-Timer is restricted to specific intervals (e.g., jitter range).

[0042] FIG. 17 shows an example where a PDU-Set discard by the UE triggers a BSR report.

DETAILED DESCRIPTION

[0043] FIG. 1A depicts an example wireless communication system 100 in which communication devices can implement these techniques. The wireless communication system 100 includes a UE 102, a base station (BS) 104, a base station 106 and a core network (CN) 110. The UE 102 initially connects to the base station 104. In some scenarios, the base station 104 can perform an SN addition to configure the UE 102 to operate in dual connectivity (DC) with the base station 104 and the base station 106. The base stations 104 and 106 operate as an MN and an SN for the UE 102, respectively.

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

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

[0046] Tn the scenarios where the UE 102 hands over from the base station 104 to the base station 106, the base stations 104 and 106 operate as the source base station (S-BS) and a target base station (T-BS), respectively. The UE 102 can operate in DC with the base station 104 and an additional base station (not shown in FIG. 1A) for example prior to the handover. The UE 102 can continue to operate in DC with the base station 106 and the additional base station or operate in single connectivity (SC) with the base station 106, after completing the handover. The base stations 104 and 106 in this case operate as a source MN (S-MN) and a target MN (T-MN), respectively.

[0047] A core network (CN) 110 can be an evolved packet core (EPC) 111 or a fifthgeneration core (5GC) 160, both of which are depicted in FIG. 1 A. The base station 104 can be an eNB supporting an S 1 interface for communicating with the EPC 111, an ng-eNB supporting an NG interface for communicating with the 5GC 160, or a gNB that supports an NR radio interface as well as an NG interface for communicating with the 5GC 160. To directly exchange messages with each other during the scenarios discussed below, the base stations 104 and 106 can support an X2 or Xn interface. Among other components, the EPC 111 can include a Serving Gateway (SGW) 112, a Mobility Management Entity (MME) 114, and a Packet DataNetwork Gateway (PGW) 116. The SGW 112 is generally 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 one or more external packet data networks, e.g., an Internet network and/or an Internet Protocol (IP) Multimedia Subsystem (IMS) network. The 5GC 160 includes a User Plane Function (UPF) 162 and an Access and Mobility Management (AMF) 164, and/or Session Management Function (SMF) 166. The UPF 162 is generally configured to transfer user-plane packets related to audio calls, video calls, Internet traffic, etc., the AMF 164 is configured to manage authentication, registration, paging, and other related functions, and the SMF 166 is configured to manage Protocol Data Unit (PDU) sessions. [0048] As illustrated in FIG. 1A, the base station 104 supports cell 124, and the base station 106 supports cell 126. The cells 124 and 126 can partially overlap, so that the UE 102 can communicate in DC with the base station 104 and the base station 106, where one of the base stations 104 and 106 is an MN and the other is an SN. The base station 104 and base station 106 can support additional cell(s) (not shown in FIG. 1 A). The base station 104 can operate the cells 124 and/or additional cell(s) via one or more transmit and receive points (TRPs). More particularly, when the UE 102 is in DC with the base station 104 and the base station 106, one of the base stations 104 and 106 operates as an MeNB, an Mng-eNB or an MgNB, and the other operates as an SgNB or an Sng-eNB.

[0049] 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 or 5G NR-6G DC.

[0050] 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, managing UL 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 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 handover procedures, and/or to support the necessary operations when the base station 104 operates as an MN relative to an SN or as an SN relative to an MN. 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.

[0051] 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 memorystoring 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 advance for the one or more user devices, 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.

[0052] In operation, the UE 102 in DC can use a radio bearer (e.g.. a DRB or an SRB) that at different times terminates at the MN 104 or the SN 106. The UE 102 can apply one or more security keys when communicating on the radio bearer, in the uplink (UL) (from the UE 102 to a base station) and/or downlink (from a base station to the UE 102) direction.

[0053] FIG. IB depicts an example distributed implementation of a base station such as the base station 104 or 106. The base station in this implementation can include a centralized unit (CU) 172 and one or more distributed units (DUs) 174. The CU 172 is equipped with processing hardware 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. In one example, the CU 172 is equipped with the processing hardware 130. In another example, the CU 172 is equipped with the processing hardware 140. The processing hardware 140 in an example implementation includes an SN RRC controller 142 configured to manage or control one or more RRC configurations and/or RRC procedures when the base station 106 operates as an SN. The DU 174 is also equipped with processing hardware 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. In some examples, the processing hardware in an example implementation includes a medium access control (MAC) controller configured to manage or control one or more MAC operations or procedures (e.g., a random-access procedure) and a radio link control (RLC) controller configured to manage or control one or more RLC operations or procedures when the base station 106 operates as an MN or an SN. The process hardware may include further a physical layer controller configured to manage or control one or more physical layer operations or procedures.

[0054] Next, FIG. 2A and 2B illustrate in simplified manners a radio protocol stack according to which the UE 102 can communicate with an eNB/ng-eNB or a gNB. Each of the base stations 104 or 106 can be the eNB/ng-eNB or the gNB.

[0055] The physical layer (PHY) 202A of EUTRA provides transport channels to the EUTRA Medium Access Control (MAC) sublayer 204A. which in turn provides logical channels to the EUTRA Radio Link Control (RLC) sublayer 206A, and the EUTRA RLC sublayer in turn provides RLC channels to the EUTRA PDCP sublayer 208 and, in some cases, NR PDCP sublayer 210. Similarly, the PHY 202B of NR provides transport channels to the NR MAC sublayer 204B, which in turn provides logical channels to the NR RLC sublayer 206B, and the NR RLC sublayer 206B in turn provides RLC channels to the NR PDCP sublayer 210. The UE 102 in some implementations supports both the EUTRA and the NR stack, to support handover between EUTRA and NR base stations and/or 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.

[0056] The EUTRA PDCP sublayer 208 and the NR PDCP sublayer 210 receive packets (e g., from the 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."

[0057] On a control plane, the EUTRA PDCP sublayer 208 and the NR PDCP sublayer 210 provide SRBs to exchange Radio Resource Control (RRC) messages, for example. On a user plane, the EUTRA PDCP sublayer 208 and the NR PDCP sublayer 210 provide DRBs to support data exchange.

[0058] When the UE 102 operates in EUTRA/NR DC (EN-DC), with the base station 104 operating as a MeNB and the base station 106 operating as a SgNB, the network can provide the UE 102 with an MN-terminated bearer that uses EUTRA PDCP 208 or MN-terminated bearer that uses NR PDCP 210. The network in various scenarios also can provide the UE 102 with an SN-terminated bearer, which use only NR PDCP 210. The MN-terminated bearer can be an MCG bearer or a split bearer. The SN-terminated bearer can be a SCG bearer or a split bearer. The MN-terminated bearer can be an SRB (e g., SRB1 or SRB2) or a DRB. The SN-terminated bearer can an SRB (e.g., SRB) or a DRB.

[0059] Referring first to FIG. 3 A, in a scenario 300A, the UE 102 initially communicates 302 with the base station 104 using a first configuration. In some implementations, the UE 102 in carrier aggregation (CA) communicates with the base station 104 on the cell 124 and other cell(s) using the first configuration. In other implementations, the UE 102 communicates with the base station 104 on the cell 124 only. In some implementations, the UE 102 communicates with the base station 104 on the cell 124 and/or other cell(s) via one or multiple TRPs. In some implementations, the cell 124 can be a PCell or a PSCell. In such cases, the other cell(s) include SCell(s) and/or additional cell(s) associated with the PCell or a SCell. In other implementations, the cell 124 can be a SCell, and one of the other cell(s) is a PCell. In such cases, the rest includes SCell(s) and/or additional cell(s) associated with the PCell or a SCell.

[0060] In the event 302. the UE 102 can transmit UL PDUs and/or UL control signals to the base station 104 on the cell 124 and/or other cell(s) via one or multiple TRPs. In some implementations, the UE 102 communicates UL PDUs and/or DL PDUs w ith the base station 104 via radio bearers which can include SRBs and/or DRB(s). The base station 104 can configure the radio bearers to the UE 102. In some implementations. UL control signals include UL control information, channel state information, hybrid automatic repeat request (HARQ) acknowledgements (ACKs), HARQ negative ACKs, scheduling request(s) and/or sounding reference signal(s). Similarly, the UE 102 can receive DL PDUs and/or DL control signals from the base station 104 on the cell 124 and/or other cell(s) via one or multiple TRPs. In some implementations, the DL control signals include downlink control information (DCIs) and reference signals (e.g., synchronization signal block, channel state information reference signal(s) (CSI-RS(s)). and/or tracking reference signal(s)). The base station 104 can transmit the DCIs on physical downlink control channel(s) (PDCCH(s)) monitored by the UE 102, on the cell 124 and/or other cell(s) via one or multiple TRPs.

[0061] In some implementations, the first configuration includes physical layer configuration parameters, MAC configuration parameters, RLC configuration parameters, PDCP configuration parameters, measurement configuration parameters, and/or radio bearer configuration parameters. In some implementations, the first configuration includes a CellGroupConflg IE defined in 3GPP specification 38.331 or configuration parameters in the CellGroupConfig IE. In some implementations, the first configuration includes a CSI- MeasConfig IE, aMecisConfig IE and/or a RadioBearerConfig IE defined in 3GPP specification 38.331 or includes configuration parameters in the CSI-MeasConfig IE. MeasConftg IE and/or RadioBearerConfig IE. In some implementations, the UE 102 receives these configuration parameters from the base station 104. In other implementations, the UE 102 receives a portion of these configuration parameters from a base station other than the base station 104 and the remaining portion of these configuration parameters from the base station 104.

[0062] While communicating with the base station 104, the UE 102 generates 304 a first buffer status report (BSR) in a first format according to a first BSR table and an amount of data buffered in UE buffer(s) of the UE 102. The first BSR includes a buffer size indicating the amount of buffered data. The buffered data can be associated with a first logical channel, a first logical channel group (LCG) and/or a first radio bearer (RB). The UE 102 can include an ID of the first logical channel or the first LCG in the first BSR to indicate that the buffer size is associated with the first logical channel or the first LCG. The UE 102 then transmits 306 the first BSR to the base station 104. After receiving the first BSR, the base station 104 generates UL grant(s) 1, ... , A to accommodate an amount of data reported in the first BSR. N is a positive integer. The base station 104 transmit 310, 314 the UL grants 1. ... , N to the UE 102. The UE 102 transmits 312. 316 data 1, ... , N to the base station 104 in accordance with the UL grants 1. , , respectively.

[0063] In some implementations, the first BSR is a MAC CE. The UE 102 includes the MAC CE and a subheader of the MAC CE in a MAC PDU and transmits 306 the MAC PDU to the base station 1 4. The UE 1 2 includes, in the subheader, a logical channel identity identifying the MAC CE (i.e., the first BSR or the first BSR format). When the base station 104 receives the MAC PDU 306, the base station 104 identifies the MAC CE is a BSR (i.e., the first BSR) of the first BSR format based on the logical channel identity. The base station 104 determines to use the first BSR table to derive a buffer status size from the first BSR, based on the logical channel identify.

[0064] Later in time, the base station 104 transmits 318 a RRC reconfiguration message including configuration parameters(s) to enable a second BSR table and/or a delay status report (DSR). For example, the RRC reconfiguration message includes a BSR configuration parameter to allow the UE 102 to transmit a BSR based on the second BSR table. In another example, the RRC reconfiguration message includes a DSR configuration parameter to allow the UE 102 to transmit a DSR. In response, the UE 102 transmits 320 a RRC reconfiguration complete message to the base station 104 and enables usage of the second BSR table and/or a DSR function. After enabling usage of the second BSR table, the UE 102 can generate 322 a second BSR in a second format in accordance with the second BSR table and an amount of data buffered in the UE buffer(s). The second BSR includes a buffer size indicating the amount of the buffered data. In some implementations, the buffered data can be associated with a second logical channel, a second LCG and/or a second RB. The UE 102 can include an ID of the second logical channel or the second LCG in the second BSR to indicate that the buffer size is associated with the second logical channel or the second LCG. The UE 102 then transmits 324 the second BSR to the base station 104. After receiving the second BSR, the base station 104 generates UL grant(s) N+l, ... , N+M to accommodate an amount of data reported in the second BSR. M is a positive integer. The base station 104 transmits 326, 330 the UL grants N+l, ... . N+Mto the UE 102. The UE 102 transmits 328, 330 data N+l, .. , N+M to the base station 104 in accordance with the UL grants N-l. ... , N+M, respectively.

[0065] In some implementations, the first BSR format includes a 5-bit buffer size field and the first BSR table includes buffer size levels (e.g., 32 levels) for the 5-bit buffer Size field. For example, the first BSR table is a BSR table 6. 1.3. 1-1 in 3GPP specification 38.321 in a version between vl5.4.0 and V17.2.0. In other implementations, the first BSR format includes an 8-bit buffer size field and the first BSR table includes buffer size levels (e.g.. 255 or 256 levels) for the 8-bit buffer Size field. For example, the first BSR table is a BSR table 6.1.3.2-1 in 3GPP specification 38.321 in a version between vl5.4.0 and V17.2.0. In some implementations, the second BSR format includes a 5-bit buffer size field and the second BSR table includes buffer size levels (e.g., 32 levels) for the 5-bit buffer Size field. In other implementations, the second BSR format includes a 6-bit buffer size field and the second BSR table includes buffer size levels (e.g., 63 or 64 levels) for the 6-bit buffer Size field. In yet other implementations, the second BSR format includes an 8-bit buffer size field and the second BSR table includes buffer size levels (e.g.. 32 levels) for the 8-bit buffer Size field. In yet other implementations, the second BSR format includes a 9-bit buffer size field and the second BSR table includes buffer size levels (e.g., 511 or 512 levels) for the 9-bit buffer Size field. In yet other implementations, the second BSR format includes a 10-bit buffer size filed and the second BSR table includes buffer size levels (e.g., 512 levels) for the 10-bit buffer Size field.

[0066] In some implementations, the second BSR table is a new BSR table. In some implementations, the new BSR table can include the same number of buffer size levels as the first BSR table. In other implementations, the second BSR table includes different number of buffer size levels. In some implementations, some of buffer status values in the first BSR table and second BSR table are different and the rest buffer status values in the first BSR table and second BSR table are the same. In other implementations, none of buffer status values in the first BSR table and second BSR table are the same.

[0067] In some implementations, the UE 102 can transmit a third BSR of the first BSR format to the base station 104 after or when enabling the second BSR table. The description above for the first BSR can apply to the third BSR. In other implementations, the UE 102 refrains transmit a BSR of the first BSR format after or when enabling the second BSR table.

[0068] After enabling the DSR function, the UE 102 can transmit 325 a DSR including delay information to the base station 104. In one implementation, the delay information includes a time duration between the time point where a data packet arrives in the UE buffer and the time point where the DSR is generated or/and reported. In another implementation, the delay information includes the remaining time before the expiry of a delay budget for a data packet. In still another implementation, the delay information includes the remaining time before the expiry of the PDCP discard timer associated to a data packet. The data packet above can be associated with the second logical channel, the second LCG or the second RB. The UE 102 can include the ID of the second logical channel or second LCG in the DSR to indicate that the DSR is associated with the second logical channel or second LCG. The base station 104 uses the delay information to schedule transmission of UL data from the UE 102 in addition to the second BSR. For example, when generating or transmitting the UL grant(s) N+l. , N M. the base station 104 takes the DSR into account to ensure that the UE 102 can transmit the data N+l, ... , N+M before expiry of the delay budget or before running out of the remaining time.

[0069] In some implementations, the UE 102 includes the second BSR and the DSR in a MAC control element (CE), includes the MAC CE and a subheader of the MAC CE in a MAC PDU and transmits 324 the MAC PDU to the base station 104. The UE 102 includes, in the subheader, a logical channel identity identifying the MAC CE. When the base station 104 receives the MAC PDU 324, the base station 104 identifies the MAC CE based on the logical channel identify. The base station 104 determines to use the second BSR table to derive a buffer status size from the second BSR, based on the logical channel identify. In such cases, the events 324 and 325 can be combined as a single event. The UE 102 can include the ID of the second logical channel or LCG in the MAC CE to indicate that the buffer size and delay information are associated with the second logical channel or second LCG. In other implementations, the second BSR and the DSR are a first MAC CE and a second MAC CE, respectively. The UE 102 includes the first MAC CE, a first subheader of the first MAC CE. the second MAC CE and a second subheader of the MAC CE in a MAC PDU and transmits 324 the MAC PDU to the base station 104. In such cases, the events 324 and 325 can be combined as a single event. The first subheader and second subheader include a first logical channel identity and a second logical channel identity identifying the first MAC CE (i.e., the second BSR or the second BSR format) and second MAC CE (i.e.. the DSR), respectively. When the base station 104 receives the MAC PDU 324, the base station 104 retrieves and identifies the first MAC CE and second MAC CE based on the first subheader and second subheader, respectively. The base station 104 determines to use the second BSR table to derive a buffer status size from the second BSR. based on the first logical channel identity. Alternatively, the UE 102 includes the first MAC CE and second MAC CE in first MAC PDU and second MAC PDU, respectively and transmits the first MAC PDU and second MAC PDU in the event 324 and event 325, respectively. When the base station 104 receives the MAC PDU 324 and the MAC PDU 325, the base station 104 retrieves and identifies the first MAC CE and second MAC CE based on the first logical channel identity and second logical channel identity, respectively. The base station 104 determines to use the second BSR table to derive a buffer status size from the second BSR, based on the first logical channel identity.

[0070] FIG. 3B illustrates a scenario 300B generally similar to that of FIG. 3 A, but here the base station 318B configures only the updated BSR table, without configuring DSR.

[0071] FIG. 3C illustrates a scenario 300C generally similar to that of FIG. 3A, but here the base station 318C configures only DSR. without configuring an updated BSR table.

[0072] Referring next to FIG. 4, illustrating new large BSR table(s) 402 (e.g., of size 512 or 1024). The base station 104 can configure the UE 102 (e.g., semi-statically with RRC or dynamically with a DCI or MAC CE) with a specific range from the table to use for the BSR reporting (e.g., the upper half or the lower half). The base station 104 can indicate to the UE 102 the minimum index 404 in the table and/or the maximum index 406 to use from the new BSR table. The base station 104 can also indicate to the UE 102 a range 408 or a number of bits for the BSR report to determine the range (e.g., 8 bits means a range of 2 8 = 256). Then, the UE 102 should use this range in the table as the BSR table to use for the BSR reporting. In another embodiment, the range can stay constant (e.g., 64, 256, .. . ) and only the start 404 can be adjusted. In another example, the UE 102 can also select the range dynamically and report to the base station 104 the selected range (e.g., the upper half or the lower half)

[0073] Referring next to FIG. 5, the base station 104 can check if XR traffic is to be transmitted 502 and enable the use of the new BSR tables in 504 only when the XR traffic is scheduled (e.g., if some XR traffic TSCAI assistance information are signalled to the base station 104 or/and XR traffic related information are signalled to the base station in the GTP- U header, or PDU-Set or Data-Burst are to be scheduled). For example, the base station 104 can configure the UE 102 with an RRC parameter dedicated to enable or disable the use of the new BSR tables. The base station 104 can configure the UE 102 to use specific BSR tables among the new and/or the legacy BSR tables. The base station 104 can also configure the UE 102 to use both the new and the legacy BSR tables simultaneously. [0074] Referring next to FIGs. 6A and 6B, the selection of the BSR table can be dynamic. For example, the UE 102 indicates in the BSR report which BSR table has been used to generate the BSR report. 3GPP can specify a new field in the BSR MAC CE subheader to indicate which BSR table is used for the BSR report. UE 102 can also use a new LCID to indicate which table has been used (legacy vs. new table). FIGs. 6A and 6B show examples of the new field 614 (T) added in the BSR MAC CE subheader 610 to indicate the BSR table used for the BSR report. The new field 614 can occupy 1 bit. The new field 614 can have a value of ‘0’ to indicate the legacy table and a value of ‘ 1 ’ to indicate the new table. The new field 614 can also occupy multiple bits if more than two tables are used simultaneously. The reserved field (R) 612 is not carrying any information and can be kept or can be removed if needed to accommodate the new field 614 (T).

[0075] Referring next to FIG. 7, the selection of the BSR table(s) can be semi-static (e.g., via RRC configuration). For example, the base station 104 configures the UE 102 to use specific BSR table(s) for a specific configuration and some other specific BSR table(s) for another configuration. For example, as shown in FIG. 7, the base station 104 can configure one or multiple specific BSR table(s) to be used for a subset of LCGs. For example, logical channels associated to conversational audio, video streaming and internet browsing could be linked to LCGs 0 to 2 respectively and can use the legacy BSR tables and logical channels associated to AR/VR traffic and cloud gaming could be linked to LCGs 3 and 4 respectively and can use the new BSR table(s). The base station 104 can configure multiple BSR tables to be used simultaneously for the same BSR format (mainly for long BSR and long truncated BSR) and use each table for a subset of LCGs. 3GPP can define LCG subsets and the base station 104 can configure the UE 102 with which BSR table to use for each LCG subset.

[0076] Referring next to FIG. 8, the selection of the BSR table can be based on a specified or a configured Buffer size threshold B_T. 3GPP can specify⁷ one or multiple thresholds for the selection of the BSR table(s). Alternatively, the base station 104 can configure the UE 102 with one or multiple thresholds to be used for the selection of the BSR table(s) for the BSR report. For example, the UE 102 can compare as in 804 the buffer size to be reported against the threshold B_T, if the buffer size is smaller than B_T then a specific BSR table is selected to generate the BSR report (e.g., one of the legacy tables) as in 808 otherwise another BSR table is selected (e.g. one of the new tables) as in 806. For example, for a VR video data rate of 45 Mbps and for a video frame rate of 60 fps, and based on the RANI packet sizes distribution as shown in Appendix 1, the minimum packet size in the VR flow is 46875 bytes. The UE 102 could use this minimum to switch between BSR tables, i.e., if BS value < 46875 bytes then the UE uses legacy table(s) otherwise the UE 102 uses the new BSR table(s). Hence, in another embodiment, the threshold could depend on the AR/VR video data rate and/or frame rate. The base station 104 can signal to the UE 102 the data rate and/or frame rate and/or any other information and the UE can derive the threshold(s) to use for the BSR table(s) selection. The UE 102 can use other information like XR traffic periodicity and packet size statistics to derive the threshold(s). 3GPP can specify a look-up table to assist the UE 102 in the selection of threshold(s). The look-up table can map XR configurations (e.g. data rate, frame rate, . . . ) to threshold(s). The base station 104 can derive and configure the UE 102 (e.g. via RRC) with the look-up table. Alternatively, 3GPP can specify the look-up table.

[0077] Referring next to FIG. 9, 3GPP can specify a formula for the BSR index calculation. The formula can be a linear formula, a logarithmic formula or an exponential formula. The UE 102 can use the formula to derive the BSR index from its BS value. Alternatively, the UE 102 can use both the formula and the BSR table to derive the BSR index to report to the base station 104 as shown in FIG. 9. For example, 3GPPP can specify' a threshold or the base station 104 can configure the UE with a threshold. As shown in 904, if the BS value is smaller or equal than the threshold then a the BSR table is used as in 908 and if the BS value is bigger than the threshold then the formula is used as in 906.

[0078] In legacy, LCID value of 61 is identifying a short BSR and LCID value of 62 is identifying a long BSR, also LCID of 59 identifies a short truncated BSR and LCID of 60 identifies a Long truncated BSR. Although, LCID stands for Logical Channel Identity, it is used in the BSR context to identify a MAC CE identity rather than a logical channel identity. 3GPP can define new LCID values to differentiate BSR reporting of XR Data-Bursts from legacy BSR reporting of non-XR data. The new' LCID values can be mapped to new' BSR formats (e.g. dedicated for the XR traffic) or mapped to the existing BSR formats but indicating specifically buffer status of XR Data-Bursts. The UE 102 can also use LCID values to differentiate XR Data-Bursts (or/and PDU-Sets) importance/priority if UE transmits different BSRs for different importance/priority. For example, the UE 102 can send two BSRs for the same LCG. The UE 102 uses a specific LCID to transmit short BSR for high priority Data-Bursts (or/and PDU-Sets) to the base station 104 and the UE 102 uses another specific LCID to transmit short BSR for low priority Data-Bursts (or/and PDU-Sets) to the base station 104. Also, the UE 102 uses a specific LCID to transmit long BSR for high priority Data-Bursts (or/and PDU-Sets) to the base station 104 and the UE 102 uses another specific LCID to transmit long BSR for low priority Data-Bursts (or/and PDU-Sets) to the base station 104.

[0079] Referring next to FIG. 10, the 8-bits BSR table (Table 6. 1.3.1 -2: Buffer size levels (in bytes) for 8-bit Buffer Size field) offers better granularity than the 5-bits BSR table for large BS values and could be more beneficial for the XR traffic which has large packets mainly for UL AR traffic. However. 3GPP defines a restriction that the long BSR is used to only accommodate multiple LCGs and the UE 102 uses long BSR only when multiple LCGs (more than 1) have UL data to be transmitted. Therefore, if only one LCG has data to be transmitted and this data is XR data, the UE 102 is not allowed to use the long BSR reporting and cannot use the 8 bits BSR table. In one embodiment, the base station 104 can configure the UE 102 to relax this restriction for the XR traffic or only for reporting the size of PDU- Sets or/and Data-Bursts waiting in the buffer as shown in FIG. 10. For example, a new RRC parameter can be specified. Then, the base station 104 can configure the UE 102 with this new RRC parameter to relax this restriction and allow the UE to use the long BSR reporting and use the 8 bits BSR table for one LCG reporting. Alternatively, 3GPP can allow the UE 102 to use the 8 bits BSR table for the short BSR reporting when reporting the size of PDU- Sets or/and Data-Bursts waiting in the buffer. A new RRC parameter can be specified. Then, the base station 104 can configure the UE 102 with this new RRC parameter to configure the UE to use the 8 bits table for the short BSR reporting to report the size of PDU-Sets or/and Data-Bursts waiting in the buffer. In another example, the UE can have the option to choose between the 8 bits BSR table and the 5 bits BSR table to report a short BSR for one LCG. The UE 102 can signal which table has been used in a new dedicated bit-field or using a new LCID for this purpose. In the example shown in FIG. 10, the UE 102 can measure in 1001 the volume of UL data waiting in the buffer to be scheduled by the base station 104. In 1002, the UE 102 checks the number of LCGs with data available for transmission and if the number of LCGs is larger than 1 then the UE 102 uses the 8-bits BSR table to derive the BSR report. If only one LCG has data available for transmission, then the UE 102 checks in 1004 if XR data (PDU-Sets / Data-Bursts) is to be transmitted to the base station 104. If XR data is available in the buffer, the UE 102 uses in 1005 the 8-bits BSR table for the BSR report. If there is no XR data available in the buffer to transmit then the UE 102 uses in 1006 the 5-bits BSR table for the BSR report.

[0080] 3GPP SA2 has agreed to signal PDU-Set importance information from CN to RAN. This can also be applied similarly in UL and the L2 of the UE 102 can signal to the base station 104 the importance of UL PDU-Sets or/and Data-Bursts. The signalling can take place in the BSR report. The UE 102 can add a dedicated fields as P0 to P7 shown in FIG. 11 to signal the priori ty of the data in the BSR report where each priority bit-field indicates the priority of the data in the associated LCG. P0 indicates the priority of the data in LCG0, Pl indicates the priority of the data in LCG1, and so on. A value of ‘0’ in any of P0 to P7 indicates a low priority data and a value of ‘ 1 ’ in any of P0 to P7 indicates a high priority data. In another example implementation, the UE 102 can use new/dedicated LCID values to signal the importance of the buffered data indicated in the BSR report. In another example as shown in FIG. 12A and FIG. 12B. the MAC sub-header can include a new field 1214 (e.g., of size 1 bit) to indicate the priority of the data indicated in the BSR report. For example, a value of ‘0’ in 1214 indicates low priority data and a value of ‘ 1 ’ indicates high priority data. In another example, the base station 104 can derive the importance implicitly from the BSR table used for by the UE 102 for the BSR report. For example, if the UE 102 uses some specific BSR table(s) for the BSR report (e.g., the new BSR tables), the base station 104 can interpret that the data indicated in the BSR report as high importance/priority data. And if the UE 102 uses some other specific BSR table(s) (e.g., the legacy BSR tables), the base station can interpret that the data indicated in the BSR report as low importance/priority data.

[0081] The UE 102 can report to the base station 104 two BSRs per LCG, one for the high priority data and another BSR for the remaining data.

[0082] The new BSR table(s) to use for the XR traffic could be defined as a UE capability. The UE 102 reports to the base station 104 its support or not of the new BSR table(s). The base station 104 can configure the UE 102 (e g., via RRC) to use the new table(s).

[0083] Instead of defining or configuring a BSR table, the base station 104 can configure the UE 102 (e.g. via RRC, MAC CE) with multiple parameters like BS_min, BS max and Step size. BSjnin can be viewed as the minimum buffer size that can be reported, BS max is the maximum buffer size that can be reported and Step size is the step size to use for the calculation which is equivalent to a uniform step size in the BSR table. UE 102 can determine an index using a formula or using a locally generated table using the base station configuration parameters. In some implementations, the UE 102 can calculate the BS index to be transmitted as BS_index = These parameters can be adjusted by the

base station 104 semi-statically (e.g., via RRC re-configuration) or dynamically (e.g. via DCI or via MAC CE). In some other implementations, this method can be used in addition to the BSR table and the UE 102 can switch semi-statically or dynamically between using a BSR table and using the method described above. In yet other implementations, this method can be used simultaneously with the BSR table and the UE 102 can select to use the BSR table or to use the method above. For example, the UE 102 can select this method for some types of traffic (e.g., PDU-Sets. Data-Bursts, . .. ) and can use the BSR table for the other types of traffic (e.g. eMBB traffic).

New BSR Triggers:

[0084] Referring next to FIG. 13, UE 102 can trigger a BSR if a new PDU-Set (or Data- Burst) becomes available for transmission and the PDU-Set (or Data-Burst) has higher priority/importance than the previously buffered PDU-Sets (or Data-Bursts) waiting to be transmitted even if the newly available PDU-Set (or Data-Burst) belongs to a logical channel which has similar or lower priority compared to the logical channel which has the already buffered PDU-Sets (or Data-Bursts). For example if UL AR traffic is mapped to the same logical channel and the UL AR traffic has PDU-Sets / Data-Bursts of low priority/importance ( e.g. associated to the video P-frames) and PDU-Sets / Data-Bursts of high priority (e.g. associated to the video I-frames), if BSR has been already reported for low priority/importance PDU-Sets / Data-Bursts and then afterwards the new PDU-Sets / Data- Bursts of high priority/importance arrive in the buffer, the UE 102 can trigger a new BSR report specifically to signal the new buffer status after the arrival of the high priority /importance PDU-Sets / Data-Bursts. As shown in FIG. 13, the UE 102 receives in its buffer a low⁷ priority PDU-Set (LP-PDU-Set) in 1302, the UE 102 sends to the base station 104 a scheduling request to schedule UL data. Then, the base station 104 sends to the UE 102 an UL grant for the UE 102 to send the BSR. The UE 102 reports the BSR to the base station 104. Afterwards, the base station 104 transmits an UL grant scheduling for the UL data. In the meantime, the UE 102 receives in its buffer from higher layers another high priority PDU-Set (HP-PDU-Sef) belonging to the same LCH as the previous low priority PDU-Set. The arrival of the high priority PDU-Set triggers a BSR reporting and the UE 102 reports to the base station 104 a new BSR in 1308 to reflect the arrival of the high priority PDU Set.

[0085] Referring next to FIG. 14, the PSDB (PDU-Set Delay Budget) can be larger than the XR periodicity (e.g., UL AR PSDB is 30 ms and for 60 fps the UL AR traffic periodicity is 16.66 ms) and the UE can be buffering multiple Data-Bursts 1402 simultaneously which have different remaining delays (because they arrived at different instants). The UE 102 can report a BSR to the base station 104 when a new PDU-Set or Data-Burst is received in the buffer regardless of the comparison of its logical channel priority with the logical channels' priorities of the existing buffered data.

[0086] Referring next to FIG. 15. 3GPP can define a new periodic BSR timer specific for XR traffic and dedicated for the reporting of buffered XR data. For example, the periodicities of the new periodic BSR timer are aligned with the XR traffic periodicities. The new periodicities for periodicBSR-Timer could be non-integer periodicities.

[0087] Referring next to FIG. 16, and in another embodiment, 3 GPP can continue using the existing periodic BSR reporting mechanism with the periodicBSR-Timer for the XR traffic. However. 3GPP can restrict the reset of the periodicBSR-Timer with the Padding BSR to some interval around the periodic arrival of the traffic, for example restricting the reset intervals to the jitter intervals (e.g. [-4ms, +4ms]). This means that the UE 102 can reset periodicBSR-Timer after transmission of a padding BSR to the base station 104 only if the padding BSR is transmitted in specific intervals of time. The base station 104 can configure the UE 102 with the specific intervals 1602 during which the padding BSR is allowed to reset the periodic BSR timer. The UE 102 can apply this restriction only for the transmission of the BSR report for the XR traffic (PDU-Sets / Data-Bursts). The base station 104 can enable/disable this functionality for the UE 102. The activation/deactivation can be based on the type of the UL traffic (e.g.. only for UL AR traffic).

[0088] UE 102 can be specified to always send BSR with each MAC PDU carrying XR traffic (PDU-Set or Data-Burst), or at least, alternatively, the UE 102 can be specified to always send a BSR in the first MAC PDU of a PDU-Set or of a Data-Burst. UE 102 can be specified to always send to the base station 104 a BSR piggybacked on the first PUSCH transmitted in the DRX On-Duration when XR traffic is transmitted. [0089] Referring next to FIG. 17, the base station 104 can configure the UE 102 to report a BSR after each PDU-Set discard decision. The UE 102 may decide to discard a PDU-Set if the delay budget of the PDU-Set has expired as in 1710 or to alleviate congestion (e.g., discarding low importance/priority PDU-Sets). The UE 102 can also decide to discard a PDU-Set if one or multiple of the PDUs in the PDU-Set are lost. The UE 102 can send a BSR report after each PDU-Set discarding as in 1711 to inform the base station 104 about the change in the buffer status. The discard decision can be included if needed in the reported BSR or on in a new MAC CE.

[0090] In another embodiment, BSR could be transmitted on every first PUSCH of a group of PUSCH occasions cartying a new PDU-Set or on every first PUSCH occasion of a group of PUSCH occasions carry ing a new Data-Burst.

[0091] If PDU-Sets of different priority/importance are mapped to the same logical channel, the UE can report multiple BSR reports per LCG, e.g., one report per PDU-Set priority/importance. The different BSR reports can have different configurations (e.g. different periodicBSR-Timer. ... ). For example, the BSR report for high priority PDU-Set could have smaller periodicBSR-Timer and can be transmitted more frequently.

Delay Reporting:

[0092] The UE 102 transmits the delay status report (DSR) including delay information to the base station 104. In one implementation, the delay information includes a time duration between the time instant where a data packet arrives in the UE buffer and the time instant where the DSR is generated or/and reported. In another implementation, the delay information includes the remaining time before the expiry of a delay budget for a data packet. In still another implementation, the delay information includes the remaining time before the expity of the PDCP discard timer associated to a data packet.

[0093] In some implementations, the delay information includes a single delay value that is associated with one group of multiple PDUs, one group of multiple PDU-Sets, or one group of multiple Data-Bursts, and the single delay value is the largest delay amongst the delays of each PDU in the group, amongst the delays for each PDU-Set in the group, or amongst the delays for each Data-Burst in the group. In other implementations, the delay information includes one or more delay values each associated with a PDU, PDU-Set or a Data Burst associated to a logical channel or an LCG. [0094] In some implementations, the base station 104 enables the DSR for the high priority/importance PDU-Sets that the UE 102 transmits (e.g., event 318). In other implementations, the base station 104 enables the DSR for the high priority logical channels of the UE 102. In still other implementations, the base station 104 enables the DSR for a LCG ofthe UE 102.

[0095] Regarding the granularity to be used for the delay information, a fraction of the PDCP discardTimer could be used. For example, if d bits are used for the delay reporting, then the granularity of the delay reporting could be PDCP_discardTimer/2^d. For example, if PDCP_discardTimer = 30 ms and if d = 3 bits are used for the delay information, then if 30 the UE reports Oi l (the value 3), this indicates that the data was buffered for — x 3 =

11.25 ms

[0096] Regarding the granularity to be used for the delay status reporting, a fraction of the PDU-Set Delay Budget (PSDB) could be used. For example, if d bits are used for the delay reporting, then the granularity of the delay reporting could be PSDB/2^d. For example, if PSDB = 30 ms and if d = 3 bits are used for the delay reporting, then if the UE reports 01 1 (the value 3). this indicates that the data was buffered for — x 3 = 11.25 ms.

[0097] Regarding the time unit to be used for the delay status reporting, it could be in units of microseconds, milliseconds, seconds. It could also be in units of frames, slots, symbols. Or alternatively, it could be in unit of a fraction of a timer or a delay budget as described in the previous paragraphs.

[0098] If the UE 102 sends the delay status report jointly with the BSR report and since the

BSR report is sent per Logical Channel Group (LCG) then the UE can also transmit the delaystatus report per LCG and could be indicating the maximum buffering delay of all the data buffered for the associated LCG. The delay status report could also be per LCG. It could be indicating the maximum buffering delay of the logical channel with the highest priority (LCP) in the LCG. The delay status report can also report the delays for all logical channels in the LCG.

[0099] The UE 102 can send to the base station 104 the DSR per PDU-Set or per Data- Burst. The UE 102 can also quantize the delays of all the buffered PDU-Sets (or/and Data- Bursts) and report each quantized delay together with the number of PDU-Sets (or/and Data- Bursts) associated to each quantized delay.

[00100] A new MAC CE can be defined to report the DSR by the UE 102 to the base station 104. The new MAC CE can have a sub-header indicating the PDU-Set index or its sequence number, or the Data-Burst index or its sequence number or any other indication about the data associated to the delay indicated in the MAC CE. Similar to the BSR reporting, the MAC CE for DSR reporting can use one or multiple fields of ‘R’, ‘F‘, ‘LCID’, L’ in the subheader, where R is a reserved field, F specifies the value of size of the length L (e.g., a value of ‘ 0’ indicating that L occupies 8 bits and a value of ‘ T indicating that L occupies 16 bits), LCID to identify the MAC CE for the DSR reporting, L to indicate the size of the MAC CE. Other fields are not excluded, like a field to indicate the PDU-Sets (or/and Data-Bursts) importance/ pri ority .

[00101] The UE 102 can send the DSR simultaneously with the BSR or separately /independently from the BSR. The base station 104 can configure the UE 102 (e.g., via RRC) to report the DSR simultaneously with BSR or separately from the BSR.

[00102] The UE 102 can send to the base station 104 the DSR and the BSR jointly in the same MAC CE. In one embodiment, a new BSR and DSR format can be specified specifically for the joint reporting of the BSR and the DSR. In another embodiment, the legacy BSR formats (long, short, long truncated and short truncated) specified in 3GPP specification 38.321 in a version between V15.4.0 and V17.2.0 can be extended to support the DSR reporting. BSR MAC CE can have new fields to indicate the DSR jointly with the BSR. For long BSR formats, each DSR can signal the delay associated with the data indicated in each BSR in the report. In one implementation, the DSR can report the delay associated with the highest priority logical channel in the LCG. In another implementation, it can report the worst delay of all logical channels in the LCG. In another implementation, it can report the average delay of all logical channels in the LCG.

[00103] 3GPP can define DSR periodicities for the DSR reporting, e.g., DSR periodicities could be aligned with the XR traffic periodicities, DSR periodicities could also be similar to the existing BSR periodicities.

[00104] 3GPP can define DSR configuration, DRS-config. The base station 104 can configure the UE 102 with the DSR configuration (e.g., via RRC). The DSR-config can include the periodic DSR timer (periodicities), the delay threshold to trigger to the DSR report, LCGs or/and LCHs for which a DSR report is required to be transmitted.

[00105] 3GPP can define a DSR table with different delay steps and the UE 102 can find the index associated to the delay status and report the index in the DSR report.

[00106] 3GPP can define DSR formats (e.g., short, long, short truncated, long truncated, . .. ) and DSR triggers (regular DSR, periodic DSR, padding DSR, . . . ).

[00107] 3GPP can define a delay threshold to trigger the DSR reporting. For example, if the PDU-Set buffering time is close to a specific fraction of the PSDB expiry (PDU-Set buffering time > a PSDB, where a < 1). For example, the UE 102 sends a DSR if the PDU- Set buffering time is above the half of the PSDB expiry (a = 0.5).

[00108] 3GPP can define a new timer for the DSR (or/and BSR) reporting. When the timer expires the UE 102 reports a DSR (or/and BSR) to the base station 104. The timer maybe set by the UE 102 upon receiving in the buffer a PDU, PDU-Set. a Data-Burst or a specific type of data. The base station 104 can configure the timer to the UE 102 (e.g., via RRC). The base station 104 can configure multiple timers to the UE 102 (e.g., via RRC). For example, different timers can be configured for different level of importance/priority of the PDU-Sets.

[00109] Multiple BSR tables could be defined/specified or configured. The UE 102 can autonomously select the suitable BSR table based on information/characteristics from higher layer about the XR traffic (e.g., video resolution, video encoding rate, PDU Set sizes, I/P frames, . . . ). The UE 102 can signal an information about the selected BSR table(s) to the base station 104. In another example, information about the XR application is signalled to the base station /XR server and the base station 104 configures the UE 102 with the suitable BSR table(s) to be used. In another example, the BSR tables are generated by the UE 102 on the fly based on up-to-date information/characteristics about the XR traffic (e.g., video resolution, video encoding rate, PDU Set sizes, I/P frames, . . . ).

[00110] The UE 102 can signal to the base station 104 the range that the BSR table(s) should cover (e.g. min BS value and max BS value in the table(s)). The base station 104 can use this information to adjust the BSR table(s) and signal them to the UE 102. The base station 104 can also use this information to select the distribution points and/or the step sizes of the BSR table(s). The base station 104 can adjust the range dynamically or semi-statically e.g. via RRC signalling to the UE 102. The objective could be to cover some specific traffic sizes.

[00111] The number of the new BSR table distribution points could be RRC configured by the base station 104 to the UE 102. In another example, the base station 104 can configure the UE 1 2 with the minimum value and the maximum value of the BSR table(s) and the step size(s) or the number of distribution points to be used to generate the BSR table(s). The base station 104 can configure the UE 102 with the distribution method to derive the BS values, for example linear, logarithmic or gaussian or truncated gaussian. The base station 104 can configure the UE 102 with the parameters to be used for the distribution method. In another example, the base station 104 can configure the UE 102 with the number of bits for the BSR reporting.

[00112] The UE 102 can report to the base station 104 the quantization errors derived when calculating the BSR values. In another example, the UE 102 can report to the base station 104 statistics about the quantization errors (e.g., mean quantization error). The base station 104 can configure the UE 102 with different parameters based on the reported quantization errors. For example, the base station 104 can configure the UE 102 with different BSR tables or configure the UE with a different step size. In another example implementation, the UE can send a request for new BSR tables based on the calculated quantization error.

[00113] If the UE 102 is using multiple BSR table(s) simultaneously to derive the BSR report, the UE can select the suitable table based on the residual quantization error. The UE 102 can select the table which gives the smallest quantization error. The UE 102 can also indicate to the base station 104, the BSR table that has been used for the BSR report.

[00114] The legacy BSR table(s) (tables up to 5G NR Rel-17) could be used to derive a coarse BSR value and the new BSR table(s) (new 5G NR Rel-18 tables) could be used to derive a finer BSR value to be both reported.

[00115] In another example if coarse BSR values and finer BSR values are reported by the UE 102 to the base station 104, then the finer BSR values are reported if the BSR quantization error is above a certain threshold. The threshold could be specified or configured by the base station 104 to the UE 102. A new bit-field could be specified and signalled with the BSR coarse value to indicate whether the finer values are going to be reported for the same buffer status or not.

[00116] One or multiple quantization formulas can be used to derive the BS index, for example the BS index can be found with a linear quantization with f(x) = + b|, where x

is the actual buffer size and where [ J indicates a rounding down to the nearest integer, round up could also be used, A is the step size, and a and b are constant that could be specified/ defined or configured by the base station 104 to the UE 102, e.g. via RRC. In another example the quantization formula could be defined as f(x) = max (n, 4-

b)j 4- d) where n is a minimum value to be specified/defined or configured by the base station 104 to the UE 102, e.g., via RRC. a, b. c and d are constants that could be specified/defined or configured by the base station 104 to the UE 102, e g., via RRC.

[00117] In another embodiment, the formula could be used jointly with the BSR tables and some of the constants and/or parameters in the formula could be derived from the BSR tables. For example, the table could be used to derive a coarse BS index and the formula could be used to derive a finer BS index and both BS indices could be signalled by the UE 102 to the base station 104 in separate BSR reports or simultaneously in the same BSR report. The formula could be a liner formula with a step size adjustable for each BS interval in the table. For example, using the legacy table a BS_value = 3100000 is associated to the BS index 202 because 3090279 < 3120000 < 3290873, assuming 2ⁿ distribution points are configured for this BS interval then another BS index between 0 and 2ⁿ could be derived and

2ⁿ(BS-BSvaluej') signalled. The new value can be derived as where BS is the actual buffer value ~ evalue j size value with the exact amount of data in the buffer and BS_valuek and BS_value are the two BS values from the BS table such that BS_vaiue < BS < BS_vatuek and [ ], indicates a rounding up to the nearest integer, and alternatively round down could also be used. The obtained value could be indicated together with the BS index.

[00118] If a scaling factor is used to adjust the reference BSR table, the UE 102 receives an RRC signalling of the scaling factor and multiplies the BS values in the reference BSR table with the signalled scaling factor to find the new BS values of the new BSR tables to be used to derive the BSR report. Multiple scaling factors could be defined/specified and the base station signals an indication of the scaling factor to be selected. In another example, the UE 102 can select a scaling factor and indicate to the base station 104 the scaling factor that has been used for the BSR report.

[00119] The following examples are illustrative only and may be combined with other examples or teachings described herein, without limitation.

[00120] Example 1 is a method of wireless communication at a UE, including: transmitting, to a netw ork entity, a DSR indicating a remaining time before an expiry of a packet data convergence protocol (PDCP) discard timer associated with a data packet.

[00121] Example 2 may be combined with example 1 and includes that communicating, with the netw ork entity, using a first configuration, wherein the UE transmits the DSR indicating a delay associated with an amount of data buffered at the UE using a second configuration.

[00122] Example 3 may be combined with any of the examples 1-2 and further includes that receiving, from the network entity', a DSR configuration indicating: a periodic DSR timer, or a delay threshold to trigger the DSR report, or at least one of a plurality' of logical channel groups, LCGs. for which the DSR report is to be transmitted, or at least one of a plurality of logical channels. LCHs, for which the DSR report is to be transmitted.

[00123] Example 4 may be combined with any of the examples 1 -3 and further includes that wherein the DSR indicates at least one of: an amount of time between a first time when a data packet arrives at the UE and a second time when the UE transmits the DSR, or an amount of time remaining before a delay budget expires for the data packet.

[00124] Example 5 may be combined with any of the examples 1-4 and further includes that the UE transmits the DSR in a medium access control -control element (MAC-CE).

[00125] Example 6 may be combined with any of the examples 1 -5 and further includes that the UE transmits the DSR per LCG.

[00126] Example 7 may be combined w ith any of the examples 1-6 and further includes that transmitting, to the network entity, a first buffer status report, BSR, indicating the amount of data buffered at the UE according to a first format.

[00127] Example 8 may be combined with example 7 and further includes that receiving, from the network entity, an indication that the UE is to generate a second BSR according to a second format; and transmitting, to the network entity, the second BSR according to the second format, where the first format corresponds to a first BSR table, and the second format corresponds to a second BSR table.

[00128] Example 9 may be combined with example 8 and further includes that the second BSR table provides a higher granularity than the first BSR table.

[00129] Example 10 may be combined with any of the examples 7-9 and further includes that transmitting, to the network entity, a UE capability message indicating a UE capability to support the second BSR.

[00130] Example 11 is a method of wireless communication at a network entity, including: receiving, from a UE, a DSR indicating a remaining time before an expiry' of a PDCP discard timer associated with a data packet.

[00131] Example 12 may be combined with example 11 and further includes that communicating, with the UE, using a first configuration, wherein the network entity receives the DSR indicating a delay associated with an amount of data buffered at the UE using a second configuration.

[00132] Example 13 may be combined with any of the examples 11-12 and further includes that transmitting, to the UE, a DSR configuration indicating: a periodic DSR timer, or a delay threshold to trigger the DSR report, or at least one of a plurality of logical channel groups. LCGs, for which the DSR report is to be transmitted, or at least one of a plurality’ of logical channels, LCHs, for which the DSR report is to be transmitted.

[00133] Example 14 may be combined with any of the examples 11-13 and further includes that the DSR indicates at least one of: an amount of time betw een a first time when a data packet arrives at the UE and a second time when the UE transmits the DSR, or an amount of time remaining before a delay budget expires for the data packet.

[00134] Example 15 may be combined with any of the examples 11-14 and further includes that the network entity receives the DSR in a medium access control -control element, (MAC-CE).

[00135] Example 16 may be combined with any of the examples 11-15 and further includes that the network entity receives the DSR per LCG, the DSR indicating a maximum buffering delay of data buffered for an associated LCG. [00136] Example 17 may be combined with any of the examples 11-16 and further includes that receiving, from the UE, a first buffer status report. BSR, indicating the amount of data buffered at the UE according to a first format.

[00137] Example 18 may be combined with example 17 and further includes that transmitting, to the UE, an indication that the UE is to generate a second BSR according to a second format; and receiving, from the UE, the second BSR according to the second format, where the first format corresponds to a first BSR table, and the second format corresponds to a second BSR table.

[00138] Example 19 may be combined with example 18 and further includes that the second BSR table provides a higher granularity than the first BSR table.

[00139] Example 20 may be combined with any of the examples 17-19 and further includes that receiving, from the UE, a UE capability message indicating a UE capability to support the second BSR.

[00140] Example 21 may be combined with example 6 and further includes that the DSR indicating a maximum buffering delay of data buffered for an associated LCG.

[00141] Example 22 may be combined with example 16 and further includes that the DSR indicating a maximum buffering delay of data buffered for an associated LCG.

[00142] Example 23 is a method implemented in a UE for buffer status reporting, the method including: transmitting, to a radio access network (RAN), a first buffer status report (BSR) according to a first format; receiving, from the base station, an indication that the UE is to generate a second BSR according to a second format; and transmitting, to the RAN, a second BSR according to the second format.

[00143] Example 24 may be combined with example 23 and further includes the first format corresponds to a first BSR table, and the second format corresponds to a second BSR table.

[00144] Example 25 may be combined with example 24 and further includes the first BSR table and the second BSR table include different numbers of entries.

[00145] Example 26 may be combined with example 24 and further includes the first BSR table and the second BSR table include a same number of entries. [00146] Example 27 may be combined with any of the examples 24-26 and further includes the second BSR table provides a higher granularity than the first BSR table.

[00147] Example 28 may be combined with example 23 and further includes that the first format corresponds to a first range within a BSR table; the indication refers to a second range within the BSR table different from the first range; and the second format corresponds to the second range.

[00148] Example 29 may be combined with example 23 and further includes that the indication is included in a command to reconfigure a radio connection betw een the UE and the RAN.

[00149] Example 30 may be combined with any of the examples 23-29 and further includes that the BSR indicates an amount of data buffered at the UE.

[00150] Example 31 may be combined with any of the examples 23-30 and further includes that transmitting, to the RAN, an indication that the UE uses the second format to generate the second BSR.

[00151] Example 32 is a method implemented in a user equipment (UE) for buffer status reporting, the method including: transmitting, to a radio access network (RAN), a buffer status report (BSR) indicative of an amount of data buffered at the UE; and transmitting, to the RAN, a delay status report (DSR) indicative of a delay associated with the data.

[00152] Example 33 may be combined with example 32 and further includes that receiving, from the base station, an indication that the UE is configured to transmit the DSR.

[00153] Example 34 may be combined with example 32 or 33 and further includes that the DSR indicates an amount of time betw een (i) a time when a data packet arrives at the UE and (ii) a time when the UE transmits the DSR.

[00154] Example 35 may be combined with example 32 or 33 and further includes that the DSR indicates an amount of time remaining before a delay budget expires for a data packet.

[00155] Example 36 is an apparatus for wireless communication including a transceiver, a memory, and a processor coupled to the memory and the transceiver, the apparatus being configured to implement a method as in any of claims 1-35.

[00156] Example 37 is an apparatus for wireless communication including means for implementing a method as in any of examples 1-35. [00157] Example 38 is a non-transitory computer-readable medium storing computer executable code, the code when executed by a processor causes the processor to implement a method as in any of examples 1-35.

Appendix

3GPP TR 38.838 V17.0.0 (2021-12) Study on XR (Extended Reality) Evaluations for NR (Release 17)

Section 5.1.1.1

Packet Size

In this model, a packet models the set of IP packets belong to the same video frame. The video frame includes both left and right eye frame sharing the same buffer, which is referred to as 'single stream for dual eye buffer¹ or 'single eye buffer' throughout this document.

The size of a packet is determined by the given data rates and frame rates, which is modelled as a random variable following truncated Gaussian distribution with following statistical parameters.

Table 5.1.1.1-1 : Statistical parameters for packet size following truncated Gaussian distribution

SUBSTITUTE SHEET (RULE 26)

Claims

CLAIMS WHAT IS CLAIMED IS:

1. A method of wireless communication at a user equipment, UE, (102), comprising: transmitting (325), to a network entity (104), a delay status report, DSR, indicating a remaining time before an expiry of a packet data convergence protocol, PDCP, discard timer associated with a data packet.

2. The method of claim 1, further comprising: communicating (302), with the network entity (104), using a first configuration, wherein the UE (102) transmits the DSR indicating a delay associated with an amount of data buffered at the UE (102) using a second configuration.

3. The method of any of claims 1-2, further comprises: receiving (318C), from the network entity (104), a DSR configuration indicating: at least one of a plurality of logical channel groups, LCGs, for which the DSR report is to be transmitted.

4. The method of any of claims 1-3, wherein the DSR indicates an amount of time remaining before a delay budget expires for the data packet.

5. The method of any of claims 1-4, wherein the UE (102) transmits (325) the DSR in a medium access control-control element, MAC-CE.

6. The method of any of claims 1-5, wherein the UE (102) transmits (325) the DSR per LCG.

7. The method of any of claims 1-6, further comprising:

37

SUBSTITUTE SHEET (RULE 26) transmitting (306), to the network entity (104), a first buffer status report, BSR, indicating the amount of data buffered at the UE (102) according to a first format. receiving (318), from the network entity (104), an indication that the UE (102) is to generate a second BSR according to a second format; and transmitting (324), to the network entity (104), the second BSR according to the second format, wherein the first format corresponds to a first BSR table, and the second format corresponds to a second BSR table.

8. The method of claim 7, further comprising: transmitting, to the network entity (104), a UE capability message indicating a UE capability to support the second BSR.

9. A method of wireless communication at a network entity (104), comprising: receiving (325), from a user equipment, UE, (102), a delay status report, DSR, indicating a remaining time before an expiry of a packet data convergence protocol, PDCP, discard timer associated with a data packet.

10. The method of claim 9, further comprising: communicating (302), with the UE (102), using a first configuration, wherein the network entity' (104) receives the DSR indicating a delay associated with an amount of data buffered at the UE (102) using a second configuration.

11. The method of any of claims 9-10, further comprises: transmitting (318C), to the UE (102), a DSR configuration indicating: at least one of a plurality of logical channel groups, LCGs, for which the DSR report is to be transmitted.

38

SUBSTITUTE SHEET (RULE 26)

12. The method of any of claims 9-11, wherein the DSR indicates an amount of time remaining before a delay budget expires for the data packet.

13. The method of any of claims 9-12, wherein the network entity (104) receives (325) the DSR in a medium access control-control element, MAC-CE.

14 The method of any of claims 9-13, wherein the network entity (104) receives (325) the DSR per LCG.

15. The method of any of claims 9-14, further comprising: receiving (306), from the UE (102), a first buffer status report, BSR, indicating the amount of data buffered at the UE (102) according to a first format. transmitting (318), to the UE (102), an indication that the UE (102) is to generate a second BSR according to a second format; and receiving (324), from the UE (102), the second BSR according to the second format, wherein the first format corresponds to a first BSR table, and the second format corresponds to a second BSR table.

16. The method of claim 15, further comprising: receiving, from the UE (102), a UE capability message indicating a UE capability to support the second BSR.

17. An apparatus for wireless communication comprising a transceiver, a memory, and a processor coupled to the memory and the transceiver, the apparatus being configured to implement a method as in any of claims 1-16.

39

SUBSTITUTE SHEET (RULE 26)