Buffer status reporting method in communication networks

Abstract

A method for reporting buffer status in a communication network. This method is for reporting the buffer status of data transmitted through a logical channel group (LCG) of a communication network. The communication network includes user equipment and base stations. The method in user equipment includes determining multiple sections to associate with multiple protocol data unit sets (PDU Sets) based on timing information of multiple PDU Sets, and transmitting a status report to the base station to report the buffer status of the multiple sections, wherein the status report includes, for at least one section, a buffer size value indicating the amount of data in at least one PDU Set associated with that at least one section, and a timer value for that at least one section.

Description

Technical Field

[0001] The present disclosure relates to a buffer status reporting method in a communication network (e.g., a mobile communication network). More specifically, the method relates to the transmission of a latency status report from a user equipment (UE) to a base station (gNB) of a communication network.

Background Art

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

[0003] Examples of such wireless multi-access communication systems include systems based on the 3rd Generation Partnership Project (3GPP™) specifications such as the 4th Generation (4G) Long Term Evolution (LTE) and (more recently) the 5th Generation (5G) New Radio (NR) systems, or systems based on the IEEE802.11 specifications (such as Wi-Fi). Among the requirements for 5G NR are service requirements related to extended reality (XR).

[0004] XR (i.e., Extended Reality) applications are defined in 3GPP document RP-2200285 as "various types of extended, virtual, and mixed environments in which human-to-machine and human-to-human communication takes place with the assistance of 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 a wearable device (e.g., a 3D helmet or augmented reality glasses) and an application server. The wearable device and the application server can be connected via a local network (e.g., Wi-Fi) or a cellular network (e.g., a 3GPP 5G cellular network, where the application server is connected to the network's 5G core network component).

[0006] Some XR applications, such as cloud gaming, involve the transfer of compressed video and audio data from the server to the UE, and positioning information from the UE to the server.

[0007] Some XR applications, such as virtual reality, involve the transfer of compressed video data, audio data, and various other information from a server to a wearable device.

[0008] Some XR applications, such as augmented reality, involve the transfer of compressed video data, audio data, and various other types of information between wearable devices and servers.

[0009] In this disclosure, information exchanged between a UE (e.g., a wearable device) and a 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 transferred between the UE (e.g., a wearable device) and the server using media transfer protocols such as RTP (Real Time Protocol, RFC3550), SRTP (Secured RTP, RFC3711), HTTP (Hyper Text Transfer Protocol, RFC2616-7540), or QUIC (RFC8999, 9000, 9001, and 9002).

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

[0012] According to the 3GPP standard, a set of protocol data units or packet data units (PDUs) (i.e., a "PDU Set") is required to forward application data packets. Therefore, application data consists of one or more application data packets. During the downlink, 3GPP PDUs are formatted by the PDU layer of the core network. Similarly, during the uplink, 3GPP PDUs are formatted by the PDU layer of the UE (e.g., a wearable device). According to the 3GPP standard, the delimiters of the PDU Set (e.g., start, end, length, etc.) are not provided by the application but are generated by the core network (each UE) through packet inspection of the media transfer protocol. Detailed procedures can be found in 3GPP document S2-2302696.

[0013] A PDU Set contains one or more PDUs that carry the payload of a single unit of information generated at the application level (e.g., a frame or video slice for an XRM service, as used in TR 26.926). In some implementations, all PDUs within a PDU Set are required by the application layer to use the corresponding unit of information. For example, a single PDU Set might contain data for a single image or frame from a video stream. In other implementations, even if some PDUs are missing, the application layer can still recover some or all of the unit of information.

[0014] The network used to transfer application data may experience perturbations and congestion. Therefore, at the receiving end (e.g., the PDU layer of the UE between downlinks and the user plane function (UPF) of the core network between uplinks), some PDUs in the PDU set may be missing or delayed.

[0015] Some video decoder implementations require that complete application data packets (e.g., a complete PDU set) be received in a timely manner in order to properly decode video. Other implementations may tolerate delayed arrival or partial delivery of data packets. For example, these implementations rely on forward error correction (FEC) or smearing techniques.

[0016] 3GPP standard document S2-2302696 defines a PDU Set QoS parameter called the PDU Set Delay Budget (PSDB). The PSDB defines the time budget allocated to the forwarding of PDU Sets across the entire 5G network. This QoS parameter, defined by the application, is used by the 5G network to evaluate whether PDU Sets (e.g., application data packets) are delivered on time.

[0017] In the same 3GPP document S2-2302696, another QoS parameter called PDU Set Integrated Handling Indication (PSIHI) is defined to characterize the decoder's tolerance to data loss or the reception of old (e.g., delayed) data. When the PSIHI parameter is set to "true", the decoder can only process (e.g., manage or process) complete application data packets that are received in time. When the PSIHI parameter is set to "false", the decoder can tolerate both incomplete and delayed application data packets.

[0018] Considering the situation in specific components of a 5G network, when a PDU Set is transmitted over the air interface, some information is available regarding the PDU's reception status and the elapsed time of the PDU Set. For example, when a PDU Set is transmitted wirelessly, a Radio Access Network (RAN) node (e.g., UE or next-generation node (gNB)) can detect that the PDU transmission has failed despite all retransmission and error correction mechanisms. In that case, if the PSIHI parameter is set to "true", the entire PDU Set becomes useless to the application. If one or more PDUs in this "useless" PDU Set are pending transmission over the air interface, the RAN node can consider discarding the remaining transmissions of the "useless" PDU, thereby achieving a saving of wireless network resources.

[0019] The gNB (i.e., base station) in a 5G network is responsible for scheduling uplink traffic. The gNB allocates radio resources to each UE based on one of the following mechanisms: * Dynamic request scheduling by each UE; * Semi-static scheduling by gNB, where gNB can issue periodic resource allocations to a single UE; and *Buffer status report (BSR) from each UE indicating the amount of data available for uplink transmission.

[0020] BSR operates on Logical Channel Groups (LCGs), which group together Logical Channels (LCHs) of multiple MACs. The BSR trigger conditions and format, as defined in 3GPP document TS38.321, are directed towards sending available data ready for uplink transmission for each LCG. Based on this knowledge, gNBs can perform resource scheduling. For example, a gNB might decide to prioritize the LCG with the most available data while preventing resource exhaustion in low-throughput LCGs.

[0021] Some XR data may have a PDSB (Pre-Delay Budget) that must not be exceeded because the data becomes outdated and unusable after the delay period has elapsed. In this situation, the scheduler needs to have knowledge of the remaining time for the XR data (e.g., remaining delay budget) when making scheduling decisions.

[0022] Given that the BSR operates on the LCG and multiple PDU sets can be multiplexed within a single logical channel, adding delay information to the BSR is not appropriate because the reported buffer data will potentially be associated with different delay periods (i.e., belonging to different PDU sets).

[0023] Therefore, there is a need to provide a method for configuring the communication network so that PDU transmission and latency are managed in a way that ensures no data loss by base stations while minimizing overhead within the network. [Overview of the project]

[0024] A part of this disclosure provides a method for configuring a RAN node (e.g., UE) of a communication network to report the buffer status of data (e.g., one or more data packets) transmitted over the network (e.g., to a gNB). The buffer status is transmitted by a status report configured (e.g., divided) into multiple sections, each section may be configured to associate multiple data packets having similar buffer statuses with the same section. The buffer status includes, for each section, an indication of the amount of data being transmitted and an indication of the remaining time until that section has elapsed. In this way, the method enables a receiving RAN node to predict when a set of data packets will elapse, thereby enabling the node to allocate network resources more efficiently while reducing the network transmission load.

[0025] A first aspect of this disclosure provides a method for reporting the buffer status of data (e.g., protocol data units (PDUs) and / or PDU sets) transmitted over a logical channel group (LCG) of a communication network including user equipment and a base station. The method in user equipment includes determining multiple sections for associating multiple protocol data units (e.g., one or more PDU sets) and / or multiple PDU sets based on timing information of multiple PDUs / PDU sets, and transmitting a status report to the base station for reporting the buffer status of the multiple sections. The status report includes, for at least one section, a buffer size value indicating the amount of data of at least one PDU (and / or PDU Set) associated with that at least one section, and a timer value for that at least one section.

[0026] According to a second aspect of the present disclosure, a method for reporting buffer status of data transmitted via a logical channel group (LCG) of a communication network including a user device and a base station is provided. The method at the base station includes identifying a plurality of PDUs, and / or a plurality of sections for associating a plurality of PDU Sets (e.g., one or more PDU Sets) based on timing information of the plurality of PDUs / PDU Sets, and receiving a status report for reporting buffer status of the plurality of sections to the base station. The status report includes, for at least one section, a buffer size value indicating the amount of data of at least one PDU (and / or PDU Set) associated with the at least one section, and a timer value of the at least one section, and based on the timer value, configures a timer associated with the at least one section.

[0027] As described above, known scheduling methods (such as BSR, etc.) allocate resources based on the amount of available data. Since such methods are not time-dependent, it means that important traffic may be delayed and the receiving node may not be able to receive the data within the required delivery time.

[0028] According to known methods of controlling a communication network, multiple buffer sizes are reported for a single LCG, along with a bit flag warning for situations with critical delays. In this known method, the delay value itself is not notified to the base station, so the base station has to interpret the bit flag warning information as an emergency. Therefore, the base station cannot predict the delayed arrival of data. Furthermore, since the status report is sent depending on the availability of resources, and the status report is easily removed from scheduling because higher-priority data is available, it cannot be guaranteed that the delay status arrives at the base station on time (even though there is a bit flag warning). Additionally, unless an additional reporting trigger is defined to send a status report when the delay becomes critical (but the data volume has not changed), the reporting mechanism is ineffective, thereby increasing the network overhead.

[0029] Another known method of controlling a communication network involves systematically providing both buffer size and delay status information for each data portion of an LCG. This represents a very large overhead and does not conform to best practices for the careful use of radio resources.

[0030] Aspects of the present disclosure provide a time-sensitive scheduling method so that important information (e.g., PDU) can be delivered on time. Furthermore, aspects of the present disclosure enable convenient scheduling of traffic with different delay requirements into one or more sections of a single channel (or multiple channels). The buffer size values and timer values for different sections can be sent in a status report (e.g., when new data is ready for transmission to the network), thereby reducing the overhead within the network (e.g., because the delay information for one section only needs to be sent once) and enabling early transmission of the delay information to the base station so as not to miss deadlines.

[0031] Upon receiving the status report of this disclosure, the base station can implement a time-remaining counter for each section. This allows the base station to closely monitor changes in both the available data and remaining time for each section. Thus, the base station can make favorable scheduling decisions based on complete knowledge of both legacy logical channel groups and time-sensitive logical channel groups, and the sections associated with them.

[0032] The following description outlines numerous optional features, which can be applied individually or in combination with any aspect of this disclosure.

[0033] Although this method is described with reference to UEs and base stations (for example, in a communication network), it will be understood that this method is applicable to any suitable component of a communication network that comprises transmitting means (e.g., transmitters) and / or receiving means (e.g., receivers).

[0034] A PDU Set may consist of at least one PDU (e.g., multiple PDUs). Timing information for the PDU Set. In some embodiments, two or more PDUs from the same PDU Set may be assigned to the same section.

[0035] A PDU Set (and / or the PDUs contained therein) may have associated timing information (e.g., measured in units of time, e.g., seconds). This timing information may include timing parameters or timer values ​​(e.g., discard timers) that indicate when a data packet will elapse or expire (e.g., PDU discard timer and / or PDU Set discard timer).

[0036] Multiple sections (for example, in an LCG) may define parts or portions of a status report that can associate (or assign) one or more PDU Sets (and / or PDUs). At least one, or each section, may be determined based on the timing information of at least one, or each of, of the multiple PDU Sets (and / or PDUs).

[0037] At least one, or each, section may consist of a corresponding timer value. The timer value may define the duration (or validity period) of the section (for example, the period until the section can be discarded).

[0038] A status report may be generated and / or sent in response to the determination of at least one of multiple sections. For example, a status report may be generated and sent in a short period of time (e.g., immediately after) after multiple sections (and / or at least one of multiple sections) have been determined. A status report may be sent after a predetermined period of time has elapsed, or immediately after the identification of at least one (and / or more, or each of) multiple sections.

[0039] Optionally, in situations where at least one section is associated with multiple PDU Sets, the buffer size value is configured to represent the data volume of all (i.e., each) associated PDU Sets. Thus, the buffer size value can define the sum of the data volumes of each PDU Set associated with the section. Advantageously, this means that the base station receives the relevant information corresponding to all associated PDU Sets (and their respective PDUs) within each section.

[0040] The method may include sending a second status report that does not include timer values. The second status report may be sent after the first status report. In embodiments, the second status report may be sent after a predetermined period and / or in response to a decision in at least one section of multiple sections (e.g., a new section). Furthermore, the second status report may be sent when additional data is received by the UE from the application layer of the protocol stack. For example, a new PDU / PDU Set (e.g., a new PDU in an existing PDU Set) may be newly associated with an existing section (e.g., a section containing at least one PDU / PDU Set with matching timer values). In this situation, the second status report may report a change in the remaining buffer size of the section, however, the timer status of the new PDU / PDU Set will match that of the section (i.e., reported in the first status report). Thus, timer values ​​can be advantageously omitted from the second report, thereby reducing the transmission burden to the network.

[0041] Methods for determining multiple sections may include generating a new section when an existing section expires (for example, when the timer value of the previous section has elapsed).

[0042] Optionally, if a PDU is the last PDU in a PDU Set, and / or if the PDU Set is discarded (e.g., by another layer of the protocol stack, such as the MAC layer), the PDU Set may be discarded from the section. The discarded section may be configured (i.e., reassigned) as a new section according to any of the relevant methods of this disclosure. For example, the discarded section may be configured as a new section in response to the UE having new data (e.g., a PDU and / or a PDU Set) to send to the base station.

[0043] This method may include sending a third status report after a first status report, and optionally after a second status report. The third status report may be sent at the end of a predetermined period corresponding to the duration of at least one of multiple sections. The third status report may include both a buffer size value and a timer value. For example, the third status report may be sent after an existing section has been discarded (e.g., due to the expiration of a timer). The remaining portion of the LCG can be reallocated to a new section. In this case, the third status report may include a buffer size value and a timer value corresponding to the new section. The base station can use the timer value to start a new counter for the associated section.

[0044] The data for transmission may consist of multiple PDUs and / or PDU Sets (for example, a transmission may consist of two or more PDU Sets, each containing at least one or more PDUs). Each PDU Set may be associated with a discard timer value (e.g., a PDU discard timer value and / or a PDU Set discard timer value). This method may include grouping two or more PDUs (or PDU Sets) with matching timing information into a single section.

[0045] Optionally, this method may include at least one of the following method steps: comparing the discard timer value of a PDU Set and / or PDU (i.e., a PDU / PDU Set discard timer value) with the timer value of at least one section of multiple sections; associating the PDU / PDU Set with that at least one section if the section timer value matches the discard timer value; and adding a size value indicating the amount of data associated with the PDU / PDU Set to the buffer size value of that at least one section.

[0046] Optionally, this method may include at least one of the following method steps: comparing a PDU / PDU Set discard timer value with the timer value of at least one section of multiple sections; generating a new section of the logical channel group if the discard timer value does not match the section timer value; starting a timer for the new section corresponding to the discard timer value; and adding a size value indicating the amount of data associated with the PDU / PDU Set to the buffer size value of the new section.

[0047] In one embodiment, if the discard timer value is substantially equal to the section timer value, the section timer value may be considered to conform to the discard timer value.

[0048] Optionally, this method comprises the following steps: comparing the PDU / PDU Set discard timer value with the timer value of at least one section of multiple sections; creating a new section of the logical channel group if the discard timer value does not match the section timer value; starting the timer for the new section corresponding to the discard timer value; and configuring the buffer size value of the new section to match the size value of the PDU / PDU Set.

[0049] In one embodiment, if a new section cannot be created, the PDU and / or PDU Set may be assigned to an existing section that has the closest buffer size value to the size value of the PDU and / or PDU Set.

[0050] Optionally, before comparing the discard timer value and the section timer value, this method may include determining the configuration of the PDUs within the PDU Set. Then, if the PDU is the first PDU in the PDU Set, the method may proceed by determining the discard timer.

[0051] This method may include sending a status report based on the network decoder receiving an indication that it is unable to decode data that has not been received within a predetermined period.

[0052] The transmission of a status report may be initiated depending on the determination of one or more of the following delayed status report trigger conditions: data becomes available at another layer of the protocol stack for at least one logical channel in a logical channel group; resources for sending a PDU / PDU Set are (currently) allocated at another layer of the protocol stack and the buffer size value of the current status report is at least the size of a previous status report (i.e., one previously sent); a retry timer that defines the period before an attempt is made to send a status report if a previous transmission failed expires; or a periodic timer that defines a predetermined period before a user device is configured to send a status report expires.

[0053] In an embodiment, a DSR trigger may be performed by continuously comparing the remaining time associated with at least one of several sections, or each of them, with a remaining time threshold configured by the gNB. In this method, a DSR may be sent only when some data reaches a critical level of remaining time.

[0054] This method may include the following steps: determining whether one or more new sections have been generated since the most recent status report trigger condition was identified; and generating at least one new section when data corresponding to different timer values ​​becomes available in the logical channels of the logical channel group.

[0055] Optionally, this method may include the following steps: receiving information indicating the buffer size and / or timer values ​​of a previously generated section; and updating the buffer size and / or timer values ​​of the new status report based on the received information.

[0056] Optionally, this method may include the following method steps: generating two or more individual section status reports from multiple sections; analyzing available radio resources for sending status reports; and determining, based on the available radio resources, the number of section status reports to merge into a combined (e.g., single) status report.

[0057] The status of sections that were not selected in previous status reports can be characterized as sections to be skipped.

[0058] Optionally, the method may include determining that at least one section status report cannot be transmitted based on available radio resources. The method may include selecting two or more sections based on at least one of the following criteria: the remaining time for each section (i.e., until the timer value has elapsed); the freshness status of each section (e.g., how recently the section was generated); the PDU Set Importance (PSI) value associated with the data for each section; and the PDU Set Integrated Importance Information (PSIHI) quality of service parameter associated with the data for each section.

[0059] In embodiments, the method may include selecting two or more sections according to the following method steps: firstly, selecting at least one section to be skipped; secondly, selecting at least one new section; thirdly, selecting at least one section with new data; and fourthly, selecting at least one of the remaining sections. By implementing this method, user equipment ensures that the base station always receives section delay information as early as possible. Thus, the base station can monitor the state of the logical channel group itself and determine the remaining time for each section. As a result, the base station can take predictive actions to ensure that delay information is never delayed.

[0060] Alternatively, the method may include selecting two or more sections according to the following method steps: firstly, determining at least one section with new data; and from these sections, selecting at least one section with critical remaining timer values ​​(e.g., timer values ​​that expire before other timers and / or within a very small period of other timer values ​​and / or within a defined (e.g., minimum) period); secondly, selecting at least one section to be skipped; thirdly, selecting at least one new section; fourthly, selecting at least one section with new data; and fifthly, selecting at least one of the remaining sections. By implementing this method, user equipment can ensure that the base station receives updates to the buffer size and delay timer of the most critical section as early as possible. This is particularly advantageous when large bursts arrive late on channels with critical delays.

[0061] As an alternative, this method may include selecting two or more sections according to the following method steps: firstly, determining one or more sections with new data; then, from the identified one or more sections, selecting at least one section that is the most critical with the highest remaining time to buffer size ratio; secondly, selecting at least one section to be skipped; thirdly, selecting at least one new section; fourthly, selecting at least one section with new data; and fifthly, selecting at least one of the remaining sections. By implementing this method, the user device ensures that sections with less time to send a known buffer size (e.g., the smallest delay budget) are prioritized.

[0062] This method may proceed to subsequent selections (i.e., those defined in the relevant preceding paragraphs) only if sufficient radio resources are available to accommodate further selection status reports.

[0063] For at least one of the above selection method steps, the user device may make a ruling between two or more eligible sections based on at least one of the following selection criteria: Logical channel priority: A section belonging to a logical channel group containing the logical channel with the highest priority may be selected (e.g., based on the quality of service protocol at the control layer of the protocol stack, e.g., application level); Remaining time: A section with the most critical remaining time may be selected (so that the base station can obtain delay information on time); Ratio of remaining time to buffer size (favoring sections with less time to transmit a known buffer size); PDU Set severity information (PSI) associated with each section's PDU Set (favoring the most important PDU Sets); and PDU Set integrated severity information (PSIHI) QoS parameter associated with each section's PDU Set (e.g., if PSIHI is set to false, it means that the application decoder can handle (e.g., manage or process) the reception of a partial PDU Set, so sections containing PDU Sets with PSIHI set to false can be skipped).

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

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

[0066] The timer values ​​for all available sections may be included in the status report. Alternatively, only the timer values ​​for new sections may be included in the status report (e.g., only the first status report generated after the creation of a new section). The timer values ​​for a particular section (e.g., a new section) may be included in the first status report after the section's creation and in subsequent N status reports, where N is an integer configured by the base station. The base station configures one of the three modes described above on the user equipment for each logical channel group. Therefore, each logical channel group may be managed according to one of the three modes, and the status report messages for each logical channel group may exist in several formats.

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

[0068] According to a second aspect, the method at a base station includes a method step of configuring at least one timer associated with at least one section based on a timer value. This method step may include starting at least one timer (or counter) associated with that at least one section, depending on the reception of a status report. The length (or duration) of the timer may be determined based on a timer value. The base station may start different timers for each section, as determined by the status report. Once the timer value has elapsed, the base station may discard the timer. After at least one timer has elapsed, the base station does not intend to receive data corresponding to that at least one section, thereby allowing the base station to allocate network resources more efficiently.

[0069] A third aspect of this disclosure provides a communication network including network elements (e.g., base stations or UEs) as described in claim 32 of the appended claims.

[0070] A fourth aspect of the present disclosure provides a user device (embodied, for example, in a transceiver of a communication network) configured to perform any one of the methods described in the preceding paragraph (for example, as defined in any one of claims 1 to 31).

[0071] The transceiver may be configured for use in a communication network (e.g., a wireless communication network) that includes transmitting means (e.g., a first transceiver). (For example, a second transceiver in the communication network may be defined.) The transceiver may be configured to receive PDU Sets from the transmitting means. The transceiver may include receiving means (e.g., a receiver) for receiving status reports, and / or transmitting means (e.g., a transmitter) for sending status reports.

[0072] Any feature of the first or second embodiment may be embodied in any suitable component of the communication network (e.g., a transmitter and / or receiver). For example, the transmitting and receiving means may be located in different locations within the communication network (e.g., to define each transmitting and receiving network node), or they may be located within a single element of the network (e.g., to define a single component of the network such as a transceiver, such as a user device or base station).

[0073] A fifth aspect of this disclosure provides a computer program as described in claim 33 of the appended claims.

[0074] A sixth aspect of this disclosure provides a computer-readable medium as described in claim 34 of the appended claims.

[0075] A PDU Set may contain one or more PDUs. At least one, or each PDU, may be configured to carry a payload of a single unit of information generated at the application level (e.g., a frame or video slice for an XRM service, as used in TR 26.926). Each PDU Set may be characterized by identification information (e.g., defining the parameters of the PDU Set). For example, the identification information may define the start, end, 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 does not have knowledge of the identification information of the PDU Set. In embodiments, the PDU identification information is unknown at all protocol layers (e.g., including that layer).

[0076] This disclosure relates to communication networks for applications related to augmented reality (XR). Such communication networks may include the 3rd Generation Partnership Protocol (3GPP) and 5th Generation (5G) New Radio (NR).

[0077] XR applications can be defined as one or more types of augmented, virtual, and hybrid environments in which human-to-machine and human-to-human communication takes place with the assistance of handheld and wearable end-user devices (for example, in 3GPP document RP-2200285). Several use cases are defined in 3GPP document TR-26.928.

[0078] Information exchanged between a UE (e.g., a wearable device) and a server can be called application data. For example, application data may include one or more images, video data, audio data, location information, and various other types of information.

[0079] Application data (e.g., video, audio, or location data) can be transferred between the UE (e.g., a wearable device) and the server using media transfer protocols including RTP (Real Time Protocol, RFC3550), SRTP (Secured RTP, RFC3711), HTTP (Hyper Text Transfer Protocol, RFC2616-7540), or QUIC (RFC8999, 9000, 9001, and 9002). Video encoding and decoding can be performed according to various formats, including MPEG2, H.264, H.265, HEVC, etc.

[0080] Any feature of one aspect of the present disclosure may be applied to other aspects of the present disclosure in any suitable combination. In particular, aspects of methods may be applied to aspects of apparatus / devices / units, and vice versa.

[0081] Furthermore, functions implemented in hardware may be implemented in software, and vice versa. Any references to software and hardware functions in this specification should be interpreted accordingly. For example, according to another aspect of this disclosure, a computer program is provided which, when executed by one or more processing units, comprises instructions causing the one or more processing units to perform any of the methods or examples described above, and a computer-readable storage medium for carrying the computer program. [Brief explanation of the drawing]

[0082] Different aspects of this disclosure will be described, by reference only to the following drawings: [Figure 1] This is a schematic diagram showing a first exemplary wireless communication system in which the Disclosure may be implemented according to one or more embodiments thereof. [Figure 2] This is a schematic diagram illustrating an example configuration of a UE in which the Disclosure may be implemented according to one or more embodiments of the Disclosure. [Figure 3]This is a schematic diagram showing an example of a base station configuration in which the Disclosure may be implemented according to one or more embodiments of the Disclosure. [Figure 4] Figure 1 is a schematic diagram showing the data plane protocol stack of a 5G NR system. [Figure 5] Figure 1 is a flowchart showing the process performed at the UE PDCP layer of the wireless communication system. [Figure 6] Figure 1 is a flowchart showing how the process is executed at the MAC layer of the UE of the wireless communication system. [Figure 7] This flowchart shows how the MAC layer of the UE of the wireless communication system in Figure 1 is executed when a Delayed Status Report (DSR) is triggered. [Figure 8] This flowchart shows how the gNB of the wireless communication system in Figure 1 performs actions when a DSR is received. [Figure 9a] This is a schematic diagram showing the short DSR format and the short truncated DSR format. [Figure 9b] This is a schematic diagram showing the Extended Short DSR format and the Extended Short Truncated DSR format. [Figure 10] This is a schematic diagram illustrating exemplary message formats, including the long DSR format, the long truncated DSR format, and the preemptive DSR format. [Figure 11] This schematic diagram shows exemplary message formats, including the Extended Long DSR format, the Extended Long Truncated DSR format, and the Extended Preemptive DSR format. [Modes for carrying out the invention]

[0083] Figure 1 shows an exemplary wireless communication system 100, a mobile wireless communication system such as a fifth-generation (5G) New Radio (NR) system that supports augmented reality services (XR). While the following description will focus on embodiments and examples of embodiments of the disclosure in relation to a 5G NR system, it should be understood that the disclosure is not intended to be limited to a 5G NR system and may be used in any wireless communication system that supports XR or similar services.

[0084] System 100 includes user devices (UEs) 101, 151, which may be augmented reality wearables such as virtual reality helmets or glasses, and which are serviced by base stations 110 to communicate with core networks such as the 5G core network 102. UEs can be any wireless devices, such as wireless communication devices, equipment, terminals, IoT devices, machine-type communication (MTC) devices, device-to-device (D2D) terminals, and user devices (e.g., smartphones, laptops, mobile phones, tablets, cameras, game consoles, wearable devices), that are capable of wirelessly communicating with one or more core networks via one or more radio access networks. Base station 110 is a network node that provides UEs with access points to the core networks and is part of a radio access network (RAN) consisting of base stations 110 and 111. In NR, base stations are called next-generation node B (gNB), the RAN is next-generation (NG)RAN, and the core network is called 5GC. Hereafter, the terms RAN node, base station, and gNB will be used interchangeably. Base stations 110 and 111 are interconnected by Xn interfaces (e.g., those specified in 3GPP document TS38.423) implemented on wired or wireless links 130. Each base station is connected to the core network 102 by NG interfaces (e.g., those specified in 3GPP document TS38.413) implemented on wired or wireless links 140 and 141.

[0085] Each of these base stations controls 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 frequency used by that cell to transmit data. A cell can be uniquely identified by a UE from identification information broadcast across its geographical area. Each base station 110, 111 can serve multiple UEs 101, 151. When a UE establishes 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 where the UE is camped is called the serving cell. The interface between the gNB and the UE is the Uu interface, which uses the Service Data Adaptation Protocol (SDAP), Packet Data Convergence Protocol (PDCP), Radio Link Control (RLC), Medium Access Control (MAC), and Physical (PHY) protocol sublayers in the user plane, and the Radio Resource Control (RRC), PDCP, RLC, MAC, and PHY protocol sublayers in the control plane.

[0086] UE101 is assumed to be receiving and / or sending XR data for one or more multicast XR sessions generated and / or addressed to the XR application server 103. XR data is provided to base station 111 (which is the base station controlling cell 121 to which UE 101 is attached) via core network 102 (e.g., via data network 160 and user plane function 161) and via transport bearer (also known as GTP-U tunnel) 106 on link 141. The XR data is then transmitted by base station 111 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 enable higher-layer data connectivity between the UE and gNB. In 5G NR, several types of radio bearers are defined: a signaling radio bearer (SRB) for the control plane; a data radio bearer (DRB) that enables point-to-point communication (e.g., unicast) with a single UE in the user plane; and a multicast radio bearer (MRB) that enables point-to-point and point-to-multipoint communication (e.g., multicast / broadcast) with multiple UEs, also in the user plane.

[0087] Figure 2 is a block diagram of a UE device 205, such as UE101 or UE151 in Figure 1, in which the Disclosure may be implemented according to one or more embodiments of the Disclosure. The UE includes components for transmitting and receiving communications, and includes, for example, at least one of a UE communications manager 220, an I / O controller 255, a transceiver 235, an antenna set 245, a storage device (such as memory) 225, and a processor (CPU: central processing unit) 215. All of these elements can communicate with one another.

[0088] Memory 225 includes Random Access Memory (RAM), Read Only Memory (ROM), or a combination of both. Alternatively or additionally, memory 225 may include mass storage devices such as disks or Solid-State Drives (SSDs). Basic Input Output System (BIOS) instructions may be stored within memory 225.

[0089] The processor 215 is configured to execute machine-readable instructions. The execution of these machine-readable instructions allows the UE to perform various functions. These functions may involve transmission and / or interaction with peripherals, such as a keyboard, screen, mouse, etc. (not shown in Figure 2). The processor may run an operating system such as iOS, Windows, or Android. The processor 215 may be a single processor, or it may comprise two or more processors that perform the processing necessary for the operation of the UE 205.

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

[0091] The I / O controller 255 may interact with all or part of, for example, an image capture device, an image rendering device, an audio capture device, an audio rendering device, or a sensor device capable of determining its usage location.

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

[0093] The wireless communication uses an antenna set 245 adapted to the spectrum of the frequency-converted signal output from the baseband modem. The antenna set 245 may be limited to one antenna, but preferably includes multiple antennas to provide beamforming capabilities.

[0094] The UE communication manager 220 controls the establishment of communication between the UE and the radio access network (RAN). It may also be configured to control the control and release of the UE from the RAN. The UE periodically receives instructions from a base station (such as a gNB) regarding available slots for communication between the UE and the base station. Thus, the UE can determine when and on what frequency it should expect to receive incoming data (e.g., from a gNB). Furthermore, the UE can determine when and on what frequency it should send out data. The UE can decide whether to send / receive data, regardless of whether the data belongs to the control plane or the data plane. In one exemplary implementation, the UE communication manager 220 implements the Uu interface.

[0095] Figure 3 shows a block diagram of a base station device 305 in which embodiments of the present disclosure may be implemented, such as gNB110 and 111 in Figure 1. The base station device 305 includes components for transmitting and receiving communications (e.g., to and from the UE). For example, the base station includes at least one of a base station communications manager 320, a core network communications manager 355, a transceiver 335, a set of antennas 345, memory 325, a processor (such as a CPU) 315, and an inter-station communications manager 365. All these elements can communicate with each other.

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

[0097] The core network communications manager 355 manages communications between base stations and the core network. To support these communications, it may provide standardized NG interfaces, such as those defined in 3GPP standards.

[0098] The transceiver 335 is configured to provide bidirectional wireless communication with other wireless devices. These devices may be UEs or other base stations. The transceiver 335 provides the modem and frequency shifter necessary to connect to multiple UEs simultaneously using different frequency carriers in time division duplexing (TDD) or frequency division duplexing (FDD). The transceiver 335 may include a PDCP transmitter and a PDCP receiver. The PDCP transmitter and PDCP receiver may be implemented by the processor 315. The PDCP transmitter and PDCP receiver may be software-only functions implemented by the processor 315. The transceiver 335 is connected to an antenna set 345, which may be limited to one antenna, but preferably includes multiple antennas to provide beamforming capabilities.

[0099] Memory 325 includes RAM, ROM, or a combination of both. Alternatively or additionally, memory 225 may consist of mass storage devices such as disks or SSDs. BIOS instructions may be stored within memory 325 to support the operating system.

[0100] The inter-station communication manager 365 manages communication with other base stations. To support these communications, the inter-station communication manager 365 may provide a standardized Xn interface (such as one defined in the 3GPP standard).

[0101] Figure 4 is a block schematic diagram showing 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 through data network 160 at the PDU layer 402 level. The PDU layer corresponds to PDUs carried between the UE and the data network (DN) via PDU sessions. If the PDU session type is IPv4, IPv6, or IPv4v6, the PDU corresponds to IPv4 packets, IPv6 packets, or both. If the PDU session type is Ethernet, the PDU corresponds to Ethernet frames; etc. At the start of a PDU session (i.e., when the PDU is established), the core network provides session QoS parameters to the UPF, gNB, and UE. PDU session QoS parameters include the XR PDU SetQoS parameter (S2-2302696): A. PDUSet Delay Budget (PDSB); B.PDU Set Error Rate (PSER); and C. PDU Set Integrated Handling Indication (PSIHI). This was previously known as the PDU Set Integration Indication.

[0102] In the explanation related to Figure 4, unless otherwise specified, PDU refers to a packet processed (e.g., managed or processed) by PDU layer 402. Other types of PDUs are processed by other layers. Therefore, PDUs belonging to one of the other layers (i.e., layers other than PDU layer 402) are referred to herein with a prefix corresponding to the respective layer name, for example, PDCP PDU or MAC PDU.

[0103] When a PDU arrives at the UPF's PDU layer 402, the UPF performs an inspection of the application packet to determine the boundaries of the PDU Set. For example, 3GPP document S2-2302696 provides an example of how to identify a PDU Set when inspecting the RTP / SRTP header, RTP header extensions, H.264 RTP payload, H.265 RTP payload, and H.266 RTP payload.

[0104] PDU Set identification information, as described in 3GPP document S2-2303842, is determined by UPF and sent to NG-RAN in the GTP-U header. PDU Set identification information includes: A. PDU Set Sequence Number; Display of the last PDU in B.PDU Set; PDU sequence number within C.PDU Set; D.PDU Set size; and E. PDU Set Importance: Identifying the relative importance of a PDU Set compared to other PDU Sets within the QoS flow.

[0105] During the uplink, the application resides on the UE. The UE obtains PDU session QoS parameters from the core network when a PDU session is established (for example, the PDU session establishment procedure is defined in section 4.3.2 of TS23.502). When the PDU generated by application 403 arrives at the UE's PDU layer 402, the UE performs an inspection of the application packet (similar to the procedure for UPF described above) to determine the boundaries of the PDU set.

[0106] Between both the downlink and uplink, application 103 sends and receives data to and from NG-RAN via a GPRs tunnel (e.g., GTP-U layer 404 as defined in TS29.281).

[0107] During the downlink, the UPF detects PDU Set identification information and retrieves a set of mapping rules (e.g., filtering rules) from the core network. The filtering rules define how each PDU Set is mapped to a QoS flow. Its, or each, QoS flow is identified by an identifier, and the GTP-U PDU is marked according to the determined QoS flow identifier. In the gNB, relay layer 406 extracts the PDU Set identification information and QoS flow identifier from the GTP-U PDU and maps them to 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 may be mapped to different QoS flows. Then, according to 3GPP document TR-38.835, in the first alternative configuration, each SDAP QoS flow can be mapped to a different PDCP data radio bearer (DRB). According to the second alternative configuration, all SDAP QoS flows from the same XR session can be mapped to a PDCP DRB (e.g., a single PDCP DRB).

[0108] During the uplink, the UE discovers PDU Set identification information at PDU Layer 402 and retrieves a set of mapping rules (e.g., filtering rules) from the core network. The filtering rules define how each PDU Set is mapped to a QoS flow. The UE maps the XR PDUs to the relevant SDAP QoS flows according to the filtering rules. Similar to the downlink, multiple PDU Sets can be mapped to the same or different QoS flows within an XR session (e.g., a single XR session) during the uplink.

[0109] During the downlink, the application layer 103 generates at least one application flow, e.g., one or more video flows and one or more audio flows, for at least one UE (e.g., a single UE). Then, in the PDU layer 402, the application flows are placed into PDU Sets. Each application flow is divided into multiple PDU Sets of the same or different types. Then, within the GTP-U layer 404, each PDU Set type is mapped to a QoS flow, and multiple application flows can be multiplexed into a QoS flow (e.g., a single QoS flow). Alternatively, each application flow may be mapped to a different QoS flow. Further alternatively, an application flow can be divided into multiple QoS flows. Then, the SDAP layer 407 maps the QoS flows to DRBs, and each DRB is handled (e.g., managed or processed) by a dedicated PDCP entity. Similar to QoS flows, multiple application flows can be multiplexed into a single DRB. Alternatively, each application flow may be mapped to a different DRB. Further alternatively, an application flow (e.g., a single application flow) can be divided into multiple DRBs.

[0110] During the uplink, the application layer 403 generates at least one application flow, such as one or more video flows, one or more audio flows, and one or more sensing flows, toward the application server 103. Then, in the PDU layer 402, the application flows are placed into PDU Sets. At least one, or each, application flow is divided into multiple PDU Sets of the same or different types, and each PDU Set type is mapped to a QoS flow, so that multiple application flows can be multiplexed into a single QoS flow, or each application flow can be mapped to a different QoS. It is also possible to divide an application flow into multiple QoS flows. The SDAP layer 407 then maps the QoS flows to DRBs. At least one, or each, radio bearer is handled (e.g., managed or processed) by a dedicated PDCP entity. Similar to QoS flows, multiple application flows can be multiplexed into a single DRB (e.g., a single DRB), or each application flow can be mapped to a separate DRB. Alternatively, an application flow (e.g., a single application flow) can be divided into multiple DRBs.

[0111] 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).

[0112] According to known network configurations, for uplink traffic scheduling, the MAC layer 410 of the gNB is configured to allocate radio resources to UEs (e.g., at least one, or each UE) based on at least one of the following mechanisms: A. Dynamic request scheduling issued by each UE (i.e., UEs dynamically issue requests for radio resources); B. Semi-static scheduling by gNB (i.e., gNB is configured to issue periodic resource allocations to at least one UE); and C. Buffer status reporting by at least one UE (i.e., the UE generates a Buffer Status Report (BSR) indicating the amount of data available for uplink transmission).

[0113] The BSR mechanism (C) reduces the need for periodic transmissions between the gNB and UE (as required by mechanism B, for example) and also reduces the computational load on the UE (unlike mechanism A, for example), thus potentially reducing network overhead compared to the other mechanisms (A and B).

[0114] The buffer status reporting mechanism operates based on logical channel groups (LCGs), meaning that the buffer status of a group of logical channels (LCHs) is reported collectively. An LCG (e.g., a single LCG) can map to multiple MAC logical channels (LCHs), and its BSR trigger conditions and format are defined in 3GPP document TS38.321. A gNB receives the BSR report and uses this knowledge to perform resource scheduling. For example, a gNB might decide to prioritize the LCG with the most available data while preventing resource exhaustion in low-throughput LCGs.

[0115] In certain situations, some XR data may have a PDU Set delay budget (PDSB), which should not be exceeded because it becomes unusable after the delay period has elapsed (e.g., it becomes useless to the decoder). For example, when a PDU Set is transmitted over a 5G network, some information may be available regarding the PDU's reception status and the elapsed time of the PDSB. The gNB can detect whether the PDU transmission failed (e.g., despite attempted retransmissions and error correction mechanisms). If the decoder can only process (e.g., manage or process) complete application data packets that have been received in time (e.g., if PSIHI is "true"), then the remaining PDUs in the PDU Set after the delay period has elapsed (i.e., PDUs still pending transmission) are useless to the decoder.

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

[0117] This disclosure envisions a method for allocating radio resources within a communication network (e.g., a mobile communication network) that overcomes the problems of the BSR mechanism. Specifically, the allocation of radio resources is performed by the MAC layer of the communication network. The method includes a delay status reporting mechanism configured to indicate the amount of data to be transmitted and the remaining time to perform the transmission (e.g., during an uplink to a gNB).

[0118] Advantageously, the delay status reporting mechanism allows the scheduler to have knowledge of the remaining time for XR data (e.g., remaining PDSB) when making scheduling decisions, enabling it to identify which PDU sets should be abandoned (e.g., not sent by the UE) to conserve network resources.

[0119] It should be noted that the buffer status reporting mechanism and the delay status reporting mechanism are not mutually exclusive and can be used in combination. For example, the BSR mechanism may be used in legacy LCGs (e.g., for applications where the decoder can handle application data packets that are not received on time), and the delay status reporting mechanism may be used in delay-sensitive LCGs.

[0120] Here, the application and benefits of the delayed status reporting mechanism are explained with reference to Figures 1 and 4. During the downlink, PDU Set identification information calculated by the core network UPF161 is inserted into the GTP-U header 404 (e.g., GPRS Tunnelling Protocol-User Plane as described in TS29.281). GTP-U is the protocol used by UPF to carry data from the core network 102 (including UPF as shown in Figure 1) to gNBs 110, 111. When the PDUs (sent from the core network via the GTP-U tunnel) arrive at gNBs 110, 111, the GTP-U header 404 is removed. This means that the PDU Set identification information is not sent to UEs 101, 151 via the SDAP layer 407 (e.g., the Service Data Adaptation layer as described in TS37.324). Thus, the PDU Set identification information is never provided "in-band" during the downlink from gNB to UE. As a result, UE101 and 151 (i.e., the receiving end during the downlink) cannot access the PDU Set identification information.

[0121] During the uplink, as shown in Figure 4, the PDU Set identifier (calculated, for example, by the UE's PDU layer 402) is not inserted into any header. Therefore, the PDU Set identifier is not provided "in-band" during the uplink from UEs 101 and 151. Consequently, gNBs 110 and 111 (i.e., the receiving end during the uplink) cannot access the PDU Set identifier.

[0122] In summary, at all protocol layers (including PDCP layer 401), whether downlink or uplink, the receiving entity does not have knowledge of the PDU Set identifier. On the transmitting side, all layers below SDAP layer 407 do not have access to the "in-band" PDU Set identifier. However, internal mechanisms can be used to associate "out-band" PDU Set delimiter information with each transmitted PDU. One example of such an internal mechanism is that PDU context information can be used to determine the PDU Set delimiter information.

[0123] According to the exemplary method during the downlink, at the gNB (i.e., the transmitting side), the GTP-U receiving entity 404 can associate "outband" PDU Set delimiter information with each PDU and pass that delimiter information to the PDCP transmitting entity 401. This allows the PDU Set delimiter information to be passed from the gNB to the UE via the PDCP layer 401. Then, during the uplink, the PDU layer 402 (of the UE) associates "outband" PDU Set delimiter information with each PDU and passes that information to the UE PDCP transmitting entity 401 (e.g., ready to transmit to the gNB).

[0124] Further details of the delayed status reporting mechanism will be explained with reference to Figures 5, 6, 7, 8, 9, 10, and 11.

[0125] The delayed status reporting mechanism operates on an LCG subdivided into multiple “sections” that define parts of the LCG. The section formation process by the UE's MAC layer 410 is described below with reference to Figure 6. An exemplary method for information sharing between the UE's PDCP layer 401 and the UE's MAC layer 410 is shown in Figure 5. Potential trigger conditions for the delayed status reporting mechanism are described with reference to Figure 7. How the delayed status reporting mechanism is processed in gNB is described with reference to Figure 8. Various delayed status reporting formats are described with reference to Figures 9, 10, and 11.

[0126] Figure 5 is a flowchart showing the steps of Method 500 performed at the UE's PDCP layer 401 to transmit uplink traffic to MAC layer 410 through 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 Method as defined below: In the first method step 501, UE101, 151 receive the PDCP DRB configuration from gNB111. The PDCP DRB configuration includes at least one discard timer (e.g., the "PDU Set discard timer" value and / or the "PDU discard timer" value).

[0127] In the second method step 502, UE101 and 151 receive the first PDU of the PDU Set from a higher layer of the UE's protocol stack (e.g., the SDAP layer 407 shown in Figure 4).

[0128] In the third method step 503, UE101, 151 transmit both the PDU and the associated PDCP DRB configuration (e.g., the "PDU discard timer" value and / or the "PDU Set discard timer" value) to the MAC logical channel (i.e., through the RLC layer 408 as shown in Figure 4).

[0129] The fourth method step 504 includes UE101, 151 waiting for the reception of one or more subsequent PDUs of the same PDU Set. Each time a new PDU is received, the UE sends the new PDU to the MAC logical channel (i.e., through RLC layer 408).

[0130] In step 505 of the method, UE101, 151 send a notification to the MAC logical channel (i.e., through RLC layer 408) if at least one of the following criteria is met: A. That the last PDU of the PDU has been received; and B. The PDU Set was discarded (for example, because the discard timer expired).

[0131] Once all PDUs in the PDU Set have been received (i.e., when the reception of the PDU Set is complete), the notification indicates the end of the PDU Set. If the discard timer has elapsed, the notification is configured to indicate that the PDU Set should be discarded. Thus, the sending and content of the notification are configured to depend on the above criteria being met. Finally, the method continues by UE101, 151 returning to method step 502 for the reception of a new PDU Set.

[0132] Some PDU sets contain only one PDU; for example, pose information can be carried in a single PDU, which leads to the creation of a single section. It will be understood that pose information may include position and orientation information related to a three-dimensional object. In the context of XR applications, pose information can be used, for example, to allow a user to manipulate a virtual object or to avoid moving to a virtual object based on its perceived position and orientation within the environment.

[0133] Figure 6 is a flowchart showing the steps of Method 600 performed at MAC layer 410 of the UE. Method 600 controls the reception of data for a single Logical Channel Group (LCG). For each LCG, MAC layer 410 of the UE performs at least one instance of the following method: In the first method step 601, the UE receives a configuration from the gNB111. The configuration includes information indicating that logical channels (LCHs) are to be grouped into logical channel groups (LCGs) at the MAC layer (i.e., an LCG (or MAC LCG) configuration).

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

[0135] According to the embodiment, if the acquired timer value is equal to the remaining timer value, the acquired timer value is consistent with the remaining timer value.

[0136] Alternatively, if the acquired discard timer value falls within the interval of the remaining timer value, the acquired timer value may be configured to conform to the remaining timer value. Thus, the interval value can define an absolute difference (e.g., ±10ms) or a relative difference (e.g., ±10%) between the acquired (i.e., PDU Set) timer value and the remaining (i.e., section) timer value. Therefore, the timer values ​​do not need to be equal to each other in order to conform according to the methods disclosed herein. In such a situation (i.e., the acquired timer value is approximately equal to the remaining timer value (e.g., slightly larger or smaller)), the remaining timer value may be configured according to at least one of the following criteria: A. The remaining timer will remain unchanged; B. The remaining timer is set to the average value between the acquired timer value and the remaining timer value; and C. The remaining timer is set to the minimum or maximum value of the timer.

[0137] If the acquired discard timer value does not match any remaining timer values ​​for any existing section, the following method steps are performed in the UE: A. Create a new section in LCG; B. Start the remaining timer for the new section, and set the new timer to the acquired discard timer value; and C. Associating the new PDU with the new section (for example, the amount of data buffered for the PDU Set is added to the buffer size of the new section).

[0138] According to one embodiment, if a new section cannot be created (for example, because there are no section identifiers in the UE), the new PDU Set is assigned to the section with the remaining timer value closest to the acquired timer value.

[0139] If the received PDU is a subsequent PDU in a PDU Set (as shown in step 504 of the method in Figure 5, for example), in step 603 the UE adds the PDU size to the buffer size of the corresponding section.

[0140] If the received PDU is the last PDU in a PDU Set (as described in step 505 of the method in Figure 5, for example), or if the PDU Set has been discarded by another layer, the UE detaches the PDU Set from its existing section in step 604 of the method. If there are no other PDU Sets associated with that existing section, the section becomes unassigned (for example, remains empty or vacant).

[0141] Throughout this disclosure, the term “section” defines a part or portion of an LCG (i.e., a logical channel group). Alternatively, without departing the scope of this disclosure, a section may be referred to as a “bucket,” “PDU set,” “burst,” “chunk,” or “part.”

[0142] Figure 7 is a flowchart showing how the method 700 is executed at MAC layer 410 of the UE when the delayed status reporting mechanism is triggered (as shown in Figure 4).

[0143] The first method step 701 involves initiating the delayed status reporting mechanism, relying on the UE to identify one or more delayed status reporting trigger conditions. The delayed status reporting trigger conditions can be summarized as follows: A. During the uplink, data must be available to the MAC entity for at least one LCH of the LCG; B. During the uplink, resources are allocated to transmit the MAC PDU, and the number of padding bits is greater than or equal to the size of the Delay Status Report (DSR); C. The first (retry) timer (e.g., retxDSR-Timer) expires so that when sending a delayed status report fails, the timer is set to attempt sending the delayed status report at another time; A second (periodic) timer (e.g., periodicDSR-Timer) expires so that the UE can be configured to use this timer to send periodic delay status reports; and The remaining time value after at least one section of the E.LCG has reached at least one threshold.

[0144] Similar trigger conditions can be associated with buffer status reporting mechanisms (for example, as defined in section 5.4.5 of 3GPP document TS38.321).

[0145] The second method step 702 includes the UE checking (e.g., identifying) whether one or more new sections of the LCG have been created since the last DSR trigger was identified (e.g., during method step 605 shown in Figure 6). If data corresponding to different delay budgets has become available in an LCH belonging to the LCG (e.g., a single LCH), then at least one new section is created. The UE then generates a delay and buffer report that defines the delay information and buffer size corresponding to the new section. The delay information and buffer size of the new section can be characterized by section parameters, which include a section identifier, buffer size, and delay information value (e.g., remaining time).

[0146] The third method step 703 involves the UE receiving delay information and buffer sizes for previously created (and skipped) sections. The UE uses the delay information and buffer sizes to update the corresponding reports for existing (e.g., skipped) sections in the LCG.

[0147] In the fourth method step 704, the UE analyzes the available radio resources for transmitting a Delay Status Report (DSR), and then calculates how many section reports can be concatenated to the available radio resources.

[0148] Generally, a DSR defines a message from the UE to the gNB, which outlines the amount of data available for uplink transmission and its associated delay budget. In an exemplary configuration, the purpose of a DSR is to assist or guide the scheduling of resource allocations to enable uplink data transfer to the gNB. As will be described below with reference to Figures 9a, 9b, 10, and 11, DSRs can be configured in various formats.

[0149] If the available radio resources are greater than or equal to the size of the short DSR format but less than the minimum size of the long DSR format, only one section is available to report using the short DSR format. If the available resources are greater than or equal to the minimum size of the long DSR format, at least two sections from the same LCG can be reported using the long DSR format. 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.

[0150] In embodiments, if the available radio resources are 2 bytes or more but less than 6 bytes, there is only enough space to report one section using the short DSR format. If the available resources are 6 bytes or more, at least two sections from the same LCG can be reported using the long DSR format. If the available radio resources are 7 bytes or more, at least two sections from two different LCGs can be reported using the long DSR format.

[0151] If the UE reports only one section of the LCG, the DSR format is called the short DSR format. If the UE must select one section from multiple sections (or one section from multiple LCGs), the DSR message is called the short truncated DSR format (see Figure 9a). Therefore, both the short DSR format and the short truncated DSR format are functionally the same type of DSR message, differing only in name.

[0152] When available radio resources fit all reportable LCGs and their sections, the DSR message in Figure 10 is called the long DSR format. When the UE must select one section from multiple sections (or one section from multiple LCGs), the DSR message in Figure 10 is called the long truncated DSR format. Therefore, both the long DSR format and the long truncated DSR format are functionally the same type of DSR message, differing only in name.

[0153] The DSR mechanism can be used for communication between IAB nodes in the context of integrated access and backhaul (IAB). For example, an IAB mobile termination (IAB-MT) may provide its parent IAB distributed unit (IAB-parent-DU) or IAB donor-DU with information about the amount of data that can be expected to arrive at the IAB-MT from its child nodes and / or UEs (connected to the IAB-MT), along with their associated delay budget.

[0154] In embodiments, when the maximum number of LCGs is large, the DSR format is called the extended short DSR format (as shown in Figure 9b). When only one section is selected from multiple sections (or one section from multiple LCGs), the DSR message is called the extended short truncated DSR format (see Figure 9b). When available radio resources fit all reportable LCGs and their sections, the DSR message is called the extended long DSR format (as shown in Figure 11). When one section is selected from multiple sections (or one section from multiple LCGs), the DSR message in Figure 11 is called the extended long truncated DSR format.

[0155] Method 700 proceeds to the fifth method step 705, where, if all candidate LCGs and sections do not fit within the available radio resources, the UE performs selection of LCGs and sections according to several criteria. Selection criteria may include: A. Remaining time for each section; B. The newness status of each section (e.g., new section vs. existing section); C. PDU Set Importance (PSI) values ​​associated with each section's PDU Set; and D. PSIHI QoS parameters associated with each section's PDU Set.

[0156] The UE is configured to characterize the state of any new sections that were not selected as "skipped" sections.

[0157] In the first exemplary method, “skip” sections from the LCG (e.g., multiple or all skipped sections from that LCG, optionally from all LCGs) are selected. Next, if there is free space after the first selection, “new” sections from the LCG are selected (e.g., multiple or all new sections from the LCG, optionally from all LCGs). If there is free space after the second selection, sections with new data from the LCG are selected (e.g., multiple or all sections with new data from the LCG, optionally from all LCGs). If there is free space after the third selection, remaining sections (of any type) from the LCG are selected (e.g., multiple or all remaining sections from the LCG, optionally from all LCGs). By implementing this method, the UE ensures that the gNB always receives delay information for sections as early as possible. Thus, the gNB can monitor the state of the LCGs itself and determine the remaining time for each section. As a result, the gNB can take predictive actions to ensure that delay information is never delayed.

[0158] According to the second exemplary method, the first selection involves identifying one or more sections (e.g., sections with multiple or all new data, optionally from all LCGs) that have new data from that LCG. Next, one or more sections with the most critical remaining time are selected from among the sections identified in the first selection. This first selection may include (without distinction) any of the new, skipped, and existing sections. Subsequently, if there is still space after the first selection, a second selection is made, including the remaining “skip” sections from the LCG (e.g., multiple or all remaining skipped sections, from the LCG, optionally from all LCGs). Next, if there is still space after the second selection, a third selection is made, including the remaining “new” sections from the LCG (e.g., multiple or all remaining new sections, from the LCG, optionally from all LCGs). If there is still space after the third selection, sections with the remaining new data from the LCG (e.g., sections with multiple or all new data, from the LCG, optionally from all LCGs) are selected. If there is free space after the fourth selection, any remaining sections (i.e., any type) from the LCG (e.g., from LCG, optionally from all LCGs, multiple, or all remaining sections) are selected. 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 sections as early as possible. This is particularly advantageous when large bursts arrive late on channels with critical delays.

[0159] In the third exemplary method, at least one section (e.g., from the LCG, optionally from all LCGs, multiple, or all sections) with new data from the LCG is identified. Next, among these identified sections, the marginal section with the highest remaining time to buffer size ratio is selected (e.g., multiple, or all sections with the highest remaining time to buffer size ratio are selected). This selection may include (without distinction) new, skipped, and existing sections. Next, if there is free space after the first selection, the remaining “skipped” sections from the LCG (e.g., from the LCG, optionally from all LCGs, multiple, or all remaining skipped sections) are selected. Following the second selection, if there is free space, the remaining “new” sections from the LCG (e.g., from that LCG, optionally from all LCGs, multiple, or all remaining new sections) are selected. After the third selection, if there is free space, the section with the remaining new data from the LCG (e.g., from that LCG, optionally from all LCGs, multiple, or all sections with new data) is selected. If there is still space after the fourth selection, the remaining sections (of any type) from the LCG (e.g., from that LCG, optionally from all LCGs, multiple, or all remaining sections) are selected. By performing this third exemplary method, the UE ensures that the section with the least time to send the known buffer size (e.g., the smallest delay budget) is preferred.

[0160] In at least one, or each, of the exemplary methods described above, further arbitration may be required at each selection step (for example, if five sections were determined in the initial selection but there are only three sections available, further arbitration will be necessary). In this situation, one of the following criteria (or a combination thereof) can be applied to determine which sections to keep: A. Logical Channel Priority: A section belonging to the LCG containing the highest priority LCH may be selected (this enforces application MAC level QoS); B. Remaining time: The section with the most critical remaining time may be selected (this allows gNB to obtain delay information in time); C. Remaining time versus buffer size ratio (prioritizes sections with less time to send a known buffer size); D. PDU Set Importance Information (PSI) associated with each section's PDU Set (prioritizing the most important PDU Set); and E. PDU Set Integration Importance Information (PSIHI) QoS parameters associated with each section's PDU Set (for example, if PSIHI is set to false, it means the application decoder can process (e.g., manage or process) the reception of a partial PDU Set, and therefore can skip sections containing PDU Sets where PSIHI is set to false).

[0161] In some cases, delay information is sent when a section is created, allowing the DSR trigger to follow the same trigger as the BSR. Therefore, there is no need to send an additional trigger (such as a dedicated DSR trigger) when the remaining time becomes critical.

[0162] In another example, a DSR trigger is performed by continuously comparing the remaining time associated with each section against a remaining time threshold configured by the gNB. Thus, a DSR is sent only when the remaining time associated with some of the data reaches a critical level.

[0163] In all examples, if no new section is selected, the UE may change the state of the new section so that it is characterized as a “skipped” section.

[0164] In the subsequent method step 706, the UE concatenates the selected section reports into a DSR format, such as one of the formats shown in Figures 9, 10, and 11 (e.g., combined as a chain or series). The DSR is then sent to the gNB.

[0165] The DSR format will be explained with specific reference to Figures 9a, 9b, 10, and 11.

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

[0167] For all sections, the section ID fields 902, 954, 1002, and 1102 are configured to display a section identifier that defines the section being reported. "New" or "Skipped" sections consist of a section type identifier or flag 903, 953, 1003, and 1103, which include a linguistic term (e.g., "new") and / or a numerical value (e.g., "1"). Additionally, "New" and "Skipped" sections have delay fields 905, 955, 1005, and 1105, set to the remaining timer value associated with the section. The remaining timer value is configured (e.g., adjusted) to the expected time for the first transmission attempt of the DSR. Furthermore, "New" and "Skipped" sections have buffer size fields 904, 954, 1004, and 1104, set to the buffer size associated with the section.

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

[0169] Using the "new" identifier means that different types of sections (e.g., "new" and "existing") can be distinguished from each other (e.g., within a DSR message), which reduces the frequency of sending delay information and allows for savings in signaling overhead.

[0170] By systematically transmitting section IDs even when delay information is not being reported, gNBs have the advantage of being able to continuously monitor delays in sensitive data (for example, using internal counters) based on the initial receipt of delay information.

[0171] Method 700 proceeds to Method Step 707, where the UE analyzes (e.g., checks) whether the previous DSR was received by the gNB. If the DSR was received successfully (i.e., the received status is delivered), the UE updates the status of the "new" sections in the previous DSR so that they are characterized as "existing".

[0172] If the previous DSR was not received by the gNB (i.e., the receive status is failure), the UE may start a retxBSR-Timer that counts down the time until further attempts are made to send a status (request) message. In addition, the UE updates the "new" status in the previous DSR so that they are characterized as "skipped".

[0173] Figure 8 is a flowchart of method 800 performed by the gNB when a delayed status report (DSR) is received (for example, from the UE). In the first method step 801, the gNB receives the DSR in one of the formats described above with reference to Figures 9, 10, and 11.

[0174] In the subsequent (optional) method step 802, for each element of delay information contained in the DSR, the gNB adjusts the delay information in the corresponding section as a function of the number of retransmissions required to receive the DSR. The delay information refers to the time of the initial transmission attempt. For example, if several PHY retransmissions were required (e.g., via a Hybrid Auto-Retransmission Request (HARQ) process or in-UE prioritization) for the MAC PDU containing the DSR to be successfully received, the number of PHY retransmissions may be recorded along with the delay information in the DSR to determine the actual remaining time.

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

[0176] In step 804 of the method, the gNB updates the buffer size information for each section in the scheduler. In particular, to determine the scheduling of uplink data, the gNB obtains the updated information from the UE providing the service. The updated information includes at least one of the following data types: A. Available data for legacy logical channel groups via legacy BSR procedures (such as those defined in 3GPP document TS38.321); B. Remaining time values ​​measured from the first section report, and available data for the corresponding section; and C. Latest information on available data.

[0177] Remaining time values ​​and updates to available data (i.e., data types A and B above) can be obtained via DSR for at least one, or each, of the sensitive LCGs.

[0178] By implementing a time-remaining counter for each section, the gNB can closely monitor changes in both the available data and remaining time for each section. Therefore, the gNB can make favorable scheduling decisions based on a complete knowledge of both legacy LCGs and time-sensitive LCGs, and the sections associated with them.

[0179] In one embodiment, the gNB constitutes the UE through dedicated signaling with respect to the legacy LCG, time-sensitive LCG, maximum number of sections, and section selection criteria (as defined, for example, in step 705 of the method in Figure 7). Alternatively, delay information may be included in the DSR for each new section and in the subsequent N DSR reports for the same section (where N is an integer configured by the gNB). Further alternatively, delay information may be systematically included in the DSR for each new section. Yet another way, the gNB constitutes the UE in one of three modes: A. Delay information for new sections only; B. Delay information for N consecutive times from section creation; and C. Systematic delay information for all sections.

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

[0181] Figure 9a is a schematic diagram showing the short DSR format and the short truncated DSR format. The short DSR format is used when there is only one LCH (or LCG) to report. The short truncated DSR has the same format as the short DSR and is used when the available radio resources are equal to the size of the short DSR format and there is data that can be sent to multiple LCHs (or LCGs). In detail, the message consists of an LCG ID 901 (e.g., consisting of at least 3 bits). The LCG ID field identifies the group of LCHs from which the delay status is being reported.

[0182] The section ID field 902 identifies a different section within the LCG (e.g., consisting of up to or at least 4 bits depending on the embodiment). In the short DSR format and short truncated DSR format, only one section is reported, even if the LCG contains multiple sections.

[0183] The term "new" in field 901 (e.g., consisting of at least 1 bit) indicates whether the section identified by the section ID field 902 is new or existing. Thus, the term "new" is an example of an ID bit that indicates whether a section is new or existing. If the section is new, associated delay information is reported in field 905 (e.g., consisting of at most or at least 3 bits), and associated buffer size is reported in field 904 (e.g., consisting of at most or at least 5 bits). If the section is not new (i.e., existing), no delay information is 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).

[0184] Figure 9b is a schematic diagram illustrating the Extended Short DSR format and the Extended Short Truncated DSR format. The Extended Short DSR format (either truncated or not) is used in the context of IAB applications that need to support a larger number of LCGs.

[0185] If a logicalChannelGroupIAB-Ext is configured (for example, as defined in 3GPP document TS38.321), the extended short DSR format is used when there is only one LCH (or LCG) to report.

[0186] 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 there is data that can be sent to multiple LCHs (or LCGs). In detail, the message consists of an LCG ID 951 (at least 8 bits). The LCG ID field identifies the group of LCHs from which the delay status is being reported.

[0187] The section ID field 954 identifies a different section within a single LCG (for example, having up to or at least 4 bits depending on the embodiment). In the Extended Short DSR format and Extended Short Truncated DSR format, only one section is reported, even if the LCG contains multiple sections.

[0188] The term "new" in field 953 (e.g., consisting of at least 1 bit) indicates whether the section identified by the section ID field 954 is new or existing. If the section is new, associated delay information is reported in field 952 (e.g., having a maximum of 3 bits or at least 3 bits), and associated buffer size is reported in field 955 (e.g., consisting of a maximum of 8 bits). If the section is not new (i.e., existing), no delay information is included, and the buffer size may only be reported in field 954. Alternatively, fields 954 and 955 may be combined as a single field (e.g., having at least 12 bits).

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

[0190] In detail, the message consists of eight LCG flags, and the corresponding LCGi (e.g., LCG) 0-7Each of the fields is assigned one field. Field 1001 indicates the presence of a delayed status report for the corresponding LCGi. If the value of field 1001 (i.e., the LCGi field) is set to 1, this indicates that the delayed status of the LCGi is "delivered" (i.e., reported). If field 1001 is set to 0, this indicates that the delayed status of the LCGi has not been reported.

[0191] The LCG delay statuses are listed in ascending order based on LCGi. The delay status for a single LCG (e.g., 1006, 1007) includes delay information for all sections within that LCG. The LCG delay status 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).

[0192] Initially, section bitmap 1002 is divided into sections Si (e.g., S 0-7 This indicates the existence of a delay status for the corresponding section (e.g., Si). If the Si field is set to 1, this indicates that a delay status has been reported for the corresponding section (e.g., Si). If the Si field is set to 0, this indicates that a delay status has not been reported for the corresponding section (e.g., Si).

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

[0194] Figure 11 is a schematic diagram showing message formats used as either the Extended Long DSR format, the Extended Long Truncated DSR format, or the Extended Preemptive DSR format. Each message is to be used when a logicalChannelGroupIAB-Ext is configured (as defined, for example, in 3GPP document TS38.321). The Extended Long DSR format is used when multiple LCGs are reported and the available radio resources are equal to the size required to report all LCGs. The Extended Long Truncated DSR format is used when multiple LCGs are reported and the available radio resources are greater than those for the Short DSR format, but less than the size required to report all LCGs. The Extended Preemptive DSR may be used in the context of IAB.

[0195] In detail, the message consists of 256 LCG flags for each LCGi. Field 1101 indicates the presence of a delay status report for the corresponding LCGi. If field 1101 (i.e., the LCGi field) is set to 1, this indicates that the delay status of the LCGi is "delivered" (i.e., reported). If the value of field 1101 is set to 0, this indicates that the delay status of the LCGi has not been reported. The LCG delay statuses are listed in ascending order based on the LCGi, and the delay status of one LCG (e.g., in fields 1106, 1107) includes delay information for all sections within the LCGi. 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).

[0196] Initially, section bitmap 1102 is divided into sections Si (e.g., S 0-7 This indicates the existence of a delay status for the corresponding section (e.g., Si). If the Si field is set to 1, this indicates that a delay status has been reported for the corresponding section (e.g., Si). If the Si field is set to 0, this indicates that a delay status has not been reported for the corresponding section (e.g., Si).

[0197] For at least one section, or for each section, the status report includes the term "new" (e.g., consisting of at least 1 bit) in field 1103, indicating whether the section is new or existing. If the section is new, associated delay information is reported in field 1105 (e.g., consisting of a maximum of 7 bits, or at least 7 bits), and associated buffer size is reported in field 1104 (e.g., consisting of a maximum of 7 bits, or at least 7 bits). If the section is not new (i.e., existing), no delay information is included, and the buffer size may be reported in 1105. The buffer size may be reported in a combined field (e.g., consisting of 15 bits) formed from 1104 and 1105. In embodiments, if the section is not new (i.e., existing), the buffer size is reported only in field 1105 (e.g., consisting of 7 bits). The section delay status may be reported "m" times for one LCG, where "m" is equal to the number of Si bits set to 1.

[0198] While embodiments of this disclosure have been described in relation to PDUs (and PDU Sets), this disclosure is not limited to this type of PDU. The methods of this disclosure can be applied to the transmission and reception of any ordered PDU, and in particular, this disclosure can be applied to the transmission of ordered PDUs on any layer.

[0199] While this disclosure has been described with reference to examples and embodiments, it should be understood that this disclosure is not limited to the examples and embodiments disclosed. 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.

[0200] All features disclosed herein (including the attached claims, abstract, and drawings), and / or all steps of any method or process disclosed herein, may be combined in any combination, except for any combination in which at least part of such features and / or steps are mutually exclusive. Each feature disclosed herein (including the attached claims, abstract, and drawings) may be replaced by alternative features serving the same, equivalent, or similar purpose unless otherwise specified. Thus, unless otherwise specified, each disclosed feature is merely a general set of examples of equivalent or similar features.

[0201] In a claim, the words “comprising” do not exclude other elements or steps, and the indefinite article “a” or “an” does not exclude plurals. The mere fact that different features are described in different dependent claims does not imply that combinations of these features cannot be used advantageously.

[0202] In the embodiments described above (i.e., exemplary configurations), the functions described may be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the functions may be stored or transmitted as one or more instructions or codes on a computer-readable medium and executed by a hardware-based processing unit.

[0203] Computer-readable media may include computer-readable storage media corresponding to tangible media such as data storage media, or communication media including any media that facilitates the transfer of computer programs from one location to another in accordance with communication protocols, etc. Thus, computer-readable media may correspond to (1) non-temporary tangible computer-readable storage media, or (2) communication media such as signals or carrier waves. Data storage media may be any available media accessible by one or more computers or one or more processors for retrieving instructions, code, and / or data structures for implementation of the technologies described herein. Computer program products may include computer-readable media.

[0204] Such computer-readable storage media may include, but are not limited to, RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, flash memory, or any other media that can be used to store desired program code in the form of instructions or data structures and that can be accessed by a computer. Also, any connection is appropriately called computer-readable media. For example, if instructions are transmitted from a website, server or other remote source using coaxial cable, fiber optic cable, twisted pair, digital subscriber line (DSL), or wireless technology such as infrared, radio, or microwave, then coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technology such as infrared, radio, or microwave may be included in the definition of media. However, it should be understood that computer-readable storage media and data storage media do not include connections, carriers, signals, or other transient media, but instead refer to non-transient tangible storage media. As used herein, the terms "disk" and "disc" include compact discs (CDs), laserdiscs, optical discs, digital-purpose discs (DVDs), floppy disks, and Blu-ray discs, where "disk" typically reproduces data magnetically and "disc" reproduces data optically using a laser. Any combination of the above 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 via a logical channel group (LCG) of a communication network, wherein the communication network includes user equipment and a base station, and the method in the user equipment is: Based on the timing information of multiple protocol data unit sets (PDU Sets), determine multiple sections to associate with the multiple PDU Sets, A status report for reporting the buffer status of the plurality of sections, wherein for at least one section, the status report includes a buffer size value indicating the amount of data of at least one PDU Set associated with that at least one section, and a timer value for that at least one section, and is transmitted to the base station. A method that includes this.

2. The method according to claim 1, wherein determining the plurality of sections includes determining at least one of the plurality of sections based on timing information of at least one of the plurality of PDU Sets.

3. The method according to claim 1 or 2, wherein the status report is transmitted after a decision is made in at least one of the multiple sections.

4. The method according to any one of claims 1 to 3, wherein, if the at least one section is associated with a plurality of PDU Sets, the buffer size value represents the amount of data for all associated PDU Sets.

5. The method according to any one of claims 1 to 4, further comprising sending an updated status report for the at least one section, which includes a buffer size value indicating the current amount of data in the at least one PDU Set.

6. The method according to any one of claims 1 to 5, wherein the method comprises sending a second status report that does not include a timer value after the first status report.

7. The method according to any one of claims 1 to 6, wherein the method for determining the plurality of sections includes generating a new section when the duration of an existing section expires.

8. The method according to any one of claims 1 to 7, comprising grouping two or more PDU Sets having matching timing information into a single section.

9. The aforementioned timing information includes the discard timer value of the PDU Set. The aforementioned method, The discard timer value of the PDU Set is compared with the timer value of one of the multiple sections, If the section timer value matches the discard timer value of the PDU Set, the PDU Set is associated with the section. The size value indicating the amount of data associated with the PDU Set is added to the buffer size value in the section, The method according to claim 8, including the method described in claim 8.

10. The aforementioned method, The discard timer value of the PDU Set is compared with the timer value of one of the multiple sections, If the discard timer value does not match the section timer value, a new section of the logical channel group is created. To start the timer for the new section corresponding to the discard timer value, The size value indicating the amount of data associated with the PDU Set is added to the buffer size value of the new section, The method according to claim 8 or 9, including the method described in claim 8 or 9.

11. The method according to claim 10, wherein if a new section cannot be generated, the PDU Set is assigned to an existing section having a buffer size value closest to the size value of the PDU Set.

12. The method according to claim 10 or 11, wherein if the discard timer value is substantially equal to the section timer value, the section timer value conforms to the discard timer value.

13. The aforementioned method, Before comparing the discard timer value and the section timer value, determine the configuration of the PDU within the PDU Set. If the PDU is the first PDU in the PDU Set, determine the discard timer, The method according to any one of claims 8 to 12, including the method described in any one of claims 8 to 12.

14. The method according to any one of claims 8 to 13, wherein two or more PDUs of the same PDU Set are assigned to the same section.

15. The method according to any one of claims 8 to 14, wherein if a PDU is the last PDU in a PDU Set, or if the PDU Set is discarded by another layer of the protocol stack, the PDU Set is discarded from the section.

16. The method according to any one of claims 1 to 15, wherein the method includes transmitting the status report, depending on the network decoder receiving an indication that it is unable to decode data that has not been received within a predetermined period of time.

17. The status report is sent depending on the determination of a delayed status report trigger, and the delayed status report trigger is For at least one logical channel in a logical channel group, data becomes available to another layer of the protocol stack, The resources for sending the PDU are allocated to another layer of the protocol stack, and the buffer size value of the current status report is at least the size of the buffer size value of the previous status report. The retry timer, which defines the period before a status report is attempted to be sent if the previous transmission failed, expires, and The periodic timer defining a predetermined period until the user device is configured to send the status report expires, The method according to any one of claims 1 to 16, which satisfies at least one of the following conditions.

18. The aforementioned method, To determine whether one or more new sections have been generated since the last status report trigger condition was identified, When data corresponding to different timer values ​​becomes available in the logical channels of a logical channel group, generate at least one new section, The method according to claim 17, including the method described in claim 17.

19. The aforementioned method, Receiving information indicating the buffer size value and / or timer value of a previously generated section, Based on the information received, update the buffer size value and / or timer value of the new status report, The method according to claim 17 or 18, including the method described in claim 17 or 18.

20. The aforementioned method, To generate status reports for two or more individual sections from the aforementioned multiple sections, Analyzing available wireless resources for sending status reports, Based on the available wireless resources, determine the number of individual section status reports to merge into the combined status report, The method according to any one of claims 1 to 19, including the method described in any one of claims 1 to 19.

21. The method, in response to determining that it is not possible to transmit at least one of the section status reports based on the available radio resources, The remaining time for each section, The newness status of each section, The PDU Set Importance (PSI) value associated with the data in each section, PDU Set Integrated Severity Information (PSIHI) service quality parameters associated with the data in each section, The method according to claim 20, comprising selecting two or more sections based on at least one of the following criteria.

22. The aforementioned method, Firstly, select at least one section to be skipped, Secondly, select at least one new section, Thirdly, select at least one section that contains new data, Fourth, select at least one of the remaining sections, The method according to claim 20 or 21, comprising selecting two or more sections in accordance with the method.

23. The aforementioned method, Firstly, determine one or more sections that have new data, and then select at least one section from the identified one or more sections that has a critical remaining timer value. Secondly, select at least one section to be skipped, Thirdly, select at least one new section, Fourth, select at least one section that contains new data, Fifth, select at least one of the remaining sections, The method according to any one of claims 20 to 22, comprising selecting two or more sections accordingly.

24. The aforementioned method, First, determine one or more sections with new data, and then select at least one section from the identified one or more sections that has the most critical and high remaining time to buffer size ratio. Secondly, select at least one section to be skipped, Thirdly, select at least one new section, Fourth, select at least one section that contains new data, Fifth, select at least one of the remaining sections, The method according to any one of claims 20 to 23, comprising selecting two or more sections accordingly.

25. The method according to any one of claims 22 to 24, wherein the method proceeds to a subsequent selection only if sufficient radio resources are available to accommodate further selection status reports.

26. In at least one of the above selections, the user device is Logical channel priority and Remaining time, The ratio of remaining time to buffer size, PDU Set importance information (PSI) associated with each section, PDU Set Integrated Severity Information (PSIHI) service quality parameters associated with each section, The method according to any one of claims 22 to 25, wherein a ruling is made between two or more eligible sections based on at least one of the following selection criteria.

27. The user device receives a dedicated signaling from the base station in order to configure the status report transmission. The aforementioned signaling is, The previous logical channel group configuration and Configuration of time-sensitive logical channel groups, The maximum number of sections, The method according to any one of claims 1 to 26, comprising information relating to at least one of the following.

28. The method according to any one of claims 1 to 27, wherein the timer values ​​for all available sections are included in the status report.

29. The method according to any one of claims 1 to 28, wherein only the timer value of the new section is included in the status report.

30. The method according to any one of claims 1 to 29, wherein the timer value of the section is included in the first status report after the creation of the section and in N subsequent status reports, where N is an integer configured by the base station.

31. A method for reporting the buffer status of data transmitted over a logical channel group (LCG) of a communication network, wherein the communication network includes user equipment and a base station, and the method at the base station is: Based on the timing information of multiple protocol data unit sets (PDU Sets), identify multiple sections to associate with the multiple PDU Sets, A status report for reporting the buffer status of the plurality of sections to the base station, the status report being received includes, for at least one section, a buffer size value indicating the amount of data of at least one PDU Set associated with that at least one section, and a timer value for that at least one section. Based on the timer value, configure the timer associated with the at least one section, A method that includes this.

32. A communication network including a user device configured to perform the method described in any one of claims 1 to 30, and / or a base station configured to perform the method described in claim 31.

33. A computer program having an instruction to cause a user device to perform the method described in any one of claims 1 to 30 when the program is executed by a user device, or having an instruction to cause a base station to perform the method described in claim 31 when the program is executed by a base station.

34. A computer-readable medium for transporting the computer program described in claim 33.

Images