Method for buffer status reporting in communication network

Abstract

A method for reporting a buffer status of data to be transmitted on a logical channel group of a communication network, the logical channel group being configured to carry a plurality of sets of protocol data units (PDU sets) associated with a first section and a second section of the logical channel group, each of the first and second segments is associated with at least one set of PDUs, the communication network comprising a user equipment and a base station wherein the method comprises, at the user equipment, transmitting a status report for reporting a buffer status of the first and second segments to the base station, the status report includes information indicating an amount of data associated with the first segment and the second segment, where the status report is transmitted based on a drop timer value associated with at least one of the first segment and the second segment.

Description

Method for reporting buffer status in communication networks Technical Field

[0001] This disclosure relates to a method for reporting the buffer status of data to be transmitted over a communication network (e.g., a mobile telecommunications network). More specifically, the method relates to transmitting a status report (e.g., a delay status report) from a user equipment (UE) of the communication network to a base station (gNB). Background Technology

[0002] Wireless communication systems are deployed to address a wide range of applications, including mobile broadband, massive machine-type communications, and ultra-reliable low-latency communication (URLLC). Such systems allow multiple user equipment (UEs) or mobile terminals to share a wireless medium to exchange different types of data content (e.g., video, voice, messaging, etc.) over a radio access network (RAN) via one or more base stations.

[0003] Examples of such wireless multiple access communication systems include systems based on the 3rd Generation Partnership Project (3GPP-RTM) standards, such as fourth-generation (4G) Long Term Evolution (LTE) and (more recently) fifth-generation (5G) New Radio (NR) systems, or systems based on the IEEE 802.11 standard, such as Wi-Fi. Among the requirements for 5G NR, there are service requirements related to Extended Reality (XR).

[0004] XR (Extended Reality) applications are defined in 3GPP document RP-2200285 as "various types of augmented, virtual, and hybrid environments in which human-to-machine and human-to-human communication is assisted by handheld and wearable end-user devices." Various use cases can be found in 3GPP document TR-26.928.

[0005] Many XR applications involve interaction between wearable devices (e.g., 3D helmets or augmented reality glasses) and application servers. Wearable devices and application servers can connect via local networks (e.g., wireless LAN) or cellular networks (e.g., 3GPP 5G cellular networks, where the application server connects to the network's 5G core network components).

[0006] Some XR applications (such as cloud gaming) involve transmitting compressed video data and audio data from the server to the user interface (UE) and transmitting location information from the UE to the server.

[0007] Some XR applications (such as virtual reality) involve transmitting compressed video data, audio data, and various information from a server to a wearable device.

[0008] Some XR applications (such as augmented reality) involve transmitting compressed video data, audio data, and various other information exchanged between wearable devices and servers.

[0009] In this disclosure, the information exchanged between the UE (e.g., a wearable device) and the server is referred to as application data, which may include one or more images, video data, audio data, location information, etc.

[0010] Video and audio data are transmitted between a UE (e.g., a wearable device) and a server using media delivery protocols such as RTP (Real-Time Protocol, RFC 3550), SRTP (Secure RTP, RFC 3711), HTTP (Hypertext Transfer Protocol, RFC 2616-7540), or QUIC (RFC 8999, 9000, 9001, and 9002).

[0011] Video encoding and decoding can be performed according to various formats, including MPEG2, H.264, H.265, HEVC, etc. Specifically, applications generate data (e.g., application data) in the form of encoded video, audio, or location information. This application data is primarily arranged by the application within data packets. For example, application data packets representing a single unit of information can be generated at the application level.

[0012] According to the 3GPP standard, a set of Protocol Data Units (PDUs) or Packet Data Units (PDUs) is required to deliver application data packets (i.e., a "PDU set"). Therefore, application data includes one or more application data packets. During downlink, the 3GPP PDU is formatted by the PDU layer of the core network. Similarly, during uplink, the 3GPP PDU is formatted by the PDU layer of the UE (e.g., a wearable device). According to the 3GPP standard, the constraints of the PDU set (e.g., start, stop, and length) are not provided by the application but are generated by the core network (and correspondingly the UE) through Media Delivery Protocol packet checking. Detailed procedures can be found in 3GPP document S2-2302696.

[0013] A PDU set includes one or more PDUs carrying a payload of an information unit generated at the application level (e.g., a frame or video strip used for XRM services, as used in TR 26.926). In some implementations, the application layer requires all PDUs in the PDU set to use the corresponding information unit. For example, a PDU set may include data from an image or frame from a video stream. In other implementations, the application layer can still recover some or all of the information units when some PDUs are missing.

[0014] The network used to transmit application data may experience disturbances and congestion. As a result, some PDUs in the PDU set may be missing or delayed on the receiving side (e.g., UE PDU layer during downlink and core network user plane function (UPF) during uplink).

[0015] Some video decoder implementations require timely receipt of complete application data packets (e.g., a complete set of PDUs) for adequate video decoding. Other implementations can tolerate delayed packet arrival or partial packet delivery. These implementations, for example, rely on forward error correction (FEC) or hiding techniques.

[0016] According to the 3GPP standard, document S2-2302696 defines a PDU set QoS parameter called the PDU set Delay Budget (PDSB). The PDSB defines the time budget allocated for delivering PDU sets across the 5G network. This QoS parameter, defined by the application, is used by the 5G network to evaluate whether PDU sets (e.g., application packets) are delivered on time.

[0017] In the same 3GPP document S2-2302696, another QoS parameter named PDU Integrated Disposal Indicator (PSIHI) is defined to characterize the decoder's tolerance for data loss or reception of outdated (e.g., delayed) data. If the PSIHI parameter is set to "true", the decoder can only dispose of (e.g., manage or process) complete application packets received on time. If the PSIHI parameter is set to "false", the decoder can tolerate both incomplete application packets and delayed application packets.

[0018] Considering the specific circumstances at certain components of a 5G network, some information regarding the reception status of PDUs and the elapsed time of PDSBs is available when a set of PDUs is transmitted over the air interface. For example, when a set of PDUs is transmitted over the air, a Radio Access Network (RAN) node (e.g., a UE or Next Generation Node (gNB)) can detect that a PDU transmission has failed (regardless of full retransmission and error correction mechanisms). In this case, if the PSIHI parameter is set to "true," the entire set of PDUs is useless to the application. In this situation, if one or more PDUs in the "useless" PDU set are pending transmissions on the air interface, the RAN node can consider discarding the remaining transmissions of the "useless" PDUs, thereby saving radio network resources.

[0019] In a 5G network, the gNB (i.e., the base station) is responsible for scheduling uplink traffic. The gNB allocates radio resources to each UE based on one of the following mechanisms:

[0020] - Dynamic request scheduling performed by each UE;

[0021] Semi-static scheduling performed by the gNB, where the gNB can issue periodic resource allocations to a UE; and

[0022] - Buffer Status Reports (BSRs) performed by each UE, indicating the amount of data available for uplink transmission.

[0023] BSR operates on Logical Channel Groups (LCGs), which group multiple MAC Logical Channels (LCHs) together. BSR triggering conditions and formats, as defined in 3GPP document TS 38.321, guide the transmission of available data prepared for uplink transmissions for each LCG. Based on this knowledge, the gNB is then able to perform resource scheduling. For example, the gNB can decide to favor the LCG with the most available data while preventing resource starvation on low-throughput LCGs.

[0024] In some situations, multiple PDU sets can be multiplexed within a single logical channel. Known BSR reporting methods configure the UE to systematically report the latency of each PDU set across multiple sets, which can result in significant overhead within the network. Furthermore, adding latency information to the BSR may be unsuitable in this scenario because the reported buffered data may be associated with potentially different latency periods (i.e., because they belong to different PDU sets).

[0025] In scenarios related to XR applications, some XR data may have a PDSB (Programmable Delay Buffer) that cannot be exceeded because the data becomes obsolete and useless after the latency period has elapsed. In such cases, when making scheduling decisions, the scheduler must know the remaining time (e.g., the remaining latency budget) allocated to the XR data.

[0026] Therefore, a method is needed to configure a communication network to manage the transmission and latency of PDUs, ensuring that base stations do not lose data while minimizing network overhead. Summary of the Invention

[0027] According to embodiments of this disclosure, a method is provided for configuring a RAN node of a communication network (e.g., a UE) to report the status of data (e.g., one or more data packets) ready for transmission across a network (e.g., to a gNB). The data ready for transmission across the network can be considered to be buffered. Therefore, the reported status information can be referred to as a "buffer status" (i.e., related to the buffered data). The content of the status report can relate to the content of the buffered data (e.g., the amount of data) and the delay timing of the buffered data (e.g., the remaining time before the transmission delay will cause the data to become outdated). Therefore, the status report can be referred to as a delay status report.

[0028] Buffer status can be transmitted through status reports (e.g., delay status reports) that are configured (e.g., divided) into multiple segments, wherein each segment can be configured such that multiple packets with similar buffer status can be associated with the same segment.

[0029] According to embodiments of this disclosure (e.g., the first and second embodiments), a status report for at least two of a plurality of segments (e.g., the first and second segments) may include an indication of the amount of data to be transmitted from each of the at least two segments. The status report is transmitted based on timing information (e.g., a remaining time value or a discard timer value) corresponding to at least one of the segments (e.g., one or more of the at least two segments). In this way, the method enables the receiving RAN node to receive individual signals for each channel (e.g., a logical channel group) and to predict when a set of data packets will elapse, allowing the node to allocate network resources more efficiently while reducing network transmission load.

[0030] According to alternative embodiments of this disclosure (e.g., the third and fourth embodiments), the status report may (e.g., for at least one or all of a plurality of segments) include an indication of the amount of data to be transmitted, and an indication of the remaining time before the segment elapses. In this way, the method enables the receiving RAN node to predict when a set of data packets will elapse, thereby allowing the node to allocate network resources more efficiently while also reducing network transmission load.

[0031] According to other embodiments of this disclosure (e.g., embodiments five through eight), status reports can be transmitted based on the satisfaction of triggering and reporting conditions. The reporting and / or triggering conditions can be configurable in response to changes in network requirements (e.g., via the network or user equipment). Triggering conditions can be associated with parameters of a logical channel group (e.g., timing information corresponding to at least one segment in the segments (such as discarded timer values), or an indication that resources and / or data have been allocated to the logical channel group). Reporting conditions can be associated with timing information (e.g., remaining time values) and / or the amount of data (e.g., data volume) of at least one segment in the segments. For example, the amount of data associated with at least one segment among multiple segments can become reportable when a corresponding reporting threshold is reached. In this way, the method enables the triggering and reporting conditions to be configured individually (e.g., via dynamic control of the network) or jointly (e.g., via a network that predefines different triggering and reporting conditions in a set of configuration files, which can be selected by the user equipment or the network) in response to changing operational requirements.

[0032] According to other embodiments of this disclosure (e.g., embodiments nine through twelfth), a status report can be transmitted based on data (e.g., PDUs or sets of PDUs) from at least one segment that has already been reported in a previous status report (i.e., a status report occurring at a time prior to the status report triggered by this method) and a triggering condition associated with the previously reported data. The triggering condition may indicate that the previously reported data is delay-critical but has been assigned a lower priority (e.g., in a transmission buffer) than non-delay-critical data. In this way, by reporting previously reported data a second time, the method reduces the possibility of losing unsent (critical) data that has been downgraded but can still be transmitted.

[0033] According to another embodiment of this disclosure (e.g., the thirteenth embodiment), the status report can be configured to provide an indication of the relative priority status of data in the transmission buffer (e.g., the relative position (or order) of data associated with a corresponding segment within the transmission buffer). In this way, the network is informed of the relative ordering of data ready for transmission, enabling decisions regarding network resource allocation.

[0034] According to a first embodiment of this disclosure, a method is provided for reporting the buffer status of data to be transmitted on a Logical Channel Group (LCG) of a communication network. The LCG is adapted to carry multiple sets of Protocol Data Units (PDU sets) associated with a first segment and a second segment of the LCG (e.g., the LCG is subdivided into multiple segments including a first segment and a second segment), wherein each segment in the first and second segments is associated with at least one PDU set. The communication network includes user equipment and a base station. At the user equipment, the method includes transmitting a status report for reporting the buffer status of the first and second segments to the base station, the status report including information indicating the amount of data associated with the first and second segments (e.g., the first segment may be associated with a first PDU set (e.g., a first plurality of PDU sets), and the second segment may be associated with a second PDU set (e.g., a second plurality of PDU sets) different from the first PDU set). The status report is transmitted based on a discard timer value associated with at least one of the first and second segments.

[0035] According to a second embodiment of this disclosure, a method is provided for reporting the buffer status of data to be transmitted on a logical channel group of a communication network. The logical channel group is adapted to carry a plurality of Protocol Data Unit sets (PDU sets) associated with a first segment and a second segment of the logical channel group, wherein each segment in the first and second segments is associated with at least one PDU set. The communication network includes user equipment and a base station. The method at the base station includes: receiving a status report for reporting the buffer status of the first and second segments to the base station, the status report including information indicating the amount of data associated with the first and second segments, wherein the status report is transmitted based on a discard timer value associated with at least one of the first and second segments; and configuring a timer associated with at least one of the first and second segments based on the information indicating the amount of data associated with the first and second segments.

[0036] As described above, known status reporting methods configure user equipment to systematically report the latency of each of multiple PDU sets multiplexed in a single logical channel. This known reporting method can lead to significant overhead within the network. Furthermore, adding latency information to the status report may be unsuitable because the reported buffered data may be associated with potentially different latency periods (i.e., because they belong to different PDU sets). The methods according to the first and second embodiments enable user equipment to transmit a single signal that provides an indication of data carried by two or more segments of a single channel, allowing the base station to easily predict when a set of data packets will pass. This advantageously allows for more efficient allocation of network resources while also reducing network transmission load.

[0037] According to a third embodiment of this disclosure, a method is provided for reporting the buffer status of data (e.g., Protocol Data Units (PDUs) and / or PDU sets) to be transmitted on a Logical Channel Group (LCG) of a communication network, the communication network including user equipment and base stations. The method at the user equipment includes: determining, based on timing information of a plurality of PDUs / PDU sets, a plurality of segments for association with (e.g., one or more PDU sets) of a plurality of Protocol Data Units and / or a plurality of PDU sets; and transmitting a status report for reporting the buffer status of the plurality of segments to the base station. The status report includes, for at least one segment, a buffer size value indicating the amount of data of at least one PDU (and / or PDU set) associated with the at least one segment, and a timer value for the at least one segment.

[0038] According to a fourth embodiment of this disclosure, a method is provided for reporting the buffer status of data to be transmitted on a Logical Channel Group (LCG) of a communication network, the communication network including user equipment and a base station. The method at the base station includes: identifying multiple segments associated with (e.g., in one or more PDU sets) multiple PDUs and / or multiple PDU sets based on timing information of multiple PDUs / PDU sets; receiving a status report for reporting the buffer status of the multiple segments to the base station. The status report includes, for at least one segment, a buffer size value indicating the amount of data of at least one PDU (and / or PDU set) associated with the at least one segment, and a timer value for the at least one segment; and configuring a timer associated with the at least one segment based on the timer value.

[0039] According to a fifth embodiment of this disclosure, a method is provided for reporting the buffer status of data to be transmitted on a logical channel group of a communication network, the logical channel group being used to carry a plurality of protocol data unit sets (PDU sets) associated with a plurality of segments, each of the plurality of segments being associated with a reporting threshold, wherein the amount of data associated with at least one of the plurality of segments becomes reportable when the corresponding reporting threshold is reached, the communication network including user equipment and base stations, wherein the method at the user equipment includes: transmitting a status report for reporting the buffer status of at least one of the plurality of segments that has reached a reporting threshold based on a trigger threshold being reached, wherein the trigger threshold and the reporting threshold for the plurality of segments are configurable.

[0040] According to a sixth embodiment of this disclosure, a method is provided for reporting the buffer status of data to be transmitted on a logical channel group of a communication network, the logical channel group carrying a plurality of protocol data unit sets (PDU sets) associated with a plurality of segments, each of the plurality of segments being associated with a reporting threshold, wherein the amount of data associated with at least one of the plurality of segments becomes reportable when a corresponding reporting threshold is reached, the communication network including user equipment and a base station, wherein the method at the base station includes: receiving a status report for reporting the buffer status of at least one of the plurality of segments that has reached a reporting threshold, wherein the status report is transmitted based on a trigger threshold being reached, wherein the trigger threshold and the reporting threshold for the plurality of segments are configurable; and configuring a timer associated with at least one segment based on the status report.

[0041] According to a seventh embodiment of this disclosure, a method is provided for reporting the buffer status of data to be transmitted on a logical channel group of a communication network, the logical channel group being used to carry multiple PDUs (e.g., from one or more PDU sets) associated with a first segment and a second segment (e.g., multiple segments) of the logical channel group, wherein each segment in the first segment and the second segment is associated with at least one PDU set, the communication network including a user equipment and a base station, wherein the method at the user equipment includes: transmitting a status report for reporting the buffer status of the first segment and the second segment to the base station, the status report including information indicating the amount of data (e.g., data volume) associated with the first segment and the second segment, wherein the status report is transmitted based on a trigger threshold associated with the logical channel group and at least one reporting threshold indicating the remaining time of data in at least one of the first segment and the second segment.

[0042] According to an eighth embodiment of this disclosure, a method is provided for reporting the buffer status of data to be transmitted on a logical channel group of a communication network, the logical channel group being used to carry multiple PDUs (e.g., from one or more PDU sets) associated with a first segment and a second segment (e.g., multiple segments) of the logical channel group, wherein each segment in the first segment and the second segment is associated with at least one PDU set, the communication network including user equipment and a base station, the method at the base station including: receiving a status report for reporting the buffer status of the first segment and the second segment to the base station, the status report including information indicating the amount of data (e.g., data volume) associated with the first segment and the second segment, wherein the status report is transmitted based on a trigger threshold associated with the logical channel group and at least one reporting threshold indicating the remaining time of data in the first segment and the second segment; and configuring a timer associated with at least one segment in the first segment and the second segment based on the information indicating the amount of data associated with at least one segment in the first segment and the second segment.

[0043] According to a ninth embodiment of this disclosure, a method is provided for reporting the buffer status of data to be transmitted on a logical channel group of a communication network, the logical channel group being used to carry a plurality of protocol data unit sets (PDU sets) associated with a plurality of segments, the communication network including user equipment and base stations, wherein the method at the user equipment includes: transmitting a status report for reporting the buffer status of at least one segment based on a data volume in one of the plurality of segments reaching a trigger threshold, wherein the data volume has previously triggered a previous status report regarding non-delay critical data.

[0044] According to a tenth embodiment of this disclosure, a method is provided for reporting the buffer status of data to be transmitted on a logical channel group of a communication network, the logical channel group carrying a plurality of protocol data unit sets (PDU sets) associated with a plurality of segments, the communication network including user equipment and base stations, wherein the method at the base station includes: receiving a status report for reporting the buffer status of at least one of the plurality of segments, wherein the status report is transmitted based on the data volume of at least one of the plurality of segments reaching a trigger threshold, wherein the data volume has previously triggered a previous status report reporting non-time-critical data; and configuring a timer associated with the at least one segment based on the status report.

[0045] According to an eleventh embodiment of this disclosure, a method is provided for reporting the buffer status of data to be transmitted on a logical channel group of a communication network, the logical channel group being used to carry multiple PDUs (e.g., from one or more PDU sets) associated with a first segment and a second segment (e.g., multiple segments) of the logical channel group, wherein each segment in the first segment and the second segment is associated with at least one PDU set, the communication network including user equipment and a base station, wherein the method at the user equipment includes: transmitting a status report for reporting the buffer status of the first segment and the second segment to the base station, the status report including information indicating the amount (e.g., data volume) of data associated with the first segment and the second segment, wherein the status report is transmitted based on data from at least one segment in the first segment and the second segment that has been reported in a previous status report, and triggering conditions associated with the previously reported data.

[0046] According to a twelfth embodiment of this disclosure, a method is provided for reporting the buffer status of data to be transmitted on a logical channel group of a communication network, the logical channel group being used to carry multiple PDUs (e.g., from one or more PDU sets) associated with a first segment and a second segment (e.g., multiple segments) of the logical channel group, wherein each segment in the first segment and the second segment is associated with at least one PDU set, the communication network including user equipment and a base station, the method at the base station including: receiving a status report for reporting the buffer status of the first segment and the second segment to the base station, the status report including information indicating the amount of data (e.g., data volume) associated with the first segment and the second segment, wherein the status report is transmitted based on data of at least one segment in the first segment and the second segment that has been reported in a previous status report, and triggering conditions associated with the previously reported data; and configuring a timer associated with at least one segment in the first segment and the second segment based on the information indicating the amount of data associated with the first segment and the second segment.

[0047] According to a thirteenth embodiment of this disclosure, a method is provided for reporting the buffer status of data to be transmitted on a logical channel group of a communication network for carrying a plurality of protocol data unit sets (PDU sets) associated with a plurality of segments, the communication network including user equipment and base stations, wherein the method at the user equipment includes: transmitting a status report for reporting the buffer status of a first segment and a second segment to the base station, the status report including information indicating the amount of data associated with the first segment and the second segment, wherein if a discard timer value associated with the first segment is critical and a discard timer value associated with the second segment is non-critical, the status report is configured such that the first segment and the second segment are arranged according to their respective positions in a transmission buffer (e.g., the logical channel group).

[0048] As mentioned above, known scheduling methods (e.g., those relying on buffer status reports) allocate resources based on the amount of available data. This approach is time-agnostic, meaning that critical traffic may be delayed, causing receiving nodes to miss data delivery within the required timeframe.

[0049] According to known methods for controlling communication networks, in cases of critical delays, multiple buffer sizes and bit flag warnings are reported for a single LCG. Using this known method, the delay value itself is not communicated to the base station, so the base station must interpret the bit flag warning information as an emergency. Therefore, the base station cannot anticipate delayed data arrival. Furthermore, because status reports are transmitted based on resource availability, and because status reports tend to be descheduled due to the availability of higher-priority data, it is impossible to guarantee that delay status will arrive at the base station on time (regardless of bit flag warnings). Moreover, the reporting mechanism is ineffective unless additional reporting triggers are defined so that a status report is sent regardless when the delay becomes critical (but the data count remains unchanged), thus increasing network overhead.

[0050] Another known method for controlling a communication network involves systematically providing buffer size and delay status information for each data portion of the LCG. This incurs significant overhead and is inconsistent with best practices for the careful use of radio resources.

[0051] Embodiments of this disclosure provide a time-sensitive scheduling method that enables the timely delivery of critical information (e.g., PDUs). Furthermore, embodiments of this disclosure allow traffic with different latency requirements to be conveniently organized into one or more segments on a single channel (or multiple channels). The buffer sizes and timer values ​​for different segments can be transmitted in status reports (e.g., when new data is ready to be transmitted to the network). This enables early communication of latency information to the base station, ensuring that deadlines are not missed, while reducing network overhead (e.g., because latency information for a segment only needs to be sent once).

[0052] Upon receiving a status report from this disclosure, the base station can implement a remaining time counter for each segment. This allows the base station to closely monitor the evolution of both available data and remaining time for each segment. Consequently, the base station can make advantageous scheduling decisions based on comprehensive knowledge of both conventional logical channel groups and time-sensitive logical channel groups with associated segments.

[0053] A number of optional features are set forth in the following paragraphs. These features may be applied individually or in any combination with any embodiment of this disclosure.

[0054] Although this method is described with reference to (e.g., a communication network) a UE and a base station, it should be understood that the method will be applied to any suitable component of a communication network that includes a transmitting component (e.g., a transmitter) and / or a receiving component (e.g., a receiver).

[0055] A PDU set may include at least one PDU (e.g., multiple PDUs). Timing information for the PDU set is also included. In an embodiment, two or more PDUs from the same PDU set may be assigned to the same segment.

[0056] A collection of PDUs (and / or the PDUs included therein) may have associated timing information (e.g., measured in time units, such as seconds). The timing information may include timing parameters or timer values ​​(e.g., discard timer values) that can indicate when a packet will pass or expire (e.g., PDU discard timer values ​​and / or the collection of PDUs discard timer values).

[0057] (For example, in an LCG) multiple segments can define a portion or part of a status report to which one or more PDU sets (and / or PDUs) can be associated (or assigned). At least one or more segments can be determined based on timing information of at least one or each of the multiple PDU sets (and / or PDUs).

[0058] At least one or each of the segments can be configured with a corresponding timer value. The timer value can define the duration (or lifetime) of the segment (e.g., a time period, before which the segment can be discarded). Each segment in a plurality of segments can be associated with a separate timer. For example, a timer can be set with an initial timer value determined by timing information associated with the set of PDUs assigned to the corresponding segment. Once the set of PDUs is assigned to a segment, a segment timer can be initiated to count down from the initial timer value.

[0059] The following paragraphs summarize several optional features particularly relevant to the first and second embodiments of this disclosure, but these features may also be applied to other embodiments described herein.

[0060] A status report can be transmitted if the discard timer value associated with at least one or both of the first and second segments does not exceed (e.g., less than (i.e., numerically smaller) or equal to) a predetermined timer threshold.

[0061] A status report can be transmitted if the discard timer value associated with the first segment does not exceed (e.g., less than (i.e., numerically smaller) or equal to) a timer threshold. Optionally, the discard timer value associated with the second segment can be greater than (e.g., larger or numerically larger) the timer threshold. Furthermore, the discard timer value associated with the second segment can be within a predetermined range of the timer threshold. For example, the first segment may have already reached the threshold (i.e., thus triggering report transmission). However, the second segment may not have reached the threshold yet. However, if the discard timer value of the second segment is close to the threshold (e.g., such that it will soon reach the threshold) when transmitting the status report, information indicating data from the second segment is included in the status report along with data indication for the first segment. In this way, the method minimizes the number of reports transmitted to the base station, which thus reduces overhead within the network.

[0062] A status report can be transmitted if the drop timer values ​​associated with each segment in the first and second segments do not exceed the timer threshold. Optionally, the drop timer value associated with the first segment may be closer to the timer threshold than the drop timer value associated with the second segment. For example, the second segment may have just reached the threshold, while the first segment may have reached the threshold some time ago (and has fallen below the threshold). Therefore, the first segment may include packets that have already been reported in previous status reports. However, one or more of the reported packets may still remain in the first segment (and / or additional packets may have been added to the first segment during an intermediate period) and may not have expired yet. Therefore, these packets may also be reported when the second segment is reported.

[0063] In an embodiment, the status report may include information associated with at least three segments (e.g., a first segment, a second segment, and a third segment). A status report may be transmitted if the discard timer values ​​associated with each of the first and second segments do not exceed a timer threshold. The discard timer value associated with the first segment may be closer to the timer threshold than the discard timer value associated with the second segment. Furthermore, the discard timer value associated with the third segment may be greater than the timer threshold (and optionally within a predetermined range of the timer threshold).

[0064] The method may include transmitting a first status report if the discard timer value associated with the first segment does not exceed (e.g., is less than (i.e., numerically smaller) or equal to) a timer threshold. The first status report may include information indicating the amount of data associated with at least one set of PDUs associated with the first segment at the time the first status report is sent (i.e., when the first status report is transmitted). The first status report may be configured such that it does not include information indicating the amount of data associated with at least one set of PDUs associated with a second segment. For example, the discard timer value for the second segment may not have reached (and / or exceeded) a timer threshold.

[0065] The method may include subsequent method steps (e.g., after the transmission of the first status report) wherein a second status report is transmitted if the drop timer value associated with the second segment does not exceed (e.g., is less than or equal to) a timer threshold. The second status report may include information indicating the amount of data in at least one set of PDUs associated with each segment in the first and second segments at the time of the second status report (i.e., when the second status report is transmitted). For example, when the second report is transmitted, the drop timer values ​​for each segment in the first and second segments may have reached (and / or exceeded) a timer threshold. Even if the first segment is reported in the first report, one or more packets may still remain (i.e., not delivered to the network). In this case, any remaining packets from the first segment can be conveniently reported in the second status report (i.e., along with packets from the second segment), thereby providing the network with a more complete picture of packets associated with the LCG that have not yet been transmitted from the user equipment.

[0066] The timer threshold can be set by the network (e.g., a base station). Timing information (e.g., discard timer values) for the first and / or second segments can be determined (e.g., generated) by the discard timer. For example, each segment can be configured with a corresponding (e.g., individual) discard timer. When data from a corresponding set of PDUs is received by a user equipment (e.g., and / or assigned to a segment) (e.g., associated with the relevant segment), a discard timer can be initiated (e.g., for each corresponding segment).

[0067] The method may include generating individual status reports for at least one segment or individual segments of a first segment and a second segment before transmitting a status report. Optionally, the method may include merging (e.g., combining and / or concatenating) the individual status reports (i.e., the first segment and the second segment) to form a single status report (e.g., a combined status report) for transmission to a base station (e.g., a status report as defined by the methods of the first and second embodiments of this disclosure).

[0068] The first segment can be associated with a first PDU set. The second segment can be associated with a second PDU set that has timing information different from that of the first PDU set.

[0069] If the amount of data in the first segment and the second segment (e.g., the total amount of data) is below a predetermined data threshold (e.g., less than or equal to), the method steps for transmitting a status report can be stopped (e.g., blocked or prevented from initiating). The data threshold can be determined based on the amount of data indicated by a previously transmitted status report. For example, the threshold can be set to a value equal to the amount of data previously transmitted.

[0070] The status report may include information indicating the total amount of data associated with the first segment and the second segment.

[0071] The method may include transmitting a status report if the user equipment does not receive a scheduling authorization from the base station within a predetermined time period. For example, after sending a status report (e.g., a previous status report), the user equipment may not receive a scheduling authorization from the base station within the predetermined time period. In this case, the transmission of the status report may be triggered (e.g., as defined according to the first and second embodiments).

[0072] Optionally, status reports can be transmitted even if the amount of data is below a data threshold.

[0073] The method may include determining the first segment and the second segment respectively based on timing information of at least one set of PDUs associated with each segment in the first segment and the second segment.

[0074] The method may include grouping two or more PDU sets with matching timing information into a single segment.

[0075] The method may include comparing timing information of at least one PDU set with a discard timer value of a first segment and a discard timer value of a second segment. Optionally, the method may include associating the at least one PDU set with the first segment if the discard timer value of the first segment matches the timing information of the at least one PDU set. Further optionally, the method may include adding information indicating the amount of data associated with the at least one PDU set to the first segment.

[0076] The method may further include generating a third segment of a logical channel group if the timing information of at least one PDU set does not match the segment timer values ​​of each segment in the first and second segments. Optionally, the method may include another method step of starting a timer for the third segment corresponding to a discard timer value (e.g., of at least one PDU set). Further optionally, the method may include a method step of adding information indicating the amount of data associated with at least one PDU set to the third segment.

[0077] If the timing information (e.g., for at least one set of PDUs) is substantially equal to (e.g., equal to) the discard timer value (i.e., the discard timer value for at least one set of PDUs), then the timing information can be matched with the discard timer value of the corresponding segment.

[0078] Status reports can be configured (e.g., to base stations in the network) to provide an indication that timing information associated with at least one of the first and second segments (e.g., discarding timer values) is critical (e.g., about to expire or be about to end). This "critical" indication can be provided instead of providing the actual timing information associated with the corresponding segment (e.g., discarding timer values), thus reducing transmission overhead within the network.

[0079] The discard timer value of at least one segment in the first segment and the second segment, or all segments, can be included in the status report. Optionally, only the discard timer value of the new segment can be included in the status report.

[0080] The following paragraphs summarize several optional features particularly relevant to the third and fourth embodiments of this disclosure, but these features may also be applied to other embodiments described herein.

[0081] In response to the identification of at least one of a plurality of segments, a status report may be generated and / or transmitted. For example, a status report may be generated and transmitted shortly after (e.g., immediately after) the identification of a plurality of segments (and / or at least one of a plurality of segments). A status report may be transmitted once a predetermined time period has expired, or alternatively immediately after the identification of at least one of a plurality of segments (and / or a plurality of, or each).

[0082] Optionally, in cases where at least one segment is associated with multiple PDU sets, the buffer size value is configured to indicate the amount of data for all (i.e., each) associated PDU sets. In this way, the buffer size value can define the sum of the amounts of data for each PDU set associated with the segment. Advantageously, this means that the base station receives relevant information corresponding to all associated PDU sets (and their respective PDUs) within each segment.

[0083] The method may include transmitting a second status report that does not include timer values. The second status report may be transmitted after the first status report. In embodiments, the second status report may be transmitted after a predetermined time period and / or in response to the determination of at least one of a plurality of segments (e.g., a new segment). Furthermore, the second status report may be transmitted when the UE receives additional data from the application layer of the protocol stack. For example, a new set of PDUs / PDUs (e.g., new PDUs in an existing set of PDUs) may be newly associated with an existing segment (e.g., which contains at least one set of PDUs / PDUs with matching timer values). In this case, the second status report may report a change in the remaining buffer size of the segment. However, the timer state of the new set of PDUs / PDUs matches the timer state of the segment (i.e., which was reported in the first status report). Therefore, timer values ​​can be advantageously omitted from the second report, thus reducing the transmission load on the network.

[0084] Methods for determining multiple segments may include generating a new segment when an existing segment expires (e.g., when the timer value of a previous segment elapses).

[0085] Optionally, if the PDU is the last PDU in the PDU set, and / or if the PDU set is discarded (e.g., discarded by another layer of the protocol stack, such as the MAC layer), the PDU set can be discarded from the segment. According to any of the relevant methods of this disclosure, the discarded segment can be configured (i.e., reallocated) as a new segment. For example, in response to the UE having new data (e.g., PDUs and / or a PDU set) to transmit to the base station, the discarded segment can be configured as a new segment.

[0086] The method may include transmitting a third status report after a first status report, and optionally after a second status report. The third status report may be transmitted at the end of a predetermined time period corresponding to the duration of at least one of a plurality of segments. The third status report may include both a buffer size value and a timer value. For example, the third status report may be transmitted after an existing segment is discarded (e.g., due to timer elapse). The remainder of the LCG may be reassigned to a new segment. In this case, the third status report may include a buffer size value and a timer value corresponding to the new segment. The base station may use the timer value to start a new counter for the associated segment.

[0087] The data used for transmission may include multiple PDUs and / or sets of PDUs (e.g., the transmission may include two or more sets of PDUs, each set of PDUs including at least one or more PDUs). Each set of PDUs may be associated with a discard timer value (e.g., a PDU discard timer value and / or a PDU set discard timer value). The method may include grouping two or more PDUs (or sets of PDUs) with matching timing information into a single segment.

[0088] Optionally, the method may include at least one of the following method steps: comparing the PDU set and / or the PDU's discard timer value (i.e., the PDU / PDU set discard timer value) with the timer value of at least one of a plurality of segments; if the segment timer value matches the discard timer value, associating the PDU / PDU set with the at least one segment; and adding a magnitude value indicating the amount of data associated with the PDU / PDU set to the buffer size value of the at least one segment.

[0089] Optionally, the method may include at least one of the following method steps: comparing a PDU / PDU set discard timer value with a timer value of at least one of a plurality of segments; if the discard timer value does not match the segment timer value, generating a new segment of the logical channel group; starting a timer for the new segment corresponding to the discard timer value; and adding a magnitude value indicating the amount of data associated with the PDU / PDU set to a buffer size value of the new segment.

[0090] In an embodiment, if the discard timer value is substantially equal to the segment timer value, then the segment timer value can be considered to match the discard timer value.

[0091] Optionally, the method includes the following steps: comparing a PDU / PDU set discard timer value with a timer value of at least one of a plurality of segments; if the discard timer value does not match the segment timer value, generating a new segment of the logical channel group; starting a timer for the new segment corresponding to the discard timer value; and configuring the buffer size value of the new segment to match the size value of the PDU / PDU set.

[0092] In an embodiment, if a new segment cannot be generated, the PDU and / or PDU set can be assigned to an existing segment with a buffer size value that is closest to the size value of the PDU and / or PDU set.

[0093] Optionally, before comparing the discard timer value with the segment timer value, the method may include determining the configuration of PDUs within the PDU set. The method can then proceed by determining the discard timer if the PDU is the first PDU in the PDU set.

[0094] The method may include transmitting a status report based on an indication that the decoder of the received network is unable to decode data that was not received within a predetermined time period.

[0095] A transmission status report can be initiated based on one or more of the following delayed status report triggering conditions: data becomes available for another layer of the protocol stack for at least one logical channel in a logical channel group; resources for transmitting a PDU / PDU set are currently allocated in another layer of the protocol stack, and the buffer size of the current status report is at least the size of the previous status report (i.e., a status report that has been previously transmitted); a retry timer expires, where the retry timer defines a period after which a status report transmission is attempted if the previous transmission failed; and a periodic timer expires, where the periodic timer defines a predetermined period after which the user equipment is configured to transmit a status report.

[0096] In embodiments, the status reporting method described above can be configured to indicate the delay status of buffered data. Therefore, the status reporting method described above (e.g., the buffer reporting method of the first embodiment) can be referred to as a delay reporting method. Similarly, a status report can be configured to indicate the delay status of buffered data waiting to be transmitted across the network. In this way, the status report can be referred to as a Delay Status Report (DSR).

[0097] In embodiments (e.g., those relating to the first and second embodiments of this disclosure), at least one trigger condition may be applied as a supplementary requirement for determining whether to transmit a status report. For example, the decision to transmit a status report may be made based on a discard timer value associated with at least one of the first and second segments, and also based on whether at least one of the trigger conditions is met.

[0098] In one embodiment, a status report can be triggered by continuously comparing the remaining time associated with at least one or each of a plurality of segments with a remaining time threshold configured by the gNB. In this way, a status report can only be sent when at least some data has reached a critical level of remaining time.

[0099] The method may include the following steps: determining whether one or more new segments have been generated since the last state report trigger condition was identified; and generating at least one new segment if data corresponding to different timer values ​​becomes available in the logical channels of the logical channel group.

[0100] Optionally, the method may include the following steps: receiving information indicating a buffer size value and / or timer value for a previously generated segment; and updating the buffer size value and / or timer value for a new status report based on the received information.

[0101] Optionally, the method may include the following steps: generating individual segment status reports for two or more segments out of a plurality of segments; analyzing available radio resources for status report transmission; and determining, based on the available radio resources, the number of segment status reports to be merged into a combined (e.g., a single) status report.

[0102] The status of an unselected segment from a previous status report can be characterized as a skipped segment.

[0103] Optionally, the method may include determining at least one of the status reports of segments that cannot be transmitted based on available radio resources. The method may include selecting two or more segments based on at least one of the following criteria: the remaining time of each segment (i.e., before a timer value expires); the novelty status of each segment (e.g., how new the segment was when it was created); the PDU set importance (PSI) value associated with the data of each segment; and the PDU set importance information (PSIHI) quality of service parameter associated with the data of each segment.

[0104] In an embodiment, the method may include selecting two or more segments according to the following method steps: first, selecting at least one skipped segment; second, selecting at least one new segment; third, selecting at least one segment with new data; and fourth, selecting at least one of the remaining segments. By implementing this method, the user equipment ensures that the base station always receives segment delay information as early as possible. Therefore, the base station can monitor the state of the logical channel group itself and determine the remaining time for each segment. Thus, the base station can take the anticipated action so that delay information is never late.

[0105] Alternatively, the method may include selecting two or more segments according to the following method steps: first, determining at least one segment with new data, and selecting from these segments at least one segment with a critical remaining timer value (e.g., a timer value that will expire before and / or within a portion of other timer values ​​and / or within a predefined (e.g., minimum) time period); second, selecting at least one skipped segment; third, selecting at least one new segment; fourth, selecting at least one segment with new data; and fifth, selecting at least one of the remaining segments. By implementing this method, the user equipment can ensure that the base station receives updates to the buffer size and delay timer of the most critical segment as early as possible. This is particularly advantageous in cases of delayed arrival of large bursts on critical channels.

[0106] Alternatively, the method may include selecting two or more segments according to the following steps: first, identifying one or more segments with new data, and then selecting at least one segment from one or more identified segments that has the highest ratio of critical remaining time to buffer size; second, selecting at least one skipped segment; third, selecting at least one new segment; fourth, selecting at least one segment with new data; and fifth, selecting at least one of the remaining segments. By implementing this method, the user equipment ensures that segments with a known buffer size are prioritized for transmission in less time (e.g., minimum latency budget).

[0107] This method can continue with subsequent selections only if there are sufficient radio resources available to accommodate additional selection status reports (i.e., as defined in the previous related paragraphs).

[0108] For at least one of the above selection method steps, the user equipment may arbitrate between two or more pre-selected segments based on at least one of the following selection criteria: logical channel priority, which may (e.g., based on the QoS protocol of the control layer of the protocol stack, such as application level) select segments belonging to a logical channel group that includes the logical channel with the highest priority; remaining time, which may select segments with the most critical remaining time (this allows the base station to obtain delay information on time); the ratio of remaining time to buffer size (this prefers to send segments with known buffer sizes in less time); PDU set importance information (PSI) associated with the PDU sets of each segment (this prefers the most important PDU sets); and PDU set unity importance information (PSIHI) QoS parameters associated with the PDU sets of each segment (e.g., segments containing PDU sets with PSIHI set to false may be skipped, because when PSIHI is set to false, it means that the application decoder can handle (e.g., manage or process) the reception of a portion of the PDU set).

[0109] User equipment can receive dedicated signaling from the base station to configure status report transmission.

[0110] Alternatively or additionally, signaling from the base station may include information about at least one of the following: the configuration of the previous logical channel group; the configuration of the time-sensitive logical channel group; and the maximum number of segments.

[0111] Timer values ​​for all available segments can be included in the status report. Alternatively, timer values ​​for only new segments can be included in the status report (e.g., only in the first status report generated after creating a new segment). Timer values ​​for a specific segment (e.g., a new segment) can be included in the first status report after that segment is generated, as well as in N subsequent status reports, where N is an integer configured by the base station. The base station configures the user equipment for each logical channel group using one of the three modes described above. Therefore, each logical channel group can be managed according to one of the three modes, and thus the status report messages for each logical channel group can exist in several formats.

[0112] Optionally, the method includes (e.g., at the user equipment and / or from the base station) receiving configurations of multiple logical channels grouped into a logical channel group. The configurations of at least one or more channels may be determined by the base station (e.g., before being transmitted to the user equipment).

[0113] According to a fourth embodiment, the method at a base station includes steps for configuring at least one timer associated with at least one segment based on a timer value. The method steps may include starting at least one timer (or counter) associated with at least one segment based on a received status report. The length (or duration) of the timer may be determined based on the timer value. The base station may start different timers for each segment as determined by the status report. Once the timer value has elapsed, the base station may discard the timer. The base station will not expect to receive data corresponding to at least one segment after at least one timer has elapsed, thereby enabling the base station to allocate network resources more efficiently.

[0114] The following paragraphs summarize several optional features particularly relevant to the fifth through eighth embodiments of this disclosure, but these features may also be applied to other embodiments described herein.

[0115] According to some embodiments, the transmission of status reports is based on trigger thresholds and / or reporting thresholds. However, it should be understood that these thresholds can be simply defined as a first threshold and a second threshold, respectively.

[0116] Optionally, at least one segment or all segments of a plurality of segments may be associated with a reporting threshold, wherein once the corresponding reporting threshold is reached (e.g., satisfied), the amount of data associated with at least one segment of the plurality of segments becomes reportable.

[0117] The following paragraphs define the possible means of configuring thresholds (e.g., statically or dynamically in response to changes in operating conditions):

[0118] Trigger thresholds and / or reporting thresholds can be configured by the communication network (e.g., a base station). For example, a user equipment (UE) can receive input from the network (e.g., prior to transmitting a status report) instructing the UE to configure at least one or more thresholds. In this way, thresholds can be configured individually (e.g., independently) or collectively in response to changing operating conditions.

[0119] This method may include a user equipment receiving multiple profiles for configuring trigger thresholds and reporting thresholds. Each of the multiple profiles may define the relationship between the trigger thresholds and the reporting thresholds. A communication network may be configured to control the user equipment to switch between profiles (e.g., to configure both thresholds together). Alternatively, the user equipment may be configured to switch between multiple profiles (e.g., autonomously or independently of network control).

[0120] Multiple profiles can be configured by the communication network, at least one of which can be set as the default profile. Therefore, when multiple profiles are received, the user equipment can assign one of them as the default profile. Later, the user equipment (or the network) can switch to an alternative profile in response to changes in operating conditions.

[0121] The following paragraphs define optional features about how thresholds can be correlated with each other:

[0122] The trigger threshold can be less than or equal to the reporting threshold (e.g., based on at least one of a plurality of profiles received by the user equipment). In embodiments, the transmission of status reports can be based on a plurality of reporting thresholds. Therefore, the trigger threshold can be configured to be less than or equal to at least one or all of the reporting thresholds. Alternatively, at least one or all of the reporting thresholds can be less than or equal to the trigger threshold. In embodiments, the trigger threshold can be configured between two of the plurality of reporting thresholds. For example, the trigger threshold can be the average of two reporting thresholds (e.g., the mean).

[0123] The following paragraphs define optional features that can be used to define trigger thresholds. For example, trigger thresholds may include:

[0124] Data threshold, which indicates that during uplink to a user equipment, for at least one logical channel in a logical channel group, data becomes available to a layer of the protocol stack of the communication network (e.g., the MAC layer).

[0125] Resource threshold, which indicates that during uplink for user equipment, resources for transmitting data are allocated to at least one logical channel in the logical channel group, and the number of padding bits is equal to or greater than the status report.

[0126] Retry timer threshold, which is used to start a retry timer after a failed attempt to transmit a previous status report;

[0127] A periodic timer threshold, which is used for a periodic timer configured to trigger periodic transmissions of status reports;

[0128] A discard timer threshold, used for discard timers associated with at least one of the first and second segments; and

[0129] A scheduling authorization timer threshold, which is configured to measure the time between sending a previous status report and receiving a scheduling authorization from the base station.

[0130] The following paragraphs summarize several optional features particularly relevant to the ninth through thirteenth embodiments of this disclosure, but these features may also be applied to other embodiments described herein.

[0131] Previously reported data can be characterized by discard timer values ​​that indicate the data is critical to latency. For example, when transmitting a status report, the discard timer value associated with previously reported data may be approaching (or may have already exceeded) a discard timer threshold.

[0132] If non-delay-critical data is placed in the transmission buffer before previously reported delay-critical data, the triggering condition can be met (e.g., satisfied). In this way, the user equipment can determine that the previously reported (delay-critical) data has been downgraded (e.g., by placing non-delay-critical data in the transmission buffer after it). Note that the previously reported data (i.e., delay-critical data) may already be non-delay-critical data when the previous status report is transmitted. Therefore, the transmission of the status report can provide the network with the following indications: a) the previously reported data is ready to be transmitted and / or b) the non-delay-critical data is placed before the previously reported data.

[0133] If previously reported data has not been transmitted after a predetermined time period, a trigger condition may be met (e.g., satisfied). For example, the trigger condition may be associated with a timer threshold indicating that a predetermined time period has elapsed since the data was previously reported to the network. The predetermined time period can be configured (e.g., set) to expire before a discard timer associated with non-delay-critical data. In this way, the user equipment can determine that a status report needs to be transmitted before non-delay-critical data becomes delay-critical (e.g., in cases where there is insufficient time to transmit previously reported data before the discard timer for non-delay-critical data expires).

[0134] In this embodiment, the triggering condition is met if non-delay-critical data is placed in the transmission buffer before previously reported delay-critical data, and if the previously reported data has not been sent after a predetermined time period. Advantageously, this combination of threshold requirements reduces the number of unnecessary status reports while ensuring that the availability of previously reported delay-critical data is accurately reported to the network.

[0135] Status reports can be configured to indicate data that has already been reported and is still awaiting transmission. Status reports can also be configured to indicate newly reported data (e.g., non-delay-critical data). In this way, status reports can be configured to distinguish between previously reported data and new data (i.e., between data ready to be transmitted). For example, status reports can be configured such that at least one or more of the first and second segments include means of distinguishing between previously reported data and newly reported data.

[0136] According to the fourteenth embodiment of this disclosure, a communication network is provided, the communication network including network elements (e.g., base stations or UEs) configured to perform any of the preceding paragraphs (e.g., as defined in the relevant sections of the first to thirteenth embodiments of this disclosure, as described herein).

[0137] According to the fifteenth embodiment of this disclosure, a user equipment (e.g., embodied in a transceiver of a communication network) is provided, which is configured to perform any of the preceding paragraphs (e.g., the methods defined in the relevant sections of the first to thirteenth embodiments of this disclosure, as described herein).

[0138] A transceiver can be configured for use in a communication network (e.g., a wireless telecommunications network) that includes a transmitting component (e.g., a first transceiver). A transceiver (e.g., a second transceiver that may define the communication network) can be configured to receive a set of PDUs from the transmitting component. The transceiver may include a receiving component (e.g., a receiver) for receiving status reports and / or a transmitting component (e.g., a transmitter) for transmitting status reports.

[0139] Features of any aspect of the first to thirteenth embodiments can be embodied in any suitable component of the communication network (e.g., a transmitter and / or receiver). For example, transmitting and receiving components can be arranged at different locations within the communication network (e.g., to define respective transmission network nodes and receiving network nodes), or they can be arranged in a single element of the network (e.g., to define a single component of the network, such as a transceiver for a user equipment or base station).

[0140] According to a sixteenth embodiment of the present disclosure, a computer program is provided that includes instructions, when executed by a user equipment, to cause the user equipment to perform a method according to any of the relevant foregoing paragraphs (e.g., as defined with respect to the first and / or third embodiments of the present disclosure); or the computer program includes instructions, when executed by a base station, to cause the base station to perform a method according to any of the relevant foregoing paragraphs (e.g., as defined with respect to the second embodiment of the present disclosure).

[0141] According to the seventeenth embodiment of the present disclosure, a computer-readable medium carrying a computer program according to the sixteenth embodiment of the present disclosure is provided.

[0142] According to any of the above embodiments, various "conditions" and / or "thresholds" (e.g., trigger thresholds) may include thresholds that indicate that a threshold is met if it is reached and / or exceeded. For example, if a threshold is associated with a timer, the threshold may be met when the timer reaches the threshold. Alternatively, if a threshold corresponds to a quantity of data (e.g., data volume), the threshold may be met when the quantity of data becomes available (or reportable) to the user equipment.

[0143] Furthermore, it should be understood that a PDU set may include one or more PDUs. At least one PDU or individual PDUs may be configured to carry a payload (e.g., a frame or video strip for XRM service, as used in TR 26.926) of an information unit generated at the application level. Individual PDU sets may be characterized by identification information (e.g., parameters that define the PDU set). For example, the identification information may define the start, stop, and / or length (e.g., the number of PDUs) of the PDU set. However, at various points in the data transmission process, the receiving entity is unaware of the identification information of the PDU set. In embodiments, the PDU identification information is unknown at all protocol layers (e.g., including the layer).

[0144] This disclosure relates to communication networks for applications related to extended reality (XR). Such communication networks may include third-generation partnership agreements (3GPP) and fifth-generation (5G) new radio (NR).

[0145] XR applications can (e.g., in 3GPP document RP-2200285) be defined as one or more types of enhanced, virtual, and hybrid environments in which human-to-machine and human-to-human communication is performed with the assistance of handheld and wearable end-user devices. Several use cases are defined in 3GPP document TR-26.928.

[0146] The information exchanged between the UE (e.g., a wearable device) and the server can be referred to as application data. For example, application data may include one or more images, video data, audio data, location information, and various other information.

[0147] Application data (e.g., video, audio, or location information / data) can be transmitted between a UE (e.g., a wearable device) and a server using media transport protocols including RTP (Real-Time Protocol, RFC 3550), SRTP (Secure RTP, RFC 3711), HTTP (Hypertext Transfer Protocol, RFC 2616-7540), or QUIC (RFC 8999, 9000, 9001, and 9002). Video encoding and decoding can be performed according to various formats including MPEG2, H.264, H.265, HEVC, etc.

[0148] Any feature in one embodiment of this disclosure may be applied in any suitable combination to other embodiments of this disclosure. In particular, method embodiments may be applied to device / apparatus / unit embodiments, and vice versa.

[0149] Furthermore, features implemented in hardware can be implemented in software, and vice versa. Any references to software features and hardware features herein should be interpreted accordingly. For example, according to other embodiments of this disclosure, a computer program including instructions is provided that, when executed by one or more processing units, cause one or more processing units to perform the methods of any of the embodiments or examples described above, and a computer-readable storage medium carrying the computer program is provided. Attached Figure Description

[0150] Different embodiments of this disclosure will now be described by way of example only and with reference to the following figures, in which:

[0151] Figure 1 is a schematic diagram illustrating a first example wireless communication system that can implement the present disclosure according to one or more embodiments of the present disclosure;

[0152] Figure 2 illustrates a schematic diagram of an example configuration of a UE that can implement the present disclosure according to one or more embodiments;

[0153] Figure 3 illustrates a schematic diagram of an example configuration of a base station that can implement the present disclosure according to one or more embodiments;

[0154] Figure 4 is a schematic diagram illustrating the data plane protocol stack of the 5G NR system shown in Figure 1;

[0155] Figure 5 is a flowchart illustrating the method performed at the UE PDCP layer of the wireless communication system of Figure 1;

[0156] Figure 6 is a flowchart illustrating the method performed at the UE MAC layer of the wireless communication system of Figure 1;

[0157] Figure 7 is a flowchart illustrating the method performed at the UE MAC layer of the wireless communication system of Figure 1 when a status report (e.g., Delayed Status Report (DSR)) is triggered;

[0158] Figure 8 is a flowchart illustrating the method performed at the gNB of the wireless communication system in Figure 1 when a status report is received;

[0159] Figure 9a is a schematic diagram illustrating the short status report format and the short truncated status report format;

[0160] Figure 9b is a schematic diagram illustrating the extended short status report and extended short truncated status report formats;

[0161] Figure 10 is a schematic diagram illustrating example message formats including long status report format, long truncated status report format and preemptive status report format;

[0162] Figure 11 is a schematic diagram illustrating example message formats including the extended long status report format, the extended long truncated status report format, and the extended preemptive status report format;

[0163] Figure 12 is a flowchart illustrating an alternative method performed at the UE MAC layer of the wireless communication system in Figure 1 when a status report is triggered;

[0164] Figure 13a is a schematic diagram illustrating another example of the short status report format and the short truncated status report format;

[0165] Figure 13b is a schematic diagram illustrating another example of the extended short status report format and the extended short truncated status report format;

[0166] Figure 14 is a schematic diagram illustrating yet another exemplary message format, including long status report format, long truncated status report format and preemptive status report format;

[0167] Figure 15 is a schematic diagram illustrating yet another exemplary message format, including the extended long status report format, the extended long truncated status report format, and the extended preemptive status report format.

[0168] Figures 16 to 20 are schematic diagrams illustrating the triggering of a status report according to an example of the method shown in Figure 12; and

[0169] Figures 21 and 22 are schematic diagrams illustrating exemplary message formats according to one or more embodiments of the present disclosure. Detailed Implementation

[0170] Figure 1 illustrates an example wireless communication system 100, particularly a mobile radio communication system such as a fifth-generation (5G) New Radio (NR) system supporting Extended Reality (XR) services. Although embodiments and examples of embodiments of this disclosure will be described with reference to 5G NR systems in the following description, it will be understood that this disclosure is not intended to be limited to 5G NR systems and can be used in any wireless communication system supporting XR or similar services.

[0171] System 100 includes user equipment (UEs) 101 and 151 served by base station 110 to communicate with a core network such as 5G core network 102. The UEs can be, for example, virtual reality headsets or extended reality wearables (such as glasses). The UEs can be any wireless device capable of wirelessly communicating with one or more core networks via one or more radio access networks, such as wireless communication devices or terminals, IoT devices, machine-type communication (MTC) devices, device-to-device (D2D) terminals, and user equipment (e.g., smartphones, laptops, mobile phones, tablets, cameras, game consoles, wearable devices). Base station 110 is a network node providing access to the core network for the UEs and is part of the radio access network (RAN) comprised of base stations 110 and 111. In NR, the base station is referred to as a next-generation node B (gNB), the RAN is a next-generation (NG) RAN, and the core network is referred to as 5GC. In the following text, the terms RAN node, base station, and gNB will be used interchangeably. Base stations 110 and 111 are interconnected via an Xn interface implemented on wired or wireless link 130 (e.g., as specified in 3GPP document TS 38.423). Each base station is connected to core network 102 via an NG interface implemented on wired or wireless links 140 and 141 (e.g., as specified in 3GPP document TS 38.413).

[0172] These base stations each control one or more cells. For example, base station 110 controls cell 120, and base station 111 controls cell 121. A cell is a geographical area of ​​a radio network defined by the frequencies used for data transmission within the cell. A UE can uniquely identify a cell based on an identifier broadcast in the geographical area. Each base station 110, 111 can serve several UEs 101, 151. Once a UE has established an RRC connection with a base station, the base station to which the UE is connected is called the UE's serving base station (or source base station), and the cell controlled by the serving base station and where the UE camps is called the serving cell. The interface between the gNB and the UE is the Uu interface using the protocol sublayers Serving Data Adaptation Protocol (SDAP), Packet Data Convergence Protocol (PDCP), Radio Link Control (RLC), Medium Access Control (MAC), and Physical (PHY) in the user plane, and the protocol sublayers Radio Resource Control (RRC), PDCP, RLC, MAC, and PHY in the control plane.

[0173] Assume UE 101 is receiving and / or transmitting XR data for one or more multicast XR sessions generated for and / or destined for XR application server 103. The XR data is provided to base station 111 (which controls cell 121 to which UE 101 is attached) via core network 102 (e.g., via data network 160 and user plane function 161) and a pass bearer (also known as a GTP-U tunnel) 106 on link 141. Base station 111 then transmits the XR data to UE 101 via data radio bearer (DRB) 154. Figure 1 also shows UE 151 receiving data via DRB 153. A radio bearer is a set of PHY (Layer 1) and MAC (Layer 2) parameters that allow higher-layer data connections between the UE and gNB. Several types of radio bearers are defined in 5G NR: signaling radio bearers (SRB) for the control plane, data radio bearers (DRB) that allow point-to-point communication (e.g., unicast) with a UE in the user plane, and multicast radio bearers (MRB) that allow point-to-point and point-to-multipoint communication (e.g., multicast / broadcast) with multiple UEs in the user plane.

[0174] Figure 2 is a block diagram of a UE device 205 (such as UE 101 or UE 151 in Figure 1) that can implement the present disclosure according to one or more embodiments. The UE includes components for transmitting and receiving communications, such as at least one of a UE communication manager 220, an I / O controller 255, a transceiver 235, an antenna assembly 245, a storage device (e.g., a memory) 225, and a processor (CPU: Central Processing Unit) 215. All these components can communicate with each other.

[0175] Memory 225 includes random access memory (RAM), read-only memory (ROM), or a combination of both. Alternatively or additionally, memory 225 may include a mass storage device, such as a disk or solid-state drive (SSD). Basic Input / Output System (BIOS) instructions may be stored in memory 225.

[0176] Processor 215 is configured to execute machine-readable instructions. Execution of these machine-readable instructions enables the UE to perform various functions. These functions may involve transmission and / or interaction with peripheral devices (e.g., keyboard, screen, mouse, etc.) (not shown in Figure 2). The processor may run an operating system such as iOS, Windows, Android, etc. Processor 215 may be a single processor, or it may include two or more processors that may include the processing required to perform the operations of UE 205.

[0177] The I / O controller 255 enables these interactions with external peripheral devices by providing the necessary hardware and managing input and output signals.

[0178] The I / O controller 255 can interact, for example, with all or part of an image capturing device, image rendering device, audio capturing device, audio rendering device, or sensor device capable of determining the location of use.

[0179] Transceiver 235 is configured to provide bidirectional wireless communication with other wireless devices. For example, transceiver 235 provides the necessary modem (e.g., a router) and frequency shifter required to connect to one or more wireless networks (such as Wi-Fi, Bluetooth, LTE, 5G NR, etc.). Transceiver 235 may include a PDCP transmitter and a PDCP receiver. The PDCP transmitter and PDCP receiver may be implemented by processor 215. The PDCP transmitter and PDCP receiver may be software-only functions implemented by processor 215.

[0180] Radio communication uses an antenna set 245 adapted to the spectrum of frequency-transposed signals emitted from a baseband modem. The antenna set 245 may be limited to a single antenna, but preferably it comprises several antennas to provide beamforming capability.

[0181] The UE communication manager 220 controls the establishment of communication between the UE and the radio access network (RAN). The UE communication manager 220 can also be configured to control the UE's control and release relative to the RAN. The UE periodically receives indications from a base station (e.g., a gNB) of time slots available for communication between the UE and the base station. Therefore, the UE can determine when and at what frequency (e.g., from the gNB) it should expect to receive incoming data. Furthermore, the UE can identify when and at what frequency it should transmit outgoing data. The UE can determine data transmission / reception regardless of whether the data belongs to the control plane or the data plane. In one example implementation, the UE communication manager 220 implements a Uu interface.

[0182] Figure 3 illustrates a block diagram of a base station apparatus 305, such as gNBs 110 and 111 in Figure 1, which can implement embodiments of the present disclosure. The base station apparatus 305 includes components for transmitting and receiving communications (e.g., relative to a UE). For example, the base station includes at least one of a base station communication manager 320, a core network communication manager 355, a transceiver 335, an antenna assembly 345, a memory 325, a processor (e.g., a CPU) 315, and an inter-site communication manager 365. All these components can communicate with each other.

[0183] The base station communication manager 320 is configured to control communication with multiple UEs. The base station communication manager 320 is responsible for establishing, controlling, and releasing these communications. In the example implementation, the base station communication manager 320 implements the Uu interface. The base station communication manager 320 includes a scheduler that allocates time slots to different UE communications. Information regarding the scheduling of these time slots is periodically sent to the involved UEs.

[0184] The Core Network Communication Manager 355 manages communication between the base station and the core network. The Core Network Communication Manager 355 can provide standardized NG interfaces, such as those defined by 3GPP standards, to support these communications.

[0185] Transceiver 335 is configured to provide bidirectional wireless communication with other wireless devices, such as UEs or even other base stations. Transceiver 335 provides the necessary modem and frequency shifter to simultaneously connect to a large number of UEs using different frequency carriers in Time Division Duplex (TDD) or Frequency Division Duplex (FDD). Transceiver 335 may include a PDCP transmitter and a PDCP receiver. The PDCP transmitter and receiver may be implemented by processor 315. The PDCP transmitter and receiver may be software-only functions implemented by processor 315. Transceiver 335 is connected to antenna assembly 345, which may be limited to a single antenna, but preferably includes several antennas to provide beamforming capabilities.

[0186] Memory 325 includes RAM, ROM, or a combination of both. Alternatively or additionally, memory 225 may include a mass storage device, such as a disk or SSD. BIOS instructions may be stored within memory 325 to support the operating system.

[0187] Inter-site Communication Manager 365 manages communication with other base stations. Inter-site Communication Manager 365 can provide standardized Xn interfaces (e.g., as defined by 3GPP standards) to support these communications.

[0188] Figure 4 is a block diagram illustrating the data plane protocol stack of the 5G NR system shown in Figure 1. The data plane protocol stack is described in detail in 3GPP document TS23.501. In the downlink direction, application server 103 connects to user plane function (UPF) 161 via data network 160 at PDU layer 402. The PDU layer corresponds to the PDU carried between the UE and data network (DN) on the PDU session. When the PDU session type is IPv4, IPv6, or IPv4v6, the PDU corresponds to an IPv4 packet, an IPv6 packet, or both. When the PDU session type is Ethernet, the PDU corresponds to an Ethernet frame; and so on. At the start of the PDU session (i.e., at PDU establishment time), the core network provides session QoS parameters to the UPF, gNB, and UE. The PDU session QoS parameters include XRPDU set QoS parameters (S2-2302696):

[0189] A. PDU Set Delay Budget (PDSB);

[0190] B. PDU set error rate (PSER); and

[0191] C. PDU Integrated Processing Instruction (PSIHI), formerly known as PDU Integrated Instruction.

[0192] In the description of Figure 4, unless otherwise stated, a PDU refers to a packet disposed of (e.g., managed or processed) by PDU layer 402. Other types of PDUs are disposed of by other layers. Therefore, PDUs belonging to one of the other layers (i.e., other than PDU layer 402) are referred to herein by a prefix corresponding to the corresponding layer name (e.g., PDCP PDU or MAC PDU).

[0193] When a PDU arrives at UPF PDU layer 402, the UPF performs an application packet inspection to determine the boundaries of the PDU set. 3GPP document S2-2302696 provides examples of how to identify PDU sets when inspecting RTP / SRTP headers, RTP header extensions, H.264 RTP payloads, H.265 RTP payloads, and H.266 RTP payloads.

[0194] As described in 3GPP document S2-2303842, the PDU set identification information is determined by the UPF and sent to the NG RAN in the GTP-U header. The PDU set identification information includes:

[0195] A. PDU set sequence number;

[0196] B. Indicator of the end PDU of the PDU set;

[0197] C. The PDU serial number within the PDU set;

[0198] D. Size of the PDU set; and

[0199] E. PDU set importance, which identifies the relative importance of a PDU set compared to other PDU sets within a QoS flow.

[0200] During the uplink, the application resides on the UE. As previously described, the UE obtains PDU session QoS parameters from the core network when establishing a PDU session (e.g., the PDU session establishment procedure is defined in TS23.502, Clause 4.3.2). When one or more PDUs generated by application 403 arrive at the UE PDU layer 402, the UE performs an application packet check to determine the PDU set boundaries (similar to the procedure described above regarding UPF).

[0201] During both the downlink and uplink, application 103 sends data to / receives data from the NG RAN via a GPR tunnel (e.g., GTP-U layer 404 as defined in TS 29.281).

[0202] During downlink, the UPF detects PDU set identification information and obtains a set of mapping rules (e.g., filtering rules) from the core network. The filtering rules define how to map individual PDU sets to QoS flows. The QoS flow, or individual QoS flows, is identified by an identifier, and the GTP-U PDU is labeled according to the determined QoS flow identifier. At the gNB, the relay layer 406 extracts the PDU set identification information and QoS flow identifier from the GTP-UPDU and maps them to (one or more) SDAP QoS flows. During an XR session (e.g., a single XR session), multiple PDU sets can be mapped to the same QoS flow. Alternatively (or additionally), one or more PDU sets can be mapped to different QoS flows. Then, according to 3GPP document TR-38.835, in a first alternative arrangement, individual SDAP QoS flows can be mapped to different PDCP data radio bearers (DRBs). According to a second alternative arrangement, all SDAP QoS flows from the same XR session can be mapped to a PDCP DRB (e.g., a single PDCP DRB).

[0203] During uplink, the UE detects PDU set identification information at PDU layer 402 and obtains a set of mapping rules (e.g., filtering rules) from the core network. The filtering rules define how to map individual PDU sets to (one or more) QoS flows. The UE maps XR PDUs to associated SDAP QoS flows according to the filtering rules. Similar to downlink, during uplink, multiple PDU sets can be mapped to the same or different (one or more) QoS flows within an XR session (e.g., a single XR session).

[0204] During downlink, application layer 103 generates at least one application flow toward at least one UE (e.g., a single UE), such as one or more video streams and one or more audio streams. Then, at PDU layer 402, the application flows are arranged in PDU sets. The individual application flows are divided into multiple PDU sets of the same or different types. Then, within GTP-U layer 404, the individual PDU set types are mapped to QoS flows, thus allowing multiple application flows to be multiplexed within a QoS flow (e.g., a single QoS flow). Alternatively, the individual application flows can be mapped to different QoS flows. Alternatively, the application flows can also be divided into multiple QoS flows. Then, SDAP layer 407 maps the QoS flows to DRBs, each DRB being handled (e.g., managed or processed) by a dedicated PDCP entity. Like QoS flows, multiple application flows can be multiplexed within a single DRB. Alternatively, the individual application flows can be mapped to different DRBs. Alternatively, the application flows (e.g., a single application flow) can also be divided into multiple DRBs.

[0205] During the uplink, application layer 403 generates at least one application stream toward application server 103, such as one or more video streams, one or more audio streams, or one or more sensing streams. Then, at PDU layer 402, the application streams are arranged in PDU sets. At least one or more application streams are divided into multiple PDU sets of the same or different types, and each PDU set type is mapped to a QoS stream, so multiple application streams can be multiplexed in a single QoS stream, or each application stream can be mapped to a different QoS. Alternatively, the application streams can be divided into multiple QoS streams. Then, SDAP layer 407 maps the QoS streams to DRBs. At least one or more radio bearers are handled (e.g., managed or processed) by a dedicated PDCP entity. For QoS streams, multiple application streams can be multiplexed in a single DRB (e.g., a single DRB), or each application stream can be mapped to a separate DRB. Alternatively, application streams (e.g., a single application stream) can be divided into multiple DRBs.

[0206] Subsequently, at least one or each DRB is mapped to at least one RLC channel, which in turn is mapped to at least one MAC logical channel (LCH).

[0207] Based on the known network configuration, in order to schedule uplink traffic, the gNB MAC layer 410 is configured to allocate radio resources to the UE (e.g., at least one or all UEs) based on at least one of the following mechanisms:

[0208] A. Dynamic request scheduling issued by each UE (i.e., where UEs dynamically issue requests for radio resources);

[0209] B. semi-static scheduling of the gNB (i.e., where the gNB is configured to issue periodic resource allocations to at least one UE); and

[0210] C. At least one UE’s buffer status report (i.e., where the UE generates a status report (BSR) indicating the amount of data available for uplink transmission).

[0211] Compared to other mechanisms (A and B), the BSR mechanism (C) has the potential to reduce network overhead because it reduces the need for periodic transmissions between the gNB and the UE (e.g., as required by mechanism B), and it also reduces the computational load at the UE (e.g., unlike mechanism A).

[0212] The buffer status reporting mechanism operates on a logical channel group (LCG) basis, meaning that the buffer status of a group of logical channels (LCHs) is reported together. An LCG (e.g., a single LCG) can be mapped to multiple MAC logical channels (LCHs), and its BSR triggering conditions and format are defined in 3GPP document TS 38.321. The gNB receives the BSR reports, and using this knowledge, the gNB can perform resource scheduling. For example, the gNB can decide to favor the LCG with the most available data while preventing resource starvation on low-throughput LCGs.

[0213] In some cases, some XR data within an XR dataset may have a PDU set delay budget (PDSB) that cannot be exceeded because the data then becomes obsolete (e.g., useless to the decoder) after the delay period has elapsed. For example, when transmitting a PDU set on a 5G network, some information about the PDU reception status and the elapsed PDSB may be available. The gNB can detect whether a PDU transmission has failed (e.g., regardless of attempts to retransmit and error correction mechanisms). If the decoder can only handle (e.g., manage or process) complete application packets received on time (e.g., if PSIHI is "true"), any remaining PDUs in the PDU set after the delay period has elapsed (i.e., PDUs still waiting to be transmitted) are useless to the decoder.

[0214] However, the BSR mechanism does not provide any indication of the delay period of the PDUs to be transmitted by the UE. Furthermore, the BSR mechanism operates against the LCG, and multiple PDU sets can be multiplexed within a single logical channel (LCH). Therefore, if delay information is included in the BSR report, the reported buffered data will be associated with potentially different delay periods (e.g., because they belong to different PDU sets). Thus, even if delay information is included in the BSR report in some way, it does not improve the gNB's resource allocation.

[0215] According to embodiments of this disclosure, a method for allocating radio resources within a communication network (e.g., a mobile telecommunications network) is envisioned, overcoming the problems inherent in the BSR mechanism. Specifically, radio resource allocation is performed by the MAC layer of the communication network. The method involves a delay state reporting mechanism, wherein at least one UE or individual UEs are configured to indicate (e.g., during uplink to a gNB) the amount of data to be transmitted. The state report is configured (e.g., segmented) into multiple segments, wherein each segment can be configured such that multiple data packets with similar buffer states can be associated with the same segment.

[0216] In at least some embodiments of this disclosure, the delay status reporting mechanism is configured to also indicate the remaining time after which transmission will be performed for at least one of a plurality of segments. This exemplary method is described below with particular reference to Figures 5 through 11.

[0217] Advantageously, the delay status reporting mechanism enables the scheduler to know the remaining time (e.g., remaining PDSB) for XR data when making scheduling decisions, so that the scheduler can identify which sets of PDUs to abandon (e.g., so that they are not transmitted by the UE) to save network resources.

[0218] Note that the buffer status reporting mechanism and the delay status reporting mechanism are not mutually exclusive and can therefore be used in combination. For example, the BSR mechanism can be used for traditional LCGs (e.g., for applications where the decoder can handle application packets that are not received on time), and the delay status reporting mechanism can be used for delay-sensitive LCGs.

[0219] The application and advantages of the delay status reporting mechanism will now be described with reference to Figures 1 and 4. During the downlink, the PDU set identification information calculated by the core network UPF 161 is inserted into the GTP-U header 404 (e.g., the GPRS tunneling protocol (user plane) as described in TS 29.281). GTP-U is a protocol used by the UPF to transmit data from the core network 102 (which includes the UPF, as shown in Figure 1) to gNBs 110 and 111. When a PDU (which is transmitted from the core network via the GTP-U tunnel) arrives at gNBs 110 and 111, the GTP-U header 404 is removed. This means that the PDU set identification information is not transmitted to UEs 101 and 151 via the SDAP layer 407 (e.g., the Service Data Adaptation layer as described in TS 37.324). In this way, the PDU set identification information is not provided "in-band" during the downlink from the gNB to the UE. Therefore, UEs 101 and 151 (i.e., the receiving side during downlink) cannot access the PDU set identification information.

[0220] During uplink, the PDU set identification information (e.g., calculated by UE PDU layer 402) is not inserted into any header, as shown in Figure 4. Therefore, the PDU set identification information is not provided "in-band" during uplink from UEs 101 and 151. Consequently, gNBs 110 and 111 (i.e., the receiving side during uplink) cannot access the PDU set identification information.

[0221] In summary, at all protocol layers (including PDCP layer 401), the receiving entity is unaware of the PDU set identification information during either downlink or uplink. On the transport side, none of the layers below SDAP layer 407 can access the "in-band" PDU set identification information. However, internal mechanisms can be used to associate "out-band" PDU set qualification information with the individual PDUs to be transmitted. An example of such an internal mechanism is using PDU context information to determine the PDU set qualification information.

[0222] According to an exemplary method during downlink, at the gNB (i.e., the transmitter side), the GTP-U receiving entity 404 can associate "out-of-band" PDU set definition information with each PDU and pass the definition information to the PDCP transmission entity 401. The PDU set definition information is thus passed from the gNB to the UE via the PDCP layer 401. Subsequently, during uplink, the (UE's) PDU layer 402 associates the "out-of-band" PDU set definition information with each PDU and passes the information to the UE PDCP transmission entity 401 (e.g., to prepare for transmission to the gNB).

[0223] The details of the delayed status reporting mechanism will now be described with reference to Figures 5, 6, 7, 8, 9a, 9b, 10, and 11.

[0224] The delay status reporting mechanism operates on an LCG, which is subdivided into multiple "segments" that define portions of the LCG. The process of forming segments by the UE MAC layer 410 is described below with reference to Figure 6. An exemplary method for information sharing between the UE PDCP layer 401 and the UE MAC layer 410 is shown in Figure 5. Potential triggering conditions for the delay status reporting mechanism are described with reference to Figure 7. A method for handling the delay status reporting mechanism at the gNB is described with reference to Figure 8. Various delay status reporting formats are described with reference to Figures 9a, 9b, 10, and 11.

[0225] Figure 5 is a flowchart illustrating the steps of a method 500 performed at the UE PDCP layer 401 to send uplink traffic to the MAC layer 410 via the RLC layer 408 (as shown in Figure 4). For each DRB (e.g., data radio bearer) 153, 154, the UE performs at least one instance of a method defined as follows:

[0226] Initial method step 501 involves UE 101, 151 receiving PDCP DRB configuration from gNB 111. The PDCP DRB configuration includes at least one discard timer (e.g., a "PDU set discard timer" value and / or a "PDU discard timer" value).

[0227] At step 502 of the second method, UE 101 and 151 receive the first PDU from the PDU set from the upper layer of the UE's protocol stack (e.g., SDAP layer 407 as shown in FIG4).

[0228] At the third method step 503, UE 101, 151 (i.e., via RLC layer 408 as shown in FIG4) sends PDU and associated PDCP DRB configuration to the MAC logical channel (e.g., “PDU discard timer” value and / or “PDU set discard timer” value).

[0229] The fourth method step 504 includes UE 101 and 151 waiting to receive one or more subsequent PDUs from the same PDU set. Each time a new PDU is received, the UE (i.e., via RLC layer 408) sends the new PDU to the MAC logical channel.

[0230] At method step 505, if at least one of the following criteria is met, UE 101, 151 (i.e., via RLC layer 408) sends a notification to the MAC logical channel:

[0231] A. Receive the last PDU in the PDU; and

[0232] B. The PDU set is discarded (e.g., because the discard timer has expired).

[0233] If every PDU from the PDU set has been received (i.e., PDU set reception is complete), a notification indicates the end of the PDU set. If the discard timer has elapsed, the notification is configured to indicate that the PDU set is to be discarded. In this way, the transmission and content of the notification are configured according to the criteria described above that have been met. Finally, the method continues: UEs 101 and 151 loop back to method step 502 to receive a new PDU set.

[0234] Some PDU collections contain only one PDU; for example, pose information can be carried within a single PDU, making it possible to create a segment. It should be understood that pose information can include position and orientation information associated with an object in 3D. In the context of XR applications, pose information can be used, for example, to allow users to manipulate virtual objects or avoid moving into them based on the perceived position and orientation of the virtual object in the environment.

[0235] Figure 6 is a flowchart illustrating the steps of method 600 performed at UE MAC layer 410. Method 600 controls the reception of data for a single logical channel group (LCG). For each LCG, UE MAC layer 410 performs at least one instance of the following method:

[0236] Initial method step 601 involves the UE receiving configuration from gNB 111. This configuration includes information indicating that logical channels (LCHs) are grouped into logical channel groups (LCGs) for the MAC layer (i.e., LCG (or MAC LCG) configuration).

[0237] The method continues to second method step 602, in which a new PDU is received on an LCH (e.g., one or more LCHs) belonging to the LCG. If the received (new) PDU is the first PDU in the PDU set (e.g., as determined in method step 502 of FIG. 5), the method proceeds to method step 605, in which the UE obtains an associated discard timer value (e.g., as sent during method step 503 of FIG. 5). The UE compares the obtained discard timer value with the remaining timer value of an existing segment. If the obtained discard timer value matches the remaining timer value of one of the existing segments of the LCG, a new PDU set is associated with an existing segment. The amount of data buffered for the PDU set is added to the buffer size of the existing segment.

[0238] According to the embodiment, when the obtained timer value is equal to the remaining timer value, the obtained timer value matches the remaining timer value.

[0239] Alternatively, when the obtained discarded timer value is included within an interval of the remaining timer value, the obtained timer value can be configured to match the remaining timer value. In this way, the interval value can define the absolute difference (e.g., + / -10ms) or relative difference (e.g., + / -10%) between the obtained timer value (i.e., the timer value of the PDU set) and the remaining timer value (i.e., the timer value of the segment). Therefore, according to the method disclosed herein, the timer values ​​do not necessarily need to be equal to each other for matching. In this case (i.e., the obtained timer value is approximately equal to (e.g., slightly greater than or less than) the remaining timer value), the remaining timer value can be configured according to at least one of the following criteria:

[0240] A. The remaining timer remains unchanged;

[0241] B. The remaining timer is set to the average of the obtained timer value and the remaining timer value; and

[0242] C. The remaining timer is set to the minimum or maximum value among the timer values.

[0243] If the obtained discard timer value does not match the remaining timer value of any existing segment, the following method steps are performed at the UE:

[0244] A. Create a new segment of the LCG;

[0245] B. Start the remaining timer for the new segment, and set the new timer to the obtained discard timer value; and

[0246] C. Associate the new PDU with the new segment (e.g., the amount of data buffered for the PDU set will be added to the buffer size of the new segment).

[0247] According to an embodiment, if a new segment cannot be created (e.g., because the UE has run out of segment identifiers), a new set of PDUs is assigned to the segment with the remaining timer value that is closest to the obtained timer value.

[0248] If the received PDU is a subsequent PDU in the PDU set (e.g., as described in method step 504 of FIG5), then at method step 603, the UE adds the PDU size to the buffer size of the corresponding segment.

[0249] If the received PDU is the last PDU in the PDU set, or if the PDU set is discarded by another layer (e.g., as described in method step 505 of FIG. 5), then at method step 604, the UE separates the PDU set from its existing segment. If no other PDU set is associated with the existing segment, then the segment is unallocated (e.g., it remains empty or idle).

[0250] Throughout this disclosure, the term "section" defines a portion or part of an LCG (i.e., a logical channel group). Without departing from the scope of this disclosure, a section may alternatively be referred to as a "bucket," "PDU set," "burst," "chunk," or "part."

[0251] Figure 7 is a flowchart illustrating method 700 performed at UE MAC layer 410 (as shown in Figure 4) when a delay status reporting mechanism (e.g., a mechanism that provides information indicating the delay associated with buffered data) is triggered.

[0252] Initial method step 701 involves the UE initiating a delay status reporting mechanism based on the identification of one or more delay status reporting trigger conditions. The delay status reporting trigger conditions are summarized as follows:

[0253] 1. During the uplink, for at least one LCH of the LCG, data becomes available to the MAC entity;

[0254] 2. During the uplink, resources are allocated for sending MAC PDUs, and the number of padding bits is equal to or greater than the size of the Delay Status Report (DSR);

[0255] 3. The first (retry) timer expires (e.g., retxDSR-Timer), causing the timer to be set again when the delayed status report transmission fails, so that the delayed status report transmission is attempted at different times (as described in step 707 of the method below);

[0256] 4. The second (periodic) timer expires (e.g., periodicDSR-Timer), allowing the gNB to configure the UE to use this timer to send periodic delay status reports; and

[0257] 5. The remaining time value when at least one segment of the LCG has reached at least one threshold.

[0258] Similar triggering conditions can be associated with buffer status reporting mechanisms (e.g., as defined in 3GPP document TS38.321, Clause 5.4.5).

[0259] The second method step 702 involves the UE checking (e.g., identifying) whether one or more new segments of the LCG have been created since the last DSR trigger was identified (e.g., during method step 605 as shown in Figure 6). At least one new segment is created if data corresponding to different delay budgets becomes available in the LCH (e.g., a single LCH) belonging to the LCG. The UE then generates a delay and buffer report, which defines the delay information and buffer size corresponding to the new segment. The delay information and buffer size of the new segment can be characterized by the following segment parameters: segment identifier; buffer size; and delay information value (e.g., remaining time).

[0260] The third method step 703 involves the UE receiving delay information and buffer size for previously created (and skipped) segments. The UE uses the delay information and buffer size to update the corresponding report for existing (e.g., skipped) segments of the LCG.

[0261] In step 704 of the fourth method, the UE analyzes the available radio resources for transmitting Delay Status Reports (DSRs), and then the UE calculates how many segment reports can be cascaded in the available radio resources.

[0262] Typically, a DSR defines a message from the UE to the gNB that outlines the amount of data available for uplink transmission and its associated delay budget. According to an exemplary arrangement, the purpose of the DSR is to assist or guide the gNB in ​​scheduling resource allocation to enable uplink data transmission. DSRs can be configured in various formats, as described now with reference to Figures 9a, 9b, 10, and 11.

[0263] If the available radio resources are greater than or equal to the size of the short DSR format and less than the minimum size of the long DSR format, then only space exists for reporting a segment using the short DSR format. If the available resources are greater than or equal to the minimum size of the long DSR format, then the long DSR format can be used to report at least two segments from the same LCG. The short DSR format is described in more detail below with reference to Figures 9a and 9b, and the long DSR format is described with reference to Figure 10.

[0264] In an embodiment, if available radio resources are greater than or equal to two bytes and less than six bytes, there is only space available for reporting a segment using the short DSR format. If available resources are greater than or equal to six bytes, the long DSR format can be used to report at least two segments from the same LCG. If available radio resources are greater than or equal to seven bytes, the long DSR format can be used to report at least two segments from two different LCGs.

[0265] When the UE has only one segment of an LCG to report, the DSR format is called the short DSR format. If the UE must select one segment from multiple segments (or select one segment from multiple LCGs), the DSR message is called the truncated DSR format (see Figure 9a). Therefore, the short DSR format and the truncated DSR format are functionally the same type of DSR message with different names.

[0266] When available radio resources match all LCGs and the segments available for reporting, the DSR message in Figure 10 is called the long DSR format. If the UE must select one segment from multiple segments (or one segment from multiple LCGs), the DSR message in Figure 10 is called the long truncated DSR format. Therefore, the long DSR format and the long truncated DSR format are functionally the same type of DSR message with different names.

[0267] In the context of Integrated Access and Backhaul (IAB), the DSR mechanism can be used for communication between individual IAB nodes. For example, an IAB mobile terminal (IAB-MT) can provide its parent IAB distributed unit (IAB parent DU) or IAB donor DU (IAB donor DU) with information about the amount of data that can be expected to arrive at the IAB-MT from child nodes and / or UEs (i.e., those connected to the IAB-MT) and its associated delay budget.

[0268] In embodiments, if the maximum number of LCGs is larger, the DSR format is referred to as the extended short DSR format (as shown in Figure 9b). If only one segment is selected from multiple segments (or one segment is selected from multiple LCGs), the DSR message is referred to as the extended short truncated DSR format (see Figure 9b). When available radio resources match all LCGs and the segments they can be used for reporting, the DSR message is referred to as the extended long DSR format (as shown in Figure 11). If one segment is selected from multiple segments (or one segment is selected from multiple LCGs), the DSR message of Figure 11 is referred to as the extended long truncated DSR format.

[0269] Method 700 continues to the fifth method step 705, in which, if all candidate LCGs and segments cannot be adapted to available radio resources, the UE selects an LCG and segment based on multiple criteria. These selection criteria may include:

[0270] A. Remaining time for each segment;

[0271] B. The novelty status of each segment (e.g., new segments versus existing segments);

[0272] C. PDU set importance (PSI) values ​​associated with (one or more) PDU sets for each segment; and

[0273] D. PSIHI QoS parameters associated with (one or more) sets of PDUs in each segment.

[0274] The UE is configured to not select new segments, so that they are characterized as "skipped" segments.

[0275] In a first exemplary method, a "skipped" segment from the LCG is selected (e.g., multiple or all skipped segments from the LCG (optionally from all LCGs)). Then, if any space remains after the first selection, a "new" segment from the LCG is selected (e.g., multiple or all new segments from the LCG (optionally from all LCGs)). If space remains after the second selection, a segment from the LCG with new data is selected (e.g., multiple or all segments from the LCG (optionally from all LCGs) with new data). If space remains after the third selection, the remaining segments from the LCG (i.e., any type of remaining segment) are selected (e.g., multiple or all remaining segments from the LCG (optionally from all LCGs)). By implementing this method, the UE ensures that the gNB always receives segment delay information as early as possible. Therefore, the gNB can monitor the status of the LCG itself and determine the remaining time for each segment. Thus, the gNB can take the expected action so that delay information is never late.

[0276] According to the second exemplary method, the first selection includes identifying one or more segments from the LCG that have new data (e.g., optionally, multiple or all segments from all LCGs that have new data). Then, one or more segments with the most critical remaining time are selected from the segments identified in the first selection. This first selection may (indiscriminately) include any of new segments, skipped segments, and existing segments. Subsequently, if space exists after the first selection, a second selection is performed, which includes the remaining "skipped" segments from the LCG (e.g., multiple or all remaining skipped segments from the LCG (optionally from all LCGs)). Then, if space exists after the second selection, a third selection is performed, which includes the remaining "new" segments from the LCG (e.g., multiple or all remaining new segments from the LCG (optionally from all LCGs)). If space exists after the third selection, the remaining segments from the LCG that have new data are selected (e.g., multiple or all segments from the LCG (optionally from all LCGs) that have new data). If space remains after the fourth selection, any remaining segment from the LCG (i.e., any type of remaining segment) is selected (e.g., multiple or all remaining segments from the LCG (optionally from all LCGs)). By implementing this second exemplary method, the UE can ensure that the gNB receives updates to the buffer size (and delay budget) of the most critical segment as early as possible. This is particularly advantageous in cases of delayed arrival of large bursts on critical channels.

[0277] In the third exemplary method, at least one segment from the LCG with new data is identified (e.g., multiple or all segments from the LCG (optionally all LCGs)). Then, among these identified segments, the segment with the highest ratio of critical remaining time to buffer size is selected (e.g., multiple or all segments with the highest ratio of critical remaining time to buffer size). This selection may (indiscriminately) include any of new segments, skipped segments, and existing segments. Then, if space is available after the first selection, the remaining "skipped" segments from the LCG are selected (e.g., multiple or all remaining skipped segments from the LCG (optionally all LCGs)). After the second selection, if space is available, the remaining "new" segments from the LCG are selected (e.g., multiple or all remaining new segments from the LCG (optionally all LCGs)). If space is available after the third selection, the remaining segments from the LCG with new data are selected (e.g., multiple or all segments with new data from the LCG (optionally all LCGs)). If space remains after the fourth selection, the remaining segments from the LCG (i.e., any type of remaining segment) are selected (e.g., multiple or all remaining segments from the LCG (optionally from all LCGs)). By implementing this third exemplary method, the UE ensures that segments with a known buffer size are prioritized for transmission in less time (e.g., minimum delay budget).

[0278] For at least one or each of the exemplary methods described above, further arbitration may be required between the selected segments at each selection step (e.g., if five segments were identified during the first selection, but only space exists for three segments, further arbitration is needed). In such cases, one (or a combination thereof) of the following criteria can be applied to arbitrate which segment(s)(s) to retain:

[0279] A. Logical Channel Priority: You can select segments belonging to the LCG that includes the LCH with the highest priority (this will implement application MAC-level QoS);

[0280] B. Remaining Time: You can select the segment with the most critical remaining time (this allows the gNB to receive delay information on time);

[0281] C. The ratio of remaining time to buffer size (this prefers to send segments with a known buffer size in less time);

[0282] D. PDU set importance information (PSI) associated with the PDU sets of each segment (this favors the most important PDU sets); and

[0283] E. PDU Set Integrated Importance Information (PSIHI) QoS parameters associated with the PDU sets of each segment (e.g., segments containing PDU sets with PSIHI set to false can be skipped because when PSIHI is set to false, it means that the application decoder can handle (e.g., manage or process) the reception of a portion of the PDU set).

[0284] In some cases, DSR triggers can follow the same triggers as BSRs because the delay information is sent at segment creation time. Therefore, when the remaining time becomes critical, there is no need to send additional triggers (e.g., dedicated DSR triggers).

[0285] In other examples, DSR triggering is achieved by continuously comparing the remaining time associated with each segment with a remaining time threshold configured by the gNB. Therefore, DSR is only sent when the remaining time associated with some data has reached a critical level.

[0286] For all examples, if a new segment has not yet been selected, the UE can change the state of the new segment so that the new segment is represented as a "skipped" segment.

[0287] In subsequent method step 706, the UE concatenates the selected segment reports (e.g., links them together in a chain or series) into a DSR format, such as one of the formats described in Figures 9a, 9b, 10, and 11. The DSR is then sent to the gNB.

[0288] The formatting of DSR will now be described with reference to Figures 9a, 9b, 10, and 11.

[0289] For all segments, the LCG identifier (ID) fields 901, 951, 1001, and 1101 are configured to include an LCG identifier that defines the LCG containing the segment (e.g., LCG0, LCG1, LCG2, etc. as shown in Figure 10).

[0290] For all segments, the segment ID fields 902, 954, 1002, and 1102 are configured to indicate a segment identifier that defines the segment being reported (one or more). "New" or "Skip" segments are configured with segment type identifiers or flags 903, 953, 1003, and 1103, which include linguistic terms (e.g., "New") and / or numerical values ​​(e.g., "1"). "New" and "Skip" segments also have delay fields 905, 955, 1005, and 1105, which are set to the remaining timer value associated with the segment. The remaining timer value is configured (e.g., adjusted) to the expected time for the first transmission attempt of the DSR. Furthermore, "New" and "Skip" segments have buffer size fields 904, 954, 1004, and 1104, which are set to the buffer size associated with the segment.

[0291] The segment type identifier of an existing segment is configured with the value "0", while this value is set to "1" for a new (or skipped) segment. Existing segments do not have a delay field. Existing segments are configured with buffer size fields 904, 954, 1004, and 1104, which are set to the buffer size associated with the segment. In some embodiments, the buffer size field is a concatenation of the buffer size field and the delay / buffer size field (e.g., a concatenation of 904 and 905 in Figure 9a, 954 and 955 in Figure 9b, 1004 and 1005 in Figure 10, and 1104 and 1105 in Figure 11).

[0292] The use of the “new” identifier means that different types of segments (e.g., “new” and “existing”) can be distinguished from each other (e.g., within a DSR message), which allows delayed information to be sent less frequently, thus allowing for savings in signaling overhead.

[0293] Even when no delay information is reported, the segment ID is systematically sent, which advantageously allows the gNB to continuously (e.g., using an internal counter) monitor the delay of sensitive data based on the reception of the first delay information.

[0294] Method 700 proceeds to method step 707, in which the UE analyzes (e.g., checks) whether the gNB has received the previous DSR. If the DSR has been successfully received (i.e., a reception status has been delivered), and if the reception is acknowledged, the UE updates the status of the “new” segments in the previous DSR so that they are now characterized as “existing”.

[0295] If the gNB does not receive the previous DSR (i.e., reception status failed), the UE can activate a retxBSR-Timer, which counts down the time until further attempts are made to transmit a status (request) message. Additionally, the UE updates the "new" statuses in the previous DSRs so that they are now characterized as "skipped".

[0296] Figure 8 is a flowchart of method 800 performed at the gNB when (e.g., from the UE) a Delay Status Report (DSR) is received. In the initial method step 801, the gNB receives the DSR according to any of the formats described above with reference to Figures 9a, 9b, 10, and 11.

[0297] In the subsequent (optional) method step 802, for each element of the delay information contained in the DSR, the gNB adjusts the delay information for the corresponding segment based on the number of retransmissions required to receive the DSR. The delay information references the time of the first transmission attempt. For example, if the MAC PDU containing the DSR has requested several PHY retransmissions for successful reception (e.g., via Hybrid Automatic Repeat Request (HARQ) processing or UE-preferred processing), the number of PHY retransmissions can be recorded in the DSR along with the delay information to establish the actual remaining time.

[0298] In method step 803, the gNB starts a timer for at least one or each of the new segments in the received DSR. The timer represents the delay information contained in the DSR (or is adjusted to account for the number of retransmission attempts, as defined in optional method step 802).

[0299] In method step 804, the gNB updates the buffer size information relative to each segment in the scheduler. Specifically, to determine the scheduling of uplink data, the gNB obtains updates from the served UE. The updates include at least one of the following data types:

[0300] A. Available data for traditional logical channel groups via the traditional BSR process (e.g., as defined in 3GPP document TS 38.321);

[0301] B. Report the remaining time value measured from the first segment and the available data for the corresponding segment; and

[0302] C. Updating available data.

[0303] The remaining time value and available data update can be obtained through DSR for at least one or each of the sensitive LCGs (i.e., data types A and B above).

[0304] By implementing remaining time counters for each segment, the gNB can closely monitor the evolution of both available data and remaining time for each segment. Therefore, the gNB can make advantageous scheduling decisions based on comprehensive knowledge of both traditional LCGs and time-sensitive LCGs with associated segments.

[0305] In this embodiment, the gNB configures the UE via dedicated signaling regarding the conventional LCG, time-sensitive LCG, the maximum number of segments, and (e.g., as defined in method step 705 of Figure 7) decision criteria used for segment selection. Alternatively, delay information may be included in the DSR for each new segment and N subsequent DSR reports for the same segment (where N is an integer configured by the gNB). Further alternatively, delay information may be systematically included in the DSR for each new segment. Still further alternatively, the gNB configures the UE in one of the following three modes:

[0306] A. Delay information only for the new segment;

[0307] B. N consecutive delay messages starting from the creation of the segment; and

[0308] C. System delay information for all segments.

[0309] The gNB configures the UE for each LCG using one of the three modes mentioned above. Each LCG can be managed according to one of the three modes. In this way, DSR messages for each LCG can exist in several formats.

[0310] Figure 9a is a schematic diagram illustrating the short DSR format and the short truncated DSR format. The short DSR format is used when only one LCH (or LCG) needs to be reported. The short truncated DSR, with the same format as the short DSR, is used when the available radio resources are equal to the size of the short DSR format and more than one LCH (or LCG) has data available for transmission. Specifically, the message consists of an LCG ID 901 (e.g., including at least 3 bits). The LCG ID field identifies the (one or more) LCH group whose delay status is being reported.

[0311] The Segment ID field 902 identifies different segments in the LCG (e.g., according to an embodiment, it includes no more than 4 bits or includes at least 4 bits). For short DSR format and short truncated DSR format, even if the LCG includes several segments, only one segment is reported.

[0312] The term "new" in field 901 (e.g., including at least one bit) indicates whether the segment identified by the segment ID field 902 is new or existing. In this way, the term "new" is an example of ID bits indicating whether the segment is new or existing. If the segment is new, associated delay information (e.g., including no more than 3 bits or including at least 3 bits) is reported in field 905, and associated buffer size (e.g., including no more than 5 bits or including at least 5 bits) is reported in field 904. If the segment is not new (i.e., existing), delay information is not included, and the buffer size may only be reported in 904. Alternatively, the buffer size field 904 may be combined with the delay field 905 (e.g., to form a single 8-bit field).

[0313] Figure 9b is a schematic diagram illustrating the extended short DSR and extended short truncated DSR formats. The extended short DSR format (e.g., truncated or untruncated) is used in the context of IAB applications where a greater number of LCGs need to be supported.

[0314] When logicalChannelGroupIAB-Ext is configured (e.g., as defined in 3GPP document TS 38.321), the extended short DSR format is used when only one LCH (or LCG) needs to be reported.

[0315] When logicalChannelGroupIAB-Ext is configured, the extended short truncated DSR format (which has the same format as the extended short DSR format) is used when the available radio resources are equal to the size of the extended short DSR format and more than one LCH (or LCG) has data available for transmission. Specifically, the message consists of an LCG ID 951 (at least 8 bits). The LCG ID field identifies the LCH group (one or more) from which the delay status is being reported.

[0316] The Segment ID field 954 identifies different segments within an LCG (e.g., depending on the embodiment, it may include no more than 4 bits or at least 4 bits). For the Extended Short DSR format and the Extended Short Truncated DSR format, only one segment is reported, even if the LCG includes several segments.

[0317] The term "new" in field 953 (e.g., including at least one bit) indicates whether the segment identified by the segment ID field 954 is new or existing. If the segment is new, associated latency information (e.g., including no more than 3 bits or including at least 3 bits) is reported in field 952, and the associated buffer size (e.g., including no more than 8 bits or including at least 8 bits) is reported in field 955. If the segment is not new (i.e., existing), latency information is not included, and the buffer size may be reported only in field 954. Alternatively, fields 954 and 955 may be combined into a single field (e.g., including at least 12 bits).

[0318] Figure 10 is a schematic diagram illustrating the message formats used as long DSR, long truncated DSR, or preemptive DSR. The long DSR format is used when reporting multiple LCGs and the available radio resources equal the size required to report all LCGs. The long truncated DSR format is used when reporting multiple LCGs and the available radio resources are greater than the short DSR format but less than the size required to report all LCGs. The preemptive DSR format is used in the IAB context.

[0319] Specifically, the message consists of 8 (eight) LCG flags, one flag for each corresponding LCGi (e.g., LCG). 0-7 Field 1001 indicates the presence of a delay status report for the corresponding LCGi. If the value in field 1001 (i.e., the LCGi field) is set to 1, this indicates that the delay status for the LCGi is "delivered" (i.e., reported). If field 1001 is set to 0, this indicates that no delay status report is made for the LCGi.

[0320] LCG delay states are included in ascending order based on LCGi. The delay state of an LCG (e.g., 1006, 1007) includes delay information for all segments in the LCG. The LCG delay state is reported k times, where k is the number of LCGs being reported (i.e., equal to the number of LCGi bits set to 1).

[0321] Initially, the segment location map 1002 indicated the segment S for each segment. i (For example, S) 0-7 The existence of a delay state for the corresponding segment (e.g., S) is indicated if the Si field is set to 1. i The delay status of ). If the Si field is set to 0, this indicates that no report has been submitted for the corresponding segment (e.g., S). i The delayed state of ).

[0322] For at least one or more segments, the status report includes the term (or flag) “new” (e.g., including at least one bit) in field 1003, indicating whether the segment is new or existing. If the segment is new, associated delay information (e.g., including no more than 7 bits or including at least 7 bits) is reported in field 1005, and associated buffer size (e.g., including no more than 7 bits or including at least 7 bits) is reported in field 1004. If the segment is not new (i.e., existing), delay information is not included, and the buffer size may be reported only in field 1005. Alternatively, fields 1004 and 1005 may be combined into a single field (e.g., including 15 bits). In some embodiments, when the segment is not new (i.e., existing), the buffer size is reported only in field 1005 (e.g., including 7 bits). The segment delay status is reported “m” times for an LCG, where m is equal to the number of Si bits set to 1.

[0323] Figure 11 is a schematic diagram illustrating the message formats used as extended long DSR, extended long truncated DSR, or extended preemptive DSR formats. Individual messages should be used when configuring logicalChannelGroupIAB-Ext (e.g., as defined in 3GPP document TS 38.321). The extended long DSR format is used when reporting multiple LCGs and the available radio resources equal the size required to report all LCGs. The extended long truncated DSR format is used when reporting multiple LCGs and the available radio resources are greater than the short DSR format but less than the size required to report all LCGs. Extended preemptive DSR can be used in the IAB context.

[0324] Specifically, for each LCGi, the message consists of 256 LCG flags. Field 1101 indicates the presence of a delay status report for the corresponding LCGi. A field 1101 (i.e., the LCGi field) set to 1 indicates that the delay status for the LCGi is "delivered" (i.e., reported). If the value in field 1101 is set to 0, this indicates that no delay status report has been made for the LCGi. LCG delay statuses are included in ascending order based on LCGi, and the delay status of an LCG (e.g., in fields 1106, 1107) includes delay information for all segments within the LCG. The LCG delay status is reported k times, where k is the number of LCHs being reported (i.e., equal to the number of LCGi bits set to 1).

[0325] Initially, the segment location map 1102 indicated the location of each segment S. i (For example, S) 0-7 The existence of a delayed state of S. i When the field is set to 1, this indicates that a report was made for the corresponding segment (e.g., S).i The delayed state of S. i If the field is set to 0, this indicates that no report was submitted for the corresponding section (e.g., S). i The delayed state of ).

[0326] For at least one or more segments, the status report includes the term "new" (e.g., including at least 1 bit) in field 1103, indicating whether the segment is new or existing. If the segment is new, associated delay information (e.g., including no more than 7 bits or including at least 7 bits) is reported in field 1105, and associated buffer size (e.g., including no more than 7 bits or including at least 7 bits) is reported in field 1104. If the segment is not new (i.e., existing), delay information is not included, and the buffer size may be reported in 1105. The buffer size may be reported in a combined field formed by 1104 and 1105 (e.g., including 15 bits). In an embodiment, when the segment is not new (i.e., existing), the buffer size is reported only in field 1105 (e.g., including 7 bits). For an LCG, the segment delay status may be reported "m" times, where "m" is equal to the number of Si bits set to 1.

[0327] In alternative embodiments of this disclosure, the buffer status reporting mechanism is configured to provide an indication of the amount of data to be transmitted from (i.e., of) at least two segments, wherein the status report is transmitted based on timing information associated with at least one of the at least two segments. Exemplary methods according to these alternative embodiments enable user equipment to transmit a single signal that provides an indication of the data carried by two or more segments of a single channel (i.e., thereby simplifying the status reporting process), allowing the network to easily predict when a set of data packets will pass. This advantageously allows for more efficient allocation of network resources while also reducing network transmission load.

[0328] Compared to the exemplary methods described above with respect to Figures 5 through 11, these alternative embodiments do not rely on reporting specific timing information associated with individual segments (and / or data packets carried therein). Instead, the report itself can be interpreted by the network as an indication that the corresponding data packet is about to pass.

[0329] Further details of the delayed state reporting mechanism according to these alternative embodiments will now be described with reference to Figures 12, 13a, 13b, 14, 15, 16, 17, 18, 19, and 20. For the sake of brevity, descriptions of any features similar to those of the previously described embodiments are omitted in the following paragraphs.

[0330] Figure 12 is a flowchart illustrating method 1200 performed at UE MAC layer 410 (as shown in Figure 4) when a delayed status reporting mechanism is triggered. Method 1200 will now be described with reference to Figures 13a, 13b, 14, and 15, which illustrate example status reports generated by this method. Furthermore, with reference to Figures 16 through 20, these figures illustrate schematic diagrams illustrating triggering mechanisms for status reporting according to embodiments of the present disclosure.

[0331] As described above, the LCG is subdivided into multiple "segments," each defining a portion of the LCG. In Figures 16 through 20, segments S1, S2, and S3 are depicted as silos or containers that can (e.g., as indicated by the arrows in Figure 17) store PDU set data. Each segment can be associated with one or more PDU sets having a similar buffer state. Information about the PDU sets is compiled into a status report, which is transmitted to the network when trigger conditions are met. In Figures 16 through 20, the transmission of status reports is depicted as being controlled by multiple "triggers" T1, T2, and T3. When trigger conditions are met (e.g., as depicted by the shaded trigger T1 in Figure 19), a trigger can be activated to enable the transmission of the status report.

[0332] Initial method step 1201 involves the UE initiating a delay status reporting mechanism based on the identification of one or more delay status reporting trigger conditions. The delay status reporting trigger conditions are summarized as follows:

[0333] A. During the uplink, for at least one LCH of the LCG, data becomes available to the MAC entity;

[0334] B. During the uplink, resources are allocated for sending MAC PDUs, and the number of padding bits is equal to or greater than the size of the Delay Status Report (DSR);

[0335] C. The first retry timer expires (e.g., retxDSR-Timer), causing a timer to be set again when delayed status report transmission fails, thereby attempting delayed status report transmission at different times (as described in step 707 of the method below); and

[0336] D. The second (periodic) timer expires (e.g., periodicDSR-Timer), allowing the gNB to configure the UE to use the timer to send periodic delayed status reports.

[0337] The remaining time (e.g., discard timer value) of at least one segment of the E.LCG has reached a remaining time threshold (e.g., if the discard timer value of at least one segment is equal to or less than the threshold timer value).

[0338] F. After sending the BSR, the user equipment did not receive a scheduling authorization from the base station within the predetermined time period.

[0339] Similar triggering conditions can be associated with buffer status reporting mechanisms (e.g., as defined in 3GPP document TS38.321, Clause 5.4.5).

[0340] In this embodiment, the delay status report is primarily based on the remaining time trigger condition (i.e., point E in the list of trigger conditions above). Optionally, one or more other trigger conditions (i.e., point AD) may be used as auxiliary (or supplementary) trigger conditions. For example, these auxiliary conditions may be considered only if the primary trigger condition is met.

[0341] Step 1202 of the second method involves creating a status report for the LCG. This involves the UE checking (e.g., identifying) whether one or more segments of the LCG have reached at least one remaining time threshold. The UE then generates a status report defining a buffer size corresponding to at least one segment of the LCG. Optionally, the buffer report may also include latency information associated with at least one segment.

[0342] Figures 16 through 18 illustrate how data associated with different segments of the LCG can change over time. For example, in Figure 17, the first segment S1 receives data with a corresponding discard timer value of 30 (e.g., milliseconds). Upon receiving the data, the discard timer for the first segment S1 begins counting down from 30. Five milliseconds later, the second segment S2 receives a set of PDU data with a discard timer value of 30 (see Figure 18). The timing information of this PDU set data does not match the data associated with S1 because the remaining time value of S1 has now decreased to 25. Instead, new PDU set data is added to S2, and the corresponding discard timer begins counting down from 30. Fifteen milliseconds later, another set of PDUs with a discard timer value of 16 is received (see Figure 19). This data is added to the third segment S3, and the corresponding discard timer begins counting down from 16.

[0343] The status report includes the sum of buffer size values ​​associated with segments of the LCG that have reached their remaining time threshold. For example, at the time shown in Figure 19, the remaining timer value (i.e., 10) of the first segment S1 has reached the threshold (i.e., 10), so the status report can be configured to include an indication of the total buffer size value associated with the data of the first segment.

[0344] In an embodiment, the status report may include the sum of buffer size values ​​associated with at least one (e.g., each) segment of the LCG, having a remaining time greater than a configured remaining time threshold but less than an additional (or auxiliary) remaining time threshold. In this way, the additional remaining time threshold defines a range of timer values ​​above the first threshold, for which data from any segment falling within that range will be included in the status report. Each of the first and / or second thresholds (i.e., TH1 and TH2 in Figure 16) can be configured as a full integer value (e.g., milliseconds). The threshold can be configured as a multiple of the duration of a network cycle (e.g., 1 millisecond).

[0345] In the exemplary arrangement shown in Figures 16 to 20, the auxiliary threshold is 15. Therefore, at the time depicted in Figure 19, the remaining timer value (i.e., 15) of the second segment has not yet reached the first threshold (i.e., 10), but it has reached the second threshold. Therefore, the data associated with the first and second segments can be included in the status report. In contrast, the remaining time value (i.e., 16) of the third segment S3 has not yet reached the second threshold (i.e., 15), so the data associated with the third segment is not included in the status report.

[0346] In an embodiment, the status report may include the sum of buffer size values ​​associated with all segments that have previously sent DSRs and have remaining unsent data. Figure 20 depicts such a scenario, where the second segment S2 has reached a first threshold (i.e., such that data associated with the second segment will be included in the status report). However, some data for the first segment S1 has not yet been sent to the network. The first segment still has some remaining time available (i.e., 5), therefore the status report is configured to include data associated with both the first and second segments. Optionally, the remaining timer value (i.e., 11) for the third segment S3 has now reached a second threshold (i.e., 15), therefore the associated data for the third segment can also be included in the status report.

[0347] The size of available data for a segment includes the sum of data buffered for that segment in the MAC, RLC, and PDCP layers. Optionally, the size of available data for a segment may take into account data that is not yet in the UE buffer but is expected to be received soon (e.g., within a predetermined time period) based on known burst parameters (such as burst arrival time, average burst size (or minimum burst size)).

[0348] Optionally, if configured by gNB, status reporting is stopped if the total amount of data to be reported is below a predetermined or configured data threshold.

[0349] In this embodiment, since the remaining time threshold used as the trigger condition is configured by the gNB, the associated delay information can be omitted from the status report. Therefore, the gNB can interpret the transmission of the status report as an indication that the reported data packet is about to pass.

[0350] In some embodiments, the remaining time can be reported if it is significantly lower than a threshold configured to trigger the event (e.g., the remaining time is the duration of one network cycle (1 millisecond)). Example reasons for reporting the remaining time may include at least one of the following:

[0351] A. The previous DSR transmission has failed (e.g., as determined in method step 1207 of Figure 12);

[0352] B. A report for the given LCG has been selected (e.g., as determined in method step 1205 of Figure 12); and

[0353] C. Channel granting is delayed due to priority management.

[0354] In cases where remaining time is reported, two or more (e.g., individual) segments may have different remaining times. In such cases, the reported remaining time can be configured to be equal to at least one of the following:

[0355] A. Minimum remaining time (e.g., the minimum remaining time for all packets associated with the status report);

[0356] B. The average of different remaining times;

[0357] C. The mean of remaining time, as measured by the available buffer size; and

[0358] D. Remaining time for the segment with the maximum available buffer size.

[0359] At step 1204 of the fourth method, the UE analyzes the available radio resources for transmitting DSR, and then the UE calculates how many LCG reports can be cascaded in the available radio resources.

[0360] Typically, a DSR defines a message from the UE to the gNB that outlines the amount of data available for uplink transmission (and optionally indicates the associated delay budget).

[0361] According to the exemplary arrangement, the purpose of the DSR is to assist or guide the gNB in ​​scheduling resource allocation to enable uplink data transmission. The DSR can be configured in various formats, as will now be described with reference to Figures 13a, 13b, 14, and 15.

[0362] If the available radio resources are greater than or equal to the size of the short DSR format and less than the minimum size of the long DSR format, then only space exists for reporting one LCG using the short DSR format. If the available resources are greater than or equal to the minimum size of the long DSR format, then the long DSR format can be used to report at least two LCGs. The short DSR format is described in more detail below with reference to Figures 13a and 13b, and the long DSR format is described with reference to Figure 14.

[0363] In this embodiment, if the available radio resources are greater than or equal to one byte and less than three bytes, there is only space available for reporting one LCG using the short DSR format. If the available resources are greater than or equal to three bytes, the long DSR format can be used to report at least two LCGs.

[0364] When the UE has only one LCG to report, the DSR format is called the short DSR format. If the UE must select one LCG from multiple LCGs, the DSR message is called the truncated DSR format (see Figure 13a). Therefore, the short DSR format and the truncated DSR format are functionally the same type of DSR message with different names.

[0365] When available radio resources match all LCGs available for reporting, the DSR message in Figure 14 is called the long DSR format. If the UE must select one LCG from multiple LCGs, the DSR message in Figure 14 is called the long truncated DSR format. Therefore, the long DSR format and the long truncated DSR format are functionally the same type of DSR message with different names.

[0366] In the context of Integrated Access and Backhaul (IAB), the DSR mechanism can be used for communication between individual IAB nodes. For example, an IAB mobile terminal (IAB-MT) can provide its parent IAB distributed unit (IAB parent DU) or IAB donor DU (IAB donor DU) with information about the amount of data that can be expected to arrive at the IAB-MT from child nodes and / or UEs (i.e., those connected to the IAB-MT) and its associated delay budget.

[0367] In embodiments, if the maximum number of LCGs is greater, the DSR format is referred to as the extended short DSR format (as shown in Figure 13b). If only one LCG is selected from multiple LCGs, the DSR message is referred to as the extended short truncated DSR format (see Figure 13b). When available radio resources match all LCGs available for reporting, the DSR message is referred to as the extended long DSR format (as shown in Figure 15). If one LCG is selected from multiple LCGs, the DSR message of Figure 15 is referred to as the extended long truncated DSR format.

[0368] Method 1200 continues to the fifth method step 1205, in which, if all candidate LCGs cannot be adapted to available radio resources, the UE selects an LCG based on multiple criteria. These selection criteria may include:

[0369] A. Logical Channel Priority: You can select a segment belonging to the LCG that includes the LCH with the highest priority (this will implement application MAC-level QoS);

[0370] B. Remaining Time: You can select the segment with the most critical remaining time (this allows the gNB to receive delay information on time);

[0371] C. The ratio of remaining time to buffer size (this prefers to send segments with a known buffer size in less time);

[0372] D. PDU set importance information (PSI) associated with the PDU sets of each segment (this favors the most important PDU sets); and

[0373] E. PDU Set Integrated Importance Information (PSIHI) QoS parameters associated with the PDU sets of each segment (e.g., segments containing PDU sets with PSIHI set to false can be skipped because when PSIHI is set to false, it means that the application decoder can handle (e.g., manage or process) the reception of a portion of the PDU set).

[0374] In one example, DSR is triggered by continuously comparing the remaining time associated with each segment with the remaining time threshold configured by the gNB, so that DSR is only sent when some data reaches a critical level of remaining time.

[0375] In another example, the DSR trigger is able to follow the same trigger as the BSR (because the delay information is sent at the segment creation time), so when the remaining time becomes critical, no additional trigger is needed to send a dedicated DSR.

[0376] In subsequent method step 1206, the UE concatenates the selected segment reports (e.g., links them together in a chain or series) into a DSR format, such as one of the formats described in Figures 13a, 13b, 14, and 15. The DSR is then sent to the gNB.

[0377] The formatting of DSR will now be described with reference to Figures 13a, 13b, 14 and 15.

[0378] For all segments, the LCG identifier (ID) fields 1301, 1351, 1401, and 1501 are configured to include an LCG identifier that defines the LCG containing the segment (e.g., LCG0, LCG1, LCG2, etc. as shown in Figure 14).

[0379] Optional delay fields 1303, 1353, 1403, and 1503 are set to remaining timer values ​​associated with at least one segment of the LCG (as calculated in step 1202). The resulting remaining timer values ​​can be configured (e.g., adjusted) to the expected time of the first transmission attempt of the DSR.

[0380] Since the delay threshold trigger is configured by gNB, the delay field can be omitted.

[0381] The buffer size fields 1303, 1353, 1402, and 1405 are set to the buffer size associated with at least one segment of the LCG calculated during step 1202.

[0382] Method 1200 continues to method step 1207, in which the UE analyzes (e.g., checks) whether the gNB has received the previous DSR. If the gNB has not received the DSR (i.e., the reception status has failed), the UE can start a retxBSR-Timer, which counts down the time until a further attempt to transmit a status (request) message is made.

[0383] Figure 13a is a schematic diagram illustrating the short DSR format and the short truncated DSR format. The short DSR format is used when only one LCH (or LCG) needs to be reported. The short truncated DSR, with the same format as the short DSR, is used when the available radio resources are equal to the size of the short DSR format and more than one LCH (or LCG) has data available for transmission. Specifically, the message consists of an LCG ID 1301 (e.g., including at least 3 bits). The LCG ID field identifies the (one or more) LCH group whose delay status is being reported. The buffer size is reported in field 1302 (e.g., including no more than or at least 8 bits). Optional delay information is reported in field 1303 (e.g., including no more than or at least 8 bits).

[0384] Figure 13b is a schematic diagram illustrating the extended short DSR and extended short truncated DSR formats. The extended short DSR format (e.g., truncated or untruncated) is used in the context of IAB applications where a greater number of LCGs need to be supported.

[0385] When logicalChannelGroupIAB-Ext is configured (e.g., as defined in 3GPP document TS 38.321), the extended short DSR format is used when only one LCH (or LCG) needs to be reported.

[0386] When logicalChannelGroupIAB-Ext is configured, the extended short truncated DSR format (which has the same format as the extended short DSR format) is used when the available radio resources are equal to the size of the extended short DSR format and more than one LCH (or LCG) has data available for transmission. Specifically, the message consists of an LCG ID 951 (at least 8 bits). The LCG ID field identifies the (one or more) LCH group whose delay status is being reported. The buffer size is reported in field 1352 (e.g., including no more than or at least 8 bits). Optional delay information is reported in field 1353 (e.g., including no more than or at least 8 bits).

[0387] Figure 14 is a schematic diagram illustrating the message formats used as long DSR, long truncated DSR, or preemptive DSR. The long DSR format is used when reporting multiple LCGs and the available radio resources equal the size required to report all LCGs. The long truncated DSR format is used when reporting multiple LCGs and the available radio resources are greater than the short DSR format but less than the size required to report all LCGs. The preemptive DSR format is used in the IAB context.

[0388] Specifically, the message consists of 8 (eight) LCG flags, one flag for each corresponding LCGi (e.g., LCG). 0-7 Field 1401 indicates the presence of a delay status report for the corresponding LCGi. If the value in field 1401 (i.e., the LCGi field) is set to 1, this indicates that the delay status for the LCGi is "delivered" (i.e., reported). If field 1401 is set to 0, this indicates that no delay status report is made for the LCGi.

[0389] LCG delay states are listed in ascending order based on LCGi. The delay state of an LCG (e.g., 1402, 1403) includes optional delay information for the LCG. The LCG delay state is reported k times, where k is the number of LCGs being reported (i.e., equal to the number of LCGi bits set to 1). For at least one LCG or individual LCGs, optional delay information is reported in field 1402 (e.g., including no more than or at least 8 bits), and the associated buffer size is reported in field 1403 (e.g., including no more than or at least 8 bits).

[0390] Figure 15 is a schematic diagram illustrating the message formats used as extended long DSR, extended long truncated DSR, or extended preemptive DSR formats. Individual messages should be used when configuring logicalChannelGroupIAB-Ext (e.g., as defined in 3GPP document TS 38.321). The extended long DSR format is used when reporting multiple LCGs and the available radio resources equal the size required to report all LCGs. The extended long truncated DSR format is used when reporting multiple LCGs and the available radio resources are greater than the short DSR format but less than the size required to report all LCGs. Extended preemptive DSR can be used in the IAB context.

[0391] Specifically, for each LCGi, the message consists of 256 LCG flags. Field 1501 indicates the presence of a delay status report for the corresponding LCGi. A setting of field 1501 (i.e., the LCGi field) to 1 indicates that the delay status for the LCGi is "delivered" (i.e., reported). If the value in field 1501 is set to 0, this indicates that no delay status report has been made for the LCGi. LCG delay statuses are listed in ascending order based on LCGi, and the delay status of an LCG (e.g., in fields 1502, 1503) includes optional delay information for the LCG. The LCG delay status is reported k times, where k is the number of LCHs being reported (i.e., equal to the number of LCGi bits set to 1).

[0392] For at least one LCG or each LCG, optional delay information is reported in field 1502 (e.g., including no more than or at least 8 bits), and the associated buffer size is reported in field 1503 (e.g., including no more than or at least 8 bits).

[0393] Further description of embodiments of this disclosure:

[0394] Within the context of buffer status reporting, consider the following points:

[0395] A. The UE can be configured to calculate the remaining time based on the PDCP discard timer value. Further considerations include whether the UE reports one value or multiple values. Furthermore, how this can be modeled in the PDCP specification is also considered. Additionally, which UEs will support this is further considered.

[0396] B. When the UE reports remaining time / If the UE reports remaining time, a reference time for the remaining time can be determined based on the point of the first transmission of the information. Further consideration is whether UE-internal priority processing can affect this.

[0397] In addition, within the context of buffer status reporting, consider the following points:

[0398] A. The working assumption is that a new, separate MAC CE can be defined for DSR (e.g., including residual latency and associated data volume) reports (e.g., DSR reports may not be coupled with BSR reports). A detailed definition of associated data volume is further considered.

[0399] B. DSR reports can be based on supported thresholds. For example, a DSR report can be triggered when the remaining latency of a PDU / PDU set falls below a threshold configured in the NW. Thresholds can be configured for each LCG. Further consideration is whether to support configuring multiple thresholds for LCGs. The definition of remaining time is also under further consideration.

[0400] There are several reasons for multiplexing PDU sets with different remaining times within a single LCG. First, different PDU sessions can be multiplexed within a single QoS stream. For example, when two video sessions with the same QoS requirements (e.g., the same PSDB) are mapped to the same QoS stream. In this case, if the PDU sets of the two PDU sessions are not synchronized, different bursts may arrive at the UE buffer at different times, thus having different remaining times. Another possibility is that the PSDB may be larger than the image segment, in which case the UE may have two PDU sets with different remaining times in its buffer. Another possibility is a channel based on non-PDU sets, such as one used to handle attitude PDUs. Each attitude PDU will have different remaining times in the UE buffer. Finally, there remains the possibility that two PDU sessions with similar QoS requirements but different PDSBs can be multiplexed within the same QoS stream. To report latency, two solutions will now be described: 1) reporting based on multiple thresholds, and 2) reporting based on a single threshold.

[0401] 1. Multiple values, multiple thresholds:

[0402] When multiple values ​​can be reported in a single DSR, the simplest solution is to report each PDU set separately. However, overhead can be reduced by grouping PDU sets with the same remaining time into a single value in the DSR report. The reported buffer status should then take into account the available data for all grouped PDU sets. Proposal 1: For an LCG, PDU sets with the same remaining time can be grouped into a single DSR report. Proposal 2: For a group of PDU sets with the same remaining time, the reported buffer size can indicate the amount of data available for all grouped PDU sets.

[0403] Receiving DSR reports when the remaining time is not critical can be advantageous for the network. For example, sending DSRs may be less straightforward under congested conditions. Sending DSRs earlier appears to be more efficient and allows the network to monitor the remaining time for each PDU set once the first DSR is received. This also provides the network with greater flexibility to anticipate scheduling decisions. To send DSRs earlier, the triggering could be similar to BSR triggering, when data first becomes available for uplink transmission. Proposal 3: The chosen triggering could allow DSR reports to be sent before the remaining time becomes critical (e.g., similar to BSR triggering, when new data becomes available).

[0404] After the DSR is sent early, when the first data is available for uplink transmission, the UE later sends the updated buffer state to the network, allowing the network to monitor the evolution of the remaining time. Since the network has already received the remaining time information, it is not necessary to send the remaining time information every time. Proposal 4: When new data is ready for uplink transmission of an LCG, the updated DSR can be sent using only the buffer state.

[0405] 2. Single threshold:

[0406] As discussed in previous chapters (i.e., multiple values, multiple thresholds), multiple PDUs can be reused within an LCG. If the PDU sets have similar delay budgets, similar periodicity, and synchronized image generation times, they may be able to reach the delay threshold trigger simultaneously. Another example is two asynchronous PDU sets or PDU sets with different delay budget requirements.

[0407] Figures 16 to 20 illustrate examples of LCG multiplexing of three PDU sets (S1, S2, S3) managed by PDCP discard timers (DT1, DT2, DT3). Remaining time counters (RT1, RT2, RT3) are managed for each PDU set. All remaining time counters are compared to a single remaining time threshold (TH1) configured for the network.

[0408] Figure 17 - First data from PDU set S1: First, data becomes available to PDU set S1, PDCP notifies the discard timer value DT1 of 30ms, and the remaining time counter RT1 is set to 30ms.

[0409] Figure 18 - First data from PDU set S2: After 5ms, data becomes available for the second PDU set (S2), the PDCP notifies the 30ms discard timer value DT2, and the remaining time counter RT2 is set to 30ms. On the other hand, the remaining time counter RT1 is now at 25ms.

[0410] Figure 19 - First data and first trigger from PDU set S3: After 15ms, data becomes available for the third PDU set (S3), the PDCP notifies the discard timer value DT3 of 16ms, and the remaining time counter RT3 is set to 16ms. Meanwhile, the remaining time counter RT1 is now at 10ms, triggering a DSR report with the S1 buffer state. The remaining time counter RT2 is now at 15ms.

[0411] Figure 20 - Second Trigger: After 5ms, the remaining time counter RT2 reaches the remaining time threshold and triggers DSR for PDU set 2. The remaining time counter RT1 is at 5ms and the remaining time counter RT3 is at 11ms.

[0412] In another example, if the discard timer DT3 is 15ms instead of 16ms, two independent PDU sets S2 and S3 will simultaneously reach their remaining time thresholds. In a single-threshold system, it is not necessary to send two DSRs; a single DSR can report the sum of available data from both PDU sets, thus minimizing overhead. Proposal 5: For an LCG, the sets of PDUs that simultaneously reach their remaining time thresholds can be reported in a single DSR.

[0413] Returning to the current example, when S2 reaches the remaining time threshold, S3 is 1ms away from reaching the same threshold. In a single-threshold system, there may be some flexibility in the threshold definition (which can be configured by the network), allowing sets of PDUs with nearly identical remaining times to be reported in the same DSR. Proposal 6: For an LCG, any set of PDUs (e.g., multiple sets of PDUs) that reaches the remaining time threshold almost simultaneously can be reported in a single DSR.

[0414] Considering Figure 19, when S1 reaches the remaining time threshold, the UE may subsequently fail to send the corresponding DSR report. Similar to BSR truncation reports, DSR reports may have been arbitrated to favor higher-priority LCGs. Intra-UE priority processing may also delay DSR transmission. Considering Figure 20, if S1 DSR has not been sent when S2 is triggered, sending a single DSR report combining S1 and S2 may be of interest. Proposal 7: For an LCG, the reported buffer status may include the status related to the set of PDUs that have most recently reached the threshold, as well as the set of PDUs that reached the threshold earlier but have not been associated with a DSR.

[0415] Considering Figure 20, when S2 reaches the remaining time threshold, although the DSR of S1 was sent earlier, some data may remain in the UE buffer corresponding to S1. In this case, it might be of interest to add the data left for S1 to the available data from S2 in a single DSR. Proposal 8: For an LCG, the reported buffer status should include the status associated with the set of PDUs that have most recently reached the threshold and the set of PDUs that reached the threshold earlier but still have available data in the buffer.

[0416] Within the context of buffer status reporting, a further consideration could be to enhance the delayed status report using multiple pairs of data amounts and remaining time. In this disclosure, the indication of multiple pairs of data amounts and remaining time, as well as the PDU set importance (PSI), needs to be included in the DSR to describe possible trigger enhancements. In embodiments, the data amounts and remaining time of each "pair" can be arranged within a single "segment" of the status report.

[0417] 1. Trigger Enhancement:

[0418] For each LCG, a single pair of data volume and remaining time can be allowed in a DSR. Only data not previously reported in a DSR can trigger a new DSR. For an LCG, for each LCH of the LCG, a DSR can be triggered when the minimum remaining value of the running PDCP discardTimer in all PDCP SDUs that have not yet been transmitted in any MAC PDU and have not yet been reported as data volume in the DSR MAC CE becomes lower than the remainingTimeThreshold of the LCG.

[0419] Considering the scenario of a DSR comprising multiple pairs (each pair corresponding to a different remaining time threshold), we can consider which threshold should be used as the trigger for the DSR. A single threshold can be used to trigger the DSR; for example, the lowest remaining time from each pair can be used by default. Alternatively, the network can be configured to use one of the pair thresholds as the trigger. Proposal 1: The remaining time associated with at least one data volume can be used as the trigger for the DSR.

[0420] Since there are multiple pairs, a further consideration could be to report some quantities multiple times if the remaining time of some quantities changes to below the second threshold. Otherwise, the gNB would be unable to track the progress of the UE's transmission buffer filling. In fact, some pairs may have new data quantities that need to be reported. Therefore, it is important that a DSR be triggered if at least one pair of pairs has new data that has exceeded the corresponding remaining time threshold. Proposal 2: A new DSR can be triggered if there is data that has exceeded the second threshold for one of the already reported pairs.

[0421] Since some pairs may have data that has already been reported in previous DSRs, data novelty indicators can be added for each pair. This allows gNB to keep track of the quantitative progress of each pair. For example, if already reported data is now below a lower threshold (e.g., "th2") and some newly arrived data is already below "th2", then two pairs must be reported, and the new pair should be distinguishable from the old pair. Proposal 3: Data novelty indicators can be defined for each pair.

[0422] Since the amount of data already reported will have a small remaining time, identifying individual pairs should be useful, allowing the gNB to track the remaining time evolution of a given amount of data. If pairs are identified, it will not be necessary to add remaining time information when the novelty flag is false. Proposal 4: Pair identifiers can be defined based on the amount of data reported first.

[0423] 2. Importance of PDU set:

[0424] PDU set importance indicators can be used for congestion management. Aside from congestion conditions, PSI is of no use to the network. Therefore, including PSI indicators in the DSR is unlikely to provide any benefit. In fact, it will most of the time not help the network make scheduling decisions. Proposal 5: Do not include PSI indicators in the DSR.

[0425] Further description of embodiments of this disclosure:

[0426] According to another embodiment of this disclosure, details of the “enhanced” delayed status reporting method will now be described with reference to Figures 21 and 22. In the following paragraphs, for the sake of brevity, descriptions of any features similar to those of the previously described embodiments (e.g., as described with respect to Figures 12 through 20) are omitted.

[0427] As described above (e.g., according to method 1200, as shown in Figure 12), status reports can be generated for at least one of multiple “triggers” T1, T2, T3 (e.g., as shown in Figures 16 to 20). According to the embodiments currently described, these triggers can be characterized as separate trigger thresholds and reporting thresholds. For example, the generation of a status report can be based on a single trigger threshold and multiple reporting thresholds. Example trigger thresholds are summarized in points A to F of the above list of trigger conditions (i.e., related to method step 1201). The reporting threshold relates to the remaining time associated with buffered data in a specific segment. However, unlike the previously described embodiments (e.g., the method of 1200) which can report the remaining time of any buffered segment (i.e., without constraints), the method of this embodiment is configured to report only those segments whose remaining time matches a reporting threshold (e.g., exceeds the reporting threshold).

[0428] In some cases, it may be advantageous for a communication network to be configured to report multiple remaining time thresholds for respective LCGs. This can include reporting multiple pairs of remaining time and buffer size (e.g., data volume) for each LCG. Example status reports resulting from such an “enhanced” delay status reporting mechanism will now be described with reference to FIGS. 21 and 22.

[0429] FIG. 21 is a schematic diagram illustrating three example status reports (i.e., Examples A - C) generated by a status reporting method according to the presently described embodiments. Different from the previously described reporting methods, the present embodiment is arranged to dynamically configure different trigger thresholds and reporting thresholds according to one or more than one criterion (as will be described in more detail below). In this way, the present embodiment can consider whether there are any constraints in how the network configures the status reporting trigger thresholds and reporting thresholds. For each of Examples A - C, as shown in FIG. 21, a transmission (TX) buffer representing the current state of data buffered at a RAN node of the network (e.g., a UE) is presented, and a status report (e.g., DSR) generated according to an example configuration of the reporting method. Generally, the example status reports are each divided into multiple sections, where each section includes a “pair” of values, and the pair of values includes a data volume (e.g., N1, N2, N3, N4...) and a remaining time (e.g., T1, T2, T3, T4...) associated with a corresponding portion of the buffered data (e.g., at least one PDU in a set of PDUs). The status report is reported based on the trigger threshold and the reporting threshold. The relationship between the trigger threshold and the reporting threshold is defined by at least one of the following configuration profiles:

[0430] According to the first configuration profile, the trigger threshold is less than or equal to the smaller reporting threshold (e.g., the reporting threshold greater than at least one other reporting threshold (e.g., the maximum reporting threshold)). Thus, the status report is configured with a first pair (or section) reporting critical data (e.g., the most critical data), and the other pairs are arranged to report details of less critical data (e.g., data less critical compared to the data reported by the first pair). Referring to “Example A” in FIG. 21, the trigger threshold is equal to the first remaining time value (T1). The reporting thresholds are defined by the relationship: T1 < T2 < T3. The data volumes N1, N2, N3, N4 correspond to the similarly numbered remaining time values. Finally, T4, N4 are omitted due to lack of reporting space. Thus, the status report includes a first pair that includes T1, N1 (i.e., the most critical data), and the remaining pairs are arranged to report T2, N2 and T3, N3 respectively.

[0431] According to the second configuration file, the all-report threshold can be lower than or equal to the trigger threshold. Thus, the status reports for each pair can be configured to report critical data. The critical data can be refined through multiple pairs, which thus provides a more accurate (i.e., detailed) report of the critical data. Referring to "Example B" in FIG. 21, the trigger threshold is again equal to T1. However, in this case, the report threshold is defined by the following relationship: T1>T0.7>T0.3 (i.e., the values T1, N1 are divided into sub-segments (i.e., N1a, N1b, N1c), and each sub-segment has an associated remaining time value (T1, T0.7, T0.3) that more detailedly reflects the criticality of the data. Again, T4, N4 are omitted due to lack of reporting space. Thus, the status report includes three pairs, and each pair reports critical data (i.e., the data corresponding to T1, N1).

[0432] According to the third configuration file, the trigger threshold is between two (different) report thresholds (e.g., a maximum report threshold and a minimum report threshold). For example, the trigger threshold can be configured to be equal to the mean of the two report thresholds. As a result, the status report can include a first pair for reporting critical data (e.g., the most critical data) and at least two pairs for reporting less critical data (e.g., data that is less critical compared to the data reported by the first pair). Referring to "Example C" in FIG. 21, the trigger threshold is again equal to T1, and T4, N4 are omitted due to lack of reporting space. However, in this case, the report thresholds are defined by the following relationship: T0.5<T1<T2, and N1 is split into N1a and N1b with corresponding remaining time values T1 and T0.5. Thus, the status report includes three pairs, where the first two pairs are for reporting critical data (e.g., T1, N1a and T0.5, N1b respectively), and the third pair is for reporting less critical data (e.g., T2, N2).

[0433] As shown in FIG. 21, the content and semantics of the DSR can vary according to the options considered. Different configurations of the thresholds can be submitted to the UE according to the type of information sought by the gNB.

[0434] The trigger threshold can be configured as "remainingTimeThreshold" by RRC, and the reporting threshold can be represented by the "delay-critical" data definition referring to remainingTimeThreshold. In the case of a delay-critical PDCP SDU, if pdu-SetDiscard is not configured, a PDCP SDU can be configured where the remaining time until discardTimer expires is less than remainingTimeThreshold. If pdu-SetDiscard is configured, a PDCP SDU belonging to a set of PDUs can be configured where at least one PDCP SDU in that set has a remaining time until discardTimer expires that is less than remainingTimeThreshold.

[0435] It is assumed that, depending on certain configuration files, the trigger threshold and the reporting threshold can have the same value. Furthermore, depending on the relationship between the trigger threshold and the reporting threshold, the resulting status report can have different semantics, thus causing different advantages and disadvantages, as outlined in Table 1 below:

[0436] Table 1 - Comparison between different threshold configuration files:

[0437]

[0438] The various reporting and triggering thresholds defined in Table 1 may be advantageous in certain scenarios. To address this, in an embodiment, the network may be configured to set triggering and reporting thresholds without constraints.

[0439] Furthermore, note that the communication environment may change multiple times during an XR session, and the gNB may require different types of status reporting information depending on the changing conditions. It may be advantageous for the network (gNB) to dynamically adjust the relationship between trigger thresholds and different reporting thresholds. In embodiments, the reporting method may include dynamically configuring different trigger thresholds and reporting thresholds to adapt to different conditions.

[0440] According to an embodiment (Option A), multiple different profiles (e.g., profiles such as those defined in Table 1) can be statically configured by the network at the UE (e.g., fixed or predetermined). A first profile can be set as the default profile, wherein the network can be configured to dynamically switch between multiple profiles (e.g., MAC CE).

[0441] According to another embodiment (Option B), the UE can be configured to autonomously select among a set of profiles configured by the network.

[0442] According to yet another embodiment (Option C), the network can be configured to dynamically configure both the trigger threshold and the reporting threshold.

[0443] Figure 22 is a schematic diagram illustrating two example status reports (i.e., examples D and E) generated by the status reporting method according to the embodiment currently described. As will now be described, compared to known reporting methods (which require that only data that has not been previously reported can trigger a new status report), the reporting method currently described enables the triggering of status reports based on previously reported data under certain conditions.

[0444] Both delayed critical data and non-delayed critical data coexist in a single LCH, and it's possible that non-delayed critical data may exist in the TX buffer before delayed critical data (e.g., non-delayed critical data at the queue head (HOL)). Therefore, it's worth considering whether to include such non-delayed critical data in the count of delayed critical data to be reported.

[0445] As illustrated above with reference to Figure 21, non-delayed critical data can be considered when using an appropriate profile (i.e., example AC) of the relationship between thresholds (e.g., trigger thresholds and / or reporting thresholds). For example, the amount of N2 data included in the TX buffer before other data amounts can be reported with its actual remaining time T2 and does not need to be counted as delayed critical data because the remaining time T1 can be reported together with the N1 data amount. Furthermore, the advantage of providing additional enhancements to the reporting method to handle the reporting of HOL non-delayed critical data is limited because the profile can be dynamically changed (see the embodiment of Option A above). However, in some cases, it can be advantageous to consider reporting non-delayed critical data (including data in the buffer that precedes the critical data) when using an appropriate profile of the relationship between the trigger threshold and the reporting threshold. However, it should be noted that, as will now be described with reference to Figure 22, the presence of non-delayed critical data in the LCH buffer that precedes the delayed critical data may cause a problem in triggering a status report.

[0446] At time t=a, the TX buffer contains four distinct data amounts (i.e., N1 to N4). N2 is at the front of the TX buffer (i.e., at the bottom of the vertically arranged segment, as shown in Figure 22), followed by N1, N3, and then N4. The remaining time associated with each data amount is arranged from minimum to maximum (T1 to T4). T1 corresponds to the trigger threshold, while T2, T3, and T4 are all reporting thresholds. When the N1 data amount reaches the remaining time of T1, a status report is triggered and the following pairs are reported: T1, N1; T2, N2; and T3, N3. After a period of time (i.e., at time t=b), the N2 data amount is fully transmitted, and the N1 data amount is partially transmitted, with the remaining data amount equal to N1'. At this point, the non-delay-critical data N2 has already been served first because it is at the head of the TX buffer. Therefore, the network is unaware that more delay-critical data N1' still exists in the TX buffer. The network will not receive any new status report information until the number of new data for reporting reaches the trigger threshold. In the example shown in Figure 22, no new status report will be triggered until the current number of N4s at the remainder of time T3 reaches the remainder of time T1. Therefore, the network may not be aware that non-delayed critical data is being transmitted before delayed critical data.

[0447] This problem can be overcome by allowing delayed-critical data already reported in a previous status report to trigger a new status report under certain conditions. For example, according to an embodiment, the reporting method can be configured such that delayed-critical data already reported (e.g., in a previously transmitted status report) is reported if non-delay-critical data is placed first in the TX buffer and if delayed-critical data has not been sent within a given time period. Note that data that is now delayed-critical (making it possible that it has already triggered the transmission of a new status report) might have been non-delay-critical in the previous report. In the example shown in Figure 22, the UE will know that delayed-critical data N1' is held in its TX buffer, and the UE knows that a new status report will not be triggered earlier than T3-T1 (i.e., when the N4 data amount will become data-critical). At this point, the UE can then decide to trigger a new status report if N1' is not sent during the waiting period and if T3-T1 is too long.

[0448] The advantage of allowing delayed critical data already reported in previous status reports to trigger new status reports under specific conditions (e.g., if non-delayed critical data exists prior to it in the TX buffer) is that the trigger can be used to indicate in the status report which data volume has been reported but is still awaiting transmission, and which data volume is new. This enhancement of known trigger conditions allows the UE to accurately inform the network of the remaining time-critical data without additional complexity in buffer management. In embodiments, status reports can be configured such that each reported pair has an indication distinguishing between newly reported and previously reported data volumes. The advantage of adding new indications is even better accuracy in providing the network with the information.

[0449] According to an alternative embodiment, the method can be configured to sort pairs in the status report based on their corresponding positions in the TX buffer. In this case, the position of the pair in the status report will reflect the position of the data volume in the TX buffer. Therefore, the network will at least know that non-latency critical data is at the beginning of the TX buffer. However, note that this method may require a complex implementation to keep track of or know the position of individual data volumes in the TX buffer. Furthermore, this method will not work if the data volumes are not contiguous in the TX buffer but are interleaved.

[0450] Although at least some embodiments of this disclosure have been described with respect to PDUs (and sets of PDUs), this disclosure is not limited to this type of PDU. The methods of this disclosure can be applied to the transmission and reception of PDUs in any order, and in particular, this disclosure is applicable to in-order PDU transmission at any layer.

[0451] While this disclosure has been described with reference to examples and embodiments, it should be understood that this disclosure is not limited to the disclosed examples and embodiments. Those skilled in the art will understand that various changes and modifications can be made without departing from the scope of this disclosure as defined in the appended claims.

[0452] All features disclosed in this specification (including any appended claims, abstract, and drawings) and / or all steps of any method or process so disclosed may be combined in any combination other than at least some mutually exclusive combinations of such features and / or steps. Unless otherwise expressly stated, each feature disclosed in this specification (including any appended claims, abstract, and drawings) may be replaced by an alternative feature serving the same, equivalent, or similar purpose. Therefore, unless otherwise expressly stated, the disclosed features are merely one example of equivalent or similar features in a general series.

[0453] In the claims, the word "comprising" does not exclude other elements or steps, and the indefinite articles "a" or "an" do not exclude plural. The fact that different features are defined only in mutually different dependent claims does not mean that combinations of these features cannot be used advantageously.

[0454] In the foregoing embodiments (i.e., exemplary arrangements), the functions can be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the functions can be stored on or transmitted via a computer-readable medium as one or more instructions or code, and executed by a hardware-based processing unit.

[0455] Computer-readable media may include: computer-readable storage media, which correspond to tangible media such as data storage media; or communication media, which include any medium that facilitates, for example, the transfer of a computer program from one place to another according to a communication protocol. In this way, a computer-readable medium may correspond to (1) a non-transitory tangible computer-readable storage medium or (2) a communication medium such as a signal or carrier wave. Data storage media may be any available medium that can be accessed by one or more computers or one or more processors to retrieve instructions, code, and / or data structures to implement the techniques described in this disclosure. Computer program products may include computer-readable media.

[0456] By way of example and not limitation, such computer-readable storage media may include RAM, ROM, EEPROM, CD-ROM or other optical disc storage units, disk storage units, or other magnetic storage devices, flash memory, or any other medium that can be used to store desired program code in the form of instructions or data structures and is accessible by a computer. Furthermore, any connection is appropriately referred to as a computer-readable medium. For example, coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technologies such as infrared, radio, and microwave can be included in the definition of medium if instructions are transmitted from a website, server, or other remote source using coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technologies such as infrared, radio, and microwave. However, it should be understood that computer-readable storage media and data storage media do not include connections, carrier waves, signals, or other transient media, but rather refer to non-transient tangible storage media. As used herein, disks (and discs) include compact discs (CDs), laser discs, optical discs, digital versatile discs (DVDs), floppy disks, and Blu-ray discs, wherein a disk typically magnetically reproduces data, while a disc optically reproduces data using lasers. The above combinations should also be included within the scope of computer-readable media.

Claims

1. A method for reporting the buffer status of data to be transmitted on a logical channel group in a communication network, the logical channel group being used to carry a plurality of Protocol Data Unit sets, i.e., PDU sets, associated with a first segment and a second segment of the logical channel group, wherein, Each segment in the first segment and the second segment is associated with at least one set of PDUs, the communication network includes user equipment and base stations, wherein the method at the user equipment includes: transmitting a status report for reporting the buffer status of the first segment and the second segment to the base station, the status report including information indicating the amount of data associated with the first segment and the second segment, wherein the status report is transmitted based on a discard timer value associated with at least one of the first segment and the second segment.

2. The method according to claim 1, wherein, The status report is transmitted if the discard timer value associated with at least one of the first and second segments does not exceed a predetermined timer threshold.

3. The method according to claim 2, wherein, The status report is transmitted when: the discard timer value associated with the first segment does not exceed the timer threshold; and the discard timer value associated with the second segment is greater than the timer threshold and is within a predetermined range of the timer threshold.

4. The method according to claim 2, wherein, The status report is transmitted when: the discard timer value associated with each segment in the first segment and the second segment does not exceed the timer threshold; and the discard timer value associated with the first segment is closer to the timer threshold than the discard timer value associated with the second segment.

5. The method according to claim 4, wherein, The method includes: transmitting a first status report if a drop timer value associated with the first segment does not exceed the timer threshold, wherein the first status report includes information indicating the amount of data of at least one PDU set associated with the first segment at the time of the first status report, wherein the first status report does not include information indicating the amount of data of at least one PDU set associated with the second segment; and transmitting a second status report after transmitting the first status report if a drop timer value associated with the second segment does not exceed the timer threshold, wherein the second status report includes information indicating the amount of data of at least one PDU set associated with each segment in the first segment and the second segment at the time of the second status report.

6. The method according to any one of claims 2 to 5, wherein, The timer threshold is set via the network.

7. The method according to any one of the preceding claims, wherein, The discard timer values ​​for the first segment and the second segment are generated by a discard timer initiated when the user equipment receives data from the corresponding PDU set.

8. The method according to any one of the preceding claims, wherein, The method includes: generating separate status reports for each segment in the first segment and the second segment before transmitting the status report; and cascading the separate buffered status reports to form a combined status report for transmission to the base station.

9. The method according to any one of the preceding claims, wherein, The first segment is associated with a first PDU set, and the second segment is associated with a second PDU set, the second PDU set having timing information different from the timing information of the first PDU set.

10. The method according to any one of the preceding claims, wherein, The method step of stopping the transmission of the status report when the amount of data in the first segment and the second segment is lower than a predetermined data threshold.

11. The method according to claim 10, wherein, The data threshold is determined based on the amount of data indicated by the previously transmitted status report.

12. The method according to any one of the preceding claims, wherein, The method includes transmitting the status report if the user equipment does not receive a scheduling authorization from the base station within a predetermined time period.

13. The method according to claim 12 when dependent on claim 10 or 11, wherein, The status report is transmitted even if the amount of data is below the data threshold.

14. The method according to any one of the preceding claims, wherein, The method includes determining the first segment and the second segment based on timing information of at least one set of PDUs associated with the corresponding segment.

15. The method according to claim 14, wherein, The method includes: grouping two or more PDU sets with matching timing information into a single segment.

16. The method according to claim 15, wherein, The method includes: comparing timing information of at least one PDU set with a discard timer value of a first segment and a discard timer value of a second segment; associating the at least one PDU set with the first segment if the discard timer value of the first segment matches the timing information of the at least one PDU set; and adding information indicating the amount of data associated with the at least one PDU set to the first segment.

17. The method according to any one of claims 14 to 16, wherein, The method includes: generating a third segment of the logical channel group when the timing information of the at least one PDU set does not match the segment timer value of each segment in the first segment and the second segment; starting a timer for the third segment corresponding to the discard timer value; and adding information indicating the amount of data associated with the at least one PDU set to the third segment.

18. The method according to claim 16 or 17, wherein, When the timing information of at least one PDU set is substantially equal to the discard timer value, the timing information is matched with the discard timer value of the corresponding segment.

19. The method according to any one of the preceding claims, wherein, The status report provides the network with a critical indication of the drop timer value associated with at least one of the first and second segments.

20. The method according to any one of the preceding claims, wherein, The status report includes the discard timer value for at least one of the first and second segments.

21. The method according to any one of the preceding claims, wherein, The status report includes only the discard timer value for the new segment.

22. The method according to any one of the preceding claims, wherein, The status report includes information indicating the total amount of data associated with the first segment and the second segment.

23. A method for reporting the buffer status of data to be transmitted on a logical channel group in a communication network, the logical channel group being used to carry a plurality of Protocol Data Unit sets, i.e., PDU sets, associated with a first segment and a second segment of the logical channel group, wherein, Each segment in the first segment and the second segment is associated with at least one set of PDUs, the communication network includes user equipment and base stations, and the method at the base station includes: receiving a status report for reporting buffer status of the first segment and the second segment to the base station, the status report including information indicating the amount of data associated with the first segment and the second segment, wherein the status report is transmitted based on a discard timer value associated with at least one of the first segment and the second segment; and configuring a timer associated with at least one of the first segment and the second segment based on the information indicating the amount of data associated with the first segment and the second segment.

24. A method for reporting the buffer status of data to be transmitted on a logical channel group in a communication network, the logical channel group carrying a set of Protocol Data Units (PDUs) associated with multiple segments, each of the multiple segments being associated with a reporting threshold, wherein, The amount of data associated with at least one of the plurality of segments becomes reportable when a corresponding reporting threshold is reached, the communication network including user equipment and base stations, wherein the method at the user equipment includes: transmitting a status report for reporting the buffer status of at least one of the plurality of segments that has reached the reporting threshold based on a trigger threshold being reached, wherein the trigger threshold and the reporting threshold for the plurality of segments are configurable.

25. The method according to claim 24, wherein, The trigger threshold and the reporting threshold are configured by the communication network.

26. The method according to claim 24 or 25, wherein, The user equipment receives multiple configuration files for configuring the trigger threshold and the reporting threshold, and the communication network controls the user equipment to switch between the configuration files.

27. The method according to claim 24 or 25, wherein, The user equipment receives multiple configuration files for configuring the trigger threshold and the reporting threshold, and the user equipment switches between the multiple configuration files.

28. The method according to claim 27, wherein, One of the multiple configuration files is configured as the default configuration file by the communication network.

29. The method according to any one of claims 24 to 28, wherein, The trigger threshold is less than or equal to the reporting threshold.

30. The method according to claim 29, wherein, The transmission of the status report is based on multiple reporting thresholds, and the trigger threshold is less than or equal to each of the reporting thresholds.

31. The method according to any one of claims 24 to 28, wherein, The transmission of the status report is based on multiple reporting thresholds, wherein the reporting thresholds are less than or equal to the trigger threshold.

32. The method according to any one of claims 25 to 28, wherein, The transmission of the status report is based on multiple reporting thresholds, and the trigger threshold is between two of the reporting thresholds.

33. The method according to claim 32, wherein, The trigger threshold is the average of the two reporting thresholds.

34. The method according to any one of claims 24 to 33, wherein, The trigger threshold includes at least one of the following: a data threshold, which indicates that during uplink to the user equipment, for at least one logical channel in the logical channel group, data becomes available for the protocol stack layer of the communication network; a resource threshold, which indicates that during uplink to the user equipment, resources for transmitting data are allocated to at least one logical channel in the logical channel group, and the threshold number of padding bits is equal to or greater than the status report. A retry timer threshold for a retry timer started after a failed attempt to transmit a previous status report; a periodic timer threshold for a periodic timer configured to cause periodic transmission of status reports; a drop timer threshold for a drop timer associated with at least one of a first segment and a second segment; and a scheduling grant timer threshold for a timer configured to measure the time between sending a previous status report and receiving a scheduling grant from the base station.

35. A method for reporting the buffer status of data to be transmitted on a logical channel group in a communication network, the logical channel group carrying a set of Protocol Data Units (PDUs) associated with multiple segments, each of the multiple segments being associated with a reporting threshold, wherein... The amount of data associated with at least one of the plurality of segments becomes reportable when a corresponding reporting threshold is reached, the communication network including user equipment and base stations, wherein the method at the base station includes: receiving a status report for reporting the buffer status of at least one of the plurality of segments that has reached the reporting threshold, wherein the status report is transmitted based on reaching a trigger threshold, wherein the trigger threshold and the reporting threshold for the plurality of segments are configurable; and configuring a timer associated with the at least one segment based on the status report.

36. A method for reporting the buffer status of data to be transmitted on a logical channel group in a communication network, the logical channel group being used to carry multiple sets of Protocol Data Units (PDUs) associated with multiple segments, the communication network including user equipment and base stations, wherein, The method at the user equipment includes: transmitting a status report for reporting the buffer status of at least one segment based on the data volume of one of the plurality of segments reaching a trigger threshold, wherein the data volume has previously triggered a previous status report reporting non-delay critical data.

37. The method of claim 36, wherein, The discard timer value associated with previously reported data indicates that the previously reported data is delay-critical.

38. The method according to claim 37, wherein, The trigger condition is met if non-delay-critical data is placed in the transmission buffer before previously reported delay-critical data.

39. The method according to any one of claims 36 to 38, wherein, The trigger condition is met if the previously reported data has not been sent after the scheduled time period.

40. The method according to claim 39 when dependent on claim 38, wherein, The predetermined time period is configured to expire before the discard timer associated with the non-delayed critical data.

41. The method according to any one of claims 36 to 40, wherein, The status report is configured to indicate data that has been previously reported and is still awaiting transmission, as well as newly reported data.

42. The method according to claim 41, wherein, The status report is configured to include a method for distinguishing between previously reported data and newly reported data in each of the plurality of segments.

43. The method according to any one of claims 24 to 42, wherein, Each of the plurality of segments is associated with a reporting threshold, wherein the amount of data associated with at least one of the plurality of segments becomes reportable when the corresponding reporting threshold is reached.

44. A method for reporting the buffer status of data to be transmitted on a logical channel group in a communication network, the logical channel group being used to carry a set of Protocol Data Units (PDUs) associated with multiple segments, wherein, The method at the base station includes: receiving a status report for reporting the buffer status of at least one of the plurality of segments, wherein the status report is transmitted based on a data volume of the at least one of the plurality of segments reaching a trigger threshold, wherein the data volume has previously triggered a previous status report reporting non-time-critical data; and configuring a timer associated with the at least one segment based on the status report.

45. A method for reporting the buffer status of data to be transmitted on a logical channel group of a communication network, the logical channel group being used to carry a set of Protocol Data Units (PDUs) associated with multiple segments, the communication network including user equipment and base stations, wherein, The method at the user equipment includes: transmitting a status report for reporting the buffer status of the plurality of segments to the base station, the status report including information indicating the amount of data associated with the plurality of segments, wherein, in the case that a drop timer value associated with a first segment is critical and a drop timer value associated with a second segment is non-critical, the status report is configured such that the first segment and the second segment are arranged according to their respective positions in the transmission buffer.

46. ​​A communication network comprising: User equipment configured to perform the method according to any one of claims 1 to 22, 24 to 34, 36 to 43 and 45, and / or base station configured to perform the method according to claims 24, 35 and 44.

47. A computer program comprising instructions that, when executed by a user equipment, cause the user equipment to perform the method according to any one of claims 1 to 22, 24 to 34, 36 to 43 and 45, or, when executed by a base station, cause the base station to perform the instructions of the method according to claims 24, 35 and 44.

48. A computer-readable medium carrying a computer program according to claim 47.

Images