Bei der Fehlersuche auf der Benutzerebene des 5G Core tritt häufig folgendes Problem auf: Das UE ist ordnungsgemäß registriert, die PDU Session wurde aufgebaut, der PDR erkennt den Datenverkehr korrekt und der FAR leitet die Pakete über den erwarteten Pfad weiter, trotzdem verändern sich die für den SMF sichtbaren Nutzungszähler nicht. Abrechnungsereignisse werden möglicherweise nicht ausgelöst oder die Quotensteuerung reagiert nicht zum erwarteten Zeitpunkt. In vielen Fällen funktioniert die Paketweiterleitung selbst einwandfrei. Es fehlt vielmehr ein Mechanismus, der der UPF vorgibt, wie die Nutzung der Benutzerebene zu messen ist und wann das Ergebnis an die Steuerungsebene gemeldet werden soll. Dieser Mechanismus ist die URR (Usage Reporting Rule) auf der N4-Schnittstelle.

Die URR bestimmt nicht, wohin Pakete weitergeleitet werden, und sie setzt auch keine Bandbreitenbegrenzung direkt durch. Stattdessen teilt sie der UPF mit, welcher zugeordnete Datenverkehr gemessen werden soll, wie diese Nutzung zu messen ist und unter welchen Bedingungen das Messergebnis an die Steuerungsebene gemeldet werden muss. Dadurch macht die URR aus Datenverkehr, der auf der Benutzerebene lediglich weitergeleitet würde, zusätzlich messbaren Datenverkehr. Die eigentliche Messung führt die UPF durch, der SMF stellt die Meldebedingungen über PFCP bereit, und die daraus entstehenden Usage Reports bilden eine kontinuierliche Rückkopplung zwischen Benutzer- und Steuerungsebene.

Welches Problem löst die URR im N4-Regelwerk?

Am einfachsten lässt sich die URR verstehen, wenn ihre Aufgabe von denen von PDR, FAR und QER getrennt betrachtet wird. Empfängt die UPF ein Paket, bestimmt zunächst der PDR, zu welchem Datenverkehr es gehört. Nach der Klassifizierung entscheidet der FAR, wie das Paket behandelt und wohin es weitergeleitet werden soll. Der QER wendet die erforderliche QoS-Behandlung an. Die URR beantwortet dagegen eine andere Frage: Wie viel von diesem Datenverkehr wurde tatsächlich genutzt?

Die wichtigsten PFCP-Regeltypen lassen sich wie folgt zusammenfassen:

PDR: Um welchen Datenverkehr handelt es sich?
FAR: Wie soll das Paket behandelt und wohin soll es weitergeleitet werden?
QER: Welche QoS-Behandlung soll auf diesen Datenverkehr angewendet werden?
URR: Wie viel von diesem Datenverkehr wurde genutzt und wann soll diese Nutzung gemeldet werden?

Eine URR muss dem relevanten PDR zugeordnet sein. Der Grund ist einfach: Die UPF kann nicht sinnvoll messen, „wie viel ein Benutzer verbraucht hat“, ohne zunächst zu wissen, welche Pakete zu diesem UE, Dienst oder Datenstrom gehören. Sobald der PDR den Datenverkehr identifiziert hat, kann die zugeordnete URR die Nutzung der passenden Pakete messen. Enthält eine PDU Session mehrere PDRs, können unterschiedliche URRs eingesetzt werden, um feinere Beziehungen für die Nutzungsmessung zu bilden.

Deshalb lautet die erste Frage bei der URR-Fehlersuche normalerweise nicht „Wurde die URR provisioniert?“, sondern „Welcher PDR trifft auf den gemessenen Datenverkehr zu und welche URR ID referenziert dieser PDR?“ Fehlt diese Zuordnung oder ist sie falsch, können die nachfolgenden Mess- und Meldephasen nicht wie erwartet funktionieren.

Wie definiert die URR, was die UPF misst?

Eine URR ist mehr als ein einfacher Verkehrszähler. Eines der ersten Elemente, die in Create URR definiert werden, ist die Measurement Method. Sie gibt der UPF vor, welche Art von Nutzung gemessen werden soll. Abhängig von den Anforderungen des Dienstes kann die Messung auf Datenvolumen, Zeit oder Ereignissen basieren.

Bei typischen paketbasierten Datendiensten ist die volumenbasierte Messung häufig am einfachsten zu beobachten. Die UPF kann Uplink-, Downlink- und Gesamtverkehrsvolumen messen; die entsprechenden Felder in Volume Measurement geben an, welche Statistiken enthalten sind. Das Verkehrsvolumen wird in Byte aufsummiert, sodass eine URR je nach Konfiguration entweder die Gesamtnutzung messen oder zwischen UL- und DL-Verkehr unterscheiden kann.

Ist die erforderliche Funktion aktiviert, kann die Messung auch Paketanzahlen umfassen. Beispielsweise kann das MNOP-Flag in Measurement Information die UPF auffordern, die Anzahl der Uplink-, Downlink- und Gesamtpakete zu messen. Dann sieht der Betreiber nicht nur, wie viele Byte übertragen wurden, sondern auch, wie viele Pakete im Messintervall verarbeitet wurden.

Die zeitbasierte Messung konzentriert sich auf die Dienstdauer. Je nach Konfiguration können Parameter wie Time Threshold, Time Quota, Inactivity Detection Time und der jeweils anzuwendende Zeitmessmechanismus einbezogen werden. Bei einer ereignisbasierten Messung werden stattdessen bestimmte Dienstereignisse gezählt und ein Bericht ausgelöst, wenn eine definierte Anzahl von Ereignissen erreicht ist.

Measurement Method beantwortet damit die grundlegendste Frage einer URR: Was bedeutet „Nutzung“ für diese Regel? Wird das nicht zuerst geklärt, lassen sich Threshold, Quota und Reporting Trigger bei der Analyse von PFCP-Nachrichten leicht verwechseln. Die gewählte Messmethode wirkt sich direkt auf die von der UPF geführten Zählertypen, das Format des Usage Report und die Interpretation des Ergebnisses durch den SMF aus.

Reporting Trigger bestimmt, wann die UPF einen Bericht senden muss

Eine Messmethode allein reicht nicht aus. Wenn die UPF Zähler lediglich weiter aufsummiert, ohne dass eine Meldebedingung definiert ist, gibt es keinen festgelegten Zeitpunkt, an dem der SMF das Ergebnis erhalten soll. Damit sind die Reporting Triggers ein weiterer Kernbestandteil des URR-Mechanismus.

Diese Trigger können entsprechend der Netzrichtlinie kombiniert werden. PERIO dient für periodische Berichte. VOLTH zeigt an, dass beim Erreichen eines Volumenschwellenwerts ein Bericht erzeugt werden soll. TIMTH gilt für einen Zeitschwellenwert. START und STOPT können Usage Reports auslösen, wenn die UPF den Beginn beziehungsweise das Ende des Datenverkehrs erkennt.

Eine weitere Gruppe von Triggern ist enger mit der Quotensteuerung verknüpft. VOLQU ist mit Bedingungen für Volumenquoten verbunden, TIMQU mit Bedingungen für Zeitquoten und EVEQU mit Bedingungen für Ereignisquoten. Quota Holding Time kann außerdem genutzt werden, wenn bereits eine Quote zugeteilt wurde, der Teilnehmer jedoch innerhalb eines definierten Zeitraums keinen Benutzerebenenverkehr erzeugt.

Besonders wichtig ist die Unterscheidung zwischen Threshold und Quota, da beide in PFCP unterschiedliche Zwecke erfüllen und bei der Trace-Analyse häufig verwechselt werden:

Ein Threshold beschreibt hauptsächlich, wann ein Messergebnis gemeldet werden soll, während eine Quota eher beschreibt, wie viele Ressourcen noch zur Nutzung verfügbar sind. Zeigt ein PFCP-Trace lediglich, dass VOLTH oder VOLQU gesetzt ist, ohne dass der zugehörige Threshold- oder Quota-Parameter geprüft wird, lässt sich die tatsächliche Dienstlogik leicht falsch interpretieren.

Ist beispielsweise VOLTH konfiguriert, der zugehörige Volume Threshold jedoch nicht korrekt definiert, hat die UPF keine sinnvolle Verkehrsgrenze, an der der erwartete Bericht ausgelöst werden kann.

Wie sendet die UPF Nutzungsergebnisse an den SMF?

Der URR-Mechanismus bildet über das PFCP-Session-Report-Verfahren eine vollständige Rückkopplung. Sobald eine von einer URR definierte Meldebedingung erfüllt ist, muss die UPF nicht zwingend darauf warten, dass der SMF die Zähler abfragt. Sie kann eine PFCP Session Report Request an den SMF senden.

Wenn Report Type angibt, dass die Nachricht einen Usage Report enthält, kann der SMF das Ereignis als Nutzungsbericht erkennen. Mehrere Felder sind bei der Analyse besonders wichtig. URR ID kennzeichnet, welche Regel den Bericht erzeugt hat. UR-SEQN kennzeichnet die Sequenz des Usage Report für diese URR. Usage Report Trigger erklärt, warum der Bericht erzeugt wurde.

Die tatsächlichen Messwerte erscheinen anschließend in den Feldern, die zur Measurement Method gehören. Bei volumenbasierter Messung kann Volume Measurement Gesamt-, Uplink- und Downlink-Nutzungswerte enthalten. Bei zeitbasierter Messung gewinnt Duration Measurement an Bedeutung. Felder wie Start Time, End Time, Time of First Packet und Time of Last Packet helfen außerdem, das genaue Messintervall zu bestimmen, das vom Bericht abgedeckt wird.

Der Empfang eines Usage Report beendet den Vorgang nicht zwangsläufig. Abhängig von der Dienstlogik kann der SMF anschließend eine PFCP Session Modification senden, um die URR zu aktualisieren, beispielsweise durch Ändern des Meldeschwellenwerts, Zuweisen einer neuen Quote oder Anpassen der Bedingungen für den nächsten Bericht.

Der vollständige URR-Ablauf lässt sich daher wie folgt zusammenfassen:

SMF provisioniert URR → UPF misst den passenden Datenverkehr → Reporting-Trigger-Bedingung wird erfüllt → UPF sendet einen Usage Report → SMF verarbeitet das Nutzungsergebnis → URR wird bei Bedarf aktualisiert.

Die Nutzungsberichterstattung besteht somit nicht einfach darin, dass die UPF einen Zähler hochlädt. Es handelt sich um einen dynamischen Prozess: Die Steuerungsebene legt die Messrichtlinie fest, die Benutzerebene führt die Messung aus, und das Ergebnis wird fortlaufend an die Steuerungsebene zurückgemeldet. Ein Problem in jeder einzelnen Phase kann zu falschen Nutzungswerten oder fehlenden Berichten führen.

Wie löst ein Volume Threshold einen tatsächlichen Usage Report aus?

Die URR-Logik wird leichter verständlich, wenn sie auf ein konkretes Verkehrsszenario angewendet wird. Angenommen, der SMF erstellt während PFCP Session Establishment eine URR und weist die UPF an, für den von einem bestimmten PDR erfassten Datenverkehr eine volumenbasierte Messung zu verwenden. VOLTH wird als Reporting Trigger aktiviert.

Ist der Volume Threshold für TOVOL auf 10240 Byte gesetzt, bedeutet diese Regel nicht, dass der Benutzer höchstens 10240 Byte verbrauchen darf. Sie bedeutet vielmehr: Sobald das gemessene Gesamtvolumen aus Uplink und Downlink diesen Schwellenwert erreicht, soll die UPF einen Usage Report erzeugen.

Sobald das UE Datenverkehr erzeugt, leitet die UPF die Pakete normal weiter und summiert gleichzeitig die von der URR definierten Nutzungszähler auf. Erreicht das kumulierte Volumen den Meldeschwellenwert, sendet die UPF eine PFCP Session Report Request. Der Usage Report nennt VOLTH als Auslösegrund, während Volume Measurement die tatsächliche Gesamtnutzung sowie die jeweiligen Uplink- und Downlink-Werte enthält.

Der endgültig gemeldete Wert muss nicht exakt bei 10240 Byte enden. Die UPF bewertet den Schwellenwert während der Verarbeitung realer Pakete, und ein vollständiges Paket kann die kumulierte Nutzung direkt von unterhalb auf oberhalb des Schwellenwerts erhöhen. Daher ist ein Usage-Report-Wert, der etwas über dem konfigurierten Threshold liegt, kein Widerspruch.

Daraus ergibt sich ein wichtiges Prinzip für die Analyse des URR-Verhaltens: Ein Threshold ist eine Meldegrenze und kein Mechanismus, der den Messwert auf eine exakte Zahl abschneidet. Ist gleichzeitig eine Quota konfiguriert, kann deren Ausschöpfung zusätzliche Steuerungsaktionen auslösen. Dieser Pfad sollte jedoch separat analysiert und nicht mit einer einfachen schwellenwertbasierten Meldung verwechselt werden.

URR-Fehlersuche sollte vier Ebenen folgen: Zuordnung, Messung, Trigger und Meldung

URR-Probleme können schwer zu erkennen sein, weil der Dienst auf der Benutzerebene selbst völlig normal erscheinen kann. Das UE kann auf das Netz zugreifen, der PDR erfasst den Datenverkehr korrekt und der FAR leitet die Pakete weiter, während die in den nachgelagerten Systemen sichtbaren Nutzungszähler trotzdem falsch bleiben, kein Usage Report erzeugt wird oder das erwartete Ereignis auf der Steuerungsebene nach Erreichen eines Schwellenwerts nicht eintritt.

Deshalb sollte die URR-Fehlersuche nicht mit der Frage „Kann der Benutzer auf das Netz zugreifen?“ beginnen. Stattdessen muss die vollständige Nutzungsmesskette verfolgt werden.

Zuerst die PDR-zu-URR-Zuordnung prüfen

Identifizieren Sie zunächst den PDR, der tatsächlich auf den Datenverkehr zutrifft, und prüfen Sie anschließend die damit verknüpfte URR ID. Eine PFCP Session kann mehrere PDRs und mehrere URRs enthalten. Wird die falsche URR analysiert, lassen sich die aktuellen Nutzungsergebnisse nicht erklären, selbst wenn alle Parameter dieser URR korrekt erscheinen.

Ein typisches Problem besteht darin, dass sich die Matching-Bedingung des PDR geändert hat, während die URR weiterhin mit einer früheren PDR ID verknüpft ist. In diesem Fall hat sich das Messziel selbst vom tatsächlichen Datenverkehr entfernt.

Danach Measurement Method und Richtung prüfen

Prüfen Sie, ob die URR für Volume-, Duration- oder Event-Messung konfiguriert ist. Bei volumenbasierter Messung ist außerdem zu prüfen, ob Total, UL, DL oder auch Paketanzahlen gemessen werden.

Dieser Schritt ist besonders wichtig, wenn Uplink- und Downlink-Statistiken nicht den Erwartungen entsprechen. Manche vermeintlichen Fehler entstehen lediglich dadurch, dass die URR nur eine Richtung misst, während der Testverkehr in die entgegengesetzte Richtung läuft und der erwartete Zähler deshalb unverändert bleibt.

Reporting Trigger und zugehörigen Threshold prüfen

Wenn die UPF keinen Bericht erzeugt, prüfen Sie, welchen Trigger die Steuerungsebene tatsächlich angefordert hat. VOLTH ohne einen passenden Volume Threshold zu konfigurieren oder periodische Berichte zu erwarten, obwohl PERIO nicht aktiviert ist, kann zu Ergebnissen führen, die vom beabsichtigten Dienstverhalten abweichen.

Ebenso sollte eine zeitbasierte Berichterstattung gemeinsam mit den zugehörigen Zeitmessparametern und Überwachungsbedingungen interpretiert werden, statt nur ein einzelnes Trigger-Flag isoliert zu betrachten.

Abschließend den PFCP Session Report verfolgen

Sobald die Triggerbedingung erfüllt ist, prüfen Sie, ob die UPF den erwarteten Usage Report sendet. Vergleichen Sie Report Type, URR ID, UR-SEQN und Usage Report Trigger mit der aktuellen PFCP Session.

Hat die UPF den Bericht bereits erzeugt, erscheinen jedoch keine neue Quote, kein neuer Schwellenwert und keine nachfolgende Steuerungsaktion, sollte sich die Fehlersuche auf den SMF und die anschließende Logik der Steuerungsebene verlagern, statt weiter auf den UPF-Zähler fokussiert zu bleiben.

Wenn es bei dem Problem um Messungen vor oder nach der QoS-Durchsetzung geht, sollten auch die relevanten Flags in Measurement Information und Usage Information geprüft werden. Eine URR steht nicht nur für einen einzelnen isolierten Wert. Das Messzeitfenster, der gemessene Datenverkehr und die Verarbeitungsstufe, in der die Messung stattfindet, beeinflussen alle die Interpretation des endgültigen Nutzungswerts.

Viele Fälle, in denen „die Nutzung nicht übereinstimmt“, werden nicht durch einen fehlerhaften UPF-Zähler verursacht, sondern durch eine Abweichung zwischen dem tatsächlichen Messumfang und dem erwarteten Abrechnungsumfang.

URR macht Benutzerebenenverkehr für die Steuerungsebene messbar

PDR, FAR und QER beschreiben vor allem, wie Pakete innerhalb der UPF identifiziert, weitergeleitet und einer QoS-Behandlung unterzogen werden. Die URR ergänzt eine weitere wesentliche Fähigkeit: Sie ermöglicht der Steuerungsebene zu erkennen, wie viel Benutzerebenenverkehr tatsächlich verbraucht wurde.

Die URR nutzt Measurement Method zur Definition des Messumfangs, Reporting Trigger zur Festlegung des Meldezeitpunkts und Parameter wie Threshold, Quota und Monitoring Time zur Steuerung verschiedener Phasen der Nutzungsmessung. Ist die erforderliche Bedingung erfüllt, sendet die UPF das Ergebnis in einem PFCP Usage Report an den SMF zurück. Anschließend kann die Steuerungsebene bei Bedarf die URR aktualisieren oder eine andere Richtlinienaktion ausführen.

Die praktischste Methode, eine URR zu verstehen, besteht daher nicht darin, Dutzende Information Elements auswendig zu lernen, sondern eine vollständige Kette zu verfolgen:

PDR wählt den zu messenden Datenverkehr → URR definiert die Messmethode → UPF misst die Nutzung fortlaufend → Reporting Trigger bestimmt den Meldezeitpunkt → Usage Report liefert das Ergebnis an den SMF → SMF aktualisiert bei Bedarf die Steuerungsrichtlinie.

Ist diese Kette klar, wirken Parameter wie Volume Threshold, Volume Quota, Measurement Period, Monitoring Time und die verschiedenen Reporting Triggers nicht mehr wie isolierte PFCP-Felder. Sie sind vielmehr unterschiedliche Steuerungspunkte innerhalb desselben Mechanismus zur Messung und Meldung der 5G-Nutzung.

Für Dienste, die nutzungsbasierte Abrechnung, Quotenverwaltung in Echtzeit oder verbrauchsabhängige Richtlinienanpassungen benötigen, bildet dieser Mechanismus die Grundlage dafür, dass die 5G-Benutzerebene Datenverkehr nicht nur weiterleiten kann, sondern auch messbar und steuerbar ist.

Häufig gestellte Fragen