Une session PDU peut fonctionner normalement depuis un certain temps : l’UE possède déjà une adresse IP, le chemin N3 du plan utilisateur est actif et le trafic applicatif circule comme prévu. Puis les conditions de service changent. Il peut être nécessaire de réduire le débit de données précédemment autorisé, d’attribuer un autre 5QI à un flux QoS ou de limiter le débit maximal de la session à 10 Mbps.
Dans ce cas, le 5GC n’a pas besoin de supprimer puis de reconstruire toute la session PDU. La session existante peut rester active tandis que seules les règles QoS, les paramètres de flux QoS ou les politiques d’application du plan utilisateur concernés sont mis à jour. C’est le rôle de PDU Session Modification.
La différence avec PDU Session Establishment est simple. L’établissement crée une session qui n’existait pas auparavant ; la modification change une session déjà active. Les principales questions ne sont donc plus de savoir comment le SMF a été sélectionné ou comment l’UPF a été créé initialement, mais ce qui a déclenché le changement, comment le SMF obtient la nouvelle politique, ce que l’UE et le gNB doivent mettre à jour, et si la nouvelle politique QoS est réellement appliquée dans l’UPF.
Périmètre de la modification de session PDU
PDU Session Modification repose sur un prérequis essentiel : la session PDU ciblée doit déjà exister. L’UE, le SMF, le PCF et le contexte RAN concerné sont déjà associés à cette session, et le plan utilisateur est normalement opérationnel.
L’objectif de la procédure de modification est de changer des paramètres tout en maintenant la session active. La QoS en est l’un des exemples les plus courants. Un flux QoS existant peut nécessiter un autre 5QI, MBR, MFBR ou un autre paramètre autorisé. Un changement de politique peut également imposer la mise à jour du contrôle de débit déjà appliqué dans l’UPF.
Une modification de QoS ne doit pas être comprise comme la simple modification d’un champ NAS. Une seule mise à jour QoS peut affecter trois parties différentes du système :
Côté UE : l’UE doit recevoir la nouvelle règle QoS ou les nouveaux paramètres du flux QoS ;
Côté RAN : le gNB peut devoir modifier la ressource de session PDU correspondante ou les ressources du flux QoS ;
Côté UPF : si l’application sur le plan utilisateur change, les règles PFCP concernées doivent être mises à jour via N4.
PDU Session Modification doit donc être considérée comme une reconfiguration en ligne d’une session active. L’identité de la session reste inchangée et la modification s’applique au PDU Session ID existant ainsi qu’aux flux QoS qui lui sont associés.
Il faut également garder à l’esprit une limite importante. PDU Session Modification peut mettre à jour un flux QoS existant mais, dans les scénarios de service applicables, elle peut aussi servir à établir un nouveau flux QoS au sein de la même session PDU. Par exemple, une politique pilotée par une application pour un appel VoNR peut nécessiter un flux supplémentaire présentant des caractéristiques QoS particulières. Ici, l’accent porte toutefois sur la modification des paramètres d’un flux QoS existant, et non sur la création d’un nouveau flux.
Principaux déclencheurs de modification de session
Une différence importante avec PDU Session Establishment est que l’UE n’est pas le seul déclencheur possible. Une session PDU active peut être reconfigurée à la suite d’une demande de l’UE, d’un changement de politique réseau, d’une mise à jour des données d’abonnement ou d’une évolution des conditions radio.
Les principales sources de déclenchement peuvent être regroupées en cinq catégories :
Déclenchement par l’UE : l’UE envoie un PDU Session Modification Request pour demander une modification de QoS ou d’autres paramètres de session ;
Déclenchement par le PCF : le contrôle de politique change, par exemple lorsqu’un seuil d’usage est atteint et que le réseau réduit le débit autorisé, ou lorsqu’une politique applicative exige une autre QoS ;
Déclenchement par l’UDM : les données d’abonnement de gestion de session changent, par exemple à la suite d’une mise à jour du niveau d’abonnement ou du profil QoS souscrit ;
Déclenchement par le SMF : le SMF décide de reconfigurer la session selon la politique locale, la configuration réseau ou l’état actuel de la session ;
Déclenchement lié au RAN : le gNB signale des conditions radio ou de ressources, puis le SMF détermine que les paramètres de session doivent être modifiés.
Tous ces déclencheurs convergent finalement vers le SMF, car celui-ci détient le contexte de contrôle de la session PDU et traduit une nouvelle exigence de service ou de politique en paramètres applicables par l’UE, le RAN et l’UPF.
Lors du dépannage de PDU Session Modification, il ne faut donc pas commencer directement par PDU Session Modification Command et poursuivre vers l’aval. Il est plus utile d’identifier le premier événement de contrôle ayant provoqué le changement. Si le premier événement est une UE Modification Request, la procédure est initiée par l’UE. Si le PCF pousse une nouvelle politique vers le SMF via une Notification URI, le changement est piloté par la politique. Si une mise à jour des données d’abonnement UDM apparaît en premier, l’analyse doit suivre le chemin de modification de l’abonnement.
Modification de session PDU initiée par l’UE
Une procédure initiée par l’UE se comprend facilement comme un cas où une application a besoin d’une QoS différente.
Supposons que l’UE utilise actuellement le PDU Session ID 5 et que l’un de ses flux QoS conserve la configuration d’origine. Une application introduit une nouvelle exigence de service ; l’UE demande alors des paramètres QoS différents en envoyant un PDU Session Modification Request.
Le message NAS transite d’abord par le gNB jusqu’à l’AMF. L’AMF met ensuite à jour le SM Context existant auprès du SMF. Sur l’interface basée sur les services, l’AMF utilise :
POST /nsmf-pdusession/v1/sm-contexts/{smContextRef}/modify
Cela diffère de Create SM Context. Le SM Context existe déjà ; le réseau met maintenant à jour le contexte d’une session existante.
La demande de l’UE peut contenir des Requested QoS Rules, des Requested QoS Flow Descriptions et des Packet Filters associés. Après réception, le SMF doit déterminer si le réseau peut autoriser la modification demandée. Si la session utilise un contrôle dynamique de politique, le SMF transmet également la demande de service au PCF pour autorisation.
Par exemple, si l’UE demande un 5QI 8 pour un flux donné, le SMF peut invoquer le service PCF SM Policy Control afin de modifier la Policy Association actuelle. Le PCF évalue la politique de l’abonné, les règles de service et les conditions réseau en cours, puis renvoie les paramètres QoS effectivement autorisés.
Une distinction est essentielle : la QoS demandée par l’UE n’est pas nécessairement celle qui sera finalement appliquée. L’UE exprime le besoin de service, tandis que les paramètres finaux restent soumis à l’autorisation du SMF et du PCF.
Une fois les paramètres autorisés déterminés, le SMF génère deux types d’informations :
N1 SM : PDU Session Modification Command transportant vers l’UE les nouveaux paramètres liés à la QoS ;
N2 SM : informations destinées à la procédure PDU Session Resource Modify, indiquant au gNB de modifier les ressources du flux QoS concerné.
L’AMF transmet les informations N2 au gNB via NGAP et relaie vers l’UE le PDU Session Modification Command contenu dans N1.
Après ajustement des ressources concernées, le gNB renvoie un PDU Session Resource Modify Response. Lorsque l’UE accepte les nouveaux paramètres, il envoie PDU Session Modification Complete via NAS.
Ce n’est qu’après réception des résultats d’exécution correspondants que le SMF peut confirmer que les nouveaux paramètres de session sont passés de l’autorisation de politique à une mise en œuvre réelle côté accès et côté UE.
Modification QoS côté réseau déclenchée par le PCF
La modification côté réseau suit une logique différente. L’UE n’a pas demandé de nouvelle QoS ; le changement commence dans la couche de contrôle de politique.
Prenons l’exemple d’un seuil d’usage. Un utilisateur dispose déjà d’une session PDU active et transfère continuellement des données. Le PCF exige que la session signale ou surveille les informations d’usage. Lorsque l’usage cumulé atteint un seuil configuré, la politique peut réduire à 10 Mbps le débit maximal de la session ou du flux concerné.
Le PCF notifie alors le SMF via la Notification URI enregistrée lors de l’établissement de la SM Policy Association. La notification contient la nouvelle SM Policy Decision, par exemple le MBR mis à jour et le Policy Control Trigger correspondant.
Du point de vue du SMF, il ne s’agit pas de créer une nouvelle session, mais de modifier une session PDU qui reste valide et active.
Si le nouveau débit doit être appliqué dans l’UPF, le SMF envoie un PFCP Session Modification Request via N4. Le QER concerné peut être mis à jour, par exemple en fixant le MBR à 10 Mbps. La nouvelle limite de débit ne prend effet dans le plan utilisateur qu’après acceptation de la modification par l’UPF.
Deux emplois différents du terme « Modification » ne doivent pas être confondus :
PDU Session Modification : la procédure globale du 5GS permettant de modifier une session PDU active ;
PFCP Session Modification : la procédure de contrôle N4 spécifique utilisée par le SMF pour mettre à jour les règles du plan utilisateur dans l’UPF.
Ces procédures opèrent à des couches différentes. Une PDU Session Modification peut inclure une PFCP Session Modification, mais la présence d’un message de modification PFCP ne signifie pas que l’ensemble de la modification de session PDU est terminé.
Une fois que l’UPF commence à appliquer le nouveau QER, le SMF peut encore devoir mettre à jour le RAN et l’UE. Les informations N1/N2 sont envoyées via l’AMF, le gNB reçoit un PDU Session Resource Modify Request et l’UE reçoit un PDU Session Modification Command.
Lorsque le gNB a terminé la mise à jour des ressources radio et que l’UE accepte les nouveaux paramètres QoS, les deux côtés renvoient leurs résultats d’exécution. Le SMF peut alors signaler le succès au PCF afin que le système de politique sache que la décision QoS a réellement été appliquée, et pas seulement enregistrée comme décision de politique.
Modification coordonnée sur N1, N2 et N4
L’un des aspects les plus déroutants de PDU Session Modification est qu’un même changement de QoS peut déclencher simultanément des procédures de modification dans NAS, NGAP et PFCP.
La logique devient plus claire lorsque les trois chemins sont séparés.
N1 met à jour les paramètres de session de l’UE
N1 SM transporte les informations de gestion de session entre l’UE et le SMF. Après décision du réseau de modifier la session, le SMF envoie un PDU Session Modification Command à l’UE via l’AMF.
L’UE met à jour ses paramètres locaux de session PDU et confirme son acceptation avec PDU Session Modification Complete.
N2 met à jour les ressources RAN
Lorsque les ressources radio associées à un flux QoS doivent changer, le SMF génère les informations N2 SM correspondantes et les transmet au gNB via l’AMF. Le gNB modifie les ressources du flux QoS au moyen de la procédure PDU Session Resource Modify et renvoie le résultat, notamment les QFI modifiés avec succès lorsque cela s’applique.
N4 met à jour les règles d’application de l’UPF
Si le changement affecte l’acheminement du plan utilisateur ou l’application de la QoS, le SMF met à jour les règles UPF concernées via PFCP Session Modification.
Une modification de limite de débit peut nécessiter une mise à jour d’un QER. D’autres changements de politique peuvent affecter un PDR, un FAR ou une autre règle du plan utilisateur. Les règles modifiées dépendent du service et de la politique de contrôle ; une PDU Session Modification ne réécrit pas nécessairement toutes les règles PFCP.
Une modification QoS complète peut donc être résumée ainsi :
Politique / demande de l’UE
→ le SMF recalcule les paramètres de session
→ N4 met à jour l’application dans l’UPF
→ N2 met à jour les ressources du gNB
→ N1 met à jour les paramètres de l’UE
→ chaque côté confirme le résultat
L’ordre exact des messages peut varier selon le déclencheur et les paramètres modifiés. Lors du dépannage, il n’est pas utile d’exiger que chaque scénario comporte exactement la même séquence de messages. Il vaut mieux confirmer que chaque point d’exécution devant changer reçoit et applique effectivement les nouveaux paramètres.
Achèvement de la modification et dépannage de la signalisation
Les problèmes de PDU Session Modification ont une caractéristique qui les distingue des échecs d’établissement : la session PDU peut rester active et l’utilisateur peut encore transférer des données, alors que la QoS obtenue ne correspond pas à la politique attendue.
Par exemple, la politique peut imposer de réduire le débit à 10 Mbps et le PCF peut avoir déjà émis la nouvelle décision de politique, tandis qu’un test de débit réel affiche encore une valeur nettement supérieure. Le maintien de la session PDU ne prouve pas que la modification a réussi. L’analyse doit déterminer à quel endroit les nouveaux paramètres ont cessé d’être appliqués.
Une séquence pratique de dépannage peut s’appuyer sur les points de contrôle suivants :
Identifier le déclencheur : déterminer si le premier événement était une UE Modification Request, une PCF Notification, une modification de données UDM ou un événement côté SMF/RAN ;
Vérifier la décision du SMF : confirmer que le SMF a accepté la demande et que le PCF a renvoyé la décision de politique attendue ;
Contrôler l’application sur N4 : si l’UPF doit appliquer la nouvelle QoS, vérifier que PFCP Session Modification a réussi et que les paramètres QER concernés ont réellement changé ;
Contrôler l’exécution sur N2 : vérifier que le gNB a reçu le PDU Session Resource Modify Request et a renvoyé les flux QoS modifiés avec succès ;
Contrôler la confirmation sur N1 : vérifier que l’UE a reçu le PDU Session Modification Command et a renvoyé PDU Session Modification Complete ;
Valider le résultat du service : confirmer que le trafic réel respecte désormais le débit, la QoS ou la politique de service mis à jour.
Si le PCF a déjà autorisé 10 Mbps mais que le QER de l’UPF contient encore l’ancien MBR, l’analyse doit se concentrer sur le chemin SMF-N4. Si l’UPF applique déjà le nouveau débit mais que le flux QoS du gNB utilise encore les anciens paramètres, la procédure N2 Resource Modify doit être examinée plus en détail. Si le côté réseau a terminé toutes les modifications requises mais que l’UE ne renvoie jamais Modification Complete, il faut contrôler le côté NAS afin de vérifier si les nouvelles règles QoS ont été acceptées.
Un nom de message peut également prêter à confusion. Certains diagrammes utilisent l’expression « PDU Session Modification Command Ack » pour décrire l’étape de confirmation de l’UE. Pourtant, dans la signalisation NAS 5GSM, le message réellement envoyé par l’UE après acceptation de PDU Session Modification Command est PDU Session Modification Complete. L’analyse de paquets doit donc s’appuyer sur le véritable NAS Message Type.
Cette méthode de dépannage par couches est bien plus efficace que de reprendre l’analyse depuis Registration Request. La session PDU existe déjà. Le problème est qu’une session active n’a pas été mise à jour de manière cohérente selon la nouvelle politique. Le domaine de panne doit donc rester centré sur le SM Context actuel, la politique, le flux QoS et l’application dans le plan utilisateur.
Questions fréquentes
PDU Session Modification réattribue-t-elle l’adresse IP de l’UE ?
Une modification QoS normale met à jour une session PDU existante et ses flux QoS au lieu de reconstruire toute la session. La modification éventuelle d’autres attributs dépend du scénario, mais une modification limitée à des paramètres tels que 5QI ou MBR ne doit pas être traitée comme une nouvelle procédure PDU Session Establishment.
PDU Session Modification est-elle toujours initiée par l’UE ?
Non. L’UE peut demander une modification via PDU Session Modification Request, mais un changement de politique PCF, une mise à jour des données d’abonnement UDM, une décision locale du SMF ou un événement lié au RAN peuvent également déclencher une modification côté réseau. Le SMF coordonne normalement les mises à jour requises entre l’UE, le RAN et l’UPF.
Quelle est la différence entre PDU Session Modification et PFCP Session Modification ?
PDU Session Modification est la procédure globale du 5GS pour modifier une session active et peut impliquer l’UE, le RAN, le SMF, le PCF et le plan utilisateur. PFCP Session Modification intervient spécifiquement sur l’interface N4 entre le SMF et l’UPF et modifie des règles concrètes du plan utilisateur dans l’UPF. La seconde peut faire partie de la première, mais elles ne sont pas équivalentes.
Si le QER a déjà été mis à jour, pourquoi le gNB et l’UE doivent-ils encore être modifiés ?
Le QER contrôle l’application de la QoS dans l’UPF, mais un flux QoS n’est pas défini uniquement au niveau de l’UPF. L’UE peut avoir besoin d’une nouvelle règle QoS ou d’une nouvelle description de flux, tandis que le RAN peut devoir ajuster les ressources radio correspondantes. Certaines modifications QoS exigent donc que N1, N2 et N4 restent cohérents. Mettre à jour uniquement l’UPF ne signifie pas que toute la procédure PDU Session Modification est terminée.
PDU Session Modification peut-elle ajouter un nouveau flux QoS ?
Oui. PDU Session Modification peut mettre à jour les paramètres d’un flux QoS existant et, dans les scénarios applicables, servir également à établir un nouveau flux QoS au sein de la même session PDU. Par exemple, un service VoNR piloté par une application peut nécessiter un flux QoS supplémentaire avec un 5QI spécifique. Ce scénario présente un contexte de service différent d’une simple mise à jour d’un flux existant et mérite une analyse distincte.
