We saw in the last video a few things about handovers. The question that we have now is, how does a handover really work in the network? That’s what we’ll see in this video. First, this is the scenario we’re considering: we have our network with an eNodeB, a Serving Gateway, a P-Gateway, an MME and the various tunnels and connections between the nodes. And we’ll consider a terminal that is at first in the coverage of an eNodeB called source eNodeB and is going towards a cell covered by another eNodeB, called target eNodeB. We’re assuming that these two eNodeBs can exchange messages via the X2 interface. The Target eNodeB is controlled by the same MME and connected to the same SGW as the source eNodeB. One small point before going into the procedures, about the protocol stack. Here, we have the protocol stack for access. The diagram is a little involved but it is similar to the protocol stacks we saw in week 4. You can review the last videos of week 4 if you want. The novelty is the X2 interface and the protocol stack between two eNodeBs. This interface is based on IP. Look at the control plane. Above IP, we find SCTP as for the S1 interface and above, we have an X2-AP protocol which is close in many aspects to S1-AP. This protocol is connection-oriented and is used for handover preparation, execution and completion. We also have a user plane with IP, of course, UDP and GTP-U. Now let’s see how handover is processed. We have a terminal that’s exchanging data and the user is moving away from the base station. When the signal received by the terminal is below a certain threshold, the eNodeB will request that the terminal upload the radio measurements made on the current base station and its neighbors. That’s what we see here, the request and the upload of these measurements as they are made. This happens in parallel with the data stream, without interfering with it. If the user continues to move away, the source eNode B will decide to transfer the radio connection, to make a handover, will choose the target eNodeB according to the measures made by the UE. So, the source eNode B sends a handover request, which is an X2-AP message. The target eNode B verifies whether it is capable of accommodating this new UE, that the cell is not saturated, for example. This is admission control. Next the target eNode B chooses a preamble that will be used afterwards in the random access phase. This preamble is sent in the acknowledgement message: Handover Request Acknowledge. Note that a data tunnel is set between the Source eNB and the Target eNB. Hence both eNBs choose TEIDs and send it to the other party on the X2 interface. When the source eNode B receives Handover Request Acknowledge, it knows that it can give the order to the terminal to change cells. It does this with an RRC Connection Reconfiguration message. It indicates the terminal’s new RNTI, the identity of the target eNodeB and the preamble. From that moment on, data that arrives from outside are forwarded on the X2-AP data tunnel. The target eNode B will buffer in memory the packets that arrive. In truth, the terminal is not yet ready to exchange data in the new cell. It must first send the allocated preamble. Next, the target eNode B verifies that it is actually the expected preamble. There is a handshake between the UE and the eNodeB. The UE acknowledges with a RC Connection Reconfiguration Complete message. From the moment this exchange takes place, the radio connection has been re-established. The data stream will then pass from the Serving Gateway to the source eNodeB, from the source eNodeB to the target eNodeB, and from there to the terminal. On the uplink, because the Serving Gateway is the same, the data can be sent directly from the target eNodeB to the Serving Gateway. We can note that, at that moment, the handover has been executed and that the MME is not yet aware of this handover. To re-direct the data correctly, that is, to avoid the forwarding mechanism and have a direct path, the target eNode B must re-establish the tunnel on the downlink between the Serving Gateway and the target eNode B. Because there’s no direct signaling exchange between the target eNode B and the Serving Gateway, the target eNodeB will send a Path Switch Request message to the MME. The goal is that the Serving Gateway be capable of re-establishing this tunnel. This triggers a Modified Bearer Request message sent by the MME. The goal is to exchange the TEID value on the eNodeB side to re-establish the data tunnel between the target-eNodeB and the Serving Gateway. To avoid a situation where messages are in buffers and stay there indefinitely, the SGW sends an END MARKER message to the source eNode B. The source eNodeB then clears its buffer and forwards the message to the target eNode B. No data packet can be sent any longer on the 2-hop path (SGW-SeNB, SeNB-TeNB). Note that this is a very particular case where we have a signaling GTP-U message. The moment the Modified Bearer Request message is received, data transmission on the downlink, and on the uplink, can be made directly. The handover is not completely finished, because the resources on the former cell must be released. The Serving Gateway, acknowledges this request and sends a response to the MME. The MME indicates to the target eNodeB that the re-establishment of direct tunnels has been accomplished. Next, the target eNode B indicates to the source eNode B that it can completely release all the resources, that the UE has been totally picked up (so to speak) in the new cell. Most often, as one would hope, this works out. But from time to time, for example, the target eNodeB is not able to receive a new UE. In that case, the beginning of the scenario is identical to the previous one, but, when the Handover Request message is received, admission control leads to a refusal and a negative acknowledgement Handover Preparation Failure is sent to the source eNodeB. Then, the source eNodeB can try to find out if there’s another eNodeB that would be possible, or it can try to keep the subscriber as long as possible in the former cell. Sometimes, it won’t succeed and the connection will be interrupted. The handover is, as we said, a complex operation with a failure rate that is never zero. In summary, during an X2 handover, an X2-AP connection is set up between the SeNB and the TeNB. It is used by the SeNB to request that the TeNB accommodate the terminal. A GTP-U tunnel is also set up. The source eNB temporarily forwards data packets to the target eNB.
