Buffer status reporting and delay status reporting

Abstract

Example embodiments of the present disclosure are related to buffer status reporting and delay status reporting. A method comprises determining that buffered data associated with a logical channel group, LCG, comprises a first type of buffered data that is mandatory to be transmitted and a second type of buffered data that is to be transmitted on best effort; determining a first size of delay-critical data from the first type of buffered data; and in accordance with a detection of a trigger of delay status reporting, transmitting to a network device, a delay status report, DSR, at least indicating the first size for the LCG.

Description

BUFFER STATUS REPORTING AND DELAY STATUS REPORTINGFIELD

[0001] Various example embodiments of the present disclosure generally relate to the field of telecommunication and in particular, to methods, devices, apparatuses and computer readable storage medium for buffer status reporting and delay status reporting.BACKGROUND

[0002] A communication network may serve as a facility that enables communications between two or more communication devices or provides communication devices access to a data network. A mobile or wireless communication network is one example of a communication network. Such communication networks operate in accordance with standards, such as those promulgated by 3GPP (Third Generation Partnership Project) or ETSI (European Telecommunications Standards Institute) . Examples of such standards include the so-called 5G (5th Generation) standard or other standards promulgated by 3GPP.

[0003] In the communication network, buffer status of data available for transmission may need to be indicated from a first communication entity (e.g., a terminal device) to a second communication entity (e.g., a network node) . A buffer status report (BSR) or a delay status report (DSR) is defined to indicate the buffer status per logical channel group (LCG) .SUMMARY

[0004] In a first aspect of the present disclosure, there is provided a first apparatus. The first apparatus comprises at least one processor; and at least one memory storing instructions that, when executed by the at least one processor, cause the first apparatus at least to: determine that buffered data associated with a logical channel group, LCG, comprises a first type of buffered data and a second type of buffered data; determine a first size of the first type of buffered data and a second size of the second type of buffered data; and transmit, to a network device, a buffer status report, BSR, indicating the first size and the second size for the LCG.

[0005] In a second aspect of the present disclosure, there is provided a second apparatus. The second apparatus comprises at least one processor; and at least one memory storing  instructions that, when executed by the at least one processor, cause the second apparatus at least to: receive, from a terminal device, a buffer status report, BSR, indicating a first size of a first type of buffered data and a second size of a second type of buffered data for a logical channel group, LCG, of the terminal device, wherein the first type of buffered data and the second type of buffered data are comprised in buffered data associated with the LCG of the terminal device; and perform resource allocation to the terminal device based on the first size and the second size.

[0006] In a third aspect of the present disclosure, there is provided a method. The method comprises: determining that buffered data associated with a logical channel group, LCG, comprises a first type of buffered data and a second type of buffered data; determining a first size of the first type of buffered data and a second size of the second type of buffered data; and transmitting, to a network device, a buffer status report, BSR, indicating the first size and the second size for the LCG.

[0007] In a fourth aspect of the present disclosure, there is provided a method. The method comprises: receiving, from a terminal device, a buffer status report, BSR, indicating a first size of a first type of buffered data and a second size of a second type of buffered data for a logical channel group, LCG, of the terminal device, wherein the first type of buffered data and the second type of buffered data are comprised in buffered data associated with the LCG of the terminal device; and performing resource allocation to the terminal device based on the first size and the second size.

[0008] In a fifth aspect of the present disclosure, there is provided a first apparatus. The first apparatus comprises means for determining that buffered data associated with a logical channel group, LCG, comprises a first type of buffered data and a second type of buffered data; means for determining a first size of the first type of buffered data and a second size of the second type of buffered data; and means for transmitting, to a network device, a buffer status report, BSR, indicating the first size and the second size for the LCG.

[0009] In a sixth aspect of the present disclosure, there is provided a second apparatus. The second apparatus comprises means for receiving, from a terminal device, a buffer status report, BSR, indicating a first size of a first type of buffered data and a second size of a second type of buffered data for a logical channel group, LCG, of the terminal device, wherein the first type of buffered data and the second type of buffered data are comprised  in buffered data associated with the LCG of the terminal device; and means for performing resource allocation to the terminal device based on the first size and the second size.

[0010] In a seventh aspect of the present disclosure, there is provided a first apparatus. The first apparatus comprises at least one processor; and at least one memory storing instructions that, when executed by the at least one processor, cause the first apparatus at least to: determine that buffered data associated with a logical channel group, LCG, comprises a first type of buffered data that is mandatory to be transmitted and a second type of buffered data that is to be transmitted on best effort; determine a first size of delay-critical data from the first type of buffered data; and in accordance with a detection of a trigger of delay status reporting, transmit, to a network device, a delay status report, DSR, at least indicating the first size for the LCG.

[0011] In an eighth aspect of the present disclosure, there is provided a second apparatus. The second apparatus comprises at least one processor; and at least one memory storing instructions that, when executed by the at least one processor, cause the second apparatus at least to: receive, from a terminal device, a delay status report, DSR, at least indicating a first size for a logical channel group, LCG, of the terminal device, wherein buffered data associated with the LCG comprises a first type of buffered data that is mandatory to be transmitted and further comprises a second type of buffered data that is to be transmitted on best effort, and the first size is a size of delay-critical data from the first type of buffered data; and perform resource allocation to the terminal device based at least in part on the first size.

[0012] In a ninth aspect of the present disclosure, there is provided a method. The method comprises: determining that buffered data associated with a logical channel group, LCG, comprises a first type of buffered data that is mandatory to be transmitted and a second type of buffered data that is to be transmitted on best effort; determining a first size of delay-critical data from the first type of buffered data; and in accordance with a detection of a trigger of delay status reporting, transmitting to a network device, a delay status report, DSR, at least indicating the first size for the LCG.

[0013] In a tenth aspect of the present disclosure, there is provided a method. The method comprises: receiving, from a terminal device, a delay status report, DSR, at least indicating a first size for a logical channel group, LCG, of the terminal device, wherein buffered data associated with the LCG comprises a first type of buffered data that is  mandatory to be transmitted and further comprises a second type of buffered data that is to be transmitted on best effort, and the first size is a size of delay-critical data from the first type of buffered data; and performing resource allocation to the terminal device based at least in part on the first size.

[0014] In an eleventh aspect of the present disclosure, there is provided a first apparatus. The third apparatus comprises means for determining that buffered data associated with a logical channel group, LCG, comprises a first type of buffered data that is mandatory to be transmitted and a second type of buffered data that is to be transmitted on best effort; means for determining a first size of delay-critical data from the first type of buffered data ; and means for in accordance with a detection of a trigger of delay status reporting, transmitting to a network device, a delay status report, DSR, at least indicating the first size for the LCG.

[0015] In a twelfth aspect of the present disclosure, there is provided a second apparatus. The fourth apparatus comprises means for receiving, from a terminal device, a delay status report, DSR, at least indicating a first size for a logical channel group, LCG, of the terminal device, wherein buffered data associated with the LCG comprises a first type of buffered data that is mandatory to be transmitted and further comprises a second type of buffered data that is to be transmitted on best effort, and the first size is a size of delay-critical data from the first type of buffered data; and means for performing resource allocation to the terminal device based at least in part on the first size.

[0016] In a thirteenth aspect of the present disclosure, there is provided a computer readable medium. The computer readable medium comprises instructions stored thereon for causing an apparatus to perform at least the method according to the third aspect, the fourth aspect, the seventh aspect, or the eighth aspect.

[0017] It is to be understood that the Summary section is not intended to identify key or essential features of embodiments of the present disclosure, nor is it intended to be used to limit the scope of the present disclosure. Other features of the present disclosure will become easily comprehensible through the following description.

[0018] It is to be understood that the Summary section is not intended to identify key or essential features of embodiments of the present disclosure, nor is it intended to be used to limit the scope of the present disclosure. Other features of the present disclosure will become easily comprehensible through the following description.BRIEF DESCRIPTION OF THE DRAWINGS

[0019] Some example embodiments will now be described with reference to the accompanying drawings, where:

[0020] FIG. 1 illustrates an example communication environment in which example embodiments of the present disclosure can be implemented;

[0021] FIG. 2 illustrates an example of forward error correction (FEC) -based discarding in video codec;

[0022] FIG. 3 illustrates a signaling flow for buffer status reporting in accordance with some example embodiments of the present disclosure;

[0023] FIG. 4 illustrates an example format of buffer status report (BSR) in accordance with some example embodiments of the present disclosure;

[0024] FIG. 5 illustrates a signaling flow for delay status reporting in accordance with some example embodiments of the present disclosure;

[0025] FIG. 6 illustrates an example format of delay status report (DSR) in accordance with some example embodiments of the present disclosure;

[0026] FIG. 7A illustrates a flowchart of a method implemented at a first apparatus in accordance with some example embodiments of the present disclosure;

[0027] FIG. 7B illustrates a flowchart of a method implemented at a second apparatus in accordance with some example embodiments of the present disclosure;

[0028] FIG. 8A illustrates a flowchart of a method implemented at a first apparatus in accordance with some other example embodiments of the present disclosure;

[0029] FIG. 8B illustrates a flowchart of a method implemented at a second apparatus in accordance with some other example embodiments of the present disclosure;

[0030] FIG. 9 illustrates a simplified block diagram of a device that is suitable for implementing example embodiments of the present disclosure; and

[0031] FIG. 10 illustrates a block diagram of an example computer readable medium in accordance with some example embodiments of the present disclosure.

[0032] Throughout the drawings, the same or similar reference numerals represent the same  or similar element.DETAILED DESCRIPTION

[0033] Principle of the present disclosure will now be described with reference to some example embodiments. It is to be understood that these embodiments are described only for the purpose of illustration and help those skilled in the art to understand and implement the present disclosure, without suggesting any limitation as to the scope of the disclosure. Embodiments described herein can be implemented in various manners other than the ones described below.

[0034] In the following description and claims, unless defined otherwise, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skills in the art to which this disclosure belongs.

[0035] References in the present disclosure to “one embodiment, ” “an embodiment, ” “an example embodiment, ” and the like indicate that the embodiment described may include a particular feature, structure, or characteristic, but it is not necessary that every embodiment includes the particular feature, structure, or characteristic. Moreover, such phrases are not necessarily referring to the same embodiment. Further, when a particular feature, structure, or characteristic is described in connection with an embodiment, it is submitted that it is within the knowledge of one skilled in the art to affect such feature, structure, or characteristic in connection with other embodiments whether or not explicitly described.

[0036] It shall be understood that although the terms “first, ” “second, ” …, etc. in front of noun (s) and the like may be used herein to describe various elements, these elements should not be limited by these terms. These terms are only used to distinguish one element from another and they do not limit the order of the noun (s) . For example, a first element could be termed a second element, and similarly, a second element could be termed a first element, without departing from the scope of example embodiments. As used herein, the term “and / or” includes any and all combinations of one or more of the listed terms.

[0037] As used herein, “at least one of the following: <a list of two or more elements>” and “at least one of <a list of two or more elements>” and similar wording, where the list of two or more elements are joined by “and” or “or” , mean at least any one of the elements, or at least any two or more of the elements, or at least all the elements.

[0038] As used herein, unless stated explicitly, performing a step “in response to A” does not indicate that the step is performed immediately after “A” occurs and one or more intervening steps may be included.

[0039] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of example embodiments. As used herein, the singular forms “a” , “an” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms “comprises” , “comprising” , “has” , “having” , “includes” and / or “including” , when used herein, specify the presence of stated features, elements, and / or components etc., but do not preclude the presence or addition of one or more other features, elements, components and / or combinations thereof.

[0040] As used in this application, the term “circuitry” may refer to one or more or all of the following:

[0041] (a) hardware-only circuit implementations (such as implementations in only analog and / or digital circuitry) and

[0042] (b) combinations of hardware circuits and software, such as (as applicable) :

[0043] (i) a combination of analog and / or digital hardware circuit (s) with software / firmware and

[0044] (ii) any portions of hardware processor (s) with software (including digital signal processor (s) ) , software, and memory (ies) that work together to cause an apparatus, such as a mobile phone or server, to perform various functions) and

[0045] (c) hardware circuit (s) and or processor (s) , such as a microprocessor (s) or a portion of a microprocessor (s) , that requires software (e.g., firmware) for operation, but the software may not be present when it is not needed for operation.

[0046] This definition of circuitry applies to all uses of this term in this application, including in any claims. As a further example, as used in this application, the term circuitry also covers an implementation of merely a hardware circuit or processor (or multiple processors) or portion of a hardware circuit or processor and its (or their) accompanying software and / or firmware. The term circuitry also covers, for example and if applicable to  the particular claim element, a baseband integrated circuit or processor integrated circuit for a mobile device or a similar integrated circuit in server, a cellular network device, or other computing or network device.

[0047] As used herein, the term “communication network” refers to a network following any suitable communication standards, such as New Radio (NR) , Long Term Evolution (LTE) , LTE-Advanced (LTE-A) , Wideband Code Division Multiple Access (WCDMA) , High-Speed Packet Access (HSPA) , Narrow Band Internet of Things (NB-IoT) and so on. Furthermore, the communications between a terminal device and a network device in the communication network may be performed according to any suitable generation communication protocols, including, but not limited to, the first generation (1G) , the second generation (2G) , 2.5G, 2.75G, the third generation (3G) , the fourth generation (4G) , 4.5G, the fifth generation (5G) , the sixth generation (6G) communication protocols, and / or any other protocols either currently known or to be developed in the future. Embodiments of the present disclosure may be applied in various communication systems. Given the rapid development in communications, there will of course also be future type communication technologies and systems with which the present disclosure may be embodied. It should not be seen as limiting the scope of the present disclosure to only the aforementioned system.

[0048] As used herein, the term “network device” refers to a node in a communication network via which a terminal device accesses the network and receives services therefrom. The network device may refer to a base station (BS) or an access point (AP) , for example, a node B (NodeB or NB) , an evolved NodeB (eNodeB or eNB) , an NR NB (also referred to as a gNB) , a Remote Radio Unit (RRU) , a radio header (RH) , a remote radio head (RRH) , a relay, an Integrated Access and Backhaul (IAB) node, a low power node such as a femto, a pico, a non-terrestrial network (NTN) or non-ground network device such as a satellite network device, a low earth orbit (LEO) satellite and a geosynchronous earth orbit (GEO) satellite, an aircraft network device, and so forth, depending on the applied terminology and technology. In some example embodiments, radio access network (RAN) split architecture comprises a Centralized Unit (CU) and a Distributed Unit (DU) at an IAB donor node. An IAB node comprises a Mobile Terminal (IAB-MT) part that behaves like a UE toward the parent node, and a DU part of an IAB node behaves like a base station toward the next-hop IAB node.

[0049] The term “terminal device” refers to any end device that may be capable of wireless  communication. By way of example rather than limitation, a terminal device may also be referred to as a communication device, user equipment (UE) , a Subscriber Station (SS) , a Portable Subscriber Station, a Mobile Station (MS) , or an Access Terminal (AT) . The terminal device may include, but not limited to, a mobile phone, a cellular phone, a smart phone, voice over IP (VoIP) phones, wireless local loop phones, a tablet, a wearable terminal device, a personal digital assistant (PDA) , portable computers, desktop computer, image capture terminal devices such as digital cameras, gaming terminal devices, music storage and playback appliances, vehicle-mounted wireless terminal devices, wireless endpoints, mobile stations, laptop-embedded equipment (LEE) , laptop-mounted equipment (LME) , USB dongles, smart devices, wireless customer-premises equipment (CPE) , an Internet of Things (IoT) device, a watch or other wearable, a head-mounted display (HMD) , a vehicle, a drone, a medical device and applications (e.g., remote surgery) , an industrial device and applications (e.g., a robot and / or other wireless devices operating in an industrial and / or an automated processing chain contexts) , a consumer electronics device, a device operating on commercial and / or industrial wireless networks, and the like. The terminal device may also correspond to a Mobile Termination (MT) part of an IAB node (e.g., a relay node) . In the following description, the terms “terminal device” , “communication device” , “terminal” , “user equipment” and “UE” may be used interchangeably.

[0050] As used herein, the term “resource, ” “transmission resource, ” “resource block, ” “physical resource block” (PRB) , “uplink resource, ” or “downlink resource” may refer to any resource for performing a communication, for example, a communication between a terminal device and a network device, such as a resource in time domain, a resource in frequency domain, a resource in space domain, a resource in code domain, or any other combination of the time, frequency, space and / or code domain resource enabling a communication, and the like. In the following, unless explicitly stated, a resource in both frequency domain and time domain will be used as an example of a transmission resource for describing some example embodiments of the present disclosure. It is noted that example embodiments of the present disclosure are equally applicable to other resources in other domains.

[0051] FIG. 1 illustrates a schematic diagram of an example communication environment 100 in which example embodiments of the present disclosure can be implemented. In the communication environment 100, a plurality of communication devices, including a  terminal device 110, and a plurality of network devices 120-1, 120-2, and 120-3, may communicate with each other. The network devices 120-1, 120-2, and 120-3 are sometimes collectively or individually referred to as network devices 120.

[0052] In the example of FIG. 1, the terminal device 110 may be a UE and a network device 120 may be a base station serving the UE. The serving area of the network device 120 may be called a cell (e.g., a cell 102-1 for the network device 120-1, a cell 102-2 for the network device 120-2, and a cell 102-3 for the network device 120-3) . The network device 120 is operating in a radio access network (RAN) and thus is also referred to as a RAN network device. The cells 102-1, 102-2, and 102-3 are sometimes collectively or individually referred to as cells 102.

[0053] In some example embodiments, the network devices 120-1, 120-2, and 120-3 serve respective cells 102-1, 102-2, and 102-3 using different carriers or frequency bands in both DL and UL. Such a frequency band may also be referred to as an operating frequency band of the corresponding network device.

[0054] It is to be understood that the number of devices and their connections shown in FIG. 1 are only for the purpose of illustration without suggesting any limitation. The communication environment 100 may include any suitable number of devices configured to implementing example embodiments of the present disclosure. Although not shown, it would be appreciated that one or more additional devices may be located in the cell 102, and one or more additional cells may be deployed in the communication environment 100. It is noted that although illustrated as a network device, the network device 120 may be another device than a network device. Although illustrated as a terminal device, the terminal device 110 may be another device than a terminal device.

[0055] In the following, for the purpose of illustration, some example embodiments are described with a terminal device 110 operating as a UE and a network device 120 operating as a base station, e.g., gNB. However, in some example embodiments, operations described in connection with a terminal device may be implemented at a network device or other device, and operations described in connection with a network device may be implemented at a terminal device or other device.

[0056] In some example embodiments, a communication direction from the network device 120 to the terminal device 110 is referred to as a downlink (DL) , while a communication direction from the terminal device 110 to the network device 120 is referred to as an uplink  (UL) . In DL, the network device 120 is a transmitting (TX) device (or a transmitter) and the terminal device 110 is a receiving (RX) device (or a receiver) . In UL, the terminal device 110 is a TX device (or a transmitter) and the network device 120 is a RX device (or a receiver) .

[0057] Communications in the communication environment 100 may be implemented according to any proper communication protocol (s) , comprising, but not limited to, cellular communication protocols of the first generation (1G) , the second generation (2G) , the third generation (3G) , the fourth generation (4G) , the fifth generation (5G) , the sixth generation (6G) , and the like, wireless local network communication protocols such as Institute for Electrical and Electronics Engineers (IEEE) 802.11 and the like, and / or any other protocols currently known or to be developed in the future. Moreover, the communication may utilize any proper wireless communication technology, comprising but not limited to: Code Division Multiple Access (CDMA) , Frequency Division Multiple Access (FDMA) , Time Division Multiple Access (TDMA) , Frequency Division Duplex (FDD) , Time Division Duplex (TDD) , Multiple-Input Multiple-Output (MIMO) , Orthogonal Frequency Division Multiple (OFDM) , Discrete Fourier Transform spread OFDM (DFT-s-OFDM) and / or any other technologies currently known or to be developed in the future.

[0058] Buffer status reporting is a procedure that informs the network device of the amount of data the terminal device has buffered for transmission. A buffer status report (BSR) may include a BSR media access control control element (MAC CE) that carries the information of how much uplink data is in the buffer of the terminal device to be sent out. Buffer status reporting is per logical channel group (LCG) , which means, buffer status information from one or more logical channels (LCHs) that belong to the same LCG needs to be collected before a BSR is constructed and signalled in UL.

[0059] Delay status reporting is a procedure that informs the network device of the amount of delay critical data the terminal device has buffered for transmission. A delay status report (DSR) may include a DSR MAC CE that carries the information of how much delay-critical uplink data buffered for an LCG. The delay-critical data may be data with a limited remaining time to be discarded. Delay status reporting may also be performed per LCG.

[0060] With the BSR and / or DSR received from the terminal device, the network device may  then allocate uplink resources for the buffered data to be transmitted based on the indicated data amount. Depending on the available uplink resources, the network device may or may not allocate sufficient uplink resources for the terminal device to transmit all buffered or delay-critical data.

[0061] Currently, in either the BSR or DSR, the size of buffered data is indicated per LCG. For example, in the BSR, a buffer size is included for each LCG to indicate a total amount of buffered data for the LCG. In the DSR, a buffer size is included for each LCG to indicate a total amount of delay-critical data for the LCG. Such reporting allows the network device to be aware only of the data volume per LCG that is buffered for transmission or is critical to be transmitted, restraining the network device from optimized resource allocation for the terminal device. The indication of the buffered data may comprise an index value corresponding to a buffer size table. That is the amount of data in the buffer of an LCG may be determined and then a corresponding index may be selected from the buffer size table. The index may be included in the BSR for that LCG. The receiver of the BSR may be aware of the buffer size table and may then determine the amount of data in the buffer of that LCG based on the received index and the known buffer size table. Similar approach may be used for DSR, but the indicated amount of data may comprise only the amount of delay-critical data for the LCG.

[0062] The communication technologies continue to develop to support more and more applications including the extended reality (XR) and Metaverse relevant applications. Hence, more and more traffic characteristics are taken into account in various enhancements of the communication systems, for example, traffic types, traffic characteristics, the concept of packet data unit (PDU) set and related quality of service (QoS) parameters, service flow dependencies via multi-modal service ID (MMSID) , QoS requirements of different traffic flows of the same application and so on. As a result, buffered data for an LCG may be divided into different types, depending on their traffic characteristics. Different types of data for an LCG may be of different importances, which should be considered by the network device for the resource allocation.

[0063] Among different types of traffic awareness information, one of them is the knowledge of forward error correction (FEC) information. With the FEC information, if there are already sufficient data available at the receiver side (e.g., the network side for the uplink transmission) , then additional PDUs from the same PDU set may not be needed. The FEC-based discarding may be applied at least to video codec. Taking example of I / P frames- based video codec, in case with FEC information at an application layer of the receiver side, then not all video P-frames are needed for a decodable video frame at the application layer. As shown in an example of FIG. 2, the video P-frames, P-1, P-2, P-3, in PDU Set#1 are dependent on an I-frame, I-1, in PDU Set #2, and the video P-frames, P-4, P-5, P-6, in PDU Set#1 are dependent on another video I-frame, I-2, in PDU Set #2. With FEC-based discarding, if less than 1 / 3 of P-frames are discarded, the video P-frames in PDU Set#1 are still decodable based on the remaining video P-frames and the video I-frames in PDU Set #2.

[0064] As such, the video I-frames and a certain number of video P-frames for an LCG are more important to be transmitted while the remaining P-frames may be discarded if there are no sufficient uplink resources. However, with the buffer status reporting or delay status reporting per LCG, it is not possible to specifically indicate the amount of data part with higher importance for an LCG.

[0065] Further, for channel state information (CSI) reporting, the terminal device may measure a CSI reference signal (CSI-RS) from the network device and construct a CSI report to be transmitted to the network device to facilitate downlink link adaption. It is now proposed that the CSI information may be reported at the MAC layer instead of physical (PHY) layer, using the physical uplink shared channel (PUSCH) . One of the benefits with CSI reporting at PUSCH is to simplify the physical layer processing as there is no need to discuss how to handle overlapped physical uplink control channel (PUCCH) carrying CSI overlapping with other PUCCH or PUSCH. Handling overlapping channels is quite complicated by considering different aspects including multiplexing / prioritization timeline, different UE processing capabilities, joint / separate coding scheme selection, resource selection and / or mapping, uplink control information (UCI) prioritization in case without sufficient granted resource, etc. When considering moving CSI reporting at the MAC layer, it may provide the terminal device with more autonomy to determine which part of CSI information to be reported. As the terminal device has the best knowledge of the needed CSI information, it could determine which part of CSI information is more important and / or which part of CSI information is less important. Still, it is not possible to enable the terminal device to indicate the buffer size of the important part of CSI information and the buffer size of the less-important part of CSI information to the network side.

[0066] According to example embodiments of the present disclosure, there are proposed  enhanced mechanisms for signaling buffer status information and / or delay status information considering different types of data from the same LCG. In some example embodiments, for buffer status reporting, it is proposed to separately indicate in a BSR buffer sizes of different types of data for an LCG. In some example embodiments, for delay status reporting, it is proposed that for an LCG with buffered data of different types, one or more of the different types of buffered data is separately indicated in a DSR if a trigger for buffer status reporting is triggered, e.g., the delay information of some delay-critical buffered data satisfies a predetermined condition. As such, it can achieve finer granularity of buffer status reporting and / or delay status reporting for a single LCG. The network device may thus perform resource allocation or other decision based on the finer-granularity buffer status reporting and / or delay status reporting.

[0067] Through the proposed mechanisms, the separate reporting for different types of data in a BSR or DSR may lead to improved resource utilization as some types of data may be guaranteed to be transmitted first if uplink resources are insufficient.

[0068] FIG. 3 illustrates a signaling flow 300 for buffer status reporting in accordance with some example embodiments of the present disclosure. For the purpose of illustration, the signaling flow 300 will be described with respect to FIG. 1. The signaling flow 300 involves the terminal device 110 and the network device 120.

[0069] The signaling flow 300 is related to separate indications of buffer sizes of different types of data for an LCG in a BSR. Thus, for an LCG, the terminal device 110 may determine whether buffered data associated with an LCG comprises more than one type of data. As used herein, an LCG may include one LCH, or may include two or more LCHs.

[0070] In the case the terminal device 110 determines (315) that buffered data associated with an LCG comprises more than one type of buffered data, e.g., a first type of buffered data and a second type of buffered data, it determines (320) a first size of the first type of buffered data and a second size of the second type of buffered data. The terminal device 110 transmits (325) , to the network device 120, a BSR indicating the first size and the second size for the LCG. The first size or the second size in the BSR may also be referred to as a “buffer size” .

[0071] It would be appreciated that although a first type and a second type of buffered data are mentioned in the discussed embodiments of the present disclosure, buffered data for an LCG may be classified into more than two types of buffered data. In this case, the  terminal device 110 may indicate separate sizes of the different types of buffered data for an LCG in a BSR.

[0072] In some example embodiments, the network device 120 may transmit (305) , to the terminal device 110, configuration information indicating at least one LCG or LCH that supports separate buffer status reporting of the buffered data. If one or more LCHs are configured, it means that an LCG (s) including the configured LCHs may support the separate buffer status reporting.

[0073] Here, the separate buffer status reporting includes indications of separate sizes of different types of data indicated for one LCG in a BSR. For example, the separate buffer status reporting may require reporting of a buffer size of the first type of buffered data and a buffer size of the second type of buffered data for a configured LCG (or an LCG including the configured LCH (s) ) . The BSR may be constructed to include at least two fields for an LCG, with at least a first field to indicate the buffer size of the first type and a second field to indicate the buffer size of the second type. The network device 120 may configure certain LCHs or LCGs for supporting the separate buffer status reporting. Such separate buffer status reporting may sometimes be referred to as enhanced buffer status reporting.

[0074] The terminal device 110 may receive (310) such configuration information and may construct the BSR based on the configuration information, to indicate separate sizes for each configured LCG in the BSR. When uplink data (or other information such as CSI) arrive at the UL data buffer, the terminal device 110 may determine whether the uplink data is coming from the configured LCG (s) supporting the separate buffer status reporting, and whether the uplink data comprises at least the first type of data and the second type of data in order to construct the BSR.

[0075] In some example embodiments, instead of the explicit configuration from the network device 120, the terminal device 110 may be pre-configured with some LCGs or LCHs that support the separate buffer status reporting. For example, the terminal device 110 may be pre-configured with the LCGs or LCHs which support the separate buffer status reporting for buffered data of one or more predetermined types. In some example embodiments, the support of the separate buffer status reporting may be configured per terminal device. For example, the network device 120 may configure some of the terminal devices to support the separate buffer status reporting while some other terminal devices without such  configuration may not be able to report the BSR according to the separate buffer status reporting.

[0076] In some example embodiments, if an LCG supports the separate buffer status reporting and includes at least the first type of buffered data and the second type of buffered data, the BSR may at least include a first field and a second field corresponding to the LCG, with the first field indicating the first size and the second field indicating the second size.

[0077] In some example embodiments, the BSR may be included in a BSR MAC CE. The terminal device 110 may transmit the BSR MAC CE to the network device 120.

[0078] Various formats may be defined to support the BSR according to the example embodiments of the present disclosure. FIG. 4 illustrates an example BSR format 400 in accordance with some example embodiments of the present disclosure.

[0079] In the BSR format 400, the field, LCGi, indicates the presence of the Buffer Size field for the logical channel group i. The LCGi field set to 1 indicates that the Buffer Size field for the logical channel group i is reported. The LCGi field set to 0 indicates that the Buffer Size field for the logical channel group i is not reported. FIG. 4 illustrates eight LCGs as an example and there may be more or fewer LCGs.

[0080] The field “First Type Buffer Size” indicates a total amount of the first type of buffered data available from all of the one or more logical channels included in a logical channel group. The field “Second Type Buffer Size” identifies a total amount of the second type of buffered data available from all of the one or more logical channels included in a logical channel group. It can be seen from FIG. 4 that there may be two fields, “First Type Buffer Size” and “Second Type Buffer Size” for one LCG (e.g., an LCG that is configured to support the separate buffer status reporting) .

[0081] Although a field for a buffer size is shown to occupy an octet in FIG. 4, the bit length of a single buffer size for an LCG, or a total bit length of buffer sizes for an LCG may be varied depending on designs of the BSR format.

[0082] It would be appreciated that the BSR format 400 of FIG. 4 is merely an example. There may be various other BSR formats applicable for the separate buffer status reporting, which may include the short BSR format (with a fixed size) , extended short BSR format (with a fixed size) , long BSR format (with a variable size) , refined long BSR format (with  a variable size) , with an extended Long BSR format (with a variable size) , a short truncated BSR format (with a fixed size) , an extended short truncated BSR format (with a fixed size) , a long truncated BSR format (with a variable size) , an extended long truncated BSR format (with a variable size) , and so on.

[0083] In some example embodiments, one or more LCGs of the terminal device 110 may not support the separate buffer status reporting. Then the BSR may include a single field corresponding to an LCG that does not support the separate buffer status reporting.

[0084] In some example embodiments, the terminal device 110 may determine a size of total buffered data associated with an LCG that does not support the separate buffer status reporting, and the single field corresponding to this LCG may indicate the size of the total buffered data.

[0085] In some example embodiments, the terminal device 110 may determine a size of buffered data of the first type associated with an LCG that does not support the separate buffer status reporting, and the single field corresponding to this LCG may indicate the size of buffered data of the first type. For example, in the BSR format 400 of FIG. 4, it is assumed that LCG0 does not support the separate buffer status reporting, and only one field, marked as “First Type Buffer Size 0” is included in the BSR for LCG0.

[0086] In some example embodiments, buffered data associated with an LCG may be divided into different types of data based on the importance of the data. As an example, for an LCG, the first type of buffered data may be of an importance level higher than that of the second type of buffered data. As another example, depending on the granularity of importance, buffered data of an LCG may be divided into more than two types of buffered data, so that the BSR may include more than two fields to indicate separate sizes of the different types of buffered data for one LCG.

[0087] In some example embodiments, for an LCG, the first type of buffered data may include data that is mandatory to be transmitted, and the second type of buffered data may include data to be transmitted on best effort. The terminal device 110 may separately indicate, in a BSR, a first size of the buffered data that is mandatory to be transmitted and a second size of the buffered data that is optionally or on best effort basis to be transmitted. The data that is mandatory to be transmitted in an LCG may herein sometimes be referred to as “mandatory data” , and the data that is optionally or on best effort basis to be transmitted in an LCG may herein sometimes be referred to as “best-effort data” .

[0088] In some example embodiments, for an LCG, the first type of buffered data may include a minimum amount of data that is to be transmitted to allow the whole buffered data of the LCG to be decoded at the receiver side, and the second type of buffered data may include remaining buffered data other than the minimum data. In this case, the minimum amount of buffered data may be more important for transmission to the network device.

[0089] In some example embodiments, an LCG supporting the separate buffer status reporting may include buffered user data traffic. In some examples, the LCG supporting the separate buffer status reporting may be used to carry user data traffic in the application flows with a FEC scheme applied at the application layer. The network device 120 may indicate, to the terminal device 110, one or more such LCGs in the configuration information. With the FEC scheme applied, a certain amount of buffered data may be discarded for transmission but the whole buffered data may still be decoded from the remaining part of data that is received at the receiver side. In such a use case, the minimum amount of data required for decoding the whole buffered data may be of higher importance, and may be determined as “mandatory data” , while the remaining amount of buffered data that are discardable may be determined as “best-effort data” .

[0090] Taking the K out of N FEC scheme as one example, at least K PDUs are required to successfully decode the whole set of N PDUs (where K<N) . The K PDUs may thus be considered as the mandatory data for the LCG, while the (N-K) PDUs are not considered as mandatory data unless some of the K PDUs are not able be to be decoded successfully at the receiver side.

[0091] In some examples, if the buffered data associated with an LCG comprises a set of PDUs (e.g., N PDUs for a video frame) , the terminal device 110 may determine the first type of buffered data by identifying, from the set of PDUs, a first number of PDUs from which the set of PDUs is to be decoded based on a FEC scheme. The first number of PDUs may be the minimum data volume which needs to be successfully decoded at receiver side in order to recovery the set of PDUs correctly. If the K out of N FEC scheme is applied, then the first number may be K as an amount of K PDUs are mandatory for successful decoding of the N PDUs. The terminal device 110 may further determine the second type of buffered data by identifying, from the set of PDUs, at least one PDU among the set of PDUs other than the first number of PDUs, which may be (N-K) PDUs. In the BSR, the first field corresponding to the first type for the LCG may indicate the size of the K PDUs,  and the second field corresponding to the second type for the LCG may indicate the (N-K) PDUs.

[0092] In some example embodiments, an LCG supporting the separate buffer status reporting may include an LCG used for CSI. The buffered data associated with such an LCG may include CSI. The network device 120 may indicate such an LCG in the configuration information. The terminal device 110 may determine a first part of CSI (e.g. CSI Part 1) with a higher importance level to be the first type of buffered data (or mandatory data) , and a second part of CSI (e.g. CSI Part 2) with a lower importance level to be the second type of buffered data (or best-effort data) .

[0093] In some example embodiments, due to the fact that different parts of CSI change at different rates, the specific components of CSI that change most frequently depend on the underlying technology and the specific use cases. For example, the channel amplitude (signal strength) might change more rapidly than the channel phase (timing of the signal) . As the DL receiver, it is the terminal device who has the knowledge of which part (s) of the CSI are most relevant. So, when the terminal device requests UL resource in a BSR for CSI transmission over PUSCH, the terminal device may indicate which part of CSI is the most important (mandatory) and which part of CSI may be handled in a best effort way. In this way, in case there is sufficient UL resource available, the terminal device may report both mandatory and best effort CSI. On the other hand, in case there is no sufficient UL resource available, the best effort CSI may be dropped or sent later.

[0094] In some example embodiments, the terminal device 110 may determine the first type of buffered data (or the mandatory data) by identifying, from the CSI for an LCG, a first part of channel state information with a high variation level (e.g., exceeding a first variation threshold) . The part of channel state information that changes more rapidly may be with high urgency to be transmitted to the network side in case there is not sufficient UL resources available. In the BSR, the first field corresponding to the first type may indicate the size of the first part of channel state information.

[0095] Further, the terminal device 110 may determine the second type of buffered data (or best-effort data) by identifying, from the CSI for an LCG, a second part of channel state information with a low variation level (e.g., being below a second variation threshold) . The part of channel state information that changes slowly may be transmitted to the network side in case there is sufficient UL resources; otherwise, this part of channel state  information may be dropped or sent later. In the BSR, the second field corresponding to the second type may indicate the size of the second part of channel state information.

[0096] In some example embodiments, for CSI reporting, it may be predefined or configurable which part of CSI is of the first type (the mandatory CSI) and which part of CSI is of the second type (and thus may be optional for transmission) .

[0097] It should be pointed out that the separate buffer status reporting of CSI may be different from a configured rule for CSI prioritization. For example, a CSI format may define CSI Part 1 and CSI Part 2, which may include different components of channel state information. It is noted that “CSI Part 1” and “CSI Part 2” are terms defined for the CSI format, which may not be necessarily equal to the first part of channel state information with a high variation level and the second part of channel state information with a low variation level as discussed above. According to CSI prioritization, CSI Part 2 may be dropped but CSI Part 1 always needs to be sent. According to some example embodiments of the present disclosure, it may also be possible that certain components in CSI Part 2 may be classified as the first type of buffered data and thus may be sent while some measurement results of CSI Part 1 may be classified as the second type of buffered data and then may be dropped due to insufficient resources.

[0098] In some examples, the first variation threshold used to identify the first type of buffered data and the second variation threshold used to identify the second type of buffered among the CSI may be one same threshold, to divide the CSI into two parts. In some other examples, the first variation threshold and the second variation threshold may be different, e.g., in order to divide the CSI into more than two parts. It would be appreciated that the example embodiments of the present disclosure are not limited by the variation thresholds, or by the number of parts divided for separate buffer status reporting.

[0099] In some example embodiments, an LCG supporting the separate buffer status reporting may include an LCG that is used for one or more types of MAC CEs. That is, the buffered data associated with the LCG supporting separate buffer status reporting may include one or more types of MAC CEs considering that those types of MAC CEs may be of different importance levels. The importance of different types of MAC CEs may be determined based on the data and / or information carried in the MAC CEs. For example, a MAC CE for a cell radio network temporary identifier (C-RNTI) or data from an uplink common control channel (UL-CCCH) may be of a higher importance level than that of a  MAC CE for an (enhanced) beam failure recovery (BFR) or a MAC CE for configured grant information, As another example, the MAC CE for the (enhanced) BFR or MAC CE for configured grant information may be of a higher importance level than that of a MAC CE for sidelink configured grant information or a MAC CE for a listen before talk (LBT) failure, a MAC CE for sidelink LBT failure, or a MAC CE for timing advance report. Of course, only some examples of MAC CEs are provided here and there may be various other types of MAC CEs. The MAC CE (s) with a higher importance level may be prioritized in transmission to the network side, and thus may be determined as the first type of buffered data for one LCG.

[0100] It would be appreciated that although some examples of LCGs that may support the separate buffer status reporting are discussed above, there may be various other uplink traffics that may be mapped to the LCGs to support the separate buffer status reporting.

[0101] Referring back to FIG. 3, at the network side, the network device 120 receives (330) the BSR from the terminal device 110 and performs (335) resource allocation to the terminal device based on the first size and the second size indicated for the LCG in the received BSR, to allocate a set of uplink resource. The uplink resources may sometimes be referred to as uplink grants.

[0102] The actual resource allocated to the terminal device 110 may depend on various other factors including the size of available uplink resources. As the terminal device 110 specifically indicates the buffer sizes of the respective types of data for an LCG, the network device 120 may obtain the information (e.g., mandatory data volume and best-effort data volume) at the terminal side. The network device 120 may determine whether to allocate sufficient uplink resources for transmission of only the first type of buffered data, for the first and second types of buffered data, or all the types of buffered data for the LCG.

[0103] The network device 120 may transmit (340) information indicating the set of uplink resources allocated to the terminal device 110. The terminal device 110 may receive (345) the information indicating the set of uplink resources and determines whether the size of the allocated uplink resources is sufficient to transmit the whole buffered data of an LCG, or may be sufficient to transmit the first type of buffered data. For example, the terminal device 110 may determine which part of the buffered data (mandatory data only, or both mandatory data and best-effort data) may be transmitted with the allocated resources.

[0104] In some example embodiments, the terminal device 110 may transmit (355) , to the network device 120, at least the first type of buffered data on the allocated set of uplink resources. The network device 120 may then receive (360) at least the first type of buffered data on the allocated set of uplink resources. In some example embodiments, if the size of the allocated set of uplink resources is greater than the first size, the terminal device 110 may transmit, to the network device 120, the first type of buffered data and at least a part of the second type of buffered data on the allocated set of uplink resources.

[0105] In some example embodiments, when the terminal device 110 performs UL transmission to the network device 120 on the allocated uplink resources, it may further transmit a padding BSR to the network device 120 if there is still new buffered data coming for an LCG. In some example embodiments, the padding BSR may also be constructed as discussed above, to separately indicate buffer sizes of different types of buffered data for a configured LCG. In some example embodiments, the buffered data reported in the padding BSR may include new data that are buffered for the LCG after the previously reported BSR. Through the mechanism of separate buffer status reporting according to the example embodiments of the present disclosure, it may enable both efficient radio resource usage and fulfilling QoS requirements in the uplink.

[0106] In some example embodiments, the separate reporting for an LCG may be applicable to delay status reporting when reporting the buffer size for delay critical data. FIG. 5 illustrates a signaling flow 500 for delay status reporting in accordance with some example embodiments of the present disclosure. For the purpose of illustration, the signaling flow 500 will be described with respect to FIG. 1. The signaling flow 500 involves the terminal device 110 and the network device 120.

[0107] In the signaling flow 500, for an LCG, the terminal device 110 may determine whether buffered data associated with an LCG comprises more than one type of data. As used herein, an LCG may include one LCH, or may include two or more LCHs.

[0108] In the case the terminal device 110 determines (515) that buffered data associated with an LCG comprises more than one type of buffered data, e.g., a first type of buffered data that is mandatory to be transmitted and a second type of buffered data that is to be transmitted on best effort, it determines (520) at least a first size of delay-critical data from the first type of buffered data.

[0109] In some example embodiments, for an LCG, the first type of buffered data and  the second type of buffered data may be defined as discussed above with reference to the signaling flow 300 of FIG. 3. The first type of buffered data may be mandatory data to be transmitted, while the second type of buffered data may be best-effort data. The identification of the first and second types of buffered data in an LCG will not be repeated for brevity. Also, similarly as in the example embodiments of the signaling flow 300, buffered data associated with an LCG may be divided into more than two types of buffered data. For the purpose of discussion, the first type of buffered data may be referred to as a type of buffered data with a higher importance level than that of the second type of buffered data (and other types of buffered data, if available) , as the first type of buffered data is mandatory for transmission.

[0110] In the example embodiments for delay status reporting, for an LCG, at least a first size of delay-critical data comprised in the first type of buffered data is indicated in the DSR. That is, the first size indicated in the DSR may be the size of mandatory and delay-critical data for an LCG. The delay-critical data may be determined based on the associated delay information, e.g., a remaining time. The delay-critical data may be data with a limited remaining time to be discarded. For example, each data unit (PDU or service data unit, SDU) of the buffered data may be configured with a discard timer. If a remaining time of a discard timer is below a remaining time threshold, then the corresponding data unit is determined as a delay-critical data unit.

[0111] In some alternative example embodiments, the first size indicated in the DSR may be determined to be a total size of the first type of buffered data. That is, buffer size of mandatory data for an LCG is considered in delay status reporting even if there may be some non-delay -critical data considered in the reported first size. The first size indicated in the DSR may be the size of mandatory data (including the data amount that is not delay-critical) .

[0112] In accordance with a detection of a trigger of delay status reporting, the terminal device 110 transmits (525) , to the network device 120, a DSR at least indicating the first size for the LCG.

[0113] In some example embodiments, for an LCG, the DSR may indicate the first size of delay-critical data among the first type of buffered data, without indicating a second size delay-critical data among the second type of buffered data or the size of other types of buffered data in the LCG. That is, the second size indicated in the DSR may be the size  of best-effort and delay-critical data for an LCG. The DSR may at least include a first field corresponding to the LCG to indicate the first size. That is, only the size of the mandatory and delay-critical data is reported for an LCG in the DSR. For example, for CSI reporting, only the mandatory part of CSI may be reported in the DSR.

[0114] In some example embodiments, for an LCG, the DSR may indicate both the first size and a second size delay-critical data among the second type of buffered data that is to be transmitted on best effort. If there are one or more other types of buffered data defined for an LCG, the DSR may also include corresponding fields to indicate the respective sizes of delay-critical data for those types. The DSR may at least include a first field and a second field corresponding to the LCG, the first field indicating the first size, and the second field indicating the second size. As such, the DSR may include separate sizes of delay-critical data for different types of buffered data for one LCG.

[0115] In some example embodiments, the second size may be determined to be a total size of the second type of buffered data. The second size indicated in the DSR may be the size of best-effort data (including the data amount that is not delay-critical) .

[0116] In some example embodiments, for an LCG, the DSR may indicate a third size of non-delay critical data from the first type of buffered data and the second type of buffered data. The DSR may further include a third field corresponding to the LCG to indicate the third size. The non-delay critical data may be buffered data with a remaining time (s) greater than the remining time threshold for the LCG.

[0117] As more fields are included in the DSR, a larger size of uplink resource may be required to transmit the DSR to the network device 120. In some example embodiments, the terminal device 110 may determine which size (s) can be indicated in the DSR based on a size of the uplink resource (also referred to as UL grant) for transmission of the DSR. For example, the terminal device 110 may determine whether the second size of the delay-critical data from the best-effort data and / or the third size of the non-delay-critical data for the LCG are to be included in the DSR based on the size of the uplink resource. If the uplink resource is not enough to include all of the sizes, some of the sizes may need to be truncated. The terminal device 110 may ensure that the first size of the mandatory and delay-critical data for an LCG is reported to the network device 120 if the uplink resource for DSR transmission does not support reporting more other sizes.

[0118] In some example embodiments, the second size may be prioritized over the third  size to be included in the DSR, as the second size is a size of delay-critical and best-effort data. Upon reception of the DSR, for UL congestion case, the network device 120 may need to prioritize delay-critical data and not always possible to provide enough uplink grant for the non-delay critical data. Thus, reporting delay-critical data in the DSR may be more important than reporting non-delay critical data.

[0119] In some example embodiments, the trigger of delay status reporting may be detected if there is delay-critical data in the buffered data associated with the LCG. The delay-critical data may be determined based on delay information associated with the buffered data. The delay information may be represented as a remaining time of a discard timer of a buffered data unit in the LCG. If the remaining time is less than a remaining time threshold, then the buffered data unit may be discarded. The DSR may be reported before the buffered data is discarded, to indicate to the network device 120 the delay status of the LCG, in order to request uplink resources for transmission of the delay-critical data.

[0120] In some example embodiments, if the delay information associated with delay-critical data comprised in the buffered data associated with the LCG satisfies a first condition, the terminal device 110 may determine to trigger the delay status reporting for the LCG. In some examples, the delay information for the LCG may indicate the smallest remaining time value of the running discard timers among all the buffered data units for the LCG. If the smallest remaining time value for the LCG becomes below a first remaining time threshold of the LCG, it may detect that the first condition is satisfied for the LCG. When considering all the buffered data associated with one LCG, the smallest remaining time value may or may not be associated with the first type of buffered data. In the case that the DSR is triggered due to some delay-critical data is found among the buffered data for the LCG, the delay status reporting may still indicate the first size of the mandatory and delay-critical data regardless of whether first delay information associated with the first type of buffered data satisfies the first condition (or more specifically, regardless of whether the smallest remaining time value associated with the first type of buffered data satisfies the first condition) . That is to say, the delay status reporting may be triggered because the remaining time of some delay-critical data of the second type of buffered data is running low. In any case when the delay status reporting is triggered, the terminal device 110 may have a chance to report the size of the mandatory data.

[0121] In some example embodiments, if the DSR is triggered due to some delay-critical data is found among the buffered data for the LCG (e.g., satisfaction of the first condition) ,  the DSR may further indicate a total size of the delay-critical data for the LCG. As such, for an LCG, there may be a first field to indicate the first size of the mandatory and delay-critical data, an optional second field to indicate the second size of the best-effort data, and a field to indicate the total size of the delay-critical data for the LCG.

[0122] In some example embodiments, if first delay information associated with the first type of buffered data satisfies a second condition, the terminal device 110 may determine to trigger delay status reporting for the LCG. For example, if the smallest remaining time value of the running discard timers among the buffered data of the first type becomes below a second remaining time threshold of the first type of buffered data, it may detect that the second condition is satisfied for the LCG. Then the terminal device 110 may trigger reporting of the DSR for the LCG. In this case, the DSR may indicate at least the first size of the mandatory and delay-critical data in the LCG.

[0123] The second condition and the first condition used to trigger the delay status reporting may be the same or may be different. For example, the same remaining time threshold configured for an LCG may be applied also to the first type of buffered data in the LCG. In another example, different remaining time thresholds may be configured for an LCG, and for the first type of buffered data in the LCG.

[0124] In some example embodiments, the network device 120 may transmit (505) , to the terminal device 110, configuration information indicating at least one LCG or LCH that supports separate delay status reporting of the buffered data. If one or more LCHs are configured, it means that an LCG (s) including the configured LCHs may support the separate delay status reporting.

[0125] Here, the separate delay status reporting may include separate fields (e.g., the first field and the second field) for different types of delay-critical buffered data in one LCG, or include a single field for delay-critical data in the first type of buffered data for one LCG. The network device 120 may configure certain LCHs or LCGs for supporting the separate delay status reporting. Such separate delay status reporting may sometimes be referred to as enhanced delay status reporting.

[0126] The terminal device 110 may receive (510) such configuration information and may construct the DSR based on the configuration information, to indicate separate sizes for each configured LCG in the DSR or to indicate only the size of delay-critical and mandatory data for each configured LCG. The terminal device 110 may determine whether  the uplink data is coming from the configured LCG (s) supporting the separate delay status reporting and whether the uplink data comprises at least the first type of data and the second type of data in order to construct the DSR.

[0127] In some example embodiments, instead of the explicit configuration from the network device 120, the terminal device 110 may be pre-configured with some LCGs or LCHs that support the separate delay status reporting. For example, the terminal device 110 may be pre-configured with the LCGs or LCHs that support the separate delay status reporting for buffered data of one or more predetermined types . In some example embodiments, the support of the separate delay status reporting may be configured per terminal device. For example, the network device 120 may configure some of the terminal devices to support the separate delay status reporting while some other terminal devices without such configuration may not be able to report the DSR according to the delay status reporting.

[0128] In some example embodiments, the DSR may further include a field for an LCG reported in the DSR, to indicate delay information. In an embodiment, for an LCG supporting the separate delay status reporting, the field for delay information may indicate the first delay information associated with the first type of buffered data, without indicating second delay information associated with the second type of buffered data. For example, the first delay information may indicate the shortest remaining value of a running discard timer among data units of the first type of buffered data that have not been transmitted before the transmission of the DSR.

[0129] In an alternative embodiment, for an LCG supporting the separate delay status reporting, the field for delay information may indicate delay information associated with the buffered data of the LCG. For example, the field may indicate the shortest remaining value of a running discard timer among data that are buffered for an LCG but have not been transmitted before the transmission of the DSR. In some example embodiments, for an LCG not supporting the separate delay status reporting, the field for delay information may also indicate delay information associated with the buffered data of the LCG.

[0130] In some example embodiments, the DSR may be included in a DSR MAC CE. The terminal device 110 may transmit the DSR MAC CE to the network device 120.

[0131] Various formats may be defined to support the DSR according to the example embodiments of the present disclosure. FIG. 6 illustrates an example DSR format 600 in  accordance with some example embodiments of the present disclosure.

[0132] In the DSR format 600, the field, LCGi, indicates the presence of the Remaining Time and Buffer Size fields for the LCGi. The LCGi field set to 1 indicates that the delay information for the LCGi is reported. The LCGi field set to 0 indicates that the delay information for the LCGi is not reported.

[0133] The “Remaining Time” field indicates the delay information, e.g., the shortest remaining value determined for an LCG supporting or not supporting the separate delay status reporting.

[0134] The field “First Type Buffer Size” indicates the first size of delay-critical data from the first type of buffered data for a logical channel group. The field “Second Type Buffer Size” indicates the second size of delay-critical data from the second type of buffered data for a logical channel group. The field “Second Type Buffer Size” may be optional for a logical channel group.

[0135] The “BT” field is present if the corresponding LCG is configured with an additional parameter additionalBS-TableAllowed and the buffer size indicated by the corresponding Buffer Size field is not zero; otherwise, this field is reserved and set to 0. “R” indicates a reserved bit.

[0136] In the example DSR format 600, the Remaining Time, the BT, and the Buffer Size fields for an LCG may be reported in consecutive octets. These three fields for different LCGs shall be included in a DSR MAC CE in ascending order based on the LCGi.

[0137] Although a field for a buffer size is shown to occupy an octet in FIG. 6, the bit length of a single buffer size for an LCG, or a total bit length of buffer sizes for an LCG may be varied depending on designs of the DSR format. It would be appreciated that the DSR format 600 of FIG. 6 is merely an example. There may be various other DSR formats applicable for the separate buffer status reporting. In some examples, the DSR format 600 may include an additional field for an LCG to indicate a size of non-delay-critical data in the LCG.

[0138] In some example embodiments, one or more LCGs of the terminal device 110 may not support the separate buffer status reporting. Then the DSR may include a single field corresponding to such an LCG to indicate the total size of the buffered data associated with the LCG. For example, in the DSR format 600 of FIG. 6, it is assumed that LCGM  does not support the separate buffer status reporting, and only one field, marked as “Buffer Size M” is included in the DSR for LCGM.

[0139] In some example embodiments, if the buffer size of the first type of buffered data and / or the buffer size of the second type of buffered data for an LCG are reported in the DSR, for example, the sizes of the delay-critical and non-delay-critical data for the first type and / or the second type are reported in the DSR, then the same buffer size (s) may not be reported for the LCG in the BSR. In some example embodiments, if the DSR includes the buffer size information of both the first type and second type of buffered data (e.g., both mandatory data and best-effort data) for an LCG, for example, the sizes of the delay-critical and non-delay-critical data for an LCG are all reported in the DSR, then the BSR for that LCG need not be separately reported to the network side.

[0140] Referring back to FIG. 5, at the network side, the network device 120 receives (530) the DSR from the terminal device 110 and performs (535) resource allocation to the terminal device based at least in part on the first size of the mandatory and delay-critical data indicated for the LCG in the received DSR, to allocate a set of uplink resources.

[0141] The actual resource allocated to the terminal device 110 may depend on various other factors including the size of available uplink resources. As the terminal device 110 specifically indicates the first size of the mandatory and delay-critical data, the network device 120 may determine whether to allocate sufficient uplink resources for transmission of only the first size of mandatory and delay-critical data, for more other or all the types of the buffered delay-critical data, or all the types of buffered data (delay-critical and non-delay-critical data) for the LCG.

[0142] The network device 120 may transmit (540) information indicating the set of uplink resources allocated to the terminal device 110. The terminal device 110 may receive (545) the information indicating the set of uplink resources and determines whether the size of the allocated uplink resources is sufficient to transmit the whole buffered data of an LCG, or may be sufficient to transmit the first type of buffered data. For example, the terminal device 110 may determine which part of the buffered data (mandatory and delay-critical data only, or both mandatory and best-effort delay-critical data, or delay-critical data and part or all of the non-delay-critical data) may be transmitted with the allocated resources.

[0143] In some example embodiments, the terminal device 110 may transmit (555) , to the network device 120, at least the delay-critical data of the first type of buffered data on the  allocated set of uplink resources. The network device 120 may then receive (560) at least the delay-critical data of the first type of buffered data on the allocated set of uplink resources. In some example embodiments, if the size of the allocated set of uplink resources is greater than the first size, the terminal device 110 may transmit, to the network device 120, the delay-critical data of the first type of buffered data and at least a part of delay-critical data of the second type of buffered data, and / or non-delay-critical data for the LCG on the allocated set of uplink resources.

[0144] Through the mechanism of separate delay status reporting, it may enable both efficient radio resource usage and fulfilling QoS requirements in the uplink. According to some example embodiments of the present disclosure, by transmitting the DSR, the buffer status reporting may not be needed, which reduces the uplink resource overhead.

[0145] FIG. 7A shows a flowchart of an example method 700 implemented at a first apparatus in accordance with some example embodiments of the present disclosure. For the purpose of discussion, the first apparatus may be or may be included in the terminal device 110 as shown in FIG. 1. The method 600 will be described from the perspective of the first apparatus.

[0146] At block 710, the first apparatus determines that buffered data associated with a logical channel group, LCG, comprises a first type of buffered data and a second type of buffered data.

[0147] At block 720, the first apparatus determines a first size of the first type of buffered data and a second size of the second type of buffered data.

[0148] At block 730, the first apparatus transmits, to a network device, a buffer status report, BSR, indicating the first size and the second size for the LCG.

[0149] In some example embodiments, the BSR at least comprises a first field and a second field corresponding to the LCG, the first field indicating the first size, and the second field indicating the second size.

[0150] In some example embodiments, the method 700 further comprises: receiving, from the network device, configuration information indicating at least one LCG that supports separate buffer status reporting of the buffered data, the separate buffer status reporting comprising the first field and the second field for one LCG.

[0151] In some example embodiments, the method 700 further comprises: for a further LCG  different from the LCG, determining a size of total buffered data associated with the further LCG or a size of buffered data of the first type associated with the further LCG. In some example embodiments, the BSR further comprises a single field corresponding to the further LCG, to indicate the determined size.

[0152] In some example embodiments, the first type of buffered data comprises data that is mandatory to be transmitted, and the second type of buffered data comprises data to be transmitted on best effort.

[0153] In some example embodiments, the buffered data associated with the LCG comprises at least one of: user data traffic, media access control control element, MAC CE, or channel state information.

[0154] In some example embodiments, the buffered data associated with the LCG comprises a set of packet data units, PDUs, and determining the first size of the first type of buffered data and the second size of the second type of data comprises: determining the first type of buffered data by identifying, from the set of PDUs, a first number of PDUs from which the set of PDUs is to be decoded based on a forward error correction scheme; determining the second type of buffered data by identifying, from the set of PDUs, at least one PDU among the set of PDUs other than the first number of PDUs; and determining the first size of the first type of buffered data and the second size of the second type of data.

[0155] In some example embodiments, the buffered data associated with the LCG comprises channel state information, and determining the first size of the first type of buffered data and the second size of the second type of data comprises: determining the first type of buffered data by identifying, from the channel state information, a first part of channel state information with a variation level exceeding a first variation threshold; determining the second type of buffered data by identifying, from the channel state information, a second part of channel state information with a variation level below a second variation threshold; and determining the first size of the first type of buffered data and the second size of the second type of buffered data.

[0156] In some example embodiments, the method 700 further comprises: receiving, from the network device, information indicating a set of uplink resources allocated to the first apparatus; and transmitting, to the network device, at least the first type of buffered data on the allocated set of uplink resources.

[0157] In some example embodiments, the method 700 further comprises: determining that the size of the allocated set of uplink resources is greater than the first size; and transmitting, to the network device, the first type of buffered data and at least a part of the second type of buffered data on the allocated set of uplink resources.

[0158] In some example embodiments, the method 700 further comprises: transmitting, to the network device, a BSR media access control control element, MAC CE comprising the BSR.

[0159] In some example embodiments, the first apparatus is or is comprised in a terminal device.

[0160] FIG. 7B shows a flowchart of an example method 702 implemented at a second apparatus in accordance with some example embodiments of the present disclosure. For the purpose of discussion, the second apparatus may be or may be included in the network device 120 as shown in FIG. 1. The method 702 will be described from the perspective of the second apparatus.

[0161] At block 712, the second apparatus receives, from a terminal device, a buffer status report, BSR, indicating a first size of a first type of buffered data and a second size of a second type of buffered data for a logical channel group, LCG, of the terminal device, wherein the first type of buffered data and the second type of buffered data are comprised in buffered data associated with the LCG of the terminal device.

[0162] At block 722, the second apparatus performs resource allocation to the terminal device based on the first size and the second size.

[0163] In some example embodiments, the BSR at least comprises a first field and a second field corresponding to the LCG, and wherein the first field indicates the first size, and the second field indicates the second size.

[0164] In some example embodiments, the method 702 further comprises: transmitting, to the terminal device, configuration information indicating at least one LCG that supports separate buffer status reporting of the buffered data, the separate buffer status reporting comprising the first field and the second field for one LCG.

[0165] In some example embodiments, the BSR further comprises a single field corresponding to a further LCG, to indicate a size of total buffered data associated with the further LCG or a size of buffered data of the first type associated with the further LCG,  and wherein the further LCG is different from the LCG.

[0166] In some example embodiments, the first type of buffered data comprises data that is mandatory to be transmitted by the terminal device, and the second type of buffered data comprises data to be transmitted by the terminal device on best effort.

[0167] In some example embodiments, the buffered data associated with the LCG comprises at least one of: user data traffic, media access control control element, MAC CE, or channel state information.

[0168] In some example embodiments, the buffered data associated with the LCG comprises a set of packet data units, PDUs, and wherein the first type of buffered data comprises a first number of PDUs from which the set of PDUs is to be decoded based on a forward error correction scheme, and the second type of buffered data comprises at least one remaining PDU among the set of PDUs other than the first number of PDUs.

[0169] In some example embodiments, the buffered data associated with the LCG comprises channel state information, and wherein the first type of buffered data comprises a first part of channel state information with a variation level exceeding a first variation threshold, and the second type of buffered data comprises a second part of channel state information with a variation level of the second part of channel state information being below a second variation threshold.

[0170] In some example embodiments, the method 702 further comprises: transmitting, to the terminal device and based on a result of the resource allocation, information indicating a set of uplink resources allocated to the terminal device; and receiving, from the terminal device, at least the first type of buffered data on the allocated set of uplink resources.

[0171] In some example embodiments, the method 702 further comprises: in accordance with a determination that the size of the allocated set of uplink resources is greater than the first size, receiving, from the terminal device, the first type of buffered data and at least a part of the second type of buffered data on the allocated set of uplink resources.

[0172] In some example embodiments, the method 702 further comprises: receiving, from the terminal device, a BSR media access control control element, MAC CE comprising the BSR.

[0173] In some example embodiments, the second apparatus is or is comprised in a network device.

[0174] In some example embodiments, a first apparatus capable of performing any of the method 700 (for example, the terminal device 110 or any other target terminal device to be positioned in FIG. 1) may comprise means for performing the respective operations of the method 700 and / or any of the described one or more example embodiments thereof. The means may be implemented in any suitable form. For example, the means may be implemented in a circuitry or software module. The first apparatus may be implemented as or included in the terminal device 110 in FIG. 1. In some example embodiments, a second apparatus capable of performing any of the method 702 (for example, the network device 120 in FIG. 1) may comprise means for performing the respective operations of the method 702 and / or any of the described one or more example embodiments thereof. The means may be implemented in any suitable form. For example, the means may be implemented in a circuitry or software module. The second apparatus may be implemented as or included in the network device 120 in FIG. 1.

[0175] FIG. 8A shows a flowchart of an example method 800 implemented at a first apparatus in accordance with some other example embodiments of the present disclosure. For the purpose of discussion, the first apparatus may be or may be included in the terminal device 110 as shown in FIG. 1. The method 800 will be described from the perspective of the first apparatus.

[0176] At block 810, the first apparatus determines that buffered data associated with a logical channel group, LCG, comprises a first type of buffered data that is mandatory to be transmitted and a second type of buffered data that is to be transmitted on best effort.

[0177] At block 820, the first apparatus determines a first size of delay-critical data from the first type of buffered data comprised in the buffered data.

[0178] At block 830, in accordance with a detection of a trigger of delay status reporting, the first apparatus transmits to a network device, a delay status report, DSR, at least indicating the first size for the LCG.

[0179] In some example embodiments, the DSR indicates the first size, without indicating a second size of delay-critical data from the second type of buffered data.

[0180] In some example embodiments, the DSR at least comprises a first field corresponding to the LCG to indicate the first size.

[0181] In some example embodiments, the DSR indicates both the first size and a second  size of delay-critical data from the second type of buffered data.

[0182] In some example embodiments, the DSR at least comprises a first field and a second field corresponding to the LCG, the first field indicating the first size, and the second field indicating the second size.

[0183] In some example embodiments, the method 800 further comprises: receiving, from the network device, configuration information indicating at least one LCG that supports separate delay status reporting of the buffered data, the separate delay status reporting comprising the first field and the second field for one LCG.

[0184] In some example embodiments, the DSR further indicates a third size of non-delay critical data from the first type of buffered data and the second type of buffered data. In some example embodiments, the DSR further comprises a third field corresponding to the LCG to indicate the third size.

[0185] In some example embodiments, the method 800 further comprises: determining, based on a size of an uplink resource for transmission of the DSR, whether at least one of the second size or the third size is to be indicated in the DSR; and generating the DSR based on the determination of whether at least one of the second size or the third size is to be indicated in the DSR.

[0186] In some example embodiments, the method 800 further comprises: in accordance with a determination that delay information associated with delay-critical data comprised in the buffered data associated with the LCG satisfies a first condition, detecting the trigger of delay status reporting for the LCG. In some example embodiments, the DSR indicates the first size regardless of whether first delay information associated with first type of buffered data satisfies the first condition, and wherein the DSR further indicates a total size of the delay-critical data for the LCG.

[0187] In some example embodiments, the method 800 further comprises: in accordance with a determination that first delay information associated with the first type of buffered data satisfies a second condition, detecting the trigger of delay status reporting for the LCG.

[0188] In some example embodiments, the DSR comprises a fourth field for the buffered data associated with the LCG, the fourth field indicating: first delay information associated with the first type of buffered data, without indicating second delay information  associated with the second type of buffered data, or delay information associated with the buffered data of the LCG.

[0189] In some example embodiments, the buffered data associated with the LCG comprises at least one of: user data traffic, media access control control element, MAC CE, or channel state information.

[0190] In some example embodiments, the buffered data associated with the LCG comprises a set of packet data units, PDUs, and determining the first type of buffered data comprises: determining the first type of buffered data by identifying, from the set of PDUs, a first number of PDUs from which the set of PDUs is to be decoded based on a forward error correction scheme.

[0191] In some example embodiments, the buffered data associated with the LCG comprises channel state information, and determining the first type of buffered data comprises: determining the first type of buffered data by identifying, from the channel state information, a first part of channel state information with a variation level exceeding a first variation threshold; and determining the first size of the first type of buffered data.

[0192] In some example embodiments, the method 800 further comprises: receiving, from the network device, information indicating a set of uplink resources allocated to the first apparatus; and transmitting, to the network device, at least the first type of buffered data on the allocated set of uplink resources.

[0193] In some example embodiments, the method 800 further comprises: determining that the size of the allocated set of uplink resources is greater than the first size; and transmitting, to the network device, the first type of buffered data and at least a part of the second type of buffered data on the allocated set of uplink resources.

[0194] In some example embodiments, transmitting the DSR comprises: transmitting, to the network device, a DSR media access control control element, MAC CE comprising the DSR.

[0195] In some example embodiments, the first apparatus is or is comprised in a terminal device.

[0196] FIG. 8B shows a flowchart of an example method 802 implemented at a second apparatus in accordance with some example embodiments of the present disclosure. For the purpose of discussion, the first apparatus may be or may be included in the network  device 120 in FIG. 1. The method 802 will be described from the perspective of the second apparatus.

[0197] At block 812, the second apparatus receives, from a terminal device, a delay status report, DSR, at least indicating a first size for a logical channel group, LCG, of the terminal device, wherein buffered data associated with the LCG comprises a first type of buffered data that is mandatory to be transmitted and further comprises a second type of buffered data that is to be transmitted on best effort, and the first size is a size of delay-critical data from the first type of buffered data.

[0198] At block 822, the second apparatus performs resource allocation to the terminal device based at least in part on the first size.

[0199] In some example embodiments, the DSR indicates the first size, without indicating a second size of delay-critical data from the second type of buffered data.

[0200] In some example embodiments, the DSR at least comprises a first field corresponding to the LCG to indicate the first size.

[0201] In some example embodiments, the DSR indicates both the first size and a second size of delay-critical data from the second type of buffered data.

[0202] In some example embodiments, the DSR at least comprises a first field and a second field corresponding to the LCG, the first field indicating the first size, and the second field indicating the second size.

[0203] In some example embodiments, the DSR further indicates a third size of non-delay critical data from the first type of buffered data and the second type of buffered data. In some example embodiments, the DSR further comprises a third field corresponding to the LCG to indicate the third size.

[0204] In some example embodiments, the DSR indicates the first size regardless of whether first delay information associated with the first type of buffered data satisfies a first condition.

[0205] In some example embodiments, the DSR indicates the first size based on first delay information associated with the first type of buffered data satisfying a second condition.

[0206] In some example embodiments, the method 802 further comprises: transmitting, to the terminal device, configuration information indicating at least one LCG that supports  separate delay status reporting of the buffered data, the separate delay status reporting comprising the first field and the second field for one LCG.

[0207] In some example embodiments, the DSR comprises a fourth field for the buffered data, the fourth field indicating: first delay information associated with the first type of buffered data, without indicating second delay information associated with the second type of buffered data, or delay information associated with the buffered data of the LCG.

[0208] In some example embodiments, the buffered data associated with the LCG comprises at least one of: user data traffic, media access control control element, MAC CE, or channel state information.

[0209] In some example embodiments, the buffered data associated with the LCG comprises a set of packet data units, PDUs, and wherein the first type of buffered data comprises a first number of PDUs from which the set of PDUs is to be decoded based on a forward error correction scheme.

[0210] In some example embodiments, the buffered data associated with the LCG comprises channel state information, and wherein the first type of buffered data comprises a first part of channel state information with a variation level exceeding a first variation threshold.

[0211] In some example embodiments, the method 802 further comprises: transmitting, to the terminal device and based on a result of the resource allocation, information indicating a set of uplink resources allocated to the terminal device; and receiving, from the terminal device, at least the first type of buffered data on the allocated set of uplink resources.

[0212] In some example embodiments, receiving the first type of buffered data comprises: in accordance with a determination that the size of the allocated set of uplink resources is greater than the first size, receiving, from the terminal device, the first type of buffered data and at least a part of the second type of buffered data on the allocated set of uplink resources.

[0213] In some example embodiments, receiving the DSR comprises: receiving, from the terminal device, a DSR media access control control element, MAC CE comprising the DSR.

[0214] In some example embodiments, the second apparatus is or is comprised in a network device.

[0215] In some example embodiments, a first apparatus capable of performing any of the method 800 (for example, the terminal device 110 in FIG. 1) may comprise means for performing the respective operations of the method 800 and / or any of the described one or more example embodiments thereof. The means may be implemented in any suitable form. For example, the means may be implemented in a circuitry or software module. The first apparatus may be implemented as or included in the terminal device 110 or any other target terminal device to be positioned in FIG. 1. In some example embodiments, a second apparatus capable of performing any of the method 802 (for example, the network device 120 in FIG. 1) may comprise means for performing the respective operations of the method 802 and / or any of the described one or more example embodiments thereof. The means may be implemented in any suitable form. For example, the means may be implemented in a circuitry or software module. The second apparatus may be implemented as or included in the network device 120 in FIG. 1.

[0216] FIG. 9 is a simplified block diagram of a device 900 that is suitable for implementing example embodiments of the present disclosure. The device 900 may be provided to implement a communication device, for example, the terminal device 110 or the network device 120 as shown in FIG. 1. As shown, the device 900 includes one or more processors 910, one or more memories 920 coupled to the processor 910, and one or more communication modules 940 coupled to the processor 910.

[0217] The communication module 940 is for bidirectional communications. The communication module 940 has one or more communication interfaces to facilitate communication with one or more other modules or devices. The communication interfaces may represent any interface that is necessary for communication with other network elements. In some example embodiments, the communication module 940 may include at least one antenna.

[0218] The processor 910 may be of any type suitable to the local technical network and may include one or more of the following: general purpose computers, special purpose computers, microprocessors, digital signal processors (DSPs) and processors based on multicore processor architecture, as non-limiting examples. The device 900 may have multiple processors, such as an application specific integrated circuit chip that is slaved in time to a clock which synchronizes the main processor.

[0219] The memory 920 may include one or more non-volatile memories and one or more  volatile memories. Examples of the non-volatile memories include, but are not limited to, a Read Only Memory (ROM) 924, an electrically programmable read only memory (EPROM) , a flash memory, a hard disk, a compact disc (CD) , a digital video disk (DVD) , an optical disk, a laser disk, and other magnetic storage and / or optical storage. Examples of the volatile memories include, but are not limited to, a random-access memory (RAM) 922 and other volatile memories that will not last in the power-down duration.

[0220] A computer program 930 includes computer executable instructions that are executed by the associated processor 910. The instructions of the program 930 may include instructions for performing operations / acts of some example embodiments of the present disclosure. The program 930 may be stored in the memory, e.g., the ROM 924. The processor 910 may perform any suitable actions and processing by loading the program 930 into the RAM 922.

[0221] The example embodiments of the present disclosure may be implemented by means of the program 930 so that the device 900 may perform any process of the disclosure as discussed with reference to FIG. 3 to FIG. 8B. The example embodiments of the present disclosure may also be implemented by hardware or by a combination of software and hardware.

[0222] In some example embodiments, the program 930 may be tangibly contained in a computer readable medium which may be included in the device 900 (such as in the memory 920) or other storage devices that are accessible by the device 900. The device 900 may load the program 930 from the computer readable medium to the RAM 922 for execution. In some example embodiments, the computer readable medium may include any types of non-transitory storage medium, such as ROM, EPROM, a flash memory, a hard disk, CD, DVD, and the like. The term “non-transitory, ” as used herein, is a limitation of the medium itself (i.e., tangible, not a signal) as opposed to a limitation on data storage persistency (e.g., RAM vs. ROM) .

[0223] FIG. 10 shows an example of the computer readable medium 1000 which may be in form of CD, DVD or other optical storage disk. The computer readable medium 1000 has the program 930 stored thereon.

[0224] Generally, various embodiments of the present disclosure may be implemented in hardware or special purpose circuits, software, logic or any combination thereof. Some aspects may be implemented in hardware, and other aspects may be implemented in  firmware or software which may be executed by a controller, microprocessor or other computing device. Although various aspects of embodiments of the present disclosure are illustrated and described as block diagrams, flowcharts, or using some other pictorial representations, it is to be understood that the block, apparatus, system, technique or method described herein may be implemented in, as non-limiting examples, hardware, software, firmware, special purpose circuits or logic, general purpose hardware or controller or other computing devices, or some combination thereof.

[0225] Some example embodiments of the present disclosure also provide at least one computer program product tangibly stored on a computer readable medium, such as a non-transitory computer readable medium. The computer program product includes computer-executable instructions, such as those included in program modules, being executed in a device on a target physical or virtual processor, to carry out any of the methods as described above. Generally, program modules include routines, programs, libraries, objects, classes, components, data structures, or the like that perform particular tasks or implement particular abstract data types. The functionality of the program modules may be combined or split between program modules as desired in various embodiments. Machine-executable instructions for program modules may be executed within a local or distributed device. In a distributed device, program modules may be located in both local and remote storage media.

[0226] Program code for carrying out methods of the present disclosure may be written in any combination of one or more programming languages. The program code may be provided to a processor or controller of a general purpose computer, special purpose computer, or other programmable data processing apparatus, such that the program code, when executed by the processor or controller, cause the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The program code may execute entirely on a machine, partly on the machine, as a stand-alone software package, partly on the machine and partly on a remote machine or entirely on the remote machine or server.

[0227] In the context of the present disclosure, the computer program code or related data may be carried by any suitable carrier to enable the device, apparatus or processor to perform various processes and operations as described above. Examples of the carrier include a signal, computer readable medium, and the like.

[0228] The computer readable medium may be a computer readable signal medium or a  computer readable storage medium. A computer readable medium may include but not limited to an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. More specific examples of the computer readable storage medium would include an electrical connection having one or more wires, a portable computer diskette, a hard disk, a random access memory (RAM) , a read-only memory (ROM) , an erasable programmable read-only memory (EPROM or Flash memory) , an optical fiber, a portable compact disc read-only memory (CD-ROM) , an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.

[0229] Further, although operations are depicted in a particular order, this should not be understood as requiring that such operations be performed in the particular order shown or in sequential order, or that all illustrated operations be performed, to achieve desirable results. In certain circumstances, multitasking and parallel processing may be advantageous. Likewise, although several specific implementation details are contained in the above discussions, these should not be construed as limitations on the scope of the present disclosure, but rather as descriptions of features that may be specific to particular embodiments. Unless explicitly stated, certain features that are described in the context of separate embodiments may also be implemented in combination in a single embodiment. Conversely, unless explicitly stated, various features that are described in the context of a single embodiment may also be implemented in a plurality of embodiments separately or in any suitable sub-combination.

[0230] Although the present disclosure has been described in languages specific to structural features and / or methodological acts, it is to be understood that the present disclosure defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as example forms of implementing the claims.

Claims

1.A first apparatus comprising:at least one processor; andat least one memory storing instructions that, when executed by the at least one processor, cause the first apparatus at least to:determine that buffered data associated with a logical channel group, LCG, comprises a first type of buffered data that is mandatory to be transmitted and a second type of buffered data that is to be transmitted on best effort;determine a first size of delay-critical data from the first type of buffered data; andin accordance with a detection of a trigger of delay status reporting, transmit, to a network device, a delay status report, DSR, at least indicating the first size for the LCG.2.The first apparatus of claim 1, wherein the DSR indicates the first size, without indicating a second size of delay-critical data from the second type of buffered data.3.The first apparatus of claim 2, wherein the DSR at least comprises a first field corresponding to the LCG to indicate the first size.4.The first apparatus of claim 1, wherein the DSR indicates both the first size and a second size of delay-critical data from the second type of buffered data.5.The first apparatus of claim 4, wherein the DSR at least comprises a first field and a second field corresponding to the LCG, the first field indicating the first size, and the second field indicating the second size.6.The first apparatus of claim 5, wherein the first apparatus is further caused to:receive, from the network device, configuration information indicating at least one LCG that supports separate delay status reporting of the buffered data, the separate delay status reporting comprising the first field and the second field for one LCG.7.The first apparatus of any of claims 1 to 6, wherein the DSR further indicates a third size of non-delay critical data from the first type of buffered data and the second type of buffered data, andwherein the DSR further comprises a third field corresponding to the LCG to indicate the third size.8.The first apparatus of any of claims 2 to 7, wherein the first apparatus is further caused to:determine, based on a size of an uplink resource for transmission of the DSR, whether at least one of the second size or the third size is to be indicated in the DSR; andgenerate the DSR based on the determination of whether at least one of the second size or the third size is to be indicated in the DSR.9.The first apparatus of any of claim1 to 8, wherein the first apparatus is caused to:in accordance with a determination that delay information associated with delay-critical data comprised in the buffered data associated with the LCG satisfies a first condition, detect the trigger of delay status reporting for the LCG, andwherein the DSR indicates the first size regardless of whether first delay information associated with first type of buffered data satisfies the first condition, andwherein the DSR further indicates a total size of the delay-critical data for the LCG.10.The first apparatus of any of claims 1 to 8, wherein the first apparatus is caused to:in accordance with a determination that first delay information associated with the first type of buffered data satisfies a second condition, detect the trigger of delay status reporting for the LCG.11.The first apparatus of any of claims 1 to 10, wherein the DSR comprises a fourth field for the buffered data associated with the LCG, the fourth field indicating:first delay information associated with the first type of buffered data, without indicating second delay information associated with the second type of buffered data, ordelay information associated with the buffered data of the LCG.12.The first apparatus of any of claims 1 to 11, wherein the buffered data associated with the LCG comprises at least one of:user data traffic,media access control control element, MAC CE, orchannel state information.13.The first apparatus of any of claims 1 to 12, wherein the buffered data associated with the LCG comprises a set of packet data units, PDUs, and wherein the first apparatus is caused to:determine the first type of buffered data by identifying, from the set of PDUs, a first number of PDUs from which the set of PDUs is to be decoded based on a forward error correction scheme.14.The first apparatus of any of claims 1 to 12, wherein the buffered data associated with the LCG comprises channel state information, and wherein the first apparatus is caused to:determine the first type of buffered data by identifying, from the channel state information, a first part of channel state information with a variation level exceeding a first variation threshold; anddetermine the first size of the first type of buffered data.15.The first apparatus of any of claims 1 to 14, wherein the first apparatus is further caused to:receive, from the network device, information indicating a set of uplink resources allocated to the first apparatus; andtransmit, to the network device, at least the delay-critical data of the first type of buffered data on the allocated set of uplink resources.16.The first apparatus of claim 15, wherein the first apparatus is caused to:determine that the size of the allocated set of uplink resources is greater than the first size; andtransmit, to the network device, the delay-critical data of the first type of buffered data and at least a part of delay-critical data of the second type of buffered data on the allocated set of uplink resources.17.The first apparatus of any of claims 1 to 16, wherein the first apparatus is caused to:transmit, to the network device, a DSR media access control control element, MAC CE comprising the DSR.18.The first apparatus of any of claims 1 to 17, wherein the first apparatus is or is comprised in a terminal device.19.A second apparatus comprising:at least one processor; andat least one memory storing instructions that, when executed by the at least one processor, cause the second apparatus at least to:receive, from a terminal device, a delay status report, DSR, at least indicating a first size for a logical channel group, LCG, of the terminal device, wherein buffered data associated with the LCG comprises a first type of buffered data that is mandatory to be transmitted and further comprises a second type of buffered data that is to be transmitted on best effort, and the first size is a size of delay-critical data from the first type of buffered data; andperform resource allocation to the terminal device based at least in part on the first size.20.The second apparatus of claim 19, wherein the DSR indicates the first size, without indicating a second size of delay-critical data from the second type of buffered data.21.The second apparatus of claim 20, wherein the DSR at least comprises a first field corresponding to the LCG to indicate the first size.22.The second apparatus of claim 19, wherein the DSR indicates both the first size and a second size determined of delay-critical data from the second type of buffered data.23.The second apparatus of claim 22, wherein the DSR at least comprises a first field and a second field corresponding to the LCG, the first field indicating the first size, and the second field indicating the second size.24.The second apparatus of any of claims 19 to 23, wherein the DSR further indicates a third size of non-delay critical data from the first type of buffered data and the second type of buffered data, andwherein the DSR further comprises a third field corresponding to the LCG to indicate the third size.25.The second apparatus of any of claims 19 to 24, wherein the DSR indicates the first size regardless of whether first delay information associated with the first type of buffered data satisfies a first condition.26.The second apparatus of any of claims 19 to 25, wherein the DSR indicates the first size based on first delay information associated with the first type of buffered data satisfying a second condition.27.The second apparatus of claim 23, wherein the second apparatus is further caused to:transmit, to the terminal device, configuration information indicating at least one LCG that supports separate delay status reporting of the buffered data, the separate delay status reporting comprising the first field and the second field for one LCG.28.The second apparatus of any of claims 19 to 27, wherein the DSR comprises a fourth field for the buffered data, the fourth field indicating:first delay information associated with the first type of buffered data, without indicating second delay information associated with the second type of buffered data, ordelay information associated with the buffered data of the LCG.29.The second apparatus of any of claims 19 to 28, wherein the buffered data associated with the LCG comprises at least one of:user data traffic,media access control control element, MAC CE, orchannel state information.30.The second apparatus of any of claims 19 to 29, wherein the buffered data associated with the LCG comprises a set of packet data units, PDUs, andwherein the first type of buffered data comprises a first number of PDUs from which the set of PDUs is to be decoded based on a forward error correction scheme.31.The second apparatus of any of claims 19 to 29, wherein the buffered data associated  with the LCG comprises channel state information, andwherein the first type of buffered data comprises a first part of channel state information with a variation level exceeding a first variation threshold.32.The second apparatus of any of claims 19 to 31, wherein the second apparatus is further caused to:transmit, to the terminal device and based on a result of the resource allocation, information indicating a set of uplink resources allocated to the terminal device; andreceive, from the terminal device, at least the delay-critical data of the first type of buffered data on the allocated set of uplink resources.33.The second apparatus of any of claims 19 to 32, wherein the second apparatus is further caused to:in accordance with a determination that the size of the allocated set of uplink resources is greater than the first size, receive, from the terminal device, the delay-critical data of the first type of buffered data and at least a part of delay-critical data of the second type of buffered data on the allocated set of uplink resources.34.The second apparatus of any of claims 19 to 33, wherein the second apparatus is caused to receive the DSR by:receiving, from the terminal device, a DSR media access control control element, MAC CE comprising the DSR.35.The second apparatus of any of claims 19 to 34, wherein the second apparatus is or is comprised in a network device.36.A method comprising:determining that buffered data associated with a logical channel group, LCG, comprises a first type of buffered data that is mandatory to be transmitted and a second type of buffered data that is to be transmitted on best effort;determining a first size of delay-critical data from the first type of buffered data; andin accordance with a detection of a trigger of delay status reporting, transmitting to a network device, a delay status report, DSR, at least indicating the first size for the LCG.37.A method comprising:receiving, from a terminal device, a delay status report, DSR, at least indicating a first size for a logical channel group, LCG, of the terminal device, wherein buffered data associated with the LCG comprises a first type of buffered data that is mandatory to be transmitted and further comprises a second type of buffered data that is to be transmitted on best effort, and the first size is a size of delay-critical data from the first type of buffered data; andperforming resource allocation to the terminal device based at least in part on the first size.38.A first apparatus comprising:means for determining that buffered data associated with a logical channel group, LCG, comprises a first type of buffered data that is mandatory to be transmitted and a second type of buffered data that is to be transmitted on best effort;means for determining a first size of delay-critical data from the first type of buffered data; andmeans for in accordance with a detection of a trigger of delay status reporting, transmitting to a network device, a delay status report, DSR, at least indicating the first size for the LCG.39.A second apparatus comprising:means for receiving, from a terminal device, a delay status report, DSR, at least indicating a first size for a logical channel group, LCG, of the terminal device, wherein buffered data associated with the LCG comprises a first type of buffered data that is mandatory to be transmitted and further comprises a second type of buffered data that is to be transmitted on best effort, and the first size is a size of delay-critical data from the first type of buffered data; andmeans for performing resource allocation to the terminal device based at least in part on the first size.40.A computer readable medium comprising instructions stored thereon for causing an apparatus at least to perform the method of claim 37 or the method of claim 38.

Images