Method for buffer status reporting in a communication network

Abstract

A method for reporting a buffer status of data to be transmitted over a logical channel group, LCG, of a communication network The communication network comprises a user equipment and a base station. The method at the user equipment comprising: determining a plurality of sections for associating with a plurality of protocol data unit Sets, PDU Sets, based on timing information of the plurality of PDU Sets; and transmitting a status report for reporting the buffer status of the plurality of sections to the base station, wherein the status report comprises, for at least one section, a buffer size value indicative of the amount of data of at least one PDU Set associated with the at least one section, and a timer value of the at least one section.

Description

[0001] METHOD FOR BUFFER STATUS REPORTING IN A COMMUNICATION NETWORK

[0002] FIELD OF THE DISCLOSURE

[0003] The present disclosure relates to a method for buffer status reporting in a communication network (e.g., a mobile telecommunication network). More particularly, the method relates to transmitting a delay status report, from a user equipment (UE) to a base station (gNB) of the communication network.

[0004] BACKGROUND

[0005] Wireless communication systems are deployed to address a wide range of applications, including mobile broadband, massive machine type communications, and Ultra Reliable Low Latency Communications (URLLC). Such systems allow a plurality of user equipment (UE) or mobile terminals to share the wireless medium to exchange different types of data content (e.g., video, voice, messaging...) over a radio access network (RAN) through one or more base stations.

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

[0007] XR (i.e. , extended Reality) applications are defined in 3GPP document RP-2200285 as “various types of augmented, virtual, and mixed environments, where human-to-machine and human-to-human communications are performed with the assistance of handheld and wearable end user devices”. Various use cases can be found in 3GPP document TR-26.928.

[0008] Many XR applications involve interactions 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 through a local Network (e.g., a wireless LAN) or cellular network (e.g., 3GPP 5G cellular network, the application server being connected to a 5G core network component of the network).

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

[0010] Some XR applications like virtual reality, involve transferring compressed video data, audio data and various information from the server to the wearable device. Some XR applications like augmented reality, involve transferring compressed video data, audio data and various information exchanged to and from the wearable device and the server.

[0011] In the present disclosure, the information exchanged to and from the UE (e.g., wearable device) and the server is referred to as application data, which may comprise one or more images, video data, audio data, position information etc.

[0012] The video and audio data are transferred between the UE (e.g., wearable device) and the server using media transport protocols such as RTP (Real Time Protocol, RFC 3550), SRTP (Secured RTP, RFC 3711), HTTP (Hyper Text Transfer Protocol, RFC 2616-7540) or QUIC (RFC 8999, 9000, 9001 and 9002).

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

[0014] According to the 3GPP standard, a set of Protocol Data Units, or Packet Data Units, (PDUs) are necessary to transport an application data packet (i.e. , “PDU Set”). Accordingly, the application data comprises one or more application data packets. During downlink, 3GPP PDUs are formatted by the PDU Layer of the core network. In the same way, during uplink, the 3GPP PDUs are formatted by the PDU layer of the UE (e.g., wearable device). According to the 3GPP standard, the delimitations of the PDU Sets (e.g., start, stop, and length etc.) are not provided by the application but generated by the core network (respectively the UE) through media transport protocol packet inspection. The detailed procedure can be found in 3GPP document S2-2302696.

[0015] A PDU Set includes one or more PDUs that carry the payload of one unit of information generated at the application level (e.g., a frame or video slice for XRM Services, as used in TR 26.926). In some implementations, all PDUs in a PDU Set are needed by the application layer to use the corresponding unit of information. For example, one PDU Set may comprise the data of one image or frame from a video stream. In other implementations, the application layer can still recover parts, or all, of the information unit, when some PDUs are missing.

[0016] The network used to transport the application data can experience perturbation and congestion. It is therefore possible that some PDUs of a PDU Set are missing, or are late, at the receiving side (e.g., UE PDU layer during downlink, and core network user plane function (UPF) during uplink).

[0017] Some video decoder implementations require that a complete application data packet (e.g., complete PDU Set) is received on time in order to adequately decode a video. Some other implementations can tolerate late arrival of data packets, or partial delivery of a data packet. For example, these implementations rely on Forward Error Correction (FEC) technology or concealment techniques.

[0018] According to the 3GPP standard, in document S2-2302696, a PDU Set QoS parameter called PDU Set Delay Budget (PSDB) is defined. The PDSB defines a time budget allocated to the transport of the PDU Set across the 5G network. This QoS parameter, defined by the application, is used by a 5G network to assess if a PDU Set (e.g., application data packet) is delivered on time.

[0019] In the same 3GPP document, S2-2302696, another QoS parameter named PDU Set Integrated Handling Indication (PSI HI) is defined to characterize the decoder’s tolerance to the loss of data, or receiving outdated (e.g., delayed) data. If the PSIHI parameter is set to “true”, then the decoder can only handle (e.g., manage or process) a complete application data packet which is received on time. If the PSIHI parameter is set to “false”, then the decoder can tolerate both incomplete and delayed application data packets.

[0020] Considering the situation at a particular component of the 5G network, when a PDU Set is sent over the air interface, some information is available regarding the reception status of the PDUs and the elapsed time of the PDSB. For example, when a PDU Set is transferred over the air a Radio Access Network (RAN) node (e.g., a UE or a next gen node (gNB)) can detect that a PDU transmission has failed despite all the retransmissions and error correction mechanisms. In that case, if the PSIHI parameter is set to “true”, then the entire PDU Set is useless to the application. In that case, if one or more PDUs of this “useless” PDU Set are pending transmission over the air interface then the RAN node can consider discarding the remaining transmission of the “useless” PDUs, thus achieving radio network resource saving.

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

[0022] • Dynamic request scheduling by each UE;

[0023] • Semi-static scheduling by the gNB, where the gNB may issue periodic resource allocation to one UE; and

[0024] • Buffer status reporting (BSR) by each UE indicating the amount of data available for uplink transmission.

[0025] BSR operates on Logical Channel Groups (LCG), which group together a plurality of MAC logical channels (LCH). The BSR triggering conditions and formats, as defined in 3GPP document TS 38.321 , are directed towards sending available data that is ready for uplink transmission for each LCG. Then, based on this knowledge the gNB is able to perform resource scheduling. For example, the gNB may decide to favour an LCG with the most data available whilst preventing resource starvation on low throughput LCGs.

[0026] Some of the XR data may have PDSB which must not be overrun because data becomes obsolete and useless after the delay period has elapsed. In this situation, it is necessary for the scheduler to have knowledge of the remaining time left (e.g., the remaining delay budget) for the XR data when taking scheduling decisions.

[0027] Considering that the BSR operates on LCG and considering that multiple PDU Sets can be multiplexed in a single logical channel, it is then not appropriate to add delay information to the BSR because the reported buffered data will be associated with delay periods which are potentially different (i.e. , because they belong to different PDU Sets).

[0028] Accordingly, there is a need to provide a method to configure a communication network such that the transmission and delay of PDUs is managed to ensure that data is not missed by the base station, whilst also minimizing overheads in the network.

[0029] SUMMARY

[0030] According to aspects of the present disclosure, there is provided a method of configuring a RAN node of a communication network (e.g., a UE) to report the buffer status of data (e.g., one or more data packets) which is to be transmitted across the network (e.g., to a gNB). The buffer status is transmitted by way of a status report which is configured (e.g., divided) into multiple sections, wherein each section may be configured to enable a plurality of data packets having similar buffer statuses to be associated with the same section. The buffer status includes, for each section, an indication of the amount of data to be transmitted, and an indication of the time remaining before the section elapses. In this way, the method enables the receiving RAN node to predict when a set of data packets will elapse, so that the node can allocate network resources more efficiently, whilst also reducing the network transmission load.

[0031] In accordance with a first aspect of the present disclosure, there is provided a method for reporting a buffer status of data to be transmitted (e.g., a protocol data unit (PDU), and / or a PDU Set) over a logical channel group (LGC) of a communication network, the communication network comprising a user equipment and a base station. The method at the user equipment comprises: determining a plurality of sections for associating with a plurality of protocol data units (e.g., of one or more PDU Sets), and / or a plurality of PDU Sets, based on timing information of the plurality of PDUs / PDU Sets; and transmitting a status report for reporting the buffer status of the plurality of sections to the base station. The status report comprises, for at least one section, a buffer size value indicative of 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. In accordance with a second aspect of the present disclosure, there is provided a method for reporting a buffer status of data to be transmitted over a logical channel group, LCG, of a communication network, the communication network comprising a user equipment and a base station. The method at the base station comprises: identifying a plurality of sections for associating with a plurality of PDlls (e.g., of one or more PDU Sets), and / or a plurality of PDU Sets, based on timing information of the plurality of PDUs / PDU Sets; receiving a status report for reporting the buffer status of the plurality of sections to the base station. The status report comprises, for at least one section, a buffer size value indicative of 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 configuring a timer associated with the at least one section based on the timer value.

[0032] As described above, known scheduling methods (e.g., such as BSR) allocate resources based on the quantity of available data. Such methods are time agnostic, which means that critical traffic might be delayed such that the receiving node will not receive the data within a required delivery time.

[0033] According to a known method of controlling a communication network, multiple buffer sizes are reported for a single LCG together with a bit flag warning for situations where there is a critical delay. With this known method, the delay value itself is not communicated to the base station, so the base station must interpret the bit flag warning information as an emergency situation. Accordingly, the base station cannot anticipate the late arrival of the data. Furthermore, since the status report is transmitted in dependence on resource availability, and since the status reporting is prone to de-scheduling because of higher priority data being available, it is not possible to guarantee that the delay status will arrive on time to the base station (despite the bit flag warning). Furthermore, the reporting mechanism is ineffective unless additional reporting triggers are defined so that when the delay becomes critical (but the data quantity is not changed) the status report is sent anyway, which thereby increases the overheads of the network.

[0034] 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 is not consistent with the best practice for careful usage off radio resources.

[0035] The aspects of the present disclosure provide a scheduling method which is time sensitive, such that critical information (e.g., PDUs) can be delivered on time. Further, the aspects of the present disclosure enable traffic with different delay requirements to be conveniently organised into one or more sections of a single channel (or plurality of channels). The buffer size and timer values for the different sections can be transmitted in a status report (e.g., when new data is ready for transmission to the network), which enables early communication of delay information to the base station so that the deadline is not missed, whilst lowering overheads within the network (e.g., since the delay information for one section only needs to be sent once).

[0036] Upon receiving the status report of the present disclosure, the base station can implement remaining time counters for each section. This enables the base station to closely monitor the evolution of both the available data and remaining time for each section. Hence the base station is able to perform advantageous scheduling decisions based on complete knowledge of both legacy logical channel group and time sensitive logical channel group with their associated sections.

[0037] A number of optional features are set out in the following passages. These are applicable singly or in any combination with any aspect of the disclosure.

[0038] Whilst the present method is described with reference to a UE and base station (e.g., of the communication network), it will be appreciated that the method would apply to any suitable component of a communication network which comprises a transmitting means (e.g., a transmitter) and / or receiving means (e.g., a receiver), respectively.

[0039] The PDU Set may be comprised of at least one PDU (e.g., a plurality of PDUs). The timing information of the PDU Set. In embodiments, two or more PDUs of the same PDU set may be assigned to the same section.

[0040] The PDU Set (and / or the PDUs comprised therein) may have an associated timing information (e.g., measured in a unit of time, e.g., seconds). The timing information may include a timing parameter or timer value (e.g., a discard timer), which may be indicative of when the data packet will elapse, or expire (e.g., a PDU discard timer, and / or a PDU Set discard timer).

[0041] The plurality of sections (e.g., of the LGC) may define portions, or parts, of a status report to which one or more PDU Sets (and / or PDUs) can be associated (or assigned). The at least one, or each, section may be determined based on the timing information of at least one, or each, of the plurality of PDU Sets (and / or PDUs).

[0042] At least one, or each, of the sections may be configured with a corresponding timer value. The timer value may define a duration (or lifetime) of the section (e.g., a time period before which the section can be discarded).

[0043] The status report may be generated, and / or transmitted, in response to determining at least one of the plurality of sections. For example, the status report may be generated and transmitted shortly (e.g., immediately) after the plurality of sections (and / or at least one of the plurality of sections) is determined. The status report may be transmitted once a predetermined time period has expired, or alternatively immediately following the identification of at least one (and / or a plurality, or each) of the plurality of sections.

[0044] Optionally, in situations where the at least one section is associated with a plurality of PDU Sets, then the buffer size value is configured to be indicative of the amount of data of all (i.e. , each) of the associated PDU Sets. In this way, buffer size value may define the sum of the amount of data of each PDU set associated with the section. Advantageously, this means that the base station receives relevant information corresponding to all of the relevant PDU Sets (and their respective PDUs) within each section.

[0045] The method may comprise transmitting a second status report which does not comprise a timer value. The second status report may be transmitted after the first status report. In embodiments, the second status report may be transmitted after a predetermined time period, and / or in response to the determination of at least one section (e.g., a new section) of the plurality of sections. Further, the second status report may be transmitted when further data is received by the UE from an application layer of the protocol stack. For example, a new PDU / PDU Set (e.g., a new PDU of an existing PDU Set) may be newly associated with an existing section (e.g., which contains at least one PDU / PDU Set having a matching timer value). In this situation, the second status report may report the change in the remaining buffer size of the section. However, the timer status of the new PDU / PDU Set matches that of the section (i.e., which was reported in the first status report). Accordingly, the timer value can be advantageously omitted from the second report, which thereby reduces the transmission burden on the network.

[0046] The method of determining the plurality of sections may comprise generating a new section when an existing section expires (e.g., when the timer value of the previous section elapses).

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

[0048] The method may comprise transmitting a third status report after the first status report, optionally after the second status report. The third status report may be transmitted at the end of a predetermined time period corresponding to the duration of at least one of the plurality of sections. The third status report may comprise both a buffer size value and a timer value. For example, the third status report may be transmitted after an existing section is discarded (e.g., due to an elapsed timer). The remaining portion of the LCG can be re-allocated to a new section. In this case, the third status report may include a buffer size value and timer value corresponding to the new section. The base station may use the timer value to start a new counter for the associated section.

[0049] The data for transmission may comprise a plurality of PDlls, and / or PDU Sets (e.g., the transmission may comprise two or more PDU Sets, each comprising at least one, or a plurality, of PDU(s)). 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). The method may comprise grouping two or more PDUs (or PDU Sets) with matching timing information into a single section.

[0050] Optionally, the method may comprise at least one of the following method steps: comparing a discard timer value of the PDU Set and / or PDU (i.e. , a PDU / PDU Set discard timer value), with the timer value of at least one section of the plurality of sections; associating the PDU / PDU Set with the at least one section if the section timer value matches the discard timer value; and adding a size value indicative of an amount of data associated with the PDU PDU Set to the buffer size value of the at least one section.

[0051] Optionally, the method may comprise 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 the plurality of 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 which corresponds to the discard timer value; and adding a size value indicative of the amount of data associated with the PDU / PDU Set to the buffer size value of the new section.

[0052] In embodiments, the section timer value may be considered to match with the discard timer value if the discard timer value is substantially equal to the section timer value.

[0053] Optionally, the method is comprised of the following method steps: comparing a PDU / PDU Set discard timer value with the timer value of at least one section of the plurality of 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 which corresponds to the discard timer value; and configuring the buffer size value of the new section to match a size value of the PDU / PDU Set.

[0054] In embodiments, if a new section cannot be generated, then the PDU and / or PDU Set may be assigned to an existing section with a buffer size value that is closest to the size value of the PDU and / or PDU Set.

[0055] Optionally, before comparing the discard timer value with the section timer value, the method may comprise determining the configuration of a PDU within the PDU set. The method may then proceed by determining the discard timer if the PDU is the first PDU of the PDU set. The method may comprise transmitting the status report in dependence on receiving an indication that a decoder of the network is incapable of decoding data which is not received within a predetermined time period.

[0056] Transmitting the status report may be initiated in dependence on determining one or more of the following delay status reporting trigger conditions: data becomes available to another layer of the protocol stack for at least one logical channel of the logical channel group; resources for sending a PDU / PDU Set are (currently) allocated in another layer of the protocol stack, and the buffer size value of the present status report is at least the size of a previous status report (i.e. , which has previously been transmitted); a retry timer expires, wherein the retry timer defines a period after which the status reporting transmission is attempted if a previous transmission failed; and a periodic timer expires, wherein the periodic timer defines a predetermined period after which the user equipment is configured to transmit the status report.

[0057] In embodiments, the DSR triggering may be performed by continuously comparing the remaining time associated to at least one, or each of, the plurality of sections with a remaining time threshold configured by the gNB. In this way, the DSR may be sent only when some data has reached a critical level of remaining time.

[0058] The method may comprise the following method steps: determining if one or more new sections have been generated since the last status report trigger conditions was identified; and generating at least one new section if data corresponding to a different timer value becomes available in a logical channel of the logical channel group.

[0059] Optionally, the method may comprise the following method steps: receiving information indicative of a buffer size value and / or a timer value of a previously generated section; and updating the buffer size value and / or a timer value of a new status report base on the received information.

[0060] Optionally, the method may comprise the following method steps: generating an individual section status report for two or more of the plurality of sections; analysing available radio resources for status report transmission; and determining, based on the available radio resources, the number of section status reports for merging into a combined (e.g., single) status report.

[0061] The status of a non-selected section from a previous status report may be characterised as a skipped section.

[0062] Optionally, the method may comprise determining that at least one of the section status reports cannot be transmitted based on the available radio resources. The method may comprise selecting two or more of the sections based on at least one of the following criteria: a remaining time of each section (i.e., before the timer value elapses); a novelty status of each section (e.g., how recently was the section generated); a PDU Set importance (PSI) value associated with the data of each section; and a PDU Set integrated importance information (PSI HI) quality of service parameter associated with the data of each section.

[0063] In embodiments, the method may comprise selecting two or more sections according to the following method steps: firstly selecting at least one skipped section; secondly selecting at least one new section; thirdly selecting at least one section with new data; fourthly selecting at least one of the remaining sections. By implementing this method, the user equipment makes sure that the base station always receives the delay information of the sections as early as possible. Accordingly, the base station is able to monitor the status of the logical channel group by itself and determine the remaining time for each section. As a result, the base station is able to take anticipated actions so that the delay information is never late.

[0064] Alternatively, the method may comprise selecting two or more sections according to the following method steps: firstly determining at least one section with new data and selecting, from these sections, at least one section with a critical remaining timer value (e.g., a timer value which will expire before the other timers, and / or within a fraction of the other timer values, and / or within a predefined (e.g., minimum) time period); secondly selecting at least one skipped section; 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 equipment can ensure that the base station receives an update of the buffer size and delay timer of the most critical section as early as possible. This is particularly advantageous in the case of a late arrival of a large burst on a delay critical channel.

[0065] Further alternatively, the method may comprise selecting two or more sections according to the following method steps: firstly determining one or more sections with new data and then selecting, from the one or more identified sections, at least one section with the highest critical remaining time to buffer size ratio; secondly selecting at least one skipped section; 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 equipment ensures that the section with less time (e.g., the smallest delay budget) to send the known buffer size is prioritized.

[0066] The method may only proceed to a subsequent selection (i.e. , as defined in the relevant preceding paragraphs) if there are sufficient radio resources available to accommodate a further selection status report.

[0067] For at least one of the above-described selection method steps, the user equipment may arbitrate between two or more qualifying sections on the basis of at least one of the following selection criteria: a logical channel priority: the section belonging to an logical channel group including an logical channel with the highest priority may be selected (e.g., based on quality of service protocol of a controlling layer of the protocol stack, for example, the application level); a remaining time: the section with the most critical remaining time may be selected (which allows the base station to obtain the delay information on time); a ratio of remaining time to buffer size (which favours the sections with less time to send the known buffer size); PDU Set Importance Information (PSI) associated with the PDU Sets of each section (which favours the most important PDU Sets); and PDU Set Integrated Importance Information (PSIHI) QoS parameter associated with the PDU Sets of each section (e.g., sections containing PDU Sets with the PSIHI set to false can be skipped, since when the PSIHI is set to false it means the application decoder can handle (e.g., manage or process) the reception of a partial PDU Set).

[0068] The user equipment may receive dedicated signalling from the base station to configure the status reporting transmission.

[0069] Alternatively, or additionally, the signalling from the base station may comprise information regarding at least one of the following: the configuration of a previous logical channel group; configuration of a time sensitive logical channel group; and a maximum number of sections.

[0070] The timer value for all available sections may be included in the status report. Alternatively, only the timer value for a new section may be included in the status report (e.g., only in the first status report generated following the creation of a new section). The timer value for a particular section (e.g., a new section) may be included in the first status report following the generation of the section, and in N subsequent status report(s), wherein N is an integer configured by the base station. The base station configures the user equipment with one of the three aforementioned modes for each logical channel group. Accordingly, 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 therefore exist in several formats.

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

[0072] According to the second aspect, the method at the base station includes the method step of configuring at least one timer associated with the at least one section based on the timer value. This method step may comprise starting at least one timer (or counter) associated with the at least one section in dependence on receiving the status report. The length (or duration) of the timer may be determined based on the timer value. The base station may start a different timer for each section, as determined by the status report. Once the timer value has elapsed the base station may discard the timer. The base station will not expect to receive data corresponding to the at least one section after the at least one timer has elapsed, which thereby enables the base station to allocate network resources more efficiently.

[0073] In accordance with a third aspect of the present disclosure, there is provided a communication network which comprises a network element (e.g., a base station or UE) as recited in claim 32 of the accompanying claims.

[0074] In accordance with a fourth aspect of the present disclosure, there is provided a user equipment (e.g., embodied within a transceiver of the communication network) which is configured to perform the methods of any one of the preceding paragraphs (e.g., as defined by any one of claims 1 to 31).

[0075] The transceiver may be configured for use in a communication network (e.g., a wireless telecommunication network) comprising a transmitting means (e.g., a first transceiver). The transceiver (e.g., which may define a second transceiver of the communication network) may be configurable to receive a PDU Set from a transmitting means. The transceiver may comprise a receiving means (e.g., a receiver) for receiving a status report, and / or a transmitting means (e.g., a transmitter) for transmitting a status report.

[0076] The features of any one of the first, and second aspects may be embodied in any suitable components of a communication network (e.g., a transmitter and / or a receiver). For example, the transmitting and receiving means may be arranged at different locations within the communication network (e.g., to define respective transmitting and receiving network nodes), or they may be arranged in a single element of the network (e.g., to a define a single component of the network, such as a transceiver of a user equipment or base station etc.).

[0077] In accordance with a fifth aspect of the present disclosure, there is provided a computer program as recited in claim 33 of the accompanying claims.

[0078] In accordance with a sixth aspect of the present disclosure, there is provided a computer-readable medium as recited in claim 34 of the accompanying claims.

[0079] The PDU Set may comprise one or more PDUs. At least one, or each, PDU may be configured to carry a payload of one unit of information generated at the application level (e.g., a frame or video slice for XRM Services, as used in TR 26.926). Each PDU Set may be characterised by identification information (e.g., which defines the parameters of the PDU Set). For example, the identification information may define the start, stop, and / or length (e.g., the number of PDUs) of the PDU Set. However, at various points in the data transmission process, the receiving entity does not have knowledge of the PDU Set’s identification information. In embodiments, the PDU identification information is unknown at all protocol layers (e.g., including the layer). The present disclosure relates to communication networks for applications relating to extended reality (XR). Such communication networks may comprise third generation partnership protocol (3GPP) and fifth generation (5G) new radio (NR).

[0080] XR applications may be defined (e.g., in 3GPP document RP-2200285) as one or more types of augmented, virtual, and mixed environments, where human-to-machine and human- to-human communications are performed with the assistance of handheld and wearable end user devices. Several use cases are defined in 3GPP document TR-26.928.

[0081] The information exchanged to and from the UE (e.g., a wearable device) and the server may be referred to as application data. For example, application data may comprise one or more images, video data, audio data, position information and various information.

[0082] Application data (e.g., such as video, audio or position information / data) may be transferred between UE (e.g., wearable device) and the server using media transport protocols including RTP (Real Time Protocol, RFC 3550), SRTP (Secured RTP, RFC 3711), HTTP (Hyper Text Transfer Protocol, RFC 2616-7540) or QUIC (RFC 8999, 9000, 9001 and 9002). Video encoding and decoding can be performed according to various formats including MPEG2, H.264, H.265, HEVC, etc.

[0083] Any feature in one aspect of the disclosure may be applied to other aspects of the disclosure, in any appropriate combination. In particular, method aspects may be applied to apparatus / device / unit aspects, and vice versa.

[0084] Furthermore, features implemented in hardware may be implemented in software, and vice versa. Any reference to software and hardware features herein should be construed accordingly. For example, in accordance with other aspects of the disclosure, there are provided a computer program comprising instructions which, when the program is executed by one or more processing units, cause the one or more processing units to carry out the method of any aspect or example described above and a computer readable storage medium carrying the computer program.

[0085] BRIEF DESCRIPTION OF THE DRAWINGS

[0086] Different aspects of the disclosure will now be described, by way of example only, and with reference to the following drawings in which:

[0087] Figure 1 is a schematic diagram illustrating a first example wireless communication system in which the present disclosure may be implemented according to one or more embodiments of the disclosure;

[0088] Figure 2 illustrates a schematic diagram of an example configuration of a UE in which the present disclosure may be implemented according to one or more embodiments of the disclosure; Figure 3 illustrates a schematic diagram of an example configuration of a base station in which the present disclosure may be implemented according to one or more embodiments of the disclosure;

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

[0090] Figure 5 is a flow chart showing a method executed at a UE PDCP layer of the wireless communication system of Figure 1 ;

[0091] Figure 6 is a flow chart showing a method executed at a UE MAC layer of the wireless communication system of Figure 1 ;

[0092] Figure 7 is a flow chart showing a method executed, when a delay status report (DSR) is triggered, at a UE MAC layer of the wireless communication system of Figure 1 ;

[0093] Figure 8 is flow chart showing a method executed, when a DSR is received, at the gNB of the wireless communication system of Figure 1 ;

[0094] Figure 9a is a schematic diagram illustrating a short DSR format and a short truncated DSR format;

[0095] Figure 9b is a schematic diagram illustrating an extended short DSR and an extended short truncated DSR format;

[0096] Figure 10 is a schematic diagram illustrating exemplary message formats, including a long DSR format, a long truncated DSR format, and a pre-emptive DSR format; and

[0097] Figure 11 is a schematic diagram illustrating exemplary message formats including an extended long DSR format, an extended long truncated DSR format, and an extended preemptive DSR format.

[0098] DETAILED DESCRIPTION

[0099] Figure 1 illustrates an example wireless communication system 100, in particular a mobile radio communication system such as a fifth-generation (5G) New Radio (NR) system supporting extended reality service (XR). Although in the following description, embodiments and examples of embodiments of the present disclosure will be described with respect to a 5G NR system, it will be appreciated that it is not intended that the present disclosure is limited to 5G NR systems and may be used in any wireless communication systems supporting XR or similar service.

[0100] The system 100 comprises a User Equipment (UE) 101 , 151 which may be for instance virtual reality helmets or extended reality wearables like glasses, served by a base station 110 to communicate with a core network, such as the 5G core network 102. The UE may be any wireless device, such as a wireless communication device or apparatus or terminal, loT device, Machine Type Communication (MTC) device, Device to Device (D2D) terminal, user device (e.g., smart phone, laptop, mobile phone, tablet, camera, game console, wearable device), capable of wireless communication with one or more core networks via one or more Radio Access Networks. The base station 110 is a network node which provides an access point to the core network for a UE and is part of the Radio Access Network (RAN) composed of the base stations 110, and 111. In NR, base stations are referred to as next-generation Node Bs (gNBs), the RAN is a Next Generation (NG) RAN and the core network is referred to as the 5GC. In the following, the terms RAN node, base station and gNB will be used interchangeably. The base stations 110 and 111 are interconnected by means of the Xn interface (e.g., as specified in the 3GPP document TS 38.423) implemented on the wired or wireless link 130. Each base station is connected to the core network 102 by means of the NG interface (e.g., as specified in the 3GPP document TS 38.413) implemented on the wired or wireless links 140 and 141.

[0101] Each of these base stations controls one or multiple cells. For instance, the base station 110 controls the cell 120, and the base station 111 controls the cell 121. A cell is a geographical area of a radio network defined by the frequency used in the cell to transmit data. The cell can be uniquely identified by a UE from an identification that is broadcasted over a geographical area. Each base station 110, 111 can serve several UEs 101 , 151. Once a UE has established a RRC connection with a base station, the base station, to which the UE is connected, is referred to as the serving base station (or source base station) of the UE and the cell which is controlled by the serving base station, and on which the UE camps, is referred to as the serving cell. The interface between a gNB and a UE is the Uu interface using the protocol sublayers Service Data Adaptation Protocol (SDAP), Packet Data Convergence Protocol (PDCP), Radio Link Control (RLC), Medium Access Control (MAC), Physical (PHY) in the user plane, and the protocol sublayers Radio Resource Control (RRC), PDCP, RLC, MAC, PHY in the control plane.

[0102] It is assumed that the UE 101 is receiving and / or sending XR data of one or more multicast XR sessions generated and / or destinated to the XR application server 103. XR data is provided to the base station 111 (which is the base station controlling the cell 121 on which the UE 101 is attached) through the core network 102 (e.g., through the Data Network 160 and the User Plane Function 161) and the transport bearer (also known as a GTP-U tunnel) 106 over the link 141. Then, XR data is transmitted by the base station 111 to the UE 101 through the Data Radio Bearer (DRB) 154. Figure 1 also shows the UE 151 receiving data through DRB 153. A radio bearer is a set of PHY (layer 1) and MAC (layer 2) parameters allowing higher layer data connection between a UE and a gNB. Multiple types of radio bearers are defined in 5G NR: the Signalling Radio Bearer (SRB) for the control plane, the Data Radio Bearer (DRB) allowing point-to-point communication with one UE in the user plane (e.g., unicast), and the Multicast radio bearer (MRB) allowing point-to-point communication and point-to-multipoint communication with multiple UEs (e.g., multicast / broadcast), also in the user plane.

[0103] Figure 2 is a block diagram of a UE device 205, like the UE 101 or UE 151 in the Figure 1 , in which the present disclosure may be implemented according to one or more embodiments of the disclosure. The UE includes components for transmitting and receiving communications, for example including at least one of a UE communication manager 220, an I / O controller 255, a transceiver 235, a set of antennas 245, a storage device (e.g., memory) 225, and a processor (CPU: Central Processing Unit) 215. All these elements may communicate with each other.

[0104] The memory 225 includes Random Access Memory (RAM), Read Only Memory (ROM), or a combination of both. Alternatively, or additionally, the memory 225 may comprise a mass storage device, such as a disk, or a Solid-State Drive (SSD). Basic Input Output System (BIOS) Instructions may be stored within the memory 225.

[0105] The processor 215 is configured to execute machine readable instructions. Execution of these machine-readable instructions causes the UE to perform various functions. These functions may relate to transmission and / or interaction with peripheral devices like for instance a keyboard, a screen, a mouse, etc. (not shown in Figure 2). The processor may run an operating system, such as iOS, Windows, Android, etc. The processor 215 may be a single processor or may comprise two or more processors carrying out the processing required for the operation of the UE 205.

[0106] The I / O controller 255 allows these interactions with external peripherals by providing the hardware required and by managing input and output signals.

[0107] The I / O controller 255 may for example interact with all or part of an image capture device, an image rendering device, an audio capture device, an audio rendering device, or a sensor device able to determine the use position.

[0108] The transceiver 235 is configured to provide bi-directional wireless communication with other wireless devices. For example, it provides the necessary modems (e.g., routers) and frequency shifters necessary to connect to one or more wireless networks, such as Wi-Fi, Bluetooth, LTE, 5G NR, etc. The transceiver 235 may comprise a PDCP transmitter and a PDCP receiver. The PDCP transmitter and the PDCP receiver may be implemented by the processor 215. The PDCP transmitter and the PDCP receiver may be a software only function implemented by the processor 215.

[0109] The radio communications use the antenna set 245 adapted to the spectrum of the frequency transposed signals, issued from the baseband modems. The antenna set 245 may be limited to one antenna, but preferably it contains several antennas, in order to provide beamforming capability.

[0110] The UE communication manager 220 controls the communication establishment of the UE to a radio access network (RAN). It may also be configured to control the control and release of the UE from the RAN. The UE regularly receives from the base station (e.g., gNB) an indication of the slots which are available for communication between the UE and the base station. Accordingly, the UE is able to determine when and at what frequency it should expect to receive incoming data (e.g., from the gNB). Further, the UE can identify when to send outgoing data, and at what frequency. The UE can determine the transmission / reception of data whether the data belongs to the control plane or the data plane. In one example implementation, the UE communication manager 220 implements the Uu interface.

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

[0112] The base station communication manager 320 is configured to control the communications with a plurality of UEs. It is responsible for the establishment, control, and release of these communications. In an example implementation, the base station communication manager 320 implements the Uu interface. The base station communication manager 320 includes a scheduler that allocates time frequency slots to the different UE communications. Information regarding the schedule of these slots is regularly sent to the involved UEs.

[0113] The core network communication manager 355 manages communications of the base station with the core network. It may provide a standardized NG interface, as defined by the 3GPP standard, to support these communications.

[0114] The transceiver 335 is configured to provide bi-directional wireless communication with other wireless devices. These devices may be UEs, or even other base stations. The transceiver 335 provides the necessary modems and frequency shifters in order to connect to a large number of UEs simultaneously, using different frequency carriers, in Time Division Duplex (TDD) or in Frequency Division Duplex (FDD). The transceiver 335 may include a PDCP transmitter and a PDCP receiver. The PDCP transmitter and the PDCP receiver may be implemented by the processor 315. The PDCP transmitter and the PDCP receiver may be a software only functions implemented by the processor 315. The transceiver 335 is connected to the antenna set 345, which may be limited to one antenna, but preferably it contains several antennas, in order to provide beamforming capability.

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

[0116] The inter-station communication manager 365 manages the communications with other base stations. The inter-station communication manager 365 may provide a standardized Xn interface (e.g., as defined by the 3GPP standard), to support these communications.

[0117] Figure 4 is a block schematic diagram illustrating the data plane protocol stack of a 5G NR systems as represented in Figure 1. The data plane protocol stack is described in detail in 3GPP document TS 23.501. In the downlink direction, an application server 103 connects to the user plane function (UPF) 161 through a data network 160 at the level of PDU layer 402. The PDU layer corresponds to the PDUs carried between the UE and the data network (DN) over the PDU session. When the PDU session type is IPv4 or IPv6 or IPv4v6, the PDUs correspond to IPv4 packets, IPv6 packets, or both. When the PDU session type is Ethernet, the PUDs correspond to Ethernet frames; etc. At the start of a PDU session (i.e. , at a PDU establishment time), the core network provides session QoS parameters to the UPF, gNB and UE. The PDU session QoS parameters includes the XR PDU set QoS parameters (S2- 2302696):

[0118] A. PDU Set delay budget (PDSB);

[0119] B. PDU Set error rate (PSER); and

[0120] C. PDU Set integrated handling indication (PSI HI), which is also previously known as a PDU Set integrated indication.

[0121] In the description relating to Figure 4, unless stated otherwise, a PDU refers to a packet which is handled (e.g., managed or processed) by the PDU layer 402. The other types of PDU are handled by the other layers. Accordingly, the PDUs belonging to one of the other layers (i.e., other than the PDU layer 402) is referred to herein with the prefix corresponding to the respective layer name, e.g., a PDCP PDU, or MAC PDU.

[0122] When the PDUs arrive at the UPF PDU layer 402, the UPF performs an application packet inspection to determine the PDU Set boundaries. For example, 3GPP document S2- 2302696 provides examples on how to identify PDU Sets when inspecting RTP / SRTP header, RTP header extension, H.264 RTP payload, H.265 RTP payload and H.266 RTP payload.

[0123] PDU Set identification information as described in 3GPP document S2-2303842 is determined by the UPF and sent to the NG-RAN in the GTP-U header. The PDU Set identification Information comprises: A. a PDU Set sequence number;

[0124] B. an indication of the end PDU of the PDU Set;

[0125] C. a PDU sequence number within a PDU Set;

[0126] D. a PDU Set size; and

[0127] E. a PDU Set importance, which identifies the relative importance of a PDU Set compared to other PDU Sets within a QoS flow.

[0128] During uplink the application is located on the UE. The UE obtains the PDU session QoS parameter from the core network when the PDU session is established (e.g., PDU session establishment procedure is defined in TS 23.502 clause 4.3.2.). When the PDU(s) generated by the application 403 arrive at UE PDU layer 402, the UE performs an application packet inspection to determine the PDU Set boundaries (similar to the procedure described above regarding the UPF).

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

[0130] During downlink, the UPF detects the PDU Set identification information and obtains from the core network a set of mapping rules (e.g., filtering rules). The filtering rules define how each PDU Set is mapped to a QoS flow. The, or each, QoS flow is identified by an identifier, and the GTP-U PDUs are marked according to the determined QoS flow identifier. At the gNB, the relay layer 406 extracts PDU Set identification information and the QoS flow identifier from the GTP-U PDUs and maps them into the SDAP QoS flow(s). 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 a first alternative arrangement, each SDAP QoS flow can be mapped to a different PDCP Data Radio Bearer (DRB). According to a second alternative arrangement, all of the SDAP QoS flows from the same XR session can be mapped to a PDCP DRB (e.g., a single PDCP DRB).

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

[0132] During downlink, the application layer 103 generates at least one application flow toward at least one UE (e.g., a single UE), for example one or more video flows and one or more audio flows. Then at the PDU layer 402, the application flows are arranged in PDU Sets. Each application flow is divided into multiple PDU Sets of the same, or different, types. Then, within the GTP-ll layer 404, each PDU Set type is mapped onto the QoS flows, so multiple application flows can be multiplexed in a QoS flow (e.g., a single QOS flow). Alternatively, each application flow can be mapped to a different QoS flow. Further alternatively, it is also possible that an application flow is divided into multiple QoS flows. Then the SDAP layer 407 maps the QoS flows into DRBs, each DRB being handled (e.g., managed or processed) by a dedicated PDCP entity. As with the QoS flows, multiple application flows can be multiplexed in a single DRB. Alternatively, each application flow can be mapped to a different DRB. Further alternatively, it is also possible that an application flow (e.g., a single application flow) can be divided into multiple DRBs.

[0133] During uplink, the application layer 403, generates at least one application flow towards the application server 103, for example one or more video flows, one or more audio flows, one or more sensing flow. Then at the PDU layer 402, the application flows are arranged in PDU Sets. At least one, or each, application flow is divided in multiple PDU Sets of same or different types and each PDU Set type is mapped on QoS flows, so multiple application flows can be multiplexed in one QoS flow, or each application flows can be mapped to different QoS. It is also possible that an application flow is divided into multiple QoS flows. Then the SDAP layer 407 maps the QoS flows into DRBs. At least one, or each, radio bearer is handled (e.g., managed or processed) by a dedicated PDCP entity. As for the QoS flow, multiple application flows can be multiplexed in one DRB (e.g., a single DRB), or each application flow can be mapped to separate DRBs. Further alternatively, it is possible that an application flow (e.g., a single application flow) is divided into multiple DRBs.

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

[0135] According to a known network configuration, for scheduling uplink traffic, the gNB MAC layer 410 is arranged to allocate radio resources to a UE (e.g., at least one or each UE) based on at least one of the following mechanisms:

[0136] A. dynamic request scheduling issued by each UE (i.e., wherein the UE dynamically issues a request for radio resources);

[0137] B. semi static scheduling by the gNB (i.e., wherein the gNB is configured to issue periodic resource allocation to at least one UE); and

[0138] C. buffer status reporting by at least one UE (i.e., wherein the UE generates a buffer status report (BSR) which indicates the amount of data available for uplink transmission).

[0139] The BSR mechanism (C) has the potential to reduce overheads within the network, compared to the other mechanisms (A and B) since it reduces the need for periodic transmissions between the gNB and UE (e.g., as required by mechanism B) and it also reduces the computational load at the UE (e.g., unlike mechanism A).

[0140] The buffer status reporting mechanism operates on the basis of a logical channel group

[0141] (LCG), which means that the buffer status of a group of logical channels (LCH) is reported together. An LCG (e.g., a single LCG) can be mapped onto multiple MAC logical channels

[0142] (LCH), of which the BSR triggering conditions and formats are defined in 3GPP document TS 38.321. The gNB receives the BSR report and, using this knowledge, the gNB is able to perform resource scheduling. For example, the gNB may decide to favour the LCGs with the most data available whilst preventing resource starvation on low throughput LCGs.

[0143] In certain situations, some of the XR data may have a PDU Set Delay Budget (PDSB) which must not be overrun because it then becomes obsolete (e.g., useless to the decoder) after the delay period has elapsed. For example, when a PDU Set is sent over a 5G network some information may be available regarding the reception status of the PDUs and the elapsed time of the PDSB. The gNB can detect whether a PDU transmission has failed (e.g., despite attempted retransmissions and error correction mechanisms). If the decoder can only handle (e.g., manage or process) a complete application data packet which is received on time (e.g., if the PSIHI is “true”) then any remaining PDUs of the PDU Set (i.e., the PDUs still pending transmission) after the delay period has elapsed are useless to the decoder.

[0144] However, the BSR mechanism does not provide any indication of the delay period for PDUs to be transmitted by the UE. Further, the BSR mechanism operates on LCG, and multiple PDU Sets can be multiplexed in a single logical channel (LCH). Therefore, if delay information were included with the BSR report, the reported buffered data would then be associated with (multiple) delay periods that are potentially different (e.g., because they belong to different PDU Sets). Accordingly, even if delay information were somehow included in the BSR report, it would not improve the allocation of resources by the gNB.

[0145] According to the present disclosure, a method for allocating radio resources within a communication network (e.g., a mobile telecommunications network) is envisaged which overcomes the problems with the BSR mechanism. Specifically, the radio resource allocation is performed by the MAC layer of the communication network. The method involves a delay status reporting mechanism wherein at least one, or each, UE is configured to indicate the amount of data to be transmitted (e.g., during uplink to the gNB) and also the remaining time in which to execute the transmission.

[0146] Advantageously, the delay status reporting mechanism enables the scheduler to have knowledge of the remaining time left (e.g., the remaining PDSB) for the XR data when taking scheduling decisions, so that it can identify which PDU sets to abandon (e.g., so that they are not transmitted by the UE) in order to save network resources. It is noted that the buffer status reporting mechanism and delay status reporting mechanism are not mutually exclusive and so may be used in conjunction. For example, the BSR mechanism may be used on legacy LCG (e.g., for applications where the decoder can handle application data packets which are not received on time) and the delay status reporting mechanism may be used on delay sensitive LCG.

[0147] The application and advantages of the delay status reporting mechanism will now be described with reference to Figures 1 and 4. During downlink the PDU Set identification information calculated by the core network UPF 161 are inserted in the GTP-ll header 404 (e.g., GPRS Tunnelling Protocol - User Plane, as described in TS 29.281). The GTP-U is the protocol used by the UPF to transport data from the core network 102 (which includes the UPF, as shown in Figure 1) to the gNBs 110, 111. When the PDUs (which are transmitted from the core network via the GTP-U tunnel) arrive at the gNBs 110, 111 , the GTP-U header 404 is removed. This means that the PDU Set identification information is not transmitted on to the UE 101 , 151 via the SDAP layer 407 (e.g., the Service Data Adaptation layer, as described in TS 37.324). In this way, the PDU Set identification information is not provided “in- band” during downlink from the gNB to the UE. Consequently, the UEs 101 , 151 (i.e., the receiving side during downlink) do not have access to the PDU Set identification information.

[0148] During uplink, the PDU Set identification information (e.g., which is calculated by the UE PDU layer 402) is not inserted in any header, as shown in Figure 4. So, the PDU Set identification information is not provided “in-band” during uplink from the UEs 101 , 151. Hence, the gNBs 110, 111 (i.e., the receiving side during uplink) do not have access to the PDU Set identification information.

[0149] To summarize, at all protocol layers (including the PDCP layer 401), the receiving entity does not have knowledge of the PDU Set identification information, whether during downlink or uplink. On the transmit side, all of the layers below the SDAP layer 407 do not have access to “in-band” PDU Set identification information. However, an internal mechanism can be used to associate “out-band” PDU Set delimitation information to each PDU which is to be transmitted. An example of such an internal mechanism may use PDU context information to determine PDU Set delimitation information.

[0150] According to an exemplary method during downlink, at the gNBs (i.e., the transmitter sider) the GTP-U receiving entity 404 can associate “out-band” PDU Set delimitation information to each PDU, and pass the delimitation information onto to the PDCP transmitting entity 401. The PDU Set delimitation information is thereby passed from the gNB to the UE via the PDCP layer 401. Subsequently, during uplink, the PDU layer 402 (of the UE) associates the “out-band” PDU Set delimitation information to each PDU and passes the information on to the UE PDCP transmitting entity 401 (e.g., ready for transmission to the gNB).

[0151] Further details of the delay status reporting mechanism will now be described with reference to Figure 5, Figure 6, Figure 7, Figure 8, Figure 9, Figure 10, and Figure 11.

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

[0153] Figure 5 is a flow chart showing the steps of method 500 which is executed at the UE PDCP layer 401 to send uplink traffic to the MAC layer 410 through the RLC layer 408 (as shown in Figure 4). For each DRB (e.g., data radio bearer) 153, 154 the UE executes at least one instance of the method defined as follows:

[0154] An initial method step 501 involves the UE 101 , 151 receiving a PDCP DRB configuration from the gNB 111. The PDCP DRB configuration includes at least one discard timer (e.g., a “PDU Set discard timer” value and / or a “PDU discard timer” value).

[0155] At a second method step 502, the UE 101 , 151 receives a first PDU of a PDU Set from an upper layer of the protocol stack of the UE (e.g., the SDAP layer 407 as shown in Figure 4).

[0156] At a third method step 503, the UE 101 , 151 sends 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).

[0157] A fourth method step 504 comprises the UE 101 , 151 waiting to receive 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 the RLC layer 408).

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

[0159] A. the last PDU of the PDU is received; and

[0160] B. the PDU Set is discarded (e.g., because the discard timer elapsed).

[0161] If every PDU from the PDU Set has been received (i.e., PDU Set reception has finished), the notification is indicative of the end of PDU Set. If the discard timer has elapsed, then the notification is configured to indicate that the PDU Set is to be discarded. In this way, the transmission and contents of the notification are configured in dependence on the above criterion having been satisfied. Finally, method continues with the UE 101 , 151 circling back to method step 502 for the reception of a new PDU Set.

[0162] Some PDU Sets contain only on PDU, for example pose information can be carried in a single PDU which leads to the creation of one section. It will be appreciated that pose information may include the position and orientation information relating to an object in three dimensions. 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 into the virtual object based on its perceived position and orientation in the environment.

[0163] Figure 6 is a flow chart showing the steps of method 600 which is executed at the UE MAC layer 410. The method 600 controls the reception of data for a single logical channel group (LCG). For each LCG, the UE MAC layer 410 executes at least one instance of the following method:

[0164] An initial method step 601 involves the UE receiving a configuration from the gNB 111. The configuration includes information indicative of the grouping of logical channels (LCH) into logical channel groups (LCG) of the MAC layer (i.e., an LCG (or MAC LCG) configuration).

[0165] The method continues with 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 of a PDU set (e.g., as determined in method step 502 of Figure 5), then the method proceeds to method step 605 with the UE obtaining the associated discard timer value (e.g., as sent during method step 503 of Figure 5). The UE compares the obtained discard timer value with the remaining timer value of the existing sections. If the obtained discard timer value matches the remaining timer value of one of the existing sections of the LCG, then the new PDU Set is associated with the existing section. The amount of data buffered for the PDU Set will be added to the buffer size of the existing section.

[0166] According to an embodiment the obtained timer value matches the remaining timer value when the obtained timer value is equal to the remaining timer value.

[0167] Alternatively, the obtained timer value may be configured to match the remaining timer value when the obtained discard timer value is included within an interval of the remaining timer value. In this way, the interval value may define an absolute difference (e.g., + / - 10 ms) or relative difference (e.g., + / - 10%) between the obtained timer value (i.e., of the PDU Set) and the remaining timer value (i.e., of the section). Accordingly, the timer values do not have to be equal to each other in order to match according to the methods disclosed herein. In such situations (i.e., where the obtained timer value is almost equal to (e.g., slightly larger, or smaller than) the remaining timer value, then the remaining timer value may be configured according to at least one of the following criteria: A. the remaining timer remains unchanged;

[0168] B. the remaining timer is set to the mean value between the obtained timer value and the remaining timer value; and

[0169] C. the remaining timer is set to the lowest, or greatest value of the timer values.

[0170] If the obtained discard timer value does not match the remaining timer value of any existing section, then the following method steps are executed at the UE:

[0171] A. creating a new section of the LCG;

[0172] B. starting a remaining timer for the new section, the new timer is set to the obtained discard timer value; and

[0173] C. associating the new PDU with the new section (e.g., the amount of data buffered for the PDU Set will be added to the buffer size of the new section).

[0174] According to an embodiment, if a new section cannot be created (e.g., because the UE has run out of section identifiers) then the new PDU Set is assigned to the section with the closest remaining timer value to the obtained timer value.

[0175] If the received PDU is a subsequent PDU of a PDU Set (e.g., as described in method step 504 of Figure 5), then at method step 603 the UE adds the PDU size to the buffer size of the corresponding section.

[0176] If the received PDU is the last PDU of a PDU Set, or if the PDU Set is being discarded by other layers (e.g., as described in method step 505 of Figure 5), then at method step 604 the UE dissociates the PDU Set from its existing section. If there are no other PDU Sets associated with its existing section, then the section is unallocated (e.g., it remains empty, or free).

[0177] Throughout this disclosure, the term “section” defines a portion, or part, of the LCG (i.e., logical channel groups). The section may, alternatively, be referred to as a “bucket”, “PDU Set”, “burst”, “chunk”, or “part”, without departing from the scope of the present disclosure.

[0178] Figure 7 is a flow chart illustrating a method 700 which is executed at the UE MAC layer 410 (as shown in Figure 4) when a delay status reporting mechanism is triggered.

[0179] An initial method step 701 involves the UE initiating the delay status reporting mechanism in dependence on identifying one or more delay status reporting trigger conditions. The delay status reporting trigger conditions are summarized as follows:

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

[0181] B. during uplink, resources for sending a MAC PDU are allocated and the number of padding bits is equal to or larger than the size of a delay status report (DSR);

[0182] C. a first (retry) timer expires (e.g., retxDSR-Timer), such that when a delay status reporting transmission fails the timer is set so that the delay status reporting transmission is attempted at a different time (as described below with reference to method step 707);

[0183] D. a second (periodic) timer expires (e.g., periodicDSR-Timer), such that the gNB can configure the UE to use this timer to send periodic delay status reports; and

[0184] E. a time value remaining once at least one section of the LCG has reached at least one threshold.

[0185] Similar trigger conditions may be associated with the buffer status reporting mechanism (e.g., as defined in 3GPP document TS 38.321 , clause 5.4.5).

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

[0187] A third method step 703 involves the UE receiving the delay information and the buffer size of a previously created (and skipped) section. The UE uses the delay information and the buffer size to update corresponding reports for the existing (e.g., skipped) sections of the LCG.

[0188] At a fourth method step 704, the UE analyses the available radio resources for sending a Delay Status Report (DSR), then the UE calculates how many section reports can be concatenated in the available radio resources.

[0189] In general, the DSR defines a message from the UE to the gNB which outlines the amount of data, and its associated delay budget, which is available for uplink transmission. According to an exemplary arrangement, the purpose of the DSR is to assist, or guide, the gNB with scheduling resource allocation to enable uplink data transfer). The DSR may be configured with various formats, as will now be described with reference to Figure 9a, Figure 9b, Figure 10 and Figure 11.

[0190] If the available radio resource is greater or equal to the size of a short DSR format and less than the minimum size of a long DSR format, then there is only room for reporting one section by using the short DSR format. If the available resources are greater or equal to the minimum size of a long DSR format then 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. In embodiments, if the available radio resource is greater or equal to two bytes and less than six bytes then there is only room for reporting one section by using the short DSR format. If the available resources are greater or equal to six bytes, then at least two sections from the same LCG can be reported using the long DSR format. If the available radio resource is greater or equal to seven bytes, then at least two sections from two different LCGs can be reported using the long DSR format.

[0191] When the UE has only one section of the LCG to report, then the DSR format is called a short DSR format. If the UE has to select one section among a plurality of sections (or one section from a plurality of LCGs), then the DSR message is called a short truncated DSR format (see Figure 9a). Accordingly, both the short DSR format and the short truncated DSR format are functionally the same type of DSR message with a different name.

[0192] When the available radio resources match all of the LCG and its sections that are available to be reported, then the DSR message of Figure 10 is called a long DSR format. If the UE has to select one section among a plurality of sections (or one section from a plurality of LCGs), then the DSR message of Figure 10 is called a long truncated DSR format. Accordingly, both the long DSR format and the long truncated DSR format are functionally the same type of DSR message with a different name.

[0193] In context of integrated access and backhaul (I AB) the DSR mechanism may be used for communication between the respective lAB-nodes. For example, an lAB-mobile termination (IAB-MT) may provide its parent IAB distributed unit (lAB-parent-DU), or an IAB donor DU (lAB-donor-DU) with information about the amount of data, and its associated delay budget, that can be expected to arrive at the IAB-MT from a child node and / or a UE (i.e. , which is connected to the IAB-MT).

[0194] In embodiments, if the maximum number of LCGs is greater, then the DSR format is called an extended short DSR format (as shown in Figure 9b). If only one section is selected among a plurality of sections (or one section from a plurality of LCGs), then the DSR message is called an extended short truncated DSR format (see Figure 9b). When the available radio resources match all of the LCG and its sections that are available to be reported, then the DSR message is called an extended long DSR format (as shown in Figure 11). If one section is selected among a plurality of sections (or one section from a plurality of LCGs), then the DSR message of Figure 11 is called an extended long truncated DSR format.

[0195] The method 700 proceeds with a fifth method step 705 in which, if all the candidate LCG and sections cannot fit into the available radio resources, the UE performs a selection of the LCG and sections according to multiple criteria. The selection criteria may include:

[0196] A. a remaining time of each section;

[0197] B. a novelty status of each section (e.g., new versus existing section); C. a PDU Set Importance (PSI) value associated with the PDU Set(s) of each section; and

[0198] D. a PSIHI QoS parameter associated with the PDU Set(s) of each section.

[0199] The UE configures the status of the non-selected new sections so that they are characterised as “skip” sections.

[0200] In a first exemplary method, a “skip” section from an LCG is selected (e.g., a plurality, or all, of the skip sections from the LCG, optionally from all of the LCGs). Then, if there is any room remaining after the first selection, a “new” section from the LCG is selected (e.g., a plurality, or all, of the new sections from the LCG, optionally from all of the LCGs). If there is room left after the second selection, then a section with new data, from the LCG, is selected (e.g., a plurality, or all, of the sections with new data from the LCG, optionally from all of the LCGs). If there is room left after the third selection, then a remaining section (i.e., of any type) from the LCG is selected (e.g., a plurality, or all, remaining sections from the LCG, optionally from all of the LCGs). By implementing this method, the UE makes sure that the gNB always receives the delay information of the sections as early as possible. Accordingly, the gNB is able to monitor the status of the LCG by itself and determine the remaining time for each section. As a result, the gNB is able to take anticipated actions so that the delay information is never late.

[0201] According to a second exemplary method, the first selection comprises identifying one or more sections with new data from the LCG (e.g., a plurality, or all, of the sections with new data, optionally from all of the LCGs). Then, one or more sections are selected with the most critical remaining time, among the sections identified in the first selection. This first selection may include (indifferently) any of the new, skip and existing sections. Subsequently, if there is room left after the first selection, a second selection is made which includes a remaining “skip” section from the LCG (e.g., a plurality, or all, of the remaining skip sections from the LCG, optionally from all of the LCGs). Then, if there is room after the second selection, a third selection is made which includes a remaining “new” section from the LCG (e.g., a plurality, or all, of the remaining new sections from the LCG, optionally from all of the LCGs). If there is room left after the third selection, then a remaining section with new data, from the LCG, is selected (e.g., a plurality, or all, of the sections with new data from the LCG, optionally from all of the LCGs). If there is room left after the fourth selection, then any remaining section (i.e., of any type) from the LCG is selected (e.g., a plurality, or all, of the remaining sections from the LCG, optionally from all of the LCGs). By implementing this second exemplary method, the UE can ensure that the gNB receives an update of the buffer size (and delay budget) of the most critical section as early as possible. This is particularly advantageous in the case of a late arrival of a large burst on a delay critical channel. In a third exemplary method, at least one section with new data from an LCG is identified (e.g., a plurality, or all, of the sections from the LCG, optionally all of the LCGs). Then, among these identified sections, a section with the highest critical remaining time to buffer size ratio is selected (e.g., a plurality, or all, of the sections with the highest critical remaining time to buffer size ratio are selected). This selection may include (indifferently) any of the new, skip and existing sections. Then if there is room left after the first selection, then a remaining “skip” section from the LCG is selected (e.g., a plurality, or all, of the remaining skip sections from the LCG, optionally from all of the LCGs). Following the second selection, if there is room left, then a remaining “new” section from the LCG is selected (e.g., a plurality, or all, of the remaining new sections from the LCG, optionally from all of the LCGs). If there is room left after the third selection, then a remaining section with new data, from the LCG, is selected (e.g., a plurality, or all, of the sections with new data from the LCG, optionally from all of the LCGs). If there is room left after the fourth selection, then a remaining section (i.e., of any type) from the LCG is selected e.g., a plurality, or all, of the remaining sections from the LCG, optionally from all of the LCGs). By implementing this third exemplary method the UE ensures that the section with less time (e.g., the smallest delay budget) to send the known buffer size is prioritized.

[0202] For at least one, or each of the above exemplary methods, at each selection step, there may be a need to further arbitrate between the selected sections (e.g., if during the first selection five sections are determined but there is only room for three sections, then further arbitration is required). In this situation, one of the following criteria (or a combination thereof) can be applied to arbitrate which section(s) to keep:

[0203] A. a logical channel priority: the section belonging to an LCG including an LCH with the highest priority may be selected (this will enforce the application MAC level QoS);

[0204] B. a remaining time: the section with the most critical remaining time may be selected (which allows the gNB to obtain the delay information on time);

[0205] C. a ratio of remaining time to buffer size (which favours the sections with less time to send the known buffer size);

[0206] D. PDU Set Importance Information (PSI) associated with the PDU Sets of each section (which favours the most important PDU Sets); and

[0207] E. PDU Set Integrated Importance Information (PSI HI) QoS parameter associated with the PDU Sets of each section (e.g., sections containing PDU Sets with the PSIHI set to false can be skipped, since when the PSIHI is set to false it means the application decoder can handle (e.g., manage or process) the reception of a partial PDU Set).

[0208] For some examples, the DSR triggering is able to follow the same triggers as the BSR because the delay information is sent at section creation time. Accordingly, there is no need for additional triggers to be sent (e.g., such as a dedicated DSR trigger) when the remaining time becomes critical.

[0209] For other examples, the DSR triggering is performed by continuously comparing the remaining time associated to each section with a remaining time threshold configured by the gNB. Thus, the DSR is sent only when the remaining time associated with some of the data has reached a critical level.

[0210] For all examples, if a new section has not been selected, then the UE may change the status of the new section so that it is characterised as a “skip” section.

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

[0212] The formatting of the DSR will now be described with specific reference to Figure 9a, Figure 9b, Figure 10 and Figure 11.

[0213] For all sections, the LCG identification (ID) field 901 , 951 ,1001 , 1101 is configured to include an LGC identifier, which defines the LCG that contains the section (e.g., LCGo, LCGi, LCG2 etc. as shown in Fig. 10).

[0214] For all sections, the section ID field 902, 954, 1002, 1102, is configured to show the section identifier, which defines the section(s) that is / are being reported. The “new” or “skip” sections are configured with a section type identifier, or flag, 903, 953, 1003, 1103, which includes a linguistic term (e.g., “new”) and / or a numerical value (e.g., “1”). The “new” and “skip” sections also have a delay field 905, 955, 1005, 1105, which is set to the remaining timer value associated with the section. The remaining timer value is configured (e.g., adjusted) to the expected time of a first transmission attempt of the DSR. In addition, the “new” and “skip” sections have a buffer size field 904, 954, 1004, 1104, which is set to the buffer size associated with the section.

[0215] The section type identifier for an existing section is configured with a numerical value of “0”, whereas the numerical value is set to “1” for a new (or skipped) section. The existing sections do not have a delay field. Existing sections are configured with a buffer size field 904, 954, 1004, 1104 which is set to a 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., a concatenation of 904 and 905 in Figure 9, 954 and 955 in Figure 9b, 1004 and 1005 in Figure 10, and 1104 and 1105 in Figure 11).

[0216] The use of the “new” identifier means that the different types of section (e.g., “new” and “existing”) can be distinguished from each other (e.g., within a DSR message), which enables the delay information to be sent less frequently thus allowing saving signalling overhead. Systematically sending the section ID even whilst the delay information is not reported advantageously allows the gNB to continuously monitor the delay of sensitive data (e.g., with use of internal counter) based on the reception of the first delay information.

[0217] The method 700 proceeds with method step 707 in which the UE analyses (e.g., checks) whether the previous DSR has been received by the gNB. If the DSR has been successfully received (i.e., the reception status is delivered). If the reception is confirmed, then the UE updates the status of the “new” sections in the previous DSR so that they now are characterised as “existing”.

[0218] If the previous DSR is not received by the gNB (i.e., the reception status is failed), then the UE may start the retxBSR-Timer, which counts down the time until a further attempt is made to transmit the status (request) message. In addition, the UE updates the status of “new” in the previous DSR so that they now are characterised as “skip”.

[0219] Figure 8 is flow chart of a method 800 which is executed at the gNB when a delay status report (DSR) is received (e.g., from the UE). In an initial method step 801 , the gNB receives a DSR according to any one of the formats described above with reference to Figure 9, Figure 10, and Figure 11.

[0220] In a subsequent (optional) method step 802, for each element of delay information contained in the DSR, the gNB adjusts the delay information of the corresponding section as a function of the number of retransmissions needed to receive the DSR. The delay information is referenced to the time of the first transmission attempt. For example, if the MAC PDU containing the DSR has required several PHY retransmissions (e.g., via a hybrid automatic repeat request, HARQ, process or an intra-UE prioritization) in order to be successfully received, then the number of PHY retransmissions may be recorded with the delay information in the DSR to establish the actual time remaining.

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

[0222] In method step 804, the gNB updates the buffer size information relative to each section in the scheduler. In particular, in order to determine the scheduling of the uplink data, the gNB obtains updates from the served UEs. The updates include at least one of the following data types:

[0223] A. available data for legacy logical channel groups through the legacy BSR procedure (e.g., as defined in 3GPP document TS 38.321);

[0224] B. a remaining time value measured from the first section report, and the available data for the corresponding section; and C. updates on the available data.

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

[0226] By implementing remaining time counters for each section, the gNB can closely monitor the evolution of both the available data and remaining time for each section. Hence the gNB is able to perform advantageous scheduling decisions based on complete knowledge of both legacy LCG and time sensitive LCG with their associated sections.

[0227] In embodiments, the gNB configures the UE through dedicated signalling regarding the legacy LCG, the time sensitive LCG, the max number of sections, and the deciding criteria for section selection (e.g., as defined in method step 705 of Figure 7). Alternatively, the delay information may be included in the DSR for each new section and for N following DSR reports of the same section (wherein N is an integer configured by the gNB). Further alternatively, the delay information may be included in the DSR systematically for each new section. Yet further alternatively, the gNB configures the UE in one of the three modes:

[0228] A. delay information for only new sections;

[0229] B. N consecutive delay information from the creation of the section; and

[0230] C. systematic delay information for all sections.

[0231] The gNB configures the UE with one of the three aforementioned modes for each LCG. Each LCG may be managed according to one of the three modes. In this way, the DSR messages for each LCG may exist in several formats.

[0232] Figure 9a is a schematic illustrating a short DSR format and a short truncated DSR format. The short DSR format is used when there is only one LCH (or LCG) to report. The short truncated DSR, which has the same format as the short DSR, is used when the available radio resource is equal to the size of the short DSR format and more than one LCH (or LCG) has data available for transmission. In detail, the message is composed of a LCG ID 901 (e.g., comprising at least 3 bits). The LCG ID field identifies the group of LCH(s) whose delay status is being reported.

[0233] The section ID field 902 identifies the different sections in an LCG (e.g., comprising up to, or at least, 4 bits depending on the embodiment). For the short DSR format and the short truncated DSR format, only one section is reported even if the LCG includes several sections.

[0234] The term “new” in field 901 (e.g., comprising at least 1 bit), indicates whether the section identified by section ID field 902 is new or existing. In this way, the term “new” is an example of an ID bit indicative of whether the section is new or existing. If the section is new, then the associated delay information is reported in field 905 (e.g., comprising up to, or at least, 3 bits) and the associated buffer size is reported in field 904 (e.g., comprising up to, or at least, 5 bits). If the section is not new (i.e., existing) then the delay information is not included, and the buffer size may be reported in 904 only. Alternatively, the buffer size field 904 may be combined with the delay field 905 (e.g., to form a single 8-bit field).

[0235] Figure 9b is a schematic diagram illustrating an extended short DSR and extended short truncated DSR format. The extended short DSR format (e.g., either truncated or not) are used in the context of IAB applications, where there is a need to support a higher number of LCGs.

[0236] When a logicalChannelGrouplAB-Ext (e.g., as defined in 3GPP document TS 38.321) is configured, the extended short DSR format is used when there is only one LCH (or LCG) to report.

[0237] When the logicalChannelGrouplAB-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 resource is equal to the size of the extended Short DSR format, and more than one LCH (or LCG) has data available for transmission. In detail, the message is composed of a LCG id 951 (at least Sbits). The LCG ID field identifies the group of LCH(s) whose delay status is being reported.

[0238] The section ID field 954 identifies the different sections in one LCG (e.g., comprising up to, or at least, 4 bits depending on the embodiment). For the extended short DSR format and the extended short truncated DSR format, only one section is reported even if the LCG includes several sections.

[0239] The term “new” in field 953 (e.g., comprising at least 1 bit), indicates whether the section identified by section ID field 954 is new or existing. If the section is new, then the associated delay information is reported in field 952 (e.g., comprising up to, or at least, 3 bits) and the associated buffer size is reported in field 955 (e.g., comprising up to, or at least 8 bits). If the section is not new (i.e. , existing) then the delay information is not included, and the buffer size may be reported in field 954 only. Alternatively, the fields 954 and 955 may be combined as a single field (e.g., comprising at least 12 bits).

[0240] Figure 10 is a schematic diagram illustrating a message format used either as a long DSR format, or a long truncated DSR format, or a pre-emptive DSR format. The long DSR format is used when multiple LCGs are reported, and the available radio resource is equal to the necessary size to report all the LCGs. The long truncated DSR format is used when multiple LCGs are reported, and the available radio resource is more than a short DSR format but less than the necessary size to report all of the LCGs. The pre-emptive DSR format is used in the IAB context.

[0241] In detail, the message is composed of 8 (eight) LCGs flags, one for each of the corresponding LCGi (e.g., LCG0-7). The field 1001 indicates the presence of the delay status report for the corresponding LCGi. If the numerical value in the field 1001 (i.e., LCGi field) is set to 1 then this indicates that the delay status for the LCGi is “delivered” (i.e. , reported). If the field 1001 is set to 0, this indicates that the delay status for the LCGi not reported

[0242] The LCG delay statuses are included in ascending order based on the LCGi. A delay status (e.g., 1006, 1007) of one LCG includes delay information for all sections in the LCG. LCG delay statuses are reported k times, where k is the number of LCGs being reported (i.e., equal to the number of LCGi bits set to one).

[0243] Initially, a section bitmap 1002 indicates the presence of the delay status for each section, Si (e.g., S0-7). If the Si field is set to 1 , this indicates that the delay status for the corresponding section (e.g., Si) is reported. If the Si field is set to 0, this indicates that the delay status for the corresponding section (e.g., Si) is not reported.

[0244] For at least one, or each section, the status report includes the term (or flag) “new” in field 1003 (e.g., comprising at least 1 bit), which indicates whether the section is new or existing. If the section is new, then the associated delay information is reported in field 1005 (e.g., comprising up to, or at least, 7 bits) and the associated buffer size is reported in field 1004 (e.g., comprising up to, or at least, 7 bits). If the section is not new (i.e., existing) then the delay information is not included, and the buffer size may be reported only in field 1005. Alternatively, the fields 1004 and 1005 may be combined as into a single field (e.g., comprising 15 bits). In some embodiments, when the section is not new (i.e., existing), the buffer size is reported only in field 1005 (e.g., comprising 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 one.

[0245] Figure 11 is a schematic diagram illustrating a message format used either as an extended long DSR format, or an extended long truncated DSR format, or an extended preemptive DSR format. Each of messages shall be used when logicalChannelGrouplAB-Ext is configured (e.g., as defined in 3GPP document TS 38.321). The extended long DSR format is used when multiple LCGs are reported, and the available radio resource is equal to the necessary size to report all the LCGs. The extended long truncated DSR format is used when multiple LCGs are reported, and the available radio resources are more than a short DSR format, but less than the necessary size to report all of the LCGs. The extended pre-emptive DSR may be used in the IAB context.

[0246] In detail, the message is composed of a 256 LCG flags, for each of the LCGi. The field 1101 indicates the presence of the delay status report for the corresponding LCGi. Field 1101 (i.e., LCGi field) is set to 1 , which indicates that the delay status for the LCGi is “delivered” (i.e., reported). If the numerical value in the field 1101 is set to 0, this indicates that the delay status for the LCGi is not reported. The LCG delay statuses are included in ascending order based on the LCGi, a delay status (e.g., in fields 1106, 1107) of one LCG includes delay information for all sections in the LCG. The LCG delay statuses are reported k times, where k is the number of LCHs being reported (i.e., equal to the number of LCGi bits set to one).

[0247] Initially, a section bitmap 1102 indicates the presence of the delay status for each section, Si e.g., S0-7). If the Si field is set to 1 , this indicates that the delay status for the corresponding section (e.g., Si) is reported. If the Si field is set to 0, this indicates that the delay status for the corresponding section (e.g., Si) is not reported.

[0248] For at least one, or each section, the status report includes the term “new” in field 1103 (e.g., comprising at least 1 bit), which indicates whether the section is new or existing. If the section is new, then the associated delay information is reported in field 1105 (e.g., comprising up to, or at least, 7 bits) and the associated buffer size is reported in field 1104 (e.g., comprising up to, or at least, 7 bits). In case the section is not new (i.e., existing) then the delay information is not included, and the buffer size may be reported in 1105. The buffer size may be reported in a combined field formed of 1104 and 1105 (e.g., comprising 15 bits). In embodiments, when the section is not new (i.e., existing), the buffer size is reported only in field 1105 (e.g., comprising 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 one.

[0249] Although the embodiments of the present disclosure have been described in relation to PDlls (and PDU Sets), the present disclosure is not limited to this type of PDU. The methods of the present disclosure can be applied to the transmission and reception of any sequenced PDlls, in particular, the present disclosure is applicable to in-sequence PDU transmission on any layer.

[0250] Whilst the present disclosure has been described with reference to examples and embodiments, it is to be understood that the disclosure is not limited to the disclosed examples and embodiments. It will be appreciated by those skilled in the art that various changes and modification might be made without departing from the scope of the disclosure, as defined in the appended claims.

[0251] All of the features disclosed in this specification (including any accompanying claims, abstract and drawings), and / or all of the steps of any method or process so disclosed, may be combined in any combination, except combinations where at least some of such features and / or steps are mutually exclusive. Each feature disclosed in this specification (including any accompanying claims, abstract and drawings) may be replaced by alternative features serving the same, equivalent or similar purpose, unless expressly stated otherwise. Thus, unless expressly stated otherwise, each feature disclosed is one example only of a generic series of equivalent or similar features.

[0252] In the claims, the word “comprising” does not exclude other elements or steps, and the indefinite article “a” or “an” does not exclude a plurality. The mere fact that different features are recited in mutually different dependent claims does not indicate that a combination of these features cannot be advantageously used.

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

[0254] Computer-readable media may include computer-readable storage media, which corresponds to a tangible medium such as data storage media, or communication media including any medium that facilitates transfer of a computer program from one place to another, e.g., according to a communication protocol. In this manner, computer-readable media may correspond to (1) tangible computer-readable storage media which is non-transitory or (2) a communication medium such as a signal or carrier wave. Data storage media may be any available media that can be accessed by one or more computers or one or more processors to retrieve instructions, code and / or data structures for implementation of the techniques described in this disclosure. A computer program product may include a computer-readable medium.

[0255] By way of example, and not limitation, such computer-readable storage media can comprise RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage, or other magnetic storage devices, flash memory, or any other medium that can be used to store desired program code in the form of instructions or data structures and that can be accessed by a computer. Also, any connection is properly termed a computer-readable medium. For example, if instructions are transmitted from a website, server, or other remote source using a coaxial cable, fibre optic cable, twisted pair, digital subscriber line (DSL), or wireless technologies such as infrared, radio, and microwave, then the coaxial cable, fibre optic cable, twisted pair, DSL, or wireless technologies such as infrared, radio, and microwave may be included in the definition of medium. It should be understood, however, that computer- readable storage media and data storage media do not include connections, carrier waves, signals, or other transient media, but are instead directed to non-transient, tangible storage media. Disk and disc, as used herein, includes compact disc (CD), laser disc, optical disc, digital versatile disc (DVD), floppy disk and Blu-ray disc, where disks usually reproduce data magnetically, whilst discs reproduce data optically with lasers. Combinations of the above should also be included within the scope of computer-readable media.

Claims

CLAIMS1 . A method for reporting a buffer status of data to be transmitted over a logical channel group, LCG, of a communication network, the communication network comprising a user equipment and a base station, the method at the user equipment comprising: determining a plurality of sections for associating with a plurality of protocol data unit Sets, PDU Sets, based on timing information of the plurality of PDU Sets; and transmitting a status report for reporting the buffer status of the plurality of sections to the base station, wherein the status report comprises, for at least one section, a buffer size value indicative of the amount of data of at least one PDU Set associated with the at least one section, and a timer value of the at least one section.

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

3. The method of claim 1 or claim 2, wherein the status report is transmitted following the determination of at least one of the plurality of sections.

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

5. The method of any one of claims 1 to 4, wherein the method further comprises: transmitting an updated status report comprising, for the at least one section, a buffer size value indicative of the current amount of data of the at least one PDU Set.

6. The method of any one of claims 1 to 5, wherein the method comprises transmitting, after the first status report, a second status report which does not comprise a timer value.

7. The method of any one of the preceding claims, wherein the method of determining the plurality of sections comprises generating a new section when the duration of an existing section expires.

8. The method of any one of the preceding claims, wherein the method comprises grouping two or more PDU Sets with matching timing information into a single section.

9. The method of claim 8, wherein the timing information includes a discard timer value of the PDU Set, wherein the method comprises: comparing a discard timer value of a PDU Set with the timer value of a section of the plurality of sections; associating the PDU Set with the section if the section timer value matches the discard timer value of the PDU Set; and adding a size value indicative of the amount of data associated with the PDU Set to the buffer size value of the section.

10. The method of claim 8 or claim 9, wherein the method comprises: comparing a discard timer value of a PDU Set with the timer value of a section of the plurality of 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 which corresponds to the discard timer value; and adding a size value indicative of the amount of data associated with the PDU Set to the buffer size value of the new section.

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

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

13. The method of any one of claims 8 to 12, wherein the method comprises: before comparing the discard timer value with the section timer value, determining the configuration of a PDU within the PDU set; and determining the discard timer if the PDU is the first PDU of the PDU set.

14. The method of 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 of any one of claims 8 to 14, wherein, if a PDU is the last PDU of a PDU Set, or if the PDU Set is discarded by another layer of the protocol stack, then the PDU set is discarded from the section.

16. The method of any one of the preceding claims, wherein the method comprises transmitting the status report in dependence on receiving an indication that a decoder of the network is incapable of decoding data which is not received within a predetermined time period.

17. The method of any one of the preceding claims, wherein the status report is transmitted in dependence on determining a delay status reporting trigger, wherein the delay status reporting trigger satisfies at least one of the following conditions: data becoming available to another layer of the protocol stack for at least one logical channel of the logical channel group; resources for sending a PDU are allocated to another layer of the protocol stack, and the buffer size value of a present status report is at least the size of a buffer size value of a previous status report; a retry timer expires, wherein the retry timer defines a period after which the status reporting transmission is attempted if a previous transmission failed; and a periodic timer expires, wherein the periodic timer defines a predetermined period after which the user equipment is configured to transmit the status report.

18. The method of claim 17, wherein the method comprises: determining if one or more new sections have been generated since the last status report trigger condition was identified; and generating at least one new section if data corresponding to a different timer value becomes available in a logical channel of the logical channel group.

19. The method of claim 17 or claim 18, wherein the method comprises: receiving information indicative of a buffer size value and / or a timer value of a previously generated section; and updating the buffer size value and / or a timer value of a new status report based on the received information.

20. The method of any one of the preceding claims, wherein the method comprises: generating an individual section status report for two or more of the plurality of sections; analysing available radio resources for status report transmission; anddetermining, based on the available radio resources, the number of individual section status reports for merging into a combined status report.

21. The method of claim 20, wherein the method comprises, upon determining that at least one of the section status reports cannot be transmitted based on the available radio resources, selecting two or more of the sections based on at least one of the following criteria: a remaining time of each section; a novelty status of each section; a PDU Set importance, PSI, value associated with the data of each section; and a PDU Set integrated importance information, PSIHI, quality of service parameter associated with the data of each section.

22. The method of claim 20 or claim 21 , wherein the method comprises selecting two or more sections according to the following method steps: firstly selecting at least one skipped section; secondly selecting at least one new section; thirdly selecting at least one section with new data; fourthly selecting at least one of the remaining sections.

23. The method of any one of claims 20 to 22, wherein the method comprises selecting two or more sections according to the following method steps: firstly determining one or more sections with new data and then selecting, from the one or more identified sections, at least one section with a critical remaining timer value; secondly selecting at least one skipped section; 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.

24. The method of any one of claims 20 to 23, wherein the method comprises selecting two or more sections according to the following method steps: firstly determining one or more sections with new data and then selecting, from the one or more identified sections, at least one section with the highest critical remaining time to buffer size ratio; secondly selecting at least one skipped section; thirdly selecting at least one new section; fourthly selecting at least one section with new data; andfifthly selecting at least one of the remaining sections.

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

26. The method of any one of claims 22 to 25, wherein for at least one of the selection method steps, the user equipment arbitrates between two or more qualifying sections on the basis of at least one of the following selection criteria: a logical channel priority; a remaining time; a ratio of remaining time to buffer size;PDU Set importance information, PSI, associated with each section; andPDU Set integrated importance information, PSIHI, quality of service parameter associated with each section.

27. The method of any one of the preceding claims, wherein the user equipment receives dedicated signalling from the base station to configure the status reporting transmission, wherein the signalling comprises information regarding at least one of the following: a configuration of a previous logical channel group; a configuration of a time sensitive logical channel group; and a maximum number of sections.

28. The method of any one of the preceding claims, wherein the timer value for all available sections is included in the status report.

29. The method of any one of the preceding claims, wherein only the timer value for a new section is included in the status report.

30. The method of any one of the preceding claims, wherein the timer value for a section is included in the first status report following the generation of the section, and in N subsequent status report(s), wherein N is an integer configured by the base station.

31. A method for reporting a buffer status of data to be transmitted over a logical channel group, LCG, of a communication network, the communication network comprising a user equipment and a base station, the method at the base station comprising:identifying a plurality of sections for associating with a plurality of protocol data unit Sets, PDU Sets, based on timing information of the plurality of PDU Sets; receiving a status report for reporting the buffer status of the plurality of sections to the base station, wherein the status report comprises, for at least one section, a buffer size value indicative of the amount of data of at least one PDU Set associated with the at least one section, and a timer value of the at least one section; and configuring a timer associated with the at least one section based on the timer value.

32. A communication network which comprises: a user equipment configured to perform the method of any one of claims 1 to 30, and / or a base station configured to perform the method of claim 31.

33. A computer program comprising instructions which, when the program is executed by a user equipment, causes the user equipment to carry out the method according to any one of claims 1 to 30, or comprising instructions which, when the program is executed by a base station, causes the base station to carry out the method of claim 31.

34. A computer-readable medium carrying a computer program according to claim 33.

Images