CHANGE

TECHNICAL FIELD

Particular embodiments are directed to wireless communications and, more particularly, to preventing packet loss when changing the length of a Packet Data Convergence Protocol (PDCP) Sequence Number (SN).

INTRODUCTION

Third Generation Partnership Project (3 GPP) specifies the Packet Data Convergence Protocol (PDCP) for use in the air interface between network nodes and wireless devices. Upon a handover of a wireless device between network nodes, the network (e.g., target node) may change the PDCP sequence number (SN) length. When the PDCP SN length does not change or when the PDCP SN length is increased, the PDCP transmitter can ensure lossless reconfigurations. Reducing the PDCP SN length, however, may result in data losses.

Normally a network attempts to use the same size PDCP SN for all connected base stations. However, for networks with a mixture of base stations belonging to different operators or with base stations using different radio technologies, a different SN length may be assigned for the same type of traffic. When a user equipment (UE) moves between these base stations and needs to perform handover from a source base station using SN length M to a target base station using SN length N (that is different from M), the UE and the network need to ensure that the PDCP SN size can be updated to the correct length.

A handover normally triggers a PDCP re-establishment procedure to be performed both by the PDCP transmitter and the PDCP receiver. The purpose of this procedure is to ensure that the PDCP layer can continue to handle traffic and avoid packet losses.

When the PDCP SN length is extended (N > M) the conversion is not normally a problem. The sequence numbers can be mapped from the PDCP window used in the source base station to the PDCP window used in the target base station, because the target window is longer than the source window.

When the PDCP SN length is shortened, however, the conversion is more complicated. The window used in the source base station is larger than the window used in the target base station. In conventional long term evolution (LTE), at handover it is not possible to change the PDCP SN size for a radio link control (RLC) acknowledged mode (AM) bearer. If a PDCP SN size change is required, the network triggers a full radio resource control (RRC) reconfiguration. Thus, the UE is reconfigured from scratch in the target base station and the PDCP instances are deleted and created again.

FIGURE 1 is a block diagram illustrating PDCP SN of different lengths. As explained in more detail below, the PDCP SN is part of a larger 32-bit value referred to as COUNT. FIGURE 1 illustrates how the structure of the COUNT value changes when the PDCP SN is shortened from length M to length N.

The PDCP protocol specification (3GPP TS 36.323) specifies different procedures, both for the receiver and the transmitter, where the usage of PDCP SN is required. The PDCP SN is used in the PDCP protocol to keep different PDCP service data units (SDUs) in order, to identify packets, and as input into the ciphering algorithm. The PDCP SN is included in the header of a PDCP protocol data unit (PDU). Thus, the length of the PDCP SN should be as short as possible.

To identify the different PDCP PDUs, the PDCP protocol uses the PDCP SN in certain procedures. For example, a PDCP transmitter may need to keep track of PDCP PDUs that have been submitted to lower layers and for which confirmation of successful delivery has not yet been received. As another example, the PDCP receiver may use the PDCP SN to ensure in-order delivery of any PDCP PDUs that are received from a lower layer. If packets are received out-of-order, PDCP may temporarily store these PDCP PDUs until the missing PDUs are received and the resulting set of PDUs can be disassembled into PDCP SDUs that can be forwarded in-order to higher layers.

A PDCP implementation normally keeps track of the status of PDCP PDUs. The receiver uses a receiver window, and the sender uses a transmitter window. In these windows the status of each PDCP SN can be indicated.

The size of the transmitter and receiver windows determines how many PDCP PDUs the PDCP protocol can keep in flight at the same time. For a PDCP transmitter, "in flight" refers to the number of PDCP PDUs that can be transmitted without having received an acknowledgement (ACK) for successful delivery. For a PDCP receiver, "in flight" refers to the number of PDCP PDUs that it can keep buffered to wait for any missing PDCP PDUs so that delivery towards higher layers is in-order.

Different services using different radio bearers may use different sizes of the PDCP

SN. For example, Voice over LTE (VoLTE) traffic may use a relatively short PDCP SN because of the generally small packet size used for VoLTE. A high data rate service may use a relatively long PDCP SN because high data rates there may keep many PDCP PDUs in flight at the same time. In many cases the size of the PDCP window (receiver and transmit) is half of the value range provided by the PDCP SN size. The reason is that the receiver needs to distinguish between PDCP PDUs that are older or newer than the most recent PDCP PDU received. Thus, using the complete window could result in the following situation. If the most recent PDU received has SN equal to X, and the receiver then receives SN equal to X + 1, the receiver would not know if the PDU is a future PDCP PDU, or if the PDU is an older PDCP PDU with an SN that would have the SN = X - windowSize.

The PDCP SN is one part of a larger value that is used to keep track of all PDCP PDUs. The PDCP is combined with a Hyper Frame Number (HFN) to form a 32-bit value referred to as COUNT. The COUNT value is formed as follows: (1) the PDCP SN is the least significant part of the COUNT (i.e., if the length of the PDCP SN is X bits, then the X least significant bits of COUNT is the PDCP SN); and (2) the HFN is the remaining most significant part of the COUNT that is not part of the PDCP SN (i.e., if the length of the PDCP SN is X bits, then the length of the HFN is 32 - X bits, which are the most significant bits of the COUNT).

COUNT is used as input when ciphering a PDCP PDU. It is not possible to use only the PDCP SN as input in the ciphering algorithm because then the same PDCP SN would be used for more than one PDCP PDU because of the wrap-around to 0 of the PDCP SN that happens frequently. Using the same number as input to the ciphering algorithm for different packets is considered unsafe.

Only the PDCP SN is sent as part of the PDCP PDUs. Thus, the current value of the HFN is kept up to date by both the network and the UE. Both the network and the UE need to understand when the PDCP SN wraps around to zero and then the HFN is incremented by one.

The PDCP receiver may create status reports. The first missing PDCP SN (FMS) is one of the elements used to create the status report. The FMS has a length equal to the SN length.

SUMMARY

The embodiments described herein include methods for changing the size of a Packet

Data Convergence Protocol (PDCP) sequence number (SN). More specifically, the embodiments include methods to decrement the PDCP SN size. In general, when the PDCP SN length is reduced, the PDCP bearer is re-established as follows: (1) the receiver processes all PDCP protocol data units (PDUs) already received from the source node/cell and which are waiting in the receiver PDCP window, and it forwards these PDUs to higher layers; (2) the receiver sends, if requested, a status report back to the transmitter indicating the missing PDCP PDUs; (3) the PDCP state variables are reset to their initial values; and (4) the transmitter retransmits the payload of all PDCP PDUs for which it has not got a confirmation from lower layers of successful reception and for which it has not got confirmation of successful reception in a PDCP status report.

According to some embodiments, a method for use in a radio network element capable of operating as a PDCP transmitting entity comprises: performing a handover from a first cell to a second cell where a PDCP SN for the second cell is smaller than a PDCP SN for the first cell; resetting PDCP state variables to initial values; for all PDCP PDUs for which the radio network element has not received confirmation of receipt from a PDCP receiver (unconfirmed PDCP PDUs), generating new PDCP PDUs by applying new PDCP headers based on the reset PDCP state variables to the payload of the unconfirmed PDCP PDUs; and transmitting the new PDCP PDUs.

In particular embodiments, resetting PDCP state variables to their initial values comprises setting Next PDCP TX SN to 0 and TX HFN to 0. Generating new PDCP PDUs for all unconfirmed PDCP PDUs may comprise: performing ciphering of a PDCP payload using the reset Next_PDCP_TX_SN and TX HFN; assigning the reset Next_PDCP_TX_SN to PDCP payload; submitting the PDCP payload to a lower protocol layer for transmission; and incrementing Next_PDCP_TX_SN and TX HFN.

In particular embodiments, the PDCP transmitter comprises a network node or a wireless device.

According to some embodiments, a PDCP transmitter comprises processing circuitry operable to perform a handover from a first cell to a second cell where a PDCP SN for the second cell is smaller than a PDCP SN for the first cell; reset PDCP state variables to initial values; for all PDCP PDUs for which the PDCP transmitter has not received confirmation of receipt from a PDCP receiver (unconfirmed PDCP PDUs), generate new PDCP PDUs by applying new PDCP headers based on the reset PDCP state variables to the payload of the unconfirmed PDCP PDUs; and transmit the new PDCP PDUs.

In particular embodiments, the processing circuitry is operable to reset PDCP state variables to their initial values by setting Next PDCP TX SN to 0 and TX HFN to 0. The processing circuitry operable to generate new PDCP PDUs for all unconfirmed PDCP PDUs may be operable to: perform ciphering of a PDCP payload using the reset Next PDCP TX SN and TX HFN; assign the reset Next PDCP TX SN to PDCP payload; submit the PDCP payload to a lower protocol layer (e.g., RLC) for transmission; and increment Next_PDCP_TX_SN and TX HFN.

In particular embodiments, the PDCP transmitter comprises a network node or a wireless device.

According to some embodiments, a method in a radio network element capable of operating as a PDCP receiving entity comprises: performing a handover from a first cell to a second cell where a PDCP SN for the second cell is smaller than a PDCP SN for the first cell; submitting to a higher protocol layer (e.g., RRC) all PDCP PDUs that were received before the handover but not yet submitted to the higher protocol layer; and resetting PDCP state variables to initial values. Resetting PDCP state variables to initial values may comprise setting Next PDCP RX SN to 0, RX HFN to 0, and Last submitted PDCP RX SN to Maximum PDCP SN.

In particular embodiments, the method further comprises identifying PDCP PDUs which were not received from the first cell using an updated first missing PDCP SN (FMS) format with a length greater than the PDCP SN length of the second cell. The updated FMS format may have a length equivalent to the PDCP SN length of the first cell, or equivalent to the number of bits as a COUNT value of one of the identified PDCP PDUs not received from the first cell.

In particular embodiments, the method further comprises: receiving a handover reconfiguration message from one of the first or second cell; upon receiving the handover reconfiguration message, identifying PDCP PDUs which were not received from the first cell using the updated FMS; and sending a status report to the second cell. The status report includes the updated FMS.

In particular embodiments, the radio network element comprises a wireless device or a network node.

According to some embodiments, a PDCP receiver comprises processing circuitry operable to: perform a handover from a first cell to a second cell where a PDCP SN for the second cell is smaller than a PDCP SN for the first cell; submit to a higher protocol layer all PDCP PDUs that were received before the handover but not yet submitted to the higher protocol layer; and reset PDCP state variables to initial values. The processing circuitry may be operable to reset PDCP state variables to initial values by setting Next PDCP RX SN to 0, RX HFN to 0, and Last submitted PDCP RX SN to Maximum PDCP SN.

In particular embodiments, the processing circuitry is further operable to identify PDCP PDUs which were not received from the first cell using an updated FMS format with a length greater than the PDCP SN length of the second cell. The updated FMS format may have a length equivalent to the PDCP SN length of the first cell, or a length equivalent to the number of bits as a COUNT value of one of the identified PDCP PDUs not received from the first cell.

According to some embodiments, a wireless device comprises a PDCP transmitting module and a PDCP receiving module. The PDCP transmitting module is operable to: perform a handover from a first cell to a second cell where a PDCP SN for the second cell is smaller than a PDCP SN for the first cell; reset PDCP state variables to initial values; for all PDCP PDUs for which the wireless device has not received confirmation of receipt from a PDCP receiver (110, 120) (unconfirmed PDCP PDUs), generate new PDCP PDUs by applying new PDCP headers based on the reset PDCP state variables to the payload of the unconfirmed PDCP PDUs; and transmit the new PDCP PDUs. The PDCP receiving module is operable to: perform a handover from a first cell to a second cell where a PDCP SN for the second cell is smaller than a PDCP SN for the first cell; submit to a higher protocol layer all PDCP PDUs that were received before the handover but not yet submitted to the higher protocol layer; and reset PDCP state variables to initial values.

According to some embodiments, a network node comprises a PDCP transmitting module and a PDCP receiving module. The PDCP transmitting module is operable to: perform a handover from a first cell to a second cell where a PDCP SN for the second cell is smaller than a PDCP SN for the first cell; reset PDCP state variables to initial values; for all PDCP protocol data units (PDUs) for which the network node has not received confirmation of receipt from a PDCP receiver (unconfirmed PDCP PDUs), generate new PDCP PDUs by applying new PDCP headers based on the reset PDCP state variables to the payload of the unconfirmed PDCP PDUs; and transmit the new PDCP PDUs. The PDCP receiving module is operable to: perform a handover from a first cell to a second cell where a PDCP SN for the second cell is smaller than a PDCP SN for the first cell; submit to a higher protocol layer all PDCP PDUs that were received before the handover but not yet submitted to the higher protocol layer; and reset PDCP state variables to initial values.

Also disclosed is a computer program product. The computer program product comprises instructions stored on non-transient computer-readable media which, when executed by a processor, perform the steps of: performing a handover from a first cell to a second cell where a PDCP SN for the second cell is smaller than a PDCP SN for the first cell; resetting PDCP state variables to initial values; for all PDCP PDUs for which the processor has not received confirmation of receipt from a PDCP receiver (unconfirmed PDCP PDUs), generating new PDCP PDUs by applying new PDCP headers based on the reset PDCP state variables to the payload of the unconfirmed PDCP PDUs; and transmitting the new PDCP PDUs.

Another computer program product comprises instructions stored on non-transient computer-readable media which, when executed by a processor, perform the steps of: performing a handover from a first cell to a second cell where a PDCP SN for the second cell is smaller than a PDCP SN for the first cell; submitting to a higher protocol layer all PDCP PDUs that were received before the handover but not yet submitted to the higher protocol layer; and resetting PDCP state variables to initial values.

Certain embodiments of the present disclosure may provide one or more technical advantages. An advantage of particular embodiments is that there will not be any losses of PDCP PDUs in the radio interface, because the PDCP transmitter will ensure that all PDCP PDUs not yet confirmed to be received are retransmitted to the PDCP receiver. Because the PDCP receiver will receive any retransmitted PDCP PDUs after it has already forwarded all its received PDCP PDUs to higher layers, the PDCP PDUs that are received as new transmissions, but which are really re-transmissions, may be received out-of-order by higher layers.

Packet losses may be avoided when the length of the PDCP SN is decreased at handover. Particular embodiments also ensure that the PDCP re-establishment procedure performed at handover can be done in a reliable way which avoids the risk of the Hyper Frame Number (HFN) values becoming out-of-sync between the transmitter and the receiver, which would otherwise lead to radio link failure (RLF).

BRIEF DESCRIPTION OF THE DRAWINGS

For a more complete understanding of the embodiments and their features and advantages, reference is now made to the following description, taken in conjunction with the accompanying drawings, in which:

FIGURE 1 is a block diagram illustrating PDCP SN of different length;

FIGURE 2 is a block diagram illustrating an example mapping of a PDCP reception window to a smaller PDCP reception window;

FIGURE 3 illustrates an example wireless network, according to a particular embodiment;

FIGURE 4 is a flow diagram of an example method in a PDCP transmitter, according to some embodiments; FIGURE 5 is a flow diagram of an example method in a PDCP receiver, according to some embodiments;

FIGURE 6 is another flow diagram of an example method in a PDCP transmitter, according to some embodiments;

FIGURE 7 is another flow diagram of an example method in a PDCP receiver, according to some embodiments;

FIGURE 8A is a block diagram illustrating an example embodiment of a wireless device;

FIGURE 8B is a block diagram illustrating example components of a wireless device; FIGURE 9A is a block diagram illustrating an example embodiment of a network node; and

FIGURE 9B is a block diagram illustrating example components of a network node.

DETAILED DESCRIPTION

As described in the Introduction, upon a handover of a wireless device between network nodes, the network (e.g., target node) may change the Packet Date Convergence Protocol (PDCP) sequence number (SN) length. When decreasing the SN size in legacy long term evolution (LTE) at handover, the handover must be done using full radio resource control (RRC) reconfiguration (i.e., no PDCP re-establishment performed). Instead, all PDCP instances are released and added as new PDCP instances for each radio bearer. Any PDCP protocol data units (PDUs) and PDCP service data units (SDUs) stored in the PDCP instances are discarded, which in some cases results in loss of packets when performing the handover procedure.

A problem with the first missing PDCP SN (FMS) is that, after the reconfiguration, the UE will use the number of bits indicated for the PDCP SN length. Thus, the FMS can only indicate a subset of the missing PDCP PDUs because the new receiving window in the target cell is shorter than at the source cell.

An alternative solution proposes decreasing the PDCP SN size at handover without the need for doing a full RRC reconfiguration by mapping parts of the PDCP windows with the long SN to the PDCP windows with the short SN. An example is illustrated in FIGURE 2.

FIGURE 2 is a block diagram illustrating an example mapping of a PDCP reception window to a smaller PDCP reception window. In the illustrated example, a PDCP SN in the middle of the larger reception window is chosen to become the low end of the smaller reception window. The next expected PDCP SN for a new PDCP PDU is chosen to become the high end of the smaller reception window.

A problem with the illustrated example is that the PDCP PDUs that are stored in the receiver window between the Last Submitted PDCP RX SN and the "SN to become the Low End in the smaller window" do not fit in the smaller window and must either be discarded or forwarded to higher layers even though there are missing PDCP PDUs that have not yet been received. Thus, PDCP PDUs are lost because those PDCP PDUs that have not been received and which do not fit in the new small window will not be retransmitted by the transmitter.

Another disadvantage is that the state variables that the transmitter and receiver are using for keeping track of the current HFN (e.g., RX HFN and TX HFN in conventional LTE) may have a small risk of becoming out-of-sync between each other after the handover. This can happen if the PDCP receiver has failed to receive a certain number of PDCP PDUs in sequence which has caused the RX HFN not to be updated, while the transmitter has updated the TX HFN for the same SN used in the smaller window. The only way to recover from this failure is to trigger a radio link failure (RLF) and setup a new RRC connection.

Particular embodiments obviate the problems described above. When a user equipment (UE) performs handover from a source base station using SN length M to a target base station using SN length N (that is different from M), the UE and the network may ensure that the PDCP SN size can be updated to the correct length.

The embodiments described herein include methods of decrementing the PDCP SN size. In particular embodiments, when the PDCP SN length is reduced, the PDCP bearer may be re-established as follows: (1) the receiver processes all PDCP PDUs already received from the source node/cell and which are waiting in the receiver PDCP window, and it forwards these PDUs to higher layers; (2) the receiver sends, if requested, a status report back to the transmitter indicating the missing PDCP PDUs; (3) the PDCP state variables are reset to their initial values; and (4) the transmitter retransmits the payload of all PDCP PDUs for which it has not got a confirmation from lower layers of successful reception and for which it has not got confirmation of successful reception in a PDCP status report.

An advantage of particular embodiments is that packet losses may be avoided when the length of the PDCP SN is decreased at handover. Particular embodiments also ensure that the PDCP re-establishment procedure performed at handover can be done without the risk of the Hyper Frame Number (HFN) values becoming out-of-sync between the transmitter and the receiver, which would otherwise lead to radio link failure (RLF). Any two or more embodiments described in this document may be combined in any way with each other. The described embodiments are not limited to LTE, but can be adapted in other RATs, such as UTRA, LTE-Advanced, 5G, NX, NB-IoT, WiFi, BlueTooth, etc.

In some embodiments a non-limiting term "UE" is used. The UE herein can be any type of wireless device capable of communicating with network node or another UE over radio signals. The UE may also be radio communication device, target device, device to device (D2D) UE, machine type UE or UE capable of machine to machine communication (M2M), a sensor equipped with UE, iPAD, Tablet, mobile terminals, smart phone, laptop embedded equipped (LEE), laptop mounted equipment (LME), USB dongles, Customer Premises Equipment (CPE) etc. The UE may also be referred to as a wireless device.

In some embodiments, generic terminology "network node" is used. It can be any kind of network node which may comprise of a radio network node such as base station, radio base station, base transceiver station, base station controller, network controller, evolved Node B (eNB), Node B, Multi-cell/multicast Coordination Entity (MCE), relay node, access point, radio access point, Remote Radio Unit (RRU) Remote Radio Head (RRH), a core network node (e.g., MME, SON node, a coordinating node, positioning node (e.g. SMLC, E-SMLC, etc.), MDT node, etc.), or even an external node (e.g., 3rd party node, a node external to the current network), etc.

Particular embodiments are described with reference to FIGURES 3-9B of the drawings, like numerals being used for like and corresponding parts of the various drawings. LTE and NR are used throughout this disclosure as an example cellular system, but the ideas presented herein may apply to other wireless communication systems as well.

FIGURE 3 is a block diagram illustrating an example wireless network, according to a particular embodiment. Wireless network 100 includes one or more wireless devices 110 (such as mobile phones, smart phones, laptop computers, tablet computers, MTC devices, or any other devices that can provide wireless communication) and a plurality of network nodes 120 (such as base stations, eNodeBs, gNBs, etc.). Network node 120 serves coverage area 115 (also referred to as cell 115).

In general, wireless devices 110 that are within coverage of radio network node 120 (e.g., within cell 115 served by network node 120) communicate with radio network node 120 by transmitting and receiving wireless signals 130. For example, wireless devices 110 and network node 120 may communicate wireless signals 130 containing voice traffic, data traffic, and/or control signals. A network node 120 communicating voice traffic, data traffic, and/or control signals to wireless device 110 may be referred to as a serving network node 120 for the wireless device 110. Wireless signals 130 may include both downlink transmissions (from radio network node 120 to wireless devices 110) and uplink transmissions (from wireless devices 110 to radio network node 120).

Wireless signals 130 may include data encapsulated in one or more protocols. For example, wireless signals 130 may include data encapsulated using PDCP 135. Each radio network element (e.g., wireless device 110, network node 120, etc.) may include a PDCP transmitter and a PDCP receiver. When network node 120a hands off wireless device 110 to network node 120b, particular PDCP parameters, such as the PDCP SN, may change. The PDCP transmitter and PDCP receiver may perform a re-establishment procedure to account for a decreased SN length. More detailed examples are described with respect to FIGURES 4 and 7.

In some embodiments, wireless device 110 may be referred to by the non-limiting term "UE." A UE may include any type of wireless device capable of communicating with a network node or another UE over radio signals. The UE may comprise radio communication device, target device, device to device (D2D) UE, machine type UE or UE capable of machine to machine communication (M2M), a sensor equipped with UE, iPAD, Tablet, mobile terminals, smart phone, laptop embedded equipped (LEE), laptop mounted equipment (LME), USB dongles, Customer Premises Equipment (CPE), etc.

In some embodiments, network node 120 may include any type of network node such as a base station, radio base station, base transceiver station, base station controller, network controller, evolved Node B (eNB), Node B, gNB, multi-RAT base station, Multi- cell/multicast Coordination Entity (MCE), relay node, access point, radio access point, Remote Radio Unit (RRU) Remote Radio Head (RRH), a core network node (e.g., MME, SON node, a coordinating node, etc.), or even an external node (e.g., 3rd party node, a node external to the current network), etc.

Each network node 120 may have a single transmitter or multiple transmitters for transmitting wireless signals 130 to wireless devices 110. In some embodiments, network node 120 may comprise a multi-input multi-output (MIMO) system. Similarly, each wireless device 110 may have a single receiver or multiple receivers for receiving signals 130 from network nodes 120.

In wireless network 100, each network node 120 may use any suitable radio access technology, such as long term evolution (LTE), LTE-Advanced, NR, UMTS, HSPA, GSM, cdma2000, WiMax, WiFi, and/or other suitable radio access technology. Wireless network 100 may include any suitable combination of one or more radio access technologies. For purposes of example, various embodiments may be described within the context of certain radio access technologies. However, the scope of the disclosure is not limited to the examples and other embodiments could use different radio access technologies.

As described above, embodiments of a wireless network may include one or more wireless devices and one or more different types of network nodes capable of communicating with the wireless devices. The network may also include any additional elements suitable to support communication between wireless devices or between a wireless device and another communication device (such as a landline telephone). A wireless device may include any suitable combination of hardware and/or software. For example, in particular embodiments, a wireless device, such as wireless device 110, may include the components described below with respect to FIGURE 8A. Similarly, a network node may include any suitable combination of hardware and/or software. For example, in particular embodiments, a network node, such as network node 120, may include the components described below with respect to FIGURE 9A.

When a handover of a wireless device from one network node to another network node is triggered, the source cell or network node transmits to the target cell or network node all PDCP SDUs for which acknowledgements were not yet received. When the PDCP SN length used in the target cell is less than the PDCP SN length used in the source cell, the PDCP transmitter and receiver perform additional steps. Examples methods are illustrated in FIGURES 4-7.

FIGURE 4 is a flow diagram of an example method in a PDCP transmitter, according to some embodiments. In particular embodiments, one or more steps may be performed by components of wireless network 100 described with reference to FIGURE 3. Although particular examples may be described with respect to a network node or a wireless device, the embodiments described herein may be performed by a network node, a wireless device, or any other suitable radio network node.

The method begins at step 1, where at PDCP re-establishment the PDCP transmitter resets all PDCP state variables to their initial values and applies the new ciphering key. For example, after handover of wireless device 110 from network node 120a to network node 120b, network node 120b may set Next_PDCP_TX_SN to 0, TX HFN to 0, and set the new smaller size of the PDCP transmission window.

At step 2, the PDCP transmitter applies the ciphering algorithm and key provided by upper layers during the re-establishment procedure. For example, network node 120b may apply ciphering using a newly received algorithm and/or key. At step 3, the PDCP transmitter re-transmits the payload of all PDCP PDUs (PDCP SDUs) for which it has not received confirmation that they have not been received by the receiver. The retransmission is done as if these PDCP PDUs are new PDUs (i.e., the transmitter adds new/updated PDCP headers, and as a payload, it puts the PDCP SDUs which the transmitter decided to re-transmit).

For example, network node 120b may at step 3.1 perform ciphering of the PDCP SDU using the new Next_PDCP_TX_SN and TX HFN, at step 3.2 assign the new SN to the PDCP PDU and submit the resulting PDCP data PDU to lower layer, and at step 3.3 increment the Next_PDCP_TX_SN and TX HFN to the next subsequent SN.

At step 5, the PDCP transmitter continues transmission of any new PDCP PDUs in the normal manner. For example, network node 120b transmits an new PDCP PDUs to wireless device 110 using the new PDCP parameters.

Modifications, additions, or omissions may be made to the method illustrated in FIGURE 4. Additionally, one or more steps in the method may be performed in parallel or in any suitable order.

FIGURE 5 is a flow diagram of an example method in a PDCP receiver, according to some embodiments. In particular embodiments, one or more steps may be performed by components of wireless network 100 described with reference to FIGURE 3. Although particular examples may be described with respect to a network node or a wireless device, the embodiments described herein may be performed by a network node, a wireless device, or any other suitable radio network node.

The method begins at step 1, where at PDCP re-establishment the PDCP receiver submits to higher layers all PDCP SDUs that it has already received, but that are waiting in the reception window because there are missing PDCP PDUs that have not yet been received and that come before the PDUs stored in the reception window. For example, network node 120b may, if not done already, perform deciphering of the associated PDCP SDU using the currently assigned COUNT value and submit the resulting PDCP data SDU to higher layers in current sequence number order.

At step 2, the PDCP receiver resets all PDCP state variables to their initial values. For example, network node 120b may set Next_PDCP_RX_SN to 0, RX HFN to 0, Last submitted PDCP RX SN to Maximum PDCP SN, and set the new smaller size of the PDCP transmission window.

At step 3, the PDCP receiver applies the new ciphering key. For example, network node 120b may apply a new ciphering algorithm and/or key. At step 4, the PDCP receiver continues to receive new PDCP PDUs as in normal reception.

Modifications, additions, or omissions may be made to the method illustrated in FIGURE 5. Additionally, one or more steps in the method may be performed in parallel or in any suitable order.

In some embodiments, the PDCP receiver may modify the FMS. As described above, the FMS length is the same as the PDCP SN length. After the reconfiguration, the receiver is not able to indicate the same range of PDCP PDUs SN. Thus, to allow the receiver to indicate any SN value from those that the source node/cell could have sent, the FMS format is updated in some embodiments.

The updated FMS format may be used (if indicated by the network) to provide a status report of those PDCP PDUs which were not received from the source node/cell. For example, the network may send a reconfiguration request to the wireless device, triggering the wireless device to send a status report using the updated FMS format. In some embodiments, the reconfiguration request may comprise an explicit reconfiguration message. The explicit reconfiguration message may be a handover reconfiguration message that includes, for example, the PDCP SN length or other parameters that are reconfigured for the target node/cell. In some embodiments, the reconfiguration message may comprise an existing message normally exchanged during the handover process that triggers the reconfiguration. The updated FMS format is such that it facilitates uniquely identifying the PDCP PDUs that are missing.

For example, in some embodiments the FMS contains the COUNT value of the first missing PDU SN which was not received from the source cell/node. This means that the FMS field contains 32 bits. Another embodiment uses the same number of bits as the PDCP SN length prior to the reconfiguration.

After sending the report, in some embodiments the UE may continue using the FMS as specified with the same number of bits as the new (reduced) PDCP SN length. In other embodiments it may use the complete COUNT.

The transmitter may use the status report which would include the new FMS format to identify missing PDUs.

Although the example embodiments are described with respect to converting a SN length to a shorter SN length upon handover, the embodiments described herein also apply when the SN length does not change, or the SN length is increased. FIGURE 6 is another flow diagram of an example method in a PDCP transmitter, according to some embodiments. In particular embodiments, one or more steps of method 600 may be performed by components (e.g., network node 120, wireless device 110) of wireless network 100 described with reference to FIGURE 3. Although particular examples may be described with respect to a network node or a wireless device, the embodiments described herein may be performed by a network node, a wireless device, or any other suitable radio network node.

The method begins at step 612, where a PDCP transmitter performs a handover from a first cell to a second cell where a PDCP SN for the second cell is smaller than a PDCP SN for the first cell. As one example, network node 120a may handover wireless device 110 from cell 115a served by network node 120a to cell 115b served by network node 120b. Cell 115b may have a smaller PDCP SN than cell 115a.

Before the handover, network node 120a has a PDCP connection with wireless device 110. Network node 120a includes a PDCP transmitter for transmitting PDCP PDUs to wireless device 110 and a PDCP receiver for receiving PDCP PDUs from wireless device 110. Wireless device 110 includes a PDCP transmitter for transmitting PDCP PDUs to network node 120a and a PDCP receiver for receiving PDCP PDUs from network node 120a.

After the handover, network node 120b has a PDCP connection with wireless device 110. Network node 120b includes a PDCP transmitter for transmitting PDCP PDUs to wireless device 110 and a PDCP receiver for receiving PDCP PDUs from wireless device 110. Wireless device 110 includes a PDCP transmitter for transmitting PDCP PDUs to network node 120b and a PDCP receiver for receiving PDCP PDUs from network node 120b.

An example of step 612 with respect to network node 120b includes network node 120b performing a handover of wireless device 110 from network node 120a. As part of the handover, network node 120b may receive instructions and data from network node 120a. Part of the data may include unacknowledged PDCP PDUs and PDCP state variables (e.g., Next_PDCP_TX_SN, TX_HFN, etc.) from network node 120a.

An example of step 612 with respect to wireless device 110 includes wireless device 110 determining or being instructed to switch to cell 115b.

At step 614, the PDCP transmitter resets PDCP state variables to initial values. For example, the PDCP transmitter of network node 120b may initialize its PDCP state variables (e.g., set Next PDCP TX SN to 0, TX HFN to 0, etc.). As another example, the PDCP transmitter of wireless device 110 may initialize its PDCP state variables (e.g., set Next PDCP TX SN to 0, TX HFN to 0, etc.). At step 616, the PDCP transmitter, for all PDCP PDUs for which it has not received confirmation of receipt from a PDCP receiver (unconfirmed PDCP PDUs), generates new PDCP PDUs by applying new PDCP headers based on the reset PDCP state variables to the payload of the unconfirmed PDCP PDUs.

For example, network node 120b may have one or more PDCP PDUs for which is has not received receipt confirmation (acknowledgement) from wireless device 110. Instead of waiting for confirmation, or re-transmitting the existing unconfirmed PDUs, network node 120b generates new PDCP PDUs using the existing PDU payloads but attaching headers based on the newly reset PDCP variables (e.g., starting with the reset variables and incrementing the values for each of the one or more unconfirmed PDUs).

Similarly, wireless device 110 may have one more PDCP PDUs for which is has not received receipt confirmation (acknowledgement) from network node 120a. Instead of waiting for confirmation, or re-transmitting the existing unconfirmed PDUs to network node 120b, wireless device generates new PDCP PDUs using the existing PDU payloads but attaching headers based on the newly reset PDCP variables.

At step 618, the PDCP transmitter transmits the new PDCP PDUs. For example, the PDCP transmitter of network node 120b may transmit the new PDCP PDUs generated at step 616 to wireless device 110. The PDCP transmitter of wireless device 110 may transmit the new PDCP PDUs generated at step 616 to network node 120b.

Modifications, additions, or omissions may be made to method 600 illustrated in

FIGURE 6. Additionally, one or more steps in method 300 may be performed in parallel or in any suitable order.

FIGURE 7 is another flow diagram of an example method in a PDCP receiver, according to some embodiments. In particular embodiments, one or more steps of method 700 may be performed by components (e.g., network node 120, wireless device 110) of wireless network 100 described with reference to FIGURE 3. Although particular examples may be described with respect to a network node or a wireless device, the embodiments described herein may be performed by a network node, a wireless device, or any other suitable radio network node.

The method begins at step 712, where a PDCP receiver performs a handover from a first cell to a second cell where a PDCP SN for the second cell is smaller than a PDCP SN for the first cell. As one example, network node 120a may handover wireless device 110 from cell 115a served by network node 120a to cell 115b served by network node 120b. Cell 115b may have a smaller PDCP SN than cell 115a. Before the handover, network node 120a has a PDCP connection with wireless device 110. Network node 120a includes a PDCP transmitter for transmitting PDCP PDUs to wireless device 110 and a PDCP receiver for receiving PDCP PDUs from wireless device 110. Wireless device 110 includes a PDCP transmitter for transmitting PDCP PDUs to network node 120a and a PDCP receiver for receiving PDCP PDUs from network node 120a.

After the handover, network node 120b has a PDCP connection with wireless device 110. Network node 120b includes a PDCP transmitter for transmitting PDCP PDUs to wireless device 110 and a PDCP receiver for receiving PDCP PDUs from wireless device 110. Wireless device 110 includes a PDCP transmitter for transmitting PDCP PDUs to network node 120b and a PDCP receiver for receiving PDCP PDUs from network node 120b.

An example of step 712 with respect to network node 120b includes network node 120b performing a handover of wireless device 110 from network node 120a. As part of the handover, network node 120b may receive instructions and data from network node 120a. Part of the data may include PDCP PDUs and PDCP state variables (e.g., Next PDCP RX SN, RX HFN, Last submitted PDCP RX SN, etc.) from network node 120a.

An example of step 712 with respect to wireless device 110 includes wireless device 110 determining or being instructed to switch to cell 115b.

At step 714, the PDCP transmitter submits to a higher protocol layer all PDCP PDUs that were received before the handover but not yet submitted to the higher protocol layer. For example, network node 120b may have one or more PDCP PDUs which it has not yet submitted to a higher protocol layer (e.g., RRC). Network node 120b may submit these PDCP PDUs to the higher protocol layer without further waiting (e.g., even if the PDUs are out of order because of a missing SN).

Similarly, wireless device 110 may have one or more PDCP PDUs which it has not yet submitted to a higher protocol layer (e.g., RRC). Wireless device 110 may submit these PDCP PDUs to the higher protocol layer at step 714.

At step 716, the PDCP receiver resets its PDCP state variables to initial values. For example the PDCP receiver of network node 120 and/or wireless device 110 may reset Next PDCP RX SN to 0, RX HFN to 0, and Last submitted PDCP RX SN to Maximum PDCP SN.

Modifications, additions, or omissions may be made to method 700 illustrated in FIGURE 7. Additionally, one or more steps in method 700 may be performed in parallel or in any suitable order. FIGURE 8A is a block diagram illustrating an example embodiment of a wireless device. The wireless device is an example of the wireless devices 110 illustrated in FIGURE 3. The wireless device is capable of performing a handover from a first cell to a second cell where a PDCP SN for the second cell is smaller than a PDCP SN for the first cell. The wireless device is capable of: resetting PDCP state variables to initial values; for all PDCP PDUs for which the wireless device has not received confirmation of receipt from a PDCP receiver (unconfirmed PDCP PDUs), generating new PDCP PDUs by applying new PDCP headers based on the reset PDCP state variables to the payload of the unconfirmed PDCP PDUs; and transmitting the new PDCP PDUs. The wireless device is capable of: submitting to a higher protocol layer all PDCP PDUs that were received before the handover but not yet submitted to the higher protocol layer; and resetting PDCP state variables to initial values.

Particular examples include a mobile phone, a smart phone, a PDA (Personal Digital Assistant), a portable computer (e.g., laptop, tablet), a sensor, a modem, a machine type (MTC) device / machine to machine (M2M) device, laptop embedded equipment (LEE), laptop mounted equipment (LME), USB dongles, a device-to-device capable device, a B- IoT device, or any other device that can provide wireless communication. The wireless device includes transceiver 810, processing circuitry 820, memory 830, and power source 840. In some embodiments, transceiver 810 facilitates transmitting wireless signals to and receiving wireless signals from wireless network node 120 (e.g., via an antenna), processing circuitry 820 executes instructions to provide some or all of the functionality described herein as provided by the wireless device, and memory 830 stores the instructions executed by processing circuitry 820. Power source 840 supplies electrical power to one or more of the components of wireless device 110, such as transceiver 810, processing circuitry 820, and/or memory 830.

Processing circuitry 820 includes any suitable combination of hardware and software implemented in one or more integrated circuits or modules to execute instructions and manipulate data to perform some or all of the described functions of the wireless device. In some embodiments, processing circuitry 820 may include, for example, one or more computers, one more programmable logic devices, one or more central processing units (CPUs), one or more microprocessors, one or more applications, and/or other logic, and/or any suitable combination of the preceding. Processing circuitry 820 may include analog and/or digital circuitry configured to perform some or all of the described functions of wireless device 110. For example, processing circuitry 820 may include resistors, capacitors, inductors, transistors, diodes, and/or any other suitable circuit components.

Memory 830 is generally operable to store computer executable code and data. Examples of memory 830 include computer memory (e.g., Random Access Memory (RAM) or Read Only Memory (ROM)), mass storage media (e.g., a hard disk), removable storage media (e.g., a Compact Disk (CD) or a Digital Video Disk (DVD)), and/or or any other volatile or non-volatile, non-transitory computer-readable and/or computer-executable memory devices that store information.

Power source 840 is generally operable to supply electrical power to the components of wireless device 110. Power source 840 may include any suitable type of battery, such as lithium-ion, lithium-air, lithium polymer, nickel cadmium, nickel metal hydride, or any other suitable type of battery for supplying power to a wireless device.

In particular embodiments, processing circuitry 820 in communication with transceiver 810 communicates PDCP encapsulated data with network node 120. For example, processing circuitry 820 in communication with transceiver 810 may perform any of the steps described with respect to FIGURES 4-7. Other embodiments of the wireless device may include additional components (beyond those shown in FIGURE 8A) responsible for providing certain aspects of the wireless device's functionality, including any of the functionality described above and/or any additional functionality (including any functionality necessary to support the solution described above).

FIGURE 8B is a block diagram illustrating example components of a wireless device 110. The components may include PDCP transmitting module 850 and PDCP receiving module 852.

PDCP transmitting module 850 may perform the PDCP transmitting functions of wireless device 110. For example, PDCP transmitting module 850 may perform the steps described with respect to FIGURES 4 and/or 6. In certain embodiments, PDCP transmitting module 850 may include or be included in processing circuitry 820.

PDCP receiving module 852 may perform the PDCP receiving functions of wireless device 110. For example, PDCP receiving module 852 may perform the steps described with respect to FIGURES 5 and/or 7. In certain embodiments, PDCP receiving module 852 may include or be included in processing circuitry 820.

FIGURE 9A is a block diagram illustrating an example embodiment of a network node. The network node is capable of performing a handover from a first cell to a second cell where a PDCP SN for the second cell is smaller than a PDCP SN for the first cell. The network node is capable of: resetting PDCP state variables to initial values; for all PDCP PDUs for which the network node has not received confirmation of receipt from a PDCP receiver (unconfirmed PDCP PDUs), generating new PDCP PDUs by applying new PDCP headers based on the reset PDCP state variables to the payload of the unconfirmed PDCP PDUs; and transmitting the new PDCP PDUs. The network node is capable of: submitting to a higher protocol layer all PDCP PDUs that were received before the handover but not yet submitted to the higher protocol layer; and resetting PDCP state variables to initial values.

Network node 120 can be an eNodeB, a nodeB, a base station, a wireless access point (e.g., a Wi-Fi access point), a low power node, a base transceiver station (BTS), a transmission point or node, a remote RF unit (RRU), a remote radio head (RRH), or other radio access node. Network node 120 includes processing circuitry 920 (e.g., CPUs, ASICs, FPGAs, etc.), at least one memory 930, at least one network interface 940, and one or more radio units that each include on or more transceivers 910 coupled to one or more antennas. Transceiver 910 facilitates transmitting wireless signals to and receiving wireless signals from a wireless device, such as wireless devices 110 (e.g., via an antenna); processing circuitry 920 executes instructions to provide some or all of the functionality described above as being provided by a network node 120; memory 930 stores the instructions executed by processing circuitry 920; and network interface 940 communicates signals to backend network components, such as a gateway, switch, router, Internet, Public Switched Telephone Network (PSTN), controller, and/or other network nodes 120. Processing circuitry 920 and memory 930 can be of the same types as described with respect to processing circuitry 820 and memory 830 of FIGURE 8 A above.

In some embodiments, network interface 940 is communicatively coupled to processing circuitry 920 and refers to any suitable device operable to receive input for network node 120, send output from network node 120, perform suitable processing of the input or output or both, communicate to other devices, or any combination of the preceding. Network interface 940 includes appropriate hardware (e.g., port, modem, network interface card, etc.) and software, including protocol conversion and data processing capabilities, to communicate through a network. In particular embodiments, processing circuitry 920 in communication with transceiver 910 communicates PDCP encapsulated data with wireless device 110.

In some embodiments, a portion of the network node 120 may be implemented as virtual component(s) (e.g., via a virtual machine(s) executing on a physical processing node(s) in a network(s)). For example, some or all of the functions executed by processing circuitry 920 of network node 120 are implemented as virtual components executed by one or more virtual machines implemented in a virtual environment(s) hosted by processing circuitry 920.

Other embodiments of network node 120 include additional components (beyond those shown in FIGURE 9 A) responsible for providing certain aspects of the network node's functionality, including any of the functionality described above and/or any additional functionality (including any functionality necessary to support the solution described above). The various different types of network nodes may include components having the same physical hardware but configured (e.g., via programming) to support different radio access technologies, or may represent partly or entirely different physical components.

FIGURE 9B is a block diagram illustrating example components of a network node 120. The components may include PDCP transmitting module 950 and PDCP receiving module 952.

PDCP transmitting module 950 may perform the PDCP transmitting functions of network node 120. For example, PDCP transmitting module 950 may perform the steps described with respect to FIGURES 4 and/or 6. In certain embodiments, PDCP transmitting module 950 may include or be included in processing circuitry 920.

PDCP receiving module 952 may perform the PDCP receiving functions of network node 120. For example, PDCP receiving module 952 may perform the steps described with respect to FIGURES 5 and/or 7. In certain embodiments, PDCP receiving module 952 may include or be included in processing circuitry 920.

Some embodiments of the disclosure may provide one or more technical advantages. Some embodiments may benefit from some, none, or all of these advantages. Other technical advantages may be readily ascertained by one of ordinary skill in the art.

Although this disclosure has been described in terms of certain embodiments, alterations and permutations of the embodiments will be apparent to those skilled in the art. Although some embodiments have been described with reference to certain radio access technologies, any suitable radio access technology (RAT) or combination of radio access technologies may be used, such as long term evolution (LTE), LTE-Advanced, R, UMTS, HSPA, GSM, cdma2000, WiMax, WiFi, etc. Accordingly, the above description of the embodiments does not constrain this disclosure. Other changes, substitutions, and alterations are possible without departing from the spirit and scope of this disclosure. Abbreviations:

3 GPP 3rd Generation Partnership Project

5GC Fifth Generation System

5GC Fifth Generation Core

AS Access Stratum

CA Carrier Aggregation

CC Component Carrier

CN Core Network

eMTC enhanced Machine Type Communications

eMTC-U enhanced Machine Type Communications for Unlicensed Band eNB Evolved Node B

eNodeB Evolved Node B

EPC Evolved Packet Core

EPS Evolved Packet System

E-SMLC Evolved Serving Mobile Location Center

FeMTC Further enhanced MTC

FDD Frequency Division Duplex

FMS First Missing PDCP SN

gNB Fifth Generation Node B

GNSS Global Navigation Satellite System

HFN Hyper Frame Number

ID Identifier

IoT Internet of Things

LBT Listen Before Talk

LPP LTE Positioning Protocol

LTE Long-Term Evolution

MF MuLTEfire

MME Mobility Management Entity

MSC Mobile Switching Center

MTC Machine Type Communication

NAS Non Access Stratum

NB-IoT NarrowB and-IoT

NB-IoT-U Narrow-band Internet of Things for Unlicensed Band

NGS Next Generation System R New Radio

NW Network

OFDM Orthogonal Frequency Division Multiplexing

OTDOA Observed Time Difference of Arrival

PBCH Physical Broadcast Channel

PCID Physical Cell Identity

PCC Primary Component Carrier

PCell Primary Cell

PDCP Packet Data Convergence Protocol

PDU Protocol Data Unit

PGW Packet Data Network Gateway

PRB Physical Resource Block

PSD Power Spectral Density

RAT Radio Access Technology

RAN Radio Access Network

RF Radio Frequency

RLF Radio Link Failure

RRC Radio Resource Control

RSRP Reference Signal Received Power

RSRQ Reference Signal Received Quality

RSTD Reference Signal Time Difference

SCC Secondary Component Carrier

SCell Secondary Cell

SDU Service Data Unit

SFN System Frame Number

SGW Serving Gateway

SLA Service Level Agreement

TDD Time Division Duplex

TDOA Time Difference Of Arrival

TOA Time Of Arrival

UE User Equipment

UMTS Universal Mobile Telecommunications System

UTDOA Uplink Time Difference of Arrival

UTRA UMTS Terrestrial Radio Access

