Lors de la capture de la signalisation d’enregistrement 5G, il est courant d’observer sur la même connexion N2 une séquence de ce type : Initial UE Message apparaît d’abord, suivi de Uplink NAS Transport et Downlink NAS Transport, puis de Initial Context Setup ; lorsque l’UE commence réellement à établir sa connectivité de données, PDU Session Resource Setup apparaît. Comprendre chaque message pris séparément n’est pas particulièrement difficile. Le plus complexe est de comprendre pourquoi ils surviennent dans cet ordre et ce que fait réellement NGAP dans l’ensemble du plan de contrôle 5G. Une manière utile d’appréhender N2 consiste à le considérer comme un canal de contrôle persistant entre le gNB et l’AMF. Les nœuds du réseau établissent d’abord leur relation, puis le contexte UE est créé, et ce n’est qu’ensuite que les ressources RAN sont préparées pour la session PDU. Lorsque l’UE se déplace, passe à l’état inactif ou que ses paramètres de service changent, des procédures NGAP supplémentaires sont déclenchées.
À quoi sert réellement l’interface N2 ?
N2 est l’interface du plan de contrôle entre le gNB et l’AMF et utilise NGAP, ou NG Application Protocol (protocole d’application NG). Sur le plan fonctionnel, elle présente certaines similitudes avec l’interface S1-MME utilisée en 4G, tout en fonctionnant dans l’architecture du système 5G.
SCTP est utilisé comme couche de transport pour N2. NGAP fonctionne au-dessus de SCTP, tandis que les messages NAS échangés entre l’UE et le cœur 5G peuvent être transportés entre le gNB et l’AMF via NGAP. Une pile protocolaire N2 typique peut donc être comprise ainsi : IP assure la connectivité réseau entre le gNB et l’AMF, SCTP fournit l’association de transport N2, NGAP transporte les procédures et paramètres de contrôle N2, et le NAS 5G est transporté sous forme de NAS-PDU lorsque nécessaire.
NGAP lui-même ne transporte pas le trafic normal du plan utilisateur de l’UE. Les données utilisateur réelles sont généralement acheminées via le plan utilisateur N3. N2 est responsable de fonctions de contrôle telles que l’établissement des ressources, la gestion du contexte UE, le transport de la signalisation NAS et la coordination de la mobilité. Fonctionnellement, N2 prend en charge l’établissement, le maintien et la libération des ressources NG-RAN associées aux sessions PDU, tout en participant à la gestion du contexte UE, à la gestion de la mobilité, au transport de la signalisation NAS et au contrôle des ressources du plan utilisateur.
Pourquoi les procédures NGAP sont-elles divisées en procédures associées à un UE et non associées à un UE ?
Lorsqu’on commence à étudier NGAP, se plonger directement dans des dizaines de procédures et de noms de messages peut vite transformer l’apprentissage en exercice de mémorisation. Une approche plus pratique consiste d’abord à déterminer si la procédure concerne un UE précis.
Les procédures associées à un UE s’articulent autour du contexte, de la session ou de l’état de mobilité d’un utilisateur donné. Elles comprennent notamment la gestion des ressources de session PDU, la gestion du contexte UE, le handover, le paging, le transport NAS, le rapport de localisation et les procédures de capacité radio de l’UE. À l’inverse, les procédures non associées à un UE servent principalement à maintenir la relation au niveau des nœuds entre le gNB et l’AMF. Les exemples typiques sont NG Setup, RAN Configuration Update, AMF Configuration Update, NG Reset, AMF Status Indication et Overload Start/Stop.
Cette distinction est extrêmement utile lors du dépannage de captures de paquets. Si les utilisateurs de tout un gNB sont affectés, il faut d’abord vérifier les procédures au niveau du nœud, telles que SCTP, NG Setup, Reset, l’état de l’AMF ou la gestion de surcharge. Si un seul UE est touché, l’analyse doit plutôt suivre les ID NGAP de cet UE, les messages de transport NAS, les procédures de contexte et la signalisation des ressources de session PDU.
Les procédures NGAP peuvent également être classées en Class 1 et Class 2 selon qu’une réponse est requise ou non. Les procédures Class 1 comprennent généralement un Request et un Response et peuvent aussi inclure un résultat Failure. Les procédures Class 2 ne nécessitent pas de réponse au niveau de la procédure de la part du pair. En dépannage réel, il est généralement plus utile de déterminer si une procédure doit aboutir à un résultat de succès ou d’échec que de mémoriser la classe de chaque message NGAP.
Comment N2 construit-il l’état depuis le démarrage du gNB jusqu’à l’enregistrement de l’UE ?
Avant l’apparition de tout UE, le premier problème que le gNB doit résoudre n’est pas l’enregistrement de l’abonné. Il doit d’abord vérifier qu’il peut communiquer correctement avec l’AMF.
La première étape est généralement NG Setup. Une fois l’association SCTP établie entre le gNB et l’AMF, le gNB envoie un NG Setup Request. Si l’AMF accepte la connexion, elle renvoie un NG Setup Response. Dans un déploiement pool d’AMF, le gNB peut devoir établir des relations N2 avec plusieurs AMF et obtenir les informations qui serviront ensuite à la sélection de l’AMF. À ce stade, seule la relation au niveau des nœuds est établie ; aucun contexte UE spécifique n’existe encore.
Lorsqu’un UE commence son enregistrement, la signalisation passe au niveau suivant. Après avoir reçu le premier message NAS de l’UE, le gNB peut le transférer à l’AMF au moyen de Initial UE Message. La signalisation NAS ultérieure entre l’UE et l’AMF est généralement transportée sur N2 au moyen de Uplink NAS Transport et Downlink NAS Transport. Un point important est que le gNB n’a pas besoin d’interpréter toute la logique de service NAS. Pour une grande partie de la signalisation NAS, sa responsabilité principale consiste à identifier le bon contexte UE et à remettre le NAS-PDU à l’AMF appropriée.
À mesure que l’enregistrement progresse, l’AMF a également besoin que le gNB établisse le contexte UE côté RAN. C’est à ce moment qu’apparaissent Initial Context Setup Request et Initial Context Setup Response. Initial Context Setup Request peut contenir des informations importantes liées à l’UE, telles que Allowed NSSAI, GUAMI, UE Security Capabilities, Mobility Restriction List et NAS-PDU. À ce stade, le gNB ne se contente plus de transférer la signalisation NAS : il commence à établir l’état nécessaire pour continuer à desservir cet UE.
Comment NGAP établit-il les ressources de session PDU lorsque l’UE commence à utiliser les données ?
Un enregistrement réussi ne signifie pas que toutes les ressources du plan utilisateur de l’UE sont déjà disponibles. Lorsque l’UE doit accéder à un réseau de données et établit une session PDU, N2 participe également à la préparation des ressources RAN correspondantes.
L’une des procédures clés est PDU Session Resource Setup. L’AMF envoie un PDU Session Resource Setup Request au gNB. Ce message transmet vers le NG-RAN les informations associées à la session PDU et à ses QoS Flow, telles que le PDU Session ID, le S-NSSAI, les informations de tunnel du plan utilisateur et la QoS Flow List. Le gNB alloue ensuite les ressources radio nécessaires en fonction des conditions locales, par exemple en configurant les DRB requis pour les QoS Flow et en préparant la connexion du plan utilisateur N3.
Une fois l’allocation des ressources terminée, le gNB envoie un PDU Session Resource Setup Response à l’AMF, indiquant quelles ressources ont été établies avec succès. La réponse peut contenir des informations de plan utilisateur du gNB ainsi que les QoS Flow admis avec succès.
C’est ici que les rôles de N1, N2 et N3 sont souvent confondus. N1 transporte vers l’UE les informations de session PDU de la couche NAS. N2 coordonne les ressources RAN et de plan utilisateur que le gNB doit établir. N3 transporte le trafic réel du plan utilisateur une fois ces ressources prêtes.
Pour cette raison, le dépannage d’un échec de session PDU ne doit pas s’arrêter lorsque la couche NAS renvoie un message Accept. Si la procédure PDU Session Resource Setup sur N2 ne se termine pas correctement, l’UE peut avoir reçu les paramètres de session alors que le plan utilisateur n’est toujours pas opérationnel.
N2 continue de fonctionner après l’établissement de la session PDU
NGAP ne s’arrête pas une fois la session PDU active. Tant que l’UE reste dans le réseau, des changements d’état ou de conditions de service peuvent déclencher d’autres procédures N2.
Lorsque l’UE se déplace vers un autre gNB, un handover basé sur N2 ou sur Xn peut être déclenché. Un handover N2 peut impliquer Handover Required, Handover Request, Handover Request Acknowledge, Handover Command et Handover Notify. Une fois le nouveau chemin établi, Path Switch Request et sa réponse peuvent suivre, tandis que l’ancien contexte UE sur le gNB source est libéré.
Si l’UE est inactif et qu’un trafic descendant arrive, l’AMF peut envoyer un message Paging au NG-RAN via NGAP, après quoi le RAN exécute la procédure de paging radio. Paging est une procédure NGAP unidirectionnelle typique. Si le réseau doit ajuster le QoS ou d’autres ressources RAN, PDU Session Resource Modify peut être déclenché. Lorsque la session n’est plus nécessaire, PDU Session Resource Release est utilisé. Le cycle de vie N2 d’une session PDU comprend donc non seulement Setup, mais aussi Modify, Release, Notify et les procédures Indication associées.
Outre les procédures de service liées à l’UE, les ingénieurs peuvent également rencontrer des messages de gestion d’interface tels que NG Reset, Error Indication, Overload Start, Overload Stop, AMF Status Indication et des procédures de mise à jour de configuration. Ils sont particulièrement utiles pour déterminer si un problème touche un seul UE ou reflète une modification plus large de la relation entre les nœuds N2.
Quel est le meilleur ordre pour dépanner une capture de paquets NGAP ?
NGAP comporte un grand nombre de messages, mais le dépannage pratique ne nécessite pas de parcourir la liste des messages 3GPP du début à la fin. Une meilleure méthode consiste à suivre l’ordre dans lequel l’état du réseau est établi.
La première étape consiste à vérifier SCTP. Si la Transport Network Layer Association entre le gNB et l’AMF n’a pas été correctement établie, il est peu utile d’analyser les procédures de service NGAP qui devraient suivre.
La deuxième étape consiste à vérifier NG Setup et à confirmer que la relation N2 au niveau des nœuds est saine. Si NG Setup a échoué, il n’est généralement pas pertinent de passer directement au dépannage de l’enregistrement UE.
La troisième étape consiste à identifier l’UE concerné. Les messages NGAP associés à un UE contiennent normalement les valeurs UE-NGAP-ID correspondantes. L’analyse des paquets doit suivre les mêmes identifiants UE dans le temps plutôt que de filtrer uniquement par type de message.
La quatrième étape consiste à confirmer que la signalisation NAS est correctement transportée. Vérifiez que Initial UE Message, Uplink NAS Transport et Downlink NAS Transport forment une séquence continue. Si le NAS-PDU a déjà atteint l’AMF mais qu’aucune réponse ne suit, l’orientation de l’analyse est très différente d’un cas où le gNB n’a jamais transmis le message NAS.
La cinquième étape consiste à vérifier l’établissement du contexte UE. Si l’enregistrement a atteint Initial Context Setup, examinez les paramètres du Request et vérifiez que le Response se termine correctement.
La sixième étape consiste à examiner les ressources de session PDU. Si l’UE est enregistré mais ne peut pas accéder au réseau de données, concentrez-vous sur PDU Session Resource Setup Request/Response et sur les résultats de ressources de session PDU et de QoS Flow renvoyés.
Si le problème survient pendant la mobilité, orientez l’analyse vers Handover, Path Switch et la libération de l’ancien contexte UE. Si un UE inactif ne peut pas être joint par le trafic descendant, concentrez-vous sur Paging.
Suivre la chaîne SCTP → NG Setup → identification UE → NAS → contexte UE → session PDU → mobilité est généralement bien plus efficace en ingénierie réelle que d’essayer de mémoriser des dizaines de noms de messages NGAP.
Questions fréquentes
Quelle est la relation entre NGAP et le NAS 5G ?
NGAP est le protocole de couche applicative utilisé sur l’interface N2 entre le gNB et l’AMF, tandis que NAS transporte la signalisation de contrôle entre l’UE et le cœur 5G. De nombreux messages NAS sont encapsulés sous forme de NAS-PDU dans des messages NGAP et transférés par le gNB entre l’UE et l’AMF ; les deux protocoles fonctionnent donc à des couches différentes.
L’interface N2 transporte-t-elle le trafic Internet de l’UE ?
Non. N2 n’est pas utilisé comme chemin normal du plan utilisateur pour les données de l’UE. Il transporte la signalisation du plan de contrôle. Le trafic utilisateur est généralement transporté entre le gNB et l’UPF sur N3, tandis que NGAP indique au RAN quelles ressources associées doivent être établies, modifiées ou libérées.
Un NG Setup réussi signifie-t-il que l’UE peut s’enregistrer normalement ?
Non. NG Setup établit la relation N2 au niveau des nœuds entre le gNB et l’AMF. Lorsqu’un UE particulier arrive, Initial UE Message, le transport NAS, l’établissement du contexte UE et les procédures ultérieures de ressources de session PDU doivent encore se terminer correctement.
Pourquoi le dépannage NGAP ne doit-il pas reposer uniquement sur des filtres type de message ?
Un seul gNB peut traiter de nombreux UE en même temps, et les mêmes types de messages NGAP peuvent apparaître à plusieurs reprises pour différents utilisateurs. Filtrer uniquement par nom de message peut facilement mélanger des procédures sans rapport. Le dépannage d’un UE spécifique doit combiner les valeurs UE-NGAP-ID, la chronologie des messages et le contexte NAS ou de session PDU concerné.
