Mobility Management Signaling

Intra-RAT (inter-eNB) handovers are handled by the X2 interface unless any of the following conditions are true:

• No X2 interface between the source and target eNBs.
• The source eNB has been configured to initiate handover to the particular target eNB via the SI interface in order to enable the change of en an EPC node (MME and/or Serving GW).
• The source eNB has attempts to start an inter-eNB handover via X2 but receives a negative reply from the target eNB with a specific cause value.
• The serving PLMN changes during handover.

The S1 interface handles inter-RAT handovers. It also handles handovers from and to HeNBs.

In what follows, the relevant signaling for the X2 and S1 interfaces are described.

X2 Mobility Management

Elementary procedures for mobility management in the X2 interface include: Handover Preparation; SN Status Transfer; UE Context Release; and Handover Cancel.

Handover Preparation involves the source eNB sending a Handover Request to the target eNB. When the target eNB receives the request, it performs an admission control request based on the resources indicated to be required for the UE's radio bearers. If sufficient resources are available, the target eNB acknowledges the request with a Handover Request Acknowledge. If not, the target eNB sends a Handover Preparation Failure message to the source eNB. This terminates that Handover Preparation procedure. If beyond a certain time the source eNB does not receive an indication of either an acknowledge or a failure, it sends a handover Cancel and indicates the cause as expired timer. If a source eNB sends cancels a handover requests, it disregards further messages from the target eNB.

The SN Status Transfer message is used to transfer the uplink PDCP SN and HFN receiver status and the downlink SN and HFN transmitter status from the source to the target eNB during an X2 handover for each respective E-RAB for which the PDCP SN and HFN status preservation applies. The status message includes information on missing and received uplink SDUs, and for downlink flows for which it has received reports on missing and received SDUs.

The release of UE context, by which the source eNB release all information relative to a UE, is made by the target eNB sending a UE Context Release to the source eNB. It is also an indication of handover success. It is possible, however, that the source eNB would retain the UE's context after receiving the context release message in case of failure.

The Handover Cancel message is sent by the source eNB to the target eNB to cancel an ongoing handover preparation or an already prepared handover. The cancel message carries reason for cancellation. Upon receiving the message, the target eNB releases any resources or context relevant to the UE.

There are two possible X2-based handovers: without or with Serving GW relocation. Figure 13.5 shows the procedure for an X2-based handover where the MME decides that the Serving GW will not be changed.

After Handoff preparation and execution, which were described above, the Handover Completion stage entails the target eBN sending a Path Switch Request. A request and response for modifying the UE's radio bearers are then processed by the Serving GW and, in turn, the PDN GW. Once complete, the Serving GW responds to the path switch request by redirecting the UE's downlink data, sending an end marker to the source eNB. In turn, the source eNB sends another end marker to the target eNB and the MME acknowledges the target eNB's path switch request. Finally, the target eNB sends a Context Release message to the source eNB.

Figure 13.5 X2-based handover without relocating serving GW. Reproduced by permission of © 2010 3GPP. Further use is strictly prohibited.

When the Serving GW is relocated during an X2-based handover, additional messages are exchanged between the MME and both the source and the target Serving GWs. First, the MME establishes a session with the target Serving GW, which in turn exchanges the bearer modification messages with the PDN GW. The MME then acknowledges the target eNB's path switch request, and deletes the session with the source serving GW. Meanwhile, the target eNB would send the source eNB a Context Release message.

Figure 13.6 A General S1-based handover. Reproduced by permission of © 2010 3GPP. Further use is strictly prohibited.

S1 Mobility Management

S1 mobility management oversees handovers that cannot be initiated by the X2 interface. They also handle HeNB handovers inter-RAT handovers.

There are several handover related signaling in the S1 interface. Handover Required, Handover Request, Handover Notify, Path Switch Request, Handover Cancel, eNB Status Transfer, and MME Status Transfer.

A Handover Required is sent by the source eNB to the MME to initiate an S1 handover preparation phase. If the MME judges that the handover can be realized, it sends a Handover Command. Otherwise, it sends a Handover Preparation Failure. When processing the Required message, the MME considers the source and target eNBs (their RATs, frequencies, resources) and the UE capabilities. Consideration for access control for HeNB are also made at the MME. An indication of a successful handoff is sent by the target eNB to the MME using a Handover Notify message.

An MME performs a handover resource allocation by sending a Handover Request message to a target eNB. Upon receiving the request message, the target eNB makes the appropriate resource allocation, context preparation and relevant security authentications for the UE. If the target eNB is unable to admit the UE, it responds with a Handover Failure message.

The Path Switch Request message is exchanged between the eNB and the MME for the MME to process the path switch with the core. Both status transfer exchanges (the eNB and MME Status Transfer) indicate the PDCP SN and HFN status in the uplink and the downlink. Finally, a handover initiated by a source eNB can be cancelled at any time for an ongoing or a prepared for handover using a Handover Cancel message. Upon receiving the cancel message, the MME would acknowledge the cancellation and initiate relevant release and removal procedures.

A general S1-based handover is shown in Figure 13.6.