Lorsque les ingénieurs découvrent pour la première fois les interfaces du cœur 5G, ils commencent souvent par mémoriser de N1 à N50 : les fonctions réseau aux deux extrémités, le protocole utilisé et l’équivalent le plus proche en 4G. Cette méthode peut être utile au début, mais elle devient rapidement insuffisante lors du déploiement, de l’analyse de signalisation et du dépannage. En pratique, les questions les plus utiles sont les suivantes : cette interface relève-t-elle de l’accès, de la gestion de session, du contrôle de politique ou du plan utilisateur ? Transporte-t-elle du NAS, du GTP-U, du PFCP ou un service SBI ? Et lorsqu’un problème survient, quel chemin de contrôle faut-il suivre ensuite ?

Il s’agit également de l’une des différences architecturales les plus importantes entre 5GC et EPC. La 5G ne se contente pas de renommer des interfaces telles que S1, S11, Gx et S6a. Elle conserve un certain nombre d’interfaces de point de référence tout en introduisant l’architecture basée sur les services, ou SBA, qui permet aux fonctions réseau du plan de contrôle d’interagir par des appels de service. Pour cette raison, il est préférable d’analyser les interfaces 5GC à la fois du point de vue des points de référence et du point de vue des services SBA.

Comment comprendre la SBA et l’architecture de points de référence

Deux approches sont utiles pour appréhender la 5GC. La première est l’architecture traditionnelle de points de référence, qui décrit la relation logique entre deux entités fonctionnelles, par exemple N1 entre l’UE et l’AMF, N2 entre le gNB et l’AMF, N3 entre le gNB et l’UPF, et N4 entre le SMF et l’UPF. La seconde est la vue SBA, dans laquelle les fonctions du plan de contrôle telles que AMF, SMF, PCF, UDM, AUSF, NSSF, NEF et NRF sont considérées comme des producteurs et des consommateurs de services.

Ces deux vues ne sont pas contradictoires. Le modèle à points de référence est utile pour suivre les chemins de signalisation de bout en bout, tandis que la SBA fournit un cadre plus clair pour comprendre la découverte dynamique des fonctions réseau, l’invocation de services et l’extension des services.

N2, par exemple, présente une relation d’extrémité très claire : le gNB se connecte à l’AMF et utilise NGAP pour transporter la signalisation NAS et prendre en charge la gestion des connexions. N3 relie le gNB à l’UPF et transporte le trafic du plan utilisateur via GTP-U. Les interfaces de ce type possèdent une caractéristique de chemin point à point clairement définie.

En revanche, lorsque l’AMF accède à l’UDM, à l’AUSF ou au PCF, l’attention se déplace vers les services exposés par ces fonctions réseau. N8 est utilisée entre l’AMF et l’UDM pour obtenir les informations d’abonnement liées à la gestion de mobilité, N12 prend en charge la gestion de l’authentification entre l’AMF et l’AUSF, et N15 permet à l’AMF d’obtenir des politiques liées à la mobilité. Ces relations illustrent la migration du plan de contrôle 5GC des protocoles dédiés traditionnels vers des interactions de service basées sur HTTP/2.

Cela signifie que, lors de l’analyse de captures de paquets ou de schémas d’architecture, les ingénieurs ne doivent pas considérer une interface comme N8 comme une simple connexion physique fixe. Il est plus important de déterminer quelle NF consomme quel service, comment l’instance de service a été découverte et à quelle étape de la procédure de service appartient la transaction HTTP/2.

Comment regrouper les principales interfaces ?

Au lieu de mémoriser les numéros d’interface un par un, une méthode plus pratique consiste à les regrouper selon la fonction réseau qu’ils prennent en charge. Lorsqu’un message de signalisation apparaît, les ingénieurs peuvent d’abord identifier sa catégorie fonctionnelle, puis réduire l’analyse jusqu’à l’interface concernée.

Chemins d’accès et du plan utilisateur

N1, N2 et N3 constituent le groupe d’interfaces le plus fondamental du côté accès 5G. N1 fonctionne entre l’UE et l’AMF et transporte des informations de gestion de mobilité et de gestion de session dans le NAS 5G. N2 relie le gNB et l’AMF, utilise NGAP pour transporter la signalisation NAS et prend en charge la gestion des connexions. N3 relie le gNB et l’UPF et transporte le trafic réel du plan utilisateur via GTP-U.

Dans le cœur de réseau, les UPF peuvent continuer à transférer le trafic utilisateur sur N9 à l’aide de GTP-U, tandis que l’UPF se connecte au réseau de données externe, ou DN, via N6. Le trafic sur N6 n’est plus une signalisation de contrôle propre à la 5G ; il s’agit d’un trafic IP de couche applicative tel que du contenu Web, des images, des vidéos et d’autres données utilisateur.

Par conséquent, si l’enregistrement de l’UE réussit et que la session PDU est établie, mais que le trafic applicatif ne passe toujours pas, le dépannage doit généralement quitter le plan de contrôle de l’AMF pour se concentrer sur N3, le comportement de transfert de l’UPF, N6 et le DN externe.

Contrôle de session et du plan utilisateur

N4 est l’une des interfaces de contrôle les plus importantes de la 5GC. Elle fonctionne entre le SMF et l’UPF et utilise PFCP. Le SMF gère le contrôle de session tandis que l’UPF assure le transfert des paquets ; N4 sert donc à installer les règles de transfert et à contrôler le comportement du plan utilisateur.

N11 relie l’AMF et le SMF et prend principalement en charge la signalisation de gestion des sessions PDU. Lorsqu’un UE lance un établissement de session PDU, l’AMF transmet la demande de gestion de session au SMF pour la suite du traitement. Si l’enregistrement réussit mais que l’établissement de la session PDU échoue, N11 et les procédures SMF qui suivent constituent généralement des points importants de dépannage.

N16 prend en charge les interactions entre instances SMF, notamment les procédures liées à la resélection de SMF. Par rapport à l’EPC, la 5GC répartit les fonctions de contrôle sur un plus grand nombre de NF indépendantes. Les responsabilités autrefois concentrées dans le MME, le SGW ou le PGW sont distribuées entre des fonctions telles que AMF, SMF, PCF et UDM, créant ainsi de nouvelles relations de service.

Politiques, authentification et données d’abonnement

Le contrôle de politique est principalement centré sur le PCF. N7 relie le SMF et le PCF et sert à demander des politiques liées à la gestion de session. N5 fonctionne entre le PCF et l’AF et transporte des paramètres et des exigences de service au niveau applicatif. N15 permet à l’AMF d’obtenir des politiques liées à la mobilité.

Pour les données d’abonnement, N8 permet à l’AMF d’accéder à l’UDM et de récupérer des informations d’abonnement liées à la gestion de mobilité, tandis que N10 relie le SMF et l’UDM afin d’obtenir les données d’abonnement liées à la gestion de session. L’authentification est en outre séparée entre N12, entre l’AMF et l’AUSF, et N13, entre l’AUSF et l’UDM.

Cette séparation est particulièrement importante. Dans l’EPC, le HSS assurait une grande partie des fonctions liées aux données d’abonné et à l’authentification. Dans la 5GC, les responsabilités sont réparties plus précisément entre UDM, AUSF et les fonctions de stockage de données associées. Lorsqu’une authentification échoue, il ne suffit plus de vérifier si les données de l’abonné existent. Il faut également déterminer si l’échec s’est produit lorsque l’AMF a lancé l’authentification, pendant le traitement AUSF ou lorsque l’AUSF a tenté de récupérer les informations nécessaires auprès de l’UDM.

Que gèrent les interfaces de service avancées ?

L’évolutivité du modèle d’interfaces 5GC devient particulièrement claire au-delà de N1 à N16. À mesure que sont introduits le découpage réseau, l’exposition de capacités, l’analyse réseau, l’itinérance et le découplage des données, davantage d’interfaces sont établies autour de fonctions réseau indépendantes.

N22 relie l’AMF et le NSSF pour la sélection de tranche réseau. N34 relie le NSSF et le NWDAF afin que l’analyse réseau puisse soutenir les décisions liées aux tranches. Le NWDAF peut également fournir des informations analytiques au PCF via N23, permettant aux données d’analyse d’aider à la prise de décision en matière de politique. Le contrôle de politique n’a ainsi plus besoin de reposer uniquement sur des informations d’abonnement statiques et des règles prédéfinies.

L’exposition de capacités concerne principalement le NEF. N29 fonctionne entre le SMF et le NEF, tandis que N30 relie le NEF et le PCF. N33 prend en charge l’invocation de services entre les API et l’AF. Le NEF occupe donc une position importante entre les applications externes et les capacités du cœur de réseau, en fournissant un moyen contrôlé d’exposer les fonctions réseau aux services côté application.

Le stockage des données est lui aussi davantage séparé. N35 relie l’UDM et l’UDR pour le stockage des données d’abonnement, N36 relie le PCF et l’UDR pour le stockage des données de politique, et N37 permet au NEF d’accéder à l’UDR pour les données liées à l’exposition de capacités et aux applications. L’UDSF est également utilisé pour le stockage de données non structurées, ce qui favorise la séparation des fonctions de calcul et de stockage.

Dans les scénarios d’itinérance et d’interconnexion entre opérateurs, d’autres interfaces interviennent : N24 entre le PCF visité et le PCF du réseau d’origine, N27 entre le NRF visité et le NRF d’origine, N31 entre V-NSSF et H-NSSF, et N32 entre V-SEPP et H-SEPP. SEPP assure le contrôle de sécurité aux frontières entre opérateurs. Ces interfaces peuvent être peu courantes dans un environnement de test local à opérateur unique, mais elles deviennent importantes lors de l’analyse d’architectures d’itinérance.

Les fonctions de taxation évoluent elles aussi du modèle traditionnel basé sur Diameter vers des interactions basées sur les services. N28 relie le PCF et le CHF afin que les informations de taxation puissent soutenir les décisions relatives aux règles PCC, tandis que N40 relie le SMF et le CHF. N41 à N49 sont réservées dans la plage correspondante des spécifications. Une autre interface spécialisée est N50, qui relie l’AMF et le CBCF pour les services d’alerte publique et d’alerte en cas de catastrophe.

Que faut-il considérer lors du mappage entre 5GC et EPC ?

L’expérience acquise avec l’EPC est très utile pour passer de la 4G à la 5G, mais la relation ne doit pas être interprétée comme un remplacement mécanique un pour un. Les similitudes entre les interfaces 5GC et EPC constituent principalement des références fonctionnelles et non des équivalences exactes.

Certaines correspondances sont relativement intuitives. N2 peut être comparée fonctionnellement à S1-MME, tandis que N3 ressemble à S1-U. N4 est fonctionnellement proche de Sxa, Sxb et Sxc dans une architecture EPC basée sur CUPS. N7 peut être comparée à Gx du point de vue du contrôle de politique, tandis que N5 aide à comprendre le rôle de politique applicative traditionnellement associé à Rx.

Des schémas de migration similaires apparaissent également dans les fonctions d’abonnement et d’authentification. N8 peut être comparée fonctionnellement à une partie de l’interaction S6a entre le MME et le HSS. N14, qui prend en charge la gestion de mobilité entre AMF, peut être comparée à S10 entre MME, tandis que N17, utilisée pour vérifier l’identité de l’équipement, correspond fonctionnellement à l’interaction S13 entre le MME et l’EIR.

Cependant, de nombreuses interfaces 5GC n’ont aucun équivalent direct en 4G. C’est notamment le cas de N22 pour la sélection de tranche, N23 pour l’analyse réseau, N27 pour la découverte NRF interdomaines et des interfaces entourant le stockage de données basé sur UDR. Ces relations ont été introduites avec l’architecture basée sur les services et le découplage fonctionnel accru de la 5GC.

Une meilleure méthode de migration consiste donc à comparer d’abord les fonctions, puis les mécanismes de signalisation, plutôt qu’à forcer chaque interface N à correspondre à une interface S ou à un point de référence Diameter. L’évolution des protocoles est particulièrement marquée : la signalisation du plan de contrôle EPC reposait fortement sur Diameter et GTPv2, tandis que de nombreuses interactions du plan de contrôle 5GC utilisent désormais des services SBI basés sur HTTP/2.

Une méthode pratique d’analyse des interfaces 5GC

Dans l’analyse réelle de la signalisation 5GC, il est souvent plus efficace de partir du symptôme de service et de remonter le chemin que de partir d’un numéro d’interface. Si l’UE ne parvient pas à s’enregistrer, commencez par N1, N2 et les procédures d’authentification AMF et de données d’abonné qui suivent. Si l’enregistrement réussit mais que la session PDU échoue, poursuivez avec N11, le SMF, N7, N10 et N4. Si la session PDU réussit mais que le trafic utilisateur n’atteint pas le réseau de données, déplacez l’attention vers N3, le transfert UPF et N6.

Pour les problèmes de politique, poursuivez avec N7 et la chaîne de signalisation liée au PCF. Pour les problèmes de sélection de tranche, concentrez-vous sur N22 entre l’AMF et le NSSF. Pour l’exposition de capacités ou les exigences de politique pilotées par les applications, étendez l’analyse aux interfaces liées à NEF, AF et PCF. Une fois établie une correspondance en quatre niveaux « étape du service — fonction réseau — interface — protocole », les dizaines d’interfaces N deviennent beaucoup plus faciles à interpréter.

De l’étude de l’architecture au dépannage d’un réseau en production, l’essentiel de l’analyse des interfaces 5GC consiste à comprendre la relation entre les fonctions. La couche d’accès fait entrer l’UE dans le cœur de réseau, la gestion de session établit la session PDU, les services de politique et d’abonnement déterminent comment cette session doit être traitée, le plan utilisateur transporte le trafic applicatif réel, et la SBA permet aux fonctions du plan de contrôle de coopérer au moyen d’interactions basées sur les services. Comprendre cette logique de bout en bout apporte davantage de valeur d’ingénierie que mémoriser une table complète d’interfaces.

Questions fréquentes

Un numéro d’interface N plus élevé signifie-t-il une fonction plus récente ?

Non. Les numéros d’interface N servent à identifier des points de référence logiques et n’indiquent ni la génération technologique, ni l’importance, ni l’ordre chronologique. N1, N2 et N3 font partie des interfaces 5GC les plus fondamentales, tandis que les numéros plus élevés comprennent à la fois des relations fonctionnelles plus récentes et des points de référence réservés.

Toutes les interfaces du plan de contrôle 5GC utilisent-elles HTTP/2 ?

Non. De nombreuses interactions du plan de contrôle liées à la SBA utilisent HTTP/2, mais la 5GC comprend plusieurs autres protocoles. N2 utilise NGAP, N3 et N9 utilisent GTP-U, N4 utilise PFCP, et les communications entre l’UE et l’AMF impliquent également le NAS 5G. Le dépannage doit donc commencer par l’identification du type d’interface avant de choisir la méthode d’analyse de protocole appropriée.

Pourquoi le nom de l’interface N est-il parfois absent des captures de paquets ?

Les noms d’interface N représentent des points de référence logiques dans l’architecture. Les captures de paquets affichent généralement le protocole réel, tel que HTTP/2, NGAP, PFCP ou GTP-U, ainsi que les adresses IP des fonctions réseau qui communiquent. L’interface N logique doit donc être identifiée à partir du rôle des deux NF et de la procédure de service analysée.

Un réseau de test 5GC doit-il déployer toutes les interfaces définies ?

Non. Les interfaces qui apparaissent réellement dépendent de la taille du réseau, des services activés et de la prise en charge éventuelle de fonctions telles que l’itinérance, le découpage réseau, l’exposition de capacités, l’analyse réseau ou les services d’alerte publique. L’enregistrement de base et la connectivité de données n’utilisent qu’une partie du cadre complet des interfaces 5GC.