WO2025210182A1

WO2025210182A1 - Method for managing data transmission in a communication network

Info

Publication number: WO2025210182A1
Application number: PCT/EP2025/059180
Authority: WO
Inventors: Yacine El Kolli; Pierre Visa; Pascal Lagrange
Original assignee: Canon Europe Ltd; Canon Inc
Current assignee: Canon Europe Ltd; Canon Inc
Priority date: 2024-04-04
Filing date: 2025-04-03
Publication date: 2025-10-09
Anticipated expiration: 2026-10-04

Abstract

A method for managing data transmission in a communication network operating in a radio link control acknowledge mode, the communication network comprising a transmitter and a receiver, wherein the method at the transmitter comprises: retransmitting a PDU having an unknown status prior to receiving a notification from the receiver indicating the status of the PDU.

Description

METHOD FOR MANAGING DATA TRANSMISSION IN A COMMUNICATION NETWORK

FIELD OF THE DISCLOSURE

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 acknowledge 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, such as virtual reality, involve transferring compressed video data, audio data and various information from the server to the wearable device.

Some XR applications, such as 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 (Hyper Text Transfer Protocol, RFC 2616-7540) or QUIC (RFC 8999, 9000, 9001 and 9002).

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

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

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

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

Some video decoder implementations require that a complete application data packet (e.g., 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 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 (PSI H I) 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 PSDB. For example, when a PDU Set is transferred over the air a Radio Access Network (RAN) node (e.g., a UE or a next gen node (gNB)) can detect that a PDU transmission has failed despite all the retransmissions and error correction mechanisms. In that case, if the PSIHI parameter is set to “true”, then the entire PDU Set is useless to the application. In that case, if one or more PDUs of this “useless” PDU Set are pending transmission over the air interface then the RAN node can consider discarding the remaining transmission of the “useless” PDUs, thus achieving radio network resource saving.

The PDU Sets are mapped on QoS flows (SDAP layer), QoS flows are mapped on DRBs (PDCP layer), DRBs are mapped on RLC channels (RLC layer), RLC channels are mapped on logical channels (MAC layer). The MAC layer implements reliability mechanism called Hybrid ARQ, it provides a given level of reliability that can be improved by the RLC layer if needed. The RLC layer Acknowledged Mode (AM) implements an additional ARQ mechanism allowing to further enhance the transmission reliability. The ARQ mechanism relies on the RLC receiver that send status reports indicating the status of received PDUs (e.g., service data units, SDUs) to the RLC transmitter which in return will schedule the retransmission of lost PDUs and update the transmit window.

Status reporting at 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 SDU. An SDU is detected as lost when both a sequence number gap is detected and a timer (e.g., t-reassembly) is elapsed.

Thus, at the RLC transmitter side the decision to retransmit a SDU is delayed both by polling and t-reassembly timer. While it may reduce the overhead (or the total number of retransmissions), it introduces additional delay when the lower layers eventually fail to transmit correctly the SDU. For applications (XR) that requires both high reliability and low latency this additional delay is not acceptable.

Furthermore, delaying the retransmission of one SDU has also a negative consequence on the transmit window management. The transmit window is defined between a lower and upper bound of SDU sequence numbers. It defines the SDUs that are eligible to be transmitted. The transmit window is updated by both incrementing the lower and upper bounds. Thus, the transmit window is only updated when the reception status of the lower bound SDU is confirmed to be good, otherwise it stays unchanged even if new 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 SDU of a first PDU Set is not confirmed and the second PDU Set’s SDUs sequence numbers are out of the transmit window. This phenomenon is also known as transmit window stalling.

Methods for reducing the impact of transit window stalling have been proposed. Forexample, 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 packets. But polling frequency cannot match the PDU Sets boundaries because PDU Set 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 overheads across the network. Accordingly, there is a need to manage the retransmission of data during RLC AM operating conditions in order improve the operating efficiency of such communication networks.

SUMMARY

According to embodiments of the present disclosure, there is provided a means of preempting the retransmission of the protocol data unit, PDU, having an unknown status before determining (e.g., deciding, inferring, identifying, estimating and/or calculating) that the PDU has been lost.

According to a first embodiment there is provided a method for managing data transmission in a communication network operating in a radio link control acknowledge mode, the communication network comprising a transmitter and a receiver, wherein the method at the transmitter comprises: retransmitting a PDU having an unknown status prior to receiving a notification from the receiver indicating the status of the PDU.

Advantageously, the method according to the present disclosure enables the transmitter to anticipate (e.g., and therefore trigger) the retransmission of a potentially missing and/or lost PDU. This enables earlier and more efficient retransmission of PDUs, which thereby minimizes the overheads in the communication network.

In embodiments, the retransmission of the PDU may be based on (and/or triggered by) the remaining time for transmission of the PDU.

The PDU retransmission may be initiated in dependence on the remaining time for transmission of the PDU falling below a threshold (e.g., an autonomous retransmission threshold value which may be predetermined by an entity of the wireless communication network).

The unknown status may be indicative of the PDU having been transmitted to the receiver but not acknowledged as being received by the receiver.

The unknown status may be indicative of the PDU having been transmitted to the receiver but not acknowledged as being not received by the receiver.

The notification may be received in response to the transmission to the receiver of a polling bit. The notification may be received when a timer set by the receiver expires. The notification may be indicative of (e.g., comprise) a negative acknowledgement that the PDU has not been received by the receiver.

Prior to receiving the notification from the receiver, another notification may be received from the receiver indicating the status of the PDU (e.g., the transmitter may receive a first notification and a second notification indicating the status of one or more PDUs). The prior notification (e.g., the earlier, or first notification) may be indicative (e.g., comprise) a positive acknowledgement of at least one PDU having been received by the receiver. For example, the first (earlier) notification may indicate that at least one (e.g., not all) of a plurality of PDUs transmitted to the receiver have been received.

The PDU may be associated with a first PDU Set. The first PDU Set may be followed by a second PDU Set comprising at least one PDU which is different to the PDU of the first PDU Set. Retransmission of the PDU having an unknown status (e.g., associated with the first PDU Set) may occur following the transmission (e.g., completed transmission or abandonment) of the first PDU Set, and before transmission (e.g., before the start of the transmission) of the second PDU Set.

Retransmission of the PDU having an unknown status may be determined (e.g., identified) based on a number of criteria. For example, retransmission of the PDU having an unknown status may occur if the second PDU Set has a lower priority than the first PDU Set. Retransmission of the PDU having an unknown status may occur during a transmission opportunity (e.g., a buffer) arranged (e.g., interposed) between the first PDU Set and the second PDU Set.

Retransmission of the PDU having an unknown status may occur based on the amount of data not transmitted to a lower layer of the protocol stack. Put another way, the retransmission may be based on an indication from a lower layer of the protocol stack of the availability of a transmission opportunity (e.g., if one or more PDUs of the same PDU Set have already been discarded, or not received, by a different level of the protocol stack).

The PDU having an unknown status may be selected for retransmission based on a sequence number of the PDU associated with the first PDU Set. For example, retransmission of the last PDU of a PDU Set may be prioritised. Alternatively, if the PDU is not the last in the sequence of the PDU Set, then retransmission of the PDU according to the present method may not proceed (e.g., the PDU retransmission may be delayed, or retransmitted using legacy data management methods).

The retransmitted PDU may be selected for retransmission based on the remaining time for transmission of the first PDU Set.

Retransmission may be determined (e.g., configured, or controlled) on the basis of the PDU having an unknown status being the last PDU in a transmission window, and at least one other PDU of the PDU Set is ready to be transmitted. Retransmission may be determined on the basis of the PDU having an unknown status being the nth last PDU in a transmit window, and at least one other PDU of the PDU Set is ready to be sent. Retransmission may be determined on the basis of a transmit window having not been updated for a predetermined amount of time. The notification may be generated based on the detection of a gap in the sequence of the PDUs received by the receiver. The notification may be generated based on a duplicate detection of a PDU being received by the receiver. The notification may be generated at the end of a timer set by the receiver.

The data packet (e.g., PDU) having an unknown status may be considered to have a pending state. A pending stat may indicate that the PDU has been received at a relay node but has not been received at the destination node (such as a UE in the downlink direction or a base station in the uplink direction) of the communication network.

The method may comprise at least one of the following method steps: transmitting, to the receiver, one or more protocol data units; receiving, from the receiver, a first notification indicating a status of the one or more PDUs; determining (e.g., identifying, inferring, estimating, calculating or deciding), based on the first notification, at least one PDU of the one or more PDUs having an unknown status. The one or more PDUs may be associated with the same PDU Set.

The method step of determining the status of the PDU may comprise transmitting a first PDU of a PDU Set; transmitting, after the first PDU, a second PDU of the PDU Set; and receiving a (first) notification indicating that the status of only one of the transmitted PDUs (e.g., the first PDU but not the second PDU).

The polling bit may be transmitted to the receiver in a header of a PDU sent by the transmitter.

Retransmission of the PDU having an unknown status may occur based on one or more missing PDUs from at least one of the first PDU Set and the second PDU Set.

According to a second embodiment there is provided a communication network which comprises a transmitter configured to perform the method according to the first embodiment. According to a third embodiment 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 embodiment. According to a fourth embodiment there is provided a computer-readable medium carrying a computer program according the third embodiment.

Throughout the statements outlined above (and in the description more generally), it will be appreciated that the phrase Protocol Data Unit (i.e. PDU) may also refer to a Service Data Unit (i.e., SDU), depending on the context.

Any feature in one embodiment of the disclosure may be applied to other embodiment embodiments of the disclosure, in any appropriate combination. In particular, method embodiments may be applied to apparatus/device/unit embodiments, 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 embodiments 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 embodiment 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 embodiments 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 examples, except where such a combination is clearly impermissible or expressly avoided. Other features, embodiments, 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 embodiments 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 data 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 schematic diagram illustrating a first method of managing data transmission between an RLC transmitter and an RLC receiver;

Figure 7 is a schematic diagram illustrating a second method of managing data transmission between an RLC transmitter and an RLC receiver;

Figure 8 is a schematic diagram illustrating a third method of managing data transmission between an RLC transmitter and an RLC receiver;

Figures 9a and 9b are flow charts illustrating the first method implemented at the RLC transmitter;

Figures 10 and 11 are flow charts illustrating the second method implemented at the RLC transmitter;

Figure 12 is a flow chart illustrating the third method implemented at the RLC transmitter; and Figure 13 is a schematic diagram illustrating example signalling between two nodes of a wireless communication network.

DETAILED DESCRIPTION

Embodiments and embodiments of the present disclosure will now be discussed with reference to the accompanying figures. Further embodiments 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 service (XR). Although in the following description, embodiments and examples of embodiments of the present disclosure will be described with respect to a 5G NR system, it will be appreciated that it is not intended that the present disclosure is limited to 5G NR systems and may be used in any wireless communication systems supporting XR or similar service.

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

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

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

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

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

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

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

The I/O controller 255 may for example interact with all or part of an image capture device, an image rendering device, an audio capture device, an audio rendering device, or a sensor device able to determine the use position. The transceiver 235 is configured to provide bi-directional wireless communication with other wireless devices. For example, it provides the necessary modems (e.g., routers) and frequency shifters necessary to connect to one or more wireless networks, such as Wi-Fi, Bluetooth, LTE, 5G NR, etc. The transceiver 235 may comprise a PDCP transmitter and a PDCP receiver. The PDCP transmitter and the PDCP receiver may be implemented by the processor 215. The PDCP transmitter and the PDCP receiver may be a software only function implemented by the processor 215.

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

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

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

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

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

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

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

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

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

A. PDU Set delay budget (PSDB);

B. PDU Set error rate (PSER); and

C. PDU Set integrated handling indication (PSIHI), which is also previously known as a PDU Set integrated indication.

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

When the PDUs arrive at the UPF PDU layer 402, the UPF performs an application packet inspection to determine the PDU Set boundaries. For example, 3GPP document S2-2302696 provides examples on how to identify PDU Sets when inspecting RTP/SRTP header, RTP header extension, H.264 RTP payload, H.265 RTP payload and H.266 RTP payload. PDU Set identification information as described in 3GPP document S2-2303842 is determined by the UPF and sent to the NG-RAN in the GTP-U header. The PDU Set identification Information comprises:

A. a PDU Set sequence number;

B. an indication of the end PDU of the PDU Set;

C. a PDU sequence number within a PDU Set;

D. a PDU Set size; and

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

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

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

During downlink, the UPF detects the PDU Set identification information and obtains from the core network a set of mapping rules (e.g., filtering rules). The filtering rules define how each PDU Set is mapped to a QoS flow. The, or each, QoS flow is identified by an identifier, and the GTP-U PDUs are marked according to the determined QoS flow identifier. At the gNB, the relay layer 406 extracts PDU Set identification information and the QoS flow identifier from the GTP-U PDUs and maps them into the SDAP QoS flow(s). During an XR session (e.g., a single XR session), multiple PDU Sets can be mapped to the same QoS flow. Alternatively (or additionally), one or more PDU Sets may be mapped to different QoS flows. Then according to 3GPP document TR- 38.835, in a first alternative arrangement, each SDAP QoS flow can be mapped to a different PDCP Data Radio Bearer (DRB). According to a second alternative arrangement, all of the SDAP QoS flows from the same XR session can be mapped to a PDCP DRB (e.g., a single PDCP DRB).

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

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

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

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

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

The RLC protocol layer can operate in three modes: A transparent mode (TM) during which data is 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 for one RLC SDU (e.g., “maxRetxThreshold”).

In a situation where an SDU has been transmitted by the transmitter, but not received by the receiver, then the transmitter is configured to retransmit the missing SDU. Several retransmissions of the missing SDU may occur (e.g., at scheduled intervals) until a certain condition is met. For example, the retransmissions may repeat until the transmitter determines that the SDU has been received. RLC AM is configured to reset the current session and trigger a Radio Link Failure (RLF) when the maximum number of retransmissions of a single SDU 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 SDUs to the RLC transmitter, which in return will schedule retransmission of lost SDUs and update the transmit 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 SDU. An SDU is detected as lost when both a sequence number gap is detected and a timer (e.g., t-reassembly) is elapsed (or expired).

Thus, at the RLC transmitter side the decision to retransmit a SDU is delayed both by polling and the t-reassembly timer. While the described procedure may reduce the overheads 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 correctly the SDU. For certain applications (e.g., XR) that require both high reliability and low latency this additional delay is not acceptable.

Furthermore, delaying the retransmission of one SDU can also have a negative consequence on the broader transmit window management. The transmit window is defined between a lower and upper bound SDU sequence number. In this way, it defines the SDUs that are eligible to be transmitted. The transmit window is updated by both incrementing the lower and upper bounds. Thus, the transmit window is only updated when the reception status of the lower bound SDU is confirmed, otherwise it stays unchanged even if new 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 SDU of a first PDU Set is not confirmed and the second PDU Set SDUs sequence number are out of the transmit window. This phenomenon is also known as transmit 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 between an RLC transmitter 501 and an RLC receiver 502. This example illustrates the status reporting mechanism implemented during RLC AM. It shows a sequence of transmission by the RLC transmitter 501 of SDUs with sequence numbers from 1 to 5 and the corresponding status reports sent by the RLC receiver 502.

During a first transmission 503, RLC SDU 1 is sent by the RLC transmitter 501 and 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 poll bit inserted into the data header of a transmitted data packet (e.g., the poll 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 poll bit set in the header. RLC SDU 2 is also correctly received by the RLC receiver 502. Due to the presence of the poll 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 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 transmit window taking into account that RLC SDUs 1 and 2 are correctly received.

In a subsequent (i.e. , third) transmission 506, SDU 3 is sent by the RLC transmitter 501 but not received by the RLC receiver 502. At the RLC receiver 502 nothing happens. However, the RLC receiver is still expecting SDU 3 as the next SDU to be received.

The next (i.e., fourth) transmission 507 involves SDU 4 being sent by the RLC transmitter

501 and being correctly received at the RLC receiver502. When receiving SDU 4, the RLC receiver

502 detects that SDU 3 is missing because of the sequence number gap (e.g., SDU 3 has an unknown status). At that point, SDU 3 is not considered lost. Nevertheless, the RLC receiver 502 starts a t-reassembly timer and waits for the correct reception of SDU 3. The goal of the network is to wait for low level retransmissions to fix the issue. If SDU 3 is not received when the t-reassembly timer elapses (or expires), then the RLC receiver 502 will consider SDU 3 as being lost (e.g., at this the status of SDU 3 is no longer unknown because the RLC receiver 502 has concluded that the previous transmissions of SDU 3 will not be received). So, at the reception of SDU 4 (i.e., during transmission 507), there are no status reports triggered at the RLC receiver 502.

A subsequent transmission 509 involves the RLC transmitter 501 sending SDU 5 with a poll bit, which is received by the RLC receiver 502 correctly. At this point the t-reassembly timer is still running and the RLC receiver 502 is still expecting SDU 3 as the next SDU to be received. Answering to the poll bit, the RLC receiver 502 sends a status report 510 back 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 (e.g., SDU3 has an unknown status), the status of SDU 4 is unknown, and the status of SDU 5 is probably correctly received because a status report was sent as a result of the poll bit which was included with SDU 5. With this information the RLC transmitter 501 cannot update the transmit window because SDU 3 is not yet received correctly by the RLC receiver 502. Another transmission 511 coincides with the expiry of the t-reassembly timer at the RLC receiver 502. At that time the RLC receiver 502 considers that the SDU 3 is lost. The RLC receiver 502 then restarts the t-reassembly timer and sends a status report to the RLC transmitter 501 . The status report contains both a negative acknowledgement (Nack) for SDU 3 and a positive acknowledgement (Ack) for SDU 6. The RLC transmitter 501 interprets the status report to mean that SDU 3 is lost and shall be retransmitted. Furthermore, the RLC transmitter interprets that all SDUs below 6 and above 3 have been correctly received by the RLC receiver 502. So, the reception status of SDUs 4 and 5 are confirmed to be good (i.e. , their statuses are known), whereas SDU 3 shall be retransmitted and so the transmit window cannot be updated.

During a further transmission 512, the RLC transmitter 501 performs the first retransmission of the SDU 3 which similar to the first transmission attempt, does not reach the RLC receiver 501 . At that time, the t-reassembly timer is still running at the RLC receiver and nothing happens.

During transmission 513, the t-reassembly timer elapses at the RLC receiver 502, meaning that the retransmission of SDU 3 has failed. At the RLC transmitter 501 , nothing changed between transmissions 512 and 513, no new data was received from the upper layers of the protocol stack (e.g., the PDCP layer) for transmission, and the status of SDU 3 remains unknown. At the time of transmission 513, the RLC receiver 502 considers that the first retransmission of SDU 3 is lost. The RLC receiver 502 shall then restart the t-reassembly timer and send a status report to the RLC transmitter 501. The status report contains both a negative acknowledgement (Nack) for SDU 3 and a positive acknowledgement (Ack) for SDU 6. The RLC transmitter 501 interprets the status report to mean that the first retransmission of SDU 3 is lost and shall be retransmitted once more. In addition, the RLC receiver 501 interprets that all SDUs below 6 and above 3 are correctly received by the RLC receiver 502. Therefore, SDU 3 shall be retransmitted again and the transmit window still cannot be updated.

The retransmission sequence 511 , 512, 513 shall be repeated until successful reception of SDU 3 is confirmed, or the threshold of maximum number of retransmissions of a single SDU (in this case SDU 3) is reached. Only the confirmation of a correct reception of SDU 3 would allow updating the transmission window by the RLC transmitter 501 . Reaching the threshold of maximum number of retransmissions triggers a radio link failure (RLF) procedure putting an end to the whole communication process.

As described above, at the RLC transmitter 501 side the decision to retransmit a SDU is delayed both by polling and the t-reassembly timer, which results in unacceptable disruption to applications (such as XR) which require both high reliability and low latency. Furthermore, delaying the retransmission of one SDU can also have a negative consequence on the broader transmit window management. The transmit window is defined between a lower and upper bound SDU sequence number. In this way, it defines the SDUs that are eligible to be transmitted. The transmit window is updated by both incrementing the lower and upper bounds. Thus, the transmit window is only updated when the reception status of the lower bound SDU is confirmed, otherwise it stays unchanged even if new 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 SDU of a first PDU Set is not confirmed and the second PDU Set SDUs sequence number are out of the transmit window. This phenomenon is also known as transmit window stalling.

Regarding the example shown in Figure 5, if SDUs 3 to 5 were associated with a first PDU Set (i.e., PDU Set 1) and a second PDU Set (i.e., PDU Set 2) therefore started at SDU 6, and if then transmit window was defined between sequence numbers 3 and 5, then the second PDU Set would stall waiting for the good reception of SDU 3.

Some parameters can be tuned to improve the status report responsiveness. For example, the maximum polling frequency can be configured to transmit a polling bit every four packets, or even every 2 packets. However, adjusting the polling frequency cannot match the PDU Set boundaries because the PDU Set boundaries are variable. Alternatively, the T_reassembly timer can be set to 0, meaning immediate response from the RLC receiver once the sequence number gap is detected. But reducing the t-reassembly timer increases the number of false missing detections, which dramatically increases the unnecessary overheads in the network.

Figure 6 is a schematic diagram illustrating a method of managing data transmission between the RLC transmitter and RLC receiver, according to a first embodiment of the present disclosure. The method will also be described with reference to the flow charts shown in Figures 9a and 9b.

Considering Figure 6, two PDU Sets 601 and 602 are shown as being available for transmission during a time period 603 in which the RLC transmitter will sends SDUs 3, 4, 5, 6 and 7.

When selecting SDU 8 (as shown by reference 604) for next transmission opportunity (e.g. method step 900 in Figure 9b), the RLC transmitter checks whether there will be other SDUs ready to be sent after SDU 8 (e.g. method step 901). In this example, as illustrated by the empty transmission opportunity 605, SDUs 9 to 11 (as shown by reference 606) are not ready for transmission (e.g., because either they are outside of the transmit window or not yet provided by the DPCP layer). In that case the RLC transmitter will check (e.g. method step 902) if some of the previous SDUs (as shown by reference 603) have an unknown reception status (e.g., missing or pending, but not lost). Then select one of them for an anticipated retransmission (e.g. method step 904).

Considering method step 902 in isolation, the present disclosure (as illustrated by Figure 9a) provides a means of retransmitting a PDU having an unknown status before receiving a notification (e.g., negative acknowledgment) from the receiver which indicates that the status of the PDU has been lost.

In this example, SDU 3 has already been retransmitted two times, but the status of the second retransmission is unknown, so SDU 3 is selected as having an unknown (or pending) reception status and having the smallest sequence number among the SDUs with unknown reception status. Consequently, SDU 3 is selected for retransmission before it is confirmed whether the SDU 3 has been lost. Then, SDU 8 is transmitted as planned (e.g. method step 905), and SDU 3 is sent at the next transmission opportunity (e.g.., 605, 906, 907). This results in the timeline 607, in which SDU 3 is interposed between the SDU 8 and SDU 9 of the SDU sequence.

In contrast to arrangements in which the t-assembly timer is set to 0, the method of Figure 9 advantageously limits anticipation of the SDU retransmission to situations where there is time available to perform the retransmission, and only for a subset of SDUs associated with a given PDU Set. Therefore, this method achieves better responsiveness with reduced overheads.

Figure 7 is a schematic diagram illustrating a method of managing data transmission between the RLC transmitter and RLC receiver, according to a second embodiment of the present disclosure. This method will also be described with reference to the flow charts shown in Figures 10 and 11.

Considering Figure 7, two PDU Sets 701 and 702 will become available for transmission during a time period 703, in which the RLC transmitter is configured to send SDUs 3, 4, 5, 6 and 7.

When selecting SDU 8 (as identified by reference 704) for the next transmission opportunity (e.g. method step 1000 in Figure 10), the RLC transmitter checks whether it is the last SDU of a PDU Set (e.g. method step 1001). In this example, SDU 8 is the last SDU of PDU Set one (e.g. reference 700), and SDUs 9 to 11 (e.g. reference 706) are part of PDU Set two (e.g. reference 701). Also in this example, SDUs 9 to 11 are ready to be sent (i.e. , they are both provided by the PDCP layer and included in the transmit window).

In contrast to arrangements in which the t-assembly timer is set to 0, the method of Figure 10 advantageously limits anticipation of the SDU retransmission to PDU Set boundaries, and only for a subset of SDUs associated with a given PDU Set. Therefore, this method achieves better responsiveness with reduced overheads.

In the implementation of Figure 11 , a further check at method step 1102 is performed to make sure that the second PDU Set (e.g. reference 701 of Figure 7), is less important than the first PDU Set (e.g. reference 700). In that case the RLC transmitter will check if some of the previous SDUs (e.g. reference 703) have an unknown, or pending, reception status (i.e., missing not lost). Then the RLC transmitter selects one of them for an anticipated retransmission (e.g. method step 1104). By anticipating the retransmission of the SDUs with an unknown status, the method therefore reduces the chances of delaying high importance PDU Sets from reaching their intended destination.

In this example, similar to the example of Figure 6, SDU 3 has already been retransmitted two times, but the status of the second retransmission is unknown. Therefore, SDU 3 is selected as having an unknown (or pending) reception status and having the smallest sequence number among the SDUs with unknown reception status. Consequently, SDU 8 is sent as planned (e.g. method step 1005), and SDU 3 is sent at the next transmission opportunity (e.g., 1005, 1006, 1007), thus delaying SDUs 9 to 11 by one transmission opportunity, which results in the timeline 707. In an alternative configuration, all the SDUs of the first PDU Set 700 with an unknown, or pending, reception status will be considered for anticipated retransmission, delaying further the SDUs of the next PDU Set.

Figure 8 is a schematic diagram illustrating a method of managing data transmission between the RLC transmitter and RLC receiver, according to a third embodiment of the present disclosure. This method will also be described with reference to the flow charts shown in Figure 12.

Considering Figure 8, two PDU Sets 801 and 802 will become available for transmission during a time period 803, during which the RLC transmitter is configurable to send SDUs 3, 4, and 5. When selecting SDU 6 (e.g., 804) for a next transmission opportunity (e.g., method step 1200 of Figure 12), the RLC transmitter detects a transmit window situation (e.g. method step 1201). In this example, SDU 6 is the last SDU of the transmit window. Also in this example, SDUs 7 to 11 are not ready to be sent (e.g., they are provided by PDCP layer but not included in the transmit window). In that case the RLC transmitter will check (e.g. method step 1202) if some of the previous SDUs (e.g. 803) have an unknown, or pending, reception status (e.g., missing not lost). Then the RLC transmitter selects one of them for an anticipated retransmission (e.g. method step 1204).

In this example, similar to the examples of Figures 6 and 7, SDU 3 has already been retransmitted two times, but the status of the second retransmission is unknown. Therefore, SDU 3 is selected as having an unknown (or pending) reception status and having the smallest sequence number among the SDUs with unknown reception status

SDU 6 is sent as planned (e.g., method step 1205), and SDU 3 is sent at the next transmission opportunity (e.g., 1205, 1206, 1207). Advantageously, this does not delay SDUs 9 to 11 by one transmission opportunity since the transmit window is stalled anyway. The resulting timeline, considering that the transmit window stall condition is resolved by the successful retransmission of SD3 is illustrated by reference 807.

In an alternative configuration, all of the SDUs of the first PDU Set 800 with an unknown, or pending, reception status will be considered for anticipated retransmission.

Figures 9a and 9b are flow charts illustrating the method according to the second embodiment of the present disclosure, as implemented by the RLC transmitter 501.

At method step 900, the RLC transmitter is ready to send a new SDU (e.g., a first SDU) and is notified by the lower layer of the protocol stack (e.g., the MAC layer) that a transmission opportunity is available. A new SDU is a SDU with a sequence number following the sequence number of the last sent SDU, that is part of the transmit window, and that has not been sent earlier. Next, at method step 901 , the RLC transmitter checks whether there are any other SDUs ready to be transmitted, either as a first transmission or as retransmission. If other SDUs are also ready to be sent (i.e., ‘no’ at method step 901), then the RLC transmitter proceeds with method step 903, and sends the first SDU according to RLC AM rules (e.g., as defined in TS 38.322). If the current SDU is the last one to be sent before a silent period, (i.e., ‘yes’ at method step

901), then the RLC transmitter checks during method step 902 if there is an SDU with an unknown, or pending, reception status (meaning that the SDU is neither confirmed as being received nor confirmed as being lost and thus not considered as being ready for retransmission).

If there are no SDUs with an unknown, or pending, reception status (i.e., ‘no’ at method step

902), then the RLC transmitter proceeds with method step 903 and sends the first SDU according to RLC AM rules (e.g., as defined in TS 38.322).

If SDUs with pending reception status are found (e.g., ‘yes’ at method step 902), then the RLC transmitter, during step 904, selects at least one of these SDUs (e.g., second SDU) for an anticipated retransmission. Selecting the second SDU for anticipated retransmission means changing the status of this second SDU from unknown (or missing not lost) to lost and placing the second SDU in the retransmission buffer. The selection of the second SDU among the SDUs with unknown, or pending, reception status is performed according to a configuration which includes the following three options:

In a first option, during method step 904, the selected SDU is the SDU with the smallest sequence number among the SDUs with pending reception status.

In a second option, during method step 904, the selected SDU, is the SDU with the smallest sequence number among the SDUs with unknown, or pending, reception status and included in the PDU Set with the smallest remaining time.

In a third option, during method step 904, the selected SDU, is the SDU with the smallest sequence number among the SDUs with unknown, or pending, reception status and included in the most important PDU Set with the smallest remaining time.

Next, the RLC transmitter proceeds with method step 905 and sends the first SDU according to RLC AM rules (e.g., as defined in TS 38.322). During a subsequent method step 906, the RLC transmitter waits for the next transmission opportunity from the lower layer of the protocol stack. A further method step 907 involves the RLC transmitter sending the second SDU according to RLC AM rules (e.g., as defined in TS 38.322).

Insofar as the above-described method (e.g., including any one of method steps 900 to 907) relates to the identification, selection and/or retransmission of a “second SDU”, it will be appreciated that the term “second” can be considered an arbitrary characteristic. For example, the same method steps maybe applied to a “first SDU” that it identified for retransmission.

Figure 10 is a flow chart of the method according to the second embodiment of the present disclosure, as implemented by the RLC transmitter 501 . The method steps of Figures 9 and 10 are identical except for method step 1001 in Figure 10, which different to method step 901 in Figure 9b. For brevity, only the differential method step 1001 will be described in detail. During method step 1001 , the RLC transmitter checks if the first SDU is the last SDU of a PDU Set, regardless of the availability of other SDUs to be transmitted after the first SDU (in contrast to the requirements of method step 901 in Figure 9b). In this way, the method in Figure 10 is able to systematically schedule an anticipated retransmission at the end of each PDU Set.

Figure 11 is a further flow chart of the method according to the second embodiment of the present disclosure, as implemented by the RLC transmitter 501. The method steps of Figures 10 and 11 are identical except for the additional method step 1102 in Figure 11 , which is not present in Figure 10. For brevity, only this differential method step 1002 will be described in detail. During method step 1102, the RLC transmitter checks if the next SDU available for transmission after the first SDU is part of a more important PDU Set. If the next available SDU is part of a more important PDU Set, then the RLC transmitter proceeds with method step 1103. If the next available SDU is part of a less important PDU Set, or if there are no next SDU ready for transmission then the RLC transmitter proceeds with method step 1104. Accordingly, the method shown in Figure 11 is able to prevent scheduling an anticipated retransmission at the expense of a more important PDU Set.

The importance of the PDU Set can be determined by at least one of a PDU Set Importance (PSI) parameter, the associated delay budget, and the associated remaining time in the delay budget. For example, a combination of all three of these criteria is possible.

Figure 12 is a flow chart of the method according to the third embodiment of the present disclosure, as implemented by the RLC transmitter 501 . The method steps shown in Figures 9 and 12 are substantially similar except for method step 1201 , which is different from the corresponding method step 901. For brevity, only method step 1201 will be described in detail. During method step 1201 the RLC transmitter checks there is a transmit window stall situation. In case a transmit window stall condition is detected, the RLC transmitter proceeds with method step 1202, otherwise it proceeds with method step 1203. Advantageously, the method shown in Figure 12 is able to anticipate the retransmission of SDUs that are blocking the transmit window. The transmit window stall condition is detected by one of a combination of the following criteria:

A. the first SDU is the last SDU in the transmit window, and at least one other SDU is ready to be transmitted;

B. the first SDU is the nth last SDU in the transmit window, and at least one other SDU is ready to be sent, wherein n is a configuration parameter; and

C. the transmit window has not been updated for a predetermined amount of time.

Further embodiments relevant to the present disclosure will now be described.

As described above, there is a need to manage the retransmission of data during RLC AM operating conditions in order improve the operating efficiency of such communication networks. Specifically, during RLC AM, the retransmission of PDUs can experience large delays. Relying on RLC parameter tunning, such as polling frequency or a t_reassembly timer, cannot solve the issue.

One way to reduce the retransmission delay is to anticipate the retransmission of PDUs with unknown status. The unknown status is indicative of the PDU having been transmitted to the receiver but not acknowledged as being received or detected lost by the receiver. This enables earlier and more efficient retransmission of some PDUs, which thereby minimizes the overheads when compared to systematic retransmission. In this way, a means is provided for anticipating retransmission of PDUs with unknown statuses.

The overhead may be further reduced if the anticipated retransmission of PDUs with unknown status is not systematically triggered. For example, the anticipated retransmission of PDUs having an unknown status may occur following the transmission of all PDUs of a PDU Set. Put another way, the network overheads may be reduced by configuring a criterion for triggering anticipated retransmission of PDUs with unknown statuses.

Further description of embodiments of the present disclosure:

Within the context of managing data in a communication network configured to operate in RLC AM, the following points are considered:

A. Howto avoid unnecessary retransmission by RLC AM. To address this issue, the following options may be considered: A receiver (Rx) initiated approach and/or a transmitter (Tx) initiated approach. The Tx initiated approach may include configuring the transmitting side of AM RLC entity to notify the receiving RLC side about the obsolete SDUs. The Tx side then stops retransmitting obsolete SDUs, and the Rx side updates the state variables according to the information from Tx side. The Rx initiated approach may include configuring (e.g., enhancing) RLC AM with a way for the receiver to indicate abandoned SDUs to the transmitter (i.e. , to achieve proper advancing of the transmitting window). The Tx side just processes the status report as in legacy schemes. Further considerations may relate to how the Rx side may determine that an SDU should be abandoned.

B. How to achieve timely retransmission by the RLC AM. To achieve timely retransmissions on RLC layer for XR traffic, the following options may be considered: Autonomous retransmission (i.e. without status report) of PDUs based on some triggers (either existing triggers or new triggers can be considered); Retransmission based on enhanced status report; and Retransmission based on enhanced polling. Further consideration may relate to whether enhancements are needed, or whether the issue can be solved with proper configuration of existing mechanisms. Further consideration may be directed towards the impact of these options on the capacity (e.g., of a network), and possible enhancements for UL traffic.

The following techniques, according to embodiments of the present disclosure, are presented for ensuring timely RLC retransmission:

A. Autonomous retransmission: One way to reduce the retransmission delay is to anticipate the retransmission of PDUs with unknown status. The unknown status is indicative of the PDU having been transmitted to the receiver but not acknowledged as being received or detected lost by the receiver. This enables earlier and more efficient retransmission of some PDUs, which thereby minimizes the overhead when compared to systematic retransmission. Proposal 1 : Consider autonomous retransmission of PDUs with unknown status. The overhead may be further reduced if the autonomous retransmission of PDUs with unknown status is not systematically triggered. For example, the autonomous retransmission of PDUs having an unknown status may occur following the transmission of all PDUs of a PDU Set. Proposal 4: Further study the criteria for triggering autonomous retransmission of PDUs with unknown status.

B. Enhanced status report: Speeding-up the transmission (e.g., by the receiving side) of status reports by the introduction of new triggers. For example, a timer-based trigger. However, while triggering a status report either periodically or based on PDB may improve the responsiveness of the transmission, it will not be sufficient in all cases. For example, when a status report timer elapses while the t-Reassembly timer is still running, there will be no nack information sent to the transmitter. Observation 4: increasing the status report frequency is not useful when the t-Reassembly timer is still running.

Further, 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. Observation 5: Enhanced status report costs extra resources in downlink.

Discarding the prohibit timer may insure timely transmission of the status report. But the prohibit timer is set by the network for reasons that are independent from the XR application itself. Therefore, the prohibit timer should not be ignored when set. Proposal 5: Do not alter the prohibit timer when set by the network. Proposal 6: Do not enhance the status report.

C. 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. For example, one option may involve reducing the t-PollRetransmit timer below 5 ms. Observation 6: Increasing the polling frequency can result in a large number of non-useful status reports being sent.

Another option may be to initiate 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. Observation 7: Autonomous retransmission is necessary to overcome the delay induced by the t-Reassembly timer.

Yet further description of embodiments of the present disclosure:

Within the context of how to avoid unnecessary retransmission by RLC AM the following points are considered: Unnecessary RLC AM retransmissions may be avoided (or reduced) by configuring the RLC AM by adopting enhancements to either the receiver (Rx) initiated approach, or the transmitter (Tx) initiated approach. For the Tx initiated approach, the transmitting side of the AM RLC entity may notify the receiving RLC side about the obsolete SDUs. Following this, the Tx side stops retransmitting obsolete SDUs and the Rx side updates state variables according to the information from the Tx side. For the Rx initiated approach proper advancing of the transmitting window, RLC AM may be enhanced by providing a way for the receiver to indicate abandoned SDUs to the transmitter. Accordingly, the Tx side just processes the status report as in known methods. Such approaches do not consider how the Rx side should determine that an SDU should be abandoned.

The following techniques, according to embodiments of the present disclosure, are presented for avoiding unnecessary retransmission using the TX approach: For the TX initiated approach there is a potential risk for TX and RX window desynchronization. At the transmitting entity, the TX window may be updated once the discard decision is taken. In that case, the TX window is updated before the RX window is updated. Furthermore, the RX window will be updated based on the discard notification received from the transmitting entity. Consequently, the RX and TX windows will be out of sync for the time that it takes for the discard notification to arrive. In summary, for the TX initiated approach, the TX and RX windows may be out of sync for a negligible amount of time. Furthermore, considering the case of lost or corrupted discard notification signalling, it may be possible to adopt (and/or adapt) a Move Receiving Window (MRW) command (e.g., as defined in Universal Mobile Telecommunications System (UMTS) TS 125 322 V4.0.0 (2001-03)) to provide the relevant discard notification.

Figure 13 is a schematic diagram illustrating an example signalling between two nodes of a wireless communication network. An SDU can be discarded with explicit signalling when a predetermined threshold has been reached, for example, when a number of retransmissions (MaxDAT) is reached, or when the transmission time exceeds a predefined value (Timer_Discard) for an SDU in acknowledged mode RLC. In dependence on the predetermined threshold being reached, a “Move Receiving Window” (MRW) command can be sent to the receiver so that acknowledge mode data (AMD), e.g., a PDU carrying the SDU which is to be discarded by the receiver and/or the receiver window, is updated accordingly. A method according to embodiments of the present disclosure is configured to merge the MRW command with the discard notification signalling, in order to limit signalling overhead. In embodiments, the method may comprise the following steps for TX initiated approach:

1 . The TX discards one or more SDUs based on a PDCP discard timer;

2. The TX window is not updated but the one or more discarded SDUs are not sent;

3. The TX sends a discard notification to the RX;

4. The RX updates the RX window based on the discard notification;

5. The RX sends a status report acknowledging a new window boundary; and

6. The TX advances the TX window based on the status report.

The following techniques, according to embodiments of the present disclosure, are presented for avoiding unnecessary retransmission using the RX Approach. Contrary to the TX side, the RX side has no knowledge of PDU Sets at any layer of the protocol stack. This is because PDU Sets information, including PDU Set boundary and sequence numbers, are not included within inline communications. As a result, providing a means for the RX side to determine that an SDU is obsolete is therefore difficult. A method for addressing this problem may involve the receiving entity (e.g., the RX) abandoning SDUs based on a timer, like is already achieved according to the PDCP. The timer may then be started upon the detection of a sequence number gap detection. The timer can then be set to a value related to some delay budget. But the time to detect a sequence number gap is unpredictable. In a worse case (e.g., when the last PDU of a PDU Set is lost) the sequence number gap will only be detected at the successful transmission of a PDU of a further (e.g., subsequent) PDU Set. In summary, the time to detect a sequence number gap is unpredictable and can be as large as a PDU Set period. During the extra time induced by the sequence number gap detection, the transmitting entity may continue to retransmit obsolete SDUs even after the PDU Set delay budget has elapsed. For these reasons, at least, it is considered that the RX initiated approach is less efficient than the TX initiated approach.

The following techniques, according to embodiments of the present disclosure, are presented for avoiding unnecessary retransmission using a combined approach: For the combined approach, both the transmitting and receiving entities (e.g., Tx and Rx) autonomously discard the one or more SDUs based on a predefined criterion, for example similar to those criteria used in the TX and RX initiated approaches (e.g., timers). Eventually, each of the Tx and Rx sides will discard the same SDUs so there is no need for discard signalling or window signalling. However, the TX and RX windows will not be exactly synced because of the difference between the RX side and the TX side timers. Consequently, there may be concerns about the time taken by the receiving side to detect a sequence number gap before initializing a timer.

The relative advantages and disadvantages of the TX initiated approach, the RX initiated approach, and the combined approach are summarised in the Table 1 , below.

Table 1 : Comparison of Discard Approaches

The efficiency of the RX initiated approach is described in the above table as being “poor” because the time to detect a missing transmission (e.g., indicative of a sequence number gap) is wasted time. Accordingly, some unnecessary transmissions cannot be avoided. The efficiency of the combined approach is described in the table as “No signalling but/poor” because the TX and RX will not discard at the same time. Hence, the window synchronisation is affected by the time to detect a missing transmission (e.g., indicative of a sequence number gap). In embodiments, the method according to the TX initiated approach is adopted with window synchronization signalling, since this provides a favourable balance between signalling, efficiency, and window synchronisation requirements.

Still further description of embodiments of the present disclosure:

2.1 . Avoid unnecessary retransmission

2.1.1. TX Approach:

For TX approach it has been discussed as to whether there is a risk for TX and RX window desynchronization. At transmitting entity, the TX window may be updated once the discard decision is taken. In that case the TX window is updated prior to the RX window. The RX window will be updated based on the discard notification received from the transmitting entity. The RX and TX windows will be out of sync for the time that until the discard notification arrives. Observation: For TX initiated approach, the TX and RX windows may be out of sync for a negligible amount of time. Furthermore, in the case of lost or corrupted discard notification signalling, it is possible to adopt the Move Receiving Window (MRW) command as defined in UMTS TS 125 322 V4.0.0 (2001-03): An SDU can be discarded with explicit signalling when MaxDAT number of retransmissions is reached or the transmission time exceeds a predefined value (Timer_Discard) for an SDU in acknowledged mode RLC. Move Receiving Window (MRW) command is sent to the receiver so that AMD PDUs carrying that SDU are discarded in the receiverand the receiver window is updated accordingly (see Fig. 13). In order to limit the signalling overhead, it is proposed to merge the MRW command with the discard notification signalling. Proposal: Adopt the following steps for TX initiated approach:

1 . TX discards SDUs based on PDCP discard timer

2. The TX window is not updated but the discarded SDU are not sent

3. TX sends discard notification to RX

4. RX updates RX window based on discard notification

5. RX sends a status report acknowledging new window boundary

6. TX advances TX window based on status report

2.1 .2 RX Approach: Contrary to TX side, RX side has no knowledge of PDU Sets at any layer. This is because PDU Sets information, including PDU Set boundary and sequence numbers, are not included inline. How RX side can determine that an SDU is obsolete is therefore a difficult issue. It has been agreed that the receiving entity will abandon SDUs based on a timer, like already done by PDCP. It is then likely that the timer would be started upon a sequence number gap detection and would be set to a value related to some delay budget. But the time to detect a sequence number gap is unpredictable, with a worst case when the last PDU of a PDU Set is lost, the sequence number gap will only be detected at the successful transmission of a PDU of a further PDU Set. Observation: The time to detect a sequence number gap is unpredictable and can be as large as a PDU Set period. During the extra time induced by the sequence number gap detection, the transmitting entity keeps retransmitting useless SDUs even after the PDU Set delay budget has elapsed. Observation: RX initiated approach is less efficient than the TX initiated approach

2.1 .3 Combined approach: In the combined approach both the transmitting and receiving entities autonomously discards SDUs based on similar criteria (timers). Eventually, each side will discard the same SDUs so there is no need for discard signalling or window signalling. However, the TX and RX windows will not be exactly synced because of the difference between the RX side and TX side timers. Of greater concern is the time taken by the receiving side to detect a sequence number gap before initializing a timer.

(*) Time to detect a missing is a waste of time => some unnecessary transmission cannot be avoided. (**) TX and RX will not discard at the same time (time to detect a missing). Proposal: Adopt TX side approach with window synchronization signalling

Even further description of embodiments of the present disclosure:

Within the context of the problem of how to avoid unnecessary and/or untimely retransmission by RLC AM the following points are considered:

One way to reduce the retransmission delay is to anticipate the retransmission of PDUs with unknown status. The unknown status may be indicative of the PDU having been transmitted to the receiver but not acknowledged as being received or detected lost by the receiver. This enables earlier and more efficient retransmission of some PDUs, which thereby minimizes the network overhead when compared to a systematic retransmission. The overhead may be reduced further if the autonomous retransmission of PDUs with unknown status is not systematically triggered. The autonomous retransmission of PDUs having an unknown status may occur following the first transmission of all SDUs of a PDU Set. Alternatively (or in addition) the autonomous retransmission of PDUs having an unknown status may occur when the transmit and retransmit buffers are empty.

In order to decrease the required network resources even further, the autonomous retransmission trigger can be further extended to a remaining time threshold applied to the transmit window. If the transmit window is stalled up to the remaining time threshold of a PDU Set, then autonomous retransmission may be triggered. Careful design of the autonomous retransmission trigger may allow drastic reduction of unnecessary SDU retransmission.

In terms of packet delay, autonomous retransmission can achieve better performances since the retransmission decision does not rely on a prior exchange of signalling with the receiving side. The gain in delay reduction can be substantially higher in favour of autonomous retransmission if the conditions for polling bit triggering are not enhanced. In this way, autonomous retransmission can achieve better retransmission delay.

In terms of capacity cost, autonomous transmission may trigger some unnecessary SDU retransmission, whilst the enhanced polling can generate unnecessary signalling exchange. The difference is not obvious to quantify, because there are numerous factors to take into account like the design of autonomous retransmission trigger, the size of the SDUs, or the frequency of the polling. Accordingly, the capacity impact of autonomous retransmission can be managed through careful design of triggering condition.

In terms of complexity, autonomous retransmission has an impact only on the TX side whereas the polling needs to be enhanced at the TX side for triggering, and at the RX side for timer management. In this way, autonomous retransmission may be less complex than polling enhancement. It is advantageous to adopt autonomous retransmission for PDUs with unknown status.

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/ordata 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, orwireless 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), laserdisc, 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 operating in a radio link control acknowledge mode, the communication network comprising a transmitter and a receiver, wherein the method at the transmitter comprises: retransmitting a PDU having an unknown status prior to receiving a notification from the receiver indicating the status of the PDU.

2. The method of claim 1 , wherein the PDU is retransmitted based on the remaining time for transmission of the PDU.

3. The method of claim 1 or claim 2, wherein the PDU retransmission is initiated in dependence on the remaining time for transmission of the PDU falls below a threshold.

4. The method according to any one of claims 1 to 3, wherein the unknown status corresponds to the PDU having been transmitted to the receiver but not acknowledged as being received by the receiver.

5. The method according to any one of claims 1 to 3, wherein the unknown status corresponds to the PDU having been transmitted to the receiver but not acknowledged as being not received by the receiver.

6. The method according to any one of claims 1 to 5, wherein the notification is received in response to the transmission to the receiver of a polling bit.

7. The method according to any one of claims 1 to 6, wherein the notification is received when a timer set by the receiver expires.

8. The method according to any one of the preceding claims, wherein the notification corresponds to a negative acknowledgement that the PDU has not been received by the receiver.

9. The method according to any one of the preceding claims, wherein, prior to receiving the notification from the receiver, another notification is received from the receiver indicating the status of the PDU, wherein the prior notification corresponds to a positive acknowledgement of at least one PDU having been received by the receiver.

10. The method according to any one of the preceding claims, wherein the PDU is associated with a first PDU Set which is followed by a second PDU Set comprising a PDU different from the PDU of the first PDU Set, wherein retransmission of the PDU having an unknown status occurs following the transmission of the first PDU Set and before transmission of the second PDU Set.

11. The method according to claim 10, wherein retransmission of the PDU having an unknown status occurs if the second PDU Set has a lower priority than the first PDU Set.

12. The method according to claim 10 or claim 11 , wherein retransmission of the PDU having an unknown status occurs during a transmission opportunity arranged between the first PDU Set and the second PDU Set.

13. The method according to any one of claims 10 to 12, wherein the retransmission of the PDU having an unknown status occurs based on an indication from a lower layer of the protocol stack of the availability of a transmission opportunity.

14. The method according to any one of claims 10 to 13, wherein the PDU having an unknown status is selected for retransmission based on a sequence number of the PDUs associated with the first PDU Set.

15. The method according to claim 14, wherein the retransmitted PDU is selected for retransmission based on the remaining time for transmission of the first PDU Set.

16. The method according to any one of claims 10 to 13, wherein the PDU having an unknown status is the last PDU in a transmission window, and at least one other PDU of the PDU Set is ready to be transmitted.

17. The method according to any one of claims 10 to 13, wherein the PDU having an unknown status is the nth last PDU in a transmit window, and at least one other PDU of the PDU Set is ready to be sent.

18. The method according to any one of claims 10 to 13, wherein a transmit window has not been updated for a predetermined amount of time.

19. The method according to any preceding claim, wherein the notification is generated based on the detection of a gap in the sequence of the PDUs received by the receiver.

20. The method according to any preceding claim, wherein the notification is generated based on duplicate detection of a PDU being received by the receiver.

21 . The method according to any preceding claim, wherein the notification is generated at the end of a timer set by the receiver.

22. A communication network which comprises a transmitter configured to perform the method of any one of claims 1 to 21.

23. 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 21 .

24. A computer-readable medium carrying a computer program according to claim 23.