Un scénario courant de dépannage dans les réseaux 5G semble simple au premier abord : l’UE s’enregistre correctement, la PDU Session est établie et une adresse IP correcte est attribuée, mais l’accès au Web échoue et même un simple trafic Ping ne fonctionne pas. Les captures peuvent montrer du trafic arrivant à l’UPF via N3, sans qu’aucun paquet correspondant ne ressorte par le chemin attendu. Si le diagnostic reste concentré uniquement sur la signalisation AMF et sur le résultat de l’établissement de la PDU Session, la cause réelle peut être difficile à isoler.
Une PDU Session correctement établie ne signifie pas automatiquement que le chemin de transfert du plan utilisateur est opérationnel. Après réception d’un paquet, l’UPF utilise d’abord une PDR pour identifier le trafic, puis applique la FAR (Forwarding Action Rule, règle d’action de transfert) associée afin de déterminer la suite : transférer, supprimer, mettre en tampon ou dupliquer le paquet. La FAR peut également définir l’interface de destination et indiquer s’il faut créer un en-tête externe de tunnel GTP-U.
Du point de vue du dépannage, cette distinction est utile : une PDR répond à la question « À quelle session et à quel flux de trafic ce paquet appartient-il ? », tandis qu’une FAR répond à la question « Maintenant que le paquet est identifié, que doit en faire l’UPF ? » Lorsque les procédures du plan de contrôle paraissent normales mais que le trafic utilisateur échoue encore, la FAR sur l’interface N4 devient un point important à examiner.
Pourquoi une PDU Session réussie ne garantit-elle pas la connectivité du plan utilisateur ?
La fin de la procédure PDU Session Establishment confirme uniquement que les ressources de session requises du plan de contrôle ont été initialisées. Le trafic applicatif réel dépend toujours du chemin complet du plan utilisateur impliquant le gNB, N3, l’UPF et N6.
Pour une PDU Session Internet typique, le trafic montant va de l’UE au gNB, est encapsulé dans un tunnel GTP-U, puis atteint l’UPF via N3. L’UPF doit supprimer l’en-tête de tunnel externe applicable, identifier le trafic et transférer le paquet d’origine vers le réseau de données. En sens descendant, le fonctionnement est inverse : le trafic entre dans l’UPF depuis N6, l’UPF identifie la PDU Session correspondante, récupère les informations du tunnel du plan utilisateur du gNB, ajoute l’en-tête externe GTP-U requis et envoie le paquet vers le gNB via N3.
Ce comportement de transfert ne devient pas disponible simplement parce que la PDU Session a été créée. Le SMF doit provisionner les règles PFCP appropriées dans l’UPF via N4. La PDR identifie le trafic correspondant, tandis que la FAR définit l’action de transfert à appliquer après classification du trafic. Les deux types de règles sont nécessaires pour un traitement correct du plan utilisateur.
Lorsque toute la signalisation du plan de contrôle semble normale mais que le service reste indisponible, le problème peut être ramené à deux questions essentielles :
La PDR identifie-t-elle correctement le trafic actuel ?
Une fois le paquet identifié, la FAR associée contient-elle les bons paramètres de traitement et de transfert ?
Se concentrer sur la relation entre PDR et FAR est souvent plus efficace que de reprendre sans cesse l’ensemble de la procédure d’établissement de la PDU Session depuis le début.
Que demande réellement une FAR à l’UPF de faire ?
Une FAR est une règle de transfert du cadre PFCP. Elle est provisionnée par le SMF dans l’UPF via N4 et associée au trafic grâce au FAR ID référencé par une PDR. Lorsqu’un paquet correspond à cette PDR, l’UPF exécute le comportement de traitement défini par la FAR référencée.
Une FAR peut contenir plusieurs Information Elements. Pour le dépannage du plan utilisateur, les champs suivants sont particulièrement importants :
| Paramètre FAR | Fonction principale |
|---|---|
| FAR ID | Identifie de façon unique l’instance FAR afin qu’une PDR puisse référencer la bonne règle de transfert |
| Apply Action | Définit l’action de base appliquée au paquet, notamment transfert, suppression, mise en tampon ou duplication |
| Forwarding Parameters | Définit la destination, la Network Instance, l’encapsulation de tunnel et les autres paramètres utilisés lorsqu’un transfert est requis |
| Duplicating Parameters | Définit comment une copie dupliquée du paquet doit être transférée lorsque la duplication du trafic est activée |
| BAR ID | Référence une Buffering Action Rule utilisée pour contrôler le comportement de mise en tampon des paquets |
En pratique, Apply Action et Forwarding Parameters sont les deux éléments que l’on confond le plus facilement. Apply Action répond à « Quelle action faut-il effectuer ? », tandis que Forwarding Parameters répond à « Si le paquet doit être transféré, comment et vers où doit-il être envoyé ? »
Le simple fait de voir le drapeau FORW dans Apply Action ne prouve pas que le chemin descendant est complet. Destination Interface, Network Instance, les informations d’Outer Header Creation et les autres paramètres de transfert associés doivent eux aussi être corrects.
Comment Apply Action détermine-t-il la première étape de traitement du paquet ?
Apply Action est représenté par un ensemble de drapeaux de bits qui indiquent à l’UPF quelles opérations de base appliquer aux paquets correspondants. Ces drapeaux ne sont pas simplement des choix mutuellement exclusifs ; leur sens doit être interprété dans le contexte de la session PFCP et du scénario de service.
DROP : Supprime le paquet correspondant.
FORW : Transfère le paquet selon les Forwarding Parameters applicables.
BUFF : Met le paquet en tampon au lieu de le transférer immédiatement.
NOCP : Utilisé avec les scénarios de mise en tampon pour notifier le plan de contrôle lorsqu’arrivent des données descendantes qui doivent être mises en tampon.
DUPL : Crée une copie dupliquée du paquet et traite cette copie selon les Duplicating Parameters.
Pourquoi BUFF et NOCP sont-ils nécessaires ?
Un cas typique se produit lorsque l’UE est inactif et qu’aucun chemin descendant immédiat du plan utilisateur n’est disponible. Le trafic descendant peut déjà avoir atteint l’UPF sans pouvoir encore être livré à l’UE. L’UPF peut mettre le paquet en tampon et, si nécessaire, utiliser le comportement de notification au plan de contrôle associé afin de déclencher d’autres procédures telles que le paging ou la restauration du chemin du plan utilisateur.
BUFF indique uniquement qu’une mise en tampon est nécessaire. Les détails de sa gestion sont associés à la BAR ; le dépannage ne doit donc pas se baser uniquement sur le drapeau BUFF.
Pourquoi DUPL ne signifie-t-il pas simplement « retransférer le paquet » ?
DUPL crée une copie distincte du paquet. Le paquet d’origine continue de suivre son chemin normal de traitement, tandis que la copie dupliquée est contrôlée séparément par les Duplicating Parameters. Cette copie peut utiliser une Destination Interface différente, une autre configuration d’en-tête externe, un Transport Level Marking différent ou une autre Forwarding Policy.
Par conséquent, il ne faut pas supposer automatiquement que le trafic répliqué ou dupliqué suit le même chemin que le trafic de service d’origine. Les paramètres de duplication doivent être contrôlés séparément.
Comment les Forwarding Parameters déterminent-ils la destination réelle d’un paquet ?
Lorsque Apply Action inclut FORW, les Forwarding Parameters déterminent le chemin de transfert réel. Plusieurs champs sont particulièrement importants lors du diagnostic des défaillances du plan utilisateur.
Destination Interface
Destination Interface définit l’interface logique vers laquelle l’UPF doit envoyer le paquet après traitement. Dans un scénario descendant typique, elle est définie sur Access, ce qui signifie que le paquet doit être transféré vers le gNB. Le trafic montant est généralement transféré vers le côté Core.
Une Destination Interface incorrecte peut provoquer une panne difficile à détecter : la PDR correspond correctement, mais le paquet est envoyé vers la mauvaise interface logique alors que le plan de contrôle peut ne montrer aucune erreur évidente.
Network Instance
Network Instance identifie le contexte de réseau logique utilisé pour le transfert. Elle est particulièrement importante dans les déploiements comportant plusieurs DNN, slices ou réseaux de données dans lesquels le trafic doit rester séparé.
Lors du dépannage de la connectivité N6 ou de services de réseau privé, il ne suffit pas de vérifier la connectivité physique. La Network Instance de la FAR doit également correspondre à la configuration UPF associée. Une incohérence peut empêcher le trafic d’être routé vers le contexte réseau attendu.
Outer Header Creation
Outer Header Creation est l’un des paramètres clés du transfert descendant via N3. Un paquet entrant dans l’UPF depuis N6 contient la charge utile UE d’origine. Avant de pouvoir envoyer ce paquet au gNB via N3, l’UPF doit ajouter l’encapsulation externe GTP-U/UDP/IP requise.
Outer Header Creation fournit les informations nécessaires à cette opération, notamment l’adresse du plan utilisateur du gNB, le TEID du tunnel N3 et le type d’en-tête externe.
De nombreux cas où le trafic descendant atteint l’UPF sans qu’aucun paquet correspondant n’apparaisse sur N3 peuvent être attribués à des informations manquantes ou incorrectes dans cette partie de la FAR, par exemple un TEID ou une adresse gNB erronés.
Autres Forwarding Parameters
Forwarding Parameters peut également inclure Redirect Information, Transport Level Marking, Forwarding Policy, Header Enrichment, Linked Traffic Endpoint ID, Proxying, Destination Interface Type et d’autres informations facultatives.
Transport Level Marking peut servir à appliquer le marquage DSCP requis aux paquets transférés. Forwarding Policy peut référencer une politique de transfert configurée localement dans l’UPF. Header Enrichment prend en charge un traitement d’en-tête supplémentaire dans les services concernés. Toutes les FAR ne transportent pas tous ces Information Elements ; le contenu réel dépend de la signalisation PFCP et des besoins du service.
Pourquoi une FAR descendante peut-elle être mise à jour après l’établissement de la session ?
Lors de la procédure initiale PDU Session Establishment, le SMF peut créer les premières PDR et FAR dans l’UPF. À ce moment-là, le gNB peut toutefois ne pas avoir terminé l’allocation des ressources du plan utilisateur descendant N3. Le TEID final du tunnel et l’adresse du plan utilisateur du gNB peuvent donc ne pas encore être disponibles pour le SMF.
Une fois que le gNB a alloué ces ressources et que les informations correspondantes du plan utilisateur N3 sont disponibles pour le SMF, celui-ci peut envoyer une PFCP Session Modification pour mettre à jour la FAR existante dans l’UPF avec les paramètres requis du tunnel descendant.
La FAR descendante mise à jour peut alors inclure les principales informations de transfert :
Destination Interface = Access, indiquant un transfert vers le côté accès ;
la Network Instanceapplicable ;
Outer Header Creation = GTP-U/UDP/IPv4 ou un autre type d’en-tête externe applicable ;
l’adresse IP du plan utilisateur N3 du gNB et le TEID du tunnel alloué.
C’est pourquoi le dépannage ne doit pas s’arrêter après l’examen du seul PFCP Session Establishment Request. La FAR initiale peut ne contenir que l’action de transfert de base, tandis que les informations nécessaires à la création effective du tunnel descendant N3 peuvent être ajoutées ultérieurement par PFCP Session Modification.
Si cette mise à jour ultérieure est ignorée pendant l’analyse, un processus normal de provisionnement progressif des règles peut facilement être pris pour une configuration FAR absente ou incomplète.
Comment une FAR renvoie-t-elle le trafic descendant dans le tunnel N3 ?
Suivre le chemin complet d’un paquet descendant permet de mieux comprendre le rôle de la FAR.
Un paquet provenant d’un serveur externe atteint l’UPF par N6. L’UPF utilise une PDR pour identifier le trafic et l’associer à la bonne PDU Session, puis lit la FAR référencée par cette PDR.
Si Apply Action inclut FORW, l’UPF évalue les Forwarding Parameters. Une Destination Interface définie sur Access signifie que le paquet doit être envoyé vers le côté accès radio. Outer Header Creation contient l’adresse du tunnel du gNB et le TEID nécessaires à la construction de l’en-tête externe GTP-U. L’UPF encapsule ensuite le paquet d’origine et l’envoie au gNB via N3.
Le chemin complet peut être résumé ainsi :
Le paquet descendant arrive sur N6 → la PDR identifie le trafic UE → la FAR applique FORW → l’UPF récupère les paramètres du tunnel N3 du gNB → l’UPF crée l’en-tête externe GTP-U → le paquet est transmis au gNB via N3.
Cela permet également de clarifier la différence entre FAR et GTP-U. GTP-U est le protocole de tunnel qui transporte les données utilisateur, tandis que la FAR est la règle de décision de l’UPF qui contrôle s’il faut créer un en-tête externe de tunnel, quelles informations de tunnel utiliser et quelle interface logique doit recevoir le paquet.
Un TEID incorrect observé dans une capture N3 n’est donc que le symptôme visible. L’analyse doit remonter vers le plan de contrôle : le gNB a-t-il alloué les bonnes informations du plan utilisateur ? Le SMF les a-t-il reçues correctement ? Ont-elles ensuite été écrites dans la FAR appropriée au moyen de la mise à jour N4 ?
Comment utiliser FAR pour dépanner une PDU Session établie mais sans connectivité de données ?
Si l’enregistrement de l’UE est normal et que la PDU Session a été établie mais que le service ne fonctionne toujours pas, le dépannage peut suivre la séquence réelle de traitement des paquets de l’UPF au lieu de rejouer toute la procédure d’enregistrement depuis le début.
Une séquence pratique de dépannage FAR est la suivante :
Confirmer que le paquet atteint l’UPF. Si aucun paquet n’arrive sur N3 ou N6, le problème se trouve en amont de la FAR et doit d’abord être recherché au niveau de l’UE, du gNB ou du chemin de transport.
Confirmer que la PDR correspond au paquet. Une FAR n’a aucun trafic sur lequel agir tant que le paquet n’a pas d’abord été identifié par la PDR associée.
Vérifier le FAR ID référencé par la PDR. S’assurer qu’un paquet correctement identifié n’est pas associé à la mauvaise règle de transfert.
Inspecter Apply Action. Déterminer si le comportement configuré est FORW, DROP, BUFF ou une combinaison de drapeaux applicables.
Vérifier Destination Interface et Network Instance. Confirmer que le paquet est envoyé dans la bonne direction logique et vers le bon contexte réseau.
Vérifier Outer Header Creation. Pour le trafic descendant N3, contrôler l’adresse gNB, le TEID et le type d’en-tête externe.
Examiner les messages PFCP Session Modification. Ne pas examiner uniquement le Create FAR initial. Confirmer que les informations du tunnel gNB ont ensuite été mises à jour dans l’UPF.
Comparer les captures N3 et N6. Comparer le comportement attendu d’après les règles PFCP avec les paquets réellement transmis par l’UPF.
Le principal avantage de cette méthode est que les règles du plan de contrôle et les captures du plan utilisateur peuvent se valider mutuellement. La signalisation PFCP montre comment l’UPF devrait transférer le paquet, tandis que les captures N3 et N6 montrent ce que l’UPF a réellement fait.
Lorsque ces deux vues ne correspondent pas, le domaine de panne peut généralement être réduit à trois zones : provisionnement incorrect des règles N4, mauvaise exécution des règles par l’UPF ou problème sur le chemin de transport du plan utilisateur. Cette approche est bien plus efficace qu’une recherche sans direction dans l’ensemble du 5G Core.
FAQ
Quelle est la principale différence entre une FAR et une PDR ?
Une PDR assure la détection et la classification des paquets et répond à des questions telles que la session et le flux auxquels appartient un paquet. Une FAR définit ce qui se passe après la correspondance, notamment comment le paquet doit être traité et vers où il doit être transféré. Une PDR référence la FAR correspondante au moyen du FAR ID.
Pourquoi le transfert peut-il encore échouer lorsque Apply Action contient FORW ?
FORW indique uniquement qu’un transfert doit être effectué. Sa réussite dépend toujours des Forwarding Parameters associés. Si Destination Interface, Network Instance ou les informations d’Outer Header Creation sont incorrectes, le paquet peut ne pas atteindre la destination attendue. Un TEID N3 erroné ou une mauvaise adresse du plan utilisateur du gNB en sont des exemples typiques.
Pourquoi la FAR du premier PFCP Session Establishment ne contient-elle parfois pas toutes les informations du tunnel N3 ?
L’établissement d’une PDU Session est une procédure en plusieurs étapes. Lors de la création de la session PFCP initiale, le gNB peut ne pas avoir encore alloué les ressources finales du plan utilisateur descendant N3. Dès que l’adresse du tunnel gNB et le TEID deviennent disponibles, le SMF peut mettre à jour la FAR par PFCP Session Modification. Le dépannage doit donc suivre les échanges N4 ultérieurs en plus du message d’établissement initial.
Quel est le lien entre Outer Header Creation et PDR Outer Header Removal ?
Ils s’appliquent à des directions opposées du traitement du tunnel. Pour le trafic montant arrivant de N3, Outer Header Removal sert à supprimer l’en-tête externe GTP-U applicable. Pour le trafic descendant quittant l’UPF vers N3, Outer Header Creation de la FAR fournit les informations nécessaires à la création du nouvel en-tête externe GTP-U. Ensemble, ils assurent les deux sens de l’encapsulation et de la décapsulation du tunnel du plan utilisateur.
Si le TEID sur N3 est incorrect, faut-il concentrer le dépannage uniquement sur GTP-U ?
Non. Une capture N3 montre uniquement que le TEID utilisé est incorrect. Les informations du tunnel proviennent du gNB, sont traitées par le SMF, puis provisionnées dans la FAR via N4. Le dépannage doit donc suivre l’allocation du gNB, les informations reçues par le SMF et la mise à jour de la FAR dans la procédure PFCP Session Modification afin de localiser la cause réelle.
