Ein UE kann sich registrieren und eine PDU Session aufbauen, während Pakete korrekt weitergeleitet werden, die SMF jedoch keine erwarteten Nutzungsaktualisierungen erhält. Prüfen Sie die Usage Reporting Rule (URR): Die SMF richtet sie über N4 mittels PFCP ein, und die UPF misst und meldet den Verkehr unter den konfigurierten Bedingungen. Nutzungsberichte unterstützen Gebührenerfassung, Überwachung und Richtlinienentscheidungen; die vollständige Abrechnung benötigt weitere Funktionen und Verfahren.
Die Rolle der URR unter den PFCP-Regeln
Eine Packet Detection Rule (PDR) erkennt Verkehr und verweist auf geltende Regeln. Eine Forwarding Action Rule (FAR) bestimmt Weiterleitung, Verwerfen oder Puffern; eine QoS Enforcement Rule (QER) steuert QoS und Freigabe beziehungsweise Sperrung; eine Buffering Action Rule (BAR) liefert zugehörige Pufferanweisungen. URR definiert Nutzungsmessung und Berichte sowie gegebenenfalls das konfigurierte Kontingentverhalten.
Eine PDR kann mehrere URRs referenzieren, und mehrere PDRs können eine URR teilen. Prüfen Sie die zutreffende PDR, ihre URR ID-Verweise und den vorgesehenen Aggregationsumfang. Eine URR kann ohne PDR-Zuordnung existieren; ihre bloße Existenz belegt jedoch keine Messung des Testverkehrs.
Measurement Method und Abrechnungsumfang
Measurement Method wählt Volumen, Dauer, Ereignisse oder unterstützte Kombinationen. Volume Measurement meldet gesamte, aufwärts und abwärts übertragene Oktette; ein Oktett entspricht einem Byte. MNOP in Measurement Information fordert zusätzlich Paketzähler an, wenn die UPF diese Funktion unterstützt. Verwechseln Sie Bytezähler, Paketzähler und Größen der Anwendungsnutzdaten nicht.
Die Dauermessung hängt von der Zeitmesskonfiguration ab. Immediate Start Time Metering kann die Messung auf Anweisung starten; andernfalls beginnt sie mit dem ersten Paket. Ein Inactivity Detection Time-Wert ungleich null unterbricht die Zeitmessung nach dem konfigurierten Inaktivitätsintervall und setzt sie bei erneutem Verkehr fort. Die Ereignismessung erfordert die entsprechende Erkennungskonfiguration.
Bei der Volumenmessung beziehen sich Berichte normalerweise auf die Nutzung nach der QoS-Durchsetzung. Wird auch eine Messung davor angefordert, unterscheiden separate Usage Reports beide Bereiche durch Usage Information. Schwellen gelten nach der QoS-Durchsetzung. Vergleichen Sie dieselbe Richtung, dasselbe Abrechnungsfenster und denselben Verarbeitungsumfang, bevor Sie einen Zählerfehler feststellen.
Berichtsauslöser, Schwellen und Kontingente
Reporting Triggers sind zusammen mit ihren Parametern zu lesen: PERIO verwendet Measurement Period; VOLTH, TIMTH und EVETH betreffen Volumen-, Zeit- und Ereignisschwellen; VOLQU, TIMQU und EVEQU betreffen Kontingente. START und STOPT melden Beginn und Ende des Verkehrs unter den geltenden Erkennungsbedingungen. Quota Holding Time betrifft Inaktivität nach einer Zuteilung und ist kein Timer für periodische Berichte.
| Parameter | Bedeutung und Grenze |
|---|---|
| Volume Threshold | Eine Berichtsgrenze, kein Verkehrskontingent und keine automatische Paketabschaltung. |
| Volume Quota | Ein zugeteiltes Nutzungskontingent. Seine Erschöpfung kann gemäß dem festgelegten Kontingentverhalten das Stoppen oder Einschränken der Weiterleitung verlangen. |
| Measurement Period | Das Intervall für angeforderte periodische Nutzungsberichte. |
| Monitoring Time | Eine Grenze zwischen Nutzung vor und nach einem festgelegten Zeitpunkt mit den jeweils geltenden nachfolgenden Schwellen oder Kontingenten. |
Kontingentverhalten umfasst mehr als eine Benachrichtigung. Nach TS 29.244 kann ein erschöpftes konfiguriertes Kontingent die Weiterleitung stoppen oder gemäß Betreiberrichtlinie nur begrenzten Verkehr zulassen. Falls unterstützt und konfiguriert, wählt FAR ID for Quota Action eine Ersatz-FAR zum Verwerfen, Puffern oder Umleiten. Die Aufgaben von QER und FAR/BAR bleiben getrennt; eine URR nur mit Schwelle ist kein Bandbreitenbegrenzer.
Sind Schwelle und Kontingent konfiguriert, bedeutet ein ausschließlich aktivierter Schwellenauslöser keinen zweiten Bericht bei Kontingenterschöpfung. Bei beiden aktivierten Auslösern sieht die geprüfte Release 18-Spezifikation Berichte an beiden Grenzen vor; ältere Versionen können abweichen. Prüfen Sie implementierte Version, Fähigkeiten, Ausnahmen und den vollständigen Regelsatz.
Wie ein Usage Report die SMF erreicht
Die UPF kann einen PFCP Session Report Request senden, dessen Report Type einen Usage Report anzeigt. Prüfen Sie URR ID, UR-SEQN und Usage Report Trigger sowie anschließend je nach Fall Volume Measurement oder Duration Measurement. Start Time, End Time und Paketzeitstempel begrenzen das Intervall. Ein allein durch START ausgelöster Bericht muss keine von null verschiedene Nutzungsmessung enthalten.
Die SMF antwortet mit einem PFCP Session Report Response; prüfen Sie dessen Cause. Eine erfolgreiche Zustellung belegt weder erfolgreiche Abrechnung noch Kontingenterneuerung. Die SMF kann separat einen PFCP Session Modification Request zur Regelaktualisierung senden. Usage Reports können nach den jeweiligen Verfahren auch in PFCP Session Modification Response und PFCP Session Deletion Response stehen. Wer nur unaufgeforderte Requests sucht, kann deshalb Abrechnungsdatensätze übersehen.
Monitoring Time kann getrennte Berichte für die Nutzung vor und nach der Grenze mit derselben URR ID erzeugen. Bewahren Sie Usage Information und Sequenzinformationen auf, unterscheiden Sie Wiederholungsübertragungen von neuen Berichten und gleichen Sie die gemeldeten Intervalle ab, statt jeden Wert als Gesamtzähler der Sitzung zu behandeln.
Beispiel: eine Volumenschwelle von 10240 Byte
Angenommen sind Volumenmessung, VOLTH und eine gesamte Volume Threshold von 10240 Byte bei gesetztem TOVOL. Die UPF meldet, wenn die gemessene Summe diese Grenze erreicht; der Wert ist kein Kontingent von 10240 Byte. Die Paketgranularität kann einen Bericht oberhalb der Schwelle erzeugen. Ein konfiguriertes Kontingent ist gegebenenfalls separat zu analysieren.
Trace-Prüfliste für fehlende oder unerwartete Nutzung
Identifizieren Sie die PFCP-Sitzung und tatsächlich zutreffende PDR; prüfen Sie URR-Verweise sowie die Aggregation über Uplink- und Downlink-PDRs.
Prüfen Sie Measurement Method, Messaktivierung, MNOP-Unterstützung, Zeitmessung und den Umfang vor/nach QoS.
Ordnen Sie jedem angeforderten Auslöser seine Schwelle, sein Kontingent oder seinen Timer zu; prüfen Sie Monitoring Time und nachfolgende Werte.
Verfolgen Sie Requests und Responses, Cause, URR ID, UR-SEQN, gemeldete Intervalle und Wiederholungsübertragungen; berücksichtigen Sie Änderungs- und Löschantworten.
Sind Berichte erfolgreich, prüfen Sie SMF-Verarbeitung, Abrechnungsintegration, erneuertes Kontingent und geltende QER/FAR-Änderungen. Prüfen Sie das tatsächliche Weiterleitungsverhalten separat.
Häufige Fragen
Kann eine URR beide Verkehrsrichtungen messen?
Ja. Die entsprechenden Uplink- und Downlink-PDRs können dieselbe URR referenzieren. Prüfen Sie die vorgesehene Aggregation, statt stets eine Richtung oder einen Dienst pro URR anzunehmen.
Bestätigt ein Usage Report, dass einem Kunden etwas berechnet wurde?
Nein. Er bestätigt ein Berichtsereignis der UPF. Gebührenkorrelation, Bewertung und Rechnungsergebnisse erfordern Nachweise aus den entsprechenden Steuerungs- und Abrechnungssystemen.
Sollten alle URR-Berichte addiert werden?
Nicht ungeprüft. Berichte können verschiedene Intervalle, Überwachungsgrenzen oder Bereiche vor/nach QoS beschreiben, und Wiederholungsübertragungen können einen Bericht wiederholen. Korrelieren Sie Kennungen und Messkontext vor der Aggregation.
