Bei der Fehlersuche im Feld ist einer der häufigsten Irrtümer, aus einem RRC Release zu schließen, dass die UE-Deregistrierung bereits abgeschlossen ist. Die Funkverbindung kann tatsächlich beendet sein und das UE kann aufgehört haben, Daten zu senden; der Registrierungskontext im AMF, die PDU-Sitzung im SMF, die N4-Sitzung im UPF, Policy-Zuordnungen im PCF und Registrierungsdaten im UDM verschwinden jedoch nicht im selben Moment, nur weil „das Signal weg ist“. In einem Signalisierungs-Trace ist entscheidend, welche NF-übergreifende Bereinigungskette auf den Deregistration Request folgt: wie der AMF den Umfang der Deregistrierung bestimmt, wie der SMF den UPF zum Entfernen von User-Plane-Ressourcen anweist und in welchem Umfang PCF- und UDM-Zuordnungen freigegeben werden müssen.
Vom UE initiierte Deregistrierung ist das kontrollierte Verfahren, mit dem ein bereits registriertes UE aus dem 5GS abgemeldet wird. Es beginnt mit einem NAS Deregistration Request und kann die Freigabe von PDU-Sitzungen, das Löschen von N4-Sitzungen und User-Plane-Tunneln im UPF, das Beenden von SM-Policy- und AM-Policy-Zuordnungen, das Entfernen zugehöriger Registrierungszustände im UDM und schließlich die Freigabe der Signalisierungsverbindung zwischen UE und Zugangsnetz umfassen. Normale Deregistrierung und Abschalten können im ersten Teil des Verfahrens ähnlich aussehen, enden jedoch unterschiedlich: Der eine Ablauf wartet auf Deregistration Accept, der andere bleibt nicht nur für eine Bestätigung online. Dieser Unterschied wird bei Trace-Analysen leicht übersehen.
Warum ist Deregistrierung mehr als nur das Markieren des UE als offline?
Nachdem ein UE die Initial Registration abgeschlossen und eine PDU-Sitzung aufgebaut hat, speichert das 5GC nicht nur ein einzelnes „Online“-Kennzeichen. Der AMF verwaltet Registrierungs- und Mobilitätskontext, der SMF den PDU-Sitzungskontext, der UPF die N4-Sitzung samt User-Plane-Weiterleitungsressourcen wie FARs, QERs und URRs, der UDM die Registrierungsbeziehungen von AMF und SMF, und der PCF kann AM-, UE- oder SM-Policy-Zuordnungen halten.
Wenn das UE einfach aus dem Netz verschwindet, werden diese Ressourcen nicht automatisch exakt zum selben Zeitpunkt entfernt. Das ist besonders wichtig, wenn noch eine oder mehrere PDU-Sitzungen bestehen. Das Netz muss wissen, welche Sitzungen freigegeben, welche User-Plane-Regeln gelöscht und welche Abonnements oder Policy-Zuordnungen nicht länger benötigt werden.
Die vom UE initiierte Deregistrierung führt daher einen geordneten Abbau des Registrierungszustands und seiner zugehörigen Ressourcenaus:
Das UE zeigt an, dass die aktuelle 5GS-Registrierung beendet werden soll
→ Der AMF bestimmt den Umfang der Deregistrierung
→ Zugehörige PDU-Sitzungen werden freigegeben
→ Der SMF weist den UPF an, User-Plane-Ressourcen zu entfernen
→ Sitzungs- und Policy-Zuordnungen werden gelöscht
→ Der Registrierungszustand wird entfernt
→ Die Signalisierungsverbindung auf der Zugangsseite wird freigegeben
Deshalb darf die Deregistrierung nicht mit RRC Release oder einer normalen N2-Verbindungsfreigabe verwechselt werden. Eine RAN-Verbindungsfreigabe bedeutet nur, dass die aktuelle Zugangssignalisierungsverbindung beendet wurde. Die Deregistrierung arbeitet auf einer höheren Ebene und entfernt die 5GS-Registrierungsbeziehung zusammen mit dem dazugehörigen Sitzungs- und Policy-Zustand. Zeigt ein Trace lediglich RRC Release, kann die Schlussfolgerung, das UE sei bereits deregistriert, leicht „Freigabe der Zugangsverbindung“ und „Entfernung der Registrierung“ verwechseln.
Wie legt der Deregistration Request fest, auf welche Weise und über welchen Zugang das UE das Netz verlässt?
Wenn das UE das 5GS aktiv verlässt, sendet es an den AMF einen NAS Deregistration Request. Bei der Signalisierungsanalyse sollten zuerst nicht die späteren PFCP-Nachrichten geprüft werden, sondern der im Request enthaltene Deregistration type und Access Type.
Der Deregistration type teilt dem Netz zunächst mit, ob es sich um einen Ausschaltfall handelt. Aus technischer Sicht tritt die vom UE initiierte Deregistrierung typischerweise in zwei Situationen auf: normale Deregistrierung, bei der das UE das Netz geordnet verlässt, und Ausschalten, bei dem das UE anzeigt, dass es gleich abgeschaltet wird oder in einen entsprechenden Abschaltzustand wechselt.
Access Type beantwortet eine andere Frage: Welcher Zugang wird tatsächlich deregistriert? Das UE kann sich nur vom 3GPP-Zugang, nur vom Non-3GPP-Zugang oder – wenn beide Zugangstypen im selben PLMN vom gleichen AMF bedient werden – gegebenenfalls von beiden abmelden. „UE-Deregistrierung“ bedeutet daher nicht immer, dass sämtliche Zugangszustände dieses UE gleichzeitig entfernt werden.
Der Deregistration Request enthält außerdem UE-Identitätsinformationen. Wenn ein gültiges 5G-GUTI verfügbar ist, kann das UE damit dem AMF helfen, die NAS-Nachricht dem bestehenden UE-Kontext zuzuordnen. Ist kein gültiges 5G-GUTI verfügbar, richtet sich die Identitätsbehandlung nach der 5GS-Identität, die dem UE aktuell zur Verfügung steht. Aus Sicht des AMF ist die korrekte Zuordnung dieser NAS-Nachricht zum vorhandenen UE-Kontext Voraussetzung dafür, die richtigen PDU-Sitzungen und Policy-Zuordnungen freizugeben.
Bei normaler Deregistrierung sendet das UE den Request und wartet auf die Bestätigung des Netzes. Beim Ausschalten soll die Information „ich verlasse das Netz“ möglichst schnell übermittelt und anschließend der Abschaltvorgang fortgesetzt werden; daher unterscheidet sich die Behandlung. Für die normale Deregistrierung kann T3521 den Zeitraum überwachen, in dem das UE auf Deregistration Accept wartet, während ein Ausschaltverfahren nicht auf dieselbe Weise auf die Netzbestätigung wartet.
Warum prüft der AMF zuerst, ob das UE noch eine PDU-Sitzung besitzt?
Nach Empfang des Deregistration Request muss der AMF unter anderem entscheiden, ob auf dem Zielzugang noch aufgebaute PDU-Sitzungen bestehen.
Hat das UE keine relevante PDU-Sitzung, gibt es keine einzelne User-Plane-Sitzung abzubauen, sodass das Verfahren deutlich kürzer sein kann. Sind jedoch noch eine oder mehrere PDU-Sitzungen aktiv, kann der AMF nicht einfach seinen eigenen Registrierungskontext löschen, weil SMF und UPF diese Sitzungen weiterhin als vorhanden betrachten würden.
Für jede freizugebende PDU-Sitzung kann der AMF Nsmf_PDUSession_ReleaseSMContext gegenüber dem zuständigen SMF aufrufen. Dies lässt sich als ausdrückliche Anweisung des AMF an die Sitzungsverwaltung verstehen: Das UE verlässt den Zielzugang, daher soll der zugehörige SM Context nicht länger gehalten werden. Erst nach dieser Anweisung kann der SMF die N4-Sitzung löschen, Policy-Zuordnungen beenden und den relevanten Registrierungszustand im UDM bereinigen.
Das verdeutlicht auch den Unterschied zwischen der Deregistrierung und einer eigenständigen Freigabe einer PDU-Sitzung. Die Freigabe einer einzelnen PDU-Sitzung bedeutet nicht, dass das UE das 5GS verlässt; das UE kann weiterhin 5GS Registered bleiben. Wenn das UE dagegen die Deregistrierung einleitet, müssen die zum Zielzugang gehörenden PDU-Sitzungen normalerweise im Rahmen des umfassenderen Deregistrierungsverfahrens bereinigt werden.
Zeigt ein Trace daher einen Deregistration Request, aber anschließend kein Nsmf_PDUSession_ReleaseSMContext, darf dies nicht sofort als fehlende Signalisierung gewertet werden. Zunächst ist zu prüfen, ob das UE auf dem betreffenden Access Type tatsächlich eine PDU-Sitzung aufgebaut hatte. Bestand keine PDU-Sitzung, kann das Fehlen eines N4-Freigabeverfahrens genau dem vorgesehenen Ablauf entsprechen.
Wie bauen SMF und UPF die User Plane tatsächlich ab?
Sobald der AMF die Anforderung zur Freigabe der PDU-Sitzung an den SMF sendet, übernimmt der SMF die Entfernung der zugehörigen User-Plane-Ressourcen. Besteht eine UPF-Sitzung, gibt der SMF sie über die N4-Schnittstelle frei.
In einem typischen Fall sendet der SMF einen PFCP Session Deletion Request. Der UPF verwendet die zugehörige F-SEID oder den N4-Sitzungskontext, um den Weiterleitungszustand des Nutzers zu entfernen, und antwortet mit einer PFCP Session Deletion Response. Anschließend werden die User-Plane-Tunnel, Weiterleitungsregeln und der zugehörige Kontext der PDU-Sitzung entfernt. Die Bereinigung beschränkt sich nicht auf einen einzelnen Tunnel; auch die Regelzustände dieser N4-Sitzung werden gelöscht, einschließlich FARs, QERs, URRs und weiterer zutreffender Regeln.
Die Steuerbeziehung lässt sich so zusammenfassen:
UE → AMF: Ich möchte mich deregistrieren
→ AMF → SMF: Gib den PDU-Sitzungskontext dieses UE frei
→ SMF → UPF: Lösche die N4-Sitzung und die User-Plane-Ressourcen
→ UPF → SMF: Löschung bestätigen
→ SMF → AMF: Freigabe des SM Context abgeschlossen
Verwendet die Sitzung dynamisches PCC, muss der SMF möglicherweise auch die entsprechende SM-Policy-Zuordnung beenden, beispielsweise über Npcf_SMPolicyControl_Delete. Ist die freigegebene Sitzung die letzte PDU-Sitzung, die dieser SMF für den betreffenden DNN und S-NSSAI verwaltet, kann er außerdem das Abonnement für Änderungen der Session Management Subscription Data im UDM beenden und mit Nudm_UECM_Deregistration die Zuordnung zwischen SMF und dem entsprechenden DNN/der PDU-Sitzung aus dem UDM entfernen.
Aus Sicht eines UPF-Traces erreicht die Deregistrierung die User Plane nicht bereits mit dem NAS Deregistration Request selbst, sondern erst mit der anschließenden Freigabe der N4-Sitzung. Erst wenn dieser Schritt abgeschlossen ist, sind die Weiterleitungsressourcen der ursprünglichen PDU-Sitzung tatsächlich aus der User Plane entfernt.
Warum müssen UDM und PCF zusätzlichen Kontext bereinigen?
Nach Abschluss der PDU-Sitzungsfreigabe kann die Nutzerebene bereits entfernt sein, während im 5GC weiterhin Zuordnungen der Steuerungsebene bestehen. Damit die Deregistrierung vollständig abgeschlossen ist, muss das Netz bestimmen, welche Abonnements, Registrierungen und Policy-Beziehungen noch gültig sind und welche entfernt werden müssen.
Auf der Sitzungsverwaltungsseite kann der SMF, wenn er die letzte PDU-Sitzung des Nutzers für den betreffenden DNN und S-NSSAI nicht mehr bedient, sein Abonnement für SM-Data-Updates im UDM beenden und die zugehörige SMF Registration entfernen. Dadurch sendet der UDM keine Session-Management-Updates mehr an einen SMF, der diese Sitzung nicht mehr bedient.
Auf der Zugangs- und Mobilitätspolicy-Seite muss der AMF eine bestehende AM Policy Association zum PCF beenden, wenn das UE über keinen relevanten Access Type mehr registriert ist. Besteht eine UE Policy Association, soll auch diese bei Erfüllung der entsprechenden Bedingungen freigegeben werden. Hält der AMF keine gültige Registrierung für dieses UE mehr, kann außerdem die AMF-Registrierungsbeziehung im UDM über Nudm_UECM_Deregistration entfernt werden müssen.
Hier gibt es eine wichtige Grenze: Es darf nicht angenommen werden, dass jeder PCF- und UDM-Kontext allein wegen eines Deregistrierungsverfahrens verschwinden muss. Bleibt das UE über einen anderen Access Type registriert oder verwaltet derselbe SMF noch andere relevante PDU-Sitzungen für dieses UE, können bestimmte Zuordnungen weiterhin erforderlich sein.
Die Bereinigung bei der Deregistrierung ist daher keine starre Abfolge von DELETE-Requests. Sie folgt einem Grundsatz: Nur Zustände entfernen, die durch diese Deregistrierung ihre betriebliche Bedeutung verloren haben, und Kontext erhalten, der weiterhin von einem anderen Zugang oder einer anderen Sitzung genutzt wird. Dies gehört zu den am leichtesten misszuverstehenden Punkten in Multi-Access- und Multi-PDU-Sitzungs-Deployments.
Warum enden normale Deregistrierung und Ausschalten unterschiedlich?
Normale Deregistrierung und Abschalten können im ersten Teil des Verfahrens beide die Freigabe von PDU-Sitzungen und Kernnetzressourcen auslösen, unterscheiden sich aber darin, wie der Vorgang auf UE-Seite abgeschlossen wird.
Bei einer normalen Deregistrierung wartet das UE nach dem Senden des Deregistration Request auf die Bestätigung des Netzes. Sobald der AMF die erforderliche Verarbeitung abgeschlossen hat, sendet er ein Deregistration Acceptzurück und informiert das UE ausdrücklich darüber, dass das Netz die Deregistrierung akzeptiert hat. NAS-Mechanismen wie T3521 können diesen Wartezeitraum überwachen. Läuft T3521 ab, führt das UE die im Protokoll definierten Wiederholungs- oder Ausnahmeverfahren aus, anstatt einfach anzunehmen, dass die Deregistrierung abgeschlossen sei.
Gilt die Deregistrierung für den 3GPP-Zugang und besteht zwischen AMF und NG-RAN noch eine N2-Signalisierungsverbindung, kann der AMF anschließend mit N2 UE Context Release fortfahren, um die entsprechende Signalisierungsverbindung auf der Zugangsseite zu beenden.
Das Ausschalten wird anders behandelt. Das UE steht kurz vor dem Ausschalten, daher ist es wenig sinnvoll, es nur für eine Bestätigungsnachricht online zu halten. Wenn der Deregistration type das Ausschalten angibt, behandelt der AMF die UE-Seite nicht wie bei normaler Deregistrierung, indem er vor dem Verlassen zwingend ein Deregistration Accept verlangt. Nachdem das UE sein Bestes getan hat, den Deregistration Request zu übermitteln, kann es mit dem Abschaltvorgang fortfahren.
Dieser Unterschied ist in Paket-Traces besonders wichtig:
Normale Deregistrierung
Deregistration Request
→ Das Kernnetz gibt die zugehörigen Ressourcen frei
→ Deregistration Accept
→ Signalisierungs- / AN-Freigabe
Abschalten
Deregistration Request
→ Das Kernnetz gibt die zugehörigen Ressourcen frei
→ Das UE wartet vor Abschluss des Abschaltens nicht auf Deregistration Accept
Das Fehlen von Deregistration Accept in einem Abschalt-Trace bedeutet daher nicht automatisch, dass das Verfahren fehlgeschlagen ist. Zunächst ist zu prüfen, ob der Deregistration type normale Deregistrierung oder Ausschalten angibt. Hat sich das UE bereits ausgeschaltet, die Funkverbindung verloren oder nicht genug Zeit für eine Antwort gehabt, kann das Netz später Mechanismen wie Mobile Reachable Timer und Implicit Deregistration nutzen, um ein unerwartetes Verschwinden des UE zu behandeln.
Häufige Fragen
Ist garantiert, dass das UE beim Ausschalten den Deregistration Request an den AMF übermittelt?
Nein. Das Ausschaltverfahren ist so ausgelegt, dass das UE vor dem Ausschalten nach bestem Bemühen den Deregistrierungs-Request sendet. Das Netz kann ihn jedoch nie erhalten, wenn das UE bereits die Abdeckung verloren hat, die Funkverbindung ausgefallen ist oder die Stromversorgung plötzlich wegfällt. Deshalb benötigt das 5GC weiterhin netzseitige Mechanismen wie Mobile Reachable Timer und Implicit Deregistration, um unerwartet verschwindende UEs zu behandeln.
Löst eine UE-Deregistrierung immer PFCP Session Deletion aus?
Nein. Wenn auf dem Ziel-Access-Type keine PDU-Sitzung aufgebaut ist, gibt es keine entsprechende N4-User-Plane-Sitzung freizugeben. Daher können die mit der PDU-Sitzungsbereinigung verbundenen Schritte in SMF und UPF fehlen. PFCP Session Deletion ist nur erforderlich, wenn eine relevante PDU-Sitzung und ihre User-Plane-Ressourcen tatsächlich existieren.
Sind Deregistrierung und Freigabe einer PDU-Sitzung dasselbe Verfahren?
Nein. Die Freigabe einer PDU-Sitzung entfernt eine bestimmte Datensitzung, während das UE weiterhin 5GS Registered bleiben kann. Die Deregistrierung entfernt die Registrierungsbeziehung des UE zum 5GS. Wenn sich das UE deregistriert, müssen bestehende PDU-Sitzungen normalerweise als zugehörige Ressourcen freigegeben werden, die beiden Verfahren arbeiten jedoch auf unterschiedlichen Ebenen und verfolgen unterschiedliche Ziele.
Warum kann nach der UE-Deregistrierung noch UDM- oder PCF-Kontext bestehen bleiben?
Zunächst ist zu prüfen, für welchen Access Type die Deregistrierung gilt und ob das UE über einen anderen Zugang weiterhin registriert bleibt. Wenn das UE noch einen anderen gültigen Zugang, weitere aktive PDU-Sitzungen oder weiterhin benötigte Policy-Beziehungen besitzt, muss möglicherweise ein Teil des Kontexts erhalten bleiben. Die Deregistrierung darf nicht als bedingungslose Löschung jedes UE-Zustands im gesamten 5GC verstanden werden.
