Delay status report medium access control control element format selection

By introducing multiple DSR, MAC, and CE formats, the problem of insufficient user equipment buffer management was solved, enabling more efficient data transmission and network scheduling, and improving data transmission efficiency and resource utilization.

CN121078552APending Publication Date: 2025-12-05APPLE INC
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
CN202510733129.1
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Priority Date
2024-06-04
Filing Date
2025-06-04
Publication Date
2025-12-05

AI Technical Summary

Technical Problem

In existing technologies, the user equipment's buffer cannot effectively manage data transmission within a limited time, resulting in data loss. Furthermore, the lack of a flexible method for selecting the Delay Status Report (DSR) Media Access Control (MAC) Control Element (CE) format affects data transmission efficiency.

Method used

By introducing multiple DSR MAC CE formats, the appropriate format can be selected based on characteristics for data reporting, including additional information and buffer size indications, thus enhancing data transmission management.

Benefits of technology

It improves data transmission efficiency and flexibility, provides a more comprehensive view of buffer status, and optimizes network scheduling and resource utilization.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN121078552A_ABST
    Figure CN121078552A_ABST
Patent Text Reader

Abstract

The invention relates to delayed state reporting medium access control control element format selection. Devices and components are disclosed, including apparatuses, systems, and methods for selecting a Delay Status Report (DSR) Medium Access Control (MAC) Control Element (CE) format for the DSR.
Need to check novelty before this filing date? Find Prior Art

Description

[0001] Cross Reference to Related Applications

[0002] This application claims priority to U.S. Provisional Application No. 63 / 655,966, filed June 4, 2024, entitled “Delay Status Report Medium Access Control Control Element Format Selection,” the disclosure of which is incorporated by reference herein in its entirety for all purposes. TECHNICAL FIELD

[0003] The present application relates to the field of wireless technology, and in particular to selection of a delay status report (DSR) medium access control (MAC) control element (CE) format for a delay status report. BACKGROUND

[0004] Third Generation Partnership Project (3GPP) networks provide transmissions between user equipment (UE) and base stations to serve users. To facilitate transmissions from the UE to the base station, the UE has a buffer that can store data, such as packets, to be transmitted to the base station. However, because the buffer has a limited amount of space, the buffer is configured to store data for a limited amount of time. Data is discarded when the limited amount of time expires, regardless of whether the data was transmitted to the target base station. BRIEF DESCRIPTION OF DRAWINGS

[0005] Figure 1 A network environment is illustrated in accordance with some embodiments.

[0006] Figure 2 A user equipment is illustrated in accordance with some embodiments.

[0007] Figure 3 A network device is illustrated in accordance with some embodiments.

[0008] Figure 4 An example delay status report (DSR) timing representation 400 is illustrated in accordance with some embodiments.

[0009] Figure 5 An example DSR medium access control (MAC) control element (CE) structure is illustrated in accordance with some embodiments.

[0010] Figure 6 An example procedure for DSR MAC CE format selection is illustrated in accordance with some embodiments.

[0011] Figure 7An example DSR MAC CE structure according to some embodiments is illustrated.

[0012] Figure 8 Another example DSR MAC CE structure according to some embodiments is illustrated.

[0013] Figure 9 An example procedure for generating a DSR according to some embodiments is illustrated.

[0014] Figure 10 An example procedure for generating a DSR according to some embodiments is illustrated.

[0015] Figure 11 An example procedure for indicating a DSR MAC CE format to utilize according to some embodiments is illustrated. DETAILED DESCRIPTION

[0016] The following detailed description references the drawings, wherein like numerals indicate the same or similar elements. In this description, for the purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of various embodiments. It should be apparent, however, that various embodiments can be practiced without

[0017] The following is a glossary of terms that can be used in the present disclosure.

[0018] As used herein, the term “circuitry” refers to, is part of, or includes: hardware components such as an electronic circuit, a logic circuit, a processor (shared, dedicated, or group) or memory (shared, dedicated, or group), an Application Specific Integrated Circuit (ASIC), a field-programmable device (FPD) (e.g., a field-programmable gate array (FPGA), a programmable logic device (PLD), a complex PLD (CPLD), a high-capacity PLD (HCPLD), a structured ASIC, or a programmable system-on-a-chip (SoC)), a digital signal processor (DSP), etc., that are configured to provide the described functionality. In some embodiments, circuitry can execute one or more software or firmware programs to provide at least some of the described functionality. The term “circuitry” can also refer to the combination of one or more hardware elements (or a combination of circuits used in electrical or electronic systems) with the program code that the hardware elements are configured to execute. In these embodiments, the combination of hardware elements and program code can be referred to as a particular type of circuitry.

[0019] As used herein, the term “processor circuitry” refers to, is part of, or includes: circuitry capable of sequentially and automatically processing a series of arithmetic or logical operations or recording, storing, or transferring digital data. The term “processor circuitry” can refer to an application processor, a baseband processor, a central processing unit (CPU), a graphics processing unit, a single-core processor, a dual-core processor, a triple-core processor, a quad-core processor, or any other device capable of executing or otherwise operating computer-executable instructions, such as program code, software modules, and / or functional processes.

[0020] As used herein, the term “interface circuitry” refers to, is part of, or includes: circuitry that enables the exchange of information between two or more components or devices, or that is part of such circuitry. The term “interface circuitry” can refer to one or more hardware interfaces, such as a bus, an I / O interface, a peripheral component interface, a network interface card, etc.

[0021] As used herein, the term “user equipment” or “UE” refers to a device with radio communication capabilities and can describe a remote user of network resources in a communication network. Furthermore, the terms “user equipment” or “UE” can be considered synonymous, and can be referred to as a client, mobile, mobile device, mobile terminal, user terminal, mobile unit, mobile station, mobile user, subscriber, user, remote station, access agent, user agent, receiver, radio equipment, reconfigurable radio equipment, reconfigurable mobile device, etc. Furthermore, the terms “user equipment” or “UE” can include any type of wireless / wired device or any computing device including a wireless communication interface.

[0022] As used herein, the term “computer system” refers to any type of interconnected electronic devices, computer devices, or components thereof. Additionally, the term “computer system” or “system” can refer to various components of a computer that are communicatively coupled to each other. Further, the term “computer system” or “system” can refer to multiple computer devices or multiple computing systems that are communicatively coupled to each other and configured to share computing resources or networking resources.

[0023] As used herein, the term “resource” refers to a physical or virtual device, a physical or virtual component within a computing environment, or a physical or virtual component within a particular device, such as a computer device, a mechanical device, memory space, processor / CPU time, processor / CPU usage, processor and accelerator load, hardware time or usage, power, input / output operations, ports or network sockets, channel / link allocation, throughput, memory usage, storage, network, database and application, units of work, and the like. A “hardware resource” can refer to a computing, storage, or network resource provided by a physical hardware element. A “virtualized resource” can refer to a computing, storage, or network resource provided by a virtualization infrastructure to an application, device, system, and the like. The term “network resource” or “communication resource” can refer to a resource that is accessible to a computer device / system via a communication network. The term “system resource” can refer to any kind of shared entity that provides a service and can include a computing resource or a network resource. A system resource can be viewed as a set of coherent functions, network data objects, or services that are accessible through a server, where such system resources reside on a single host or multiple hosts and are clearly identifiable.

[0024] As used herein, the term “channel” refers to any tangible or intangible transmission medium that is used to convey or transfer data or data signals. The term “channel” can be synonymous with or equivalent to “communication channel,” “data communication channel,” “transmission channel,” “data transmission channel,” “access channel,” “data access channel,” “link,” “data link,” “carrier wave,” “radio frequency carrier wave,” or any other similar term denoting a pathway or medium through which data is conveyed. Additionally, as used herein, the term “link” refers to a connection made between two devices for transmitting and receiving information.

[0025] As used herein, the terms “instantiate,” “instantiation,” and the like refer to the creation of an instance. An “instance” also refers to a concrete occurrence of an object, which can occur, for example, during execution of program code.

[0026] The term “connect” can mean that two or more elements have an established signaling relationship with each other over a communication channel, link, interface, or reference point at a common communication protocol layer.

[0027] As used herein, the term “network element” refers to physical or virtualized equipment or infrastructure used to provide wired or wireless communication network services. The term “network element” can be considered synonymous with or otherwise be referred to as networked computers, networked hardware, network equipment, network nodes, virtualized network functions, etc.

[0028] The term “information element” refers to a structural element that contains one or more fields. The term “field” refers to individual content of an information element, or a data element that contains content. An information element can include one or more additional information elements.

[0029] As used herein, the term “based at least in part on” can indicate that an item is based on another item and / or an item based on the other item and one or more additional items. For example, in an embodiment, determining item 1 based at least in part on item 2 can indicate that item 1 is determined based on item 2 alone and / or item 1 is determined based on item 2 and one or more other items.

[0030] As used herein, the terms “buffering delay report” and “delay status report” can refer to the same report. Accordingly, the terms “buffering delay report” and “delay status report” can be used interchangeably herein to refer to the same report. Additionally, “buffering delay report” and “delay status report” can also be used interchangeably.

[0031] Some of the methods described throughout the present disclosure can provide for selecting a delay status report (DSR) medium access control (MAC) control element (CE) format for transmitting a DSR from a plurality of DSR MAC CE formats. Conventional methods include providing a single DSR MAC CE format that provides limited information. It can be desirable to operate to provide additional information and / or fields within a DSR MAC CE, which can result in defining two or more different DSR MAC CE formats for the operation. When multiple different DSR MAC CE formats, it can be beneficial to utilize different DSR MAC CE formats in different situations, such as when channel quality is insufficient for one or more of the plurality of different DSR MAC CE formats and / or resources allocated for the DSR are insufficient for one or more of the plurality of different DSR MAC CE formats. The methods described herein can determine a DSR MAC CE format for a DSR based on characteristics related to the DSR. Additionally, the methods described throughout the present disclosure can provide for a DSR that includes one or more indications of information included in the DSR and / or buffer size information for the DSR.

[0032] Figure 1A network environment 100 is illustrated in accordance with some embodiments. The network environment 100 can include a user equipment (UE) 104 communicatively coupled with a base station 108 of a radio access network (RAN) 110. The UE 104 and the base station 108 can communicate over an air interface compatible with 3GPP TS, such as an interface defining a fifth generation (5G) New Radio (NR) system or higher. The base station 108 can provide user plane and control plane protocol terminations towards the UE 104.

[0033] In some embodiments, the UE 104 and the base station 108 can establish data radio bearers (DRBs) to support sending data over a wireless link between the two nodes. In one example, these DRBs can be used for traffic from an extended reality (XR) application that contains a large amount of data conveying real and virtual images and audio for presentation to a user.

[0034] The network environment 100 can further include a core network 112. For example, the core network 112 can include a 5th Generation Core Network (5GC) or a next generation core network. The core network 112 can be coupled to the base station 108 via a fiber or wireless backhaul. The core network 112 can provide functionality for the UE 104 via the base station 108. These functionalities can include managing subscriber profile information, subscriber location, service authentication, or handover functionality for voice and data sessions.

[0035] In some embodiments, the network environment 100 can also include a UE 106. The UE 106 can be coupled with the UE 104 via a sidelink interface. In some embodiments, the UE 106 can act as a relay node to communicatively couple the UE 104 to the RAN 110. In other embodiments, the UE 106 and the UE 104 can represent terminal nodes of a communication link. For example, the UEs 104 and 106 can exchange data with each other.

[0036] Figure 2 A UE 200 is illustrated in accordance with some embodiments. The UE 200 can be similar to the UE 104 or the UE 106 and substantially interchangeable therewith.

[0037] The UE 200 can be any mobile or non-mobile computing device, such as, for example, a mobile phone, a computer, a tablet, an industrial wireless sensor (e.g., a microphone, a carbon dioxide sensor, a pressure sensor, a humidity sensor, a thermometer, a motion sensor, an accelerometer, a laser scanner, a fluid level sensor, an inventory sensor, a voltage / current meter, or an actuator), a video surveillance / monitoring device (e.g., a camera or a video camera), a wearable device (e.g., a smart watch), or an Internet of Things device.

[0038] The UE 200 can include a processor 204, RF interface circuitry 208, memory / storage 212, user interface 216, sensors 220, drive circuitry 222, power management integrated circuit (PMIC) 224, antenna 226, and battery 228. The components of the UE 200 can be implemented as integrated circuits (ICs), portions of ICs, discrete electronic devices, or other modules, logic, hardware, software, firmware, or a combination thereof. Figure 2 The block diagram of FIG. 2 is intended to show a high-level view of some of the components of the UE 200. However, some of the components shown can be omitted, additional components can be present, and different arrangements of the components shown can occur in other implementations.

[0039] The components of the UE 200 can be coupled through one or more interconnects 232, which can represent any type of interface, input / output, bus (local, system, or expansion), transmission line, trace, or optical connection that allows the various circuit components (on common or different chips or chip sets) to interact with each other.

[0040] The processor 204 can include processor circuitry such as, for example, baseband processor circuitry (BB) 204A, central processor unit circuitry (CPU) 204B, and graphics processor unit circuitry (GPU) 204C. The processor 204 can include any type of circuit or processor circuitry that executes or otherwise operates computer-executable instructions, such as program code, software modules, or functional processes from the memory / storage 212, to cause the UE 200 to perform operations as described herein. The processor 204 can also include interface circuitry 204D to communicatively couple the processor circuitry with one or more other components of the UE 200.

[0041] In some embodiments, the baseband processor circuitry 204A can access a communication protocol stack 236 in the memory / storage 212 to communicate over a 3GPP-compatible network. Generally, the baseband processor circuitry 204A can access the communication protocol stack 236 to perform user plane functions at the PHY layer, MAC layer, RLC layer, PDCP layer, SDAP layer, and PDU layer; and control plane functions at the PHY layer, MAC layer, RLC layer, PDCP layer, RRC layer, and NAS layer. In some embodiments, PHY layer operations can additionally / alternatively be performed by components of the RF interface circuitry 208.

[0042] The baseband processor circuitry 204A can generate or process baseband signals or waveforms carrying information that are capable of being carried on a 3GPP compliant network. In some embodiments, the waveforms for NR can be based on cyclic prefix OFDM (CP-OFDM) in the uplink or downlink, and discrete Fourier transform spread OFDM (DFT-S-OFDM) in the uplink.

[0043] The memory / storage 212 can include one or more non-transitory computer-readable media including instructions (e.g., communication protocol stack 236) executable by one or more of the processors 204 to cause the UE 200 to perform various delay adaptation operations described herein.

[0044] The memory / storage 212 includes any type of volatile or nonvolatile memory now in use or yet to be developed, including removable and non-removable storage. In some embodiments, some of the memory / storage 212 can be located on the processor 204 itself (e.g., the memory / storage 212 can be a part of the chipset corresponding to the baseband processor circuitry 204A), while other memory / storage 212 is located off the processor 204, but is accessible via a memory bus, for example. The memory / storage 212 can include any suitable volatile memory, such as dynamic random access memory (DRAM), static random access memory (SRAM), or the like. The memory / storage 212 can also include any suitable non-volatile memory, such as one or more types of read only memory (ROM), programmable ROM (PROM), erasable PROM (EPROM), electrically EPROM (EEPROM), flash memory, solid state memory, or the like.

[0045] The RF interface circuitry 208 can include transceiver circuitry and radio frequency front module (RFEM) that allow UE 200 to communicate with other devices over a radio access network. The RF interface circuitry 208 can include various elements arranged in transmit or receive paths. These elements can include, for example, switches, mixers, amplifiers, filters, synthesizer circuitry, and control circuitry.

[0046] In the receive path, the RFEM can receive a radiated signal from the air interface via the antenna 226 and continue to filter and amplify the signal (with a low noise amplifier). The signal can be provided to a receiver of the transceiver that down-converts the RF signal to a baseband signal that is provided to the baseband processor of the processor 204.

[0047] In the transmit path, a transmitter of the transceiver up-converts a baseband signal received from the baseband processor and provides an RF signal to the RFEM. The RFEM can amplify the signal through a power amplifier before the signal is radiated across the air interface via the antenna 226.

[0048] In various embodiments, the RF interface circuitry 208 can be configured to transmit / receive signals in a manner compatible with NR access technology.

[0049] Antennas 226 can include antenna elements to convert electrical signals into radio waves for transmission through the air and to convert received radio waves into electrical signals. The antenna elements can be arranged into one or more antenna panels. Antennas 226 can have an antenna panel that is omnidirectional, directional, or a combination thereof, to enable beamforming and multiple-input, multiple-output communication. Antennas 226 can include microstrip antennas, printed antennas fabricated on the surface of one or more printed circuit boards, patch antennas, or phased array antennas. Antennas 226 can have one or more panels designed for a particular frequency band, including bands in FR1 or FR2.

[0050] User interface 216 includes various input / output (I / O) devices designed to enable user interaction with the UE 200. User interface 216 includes input device circuitry and output device circuitry. Input device circuitry includes any physical or virtual means for accepting an input including, inter alia, one or more physical or virtual buttons (e.g., a reset button), a physical keyboard, a keypad, a mouse, a touchpad, a touchscreen, a microphone, a scanner, or a headset, etc. Output device circuitry includes any physical or virtual means for showing information or otherwise conveying information, such as sensor readings, actuator positions, or other similar information. Output device circuitry can include any number or combination of audio or visual displays, including, inter alia, one or more simple visual outputs / indicators (e.g., binary status indicators (such as light-emitting diodes (LEDs) and multi-character visual outputs), or more complex outputs such as display devices or touchscreens (e.g., liquid crystal displays (LCD), LED displays, quantum dot displays, and projectors), the output of characters, graphics, multimedia objects, etc. being generated or produced through operation of the UE 200.

[0051] The sensors 220 can include devices, modules, or subsystems whose purpose is to detect events or changes in its environment and send the information about the detected events (sensor data) to some other devices, modules, or subsystems. Examples of such sensors include: an inertial measurement unit comprising an accelerometer, a gyroscope, or a magnetometer; a microelectromechanical system or nanoelectromechanical system comprising a 3-axis accelerometer, a 3-axis gyroscope, or a magnetometer; a level sensor; a flow sensor; a temperature sensor (e.g., a thermistor); a pressure sensor; a barometric pressure sensor; a gravimeter; an altimeter; an image capture device (e.g., a camera or a lensless aperture); a light detection and ranging sensor; a proximity sensor (e.g., an infrared radiation detector, etc.); a depth sensor; an ambient light sensor; an ultrasonic transceiver; and a microphone or other similar audio capture device.

[0052] The drive circuits 222 can include software and hardware elements that are to control a particular device embedded in, attached to, or otherwise coupled to the UE 200. The drive circuits 222 can include individual drivers to allow other components to interact with or control various input / output (I / O) devices that can be present in or connected to the UE 200. For example, the drive circuits 222 can include a display driver to control and allow access to a display device, a touchscreen driver to control and allow access to a touchscreen interface, a sensor driver to obtain sensor readings from the sensors 220 and to control and allow access to the sensors 220, a driver to obtain actuator positions of electromechanical components or to control and allow access to electromechanical components, a camera driver to control and allow access to an embedded image capture device, an audio driver to control and allow access to one or more audio devices.

[0053] The PMIC 224 can manage power provided to the various components of the UE 200. In particular, with respect to the processor 204, the PMIC 224 can control a power-source selection, voltage scaling, battery charging, or DC-to-DC conversion.

[0054] The battery 228 can power the UE 200, although in some examples the UE 200 can be installed in a fixed location, and can have an electrical power source coupled to an electrical grid. The battery 228 can be a lithium ion battery, a metal-air battery, such as a zinc-air battery, an aluminum-air battery, a lithium-air battery, and so forth. In some implementations, such as in vehicle-based applications, the battery 228 can be a typical lead-acid automotive battery.

[0055] Figure 3 A network device 300 is illustrated in accordance with some embodiments. The network device 300 can be similar to a device of the base stations 108 or the core network 112 or the external data network 120, and can be substantially interchangeable therewith.

[0056] The network device 300 can include a processor 304, RF interface circuitry 308 (if implemented as a base station), core network (CN) interface circuitry 314, memory / storage circuitry 312, and antenna structure 326.

[0057] The components of the network device 300 can be coupled with various other components through one or more interconnects 328.

[0058] The processor 304, RF interface circuitry 308, memory / storage circuitry 312 (including communication protocol stack 310), antenna structure 326, and interconnects 328 can be similar to the similarly named elements described with respect to Figure 2 The similarly named elements shown and described.

[0059] The processor 304 can include processor circuitry such as, for example, baseband processor circuitry (BB) 304A, central processor unit circuitry (CPU) 304B, and graphics processor unit circuitry (GPU) 304C. The processor 304 can include any type of circuit or processor circuitry that executes or otherwise operates computer-executable instructions (such as program code, software modules, or functional processes from the memory / storage circuitry 312) to cause the network device 300 to perform the operations described herein. The processor 304 can also include interface circuitry 304D to communicatively couple the processor circuitry with one or more other components of the network device 300.

[0060] The CN interface circuitry 314 can provide connectivity to a core network (e.g., a 5thGeneration Core Network (5GC) using a 5GC-compatible network interface protocol such as carrier Ethernet protocol or some other suitable protocol). Network connectivity can be provided to / from the network device 300 via fiber or wireless backhaul. The CN interface circuitry 314 can include one or more specialized processors or FPGAs for communicating using one or more of the aforementioned protocols. In some implementations, the CN interface circuitry 314 can include multiple controllers for providing connectivity to other networks using the same or different protocols.

[0061] To assist with delay-aware scheduling for extended reality (XR), a mechanism for delay status reporting has been specified in Third Generation Partnership Project (3GPP) Release-18 (Rel-18). A delay status reporting medium access control (MAC) control element (CE) is triggered when the remaining time of data in a logical channel (LCH) until the discard timer expires meets a remaining time threshold.

[0062] The report includes information of the remaining time until the discard timer expires (reference point is the start of the uplink shared channel (UL-SCH) for such MAC CE) and the amount of data (i.e., buffer size) considering such remaining time. The delay status report MAC CE structure employed in Rel-18 is shown in the following Figure 5

[0063] Figure 4 An example delay status report (DSR) timing representation 400 is illustrated in accordance with some embodiments. For example, the representation 400 illustrates an example of a delay status reporting procedure in accordance with some embodiments. One or more of the operations illustrated in the representation 400 can be performed by a user equipment (UE), such as the UE 104( Figure 1 ), the UE 106( Figure 1 ), and / or the UE 200( Figure 2 ).

[0064] The representation 400 includes a packet arrival 402. The UE can receive a packet from an upper layer at the packet arrival 402, where the packet is to be transmitted to a base station. In some embodiments, the packet can be received by the UE or a portion thereof from an application layer.

[0065] A discard timer can be started at 404 based on the packet arrival 402. For example, the UE can start the discard timer when the packet is received. The UE can be configured to discard the packet received at the packet arrival 402 when the discard timer expires.

[0066] A buffer delay report can be triggered at 406. The buffer delay report can be triggered based on the remaining time of the discard timer falling below a threshold time. For example, the UE can determine that the remaining time of the discard timer falls below the threshold time. The UE can collect information to be included in the buffer delay report and / or can generate the buffer delay report in response to triggering the buffer delay report in 406.

[0067] The UE can transmit the buffer delay report at 408. For example, the UE can transmit the buffer delay report to the base station at 408. The UE can transmit the buffer delay report at 408 since resources are available to transmit the delay report at 408. The buffer delay report can include an indication of the remaining time 410 of the discard timer at the time the buffer delay report is transmitted. The buffer delay report can facilitate the network scheduling the packet for transmission.

[0068] The discard timer can expire at 412. The UE can determine that the discard timer has expired and discard the packet at 414. At 414, the UE can discard the packet regardless of whether the packet has been transmitted to the base station.

[0069] Figure 5 ​An example DSR MAC CE structure 500 according to some embodiments is illustrated. Structure 500 can have a Rel-18 DSR MAC CE format, where structure 500 is an example of a structure that can be utilized in Rel-18. The MAC CE defined in Rel-18 can allow a UE to report a data volume associated with a minimum remaining time for each logical channel group (LCG).

[0070] Structure 500 can include one or more LCG indication fields 502. LCG indication field 502 can indicate for which LCGs information is included in structure 500. LCG indication field 502 can indicate the presence of delay information for an LCG. An LCG indication field in LCG indication field 502 set to 1 can indicate that delay information for the LCG is reported. An LCG field set to 0 can indicate that delay information for the LCG is not reported.

[0071] Structure 500 can include a section for each LCG indicated by LCG indication field 502. Each section can include a buffer size table indicator field, a remaining time indication field, and a buffer size indication field. For example, in the illustrated embodiment, a first portion corresponding to an LCG includes a first buffer size table indicator field 504, a first remaining time indication field 506, and a first buffer size indication field 508. The buffer size table indicator field can indicate a total amount of delay critical uplink (UL) data for the LCG and / or can indicate a defined table that indicates a buffer size corresponding to the LCG. The remaining time indication field can indicate an amount of time remaining on a discard timer corresponding to the LCG. The buffer size indication can indicate the shortest remaining value of a packet data convergence protocol (PDCP) discardTimer running among all PDCP service data units (SDUs) buffered for the LCG but not yet transmitted in any MAC packet data unit (PDU) at a first symbol of a first physical uplink shared channel (PUSCH) transmission that includes the DSR MAC CE.

[0072] For example, the fields in a DSR MAC CE in DSR MAC CE structure 500 can be defined as follows.

[0073] LCG i This field can indicate the presence of delay information (i.e., the remaining time and buffer size fields) for LCG i . An LCG i field set to 1 can indicate that delay information for LCG i is reported. An LCG i field set to 0 can indicate that delay information for LCG i is not reported.

[0074] Remaining time: This field can indicate the shortest remaining value of the packet data convergence protocol (PDCP) discardTimer running among all PDCP service data units (SDUs) buffered for the LCG but not yet transmitted in any MAC packet data unit (PDU) at the time of the first symbol of the first physical uplink shared channel (PUSCH) transmission that includes this DSR MAC CE. The length of this field can be 6 bits. This field can only be present if the buffer size indicated by the corresponding buffer size field is not zero; otherwise, this field can be reserved and set to 0. If present, the value r in this field can indicate the remaining time in the range of (r, r+1] milliseconds (msec).

[0075] BT: This field can only be present if the corresponding LCG is configured with additionalBS-TableAllowed and the buffer size indicated by the corresponding buffer size field is not zero; otherwise, this field can be reserved and set to 0. If present, the BT field set to 1 can indicate that the value of the buffer size field is set using the buffer sizes specified in Table 6.1.3.1-3 of Technical Specification (TS) 38.323 (3rd Generation Partnership Project; Technical Specification Group Radio Access Network; NR; Packet Data Convergence Protocol (PDCP) Specification (Release 18), (2024), 3GPP TS 38.323, 18.1.0), while the BT field set to 0 can indicate that the buffer sizes specified in Table 6.1.3.1-2 of TS 38.323 are used instead.

[0076] Buffer size: The buffer size field can indicate the total amount of delay-critical uplink (UL) data for the LCG calculated according to the data amount calculation procedures specified in clause 5.5 of TS 38.322 (3rd Generation Partnership Project; Technical Specification Group Radio Access Network; NR; Radio Link Control (RLC) Protocol Specification (Release 18), (2023), 3GPP TS 38.322, 18.0.0) and clause 5.15 of TS 38.323 for the associated radio link control (RLC) entity and PDCP entity, respectively, after the MAC PDU has been built. If the corresponding LCG is configured with additionalBS-TableAllowed and the amount of delay-critical UL data for the LCG is within the buffer sizes specified in Table 6.1.3.1-3, the MAC entity can set the value of this field using the buffer sizes specified in Table 6.1.3.1-3; otherwise, the MAC entity can use Table 6.1.3.1-2 instead. This field can be indicated in the number of bytes. The length of this field can be 8 bits.

[0077] Potential latency status reporting enhancements can be introduced in Release 19 (Rel-19). For example, enhancements to the DSR for extended reality (XR) for Rel-19 can be desirable. In particular, additional information can be included in the DSR MAC CE to provide a more comprehensive view to the base station (such as a next generation NodeB (gNB)) about the buffer status.

[0078] The following directions for enhancements for Rel-19 can be considered. Rel-19 DSR can be enhanced to include multiple (remaining time, buffer size) pairs per LCG. Rel-19 DSR can be enhanced to include multiple buffer size information per LCG corresponding to multiple remaining time threshold levels. Rel-19 DSR can additionally include the amount of data for non-latency critical data (i.e., data with remaining time greater than a threshold). Rel-19 DSR can include a level of importance for latency critical data (e.g., whether the reported latency critical data includes sets of PDUs considered important or less important). Rel-19 DSR can include information of remaining time and amount of latency critical data per logical channel (LCH) (rather than per LCG). Rel-19 DSR can include a total amount of data and multiple remaining time values corresponding to different percentile portions of the total amount of data. One or more of these directions for enhancements can be implemented in different embodiments.

[0079] The importance of enhancing the existing DSR with additional information (e.g., multiple pairs of remaining time / buffer information) can be considered. Whether to include only more information about latency critical data or also information about non-latency critical data can need further study.

[0080] Assuming at least one additional DSR MAC CE format (or additional type of DSR MAC CE) is introduced in addition to the legacy Rel-18 DSR, a method / process for the UE to decide which DSR format (or type) it should select and report when DSR is triggered can be specified.

[0081] Some observations regarding DSR include the following. In legacy methods, DSR enabling is configured per LCG, i.e., the UE triggers DSR only for LCHs in LCGs configured with such mechanism. DSR for an LCH / LCG is triggered when the remaining time of one buffered PDCP SDU drops below the remaining time threshold. Furthermore, in one DSR MAC CE, the UE only reports the DSR information for the LCGs whose LCHs have triggered DSR (i.e., LCGs with pending DSR). Since only one DSR MAC CE format is defined, the UE always reports the delay information based on the same format in Rel-18. Rel-19 can introduce one or more new DSR formats, which can convey more information, potentially with higher signaling overhead. Therefore, the new DSR format can be used for reporting only when needed.

[0082] A potential issue that can arise by introducing one or more new DSR formats can be how the UE selects the DSR MAC CE format when the UE intends to transmit DSR that has been triggered by at least one LCH?

[0083] A first method, which can be referred to as “Method 1,” can include conditional DSR MAC CE format selection. Some assumptions for the first method can include that there can be multiple DSR formats, including the Rel-18 DSR MAC CE format and one or more Rel-19 DSR MAC CE formats. Some DSR MAC CE formats can have fields such as LCH identifier (ID) or LCG ID, instead of a bitmap based on Rel-18. The one or more Rel-19 DSR MAC CE formats can include more or different information and / or more or different fields compared to the Rel-18 DSR MAC CE format.

[0084] When triggering DSR, there are two possible cases. In a first case, the UE can always use a particular DSR MAC CE format (e.g., Rel-18 format or Rel-19 format). Or in a second case, the UE can select the DSR format based on whether certain conditions are met. The conditions can be fixed by specification or pre-configured by the network (e.g., via radio resource control (RRC)). The methods described herein can involve the second case.

[0085] Figure 6 An example procedure 600 for DSR MAC CE format selection is illustrated in accordance with some embodiments. The procedure 600 can be performed by a UE to select a DSR MAC CE format for transmission of DSR. The procedure 600 can be performed as part of the first method.

[0086] The process 600 can begin, at 602. The process 600 can include, at 604, at least one LCH or LCG having a triggered delay status report. For example, a remaining time of a discard timer of the at least one LCH or LCG can be less than a threshold time. The trigger of the delay status report can include one or more of the features of the trigger of the buffer status report in 406 Figure 4 ). The trigger of the delay status report can indicate that a DSR is to be generated and / or transmitted to the base station.

[0087] The process 600 can include, at 606, determining whether a particular condition is satisfied. For example, the UE can determine whether a particular condition related to the DSR is satisfied. In some embodiments, the UE can determine a characteristic related to the DSR to determine whether the particular condition related to the DSR is satisfied. In some embodiments, the condition can relate to one or more of: an amount of buffered data of the LCH and / or LCG that triggered the DSR, one or more remaining time values of the buffered data of the LCH and / or LCG that triggered the DSR, one or more configurations of the delay status report of the LCH and / or LCG that triggered the DSR, a number of the LCH and / or LCG that triggered the DSR, one or more importance levels of the buffered data of the LCH and / or LCG that triggered the DSR, a number of padding bits in a radio resource to be used to transmit the DSR, a size of the radio resource to be used to transmit the DSR, and / or a type of the radio resource to be used to transmit the DSR. If the condition is not satisfied, the process 600 can proceed to 608. If the condition is satisfied, the process 600 can proceed to 610.

[0088] At 608, the process 600 can report the DSR using a first DSR MAC CE format. In some embodiments, the first DSR MAC CE format can be a legacy Rel-18 DSR MAC CE format. The UE can generate the DSR according to the first DSR MAC CE format and / or transmit the DSR to the base station.

[0089] At 610, the process 600 can report the DSR using a second DSR MAC CE format. In some embodiments, the second DSR MAC CE format can be a Rel-19 DSR MAC CE format. The second DSR MAC CE format can include additional information and / or additional fields compared to the first DSR MAC CE format. The UE can generate the DSR according to the second DSR MAC CE format and / or transmit the DSR to the base station.

[0090] The condition for determining the DSR MAC CE format to be used for DSR can be based on at least one of the following. A first condition can be the number of LCGs / LCHs for which DSR has been triggered. As a first example of the first condition, when there is only one LCG for which DSR has been triggered, the UE can use the first DSR MAC CE, and when there are multiple LCGs for which DSR has been triggered, the UE can use the second DSR MAC CE. As a second example of the first condition, when there are less than N LCGs for which DSR has been triggered, the UE can use the first DSR MAC CE, and when there are N or more LCGs for which DSR has been triggered, the UE can use the second DSR MAC CE, N being a configured number.

[0091] A second condition can include that a particular LCG / LCH has triggered DSR. As a first example of the second condition, one or more LCHs / LCGs can have been configured to enable the first DSR MAC CE format. When at least one (or more) of these LCHs / LCGs has triggered DSR, the UE can use the first DSR MAC CE format. Otherwise, if none of these LCHs / LCGs has triggered DSR, the UE can use the second DSR MAC CE format when DSR is triggered by any other LCH / LCG.

[0092] As a second example of the second condition, when at least one (or more) LCH / LCG with priority higher / lower than a threshold has triggered DSR, the UE can use the first DSR MAC CE format. Otherwise, the UE can use the second DSR MAC CE format.

[0093] As a third example of the second condition, when at least one (or more) LCH / LCG with amount of delay critical (or non-delay critical) data greater than / less than a threshold (or in a range) has triggered DSR, the UE can use the first DSR MAC CE format. Otherwise, the UE can use the second DSR MAC CE format.

[0094] In some embodiments, DSR MAC CE format selection can be based on distribution of (delay critical) data volume in different remaining time ranges. Suppose multiple remaining threshold levels are defined, and each LCH / LCG can have different data volume associated with different “remaining time range” or “remaining time threshold” such as: data volume with remaining time less than 5 milliseconds (ms): 800 kilobytes (K); data volume with remaining time between 5 ms and 10 ms: 200 K; and data volume with remaining time between 10 ms and 20 ms: 500 K. For example, in this embodiment, data volume less than 5 ms can have a threshold of 800 K, data volume with remaining time between 5 ms and 10 ms can have a threshold of 200 K, and data volume with remaining time between 10 ms and 20 ms can have a threshold of 500 K.

[0095] The UE can select a DSR format based on data volume in each remaining time range of one or more LCHs / LCGs. For example, if DSR triggered by at least one LCH / LCG has data volume above a threshold (e.g., zero) in more than one pre-defined remaining time range, the DSR can be reported based on a first DSR MAC CE format. Otherwise, the DSR can be reported based on a second DSR MAC CE format. There can be many other examples of the UE selecting a DSR format based on data volume in each remaining time range of one or more LCHs / LCGs. In one example, the UE can select a DSR format based on at least one difference in values between multiple data volumes corresponding to multiple remaining time thresholds or remaining time ranges.

[0096] In some embodiments, DSR MAC CE format selection can be based on distribution of remaining time values of buffered data. For example, if a difference between maximum remaining time and minimum remaining time exceeds a threshold, the UE can select a first DSR format. Otherwise, the UE can select a second DSR format. As another example, if remaining times of all buffered data are the same, the UE can select a first DSR format. Otherwise, the UE can select a second DSR format.

[0097] In some embodiments, the UE can report two DSR MAC CEs for different subsets of LCGs / LCHs, one based on a first DSR MAC CE format and one based on a second DSR MAC CE format.

[0098] The two DSR MAC CEs can be transmitted using the same or different MAC PDUs. In some embodiments, the UE can select a DSR MAC CE based on uplink grant size. If the uplink grant size is larger than a threshold, the first DSR MAC CE format can be used for reporting. Otherwise, the second DSR MAC CE format can be used for reporting.

[0099] In some embodiments, the UE can use padding bits (if available after data multiplexing) in uplink shared channel (UL-SCH) resources to report the DSR MAC CE. If the number of padding bits is sufficient for the first DSR MAC CE format, the first DSR MAC CE format can be used for reporting. Otherwise, the second DSR MAC CE format can be used for reporting.

[0100] In some embodiments, the UE can select the DSR MAC CE format based on whether the buffer delay critical data includes important (or less important) packets (e.g., PDU sets with PDU set importance above / below a threshold). If the buffer delay critical data includes important packets, the UE can select the first DSR MAC CE format to report the DSR. Otherwise, the second DSR MAC CE format can be used for reporting.

[0101] In some embodiments, the UE can select the DSR MAC CE format based on quality of service (QoS) requirements (e.g., target reliability and / or packet delay budget) of the data flow corresponding to the LCH that triggered the DSR.

[0102] In some embodiments, the UE can select the DSR MAC CE based on channel quality of the serving cell in which the MAC PDU (which can include the DSR MAC CE) is to be transmitted. For example, if the signal to interference plus noise ratio (SINR) / reference signal received power (RSRP) / reference signal received quality (RSRQ) is above a threshold, the first DSR MAC CE format can be used for reporting. Otherwise, if the SINR / RSRP / RSRQ is below a threshold, the second DSR MAC CE format can be used for reporting.

[0103] In some embodiments, the DSR MAC CE format can be flexible in terms of the fields to be included in the MAC CE (hence the size of such MAC CE is variable). In such cases, some indicators / fields can be included in the MAC CE to indicate whether the MAC CE is to include additional fields as well. This can be achieved by including one or more bits / fields in the MAC CE to indicate the “presence,” “extension,” and / or “type” of information to be reported in the DSR.

[0104] In some embodiments, for logical channel prioritization (LCP) procedures, different DSR MAC CE formats can have different priority orders. For example, the first DSR MAC CE format can have a higher priority than the second DSR MAC CE format.

[0105] In some embodiments, a UE can select a DSR MAC CE format based on an uplink grant type of a MAC PDU for a DSR MAC CE transmission. For example, a UE can select a DSR MAC CE format based on whether a grant is a dynamic grant or a configured grant. For example, a UE can be only allowed to report a first DSR MAC CE format on a configured grant, but not on a dynamic grant. Thus, in this example, the UE can report a second DSR MAC CE format on a dynamic grant.

[0106] For another example, a UE can select a DSR MAC CE format based on a particular configured grant configuration. For example, a UE can be only allowed to report a first DSR MAC CE format on resources of a particular configured grant configuration. Thus, the UE can report a second DSR MAC CE format on other resources except the particular configured grant configuration.

[0107] For another example, a UE can select a DSR MAC CE format based on a dynamic grant with a particular Layer 1 (L1) priority. For example, a UE can be only allowed to report a first DSR MAC CE format on a dynamic grant with a higher L1 priority. Thus, the UE can report a second DSR MAC CE format on a dynamic grant without a higher L1 priority and / or a non-dynamic grant.

[0108] In some embodiments, a base station can transmit dynamic signaling (e.g., a MAC CE or downlink control information (DCI)) to explicitly / implicitly indicate a UE to switch a DSR MAC CE format. A base station can pre-configure a default DSR MAC CE format via radio resource control (RRC) and switch the format using dynamic signaling. In some embodiments, a UE can sometimes autonomously fall back to the default DSR MAC CE after receiving such dynamic signaling.

[0109] In some embodiments, a UE can periodically report DSR using a first DSR MAC CE format or type, while reporting DSR based on an aperiodic triggering event using a second DSR MAC CE format or type. In one example, a UE can be configured to report a Rel-18 DSR MAC CE based on a pre-configured periodicity, and report a Rel-19 DSR MAC CE only when a condition is met.

[0110] In a first option of the second method (which can be referred to as “Method 2a”), a DSR MAC CE format can include an indication of a “level of detail” for each LCG in a single MAC CE.

[0111] The assumption of the first option of the second method can be that multiple LCGs have triggered DSR and the UE can transmit one MAC CE to report the DSR for all these LCGs. For some of these LCGs, “simplified” delay information can be sufficient. For example, all buffered PDCP SDUs in an LCG can have the same remaining time, so only one pair of remaining time value and buffer size information can be needed for this LCG (this can correspond to the first level of detail). For some of these LCGs, “more detailed” delay information can be needed. For example, the buffered PDCP SDUs in an LCG can have very different remaining times, so multiple pairs of remaining time value and buffer size information can be needed for the DSR for this LCG (this can correspond to the second level of detail). The problem to be solved by the first option of the second method can be how to include the DSR for these LCGs with different “level of detail” requirements in the same DSR MAC CE.

[0112] For the first option of the second method, a new bitmap can be included in the DSR MAC CE to indicate the “level of detail” of the DSR for each LCG to be reported. It can be assumed that in some implementations only two levels of detail are implemented, so 1 bit is sufficient for one LCG. However, this does not exclude the case where more than two levels of detail and / or more than 1 bit are used.

[0113] Figure 7 An example DSR MAC CE structure 700 according to some embodiments is illustrated. The structure 700 can implement the bitmap included in the DSR MAC CE of the first option of the second method. The structure 700 can have the Rel-19 DSR MAC CE format and / or can include one or more features of the Rel-19 DSR MAC CE format.

[0114] The structure 700 can include one or more LCG indication fields 702. The LCG indication fields 702 can form a bitmap. The bitmap can indicate which LCGs are involved in this DSR MAC CE (this field is the same as the legacy field). The LCG indication fields 702 can include one or more of the features of the LCG indication field 502( Figure 5 ) of the Rel-19 DSR MAC CE. For example, the LCG indication fields 702 can indicate the presence of delay information for an LCG. An LCG indication field in the LCG indication fields 702 being set to 1 can indicate that delay information for the LCG is reported. The LCG field being set to 0 can indicate that no delay information for the LCG is reported.

[0115] Structure 700 can include a bitmap 704 that includes one or more detail level fields. Bitmap 704 can include a detail level field corresponding to each of the LCGs. For example, bitmap 704 can include a detail level field that corresponds one-to-one with LCG indication field 702. The detail level field can indicate a level of detail provided in the DSR section of the corresponding LCG. For example, bitmap 704 can indicate the “detail level” of the DSR for each LCG to be reported. Detail level field value 1 can indicate more detail (e.g., more than one pair of remaining time value and buffer size). Detail level field value 0 can indicate less detail (e.g., only one pair of remaining time value and buffer size). DSRs with different levels of detail can require different numbers of bytes.

[0116] Structure 700 can include one or more DSRs 706 for one or more LCGs. Structure 700 can include a DSR for each of the LCGs for which LCG indication field 702 indicates that delay information is present. The size (in terms of number of bytes) of the DSRs can differ based on the level of detail corresponding to the DSR, as indicated by bitmap 704. As an example, in the illustrated embodiment, DSRs 706 can include a DSR 708 for the ith LCG. As an example, DSR 708 for the ith LCG can have M or N bytes, depending on whether it is a “more detailed” or a “less detailed” DSR, where M can not equal N. Each DSR can include one or more remaining times and / or one or more buffer sizes. The buffer size can correspond to a delay critical data amount or an all data amount of a buffer for the LCG.

[0117] As a first option of the second method, the indication of the “detail level” can be per LCG in a single MAC CE.

[0118] A DSR MAC CE with DSRs for multiple LCGs can have an indicator included in the DSR for each LCG that indicates whether the DSR is based on a more detailed format or a basic format. Different DSRs for different LCGs in one MAC CE can take different numbers of bytes / bits depending on their “detail level”. The “location” of this indicator can be anywhere within the DSR.

[0119] Figure 8 Another example DSR MAC CE structure 800 is illustrated, in accordance with some embodiments. Structure 800 can implement a detail level per LCG in the DSR. Structure 800 can have a Rel-19 DSR MAC CE format and / or can include one or more features of a Rel-19 DSR MAC CE format.

[0120] Structure 800 can include one or more LCG indication fields 802. LCG indication fields 802 can form a bitmap. The bitmap can indicate which LCGs are involved in the DSR MAC CE (the field is the same as the legacy field). LCG indication fields 802 can include one or more of the features of LCG indication field 502 Figure 5

[0121] Structure 800 can include one or more DSRs. Structure 800 can include a DSR for each LCG that LCG indication fields 802 indicate has delay information present. A first DSR 804, a second DSR 806, and a third DSR 808 are illustrated in the illustrated embodiment. Each of first DSR 804, second DSR 806, and third DSR 808 can correspond to a different LCG.

[0122] Each of the DSRs can include a detail level field that indicates a level of detail for the corresponding DSR. For example, in the illustrated embodiment, first DSR 804 includes a first detail level field 810, second DSR 806 includes a second detail level field 812, and third DSR 808 includes a third detail level field 814. The size (in terms of number of bytes) of a DSR can differ based on the level of detail corresponding to the DSR, as indicated by the DSR. As an example, first detail level field 810 and second detail level field 812 indicate that first DSR 804 and second DSR 806 are less detailed DSRs in the illustrated embodiment. First DSR 804 and second DSR 806 can each have N bytes based on being less detailed. Third detail level field 814 indicates that third DSR 808 is a more detailed DSR in the illustrated embodiment. Third DSR 808 can have M bytes based on being more detailed, where M has a value that is greater than the value of N. Each DSR can include one or more remaining times and / or one or more buffer sizes (e.g., buffer sizes corresponding to different remaining time thresholds).

[0123] In a second option of the second method (which can be referred to as “Method 2b”), the DSR MAC CE format can include a “BS table selection” for different data parts.

[0124] ​The assumption for the second option of the second method can be that in the DSR MAC CE, the UE needs to report multiple buffer size (BS) values for different parts of data buffered in one LCG, such as buffer sizes corresponding to different remaining time thresholds. For example, the BS corresponding to PDCP SDUs with remaining time in a certain range can be reported as 800K for data with remaining time less than 5ms, 200K for data with remaining time between 5ms and 10ms, and 500K for data with remaining time between 10ms and 20ms. Depending on the amount of data in each part, a different BS table can be selected for reporting. If the amount of data falls into the range of Table 6.1.3.1-3 in TS 38.321, Table 6.1.3.1-3 can be used. Otherwise, Table 6.1.3.1-2 can be used.

[0125] For the second option of the second method, a bitmap can be included in the DSR MAC CE to indicate the “BS table selection” of multiple BS values to be reported for the DSR of one LCG to be reported. The first bit can represent the BS table for the first part of data in the LCG, the second bit can represent the BS table for the second part of data in the LCG, and so on. When the DSR MAC CE is intended to indicate the DSR of multiple LCGs, multiple bitmaps (one bitmap per LCG) can be included.

[0126] Figure 9 An example process 900 for generating a DSR is illustrated in accordance with some embodiments. The DSR can be generated according to a determined DSR MAC CE format. Process 900 can be performed by a UE, such as UE 104( Figure 1 ), UE 106( Figure 1 ), and / or UE 200( Figure 2 ).

[0127] Process 900 can include identifying a DSR trigger for a DSR, at 902.

[0128] Process 900 can include determining a DSR MAC CE format or type for the DSR, at 904. For example, the UE can determine the DSR MAC CE format or type for the DSR based at least in part on one or more characteristics related to the DSR.

[0129] In some embodiments, determining the DSR MAC CE format or type can include determining whether a condition for the DSR is satisfied, where the DSR MAC CE format is determined based at least in part on whether it is determined that the condition is satisfied. In some embodiments, the condition can relate to which logical channel (LCH) or logical channel group (LCG) triggered the DSR, one or more buffer data volumes of one or more LCHs or one or more LCGs that triggered the DSR, one or more remaining time values of buffer data of one or more LCHs or one or more LCGs that triggered the DSR, one or more configurations of delay status reporting of one or more LCHs or one or more LCGs that triggered the DSR, a number of one or more LCHs or one or more LCGs that triggered the DSR, one or more importance levels of buffer data of one or more LCHs or one or more LCGs that triggered the DSR, a number of padding bits in a radio resource to be used to transmit the DSR, a size of a radio resource to be used to transmit the DSR, or a type of a radio resource to be used to transmit the DSR.

[0130] In some embodiments, determining the DSR MAC CE format or type can include determining whether a number of logical channel groups (LCGs) or logical channels (LCHs) that triggered the DSR exceeds a threshold number of LCGs or LCHs, determining whether the LCGs or LCHs that triggered the DSR are configured for a particular MAC CE format, determining whether the LCGs or LCHs that triggered the DSR have a priority that is higher than a threshold priority, or determining whether the LCGs or LCHs that triggered the DSR have a delay critical data volume or a non-delay critical volume that is greater than a threshold.

[0131] In some embodiments, determining the DSR MAC CE format or type can include determining whether a buffer size associated with a remaining time range or a remaining time threshold of the DSR exceeds a threshold data volume, or determining whether a number of remaining time ranges in the DSR that are associated with a data volume exceeding a threshold data volume exceeds a threshold number.

[0132] In some embodiments, determining the DSR MAC CE format or type can include determining a difference between two remaining time values of the DSR, and determining whether the difference exceeds a threshold difference.

[0133] In some embodiments, determining the DSR MAC CE format or type can include determining the DSR MAC CE format based at least in part on whether an uplink grant size for the DSR is greater than an uplink grant size threshold, determining the DSR MAC CE format based at least in part on a number of padding bits in uplink shared channel (UL-SCH) resources for the DSR, determining the DSR MAC CE format based at least in part on whether a buffer delay critical data of the DSR includes important packets, or determining the DSR MAC CE format based at least in part on quality of service (QoS) requirements of data flows corresponding to one or more logical channels (LCHs) that triggered the DSR.

[0134] In some embodiments, determining the DSR MAC CE format or type can include determining the DSR MAC CE format based at least in part on a channel quality of a serving cell in which a MAC packet data unit (PDU) including the DSR is to be transmitted, or determining the DSR MAC CE format based at least in part on an uplink grant type used to transmit the DSR.

[0135] In some embodiments, the DSR MAC CE format or type can include one or more bits or fields indicating information to be reported in the DSR. Further, in some embodiments, process 900 can include identifying an indication of a DSR MAC CE format received from a base station, where the DSR MAC CE format is determined based at least in part on the indication.

[0136] Process 900 can include generating a DSR at 906. For example, the UE can generate a DSR according to a DSR MAC CE format for transmission.

[0137] In some embodiments, the DSR MAC CE format can be a first DSR MAC CE format, where the first DSR MAC CE format is determined for a first subset of LCGs or LCHs used for the DSR. Further, generating the DSR can include generating a first portion of the DSR corresponding to the first subset according to the first DSR MAC CE format. The method can further include determining a second DSR MAC CE format for a second subset of LCGs or LCHs used for the DSR, where generating the DSR includes generating a second portion of the DSR corresponding to the second subset according to the second DSR MAC CE format.

[0138] In an embodiment, Figure 9Any one or more of the operations in the method described above can be performed in an order different from the order described, and / or one or more operations can be performed concurrently. Further, it should be understood that in other embodiments, one or more of the operations described above can be omitted, and / or one or more additional operations can be added to the method 900.

[0139] Figure 10 An example process 1000 for generating a DSR is illustrated in accordance with some embodiments. The DSR can be generated in accordance with a determined DSR MAC CE format. The process 1000 can be performed by a UE, such as the UE 104( Figure 1 ), the UE 106( Figure 1 ), and / or the UE 200( Figure 2 ).

[0140] The process 1000 can include identifying a DSR trigger for the DSR, at 1002.

[0141] The process 1000 can include determining a DSR MAC CE format for the DSR, at 1004. The DSR MAC CE format can include one or more detail level indicators to indicate a level of detail for each logical channel group (LCG) to be reported in the DSR; or one or more buffer size (BS) table selection indicators to indicate one or more BS tables for one or more data portions of one or more LCGs for the DSR. In some embodiments, determining the DSR MAC CE format can include determining a field to indicate a DSR format for LCGs in the DSR MAC CE.

[0142] In some embodiments, the DSR MAC CE format can include one or more detail level indicators, and wherein the one or more detail level indicators include a bitmap indicating a level of detail for each of the LCGs to be reported in the DSR. Further, in some embodiments, the DSR MAC CE format can include one or more BS table selection indicators, wherein the DSR is to include information for multiple LCGs, and wherein the one or more BS table selection indicators include multiple bitmaps for the multiple LCGs.

[0143] In some embodiments, the DSR MAC CE format can include one or more BS table selection indicators, and wherein the one or more BS table selection indicators include a bitmap indicating a BS table selection for one or more BS values to be reported for an LCG of the one or more LCGs. In some of these embodiments, the bitmap includes a first bit for a first data portion of the LCG and a second bit for a second data portion of the LCG.

[0144] The process 1000 can generate the DSR in 1006. For example, the UE can generate the DSR according to the DSR MAC CE format for transmission.

[0145] In embodiments, Figure 10 Any one or more of the operations in can be performed in a different order than shown and / or one or more of the operations can be performed concurrently. Also, it is to be understood that one or more of the operations in can be omitted in other embodiments, and / or one or more additional operations can be added to the process 1000.

[0146] Figure 11 An example process 1100 for indicating a DSR MAC CE format to utilize is illustrated in accordance with some embodiments. The process 1100 can be performed by a base station such as the base station 108( Figure 1 ) and / or the network device 300( Figure 3 ).

[0147] The process 1100 can include determining a DSR MAC CE format for a UE in 1102.

[0148] In some embodiments, the DSR MAC CE format can be a first DSR MAC CE format, where the process 1100 can further include configuring the UE with a second DSR MAC CE format, and where the dynamic signal can reconfigure the UE from the second DSR MAC CE format to the first DSR MAC CE format. In some embodiments, the UE can be configured with the second DSR MAC CE format via RRC signaling.

[0149] The process 1100 can include generating a dynamic signal for transmission to the UE in 1104, the dynamic signal indicating that the UE is to utilize the DSR MAC CE format. In some embodiments, the dynamic signal can include a MAC CE signal or a downlink control information (DCI) signal.

[0150] In embodiments, Figure 11 Any one or more of the operations in can be performed in a different order than shown and / or one or more of the operations can be performed concurrently. Also, it is to be understood that one or more of the operations in can be omitted in other embodiments, and / or one or more additional operations can be added to the process 1100.

[0151] It is well understood that the use of personally identifiable information should follow privacy policies and practices that are generally recognized as meeting or exceeding industry or governmental requirements for maintaining the privacy of users. In particular, the data relating to personally identifiable information should be managed and processed so as to minimize the risk of unintended or unauthorized access or use, and the nature of authorized use should be clearly explained to the users.

[0152] For one or more embodiments, at least one component of the components illustrated in one or more of the preceding figures can be configured to perform one or more operations, techniques, processes, or methods set forth in the Examples section below. For example, the baseband circuitry described above in connection with one or more of the preceding figures can be configured to operate according to one or more of the examples described below. In another example, circuitry associated with a UE, base station, network element, etc. described above in connection with one or more of the preceding figures can be configured to operate according to one or more of the examples set forth in the Examples section below.

[0153] Example

[0154] In the following sections, additional example embodiments are provided.

[0155] Example 1 can include a method comprising: identifying a delay status report (DSR) trigger for a DSR; determining a DSR medium access control (MAC) control element (CE) format or type for the DSR based at least in part on one or more characteristics related to the DSR; and generating the DSR according to the DSR MAC CE format for transmission.

[0156] Example 2 can include the method of Example 1, wherein determining the DSR MAC CE format or type comprises: determining whether a condition for the DSR is satisfied, wherein the DSR MAC CE format is determined based at least in part on whether it is determined that the condition is satisfied.

[0157] Example 3 can include the method of Example 2, wherein the condition relates to: which logical channel (LCH) or logical channel group (LCG) triggered the DSR; one or more buffer data volumes of one or more LCHs or one or more LCGs that triggered the DSR; one or more remaining time values of buffer data of one or more LCHs or one or more LCGs that triggered the DSR; one or more configurations of delay status reporting of one or more LCHs or one or more LCGs that triggered the DSR; a number of one or more LCHs or one or more LCGs that triggered the DSR; one or more importance levels of buffer data of one or more LCHs or one or more LCGs that triggered the DSR; a number of padding bits to be used in a radio resource for transmitting the DSR; a size of a radio resource to be used for transmitting the DSR; or a type of a radio resource to be used for transmitting the DSR.

[0158] Example 4 can include the method of Example 1, wherein determining the DSR MAC CE format or type comprises: determining whether a number of logical channel groups (LCGs) or logical channels (LCHs) that triggered the DSR exceeds a threshold number of LCGs or LCHs; determining whether the LCGs or LCHs that triggered the DSR are configured for a particular MAC CE format; determining whether the LCGs or LCHs that triggered the DSR have a priority that is higher than a threshold priority; or determining whether the LCGs or LCHs that triggered the DSR have a delay critical data volume or a non-delay critical volume that is greater than a threshold.

[0159] Example 5 can include the method of Example 1, wherein determining the DSR MAC CE format or type comprises: determining whether a buffer size associated with a remaining time range or a remaining time threshold of the DSR exceeds a threshold data volume; or determining whether a number of remaining time ranges in the DSR that are associated with a data volume exceeding a threshold data volume exceeds a threshold number.

[0160] Example 6 can include the method of Example 1, wherein determining the DSR MAC CE format comprises: determining a difference between two remaining time values of the DSR; and determining whether the difference exceeds a threshold difference.

[0161] Example 7 can include the method of Example 1, wherein the DSR MAC CE format is a first DSR MAC CE format, wherein the first DSR MAC CE format is determined for a first subset of LCGs or LCHs for the DSR, wherein generating the DSR includes generating a first portion of the DSR corresponding to the first subset according to the first DSR MAC CE format, and wherein the method further includes determining a second DSR MAC CE format for a second subset of LCGs or LCHs for the DSR, wherein generating the DSR includes generating a second portion of the DSR corresponding to the second subset according to the second DSR MAC CE format.

[0162] Example 8 can include the method of Example 1, wherein determining the DSR MAC CE format or type includes determining the DSR MAC CE format based at least in part on whether an uplink grant size for the DSR is greater than an uplink grant size threshold, determining the DSR MAC CE format based at least in part on a number of padding bits in uplink shared channel (UL-SCH) resources for the DSR, determining the DSR MAC CE format based at least in part on whether a buffer delay critical data of the DSR includes important packets, or determining the DSR MAC CE format based at least in part on quality of service (QoS) requirements of data flows corresponding to one or more logical channels (LCHs) that triggered the DSR.

[0163] Example 9 can include the method of Example 1, wherein determining the DSR MAC CE format or type includes determining the DSR MAC CE format based at least in part on a channel quality of a serving cell in which a MAC packet data unit (PDU) including the DSR is to be transmitted, or determining the DSR MAC CE format based at least in part on an uplink grant type used to transmit the DSR.

[0164] Example 10 can include the method of Example 1, wherein the DSR MAC CE format includes one or more bits or fields indicating information to be reported in the DSR.

[0165] Example 11 can include the method of Example 1, further comprising identifying an indication of the DSR MAC CE format received from a base station, wherein the DSR MAC CE format is determined based at least in part on the indication.

[0166] Example 12 can include the method of Example 1, wherein the DSR MAC CE format or type includes one or more remaining time / buffer size pairs per logical channel group (LCG).

[0167] Example 13 can include a method comprising: identifying a delay status report (DSR) trigger for a DSR; determining a DSR medium access control (MAC) control element (CE) format for the DSR, the DSR MAC CE format including: one or more detail level indicators to indicate a detail level per logical channel group (LCG) to be reported in the DSR; or one or more buffer size (BS) table selection indicators to indicate one or more BS tables for one or more data portions of one or more LCGs of the DSR; and generating the DSR in accordance with the DSR MAC CE format for transmission.

[0168] Example 14 can include the method of Example 13, the DSR MAC CE format including the one or more detail level indicators, and wherein the one or more detail level indicators include a bitmap indicating the detail level per one of to be reported in the DSR.

[0169] Example 15 can include the method of Example 13, wherein the DSR MAC CE format includes the one or more BS table selection indicators, and wherein the one or more BS table selection indicators include a bitmap indicating BS table selection for one or more BS values to be reported for an LCG of the one or more LCGs.

[0170] Example 16 can include the method of Example 15, wherein the bitmap includes a first bit for a first data portion of the LCG and a second bit for a second data portion of the LCG.

[0171] Example 17 can include the method of Example 13, wherein the DSR MAC CE format includes the one or more BS table selection indicators, wherein the DSR includes information for a plurality of LCGs, and wherein the one or more BS table selection indicators include a plurality of bitmaps for the plurality of LCGs.

[0172] Example 18 can include a method comprising: determining a delay status report (DSR) medium access control (MAC) control element (CE) format for a user equipment (UE); and generating a dynamic signal for transmission to the UE, the dynamic signal indicating that the UE is to utilize the DSR MAC CE format.

[0173] Example 19 can include the method of Example 18, wherein the dynamic signal comprises a MAC CE signal or a downlink control information (DCI) signal.

[0174] Example 20 can include the method of Example 18, wherein the DSR MAC CE format is a first DSR MAC CE format, wherein the method further comprises configuring the UE with a second DSR MAC CE format, and wherein the dynamic signal reconfigures the UE from the second DSR MAC CE format to the first DSR MAC CE format.

[0175] Example 21 can include the method of Example 20, wherein the UE is configured with the second DSR MAC CE format via radio resource control (RRC) signaling.

[0176] Example 22 can include an apparatus comprising means for performing one or more elements of a method described in or related to any of Examples 1-21, or any other method or process described herein.

[0177] Example 23 can include one or more non-transitory computer-readable media comprising instructions to cause an electronic device, upon execution of the instructions by one or more processors of the electronic device, to perform one or more elements of a method described in or related to any of Examples 1-21, or any other method or process described herein.

[0178] Example 24 can include an apparatus comprising logic, modules, or circuitry to perform one or more elements of a method described in or related to any of Examples 1-21, or any other method or process described herein.

[0179] Example 25 can include a method, technique, or process as described in or related to any of Examples 1-21, or portions or combinations thereof.

[0180] Example 26 can include an apparatus comprising: one or more processors; and one or more computer-readable media comprising instructions to cause the one or more processors to perform a method, technique, or process as described in or related to any of Examples 1-21, or portions thereof, when executed by the one or more processors.

[0181] Example 27 can include a signal as described in or related to any of Examples 1-21, or portions or combinations thereof.

[0182] Example 28 can include a datagram, information element, packet, frame, segment, PDU, or message, or portions or components thereof, according to any of Examples 1-21, or otherwise described in the present disclosure.

[0183] Example 29 can include a signal encoded with data, or portions or components thereof, according to any of Examples 1-21, or otherwise described in the present disclosure.

[0184] Example 30 can include a signal encoded with a datagram, IE, packet, frame, segment, PDU, or message, or portions or components thereof, according to any of Examples 1-21, or otherwise described in the present disclosure.

[0185] Example 31 can include an electromagnetic signal carrying computer-readable instructions, wherein execution of the computer-readable instructions by one or more processors will cause the one or more processors to perform a method, technique, or process as described in or related to any of Examples 1-21, or portions or components thereof.

[0186] Example 32 can include a computer program comprising instructions, wherein execution of the program by a processing element will cause the processing element to perform a method, technique, or process as described in or related to any of Examples 1-21, or portions or components thereof.

[0187] Example 33 can include a signal in a wireless network as shown and described herein.

[0188] Example 34 can include a method of communicating in a wireless network as shown and described herein.

[0189] Example 35 can include a system for providing wireless communication as shown and described herein.

[0190] Example 36 can include an apparatus for providing wireless communication as shown and described herein.

[0191] Any of the above examples can be combined with any other example (or combination of examples), unless explicitly stated otherwise. The foregoing description of one or more implementations provides a description with reference to which variations and modifications can be based. Variations and modifications can be based on the description as set forth herein, as well as the description as set forth in the figures and / or the claims.

[0192] While the implementations described above have been described in connection with certain examples, it is to be understood that the above description is meant to be illustrative only and not limiting. The steps of the disclosed methods may, in some cases, be carried out in a different order, be combined or divided into sub-steps or be carried out concurrently with each other. The various examples disclosed herein can be implemented in hardware and / or in software (including firmware, resident software, micro-code, etc.). Furthermore, the foregoing description for any aspects of the implementations is provided by way of example only. Nothing limiting the various examples described herein is implied by the description as set forth herein. Accordingly, there is no intention in any way limiting the described examples to the examples described. Accordingly, the disclosure of any priorities is hereby incorporated by reference herein in its entirety.

Claims

1. A method comprising: identifying a trigger for a delay status report (DSR); and generating, based at least in part on the trigger, a DSR medium access control (MAC) control element (CE) for transmission of a plurality of DSRs, the DSR MAC CE comprising a field providing information about pairs of a remaining time value and a buffer size of the DSR MAC CE.

2. The method of claim 1, wherein the DSR MAC CE further comprises one or more buffer size values for data of one or more logical channel groups (LCGs) corresponding to one or more of the plurality of DSRs.

3. The method of claim 1 or claim 2, wherein the DSR MAC CE for the plurality of DSRs is generated based at least in part on a size of resources for the DSR MAC CE.

4. The method of claim 1 or claim 2, wherein the field is a first field corresponding to a first DSR of the DSR MAC CE, and wherein the information about pairs of a remaining time value and a buffer size is information for pairs of a remaining time value and a buffer size for one or more DSRs after the first DSR.

5. The method of claim 4, wherein the DSR MAC CE further comprises a second field corresponding to a second DSR of the DSR MAC CE, the second field providing information for pairs of a remaining time value and a buffer size after the second DSR.

6. The method of claim 1 or claim 2, wherein the field corresponds to a first DSR, and wherein the field indicates a number of bytes of the first DSR.

7. The method of claim 1 or claim 2, wherein the DSR MAC CE further comprises one or more logical channel group (LCG) indication fields, wherein each of the one or more LCG indication fields indicates delay information for a corresponding LCG.

8. The method of claim 1 or claim 2, wherein identifying the trigger comprises: identifying that a remaining time for a logical channel (LCH) or logical channel group (LCG) is less than a threshold time.

9. A method comprising: identifying a received DSR medium access control (MAC) control element (CE) for a plurality of delay status reports (DSRs); identifying a value of a field of the DSR MAC CE, the field providing information about pairs of a remaining time value and a buffer size of the DSR MAC CE; and processing the DSR MAC CE according to the value within the field.

10. The method of claim 9, further comprising identifying one or more buffer sizes of the DSR MAC CE for one or more logical channel groups (LCGs) of the DSR MAC CE, wherein the DSR MAC CE is processed according to the one or more buffer sizes.

11. The method of claim 9 or claim 10, wherein the field is a first field corresponding to a first DSR of the DSR MAC CE, the method further comprising: determining, based at least in part on the value of the first field, one or more pairs of a remaining time value and a buffer size for one or more DSRs following the first DSR, wherein the DSR MAC CE is processed according to the determined one or more pairs of remaining time value and buffer size.

12. The method of claim 9 or claim 10, wherein the field corresponds to a first DSR of the plurality of DSRs, and wherein the method further comprises: determining, based at least in part on the value of the field, a number of bytes of the first DSR, wherein the DSR MAC CE is processed according to the determined number of bytes.

13. The method of claim 9 or claim 10, the method further comprising: identifying a value of a logical channel group (LCG) indication field of the DSR MAC CE, the LCG indication field corresponding to an LCG of the DSR MAC CE; and determining, based at least in part on the value of the LCG indication field, delay information for the LCG.

14. The method of claim 9 or claim 10, the method further comprising: generating, for transmission, a dynamic signal indicating a DSR MAC CE format to be used for the DSR MAC CE.

15. The method of claim 9 or claim 10, wherein the DSR MAC CE has a first DSR MAC CE format, and wherein the method further comprises: generating, for transmission, a DSR MAC CE configuration for configuring a UE with a second DSR MAC CE format; and generating, for transmission, a dynamic signal to reconfigure the UE from the first DSR MAC CE format to the second DSR MAC CE format.

16. One or more computer-readable media having instructions that, when executed, cause processing circuitry to: identify a trigger for a delay status report (DSR); determine a DSR medium access control (MAC) control element (CE) format for the DSR, the DSR MAC CE format being for a plurality of DSRs; and generate, based at least in part on the trigger, a DSR MAC CE of the DSR MAC CE format, the DSR MAC CE including a plurality of pairs of a remaining time value and a buffer size for the DSR MAC CE.

17. The one or more computer-readable media of claim 16, wherein the DSR MAC CE further includes one or more buffer size values for data of one or more logical channel groups (LCGs) corresponding to one or more DSRs of the plurality of DSRs. ​ ​ 18. The one or more computer-readable media of claim 16 or claim 17, wherein the DSR MAC CE format is determined based at least in part on a size of resources of the DSR MAC CE.

19. The one or more computer-readable media of claim 16 or claim 17, wherein the DSR MAC CE includes a field indicating a number of bytes of a first DSR.

20. The one or more computer-readable media of claim 16 or claim 17, wherein identifying the trigger comprises: identifies that a remaining time for a logical channel (LCH) or a logical channel group (LCG) is less than a threshold time.