We saw, in the previous video, that, after a certain period of inactivity the radio connections and a few tunnels or connections are released. The question we must ask now is: can I use my terminal once the radio connection has been released? Or, if I have an application running, can my terminal transmit data rapidly after a long period of inactivity? We’re going to consider the following scenario. A terminal has, for example, been turned on. All the tunnels were established, which means that, at the end of the attach procedure, the terminal is in EMM-Registered ECM-Connected state. The TEIDs used for the data bearers are 101 on the eNodeB side, 102 on the Serving Gateway side, again 101 for the tunnel between the Serving Gateway and the P-Gateway and 32,000 on the P-Gateway side. We assume that the user has not done anything with his terminal. After a moment, it will return to standby mode and the tunnels will be released, especially the S1 tunnel. If the user then moves and goes into the cell represented here with a green eNodeB, what happens when the user wants to, for example, load a Web page? We’re going to need a procedure to re-establish connections and tunnels that is as fast as possible. The first thing that comes to mind is: let’s re-establish the tunnels after everything has been released. So, there are data to transmit. For example, the application sends a request to a Web server, it will make a random access procedure on the radio interface, an RNTI is allocated, and after a handshake, the RNTI is confirmed. The terminal then sends a message called EMM Service Request to say, “I want connectivity again to transmit data.” This message is transmitted in an RRC message, connection set up complete. It is received by the eNodeB. The eNodeB will re-establish the S1-AP connection. At the same time it sends an EMM Service Request message, with KSI (data related to security keys). The MME checks to see if the subscriber is authorized and requests the re-establishment of various radio bearers, various radio connections with the management of quality of service (if there is quality of service). eNodeB2 selects a value for TEID, for example 16,538. eNodeB1 had chosen 101, but this eNodeB2 is unaware of that, so the value is completely different. Before it was 101, now it is is 16,538. This value (16,538) is sent in the S1-AP Initial Context Set up complete message and the MME sends back a GTP-C Modify Bearer Request message with the TEID, to request the establishment of the tunnel between the eNodeB and the Serving Gateway. The Serving Gateway chooses a TEID. This TEID should be sent back to the eNodeB. So there must be a message from the Serving Gateway to the MME, from the MME to the eNodeB. These messages make the procedure longer. Even if the additional time is small (several dozens ms), the effect isn’t negligible. So, we’ll try to be a bit more subtle when re-establishing the various bearers. When we look at the scenario, given that all the messages for the establishment of the initial tunnel go through the MME, the MME can memorize the TEID used by the Serving Gateway for the S1 tunnel. So, this value is memorized and when we release the connection because of “radio inactivity,” we do not completely release the S1 tunnel. We’ll retain the TEID value of 102. This means that, when the cell phone reappears in another cell, this TEID is reused for the new tunnel. So, when the tunnel is re-established, we will avoid message exchanges between the MME and the Serving Gateway. Let’s see how that works. The beginning of the procedure is the same. In this slide, to underscore that the MME retains in memory some things, we show that the TEID value is stored by the MME, and this value is considered as still allocated by the Serving Gateway. The cell phone has data to transmit: we have random access, the allocation of an RNTI like earlier, the establishment of a radio connection, confirmation of the RNTI like earlier, sending a Service Request with security data, and like earlier, the establishment of the S1-AP connection: a new connection, between the eNodeB where the terminal is located and the MME. The MME verifies that the subscriber is authorized and he can respond directly by sending the TEID 102 to the eNodeB. This way, the eNodeB has a tunnel which has been re-established, on the uplink, because it knows the TEID used by the Serving Gateway; it can then easily send data using the TEID of the recipient (here the TEID allocated by the Serving Gateway). The radio connection is re-established, the eNodeB chooses its TEID (in accordance with its own system of reference), then sends an S1-AP Set up Complete message, with the value of the TEID, and this value will be stored by the Serving Gateway. At the end of this exchange, the S1 tunnel and the S1 Bearer are completely re-established. But we can see that, very rapidly, from this phase on , data to transmit could be sent on the radio connection and on the S1 tunnel. So, we have a procedure that enables us to rapidly re-establish the connection. This procedure will still take a few tens of milliseconds, up to one hundred milliseconds, typically. To summarize, after radio inactivity, the S1 bearer is only PARTIALLY released. The TEID values are stored by the MME. A procedure called UE Triggered service request is defined to re-establish as quickly as possible the bearers and the connections.
