Ein 5G-Gerät kann sich im Netz registrieren, ohne sofort einen Benutzerdatenpfad aufzubauen. Diese kleine Designänderung zeigt deutlich, wie sich das 5GC-Sitzungsmanagement von älteren Mobilfunkkernnetzen unterscheidet. In 4G war der Attach-Vorgang eng mit dem Aufbau einer standardmäßigen PDN-Verbindung und eines Default Bearers verknüpft. In 5G sind Registrierung und Sitzungsaufbau klarer voneinander getrennt. Dadurch kann das Netz freier entscheiden, wann ein Benutzerpfad tatsächlich benötigt wird.

Das 5GC-Sitzungsmanagement ist die Steuerungsebene, die festlegt, wie ein UE eine Verbindung zu einem Datennetz herstellt, welche PDU-Sitzung aufgebaut wird, welches DNN verwendet wird, welche Slice-Informationen gelten, welche QoS-Regeln zugewiesen werden, welches UPF den Verkehr verankert und wie bei Bewegung des UE die Kontinuität behandelt wird. Es ist nicht nur eine umbenannte Version des 4G-Bearer-Managements, sondern ein flexiblerer Rahmen für mobiles Breitband, Sprache über 5G, Unternehmenszugang, latenzarme Dienste, lokale Datennetze und Edge Computing.

Deshalb gehört das Sitzungsmanagement zu den zentralen Konzepten des 5G Core. Das Mobilitätsmanagement teilt dem Netz mit, wo sich das UE befindet und ob es erreichbar ist. Das Sitzungsmanagement legt fest, welchen Dienstpfad das UE benötigt, welches Datennetz erreicht werden soll, wie der Verkehr zu klassifizieren ist und wie Ressourcen der Benutzerebene gesteuert werden. Beide Funktionen arbeiten eng zusammen, werden aber nicht mehr als ein gemeinsamer Steuerungsblock behandelt.

Warum sich die Sitzungssteuerung änderte

Die größte architektonische Änderung ist die Trennung von Mobilitätsmanagement und Sitzungsmanagement. Im 5G Core ist das AMF für das NAS-Mobilitätsmanagement zuständig, während das SMF das Sitzungsmanagement übernimmt. NAS-SM-Nachrichten werden im AMF nicht vollständig verarbeitet. Stattdessen leitet das AMF die Sitzungsmanagement-Signalisierung über die N11-Schnittstelle an das SMF weiter. Das AMF hält den Sitzungsmanagementkontext des UE daher nicht mehr so vor wie die frühere kombinierte Steuerungslogik.

Diese Trennung macht den 5G Core übersichtlicher. Das AMF kann sich auf Registrierung, Zugangskontrolle, Erreichbarkeit, Mobilitätsstatus und standortbezogene Verfahren konzentrieren. Das SMF kann den Aufbau, die Änderung und die Freigabe von PDU-Sitzungen, die DNN-Verarbeitung, die UPF-Auswahl, die Steuerung von QoS-Regeln, die Sitzungskontinuität und abrechnungsbezogene Parameter übernehmen. Durch die getrennten Zuständigkeiten kann das Netz jede Funktion entsprechend ihrer eigenen Last skalieren.

Die Änderung passt auch zur Dienstausrichtung von 5G. Ein Smartphone, ein Industriesensor, ein Fahrzeug, ein privates Netzgerät und eine Edge-Computing-Anwendung können 5G sehr unterschiedlich nutzen. Manche Geräte benötigen häufige Datensitzungen. Andere registrieren sich und bleiben anschließend inaktiv. Einige brauchen nur lokalen Zugriff innerhalb eines festgelegten Bereichs. Andere erfordern bei Bewegung eine stabile IP-Kontinuität. Ein einziges Modell nach dem Prinzip „beim Einschalten immer einen Default Bearer aufbauen“ ist für diese Vielfalt nicht flexibel genug.

In 5G kann sich ein UE registrieren, ohne sofort eine PDU-Sitzung aufzubauen. Dadurch werden keine Ressourcen der Benutzerebene eingerichtet, bevor ein Dienst sie wirklich benötigt. Für massives IoT und maschinenartige Zugänge ist das besonders wichtig. Das Netz kann das UE kennen und erreichbar halten, ohne unnötige Datenpfade aufzubauen.

Die Trennung von Mobilitäts- und Sitzungssteuerung wirkt sich auch auf Teilnehmerdaten aus. UDM-Abonnementdaten werden in mobilitätsbezogene und sitzungsbezogene Teile gegliedert. Das AMF erhält Mobilitätsabonnementdaten, das SMF verwendet Abonnementdaten für das Sitzungsmanagement, und das AMF kann SMF-Auswahldaten erhalten, um beim Aufbau einer PDU-Sitzung das richtige SMF auszuwählen. Diese Struktur macht das Kernnetz modularer und erleichtert die Ausrichtung auf Network Slicing, DNN-spezifische Richtlinien und differenzierte Dienstmodelle.

Von PDN zu PDU

Viele Begriffe des 5G-Sitzungsmanagements stammen aus 4G, doch Terminologie und Struktur haben sich geändert. Die PDN-Verbindung aus 4G wird in 5G zu einer PDU-Sitzung . Das 4G- PDN wird zum DN, also zum Datennetz. Der 4G- APN wird zum DNN, also zum Datennetz-Namen. Der 4G-Default-Bearer wird durch den standardmäßigen QoS Flowersetzt, während dedizierte Bearer zu zusätzlichen oder nicht standardmäßigen QoS Flows werden.

Diese Änderung ist nicht nur kosmetisch. Eine PDU-Sitzung unterstützt verschiedene Arten der Protokolldateneinheiten-Konnektivität. In 4G umfasste der PDN-Typ hauptsächlich IPv4, IPv6 und IPv4v6. In 5G erhöht der PDU-Sitzungstyp die Flexibilität, indem Ethernet und unstrukturierte Daten als Nicht-IP-Optionen unterstützt werden. Das ist wichtig, weil 5G mehr als klassischen Internetzugang bereitstellen soll. Industriegeräte, private Unternehmensnetze und besondere Dienstumgebungen können Modelle benötigen, die nicht auf herkömmliche IP-Konnektivität beschränkt sind.

Ein UE kann eine PDU-Sitzung für den allgemeinen Internetzugang und eine weitere für IMS aufbauen. Innerhalb der IMS-bezogenen PDU-Sitzung können unterschiedliche QoS Flows für SIP-Signalisierung, VoNR-Audio und VoNR-Video verwendet werden. Der wichtige Unterschied besteht darin, dass 5G nicht mehr jeden Dienst auf dieselbe Weise einem separaten EPS Bearer zuordnet. Stattdessen ist der QoS Flow die zentrale Granularität für die Dienstbehandlung, während die DRB-Zuordnung auf der Funkseite durch das gNB gesteuert wird.

Dieses Modell ermöglicht eine feinere Dienststeuerung. Eine einzelne PDU-Sitzung kann mehrere QoS Flows transportieren, und jeder Flow kann andere 5QI- und ARP-Werte sowie eine unterschiedliche QoS-Behandlung erhalten. Für Unternehmens- und Betreiberdienste lassen sich so mehrere Verkehrsklassen unterstützen, ohne jeden Dienst in ein starres Bearer-Modell zu zwingen.

Wie das SMF die Kontrolle übernimmt

Das SMF ist die wichtigste Steuerungsfunktion für das 5GC-Sitzungsmanagement. Es übernimmt Aufbau, Änderung und Freigabe von PDU-Sitzungen. Es wählt die UPF-Nutzung aus oder steuert sie, verwaltet sitzungsbezogene Richtlinieninteraktionen, weist QoS-Regeln zu und bestimmt den Aufbau der Benutzerebene. Wenn das AMF NAS-SM-Signalisierung vom UE empfängt, leitet es diese Informationen an das SMF weiter, anstatt die gesamte Sitzungslogik lokal zu verarbeiten.

Durch dieses Design arbeiten AMF und SMF wie zwei koordinierte Ebenen. Das AMF kennt den Zugangs- und Mobilitätsstatus des UE. Das SMF kennt die Anforderungen der Dienstsitzung. Bei Anforderung einer PDU-Sitzung unterstützt das AMF den Signalisierungstransport und liefert zugangsbezogenen Kontext, während das SMF anhand von DNN, S-NSSAI, Abonnementdaten, Richtliniensteuerung und Verfügbarkeit der Benutzerebene entscheidet, wie die Sitzung aufgebaut wird.

Das SMF spielt auch bei der Auswahl des SSC-Modus eine zentrale Rolle. Die Auswahl erfolgt nicht zufällig. Sie hängt vom vom UE angeforderten SSC-Modus, vom in den UDM-Daten abonnierten SSC-Modus und von der Menge der zulässigen SSC-Modi ab. Nach dem Aufbau der PDU-Sitzung kann ihr SSC-Modus nicht mehr geändert werden. Deshalb ist die anfängliche Auswahl wichtig.

Eine weitere Kernaufgabe ist die Steuerung der Ressourcen der Benutzerebene. Das SMF kann diese Ressourcen aktivieren oder deaktivieren, eine PDU-Sitzung freigeben oder die Sitzungsbehandlung abhängig von Mobilität, Dienstbereich, Richtlinie und Zugangsstatus anpassen. Bei LADN kann das SMF beispielsweise nach dem Verlassen des LADN-Dienstbereichs durch das UE die zugehörige PDU-Sitzung freigeben oder die Benutzerressourcen deaktivieren.

Das SMF steuert außerdem die Verkehrslenkung für Edge-Computing-Szenarien. Werden UPFs als Anker und Klassifizierer eingesetzt, kann das SMF Regeln installieren, die den Verkehr zu einem entfernten DN oder zu einem lokalen Dienstnetz lenken. Damit ist das SMF sowohl für gewöhnliche Datensitzungen als auch für fortgeschrittene lokale Breakout-Modelle zentral.

Abonnementdaten steuern den Aufbau

Der Sitzungsaufbau hängt stark von den Abonnementdaten ab. Da Mobilitäts- und Sitzungsmanagement getrennt sind, werden auch die UDM-Daten in unterschiedliche logische Bereiche aufgeteilt. Das AMF verwendet mobilitätsbezogene Abonnementdaten, während das SMF die Sitzungsmanagement-Abonnementdaten nutzt. Zusätzlich können dem AMF SMF-Auswahldaten bereitgestellt werden, damit bei einer PDU-Sitzungsanforderung des UE ein geeignetes SMF ausgewählt wird.

Die Abonnementdaten für das Sitzungsmanagement enthalten mehrere wichtige Elemente. S-NSSAI kennzeichnet den abonnierten Slice-Kontext. DNN-Konfigurationen legen fest, wie das UE auf ein Datennetz zugreifen kann. Darin kann das Netz standardmäßige und zulässige PDU-Sitzungstypen, standardmäßige und zulässige SSC-Modi, abonnierte QoS-Informationen, aggregierte Bitratenbegrenzungen auf Sitzungsebene und Abrechnungsmerkmale definieren.

Diese Struktur ermöglicht es, einen Dienst bereits vor dem Aufbau der PDU-Sitzung zu gestalten. Ein UE kann für ein DNN zugelassen sein, für ein anderes jedoch nicht. Es kann IPv4v6 für Internetzugang und einen anderen PDU-Typ für einen Unternehmens- oder Spezialdienst verwenden dürfen. Für ein DNN kann ein standardmäßiger SSC-Modus gelten und für ein anderes eine andere zulässige Modusmenge. Auch unterschiedliche Session-AMBR- und QoS-Profile können entsprechend dem abonnierten Dienst zugewiesen werden.

DNN-Konfigurationen

Die DNN-Konfiguration ist einer der praktischsten Teile der Sitzungsmanagementdaten. Sie bestimmt, wie sich ein bestimmter Datennetz-Name für den Benutzer verhalten soll. Steht das DNN für Internetdienste, kann sich die Richtlinie auf gewöhnliches mobiles Breitband konzentrieren. Steht es für IMS, kann sie signalisierungs- und sprachbezogene QoS unterstützen. Steht es für einen lokalen Dienst, kann es mit LADN-Verhalten und geografischen Beschränkungen verknüpft sein.

Slice-Informationen

S-NSSAI verbindet das Sitzungsmanagement mit Network Slicing. Eine PDU-Sitzung ist nicht nur einem DNN zugeordnet, sondern kann auch einem Slice zugeordnet sein. So kann das Netz verschiedene Dienstkategorien, Geschäftskunden oder Betriebsbereiche mit getrennten Slice-Richtlinien unterstützen.

Bitratenbegrenzung und Abrechnung

Session-AMBR definiert aggregierte Bitratenbegrenzungen auf Ebene der PDU-Sitzung. Auch Abrechnungsmerkmale können Teil des Sitzungsmanagementprofils sein. Diese Parameter sind wichtig, weil Sitzungsmanagement nicht nur Konnektivität, sondern auch Dienststeuerung, Richtliniendurchsetzung und geschäftliche Behandlung umfasst.

PDU-Sitzungen gestalten den Zugang

Eine PDU-Sitzung ist die grundlegende Zugangseinheit, die ein UE über den 5G Core mit einem DN verbindet. Sie enthält Dienstattribute wie DNN, PDU-Sitzungstyp, S-NSSAI, SSC-Modus und PDU-Sitzungs-ID. Nach dem Aufbau dient die Sitzung als Container für einen oder mehrere QoS Flows. Der Benutzerverkehr wird dann anhand von QoS-Regeln, QFI-Werten, Paketfiltern und funkseitiger Zuordnung behandelt.

Dieses Modell ist flexibler als eine einfache dauerhafte Verbindung. Ein UE kann eine PDU-Sitzung erst dann aufbauen, wenn ein Dienst sie benötigt. Es kann getrennte PDU-Sitzungen für Internet und IMS aufbauen. Wenn Abonnement- und Bereichsregeln es erlauben, kann es außerdem eine Sitzung zu einem bestimmten Unternehmens-, lokalen oder Edge-Dienst-DNN herstellen.

Die PDU-Sitzungs-ID identifiziert die Sitzung aus Sicht des UE. Ein UE kann mehrere PDU-Sitzungen besitzen, die jeweils einem anderen DNN, Slice oder Sitzungstyp zugeordnet sind. Beispielsweise kann eine PDU-Sitzung mit dem Internet-DN und eine andere mit dem IMS-DN verbunden sein. Innerhalb dieser Sitzungen können QoS Flows unterschiedliche Dienstanforderungen abbilden.

Auch der PDU-Sitzungstyp erweitert das Zugangsmodell. IPv4, IPv6 und IPv4v6 bleiben bekannte Optionen, während Ethernet- und unstrukturierte PDU-Typen 5G für nicht traditionelle Dienste geeigneter machen. Das ist besonders in Unternehmens- und Industrieumgebungen wichtig, in denen Geräte ein Layer-2-Dienstverhalten oder die Übertragung von Nicht-IP-Nutzdaten benötigen können.

Das Design der PDU-Sitzung beeinflusst außerdem die Sprachverarbeitung im Netz. In einem VoNR-orientierten Dienstmodell kann die IMS-Signalisierung einen Non-GBR-QoS-Flow verwenden, während Audio und Video GBR-QoS-Flows mit unterschiedlichen 5QI-Werten nutzen. Mit dem QoS-Flow-Modell lassen sich Signalisierung, Sprache und Video innerhalb desselben IMS-bezogenen Zugangskontexts unterscheiden, ohne die EPS-Struktur dedizierter Bearer direkt zu kopieren.

SSC-Modi bewahren die Nutzererfahrung

SSC steht für Session and Service Continuity, also Sitzungs- und Dienstkontinuität. Der Begriff umfasst zwei verwandte, aber unterschiedliche Ideen. Sitzungskontinuität bedeutet, dass PDU-Sitzung und UE-IP-Adresse unverändert bleiben. Dienstkontinuität bedeutet, dass die Nutzererfahrung aus Anwendungssicht kontinuierlich bleibt. Wer ein Video ansieht, einen Sprachanruf führt oder einen interaktiven Dienst nutzt, achtet vor allem auf Unterbrechungen, während das Netz zusätzlich wissen muss, ob dieselbe Sitzung und IP-Adresse erhalten bleiben.

Der SSC-Modus legt fest, wie das Netz die Kontinuität behandelt, wenn eine Bewegung des UE einen Wechsel von Pfad, Anker oder Dienstzugang auslöst. 5G definiert drei SSC-Modi. Jeder bietet ein anderes Gleichgewicht zwischen Sitzungs- und Dienstkontinuität sowie Flexibilität der Benutzerebene.

SSC-Modus 1

SSC-Modus 1 bewahrt sowohl die Sitzungs- als auch die Dienstkontinuität. Dieselbe PDU-Sitzung wird beibehalten und die IP-Adresse des UE ändert sich nicht. Dies ist die stärkste Kontinuitätsoption und für Dienste erforderlich, bei denen eine Unterbrechung nicht akzeptabel ist. VoNR ist ein typisches Beispiel, weil Sprachdienste bei Mobilität auf stabile Kontinuität angewiesen sind.

SSC-Modus 2

SSC-Modus 2 bewahrt die Sitzungskontinuität nicht, versucht aber, die Dienstkontinuität aus Nutzersicht zu erhalten. Er verwendet ein Break-before-Make-Verfahren. Die alte PDU-Sitzung wird freigegeben, bevor die neue aufgebaut wird. Das kann für manche Dienste akzeptabel sein, bietet jedoch eine schwächere Nutzererfahrung als die anderen Optionen.

SSC-Modus 3

Auch SSC-Modus 3 bewahrt nicht dieselbe Sitzungskontinuität, verwendet jedoch ein Make-before-Break-Verfahren. Eine neue PDU-Sitzung wird aufgebaut, bevor die alte freigegeben wird. Während des Übergangs kann das UE vorübergehend zwei PDU-Sitzungen halten. In vielen Fällen ist die Nutzererfahrung besser als bei SSC-Modus 2, weil die Dienstunterbrechung reduziert werden kann.

Aus Sicht der Nutzererfahrung bietet SSC-Modus 1 die stärkste Kontinuität, SSC-Modus 3 ist im Allgemeinen besser als SSC-Modus 2, und SSC-Modus 2 ist die ungünstigste der drei Varianten. Das SMF trifft die Auswahl auf Grundlage der UE-Anforderung, der Abonnementdaten und der zulässigen Modusmenge. Nach dem Sitzungsaufbau bleibt der SSC-Modus für diese PDU-Sitzung fest.

LADN begrenzt die lokale Reichweite

LADN steht für Local Area Data Network, also ein lokales Datennetz. Es bezeichnet einen Datennetzdienst, der nur innerhalb eines bestimmten Dienstbereichs verfügbar ist. Dieser Bereich besteht aus einer oder mehreren Tracking Areas. Befindet sich das UE im LADN-Bereich, kann es bei entsprechender Abonnement- und Konfigurationsfreigabe auf das zugehörige DNN zugreifen. Verlässt es den Bereich, kann es den 5G-Dienst dieses DN nicht mehr nutzen.

LADN ist sinnvoll, weil manche Dienste nur in einer lokalen Region relevant sind. Ein autonomer Fahrdienst kann nur innerhalb eines Testgebiets verfügbar sein. Ein Telemedizin-Dienst kann an ein Krankenhausgelände gebunden sein. Eine Fabrikanwendung kann nur auf einem privaten Industriecampus gelten. In solchen Fällen ist das Datennetz kein globaler mobiler Internetdienst, sondern ein lokaler, standortabhängig verfügbarer Dienst.

Sowohl das UE als auch das Netz müssen LADN-bezogene Informationen kennen. Das UE kann so konfiguriert werden, dass es erkennt, ob ein DNN ein LADN-DNN ist und welche Anwendung damit verknüpft ist. Dienstbereich und LADN-DNN werden im AMF pro DN konfiguriert. Das AMF kann dem UE LADN-Informationen während der Registrierung oder bei Konfigurationsaktualisierungen bereitstellen.

Aus Sicht des Sitzungsmanagements besitzt LADN drei Standortzustände. Innerhalb bedeutet, dass sich das UE im LADN-Bereich befindet. Außerhalb bedeutet, dass das UE den LADN-Bereich verlassen hat. Unbekannt kann gelten, wenn sich das UE beispielsweise im Zustand CM-IDLE befindet und das Netz keine genaue aktuelle Positionsangabe besitzt. Das SMF kann anhand von AMF-Informationen bestimmen, ob sich das UE noch im Dienstbereich befindet.

Befindet sich das UE außerhalb des LADN-Dienstbereichs, darf es weder die Aktivierung der Benutzerebene für dieses LADN-DNN noch den Aufbau oder die Änderung einer PDU-Sitzung für dieses DNN anfordern. Liegen dem UE für ein LADN-DNN keine Dienstbereichsinformationen vor, muss es sich als außerhalb des Bereichs betrachten. Erhält das SMF eine LADN-bezogene Sitzungsanforderung ohne gültige Angabe, dass sich das UE im Dienstbereich befindet, behandelt es das UE als außerhalb und weist die Anforderung zurück.

Edge-Pfade benötigen Anker

Die Unterstützung von Edge Computing ist einer der Gründe, warum das 5GC-Sitzungsmanagement ein flexibleres Design der Benutzerebene benötigt. Ein Dienst kann verlangen, dass ein Teil des Verkehrs zu einem entfernten Server geht, während anderer Verkehr lokal bleibt. Gewöhnliche Protokolldaten können beispielsweise an ein entferntes Rechenzentrum gesendet werden, während latenzarmer Steuerverkehr zu einem lokalen Anwendungsserver nahe dem Zugangsnetz geleitet wird.

Das Konzept des PSA, also des PDU Session Anchor, ist hier wichtig. Ein PSA ist ein UPF, das eine PDU-Sitzung verankert und eine N6-Schnittstelle zum Datennetz bereitstellt. Nicht jedes UPF ist automatisch ein PSA. Manche UPFs können andere Aufgaben wie Klassifizierung oder Weiterleitung übernehmen. Das Design der Benutzerebene hängt davon ab, wie die UPFs angeordnet sind und wie der Verkehr lokale oder entfernte DNs erreichen soll.

Zwei Lenkungsmethoden sind wichtig. ULCL, der Uplink Classifier, klassifiziert Uplink-Verkehr anhand von Regeln. Er kann für IPv4- und IPv6-Verkehr eingesetzt werden. Das SMF kann ULCL-Regeln installieren, damit Verkehr, der einem bestimmten Ziel oder einer Dienstklasse entspricht, an den richtigen Zweig gesendet wird. Verkehr zu einem Ziel kann beispielsweise zu einem entfernten Server gehen, während Verkehr zu einem anderen Ziel an einen lokalen Edge-Dienst geleitet wird.

Die zweite Methode ist der Branching-Point -Ansatz, der auf IPv6-Präfixverzweigung basiert. Diese Methode gilt nur für IPv6. Sie ermöglicht die Verkehrslenkung anhand der IPv6-Präfixlogik und eignet sich für Designs, in denen lokale oder entfernte Dienstzweige über IPv6-Adressierung erkannt werden.

Diese Mechanismen machen Edge Computing innerhalb des 5GC-Sitzungsmanagements praktisch nutzbar. Das SMF steuert die Sitzungsregeln, das UPF übernimmt Paketweiterleitung und Klassifizierung, und das PSA stellt den Anker zum DN bereit. Der Dienstpfad kann dadurch nach Verkehrstyp gestaltet werden, anstatt den gesamten Verkehr über einen einzigen entfernten Kernnetzanker zu führen.

QoS Flow erhöht die Granularität

Der QoS Flow ist die wichtigste QoS-Steuerungsgranularität in 5G. Anstelle von EPS Bearern als zentraler Einheit zur Dienstdifferenzierung verwendet 5G durch QFI gekennzeichnete QoS Flows. Jeder QoS Flow kann ein eigenes QoS-Profil tragen und vom gNB einem DRB zugeordnet werden. Die Anzahl der DRBs muss nicht der Anzahl der QFIs entsprechen. Das gNB kann anhand von Funkbedingungen und Richtlinien entscheiden, ob mehrere QoS Flows demselben oder unterschiedlichen DRBs zugeordnet werden.

Ein typisches Dienstbeispiel kann gewöhnliche Internetanwendungen, kooperativen Dienstverkehr und betreibereigene Dienste umfassen. Allgemeiner Anwendungsverkehr kann einen Non-GBR-QoS-Flow nutzen. Anspruchsvollerer Verkehr wie Echtzeit-VR, AR oder Gaming kann einen GBR-QoS-Flow verwenden. VoNR-Audio und -Video können unterschiedliche GBR-QoS-Flows mit dienstspezifischen 5QI-Werten nutzen. Dadurch kann das Netz verschiedene Dienstflüsse detaillierter behandeln.

QoS-Parameter sind auf mehreren Ebenen organisiert. Auf QoS-Flow-Ebene gehören dazu häufig 5QI und ARP. 5QI steht mit Merkmalen wie Prioritätsstufe, Paketverzögerungsbudget, Paketfehlerrate, Mittelungsfenster und maximalem Datenburstvolumen in Verbindung. ARP hilft bei knappen Ressourcen, die Zuweisungs- und Haltepriorität zu bestimmen.

Zu den GBR-Flow-Parametern gehören GFBR, die garantierte Flow-Bitrate, und MFBR, die maximale Flow-Bitrate. Beide sind für GBR-Flows obligatorisch. Benachrichtigungssteuerung und maximale Paketverlustrate können als optionale Parameter hinzukommen. Für Non-GBR-Flows kann RQA, das Reflective QoS Attribute, verwendet werden. Auf einer übergeordneten Begrenzungsebene steuern UE-AMBR und Session-AMBR das Verhalten der aggregierten Bitrate für Non-GBR-Verkehr.

Diese Granularität ist einer der wichtigsten Unterschiede zwischen der 4G-Bearer-Logik und der 5G-Sitzungslogik. Bei 4G VoLTE waren Default und Dedicated Bearer mit APN, QCI, EBI, E-RAB, DRB und Benutzerpfadtunneln verknüpft. In 5G bilden PDU-Sitzung, QFI, QoS-Flow-Typ, N3-Tunnel und DRB-Zuordnung eine andere Struktur. Das Ergebnis ist flexibler, hängt aber stärker von korrekten SMF-Richtlinien, installierten QoS-Regeln und dem Zuordnungsverhalten des gNB ab.

Wie Sitzungen aufgebaut werden

Eine PDU-Sitzung wird nicht isoliert aufgebaut. Das Netz muss mehrere Entscheidungen treffen, bevor die Benutzerebene nutzbar wird. Das UE fordert eine Sitzung mit DNN, PDU-Sitzungstyp und zugehörigen Parametern an. Das AMF transportiert die NAS-SM-Nachricht zum SMF. Das SMF prüft Abonnementdaten, Richtlinien, Slice-Informationen und DNN-Konfiguration. Anschließend wählt es Benutzerressourcen, weist QoS-Regeln zu und steuert die Verbindung der Sitzung zum DN.

Der Ablauf lässt sich als Folge von Entscheidungen verstehen. Erstens prüft das Netz, ob das UE das angeforderte DNN verwenden darf. Zweitens prüft es, ob der angeforderte PDU-Sitzungstyp zulässig ist. Drittens berücksichtigt es über S-NSSAI die Slice-Informationen. Viertens wählt oder bestätigt es den SSC-Modus. Fünftens bestimmt es das UPF oder den Ankerpfad. Sechstens wendet es QoS- und Ratensteuerungsinformationen an.

Das Ergebnis ist eine Sitzung, die mehr als nur einen Tunnel darstellt. Sie enthält Dienstidentität, Datennetzidentität, Benutzerpfad, QoS-Regeln, Kontinuitätsverhalten, Abrechnungsmerkmale und mögliche Bereichsbeschränkungen. Bei lokalen Diensten können LADN-Regeln gelten. Bei Edge Computing können PSA- und ULCL-Verfahren angewendet werden. Bei Sprachdiensten sind IMS und QoS-Flow-Verhalten entscheidend.

Auch nach dem Aufbau kann eine Sitzung geändert werden. Ein QoS Flow kann hinzugefügt oder angepasst werden. Ressourcen der Benutzerebene können aktiviert oder deaktiviert werden. Eine Sitzung kann freigegeben werden, wenn sie nicht mehr benötigt wird, wenn das UE einen Dienstbereich verlässt oder wenn Richtlinien dies verlangen. Da das SMF die Sitzung steuert, ist es die Schlüsselfunktion, die Abonnement- und Richtlinienregeln in reales Datenpfadverhalten umsetzt.

Deshalb erfordert die Fehlersuche bei 5GC-Sitzungen mehr als die Prüfung des Funkzugangs. Ingenieure müssen möglicherweise das Weiterleitungsverhalten des AMF, die SMF-Auswahl, UDM-Daten, DNN-Konfiguration, S-NSSAI, den UPF-Pfad, die Installation von QoS-Regeln, den LADN-Status, den SSC-Modus und N4-Regeln zum UPF prüfen. Ein Fehler in einem dieser Bereiche kann den Sitzungsaufbau verhindern, zu falschem Verhalten führen oder die erwartete QoS-Behandlung beeinträchtigen.

Planungshinweise für Ingenieure

Gute Planung des 5GC-Sitzungsmanagements beginnt mit der Trennung der Dienste. Nicht jeder Dienst sollte dasselbe DNN, denselben Slice, dasselbe QoS-Modell und denselben Kontinuitätsmodus verwenden müssen. Internetzugang, IMS, privater Unternehmenszugang, lokale Campus-Anwendungen, industrieller Steuerverkehr und Edge-Dienste können unterschiedliche Anforderungen haben. Ein sauberes Design sollte diese Unterschiede vor der Konfiguration von DNN und Abonnementdaten identifizieren.

Als Nächstes ist festzulegen, wie viel Sitzungskontinuität benötigt wird. Manche Dienste erfordern eine stabile UE-IP-Adresse und unterbrechungsfreies Sitzungsverhalten. Andere können eine neue Sitzung tolerieren, sofern sich die Anwendung erholt. Manche profitieren von Make-before-Break, andere akzeptieren Break-before-Make. Der SSC-Modus sollte als Dienstdesignentscheidung und nicht nur als Tabellenparameter betrachtet werden.

Die LADN-Planung sollte bei der Dienstgeografie beginnen. Der Dienstbereich muss aus Tracking Areas bestehen, und das AMF muss pro DN mit LADN-DNN- und Dienstbereichsinformationen konfiguriert werden. Auch das UE benötigt die richtige lokale Konfiguration, um ein LADN-DNN und die dazugehörige Anwendung zu erkennen. Fehlen LADN-Dienstbereichsinformationen, muss sich das UE als außerhalb des Bereichs betrachten, wodurch Dienstversuche wie vorgesehen fehlschlagen können.

Die Edge-Planung erfordert eine klare Verkehrslenkungslogik. ULCL-Regeln sollten dem tatsächlichen Anwendungsverkehr entsprechen und nicht vagen Dienstannahmen. Werden lokaler und entfernter Verkehr in einer PDU-Sitzung gemischt, müssen SMF- und UPF-Verhalten sorgfältig konfiguriert werden. PSA-Auswahl, N6-Konnektivität, N9-Pfade und die Platzierung lokaler Server beeinflussen Latenz und Dienstkontinuität.

Die QoS-Planung verdient ebenso viel Aufmerksamkeit. Es reicht nicht, nur einen 5QI-Wert festzulegen. Ingenieure müssen wissen, ob ein Flow GBR oder Non-GBR ist, ob GFBR und MFBR erforderlich sind, ob Session-AMBR und UE-AMBR passen, wie QFI zugewiesen wird und wie das gNB QoS Flows auf DRBs abbildet. Entspricht die Funkzuordnung nicht den Diensterwartungen, kann die Sitzung korrekt aufgebaut sein und dennoch eine schlechte Erfahrung liefern.

Schließlich sollte das Sitzungsmanagement mit realistischen Mobilitäts- und Dienstszenarien getestet werden. Ein statischer Laboranruf weist kein SSC-Verhalten nach. Eine einzelne Internetsitzung belegt keine LADN-Beschränkung. Ein einfacher Durchsatztest beweist keine QoS-Flow-Differenzierung. Zu testen sind Registrierung ohne Sitzungsaufbau, mehrere PDU-Sitzungen, Eintritt und Austritt aus LADN, SSC-Modi, Edge Breakout, Hinzufügen von QoS Flows, Aktivierung der Benutzerebene und Sitzungsfreigabe.

Abschließende technische Betrachtung

Das 5GC-Sitzungsmanagement ist der Teil des Kernnetzes, der Dienstabsichten in Datenkonnektivität umsetzt. Es erstellt und steuert PDU-Sitzungen, wählt DNN-Zugänge, wendet Slice- und Abonnementregeln an, bestimmt den SSC-Modus, verwaltet UPF-Pfade, unterstützt lokale Bereichsbeschränkungen und weist QoS-Flow-Behandlungen zu. Es verleiht 5G die nötige Flexibilität für Smartphones, Sprachdienste, Industriegeräte, Unternehmensnetze, lokale Zugänge und Edge Computing.

Der Übergang von der 4G-Bearer-Logik zur 5G-PDU-Sitzungslogik ist keine bloße Terminologieänderung. Er verändert den Aufbau von Konnektivität, die Trennung von Diensten, die QoS-Anwendung und die Lenkung der Benutzerpfade. Die Trennung von AMF und SMF macht die Architektur modularer. UDM-Abonnementdaten werden strukturierter. SSC-Modi bieten unterschiedliche Kontinuitätsmodelle. LADN ergänzt bereichsabhängigen Dienstzugang. ULCL und PSA ermöglichen Edge-Pfade. QoS Flows ersetzen bearerzentriertes Denken durch eine feinere Dienstklassifizierung.

Am besten lässt sich das 5GC-Sitzungsmanagement verstehen, indem ein Dienst von der Anforderung bis zur Benutzerebene verfolgt wird. Das UE fordert eine PDU-Sitzung an. Das AMF transportiert die Sitzungsnachricht. Das SMF prüft Abonnement, DNN, Slice, PDU-Typ und SSC-Modus. Das UPF erstellt den Pfad zum DN. QoS-Regeln klassifizieren den Verkehr. Das gNB ordnet QoS Flows Funkbearern zu. Änderungen von Mobilität und Standort beeinflussen anschließend Kontinuität, lokalen Dienstzugang und Edge-Routing. Jeder Schritt gehört zur selben Sitzungsmanagementkette.

FAQ

Warum kann sich ein UE registrieren, ohne eine PDU-Sitzung aufzubauen?

Die Registrierung teilt dem Netz nur mit, dass das UE bekannt und erreichbar ist. Eine PDU-Sitzung wird erst für Benutzerdatendienste benötigt. 5G kann daher Ressourcen der Benutzerebene vermeiden, bevor sie nützlich sind.

Warum leitet das AMF NAS-SM-Nachrichten weiter, statt sie vollständig zu verarbeiten?

Das AMF ist für Zugangs- und Mobilitätssteuerung ausgelegt, während das SMF die Sitzungslogik besitzt. Die Weiterleitung der NAS-SM-Signalisierung hält diese Zuständigkeiten getrennt und macht die Architektur modularer.

Warum ist DNN mehr als nur ein umbenannter APN?

DNN ist mit 5G-Sitzungsregeln, Slice-Kontext, PDU-Sitzungstypen, LADN-Verhalten, Richtliniensteuerung und SMF-Auswahl verknüpft und übernimmt daher eine umfassendere Rolle als ein einfacher Zugangsname.

Wann sollte SSC-Modus 3 gegenüber SSC-Modus 2 bevorzugt werden?

SSC-Modus 3 eignet sich, wenn ein Dienst eine geänderte Sitzung tolerieren kann, aber von Make-before-Break profitiert, wodurch Unterbrechungen gegenüber der vorherigen Freigabe der alten Sitzung reduziert werden.

Warum benötigt LADN eine UE-seitige Kenntnis?

Das UE muss wissen, ob ein DNN ein LADN-DNN ist und ob es sich im konfigurierten Dienstbereich befindet, bevor es Sitzungsaufbau, Sitzungsänderung oder Aktivierung der Benutzerebene anfordert.