6g radio link control protocol data convergence protocol merge - integrated queue management

Abstract

A method, system and apparatus are disclosed. In an example embodiment, method implemented in a user equipment includes identifying a sequence number (SN) gap in a plurality of received packets. The method includes, in response to identifying the SN gap, starting a timer. The method includes, upon expiration of the timer, triggering delivery of packets received subsequent the SN gap and subsequently transmitting a feedback message. The method includes considering the SN gap to be acknowledged-received.

Description

[0001] 6G RADIO LINK CONTROL PROTOCOL DATA CONVERGENCE PROTOCOL

[0002] MERGE - INTEGRATED QUEUE MANAGEMENT

[0003] FIELD

[0004] The present disclosure relates to wireless communications, and in particular, to a transmitting / receiving protocol.

[0005] BACKGROUND

[0006] The Third Generation Partnership Project (3GPP) has developed and is developing standards for Fourth Generation (4G) (also referred to as Long Term Evolution (LTE)) and Fifth Generation (5G) (also referred to as New Radio (NR)) wireless communication systems. Such systems provide, among other features, broadband communication between network nodes, such as base stations, and mobile user equipments (UE), as well as communication between network nodes and between UEs. The 3GPP is also developing standards for Sixth Generation (6G) wireless communication networks.

[0007] The 5G user-plane architecture and protocols are described with reference to FIG. 1. UE is connected over the air via the Uu protocol with the radio access network (RAN) gNB (gNB is an example of a network node). The gNB may be separated into distributed unit (DU) and centralized unit (CU), connected via Fl interface. The gNB is connected to the core network (CN) including the user-plane function (UPF). Typically, IP data is transported via UE-gNB-UPF. The RAN protocol stack between UE and gNB includes the Service Data Adaptation Protocol (SDAP) protocol, for handling mapping of QoS flows as established by the UPF to data radio bearers (DRBs) as established by the gNB. The protocol data convergence protocol (PDCP) is among others responsible for encryption / integrity protection and handover forwarding and retransmission. For handovers between gNBs the Xn interface is employed. The radio link control (RLC) is among others responsible for segmentation of higher layer PDCP / IP data to fitting the transport blocks (TBs) available for the lower layer over the air transmission. Also, retransmissions are based on automated repeat request (ARQ) in acknowledged mode of RLC. MAC protocol stands for medium access control and supports scheduling of transmissions over the air, and entails the hybrid automated repeat request (HARQ) protocol. The physical layer (PHY) handles e.g. modulation and coding and the actual physical transmission. RLC and PDCP window handling and timers

[0008] RLC and PDCP maintain transmit and receive windows, defined by state variables that mark the lower and upper window edge of the used sequence numbers (SNs) of the packets. A range of SNs to be used is specified, e.g., from [0 to maxNr], A wrap-around, i.e., SNs, start again from 0 when maxNR is reached as defined. A receiver, for example, may discard packets received out of a window.

[0009] For the PDCP receiver, it is specified in, e.g. NR specifications, that the transmitter should not bring more than half the SN space in flight. This may be needed for the receiver to be able to distinguish which hyper frame number (HFN) the packets belong to when the SNs wrap-around (e.g., before or after the wrap-around occurred).

[0010] For PDCP, the window model is push-based, i.e., the highest in-sequence delivered SN pushes up the lower window edge. A reordering timer that starts when a SN gap is identified, and it may also move the lower window edge forward upon expiry, i.e., past the SN gap.

[0011] For RLC UM, the window model is pull-based, i.e., the highest transmitted / received SN pulls the window further up. In the receiver, a reassembly / reordering timer is defined that moves the lower window edge forward upon expiry, similar to the PDCP reordering timer.

[0012] For RLC AM, the window model is push-based, i.e., the lower window edge may only be moved forward upon in-sequence reception of SNs. A receiver side reassembly / reordering timer is started when a SN gap is identified, and upon expiry the timer triggers a status report feedback message to the transmitter informing the transmitter about the gap. In this way, retransmissions to close the transmission gap can be triggered. In RLC AM mode the transmitter may also, in some situations, trigger status reports based on poll bit inclusions. The RLC AM transmit window follows the receiver side window, i.e., maintains a lower transmit window edge aligned with the informed lower receiver window edge by the status reports. Poll bits may be included periodically, e.g.. every X packet data units (PDUs) or bytes, and may be retransmitted if a status report was not received within a certain time.

[0013] Segment handling

[0014] RLC applies segmentation of packets to be transmitted to fit the transmit frame size for the over-the-air transmission. RLC may include a segmentation offset and other fields in the RLC PDU header. RLC UM may use SNs only when packets are segmented. PDCP may be specified to work only with full packets, i.e., there is a one-to-one mapping of PDCP packets to higher layer payload, such as IP packets.

[0015] PDCP is the handover anchoring protocol. At a handover, lower layer protocols like RLC and HARQ are reset. PDCP undergoes the re-establishment procedure. A new security key is applied, and in AM mode, packets that were not yet acknowledged are retransmitted after the handover by PDCP.

[0016] Active queue management (AQM)

[0017] Active queue management is technique employed to maintain the transmission queue buffer within acceptable levels so as to avoid the queue from being be too long. A queue that is too long may lead to unwanted high latency for packets of services, including services competing for the same radio resources. Moreover, not letting the queue deplete, e.g., due to changes in available data rate, may mean that available resources cannot be fully exploited.

[0018] Active queue management triggers congestion indications for higher layer transmitters, e.g., the TCP transmitter, to reduce transmission rate. One way to indicate congestion is to drop packets so that the TCP receiver observes a gap in the TCP sequence and informs the TCP transmitter about it (e.g., via TCP acknowledgements).

[0019] Later NR specifications relate to an SN gap report, which is triggered when a specified discard timer for a packet expires. The SN gap report informs the receiver of a dropped packet. The receiver may expedite delivery of subsequent packets without waiting for the reordering timer to expire.

[0020] It may be beneficial for a transmitter to pre-assign SNs as soon as possible to incoming packets, e.g., to pre-process the packets. At the same time, for an AQM triggered packet drop at the PDCP Tx side, given the required reordering timer based on SNs gaps, pre-assigning may lead to delays in indicating the congestion to higher layers by the PDCP Rx side.

[0021] Thus, PDCP and RLC windows may be out of synch, meaning that while RLC AM retransmissions are still ongoing to recover lost packets, the PDCP window may have moved forward already due to the reordering timer expiring.

[0022] Although the NR PDCP and RLC protocol stacks are designed to be run independently, the window management techniques like AQM discard may require more cross-layer interaction between them. Data may be considered multiple times for retransmission in RLC and may not be able to be disregarded, even though it may be already outdated and further retransmissions are redundant.

[0023] Complexities in handling two separate windows or implementations for the two protocols lead to inefficiencies and thus potentially higher energy consumption.

[0024] SUMMARY

[0025] Some embodiments advantageously provide methods, systems, and apparatuses relating to a transmitting / receiving protocol.

[0026] Approaches described herein relate to a merged protocol uniting aspects of RLC UM, RLC AM, and PDCP protocols. Some embodiments described herein relate to how the single resulting transmission / reception window may need to behave, and how state variables and timers interact.

[0027] Below is described a receiver side short timer that may be related to a RLC AM t- reassembly, and a receiver-side long timer that may be related to a PDCP t-reordering timer. SN Gap indication from transmitter to receiver may be standardized for PDCP. Features of Applicant’s embodiments (which are italicized below) relate to the interaction between the two timers. The SN Gap indication may be considered in RLC-like procedures (short timer and polling).

[0028] An example radio protocol (e.g., uniting aspects of RLC UM, AM, PDCP) to manage transmission and reception windows may be as follows:

[0029] A receiver side short timer, o started when an SN gap is identified, o upon expiry: triggering a feedback message informing the transmitter about current reception window, considering the lower window edge, a maintained to be reported high receiver window edge and SN gaps in between.

[0030] A receiver-side long timer, o started when an SN gap is identified, o upon expiry: triggering delivery of packets subsequent to the SN gap i.e. considering these packets as well as the SN gap packet as acknowledged-received and updating the lower window edge. o Thereafter, triggering actions as if the receiver-side short timer has expired, e.g., sending the feedback message with updated state variables as described above. This may include informing the transmitter via a feedback message (considered SN gap packets as ACK).

[0031] Active queue management (AQM) that generates SN Gap reports from transmitter to receiver, e.g., converting not-yet-transmitting PDUs to empty PDUs as drop-indications, i.e., the packet at the front of the queue. o The receiver considers such PDUs as acknowledged-received for later feedback reporting, and for delivering subsequent PDUs (until the next SN gap).

[0032] (optionally in addition) Discard timer in transmitter, a maximum waiting time and including time for feedback for PDUs before considering them as lost and transmitting for them the SN Gap report from transmitter to the receiver. o The receiver considering such PDUs as acknowledged-received for later feedback reporting, and delivering subsequent PDUs (until the next SN gap).

[0033] Include a poll bit in such an SN gap indication or alternatively considering SN gap indication in receiver as having poll bit included. o Retransmitting such empty PDUs as gap indications based on poll- Retransmit timer.

[0034] Advantages of approaches described herein include enabling, at the same time: Pre-processing of packets upon their arrival, including ciphering and integrity protection. This may saving latency in time-critical processing upon departure / transmission and may enable energy-efficiency implementation.

[0035] Fast congestion indications based on active queue management, e.g., applying congestion marking / drop-indications at the front of the transmitter queue but not undergoing reordering delays in the receiver.

[0036] Simplification of specification and implementation by uniting protocols.

[0037] According to one aspect of the present disclosure, a method implemented in a UE that is configured to communicate with a network node is provided. The method includes: identifying a sequence number, SN, gap in a plurality of received packets; in response to identifying the SN gap, starting a timer; upon expiration of the timer, triggering delivery of packets received subsequent the SN gap and subsequently transmitting a feedback message; and considering the SN gap to be acknowledged-received.

[0038] According to another aspect of the present disclosure, a UE that is configured to communicate with a network node is provided. The UE is configured to: identify a sequence number, SN, gap in a plurality of received packets; in response to identifying the SN gap, start a timer; upon expiration of the timer, trigger delivery of packets received subsequent the SN gap and subsequently transmitting a feedback message; and consider the SN gap to be acknowledged-received.

[0039] According to another aspect of the present disclosure, a method implemented in a network node that is configured to communicate with a UE is provided. The method includes: identifying a sequence number, SN, gap in a plurality of received packets; in response to identifying the SN gap, starting a timer; upon expiration of the timer, triggering delivery of packets received subsequent the SN gap and subsequently transmitting a feedback message; and considering the SN gap to be acknowledged- received.

[0040] According to another aspect of the present disclosure, A network node that is configured to communicate with a UE is provided. The network node is configured to: identify a sequence number, SN, gap in a plurality of received packets; in response to identifying the SN gap, start a timer; upon expiration of the timer, trigger delivery of packets received subsequent the SN gap and subsequently transmitting a feedback message; and consider the SN gap to be acknowledged-received.

[0041] BRIEF DESCRIPTION OF THE DRAWINGS

[0042] A more complete understanding of the present embodiments, and the attendant advantages and features thereof, will be more readily understood by reference to the following detailed description when considered in conjunction with the accompanying drawings wherein:

[0043] FIG. 1 is a block diagram of 5G user-plane protocols;

[0044] FIG. 2 is a schematic diagram of an example network architecture illustrating a communication system according to principles disclosed herein;

[0045] FIG. 3 is a block diagram of a network node in communication with a user equipment over a wireless connection according to some embodiments of the present disclosure;

[0046] FIG. 4 is a flowchart of an example process in a network node according to some embodiments of the present disclosure;

[0047] FIG. 5 is a flowchart of an example process in a user equipment according to some embodiments of the present disclosure;

[0048] FIG. 6 is a flowchart of an example process in a network node according to some embodiments of the present disclosure; FIG. 7 is a flowchart of an example process in a user equipment according to some embodiments of the present disclosure;

[0049] FIG. 8 is a block diagram of transmitter side window and state variables according to some embodiments of the present disclosure;

[0050] FIG. 9 is a block diagram of receiver side state variables and timers according to some embodiments of the present disclosure;

[0051] Figure 10A and 10B are graphical diagrams of satisfied fraction of UEs with a combination of HARQ and RLC retransmissions for short discard timers of 10, 15 and 20 ms according to some embodiments of the present disclosure;

[0052] Figure 11A and 1 IB are graphical diagrams of Satisfied Fraction of UEs with a combination of HARQ and RLC retransmissions for short discard of 10, 15 and 20 ms with shorter t-reassembly according to some embodiments of the present disclosure;

[0053] Figure 12 is a graphical diagram of Satisfied Fraction of UEs with a combination of HARQ and RLC retransmissions for long discard timers of 100 and 200 ms according to some embodiments of the present disclosure; and

[0054] Figure 13 is a graphical diagram of Satisfied Fraction of UEs with a combination of HARQ and RLC retransmissions for long discard timers of 100 and 200 ms with shorter t-reassembly.

[0055] DETAILED DESCRIPTION

[0056] Before describing in detail exemplary embodiments, it is noted that the embodiments reside primarily in combinations of apparatus components and processing steps related to transmitting / receiving protocol. Accordingly, components have been represented where appropriate by conventional symbols in the drawings, showing only those specific details that are pertinent to understanding the embodiments so as not to obscure the disclosure with details that will be readily apparent to those of ordinary skill in the art having the benefit of the description herein.

[0057] As used herein, relational terms, such as “first” and “second,” “top” and “bottom,” and the like, may be used solely to distinguish one entity or element from another entity or element without necessarily requiring or implying any physical or logical relationship or order between such entities or elements. The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the concepts described herein. As used herein, the singular forms “a”, “an” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms “comprises,” “comprising,” “includes” and / or “including” when used herein, specify the presence of stated features, integers, steps, operations, elements, and / or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or groups thereof.

[0058] In embodiments described herein, the joining term, “in communication with” and the like, may be used to indicate electrical or data communication, which may be accomplished by physical contact, induction, electromagnetic radiation, radio signaling, infrared signaling or optical signaling, for example. One having ordinary skill in the art will appreciate that multiple components may interoperate and modifications and variations are possible of achieving the electrical and data communication.

[0059] In some embodiments described herein, the term “coupled,” “connected,” and the like, may be used herein to indicate a connection, although not necessarily directly, and may include wired and / or wireless connections.

[0060] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the concepts described herein. As used herein, the singular forms “a”, “an” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms “comprises,” “comprising,” “includes” and / or “including” when used herein, specify the presence of stated features, integers, steps, operations, elements, and / or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or groups thereof.

[0061] The term “network node” used herein can be any kind of network node comprised in a radio network which may further comprise any of base station (BS), radio base station, base transceiver station (BTS), base station controller (BSC), radio network controller (RNC), g Node B (gNB), evolved Node B (eNB or eNodeB), Node B, multistandard radio (MSR) radio node such as MSR BS, multi-cell / multicast coordination entity (MCE), relay node, donor node controlling relay, radio access point (AP), transmission points, transmission nodes, Remote Radio Unit (RRU) Remote Radio Head (RRH), a core network node (e.g., mobile management entity (MME), self-organizing network (SON) node, a coordinating node, positioning node, MDT node, etc.), an external node (e.g., 3rd party node, a node external to the current network), nodes in distributed antenna system (DAS), a spectrum access system (SAS) node, an element management system (EMS), etc. The network node may also comprise test equipment. The term “radio node” used herein may be used to also denote a user equipment (UE) such as a wireless device (WD) or a radio network node.

[0062] In some embodiments, the non-limiting terms wireless device (WD) or a user equipment (UE) are used interchangeably. The UE herein can be any type of user equipment capable of communicating with a network node or another UE over radio signals, such as a wireless device (WD). The UE may also be a radio communication device, target device, device to device (D2D) UE, machine type UE or UE capable of machine to machine communication (M2M), low-cost and / or low-complexity UE, a sensor equipped with UE, Tablet, mobile terminals, smart phone, laptop embedded equipped (LEE), laptop mounted equipment (LME), USB dongles, Customer Premises Equipment (CPE), an Internet of Things (loT) device, or a Narrowband loT (NB-IOT) device etc.

[0063] Also, in some embodiments the generic term “radio network node” is used. It can be any kind of a radio network node which may comprise any of base station, radio base station, base transceiver station, base station controller, network controller, RNC, evolved Node B (eNB), Node B, gNB, Multi-cell / multicast Coordination Entity (MCE), relay node, access point, radio access point, Remote Radio Unit (RRU) Remote Radio Head (RRH).

[0064] Note that although terminology from one particular wireless system, such as, for example, 3GPP LTE and / or New Radio (NR) and / or 6G, may be used in this disclosure, this should not be seen as limiting the scope of the disclosure to only the aforementioned system. It is contemplated that other 3GPP systems may make use of the concepts and arrangements disclosed herein. For example, a disclosure relating to NR may also be implementable in a 6G system and / or an LTE system, a disclosure relating to 6G may also be implementable in a NR and / or LTE system, and a disclosure relating to LTE may also be implementable in a NR and / or 6G system. Other wireless systems, including without limitation Wide Band Code Division Multiple Access (WCDMA), Worldwide Interoperability for Microwave Access (WiMax), Ultra Mobile Broadband (UMB) and Global System for Mobile Communications (GSM), may also benefit from exploiting the ideas covered within this disclosure.

[0065] According to one or more embodiments of this aspect, the general description elements in the form of “one of A and B” corresponds to A or B. According to one or more embodiments of this aspect, at least one of A and B corresponds to A, B or AB, or to one or more of A and B, or one or both of A and B . According to one or more embodiments of this aspect, at least one of A, B and C corresponds to one or more of A, B and C, and / or A, B, C or a combination thereof.

[0066] Note further, that functions described herein as being performed by a user equipment or a network node may be distributed over a plurality of user equipments and / or network nodes. In other words, it is contemplated that the functions of the network node and user equipment described herein are not limited to performance by a single physical device and, in fact, can be distributed among several physical devices.

[0067] Unless otherwise defined, all terms (including technical and scientific terms) used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this disclosure belongs. It will be further understood that terms used herein should be interpreted as having a meaning that is consistent with their meaning in the context of this specification and the relevant art and will not be interpreted in an idealized or overly formal sense unless expressly so defined herein.

[0068] Some embodiments are directed to transmitting / receiving protocol.

[0069] Referring again to the drawing figures, in which like elements are referred to by like reference numerals, there is shown in FIG. 2 a schematic diagram of a communication system 10, according to an embodiment, such as a 3GPP-type cellular network that may support standards such as LTE and / or NR (5G) and / or 6G, which comprises an access network 12, such as a radio access network, and a core network 14. The access network 12 comprises a plurality of network nodes 16a, 16b, 16c (referred to collectively as network nodes 16), such as NBs, eNBs, gNBs or other types of wireless access points, each defining a corresponding coverage area 18a, 18b, 18c (referred to collectively as coverage areas 18). Each network node 16a, 16b, 16c is connectable to the core network 14 over a wired or wireless connection 20. A first user equipment (UE) 22a located in coverage area 18a is configured to wirelessly connect to, or be paged by, the corresponding network node 16a. A second UE 22b in coverage area 18b is wirelessly connectable to the corresponding network node 16b. While a plurality of UEs 22a, 22b (collectively referred to as user equipments 22) are illustrated in this example, the disclosed embodiments are equally applicable to a situation where a sole UE is in the coverage area or where a sole UE is connecting to the corresponding network node 16. Note that although only two UEs 22 and three network nodes 16 are shown for convenience, the communication system may include many more UEs 22 and network nodes 16. Also, it is contemplated that a UE 22 can be in simultaneous communication and / or configured to separately communicate with more than one network node 16 and more than one type of network node 16. For example, a UE 22 can have dual connectivity with a network node 16 that supports LTE and the same or a different network node 16 that supports NR. As an example, UE 22 can be in communication with an eNB for LTE / E-UTRAN and a gNB for NR / NG-RAN.

[0070] A network node 16 (eNB or gNB) is configured to include a network node (NN) unit 24 which is configured to perform one or more network node 16 functions described herein, including functions related to transmitting / receiving protocol. A user equipment 22 is configured to include a UE unit 26 which is configured to perform one or more UE 22 functions described herein, including functions related to transmitting / receiving protocol.

[0071] Example implementations, in accordance with an embodiment, of the UE 22 and network node 16 discussed in the preceding paragraphs will now be described with reference to FIG. 2.

[0072] The communication system 10 includes a network node 16 provided in a communication system 10 and including hardware 28 enabling it to communicate with the UE 22. The hardware 28 may include a radio interface 30 for setting up and maintaining at least a wireless connection 32 with a UE 22 located in a coverage area 18 served by the network node 16. The radio interface 30 may be formed as or may include, for example, one or more RF transmitters, one or more RF receivers, and / or one or more RF transceivers. The radio interface 30 includes an array of antennas 34 to radiate and receive signal(s) carrying electromagnetic waves.

[0073] In the embodiment shown, the hardware 28 of the network node 16 further includes processing circuitry 36. The processing circuitry 36 may include a processor 38 and a memory 40. In particular, in addition to or instead of a processor, such as a central processing unit, and memory, the processing circuitry 36 may comprise integrated circuitry for processing and / or control, e.g., one or more processors and / or processor cores and / or FPGAs (Field Programmable Gate Array) and / or ASICs (Application Specific Integrated Circuitry) adapted to execute instructions. The processor 38 may be configured to access (e.g., write to and / or read from) the memory 40, which may comprise any kind of volatile and / or nonvolatile memory, e.g., cache and / or buffer memory and / or RAM (Random Access Memory) and / or ROM (Read-Only Memory) and / or optical memory and / or EPROM (Erasable Programmable Read-Only Memory). Thus, the network node 16 further has software 42 stored internally in, for example, memory 40, or stored in external memory (e.g., database, storage array, network storage device, etc.) accessible by the network node 16 via an external connection. The software 42 may be executable by the processing circuitry 36. The processing circuitry 36 may be configured to control any of the methods and / or processes described herein and / or to cause such methods, and / or processes to be performed, e.g., by network node 16. Processor 38 corresponds to one or more processors 38 for performing network node 16 functions described herein. The memory 40 is configured to store data, programmatic software code and / or other information described herein. In some embodiments, the software 42 may include instructions that, when executed by the processor 38 and / or processing circuitry 36, causes the processor 38 and / or processing circuitry 36 to perform the processes described herein with respect to network node 16. For example, processing circuitry 36 of the network node 16 may include NN unit 24 which is configured to perform one or more network node 16 functions described herein, including functions related to transmitting / receiving protocol.

[0074] The communication system 10 further includes the UE 22 already referred to. The UE 22 may have hardware 44 that may include a radio interface 46 configured to set up and maintain a wireless connection 32 with a network node 16 serving a coverage area 18 in which the UE 22 is currently located. The radio interface 46 may be formed as or may include, for example, one or more RF transmitters, one or more RF receivers, and / or one or more RF transceivers. The radio interface 46 includes an array of antennas 48 to radiate and receive signal(s) carrying electromagnetic waves.

[0075] The hardware 44 of the UE 22 further includes processing circuitry 50. The processing circuitry 50 may include a processor 52 and memory 54. In particular, in addition to or instead of a processor, such as a central processing unit, and memory, the processing circuitry 50 may comprise integrated circuitry for processing and / or control, e.g., one or more processors and / or processor cores and / or FPGAs (Field Programmable Gate Array) and / or ASICs (Application Specific Integrated Circuitry) adapted to execute instructions. The processor 52 may be configured to access (e.g., write to and / or read from) memory 54, which may comprise any kind of volatile and / or nonvolatile memory, e.g., cache and / or buffer memory and / or RAM (Random Access Memory) and / or ROM (Read-Only Memory) and / or optical memory and / or EPROM (Erasable Programmable Read-Only Memory). Thus, the UE 22 may further comprise software 56, which is stored in, for example, memory 54 at the UE 22, or stored in external memory (e.g., database, storage array, network storage device, etc.) accessible by the UE 22. The software 56 may be executable by the processing circuitry 50. The software 56 may include a client application 58. The client application 58 may be operable to provide a service to a human or non-human user via the UE 22.

[0076] The processing circuitry 50 may be configured to control any of the methods and / or processes described herein and / or to cause such methods, and / or processes to be performed, e.g., by UE 22. The processor 52 corresponds to one or more processors 52 for performing UE 22 functions described herein. The UE 22 includes memory 54 that is configured to store data, programmatic software code and / or other information described herein. In some embodiments, the software 56 and / or the client application 58 may include instructions that, when executed by the processor 52 and / or processing circuitry 50, causes the processor 52 and / or processing circuitry 50 to perform the processes described herein with respect to UE 22. For example, the processing circuitry 50 of the user equipment 22 may include UE unit 26 which is configured to perform one or more UE 22 functions described herein, including functions related to transmitting / receiving protocol.

[0077] In some embodiments, the inner workings of the network node 16 and UE 22 may be as shown in FIG. 3 and independently, the surrounding network topology may be that of FIG. 2.

[0078] The wireless connection 32 between the UE 22 and the network node 16 is in accordance with the teachings of the embodiments described throughout this disclosure. More precisely, the teachings of some of these embodiments may improve the data rate, latency, and / or power consumption and thereby provide benefits such as reduced user waiting time, relaxed restriction on file size, better responsiveness, extended battery lifetime, etc. In some embodiments, a measurement procedure may be provided for the purpose of monitoring data rate, latency and other factors on which the one or more embodiments improve.

[0079] Although FIGS. 2 and 3 show various “units” such as NN unit 24 and UE unit 26 as being within a respective processor, it is contemplated that these units may be implemented such that a portion of the unit is stored in a corresponding memory within the processing circuitry. In other words, the units may be implemented in hardware or in a combination of hardware and software within the processing circuitry. FIG. 4 is a flowchart of an example process in a network node 16 according to some embodiments of the present disclosure. One or more blocks described herein may be performed by one or more elements of network node 16 such as by one or more of processing circuitry 36 (including the NN unit 24), processor 38, and / or radio interface 30. Network node 16 configured to identify a sequence number (SN) gap in a plurality of received packets (Block SI 00). Network node 16 is configured to, in response to identifying the SN gap, start a timer (Block SI 02). Network node 16 is configured to, upon expiration of the timer, trigger delivery of packets received subsequent the SN gap and to subsequently transmit a feedback message (Block S104).

[0080] In some embodiments, network node 16 is configured to report a received empty packet data unit, PDU, as acknowledged-received and delivering subsequent PDUs until a next SN gap.

[0081] In some embodiments, network node 16 is configured to one of include a poll bit in an SN gap indication or consider a received SN gap indication as including the poll bit.

[0082] FIG. 5 is a flowchart of an example process in a user equipment 22 according to some embodiments of the present disclosure. One or more blocks described herein may be performed by one or more elements of user equipment 22 such as by one or more of processing circuitry 50 (including the UE unit 26), processor 52, and / or radio interface 46. UE 22 configured to identify a sequence number (SN) gap in a plurality of received packets (Block SI 06). UE 22 is configured to, in response to identifying the SN gap, start a timer (Block SI 08). UE 22 is configured to, upon expiration of the timer, trigger delivery of packets received subsequent the SN gap and subsequently transmitting a feedback message (Block SI 10).

[0083] In some embodiments, UE 22 is configured to report a received empty packet data unit, PDU, as acknowledged-received and delivering subsequent PDUs until a next SN gap.

[0084] In some embodiments, UE 22 is configured to one of include a poll bit in an SN gap indication or consider a received SN gap indication as including the poll bit.

[0085] FIG. 6 is a flowchart of another example process in a network node 16 according to some embodiments of the present disclosure. One or more blocks described herein may be performed by one or more elements of network node 16 such as by one or more of processing circuitry 36 (including the NN unit 24), processor 38, and / or radio interface 30. Network node 16 configured to identify (Block SI 12) a sequence number, SN, gap in a plurality of received packets. Network node 16 configured to, in response to identifying the SN gap, start (Block SI 14) a timer. Network node 16 configured to, upon expiration of the timer, trigger (Block SI 16) delivery of packets received subsequent the SN gap and subsequently transmitting a feedback message. Network node 16 configured to consider (Block SI 18) the SN gap to be acknowledged-received.

[0086] In some embodiments, the network node 16 is further configured to deliver subsequent PDUs until a next SN gap.

[0087] In some embodiments, the network node 16 is further configured to one of: include a poll bit in an SN gap indication or consider a received SN gap indication as including the poll bit.

[0088] In some embodiments, the network node 16 is further configured to retransmit the poll bit and an SN drop indication upon expiration of a timer.

[0089] FIG. 7 is a flowchart of another example process in a user equipment 22 according to some embodiments of the present disclosure. One or more blocks described herein may be performed by one or more elements of user equipment 22 such as by one or more of processing circuitry 50 (including the UE unit 26), processor 52, and / or radio interface 46. UE 22 is configured to identify (Block SI 20) a sequence number, SN, gap in a plurality of received packets. UE 22 is configured to, in response to identifying the SN gap, start (Block S122) a timer. UE 22 is configured to, upon expiration of the timer, trigger (Block SI 24) delivery of packets received subsequent the SN gap and subsequently transmitting a feedback message. UE 22 is configured to consider (Block SI 26) the SN gap to be acknowledged-received.

[0090] In some embodiments, UE 22 is further configured to deliver subsequent PDUs until a next SN gap.

[0091] In some embodiments, the UE 22 is further configured to one of: include a poll bit in an SN gap indication or consider a received SN gap indication as including the poll bit.

[0092] In some embodiments, UE 22 is further configured to retransmit the poll bit and an SN drop indication upon expiration of a timer.

[0093] Having described the general process flow of arrangements of the disclosure and having provided examples of hardware and software arrangements for implementing the processes and functions of the disclosure, the sections below provide details and examples of arrangements for a transmitting / receiving protocol. One or more UE 22 functions described below may be performed by one or more of processing circuitry 50, processor 52, UE unit 26, etc. One or more network node 16 functions described below may be performed by one or more of processing circuitry 36, processor 38, NN unit 24, etc. Embodiments described herein relate to a merged RLC AM, RLC UM and PDCP protocol, such as for 6G a communication network. The protocol may be configured to work in unacknowledged or acknowledged mode. In acknowledged mode, poll bits to trigger status reports are used, and status reports are triggered. In unacknowledged mode, this may not be needed. In unacknowledged mode, data may be assumed to be received in a transmitter after a time period following transmission, without the need for an acknowledgement by the status report.

[0094] The SN gap indication or SN drop indication may be realized as a Control PDU of the protocol, or (as further described below) as an empty PDU. The transmitter may always include a poll bit in the SN drop indication or may at least treat the SN drop indication as if there was a poll bit included. For example, in some embodiments, pollRetransmitTimer applies also for retransmitting the poll and the SN drop indication. This may ensure that the SN drop indication is received.

[0095] The transmitter side (e.g., from the perspective of a network node 16 and / or UE 22 when transmitting) is defined by the following state variables:

[0096] TX_NEXT: the higher window edge, i.e., the highest transmitted PDU SN plus one.

[0097] TX_NEXT_ACK: the lower window edge, i.e., the highest acknowledged (via status reports) to be received (AM) or assumed to be received SN (UM), plus one. Transmission may only be allowed if not more than half of the SN space is brought in flight, i.e., the distance between TX_NEXT and TX_NEXT_ACK.

[0098] DiscardTimer: started for each incoming packet (SDU) and continues during transmission until acknowledgment or assumption of reception. Upon expiry, an SN gap report is sent to the receiver. The SN gap report may be an empty PDU with the SN of the original PDU.

[0099] AQM: SN gap reports or empty PDUs as drop indications may also be transmitted resulting from AQM. AQM monitors the transmitter queue, e.g., the not-yet-transmitted packets, their size, and their age. Based on certain AQM algorithms, packets may be considered as marked or dropped, in which case an SN gap indication is sent for this packet. For fast congestion indication based on AQM, the packet at the front of the queue may be considered an SN gap indication.

[0100] When a PDU is indicated as negatively acknowledged by the receiver status reporting, it is considered for retransmission.

[0101] FIG. 8 depicts an example of transmitter-side window and state variables. The PDU header may consider the following fields.

[0102] SI field, to indicate segmentation, e.g., if first and last byte of the SDU pay load are included in the PDU;

[0103] SO field, to indicate the segmentation offset;

[0104] P field, the polling field;

[0105] One SN, which may always be included; and Payload, if the PDU is not a drop-indication.

[0106] Pre-processing of PDU headers (e.g., upon arrival of data) is possible under the assumption that no segmentation is required upon transmission. Payload data is encrypted and integrity protected. If segmentation is needed, few specific header fields are updated without need for header size changes for the first segment to be transmitted. For a later point in time, when the secondary segments of the packets are being transmitted, a segmentation offset is added to the header. Upon transmission, the pre-processed PDU header (with updates for segmentation) and pre-processed data is transmitted without further modification. This is beneficial from processing point of view.

[0107] The receiver side (e.g., from the perspective of a network node 16 and / or UE 22 when receiving) may be defined as follows:

[0108] RX_NEXT: highest received SN, plus one.

[0109] RX_DELIV: highest received in-order delivered SN, plus one.

[0110] RX_REORD: SN that triggered the gap identification, e.g., SN following the SN gap plus one. It serves as the state variable for the t-ReorderingLong timer. t-ReorderingLong timer: starts when an SN gap is identified. It stops when the SN gap is closed. Loss is considered as identified upon expiry, e.g., RX_DELIV is moved past the loss, triggering out-of-order delivery of packets now behind RX DELIV and any subsequent in-order delivered packets until the next SN Gap. RX REORD is updated to RX_NEXT, if another gap is present upon expiry of the timer. Furthermore, in at least one embodiment, the expiry of t-reorderingLong triggers the actions of t-ReorderingShort expiry. Data behind updated RX DELIV is considered as acknowledged to be received.

[0111] RX_NEXT_STATUS_TRIGGER: SN that triggered the gap identification, i.e., SN gap plus one. It serves as the state variable for the t-ReorderingShort timer. In some cases, it may only be used in AM.

[0112] RX HIGHEST STATUS: highest possible acknowledged SN for the next status report. In some cases, it may only be used in AM. t-ReorderingShort timer: starts when an SN gap identified. It stops when the SN gap is closed. At expiry, the need for a status report is identified, and the status report is triggered after updating state variables as follows: RX HIGHEST STATUS is moved past the loss, and RX NEXT STATUS TRIGGER is moved to RX NEXT if another gap is present. In some cases, it may only be used in AM.

[0113] In at least one embodiment, upon reception of the SN gap indication as drop indication (e.g. as empty PDU), the receiver (e.g., UE) considers the PDU received (e.g.. for updating RX DELIV). Subsequent data may be delivered (e.g., until the next SN Gap). The timers above may also be stopped upon the SN gap indication, since the PDU of the SN gap is considered to be received (i.e. the SN Gap is considered closed). Status reporting considers the indicated gaps as successfully received and indicates them as ACK.

[0114] In some embodiments, the SN gap indication may be considered to have a poll bit included and thus trigger status reporting. In some embodiments, the transmitter may always include a poll bit in the SN Gap indication to trigger the status report.

[0115] The interaction between the timers is illustrated in FIG. 9, which depicts receiverside state variables and timers.

[0116] At rx-reordering-long expiry, it may be necessary to trigger actions of rx- reordering-short expiry, even if rx-reordering-short was not running before. This may, e.g., update rx-highest-status and attempt to trigger a status report. However, in some cases it may be necessary that this occurs after rx-deliv and rx-reord have been updated, e.g., to create these “fake” ACKs (i.e., to not consider blocks 3 and 4 as NACKs).

[0117] In some embodiments, the receiver side operations can also be performed without the RX NEXT STATUS TRIGGER and RX HIGHEST STATUS, as these status variables may only be used for status reporting and do not impact the receiver window handling. Hence, the status report can indicate the received status of the PDUs between RX DELIV and RX NEXT. For non-contiguous discarding, the report can include the first missing SN set to RX DELIV and a bitmap size equal to (RX DELIV - RX NEXT). For contiguous discarding, the status report can include the range of PDUs discarded between RX DELIV and RX NEXT.

[0118] Transmitter and receiver implementations can be prepared to handle the SN Gap report as “empty PDU,” i.e., transmitting an SN Gap report for a PDU with the SN can be considered “converting” the PDU to empty PDU (i.e., a PDU without payload or dummy payload). Transmitter, upon conversion to empty PDU, may ignore potential feedback details such as segmentation offsets triggered by the receiver in the meantime and based on the original PDU length.

[0119] Receiver upon reception of empty PDU as drop indication, may disregard potentially received segments of original PDU for status reporting. Instead, the receiver may consider PDU as completely acknowledged-received.

[0120] Regarding handover, the transmitter and receiver may consider partially received packets as not received, i.e., disregarding any received segment. Transmitter and receiver may use only a new / other security key after the handover for transmissions / retransmissions.

[0121] PDU Set handling

[0122] Packet dependence can be defined as between PDUs. These PDUs may be considered part of a PDU set. This information is available at the transmitter side. A PDU set may include PDUs having a same application-level delivery deadline, e.g., PDUs of packets of a same video frame or update message of a real-time application.

[0123] A discard timer expiry for one PDU of the PDU set may thus trigger SN gap reporting for all PDUs belonging to the same set, i.e., all are to be considered as acknowledged-received in the receiver side upon reception of this SN gap report.

[0124] If the receiver side has information on the PDU set belonging of the PDUs, the SN gap report may include only information on one PDU and it is the receiver that based on the information on the belonging of the PDUs to the PDU set considers all PDUs for the PDU set as acknowledged-received.

[0125] In cases where the receiver has PDU Set information, i.e., the SN belonging to a PDU Set, it can also update the window edge based on the PDU Set SN when a loss is identified and inform the transmitter of this in the status report. This may be relevant if only partial of PDU Set need to be delivered (as explained in next paragraph). The receiver may have shorter reordering timers configured to trigger the delivery of certain amount of a PDU Set, and then essentially inform transmitter, e.g. in a status report, that the rest of the SN doesn’t need to be transmitted and can be discarded.

[0126] The described PDU Set handling procedures may also include the application of a threshold as to when to trigger completion of the discarding of the PDU Set. That is, there can be cases when only a partial PDU Set may need to be delivered. For example, a threshold can be applied on the number / percentage of PDUs that need to be delivered in a PDU Set, and only when a larger gap than the threshold (e.g., more than a certain number of PDUs are discarded) is identified then the rest of the PDUs are also discarded.

[0127] Example Embodiments:

[0128] Example Al . A method implemented in a UE 22 that is configured to communicate with a network node 16 and / or another UE, the method comprising: identifying an SN gap in a plurality of received packets; in response to identifying the SN gap, starting a timer; and upon expiration of the timer, triggering delivery of packets received subsequent the SN gap and subsequently transmitting a feedback message.

[0129] Example A2. The method of Example Al, further comprising reporting a received empty PDU as acknowledged-received and delivering subsequent PDUs until a next SN gap.

[0130] Example A3. The method of Example Al, further comprising one of including a poll bit in an SN gap indication or considering a received SN gap indication as including the poll bit.

[0131] Example Bl . A UE 22 configured to communicate with a network node 16 and / or another UE, the UE 22 configured to, and / or comprising a radio interface and / or processing circuitry configured to: identify an SN gap in a plurality of received packets; in response to identifying the SN gap, start a timer; and upon expiration of the timer, trigger delivery of packets received subsequent the SN gap and subsequently transmitting a feedback message.

[0132] Example B2. The UE 22 of Example Bl, wherein the UE 22 is further configured to report a received empty PDU as acknowledged-received and delivering subsequent PDUs until a next SN gap.

[0133] Example B3. The UE 22 of Example Bl, wherein the UE 22 is further configured to one of include a poll bit in an SN gap indication or consider a received SN gap indication as including the poll bit.

[0134] Example Cl. A method implemented in a network node 16 that is configured to communicate with a UE 22 and / or another network node, the method comprising: identifying an SN gap in a plurality of received packets; in response to identifying the SN gap, starting a timer; and upon expiration of the timer, triggering delivery of packets received subsequent the SN gap and subsequently transmitting a feedback message

[0135] Example C2. The method of Example Cl, further comprising reporting a received empty PDU as acknowledged-received and delivering subsequent PDUs until a next SN gap. Example C3. The method of Example Cl, further comprising one of including a poll bit in an SN gap indication or considering a received SN gap indication as including the poll bit.

[0136] Example DI. A network node 16 configured to communicate with a UE 22 and / or another network node, the network node 16 configured to, and / or comprising a radio interface and / or comprising processing circuitry configured to: identify an SN gap in a plurality of received packets; in response to identifying the SN gap, start a timer; and upon expiration of the timer, trigger delivery of packets received subsequent the SN gap and subsequently transmitting a feedback message.

[0137] Example D2. The network node 16 of Example DI, wherein the network node 16 is further configured to report a received empty PDU as acknowledged-received and delivering subsequent PDUs until a next SN gap.

[0138] Example D3. The network node 16 of Example DI, wherein the network node is further configured to one of include a poll bit in an SN gap indication or consider a received SN gap indication as including the poll bit.

[0139] The following provides non-limiting examples of how certain aspects of the proposed solutions could be implemented within the framework of a specific communication standard. In particular, the following provides non-limiting examples of how the proposed solutions could be implemented within the framework of a 3GPP TSG RAN standard. The changes described are merely intended to illustrate how certain aspects of the proposed solutions could be implemented in a particular standard. However, the proposed solutions could also be implemented in other suitable manners, both in the 3GPP Specification and in other specifications or standards.

[0140] 1 Introduction

[0141] The following were the agreements from the RLC AM enhancement discussions in RAN2#127bis:

[0142] In this contribution, we discuss further on the details of the combined approach for avoid unnecessary retransmissions. Further, provide our views on the two approaches for RLC timely retransmissions.

[0143] This paper will also provide a discussion on the incoming SA2 LS (S2-2410999) on AL- FEC.

[0144] 2 Discussion

[0145] 2.1 Combined Tx-Rx Approach

[0146] The new local timer enables the RLC layer to be aware of the SDUs relevance. When running, the RLC layer is aware that this SDU is still relevant to the PDCP layer but upon expiry, would recognize that the corresponding PDCP PDU is irrelevant and hence, the SDU can be abandoned.

[0147] Observation 1 The local timer enables RLC to be aware of the SDUs relevance in the PDCP.

[0148] The local timer need not be perfectly synchronized with t-Reordering, but it should allow for a certain number of retransmissions before abandonment thereby limiting the number of ARQ retransmissions to deliver the missing RLC data. As a result, the length of the new timer can have values in the range of t-Reordering.

[0149] The length of the new timer can be of the order of t-Reordering.

[0150] The local timer is started when a higher RLC SN than RX_Next has been delivered to the upper layers (i.e., when a gap is created), then RLC knows that the PDCP will only wait a finite time for the missing PDCP SN before advancing the PDCP Rx window. The stopping condition is when the gap no longer exists i.e., the missing SNs have been received.

[0151] Local timer can be started when a higher RLC SN than RX Next has been delivered to the upper layers.

[0152] Local timer can be stopped / reset when RX Next Highest is equal to RX Next.

[0153] Upon expiry of the local timer, as agreed in the last meeting, the Rx side considers the corresponding SDU to be abandoned and informs the Tx side with an ACK for the abandoned SDU i.e., indicating to the Tx side with a fake ACK for the abandoned SDUs. Upon expiry of the local timer, the Rx side informs the Tx side with an ACK in the

[0154] RLC status report for the abandoned SDU.

[0155] For handling of the control PDUs, typically the size of control PDUs are quite small, < 2 octets except for the PDCP status report / PDCP SN gap report which can be at least 6 octets. In practice, with a 10% BLER target, such small PDUs are successfully transmitted in the initial transmission or with the least number of retransmission attempts. Thus, proper network configuration of the local timer is sufficient to allow for receiving the control PDUs without being abandoned.

[0156] Proper network configuration of the local timer is sufficient to handle the control PDUs.

[0157] For the indication from the Tx to the Rx, given the agreement that the Rx window is moved first and then the Tx window is moved to maintain synchronization, there is no need for any Tx side indication. In addition, given that RLC performs out-of-order delivery, there is reordering delay at the Rx side. As a result, we think there is no need for any indication from the Tx to Rx.

[0158] As RLC performs out-of-order delivery to upper layers, no indication is needed from the Tx to Rx.

[0159] Refer to the TP in the Annex.

[0160] 2.2 Timely Retransmissions

[0161] In the last meeting, RAN2 agreed to focus on the autonomous retransmissions and polling enhancements. In the following sections, we provide our analysis on these methods.

[0162] 2.2.1 Autonomous Retransmissions

[0163] The proponents for the autonomous retransmissions claim that there is a significant delay in receiving the RLC status report from the Rx side and thus, the discard timer on the PDU can run out. As the round-trip-time (RTT) for receiving the RLC status report seems to be the bottleneck, we should first discuss the possible RTTs and thus, the applicability of the autonomous retransmissions.

[0164] Observation 2 It is important to establish the applicability of autonomous retransmissions in the context of the discard timers.

[0165] In practice, for ongoing UL traffic, the RTT for receiving the RLC status report is around 8-10 ms and not more than 20 ms in a loaded gNB scenario. For discard timers longer than 20 ms, the UE has enough time to receive the RLC status report and thus, these autonomous retransmissions are not relevant. Hence, the autonomous retransmissions are only relevant for discard timers less than 20 ms i.e., short discard timers.

[0166] Observation 3 Autonomous retransmissions are only relevant for short discard timers.

[0167] For short discard timers, although one could argue that the RLC status PDUs (RLC control PDUs) are prioritized, there is not enough time to trigger RLC retransmissions i.e., RLC AM is not suited for such short discard timers. However, the blind HARQ retransmissions (under gNB control) can be done and are better when compared to RLC retransmissions because of the 3 dB gain from the soft combining across different transmissions.

[0168] Observation 4 For shorter discard timers, the Tx entity (under gNB control) can continue to perform blind HARQ retransmissions (rather than triggering RLC retransmissions) thereby obtaining a 3 dB gain from soft combining.

[0169] To better understand the difference between HARQ and RLC transmissions, we ran simulations with XR traffic for short and long discard timers. We quantified the result in terms of satisfied number of UEs with RLC and HARQ retransmissions shown below:

[0170] Figure 10A and 10B depict Satisfied Fraction of UEs with a combination of HARQ and RLC retransmissions for short discard timers of 10, 15 and 20 ms.

[0171] Figure 11A and 11B depict Satisfied Fraction of UEs with a combination of HARQ and RLC retransmissions for short discard of 10, 15 and 20 ms with shorter t-reassembly. As seen in Figure 1, RLC retransmissions do not provide any gains as opposed to HARQ retransmissions. With the red curve (which runs RLC UM, without a limit for the #HARQ retransmissions) being a good indication for the efficacy of HARQ retransmissions. Additionally, we tried to increase the number of RLC retransmissions by reducing the t- reassembly timer, but this results in the same outcome. Observation 5 For short discard timers, the efficacy of HARQ retransmissions is higher than RLC retransmissions.

[0172] Figure 12 depicts Satisfied Fraction of UEs with a combination of HARQ and RLC retransmissions for long discard timers of 100 and 200 ms.

[0173] Figure 13 depicts Satisfied Fraction of UEs with a combination of HARQ and RLC retransmissions for long discard timers of 100 and 200 ms with shorter t-reassembly. In comparison and as expected, for longer discard timers, RLC retransmissions are more effective, provide more gains and results in a higher percentage of satisfied users as shown in Figure 3 and 4.

[0174] Observation 6 Gains with RLC retransmissions are only obtained for long discard timers.

[0175] For autonomous retransmissions, with a BLER target usually set to 10%, 90% of these transmissions are redundant and thus leads to wastage of resources. In addition, from a system perspective, UEs in bad radio channel conditions would essentially consume 2x UL resources per UE, per RLC SDU retransmission, where x depends on segmentation. This would be detrimental in an already resource constrained environment exacerbating UL congestion in the cell. Further, there is no guarantee that such autonomous retransmissions will be successful.

[0176] Observation 7 Autonomous retransmissions will be redundant 90% of the time and would consume 2x UL resources per UE, per RLC SDU retransmission. For example, if segmented into 4 AMD PDUs, a UE would consume eight times the UL resources which would exacerbate UL congestion.

[0177] Do not pursue autonomous retransmissions to achieve timely retransmissions.

[0178] 2.2.2 Polling Enhancements

[0179] One could optimize the current polling mechanism based on the argument that this mechanism might result in the RLC status reports being sent either too frequently (too early) or sparsely (too late). Such frequent status reports are not always necessary because not all the AMD PDUs are delay critical at a given time and hence, it leads to overheads in transmission. On the other hand, it cannot be too sparse (too late) because this would result in the AMD PDU to be delay critical or even discarded if received too late i.e., current polling mechanism might not always be synchronized with the delay requirements of the AMD PDU as the Rx entity is unaware of the remaining time to discard. Observation 8 The current polling mechanism cannot consider the delay criticality of the AMD PDU in the buffer. It is a trade-off between transmission overhead and timely reception of the RLC status PDU.

[0180] As a result, if any enhancements are to be pursued to enable timely retransmission for XR traffic, it should be enhancements to the polling mechanism. Such enhancements to the polling mechanism could consider the delay criticality of the AMD PDU in the buffer. The advantages are that the polling is set only when required and it helps the Rx entity to send the RLC status report in a timely manner.

[0181] Pursue enhancements to the polling mechanism where the delay criticality of the AMD PDU is considered.

[0182] With the polling enhancements and upon receiving this RLC status report, the UE should also prioritize retransmissions for packets which are delay critical among those which are pending retransmission. Thus, RAN2 should also discuss the enhancements to the retransmission procedures upon receiving the RLC status report.

[0183] Consider enhancements to the retransmission procedure up on receiving the RLC status report based on the polling enhancements.

[0184] 2.3 Discussion on SA2 LS on AL-FEC

[0185] 2.3.1 General on AL-FEC in RAN

[0186] The solution depicted using AL-FEC is for discarding data in RAN. Related to this topic RAN2 introduced PDU Set dropping in Rel-18 with the purpose to discard all PDCP PDUs belonging to one PDU Set when the PDU Set will not be delivered on time to the receiver. The algorithms in which the gNB decide to discard PDU Sets are not specified; however, it can be understood that the gNB will assess whether it can deliver each PDU Set within the corresponding time budget before transmission of the PDU Set starts. Either all packets are attempted to be transmitted or none of them. Evaluations have shown that discarding only a few PDCP PDUs within a PDU Set does not result in any substantial benefit for the network. When looking at the FEC discarding solution, this non-beneficial scenario is the scenario targeted and there will thus be very small gains.

[0187] Furthermore, and more importantly, when the network is experiencing congestion, one of the worst solutions is that the application transmits redundant data such as FEC. Adding FEC information will always result in an increase of the congestion level in the network unless perfect discarding is applied. Such perfect discarding is unachievable with an FEC solution. Thus, queues will increase and so will delays. More PDU Sets may be dropped, and more applications and services will have to rate adapt down their bit rates. This will, in turn, result in poorer image quality and worse perceived service to the end user.

[0188] Therefore, as a principle, transmitting even more data in congestion situations, is not really justified and not desirable regardless of the underlying RAN protocols or configured RLC mode. In general, the best the application can do is to transmit the minimal amount of data for the given desired service quality and provide the corresponding PDU Set information specified in Release 18.

[0189] Observation 9 Adding redundant data has a negative impact on RAN performance and can be harmful to user experience.

[0190] 2.3.2 Discussion on Question 1

[0191] As outlined in 2.3.1, FEC or any other mechanism adding redundancy information is not desired, especially during congestion. Thus, RAN2 should not recommend the use of FEC. In fact, if redundancy information is added, the gNB will not be able to make use of the content ratio, or any other marking, as is explained below and there will be negative performance impacts.

[0192] A baseline principle is that in congestion, the NW will not want to transmit redundant information. In the context of FEC this means that, before the network transmits the additional FEC data, it should be very clear that not enough packets have been successfully received. That implies that the gNB should have received, when in RLC AM, an RLC status report message from the UE. It is obvious that, during congestion, the gNB will not be able to request RLC status reports often and, transmission of the RLC status report in the UL may take time. In any case until this information is obtained, the NW should not transmit the FEC content. However, when a negative status report is received, the RLC entity will anyway retransmit the failed packets. The network will continue retransmitting the initial packets and, thus, the additional FEC packets are of no help.

[0193] Observation 10 RLC AM will continue retransmission of the initial packets making the additional FEC packets redundant.

[0194] Additionally, as long as there is one packet in the head of the queue, other successive packets will not be transmitted. This means that buffered FEC packets of one PDU Set will negatively impact the following packets or PDU Sets and they will have less delay budget to be transmitted due to the buffered FEC packets blocking new transmissions.

[0195] Observation 11 Buffered FEC packets of a PDU set will negatively impact the subsequent packets or PDU sets due to head of the line blocking. For FEC packets to be of any use, they should be sent on time and that may imply that the NW will likely have to send them before receiving any status reports, i.e. no buffering as outlined above. This means that, anyway, the NW will transmit the complete PDU Set including FEC information and only when RLC ACKs are received, there is a possibility to move the transmitting or receiving window. However, at this point the transmissions cannot be stopped. All data which is in the MAC entity will continue being transmitted regardless of any RAN2 improvements done in Release 19.

[0196] Despite any potential RLC AM enhancements the content ratio for discarding will not improve XR performance but instead introduce additional packet delays or increased network load.

[0197] 2.3.2 Discussion on Question 2

[0198] The same answer as above applies: the gNB will not be able to make use of the content ratio or any other marking.

[0199] The main difference is that in RLC UM, there are no status reports and, thus, the transmitter side cannot know for sure if the packets were successfully transmitted. That would result in that FEC packets need to be transmitted too. All the problems outlined in earlier sections are still applicable also to RLC UM.

[0200] Content ratio or any other FEC information is of no use for the network regardless of the RLC mode configured by the NW.

[0201] 3 Conclusion

[0202] Based on the discussion in the previous sections, we have the following observations:

[0203] Observation 1 The local timer enables RLC to be aware of the SDUs relevance in the PDCP.

[0204] Observation 2 It is important to establish the applicability of autonomous retransmissions in the context of the discard timers. Observation 3 Autonomous retransmissions are only relevant for short discard timers.

[0205] Observation 4 For shorter discard timers, the Tx entity (under gNB control) can continue to perform blind HARO retransmissions (rather than triggering RLC retransmissions) thereby obtaining a 3 dB gain from soft combining.

[0206] Observation 5 For short discard timers, the efficacy of HARO retransmissions is higher than RLC retransmissions.

[0207] Observation 6 Gains with RLC retransmissions are onlv obtained for long discard timers. Observation 7 Autonomous retransmissions will be redundant 90% of the time and would consume 2x UL resources per UE, per RLC SDU retransmission. For example, if segmented into 4 AMD PDUs, a

[0208] UE would consume eight times the UL resources which would exacerbate UL congestion. Observation 8 The current polling mechanism cannot consider the delay criticality of the AMD PDU in the buffer. It is a trade-off between transmission overhead and timely reception of the RLC status PDU.

[0209] Observation 9 Adding redundant data has a negative impact on RAN performance and can be harmful to user experience.

[0210] Observation 10 RLC AM will continue retransmission of the initial packets making the additional FEC packets redundant.

[0211] Observation 11 Buffered FEC packets of a PDU set will negatively impact the subsequent packets or PDU sets due to head of the line blocking. Based on the discussion in the previous sections, we propose the following:

[0212] Proposal 1 The length of the new timer can be of the order of t-Reorderins.

[0213] Proposal 2 Local timer can be started when a higher RLC SN than RX Next has been delivered to the upper layers. Proposal 3 _ Local timer can be stopped / reset when RX Next Highest is equal to

[0214] RX Next.

[0215] Proposal 4 _ Upon expiry of the local timer, the Rx side informs the Tx side with an ACK in the RLC status report for the abandoned SDU.

[0216] Proposal 5 _ Proper network configuration of the local timer is sufficient to handle the control PDUs.

[0217] Proposal 6 _ As RLC performs out-of-order delivery to upper layers, no indication is needed from the Tx to Rx.

[0218] Proposal 7 _ For timely retransmissions, do not pursue autonomous retransmissions.

[0219] Proposal 8 _ Pursue enhancements to the polling mechanism where the delay criticality of the AMD PDU is considered.

[0220] Proposal 9 _ Consider enhancements to the retransmission procedure up on receiving the RLC status report based on the polling enhancements.

[0221] Proposal 10 Despite any potential RLC AM enhancements the content ratio for discarding will not improve XR performance but instead introduce additional packet delays or increased network load.

[0222] Proposal 11 Content ratio or any other FEC information is of no use for the network regardless of the RLC mode configured by the NW.

[0223] 5 TP - 38.323

[0224] 5.2.3.2 Receive operations

[0225] 5.2.3.2.1 General

[0226] The receiving side of an AM RLC entity shall maintain a receiving window according to the state variable RX_Next as follows:

[0227] - a SN falls within the receiving window if RX_Next <= SN < RX_Next + AM_Window_Size;

[0228] - a SN falls outside of the receiving window otherwise.

[0229] When receiving an AMD PDU from lower layer, the receiving side of an AM RLC entity shall: either discard the received AMD PDU or place it in the reception buffer (see clause 5.2.3.2.2); if the received AMD PDU was placed in the reception buffer: - update state variables, reassemble and deliver RLC SDUs to upper layer and start / stop t-Reassembly as needed (see clause 5.2.3.2.3).

[0230] When t -Reassembly expires, the receiving side of an AM RLC entity shall:

[0231] - update state variables and start t-Reassembly as needed (see clause 5.2.3.2.4).

[0232] 5.2.3.2.2 Actions when an AMD PDU is received from lower layer

[0233] When an AMD PDU is received from lower layer, where the AMD PDU contains byte segment numbers y to z of an RLC SDU with SN = x, the receiving side of an AM RLC entity shall:

[0234] - if x falls outside of the receiving window; or

[0235] - if byte segment numbers y to z of the RLC SDU with SN = x have been received before:

[0236] - discard the received AMD PDU.

[0237] - else:

[0238] - place the received AMD PDU in the reception buffer;

[0239] - if some byte segments of the RLC SDU contained in the AMD PDU have been received before:

[0240] - discard the duplicate byte segments.

[0241] 5.2.3.2.3 Actions when an AMD PDU is placed in the reception buffer

[0242] When an AMD PDU with SN = x is placed in the reception buffer, the receiving side of an AM RLC entity shall: if x >= RX_Next_Highest:

[0243] - update RX_Next_Highest to x+ 1. if all bytes of the RLC SDU with SN = x are received:

[0244] - reassemble the RLC SDU from AMD PDU(s) with SN = x, remove RLC headers when doing so and deliver the reassembled RLC SDU to upper layer;

[0245] - if x = RX Highest Status:

[0246] - update RX_Highest_Status to the SN of the first RLC SDU with SN > current RX Highest Status for which not all bytes have been received.

[0247] - ifx = RX_Next:

[0248] - update RX_Next to the SN of the first RLC SDU with SN > current RX_Next for which not all bytes have been received. if t-Reassembly is running:

[0249] - if RX_Next_Status_Trigger = RX_Next; or - if RX_Next_Status_Trigger = RX_Next + 1 and there is no missing byte segment of the SDU associated with SN = RX_Next before the last byte of all received segments of this SDU; or

[0250] - if RX_Next_Status_Trigger falls outside of the receiving window and RX_Next_Status_Trigger is not equal to RX_Next + AM_Window_Size:

[0251] - stop and reset t-Reassembfy. if t-Reassembfy is not running (includes the case t-Reassembfy is stopped due to actions above):

[0252] - if RX_Next_Highest> RX_Next +1 ; or

[0253] - if RX_Next_Highest = RX_Next + 1 and there is at least one missing byte segment of the SDU associated with SN = RX_Next before the last byte of all received segments of this SDU:

[0254] - start t-Reassembly,

[0255] - set RX_Next_Status_Trigger to RX_Next_Highest. if t-WinAdvance is running:

[0256] - if RX_Next_Highest = RX_Next; or

[0257] - if RX_Next_Highest = RX_Next + 1 and there is at least one missing byte segment of the SDU associated with SN = RX_Next before the last byte of all received segments of this SDU: stop and reset t-WinAdvance. if t-WinAdvance is not running (includes the case t-WinAdvance is stopped due to actions above):

[0258] - if RX_Next_Highest > RX_Next + 1 and at least one RLC SDU has been delivered to upper layer with SN > RX_NEXT; or

[0259] - start t-WinAdvance.

[0260] 5.2.3.2.4 Actions when t-Reassembfy expires

[0261] When t-Reassembfy expires, the receiving side of an AM RLC entity shall:

[0262] - update RX_Highest_Status to the SN of the first RLC SDU with SN >= RX_Next_Status_Trigger for which not all bytes have been received;

[0263] - if RX_Next_Highest> RX_Highest_Status +1: or

[0264] - if RX_Next_Highest = RX_Highest_Status + 1 and there is at least one missing byte segment of the SDU associated with SN = RX_Highest_Status before the last byte of all received segments of this SDU:

[0265] - start t-Reassembly, set RX_Next_Status_Trigger to RX_Next_Highest.

[0266] 5.2.3.2.4 Actions when t-WinAdvance expires

[0267] When t-WinAdvance expires, the receiving side of an AM RLC entity shall:

[0268] - update RX_Next to the SN of the first RLC SDU with SN > current RX_Next for which not all bytes have been received:

[0269] - start t-WinAdvance.

[0270] 5.3.4 Status reporting

[0271] An AM RLC entity sends STATUS PDUs to its peer AM RLC entity in order to provide positive and / or negative acknowledgements of RLC SDUs (or portions of them).

[0272] Triggers to initiate STATUS reporting include:

[0273] - Polling from its peer AM RLC entity:

[0274] - When an AMD PDU with SN = x and the P field set to "1" is received from lower layer, the receiving side of an AM RLC entity shall:

[0275] - if the AMD PDU is to be discarded as specified in clause 5.2.3.2.2; or

[0276] - if x < RX_Highest_Status or x >= RX_Next + AM_Window_Size:

[0277] - trigger a STATUS report.

[0278] - else:

[0279] - delay triggering the STATUS report until x < RX Highest Status or x >= RX_Next + AM_Window_Size.

[0280] NOTE 1 : This ensures that the RLC Status report is transmitted after HARQ reordering.

[0281] - Detection of reception failure of an AMD PDU

[0282] - The receiving side of an AM RLC entity shall trigger a STATUS report when t- Reassembfy expires.

[0283] NOTE 2: The expiry of t-Reassembly triggers both RX_Highest_Status to be updated and a STATUS report to be triggered, but the STATUS report shall be triggered after RX_Highest_Status is updated.

[0284] When STATUS reporting has been triggered, the receiving side of an AM RLC entity shall: if t-StatusProhibit is not running: - at the first transmission opportunity indicated by lower layer, construct a STATUS PDU and submit it to lower layer.

[0285] - else:

[0286] - at the first transmission opportunity indicated by lower layer after t-StatusProhibit expires, construct a single STATUS PDU even if status reporting was triggered several times while t-StatusProhibit was running and submit it to lower layer.

[0287] When a STATUS PDU has been submitted to lower layer, the receiving side of an AM RLC entity shall:

[0288] - start t-StatusProhibit .

[0289] When constructing a STATUS PDU, the AM RLC entity shall:

[0290] - for the RLC SDUs with SN such that RX_Next <= SN < RX_Highest_Status that has not been completely received yet, in increasing SN order of RLC SDUs and increasing byte segment order within RLC SDUs, starting with SN = RX_Next up to the point where the resulting STATUS PDU still fits to the total size of RLC PDU(s) indicated by lower layer:

[0291] - for an RLC SDU for which no byte segments have been received yet:

[0292] - include in the STATUS PDU a NACK_SN which is set to the SN of the RLC SDU.

[0293] - for a continuous sequence of byte segments of a partly received RLC SDU that have not been received yet:

[0294] - include in the STATUS PDU a set of NACK_SN, SOstart and SOend.

[0295] - for a continuous sequence of RLC SDUs that have not been received yet:

[0296] - include in the STATUS PDU a set of NACK_SN and NACK range;

[0297] - include in the STATUS PDU, if required, a pair of SOstart and SOend.

[0298] - set the ACK_SN to the SN of the next not received RLC SDU or the skipped SN due to t-WinAdvance expiry which is not indicated as missing in the resulting STATUS PDU.

[0299] As will be appreciated by one of skill in the art, the concepts described herein may be embodied as a method, data processing system, computer program product and / or computer storage media storing an executable computer program. Accordingly, the concepts described herein may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects all generally referred to herein as a “circuit” or “module.” Any process, step, action and / or functionality described herein may be performed by, and / or associated to, a corresponding module, which may be implemented in software and / or firmware and / or hardware. Furthermore, the disclosure may take the form of a computer program product on a tangible computer usable storage medium having computer program code embodied in the medium that can be executed by a computer. Any suitable tangible computer readable medium may be utilized including hard disks, CD-ROMs, electronic storage devices, optical storage devices, or magnetic storage devices.

[0300] Some embodiments are described herein with reference to flowchart illustrations and / or block diagrams of methods, systems and computer program products. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer (to thereby create a special purpose computer), special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions / acts specified in the flowchart and / or block diagram block or blocks.

[0301] These computer program instructions may also be stored in a computer readable memory or storage medium that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer readable memory produce an article of manufacture including instruction means which implement the function / act specified in the flowchart and / or block diagram block or blocks.

[0302] The computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions / acts specified in the flowchart and / or block diagram block or blocks.

[0303] It is to be understood that the functions / acts noted in the blocks may occur out of the order noted in the operational illustrations. For example, two blocks shown in succession may in fact be executed substantially concurrently or the blocks may sometimes be executed in the reverse order, depending upon the functionality / acts involved. Although some of the diagrams include arrows on communication paths to show a primary direction of communication, it is to be understood that communication may occur in the opposite direction to the depicted arrows.

[0304] Computer program code for carrying out operations of the concepts described herein may be written in an object oriented programming language such as Python, Java® or C++. However, the computer program code for carrying out operations of the disclosure may also be written in conventional procedural programming languages, such as the "C" programming language. The program code may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer. In the latter scenario, the remote computer may be connected to the user's computer through a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider).

[0305] Many different embodiments have been disclosed herein, in connection with the above description and the drawings. It will be understood that it would be unduly repetitious and obfuscating to literally describe and illustrate every combination and subcombination of these embodiments. Accordingly, all embodiments can be combined in any way and / or combination, and the present specification, including the drawings, shall be construed to constitute a complete written description of all combinations and subcombinations of the embodiments described herein, and of the manner and process of making and using them, and shall support claims to any such combination or subcombination.

[0306] It will be appreciated by persons skilled in the art that the embodiments described herein are not limited to what has been particularly shown and described herein above. In addition, unless mention was made above to the contrary, it should be noted that all of the accompanying drawings are not to scale. A variety of modifications and variations are possible in light of the above teachings and following claims.

Claims

What is claimed is:

1. A method implemented in a user equipment, UE, (22) that is configured to communicate with a network node (16), the method comprising: identifying (SI 20) a sequence number, SN, gap in a plurality of received packets; in response to identifying the SN gap, starting (SI 22) a timer; upon expiration of the timer, triggering (SI 24) delivery of packets received subsequent the SN gap and subsequently transmitting a feedback message; and considering (S126) the SN gap to be acknowledged-received.

2. The method of Claim 1, further comprising delivering subsequent PDUs until a next SN gap.

3. The method of any of Claims 1-2, further comprising one of: including a poll bit in an SN gap indication or considering a received SN gap indication as including the poll bit.

4. The method of Claim 3, further comprising retransmitting the poll bit and an SN drop indication upon expiration of a timer.

5. A user equipment, UE, (22) that is configured to communicate with a network node (16), the UE (22) comprising processing circuitry (50) configured to: identify a sequence number, SN, gap in a plurality of received packets; in response to identifying the SN gap, start a timer; upon expiration of the timer, trigger delivery of packets received subsequent the SN gap and subsequently transmit a feedback message; and consider the SN gap to be acknowledged-received.

6. The UE (22) of Claim 5, wherein the processing circuitry (50) is further configured to deliver subsequent PDUs until a next SN gap.

7. The UE (22) of any of Claims 5-6, wherein the processing circuitry (50) is further configured to one of: include a poll bit in an SN gap indication or consider a received SN gap indication as including the poll bit.

8. The UE (22) of Claim 7, wherein the processing circuitry (50) is further configured to retransmit the poll bit and an SN drop indication upon expiration of a timer.

9. A method implemented in a network node (16) that is configured to communicate with a user equipment, UE, (22), the method comprising: identifying (SI 12) a sequence number, SN, gap in a plurality of received packets; in response to identifying the SN gap, starting (SI 14) a timer; upon expiration of the timer, triggering (SI 16) delivery of packets received subsequent the SN gap and subsequently transmitting a feedback message; and considering (SI 18) the SN gap to be acknowledged-received.

10. The method of Claim 9, further comprising delivering subsequent PDUs until a next SN gap.

11. The method of any of Claims 9-10, further comprising one of: including a poll bit in an SN gap indication or considering a received SN gap indication as including the poll bit.

12. The method of Claim 11, further comprising retransmitting the poll bit and an SN drop indication upon expiration of a timer.

13. A network node (16) that is configured to communicate with a user equipment, UE, (22), the network node (16) comprising processing circuitry (36) configured to: identify a sequence number, SN, gap in a plurality of received packets; in response to identifying the SN gap, start a timer; upon expiration of the timer, trigger delivery of packets received subsequent the SN gap and subsequently transmit a feedback message; and consider the SN gap to be acknowledged-received.

14. The network node (16) of Claim 13, wherein the processing circuitry (36) is further configured to deliver subsequent PDUs until a next SN gap.

15. The network node (16) of any of Claims 13-14, wherein the processing circuitry (36) is further configured to one of: include a poll bit in an SN gap indication or consider a received SN gap indication as including the poll bit.

16. The network node (16) of Claim 15, wherein the processing circuitry (36) is further configured to retransmit the poll bit and an SN drop indication upon expiration of a timer.

Images