Lorsqu’une UPF reçoit un paquet du plan utilisateur, elle ne décide pas immédiatement de sa destination. Elle doit d’abord déterminer à quelle session PFCP appartient le paquet et quelle règle de traitement doit s’appliquer. Dans le cadre de règles PFCP de l’interface N4, la PDR (Packet Detection Rule, règle de détection de paquets) prend en charge cette première étape du traitement. Une PDR indique à l’UPF quels paquets appartiennent à une catégorie de trafic donnée. Lorsqu’un paquet correspond à la règle, l’UPF peut appliquer les FAR, QER, URR et autres règles associées pour le transfert, l’application de la QoS et la remontée d’usage.
La manière la plus simple de comprendre une PDR consiste à séparer trois responsabilités : la PDR identifie le trafic, la PDI définit les conditions de correspondance, et FAR/QER/URR déterminent ce qui se passe après une correspondance. En gardant ces rôles distincts, le traitement PFCP des paquets est bien plus facile à suivre que si l’on cherche à mémoriser chaque IE individuellement.
Quel problème une PDR résout-elle sur l’interface N4 ?
N4 est l’interface de contrôle entre la SMF et l’UPF dans le cœur 5G. La SMF utilise des sessions PFCP pour installer dans l’UPF les règles de traitement du plan utilisateur, et la PDR est le type de règle chargé de détecter et de classer les paquets. Une PDR est généralement créée lors de l’établissement d’une session PFCP, puis peut être ajoutée, supprimée ou mise à jour au moyen d’une modification de session PFCP. Autrement dit, la classification des paquets est pilotée par les règles provisionnées par la SMF en fonction de la session PDU, du flux de trafic et des besoins de transfert.
Une même session PFCP peut contenir plusieurs PDR. Une session PDU donnée nécessite par exemple généralement des règles distinctes pour le trafic montant et descendant. D’autres PDR peuvent être nécessaires lorsque la session comprend plusieurs flux de données de service, différents flux QoS ou des classifications de trafic plus fines. Une PDR peut donc être considérée comme la règle de sélection de trafic de l’UPF : elle détermine le type de paquet reçu avant que d’autres règles ne décident comment le traiter.
Comment l’UPF trouve-t-elle la PDR correspondante ?
Le traitement des paquets dans l’UPF suit une séquence définie. Lorsqu’un paquet entre dans l’UPF, celle-ci identifie d’abord la session PFCP correspondante, puis évalue les PDR associées à cette session. Si plusieurs PDR sont susceptibles de correspondre, l’UPF utilise la valeur de Precedence pour déterminer leur priorité relative. Une valeur de Precedence plus faible correspond à une priorité plus élevée ; les règles les plus prioritaires sont donc évaluées avant les autres lors de la recherche d’une correspondance.
Lorsqu’une PDR correspond, elle n’exécute pas elle-même toutes les opérations suivantes de traitement du paquet. Elle peut plutôt référencer d’autres règles PFCP :
FAR (Forwarding Action Rule, règle d’action de transfert): détermine comment le paquet doit être traité et transféré, notamment s’il doit être transféré, supprimé, mis en tampon ou envoyé vers une interface de destination particulière.
QER (QoS Enforcement Rule, règle d’application de QoS): applique les contrôles liés à la QoS, tels que le gating, la limitation de débit et d’autres traitements du trafic.
URR (Usage Reporting Rule, règle de remontée d’usage): mesure l’utilisation du trafic et fournit des informations de reporting pouvant servir à la facturation, à la supervision ou à des fonctions liées aux politiques.
Le chemin de traitement global de l’UPF peut donc être simplifié ainsi :
Identifier la session PFCP → évaluer les PDR selon la Precedence → classer le paquet → appliquer FAR/QER/URR. L’ordre est important. La FAR répond à la question de savoir comment traiter un paquet, mais l’UPF a d’abord besoin d’une PDR pour établir à quel paquet ou flux de trafic l’action s’applique.
Quels sont les principaux paramètres d’une PDR ?
Un Create PDR contient plusieurs Information Elements, mais il suffit d’en comprendre d’abord un sous-ensemble pour étudier le comportement de détection de paquets. Ces paramètres définissent comment la règle est identifiée, comment les paquets sont comparés et quelles règles de traitement ultérieures sont associées au résultat.
| Paramètre | Fonction principale |
|---|---|
| ID de PDR | Identifie de manière unique la PDR dans la session PFCP et la distingue des autres règles de détection de paquets |
| Precedence | Définit la priorité relative de la PDR lorsque plusieurs règles sont évaluées ; les valeurs les plus faibles indiquent une priorité plus élevée |
| PDI | Contient les critères de détection utilisés par l’UPF pour déterminer si le trafic entrant correspond à la PDR |
| Suppression de l’en-tête externe | Indique si l’UPF doit supprimer un en-tête de protocole externe, par exemple un en-tête GTP-U/UDP/IP sur le trafic montant |
| ID de FAR | Référence la FAR qui définit l’action de transfert pour les paquets correspondants |
| ID d’URR | Référence une URR utilisée pour mesurer le trafic et produire les rapports d’usage |
| ID de QER | Référence une QER qui applique le traitement QoS au trafic correspondant |
| Activer les règles prédéfinies | Active une ou plusieurs règles prédéfinies déjà disponibles dans l’UPF |
| Heure d’activation / heure de désactivation | Définit quand la PDR devient active et quand elle cesse de l’être |
Parmi ces paramètres, l’élément qui définit réellement quels paquets peuvent correspondre à la PDR est la PDI (Packet Detection Information). Les identifiants FAR et QER référencent des actions exécutées après la classification du trafic ; la PDI contient les informations utilisées pour effectuer la classification elle-même.
Comment la PDI définit-elle les conditions de correspondance des paquets ?
La PDI peut être comprise comme l’ensemble des conditions de détection contenues dans une PDR. Il ne s’agit pas d’un champ unique. Elle regroupe plusieurs paramètres pouvant être combinés pour identifier le trafic selon l’endroit où le paquet entre dans l’UPF, ses informations de tunnel, l’adresse de l’UE, les caractéristiques du flux de service et les informations de QoS. Les paramètres PDI courants comprennent :
Interface source: identifie le côté logique depuis lequel le paquet arrive, par exemple Access pour le trafic provenant du côté accès, ou Core pour le trafic provenant du cœur ou du côté réseau de données.
F-TEID local: peut servir à faire correspondre le TEID et les informations d’adressage associées à un tunnel GTP-U, ce qui est particulièrement important pour la détection du trafic de tunnel montant.
Instance réseau: identifie un réseau logique configuré dans l’UPF, par exemple une instance réseau liée à Internet ou à IMS.
Adresse IP de l’UE: fait correspondre le trafic en fonction de l’adresse IP source ou destination de l’UE, selon le sens du paquet.
ID de point terminal de trafic: identifie un point terminal de trafic pouvant être utilisé dans les scénarios d’optimisation PDI pris en charge.
Filtre SDF: fournit un filtrage plus fin selon des paramètres tels que les adresses source et destination, le protocole, les ports et le sens du trafic.
ID d’application: peut être utilisé pour identifier le trafic au niveau applicatif lorsque l’UPF dispose des capacités de détection d’application nécessaires.
QFI (QoS Flow Identifier): identifie le flux QoS associé au paquet.
Type d’interface source: fournit des informations supplémentaires sur l’interface 3GPP associée à la source, par exemple N3, N6 ou N9.
Lorsque plusieurs paramètres de correspondance sont présents dans la PDI, ils définissent collectivement la condition de détection. Le paquet entrant doit satisfaire les critères applicables avant que la PDR soit considérée comme correspondante. La SMF peut ainsi créer des règles allant d’une classification large au niveau de la session à une détection beaucoup plus précise des flux de service.
Jusqu’où un filtre SDF peut-il affiner la détection du trafic ?
L’interface source, le F-TEID et l’adresse IP de l’UE peuvent suffire à identifier une session ou une catégorie générale de trafic, mais ils ne permettent pas toujours de distinguer chaque flux de données de service. Un filtre SDF fournit une classification plus fine. Sa Description de flux peut inclure l’adresse IP source, l’adresse IP destination, le numéro de protocole, le port source, le port destination et le sens du trafic. Ces champs permettent à l’UPF de distinguer des flux IP précis au lieu de traiter de la même manière tous les paquets associés à un UE.
Un filtre SDF peut également transporter des informations de correspondance supplémentaires :
TOS / classe de trafic: correspond au champ Type of Service d’IPv4 ou Traffic Class d’IPv6.
Security Parameter Index (SPI): peut être utilisé pour faire correspondre du trafic associé à une association de sécurité IPsec.
Flow Label: correspond au Flow Label contenu dans un en-tête IPv6.
ID de filtre SDF: identifie le filtre SDF associé à des fins de gestion et de référence.
Cela crée un modèle de classification par couches. Des paramètres PDI comme l’interface, le tunnel et l’adresse de l’UE peuvent d’abord restreindre le trafic à un contexte particulier, tandis que le filtre SDF identifie les flux IP individuels dans ce contexte. Si l’identification des applications est également prise en charge, l’UPF peut appliquer un mécanisme supplémentaire de classification applicative au lieu de se fier uniquement aux adresses et aux ports.
Quelle différence existe-t-il entre les PDR montantes et descendantes ?
Comparer le trafic montant et descendant est l’un des moyens les plus clairs de comprendre le fonctionnement des PDR. Les deux directions utilisent la même structure générale de règle, mais les paquets entrent dans l’UPF par des interfaces différentes et exigent donc des critères de détection différents.
Pour un trafic montant typique, les paquets arrivent dans l’UPF depuis le côté accès radio. La PDI peut donc utiliser Interface source = Access. La règle peut également utiliser un F-TEID local pour identifier le tunnel GTP-U et une adresse IP de l’UE pour identifier le trafic de l’UE. Une PDR montante typique peut donc exiger :
l’interface source est Access ;
le paquet GTP-U entrant correspond au F-TEID spécifié, y compris au TEID et aux informations d’adresse pertinentes ;
l’adresse IP de l’UE correspond à l’adresse associée à la session.
Lorsque ces conditions sont satisfaites, la PDR correspond. Comme le trafic reçu sur N3 est normalement encapsulé dans GTP-U, Suppression de l’en-tête externe peut demander à l’UPF de supprimer les en-têtes externes GTP-U/UDP/IP avant que le paquet soit traité selon la FAR associée.
La détection descendante commence dans le sens opposé. Les paquets arrivent généralement d’un réseau de données vers l’UPF ; la PDI peut donc utiliser Interface source = Core. Dans ce cas, des paramètres tels que l’ Instance réseau et l’ Adresse IP de l’UE peuvent servir à déterminer à quelle session PDU appartient le paquet. Une PDR descendante typique peut donc exiger :
l’interface source est Core ;
l’instance réseau correspond au réseau logique requis, par exemple « internet » ou « ims » ;
la destination du paquet correspond à l’adresse IP de l’UE associée à la session.
Une fois la PDR descendante correspondante, la FAR associée détermine comment le paquet doit être transféré vers le côté accès, y compris le comportement de transfert par tunnel nécessaire. La différence entre PDR montantes et descendantes reflète donc le sens d’entrée des paquets dans l’UPF et les informations disponibles pour les identifier.
Comment PDR, FAR, QER et URR fonctionnent-elles ensemble ?
Une PDR résout le problème d’identification des paquets, mais ne représente pas toute la politique de traitement du plan utilisateur. PFCP sépare la détection, le transfert, l’application de la QoS et la mesure d’usage en différents types de règles. Cette séparation permet à chaque règle d’exécuter une fonction précise tout en opérant dans la même session PFCP.
PDR : de quel trafic s’agit-il ? (Détection et classification)
FAR : que faut-il en faire et où doit-il aller ? (Action de transfert)
QER : quel traitement QoS doit s’appliquer ? (Application de la QoS)
URR : comment son utilisation doit-elle être mesurée et rapportée ? (Rapport d’usage)
Prenons un paquet montant qui correspond à une PDR. Une fois que l’UPF a déterminé à quel UE et à quel flux de service appartient le paquet, elle peut supprimer l’en-tête externe GTP-U requis, appliquer le comportement de transfert référencé par la FAR, faire respecter la QER applicable et comptabiliser le trafic selon l’URR associée. Le résultat de la détection fournit ainsi le contexte nécessaire à toutes les opérations suivantes.
D’un point de vue d’ingénierie, une PDR ne doit pas être considérée comme une politique de transfert isolée. Elle constitue le point d’entrée dans l’ensemble de règles du plan utilisateur PFCP. Une fois comprise la relation entre la PDR pour la classification, la PDI pour les critères de correspondance et FAR/QER/URR pour le traitement ultérieur , des paramètres tels que l’interface source, le F-TEID, l’adresse IP de l’UE et le filtre SDF deviennent beaucoup plus faciles à comprendre lors de l’analyse réelle de la signalisation N4 et des paquets.
FAQ
La Precedence est utilisée lorsque l’UPF évalue les PDR d’une session PFCP. Toutefois, si les conditions PDI de deux règles sont totalement mutuellement exclusives, les deux PDR ne peuvent pas correspondre au même paquet et leur priorité relative ne change donc pas le résultat final. La Precedence devient surtout importante lorsque les conditions des règles se chevauchent et que plusieurs PDR pourraient correspondre au même trafic.
Si l’adresse de l’UE utilisée comme condition de correspondance PDI change, la règle associée à cette adresse doit elle aussi refléter les informations de session mises à jour. La SMF peut mettre à jour les informations PDR concernées via une modification de session PFCP afin que l’UPF continue de classer correctement le trafic de l’UE.
Oui. Un filtre SDF n’impose pas que tous les champs possibles restreignent le trafic à un port précis. Selon la définition de la règle, des plages de ports ou des conditions de correspondance moins restrictives peuvent couvrir un ensemble de trafic plus large. Des masques d’adresse peuvent également être utilisés lorsque la définition du filtre applicable exige la correspondance avec une plage d’adresses.
Si un paquet entrant ne peut être associé à une PDR applicable, l’UPF ne dispose d’aucune règle de traitement correspondante pour ce trafic dans le contexte concerné. Le traitement qui en résulte dépend des règles PFCP applicables, de l’implémentation de l’UPF et de la configuration de la session. En dépannage, une non-correspondance PDR inattendue constitue donc un point important à examiner lorsque le trafic atteint l’UPF mais n’est pas transféré comme prévu.
PFCP prend en charge des règles prédéfinies déjà provisionnées dans la fonction UP et pouvant être activées lorsque nécessaire. Au lieu de reprovisionner tous les paramètres de règle pour chaque scénario applicable, le plan de contrôle peut activer la règle prédéfinie correspondante. Cela peut réduire la quantité de signalisation requise lorsque les mêmes ensembles de règles sont réutilisés dans des sessions appropriées.
