Que se passe-t-il si je n'utilise pas pendant une longue période, typiquement une dizaine de secondes ou quelques dizaines de secondes, les fonctions radio de mon terminal, c'est-à -dire que par exemple je ne regarde pas de site Web ou je n'ai pas une application qui fait appel au réseau. Nous connaissons la réponse nous allons avoir un passage de l'état d'ECM-Connected avec la connexion radio, à un état ECM-IDLE où il n'y a plus de connexions radio. Nous représentons ici l'état initial que nous considérons. Le terminal a l'ensemble des tunnels et des connexions établis, y compris la connexion radio, il est en état ECM-Connected et le MME a la mémorisation de cet état ECM Connected, correspondant au terminal que nous considérons. Nous voyons la procédure de libération. Nous supposons que le terminal est déjà connecté, il a les bearers et les différents tunnels qui sont établis. Il est inactif, c'est-à -dire qu'il n'y a pas de transmission de paquets utilisateurs pendant un certain temps. Au bout de ce temps-là typiquement cinq, dix, quinze secondes, l'eNodeB va envoyer un message, S1AP, demandant la libération du contexte. Il va indiquer la cause: inactivité d'utilisateurs. Le MME va à ce moment-là envoyer un message GTP de contrôle, pour demander la libération du tunnel entre le SGW et l'eNodeB. Le SGW prend en compte la demande, exécute, répond positivement au MME, que la libération est faite, et le MME va informer l'eNodeB que cette libération est à faire de son côté. L'eNodeB informe le terminal que la connexion est libérée. Le terminal va retourner en veille côté radio. Si l'utilisateur est en train de jouer et que c'est une activité qui ne génère pas d'échange radio, le terminal reste actif. Mais d'un point de vue Radio il est inactif. Il considère que le RNTI n'est plus alloué, donc il ne peut plus utiliser le RNTI, et l'eNodeB libère la connexion radio et le RNTI. Une fois que c'est fait l'eNodeB répond au MME pour indiquer que la libération est complètement effectuée. À l'issue de cette procédure le terminal et le MME pour ce terminal reviennent à l'état ECM-IDLE. Par contre, le terminal garde son adresse IP, c'est-à -dire qu'il est toujours dans l'état EMM-Registered. On a donc deux types d'états: les États ECM et les états EMM. Dans l'état EMM-Deregistered le terminal n'existe pas vu du réseau, donc il est forcément dans l'état ECM-IDLE. Il est non-connecté au réseau il n'a pas d'adresse IP. Dans l'état EMM-Registered et EMM-Connected le terminal est connecté au réseau, il a une adresse IP, sa localisation est connue à la cellule près par le MME, le terminal 1-RNTI et tous les tunnels et les connexions sont établis. Dans l'état EMM-Registered et ECM-IDLE vu des applications, vu de l'utilisateur, il est toujours connecté. Le terminal est donc apparemment connecté au réseau, il a son adresse IP, mais il n'a pas de RNTI alloué. Il n'y a pas de tunnel ni de connexion partant de l'eNodeB. En revanche le tunnel entre le Serving Gateway et le P Gateway, et le tunnel entre le Serving Gateway et le MME est maintenu. Pourquoi ? Parce qu'un Serving Gateway gère une large zone et que la probabilité de changer de Serving Gateway en quelques minutes est relativement faible. Dans cet état, EMM Registered, ECM-IDLE, la localisation est vague au niveau de l'UE, le réseau ne se préoccupe pas de savoir dans quelle cellule précise se trouve le terminal. Nous avons donc la visualisation suivante: Lorsque le mobile est complètement absent du réseau, il n'est pas associé à un Serving Gateway ou P Gateway, donc j'en ai dessiné plusieurs sur le schéma. Lorsqu'on s'attache au réseau on passe en état EMM-Registered et ECM-Connected, il y a une connexion ERRC, tous les tunnels sont établis. Au bout d'un temporisateur d'inactivité on va repasser en état ECM-IDLE, mais tout en restant en état EMM-Registered, c'est-à -dire qu'on garde l'adresse IP.
