Wenn eine UPF ein Paket der Benutzerebene empfängt, entscheidet sie nicht sofort, wohin dieses Paket weitergeleitet werden soll. Zuerst muss sie bestimmen, zu welcher PFCP-Sitzung das Paket gehört und welche Verarbeitungsregel anzuwenden ist. Innerhalb des PFCP-Regelwerks an der N4-Schnittstelle übernimmt die PDR (Packet Detection Rule, Paketerkennungsregel) diese erste Stufe der Paketverarbeitung. Eine PDR teilt der UPF mit, welche Pakete zu einer bestimmten Verkehrskategorie gehören. Sobald ein Paket übereinstimmt, kann die UPF die zugehörigen FAR-, QER-, URR- und weiteren Regeln für Weiterleitung, QoS-Durchsetzung und Nutzungsberichte anwenden.
Am einfachsten lässt sich eine PDR verstehen, wenn drei unterschiedliche Aufgaben getrennt betrachtet werden: Die PDR identifiziert den Verkehr, die PDI definiert die Abgleichbedingungen, und FAR/QER/URR bestimmen, was nach einer Übereinstimmung geschieht. Wenn diese Rollen getrennt betrachtet werden, ist die PFCP-Paketverarbeitung deutlich leichter nachzuvollziehen, als jedes einzelne IE auswendig zu lernen.
Welches Problem löst eine PDR an der N4-Schnittstelle?
N4 ist die Steuerschnittstelle zwischen SMF und UPF im 5G Core. Die SMF verwendet PFCP-Sitzungen, um Regeln für die Benutzerebene in der UPF zu installieren; die PDR ist dabei der Regeltyp zur Erkennung und Klassifizierung von Paketen. Eine PDR wird üblicherweise beim Aufbau einer PFCP-Sitzung erstellt und kann später über eine PFCP Session Modification hinzugefügt, entfernt oder aktualisiert werden. Die Paketklassifizierung wird somit durch Regeln gesteuert, die von der SMF entsprechend der aktuellen PDU Session, dem Verkehrsfluss und den Weiterleitungsanforderungen bereitgestellt werden.
Eine einzelne PFCP-Sitzung kann mehrere PDRs enthalten. Für dieselbe PDU Session werden beispielsweise normalerweise getrennte Regeln für Uplink- und Downlink-Verkehr benötigt. Zusätzliche PDRs können erforderlich sein, wenn die Sitzung mehrere Service Data Flows, unterschiedliche QoS Flows oder feinere Verkehrsklassifizierungen enthält. Eine PDR kann daher als Verkehrsauswahlregel der UPF verstanden werden: Sie bestimmt, welche Art von Paket eingetroffen ist, bevor andere Regeln festlegen, wie es verarbeitet wird.
Wie findet die UPF die passende PDR?
Die Paketverarbeitung in der UPF folgt einer definierten Reihenfolge. Nachdem ein Paket in die UPF gelangt, wird zunächst die zugehörige PFCP-Sitzung ermittelt und anschließend werden die mit dieser Sitzung verknüpften PDRs ausgewertet. Wenn mehr als eine PDR potenziell passen könnte, verwendet die UPF den Wert Precedence zur Bestimmung der relativen Priorität. Ein niedrigerer Precedence-Wert bedeutet eine höhere Priorität, sodass Regeln mit höherer Priorität bei der Suche nach einer Übereinstimmung vor Regeln mit niedrigerer Priorität ausgewertet werden.
Wenn eine PDR übereinstimmt, führt die PDR selbst nicht alle nachfolgenden Paketverarbeitungsschritte aus. Stattdessen kann sie auf andere PFCP-Regeln verweisen:
FAR (Forwarding Action Rule, Weiterleitungsaktionsregel): legt fest, wie das Paket behandelt und weitergeleitet werden soll, etwa ob es weitergeleitet, verworfen, gepuffert oder an eine bestimmte Zielschnittstelle gesendet wird.
QER (QoS Enforcement Rule, QoS-Durchsetzungsregel): wendet QoS-bezogene Kontrollen wie Gating, Ratenbegrenzung und weitere Verkehrsbehandlungen an.
URR (Usage Reporting Rule, Nutzungsberichtsregel): misst die Verkehrsnutzung und liefert Berichtsinformationen, die für Abrechnung, Überwachung oder richtlinienbezogene Zwecke verwendet werden können.
Der gesamte Verarbeitungsweg in der UPF lässt sich daher vereinfachen zu:
PFCP-Sitzung identifizieren → PDRs nach Precedence auswerten → Paket klassifizieren → FAR/QER/URR anwenden. Die Reihenfolge ist entscheidend. Die FAR beantwortet die Frage, wie ein Paket behandelt werden soll; die UPF benötigt jedoch zunächst eine PDR, um festzustellen, für welches Paket oder welchen Verkehrsfluss die Aktion gilt.
Welche Hauptparameter enthält eine PDR?
Ein Create PDR enthält mehrere Information Elements. Für das Verständnis des Paketerkennungsverhaltens muss jedoch zunächst nur eine kleinere Gruppe betrachtet werden. Diese Parameter definieren, wie die Regel identifiziert wird, wie Pakete abgeglichen werden und welche nachgelagerten Verarbeitungsregeln mit dem Ergebnis verknüpft sind.
| Parameter | Hauptfunktion |
|---|---|
| PDR-ID | Identifiziert die PDR innerhalb der PFCP-Sitzung eindeutig und unterscheidet sie von anderen Paketerkennungsregeln |
| Precedence | Definiert die relative Priorität der PDR bei der Auswertung mehrerer Regeln; niedrigere Werte bedeuten höhere Priorität |
| PDI | Enthält die Paketerkennungskriterien, anhand derer die UPF feststellt, ob eingehender Verkehr mit der PDR übereinstimmt |
| Outer Header Removal | Gibt an, ob die UPF einen äußeren Protokollheader entfernen soll, beispielsweise einen GTP-U/UDP/IP-Header bei Uplink-Verkehr |
| FAR-ID | Verweist auf die FAR, welche die Weiterleitungsaktion für passende Pakete definiert |
| URR-ID | Verweist auf eine URR zur Verkehrsmessung und Nutzungsberichterstattung |
| QER-ID | Verweist auf eine QER, die QoS-bezogene Behandlung auf den passenden Verkehr anwendet |
| Vordefinierte Regeln aktivieren | Aktiviert eine oder mehrere bereits in der UPF vorhandene vordefinierte Regeln |
| Aktivierungszeit / Deaktivierungszeit | Legt fest, wann die PDR aktiv wird und wann sie nicht mehr aktiv ist |
Unter diesen Parametern ist das Element, das tatsächlich definiert, welche Pakete mit der PDR übereinstimmen können, die PDI (Packet Detection Information). FAR-ID und QER-ID verweisen auf Aktionen, die nach der Klassifizierung des Verkehrs stattfinden; die PDI enthält dagegen die Informationen für die Klassifizierung selbst.
Wie definiert die PDI die Bedingungen für den Paketabgleich?
Die PDI kann als Menge der Paketerkennungsbedingungen innerhalb einer PDR verstanden werden. Sie ist kein einzelnes Feld, sondern enthält mehrere Parameter, die kombiniert werden können, um Verkehr anhand des Eintrittspunkts in die UPF, der Tunnelinformationen, der UE-Adresse, der Eigenschaften des Service-Flows und der QoS-Informationen zu identifizieren. Zu den üblichen PDI-Parametern gehören:
Source Interface: kennzeichnet die logische Seite, von der das Paket eintrifft, zum Beispiel Access für Verkehr von der Zugangsseite oder Core für Verkehr aus dem Core- oder Datennetzbereich.
Local F-TEID: kann zum Abgleich der TEID und der zugehörigen Adressinformationen eines GTP-U-Tunnels verwendet werden und ist insbesondere bei der Erkennung von Uplink-Tunnelverkehr wichtig.
Network Instance: kennzeichnet ein in der UPF konfiguriertes logisches Netz, beispielsweise eine Internet- oder IMS-bezogene Netzinstanz.
UE IP Address: gleicht den Verkehr abhängig von der Paketrichtung mit der Quell- oder Ziel-IP-Adresse des UE ab.
Traffic Endpoint ID: kennzeichnet einen Verkehrsendpunkt, der in unterstützten PDI-Optimierungsszenarien verwendet werden kann.
SDF Filter: ermöglicht eine feinere Filterung auf Basis von Parametern wie Quell- und Zieladresse, Protokoll, Ports und Verkehrsrichtung.
Application ID: kann zur Verkehrserkennung auf Anwendungsebene verwendet werden, wenn die UPF über die erforderliche Anwendungserkennungsfunktion verfügt.
QFI (QoS Flow Identifier): identifiziert den dem Paket zugeordneten QoS Flow.
Source Interface Type: liefert zusätzliche Informationen über die mit der Quelle verknüpfte 3GPP-Schnittstelle, beispielsweise N3, N6 oder N9.
Wenn mehrere Abgleichparameter in der PDI vorhanden sind, definieren sie gemeinsam die Paketerkennungsbedingung. Das eingehende Paket muss die jeweils geltenden Kriterien erfüllen, bevor die PDR als passend gilt. Dadurch kann die SMF Regeln von einer breiten Klassifizierung auf Sitzungsebene bis hin zu einer deutlich spezifischeren Service-Flow-Erkennung erstellen.
Wie granular kann die Verkehrserkennung mit einem SDF Filter werden?
Source Interface, F-TEID und UE IP Address können ausreichen, um eine Sitzung oder eine breite Verkehrskategorie zu identifizieren, unterscheiden jedoch nicht immer einzelne Service Data Flows. Ein SDF Filter ermöglicht eine feinere Klassifizierung. Seine Flow Description kann Quell-IP-Adresse, Ziel-IP-Adresse, Protokollnummer, Quellport, Zielport und Verkehrsrichtung enthalten. Damit kann die UPF konkrete IP-Flows unterscheiden, anstatt alle Pakete eines UE gleich zu behandeln.
Ein SDF Filter kann außerdem zusätzliche Abgleichinformationen enthalten:
TOS / Traffic Class: gleicht das IPv4-Feld Type of Service oder das IPv6-Feld Traffic Class ab.
Security Parameter Index (SPI): kann beim Abgleich von Verkehr verwendet werden, der mit einer IPsec Security Association verknüpft ist.
Flow Label: gleicht das in einem IPv6-Header enthaltene Flow Label ab.
SDF Filter ID: identifiziert den zugehörigen SDF Filter zu Verwaltungs- und Referenzzwecken.
Auf diese Weise entsteht ein mehrstufiges Klassifizierungsmodell. PDI-Parameter wie Schnittstelle, Tunnel und UE-Adresse können den Verkehr zunächst auf einen bestimmten Kontext eingrenzen; der SDF Filter identifiziert anschließend einzelne IP-Flows innerhalb dieses Kontexts. Wird zusätzlich Anwendungserkennung unterstützt, kann die UPF einen weiteren Klassifizierungsmechanismus auf Anwendungsebene einsetzen, statt sich nur auf Adressen und Ports zu stützen.
Was ist der Unterschied zwischen Uplink- und Downlink-PDRs?
Der Vergleich von Uplink- und Downlink-Verkehr ist eine der klarsten Möglichkeiten, die Funktionsweise von PDRs zu verstehen. Beide Richtungen verwenden dieselbe grundlegende Regelstruktur, doch die Pakete gelangen über unterschiedliche Schnittstellen in die UPF und erfordern daher unterschiedliche Erkennungskriterien.
Bei typischem Uplink-Verkehr gelangen Pakete von der Funkzugangsseite zur UPF. Die PDI kann daher Source Interface = Accessverwenden. Zusätzlich kann die Regel einen Local F-TEID zur Identifizierung des GTP-U-Tunnels und eine UE IP Address zur Identifizierung des UE-Verkehrs verwenden. Eine typische Uplink-PDR kann daher Folgendes verlangen:
Source Interface ist Access;
das eingehende GTP-U-Paket stimmt mit dem angegebenen F-TEID einschließlich der relevanten TEID- und Adressinformationen überein;
die UE-IP-Adresse entspricht der mit der Sitzung verknüpften Adresse.
Sind die Bedingungen erfüllt, stimmt die PDR überein. Da über N3 empfangener Verkehr normalerweise in GTP-U gekapselt ist, kann Outer Header Removal die UPF anweisen, die äußeren GTP-U/UDP/IP-Header zu entfernen, bevor das Paket entsprechend der zugehörigen FAR verarbeitet wird.
Die Downlink-Erkennung beginnt in der entgegengesetzten Richtung. Pakete treffen typischerweise aus einem Datennetz bei der UPF ein, sodass die PDI Source Interface = Coreverwenden kann. In diesem Fall können Parameter wie die Network Instance und die UE IP Address verwendet werden, um zu bestimmen, zu welcher PDU Session das Paket gehört. Eine typische Downlink-PDR kann daher Folgendes verlangen:
Source Interface ist Core;
die Network Instance stimmt mit dem erforderlichen logischen Netz überein, etwa „internet“ oder „ims“;
das Paketziel entspricht der mit der Sitzung verknüpften UE-IP-Adresse.
Nach einer Übereinstimmung der Downlink-PDR bestimmt die zugehörige FAR, wie das Paket zur Zugangsseite weitergeleitet werden soll, einschließlich des erforderlichen Tunnel-Weiterleitungsverhaltens. Der Unterschied zwischen Uplink- und Downlink-PDRs spiegelt somit die Richtung wider, aus der Pakete in die UPF gelangen, sowie die jeweils verfügbaren Informationen zu ihrer Identifizierung.
Wie arbeiten PDR, FAR, QER und URR zusammen?
Eine PDR löst das Problem der Paketidentifizierung, stellt aber nicht die gesamte Verarbeitungspolitik der Benutzerebene dar. PFCP trennt Paketerkennung, Weiterleitung, QoS-Durchsetzung und Nutzungsmessung in unterschiedliche Regeltypen. Dadurch kann jede Regel eine klar definierte Funktion erfüllen und dennoch innerhalb derselben PFCP-Sitzung arbeiten.
PDR: Um welchen Verkehr handelt es sich? (Erkennung und Klassifizierung)
FAR: Was soll mit ihm geschehen und wohin soll er gehen? (Weiterleitungsaktion)
QER: Welche QoS-Behandlung soll gelten? (QoS-Durchsetzung)
URR: Wie soll die Nutzung gemessen und gemeldet werden? (Nutzungsbericht)
Betrachten wir ein Uplink-Paket, das mit einer PDR übereinstimmt. Nachdem die UPF bestimmt hat, zu welchem UE und Service-Flow das Paket gehört, kann sie den erforderlichen äußeren GTP-U-Header entfernen, das von der FAR referenzierte Weiterleitungsverhalten anwenden, die passende QER durchsetzen und den Verkehr gemäß der zugehörigen URR erfassen. Das Ergebnis der Paketerkennung liefert damit den Kontext für alle nachfolgenden Schritte.
Aus technischer Sicht sollte eine PDR nicht als isolierte Weiterleitungspolitik betrachtet werden. Sie ist der Einstiegspunkt in den PFCP-Regelsatz der Benutzerebene. Sobald die Beziehung zwischen PDR für die Klassifizierung, PDI für die Abgleichkriterien und FAR/QER/URR für die nachfolgende Verarbeitung klar ist, lassen sich Parameter wie Source Interface, F-TEID, UE IP Address und SDF Filter in realen N4-Signalisierungs- und Paketanalysen wesentlich leichter verstehen.
FAQ
Precedence wird verwendet, wenn die UPF PDRs innerhalb einer PFCP-Sitzung auswertet. Sind die PDI-Bedingungen zweier Regeln jedoch vollständig gegenseitig ausschließend, können beide PDRs nicht auf dasselbe Paket passen; ihre relative Precedence verändert das Endergebnis daher nicht. Besonders wichtig wird die Precedence, wenn sich Regelbedingungen überschneiden und mehr als eine PDR denselben Verkehr treffen könnte.
Ändert sich die als PDI-Abgleichbedingung verwendete UE-Adresse, muss auch die zu dieser Adresse gehörende Regel die aktualisierten Sitzungsinformationen widerspiegeln. Die SMF kann relevante PDR-Informationen über eine PFCP Session Modification aktualisieren, damit die UPF den UE-Verkehr weiterhin korrekt klassifiziert.
Ja. Beim SDF-Filtering müssen nicht alle möglichen Felder den Verkehr auf einen bestimmten Port einschränken. Je nach Regeldefinition können Portbereiche oder weniger restriktive Abgleichbedingungen verwendet werden, um einen größeren Verkehrsbereich abzudecken. Auch Adressmasken können eingesetzt werden, wenn die jeweilige Filterdefinition den Abgleich eines Adressbereichs erfordert.
Kann ein eingehendes Paket keiner anwendbaren PDR zugeordnet werden, besitzt die UPF im betreffenden Kontext keine passende Paketverarbeitungsregel für diesen Verkehr. Die weitere Behandlung hängt von den anwendbaren PFCP-Regeln, der UPF-Implementierung und der Sitzungskonfiguration ab. Bei der Fehlersuche ist eine unerwartete PDR-Nichtübereinstimmung daher ein wichtiger Prüfpunkt, wenn Verkehr die UPF erreicht, aber nicht wie erwartet weitergeleitet wird.
PFCP unterstützt vordefinierte Regeln, die bereits in der UP-Funktion bereitgestellt sind und bei Bedarf aktiviert werden können. Statt in geeigneten Szenarien sämtliche Regelparameter wiederholt bereitzustellen, kann die Steuerungsebene die entsprechende vordefinierte Regel aktivieren. Dadurch lässt sich der erforderliche Signalisierungsumfang reduzieren, wenn dieselben Regelsätze in passenden Sitzungen wiederverwendet werden.
