Method for managing data transmission in a communication network

Abstract

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

Description

Technical Field

[0001] This disclosure relates to a method for managing data in a communication network (e.g., a mobile telecommunications network). More specifically, the method is intended to be configured to manage data in a communication network operating in Radio Link Control Acknowledgment Mode (RLC AM). Background Technology

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

[0003] Examples of such wireless multiple access communication systems include systems based on the 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 the IEEE 802.11 standard, such as Wi-Fi. Among the requirements for 5G NR, there are service requirements related to Extended Reality (XR).

[0004] XR (Extended Reality) applications are defined in 3GPP document RP-2200285 as "various types of augmented, virtual, and hybrid environments in which human-to-machine and human-to-human communication is assisted by handheld and wearable end-user devices." Various use cases can be found in 3GPP document TR-26.928.

[0005] Many XR applications involve interaction between wearable devices (e.g., 3D helmets or augmented reality glasses) and application servers. Wearable devices and application servers can connect via local networks (e.g., wireless LAN) or cellular networks (e.g., 3GPP 5G cellular networks, where the application server connects to the network's 5G core network components).

[0006] Some XR applications (such as cloud gaming) involve transmitting compressed video data and audio data from the server to the user interface (UE), as well as transmitting location information from the UE to the server.

[0007] Some XR applications (such as virtual reality) involve transmitting compressed video data, audio data, and various information from a server to a wearable device.

[0008] Some XR applications (such as augmented reality) involve transmitting compressed video data, audio data, and various other information exchanged between wearable devices and servers.

[0009] In this disclosure, the information exchanged between the UE (e.g., a wearable device) and the server is referred to as application data, which may include one or more images, video data, audio data, location information, etc.

[0010] Video and audio data are transmitted between a UE (e.g., a wearable device) and a server using media delivery protocols such as RTP (Real-Time Protocol, RFC 3550), SRTP (Secure RTP, RFC 3711), HTTP (Hypertext Transfer Protocol, RFC 2616-7540), or QUIC (RFC 8999, 9000, 9001, and 9002).

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

[0012] According to 3GPP standards, a set of Protocol Data Units (PDUs) or Packet Data Units (PDUs) is required to transmit application data packets (i.e., a "PDU set"). Therefore, application data includes one or more application data packets. During downlink, the 3GPP PDU is formatted by the PDU layer of the core network. Similarly, during uplink, the 3GPP PDU is formatted by the PDU layer of the UE (e.g., a wearable device). According to 3GPP standards, the definition of the PDU set (e.g., start, stop, and length) is not provided by the application but is generated by the core network (correspondingly, the UE) through a media delivery protocol packet check. Detailed procedures can be found in 3GPP document S2-2302696.

[0013] A PDU set includes one or more PDUs carrying a payload of an information unit generated at the application level (e.g., a frame or video strip used for XRM services, as used in TR 26.926). In some implementations, the application layer requires all PDUs in the PDU set to use the corresponding information unit. For example, a PDU set may include data from an image or frame from a video stream. In other implementations, the application layer can still recover some or all of the information units when some PDUs are missing.

[0014] The network used to transmit application data may experience disturbances and congestion. As a result, some PDUs in the PDU set may be missing or delayed on the receiving side (e.g., UE PDU layer during downlink and core network user plane function (UPF) during uplink).

[0015] Some video decoder implementations require timely receipt of complete application data packets (e.g., a complete set of PDUs) for adequate video decoding. Other implementations can tolerate delayed arrival or partial delivery of data packets. These implementations, for example, rely on forward error correction (FEC) or hiding techniques.

[0016] According to the 3GPP standard, document S2-2302696 defines a PDU set QoS parameter called PDU set Delay Budget (PSDB). The PSDB defines the time budget allocated for delivering PDU sets across the 5G network. This QoS parameter, defined by the application, is used by the 5G network to assess whether PDU sets (e.g., application data packets) are delivered on time.

[0017] In the same 3GPP document S2-2302696, another QoS parameter named PDU Collective Integrated Disposal Indicator (PSIHI) is defined to characterize the decoder's tolerance for data loss or reception of outdated (e.g., delayed) data. If the PSIHI parameter is set to "True", the decoder can only dispose of (e.g., manage or process) complete application data packets received on time. If the PSIHI parameter is set to "False", the decoder can tolerate both incomplete application data packets and delayed application data packets.

[0018] Considering the specific circumstances at certain components of a 5G network, some information regarding the reception status of PDUs and the elapsed time of the PSDB is available when a set of PDUs is transmitted over the air interface. For example, when a set of PDUs is transmitted over the air, a Radio Access Network (RAN) node (e.g., a UE or Next Generation Node (gNB)) can detect that a PDU transmission has failed (regardless of full retransmission and error correction mechanisms). In this case, if the PSIHI parameter is set to "true," the entire set of PDUs is useless to the application. In this situation, if one or more PDUs in this "useless" set are waiting for transmission over the air interface, the RAN node can consider discarding the remaining transmission of the "useless" PDUs, thereby saving radio network resources.

[0019] PDU sets are mapped onto QoS flows (SDAP layer), QoS flows are mapped onto DRBs (PDCP layer), DRBs are mapped onto RLC channels (RLC layer), and RLC channels are mapped onto logical channels (MAC layer). The MAC layer implements a reliability mechanism known as Hybrid ARQ, which provides a given level of reliability that can be enhanced by the RLC layer if needed. The RLC layer Acknowledgment Mode (AM) implementation allows for additional ARQ mechanisms to further enhance transmission reliability. The ARQ mechanism relies on an RLC receiver that sends a status report to an RLC transmitter indicating the status of received PDUs (e.g., Service Data Units, SDUs), which in turn schedules retransmissions of lost PDUs and updates the transmission window.

[0020] Status reports at the RLC receiver are triggered on demand by the RLC transmitter (e.g., polling bit) or by the RLC receiver detecting a lost SDU. An SDU is detected as lost when a sequence number gap is detected and a timer (e.g., t-reassembly timer) has elapsed.

[0021] Therefore, on the RLC transmitter side, the decision to retransmit the SDU is delayed by both polling and the t-reassembly timer. While this may reduce overhead (or the total number of retransmissions), it introduces additional latency when the lower layer ultimately fails to transmit the SDU correctly. This additional latency is unacceptable for applications requiring both high reliability and low latency (XR).

[0022] Furthermore, delaying the retransmission of an SDU has negative consequences for transmission window management. The transmission window is defined between a lower bound and an upper bound of the SDU sequence number. The transmission window defines the SDUs eligible for transmission. It is updated by incrementing both the lower and upper bounds. Therefore, the transmission window is only updated when the reception status of the lower bound SDU is acknowledged as good; otherwise, it remains unchanged even if higher layers of the protocol stack (e.g., PDCP) provide new SDUs for transmission. For example, transmission of the second PDU set may stall because the reception status of an SDU in the first PDU set is not acknowledged and the SDU sequence number of the second PDU set is outside the transmission window. This phenomenon is also known as transmission window stalling.

[0023] Methods have been proposed to reduce the impact of transmission window stagnation. For example, some network parameters can be tuned to improve status report responsiveness. The maximum polling frequency can be configured to one polling bit every four packets. However, the polling frequency cannot match the PDU set boundaries because the PDU set boundaries are variable.

[0024] Alternatively, the t-reassembly timer can be reduced (or even set to 0), thus increasing the responsiveness of the RLC receiver once a sequence number gap is detected. However, reducing the t-reassembly timer increases the number of false missing detections, which can then increase overhead across the entire network. Therefore, data retransmission needs to be managed during RLC AM operating conditions to improve the operational efficiency of such communication networks. Summary of the Invention

[0025] According to embodiments of this disclosure, means are provided for preemptively retransmitting a Protocol Data Unit (PDU) with an unknown state before it is determined (e.g., decided, inferred, identified, estimated, and / or calculated) that the PDU has been lost.

[0026] According to a first embodiment, a method is provided for managing data transmission in a communication network operating in a radio link control acknowledgment mode, the communication network including a transmitter and a receiver, wherein the method at the transmitter includes: retransmitting a PDU having an unknown state before receiving a notification from the receiver indicating the state of the PDU.

[0027] Advantageously, the method according to this disclosure enables the transmitter to anticipate (e.g., and thus trigger) the retransmission of potentially missing and / or lost PDUs. This allows for earlier and more efficient retransmission of PDUs, thereby minimizing overhead in the communication network.

[0028] In an embodiment, PDU retransmission may be based on the remaining time of PDU transmission (and / or triggered by that remaining time).

[0029] PDU retransmission can be initiated when the remaining transmission time of the PDU falls below a threshold (e.g., an autonomous retransmission threshold that can be predetermined by an entity in the wireless communication network).

[0030] An unknown status indicates that the PDU has been transmitted to the receiver, but has not yet been acknowledged as received by the receiver.

[0031] An unknown status indicates that the PDU has been transmitted to the receiver, but has not yet been confirmed as not received by the receiver.

[0032] The notification may be received in response to the transmission of a polling bit to the receiver. The notification may also be received when a timer set by the receiver expires.

[0033] The notification may indicate (for example, include) a negative acknowledgment that the PDU has not yet been received by the receiver.

[0034] Before receiving this notification from the receiver, the transmitter may receive other notifications 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 earlier notification (e.g., the first notification) may indicate (e.g., include) a positive acknowledgment that at least one PDU has 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 has been received.

[0035] A PDU can be associated with a first set of PDUs. Following the first set of PDUs may be a second set of PDUs, which includes at least one PDU that is different from the PDUs in the first set of PDUs. Retransmission of a PDU with an unknown state (e.g., associated with the first set of PDUs) may occur after the transmission of the first set of PDUs (e.g., transmission completed or aborted) and before the transmission of the second set of PDUs (e.g., before the start of transmission).

[0036] Retransmission of PDUs with unknown states can be determined (e.g., identified) based on multiple criteria. For example, retransmission of PDUs with unknown states can occur if the second set of PDUs has a lower priority than the first set of PDUs. Retransmission of PDUs with unknown states can occur during transmission opportunities (e.g., buffers) arranged (e.g., between) the first and second sets of PDUs.

[0037] Retransmission of PDUs with unknown states can occur based on the amount of data that has not been transmitted to lower layers of the protocol stack. In other words, retransmission can be based on indications of the availability of transmission opportunities from lower layers of the protocol stack (e.g., if one or more PDUs from the same set of PDUs have been dropped or not received by different levels of the protocol stack).

[0038] A PDU with an unknown state can be selected for retransmission based on the sequence number of the PDUs associated with the first PDU set. For example, the retransmission of the last PDU in the PDU set can be prioritized. Alternatively, if the PDU is not the last in the sequence of the PDU set, the retransmission of the PDU according to this method may not proceed (e.g., the PDU retransmission may be delayed, or retransmission may be performed using conventional data management methods).

[0039] The PDUs to be retransmitted can be selected for retransmission based on the remaining transmission time of the first set of PDUs.

[0040] Retransmission can be determined based on the PDU with an unknown state being the last PDU in the transmission window (e.g., configuration or control), and at least one other PDU in the PDU set being ready to be transmitted. Retransmission can also be determined based on the PDU with an unknown state being the nth-to-last PDU in the transmission window, and at least one other PDU in the PDU set being ready to be sent. Retransmission can also be determined based on the transmission window not being updated for a predetermined amount of time.

[0041] The notification can be generated based on the detection of gaps in the sequence of PDUs received by the receiver. The notification can also be generated based on the repeated detection of PDUs received by the receiver. Alternatively, the notification can be generated when a timer set by the receiver expires.

[0042] Data packets with unknown states (e.g., PDUs) can be considered to be in a pending state. A pending state can indicate that the PDU has been received at a relay node, but has not yet been received at the destination node of the communication network (such as a UE in the downlink direction or a base station in the uplink direction).

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

[0044] The method steps for determining the state of a PDU may include: transmitting a first PDU in the PDU set; transmitting a second PDU in the PDU set after the first PDU; and

[0045] Receive a (first) notification indicating the status of only one of the transmitted PDUs (e.g., the first PDU instead of the second PDU).

[0046] Polling bits can be transmitted to the receiver in the header of the PDU sent by the transmitter.

[0047] Retransmission of a PDU with an unknown state can occur based on one or more missing PDUs from at least one of the first PDU set and the second PDU set.

[0048] According to a second embodiment, a communication network is provided, including a transmitter configured to perform the method according to a first embodiment. According to a third embodiment, a computer program including instructions that, when executed by the transmitter, cause the transmitter to perform the method according to the first embodiment. According to a fourth embodiment, a computer-readable medium carrying a computer program according to the third embodiment is provided.

[0049] Throughout the foregoing statements (and more generally, in the specification), it will be understood that a phrase protocol data unit (i.e., PDU) may also refer to a service data unit (i.e., SDU), depending on the context.

[0050] Any feature in one embodiment of this disclosure may be applied in any suitable combination to other embodiments of this disclosure. In particular, method embodiments may be applied to device / apparatus / unit embodiments, and vice versa.

[0051] It will be understood that features implemented in hardware can be implemented in software, and vice versa. Any references to software features and hardware features herein should be interpreted accordingly. For example, according to other embodiments of this disclosure, a computer program including instructions is provided that, when executed by one or more processing units, cause one or more processing units to perform the methods of any of the embodiments or examples described above, and a computer-readable storage medium carrying the computer program is provided.

[0052] The foregoing summary is provided for the purpose of outlining some examples to provide a basic understanding of embodiments of the subject matter described herein. Therefore, the foregoing features should not be construed as narrowing the scope or spirit of the subject matter described herein in any way. Furthermore, the foregoing and / or the foregoing examples can be combined in any suitable combination to provide further examples, unless such combination is clearly not permitted or explicitly avoided. Other features, embodiments, and advantages of the subject matter described herein will become apparent from the following text and accompanying drawings. Attached Figure Description

[0053] Different embodiments of this disclosure will now be described by way of example only and with reference to the following figures, in which:

[0054] Figure 1 This is a schematic diagram illustrating a first example wireless communication system that can implement the present disclosure according to one or more embodiments;

[0055] Figure 2 This is a schematic diagram illustrating an example configuration of a UE that can implement the present disclosure according to one or more embodiments;

[0056] Figure 3This is a schematic diagram illustrating an example configuration of a base station that can implement the present disclosure according to one or more embodiments;

[0057] Figure 4 Examples Figure 1 The diagram shows a schematic of the data plane protocol stack of a 5G NR system.

[0058] Figure 5 This is a flowchart illustrating the sequence exchange between an RLC transmitter and an RLC receiver in a wireless communication system;

[0059] Figure 6 This is a schematic diagram illustrating a first method for managing data transmission between an RLC transmitter and an RLC receiver;

[0060] Figure 7 This is a schematic diagram illustrating a second method for managing data transmission between an RLC transmitter and an RLC receiver;

[0061] Figure 8 This is a schematic diagram illustrating a third method for managing data transmission between an RLC transmitter and an RLC receiver;

[0062] Figure 9a and Figure 9b This is a flowchart illustrating the first method implemented at the RLC transmitter;

[0063] Figure 10 and Figure 11 This is a flowchart illustrating the second method implemented at the RLC transmitter;

[0064] Figure 12 This is a flowchart illustrating the third method implemented at the RLC transmitter; and

[0065] Figure 13 This is a schematic diagram illustrating example signaling between two nodes in a wireless communication network. Detailed Implementation

[0066] Embodiments of this disclosure will now be discussed with reference to the accompanying drawings. Further embodiments will be apparent to those skilled in the art.

[0067] Figure 1 An example wireless communication system 100 is illustrated, particularly a mobile radio communication system such as a fifth-generation (5G) New Radio (NR) system supporting Extended Reality (XR) services. Although embodiments and examples of embodiments of this disclosure are described with reference to 5G NR systems in the following description, it will be understood that this disclosure is not intended to be limited to 5G NR systems and can be used in any wireless communication system supporting XR or similar services.

[0068] System 100 includes user equipment (UEs) 101 and 151 served by base station 110 to communicate with a core network such as 5G core network 102. The UEs can be, for example, virtual reality headsets or extended reality wearables (such as glasses). The UEs can be any wireless device capable of wirelessly communicating with one or more core networks via one or more radio access networks, such as wireless communication devices or terminals, IoT devices, machine-type communication (MTC) devices, device-to-device (D2D) terminals, and user equipment (e.g., smartphones, laptops, mobile phones, tablets, cameras, game consoles, wearable devices). Base station 110 is a network node providing access to the core network for the UEs and is part of the radio access network (RAN) comprised of base stations 110 and 111. In NR, the base station is referred to as a next-generation node B (gNB), the RAN is a next-generation (NG) RAN, and the core network is referred to as 5GC. In the following text, the terms RAN node, base station, and gNB will be used interchangeably. Base stations 110 and 111 are interconnected via an Xn interface implemented on wired or wireless link 130 (e.g., as specified in 3GPP document TS 38.423). Each base station is connected to core network 102 via an NG interface implemented on wired or wireless links 140 and 141 (e.g., as specified in 3GPP document TS 38.413).

[0069] These base stations each control one or more cells. For example, base station 110 controls cell 120, and base station 111 controls cell 121. A cell is a geographical area of ​​a radio network defined by the frequencies used for data transmission within the cell. A UE can uniquely identify a cell based on an identifier broadcast in the geographical area. Each base station 110, 111 can serve several UEs 101, 151. Once a UE has established an RRC connection with a base station, the base station to which the UE is connected is called the UE's serving base station (or source base station), and the cell controlled by the serving base station and where the UE camps is called the serving cell. The interface between the gNB and the UE is the Uu interface using the protocol sublayers Serving Data Adaptation Protocol (SDAP), Packet Data Convergence Protocol (PDCP), Radio Link Control (RLC), Medium Access Control (MAC), and Physical (PHY) in the user plane, and the protocol sublayers Radio Resource Control (RRC), PDCP, RLC, MAC, and PHY in the control plane.

[0070] Assume that UE 101 is receiving and / or transmitting XR data for one or more multicast XR sessions generated for and / or destined for XR application server 103. The XR data is provided to base station 111 (which is the base station controlling cell 121 to which UE 101 is attached) via core network 102 (e.g., via data network 160 and user plane function 161) and a pass bearer (also known as a GTP-U tunnel) 106 on link 141. Base station 111 then transmits the XR data to UE 101 via data radio bearer (DRB) 154. Figure 1 The diagram also shows UE 151 receiving data via DRB 153. A radio bearer is a set of PHY (Layer 1) and MAC (Layer 2) parameters that allow higher-layer data connections between the UE and the gNB. Several types of radio bearers are defined in 5G NR: signaling radio bearers (SRBs) for the control plane, data radio bearers (DRBs) that allow point-to-point communication (e.g., unicast) with a single UE in the user plane, and multicast radio bearers (MRBs) that allow point-to-point and point-to-multipoint communication (e.g., multicast / broadcast) with multiple UEs also in the user plane.

[0071] Figure 2 The UE device 205 that can implement the present disclosure is based on one or more embodiments of the present disclosure (e.g., Figure 1 A block diagram of UE 101 or UE 151. The UE includes components for transmitting and receiving communications, such as at least one of a UE communication manager 220, an I / O controller 255, a transceiver 235, an antenna assembly 245, a storage device (e.g., a memory) 225, and a processor (CPU: central processing unit) 215. All these components can communicate with each other.

[0072] Memory 225 includes random access memory (RAM), read-only memory (ROM), or a combination of both. Alternatively or additionally, memory 225 may include a mass storage device, such as a disk or solid-state drive (SSD). Basic Input / Output System (BIOS) instructions may be stored in memory 225.

[0073] Processor 215 is configured to execute machine-readable instructions. The execution of these machine-readable instructions enables the UE to perform various functions. These functions may involve transmission and / or communication with peripheral devices (e.g., keyboard, screen, mouse, etc.). Figure 2 (Not shown in the image) interaction. The processor can run an operating system such as iOS, Windows, Android, etc. Processor 215 can be a single processor, or it can include two or more processors that may include the processing required to perform the operations of UE 205.

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

[0075] The I / O controller 255 can interact, for example, with all or part of an image capturing device, image rendering device, audio capturing device, audio rendering device, or sensor device capable of determining the location of use.

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

[0077] Radio communication uses an antenna set 245 adapted to the spectrum of frequency-transposed signals emitted from a baseband modem. The antenna set 245 may be limited to a single antenna, but preferably it comprises several antennas to provide beamforming capability.

[0078] The UE communication manager 220 controls the establishment of communication between the UE and the radio access network (RAN). The UE communication manager 220 can also be configured to control the UE's control and release relative to the RAN. The UE periodically receives indications from a base station (e.g., a gNB) of time slots available for communication between the UE and the base station. Therefore, the UE can determine when and at what frequency (e.g., from the gNB) it should expect to receive incoming data. Furthermore, the UE can identify when and at what frequency it should transmit outgoing data. The UE can determine data transmission / reception regardless of whether the data belongs to the control plane or the data plane. In one example implementation, the UE communication manager 220 implements a Uu interface.

[0079] Figure 3 Examples of embodiments that can implement this disclosure are illustrated. Figure 1 A block diagram of a base station apparatus 305, such as gNB 110 and 111. Base station apparatus 305 includes components for transmitting and receiving communications (e.g., relative to a 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, an antenna assembly 345, a memory 325, a processor (e.g., CPU) 315, and an inter-site communication manager 365. All these components can communicate with each other.

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

[0081] The Core Network Communication Manager 355 manages communication between the base station and the core network. The Core Network Communication Manager 355 can provide standardized NG interfaces, such as those defined by 3GPP standards, to support these communications.

[0082] Transceiver 335 is configured to provide bidirectional wireless communication with other wireless devices, such as UEs or even other base stations. Transceiver 335 provides the necessary modem and frequency shifter to simultaneously connect to a large number of UEs using different frequency carriers in Time Division Duplex (TDD) or Frequency Division Duplex (FDD). Transceiver 335 may include a PDCP transmitter and a PDCP receiver. The PDCP transmitter and receiver may be implemented by processor 315. The PDCP transmitter and receiver may be software-only functions implemented by processor 315. Transceiver 335 is connected to antenna assembly 345, which may be limited to a single antenna, but preferably includes several antennas to provide beamforming capabilities.

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

[0084] Inter-site Communication Manager 365 manages communication with other base stations. Inter-site Communication Manager 365 can provide standardized Xn interfaces (e.g., as defined by 3GPP standards) to support these communications.

[0085] Figure 4 Examples Figure 1The diagram shows a block illustration of the data plane protocol stack of a 5G NR system. The data plane protocol stack is described in detail in 3GPP document TS23.501. In the downlink direction, application server 103 connects to user plane function (UPF) 161 via data network 160 at PDU layer 402. The PDU layer corresponds to the PDU carried between the UE and data network (DN) on the PDU session. When the PDU session type is IPv4, IPv6, or IPv4v6, the PDU corresponds to an IPv4 packet, an IPv6 packet, or both. When the PDU session type is Ethernet, the PDU corresponds to an Ethernet frame; and so on. At the start of the PDU session (i.e., at PDU establishment time), the core network provides session QoS parameters to the UPF, gNB, and UE. PDU session QoS parameters include XR PDU set QoS parameters (S2-2302696):

[0086] A. PDU Set Delay Budget (PSDB);

[0087] B. PDU set error rate (PSER); and

[0088] C. PDU Integrated Processing Instruction (PSIHI), formerly known as PDU Integrated Processing Instruction.

[0089] In relation to Figure 4 In the description, unless otherwise stated, a PDU refers to a group of packets disposed of (e.g., managed or processed) by PDU layer 402. Other types of PDUs are disposed of by other layers. Therefore, PDUs belonging to one of the other layers (i.e., other than PDU layer 402) are referred to herein by a prefix corresponding to the corresponding layer name (e.g., PDCPPDU or MAC PDU).

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

[0091] As described in 3GPP document S2-2303842, the PDU set identification information is determined by the UPF and sent to the NG RAN in the GTP-U header. The PDU set identification information includes:

[0092] A. PDU set sequence number;

[0093] B. Indication of the end PDU of the PDU set;

[0094] C. The PDU serial number within the PDU set;

[0095] D. Size of the PDU set; and

[0096] E. PDU set importance, which identifies the relative importance of a PDU set compared to other PDU sets within a QoS flow.

[0097] During the uplink, the application resides on the UE. As previously described, the UE obtains PDU session QoS parameters from the core network when establishing a PDU session (e.g., the PDU session establishment procedure is defined in TS23.502, Clause 4.3.2). When one or more PDUs generated by application 403 arrive at the UE PDU layer 402, the UE performs an application packet check to determine the PDU set boundaries (similar to the procedure described above regarding UPF).

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

[0099] During downlink, the UPF detects PDU set identification information and obtains a set of mapping rules (e.g., filtering rules) from the core network. The filtering rules define how to map individual PDU sets to QoS flows. The QoS flow, or individual QoS flows, is identified by an identifier, and the GTP-U PDU is labeled according to the determined QoS flow identifier. At the gNB, the relay layer 406 extracts the PDU set identification information and QoS flow identifier from the GTP-UPDU and maps them to (one or more) SDAP QoS flows. During an XR session (e.g., a single XR session), multiple PDU sets can be mapped to the same QoS flow. Alternatively (or additionally), one or more PDU sets can be mapped to different QoS flows. Then, according to 3GPP document TR-38.835, in a first alternative arrangement, individual SDAP QoS flows can be mapped to different PDCP data radio bearers (DRBs). According to a second alternative arrangement, all SDAP QoS flows from the same XR session can be mapped to a PDCP DRB (e.g., a single PDCP DRB).

[0100] During uplink, the UE detects PDU set identification information at PDU layer 402 and obtains a set of mapping rules (e.g., filtering rules) from the core network. The filtering rules define how to map individual PDU sets to (one or more) QoS flows. The UE maps XR PDUs to associated SDAP QoS flows according to the filtering rules. Similar to downlink, during uplink, multiple PDU sets can be mapped to the same or different (one or more) QoS flows within an XR session (e.g., a single XR session).

[0101] During downlink, application layer 103 generates at least one application flow toward at least one UE (e.g., a single UE), such as one or more video streams and one or more audio streams. Then, at PDU layer 402, the application flows are arranged in PDU sets. The individual application flows are divided into multiple PDU sets of the same or different types. Then, within GTP-U layer 404, the individual PDU set types are mapped to QoS flows, thus allowing multiple application flows to be multiplexed within a QoS flow (e.g., a single QoS flow). Alternatively, the individual application flows can be mapped to different QoS flows. Alternatively, the application flows can also be divided into multiple QoS flows. Then, SDAP layer 407 maps the QoS flows to DRBs, each DRB being handled (e.g., managed or processed) by a dedicated PDCP entity. Like QoS flows, multiple application flows can be multiplexed within a single DRB. Alternatively, the individual application flows can be mapped to different DRBs. Alternatively, the application flows (e.g., a single application flow) can also be divided into multiple DRBs.

[0102] During the uplink, application layer 403 generates at least one application stream toward application server 103, such as one or more video streams, one or more audio streams, or one or more sensing streams. Then, at PDU layer 402, the application streams are arranged in PDU sets. At least one or more application streams are divided into multiple PDU sets of the same or different types, and each PDU set type is mapped to a QoS stream, so multiple application streams can be multiplexed in a single QoS stream, or each application stream can be mapped to a different QoS. Alternatively, the application streams can be divided into multiple QoS streams. Then, SDAP layer 407 maps the QoS streams to DRBs. At least one or more radio bearers are handled (e.g., managed or processed) by a dedicated PDCP entity. For QoS streams, multiple application streams can be multiplexed in a single DRB (e.g., a single DRB), or each application stream can be mapped to a separate DRB. Alternatively, the application streams (e.g., a single application stream) can be divided into multiple DRBs.

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

[0104] In some cases, some XR data within an XR dataset may have a PDU set delay budget (PSDB) that cannot be exceeded because the data then becomes obsolete (e.g., useless to the decoder) after the delay period has elapsed. For example, when transmitting a PDU set on a 5G network, some information about the PDU reception status and the elapsed PSDB may be available. The gNB can detect whether a PDU transmission has failed (e.g., regardless of attempts to retransmit and error correction mechanisms). If the decoder can only handle (e.g., manage or process) complete application data packets received on time (e.g., if PSIHI is "true"), any remaining PDUs in the PDU set after the delay period has elapsed (i.e., PDUs still waiting to be transmitted) are useless to the decoder.

[0105] The RLC protocol layer can operate in three modes: Transparent Mode (TM), during which data is transmitted without headers or any protocol implementation; Unacknowledged Mode (UM), which implements fragmentation and copy detection; and finally, Acknowledged Mode (AM), which implements the same functionality as UM mode but adds a retransmission mechanism (e.g., Automatic Repeat Request (ARQ)).

[0106] RLC AM is used when enhanced reliability is required by lower layers of the protocol stack (e.g., PHY and MAC). The retransmission process for RLC AM is parameterized and configured by the gNB. An important parameter is the maximum allowed retransmission count for an RLC SDU (e.g., "maxRetxThreshold").

[0107] In cases where an SDU has been transmitted by the transmitter but not yet received by the receiver, the transmitter is configured to retransmit the missing SDU. Multiple retransmissions of the missing SDU can occur (e.g., at scheduled intervals) until certain conditions are met. For example, retransmissions can 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 for a single SDU has been reached (or exceeded). The RLCAM retransmission process also relies on an RLC receiver, which sends a status report to the RLC transmitter indicating the status of the received SDU. The RLC transmitter, in turn, schedules the retransmission of the lost SDU and updates the transmission window.

[0108] Status reports at the RLC receiver are triggered on demand by the RLC transmitter (e.g., polling bit) or by the RLC receiver detecting a lost SDU. An SDU is detected as lost when a sequence number gap is detected and a timer (e.g., t-reassembly) has elapsed (or the timer expires).

[0109] Therefore, on the RLC transmitter side, the decision to retransmit the SDU is delayed by both polling and the t-reassembly timer. While the described process can reduce network overhead (and / or the total number of retransmissions), the reliance on status reports introduces additional latency when lower layers of the protocol stack ultimately fail to transmit the SDU correctly. For some applications requiring both high reliability and low latency (e.g., XR), this additional latency is unacceptable.

[0110] Furthermore, delaying the retransmission of an SDU can negatively impact broader transmission window management. A transmission window is defined between a lower bound and an upper bound of the SDU sequence number. In this way, the transmission window defines the SDUs eligible for transmission. The transmission window is updated by incrementing both the lower and upper bounds. Therefore, the transmission window is only updated when the reception status of the lower bound SDU is acknowledged; otherwise, it remains unchanged even if the upper layer (e.g., PDCP) provides new SDUs for transmission. For example, transmission of the second PDU set may stall because the reception status of an SDU in the first PDU set is not acknowledged and the SDU sequence number of the second PDU set is outside the transmission window. This phenomenon is also known as transmission window stalling. References will now be made to... Figure 5 Describe the problem in more detail.

[0111] Figure 5 This is a flowchart illustrating an example of sequence exchange between RLC transmitter 501 and RLC receiver 502. This example illustrates a status reporting mechanism implemented during RLC AM. The example shows the transmission sequence of SDUs with sequence numbers from 1 to 5 by RLC transmitter 501 and the corresponding status reports sent by RLC receiver 502.

[0112] During the first transmission 503, RLC SDU 1 is sent by RLC transmitter 501 and correctly received by RLC receiver 502. During this phase, RLC receiver 502 does not send a status report because there is no valid trigger for a status report. There are two triggers for RLC receiver 502 to send a status report: a missing SDU detection performed by RLC receiver 502, and a detection of the polling bit inserted into the header of the transmitted data packet (e.g., the polling bit has been inserted by RLC transmitter 501).

[0113] Considering the second transmission 504, RLC SDU 2 is sent by RLC transmitter 501 with the polling bit set in the header. RLC SDU 2 is also correctly received by RLC receiver 502. Due to the presence of the polling bit, RLC receiver 502 sends a status report 505 back to RLC transmitter 501. The status report contains a positive acknowledgment (ACK) for RLC SDU 3, indicating that RLC SDU 3 is the expected next SDU at RLC receiver 502. RLC transmitter 501 interprets the status report as meaning that all SDUs with sequence numbers below 3 have been correctly received by RLC receiver 502. RLC transmitter 501 then updates its transmission window, taking into account that RLC SDU 1 and RLC SDU 2 have been correctly received.

[0114] In a subsequent (i.e., third) transmission 506, SDU 3 was sent by RLC transmitter 501 but not received by RLC receiver 502. Nothing happened at RLC receiver 502. However, the RLC receiver still expected SDU 3 as the next SDU to be received.

[0115] The next (i.e., the fourth) transmission 507 involves SDU 4 being sent by RLC transmitter 501 and correctly received at RLC receiver 502. Upon receiving SDU 4, RLC receiver 502 detects a missing SDU 3 due to a sequence number gap (e.g., SDU 3 has an unknown state). At this point, SDU 3 is not considered lost. However, 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 a low-level retransmission to resolve the issue. If SDU 3 is not received after the t-reassembly timer has elapsed (or the t-reassembly timer has expired), RLC receiver 502 will consider SDU 3 lost (e.g., the state of SDU 3 is no longer unknown at this point because RLC receiver 502 has determined that previous transmissions of SDU 3 will not be received). Therefore, no state report is triggered at RLC receiver 502 upon receiving SDU 4 (i.e., during transmission 507).

[0116] Subsequent transmission 509 involves RLC transmitter 501 sending SDU 5 with polling bits, which is correctly received by RLC receiver 502. At this time, the t-reassembly timer is still running, and RLC receiver 502 still expects SDU 3 as the next SDU to be received. In response to the polling bits, RLC receiver 502 sends a status report 510 back to RLC transmitter 501. The status report contains a positive acknowledgment (ACK) for RLC SDU 3, meaning that RLC SDU 3 is the next SDU expected at the RLC receiver. RLC transmitter 501 interprets the status report as meaning that RLC SDU 3 is missing but not lost (e.g., SDU 3 has an unknown state), the state of SDU 4 is unknown, and the state of SDU 5 may have been correctly received because the status report was sent as a result of the polling bits included with SDU 5. Using this information, RLC transmitter 501 cannot update the transmission window because RLC receiver 502 has not yet correctly received SDU 3.

[0117] Another transmission 511 coincides with the expiration of the t-reassembly timer at RLC receiver 502. At this point, RLC receiver 502 considers SDU 3 to be lost. RLC receiver 502 then restarts the t-reassembly timer and sends a status report to RLC transmitter 501. The status report contains both a negative acknowledgment (Nack) for SDU 3 and a positive acknowledgment (Ack) for SDU 6. RLC transmitter 501 interprets the status report as meaning that SDU 3 is lost and should be retransmitted. Furthermore, the RLC transmitter interprets that RLC receiver 502 has correctly received all SDUs below 6 and above 3. Therefore, the reception status of SDU 4 and SDU 5 is confirmed as good (i.e., their status is known), while SDU 3 should be retransmitted, and therefore the transmission window cannot be updated.

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

[0119] During transmission 513, the t-reassembly timer expired at RLC receiver 502, meaning that the retransmission of SDU 3 had failed. At RLC transmitter 501, no changes occurred between transmissions 512 and 513; no new data was received from upper layers of the protocol stack (e.g., the PDCP layer) for transmission, and the state of SDU 3 remained unknown. During transmission 513, RLC receiver 502 assumed the first retransmission of SDU 3 was lost. RLC receiver 502 should then restart the t-reassembly timer and send a status report to RLC transmitter 501. The status report contains both a negative acknowledgment (Nack) for SDU 3 and a positive acknowledgment (Ack) for SDU 6. RLC transmitter 501 interprets the status report as meaning the first retransmission of SDU 3 was lost and should be retransmitted once. Additionally, RLC receiver 501 interprets this as RLC receiver 502 correctly receiving all SDUs below 6 and above 3. Therefore, SDU 3 should be retransmitted and the transmission window still cannot be updated.

[0120] The retransmission sequence 511, 512, and 513 should be repeated until successful reception of SDU 3 is confirmed, or the maximum retransmission count threshold for a single SDU (in this case, SDU 3) is reached. Only confirmation of correct reception of SDU 3 will allow the RLC transmitter 501 to update its transmission window. Reaching the maximum retransmission count threshold triggers a radio link failure (RLF) procedure, thus ending the entire communication process.

[0121] As described above, on the RLC transmitter 501 side, the decision to retransmit an SDU is delayed by both polling and the t-reassembly timer, leading to unacceptable interruptions for applications requiring both high reliability and low latency (such as XR). Furthermore, delaying the retransmission of an SDU can negatively impact broader transmission window management. The transmission window is defined between a lower bound and an upper bound of the SDU sequence number. In this way, the transmission window defines the SDUs eligible for transmission. The transmission window is updated by incrementing both the lower and upper bounds. Therefore, the transmission window is only updated when the reception status of the lower bound SDU is acknowledged; otherwise, it remains unchanged even if the upper layer (e.g., PDCP) provides new SDUs for transmission. For example, transmission of the second PDU set may stall because the reception status of an SDU in the first PDU set is not acknowledged and the SDU sequence number of the second PDU set is outside the transmission window. This phenomenon is also known as transmission window stalling.

[0122] about Figure 5In the example shown, if SDU 3 through SDU 5 are associated with the first PDU set (i.e., PDU set 1) and therefore the second PDU set (i.e., PDU set 2) begins at SDU 6, and if a transmission window is then defined between sequence numbers 3 and 5, the second PDU set will stall, waiting for a good reception of SDU 3.

[0123] Several parameters can be tuned to improve status reporting responsiveness. For example, the maximum polling frequency can be configured to transmit polling bits every four packets or even every two packets. However, adjusting the polling frequency cannot match PDU set boundaries, as PDU set boundaries are variable. Alternatively, the t-reassembly timer can be set to 0, meaning the RLC receiver responds immediately upon detecting a sequence number gap. However, decreasing the t-reassembly timer increases the number of false missing detections, which significantly increases unnecessary overhead in the network.

[0124] Figure 6 This is a schematic diagram illustrating a method for managing data transmission between an RLC transmitter and an RLC receiver according to a first embodiment of the present disclosure. Reference will also be made to... Figure 9a and Figure 9b The flowchart shown illustrates the method.

[0125] consider Figure 6 Two PDU sets 601 and 602 are shown as available for transmission during time period 603 when the RLC transmitter will send SDU 3, SDU 4, SDU 5, SDU 6 and SDU 7.

[0126] When SDU 8 (as shown by reference numeral 604 in the attached figure) is selected for the next transmission opportunity (e.g., Figure 9b In method step 900, the RLC transmitter checks whether there are other SDUs ready to be transmitted after SDU 8 (e.g., method step 901). In this example, as illustrated by empty transmission opportunity 605, SDUs 9 through 11 (as shown by reference numeral 606) are not ready for transmission (e.g., because SDUs 9 through 11 are outside the transmission window or have not yet been provided by the DPCP layer). In this case, the RLC transmitter will check (e.g., method step 902) whether some of the previous SDUs (as shown by reference numeral 603) have an unknown reception status (e.g., missing or pending, but not lost). Then, one of these SDUs is selected for the anticipated retransmission (e.g., method step 904).

[0127] Considering method step 902 alone, this disclosure (such as...) Figure 9a(As illustrated) provides a means to retransmit a PDU with an unknown state before receiving a notification (e.g., a negative acknowledgment) from the receiver indicating that the state of the PDU has been lost.

[0128] In this example, SDU 3 has been retransmitted twice, but the status of the second retransmission is unknown. Therefore, SDU 3 is selected as having an unknown (or pending) reception status and the smallest sequence number among SDUs with an unknown reception status. Thus, SDU 3 is selected for retransmission before it is confirmed whether SDU 3 has been lost. SDU 8 is then transmitted as scheduled (e.g., method step 905), and SDU 3 is sent at the next transmission opportunity (e.g., 605, 906, 907). This results in timeline 607, where SDU 3 is positioned between SDU 8 and SDU 9 in the SDU sequence.

[0129] Compared to an arrangement where the t-reassembly timer is set to 0, Figure 9a and Figure 9b The method advantageously restricts the anticipated retransmission of SDUs to situations where there is available time to perform the retransmission, and only to a subset of SDUs associated with a given set of PDUs. Therefore, this method achieves better responsiveness with reduced overhead.

[0130] Figure 7 This is a schematic diagram illustrating a method for managing data transmission between an RLC transmitter and an RLC receiver according to a second embodiment of the present disclosure. Reference will also be made to... Figure 10 and Figure 11 The flowchart shown illustrates the method.

[0131] consider Figure 7 Two PDU sets 701 and 702 will become available for transmission during time period 703, during which the RLC transmitter is configured to transmit SDU 3, SDU 4, SDU 5, SDU 6 and SDU 7.

[0132] When selecting SDU 8 (as identified by reference numeral 704 in the attached figure) for the next transmission opportunity (e.g., Figure 10 In method step 1000, the RLC transmitter checks whether SDU 8 is the last SDU in the PDU set (e.g., method step 1001). In this example, SDU 8 is the last SDU in PDU set one (e.g., reference numeral 700), and SDUs 9 through 11 (e.g., reference numeral 706) are part of PDU set two (e.g., reference numeral 701). Also in this example, SDUs 9 through 11 are ready to be transmitted (i.e., they are all provided by the PDCP layer and included in the transmission window).

[0133] Compared to an arrangement where the t-reassembly timer is set to 0, Figure 10 The method advantageously restricts the expected SDU retransmission to the boundary of the PDU set, and only to a subset of SDUs associated with a given PDU set. Therefore, this method achieves better responsiveness with reduced overhead.

[0134] exist Figure 11 In the implementation, a further check is performed at method step 1102 to ensure the second PDU set (e.g., Figure 7 The SDUs (reference numeral 701) are less important than the first set of PDUs (e.g., reference numeral 700). In this case, the RLC transmitter will check whether some of the previous SDUs (e.g., reference numeral 703) have an unknown or pending reception status (i.e., missing rather than lost). The RLC transmitter then selects one of these SDUs for the anticipated retransmission (e.g., method step 1104). By anticipating the retransmission of SDUs with unknown status, the method thereby reduces the likelihood of delaying the arrival of the high-importance PDU set at its intended destination.

[0135] In this example, similar to Figure 6 For example, SDU 3 has been retransmitted twice, but the status of the second retransmission is unknown. Therefore, SDU 3 is selected as having an unknown (or pending) reception status and the smallest sequence number among SDUs with an unknown reception status. Thus, SDU 8 is sent as scheduled (e.g., method step 1005), and SDU 3 is sent on the next transmission opportunity (e.g., 1005, 1006, 1007), thereby delaying SDU 9 through SDU 11 by one transmission opportunity, resulting in timeline 707.

[0136] In the alternative configuration, all SDUs with unknown or pending reception status in the first PDU set 700 will be considered for anticipated retransmissions, which further delays the SDUs in the next PDU set.

[0137] Figure 8 This is a schematic diagram illustrating a method for managing data transmission between an RLC transmitter and an RLC receiver according to a third embodiment of the present disclosure. Reference will also be made to... Figure 12 The flowchart shown illustrates the method.

[0138] consider Figure 8 Two PDU sets, 801 and 802, will become available for transmission during time period 803, during which the RLC transmitter can be configured to transmit SDU 3, SDU 4, and SDU 5. When SDU 6 (e.g., 804) is selected for the next transmission opportunity (e.g., ...), Figure 12In method step 1200), the RLC transmitter detects the transmission window situation (e.g., method step 1201). In this example, SDU 6 is the last SDU in the transmission window. Also in this example, SDUs 7 through 11 are not ready to be transmitted (e.g., they are provided by the PDCP layer but are not included in the transmission window). In this case, the RLC transmitter will check (e.g., method step 1202) whether some of the previous SDUs (e.g., 803) have an unknown or pending reception status (e.g., missing rather than lost). The RLC transmitter then selects one of these SDUs for the anticipated retransmission (e.g., method step 1204).

[0139] In this example, similar to Figure 6 and Figure 7 For example, SDU 3 has been retransmitted twice, but the status of the second retransmission is unknown. Therefore, SDU 3 is selected as having an unknown (or pending) reception status and the smallest sequence number among SDUs with an unknown reception status.

[0140] SDU 6 is sent as planned (e.g., method step 1205), and SDU 3 is sent on the next transmission opportunity (e.g., 1205, 1206, 1207). Advantageously, this does not delay SDU 9 through SDU 11 by a transmission opportunity, since the transmission window would otherwise be stalled. The resulting timeline is illustrated by reference numeral 807, taking into account that the transmission window stall condition is resolved by the successful retransmission of SD3.

[0141] In the alternative configuration, all SDUs with unknown or pending reception status in the first PDU set 800 will be considered for anticipated retransmissions.

[0142] Figure 9a and Figure 9b This is a flowchart illustrating a method according to a second embodiment of the present disclosure implemented by an RLC transmitter 501.

[0143] At method step 900, the RLC transmitter is ready to transmit a new SDU (e.g., the first SDU) and is notified by a lower layer of the protocol stack (e.g., the MAC layer) that a transmission opportunity is available. The new SDU is an SDU with a sequence number following the sequence number of the last transmitted SDU; this new SDU is part of the transmission window and was not transmitted earlier. Next, at method step 901, the RLC transmitter checks whether any other SDU is ready to be transmitted, either as a first transmission or as a retransmission. If other SDUs are also ready to be transmitted (i.e., "No" in method step 901), the RLC transmitter proceeds to method step 903 and transmits the first SDU according to the RLC AM rules (e.g., as defined in TS 38.322).

[0144] If the current SDU is the last SDU to be sent before the silent period (i.e., "yes" at method step 901), the RLC transmitter checks during method step 902 whether there is an SDU with an unknown or pending reception status (meaning that the SDU has neither been acknowledged as received nor acknowledged as lost, and is therefore not considered ready for retransmission).

[0145] If there is no SDU with an unknown or pending reception status (i.e., "No" at method step 902), the RLC transmitter proceeds to method step 903 and transmits the first SDU according to the RLC AM rules (e.g., as defined in TS 38.322).

[0146] If an SDU with a pending reception state is found (e.g., "Yes" at method step 902), then during step 904, the RLC transmitter selects at least one of these SDUs (e.g., a second SDU) for the anticipated retransmission. Selecting a second SDU for the anticipated retransmission means changing the state of the second SDU from unknown (or missing rather than lost) to lost, and placing the second SDU in the retransmission buffer. The selection of a second SDU from SDUs with unknown or pending reception states is based on a configuration that includes the following three options:

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

[0148] In the second option, during method step 904, the selected SDU is the SDU with the smallest sequence number among SDUs with unknown or pending reception status and is included in the set of PDUs with the smallest remaining time.

[0149] In the third option, during method step 904, the selected SDU is the SDU with the smallest sequence number among SDUs with unknown or pending reception status, and is included in the set of the most important PDUs with the smallest remaining time.

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

[0151] With regard to the identification, selection, and / or retransmission of a “second SDU” in the above methods (e.g., including any of method steps 900 to 907), it will be understood that the term “second” can be considered as any characteristic. For example, the same method steps can be applied to identify a “first SDU” for retransmission.

[0152] Figure 10 This is a flowchart of a method according to a second embodiment of the present disclosure, implemented by an RLC transmitter 501. (Except for...) Figure 10 Method step 1001 (which differs from...) Figure 9b Apart from step 901 in the method, Figure 9b and Figure 10 The method steps are the same. For the sake of brevity, only the different method step 1001 will be described in detail. During method step 1001, the RLC transmitter checks whether the first SDU is the last SDU in the PDU set, regardless of the availability of other SDUs to be transmitted after the first SDU (and...). Figure 9b (This is in contrast to the requirements of method step 901). In this way, Figure 10 The method in this paper can systematically schedule the expected retransmissions at the end of each PDU set.

[0153] Figure 11 This is another flowchart of a method according to a second embodiment of the present disclosure, implemented by an RLC transmitter 501. Besides... Figure 11 Additional method step 1102 (which does not exist in) Figure 10 In addition to (China), Figure 10 and Figure 11The method steps are the same. For brevity, only the different method step 1002 will be described in detail. During method step 1102, the RLC transmitter checks whether the next SDU available for transmission after the first SDU is part of a more important set of PDUs. If the next available SDU is part of a more important set of PDUs, the RLC transmitter proceeds to method step 1103. If the next available SDU is part of a less important set of PDUs, or if there is no next SDU ready for transmission, the RLC transmitter proceeds to method step 1104. Therefore, Figure 11 The method shown can prevent scheduled retransmissions from being made at the expense of a more important set of PDUs.

[0154] The importance of a PDU set can be determined by at least one of the following: PDU set importance (PSI) parameter, associated delay budget, and associated remaining time in the delay budget. For example, a combination of all three criteria is feasible.

[0155] Figure 12 This is a flowchart of a method according to a third embodiment of the present disclosure, implemented by an RLC transmitter 501. Except for method step 1201, which differs from the corresponding method step 901, Figure 9b and Figure 12 The method steps shown are essentially similar. For brevity, only method step 1201 will be described in detail. During method step 1201, the RLC transmitter checks for a transmission window stall condition. If a transmission window stall condition is detected, the RLC transmitter proceeds to method step 1202; otherwise, the RLC transmitter proceeds to method step 1203. Advantageously, Figure 12 The method shown can anticipate retransmissions of SDUs that are blocking the transmission window. Transmission window stall conditions are detected by a combination of one of the following criteria:

[0156] A. The first SDU is the last SDU in the transmission window, and at least one other SDU is ready to be transmitted;

[0157] B. The first SDU is the nth SDU from the end of the transmission window, and at least one other SDU is ready to be sent, where n is a configuration parameter; and

[0158] C. The scheduled transmission window time has not been updated.

[0159] Further embodiments relating to this disclosure will now be described.

[0160] As mentioned above, data retransmission needs to be managed during RLC AM operating conditions to improve the operational efficiency of this communication network. Specifically, during RLC AM, PDU retransmissions can experience significant delays. Relying on RLC parameter tuning (such as polling frequency or t-reassembly timers) cannot solve the problem.

[0161] One way to reduce retransmission latency is to anticipate retransmissions of PDUs with unknown states. An unknown state indicates that a PDU has been transmitted to the receiver but has not yet been acknowledged as received or detected as lost. This allows for earlier and more efficient retransmissions of some PDUs, thereby minimizing overhead compared to systematic retransmissions. In this way, a means for anticipating retransmissions of PDUs with unknown states is provided.

[0162] Overhead can be further reduced if anticipated retransmissions of PDUs with unknown states are not systematically triggered. For example, anticipated retransmissions of PDUs with unknown states can occur after the transmission of all PDUs in the PDU set. In other words, network overhead can be reduced by configuring criteria for triggering anticipated retransmissions of PDUs with unknown states.

[0163] Further description of embodiments of this disclosure:

[0164] In the context of managing data in a communication network configured to operate in RLC AM, consider the following points:

[0165] A. How to avoid unnecessary retransmissions via RLC AM. To address this issue, the following options can be considered: receiver (Rx)-initiated schemes and / or transmitter (Tx)-initiated schemes. Tx-initiated schemes may involve configuring the transmitting side of the AM RLC entity to notify the receiving RLC side of outdated SDUs. The Tx side then stops retransmitting outdated SDUs, and the Rx side updates state variables based on information from the Tx side. Rx-initiated schemes may involve configuring (e.g., enhancing) RLCAM in a way that allows the receiver to indicate to the transmitter the SDUs to be abandoned (i.e., to appropriately shift the transmission window forward). The Tx side processes the state report only as in conventional schemes. Further considerations may involve how the Rx side can determine that an SDU should be abandoned.

[0166] B. How to achieve timely retransmission at the RLC layer for XR services. To achieve timely retransmission at the RLC layer for XR services, the following options can be considered: autonomous retransmission based on some triggered PDUs (i.e., without status reports); retransmission based on enhanced status reports; and retransmission based on enhanced polling. Further considerations may involve whether enhancements are needed, or whether the problem can be addressed by appropriately configuring existing mechanisms. Further considerations may include the impact of these options on (e.g., network) capacity and potential enhancements to UL services.

[0167] According to embodiments of this disclosure, the following techniques are presented to ensure timely RLC retransmission:

[0168] A. Autonomous Retransmission: One way to reduce retransmission latency is to anticipate retransmissions of PDUs with unknown states. An unknown state indicates that a PDU has been transmitted to the receiver but has not yet been acknowledged as received or detected as lost. This allows for earlier and more efficient retransmissions of some PDUs, thereby minimizing overhead compared to systematic retransmissions. Proposal 1: Consider autonomous retransmissions of PDUs with unknown states.

[0169] Overhead can be further reduced if the autonomous retransmission of PDUs with unknown states is not systematically triggered. For example, the autonomous retransmission of PDUs with unknown states can occur after the transmission of all PDUs in the PDU set. Proposal 4: Further investigate the criteria for triggering autonomous retransmission of PDUs with unknown states.

[0170] B. Enhanced Status Reporting: Accelerate status reporting transmission (e.g., by the receiver) by introducing new triggers. For example, timer-based triggering. However, while periodic or PDB-based triggering of status reports can improve transmission responsiveness, this is not always sufficient. For instance, if the status report timer has elapsed while the t-reassembly timer is still running, no ACK information will be sent to the transmitter. Observation 4: Increasing the status report frequency is useless when the t-reassembly timer is still running.

[0171] Furthermore, the t-reassembly timer can be reduced (or even set to 0), thus increasing the responsiveness of the RLC receiver once a sequence number gap is detected. However, reducing the t-reassembly timer increases the number of false missing detections, which can then increase overhead across the entire network. Observation 5: Enhanced status reporting consumes additional resources in the downlink.

[0172] Discarding the disable timer ensures timely transmission of status reports. However, because it is independent of the XR application itself, the disable timer is set by the network. Therefore, the disable timer should not be ignored when setting it. Recommendation 5: Do not change the disable timer when it is set by the network. Recommendation 6: Do not enhance status reporting.

[0173] C. Enhanced Polling: The maximum polling frequency can be configured to one polling bit every four packets. However, the polling frequency cannot match PDU set boundaries because PDU set boundaries are variable. For example, one option could involve reducing the t-PollRetransmit timer to below 5ms. Observation 6: Increasing the polling frequency can result in sending a large number of useless status reports.

[0174] Another option is for the transmitter to initiate polling based on remaining time information. However, if the polling bit triggers a status report based on the 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 needed to overcome the delay caused by the t-reassembly timer.

[0175] Further description of embodiments of this disclosure:

[0176] In the context of avoiding unnecessary retransmissions via RLC AM, consider the following: Unnecessary RLC AM retransmissions can be avoided (or reduced) by configuring RLC AM with enhancements to either receiver-initiated (Rx) or transmitter-initiated (Tx) schemes. For Tx-initiated schemes, the transmitting side of the AM RLC entity can notify the receiving RLC side of outdated SDUs. Subsequently, the Tx side stops retransmitting outdated SDUs, and the Rx side updates its state variables based on information from the Tx side. For Rx-initiated schemes (appropriate forward shifting of the transmission window), RLC AM can be enhanced by providing SDUs for the receiver to indicate to the transmitter that they should be abandoned. Therefore, the Tx side only processes state reports as known methods. Such schemes do not consider how the Rx side should determine that an SDU should be abandoned.

[0177] According to embodiments of this disclosure, the following techniques are presented to avoid unnecessary retransmissions using the TX scheme: For TX-initiated schemes, there is a potential risk of desynchronization between the TX window and the RX window. At the transmitting entity, the TX window can be updated once a discard decision is made. In this case, the TX window is updated before the RX window is updated. Furthermore, the RX window is updated based on the discard notification received from the transmitting entity. Therefore, the RX window and the TX window will be out of sync for the time it takes for the discard notification to arrive. In summary, for TX-initiated schemes, the TX window and the RX window may be out of sync for a negligible amount of time. Furthermore, considering the possibility of lost or corrupted discard notification signaling, a Mobile Receive Window (MRW) command (e.g., as defined in Universal Mobile Telecommunications System (UMTS) TS 125 322 V4.0.0 (2001-03)) can be employed (and / or adapted) to provide the relevant discard notification.

[0178] Figure 13 This is a schematic diagram illustrating example signaling between two nodes in a wireless communication network. When a predetermined threshold is reached, for example, when the number of retransmissions (MaxDAT) is reached, or when the transmission time for an SDU in Acknowledgment Mode RLC exceeds a predefined value (Timer_Discard), an SDU can be discarded using explicit signaling. Based on reaching the predetermined threshold, a "Mobile Receive Window" (MRW) command can be sent to the receiver, causing the Acknowledgment Mode Data (AMD) to be updated accordingly (e.g., a PDU carrying the SDU to be discarded by the receiver and / or the receiver window). The method according to embodiments of this disclosure is configured to combine the MRW command with discard notification signaling to limit signaling overhead. In embodiments, the method may include the following steps for a TX-initiated scheme:

[0179] 1. TX uses the PDCP discard timer to discard one or more SDUs;

[0180] 2. Do not update the TX window, but do not send one or more discarded SDUs;

[0181] 3. TX sends a drop notification to RX;

[0182] 4. RX updates the RX window based on the discard notification;

[0183] 5. RX sends a status report confirming the new window boundaries; and

[0184] 6. TX moves the TX window forward based on the status report.

[0185] According to embodiments of this disclosure, the following techniques are presented to avoid unnecessary retransmissions using the RX scheme. Unlike the TX side, the RX side cannot obtain the PDU set at any layer of the protocol stack. This is because PDU set information, including PDU set boundaries and sequence numbers, is not included in the inline communication. Consequently, providing a means for the RX side to determine that an SDU is outdated is therefore difficult. As has been implemented under PDCP, a method to address this problem could involve the receiving entity (e.g., RX) abandoning the SDU based on a timer. The timer can then be started when a sequence number gap is detected. The timer can then be set to a value related to a certain delay budget. However, the timing of sequence number gap detection is unpredictable. In the worst case (e.g., when the last PDU in the PDU set is lost), the sequence number gap will only be detected upon successful transmission of a PDU in another (e.g., subsequent) PDU set. In summary, the timing of sequence number gap detection is unpredictable and can be as large as the PDU set time period. During the additional time caused by sequence number gap detection, the transmitting entity can continue to retransmit outdated SDUs even after the PDU set delay budget has elapsed. For at least these reasons, the RX-initiated scheme is considered less efficient than the TX-initiated scheme.

[0186] According to embodiments of this disclosure, the following techniques are presented to avoid unnecessary retransmissions using a combined scheme: For the combined scheme, both the transmitting and receiving entities (e.g., Tx and Rx) autonomously discard one or more SDUs based on predefined criteria (e.g., those similar to those used in TX-initiated schemes and RX-initiated schemes (e.g., timers)). Ultimately, the Tx and Rx sides will each discard the same SDUs, thus eliminating the need for discarded signaling or window signaling. However, due to the difference between the RX-side timer and the TX-side timer, the TX window and RX window will not be fully synchronized. Therefore, there may be concerns related to the time spent by the receiving side detecting sequence number gaps before initializing the timer.

[0187] Table 1 below summarizes the relative advantages and disadvantages of TX-initiated schemes, RX-initiated schemes, and combined schemes.

[0188] Table 1: Comparison of Discarding Schemes

[0189]

[0190] The efficiency of the RX-initiated scheme is described as "poor" in the table above because the time spent detecting missing transmissions (e.g., sequence number gaps) is wasted. Therefore, some unnecessary transmissions cannot be avoided. The efficiency of the combined scheme is described as "no signaling but / poor" in the table because TX and RX will not be dropped simultaneously. Therefore, window synchronization is affected by the time spent detecting missing transmissions (e.g., sequence number gaps).

[0191] In this embodiment, the method of the scheme initiated by TX is used together with window synchronization signaling because this provides a favorable balance between signaling, efficiency and window synchronization requirements.

[0192] Further description of embodiments of this disclosure:

[0193] 2.1. Avoid unnecessary retransmissions

[0194] 2.1.1. TX Scheme:

[0195] For the TX scheme, the risk of desynchronization between the TX and RX windows has been discussed. At the transmitting entity, the TX window can be updated once a discard decision is made. In this case, the TX window is updated before the RX window. The RX window is updated based on the discard notification received from the transmitting entity. The RX and TX windows will be out of sync for the time until the discard notification arrives. Observation: For TX-initiated schemes, the TX and RX windows may be out of sync for a negligible amount of time. Furthermore, in the event of lost or corrupted discard notification signaling, the Mobile Receive Window (MRW) command, as defined in UMTS TS 125 322 V4.0.0 (2001-03), can be used: when the MaxDAT retransmission count is reached, or when the SDU transmission time in acknowledgment mode RLC exceeds a predefined value (Timer_Discard), the SDU can be discarded using explicit signaling. A Mobile Receive Window (MRW) command is sent to the receiver, causing the AMD PDU carrying the SDU to be discarded in the receiver, and the receiver window is updated accordingly (see [link to relevant documentation]). Figure 13 To limit signaling overhead, it is proposed to merge the MRW command with the drop notification signaling. Proposal: For TX-initiated schemes, the following steps are adopted:

[0196] 1. TX uses a PDCP discard timer to discard SDUs;

[0197] 2. Do not update the TX window, but do not send discarded SDUs;

[0198] 3. TX sends a drop notification to RX;

[0199] 4. RX updates the RX window based on the discard notification;

[0200] 5. RX sends a status report confirming the new window boundary;

[0201] 6. TX moves the TX window forward based on the status report.

[0202] 2.1.2 RX Scheme: Unlike the TX side, the RX side cannot obtain the PDU set at any layer. This is because the PDU set information, including the PDU set boundaries and sequence numbers, is not inlined. Therefore, how the RX side determines that an SDU is outdated is a problem. It has been agreed that the receiving entity will discard SDUs based on a timer, as has been done by PDCP. The timer will then most likely start during sequence number gap detection and will be set to a value related to a certain delay budget. However, the timing of sequence number gap detection is unpredictable; in the worst case, the sequence number gap will only be detected when the last PDU in the PDU set is lost, upon successful transmission of a PDU in another PDU set. Observation: The timing of sequence number gap detection is unpredictable and can be as long as the PDU set time period. During the additional time caused by sequence number gap detection, the transmitting entity continues to retransmit useless SDUs even after the PDU set delay budget has elapsed. Observation: The RX-initiated scheme is less efficient than the TX-initiated scheme.

[0203] 2.1.3 Combined Scheme: In the combined scheme, both the transmitting and receiving entities autonomously discard SDUs based on similar criteria (timers). Ultimately, both sides will discard the same SDUs, thus eliminating the need for discard signaling or window signaling. However, due to the difference between the RX-side timer and the TX-side timer, the TX window and RX window will not be perfectly synchronized. A more concerning issue is the time spent by the receiving side detecting sequence number gaps before initializing the timer.

[0204]

[0205] ( Detecting missing data is a waste of time => it cannot prevent some unnecessary transmissions. TX and RX will not be discarded simultaneously (missing time detected). Proposal: Use a TX-side scheme with window synchronization signaling.

[0206] Further description of embodiments of this disclosure:

[0207] In the context of how to avoid unnecessary and / or untimely retransmissions via RLC AM, consider the following points:

[0208] One way to reduce retransmission latency is to anticipate retransmissions of PDUs with unknown states. An unknown state indicates that a PDU has been transmitted to the receiver but has not yet been acknowledged as received or detected as lost. This allows for earlier and more efficient retransmissions of some PDUs, thereby minimizing network overhead compared to systematic retransmissions. Overhead can be further reduced if autonomous retransmissions of PDUs with unknown states are not triggered systematically. Autonomous retransmissions of PDUs with unknown states can occur after the first transmission of all SDUs in the PDU set. Alternatively (or additionally), autonomous retransmissions of PDUs with unknown states can occur when both the transmit and retransmission buffers are empty.

[0209] To further reduce the required network resources, discretionary retransmission triggering can be extended to a remaining time threshold applied to the transmission window. If the transmission window is stalled until the remaining time threshold of the PDU set is reached, discretionary retransmission can be triggered. Careful design of discretionary retransmission triggering can drastically reduce unnecessary SDU retransmissions.

[0210] In terms of packet delay, autonomous retransmission can achieve better performance because the retransmission decision does not depend on previous signaling exchanges with the receiver. If the conditions used for polling bit triggering are not enhanced, the delay reduction gain can be significantly more favorable to autonomous retransmission. In this way, autonomous retransmission can achieve better retransmission delay.

[0211] In terms of capacity cost, autonomous transmission may trigger some unnecessary SDU retransmissions, while enhanced polling may generate unnecessary signaling exchanges. The differences are not immediately apparent in quantification because there are many factors to consider, such as the design of autonomous retransmission triggers, the size of the SDU, or the frequency of polling. Therefore, the capacity impact of autonomous retransmissions can be managed by carefully designing the triggering conditions.

[0212] In terms of complexity, autonomous retransmission only affects the TX side, while polling requires enhancements on the TX side for triggering and on the RX side for timer management. In this way, autonomous retransmission can be less complex than polling. Autonomous retransmission is advantageous for PDUs with unknown states.

[0213] While this disclosure has been described with reference to examples and embodiments, it should be understood that this disclosure is not limited to the disclosed examples and embodiments. Those skilled in the art will understand that various changes and modifications can be made without departing from the scope of this disclosure as defined in the appended claims.

[0214] All features disclosed in this specification (including any appended claims, abstract, and drawings) and / or all steps of any method or process so disclosed may be combined in any combination other than at least some mutually exclusive combinations of such features and / or steps. Unless otherwise expressly stated, each feature disclosed in this specification (including any appended claims, abstract, and drawings) may be replaced by an alternative feature serving the same, equivalent, or similar purpose. Therefore, unless otherwise expressly stated, the disclosed features are merely one example of equivalent or similar features in a general series.

[0215] Unless otherwise defined herein, scientific and technical terms used in connection with the inventive concept of this disclosure should have the meanings commonly understood by one of ordinary skill in the art, and known techniques and processes can be carried out according to conventional methods known in the art and described in various general and more specific references that may be cited and discussed in this specification.

[0216] As used in this specification and (one or more) claims, 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,” etc.) are inclusive or open-ended and do not exclude additional unlisted elements or method steps. The use of the term “a” or “an” in the claims and / or specification can mean “a” as well as “one or more,” “at least one,” and “more than one.” Therefore, unless the context explicitly indicates otherwise, the terms “a,” “an,” and “the,” and all singular terms, include the plural referent. Similarly, unless the context requires otherwise, plural terms should include the singular. Unless explicitly indicated to refer only to alternatives or unless these alternatives are mutually exclusive, the term “or” is used in this disclosure (including the claims) to mean inclusive “and / or.”

[0217] Unless otherwise expressly stated as incompatible, or if the physical or other aspects of the embodiments, examples, or claims prevent such combination, the features of the examples and claims disclosed herein may be integrated in any suitable arrangement (especially one in which beneficial effects exist). This is not limited to any specified benefit, but may derive from "after-the-fact" benefits. That is, the combination of features is not limited to the forms described, and in particular not to the forms (e.g., numbering) of (one or more) examples, (one or more) embodiments, or (one or more) the dependencies of the claims.

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

[0219] Computer-readable media may include: computer-readable storage media, which correspond to tangible media such as data storage media; or communication media, which include any medium that facilitates, for example, the transfer of a computer program from one place to another according to a communication protocol. In this way, a computer-readable medium may correspond to (1) a non-transitory tangible computer-readable storage medium or (2) a communication medium such as a signal or carrier wave. Data storage media may be any available medium that can be accessed by one or more computers or one or more processors to retrieve instructions, code, and / or data structures to implement the techniques described in this disclosure. Computer program products may include computer-readable media.

[0220] By way of example and not limitation, such computer-readable storage media may include RAM, ROM, EEPROM, CD-ROM or other optical disc storage units, disk storage units, 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 is accessible by a computer. Furthermore, any connection is appropriately referred to as a computer-readable medium. For example, coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technologies such as infrared, radio, and microwave can be included in the definition of medium if instructions are transmitted from a website, server, or other remote source using coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technologies such as infrared, radio, and microwave. However, it should be understood that computer-readable storage media and data storage media do not include connections, carrier waves, signals, or other transient media, but rather refer to non-transient tangible storage media. As used herein, disks (and discs) include compact discs (CDs), laser discs, optical discs, digital versatile discs (DVDs), floppy disks, and Blu-ray discs, wherein a disk typically magnetically reproduces data, while a disc optically reproduces data using lasers. The above combinations 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 acknowledgment mode, the communication network comprising a transmitter and a receiver, wherein, The method includes, at the transmitter: Before receiving a notification from the receiver indicating the status of the PDU, the PDU with an unknown status is retransmitted.

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

3. The method according to claim 1 or 2, wherein, The retransmission of the PDU is initiated when the remaining transmission time of the PDU drops below a threshold.

4. The method according to any one of claims 1 to 3, wherein, The unknown state corresponds to the PDU being transmitted to the receiver, but not yet being confirmed as received by the receiver.

5. The method according to any one of claims 1 to 3, wherein, The unknown state corresponds to the PDU being transmitted to the receiver, but not yet confirmed as not being 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 of a polling bit to the receiver.

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

8. The method according to any one of the preceding claims, wherein, The notification corresponds to a negative acknowledgment that the PDU has not yet 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, the receiver receives other notifications indicating the status of the PDU, wherein the prior notification corresponds to a positive confirmation that at least one PDU has 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, followed by a second PDU set which includes PDUs that are different from those in the first PDU set. The retransmission of a PDU with an unknown state occurs after the transmission of the first PDU set and before the transmission of the second PDU set.

11. The method according to claim 10, wherein, If the second PDU set has a lower priority than the first PDU set, a retransmission of a PDU with an unknown state occurs.

12. The method according to claim 10 or 11, wherein, Retransmission of PDUs with unknown states occurs during transmission opportunities arranged between the first set of PDUs and the second set of PDUs.

13. The method according to any one of claims 10 to 12, wherein, Retransmission of PDUs with unknown states occurs based on indications of the availability of transmission opportunities from lower layers of the protocol stack.

14. The method according to any one of claims 10 to 13, wherein, PDUs with unknown states are selected for retransmission based on the sequence number of the PDUs associated with the first set of PDUs.

15. The method according to claim 14, wherein, The PDUs that are retransmitted are selected for retransmission based on the remaining transmission time of the first set of PDUs.

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

17. The method according to any one of claims 10 to 13, wherein, The PDU with an unknown state is the nth PDU from the end of the transmission window, and at least one other PDU in the PDU set is ready to be transmitted.

18. The method according to any one of claims 10 to 13, wherein, The transmission window has been scheduled for a certain amount of time but has not been updated.

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

20. The method according to any one of the preceding claims, wherein, The notification is generated based on the repeated detection that the receiver has received a PDU.

21. The method according to any one of the preceding claims, wherein, The notification is generated when the timer set by the receiver expires.

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

23. A computer program comprising instructions that, when executed by a transmitter, cause the transmitter to perform the method according to any one of claims 1 to 21.

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

Images