Wechselt ein UE über einen 3GPP-Zugang in CM-IDLE, kann eine bestehende PDU Session erhalten bleiben, während ihre Nutzerebenenverbindung deaktiviert wird. Downlink-Pakete können weiterhin über N6 aus dem Datennetz bei der UPF eintreffen, obwohl der zugangsseitige N3-Tunnel für die sofortige Zustellung nicht verfügbar ist. Durch Pufferung lässt sich ein Teil dieses Verkehrs aufbewahren, während die Steuerungsebene versucht, die Zustellung wiederherzustellen.
Auf N4 steuert die SMF die UPF über PFCP. Eine Buffering Action Rule (BAR) liefert Pufferanweisungen für zugeordnete Forwarding Action Rules (FARs). Die Unterscheidung ist wesentlich: Die FAR wählt die Pufferung über Apply Action aus; BAR klassifiziert selbst keine Pakete und löst kein Paging aus. CM-IDLE garantiert auch nicht, dass jedes Paket gepuffert wird oder jede Benachrichtigung zu Paging führt.
PDR, FAR und BAR haben unterschiedliche Aufgaben
Eine Packet Detection Rule (PDR) erkennt den betreffenden Verkehr und verweist auf eine FAR. FORW fordert die Weiterleitung anhand der geltenden Forwarding Parameters an. BUFF fordert Pufferung an. NOCP fordert die Benachrichtigung der Steuerungsebene über das erste gepufferte Downlink-Paket an; es ist eine Benachrichtigungsaktion und kein Parameter zur Speicherzuweisung.
Im üblichen 5GC-Fall mit BUFF/NOCP wird das erste Downlink-Paket jedes QoS-Flows für eine bestimmte FAR gemeldet. Nachfolgende Pakete desselben QoS-Flows erfordern nicht jeweils einen weiteren Bericht. Pakete eines anderen QoS-Flows oder mit Zuordnung zu einer anderen FAR können weitere Berichte erzeugen. Erweiterte Pufferung kann dieses Meldeverhalten verändern.
Eine FAR kann über BAR ID auf BAR verweisen. Eine BAR kann mehreren zugeordneten FARs dienen, auch mit gemeinsamem Puffer für die PFCP Session. Nach TS 29.244 V18.7.0 darf pro PFCP Session höchstens eine BAR angelegt werden. Das Anlegen allein beweist nicht, dass der Downlink-Verkehr diese BAR nutzt: Prüfen Sie die PDR-FAR-Zuordnung und die BAR ID der FAR.
Die zugrunde liegenden Klassifizierungs- und Weiterleitungsschritte erläutern die ergänzenden Anleitungen zur PDR-Paketerkennung auf N4 und zu FAR-Weiterleitung und Tunnelparametern.
Was geschieht beim Eintreffen von Downlink-Daten in CM-IDLE?
Betrachten wir ein registriertes UE mit bestehender PDU Session. Bei aktiver Nutzerebenenverbindung leitet die UPF Downlink-Pakete an die gNB weiter. Wird diese Verbindung deaktiviert, aktualisiert die SMF die betreffenden N4-Regeln und Zugangstunnelinformationen. Für Pufferung in der UPF kann die betroffene FAR BUFF und NOCP statt sofortiger Weiterleitung anfordern. Dies ist eine Entscheidung der Sitzungssteuerung und keine autonome Reaktion von BAR auf einen Funkzustandswechsel.
Downlink-Daten erreichen die UPF. Die passende PDR und die zugeordnete FAR bestimmen ihre Behandlung.
Bei der Anweisung zum Puffern und Benachrichtigen puffert die UPF die Daten und sendet einen PFCP Session Report Request mit einem Downlink Data Report. Dieser identifiziert die betreffenden PDRs; die SMF kann den QoS-Flow aus dem PDR-Kontext oder aus Downlink Data Service Information bestimmen.
Die SMF bestätigt den Bericht mit einer PFCP Session Report Response und kontaktiert gegebenenfalls die AMF über Namf_Communication_N1N2MessageTransfer. Die AMF kann Paging und das Service Request-Verfahren einleiten, um die Nutzerebenenverbindung wiederherzustellen.
Sobald der zugangsseitige Tunnel eingerichtet ist, aktualisiert die SMF die UPF mit der Weiterleitungsaktion und den richtigen Tunnelparametern. Gepufferte Pakete können dann gemäß den neuen Anweisungen weitergeleitet werden.
TS 23.502 bezeichnet den Stage-2-Austausch als Data Notification und Data Notification Ack. Verwenden Sie in einem N4-Mitschnitt die tatsächlichen PFCP-Nachrichten- und Downlink Data Report-Namen. „DDN“ ist eine praktische Kurzbezeichnung für den gesamten Austausch, macht ihn aber nicht zu einer EPC-Nachricht Downlink Data Notification auf S11.
Dieser Ablauf beschreibt einen häufigen Fall der UPF-Pufferung. TS 23.502 erlaubt bei entsprechender Anweisung auch die Weiterleitung der Daten an die SMF zur Pufferung. Ein UE kann in CM-CONNECTED sein, während einer bestimmten PDU Session eine aktive Nutzerebenenverbindung fehlt; auch RRC_INACTIVE unterscheidet sich von CM-IDLE. Zugangstyp, MICO, erweitertes Idle-Mode-DRX, Paging-Beschränkungen und bekannte Nichterreichbarkeit können Paging verändern oder verhindern. Prüfen Sie den tatsächlichen Sitzungs- und Zugangszustand, bevor Sie eine Erklärung für den Ruhezustand anwenden.
BAR-Felder müssen im Kontext des Verfahrens gelesen werden
Die folgenden Unterscheidungen folgen TS 29.244 V18.7.0, Abschnitten 5.2.4, 7.5.2.6, 7.5.4.11 und 7.5.9.2. BAR ist kein universeller Behälter, in dem bei jedem N4-Austausch alle denkbaren Puffereinstellungen erscheinen müssen.
| Feld | Bedeutung und Bedingungen |
|---|---|
| BAR ID | Identifiziert BAR innerhalb der PFCP Session. Ein FAR-Verweis wählt die dieser BAR zugeordneten Pufferanweisungen aus. |
| Suggested Buffering Packets Count | Ein von UDBC abhängiges Feld für die vorgeschlagene Pufferung von UL/DL-Paketen bis zu neuen Anweisungen der Steuerungsebene. Es beschreibt nicht die physische Speicherkapazität der UPF. Wird es übermittelt, verlangen die zitierten Create/Update BAR-Tabellen das Verwerfen der Pakete, die den Grenzwert überschreiten. |
| DL Buffering Suggested Packet Count | Ein anderes Feld: die vorgeschlagene maximale Anzahl von Downlink-Paketen für die erweiterte Pufferung in der PFCP Session. Es darf nicht mit Suggested Buffering Packets Count verwechselt werden. |
| DL Buffering Duration | Steuert die erweiterte Downlink-Pufferung. Die Übermittlung in PFCP Session Report Response hängt von DLBD-Unterstützung ab; über PFCP Session Modification von DBDM-Unterstützung und den geltenden Bedingungen. Bei der anfänglichen Einrichtung ist es nicht zwingend vorhanden. |
| Downlink Data Notification Delay | Verzögert gegebenenfalls die Benachrichtigung nach Paketeingang. Abschnitt 5.2.4 beschreibt seine Bereitstellung für EPC; allein das Auftreten in einer allgemeinen BAR-Abbildung oder einem dekodierten gruppierten IE macht es nicht zu einer allgemeinen Steuerung der 5GC-Paging-Verzögerung. |
DL Buffering Duration wirkt sich sowohl auf Berichte als auch auf die Aufbewahrung aus. Während der angegebenen erweiterten Pufferdauer werden weitere Meldungen über Downlink-Dateneingänge normalerweise unterdrückt. Bei Unterstützung von Extended DL Buffering Notification Control (EDBNC) und EDBN gleich 1 meldet die UPF stattdessen während dieses Zeitraums das erste gepufferte Paket jedes QoS-Flows für eine bestimmte FAR. NOCP allein beweist daher nicht, dass ein weiterer Bericht fällig ist.
Endet die erweiterte Pufferung, wendet die UPF DL Buffering Duration und DL Buffering Suggested Packet Count nicht weiter an und entfernt diese Parameter aus BAR. Neue Anweisungen der Steuerungsebene entscheiden, ob bereits gepufferte Pakete weitergeleitet oder verworfen werden. Pufferung ist eine vorübergehende Verkehrsbehandlung und kein garantiert verlustfreier Speicher.
Warum ein Mitschnitt nicht jeden Pufferparameter zeigt
Beginnen Sie mit dem vollständigen Verlauf der PFCP Session. BAR kann bei der Einrichtung oder einer früheren Änderung angelegt worden sein, während der untersuchte Austausch nur die FAR aktualisiert. Optionale und fähigkeitsabhängige Felder müssen ebenfalls nicht in jeder Nachricht erscheinen. Ein fehlendes optionales Feld unterscheidet sich von einem nicht auflösbaren Verweis oder einem fehlenden, unter bestimmten Bedingungen vorgeschriebenen Feld.
TS 29.244 erlaubt, Pufferparameter optional zusammen mit BUFF bereitzustellen. Bevor eine BAR in einer PFCP Session Report Response geändert werden kann, muss sie jedoch bereits bereitgestellt und den FARs zugeordnet worden sein, auch wenn sie leer ist. Lokale Ressourcenbegrenzungen der UPF ersetzen weder eine BAR ID-Zuordnung noch ein vom geltenden Verfahren vorgeschriebenes Feld.
Abschnitt 5.2.4.3 beschreibt eine engere Implementierungsoption: Unterstützt die UPF konfigurierte erweiterte Pufferung für APN/DNN und/oder S-NSSAI und gelten die weiteren genannten Bedingungen, kann die Steuerungsebene den Timer selbst verwalten, statt ihn an die UPF zu übermitteln, während NOCP für Benachrichtigungen zusätzlicher QoS-Flows aktiviert bleibt. Dies ist keine pauschale Ausnahme, durch die jeder BAR-Parameter durch lokale Konfiguration ersetzt werden darf.
Ermitteln Sie bei der Fehlersuche die ausgehandelten UP Function Features, frühere BAR-Bereitstellungen, aktuelle Regelzuordnungen und relevante lokale Ressourceneinstellungen. So lässt sich ein normal ausgelassener optionaler Parameter von nicht unterstützten Funktionen, einem unvollständigen Mitschnitt oder einem tatsächlichen Bereitstellungsfehler unterscheiden.
Aktion, Pufferung, Benachrichtigung und Wiederherstellung untersuchen
Eine verspätete erste Nachricht nach Inaktivität, erfolgreiches Paging mit fehlenden Anfangspaketen oder wachsende UPF-Puffer können unterschiedliche Ursachen haben. Verfolgen Sie das Paket und seinen Steuerungsebenenzustand in vier Schritten.
1. Aktion und passende Regel bestätigen
Prüfen Sie, ob Downlink-Pakete tatsächlich die erwartete UPF erreichen und zur richtigen PDR passen. Folgen Sie deren FAR ID, prüfen Sie Apply Action und das akzeptierte Ergebnis von PFCP Session Modification. Verwendet die FAR noch veraltete Zugangstunnelinformationen zur Weiterleitung, untersuchen Sie zunächst Regel- und Tunnelaktualisierungen, bevor Sie Pufferparameter ändern.
2. Wirksame Pufferanweisungen ermitteln
Lösen Sie BAR ID auf und prüfen Sie das letzte Create BAR oder Update BAR im passenden Nachrichtenkontext. Unterscheiden Sie die beiden Paketanzahlfelder und prüfen Sie die Funktionsunterstützung. Vergleichen Sie konfigurierte Grenzen mit tatsächlich gepufferten und verworfenen Paketen; eine vorgeschlagene Anzahl reserviert keinen physischen Speicher und garantiert nicht, dass jedes Paket bis zur Wiederverbindung erhalten bleibt.
3. Bericht und Verarbeitung prüfen
Suchen Sie PFCP Session Report Request, Downlink Data Report, PDR ID und die zugehörige Antwort. Prüfen Sie den Meldeumfang je QoS-Flow, Benachrichtigungsunterdrückung, erweiterte Pufferung und etwaige Fehlerursachen. Wird ein Bericht akzeptiert, ohne dass Paging folgt, prüfen Sie den SMF-AMF-Austausch und die Erreichbarkeitsbedingungen des UE, bevor Sie BAR als fehlerhaft einstufen.
4. Zustellung nach der Wiederherstellung prüfen
Prüfen Sie nach erfolgreichem Service Request, ob die SMF FORW sowie die aktuelle zugangsseitige Adresse und TEID wiederherstellt. Vergleichen Sie N6-Eingänge, N3-Ausgänge und Pufferzähler. Auch ein erreichbares UE kann Daten verpassen, wenn die FAR in BUFF bleibt, Tunnelinformationen falsch sind, die Pufferdauer abgelaufen ist oder Pakete bereits verworfen wurden.
Häufige Fragen
Benötigt BUFF BAR zur Klassifizierung von Paketen?
Nein. Die PDR klassifiziert den Verkehr, und die FAR fordert BUFF an. BAR liefert nach Bereitstellung und Zuordnung spezifische Pufferanweisungen; sie ist kein weiterer Paketklassifizierer.
Beweist ein fehlendes Suggested Buffering Packets Count eine Fehlkonfiguration?
Nein. Dieses Feld hängt von UDBC-Unterstützung ab und unterscheidet sich vom Paketanzahlfeld für erweiterte Downlink-Pufferung. Prüfen Sie Nachrichtenkontext, ausgehandelte Funktionen und bestehenden BAR-Zustand, bevor Sie die Auslassung bewerten.
Löst jeder Downlink Data Report Paging aus?
Nein. SMF und AMF wenden Erreichbarkeits-, Zugangs- und Richtlinienbedingungen an. Ein Bericht kann zur Reaktivierung der Nutzerebene, erweiterter Pufferung oder Fehlerbehandlung führen; Paging ist nur ein möglicher Teil des Verfahrens.
Warum können trotz erfolgreicher Wiederverbindung Pakete verloren gehen?
Der Puffer kann vor der Wiederherstellung eine Grenze erreicht haben oder abgelaufen sein. Alternativ kann die FAR- oder Tunnelaktualisierung unvollständig sein. Eine erfolgreiche Wiederverbindung allein bestätigt weder die aufbewahrten Pakete noch die wiederaufgenommene N3-Weiterleitung.
Referenzen
3GPP TS 29.244 V18.7.0: Abschnitte 5.2.3–5.2.4, 7.5.2.6, 7.5.4.11, 7.5.8–7.5.9 und 8.2.28–8.2.30, 8.2.100 behandeln FAR/BAR-Verarbeitung, Berichte und Puffer-Informationselemente.
3GPP TS 23.502 V18.9.0: Abschnitt 4.2.3.3 beschreibt Network Triggered Service Request, Datenbenachrichtigung, Erreichbarkeitsausnahmen und erweiterte Pufferung.
