Method for managing data transmission in a communication network

Abstract

A method for enhanced polling in a Radio Link Control Acknowledged Mode (RLC AM) communications network 700 where time information, which may be related to a delay budget, relating to at least one of

Description

TECHNICAL FIELD The present disclosure relates to a method for managing data in a communication network (e.g., a mobile telecommunication network). More particularly, the method is directed towards managing data in a communication network configured to operate in a Radio Link Control Acknowledged Mode (RLC AM). 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., a “PDU Set”). Accordingly, the application data comprise 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., a 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 forXR 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., at PDU layer of UE in downlink, or at PDU layer of user plane function (UPF) in the core network in uplink). Some video decoder implementations require that a complete application data packet (e.g., a 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 Quality of Service (QoS) parameter called PDU Set Delay Budget (PSDB) is defined. The PSDB 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 next generation node B (gNB)) or a UE 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 the transmission over the air interface of one or more PDUs of this “useless” PDU Set is pending, then the UE or the RAN node can consider discarding the remaining transmission of the “useless” PDUs, thus achieving radio network resource saving. The PDU Sets are mapped on QoS flows at Service Data Adaptation Protocol (SDAP) layer, QoS flows are mapped on Data Radio Bearers (DRBs) at Packet Data Convergence Protocol (PDCP) layer, DRBs are mapped on Radio Link Control (RLC) channels at RLC layer, RLC channels are mapped on logical channels at Medium Access Control (MAC) layer. The MAC layer implements reliability mechanism called Hybrid Automatic Repeat Request (HARQ), it provides a given level of reliability that can be improved by the RLC layer if needed. The RLC layer can be operated in an Acknowledged Mode (AM), which implements an additional ARQ mechanism that allows further enhancement of the transmission’s reliability. The RLC protocol in a 5G system is specified in the 3GPP document TS 38.322. The transmitting side of an AM RLC entity receives RLC SDUs (Service Data Units) from upper layer and sends RLC PDUs to its peer RLC AM entity via lower layers. The receiving side of an RLC AM entity delivers RLC SDUs to upper layer and receives RLC PDUs from its peer RLC AM entity via lower layers. Each RLC SDU is used to construct an RLC PDU without waiting for notification from the lower layer (i.e., by MAC) of a transmission opportunity. Thus, an RLC SDU may be segmented and transported using two or more RLC PDUs based on the notification(s) from the lower layer. RLC PDUs are submitted to a lower layer only when a transmission opportunity has been notified by the lower layer (i.e. by MAC). An RLC (data) PDU contains either one complete RLC SDU or one RLC SDU segment. The header of a RLC (data) PDU contains the RLC SDU Sequence Number (SN) and, if the RLC SDU has been segmented, a segment offset. The ARQ mechanism with RLC AM relies on the RLC receiver sending status reports indicating the reception status of RLC PDUs (thus indicating the reception status of RLC SDUs or RLC SDU segments) to the RLC transmitter which in return will schedule the retransmission of the lost RLC SDUs or RLC SDU segments and update the transmitting window. Status reporting at the RLC receiver is triggered either on demand by the RLC transmitter (polling bit) or by the detection by the RLC receiver of a lost RLC PDU. An RLC PDU is detected as lost when both a sequence number gap (or a segment offset gap) is detected and a timer is elapsed (e.g., t-Reassembly as described in TS 38.322). Thus, at the RLC transmitter side the decision to retransmit a RLC SDU (or RLC SDU segment) is delayed both by polling and t-Reassembly timer. While these mechanisms may reduce the overhead (or the total number of retransmissions), they introduce additional delay when the lower layers eventually fail to transmit the RLC SDU (or RLC SDU segment) correctly. For applications (like XR) that require both high reliability and low latency, this additional delay is not acceptable. Furthermore, delaying the retransmission of one RLC SDU has also a negative consequence on the transmitting window management. The transmitting window is defined between a lower bound and an upper bound of RLC SDU sequence numbers. It defines the RLC SDUs that are eligible to be transmitted. The transmitting window is updated by both incrementing the lower and upper bounds. Thus, the transmitting window is only updated when the reception status of the lower bound RLC SDU is confirmed to be good, otherwise it stays unchanged even if new RLC SDUs are provided by an upper layer of the protocol stack (e.g., PDCP) for transmission. For example, a second PDU Set transmission can be stalled because the reception status of one RLC SDU of a first PDU Set is not confirmed and the sequence numbers of RLC SDUs from a second PDU Set are omitted from the transmitting window. This phenomenon is also known as transmitting window stalling. Methods for reducing the impact of transmitting window stalling have been proposed. For example, some network parameters can be tuned to improve the status report responsiveness. The maximum polling frequency can be configured as one polling bit every 4 RLC PDUs. But polling frequency cannot match the PDU Sets boundaries because PDU Sets boundaries are variable. Alternatively, a t-Reassembly timer can be reduced (or even set to 0), which increases the responsiveness of the RLC receiver once the sequence number gap is detected. But reducing the t-Reassembly timer increases the number of false missing detections, which can then increase the overhead across the network. Accordingly, there is a need to manage the retransmission of data when applying RLC AM in order to improve the efficiency of such communication networks. SUMMARY According to aspects of the present disclosure, there is provided a technique for managing data transmission between a transmitter and a receiver, wherein the receiver is requested to report the receipt status of a plurality of data packets (e.g., Protocol Data Units, PDUs). For example, a first request may request that the receiver reports the receipt status of a first data packet, subsequently a second request (e.g., which is different to the first request) may request that the receiver reports the receipt status of the first data packet and a second data packet which was transmitted subsequently to the first data packet. According to a first aspect of the present disclosure, there is provided a method for managing data transmission in a communication network using a Radio Link Control Acknowledged Mode, RLC AM, the communication network comprising a transmitter and a receiver, wherein the method at the transmitter comprises: transmitting, to the receiver, a request to report the receipt status of a plurality of Protocol Data Units, PDUs, wherein the request is transmitted based on timer information associated with at least one PDU of the plurality of PDUs. According to a second aspect of the present disclosure, there is provided a method for managing data transmission in a communication network using a Radio Link Control Acknowledged Mode, RLC AM, the communication network comprising a transmitter and a receiver, wherein the method at the receiver comprises: reporting to the transmitter the receipt status of a plurality of Protocol Data Units, PDUs, in response to a request from the transmitter, wherein the request is transmitted based on timer information associated with at least one PDU of the plurality of PDUs. According to a third aspect there is provided a communication network which comprises a transmitter configured to perform the method according to the first aspect, and / or a receiver configured to perform the method according to the second aspect. According to a fourth aspect there is provided a computer program comprising instructions which, when the program is executed by a transmitter, causes the transmitter to carry out the method according to the first aspect. According to a fifth aspect there is provided a computer program comprising instructions which, when the program is executed by a receiver, causes the receiver to carry out the method according to the second aspect. According to a sixth aspect there is provided a computer-readable medium carrying a computer program according the fourth aspect and / or the fifth aspect. Known status reporting techniques at the RLC receiver is triggered either on demand by the RLC transmitter, or by the detection by the RLC receiver of a lost SDU. For example, an SDU is detected as lost when both a sequence number gap is detected and a timer is elapsed (or expired). Thus, at the RLC transmitter the decision to retransmit a SDU is delayed both by polling and by the t-Reassembly timer. While the described procedure may reduce the overhead within the network (and / or the total number of retransmissions), the reliance on status reports introduces additional delays when the lower layers of the protocol stack eventually fail to transmit the SDU correctly. For certain applications that require both high reliability and low latency (e.g., XR), this additional delay is not acceptable. The present disclosure (e.g., according to any one of the first to sixth aspects) advantageously provides the transmitter with a means of establishing the receipt status of the plurality of unknown PDUs by receiving a single status receipt report from the receiver. The transmitter is then able to manage the retransmission of data (e.g., by retransmitting the missing PDU(s) before the expiry of a timer associated with at least one of the unknown PDUs), which thereby improves the efficiency of the communication network. The present disclosure also applies advantageously to situations where the status of a plurality of PDUs is unknown to the transmitter. In such situations, known methods for managing data transmission are configured to report the receipt status of a single PDU in response to a request from the transmitter, or in response to the expiry of a timer associated with the single PDU. Accordingly, if the receipt status of two or more PDUs is unknown, then the transmitter must wait to receive a separate status report for each of the missing PDUs, which can delay the retransmission of the missing PDUs until after it is too late (e.g., after a transmission window has closed). The present disclosure addresses this problem by providing a means for the receiver to report the receipt status of a plurality of PDUs in a timely manner, so that the transmitter is then able to retransmit the missing PDUs before they expire. Optional features will now be set out. These are applicable singly or in any combination with any aspect of the disclosure. The timing information (e.g., indicative of a timer) associated with the at least one PDU may be associated with a Delay Budget associated with at least one PDU of the plurality of PDUs (e.g., a Delay Budget timer). For example, the request may be transmitted before expiry of a timer associated with at least one PDU (e.g., the at least one PDU of the plurality of PDUs corresponding to the timing information). By reporting the receipt status report before the expiry of the Delay Budget timer, this allows the transmitter time to retransmit the associated PDU before it expires. Prior to transmitting the request, the receipt status of at least one of the plurality of PDUs may be unknown (e.g., the at least one PDU may not yet have been received by the receiver). In this way, the receipt status report may be configured to identify the current status (e.g., missing / received / unknown) of the plurality of PDUs. The receipt status may comprise an acknowledgement (ACK) and / or a negative acknowledgement (NACK) which, respectively, indicate that at least one of the plurality of PDUs (e.g., the at least one PDU of the plurality of PDUs, and / or another PDU of the plurality of PDUs) has been received or has not been received by the receiver. The method may comprise determining whether to retransmit at least one PDU of the plurality of PDUs based on the receipt status report (e.g., based on the receipt status of at least one of the PDUs, as indicated by the report). The method may comprise determining whether to retransmit at least one PDU of the plurality of PDUs based on timing information associated with at least one PDU of the plurality of PDUs (e.g., the retransmitted PDU may be the same as the PDU corresponding to the timing information). The timing information may be indicative of a timer, in which case retransmission of at least one PDU of the plurality of PDUs may be performed if the remaining time of the timer is above a threshold value. In this way, the transmitter may not retransmit the at least one PDU if there is not enough time for the at least one PDU (and / or a subsequent PDU of a corresponding PDU Set) to be received by receiver. Retransmission of the PDU may be performed if the receipt status report indicates that the PDU has not been received by the receiver (e.g., if the receipt status comprises a NACK), or if the receipt status indicates that the status of the PDU is unknown (e.g., if the receipt status comprises an ACK, which may indicate that the PDU is expected by the receiver but has not yet been received). The request may be transmitted in dependence on time information associated with a plurality of PDUs (e.g., two or more PDUs of the plurality of PDUs).. A PDU of the plurality of PDUs may be associated with a PDU Set. The request may be transmitted in dependence on the remaining time for transmitting the PDU Set being less than a threshold value (e.g., a PDU Set threshold timer value). For example, a first PDU of the plurality of PDUs may be associated with a first PDU Set and a second PDU of the plurality of PDUs is associated with a second PDU Set different to the first PDU Set, wherein the request may be transmitted when the remaining time for transmitting at least one of the first PDU Set and the second PDU Set is less than a threshold value. The threshold value may be less than the PDU Set Delay Budget (e.g., less than two thirds, or half, the PDU Set Delay Budget), so as to allow enough time for retransmission of the missing PDU and / or any subsequent PDUs of the PDU Set. The request may be transmitted in dependence on an indication from a lower layer of the protocol stack of the availability of a transmission opportunity. In this way, the lower layer of the protocol stack may trigger the transmitter to prioritise the retransmission of a particular PDU, or PDU Set. The request may be transmitted in dependence on the detection of a gap in the sequence of the plurality of PDUs (e.g., which are positively acknowledged by the receiver). In this way, the transmitter may anticipate that the retransmission of the missing PDU can occur during the detected gap. The request may comprise information which directs the receiver to prohibit or suspend a timer relating to at least one of the plurality of PDUs (e.g., a ProhibitTimerDisable field or a ProhibitTimerSuspend field, respectively). The request may comprise a polling bit for requesting that the receiver send a status report relating to the plurality of PDUs. The request may comprise information which indicates when to report the receipt status of the plurality of PDUs. The request may comprise information which directs the receiver to report the receipt status of the plurality of PDUs immediately (e.g., upon receipt of the request from the transmitter). In this way, the received is enabled to effectively manage the receipt status reporting and prioritise the status reporting of those PDUs which are of upmost importance to the transmitter. The request may comprise information which directs the receiver to ignore a PDU reordering process (e.g., a IgnoreReassembly field). This enables the receiver to determine whether to ignore a process induced by a Hybrid Automatic Repeat Request (HARQ). The request may comprise information which indicates the plurality of PDUs whose receipt statuses are to be reported (e.g., a PDUsToACKList field). This enables the receiver to report the most relevant receipt status information to the transmitter. The request may comprise information which indicates to the receiver that the receipt status for at least one of the plurality of PDUs is critical (e.g., a CriticitalityLevel field). This allows the receiver to identify which of the plurality of PDUs is most likely to expire first. The request may comprise timing information for at least one the plurality of PDUs. For example, the request may comprise a field which includes timing information that is indicative of the remaining time before the expiry of the corresponding PDU Set Delay Budget. The request may comprise a sequence number associated with at least one of the plurality of PDUs. The request may be included in the header of a Data PDU for transmitting a data payload to the receiver. For example, the request may be c identifiable by at least one bit of the header of the Data PDU. In this way, the request does not require an additional communication between the transmitter and receiver, which thereby reduces the traffic within the network. The request may be included in a Control PDU for transmitting control information to the receiver. The Control PDU may not include a data payload. Accordingly, the transmitter is able to trigger the receipt request, even when there are no further PDUs to be transmitted to the receiver. In embodiments, the request may be identifiable by an identifier code with at least one bit of the Control PDU. The method at the receiver may comprise identifying that the request is transmitted in dependence on the timing information associated with at least one of the PDUs. The method at the receiver may comprise identifying the request in the header of a Data PDU for transmitting a data payload to the receiver. The request may be identified by an identifier coded with at least one bit of the Control PDU. The receipt status may comprise information which indicates whether or not at least one of the plurality of PDUs has been received by the receiver. The receipt status may comprise a sequence number for the at least one of the plurality of PDUs that has been received by the receiver. In embodiments, if at least one PDU of the plurality of PDUs is undergoing a reassembly process, then the status request and / or the reporting procedure may be configured so that the at least one PDU is considered to be lost (e.g., at least one of PDU is negatively acknowledged, NACK). The method at the receiver may comprise, after reporting the initial status report, prohibiting transmission of a further status report during a predetermined time period. For example, the method at the receiving may comprise starting a timer (e.g., t-StatusProhibit timer) after the transmission of the status report, wherein a further status report is prohibited from being reported (to the transmitter) until the timer has expired. Alternatively, a subsequent status report may be prohibited if it contains the same information as the first report. In this way, the transmission of the second status report too rapidly after the first status report is prevented, which thereby avoids wasting radio resources by reporting the same status information several times. The method at the receiver may comprise prohibiting, and / or suspending, a timer relating to at least one of the plurality of PDUs. For example, the timer may be prohibited, or suspended, in response to receiving a the request from the transmitter. For example, the polling bit may be configured to indicate when to report the receipt status of the plurality of PDUs. The method at the receiver may comprise immediately reporting the receipt status of the plurality of PDUs in response to the request from the transmitter. The method at the receiver may comprise determining a NACK status of at least one of the plurality of PDUs. For example, the NACK status may be determined based by comparing the sequence numbers of PDUs which have been received from the transmitter. The method may comprise setting a NACK status for at least one of the plurality of PDUs being associated with a timer (e.g., of the receiver and / or transmitter) which exceeds a threshold value. In this way, only a NACK status (which may trigger retransmission of the PDU) is set for those PDUs which will expire imminently. Reporting the receipt status of the plurality of PDUs may comprise transmitting a report which does not include timing information. For example, the report may comprise sequence numbers, only. In this way, the reporting procedure reduces the computational processing load required of the receiver to determine the timing information. Reporting the receipt status of the plurality of PDUs may comprise transmitting a report which includes timing information relating to at least on the plurality of PDUs. The method at the receiver may comprise ignoring a PDU reordering process in response to the request from the transmitter. 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. It will be understood that 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. The preceding summary is provided for purposes of summarising some examples to provide a basic understanding of aspects of the subject matter described herein. Accordingly, the above-described features should not be construed to narrow the scope or spirit of the subject matter described herein in any way. Moreover, the above and / or proceeding examples may be combined in any suitable combination to provide further exam pies, except where such a combination is clearly impermissible or expressly avoided. Other features, aspects, and advantages of the subject matter described herein will become apparent from the following text and the accompanying drawings. 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 is 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 is 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 user plane protocol stack of a 5G NR system as represented in Figure 1; Figure 5 is a flow chart illustrating a sequence exchange between an RLC transmitter and an RLC receiver of a wireless communication system; Figure 6 is a flow chart illustrating a method for triggering a RLC status report according to one or more embodiments of the disclosure; Figure 7 is a flow chart illustrating a sequence exchange between an RLC transmitter and an RLC receiver of a wireless communication system according to one or more embodiments of the disclosure; Figure 8 is a schematic diagram illustrating an example of RLC control PDU to transmit a RLC priority polling according to one or more embodiments of the disclosure; Figure 9 is a schematic diagram illustrating an example of a RLC data PDU to transmit a RLC priority polling according to one or more embodiments of the disclosure; Figure 10 is a schematic diagram illustrating an example of RLC status report format according to one or more embodiments of the disclosure; Figure 11a is a flow chart illustrating a method implemented at a RLC transmitter according to one or more embodiments of the disclosure; Figure 11b is a flow chart illustrating a method implemented at a RLC receiver according to one or more embodiments of the disclosure; and Figures 12 and 13 are schematic diagrams illustrating example message formats according to one or more embodiments of the disclosure. DETAILED DESCRIPTION Aspects and embodiments of the present disclosure will now be discussed with reference to the accompanying figures. Further aspects and embodiments will be apparent to those skilled in the art. 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 (XR) service. 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 one or more User Equipments (UE1 and UE2) 101, 151, which may be for example virtual reality helmets or extended reality wearables like glasses, served by a base station 111 to communicate with a core network, such as the 5G core network 102. A 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 111 is a network node which provides an access point to the core network for UEs and is part of the Radio Access Network (RAN) composed of the base stations 110, and 111. In 5G 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 example, 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 like UE1 101, UE2 151. Once a UE has established a Radio Resource Control (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) for 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. Taking the example of downlink transmission, XR data are 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 are transmitted by the base station 111 to the UE 101 through the Data Radio Bearer (DRB) 154. Figure 1 also shows the UE2 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 example 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 user position. The transceiver 235 is configured to provide bi-directional wireless communication with other wireless devices. For example, it provides the necessary modems (modulatordemodulator) 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 RLC transmitter and a RLC receiver. The RLC transmitter and the RLC receiver may be implemented by the processor 215. The RLC transmitter and the RLC receiver may be software only functions 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 connection 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 and whether the data belong to the control plane or the user 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 slots and frequency 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 RLC transmitter and a RLC receiver. The RLC transmitter and the RLC receiver may be implemented by the processor 315. The RLC transmitter and the RLC receiver may be 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 400 illustrating the user plane protocol stack of a 5G NR system as represented in Figure 1. The user plane protocol stack is described in detail in 3GPP document TS 23.501. Figure 4 shows a UE (e.g., like UEs 101, 151 of Figure 1), a base station (gNB) (e.g., like the gNBs 110, 111 of Figure 1), a User Plane Function (UPF) (e.g., like UPF 161 of Figure 1), and a Data Network (DN) (e.g., like DN 160 of Figure 1). In embodiments, there may be an intermediate UPF(s), like UPF 421, between the gNB and the anchor UPF 422 connecting to the DN 160. The interface between the UE and the gNB is the Uu interface comprised of the SDAP layer 407, the PDCP layer 401, the RLC layer 408, the MAC layer 410, and the PHY layer 411. The interface between the gNB and the UPF 160 is the NG-U interface comprised of the GTP-U layer 404, the User Datagram Protocol (UDP) layer 412, the Internet Protocol (IP) layer 413, a data link (L2) layer 414, and a physical link (L1) layer 415. Any data link layer 604 and physical layer 605 that fulfil the requirements of upper layers 404, 412, 413 may be used. For example, these layers can be implemented with Ethernet protocol over fibre cables. In the gNB 110, 111, a relay layer 406 enables the bridging between SDAP layer 407 and GTP-U layer 404, while in the intermediate UPF(s) 421, a relay layer 416 enables the bridging between the GTP-U layers 404. The interface between the UPF 422 and the DN 160 is the N6 interface (as described in TS 23.501). The interface may rely on the same data link layer 604 and physical layer 605 as for the NG interface. 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 handles 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 PDUs correspond to Ethernet frames; etc. At the start of a PDU session (i.e., at a PDU establishment time) in the downlink direction, the core network provides QoS parameters to the UPF, gNB and UE. The QoS parameters of a PDU session for XR application include the XR PDU Set QoS parameters (as defined in S2-2302696): A. PDU Set delay budget (PSDB); B. PDU Set error rate (PSER); and C. PDU Set integrated handling indication (PSIHI), which is also 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 RLC PDU, or MAC PDU. When the PDUs arrive at the PDU layer 402 of UPF 161, the UPF performs an application packet inspection to determine the PDU Set boundaries. 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. As described in 3GPP document S2-2303842, PDU Set identification information is determined by the UPF and sent to the NG-RAN in the GTP-U header. The PDU Set identification Information comprises: A. PDU Set sequence number; B. indication of the end PDU of the PDU Set; C. PDU sequence number within a PDU Set; D. PDU Set size; and E. PDU Set importance, which identifies the relative importance of a PDU Set compared to other PDU Sets within a QoS flow. In the uplink direction the application data are generated in the UE. The UE obtains the QoS parameters of a PDU session 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 layer 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). For both downlink and uplink, the application 103 sends and receives data to / from the NG-RAN through a General Packet Radio Service (GPRS) tunnel with GTP-U layer 404, as defined in TS 29.281. In 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). In 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 downlink, multiple PDU Sets can be mapped to the same, or different, QoS flow(s) in an XR session (e.g., a single XR session) in uplink. In 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. 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). In 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 flow 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). In certain situations, some of the XR data may become obsolete (e.g., useless to the decoder) after a delay period has elapsed. 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 with regard to the PDU Set Delay Budget (PSDB). The gNB in downlink, or the UE in uplink, 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 with transmission still pending) are useless to the decoder after the PSDB has elapsed. The RLC protocol layer can operate in three modes: A transparent mode (TM) during which data are transmitted with no header or any protocol implementation; an unacknowledged mode (UM) which implements segmentation and duplication detection; and finally, an acknowledged mode (AM) which implements the same functions as the UM mode but with the addition of a retransmission mechanism (e.g., an automatic repeat request (ARQ)). RLC AM is used when the reliability provided by lower layers of the protocol stack (e.g., PHY and MAC) needs to be enhanced. The retransmission procedure of RLC AM is parametrised and configured by the gNB. One important parameter is the maximum number of allowed retransmissions (e.g., “maxRetxThreshold” in TS 38.322) for one RLC SDU (or one RLC SDU segment). In a situation where an RLC SDU (or RLC SDU segment) has been transmitted by the RLC transmitter, but not received by the RLC receiver, then the RLC transmitter is configured to retransmit the missing RLC SDU (or RLC SDU segment). Several retransmissions of the missing RLC SDU may occur (e.g., at scheduled intervals) until a certain condition is met. For example, the retransmissions may repeat until the RLC transmitter determines that the RLC SDU (or RLC SDU segment) has been received. RLC AM is configured to reset the current session and to trigger a Radio Link Failure (RLF) when the maximum number of retransmissions of a single RLC SDU (or RLC SDU segment) has been reached (or exceeded). The retransmission procedure of RLC AM also relies on the RLC receiver which sends status reports indicating the status of received RLC SDUs (and RLC SDU segments) to the RLC transmitter, which in return will schedule retransmission of lost RLC SDUs and update the transmitting window. Status reporting at the RLC receiver is triggered either on demand by the RLC transmitter (e.g., a polling bit) or by the detection by the RLC receiver of a lost RLC SDU. An RLC SDU (or RLC SDU segment) is detected as lost when both a sequence number gap (or segment offset gap) is detected and a timer (e.g., t-Reassembly as described in TS 38.322) is elapsed (or expired). Thus, at the RLC transmitter side the decision to retransmit a RLC SDU (or RLC SDU segment) is delayed both by polling and by the t-Reassembly timer. While the described procedure may reduce the overhead within the network (and / or the total number of retransmissions), the reliance on status reports introduces additional delays when the lower layers of the protocol stack eventually fail to transmit the RLC SDU (or RLC SDU segment) correctly. For certain applications that require both high reliability and low latency (e.g., XR), this additional delay is not acceptable. Furthermore, delaying the retransmission of one RLC SDU can also have a negative consequence on the broader transmitting window management. The transmitting window is defined between a lower and an upper bound of RLC SDU sequence numbers. In this way, it defines the RLC SDUs that are eligible to be transmitted. The transmitting window is updated by both incrementing the lower and upper bounds. Thus, the transmitting window is only updated when the reception status of the lower bound RLC SDU is confirmed, otherwise it stays unchanged even if new RLC SDUs are provided by upper layer (e.g., PDCP) for transmission. For example, a second PDU Set transmission can be stalled because the reception status of one RLC SDU of a first PDU Set is not confirmed and the sequence numbers of the RLC SDUs from a second PDU Set are out of the transmitting window. This phenomenon is also known as transmitting window stalling. This problem will now be described in more detail with reference to Figure 5. Figure 5 is a flow chart showing an example of a sequence exchange 500 between an RLC transmitter 501 and an RLC receiver 502. This example illustrates the status reporting mechanism implemented with RLC AM. It shows a sequence of transmissions by the RLC transmitter 501 of RLC SDUs with sequence numbers 1 to 4 from a first PDU Set (PDU Set 1) 521, and of a RLC SDU from a second PDU Set (PDU Set 2) 522. It also shows the transmissions by the RLC receiver 502 of RLC status reports. To simplify the illustration, it is assumed that there is no need for segmentation of RLC SDUs, and that one RLC SDU corresponds to one RLC PDU. During a first transmission 503, RLC SDU 1 is sent by the RLC transmitter 501 and is correctly received by the RLC receiver 502. At this stage the RLC receiver 502 does not send a status report because there is no valid trigger for it. There are two triggers for sending a status report by the RLC receiver 502, namely a missing SDU detection by the RLC receiver 502, and a detection of a polling bit inserted into the header of a transmitted data PDU (e.g., the polling bit having been inserted by the RLC transmitter 501). Considering the second transmission 502, RLC SDU 2 is sent by the RLC transmitter 501 with a polling bit set in the header of the RLC PDU containing RLC SDU 2. RLC SDU 2 is also correctly received by the RLC receiver 502. Due to the presence of the polling bit, the RLC receiver 502 sends a status report 505 back to the RLC transmitter 501. The status report contains a positive acknowledgement (ACK) for RLC SDU 3, indicating that RLC SDU 3 is the next RLC SDU expected at the RLC receiver 502. The RLC transmitter 501 interprets the status report to mean that all SDUs with sequence numbers below 3 have been correctly received by the RLC receiver 502. The RLC transmitter 501 then updates the transmitting window taking into account that RLC SDUs 1 and 2 are correctly received. When transmitting a RLC status report, the RLC receiver 502 may start a timer (e.g. t-StatusProhibit as described in TS 38.322) which prevents another RLC status report from being sent before this timer has elapsed. The aim is to limit the overhead generated by sending several RLC status report during a short time period. This t-StatusProhibit may be configured with a null value so that it has no effect in the RLC AM operation. In a subsequent (i.e., third) transmission 506, RLC SDU 3 is sent by the RLC transmitter 501 but is not received by the RLC receiver 502, for example because of bad radio conditions during the transmission 506. At the RLC receiver 502 nothing happens. However, the RLC receiver is still expecting RLC SDU 3 as the next RLC SDU to be received. The next (i.e., fourth) transmission 507 involves RLC SDU 4 being sent by the RLC transmitter 501 and being correctly received at the RLC receiver 502. When receiving RLC SDU 4, the RLC receiver 502 detects that RLC SDU 3 is missing because of the sequence number (SN) gap (i.e., RLC SDU 3 has an unknown status). At that point, RLC SDU 3 is not considered as lost. Nevertheless, the RLC receiver 502 starts t-Reassembly timer 508 (as described in TS 38.322) waiting for the correct reception of RLC SDU 3. The goal of the network is to wait for low level retransmissions to fix the issue. So, at the reception of RLC SDU 4 (i.e., with transmission 507), there is no status report triggered at the RLC receiver 502. A subsequent transmission 509 involves the RLC transmitter 501 sending RLC SDU 5 with a polling bit, which is correctly received by the RLC receiver 502. At this point the t-Reassembly timer is still running and the RLC receiver 502 is still expecting RLC SDU 3 as the next RLC SDU to be received. Answering to the polling bit, the RLC receiver 502 sends back a status report 510 to the RLC transmitter 501. The status report contains a positive acknowledgement (ACK) for RLC SDU 3, meaning that RLC SDU 3 is the next SDU expected at the RLC receiver. The RLC transmitter 501 interprets the status report to mean that RLC SDU 3 is missing but not lost (i.e., RLC SDU 3 has an unknown status), the status of RLC SDU 4 is also unknown, and the status of RLC SDU 5 is likely to be correctly received because a status report was sent after the transmission of the polling bit included with RLC SDU 5. However, the RLC transmitter 501 cannot update the transmitting window with this information because the status of RLC SDU 3 is still unknown. The RLC status report 510 may be sent only when the timer t-StatusProhibit has expired. When the t-Reassembly timer elapses (or expires), the RLC receiver 502 considers that RLC SDU 3 is lost (i.e., the status of RLC SDU 3 is no longer unknown because the RLC receiver 502 concludes that RLC SDU 3 will not be received). The RLC receiver 502 may restart the t-Reassembly timer (or not) and sends a status report to the RLC transmitter 501 through the transmission 511. The status report contains both a negative acknowledgement (NACK) for RLC SDU 3 and a positive acknowledgement (ACK) for RLC SDU 6. The RLC transmitter 501 interprets the status report to mean that RLC SDU 3 is lost and shall be retransmitted. Furthermore, the RLC transmitter 501 interprets that all RLC SDUs below sequence number 6 and above sequence number 3 have been correctly received by the RLC receiver 502. So, the reception status of RLC SDU 4 and RLC SDU 5 are confirmed to be good (i.e., their status is known as having been correctly received), whereas RLC SDU 3 shall be retransmitted and the transmitting window still cannot be updated. During a further transmission 512, the RLC transmitter 501 performs the first retransmission of the RLC SDU 3 which is this time correctly received by the RLC receiver 501. However, the correct reception of RLC SDU 3 occurs after the PDU Set Delay Budget of PDU Set 1, 521, has expired. In case the application needs to receive the whole PDU Set 1 on time to process it, it means that the transmission of the whole PDU Set 1, 521, has failed and it is useless for the application. Moreover, some radio bandwidth has been wasted by transmitting and retransmitting useless RLC SDUs. To cope with this situation and to reduce the cases with useless RLC SDUs transmission, it is proposed some enhancements of polling and status report triggering in RLC, as described with the following figures. Figure 6 is a flow chart illustrating a method 600 for triggering a RLC status report according to one or more embodiments of the disclosure. This figure shows a RLC transmitter 601 and a RLC receiver 602. For downlink transmissions, the RLC transmitter 601 may be implemented in a gNB (e.g., like gNBs 110, 111 of Figure 1), and the RLC receiver 602 may be implemented in a UE (e.g., like UEs 101, 151 of Figure 1). For uplink transmissions, the RLC transmitter 601 may be implemented in a UE (e.g., like UEs 101, 151 of Figure 1), and the RLC receiver 602 may be implemented in a gNB (e.g., like gNBs 110, 111 of Figure 1). The transmission 611 illustrates the sending of a RLC priority polling by the RLC transmitter 601 to the RLC receiver 602. The aim of the RLC priority polling is to generate a new triggering condition in the RLC receiver 602 to send back a RLC status report. The RLC priority polling 611 may be sent when the RLC transmitter 501 detects the need to update the status of RLC SDUs (and RLC SDU segments) already transmitted to the RLC receiver 602, and for which the reception status is currently unknown. The transmission of RLC priority polling 611 at the RLC transmitter 601 may be triggered by the detection that the PDU Set Delay Budget (PSDB) for a PDU Set has reached a predefined threshold (e.g. half of the PSDB, or two-thirds of the PSDB), meaning that the RLC transmitter 601 may soon run out of time to retransmit RLC SDUs (and RLC SDU segments) that would be indicated as lost by the RLC receiver 602. The RLC transmitter 601 may refrain from sending this RLC priority polling if the RLC transmitter 601 has just sent a RLC PDU with the legacy polling bit set to true (as defined in TS 38.322). Also, the RLC transmitter 601 will not send the RLC priority polling if the RLC transmitter 601 already knows the reception status for all the RLC SDUs (and RLC SDU segments) sent to the RLC receiver 602 for the considered PDU Set. The RLC transmitter 601 may not send the RLC priority polling if the remaining amount of data related to the considered PDU Set to be sent is below a predefined threshold (e.g., 8 Kbytes). The RLC transmitter 601 may refrain from sending the RLC priority polling if the PSIHI of the considered PDU Set is set to false, meaning that the application at the receiver side may be able to use the data belonging to the considered PDU Set even if the PDU Set has not been completely received. Upon reception of the RLC priority polling 611, the RLC receiver 602 may immediately trigger the transmission 612 of a RLC status report to the RLC transmitter 601. This means that the RLC receiver 602 by-passes the legacy triggering conditions to send a RLC status report associated to the legacy polling bit, or triggered at the expiry of t-Reassembly timer. For example, the RLC receiver 602 may not take into account the t-StatusProhibit timer (which may be stopped or which may continue running). Besides, the RLC receiver 602 may refrain from sending the RLC status report 612 if an RLC status report was already sent just before the reception of RLC priority polling 611. According to an alternative arrangement, the content of RLC status report 612 may be different from the content of a RLC status report sent upon reception of a RLC PDU with the legacy polling bit set to true or at the expiry of t-Reassembly timer. The RLC status report 612 may indicate that a RLC SDU (or RLC SDU segment) is lost (i.e., NACK RLC SDU or RLC SDU segment) even if the t-Reassembly timer is still running, and that the RLC receiver 602 will not wait for the result of reliability mechanisms in lower layers (e.g., after HARQ reordering in the MAC layer). Still, the RLC receiver 602 may receive some feedback from the low layers to evaluate the probability of correctly receiving a missing RLC SDU (or RLC SDU segment). If the lower layers are about to complete the reception of a RLC SDU, the RLC receiver 602 may consider this RLC SDU as not lost and will not indicate this RLC SDU as lost (i.e., as a NACK RLC SDU) in the RLC status report 612. In the RLC status report, the RLC SDU(s) reported as lost even if the t-Reassembly timer is still running may be tagged with an information element so that the RLC transmitter can understand that the corresponding RLC SDU may be correctly received later at the RLC receiver. Figure 7 is a flow chart illustrating a sequence exchange 700 between an RLC transmitter 701 and an RLC receiver 702 of a wireless communication system according to one or more embodiments of the disclosure. For downlink transmissions, the RLC transmitter 701 may be implemented in a gNB (e.g., likegNBs 110,111 of Figure 1), and the RLC receiver 702 may be implemented in a UE (e.g., like UEs 101,151 of Figure 1). For uplink transmissions, the RLC transmitter 701 may be implemented in a UE (e.g., like UEs 101, 151 of Figure 1), and the RLC receiver 702 may be implemented in a gNB (e.g., like gNBs 110, 111 of Figure 1). The example shown in Figure 7 is similar to the example shown in Figure 5. It shows a sequence of transmissions by the RLC transmitter 701 of RLC SDlls with sequence numbers from 1 to 4 from a first PDU Set (PDU Set 1) 721, and of a RLC SDU from a second PDU Set (PDU Set 2) 722. It also shows the transmissions by the RLC receiver 702 of RLC status reports. To simplify the illustration, it is assumed that there is no need for segmentation of RLC SDUs, and that one RLC SDU corresponds to one RLC PDU. During a first transmission 703, RLC SDU 1 is sent by the RLC transmitter 701 and is correctly received by the RLC receiver 702. At this stage the RLC receiver 702 does not send a status report because there is no valid trigger for it. Considering the second transmission 702, RLC SDU 2 is sent by the RLC transmitter 701 with a polling bit set in the header of the RLC PDU containing RLC SDU 2. RLC SDU 2 is also correctly received by the RLC receiver 702. Due to the presence of the polling bit, the RLC receiver 702 sends a status report 705 back to the RLC transmitter 701. The status report contains a positive acknowledgement (ACK) for RLC SDU 3, indicating that RLC SDU 3 is the next RLC SDU expected at the RLC receiver 702. The RLC transmitter 701 interprets the status report to mean that all RLC SDUs with sequence numbers below 3 have been correctly received by the RLC receiver 702. The RLC transmitter 701 then updates the transmitting window, whilst taking into account that RLC SDUs 1 and 2 are correctly received. When transmitting a RLC status report, the RLC receiver 702 may start a timer (e.g. t-StatusProhibit as described in TS 38.322) which prevents the sending of another RLC status report before this timer has elapsed (or expired). In a subsequent (i.e., third) transmission 706, RLC SDU 3 is sent by the RLC transmitter 701 but is not received by the RLC receiver 702, for example because of bad radio conditions during the transmission 706. At the RLC receiver 702 nothing happens. However, the RLC receiver is still expecting RLC SDU 3 as the next RLC SDU to be received. The next (i.e., fourth) transmission 707 involves RLC SDU 4 being sent by the RLC transmitter 701 and being correctly received at the RLC receiver 702. When receiving RLC SDU 4, the RLC receiver 702 detects that RLC SDU 3 is missing because of the sequence number (SN) gap (i.e., RLC SDU 3 has an unknown status). At that point, RLC SDU 3 is not considered as lost. Nevertheless, the RLC receiver 502 starts t-Reassembly timer 708 (as described in TS 38.322) waiting for the correct reception of RLC SDU 3. The goal of the network is to wait for low level retransmissions to fix the issue. So, at the reception of RLC SDU 4 (i.e., with transmission 707), there are no status reports triggered at the RLC receiver 702. Prior to the RLC SDU 4 transmission 706, the RLC transmitter 701 has detected that the remaining time to transmit PDU Set 1 (721) is less than a predefined threshold (for example, less than half the PDU Set Delay Budget). Also at that time, the RLC transmitter 701 does not know the status of RLC SDU 3 and thus if retransmission of RLC SDU 3 is necessary. Then, the RLC transmitter decides to transmit a RLC priority polling to the RLC receiver 702 to get an update of RLC SDUs status. Two possible methods to send the RLC priority polling are illustrated with the example of Figure 7. In a first option, the RLC transmitter 701 insert a priority polling bit in the header of a data RLC PDU. In the example of Figure 7, the priority polling is inserted in the header of the RLC PDU containing the RLC SDU 4 (transmission 707). In a second option, the RLC transmitter 701 sends a dedicated RLC control PDU 709 at the first transmission opportunity. Upon reception of RLC priority polling, the RLC receiver 702 triggers the transmission of a RLC status report 710 to the RLC transmitter 701. Instead of building a legacy RLC status report, the RLC receiver 702 adapts the content because the trigger is a RLC priority polling. The RLC receiver 702 may consider that the RLC SDU 3 is lost, while it is normally not the case as t-Reassembly timer 708 is started to wait for the correct reception of this RLC SDU. Then, the status report 710 indicates that RLC SDU 3 is lost (i.e. sequence number 3 has NACK status), and the next RLC SDU expected at the RLC receiver 702 is RLC SDU 5 (i.e sequence number 5 has the ACK status). The timer t-StatusProhibit may be started by the RLC receiver 702 after the transmission of the status report 710 to prevent from the transmission of another status report too rapidly after the status report 710 (e.g., to avoid wasting radio resources by sending several times the same status information). Upon reception of the RLC status report 710, the RLC transmitter 701 interprets that RLC SDU 4 is correctly received, RLC SDU 3 is lost, and its retransmission shall be scheduled. Thus, the retransmission 711 of RLC SDU 3 is performed at the next transmission opportunity. In the example of Figure 7, the retransmission 711 of RLC SDU 3 is correctly received at the RLC receiver 702 within the PDU Set Delay Budget for PDU Set 1 (721). Upon the successful reception of RLC SDU 3, the RLC receiver 702 can stop the t-Reassembly timer 708 if this timer is still running. Thus, thanks to the priority polling, the RLC transmitter 701 has received the information that a problem occurred with the transmission of RLC SDU 3, early enough to retransmit RLC SDU 3 within the PDU Set Delay Budget. Finally, the RLC transmitter 701 starts the transmission of PDU Set 2 (722) with the transmission 712 of RLC SDU 5. Figure 8 is a schematic diagram illustrating an example of RLC control PDU 800 to transmit a RLC priority polling according to one or more embodiments of the disclosure. The format is based on the description of RLC control PDU format in 3GPP document TS 38.322. RLC control PDU is a bit string that is byte aligned (i.e., multiple of 8 bits) in length. In the Figure 8, the bit string is represented by a table in which the first and most significant bit is the left most bit of the first line of the table, the last and least significant bit is the rightmost bit of the last line of the table, the bit string is to be read from left to right and then in the reading order of the lines. The first byte is reference 801 and other bytes are reference 802, the box 802 may be composed of several bytes depending on the information included in the RLC control PDU 800. The most significant bit of byte 801 is the D / C field indicating whether the RLC PDU is an RLC data PDU or RLC control PDU. The 3 bits following the D / C bit represent the Control PDU Type (CPT) field indicating the type of the RLC control PDU. For a RLC control PDU to transmit a RLC priority polling, the value of the D / C field is “0” and the value of CPT field is, for example, “010”. The bytes 802 may include all or part of the following fields: ProhibitTimerDisable or ProhibitTimerSuspend: these fields may be used by the RLC transmitter to request the RLC receiver to disable or suspend or reset the t-StatusProhibit timer. The RLC receiver may reject this request. PriorityPolling: this field may be used by the RLC transmitter to request the RLC receiver to send a status report. This status report may be sent immediately after the reception of RLC control PDU 800 without considering the t-Reassembly timer (and thus the HARQ process). IgnoreReassembly: this field may be used by the RLC transmitter to request the RLC receiver to ignore the process induced by HARQ. PDUsToACKList: this field may be used by the RLC transmitter to indicate to the RLC receiver which RLC SDUs status have to be provided. For example, it may be a list of RLC SDUs and RLC SDU segments for which the status is needed because the corresponding PDU Set Delay Budget is close to expiration. This field may be formatted with a list of sequence numbers or a range of sequence numbers. Segment offsets may be associated to a sequence number to request the status of RLC SDU segments. - CriticitalityLevel: this field may be used by the RLC transmitter to inform the RLC receiver on the criticality level for the RLC transmitter to get the status for a given RLC SDU or a list of RLC SDUs. This field may be formatted with a list of sequence numbers or a range of sequence numbers. Segment offsets may be associated to a sequence number to indicate the criticality level of RLC SDU segments. This field may include timing information, for example the remaining time before the expiry of the corresponding PDU Set Delay Budget. Figure 9 is a schematic diagram illustrating an example of RLC data PDU 900 to transmit a RLC priority polling with RLC AM according to one or more embodiments of the disclosure. The format is based on the description of RLC data PDU formats in 3GPP document TS 38.322. RLC data PDU is a bit string that is byte aligned (i.e. multiple of 8 bits) in length. In Figure 9, the bit string is represented by a table in which the first and most significant bit is the left most bit of the first line of the table, the last and least significant bit is the rightmost bit of the last line of the table, the bit string is to be read from left to right and then in the reading order of the lines. The header may be composed of the bytes with references 901 to 905, while the payload containing the application data are represented by other bytes with reference 906, the box 906 may be composed of several bytes depending on the amount of application data included in the RLC data PDU 900. The most significant bit of byte 901 is the D / C field indicating whether the RLC PDU is an RLC data PDU or RLC control PDU. The following bit is the polling bit field. For a RLC data PDU to transmit a legacy RLC polling, the value of the polling bit is “1”. The two bits following the polling bit represent the Segmentation Information (SI) to indicate whether the RLC PDU contains a complete RLC SDU or the first, middle, last segment of an RLC SDU. The value “00” indicates that the Data field 906 contains all bytes of an RLC SDU (i.e. there is no segmentation), the value “01” indicate that the Data field 906 contains the first segment of an RLC SDU, the value “10” indicates that the Data field 906 contains the last segment of an RLC SDU, and the value “11” indicates that the Data field 906 contains neither the first nor last segment of an RLC SDU. For other fields, the format of a RLC data PDU depends on the length of the sequence number and on the presence of segmentation. For a RLC data PDU with 12 bit sequence number without segmentation, the four less significant bits of byte 901 and byte 902 represent the sequence number. The bytes 903, 904, and 905 are not present. For a RLC data PDU with 18 bit sequence number without segmentation, the two less significant bits of byte 901, byte 902, and byte 903 represent the sequence number. The bytes 904 and 905 are not present. The fifth bit (from the left) of byte 901 may be the RLC priority polling bit set to the value “1” when the RLC transmitter wants to transmit a RLC priority polling to the RLC receiver. The sixth bit (from the left) of byte 901 may be a reserved bit without dedicated function. According to an alternative arrangement, the fifth and sixth bit of byte 901 may be used as: ProhibitTimerDisable or ProhibitTimerSuspend field, used by the RLC transmitter to request the RLC receiver to disable or suspend or reset the t-StatusProhibit timer. The RLC receiver may reject this request. IgnoreReassembly field, used by the RLC transmitter to request the RLC receiver to ignore the process induced by HARQ. For a RLC data PDU with 12 bit sequence number with segmentation, the four less significant bits of byte 901 and byte 902 represent the sequence number, the bytes 904 and 905 represent the Segment Offset (SO) field. The SO field indicates the position of the RLC SDU segment in bytes within the original RLC SDU. Specifically, the SO field indicates the position within the original RLC SDU to which the first byte of the RLC SDU segment in the Data field 906 corresponds. The first byte of the original RLC SDU is referred by the SO field value "0000000000000000", i.e., numbering starts at zero. For a RLC data PDU with 18 bit sequence number with segmentation, the two less significant bits of byte 901, byte 902, and byte 903 represent the sequence number. The bytes 904 and 905 represent the Segment Offset (SO) field. The fifth bit (from the left) of byte 901 may be the RLC priority polling bit set to the value “1” when the RLC transmitter wants to transmit a RLC priority polling to the RLC receiver. The sixth bit (from the left) of byte 901 may be a reserved bit without dedicated function. Accoring to an alternative arrangement, the fifth and sixth bit of byte 901 may be used as ProhibitTimerDisable or ProhibitTimerSuspend field, and IgnoreReassembly field, as described above. Figure 10 is a schematic diagram illustrating an example of RLC status report 1000 according to one or more embodiments of the disclosure. This RLC status report is triggered by the reception in a RLC receiver (e.g., receiver 702 shown in Figure 7) operating in RLC AM of a RLC priority polling sent by a peer RLC transmitter (e.g., transmitter 701 shown in Figure 7). According to an aspect of the present disclosure, the format of the RLC status report 1000 corresponds to the legacy RLC status report formats defined in 3GPP document TS 38.322. RLC status report is a bit string that is byte aligned (i.e. multiple of 8 bits) in length. In the Figure 10, the bit string is represented by a table in which the first and most significant bit is the left most bit of the first line of the table, the last and least significant bit is the rightmost bit of the last line of the table, the bit string is to be read from left to right and then in the reading order of the lines. There are two different formats depending on the length (e.g., 12 bits or 18 bits) of RLC SDU sequence numbers. Basically, the status report indicates one RLC SDU sequence number with a positive acknowledgment (ACK SN) to indicate the next RLC SDU SN to be received, and a list of RLC SDU sequence number(s) with a negative acknowledgment (NACK SN) to indicate the RLC SDU(s) detected as lost. In case of segmentation, two fields (SOstart and SOend) indicate the portion of the RLC SDU with SN = NACK_SN, which has been detected as lost at the RLC receiver. The SOstart field indicates the position of the first byte of the portion of the RLC SDU in bytes within the original RLC SDU. The SOend field indicates the position of the last byte of the portion of the RLC SDU in bytes within the original RLC SDU. Upon reception of the RLC status report, the RLC transmitter understands that for RLC SDUs with a sequence number equal or above the ACK SN, the reception status is unknown. According to another aspect of the present disclosure, the format of RLC status report 1000 is enhanced to include a timing information to indicate the remaining time for the t-Reassembly timer (i.e., if this timer is running). Thanks to this information, the RLC transmitter may evaluate if the NACK SN(s) can be recovered or not at RLC transmitter side. Indeed, if the t-Reassembly timer is about to expire, the probability to recover the missing RLC SDU(s) at the RLC receiver may be considered as low. In this situation, the RLC transmitter may consider the scheduling of the retransmission of NACK SN(s), especially if the remaining time compared to the corresponding PDU Set Delay Budget is low. In Figure 10, the format of RLC status report 1000 assumes 18-bit length SNs. However, it can be adapted to support 12-bit length SNs as for the legacy RLC status report described in TS 38.322. The RLC status report 1000 consists of a payload, and an RLC control PDU composed of a D / C and a CPT field positioned at the most significant bits of byte 1001. For a legacy RLC status report the value of D / C field is “0” and the value of CPT field is “000”. For an enhanced RLC status report the value of D / C field is “0” and the value of CPT field is for example “001”. The payload part of RLC status report 1000 starts with the fifth bit of byte 1001. The remaining bits of byte 1001, the byte 1002, and the six most significant bits of byte 1003 represent the ACK SN (i.e. the next expected RLC SDU SN, so a RLC SDU with unknown reception status for the RLC transmitter). The field E4 of byte 1003 indicates if a timing information follows: value “1” if there is a timing information, value “0” if there is no timing information in the RLC status report. The field E1 of byte 1003 indicates whether or not a set of NACK SN follows: value “1” if a set of NACK SN(s) follows, value “0” if there is no NACK SN in the RLC status report. If present, the byte 1004 and the six most significant bits of byte 1005 represent the timing information. The 14-bit length value of the timing information may represent a number of 20ns periods indicating the remaining time of t-Reassembly timer with an accuracy of 20ns. The field E1 of byte 1005 indicates whether or not a set of NACK SN follows: value “1” if a set of NACK SN(s) follows, value “0” if there is no NACK SN in the RLC status report. The field R of byte 1005 is a reserved bit in this example. If present, bytes 1006, 1007, and the two most significant bits of byte 1008 represents a NACK SN. The field E1 of byte 1008 indicates whether or not a set of NACK SN follows: value “1” if a set of NACK SN(s) follows, value “0” if there is no other NACK SN in the RLC status report. The field E2 of byte 1008 indicates whether or not a set of SOstart and SOend follows: value “1” if a set of SOstart and SOend follows (case of a portion of RLC SDU is lost), value “0” if there is no SOstart and SOend. The field E3 of byte 1008 indicates whether or not information about a continous sequence of RLC SDUs that have not been received follows: value “0” if a NACK range field does not follow for this NACK_SN, value “1” if a NACK range field follows for this NACK_SN. The NACK range field is the number of consecutively lost RLC SDUs starting from and including NACK_SN. The field E5 of byte 1008 may indicate whether or not the corresponding RLC SDU is assumed as lost. The value “1” may indicate that the RLC receiver has considered the corresponding RLC SDU (or portion of RLC SDU) as lost while the timer t-Reassembly was still running. The value “0” may indicate that the RLC corresponding RLC SDU (or portion of RLC SDU) is effectively lost (then it has the same meaning as the legacy RLC status report). The fields R in byte 1008 are reserved bits without defined function yet. The bytes 1009 to 1011 illustrate the presence of another NACK SN for which the corresponding RLC SDU is entirely lost. The bytes 1012 to 1015 illustrate the presence of another NACK SN with only a missing portion of the corresponding RLC SDU. The byte 1016 illustrates the presence of NACK range following the NACK SN indicated with bytes 1009 to 1011. The bytes 1017 to 1019 illustrate the presence of another NACK SN for which the corresponding RLC SDU is entirely lost. Finally, the box 1020 indicates that other NACK SN(s) may follow. Figure 11a is a flow chart 1100 illustrating a method implemented at a RLC transmitter according to one or more embodiments of the disclosure. For example, with reference to the communication system 100 shown in and described with respect to Figure 1, the RLC transmitter may be implemented in the UE1 101 and the peer RLC receiver may be implemented in the gNB2 111. In another example, the RLC transmitter may be implemented in the gNB2 111 and the peer RLC receiver may be implemented in the UE1 101. The method 1100 as shown in and described with respect to Figure 11a may be performed by software elements and / or hardware elements. The RLC transmitter may be implemented in a network node 205 as shown in and described with reference to Figure 2 with the method as shown in and described with respect to Figure 11a being performed by an apparatus including one or more processing units, such as the processing unit 215. The RLC transmitter may also be implemented in a network node 305 as shown in and described with reference to Figure 3 with the method as shown in and described with respect to Figure 11a being performed by an apparatus including one or more processing units, such as the processing unit 315. At step 1101, the RLC transmitter detects conditions to send a RLC priority polling to the peer RLC receiver. The triggering conditions are described in the Figures 6 and 7. At step 1102, the RLC transmitter builds the RLC priority polling within a RLC PDU. As described with the Figures 8 and 9, it may be a RLC priority polling within a RLC control PDU or within the header of a RLC data PDU. At step 1103, the RLC transmitter sends the RLC PDU indicating the RLC priority polling to the peer RLC receiver. At step 1104, in response to the RLC priority polling sent at step 1103, the RLC transmitter receives a RLC status report from the peer RLC receiver. At step 1105, the RLC transmitter selects RLC SDU(s) and / or RLC SDU segment(s) to be retransmitted according to the received RLC status report. The selected RLC SDU(s) or part(s) of RLC SDU(s) for retransmission may correspond to the list of RLC SDU(s) or part(s) of RLC SDU(s) indicated as lost (i.e. associated to a NACK SN in the received RLC status report as described in the Figure 10) and with an unknown status (i.e., associated to the ACK SN in the received RLC status report as described in the Figure 10). Besides, the retransmission of a selected RLC SDU may be conditioned by the remaining time before the expiry of the corresponding PDU Set Delay Budget. For example, the RLC transmitter may decide to retransmit a RLC SDU if the remaining time is above a configured threshold (for example, 1ms or 10% of the PDU Set Delay Budget or 1ms), or if the next transmission opportunity happens before the expiry of the PDU Set Delay Budget. At step 1106, the RLC transmitter retransmits the RLC SDU(s) and / or RLC SDU segment(s) selected at step 1105. Figure 11b is a flow chart 1110 illustrating a method implemented at a RLC receiver according to one or more embodiments of the disclosure. For example, with reference to the communication system 100 shown in and described with respect to Figure 1, the RLC receiver may be implemented in the UE1 101 and the peer RLC transmitter may be implemented in the gNB2 111. In another example, the RLC receiver may be implemented in the gNB2 111 and the peer RLC transmitter may be implemented in the UE1 101. The method 1110 as shown in and described with respect to Figure 11b may be performed by software elements and / or hardware elements. The RLC receiver may be implemented in a network node 205 as shown in and described with reference to Figure 2 with the method as shown in and described with respect to Figure 11 b being performed by an apparatus including one or more processing units, such as the processing unit 215. The RLC receiver may also be implemented in a network node 305 as shown in and described with reference to Figure 3 with the method as shown in and described with respect to Figure 11b being performed by an apparatus including one or more processing units, such as the processing unit 315. At step 1111, the RLC receiver receives a RLC PDU with a RLC priority polling from the peer RLC transmitter. As described with the Figures 8 and 9, it may be a RLC priority polling indication within a RLC control PDU or within the header of a RLC data PDU. At step 1112, the RLC receiver detects if certain conditions are met to send a RLC status report to the peer RLC transmitter. The triggering conditions are described in Figures 6 and 7. At step 1113, in response to the RLC priority polling, the RLC receiver builds a RLC status report (as described with the Figures 6 and 7). At step 1114, the RLC receiver sends the RLC status report to the peer RLC transmitter. At step 1115, the RLC receiver may stop the t-Reassembly timer and / or it may stop the t-StatusProhibit timer. The RLC receiver may also restart (and / or stop) the t-Reassembly timer and / or it may restart the t-StatusProhibit timer. Further description of embodiments of the present disclosure: Within the context of providing timely RLC retransmissions, the following points are considered: According to embodiments of the present disclosure, an enhanced polling method may be provided for controlling one or more nodes of a wireless communication network. The method may comprise configuring a maximum polling frequency so that it is one polling bit for every 4 packets. However, it is not possible to match the polling frequency to the PDU Set boundaries because PDU Set boundaries are variable. However, increasing the polling frequency can result in a large number of non-useful status reports being sent. A way to address this problem is to reduce the polling retransmission timer (e.g., t-Pol I Retransmit) below 5 ms. Alternatively, the polling may be initiated by the transmitter based on remaining time information. However, if the polling bit triggers a status report based on the packet delay budget (PDB), but the t-Reassembly timer is still running, then there will be no NACK information sent back to the transmitter. Also, the prohibit timer might prevent the receiver from sending back a status report. Consequently, there is a need for certain polling bits to be interpreted differently at the receiving side. For example, a polling bit may be sent in dependent on (e.g., only if) the remaining time information is enhanced with dedicated signalling that allows the receiving entity to handle the reassembly timer and / or the prohibit timer differently. In embodiments, a method may comprise enhancing the polling bit signalling to indicate a low remaining time condition. Yet further description of embodiments of the present disclosure: 2.2.3. Enhanced Polling: The maximum polling frequency can be configured as one polling bit every 4 packets. But polling frequency cannot match the PDU Sets boundaries because PDU Set boundaries are variable. In R2-2405032 the authors suggest to reduce the t-PollRetransmit timer below 5 ms. Observation: Increasing the polling frequency can result in a large number of non-useful status reports being sent. In R2-2404850 and R2-2405445, the authors suggest initiating polling by the transmitter based on remaining time information. However, if the polling bit triggers a status report based on PDB, but the t-Reassembly timer is still running, there will be no nack information sent back to the transmitter. Also, the prohibit timer might prevent the receiver to send back a status report. Observation: There is a need for certain polling bits to be interpreted differently at the receiving side. For example, a polling bit which is sent based on remaining time information is enhanced with dedicated signalling that allows the receiving entity to handle differently the reassembly and prohibit timers. Proposal: Enhance the polling bit signalling to indicate a low remaining time condition. The present disclosure also includes the following embodiments. During a previous 3GPP 5G meeting it was agreed to enhance delay status reporting with multiple pairs of data volume and remaining time. In this disclosure we also discuss two topics: (i) a first topic deals with whether there are any constraints on how the NW (Network) configures DSR (Delay Status report) triggering and reporting thresholds, as discussed in the following section A; (ii) a second topic deals with whether to include non-delay critical data ahead of delay critical data in the buffer size calculation for DSR, as discussed in the following section B. A. Trigger and reporting thresholds: As agreed during a previous 3GPP 5G meeting, there is a single triggering threshold and multiple reporting thresholds. Three profiles can be considered regarding the relationship between the triggering threshold and the reporting thresholds: 1. The triggering threshold is smaller than, or equal to, the smaller reporting threshold (e.g., a reporting threshold which is greater than at least one other reporting threshold, e.g., the greatest reporting threshold). The status report is configured with a first pair which reports critical data (e.g., the most critical data), and the other pairs are arranged to report the details of less critical data (e.g., data which is less critical than the data reported by the first pair). 2. All reporting thresholds may be lower than, or equal to, the triggering threshold. Each of the pairs of the status report may be configured to report critical data. Critical data may be refined through multiple pairs, which thereby provides more accurate (i.e., detailed) reporting of the critical data. 3. The triggering threshold is between two (different) reporting thresholds (e.g., the greatest reporting threshold and the smallest reporting threshold). For example, the triggering threshold may be configured to be equal to the mean value of the two reporting thresholds. The status report includes three pairs, the first two pairs are for reporting critical data (e.g., T1, N1a and TO.5, N1b, respectively) and the third pair is for reporting less critical data (e.g., T2, N2). As illustrated in Figure 12, the content and the semantic of the DSR may be different depending on the considered profile. According to the kind of information sought by the gNB, a different configuration option of the thresholds can be submitted to the UE (served by the gNB). In release 18 3GPP 5G, the triggering threshold is configured by RRC (Radio Resource Control) as “remainingTimeThreshold”. Also in release 18, the reporting threshold is represented by “delay-critical” data definition referring to remainingTimeThreshold: Delay-critical PDCP SDU: if pdu-SetDiscard is not configured, a PDCP SDU for which the remaining time till discardTimer expiry is less than the remainingTimeThreshold. If pdu-SetDiscard is configured, a PDCP SDU belonging to a PDU Set of which at least one PDCP SDU has the remaining time till discardTimer expiry less than the remainingTimeThreshold. It is noted that, in release 18, triggering threshold and reporting threshold have the same value. For release 19 3GPP 5G, depending on the relationship between the triggering threshold and the reporting thresholds, the report will have different semantics, leading to different advantages and drawbacks. Profile name Relation between triggers Pro Cons Fine grained delay critical Triggering threshold >= higher report threshold Delay critical data are accurately reported in multiple pairs Potential future delay critical data are not reported Mixed Lower report threshold <Triggering threshold <higher report threshold Balance between delay critical and potential future delay critical Potential future delay critical Triggering threshold <= Lower report threshold Potential future delay critical data are reported fine grained in multiple pairs Delay critical data are reported in a single pair Table 2 1 Comparison between different threshold settings It can be noticed that each setting of reporting and triggering thresholds may be advantageous to certain scenario. According to some embodiments, the network is allowed to configure the triggering and reporting thresholds without constraints. Communication environment may change multiple times during an XR session, and a gNB might need different type of DSR information depending on changing conditions. It can be advantageous for the network (gNB) to be able to change dynamically the relationship between the triggering threshold and the different reporting thresholds. For example (option a, in Figure 12), a plurality of different profiles (e.g., such as those defined in Table 2 1) can be statically configured by the network at the UE. A first profile may be set as the default profile, the network being able to switch between the plurality of profiles dynamically (e.g., by MAC CE). Another possibility (option b, in Figure 12) the UE may be configured to autonomously choose between a set of profiles configured by the network. Finally (option c, in Figure 12), there is also the possibility to let the network configure dynamically both the triggering and the reporting thresholds. According to some embodiments, it is proposed to study the possibility to dynamically configure different triggering and reporting thresholds among three options: • Option a: static profiles, dynamic switch between profiles controlled by the network • Option b: static profiles, autonomous UE switching between configured profiles • Option c: dynamic thresholds setting by the network B. Non delay critical data: Both delay critical and non-delay critical data coexist in one LCH (logical channel), and it can happen that non-delay critical data are present ahead of delay critical data in the TX buffer (Head Of Une, HOL, non-delay critical data). In a previous 3GPP 5G meeting, it has been discussed whether to include or not the HOL non-delay critical data into the count of delay critical data ([R2-2407047, Discussion on scheduling enhancements, Ericsson]). As explained in the previous section, non-delay critical data can be taken into account when using an appropriate profile of the relationship between thresholds (triggering, reporting) i.e. options 1 or 3. For example, Figure 12 shows that N2 data volume which is included in the TX buffer, ahead of other data volumes, can be reported with its actual remaining time T2 and it does not have to be counted as delay critical data because the T1 remaining time is reported together with the N1 data volume. Further, since it is possible to dynamically change the profiles, we do not think that we need further enhancements other than threshold profile management described earlier to handle the reporting of HOL non-delay critical data. It is noted that non-delay critical data, including data ahead of critical data in the buffer, can be taken into account in the DSR when using the appropriate profile of the relationship between the triggering and the reporting thresholds. However, the potential presence of non-delay critical data ahead in the buffer of an LCH may cause issues with the triggering of DSR, as illustrated in Figure 13. First, a TX buffer is represented containing four different data volumes (N1 to N4). N2 is ahead in the TX buffer, followed by N1, N3 then N4. The remaining times associated to each data quantities are noted from smallest to largest T1 to T4. T1 corresponds also to the triggering threshold. When N1 volume reached T1 remaining time, the DSR is triggered and the following pairs are reported: (T1, N1), (T2, N2) and (T3, N3). After a while, as illustrated in the lower half of the figure 13, N2 volume is entirely sent and N1 volume is partially sent with a remaining data volume equal to NT. At that point, non-delay critical data N2, has been served first because it was at the head of the TX buffer. A consequence is that delay-critical data NT are still present in the TX buffer and the network has no knowledge of that situation. The network will not get any new DSR information until a new data volume for reporting reaches the triggering threshold T1. Indeed, release 18 specifications [ NR; Medium Access Control (MAC) protocol specification, (Release 18)] states that DSR can only be triggered by data that have not been previously reported in a DSR. In this example, new DSR will not be triggered until the N4 volume, currently at the T3 remaining time, reaches the T1 remaining time. It is noted that the network may have no knowledge of non-delay critical data being transmitted before delay-critical data. During a previous 3GPP 5G meeting, some LCP related papers ([R2-2406989, Further discussion on scheduling enhancement on XR, CMCC], [ R2-2406371, Discussion on delay-aware LCP enhancement, TCL]) suggested that delay-critical data could be prioritized when sending data from one TX buffer containing a mix of delay-critical and non-delay-critical data. That would have solved this issue but it was also dismissed in other papers as being too complex to implement ([R2-2406741, Discussion on XR scheduling enhancements, China Telecom], [R2-2406784, Scheduling enhancements for Rel-19 XR, Samsung]). One simple solution would be to allow the delay critical data which have already been reported in a previous DSR to trigger a new DSR under certain conditions. For example, triggering of a new DSR by delay critical data that have been already reported, would be allowed if non-delay-critical data were ahead in the TX buffer and delay critical data have not been sent over a given amount of time. In the example of Figure 13, the UE would know that N1 ’ delay-critical data remain in its TX buffer, and the U E knows that new DSR will be triggered not earlier than T3-T1 when N4 data volume will become data-critical, then it can decide that if NT is not sent during a waiting period and that T3-T1 is too long, then a new DSR is triggered. It is noted that the proposed enhancement of trigger conditions allows to accurately inform the network about remaining time-critical data with no extra complexity in buffer management. According to some embodiments, it is proposed to enhance the release 18 DSR trigger conditions to allow delay-critical data already reported in a DSR to trigger a new DSR under specific conditions e.g. non-delay-critical data were present ahead in the TX buffer. If the new trigger is adopted then it can be useful to indicate in the DSR which data volume has already been reported but is still pending for transmission and which data volume is new. According to some embodiments, in the DSR each reported pair has an indication to discriminate newly reported and already reported data volume. A third solution would consist in sorting the pairs in the DSR message according to their respective position in the TX buffer. In this case, the position of the pair in the DSR message would reflect the position of the data volume in the TX buffer and the network would at least be aware that non-delay-critical data are ahead in the Tx buffer. But it may be complex for implementation to keep track or to have knowledge of each data volume’s position in the transmit buffer. Also, this would not work if the data volumes are not contiguous in the TX buffer but interleave with each other. It is noted that enhancing the triggering condition is the only solution that has no impact on TX buffer implementation. 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. Unless otherwise defined herein, scientific and technical terms used in connection with the presently disclosed inventive concept(s) shall have the meanings that are commonly understood by those of ordinary skill in the art, and known techniques and procedures may be performed according to conventional methods well known in the art and as described in various general and more specific references that may be cited and discussed in the present specification. As used in this specification and claim(s), the words “comprising, “having,” “including,” or “containing” (and any forms thereof, such as “comprise” and “comprises,” “have” and “has,” “includes” and “include,” or “contains” and “contain,” respectively) are inclusive or open-ended and do not exclude additional, unrecited elements or method steps. The use of the term “a” or “an” in the claims and / or the specification may mean “one,” as well as “one or more,” “at least one,” and “one or more than one.” As such, the terms “a,” “an,” and “the,” as well as all singular terms, include plural referents unless the context clearly indicates otherwise. Likewise, plural terms shall include the singular unless otherwise required by context. The use of the term “or” in the present disclosure (including the claims) is used to mean an inclusive “and / or” unless explicitly indicated to refer to alternatives only or unless the alternatives are mutually exclusive. Unless otherwise explicitly stated as incompatible, or the physics or otherwise of the embodiments, examples, or claims prevent such a combination, the features of examples disclosed herein, and of the claims, may be integrated together in any suitable arrangement, especially ones where there is a beneficial effect in doing so. This is not limited to only any specified benefit, and instead may arise from an “ex post facto” benefit. This is to say that the combination of features is not limited by the described forms, particularly the form (e.g., numbering) of example(s), embodiment(s), or dependency of claim(s). 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 managing data transmission in a communication network using a Radio Link Control Acknowledged Mode, RLC AM, the communication network comprising a transmitter and a receiver, wherein the method at the transmitter comprises: transmitting, to the receiver, a request to report the receipt status of a plurality of Protocol Data Units, PDUs, wherein the request is transmitted based on timing information associated with at least one PDU of the plurality of PDUs.

2. The method according to claim 1, wherein the method comprises determining whether to retransmit a PDU of the plurality of PDUs based on the receipt status report.

3. The method according to claim 1 or claim 2, wherein the method comprises determining whether to retransmit a PDU of the plurality of PDUs based on timing information associated with at least one PDU of the plurality of PDUs .

4. The method according to claim 2 or claim 3, wherein the timing information is indicative of a timer, and wherein retransmission of the PDU is performed if the remaining time of the timer is above a threshold value.

5. The method according to any one of claims 2 to 4, wherein retransmission of the PDU is performed if the receipt status report indicates that at least one PDU is lost or unknown.

6. The method according to any one of claims 1 to 5, wherein the request is transmitted before the expiry of a timer associated with the at least one PDU.

7. The method according to claim 6, wherein a PDU of plurality of PDUs is associated with a PDU Set, and the request is transmitted when the remaining time for transmitting the PDU Set is less than a threshold value.

8. The method according to claim 7, wherein a first PDU of the plurality of PDUs is associated with a first PDU Set and a second PDU of the plurality of PDUs is associated with a second PDU Set different to the first PDU Set, wherein the request is transmitted when the remaining time for transmitting at least one of the first PDU Set and the second PDU Set is less than a threshold value.

9. The method according to claim 7 or claim 8, wherein the threshold value is less than the PDU Set Delay Budget.

10. The method according to any one of claims 1 to 9, wherein the request is transmitted in dependence on an indication from a lower layer of the protocol stack of the availability of a transmission opportunity.

11. The method according to any one of the preceding claims, wherein the request is transmitted in dependence on a detection of a gap in the sequence of the plurality of PDlls which are positively acknowledged by the receiver.

12. The method according to any one of the preceding claims, wherein the request comprises information which directs the receiver to prohibit or suspend a timer relating to at least one of the plurality of PDlls.

13. The method according to any one of the preceding claims, wherein the request comprises a polling bit for requesting that the receiver send a status report relating to the plurality of PDlls.

14. The method according to any one of the preceding claims, wherein the request comprises information which indicates when to report the receipt status of the plurality of PDlls.

15. The method according to any one of the preceding claims, wherein the request comprises information which directs the receiver to report the receipt status of the plurality of PDUs immediately.

16. The method according to any one of the preceding claims, wherein the request comprises information which directs the receiver to ignore a PDU reordering process.

17. The method according to any one of the preceding claims, wherein the request comprises information which indicates the plurality of PDUs whose receipt statuses are to be reported.

18. The method according to any one of the preceding claims, wherein the request comprises information which indicates to the receiver that the receipt status for at least one of the plurality of PDUs is critical.

19. The method according to any one of claims 12 to 18, wherein the request comprises timing information for at least one the plurality of PDlls.

20. The method according to any one of claims 12 to 19, wherein the request comprises a sequence number associated with at least one of the plurality of PDUs.

21. The method according to any one of the preceding claims, wherein the request is included in the header of a Data PDU for transmitting a data payload to the receiver.

22. The method according to claim 21, wherein the request is identifiable by at least one bit of the header of the Data PDU.

23. The method according to any one of claims 1 to 20, wherein the request is included in a Control PDU for transmitting control information to the receiver.,.

24. The method according to claim 23, wherein the request is identified by an identifier coded with at least one bit of the Control PDU.

25. A method for managing data transmission in a communication network using a Radio Link Control Acknowledged Mode, RLC AM, the communication network comprising a transmitter and a receiver, wherein the method at the receiver comprises: reporting to the transmitter the receipt status of a plurality of Protocol Data Units, PDUs, in response to a request from the transmitter, wherein the request is transmitted based on timing information associated with at least one PDU of the plurality of PDUs.

26. The method according to claim 25, wherein the method comprises identifying that the request is transmitted in dependence on the timing information associated with at least one of the PDUs.

27. The method according to claim 25 or claim 26, wherein the method comprises identifying the request in the header of a Data PDU for transmitting a data payload to the receiver.

28. The method according to claim 25 or claim 26, wherein the request is identified by an identifier coded with at least one bit of a Control PDU for transmitting control information to the receiver.

29. The method according to any one of claims 25 to 28, wherein the receipt status comprises information which indicates whether or not at least one of the plurality of PDUs has been received by the receiver.

30. The method according to claim 29, wherein the receipt status comprises a sequence number for at least one of the plurality of PDUs which has been received by the receiver.

31. The method according to claim 29 or claim 30, wherein, if at least one PDU of the plurality of PDUs is undergoing a reassembly process, then the status of the at least one PDU is considered to be lost.

32. The method according to any one of claims 25 to 31, wherein the method comprises prohibiting, or suspending, a timer associated with to at least one of the plurality of PDUs.

33. The method according to claim 32, wherein the timer is prohibited, or suspended, in response to receiving the request from the transmitter.

34. The method according to any one of the claims 25 to 33, wherein the request comprises information which indicates when to report the receipt status of the plurality of PDUs.

35. The method according to any one of claims 25 to 34, wherein the method comprises immediately reporting the receipt status of the plurality of PDUs in response to the request from the transmitter.

36. The method according to any one of claims 25 to 35, wherein the method comprises determining a negative-acknowledgement, NACK, status of the plurality of PDUs in response to receiving the request.

37. The method according to claim 36, wherein the method comprises setting a NACK status for at least one of the plurality of PDUs being associated with a timer of the receiver which exceeds a threshold value.

38. The method according to any one of claims 25 to 37, wherein reporting the receipt status of the plurality of PDlls comprises transmitting a report which includes timing information relating to at least on the plurality of PDlls.

39. The method according to any one of claims 25 to 38, wherein the method comprises ignoring a PDU reordering process in response to the request from the transmitter.

40. The method according to any one of claims 25 to 39, wherein the method comprises, after reporting the initial receipt status report, prohibiting the transmission of a further status report for a predetermined time period.

41. A communication network which comprises a transmitter configured to perform the method of any one of claims 1 to 24, and / or a receiver configured to perform the method of any one of claims 25 to 40.

42. A computer program comprising instructions which, when the program is executed by a transmitter, causes the transmitter to carry out the method according to any one of claims 1 to 24, and / or when the program is executed by a receiver, causes the receiver to carry out the method according to any one of claims 25 to 40.

43. A computer-readable medium carrying a computer program according to claim 42.

Images