WO2015064931A1 - Method and apparatus for reconfiguring a bearer - Google Patents
Method and apparatus for reconfiguring a bearer Download PDFInfo
- Publication number
- WO2015064931A1 WO2015064931A1 PCT/KR2014/009581 KR2014009581W WO2015064931A1 WO 2015064931 A1 WO2015064931 A1 WO 2015064931A1 KR 2014009581 W KR2014009581 W KR 2014009581W WO 2015064931 A1 WO2015064931 A1 WO 2015064931A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- pdcp
- bearer
- split bearer
- pdus
- menb
- Prior art date
Links
- 238000000034 method Methods 0.000 title claims abstract description 49
- 230000005540 biological transmission Effects 0.000 claims abstract description 66
- 238000012790 confirmation Methods 0.000 claims abstract description 14
- 230000000977 initiatory effect Effects 0.000 claims abstract description 9
- 238000010295 mobile communication Methods 0.000 claims abstract description 9
- 230000007774 longterm Effects 0.000 claims abstract description 6
- 230000001174 ascending effect Effects 0.000 claims description 5
- 230000006399 behavior Effects 0.000 description 30
- 238000004891 communication Methods 0.000 description 6
- 230000006835 compression Effects 0.000 description 6
- 238000007906 compression Methods 0.000 description 6
- 238000005516 engineering process Methods 0.000 description 6
- 230000011664 signaling Effects 0.000 description 6
- 101100077212 Schizosaccharomyces pombe (strain 972 / ATCC 24843) rlc1 gene Proteins 0.000 description 5
- 230000009977 dual effect Effects 0.000 description 5
- 238000012986 modification Methods 0.000 description 4
- 230000004048 modification Effects 0.000 description 4
- 230000008569 process Effects 0.000 description 4
- 230000009471 action Effects 0.000 description 3
- 238000007726 management method Methods 0.000 description 3
- 230000009467 reduction Effects 0.000 description 3
- 230000001413 cellular effect Effects 0.000 description 2
- 230000000694 effects Effects 0.000 description 2
- 230000006870 function Effects 0.000 description 2
- 238000005259 measurement Methods 0.000 description 2
- 239000007787 solid Substances 0.000 description 2
- 230000001960 triggered effect Effects 0.000 description 2
- IESVDEZGAHUQJU-ZLBXKVHBSA-N 1-hexadecanoyl-2-(4Z,7Z,10Z,13Z,16Z,19Z-docosahexaenoyl)-sn-glycero-3-phosphocholine Chemical compound CCCCCCCCCCCCCCCC(=O)OC[C@H](COP([O-])(=O)OCC[N+](C)(C)C)OC(=O)CC\C=C/C\C=C/C\C=C/C\C=C/C\C=C/C\C=C/CC IESVDEZGAHUQJU-ZLBXKVHBSA-N 0.000 description 1
- 108700026140 MAC combination Proteins 0.000 description 1
- 101150014328 RAN2 gene Proteins 0.000 description 1
- 238000013459 approach Methods 0.000 description 1
- 230000003190 augmentative effect Effects 0.000 description 1
- 230000008859 change Effects 0.000 description 1
- 238000004590 computer program Methods 0.000 description 1
- 238000012217 deletion Methods 0.000 description 1
- 230000037430 deletion Effects 0.000 description 1
- 238000013461 design Methods 0.000 description 1
- 238000011161 development Methods 0.000 description 1
- 238000007689 inspection Methods 0.000 description 1
- 238000012545 processing Methods 0.000 description 1
- 230000004044 response Effects 0.000 description 1
- 230000019491 signal transduction Effects 0.000 description 1
- 238000012546 transfer Methods 0.000 description 1
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
- H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W36/00—Hand-off or reselection arrangements
- H04W36/02—Buffering or recovering information during reselection ; Modification of the traffic flow during hand-off
- H04W36/023—Buffering or recovering information during reselection
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
- H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
- H04L1/18—Automatic repetition systems, e.g. Van Duuren systems
- H04L1/1867—Arrangements specially adapted for the transmitter end
- H04L1/188—Time-out mechanisms
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/40—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks using virtualisation of network functions or resources, e.g. SDN or NFV entities
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W76/00—Connection management
- H04W76/30—Connection release
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
- H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
- H04L1/1607—Details of the supervisory signal
- H04L1/1614—Details of the supervisory signal using bitmaps
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
- H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
- H04L1/1607—Details of the supervisory signal
- H04L1/1685—Details of the supervisory signal the supervisory signal being transmitted in response to a specific request, e.g. to a polling signal
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
- H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
- H04L1/18—Automatic repetition systems, e.g. Van Duuren systems
- H04L1/1867—Arrangements specially adapted for the transmitter end
- H04L1/1874—Buffer management
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W28/00—Network traffic management; Network resource management
- H04W28/02—Traffic management, e.g. flow control or congestion control
- H04W28/0205—Traffic management, e.g. flow control or congestion control at the air interface
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W28/00—Network traffic management; Network resource management
- H04W28/02—Traffic management, e.g. flow control or congestion control
- H04W28/0252—Traffic management, e.g. flow control or congestion control per individual bearer or channel
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W76/00—Connection management
- H04W76/10—Connection setup
- H04W76/15—Setup of multiple wireless link connections
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W76/00—Connection management
- H04W76/20—Manipulation of established connections
- H04W76/22—Manipulation of transport tunnels
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W80/00—Wireless network protocols or protocol adaptations to wireless operation
- H04W80/02—Data link layer protocols
Definitions
- the present invention relates to bearer reconfiguration.
- certain embodiments of the present invention relate to reconfiguration of a split bearer to a non-split bearer, or vice versa, in a 3rd Generation Partnership Project (3GPP) Long Term Evolution (LTE) or LTE Advanced compliant mobile communications network comprising a mobile terminal (also referred to herein as the User Equipment, UE) and network equipment.
- 3GPP 3rd Generation Partnership Project
- LTE Long Term Evolution
- UE User Equipment
- the present invention relates to determining which Packet Data Convergence Protocol, PDCP, Service Data Units (SDUs) the UE should retransmit following bearer reconfiguration.
- PDCP Packet Data Convergence Protocol
- SDUs Service Data Units
- Wireless or mobile (cellular) communications networks in which a mobile terminal (UE, such as a mobile handset) communicates via a radio link to a network of base stations (eNBs) or other wireless access points connected to a telecommunications network, have undergone rapid development through a number of generations.
- eNBs base stations
- eNBs base stations
- GERAN GSM Enhanced Data rates for GSM Evolution Radio Access Network
- Second generation systems have themselves been largely replaced by or augmented by Third Generation (3G) digital systems such as the Universal Mobile Telecommunications System (UMTS), which uses a Universal Terrestrial Radio Access Network (UTRAN) radio access technology and a similar core network to GSM.
- UMTS is specified in standards produced by 3GPP.
- Third generation standards provide for a greater throughput of data than is provided by second generation systems. This trend is continued with the move towards Fourth Generation (4G) systems.
- 3GPP design specify and standardise technologies for mobile wireless communications networks. Specifically, 3GPP produces a series of Technical Reports (TR) and Technical Specifications (TS) that define 3GPP technologies.
- TR Technical Reports
- TS Technical Specifications
- the focus of 3GPP is currently the specification of standards beyond 3G, and in particular an Evolved Packet System (EPS) offering enhancements over 3G networks, including higher data rates.
- the set of specifications for the EPS comprises two work items: Systems Architecture Evolution (SAE, concerning the core network) and LTE concerning the air interface.
- SAE Systems Architecture Evolution
- LTE concerning the air interface.
- the first set of EPS specifications were released as 3GPP Release 8 in December 2008.
- LTE uses an improved radio access technology known as Evolved UTRAN (E-UTRAN), which offers potentially greater capacity and additional features compared with previous standards.
- E-UTRAN Evolved UTRAN
- EPC Evolved Packet Core
- LTE is commonly used to refer to the whole of the EPS, including by 3GPP themselves.
- LTE is used in this sense in the remainder of this specification, including when referring to LTE enhancements, such as LTE Advanced.
- LTE is an evolution of UMTS and shares certain high level components and protocols with UMTS.
- LTE Advanced offers still higher data rates compared to LTE and is defined by 3GPP standards releases from 3GPP Release 10 up to and including 3GPP Release 12.
- LTE Advanced is considered to be a 4G mobile communication system by the International Telecommunication Union (ITU).
- ITU International Telecommunication Union
- the present invention is implemented within an LTE mobile network. Therefore, an overview of an LTE network is shown in Figure 1.
- the LTE system comprises three high level components: at least one UE 102, the E-UTRAN 104 and the EPC 106.
- the EPC 106 communicates with Packet Data Networks (PDNs) and servers 108 in the outside world.
- Figure 1 shows the key component parts of the EPC 106. It will be appreciated that Figure 1 is a simplification and a typical implementation of LTE will include further components.
- interfaces between different parts of the LTE system are shown.
- the double ended arrow indicates the air interface between the UE 102 and the E-UTRAN 104. For the remaining interfaces user data is represented by solid lines and signalling is represented by dashed lines.
- the E-UTRAN 104 comprises a single type of component: an eNB (E-UTRAN Node B) which is responsible for handling radio communications between the UE 102 and the EPC 106 across the air interface.
- An eNB controls UEs 102 in one or more cell.
- LTE is a cellular system in which the eNBs provide coverage over one or more cells. Typically there is a plurality of eNBs within an LTE system. In general, a UE in LTE communicates with one eNB through one cell at a time.
- the EPC 106 Key components of the EPC 106 are shown in Figure 1. It will be appreciated that in an LTE network there may be more than one of each component according to the number of UEs 102, the geographical area of the network and the volume of data to be transported across the network. Data traffic is passed between each eNB and a corresponding Serving Gateway (S-GW) 110 which routes data between the eNB and a PDN Gateway (P-GW) 112. The P-GW 112 is responsible for connecting a UE to one or more servers or PDNs 108 in the outside world.
- S-GW Serving Gateway
- P-GW PDN Gateway
- the P-GW 112 is responsible for connecting a UE to one or more servers or PDNs 108 in the outside world.
- the Mobility Management Entity (MME) 114 controls the high-level operation of the UE 102 through signalling messages exchanged with the UE 102 through the E-UTRAN 104. Each UE is registered with a single MME.
- MME Mobility Management Entity
- Signalling messages between the MME 114 and the UE 102 comprise EPS Session Management (ESM) protocol messages controlling the flow of data from the UE to the outside world and EPS Mobility Management (EMM) protocol messages controlling the rerouting of signalling and data flows when the UE 102 moves between eNBs within the E-UTRAN.
- EMM EPS Session Management
- EMM EPS Mobility Management
- the MME 114 exchanges signalling traffic with the S-GW 110 to assist with routing data traffic.
- the MME 114 also communicates with a Home Subscriber Server (HSS) 116 which stores information about users registered with the network.
- HSS Home Subscriber Server
- An EPS bearer serves to transfer data between a UE and a P-GW.
- the data flow is bi-directional.
- Data carried by an EPS bearer comprises one or more service data flows carrying data for a particular service, for instance streamed media.
- Each service data flow comprises one or more packet flows.
- 3GPP Radio Access Network (RAN) workgroups are current working on a Study Item (SI) called “Small Cell Enhancements”.
- SI Study Item
- the technical outcome of this SI is documented in 3GPP TR 36.842 “Evolved Universal Terrestrial Radio Access (E-UTRA)”; Study on Small Cell enhancements for E-UTRA and E-UTRAN ? Higher layer aspects (Release 12); v0.4.0.
- 3GPP TR 36.842 concerns the radio access aspects of the SI and impacts upon both the UE and the eNB.
- Small cell enhancements are applicable, for instance, where there is a macro cell and a small cell (within the coverage area of the macro cell) operating on the same carrier frequency.
- Dual connectivity refers to an operation where a given UE consumes radio resources provided by at least two different network points (Master and Secondary eNBs) connected with non-ideal backhaul while the UE is active within the network (in an RRC_CONNECTED (Radio Resource Control Connected) state. Dual connectivity permits a greater data rate to be achieved between the UE and the RAN.
- RRC_CONNECTED Radio Resource Control Connected
- Dual connectivity permits a greater data rate to be achieved between the UE and the RAN.
- the RAN will support “bearer split” functionality.
- bearer split refers to the ability to split a bearer over multiple eNBs.
- a Master eNB (MeNB, usually the macro cell eNB) is the eNB which terminates at least S1-MME interface (the interface between the eNB and the MME) and therefore act as mobility anchor towards the Core Network (CN).
- a Secondary eNB (SeNB) is an eNB providing additional radio resources for the UE, which is not the MeNB.
- this shows option 3 of Figure 8.1.1-1 of TS 36.842, which illustrates one bearer split option, taking the downlink direction as an example.
- EPS bearer (#1: solid arrows) communicating directly from a P-GW (not shown) via the S-GW and the MeNB to the UE.
- a second EPS bearer (#2: dashed arrows) passes from the MeNB to the UE via the SeNB as well as directly between the MeNB and the UE.
- the second EPS bearer is split across the RAN.
- the eNB for communicating with the UE across the air interface, the eNB comprises a protocol stack having a PDCP layer, a Radio Link Control (RLC) layer and a Medium Access Control (MAC) layer. Collectively, these protocol layers form the data link layer: layer two of the standard Open Systems Interconnection (OSI) model.
- OSI Open Systems Interconnection
- the MAC layer carries out low-level control of the physical layer (layer 1 of the OSI model, and outside of the scope of the present specification), including scheduling data transmissions between the mobile and the base station.
- the RLC layer maintains the data link between the UE and the eNB, and handles the acknowledgement of receipt of data packets, when required.
- the PDCP layer carries out higher-level transport functions including header compression and security.
- SDU Service Data Unit
- PDU Protocol Data Unit
- the PDU becomes the incoming SDU of the next layer down the stack.
- a split radio bearer uses two RLC entities as shown in Figure 3, which reproduces Figure 8.1.1.8-1 from 3GPP TR 36.842.
- Figure 3 shows a first non-split bearer protocol stack at the MeNB (solid boxes).
- Figure 3 shows data being received from the S-GW across the S1 interface.
- Figure 3 further shows a second split radio bearer (dashed boxes and dashed arrows).
- the split bearer there is a single PDCP entity at the MeNB and duplicated RLC/MAC protocol stack entities for the split bearer in both the MeNB and the SeNB.
- Data is sent between the single PDCP entity in the MeNB and the RCL/MAC entities in the SeNB across the Xn interface (alternatively referred to as the X2 interface).
- the Xn interface alternatively referred to as the X2 interface.
- the UE side there would be corresponding MAC/RLC/PDCP entities, and specifically a single UE PDCP entity and duplicated UE MAC/RLC entities.
- part or the whole of the radio bearer protocol stack may be moved from one termination point to another termination point, for instance from one eNB to another eNB. For non-split radio bearers this may be due to the UE roaming between cells controlled by separate eNBs. In this case some of the on-going transmissions in the discontinued user plane stack will be terminated before successful delivery of the corresponding PDCP SDUs has been ensured. To overcome the loss that would be the result of this termination, PDCP SDU retransmissions may be initiated after the radio bearer protocol stack move.
- 3GPP RAN2 specifications have only specified how PDCP SDU retransmissions are handled for non-split bearers (that is, how PDCP SDU retransmissions are to be handled when the complete RAN protocol stack is moved). If it is required to reconfigure a split bearer as a non-split bearer, for instance due to the UE moving out of the coverage area of the small cell, while remaining in the coverage area of the macro cell, then this also requires at least the part of the radio bearer protocol stack within the SeNB to be moved. Applying the same retransmission techniques when reconfiguring a split bearer to a non-split bearer will lead to inefficient retransmission, as is described in greater detail below.
- a data transmission method of a User Equipment, UE, in a Long Term Evolution, LTE, compliant mobile communications network comprising: detecting reconfiguration of a bearer from a split bearer in which uplink Packet Data Convergence Protocol, PDCP, Protocol Data Units, PDUs, are transmitted to both a Master eNB, MeNB, and to a Secondary eNB, SeNB, to a non-split bearer in which uplink PDCP PDUs are transmitted only to the MeNB; and if reconfiguration of a bearer from a split bearer to a non-split bearer in which uplink PDCP PDUs are transmitted to the MeNB is detected: initiating retransmission of PDCP Service Data Units, SDUs, from the first PDCP SDU for which transmission of the corresponding PDCP PDU was attempted via the SeNB and for which there has been no confirmation of successful delivery by a protocol layer below the PD
- the retransmission of PDCP SDUs may be in ascending order of count values assigned to the PDCP SDUs prior to the reconfiguration of the bearer.
- the method may further comprise: receiving a PDCP status report from the MeNB; and determining that PDCP SDUs that are indicated in the PDCP status report as received need not be retransmitted.
- the UE may be configured to use only bearers for which successful delivery of PDCP PDUs is acknowledged by the eNB at a protocol layer below the PDCP layer.
- the UE may be configured to use only bearers using Radio Link Control Acknowledged Mode, RLC-Acknowledged Mode.
- Successful delivery of a PDCP PDU may be confirmed by the Radio Link Control, RLC, layer or the Medium Access Control, MAC, layer.
- the method may further comprise: detecting reconfiguration of a bearer from a split bearer in which uplink Packet Data Convergence Protocol, PDCP, Protocol Data Units, PDUs, are transmitted to both a Master eNB, MeNB, and to a Secondary eNB, SeNB, to a non-split bearer in which uplink PDCP PDUs are transmitted to the SeNB; and if reconfiguration of a bearer from a split bearer to a non-split bearer in which uplink PDCP PDUs are transmitted only to the SeNB is detected: initiating retransmissoin of PDCP SDUs from the first PDCP SDU for which there is no confirmation of successful delivery of a corresponding PDCP PDU by a protocol layer below the PDCP layer within the UE; and retransmitting all PDCP SDUs from the first PDCP SDU.
- PDCP Packet Data Convergence Protocol
- PDUs Protocol Data Units
- the method may further comprise: detecting reconfiguration of a bearer from a non-split bearer to split bearer; and if reconfiguration of a bearer from a non-split bearer to a split bearer is detected: determining whether, before reconfiguration of the bearer from a split bearer to a non-split bearer, PDCP transmission were terminated within the MeNB or the SeNB; wherein if it is determined that PDCP transmissions were terminated within the MeNB then the method further comprises determining that no PDCP SDU retransmissions are required.
- the method further comprises: initiating retransmission of PDCP SDUs from the first PDCP SDU for which there is no confirmation of successful delivery of a corresponding PDCP PDU by a protocol layer below the PDCP layer within the UE; and retransmitting all PDCP SDUs from the first PDCP SDU.
- the method may further comprise detecting reconfiguration of a bearer from a split bearer in which uplink PDCP PDUs are transmitted to only one of a MeNB and a SeNB to a non-split bearer in which uplink PDCP PDUs are transmitted to the MeNB; determining whether before reconfiguration PDCP PDU transmissions from the UE were restricted to transmissions to just the MeNB or just the SeNB; wherein if it is determined that PDCP PDU transmissions from the UE were restricted to transmissions to just the MeNB then the method further comprises determining that no PDCP SDU retransmissions are required; and wherein if it is determined that PDCP PDU transmissions from the UE were restricted to transmissions to just the SeNB then the method further comprises: initiating retransmission of PDCP SDUs from the first PDCP SDU for which there is no confirmation of successful delivery of a corresponding PDCP PDU by a protocol layer below the PDCP layer within the UE; and retransmitting
- a User Equipment in a Long Term Evolution, LTE, compliant mobile communications network, wherein the UE is arranged to: detect reconfiguration of a bearer from a split bearer in which uplink Packet Data Convergence Protocol, PDCP, Protocol Data Units, PDUs, are transmitted to both a Master eNB, MeNB, and to a Secondary eNB, SeNB, to a non-split bearer in which uplink PDCP PDUs are transmitted only to the MeNB; if reconfiguration of a bearer from a split bearer to a non-split bearer in which uplink PDCP PDUs are transmitted to the MeNB is detected, initiate retransmission of PDCP Service Data Units, SDUs, from the first PDCP SDU for which transmission of the corresponding PDCP PDU was attempted via the SeNB and for which there has been no confirmation of successful delivery by a protocol layer below the PDCP layer within the
- the UE may be further arranged to implement the above described method.
- Another aspect of the invention provides a computer program comprising instructions arranged, when executed, to implement a method and/or apparatus in accordance with any one of the above-described aspects.
- a further aspect provides machine-readable storage storing such a program.
- Certain embodiments of the present invention relate specifically to retransmissions of PDCP SDUs from the UE to the network.
- Certain embodiments of the present invention are specifically concerned with the case that a split bearer is reconfigured to a non-split bearer while keeping the same PDCP entity in the network. In this case the part of the user plane stack in the SeNB is terminated and transmissions on-going in that part may be lost.
- Certain embodiments of the invention are concerned specifically with bearers configured for reliable transport, for instance using RLC-Acknowledged Mode.
- the transmitter sends PDUs and stores the PDUs in a retransmission buffer until an acknowledgement of receipt is received.
- the transmitter regularly polls the receiver to return a status PDU listing the received PDUs.
- the transmitter may then delete the received PDUs from the buffer and re-transmit the remaining PDUs.
- FIG 1 schematically illustrates an overview of an LTE mobile communication network
- Figure 2 illustrates a split bearer
- Figure 3 illustrates a RAN protocol stack at a MeNB and a SeNB for the split bearer of Figure 2;
- Figure 4 illustrates a message flow during an X2 handover of a non-split bearer between a source eNB and a target eNB;
- Figure 5 illustrates the format of a PDCP status report
- Figure 6 illustrates the delivery situation for a non-split radio bearer immediately before an X2 handover from a source eNB to a target eNB;
- Figure 7 illustrates PDCP SDU retransmissions for the delivery situation of Figure 6 upon the X2 handover, according to a first network option
- Figure 8 illustrates PDCP SDU retransmissions for the delivery situation of Figure 6 upon the X2 handover, according to a second network option
- Figure 9 illustrates the delivery situation for a split radio bearer immediately before reconfiguration to a non-split radio bearer
- Figures 10 to 15 illustrate PDCP SDU retransmissions for the delivery situation of Figure 9 following reconfiguration to a non-split bearer, according to a first to sixth options
- Figure 16 illustrates PDCP SDU retransmissions for the delivery situation of Figure 9 following reconfiguration to a non-split bearer, according to a first embodiment of the present invention
- Figure 17 illustrates PDCP SDU retransmissions for the delivery situation of Figure 9 following reconfiguration to a non-split bearer, according to a second embodiment of the present invention
- Figure 18 illustrates a message flow during reconfiguration of a bearer according an embodiment of the invention.
- Figure 19 is a flowchart illustrating a method of reconfiguring a bearer according to an embodiment of the invention.
- Embodiments of the invention will now be described in the context of an LTE compliant mobile wireless communications network operating in accordance with Release-11 and beyond of the 3GPP LTE standards. However, it will be understood that this is by way of example only and that other embodiments may involve other wireless networks, operating at least partially in compliance with other releases and other standards.
- this shows the message sequence chart for an “X2 handover” from 3GPP TS 36.300 ( Figure 10.1.2.1.1-1). Specifically, this shows an X2 handover of a UE in RRC_CONNECTED mode in which a non-split bearer is reconfigured such that it is terminated at a target eNB in place of a source eNB.
- the source eNB determines whether to handover.
- Steps 4 to 7 concern handover preparation during which the source eNB passes all necessary information to the target eNB for effecting the handover.
- Steps 8 to 11 comprise handover execution.
- Steps 12 to 18 comprise handover execution.
- a more detailed explanation of Figure 4 is provided in section 10.1.2.1.1 of 3GPP TS 36.300, but is not needed for explanation of the present invention.
- a first key step is the “Data Forwarding” of user data from the source eNB to the target eNB after step 8 (during handover execution).
- the source eNB may discard all such out of sequence PDCP SDUs and rely on the UE retransmitting all PDCP SDU’s from the first non-delivered PDCP SDU to the target eNB.
- the source eNB may forward all such out of sequence PDCP SDUs and ask the UE to only retransmit the missing PDCP SDUs to the target eNB.
- the source eNB shall either:
- the source eNB is further responsible for forwarding unacknowledged downlink PDCP SDUs to the target eNB and forwarding successively received uplink PDCP SDUs to the S-GW though this is outside of the scope of the present specification.
- a second key step is the “packet data” delivery of user data between the UE and the target eNB after step 11.
- the UE retransmits all PDCP SDUs for which successful delivery of corresponding PDCP PDU has not been confirmed by lower layers as documented in 3GPP TS 36.323 “Evolved Universal Terrestrial Radio Access (E-UTRA)”; Packet Data Convergence Protocol (PDCP) specification (Release 11); v11.2.0 section 5.2.1.1:
- the source eNB is configured to the option of not forwarding out of sequence PDCP SDUs, then the retransmission by the UE of all PDCP SDUs from the first PDCP SDU for which there is not lower layer confirmation of successful delivery is fine and no further action is required.
- the specifications allow the target eNB to inform the UE about the already received PDCP SDUs with a PDCP status report as described in 3GPP TS 36.323 section 6.2.6.
- Figure 4 does not show a PDCP status report message, though this would be provided after the data forwarding following step 8 and before the packet data transmission following step 11.
- Figure 5 reproduces Figure 6.2.6.1 of 3GPP TS 36.323 and shows the format of a PDCP Control PDU carrying one PDCP status report when a 12 bit sequence number length is used.
- the field FMS identifies the first missing PDCP serial number.
- the bitmap field indicates missing PDCP SDUs from the first missing PDCP SDU.
- the bitmap field is of length in bits equal to the number of PDCP sequence numbers from, but not including the first missing PDCP SDU and up to and including the last received out of sequence PDCP SDU, rounded to the next multiple of 8 bits. For each position in the bitmap a zero indicates a PDCP SDU sequence number which is not reported to have been received by the lower layers. A one in the bitmap indicates a received PDCP SDU.
- the UE may omit retransmissions of any PDCP SDUs which have been received by the source eNB. This behaviour is documented in section 5.4 of 3GPP TS 36.323:
- the UE shall discard the PDCP SDU along with the corresponding PDCP PDU. If the corresponding PDCP PDU has already been submitted to lower layers the discard is indicated to lower layers.
- Figure 6 shows a possible delivery situation for a non-split radio bearer just before an X2 handover.
- Figure 6 shows PDCP and RLC entities at both a UE and a source eNB (MAC entities are omitted for clarity). This split between the network and the UE is shown.
- the UE PDCP entity shows six PDCP PDUs for transmission to the source eNB PDCP entities.
- PDCP PDU 1 is the last PDCP PDU delivered in sequence to the eNB PDCP entity.
- PDCP PDUs 2 and 4 failed at during their first transmission at lower layers and will have to be retransmitted by the UE RLC entity.
- PDUs 3 and 5 have been delivered to the RLC entity at the eNB, but since the RLC entity only delivers PDCP PDU’s in sequence to PDCP, these PDCP PDU’s are still buffered at the source eNB RLC entity. Receipt of the PDUs 3 and 5 will have been acknowledged by the source eNB RLC entity to the UE RLC entity.
- Figure 7 shows what happens after X2 handover to a target eNB if the network implements the first option in which the source eNB discards out of sequence SDUs.
- the source eNB RLC entity delivers out of sequence delivered PDCP PDUs (PDUs 3 and 5) to the PDCP entity due to a re-establishment of the RLC entity in the source eNB.
- the source PDCP entity will discard these PDUs, indicated by PDUs 3 and 5 being crossed out.
- the UE retransmits all PDUs from the first non-delivery-confirmed PDCP PDU (PDCP PDU 2 in this example). Consequently, the UE must retransmit PDCP PDUs 2 to 6 (indicated by the arrows between the UE PDCP entity and the target eNB PDCP entity), even though PDUs 3 and 5 were successfully delivered to the network.
- Figure 8 shows what happens after X2 handover to a target eNB if the network implements the second option in which the source eNB forwards out of sequence SDUs.
- PDCP PDUs 3 and 5 are delivered to the source eNB PDCP entity due to a re-establishment of the RLC entity in the source eNB.
- this time PDCP PDUs 3 and 5 are forwarded to the target eNB PDCP entity.
- the UE Based on a PDCP status report as described above in connection with Figure 5, the UE knows that these PDCP PDUs do not have to be transmitted in the target eNB, thus saving resources in the UE and the target eNB. Consequently, the UE need only retransmit PDCP PDUs 2, 4 and 6 (indicated by the arrows between the UE PDCP entity and the target eNB PDCP entity).
- the same techniques described above for an X2 handover of a non-split bearer may be reapplied.
- the result is a significant reduction in efficiency caused by retransmission of data unnecessarily.
- the following cases relate to the reconfiguration of a split bearer to a non-split bearer in which the PDCP entity within a MeNB remains following the reconfiguration and the RLC/MAC entities within a SeNB are removed.
- RLC entities will in normal situations (other than for re-establishment) only deliver in sequence PDCP PDUs to the PDCP entity.
- each RLC entity is only handling part of the PDCP PDUs, they do not necessarily need to be consecutive PDCP PDUs such that there could be gaps in the PDCP PDUs delivered by each RLC entity to a PDCP entity for a split bearer.
- each RLC entity (one each for transmissions to eNB1 and eNB2) each PDCP PDU allocated for transmission to that eNB is numbered sequentially to form RLC PDUs, such that while there may be gaps in the numbering of PDCP PDUs sent to each eNB, there are no gaps for the RLC PDUs.
- the RLC entity does not pass received RLC PDUs to the PDCP entity out of sequence.
- Figure 9 shows a possible delivery situation for a split radio bearer just before reconfiguration from a split bearer to a non-split bearer.
- PDCP PDU 1 is the last in sequence PDCP PDU delivered via eNB1 RLC (the MeNB RLC entity) to the PDCP entity.
- PDCP PDU 4 is the last in PDCP PDU delivered via eNB2 RLC (the SeNB RLC entity).
- the UE is aware that PDCP PDUs 1 and 4 have successfully transmitted based on lower layer confirmation.
- PDCP PDUs 3, 5, 7 and 8 were also successful for PDCP PDUs 3, 5, 7 and 8 to the eNB RLC entities but all these PDUs remain buffered in the receiving RLC entity due to out of sequence reception (that is, the received RLC PDUs are out of sequence).
- PDCP PDUs 2 and 6 still need to be retransmitted by the UE though these have not necessarily failed transmissions. Since transmissions in eNB2 are discontinued, PDCP PDU6 cannot be received by the network PDCP entity unless there is a new retransmission from the UE.
- PDCP PDU2 will be delivered by the RLC/lower layers in eNB1 if these layers are not re-established.
- the amount of unnecessary retransmissions resulting from the current UE behaviour will depend on the network behaviour, as will now be set out via several example cases.
- the description of the following cases is not exhaustive of all possible scenarios for current UE behaviour and current network behaviour.
- the following example cases vary according to whether the eNB1 RLC is re-established, whether there is forwarding from the enB1 (SeNB) to the eNB2 (MeNB) and whether the PDCP entity sends a PDCP status report.
- PDUs 2, 3 and 5 On-going transmissions (PDUs 2, 3 and 5) will continue and eventually these PDCP PDUs will be delivered to the PDCP entity (unless of course they later fail and no acknowledgement of receipt is received by the UE before the normal acknowledgement timer expires, in which case they would be retransmitted conventionally).
- Case 1a No eNB1 RLC re-establishment; No forwarding of out of sequence PDCP PDUs from eNB2 RLC; No PDCP status report
- PDCP PDU 2 the first PDCP PDU for which there is no confirmation of receipt by the lower level layers.
- PDCP PDUs 2, 3, 4 and 5 are unnecessarily retransmitted by the UE, and retransmission of PDCP SDU’s 7 and 8 could have been avoided if eNB2 had forwarded out of sequence received PDUs.
- PDCP PDU 2 With the current UE behaviour the UE will restart transmissions from PDCP PDU 2 and only skip PDCP PDU 4.
- PDCP PDUs 2, 3 and 5 are unnecessarily retransmitted by the UE, and retransmission of PDCP SDU’s 7 and 8 could have been avoided if eNB2 had forwarded out of sequence received PDUs.
- PDCP PDU 2 With the current UE behaviour the UE will restart transmissions from PDCP PDU 2.
- PDCP PDUs 2, 3, 4, 5, 7 and 8 are unnecessarily retransmitted by the UE.
- Case 1b This case differs from Case 1b only in that there is forwarding from eNB2 RLC. As for Case 1b, it is probable that the PDCP status report will not indicate that PDCP PDUs 2, 3 and 5 have been received. However, differing from Case 1b, the PDCP status report will indicate that PDCP PDUs 7 and 8 (in addition to PDCP PDUs 1 and 4) do not need to be retransmitted.
- PDCP PDU 2 With the current UE behaviour the UE will restart transmissions from PDCP PDU 2 and only skip PDCP PDUs 4, 7 and 8. PDCP PDUs 2, 3 and 5 are unnecessarily retransmitted by the UE.
- Case 3a eNB1 RLC re-establishment; Forwarding of out of sequence PDCP PDUs from eNB2 RLC; No PDCP status report
- This case differs from Case 2a only in that the eNB1 RLC is re-established along with the corresponding UE RLC1 entity.
- PDCP PDU 2 With the UE current behaviour the UE will restart transmissions from PDCP PDU 2.
- PDCP PDUs 3, 5, 4, 7 and 8 are unnecessarily retransmitted by the UE.
- PDCP PDU2 may also be unnecessarily retransmitted depending on whether already some part of the PDCP PDU 2 was received in the eNB1 RLC.
- Case 3b eNB1 RLC re-establishment; Forwarding of out of sequence PDCP PDUs from eNB2 RLC; PDCP status report
- This case differs from Case 2a only in that the eNB1 RLC is re-established along with the corresponding UE RLC1 entity.
- PDCP PDUs 3 and 5 which were buffered in the eNB1 RLC, will be delivered to the eNB PDCP entity. Since PDCP PDUs 7 and 8 were also forwarded from the of the eNB2 RLC entity, and PDCP PDUs 1 and 4 were already delivered, the PDCP status report can indicated that PDCP PDU’s 1, 3, 4, 5, 7 and 8 do not need to be retransmitted. The corresponding retransmission situation is shown in Figure 15.
- PDCP PDU 2 With the current UE behaviour the UE will restart transmissions from PDCP PDU 2. Assuming that the PDCP status report is received in time, only the UE only retransmits PDCP PDUs 2 and 6. PDCP PDU2 may be unnecessarily retransmitted depending on whether already some part of the PDCP PDU 2 was received in the eNB1 RLC.
- the UE retransmission behaviour is changed relative to the current 3GPP specified behaviour.
- the UE In place of having the UE restart transmissions of all PDCP SDUs from the first PDCP SDU for which the successful delivery of the corresponding PDCP PDU has not been confirmed by lower layers, the UE:
- the UE only retransmits PDCP SDUs for which transmission of the corresponding PDCP PDU was attempted/ performed via the discontinued lower layer protocol stack part.
- PDCP PDUs 2, 3 and 5 Since the UE will not consider PDCP PDUs transmitted via eNB1 for retransmission, retransmission for PDCP PDUs 2, 3 and 5 will not be triggered. Assuming that PDCP PDU 4 transmission was confirmed by lower layers of UE RLC2, the UE will only start retransmission from PDCP PDU6 and retransmit PDUs 6, 7 and 8.
- Table 2 First comparison of embodiment of the invention to current UE behaviour.
- Case 4b no eNB1 RLC re-establishment; Forwarding of out of sequence PDCP PDUs from eNB2 RLC; PDCP status report
- PDCP PDUs 2, 3 and 5 Since the UE will not consider PDCP PDUs transmitted via eNB1 for retransmission, retransmission for PDCP PDUs 2, 3 and 5 will not be triggered. Since the PDCP status report confirms that PDCP PDUs 4, 7 and 8 no longer need to be retransmitted, in the end only PDCP PDU 6 will be retransmitted.
- Table 3 Second comparison of embodiment of the invention to current UE behaviour.
- the embodiments of the present invention described above in connection with Case 4a and Case 4b are not reliant upon processing a PDCP status report to determine which PDCP PDUs to retransmit.
- a PDCP status report based approach might result in the UE having started certain PDCP PDU transmissions before receiving the PDCP status report (a race condition). If the UE has already started to retransmit unnecessary PDCP PDUs when the PDCP status report is received then this can result in a loss of efficiency.
- FIG 18 shows an example full sequence message flow in accordance with certain embodiments of the present invention for deletion of the last cell in a Small Cell Group (SCG) resulting also in the reconfiguration a split bearer to a non-split bearer.
- Figure 18 shows messages transferred between the UE, the MeNB, the SeNB and the CN.
- At least one radio bearer serving the UE is split between the MeNB and the SeNB as described above in connection with Figure 3.
- the MeNB obtains measurement information from the UE and / or status information from the SeNB.
- the measurement information or status information may be the trigger that causes the MeNB to decide to release the last cell in the SCG. There may be other triggers. Alternatively, the trigger may be some other status report.
- the MeNB determines that release of the last cell in the SCG is required.
- the SeNB is instructed to release the last cell in the SCG at step 3 (the MeNB commands the SeNB to remove the SCG part of the bearer) and acknowledges this at step 4.
- the SeNB makes a new SeNB configuration to be sent to the UE and forwards this to the MeNB.
- the SeNB forwards out of sequence uplink PDCP PDUs (though it is noted that the present invention functions correctly as in Case 4a described above even if there is no forwarding).
- the SeNB forwards undelivered downlink PDCP PDUs to the MeNB.
- the PDUs are buffered by the MeNB at step 6.
- the MeNB instructs the UE to release the last cell in the SCG.
- the MeNB sends the new SeNB configuration to the UE.
- the UE begins to reorder received downlink PDCP PDUs.
- the UE determines which uplink PDCP PDUs to retransmit as described above in connection with Case 4a and Case 4b. That is, only PDCP PDUs transmitted to the discontinued eNB protocol stack (at the SeNB), and for which no lower layer acknowledgement of receipt has been received, will be retransmitted.
- the UE signals to the MeNB that the release of the last cell in the SCG is complete and at step 12a the UE sends a PDCP status report including a bitmap indicating received and missing downlink PDCP PDUs.
- the MeNB sends a PDCP status report indicating what retransmissions to make including a bitmap indicating received and missing uplink PDCP PDUs.
- this PDCP status report is partially ignored and does not trigger retransmission of PDCP PDUs transmitted directly to the MeNB.
- Steps 13, 14 and 15 relate to the release of radio resources by the SeNB.
- the MeNB informs the SeNB about the UE response
- the SeNB informs the MeNB that reconfiguration has been completed.
- the UE and the MeNB (which from now on may be simply referred to as the eNB) continue to operate in a “normal mode” in which a non-split bearer is used.
- the UE When upper layers request a PDCP re-establishment due to reconfiguration of the radio bearer from a split bearer to a non-split bearer handled by the PCG, the UE shall:
- the UE shall:
- PCG stands for “primary cell group” and corresponds to cells in the MeNB
- SCG stands for “secondary cell group” and corresponds to cells in the SeNB.
- consideration of how UE retransmission behaviour may be improved to increase efficiency is extended to considering a reconfiguration of an uplink non-split bearer to an uplink split bearer (the reverse situation to that described above).
- this shows a flow chart illustrating retransmission behaviour at the UE.
- the UE determines that reconfiguration of an uplink bearer termination is required. That is, the UE determines whether as a result of a re-establishment process retransmission of PDCP SDUs is required.
- a determination is made whether the reconfiguration is from a split bearer to a non-split bearer. If it is determined that the reconfiguration is from a split bearer to a non-split bearer then at step 183 a determination is made where the uplink configuration is to be located after the reconfiguration to a non-split bearer.
- step 183 may be viewed as determining for which eNB uplink PDU transmission is to be configured.
- step 183 may be viewed as determining whether PDCP PDU transmission is to be allowed only in in the Macro Cell Group (MCG) or only in the SCG.
- MCG Macro Cell Group
- step 183 If at step 183 it is determined that the PDCP entity will reside in the MeNB after reconfiguration then at step 184 the UE performs retransmission according to the embodiments of the present invention described above in connection with Case 4a and Case 4b. That is, only PDCP SDUs for which the corresponding PDCP PDUs were transmitted via the SeNB, and which have not been confirmed as delivered, are retransmitted.
- step 183 If at step 183 it is determined that the PDCP entity will reside in the SeNB then at step 185 the UE performs retransmission according to the existing 3GPP specified behaviour (all PDCP SDUs are retransmitted if there has been no acknowledgement of delivery via lower layers).
- step 182 it is determined that the reconfiguration is not from a split bearer to a non-split bearer then at step 186 a determination is made whether the reconfiguration is from a non-split bearer to a split bearer. If it is determined that the reconfiguration is not from a non-split bearer to a split bearer then the flow passes to step 185 and the UE performs retransmission according to the existing 3GPP specified behaviour.
- step 187 a determination is made where the uplink configuration was located before the reconfiguration to a split bearer. That is, it is determined where the PDCP entity was located at the network side before reconfiguration.
- step 187 may be viewed as determining for which eNB uplink PDU transmission was previously located configured.
- step 187 may be viewed as determining whether PDCP PDU transmission was previously only in in the Macro Cell Group (MCG) or only in the Small Cell Group (SCG).
- MCG Macro Cell Group
- SCG Small Cell Group
- step 187 it is determined that the PDCP entity previously resided in the SeNB then at step 185 the UE performs retransmission according to the existing 3GPP specified behaviour.
- step 187 it is determined that before reconfiguration the PDCP entity resided in the MeNB then at step 188 in accordance with certain embodiments of the invention no PDCP SDU retransmissions are required. This may include if the MeNB sends a PDCP status report indicating that certain corresponding PDCP PDUs have not been received.
- Figure 19 illustrates the behaviour of the UE when a reconfiguration of a radio bearer is commanded between first and second configurations.
- the first configuration is where a radio bearer is configured with two bi-directional RLC entities (at a MeNB and a SeNB, and also duplicated at the UE).
- the second configuration is where a radio bearer is configured with one bi-directional RLC entity (at an eNB, and also duplicated at the UE). While noting that bearers are bi-directional (and both “paths” are typically used in a split bearer for the downlink), for the uplink in a split bearer the UE could be restricted to only transmitting PDCP PDUs via a single “path” (to an RLC entity at only the MeNB or the SeNB).
- the UE checks if reconfiguration of a bearer is from configuration 1 (split) to configuration 2 (non-split). If so, the UE checks whether in configuration 1 PDCP PDU transmission was allowed only to the SeNB (or only on SCG serving cells) or only to the MeNB.
- PDCP PDU transmission was allowed only to the SeNB (only via SCG serving cells) then PDCP SDU retransmissions need to be performed in accordance with the current 3GPP standards, that is according to step 185. If, however, PDCP PDU transmission was allowed only to the MeNB then no retransmission is required, that is according to step 188. However, for simplicity, this UE behaviour is not included in Figure 19, and it is assumed in Figure 19 that when in the first configuration (split bearer) PDCP PDUs are transmitted via both paths.
- Certain embodiments of the present invention described above are based upon modifications only to the way in which the UE responds to a bearer reconfiguration, and in particular how the UE determines which PDCP SDUs to retransmit to maximise resource efficiency.
- two further options in accordance with further embodiments of the invention for increasing resource efficiency during reconfiguration from a split bearer to a non-split bearer are now presented.
- the eNB1 RLC entity may be re-established when removing the eNB2 protocol stack part and a PDCP status report may be sent from eNB1 to the UE. If the network re-establishes the eNB1 RLC entity when deleting the protocol stack part in eNB2, out of sequence PDCP PDUs will be delivered to the PDPC entity which will improve the contents of the PDCP status report (no longer asking retransmission of PDCP PDUs 3 and 5 unnecessarily in the example of Case 3b).
- the UE behaviour may be that currently specified in the 3GPP standards, with the improvements in resource efficiency arising through appropriate configuration of the eNB1 behaviour.
- partly received PDCP PDUs for instance PDCP PDU 2
- eNB1 the RLC entity in eNB1
- the eNB1 RLC entity informs the PDCP entity about the reception status or PDCP PDUs. Again, this results in a more accurate PDCP status report.
- the transmission of PDCP PDU 2 to the eNB1 will continue, and PDCP PDU 2 will be retransmitted.
- the second option requires modification to the 3GPP standards concerning the behaviour of the eNB RLC upon a change in a PDCP termination.
- embodiments of the present invention can be realized in the form of hardware, software or a combination of hardware and software. Any such software may be stored in the form of volatile or non-volatile storage, for example, a storage device like a ROM, whether erasable or rewritable or not, or in the form of memory, for example, RAM, memory chips, device or integrated circuits or on an optically or magnetically readable medium, for example, a CD, DVD, magnetic disk or magnetic tape or the like. It will be appreciated that the storage devices and storage media are embodiments of machine-readable storage that are suitable for storing a program or programs comprising instructions that, when executed, implement embodiments of the present invention.
- embodiments provide a program comprising code for implementing apparatus or a method as claimed in any one of the claims of this specification and a machine-readable storage storing such a program. Still further, such programs may be conveyed electronically via any medium including a communication signal carried over a wired or wireless connection and embodiments suitably encompass the same.
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Mobile Radio Communication Systems (AREA)
Abstract
A data transmission method of a User Equipment, UE, in a Long Term Evolution, LTE, compliant mobile communications network, and a corresponding UE. The method comprises detecting reconfiguration of a bearer from a split bearer in which uplink Packet Data Convergence Protocol, PDCP, Protocol Data Units, PDUs, are transmitted to both a Master eNB, MeNB, and to a Secondary eNB, SeNB, to a non-split bearer in which uplink PDCP PDUs are transmitted only to the MeNB. If reconfiguration of a bearer from a split bearer to a non-split bearer in which uplink PDCP PDUs are transmitted to the MeNB is detected, the method further comprises initiating retransmission of PDCP Service Data Units, SDUs, from the first PDCP SDU for which transmission of the corresponding PDCP PDU was attempted via the SeNB and for which there has been no confirmation of successful delivery by a protocol layer below the PDCP layer within the UE. The method further comprises retransmitting only PDCP SDUs for which transmission of the corresponding PDCP PDU was attempted via the SeNB.
Description
The present invention relates to bearer reconfiguration. In particular, certain embodiments of the present invention relate to reconfiguration of a split bearer to a non-split bearer, or vice versa, in a 3rd Generation Partnership Project (3GPP) Long Term Evolution (LTE) or LTE Advanced compliant mobile communications network comprising a mobile terminal (also referred to herein as the User Equipment, UE) and network equipment. The present invention relates to determining which Packet Data Convergence Protocol, PDCP, Service Data Units (SDUs) the UE should retransmit following bearer reconfiguration.
Wireless or mobile (cellular) communications networks in which a mobile terminal (UE, such as a mobile handset) communicates via a radio link to a network of base stations (eNBs) or other wireless access points connected to a telecommunications network, have undergone rapid development through a number of generations. The initial deployment of systems using analogue signalling has been superseded by Second Generation (2G) digital systems such as Global System for Mobile communications (GSM), which typically use a radio access technology known as GSM Enhanced Data rates for GSM Evolution Radio Access Network (GERAN), combined with an improved core network.
Second generation systems have themselves been largely replaced by or augmented by Third Generation (3G) digital systems such as the Universal Mobile Telecommunications System (UMTS), which uses a Universal Terrestrial Radio Access Network (UTRAN) radio access technology and a similar core network to GSM. UMTS is specified in standards produced by 3GPP. Third generation standards provide for a greater throughput of data than is provided by second generation systems. This trend is continued with the move towards Fourth Generation (4G) systems.
3GPP design, specify and standardise technologies for mobile wireless communications networks. Specifically, 3GPP produces a series of Technical Reports (TR) and Technical Specifications (TS) that define 3GPP technologies. The focus of 3GPP is currently the specification of standards beyond 3G, and in particular an Evolved Packet System (EPS) offering enhancements over 3G networks, including higher data rates. The set of specifications for the EPS comprises two work items: Systems Architecture Evolution (SAE, concerning the core network) and LTE concerning the air interface. The first set of EPS specifications were released as 3GPP Release 8 in December 2008. LTE uses an improved radio access technology known as Evolved UTRAN (E-UTRAN), which offers potentially greater capacity and additional features compared with previous standards. SAE provides an improved core network technology referred to as the Evolved Packet Core (EPC). Despite LTE strictly referring only to the air interface, LTE is commonly used to refer to the whole of the EPS, including by 3GPP themselves. LTE is used in this sense in the remainder of this specification, including when referring to LTE enhancements, such as LTE Advanced. LTE is an evolution of UMTS and shares certain high level components and protocols with UMTS. LTE Advanced offers still higher data rates compared to LTE and is defined by 3GPP standards releases from 3GPP Release 10 up to and including 3GPP Release 12. LTE Advanced is considered to be a 4G mobile communication system by the International Telecommunication Union (ITU).
The present invention is implemented within an LTE mobile network. Therefore, an overview of an LTE network is shown in Figure 1. The LTE system comprises three high level components: at least one UE 102, the E-UTRAN 104 and the EPC 106. The EPC 106 communicates with Packet Data Networks (PDNs) and servers 108 in the outside world. Figure 1 shows the key component parts of the EPC 106. It will be appreciated that Figure 1 is a simplification and a typical implementation of LTE will include further components. In Figure 1 interfaces between different parts of the LTE system are shown. The double ended arrow indicates the air interface between the UE 102 and the E-UTRAN 104. For the remaining interfaces user data is represented by solid lines and signalling is represented by dashed lines.
The E-UTRAN 104 comprises a single type of component: an eNB (E-UTRAN Node B) which is responsible for handling radio communications between the UE 102 and the EPC 106 across the air interface. An eNB controls UEs 102 in one or more cell. LTE is a cellular system in which the eNBs provide coverage over one or more cells. Typically there is a plurality of eNBs within an LTE system. In general, a UE in LTE communicates with one eNB through one cell at a time.
Key components of the EPC 106 are shown in Figure 1. It will be appreciated that in an LTE network there may be more than one of each component according to the number of UEs 102, the geographical area of the network and the volume of data to be transported across the network. Data traffic is passed between each eNB and a corresponding Serving Gateway (S-GW) 110 which routes data between the eNB and a PDN Gateway (P-GW) 112. The P-GW 112 is responsible for connecting a UE to one or more servers or PDNs 108 in the outside world. The Mobility Management Entity (MME) 114 controls the high-level operation of the UE 102 through signalling messages exchanged with the UE 102 through the E-UTRAN 104. Each UE is registered with a single MME. There is no direct signalling pathway between the MME 114 and the UE 102 (communication with the UE 102 being across the air interface via the E-UTRAN 104). Signalling messages between the MME 114 and the UE 102 comprise EPS Session Management (ESM) protocol messages controlling the flow of data from the UE to the outside world and EPS Mobility Management (EMM) protocol messages controlling the rerouting of signalling and data flows when the UE 102 moves between eNBs within the E-UTRAN. The MME 114 exchanges signalling traffic with the S-GW 110 to assist with routing data traffic. The MME 114 also communicates with a Home Subscriber Server (HSS) 116 which stores information about users registered with the network.
Within an LTE network, data is transferred between different components of the network using bearers. An EPS bearer serves to transfer data between a UE and a P-GW. The data flow is bi-directional. Data carried by an EPS bearer comprises one or more service data flows carrying data for a particular service, for instance streamed media. Each service data flow comprises one or more packet flows.
3GPP Radio Access Network (RAN) workgroups are current working on a Study Item (SI) called “Small Cell Enhancements”. The technical outcome of this SI is documented in 3GPP TR 36.842 “Evolved Universal Terrestrial Radio Access (E-UTRA)”; Study on Small Cell enhancements for E-UTRA and E-UTRAN ? Higher layer aspects (Release 12); v0.4.0. 3GPP TR 36.842 concerns the radio access aspects of the SI and impacts upon both the UE and the eNB. Small cell enhancements are applicable, for instance, where there is a macro cell and a small cell (within the coverage area of the macro cell) operating on the same carrier frequency.
It is currently proposed that the RAN will support so called “dual connectivity” functionality. Dual connectivity refers to an operation where a given UE consumes radio resources provided by at least two different network points (Master and Secondary eNBs) connected with non-ideal backhaul while the UE is active within the network (in an RRC_CONNECTED (Radio Resource Control Connected) state. Dual connectivity permits a greater data rate to be achieved between the UE and the RAN. To achieve dual connectivity, it is proposed that the RAN will support “bearer split” functionality. In dual connectivity, bearer split refers to the ability to split a bearer over multiple eNBs. A Master eNB (MeNB, usually the macro cell eNB) is the eNB which terminates at least S1-MME interface (the interface between the eNB and the MME) and therefore act as mobility anchor towards the Core Network (CN). A Secondary eNB (SeNB) is an eNB providing additional radio resources for the UE, which is not the MeNB.
Referring to Figure 2, this shows option 3 of Figure 8.1.1-1 of TS 36.842, which illustrates one bearer split option, taking the downlink direction as an example. It can be seen that there is a first EPS bearer (#1: solid arrows) communicating directly from a P-GW (not shown) via the S-GW and the MeNB to the UE. A second EPS bearer (#2: dashed arrows) passes from the MeNB to the UE via the SeNB as well as directly between the MeNB and the UE. The second EPS bearer is split across the RAN.
To achieve a split bearer it is necessary to modify the existing user plane architecture shown in Figure 6-1 of 3GPP TS 36.300 “Evolved Universal Terrestrial Radio Access (E-UTRA) and Evolved Universal Terrestrial Radio Access Network (E-UTRAN)"; Overall description; Stage 2 (Release 11); v11.7.0 (not reproduced in the present specification). At an eNB, for communicating with the UE across the air interface, the eNB comprises a protocol stack having a PDCP layer, a Radio Link Control (RLC) layer and a Medium Access Control (MAC) layer. Collectively, these protocol layers form the data link layer: layer two of the standard Open Systems Interconnection (OSI) model. The MAC layer carries out low-level control of the physical layer (layer 1 of the OSI model, and outside of the scope of the present specification), including scheduling data transmissions between the mobile and the base station. The RLC layer maintains the data link between the UE and the eNB, and handles the acknowledgement of receipt of data packets, when required. The PDCP layer carries out higher-level transport functions including header compression and security. At each layer of the protocol stack the protocol receives a data packet from the protocol above in the form of a Service Data Unit (SDU), processes the packets and adds a header to form a Protocol Data Unit (PDU). The PDU becomes the incoming SDU of the next layer down the stack.
In a bearer split architecture such as is shown in Figure 2 the layer 2 protocol stack at the eNB is split between the MeNB and the SeNB. Specifically, a split radio bearer uses two RLC entities as shown in Figure 3, which reproduces Figure 8.1.1.8-1 from 3GPP TR 36.842. Figure 3 shows a first non-split bearer protocol stack at the MeNB (solid boxes). Figure 3 shows data being received from the S-GW across the S1 interface. Figure 3 further shows a second split radio bearer (dashed boxes and dashed arrows). For the split bearer there is a single PDCP entity at the MeNB and duplicated RLC/MAC protocol stack entities for the split bearer in both the MeNB and the SeNB. Data is sent between the single PDCP entity in the MeNB and the RCL/MAC entities in the SeNB across the Xn interface (alternatively referred to as the X2 interface). Although not shown in Figure 3, at the UE side there would be corresponding MAC/RLC/PDCP entities, and specifically a single UE PDCP entity and duplicated UE MAC/RLC entities.
In certain scenarios, part or the whole of the radio bearer protocol stack may be moved from one termination point to another termination point, for instance from one eNB to another eNB. For non-split radio bearers this may be due to the UE roaming between cells controlled by separate eNBs. In this case some of the on-going transmissions in the discontinued user plane stack will be terminated before successful delivery of the corresponding PDCP SDUs has been ensured. To overcome the loss that would be the result of this termination, PDCP SDU retransmissions may be initiated after the radio bearer protocol stack move. So far, 3GPP RAN2 specifications have only specified how PDCP SDU retransmissions are handled for non-split bearers (that is, how PDCP SDU retransmissions are to be handled when the complete RAN protocol stack is moved). If it is required to reconfigure a split bearer as a non-split bearer, for instance due to the UE moving out of the coverage area of the small cell, while remaining in the coverage area of the macro cell, then this also requires at least the part of the radio bearer protocol stack within the SeNB to be moved. Applying the same retransmission techniques when reconfiguring a split bearer to a non-split bearer will lead to inefficient retransmission, as is described in greater detail below.
According to a first aspect of the present invention there is provided a data transmission method of a User Equipment, UE, in a Long Term Evolution, LTE, compliant mobile communications network, the method comprising: detecting reconfiguration of a bearer from a split bearer in which uplink Packet Data Convergence Protocol, PDCP, Protocol Data Units, PDUs, are transmitted to both a Master eNB, MeNB, and to a Secondary eNB, SeNB, to a non-split bearer in which uplink PDCP PDUs are transmitted only to the MeNB; and if reconfiguration of a bearer from a split bearer to a non-split bearer in which uplink PDCP PDUs are transmitted to the MeNB is detected: initiating retransmission of PDCP Service Data Units, SDUs, from the first PDCP SDU for which transmission of the corresponding PDCP PDU was attempted via the SeNB and for which there has been no confirmation of successful delivery by a protocol layer below the PDCP layer within the UE; and retransmitting only PDCP SDUs for which transmission of the corresponding PDCP PDU was attempted via the SeNB.
The retransmission of PDCP SDUs may be in ascending order of count values assigned to the PDCP SDUs prior to the reconfiguration of the bearer.
The method may further comprise: receiving a PDCP status report from the MeNB; and determining that PDCP SDUs that are indicated in the PDCP status report as received need not be retransmitted.
The UE may be configured to use only bearers for which successful delivery of PDCP PDUs is acknowledged by the eNB at a protocol layer below the PDCP layer.
The UE may be configured to use only bearers using Radio Link Control Acknowledged Mode, RLC-Acknowledged Mode.
Successful delivery of a PDCP PDU may be confirmed by the Radio Link Control, RLC, layer or the Medium Access Control, MAC, layer.
The method may further comprise: detecting reconfiguration of a bearer from a split bearer in which uplink Packet Data Convergence Protocol, PDCP, Protocol Data Units, PDUs, are transmitted to both a Master eNB, MeNB, and to a Secondary eNB, SeNB, to a non-split bearer in which uplink PDCP PDUs are transmitted to the SeNB; and if reconfiguration of a bearer from a split bearer to a non-split bearer in which uplink PDCP PDUs are transmitted only to the SeNB is detected: initiating retransmissoin of PDCP SDUs from the first PDCP SDU for which there is no confirmation of successful delivery of a corresponding PDCP PDU by a protocol layer below the PDCP layer within the UE; and retransmitting all PDCP SDUs from the first PDCP SDU.
The method may further comprise: detecting reconfiguration of a bearer from a non-split bearer to split bearer; and if reconfiguration of a bearer from a non-split bearer to a split bearer is detected: determining whether, before reconfiguration of the bearer from a split bearer to a non-split bearer, PDCP transmission were terminated within the MeNB or the SeNB; wherein if it is determined that PDCP transmissions were terminated within the MeNB then the method further comprises determining that no PDCP SDU retransmissions are required.
If it is determined that PDCP transmissions were terminated within the SeNB then the method further comprises: initiating retransmission of PDCP SDUs from the first PDCP SDU for which there is no confirmation of successful delivery of a corresponding PDCP PDU by a protocol layer below the PDCP layer within the UE; and retransmitting all PDCP SDUs from the first PDCP SDU.
The method may further comprise detecting reconfiguration of a bearer from a split bearer in which uplink PDCP PDUs are transmitted to only one of a MeNB and a SeNB to a non-split bearer in which uplink PDCP PDUs are transmitted to the MeNB; determining whether before reconfiguration PDCP PDU transmissions from the UE were restricted to transmissions to just the MeNB or just the SeNB; wherein if it is determined that PDCP PDU transmissions from the UE were restricted to transmissions to just the MeNB then the method further comprises determining that no PDCP SDU retransmissions are required; and wherein if it is determined that PDCP PDU transmissions from the UE were restricted to transmissions to just the SeNB then the method further comprises: initiating retransmission of PDCP SDUs from the first PDCP SDU for which there is no confirmation of successful delivery of a corresponding PDCP PDU by a protocol layer below the PDCP layer within the UE; and retransmitting all PDCP SDUs from the first PDCP SDU.
According to a second aspect of the present invention there is provided a User Equipment, UE, in a Long Term Evolution, LTE, compliant mobile communications network, wherein the UE is arranged to: detect reconfiguration of a bearer from a split bearer in which uplink Packet Data Convergence Protocol, PDCP, Protocol Data Units, PDUs, are transmitted to both a Master eNB, MeNB, and to a Secondary eNB, SeNB, to a non-split bearer in which uplink PDCP PDUs are transmitted only to the MeNB; if reconfiguration of a bearer from a split bearer to a non-split bearer in which uplink PDCP PDUs are transmitted to the MeNB is detected, initiate retransmission of PDCP Service Data Units, SDUs, from the first PDCP SDU for which transmission of the corresponding PDCP PDU was attempted via the SeNB and for which there has been no confirmation of successful delivery by a protocol layer below the PDCP layer within the UE; and retransmit only PDCP SDUs for which transmission of the corresponding PDCP PDU was attempted via the SeNB.
The UE may be further arranged to implement the above described method.
Another aspect of the invention provides a computer program comprising instructions arranged, when executed, to implement a method and/or apparatus in accordance with any one of the above-described aspects. A further aspect provides machine-readable storage storing such a program.
It is an aim of certain embodiments of the present invention to improve the efficiency of PDCP SDU retransmission when reconfiguring a split bearer as a non-split bearer. Certain embodiments relate specifically to retransmissions of PDCP SDUs from the UE to the network. Certain embodiments of the present invention are specifically concerned with the case that a split bearer is reconfigured to a non-split bearer while keeping the same PDCP entity in the network. In this case the part of the user plane stack in the SeNB is terminated and transmissions on-going in that part may be lost. Certain embodiments of the invention are concerned specifically with bearers configured for reliable transport, for instance using RLC-Acknowledged Mode. In RLC-Acknowledged Mode the transmitter sends PDUs and stores the PDUs in a retransmission buffer until an acknowledgement of receipt is received. The transmitter regularly polls the receiver to return a status PDU listing the received PDUs. The transmitter may then delete the received PDUs from the buffer and re-transmit the remaining PDUs.
Embodiments of the invention are further described hereinafter with reference to the accompanying drawings, in which:
Figure 1 schematically illustrates an overview of an LTE mobile communication network;
Figure 2 illustrates a split bearer;
Figure 3 illustrates a RAN protocol stack at a MeNB and a SeNB for the split bearer of Figure 2;
Figure 4 illustrates a message flow during an X2 handover of a non-split bearer between a source eNB and a target eNB;
Figure 5 illustrates the format of a PDCP status report;
Figure 6 illustrates the delivery situation for a non-split radio bearer immediately before an X2 handover from a source eNB to a target eNB;
Figure 7 illustrates PDCP SDU retransmissions for the delivery situation of Figure 6 upon the X2 handover, according to a first network option;
Figure 8 illustrates PDCP SDU retransmissions for the delivery situation of Figure 6 upon the X2 handover, according to a second network option;
Figure 9 illustrates the delivery situation for a split radio bearer immediately before reconfiguration to a non-split radio bearer;
Figures 10 to 15 illustrate PDCP SDU retransmissions for the delivery situation of Figure 9 following reconfiguration to a non-split bearer, according to a first to sixth options; Figure 16 illustrates PDCP SDU retransmissions for the delivery situation of Figure 9 following reconfiguration to a non-split bearer, according to a first embodiment of the present invention;
Figure 17 illustrates PDCP SDU retransmissions for the delivery situation of Figure 9 following reconfiguration to a non-split bearer, according to a second embodiment of the present invention;
Figure 18 illustrates a message flow during reconfiguration of a bearer according an embodiment of the invention; and
Figure 19 is a flowchart illustrating a method of reconfiguring a bearer according to an embodiment of the invention.
Embodiments of the invention will now be described in the context of an LTE compliant mobile wireless communications network operating in accordance with Release-11 and beyond of the 3GPP LTE standards. However, it will be understood that this is by way of example only and that other embodiments may involve other wireless networks, operating at least partially in compliance with other releases and other standards.
Referring to Figure 4, this shows the message sequence chart for an “X2 handover” from 3GPP TS 36.300 (Figure 10.1.2.1.1-1). Specifically, this shows an X2 handover of a UE in RRC_CONNECTED mode in which a non-split bearer is reconfigured such that it is terminated at a target eNB in place of a source eNB. At steps 1 to 3 the source eNB determines whether to handover. Steps 4 to 7 concern handover preparation during which the source eNB passes all necessary information to the target eNB for effecting the handover. Steps 8 to 11 comprise handover execution. Steps 12 to 18 comprise handover execution. A more detailed explanation of Figure 4 is provided in section 10.1.2.1.1 of 3GPP TS 36.300, but is not needed for explanation of the present invention.
In the context of the present invention a first key step is the “Data Forwarding” of user data from the source eNB to the target eNB after step 8 (during handover execution). Importantly, it is at the discretion of the source eNB whether or not uplink PDCP SDUs that are received out of sequence are forwarded to the target eNB. As a first option, the source eNB may discard all such out of sequence PDCP SDUs and rely on the UE retransmitting all PDCP SDU’s from the first non-delivered PDCP SDU to the target eNB. Alternatively, as a second option the source eNB may forward all such out of sequence PDCP SDUs and ask the UE to only retransmit the missing PDCP SDUs to the target eNB.
This behaviour is captured in 3GPP TS 36.300 section 10.1.2.3.1:
Then the source eNB shall either:
- discard the uplink PDCP SDUs received out of sequence if the source eNB has not accepted the request from the target eNB for uplink forwarding or if the target eNB has not requested uplink forwarding for the bearer during the Handover Preparation procedure,
- forward to the target eNB the uplink PDCP SDUs received out of sequence if the source eNB has accepted the request from the target eNB for uplink forwarding for the bearer during the Handover Preparation procedure.
As further set out in 3GPP TS 36.300 section 10.1.2.3.1, the source eNB is further responsible for forwarding unacknowledged downlink PDCP SDUs to the target eNB and forwarding successively received uplink PDCP SDUs to the S-GW though this is outside of the scope of the present specification.
This optional behaviour for handling out of sequence uplink PDCP SDUs has consequences for later steps in Figure 4. A second key step is the “packet data” delivery of user data between the UE and the target eNB after step 11. The UE retransmits all PDCP SDUs for which successful delivery of corresponding PDCP PDU has not been confirmed by lower layers as documented in 3GPP TS 36.323 “Evolved Universal Terrestrial Radio Access (E-UTRA)”; Packet Data Convergence Protocol (PDCP) specification (Release 11); v11.2.0 section 5.2.1.1:
- from the first PDCP SDU for which the successful delivery of the corresponding PDCP PDU has not been confirmed by lower layers, perform retransmission or transmission of all the PDCP SDUs already associated with PDCP SNs in ascending order of the COUNT values associated to the PDCP SDU prior to the PDCP re-establishment as specified below:
// partly omitted//
- submit the resulting PDCP Data PDU to lower layer.
If the source eNB is configured to the option of not forwarding out of sequence PDCP SDUs, then the retransmission by the UE of all PDCP SDUs from the first PDCP SDU for which there is not lower layer confirmation of successful delivery is fine and no further action is required.
If the source eNB is configured to forward out of sequence received PDCP SDUs to the target eNB, then the specifications allow the target eNB to inform the UE about the already received PDCP SDUs with a PDCP status report as described in 3GPP TS 36.323 section 6.2.6. Figure 4 does not show a PDCP status report message, though this would be provided after the data forwarding following step 8 and before the packet data transmission following step 11. Figure 5 reproduces Figure 6.2.6.1 of 3GPP TS 36.323 and shows the format of a PDCP Control PDU carrying one PDCP status report when a 12 bit sequence number length is used. The field FMS identifies the first missing PDCP serial number. If there are received out of sequence PDCP SDUs then the bitmap field indicates missing PDCP SDUs from the first missing PDCP SDU. The bitmap field is of length in bits equal to the number of PDCP sequence numbers from, but not including the first missing PDCP SDU and up to and including the last received out of sequence PDCP SDU, rounded to the next multiple of 8 bits. For each position in the bitmap a zero indicates a PDCP SDU sequence number which is not reported to have been received by the lower layers. A one in the bitmap indicates a received PDCP SDU.
If the UE receives a PDCP status report, the UE may omit retransmissions of any PDCP SDUs which have been received by the source eNB. This behaviour is documented in section 5.4 of 3GPP TS 36.323:
When the discardTimer expires for a PDCP SDU, or the successful delivery of a PDCP SDU is confirmed by PDCP status report, the UE shall discard the PDCP SDU along with the corresponding PDCP PDU. If the corresponding PDCP PDU has already been submitted to lower layers the discard is indicated to lower layers.
The currently specified solution works fine for an X2 handover when moving a non-split bearer. To illustrate the conventional retransmission of PDCP SDUs from a UE to a target eNB during such a handover, both with and without forwarding by the source PDCP, reference is now made to Figures 6 to 8.
Figure 6 shows a possible delivery situation for a non-split radio bearer just before an X2 handover. Figure 6 shows PDCP and RLC entities at both a UE and a source eNB (MAC entities are omitted for clarity). This split between the network and the UE is shown. The UE PDCP entity shows six PDCP PDUs for transmission to the source eNB PDCP entities. In this example, PDCP PDU 1 is the last PDCP PDU delivered in sequence to the eNB PDCP entity. PDCP PDUs 2 and 4 failed at during their first transmission at lower layers and will have to be retransmitted by the UE RLC entity. This is indicated by the arrows from those PDUs not reaching across the network line to the source eNB RLC entity. PDUs 3 and 5 have been delivered to the RLC entity at the eNB, but since the RLC entity only delivers PDCP PDU’s in sequence to PDCP, these PDCP PDU’s are still buffered at the source eNB RLC entity. Receipt of the PDUs 3 and 5 will have been acknowledged by the source eNB RLC entity to the UE RLC entity.
Figure 7 shows what happens after X2 handover to a target eNB if the network implements the first option in which the source eNB discards out of sequence SDUs. At handover the source eNB RLC entity delivers out of sequence delivered PDCP PDUs (PDUs 3 and 5) to the PDCP entity due to a re-establishment of the RLC entity in the source eNB. However, the source PDCP entity will discard these PDUs, indicated by PDUs 3 and 5 being crossed out. During handover completion the UE retransmits all PDUs from the first non-delivery-confirmed PDCP PDU (PDCP PDU 2 in this example). Consequently, the UE must retransmit PDCP PDUs 2 to 6 (indicated by the arrows between the UE PDCP entity and the target eNB PDCP entity), even though PDUs 3 and 5 were successfully delivered to the network.
Figure 8 shows what happens after X2 handover to a target eNB if the network implements the second option in which the source eNB forwards out of sequence SDUs. Again PDCP PDUs 3 and 5 are delivered to the source eNB PDCP entity due to a re-establishment of the RLC entity in the source eNB. However, this time PDCP PDUs 3 and 5 are forwarded to the target eNB PDCP entity. Based on a PDCP status report as described above in connection with Figure 5, the UE knows that these PDCP PDUs do not have to be transmitted in the target eNB, thus saving resources in the UE and the target eNB. Consequently, the UE need only retransmit PDCP PDUs 2, 4 and 6 (indicated by the arrows between the UE PDCP entity and the target eNB PDCP entity).
To implement similar functionality during reconfiguration of a split bearer, the same techniques described above for an X2 handover of a non-split bearer may be reapplied. However, as will now be demonstrated, the result is a significant reduction in efficiency caused by retransmission of data unnecessarily. The following cases relate to the reconfiguration of a split bearer to a non-split bearer in which the PDCP entity within a MeNB remains following the reconfiguration and the RLC/MAC entities within a SeNB are removed.
Before illustrating specific examples, it is first clarified that it is assumed that also for a split bearer, RLC entities will in normal situations (other than for re-establishment) only deliver in sequence PDCP PDUs to the PDCP entity. However, since each RLC entity is only handling part of the PDCP PDUs, they do not necessarily need to be consecutive PDCP PDUs such that there could be gaps in the PDCP PDUs delivered by each RLC entity to a PDCP entity for a split bearer. At the RLC layer, in RLC Acknowledged Mode, for the uplink in the UE each RLC entity (one each for transmissions to eNB1 and eNB2) each PDCP PDU allocated for transmission to that eNB is numbered sequentially to form RLC PDUs, such that while there may be gaps in the numbering of PDCP PDUs sent to each eNB, there are no gaps for the RLC PDUs. At each eNB the RLC entity does not pass received RLC PDUs to the PDCP entity out of sequence.
Figure 9 shows a possible delivery situation for a split radio bearer just before reconfiguration from a split bearer to a non-split bearer. PDCP PDU 1 is the last in sequence PDCP PDU delivered via eNB1 RLC (the MeNB RLC entity) to the PDCP entity. PDCP PDU 4 is the last in PDCP PDU delivered via eNB2 RLC (the SeNB RLC entity). The UE is aware that PDCP PDUs 1 and 4 have successfully transmitted based on lower layer confirmation. Transmission was also successful for PDCP PDUs 3, 5, 7 and 8 to the eNB RLC entities but all these PDUs remain buffered in the receiving RLC entity due to out of sequence reception (that is, the received RLC PDUs are out of sequence). PDCP PDUs 2 and 6 still need to be retransmitted by the UE though these have not necessarily failed transmissions. Since transmissions in eNB2 are discontinued, PDCP PDU6 cannot be received by the network PDCP entity unless there is a new retransmission from the UE. PDCP PDU2 will be delivered by the RLC/lower layers in eNB1 if these layers are not re-established.
The amount of unnecessary retransmissions resulting from the current UE behaviour will depend on the network behaviour, as will now be set out via several example cases. The description of the following cases is not exhaustive of all possible scenarios for current UE behaviour and current network behaviour. The following example cases vary according to whether the eNB1 RLC is re-established, whether there is forwarding from the enB1 (SeNB) to the eNB2 (MeNB) and whether the PDCP entity sends a PDCP status report. If the eNB1 RLC is not re-established then on-going transmissions ( PDUs 2, 3 and 5) will continue and eventually these PDCP PDUs will be delivered to the PDCP entity (unless of course they later fail and no acknowledgement of receipt is received by the UE before the normal acknowledgement timer expires, in which case they would be retransmitted conventionally).
Case 1a: No eNB1 RLC re-establishment; No forwarding of out of sequence PDCP PDUs from eNB2 RLC; No PDCP status report
The resulting UE retransmissions following reconfiguration from a split bearer to a non-split bearer are shown in Figure 10.
With the current UE behaviour the UE will restart transmissions from PDCP PDU 2 (the first PDCP PDU for which there is no confirmation of receipt by the lower level layers). PDCP PDUs 2, 3, 4 and 5 are unnecessarily retransmitted by the UE, and retransmission of PDCP SDU’s 7 and 8 could have been avoided if eNB2 had forwarded out of sequence received PDUs.
Case 1b: No eNB1 RLC re-establishment; No forwarding of out of sequence PDCP PDUs from eNB2 RLC; PDCP status report
This case differs from Case 1a only in the fact that the PDCP entity sends a PDCP status report during bearer reconfiguration. The resulting UE retransmissions following reconfiguration from a split bearer to a non-split bearer are shown in Figure 11. It is clear that in this case the PDCP status report will indicate that PDCP PDUs 1 and 4 do not need to be retransmitted. It is questionable what the PDCP status report would say for PDCP PDUs 2, 3 and 5. Since these PDCP PDUs are not received by the PDCP entity, it is probable that the only thing the PDCP entity can say is that these PDCP PDUs need to be retransmitted.
With the current UE behaviour the UE will restart transmissions from PDCP PDU 2 and only skip PDCP PDU 4. PDCP PDUs 2, 3 and 5 are unnecessarily retransmitted by the UE, and retransmission of PDCP SDU’s 7 and 8 could have been avoided if eNB2 had forwarded out of sequence received PDUs.
Case 2a: No eNB1 RLC re-establishment; Forwarding of out of sequence PDCP PDUs from eNB2 RLC; No PDCP status report
This case differs from Case 1a only in that there is forwarding from eNB2 RLC. The resulting UE retransmissions following reconfiguration from a split bearer to a non-split bearer are shown in Figure 12.
With the current UE behaviour the UE will restart transmissions from PDCP PDU 2. PDCP PDUs 2, 3, 4, 5, 7 and 8 are unnecessarily retransmitted by the UE.
Case 2b: No eNB1 RLC re-establishment; Forwarding of out of sequence PDCP PDUs from eNB2 RLC; PDCP status report
This case differs from Case 1b only in that there is forwarding from eNB2 RLC. As for Case 1b, it is probable that the PDCP status report will not indicate that PDCP PDUs 2, 3 and 5 have been received. However, differing from Case 1b, the PDCP status report will indicate that PDCP PDUs 7 and 8 (in addition to PDCP PDUs 1 and 4) do not need to be retransmitted.
The resulting UE retransmissions following reconfiguration from a split bearer to a non-split bearer are shown in Figure 13.
With the current UE behaviour the UE will restart transmissions from PDCP PDU 2 and only skip PDCP PDUs 4, 7 and 8. PDCP PDUs 2, 3 and 5 are unnecessarily retransmitted by the UE.
Case 3a: eNB1 RLC re-establishment; Forwarding of out of sequence PDCP PDUs from eNB2 RLC; No PDCP status report
This case differs from Case 2a only in that the eNB1 RLC is re-established along with the corresponding UE RLC1 entity.
The resulting UE retransmissions following reconfiguration from a split bearer to a non-split bearer are shown in Figure 14.
With the UE current behaviour the UE will restart transmissions from PDCP PDU 2. PDCP PDUs 3, 5, 4, 7 and 8 are unnecessarily retransmitted by the UE. PDCP PDU2 may also be unnecessarily retransmitted depending on whether already some part of the PDCP PDU 2 was received in the eNB1 RLC.
Case 3b: eNB1 RLC re-establishment; Forwarding of out of sequence PDCP PDUs from eNB2 RLC; PDCP status report
This case differs from Case 2a only in that the eNB1 RLC is re-established along with the corresponding UE RLC1 entity.
Due to the re-establishment of the eNB1 RLC entity, in this case PDCP PDUs 3 and 5, which were buffered in the eNB1 RLC, will be delivered to the eNB PDCP entity. Since PDCP PDUs 7 and 8 were also forwarded from the of the eNB2 RLC entity, and PDCP PDUs 1 and 4 were already delivered, the PDCP status report can indicated that PDCP PDU’s 1, 3, 4, 5, 7 and 8 do not need to be retransmitted. The corresponding retransmission situation is shown in Figure 15.
With the current UE behaviour the UE will restart transmissions from PDCP PDU 2. Assuming that the PDCP status report is received in time, only the UE only retransmits PDCP PDUs 2 and 6. PDCP PDU2 may be unnecessarily retransmitted depending on whether already some part of the PDCP PDU 2 was received in the eNB1 RLC.
The unnecessary retransmission of PDCP PDUs for the above cases 1a to 3b is shown in Table 1 below:
Table 1
eNB RLC1 re-establish | Forwarding from eNB2 | PDCP status report | Unnecessarily | Comment | ||||||
2 | 3/5 | 4 | 6 | 7/8 | ||||||
1a | No | No (A) | No | x | x | x | x | |||
1b | No | No (A) | Yes | x | x | x | ||||
2a | No | Yes (B) | No | x | x | x | x | |||
2b | No | Yes (B) | Yes | x | x | |||||
3a | Yes | Yes (B) | No | x | x | x | x | PDCP PDU2 possibly unnecessarily retransmitted | ||
3b | Yes | Yes (B) | Yes | x | PDCP PDU2 possibly unnecessarily retransmitted |
Table 1: Unnecessary retransmissions with currently specified UE behaviour.
As we can see from Table 1, although usage of a PDCP status report improves the situation, especially if combined with forwarding between eNB2 and eNB1 and re-establishing eNB1 RLC, in none of the cases are all unnecessary retransmissions are avoided. That is, according to currently specified UE and network behaviour, it is not possible to fully eliminate all possible inefficient use of UE and eNB resources.
In accordance with certain embodiments of the present invention, in the event of reconfiguring a split bearer to a non-split bearer, the UE retransmission behaviour is changed relative to the current 3GPP specified behaviour. In place of having the UE restart transmissions of all PDCP SDUs from the first PDCP SDU for which the successful delivery of the corresponding PDCP PDU has not been confirmed by lower layers, the UE:
1) Restarts transmissions for PDCP SDUs from the first PDCP SDU for which transmission was attempted via the discontinued lower layer protocol stack part (at the SeNB) and for which the successful delivery of the corresponding PDCP PDU has not been confirmed by lower layers.
2) Furthermore, the UE only retransmits PDCP SDUs for which transmission of the corresponding PDCP PDU was attempted/ performed via the discontinued lower layer protocol stack part.
That is, in accordance with certain embodiments of the present invention, there is no retransmission of PDCP SDUs for which a PDCP PDU has already been provided to the lower layer protocol stack part that is not discontinued (at the MeNB).
As a consequence, in accordance with certain embodiments of the present invention, even if the UE receives a PDCP status report in this case indicating that certain PDCP PDUs are missing, this does not trigger retransmissions of PDCP PDUs already sent via the MeNB. Should those PDCP PDUs truly be missing then normal retransmission is initiated following expiry of a retransmission timer.
To illustrate this embodiment of the present invention, two further example cases are highlighted based upon the same delivery situation for a split radio bearer just before reconfiguration from a split bearer to a non-split bearer shown in Figure 9.
Case 4a: no eNB1 RLC re-establishment; No forwarding of out of sequence PDCP PDUs from eNB2 RLC; No PDCP status report
The resulting UE retransmissions situation is shown in Figure 16.
Since the UE will not consider PDCP PDUs transmitted via eNB1 for retransmission, retransmission for PDCP PDUs 2, 3 and 5 will not be triggered. Assuming that PDCP PDU 4 transmission was confirmed by lower layers of UE RLC2, the UE will only start retransmission from PDCP PDU6 and retransmit PDUs 6, 7 and 8.
If we compare this solution with Case 1a (as shown in Table 2 below), it can be seen that there is a clear reduction in the number of retransmitted PDCP PDUs.
Table 2
eNB RLC1 re-establish | Forwarding from eNB2 | PDCP status report | Unnecessarily | Comment | ||||||
2 | 3/5 | 4 | 6 | 7/8 | ||||||
1a | No | No (A) | No | x | x | x | x | |||
4a | No | No (A) | No | x |
Table 2: First comparison of embodiment of the invention to current UE behaviour.
Case 4b: no eNB1 RLC re-establishment; Forwarding of out of sequence PDCP PDUs from eNB2 RLC; PDCP status report
The resulting UE retransmissions situation is shown in Figure 17.
Since the UE will not consider PDCP PDUs transmitted via eNB1 for retransmission, retransmission for PDCP PDUs 2, 3 and 5 will not be triggered. Since the PDCP status report confirms that PDCP PDUs 4, 7 and 8 no longer need to be retransmitted, in the end only PDCP PDU 6 will be retransmitted.
If we compare this solution with Case 2b (as shown in Table 3 below), it can be seen that again there is a clear reduction in the number of retransmitted PDCP PDUs.
Table 3
eNB RLC1 re-establish | Forwarding from eNB2 | PDCP status report | Unnecessarily | Comment | ||||||
2 | 3/5 | 4 | 6 | 7/8 | ||||||
2b | No | Yes (B) | Yes | x | x | |||||
4b | No | Yes (B) | Yes |
Table 3: Second comparison of embodiment of the invention to current UE behaviour.
Advantageously, the embodiments of the present invention described above in connection with Case 4a and Case 4b are not reliant upon processing a PDCP status report to determine which PDCP PDUs to retransmit. A PDCP status report based approach might result in the UE having started certain PDCP PDU transmissions before receiving the PDCP status report (a race condition). If the UE has already started to retransmit unnecessary PDCP PDUs when the PDCP status report is received then this can result in a loss of efficiency.
Referring now to Figure 18, this shows an example full sequence message flow in accordance with certain embodiments of the present invention for deletion of the last cell in a Small Cell Group (SCG) resulting also in the reconfiguration a split bearer to a non-split bearer. Figure 18 shows messages transferred between the UE, the MeNB, the SeNB and the CN. Prior to release of the last cell in the SCG, at least one radio bearer serving the UE is split between the MeNB and the SeNB as described above in connection with Figure 3.
At step 1 the MeNB obtains measurement information from the UE and / or status information from the SeNB. The measurement information or status information may be the trigger that causes the MeNB to decide to release the last cell in the SCG. There may be other triggers. Alternatively, the trigger may be some other status report. At step 2 the MeNB determines that release of the last cell in the SCG is required. The SeNB is instructed to release the last cell in the SCG at step 3 (the MeNB commands the SeNB to remove the SCG part of the bearer) and acknowledges this at step 4. Specifically, at step 4 the SeNB makes a new SeNB configuration to be sent to the UE and forwards this to the MeNB. At step 5a the SeNB forwards out of sequence uplink PDCP PDUs (though it is noted that the present invention functions correctly as in Case 4a described above even if there is no forwarding). At step 5b the SeNB forwards undelivered downlink PDCP PDUs to the MeNB. The PDUs are buffered by the MeNB at step 6.
At step 7 the MeNB instructs the UE to release the last cell in the SCG. At step 7 the MeNB sends the new SeNB configuration to the UE. At step 8 the UE begins to reorder received downlink PDCP PDUs. At step 9, in accordance with certain embodiments of the present invention the UE determines which uplink PDCP PDUs to retransmit as described above in connection with Case 4a and Case 4b. That is, only PDCP PDUs transmitted to the discontinued eNB protocol stack (at the SeNB), and for which no lower layer acknowledgement of receipt has been received, will be retransmitted.
At step 10 the UE signals to the MeNB that the release of the last cell in the SCG is complete and at step 12a the UE sends a PDCP status report including a bitmap indicating received and missing downlink PDCP PDUs. At step 12b, in accordance with the 3GPP specifications, the MeNB sends a PDCP status report indicating what retransmissions to make including a bitmap indicating received and missing uplink PDCP PDUs. However, in accordance with certain embodiments of the present invention, this PDCP status report is partially ignored and does not trigger retransmission of PDCP PDUs transmitted directly to the MeNB.
The modified retransmission behaviour of the UE described above in connection with certain embodiments of the invention could be captured within a modification to the relevant 3GPP specification (3GPP TS 36.323) as follows, with changes indicated by underlining.
5.2.1.1 Procedures for DRBs mapped on RLC AM
When upper layers request a PDCP re-establishment due to reconfiguration of the radio bearer from a split bearer to a non-split bearer handled by the PCG, the UE shall:
- from the first PDCP SDU transmitted via the SCG for which the successful delivery of the corresponding PDCP PDU has not been confirmed by lower layers, perform retransmission of all PDCP SDUs for which initial transmission was performed via the SCG, in ascending order of the COUNT values associated to the PDCP SDU prior to the PDCP re-establishment as specified below:
- perform header compression of the PDCP SDU (if configured) as specified in the subclause 5.5.4;
- if connected as an RN, perform integrity protection (if configured) of the PDCP SDU using the COUNT value associated with this PDCP SDU as specified in the subclause 5.7;
- perform ciphering of the PDCP SDU using the COUNT value associated with this PDCP SDU as specified in the subclause 5.6;
- submit the resulting PDCP Data PDU to lower layer.
When upper layers request a PDCP re-establishment for other reasons, the UE shall:
- reset the header compression protocol for uplink and start with an IR state in U-mode (if configured) [9] [11];
- if connected as an RN, apply the integrity protection algorithm and key provided by upper layers (if configured) during the re-establishment procedure;
- apply the ciphering algorithm and key provided by upper layers during the re-establishment procedure;
- from the first PDCP SDU for which the successful delivery of the corresponding PDCP PDU has not been confirmed by lower layers, perform retransmission or transmission of all the PDCP SDUs already associated with PDCP SNs in ascending order of the COUNT values associated to the PDCP SDU prior to the PDCP re-establishment as specified below:
- perform header compression of the PDCP SDU (if configured) as specified in the subclause 5.5.4;
- if connected as an RN, perform integrity protection (if configured) of the PDCP SDU using the COUNT value associated with this PDCP SDU as specified in the subclause 5.7;
- perform ciphering of the PDCP SDU using the COUNT value associated with this PDCP SDU as specified in the subclause 5.6;
- submit the resulting PDCP Data PDU to lower layer.
It is noted that in this revised section of 3GPP TS 36.323 references to header compression, integrity protection and ciphering are unchanged from the case for PDCP re-establishment for other reasons, except that the header compression entity might not need to be reset. PCG stands for “primary cell group” and corresponds to cells in the MeNB, and SCG stands for “secondary cell group” and corresponds to cells in the SeNB.
In accordance with certain embodiments of the invention consideration of how UE retransmission behaviour may be improved to increase efficiency is extended to considering a reconfiguration of an uplink non-split bearer to an uplink split bearer (the reverse situation to that described above).
Referring now Figure 19, this shows a flow chart illustrating retransmission behaviour at the UE. At step 181 the UE determines that reconfiguration of an uplink bearer termination is required. That is, the UE determines whether as a result of a re-establishment process retransmission of PDCP SDUs is required. At step 182 a determination is made whether the reconfiguration is from a split bearer to a non-split bearer. If it is determined that the reconfiguration is from a split bearer to a non-split bearer then at step 183 a determination is made where the uplink configuration is to be located after the reconfiguration to a non-split bearer. That is, it is determined where the PDCP entity is to be located at the network side after reconfiguration. Alternatively, step 183 may be viewed as determining for which eNB uplink PDU transmission is to be configured. As a further alternative, step 183 may be viewed as determining whether PDCP PDU transmission is to be allowed only in in the Macro Cell Group (MCG) or only in the SCG.
If at step 183 it is determined that the PDCP entity will reside in the MeNB after reconfiguration then at step 184 the UE performs retransmission according to the embodiments of the present invention described above in connection with Case 4a and Case 4b. That is, only PDCP SDUs for which the corresponding PDCP PDUs were transmitted via the SeNB, and which have not been confirmed as delivered, are retransmitted.
If at step 183 it is determined that the PDCP entity will reside in the SeNB then at step 185 the UE performs retransmission according to the existing 3GPP specified behaviour (all PDCP SDUs are retransmitted if there has been no acknowledgement of delivery via lower layers).
Alternatively, if at step 182 it is determined that the reconfiguration is not from a split bearer to a non-split bearer then at step 186 a determination is made whether the reconfiguration is from a non-split bearer to a split bearer. If it is determined that the reconfiguration is not from a non-split bearer to a split bearer then the flow passes to step 185 and the UE performs retransmission according to the existing 3GPP specified behaviour.
If at step 186 it is determined that the reconfiguration is from a non-split bearer to a split bearer then at step 187 a determination is made where the uplink configuration was located before the reconfiguration to a split bearer. That is, it is determined where the PDCP entity was located at the network side before reconfiguration. Alternatively, step 187 may be viewed as determining for which eNB uplink PDU transmission was previously located configured. As a further alternative, step 187 may be viewed as determining whether PDCP PDU transmission was previously only in in the Macro Cell Group (MCG) or only in the Small Cell Group (SCG).
If at step 187 it is determined that the PDCP entity previously resided in the SeNB then at step 185 the UE performs retransmission according to the existing 3GPP specified behaviour. Alternatively, if at step 187 it is determined that before reconfiguration the PDCP entity resided in the MeNB then at step 188 in accordance with certain embodiments of the invention no PDCP SDU retransmissions are required. This may include if the MeNB sends a PDCP status report indicating that certain corresponding PDCP PDUs have not been received.
Figure 19 illustrates the behaviour of the UE when a reconfiguration of a radio bearer is commanded between first and second configurations. The first configuration is where a radio bearer is configured with two bi-directional RLC entities (at a MeNB and a SeNB, and also duplicated at the UE). The second configuration is where a radio bearer is configured with one bi-directional RLC entity (at an eNB, and also duplicated at the UE). While noting that bearers are bi-directional (and both “paths” are typically used in a split bearer for the downlink), for the uplink in a split bearer the UE could be restricted to only transmitting PDCP PDUs via a single “path” (to an RLC entity at only the MeNB or the SeNB). In such a situation then if PDCP PDUs have been transmitted only to the MeNB, upon reconfiguring the bearer from the first configuration to the second configuration then in accordance with certain embodiments of the present invention no PDCP retransmissions may be required. Specifically, when bearer reconfiguration is commanded, the UE checks if reconfiguration of a bearer is from configuration 1 (split) to configuration 2 (non-split). If so, the UE checks whether in configuration 1 PDCP PDU transmission was allowed only to the SeNB (or only on SCG serving cells) or only to the MeNB. If PDCP PDU transmission was allowed only to the SeNB (only via SCG serving cells) then PDCP SDU retransmissions need to be performed in accordance with the current 3GPP standards, that is according to step 185. If, however, PDCP PDU transmission was allowed only to the MeNB then no retransmission is required, that is according to step 188. However, for simplicity, this UE behaviour is not included in Figure 19, and it is assumed in Figure 19 that when in the first configuration (split bearer) PDCP PDUs are transmitted via both paths.
Certain embodiments of the present invention described above are based upon modifications only to the way in which the UE responds to a bearer reconfiguration, and in particular how the UE determines which PDCP SDUs to retransmit to maximise resource efficiency. However, two further options in accordance with further embodiments of the invention for increasing resource efficiency during reconfiguration from a split bearer to a non-split bearer are now presented.
As a first option, and as described above in connection with Case 3b, the eNB1 RLC entity may be re-established when removing the eNB2 protocol stack part and a PDCP status report may be sent from eNB1 to the UE. If the network re-establishes the eNB1 RLC entity when deleting the protocol stack part in eNB2, out of sequence PDCP PDUs will be delivered to the PDPC entity which will improve the contents of the PDCP status report (no longer asking retransmission of PDCP PDUs 3 and 5 unnecessarily in the example of Case 3b). The UE behaviour may be that currently specified in the 3GPP standards, with the improvements in resource efficiency arising through appropriate configuration of the eNB1 behaviour. As discussed above in connection with Case 3b, partly received PDCP PDUs (for instance PDCP PDU 2) will be dropped by the RLC entity in eNB1, which may cause them to be at least partly unnecessarily retransmitted.
As a second option, rather than re-establishing the RLC entity in eNB1, the eNB1 RLC entity informs the PDCP entity about the reception status or PDCP PDUs. Again, this results in a more accurate PDCP status report. In accordance with the second option the transmission of PDCP PDU 2 to the eNB1 will continue, and PDCP PDU 2 will be retransmitted. It is noted that the second option requires modification to the 3GPP standards concerning the behaviour of the eNB RLC upon a change in a PDCP termination.
It will be appreciated that embodiments of the present invention can be realized in the form of hardware, software or a combination of hardware and software. Any such software may be stored in the form of volatile or non-volatile storage, for example, a storage device like a ROM, whether erasable or rewritable or not, or in the form of memory, for example, RAM, memory chips, device or integrated circuits or on an optically or magnetically readable medium, for example, a CD, DVD, magnetic disk or magnetic tape or the like. It will be appreciated that the storage devices and storage media are embodiments of machine-readable storage that are suitable for storing a program or programs comprising instructions that, when executed, implement embodiments of the present invention. Accordingly, embodiments provide a program comprising code for implementing apparatus or a method as claimed in any one of the claims of this specification and a machine-readable storage storing such a program. Still further, such programs may be conveyed electronically via any medium including a communication signal carried over a wired or wireless connection and embodiments suitably encompass the same.
Throughout the description and claims of this specification, the words “comprise” and “contain” and variations of them mean “including but not limited to”, and they are not intended to (and do not) exclude other components, integers or steps. Throughout the description and claims of this specification, the singular encompasses the plural unless the context otherwise requires. In particular, where the indefinite article is used, the specification is to be understood as contemplating plurality as well as singularity, unless the context requires otherwise.
Features, integers or characteristics described in conjunction with a particular aspect, embodiment or example of the invention are to be understood to be applicable to any other aspect, embodiment or example described herein unless incompatible therewith. All of the features disclosed in this specification (including any accompanying claims, abstract and drawings), and/or all of the steps of any method or process so disclosed, may be combined in any combination, except combinations where at least some of such features and/or steps are mutually exclusive. The invention is not restricted to the details of any foregoing embodiments. The invention extends to any novel one, or any novel combination, of the features disclosed in this specification (including any accompanying claims, abstract and drawings), or to any novel one, or any novel combination, of the steps of any method or process so disclosed. It will be also be appreciated that, throughout the description and claims of this specification, language in the general form of “X for Y” (where Y is some action, activity or step and X is some means for carrying out that action, activity or step) encompasses means X adapted or arranged specifically, but not exclusively, to do Y.
The reader's attention is directed to all papers and documents which are filed concurrently with or previous to this specification in connection with this application and which are open to public inspection with this specification, and the contents of all such papers and documents are incorporated herein by reference...
The above embodiments are to be understood as illustrative examples of the invention. Further embodiments of the invention are envisaged. It is to be understood that any feature described in relation to any one embodiment may be used alone, or in combination with other features described, and may also be used in combination with one or more features of any other of the embodiments, or any combination of any other of the embodiments. Furthermore, equivalents and modifications not described above may also be employed without departing from the scope of the invention, which is defined in the accompanying claims.
Claims (12)
- A data transmission method of a User Equipment, UE, in a Long Term Evolution, LTE, compliant mobile communications network, the method comprising:detecting reconfiguration of a bearer from a split bearer in which uplink Packet Data Convergence Protocol, PDCP, Protocol Data Units, PDUs, are transmitted to both a Master eNB, MeNB, and to a Secondary eNB, SeNB, to a non-split bearer in which uplink PDCP PDUs are transmitted only to the MeNB; andif reconfiguration of a bearer from a split bearer to a non-split bearer in which uplink PDCP PDUs are transmitted to the MeNB is detected:initiating retransmission of PDCP Service Data Units, SDUs, from the first PDCP SDU for which transmission of the corresponding PDCP PDU was attempted via the SeNB and for which there has been no confirmation of successful delivery by a protocol layer below the PDCP layer within the UE; andretransmitting only PDCP SDUs for which transmission of the corresponding PDCP PDU was attempted via the SeNB.
- The method of claim 1, wherein the retransmission of PDCP SDUs is in ascending order of count values assigned to the PDCP SDUs prior to the reconfiguration of the bearer.
- The method of claim 1 or claim 2, further comprising:receiving a PDCP status report from the MeNB; anddetermining that PDCP SDUs that are indicated in the PDCP status report as received need not be retransmitted.
- The method of any one of the preceding claims, wherein the UE is configured to use only bearers for which successful delivery of PDCP PDUs is acknowledged by the eNB at a protocol layer below the PDCP layer.
- The method of claim 4, wherein the UE is configured to use only bearers using Radio Link Control Acknowledged Mode, RLC-Acknowledged Mode.
- The method of any one of the preceding claims, wherein successful delivery of a PDCP PDU is confirmed by the Radio Link Control, RLC, layer or the Medium Access Control, MAC, layer.
- The method of any one of the preceding claims, further comprising:detecting reconfiguration of a bearer from a split bearer in which uplink Packet Data Convergence Protocol, PDCP, Protocol Data Units, PDUs, are transmitted to both a Master eNB, MeNB, and to a Secondary eNB, SeNB, to a non-split bearer in which uplink PDCP PDUs are transmitted to the SeNB; andif reconfiguration of a bearer from a split bearer to a non-split bearer in which uplink PDCP PDUs are transmitted only to the SeNB is detected:initiating retransmission of PDCP SDUs from the first PDCP SDU for which there is no confirmation of successful delivery of a corresponding PDCP PDU by a protocol layer below the PDCP layer within the UE; andretransmitting all PDCP SDUs from the first PDCP SDU.
- The method of any one of the preceding claims, further comprising:detecting reconfiguration of a bearer from a non-split bearer to split bearer; andif reconfiguration of a bearer from a non-split bearer to a split bearer is detected:determining whether, before reconfiguration of the bearer from a split bearer to a non-split bearer, PDCP transmission were terminated within the MeNB or the SeNB;wherein if it is determined that PDCP transmissions were terminated within the MeNB then the method further comprises determining that no PDCP SDU retransmissions are required.
- The method of claim 8, wherein if it is determined that PDCP transmissions were terminated within the SeNB then the method further comprises:initiating retransmission of PDCP SDUs from the first PDCP SDU for which there is no confirmation of successful delivery of a corresponding PDCP PDU by a protocol layer below the PDCP layer within the UE; andretransmitting all PDCP SDUs from the first PDCP SDU.
- The method of any one of the preceding claims, further comprising:detecting reconfiguration of a bearer from a split bearer in which uplink PDCP PDUs are transmitted to only one of a MeNB and a SeNB to a non-split bearer in which uplink PDCP PDUs are transmitted to the MeNB;determining whether before reconfiguration PDCP PDU transmissions from the UE were restricted to transmissions to just the MeNB or just the SeNB;wherein if it is determined that PDCP PDU transmissions from the UE were restricted to transmissions to just the MeNB then the method further comprises determining that no PDCP SDU retransmissions are required; andwherein if it is determined that PDCP PDU transmissions from the UE were restricted to transmissions to just the SeNB then the method further comprises:initiating retransmission of PDCP SDUs from the first PDCP SDU for which there is no confirmation of successful delivery of a corresponding PDCP PDU by a protocol layer below the PDCP layer within the UE; andretransmitting all PDCP SDUs from the first PDCP SDU.
- A User Equipment, UE, in a Long Term Evolution, LTE, compliant mobile communications network, wherein the UE is arranged to:detect reconfiguration of a bearer from a split bearer in which uplink Packet Data Convergence Protocol, PDCP, Protocol Data Units, PDUs, are transmitted to both a Master eNB, MeNB, and to a Secondary eNB, SeNB, to a non-split bearer in which uplink PDCP PDUs are transmitted only to the MeNB;if reconfiguration of a bearer from a split bearer to a non-split bearer in which uplink PDCP PDUs are transmitted to the MeNB is detected, initiate retransmission of PDCP Service Data Units, SDUs, from the first PDCP SDU for which transmission of the corresponding PDCP PDU was attempted via the SeNB and for which there has been no confirmation of successful delivery by a protocol layer below the PDCP layer within the UE; andretransmit only PDCP SDUs for which transmission of the corresponding PDCP PDU was attempted via the SeNB.
- A UE according to claim 12, wherein the UE is further arranged to implement the method of any one of claims 2 to 10.
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
GB1319312.3 | 2013-11-01 | ||
GB1319312.3A GB2520923B (en) | 2013-11-01 | 2013-11-01 | Bearer reconfiguration |
Publications (1)
Publication Number | Publication Date |
---|---|
WO2015064931A1 true WO2015064931A1 (en) | 2015-05-07 |
Family
ID=49767518
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
PCT/KR2014/009581 WO2015064931A1 (en) | 2013-11-01 | 2014-10-13 | Method and apparatus for reconfiguring a bearer |
Country Status (2)
Country | Link |
---|---|
GB (1) | GB2520923B (en) |
WO (1) | WO2015064931A1 (en) |
Cited By (14)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
EP3123777A2 (en) * | 2014-03-28 | 2017-02-01 | Alcatel Lucent | Method and apparatus for processing rlc/ pdcp entities at a user equipment in a dual connectivity system |
WO2017032338A1 (en) * | 2015-08-27 | 2017-03-02 | Mediatek Inc. | Method of dynamic pdcp status report polling for lte wlan aggregation |
WO2018200565A1 (en) * | 2017-04-24 | 2018-11-01 | Motorola Mobility Llc | Duplicating pdcp pdus for a radio bearer |
WO2019061036A1 (en) * | 2017-09-26 | 2019-04-04 | Oppo广东移动通信有限公司 | Data processing method and terminal device |
WO2019140634A1 (en) * | 2018-01-19 | 2019-07-25 | Oppo广东移动通信有限公司 | Parameter adjustment method and relevant device |
CN110402612A (en) * | 2017-03-24 | 2019-11-01 | 摩托罗拉移动有限责任公司 | Separate the routing of loaded packet data convergence protocol protocol Data Unit |
CN110720234A (en) * | 2017-06-05 | 2020-01-21 | 三星电子株式会社 | Method and apparatus for configuring PDCP device and SDAP device in next generation mobile communication system |
CN110754110A (en) * | 2017-06-15 | 2020-02-04 | 三星电子株式会社 | Method and apparatus for controlling packet transmission |
EP3592037A4 (en) * | 2017-03-24 | 2020-03-25 | Huawei Technologies Co., Ltd. | Method and device for switching |
CN110999519A (en) * | 2017-08-11 | 2020-04-10 | 三星电子株式会社 | Method for performing bearer type change for multiple bearers configured for user equipment |
CN113271589A (en) * | 2014-08-04 | 2021-08-17 | 三星电子株式会社 | Apparatus in communication system supporting dual connection and method of operating the same |
US20220007375A1 (en) * | 2014-11-07 | 2022-01-06 | Nec Corporation | Wireless communication system, base station, and communication method |
CN116057985A (en) * | 2020-10-20 | 2023-05-02 | Oppo广东移动通信有限公司 | Method, device, equipment and medium for determining layer two measurement results of separated bearing |
US11838790B2 (en) | 2017-06-05 | 2023-12-05 | Samsung Electronics Co., Ltd. | Method and apparatus for configuring PDCP device and SDAP device in next-generation mobile communication system |
Families Citing this family (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
GB2525891B (en) * | 2014-05-07 | 2017-06-07 | Samsung Electronics Co Ltd | Bearer reconfiguration |
KR20150090804A (en) * | 2014-01-29 | 2015-08-06 | 삼성전자주식회사 | Method and apparatus for transmitting and receiving data using a plurality of carriers in mobilre communication system |
US11432223B2 (en) | 2015-07-08 | 2022-08-30 | Nokia Solutions And Networks Oy | Methods and apparatuses for selecting a first base station or a second base station to transmit a packet data unit (PDU) to a user equipment (UE) |
US10405367B2 (en) * | 2016-02-23 | 2019-09-03 | Telefonaktiebolaget Lm Ericsson (Publ) | Methods used in user equipment and associated UES |
KR102561713B1 (en) * | 2017-11-10 | 2023-08-01 | 삼성전자주식회사 | Method and apparatus for transmission and reception of data in wireless communication system |
CN109803390B (en) * | 2017-11-17 | 2023-05-02 | 中兴通讯股份有限公司 | Message and strategy sending method and device, storage medium and processor |
Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
KR20080047960A (en) * | 2006-11-27 | 2008-05-30 | 삼성전자주식회사 | Method and apparatus for data transmission of radio link control layer by timer in mobile telecommunication |
KR20090116921A (en) * | 2008-05-08 | 2009-11-12 | 주식회사 케이티테크 | Method for preventing from call drop during srns relocation and apparatus therefor |
US20100046442A1 (en) * | 2006-06-19 | 2010-02-25 | Ntt Docomo, Inc. | Method of controlling transmission parameter change and radio base station |
US20120120920A1 (en) * | 2003-11-05 | 2012-05-17 | Interdigital Technology Corporation | Method and wireless transmit/receive unit for supporting an enhanced uplink dedicated channel inter-node-b serving cell change |
WO2013154387A1 (en) * | 2012-04-12 | 2013-10-17 | Lg Electronics Inc. | Method and apparatus for transmitting configuration in wireless communication system |
Family Cites Families (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101389119B (en) * | 2007-09-11 | 2012-09-05 | 电信科学技术研究院 | Data retransmission method and device in process of LTE system cell switching |
-
2013
- 2013-11-01 GB GB1319312.3A patent/GB2520923B/en not_active Expired - Fee Related
-
2014
- 2014-10-13 WO PCT/KR2014/009581 patent/WO2015064931A1/en active Application Filing
Patent Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20120120920A1 (en) * | 2003-11-05 | 2012-05-17 | Interdigital Technology Corporation | Method and wireless transmit/receive unit for supporting an enhanced uplink dedicated channel inter-node-b serving cell change |
US20100046442A1 (en) * | 2006-06-19 | 2010-02-25 | Ntt Docomo, Inc. | Method of controlling transmission parameter change and radio base station |
KR20080047960A (en) * | 2006-11-27 | 2008-05-30 | 삼성전자주식회사 | Method and apparatus for data transmission of radio link control layer by timer in mobile telecommunication |
KR20090116921A (en) * | 2008-05-08 | 2009-11-12 | 주식회사 케이티테크 | Method for preventing from call drop during srns relocation and apparatus therefor |
WO2013154387A1 (en) * | 2012-04-12 | 2013-10-17 | Lg Electronics Inc. | Method and apparatus for transmitting configuration in wireless communication system |
Cited By (41)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
EP3123777A2 (en) * | 2014-03-28 | 2017-02-01 | Alcatel Lucent | Method and apparatus for processing rlc/ pdcp entities at a user equipment in a dual connectivity system |
CN113271589B (en) * | 2014-08-04 | 2024-03-05 | 三星电子株式会社 | Apparatus in communication system supporting dual connection and method of operating the same |
CN113271589A (en) * | 2014-08-04 | 2021-08-17 | 三星电子株式会社 | Apparatus in communication system supporting dual connection and method of operating the same |
US11528715B2 (en) * | 2014-11-07 | 2022-12-13 | Nec Corporation | Wireless communication system, base station, and communication method |
US20220007375A1 (en) * | 2014-11-07 | 2022-01-06 | Nec Corporation | Wireless communication system, base station, and communication method |
US10721617B2 (en) | 2015-08-27 | 2020-07-21 | Mediatek Inc. | Method of dynamic PDCP status report polling for LTE-WLAN aggregation |
WO2017032338A1 (en) * | 2015-08-27 | 2017-03-02 | Mediatek Inc. | Method of dynamic pdcp status report polling for lte wlan aggregation |
US10251052B2 (en) | 2015-08-27 | 2019-04-02 | Mediatek Inc. | Method of dynamic PDCP status report polling for LTE-WLAN aggregation |
US11751112B2 (en) | 2017-03-24 | 2023-09-05 | Huawei Technologies Co., Ltd. | Handover method and device |
EP3923632A1 (en) * | 2017-03-24 | 2021-12-15 | Huawei Technologies Co., Ltd. | Handover method and device |
CN110402612A (en) * | 2017-03-24 | 2019-11-01 | 摩托罗拉移动有限责任公司 | Separate the routing of loaded packet data convergence protocol protocol Data Unit |
EP3592037A4 (en) * | 2017-03-24 | 2020-03-25 | Huawei Technologies Co., Ltd. | Method and device for switching |
US10986549B2 (en) | 2017-03-24 | 2021-04-20 | Huawei Technologies Co., Ltd. | Handover method and device |
CN110402612B (en) * | 2017-03-24 | 2024-04-26 | 摩托罗拉移动有限责任公司 | Separate bearer packet data convergence protocol data unit routing |
CN114401217A (en) * | 2017-04-24 | 2022-04-26 | 摩托罗拉移动有限责任公司 | Duplicating PDCP PDUs for radio bearers |
US10574564B2 (en) | 2017-04-24 | 2020-02-25 | Motorola Mobility Llc | Duplicating PDCP PDUS for a radio bearer |
US11936555B2 (en) | 2017-04-24 | 2024-03-19 | Motorola Mobility Llc | Duplicating PDCP PDUs for a radio bearer |
CN110945901A (en) * | 2017-04-24 | 2020-03-31 | 摩托罗拉移动有限责任公司 | Duplicating PDCP PDUs for radio bearers |
EP4329272A3 (en) * | 2017-04-24 | 2024-06-05 | Motorola Mobility LLC | Duplicating pdcp pdus for a radio bearer |
KR102625204B1 (en) * | 2017-04-24 | 2024-01-16 | 모토로라 모빌리티 엘엘씨 | Replication of PDCP PDUs for radio bearers |
WO2018200565A1 (en) * | 2017-04-24 | 2018-11-01 | Motorola Mobility Llc | Duplicating pdcp pdus for a radio bearer |
CN110945901B (en) * | 2017-04-24 | 2022-03-01 | 摩托罗拉移动有限责任公司 | Duplicating PDCP PDUs for radio bearers |
KR20190139886A (en) * | 2017-04-24 | 2019-12-18 | 모토로라 모빌리티 엘엘씨 | Replication of PDCP PDUs for Radio Bearer |
US11343169B2 (en) | 2017-04-24 | 2022-05-24 | Motorola Mobility Llc | Duplicating PDCP PDUs for a radio bearer |
CN110720234A (en) * | 2017-06-05 | 2020-01-21 | 三星电子株式会社 | Method and apparatus for configuring PDCP device and SDAP device in next generation mobile communication system |
US11838790B2 (en) | 2017-06-05 | 2023-12-05 | Samsung Electronics Co., Ltd. | Method and apparatus for configuring PDCP device and SDAP device in next-generation mobile communication system |
CN110720234B (en) * | 2017-06-05 | 2023-10-24 | 三星电子株式会社 | Method and apparatus for configuring PDCP device and SDAP device in next generation mobile communication system |
CN110754110B (en) * | 2017-06-15 | 2023-09-19 | 三星电子株式会社 | Method and apparatus for controlling packet transmission |
CN110754110A (en) * | 2017-06-15 | 2020-02-04 | 三星电子株式会社 | Method and apparatus for controlling packet transmission |
US11722942B2 (en) | 2017-06-15 | 2023-08-08 | Samsung Electronics Co., Ltd. | Method and apparatus for controlling packet transmission |
CN110999519B (en) * | 2017-08-11 | 2023-10-27 | 三星电子株式会社 | Method for performing bearer type change for multiple bearers configured for user equipment |
US11950313B2 (en) | 2017-08-11 | 2024-04-02 | Samsung Electronics Co., Ltd. | Method for performing bearer type change of a plurality of bearers configured for user equipment |
CN110999519A (en) * | 2017-08-11 | 2020-04-10 | 三星电子株式会社 | Method for performing bearer type change for multiple bearers configured for user equipment |
WO2019061036A1 (en) * | 2017-09-26 | 2019-04-04 | Oppo广东移动通信有限公司 | Data processing method and terminal device |
US11582644B2 (en) | 2017-09-26 | 2023-02-14 | Guangdong Oppo Mobile Telecommunications Corp., Ltd. | System for performing split bearer operation using packet data convergence protocol (PDCP) |
TWI769314B (en) * | 2017-09-26 | 2022-07-01 | 大陸商Oppo廣東移動通信有限公司 | Method and terminal for processing data |
US10939327B2 (en) | 2017-09-26 | 2021-03-02 | Guangdong Oppo Mobile Telecommunications Corp., Ltd. | System for performing split bearer operation using packet data convergence protocol (PDCP) |
WO2019140634A1 (en) * | 2018-01-19 | 2019-07-25 | Oppo广东移动通信有限公司 | Parameter adjustment method and relevant device |
CN111406393B (en) * | 2018-01-19 | 2022-05-31 | Oppo广东移动通信有限公司 | Parameter adjusting method and related equipment |
CN111406393A (en) * | 2018-01-19 | 2020-07-10 | Oppo广东移动通信有限公司 | Parameter adjusting method and related equipment |
CN116057985A (en) * | 2020-10-20 | 2023-05-02 | Oppo广东移动通信有限公司 | Method, device, equipment and medium for determining layer two measurement results of separated bearing |
Also Published As
Publication number | Publication date |
---|---|
GB2520923A8 (en) | 2015-06-17 |
GB201319312D0 (en) | 2013-12-18 |
GB2520923A (en) | 2015-06-10 |
GB2520923B (en) | 2017-07-26 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
WO2015064931A1 (en) | Method and apparatus for reconfiguring a bearer | |
US11490446B2 (en) | Method and apparatus for reconfiguring a bearer | |
CN107277879B (en) | Method for supporting seamless switching and base station equipment | |
US7356146B2 (en) | Method for relocating SRNS in a mobile communication system | |
EP2184949B1 (en) | A method and an apparatus for non-access stratum message processing during handover in evolved network | |
WO2009099286A2 (en) | Mobile communication system and method for processing handover procedure thereof | |
US20080188223A1 (en) | Method, a system and a network element for performing a handover of a mobile equipment | |
WO2015115814A1 (en) | Efficient session management method and apparatus guaranteeing terminal mobility | |
WO2014182132A1 (en) | Method and device for transmitting data in wireless communication system supporting dual connectivity | |
WO2012060565A2 (en) | Method and apparatus for reconfiguring connection to base station at relay node in a wireless communication system | |
US20110149905A1 (en) | HANDOVER METHOD BETWEEN eNBs IN MOBILE COMMUNICATION SYSTEM | |
WO2013105786A1 (en) | Handover method and apparatus in wireless communication system | |
WO2019035645A2 (en) | Method and system for handling packet duplication and resumption of rbs in wireless communication system | |
WO2016089082A1 (en) | Method and apparatus for configuring disconnected tcp connection in communication system, handover support method and apparatus therefor | |
JP2013513988A (en) | Relay handover control | |
CN1422476A (en) | Data packet numbering in packet-switched data transmission | |
US20150195748A1 (en) | Mobile communication method | |
GB2525891A (en) | Bearer reconfiguration | |
WO2019066427A1 (en) | Method for handling data lossless in a um rlc entity in wireless communication system and a device therefor | |
WO2020197277A1 (en) | Method and device for processing downlink srb message in mcg rlf | |
US20070291712A1 (en) | Mobile communication system and data retransmission control method | |
WO2011059284A2 (en) | Method for securing handover data integrity in mobile communication system and system thereof | |
WO2021206405A1 (en) | Method and device for processing downlink rrc segment message in next-generation mobile communication system | |
WO2021096184A1 (en) | Method and device for segmenting downlink radio resource control message in next-generation mobile communication system | |
WO2022255824A1 (en) | Method and device for connecting multiple base stations in wireless communication system |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
121 | Ep: the epo has been informed by wipo that ep was designated in this application |
Ref document number: 14858924 Country of ref document: EP Kind code of ref document: A1 |
|
NENP | Non-entry into the national phase |
Ref country code: DE |
|
122 | Ep: pct application non-entry in european phase |
Ref document number: 14858924 Country of ref document: EP Kind code of ref document: A1 |