Ein typischer Fehlerfall auf der 5G-Benutzerebene kann zunächst verwirrend sein: Die PDU Session ist erfolgreich aufgebaut, das UE erhält eine IP-Adresse, die PDR trifft auf den erwarteten Verkehr zu, die FAR enthält FORW und Pakete beginnen möglicherweise sogar zu fließen. Trotzdem erlebt der Benutzer Video-Pufferung, unerwartet niedrige Downloadraten oder Verkehr, der nur in eine Richtung funktioniert.
In diesem Fall reicht die Prüfung von PDR und FAR möglicherweise nicht aus, um die Ursache zu erkennen. Das Problem muss nicht darin liegen, ob der Verkehr identifiziert wurde oder wohin das Paket weitergeleitet wurde, sondern vielmehr darin, welche QoS-Richtlinie die UPF angewendet hat, nachdem die Weiterleitung erlaubt wurde. Innerhalb des PFCP-Regelwerks an der N4-Schnittstelle ist die QER (QoS Enforcement Rule, QoS-Durchsetzungsregel) für die Durchsetzung dieser QoS-Richtlinien in der UPF verantwortlich. Sie kann steuern, ob Verkehr passieren darf, Uplink- oder Downlink-Raten begrenzen, Verkehr einem QoS Flow zuordnen und Markierungen auf Transportebene anwenden. Daher müssen PDR, FAR und QER gemeinsam betrachtet werden, um das vollständige Verhalten der Benutzerebene zu verstehen.
Warum wird QER noch benötigt, wenn PDR und FAR bereits funktionieren?
QER lässt sich am einfachsten verstehen, wenn die Zuständigkeiten der verschiedenen UPF-Regeln getrennt betrachtet werden.
Die PDR beantwortet zuerst die Frage „Welcher Verkehr ist das?“. Sie nutzt Bedingungen wie PDI, UE-IP-Adresse, F-TEID und SDF Filter, um Pakete zu erkennen und zu klassifizieren. Sobald der Verkehr identifiziert ist, beantwortet die FAR die nächste Frage: „Was soll mit diesem Paket geschehen und wohin soll es weitergeleitet werden?“
Dass ein Paket weitergeleitet werden darf, bedeutet jedoch nicht, dass dies ohne Einschränkungen geschieht. Wenn das Netz weiterhin Rate, Gating, QoS-Flow-Zuordnung oder Markierung auf Transportebene steuern muss, muss die UPF die zugehörige QER anwenden.
Eine typische Verarbeitungsfolge lässt sich daher vereinfachen zu:
PDR identifiziert den Verkehr → FAR bestimmt die Weiterleitungsaktion → QER setzt die QoS-Richtlinie durch.
Diese Regeln ersetzen einander nicht, sondern arbeiten zusammen. Ein Paket kann korrekt einer PDR entsprechen und von der FAR zugelassen werden, aber weiterhin Ratenbegrenzungen oder Gating-Bedingungen der QER unterliegen. Ohne QER weiß die UPF möglicherweise, dass das Paket weitergeleitet werden soll, verfügt aber nicht über dieselben Richtlinieninformationen, die beschreiben, wie der Verkehr aus QoS-Sicht behandelt werden soll.
Wann wird eine QER installiert und warum kann sie später aktualisiert werden?
Eine QER wird üblicherweise vom SMF während PFCP Session Establishment als Teil der Benutzerebenenregeln einer PDU Session in die UPF provisioniert. Sie ist keine QoS-Regel, die die UPF nach Beobachtung des Verkehrs selbständig erzeugt. Die Steuerungsebene bestimmt das anzuwendende QoS-Verhalten, und die UPF setzt die daraus resultierende Regel um.
Die QER muss nicht über die gesamte Lebensdauer der Sitzung unverändert bleiben. Ändert sich die Richtlinie während eines aktiven Dienstes, kann der SMF eine vorhandene QER über PFCP Session Modification aktualisieren. Änderungen an Teilnehmer-, Anwendungs- oder anderen Richtlinienentscheidungen der Steuerungsebene können daher neue Ratenbegrenzungen, andere Gate-Zustände, eine veränderte QoS-Flow-Zuordnung oder weitere QoS-Parameter erzeugen.
Deshalb sollte die Fehlersuche nicht beim ursprünglichen Create QER enden. Tritt ein QoS-Problem erst auf, nachdem die Sitzung bereits eine Zeit lang läuft, sollten auch spätere Update-QER-Informationen geprüft und mit den ursprünglichen Werten verglichen werden.
Aus Sicht der Steuerungsebene kann die vom SMF verwendete QoS-Richtlinie aus lokaler Konfiguration oder aus mit dem PCF verknüpften Richtlinieninformationen stammen. Wenn die Richtlinie die N4-Schnittstelle erreicht, wird sie als PFCP-Regeln dargestellt, die die UPF durchsetzen kann. Je nach Dienstdesign kann die QoS-Durchsetzung auf PDU-Session-Ebene, QoS-Flow-Ebene oder für spezifischeren SDF- oder Anwendungsverkehr gelten.
Wie kann Gate Status Verkehr blockieren, obwohl die Sitzung normal aussieht?
Gate Status ist einer der direktesten QER-Parameter, weil er unmittelbar ändern kann, ob Verkehr passieren darf.
Die Gate-Zustände für Uplink und Downlink können unabhängig gesteuert werden. Ist ein Gate OPEN, darf Verkehr in dieser Richtung weiterlaufen. Ist es CLOSED, wird der Verkehr in dieser Richtung durch die QoS-Durchsetzungsregel blockiert.
Eine typische Fehlersuchfolge kann daher so aussehen:
Die PDU Session wurde erfolgreich aufgebaut;
Das UE hat eine IP-Adresse erhalten;
Die PDR trifft korrekt zu;
Die FAR enthält FORW;
Der Anwendungsverkehr funktioniert trotzdem nicht.
An diesem Punkt sollten UL Gate und DL Gate in der zugehörigen QER geprüft werden. Da beide Richtungen getrennt gesteuert werden, kann ein Gate OPEN und das andere CLOSED sein. Das Ergebnis kann wie ein einseitiger Fehler der Benutzerebene aussehen: Das UE empfängt Downlink-Verkehr, kann aber keinen Uplink-Verkehr erfolgreich senden, oder umgekehrt.
Darum ist QER eine Durchsetzungsregel und nicht nur ein beschreibendes QoS-Attribut. Ihre Einstellungen können direkt bestimmen, ob bestimmter Verkehr die UPF passieren darf.
Was steuern MBR, GBR und Packet Rate?
Gate Status beantwortet die Frage „Darf der Verkehr passieren?“. Ratenbezogene Parameter beantworten eine andere Frage: „Wie viel Verkehr darf passieren und mit welcher Rate?“. QER kann sowohl auf Bitrate als auch auf Paketrate basierende Grenzen durchsetzen.
Maximale Bitrate (MBR)
MBR definiert die maximale Bitrate für passenden Verkehr und kann für Uplink und Downlink separat konfiguriert werden. In einer 5GC-Umgebung kann die jeweilige Begrenzung je nach Regeldesign einer Sitzungsebene, einem bestimmten QoS Flow oder einem spezifischeren Verkehrsfluss entsprechen.
Wenn ein Benutzer den Dienst normal nutzen kann, der Durchsatz aber wiederholt nahe einer reproduzierbaren Obergrenze stoppt, gehört der MBR der zugehörigen QER zu den zu prüfenden Parametern.
MBR wird leicht mit der Funkkapazität verwechselt. Gute Funkbedingungen und ausreichende Transportbandbreite garantieren nicht, dass die Anwendung die gesamte physische Kapazität nutzen kann. Wenn die UPF einen niedrigeren MBR durchsetzen soll, bleibt der Durchsatz der Benutzerebene auf diesen Wert begrenzt. Bei niedrigem Durchsatz sollten daher auch die N4-QoS-Regeln geprüft werden, statt sich nur auf die Funkleistung zu konzentrieren.
Garantierte Bitrate (GBR)
GBR beschreibt die garantierte Bitrate für Verkehr, der einen definierten Grad an Ressourcengarantie benötigt. Sie kann ebenfalls getrennt für Uplink und Downlink angegeben werden.
GBR kann für Dienste relevant sein, die eine besser vorhersehbare Leistung benötigen, etwa bestimmte Echtzeit-Sprach-, Video- oder andere QoS-sensitive Anwendungen. Der Wert sollte nicht isoliert betrachtet werden; auch der zugehörige QoS Flow und die gesamte QoS-Richtlinie sind zu berücksichtigen.
Konzeptionell definiert MBR eine Obergrenze für die zulässige Rate, während GBR die in der Dienstrichtlinie geforderte garantierte Rate beschreibt.
Paketrate
Einige Verkehrsarten lassen sich nicht ausreichend allein durch die Bitrate beschreiben. QER kann zusätzlich Packet-Rate-Parameter enthalten, die die Zahl der innerhalb eines bestimmten Zeitraums erlaubten Pakete begrenzen.
Das kann bei Arbeitslasten wichtig sein, die viele kleine Pakete erzeugen, etwa DNS-Transaktionen, IoT-Keepalives oder signalisierungsähnlicher Verkehr. Die Gesamtbitrate kann relativ niedrig bleiben, während die Zahl der Pakete pro Sekunde hoch wird. In solchen Fällen erklärt die Prüfung des MBR allein das beobachtete QoS-Verhalten möglicherweise nicht.
Wird die Paketratenbegrenzung erreicht, kann der Benutzer höhere Latenz, langsamere Antworten oder fehlgeschlagene Anfragen erleben, obwohl die gesamte Bandbreitennutzung moderat erscheint.
Welche Aufgaben haben QFI, Flow Level Marking und PPI in einer QER?
QER ist mehr als ein Ratenbegrenzer. Zusätzlich zu Gate Status, MBR und GBR kann sie Parameter zur QoS-Flow-Identifikation und Paketbehandlung enthalten. Gemeinsam helfen diese Parameter festzulegen, wie Verkehr in der Benutzerebene behandelt wird.
QoS Flow Identifier (QFI)
QFI identifiziert einen QoS Flow. Eine einzelne PDU Session kann mehrere QoS Flows enthalten, damit verschiedene Dienstverkehre unterschiedliche QoS-Behandlungen erhalten.
Aus Sicht der Benutzerebene identifiziert QFI, welchem QoS Flow ein Paket zugeordnet ist. Innerhalb der QER kann dieser Bezeichner genutzt werden, um das relevante QoS-Durchsetzungsverhalten mit dem entsprechenden QoS Flow zu verknüpfen.
Wenn der einer Regel zugeordnete QFI nicht zum beabsichtigten Dienstdesign passt, kann der Verkehr einem unerwarteten QoS Flow zugeordnet werden, auch wenn die Ratenparameter selbst korrekt erscheinen. Dadurch kann sich die Ressourcenbehandlung von der für den Dienst vorgesehenen unterscheiden.
DL Flow Level Marking
QER kann die UPF anweisen, Flow-Level-Markierungen auf Downlink-Verkehr anzuwenden, zum Beispiel einen DSCP-Wert für das IP-Transportnetz zu setzen.
Diese Markierung bestimmt nicht, zu welchem 5G QoS Flow das Paket gehört. Stattdessen beeinflusst sie, wie das Paket nach Eintritt in das IP-Transportnetz identifiziert und behandelt werden kann.
Ist die Markierung auf Transportebene falsch, kann 5G-QoS korrekt konfiguriert sein, während das nachgelagerte Transportnetz das Paket dennoch mit einer unerwünschten Priorität behandelt.
Paging Policy Indicator (PPI)
PPI steht im Zusammenhang mit der Paging-Policy-Behandlung von Downlink-Verkehr. Eine QER kann in geeigneten Weiterleitungsszenarien Paging-bezogene Richtlinieninformationen bereitstellen, damit verschiedene Verkehrstypen bei beteiligtem Paging unterschiedlich behandelt werden.
Für ein UE, das sich derzeit nicht in einem aktiven Benutzerebenenzustand befindet, können verschiedene Arten von Downlink-Verkehr unterschiedliche Paging-Auswirkungen haben. PPI liefert Informationen, die Teil dieser differenzierten Behandlung sein können.
Averaging Window
Durchsetzung von Ratenlimits kann nicht immer auf der momentanen Beobachtung eines einzelnen Pakets basieren. Averaging Window definiert das Zeitfenster, über das das bitratebezogene Verhalten bewertet wird.
Ein kürzeres Fenster reagiert schneller auf Burst-Verkehr, während ein längeres Fenster einen glatteren Mittelwert erzeugt und kurze Bursts anders tolerieren kann. Deshalb sollte sich die QER-Analyse nicht nur auf QER ID und MBR konzentrieren. Das resultierende QoS-Verhalten kann vom Zusammenspiel mehrerer Parameter abhängen.
Wie können PFCP-Nachrichten genutzt werden, um zu prüfen, ob QER wie erwartet arbeitet?
Die nützlichste Methode zur QER-Analyse besteht nicht darin, jedes Informationselement auswendig zu lernen, sondern die PFCP-Regel mit dem tatsächlichen Dienstsymptom zu verknüpfen.
Ein Create QER könnte beispielsweise enthalten:
QER ID = 1;
UL Gate = OPEN;
DL Gate = OPEN;
UL MBR = 100000 kbps;
DL MBR = 150000 kbps.
Diese Werte sind nur Beispiele, zeigen aber einen wichtigen Punkt: Ein OPEN Gate bedeutet nicht, dass keine QoS-Einschränkung besteht. Verkehr kann passieren dürfen und trotzdem der MBR-Durchsetzung unterliegen.
Eine praktische Fehlersuchfolge kann diese Schritte verwenden:
Zuerst die PDR identifizieren. Bestimmen, welche PDR tatsächlich auf den betroffenen Verkehr zutrifft. Wird die falsche PDR gewählt, wird die erwartete QER nicht korrekt angewendet.
Die von der PDR referenzierte QER ID prüfen. Nicht jede QER der PFCP-Sitzung ohne Kontext untersuchen. Zuerst die QER bestimmen, die tatsächlich mit dem analysierten Verkehr verknüpft ist.
Create QER und Update QER prüfen. Bestätigen, ob die aktuell wirksame Regel durch eine spätere PFCP Session Modification geändert wurde. Ein QoS-Problem kann durch ein späteres Update statt durch den ursprünglichen Sitzungsaufbau entstehen.
Gate Status prüfen. Die Gate-Zustände für Uplink und Downlink getrennt prüfen. Ein geschlossenes Gate nur in einer Richtung kann einen einseitigen Dienstfehler verursachen.
MBR, GBR und Packet Rate prüfen. Die konfigurierten Grenzen mit dem beobachteten Durchsatz oder Paketverhalten vergleichen, insbesondere wenn der Dienst wiederholt nahe einer festen Rate stoppt.
QFI und weitere QoS-Parameter prüfen. Sicherstellen, dass der vorgesehene QoS Flow, die Markierung und Paging-bezogene Einstellungen zum Dienstdesign passen.
Die Regel mit dem tatsächlichen Benutzerebenenverkehr vergleichen. PFCP zeigt, was die UPF voraussichtlich durchsetzen soll; Durchsatztests und Paketmitschnitte zeigen, was tatsächlich geschehen ist. Die Differenz zwischen beiden Ansichten ist häufig der hilfreichste Hinweis für die Fehlersuche.
Diese Methode ist zuverlässiger, als ein einzelnes QER-Feld isoliert zu interpretieren. Die PFCP-Signalisierung sagt uns, was die UPF durchsetzen sollte, während Tests der Benutzerebene das tatsächlich beobachtete Ergebniszeigen. Der Vergleich dieser beiden Ansichten ist entscheidend, um festzustellen, ob QER wie beabsichtigt arbeitet.
FAQ
Was ist der wichtigste Unterschied zwischen QER und FAR?
FAR bestimmt hauptsächlich, wie ein passendes Paket behandelt und wohin es weitergeleitet werden soll, einschließlich Aktionen wie FORW, DROP oder BUFF. QER setzt QoS-bezogenes Verhalten wie Gating, Ratenbegrenzung, QoS-Flow-Zuordnung und Markierung auf Transportebene durch. Beide arbeiten typischerweise, nachdem die PDR den Verkehr identifiziert hat. Vereinfacht gesagt bestimmt FAR wohin und wie das Paket weitergeleitet wird, während QER bestimmt welche QoS-Behandlung auf diesen Verkehr angewendet wird.
Warum kann der Benutzerdurchsatz trotz OPEN Gate Status niedrig bleiben?
OPEN bedeutet nur, dass Verkehr in dieser Richtung passieren darf. Andere QoS-Einschränkungen werden dadurch nicht aufgehoben. MBR, GBR, Packet Rate und der zugehörige QoS Flow müssen weiterhin geprüft werden. Ist MBR niedriger als die verfügbare Funk- oder Transportkapazität konfiguriert, kann der Durchsatz trotz vollständig geöffneter Gates begrenzt bleiben.
Kann eine QER nur während PFCP Session Establishment erstellt werden?
Nein. Eine QER kann während PFCP Session Establishment erstellt und später über PFCP Session Modification geändert werden. Wenn sich das QoS-Verhalten nach laufender Sitzung ändert, sollten spätere Update-QER-Informationen geprüft werden, statt nur das anfängliche Create QER zu analysieren.
Sind QFI und QER dasselbe?
Nein. QFI ist der Bezeichner eines QoS Flow, während QER eine von der UPF angewandte QoS-Durchsetzungsregel ist. Eine QER kann QFI-Informationen enthalten oder referenzieren, um eine bestimmte QoS-Behandlung mit dem entsprechenden QoS Flow zu verknüpfen. QFI identifiziert welcher QoS Flow beteiligt ist; QER definiert wie die QoS-Kontrolle auf den Verkehr angewendet wird.
Warum kann Verkehr noch fehlschlagen, obwohl die PDR zutrifft und die FAR die Weiterleitung erlaubt?
Weil die Verarbeitung der Benutzerebene nicht zwingend mit der FAR endet. Nachdem die Weiterleitung erlaubt wurde, kann die zugehörige QER weiterhin Gate Status, MBR, GBR, Packet Rate oder andere QoS-Beschränkungen anwenden. Die Fehlersuche sollte PDR, FAR und QER daher als durchgehende Verarbeitungskette betrachten. Eine Abweichung in einer dieser Stufen kann das endgültige Dienstergebnis beeinflussen.
