Prenons une session PDU déjà établie qui transporte normalement du trafic. L'UE possède une adresse IP, le gNB conserve les ressources de session PDU et les flux QoS correspondants, et l'UPF dispose d'une session PFCP active pour l'acheminement du plan utilisateur. Si l'utilisateur décide de mettre fin à la connexion de données, si une fonction de politique exige la terminaison de la session ou si le réseau estime qu'elle ne doit plus rester active, le 5GC ne se contente plus de modifier quelques paramètres QoS. Il doit supprimer la session à la fois dans le plan de contrôle et le plan utilisateur.
C'est précisément le rôle de la libération de session PDU. Cette procédure définit la suppression d'une session PDU établie : effacement du contexte 5GSM côté UE, libération des ressources RAN, suppression de la session N4 et de l'état d'acheminement dans l'UPF, puis terminaison de l'association de politiques concernée, le cas échéant. L'objectif est d'amener l'AMF, le SMF, le gNB, l'UPF et l'UE à un état cohérent où cette session PDU n'existe plus.
Cette procédure ne se situe pas au même niveau que l'enregistrement (Registration). Un UE peut libérer une session PDU tout en restant enregistré auprès du 5GS, et les autres sessions PDU actives peuvent continuer à fonctionner. Pour analyser la signalisation, l'essentiel est de suivre la manière dont les ressources liées à un identifiant précis de session PDU sont supprimées de l'UE, du RAN, du SMF, de l'UPF et des couches de contrôle des politiques, plutôt que de reprendre l'analyse des traces à partir de Registration Request.
Différences entre libération, établissement, modification et désenregistrement
L'établissement, la modification et la libération d'une session PDU ainsi que le désenregistrement 5GS peuvent figurer dans les mêmes traces, mais répondent à des besoins très différents.
| Procédure | Objectif principal | État obtenu |
|---|---|---|
| Établissement de session PDU | Créer une nouvelle session de données et des ressources du plan utilisateur | Une nouvelle session PDU devient active |
| Modification de session PDU | Modifier la QoS, les politiques ou les ressources d'une session existante | La session PDU reste active |
| Libération de session PDU | Terminer une session PDU donnée et libérer ses ressources | Cette session PDU n'existe plus |
| Désenregistrement 5GS | Mettre fin à la relation d'enregistrement entre l'UE et le 5GS | L'UE quitte l'état enregistré correspondant du 5GS |
La libération et le désenregistrement sont particulièrement faciles à confondre. Supposons qu'un UE possède une session PDU pour accéder à Internet et une autre pour un réseau d'entreprise privé. La libération de l'une ne supprime pas automatiquement l'autre et n'entraîne pas nécessairement l'effacement du contexte d'enregistrement de l'UE dans l'AMF.
Il ne faut pas non plus assimiler RRC Release à la libération de session PDU. RRC Release modifie principalement l'état de la connexion radio entre l'UE et le gNB, alors que la session PDU peut rester active dans le cœur de réseau. À l'inverse, la libération de session PDU supprime les ressources associées à un identifiant de session PDUdonné.
Pour comprendre comment la session a été initialement créée, consultez laProcédure d'établissement de session PDU dans le cœur de réseau 5GC. Si la session reste active et que seuls ses paramètres QoS ou de politique changent, consultez laProcédure de modification de session PDU dans le cœur de réseau 5GC.
Principaux déclencheurs de la libération de session PDU
Une libération de session PDU peut être lancée à différents endroits du réseau. Une session active peut être terminée à la suite d'une action de l'UE, d'une décision de contrôle des politiques, d'une incohérence de l'état du réseau ou d'une condition liée aux ressources.
Les déclencheurs courants comprennent :
Déclenchement par l'UE : l'UE envoie PDU Session Release Request lorsqu'il n'a plus besoin de la session de données en cours ;
Déclenchement par le PCF : le contrôle des politiques exige la fin de la session car l'autorisation de service, les conditions d'utilisation ou une autre règle ne permettent plus de la maintenir active ;
Déclenchement par l'AMF : l'AMF détecte une incohérence entre les états de session PDU de l'UE et du réseau, ou la tranche de réseau (Network Slice) associée n'est plus disponible ;
Déclenchement par le RAN : par exemple, tous les flux QoS liés à une session PDU ont déjà été libérés et le RAN transmet l'état correspondant au cœur de réseau ;
Déclenchement par le SMF : le SMF décide de terminer la session selon sa politique locale ou des informations reçues de fonctions comme l'UDM ou le CHF.
Le déclencheur initial pouvant provenir de différentes fonctions réseau, les premières étapes de signalisation ne sont pas toujours identiques. La procédure converge toutefois vers le SMF, qui conserve le contexte de contrôle de la session PDU et coordonne le plan utilisateur de l'UPF, les ressources d'accès AMF/RAN et l'association de politiques du PCF.
Lors de l'analyse des traces de paquets, déterminer quelle entité a demandé la libération en premier est généralement plus utile que de commencer directement par PDU Session Release Command. Un Release Request de l'UE indique une initiative du terminal. Une notification de terminaison du PCF signale une libération imposée par une politique. Une demande de l'AMF visant à libérer un SM Context correspond à une autre branche déclenchée par le réseau.
Signalisation N1, N2 et N4 lors d'une libération initiée par l'UE
La libération initiée par l'UE montre clairement comment les ressources de session sont supprimées dans les différentes couches.
Supposons que l'UE utilise l'identifiant de session PDU 5 pour l'accès aux données. Lorsque l'appareil n'a plus besoin de cette session, il génère un message PDU Session Release Request et l'envoie dans un N1 SM Container. Le gNB transfère le message NAS à l'AMF avec UL NAS Transport, et l'AMF identifie le SMF responsable de l'identifiant de session PDU indiqué.
Sur l'interface basée sur les services, l'AMF transmet la demande de libération via le SM Context existant, par exemple en invoquant Nsmf_PDUSession_UpdateSMContext. Il ne s'agit pas de créer un nouveau SM Context : celui-ci existe déjà et l'AMF informe le SMF que la session active entre en procédure de libération.
Le SMF prend ensuite en charge le nettoyage du plan utilisateur. Pour une session N4 existante, il envoie une PFCP Session Deletion Request à l'UPF. Celui-ci supprime l'état du plan utilisateur associé à la session PFCP concernée et retourne une PFCP Session Deletion Response.
Cette opération diffère fondamentalement de PFCP Session Modification durant une modification de session PDU. Une modification met à jour les règles au sein d'une session N4 existante, tandis qu'une suppression retire l'état de session de l'UPF.
Une fois le nettoyage du plan utilisateur engagé, le SMF prépare les informations destinées au RAN et à l'UE :
N2 SM : indique au gNB de libérer la ressource correspondante de la session PDU ;
N1 SM : transporte PDU Session Release Command vers l'UE.
L'AMF envoie PDU Session Resource Release Command au gNB via NGAP. Ce message peut contenir le PDU Session Release Command NAS destiné à l'UE. Après avoir libéré les ressources d'accès associées à la session PDU, le gNB renvoie PDU Session Resource Release Response.
Après réception de Release Command, l'UE supprime son contexte local de session PDU et envoie PDU Session Release Complete en guise de confirmation 5GSM.
Une séquence typique initiée par l'UE peut se résumer ainsi :
Demande de libération UE → AMF → SMF → Suppression de session PFCP → Libération des ressources N2 → Commande de libération PDU → Confirmation UE
Si l'UE se trouve initialement en état CM-IDLE, le réseau peut d'abord nécessiter un Service Request pour rétablir la connexion de signalisation permettant de poursuivre la libération. Les traces de paquets ne commencent donc pas systématiquement dans le même état radio.
Libération initiée par le réseau et terminaison de politique PCF
Lors d'une libération initiée par le réseau, l'UE n'envoie pas PDU Session Release Request en premier. Le changement peut commencer dans la couche de contrôle des politiques ou une autre fonction du cœur de réseau.
Prenons un déclenchement par le PCF. Une session PDU transporte normalement du trafic, mais le PCF décide ensuite d'y mettre fin conformément à une politique. Le PCF informe le SMF par le mécanisme de notification établi pour l'association de politiques existante.
Après réception du déclencheur lié à la politique, le SMF doit toujours supprimer le plan utilisateur. PFCP Session Deletion Request et Response peuvent donc apparaître avant l'envoi, par le SMF via l'AMF, des informations N1 et N2 nécessaires :
SMF → AMF → gNB / UE
Le transfert AMF N1N2 Message Transfer peut transporter les informations N2 liées à la libération des ressources de session PDU ainsi que PDU Session Release Command destiné à l'UE.
Du point de vue de l'UE, que le déclenchement initial provienne du PCF, du SMF ou d'une autre fonction, une procédure NAS explicite de libération implique toujours l'envoi par le réseau de PDU Session Release Command, suivi de la réponse de l'UE avec PDU Session Release Complete.
Du point de vue des traces du cœur de réseau, ces deux messages NAS ne suffisent toutefois pas à déterminer le déclencheur initial. Les éléments décisifs apparaissent avant Release Command : terminaison d'une politique PCF, demande de libération du SM Context par l'AMF, événement lié au RAN ou décision locale du SMF.
Cette distinction est essentielle tant pour l'analyse technique que pour le dépannage : PDU Session Release Command indique que le réseau demande à l'UE de terminer la session, mais ne permet pas à lui seul de savoir quelle entité a déclenché la libération à l'origine.
Nettoyage des ressources UPF, RAN et du contexte de politiques
La libération d'une session PDU ne doit pas être considérée comme terminée au seul motif que l'UE ne peut plus envoyer de données. Les ressources associées doivent être nettoyées dans les fonctions réseau concernées selon le scénario de libération.
N4 supprime la session UPF
PFCP Session Deletion constitue une étape majeure du nettoyage du plan utilisateur. Une fois la session N4 correspondante supprimée par l'UPF, les PDR, FAR, QER, URR et les autres états de transfert applicables n'opèrent plus dans le cadre de la session PDU libérée.
Les ressources N3 liées à la session PDU, ainsi que les autres ressources de terminaison du plan utilisateur applicables, sont également libérées à la fin du cycle de vie de la session.
N2 libère les ressources du gNB
Le gNB conserve les ressources d'accès associées à la session PDU et à ses flux QoS. Après réception de PDU Session Resource Release Command, le RAN supprime les ressources concernées et transmet le résultat au cœur de réseau via la réponse correspondante.
Ainsi, la réussite de PFCP Session Deletion ne prouve pas à elle seule que la libération complète de la session PDU est terminée. Si l'UPF est nettoyé alors que le gNB conserve la ressource de session PDU, le réseau reste dans un état incohérent.
L'UE supprime son contexte de session 5GSM
Après réception de PDU Session Release Command, l'UE efface le contexte local et confirme l'opération par PDU Session Release Complete. Pour une session PDU de type IP, l'adresse IP ou le préfixe qui lui est associé entre également dans le processus de libération.
Le SMF informe l'AMF et nettoie l'état des politiques
Quand la session atteint l'état Released, le SMF peut envoyer une SM Context Status Notification à l'AMF afin que celui-ci synchronise l'état de session qu'il conserve.
Si la session PDU possède une SM Policy Association, la relation de politique PCF correspondante doit aussi être terminée ou supprimée selon la branche applicable. Si cette session est la dernière à nécessiter un DNN, S-NSSAI ou un état d'abonnement particulier, le SMF peut procéder à un nettoyage supplémentaire des informations d'abonnement ou d'enregistrement impliquant l'UDM ou l'UDR lorsque les conditions sont réunies. Ces actions sont conditionnelles et ne figurent pas nécessairement dans chaque libération.
Le nettoyage concerne donc plusieurs états liés à l'identifiant de session PDU et non un seul tunnel :
Contexte UE + Ressource RAN + Contexte SM + Session N4 UPF + Association de politiques
Vérifier l'achèvement de la libération dans les traces de signalisation
Les échecs de libération d'une session PDU ne sont pas toujours visibles pour l'utilisateur. L'UE peut déjà avoir arrêté de transmettre des données alors qu'un état obsolète persiste dans une ou plusieurs fonctions du cœur de réseau. Dans un autre cas, l'UE peut avoir supprimé sa session locale alors que la session PFCP de l'UPF reste active.
Plutôt que de mémoriser tous les enchaînements possibles de messages, une méthode de dépannage plus efficace consiste à établir des points de contrôle autour de l'identifiant de session PDU concerné.
Identifier la session à libérer : concentrer l'analyse sur le bon identifiant de session PDU afin de ne pas mélanger les signaux d'une autre session simultanée ;
Identifier le déclencheur : déterminer si le premier événement est un UE Release Request, une notification de terminaison du PCF, une demande de l'AMF ou un autre événement du réseau ;
Vérifier le traitement par le SMF : confirmer que la demande est parvenue au SMF responsable de la session PDU et que ce dernier a engagé la libération ;
Vérifier les ressources N4 : confirmer l'achèvement de PFCP Session Deletion Request et Response ainsi que la suppression des règles de la session UPF initiale ;
Vérifier les ressources N2 : vérifier que le gNB a reçu la signalisation de libération des ressources de session PDU et renvoyé le résultat correspondant ;
Vérifier l'état N1 : dans une procédure NAS explicite de libération applicable, vérifier que l'UE a reçu Release Command et renvoyé PDU Session Release Complete ;
Vérifier l'état final : confirmer que l'état de session PDU dans l'AMF, le contexte SMF et toute association PCF sont cohérents avec l'état Released.
Par exemple, si l'UE a déjà renvoyé PDU Session Release Complete mais que la session PFCP correspondante existe encore dans l'UPF, l'analyse doit d'abord porter sur le SMF et le nettoyage N4. Si l'état PFCP a été supprimé mais que le gNB conserve la ressource de session PDU, il faut ensuite examiner le chemin de libération N2.
À l'inverse, la seule présence de RRC Release ne permet pas de conclure que la session PDU est terminée en l'absence de PDU Session Release Request, de Release Command ou d'un nettoyage correspondant des ressources du cœur de réseau.
La dénomination des messages selon les couches de spécification peut également prêter à confusion. Certaines descriptions utilisent « PDU Session Release Ack » pour une étape du déroulement, alors que le véritable message NAS 5GSM envoyé par l'UE après acceptation de PDU Session Release Command est PDU Session Release Complete. L'analyse des traces de l'interface radio et NAS doit s'appuyer sur le Message Type réel.
Un critère d'achèvement plus fiable consiste donc à se demander : les états associés à l'identifiant initial de session PDU ont-ils bien été supprimés de l'UE, du RAN, du SMF et de l'UPF, plutôt que de vérifier simplement l'apparition d'un message « final » ?
Questions fréquentes
La libération d'une session PDU désenregistre-t-elle l'UE ?
Pas nécessairement. La libération de session PDU ne termine que la session de données indiquée. L'UE peut rester enregistré dans le 5GS et continuer à utiliser d'autres sessions PDU actives. Le désenregistrement met fin à la relation d'enregistrement entre l'UE et le 5GS.
La libération d'une session PDU libère-t-elle l'adresse IP de l'UE ?
Pour une session PDU de type IP, l'adresse IP ou le préfixe associé fait partie des ressources à libérer. Une fois la procédure terminée, il ne doit plus être utilisé comme adresse valide du plan utilisateur pour la session PDU libérée. La restitution au pool d'adresses et toute réattribution ultérieure dépendent de l'implémentation du réseau.
La suppression de session PFCP équivaut-elle à la libération d'une session PDU ?
Non. PFCP Session Deletion est la procédure N4 utilisée par le SMF pour supprimer la session UPF et ses règles du plan utilisateur. Elle constitue souvent une partie importante de la libération de session PDU, mais la procédure complète peut aussi impliquer l'UE, le RAN, l'AMF, le PCF et d'autres contextes associés.
Quelle est la différence principale entre libération et modification de session PDU ?
La modification de session PDU conserve la session active tout en changeant la QoS, les politiques ou des ressources associées. La libération termine la session visée et supprime ses ressources. Si le même identifiant de session PDU reste valide et continue à transporter du trafic, la libération n'est généralement pas achevée.
Pourquoi le réseau envoie-t-il PDU Session Release Command après une demande de libération de l'UE ?
UE Release Request exprime la volonté de l'UE de terminer la session, mais le SMF doit encore coordonner l'état de l'UPF, du RAN et de l'UE. Une fois la libération engagée côté réseau, PDU Session Release Command indique à l'UE d'effacer le contexte 5GSM correspondant ; l'UE répond alors par PDU Session Release Complete.
