Ein einziges 5G-Netz soll gleichzeitig sehr unterschiedliche Dienstwelten unterstützen. Ein Nutzer sieht möglicherweise hochauflösende Videos, ein anderer verwendet eine große Zahl von IoT-Sensorverbindungen, während ein Industriekunde für einen lokalen Produktionsprozess extrem geringe Latenz und höhere Zuverlässigkeit benötigt. Diese Dienste stellen nicht dieselben Anforderungen an Bandbreite, Verzögerung, Sicherheit, Gerätedichte oder Abdeckungsanforderungen.
Für jeden Diensttyp ein separates physisches Mobilfunknetz aufzubauen, ist unrealistisch. Die Kosten wären zu hoch, die Ressourcen schwer zu verwalten und die Bereitstellung zu langsam. 5GC-Network-Slicing löst dieses Problem, indem es logische private Netze auf gemeinsam genutzter physischer Infrastruktur erzeugt. Jeder Slice kann mit eigenen Dienstmerkmalen entworfen werden und zugleich gemeinsame Zugangs-, Transport-, Rechen- und Kernnetzressourcen wiederverwenden.
Vereinfacht gesagt ist ein Network Slice ein angepasstes logisches Netz für eine bestimmte Dienstgruppe, einen Industriekunden oder eine Anwendungskategorie. Es handelt sich nicht nur um ein 5GC-Konzept innerhalb des Kernnetzes, sondern um einen Ende-zu-Ende-Ansatz, der das 5G-Zugangsnetz, das Transport- oder Trägernetz und das 5G-Kernnetz umfassen kann. Der Nutzen entsteht aus dem Ausgleich zweier Ziele: gemeinsame Nutzung physischer Ressourcen für Kosteneffizienz und logische Isolierung für die Differenzierung von Diensten.
Warum Network Slices benötigt werden
Der Hintergrund des 5GC-Network-Slicings liegt in den großen Unterschieden zwischen den 5G-Dienstszenarien. Die üblichen Kategorien sind eMBB, mMTC und uRLLC. Enhanced Mobile Broadband konzentriert sich auf hohen Durchsatz und ein umfangreiches Nutzererlebnis. Massive Machine Type Communication konzentriert sich auf eine sehr große Zahl von Geräten mit niedriger Datenrate. Ultra-Reliable Low-Latency Communication konzentriert sich auf strenge Latenz-, Zuverlässigkeits- und Dienstgarantieanforderungen.
Diese Kategorien führen zu unterschiedlichen Prioritäten beim Netzdesign. eMBB kann einen hohen oder sehr hohen Durchsatz pro Gerät und eine breite Abdeckung erfordern. mMTC kann eine sehr hohe Gerätedichte, niedrige Datenraten und geringe Kosten pro Bit benötigen. uRLLC kann extrem geringe Latenz, höhere Zuverlässigkeit und eine strengere Kontrolle des Dienstverhaltens verlangen. Würden all diese Dienste als gewöhnlicher Best-Effort-Verkehr behandelt, bliebe das Potenzial von 5G ungenutzt.
Network Slicing ermöglicht es einem Betreiber, diese unterschiedlichen Anforderungen durch logische Trennung zu erfüllen. Ein Breitband-Slice für Endkunden, ein industrieller Steuerungs-Slice und ein IoT-Slice können dieselbe physische Infrastruktur nutzen, während ihre Dienstregeln, Kernnetzfunktionen, ihr QoS-Verhalten und ihre Betriebsregeln unterschiedlich sind. Dadurch lässt sich Mobilfunknetzfähigkeiten flexibler vermarkten und betreiben.
Was ein Slice enthält
Ein Network Slice ist ein logisches Netz mit bestimmten Netzfähigkeiten und Eigenschaften. Eine Network Slice Instance, kurz NSI, ist die bereitgestellte Ausprägung dieses Slices. Sie enthält eine Gruppe von Netzfunktionsinstanzen und die zu deren Betrieb benötigten Rechen-, Speicher- und Netzwerkressourcen.
In einer 5GC-Bereitstellung können einige Funktionen von mehreren Slices gemeinsam genutzt werden, während andere einem einzelnen Slice vorbehalten sind. So können mehrere Slices in bestimmten Designs gemeinsame Steuerungsebenenfunktionen wie AMF teilen. Gleichzeitig kann jeder Slice eigene SMF- und UPF-Instanzen verwenden, damit Sitzungsverarbeitung und Nutzerebenenverkehr slice-spezifischen Anforderungen folgen.
Dadurch entsteht eine klare Trennung zwischen gemeinsamen und slice-spezifischen Teilen. Der gemeinsame Teil verringert Doppelungen und spart Ressourcen. Der slice-spezifische Teil verleiht jedem Dienst ein eigenes Verhalten, einen eigenen Datenpfad und eine eigene Behandlung. In vielen Designs kann ein UE außerdem auf mehrere Slices zugreifen, wobei unterschiedliche PDU-Sitzungen verschiedene slice-bezogene Pfade verwenden.
Network Slicing verlangt nicht, dass jede Funktion auf einem physisch separaten Server läuft. Funktionen unterschiedlicher Slices können auf demselben X86-Servercluster ausgeführt und dennoch durch Virtualisierung, KVM, Container-Namespaces, VPN-Mechanismen und Verwaltungsrichtlinien isoliert werden. Dies ist einer der Gründe, weshalb Slicing praktikabler ist als der Aufbau separater physischer Netze.
Wie die Slice-Identität funktioniert
Die Slice-Auswahl basiert auf Kennungen. Die zentrale Kennung ist S-NSSAI, die Single Network Slice Selection Assistance Information. Sie identifiziert einen einzelnen Network Slice eindeutig. NSSAI ist eine Sammlung mehrerer S-NSSAIs und steht daher für eine Gruppe von Slices statt nur für einen.
S-NSSAI besteht aus zwei Hauptteilen. SST, der Slice/Service Type, kennzeichnet den Slice-Typ. Übliche SST-Werte sind 1 für eMBB, 2 für URLLC, 3 für MIOT und 4 für V2X. SD, der Slice Differentiator, unterscheidet mehrere Slices desselben Typs. Dies ist hilfreich, wenn zwei Slices derselben Dienstklasse angehören, aber unterschiedliche Kunden, Regionen oder Geschäftsrichtlinien bedienen.
Mehrere NSSAI-Begriffe sind in realen Abläufen wichtig. Configured NSSAI kann im UE vorkonfiguriert oder von AMF bereitgestellt werden und hilft dem UE, die angeforderten Slice-Informationen zu erzeugen. Subscribed NSSAI sind die für den Nutzer gespeicherten Slice-Abonnementdaten. Requested NSSAI wird vom UE in der Registrierungsanforderung übertragen. Allowed NSSAI ist die Slice-Menge, auf die das UE im aktuellen Registrierungsgebiet zugreifen darf. Rejected NSSAI informiert das UE darüber, welche Slice-Zugriffe abgelehnt wurden.
Die erlaubte Slice-Menge wird nicht allein vom UE bestimmt. Sie hängt von NSSF-Richtlinien, UDM-Abonnementdaten, der Unterstützungsfähigkeit des AMF und den Bedingungen des Registrierungsgebiets ab. Das endgültige Ergebnis wird vom AMF in der Registrierungsannahme an das UE übermittelt. Ein UE kann gleichzeitig Zugriff auf bis zu acht Slices erhalten, sodass Allowed NSSAI bis zu acht S-NSSAIs enthalten kann.
Wie die Auswahl entschieden wird
5G führt NSSF, die Network Slice Selection Function, ein, um eine geeignete Slice-Instanz auszuwählen, einen AMF-Einstiegspunkt für den Slice zu bestimmen und Allowed NSSAI festzulegen. Die Slice-Auswahl erfolgt in zwei Hauptphasen. Die erste findet bei der Erstregistrierung statt: Das Netz wählt den mit dem Slice verbundenen AMF und bestimmt die für das UE erlaubte Slice-Menge. Die zweite erfolgt beim Aufbau einer PDU-Sitzung, wenn SMF, UPF und die zugehörige Nutzerebenenverarbeitung ausgewählt werden.
Während der Registrierung kann das UE Requested NSSAI anhand seines Configured NSSAI oder eines zuvor gespeicherten Allowed NSSAI auswählen. Wenn der gNB einen AMF wählen muss, kann er bei Verfügbarkeit 5G-S-TMSI oder GUAMI verwenden. Sind diese Kennungen nicht vorhanden, kann der gNB Requested NSSAI zur Steuerung der AMF-Auswahl nutzen. Hilft keine dieser Bedingungen, kann die Nachricht an einen Standard-AMF gesendet werden.
Requested S-NSSAI verbessert den ersten AMF-Auswahlversuch. Statt ohne Grundlage auszuwählen, verfügt der gNB über slice-bezogene Informationen, die die Wahrscheinlichkeit eines geeigneten AMF erhöhen. Kann der gewählte AMF den angeforderten Slice bedienen und besitzt das UE die entsprechende Berechtigung, kann der AMF die Registrierungsannahme mit dem passenden Allowed NSSAI senden.
Kann der AMF den angeforderten Slice nicht bedienen oder ist das UE nicht für diesen Slice angemeldet, muss der AMF möglicherweise NSSF abfragen. NSSF kann ein anderes Allowed NSSAI und einen geeigneten AMF zurückgeben. Die Registrierungsanforderung kann anschließend direkt oder indirekt zum richtigen AMF umgeleitet werden. So bleibt die Auswahl flexibel und zugleich durch Abonnement, Richtlinien und Netzfähigkeit kontrolliert.
Warum Isolierung wichtig ist
Isolierung ist einer der Hauptgründe, weshalb Unternehmen und Industriekunden Slicing nutzen möchten. Jeder Slice soll sich wie ein logisches privates Netz verhalten, obwohl physische Ressourcen geteilt werden. Unterschiedliche Slices dürfen einander nicht beliebig sehen oder beeinflussen. Dies unterstützt Sicherheit, betriebliche Unabhängigkeit und die Kontrolle des Dienstniveaus.
Isolierung kann auf mehreren Ebenen umgesetzt werden. Die Slice-Auswahl trennt den Dienstzugangspfad. Virtuelle Maschinen oder Container trennen Rechenumgebungen. Namespace-Mechanismen können Ressourcen auf Containerebene isolieren. VPNs und Transporttrennung schützen Verkehrswege. Richtliniensteuerung kann unterschiedliche QoS- und Dienstregeln definieren. Verwaltungssysteme können außerdem Kundensichtbarkeit und Betriebsberechtigungen voneinander trennen.
Auf geschäftlicher Ebene erleichtert Isolierung die Bereitstellung maßgeschneiderter Dienste. Ein Fabrik-Slice kann höhere Zuverlässigkeit und geringere Latenz benötigen. Ein Video-Breitband-Slice kann hohen Durchsatz verlangen. Ein IoT-Slice kann große Gerätekapazität und geringe Signalisierungskosten erfordern. Jeder Slice lässt sich an unterschiedliche Anforderungen anpassen, ohne die Kosten eines vollständig separaten physischen Netzes zu verursachen.
Warum Lebenszyklusverwaltung entscheidend ist
Network Slices sind keine statischen Objekte. Wie Netzfunktionen besitzen sie einen Lebenszyklus. Ein Slice kann vorbereitet, instanziiert, konfiguriert, aktiviert, überwacht, skaliert, geändert, deaktiviert und beendet werden. Diese Verwaltung ist wichtig, weil Slicing erst dann kommerziell nutzbar wird, wenn Slices effizient erstellt, geändert und entfernt werden können.
Der Lebenszyklus lässt sich in vier Phasen gliedern. Die erste ist die Vorbereitung mit Slice-Template-Design, Vorbereitstellung und Vorbereitung der Netzumgebung. Die zweite umfasst Instanziierung, Konfiguration und Aktivierung, wobei der Slice erstellt, die Dienstkonfiguration geladen und der Betrieb aufgenommen wird. Die dritte ist der Laufzeitbetrieb, in dem KPIs, Alarme, Berichte und die Dienstperformance überwacht werden. Auf dieser Grundlage kann das System Selbstheilung oder automatische Skalierung auslösen. Die vierte ist die Außerbetriebnahme, bei der Nutzer migriert, der Slice deaktiviert und Ressourcen freigegeben werden können.
Dieser Prozess wird üblicherweise von einem Slice-Manager zusammen mit MANO durchgeführt. MANO umfasst Orchestrierung, VNF-Verwaltung und Verwaltung der virtuellen Infrastruktur. EMS- oder NMS-Funktionen übernehmen Netzelementverwaltung, Konfiguration, Alarm-, Leistungs- und sicherheitsbezogene Aufgaben. Gemeinsam wandeln diese Systeme einen Slice-Entwurf in einen bereitgestellten und verwaltbaren Netzdienst um.
Templates ermöglichen NSaaS
Ein Slice-Template beschreibt die benötigten Netzfunktionen, Spezifikationen, Ressourcen, Verbindungen und Dienstparameter. Für externe Kunden erscheint es als Slice-Template. Innerhalb der Betreiberumgebung muss es möglicherweise in ein von MANO interpretierbares Netzdienst-Template umgewandelt werden. Je nach Orchestrierungsumgebung können Formate wie HOT, OVF und TOSCA verwendet werden.
Das Template-Design beginnt mit den Kundenanforderungen. Der Betreiber muss QoS-Bedarf, Bandbreite, Zahl gleichzeitig aktiver Nutzer, Redundanz, Sicherheit und Dienstabdeckung verstehen. Diese Anforderungen werden anschließend in Netzressourcen und 5GC-Parameter wie 5QI und zugehörige Richtliniensteuerung übersetzt. Danach kann das Template für die Lebenszyklusverwaltung in den Slice-Manager oder Orchestrator geladen werden.
Daraus entsteht das Konzept Network Slice as a Service, kurz NSaaS. In einem idealen Modell kann ein Industriekunde online ein Slice-Template auswählen, Dienstanforderungen übermitteln, eine Bestellung abschließen und nach automatischer Erstellung die Slice-Parameter erhalten. Der Slice-Marktplatz oder das Kundenportal sendet die Bestellung an BOSS und den Orchestrator. Der Orchestrator arbeitet mit VNFM, VIM sowie EMS oder NMS zusammen, um den Slice zu instanziieren, Ressourcen zuzuweisen, Netzfunktionen zu konfigurieren und die Dienstbereitschaft zu bestätigen.
Das Ergebnis ist ein neues Geschäftsmodell. Statt langer Offline-Verhandlungen und manueller Aktivierung kann der Kunde ein Self-Service-Portal, schnellere Bereitstellung und elastische Erweiterung erhalten. Ein kleiner Kunde könnte mit einem Slice für 500 Nutzer beginnen, ihn ein Jahr lang betreiben und später auf 1000 Nutzer erweitern. Endet der Dienst, kann der Slice gelöscht und die Ressourcen freigegeben werden. Das ist der praktische Nutzen des Slicings: maßgeschneiderte Dienste, kürzere Markteinführungszeit und bessere Ressourcennutzung.
Häufig gestellte Fragen
Kann ein Network Slice ohne dedizierte physische Hardware existieren?
Ja. Ein Slice ist ein logisches Netz. Es kann physische Server, Transportressourcen und Zugangsinfrastruktur teilen und zugleich durch Virtualisierung, Container und Richtliniensteuerung getrennt bleiben.
Warum benötigt ein UE mehrere Slices?
Ein UE kann gleichzeitig unterschiedliche Diensttypen verwenden. Beispielsweise kann eine PDU-Sitzung einen Unternehmens-Slice nutzen, während eine andere einen allgemeinen Internet- oder IMS-bezogenen Slice verwendet.
Wovon hängt die Annahme einer Slice-Anforderung ab?
Die Annahme hängt von Abonnementdaten, AMF-Fähigkeit, NSSF-Richtlinien, den Bedingungen des Registrierungsgebiets und davon ab, ob das angeforderte S-NSSAI im aktuellen Netzkontext unterstützt wird.
Warum wird SD benötigt, wenn SST den Slice-Typ bereits kennzeichnet?
SST kennzeichnet den Diensttyp, während SD unterschiedliche Slices desselben Typs unterscheidet. Dadurch können mehrere eMBB-, URLLC- oder IoT-Slices mit unterschiedlicher geschäftlicher Bedeutung gleichzeitig bestehen.
Wie verkürzt Slicing die kommerzielle Bereitstellungszeit?
Templates, Orchestrierung und automatisierte Lebenszyklusverwaltung verringern manuelle Design- und Bereitstellungsarbeiten. Skalierung, Aktivierung und Ressourcenfreigabe können wesentlich schneller erfolgen als beim traditionellen Aufbau eines dedizierten Netzes.
5GC-Network-Slicing ist nicht nur eine technische Architektur. Es ist eine Möglichkeit, Mobilfunknetzfähigkeiten als logische, isolierte und dienstspezifische Netze bereitzustellen. Durch die Kombination aus gemeinsam genutzter Infrastruktur, Slice-Identität, kontrollierter Auswahl, Lebenszyklusverwaltung und template-basierter Orchestrierung können Betreiber unterschiedliche Branchen und Diensttypen unterstützen, ohne für jeden Kunden ein separates physisches Netz aufzubauen.
