Lors de la capture de la signalisation d’enregistrement 5G, les ingénieurs trouvent généralement sans difficulté des messages tels que Initial UE Message, Uplink NAS Transport et d’autres procédures NGAP. La question la plus complexe se situe souvent en dessous : comment un paquet de signalisation N2 quitte-t-il le gNB, traverse-t-il le réseau de transport et le centre de données, puis atteint-il le serveur qui héberge le service AMF ? Si l’AMF est virtualisée et s’exécute dans une VM, avec quel point d’extrémité le gNB établit-il réellement son association SCTP ? Quels rôles jouent la passerelle PTN, le routeur de périphérie du centre de données et les commutateurs EOR et TOR ? Et lorsque la signalisation échoue, faut-il commencer le dépannage par NGAP, SCTP, le routage IP ou le transfert MAC de couche 2 ?

Ces questions semblent relever de domaines d’ingénierie différents. L’équipe radio se concentre sur le gNB, l’équipe cœur de réseau sur l’AMF et NGAP, l’équipe transport gère le PTN, et l’équipe du centre de données est responsable des commutateurs et des serveurs. Pourtant, sur un chemin N2 opérationnel, tous ces composants fonctionnent comme une chaîne continue. Un NAS Registration Request reçu par le gNB ne « saute » pas simplement jusqu’à l’AMF. Le gNB relaie d’abord le message depuis le côté RRC vers NGAP, l’encapsule sur SCTP et IP, l’envoie à travers plusieurs nœuds réseau de couche 3 et de couche 2, puis le remet finalement à l’environnement de calcul où s’exécute le processus AMF. Le dépannage du routage N2 devient beaucoup plus simple lorsque le chemin logique des protocoles et le chemin physique du réseau sont examinés ensemble, plutôt que réduits à un simple test « Puis-je pinguer l’AMF ? ».

Que transfère réellement l’interface N2 ?

N2 est l’interface de signalisation entre le gNB et l’AMF. Pour l’enregistrement de l’UE, la gestion de la mobilité et les autres procédures du plan de contrôle 5G, l’UE génère des messages NAS tandis que le gNB assure une fonction essentielle de relais. Il prend le NAS-PDU reçu de l’UE, le transporte dans le message NGAP approprié et l’envoie vers l’AMF via N2. Le processus inverse s’applique dans le sens descendant. Comprendre la signalisation N2 exige donc de distinguer le message applicatif lui-même du chemin de transport qui le véhicule.

Prenons un UE qui initie son enregistrement. L’UE envoie d’abord un NAS Registration Request vers le gNB à travers la pile de protocoles radio. Pour ce type de signalisation, le gNB n’est pas le point d’extrémité applicatif final. Son rôle consiste à placer le NAS-PDU dans un message NGAP et à le transférer vers l’AMF via la relation de transport N2 déjà établie. À haut niveau, côté UE, le message est traité par NAS, RRC, PDCP, RLC, MAC et L1. Au niveau du gNB, le message NAS est relayé depuis la pile radio vers NGAP, puis transporté sur SCTP, IP, la couche 2 et la couche 1. À l’AMF, le paquet est désencapsulé en suivant la pile inverse jusqu’à ce que le message NAS atteigne la couche de traitement NAS.

Une erreur fréquente consiste à considérer « le gNB transfère NAS » comme le même type de transfert que celui d’un routeur IP. Ces opérations ont lieu à des couches différentes. Le gNB effectue d’abord un relais au niveau protocolaire de NAS/RRC vers NGAP et crée un nouveau paquet SCTP/IP côté N2. Le réseau de transport et le réseau du centre de données n’ont pas besoin de savoir si la charge utile contient un Registration Request ou une autre procédure NAS. Leur rôle consiste simplement à acheminer le paquet selon le routage IP, l’adressage MAC et les informations d’interface.

Les procédures NGAP peuvent également être classées en procédures associées à un UE et non associées à un UE. NAS Transport et Initial Context Setup sont associées à un UE, tandis que NG Setup est une procédure de niveau nœud non associée à un UE. Cette distinction est utile pour le dépannage. Si tous les UE d’un gNB ne peuvent pas communiquer avec l’AMF, il faut d’abord examiner la relation N2 au niveau du nœud, SCTP et le routage IP. Si un seul UE est affecté, l’analyse doit se poursuivre en suivant le contexte NGAP et NAS de cet UE.

Quels nœuds réseau la signalisation N2 traverse-t-elle entre le gNB et l’AMF ?

Les schémas d’architecture logique représentent souvent N2 par une seule ligne entre le gNB et l’AMF. Cette représentation est utile pour expliquer la relation d’interface, mais elle ne montre pas le chemin réseau réellement emprunté par le trafic de signalisation. Dans un déploiement réel, un gNB est rarement relié directement à un serveur AMF par un seul lien physique. Un réseau de transport se situe entre le RAN et le centre de données du cœur de réseau, tandis que des routeurs, des commutateurs et un réseau de serveurs sont utilisés à l’intérieur du centre de données.

Un chemin de transport N2 simplifié peut être représenté ainsi : le gNB envoie le trafic vers une passerelle PTN de couche 3 ; le paquet traverse le réseau de transport et atteint le routeur de périphérie de couche 3 du centre de données ; il passe ensuite par les commutateurs EOR et TOR avant d’arriver au serveur qui héberge l’AMF. Le PTN transporte le trafic IP côté gNB vers le centre de données régional ou central. Le routeur de couche 3 à la frontière du centre de données achemine ensuite le paquet N2 vers le bon réseau de serveurs. À l’intérieur du centre de données, les commutateurs EOR et TOR effectuent une commutation de couche 2 jusqu’à ce que la trame Ethernet atteigne l’interface du serveur qui porte la charge de travail AMF.

Dans un cœur 5G basé sur le cloud, la question « Sur quel équipement se trouve l’AMF ? » ne peut pas être résolue uniquement en termes de serveur physique. L’AMF peut s’exécuter comme fonction réseau virtualisée sur un nœud de calcul généraliste, et le même serveur physique peut également héberger des machines virtuelles OAM, d’autres fonctions réseau ou plusieurs instances de service. Par exemple, une VM peut exécuter le service AMF chargé du traitement NAS, NGAP et SCTP. Du point de vue du gNB, toutefois, l’information essentielle est le point d’extrémité IP du service N2 exposé par l’AMF, et non l’étiquette du serveur physique dans la baie.

Cela signifie que le dépannage N2 implique au moins trois notions différentes d’emplacement. L’emplacement physique identifie la baie et l’hôte physique où s’exécute la charge de travail. L’emplacement logique identifie la VM ou l’instance de service qui héberge l’AMF. L’emplacement réseau est l’adresse IP N2 de l’AMF utilisée par le gNB pour établir l’association SCTP. Il est tout à fait possible que le serveur physique, la VM et le processus AMF semblent fonctionner correctement alors que N2 reste inaccessible, parce que le VLAN, la passerelle par défaut, la route IP, le port du commutateur ou la couche de commutation virtuelle n’achemine pas correctement le trafic vers cette adresse N2.

Quelle est la différence entre routage et transfert sur le chemin N2 ?

Livrer un paquet de signalisation N2 à l’AMF ne consiste pas simplement à disposer d’une table de routage. Du point de vue du traitement réseau, il est important de distinguer le routage du transfert. Le routage est généralement une fonction de couche 3. Lorsqu’un équipement reçoit un paquet IP, il recherche l’adresse IP de destination dans sa table de routage, détermine l’interface de sortie et sélectionne le prochain saut approprié. Le long du chemin N2, le gNB, la passerelle PTN de couche 3 et le routeur de périphérie du centre de données ont tous besoin des informations de routage IP correspondantes. Ces routes peuvent être configurées statiquement ou apprises via un protocole de routage dynamique.

Supposons que l’adresse source N2 du gNB soit A et que l’adresse N2 de l’AMF soit B. Le gNB n’a pas besoin de savoir dans quelle baie physique de serveurs se trouve B. Il doit seulement savoir quelle passerelle de prochain saut doit recevoir les paquets destinés au sous-réseau contenant B. Les équipements de couche 3 du PTN prennent la même décision à l’aide de leurs propres tables de routage jusqu’à ce que le paquet entre dans le réseau du centre de données contenant l’AMF.

Le routage détermine où le paquet doit aller ensuite, mais le paquet doit encore être transmis sur le lien physique actuel. Si Ethernet est utilisé, l’équipement ajoute un en-tête de trame Ethernet contenant les adresses MAC source et destination. Le commutateur transfère ensuite la trame selon sa table d’adresses MAC. Par conséquent, l’en-tête externe de couche 2 du même paquet IP N2 peut changer lorsqu’il traverse différents sauts de couche 3. La couche IP continue de représenter la relation de bout en bout entre le gNB et l’AMF, tandis que les adresses MAC ne sont pertinentes que pour le segment de couche 2 courant.

Dans le centre de données, les commutateurs EOR et TOR assurent principalement la commutation de couche 2. Une fois que le routeur de couche 3 du centre de données a livré le paquet N2 au bon domaine de couche 2 côté serveur, les commutateurs EOR et TOR utilisent leurs tables MAC pour déplacer la trame vers le port du serveur cible. Cette distinction est importante lors de l’analyse de captures. Des adresses MAC différentes à différents points de capture ne signifient pas que le paquet a changé de destination finale, et des adresses IP source et destination inchangées ne signifient pas que le paquet a circulé directement entre les deux extrémités sans traverser d’équipements intermédiaires.

Pourquoi l’association SCTP constitue-t-elle la frontière clé du dépannage N2 ?

NGAP ne s’exécute pas directement sur IP, mais sur SCTP. Un chemin N2 utilisable exige donc d’abord une connectivité IP, puis l’établissement réussi de l’association SCTP. Cela crée une dépendance claire pour le dépannage : si le routage IP est défaillant, SCTP ne peut pas être établi ; sans SCTP, NGAP ne peut pas fonctionner ; et sans NGAP, la signalisation NAS ne peut pas être relayée correctement.

L’inverse n’est toutefois pas nécessairement vrai. Pouvoir pinguer l’AMF ne démontre qu’un certain niveau de connectivité IP. Cela ne prouve pas que le service SCTP requis est joignable, que l’association SCTP peut être établie, que les paramètres NGAP sont corrects ou que le processus applicatif AMF fonctionne normalement.

• Premièrement, vérifiez le chemin IP. Vérifiez l’adresse N2 du gNB, le masque de sous-réseau, la passerelle par défaut et la route vers l’adresse N2 de l’AMF. Vérifiez ensuite que la passerelle PTN et les équipements de couche 3 du centre de données disposent à la fois de la route aller et de la route retour. La route retour est particulièrement facile à oublier. Un paquet quittant le gNB peut atteindre correctement l’AMF alors que l’AMF ne dispose toujours d’aucune route valide vers le sous-réseau du gNB. N2 étant une interface de signalisation bidirectionnelle, les deux sens doivent fonctionner.

• Deuxièmement, confirmez que SCTP est réellement établi. Une fois la connectivité IP vérifiée, contrôlez si le gNB et l’AMF terminent la procédure d’association SCTP et passent à l’état Established. Si l’association ne s’établit jamais, examinez les ports de la couche transport, les liaisons IP locales, les ACL, les pare-feu et toute politique de sécurité appliquée sur le chemin. Les centres de données réels peuvent également contenir des IDS/IPS, des répartiteurs de charge, des composants SDN ou d’autres systèmes de sécurité et de contrôle du trafic susceptibles d’affecter SCTP même s’ils n’apparaissent pas sur les schémas d’architecture simplifiés.

• Troisièmement, remontez vers NGAP et NAS. NG Setup, Initial UE Message et NAS Transport ne doivent être analysés qu’une fois l’association SCTP stable. Si SCTP fonctionne mais que NG Setup échoue, le problème se situe au-dessus de la couche de transport IP, dans la logique applicative ou de configuration N2. Si NG Setup réussit mais que la signalisation d’enregistrement d’un UE particulier n’atteint pas l’AMF, poursuivez en suivant Initial UE Message, les valeurs UE-NGAP-ID et le NAS-PDU. Cette approche par couches évite une erreur courante : commencer le dépannage NAS avant d’avoir confirmé que le message NAS a réellement traversé l’interface N2.

Comment une capture de paquets peut-elle reconstruire le chemin complet de signalisation N2 ?

La véritable utilité de la compréhension du routage N2 apparaît lors des captures de paquets et de l’isolation des pannes. Lorsqu’on dépanne un cas où la signalisation entre le gNB et l’AMF échoue, le chemin doit être vérifié depuis les couches de transport vers le haut. L’emplacement de la capture est important. Une trace côté gNB confirme si la signalisation quitte réellement la station de base. Une capture près du PTN ou de la périphérie du centre de données permet de déterminer si le paquet entre dans la zone du cœur de réseau. Une capture côté serveur montre si le paquet N2 atteint physiquement l’hôte qui exécute la charge de travail AMF. Si la trace côté gNB montre l’émission de paquets SCTP INIT alors que l’hôte AMF ne les voit jamais, la panne se situe presque certainement dans le réseau intermédiaire plutôt que dans la logique applicative NGAP.

Après la capture du paquet, vérifiez que les adresses IP source et destination correspondent à la conception prévue. Si l’AMF a été migrée, étendue ou déplacée vers une nouvelle VM alors que le gNB pointe toujours vers une ancienne adresse N2, la signalisation peut suivre un mauvais chemin même si la configuration NGAP semble par ailleurs inchangée. Examinez ensuite la route saut par saut sur les équipements de couche 3. Sur le gNB, la passerelle PTN et le routeur du centre de données, vérifiez la route vers le sous-réseau de l’AMF, notamment l’interface de sortie, le prochain saut et le chemin de retour. Si un routage dynamique est utilisé, confirmez que la route a réellement été apprise et installée dans la table de transfert, au lieu de vérifier seulement que le protocole de routage est activé dans la configuration.

Lorsque le paquet atteint la frontière de couche 3 du centre de données mais n’atteint toujours pas le serveur AMF, le dépannage passe du routage IP au transfert de couche 2. Vérifiez l’appartenance aux VLAN sur les commutateurs EOR et TOR, l’apprentissage des adresses MAC, l’état des ports côté serveur et si le serveur ou la couche de commutation virtuelle est raccordé au bon réseau de service. Enfin, mettez en relation les constats réseau avec l’état SCTP. Si le chemin IP bidirectionnel est sain mais que SCTP ne s’établit toujours pas, examinez le traitement des ports SCTP, la liaison IP et le processus AMF lui-même. Une fois SCTP établi, l’analyse NGAP et NAS peut se poursuivre avec une frontière de panne beaucoup plus claire.

Vu de bout en bout, le « routage de la signalisation N2 » se compose en réalité de deux processus différents mais continus. Le premier se déroule à l’intérieur du gNB. Un message NAS arrive depuis l’UE par le côté radio, est relayé dans un message NGAP, puis encapsulé sur SCTP et IP afin d’être transporté à travers le réseau N2.

Le second processus a lieu dans le réseau de transport et le centre de données. Ces équipements réseau n’ont pas besoin de savoir si la charge utile contient un Registration Request ou une procédure Initial Context Setup. Ils utilisent le routage IP de couche 3 et le transfert MAC de couche 2 pour faire progresser le paquet saut par saut vers l’environnement de calcul qui exécute le service AMF.

En pratique, la méthode la plus efficace pour dépanner N2 consiste donc à conserver une vue de bout en bout :

UE NAS → relais gNB → NGAP → SCTP → routage IP → transfert de couche 2 → serveur AMF → processus AMF

Une fois cette chaîne suivie couche par couche, de nombreux problèmes qui semblaient d’abord être des « échecs d’enregistrement », des défauts « N2 inaccessible » ou des « échecs d’association SCTP » complexes peuvent être ramenés à une question beaucoup plus précise : à quelle couche et à quel saut le paquet s’est-il arrêté ?

Questions fréquentes

La signalisation N2 passe-t-elle par l’UPF ?

Dans une architecture 5G normale, le chemin du plan de contrôle N2 ne dépend pas de l’UPF. N2 relie le gNB et l’AMF, tandis que l’UPF participe principalement au chemin du plan utilisateur. Lorsque N2 est inaccessible, le dépannage doit se concentrer sur le chemin de transport du plan de contrôle entre le gNB et l’AMF plutôt que de commencer par le tunnel du plan utilisateur N3.

Pourquoi les adresses MAC changent-elles lorsqu’on capture le même paquet N2 à différents endroits ?

Les adresses MAC appartiennent au segment de couche 2 courant. Après qu’un paquet a traversé un équipement de routage de couche 3, il est encapsulé avec un nouvel en-tête de couche 2 pour le lien suivant. Les adresses MAC source et destination peuvent donc changer d’un saut à l’autre, même si les adresses IP de bout en bout du gNB et de l’AMF restent associées au même flux de communication N2.

Pourquoi SCTP peut-il encore échouer même si le gNB peut pinguer l’AMF ?

Le ping vérifie principalement la connectivité IP basée sur ICMP. SCTP dépend aussi du traitement des ports de transport, de la liaison IP locale, des ACL, des pare-feu, des politiques de sécurité et du processus applicatif AMF. La connectivité IP n’est donc qu’un prérequis à la communication N2 et ne garantit pas le bon fonctionnement de SCTP ou NGAP.

Si l’AMF s’exécute dans une machine virtuelle, le gNB doit-il connaître l’emplacement physique du serveur ?

Non. Le gNB établit la connexion N2 en utilisant l’adresse IP du service N2 de l’AMF plutôt que l’emplacement physique du serveur. L’hôte physique, le commutateur virtuel, le mappage de la VM et la topologie interne du centre de données sont des détails d’implémentation, mais ils doivent néanmoins acheminer les paquets destinés au point d’extrémité N2 de l’AMF vers la bonne instance de service.

Pourquoi faut-il vérifier à la fois les routes aller et retour lors de problèmes N2 ?

NGAP et SCTP sont tous deux bidirectionnels. Même si les paquets du gNB peuvent atteindre l’AMF, l’échange SCTP et les procédures NGAP suivantes échoueront toujours si l’AMF ne dispose pas d’une route valide vers le sous-réseau du gNB. Une connectivité à sens unique ne suffit donc pas à prouver que le chemin N2 est complet.