Page 279 - From GMS to LTE

Long Term Evolution (LTE) and LTE-Advanced Pro 265

on the S1 interface, but as only the eNode‐B is exactly aware of the time the handover
takes place it ensures the smoothest handover possible.
Once the mobile device has contacted the target eNode‐B with a contention‐free
random access procedure, that is, the resources allocated for the random access are
dedicated to the mobile device and hence no identification of the mobile is neces-
sary, the target eNode‐B contacts the MME and confirms the handover with a
Handover Notify message. The MME then redirects the downlink user data tunnel to
the target eNode‐B by modifying the eNode‐B tunnel ID of the bearer context on the
Serving‐GW with a Modify Bearer Request message. Once the operation is con-
firmed, the MME then releases the user’s context in the source eNode‐B with a UE
Context Release message, which is answered with a UE Context Release Acknowledge
message.
In the final step, the indirect forwarding tunnel on the Serving‐GW is also removed.
At this point, all resources that are no longer needed are removed and the user data
flows directly to and from the target eNode‐B.
While from a mobile device’s point of view this handover takes slightly longer than a
pure X2 handover, which is a bit less complicated and requires fewer messages between
the different entities in the network, an S1 handover is also executed within just a few
hundred milliseconds. Owing to the optional user data rerouting during the handover
procedure itself the outage experienced by the mobile device is further minimized.
Also, as previously stated, the complexity of a handover in the network is completely
hidden from the mobile device as it only sees the RRC Reconfiguration message and
then uses the random access procedure to get access to the new cell, independently of
whether the handover is executed over the X2 or S1 interface.
Not shown in the X2 and S1 handover examples above is a potential tracking area
update procedure that has to be executed by the mobile device after the handover in
case the target eNode‐B is part of a new tracking area. This is necessary so that the
network can locate the mobile device when the eNode‐B later decides to remove the
physical connection to the device because of prolonged inactivity. This concept is
described in more detail in Section 4.7.2 on mobility management and cell reselection
in the RRC idle state.

MME and S‐GW Changes
In the X2 and S1 handover examples above, no core network node changes were shown.
Under some circumstances, however, these have to be changed during or after a hando-
ver as well:
for load balancing, processing and user‐plane capacity reasons;
●
to optimize the user data path between the radio network and the core network;
●
when the target eNode‐B is in a tracking area that is not served by the source MME.
●
In such cases, the handover processes described above are extended with additional
procedures to include the network elements becoming newly responsible for the con-
nection in the overall process. From a mobile device’s point of view, however, this is
transparent and just increases the time between the initial measurement report and the
execution of the handover with the RRC Reconfiguration message. For further details,
refer to 3GPP TS 23.401 [18].