GB2640355A - Method for managing data transmission in a communication network - Google Patents

Abstract

A method for managing data transmission in a communication network operating in a radio link control (RLC) acknowledge mode (RLC AM), the network comprising a transmitter and a receiver, the method at the transmitter comprising: stopping retransmission of a protocol data unit, PDU, to the receiver in dependence on a number of retransmissions of the PDU exceeding a predetermined discard threshold value, wherein the predetermined discard threshold value is less than a threshold value associated with a radio link failure (RLF) of the network. The retransmission of the PDU may be stopped if a discard timer associated with the PDU exceeds a discard timer threshold value. The PDU may be associated with a PDU Set, and the discard timer is started when a first PDU of the PDU Set is received by the transmitter. The method may comprise, upon determining that retransmission of the PDU is stopped, transmitting a discard notification to the receiver. The method may comprise, upon determining that retransmission of the PDU is stopped, transmitting a PDU of a subsequent PDU Set.

Description

METHOD FOR MANAGING DATA TRANSMISSION IN A COMMUNICATION NETWORK

TECHNICAL FIELD

The present disclosure relates to a method for managing data in a communication network (e.g., a mobile telecommunication network comprising a transmitter and a receiver). More particularly, the method is directed towards managing data in a communication network configured to operate in a radio link control acknowledge mode (RLC AM).

BACKGROUND

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

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

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

Many XR applications involve interactions between a wearable device (e.g., a 3D helmet or augmented reality glasses) and an application server. The wearable device and the application server can be connected through a local Network (e.g., a wireless LAN) or cellular network (e.g., 3GPP 5G cellular network, the application server being connected to a 5G core network component of the network).

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

Some XR applications, such as virtual reality, involve transferring compressed video data, audio data and various information from the server to the wearable device.

Some XR applications, such as augmented reality, involve transferring compressed video data, audio data and various information exchanged to and from the wearable device and the server.

In the present disclosure, the information exchanged to and from the UE (e.g., wearable device) and the server is referred to as application data, which may comprise one or more images, video data, audio data, position information etc. The video and audio data are transferred between the UE (e.g., wearable device) and the server using media transport protocols such as RTP (Real Time Protocol, RFC 3550), SRTP (Secured RTP, RFC 3711), HTTP (Hyper Text Transfer Protocol, RFC 2616-7540) or QUIC (RFC 8999, 9000, 9001 and 9002).

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

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

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

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

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

According to the 3GPP standard, in document S2-2302696, a PDU Set QoS parameter called PDU Set Delay Budget (PSDB) is defined. The PSDB defines a time budget allocated to the transport of the PDU Set across the 5G network. This QoS parameter, defined by the application, is used by a 5G network to assess if a PDU Set (e.g., application data packet) is delivered on time. In the same 3GPP document, S2-2302696, another QoS parameter named PDU Set Integrated Handling Indication (PSIHI) is defined to characterize the decoder's tolerance to the loss of data, or receiving outdated (e.g., delayed) data. If the PSIHI parameter is set to "true", then the decoder can only handle (e.g., manage or process) a complete application data packet which is received on time. If the PSIHI parameter is set to "false", then the decoder can tolerate both incomplete and delayed application data packets.

Considering the situation at a particular component of the 5G network, when a PDU Set is sent over the air interface, some information is available regarding the reception status of the PDUs and the elapsed time of the PSDB. For example, when a PDU Set is transferred over the air a Radio Access Network (RAN) node (e.g., a UE or a next gen node (gNB)) can detect that a PDU transmission has failed despite all the retransmissions and error correction mechanisms. In that case, if the PSIHI parameter is set to "true", then the entire PDU Set is useless to the application.

In that case, if one or more PDUs of this "useless" PDU Set are pending transmission over the air interface then the RAN node can consider discarding the remaining transmission of the "useless" PDUs, thus achieving radio network resource saving.

The PDU Sets are mapped on QoS flows (SOAP layer), QoS flows are mapped on DRBs (PDCP layer), DRBs are mapped on RLC channels (RLC layer), RLC channels are mapped on logical channels (MAC layer). The MAC layer implements a reliability mechanism called hybrid automatic repeat request (ARQ), which provides a given level of reliability that can be improved by the RLC layer if needed. The RLC layer can be operated in an acknowledge mode, which implements an additional ARQ mechanism that further enhances the reliability of the transmission.

The RLC AM ARQ mechanism is based on perpetual retransmission of RLC service data units (SOU), which may contain PDUs of a PDU Set. A radio link failure condition (RLF) occurs if the retransmission is stopped (e.g., if the number of retransmissions exceed a threshold value). This can lead to the current session being reset, at which point the UE may be handed over to another base station. Consequently, any retransmissions that occur after the PSDB and before the RLF threshold are unproductive, since they will likely be discarded (e.g., even if successfully received by the UE) and yet they occupy valuable transmission time that could otherwise be allocated to another session (e.g., transmission of the next PDU Set). Such unproductive retransmissions can delay the subsequent transmission of data. Accordingly, there is a need to manage the retransmission of data during RLC AM operating conditions in order to minimize the overheads in the communication network.

SUMMARY

According to embodiments of the present disclosure, there is provided a method of abandoning retransmission of a failed protocol data unit, PDU, at a time that precedes the triggering of a radio link failure within the network.

According to a first embodiment there is provided a method for managing data transmission in a communication network operating in a radio link control acknowledge mode (RLC AM), the network comprising a transmitter and a receiver, the method at the transmitter comprising: stopping retransmission of a protocol data unit, PDU, (e.g., at least one PDU) to the receiver in dependence on (e.g., a determination that) a number of retransmissions of the PDU exceeding a predetermined discard threshold value, wherein the predetermined discard threshold value is less than a threshold value associated with a radio link failure of the network.

Advantageously, the present disclosure provides a means of determining whether or not to abandon the retransmission of a failed PDU which pre-empts the triggering of a radio link failure of the network. This reduces the transmission (e.g., retransmission) of redundant PDUs which would otherwise take up valuable network resources. For example, in contrast to known data management methods (e.g., associated with operating a network in an RLC UM operating mode) the described method adds necessary retransmissions which increase the reliability of the network, whilst also decreasing unnecessary transmissions (e.g., associated with known methods of operating a network in a RLC AM mode).

The predetermined discard threshold value defines a conditional criterion upon which the transmitter may determine whether or not to retransmit a failed PDU. In this way, the predetermined discard threshold value may be considered to represent a retransmission (or retransmit) threshold value.

Retransmission of the PDU may be stopped if a discard timer associated with the PDU exceeds a discard timer threshold value.

The PDU may be associated with a PDU Set. The discard timer may be started when a first PDU of the PDU Set is received by the transmitter. The discard timer threshold value may be set by the network (e.g., a base station of the network). The discard timer threshold value may be based on at least one (e.g., either one) of a PDU Set delay budget and a PDU session identity. The method may comprise at least one of the following method steps: counting the number of retransmissions of the PDU; and before each retransmission of the PDU, comparing the number of retransmissions to the predetermined discard threshold value to determine whether to proceed with the retransmission. The method of counting the number of retransmissions may be triggered by receiving a notification indicating that the status of the PDU is unknown. For example, the transmitter may receiver a negative acknowledgement from the receiver indicating that the PDU is lost.

Optionally, upon determining that retransmission of the PDU is stopped, the method may comprise transmitting a discard notification to the receiver.

The method may comprise, upon determining that retransmission of the PDU is stopped, transmitting a further PDU of a PDU Set associated with the PDU.

The method may comprise determining whether to transmit at least one further PDU (e.g., a subsequent PDU) of the PDU Set. Transmission of the further PDU may be stopped if the number of retransmissions of the PDU exceeds the predetermined discard threshold value. Advantageously, this further reduces the transmission of redundant PDUs within the communication network.

In a situation where retransmission of the PDU may be stopped if a discard timer associated with the PDU exceeds a discard timer threshold value, then the transmission of a further PDU may be stopped if the discard timer associated with the PDU exceeds the discard timer threshold value.

The method may comprise, upon determining that retransmission of the PDU is stopped, stopping transmission (e.g., retransmission) of all subsequent PDUs of the PDU Set to which the PDU is associated.

The method may comprise, upon determining that retransmission of the PDU is stopped, transmitting a PDU of a subsequent PDU Set.

The method may comprise one or more of the following method steps: transmitting, to the receiver, one or more protocol data units, PDUs; receiving, from the receiver, a notification for indicating a status of the one or more PDUs; determining, based on the notification, that at least one PDU of the one or more PDUs has an unknown status; and retransmitting the at least one PDU having an unknown status. The unknown status may be associated with a negative acknowledgement (nack) from the receiver.

The method may comprise counting retransmissions of the at least one PDU and comparing the number with the discard threshold value, wherein the same retransmission counter is used to count the number of retransmissions with respect to the predetermined discard threshold value and the radio link failure threshold value.

The PDU may define a first PDU of one or more PDUs which are scheduled to be transmitted to the receiver. A second PDU of the one or more PDUs may be scheduled to be transmitted subsequently to the first PDU. The method may comprise abandoning retransmission of the second PDU if the number of retransmissions exceeds the threshold value for triggering a network failure. The first and second PDU may be associated with the same PDU Set. Alternatively, the first PDU may be associated with a first PDU Set, and the second PDU may be associated with second PDU Set which is scheduled to be transmitted subsequent to the first PDU Set.

According to a second embodiment there is provided a communication network which comprises a transmitter configured to perform the method according to the first embodiment. According to a third embodiment there is provided a computer program comprising instructions which, when the program is executed by a transmitter, causes the transmitter to carry out the method according to the first embodiment. According to a fourth embodiment there is provided a computer-readable medium carrying a computer program according the third embodiment.

Any feature in one embodiment of the disclosure may be applied to other embodiments of the disclosure, in any appropriate combination. In particular, method embodiments may be applied to apparatus/device/unit embodiments, and vice versa.

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

The preceding summary is provided for purposes of summarising some examples to provide a basic understanding of embodiments of the subject matter described herein. Accordingly, the above-described features should not be construed to narrow the scope or spirit of the subject matter described herein in any way. Moreover, the above and/or proceeding examples may be combined in any suitable combination to provide further examples, except where such a combination is clearly impermissible or expressly avoided. Other features, embodiments, and advantages of the subject matter described herein will become apparent from the following text and the accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

Different embodiments of the disclosure will now be described, by way of example only, and with reference to the following drawings in which: Figure 1 is a schematic diagram illustrating a first example wireless communication system in which the present disclosure may be implemented according to one or more embodiments of the disclosure; Figure 2 illustrates a schematic diagram of an example configuration of a user equipment (UE) in which the present disclosure may be implemented according to one or more embodiments

of the disclosure;

Figure 3 illustrates a schematic diagram of an example configuration of a base station in which the present disclosure may be implemented according to one or more embodiments of the disclosure; Figure 4 is a schematic diagram illustrating the data plane protocol stack of a 5G new radio (NR) system as represented in Figure 1; Figure 5 is a flow chart showing an example of sequence exchange between a radio link control (RLC) transmitter and a RLC receiver; Figure 6 is a flow chart showing an example of a sequence exchange between an RLC transmitter and an RLC receiver according to a first embodiment; Figure 7 is a flow chart showing an example of a sequence exchange between an RLC transmitter and an RLC receiver according to a second embodiment; Figure 8a is a flow chart showing a method at the RLC transmitter of a UE according to an arrangement of the present disclosure; Figure 8b is a flow chart showing a method at the RLC transmitter of a UE of a communication network, the method being executed when receiving a negative acknowledgement related to an RLC service data unit (SDU) containing a PDU of a PDU Set; Figure 9 is a flow chart showing a method at the RLC transmitter of a UE, the method being executed when receiving a negative acknowledgement related to an RLC SDU containing a PDU of a PDU Set; Figure 10 is a flow chart showing a method at the RLC transmitter of a UE, the method being executed when a discard timer related to an RLC SDU containing a PDU of a PDU Set elapses; and Figure 11 is a flow chart showing a method at the RLC transmitter of a UE, the method being executed when a discard timer related to a RLC SDU containing a PDU of a PDU Set elapses.

DETAILED DESCRIPTION

Embodiments and embodiments of the present disclosure will now be discussed with reference to the accompanying figures. Further embodiments and embodiments will be apparent to those skilled in the art.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Figure 4 is a block schematic diagram illustrating the data plane protocol stack of a 5G NR systems as represented in Figure 1. The data plane protocol stack is described in detail in 3GPP document TS 23.501. In the downlink direction, an application server 103 connects to the user plane function (UPF) 161 through a data network 160 at the level of PDU layer 402. The PDU layer corresponds to the PDUs carried between the UE and the data network (DN) over the PDU session.

When the PDU session type is IPv4 or IPv6 or IPv4v6, the PDUs correspond to IPv4 packets, IPv6 packets, or both. When the PDU session type is Ethernet, the PUDs correspond to Ethernet frames; etc. At the start of a PDU session (i.e., at a PDU establishment time), the core network provides session QoS parameters to the UPF, gNB and UE. The PDU session QoS parameters includes the XR PDU set QoS parameters (S2-2302696): A. PDU Set delay budget (PSDB); B. PDU Set error rate (PSER); and C. PDU Set integrated handling indication (PSIHI), which is also previously known as a PDU Set integrated indication. In the description relating to Figure 4, unless stated otherwise, a PDU refers to a packet which is handled (e.g., managed or processed) by the PDU layer 402. The other types of PDU are handled by the other layers. Accordingly, the PDUs belonging to one of the other layers (i.e., other than the PDU layer 402) is referred to herein with the prefix corresponding to the respective layer name, e.g., a PDCP PDU, or MAC PDU.

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

PDU Set identification information as described in 3GPP document S2-2303842 is determined by the UPF and sent to the NG-RAN in the GTP-U header. The PDU Set identification Information comprises: A. a PDU Set sequence number; B. an indication of the end PDU of the PDU Set; C. a PDU sequence number within a PDU Set; D. a PDU Set size; and E. a PDU Set importance, which identifies the relative importance of a PDU Set compared to other PDU Sets within a QoS flow. During uplink the application is located on the UE. The UE obtains the PDU session QoS parameter from the core network when the PDU session is established (e.g., PDU session establishment procedure is defined in TS 23.502 clause 4.3.2.). When the PDU(s) generated by the application 403 arrive at UE PDU layer 402, the UE performs an application packet inspection to determine the PDU Set boundaries (similarto the procedure described above regarding the UPF).

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

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

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

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

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

The RLC protocol layer can operate in three modes: A transparent mode (TM) during which data is transmitted with no header or any protocol implementation; an unacknowledged mode (UM) which implements segmentation and duplication detection; and finally, an acknowledged mode (AM) which implements the same functions as the UM mode but with the addition of a retransmission mechanism (e.g., an automatic repeat request (ARQ)).

The RLC AM mode is used when the reliability provided by lower layers of the protocol (e.g., PHY and MAC) needs to be enhanced. The retransmission procedure of RLC AM is parametrised and configured by the gNB. One important parameter is the maximum number of allowed retransmissions for one RLC SDU (e.g., "maxRetxThreshold").

In a situation where an SDU has been transmitted by the transmitter, but not received by the receiver, then the transmitter is configured to retransmit the missing SDU. Several retransmissions of the missing SDU may occur (e.g., at scheduled intervals) until a certain condition is met. For example, the retransmissions may repeat until the transmitter determines that the SDU has been received. The RLC AM is configured to reset the current session and trigger a Radio Link Failure (RLF) when a maximum number of retransmissions of a single SDU is reached. In this way, the maximum number of retransmissions defines a discard threshold value associated with the RLF (i.e., an RLF discard threshold).

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

The problem is that all retransmissions above the PDU Set delay budget and bellow the RLF discard threshold are useless and that the next PDU set transmission is delayed because of these useless transmissions (and/or retransmissions). This problem is described below in more detail with reference to Figure 5.

A first embodiment allowing discarding without triggering an RLF condition is illustrated through the example of Figure 6. Further details of the first embodiment are described in Figures 8a, 8b, and 10.

A second embodiment allowing further discarding of other SDUs is illustrated through the example shown in Figure 7. Further details of the second embodiment are described below with respect to Figures 9 and 11.

Figure 5 is a flow chart showing an example of a sequence exchange between an RLC transmitter 501 and an RLC receiver 502 of a communication network. In this example, two PDU Sets, 503, 504, are submitted by a higher layer of the protocol stack to RLC transmitter 501. The SDUs are associated with sequence numbers 3 to 8 for the first PDU Set and sequence numbers 9 to 11 for the second PDU Set.

Initially, the SDUs 3 to 5 are submitted by the RLC transmitter 501 to the lower layer of the protocol stack. RLC SDU 3, 505, is successfully received by the RLC receiver 502. Then a temporary network failure 506, prevents RLC SDUs 4 and 5 from being received at the RLC receiver 502. The RLC transmitter will keep retransmitting SDUs 4 and 5 each time a negative acknowledgement is received from the RLC receiver 502. The negative acknowledgements which are sent by the RLC receiver 502 are a type of status report, or notification, which indicates the status of the SDUs being transmitted between the transmitter and receiver. For example, the status reports contain information about received SDUs, including negative acknowledgements for SDUs that the RLC receiver 502 has failed to receive. Each time an SDU is retransmitted, the RLC transmitter 501 increments a retransmission counter associated with the retransmitted SDU. In the flow chart shown in Figure 5, the status reports sent by the RLC receiver 502 are not shown for simplification purposes.

The RLC transmitter 501 may continue retransmitting the failed (e.g., missing) SDUs until the RLF discard threshold is exceeded, and in that case a RLF procedure is triggered. The time it takes for the RLF procedure to be triggered may be defined as an RLF failure period (e.g., the time that elapses from the initial 'failed' transmission of an SDU until the point at which the RLF discard threshold is exceeded). In the example shown in Figure 5, the RLC SDU 4 and RLC SDU 5 are correctly received by the RLC receiver 507, 508 before the RLF discard threshold is triggered (i.e., before the number of retransmissions exceeds the RLF discard threshold).

In this example a delay budget 509 associated with the first PDU Set 503 has already elapsed when the SDU 4 and 5 are received correctly by the RLC receiver 502. At this time, the SDUs labelled 6, 7 and 8 may have already been discarded by a higher layer of the protocol stack, as identified by reference numeral 510 in Figure 5. In this example the transmission window of the RLC transmitter 501 ends at SDU 5. For this reason, the SDUs 6 to 8 can be discarded by the higher layer of the protocol stack since it is not allowed to discard an SDU that has been submitted by an RLC transmitter 501 to a lower layer of the protocol stack. This example is typical of the problem caused by known RLC AM specifications. In particular, the SDUs (e.g., SDU 4 and SDU 5, as shown in Figure 5) belonging to a single PDU Set (e.g., the first PDU Set 503) with an elapsed delay budget will be uselessly retransmitted until they are successfully received by the RLC receiver 502 (as shown by reference 511 in Figure 5). This causes unnecessary use of radio resources in the network, which leads to a delay 512 in the transmission of the next PDU Set (e.g., the second PDU Set 504). This is because the SDUs of the second PDU Set 504 are not sent until the successful transmission, or discarding, of all the SDUs of the previous PDU Set 503.

Figure 6 is a flow chart showing an example of a sequence exchange between an RLC transmitter 601 and an RLC receiver 602 according to a first embodiment of the present disclosure. Numerous elements of the sequence exchange shown in Figure 6 are similar to those described above in relation to Figure 5.

In this example, two PDU Sets 603, 604 are submitted by the higher layer of the protocol stack to RLC transmitter 601. The SDUs are associated with sequence numbers 3 to 8 for the first PDU Set and sequence numbers 9 to 11 for the second PDU Set. Initially, the SDUs 3 to 5 are transmitter by the RLC transmitter 601 to the lower layer of the protocol stack. Notably, the third RLC SDU 605 is successfully received by the RLC receiver 602. Then a temporary network failure 606 occurs, which prevents RLC SDUs 4 and 5 from being received at the RLC receiver 602. The RLC transmitter 601 will keep retransmitting SDUs 4 and 5 each time a negative acknowledgement is received from the RLC receiver 602.

In this arrangement, an additional predetermined discard threshold value is defined for each SDU. The additional threshold defines the maximum number of retransmissions allowed for each SDU belonging to a PDU Set.

In a first embodiment (e.g., as shown in Figure 8b), the additional threshold is configured by the network (e.g., the gNB) and its value is related to at least one of the delay budgets of the PDU Set to which the SDU belongs, the PDCP Data Radio Bearer, and the RLC channel.

In a second embodiment (e.g., as shown in Figure 8b), the additional predetermined threshold is defined at the UE by the upper layer of the protocol stack (e.g., PDCP). For example, the predetermined threshold may be based on a PDCP timer value, including the PDCP discard timer and/or the PDCP PSI discard timer. In particular, the PDCP discard timer may be, for example, a discardTimer or a discardTimerForLowlmportance.

For both of the first and second embodiments, it is expected that the additional predetermined threshold value is lower than the RLF threshold value (i.e., which defines the maximum number of retransmissions required to trigger an RLF).

In a third embodiment (e.g., as shown in Figure 10), discarding of a SDU is not decided on the basis on the number of retransmissions but rather based on a timer event. The timer event is either generated by the RLC transmitter or by the PDCP layer of the protocol stack.

According to the first and second embodiments, when the number of retransmissions of the failed SDU exceeds the maximum retransmission value as defined by the additional predetermined threshold value 804, then the RLC transmitter is configured to stop the retransmission of the SDU.

However, the RLC transmitter does not trigger an RLF condition. Instead, the transmitter applies a discard procedure allowing normal operation to proceed with the rest of the SDUs (e.g., starting with SDU 5).

In addition, the retransmission of the failed SDU may be dependent on the satisfaction of a further condition. For example, the retransmission may be dependent on the expiration of a discard timer 1000 (as shown in Figure 10). The discard timer 1000 may be associated with a PDU Set to which the failed SDU belongs. For example, when the timer 1000 elapses (or expires), the RLC transmitter 601 stops the retransmission of the SDU 4 but does not trigger the RLF condition (1001). It shall apply a discard procedure allowing normal operation to proceed with the rest of the SDUs.

According to an embodiment of the present disclosure, the retransmission of the failed SDU may be dependent on both a timer (e.g., the discard timer 1000) and a discard retransmission mechanism (e.g., using the predetermined discard threshold), simultaneously. In such arrangements, if one of the two conditions is true (e.g., either the timer has elapsed, or the number of retransmissions exceeds the predetermined discard threshold) then the SDU retransmission is stopped without triggering a RLF condition.

The RLC transmitter will continue retransmitting non PDU Set related failed SDUs until reaching the RLF threshold, and thereby triggering the RLF procedure if the number of retransmissions exceeds the RLF discard threshold value.

The association of an SDU with a PDU Set is defined by a higher layer of the protocol stack (e.g., the PDCP). For example, in a situation where a PDCP PDU is delivered to the RLC transmitter, the PDCP layer may inform the RLC layer whether the PDCP PDU is part of a PDU Set or not.

In this example, as shown in Figure 6, the number of retransmissions of SDU 4 exceeds the predetermined discard threshold for the number of retransmissions before the network failure is recovered. Hence, SDU 4 is discarded without triggering an RLF, and SDU 5 is retransmitted instead of SDU 4 (see reference 613 in Figure 6). On the other hand, the number of retransmissions of the SDU 5 did not reach the predetermined discard threshold before the recovery from the network failure, and so SDU 5 was eventually successfully received at the RLC receiver 602.

In this example the delay budget associated with the first PDU Set is already elapsed when the SDU 5 is correctly received by the RLC (see reference 607 in Figure 6). Similar to the example arrangement shown in Figure 5, the subsequent SDUs 6, 7 and 8 may have already been discarded by higher layers of the protocol stack. Therefore, the SDUs 6, 7 and 8 are not transmitted. In this example the transmission window of the RLC transmitter ends at SDU 5, which is why SDUs 6 to 8 can be discarded by higher layers (see reference 610 in Figure 6).

Compared to the known network control methods (e.g., as described above with reference to Figure 5), this first embodiment of the present disclosure advantageously prevents unnecessary transmission of SDUs without triggering the RLF condition.

In particular, by providing a predetermined discard threshold, the RLC transmitter is able to discard PDU Set related SDUs well in advance of triggering the RLF condition. For example, the RLC transmitter may be configured to discard failed SDUs based on the PDU Set delay budget associated with the corresponding PDU Set. Hence, the unnecessary transmission of SDUs is reduced (as exemplified by reference 611 in Figure 6), and the additional delay is also reduced (see reference 612 in Figure 6). Furthermore, in contrast to other known data management methods (e.g., relating to the RLC UM operating mode) the arrangement described herein adds necessary retransmissions that increases the reliability of the network, while decreasing unnecessary transmissions caused by known methods of operating a network in RLC AM mode. Figure 7 is a flow chart showing an example of sequence exchange between an RLC transmitter and an RLC receiver according to a second embodiment of the present disclosure.

Numerous elements of the sequence exchange shown in Figure 7 are similar to those described above in relation to Figures 5 and 6.

In this example two PDU Sets 703, 704 are submitted by a higher layer of the protocol stack to RLC transmitter 701. The SDUs are associated with sequence numbers 3 to 8 for the first PDU Set and sequence numbers 9 to 11 for the second PDU Set. Initially, the SDUs 3 to 5 are transmitted by the RLC transmitter 701 to the lower layer of the protocol stack. In particular, the third RLC SDU 705 is successfully received by the RLC receiver 702.

Following a temporary network failure 706, the fourth and fifth SDUs are not received at the RLC receiver 702. The RLC transmitter 701 continues to retransmit SDUs 4 and 5 each time a negative acknowledgement is received from the RLC receiver 702.

Considering Figure 7, a PDU Set delay budget 709 is represented by a timer. According to a first arrangement (e.g., as shown in Figure 11) the timer is started upon reception by the RLC transmitter of the first PDCP PDU of a PDU Set (e.g., the third SDU of the first PDU Set, and the ninth SDU of the second PDU Set, as shown in Figure 7). The timer duration is set to the PDU Set delay budget, which may be configured by the network (e.g., gNB).

In a second arrangement (e.g., as shown in Figure 11), a higher layer of the protocol stack (e.g., the PDCP layer) maintains at least one discard timer associated to each PDCP PDU. When one timer expires (or elapses) for a given PDCP PDU, all PDCP PDUs belonging to the same PDU Set (i.e., as a PDU) are discarded. The discard notification of each PDU is then communicated to the RLC transmitter, which is configured to discard all corresponding RLC SDUs, including the ones currently in the transmit window. The PDCP discard timers are, for example, the discardTimer or the discardTimerForLowlmportance.

In a third arrangement (e.g., as shown in Figure 9), the process of discarding a SDU is not decided based on timers, but rather based on the predetermined discard threshold (e.g., corresponding to the maximum number of allowed retransmissions). The predetermined discard threshold value can either be configured by the network (e.g., the gNB) or by the UE PDCP layer.

In this embodiment, when an RLC SDU is discarded the RLC transmitter stops the retransmission of the SDU but does not trigger an RLF condition. Further, the RLC transmitter applies a discard procedure allowing normal operation to proceed with the remainder of the SDUs being transmitted to the RLC receiver. For example, the RLC transmitterwill continue retransmitting non PDU Set related failed SDUs until the RLF threshold is exceeded, at which point an RLF will be triggered within the network.

The association of an SDU with a PDU Set is defined by a higher layer of the protocol stack (e.g., the PDCP layer). For example, when a PDCP PDU is delivered to the RLC transmitter, the PDCP layer informs the RLC layer whether the PDCP PDU is part of a PDU Set or not.

In the presently described arrangement, it is noted that the PDU Set delay budget 709 of the first PDU Set is elapsed before the network failure 706 is still ongoing (i.e., the network failure has not been resolved).

According to a first arrangement, the RLC timer associated to the first PDU Set elapses 1100 and the fourth SDU is discarded 1101. Subsequently, the fifth SDU is also discarded for being part of the same PDU Set as SDU 4 (see the loopback from method step 1102 to method step 1101 in Figure 11).

According to a second arrangement, the higher layer of the protocol stack notifies the RLC transmitter that the fourth SDU is to be discarded (see method step 1100). Subsequently, the fifth SDU is also discarded as being part of the same PDU Set as the fourth SDU (see the loopback from method step 1102 to 1101 in Figure 11).

According to third arrangement, the number of retransmissions of the fourth SDU exceeds the predetermined discard threshold (i.e., 'yes' at method step 902). Hence, the fourth SDU is discarded (see method step 904 in Figure 9) by the RLC transmitter. Then, the fifth SDU is also discarded as being part of the same PDU Set as the fourth SDU (see the loopback from method step 905 to method step 904 in Figure 9).

Similar to the arrangements in Figures 5 and 6, the SDUs in Figure 7 are discarded without triggering the RLF condition. At the same time the SDUs 6, 7 and 8 may have been already discarded by higher layers of the protocol stack.

In this example the transmission window of the RLC transmitter 701 ends at SDU 5. That is the reason why the SDUs 6 to 8 can be discarded by higher layers of the protocol stack. Compared to the first embodiment (e.g., as exemplified by Figure 6), this second embodiment prevents the transmission of further unnecessary SDUs without triggering the RLF condition.

Thanks to the discard of all SDUs belonging to the same PDU Sets, RLC transmitter can start sending SDUs related to another PDU Set (e.g., the seventh and eight SDUs 707, 708, as shown in Figure 7).

Figure 8a is a flow chart showing a method of the RLC transmitter of a UE. The method comprises stopping retransmission of a PDU (e.g., a lost PDU, or SDU) if a number of PDU retransmissions exceeds a retransmit threshold (i.e., the predetermined discard threshold value), wherein the retransmit threshold is less than the discard threshold value associated with a radio link failure of the network.

Figure 8b is flow chart showing a method of the RLC transmitter (e.g., 601, 701, 801) of a UE, the method being executed when receiving a negative acknowledgement related to a RLC SDU containing a PDU of a PDU Set. For example, the method shown in Figure 8 can be executed by the network configuration shown in Figure 6.

During method step 800 a status report (e.eg., according to TS 38.322, clause 6.2.2.5) is received by the RLC transmitter 601. The status report contains a negative acknowledgement related to a RLC SDU containing a PDU of a PDU SET. The method then proceeds to method step 801, at which point the RLC transmitter 601 updates the retransmission counter attached to the RLC SDU. If it is a first retransmission of the SDU, the retransmission counter is initialized to 0, otherwise the retransmission counter is incremented by one unit.

Next, during method step 802, the retransmission counter is compared to the predetermined discard threshold value. If the retransmission counter is less than the predetermined discard threshold value, then during method step 803, the RLC transmitter 601 proceeds with the SDU retransmission (e.g., according to TS 38.322 clause 5.3.2).

If the retransmission counter is greater than the predetermined discard threshold value, then during method step 804, the RLC transmitter 601 stops retransmitting the SDU. During this step the RLC transmitter 601 does not trigger an RLF procedure. Instead, the transmitter proceeds with the transmission process and updates the transmit window, the same way as if the SDU was positively acknowledged.

During optional method step 805, the RLC transmitter 601 may notify the peer RLC receiver 602 that an SDU has been discarded. The notification may comprise at least one of an indication of the sequence number of the discarded SDU, a bit map indicating several sequence numbers, and an interval between two sequence numbers. The discard notification can be transmitted as a header only PDU, or as a dedicated control PDU. Alternatively, the discard notification may be inserted in the header of a data PDU. The discard notification can be delayed (e.g., by a predetermined time value, and/or by a predetermined number of SDU transmission events) in order to gather discard information related to several SDUs.

Figure 9 is flow chart showing a method of the RLC transmitter (e.g., 601, 701, 801) of a UE executed when receiving a negative acknowledgement related to a RLC SDU containing a PDU of a PDU Set. For example, the method shown in Figure 9 may be executed by the network configuration shown in Figure 7.

During method step 900, a status report (e.g., as defined by TS 38.322, clause 6.2.2.5) is received by the RLC transmitter 701. The status report contains a negative acknowledgement related to a RLC SDU containing a PDU of a PDU Set. The method then proceeds to method step 901, at which point the RLC transmitter updates the retransmission counter attached to the RLC SDU. If it is a first retransmission of the SDU, then the retransmission counter is initialized to 0, otherwise the retransmission counter is incremented by one unit.

Next, during method step 902, the retransmission counter is compared to the predetermined discard threshold value. If the retransmission counter value is less than the predetermined discard threshold value, then during method step 903 the RLC transmitter 701 proceeds with the SDU retransmission (e.g., according to TS 38.322 clause 5.3.2).

If the retransmission counter is greater than the predetermined discard threshold value, then during method step 904, the RLC transmitter 701 stops retransmitting the SDU. During this method step the RLC transmitter 701 does not trigger an RLF procedure. Rather, it proceeds with the transmission process (e.g., by transmitting subsequent SDUs) and updates the transmit window the same way as if the SDU was positively acknowledged.

During method step 905, the RLC transmitter 701 checks whether there are other SDUs related to the same PDU set as the one treated in previous steps. For each SDU related to the same PDU Set that is in the transmission window, the RLC transmitter 701 executes the method step 904 to stop transmitting (and/or retransmitting) these SDUs.

During optional method step 906, the RLC transmitter may notify the peer RLC receiver that an SDU have been discarded. The notification may comprise at least one of an indication of the sequence number of the discarded SDU, a bit map indicating several sequence numbers, and an interval between two sequence numbers. The discard notification can be transmitted as a header only PDU or as a dedicated control PDU, or inserted in the header of a data PDU. Furthermore, the discard notification can be delayed so as to gather discard information related to several SDUs. Figure 10 is flow chart showing a method of the RLC transmitter (e.g., 501, 601, 701) of a UE, the method being executed when a discard timer related to a RLC SDU containing a PDU of a PDU Set elapses. For example, the method shown in Figure 10 may be executed with respect to the network configuration shown in Figure 6.

During method step 1000 a discard timer related to a RLC SDU containing a PDU of a PDU Set elapses. The discard timer can be at least one of (e.g., either one of) a PDCP discard timer, a PDCP discardForLowlmportance PDCP timer or an RLC discard timer. PDCP discard and PDCP discrdForLowlmportance timers are started according to TS 38.323 clause 5.2.1. RLC discard timer is started at the reception of a PDCP PDU from PDCP layer. The initial value of both PDCP timers can be configured by the network (e.g., the gNB) and the initial value of the RLC discard timer can either configured by the network (e.g., gNB) or by the UE PDCP layer.

During method step 1001, the RLC transmitter stops transmitting or retransmitting the corresponding SDU. During this method step the RLC transmitter does not trigger an RLF procedure. Instead, it updates the transmit window the same way as if the corresponding SDU was positively acknowledged. Method step 1002 is similar to steps 906 and 805, as shown in Figures 9 and 8 respectively.

Figure 11 is a flow chart showing a method of the RLC transmitter (e.g., 501, 601, 701) of a UE, the method being executed when a discard timer related to a RLC SDU containing a PDU of a PDU Set elapses. For example, the method of Figure 11 may be executed in relation to the arrangement described above with reference to Figure 7.

During method step 1100 a discard timer related to a RLC SDU containing a PDU of a PDU Set elapses. The discard timer can be at least one of (e.g., either one of) a PDCP discard timer, a PDCP discardForLowlmportance PDCP timer or an RLC discard timer. PDCP discard and PDCP discrdForLowlmportance timers are started according to TS 38.323 clause 5.2.1. The RLC discard timer is started at the reception of a PDCP PDU from PDCP layer. The initial value of both PDCP timers can be configured by the network (e.g., the gNB) and the initial value of the RLC discard timer can either configured by the network (e.g., the gNB), or by the UE PDCP layer.

During method step 1101, the RLC transmitter stops transmitting or retransmitting the corresponding SDU. During this step the RLC transmitter shall not trigger an RLF procedure, it shall update the transmit window the same way as if the corresponding SDU was positively acknowledged. During method step 1102, the RLC transmitter checks whether there are other SDUs related to the same PDU Set as the SDU treated in the previous method steps. For each SDU related to the same PDU Set that is in the transmission window, the RLC transmitter shall execute method step 1101 to stop transmitting or retransmitting these SDUs. Correspondingly, method step 1103 is similar to steps 906 and 805 shown in Figures 9 and 8, respectively.

In the preceding description, the decision whether or not to retransmit the SDU is determined in dependence on a threshold value having been exceeded by a determined number of retransmissions (e.g., if the number of retransmissions 'exceeds' a predetermined discard threshold value, then the retransmission is stopped). It will be appreciated that the present disclosure is not limited to this conditional criterion. For example, the decision to retransmit the SDU may be determined in dependence on a threshold value being reached or achieved (e.g., if the number of SDU retransmissions teaches' the predetermined discard threshold value, then the retransmission is stopped). It will be appreciated, therefore, that each of these conditional criteria (and further alternative criteria) fall within the scope of the present disclosure.

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

As described above, there is a need to manage the retransmission of data during RLC AM operating conditions in order improve the operating efficiency of the communication network. For example, it has been identified that any retransmissions that occur after the PSDB and before the RLF threshold are unproductive. Stopping such retransmissions after the PSDB can be done in dependence on a number of retransmissions of the PDU exceeding a predetermined discard threshold value that is less than the threshold value associated with a radio link failure of the network. In this way, a second threshold (e.g., smaller than the RLF threshold) for stopping the retransmission of PDUs linked to PDU Sets may be provided. Alternatively, the RLC transmitter can rely on an upper layer discard timer to stop the retransmission of the PDU linked to a PDU Set.

In this way, elements of the transmission network may be configured to stop the retransmission of RLC PDUs linked to PDU Sets after PSDB and before RLF. For example, the retransmission may be stopped based on a second threshold, and/or based on a discard timer.

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

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

Yet further embodiments relevant to the present disclosure will now be described.

The following techniques, according to embodiments of the present disclosure, are presented for avoiding unnecessary retransmission: 1. Transmitter (TX) Initiated approach: Generally, the TX side has the knowledge of PDU Set information. The PDCP layer is already able to monitor each PDU Set delay budget and to maintain remaining time indication for each PDU Sets. Inter layer information circulation about PDU Sets is already implemented between MAC layer and PDCP layer. DSR triggering in MAC relies on PDU Set remaining time information provided by PDCP layer. Accordingly, it may be considered that necessary mechanisms for obsolete SDU detection by RLC transmitter are already available.

When the PDCP transmit entity discards obsolete SDUs, it sends a discard notification to the PDCP receiving entity. consequently, a discard notification and corresponding RX side processing exists at the PDCP layer. To address this, in embodiments of the present disclosure, a method is provided which uses a PDCP PDU Set discard mechanism as a baseline for RLC TX initiated PDU Set discard.

2. Receiver (RX) Initiated Approach: Contrary to the TX side, the RX side has no knowledge of PDU Sets at any layer. This is because PDU Sets information, including PDU Set boundary and sequence numbers, are not included inline. Howthe RX side can determine that an SDU is obsolete is therefore a difficult issue. One approach may be to configure the RX side to send a fake ack when an SDU failed to be received before being obsolete. To define SDU obsolescence a dedicated timer may be used to start a discard timer for each received SDU. For example, the t-Reassembly timer may be used as SDU obsolescence indication. Therefore, the RX initiated approach may be based on t-Reassembly timer as a PDU obsolescence indication. However, the t-Reassembly timer can be used as a trigger to send a nack indication to the TX side to prompt SDU retransmission. This would mean that retransmission would only be achieved through autonomous retransmission in that case. According to embodiments of the present disclosure a method is proposed to adopt the RX initiated approach only if autonomous retransmission is adopted.

Still further embodiments relevant to the present disclosure will now be described.

The following methods, according to embodiments of the present disclosure, are presented for reducing RLC transmission delay: A first approach is directed towards autonomous retransmission. In particular, the method is configured to anticipate the retransmission of PDUs with unknown status. The unknown status may be indicative of the PDU having been transmitted to the receiver but not acknowledged as being received or detected lost by the receiver. This enables earlier and more efficient retransmission of some PDUs, which thereby minimizes the network overhead when compared to methods which rely upon systematic retransmissions. According to this first approach, the method may be configured to provide autonomous retransmission of PDUs with unknown status. In this way, the network overhead may be reduced if the autonomous retransmission of PDUs with unknown status is not systematically triggered. In certain situations, the autonomous retransmission of PDUs having an unknown status may occur following the first transmission of all SDUs of a PDU Set. If all SDUs of a PDU Set have been sent, or are have an unknown status, then the UE can trigger autonomous retransmission of the SDUs of the PDU Set with unknown status. Accordingly, the first approach may be configured to trigger the autonomous retransmission of an SDU with unknown status if all SDUs of the PDU Set are sent or with have unknown status. In certain situations, the autonomous retransmission of PDUs having an unknown status may occur when the transmit and retransmit buffers are empty. Accordingly, the first approach may be configured to trigger autonomous retransmission of an SDU with unknown status if there are no other SDUs to send or retransmit. In certain situations, the required network resources can be reduced further if the autonomous retransmission trigger is further extended to a remaining time threshold applied to the transmit window. If the transmit window is stalled up to the remaining time threshold of a PDU Set, then autonomous retransmission may be triggered. Accordingly, the first approach may be configured to trigger autonomous retransmission if the transmit window is stalled bellow a time threshold.

A second approach for reducing RLC transmission delay is directed towards an enhanced status reporting metho. One way to speed-up the transmission of the status report by the receiving side is to introduce new triggers, for example, a timer-based trigger. However, whilst triggering a status report either periodically, or based on packet delay budget (PDB), may improve the transmission responsiveness, it will not be sufficient in all cases. For example, when a status report timer elapses while the t-Reassembly timer is still running, there will be no nack information sent to the transmitter. Accordingly, increasing the status report frequency may not be useful when the t-Reassembly timer is still running. In certain situations, the t-Reassembly timer can be reduced (or even set to 0), which increases the responsiveness of the RLC receiver once the sequence number gap is detected. But reducing the t-Reassembly timer increases the number of false missing detections, which can then increase the overhead across the network. As a consequence, enhanced status reporting can cost extra resources in downlink. One solution to this problem is to discard the prohibit timer to insure timely transmission of the status report. However, the prohibit timer is set by the network for reasons that are independent from the XR application itself, and therefore it should not be ignored when set. Accordingly, the second approach may involve a method in which the prohibit timer is not altered when it is set by the network. Further, the second approach may be configured so that the status report is not enhanced.

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

2.2. Timely RLC retransmission 2.2.1. Autonomous retransmission: One way to reduce the retransmission delay is to anticipate the retransmission of PDUs with unknown status. The unknown status is indicative of the PDU having been transmitted to the receiver but not acknowledged as being received or detected lost by the receiver. This enables earlier and more efficient retransmission of some PDUs, which thereby minimizes the overhead when compared to systematic retransmission. Proposal: Consider autonomous retransmission of PDUs with unknown status. The overhead may be reduced if the autonomous retransmission of PDUs with unknown status is not systematically triggered. The autonomous retransmission of PDUs having an unknown status may occur following the first transmission of all SDUs of a PDU Set. If all SDUs of a PDU Set have been either sent or are have unknown statuses, then the UE can trigger autonomous retransmission of the SDUs of the PDU Set with unknown status. Proposal: Trigger autonomous retransmission of an SDU with unknown status if all SDUs of the PDU Set are sent or with have unknown status. The autonomous retransmission of PDUs having an unknown status may occur when the transmit and retransmit buffers are empty. Proposal: Trigger autonomous retransmission of an SDU with unknown status if there are no other SDUS to send or retransmit. To decrease even more the needed resources the autonomous retransmission trigger can be further extended to a remaining time threshold applied to the transmit window. If the transmit window is stalled up to the remaining time threshold of a PDU Set, then autonomous retransmission may be triggered. Proposal: Trigger autonomous retransmission if the transmit window is stalled bellow a time threshold.

2.2.2 Enhanced status report: In R2-2404197, the authors suggest to speed-up the transmission of status report by the receiving side by the introduction of new triggers, for example, in R2-2404850, the authors suggest using a timer-based trigger. However, while triggering status report either periodically or based on PDB may improve the transmission responsiveness it will not be sufficient in all cases. For example, when a status report timer elapses while the t-Reassembly timer is still running, there will be no nack information sent to the transmitter. Observation: increasing the status report frequency is not useful when the t-Reassembly timer is still running. The t-Reassembly timer can be reduced (or even set to 0), which increases the responsiveness of the RLC receiver once the sequence number gap is detected. But reducing the t-Reassembly timer increases the number of false missing detections, which can then increase the overhead across the network. Observation: Enhanced status report costs extra resources in downlink. In 822405002, the authors propose to discard the prohibit timer to insure timely transmission of the status report. But the prohibit timer is set by the network for reasons that are independent from the XR application itself, and therefore it should not be ignored when set. Proposal: Do not alter the prohibit timer when set by the network. Proposal: Do not enhance the status report.

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

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

Unless otherwise defined herein, scientific, and technical terms used in connection with the presently disclosed inventive concept(s) shall have the meanings that are commonly understood by those of ordinary skill in the art, and known techniques and procedures may be performed according to conventional methods well known in the art and as described in various general and more specific references that may be cited and discussed in the present specification.

As used in this specification and claim(s), the words "comprising, "having," "including," or "containing" (and any forms thereof, such as "comprise" and "comprises," "have" and "has," "includes" and "include," or "contains" and "contain," respectively) are inclusive or open-ended and do not exclude additional, unrecited elements or method steps. The use of the term "a" or "an" in the claims and/or the specification may mean "one," as well as "one or more," "at least one," and "one or more than one." As such, the terms "a," "an," and "the," as well as all singular terms, include plural referents unless the context clearly indicates otherwise. Likewise, plural terms shall include the singular unless otherwise required by context. The use of the term "or" in the present disclosure (including the claims) is used to mean an inclusive "and/or" unless explicitly indicated to refer to alternatives only or unless the alternatives are mutually exclusive.

Unless otherwise explicitly stated as incompatible, or the physics or otherwise of the embodiments, examples, or claims prevent such a combination, the features of examples disclosed herein, and of the claims, may be integrated together in any suitable arrangement, especially ones where there is a beneficial effect in doing so. This is not limited to only any specified benefit, and instead may arise from an "ex post facto" benefit. This is to say that the combination of features is not limited by the described forms, particularly the form (e.g., numbering) of example(s), embodiment(s), or dependency of claim(s).

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

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

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

Claims (16)

1. CLAIMS1. A method for managing data transmission in a communication network operating in a radio link control acknowledge mode, the network comprising a transmitter and a receiver, the method at the transmitter comprising: stopping retransmission of a protocol data unit, PDU, to the receiver in dependence on a number of retransmissions of the PDU exceeding a predetermined discard threshold value, wherein the predetermined discard threshold value is less than a threshold value associated with a radio link failure of the network.
2. 2. The method of claim 1, wherein retransmission of the PDU is stopped if a discard timer associated with the PDU exceeds a discard timer threshold value.
3. 3. The method of claim 2, wherein the PDU is associated with a PDU Set, and the discard timer is started when a first PDU of the PDU Set is received by the transmitter.
4. 4. The method of claim 2 or claim 3, wherein the discard timer threshold value is set by the network.
5. 5. The method of any one of claims 2 to 4, wherein the discard timer threshold value is based on at least one of a PDU Set delay budget and a PDU session identity.
6. 6. The method of any one of the preceding claims, wherein the method comprises: counting the number of retransmissions of the PDU; and before each retransmission of the PDU, comparing the number of retransmissions to the predetermined discard threshold value to determine whether to proceed with the retransmission.
7. 7. The method of claim 6, wherein the method of counting the number of retransmissions is triggered by receiving a notification indicating that the status of the PDU is unknown.
8. 8. The method of any one of the preceding claims, wherein the method comprises, upon determining that retransmission of the PDU is stopped, transmitting a discard notification to the receiver.
9. 9. The method of any one of the preceding claims, wherein the method comprises, upon determining that retransmission of the PDU is stopped, transmitting a further PDU of a PDU Set associated with the PDU.
10. 10. The method of any one of claims 1 to 8, wherein the method comprises determining whether to transmit at least one further PDU of the PDU Set, wherein transmission of the further PDU is stopped if the number of retransmissions of the PDU exceeds the predetermined discard threshold value.
11. 11. The method of claim 10, when dependent on claim 2, wherein transmission of the further PDU is stopped if the discard timer associated with the PDU exceeds the discard timer threshold value.
12. 12. The method of claim 10 or claim 11, wherein the transmission of all subsequent PDUs of the PDU set are stopped.
13. 13. The method of any one of the preceding claims, wherein the method comprises, upon determining that retransmission of the PDU is stopped, transmitting a PDU of a subsequent PDU 15 Set.
14. 14. A communication network which comprises a transmitter configured to perform the method of any one of claims 1 to 13.
15. 15. A computer program comprising instructions which, when the program is executed by a transmitter, causes the transmitter to carry out the method according to any one of claims 1 to 13.
16. 16. A computer-readable medium carrying a computer program according to claim 15.