Un cas fréquent de dépannage du plan utilisateur 5G peut sembler déroutant au départ : la PDU Session est établie correctement, l’UE reçoit une adresse IP, la PDR correspond au trafic attendu, la FAR contient FORW et les paquets peuvent même commencer à circuler. Pourtant, l’utilisateur subit encore des mises en mémoire tampon vidéo, des débits de téléchargement anormalement faibles ou un trafic qui ne fonctionne que dans un seul sens.
Dans ce cas, vérifier uniquement la PDR et la FAR peut ne pas révéler la cause. Le problème peut ne pas concerner le fait que le trafic ait été identifié ou l’endroit où le paquet a été transféré, mais plutôt la politique QoS appliquée par l’UPF après l’autorisation du transfert. Dans le cadre des règles PFCP de l’interface N4, la QER (QoS Enforcement Rule, règle d’application de la QoS) est chargée d’appliquer ces politiques QoS dans l’UPF. Elle peut contrôler l’autorisation du trafic, limiter les débits uplink ou downlink, associer le trafic à un QoS Flow et appliquer des marquages au niveau transport. PDR, FAR et QER doivent donc être analysées ensemble pour comprendre le comportement complet du plan utilisateur.
Pourquoi QER reste-t-elle nécessaire lorsque PDR et FAR fonctionnent déjà ?
La manière la plus simple de comprendre QER consiste à séparer les responsabilités des différentes règles de l’UPF.
La PDR répond d’abord à la question « Quel est ce trafic ? ». Elle utilise des conditions telles que PDI, l’adresse IP de l’UE, F-TEID et SDF Filter pour détecter et classer les paquets. Une fois le trafic identifié, la FAR répond à la question suivante : « Que doit-il arriver à ce paquet et où doit-il être transféré ? »
Mais autoriser le transfert d’un paquet ne signifie pas qu’il peut être transféré sans restriction. Si le réseau doit encore contrôler le débit, le gating, l’association à un QoS Flow ou le marquage au niveau transport, l’UPF doit appliquer la QER associée.
Une séquence de traitement typique peut donc être simplifiée ainsi :
PDR identifie le trafic → FAR détermine l’action de transfert → QER applique la politique QoS.
Ces règles ne se remplacent pas ; elles travaillent ensemble. Un paquet peut correspondre correctement à une PDR et être autorisé par la FAR tout en restant soumis à des limites de débit ou à des conditions de gating définies par la QER. Sans QER, l’UPF peut savoir qu’un paquet doit être transféré, mais elle ne dispose pas des mêmes informations de politique décrivant le traitement QoS à appliquer au trafic.
Quand une QER est-elle installée et pourquoi peut-elle être mise à jour ultérieurement ?
Une QER est généralement provisionnée par le SMF dans l’UPF pendant PFCP Session Establishment, dans le cadre des règles du plan utilisateur d’une PDU Session. Il ne s’agit pas d’une règle QoS créée indépendamment par l’UPF après observation du trafic. Le plan de contrôle détermine le comportement QoS à appliquer, puis l’UPF exécute la règle correspondante.
La QER ne reste pas nécessairement inchangée pendant toute la durée de vie de la session. Si la politique évolue pendant que le service est actif, le SMF peut mettre à jour une QER existante via PFCP Session Modification. Des changements de politique d’abonnement, de politique applicative ou d’autres décisions du plan de contrôle peuvent donc produire de nouvelles limites de débit, des états Gate différents, une association QoS Flow modifiée ou d’autres paramètres QoS.
Le dépannage ne doit donc pas s’arrêter au Create QER initial. Si un problème QoS apparaît après que la session fonctionne depuis un certain temps, les Update QER ultérieurs doivent également être examinés et comparés aux valeurs d’origine.
Du point de vue du plan de contrôle, la politique QoS utilisée par le SMF peut provenir d’une configuration locale ou d’informations de politique associées au PCF. Lorsqu’elle atteint l’interface N4, elle est représentée par des règles PFCP que l’UPF peut appliquer. Selon la conception du service, l’application de la QoS peut se faire au niveau PDU Session, au niveau QoS Flow ou sur des trafics SDF ou applicatifs plus spécifiques.
Comment Gate Status peut-il bloquer le trafic alors que la session semble normale ?
Gate Status est l’un des paramètres QER les plus directs, car il peut modifier immédiatement l’autorisation de passage du trafic.
Les états Gate uplink et downlink peuvent être contrôlés indépendamment. Lorsqu’un Gate est OPEN, le trafic de cette direction est autorisé à continuer. Lorsqu’il est CLOSED, le trafic de cette direction est bloqué par la règle d’application QoS.
Une séquence de dépannage typique peut donc être la suivante :
La PDU Session est établie avec succès ;
L’UE a reçu une adresse IP ;
La PDR correspond correctement ;
La FAR contient FORW ;
Mais le trafic applicatif ne fonctionne toujours pas.
À ce stade, il faut vérifier UL Gate et DL Gate dans la QER associée. Comme les deux directions sont contrôlées séparément, un Gate peut être OPEN tandis que l’autre est CLOSED. Le symptôme peut alors ressembler à un problème unidirectionnel du plan utilisateur : l’UE reçoit du trafic downlink mais ne parvient pas à envoyer correctement du trafic uplink, ou l’inverse.
C’est pourquoi QER est une règle d’application et non un simple attribut descriptif de QoS. Ses paramètres peuvent déterminer directement si un trafic donné est autorisé à continuer à travers l’UPF.
Que contrôlent MBR, GBR et Packet Rate ?
Gate Status répond à la question « Le trafic peut-il passer ? ». Les paramètres de débit répondent à une autre question : « Quelle quantité de trafic peut passer et à quelle vitesse ? ». QER peut appliquer des limites fondées à la fois sur le débit binaire et sur le taux de paquets.
Débit binaire maximal (MBR)
MBR définit le débit binaire maximal du trafic correspondant et peut être configuré séparément pour les directions uplink et downlink. Dans un environnement 5GC, la limite applicable peut correspondre à une restriction au niveau session, à un QoS Flow particulier ou à un flux de trafic plus spécifique selon la conception des règles.
Lorsqu’un utilisateur accède normalement au service mais que le débit plafonne systématiquement près d’une valeur répétable, le MBR de la QER associée est l’un des paramètres à vérifier.
MBR est facilement confondu avec la capacité radio. De bonnes conditions radio et une bande passante de transport suffisante ne garantissent pas que l’application puisse exploiter toute la capacité physique. Si l’UPF doit appliquer un MBR inférieur, le débit du plan utilisateur reste limité par cette valeur. Le dépannage des faibles débits doit donc inclure les règles QoS N4 au lieu de se concentrer uniquement sur les performances radio.
Débit binaire garanti (GBR)
GBR décrit le débit binaire garanti associé au trafic qui exige un niveau défini de garantie de ressources. Il peut également être spécifié séparément pour uplink et downlink.
GBR peut être pertinent pour des services nécessitant des performances plus prévisibles, comme certaines applications voix temps réel, vidéo ou autres services sensibles à la QoS. Il ne doit pas être interprété comme une valeur isolée ; le QoS Flow correspondant et la politique QoS globale doivent également être pris en compte.
Conceptuellement, MBR définit une limite supérieure du débit autorisé, tandis que GBR décrit l’exigence de débit garanti associée à la politique de service.
Taux de paquets
Certains trafics ne peuvent pas être décrits correctement par le seul débit binaire. QER peut aussi contenir des paramètres Packet Rate qui limitent le nombre de paquets autorisés pendant une période donnée.
Cela peut être important pour les charges générant de nombreux petits paquets, telles que les transactions DNS, les keepalives IoT ou les trafics proches de la signalisation. Leur débit binaire total peut rester relativement faible alors que le nombre de paquets par seconde devient élevé. Dans ce cas, vérifier uniquement MBR peut ne pas expliquer le comportement QoS observé.
Lorsque la limite de Packet Rate est atteinte, l’utilisateur peut subir une latence accrue, des réponses plus lentes ou des requêtes en échec alors que la consommation totale de bande passante semble modérée.
Quel est le rôle de QFI, Flow Level Marking et PPI dans une QER ?
QER est plus qu’un limiteur de débit. En plus de Gate Status, MBR et GBR, elle peut contenir des paramètres associés à l’identification du QoS Flow et au traitement des paquets. Ensemble, ces paramètres contribuent à déterminer le traitement du trafic dans le plan utilisateur.
QoS Flow Identifier (QFI)
QFI identifie un QoS Flow. Une PDU Session peut contenir plusieurs QoS Flows afin que différents trafics de service bénéficient de traitements QoS différents.
Du point de vue du plan utilisateur, QFI identifie le QoS Flow auquel un paquet est associé. Dans la QER, cet identifiant peut servir à associer le comportement d’application QoS pertinent au QoS Flow correspondant.
Si le QFI associé à une règle ne correspond pas à la conception de service prévue, le trafic peut être associé à un QoS Flow inattendu, même si les paramètres de débit semblent corrects. Cela peut entraîner un traitement des ressources différent de celui prévu pour le service.
DL Flow Level Marking
QER peut demander à l’UPF d’appliquer un marquage au niveau du flux au trafic downlink, par exemple en définissant une valeur DSCP pour le réseau de transport IP.
Ce marquage ne détermine pas à quel QoS Flow 5G appartient le paquet. Il affecte plutôt la manière dont le paquet peut être identifié et traité après son entrée dans le réseau de transport IP.
Si le marquage de transport est incorrect, la QoS 5G peut être correctement configurée tandis que le réseau de transport en aval traite encore le paquet avec une priorité non prévue.
Paging Policy Indicator (PPI)
PPI est lié au traitement de la politique de paging pour le trafic downlink. Une QER peut fournir des informations liées à la politique de paging dans les scénarios de transfert concernés afin que différents trafics soient traités différemment lorsque le paging entre en jeu.
Pour un UE qui n’est pas actuellement dans un état actif du plan utilisateur, différents types de trafic downlink peuvent avoir des implications de paging différentes. PPI fournit des informations utilisables dans ce traitement différencié.
Averaging Window
L’application des débits ne peut pas toujours se baser sur l’observation instantanée d’un seul paquet. Averaging Window définit la fenêtre temporelle sur laquelle le comportement lié au débit binaire est évalué.
Une fenêtre plus courte réagit plus vite au trafic en rafale, tandis qu’une fenêtre plus longue produit une moyenne plus lisse et peut tolérer différemment les courtes rafales. C’est pourquoi l’analyse QER ne doit pas se limiter à QER ID et MBR. Le comportement QoS résultant peut dépendre de plusieurs paramètres agissant ensemble.
Comment utiliser les messages PFCP pour vérifier que QER fonctionne comme prévu ?
La méthode la plus utile pour analyser QER n’est pas de mémoriser chaque élément d’information, mais de relier la règle PFCP au symptôme réel du service.
Par exemple, un Create QER peut contenir :
QER ID = 1 ;
UL Gate = OPEN ;
DL Gate = OPEN ;
UL MBR = 100000 kbps ;
DL MBR = 150000 kbps.
Ces valeurs ne sont qu’un exemple, mais elles illustrent un point important : un Gate OPEN ne signifie pas qu’aucune restriction QoS n’existe. Le trafic peut être autorisé à passer tout en restant soumis à l’application de MBR.
Une séquence pratique de dépannage peut suivre ces étapes :
Identifier d’abord la PDR. Déterminer quelle PDR correspond réellement au trafic affecté. Si la mauvaise PDR est sélectionnée, la QER attendue ne sera pas appliquée correctement.
Vérifier le QER ID référencé par la PDR. Ne pas examiner toutes les QER de la session PFCP sans contexte. Identifier d’abord la QER réellement associée au trafic analysé.
Examiner Create QER et Update QER. Confirmer si la règle actuellement effective a été modifiée par une PFCP Session Modification ultérieure. Un problème QoS peut être introduit par une mise à jour postérieure plutôt que par l’établissement initial de la session.
Vérifier Gate Status. Contrôler séparément les états Gate uplink et downlink. Un Gate fermé dans une seule direction peut produire une défaillance unidirectionnelle du service.
Vérifier MBR, GBR et Packet Rate. Comparer les limites configurées au débit observé ou au comportement des paquets, notamment si le service plafonne systématiquement près d’un débit fixe.
Vérifier QFI et les autres paramètres QoS. Confirmer que le QoS Flow prévu, le marquage et les réglages liés au paging correspondent à la conception du service.
Comparer la règle au trafic réel du plan utilisateur. PFCP indique ce que l’UPF est censée appliquer ; les tests de débit et les captures de paquets montrent ce qui s’est réellement produit. L’écart entre les deux constitue souvent l’indice de dépannage le plus utile.
Cette méthode est plus fiable que l’interprétation isolée d’un seul champ QER. La signalisation PFCP indique ce que l’UPF devrait appliquer, tandis que les tests du plan utilisateur montrent le résultat réellement observé. La comparaison de ces deux vues est essentielle pour déterminer si QER se comporte comme prévu.
FAQ
Quelle est la principale différence entre QER et FAR ?
FAR détermine principalement comment un paquet correspondant doit être traité et où il doit être transféré, avec des actions telles que FORW, DROP ou BUFF. QER applique les comportements liés à la QoS, tels que le gating, les limites de débit, l’association au QoS Flow et le marquage au niveau transport. Les deux interviennent généralement après l’identification du trafic par la PDR. On peut résumer la relation ainsi : FAR détermine où et comment le paquet est transféré, tandis que QER détermine quel traitement QoS s’applique à ce trafic.
Pourquoi le débit utilisateur peut-il rester faible lorsque Gate Status est OPEN ?
OPEN signifie uniquement que le trafic est autorisé à passer dans cette direction. Il ne supprime pas les autres restrictions QoS. MBR, GBR, Packet Rate et le QoS Flow associé doivent toujours être vérifiés. Si MBR est configuré en dessous de la capacité radio ou de transport disponible, le débit peut rester limité même si les deux Gates sont entièrement ouverts.
Une QER ne peut-elle être créée que pendant PFCP Session Establishment ?
Non. Une QER peut être créée pendant PFCP Session Establishment puis modifiée via PFCP Session Modification. Si le comportement QoS change après que la session fonctionne déjà, les Update QER ultérieurs doivent être analysés au lieu de se limiter au Create QER initial.
QFI et QER sont-ils la même chose ?
Non. QFI est l’identifiant d’un QoS Flow, tandis que QER est une règle d’application de QoS exécutée par l’UPF. Une QER peut contenir ou référencer des informations QFI afin d’associer un traitement QoS précis au QoS Flow correspondant. QFI identifie quel QoS Flow est concerné ; QER définit comment le contrôle QoS est appliqué au trafic.
Pourquoi le trafic peut-il encore échouer lorsque la PDR correspond et que la FAR autorise le transfert ?
Parce que le traitement du plan utilisateur ne se termine pas nécessairement avec la FAR. Après l’autorisation du transfert, la QER associée peut encore appliquer Gate Status, MBR, GBR, Packet Rate ou d’autres contraintes QoS. Le dépannage doit donc considérer PDR, FAR et QER comme une chaîne de traitement continue. Une incohérence à n’importe quelle étape peut affecter le résultat final du service.
