Un problème fréquent apparaît lors du dépannage du plan utilisateur du 5G Core : l’UE est correctement enregistré, la PDU Session est établie, le PDR identifie bien le trafic et le FAR transfère les paquets selon le chemin prévu, mais les compteurs d’usage visibles par le SMF restent inchangés. Les événements de taxation peuvent ne pas être déclenchés, ou le contrôle de quota peut ne pas réagir au moment attendu. Dans de nombreux cas, le transfert des paquets fonctionne pourtant correctement. Ce qui manque est un mécanisme indiquant à l’UPF comment mesurer l’usage du plan utilisateur et à quel moment transmettre le résultat au plan de contrôle. Ce mécanisme est l’URR (Usage Reporting Rule) sur l’interface N4.

L’URR ne décide pas où les paquets doivent être transférés et n’impose pas directement de limite de bande passante. Elle indique plutôt à l’UPF quel trafic correspondant doit être mesuré, comment cet usage doit être mesuré et dans quelles conditions le résultat de la mesure doit être rapporté au plan de contrôle. L’URR transforme donc le trafic du plan utilisateur, qui serait sinon simplement transféré, en trafic également mesurable. L’UPF effectue la mesure réelle, le SMF provisionne les conditions de rapport via PFCP et les Usage Reports obtenus forment une boucle de rétroaction continue entre le plan utilisateur et le plan de contrôle.

Quel problème l’URR résout-elle dans le cadre des règles N4 ?

Le moyen le plus simple de comprendre l’URR consiste à distinguer sa responsabilité de celles du PDR, du FAR et du QER. Lorsque l’UPF reçoit un paquet, le PDR détermine d’abord à quel trafic il appartient. Une fois le paquet classifié, le FAR décide de son traitement et de sa destination. Le QER applique le traitement QoS requis. L’URR répond à une autre question : quelle quantité de ce trafic a réellement été utilisée ?

Les principaux types de règles PFCP peuvent être résumés ainsi :

PDR : De quel trafic s’agit-il ?
FAR : Comment le paquet doit-il être traité et vers où doit-il être transféré ?
QER : Quel traitement QoS doit être appliqué à ce trafic ?
URR : Quelle quantité de ce trafic a été utilisée et quand cet usage doit-il être rapporté ?

Une URR doit être associée au PDR concerné. La raison est simple : l’UPF ne peut pas mesurer de manière pertinente « combien un utilisateur a consommé » sans savoir d’abord quels paquets appartiennent à cet UE, à ce service ou à ce flux de trafic. Une fois le trafic identifié par le PDR, l’URR associée peut mesurer l’usage des paquets correspondants. Si une PDU Session contient plusieurs PDR, plusieurs URR peuvent également être utilisées pour créer des relations de mesure d’usage plus granulaires.

Pour cette raison, la première question lors du dépannage d’une URR n’est généralement pas « L’URR a-t-elle été provisionnée ? », mais plutôt « Quel PDR correspond au trafic mesuré et quel URR ID ce PDR référence-t-il ? » Si cette association est absente ou incorrecte, les étapes suivantes de mesure et de rapport ne peuvent pas fonctionner comme prévu.

Comment l’URR définit-elle ce que l’UPF doit mesurer ?

Une URR est bien plus qu’un simple compteur de trafic. L’un des premiers éléments définis dans Create URR est la Measurement Method, qui indique à l’UPF quel type d’usage doit être mesuré. Selon les besoins du service, la mesure peut reposer sur le volume de trafic, le temps ou des événements.

Pour les services de données par paquets courants, la mesure fondée sur le volume est souvent la plus facile à observer. L’UPF peut mesurer le volume de trafic montant, descendant et total, tandis que les champs correspondants de Volume Measurement indiquent quelles statistiques sont incluses. Le volume de trafic est cumulé en octets ; une URR peut donc mesurer l’usage total ou distinguer le trafic UL du trafic DL selon la configuration.

Si la capacité requise est activée, la mesure peut également inclure le nombre de paquets. Par exemple, le drapeau MNOP de Measurement Information peut demander à l’UPF de mesurer le nombre de paquets montants, descendants et total. L’opérateur voit alors non seulement le nombre d’octets transférés, mais aussi le nombre de paquets traités pendant l’intervalle de mesure.

La mesure fondée sur le temps s’intéresse à la durée du service. Selon la configuration, elle peut faire intervenir des paramètres tels que Time Threshold, Time Quota, Inactivity Detection Time et le mécanisme de mesure temporelle applicable. La mesure fondée sur des événements peut, elle, compter des événements de service précis et produire un rapport lorsqu’un nombre défini d’événements est atteint.

Measurement Method répond donc à la question la plus fondamentale de l’URR : que signifie « usage » pour cette règle ? Si ce point n’est pas défini en premier, il est facile de confondre Threshold, Quota et Reporting Trigger lors de l’analyse des messages PFCP. La méthode de mesure sélectionnée influe directement sur le type de compteurs maintenus par l’UPF, le format du Usage Report et la manière dont le SMF interprète le résultat.

Reporting Trigger détermine quand l’UPF doit envoyer un rapport

Une méthode de mesure seule ne suffit pas. Si l’UPF continue simplement à cumuler des compteurs sans aucune condition de rapport, le SMF ne dispose d’aucun moment défini auquel il doit recevoir le résultat. Les Reporting Triggers constituent donc un autre élément central du mécanisme URR.

Ces déclencheurs peuvent être combinés selon la politique réseau. PERIO peut servir aux rapports périodiques. VOLTH indique qu’un rapport doit être généré lorsqu’un seuil de volume est atteint. TIMTH s’applique à un seuil temporel. START et STOPT peuvent déclencher des Usage Reports lorsque l’UPF détecte le début ou l’arrêt du trafic.

Un autre groupe de déclencheurs est davantage lié au contrôle de quota. VOLQU est associé aux conditions de quota de volume, TIMQU aux conditions de quota de temps et EVEQU aux conditions de quota d’événements. Quota Holding Time peut également être utilisé lorsqu’un quota a été accordé mais que l’abonné ne génère aucun trafic du plan utilisateur pendant une période définie.

Il est particulièrement important de distinguer Threshold et Quota, car ils remplissent des fonctions différentes dans PFCP et sont souvent confondus lors de l’analyse des traces :

Un Threshold concerne principalement le moment où un résultat de mesure doit être rapporté, tandis qu’un Quota se rapproche davantage de la quantité de ressources encore disponible à l’utilisation. Si une trace PFCP montre uniquement que VOLTH ou VOLQU est activé, sans que l’ingénieur examine le paramètre Threshold ou Quota correspondant, il est facile de mal comprendre la logique réelle du service.

Par exemple, si VOLTH est configuré mais que le Volume Threshold correspondant n’est pas correctement défini, l’UPF ne dispose d’aucune limite de trafic pertinente pour déclencher le rapport attendu.

Comment l’UPF envoie-t-il les résultats d’usage au SMF ?

Le mécanisme URR forme une boucle de rétroaction complète via la procédure PFCP Session Report. Dès qu’une condition de rapport définie par une URR est satisfaite, l’UPF n’a pas nécessairement besoin d’attendre que le SMF interroge les compteurs. Il peut envoyer une PFCP Session Report Request au SMF.

Lorsque Report Type indique que le message contient un Usage Report, le SMF peut identifier l’événement comme un rapport d’usage utilisateur. Plusieurs champs sont particulièrement importants pendant l’analyse. URR ID indique quelle règle a généré le rapport. UR-SEQN identifie la séquence du Usage Report pour cette URR. Usage Report Trigger explique pourquoi le rapport a été généré.

Les valeurs de mesure réelles apparaissent ensuite dans les champs correspondant à la Measurement Method. Pour une mesure fondée sur le volume, Volume Measurement peut contenir les valeurs d’usage total, montant et descendant. Pour une mesure fondée sur le temps, Duration Measurement devient plus important. Des champs tels que Start Time, End Time, Time of First Packet et Time of Last Packet peuvent également aider à déterminer précisément l’intervalle de mesure couvert par le rapport.

La réception du Usage Report ne met pas nécessairement fin au processus. Selon la logique de service, le SMF peut poursuivre en envoyant une PFCP Session Modification pour mettre à jour l’URR, par exemple en modifiant le seuil de rapport, en attribuant un nouveau quota ou en changeant les conditions du rapport suivant.

Le déroulement complet d’une URR peut donc être résumé ainsi :

Le SMF provisionne l’URR → l’UPF mesure le trafic correspondant → la condition de Reporting Trigger est satisfaite → l’UPF envoie un Usage Report → le SMF traite le résultat d’usage → l’URR est mise à jour si nécessaire.

Le rapport d’usage ne consiste donc pas simplement à faire remonter un compteur par l’UPF. Il s’agit d’un processus dynamique dans lequel le plan de contrôle définit la politique de mesure, le plan utilisateur exécute la mesure et le résultat est continuellement renvoyé vers le plan de contrôle. Un problème à n’importe quelle étape peut entraîner des valeurs d’usage inexactes ou des rapports manquants.

Comment un Volume Threshold déclenche-t-il un véritable Usage Report ?

La logique URR devient plus facile à comprendre lorsqu’elle est placée dans un scénario de trafic concret. Supposons que le SMF crée une URR pendant PFCP Session Establishment et demande à l’UPF d’utiliser une mesure fondée sur le volume pour le trafic correspondant à un PDR donné. VOLTH est activé comme Reporting Trigger.

Si Volume Threshold est configuré sur TOVOL avec une valeur de 10240 octets, la règle ne signifie pas que l’utilisateur ne peut consommer que 10240 octets au maximum. Elle signifie plutôt que lorsque le volume total mesuré en liaison montante et descendante atteint ce seuil, l’UPF doit générer un Usage Report.

Lorsque l’UE commence à générer du trafic, l’UPF continue de transférer normalement les paquets tout en cumulant les compteurs d’usage définis par l’URR. Quand le volume cumulé atteint le seuil de rapport, l’UPF envoie une PFCP Session Report Request. Le Usage Report indique VOLTH comme cause du déclenchement, tandis que Volume Measurement contient l’usage total réel ainsi que les valeurs montantes et descendantes correspondantes.

La valeur finale rapportée n’a pas besoin de s’arrêter exactement à 10240 octets. L’UPF évalue le seuil pendant le traitement de paquets réels, et un paquet complet peut faire passer l’usage cumulé directement d’une valeur inférieure au seuil à une valeur supérieure. Il n’est donc pas contradictoire de voir dans un Usage Report une valeur légèrement supérieure au Threshold configuré.

Cela conduit à un principe important lors de l’analyse du comportement d’une URR : un Threshold est une limite de rapport, et non un mécanisme qui tronque la valeur mesurée à un nombre exact. Si un Quota est configuré en parallèle, son épuisement peut déclencher des actions de contrôle supplémentaires, mais ce chemin de contrôle doit être analysé séparément et ne pas être confondu avec un simple rapport fondé sur un seuil.

Le dépannage URR doit suivre quatre niveaux : association, mesure, déclenchement et rapport

Les problèmes liés aux URR peuvent être difficiles à détecter car le service du plan utilisateur peut sembler parfaitement normal. L’UE peut accéder au réseau, le PDR identifie correctement le trafic et le FAR continue de transférer les paquets, alors que les compteurs d’usage visibles dans les systèmes en aval restent incorrects, qu’aucun Usage Report n’est généré ou que l’événement attendu sur le plan de contrôle n’a jamais lieu après l’atteinte d’un seuil.

Pour cette raison, le dépannage d’une URR ne doit pas commencer par la question « L’utilisateur peut-il accéder au réseau ? ». Il doit suivre toute la chaîne de mesure de l’usage.

Commencer par confirmer l’association PDR-URR

Commencez par identifier le PDR qui correspond réellement au trafic, puis confirmez l’URR ID qui lui est associé. Une PFCP Session peut contenir plusieurs PDR et plusieurs URR. L’analyse d’une mauvaise URR n’expliquera pas les résultats d’usage actuels, même si tous les paramètres de cette URR semblent corrects.

Un problème typique apparaît lorsque la condition de correspondance du PDR a changé alors que l’URR reste associée à un ancien PDR ID. Dans ce cas, la cible de mesure elle-même ne correspond plus au trafic réel.

Vérifier ensuite la Measurement Method et la direction

Vérifiez si l’URR est configurée pour une mesure de type Volume, Duration ou Event. Si la mesure est fondée sur le volume, vérifiez également si la règle mesure Total, UL, DL ou le nombre de paquets.

Cette étape est particulièrement importante lorsque les statistiques montantes et descendantes ne correspondent pas aux attentes. Certaines pannes apparentes proviennent simplement du fait que l’URR ne mesure qu’une direction alors que le trafic de test circule dans l’autre, ce qui laisse le compteur attendu inchangé.

Vérifier le Reporting Trigger et le Threshold correspondant

Si l’UPF ne génère pas de rapport, confirmez quel déclencheur a réellement été demandé par le plan de contrôle. Configurer VOLTH sans Volume Threshold approprié, ou attendre des rapports périodiques alors que PERIO n’est pas activé, peut produire des résultats différents du comportement de service attendu.

De la même manière, un rapport fondé sur le temps doit être interprété avec les paramètres de mesure temporelle et les conditions de surveillance associés, plutôt qu’en examinant isolément un seul drapeau de déclenchement.

Enfin, suivre le PFCP Session Report

Une fois la condition de déclenchement satisfaite, vérifiez si l’UPF envoie le Usage Report attendu. Contrôlez Report Type, URR ID, UR-SEQN et Usage Report Trigger par rapport à la PFCP Session en cours.

Si l’UPF a déjà généré le rapport mais qu’aucun nouveau quota, seuil ou aucune action de contrôle ultérieure n’apparaît, le dépannage doit se déplacer vers le SMF et la logique de contrôle qui suit, plutôt que de rester centré sur le compteur de l’UPF.

Si le problème concerne une mesure avant ou après l’application de la QoS, il faut également examiner les drapeaux pertinents de Measurement Information et Usage Information. Une URR ne représente pas un simple nombre isolé. La fenêtre temporelle de mesure, le trafic mesuré et l’étape de traitement à laquelle la mesure est effectuée influencent tous la manière dont la valeur finale d’usage doit être interprétée.

De nombreux cas où « l’usage ne correspond pas » ne sont pas dus à un compteur UPF incorrect, mais à un écart entre le périmètre réel de mesure et le périmètre de comptabilisation attendu.

L’URR transforme le trafic du plan utilisateur en information mesurable pour le plan de contrôle

PDR, FAR et QER décrivent principalement comment les paquets sont identifiés, transférés et soumis au traitement QoS dans l’UPF. L’URR ajoute une autre capacité essentielle : elle permet au plan de contrôle de savoir quelle quantité de trafic du plan utilisateur a réellement été consommée.

L’URR utilise Measurement Method pour définir le périmètre de mesure, Reporting Trigger pour déterminer quand un rapport est requis, et des paramètres tels que Threshold, Quota et Monitoring Time pour contrôler les différentes étapes de mesure de l’usage. Une fois la condition requise satisfaite, l’UPF renvoie le résultat au SMF dans un PFCP Usage Report, après quoi le plan de contrôle peut mettre à jour l’URR ou appliquer une autre action de politique si nécessaire.

La manière la plus pratique de comprendre une URR n’est donc pas de mémoriser des dizaines d’Information Elements, mais de suivre une chaîne complète :

Le PDR sélectionne le trafic à mesurer → l’URR définit la méthode de mesure → l’UPF mesure l’usage en continu → Reporting Trigger détermine quand rapporter → Usage Report renvoie le résultat au SMF → le SMF met à jour la politique de contrôle si nécessaire.

Une fois cette chaîne comprise, des paramètres comme Volume Threshold, Volume Quota, Measurement Period, Monitoring Time et les différents Reporting Triggers cessent d’apparaître comme des champs PFCP isolés. Ils deviennent différents points de contrôle au sein du même mécanisme de mesure et de rapport de l’usage 5G.

Pour les services nécessitant une taxation selon l’usage, une gestion de quota en temps réel ou un ajustement de politique fondé sur la consommation, ce mécanisme fournit la base qui rend le plan utilisateur 5G non seulement capable de transférer le trafic, mais aussi mesurable et contrôlable.

Questions fréquentes