LTE Handovers Process
This procedure is used to set up necessary resources on an eNodeB for handover.
UE-related signaling is required in this procedure.
Handover preparation (successful operation)
The source eNodeB sends the target eNodeB a HANDOVER REQUEST message to initiate the procedure. When the source eNodeB sends the message, it starts the TRELOCprep timer.
The resource allocation according to the values of the Allocation and Retention Priority IE must follow the principles described for the E-UTRAN radio access bearer (E-RAB) Setup procedure in TS36.413.
The source eNodeB contains in the GUMMEI IE any GUMMEI corresponding to the serving mobility management entity (MME).
If a minimum of one requested non-GBR E-RAB is admitted to the cell indicated by the Target Cell ID IE, the target eNodeB reserves necessary resources, and sends the source eNodeB a HANDOVER REQUEST ACKNOWLEDGE message. The target eNodeB includes the E-RABs for which resources have been prepared at the target cell in the E-RABs Admitted List IE. In addition, the target eNodeB includes the E-RABs that have not been admitted in the E-RABs Not Admitted List IE with an appropriate cause value.
After receiving the HANDOVER REQUEST message, the target eNodeB performs the following operations:
Prepares the configuration of the AS security relationship between UEs and the target eNodeB using the information in the UE Security Capabilities IE and the AS Security Information IE in the UE Context Information IE.
For each E-RAB for which the source eNodeB requests to forward downlink data, the source eNodeB must include the DL Forwarding IE within the E-RABs To be Setup Item IE in a HANDOVER REQUEST message. For each E-RAB that it has decided to admit, the target eNodeB includes the DL GTP Tunnel Endpoint IE within the E-RABs Admitted Item IE in a HANDOVER REQUEST ACKNOWLEDGE message. This indicates that the target eNodeB accepts the requested forwarding of downlink data for this bearer. Based on the implementation choice, the GPRS tunneling protocol (GTP) tunnel endpoint may be different from the corresponding GTP TEID IE within the E-RAB To Be Switched in Downlink List IE in a PATH SWITCH REQUEST message. For details, see TS36.413.
For each bearer in the E-RABs Admitted List IE, the target eNodeB uses the UL GTP Tunnel Endpoint IE to indicate that it requests to forward uplink packet data on a specific bearer.
After receiving the HANDOVER REQUEST ACKNOWLEDGE message, the source eNodeB stops the TRELOCprep timer and starts the TX2RELOCoverall timer to terminate the Handover Preparation procedure. The source eNodeB is then defined to have a prepared handover related to the X2 UE-related signaling.
If the Trace Activation IE is included in a HANDOVER REQUEST message, the target eNodeB starts to request the tracing function, as described in TS 32.422  if it supports this function.
If the Handover Restriction List IE meets the following conditions:
l It is included in a HANDOVER REQUEST message. The target eNodeB stores information received in the Handover Restriction List IE in the UE context, and uses the information to determine a target cell for the UEs during subsequent handover attempts, except when one of the E-RABs has some particular Address Resolution Protocol (ARP) values (TS 23.401 ). In this case, the information does not apply.
l It is not included in a HANDOVER REQUEST message. The target eNodeB considers that no roaming, no area, and no access restriction apply to the UE.
If the Location Reporting Information IE is included in a HANDOVER REQUEST message, the target eNodeB initiates the requested location reporting function, as defined in TS 36.413 .
If the SRVCC Operation Possible IE is included in a HANDOVER REQUEST message, the target eNodeB stores the SRVCC Operation Possible field in the UE context and uses it as defined in TS 23.216 .
If the UE Security Capabilities IE included in a HANDOVER REQUEST message contains only the EIA0 algorithm as defined in TS 33.401  (assume that the EIA0 algorithm is defined in the configured list of allowed integrity protection algorithms in the eNodeB (TS 33.401 ), the eNodeB takes the IE into use and ignores the keys received in the AS Security Information IE.
A HANDOVER REQUEST message must contain the Subscriber Profile ID for RAT/Frequency priority IE, if available.
If the Subscriber Profile ID for RAT/Frequency priority IE is included in a HANDOVER REQUEST message, the target eNodeB stores the information and the uses the information as defined in TS 36.300 .
After receiving the UE History Information IE from the HANDOVER REQUEST message, the target eNodeB collects mandatory information in the UE History Information IE (on condition that the UE stays in one of its cells) and stores the collected information to be used for future handover preparations.
If the target eNodeB does not admit a minimum of one non-GBR E-RAB, or a failure occurs during the Handover Preparation procedure, the target eNodeB sends the source eNodeB a HANDOVER PREPARATION FAILURE message. The message must contain the Cause IE with an appropriate value.
If the target eNodeB receives a HANDOVER REQUEST message containing the RRC Context IE that does not include required information as specified in TS 36.331 , the target eNodeB sends the source eNodeB a HANDOVER PREPARATION FAILURE message.
Interactions During Handover Cancelation Procedure
If the source eNodeB does not receive the HANDOVER REQUEST message from the target eNodeB before the TRELOCprep timer expires, the source eNodeB cancels the Handover Preparation procedure towards the target eNodeB by initiating the Handover Cancelation procedure with an appropriate value for the Cause IE. The source eNodeB ignores any HANDOVER REQUEST ACKNOWLEDGE or HANDOVER PREPARATION FAILURE message received after the initiation of the Handover Cancelation procedure, removes any reference, and releases any resources related to the X2 UE-related signaling.