Lorsqu'on met sous tension un terminal il établit une connexion radio. Si je n'utilise pas mon terminal, si je le laisse dans ma poche, est-ce que les connexions sont toujours maintenues ? D'autre part, si je veux maintenir une connexion radio est-ce que ça ne va pas consommer trop d'énergie ? Ce sont deux questions auxquelles nous allons répondre dans cette vidéo. À la mise sous tension nous avons donc vu l'établissement d'un bearer par défaut. Un paquet qui arrive du réseau doit être routé le plus rapidement possible. De la même façon un paquet qui est créé parce que j'ai une application qui tourne sur mon terminal, doit être émis le plus rapidement possible. En cas d'utilisation du terminal, comme le terminal l'UE peut se déplacer, eh bien une connexion active sur l'interface radio nécessite l'envoi régulier de mesures, des signaux venant des différentes stations bases, pour détecter que le terminal s'éloigne par exemple d'une station de base et se rapproche d'une autre. Ce sont par exemple des mesures de niveau de puissance. Si je n'utilise pas mon terminal, maintenir cette connexion radio nécessite d'avoir des échanges réguliers de mesure et de vérification, que le terminal est bien toujours sur la couverture du même eNodeB, donc tout ça provoquerait la dépense de beaucoup d'énergie. Et les batteries ne tiendraient pas très longtemps. D'autre part, quand on a une connexion radio établie, on a l'allocation d'un RNTI. Les RNTI sont codés sur seize bits, ça en fait soixante-cinq milles et quelques, mais ce n'est pas si important que ça. Donc on va éviter de maintenir tout le temps la connexion radio. Ce qui va se passer c'est qu'il y a une temporisation d'inactivité radio. Tant que j'utilise mon terminal, c'est-à -dire qu'il y a transmission de données utilisateurs, la connexion est maintenue et le temporisateur d'inactivité est rechargé. On le voit ici il n'y a plus d'activité, le temporisateur a sa valeur qui est diminuée, elle descend, mais l'utilisateur par exemple a lu une page Web, il demande le chargement d'une autre page Web, à nouveau il y a de l'activité. Le temporisateur est relancé. Lorsque la valeur atteint zéro, c'est-à -dire qu'on n'a pas utilisé dans le concret ou qu'aucune application n'a engendré de messages pendant un certain temps, on va libérer la connexion radio. Cette temporisation est classée dans l'eNodeB et elle est lancée à la fin d'un échange. À échéance de la temporisation on va libérer la connexion RRC et le terminal va perdre son RNTI. Si on regarde l'aspect réseau, on a ici la représentation de l'ensemble des connexions et des tunnels. Ce sont des dessins que nous avons déjà vus dans les séquences précédentes. S'il y a activité radio, la connexion et tous les tunnels sont maintenus. S'il y a inactivité on va libérer la connexion radio. Mais si on libère la connexion radio ça veut dire qu'on perd la connaissance de la cellule précise où se trouve le terminal. Donc le terminal peut bouger, changer de station de base sans que le réseau soit forcément au courant. C'est ce que nous verrons en semaine cinq. Ceci veut dire que si on ne sait plus précisément sous quel eNodeB se trouve le terminal, il ne sert à rien de maintenir un tunnel S1 entre l'eNodeB et le Serving Gateway, et il ne sert à rien de maintenir une connexion S1AP. Donc lorsqu'on libère la connexion radio en même temps on libère le tunnel et la connexion S1AP. On va donc avoir une notion qu'on appelle, l'état ECM. Dans l'état de ECM-IDLE il n'y a pas de connexion radio. On ne sait pas où se trouve le terminal. En revanche, le terminal reste attaché au réseau. Lorsqu'on a ECM-Connected, on a la connexion radio qui est active, on a le RMTI qui est alloué et les bearers de signalisations et utilisateurs. On va avoir donc une alternance entre l'état ECM-Connected et l'état ECM-IDLE.
