Page 277 - From GMS to LTE

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

without any detour over the source eNode‐B. Downlink data that continues to be for-
warded from the source eNode‐B to the target eNode‐B can now also be delivered to the
mobile device. In the radio and core network, however, additional steps are required to
redirect the S1 tunnel from the source eNode‐B to the target eNode‐B. Figure 4.20 shows
the simplest variant, in which the MME and Serving‐GW do not change in the process.
The S1 user data tunnel redirection and an MME context update are invoked with a
Path Switch Request message that the target eNode‐B sends to the MME. The MME
then updates the subscriber’s mobility management record and checks if the target
eNode‐B should continue to be served by the current Serving‐GW or if this should be
changed as well, for example, for better load balancing or to optimize the path between
the core network and the radio network. In this example, the Serving‐GW remains the
same, so only a Modify Bearer Request message has to be sent to the current Serving‐
GW to inform it of the new tunnel endpoint of the target eNode‐B. The Serving‐GW
makes the necessary changes and returns a Modify Bearer Response message to the
MME. The MME in turn confirms the operation to the target eNode‐B with a Path
Switch Request Acknowledge message. Finally, the target eNode‐B informs the source
eNode‐B that the handover has been performed successfully and that the user data
tunnel on the S1 interface has been redirected with a Release Resource message. The
source eNode‐B can then delete the user’s context from its database and release all
resources for the connection.

S1 Handover
It is also possible that the source eNode‐B is not directly connected to the target eNode‐
B, so a direct X2 handover is not possible. In such cases, the source eNode‐B requests
the help of the MME. All signaling exchanges and user data forwarding are then per-
formed over the S1 interface as shown in Figure 4.21. Consequently, such a handover is
referred to as an S1 handover.
From a mobile device point of view, there is no difference between an X2 and an S1
handover. When radio conditions trigger a measurement report, the source eNode‐B
can decide to initiate the handover. As the X2 link is missing, it will send a Handover
Request message to the MME. On the basis of the Tracking Area ID of the new eNode‐B,
the MME can decide if it is responsible by itself for the new cell or if another MME
should take over the connection. In the scenario shown in Figure 4.21, the same MME
remains responsible for the connection so that no further messaging is required at this
stage to contact another MME. In this example, the MME also decides that the current
Serving‐GW remains in the user data path after the handover so that no further signaling
is required.
In the next step, the MME contacts the target eNode‐B with a Handover Request
message. If the eNode‐B has enough capacity to handle the additional connection, it
returns a Handover Request Acknowledge message to the MME which, as in the previ-
ous examples, contains all the parameters required for the mobile device to make the
handover. This includes information on dedicated resources in the uplink direction to
perform a non‐contention‐based random access procedure to speed up the handover.
For details, see the description of the X2 handover above.
Before the handover can be executed, a temporary tunnel for downlink user data is
established to ensure that no packets are lost during the handover. There are two options
for forwarding data during an S1 handover. Even if no signaling message exchange is