Ein Ausfall des Kernnetzes entsteht nicht immer durch unzureichende Rechenleistung. Sehr häufig liegt das eigentliche Problem im Zustand. Fällt eine Netzwerkfunktion aus, während der Benutzerkontext an einem zuverlässigen Ort erhalten bleibt, kann eine andere Funktion den Dienst möglicherweise fortsetzen. Verschwindet der Kontext zusammen mit dem ausgefallenen Knoten, wird die Wiederherstellung deutlich schwieriger. Darauf beruht eine wichtige Designidee von 5GC: die Trennung von Rechen- und Speicherressourcen.
In einem mobilen Kernnetz kann der Benutzerkontext den Registrierungsstatus, Mobilitätsinformationen, temporäre Identitäten, sitzungsbezogene Daten, Standortreferenzen und weitere Dienstzustände enthalten. Diese Werte helfen dem Netz zu erkennen, wer das UE ist, wo es sich befindet, welche Sitzung es nutzt und wie spätere Signalisierung zu verarbeiten ist. Ist dieser Kontext eng an eine einzige lokale Instanz einer Netzwerkfunktion gebunden, ist diese Instanz mehr als ein Verarbeitungsknoten. Sie wird zu einem einzelnen Risikopunkt für die Dienstkontinuität.
5GC begegnet diesem Risiko durch eine stärkere Unterstützung zustandsloser Netzwerkfunktionen. Das bedeutet nicht, dass eine Netzwerkfunktion während des Betriebs niemals Zustände verwendet. Entscheidend ist vielmehr, dass langfristige oder wiederherstellbare Zustände nicht in einer einzigen lokalen Recheninstanz eingeschlossen bleiben. Indem unstrukturierte Daten wie der UE-Kontext über UDSF gespeichert und abgerufen werden können, erhalten AMF und andere Netzwerkfunktionen ein flexibleres Wiederherstellungsmodell.
Warum lokaler Zustand zum Risiko wird
Das Beispiel des 4G-MME verdeutlicht das Problem. In einem LTE/EPC-Netz erzeugt und speichert ein MME nach dem Attach eines UE über MME1 den UE-Kontext lokal. Der Kontext kann Informationen zum Mobilitäts- und Sitzungsmanagement enthalten, etwa den Standort des UE, die GUTI und UE-IP-bezogene Parameter.
Fällt MME1 unerwartet aus, kann MME2 innerhalb des MME-Pools weiterhin physisch verfügbar sein. Die Verfügbarkeit eines anderen MME bedeutet jedoch nicht automatisch Dienstkontinuität. Existiert der UE-Kontext nur auf MME1, fehlen MME2 ausreichende Informationen, um das UE nahtlos weiter zu bedienen. Der Benutzer muss das Gerät möglicherweise aus- und wieder einschalten oder erneut attachen, bevor der Dienst wiederhergestellt ist. Aus Sicht der Benutzererfahrung ist dies ein unzureichendes Wiederherstellungsmodell.
Eine herkömmliche Lösung ist ein MME-Cluster mit Active-Standby-Synchronisierung. Dabei wird der UE-Kontext in Echtzeit zwischen aktivem und Standby-MME synchronisiert. Fällt das aktive MME aus, kann der Standby-Knoten mit dem synchronisierten Kontext übernehmen. Dieser Ansatz kann Dienstunterbrechungen reduzieren, hat aber auch Grenzen. Er kann von herstellerspezifischen Implementierungen abhängen, nur begrenzt standardisiert sein, zusätzliche Kosten verursachen und die Portabilität zwischen unterschiedlichen Systemumgebungen einschränken.
Das grundlegende Problem besteht darin, dass lokaler Zustand eine enge Bindung zwischen einer Dienstinstanz und ihren Daten erzeugt. Sobald der Rechenknoten der einzige praktische Träger des Benutzerkontexts ist, wird das Failover komplexer. 5GC verfolgt ein saubereres Modell, indem wiederherstellbarer Zustand in eine separate Speicherfunktion verlagert wird, auf die autorisierte Netzwerkfunktionen zugreifen können.
Was UDSF verändert
UDSF steht für Unstructured Data Storage Function, also Funktion zur Speicherung unstrukturierter Daten. Sie ermöglicht jeder 5GC-Netzwerkfunktion, ihre unstrukturierten Daten einschließlich des UE-Kontexts zu speichern und abzurufen. In diesem Modell kann das AMF oder eine andere NF die Signalisierung als Rechenfunktion verarbeiten, während UDSF einen unabhängigen Speicherort für ausgewählte Zustandsinformationen bereitstellt.
Dies ähnelt konzeptionell einer festplattenlosen Workstation. Eine solche Workstation besitzt CPU, Arbeitsspeicher, Netzwerkschnittstelle und weitere Ausführungshardware, speichert ihre Arbeitsdaten jedoch nicht auf einer lokalen Festplatte. Sie startet und bezieht ihre Daten von einem Netzwerkserver. Die Workstation führt Berechnungen aus, während der Speicher getrennt ist. In 5GC lassen sich Netzwerkfunktionen vergleichbar gestalten: Die NF verarbeitet Signalisierung und Dienstlogik, während Kontextdaten außerhalb der lokalen Instanz gespeichert werden können.
Der Nutzen von UDSF besteht nicht nur darin, wie eine Datenbank zu arbeiten. Der architektonische Wert liegt in der Unterstützung zustandsloser NF-Designs, der AMF-Wiederherstellung und flexiblerer cloudnativer Bereitstellungen. Ist der Zustand über UDSF zugänglich, kann eine AMF-Instanz ausfallen, ohne zwangsläufig einen dauerhaften Verlust des UE-Kontexts zu verursachen. Ein neu ausgewähltes AMF kann den erforderlichen Kontext abrufen und die Verarbeitung bei der nächsten Transaktion fortsetzen.
UDSF passt auch zur allgemeinen Entwicklung virtualisierter und cloudnativer Kernnetze. In einer Cloud-Bereitstellung können Netzwerkfunktionsinstanzen horizontal skaliert, reduziert, neu gestartet oder innerhalb der Infrastruktur verschoben werden. Wenn jede Instanz ihren lokalen Zustand fest an sich bindet, wird Automatisierung schwierig. Die Entkopplung von Rechenleistung und Speicher macht Skalierung und Wiederherstellung besser beherrschbar.
Wie sich Datentypen unterscheiden
Für ein korrektes Verständnis von UDSF ist die Unterscheidung zwischen strukturierten und unstrukturierten Daten wichtig. In der 5GC-Terminologie sind strukturierte Daten solche, deren Aufbau durch 3GPP-Spezifikationen definiert ist. Teilnehmerdaten sind ein typisches Beispiel, weil ihre Ressourcenstruktur und ihr Zugriffsmodell eindeutig beschrieben sind.
Unstrukturierte Daten sind Daten, deren interne Struktur nicht durch 3GPP-Spezifikationen festgelegt ist. Der UE-Kontext ist ein typisches Beispiel. Er ist für die Dienstkontinuität entscheidend, seine genaue interne Organisation ist jedoch nicht auf dieselbe Weise standardisiert wie Teilnehmerdaten. Deshalb eignet er sich für die Speicherung über UDSF.
Dieser Unterschied wirkt sich auf die technische Planung aus. Strukturierte Daten können über standardisierte Datendienste mit definierten Ressourcenmodellen verwaltet werden. Unstrukturierte Daten werden in der Regel von der Netzwerkfunktion erzeugt und interpretiert, die für die Dienstlogik zuständig ist. UDSF bietet dieser Funktion einen Speicherort, an dem Daten gesichert und abgerufen werden können, ohne das gesamte interne Format in einen standardisierten Datenbaum überführen zu müssen.
Bei der Bereitstellungsplanung sollten Ingenieure nicht alle 5GC-Daten als eine einzige Kategorie behandeln. Teilnehmerdaten, Richtliniendaten, Sitzungszustand, temporärer Benutzerkontext und wiederherstellungsbezogene Informationen können sich hinsichtlich Zugriffshäufigkeit, Latenzempfindlichkeit, Struktur, Zuständigkeit und Wiederherstellungsanforderungen unterscheiden. UDSF konzentriert sich vor allem auf unstrukturierten Zustand, den Netzwerkfunktionen für Resilienz und Kontinuität benötigen.
Wie die AMF-Wiederherstellung funktioniert
Ein typischer AMF-Wiederherstellungsprozess mit UDSF folgt einer klaren Abfolge. Zunächst registriert sich ein 5G-UE über AMF1. AMF1 erstellt den für Zugangs- und Mobilitätsmanagement erforderlichen UE-Kontext. Anschließend speichert AMF1 diesen Kontext in UDSF. Damit ist der Benutzerzustand nicht mehr ausschließlich in der lokalen AMF-Instanz eingeschlossen.
Fällt AMF1 aus, erkennen das 5G-Zugangsnetz oder gleichrangige Kontrollfunktionen den Fehler. Das ausgefallene AMF wird bei der Auswahl nicht mehr berücksichtigt. Muss das Netz ein anderes AMF aus demselben AMF-Set wählen, kann es AMF2 auswählen. An dieser Stelle verändert UDSF das Wiederherstellungsverhalten.
AMF2 muss das UE nicht als vollständig unbekanntes Gerät behandeln. Bei einer Transaktion mit dem UE kann AMF2 den UE-Kontext aus UDSF abrufen. Dafür können Kennungen wie SUPI, 5G-GUTI oder AMF UE NGAP ID verwendet werden. Nach dem Abruf kann AMF2 die UE-Nachricht verarbeiten und bei Bedarf die 5G-GUTI gegenüber dem UE aktualisieren.
Das praktische Ergebnis ist eine bessere Dienstkontinuität. Das Netz benötigt weiterhin eine korrekte Fehlererkennung, AMF-Neuauswahl und Logik zum Kontextabruf, doch die Grundlage der Wiederherstellung ist stärker als bei einem Modell, in dem der gesamte Benutzerkontext nur im ausgefallenen Knoten gespeichert ist. Aus Benutzersicht besteht das ideale Ergebnis in einer Wiederherstellung ohne Neustart des Geräts, manuelles erneutes Attach oder wahrnehmbare Dienstunterbrechung.
Technischer Nutzen und Grenzen
Der wichtigste technische Nutzen der Entkopplung von Rechenleistung und Speicher ist die Resilienz. Fällt eine AMF-Instanz aus, kann der Dienstzustand weiterhin über UDSF verfügbar sein. Das verringert die Abhängigkeit vom lokalen Knotenzustand und ermöglicht eine Wiederherstellung mit geringeren Auswirkungen. Zudem wird elastische Skalierung unterstützt, weil neue Netzwerkfunktionsinstanzen eingeführt werden können, ohne zuvor den gesamten historischen Zustand lokal synchronisieren zu müssen.
Der zweite Nutzen ist die architektonische Portabilität. Im Vergleich zu herstellerspezifischer Active-Standby-Synchronisierung ist UDSF Bestandteil der 5GC-Architektur und passt besser zu einem standardisierten cloudnativen Kernnetzdesign. Dadurch lässt sich Zustandspeicherung und -wiederherstellung offener gestalten, statt Hochverfügbarkeit an einen proprietären Clustermechanismus zu binden.
UDSF beseitigt jedoch nicht jede Komplexität. Die Funktion wird zu einem kritischen Bestandteil der Wiederherstellungskette. Ist UDSF langsam, nicht verfügbar, inkonsistent oder unzureichend geschützt, kann sie zu einem neuen Engpass werden. Deshalb muss UDSF selbst mit hoher Verfügbarkeit, schnellen Lese- und Schreibvorgängen, zuverlässiger Replikation, sicherer Zugriffskontrolle und Disaster-Recovery-Fähigkeit ausgelegt werden.
Auch die Wahl der Datenbank ist wichtig. In UDSF-bezogenen Designs können abhängig von Herstellerimplementierung und Systemanforderungen sowohl relationale als auch nicht relationale Datenbanken eingesetzt werden. Entscheidend ist nicht nur der Datenbanktyp, sondern ob die gesamte Speicherschicht Anforderungen an Latenz, Zuverlässigkeit, Konsistenz und Wiederherstellung auf Telekommunikationsniveau erfüllt.
Für Ingenieure gehören zu den wichtigsten Prüfungen, ob der UE-Kontext zum richtigen Zeitpunkt in UDSF geschrieben wird, ob das neu ausgewählte AMF ihn korrekt abrufen kann, ob die Auswahl innerhalb des AMF-Sets erwartungsgemäß funktioniert, ob Kennungen konsistent verarbeitet werden und ob das Failover für den Benutzer tatsächlich unsichtbar oder nahezu unsichtbar ist. Die Entkopplung ist nur wertvoll, wenn der gesamte Wiederherstellungspfad Ende zu Ende getestet wird.
FAQ
Wird UDSF nur vom AMF verwendet?
Nein. UDSF ist für jede Netzwerkfunktion vorgesehen, die unstrukturierte Daten speichern und abrufen muss. Die AMF-Wiederherstellung mit UE-Kontext ist lediglich eines der anschaulichsten Beispiele.
Warum gilt der UE-Kontext als unstrukturierte Daten?
Der UE-Kontext ist wichtig, seine interne Struktur ist jedoch nicht vollständig als standardisierte 3GPP-Datenstruktur definiert. Daher eignet er sich für die Speicherung als unstrukturierte Daten.
Ersetzt UDSF den gesamten lokalen Zustand in Netzwerkfunktionen?
Nicht vollständig. Netzwerkfunktionen können während der Verarbeitung weiterhin temporären lokalen Zustand verwenden. UDSF dient hauptsächlich dazu, wiederherstellbare unstrukturierte Daten zu erhalten, die nicht mit einer einzelnen Recheninstanz verloren gehen dürfen.
Kann UDSF eine vollständig unterbrechungsfreie Dienstwiederherstellung garantieren?
Nicht allein. UDSF verbessert die Grundlage für die Wiederherstellung, die tatsächliche Kontinuität hängt jedoch auch von Fehlererkennung, AMF-Neuauswahl, Datenaktualität, Signalisierungsverhalten und UDSF-Verfügbarkeit ab.
Was sollte vor einer produktiven UDSF-Bereitstellung getestet werden?
Tests sollten den Zeitpunkt der Kontextspeicherung, den Kontextabruf, die Erkennung eines AMF-Ausfalls, die Neuauswahl im AMF-Set, Datenbank-Failover, Lese- und Schreiblatenz, Zugriffssicherheit und die reale UE-Erfahrung während der Wiederherstellung abdecken.
Die Entkopplung von Rechenleistung und Speicher in 5GC ist mehr als eine Anpassung der Datenbank. Sie verändert, wie das Kernnetz Zustand, Ausfall und Wiederherstellung betrachtet. Durch UDSF zur Speicherung unstrukturierter Daten wie des UE-Kontexts können Netzwerkfunktionen weniger von lokalem Speicher abhängen und besser für resiliente cloudnative Bereitstellungen geeignet sein. Die Grundidee ist einfach: Recheninstanzen können ausfallen oder wechseln, der Benutzerzustand muss jedoch wiederherstellbar bleiben.