Un smartphone peut déjà afficher l’icône 5G alors que les pages Web refusent toujours de se charger. Dans ce cas, le premier réflexe consiste souvent à vérifier la procédure de Registration : le 5G-AKA s’est-il terminé ? Un Registration Accept a-t-il été reçu ? T3512 a-t-il expiré ? Après ces vérifications, la procédure de Registration peut sembler parfaitement normale alors que le service de données ne fonctionne toujours pas.
Dans de nombreux cas, le problème ne vient pas de Registration, mais de la PDU Session. Registration répond à la question « l’UE peut-il s’enregistrer sur le 5GS ? ». PDU Session Establishment répond à la suivante : « l’UE peut-il réellement accéder à un réseau de données ? ». Cet article suit la procédure d’établissement d’une session PDU de bout en bout : comment l’UE demande une session, comment l’AMF sélectionne un SMF, comment le SMF récupère les informations d’abonnement et de politique, comment l’UPF est configuré et comment le tunnel N3 est finalement établi.
Une fois le 5GS Registration terminé, l’AMF dispose déjà de l’identité de l’utilisateur, du contexte de mobilité, de sécurité et des informations d’abonnement associées. Toutefois, la réussite de l’enregistrement ne signifie pas qu’un chemin de plan utilisateur existe déjà. L’UE peut encore ne disposer d’aucun chemin actif vers Internet ou vers un réseau de données d’entreprise.
PDU Session Establishment fait passer l’UE de l’état « enregistré » à l’état « capable de transporter le trafic des applications ». L’UE demande une session, le réseau sélectionne le SMF et l’UPF, récupère les données d’abonnement associées au DNN et au S-NSSAI, obtient la politique de session, installe les règles PFCP dans l’UPF et se coordonne avec le gNB afin d’établir le tunnel N3. À la fin de la procédure, l’UE dispose d’une adresse IP, de règles QoS et d’un chemin de plan utilisateur vers le Data Network.
La procédure est plus facile à comprendre si elle n’est pas considérée comme un message NAS isolé. Trois opérations se déroulent en parallèle : gestion de session, contrôle de politique et configuration des ressources du plan utilisateur. Elles convergent finalement vers une PDU Session utilisable.
Frontière fonctionnelle entre la session PDU et l’enregistrement 5GS
Dans le 5GC, la séparation entre Registration et PDU Session est simple : le premier établit l’enregistrement réseau, la seconde établit la connectivité de données.
Registration détermine si l’UE peut accéder au 5GS. L’AMF vérifie l’identité de l’UE, effectue l’authentification, établit la sécurité NAS, récupère les données d’abonnement liées à la mobilité et crée le contexte requis pour RM (Registration Management) et CM (Connection Management). Une fois ces étapes terminées, la relation de gestion entre l’UE et le cœur de réseau est établie.
Une PDU Session est liée au service de données réel. Si l’UE doit accéder à Internet, à une connectivité IMS ou à un réseau privé d’entreprise, Registration seul ne suffit pas. Le réseau doit encore déterminer le DNN à utiliser, le S-NSSAI applicable, le SMF qui contrôle la session, l’UPF qui transporte le plan utilisateur ainsi que les paramètres QoS et de bande passante autorisés.
La comparaison avec l’EPC permet de mieux retenir la différence. LTE utilise les concepts de PDN Connection et d’EPS Bearer. Dans le 5GC, ce modèle est remplacé par PDU Session + QoS Flow. Une fois la PDU Session établie, le réseau crée des règles QoS et des ressources QoS Flow plutôt qu’un Default EPS Bearer de type LTE.
Autre point important : une PDU Session n’a pas besoin d’être établie en même temps que le Registration initial. Un UE peut terminer Registration et rester sans PDU Session jusqu’à ce qu’une application ait réellement besoin d’un service de données. Par exemple, le terminal peut s’enregistrer au démarrage, mais la PDU Session ne sera créée que lorsque l’utilisateur ouvrira une application vidéo une demi-heure plus tard.
Cette distinction est utile lors de l’analyse des traces. Si Registration s’est terminé correctement mais que PDU Session Establishment n’a pas abouti, vérifier à répétition 5G-AKA, Registration Accept ou T3512 ne résoudra généralement pas le problème de service de données, car l’analyse porte sur la mauvaise procédure.
DNN, S-NSSAI et type de requête dans la demande de session PDU
PDU Session Establishment commence par un message NAS envoyé par l’UE. Un PDU Session Establishment Request ne se contente pas d’indiquer au cœur de réseau « j’ai besoin d’un accès aux données ». Les éléments d’information transportés dans la demande influencent la sélection ultérieure des NF et la configuration de la session.
Une demande initiale typique peut inclure PDU Session ID, Request Type, PDU Session Type, SSC Mode, DNN et S-NSSAI.
PDU Session ID permet de distinguer plusieurs sessions appartenant au même UE. Un UE peut maintenir plusieurs PDU Sessions simultanément, par exemple une pour l’accès à Internet et une autre pour un réseau privé d’entreprise. SUPI identifie l’abonné, mais ne permet pas à lui seul d’identifier la PDU Session individuelle en cours de traitement.
DNN identifie le Data Network que l’UE souhaite atteindre. L’accès Internet de l’opérateur, IMS et les réseaux d’entreprise peuvent utiliser des DNN différents. Le DNN intervient également dans la sélection du SMF, la sélection de l’UPF et les décisions de politique plus tard dans la procédure.
S-NSSAI associe la session à une tranche de réseau (Network Slice) particulière. L’AMF et le SMF doivent déterminer si la tranche demandée est compatible avec l’abonnement de l’utilisateur, le DNN demandé et les capacités du réseau déployé.
Request Type indique le contexte de la demande. Outre une nouvelle PDU Session, la procédure peut également concerner une session existante, un changement d’accès ou un scénario de service d’urgence. Lors de l’analyse des traces, la présence d’un PDU Session Establishment Request ne doit donc pas être automatiquement interprétée comme correspondant au même scénario à chaque fois.
Le cas le plus courant est un Initial Request : l’UE a déjà terminé Registration et crée maintenant une nouvelle PDU Session pour un DNN donné. La sélection du SMF, la récupération des données d’abonnement UDM, le contrôle de politique PCF et l’établissement des ressources UPF sont tous pilotés par ce contexte de session.
Sélection du SMF et création du SM Context par l’AMF
Le message NAS de gestion de session de l’UE atteint d’abord le gNB, puis est transmis à l’AMF via NGAP avec des informations liées à l’accès, telles que NR-CGI et TAI. Le gNB ne prend pas les décisions de contrôle de la PDU Session ; il transporte les informations NAS vers le cœur de réseau.
Après réception de la demande, l’AMF doit identifier un SMF capable de servir le S-NSSAI et le DNN demandés.
Dans une architecture 5GC orientée services, l’AMF peut utiliser le NRF pour la découverte des NF. Les critères de découverte peuvent inclure le type de NF cible, le service Nsmf_PDUSession requis, le S-NSSAI, le DNN et le PLMN de service. Le NRF renvoie des instances SMF candidates, puis l’AMF sélectionne le SMF qui assurera effectivement le service selon la politique du réseau.
L’AMF invoque ensuite le service PDU Session du SMF afin de créer un SM Context. En plus du SUPI, du PDU Session ID, du DNN et du S-NSSAI, la demande transporte le PDU Session Establishment Request d’origine de l’UE sous forme d’information N1 SM.
À partir de ce point, le centre de contrôle de la session passe de l’AMF au SMF. L’AMF continue à gérer l’accès et la mobilité et à relayer la signalisation N1 SM entre l’UE et le SMF, mais c’est le SMF qui décide comment créer la PDU Session, quel UPF sélectionner, quelles politiques appliquer et comment configurer les règles du plan utilisateur.
Un point pratique est important lors du dépannage : le nombre de transactions NRF observées dans un réseau commercial peut ne pas correspondre exactement à un diagramme de signalisation de référence. Les résultats de découverte NF peuvent être mis en cache, une configuration statique peut être utilisée ou un SCP peut assurer le routage des services. La question essentielle n’est pas de savoir si une requête NRF précise apparaît dans la trace, mais si le SMF sélectionné prend réellement en charge le DNN, le S-NSSAI et les capacités de service requis.
Données d’abonnement UDM et traitement de la politique de session PCF
Une fois que le SMF comprend le type de session demandé par l’UE, il ne peut pas encore créer immédiatement le plan utilisateur. Il doit d’abord déterminer quel type de PDU Session l’abonné est effectivement autorisé à établir.
Dans une procédure typique, le SMF localise l’UDM approprié, s’enregistre comme SMF desservant le SUPI et la PDU Session, puis récupère les Session Management Subscription Data associés au S-NSSAI et au DNN demandés.
Les données d’abonnement peuvent contenir le PDU Session Type autorisé, le SSC Mode, le Session-AMBR et les paramètres QoS par défaut. Ces valeurs définissent les limites de la session au niveau de l’abonné. Par exemple, si l’UE demande une PDU Session IPv4, le SMF doit encore vérifier que le DNN autorise ce PDU Session Type et que le SSC Mode demandé est permis.
Le SMF peut également s’abonner aux modifications des données d’abonnement SM. Si l’abonnement de gestion de session concerné est ultérieurement modifié dans l’UDM, celui-ci peut notifier le SMF desservant via le Callback URI enregistré.
Si le déploiement utilise un contrôle dynamique de politique SM, le SMF sélectionne un PCF et établit une SM Policy Association. Le SMF fournit un contexte tel que SUPI, PDU Session ID, DNN, S-NSSAI, la localisation de l’UE et les paramètres QoS souscrits. Le PCF renvoie ensuite la politique de session autorisée, qui peut inclure le Session-AMBR, la QoS par défaut et d’autres règles de politique applicables.
Cette étape peut être considérée comme une convergence des paramètres de session :
Demande de service UE → limites d’abonnement UDM → autorisation de politique PCF → le SMF finalise les paramètres de contrôle de session
Les règles QoS et de transfert installées ultérieurement dans l’UPF reposent sur ces résultats.
Établissement de session N4 et installation des règles du plan utilisateur dans l’UPF
Une fois les paramètres de session déterminés, le SMF sélectionne un UPF capable de servir le DNN, le S-NSSAI et la localisation UE demandés, puis établit une PFCP Session sur l’interface N4.
PFCP Session Establishment Request constitue l’un des points les plus importants de la procédure PDU Session Establishment. Jusqu’à cette étape, le réseau a principalement travaillé avec des exigences de service abstraites. Sur N4, ces exigences sont converties en règles que l’UPF peut exécuter sur les paquets utilisateur réels.
Le SMF peut installer des règles PDR, FAR, QER et URR dans l’UPF :
PDR : indique à l’UPF comment identifier les paquets appartenant à la PDU Session ou à un flux de trafic particulier ;
FAR : définit l’action à appliquer aux paquets correspondants, par exemple transfert, rejet, mise en mémoire tampon ou autre action appropriée ;
QER : applique dans l’UPF les contrôles QoS requis ;
URR : définit les exigences de mesure et de rapport d’utilisation du plan utilisateur.
Ces règles ne doivent pas être considérées comme quatre fonctions sans lien. Ensemble, elles définissent la manière dont l’UPF traite le trafic. Le PDR identifie le flux de paquets et référence les FAR, QER et URR applicables afin que l’UPF sache où envoyer les paquets, quels contrôles QoS appliquer et s’il faut mesurer l’utilisation.
Lorsque l’UPF accepte le PFCP Session Establishment, il renvoie son F-SEID et les paramètres de plan utilisateur qu’il a créés. L’un des résultats les plus importants est l’adresse de plan utilisateur côté UPF et le TEID utilisés pour N3.
À ce stade, le chemin descendant peut toutefois rester incomplet, car le gNB n’a pas encore terminé l’allocation de ses ressources N3. PDU Session Establishment ne se termine donc pas avec une seule requête PFCP. La procédure doit encore attendre que le RAN termine sa partie de la configuration du plan utilisateur.
La signalisation N1/N2 finalise le tunnel N3 et la configuration des QoS Flow
Une fois les ressources côté UPF prêtes, le SMF doit renvoyer deux ensembles d’informations distincts via l’AMF.
Le premier est N1 SM information, finalement transmis à l’UE. Il contient le PDU Session Establishment Accept ainsi que les paramètres dont l’UE a besoin après l’établissement de la session, tels que PDU Session Type, SSC Mode, DNN, S-NSSAI, l’adresse IP de l’UE, Session-AMBR et la QoS Rule par défaut.
Le second est N2 SM information, destiné au gNB. Il indique au RAN quelle PDU Session est en cours de création, quels QoS Flows sont concernés et quelle adresse IP UPF ainsi que quel TEID doivent être utilisés sur N3.
L’AMF envoie un PDU Session Resource Setup Request au gNB via NGAP. Le gNB alloue les ressources radio et N3 requises et transmet le PDU Session Establishment Accept à l’UE.
Après la configuration des ressources, le gNB renvoie un PDU Session Resource Setup Response contenant sa propre adresse de plan utilisateur N3 et son TEID, ainsi que des informations sur les QoS Flows établis avec succès.
Un détail de séquencement est important ici. Lorsque le SMF a initialement établi la PFCP Session, il connaissait déjà les informations N3 côté UPF, mais il ne connaissait peut-être pas encore les informations finales du tunnel côté gNB. Une fois que le gNB renvoie son adresse N3 et son TEID, l’AMF transmet ces informations au SMF. Le SMF utilise alors PFCP Session Modification pour mettre à jour le FAR concerné dans l’UPF afin que les paquets descendants puissent être encapsulés dans le bon tunnel GTP-U vers le gNB.
À ce stade, les chemins montant et descendant du plan utilisateur sont complets :
UE → gNB → N3 GTP-U → UPF → N6 → Data Network
Data Network → N6 → UPF → N3 GTP-U → gNB → UE
C’est pourquoi la réception d’un PDU Session Establishment Accept ne prouve pas à elle seule que tous les éléments du plan utilisateur sont corrects. Les paramètres du tunnel N3, PFCP Session Modification et les règles finales de l’UPF doivent encore être vérifiés par rapport au transfert réel des paquets.
Dépannage de la signalisation lors de l’établissement d’une session PDU
PDU Session Establishment implique de nombreuses fonctions réseau. Dépanner la procédure en comparant chaque message depuis le premier paquet peut rapidement devenir confus. Une méthode plus efficace consiste à diviser la procédure en plusieurs points de contrôle et à réduire progressivement le domaine de panne.
Vérifier que la demande de session atteint correctement l’AMF
Vérifiez d’abord que l’UE a terminé le 5GS Registration requis. Examinez ensuite le PDU Session Establishment Request et vérifiez que PDU Session ID, Request Type, DNN, S-NSSAI, PDU Session Type et SSC Mode sont appropriés. Si la demande contient déjà un paramètre invalide au point d’entrée, même un SMF et un UPF fonctionnant correctement ne pourront pas produire la session attendue.
Vérifier que le SMF crée un SM Context valide
Vérifiez ensuite que l’AMF sélectionne un SMF approprié et que Create SM Context réussit. L’objectif n’est pas simplement de trouver un message NRF dans la trace, mais de confirmer que le SMF sélectionné prend en charge le DNN, le S-NSSAI et les capacités de service requis.
Vérifiez ensuite que les données d’abonnement SM renvoyées par l’UDM autorisent la PDU Session demandée et que la politique PCF est cohérente avec la configuration QoS attendue.
Vérifier que les ressources UPF et N3 sont complètes
Si le plan de contrôle a déjà renvoyé PDU Session Establishment Accept mais que l’UE ne peut toujours pas transporter de données, l’analyse doit descendre jusqu’à N4 et N3.
Vérifiez dans l’ordre :
si PFCP Session Establishment réussit et si l’UPF crée la session correspondante ;
si les règles PDR, FAR, QER et autres correspondent au sens de trafic attendu ;
si le gNB renvoie correctement son adresse IP de plan utilisateur N3 et son TEID ;
si le SMF met à jour l’UPF avec les informations du tunnel gNB via PFCP Session Modification ;
si des paquets GTP-U utilisant le TEID attendu apparaissent réellement sur N3 ;
si l’UPF peut correctement envoyer et recevoir du trafic vers le Data Network cible via N6.
Cette séquence permet de limiter le problème à NAS, SBI, N4, N3 ou au transfert de paquets UPF, au lieu de considérer l’ensemble du 5GC comme un domaine de panne unique et indifférencié.
Questions fréquentes
Pourquoi un UE peut-il terminer l’enregistrement 5G sans pouvoir accéder à Internet ?
Registration établit le contexte d’accès, d’identité, de sécurité et de mobilité entre l’UE et le 5GC. Il ne crée pas automatiquement un chemin de données utilisateur. Avant que l’UE puisse accéder à Internet ou à un autre Data Network, une PDU Session reste nécessaire afin que le SMF puisse configurer les paramètres de session, les ressources UPF et le plan utilisateur N3.
Une PDU Session est-elle toujours établie lorsque l’UE s’allume ?
Non. Une PDU Session peut être établie autour du moment de Registration, mais elle peut aussi être initiée plus tard lorsque l’UE a réellement besoin d’un service de données. Le 5GS permet à un UE de rester enregistré sans PDU Session active ; la fin de Registration et PDU Session Establishment ne doivent donc pas être traitées comme un seul et même événement.
La réussite de PDU Session Establishment garantit-elle que l’UE peut accéder à Internet ?
Non. Un PDU Session Establishment Accept au niveau NAS ne constitue pas à lui seul une preuve suffisante de connectivité de données. Le trafic utilisateur réel dépend également du tunnel N3 entre le gNB et l’UPF, des règles PDR/FAR/QER dans l’UPF, de la connexion N6 et du Data Network cible. Un UE peut recevoir une adresse IP alors que le transfert du plan utilisateur reste incorrect.
Pourquoi PFCP Session Modification intervient-il après PFCP Session Establishment ?
Lorsque la PFCP Session initiale est créée dans l’UPF, le gNB peut ne pas avoir encore terminé l’allocation de ses ressources N3 ; le SMF peut donc ne pas encore connaître l’adresse IP de plan utilisateur et le TEID définitifs du gNB. Une fois que le gNB renvoie ces valeurs dans le PDU Session Resource Setup Response, le SMF met à jour les règles UPF correspondantes via PFCP Session Modification afin que le trafic descendant puisse être envoyé dans le bon tunnel N3 GTP-U.
Le QFI d’une PDU Session et le QER sur l’interface N4 désignent-ils le même concept ?
Non. Le QFI identifie un QoS Flow dans le 5GS, tandis que le QER est une QoS Enforcement Rule configurée par le SMF dans l’UPF via N4. Un QER participe à l’application de la QoS et peut être associé à un QFI lorsque cela s’applique, mais le QFI lui-même n’est pas un QER et les deux concepts ne doivent pas être considérés comme interchangeables.
