Entre un UE entièrement connecté et un UE totalement au repos, la 5G introduit un état qui paraît silencieux du point de vue de l'utilisateur, mais qui conserve une importance technique dans le NG-RAN. Cet état est RRC Inactive. Il a été ajouté à la gestion des connexions 5G pour résoudre un problème concret : de nombreux équipements doivent reprendre rapidement la transmission de données, mais maintenir tous les équipements en permanence dans l'état RRC Connected gaspillerait des ressources de signalisation, des ressources radio et l'énergie de la batterie.

Un smartphone peut vérifier des messages en arrière-plan, un capteur peut envoyer de courtes rafales de données et une application peut se réveiller brièvement après une longue période de silence. Ces profils de trafic ne justifient pas toujours un retour complet à l'état de repos suivi d'une procédure intégrale d'établissement de connexion. RRC Inactive fournit une couche intermédiaire. L'UE peut réduire son activité, conserver les principaux contextes et reprendre plus rapidement la connexion lorsque des données montantes ou descendantes apparaissent.

Le point essentiel est que RRC Inactive n'est pas identique à RRC Idle. Dans RRC Idle, l'UE est également en CM-IDLE du point de vue du réseau cœur. Dans RRC Inactive, l'UE reste en CM-CONNECTED, tandis que la couche RRC est suspendue par rapport au fonctionnement connecté actif. Le gNodeB conserve le contexte UE, l'UE conserve le contexte AS et le réseau peut ramener l'UE vers RRC Connected au moyen d'une procédure de reprise, sans tout recommencer depuis le début.

Pourquoi la 5G a besoin de cet état

La gestion des connexions 5G doit prendre en charge de nombreux types de trafic en même temps. Certains services nécessitent un débit élevé et une connexion continue. D'autres n'ont besoin que d'échanges de données courts et occasionnels. Certains terminaux restent silencieux pendant de longues périodes, mais doivent néanmoins répondre rapidement lorsque le réseau ou l'application les sollicite. Si tous les UE restaient en RRC Connected, le réseau supporterait une surcharge de contrôle inutile. Si tous les UE inactifs étaient entièrement basculés vers RRC Idle, la récupération de la connexion pourrait devenir plus lente et plus exigeante en signalisation.

RRC Inactive réduit cet écart. L'UE peut arrêter le traitement actif des données propre à RRC Connected, mais le contexte important de la strate d'accès n'est pas supprimé. Une future procédure de reprise peut ainsi rétablir plus rapidement la connexion. Du point de vue de l'expérience utilisateur, l'équipement peut rester réactif. Du point de vue du réseau, le système évite de conserver des ressources actives plus longtemps que nécessaire.

Cette conception est particulièrement utile pour les applications qui se réveillent fréquemment sans maintenir de longues sessions. Les services de messagerie, la synchronisation en arrière-plan, les remontées intermittentes de capteurs, les petites rafales de données montantes et les brèves notifications descendantes peuvent tous bénéficier d'un état permettant un retour plus rapide au fonctionnement connecté.

Du point de vue de l'architecture réseau, RRC Inactive est également utile car il transfère vers le NG-RAN une partie de la responsabilité liée à la mobilité et au paging. L'AMF n'a pas besoin de traiter chaque déplacement à l'intérieur d'une zone locale de notification RAN comme un événement de mobilité du réseau cœur. Le gNodeB peut gérer plus efficacement le contexte UE et le paging local.

Comment cet état est défini

RRC Inactive possède plusieurs caractéristiques essentielles. Premièrement, l'UE est toujours considéré comme CM-CONNECTED. C'est une différence majeure par rapport à RRC Idle, dans lequel l'UE est également en CM-IDLE. La relation de connexion avec le cœur 5G reste en place, même si la connexion RRC ne transporte pas activement les données normales du mode connecté.

Deuxièmement, cet état est en grande partie transparent pour le réseau cœur. En fonctionnement normal, l'AMF n'a pas besoin de gérer directement RRC Inactive de la même manière que le NG-RAN. Le dernier gNodeB de service conserve le contexte UE et connaît la RAN Notification Area à laquelle appartient l'UE. Cette conservation du contexte permet une récupération rapide.

Troisièmement, l'UE et le gNodeB conservent le contexte de la couche AS. Puisque le contexte de la strate d'accès est préservé, l'UE n'a pas besoin d'une configuration entièrement nouvelle lors de la reprise du service. Il peut utiliser une procédure RRC Resume pour revenir à RRC Connected.

Le passage à RRC Inactive s'effectue au moyen d'un message RRC Release contenant une configuration de suspension. C'est pourquoi cet état est souvent présenté avec les procédures de suspension et de reprise. Le réseau libère la connexion RRC active, mais demande à l'UE de suspendre son contexte au lieu de le supprimer complètement.

Lorsqu'une nouvelle activité est nécessaire, l'UE peut passer de RRC Inactive à RRC Connected. Cela peut se produire lorsqu'il dispose de données montantes à transmettre ou lorsqu'il reçoit un paging RAN lié à des données descendantes. Si l'inactivité dure trop longtemps, l'UE Inactivity Timer du gNodeB peut finalement entraîner une libération N2, faisant évoluer l'UE vers RRC Idle et CM-IDLE.

Ce que l'UE peut encore faire

RRC Inactive ne signifie pas que l'UE est figé. Plusieurs procédures restent possibles même lorsque l'UE n'est pas activement en RRC Connected. Il peut effectuer une sélection PLMN, recevoir la diffusion des informations système, réaliser une resélection de cellule et répondre à un paging initié par le RAN. Ces fonctions permettent à l'UE de rester joignable sans maintenir une connexion RRC entièrement active.

Le réseau reste également actif de manière ciblée. Le NG-RAN gère la RAN Notification Area, configure le DRX pour le paging RAN et conserve le contexte AS de l'UE. Le gNodeB sait à quel RNA appartient l'UE et peut donc déterminer la portée du paging local lorsque des données ou de la signalisation imposent une reprise.

Autre point important : les contextes de connexion N2 et N3 peuvent rester établis pour l'UE dans ce modèle de fonctionnement. Cela compte lorsque des données descendantes arrivent. L'UPF peut encore connaître l'adresse du gNodeB et transférer les données vers le dernier gNodeB de service. Celui-ci déclenche alors le paging dans le RNA configuré au lieu de forcer, depuis le début, une procédure de paging du réseau cœur.

Ces éléments conservés expliquent pourquoi RRC Inactive est utile, mais aussi plus complexe qu'un simple comportement au repos. Le réseau doit préserver suffisamment de contexte pour récupérer rapidement, sans conserver une quantité de ressources actives telle que cet état deviendrait équivalent à RRC Connected. La valeur de cet état réside dans cet équilibre de conception.

Comment le RNA contrôle la mobilité

RNA signifie RAN Notification Area. Il s'agit d'une zone de notification côté RAN utilisée pour les UE en RRC Inactive. Un RNA regroupe plusieurs cellules, généralement dans une même Tracking Area. Lorsqu'un UE se déplace à l'intérieur du RNA qui lui est attribué, il n'a pas besoin d'informer le réseau à chaque changement de cellule. Cela évite une signalisation inutile lorsque l'UE se déplace uniquement au niveau local.

Le RNA est identifié par un RNA ID. Cet identifiant est formé à partir du TAC et du RAN Area Code. La plage du RAN Area Code va de 0 à 255. En pratique, cela fournit au NG-RAN un moyen compact de définir des zones locales dans lesquelles les UE inactifs peuvent se déplacer sans mises à jour fréquentes.

Le dernier gNodeB de service attribue le RNA ID au moyen de la configuration de suspension du message RRC Release. Ce détail est important, car le gNodeB ayant servi l'UE en dernier devient responsable de la connaissance de son contexte RNA. Si des données descendantes apparaissent ensuite, ce gNodeB peut décider comment rechercher l'UE dans la zone appropriée.

L'UE doit toutefois mettre le réseau à jour dans certaines conditions. Si le temporisateur périodique de mise à jour RNA expire ou si l'UE quitte le RNA configuré, il doit lancer la procédure de mise à jour RNA. Le NG-RAN conserve ainsi une connaissance exploitable de la zone locale de l'UE, tout en évitant une signalisation excessive lors des déplacements normaux à l'intérieur du RNA.

La conception du RNA influence l'efficacité du paging. Un RNA très petit peut provoquer des mises à jour fréquentes lorsque l'UE se déplace. Un RNA très grand peut augmenter la charge de paging, car davantage de cellules peuvent devoir être sollicitées à l'arrivée de données descendantes. Une bonne planification dépend donc des profils de mobilité, de la disposition des cellules, des limites des gNodeB et du comportement attendu des services.

Comment les données descendantes sont livrées

Le traitement des données descendantes est l'un des exemples les plus clairs de l'intérêt de RRC Inactive. Lorsque des données descendantes arrivent de l'UPF alors que l'UE est en RRC Inactive, elles peuvent être envoyées vers le dernier gNodeB de service. Le gNodeB lance alors le paging dans le RNA, car il sait que l'UE est inactif tout en restant joignable localement par un paging au niveau RAN.

Si toutes les cellules du RNA appartiennent au dernier gNodeB de service, la procédure est relativement directe. Le gNodeB lance le paging de l'UE dans les cellules concernées. L'UE reçoit le message de paging RAN, lance la procédure RRC Resume et revient à RRC Connected. Une fois la reprise terminée, il peut recevoir les données descendantes.

Si le RNA contient des cellules desservies par des gNodeB voisins, le dernier gNodeB de service peut utiliser la signalisation Xn. Il peut envoyer un message XnAP RAN Paging au gNodeB voisin afin que le paging soit également effectué dans ces cellules. La portée du paging suit ainsi le RNA au lieu d'être limitée aux seules cellules du dernier gNodeB de service.

La même logique générale s'applique lorsque de la signalisation descendante associée à l'UE arrive depuis l'AMF, à l'exception de cas tels que UE Context Release Command qui utilisent une autre voie de traitement. Le point essentiel est que le NG-RAN peut gérer le paging d'un UE inactif sans le traiter immédiatement comme un cas complet de paging du réseau cœur en mode au repos.

Du point de vue du service, l'expérience utilisateur dépend de la rapidité avec laquelle l'UE reçoit le paging et termine la reprise. Du point de vue du réseau, le système bénéficie de la réutilisation du contexte et d'une signalisation davantage localisée.

Comment fonctionnent les transitions de reprise

RRC Inactive peut revenir à RRC Connected depuis le côté UE ou depuis le côté réseau. Une transition déclenchée par l'UE se produit lorsque celui-ci dispose de données montantes ou d'un besoin de signalisation. L'UE envoie une RRC Resume Request au gNodeB. Si le gNodeB actuel n'est pas le dernier gNodeB de service, il peut devoir récupérer le contexte UE auprès de ce dernier avant de terminer la reprise.

Une procédure type déclenchée par l'UE peut inclure RRC Resume Request, Retrieve UE Context Request, Retrieve UE Context Response, RRC Resume et RRC Resume Complete. Si le gNodeB de service change, des procédures supplémentaires peuvent être nécessaires, notamment Xn-U Address Indication et Path Switch Request vers l'AMF. Une fois le changement de chemin traité, l'ancien contexte peut être libéré lorsque cela convient.

La transition déclenchée par le réseau commence différemment. Le dernier gNodeB de service reçoit des données descendantes ou de la signalisation pertinente et déclenche le paging RAN. Le paging de l'UE est lancé dans le RNA. Après réception du paging, il reprend depuis RRC Inactive et revient à RRC Connected afin de traiter les données ou la signalisation en attente.

Ces transitions sont conçues pour être plus légères qu'un établissement complet de connexion depuis le mode au repos. Cela ne signifie pas qu'elles soient triviales. Leur bon fonctionnement dépend du contexte stocké, de la coordination entre gNodeB, du changement de chemin au niveau de l'AMF lorsqu'il est nécessaire et de la libération propre du contexte après l'établissement du nouveau chemin de service.

La voie contrôlée par temporisateur est également importante. Si l'UE reste inactif au-delà de la politique du UE Inactivity Timer du gNodeB, le réseau peut le faire évoluer vers RRC Idle. Cela implique généralement une libération N2 et fait passer l'état du réseau cœur à CM-IDLE. À ce stade, les avantages de reprise rapide de RRC Inactive ne s'appliquent plus.

Comment l'AMF reçoit les rapports d'état

RRC Inactive est souvent décrit comme transparent pour le réseau cœur, mais cette affirmation doit être interprétée avec prudence. En général, l'AMF ne contrôle pas directement l'état RRC de l'UE de la même manière que le NG-RAN. Il peut toutefois demander des rapports sur les transitions d'état RRC au moyen de la signalisation NGAP.

L'AMF peut inclure un paramètre RRC Inactive Transition Report Request dans des messages tels que Initial Context Setup Request ou UE Context Modification Request. Lorsque la demande porte sur les transitions ultérieures, le gNodeB doit signaler l'entrée ou la sortie de l'UE dans l'état RRC Inactive.

Lorsqu'un changement d'état se produit, le gNodeB envoie à l'AMF un RRC Inactive Transition Report. Le rapport contient la valeur RRC State, par exemple Inactive ou Connected. Ce mécanisme donne de la visibilité à l'AMF lorsqu'il la demande, sans modifier le principe selon lequel le NG-RAN gère le comportement RRC Inactive.

Cette capacité de rapport est utile pour la coordination du réseau, la connaissance des politiques et la supervision opérationnelle. Elle explique aussi pourquoi RRC Inactive ne doit pas être décrit trop simplement comme totalement invisible pour le réseau cœur. Une description plus juste est qu'il est principalement géré par le RAN, tandis que l'AMF peut obtenir des informations de transition d'état dans des conditions définies.

Pour l'analyse technique, cette distinction est importante. En cas d'échec d'une procédure, le diagnostic peut devoir examiner à la fois le comportement du RAN et celui des rapports NGAP. L'état de l'UE, le contexte du gNodeB, la configuration RNA, le paging RAN, la demande de rapport de l'AMF et le traitement du changement de chemin peuvent tous influencer le résultat final.

Questions fréquentes

Pourquoi RRC Inactive n'est-il pas identique à RRC Idle ?

RRC Inactive maintient l'UE en CM-Connected et conserve le contexte de la strate d'accès, tandis que RRC Idle correspond à une relation au repos avec le réseau cœur dans laquelle la récupération de la connexion nécessite une procédure plus lourde.

Qu'est-ce qui déclenche la reprise depuis RRC Inactive ?

La reprise peut être déclenchée par des données montantes de l'UE, un besoin de signalisation de l'UE ou un paging RAN provoqué par des données descendantes ou une signalisation descendante prise en charge.

Pourquoi le RNA réduit-il la signalisation ?

Le RNA permet à l'UE de se déplacer dans une zone de notification RAN définie sans informer le réseau de chaque changement de cellule, ce qui réduit la signalisation inutile liée à la mobilité locale.

Que se passe-t-il si l'UE quitte son RNA ?

L'UE doit lancer une procédure de mise à jour RNA afin que le NG-RAN actualise les informations de zone utilisées pour le paging local et la joignabilité à l'état inactif.

Pourquoi des gNodeB voisins peuvent-ils participer au paging ?

Si le RNA contient des cellules desservies par des gNodeB voisins, le dernier gNodeB de service peut envoyer XnAP RAN Paging afin que ces cellules voisines puissent également effectuer le paging de l'UE.

Quand l'AMF connaît-il les changements d'état RRC ?

L'AMF peut recevoir des rapports de transition lorsqu'il les a demandés au moyen du paramètre RRC Inactive Transition Report Request dans des procédures NGAP prises en charge.

RRC Inactive est l'une des améliorations les plus pratiques de la gestion des connexions 5G. Il conserve suffisamment de contexte pour une reprise rapide, réduit l'utilisation inutile de ressources de connexion actives, prend en charge les déplacements locaux au moyen du RNA et permet au NG-RAN de gérer le paging plus efficacement. Sa valeur vient de son équilibre : plus rapide qu'un retour depuis un état totalement au repos, plus léger que le maintien d'une connexion complète et suffisamment flexible pour les profils modernes de trafic mobile.