Technische Fragen und Antworten: Wie steuert die BAR auf der N4-Schnittstelle die Pufferung von Downlink-Paketen und die Datenbenachrichtigung, wenn sich ein UE im CM-IDLE befindet?
Wenn ein UE in den CM-IDLE-Zustand wechselt, verschwindet seine PDU-Sitzung nicht. Der zuvor für die Downlink-Weiterleitung genutzte N3-User-Plane-Pfad ist jedoch möglicherweise nicht mehr aktiv. Wenn in diesem Moment neue Daten aus einem externen Netzwerk eintreffen, können die Pakete den UPF zwar noch erreichen, aber sie können nicht unmittelbar über N3 an das gNB weitergeleitet werden, wie es im CM-CONNECTED-Zustand der Fall wäre. Der UPF muss daher feststellen, ob die Pakete gepuffert werden sollen, wie viele Pakete zurückgehalten werden können, wie lange sie gepuffert bleiben können und wann die Steuerebene darüber informiert werden muss, dass Downlink-Daten eingetroffen sind.
Innerhalb des PFCP-Regelwerks auf der N4-Schnittstelle liefert die BAR (Buffering Action Rule) die Regeln für dieses Pufferverhalten. Die BAR entscheidet jedoch nicht eigenständig, ob eine Pufferung erfolgen soll. Die Pufferaktion wird durch die Apply Action in der FAR ausgelöst, während die BAR festlegt, wie diese Pufferung durchgeführt werden soll. Diese Unterscheidung ist grundlegend für das Verständnis des Zusammenhangs zwischen FAR und BAR.
Die BAR legt fest, wie der UPF Pakete puffert
Wenn der UPF ein Paket empfängt, verwendet er zunächst eine PDR, um den Datenverkehr zu identifizieren, und folgt dann der von dieser PDR referenzierten FAR, um die nächste Aktion zu bestimmen. Wenn die FAR eine normale Weiterleitung verlangt, leitet der UPF das Paket gemäß den Forwarding Parameters weiter. Wenn die Apply Action der FAR BUFF enthält, wird das Paket nicht sofort zur Zielschnittstelle gesendet, sondern durchläuft den Pufferprozess.
An dieser Stelle wird die BAR relevant. Die FAR kann auf eine BAR verweisen, die dem UPF mitteilt, wie die betroffenen Pakete gepuffert werden sollen. Die Beziehung lässt sich wie folgt zusammenfassen:
PDR identifiziert das Paket → FAR wählt BUFF/NOCP → BAR definiert das Pufferverhalten.
Ein häufiges Missverständnis besteht darin, BUFF und BAR so zu behandeln, als wären sie dasselbe. Sie sind es nicht. BUFF beantwortet die Frage: „Soll dieses Paket jetzt gepuffert werden?“ Die BAR beantwortet die Frage: „Sobald die Pufferung ausgewählt wurde, unter welchen Bedingungen soll das Paket gepuffert werden?“ Nur auf BUFF in der FAR zu schauen, ohne die zugehörige BAR oder die lokale Pufferkonfiguration des UPF zu prüfen, liefert nur einen Teil des Bildes vom Verhalten der User Plane.
NOCP wird ebenfalls häufig mit diesem Szenario in Verbindung gebracht. Wenn der UPF Downlink-Pakete puffert, kann NOCP verlangen, dass der UPF die Steuerebene darüber informiert, dass Downlink-Daten eingetroffen sind, damit der SMF die nachfolgenden Steuerebenen-Prozeduren einleiten kann. Pufferung und Benachrichtigung erfolgen daher als zwei koordinierte Aufgaben: Die User Plane hält die Pakete vorübergehend zurück, während das Ereignis an die Steuerebene gemeldet wird.
Das typischste BAR-Szenario tritt auf, nachdem das UE in den CM-IDLE-Zustand wechselt
Die Rolle der BAR ist am einfachsten zu verstehen, wenn ein UE von CM-CONNECTED zu CM-IDLE übergeht. Angenommen, das UE hat die Registrierung und den Aufbau der PDU-Sitzung bereits abgeschlossen. Solange es verbunden ist, steht der N3-User-Plane-Pfad zur Verfügung und der UPF kann Downlink-Pakete direkt an das gNB weiterleiten.
Nach einer Phase der Inaktivität kann die Zugangsseite die Verbindung freigeben, und das UE wechselt in den CM-IDLE-Zustand. Die PDU-Sitzung bleibt bestehen, aber der zuvor aktive N3-User-Plane-Weiterleitungspfad ist nicht mehr unmittelbar verfügbar. Externe Server sind sich dieses Zustandswechsels nicht unbedingt bewusst, sodass neue Downlink-IP-Pakete den UPF weiterhin über N6 erreichen können.
Daraus ergibt sich das Kernproblem: Der UPF hat die Daten empfangen, verfügt aber derzeit über keinen nutzbaren N3-Pfad, über den er sie an das UE zustellen könnte.
In dieser Phase aktualisiert der SMF die User-Plane-Regeln über N4, sodass die betreffende FAR von der sofortigen Weiterleitung auf das Pufferverhalten umschaltet. In einem typischen Fall werden BUFF und NOCP in der Apply Action aktiviert, während FORW nicht mehr als aktuelle Downlink-Aktion verwendet wird. Wenn neue Downlink-Pakete eintreffen, hält der UPF sie gemäß der anwendbaren Pufferrichtlinie zurück und meldet das Eintreffen der Downlink-Daten an den SMF.
Nach Erhalt der Benachrichtigung kann der SMF sich mit dem AMF abstimmen, um die erforderlichen Prozeduren einzuleiten, damit das UE wieder erreichbar wird, einschließlich Paging, sofern zutreffend. Sobald das UE in einen Zustand zurückkehrt, in dem User-Plane-Verkehr übertragen werden kann und der N3-Pfad wiederhergestellt ist, aktualisiert der SMF die UPF-Regeln erneut, sodass die Downlink-Behandlung von der Pufferung zurück zur Weiterleitung wechselt. Gepufferte Pakete können dann in Richtung UE weitergeleitet werden.
Die BAR ist daher nicht einfach eine statische Speicherzuweisungsregel. Ihr eigentlicher Zweck besteht darin, der User Plane zu helfen, den vorübergehenden Zeitraum zu überbrücken, in dem Downlink-Pakete bereits eingetroffen sind, die sofortige Weiterleitung aber noch nicht möglich ist.
Wichtige BAR-Parameter definieren die Grenzen der Pufferung
Die Pufferung kann nicht unbegrenzt fortgesetzt werden. Wenn der UPF unbegrenzte Downlink-Daten für ein nicht erreichbares UE zurückhalten dürfte, könnte der Speicher der User Plane unnötig verbraucht werden. Die BAR legt daher Grenzen für das Pufferverhalten fest. Abhängig von der PFCP-Prozedur und den UPF-Fähigkeiten können dazu BAR-ID, Paketanzahl-Limits, Pufferdauer und Parameter für die Benachrichtigungsverzögerung gehören.
BAR-ID
Die BAR-ID identifiziert die Pufferregel innerhalb der PFCP-Sitzung eindeutig und ermöglicht es der zugehörigen FAR, auf die richtige BAR zu verweisen. Bei der Fehlerbehebung beweist das bloße Vorhandensein einer Create BAR noch nicht, dass die Regel den analysierten Verkehr beeinflusst. Die entsprechende FAR sollte ebenfalls geprüft werden, um zu bestätigen, auf welche BAR-ID sie tatsächlich verweist.
Vorgeschlagene Anzahl zu puffernder Pakete
Die vorgeschlagene Anzahl zu puffernder Pakete gibt an, wie viele Pakete der UPF für den betreffenden Verkehr puffern soll. Sobald das vorgeschlagene Limit überschritten wird, können weitere Pakete verworfen werden. Dieser Parameter steuert die Kapazitätsgrenze der Pufferung und nicht die Pufferzeit.
Sein Vorhandensein hängt auch von der Feature-Unterstützung des UPF ab. Wenn das Feld in einem PFCP-Trace nicht sichtbar ist, beweist das allein noch nicht, dass die Puffersteuerung fehlt. Bei der Analyse sollte auch berücksichtigt werden, ob der UPF die entsprechende Fähigkeit unterstützt und ob stattdessen lokale Pufferparameter verwendet werden.
DL-Pufferdauer
Die DL-Pufferdauer definiert den Zeitraum, in dem Downlink-Pakete im Rahmen der anwendbaren Prozedur weiterhin im UPF gepuffert werden dürfen. Sie spiegelt ein wichtiges Konstruktionsprinzip wider: Die Pufferung ist als temporärer Mechanismus gedacht, während die Zustellung auf der User Plane wiederhergestellt wird, und nicht als dauerhafte Paketspeicherung.
Wenn das UE über einen längeren Zeitraum nicht erreichbar bleibt, benötigt der Pufferprozess eine definierte Abbruchbedingung; andernfalls könnten User-Plane-Ressourcen unbegrenzt belegt bleiben.
Verzögerung der Downlink-Datenbenachrichtigung
Bei unterstützten Prozeduren und Fähigkeitskombinationen kann die Verzögerung der Downlink-Datenbenachrichtigung steuern, wie lange der UPF nach dem Empfang des ersten Downlink-Pakets wartet, bevor er die Steuerebene benachrichtigt. Dieser Parameter beeinflusst wann die Benachrichtigung gesendet wird, und nicht, ob das Paket gepuffert werden soll.
Sein Verhalten sollte daher im Kontext der jeweiligen PFCP-Prozedur, der Netzimplementierung und der UPF-Fähigkeiten interpretiert werden und nicht allein aus dem Parameternamen abgeleitet werden.
Warum fehlen in PFCP-Traces manchmal vollständige BAR-Parameter?
Dies ist einer der am leichtesten falsch zu interpretierenden Punkte bei der Analyse der BAR. Die Anzahl der zu puffernden Pakete, die Pufferdauer und andere Pufferparameter müssen nicht immer dynamisch über N4 bereitgestellt werden. Betreiber oder Geräteanbieter können Pufferrichtlinien auch lokal im UPF konfigurieren.
Bei dieser Implementierung muss der SMF möglicherweise nur die FAR-Aktion dynamisch ändern. Beispielsweise kann der SMF nach dem Wechsel des UE in den CM-IDLE-Zustand die PFCP Session Modification verwenden, um die betreffende FAR auf BUFF/NOCP zu aktualisieren. Sobald der UPF die Pufferaktion erkennt, kann er lokal konfigurierte Paketanzahl- und Dauerlimits anwenden.
Die folgende Beobachtung in einem Trace ist daher nicht automatisch ungewöhnlich:
Die FAR fordert BUFF an, aber die PFCP-Nachrichten enthalten nicht die vollständigen BAR-Parameter, die der Ingenieur erwartet.
Mindestens zwei zusätzliche Fragen sollten geprüft werden: ob der UPF lokal konfigurierte Pufferwerte verwendet und ob der UPF die dynamische Bereitstellung der relevanten BAR-Parameter unterstützt. Andernfalls könnte ein Implementierungsunterschied mit einer fehlenden Regel vom SMF verwechselt werden.
Die lokale Konfiguration kann auch praktische Vorteile haben. Sie kann einen Teil der N4-Signalisierung reduzieren und Unterschiede in den Fähigkeiten zwischen UPF-Implementierungen ausgleichen. Der Nachteil besteht darin, dass ein Teil des Pufferverhaltens nicht mehr vollständig in einem einzigen PFCP-Trace sichtbar ist, sodass die Fehlerbehebung bei mehreren Anbietern sowohl die Signalisierungsanalyse als auch die Prüfung der lokalen UPF-Konfiguration erfordern kann.
Wie ist der PFCP-Ablauf zu verstehen, wenn Downlink-Daten im CM-IDLE eintreffen?
Die BAR ist leichter zu verstehen, wenn sie in die vollständige Prozedur zurückversetzt wird, anstatt sie als isoliertes Informationselement zu analysieren.
Während sich das UE im CM-CONNECTED-Zustand befindet, ist der N3-Pfad verfügbar, und der UPF leitet Downlink-Pakete gemäß der normalen FAR weiter. Nach einer Phase der Inaktivität wird die zugangsseitige Verbindung freigegeben. Sobald der SMF erfährt, dass sich der Verbindungszustand der User Plane geändert hat, verwendet er die PFCP Session Modification, um die betreffenden UPF-Regeln zu aktualisieren.
Der wichtige Punkt ist, dass die PDU-Sitzung nicht gelöscht wurde. Stattdessen ist der aktuelle Downlink-User-Plane-Pfad vorübergehend nicht für die sofortige Zustellung verfügbar. Die betreffende FAR kann daher in das Pufferverhalten wechseln, indem BUFF und die erforderliche Benachrichtigungsaktion an die Steuerebene aktiviert werden, während die BAR oder die lokale UPF-Konfiguration die detaillierten Pufferbedingungen liefert.
Wenn ein Internetserver oder eine Anwendung anschließend neue Downlink-Daten sendet, erreichen die Pakete zuerst den UPF. Der UPF verwendet die PDR, um den Verkehr zu identifizieren, und wendet dann die zugehörige FAR an. Da die aktuelle Aktion nicht mehr FORW ist, werden die Pakete gepuffert. Gleichzeitig meldet der UPF das Eintreffen der Downlink-Daten über den PFCP-Reporting-Mechanismus an den SMF.
Der SMF koordiniert sich dann mit den AMF-seitigen Prozeduren, damit das UE wieder erreichbar wird und der User-Plane-Pfad wiederhergestellt werden kann. Sobald die N3-Weiterleitung wieder verfügbar ist, wird die FAR auf N4 erneut für die normale Weiterleitung aktualisiert, und der UPF kann die Zustellung des Downlink-Verkehrs an das UE fortsetzen.
Die Gesamtlogik lässt sich wie folgt zusammenfassen:
UE wechselt in CM-IDLE → N3 ist vorübergehend nicht verfügbar → SMF aktualisiert FAR/BAR → Downlink-Daten erreichen den UPF → UPF puffert und meldet → Steuerebene stellt die Erreichbarkeit des UE wieder her → N3 wird wiederhergestellt → FAR kehrt zur Weiterleitung zurück.
Die BAR steuert somit das User-Plane-Verhalten während des Zeitraums, in dem die Daten bereits eingetroffen sind, der Zustellpfad aber noch nicht zurückgekehrt ist.
Die BAR-Fehlerbehebung sollte vier Schritten folgen: Aktion, Pufferung, Benachrichtigung und Wiederherstellung
BAR-bezogene Probleme treten selten als expliziter „BAR-Fehler“ auf. Häufiger ist das Symptom, dass sich der erste Downlink-Verkehr, nachdem das UE in einen Ruhezustand gewechselt ist, ungewöhnlich verhält. Eine Anwendung kann im aktiven Zustand normal funktionieren, aber nach einer Phase der Inaktivität kommt die nächste Nachricht mit spürbarer Verzögerung an. In einem anderen Fall kann das UE erfolgreich gepagt und wieder verbunden werden, aber die ersten Downlink-Pakete sind bereits verloren gegangen.
Diese Probleme können in vier Phasen analysiert werden.
Schritt 1: Bestätigen, dass die FAR tatsächlich in den Puffermodus gewechselt ist
Beginnen Sie mit der FAR, auf die die betreffende Downlink-PDR verweist, und bestätigen Sie, dass die erwartete PFCP Session Modification nach dem Wechsel des UE in den CM-IDLE-Zustand stattgefunden hat. Prüfen Sie, ob die Apply Action vom normalen FORW-Verhalten zu den für das Szenario erwarteten BUFF- und Benachrichtigungsaktionen gewechselt hat.
Wenn die FAR weiterhin versucht, Pakete über einen User-Plane-Pfad weiterzuleiten, der nicht mehr nutzbar ist, handelt es sich nicht in erster Linie um ein BAR-Problem.
Schritt 2: Feststellen, welche Pufferregeln der UPF anwendet
Überprüfen Sie die von der FAR referenzierte BAR-ID und untersuchen Sie dann die entsprechenden Create-BAR- oder Update-BAR-Parameter. Wenn der PFCP-Trace die vollständigen Pufferparameter nicht enthält, fahren Sie mit der Prüfung der lokalen Pufferkonfiguration des UPF und der unterstützten Fähigkeiten fort.
Wenn das Paketanzahl-Limit zu klein ist, könnten einige der ersten Downlink-Pakete verworfen werden, bevor das UE wieder erreichbar wird. Wenn das beobachtete Pufferverhalten erheblich von den Erwartungen abweicht, sollte auch die BAR-Zuordnung selbst überprüft werden.
Schritt 3: Bestätigen, dass der UPF das Eintreffen der Downlink-Daten gemeldet hat
Das Puffern von Paketen allein stellt die Kommunikation mit dem UE nicht wieder her. Wenn die Steuerebene nicht weiß, dass neue Downlink-Daten eingetroffen sind, wird die nachfolgende Paging- oder User-Plane-Wiederherstellungsprozedur nicht eingeleitet. Der Trace sollte daher auf den entsprechenden PFCP Session Report und die korrekte Verarbeitung durch den SMF geprüft werden.
Wenn Pakete bereits im UPF gepuffert werden, aber keine weitere Steuerebenen-Prozedur folgt, sollte die Fehlerbehebung von den BAR-Parametern zum UPF-zu-SMF-Meldepfad und den nachfolgenden SMF-Prozeduren übergehen.
Schritt 4: Bestätigen, dass die Weiterleitung nach der Wiederherstellung der User Plane wieder aufgenommen wird
Nachdem das UE wieder erreichbar ist, überprüfen Sie, ob der SMF die N4-Regeln korrekt aktualisiert, sodass die Downlink-FAR von der Pufferung zurück zur normalen Weiterleitung wechselt und die erforderlichen N3-Weiterleitungsparameter wiederhergestellt werden.
Wenn das Paging erfolgreich ist und das UE zurückgekehrt ist, die FAR jedoch im BUFF-Modus bleibt, kann das System in einen Zustand geraten, in dem das UE erreichbar ist, während Pakete weiterhin im UPF verbleiben. Die BAR-Fehlerbehebung sollte daher fortgesetzt werden, bis der User-Plane-Weiterleitungspfad vollständig wiederhergestellt ist.
Der zentrale Wert der BAR
Innerhalb des PFCP-Regelwerks nimmt die BAR nicht an jedem normal weitergeleiteten Paket in derselben Weise teil wie PDR und FAR. Ihre Bedeutung wird in einer spezifischen, aber kritischen Situation am deutlichsten: Die Sitzung besteht weiterhin, aber der aktuelle User-Plane-Pfad kann die neu eingetroffenen Downlink-Daten nicht unmittelbar zustellen.
Die FAR ändert die Paketverarbeitungsaktion von FORW zu BUFF, die BAR definiert die Puffergrenzen, der UPF hält die Pakete vorübergehend zurück und meldet ihr Eintreffen, und Steuerebenen-Funktionen wie SMF und AMF koordinieren die Wiederherstellung der UE-Erreichbarkeit. Zusammen überbrücken diese Mechanismen den Übergang von der vorübergehenden Nichtverfügbarkeit der Zustellung zurück zu einem aktiven User-Plane-Pfad.
Die BAR sollte daher nicht nur als „Buffering Action Rule = eine Paketpufferregel“ verstanden werden. Eine nützlichere Interpretation ist: Die BAR teilt dem UPF mit, wie er mit Downlink-Paketen umgehen soll, die bereits eingetroffen sind, während der User-Plane-Zustellpfad vorübergehend nicht verfügbar ist. Sobald die BAR zusammen mit CM-IDLE, FAR BUFF/NOCP, PFCP Session Report und den nachfolgenden Paging- und User-Plane-Wiederherstellungsprozeduren betrachtet wird, wird ihre Rolle auf der N4-Schnittstelle viel klarer.
FAQ
Was ist der Unterschied zwischen BAR und BUFF in der FAR?
BUFF ist eine Apply Action in der FAR, die anzeigt, dass übereinstimmende Pakete gepuffert statt sofort weitergeleitet werden sollen. Die BAR definiert, wie diese Pufferung durchgeführt werden soll, z. B. Paketanzahl-Limits, Pufferdauer oder andere anwendbare Bedingungen. Einfach ausgedrückt entscheidet die FAR, dass eine Pufferung erforderlich ist, während die BAR definiert, wie die Pufferung durchgeführt wird.
Kann die BAR unabhängig von einer FAR arbeiten?
Die BAR sollte nicht als unabhängige Paketabgleichsregel behandelt werden. Das Paket wird zunächst von einer PDR abgeglichen, die auf die betreffende FAR verweist. Wenn diese FAR eine Pufferung verlangt und auf die anwendbare BAR verweist, werden die BAR-Parameter verwendet, um zu steuern, wie diese Pakete gepuffert werden.
Warum werden Downlink-Pakete nicht einfach verworfen, wenn das UE in den CM-IDLE-Zustand wechselt?
CM-IDLE bedeutet nicht, dass die PDU-Sitzung gelöscht wurde. Externe Anwendungen können weiterhin Daten senden, während der User-Plane-Zustellpfad nur vorübergehend nicht verfügbar ist. Die kurzfristige Pufferung ermöglicht es, einen Teil dieses Downlink-Verkehrs zurückzuhalten, während die Steuerebene die UE-Erreichbarkeit wiederherstellt, und trägt so dazu bei, Unterbrechungen der Anwendungskontinuität zu reduzieren.
Bedeutet das Fehlen der vorgeschlagenen Anzahl zu puffernder Pakete, dass die BAR falsch konfiguriert ist?
Nicht unbedingt. Ob dieser Parameter erscheint, hängt von der PFCP-Prozedur, der UPF-Fähigkeit und der Implementierung ab. Paketanzahl-Limits und anderes Pufferverhalten können auch lokal im UPF konfiguriert sein; daher sollten die Fähigkeitsunterstützung, die BAR-Zuordnung und die geräteseitige Pufferkonfiguration geprüft werden.
Warum empfängt das UE immer noch keine Daten, obwohl der UPF die Downlink-Pakete gepuffert hat?
Die Pufferung ist nur ein Teil der Prozedur. Der UPF muss außerdem das Eintreffen der Downlink-Daten an den SMF melden, die Steuerebene muss die erforderlichen Prozeduren zur Wiederherstellung der UE-Erreichbarkeit einleiten, und der SMF muss die FAR und die N3-Weiterleitungsparameter aktualisieren, sobald der User-Plane-Pfad wieder verfügbar ist. Ein Fehler in einer dieser Phasen kann dazu führen, dass Pakete gepuffert bleiben oder schließlich verworfen werden.
