GB2572631A - Packet data convergence protocol (PDCP) duplication deactivation - Google Patents

Abstract

A user equipment (UE) performing Packet Data Convergence Protocol (PDCP) duplication, where the Protocol Data Units (PDUs) are transmitted to the PDCP receiver over first and second radio links, implicitly deactivates the process when specified conditions of the duplication process are met. The conditions may be associated with various quantities exceeding respective thresholds, such as the number of PDUs being buffered before transmission (not including duplicates), the transmission window size of the duplication process, the queuing time of the Service Data Units (SDUs), and the time difference between transmission of duplicate PDUs on the first and second radio links. The specified conditions may apply only to the duplicate link or to the control bearer of either the first or second radio links. The UE may revert to split bearer operation following the deactivation. The system avoids wasting radio resources in situations where PDCP duplication is not required but would otherwise remain active, and finds application with URLLC services in 5G NR networks.

Description

PACKET DATA CONVERGENCE PROTOCOL (PDCP) DUPLICATION DEACTIVATION

Technical Field

The invention relates to cellular communication devices and methods and is applicable, in particular, to enhancements related to packet data convergence protocol (PDCP) packet duplication functionality.

Background

Wireless communication systems, such as the third-generation (3G) of mobile telephone standards and technology are well known. Such 3G standards and technology have been developed by the Third Generation Partnership Project (3GPP). The 3^rd generation of wireless communications has generally been developed to support macro-cell mobile phone communications. Communication systems and networks have developed towards a broadband and mobile system.

The 3rd Generation Partnership Project has developed the so-called Long Term Evolution (LTE) system, namely, an Evolved Universal Mobile Telecommunication System Territorial Radio Access Network, (E-UTRAN), for a mobile access network where one or more macro-cells are supported by a base station known as an eNodeB or eNB (evolved NodeB). More recently, LTE is evolving further towards the so-called 5G or NR (new radio) systems where one or more cells are supported by a base station known as a gNB.

The new radio (NR) protocol stack has multiple layers including Service Data Protocol (SDAP), Packet Data Convergence Protocol (PDCP), Radio Link Control (RLC), Medium Access Control (MAC), and physical layer (PHY). The PDCP layer provides transport for user payload, such as Internet Protocol (IP) packets in the user plane and/or control plane data in the control plane, depending on the radio bearer for which it is carrying data. Such payload might be embedded in a SDAP PDU.

In order to improve reliability and/or reduce latency of PDCP PDU transmission, packet duplication in PDCP (also denoted as PDCP duplication) is a feature which may be activated. When PDCP packet duplication is activated, a PDCP transmitter creates duplicates of PDCP protocol data units (PDUs) and transmits the original PDCP PDU and the duplicate PDCP PDU over two independent transmission paths: the original link or leg (RLC bearer), and an additional link or leg (RLC bearer), also called duplicate link. A PDCP receiver eliminates the duplicates using a sequence number (SN) identifier included in the PDCP PDlls. In this way enhanced reliability, as well a reduced latency is achieved for ultra-reliable low latency communication (LIRLLC) and other applications.

The present invention is seeking to solve at least some of the outstanding problems in this domain.

Summary

This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter.

In various examples a user equipment in a telecommunications network performs a method comprising: carrying out a packet data convergence protocol (PDCP) duplication process comprising, computing PDCP protocol data units (PDlls) from SDlls received at a PDCP layer of a protocol stack of the user equipment, computing duplicates of the PDCP PDlls, transmitting the PDCP protocol data units (PDUs) on a first radio link control bearer from the user equipment to a PDCP receiver at a node of the telecommunications network, and transmitting the duplicates on a duplicate link, being a second radio link control bearer from the user equipment to the PDCP receiver. The user equipment observes the PDCP duplication process; and when specified conditions of the PDCP duplication process are observed, performing an implicit deactivation of packet duplication.

In some examples there is provided a non-transitory computer readable medium having computer readable instructions stored thereon for execution by a processor to perform the methods described herein.

The non-transitory computer readable medium may comprise at least one from a group consisting of: a hard disk, a CD-ROM, an optical storage device, a magnetic storage device, a Read Only Memory, a Programmable Read Only Memory, an Erasable Programmable Read Only Memory, EPROM, an Electrically Erasable Programmable Read Only Memory and a Flash memory.

Brief description of the drawings j

Further details, aspects and embodiments of the invention will be described, by way of example only, with reference to the drawings. Elements in the figures are illustrated for simplicity and clarity and have not necessarily been drawn to scale. Like reference numerals have been included in the respective drawings to ease understanding.

Figure 1 is a schematic diagram of a wireless cellular communications system;

Figure 2 is a flow diagram of a method of operation at a user equipment of a wireless cellular communications system, such as that of figure 1;

Figure 3 is a schematic diagram of a method of operation at a user equipment and at a base station gNB;

Figure 4 is a schematic diagram of user plane protocol stacks at a user equipment (UE) and at an evolved NodeB;

Figure 5 is a schematic diagram of uplink layer 2 structure;

Figure 6 is a schematic diagram of a cellular wireless communications network architecture configured for dual connectivity (DC);

Figure 7 is a schematic diagram of a radio protocol architecture of a user equipment;

Figure 8 is a schematic diagram of network side protocol termination options;

Figure 9a is a schematic diagram of a radio bearer in the case that the radio bearer is not configured for duplication;

Figure 9b is a schematic diagram of a radio bearer in the case that the radio bearer is configured for duplication;

Figure 10 is a schematic diagram of a PDCP Sequence Number space comprising a discard window and a reordering window;

Figure 11 shows the format of a COUNT value;

Figure 12 is a schematic diagram of a radio bearer and two RLC channels.

Detailed description of the preferred embodiments

Those skilled in the art will recognise and appreciate that the specifics of the examples described are merely illustrative of some embodiments and that the teachings set forth herein are applicable in a variety of alternative settings.

As mentioned above, when PDCP duplication is activated, a PDCP transmitter creates duplicates of PDCP protocol data units (PDlls) and transmits them on a duplicate link or leg (RLC bearer). A PDCP receiver eliminates the duplicates using a sequence number (SN) identifier included in the PDCP PDUs. In this way enhanced reliability, as well a reduced latency is achieved for ultra-reliable low latency communication (URLLC) and other applications. However, PDCP duplication leads to problems in some situations, including waste of radio resources and/or bad performance and/or protocol problems.

Waste of radio resources occurs where PDCP duplication remains activated in situations when it is not required. This can happen when a control node of the communications network has instructed the user equipment to stop using PDCP duplication but the instruction has failed to arrive at the user equipment, or when the communications network has failed to correctly instruct the user equipment to stop using PDCP duplication, for instance because of conflicting instructions from 2 nodes (in case of dual connectivity (DC)), or because the communications network has failed to notice the issue.

Protocol problems occur where PDCP duplication remains activated in situations when there is a “slow leg”. A “slow leg” is a radio link control channel over which transmission of PDCP PDUs from the user equipment to a PDCP receiver is so slow that the receiver incorrectly deciphers the PDCP PDUs and is unaware of the incorrect deciphering problem. Because the receiver is unaware of the incorrectly deciphered PDCP PDUs it proceeds as normal and this leads to unexpected results, corrupted data and potential malfunction at the PDCP receiver.

Bad performance problem occurs if to avoid above protocol problems, an implementation avoids further transmission of PDCP PDUs on the “fast leg” (i.e. stall the data transmission) because of the “slow leg”, i.e. the data transmission becomes limited by the “slow leg”.

The present technology addresses these problems by providing a user equipment which is designed to carry out implicit duplication deactivation when it observes specified conditions. Because the user equipment acts using its own observations, rather than relying on instructions received from another entity in the telecommunications network, duplication deactivation occurs when it should. That is, there is no risk of duplication remaining active when it should not, due to e.g. loss of duplication deactivation instructions that are dropped when sent to the user equipment, thereby avoiding excessive buffering in a slow leg and associated protocol and/or performance issues.

As already described, excessive buffering in “slow leg” is mainly an issue for unacknowledged (UM) bearer for which there is no automatic repeat request (ARQ) feedback. Alternative approaches for UM bearer could use hybrid automatic repeat request (HARQ) feedback to trigger the discard of a duplicate PDCP PDU once HARQ feedback indicated that the initial PDCP PDU transmission was successful. However such approach suffers from the problem that HARQ feedback is not sent in some circumstances, and even if sent, may be dropped during sending. Use of HARQ feedback also adds complexity for the user equipment.

Using MAC CE sent to the UE to deactivate duplication is also problematic, since the MAC CE is sometimes lost on the air interface. In the scenario under consideration, one leg (the slow leg) has issues, and the the PDCP PDUs are not going through in that leg. By deactivating duplication with a MAC CE, the network would not see anything since anyway nothing was transmitted on that leg. Hence the network cannot ensure that the MAC CE sent to deactivate duplication was successfully received and taken into account by the user equipment (UE). Race conditions and conflicts are also possible where MAC CEs from two nodes are used to activate/deactivate duplication in the case of dual connectivity, with no coordination between nodes on network side. Indeed MAC CEs can be sent by both nodes independently. The following scenario could happen. The primary path may decide on its own whether it needs or not duplication on the secondary path based on radio conditions. The node with PDCP may decide to switch off PDCP duplication based on delta between both legs. But the primary path may not be from the node with PDCP. In such case there could be conflicts (race condition) between MAC CEs from both nodes, it could be possible duplication remains activated while the node with PDCP thinks it is deactivated.

Alternative approaches using PDCP SDU discard timers, or PDCP PDU duplicate timers are unable to ensure avoiding buffering more than half of the PDCP sequence number space of PDUs, as the buffering also depends on the incoming PDCP PDU rate. Additional complexity is introduced where the PDCP PDU timer has to be introduced as the UE has to manage this.

Alternatively, by discarding the old duplicate PDCP PDlls when the transmission window becomes full, the process of generating PDCP PDlls from SDlls is not stalled. However, this adds complexity as it requires to implement a complex discarding mechanism. Moreover, it seems there is little benefit in specifying such a UE behaviour where half of PDCP SN space worth of PDCP PDlls will be kept buffered in a stuck/slow leg (continuously updated such as only the last half of PDCP SN duplicate PDCP PDlls are stored).

In various embodiments of the present technology, the user equipment carries out a packet data convergence protocol (PDCP) duplication process comprising, computing PDCP protocol data units (PDUs) from SDUs received at a PDCP layer of a protocol stack of the user equipment, computing duplicates of the PDCP PDUs, transmitting the PDCP protocol data units (PDUs) on a first radio link control bearer from the user equipment to a PDCP receiver at a node of the telecommunications network, and transmitting the duplicates on a duplicate link, being a second radio link control bearer from the user equipment to the PDCP receiver, via the same node (in single connectivity) or a different node (in dual connectivity). The user equipment observes the PDCP duplication process; and when specified conditions of the PDCP duplication process are observed, deactivates the PDCP duplication operation for that RB. In an example, when said UE deactivates the PDCP duplication operation, the UE acts as if it is requested by the NW to deactivate the PDCP packet duplication for that bearer, i.e. the UE performs all the actions related to deactivation of the PDCP packet duplication.

By careful specification of the conditions under which duplication deactivation is to be triggered, for uplink communications, the user equipment is able to effectively manage duplication deactivation. Various conditions are used and examples include one or more of: observing a threshold number of PDCP PDUs being buffered before transmission on a radio link control bearer, observing a threshold number of the SDUs being buffered, a transmission window size being higher than a threshold, a queuing time being longer than a threshold, a delta time exceeding a threshold where the delta time is a difference between the time when a PDCP PDU is transmitted on one of the radio link control bearers and a time when a duplicate of the PDCP PDU is transmitted on the other radio link control bearer. These conditions are straightforward for the user equipment to monitor and compute efficiently.

In one example, the condition is detection that PDCP transmission window is full for one RB for which packet duplication is activated.

When the UE deactivates the PDCP duplication operation, acting as if it is requested by the NW to deactivate the PDCP packet duplication for that RB, the following operations are performed. The duplicated PDCP PDlls, or corresponding RLC SDUs/PDUs (not yet submitted to MAC layer) are discarded. In case of CA duplication, the SCell (equivalently component carriers) restrictions are removed for the 2 logical channels associated to the RB. In case of DC duplication, the RB fallbacks to split bearer operation.

The PDCP duplication activation or deactivation may be triggered by several events. It may be triggered by a MAC CE. It may be triggered by a RRC reconfiguration. In the disclosed method, the PDCP duplication deactivation may be further triggered implicitly by the UE.

It is beneficial that the same processing is performed independently from the event triggering the activation or the deactivation of PDCP duplication. This allows an easier implementation and simplify specification as well as testing aspects.

In order to handle these different triggers, it is beneficial that a common framework is used. RRC is informed whether the duplication for a RB is activated or deactivated through RRC configuration. In an example, the RRC is further informed whether the duplication for a RB is activated/deactivated through a MAC CE. In a further example, RRC is informed whether the duplication for a RB is implicitly deactivated. RRC maybe referred to as “upper layers”.

In such framework, there is a common understanding whether duplication for a RB is activated or deactivated, and accordingly a common operation of protocol stack layers, independently of the event which triggered the activation or deactivation of PDCP duplication.

In such framework, there is a common understanding of actions to be performed when duplication for a RB is activated or deactivated, i.e. actions to be performed upon activation or deactivation of PDCP duplication for a RB in protocol stack layers are independent from the event which triggered the activation or deactivation of PDCP duplication.

For instance, the RRC layer may centralize events such as indication from lower layers, RRC reconfiguration, which can impact the PDCP duplication activation state; decides whether PDCP duplication state is changed, i.e. if it is becoming activated or becoming deactivated, and instruct the other protocol stack layers to perform associated actions. The protocol stack layers may refer directly to whether PDCP duplication state is activated or deactivated for a RB without ambiguity.

Figure 1 shows an example wireless cellular communications system 100. The wireless cellular system 100 is a 3GPP LTE system, also known as Evolved Universal Terrestrial Radio Access (E-UTRA) system or LTE Advanced system. The LTE wire-less cellular system 100 includes one or more user equipments (UEs) (one UE 110 is shown), a radio access network (RAN) 120, a core network (CN) 130, (e.g., evolved packet core (EPC), or 5G core network, 5GC), and external networks 140 (e.g., internet protocol (IP) networks). The RAN 120 further includes one or more base stations (one base station 115 is shown). The base station 115 may be a gNB or an evolved Node B (eNB).

The UE 110 is any mobile electronic device that is suitable to perform one or more PDCP PDU handling processes described in this document. Generally, the UE 110 may be used by an end-user to communicate, for example, within the wireless cellular communications system 100. The UE 110 may be referred to as mobile electronic device, mobile device, user device, mobile station, subscriber station, or wireless terminal. UE 110 may be a cellular phone, personal data assistant (PDA), smartphone, laptop, tablet personal computer (PC), or other wireless communication device. Further, UEs 110 may include wearable computer, augmented reality computing device, portable computers, Session Initiation Protocol (SIP) phones, one or more processors within devices, or any other suitable processing devices capable of communicating information using a radio technology. UE 110 may communicate directly with a base station 115 included in a RAN 120 to receive service when UE 110 is operated within the cell associated with the corresponding base station 115. UE 110 may also receive radio signals from more than one base station 115 included in RAN 120.

In some implementations, UEs 110 may transmit in one or more cellular bands. One or more UEs 110 may be communicably coupled to the RAN 120. In these cases, messages transmitted or received by UEs 110 may be based on one or more multiple radio access technologies. In some implementations, the UEs 110 may be configured to use, for example, orthogonal frequency division multiple access (OFDMA) technology or single carrier—frequency division multiple access (SCFDMA) technology, to communicate with a base station 115. UEs 110 may transmit voice, video, multimedia, text, web content or any other user/client-specific content. UEs 110 generate requests, responses or otherwise communicate in different means with core network 130 or external networks 140 through RAN 120.

The UE 110 has a user plane protocol stack that has multiple layers for characterizing or standardizing the functions of wireless communications between the UE 110 and an eNB 115. The layer may include a Packet Data Convergence Protocol (PDCP) layer, Radio Link Control (RLC) layer, Medium Access Control (MAC) layer, and Physical (PHY) layer. In PDCP downlink data transfer procedures for DRBs mapped on RLC acknowledge mode (AM), the UE 110 may perform a reordering or duplication detection to discard some of the received PDCP PDUs from the eNB 115. The UE 110 performs the reordering based on determining whether the received PDCP PDU is outside of a reordering window. For example, a received PDCP PDU is outside of a reordering window when the SN of the received PDCP PDU exceeds an SN of a last PDCP SDU delivered to an upper layer by a particular value (e.g., a reordering window size). The UE 110 performs duplication detection based on determining whether the received PDCP PDU is a duplicate PDCP PDU. For example, a received PDCP PDU is a duplicate PDU when the SN of the received PDCP PDU is the same as a previously stored PDCP SN. When header compression is not configured by upper layers, the UE 110 may discard the received PDCP PDU without performing deciphering and header decompression if the UE 110 determines that the received PDCP PDU is outside of a reordering window or that the received PDCP PDU is a duplicated PDCP PDU.

A RAN 120 in a 3GPP LTE system is an Evolved Universal Terrestrial Radio Access Network (E-UTRAN) or a Next Generation Radio Access Network NG-RAN. The RAN 120 can be located between the UEs 110 and the CN 130. The RAN 120 includes one or more base stations 115. The base stations 115 are radio base stations 115 that control one or more radio-related functions. The base station 115 directly communicate with one or more UEs 110, other base stations 115 or the CN 130. The base station 115 may be the end point of the radio protocols towards the UEs 110 and relay signals between the UEs 110 and the CN 130. As mentioned above the base station 115 is preferably a gNB.

Figure 2 is a flow diagram of a method of operation at a user equipment of a wireless cellular communications system, such as that of figure 1. The user equipment is carrying out PDCP duplication at operation 200 and it monitors to see if criteria are met at check 202. The monitoring comprises checking whether a PDCP transmission window becomes full. This is done by checking whether the PDCP PDUs buffered for transmission, including PDCP PDUs buffered in PDCP, as well as in lower layers (RLC) within RLC SDUs or RLC PDUs, cover a range that is greater than or equal to half of the PDCP sequence number space. Equivalently, this is done by checking whether the number of PDCP PDUs buffered for transmission, including PDCP PDUs buffered in PDCP, as well as in lower layers (RLC) within RLC SDUs or RLC PDUs, wherein PDCP duplicates are not counted, is greater than or equal to half of the PDCP sequence number space. Equivalently, this is done by checking whether a PDCP PDU with COUNT value equal to TX_NEXT-window_size is still buffered for transmission, in PDCP or in lower layers (RLC) within RLC SDU or RLC PDU. In an example, the “PDCP PDUs buffered for transmission” also includes PDCP SDUs already associated to a SN, even though the PDCP PDU was not yet generated. If so, the user equipment proceeds to carry out implicit duplication deactivation 204. If not, the user equipment continues to carry out PDCP duplication 200.

If implicit duplication deactivation is carried out 204 the user equipment discards 206 duplicate PDCP PDUs. In the case of carrier aggregation (CA) duplication the user equipment removes serving cell (equivalently component carriers) restrictions (referred to as removing S cell restrictions) 208. In the case of dual connectivity (DC) duplication (explained below) the user equipment falls back to a split bearer 210.

The user equipment optionally sends a notification 220 of duplication deactivation to the network, such as to the PDCP receiver or another node in the telecommunications network.

In cases where dual connectivity duplication is used, and the slow leg was a secondary cell group (SCG) leg the notification 220 is sent as part of an SCG failure procedure. In some cases a specific failure cause is added.

If the user equipment receives 222 a duplication activation request from a medium access control (MAC), control element (CE) it restores 224 PDCP duplication and the process of figure 2 repeats.

Various other criteria are used at check 202 in other examples. These criteria include one or more of: observing the PDCP transmission window is full, observing a threshold number of PDCP PDUs being buffered (in PDCP or lower layers, wherein PDCP PDU duplicates are excluded, i.e. a same PDCP PDU is not counted twice if it was duplicated) before transmission on a radio link control bearer, observing a threshold number of the SDlls being buffered, a transmission window size being higher than a threshold (lower than half the PDCP sequence number space), a queuing time being longer than a threshold (from PDCP SDU entering PDCP till transmission of the corresponding PDU on either leg being higher than a configured threshold), a delta time exceeding a threshold where the delta time is a difference between the time when a PDCP PDU is transmitted on one of the radio link control bearers and a time when a duplicate of the PDCP PDU is transmitted on the other radio link control bearer.

In various examples, the transmission window is a range defined as [TX_NEXTwindow_size, TX_NEXT[. This is expressed in words as, the transmission window is a range from the value of the variable TX_NEXT minus the window_size, which is half of the PDCP sequence number space, to the value of the variable TX_NEXT. The value of the variable TX_NEXT represents the COUNT value which be associated to the next generated PDCP PDU.

Figure 3 represents a method at the user equipment and a method at a base station or other communications network node comprising a PDCP receiver.

The user equipment is carrying out PDCP duplication 300 and transmits PDCP transmissions to the base station. The base station receives 302 PDCP transmissions from the user equipment and one or more other user equipment.

When the user equipment detects that criteria are met 304 such as using the operation 202 of figure 2 it carries out implicit duplication deactivation 306. The base station continues to receive 308 PDCP transmissions from the user equipment.

The user equipment sends a notification 310 to the base station to inform the base station that the user equipment has done implicit duplication deactivation. Note that operation 310 is optional and in some cases is not done.

The base station detects 312 that duplication deactivation at the user equipment has taken place. This is done by observing that duplicates are no longer received from the user equipment and/or by receiving the notification at operation 310.

The base station sends a request 314 to the user equipment to activate duplication. In some cases a MAC CE is sent. The user equipment receives the request and restores PDCP duplication at operation 316.

As mentioned above PDCP is one of the layers of a radio protocol stack. A PDCP entity of a wireless communication device can communicate PDCP PDUs to a peer PDCP entity of another wireless communication device. The PDCP entity may be located in the PDCP layer. Each PDCP entity is associated with a radio bearer. The PDCP entity is associated with a control plane or a user plane depending on the radio bearer.

In a PDCP transmission process, a wireless communication device performs a sequence numbering operation on the data packets, where a sequence number (SN) is included in an SN field of a PDCP header for each PDCP data PDU. Each PDCP entity that carries user plane data is able to use header compression per radio bearer. The PDCP entity also performs ciphering after performing header compression.

In a PDCP receiving process, the PDCP entity is able to identify the SN from the SN field of the header. The PDCP entity uses the identified SN to perform a reordering and duplication detection. When receiving a PDCP PDU with a given SN, the PDCP receiver derives the HFN (and hence the COUNT) by considering whether it is a “new” or “late” PDCP PDU based on its position with respect to RX_DELIV, according to figure 10.

Figure 4 is FIG. 4 is a schematic 400 illustrating user plane protocol stacks for a UE 410a and an eNB 410b. In other words, the illustrated schematic 400 includes UE side protocol stack 410a and eNB side protocol stack 41 Ob. While the schematic 400 is illustrated as including a UE and an eNB, the schematic 400 can include any wireless communication devices. User plane protocol stack 410a and 410b can include multiple abstraction layers for characterizing or standardizing the functions of wireless communications between the UE and eNB. The illustrated layers of the UE side protocol stack 410a include, from top to bottom, PDCP 450a, RLC 440a, MAC 430a, and PHY 420a. The illustrated layers of the eNB side protocol stack 410b include, from top to bottom, PDCP 450b, RLC 440b, MAC 430b, and PHY 420b. The UE side protocol stack 410a and the eNB side protocol stack 410b may include other layers for providing various functions in wireless communications.

PDCPs 450a and 450b can receive respective PDCP data PDUs 460a and 460b directly from associated RLC layers 440a and 440b; and send respective PDCP data SDUs 470a and 470b to a respective upper layer. A UE entity can interact with a corresponding entity at the same layer in the eNB by means of a protocol by transmitting a PDU. For example, the PDCP 450a entity may interact with the corresponding PDCP 450b entity by transmitting PDCP data PDU.

Generally, a PDU is a protocol data unit that is specified in a protocol of a given layer. The PDU may include protocol-control information and/or user data of the given layer. For example, the PDCP data PDU 460a and 460b is a PDU of PDCP layer 450a and 450b, respectively. The PDCP SDU 470a and 470b can be the payload of the PDCP data PDU. As illustrated in FIG. 4, PDCP SDU 470a and PDCP data PDU 460a are the data units associated with the PDCP 450a of the UE, and the PDCP SDU 470b, respectively and PDCP data PDU 460b are the data units associated with the PDCP 406 of the eNB. The process of changing the PDCP SDU 470a and 470b to the PDCP data PDU 460a and 460b can include an encapsulation process performed by the PDCP. Correspondingly, the process of changing the PDCP data PDU 460a and 460b to the PDCP SDU 470a and 470b can include decoding the PDCP data PDU to extract the PDCP SDU 470a and 470b (e.g., deciphering, header decompression).

Generally, PDCP 450a and 450b delivers data packets to and receives data packets from a peer PDCP entity. Each PDCP entity can be associated with a DRB. Depending on characteristics of the traffic, the DRB may be mapped to an RLC 440a and 440b acknowledged mode (AM), or an RLC 440a and 440 unacknowledged mode (UM). For example, Transmission Control Protocol (TCP)Zlnternet Protocol (IP) traffic can be mapped to RLC AM since reliable radio trans-port is required for TCP/IP. In some cases, PDCP entities associated with the DRBs can be configured by upper layers to use header compression. In data packet transmission, header compression for user plane data may be performed by a PDCP entity using a header compression protocol. The header compression protocol can generate two types of output packets: 1) compressed packets, each associated with one PDCP SDU; and

2) standalone packets not associated with a PDCP SDU. The compressed packets associated with PDCP SDU may then be ciphered, added to the PDCP header, and transmitted to the peer PDCP entity as PDCP data PDU. In data packet reception, the peer PDCP entity may remove the PDCP header from the received PDCP data PDU, decipher the compressed packets, and perform a header decompression of the compressed packets.

In cellular systems, such as new radio (NR), data is transmitted over the air interface trough so-called radio bearers (RB). A radio bearer is the service provided by Layer 2 to transport user data packets (Data Radio Bearer, DRB) or signaling data packets (Signaling Radio Bearer, SRB) between the UE and the network (NW). It can be configured with specific characteristics depending of the traffic conveyed and the quality of service (QoS) desired for that traffic.

In NR and LTE systems, the layer 2 consists in several sublayers, including the PDCP sublayer. Several PDCP entities may be defined for a UE. Each PDCP entity is carrying the data of one radio bearer. A radio bearer conveys PDCP SDUs from a transmitting PDCP entity to a receiving PDCP entity. Each RB (except for SRBO) is associated with one PDCP entity.

Figure 5 of the accompanying drawings shows schematically an example of an Uplink Layer 2 Structure such as is known in the art from 3GPP TS 38.300v15.0.0. In Figure 5, the Layer 2 NR uplink protocol stack can be seen to comprise Medium Access Control (MAC), Radio Link Control (RLC), Packet Data Convergence Protocol (PDCP) and Service Data Adaption Protocol (SDAP). As shown in Figure 5, in the Uplink Layer 2, the physical layer offers transport channels to the MAC sublayer. The MAC sublayer offers logical channels to the RLC sublayer logical channels. The RLC sublayer offers RLC channels to the PDCP sublayer. The PDCP sublayer offers radio bearers to the SDAP sublayer and the SDAP sublayer offers QoS flows to above layers.

A PDCP entity uses services from the underlying RLC entity. The RLC provides transparent mode (TM), unacknowledged mode (UM) and acknowledged mode (AM) data transfer service. For a RB, only RLC UM or RLC AM modes are used. Depending on required QoS, a RB might be configured using RLC UM (UM bearer) or RLC AM (AM bearer). For a UM RB, packet losses on the air interface might happen. For an AM RB, packet losses on the air interface do not happen as RLC ARQ provides necessary retransmissions. SRBs (except for SRBO) are configured as AM RBs (as control plane signalling shall not be lost on the air interface), DRBs using real time services (such as voice) are configured as UM RBs (as this kind of service tolerates some packet loss, and is sensitive to latency induced by retransmissions), DRBs used for data transfer are configured as AM RBs (as retransmission is best performed at lower layers than application layers).

A PDCP entity is associated to at least one RLC entity. In this document the term link or leg is used to denote an underlying RLC link (including RLC entity/Logical Channel/MAC configuration) which is associated to the PDCP entity. This is also known as “RLC bearer”.

In single connectivity, when PDCP duplication is not configured, each PDCP entity is associated with one RLC entity.

In dual connectivity (DC), a multiple receive/transmit (Rx/Tx) UE may be configured to utilize radio resources provided by two distinct schedulers in two different nodes (the Master Node and the Secondary Node) connected via non-ideal backhaul. At least the MN is connected to the Core Network. Each node provides resources within group of serving cells, respectively Master Cell Group (MCG) and Secondary Cell Group (SCG). In DC, a radio bearer might be configured as a MCG, SCG, or split radio bearer. A MCG radio bearer uses RLC/MAC configured in MCG only, a SCG radio bearer uses RLC/MAC configured in SCG only, and a split radio bearer uses RLC/MAC configured in both MCG and SCG. The PDCP entity of a split radio bearer is associated to (at least) 2 RLC entities, one associated to the MN and one associated to the SN. Dual connectivity was originally introduced for E-UTRA access (LTE). A split bearer uses 2 links while a MCG or SCG bearer uses one link (when PDCP packet duplication is not configured).

Multi-RAT Dual Connectivity (MR-DC) is a generalization of the Intra-E-UTRA Dual Connectivity (DC) in which one node is providing E-IITRA access and the other one is providing NR access. In E-UTRA-NR Dual Connectivity (ΕΝ-DC), the CN is the EPC, and the UE is connected to one eNB acting as MN and one gNB (en-gNB) acting as SN.

Figure 6 is a schematic diagram of overall architecture in the case of dual connectivity and shows evolved packet system EPC 600 and E-UTRAN 602.

Figure 7 shows an example user equipment 700 radio protocol architecture for MCG, SCG and split bearers in dual connectivity.

Figure 8 shows an example network side protocol termination option for MCG, SCG and split bearers in dual connectivity.

When the packet duplication feature is activated, the PDCP transmitter creates duplicates of PDCP PDUs and transmits the original PDCP PDU and the duplicate PDCP PDU over two links: the original (initial) link, and the “duplicate link” (or leg) (i.e. two different RLC entity I logical channel, also referred to as “RLC bearer”, are used). The PDCP receiver eliminates the duplicates thanks to the sequence number (SN) included in the PDCP PDUs. The duplication feature enables enhanced reliability, as well as reduced latency (for ultra-reliable low latency communication URLLC). The main use cases are: URLLC (both for reliability and latency) and enhanced reliability, for SRBs, or generally non-URLLC DRBs, for instance at the time of hand off (HO).

PDCP Packet duplication is pre-configured by RRC at radio bearer level, by configuring a duplicate leg, in addition to the initial leg. Both are associated to the radio bearer PDCP entity. It is supported both in downlink (DL) and uplink (UL). For DRBs, It is supported both for acknowledge mode (AM) and unacknowledged mode (UM). It is supported both, in Dual Connectivity (DC) (reusing the split bearer configuration, with one leg on each cell group) and single connectivity when Carrier Aggregation (CA) is configured (each leg is mapped on different carrier(s), or equivalently serving cells).

Figure 9A shows a radio bearer which is not configured for duplication and figure 9B shows a radio bearer which is configured for duplication.

Generally, PDCP receives PDCP SDU from upper layers, build PDCP PDlls, submit PDCP PDlls to lower layers. The exact timing of PDCP PDU creation, and of submission to lower layers is not defined. At a given time, PDCP may store PDCP SDlls as well as PDCP PDlls. When UL PDCP duplication is activated, PDCP PDUs shall be duplicated to be submitted to both links. In the generally accepted modelling, the PDCP performs the duplication of PDCP PDUs at the time of submission to lower layers, and submits PDCP PDUs to both underlying entities at the same time. This means that at a given instant, there is always only one PDCP PDU within the PDCP entity (no PDCP PDU duplicate is stored in the PDCP entity). Compared to the case where PDCP duplication is not activated, there is no change in the calculation of PDCP data volume. In an alternative modelling, PDCP is allowed to perform submission of a PDCP PDU and its duplicate to the different RLC at different times. However, that would result in PDCP storing PDCP PDUs as well as duplicated PDCP PDUs, which adds some complexity to the modelling. In practice, with the generally accepted modelling, duplicated PDCP PDUs are stored as RLC SDUs in lower layers rather than PDCP PDUs in PDCP (while not transmitted), but this is not expected to impact the functionality.

Assuming a scenario with a “fast leg” and a “slow leg”, the PDCP layer will submit PDCP PDUs in accordance with the rate of the “fast leg” (PDCP might also submit some PDCP PDUs before UE has received UL grants, i.e. transmitting opportunities on the link, for pre-processing purpose). As a result RLC SDUs may start buffering into the slow leg. Such buffering may eventually lead to performance and/or protocol issues, as described in other sections of this application, referred to herein as “excessive buffering”.

In case of an AM bearer, the UE can discards packet that have been acknowledged by RLC in the other RLC leg. PDCP should indicate to the other associated RLC entity to discard the corresponding PDCP PDU.

Hence for an acknowledged mode (AM) bearer, as soon as one leg (e.g. the “fast leg”) receives confirmation that a PDCP PDU (RLC SDU) was successfully transmitted (thanks to a RLC STATUS acknowledgment), it will indicate it to PDCP, which will in turn indicate the other leg (e.g. the “slow leg”) to discard the corresponding PDCP SDU. Hence, if the corresponding RLC PDU was not yet submitted to MAC, it will be discarded (dropped), and any excessive buffering in the slow leg is mitigated.

In case of an unacknowledged mode (UM) bearer, there is no indication of successful transmission of a RLC SDU (PDCP PDU) by one leg. Hence, excessive buffering may occur.

In an example the PDCP receive operation uses a PUSH based reordering window (see figure 10). The reordering window lower edge “RX_DELIV” is pushed by arrival of PDCP PDU with COUNT = RX_DELIV, or by expiry of the reordering timer.

The reordering timer is started whenever it was not already running and a gap is created in the received. Only PDCP SN is included in a PDCP PDU (with configurable length, either 12 or 18 bits).

It is used to derive a COUNT value which is a variable of length 32 bits.

The COUNT value is composed of a hyper frame number (HFN) and the PDCP SN as shown in figure 11. The size of the HFN part in bits is equal to 32 minus the length of the PDCP SN. The COUNT value is used for ciphering and integrity (if configured).

When receiving a PDCP PDU with a given SN, the PDCP receiver derives the HFN (and hence the COUNT) by considering whether it is a “new” or “late” PDCP PDU based on its position with respect to RX_DELIV, according to the figure 10.

There is no transmit window explicitly defined in PDCP.

The following variable is used: TX_NEXT. This state variable indicates the COUNT value of the next PDCP SDU to be transmitted. The initial value is 0.

The transmission procedure is as follows (from 3GPP 38.323 v15.0.0):

For a PDCP SDU received from upper layers, the transmitting PDCP entity shall:

associate the COUNT value corresponding to TX_NEXT to this PDCP SDU;

NOTE 1 Associating more than half of the PDCP SN space of contiguous PDCP SDUs with PDCP SNs, when e.g., the PDCP SDUs are discarded or transmitted without acknowledgement, may cause HFN desynchronization problem. How to prevent HFN desynchronization problem is left up to UE implementation

-perform header compression of the PDCP SDU;

-perform integrity protection, and ciphering using the TX_NEXT;

-set the PDCP SN of the PDCP Data PDU to TX_NEXT modulo 2[pdcp-SN-Size];

-increment TX_NEXT by one;

-submit the resulting PDCP Data PDU to lower layer.

There is no explicit transmission window in PDCP specification, but it can be defined as covering the following range [TX_NEXT-window_size, TX_NEXT[, with window_size equal to half of the PDCP SN space. This is a convenient definition which is also the general understanding from PDCP specification.

The above NOTE1 is meant to address what is known as “HFN desynchronization issue”. Consider the possible following scenario:

- the PDCP transmitting entity generates N PDCP PDUs, N > half of the PDCP SN space

- those PDCP PDUs are discarded (e.g. by discard timer) or lost on air interface (e.g. tunnel)

At the receiver, there will be a gap of N PDCP SNs, N > half of the PDCP SN space. The HFN of following PDUs will not be correctly derived and those PDUs will be either discarded or associated with the wrong COUNT, leading to deciphering issues.

If PDCP packet duplication is activated for a RB, in case of a “slow leg/fast leg” scenario, buffering in the slow leg might lead to similar though different issue.

Figure 12 shows a radio bearer with two associated RLC channels (links). PDCP packet duplication is activated for the radio bearer.

Transmissions of PDCP PDUs on the “fast leg” ensure that the PDCP receiver HFN is synched with the PDCP transmitter. From this point of view, there is no HFN desynchronization, as the “fast leg” enables to keep HFN synchronization between both PDCP entities. If the “slow leg” leads to more than half of the PDCP SN space being buffered in RLC/PDCP, when those old duplicate PDCP PDUs will eventually be transmitted by the “slow leg”:

- they will either fall in the discard window (this would not cause any issue)

- or if they are really late (M >= PDCP SN space), they will fall in the reordering window. In that case, they will be deciphered with incorrect COUNT value, but considered as valid from PDCP point of view, as there is no way for PDCP to notice the deciphering issue. Such PDU with wrong COUNT value could be discarded only if integrity protection was activated for the bearer, however this is optional and will generally not be activated as it is costly in terms of overhead and processing. The PDCP PDU wrongly deciphered will generate a PDCP SDU which will generally be discarded by upper layers (e.g. wrong IP header). However, the PDCP layer will consider the good PDCP PDU received by the good leg as a duplicate and discard it.

As it can be seen, even if there is no HFN desynchronization issue thanks to the “fast leg”, an issue of “Late PDCP PDUs” being transmitted by the “slow leg” can occur, leading to protocol issues (good PDCP PDUs would be discarded at the PDCP receiver, leading to PDCP SDU loss). This problem is addressed by the present technology as explained above with reference to figures 2 and 3.

If to prevent above protocol problem, an alternative is to extend the “NOTE1” rule to cover the UL PDCP duplication case. Given the agreed PDCP modelling, since most of the PDCP PDUs in case of “fast leg” I “slow leg” scenario are no longer in PDCP, it would be needed to explicitly take into account PDCP PDUs already submitted to lower layers (RLC entity). The NOTE1 could be amended by adding “including to PDCP PDUs already submitted to lower layers but still buffered for transmission”, or “including to PDCP PDUs already submitted to lower layers not yet transmitted”, as follows:

Amended NOTE 1: Associating more than half of the PDCP SN space of contiguous PDCP SDUs with PDCP SNs (including to PDCP PDUs already submitted to lower layers but still buffered for transmission), when e.g., the PDCP SDUs are discarded or transmitted without acknowledgement, may cause HFN desynchronization problem. How to prevent HFN desynchronization problem is left up to UE implementation.

The understanding would be that to prevent any issue, the PDCP entity would have to refrain from generating any new PDCP PDU once PDCP PDUs corresponding to half of the PDCP SN space are already generated and not yet transmitted (for at least one leg). The consequence would be a stall of the transmission: due to the “slow leg”, the PDCP entity can no longer transmit data on the “fast leg”.

This would prevent above protocol problem. However, as it can be seen, the data transmission becomes limited by the “slow leg”, i.e. the protocol problem becomes a performance problem.

Figure 13 is an example of a wireless network 1300 with two wireless communication devices. Wireless communication devices 1305, 1307, such as an access device, base station, NodeB, eNB, wireless headset, access terminal, client station, or mobile station, can include circuitry such as processor electronics 1310, 1312. Processor electronics 1310, 1312 can include one or more processors that implement one or more techniques presented in this disclosure. Wireless communication devices 1305, 1307 include circuitry such as transceiver electronics 1315, 1317 to send and receive wireless signals over one or more antennas 1320a, 1320b, 1322a, 1322b. In some implementations, transceiver electronics 1315, 1317 include integrated transmitting and receiving circuitry. In some implementations, transceiver electronics 1315, 1317 include multiple radio units. In some implementations, a radio unit includes a baseband unit (BBU) and a radio frequency unit (RFU) to transmit and receive signals. Transceiver electronics 1315, 1317 can include one or more of: detector, decoder, modulator, and encoder. Transceiver electronics 1315, 1317 can include one or more analog circuits. Wireless communication devices 1305, 1307 include one or more memories 1325, 1327 configured to store information such as data, instructions, or both. In some implementations, wireless communication devices 1305, 1307 include dedicated circuitry for transmitting and dedicated circuitry for receiving. In some implementations, a wireless communication device 1305, 1307 is operable to act as a serving device (e.g., an access point), or a client device.

The various wireless communications functions can be performed by the wireless communication devices 1305, 1307 using a protocol stack (e.g., the protocol stack described with respect to FIG. 4). Data packets encoded in different protocols for different layers of the protocol stack can be stored in the memory 1325, 1327. The processor electronics 1310, 1312 execute instructions to pass data packets between layers included in the protocol stack as PDU or SDU. Data packets of an entity can be processed and transmitted by a wireless communication device to a peer entity on the same layer of the other wireless communication device. The radio frequency processing and transmission of the data packets can be performed by the transceiver electronics 1315, 1317 and the one or more antennas 1320, 1322, respectively.

Although not shown in detail any of the devices or apparatus that form part of the network may include at least a processor, a storage unit and a communications interface, wherein the processor unit, storage unit, and communications interface are configured to perform the method of any aspect of the present invention. Further options and choices are described below.

The signal processing functionality of the embodiments of the invention especially the gNB and the LIE may be achieved using computing systems or architectures known to those who are skilled in the relevant art. Computing systems such as, a desktop, laptop or notebook computer, hand-held computing device (PDA, cell phone, palmtop, etc.), mainframe, server, client, or any other type of special or general purpose computing device as may be desirable or appropriate for a given application or environment can be used. The computing system can include one or more processors which can be implemented using a general or special-purpose processing engine such as, for example, a microprocessor, microcontroller or other control module.

The computing system can also include a main memory, such as random access memory (RAM) or other dynamic memory, for storing information and instructions to be executed by a processor. Such a main memory also may be used for storing temporary variables or other intermediate information during execution of instructions to be executed by the processor. The computing system may likewise include a read only memory (ROM) or other static storage device for storing static information and instructions for a processor.

The computing system may also include an information storage system which may include, for example, a media drive and a removable storage interface. The media drive may include a drive or other mechanism to support fixed or removable storage media, such as a hard disk drive, a floppy disk drive, a magnetic tape drive, an optical disk drive, a compact disc (CD) or digital video drive (DVD) read or write drive (R or RW), or other removable or fixed media drive. Storage media may include, for example, a hard disk, floppy disk, magnetic tape, optical disk, CD or DVD, or other fixed or removable medium that is read by and written to by media drive. The storage media may include a computer-readable storage medium having particular computer software or data stored therein.

In alternative embodiments, an information storage system may include other similar components for allowing computer programs or other instructions or data to be loaded into the computing system. Such components may include, for example, a removable storage unit and an interface , such as a program cartridge and cartridge interface, a removable memory (for example, a flash memory or other removable memory module) and memory slot, and other removable storage units and interfaces that allow software and data to be transferred from the removable storage unit to computing system.

The computing system can also include a communications interface. Such a communications interface can be used to allow software and data to be transferred between a computing system and external devices. Examples of communications interfaces can include a modem, a network interface (such as an Ethernet or other NIC card), a communications port (such as for example, a universal serial bus (USB) port), a PCMCIA slot and card, etc. Software and data transferred via a communications interface are in the form of signals which can be electronic, electromagnetic, and optical or other signals capable of being received by a communications interface medium.

In this document, the terms ‘computer program product’, ‘computer-readable medium’ and the like may be used generally to refer to tangible media such as, for example, a memory, storage device, or storage unit. These and other forms of computer-readable media may store one or more instructions for use by the processor comprising the computer system to cause the processor to perform specified operations. Such instructions, generally referred to as ‘computer program code’ (which may be grouped in the form of computer programs or other groupings), when executed, enable the computing system to perform functions of embodiments of the present invention. Note that the code may directly cause a processor to perform specified operations, be compiled to do so, and/or be combined with other software, hardware, and/or firmware elements (e.g., libraries for performing standard functions) to do so.

The non-transitory computer readable medium may comprise at least one from a group consisting of: a hard disk, a CD-ROM, an optical storage device, a magnetic storage device, a Read Only Memory, a Programmable Read Only Memory, an Erasable Programmable Read Only Memory, EPROM, an Electrically Erasable Programmable Read Only Memory and a Flash memory

In an embodiment where the elements are implemented using software, the software may be stored in a computer-readable medium and loaded into computing system using, for example, removable storage drive. A control module (in this example, software instructions or executable computer program code), when executed by the processor in the computer system, causes a processor to perform the functions of the invention as described herein.

Furthermore, the inventive concept can be applied to any circuit for performing signal processing functionality within a network element. It is further envisaged that, for example, a semiconductor manufacturer may employ the inventive concept in a design of a stand-alone device, such as a microcontroller of a digital signal processor (DSP), or application-specific integrated circuit (ASIC) and/or any other sub-system element.

It will be appreciated that, for clarity purposes, the above description has described embodiments of the invention with reference to a single processing logic. However, the inventive concept may equally be implemented by way of a plurality of different functional units and processors to provide the signal processing functionality. Thus, references to specific functional units are only to be seen as references to suitable means for providing the described functionality, rather than indicative of a strict logical or physical structure or organisation.

Aspects of the invention may be implemented in any suitable form including hardware, software, firmware or any combination of these. The invention may optionally be implemented, at least partly, as computer software running on one or more data processors and/or digital signal processors or configurable module components such as FPGA devices. Thus, the elements and components of an embodiment of the invention may be physically, functionally and logically implemented in any suitable way. Indeed, the functionality may be implemented in a single unit, in a plurality of units or as part of other functional units.

Although the present invention has been described in connection with some embodiments, it is not intended to be limited to the specific form set forth herein.

Rather, the scope of the present invention is limited only by the accompanying claims. Additionally, although a feature may appear to be described in connection with particular embodiments, one skilled in the art would recognize that various features of the described embodiments may be combined in accordance with the invention. In the claims, the term ‘comprising’ does not exclude the presence of other elements or steps.

Furthermore, although individually listed, a plurality of means, elements or method steps may be implemented by, for example, a single unit or processor. Additionally, although individual features may be included in different claims, these may possibly be advantageously combined, and the inclusion in different claims does not imply that a combination of features is not feasible and/or advantageous. Also, the inclusion of a feature in one category of claims does not imply a limitation to this category, but rather indicates that the feature is equally applicable to other claim categories, as appropriate.

Furthermore, the order of features in the claims does not imply any specific order in which the features must be performed and in particular the order of individual steps in a method claim does not imply that the steps must be performed in this order. Rather, the steps may be performed in any suitable order. In addition, singular references do not exclude a plurality. Thus, references to ‘a’, ‘an’, ‘first’, ‘second’, etc. do not preclude a plurality.

Although the present invention has been described in connection with some embodiments, it is not intended to be limited to the specific form set forth herein. Rather, the scope of the present invention is limited only by the accompanying claims. Additionally, although a feature may appear to be described in connection with particular embodiments, one skilled in the art would recognise that various features of the described embodiments may be combined in accordance with the invention. In the claims, the term ‘comprising’ or “including” does not exclude the presence of other elements.

Claims (14)

1. A computer-implemented method performed by a user equipment in a telecommunications network the method comprising:

carrying out a packet data convergence protocol (PDCP) duplication process comprising, computing PDCP protocol data units (PDUs) from SDUs received at a PDCP layer of a protocol stack of the user equipment, computing duplicates of the PDCP PDUs, transmitting the PDCP protocol data units (PDUs) on a first radio link control bearer from the user equipment to a PDCP receiver at a node of the telecommunications network, and transmitting the duplicates on a duplicate link, being a second radio link control bearer from the user equipment to the PDCP receiver;

observing the PDCP duplication process; and when specified conditions of the PDCP duplication process are observed, performing an implicit deactivation of packet duplication.

2. The method of claim 1, wherein the specified conditions comprise, for at least one of the radio link control bearers, a threshold number of the PDCP PDUs being buffered before transmission not including duplicate PDCP PDUs.

3. The method of claim 2 wherein the PDCP PDUs buffered for transmission not including duplicate PDCP PDUs, comprises PDCP PDUs buffered in PDCP, as well as in lower layers (RLC), within RLC SDUs or RLC PDUs.

4. The method of claim 2 or claim 3 wherein the threshold number is half of a the PDCP sequence number space.

5. The method of claim 1 wherein the specified conditions comprise, a transmission window size being higher than a threshold, the transmission window being a transmission window of the PDCP duplication process used for either the first or second radio link control bearer.

6. The method of claim 1 wherein the specified conditions comprise, a queuing time being longer than a threshold, where the queuing time is a time from receipt of an SDU to transmission of a corresponding PDCP PDU.

7. The method of any preceding claim wherein the specified conditions apply to only the duplicate link.

8. The method of any preceding claim wherein the specified conditions apply to either of the first radio link control bearer and the second radio link control bearer.

9. The method of claim 1 wherein the specified conditions comprise a delta time exceeding a threshold, where the delta time is a difference between the time when a PDCP PDU is transmitted on one of the radio link control bearers and a time when a duplicate of the PDCP PDU is transmitted on the other radio link control bearer.

10. The method of any preceding claim wherein the logical channels from first and second radio link control bearers are restricted onto different carriers, and wherein performing an implicit deactivation of packet duplication further comprises removing these restrictions for those logical channels.

11. The method of any preceding claim wherein the first and second radio link control bearers use different cell groups of the telecommunications network, and wherein performing an implicit deactivation of packet duplication further comprises reverting to split bearer operation over the different cell groups.

12. The method of any preceding claim further comprising sending a notification of duplication deactivation to the PDCP receiver.

13. A user equipment, UE, apparatus comprising a processor, a storage unit and a communications interface, wherein the processor unit, storage unit, and communications interface are configured to perform the method as claimed in any one of claims 1 -14.

14. A non-transitory computer readable medium having computer readable instructions stored thereon for execution by a processor to perform the method according to any of claims 1-14.

Intellectual