Comment est gérée la mise à jour de localisation lorsque le terminal passe d'une cellule qui dépend d'un MME par exemple à une cellule qui dépend d'un MME différent ? Ou bien d'un S Gateway différent ? Telle est la question à laquelle nous allons répondre dans cette vidéo. Nous allons prendre un cas, d'abord relativement simple, où nous avons notre terminal qui est sous la couverture d'une station de base eNode B appartenant à la zone de suivi TA 1. Cette station de base dépend d'un S Gateway. Nous avons une autre station de base qui appartient à TA 2, qui dépend d'un autre S Gateway. Mais les deux peuvent communiquer avec le même MME. Le terminal va donc passer de la cellule du haut à la cellule du bas. Si nous regardons l'état, le terminal, nous le supposons attaché correctement au réseau, c'est à dire dans l'état EMM register. Ce qui veut dire qu'il y a un tunnel qui est établi entre le Serving Gateway courant et le P Gateway. Plus précisément, un tunnel de données et un tunnel de contrôle. Le fait que le mobile passe dans une station de base différente fait qu'on va être obligé de rerouter ces tunnels, ou de modifier ces tunnels, puisqu'il va falloir les aiguiller vers le nouveau S Gateway. Comment va -t-on procéder ? Eh bien, le terminal change de cellule, comme je l'ai dit. Il va établir la connexion radio, la connexion S1AP, et on va établir un nouveau tunnel de contrôle entre le nouveau S Gateway et le MME, et modifier donc les tunnels entre S Gateway et P Gateway. A l'issue de la procédure, on libère les connexions radios et les tunnels S1AP. Si nous regardons le chronogramme de cet échange, le terminal va procéder exactement de la même façon que précédemment. Il envoie le message EMM Tracking area update request, en mettant son GUTI et l'ancienne zone de localisation où il se trouvait avant. Les procédures de sécurité peuvent être activées suivant le choix de l'opérateur. Et le MME va, une fois qu'il est sûr que l'abonné est bien autorisé, contacter le nouveau S Gateway en lui demandant de créer un nouveau tunnel. C'est le message GTPC Modify Bearer Request, échangé entre S Gateway et P Gateway, et la réponse associée. Lorsque c'est fait, le S Gateway acquitte en envoyant Create Session Response au MME. Le MME va à ce moment là acquitter la demande qu'a fait le mobile en envoyant EMM Tracking Area Update Accept. Et va demander à l'ancien S Gateway de libérer les contextes qui sont associés au terminal. Il y a des identités de tunnels, un certain nombre de contextes. Puisque le terminal ne se trouve plus sous la couverture de ce S Gateway, il n'est plus nécessaire de mémoriser ces contextes. Le S Gateway, une fois qu'il a vidé le contexte de sa mémoire, acquitte la demande de libération du contexte. Et le terminal va acquitter lui, lorsqu'il reçoit le message Tracking Area Update Accept, en indiquant qu'il a bien pris en compte la nouvelle liste, et la mise à jour est correctement effectuée. Nous pouvons remarquer dans cet échange que les messages émis et reçus par le terminal sont les mêmes que lorsqu'on reste sous le même S Gateway. La différence n'est visible que lorsqu'on regarde les échanges à l'intérieur du réseau. Voyons maintenant le cas où un terminal passe d'un eNode B qui est géré par un MME à un eNode B qui est géré par un MME différent. Le point qu'il faut se rappeler, c'est que c'est le MME qui alloue le TMSI, Temporary Mobile Subscriber Identity. Dans notre exemple, nous avons supposé que lorsque le terminal se trouvait sous la couverture du MME 1, ce MME 1 lui a alloué le TMSI 3 4 BE. Et seul le MME un connaît la correspondance entre le TMSI et l'IMSI complet de l'abonné. La première chose qu'on peut penser, si on veut simplifier au maximum les procédures, c'est de se dire le mobile, lorsqu'il envoie EMM tracking Area Update Request, il va placer son TMSI. Si nous faisons de la sorte, que va-t-il se passer ? Eh bien, le MME 2 va recevoir un message tracking Area Update Request avec un TMSI. Mais le MME 2 n'est pas capable de déterminer de quel abonné il s'agit. Le fait d'utiliser le TMSI fait qu'on brouille les pistes, non seulement pour les personnes éventuelles qui écoutent la voix radio, mais ici aussi pour le réseau. Si nous regardons les différents concepts que nous avons en lien avec les identités en 4 G, nous avons vu qu'il y a le GUTI. Et le GUTI, en simplifiant à l'extrême, c'est un code qui indique le MME plus le TMSI, ça veut dire que l'on est obligé non pas d'indiquer seulement le TMSI, mais le GUTI Globaly Unique Temporary Identity. Ce GUTI contient le TMSI, mais contient surtout le code de MME. Lorsque le MME reçoit ce message Tracking Area Update Request avec le GUTI, il peut analyser le code du MME, déduire le MME qui prenait en charge le terminal qui arrive ici, dans la cellule, et peut à ce moment-là le contacter. Le MME 2 va donc envoyer un message GTPC Identification Request au MME 1 et va placer le TMSI. Le MME 1 va répondre en indiquant de quel abonné il s'agit, en indiquant son IMSI complet. On voit l'importance de bien sécuriser les échanges entre les MME, de la même façon qu'il est important de sécuriser les échanges entre les différentes entités du réseau. Les opérateurs ont donc intérêt à utiliser des mécanismes de chiffrement, pour éviter que l'IMSI puisse être capturé par un espion. Si nous regardons l'aspect tunnel, nous n'allons pas détailler les procédures, mais de la même façon que précédemment, si on suppose qu'on change aussi de S Gateway, il va falloir réétablir un tunnel, ou plutôt modifier le tunnel existant, en gardant le même P Gateway, mais en changeant le S Gateway A l'issue de la procédure, le MME a aussi intérêt à allouer un nouveau TMSI pour renouveler cette identité temporaire.
