Si je n'utilise pas mon terminal pendant quelques dizaines de secondes, celui-ci va revenir en état de repos par rapport à la connexion radio. Si un serveur veut au bout de quelques minutes m'envoyer un paquet, peut-il le faire alors que ma connexion radio n'est plus active ? Telle est la question à laquelle nous allons répondre dans cette vidéo. Nous avons vu dans les vidéos précédentes qu'un mobile qui est attaché au réseau, c'est à dire qui a une adresse IP, est dans l'état EMM Registered. S'il est inactif, il est dans l'état ECM Idle. Lorsque l'utilisateur veut faire quelque chose sur son terminal, cela va provoquer l'émission d'un paquet du terminal vers le réseau et cela enclenche une procédure UI Triggered Service Request, Demande de Service par le terminal où on a le rétablissement de la connexion radio ou de la connexion S1AP et du tunnel entre l'eNode B et S. Gateway. Il y a une autre procédure qui est définie, qui s'appelle Network Triggered Service Request. Lorsqu’un paquet arrive du réseau extérieur, et bien il faut pouvoir rétablir la connexion. Par exemple si on fait de la téléphonie sur IP on utilise en général le protocole SIP, Session Initiation Protocol, et ce protocole dispose d'un message pour appeler un terminal. On peut avoir aussi d'autres applications qui provoquent régulièrement l'envoi de messages par le réseau, par un serveur. On a donc défini cette procédure où l'initiative vient du réseau extérieur. A la fin de la procédure, que ce soit UI Triggered Service Request ou Network Triggered Service Request, le mobile est dans l'état EMM Registered, ça, ça ne change pas, et ECM Connected, ça, c'est différent. Voyons l'état initial. Nous considérons donc la situation suivante, avec les tunnels représentés sur ce dessin. Entre S. Gateway et P.Gateway les tunnels sont maintenus. Le tunnel entre S. Gateway et MME est maintenu. Et une extrémité du tunnel partant du S.Gateway est maintenue quand on considère le tunnel entre l'eNode B et le S.Gateway. Le mobile est en état inactif au niveau ECM, par contre il est toujours attaché au réseau, c'est à dire qu'il a une adresse IP et toutes les identités, identités temporaires, qui s'ensuivent. Ce qui va déclencher le mécanisme, c'est qu'on a un serveur sur un réseau externe qui envoie un paquet de données. Ce paquet de données est reçu par le P. Gateway. Le P. Gateway dispose bien du tunnel de données. Il va donc envoyer le paquet vers le Serving Gateway. C'est ce que nous voyons sur la figure suivante. Le S. Gateway, lui, même s'il a mémorisé une partie, gardé le TUID en mémoire, il n'a pas un tunnel réellement actif. Donc il va demander au MME d'établir la connexion. Le MME, nous le verrons dans la semaine de gestion de la mobilité, a une connaissance vague de la localisation du terminal. Il ne sait pas exactement dans quel eNode B se trouve le mobile lorsqu'il est dans l'état ECM Idle. Ce qu'il va faire, c'est envoyer un message qui s'appelle un message de Paging à toutes les cellules où est susceptible de se trouver le terminal. Ce message de Paging contient le TMSI, l'identité temporaire du terminal. Le terminal est de toute façon en permanence à l'écoute du réseau, à l'écoute de ce qui est envoyé. Si jamais il voit passer son TMSI accompagné d'un message de Paging, là il se réactive. Le terminal, là où il se trouve, va donc répondre à cette demande. C'est ce que nous allons voir dans le scénario d'échange de messages. Le paquet IP vient de l'extérieur. Nous avons le Bearer qui est établi entre Serving Gateway et P.Gateway et puis nous avons le TUID, par exemple 102, qui est réservé encore pour le tunnel. Le paquet IP est transmis par le P.Gateway vers le S. Gateway. Ce paquet ne peut pas être délivré immédiatement. Il va donc être stocké. S'il y a des paquets ultérieurs, ces paquets vont être mis dans une file d'attente, vont être stockés en mémoire. Le S. Gateway va demander au MME de réactiver la connexion en envoyant Downlink Data Notification. En d'autres termes cela veut dire "j'ai des données qui sont en attente, que je ne peux pas livrer. Occupe-toi de me retrouver le terminal." Le MME connaît la localisation imprécise de l'abonné et va envoyer un message qui s'appelle S1AP Paging, avec le TMSI de l'abonné, un message sur chaque cellule où est susceptible de se trouver l'abonné. L'eNode B répercute ce message sur la voie radio, c'est à dire qu'on a autant de messages sur la voie radio que d'eNode B auxquels le MME a envoyé un message S1AP Paging. Et nous considérons la cellule où le terminal se trouve. Celui-ci va réagir au S1 Paging et va tout simplement effectuer la procédure UI Triggered Service Request. Cela va donc provoquer le rétablissement de la connexion radio, avec le Radio Bearer correspondant, le S1 Bearer entre l'eNode B et le Serving Gateway, on ne l'a de toute façon jamais libéré, le Bearer entre S.Gateway et P. Gateway. Les paquets ont peut-être continué à être envoyés vers le Serving Gateway. Celui-ci les a mis en mémoire et dès qu'il peut, il va transférer ces paquets sur les Bearers qui sont rétablis. Suivant la stratégie de l'opérateur, il peut y avoir une mise en mémoire plus ou moins importante, une capacité mémoire plus ou moins importante. Il est possible que l'opérateur décide de ne pas mémoriser les paquets en attente en se disant "s’il y a un protocole supérieur comme TCP, celui-ci va gérer ce mécanisme de reprise." Si on veut offrir une bonne qualité de service il est préférable de stocker les paquets entre le moment où le premier paquet a été reçu et les Bearers sont bien ré-établis.
