完全に接続されたUEと完全にアイドル状態のUEの間に、5Gはユーザー側からは静かに見えても、NG-RAN内部では技術的に重要な意味を持つ状態を導入しました。これがRRC Inactiveです。この状態は、5Gの接続管理における実際的な課題を解決するために追加されました。多くの端末はデータ通信へ迅速に戻る必要がありますが、すべての端末を常にRRC Connectedに維持すると、シグナリング資源、無線資源、バッテリー電力を浪費するからです。
スマートフォンがバックグラウンドメッセージを確認したり、センサーが短いデータバーストを送信したり、アプリケーションが長い無通信時間の後に短時間だけ起動したりすることがあります。このようなトラフィックパターンでは、完全にアイドル状態へ戻った後、接続確立を最初から行う必要があるとは限りません。RRC Inactiveは中間層を提供します。UEは活動量を下げながら重要なコンテキストを保持し、上りまたは下りデータが発生したときに、より早く接続を再開できます。
重要なのは、RRC InactiveがRRC Idleと同じではないことです。RRC Idleでは、コアネットワークから見てもUEはCM-IDLEです。一方、RRC InactiveではUEはCM-CONNECTEDのままで、RRC層だけがアクティブな接続動作から一時停止されています。gNodeBはUEコンテキストを保持し、UEはASコンテキストを保持するため、ネットワークはすべてを最初から確立するのではなく、再開手順によってUEをRRC Connectedへ戻せます。
5Gにこの状態が必要な理由
5Gの接続管理は、同時に多様なトラフィックを処理しなければなりません。高スループットと継続接続を必要とするサービスもあれば、短時間で断続的なデータ交換だけを必要とするサービスもあります。また、長時間通信しなくても、ネットワークやアプリケーションから要求されたときには素早く応答しなければならない端末もあります。すべてのUEをRRC Connectedに保つと不要な制御オーバーヘッドが発生し、すべての非アクティブUEを完全にRRC Idleへ移すと、接続復旧が遅くなりシグナリング負荷も増えます。
RRC Inactiveはこの差を縮めます。UEはRRC Connectedとしてのアクティブなデータ処理を停止できますが、重要なアクセスストラタムのコンテキストは破棄されません。そのため、将来の再開手順でより早く接続を復旧できます。ユーザー体験の面では端末が応答性を保ち、ネットワークの面では必要以上にアクティブ資源を保持せずに済みます。
この設計は、頻繁に起動するものの長いセッションを維持しないアプリケーションに特に有効です。メッセージングサービス、バックグラウンド同期、断続的なセンサー報告、小規模な上りデータバースト、短い下り通知などは、接続動作へ素早く戻れる状態の恩恵を受けます。
ネットワークアーキテクチャの観点では、RRC Inactiveは移動管理とページングの一部をNG-RAN側へ移す点でも有用です。AMFは、ローカルなRAN通知エリア内のすべての移動をコアネットワークのモビリティイベントとして扱う必要がありません。gNodeBはUEコンテキストとローカルページングをより効率的に管理できます。
状態の定義
RRC Inactiveにはいくつかの特徴があります。第一に、UEは引き続きCM-CONNECTEDと見なされます。これは、UEがCM-IDLEでもあるRRC Idleとの大きな違いです。RRC接続が通常の接続モードデータをアクティブに運んでいなくても、5Gコアとの接続関係は維持されます。
第二に、この状態はコアネットワークに対してほぼ透過的です。通常動作では、AMFがNG-RANと同じようにRRC Inactiveを直接管理する必要はありません。最後にUEを収容したgNodeBがUEコンテキストを保持し、そのUEが属するRAN Notification Areaを把握します。このコンテキスト保持により高速な復旧が可能になります。
第三に、UEとgNodeBはAS層のコンテキストを保持します。アクセスストラタムのコンテキストが保存されるため、サービス再開時にUEは完全な新規セットアップを行う必要がありません。代わりに、RRC Resume手順を使ってRRC Connectedへ戻れます。
RRC Inactiveへの遷移は、サスペンド設定を含むRRC Releaseメッセージによって行われます。そのため、この状態はサスペンド手順および再開手順と一緒に説明されることが多くあります。ネットワークはアクティブなRRC接続を解放しますが、コンテキストを完全に破棄するのではなく、一時停止するようUEへ指示します。
再び通信が必要になると、UEはRRC InactiveからRRC Connectedへ移行できます。これはUEに送信すべき上りデータがある場合や、下りデータのためのRANページングを受信した場合に起こります。非アクティブ状態が長く続くと、gNodeBのUE Inactivity Timerによって最終的にN2が解放され、UEがRRC IdleおよびCM-IDLEへ移ることがあります。
UEが引き続き実行できる処理
RRC InactiveになってもUEが停止するわけではありません。UEがアクティブなRRC Connectedでなくても、いくつかの手順は実行できます。UEはPLMN選択、システム情報ブロードキャストの受信、セル再選択、RAN起点のページングへの応答を行えます。これにより、完全にアクティブなRRC接続を維持しなくても到達可能な状態を保てます。
ネットワーク側も特定の機能を維持します。NG-RANはRAN Notification Areaを管理し、RANページング向けのDRXを設定し、UEのASコンテキストを保持します。gNodeBはUEがどのRNAに属するかを把握しているため、データやシグナリングによって再開が必要になったとき、ローカルページング範囲を判断できます。
もう一つ重要なのは、この動作モデルではUEのN2およびN3接続コンテキストを維持できることです。これは下りデータが到着したときに重要です。UPFは引き続きgNodeBのアドレスを把握し、下りデータを最後にUEを収容したgNodeBへ転送できます。そのgNodeBは、コアネットワークのページングを最初から実行する代わりに、設定されたRNA内でページングを開始します。
これらの保持要素は、RRC Inactiveが有用である一方、単純なアイドル動作より複雑である理由を示します。ネットワークは高速復旧に必要なコンテキストを十分に保持する必要がありますが、RRC Connectedと同等になるほど多くのアクティブ資源を割り当ててはいけません。このバランスこそが、この状態の価値です。
RNAによるモビリティ制御
RNAはRAN Notification Areaを意味します。RRC InactiveのUEに使用されるRAN側の通知エリアです。RNAは複数のセルで構成され、通常は同じTracking Area内にあります。UEが割り当てられたRNA内を移動する場合、セルが変わるたびにネットワークへ通知する必要はありません。これにより、UEがローカルに移動するだけのときに不要なシグナリングを避けられます。
RNAはRNA IDによって識別されます。この識別子はTACとRAN Area Codeから構成され、RAN Area Codeの範囲は0から255です。実際には、NG-RANが非アクティブUEの頻繁な更新を避けながら移動可能なローカルエリアを簡潔に定義する方法となります。
最後にUEを収容したgNodeBは、RRC Releaseメッセージ内のサスペンド設定を通じてRNA IDを割り当てます。最後のgNodeBがUEのRNAコンテキストを把握する責任を持つため、これは重要な点です。後で下りデータが発生した場合、そのgNodeBは適切なエリア内でUEをどのようにページングするかを決定できます。
一定の条件ではUEがネットワークを更新する必要があります。周期的なRNA更新タイマーが満了した場合、またはUEが設定されたRNAを離れた場合、UEはRNA更新手順を開始します。これにより、RNA内の通常移動に対する過剰なシグナリングを避けながら、NG-RANがUEのローカルエリア情報を失わないようにします。
RNAの設計はページング効率に影響します。RNAが小さすぎるとUEの移動時に頻繁な更新が発生し、大きすぎると下りデータ到着時により多くのセルをページングする必要があり、オーバーヘッドが増えます。したがって、適切な設計にはユーザーの移動パターン、セル配置、gNodeB境界、想定サービス動作を考慮する必要があります。
下りデータの配信方法
下りデータ処理は、RRC Inactiveが存在する理由を最も分かりやすく示す例の一つです。UEがRRC InactiveのときにUPFから下りデータが到着すると、そのデータは最後にUEを収容したgNodeBへ送られます。gNodeBは、UEが非アクティブでもRANレベルのページングによってローカルに到達可能であることを把握しているため、RNA内でページングを開始します。
RNA内のすべてのセルが最後のgNodeBに属する場合、処理は比較的直接的です。gNodeBは対象セルでUEをページングします。UEはRANページングメッセージを受信し、RRC Resume手順を開始してRRC Connectedへ戻ります。再開後、UEは下りデータを受信できます。
RNAに隣接gNodeBが収容するセルが含まれる場合、最後のgNodeBはXnシグナリングを使用できます。隣接gNodeBへXnAP RAN Pagingメッセージを送信し、そのセルでもページングを実行させます。これにより、ページング範囲は最後のgNodeB自身のセルだけに限定されず、RNA全体に従います。
AMFからUE関連の下りシグナリングが到着した場合にも、UE Context Release Commandのように別の処理経路が適用される例外を除き、同じ基本的な考え方が適用されます。重要なのは、NG-RANが非アクティブUEのページングを管理でき、直ちに完全なアイドルモードのコアネットワークページングとして扱う必要がない点です。
サービスの観点では、UEがどれだけ早くページを受信し再開を完了するかがユーザー体験を左右します。ネットワークの観点では、コンテキストの再利用とシグナリングのローカル化によって効率が向上します。
再開遷移の仕組み
RRC InactiveからRRC Connectedへの復帰は、UE側またはネットワーク側のいずれからも開始できます。UEに上りデータやシグナリング要求がある場合、UE起点の遷移が発生します。UEはgNodeBへRRC Resume Requestを送信します。現在のgNodeBが最後にUEを収容したgNodeBでない場合、再開完了前に最後のgNodeBからUEコンテキストを取得する必要があります。
一般的なUE起点手順には、RRC Resume Request、Retrieve UE Context Request、Retrieve UE Context Response、RRC Resume、RRC Resume Completeが含まれます。収容gNodeBが変わる場合には、Xn-U Address IndicationやAMFへのPath Switch Requestなど、追加手順が必要になることがあります。パス切替後、適切な時点で旧コンテキストを解放できます。
ネットワーク起点の遷移は異なる形で始まります。最後にUEを収容したgNodeBが下りデータまたは関連シグナリングを受信し、RANページングを開始します。UEはRNA内でページングされ、ページングを受信するとRRC Inactiveから再開してRRC Connectedへ戻り、保留中のデータやシグナリングを処理します。
これらの遷移は、アイドル状態から完全な接続確立を行うより軽量に設計されています。ただし、単純な処理という意味ではありません。正しい動作には、保存されたコンテキスト、gNodeB間の連携、必要に応じたAMFでのパス切替、新しい収容経路確立後の適切なコンテキスト解放が必要です。
タイマーによる経路も重要です。UEがgNodeBのUE Inactivity Timer方針を超えて非アクティブ状態を続けると、ネットワークはUEをRRC Idleへ移行させることができます。通常はN2解放が行われ、コアネットワークの状態はCM-IDLEへ変わります。その時点でRRC Inactiveの高速再開の利点は失われます。
AMFが状態レポートを受信する仕組み
RRC Inactiveはコアネットワークに対して透過的と説明されることが多いものの、この表現は慎重に解釈する必要があります。一般に、AMFはNG-RANと同じようにUEのRRC状態を直接制御しません。ただしAMFは、NGAPシグナリングを通じてRRC状態遷移の報告を要求できます。
AMFはInitial Context Setup RequestやUE Context Modification RequestなどのメッセージにRRC Inactive Transition Report Requestパラメータを含めることができます。要求が後続状態遷移報告に設定されると、UEがRRC Inactiveへ入る、またはRRC Inactiveから出る際にgNodeBが報告します。
状態変化が起きると、gNodeBはAMFへRRC Inactive Transition Reportを送信します。レポートにはInactiveやConnectedなどのRRC State値が含まれます。この仕組みにより、基本的なRRC Inactive管理がNG-RAN側にあることを変えずに、要求したAMFへ状態の可視性を提供できます。
この報告機能は、ネットワーク連携、ポリシー把握、運用監視に役立ちます。また、RRC Inactiveをコアネットワークから完全に見えない状態と単純に説明すべきではない理由も示しています。より正確には、主にRANが管理し、指定条件下でAMFが状態遷移情報を取得できる状態です。
エンジニアリング分析では、この違いが重要です。手順が失敗した場合、トラブルシューティングではRANの動作とNGAP報告動作の両方を確認する必要があります。UE状態、gNodeBコンテキスト、RNA設定、RANページング、AMFの報告要求、パス切替処理のすべてが最終結果に影響します。
よくある質問
RRC InactiveがRRC Idleと同じではないのはなぜですか？
RRC InactiveではUEがCM-Connectedのままアクセスストラタムのコンテキストを保持します。一方、RRC Idleはコアネットワークとの関係もアイドル状態であり、接続復旧にはより重い手順が必要です。
UEがRRC Inactiveから再開するきっかけは何ですか？
再開は、UEからの上りデータ、UE側のシグナリング要求、または下りデータや対応する下りシグナリングによって発生するRANページングで開始されます。
RNAがシグナリングを削減できるのはなぜですか？
RNAでは、UEが定義されたRAN通知エリア内を移動しても、セルが変わるたびにネットワークへ通知する必要がないため、不要なローカルモビリティシグナリングを削減できます。
UEがRNAを離れるとどうなりますか？
UEはRNA更新手順を開始し、NG-RANがローカルページングと非アクティブ状態の到達性に使用するエリア情報を更新できるようにします。
なぜ隣接gNodeBがページングに関与することがあるのですか？
RNAに隣接gNodeBが収容するセルが含まれる場合、最後にUEを収容したgNodeBはXnAP RAN Pagingを送信し、隣接セルでもUEをページングできるようにします。
AMFはいつRRC状態の変化を把握しますか？
AMFは、対応するNGAP手順でRRC Inactive Transition Report Requestパラメータを使って要求した場合に、状態遷移レポートを受信できます。
RRC Inactiveは、5Gの接続管理における最も実用的な改善の一つです。迅速な再開に必要なコンテキストを保持し、不要なアクティブ接続資源の使用を減らし、RNAによるローカル移動を支え、NG-RANがページングをより効率的に処理できるようにします。その価値はバランスにあります。完全なアイドルから戻るより速く、完全接続を維持するより軽量で、現代のモバイルトラフィックパターンに対応できる柔軟性を備えています。
