Ein typisches Fehlerszenario in 5G-Netzen wirkt zunächst unkompliziert: Das UE registriert sich erfolgreich, die PDU Session wird aufgebaut und eine IP-Adresse korrekt zugewiesen, dennoch funktioniert der Webzugriff nicht und selbst einfacher Ping-Verkehr schlägt fehl. Paketmitschnitte können zeigen, dass Verkehr über N3 an der UPF ankommt, aber kein entsprechendes Paket den erwarteten Pfad verlässt. Wenn sich die Fehlersuche nur auf AMF-Signalisierung und das Ergebnis des PDU-Session-Aufbaus konzentriert, lässt sich die tatsächliche Ursache nur schwer eingrenzen.
Eine erfolgreich aufgebaute PDU Session bedeutet nicht automatisch, dass der Weiterleitungspfad der Benutzerebene betriebsbereit ist. Nach Empfang eines Pakets verwendet die UPF zunächst eine PDR zur Identifizierung des Verkehrs und wendet anschließend die zugehörige FAR (Forwarding Action Rule, Weiterleitungsaktionsregel) an, um festzulegen, was als Nächstes geschieht: Paket weiterleiten, verwerfen, puffern oder duplizieren. Die FAR kann außerdem die Zielschnittstelle und die Notwendigkeit eines äußeren GTP-U-Tunnelheaders definieren.
Für die Fehlersuche ist diese Unterscheidung hilfreich: Eine PDR beantwortet die Frage „Zu welcher Sitzung und zu welchem Verkehrsfluss gehört dieses Paket?“, während eine FAR beantwortet „Das Paket ist identifiziert – was soll die UPF jetzt damit tun?“ Wenn die Verfahren der Steuerungsebene normal erscheinen, der Benutzerverkehr aber weiterhin ausfällt, ist die FAR an der N4-Schnittstelle ein wichtiger Prüfpunkt.
Warum garantiert eine erfolgreiche PDU Session keine Konnektivität der Benutzerebene?
Der Abschluss des PDU Session Establishment bestätigt lediglich, dass die erforderlichen Sitzungsressourcen der Steuerungsebene initialisiert wurden. Der tatsächliche Anwendungsverkehr hängt weiterhin vom vollständigen Pfad der Benutzerebene mit gNB, N3, UPF und N6 ab.
Bei einer typischen Internet-PDU-Session läuft der Uplink-Verkehr vom UE zum gNB, wird in einem GTP-U-Tunnel gekapselt und erreicht die UPF über N3. Die UPF muss den entsprechenden äußeren Tunnelheader entfernen, den Verkehr identifizieren und das ursprüngliche Paket in Richtung Datennetz weiterleiten. Im Downlink verläuft der Vorgang umgekehrt: Verkehr kommt über N6 in die UPF, die UPF identifiziert die zugehörige PDU Session, erhält die Tunnelinformationen der gNB-Benutzerebene, fügt den erforderlichen äußeren GTP-U-Header hinzu und sendet das Paket über N3 zum gNB.
Dieses Weiterleitungsverhalten steht nicht allein deshalb zur Verfügung, weil die PDU Session erstellt wurde. Die SMF muss über N4 die geeigneten PFCP-Regeln in der UPF bereitstellen. Die PDR identifiziert passenden Verkehr, während die FAR die nach der Klassifizierung anzuwendende Weiterleitungsaktion definiert. Für eine korrekte Verarbeitung der Benutzerebene werden beide Regeltypen benötigt.
Wenn die gesamte Signalisierung der Steuerungsebene normal aussieht, der Dienst aber weiterhin nicht verfügbar ist, lässt sich das Problem auf zwei Kernfragen reduzieren:
Identifiziert die PDR den aktuellen Verkehr korrekt?
Enthält die zugehörige FAR nach der Paketidentifizierung die richtigen Verarbeitungs- und Weiterleitungsparameter?
Die Konzentration auf die Beziehung zwischen PDR und FAR ist häufig effizienter, als den gesamten PDU-Session-Aufbau wiederholt von Anfang an zu prüfen.
Was weist eine FAR die UPF tatsächlich an zu tun?
Eine FAR ist eine Weiterleitungsregel im PFCP-Rahmen. Sie wird von der SMF über N4 in der UPF bereitgestellt und über die von einer PDR referenzierte FAR ID mit dem Verkehr verknüpft. Sobald ein Paket mit dieser PDR übereinstimmt, führt die UPF das in der referenzierten FAR definierte Verarbeitungsverhalten aus.
Eine FAR kann mehrere Information Elements enthalten. Für die Fehlersuche in der Benutzerebene sind die folgenden Felder besonders wichtig:
| FAR-Parameter | Hauptfunktion |
|---|---|
| FAR ID | Identifiziert eine FAR-Instanz eindeutig, damit eine PDR die richtige Weiterleitungsregel referenzieren kann |
| Apply Action | Definiert die grundlegende Paketaktion, einschließlich Weiterleiten, Verwerfen, Puffern oder Duplizieren |
| Forwarding Parameters | Definiert Ziel, Network Instance, Tunnelkapselung und weitere Parameter, die bei der Weiterleitung verwendet werden |
| Duplicating Parameters | Definiert, wie eine duplizierte Paketkopie weitergeleitet werden soll, wenn Verkehrsdublizierung aktiviert ist |
| BAR ID | Referenziert eine Buffering Action Rule zur Steuerung des Paketpufferungsverhaltens |
In der Praxis werden Apply Action und Forwarding Parameters besonders leicht verwechselt. Apply Action beantwortet „Welche Aktion soll ausgeführt werden?“, während Forwarding Parameters beantwortet „Wenn das Paket weitergeleitet wird, wie und wohin soll es gesendet werden?“
Das FORW-Flag in Apply Action allein beweist nicht, dass der Downlink-Pfad vollständig ist. Destination Interface, Network Instance, die Informationen für Outer Header Creation und die weiteren zugehörigen Weiterleitungsparameter müssen ebenfalls korrekt sein.
Wie bestimmt Apply Action den ersten Verarbeitungsschritt für ein Paket?
Apply Action wird durch eine Reihe von Bit-Flags dargestellt, die der UPF mitteilen, welche grundlegenden Operationen auf passende Pakete anzuwenden sind. Diese Flags sind nicht einfach gegenseitig ausschließende Optionen; ihre Bedeutung muss im Kontext der PFCP-Sitzung und des Dienstszenarios interpretiert werden.
DROP: Das passende Paket verwerfen.
FORW: Das Paket gemäß den anwendbaren Forwarding Parameters weiterleiten.
BUFF: Das Paket puffern, anstatt es sofort weiterzuleiten.
NOCP: Wird in Pufferszenarien verwendet, um die Steuerungsebene zu informieren, wenn Downlink-Daten eintreffen, die gepuffert werden müssen.
DUPL: Eine duplizierte Kopie des Pakets erstellen und diese Kopie gemäß den Duplicating Parameters verarbeiten.
Warum werden BUFF und NOCP benötigt?
Ein typischer Anwendungsfall liegt vor, wenn das UE im Idle-Zustand ist und kein unmittelbarer Downlink-Pfad der Benutzerebene zur Verfügung steht. Downlink-Verkehr kann die UPF bereits erreicht haben, aber noch nicht an das UE ausgeliefert werden. Die UPF kann das Paket puffern und bei Bedarf das zugehörige Benachrichtigungsverhalten der Steuerungsebene nutzen, damit weitere Verfahren wie Paging oder die Wiederherstellung des Benutzerebenenpfads eingeleitet werden.
BUFF zeigt lediglich an, dass Pufferung erforderlich ist. Einzelheiten zur Pufferung sind mit der BAR verknüpft; bei der Fehlersuche sollte daher nicht allein auf das BUFF-Flag vertraut werden.
Warum ist DUPL mehr als nur „das Paket noch einmal weiterleiten“?
DUPL erstellt eine separate Kopie des Pakets. Das Originalpaket folgt weiterhin seinem normalen Verarbeitungspfad, während die duplizierte Kopie unabhängig über die Duplicating Parameters gesteuert wird. Für die Kopie können eine andere Destination Interface, eine andere Konfiguration des äußeren Headers, Transport Level Marking oder Forwarding Policy verwendet werden.
Daher sollte bei gespiegeltem oder dupliziertem Verkehr nicht automatisch angenommen werden, dass er denselben Pfad wie der ursprüngliche Dienstverkehr nimmt. Die Duplizierungsparameter müssen separat geprüft werden.
Wie bestimmen Forwarding Parameters, wohin ein Paket tatsächlich gelangt?
Wenn Apply Action FORW enthält, bestimmen die Forwarding Parameters den tatsächlichen Weiterleitungspfad. Bei der Diagnose von Fehlern der Benutzerebene sind mehrere Felder besonders wichtig.
Destination Interface
Destination Interface definiert die logische Schnittstelle, an die die UPF das Paket nach der Verarbeitung senden soll. In einem typischen Downlink-Szenario wird sie auf Access gesetzt, was bedeutet, dass das Paket zum gNB weitergeleitet werden soll. Uplink-Verkehr wird üblicherweise in Richtung Core weitergeleitet.
Eine falsche Destination Interface kann einen schwer erkennbaren Fehler verursachen: Die PDR passt korrekt, aber das Paket wird an die falsche logische Schnittstelle gesendet, während die Steuerungsebene möglicherweise keinen offensichtlichen Fehler zeigt.
Network Instance
Network Instance identifiziert den logischen Netzkontext, der für die Weiterleitung verwendet wird. Sie ist besonders wichtig in Implementierungen mit mehreren DNNs, Slices oder Datennetzen, in denen der Verkehr getrennt bleiben muss.
Bei der Fehlersuche für N6-Konnektivität oder private Netzdienste reicht es nicht aus, nur die physische Erreichbarkeit zu prüfen. Die Network Instance in der FAR muss ebenfalls mit der entsprechenden UPF-Konfiguration übereinstimmen. Eine Abweichung kann verhindern, dass der Verkehr in den erwarteten Netzkontext geroutet wird.
Outer Header Creation
Outer Header Creation ist einer der Schlüsselparameter für die Downlink-Weiterleitung über N3. Ein Paket, das von N6 in die UPF gelangt, enthält die ursprüngliche UE-Nutzlast. Bevor dieses Paket über N3 zum gNB gesendet werden kann, muss die UPF die erforderliche äußere GTP-U/UDP/IP-Kapselung hinzufügen.
Outer Header Creation liefert die dafür benötigten Informationen, einschließlich der Adresse der gNB-Benutzerebene, der TEID des N3-Tunnels und des Typs des äußeren Headers.
Viele Fälle, in denen Downlink-Verkehr die UPF erreicht, aber kein entsprechendes Paket auf N3 erscheint, lassen sich auf fehlende oder falsche Informationen in diesem Teil der FAR zurückführen, etwa eine falsche TEID oder gNB-Adresse.
Weitere Forwarding Parameters
Forwarding Parameters können außerdem Redirect Information, Transport Level Marking, Forwarding Policy, Header Enrichment, Linked Traffic Endpoint ID, Proxying, Destination Interface Type und weitere optionale Informationen enthalten.
Transport Level Marking kann verwendet werden, um die erforderliche DSCP-Markierung auf weitergeleitete Pakete anzuwenden. Forwarding Policy kann auf eine lokal in der UPF konfigurierte Weiterleitungsrichtlinie verweisen. Header Enrichment unterstützt zusätzliche Header-Verarbeitung in geeigneten Diensten. Nicht jede FAR enthält alle diese Information Elements; der tatsächliche Inhalt hängt von der PFCP-Signalisierung und den Dienstanforderungen ab.
Warum kann eine Downlink-FAR nach dem Sitzungsaufbau aktualisiert werden?
Während des anfänglichen PDU Session Establishment kann die SMF die ersten PDRs und FARs in der UPF erstellen. Zu diesem Zeitpunkt hat der gNB die Zuweisung der Downlink-N3-Ressourcen der Benutzerebene möglicherweise noch nicht abgeschlossen. Daher können die endgültige Tunnel-TEID und die Adresse der gNB-Benutzerebene der SMF noch nicht zur Verfügung stehen.
Sobald der gNB diese Ressourcen zugewiesen hat und die entsprechenden N3-Benutzerebeneninformationen für die SMF verfügbar sind, kann die SMF eine PFCP Session Modification senden, um die vorhandene FAR in der UPF mit den erforderlichen Downlink-Tunnelparametern zu aktualisieren.
Die aktualisierte Downlink-FAR kann anschließend folgende wichtige Weiterleitungsinformationen enthalten:
Destination Interface = Access, was die Weiterleitung in Richtung Zugangsseite angibt;
die anwendbare Network Instance;
Outer Header Creation = GTP-U/UDP/IPv4 oder einen anderen anwendbaren Typ des äußeren Headers;
die IP-Adresse der gNB-N3-Benutzerebene und die zugewiesene Tunnel-TEID.
Aus diesem Grund sollte die Fehlersuche nicht nach der Prüfung des PFCP Session Establishment Request enden. Die anfängliche FAR kann nur die grundlegende Weiterleitungsaktion enthalten, während die zum Aufbau des tatsächlichen N3-Downlink-Tunnels benötigten Informationen später über PFCP Session Modification hinzugefügt werden können.
Wird diese spätere Aktualisierung bei der Analyse ignoriert, kann ein normaler stufenweiser Regelbereitstellungsprozess leicht mit einer fehlenden oder unvollständigen FAR-Konfiguration verwechselt werden.
Wie sendet eine FAR Downlink-Verkehr zurück in den N3-Tunnel?
Wenn man den vollständigen Pfad eines Downlink-Pakets verfolgt, lässt sich die Rolle der FAR leichter verstehen.
Ein Paket von einem externen Server erreicht die UPF über N6. Die UPF verwendet eine PDR zur Identifizierung des Verkehrs und ordnet ihn der richtigen PDU Session zu. Anschließend liest sie die von dieser PDR referenzierte FAR.
Wenn Apply Action FORW enthält, wertet die UPF die Forwarding Parameters aus. Destination Interface = Access bedeutet, dass das Paket in Richtung Funkzugang gesendet werden soll. Outer Header Creation enthält die gNB-Tunneladresse und die TEID, die zur Erstellung des äußeren GTP-U-Headers erforderlich sind. Danach kapselt die UPF das ursprüngliche Paket und sendet es über N3 an den gNB.
Der vollständige Pfad lässt sich wie folgt zusammenfassen:
Downlink-Paket kommt auf N6 an → PDR erkennt UE-Verkehr → FAR wendet FORW an → UPF erhält die gNB-N3-Tunnelparameter → UPF erstellt den äußeren GTP-U-Header → Paket wird über N3 zum gNB übertragen.
Dies verdeutlicht auch den Unterschied zwischen FAR und GTP-U. GTP-U ist das Tunnelprotokoll, das die Benutzerdaten transportiert, während die FAR die Entscheidungsregel der UPF ist, die steuert ob ein äußerer Tunnelheader erstellt werden soll, welche Tunnelinformationen zu verwenden sind und welche logische Schnittstelle das Paket erhalten soll.
Eine falsche TEID in einem N3-Paketmitschnitt ist daher nur das sichtbare Symptom. Die Untersuchung sollte zur Steuerungsebene zurückverfolgt werden: Hat der gNB die richtigen Benutzerebeneninformationen zugewiesen? Hat die SMF sie korrekt erhalten? Wurden sie anschließend über die N4-Aktualisierung in die richtige FAR geschrieben?
Wie kann FAR zur Fehlersuche bei einer aufgebauten PDU Session ohne Datenkonnektivität verwendet werden?
Wenn die UE-Registrierung normal ist und die PDU Session aufgebaut wurde, der Dienst aber weiterhin nicht funktioniert, kann die Fehlersuche der tatsächlichen Paketverarbeitungsreihenfolge der UPF folgen, anstatt den gesamten Registrierungsablauf von Beginn an erneut durchzugehen.
Eine praktische Reihenfolge für die FAR-Fehlersuche lautet:
Bestätigen, dass das Paket die UPF erreicht. Wenn auf N3 oder N6 kein Paket ankommt, liegt das Problem vor der FAR und sollte zunächst am UE, gNB oder Transportpfad untersucht werden.
Bestätigen, dass die PDR mit dem Paket übereinstimmt. Eine FAR hat keinen Verkehr zu verarbeiten, solange das Paket nicht zuerst von der zugehörigen PDR identifiziert wurde.
Die von der PDR referenzierte FAR ID prüfen. Sicherstellen, dass ein korrekt erkanntes Paket nicht mit der falschen Weiterleitungsregel verknüpft ist.
Apply Action prüfen. Feststellen, ob FORW, DROP, BUFF oder eine Kombination der anwendbaren Flags konfiguriert ist.
Destination Interface und Network Instance prüfen. Bestätigen, dass das Paket in die richtige logische Richtung und den richtigen Netzkontext gesendet wird.
Outer Header Creation prüfen. Für N3-Downlink-Verkehr die gNB-Adresse, TEID und den Typ des äußeren Headers prüfen.
PFCP Session Modification-Nachrichten prüfen. Nicht nur die anfängliche Create FAR betrachten. Sicherstellen, dass die gNB-Tunnelinformationen anschließend in der UPF aktualisiert wurden.
N3- und N6-Paketmitschnitte abgleichen. Das von den PFCP-Regeln erwartete Verhalten mit den von der UPF tatsächlich übertragenen Paketen vergleichen.
Der Hauptvorteil dieses Ansatzes besteht darin, dass Regeln der Steuerungsebene und Paketmitschnitte der Benutzerebene einander verifizieren können. Die PFCP-Signalisierung zeigt, wie die UPF das Paket weiterleiten sollte , während N3- und N6-Mitschnitte zeigen, was die UPF tatsächlich getan hat.
Wenn diese beiden Sichtweisen nicht übereinstimmen, lässt sich der Fehlerbereich meist auf drei Bereiche eingrenzen: fehlerhafte Bereitstellung von N4-Regeln, fehlerhafte Regelausführung in der UPF oder ein Problem im Transportpfad der Benutzerebene. Das ist deutlich effizienter, als ohne klare Richtung das gesamte 5G Core zu durchsuchen.
FAQ
Was ist der wichtigste Unterschied zwischen FAR und PDR?
Eine PDR erkennt und klassifiziert Pakete und beantwortet Fragen wie, zu welcher Sitzung und welchem Verkehrsfluss ein Paket gehört. Eine FAR definiert, was nach dieser Übereinstimmung geschieht, einschließlich der Behandlung des Pakets und seines Weiterleitungsziels. Eine PDR referenziert die entsprechende FAR über die FAR ID.
Warum kann die Weiterleitung trotz FORW in Apply Action fehlschlagen?
FORW zeigt nur an, dass eine Weiterleitung durchgeführt werden soll. Der Erfolg hängt weiterhin von den zugehörigen Forwarding Parameters ab. Wenn Destination Interface, Network Instance oder die Informationen für Outer Header Creation falsch sind, kann das Paket das erwartete Ziel trotzdem nicht erreichen. Eine falsche N3-TEID oder gNB-Benutzerebenenadresse ist ein typisches Beispiel.
Warum fehlen in der ersten FAR des PFCP Session Establishment manchmal vollständige N3-Tunnelinformationen?
Der Aufbau einer PDU Session ist ein mehrstufiger Vorgang. Bei der Erstellung der anfänglichen PFCP-Sitzung hat der gNB möglicherweise noch nicht die endgültigen Downlink-N3-Ressourcen der Benutzerebene zugewiesen. Sobald gNB-Tunneladresse und TEID verfügbar sind, kann die SMF die FAR über PFCP Session Modification aktualisieren. Die Fehlersuche muss daher neben der anfänglichen Aufbau-Nachricht auch die nachfolgenden N4-Austausche verfolgen.
Wie hängen Outer Header Creation und PDR Outer Header Removal zusammen?
Sie gelten für entgegengesetzte Richtungen der Tunnelverarbeitung. Bei Uplink-Verkehr, der von N3 ankommt, entfernt Outer Header Removal den entsprechenden äußeren GTP-U-Header. Bei Downlink-Verkehr, der die UPF in Richtung N3 verlässt, liefert Outer Header Creation in der FAR die Informationen zum Erstellen des neuen äußeren GTP-U-Headers. Zusammen unterstützen sie beide Richtungen der Kapselung und Entkapselung des Benutzerebenentunnels.
Wenn die TEID auf N3 falsch ist, sollte sich die Fehlersuche nur auf GTP-U konzentrieren?
Nein. Ein N3-Paketmitschnitt zeigt lediglich, dass die verwendete TEID falsch ist. Die Tunnelinformationen stammen vom gNB, werden von der SMF verarbeitet und anschließend über N4 in der FAR bereitgestellt. Zur Ermittlung der tatsächlichen Ursache sollte die Fehlersuche daher die Ressourcenzuweisung im gNB, die von der SMF empfangenen Informationen und die FAR-Aktualisierung im PFCP Session Modification verfolgen.
