Nous avons vu, dans la vidéo précédente, qu'au bout d'une certaine période d'inactivité les connexions radio et certains tunnels étaient relâchés. La question qu'on se pose maintenant c'est, puis-je utiliser mon terminal alors que la connexion radio a été libérée ? Ou si j'ai une application qui tourne est-ce que mon terminal peut transmettre rapidement des données après une longue période d'inactivité ? Nous allons considérer le scénario suivant. Un terminal a par exemple été allumé alors qu'il est sous la couverture d'une station de base. Il y a eu établissement de tous les tunnels, ce qui veut dire qu'à l'issue des procédures le ou terminal est en état EMM Registered et en état ECM Connected. Les TEID par exemple utilisé pour les tunnels utilisateurs sont 101 102 côté du Serving Gateway, à nouveau 101 côté du Serving Gateway pour le tunnel entre le Serving Gateway, le PGateway et mettons 32 000 côté du PGateway. Nous supposons que l'utilisateur ne fait rien avec son terminal. Au bout d'un moment il va revenir en état de veille et on va avoir une libération des tunnels, notamment du tunnel S1. Si le terminal ensuite se déplace, ou l'utilisateur plutôt se déplace, et qu'il va dans une cellule qui est ici représentée avec un eNodeB en vert, que se passe-t-il lorsque l'utilisateur veut par exemple consulter une page Web ? On va avoir besoin d'une procédure de rétablissement des connexions et des tunnels, qui soit la plus rapide possible. La première chose auquel on peut penser c'est rétablissons les tunnels après une complète libération. Donc on a des données à transmettre, ou l'application par exemple ou l'utilisateur veut consulter une page Web, on va avoir l'accès aléatoire sur la voie radio, l'allocation d'un RMTI, et au bout d'un échange que le RMTI qui est confirmé. Le terminal va alors envoyer un message qui s'appelle EMM Services Request. Pour dire je veux à nouveau la connectivité pour pouvoir transmettre des données. Ce message est transmis dans un message RRC, connexion set up complete. Il est reçu par l'eNodeB. L'eNodeB va rétablir la connexion SA1P en même temps qu'elle envoie un message EMM Service Request, avec KSI, ce sont les données liées aux clés de sécurité. Le MME vérifie que la monnaie est autorisée et va demander le rétablissement des différents supports radio, des différentes connexions radio avec la gestion de qualité de service. S'il y a de la qualité de service. L'eNodeB va choisir une valeur de TUID, par exemple 16 538, c'est un eNodeB différent du précédent. Le précédent avait choisi 101, mais ce n'est pas connu par cet ENodeB, donc la valeur est complètement différente. Cette valeur va être envoyée dans le message S1AP contexte, initial contexte Set up complete, et le MME va renvoyer un message GTPC Modified Error Request avec le TUD, pour demander l'établissement du tunnel entre l'eNodeB et le Serving Gateway. Le Serving Gateway va choisir un TUID et on est obligé d'avoir un message du Serving Gateway vers le MME, du MME vers l'eNodeB, pour renvoyer à l'eNodeB la valeur choisie pour le tunnel entre l'eNodeB et le Serving Gateway. Ça, se sont des messages qui rallongent très légèrement, mais ce n'est quand même pas négligeable, la procédure. Donc on va essayer de faire un petit peu plus subtil pour rétablir les différents bearers. Lorsque l'on reprend le scénario, étant donné que tous les messages d'établissements du tunnel initial passent par le MME pour ce qui concerne le tunnel sur l'interface S1, le MME a la possibilité de mémoriser la valeur du TUID utilisé par le Serving Gateway pour le tunnel S 1. Cette valeur est donc mémorisée, et lorsqu'on libère la connexion sur "inactivité radio", on ne va en fait pas complètement libérer le tunnel. On va garder en mémoire cette valeur de TUID 102. Ce qui fait que lorsque le mobile va apparaître dans une autre cellule eh bien cette valeur de TUID est réutilisée pour le nouveau tunnel. Ainsi, lorsqu'on rétablit le tunnel on va éviter des échanges de messages entre le MME et le Serving Gateway. Voyons comment cela se passe. Le début de la procédure est le même. Dans ce transparent pour souligner que le MME garde en mémoire certaines choses on montre que le TUID 102, cette valeur est stockée par le MME, et la valeur est considérée comme toujours allouée par le Serving Gateway. Le mobile a des données à transmettre, on a un accès aléatoire allocation d'un RMTI comme précédemment, établissement de la connexion radio, confirmation du RMTI comme précédemment. On voit du Service Request avec les données de sécurité. Et comme précédemment établissement de la connexion S1AP, qui est une nouvelle connexion, entre l'eNodeB où se trouve le terminal et Le MME. Le MME vérifie que l'abonné est autorisé et il va pouvoir répondre directement en envoyant le TUID 102 à l'eNodeB. De cette façon l'eNodeB a un tunnel qui est rétabli là sur la voie montante, puisqu'il connaît le TUID utilisé par le Serving Gateway, il peut donc envoyer facilement les messages en mettant le TUID du destinataire. Ici le TUID alloué par le Serving Gateway. La connexion radio est rétablie, l'eNodeB va choisir son TUID, qui lui est propre à son système de référence, va envoyer ensuite un message S1AP, Set up Complete, avec la valeur du TUID, et cette valeur va être stockée par le Serving Gateway. À la suite de cet échange le tunnel S1, le Bearer S1, est complètement rétabli. Mais on peut voir que très rapidement dès cette phase-là les données à transmettre ont pu être envoyées sur la connexion radio et sur le tunnel S1. On a donc une procédure qui permet de rétablir rapidement la connexion. Mais cette procédure va quand même prendre quelques dizaines de millisecondes, jusqu'à cent millisecondes typiquement.
