How is the location update managed when the terminal goes from one cell depending on one SGW to another cell depending on another SGW? Or on a different MME ? That is the question we will answer in this video. We’ll take a case, where we have our terminal in the coverage of an eNodeB belonging to the TA 1 tracking zone. This base station depends on an S-Gateway. We have another base station belonging to TA 2, which depends on another S-Gateway. But the two communicate with the same MME. So, the terminal will go from the cell on the top to the cell on the bottom. The terminal is in the state EMM-Registered. Which means that there are tunnels established between the current Serving Gateway and the P‑Gateway, more precisely, a data tunnel and a control tunnel. The fact that the cell phone passes to a different base station means that we will have to modify these tunnels, since it will be necessary to steer them towards the new S‑Gateway. How will we do this? Well, the terminal changes cells, as I said. It will establish a radio connection, then an S1‑AP connection, and we will establish a new tunnel for control between the new S‑Gateway and the MME, and thereby modify the tunnels between the S-Gateway and the P-Gateway. At the end of this procedure, we release the radio connection and the S1‑AP connection. If we look at the message sequence chart of this exchange, the terminal will proceed exactly the same way as earlier. It sends an EMM Tracking area update request message, including its GUTI and the former tracking area where it was earlier. The security procedures can be activated, depending on the operator. And the MME will, once it is sure that the subscriber is authorized, contact the new S‑Gateway, requesting it to modify the SGW-PGW tunnel. It’s the GTP-C Modify Bearer Request message, exchanged between the S-Gateway and the P-Gateway, and its response. Once it’s done, the S‑Gateway acknowledges it by sending a Create Session Response to the MME. Then, the MME acknowledges the request that the UE made by sending EMM Tracking Area Update Accept and requests the former S-Gateway to release the contexts associated with the terminal. There are tunnel identities, a certain number of contexts that are stored. Since the terminal is no longer in the coverage of that S Gateway, it is no longer necessary to store these contexts. The old S6Gateway, once it has erased the context from its memory, acknowledges the request to release the context. And the terminal sends an acknowledgement, when it receives the Tracking Area Update Accept message, message, indicating that it has taken the new list into account and that the update has been correctly carried out. We can note in this exchange that the messages emitted and received by the terminal are the same as when it stays on the same S‑Gateway. The difference is only visible when you look at the exchanges inside the network. Now let’s look at the case where the terminal goes from an eNodeB which is managed by an MME to an eNodeB managed by a different MME. The point to remember is that it’s the MME that allocates the TMSI, Temporary Mobile Subscriber Identity. In our example, the terminal was in the coverage of MME 1 which allocated the TMSI 34‑BE. And only MME 1 knows the link between the TMSI and the complete IMSI of the subscriber. The first thing to come to mind, if we want to simplify the procedures as much as possible, would be that the UE sends its TMSI when it sends the EMM Tracking Area Update Request. If we do that, what happens? Well, MME 2 will receive a Tracking Area Update Request with a TMSI. But MME 2 is not able of determining which subscriber it is. Using the TMSI means we’ll confuse things, not only for any hackers who are listening to the radio interface, but here, also for the network. If we look at the various concepts related to identities in 4G, we have the GUTI, Globally Unique Temporary Identity. And the GUTI is the TMSI plus a code that indicates the MME. That means that we have to indicate not the TMSI, but the GUTI. When the MME receives the Tracking Area Update Request with the GUTI, it can analyze the MME code, figure out which MME was taking care of the terminal just before it arrives in the cell. MME 2 can then deduce that MME 1 has taken care of the UE and it can contact MME 1. MME 2 sends a GTP-C Identification Request message to MME 1 with the TmSI inside the message. MME 1 responds, indicating who the subscriber is, giving his complete IMSI. You can see the importance of securing exchanges between MMEs, in the same way it’s important to secure exchanges between the various entities of the network. Operators therefore have an interest in using cyphering, in order to prevent the IMSI from being picked up by a spy or a hacker. If we look at the tunnel aspect, we won’t get into the details of the procedures, but in the same way as previously, if we imagine that we also change S‑Gateway, we’ll have to modify the existing tunnels, keeping the same P‑Gateway, by changing the S‑Gateway at the end of the procedure. The MME also has an interest in allocating a new TMSI to renew this temporary identity. The location update procedure is defined for all cases. When a UE enters a cell controlled by an eNodeB connected to the same Gateway, or a different SGW, or a different MME. In all cases, the procedure is the same from the UE point of view. The UE puts its GUTI in the TRACKING AREA UPDATE REQUEST message. In the network, when the procedure involves a new MME, the GUTI is analyzed by this MME to find the previous MME. The previous MME sends the IMSI of the UE.
