Un UE peut s’enregistrer et établir une PDU Session avec un acheminement correct des paquets, sans que le SMF reçoive les mises à jour d’usage attendues. Vérifiez la Usage Reporting Rule (URR) : le SMF la configure sur N4 par PFCP, puis l’UPF mesure le trafic et produit des rapports selon les conditions définies. Ces rapports servent à la taxation, à la supervision et aux décisions de politique ; la taxation complète exige d’autres fonctions et procédures.
La place d’URR parmi les règles PFCP
Une Packet Detection Rule (PDR) identifie le trafic et référence les règles applicables. Une Forwarding Action Rule (FAR) définit l’acheminement, le rejet ou la mise en mémoire tampon ; une QoS Enforcement Rule (QER) contrôle la QoS et l’autorisation de passage ; une Buffering Action Rule (BAR) fournit les instructions de mise en tampon associées. URR définit la mesure et les rapports d’usage, ainsi que le comportement lié aux quotas lorsqu’il est configuré.
Une PDR peut référencer plusieurs URR, et plusieurs PDR peuvent partager une URR. Confirmez la PDR correspondante, ses références URR ID et le périmètre d’agrégation prévu. Une URR peut exister sans association à une PDR, mais sa seule présence ne prouve pas que le trafic de test est mesuré.
Measurement Method et périmètre comptable
Measurement Method sélectionne le volume, la durée, les événements ou les combinaisons prises en charge. Volume Measurement rapporte les octets totaux, montants et descendants ; un octet correspond à un byte. MNOP dans Measurement Information demande aussi le comptage des paquets lorsque l’UPF prend cette fonction en charge. Ne confondez pas compteurs d’octets, compteurs de paquets et tailles des charges utiles applicatives.
La mesure de durée dépend de la configuration du comptage temporel. Immediate Start Time Metering peut démarrer la mesure à réception de l’instruction ; sinon, elle commence au premier paquet. Un Inactivity Detection Time non nul suspend la mesure après l’intervalle d’inactivité configuré et la reprend au retour du trafic. La mesure d’événements exige la configuration de détection correspondante.
Pour le volume, les rapports couvrent normalement l’usage après application de la QoS. Si une mesure avant application est aussi demandée, des Usage Reports distincts différencient les deux périmètres au moyen de Usage Information. Les seuils s’appliquent après la QoS. Comparez la même direction, la même fenêtre comptable et le même périmètre de traitement avant de conclure à un écart de compteur.
Déclencheurs de rapport, seuils et quotas
Reporting Triggers s’interprète avec ses paramètres : PERIO utilise Measurement Period ; VOLTH, TIMTH et EVETH concernent les seuils de volume, de temps et d’événements ; VOLQU, TIMQU et EVEQU concernent les quotas. START et STOPT signalent le début et l’arrêt du trafic selon les conditions de détection applicables. Quota Holding Time concerne l’inactivité après une allocation ; ce n’est pas le temporisateur des rapports périodiques.
| Paramètre | Signification et limite |
|---|---|
| Volume Threshold | Une limite de déclenchement de rapport, sans allocation de trafic ni coupure automatique des paquets. |
| Volume Quota | Une allocation d’usage. Son épuisement peut imposer l’arrêt ou la limitation de l’acheminement selon le comportement de quota défini. |
| Measurement Period | L’intervalle utilisé pour les rapports d’usage périodiques demandés. |
| Monitoring Time | Une limite séparant l’usage avant et après un instant défini, avec les seuils ou quotas ultérieurs applicables. |
Le comportement de quota dépasse la simple notification. Selon TS 29.244, l’épuisement d’un quota configuré peut arrêter l’acheminement ou n’autoriser qu’un trafic limité selon la politique de l’opérateur. Lorsqu’il est pris en charge et configuré, FAR ID for Quota Action sélectionne une FAR de substitution pour rejeter, mettre en tampon ou rediriger le trafic. Les responsabilités QER et FAR/BAR restent distinctes ; une URR limitée à un seuil ne limite pas la bande passante.
Lorsque seuil et quota sont configurés, activer uniquement le déclencheur de seuil n’implique pas un second rapport à l’épuisement du quota. Avec les deux déclencheurs, la spécification Release 18 examinée prévoit un rapport aux deux limites ; les versions antérieures peuvent différer. Vérifiez la version implémentée, les capacités, les exemptions et l’ensemble des règles.
Comment un Usage Report parvient au SMF
L’UPF peut envoyer un PFCP Session Report Request dont Report Type indique un Usage Report. Examinez URR ID, UR-SEQN et Usage Report Trigger, puis Volume Measurement ou Duration Measurement selon le cas. Start Time, End Time et les horodatages des paquets délimitent l’intervalle. Un rapport déclenché uniquement par START ne contient pas nécessairement une mesure d’usage non nulle.
Le SMF renvoie un PFCP Session Report Response ; vérifiez son Cause. Une remise réussie ne prouve ni une taxation réussie ni un renouvellement de quota. Le SMF peut envoyer séparément un PFCP Session Modification Request pour mettre les règles à jour. Des Usage Reports peuvent également figurer dans PFCP Session Modification Response et PFCP Session Deletion Response selon les procédures applicables ; ne rechercher que les requêtes spontanées risque donc d’omettre des enregistrements comptables.
Monitoring Time peut produire des rapports séparés pour l’usage avant et après la limite avec le même URR ID. Conservez Usage Information et les informations de séquence, distinguez les retransmissions des nouveaux rapports et rapprochez les intervalles rapportés au lieu de traiter chaque valeur comme un compteur cumulatif de toute la session.
Exemple : un seuil de volume de 10240 octets
Supposons une mesure de volume, VOLTH et un Volume Threshold total de 10240 octets avec TOVOL activé. L’UPF produit un rapport lorsque le total mesuré atteint cette limite ; ce n’est pas une allocation de 10240 octets. La granularité des paquets peut produire une valeur supérieure au seuil. Le quota configuré, s’il existe, doit être analysé séparément.
Vérifications de traces pour un usage absent ou inattendu
Identifiez la session PFCP et la PDR réellement correspondante ; vérifiez les références URR et l’agrégation entre PDR montantes et descendantes.
Vérifiez Measurement Method, l’activation de la mesure, la prise en charge de MNOP, le comptage temporel et le périmètre avant/après QoS.
Associez chaque déclencheur demandé à son seuil, quota ou temporisateur ; vérifiez Monitoring Time et les valeurs ultérieures.
Suivez requêtes et réponses, Cause, URR ID, UR-SEQN, intervalles rapportés et retransmissions ; incluez les réponses de modification et de suppression.
Si les rapports aboutissent, examinez le traitement SMF, l’intégration de taxation, le quota renouvelé et les changements QER/FAR applicables. Vérifiez séparément l’acheminement réel.
Questions fréquentes
Une URR peut-elle mesurer les deux directions du trafic ?
Oui. Les PDR montantes et descendantes concernées peuvent référencer la même URR. Vérifiez l’agrégation prévue sans supposer qu’une URR représente toujours une direction ou un service.
Un Usage Report confirme-t-il qu’un client a été facturé ?
Non. Il confirme un événement de rapport de l’UPF. La corrélation de taxation, la valorisation et les résultats de facturation exigent des preuves issues des systèmes de contrôle et de taxation correspondants.
Faut-il additionner tous les rapports URR ?
Pas sans vérification. Les rapports peuvent décrire différents intervalles, limites de supervision ou périmètres avant/après QoS, et les retransmissions peuvent répéter un rapport. Corrélez les identifiants et le contexte de mesure avant toute agrégation.
