Method for buffer status reporting in a communication network

Abstract

In a communication network for carrying a plurality of protocol data unit (PDU) sets the invention comprises reporting a buffer status of data to be transmitted by transmitting a status report compris

Description

FIELD OF THE DISCLOSURE 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. BACKGROUND 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. 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). 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. 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). 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. 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. 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. 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 (HyperText Transfer Protocol, RFC 2616-7540) or QUIC (RFC 8999, 9000, 9001 and 9002). Video encoding and decoding can be performed according to various formats including MPEG2, H.264, H.265, HEVC, etc. 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. 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. 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. 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). 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. 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. In the same 3GPP document, S2-2302696, another QoS parameter named PDU Set Integrated Handling Indication (PSIHI) 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. 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. 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: - Dynamic request scheduling by each UE; - Semi-static scheduling by the gNB, where the gNB may issue periodic resource allocation to one UE; and - Buffer status reporting (BSR) by each UE indicating the amount of data available for uplink transmission. 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. In certain situations, a plurality of PDU Sets can be multiplexed in a single logical channel. Known BSR reporting methods configure the UE to systematically report the delay of each of a plurality of PDU sets which can cause a considerable overhead within the network. Furthermore, in such situations it may not be appropriate to add delay information to the BSR because the reported buffered data may be associated with delay periods which are potentially different (i.e., because they belong to different PDU Sets). In situations relating to XR application, some of the XR data may have a 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. 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. SUMMARY 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 may be transmitted by way of a status report which is configured (e.g., divided) into a plurality of sections, wherein each of the sections may be configured to enable a plurality of data packets having similar buffer statuses to be associated with the same section. According to aspects of the disclosure (e.g., the first and second aspects), the buffer status report may include, for at least two sections (e.g., a first section and a second section) of the plurality of sections, an indication of the amount of data to be transmitted from each of the at least two sections. The buffer status report is transmitted in dependence on the timing information (e.g., a remaining time value, or a discard timer value) corresponding to at least one of the sections (e.g., one or more of the at least two sections). In this way, the method enables the receiving RAN node to receive a single signal for each channel (e.g., of a logical channel group), and can 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. According to alternative aspects of the disclosure (e.g., the third and fourth aspects), the buffer status report may include (e.g., for at least one, or each, of the plurality of sections) 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. 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 over a logical channel group (LCG) of a communication network. The LCG is suitable for carrying a plurality of protocol data unit sets, PDU Sets, associated with a first section and a second section of the LCG (e.g., the LCG is subdivided into a plurality of sections including the first and second sections), wherein each of the first and second sections is associated with at least one PDU Set. The communication network comprises a user equipment and a base station. The method at the user equipment comprises: transmitting a status report for reporting the buffer status of the first section and the second section to the base station, the status report comprises information indicative of the amount of data associated with the first and second sections (e.g., the first section may be associated with a first PDU Set (e.g., a first plurality of PDU Sets) and the second section may be associated with a second PDU Set (e.g., a second plurality of PDU Sets) which is different to the first PDU Set). The status report is transmitted based on a discard timer value associated with at least one of the first and second sections. 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 of a communication network. The logical channel group is suitable for carrying a plurality of protocol data unit sets, PDU Sets, associated with a first section and a second section of the logical channel group, wherein each of the first and second sections is associated with at least one PDU Set. The communication network comprises a user equipment and a base station. The method at the base station comprises: receiving a status report for reporting the buffer status of the first section and the second section to the base station, the status report comprises information indicative of the amount of data associated with the first and second sections, wherein the status report is transmitted based on a discard timer value associated with at least one of the first and second sections; and configuring a timer associated with at least one of the first and second sections based on the information indicative of the amount of data associated with the first and second sections. As described above, known buffer status reporting methods configure the user equipment to systematically report the delay of every PDU Set, of a plurality of PDU Sets that are multiplexed in a single logical channel. Such known reporting methods can result in significant overheads within the network. Furthermore, it may not be appropriate to add delay information to the buffer status report, since the reported buffered data may be associated with delay periods which are potentially different (i.e., because they belong to different PDU Sets). The method according to the first and second aspects enables the user equipment to transmit a single signal which provides an indication of the data carried by two or more sections of a single channel, so that the base station and can easily predict when a set of data packets will elapse. This advantageously allows network resources to be allocated more efficiently, whilst also reducing the network transmission load. In accordance with a third 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 (LCG) 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 fourth 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 PDUs (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. 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. 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. 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. 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). 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 the legacy logical channel group and the time sensitive logical channel group with their associated sections. 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. 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. 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. 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 value), which may be indicative of when the data packet will elapse, or expire (e.g., a PDU discard timer value, and / or a PDU Set discard timer value). The plurality of sections (e.g., of the LCG) 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). 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). Each of the plurality of sections may be associated with a separate timer. For example, the timer may be set with an initial timer value that is determined by the timing information associated with a PDU Set that is assigned to the respective section. Once the PDU Set is assigned to the section, the section timer may be initiated to count down from the initial timer value. The following paragraphs outline a number of optional features that are particularly relevant to first and second aspects of the present disclosure, but which may also be applied to the other aspects described herein. The status report may be transmitted if the discard timer value associated with at least one, or each, of the first and second sections is up to (e.g., less than (i.e., numerically smaller), or equal to) a predetermined timer threshold value. The status report may be transmitted if the discard timer value associated with the first section is upto (e.g., less than (i.e., numerically smaller), or equal to) the timer threshold value. Optionally, the discard timer value associated with the second section may be more (e.g., greater, or numerically larger) than the timer threshold value. Further, the discard timer value associated with the second section may be within a predetermined range of the timer threshold value. For example, the first section may have reached the threshold (i.e., thereby triggering the report transmission). However, the second section may not have yet reached the threshold value. However, if at the time of the transmitting the status report the discard timer value of the second section is close to the threshold (e.g., such that it will soon reach the threshold), then the information indicative of the data from the second section is included in the status reporting together with the data indication for the first section. In this way, the method minimises the number of reports that are transmitted to the base station, which thereby reduces the overhead within the network. The status report may be transmitted if the discard timer values associated with each of the first and second sections are up to the timer threshold value. Optionally, the discard timer value associated with the first section may be closer to the timer threshold value than the discard timer value associated with the second section. For example, the second section may have just recently reached the threshold value whereas the first section may have reached (and dropped below) the threshold some time ago. Accordingly, the first section may comprise data packets which had been reported in a previous status report. However, one or more of the reported packets may still remain in the first section (and / or further packets may have been added to the first section in the intervening period) and may have not yet expired. As such, these data packets can also be reported when reporting the second section. In embodiments, the status report may include information associated with at least three sections, for example, a first section, a second section and a third section. The status report may be transmitted if: the discard timer values associated with each of the first and second sections are up to the timer threshold value. The discard timer value associated with the first section may be closer to the timer threshold value than the discard timer value associated with the second section. Further, the discard timer value associated with the third section may be more than the timer threshold value (and optionally within a predetermined range of the timer threshold value). The method may comprises transmitting a first status report if the discard timer value associated with the first section is up to (e.g., less than (i.e., numerically smaller), or equal to) the timer threshold value. The first status report may comprise information indicative of the amount of data of the at least one PDU Set associated with first section at the time of the first status report (i.e., at the time of the transmission of the first status report). The first status report may be configured such that it does not comprise information indicative of the amount of data of the at least one PDU Set associated with the second section. For example, the discard timer value of the second section may not have reached (and / or exceeded) the timer threshold value. The method may comprise a subsequent method step (e.g., following the transmission of the first status report), in which a second status report is transmitted if the discard timer value associated with the second section is up to (e.g., less than or equal to) the timer threshold value. The second status report may comprise information indicative of the amount of data of the at least one PDU Sets associated with each of the first section and the second section at the time of the second status report (i.e., at the time of the transmission of the second status report). For example, when the second report is transmitted the discard timer values of each of the first and second sections may have reached (and / or exceeded) the timer threshold value. Even though the first section was reported in the first report, one or more data packets may still remain (i.e., undelivered to the network). In which case, any remaining data packets from the first section can be conveniently reported (i.e., together with the data packets of the second section) in the second status report, thereby providing the network with a more complete picture of the data packets that are associated with the LCG and yet to be transmitted from the user equipment. The timer threshold value may be set by the network (e.g., the base station). The timing information (e.g., discard timer value) of the first section and / or second section may be determined (e.g., generates) by a discard timer. For example, each of the sections may be configured with a respective (e.g., separate) discard timer. The discard timer (e.g., for each of the respective sections) may be initiated when data the respective PDU Set (e.g., that is to be associated with the relevant section) is received by the user equipment (e.g., and / or assigned with the section). The method may comprise, before transmitting the status report, first generating an individual status report for at least one, or each, of the first section and second section. Optionally, the method may comprise merging (e.g., combining and / or concatenating) the individual buffer status reports (i.e., of the first and second sections) to form a single status report (e.g., a combined status report) for transmitting to the base station (e.g., the status report as defined according to the methods of the first and second aspects of the present disclosure). The first section may be associated with a first PDU Set. The second section may be associated with a second PDU Set having timing information which is different to that of the first PDU Set. The method step of transmitting the status report may be stopped (e.g., blocked, or prevented from initiating) if the amount of data (e.g., the total amount of data) of the first section and the second section is below (e.g., less than or equal to) a predetermined data threshold value. The data threshold value may be determined based on the amount of data indicated by a previously transmitted status report. For example, the threshold value may be set to equal the value of the previously transmitted amount of data. The status report may comprise information indicative of the total amount of data associated with the first and second sections. The method may comprise transmitting the status report if the user equipment does not receive, within a predetermined time period, a scheduling grant from the base station. For example, after sending a status report (e.g., a previous status report) the user equipment may not receive a scheduling grant from the base station within a predetermined time period. In this situation, the transmission of the status report (e.g., as defined according to the first and second aspects) may be triggered. Optionally, the status report may be transmitted even if the amount of data is below the data threshold value. The method may comprise determining the first and second sections based on timing information of at least one PDU Set associated with each of the first and second sections, respectively. The method may comprise grouping two or more PDU Sets with matching timing information into a single section. The method may comprise comparing timing information of at least one PDU Set with the discard timer value of the first section and the discard timer value of the second section. Optionally, the method may comprise associating the at least one PDU Set with the first section if the first discard section timer value matches the timing information of the at least one PDU Set. Further optionally, the method may comprise the step of adding information indicative of the amount of data associated with the at least one PDU Set to the first section. The method may further comprise generating a third section of the logical channel group if the timing information of the at least one PDU Set does not match the section timer value of each of the first section and the second section. Optionally, the method may comprise the further method step of starting a timer for the third section which corresponds to the discard timer value (e.g., of the at least one PDU Set). Further optionally, the method may comprise the method step of adding information indicative of the amount of data associated with the at least one PDU Set to the third section. The timing information (e.g., of the at least one PDU Set) may match the discard timer value of the respective section if the timing information is substantially equal (e.g., equal) to the discard timer value (i.e., of the at least one PDU Set). The status report may be configured to provide an indication (e.g., to the base station of the network) that the timing information (e.g., a discard timer value) associated with at least one of the first and second sections is critical (e.g., about to elapse, or expire). This “critical” indication may be provided instead of providing the actual timing information (e.g., a discard timer value) associated with the respective section, which thereby reduces the transmission overhead within the network. The discard timer value for at least one, or each, of the first and second sections may be included in the status report. Optionally, only the discard timer value for a new section is included in the status report. The following paragraphs outline a number of optional features that are particularly relevant to third and fourth aspects of the present disclosure, but which may also be applied to the other aspects described herein. 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. 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. 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. 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). 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). 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. The data for transmission may comprise a plurality of PDUs, 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. 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 PDUPDU Set to the buffer size value of the at least one section. 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. 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. 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. 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. 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. 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. In embodiments (e.g., relating to the first and second aspects of the present disclosure), the at least one trigger conditions may be applied as a supplementary requirement for determining whether to transmit the status report For example, a decision whether to transmit the status report may be made based a discard timer value associated with at least one of the first and second sections, and also in dependence on whether at least one of the trigger conditions is satisfied. 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 at least some of the data has reached a critical level of remaining time. 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. 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. 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. The status of a non-selected section from a previous status report may be characterised as a skipped section. 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 (PSIHI) quality of service parameter associated with the data of each section. 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. 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. 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. 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. 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 PDll 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). The user equipment may receive dedicated signalling from the base station to configure the status reporting transmission. 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. 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. 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). According to the fourth 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. In accordance with a fifth aspect of the present disclosure, there is provided a communication network which comprises a network element (e.g., a base station or UE) configured to perform the methods of any one of the preceding paragraphs (e.g., as defined in relevant parts of the first, second, third, and fourth aspects of the present disclosure, as described herein). In accordance with a sixth 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 in relevant parts of the first, second, third, and fourth aspects of the present disclosure, as described herein). 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. The features of any one of the first, second, third, and fourth 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.). In accordance with a seventh aspect of the present disclosure, there is provided 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 the relevant preceding paragraphs (e.g., as defined in relation to the first and / or third aspects of the present disclosure), or comprising instructions which, when the program is executed by a base station, causes the base station to carry out the method according to any one of the relevant preceding paragraphs (e.g., as defined in relation to the second and / or fourth aspects of the present disclosure). In accordance with an eighth aspect of the present disclosure, there is provided a computer-readable medium carrying a computer program according to the seventh aspect of the present disclosure. 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). 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. 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. 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. 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. 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. BRIEF DESCRIPTION OF THE DRAWINGS Different aspects of the disclosure will now be described, by way of example only, and with reference to the following drawings in which: 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; 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; Figure 4 is a schematic diagram illustrating the data plane protocol stack of a 5G NR system as represented in Figure 1; Figure 5 is a flow chart showing a method executed at a UE PDCP layer of the wireless communication system of Figure 1; Figure 6 is a flow chart showing a method executed at a UE MAC layer of the wireless communication system of Figure 1; 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; 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; Figure 9a is a schematic diagram illustrating a short DSR format and a short truncated DSR format; Figure 9b is a schematic diagram illustrating an extended short DSR and an extended short truncated DSR format; 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; 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 Figure 12 is a flow chart showing an alternative method executed, when a delay status report (DSR) is triggered, at a UE MAC layer of the wireless communication system of Figure 1; Figure 13a is a schematic diagram illustrating further example of a short DSR format and a short truncated DSR format; Figure 13b is a schematic diagram illustrating a further example of an extended short DSR format and an extended short truncated DSR format; Figure 14 is a schematic diagram illustrating a still further exemplary message format, including a long DSR format, a long truncated DSR format, and a pre-emptive DSR format; Figure 15 is a schematic diagram illustrating a yet further exemplary message format including an extended long DSR format, an extended long truncated DSR format, and an extended pre-emptive DSR format; and Figures 16 to 20 are schematic diagrams illustrating the triggering of a DSR according to an example of the method shown in Figure 12. DETAILED DESCRIPTION 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. 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. 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. 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. 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. 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. 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. The I / O controller 255 allows these interactions with external peripherals by providing the hardware required and by managing input and output signals. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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): A. PDU Set delay budget (PDSB); B. PDU Set error rate (PSER); and C. PDU Set integrated handling indication (PSIHI), which is also previously known as a PDU Set integrated indication. 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. 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. 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; B. an indication of the end PDU of the PDU Set; C. a PDU sequence number within a PDU Set; D. a PDU Set size; and E. a PDU Set importance, which identifies the relative importance of a PDU Set compared to other PDU Sets within a QoS flow. 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). 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). 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). 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). 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-U 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. 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. 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). 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: A. dynamic request scheduling issued by each UE (i.e., wherein the UE dynamically issues a request for radio resources); 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 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). 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). The buffer status reporting mechanism operates on the basis of a logical channel group (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 (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. 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. 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. According to aspects of 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). The status report is configured (e.g., divided) into a plurality of sections, wherein each of the sections may be configured to enable a plurality of data packets having similar buffer statuses to be associated with the same section. In at least some aspects of the present disclosure, the delay status reporting mechanism is configured to also indicate the remaining time in which to execute the transmission for at least one of the plurality of sections. This exemplary method is described below with particular reference to Figs. 5 to 11. 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. 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-U 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. 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. 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. 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). 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. 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. 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: 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). 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). 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). 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). 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: A. the last PDU of the PDU is received; and B. the PDU Set is discarded (e.g., because the discard timer elapsed). 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. Some PDU Sets contain only one 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. 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: 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). 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. 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. 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., +1-10 ms) or relative difference (e.g., +1- 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; B. the remaining timer is set to the mean value between the obtained timer value and the remaining timer value; and C. the remaining timer is set to the lowest, or greatest value of the timer values. 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: A. creating a new section of the LCG; B. starting a remaining timer for the new section, the new timer is set to the obtained discard timer value; and 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). 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. 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. 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). 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. 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. 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: 1. during uplink, data becomes available to the MAC entity, for at least one LCH of an LCG; 2. 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); 3. 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); 4. 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 5. a time value remaining once at least one section of the LCG has reached at least one threshold. 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). 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). 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. 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. 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. 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. 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. 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. In context of integrated access and backhaul (IAB) 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). 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. 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: A. a remaining time of each section; 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 D. a PSIHI QoS parameter associated with the PDU Set(s) of each section. The UE configures the status of the non-selected new sections so that they are characterised as “skip” sections. 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. 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. 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: 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); 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); C. a ratio of remaining time to buffer size (which favours the sections with less time to send the known buffer size); D. PDU Set Importance Information (PSI) associated with the PDU Sets of each section (which favours the most important PDU Sets); and E. 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). 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. 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. 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. 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. The formatting of the DSR will now be described with specific reference to Figure 9a, Figure 9b, Figure 10 and Figure 11. For all sections, the LCG identification (ID) field 901, 951,1001, 1101 is configured to include an LCG identifier, which defines the LCG that contains the section (e.g., LCG0, LCG1, LCG2 etc. as shown in Fig. 10). 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. 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). 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. 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”. 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”. 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. 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. 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). 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: A. available data for legacy logical channel groups through the legacy BSR procedure (e.g., as defined in 3GPP document TS 38.321); 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. 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. 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. 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: A. delay information for only new sections; B. N consecutive delay information from the creation of the section; and C. systematic delay information for all sections. 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. 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. The section ID field 902 identifies the different sections in an LOG (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. 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). 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. 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. 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 8bits). The LCG ID field identifies the group of LCH(s) whose delay status is being reported. 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. 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). 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. In detail, the message is composed of 8 (eight) LCGs flags, one for each of the corresponding LCGi (e.g., LCGO-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 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). Initially, a section bitmap 1002 indicates the presence of the delay status for each section, Si (e.g., SO-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. 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. 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. 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). Initially, a section bitmap 1102 indicates the presence of the delay status for each section, Si e.g., SO-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. 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. In alternative aspects of the present disclosure, the buffer status reporting mechanism is configured to provide an indication of the amount of data to be transmitted from at least two sections (i.e., of the plurality of section), wherein the status report is transmitted in dependence on the timing information associated with at least on the at least two sections. The exemplary methods according to these alternative aspects enable the user equipment to transmit a single signal which provides an indication of the data carried by two or more sections of a single channel (i.e., thereby simplifying the status reporting procedure), so that the network and can readily predict when a set of data packets will elapse. This advantageously allows network resources to be allocated more efficiently, whilst also reducing the network transmission load. In contrast to the exemplary method described above, with respect to Figs. 5 to 11, these alternative aspects do not rely on the reporting of specific timing information associated with individual sections (and / or the data packets carried therein). Rather, the report itself can be interpreted by the network as an indication that the corresponding data packets are about to elapse. Further details of the delay status reporting mechanism according to these alternative aspects will now be described with reference to Figure 12, Figure 13, Figure 14, Figure 15, Figure 16, Figure 17, Figure 18, Figure 19, and Figure 20. In the following passages, the description of any similar features to that of the previously described aspects are omitted for brevity. Figure 12 is a flow chart illustrating a method 1200 which is executed at the UE MAC layer 410 (as shown in Figure 4) when a delay status reporting mechanism is triggered. The method 1200 will now be described with reference to Figure 13a, Figure 13b, Figure 14, and Figure 15 which show example status reports produced by the method. Also, reference is made to Figures 16 to 20 which show schematic diagrams illustrating the triggering mechanism for the status report according to embodiments of the present disclosure. As described above, the LCG is subdivided into a plurality of “sections”, which define parts of the LCG. In Figs. 16 to 20, the sections S1, S2, S3 are depicted as silos, or containers, into which PDU Set data can be deposited (e.g., as shown by the arrow in Fig. 17). Each of the section can be associated with one or more PDU Sets with the similar buffer status. Information about the PDU Sets is compiled into a status report which is transmitted to the network when a trigger condition being satisfied. In Figs. 16 to 20, the transmission of the status report is depicted as being controlled by a plurality of “triggers” T1, T2, T3. When a trigger condition is satisfied the trigger may be activated (e.g., as depicted by the shaded trigger T1 in Fig. 19) to enable the transmission of the status report. An initial method step 1201 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: A. during uplink, data becomes available to the MAC entity, for at least one LCH of an LCG; 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); 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); and 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. E. a remaining time (e.g., a discard timer value) of at least one section of the LCG has reached a remaining time threshold (e.g., if the discard timer value of the at least one section is equal to, or less than, a threshold timer value). F. after sending a BSR, the user equipment does not receive, within a predetermined time period, a scheduling grant from the base station 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). In embodiments, the delay status report is based primarily on the remaining time trigger condition (i.e., point E in the above-described list of trigger conditions). Optionally, one or more of the other trigger conditions (i.e., points A-D) may be used as secondary (or supplementary) trigger conditions. For example, these secondary conditions may only be considered if the primary trigger condition is satisfied. A second method step 1202 involves creating a status report for the LCG. This involves the UE checking (e.g., identifying) if one or more sections of the LCG have reached at least one remaining time threshold. The UE then generates a status report which defines the buffer size corresponding to at least one section of the LCG. Optionally, the buffer report may also include delay information relating to the at least one section. Figs. 16 to 18 illustrate how the data associated with different sections of the LCG can change over time. For example, in Fig. 17 the first section S1 receives data with a corresponding discard timer value of 30 (e.g., milliseconds). Upon receiving the data, a discard timer of the first section S1 starts to count down from 30. Five milliseconds later, the second section S2 receives PDU Set data with a discard timer value of 30 (see Fig. 18). The timing information of this PDU Set data does not match the data associated with S1, because the remaining time value of S1 has now reduced to 25. Instead, the new PDU Set data is added to S2, and a corresponding discard timer starts to count down from 30. Fifteen milliseconds later, a further PDU Set is received with a discard timer value of 16 (see Fig. 19). This data is added to the third section S3 and a corresponding discard timer starts to count down from 16. The buffer status report includes the sum of the buffer size values associated with the sections of the LCG which have reached the remaining time threshold. For example, at the time shown in Fig. 19 the remaining timer value (i.e., 10) of the first section S1 has reached the threshold value (i.e., 10) and so the buffer status report may be configured to include an indication of the total buffer size value of the data associated with the first section. In embodiments, the status report may include the sum of the buffer size values associated with at least one (e.g., each) section of the LCG which has a remaining time greater than the configured remaining time threshold, but which is lower than a further (or secondary) remaining time threshold. In this way, the further remaining time threshold defines a range of timer values, above the first threshold, for which the data of any section that falls within the range will be included in the status report. Each of the first and / or second threshold values (i.e., TH1 and TH2 in Fig. 16) may be configured as whole integer values (e.g., milliseconds). The threshold values may be configured as multiples of the duration of one network cycle (e.g., 1 millisecond). In the exemplary arrangement shown in Figs. 16 to 20, the secondary threshold is 15. Accordingly, at the time depicted in Fig. 19, the remaining timer value of the second section (i.e., 15) has not yet reached the first threshold value (i.e., 10), but it has reached the second threshold value. Therefore, the data associated with the first section and the second section may be included in the status report. By contrast, the remaining time value (i.e., 16) of the third section S3 has not yet reached the second threshold value (i.e., 15), and thus the data associated with the third section is not included in the status report. In embodiments, the status report may include the sum of buffer size values associated to all sections for which a DSR has already been sent in the past and for which there are remaining data left unsent. Such a situation is depicted in Fig. 20 in which the second section S2 has reached the first threshold (i.e., such that the data associated with the second section will be included in the status report). However, some of the data for the first section S1 has not yet been sent to the network. The first section still has some remaining time available (i.e., 5) and so the status report is configured to include the data associated with both the first and second sections. Optionally, the remaining timer value (i.e., 11) of the third section S3 has now reached the second threshold (i.e., 15) and so the associated data of the third section may also be included in the status report. The size of available data for one section includes the sum of data buffered for that section in MAC, RLC and PDCP layers. Optionally, the size of available data for one section may account for data that is not yet in the UE buffers but is deemed to be received soon (e.g., within a predetermined time period) according to known burst parameters such as the Burst Arrival time and the average burst size (or minimum burst size). Optionally, if configured by the gNB, the status report is stopped if the total amount of data to be reported is below a predetermined or configured data threshold value. In embodiments, the associated delay information may be omitted from the status report since the remaining time threshold used as the trigger condition is configured by the gNB. Hence, the gNB can interpret the transmission of the status report as an indication that the reported data packets are about to elapse. In certain embodiments, the remaining time may be reported if it is significantly below the threshold configured as the trigger (e.g., the remaining time is the duration of one network cycle (1 millisecond). Example reasons for reporting the remaining time can include at least one of: A. The previous DSR transmission has failed (e.g., as determined in method step 1207 of Fig. 12); B. A report for a given LCG has been down selected (e.g., as determined in method step 1205 of Fig. 12); and C. A channel grant is delayed because of priority management. In such cases where the remaining time is reported, it is possible that two or more (e.g., each) of the sections have different remaining times. In such cases, the reported remaining time can be configured to equal at least one of: A. the shortest remaining time (e.g., the lowest remaining time of all of the data packets associated with the status report); B. the mean value of the different remaining times; C. the mean value of the remining time pondered by the available buffer sizes; and D. the remaining time of the section with the biggest available buffer size. At a fourth method step 1204, the UE analyses the available radio resources for sending a DSR, then the UE calculates how many LCG reports can be concatenated in the available radio resources. In general, the DSR defines a message from the UE to the gNB which outlines the amount of data which is available for uplink transmission (and optionally indicates the associated delay budget). 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 13a, Figure 13b, Figure 14 and Figure 15. 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 LCG 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 LCGs can be reported using the long DSR format. The short DSR format is described in more detail below with reference to Figures 13a and 13b, and the long DSR format is described with reference to Figure 14. In embodiments, if the available radio resource is greater or equal to one byte and less than three bytes then there is only room for reporting one LCG by using the short DSR format. If the available resources are greater or equal to 3 bytes, then at least two LCGs can be reported using the long DSR format. When the UE has only one LCG to report, then the DSR format is called a short DSR format. If the UE has to select one LCG among a plurality of LCGs, then the DSR message is called a short truncated DSR format (see Figure 13a). Accordingly, both the short DSR format and the short truncated DSR format are functionally the same type of DSR message with a different name. When the available radio resources match all of the LCGs that are available to be reported, then the DSR message of Figure 14 is called a long DSR format. If the UE has to select one LCG among a plurality of LCGs, then the DSR message of Figure 14 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. In context of integrated access and backhaul (IAB) 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). 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 13b). If only one LCG is selected among a plurality of LCGs, then the DSR message is called an extended short truncated DSR format (see Figure 13b). When the available radio resources match all of the LCGs that are available to be reported, then the DSR message is called an extended long DSR format (as shown in Figure 15). If one LCG is selected among a plurality of LCGs, then the DSR message of Figure 15 is called an extended long truncated DSR format. The method 1200 proceeds with a fifth method step 1205 in which, if all the candidate LCGs cannot fit into the available radio resources, the UE performs a selection of the LCG according to multiple criteria. The selection criteria may include: 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); 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); C. a ratio of remaining time to buffer size (which favours the sections with less time to send the known buffer size); D. PDU Set Importance Information (PSI) associated with the PDU Sets of each section (which favours the most important PDU Sets); and E. 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). In one example, the DSR triggering is performed by continuously comparing the remaining time associated to each section with a remaining time threshold configured by the gNB and thus DSR is sent only when some data reached a critical level of remaining time. In another example, the DSR triggering is able to follow the same triggers as the BSR because the delay information is sent at section creation time and thus there is no need for additional triggers for sending a dedicated DSR when the remaining time becomes critical. In a subsequent method step 1206, 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 13, Figure 14, and Figure 15. The DSR is then sent to the gNB. The formatting of the DSR will now be described with specific reference to Figure 13a, Figure 13b, Figure 14 and Figure 15. For all sections, the LOG identification (ID) field 1301, 1351,1401, 1501 is configured to include an LCG identifier, which defines the LCG that contains the section (e.g., LCG0, LCG1, LCG2 etc. as shown in Fig. 14). The optional delay field 1303, 1353, 1403, 1503, which is set to the remaining timer value associated with at least one section of the LCG (as calculated in step 1202). The resulting remaining timer value may be configured (e.g., adjusted) to the expected time of a first transmission attempt of the DSR. Since the delay threshold trigger is configured by the gNB the delay field can be omitted. The buffer size field 1303, 1353, 1402,1405, is set to the buffer size associated with the at least one section of the LCG as calculated during step 1202. The method 1200 proceeds with method step 1207 in which the UE analyses (e.g., checks) whether the previous DSR has been received by the gNB. If the 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. Figure 13a 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 1301 (e.g., comprising at least 3 bits). The LCG ID field identifies the group of LCH(s) whose delay status is being reported. The buffer size is reported in field 1302 (e.g., comprising up to, or at least, 8 bits). The optional delay information is reported in field 1303 (e.g., comprising up to, or at least, 8 bits) Figure 13b 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. 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. 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 8bits). The LCG ID field identifies the group of LCH(s) whose delay status is being reported. The buffer size is reported in field 1352 (e.g., comprising up to, or at least, 8 bits). The optional delay information is reported in field 1353 (e.g., comprising up to, or at least, 8 bits) Figure 14 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. In detail, the message is composed of 8 (eight) LCGs flags, one for each of the corresponding LCGi (e.g., LCGO-7). The field 1401 indicates the presence of the delay status report for the corresponding LCGi. If the numerical value in the field 1401 (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 1401 is set to 0, this indicates that the delay status for the LCGi not reported. The LCG delay statuses are included in ascending order based on the LCGi. A delay status (e.g., 1402, 1403) of one LCG includes an optional delay information for 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). For at least one, or each LCG, an optional delay information is reported in field 1402 (e.g., comprising up to, or at least, 8 bits) and the associated buffer size is reported in field 1403 (e.g., comprising up to, or at least, 8 bits). Figure 15 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. In detail, the message is composed of a 256 LCG flags, for each of the LCGi. The field 1501 indicates the presence of the delay status report for the corresponding LCGi. Field 1501 (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 1501 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 1502, 1503) of one LCG includes optional delay information for 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). For at least one, or each LCG, an optional delay information is reported in field 1502 (e.g., comprising up to, or at least, 8 bits) and the associated buffer size is reported in field 1503 (e.g., comprising up to, or at least, 8 bits). Further description of aspects of the present disclosure: Within the context of buffer status reporting, the following points are considered: A. The UE may be configured to calculate the remaining time based on the PDCP discard timer value. For further consideration is whether the UE reports one or multiple values. Also, for further consideration is how this is modelled in PDCP specification. Also, for further consideration is which UEs would support this. B When / if the UE reports remaining time, the reference time for the remaining time may be determined from the point of the first transmission of the information. For further consideration is whether intra-UE prioritization can impact this. Further within the context of buffer status reporting, the following points are considered: A. A working assumption is that a new separate MAC CE may be defined for DSR (e.g., comprising remaining delay and associated data volume) reporting, e.g., the DSR reporting may not be coupled with BSR reporting. A detailed definition of associated data volume is for further consideration. B. DSR reporting may be support threshold based, e.g. DSR reporting may be triggered when remaining delay of a PDU / PDU Set is below a NW configured threshold. The threshold may be configured per LCG. For further consideration is whether configuring multiple thresholds for a LCG is supported. A definition of the remaining time is also for further consideration. There are many reasons for multiplexing PDU Sets with different remaining times within a single LCG. First, different PDU sessions can be multiplexed in one QoS flow. For example, when two video sessions with the same QoS requirements (e.g., same PSDB) are mapped to the same QoS flow. In that case, if the PDU Sets of the two PDU sessions are not synchronized, the different bursts may arrive at different times at the UE buffers and thus having different remaining times. Another possibility is that the PSDB may be larger than the image period, in that case it may happen that the UE has in its buffers two PDU Sets with different remaining times. Another possibility is the non-PDU Set based channel for example to handle the pose PDUs. Each Pose PDU will have a different remaining time in the UE buffers. Finally, there is still the possibility that two PDU sessions with similar QoS requirements but different PDSBs being multiplexed in the same QoS flow. For reporting the delay two solutions will now be described, namely 1) multiple threshold-based reporting, and 2) single threshold-based reporting. 1. Multiple values, multiple thresholds: When multiple values can be reported in one DSR the simplest solution is to report each PDU set separately. However, the overhead can be reduced by grouping the PDU Sets with the same remaining time into a single value in the DSR report. The reported buffer status shall then account for available data for all the grouped PDU Sets. Proposal 1: For one LCG, PDU Sets that have the same remaining time may be grouped in a single DSR report. Proposal 2: For one group of PDU Sets with the same remaining time, the reported buffer size may be indicative of the amount of data available for all of the grouped PDU Sets. It can be advantageous for the network to receive DSR reports while the remaining time is not yet critically low. For example, in case of congestion, it may not be so easy to send the DSR. It seems more efficient to send the DSR in advance and let the network monitoring the remaining time per PDU Set once it receives the first DSR. This can also give more flexibility to the network to anticipate the scheduling decisions. To send the DSR earlier, the trigger can be similar to the BSR trigger, when data first becomes available for uplink transfer. Proposal 3: The chosen trigger may allow the DSR report to be sent before the remaining time becomes critical (e.g., when new data is available, similar to BSR trigger). Having sent the DSR early, when first data was available for uplink transfer, the UE shall later send updated buffer status to the network so that the network is able to monitor the evolution of the remaining time. Since the network already received the remining time information, it is not necessary to send it each time. Proposal 4: When new data is ready for uplink for one LCG, an updated DSR may be sent with buffer status only. 2. Single threshold: As discussed in the previous section (i.e., multiple values, multiple thresholds), multiple PDUs may be multiplexed in one LCG. If the PDU Sets have similar delay budgets, similar periodicity and synchronized image generation time, it is likely that they can reach the delay threshold trigger simultaneously. Another example is two non-synchronized PDU Sets or PDU Sets with different delay budget requirements. Figures 16 to 20 illustrate an example of an LCG multiplexing three PDU Sets (S1, S2, S3) managed by PDCP discard timers (DT1, DT2, DT3), respectively. A remaining time counter is managed for each PDU Set (RT1, RT2, RT3). All remaining time counters are compared to a single remaining time threshold (TH1) configured by the network. Figure 17 - First data from PDU Set S1: At first, data becomes available for PDU Set S1, PDCP notify a discard timer value DT1 of 30 ms, remaining time counter RT1 is set to 30 ms. Figure 18 - First data from PDU Set S2: After 5 ms, data becomes available for the second PDU Set (S2), PDCP notify a discard timer value DT2 of 30 ms, remaining time counter RT2 is set to 30 ms. Meanwhile, the remaining time counter RT1 is now at 25 ms. Figure 19 - First data from PDU Set S3 and first trigger: 15 ms later, data becomes available for the third PDU Set (S3), PDCP notify a discard timer value DT3 of 16 ms, remaining time counter RT3 is set to 16 ms. Meanwhile, the remaining time counter RT1 is now at 10 ms triggering a DSR report with S1 buffer status. The remaining time counter RT2 is now at 15 ms. Figure 20 - Second trigger: 5 ms later, the remaining time counter RT2 reaches the remaining time threshold and a DSR is triggered for PDU Set 2. The remaining time counter RT 1 is at 5 ms and the remaining time counter RT3 is at 11 ms. If, in another example, the discard timer DT3 was 15 ms, instead of 16 ms, two independent PDU Sets S2 and S3 would have reached the remaining time threshold simultaneously. In a single threshold system, there is no need to send two DSR, one DSR can report the sum of available data from the two PDU Sets, thus minimizing the overhead. Proposal 5: For one LCG, PDU Sets that reaches simultaneously the remaining time threshold may be reported in a single DSR. Returning to the current example, when S2 reaches the remaining time threshold, S3 is 1 ms away from reaching the same threshold. In a single threshold system, there may be some flexibility (may be configured by the network) in the threshold definition allowing PDU sets with almost the same remaining time to be reported in the same DSR. Proposal 6: For one LCG, any PDU Sets (e.g., a plurality of PDU Sets) that reach the remaining time threshold almost in the same time may be reported in a single DSR. Considering Figure 19, when S1 reached the remaining time threshold, the UE may have subsequently failed to send the corresponding DSR report. Similar to a BSR truncated report, the DSR report may have been arbitrated out in favour of a higher priority LCG. Intra UE prioritization might also delay DSR sending. Considering Figure 20, in the case where S1 DSR is not yet sent when S2 is triggered, it may be interesting to send a single DSR report combining both S1 and S2. Proposal 7: For one LCG, the reported buffer status may include the status relative to the PDU sets that have recently reached the threshold as well as the PDU sets that have reached the threshold earlier but did not have an associated DSR. Considering Figure 20, at the time when S2 reaches the remaining time threshold, although STs DSR have already been sent earlier, there may be some data left in UE buffers corresponding to S1. In that situation, it may be interesting to sum the data left for S1 with the available data from S2 in a single DSR. Proposal 8: For one LCG, the reported buffer status shall include the status relative to the PDU sets that have recently reached the threshold as well as the PDU sets that have reached the threshold earlier but that still have available data in the buffers. Within the context of buffer status reporting, a further consideration may be to enhance delay status reporting with multiple pairs of data volume and remaining time. In the present disclosure a possible triggering enhancement is described with regards to the multiple pairs of data volume and remaining time, and whether an indication of PDU Set Importance (PSI) needs to be included in DSR. 1. Triggering enhancement: A single pair of data volume and remaining time may be allowed in one DSR for each LCG. Only data which have not been reported in prior DSR can trigger a new DSR. For one LOG, for each LCH of the LCG, a DSR may be triggered when the smallest remaining value of the running PDCP discardTimers among all the PDCP SDUs buffered for the logical channel that have not been transmitted in any MAC PDU and have not been reported as data volume in a DSR MAC CE becomes below a remainingTimeThreshold of the LCG. Considering a situation in a DSR comprising multiple pairs, with each pair corresponding to a different remaining time threshold, it may be considered which threshold is used as a trigger for the DSR. A single threshold can be used to trigger the DSR, for example, the lowest remaining time among the different pairs can be used by default. Further, the network can configure one of the pair thresholds to be used as a trigger. Proposal 1: The remaining time associated with at least one data volume can be used as a trigger for the DSR. Since there are multiple pairs, a further consideration may be to report some volumes multiple times if their remaining time changes below a second threshold. Otherwise, it will be impossible for the gNB to track the progress of the UE TX buffer filing. Indeed, some pairs may have new data volumes that need to be reported. Thus, it is important that the DSR can be triggered if at least one of the pairs has new data which have passed the corresponding remaining time threshold. Proposal 2: If there are data which have passed a second threshold for one of the already reported pairs then a new DSR may be triggered. As some pairs could have data that have already been reported in a previous DSR, a data novelty indication can be added for each pair. This allows the gNB to keep track of the progress of each pair in volume. For example, if already reported data are now below a lower threshold (e.g., “th2”) and some new arrived data are already below “th2”, then two pairs must be reported and the new one shall be distinguishable from the old one. Proposal 3: A data novelty indication may be defined for each pair. Since an already reported data volume will have a smaller remaining time it should be useful to identify each pair so that the gNB can track the remaining time evolution of a given data volume. If a pair is identified then it will not be necessary to add the remaining time information when the novelty flag is false. Proposal 4: A pair identification may be defined based on the first reported data volume. 2. PDll Set importance: PDU Set importance indication may be used for congestion management Except the congestion condition, PSI has no use for the network. Thus, it is unlikely that there would be any benefits to include PSI indication in the DSR. Indeed, most of the time it will not help the network to make scheduling decisions. Proposal 5: Do not include PSI indication in the DSR. 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 PDUs, in particular, the present disclosure is applicable to in-sequence PDU transmission on any layer. 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. 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. 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. 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. 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. 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

1. A method for reporting a buffer status of data to be transmitted over a logical channel group of a communication network for carrying a plurality of protocol data unit sets, PDU Sets, associated with a first section and a second section of the logical channel group, wherein each of the first and second sections is associated with at least one PDU Set, the communication network comprises a user equipment and a base station, wherein the method at the user equipment comprises:transmitting a status report for reporting the buffer status of the first section and the second section to the base station, the status report comprises information indicative of the amount of data associated with the first and second sections, wherein the status report is transmitted based on a discard timer value associated with at least one of the first and second sections.

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

3. The method of claim 2, wherein the status report is transmitted if:the discard timer value associated with the first section is up to the timer threshold value; andthe discard timer value associated with the second section is more than the timer threshold value, and is within a predetermined range of the timer threshold value.

4. The method of claim 2, wherein the status report is transmitted if:the discard timer values associated with each of the first and second sections are up to the timer threshold value; andthe discard timer value associated with the first section is closer to the timer threshold value than the discard timer value associated with the second section.

5. The method of claim 4, wherein the method comprises:transmitting a first status report if the discard timer value associated with the first section is up to the timer threshold value, wherein the first status report comprises information indicative of the amount of data of the at least one PDU Set associated with first section at the time of the first status report, wherein the first status report does not comprise information indicative of the amount of data at least one PDU Set associated with the second section; and following the transmission of the first status report, transmitting a second status report if the discard timer value associated with the second section is up to the timer threshold value,wherein the second status report comprises information indicative of the amount of data of the at least one PDU Sets associated with each of the first and second sections at the time of the second status report.

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

7. The method of any one of the preceding claims, wherein the discard timer value of the first and second sections is generated by a discard timer which is initiated when data for the respective PDU Set is received by the user equipment8. The method of any one of the preceding claims, wherein the method comprises: before transmitting the status report, generating an individual status report for each of the first and second sections; andconcatenating the individual buffer status reports to form the combined status report for transmitting to the base station.

9. The method of any one of the preceding claims, wherein the first section is associated with a first PDU Set, and the second section is associated with a second PDU Set having timing information which is different to that of the first PDU Set.

10. The method of any one of the preceding claims, wherein the method step of transmitting the status report is stopped if the amount of data of the first and second sections is below a predetermined data threshold value.

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

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

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

14. The method of any one of the preceding claims, wherein the method comprises determining the first and second sections based on timing information of the at least one PDU Sets associated with the respective sections.

15. The method of claim 14, wherein the method comprises grouping two or more PDU Sets with matching timing information into a single section.

16. The method of claim 15, wherein the method comprises:comparing timing information of at least one PDU Set with the discard timer value of the first section and the discard timer value of the second section;associating the at least one PDU Set with the first section if the first discard section timer value matches the timing information of the at least one PDU Set; andadding information indicative of the amount of data associated with the at least one PDU Set to the first section.

17. The method of any one of claim 14 to 16, wherein the method comprises:generating a third section of the logical channel group if the timing information of the at least one PDU Set does not match the section timer value of each of the first and second sections;starting a timer for the third section which corresponds to the discard timer value; and adding information indicative of the amount of data associated with the at least one PDU Set to the third section.

18. The method of claim 16 or claim 17, wherein the timing information of the at least one PDU Set matches the discard timer value of the respective section if the timing information is substantially equal to the discard timer value.

19. The method of any one of the preceding claims, wherein the status report provides an indication to the network that a discard timer value associated with at least one of the first and second sections is critical.

20. The method of any one of the preceding claims, wherein the discard timer value for at least one of the first and second sections is included in the status report.

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

22. The method of any one of the preceding claims, wherein the status report comprises information indicative of the total amount of data associated with the first and second sections.

23. A method for reporting a buffer status of data to be transmitted over a logical channel group of a communication network for carrying a plurality of protocol data unit sets, PDU Sets, associated with a first section and a second section of the logical channel group, wherein each of the first and second sections is associated with at least one PDU Set, the communication network comprises a user equipment and a base station, the method at the base station comprises:receiving a status report for reporting the buffer status of the first section and the second section to the base station, the status report comprises information indicative of the amount of data associated with the first and second sections, wherein the status report is transmitted based on a discard timer value associated with at least one of the first and second sections; andconfiguring a timer associated with at least one of the first and second sections based on the information indicative of the amount of data associated with the first and second sections.

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

25. 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 22, or comprising instructions which, when the program is executed by a base station, causes the base station to carry out the method of claim 24.

26. A computer-readable medium carrying a computer program according to claim 25.

Images