PDCP reordering enhancements

Abstract

Methods, systems, apparatuses, and computer programs for updating packet data convergence protocol (PDCP) reordering windows are disclosed. In one aspect, a method may include receiving, by a PDCP receiver, a drop indication indicating one or more PDCP PDUs as dropped PDUs; determining, by the PDCP receiver, whether a reorder timer is running; and based on determining that the reordering timer is running, updating, by the PDCP receiver, an upper end of the reordering window to a first value, the first value being determined by adjusting a value of a first state variable based on a number of PDUs subsequently discarded.

Description

Background Art

[0001] Wireless communication networks provide an integrated communication platform and telecommunications services to wireless user equipment. Example telecommunications services include telephony, data (e.g., voice, audio, and / or video data), messaging, Internet access, and / or other services. Wireless communication networks have radio access nodes that exchange radio signals with wireless user equipment using wireless network protocols (such as those described in various telecommunications standards promulgated by the 3rd Generation Partnership Project (3GPP)). Example wireless communication networks include Code Division Multiple Access (CDMA) networks, Time Division Multiple Access (TDMA) networks, Frequency Division Multiple Access (FDMA) networks, Orthogonal Frequency Division Multiple Access (OFDMA) networks, Long Term Evolution (LTE), and 5th Generation New Radio (5G NR). Wireless communication networks use technologies such as OFDM, Multiple-Input Multiple-Output (MIMO), advanced channel decoding, massive MIMO, beamforming, and / or other features to facilitate mobile broadband services. Summary of the Invention

[0002] In XR operations, Packet Data Convergence Protocol (PDCP) operations include a packet discard option where PDUs are discarded on a fairly regular basis such that packet discards are no longer an exceptional event. In conventional PDCP operations, discarding a PDCP SDU that has already been associated with a PDCP SN results in an SN gap in the PDCP data PDUs being sent, which increases the PDCP reordering delay in the receiving PDCP entity. On the other hand, XR requires low latency and should minimize the processing overhead and use of system resources (including memory at the PDCP receiver).

[0003] Conventional systems already have a PDCP transmitter that is plagued by the processing overhead of PDCP packet discards. However, the present disclosure provides systems and methods for minimizing the overhead of the PDCP transmitter caused by PDCP packet discards by enhancing the functionality of the PDCP receiver.

[0004] Specifically, the present disclosure enhances the PDCP receiver to identify and process discarded PDCP PDUs. The discard indication indicates one or more PDCP PDUs that have been identified as discarded by the PDPC transmitter but are still ultimately sent by the PDCP transmitter. Based on the discard indication or based on the packet header of the PDU set, the PDCP receiver may update one or more PDCP state variables, set the boundaries of the PDCP reordering window, process the discarded PDCP PDUs, or a combination thereof. This functionality of the PDCP receiver relieves the PDCP transmitter from performing a discard operation, which is a computationally intensive task because the PDCP transmitter discards the PDCP PDUs may occur after the PDCP PDUs have been encrypted or after the PDCP PDUs are sent to lower layer protocols.

[0005] According to an innovative aspect of the present disclosure, a method for updating a packet data convergence protocol (PDCP) reordering window is disclosed. In one aspect, the method may include: receiving, by a PDCP receiver, a discard indication indicating one or more PDCP PDUs as discarded PDUs; determining, by the PDCP receiver, whether a reordering timer is running; and updating, by the PDCP receiver, an upper end of the reordering window to a first value based on determining that the reordering timer is running, the first value being determined by adjusting a value of a first state variable based on the number of subsequently discarded PDUs.

[0006] Other aspects include apparatus, systems, and computer programs for performing the actions of the aforementioned methods.

[0007] The innovative method may include other optional features. For example, in some implementations, the value of the first state variable corresponds to a sequence count value subsequent to a sequence count value associated with a PDCP data PDU that triggered a reordering timer.

[0008] In some specific implementations, the method may also include: based on determining that the reordering timer is not running, the PDCP receiver updates the lower end of the reordering window to a second value, wherein the second value is determined by adjusting the value of a second state variable based on the number of PDUs subsequently discarded.

[0009] In some implementations, the value of the second state variable corresponds to a sequence count value of a first PDCP SDU that (i) has not been delivered to an upper layer and (ii) is still awaited by a receiving device.

[0010] In some specific implementations, the method further includes: updating, by the PDCP receiver, a value of a third state variable based on a number of consecutively discarded PDUs.

[0011] In some specific implementations, the method may also include: the PDCP receiver (i) determining that the value of the second state variable corresponds to a sequence count value of a first PDCP SDU, which (a) has not been delivered to an upper layer and (b) is still being waited for by a receiving device; and (ii) determining the value of the third state variable based on the number of consecutively discarded PDUs; and based on determining that the value of the second state variable is equal to the value of the third state variable: the PDCP receiver delivers to an upper layer protocol all stored PDCP SDUs having consecutive associated values ​​starting from a sequence number equal to the value of the second state variable, and the PDCP receiver updates the value of the second state variable to the sequence number of the first PDCP SDU that has not yet been delivered to the upper layer.

[0012] In some implementations, the updated value of the second state variable is a sequence number greater than the value of the second state variable before the update.

[0013] In a specific implementation, the stored PDCP SDUs with consecutive associated values ​​are delivered after header decompression.

[0014] According to another innovative aspect of the present disclosure, a method for updating a packet data convergence protocol (PDCP) state variable is disclosed. In one aspect, the method may include: receiving, by a PDCP receiver, a discard indication indicating one or more PDCP PDUs as discarded PDUs; and based on receiving the discard indication, updating, by the PDCP receiver, the values ​​of one or more PDCP state variables based on the received discard indication.

[0015] Other aspects include apparatus, systems, and computer programs for performing the actions of the aforementioned methods.

[0016] The innovative method may include other optional features. For example, in some implementations, the one or more PDCP state variables include a first state variable corresponding to a sequence count value subsequent to a sequence count value associated with a PDCP data PDU that triggered a reordering timer.

[0017] In some implementations, updating the first state variable may include adjusting, by the PDCP receiver, a value of the first state variable based on a number of subsequently discarded PDUs.

[0018] In some implementations, the one or more PDCP state variables include a second state variable corresponding to a sequence count value of a first PDCP SDU that (i) has not been delivered to an upper layer and (ii) is still awaited by a receiving device.

[0019] In some implementations, adjusting the value of the second state variable based on the number of subsequently discarded PDUs includes adding a value corresponding to the number of subsequently discarded PDUs to the value of the second state variable.

[0020] According to another innovative aspect of the present disclosure, a method for processing a packet data convergence protocol (PDCP) PDU indicated to be discarded is disclosed. In one aspect, the method may include the following actions: receiving, by a PDCP receiver, a PDCP PDU that has been indicated to be discarded by a PDCP PDU transmitter; and processing, by the PDCP receiver, the received PDCP PDU.

[0021] Other aspects include apparatus, systems, and computer programs for performing the actions of the aforementioned methods.

[0022] The innovative method may include other optional features. For example, in some implementations, processing the received PDCP PDU by the PDCP receiver includes: discarding the received PDCP PDU by the PDCP receiver.

[0023] In some implementations, discarding, by the PDCP receiver, the received PDCP PDU includes discarding, by the PDCP receiver, the received PDCP PDU only after a predetermined time period has expired after receiving the PDCP PDU.

[0024] In some specific implementations, discarding the received PDCP PDU by the PDCP receiver includes: discarding the received PDCP PDU by the PDCP receiver when receiving the PDCP PDU.

[0025] In some implementations, processing, by the PDCP receiver, the received PDCP PDU may include delivering, by the PDCP receiver, the received PDCP PDU to one or more upper layer protocols.

[0026] In some specific implementations, the method may also include: receiving, by the PDCP receiver, a request to retransmit one or more PDCP PDUs including a received PDCP PDU indicated as discarded; and prohibiting, by the PDCP receiver, the request to retransmit the received PDCP PDU indicated as discarded to prevent it from being sent to the PDCP transmitter.

[0027] The details of one or more embodiments of these systems and methods are set forth in the following drawings and description. Other features, objects, and advantages of these systems and methods will be apparent from the description and drawings, and from the claims. BRIEF DESCRIPTION OF THE DRAWINGS

[0028] Figure 1 Illustrates a wireless network according to some embodiments.

[0029] Figure 2 Is a flowchart of a process by which a PDCP receiver updates PDCP state variables based on a received discard indication.

[0030] Figure 3 Is a flowchart of a process by which a PDCP receiver sets the boundaries of a PDCP reordering window using the updated PDCP state variables.

[0031] Figure 4 Is a flowchart of a process by which a PDCP receiver processes discarded PDCP PDUs.

[0032] Figure 5 Illustrates a user equipment (UE) according to some embodiments.

[0033] Figure 6 Illustrates an access node according to some embodiments. Detailed Description

[0034] The present disclosure relates to apparatuses, systems, and methods for a PDCP receiver to identify and process discarded PDCP PDUs. The PDCP receiver may receive a discard indication from a PDCP transmitter, the discard indication indicating one or more PDCP PDUs that have been identified by the PDCP transmitter as discarded but are still being transmitted by the PDCP transmitter.

[0035] Alternatively, in some cases, the PDCP receiver may infer discarded packets (or identify sequence number gaps) from a packet header associated with a set of PDUs. The PDCP receiver may then update one or more PDCP state variables based on receiving the discard indication, set the boundaries of a PDCP reordering window, process one or more discarded PDCP PDU packets, or a combination thereof.

[0036] This PDCP receiver functionality provides a technical improvement to the overall communication system because it minimizes the processing overhead associated with discarded PDCP PDUs. For example, in a conventional communication system, when packet discard occurs after the PDU has been encrypted, or when the PDU to be discarded has already been submitted to a lower layer and the PDU is already part of a time-critical operation in the RLC (with assigned state variables) or MAC (LCP is running, MAC PDU generation is in progress, etc.), the discard can be complex (involving concurrency, resulting in high CPU load) and computationally intensive at the transmitter.

[0037] This reduction in processing overhead results in an overall PDCP reordering delay during packet drops. Such a reduction in the overall PDCP reordering delay is essential for XR communications that require low latency.

[0038] Figure 1 Illustrated is a wireless network 100 according to some specific implementations. The wireless network 100 includes a UE 102 and a base station 104 connected via one or more channels 106A, 106B across an air interface 108. The UE 102 and the base station 104 communicate using a system that supports control for managing access of the UE 102 to the network via the base station 104.

[0039] In some specific implementations, the wireless network 100 can be a non-standalone (NSA) network that combines Long Term Evolution (LTE) and Fifth Generation (5G) New Radio (NR) communication standards as defined by the technical specifications of the Third Generation Partnership Project (3GPP). For example, the wireless network 100 can be an E-UTRA (Evolved Universal Terrestrial Radio Access)-NR Dual Connectivity (EN-DC) network or an NR-EUTRA Dual Connectivity (NE-DC) network. However, the wireless network 100 can also be a standalone (SA) network that combines only 5G NR. Additionally, other types of communication standards are possible, including future 3GPP systems (e.g., Sixth Generation (6G)) systems, Institute of Electrical and Electronics Engineers (IEEE) 802.11 technologies (e.g., IEEE 802.11a; IEEE 802.11b; IEEE 802.11g; IEEE 802.11-2007; IEEE 802.11n; IEEE 802.11-2012; IEEE 802.11ac; or other currently or future developed IEEE 802.11 technologies), IEEE 802.16 protocols (e.g., WMAN, WiMAX, etc.), etc. Although terms commonly associated with 5G NR may be used herein to describe aspects, aspects of the present disclosure can be applied to other systems, such as 3G, 4G, and / or systems after 5G (e.g., 6G).

[0040] In wireless network 100, UE 102 and any other UE in the system can be, for example, a laptop computer, a smart phone, a tablet computer, a machine type device such as a smart meter for healthcare or a dedicated device, a smart transportation system, or any other wireless device with or without a user interface. In network 100, base station 104 provides a network connection for UE 102 to a wider network (not shown). This UE 102 connection is provided via air interface 108 in the base station service area provided by base station 104. In some specific implementations, such a wider network can be a wide area network operated by a cellular network provider, or can be the Internet. Each base station service area associated with base station 104 is supported by an antenna integrated with base station 104. The service area is divided into multiple sectors associated with certain antennas. Such sectors can be physically associated with fixed antennas, or can be assigned to physical areas with tunable antennas or antenna settings that can be adjusted during the beamforming process for directing signals to a specific sector.

[0041] UE 102 includes control circuit 110 coupled to transmit circuit 112 and receive circuit 114. Transmit circuit 112 and receive circuit 114 can each be coupled to one or more antennas. Control circuit 110 can include various combinations of dedicated circuits and baseband circuits. Transmit circuit 112 and receive circuit 114 can be respectively adapted to transmit and receive data, and can include radio frequency (RF) circuits or front-end module (FEM) circuits.

[0042] In various specific implementations, aspects of transmit circuit 112, receive circuit 114, and control circuit 110 can be integrated in various ways to implement the operations described herein. Control circuit 110 can be adapted or configured to perform various operations, such as operations related to the UE described elsewhere in this disclosure. For example, when UE 102 is a PDCP receiver, control circuit 110 can perform operations related to updating PDCP state variables, updating the boundaries of the PDCP reordering window, handling discarded PDCP PDUs, or combinations thereof. These operations can include, for example Figures 2 to 4 one or more operations of one or more of the figures in

[0043] Transmit circuit 112 can perform various operations described in this specification. For example, when the UE is a PDCP transmitter, transmit circuit 112 can, for example, transmit discard indications, one or more discarded PDCP PDUs, or combinations thereof. Additionally, transmit circuit 112 can transmit multiple multiplexed uplink physical channels. The multiple uplink physical channels can be multiplexed according to time-division multiplexing (TDM) or frequency-division multiplexing (FDM) and carrier aggregation. Transmit circuit 112 can be configured to receive block data from control circuit 110 for transmission across air interface 108.

[0044] The receiving circuit 114 can perform various operations described in this specification. For example, when the UE is a PDCP receiver, the UE can use the receiving circuit 114 to receive discard indications and one or more discarded PDCP PDUs. Additionally, the receiving circuit 114 can receive multiple multiplexed downlink physical channels from the air interface 108 and relay these physical channels to the control circuit 110. The multiple downlink physical channels can be multiplexed according to TDM or FDM and carrier aggregation. The transmitting circuit 112 and the receiving circuit 114 can transmit and receive both control data and content data (e.g., messages, images, videos, etc.) structured within data blocks carried by the physical channels.

[0045] Figure 1 The base station 104 is also illustrated. In a particular implementation, the base station 104 can be an NG radio access network (RAN) or 5G RAN, E-UTRAN, a non-terrestrial cell, or a traditional RAN such as UTRAN or GERAN. As used herein, the term "NG RAN" etc. can refer to the base station 104 operating in the NR or 5G wireless network 100, and the term "E-UTRAN" etc. can refer to the base station 104 operating in the LTE or 4G wireless network 100. The UE 102 utilizes connections (or channels) 106A, 106B, each connection including a physical communication interface or layer.

[0046] The base station 104 circuitry can include a control circuit 116 coupled to a transmitting circuit 118 and a receiving circuit 120. The transmitting circuit 118 and the receiving circuit 120 can each be coupled to one or more antennas, which can be used to enable communication via the air interface 108. The transmitting circuit 118 and the receiving circuit 120 can be adapted to transmit and receive data to and from any UE connected to the base station 104, respectively. The transmitting circuit 118 can transmit downlink physical channels including multiple downlink subframes. Additionally, for example, when the base station 104 is a PDCP transmitter, the base station can use the transmitting circuit 118 to, for example, transmit discard indications, one or more discarded PDCP PDUs, or a combination thereof. The base station 104 can use the receiving circuit 120 to receive multiple uplink physical channels from various UEs including the UE 102. Additionally, when the base station 104 is a PDCP receiver, the base station 104 can use the receiving circuit 120 to receive or detect discard indications, one or more discarded PDCP PDUs, or both. Additionally, when the base station 104 is a PDCP receiver, the base station 104 can use the control circuit to perform operations related to updating PDCP state variables, updating the boundaries of the PDCP reordering window, processing discarded PDCP PDUs, or a combination thereof. These operations can include, for example Figures 2 to 4 one or more of the operations.

[0047] In Figure 1 one or more channels 106A, 106B are shown to implement an air interface for communication coupling and may conform to cellular communication protocols such as GSM protocol, CDMA network protocol, UMTS protocol, 3GPP LTE protocol, Advanced Long Term Evolution (LTE-A) protocol, LTE-based Unlicensed Spectrum Access (LTE-U), 5G protocol, NR protocol, NR-based Unlicensed Spectrum Access (NR-U) protocol, and / or any other communication protocol discussed herein. In a particular implementation, the UE 102 may directly exchange communication data via the ProSe interface. The ProSe interface may alternatively be referred to as a sidelink (SL) interface and may include one or more logical channels including, but not limited to, Physical Sidelink Control Channel (PSCCH), Physical Sidelink Control Channel (PSCCH), Physical Sidelink Discovery Channel (PSDCH), and Physical Sidelink Broadcast Channel (PSBCH).

[0048] Discard indicator

[0049] Most packets (a complete set of PDUs or certain PDUs of a set of PDUs) may be discarded at the PDCP layer. To assist the reordering function at the PDCP receiver to minimize the reordering delay, a discard indicator may be used to notify the receiver of the discarded PDCP PDUs. The discard indicator may be generated by the PDCP transmitter and indicates one or more PDCP PDUs that the PDCP transmitter has determined should be discarded. In some particular implementations, the discard indicator may use the PDCP PDU sequence number (SN) or PDCP COUNT range to indicate the range of PDCP PDUs that have been discarded by the PDCP transmitter.

[0050] In some particular implementations, a control PDU or a status PDU may be used to implement the discard indicator. In other particular implementations, the PDCP PDU header information may be used to indicate the packets to be discarded.

[0051] Based on receiving one or more discard indicators, the PDCP receiver may consider the PDUs discarded by the PDCP transmitter as part of the receive operation, reordering, and in-order delivery. The SN gap associated with the discarded PDUs does not trigger an out-of-order operation. In other words, the received PDUs are considered in order despite the SN gap. In some instances, this may include updating the PDCP receive state variables regarding the reordering window and the next expected SN.

[0052] In addition, for SDUs or PDUs that are intended to be discarded but are submitted by the PDCP transmitter to the lower layer, the receiver may perform the discard at the receiving end. Alternatively, the receiver may decide to still deliver the PDCP SDUs that are to be discarded to the upper layer (e.g., based on a specific implementation or based on a network configuration (for a UE) or an operator configuration (for a gNB)).

[0053] PDCP reordering window

[0054] The NR PDCP Window_Size parameter indicates the size of the reordering window. The reordering window can be configured by the network based on the sequence number space. In some specific implementations, for a signaling radio bearer (SRB) / data radio bearer (DRB) / MBS radio bearer (MRB), the parameter Window_Size value is equal to 2 pdcp-SN-SizeDL -1. The PDCP-config for a specific SRB / DRB / MRB can be used to set the parameter PDCP-SN-SIZEDL.

[0055] PDCP status variables

[0056] The PDCP receiver may track multiple different PDCP status variables with corresponding values. The list of PDCP status variables tracked by the PDCP receiver may include TX_NEXT, RX_NEXT, RX DELIV, and RX REORD.

[0057] TX_NEXT is a PDCP status variable that indicates the COUNT value of the next PDCP SDU to be sent. RX_NEXT is a PDCP status variable that indicates the COUNT value of the next PDCP SDU expected to be received. RX_DELIV is a PDCP status variable that indicates the COUNT value of the first PDCP SDU that has not been delivered to the upper layer but is still being awaited. RX_DELIV indicates the lower end of the PDCP reordering window. RX_REORD is a PDCP status variable that indicates the COUNT value after the COUNT value associated with the PDCP data PDU that triggered the t-Reordering reordering timer. RX_REORD indicates the upper end of the reordering window. The specification definitions of these PDCP status variables are provided in more detail in clause 7.1 of TS 38.323.

[0058] In the present disclosure, new PDCP status variables are also proposed for some specific implementations. The new PDCP status variable may be referred to as RX_DISCARD herein. RX_DISCARD may indicate the number of consecutively discarded PDCP PDUs. The RX_DISCARD PDCP status variable may be updated based on the discard indication received by the PDCP transmitter and reset to 0 after the reordering operation (with respect to discard) is completed.

[0059] Update the PDCP variable regardless of whether the reordering timer is running

[0060] Figure 2 FIG. 200 is a flowchart of a process 200 for updating a PDCP status variable by a PDCP receiver based on a received discard indication. Process 200 will be described herein as being performed by a PDCP receiver that receives a PDCP discard indication from a PDCP transmitter. For the purposes of the present disclosure, the PDCP receiver may be a UE or a base station that receives a PDCP discard indication from a PDCP transmitter. Similarly, the PDCP transmitter may be a UE or a base station that sends a PDCP discard indication and one or more discarded PDCP PDUs to the PDCP receiver, and the PDCP receiver may be a UE or a base station. Thus, the communication between the PDCP transmitter and the PDCP receiver may be between UE-to-base station communication, base station-to-UE communication, or UE-to-UE communication. In some cases, the PDCP receiver may be able to infer the number of discarded packets by observing the regular packet headers of a set of PDUs, where the regular packet headers may include a PDU set end indication for one set of PDUs and a PDU set start indication for the next set of PDUs, and the two sets of PDUs are in sequence, but the PDCP sequence numbers associated with the last PDU set header of PDU set 1 and the first PDU set header of PDU set 2 are not in sequence. From the perspective of the receiver, this may provide information similar to a discard indication.

[0061] The PDCP receiver may start performing process 200 (210) by receiving a discard indication that indicates one or more PDCP PDUs as discarded PDUs.

[0062] Then, based on the received discard indication, the PDCP receiver may continue performing process 200 (220) by updating the values of one or more PDCP status variables based on the received discard indication.

[0063] In some specific implementations, one or more PDCP status variables may include a first status variable that corresponds to the sequence count value following the sequence count value associated with the PDCP data PDU that triggered the reordering timer. The first status variable may correspond to the RX_REORD PDCP status variable. In such specific implementations, updating the first status variable may include the PDCP receiver adjusting the value of the first status variable based on the number of subsequently discarded PDUs.

[0064] In some specific implementations, one or more PDCP status variables may include a second status variable that corresponds to the sequence count value of a first PDCP SDU that (i) has not been delivered to the upper layer and (ii) is still being awaited by the receiving device. The second status variable may correspond to the RX_DELIV_PDCP status variable. In such specific implementations, updating the second status variable may include the PDCP receiver adjusting the value of the second status variable based on the number of subsequently discarded PDUs.

[0065] Updating the boundaries of the PDCP reordering window

[0066] In some specific implementations, to make the PDCP receiver aware of the range of received PDCP PDU sequence numbers (SNs) or COUNTs that have been discarded at the transmitter, the receiver can utilize this information to minimize the reordering delay.

[0067] The COUNT value is a 32-bit value that increments in a cyclic manner, while the value range of the PDCP sequence number (SN) depends on the network configuration. The PDCP sequence number (SN) can be 12 or 18 bits, as defined in clause 6.3 of TS 38.323.

[0068] The COUNT value consists of the HFN and the PDCP SN. The size of the HFN part (in bits) is equal to 32 minus the length of the PDCP SN.

[0069] In some specific implementations, for example, when receiving a discard indication from the transmitter, the PDCP receiver may treat the last PDU (or packet) before the range of discarded SNs and the first PDU (or packet) after the range of discarded SNs as in-sequence. Then, the PDCP receiver may update the PDCP reordering window. In some specific implementations, the PDCP receiver may determine whether to update the upper boundary or the lower boundary of the PDCP reordering window based on whether a reordering timer such as t-Reordering is running.

[0070] If a reordering timer such as t-Reordering is not running, considering modulo arithmetic, the PDCP receiver may update the lower end RX_DELIV of the reordering window to: RX_DELIV = RX_DELIV + x, where x is the number of PDUs (or packets) subsequently discarded in one or more PDU sets. Here, "subsequently discarded" means after the last packet before the SN gap. In some specific implementations, the PDCP receiver may perform this update of the lower end of the reordering window during any part of the PDCP operation. In other specific implementations, the PDCP receiver may perform this update of the lower end of the reordering window during clause 5.2.2 of 38.323 that defines the PDCP reception operation.

[0071] Alternatively, if a reordering timer such as t-Reordering is running, considering modulo arithmetic, the PDCP receiver may update the upper end RX_REORD of the reordering window to: RX_REORD = RX_REORD + x, where x is the number of PDUs (or packets) subsequently discarded in one or more PDU sets. In some specific implementations, the PDCP receiver may perform this update of the upper end of the reordering window during any part of the PDCP operation. In other specific implementations, the PDCP receiver may perform this update of the lower end of the reordering window during clause 5.2.2 of 38.323 that defines the PDCP reception operation.

[0072] In some specific implementations, the PDCP receiver may have to adjust a part of the PDCP reception operation, such as the PDCP reception operation described by clause 5.2.2 of 38.323. For example, when T-Reordering is running, the skipped SNs refer to the discarded PDCP PDU / COUNT values pointed to by the discard indication (discard flag) from the transmitter. In some specific implementations, the number of continuously discarded PDUs may also be stored in a new PDCP status variable, which is updated according to the discard indication and reset to 0 after the reordering operation (regarding discard) is completed.

[0073] In some specific implementations, a new PDCP status variable RX_DISCARD may be used to store the number of continuously discarded PDUs.

[0074] In some specific implementations, if RCVD_COUNT = RX_DELIV, the PDCP receiver may, after performing header decompression (if not already decompressed), deliver to the upper layer in ascending order of the associated sequence number or COUNT value all stored PDCP SDUs with consecutive associated COUNT values starting from COUNT = RX_DELIV (by skipping the SNs indicated as discarded). Then, the PDCP receiver may update RX_DELIV to the COUNT value of the first PDCP SDU that has not been delivered to the upper layer, where the COUNT value > RX_DELIV.

[0075] In such specific implementations, a discard indication may be received from the transmitter while the reordering process is already in progress. For the case where the discard indication is already available before the first packet is received (e.g., when the receive buffer is empty and all packets have been delivered to the upper layer), the receiver may directly update the SN position based on the received discard status, e.g., by updating RX_DELIV (for the case where t_Reordering is not running).

[0076] Figure 3 FIG. 300 is a flow chart of a process 300 in which the PDCP receiver sets the boundaries of the PDCP reordering window using updated PDCP state variables. Process 300 will be described herein as being performed by a PDCP receiver that receives a PDCP discard indication from a PDCP transmitter. For the purposes of this disclosure, the PDCP receiver may be a UE or a base station that receives a PDCP discard indication from a PDCP transmitter. Similarly, the PDCP transmitter may be a UE or a base station that sends a PDCP discard indication and one or more discarded PDCP PDUs to a PDCP receiver, which may be a UE or a base station. Thus, the communication between the PDCP transmitter and the PDCP receiver may be between UE-to-base station communication, base station-to-UE communication, or UE-to-UE communication.

[0077] The PDCP receiver may start executing process 300 (310) by receiving a discard indication that indicates one or more PDCP PDUs as discarded PDUs.

[0078] The PDCP receiver may continue executing process 300 (320) by determining, by the PDCP receiver, whether the reordering timer is running.

[0079] Then, based on the PDCP receiver determining at stage 320 that the reordering timer is running, the PDPC receiver may continue to execute process 300 at stage 330a by updating the upper end of the reordering window to a first value that is determined by adjusting the value of a first state variable based on the number of subsequently discarded PDUs. In such an embodiment, the value of the first state variable corresponds to the sequence count value after the sequence count value associated with the PDCP data PDU that triggered the reordering timer. The first state variable may be the RX_REORD PDCP state variable. In some embodiments, adjusting the value of the first state variable (such as RX_REORD) based on the number of subsequently discarded PDUs may include adding the number of subsequently discarded PDUs to the value of RX_REORD.

[0080] Alternatively, based on the PDCP receiver determining at stage 320 that the reordering timer is not running, the PDCP receiver may continue to execute process 300 at stage 330b by updating the lower end of the reordering window to a second value that is determined by adjusting the value of a second state variable based on the number of subsequently discarded PDUs. In such an embodiment, the value of the second state variable corresponds to the sequence count value of a first PDCP SDU that (i) has not been delivered to the upper layer and (ii) is still being awaited by the receiving device. The second state variable may be the RX_DELIV_PDCP state variable. In some embodiments, adjusting the value of the second state variable (such as RX_DELIV) based on the number of subsequently discarded PDUs may include adding the number of subsequently discarded PDUs to the value of RX_DELIV.

[0081] In some embodiments, the PDCP receiver may continue to execute process 300 by updating the value of a third state variable based on the number of consecutively discarded PDUs. The third state variable may include a new PDCP state variable RX_DISCARD proposed by the present disclosure.

[0082] In some specific embodiments, the PDCP receiver may continue to perform process 300 in the following manner: (i) determining that the value of a second state variable corresponds to the sequence count value of a first PDCP SDU that (a) has not been delivered to the upper layer and (b) is still awaited by the receiving device; and (ii) determining the value of a third state variable based on the number of PDUs that have been consecutively discarded in the PDU set. Then, based on the PDCP receiver determining that the value of the second state variable is equal to the value of the third state variable, the PDCP receiver may continue to perform process 300 in the following manner: delivering to the upper layer protocol all stored PDCP SDUs having consecutive associated values starting from the sequence number equal to the value of the second state variable; and updating, by the PDCP receiver, the value of the second state variable to the sequence number of the first PDCP SDU that has not yet been delivered to the upper layer. In some specific embodiments, the updated value of the second state variable is a sequence number greater than the value of the second state variable before the update.

[0083] In some specific embodiments, stored PDCP SDUs having consecutive associated values are delivered after header decompression.

[0084] Processing of discarded PDCP PDUs by the PDCP receiver

[0085] In a specific embodiment, the transmitter may still deliver some or all of the discarded PDUs, even if they have been signaled or declared as discarded. For example, when packet discarding occurs after the PDU has been encrypted, or when the PDU to be discarded has been submitted to the lower layer and the PDU is already part of a time-critical operation in the RLC (with an assigned state variable) or MAC (LCP is running, generation of MAC PDUs is in progress, etc.), the discarding may be more complex (involving concurrency and thus resulting in high CPU load), so the transmitter may still transmit those PDUs. Thus, generally speaking, the more discarded PDUs that are sent to the PDCP receiver for processing (and thus not discarded by the PDCP transmitter), the greater the reduction in overhead processing by the PDCP transmitter.

[0086] When a PDU that has been indicated or declared as discarded (e.g., by the transmitter) is received, the receiver may discard the PDU or deliver it to the upper layer. The discarding of such PDUs may have occurred at the MAC (to prevent subsequent processing in the upper layer), but may also be done in the RLC or PDCP. The main assumption (applicable to this disclosure) is that the discarding occurs in the PDCP receiver.

[0087] Thus, in some specific implementations, the PDCP receiver may discard PDCP PDUs indicated for discard by the discard indicator. This option helps save resources at the next hop and is preferred. Alternatively, in some specific implementations, the receiver may still deliver to the upper layer PDCP PDUs indicated for discard by the discard indicator. This alternative option minimizes the impact on existing specifications and still provides some redundancy. Any of these alternatives may be implemented through explicit network configuration or defined in the specification.

[0088] In yet another alternative, the PDCP transmitter may notify the PDCP receiver of PDCP packets that have expired but that the PDCP transmitter will continue to send, for example, due to the above constraints. In this case, the PDCP receiver may decide how to handle these packets. For example, it may wait for a predetermined amount of time to discard PDCP packets indicated as being discarded or expired, or directly discard PDCP packets indicated as being discarded or expired (e.g., discard immediately without waiting for a predetermined amount of time).

[0089] In a conventional system, for an AM DRB, when the upper layer requests PDCP data recovery for a radio bearer, the sender PDCP entity will retransmit all PDCP data PDUs previously submitted to a reconstructed or released AM RLC entity in ascending order of the associated COUNT value, where successful delivery has not been confirmed by the lower layer following the data submission procedure in Clause 5.2.1.

[0090] However, when the upper layer requests PDCP data recovery for a radio bearer after packet discard and assuming that the RLC / MAC layer did in fact send some of the discarded PDUs earlier (e.g., to minimize the SN gap in the RLC or to minimize complexity), retransmitting those discarded PDUs is a waste and can be avoided. Thus, the specification can be extended to avoid this situation regarding discarded PDUs stored in the lower layer, as it is expected that discard will occur on a more regular basis compared to earlier versions.

[0091] Furthermore, from the perspective of the upper layer, it is clear that the data recovery process should not first request recovery of discarded packets. But there may still be packets stored at the lower layer.

[0092] Figure 4FIG. 400 is a flow chart of a process 400 in which a PDCP receiver processes discarded PDCP PDUs. Process 400 will be described herein as being performed by a PDCP receiver that receives a PDCP discard indication from a PDCP transmitter. For purposes of this disclosure, the PDCP receiver can be a UE or a base station that receives a PDCP discard indication from a PDCP transmitter. Similarly, the PDCP transmitter can be a UE or a base station that sends a PDCP discard indication and one or more discarded PDCP PDUs to a PDCP receiver, which can be a UE or a base station. Thus, the communication between the PDCP transmitter and the PDCP receiver can be between UE-to-base station communication, base station-to-UE communication, or UE-to-UE communication.

[0093] The PDCP receiver can begin to perform process 400 (410) by receiving a PDCP PDU that has been indicated as discarded by the PDCP PDU transmitter.

[0094] The PDCP receiver can continue to perform process 400 by processing the received PDCP PDU. In some embodiments, processing the received PDCP PDU by the PDCP receiver can include the PDCP receiver discarding the received PDCP PDU. In some embodiments, discarding the received PDCP PDU can include the PDCP receiver discarding the received PDCP PDU only after a predetermined time period has elapsed after receiving the PDCP PDU. Alternatively, in other embodiments, discarding the received PDCP PDU by the PDCP receiver can include the PDCP receiver immediately discarding the received PDCP PDU upon receipt.

[0095] Alternatively, in other embodiments, processing the received PDCP PDU by the PDCP receiver can include the PDCP receiver delivering the received PDCP PDU to one or more upper layer protocols.

[0096] In some embodiments, the performance of process 400 can include: the PDCP receiver receiving a request to retransmit one or more PDCP PDUs including the received PDCP PDU indicated as discarded; and the PDCP receiver prohibiting the request to retransmit the received PDCP PDU indicated as discarded to prevent it from being sent to the PDCP transmitter.

[0097] Figure 5 Illustrates a UE 500 according to some embodiments. UE 500 can be similar to Figure 1 UE 102 and can be substantially interchangeable therewith.

[0098] The UE 500 can be any mobile or non-mobile computing device, such as, for example, a mobile phone, a computer, a tablet, an industrial wireless sensor (e.g., a microphone, a pressure sensor, a thermometer, a motion sensor, an accelerometer, an inventory sensor, a voltage / current meter, etc.), a video device (e.g., a camera, a video camera, etc.), a wearable device (e.g., a smart watch), a loose IoT device.

[0099] The UE 500 can include a processor 502, an RF interface circuit 504, a memory / storage 506, a user interface 508, sensors 510, a driver circuit 512, a power management integrated circuit (PMIC) 514, an antenna structure 516, and a battery 518. The components of the UE 500 can be implemented as integrated circuits (ICs), parts of integrated circuits, discrete electronic devices, or other modules, logic components, hardware, software, firmware, or combinations thereof. Figure 5 The block diagram is intended to show a high-level view of some of the components of the UE 500. However, some of the shown components may be omitted, additional components may exist, and different arrangements of the shown components may occur in other specific implementations.

[0100] The components of the UE 500 can be coupled to various other components through one or more interconnects 520, which can represent any type of interface, input / output terminal, bus (local, system, or expansion), transmission line, trace, optical connection, etc., that allows various circuit components (on common or different chips or chip sets) to interact with each other.

[0101] The processor 502 can include processor circuitry, such as, for example, a baseband processor circuit (BB) 522A, a central processing unit circuit (CPU) 522B, and a graphics processing unit circuit (GPU) 522C. The processor 502 can include any type of circuit or processor circuitry that executes or otherwise operates computer-executable instructions (such as program code, software modules, or functional processes from the memory / storage 506) to cause the UE 500 to perform the operations described herein.

[0102] In some embodiments, the baseband processor circuit 522A may access the communication protocol stack 524 in the memory / storage 506 to communicate via a 3GPP-compliant network. Generally, the baseband processor circuit 522A may access the communication protocol stack to: perform user plane functions at the physical (PHY) layer, medium access control (MAC) layer, radio link control (RLC) layer, packet data convergence protocol (PDCP) layer, service data adaptation protocol (SDAP) layer, and PDU layer; and perform control plane functions at the PHY layer, MAC layer, RLC layer, PDCP layer, RRC layer, and non-access stratum. In some embodiments, the PHY layer operations may additionally / alternatively be performed by components of the RF interface circuit 504. The baseband processor circuit 522A may generate or process baseband signals or waveforms that carry information in a 3GPP-compliant network. In some embodiments, the waveforms for NR may be based on cyclic prefix orthogonal frequency division multiplexing (OFDM) “CP-OFDM” in the uplink or downlink, and discrete Fourier transform spread OFDM “DFT-S-OFDM” in the uplink.

[0103] The memory / storage 506 may include one or more non-transitory computer-readable media that include instructions (e.g., the communication protocol stack 524) that may be executed by one or more of the processors in the processor 502 to cause the UE 500 to perform the various operations described herein. The memory / storage 506 includes any type of volatile or non-volatile memory that may be distributed throughout the UE 500. In some embodiments, some of the memory / storage in the memory / storage 506 may be located on the processor 502 itself (e.g., L1 cache and L2 cache), while other memory / storage 506 is located external to the processor 502 but may be accessed via a memory interface. The memory / storage 506 may include any suitable volatile or non-volatile memory, such as but not limited to dynamic random access memory (DRAM), static random access memory (SRAM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), flash memory, solid state memory, or any other type of memory device technology.

[0104] The RF interface circuit 504 may include transceiver circuitry and a radio frequency front-end module (RFEM) that allows the UE 500 to communicate with other devices via a radio access network. The RF interface circuit 504 may include various elements arranged in a transmit path or a receive path. These elements may include, for example, switches, mixers, amplifiers, filters, synthesizer circuitry, control circuitry, and the like.

[0105] In the receive path, the RFEM can receive a radiated signal from the air interface via the antenna structure 516 and then filter and amplify the signal (using a low-noise amplifier). The signal can be provided to the receiver of the transceiver, which down-converts the RF signal to a baseband signal that is provided to the baseband processor of the processor 502.

[0106] In the transmit path, the transmitter of the transceiver up-converts the baseband signal received from the baseband processor and provides the RF signal to the RFEM. The RFEM can amplify the signal through a power amplifier before the RF signal is radiated across the air interface via the antenna 516. In various embodiments, the RF interface circuit 504 can be configured to transmit / receive signals in a manner compatible with the NR access technology.

[0107] The antenna 516 can include antenna elements to convert an electrical signal into radio waves to travel through the air and convert the received radio waves into an electrical signal. These antenna elements can be arranged into one or more antenna panels. The antenna 516 can have antenna panels with omnidirectional, directional, or a combination thereof to enable beamforming and multiple-input / multiple-output communication. The antenna 516 can include a microstrip antenna, a printed antenna fabricated on the surface of one or more printed circuit boards, a patch antenna, a phased array antenna, etc. The antenna 516 can have one or more panels that are designed for a specific frequency band of the bands included in FR1 or FR2.

[0108] The user interface 508 includes various input / output (I / O) devices that are designed to enable a user to interact with the UE 500. The user interface 508 includes input device circuitry and output device circuitry. The input device circuitry includes any physical or virtual component for accepting input, particularly including one or more physical or virtual buttons (e.g., a reset button), a physical keyboard, a keypad, a mouse, a touchpad, a touch screen, a microphone, a scanner, or a headset, etc. The output device circuitry includes any physical or virtual component for displaying information or otherwise conveying information (such as sensor readings, actuator positions, or other similar information). The output device circuitry can include any number or combination of audio or visual displays, particularly including one or more simple visual outputs / indicators (e.g., binary state indicators such as light-emitting diodes "LEDs" and multi-character visual outputs), or more complex outputs such as a display device or a touch screen (e.g., a liquid crystal display "LCD", an LED display, a quantum dot display, a projector, etc.), where the output of characters, graphics, multimedia objects, etc. is generated or produced through the operation of the UE 500.

[0109] The sensor 510 may include a device, module, or subsystem that is designed to detect events or changes in its environment and send information about the detected events (sensor data) to some other device, module, subsystem, etc. Examples of such sensors include, in particular: inertial measurement units including accelerometers, gyroscopes, or magnetometers; microelectromechanical systems or nanoelectromechanical systems including three-axis accelerometers, three-axis gyroscopes, or magnetometers; liquid level sensors; temperature sensors (e.g., thermistors); pressure sensors; image capture devices (e.g., cameras or lensless apertures); light detection and ranging sensors; proximity sensors (e.g., infrared radiation detectors, etc.); depth sensors; ambient light sensors; ultrasonic transceivers; microphones or other similar audio capture devices; and so on.

[0110] The drive circuit 512 may include software elements and hardware elements that operate to control specific devices embedded in, attached to, or otherwise communicatively coupled to the UE 500. The drive circuit 512 may include individual drivers, thereby allowing other components to interact with or control various input / output (I / O) devices that may be present within or connected to the UE 500. For example, the drive circuit 512 may include: a display driver for controlling and allowing access to a display device, a touchscreen driver for controlling and allowing access to a touchscreen interface, a sensor driver for obtaining sensor readings from the sensor circuit 510 and controlling and allowing access to the sensor circuit 510, a driver for obtaining the actuator position of an electromechanical component or controlling and allowing access to an electromechanical component, a camera driver for controlling and allowing access to an embedded image capture device, and an audio driver for controlling and allowing access to one or more audio devices.

[0111] The PMIC 514 may manage the power supplied to various components of the UE 500. Specifically, with respect to the processor 502, the PMIC 514 may control power selection, voltage scaling, battery charging, or DC-DC conversion.

[0112] In some specific implementations, the PMIC 514 may control or otherwise be part of various power saving mechanisms of the UE 500. The battery 518 may power the UE 500, but in some examples, the UE 500 may be installed and deployed in a fixed location and may have a power source coupled to the power grid. The battery 518 may be a lithium-ion battery, a metal-air battery such as a zinc-air battery, an aluminum-air battery, a lithium-air battery, etc. In some specific implementations, such as in vehicle-based applications, the battery 518 may be a typical lead-acid automotive battery.

[0113] Figure 6An access node 600 (e.g., a base station or gNB) is illustrated according to some implementations. The access node 600 may be similar to the base station 104 and may be substantially interchangeable therewith. The access node 600 may include a processor 602, an RF interface circuit 604, a core network (CN) interface circuit 606, a memory / storage circuit 608, and an antenna structure 610.

[0114] The components of access node 600 may be coupled to various other components via one or more interconnects 612. Processor 602, RF interface circuitry 604, memory / storage circuitry 608 (including communication protocol stack 614), antenna structures 610, and interconnects 612 may be similar to those described with reference to Figure 5 Like-named elements are shown and described.For example, processor 602 may include processor circuits such as, for example, baseband processor circuit (BB) 616A, central processor unit circuit (CPU) 616B, and graphics processor unit circuit (GPU) 616C.

[0115] The CN interface circuit 606 may provide a connection to a core network (e.g., a 5GC using a 5th generation core network (5GC) compatible network interface protocol such as a carrier Ethernet protocol or some other suitable protocol). Network connectivity may be provided to / from the access node 600 via optical fiber or wireless backhaul. The CN interface circuit 606 may include one or more dedicated processors or FPGAs for communicating using one or more of the aforementioned protocols. In some implementations, the CN interface circuit 606 may include multiple controllers for providing connectivity to other networks using the same or different protocols.

[0116] As used herein, the terms "access node", "access point", etc. may describe equipment that provides radio baseband functionality for data and / or voice connections between a network and one or more users. These access nodes may be referred to as BS, gNB, RAN node, eNB, NodeB, RSU, TRxP or TRP, etc., and may include ground stations (e.g., ground access points) or satellite stations that provide coverage within a geographic area (e.g., a cell). As used herein, the terms "NG RAN node" and the like may refer to an access node 600 (e.g., a gNB) operating in an NR or 5G system, and the terms "E-UTRAN node" and the like may refer to an access node 600 (e.g., an eNB) operating in an LTE or 4G system. According to various specific implementations, the access node 600 may be implemented as one or more of a dedicated physical device such as a macrocell base station and / or a low power (LP) base station for providing a femtocell, picocell or other similar cell with a smaller coverage area, smaller user capacity or higher bandwidth than a macrocell.

[0117] In some specific implementations, all or part of the access node 600 may be implemented as one or more software entities running on a server computer, as part of a virtual network that may be referred to as a CRAN and / or a virtual baseband unit pool (vBBUP). In a V2X scenario, the access node 600 may be or act as a "road side unit". The term "road side unit" or "RSU" may refer to any traffic infrastructure entity for V2X communication. The RSU may be implemented in or by a suitable RAN node or a stationary (or relatively stationary) UE, where the RSU implemented in or by the UE may be referred to as a "UE-type RSU", the RSU implemented in or by the eNB may be referred to as an "eNB-type RSU", the RSU implemented in or by the gNB may be referred to as a "gNB-type RSU", and so on.

[0118] For ease of description, various components may be described as performing one or more tasks. Such descriptions should be interpreted as including the phrase "configured to". A component described as configured to perform one or more tasks is expressly intended not to invoke an interpretation under 35 U.S.C. § 112(f) for that component.

[0119] Other embodiments

[0120] Specific embodiments of the present disclosure have been described. Other embodiments are within the scope of the following claims. For example, the steps recited in the claims or any process described herein are combined, performed in a different order, or both, and still achieve the desired result.

Claims

1. A method for updating a Packet Data Convergence Protocol (PDCP) reordering window, the method comprises: receiving, by a PDCP receiver, a discard indication indicating that one or more PDCP PDUs are discarded PDUs; determining, by the PDCP receiver, whether a reordering timer is running; and based on determining that the reordering timer is running, updating, by the PDCP receiver, an upper end of the reordering window to a first value, the first value being determined by adjusting a value of a first state variable based on a number of subsequently discarded PDUs.

2. The method according to claim 1, wherein the value of the first state variable corresponds to a sequence count value after a sequence count value associated with a PDCP data PDU that triggered the reordering timer.

3. The method according to claim 1, the method further comprises: based on determining that the reordering timer is not running, updating, by the PDCP receiver, a lower end of the reordering window to a second value, the second value being determined by adjusting a value of a second state variable based on the number of subsequently discarded PDUs.

4. The method according to claim 3, wherein the value of the second state variable corresponds to a sequence count value of a first PDCP SDU that (i) has not been delivered to an upper layer and (ii) is still awaited by a receiving device.

5. The method according to claim 1, the method further comprises: updating, by the PDCP receiver, a value of a third state variable based on a number of consecutively discarded PDUs.

6. The method according to claim 1, the method further comprises: determining, by the PDCP receiver, (i) that the value of the second state variable corresponds to a sequence count value of a first PDCP SDU that (a) has not been delivered to an upper layer and (b) is still awaited by a receiving device, and (ii) determining the value of the third state variable based on the number of consecutively discarded PDUs; and based on determining that the value of the second state variable is equal to the value of the third state variable: delivering, by the PDCP receiver, to an upper layer protocol all stored PDCP SDUs having consecutive associated values starting from a sequence number equal to the value of the second state variable; and updating, by the PDCP receiver, the value of the second state variable to a sequence number of a first PDCP SDU not yet delivered to the upper layer.

7. The method according to claim 6, wherein an updated value of the second state variable is a sequence number greater than the value of the second state variable before the update.

8. The method according to claim 6, wherein the stored PDCP SDUs having consecutive associated values are delivered after header decompression.

9. One or more processors, the one or more processors comprising circuitry for executing one or more instructions which, when executed, cause a PDCP receiver device to perform the operations of method claims 1 to 8.

10. The method according to claim 9, wherein the PDCP receiver device is a UE or a base station.

11. One or more computer-readable storage media storing instructions that, when executed by a PDCP receiver device, cause the PDCP receiver device to perform the operations of method claims 1 to 8.

Images