Comment un UE est-il géré dans l'état RRC-Inactive? C'est ce que nous allons voir dans cette vidéo. Nous représentons sur ce dessin l'état des tunnels et connexions dans le réseau 5G pour un terminal qui est dans l'état RRC-Connected, CM-Connected. Une connexion radio est établie, nous avons également une connexion entre le gNodeB et l'AMF, et un tunnel de données entre le gNodeB et l'UPF. Pour transmettre au mieux les données sur la voie radio, le gNodeB a besoin de connaître les caractéristiques radios du terminal. Par exemple, sa capacité à gérer différentes bandes de fréquences, ou sa capacité à émettre en modulation 64-QAM ou 256-QAM. Avec la complexification des technologies, la liste des caractéristiques radios est relativement longue, il vaut donc mieux éviter de la transmettre trop fréquemment. L'ensemble des caractéristiques et d'autres données constitue le contexte de l'UE. Ce contexte est stocké par le gNodeB. Notons que le gNodeB ne connaît pas l'identité permanente, appelée SUPI en 5G, ou même l'idée temporaire 5G-GUTI : le gNodeB ne connaît que le RNTI du terminal. Lorsqu'on passe en état RRC-Inactive, la connexion radio est supprimée. Les autres connexions sont maintenues, et il faut garder, si l'on veut réétablir rapidement le flux de données sur la voie radio, il faut garder le contexte de l'UE stocké dans le gNodeB. Le problème, c'est que comme on a libéré la connexion radio, on n'a plus de RNTI. Il faut donc garder la possibilité d'identifier de façon spécifique l'UE. Pour ce faire, on va définir une nouvelle classe d'identité appelée I-RNTI. Dans les spécifications, le I n'est pas explicité, on peut penser que ça veut dire intermédiaire ou Intermediary RNTI. Le but du I-RNTI est de garder la capacité d'identifier chaque UE dans le gNodeB. Étant donné qu'un terminal peut rester un temps assez long en état RRC-Inactive, on a codé le I-RNTI sur 40 bits, ce qui laisse un grand nombre de I-RNTI possibles. Le I-RNTI peut être considéré un peu comme une plage d'identités de réserve, et l'intérêt du I-RNTI, c'est de pouvoir identifier chaque UE et donc d'associer le contexte radio de l'UE au I-RNTI. Notons qu'il n'y a pas d'échange possible immédiatement pour un terminal qui n'a qu'un I-RNTI. Voyons comment les choses se passent. Nous considérons un UE dans l'état connecté, CM-Connected, et nous supposons qu'il n'y a plus d'activité. Au bout d'un moment, le gNodeB va décider de faire passer cet UE en état RRC-Inactive. Il va donc envoyer un message RRC Release, mais dans ce message RRC Release, il va placer un I-RNTI. Ce I-RNTI a été choisi par le gNodeB et va être stocké par l'UE. L'UE peut, à ce moment-là , revenir en état de veille, en état RRC-Inactive. Notons que l'AMF voit toujours l'UE comme étant connecté. Lorsqu'il y a à nouveau des données à envoyer par l'UE, il a un I-RNTI mais pas de RNTI. Pour acquérir un RNTI, il fait donc une procédure d'accès radio standard avec l'envoi d'un préambule, l'allocation d'un RNTI provisoire qui devient ensuite définitif, et cette procédure lui permet d'avoir un RNTI dont la valeur n'est pas forcément identique à la valeur qui lui était allouée avant, c'est pour ça que nous l'avons appelé RNTI'. Le premier message qu'il va envoyer à l'issue de l'accès aléatoire est un message Resume Request, qui donne aussi le nom de la procédure qui s'appelle la procédure RRC-Connection Resume. Ce message Resume Request contient le I-RNTI. La présence du I-RNTI permet au gNodeB d'identifier de quel terminal, de quel UE il s'agit, et de récupérer toutes les caractéristiques radios. Dès que les caractéristiques radios sont connues, il est possible de retransférer un flux de données sur la voie radio en utilisant au mieux les capacités radios du terminal. Le I-RNTI est libéré et, comme le terminal a à nouveau un RNTI, il n'y a plus de problème : le terminal est dans l'état RRC-Connected. Notons que, lors de cette procédure, l'AMF et l'UPF n'ont pas été sollicités, ils ne voient aucune modification. En conclusion, pour identifier chaque UE en état RRC-Inactive au sein du gNodeB, on définit un I-RNTI, et on va définir également des procédures internes au réseau d'accès radio, qui permettent la libération de la connexion radio avec un passage de RRC-Connected à RRC-Inactive, avec allocation d'un I-RNTI, et une procédure de reprise de la connexion qui s'appelle RRC Resume. Par rapport aux procédures de passage RRC-Connected/ECM-Connected à RRC-Idle/ECM-Idle, on a moins de messages et on a plus de rapidité à réétablir le flux de données. Tout ceci est vrai mais nous n'avons pas du tout considéré la mobilité d'un terminal, par exemple le changement de cellule. C'est ce que nous allons voir dans la vidéo suivante. [MUSIQUE]
