Avoid unnecessary retransmission of RLC pdu

Abstract

Various aspects of the present disclosure relate to avoiding unnecessary retransmission of an RLC PDU. In one aspect, a first RLC entity of a first communication device determines one of the following: a first RLC timer expires, a first indication is received from a first PDCP entity of the first communication device, or a first report is received from a second RLC entity of a second communication device. In turn, the first RLC entity updates a first state variable or determine at least one abandoned RLC SDU based on one of the following: expiration of the first RLC timer, the first indication, or the first report. The first state variable holds a value of a first SN following a last in-sequence completely received RLC SDU, and the first state variable serves as a lower edge of a receiving window of the first communication device.

Description

AVOID UNNECESSARY RETRANSMISSION OF RLC PDUTECHNICAL FIELD

[0001] The present disclosure relates to wireless communications, and more specifically to communication devices and methods performed by the communication devices for avoiding unnecessary retransmission of a radio link control (RLC) protocol data unit (PDU) .BACKGROUND

[0002] A wireless communications system may include one or multiple network communication devices, such as base stations, which may be otherwise known as an eNodeB (eNB) , a next-generation NodeB (gNB) , or other suitable terminology. Each network communication devices, such as a base station may support wireless communications for one or multiple user communication devices, which may be otherwise known as UE, or other suitable terminology. The wireless communications system may support wireless communications with one or multiple user communication devices by utilizing resources of the wireless communication system (e.g., time resources (e.g., symbols, slots, subframes, frames, or the like) or frequency resources (e.g., subcarriers, carriers) . Additionally, the wireless communications system may support wireless communications across various radio access technologies including third generation (3G) radio access technology, fourth generation (4G) radio access technology, fifth generation (5G) radio access technology, among other suitable radio access technologies beyond 5G (e.g., sixth generation (6G) ) .

[0003] In legacy RLC, if an RLC SDU has been discarded at a receiving packet data convergence protocol (PDCP) entity and has been submitted to lower layer, the RLC SDU will not be discarded at a receiving RLC entity. And if the receiving PDCP entity has updated a receiving window due to expiration of a PDCP reordering timer, the later received data with a PDCP sequence number (SN) lower than RX_DELIV will be abandoned. Therefore, the later received data is unnecessary to be retransmitted. However, discarding an obsoleted RLC SDU already submitted to lower layer will cause RLC SN gap, and RLC acknowledged mode (AM) window stalling will occur at both transmitting side and receiving side of RLC AM. Thus, there is a need to discuss how to support avoiding unnecessary retransmission of an RLC PDU.SUMMARY

[0004] The present disclosure relates to communication devices and methods that support avoiding unnecessary retransmission of an RLC PDU. The communication devices and methods may avoid unnecessary retransmission of an RLC PDU.

[0005] Some implementations of a first communication device described herein may include a processor and a transceiver coupled to the processor, wherein the processor is configured to: determine one of the following at a first RLC entity of the first communication device: a first RLC timer expires, a first indication is received from a first PDCP entity of the first communication device, or a first report is received from a second RLC entity of a second communication device; and update a first state variable or determine at least one abandoned RLC SDU based on one of the following: expiration of the first RLC timer, the first indication, or the first report. The first state variable holds a value of a first SN following a last in-sequence completely received RLC SDU, and the first state variable serves as a lower edge of a receiving window of the first communication device.

[0006] In some implementations, the processor is further configured to: based on determining that a first RLC SDU with an SN greater than the first state variable is received, start the first RLC timer, and set a second state variable to a third state variable, wherein the second state variable holds a value of a second SN following the SN of the RLC SDU which triggered the first RLC timer, and the third state variable holds a value of a third SN following an SN of a second RLC SDU with a highest SN among received RLC SDUs.

[0007] In some implementations, the processor is further configured to: update the first state variable to an SN of a start RLC SDU with the SN equal to or greater than the second state variable, wherein not all bytes of the start RLC SDU have been received by the first communication device.

[0008] In some implementations, the processor is configured to update the first state variable further based on determining one of the following: the first state variable is equal to one of at least one RLC SN of the at least one abandoned RLC SDU, or the first state variable is equal to or less than the SN of a reference RLC SDU.

[0009] In some implementations, the processor is further configured to determine that the first RLC SDU with the SN greater than the first state variable is received by: determining that the third state variable is greater than the first state variable.

[0010] In some implementations, the processor is further configured to: update a fourth state variable to an SN of a start RLC SDU with the SN greater than the fourth state variable, wherein not all bytes of the start RLC SDU have been received by the first communication device, and the fourth state variable holds a highest possible value of an SN which can be indicated by a field in a STATUS protocol data unit (PDU) when the STATUS PDU needs to be constructed, the field indicates an SN of a next not received RLC SDU which is not reported as missing in the STATUS PDU.

[0011] In some implementations, the processor is configured to update the fourth state variable to the SN of the start RLC SDU with the SN greater than the fourth state variable based on determining one of the following: the fourth state variable is equal to one of at least one RLC SN of the at least one abandoned RLC SDU, or the fourth state variable is equal to or less than the first state variable.

[0012] In some implementations, the processor is further configured to perform one of the following after updating the first state variable: stop a second RLC timer based on the first state variable and a fifth state variable, wherein the fifth state variable holds a value of an SN following an SN of a third RLC SDU which triggered the second RLC timer, the second timer is used by the first RLC entity to detect loss of RLC PDUs at a lower layer of the first communication device; or based on determining that the third state variable is greater than the first state variable, start the second RLC timer and set the fifth state variable to the third state variable.

[0013] In some implementations, the processor is further configured to perform at least one of the following before the first RLC timer expires: stop the first RLC timer based on determining that a fourth RLC SDU with an SN equal to the second state variable is received and the SN is equal to the first state variable.

[0014] In some implementations, the processor is further configured to: transmit a second report via the transceiver to the second communication device, wherein the second report indicates a reference RLC SDU via an RLC SN or indicates the at least one abandoned RLC SDU.

[0015] In some implementations, the RLC SN of the reference RLC SDU is equal to the first state variable.

[0016] In some implementations, at least one SN of the at least one abandoned RLC SDU is less than the updated first state variable.

[0017] In some implementations, the processor is further configured to: transmit a second report via the transceiver to the second communication device, In some implementations, the second report is a STATUS PDU, the STATUS PDU is used by the first entity to inform the second RLC entity about at least one RLC data PDU that is received successfully, and / or at least one RLC data PDU that has not been completely received except that has not been abandoned.

[0018] In some implementations, an SN of the at least one RLC data PDU is equal to or greater than the updated first state variable and less than a fourth state variable, the fourth state variable holds a highest possible value of an SN which can be indicated by a field in the STATUS PDU when the STATUS PDU needs to be constructed, the field indicates an SN of a next not received RLC SDU which is not reported as missing in the STATUS PDU.

[0019] In some implementations, the second report is triggered based on determining at least one of the following: the at least one abandoned RLC SDU is determined; the at least one abandoned RLC SDU has not been reported in a second report; or the first state variable is updated.

[0020] In some implementations, the at least one abandoned RLC SDU comprises multiple abandoned RLC SDUs, the second report comprises a first filed, the first filed indicates a start abandoned RLC SDU among the multiple abandoned RLC SDUs.

[0021] In some implementations, the second report further comprises a bitmap field, each of bits in the bitmap field is associated with an RLC SDU and indicates whether the RLC SDU is abandoned at the first RLC entity.

[0022] In some implementations, a least significant bit or a most significant bit of the bitmap field is associated with the start abandoned RLC SDU.

[0023] In some implementations, the at least one abandoned RLC SDU comprises multiple abandoned RLC SDUs, the second report comprises at least one second filed, each of the at least one second filed indicates one of the multiple abandoned RLC SDUs.

[0024] In some implementations, the second report further comprises an abandon range field, the abandon range field indicates the number of abandoned RLC SDUs in a continuous sequence of abandoned RLC SDUs starting from an abandoned RLC SDU indicated by one of the at least one second field, the abandon range field follows the one of the at least one second field.

[0025] In some implementations, the processor is further configured to construct the second report by: for the multiple abandoned RLC SDUs with SNs such that the SNs less than the first state variable that have not been completely received yet, in increasing SN order of the abandoned RLC SDUs, starting with an RLC SN of a start abandoned RLC SDU among the multiple abandoned RLC SDUs, for which that have not been completely received yet and have not reported, up to a point where the resulting second report still fits to a total size of the multiple abandoned RLC SDUs indicated by a lower layer of the first communication device: first including in the second report one of the at least one second field which is set to an SN of a start abandoned RLC SDU among the abandoned RLC SDUs for which no byte segments or partly have been received yet, and then including in the second report a further one of the at least one second field and the abandon range field for the continuous sequence of the abandoned RLC SDUs that have not been received yet.

[0026] In some implementations, the second report further comprises a field, wherein the field indicates an SN of a next not received RLC SDU which is not reported as missing in the second report.

[0027] In some implementations, the processor is configured to start the first RLC timer by: based on determining that the first RLC SDU comprises a PDCP data SDU, starting the first RLC timer.

[0028] In some implementations, the first indication indicates a reference RLC SDU or the at least one abandoned RLC SDU.

[0029] In some implementations, the reference RLC SDU corresponds to a PDCP PDU with a PDCP SN equal to a seventh state variable; and wherein the seventh state  variable indicates a COUNT value of a start PDCP SDU which is not delivered to upper layers of the first communication device but still waited for.

[0030] In some implementations, the processor is configured to: maintain mapping between an RLC SN and a PDCP SN for an RLC SDU.

[0031] In some implementations, the processor is configured to: deliver an RLC SDU to the first PDCP entity with an RLC SN of the RLC SDU.

[0032] In some implementations, the first report comprises a PDCP SN gap report.

[0033] In some implementations, the first indication indicates a reference PDCP protocol data unit (PDU) or at least one abandoned PDCP PDU corresponding to the at least one abandoned RLC SDU.

[0034] In some implementations, the reference PDCP PDU has a PDCP SN equal to a seventh state variable; and wherein the seventh state variable indicates a COUNT value of a start PDCP SDU which is not delivered to upper layers of the first communication device but still waited for.

[0035] In some implementations, the first indication indicates one of the following: an RLC SN of an abandoned RLC SDU, a PDCP SN of an abandoned PDCP PDU, a reference RLC SN, or a reference PDCP SN.

[0036] In some implementations, the processor is further configured to receive a configuration from the second communication device, wherein the configuration indicates at least one of the following: the first RLC timer per RLC entity; transmission of the first indication per PDCP entity; transmission of the first report per RLC entity; delivery of an RLC SN to the first PDCP entity; or maintaining mapping between an RLC SN and a PDCP SN for an RLC SDU.

[0037] Some implementations of a second communication device described herein may include a processor and a transceiver coupled to the processor, wherein the processor is configured to: determine, at a second RLC entity of the second communication device, at least one of a second report from a first RLC entity of a first communication device or a discard indication from a second PDCP entity of the second communication device is received; and update a six state variable based on the second report or the discard indication, wherein the six state variable holds a value of an SN of a next RLC SDU for  which a positive acknowledgment is to be received in-sequence, and the six state variable serves as a lower edge of a transmitting window of the second communication device.

[0038] In some implementations, the second report indicates a reference RLC SDU via an RLC SN or indicates at least one abandoned RLC SDU.

[0039] In some implementations, the RLC SN of the reference RLC SDU is equal to a first state variable, the first state variable holds a value of a first SN following a last in-sequence completely received RLC SDU, and the first state variable serves as a lower edge of a receiving window of the first communication device.

[0040] In some implementations, the processor is further configured to: generate a protocol data unit (PDU) for an abandoned RLC SDU including a PDCP control PDU.

[0041] In some implementations, the processor is further configured to: transmit a second indication from the second RLC entity to the second PDCP entity, wherein the second indication indicates at least one abandoned RLC SDU or at least one abandoned PDCP PDU.

[0042] In some implementations, the processor is further configured to: receive, at the second RLC entity from the second PDCP entity, a PDU for an abandoned RLC SDU including a PDCP control PDU.

[0043] Some implementations of a second communication device described herein may include a processor and a transceiver coupled to the processor, wherein the processor is configured to: transmit a PDCP SN gap report from a second PDCP entity of the second communication device to a first PDCP entity of a first communication device or transmit a discard indication from the second PDCP entity to a second RLC entity of the second communication device; receive a discard indication from the second RLC entity, wherein the discard indication indicates at least one abandoned PDCP PDU; generate a PDU for an abandoned RLC SDU including a PDCP control PDU; and transmit the PDU to the second RLC entity.

[0044] Some implementations of a method described herein may include: determining one of the following at a first RLC entity of the first communication device: a first RLC timer expires, a first indication is received from a first PDCP entity of the first communication device, or a first report is received from a second RLC entity of a second communication device; and updating a first state variable or determine at least one  abandoned RLC SDU based on one of the following: expiration of the first RLC timer, the first indication, or the first report. The first state variable holds a value of a first SN following a last in-sequence completely received RLC SDU, and the first state variable serves as a lower edge of a receiving window of the first communication device.

[0045] Some implementations of a method described herein may include: determining, at a second RLC entity of a second communication device, at least one of a second report from a first RLC entity of a first communication device or a discard indication from a second PDCP entity of the second communication device is received; and updating a six state variable based on the second report or the discard indication, wherein the six state variable holds a value of a SN of a next RLC SDU for which a positive acknowledgment is to be received in-sequence, and the six state variable serves as a lower edge of a transmitting window of the second communication device.

[0046] Some implementations of a method described herein may include: transmitting a PDCP SN gap report from a second PDCP entity of the second communication device to a first PDCP entity of a first communication device or transmitting a discard indication from the second PDCP entity to a second RLC entity of the second communication device; receiving a discard indication from the second RLC entity, wherein the discard indication indicates at least one abandoned PDCP PDU; generating a PDU for an abandoned RLC SDU including a PDCP control PDU; and transmitting the PDU to the second RLC entity.

[0047] Some implementations of a processor described herein may include at least one memory and a controller coupled with the at least one memory and configured to cause the controller to: determine one of the following at a first RLC entity of the first communication device: a first RLC timer expires, a first indication is received from a first PDCP entity of the first communication device, or a first report is received from a second RLC entity of a second communication device; and update a first state variable or determine at least one abandoned RLC SDU based on one of the following: expiration of the first RLC timer, the first indication, or the first report. The first state variable holds a value of a first SN following a last in-sequence completely received RLC SDU, and the first state variable serves as a lower edge of a receiving window of the first communication device.

[0048] Some implementations of a processor described herein may include at least one memory and a controller coupled with the at least one memory and configured to cause the controller to: determine, at a second RLC entity of the second communication device, at least one of a second report from a first RLC entity of a first communication device or a discard indication from a second PDCP entity of the second communication device is received; and update a six state variable based on the second report or the discard indication, wherein the six state variable holds a value of an SN of a next RLC SDU for which a positive acknowledgment is to be received in-sequence, and the six state variable serves as a lower edge of a transmitting window of the second communication device.

[0049] Some implementations of a processor described herein may include at least one memory and a controller coupled with the at least one memory and configured to cause the controller to: transmit a PDCP SN gap report from a second PDCP entity of a second communication device to a first PDCP entity of a first communication device or transmit a discard indication from the second PDCP entity to a second RLC entity of the second communication device; receive a discard indication from the second RLC entity, wherein the discard indication indicates at least one abandoned PDCP PDU; generate a PDU for an abandoned RLC SDU including a PDCP control PDU; and transmit the PDU to the second RLC entity.

[0050] It is to be understood that the summary section is not intended to identify key or essential features of embodiments of the present disclosure, nor is it intended to be used to limit the scope of the present disclosure. Other features of the present disclosure will become easily comprehensible through the following description.BRIEF DESCRIPTION OF THE DRAWINGS

[0051] Fig. 1 illustrates an example of a wireless communications system that supports avoiding unnecessary retransmission of an RLC PDU in accordance with aspects of the present disclosure;

[0052] Fig. 2 illustrates an example of updating receiving windows in accordance with a conventional solution;

[0053] Fig. 3 illustrates another example of a wireless communications system that supports avoiding unnecessary retransmission of an RLC PDU in accordance with aspects of the present disclosure;

[0054] Fig. 4 illustrates a signaling diagram illustrating an example process that supports avoiding unnecessary retransmission of an RLC PDU in accordance with aspects of the present disclosure;

[0055] Fig. 5 illustrates a signaling diagram illustrating an example process that supports avoiding unnecessary retransmission of an RLC PDU in accordance with aspects of the present disclosure;

[0056] Fig. 6 illustrates an example of updating a second state variable in accordance with aspects of the present disclosure;

[0057] Figs. 7 to 11 illustrate an example of an RLC control PDU in accordance with aspects of the present disclosure, respectively;

[0058] Figs. 12 and 13 illustrate an example of an STATUS PDU in accordance with aspects of the present disclosure, respectively;

[0059] Fig. 14 illustrates a signaling diagram illustrating an example process that supports avoiding unnecessary retransmission of an RLC PDU in accordance with aspects of the present disclosure;

[0060] Figs. 15 and 16 illustrate an example of updating a first state variable in accordance with aspects of the present disclosure, respectively;

[0061] Figs. 17 and 18 illustrate a signaling diagram illustrating an example process that supports avoiding unnecessary retransmission of an RLC PDU in accordance with aspects of the present disclosure, respectively;

[0062] Fig. 19 illustrates an example of a device that supports avoiding unnecessary retransmission of an RLC PDU in accordance with some aspects of the present disclosure;

[0063] Fig. 20 illustrates an example of a processor that supports avoiding unnecessary retransmission of an RLC PDU in accordance with aspects of the present disclosure; and

[0064] Figs. 21 and 22 illustrate a flowchart of a method that supports avoiding unnecessary retransmission of an RLC PDU in accordance with aspects of the present disclosure, respectively.DETAILED DESCRIPTION

[0065] Principles of the present disclosure will now be described with reference to some embodiments. It is to be understood that these embodiments are described only for the purpose of illustration and help those skilled in the art to understand and implement the present disclosure, without suggesting any limitation as to the scope of the disclosure. The disclosure described herein may be implemented in various manners other than the ones described below.

[0066] In the following description and claims, unless defined otherwise, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skills in the art to which this disclosure belongs.

[0067] References in the present disclosure to “one embodiment, ” “an example embodiment, ” “an embodiment, ” “some embodiments, ” and the like indicate that the embodiment (s) described may include a particular feature, structure, or characteristic, but it is not necessary that every embodiment includes the particular feature, structure, or characteristic. Moreover, such phrases do not necessarily refer to the same embodiment (s) . Further, when a particular feature, structure, or characteristic is described in connection with an embodiment, it is submitted that it is within the knowledge of one skilled in the art to affect such feature, structure, or characteristic in connection with other embodiments whether or not explicitly described.

[0068] It shall be understood that although the terms “first” and “second” or the like may be used herein to describe various elements, these elements should not be limited by these terms. These terms are only used to distinguish one element from another element. For example, a first element could also be termed as a second element, and similarly, a second element could also be termed as a first element, without departing from the scope of embodiments. As used herein, the term “and / or” includes any and all combinations of one or more of the listed terms.

[0069] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of example embodiments. 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” , “has” , “having” , “includes” and / or “including” , when used herein, specify the presence of stated features, elements, and / or components etc., but  do not preclude the presence or addition of one or more other features, elements, components and / or combinations thereof.

[0070] Aspects of the present disclosure are described in the context of a wireless communications system.

[0071] Fig. 1 illustrates an example of a wireless communications system 100 that supports avoiding unnecessary retransmission of an RLC PDU in accordance with aspects of the present disclosure. The wireless communications system 100 may include one at least one of network entities 102 (also referred to as network equipment (NE) ) , one or more terminal devices or UEs 104, a core network 106, and a packet data network 108. The wireless communications system 100 may support various radio access technologies. In some implementations, the wireless communications system 100 may be a 4G network, such as an LTE network or an LTE-advanced (LTE-A) network. In some other implementations, the wireless communications system 100 may be a 5G network, such as an NR network. In other implementations, the wireless communications system 100 may be a combination of a 4G network and a 5G network, or other suitable radio access technology including institute of electrical and electronics engineers (IEEE) 802.11 (Wi-Fi) , IEEE 802.16 (WiMAX) , IEEE 802.20. The wireless communications system 100 may support radio access technologies beyond 5G. Additionally, the wireless communications system 100 may support technologies, such as time division multiple access (TDMA) , frequency division multiple access (FDMA) , or code division multiple access (CDMA) , etc.

[0072] The network entities 102 may be dispersed throughout a geographic region to form the wireless communications system 100. One or more of the network entities 102 described herein may be or include or may be referred to as a network node, a base station (BS) , a network element, a radio access network (RAN) node, a base transceiver station, an access point, a NodeB, an eNodeB (eNB) , a next-generation NodeB (gNB) , or other suitable terminology. A network entity 102 and a UE 104 may communicate via a communication link 110, which may be a wireless or wired connection. For example, a network entity 102 and a UE 104 may perform wireless communication (e.g., receive signaling, transmit signaling) over a Uu interface. The network entities 102 may be collectively referred to as network entities 102 or individually referred to as a network entity 102.

[0073] A network entity 102 may provide a geographic coverage area 112 for which the network entity 102 may support services (e.g., voice, video, packet data, messaging, broadcast, etc. ) for one or more UEs 104 within the geographic coverage area 112. For example, a network entity 102 and a UE 104 may support wireless communication of signals related to services (e.g., voice, video, packet data, messaging, broadcast, etc. ) according to one or multiple radio access technologies. In some implementations, a network entity 102 may be moveable, for example, a satellite associated with a non-terrestrial network. In some implementations, different geographic coverage areas 112 associated with the same or different radio access technologies may overlap, but the different geographic coverage areas 112 may be associated with different network entities 102. Information and signals described herein may be represented using any of a variety of different technologies and techniques. For example, data, instructions, commands, information, signals, bits, symbols, and chips that may be referenced throughout the description may be represented by voltages, currents, electromagnetic waves, magnetic fields or particles, optical fields or particles, or any combination thereof.

[0074] The one or more UEs 104 may be dispersed throughout a geographic region of the wireless communications system 100. A UE 104 may include or may be referred to as a mobile device, a wireless device, a remote device, a remote unit, a handheld device, or a subscriber device, or some other suitable terminology. In some implementations, the UE 104 may be referred to as a unit, a station, a terminal, or a client, among other examples. Additionally, or alternatively, the UE 104 may be referred to as an internet-of-things (IoT) device, an internet-of-everything (IoE) device, or machine-type communication (MTC) device, among other examples. In some implementations, a UE 104 may be stationary in the wireless communications system 100. In some other implementations, a UE 104 may be mobile in the wireless communications system 100.

[0075] The one or more UEs 104 may be devices in different forms or having different capabilities. Some examples of UEs 104 are illustrated in Fig. 1. A UE 104 may be capable of communicating with various types of devices, such as the network entities 102, other UEs 104, or network equipment (e.g., the core network 106, the packet data network 108, a relay device, an integrated access and backhaul (IAB) node, or another network equipment) , as shown in Fig. 1. Additionally, or alternatively, a UE 104 may support communication with other network entities 102 or UEs 104, which may act as relays in the wireless communications system 100.

[0076] A UE 104 may also be able to support wireless communication directly with other UEs 104 over a communication link 114. For example, a UE 104 may support wireless communication directly with another UE 104 over a device-to-device (D2D) communication link. In some implementations, such as vehicle-to-vehicle (V2V) deployments, vehicle-to-everything (V2X) deployments, or cellular-V2X deployments, the communication link 114 may be referred to as a sidelink. For example, a UE 104 may support wireless communication directly with another UE 104 over a PC5 interface.

[0077] A network entity 102 may support communications with the core network 106, or with another network entity 102, or both. For example, a network entity 102 may interface with the core network 106 through one or more backhaul links 116 (e.g., via an S1, N2, N2, or another network interface) . The network entities 102 may communicate with each other over the backhaul links 116 (e.g., via an X2, Xn, or another network interface) . In some implementations, the network entities 102 may communicate with each other directly (e.g., between the network entities 102) . In some other implementations, the network entities 102 may communicate with each other or indirectly (e.g., via the core network 106) . In some implementations, one or more network entities 102 may include subcomponents, such as an access network entity, which may be an example of an access node controller (ANC) . An ANC may communicate with the one or more UEs 104 through one or more other access network transmission entities, which may be referred to as a radio heads, smart radio heads, or transmission-reception points (TRPs) .

[0078] In some implementations, a network entity 102 may be configured in a disaggregated architecture, which may be configured to utilize a protocol stack physically or logically distributed among two or more network entities 102, such as an integrated access backhaul (IAB) network, an open radio access network (O-RAN) (e.g., a network configuration sponsored by the O-RAN Alliance) , or a virtualized RAN (vRAN) (e.g., a cloud RAN (C-RAN) ) . For example, a network entity 102 may include one or more of a central unit (CU) , a distributed unit (DU) , a radio unit (RU) , a RAN intelligent controller (RIC) (e.g., a near-real time RIC (Near-RT RIC) , a non-real time RIC (Non-RT RIC) ) , a service management and orchestration (SMO) system, or any combination thereof.

[0079] An RU may also be referred to as a radio head, a smart radio head, a remote radio head (RRH) , a remote radio unit (RRU) , or a transmission reception point (TRP) .  One or more components of the network entities 102 in a disaggregated RAN architecture may be co-located, or one or more components of the network entities 102 may be located in distributed locations (e.g., separate physical locations) . In some implementations, one or more network entities 102 of a disaggregated RAN architecture may be implemented as virtual units (e.g., a virtual CU (VCU) , a virtual DU (VDU) , a virtual RU (VRU) ) .

[0080] Split of functionality between a CU, a DU, and an RU may be flexible and may support different functionalities depending upon which functions (e.g., network layer functions, protocol layer functions, baseband functions, radio frequency functions, and any combinations thereof) are performed at a CU, a DU, or an RU. For example, a functional split of a protocol stack may be employed between a CU and a DU such that the CU may support one or more layers of the protocol stack and the DU may support one or more different layers of the protocol stack. In some implementations, the CU may host upper protocol layer (e.g., a layer 3 (L3) , a layer 2 (L2) ) functionality and signaling (e.g., radio resource control (RRC) , service data adaption protocol (SDAP) , packet data convergence protocol (PDCP) ) . The CU may be connected to one or more DUs or RUs, and the one or more DUs or RUs may host lower protocol layers, such as a layer 1 (L1) (e.g., physical (PHY) layer) or an L2 (e.g., radio link control (RLC) layer, medium access control (MAC) layer) functionality and signaling, and may each be at least partially controlled by the CU.

[0081] Additionally, or alternatively, a functional split of the protocol stack may be employed between a DU and an RU such that the DU may support one or more layers of the protocol stack and the RU may support one or more different layers of the protocol stack. The DU may support one or multiple different cells (e.g., via one or more RUs) . In some implementations, a functional split between a CU and a DU, or between a DU and an RU may be within a protocol layer (e.g., some functions for a protocol layer may be performed by one of a CU, a DU, or an RU, while other functions of the protocol layer are performed by a different one of the CU, the DU, or the RU) .

[0082] A CU may be functionally split further into CU control plane (CU-CP) and CU user plane (CU-UP) functions. A CU may be connected to one or more DUs via a midhaul communication link (e.g., F1, F1-c, F1-u) , and a DU may be connected to one or more RUs via a fronthaul communication link (e.g., open fronthaul (FH) interface) . In some implementations, a midhaul communication link or a fronthaul communication link  may be implemented in accordance with an interface (e.g., a channel) between layers of a protocol stack supported by respective network entities 102 that are in communication via such communication links.

[0083] The core network 106 may support user authentication, access authorization, tracking, connectivity, and other access, routing, or mobility functions. The core network 106 may be an evolved packet core (EPC) , or a 5G core (5GC) , which may include a control plane entity that manages access and mobility (e.g., a mobility management entity (MME) , an access and mobility management functions (AMF) ) and a user plane entity that routes packets or interconnects to external networks (e.g., a serving gateway (S-GW) , a packet data network (PDN) gateway (P-GW) , or a user plane function (UPF) ) . In some implementations, the control plane entity may manage non-access stratum (NAS) functions, such as mobility, authentication, and bearer management (e.g., data bearers, signal bearers, etc. ) for the one or more UEs 104 served by the one or more network entities 102 associated with the core network 106.

[0084] The core network 106 may communicate with the packet data network 108 over one or more backhaul links 116 (e.g., via an S1, N2, N2, or another network interface) . The packet data network 108 may include an application server 118. In some implementations, one or more UEs 104 may communicate with the application server 118. A UE 104 may establish a session (e.g., a protocol data unit (PDU) session, or the like) with the core network 106 via a network entity 102. The core network 106 may route traffic (e.g., control information, data, and the like) between the UE 104 and the application server 118 using the established session (e.g., the established PDU session) . The PDU session may be an example of a logical connection between the UE 104 and the core network 106 (e.g., one or more network functions of the core network 106) .

[0085] In the wireless communications system 100, the network entities 102 and the UEs 104 may use resources of the wireless communications system 100 (e.g., time resources (e.g., symbols, slots, subframes, frames, or the like) or frequency resources (e.g., subcarriers, carriers) ) to perform various operations (e.g., wireless communications) . In some implementations, the network entities 102 and the UEs 104 may support different resource structures. For example, the network entities 102 and the UEs 104 may support different frame structures. In some implementations, such as in 4G, the network entities 102 and the UEs 104 may support a single frame structure. In some other implementations,  such as in 5G and among other suitable radio access technologies, the network entities 102 and the UEs 104 may support various frame structures (i.e., multiple frame structures) . The network entities 102 and the UEs 104 may support various frame structures based on one or more numerologies.

[0086] One or more numerologies may be supported in the wireless communications system 100, and a numerology may include a subcarrier spacing and a cyclic prefix. A first numerology (e.g., μ=0) may be associated with a first subcarrier spacing (e.g., 15 kHz) and a normal cyclic prefix. In some implementations, the first numerology (e.g., μ=0) associated with the first subcarrier spacing (e.g., 15 kHz) may utilize one slot per subframe. A second numerology (e.g., μ=1) may be associated with a second subcarrier spacing (e.g., 30 kHz) and a normal cyclic prefix. A third numerology (e.g., μ=2) may be associated with a third subcarrier spacing (e.g., 60 kHz) and a normal cyclic prefix or an extended cyclic prefix. A fourth numerology (e.g., μ=3) may be associated with a fourth subcarrier spacing (e.g., 120 kHz) and a normal cyclic prefix. A fifth numerology (e.g., μ=4) may be associated with a fifth subcarrier spacing (e.g., 240 kHz) and a normal cyclic prefix.

[0087] A time interval of a resource (e.g., a communication resource) may be organized according to frames (also referred to as radio frames) . Each frame may have a duration, for example, a 10 millisecond (ms) duration. In some implementations, each frame may include multiple subframes. For example, each frame may include 10 subframes, and each subframe may have a duration, for example, a 1 ms duration. In some implementations, each frame may have the same duration. In some implementations, each subframe of a frame may have the same duration.

[0088] Additionally or alternatively, a time interval of a resource (e.g., a communication resource) may be organized according to slots. For example, a subframe may include a number (e.g., quantity) of slots. The number of slots in each subframe may also depend on the one or more numerologies supported in the wireless communications system 100. For instance, the first, second, third, fourth, and fifth numerologies (i.e., μ=0, μ=1, μ=2, μ=3, μ=4) associated with respective subcarrier spacings of 15 kHz, 30 kHz, 60 kHz, 120 kHz, and 240 kHz may utilize a single slot per subframe, two slots per subframe, four slots per subframe, eight slots per subframe, and 16 slots per subframe, respectively. Each slot may include a number (e.g., quantity) of symbols (e.g., OFDM  symbols) . In some implementations, the number (e.g., quantity) of slots for a subframe may depend on a numerology. For a normal cyclic prefix, a slot may include 14 symbols. For an extended cyclic prefix (e.g., applicable for 60 kHz subcarrier spacing) , a slot may include 12 symbols. The relationship between the number of symbols per slot, the number of slots per subframe, and the number of slots per frame for a normal cyclic prefix and an extended cyclic prefix may depend on a numerology. It should be understood that reference to a first numerology (e.g., μ=0) associated with a first subcarrier spacing (e.g., 15 kHz) may be used interchangeably between subframes and slots.

[0089] In the wireless communications system 100, an electromagnetic (EM) spectrum may be split, based on frequency or wavelength, into various classes, frequency bands, frequency channels, etc. By way of example, the wireless communications system 100 may support one or multiple operating frequency bands, such as frequency range designations FR1 (410 MHz –7.125 GHz) , FR2 (24.25 GHz –52.6 GHz) , FR3 (7.125 GHz –24.25 GHz) , FR4 (52.6 GHz –114.25 GHz) , FR4a or FR4-1 (52.6 GHz –71 GHz) , and FR5 (114.25 GHz –300 GHz) . In some implementations, the network entities 102 and the UEs 104 may perform wireless communications over one or more of the operating frequency bands. In some implementations, FR1 may be used by the network entities 102 and the UEs 104, among other equipment or devices for cellular communications traffic (e.g., control information, data) . In some implementations, FR2 may be used by the network entities 102 and the UEs 104, among other equipment or devices for short-range, high data rate capabilities.

[0090] FR1 may be associated with one or multiple numerologies (e.g., at least three numerologies) . For example, FR1 may be associated with a first numerology (e.g., μ=0) , which includes 15 kHz subcarrier spacing; a second numerology (e.g., μ=1) , which includes 30 kHz subcarrier spacing; and a third numerology (e.g., μ=2) , which includes 60 kHz subcarrier spacing. FR2 may be associated with one or multiple numerologies (e.g., at least 2 numerologies) . For example, FR2 may be associated with a third numerology (e.g., μ=2) , which includes 60 kHz subcarrier spacing; and a fourth numerology (e.g., μ=3) , which includes 120 kHz subcarrier spacing.

[0091] Fig. 2 illustrates an example of updating receiving windows in accordance with a conventional solution. In the example of Fig. 2, a receiving PDCP entity of a receiving device maintains a receiving window 210, and a receiving RLC entity of the receiving device maintains a receiving window 220. A transmitting device transmits  packets with PDCP SNs #1, #2, #3, #4, #5 and #6 to the receiving device. The packets with PDCP SNs #1, #3, #4 and #6 are received by the receiving device and the packets with PDCP SNs #2 and #5 are not completely received by the receiving device. Thus, the receiving PDCP entity updates RX_DELIV to 2 and starts a reordering timer. RX_DELIV indicates a COUNT value of the first PDCP SDU not delivered to the upper layers, but still waited for. The receiving RLC entity updates RX_Next to 2. RX_Next holds a value of an SN following the last in-sequence completely received RLC SDU, and it serves as the lower edge of the receiving window 220.

[0092] When the reordering timer expires, the receiving PDCP entity will update the receiving window 210 by updating RX_DELIV to 5 while the receiving RLC entity keeps RX_Next unchanged.

[0093] Later, the packet with PDCP SN #2 is retransmitted to the receiving device. Upon receiving the packet with PDCP SN #2, the receiving RLC entity delivers the packet with PDCP SN #2 to the receiving PDCP entity. Because PDCP SN #2 is lower than RX_DELIV (i.e., 5) , the receiving PDCP entity will abandon the packet with PDCP SN #2.Therefore, retransmission of the packet with PDCP SN #2 is unnecessary. Thus, there is a need to discuss how to support avoiding unnecessary retransmission of an RLC PDU.

[0094] In view of the above, the present disclosure provides a solution that supports avoiding unnecessary retransmission of an RLC PDU. In this solution, a first RLC entity of a first communication device determines one of the following: a first RLC timer expires, a first indication is received from a first PDCP entity of the first communication device, or a first report is received from a second RLC entity of a second communication device. In turn, the first RLC entity updates a first state variable or determine at least one abandoned RLC SDU based on one of the following: expiration of the first RLC timer, the first indication, or the first report. The first state variable holds a value of a first SN following a last in-sequence completely received RLC SDU, and the first state variable serves as a lower edge of a receiving window of the first communication device. With this solution, unnecessary retransmission of an RLC PDU may be avoided.

[0095] Fig. 3 illustrates another example of a wireless communications system 300 that supports avoiding unnecessary retransmission of an RLC PDU in accordance with aspects of the present disclosure. As shown in Fig. 3, the wireless communications system 300 may comprise a first communication device 310 and a second communication device 320.

[0096] In some implementations, the first communication device 310 may comprise a first RLC entity 312 and a first PDCP entity 314, and the second communication device 320 may comprise a second RLC entity 322 and a second PDCP entity 324.

[0097] In some implementations, the first communication device 310 may be implemented as a receiving device of a packet, and the second communication device 320 may be implemented as a transmitting device of the packet. In such implementations, the first RLC entity 312 and the first PDCP entity 314 may be implemented as a receiving RLC entity 312 and a receiving PDCP entity 314 respectively, and the second RLC entity 322 and the second PDCP entity 324 may be implemented as a transmitting RLC entity 322 and a transmitting PDCP entity 324 respectively.

[0098] In some implementations, the first communication device 310 may be implemented as the network entity 102 in Fig. 1, and the second communication device 320 may be implemented as the UE 104 in Fig. 1. Alternatively, the first communication device 310 may be implemented as the UE 104 in Fig. 1, and the second communication device 320 may be implemented as the network entity 102 in Fig. 1.

[0099] Fig. 4 illustrates a flowchart of a method 400 that supports avoiding unnecessary retransmission of an RLC PDU in accordance with aspects of the present disclosure. The operations of the method 400 may be implemented by a device or its components as described herein. For example, the operations of the method 400 may be performed by the first communication device 310 in Fig. 3 as described herein. In some implementations, the device may execute a set of instructions to control the function elements of the device to perform the described functions. Additionally, or alternatively, the device may perform aspects of the described functions using special-purpose hardware. For the purpose of discussion, the process 400 will be described with reference to Fig. 3.

[0100] Generally, in the method 400, the first communication device 310 may be implemented as a receiving device of a packet, and the second communication device 320 may be implemented as a transmitting device of the packet.

[0101] As shown in Fig. 4, at 410, the first RLC entity 312 of the first communication device 310 determines one of the following: a first RLC timer expires, a first indication is received from the first PDCP entity 314 of the first communication device 310, or a  first report is received from the second RLC entity 322 of the second communication device 320.

[0102] In some implementations, the first RLC timer may be a dedicated or new timer for avoiding unnecessary retransmission of an RLC PDU. In such implementations, the first RLC timer may be configured per RLC entity by an RRC message from the network entity 102. For example, the first RLC timer is separately configured per downlink (DL) AM RLC entity as shown in Table 1.

[0103] Table 1

[0104] Alternatively, in some implementations, the first RLC timer may be the same as a second timer which is used by the first RLC entity 312 to detect loss of RLC PDUs at a lower layer of the first communication device 310. In such implementations, each of the first RLC timer and the second RLC timer may be referred to as t-Reassembly.

[0105] At 420, the first RLC entity 312 updates a first state variable or determines at least one abandoned RLC SDU based on one of the following: expiration of the first RLC timer, the first indication, or the first report.

[0106] In the present disclosure, the term “discard” used at the transmitting device may be used interchangeably with the term “abandon” used at the receiving device. The term “obsolete” or “discarded” used at the transmitting device may be used interchangeably with the term “abandoned” used at the receiving device.

[0107] The first state variable holds a value of a first SN following a last in-sequence completely received RLC SDU, and the first state variable serves as a lower edge of a receiving window of the first communication device. The first state variable is initially set to 0. Hereinafter, the first state variable is represented by RX_Next.

[0108] With the method 400, unnecessary retransmission of an RLC PDU may be avoided.

[0109] Fig. 5 illustrates a signaling diagram illustrating an example process 500 that supports avoiding unnecessary retransmission of an RLC PDU in accordance with aspects of the present disclosure. The process 500 may be considered as an example  implementation of the method 400. The process 500 may involve the first RLC entity 312 of the first communication device 310 as well as the second RLC entity 322 and the second PDCP entity 324 of the second communication device 320 in Fig. 3. For the purpose of discussion, the process 500 will be described with reference to Fig. 3.

[0110] Generally, in the process 500, the first RLC entity 312 may be implemented as the receiving RLC entity 312, and the second RLC entity 322 and the second PDCP entity 324 may be implemented as the transmitting RLC entity 322 and the transmitting PDCP entity 324 respectively.

[0111] In addition, in the process 500, the first RLC entity 312 determines the expiration of the first RLC timer and updates the first state variable or determines at least one abandoned RLC SDU based on the expiration of the first RLC timer.

[0112] As shown in Fig. 5, if the first RLC entity 312 receives a first RLC SDU with an SN greater than the first state variable (RX_Next) , the first RLC entity 312 starts 510 the first RLC timer, and sets a second state variable to a third state variable.

[0113] The second state variable holds a value of a second SN following the SN of the RLC SDU which triggered the first RLC timer. Hereinafter, the second state variable is represented by RX_Next_1.

[0114] The third state variable holds a value of a third SN following an SN of a second RLC SDU with a highest SN among received RLC SDUs. The third state variable is initially set to 0. Hereinafter, the third state variable is represented by RX_Next_Highest.

[0115] In some implementations, if the third state variable (RX_Next_Highest) is greater than the first state variable (RX_Next) plus 1, the first RLC entity 312 may determine that the first RLC SDU with the SN greater than the first state variable is received. In such implementations, if the third state variable (RX_Next_Highest) is greater than the first state variable (RX_Next) , the first RLC entity 312 may start the first RLC timer and set the second state variable (RX_Next_1) to the third state variable (RX_Next_Highest) . For example, the first RLC entity 312 may start the first RLC timer and set the second state variable to the third state variable if RX_Next_Highest is equal to RX_Next plus 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, e.g., by performing a procedure as shown in Table 2.

[0116] Table 2

[0117] Upon the expiration of the first RLC timer, the first RLC entity 312 may update 520 the first state variable (RX_Next) to an SN of a start RLC SDU with the SN equal to or greater than the second state variable (RX_Next_1) , wherein not all bytes of the start RLC SDU have been received by the first communication device 310. For example, the start RLC SDU is not abandoned or not indicated as abandoned.

[0118] In some implementations, after the first RLC entity 312 (such as the receiving side of an AM RLC entity) updates the first state variable, it may start the first RLC timer and set the second state variable if RX_Next_Highest is greater than RX_Next, e.g., by performing a procedure as shown in Table 3.

[0119] Table 3

[0120] In some implementations, upon the first RLC timer expiration, the first RLC entity 312 may determine at least one RLC SDU with an SN less than RX_Next_1, for which not all bytes have been received, is abandoned. This will be described with reference to Fig. 6.

[0121] In some implementations, after the first state variable is updated, the first RLC entity 312 may determine at least one RLC SDU with an SN less than RX_Next, for which not all bytes have been received, is abandoned.

[0122] Fig. 6 illustrates an example of updating the second state variable (RX_Next_1) in accordance with aspects of the present disclosure. In the example of Fig. 6, firstly, an RLC SDU with an SN#1 is received by the first RLC entity 312. Thus, RX_Next is set to 2.When an RLC SDU with an SN#4 is received by the first RLC entity 312, the first RLC entity 312 starts the first RLC timer, sets RX_Next_Highest to 5, sets RX_Next_1 to RX_Next_Highest (i.e., 5) .

[0123] In addition, when the RLC SDU with an SN#4 is received by the first RLC entity 312, the first RLC entity 312 starts a second RLC timer (i.e., t-Reassembly) , sets RX_Next_Status_Trigger to 5 and sets RX_Highest_Status to 2. RX_Next_Status_Trigger holds the value of the SN following the SN of the RLC SDU which triggered t-Reassembly. RX_Highest_Status holds the highest possible value of the SN which can be indicated by "ACK_SN"when a STATUS PDU needs to be constructed. It is initially set to 0. The ACK_SN field indicates the SN of the next not received RLC SDU which is not reported as missing in the STATUS PDU.

[0124] An RLC SDU with an SN#6 is received before the first RLC timer expiration. Thus, RX_Next_Highest is updated to 7. Upon the first RLC timer expiration, the first RLC entity 312 updates RX_Next to an SN of a start RLC SDU with the SN equal to or greater than RX_Next_1, wherein not all bytes of the start RLC SDU have been received by the first communication device 310. That is, upon the first RLC timer expiration, the first RLC entity 312 updates RX_Next to 5. In addition, because the RLC SDU with an SN#6 is received, upon the first RLC timer expiration, the first RLC entity 312 sets RX_Next_1 to RX_Next_Highest (i.e., 7) , and sets RX_Highest_Status to 5, sets RX_Next_Status_Trigger to 7.

[0125] Upon the first RLC timer expiration, before updating the RX_Next and the RX_Next_1, the first RLC entity 312 determines RLC SDUs with RLC SN < RX_Next_1, for which not all bytes have been received, are abandoned. That is, the first RLC entity 312 determines RLC SDUs with RLC SNs #2 and #3, for which not all bytes have been received, are abandoned. Since RX_Next_Highest (7) is greater than RX_Next (5) , the first RLC entity 312 starts (i.e., restart) the first RLC timer. In addition, a second report  may be triggered for transmission to the second RLC entity 322, which will be described later.

[0126] In some implementations, after updating RX_Next, the first RLC entity 310 may update a fourth state variable to an SN of a start RLC SDU with the SN greater than the current fourth state variable, wherein not all bytes of the start RLC SDU have been received by the first communication device 310. And further the start RLC SDU is not abandoned. The fourth state variable holds a highest possible value of an SN which can be indicated by a field in a STATUS protocol data unit (PDU) when the STATUS PDU needs to be constructed. The field indicates an SN of a next not received RLC SDU which is not reported as missing in the STATUS PDU. Hereinafter, the fourth state variable is represented by RX_Highest_Status, and the field in the STATUS PDU is also referred to as an ACK_SN field.

[0127] For example, if RX_Highest_Status is equal to one of at least one RLC SN of the at least one abandoned RLC SDU, the first RLC entity 312 may update RX_Highest_Status to the SN of the start RLC SDU with SN > current RX_Highest_Status, for which not all bytes have been received. That is, the first RLC entity 312 may update RX_Highest_Status to the SN of the next not received RLC SDU, which is not reported as missing in the STATUS PDU, and which is not abandoned or not indicated as abandoned.

[0128] For another example, if RX_Highest_Status <= RX_Next, the first RLC entity 312 may update RX_Highest_Status to the SN of the start RLC SDU with SN >= current RX_Next for which not all bytes have been received.

[0129] In some implementations, after updating at least one of RX_Next and RX_Next_Status_Trigger, the first RLC entity 312 may determine whether to stop and reset the second RLC timer (i.e., t-Reassembly) based on the first state variable (RX_Next) and a fifth state variable. The fifth state variable holds a value of an SN following an SN of a third RLC SDU which triggered the second RLC timer. Hereinafter, the fifth state variable is represented by RX_Next_Status_Trigger.

[0130] For example, the first RLC entity 312 may determine whether to stop and reset the second RLC timer (i.e., t-Reassembly) 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 except the abandoned RLC SDU (s) , e.g., by performing a procedure as shown in Table 4.

[0131] Table 4

[0132] In some implementations, after stopping and resetting the second RLC timer, the first RLC entity 312 may determine whether to start the second RLC timer (i.e., t-Reassembly) based on the first state variable (RX_Next) and the third state variable (RX_Next_Highest) . In some implementations, if the third state variable (RX_Next_Highest) is greater than the first state variable (RX_Next) , the first RLC entity 312 may start the second RLC timer (i.e., t-Reassembly) and set the fifth state variable (RX_Next_Status_Trigger) to the third state variable (RX_Next_Highest) .

[0133] For example, the first RLC entity 312 may determine whether to start the second RLC timer (i.e., t-Reassembly) and set the fifth state variable (RX_Next_Status_Trigger) by performing a procedure as shown in Table 5.

[0134] Table 5

[0135] In some implementations, when the first RLC entity 312 receives an RLC SDU, and if the RLC SDU is placed in a reception buffer and if an SN of the RLC SDU is equal to the first state variable (RX_Next) , the first RLC entity 312 may update the first state variable (RX_Next) to the SN of the start RLC SDU with the SN > current RX_Next for which not all bytes have been received.

[0136] In some implementations, before the first RLC timer expires, the first RLC entity 312 may stop the first RLC timer if the second state variable (RX_Next_1) is equal to the first state variable (RX_Next) . In such implementations, if the first RLC timer is running and RX_Next_1 = RX_Next after receiving a fourth RLC SDU (s) , the first RLC entity 312 may stop and reset the first RLC timer.

[0137] Alternatively, if the first RLC timer is running and if RX_Next_1 falls outside of the receiving window and RX_Next_1 is not equal to RX_Next + AM_Window_Size, the first RLC entity 312 may stop and reset the first RLC timer.

[0138] For example, the first RLC entity 312 (i.e., the receiving side of an AM RLC entity) may stop the first RLC timer by performing a procedure as shown in Table 6.

[0139] Table 6

[0140] In some implementations, if all byte segments of the AMD PDU with SN =RX_Next_1 are received, the first RLC entity 312 may updates RX_Next_1 to the SN of the start AMD PDU with SN > current RX_Next_1 for which not all byte segments have been received. For example, the first RLC entity 312 (i.e., the receiving side of an AM RLC entity) may update RX_Next_1 by performing a procedure as shown in Table 7.

[0141] Table 7

[0142] Returning to Fig. 5, the first RLC entity 312 transmits 530 a second report to the second RLC entity 322 of the second communication device 320.

[0143] In some implementations, the second report is triggered if the at least one abandoned RLC SDU is determined.

[0144] In some implementations, the second report is triggered if the at least one abandoned RLC SDU has not been reported in the second report.

[0145] In some implementations, the second report is triggered if a first poll bit is received from the second RLC entity 322. For example, the first poll bit may be a new poll bit or legacy poll bit.

[0146] In some implementations, the second report is triggered based on the first RLC timer expiration or the first indication from the first PDCP entity 314 or the first report from the second RLC entity 322.

[0147] In some implementations, the second report is triggered if the first state variable (RX_Next) is updated. For example, the second report is triggered after the first state variable (RX_Next) is updated based on the first RLC timer expiration or the first indication from the first PDCP entity 314 or the first report from the second RLC entity 322.

[0148] In some implementations, the second report may be triggered before the first state variable (RX_Next) and the second state variable (RX_Next_1) are updated.

[0149] In some implementations, the second report may indicate a reference RLC SDU via an RLC SN.

[0150] In some implementations, the second report may indicate at least one abandoned RLC SDU.

[0151] In some implementations, the second report may be an RLC control PDU which comprises a reference RLC SN field (e.g., R_SN) . The reference RLC SN field comprises the RLC SN of the reference RLC SDU.

[0152] In some implementations, the RLC SN of the reference RLC SDU is equal to the first state variable (RX_Next) .

[0153] In some implementations, at least one SN of the at least one abandoned RLC SDU is less than the updated first state variable.

[0154] Fig. 7 illustrates an example of an RLC control PDU 700 in accordance with aspects of the present disclosure. As shown in Fig. 7, the RLC control PDU 700 comprises an RLC control PDU payload and an RLC control PDU header. The RLC control PDU header consists of a Data / Control (D / C) field and a Control PDU Type (CPT) field. The D / C field indicates whether the RLC PDU is an RLC data PDU or RLC control PDU. The CPT field indicates the type of the RLC control PDU 700.

[0155] The RLC control PDU payload starts from the first bit following the RLC control PDU header. The RLC control PDU payload comprises a reference RLC SN field (i.e., R_SN) . A length of the R_SN field is 12 bits.

[0156] Fig. 8 illustrates an example of an RLC control PDU 800 in accordance with aspects of the present disclosure. As shown in Fig. 8, the RLC control PDU 800 is different from the RLC control PDU 700 in that a length of the R_SN field is 18 bits.

[0157] Alternatively, in some implementations, the second report may indicate the at least one abandoned RLC SDU. At least one SN of the at least one abandoned RLC SDU is less than the updated first state variable.

[0158] In some implementations, the at least one abandoned RLC SDU comprises multiple abandoned RLC SDUs. The second report may comprise a first filed. The first filed indicates a start abandoned RLC SDU among the multiple abandoned RLC SDUs. Hereinafter, the first filed is also referred to as an FA_SN field.

[0159] In some implementations, the second report may further comprise a bitmap field. Each of bits in the bitmap field is associated with an RLC SDU and indicates whether the RLC SDU is abandoned at the first RLC entity 312. Hereinafter, the bitmap field is also referred to as an Abandon Bitmap field.

[0160] In some implementations, a least significant bit or a most significant bit of the bitmap field is associated with the start abandoned RLC SDU.

[0161] In some implementations, the second report may be an RLC control PDU. The RLC control PDU comprises the FA_SN field and the Abandon Bitmap field. This will be described with reference to Fig. 9.

[0162] Fig. 9 illustrates an example of an RLC control PDU 900 in accordance with aspects of the present disclosure. As shown in Fig. 9, the RLC control PDU 900 comprises an RLC control PDU payload and an RLC control PDU header.

[0163] The RLC control PDU header comprises a D / C field and a CPT field. The RLC control PDU payload starts from the first bit following the RLC control PDU header. The RLC control PDU payload comprises the FA_SN field and the Abandon Bitmap field.

[0164] The FA_SN filed indicates a start abandoned RLC SDU among the multiple abandoned RLC SDUs.

[0165] Each of bits in the Abandon Bitmap field is associated with an RLC SDU and indicates whether the RLC SDU is abandoned at the first RLC entity 312. A least significant bit or a most significant bit of the Abandon Bitmap field is associated with the start abandoned RLC SDU. The bit position of the Nth bit in the Abandon Bitmap field is N, i.e., the bit position of the first bit in the Abandon Bitmap is 1.

[0166] A length of the Abandon Bitmap field is variable. The length of the Abandon Bitmap field can be 0.

[0167] An example interpretation of the Abandon Bitmap field is provided in Table 8 where a length of an RLC SN is 12 bits.

[0168] Table 8

[0169] Another example interpretation of the Abandon Bitmap field is provided in Table 9 where a length of an RLC SN is 18 bits.

[0170] Table 9

[0171] In some implementations, the at least one abandoned RLC SDU may comprise multiple abandoned RLC SDUs, the second report may comprise at least one second filed, and each of the at least one second filed indicates one of the multiple abandoned RLC SDUs. Hereinafter, each of the at least one second filed is also referred to as an A_SN field.

[0172] In some implementations, the second report further may comprise an abandon range field. The abandon range field indicates the number of abandoned RLC SDUs in a continuous sequence of abandoned RLC SDUs starting from an abandoned RLC SDU indicated by one of the at least one second field. The abandon range field follows the one of the at least one second field.

[0173] In some implementations, the second report may be an RLC control PDU. The RLC control PDU may comprise the at least one A_SN field and the abandon range field. This will be described with reference to Fig. 10.

[0174] Fig. 10 illustrates an example of an RLC control PDU 1000 in accordance with aspects of the present disclosure. As shown in Fig. 10, the RLC control PDU1000 comprises an RLC control PDU payload and an RLC control PDU header.

[0175] The RLC control PDU header comprises a D / C field and a CPT field. The RLC control PDU payload starts from the first bit following the RLC control PDU header. The RLC control PDU payload comprises the at least one A_SN field and the abandon range field. A length of the A_SN field may be 12 bits, and a length of the abandon range field may be variable.

[0176] For example, in Fig. 10, the control PDU payload may comprise A_SN fields 1010, 1012, 1014 and 1016 and an abandon range field 1020.

[0177] The A_SN field 1010 occupies the fifth bit to the eighth bits of the first octet (i.e., Oct 1) as well as the second octet (i.e., Oct 2) . The A_SN field 1012 occupies the fourth octet (i.e., Oct 4) as well as the first bit to the fourth bits of the fifth octet (i.e., Oct 5) .The A_SN field 1014 occupies the sixth octet (i.e., Oct 6) as well as the first bit to the  fourth bits of the seventh octet (i.e., Oct 7) . The A_SN field 1016 occupies the ninth octet (i.e., Oct 9) as well as the first bit to the fourth bits of the tenth octet (i.e., Oct 10) .

[0178] Each of the at least one A_SN filed indicates one of the multiple abandoned RLC SDUs via an RLC SN of the respective abandoned RLC SDU. For example, the A_SN field 1010 may indicate an abandoned RLC SDU with an RLC SN#1, the A_SN field 1012 may indicate an abandoned RLC SDU with an RLC SN#3, the A_SN field 1014 may indicate an abandoned RLC SDU with an RLC SN#6, and the A_SN field 1016 may indicate an abandoned RLC SDU with an RLC SN#11.

[0179] The abandon range field 1020 indicates the number of abandoned RLC SDUs in a continuous sequence of abandoned RLC SDUs starting from an abandoned RLC SDU indicated by the A_SN field 1014. The abandon range field 1020 follows the A_SN field 1014. For example, the abandon range field 1020 may indicate three. That is, a continuous sequence of RLC SDUs with RLC SNs#6, #7 and #8 starting from the abandoned RLC SDU with the RLC SN#6 is abandoned.

[0180] As shown in Fig. 10, the control PDU payload may further comprise at least one E4 field and / or at least one E5 field. Each E4 field indicates whether or not at least one of the A_SN field, E4 field or E5 field follows. For example, each E4 field indicates whether or not a set of A_SN field, E4 field and E5 field follows. A length of each E4 field is 1 bit. The interpretation of each E4 field is provided in Table 10.

[0181] Table 10

[0182] Each E5 field indicates whether or not information about a continuous sequence of RLC SDUs that have been abandoned follows. A length of each E5 field is 1 bit. The interpretation of each E5 field is provided in Table 11.

[0183] Table 11

[0184] In some implementations, the second report may further comprise a field. The field indicates an SN of a next not received RLC SDU which is not reported as missing in the second report. The field may be referred to as an ACK_SN field. The second report may include E4 field following the ACK_SN field.

[0185] In some implementations, the second report may be an enhanced status report, which indicates information about at least one RLC data PDU that is abandoned, and / or about at least one RLC data PDU that is successfully received, and / or about at least one RLC data PDU that has not been completely received. For example, the enhanced status report includes at least one of the following: the A_SN field, or the abandon range field. This will be described with reference to Fig. 11. In some implementations, the second report may be an enhanced status report including at least one NACK_SN field. In some implementations, the second report may be an enhanced status report including at least one A_SN field.

[0186] Fig. 11 illustrates an example of an STATUS PDU 1100 in accordance with aspects of the present disclosure. As shown in Fig. 11, the STATUS PDU 1100 comprises a STATUS PDU payload and an RLC control PDU header.

[0187] The RLC control PDU header comprises a D / C field and a CPT field. The STATUS PDU payload starts from the first bit following the RLC control PDU header. The STATUS PDU payload comprises the at least one A_SN field and the abandon range field.

[0188] As shown in Fig. 11, the STATUS PDU payload further comprises one ACK_SN field and one E1 field, zero or more sets of a NACK_SN field, an E1 field, an E2 field and an E3 field, and possibly a pair of an SO start (SOstart) field and an SO end (SOend) field or a NACK range field for each NACK_SN.

[0189] The ACK_SN field indicates an SN of a next not received RLC SDU which is not reported as missing in the second report.

[0190] The NACK_SN field indicates an SN of the RLC SDU (or RLC SDU segment) that has been detected as lost at the first RLC entity 312.

[0191] The E1 field indicates whether or not a set of NACK_SN, E1, E2 and E3 follows.

[0192] The E2 field indicates whether or not a set of SOstart and SOend follows.

[0193] The E3 field indicates whether or not information about a continous sequence of RLC SDUs that have not been received follows.

[0194] The SOstart field (together with the SOend field) indicates the portion of the RLC SDU with SN = NACK_SN (the NACK_SN for which the SOstart is related to) that has been detected as lost at the first RLC entity 312.

[0195] When E3 is 0, the SOend field (together with the SOstart field) indicates the portion of the RLC SDU with SN = NACK_SN (the NACK_SN for which the SOend is related to) that has been detected as lost at the first RLC entity 312.

[0196] The NACK range field is the number of consecutively lost RLC SDUs starting from and including NACK_SN.

[0197] The interpretations of the E4 and E5 fields in Fig. 11 are provided in Tables 10 and 11 as above.

[0198] In some implementations, after updating the first state variable based on the first RLC timer expiration or the first indication from the first PDCP entity 314 or the first report from the second RLC entity 322, the first RLC entity 312 may indicate information for the multiple abandoned RLC SDUs with SNs such that the SNs less than the first state variable, in increasing SN order of the abandoned RLC SDUs, starting with an RLC SN of a start abandoned RLC SDU among the multiple abandoned RLC SDUs, for which that have not been completely received yet and have not reported.

[0199] In some implementations, the second report may indicate information for the multiple abandoned RLC SDUs with SNs such that the SNs are less than the second state variable and larger than or equal to the first state variable, both have not been updated based on the first RLC timer expiration or the first indication from the first PDCP entity 314 or the first report from the second RLC entity 322 in increasing SN order of the abandoned RLC SDUs, starting with an RLC SN of a start abandoned RLC SDU among the multiple abandoned RLC SDUs, for which that have not been completely received yet and have not reported.

[0200] In some implementations, the second report may indicate information for the multiple abandoned RLC SDUs with SNs such that the SNs are less than the fourth state variable and larger than or equal to the first state variable, both have not been updated based on the first RLC timer expiration or the first indication from the first PDCP entity 314 or the first report from the second RLC entity 322, in increasing SN order of the abandoned RLC SDUs, starting with an RLC SN of a start abandoned RLC SDU among the multiple abandoned RLC SDUs, for which that have not been completely received yet and have not reported.

[0201] In some implementations, after updating the first state variable based on the first RLC timer expiration or the first indication from the first PDCP entity 314 or the first report, the first RLC entity 312 may construct the second report by performing the following:

[0202] -for the multiple abandoned RLC SDUs with SNs such that the SNs less than the first state variable that have not been completely received yet, in increasing SN order of the abandoned RLC SDUs, starting with an RLC SN of a start abandoned RLC SDU among the multiple abandoned RLC SDUs, for which that have not been completely received yet and have not reported, up to a point where the resulting second report still fits to a total size of the multiple abandoned RLC SDUs indicated by a lower layer of the first communication device 310:

[0203] -first including in the second report one of the at least one second field which is set to an SN of a start abandoned RLC SDU among the abandoned RLC SDUs for which no byte segments or partly have been received yet, and / or

[0204] -then including in the second report a further one of the at least one second field and the abandon range field for the continuous sequence of the abandoned RLC SDUs that have not been received yet.

[0205] For example, after determining the abandoned RLC SDUs, the first RLC entity 312 may construct the second report by performing a procedure in Table 12.

[0206] Table 12

[0207] In some implementations, the second report may be a Status Report. The Status Report may comprise a STATUS PDU. The STATUS PDU is used by the first entity 312 to inform the second RLC entity 322 about at least one RLC data PDU that is received successfully, and / or about at least one RLC data PDU that has not been completely received. In such implementations, the legacy Status Report may be reused. In this case, the at least one abandoned RLC SDU is reported as if the at least one abandoned RLC SDU is successfully received.

[0208] In such implementations, an SN of the at least one RLC data PDU is equal to or greater than the first state variable (RX_Next) and less than the fourth state variable (RX_Highest_Status) . The fourth state variable holds a highest possible value of an SN which can be indicated by a field in the STATUS PDU when the STATUS PDU needs to be constructed, the field indicates an SN of a next not received RLC SDU which is not reported as missing in the STATUS PDU. In such implementations, the first RLC entity 312 treats the at least one abandoned RLC SDU with SN such that RX_Next <= SN<RX_Highest_Status and SN < RX_Next, for which not all bytes have been received as if at least one completely received RLC, i.e., not indicated as NACK. In such implementation, the first state variable has been updated based on the first RLC timer expiration or the first indication from the first PDCP entity 314 or the first report from  the second RLC entity 322. In such implementation, the fourth state variable is current fourth state variable after it is updated based on the first RLC timer expiration or the first indication from the first PDCP entity 314 or the first report from the second RLC entity 322.

[0209] Fig. 12 illustrates an example of an STATUS PDU 1200 in accordance with aspects of the present disclosure. In the STATUS PDU 1200, a length of an RLC SN is 12 bits.

[0210] Fig. 13 illustrates an example of an STATUS PDU 1300 in accordance with aspects of the present disclosure. In the STATUS PDU 1300, a length of an RLC SN is 18 bits.

[0211] The interpretations of the fields in the STATUS PDUs 1200 and 1300 are the same as those in the STATUS PDU 1100. Details of such fields in the STATUS PDUs 1200 and 1300 are omitted for brevity.

[0212] In some implementations, the first entity 312 may trigger the Status Report based on the first RLC timer expiration or the first indication from the first PDCP entity 314 or the first report from the second RLC entity 322. In some implementations, the first entity 312 may trigger the Status Report if the first state variable is updated.

[0213] In some implementations, the STATUS PDU may indicate information for the RLC SDUs with SN such that RX_Next <= SN < RX_Highest_Status that has not been completely received yet except the abandoned RLC SDU (s) , in increasing SN order of RLC SDUs and increasing byte segment order within RLC SDUs, starting with SN =RX_Next except the abandoned RLC SDU (s) .

[0214] In some implementations, if the at least one abandoned RLC SDU is determined, the first entity 312 may trigger the Status Report. In some implementations, if the at least one abandoned RLC SDU is determined and has not been reported to the second RLC entity 322, the first entity 312 may trigger the Status Report. For example, the first RLC entity 312 may construct the STATUS PDU by performing a procedure in Table 13.

[0215] Table 13

[0216] Alternatively, in some implementations, the first entity 312 may trigger the Status Report after updating at least one of the following based on expiration of the first RLC timer: the first state variable (RX_Next) , the fourth state variable (RX_Highest_Status) , or the third state variable (RX_Next_Highest) .

[0217] Hereinafter, actions of the second RLC entity 322 and the second PDCP entity 324 will be described with reference to Fig. 5.

[0218] Upon receiving the second report, the second RLC entity 322 updates 540 a sixth state variable based on the second report. The sixth state variable holds a value of an SN of a next RLC SDU for which a positive acknowledgment is to be received in-sequence, and the sixth state variable serves as a lower edge of a transmitting window of  the second communication device. The sixth state variable is initially set to 0. Hereinafter, the sixth state variable is represented by TX_Next_Ack.

[0219] In some implementations, the second RLC entity 322 abandons at least one RLC PDU if the sixth state variable (TX_Next_Ack) is updated.

[0220] In some implementations, if the Status report is received, the second RLC entity 322 sets the sixth state variable (TX_Next_Ack) to the SN of the RLC SDU with the smallest SN, whose SN falls within the range TX_Next_Ack <= SN <= TX_Next and for which a positive acknowledgment has not been received yet.

[0221] In some implementations, if the FA_SN field and the Abandon Bitmap field are present in the report, or if the at least one A_SN field and the abandon range field are present in the report, the second RLC entity 322 sets the sixth state variable (TX_Next_Ack) to the SN of the RLC SDU with the smallest SN, whose SN falls within the range TX_Next_Ack <= SN <= TX_Next and for which a positive acknowledgment has not been received yet, and for which is not indicated as abandoned in the second report. TX_Next holds a value of an SN to be assigned for the next newly generated AMD PDU. It is initially set to 0, and is updated whenever the second RLC entity 322 constructs an AMD PDU with SN = TX_Next and contains an RLC SDU or the last segment of an RLC SDU.

[0222] Alternatively, if the R_SN field is present in the second report, the second RLC entity 322 sets the sixth state variable (TX_Next_Ack) to the SN of the RLC SDU with the smallest SN, whose SN falls within the range TX_Next_Ack <= SN <= TX_Next and for which a positive acknowledgment has not been received yet, and whose SN >=R_SN in the second report.

[0223] The second RLC entity 322 may transmit 550 a second indication to the second PDCP entity 324. The second indication indicates at least one abandoned RLC SDU or at least one abandoned PDCP PDU.

[0224] It shall be noted that the action 550 may be performed in parallel to, prior to or subsequent to the action 540.

[0225] In some implementations, if the second indication indicates that a PDCP control PDU has been abandoned by the first RLC entity 312, the second PDCP entity  324 may generate, based on the second indication, a PDU for an abandoned RLC SDU including the PDCP control PDU.

[0226] Alternatively, in some implementations, if the second indication indicates that a PDCP SDU belonging to high importance PDU set is abandoned, the second PDCP entity 324 may generate, based on the second indication, a PDU for an abandoned RLC SDU including the PDCP SDU belonging to high importance PDU set.

[0227] For example, the second PDCP entity 324 may reuse the original PDCP control PDU. For another example, the second PDCP entity 324 may regenerate a new PDCP PDU for the PDCP PDU corresponding to the abandoned RLC SDU.

[0228] In turn, the second PDCP entity 324 may deliver 570 the generated PDU to the second RLC entity 322.

[0229] The second RLC entity 322 may transmit 580 a report confirm to the first RLC entity 312.

[0230] For example, the report confirm may be an indicator in an RLC AMD PDU or an RLC control PDU.

[0231] For another example, the indicator may indicate the value in the last A_SN field, last NACK_SN field or ACK_SN field indicated in the second report.

[0232] For another example, the indicator may indicate the RLC SN of the last abandoned RLC SDU indicated in the second report.

[0233] For another example, the indicator may indicate the value of the sixth state variable (i.e., TX_Next_Ack) .

[0234] In some implementations, if the fist RLC entity 312 does not receive 580 the report confirm from the second RLC entity 322 after a time period, it can transmit a second report to the second RLC entity 322. The time period may be configured by the network entity 102.

[0235] In some implementations, the fist RLC entity 312 may determine whether to (re) transmit a second report for the abandoned RLC SDU (s) to the second RLC entity 322 based on the abandoned SN, NACK_SN or the value of the sixth state variable received in the report confirm. For example, if the NACK_SN, abandoned SN, or the value of the sixth state variable is equal to one of the SN of the abandoned RLC SDU (s) , the fist RLC  entity 312 may (re) transmit the second report for the abandoned RLC SDU (s) . Otherwise, the fist RLC entity 312 may (re) transmit a second report.

[0236] In some implementations, the action 540 may be replaced by the following action: the second RLC entity 322 updates the sixth state variable (TX_Next_Ack) based on a discard indication received from the second PDCP entity 324. The discard indication indicates at least one abandoned PDCP PDU. The second RLC entity 322 sets the sixth state variable (TX_Next_Ack) to an SN of an RLC SDU with the smallest SN, whose SN falls within the range TX_Next_Ack <= SN <= TX_Next and for which a positive acknowledgment has not been received yet, and for which the discard indication has not been received.

[0237] As a result, the second RLC entity 322 abandons the RLC PDU if the TX_Next_Ack is updated.

[0238] In some implementations, if the first communication device 310 receives a configuration for UL AM RLC from the network entity 102 or if the first communication device 310 reports the capability to support the first RLC timer or avoiding unnecessary RLC retransmission, the second RLC entity 322 may abandon an RLC SDU, for which at least some bytes of the RLC SDU have been delivered to lower layer.

[0239] Alternatively, in some implementations, if the first communication device 310 receives a configuration for UL AM RLC from the network entity 102 or if the first communication device 310 report the capability to support first RLC timer or avoiding unnecessary RLC retransmission, the second RLC entity 322 may update the sixth state variable (TX_Next_Ack) based on the discard indication from the second PDCP entity 324.

[0240] For example, the configuration may comprise a new indication (represented by “indication-1” ) . The indication may be configured per RLC entity by an RRC message from the network entity 102. For example, the indication is separately configured per UL AM RLC entity as shown in Table 13.

[0241] Table 13

[0242] In some implementations, the action 560 may be replaced by the following action: the second RLC entity 322 may re-assign a new RLC SN for the abandoned RLC SDU corresponding to a PDCP control PDU or PDCP SDU belonging to high importance PDU set and delivers it to MAC layer.

[0243] In some implementations, the action 510 may be replaced by the following action: the first RLC entity 312 starts the first RLC timer if it is not running and an RLC SDU with RLC SN > RX_Next is received, wherein the RLC SDU comprises a PDCP data SDU.

[0244] In some implementations, in order to determine whether a received RLC SDU comprises a PDCP control PDU or PDCP data SDU, the first RLC entity 312 reads the received RLC SDU, i.e., checks it is a PDCP control PDU or PDCP data SDU.

[0245] Alternatively, in some implementations, in order to determine whether a received RLC SDU comprises a PDCP control PDU or PDCP data SDU, the second RLC entity 322 adds a bit in the RLC header to indicate whether it is a PDCP control PDU or not.

[0246] Alternatively, in some implementations, in order to determine whether a received RLC SDU comprises a PDCP control PDU or PDCP data SDU, the first PDCP entity 314 indicates a received RLC SDU comprises a PDCP control PDU or not to the first RLC entity 312.

[0247] In some implementations, the action 510 may be replaced by the following action: the first RLC entity 312 starts the first RLC timer if the first RLC is not running and an RLC SDU with RLC SN > RX_Next is received, wherein the RLC SDU comprises a PDCP SDU belonging to a high importance PDU set. Identification of Protocol Data Unit Set Importance (PSI) of a PDU Set and determination of low importance PDU Set are left up to implementation of the first communication device 310.

[0248] As described above, in some implementations, the first RLC timer may be t-reassembly.

[0249] For example, if the first communication device 310 receives a configuration from the network entity 102, the first communication device 310 may use the t- reassembly as the first RLC timer in above procedure. That is to say, the configuration indicates the first RLC entity 312 is allowed to abandon an RLC SDU based on expiration of the t-reassembly or indicates the first RLC entity 312 to update the first state variable (RX_Next) based on the expiration of the t-reassembly.

[0250] For example, the configuration may comprise a new indication (represented by “indication-2” ) . The indication may be configured per RLC entity by RRC message from the network entity 102. For example, the indication is separately configured per DL AM RLC entity as shown in Table 14.

[0251] Table 14

[0252] If the first RLC entity 312 updates the first state variable (RX_Next) based on the expiration of the t-reassembly, the second state variable (RX_Next_1) is replaced by the fifth state variable (RX_Next_Status_Trigger) in the above procedure.

[0253] Fig. 14 illustrates a signaling diagram illustrating an example process 1400 that supports avoiding unnecessary retransmission of an RLC PDU in accordance with aspects of the present disclosure. The process 1400 may be considered as an example implementation of the method 400. The process 1400 may involve the first RLC entity 312 and the first PDCP entity 314 of the first communication device 310 in Fig. 3. For the purpose of discussion, the process 1400 will be described with reference to Fig. 3.

[0254] Generally, in the process 1400, the first RLC entity 312 may be implemented as the receiving RLC entity 312, and the first PDCP entity 314 may be implemented as the receiving PDCP entity 314.

[0255] In addition, in the process 1400, the first RLC entity 312 determines the first indication is received from the first PDCP entity 314 and updates the first state variable or determines at least one abandoned RLC SDU based on the first indication.

[0256] As shown in Fig. 14, the first RLC entity 312 delivers 1410 an RLC SDU (i.e, PDCP PDU) to the first PDCP entity 314.

[0257] In a first implementation, the first RLC entity 312 may deliver the RLC SDU to the first PDCP entity 314 with an RLC SN of the RLC SDU. Thus, the first PDCP entity 314 may determine mapping between an RLC SN and a PDCP SN for the RLC SDU.

[0258] In CU-DU split case, a DU may deliver an RLC SDU to the first PDCP entity 314 together with an RLC SN to a CU. Thus, the first PDCP entity 314 may determine mapping between an RLC SN and a PDCP SN for the RLC SDU for an DRB per each DU.

[0259] The internal structure of the network entity 102 may be split into two parts called gNB-CU and gNB-DU and these two entities are connected by a new interface called F1. The gNB-CU generates some other system information like system information block type 2 (SIB2) , system information block type 3 (SIB3) and so on and provides it to gNB-DU. The gNB-DU generates system information block type 1 (SIB1) and master information block (MIB) , and provides it to the gNB-CU. The RRC, SDAP, PDCP layers are in gNB-CU. The gNB-DU holds the RLC, MAC and PHY layers.

[0260] Alternatively, in a second implementation, the first RLC entity 312 may maintain 1415 mapping between an RLC SN and a PDCP SN for an RLC SDU. In this implementation, the first RLC entity 312 may deliver the RLC SDU to the first PDCP entity 314 without an RLC SN of the RLC SDU.

[0261] Upon receiving the PDCP PDU with an SN > a seventh state variable, the first PDCP entity 314 starts 1420 a reordering timer (i.e., t-Reordering) . The seventh state variable RX_DELIV indicates a COUNT value of the first PDCP SDU not delivered to the upper layers, but still waited for. In the present disclosure, the seventh state variable is represented by RX_DELIV.

[0262] Upon expiration of t-Reordering, the first PDCP entity 314 updates 1425 RX_DELIV and transmits 1430 the first indication to the first RLC entity 312.

[0263] Based on the first implementation, the first indication may indicate an RLC SN of an abandoned RLC SDU corresponding to a PDCP PDU with PDCN SN <RX_DELIV. For example, the first PDCP entity 314 is aware of the mapping between an RLC SN and a PDCP SN for the RLC SDU.

[0264] Alternatively, based on the first implementation, the first indication may indicate a reference RLC SDU or a reference RLC SN. Alternatively, based on the first implementation, the first indication may indicate a reference PDCP PDU or a reference PDCP SN. The reference RLC SDU corresponds to a PDCP PDU with a PDCP SN equal to the seventh state variable (RX_DELIV) . The reference PDCP PDU has a PDCP SN equal to the seventh state variable (RX_DELIV) . The first RLC entity 312 may be aware of the mapping between an RLC SN and a PDCP SN for the RLC SDU.

[0265] Based on the second implementation, the first indication may indicate at least one abandoned RLC SDU or PDCP PDU. The first RLC entity 312 may be aware of the mapping between an RLC SN and a PDCP SN for the RLC SDU.

[0266] Alternatively, based on the second implementation, the first indication may indicate each abandoned RLC SDU or each abandoned PDCP PDU to the RLC entity. The first indication may indicate a PDCP SN or an RLC SN.

[0267] In some implementations, this may be configured per PDCP entity by RRC message from the network entity 102. In such implementations, the configuration from the network entity 102 may indicate at least one of the following: transmission of the first indication; receiving of an RLC SN of an RLC SDU corresponding to a PDCP PDU from the first RLC entity 312 or maintaining mapping between an RLC SN and a PDCP SN for an RLC SDU.

[0268] The first RLC entity 312 updates 1435 the first state variable (RX_Next) based on the first indication.

[0269] In some implementations, the configuration may indicate the first RLC entity 312 to update the first state variable (RX_Next) based on the first indication. This may be configured per RLC entity by RRC message from the network entity 102. For example, this is separately configured per DL AM RLC entity. Based on the first implementation, the first RLC entity 312 may update RX_Next to an RLC SN of the start RLC SDU, for which not all bytes have not received, wherein the RLC SN is larger than or equal to the RLC SN of the indicated RLC SDU (i.e., reference RLC SDU) .

[0270] For example, the first RLC entity 312 may update RX_Next by performing a procedure in Table 15.

[0271] Table 15

[0272] Based on the first implementation, the first RLC entity 312 abandons at least one RLC SDU before the indicated RLC SDU (i.e. reference RLC SDU) , e.g., for which not all bytes have received. i.e., the first RLC entity 312 abandons the at least one RLC SDU, for which not all bytes have been received, with RLC SN < the RLC SN (i.e., reference RLC SN) indicated by the first PDCP entity 314. Based on the second implementation, the first RLC entity 312 may update the RX_Next to the RLC SN of the start RLC SDU, with RLC SN >= current RX_Next, for which not all bytes have not received and which is not indicated as abandoned if current RX_Next is equal to or less than one of the at least one RLC SN of the at least one abandoned RLC SDU. For example, the first RLC entity 312 may update the RX_Next to the RLC SN of the start RLC SDU, with RLC SN > current RX_Next, for which not all bytes have not received, and which is not indicated as abandoned if current RX_Next is equal to one of the at least one RLC SN of the at least one abandoned RLC SDU.

[0273] Fig. 15 illustrates an example of updating the first state variable (RX_Next) in accordance with aspects of the present disclosure. In the example of Fig. 15, the first PDCP entity 314 maintains a receiving window 1510, and the first RLC entity 312 maintains a receiving window 1520. The second communication device 320 transmits PDCP data PDUs with PDCP SNs #1, #2, #3, #4, #5 and #6 to the first communication device 310. The PDCP data PDUs with PDCP SNs #1, #3, #4 and #6 are received by the first communication device 310 and the PDCP data PDUs with PDCP SNs #2 and #5 are not completely received by the first communication device 310. Thus, the first PDCP entity 314 updates RX_DELIV to 2 and starts a reordering timer. RX_DELIV indicates a COUNT value of the first PDCP SDU not delivered to the upper layers, but still waited for. The first RLC entity 312 updates RX_Next to 2. RX_Next holds a value of an SN following the last in-sequence completely received RLC SDU, and it serves as the lower edge of the receiving window 1520.

[0274] When the reordering timer expires, the first PDCP entity 314 will update the receiving window 1510 by updating RX_DELIV to 5.

[0275] The first PDCP entity 314 transmits the first indication to the first RLC entity 312. Based on the first implementation, the first PDCP entity 314 has the mapping between an RLC SN and a PDCP SN for an RLC SDU. Thus, the first indication may indicate a reference RLC SDU. The reference RLC SDU corresponds to a PDCP PDU with a PDCP SN equal to RX_DELIV. In this example, RX_DELIV=5, and the first indication indicates a reference RLC SDU corresponding to a PDCP PDU with the PDCP SN#5.

[0276] Upon receiving the first indication, the first RLC entity 312 updates the first state variable (RX_Next) to 5 and updates the fourth state variable (RX_Highest_Status) to 7.

[0277] Fig. 16 illustrates an example of updating the first state variable (RX_Next) in accordance with aspects of the present disclosure. In the example of Fig. 16, the first PDCP entity 314 maintains a receiving window 1610, and the first RLC entity 312 maintains a receiving window 1620. The second communication device 320 transmits PDCP data PDUs with PDCP SNs #1, #2, #3, #4, #5 and #6 as well as a PDCP control PDU without PDCP SN to the first communication device 310. The PDCP control PDU is represented by “C” for brevity.

[0278] The PDCP data PDUs with PDCP SNs #1, #3, #4 and #6 as well as the PDCP control PDU are received by the first communication device 310 while the PDCP data PDUs with PDCP SNs #2 and #5 are not completely received by the first communication device 310. Thus, the first PDCP entity 314 updates RX_DELIV to 2 and starts a reordering timer. The first RLC entity 312 updates RX_Next to 2.

[0279] When the reordering timer expires, the first PDCP entity 314 will update the receiving window 1610 by updating RX_DELIV to 5.

[0280] The first PDCP entity 314 transmits the first indication to the first RLC entity 312. Based on the second implementation, the first indication may indicate a reference PDCP PDU. The reference PDCP PDU has a PDCP SN equal to RX_DELIV. In this example, RX_DELIV=5, and the first indication indicates a reference PDCP PDU with the PDCP SN#5.

[0281] Because the first RLC entity 312 maintains the mapping between an RLC SN and a PDCP SN for an RLC SDU, the first RLC entity 312 may determine that the indicated PDCP PDU with the PDCP SN#5 is mapped to an RLC SDU with the RLC  SN#6. Thus, the first RLC entity 312 updates the first state variable (RX_Next) to 6 and updates the fourth state variable (RX_Highest_Status) to 8.

[0282] In some implementations, the first RLC entity 312 may update RX_Next to the SN of the start RLC SDU with SN > RX_Next, for which not all bytes have been received and which is not abandoned or not indicated as abandoned if an RLC SDU with RLC SN equal to or larger than current RX_Next is indicated as abandoned in the first indication from the first PDCP entity, e.g., by performing a procedure in Table 16.

[0283] Table 16

[0284] In some implementations, the first RLC entity 312 abandons the indicated at least one RLC SDU as abandoned by the first PDCP entity 314, for which not all bytes have been received.

[0285] The first RLC entity 312 may update 1440 the fourth state variable (RX_Highest_Status) based on the first indication if the RLC SN of the indicated RLC SDU larger than or equal to the current fourth state variable.

[0286] For example, based on the first implementation, the first RLC entity 312 may update the RX_Highest_Staus to the RLC SN of the start RLC SDU with SN >= the RLC SN of the indicated RLC SDU (i.e., reference RLC SDU) , for which not all bytes have not received. For example, the start RLC SDU is not indicated as abandoned in the first indication.

[0287] For example, in the example of Fig. 15, the first indication indicates the reference RLC SDU which corresponds to the PDCP PDU with the PDCP SN #5, and the RLC SDU with the RLC SN#6 is received. Thus, the first RLC entity 312 updates RX_Highest_Status to 7.

[0288] For another example, in the example of Fig. 16, the first indication indicates the the PDCP PDU with the PDCP SN #5, and the RLC SDU with the RLC SN#7 is received. Thus, the first RLC entity 312 updates RX_Highest_Status to 8.

[0289] In some implementations, further updating is performed if the RLC SN of the indicated RLC SDU (i.e., reference RLC SDU) >= RX_Highest_Status.

[0290] For example, based on the second implementation, the first RLC entity 312 may update the RX_Highest_Staus to the RLC SN of the start RLC SDU with SN >=RLC SN of the indicated RLC SDU (i.e., abandoned RLC SDU) , for which not all bytes have not received. For example, the start RLC SDU is not abandoned or not indicated as abandoned in the first indication.

[0291] In some implementations, further updating is performed if one of the at least one RLC SN of the at least one indicated RLC SDU (i.e., abandoned RLC SDU) >=RX_Highest_Status.

[0292] For example, based on the second implementation, the first RLC entity 312 may update the RX_Highest_Staus to the RLC SN of the start RLC SDU with SN >current RX_Highest_Status, for which not all bytes have not received. For example, the start RLC SDU is not indicated as abandoned in the first indication.

[0293] The first RLC entity 312 may update 1445 the fifth state variable (RX_Next_Status_Trigger) based on the first indication if the RLC SN of the indicated RLC SDU (i.e., reference RLC SDU) >= RX_Next_Status_Trigger.

[0294] For example, based on the first implementation, the first RLC entity 312 may update the RX_Next_Status_Trigger to the RLC SN of the start RLC SDU with SN >=the RLC SN of the indicated RLC SDU (i.e., reference RLC SDU) , for which not all bytes have not received. The start RLC SDU is not abandoned or not indicated as abandoned.

[0295] In some implementations, further updating is performed if the RLC SN of the indicated RLC SDU (i.e., abandoned RLC SDU) >= RX_Next_Status_Trigger.

[0296] For example, based on the second implementation, the first RLC entity 312 may update the RX_Next_Status_Trigger to the RLC SN of the start RLC SDU with RLC SN > current RX_Next_Status_Trigger , for which not all bytes have not received and which is not abandoned or not indicated as abandoned.

[0297] In some implementations, further updating is performed if one of the at least one RLC SN of the at least one indicated RLC SDU >= current RX_Next_Status_Trigger.

[0298] After updating at least one of RX_Next and RX_Next_Status_Trigger, the first RLC entity 312 may determine 1450 whether to stop and reset the t-Reassembly based on RX_Next_Status_Trigger, RX_Next, and whether to start t-Reassembly based on RX_Next_Highest, RX_Next. For example, the first RLC entity 312 may determine whether to stop and reset the t-Reassembly by performing a procedure in Table 17.

[0299] Table 17

[0300] The first RLC entity 312 may transmit 1455 the second report to the second RLC entity 322 based on the first indication. Some implementations of the second report have been described above with reference to Figs. 5 to 13. Such implementations are omitted for brevity.

[0301] Upon receiving the second report, the second RLC entity 322 updates 1460 the sixth state variable (TX_Next_Ack) based on the second report.

[0302] For example, the second RLC entity 322 may update the sixth state variable (TX_Next_Ack) by performing a procedure in Table 18.

[0303] Table 18

[0304] For another example, the second RLC entity 322 may update the sixth state variable (TX_Next_Ack) by performing a procedure in Table 19.

[0305] Table 19

[0306] The second RLC entity 322 may transmit 1465 a report confirm of the received report to the first RLC entity 312. The action 1465 is the same as the action 580 in Fig. 5. Details of this action is omitted for brevity.

[0307] Fig. 17 illustrates a signaling diagram illustrating an example process 1700 that supports avoiding unnecessary retransmission of an RLC PDU in accordance with aspects of the present disclosure. The process 1700 may be considered as an example implementation of the method 400. The process 1700 may involve the first RLC entity 312 of the first communication device 310 as well as the second RLC entity 322 and the  second PDCP entity 324 of the second communication device 320 in Fig. 3. For the purpose of discussion, the process 1700 will be described with reference to Fig. 3.

[0308] Generally, in the process 1700, the first RLC entity 312 may be implemented as the receiving RLC entity 312, and the second RLC entity 322 and the second PDCP entity 324 may be implemented as the transmitting RLC entity 322 and the transmitting PDCP entity 324, respectively.

[0309] In addition, in the process 1700, the first RLC entity 312 determines a first report is received from the second RLC entity 322 and updates the first state variable or determines at least one abandoned RLC SDU based on the first report.

[0310] As shown in Fig. 17, the second PDCP entity 324 starts 1710 a discard timer upon receiving a PDCP SDU from upper layer of the second communication device 320.

[0311] Upon the discard timer expiration, the second PDCP entity 324 discards 17320 the PDCP SDU or PDCP PDU.

[0312] The second PDCP entity 324 transmits 1730 a discard indication to the second RLC entity 322. For example, when the discard timer or discardTimerForLowImportance expires for a PDCP SDU, the second PDCP entity 324 may transmit the discard indication to the second RLC entity 322.

[0313] The second RLC entity 322 discards 1740 the RLC SDU or the RLC PDU based on the discard indication from the second PDCP entity 324.

[0314] In addition, the second RLC entity 322 sets 1750 the sixth state variable (TX_Next_Ack) to the SN of the RLC SDU with the smallest SN, whose SN falls within the range TX_Next_Ack <= SN <= TX_Next and for which a positive acknowledgment has not been received yet, and not abandoned or not indicated as abandoned.

[0315] The second RLC entity 322 transmits 1760 the first report to the first RLC entity 312. The first report indicates at least one abandoned RLC SDU.

[0316] The implementations of the first report may be same as those of the second report as described with reference to Figs. 7, 8, 9 and 10. Details of such implementations are omitted for brevity.

[0317] In some implementations, a polling bit may be comprised in the first report.

[0318] In some implementations, the reporting of the first report may be configured per RLC entity by RRC message from the network entity 102. For example, this is separately configured per UL AM RLC entity.

[0319] Upon receiving the first report, the first RLC entity 312 updates 1770 the first state variable (RX_Next) based on the first report.

[0320] In some implementations, the configuration from the network entity 102 may indicate the first RLC entity 312 to update the first state variable (RX_Next) based on the first report. This may be configured per RLC entity by RRC message from the network entity 102. For example, this is separately configured per DL AM RLC entity.

[0321] In some implementations, the first RLC entity 312 updates the RX_Next to the SN of the start RLC SDU, with SN >= current RX_Next, for which not all bytes have been received and not indicated as abandoned.

[0322] For example, if RX_Next is equal to one of the at least one abandoned RLC SN indicated from the second RLC entity 322, the first RLC entity 312 may update RX_Next to the SN of the first RLC SDU, which is not abandoned or not indicated as abandoned, with SN >= current RX_Next, for which not all bytes have been received and which is not abandoned or not indicated as abandoned. The first RLC entity 312 determines and abandons the at least one RLC SDU based on the first report. For example, after updating RX_Next, if there is an RLC SDU with RLC SN < RX_Next, for which not all bytes are received, the first RLC entity 312 determines the RLC SDU as abandoned.

[0323] If current RX_Next_Highest is equal to or less than one of the at least one abandoned RLC SN, the first RLC entity 312 may update RX_Next_Highest to the SN of the start RLC SDU not indicated in the abandoned, with SN >= current RX_Next_Highest for which not all bytes have been received and which is not abandoned or not indicated as abandoned.

[0324] In some implementations, the first RLC entity 312 may also update the RX_Highest_Status based on the first report.

[0325] In some implementations, the first RLC entity 312 may update the 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 and not abandoned or not indicated as abandoned. For example, if current RX_Highest_Status is equal to one of the  at least one abandoned SN, the first RLC entity 312 may update RX_Highest_Status to the SN of the start RLC SDU not indicated in the abandoned, with SN >= current RX_Highest_Status for which not all bytes have been received and which is not abandoned or not indicated as abandoned.

[0326] In some implementations, after updating at least one of RX_Next or RX_Next_Status_Trigger, the first RLC entity 312 may determine whether to stop and reset t-Reassembly based on the RX_Next and RX_Next_Status_Trigger. For example, the first RLC entity 312 may determine whether to stop and reset t-Reassembly by performing the procedure in Table 4.

[0327] In some implementations, after updating at least one of: RX_Next or RX_Next_Highest, the first RLC entity 312 determines whether to start t-Reassembly based on the RX_Next and RX_Next_Highest. For example, the first RLC entity 312 may determine whether to stop and reset t-Reassembly by performing the procedure in Table 5.

[0328] In some implementations, the first RLC entity 312 may transmit 1780 a report confirm of the received report to the second RLC entity 322. The report confirm indicates whether the first report is received.

[0329] In some implementations, any of the formats as described with reference to Figs. 7 to 13 may be used as a format of the report confirm.

[0330] In some implementations, after reception of the first report or after updating at least one of: the RX_Next, RX_Highest_Status, or RX_Next_Highest based on the first report, the first RLC entity 312 triggers the report confirm with any of the formats as described with reference to Figs. 7 to 11 as explicit confirm and with any of the formats as described with reference to Figs. 12 and 13 as an implicit confirm.

[0331] In some implementations, a report confirm with any of the formats as described with reference to Figs. 7 to 11 may be an explicit confirm, and a report confirm with any of the formats as described with reference to Figs. 12 and 13 may be an implicit confirm.

[0332] In some implementations, the report confirm may be a new indication in a RLC AMD PDU. In some implementations, the report confirm may a new indication in a legacy RLC control PDU (e.g., status report PDU) .

[0333] In some implementations, the report confirm may indicate the last A_SN indicated in the first report or an SN which indicates RX_Next.

[0334] Fig. 18 illustrates a signaling diagram illustrating an example process 1800 that supports avoiding unnecessary retransmission of an RLC PDU in accordance with aspects of the present disclosure. The process 1800 may be considered as an example implementation of the method 400. The process 1800 may involve the first RLC entity 312 and the first PDCP entity 314 of the first communication device 310 as well as the second RLC entity 322 and the second PDCP entity 324 of the second communication device 320 in Fig. 3. For the purpose of discussion, the process 1800 will be described with reference to Fig. 3.

[0335] Generally, in the process 1800, the first RLC entity 312 and the first PDCP entity 314 may be implemented as the receiving RLC entity 312 and the receiving PDCP entity 314 respectively, and the second RLC entity 322 and the second PDCP entity 324 may be implemented as the transmitting RLC entity 322 and the transmitting PDCP entity 324 respectively.

[0336] In addition, in the process 1800, the first PDCP entity 314 receives a PDCP SN gap report from the second PDCP entity 324. The first PDCP entity 314 updates RX_DELIV based on the PDCP SN gap report. After updating RX_DELIV, the first PDCP entity 314 transmits the first indication to the first RLC entity 312 to indicate at least one obsoleted PDCP SDU. The first RLC entity 312 updates at least one of the following based on the first indication: RX_Next, RX_Highest_Status, or RX_Next_Highest.

[0337] The process 1800 is similar to the process 500 in that the first PDCP entity 314 assists the first RLC entity 312 to determine which RLC SDU (s) is to be abandoned. The process 1800 is different from the process 500 in that the first PDCP entity 314 transmits the first indication to the first RLC entity 312 based on the PDCP SN gap report.

[0338] The process 1800 is similar to the process 1400 in that in the first implementation, the first RLC entity 312 may deliver an RLC SDU to the first PDCP entity 314 with an RLC SN of the RLC SDU. Thus, the first PDCP entity 314 may determine mapping between an RLC SN and a PDCP SN for the RLC SDU.

[0339] The process 1800 is also similar to the process 1400 in that in the second implementation, the first RLC entity 312 may maintain 1840 mapping between an RLC SN and a PDCP SN for an RLC SDU. In this implementation, the first RLC entity 312 may deliver the RLC SDU to the first PDCP entity 314 without an RLC SN of the RLC SDU.

[0340] In some implementations, the configuration from the network entity 102 may indicate that the first RLC entity 312 delivers an RLC SDU to the first PDCP entity 314 with an RLC SN of the RLC SDU, or maintains mapping between an RLC SN and a PDCP SN for an RLC SDU. This may be configured per PDCP entity by RRC message from the network entity 102.

[0341] As shown in Fig. 18, upon expiration of a discard timer, the second PDCP entity 324 generates 1810 a PDCP SN gap report.

[0342] In turn, the second PDCP entity 324 transmits 1815 the PDCP SN gap report to the first PDCP entity 314. For example, when the discard timer or discardTimerForLowImportance expires for a PDCP SDU, the second PDCP entity 324 triggers the PDCP SN gap report to the first PDCP entity 314. For example, the second PDCP entity 324 triggers the PDCP SN gap report further when the at least one PDCP SDU is discarded and there is at least one stored PDCP SDU which is associated with a COUNT value larger than the COUNT value associated to the at least one discarded PDCP SDU; and the at least one discarded PDCP SDU has been submitted by the RLC entity to lower layers.

[0343] The second PDCP entity 324 transmits 1820 a discard indication to the second RLC entity 322. For example, when the discard timer or discardTimerForLowImportance expires for a PDCP SDU, the second PDCP entity 324 transmits the discard indication to the second RLC entity 322.

[0344] The second RLC entity 322 discards 1830 at least one RLC PDU based on the discard indication from the second PDCP entity 324.

[0345] The second RLC entity 322 updates 1830 the sixth state variable (TX_Next_Ack) based on the discard indication. For example, the second RLC entity 322 updates, based on the discard indication, the sixth state variable (TX_Next_Ack) to the SN of the RLC SDU with the smallest SN, whose SN falls within the range TX_Next_Ack  <= SN <= TX_Next and for which a positive acknowledgment has not been received yet, and which is not abandoned or not indicated as abandoned.

[0346] Upon reception of the PDCP SN gap report, the first PDCP entity 314 updates 1835 RX_DELIV and transmits 1845 the first indication to the first RLC entity 312.

[0347] Based on the first implementation, the first indication may indicate a reference RLC SDU. The reference RLC SDU corresponds to a PDCP PDU with a PDCP SN equal to RX_DELIV.

[0348] Based on the second implementation, the first indication may indicate the at least one abandoned RLC SDU, which is corresponding to a PDCP SDU with the discard PDCP count (s) indicated in the PDCP SN gap report.

[0349] The first RLC entity 312 updates 1850 the first state variable (RX_Next) based on the first indication. For example, if the first communication device 310 reports the capability to support avoiding unnecessary RLC retransmission, the first RLC entity 312 updates 1850 the first state variable (RX_Next) based on the first indication.

[0350] In some implementations, the configuration from the network entity 102 may indicate that the first RLC entity 312 updates the first state variable (RX_Next) based on the first indication. This may be configured per RLC entity by RRC message from the network entity 102. For example, this is separately configured per DL AM RLC entity.

[0351] In some implementations, if RX_Next is equal to or less than one of at least one RLC SN of the at least one abandoned RLC SDU indicated in the first indication, the first RLC entity 312 updates RX_Next based on the first indication.

[0352] For example, based on the first implementation, the first RLC entity 312 updates RX_Next to the RLC SN of the start RLC SDU, for which not all bytes have not received, which RLC SN >= the RLC SN of the indicated RLC SDU (i.e., the reference RLC SDU) .

[0353] The first RLC entity 312 abandons the at least one RLC SDU based on the first indication. For example, based on the first implementation, the first RLC entity 312 abandons the at least one RLC SDU before the indicated RLC SDU (i.e., with RLC SN <the RLC SN of the reference RLC SDU) , e.g., for which not all bytes have received.

[0354] For example, based on the second implementation, the first RLC entity 312 updates RX_Next to the RLC SN of the start RLC SDU, with RLC SN >= RX_Next, for which not all bytes have not received and is not indicated as abandoned if RX_Next is equal to or less than one of the at least one RLC SN of the at least one RLC SDU indicated as abandoned.

[0355] The first RLC entity 312 abandons the at least one RLC SDU based on the first indication. For example, based on the first implementation, the first RLC entity 312 abandons the at least one indicated RLC SDU (i.e., abandoned RLC SDU) , e.g., for which not all bytes have received.

[0356] The first RLC entity 312 may update the fourth state variable (RX_Highest_Status) based on the first indication.

[0357] For example, based on the first implementation, the first RLC entity 312 updates RX_Highest_Staus to the RLC SN of the start RLC SDU, for which not all bytes have not received, for which RLC SN >= the RLC SN of the indicated RLC SDU (i.e., the reference SDU) .

[0358] For example, based on the second implementation, the first RLC entity 312 updates RX_Highest_Staus to the RLC SN of the start RLC SDU, for which not all bytes have not received and not indicated as abandoned RLC SDU. For example, if current RX_Highest_Status is equal to one of the at least one abandoned RLC SN, the first RLC entity 312 may update RX_Highest_Status to the SN of the first RLC SDU not indicated in the abandoned, with SN >= current RX_Highest_Status, for which not all bytes have been received and which is not abandoned or not indicated as abandoned.

[0359] The first RLC entity 312 may update the third state variable (RX_Next_Highest) based on the first indication.

[0360] For example, if current RX_Next_Highest is equal to one of the at least one abandoned RLC SN, the first RLC entity 312 may update RX_Next_Highest to the SN of the start RLC SDU not indicated in the abandoned, with SN >= current RX_Next_Highest for which not all bytes have been received and which is not indicated as abandoned.

[0361] Further, after updating at least one of RX_Next or RX_Next_Status_Trigger, the first RLC entity 312 may determine whether to stop and reset t-Reassembly based on the RX_Next and RX_Next_Status_Trigger. For example, the first RLC entity 312 may  determine whether to stop and reset t-Reassembly by performing the procedure in Table 4.

[0362] In addition, after updating at least one of: RX_Next or RX_Next_Highest, the first RLC entity 312 may determine whether to start t-Reassembly based on the RX_Next and RX_Next_Highest. For example, the first RLC entity 312 may determine whether to start t-Reassembly by performing the procedure in Table 5.

[0363] Optionally, the first RLC entity 312 may transmit 1855 the second report to peer RLC entity.

[0364] The second report indicates a reference RLC SDU via an RLC SN or indicates the at least one abandoned RLC SDU. For example, at least one abandoned RLC SDU may be the last abandoned RLC SDU. The RLC SN of the reference RLC SDU may be equal to the first state variable (updated RX_Next) based on the first indication from the second PDCP entity 324. Any of the formats as described with reference to Figs. 7 to 13 may be used as a format of the second report.

[0365] In some implementations, the action 1830 may be replace by an action 1860. In the action 1860, the second RLC entity 322 may receive the second report and update the sixth state variable (TX_Next_Ack) based on the second report.

[0366] In some implementations, if receiving the first indication from the first PDCP entity 314, the first RLC entity 312 may perform a procedure in Table 20.

[0367] Table 20

[0368] Fig. 19 illustrates an example of a device 1900 that supports avoiding unnecessary retransmission of an RLC PDU in accordance with aspects of the present disclosure. The device 1900 may be an example of the first communication device 310 or the second communication device 320 as described herein. The device 1900 may support wireless communication with one or more network entities 102, UEs 104, or any combination thereof. The device 1900 may include components for bi-directional communications including components for transmitting and receiving communications, such as a processor 1902, a memory 1904, a transceiver 1906, and, optionally, an I / O controller 1908. These components may be in electronic communication or otherwise  coupled (e.g., operatively, communicatively, functionally, electronically, electrically) via one or more interfaces (e.g., buses) .

[0369] The processor 1902, the memory 1904, the transceiver 1906, or various combinations thereof or various components thereof may be examples of means for performing various aspects of the present disclosure as described herein. For example, the processor 1902, the memory 1904, the transceiver 1906, or various combinations or components thereof may support a method for performing one or more of the operations described herein.

[0370] In some implementations, the processor 1902, the memory 1904, the transceiver 1906, or various combinations or components thereof may be implemented in hardware (e.g., in communications management circuitry) . The hardware may include a processor, a digital signal processor (DSP) , an application-specific integrated circuit (ASIC) , a field-programmable gate array (FPGA) or other programmable logic device, a discrete gate or transistor logic, discrete hardware components, or any combination thereof configured as or otherwise supporting a means for performing the functions described in the present disclosure. In some implementations, the processor 1902 and the memory 1904 coupled with the processor 1902 may be configured to perform one or more of the functions described herein (e.g., executing, by the processor 1902, instructions stored in the memory 1904) .

[0371] For example, the processor 1902 may support wireless communication at the device 1900 in accordance with examples as disclosed herein. The processor 1902 may be configured to operable to support a means for performing the following: determining one of the following at a first RLC entity of the first communication device: a first RLC timer expires, a first indication is received from a first PDCP entity of the first communication device, or a first report is received from a second RLC entity of a second communication device; and updating a first state variable or determine at least one abandoned RLC SDU based on one of the following: expiration of the first RLC timer, the first indication, or the first report. The first state variable holds a value of a first SN following a last in-sequence completely received RLC SDU, and the first state variable serves as a lower edge of a receiving window of the first communication device.

[0372] Alternatively, in some implementations, the processor 1902 may be configured to operable to support a means for performing the following: determining, at  a second RLC entity of a second communication device, at least one of a second report from a first RLC entity of a first communication device or a discard indication from a second PDCP entity of the second communication device is received; and updating a six state variable based on the second report or the discard indication, wherein the six state variable holds a value of a SN of a next RLC SDU for which a positive acknowledgment is to be received in-sequence, and the six state variable serves as a lower edge of a transmitting window of the second communication device.

[0373] The processor 1902 may include an intelligent hardware device (e.g., a general-purpose processor, a DSP, a CPU, a microcontroller, an ASIC, an FPGA, a programmable logic device, a discrete gate or transistor logic component, a discrete hardware component, or any combination thereof) . In some implementations, the processor 1902 may be configured to operate a memory array using a memory controller. In some other implementations, a memory controller may be integrated into the processor 1902. The processor 1902 may be configured to execute computer-readable instructions stored in a memory (e.g., the memory 1904) to cause the device 1900 to perform various functions of the present disclosure.

[0374] The memory 1904 may include random access memory (RAM) and read-only memory (ROM) . The memory 1904 may store computer-readable, computer-executable code including instructions that, when executed by the processor 1902 cause the device 1900 to perform various functions described herein. The code may be stored in a non-transitory computer-readable medium such as system memory or another type of memory. In some implementations, the code may not be directly executable by the processor 1902 but may cause a computer (e.g., when compiled and executed) to perform functions described herein. In some implementations, the memory 1904 may include, among other things, a basic I / O system (BIOS) which may control basic hardware or software operation such as the interaction with peripheral components or devices.

[0375] The I / O controller 1908 may manage input and output signals for the device 1900. The I / O controller 1908 may also manage peripherals not integrated into the device M02. In some implementations, the I / O controller 1908 may represent a physical connection or port to an external peripheral. In some implementations, the I / O controller 1908 may utilize an operating system such as or another known operating system. In some  implementations, the I / O controller 1908 may be implemented as part of a processor, such as the processor 1902. In some implementations, a user may interact with the device 1900 via the I / O controller 1908 or via hardware components controlled by the I / O controller 1908.

[0376] In some implementations, the device 1900 may include a single antenna 1910. However, in some other implementations, the device 1900 may have more than one antenna 1910 (i.e., multiple antennas) , including multiple antenna panels or antenna arrays, which may be capable of concurrently transmitting or receiving multiple wireless transmissions. The transceiver 1906 may communicate bi-directionally, via the one or more antennas 1910, wired, or wireless links as described herein. For example, the transceiver 1906 may represent a wireless transceiver and may communicate bi-directionally with another wireless transceiver. The transceiver 1906 may also include a modem to modulate the packets, to provide the modulated packets to one or more antennas 1910 for transmission, and to demodulate packets received from the one or more antennas 1910. The transceiver 1906 may include one or more transmit chains, one or more receive chains, or a combination thereof.

[0377] A transmit chain may be configured to generate and transmit signals (e.g., control information, data, packets) . The transmit chain may include at least one modulator for modulating data onto a carrier signal, preparing the signal for transmission over a wireless medium. The at least one modulator may be configured to support one or more techniques such as amplitude modulation (AM) , frequency modulation (FM) , or digital modulation schemes like phase-shift keying (PSK) or quadrature amplitude modulation (QAM) . The transmit chain may also include at least one power amplifier configured to amplify the modulated signal to an appropriate power level suitable for transmission over the wireless medium. The transmit chain may also include one or more antennas 1910 for transmitting the amplified signal into the air or wireless medium.

[0378] A receive chain may be configured to receive signals (e.g., control information, data, packets) over a wireless medium. For example, the receive chain may include one or more antennas 1910 for receive the signal over the air or wireless medium. The receive chain may include at least one amplifier (e.g., a low-noise amplifier (LNA) ) configured to amplify the received signal. The receive chain may include at least one demodulator configured to demodulate the receive signal and obtain the transmitted data by reversing  the modulation technique applied during transmission of the signal. The receive chain may include at least one decoder for decoding the processing the demodulated signal to receive the transmitted data.

[0379] Fig. 20 illustrates an example of a processor 2000 that supports avoiding unnecessary retransmission of an RLC PDU in accordance with aspects of the present disclosure. The processor 2000 may be an example of a processor configured to perform various operations in accordance with examples as described herein. The processor 2000 may include a controller 2002 configured to perform various operations in accordance with examples as described herein. The processor 2000 may optionally include at least one memory 2004, such as L1 / L2 / L3 cache. Additionally, or alternatively, the processor 2000 may optionally include one or more arithmetic-logic units (ALUs) 2006. One or more of these components may be in electronic communication or otherwise coupled (e.g., operatively, communicatively, functionally, electronically, electrically) via one or more interfaces (e.g., buses) .

[0380] The processor 2000 may be a processor chipset and include a protocol stack (e.g., a software stack) executed by the processor chipset to perform various operations (e.g., receiving, obtaining, retrieving, transmitting, outputting, forwarding, storing, determining, identifying, accessing, writing, reading) in accordance with examples as described herein. The processor chipset may include one or more cores, one or more caches (e.g., memory local to or included in the processor chipset (e.g., the processor 2000) or other memory (e.g., random access memory (RAM) , read-only memory (ROM) , dynamic RAM (DRAM) , synchronous dynamic RAM (SDRAM) , static RAM (SRAM) , ferroelectric RAM (FeRAM) , magnetic RAM (MRAM) , resistive RAM (RRAM) , flash memory, phase change memory (PCM) , and others) .

[0381] The controller 2002 may be configured to manage and coordinate various operations (e.g., signaling, receiving, obtaining, retrieving, transmitting, outputting, forwarding, storing, determining, identifying, accessing, writing, reading) of the processor 2000 to cause the processor 2000 to support various operations in accordance with examples as described herein. For example, the controller 2002 may operate as a control unit of the processor 2000, generating control signals that manage the operation of various components of the processor 2000. These control signals include enabling or  disabling functional units, selecting data paths, initiating memory access, and coordinating timing of operations.

[0382] The controller 2002 may be configured to fetch (e.g., obtain, retrieve, receive) instructions from the memory 2004 and determine subsequent instruction (s) to be executed to cause the processor 2000 to support various operations in accordance with examples as described herein. The controller 2002 may be configured to track memory address of instructions associated with the memory 2004. The controller 2002 may be configured to decode instructions to determine the operation to be performed and the operands involved. For example, the controller 2002 may be configured to interpret the instruction and determine control signals to be output to other components of the processor 2000 to cause the processor 2000 to support various operations in accordance with examples as described herein. Additionally, or alternatively, the controller 2002 may be configured to manage flow of data within the processor 2000. The controller 2002 may be configured to control transfer of data between registers, arithmetic logic units (ALUs) , and other functional units of the processor 2000.

[0383] The memory 2004 may include one or more caches (e.g., memory local to or included in the processor 2000 or other memory, such RAM, ROM, DRAM, SDRAM, SRAM, MRAM, flash memory, etc. In some implementation, the memory 2004 may reside within or on a processor chipset (e.g., local to the processor 2000) . In some other implementations, the memory 2004 may reside external to the processor chipset (e.g., remote to the processor 2000) .

[0384] The memory 2004 may store computer-readable, computer-executable code including instructions that, when executed by the processor 2000, cause the processor 2000 to perform various functions described herein. The code may be stored in a non-transitory computer-readable medium such as system memory or another type of memory. The controller 2002 and / or the processor 2000 may be configured to execute computer-readable instructions stored in the memory 2004 to cause the processor 2000 to perform various functions. For example, the processor 2000 and / or the controller 2002 may be coupled with or to the memory 2004, the processor 2000, the controller 2002, and the memory 2004 may be configured to perform various functions described herein. In some examples, the processor 2000 may include multiple processors and the memory 2004 may include multiple memories. One or more of the multiple processors may be coupled with  one or more of the multiple memories, which may, individually or collectively, be configured to perform various functions herein.

[0385] The one or more ALUs 2006 may be configured to support various operations in accordance with examples as described herein. In some implementation, the one or more ALUs 2006 may reside within or on a processor chipset (e.g., the processor 2000) . In some other implementations, the one or more ALUs 2006 may reside external to the processor chipset (e.g., the processor 2000) . One or more ALUs 2006 may perform one or more computations such as addition, subtraction, multiplication, and division on data. For example, one or more ALUs 2006 may receive input operands and an operation code, which determines an operation to be executed. One or more ALUs 2006 be configured with a variety of logical and arithmetic circuits, including adders, subtractors, shifters, and logic gates, to process and manipulate the data according to the operation. Additionally, or alternatively, the one or more ALUs 2006 may support logical operations such as AND, OR, exclusive-OR (XOR) , not-OR (NOR) , and not-AND (NAND) , enabling the one or more ALUs 2006 to handle conditional operations, comparisons, and bitwise operations.

[0386] The processor 2000 may support wireless communication in accordance with examples as disclosed herein. The processor 2000 may be configured to operable to support a means for performing the following: determining one of the following at a first RLC entity of the first communication device: a first RLC timer expires, a first indication is received from a first PDCP entity of the first communication device, or a first report is received from a second RLC entity of a second communication device; and updating a first state variable or determine at least one abandoned RLC SDU based on one of the following: expiration of the first RLC timer, the first indication, or the first report. The first state variable holds a value of a first SN following a last in-sequence completely received RLC SDU, and the first state variable serves as a lower edge of a receiving window of the first communication device.

[0387] Alternatively, in some implementations, the processor 2000 may be configured to operable to support a means for performing the following: determining, at a second RLC entity of a second communication device, at least one of a second report from a first RLC entity of a first communication device or a discard indication from a second PDCP entity of the second communication device is received; and updating a six  state variable based on the second report or the discard indication, wherein the six state variable holds a value of a SN of a next RLC SDU for which a positive acknowledgment is to be received in-sequence, and the six state variable serves as a lower edge of a transmitting window of the second communication device.

[0388] Fig. 21 illustrates a flowchart of a method 2100 that supports avoiding unnecessary retransmission of an RLC PDU in accordance with aspects of the present disclosure. The operations of the method 2100 may be implemented by a device or its components as described herein. For example, the operations of the method 2100 may be performed by the second communication device 320 as described herein. In some implementations, the device may execute a set of instructions to control the function elements of the device to perform the described functions. Additionally, or alternatively, the device may perform aspects of the described functions using special-purpose hardware.

[0389] At 2110, the method may include determining, at a second RLC entity of a second communication device, at least one of a second report from a first RLC entity of a first communication device or a discard indication from a second PDCP entity of the second communication device is received. The operations of 2110 may be performed in accordance with examples as described herein. In some implementations, aspects of the operations of 2110 may be performed by the second communication device 320 as described with reference to Fig. 3.

[0390] At 2120, the method may include updating a six state variable based on the second report or the discard indication, wherein the six state variable holds a value of a SN of a next RLC SDU for which a positive acknowledgment is to be received in-sequence, and the six state variable serves as a lower edge of a transmitting window of the second communication device. The operations of 2120 may be performed in accordance with examples as described herein. In some implementations, aspects of the operations of 2120 may be performed by the second communication device 320 as described with reference to Fig. 3.

[0391] Fig. 22 illustrates a flowchart of a method 2200 that supports avoiding unnecessary retransmission of an RLC PDU in accordance with aspects of the present disclosure. The operations of the method 2200 may be implemented by a device or its components as described herein. For example, the operations of the method 2200 may be  performed by the second communication device 320 as described herein. In some implementations, the device may execute a set of instructions to control the function elements of the device to perform the described functions. Additionally, or alternatively, the device may perform aspects of the described functions using special-purpose hardware.

[0392] At 2210, the method may include transmitting a PDCP SN gap report from a second PDCP entity of the second communication device to a first PDCP entity of a first communication device or transmitting a discard indication from the second PDCP entity to a second RLC entity of the second communication device. The operations of 2210 may be performed in accordance with examples as described herein. In some implementations, aspects of the operations of 2210 may be performed by the second communication device 320 as described with reference to Fig. 3.

[0393] At 2220, the method may include receiving a discard indication from the second RLC entity, wherein the discard indication indicates at least one abandoned PDCP PDU. The operations of 2220 may be performed in accordance with examples as described herein. In some implementations, aspects of the operations of 2220 may be performed by the second communication device 320 as described with reference to Fig. 3.

[0394] At 2230, the method may include generating a PDU for an abandoned RLC SDU including a PDCP control PDU. The operations of 2230 may be performed in accordance with examples as described herein. In some implementations, aspects of the operations of 2230 may be performed by the second communication device 320 as described with reference to Fig. 3.

[0395] At 2240, the method may include transmitting the PDU to the second RLC entity. The operations of 2240 may be performed in accordance with examples as described herein. In some implementations, aspects of the operations of 2240 may be performed by the second communication device 320 as described with reference to Fig. 3.

[0396] It shall be noted that implementations of the present disclosure which have been described with reference to Figs. 1 to 18 are also applicable to the device 1900, the processor 2000 and the methods 2100 and 2200.

[0397] It should be noted that the methods described herein describes possible implementations, and that the operations and the steps may be rearranged or otherwise modified and that other implementations are possible. Further, aspects from two or more of the methods may be combined.

[0398] The various illustrative blocks and components described in connection with the disclosure herein may be implemented or performed with a general-purpose processor, a DSP, an ASIC, a CPU, an FPGA or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. A general-purpose processor may be a microprocessor, but in the alternative, the processor may be any processor, controller, microcontroller, or state machine. A processor may also be implemented as a combination of computing devices (e.g., a combination of a DSP and a microprocessor, multiple microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configuration.

[0399] The functions described herein may be implemented in hardware, software executed by a processor, firmware, or any combination thereof. If implemented in software executed by a processor, the functions may be stored on or transmitted over as one or more instructions or code on a computer-readable medium. Other examples and implementations are within the scope of the disclosure and appended claims. For example, due to the nature of software, functions described herein may be implemented using software executed by a processor, hardware, firmware, hardwiring, or combinations of any of these. Features implementing functions may also be physically located at various positions, including being distributed such that portions of functions are implemented at different physical locations.

[0400] Computer-readable media includes both non-transitory computer storage media and communication media including any medium that facilitates transfer of a computer program from one place to another. A non-transitory storage medium may be any available medium that may be accessed by a general-purpose or special-purpose computer. By way of example, non-transitory computer-readable media may include RAM, ROM, electrically erasable programmable ROM (EEPROM) , flash memory, compact disk (CD) ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other non-transitory medium that may be used to carry  or store desired program code means in the form of instructions or data structures and that may be accessed by a general-purpose or special-purpose computer, or a general-purpose or special-purpose processor.

[0401] As used herein, including in the claims, an article “a” before an element is unrestricted and understood to refer to “at least one” of those elements or “one or more” of those elements. The terms “a, ” “at least one, ” “one or more, ” and “at least one of one or more” may be interchangeable. As used herein, including in the claims, “or” as used in a list of items (e.g., a list of items prefaced by a phrase such as “at least one of” or “one or more of” or “one or both of” ) indicates an inclusive list such that, for example, a list of at least one of A, B, or C means A or B or C or AB or AC or BC or ABC (i.e., A and B and C) . Also, as used herein, the phrase “based on” shall not be construed as a reference to a closed set of conditions. For example, an example step that is described as “based on condition A” may be based on both a condition A and a condition B without departing from the scope of the present disclosure. In other words, as used herein, the phrase “based on” shall be construed in the same manner as the phrase “based at least in part on. Further, as used herein, including in the claims, a “set” may include one or more elements.

[0402] The description herein is provided to enable a person having ordinary skill in the art to make or use the disclosure. Various modifications to the disclosure will be apparent to a person having ordinary skill in the art, and the generic principles defined herein may be applied to other variations without departing from the scope of the disclosure. Thus, the disclosure is not limited to the examples and designs described herein but is to be accorded the broadest scope consistent with the principles and novel features disclosed herein.

Claims

1.A first communication device, comprising:a processor; anda transceiver coupled to the processor,wherein the processor is configured to:determine one of the following at a first radio link control (RLC) entity of the first communication device:a first radio link control (RLC) timer expires,a first indication is received from a first packet data convergence protocol (PDCP) entity of the first communication device, ora first report is received from a second RLC entity of a second communication device; andupdate a first state variable or determine at least one abandoned RLC service data unit (SDU) based on one of the following:expiration of the first RLC timer,the first indication, orthe first report;wherein the first state variable holds a value of a first sequence number (SN) following a last in-sequence completely received RLC SDU, and the first state variable serves as a lower edge of a receiving window of the first communication device.2.The first communication device of claim 1, wherein the processor is further configured to:based on determining that a first RLC SDU with an SN greater than the first state variable is received,start the first RLC timer, andset a second state variable to a third state variable, wherein the second state variable holds a value of a second SN following the SN of the RLC SDU which triggered the first RLC timer, and the third state variable holds a value of a third SN following an SN of a second RLC SDU with a highest SN among received RLC SDUs.3.The first communication device of claim 1 or 2, wherein the processor is further configured to:update the first state variable to an SN of a start RLC SDU with the SN equal to or greater than the second state variable, wherein not all bytes of the start RLC SDU have been received by the first communication device.4.The first communication device of claim 3, wherein the processor is configured to update the first state variable further based on determining one of the following:the first state variable is equal to one of at least one RLC SN of the at least one abandoned RLC SDU, orthe first state variable is equal to or less than the SN of a reference RLC SDU.5.The first communication device of claim 2, wherein the processor is further configured to determine that the first RLC SDU with the SN greater than the first state variable is received by:determining that the third state variable is greater than the first state variable.6.The first communication device of claim 1 or 2, wherein the processor is further configured to:update a fourth state variable to an SN of a start RLC SDU with the SN greater than the fourth state variable,wherein not all bytes of the start RLC SDU have been received by the first communication device, and the fourth state variable holds a highest possible value of an SN which can be indicated by a field in a STATUS protocol data unit (PDU) when the STATUS PDU needs to be constructed, the field indicates an SN of a next not received RLC SDU which is not reported as missing in the STATUS PDU.7.The first communication device of claim 1 or 2, wherein the processor is further configured to perform one of the following after updating the first state variable:stop a second RLC timer based on the first state variable and a fifth state variable, wherein the fifth state variable holds a value of an SN following an SN of a third RLC SDU which triggered the second RLC timer, the second timer is used by the first RLC entity to detect loss of RLC PDUs at a lower layer of the first communication device; orbased on determining that the third state variable is greater than the first state variable, start the second RLC timer and set the fifth state variable to the third state variable.8.The first communication device of claim 1 or 2, wherein the processor is further configured to perform at least one of the following before the first RLC timer expires:stop the first RLC timer based on determining that a fourth RLC SDU with an SN equal to the second state variable is received and the SN is equal to the first state variable.9.The first communication device of claim 1, wherein the processor is further configured to:transmit a second report via the transceiver to the second communication device, wherein the second report indicates a reference RLC SDU via an RLC SN or indicates the at least one abandoned RLC SDU.10.The first communication device of claim 1, wherein the processor is further configured to:transmit a second report via the transceiver to the second communication device, wherein the second report is a STATUS protocol data unit (PDU) , the STATUS PDU is used by the first entity to inform the second RLC entity about at least one RLC data PDU that is received successfully, and / or at least one RLC data PDU that has not been completely received except that has not been abandoned.11.The first communication device of claim 1, 9, or 10, wherein the second report is triggered based on determining at least one of the following:the at least one abandoned RLC SDU is determined;the at least one abandoned RLC SDU has not been reported in a second report; orthe first state variable is updated.12.The first communication device of claim 9, wherein the at least one abandoned RLC SDU comprises multiple abandoned RLC SDUs, the second report comprises at least one second filed, each of the at least one second filed indicates one of the multiple abandoned RLC SDUs.13.The first communication device of claim 1, wherein the first indication indicates a reference RLC SDU or the at least one abandoned RLC SDU.14.The first communication device of claim 1, wherein the processor is configured to:deliver an RLC SDU to the first PDCP entity with an RLC SN of the RLC SDU.15.A second communication device, comprising:a processor; anda transceiver coupled to the processor,wherein the processor is configured to:determine, at a second radio link control (RLC) entity of the second communication device, at least one of a second report from a first RLC entity of a first communication device or a discard indication from a second packet data convergence protocol (PDCP) entity of the second communication device is received; andupdate a sixth state variable based on the second report or the discard indication, wherein the sixth state variable holds a value of a sequence number (SN) of a next RLC service data unit (SDU) for which a positive acknowledgment is to be received in-sequence, and the sixth state variable serves as a lower edge of a transmitting window of the second communication device.16.The second communication device of claim 15, wherein the second report indicates a reference RLC SDU via an RLC SN or indicates at least one abandoned RLC SDU.17.The second communication device of claim 15, wherein the processor is further configured to:transmit a second indication from the second RLC entity to the second PDCP entity, wherein the second indication indicates at least one abandoned RLC SDU or at least one abandoned PDCP PDU.18.The second communication device of claim 15, wherein the processor is further configured to:receive, at the second RLC entity from the second PDCP entity, a PDU for an abandoned RLC SDU including a PDCP control PDU.19.A processor for wireless communication, comprising:at least one memory; anda controller coupled with the at least one memory and configured to cause the controller to:determine one of the following at a first radio link control (RLC) entity of a first communication device:a first radio link control (RLC) timer expires,a first indication is received from a first packet data convergence protocol (PDCP) entity of the first communication device, ora first report is received from a second RLC entity of a second communication device; andupdate a first state variable or determine at least one abandoned RLC service data unit (SDU) based on one of the following:expiration of the first RLC timer,the first indication, orthe first report;wherein the first state variable holds a value of a first sequence number (SN) following a last in-sequence completely received RLC SDU, and the first state variable serves as a lower edge of a receiving window of the first communication device.20.A processor for wireless communication, comprising:at least one memory; anda controller coupled with the at least one memory and configured to cause the controller to:determine, at a second radio link control (RLC) entity of a second communication device, at least one of a second report from a first RLC entity of a first communication device or a discard indication from a second packet data convergence protocol (PDCP) entity of the second communication device is received; andupdate a sixth state variable based on the second report or the discard indication, wherein the sixth state variable holds a value of a sequence number (SN) of a next RLC service data unit (SDU) for which a positive acknowledgment is to be received in-sequence, and the sixth state variable serves as a lower edge of a transmitting window of the second communication device.

Images