Eine PDU-Sitzung kann bereits längere Zeit normal laufen: Das UE besitzt eine IP-Adresse, der N3-Nutzerebenenpfad ist aktiv und der Anwendungsverkehr fließt wie erwartet. Dann ändern sich die Dienstbedingungen. Die zuvor genehmigte Datenrate muss möglicherweise reduziert werden, ein QoS Flow benötigt einen anderen 5QI oder das Netz begrenzt die maximale Sitzungsrate auf 10 Mbps.
In dieser Situation muss das 5GC nicht die gesamte PDU-Sitzung abbauen und neu aufbauen. Die bestehende Sitzung kann aktiv bleiben, während nur die betroffenen QoS-Regeln, QoS-Flow-Parameter oder Durchsetzungsrichtlinien der Nutzerebene aktualisiert werden. Genau dafür dient PDU Session Modification.
Der Unterschied zu PDU Session Establishment ist eindeutig. Die Einrichtung erzeugt eine Sitzung, die zuvor nicht existierte; die Änderung passt eine bereits aktive Sitzung an. Im Mittelpunkt stehen daher nicht mehr die Auswahl des SMF oder die anfängliche Einrichtung des UPF, sondern was die Änderung ausgelöst hat, wie der SMF die neue Richtlinie erhält, was UE und gNB aktualisieren müssen und ob die neue QoS-Richtlinie im UPF tatsächlich durchgesetzt wird.
Umfang der PDU-Sitzungsänderung
PDU Session Modification hat eine wichtige Voraussetzung: Die betroffene PDU-Sitzung muss bereits bestehen. UE, SMF, PCF und der zugehörige RAN-Kontext sind bereits mit dieser Sitzung verknüpft, und die Nutzerebene ist normalerweise betriebsbereit.
Ziel des Änderungsverfahrens ist es, Parameter zu ändern, während die Sitzung aktiv bleibt. QoS ist eines der häufigsten Beispiele. Ein bestehender QoS Flow kann einen anderen 5QI, MBR, MFBR oder einen anderen genehmigten Parameter benötigen. Eine Richtlinienänderung kann außerdem erfordern, die bereits im UPF durchgesetzte Ratensteuerung zu aktualisieren.
Eine QoS-Änderung darf nicht als bloße Änderung eines einzelnen NAS-Feldes verstanden werden. Eine einzige QoS-Aktualisierung kann drei unterschiedliche Teile des Systems betreffen:
UE-Seite: Das UE muss die neue QoS Rule oder neue QoS-Flow-Parameter erhalten;
RAN-Seite: Der gNB muss möglicherweise die zugehörige PDU Session Resource oder QoS-Flow-Ressourcen ändern;
UPF-Seite: Wenn sich die Durchsetzung in der Nutzerebene ändert, müssen die betreffenden PFCP-Regeln über N4 aktualisiert werden.
PDU Session Modification lässt sich daher am besten als Online-Neukonfiguration einer aktiven Sitzung verstehen. Die Sitzungsidentität bleibt unverändert, und die Änderung wird auf die bestehende PDU Session ID und die zugehörigen QoS Flows angewendet.
Dabei ist eine wichtige Grenze zu beachten. PDU Session Modification kann einen bestehenden QoS Flow aktualisieren und in geeigneten Dienstszenarien auch einen neuen QoS Flow innerhalb derselben PDU-Sitzung einrichten. Beispielsweise kann eine anwendungsgetriebene Richtlinie für einen VoNR-Anruf einen zusätzlichen Flow mit bestimmten QoS-Eigenschaften erfordern. Hier liegt der Schwerpunkt jedoch auf dem Ändern der Parameter eines bestehenden QoS Flow und nicht auf dem Erstellen eines neuen.
Wichtige Auslöser für Sitzungsänderungen
Ein wesentlicher Unterschied zu PDU Session Establishment besteht darin, dass das UE nicht der einzige mögliche Auslöser ist. Eine aktive PDU-Sitzung kann aufgrund einer UE-Anforderung, einer Netzrichtlinienänderung, aktualisierter Teilnehmerdaten oder veränderter Funkbedingungen neu konfiguriert werden.
Häufige Auslöser lassen sich in fünf Kategorien einteilen:
Vom UE ausgelöst: Das UE sendet einen PDU Session Modification Request, um eine QoS- oder andere Sitzungsänderung anzufordern;
Vom PCF ausgelöst: Die Richtliniensteuerung ändert sich, etwa wenn ein Nutzungsschwellenwert erreicht wird und das Netz die genehmigte Rate reduziert oder wenn eine Anwendungsrichtlinie eine andere QoS verlangt;
Vom UDM ausgelöst: Die Sitzungsmanagement-Abonnementdaten ändern sich, beispielsweise durch eine aktualisierte Teilnehmerstufe oder ein geändertes gebuchtes QoS-Profil;
Vom SMF ausgelöst: Der SMF entscheidet anhand lokaler Richtlinien, der Netzkonfiguration oder des bestehenden Sitzungszustands, die Sitzung neu zu konfigurieren;
RAN-bezogener Auslöser: Der gNB meldet Funk- oder Ressourcenbedingungen, woraufhin der SMF entscheidet, dass Sitzungsparameter geändert werden müssen.
Diese Auslöser laufen letztlich beim SMF zusammen, weil der SMF den Steuerungskontext der PDU-Sitzung besitzt und neue Dienst- oder Richtlinienanforderungen in Parameter übersetzt, die von UE, RAN und UPF umgesetzt werden können.
Bei der Fehlersuche für PDU Session Modification sollte daher nicht einfach beim PDU Session Modification Command begonnen und von dort weitergegangen werden. Sinnvoller ist es, das früheste Steuerungsereignis zu identifizieren, das die Änderung ausgelöst hat. Ist das erste Ereignis eine UE Modification Request, wurde der Ablauf vom UE initiiert. Überträgt der PCF eine neue Richtlinie über eine Notification URI an den SMF, ist die Änderung richtliniengesteuert. Erscheint zuerst eine Aktualisierung der UDM-Teilnehmerdaten, sollte die Analyse dem Pfad der Abonnementänderung folgen.
Vom UE initiierte PDU-Sitzungsänderung
Ein vom UE initiierter Ablauf lässt sich am einfachsten als Fall verstehen, in dem eine Anwendung eine andere QoS benötigt.
Angenommen, das UE verwendet aktuell die PDU Session ID 5 und einer seiner QoS Flows nutzt noch die ursprüngliche Konfiguration. Eine Anwendung erzeugt eine neue Dienstanforderung, woraufhin das UE andere QoS-Parameter über einen PDU Session Modification Request anfordert.
Die NAS-Nachricht gelangt zunächst über den gNB zum AMF. Anschließend aktualisiert der AMF den bestehenden SM Context beim SMF. Auf der servicebasierten Schnittstelle verwendet der AMF:
POST /nsmf-pdusession/v1/sm-contexts/{smContextRef}/modify
Dies unterscheidet sich von Create SM Context. Der SM Context besteht bereits; das Netz aktualisiert jetzt einen vorhandenen Sitzungskontext.
Die UE-Anforderung kann Requested QoS Rules, Requested QoS Flow Descriptions und zugehörige Packet Filters enthalten. Nach Eingang der Anforderung muss der SMF entscheiden, ob das Netz die gewünschte Änderung genehmigen kann. Nutzt die Sitzung dynamische Richtliniensteuerung, sendet der SMF die Dienstanforderung außerdem zur Autorisierung an den PCF.
Fordert das UE beispielsweise für einen bestimmten Flow 5QI 8 an, kann der SMF den Dienst PCF SM Policy Control aufrufen, um die bestehende Policy Association zu ändern. Der PCF bewertet Teilnehmerpolitik, Dienstregeln und aktuelle Netzbedingungen und liefert anschließend die tatsächlich genehmigten QoS-Parameter zurück.
Eine Unterscheidung ist wichtig: Die vom UE angeforderte QoS ist nicht zwangsläufig die QoS, die am Ende tatsächlich durchgesetzt wird. Das UE formuliert den Dienstbedarf, während die endgültigen Parameter der Genehmigung durch SMF und PCF unterliegen.
Sobald die genehmigten Parameter feststehen, erzeugt der SMF zwei Arten von Informationen:
N1 SM: PDU Session Modification Command mit den neuen QoS-bezogenen Parametern in Richtung UE;
N2 SM: Informationen für das PDU Session Resource Modify-Verfahren, mit denen der gNB angewiesen wird, die zugehörigen QoS-Flow-Ressourcen zu ändern.
Der AMF übermittelt die N2-Informationen per NGAP an den gNB und leitet den in N1 enthaltenen PDU Session Modification Command an das UE weiter.
Nachdem der gNB die betreffenden Ressourcen angepasst hat, sendet er einen PDU Session Resource Modify Response zurück. Sobald das UE die neuen Parameter akzeptiert, sendet es über NAS PDU Session Modification Complete.
Erst nachdem der SMF die entsprechenden Ausführungsergebnisse erhalten hat, kann er bestätigen, dass die neuen Sitzungsparameter von der Richtlinienfreigabe tatsächlich in die Umsetzung auf Zugangs- und UE-Seite übergegangen sind.
Vom PCF ausgelöste netzseitige QoS-Änderung
Die netzseitige Änderung folgt einer anderen Logik. Das UE hat keine neue QoS angefordert; die Änderung beginnt in der Richtliniensteuerung.
Betrachten wir ein Beispiel mit einem Nutzungsschwellenwert. Ein Teilnehmer besitzt bereits eine aktive PDU-Sitzung und überträgt kontinuierlich Daten. Der PCF verlangt, dass die Sitzung Nutzungsinformationen meldet oder überwacht. Sobald die kumulierte Nutzung einen konfigurierten Schwellenwert erreicht, kann die Richtlinie die maximale Rate der Sitzung oder des zugehörigen Flow auf 10 Mbps reduzieren.
Der PCF benachrichtigt daraufhin den SMF über die Notification URI, die beim Aufbau der SM Policy Association registriert wurde. Die Benachrichtigung enthält die neue SM Policy Decision, beispielsweise den aktualisierten MBR und den zugehörigen Policy Control Trigger.
Aus Sicht des SMF wird keine neue Sitzung erstellt. Vielmehr wird eine weiterhin gültige und aktive PDU-Sitzung geändert.
Muss die neue Rate im UPF durchgesetzt werden, sendet der SMF über N4 einen PFCP Session Modification Request. Der zugehörige QER kann beispielsweise durch Setzen des MBR auf 10 Mbps aktualisiert werden. Erst wenn der UPF die Änderung akzeptiert, wird die neue Ratenbegrenzung in der Nutzerebene wirksam.
Zwei unterschiedliche Verwendungen des Begriffs „Modification“ dürfen nicht verwechselt werden:
PDU Session Modification: das gesamte 5GS-Verfahren zur Änderung einer aktiven PDU-Sitzung;
PFCP Session Modification: das konkrete N4-Steuerungsverfahren, mit dem der SMF Nutzerebenenregeln im UPF aktualisiert.
Beide arbeiten auf unterschiedlichen Ebenen. Eine PDU Session Modification kann eine PFCP Session Modification enthalten, aber das Auftreten einer PFCP-Änderungsnachricht bedeutet nicht, dass die vollständige PDU-Sitzungsänderung abgeschlossen ist.
Nachdem der UPF den neuen QER durchsetzt, muss der SMF möglicherweise weiterhin RAN und UE aktualisieren. N1/N2-Informationen werden über den AMF übertragen, der gNB erhält einen PDU Session Resource Modify Request und das UE einen PDU Session Modification Command.
Sobald der gNB die Funkressourcen aktualisiert hat und das UE die neuen QoS-Parameter akzeptiert, melden beide Seiten ihre Ausführungsergebnisse zurück. Der SMF kann den erfolgreichen Abschluss anschließend an den PCF melden, damit das Richtliniensystem weiß, dass die QoS-Entscheidung tatsächlich durchgesetzt und nicht nur als Richtlinienentscheidung gespeichert wurde.
Koordinierte Änderung über N1, N2 und N4
Einer der verwirrendsten Aspekte von PDU Session Modification ist, dass dieselbe QoS-Änderung gleichzeitig Änderungsverfahren in NAS, NGAP und PFCP auslösen kann.
Die Logik wird klarer, wenn die drei Pfade getrennt betrachtet werden.
N1 aktualisiert UE-Sitzungsparameter
N1 SM transportiert Session-Management-Informationen zwischen UE und SMF. Nachdem das Netz die Änderung der Sitzung beschlossen hat, sendet der SMF über den AMF einen PDU Session Modification Command an das UE.
Das UE aktualisiert seine lokalen PDU-Sitzungsparameter und bestätigt die Annahme mit PDU Session Modification Complete.
N2 aktualisiert RAN-Ressourcen
Müssen Funkressourcen eines QoS Flow geändert werden, erzeugt der SMF die entsprechenden N2-SM-Informationen und übermittelt sie über den AMF an den gNB. Der gNB ändert die betreffenden QoS-Flow-Ressourcen mit dem PDU Session Resource Modify-Verfahren und liefert das Ergebnis zurück, einschließlich erfolgreich geänderter QFIs, sofern zutreffend.
N4 aktualisiert UPF-Durchsetzungsregeln
Wirkt sich die Änderung auf die Weiterleitung in der Nutzerebene oder die QoS-Durchsetzung aus, aktualisiert der SMF die betreffenden UPF-Regeln über PFCP Session Modification.
Eine Änderung der Ratenbegrenzung kann eine Aktualisierung eines QER erfordern. Andere Richtlinienänderungen können einen PDR, FAR oder eine andere Nutzerebenenregel betreffen. Welche Regeln geändert werden, hängt vom Dienst und von der Steuerungsrichtlinie ab; eine PDU Session Modification schreibt nicht zwangsläufig jede PFCP-Regel neu.
Eine vollständige QoS-Änderung lässt sich daher wie folgt zusammenfassen:
Richtlinie / UE-Anforderung
→ SMF berechnet Sitzungsparameter neu
→ N4 aktualisiert die Durchsetzung im UPF
→ N2 aktualisiert gNB-Ressourcen
→ N1 aktualisiert UE-Parameter
→ jede Seite bestätigt das Ergebnis
Die genaue Nachrichtenreihenfolge kann je nach Auslöser und geänderten Parametern variieren. Bei der Fehlersuche ist es nicht sinnvoll, für jedes Szenario eine identische Nachrichtenfolge zu verlangen. Besser ist es zu prüfen, ob jeder Ausführungspunkt, der geändert werden muss, die neuen Parameter tatsächlich erhält und anwendet.
Abschluss der Änderung und Signalisierungsfehleranalyse
Probleme bei PDU Session Modification unterscheiden sich in einem Punkt von Fehlern beim Sitzungsaufbau: Die PDU-Sitzung kann aktiv bleiben und der Benutzer weiterhin Daten übertragen, obwohl die resultierende QoS nicht der vorgesehenen Richtlinie entspricht.
Beispielsweise kann die Richtlinie eine Reduzierung auf 10 Mbps verlangen und der PCF bereits die neue Richtlinienentscheidung ausgegeben haben, während ein realer Durchsatztest weiterhin eine deutlich höhere Rate zeigt. Dass die PDU-Sitzung fortbesteht, beweist nicht den Erfolg der Änderung. Die Analyse muss feststellen, an welcher Stelle die neuen Parameter nicht mehr angewendet wurden.
Für die praktische Fehlersuche eignen sich folgende Prüfpunkte:
Auslöser identifizieren: feststellen, ob das erste Ereignis eine UE Modification Request, eine PCF Notification, eine UDM-Datenänderung oder ein Ereignis auf SMF-/RAN-Seite war;
SMF-Entscheidung prüfen: bestätigen, dass der SMF die Anforderung akzeptiert hat und der PCF die erwartete Richtlinienentscheidung zurückgegeben hat;
N4-Durchsetzung prüfen: muss der UPF neue QoS durchsetzen, prüfen, ob PFCP Session Modification erfolgreich war und ob sich die betreffenden QER-Parameter tatsächlich geändert haben;
N2-Ausführung prüfen: bestätigen, dass der gNB den PDU Session Resource Modify Request erhalten und die erfolgreich geänderten QoS Flows zurückgemeldet hat;
N1-Bestätigung prüfen: bestätigen, dass das UE den PDU Session Modification Command erhalten und PDU Session Modification Complete zurückgesendet hat;
Dienstergebnis validieren: bestätigen, dass der reale Verkehr nun der aktualisierten Rate, QoS oder Dienstrichtlinie folgt.
Hat der PCF bereits 10 Mbps genehmigt, enthält der QER im UPF aber weiterhin den alten MBR, sollte sich die Analyse auf den Pfad SMF-N4 konzentrieren. Erzwingt der UPF bereits die neue Rate, während der QoS Flow im gNB noch alte Parameter verwendet, muss das N2 Resource Modify-Verfahren genauer untersucht werden. Hat die Netzseite alle notwendigen Änderungen abgeschlossen, das UE sendet jedoch nie Modification Complete zurück, sollte auf NAS-Seite geprüft werden, ob die neuen QoS-Regeln akzeptiert wurden.
Auch ein Nachrichtenname kann zu Verwirrung führen. Manche Ablaufdiagramme verwenden die Bezeichnung „PDU Session Modification Command Ack“ für den Bestätigungsschritt des UE. In der 5GSM-NAS-Signalisierung lautet die tatsächliche Nachricht des UE nach Annahme des PDU Session Modification Command jedoch PDU Session Modification Complete. Bei der Paketanalyse sollte daher der tatsächliche NAS Message Type verwendet werden.
Diese schichtweise Fehlersuche ist deutlich wirksamer als eine erneute Analyse ab Registration Request. Die PDU-Sitzung besteht bereits. Das Problem ist, dass eine aktive Sitzung nicht konsistent gemäß der neuen Richtlinie aktualisiert wurde. Der Fehlerbereich sollte daher auf den aktuellen SM Context, die Richtlinie, den QoS Flow und die Durchsetzung in der Nutzerebene fokussiert bleiben.
Häufig gestellte Fragen
Weist PDU Session Modification dem UE eine neue IP-Adresse zu?
Eine normale QoS-Änderung aktualisiert eine bestehende PDU-Sitzung und ihre QoS Flows, anstatt die gesamte Sitzung neu aufzubauen. Ob sich andere Sitzungsattribute ändern, hängt vom konkreten Szenario ab; eine Änderung, die auf Parameter wie 5QI oder MBR beschränkt ist, sollte jedoch nicht als erneutes PDU Session Establishment behandelt werden.
Wird PDU Session Modification immer vom UE initiiert?
Nein. Das UE kann über einen PDU Session Modification Request eine Änderung anfordern, aber auch eine PCF-Richtlinienänderung, eine Aktualisierung der UDM-Teilnehmerdaten, eine lokale SMF-Entscheidung oder ein RAN-bezogenes Ereignis können eine netzseitige Änderung auslösen. Der SMF koordiniert üblicherweise die erforderlichen Aktualisierungen zwischen UE, RAN und UPF.
Was ist der Unterschied zwischen PDU Session Modification und PFCP Session Modification?
PDU Session Modification ist das gesamte 5GS-Verfahren zur Änderung einer aktiven Sitzung und kann UE, RAN, SMF, PCF und Nutzerebene umfassen. PFCP Session Modification findet speziell über die N4-Schnittstelle zwischen SMF und UPF statt und ändert konkrete Nutzerebenenregeln im UPF. Letzteres kann Teil des ersteren sein, die beiden Verfahren sind jedoch nicht gleichbedeutend.
Wenn der QER bereits aktualisiert wurde, warum müssen gNB und UE trotzdem geändert werden?
Der QER steuert die QoS-Durchsetzung im UPF, ein QoS Flow wird jedoch nicht allein im UPF definiert. Das UE kann eine neue QoS Rule oder Flow-Beschreibung benötigen, während das RAN die zugehörigen Funkressourcen anpassen muss. Einige QoS-Änderungen verlangen daher Konsistenz zwischen N1, N2 und N4. Nur den UPF zu aktualisieren bedeutet nicht, dass das vollständige PDU Session Modification-Verfahren abgeschlossen ist.
Kann PDU Session Modification einen neuen QoS Flow hinzufügen?
Ja. PDU Session Modification kann die Parameter eines bestehenden QoS Flow aktualisieren und in geeigneten Szenarien auch einen neuen QoS Flow innerhalb derselben PDU-Sitzung einrichten. Beispielsweise kann ein anwendungsgetriebener VoNR-Dienst einen zusätzlichen QoS Flow mit einem bestimmten 5QI erfordern. Dieses Szenario hat einen anderen Dienstkontext als die einfache Aktualisierung eines bestehenden Flow und sollte getrennt analysiert werden.
