Zwischen einem vollständig verbundenen UE und einem vollständig inaktiven UE führt 5G einen Zustand ein, der aus Nutzersicht ruhig erscheint, innerhalb des NG-RAN jedoch technisch weiterhin von Bedeutung ist. Dieser Zustand heißt RRC Inactive. Er wurde in das 5G-Verbindungsmanagement aufgenommen, um ein praktisches Problem zu lösen: Viele Geräte müssen schnell zur Datenübertragung zurückkehren, doch würden alle Geräte dauerhaft in RRC Connected gehalten, würden Signalisierungsressourcen, Funkressourcen und Akkuleistung verschwendet.
Ein Smartphone kann Hintergrundnachrichten prüfen, ein Sensor kurze Datenpakete senden und eine Anwendung nach einer längeren Ruhephase kurz aufwachen. Solche Verkehrsmuster rechtfertigen nicht immer eine vollständige Rückkehr in den Ruhezustand mit anschließendem vollständigem Verbindungsaufbau. RRC Inactive bildet eine Zwischenstufe. Das UE kann seine Aktivität reduzieren, wichtigen Kontext beibehalten und die Verbindung schneller fortsetzen, sobald Uplink- oder Downlink-Daten anstehen.
Wichtig ist, dass RRC Inactive nicht mit RRC Idle gleichzusetzen ist. In RRC Idle befindet sich das UE aus Sicht des Kernnetzes ebenfalls in CM-IDLE. In RRC Inactive bleibt das UE dagegen in CM-CONNECTED, während die RRC-Schicht gegenüber dem aktiven verbundenen Betrieb ausgesetzt ist. Der gNodeB behält den UE-Kontext, das UE den AS-Kontext, und das Netz kann das UE über ein Wiederaufnahmeverfahren nach RRC Connected zurückführen, ohne sämtliche Schritte neu zu beginnen.
Warum 5G diesen Zustand benötigt
Das 5G-Verbindungsmanagement muss gleichzeitig viele Verkehrsarten bedienen. Manche Dienste benötigen hohen Durchsatz und eine dauerhafte Verbindung. Andere erfordern nur kurze, gelegentliche Datenübertragungen. Einige Endgeräte bleiben lange still, müssen aber schnell reagieren, sobald Netz oder Anwendung sie benötigen. Würde jedes UE in RRC Connected gehalten, entstünde unnötiger Steuerungsaufwand. Würde jedes inaktive UE vollständig nach RRC Idle verschoben, könnte die Wiederherstellung langsamer und signalisierungsintensiver werden.
RRC Inactive schließt diese Lücke. Das UE kann die aktive Datenverarbeitung im Sinne von RRC Connected beenden, ohne dass wichtiger Access-Stratum-Kontext verworfen wird. Ein späteres Wiederaufnahmeverfahren kann die Verbindung daher schneller wiederherstellen. Aus Nutzersicht bleibt das Gerät reaktionsfähig. Aus Netzsicht werden aktive Ressourcen nicht länger als erforderlich gehalten.
Diese Auslegung eignet sich besonders für Anwendungen, die häufig aufwachen, aber keine langen Sitzungen aufrechterhalten. Nachrichtendienste, Hintergrundsynchronisation, sporadische Sensorberichte, kleine Uplink-Datenbursts und kurze Downlink-Benachrichtigungen profitieren von einem Zustand, der eine schnellere Rückkehr in den verbundenen Betrieb ermöglicht.
Aus Sicht der Netzarchitektur ist RRC Inactive außerdem nützlich, weil ein Teil der Mobilitäts- und Paging-Verantwortung auf das NG-RAN verlagert wird. Das AMF muss nicht jede Bewegung innerhalb eines lokalen RAN Notification Area als Mobilitätsereignis des Kernnetzes behandeln. Der gNodeB kann UE-Kontext und lokales Paging effizienter verwalten.
Wie der Zustand definiert ist
RRC Inactive besitzt mehrere kennzeichnende Eigenschaften. Erstens gilt das UE weiterhin als CM-CONNECTED. Dies ist ein wesentlicher Unterschied zu RRC Idle, wo sich das UE zugleich in CM-IDLE befindet. Die Verbindungsbeziehung zum 5G-Kernnetz bleibt bestehen, obwohl die RRC-Verbindung keine normalen Daten des verbundenen Modus aktiv überträgt.
Zweitens ist der Zustand für das Kernnetz weitgehend transparent. Im Normalbetrieb muss das AMF RRC Inactive nicht auf dieselbe Weise direkt verwalten wie das NG-RAN. Der zuletzt bedienende gNodeB hält den UE-Kontext und kennt das RAN Notification Area, dem das UE zugeordnet ist. Diese Kontexterhaltung ermöglicht die schnelle Wiederaufnahme.
Drittens behalten UE und gNodeB den Kontext der AS-Schicht. Weil der Access-Stratum-Kontext erhalten bleibt, benötigt das UE bei Wiederaufnahme des Dienstes keinen vollständig neuen Aufbau. Stattdessen kann es über ein RRC-Resume-Verfahren nach RRC Connected zurückkehren.
Der Übergang nach RRC Inactive erfolgt durch eine RRC-Release-Nachricht mit Suspend-Konfiguration. Deshalb wird dieser Zustand häufig zusammen mit Suspend- und Resume-Verfahren erläutert. Das Netz gibt die aktive RRC-Verbindung frei, weist das UE jedoch an, seinen Kontext auszusetzen, statt ihn vollständig zu verwerfen.
Wird erneut Aktivität benötigt, kann das UE von RRC Inactive nach RRC Connected wechseln. Dies geschieht, wenn das UE Uplink-Daten senden muss oder wegen Downlink-Daten ein RAN-Paging empfängt. Hält die Inaktivität zu lange an, kann der UE Inactivity Timer des gNodeB schließlich eine N2-Freigabe auslösen und das UE in Richtung RRC Idle und CM-IDLE verschieben.
Was das UE weiterhin tun kann
RRC Inactive bedeutet nicht, dass das UE eingefroren ist. Auch wenn es nicht aktiv in RRC Connected arbeitet, bleiben mehrere Verfahren möglich. Das UE kann eine PLMN-Auswahl durchführen, ausgestrahlte Systeminformationen empfangen, Zellen neu auswählen und auf vom RAN ausgelöstes Paging reagieren. Dadurch bleibt das UE erreichbar, ohne eine vollständig aktive RRC-Verbindung aufrechtzuerhalten.
Auch die Netzseite bleibt in bestimmter Weise aktiv. Das NG-RAN verwaltet das RAN Notification Area, konfiguriert DRX für RAN-Paging und behält den AS-Kontext des UE. Der gNodeB kennt das RNA des UE und kann daher den lokalen Paging-Bereich festlegen, wenn Daten oder Signalisierung eine Wiederaufnahme erfordern.
Ein weiterer wichtiger Punkt ist, dass N2- und N3-Verbindungskontext in diesem Betriebsmodell für das UE bestehen bleiben kann. Das ist relevant, wenn Downlink-Daten eintreffen. Die UPF kann die Adresse des gNodeB weiterhin kennen und Daten an den zuletzt bedienenden gNodeB weiterleiten. Dieser löst dann Paging innerhalb des konfigurierten RNA aus, statt ein Paging-Verfahren des Kernnetzes vollständig neu zu starten.
Diese erhaltenen Elemente erklären, weshalb RRC Inactive nützlich, aber auch komplexer als einfaches Idle-Verhalten ist. Das Netz muss genug Kontext für eine schnelle Wiederherstellung behalten, darf jedoch nicht so viele aktive Ressourcen reservieren, dass der Zustand RRC Connected entspricht. Der Wert des Zustands liegt in diesem Ausgleich.
Wie RNA die Mobilität steuert
RNA steht für RAN Notification Area. Es handelt sich um einen RAN-seitigen Benachrichtigungsbereich für UE in RRC Inactive. Ein RNA besteht aus mehreren Zellen, in der Regel innerhalb derselben Tracking Area. Bewegt sich ein UE innerhalb seines zugewiesenen RNA, muss es das Netz nicht bei jedem Zellwechsel informieren. So wird unnötige Signalisierung bei rein lokalen Bewegungen vermieden.
Das RNA wird durch eine RNA ID gekennzeichnet. Die Kennung setzt sich aus TAC und RAN Area Code zusammen. Der Wertebereich des RAN Area Code liegt zwischen 0 und 255. Praktisch erhält das NG-RAN damit eine kompakte Möglichkeit, lokale Bereiche zu definieren, in denen sich inaktive UE ohne häufige Aktualisierungen bewegen können.
Der zuletzt bedienende gNodeB weist die RNA ID über die Suspend-Konfiguration in der RRC-Release-Nachricht zu. Dieses Detail ist wichtig, weil der gNodeB, der das UE zuletzt bedient hat, den RNA-Kontext des UE kennen muss. Treffen später Downlink-Daten ein, kann dieser gNodeB festlegen, wie das UE im richtigen Bereich zu paginieren ist.
Unter bestimmten Bedingungen muss das UE das Netz dennoch aktualisieren. Läuft der periodische RNA-Aktualisierungstimer ab oder verlässt das UE das konfigurierte RNA, sollte es das RNA-Aktualisierungsverfahren starten. Dadurch behält das NG-RAN verwertbare Kenntnis über den lokalen Aufenthaltsbereich, ohne bei normalen Bewegungen im RNA übermäßige Signalisierung zu erzeugen.
Die Auslegung des RNA beeinflusst die Paging-Effizienz. Ein sehr kleines RNA kann bei Bewegungen häufige Aktualisierungen verursachen. Ein sehr großes RNA kann den Paging-Aufwand erhöhen, weil bei Downlink-Daten möglicherweise mehr Zellen paginiert werden müssen. Eine gute Planung hängt deshalb von Mobilitätsmustern, Zellanordnung, gNodeB-Grenzen und erwartetem Dienstverhalten ab.
Wie Downlink-Daten zugestellt werden
Die Behandlung von Downlink-Daten ist eines der deutlichsten Beispiele für den Zweck von RRC Inactive. Treffen Downlink-Daten von der UPF ein, während sich das UE in RRC Inactive befindet, können sie an den zuletzt bedienenden gNodeB gesendet werden. Der gNodeB startet anschließend Paging im RNA, weil er weiß, dass das UE inaktiv, über RAN-seitiges Paging jedoch lokal erreichbar ist.
Gehören alle Zellen des RNA zum zuletzt bedienenden gNodeB, ist das Verfahren vergleichsweise direkt. Der gNodeB paginiert das UE in den betreffenden Zellen. Das UE empfängt die RAN-Paging-Nachricht, startet RRC Resume und kehrt nach RRC Connected zurück. Nach der Wiederaufnahme kann es die Downlink-Daten empfangen.
Enthält das RNA Zellen benachbarter gNodeB, kann der zuletzt bedienende gNodeB Xn-Signalisierung verwenden. Er kann dem benachbarten gNodeB eine Nachricht XnAP RAN Paging senden, damit auch in diesen Zellen gepaginiert wird. Dadurch folgt der Paging-Bereich dem RNA und bleibt nicht auf die eigenen Zellen des zuletzt bedienenden gNodeB beschränkt.
Dasselbe Grundprinzip gilt, wenn UE-bezogene Downlink-Signalisierung vom AMF eintrifft, ausgenommen Fälle wie UE Context Release Command, für die ein anderer Behandlungsweg gilt. Entscheidend ist, dass das NG-RAN das Paging eines inaktiven UE verwalten kann, ohne es sofort als vollständigen Kernnetz-Paging-Fall im Idle-Modus zu behandeln.
Aus Dienstsicht hängt die Nutzererfahrung davon ab, wie schnell das UE das Paging empfängt und die Wiederaufnahme abschließt. Aus Netzsicht profitiert das System von wiederverwendetem Kontext und stärker lokalisierter Signalisierung.
Wie Resume-Übergänge funktionieren
RRC Inactive kann sowohl UE-seitig als auch netzseitig nach RRC Connected zurückkehren. Ein UE-ausgelöster Übergang erfolgt, wenn das UE Uplink-Daten oder Signalisierungsbedarf hat. Das UE sendet eine RRC Resume Request an den gNodeB. Ist der aktuelle gNodeB nicht der zuletzt bedienende, muss er möglicherweise vor Abschluss der Wiederaufnahme den UE-Kontext vom letzten gNodeB abrufen.
Ein typischer UE-ausgelöster Ablauf kann RRC Resume Request, Retrieve UE Context Request, Retrieve UE Context Response, RRC Resume und RRC Resume Complete umfassen. Ändert sich der bedienende gNodeB, können zusätzliche Verfahren wie Xn-U Address Indication und Path Switch Request zum AMF erforderlich sein. Nach erfolgtem Pfadwechsel kann der alte Kontext bei Bedarf freigegeben werden.
Der netzseitig ausgelöste Übergang beginnt anders. Der zuletzt bedienende gNodeB erhält Downlink-Daten oder relevante Signalisierung und startet RAN-Paging. Das UE wird innerhalb des RNA paginiert. Nach Empfang des Paging nimmt es die Verbindung aus RRC Inactive wieder auf und kehrt nach RRC Connected zurück, damit ausstehende Daten oder Signalisierung verarbeitet werden können.
Diese Übergänge sind leichter ausgelegt als ein vollständiger Verbindungsaufbau aus dem Idle-Zustand. Das bedeutet nicht, dass sie trivial sind. Korrektes Verhalten hängt von gespeichertem Kontext, gNodeB-Koordination, gegebenenfalls Pfadwechsel im AMF und sauberer Kontextfreigabe nach Aufbau des neuen Bedienpfads ab.
Auch der Timer-Pfad ist wichtig. Bleibt das UE länger inaktiv, als es die UE-Inactivity-Timer-Richtlinie des gNodeB vorsieht, kann das Netz es nach RRC Idle verschieben. Dies umfasst üblicherweise eine N2-Freigabe und ändert den Kernnetzzustand in CM-IDLE. Ab diesem Punkt gelten die Vorteile der schnellen Wiederaufnahme von RRC Inactive nicht mehr.
Wie das AMF Zustandsberichte erhält
RRC Inactive wird häufig als für das Kernnetz transparent beschrieben, doch diese Aussage muss sorgfältig ausgelegt werden. Im Allgemeinen steuert das AMF den RRC-Zustand des UE nicht direkt wie das NG-RAN. Es kann jedoch über NGAP-Signalisierung Berichte zu RRC-Zustandsübergängen anfordern.
Das AMF kann einen Parameter RRC Inactive Transition Report Request in Nachrichten wie Initial Context Setup Request oder UE Context Modification Request aufnehmen. Ist die Anforderung auf nachfolgende Zustandsübergänge gesetzt, sollte der gNodeB melden, wenn das UE RRC Inactive betritt oder verlässt.
Bei einer Zustandsänderung sendet der gNodeB einen RRC Inactive Transition Report an das AMF. Der Bericht enthält den Wert RRC State, beispielsweise Inactive oder Connected. Damit erhält das AMF auf Anforderung Sichtbarkeit, ohne die Grundtatsache zu ändern, dass das NG-RAN das RRC-Inactive-Verhalten verwaltet.
Diese Berichtsfunktion ist für Netzkoordination, Richtlinienkenntnis und Betriebsüberwachung hilfreich. Sie erklärt auch, weshalb RRC Inactive nicht vereinfacht als vollständig unsichtbar für das Kernnetz beschrieben werden sollte. Treffender ist, dass der Zustand hauptsächlich vom RAN verwaltet wird, während das AMF unter festgelegten Bedingungen Informationen zu Zustandsübergängen erhalten kann.
Für technische Analysen ist diese Unterscheidung wichtig. Scheitert ein Verfahren, muss die Fehlersuche möglicherweise sowohl das RAN-Verhalten als auch die NGAP-Berichterstattung untersuchen. UE-Zustand, gNodeB-Kontext, RNA-Konfiguration, RAN-Paging, AMF-Berichtsanforderung und Pfadwechsel können das Endergebnis beeinflussen.
Häufig gestellte Fragen
Warum ist RRC Inactive nicht dasselbe wie RRC Idle?
RRC Inactive hält das UE in CM-Connected und bewahrt den Access-Stratum-Kontext, während RRC Idle eine Idle-Beziehung zum Kernnetz darstellt, bei der die Verbindungswiederherstellung ein umfangreicheres Verfahren erfordert.
Was löst die Wiederaufnahme aus RRC Inactive aus?
Die Wiederaufnahme kann durch Uplink-Daten des UE, einen Signalisierungsbedarf des UE oder RAN-Paging aufgrund von Downlink-Daten beziehungsweise unterstützter Downlink-Signalisierung ausgelöst werden.
Warum reduziert RNA die Signalisierung?
RNA erlaubt dem UE, sich innerhalb eines definierten RAN-Benachrichtigungsbereichs zu bewegen, ohne jeden Zellwechsel dem Netz zu melden, und verringert damit unnötige lokale Mobilitätssignalisierung.
Was geschieht, wenn das UE sein RNA verlässt?
Das UE sollte ein RNA-Aktualisierungsverfahren starten, damit das NG-RAN die Bereichsinformationen für lokales Paging und Erreichbarkeit im inaktiven Zustand aktualisieren kann.
Warum können benachbarte gNodeB am Paging beteiligt sein?
Enthält das RNA Zellen benachbarter gNodeB, kann der zuletzt bedienende gNodeB XnAP RAN Paging senden, damit auch diese Nachbarzellen das UE paginieren.
Wann erfährt das AMF von RRC-Zustandsänderungen?
Das AMF kann Zustandsübergangsberichte erhalten, wenn es sie über den Parameter RRC Inactive Transition Report Request in unterstützten NGAP-Verfahren angefordert hat.
RRC Inactive ist eine der praktischsten Verbesserungen des 5G-Verbindungsmanagements. Der Zustand bewahrt genug Kontext für eine schnelle Wiederaufnahme, reduziert unnötige Nutzung aktiver Verbindungsressourcen, unterstützt lokale Bewegung über RNA und ermöglicht dem NG-RAN effizienteres Paging. Sein Wert liegt im Gleichgewicht: schneller als die Rückkehr aus vollständigem Idle, leichter als dauerhaft vollständig verbunden zu bleiben und flexibel genug für moderne mobile Verkehrsmuster.
