10.1.2 Mobility Management in ECM-CONNECTED/CM-CONNECTED

36.3003GPPEvolved Universal Terrestrial Radio Access (E-UTRA) and Evolved Universal Terrestrial Radio Access Network (E-UTRAN)Overall descriptionRelease 17Stage 2TS

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

10.1.2.0 General

The Intra-E-UTRAN-Access Mobility Support for UEs in ECM-CONNECTED/CM-CONNECTED handles all necessary steps for

– Handover procedures, like processes that precede the final HO decision on the source network side (control and evaluation of UE and eNB measurements taking into account certain UE specific roaming and access restrictions), preparation of resources on the target network side, commanding the UE to the new radio resources and finally releasing resources on the (old) source network side. It contains mechanisms to transfer context data between evolved nodes, and to update node relations on C-plane and U-plane. A CHO (for more details, see 10.1.2.1a) configuration may be also included in the handover procedures.

– DC specific procedures, like processes that precede the final decision for a certain configuration of a SeNB (control and evaluation of UE and network side measurements), preparation of respective resources on the network side of a SeNB, commanding the UE to the new radio resources configuration for a second connection and, if applicable, finally releasing resources of a SeNB. It contains mechanisms to transfer UE- and bearer-context data between involved nodes, and to update node relations on C-plane and U-plane.

In E-UTRAN RRC_CONNECTED state, network-controlled UE-assisted handovers and DC specific activities are performed and various DRX cycles are supported.

The UE makes measurements of attributes of the serving and neighbour cells to enable the process:

– There is no need to indicate neighbouring cells to enable the UE to search and measure a cell i.e. E-UTRAN relies on the UE to detect the neighbouring cells;

– For the search and measurement of inter-frequency neighbouring cells, at least the carrier frequencies need to be indicated;

– The E-UTRAN signals reporting criteria for event-triggered and periodical reporting;

– An NCL can be provided by the serving cell by RRC dedicated signalling to handle specific cases for intra- and inter-frequency neighbouring cells. This NCL contains cell specific measurement parameters (e.g. cell specific offset) for specific neighbouring cells;

– Exclude-lists can be provided to prevent the UE from measuring specific neighbouring cells.

For the UE measuring discovery signals (i.e. CRS and/or CSI-RS) of the serving and neighbour cells, the E-UTRAN indicates the measurement configuration to the UE, including the measurement timing configuration of the discovery signals.

Depending on whether the UE needs transmission/reception gaps to perform the relevant measurements, measurements are classified as gap assisted or non-gap assisted. A non-gap assisted measurement is a measurement on a cell that does not require transmission/reception gaps to allow the measurement to be performed. A gap assisted measurement is a measurement on a cell that does require transmission/reception gaps to allow the measurement to be performed. Gap patterns (as opposed to individual gaps) are configured and activated by RRC.

In the text and figure(s) in the following clauses, intra-E-UTRA HO description is applicable for both intra-EPC and intra-5GC cases. In addition, the following differences are applicable for intra-5GC:

– ng-eNB should be considered instead of eNB;

– 5GC should be considered instead of EPC, and NG interface should be considered instead of S1 interface;

– Xn interface should be considered instead of X2 interface and the messages sent between ng-eNBs over Xn are defined in TS 38.423 [86];

– AMF should be considered intead of MME, and UPF should be considered instead of Serving Gateway;

– PDU session information should be considered instead of E-RAB QoS, and the QoS flow to DRB mapping rules applied to the UE should be forwarded to the target ng-eNB;

– For the messages sent between MME and Serving Gateway, and between MME and eNB, use AMF/UPF/ng-eNB respectively;

– The data forwarding defined in clause 9.2.3.2.3 in TS 38.300 [79] should be applied instead of clause 10.1.2.3;

– The Dual Connectivity operation in clause 10.1.2.8 is not applicable to intra-5GC mobility. The corresponding Dual Connectivity operations for 5GC are described in TS 37.340 [76].

10.1.2.1 Handover

10.1.2.1.0 General

The intra E-UTRAN HO of a UE in RRC_CONNECTED state is a UE-assisted network-controlled HO, with HO preparation signalling in E-UTRAN:

– Part of the HO command comes from the target eNB and is transparently forwarded to the UE by the source eNB;

– To prepare the HO, the source eNB passes all necessary information to the target eNB (e.g. E-RAB attributes and RRC context):

– When CA is configured and to enable SCell selection in the target eNB, the source eNB can provide in decreasing order of radio quality a list of the best cells and optionally measurement result of the cells.

– When DC is configured, the source MeNB provides the SCG configuration (in addition to the MCG configuration) to the target MeNB.

– Both the source eNB and UE keep some context (e.g. C-RNTI) to enable the return of the UE in case of HO failure;

– If RACH-less HO is not configured, the UE accesses the target cell via RACH following a contention-free procedure using a dedicated RACH preamble or following a contention-based procedure if dedicated RACH preambles are not available:

– the UE uses the dedicated preamble until the handover procedure is finished (successfully or unsuccessfully);

– If RACH-less HO is configured, the UE accesses the target cell via the uplink grant preallocated to the UE in the RRC message. If the UE does not receive the preallocated uplink grant in the RRC message from the source eNB, the UE monitors the PDCCH of the target cell;

– If DAPS handover is configured, the UE continues the downlink user data reception from the source eNB until releasing the source cell and continues the uplink user data transmission to the source eNB until successful random access procedure to the target eNB. Upon reception of the handover command, the UE:

– Creates a MAC entity for target cell;

– Establishes the RLC entity and an associated DTCH logical channel for target cell for each DRB configured with DAPS;

– For the DRB(s) configured with DAPS, reconfigures the PDCP entity to configure DAPS with separate security and ROHC functions for source and target and associates them with the RLC entities configured for source and target respectively;

– Retains rest of the source link configurations until release of the source.

– UE maintains only PCell connection with both source and target eNBs. Any other configured serving cells, NR sidelink configurations and V2X sidelink configurations are released by the network before the handover command is sent to the UE.

NOTE: Void.

– If the access towards the target cell (using RACH or RACH-less procedure) is not successful within a certain time, the UE initiates radio link failure recovery using a suitable cell except in DAPS handover or CHO scenarios:

– When DAPS handover fails, the UE falls back to source cell configuration, resumes the connection with source cell, and reports the DAPS handover failure via the source without triggering RRC connection re-establishment if the source link is still available; Otherwise, RRC re-establishment is performed;

– When initial CHO execution attempt fails or Handover fails, if network configured the UE to try CHO after HO/CHO failure and the UE performs cell selection to a CHO candidate cell, the UE attempts CHO execution to that cell; Otherwise, RRC re-establishment is performed.

– No ROHC and EHC context is transferred at handover;

– No UDC context is transferred at handover;

– ROHC and EHC contexts can be kept at handover within the same eNB.

10.1.2.1.1 C-plane handling

The preparation and execution phase of the HO procedure is performed without EPC involvement, i.e. preparation messages are directly exchanged between the eNBs. The release of the resources at the source side during the HO completion phase is triggered by the eNB. In case an RN is involved, its DeNB relays the appropriate S1 messages between the RN and the MME (S1-based handover) and X2 messages between the RN and target eNB (X2-based handover); the DeNB is explicitly aware of a UE attached to the RN due to the S1 proxy and X2 proxy functionality (see clause 4.7.6.6). The figure below depicts the basic handover scenario where neither MME nor Serving Gateway changes:

Figure 10.1.2.1.1-1: Intra-MME/Serving Gateway HO

Below is a more detailed description of the intra-MME/Serving Gateway HO procedure:

0 The UE context within the source eNB contains information regarding roaming and access restrictions which were provided either at connection establishment or at the last TA update.

1 The source eNB configures the UE measurement procedures according to the roaming and access restriction information and e.g. the available multiple frequency band information. Measurements provided by the source eNB may assist the function controlling the UE’s connection mobility.

2 A MEASUREMENT REPORT is triggered and sent to the eNB.

3 The source eNB makes decision based on MEASUREMENT REPORT and RRM information to hand off the UE.

4 The source eNB issues a HANDOVER REQUEST message to the target eNB passing necessary information to prepare the HO at the target side (UE X2 signalling context reference at source eNB, UE S1 EPC signalling context reference, target cell ID, K_eNB*, RRC context including the C-RNTI of the UE in the source eNB, AS-configuration, E-RAB context and physical layer ID of the source cell + short MAC-I for possible RLF recovery). The source eNB may also request a DAPS Handover for one or more E-RABs. UE X2 / UE S1 signalling references enable the target eNB to address the source eNB and the EPC. The E-RAB context includes necessary RNL and TNL addressing information, and QoS profiles of the E-RABs.

5 Admission Control may be performed by the target eNB dependent on the received E-RAB QoS information to increase the likelihood of a successful HO, if the resources can be granted by target eNB. The target eNB configures the required resources according to the received E-RAB QoS information and reserves a C-RNTI and optionally a RACH preamble. The AS-configuration to be used in the target cell can either be specified independently (i.e. an "establishment") or as a delta compared to the AS-configuration used in the source cell (i.e. a "reconfiguration").

6 The target eNB prepares HO with L1/L2 and sends the HANDOVER REQUEST ACKNOWLEDGE to the source eNB. The HANDOVER REQUEST ACKNOWLEDGE message includes a transparent container to be sent to the UE as an RRC message to perform the handover. The container includes a new C-RNTI, target eNB security algorithm identifiers for the selected security algorithms, may include a dedicated RACH preamble, and possibly some other parameters i.e. access parameters, SIBs, etc. If RACH-less HO is configured, the container includes timing adjustment indication and optionally a preallocated uplink grant. The HANDOVER REQUEST ACKNOWLEDGE message may also include RNL/TNL information for the forwarding tunnels, if necessary. The target eNB also indicates if a DAPS Handover is accepted.

NOTE 1: As soon as the source eNB receives the HANDOVER REQUEST ACKNOWLEDGE, or as soon as the transmission of the handover command is initiated in the downlink, data forwarding may be initiated.

NOTE 1a: For E-RABs configured with DAPS, downlink PDCP SDUs are forwarded with SN assigned by the source eNB, until SN assignment is handed over to the target eNB in step 11b, for which the normal data forwarding follows as defined in 10.1.2.3.

Steps 7 to 16 provide means to avoid data loss during HO and are further detailed in 10.1.2.1.2 and 10.1.2.3.

7 The target eNB generates the RRC message to perform the handover, i.e. RRCConnectionReconfiguration message including the mobilityControlInfo, to be sent by the source eNB towards the UE. The source eNB performs the necessary integrity protection and ciphering of the message.

The UE receives the RRCConnectionReconfiguration message with necessary parameters (i.e. new C-RNTI, target eNB security algorithm identifiers, and optionally dedicated RACH preamble, target eNB SIBs, etc.) and is commanded by the source eNB to perform the HO. If RACH-less HO is configured, the RRCConnectionReconfiguration includes timing adjustment indication and optionally preallocated uplink grant for accessing the target eNB. If preallocated uplink grant is not included, the UE should monitor PDCCH of the target eNB to receive an uplink grant. The UE does not need to delay the handover execution for delivering the HARQ/ARQ responses to source eNB.

If Make-Before-Break HO is configured, the connection to the source cell is maintained after the reception of RRCConnectionReconfiguration message with mobilityControlInfo before the UE executes initial uplink transmission to the target cell.

NOTE 2: If Make-Before-Break HO is configured, the source eNB decides when to stop transmitting to the UE.

NOTE 3: The UE can be configured with Make-Before-Break HO and RACH-less HO simultaneously.

In case of DAPS Handover, the UE does not detach from the source cell upon receiving the RRCConnectionReconfiguration message. The UE releases the source SRB resources, security configuration of the source cell and stops DL/UL reception/transmission with the source upon receiving an explicit release from the target node.

NOTE 3a: The DAPS Handover is considered to only be completed after the UE has released the source cell as explicitly requested from the target node. Features that cannot be configured simultaneously with DAPS Handover (CA, DC, EHC, UDC and CHO) can be configured earliest in the same RRCConnectionReconfiguration message that releases the source cell. RRC suspend, a subsequent handover or inter-RAT handover cannot be initiated until the source cell has been released.

NOTE 4: CA, DC, EHC, UDC, CHO or RACH-less HO cannot be configured simultaneously with DAPS Handover and must be released by the source eNB before the DAPS Handover command is sent to the UE.

NOTE 5: For E-RABs configured with DAPS, the source eNB does not stop transmitting downlink packets until it receives the HANDOVER SUCCESS message from the target eNB in step 11a.

8a For E-RABs configured with DAPS, the source eNB sends the EARLY STATUS TRANSFER message. The DL COUNT value conveyed in the EARLY STATUS TRANSFER message indicates PDCP SN and HFN of the first PDCP SDU that the source eNB forwards to the target eNB. The source eNB does not stop assigning PDCP SNs to downlink packets until it sends the SN STATUS TRANSFER message to the target eNB in step 11b.

8 For E-RABs not configured with DAPS, the source eNB sends the SN STATUS TRANSFER message to the target eNB to convey the uplink PDCP SN receiver status and the downlink PDCP SN transmitter status of E-RABs for which PDCP status preservation applies (i.e. for RLC AM). The uplink PDCP SN receiver status includes at least the PDCP SN of the first missing UL SDU and may include a bit map of the receive status of the out of sequence UL SDUs that the UE needs to retransmit in the target cell, if there are any such SDUs. The downlink PDCP SN transmitter status indicates the next PDCP SN that the target eNB shall assign to new SDUs, not having a PDCP SN yet. The source eNB may omit sending this message if none of the E-RABs of the UE shall be treated with PDCP status preservation.

NOTE 6: In case of DAPS Handover, the uplink PDCP SN receiver status and the downlink PDCP SN transmitter status for an E-RAB with RLC-AM and not configured with DAPS may be transferred by the SN STATUS TRANSFER message in step 11b instead of step 8.

NOTE 7: For E-RABs configured with DAPS, the source eNB may additionally send the EARLY STATUS TRANSFER message(s) between step 8 and step 11b, to inform discarding of already forwarded PDCP SDUs. The target eNB does not transmit forwarded downlink PDCP SDUs to the UE whose COUNT is less than the conveyed DL COUNT value and discards them if transmission has not been attempted already.

9 If RACH-less HO is not configured, after receiving the RRCConnectionReconfiguration message including the mobilityControlInfo, UE performs synchronisation to target eNB and accesses the target cell via RACH, following a contention-free procedure if a dedicated RACH preamble was indicated in the mobilityControlInfo, or following a contention-based procedure if no dedicated preamble was indicated. UE derives target eNB specific keys and configures the selected security algorithms to be used in the target cell.

If RACH-less HO is configured, UE performs synchronisation to target eNB. UE derives target eNB specific keys and configures the selected security algorithms to be used in the target cell.

10 If RACH-less HO is not configured, the target eNB responds with UL allocation and timing advance.

10a If RACH-less HO is configured and the UE did not get the periodic pre-allocated uplink grant in the RRCConnectionReconfiguration message including the mobilityControlInfo, the UE receives uplink grant via the PDCCH of the target cell. The UE uses the first available uplink grant after synchronization to the target cell.

11 When the RACH-less HO is not configured and the UE has successfully accessed the target cell, the UE sends the RRCConnectionReconfigurationComplete message (C-RNTI) to confirm the handover, along with an uplink Buffer Status Report, and/or UL data, whenever possible, to the target eNB, which indicates that the handover procedure is completed for the UE. The target eNB verifies the C-RNTI sent in the RRCConnectionReconfigurationComplete message. The target eNB can now begin sending data to the UE.

When the RACH-less HO is configured, after the UE has received uplink grant, the UE sends the RRCConnectionReconfigurationComplete message (C-RNTI) to confirm the handover, along with an uplink Buffer Status Report, and/or UL data, whenever possible, to the target eNB. The target eNB verifies the C-RNTI sent in the RRCConnectionReconfigurationComplete message. The target eNB can now begin sending data to the UE. The handover procedure is completed for the UE when the UE receives the UE contention resolution identity MAC control element from the target eNB.

11a/b In case of DAPS Handover, the target eNB sends the HANDOVER SUCCESS message to the source eNB to inform that the UE has successfully accessed the target cell. In return, the source eNB sends the SN STATUS TRANSFER message for E-RABs configured with DAPS for which the description in step 8 applies, and the normal data forwarding follows as defined in 10.1.2.3.

NOTE 8: For E-RABs configured with DAPS, the source eNB does not stop delivering uplink packets to the S-GW until it sends the SN STATUS TRANSFER message in step 11b. The target eNB does not forward the uplink PDCP SDUs successfully received in-sequence to the S-GW until it receives the SN STATUS TRANSFER message, in which UL HFN and the first missing SN in the uplink PDCP SN receiver status indicates the start of uplink PDCP SDUs to be delivered to the S-GW. The target eNB does not deliver any uplink packet which has an UL COUNT lower than the provided.

NOTE 9: Void.

12 The target eNB sends a PATH SWITCH REQUEST message to MME to inform that the UE has changed cell.

13 The MME sends a MODIFY BEARER REQUEST message to the Serving Gateway.

14 The Serving Gateway switches the downlink data path to the target side. The Serving gateway sends one or more "end marker" packets on the old path to the source eNB and then can release any U-plane/TNL resources towards the source eNB.

15 The Serving Gateway sends a MODIFY BEARER RESPONSE message to MME.

16 The MME confirms the PATH SWITCH REQUEST message with the PATH SWITCH REQUEST ACKNOWLEDGE message.

17 By sending the UE CONTEXT RELEASE message, the target eNB informs success of HO to source eNB and triggers the release of resources by the source eNB. The target eNB sends this message after the PATH SWITCH REQUEST ACKNOWLEDGE message is received from the MME.

18 Upon reception of the UE CONTEXT RELEASE message, the source eNB can release radio and C-plane related resources associated to the UE context. Any ongoing data forwarding may continue.

When an X2 handover is used involving HeNBs and when the source HeNB is connected to a HeNB GW, a UE CONTEXT RELEASE REQUEST message including an explicit GW Context Release Indication is sent by the source HeNB, in order to indicate that the HeNB GW may release of all the resources related to the UE context.

For DAPS handover, upon receiving DAPS handover command message, the UE suspends source cell SRBs, stops sending and receiving any RRC control plane signalling towards the source cell and establishes SRBs for the target cell. The UE releases the source cell SRBs configuration upon receiving source cell release indication from the target cell after successful DAPS handover execution. When DAPS handover to the target cell fails and if the source cell link is available then the UE reverts back to the source cell configuration and activates source cell SRBs for control plane signalling. When DAPS handover is configured, PDCP duplication is not allowed.

10.1.2.1.2 U-plane handling

The U-plane handling during the Intra-E-UTRAN-Access mobility activity for UEs in ECM-CONNECTED takes the following principles into account to avoid data loss during HO:

– During HO preparation U-plane tunnels can be established between the source eNB and the target eNB. There is one tunnel established for uplink data forwarding and another one for downlink data forwarding for each E-RAB for which data forwarding is applied. In the case of a UE under an RN performing handover, forwarding tunnels can be established between the RN and the target eNB via the DeNB.

– During HO execution, user data can be forwarded from the source eNB to the target eNB. The forwarding may take place in a service and deployment dependent and implementation specific way.

– Forwarding of downlink user data from the source to the target eNB should take place in order as long as packets are received at the source eNB from the EPC or the source eNB buffer has not been emptied.

– During HO completion:

– The target eNB sends a PATH SWITCH message to MME to inform that the UE has gained access and MME sends a MODIFY BEARER REQUEST message to the Serving Gateway, the U-plane path is switched by the Serving Gateway from the source eNB to the target eNB.

– The source eNB should continue forwarding of U-plane data as long as packets are received at the source eNB from the Serving Gateway or the source eNB buffer has not been emptied.

For RLC-AM bearers:

– During normal HO not involving Full Configuration:

– For in-sequence delivery and duplication avoidance, PDCP SN is maintained on a bearer basis and the source eNB informs the target eNB about the next DL PDCP SN to allocate to a packet which does not have a PDCP sequence number yet (either from source eNB or from the Serving Gateway).

– For security synchronisation, HFN is also maintained and the source eNB provides to the target one reference HFN for the UL and one for the DL i.e. HFN and corresponding SN.

– In both the UE and the target eNB, a window-based mechanism is needed for duplication detection.

– The occurrence of duplicates over the air interface in the target eNB is minimised by means of PDCP SN based reporting at the target eNB by the UE. In uplink, the reporting is optionally configured on a bearer basis by the eNB and the UE should first start by transmitting those reports when granted resources in the target eNB. In downlink, the eNB is free to decide when and for which bearers a report is sent and the UE does not wait for the report to resume uplink transmission.

– The target eNB re-transmits and prioritizes all downlink PDCP SDUs forwarded by the source eNB (i.e. the target eNB should send data with PDCP SNs from X2 before sending data from S1), with the exception of PDCP SDUs of which the reception was acknowledged through PDCP SN based reporting by the UE.

– The UE re-transmits in the target eNB all uplink PDCP SDUs starting from the first PDCP SDU following the last consecutively confirmed PDCP SDU i.e. the oldest PDCP SDU that has not been acknowledged at RLC in the source, excluding the PDCP SDUs of which the reception was acknowledged through PDCP SN based reporting by the target.

– During HO involving Full Configuration:

– The following description below for RLC-UM bearers also applies for RLC-AM bearers. Data loss may happen.

For RLC-UM bearers:

– The PDCP SN and HFN are reset in the target eNB, unless the bearer is configured with DAPS Handover.

– No PDCP SDUs are retransmitted in the target eNB.

– The target eNB prioritizes all downlink PDCP SDUs forwarded by the source eNB if any (i.e. the target eNB should send data with PDCP SNs from X2 before sending data from S1).

– The UE PDCP entity does not attempt to retransmit any PDCP SDU in the target cell for which transmission had been completed in the source cell. Instead UE PDCP entity starts the transmission with other PDCP SDUs.

For DAPS handover:

A DAPS Handover can be used for an RLC-AM or RLC-UM bearer. For a DRB configured with DAPS, the following principles are additionally applied.

Downlink:

– During HO preparation, a forwarding tunnel is always established.

– The source eNB is responsible for allocating downlink PDCP SNs until the SN assignment is handed over to the target eNB and data forwarding in 10.1.2.3.1 (RLC-AM) or in 10.1.2.3.2 (RLC-UM) takes place. That is, the source eNB does not stop assigning PDCP SNs to downlink packets until it receives the HANDOVER SUCCESS message and sends the SN STATUS TRANSFER message to the target eNB.

– Upon allocation of downlink PDCP SNs by the source eNB, it starts scheduling downlink data on the source radio link and also starts forwarding downlink PDCP SDUs along with assigned PDCP SNs to the target eNB.

– For security synchronisation, HFN is maintained for the forwarded downlink SDUs with PDCP SNs assigned by the source eNB. The source eNB sends the EARLY STATUS TRANSFER message to convey the DL COUNT value, indicating PDCP SN and HFN of the first PDCP SDU that the source eNB forwards to the target eNB.

– HFN and PDCP SN are maintained after the SN assignment is handed over to the target eNB. The SN STATUS TRANSFER message indicates the next DL COUNT to allocate to a packet which does not have a PDCP sequence number yet, even for RLC-UM.

– During handover execution period, the source and target eNBs separately perform ROHC header compression, ciphering and adding PDCP header.

– During handover execution period, the UE continues to receive downlink data from both source and target eNBs until the source eNB connection is released by an explicit release command from the target eNB.

– During handover execution period, the UE PDCP entity configured with DAPS maintains separate security and ROHC header decompression functions associated with each eNB, while maintaining common functions for reordering, duplicate detection and discard, and PDCP SDUs in-sequence delivery to upper layers, PDCP SN continuity will be supported for both RLC AM and UM DRBs configured with DAPS.

Uplink:

– The UE transmits UL data to the source eNB until the random access procedure towards the target eNB has been successfully completed. Afterwards the UE switches its UL data transmission to the target eNB.

– Even after switching its UL data transmissions towards the target eNB, the UE continues to send UL layer 1 CSI feedback, HARQ feedback, layer 2 RLC feedback, ROHC feedback, HARQ data (re-)transmissions and RLC data (re-)transmissions to the source eNB.

– During handover execution period, the UE maintains separate security context and ROHC header compressor context for uplink transmissions towards the source and target eNBs. The UE maintains common UL PDCP SN allocation, PDCP SN continuity is supported for both RLC AM and UM DRBs configured with DAPS.

– During handover execution period, the source and target eNBs maintain their own security and ROHC header decompressor contexts to process UL data received from the UE.

– The establishment of a forwarding tunnel is optional.

– HFN and PDCP SN are maintained in the target eNB. The SN STATUS TRANSFER message indicates the UL COUNT of the first missing PDCP SDU that the target eNB should start delivering to the S-GW, even for RLC-UM.

For DRBs not configured with DAPS, upon UE receiving DAPS handover command message, UE stops transmission and reception of data from source cell and keeps source cell non-DAPS DRB configuration. When DAPS handover to target cell fails and if source cell link is available then UE will revert back to source cell configuration prior to the reception of DAPS handover command (including RLC, PDCP state variables and buffers).

10.1.2.1a Conditional Handover

10.1.2.1a.1 General

A Conditional Handover (CHO) is defined as a handover that is executed by the UE when one or more handover execution conditions are met. The UE starts evaluating the execution condition(s) for CHO candidate cells upon receiving the CHO configuration, and executes CHO once the execution condition(s) are met for a CHO candidate cell. UE stops evaluating the execution condition(s) once a handover is executed.

The following principles apply to CHO:

– The CHO configuration contains the configuration of CHO candidate cell(s) generated by each CHO candidate cell and execution condition(s) generated by the source cell.

– An execution condition may consist of one or two trigger condition(s) (CHO events A3/A5). Only single RS type is supported and at most two different trigger quantities (e.g. RSRP and RSRQ, RSRP and SINR, etc.) can be configured simultaneously for the evaluation of CHO execution condition of a single candidate cell.

– UE maintains connection with source eNB until UE determines a CHO execution condition is met for CHO candidate cell.

– Before any CHO execution condition is satisfied, upon reception of HO command (without CHO configuration), the UE executes the HO procedure as described in clause 10.1.2.1, regardless of any previously received CHO configuration.

– After source eNB sends CHO command to UE, the network is allowed to change source eNB configuration and network can add, modify or release a configured CHO configuration using RRC message (i.e. until UE starts executing CHO.

– While executing CHO, i.e. from the time when the UE starts synchronization with target cell, UE does not monitor source cell.

NOTE 1: CHO is not supported for S1 based handover in this release of the specification.

NOTE 2: In case LTE-DC is configured, CHO is only supported in MeNB to eNB change procedure in this release of the specification.

10.1.2.1a.2 C-plane handling

The figure below depicts the CHO scenario where neither MME nor Serving Gateway changes:

Figure 10.1.2.1a-1: Intra-MME/Serving Gateway Conditional Handover

1. The source eNB configures the UE with measurement configuration, which may be used by the UE to trigger Measurement Reports for potential CHO candidate cell(s).

2. A MEASUREMENT REPORT is triggered and sent to the source eNB.

3. The source eNB makes decision on the usage of CHO to handoff the UE based on MEASUREMENT REPORT information.

4. The source eNB requests a CHO to the eNB(s) of candidate cell(s). A CHO request message is sent for each candidate cell.

5. Same as step 5 in Figure 10.1.2.1.1-1 of clause 10.1.2.1.1.

6. The eNB(s) of candidate cell(s) sends CHO response including configuration of CHO candidate cell(s) to the source eNB. The response message is also sent for each candidate cell.

7. The source eNB sends a RRCConnectionReconfiguration message to the UE, containing configuration of CHO candidate cell(s) and CHO execution condition(s). The source eNB decides on the condition for the execution of CHO and adds the condition(s) to the RRC message sent to the UE.

NOTE 1: The source eNB may reconfigure the UE’s source configuration after providing CHO configuration for candidate target cell(s).

NOTE 1a: A configuration of a CHO candidate cell cannot contain a DAPS handover.

8. The UE sends an RRCConnectionReconfigurationComplete message to the source eNB.

8a. If early data forwarding is applied, the source eNB sends the EARLY STATUS TRANSFER message.

9. The UE maintains connection with the source eNB after receiving CHO configuration, and starts evaluating the CHO execution condition(s) for the CHO candidate cell(s). If at least one CHO candidate cell satisfies the corresponding CHO execution condition, the UE detaches from the source eNB, applies the stored corresponding configuration for that candidate cell and synchronises to that candidate cell.

10-11. The UE accesses to the target eNB and completes the handover procedure by sending RRCConnectionReconfigurationComplete message to the target eNB. The UE releases the stored CHO configurations after successful completion of RRC handover procedure.

11a/b. The target eNB sends the HANDOVER SUCCESS message to the source eNB to inform that the UE has successfully accessed the target cell. In return, the source eNB sends the SN STATUS TRANSFER message.

NOTE 2: Late data forwarding may be initiated as soon as the source eNB receives the HANDOVER SUCCESS message.

11c. The source eNB sends the HANDOVER CANCEL message toward the other signalling connections or other potential target eNBs, if any, to cancel CHO for the UE.

12. Steps 12-18 as in Figure 10.1.2.1.1-1.

10.1.2.1a.3 U-plane handling

The U-plane handling for Conditional Handover follows the same principles for DAPS Handover in 10.1.2.1.2, if early data forwarding is applied, except that, in case of Full Configuration, HFN and PDCP SN are reset in the target eNB after the SN assignment is handed over to the target eNB. If late data forwarding is applied, the U-plane handling follows the RLC-AM or RLC-UM bearer principles defined in 10.1.2.1.2.

10.1.2.1a.4 Data Forwarding

If late data forwarding is applied, the source eNB initiates data forwarding once it knows which target eNB the UE has successfully accessed. In that case the behavior of the Conditional Handover data forwarding follows the same behavior as defined in 10.1.2.3.1 and 10.1.2.3.2 for the intra-system handover data forwarding for RLC-AM and RLC-UM bearers.

If early data forwarding is applied instead, the source eNB initiates data forwarding before the UE executes the handover, to a candidate target node of interest, The behavior of early data forwarding for the Conditional Handover follows the same principles for DRBs configured with DAPS Handover in the intra-system handover as defined in 10.1.2.3.5.

10.1.2.2 Path Switch

10.1.2.2.1 Path Switch upon handover

After the downlink path is switched at the Serving GW downlink packets on the forwarding path and on the new direct path may arrive interchanged at the target eNB. The target eNodeB should first deliver all forwarded packets to the UE before delivering any of the packets received on the new direct path. The method employed in the target eNB to enforce the correct delivery order of packets is outside the scope of the standard.

In order to assist the reordering function in the target eNB, the Serving GW shall send one or more "end marker" packets on the old path immediately after switching the path for each E-RAB of the UE. The "end marker" packet shall not contain user data. The "end marker" is indicated in the GTP header. After completing the sending of the tagged packets the GW shall not send any further user data packets via the old path.

Upon receiving the "end marker" packets, the source eNB shall, if forwarding is activated for that bearer, forward the packet toward the target eNB.

On detection of an "end marker" the target eNB shall discard the end marker packet and initiate any necessary processing to maintain in sequence delivery of user data forwarded over X2 interface and user data received from the serving GW over S1 as a result of the path switch.

On detection of the "end marker", the target eNB may also initiate the release of the data forwarding resource. However, the release of the data forwarding resource is implementation dependent and could also be based on other mechanisms (e.g. timer-based mechanism).

EPC may change the uplink end-point of the tunnels with Path Switch procedure. However, the EPC should keep the old GTP tunnel end-point(s) sufficiently long time in order to minimise the probability of packet losses and avoid unintentional release of respective E-RAB(s).

10.1.2.2.2 Path Update upon Dual Connectivity specific activities

Upon DC specific activities which involve the transfer of bearer contexts from one eNB to another, if one of the eNBs involved in DC provides radio resources to the UE for one or several E-RABs configured with the SCG bearer option, the update of the downlink path towards the EPC for the relevant E-RABs needs to be communicated by the MeNB to the MME. The functions specified for the path switch for handover as specified in clause 10.1.2.2.1 are applicable for the path update for DC with SCG bearer option as well except that:

– The role of involved eNBs are different: in DC, the "source eNB" as specified for handover, is the eNB from which the bearer context is transferred and the "target eNB" is the eNB to which the bearer context is transferred.

– The EPC does not change the uplink end-point of the tunnels with the Path Update procedure in a way that this would change the Serving GW.

10.1.2.2.3 Path Switch upon UE context resume

Upon resumption of a UE context in an eNB different from the one where the UE context was suspended, the Path Switch procedure is used to request the MME to resume the UE context and related bearer contexts in the EPC and update the downlink path.

10.1.2.3 Data forwarding

10.1.2.3.1 For RLC-AM DRBs

Upon handover, the source eNB may forward in order to the target eNB all downlink PDCP SDUs with their SN that have not been acknowledged by the UE. In addition, the source eNB may also forward without a PDCP SN fresh data arriving over S1 to the target eNB.

NOTE 1: The target eNB does not have to wait for the completion of forwarding from the source eNB before it begins transmitting packets to the UE.

The source eNB discards any remaining downlink RLC PDUs. Correspondingly, the source eNB does not forward the downlink RLC context to the target eNB.

NOTE 2: The source eNB does not need to abort ongoing RLC transmissions with the UE as it starts data forwarding to the target eNB.

Upon handover, the source eNB forwards to the Serving Gateway the uplink PDCP SDUs successfully received in-sequence until the sending of the Status Transfer message to the target eNB. Then at that point of time the source eNB stops delivering uplink PDCP SDUs to the S-GW and shall discard any remaining uplink RLC PDUs. Correspondingly, the source eNB does not forward the uplink RLC context to the target eNB.

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.

The PDCP SN of forwarded SDUs is carried in the "PDCP PDU number" field of the GTP-U extension header. The target eNB shall use the PDCP SN if it is available in the forwarded GTP-U packet.

For normal HO in-sequence delivery of upper layer PDUs during handover is based on a continuous PDCP SN and is provided by the "in-order delivery and duplicate elimination" function at the PDCP layer:

– in the downlink, the "in-order delivery and duplicate elimination" function at the UE PDCP layer guarantees in-sequence delivery of downlink PDCP SDUs;

– in the uplink, the "in-order delivery and duplicate elimination" function at the target eNB PDCP layer guarantees in-sequence delivery of uplink PDCP SDUs.

After a normal handover, when the UE receives a PDCP SDU from the target eNB, it can deliver it to higher layer together with all PDCP SDUs with lower SNs regardless of possible gaps.

For handovers involving Full Configuration, the source eNB behaviour is unchanged from the description above. The target eNB may not send PDCP SDUs for which delivery was attempted by the source eNB. The target eNB identifies these by the presence of the PDCP SN in the forwarded GTP-U packet and discards them.

After a Full Configuration handover, the UE delivers received PDCP SDU from the source cell to the higher layer regardless of possible gaps. UE discards uplink PDCP SDUs for which transmission was attempted and retransmission of these over the target cell is not possible.

10.1.2.3.2 For RLC-UM DRBs

Upon handover, the source eNB does not forward to the target eNB downlink PDCP SDUs for which transmission had been completed in the source cell. PDCP SDUs that have not been transmitted may be forwarded. In addition, the source eNB may forward fresh downlink data arriving over S1 to the target eNB. The source eNB discards any remaining downlink RLC PDUs. Correspondingly, the source eNB does not forward the downlink RLC context to the target eNB.

Upon handover, the source eNB forwards all uplink PDCP SDUs successfully received to the Serving Gateway (i.e. including the ones received out of sequence) and discards any remaining uplink RLC PDUs. Correspondingly, the source eNB does not forward the uplink RLC context to the target eNB.

10.1.2.3.3 SRB handling

With respect to SRBs, the following principles apply at HO:

– No forwarding or retransmissions of RRC messages in the target;

– The PDCP SN and HFN are reset in the target.

10.1.2.3.4 User data forwarding for Dual Connectivity

Upon DC specific activities user data forwarding may be performed for E-RABs configured with the SCG bearer option　or with the split bearer option. The behaviour of the eNB from which data is forwarded is the same as specified for the "source eNB" for handover, the behaviour of the eNB to which data is forwarded is the same as specified for the "target eNB" for handover. If data forwarding for split bearer option is applied, the PDCP PDUs which are not acknowledged by the UE are forwarded from the SeNB to the MeNB in the course of procedures involving the release of the SCG part of the split bearer (e.g., SeNB Modification, SeNB Release, Change of SeNB).

10.1.2.3.5 For DRBs configured with DAPS Handover

Data forwarding after the source eNB receives the HANDOVER SUCCESS message from the target eNB follows the same behaviors as defined in 10.1.2.3.1 if with RLC-AM and in 10.1.2.3.2 if with RLC-UM.

Before the source eNB receives the HANDOVER SUCCESS message:

– The source eNB may forward to the target eNB downlink PDCP SDUs with SNs assigned by the source eNB. No downlink PDCP SDU without a SN assigned is forwarded. No uplink PDCP SDU is forwarded.

– The source eNB sends the EARLY STATUS TRANSFER message to maintain HFN continuity by indicating PDCP SN and HFN of the first PDCP SDU that the source eNB forwards to the target eNB. The subsequent messages may be sent for discarding of already forwarded downlink PDCP SDUs in the target eNB.

– The source eNB does not stop transmitting downlink packets to the UE. The source eNB keeps forwarding to the Serving Gateway the uplink PDCP SDUs successfully received in-sequence from the UE.

10.1.2.4 Void

10.1.2.5 Void

10.1.2.6 Void

10.1.2.7 Timing Advance

In RRC_CONNECTED, the eNB is responsible for maintaining the timing advance. Serving cells having UL to which the same timing advance applies (typically corresponding to the serving cells hosted by the same receiver) and using the same timing reference cell are grouped in a timing advance group (TAG). Each TAG contains at least one serving cell with configured uplink, and the mapping of each serving cell to a TAG is configured by RRC. In case of DC, a TAG only includes cells that are associated to the same CG and the maximum number of TAG is 8.

For the pTAG the UE uses the PCell in MCG and the PSCell in SCG as timing reference. In a sTAG, the UE may use any of the activated SCells of this TAG as a timing reference cell, but should not change it unless necessary.

For NB-IoT, the UE uses the anchor carrier as timing reference no matter if the non-anchor carrier is configured or not.

In some cases (e.g. during DRX), the timing advance is not necessarily always maintained and the MAC sublayer knows if the L1 is synchronised and which procedure to use to start transmitting in the uplink:

– as long as the L1 is non-synchronised, uplink transmission can only take place on PRACH.

For a TAG, cases where the UL synchronisation status moves from "synchronised" to "non-synchronised" include:

– Expiration of a timer specific to the TAG;

– Non-synchronised handover.

The synchronisation status of the UE follows the synchronisation status of the pTAG of MCG. The synchronisation status of the UE w.r.t. SCG follows the synchronisation status of the pTAG of SCG. When the timer associated with pTAG is not running, the timer associated with an sTAG in that CG shall not be running. Expiry of the timers associated with one CG does not affect the operation of the other CG.

The value of the timer associated to the pTAG of MCG is either UE specific and managed through dedicated signalling between the UE and the eNB, or cell specific and indicated via broadcast information. In both cases, the timer is normally restarted whenever a new timing advance is given by the eNB for the pTAG:

– restarted to a UE specific value if any; or

– restarted to a cell specific value otherwise.

The value of the timer associated to a pTAG of SCG and the value of a timer associated to an sTAG of an MCG or an sTAG of SCG are managed through dedicated signalling between the UE and the eNB, and the timers associated to these TAGs can be configured with different values. The timers of these TAGs are normally restarted whenever a new timing advance is given by the eNB for the corresponding TAG.

Upon DL data arrival or for positioning purpose, a dedicated signature on PRACH can be allocated by the eNB to the UE. When a dedicated signature on PRACH is allocated, the UE shall perform the corresponding random access procedure regardless of its L1 synchronisation status.

Timing advance updates are signalled by the eNB to the UE in MAC PDUs.

With RACH-less HO, only timing adjustment indication, N_TA=0 or reuse N_TA from a source eNB, are allowed where N_TA denotes a parameter defined in TS36.213 [6] and TS36.211 [4].

10.1.2.8 Dual Connectivity operation

10.1.2.8.1 SeNB Addition

The SeNB Addition procedure is initiated by the MeNB and is used to establish a UE context at the SeNB in order to provide radio resources from the SeNB to the UE. This procedure is used to add at least the first cell (PSCell) of the SCG. Figure 10.1.2.8.1-1 shows the SeNB Addition procedure.

Figure 10.1.2.8.1-1: SeNB Addition procedure

1. The MeNB decides to request the SeNB to allocate radio resources for a specific E-RAB, indicating E-RAB characteristics (E-RAB parameters, TNL address information corresponding to bearer type). In addition, MeNB indicates within SCG-ConfigInfo the MCG configuration and the entire UE capabilities for UE capability coordination to be used as basis for the reconfiguration by the SeNB, but does not include SCG configuration. The MeNB can provide the latest measurement results for the SCG cell(s) requested to be added. The SeNB may reject the request.

NOTE: In contrast to SCG bearer, for the split bearer option the MeNB may either decide to request resources from the SeNB of such an amount, that the QoS for the respective E-RAB is guaranteed by the exact sum of resources provided by the MeNB and the SeNB together, or even more. The MeNBs decision may be reflected in step 1 by the E-RAB parameters signalled to the SeNB, which may differ from E-RAB parameters received over S1.

NOTE: For a specific E-RAB, the MeNB may request the direct establishment of an SCG or a Split bearer, i.e., without first having to establish an MCG bearer.

2. If the RRM entity in the SeNB is able to admit the resource request, it allocates respective radio resources and, dependent on the bearer option, respective transport network resources. The SeNB triggers Random Access so that synchronisation of the SeNB radio resource configuration can be performed. The SeNB provides the new radio resource of SCG in SCG-Config to the MeNB. For SCG bearers, the SeNB provides the new radio resource of the SCG together with S1 DL TNL address information for the respective E-RAB and security algorithm, for split bearers together with X2 DL TNL address information.

NOTE: In case of split bearers, transmission of user plane data may take place after step 2.

NOTE: In case of SCG bearers, data forwarding and the SN Status Transfer may take place after step 2.

3. If the MeNB endorses the new configuration, the MeNB sends the RRCConnectionReconfiguration message to the UE including the new radio resource configuration of SCG according to the SCG-Config.

4. The UE applies the new configuration and replies with RRCConnectionReconfigurationComplete message. In case the UE is unable to comply with (part of) the configuration included in the RRCConnectionReconfiguration message, it performs the reconfiguration failure procedure.

5. The MeNB informs the SeNB that the UE has completed the reconfiguration procedure successfully.

6. The UE performs synchronisation towards the PSCell of the SeNB. The order the UE sends the RRCConnectionReconfigurationComplete message and performs the Random Access procedure towards the SCG is not defined. The successful RA procedure towards the SCG is not required for a successful completion of the RRC Connection Reconfiguration procedure.

7./8. In case of SCG bearers, and dependent on the bearer characteristics of the respective E-RAB, the MeNB may take actions to minimise service interruption due to activation of dual connectivity (Data forwarding, SN Status Transfer).

9.-12. For SCG bearers, the update of the UP path towards the EPC is performed.

10.1.2.8.2 SeNB Modification

The SeNB Modification procedure may be initiated either by the MeNB or by the SeNB and be used to modify, establish or release bearer contexts, to transfer bearer contexts to and from the SeNB or to modify other properties of the UE context within the same SeNB.

The SeNB modification procedure does not necessarily need to involve signalling towards the UE.

MeNB initiated SeNB Modification

Figure 10.1.2.8.2-1: SeNB Modification procedure – MeNB initiated

The MeNB uses the procedure to initiate configuration changes of the SCG within the same SeNB, e.g. the addition or release of SCG SCells, the addition, modification or release of SCG bearer(s) and the SCG part of split bearer(s) and to trigger PSCell change involving PSCell release. The SeNB may reject the request, except if it concerns the release of SCG cells, of SCG bearer(s) or the SCG part of split bearer(s). Figure 10.1.2.8.2-1 shows an example signalling flow for a MeNB initiated SeNB Modification procedure.

NOTE: MeNB may request the establishment or release of SCG or Split bearer while not reconfiguration to MCG bearer, which can be performed without SCG change.

2. The SeNB responds with the SeNB Modification Request Acknowledge message, which may contain radio configuration information within SCG-Config message and data forwarding address information (if applicable). In this step, the SeNB does not initiate an SCG change i.e. the SCG-Config message indicates an SCG Change only if the MeNB included the SCG Change Indication in the SeNB Modification Request message (as an SCG change initiated by the SeNB would subsequently require an SCG counter from the MeNB). In case of SCG Change, for E-RABs configured with the split bearer option for which no bearer type change is performed, the SeNB provides a new DL GTP TEID to the MeNB. The MeNB shall continue sending DL PDCP PDUs to the SeNB with the previous DL GTP TEID until it performs PDCP re-establishment or PDCP data recovery, and use the new DL GTP TEID starting with the PDCP re-establishment or data recovery.

3/4. The MeNB initiates the RRC connection reconfiguration procedure. The UE applies the new configuration and replies with RRCConnectionReconfigurationComplete. In case the UE is unable to comply with (part of) the configuration included in the RRCConnectionReconfiguration message, it performs the reconfiguration failure procedure.

5. Upon successful completion of the reconfiguration, the success of the procedure is indicated in the SeNB Reconfiguration Complete message.

6. If instructed, the UE performs synchronisation towards the PSCell of the SeNB as described in SeNB addition procedure. Otherwise, the UE may perform UL transmission after having applied the new configuration.

7/8. If applicable, data forwarding between MeNB and the SeNB takes place (Figure 10.1.2.8.2-1 depicts the case where a bearer context is transferred from the MeNB to the SeNB).

9. If applicable, a path update is performed.

SeNB initiated SeNB Modification

Figure 10.1.2.8.2-2: SeNB Modification procedure – SeNB initiated

The SeNB uses the procedure to perform configuration changes of the SCG within the same SeNB, e.g. to trigger the release of SCG SCell(s) (other than PSCell), SCG bearer(s) and the SCG part of split bearer(s) (upon which the MeNB may release the bearer or reconfigure it to an MCG bearer), and to trigger PSCell change. The MeNB cannot reject the release request of SCG SCells (other than PSCell), SCG bearer and the SCG part of split bearer. The SeNB cannot initiate an SCG SCell addition except for the case of SI update of an SCG SCell. Figure 10.1.2.8.2-2 shows an example signalling flow for an SeNB initiated SeNB Modification procedure.

1. The SeNB sends the SeNB Modification Required message, which may contain bearer context related, other UE context related information and SCG-Config which contains the new radio resource configuration of SCG. For bearer release or modification a corresponding E-RAB list is included in the SeNB Modification Required message. In case of SCG Change, SCG Change Indication together with SCG-Config are included. In case of release of bearer served by SeNB, SCG-Config is not included.

The SeNB can decide whether the Random Access procedure is required, i.e. SCG change.

2./3. If data forwarding and/or SeNB security key change needs to be applied, the MeNB triggers the preparation of the MeNB initiated SeNB Modification procedure and provides forwarding address and/or a new SeNB security key information within the SeNB Modification Request message, respectively. If the SeNB requested to release a bearer in step 1, and the MeNB decides to reconfigure it to an MCG bearer, the MeNB provides the SCG Change Indication within the SeNB Modification Request message and the SeNB provides respective RRC information in the SCG-Configuration within the SeNB Modification Request Acknowledgement message.

NOTE: When the SeNB Modification Required message contains SCG-Config in step 1, the following MeNB initiated SeNB Modification procedure triggered by the MeNB in step 2 cannot be used for anything that would require a new SCG configuration (as SCG-Config cannot be subsequently signalled by the SeNB).

NOTE: If only SeNB security key (i.e. without SCG Change Indication) is provided in step 2, the MeNB does not need to wait for the reception of step 3 to initiate the RRC connection reconfiguration procedure.

4. If MeNB accepts the SeNB request, the MeNB sends the RRCConnectionReconfiguration message to the UE including the new radio resource configuration of SCG according to the SCG-Config.

5. The UE applies the new configuration and replies the RRCConnectionReconfigurationComplete message. In case the UE is unable to comply with (part of) the configuration included in the RRCConnectionReconfiguration message, it performs the reconfiguration failure procedure.

6. Upon successful completion of the reconfiguration, the success of the procedure related to SCG-Config is indicated in the SeNB Modification Confirm message.

7. If instructed, the UE performs synchronisation towards the PSCell of the SeNB as described in SeNB addition procedure. Otherwise, the UE may perform UL transmission after having applied the new configuration.

8/9. If applicable, data forwarding between MeNB and the SeNB takes place (Figure 10.1.2.8.2-2 depicts the case where a bearer context is transferred from the SeNB to the MeNB).

10. If applicable, a path update is performed.

10.1.2.8.2.1 Intra-MeNB handover involving SCG change

This procedure is used to perform handover within the same MeNB while keeping the SCG in the same SeNB.

Figure 10.1.2.8.2.1-1: Intra-MeNB handover procedure with SeNB configuration

1. The MeNB sends the SeNB Modification Request message, which may contain bearer context related or other UE context related information, data forwarding address information (if applicable) and SCG-ConfigInfo which contains the MCG configuration and the entire UE capabilities for UE capability coordination to be used as basis for the reconfiguration by the SeNB. In case of SCG SCell addition request, the MeNB can provide the latest measurement results for the SCG cell(s) requested to be added and SCG serving cell(s). For E-RABs configured with the split bearer option for which no bearer type change is performed during the SCG Change procedure the MeNB provides a new UL GTP TEID to the SeNB. The SeNB shall continue sending UL PDCP PDUs to the MeNB with the previous UL GTP TEID until it re-establishes the RLC and use the new UL GTP TEID after RLC re-establishment.

3. The MeNB triggers the UE to apply the new configuration including SCG configuration.

4/5. The UE synchronizes to the MeNB.

6. Upon successful completion of the reconfiguration, the success of the procedure is indicated in the SeNB Reconfiguration Complete message.

7. The UE performs synchronisation towards the PSCell of the SeNB as described in SeNB addition procedure.

8/9. Data forwarding between MeNB and the SeNB may take place.

10. If applicable, a path update is performed.

10.1.2.8.3 SeNB Release

The SeNB Release procedure may be initiated either by the MeNB or by the SeNB and is used to initiate the release of the UE context at the SeNB. The recipient node of this request cannot reject.

It does not necessarily need to involve signalling towards the UE, e.g., RRC connection re-establishment due to Radio Link Failure in MeNB.

MeNB initiated SeNB Release

Figure 10.1.2.8.3-1: SeNB Release procedure – MeNB initiated

Figure 10.1.2.8.3-1 shows an example signalling flow for the MeNB initiated SeNB Release procedure.

1. The MeNB initiates the procedure by sending the SeNB Release Request message. If data forwarding is requested, the MeNB provides data forwarding addresses to the SeNB.

2/3. If required, the MeNB indicates in the RRCConnectionReconfiguration message towards the UE that the UE shall release the entire SCG configuration. In case the UE is unable to comply with (part of) the configuration included in the RRCConnectionReconfiguration message, it performs the reconfiguration failure procedure.

NOTE: If data forwarding is applied, timely coordination between steps 1 and 2 may minimize gaps in service provision, this is however regarded to be an implementation matter.

4/5. Data forwarding from the SeNB to the MeNB takes place.

6. If applicable, the path update procedure is initiated.

7. Upon reception of the UE Context Release message, the SeNB can release radio and C-plane related resource associated to the UE context. Any ongoing data forwarding may continue.

SeNB initiated SeNB Release

Figure 10.1.2.8.3-2: SeNB Release procedure – SeNB initiated

Figure 10.1.2.8.3-2 shows an example signalling flow for the SeNB initiated SeNB Release procedure.

1. The SeNB initiates the procedure by sending the SeNB Release Required message which does not contain inter-node message.

2. If data forwarding is requested, the MeNB provides data forwarding addresses to the SeNB in the SeNB Release Confirm message. The SeNB may start data forwarding and stop providing user data to the UE as early as it receives the SeNB Release Confirm message.

3/4. If required, the MeNB indicates in the RRCConnectionReconfiguration message towards the UE that the UE shall release the entire SCG configuration. In case the UE is unable to comply with (part of) the configuration included in the RRCConnectionReconfiguration message, it performs the reconfiguration failure procedure.

NOTE: If data forwarding is applied, timely coordination between steps 2 and 3 may minimize gaps in service provision. This is however regarded to be an implementation matter.

5/6. Data forwarding from the SeNB to the MeNB takes place.

7. If applicable, the path update procedure is initiated.

8. Upon reception of the UE Context Release message, the SeNB can release radio and C-plane related resource associated to the UE context. Any ongoing data forwarding may continue.

10.1.2.8.4 Change of SeNB

The change of SeNB procedure is initiated by MeNB and used to transfer a UE context from a source SeNB to a target SeNB and to change the SCG configuration in UE from one SeNB to another.

Figure 10.1.2.8.4-1: Change of SeNB

Figure 10.1.2.8.4-1 shows an example signalling flow for the Change of SeNB:

1/2. The MeNB initiates the change of SeNB by requesting the target SeNB to allocate resources for the UE by means of the SeNB Addition Preparation procedure. MeNB includes the SCG configuration of the old SeNB in the SeNB Addition Request. If forwarding is needed, the target SeNB provides forwarding addresses to the MeNB.

If RACH-less SeNB Change is configured, the target SeNB includes timing adjustment indication and optionally a preallocated uplink grant in the container.

3. If the allocation of target SeNB resources was successful, the MeNB initiates the release of the source SeNB resources towards the UE and the source SeNB. In case Make-Before-Break SeNB change is configured, the source SeNB decides when to stop transmitting to the UE. If data forwarding is needed the MeNB provides data forwarding addresses to the source SeNB. Either direct data forwarding or indirect data forwarding is used for SCG bearer. Only indirect data forwarding is used for Split bearer. Reception of the SeNB Release Request message triggers the source SeNB to stop providing user data to the UE and, if applicable, to start data forwarding.

4/5. The MeNB triggers the UE to apply the new configuration. The MeNB indicates the new configuration in the RRCConnectionReconfiguration message towards the UE. In case the UE is unable to comply with (part of) the configuration included in the RRCConnectionReconfiguration message, it performs the reconfiguration failure procedure.

If Make-Before-Break SeNB change is configured, the connection to the source SeNB is maintained after the reception of RRCConnectionReconfiguration message with mobilityControlInfoSCG before the UE executes initial uplink transmission to the target cell.

NOTE: The UE can be configured with Make-Before-Break SeNB change and RACH-less SeNB change simultaneously.

6. If the RRC connection reconfiguration procedure was successful, the MeNB informs the target SeNB.

7. The UE synchronizes to the target SeNB.

If RACH-less SeNB Change is configured, the preallocated uplink grant may be included in the RRCConnectionReconfiguration message. If the preallocated uplink grant is not included, the UE should monitor PDCCH of the target SeNB for uplink grant. The SeNB Change procedure is completed for the UE when the UE receives the UE contention resolution identity.

8/9. If applicable, data forwarding from the source SeNB takes place. It may be initiated as early as the source SeNB receives the SeNB Release Request message from the MeNB.

10-14. If one of the bearer contexts was configured with the SCG bearer option at the source SeNB, path update is triggered by the MeNB.

15. Upon reception of the UE Context Release message, the source SeNB can release radio and C-plane related resource associated to the UE context. Any ongoing data forwarding may continue.

10.1.2.8.5 MeNB to eNB Change

The MeNB to eNB Change procedure is used to transfer context data from a source MeNB/SeNB to a target eNB.

Figure 10.1.2.8.5-1: MeNB to eNB Change procedure

Figure 10.1.2.8.5-1 shows an example signalling flow for the MeNB to eNB Change procedure:

1. The source MeNB starts the MeNB to eNB Change procedure by initiating the X2 Handover Preparation procedure. The source MeNB includes the SCG configuration in the HandoverPreparationInformation.

2. The target eNB includes the field in HO command which releases SCG configuration, and may also provide forwarding addresses to the source MeNB. The addition of an SeNB can be initiated only after completing HO.

3. If the allocation of target eNB resources was successful, the MeNB initiates the release of the source SeNB resources towards the source SeNB. If data forwarding is needed, the MeNB provides data forwarding addresses to the source SeNB. Either direct data forwarding or indirect data forwarding is used for SCG bearer. Only indirect data forwarding is used for Split bearer. Reception of the SeNB Release Request message triggers the source SeNB to stop providing user data to the UE and, if applicable, to start data forwarding.

NOTE 1: In case the handover is a conditional handover, step 3 is performed after the source MeNB receives an indication that the UE has successfully accessed one of the potential target eNB (i.e. after step 6).

NOTE 2: In case the handover is a conditional handover, the Data Forwarding Address Indication procedure is executed right after step 2. This Data Forwarding Address Indication informs conditional handover to the source SeNB for which it may decide to perform, if applicable, early data forwarding for SN-terminated bearers, together with the sending of an EARLY STATUS TRANSFER message to the source MeNB. Separate Data Forwarding Address Indication procedures may be invoked to provide different forwarding addresses of the prepared conditional handovers. In this case, it is up to the source MeNB and SeNB implementations to make sure that the EARLY STATUS TRANSFER message(s) from the source SeNB, if any, is forwarded to the right target destination. The Data Forwarding Address Indication procedure may further be invoked to indicate to the SeNB to stop already initiated early data forwarding for some SN-terminated bearers if they are no longer subject to data forwarding due to the modification or cancellation of the prepared conditional handovers. If applicable, the normal data forwarding and SN STATUS TRANSFER message would follow from the source SeNB once it receives SeNB release request of the step 3 that is performed after step 6.

4. The MeNB triggers the UE to apply the new configuration. Upon receiving the new configuration, the UE releases the entire SCG configuration.

5/6. The UE synchronizes to the target eNB.

7/8. If applicable, data forwarding from the source SeNB takes place. It may start as early as the source SeNB receives the SeNB Release Request message from the MeNB.

9-13. The target eNB initiates the S1 Path Switch procedure.

14. The target eNB initiates the UE Context Release procedure towards the source MeNB.

15. Upon reception of the UE CONTEXT RELEASE message, the S-SeNB can release radio and C-plane related resource associated to the UE context. Any ongoing data forwarding may continue.

10.1.2.8.6 SCG change

"SCG change" refers to a synchronous SCG reconfiguration procedure towards the UE involving random access on PSCell. This procedure is used to establish SCG, and can be used to reconfigure the SCG configuration. During SCG change, MAC configured for SCG is reset and RLC configured for SCG is re-established regardless of the bearer type(s) established on SCG. For SCG bearer, PDCP configured for SCG is re-established. In case of reconfiguration from split to MCG bearer, RLC configured for SCG is released. During SCG change, S-KeNB key is refreshed. To perform SCG change within the same SeNB, the SeNB Modification procedure as described in clause 10.1.2.8.2 is used and in this case, the path switch and data forwarding for DRB on SCG may be suppressed. To perform SCG change between different SeNBs, the change of SeNB as described in clause 10.1.2.8.4 is used.

10.1.2.8.7 eNB to MeNB change

The eNB to MeNB change procedure is used to transfer context data from a source eNB to a target MeNB that adds an SeNB during the handover.

Figure 10.1.2.8.7-1: eNB to MeNB change

Figure 10.1.2.8.7-1 shows an example signaling flow for eNB to MeNB change:

1. The source eNB starts the handover procedure by initiating the X2 Handover Preparation procedure.

2. The target MeNB sends SeNB Addition Request to the target SeNB.

3. The target SeNB replies with SeNB Addition Request Acknowledge. If data forwarding is needed, the target SeNB provides forwarding addresses to the target MeNB.

4. The target MeNB includes within the Handover Request Acknowledge message a transparent container to be sent to the UE as an RRC message to perform the handover which also includes the SCG configuration, and may also provide forwarding addresses to the source eNB. Either direct data forwarding or indirect data forwarding is used for SCG bearer. Only indirect data forwarding is used for split bearer.

5. The source eNB triggers the UE to apply the new configuration.

6/7. The UE synchronizes to the target MeNB and replies with RRCConnectionReconfigurationComplete message.

8. The UE synchronizes to the target SeNB

9. If the RRC connection reconfiguration procedure was successful, the target MeNB informs the target SeNB.

10/11. Data forwarding from the source eNB takes place.

12-15. The target MeNB initiates the S1 Path Switch procedure.

NOTE: If new UL TEIDs of the S-GW are included, the target MeNB performs MeNB initiated SeNB Modification procedure to provide them to the target SeNB.

16. The target MeNB initiates the UE Context Release procedure towards the source eNB.

10.1.2.8.8 Inter-MeNB handover without SeNB change

Inter-MeNB handover without SeNB change is used to transfer context data from a source MeNB to a target MeNB while the context at the SeNB is kept.

Figure 10.1.2.8.8-1: Inter-MeNB handover without SeNB change

Figure 10.1.2.8.8-1 shows an example signaling flow for inter-MeNB handover without SeNB change:

1. The source MeNB starts the handover procedure by initiating the X2 Handover Preparation procedure. The source MeNB includes the SCG configuration in the HandoverPreparationInformation. The source MeNB includes the SeNB UE X2AP ID and SeNB ID as a reference to the UE context in the SeNB that was established by the source MeNB in the Handover Request message.

2. If the target MeNB decides to keep the SeNB, the target MeNB sends SeNB Addition Request to the SeNB including the SeNB UE X2AP ID as a reference to the UE context in the SeNB that was established by the source MeNB.

3. The SeNB replies with SeNB Addition Request Acknowledge.

4. The target MeNB includes within the Handover Request Acknowledge message a transparent container to be sent to the UE as an RRC message to perform the handover which also includes the SCG configuration, and may also provide forwarding addresses to the source MeNB. The target MeNB indicates to the source MeNB that the UE context in the SeNB is kept if the target MeNB and the SeNB decided to keep the UE context in the SeNB in step 2 and step 3.

5. The source MeNB sends SeNB Release Request to the SeNB. The source MeNB indicates to the SeNB that the UE context in SeNB is kept. If the indication as the UE context kept in SeNB is included, the SeNB keeps the UE context.

6. The source MeNB triggers the UE to apply the new configuration.

7/8. The UE synchronizes to the target MeNB and replies with RRCConnectionReconfigurationComplete message.

9. The UE synchronizes to the SeNB.

10. If the RRC connection reconfiguration procedure was successful, the target MeNB informs the SeNB.

11/12. Data forwarding from the source MeNB takes place. Data forwarding may be omitted for SCG bearers. Direct data forwarding from the source MeNB to the SeNB is not possible for split bearers.

NOTE: Direct data forwarding may occur only for bearer type change.

13-16. The target MeNB initiates the S1 Path Switch procedure.

NOTE: If new UL TEIDs of the S-GW are included, the target MeNB performs MeNB initiated SeNB Modification procedure to provide them to the SeNB.

17. The target MeNB initiates the UE Context Release procedure towards the source MeNB.

18. Upon reception of the UE Context Release message, the SeNB can release C-plane related resource associated to the UE context towards the source MeNB. Any ongoing data forwarding may continue. The SeNB shall not release the UE context associated with the target MeNB if the indication was included in the SeNB Release Request in step 5.

10.1.2.8.9 Addition of a hybrid HeNB as the SeNB

Figure 10.1.2.8.9-1: Addition of a hybrid cell as serving cell of the SeNB

Figure 10.1.2.8.9-1 shows the signalling flow for the addition of the hybrid cell as serving cell of the SeNB procedure:

1a. The UE is connected to an MeNB and detects a potential candidate cell for dual connectivity.

1b. The UE reads System Information from the candidate cell (csg-Indication, csg-Identity).

1c. The MeNB receives CSG related information from the UE (csg-MemberStatus, csg-Identity).

2. The MeNB initiates the SeNB Addition preparation procedure including Memebership Status of the UE in the hybrid HeNB.

3. The SeNB takes the membership information provided by the MeNB into account (even if this was not yet verified with the MME).

4-7. No difference to the SeNB Addition Preparation procedure as described in 10.2.1.1.

8/9. The MeNB requests the MME to verify the membership status of the UE for the CSG-ID reported by the UE.

– For SCG bearer, the MeNB triggers the E-RAB Modification Indication procedure.

– For split bearer, the MeNB triggers the UE Context Modification Indication procedure.

10-13. If the result of the membership verification requires an update of the UE context at the SeNB, the MeNB triggers the MeNB initiated SeNB Modification Preparation procedure. If the membership verification fails, it is up to the SeNB to decide on further actions.

10.1.2.9 LWA mobility

10.1.2.9.1 Inter-eNB handover without WT change

Inter-eNB handover without WT change is used to transfer context data from a source eNB to a target eNB while the LWA connectivity is kept.

Figure 10.1.2.9-1: Handover without WT change

1. The source eNB starts the handover procedure by initiating the X2 Handover Preparation procedure. The source eNB includes the LWA configuration in the HANDOVER REQUEST: the Mobility Set currently valid for the UE, the WT UE XwAP ID and WT ID as a reference to the UE context in the WT that was established by the source eNB.

2. If the target eNB decides to keep the LWA connection, the target eNB sends WT ADDITION REQUEST to the WT including the WT UE XwAP ID as a reference to the UE context in the WT that was established by the source eNB. The WT shall use this information to check if the UE context is present.

3. If successful, the WT replies with WT ADDITION REQUEST ACKNOWLEDGE.

4. If both, the target eNB and the WT decided to keep the LWA connection in steps 2 and 3 respectively, the target eNB sends the HANDOVER REQUEST ACKNOWLEDGE message, which includes the LWA configuration and the UE LWA Context Kept Indicator, and may also provide forwarding addresses to the source eNB.

5. The source eNB triggers the UE to apply the new configuration.

6a. After the UE applies the target eNB PDCP keys contained in the handover command for UL, the UL end marker packet is sent to WT.

NOTE: The UE can change the DL and UL encryption keys at different times since it can receive an end marker packet at a different time than changing the PDCP key for UL.

6b. WT forwards the UL end marker packet to the source eNB. If WT is able to distinguish the UL end marker packet, it may also forward the end marker packet to target eNB.

6c. When the source eNB has sent the last DL packet to UE, it sends a DL end marker packet to the UE. When UE receives the end marker packet, it starts using the target eNB PDCP keys for decoding of DL packets.

NOTE: The DL end marker packet should be sent before the UE completes the handover, i.e. before step 9.

7. The source eNB sends the WT Release Request to the WT, indicating whether the UE context has been matched at the target. The WT keeps the relevant part of the UE context based on the identification information provided from the target eNB at step 2.

NOTE: The source eNB may postpone sending the WT Release Request until the UE CONTEXT RELEASE is received in step 12.

8-9. The UE synchronizes to the target eNB and replies with RRCConnectionReconfigurationComplete message.

10. The source eNB forwards the SN status to the target eNB.

11-12. The target eNB initiates the S1 Path Switch procedure.

13. The target eNB initiates the UE Context Release procedure towards the source eNB.

NOTE: Some time after the handover without WT change procedure, the target eNB may provide the UE and the WT with new WLAN security information. Based on this information, the UE re-authenticates itself in the WLAN network.

User plane aspects:

Before the source eNB initiates the WT Release Request, the WT is configured with bearer tunnels to both source and target eNB (after WT Addition by the target eNB).

In the downlink, the source eNB forwards end marker packets immediately after the last data packets sent to the WT for a particular bearer, and the WT forwards packets received from either eNB towards the UE. The end marker packets may be used by the UE to switch the PDCP key.

In the uplink, the UE inserts end marker packets to indicate the key switch. The WT may use the end marker packets to infer which packets should be forwarded to source eNB or target eNB. The source eNB may use the end marker packets to infer which packets it should process or discard while the source Xw-u tunnel is operational. The target eNB processes all received packets.

10.1.2.10 EN-DC Operation

Procedures to support EN-DC Operation are described in TS 37.340 [76].