目次
- 1. はじめに
- 2. UEのRRC_INACTIVE状態におけるRANベース通知エリア更新手順
- 3. シーケンスチャート
- 4. Uuインターフェースにおけるランダムアクセス手順
- 5. UuインターフェースにおけるRRC接続再開とRNA更新シグナリング
- 6. RNA更新のためのコアネットワーク(5GC)シグナリング
- 7. UEコンテキスト解放コマンド (AMF → gNB_Src)
- 8. 最終状態
- 9. 結論
- 10. 引用文献
1. はじめに
第5世代移動通信システム(5G)では、UE(User Equipment)の電力消費を抑えつつ、データ転送時の遅延を短縮するために、RRC_IDLE状態とRRC_CONNECTED状態の間にRRC_INACTIVE状態が導入されました [1]。このRRC_INACTIVE状態では、UEはネットワークとの無線リソースを解放しつつも、UEとgNB(next generation NodeB)の両方がAS(Access Stratum)コンテキストを保持します [1]。これにより、UEがRRC_CONNECTED状態へ迅速に遷移することが可能となり、特にMTC(Machine Type Communications)のような小規模なデータ伝送に適しています [4]。
本報告書では、RRC_INACTIVE状態にあるUEが、通信を伴わずにセルを移動し、RANベース通知エリア(RNA)の更新を行う際のメッセージシーケンスチャートを示し、その手順と各ステップにおける推測される動作について解説します。この手順は、UEが現在のRNAの外に移動した際にトリガーされ、UEのモビリティ管理とネットワークの効率的な運用を支える重要なプロセスです [2]。
2. UEのRRC_INACTIVE状態におけるRANベース通知エリア更新手順
2.1. 初期状態の概要
本手順が開始される前、UEはRRC_INACTIVE状態にあります。これは、UEが電源オンからSIB(System Information Block)受信を完了し、初期登録を行った後、待機状態にあることを意味します [1]。この状態において、UEはCM-CONNECTED状態にあり、コアネットワーク(CN)との接続は維持されていますが、無線区間の専用リソースは解放されています [1]。UEのASコンテキストは、UE自身と、UEが以前に接続していたgNB(本報告書では「gNB (Source)」と呼称)によって保持されています [1]。また、UEはgNB (Source)によって設定されたRNA(RAN-based Notification Area)内での移動が許可されており、このエリア内であればネットワークに通知することなく移動できます [2]。本シナリオでは、UEはアクティブな通信セッションを持たない状態です。これは、PDUセッションコンテキスト(QoS Flow Information (QFI)やData Radio Bearer (DRB)のマッピングを含む)はSMF(Session Management Function)、UPF(User Plane Function)、UE、およびgNBに保持されているものの、ユーザープレーンのトラフィックは現在流れていないことを示唆しています。
2.2. イベントトリガー
UEはRRC_INACTIVE状態において、RRC_IDLE状態と同様にセル再選択を実行し、周辺セルの測定を行います [1]。このセル再選択の結果、UEが現在設定されているRNAに含まれないセル(本報告書では「gNB (Target)」が提供するセル)に移動した場合、UEはRANベース通知エリア更新(RNAU)手順を開始します [2]。これは、UEの粗い位置情報をネットワークが把握し続けるために不可欠なプロセスです [5]。
3. シーケンスチャート
4. Uuインターフェースにおけるランダムアクセス手順
UEがRNA外の新しいセルに移動した際、最初に新しいgNB(gNB (Target))との無線接続を確立するためにランダムアクセス(RA)手順を実行します。
4.1. Msg1: PRACHプリアンブル (UE → gNB_Tgt)
UEはRA手順を開始するために、PRACHプリアンブル(Physical Random Access Channel Preamble)を送信します [10]。これは、UEがgNB (Target)との同期を確立し、アップリンク(UL)リソースを要求するための最初の物理信号です [1]。PRACHは、UEがネットワークにアクセスするために使用できる唯一のアップリンクチャネルの一つであり、RRC_INACTIVE状態のUEがアップリンクで送信できるのはPRACHのみです [1]。
- 物理シグナル: PRACH Preamble [10]
- 物理チャネル: PRACH [10]
4.2. Msg2: ランダムアクセス応答 (Random Access Response - RAR) (gNB_Tgt → UE)
PRACHプリアンブルの成功した検出後、gNB (Target)はランダムアクセス応答(RAR)で応答します [10]。このメッセージは、ダウンリンク共有チャネル(DL-SCH)で伝送され、物理ダウンリンク共有チャネル(PDSCH)を介して送信されます [10]。PDSCHのスケジューリング情報は、RA-RNTI(Random Access Radio Network Temporary Identifier)によってスクランブルされたCRC(Cyclic Redundancy Check)ビットを持つ物理ダウンリンク制御チャネル(PDCCH)を介して提供されます [11]。RARは、UEにタイミングアドバンス(TA)コマンド(アップリンク同期のため)、RA-RNTI、および後続のMsg3送信のための初期アップリンクグラントを含む重要な情報を提供します [10]。
- 物理チャネル: PDCCH(DCI、RA-RNTIスクランブル用)、PDSCH [10]
- トランスポートチャネル: DL-SCH [11]
4.3. Msg3: RRCResumeRequest (UE → gNB_Tgt)
Msg2で受信したアップリンクグラントを使用して、UEは物理アップリンク共有チャネル(PUSCH)でMsg3を送信します [10]。RNA更新のコンテキストでは、Msg3は3GPP TS 38.331
で定義されているRRCResumeRequest
メッセージを伝送します [1]。このメッセージは、UEがgNB (Target)との専用RRC接続をまだ確立していないため、Common Control Channel(CCCH)論理チャネル上で送信されます [12]。
RRCResumeRequest
メッセージ内の主要な情報要素(IE)は以下の通りです。
-
resumeIdentity: ShortI-RNTI(24ビット)が含まれます [2]。これはgNB (Target)が、UEのコンテキストを以前にサービスしていたgNBから効率的に取得するために使用されます [4]。fullI-RNTI(40ビット)よりもShortI-RNTIが選択されるのは、メッセージサイズを小さく保ち、特にセルエッジのような厳しい無線条件下でも信頼性の高い受信を確保するためです [4]。
-
resumeMAC-I: 既存のASセキュリティ設定を使用して計算されたMAC-I(Message Authentication Code for Integrity)の最下位16ビットを含む認証トークンです [14]。このトークンは、gNB (Target)におけるUEの認証を容易にします。
-
resumeCause: RRC接続再開要求の理由を示し、このシナリオでは
ran-NotificationAreaUpdate
に設定されます [14]。 -
論理チャネル: CCCH [12]
-
トランスポートチャネル: UL-SCH [11]
-
物理チャネル: PUSCH [10]
-
RRCメッセージ:
RRCResumeRequest
(TS 38.331
) [1]
4.4. Msg4: コンテンション解決 (gNB_Tgt → UE)
Msg3の処理後、gNB (Target)はPDSCHでMsg4を送信します [10]。このMACデータメッセージは、特に複数のUEが同じプリアンブルを選択した可能性があるコンテンションベースのランダムアクセスシナリオにおいて、コンテンション解決のために不可欠です [10]。Msg4にはUEの識別子が含まれており、gNB (Target)がUEを正しく識別し、コンテンションが解決されたことを確認します。Msg4の成功した受信とデコード後、ネットワークはUEにC-RNTI(Cell Radio Network Temporary Identifier)を提供します [10]。
- 物理チャネル: PDSCH [10]
- トランスポートチャネル: DL-SCH [12]
- 論理チャネル: MAC CE(コンテンション解決用)
4.5. 最適化された初期アクセス
RRCResumeRequest
がRA手順のMsg3に直接統合されていることは、RRC_INACTIVE状態におけるモビリティ管理の重要な最適化です [10]。RRC_IDLE状態からの完全なRRC接続確立を必要とする汎用的なRRCSetupRequest
とは異なり、ネットワークはUEが中断された接続を再開しようとしている意図を即座に理解できます [10]。この設計により、処理オーバーヘッドとシグナリングステップが削減されます。また、ShortI-RNTIの選択は、この最適化をさらに強化するものです [4]。これにより、重要な再開メッセージが小型に保たれ、厳しい無線条件下でも信頼性の高い伝送が保証され、RRC_INACTIVE状態の低遅延目標に貢献しています [4]。
5. UuインターフェースにおけるRRC接続再開とRNA更新シグナリング
RA手順が完了すると、UEとgNB (Target)はRRC接続の再開とRNAの更新に関するシグナリングを開始します。
5.1. UEコンテキストの取得 (gNB_Tgt ↔ gNB_Src)
RRCResumeRequest
を受信し、RA手順を正常に完了した後、gNB (Target)はI-RNTIを抽出します [14]。gNB (Target)は、この識別子を使用して、UEのASコンテキストを保持している以前のサービスgNB(gNB (Source))を特定します [4]。その後、gNB (Target)はgNB (Source)に対してXn-AP: Retrieve UE Context Request
(TS 38.423
) を開始します [7]。この要求には、I-RNTI、ターゲットセルID、およびRRC再開理由が含まれます。gNB (Source)は、UEの完全なASコンテキスト(ASセキュリティコンテキスト、Allowed NSSAI(Network Slice Selection Assistance Information)、RNA情報を含む)を提供するXn-AP: Retrieve UE Context Response
(TS 38.423
) で応答します [7]。
-
プロトコル: Xn-AP (
TS 38.423
) [18] - インターフェース: Xn [6]
5.2. RRCResume (gNB_Tgt → UE)
gNB (Target)がUEコンテキストを正常に取得および検証した後、UEにRRCResume
メッセージ(TS 38.331
)を送信します [1]。このメッセージは、シグナリング無線ベアラ1(SRB1)上で、確認応答モード(AM)を使用して送信され、信頼性の高い配信を保証します [1]。これにはASセキュリティ設定が含まれており、UEとgNB (Target)は、再利用されたASセキュリティコンテキストを使用して完全性保護と暗号化をアクティブ化できます [16]。UEがRRCResumeRequest
で以前に送信したresumeMAC-I
は、gNBによる初期認証と完全性検証に使用されます [14]。
-
RRCメッセージ:
RRCResume
(TS 38.331
) [1] - 無線ベアラID: SRB1 [1]
- 論理チャネル: DCCH (Dedicated Control Channel) [12]
- トランスポートチャネル: DL-SCH (Downlink Shared Channel) [12]
- 物理チャネル: PDSCH (Physical Downlink Shared Channel) [12]
-
セキュリティ: 既存のASセキュリティコンテキスト(
TS 33.501
)を使用して、完全性保護と暗号化がアクティブ化されます [16]。
5.3. RRCResumeComplete (UE → gNB_Tgt)
UEは、RRCResumeComplete
メッセージ(TS 38.331
)をgNB (Target)に送信することで、RRC接続再開手順の正常な完了を確認します [1]。このメッセージもSRB1上でAMモードを使用して送信されます [1]。この時点で、UEはgNB (Target)とのRRC_CONNECTED状態にあると見なされます。
-
RRCメッセージ:
RRCResumeComplete
(TS 38.331
) [1] - 無線ベアラID: SRB1 [1]
- 論理チャネル: DCCH [12]
- トランスポートチャネル: UL-SCH (Uplink Shared Channel) [12]
- 物理チャネル: PUSCH (Physical Uplink Shared Channel) [12]
5.4. 効率的なRRC状態遷移とセキュリティコンテキストの再利用
RRC_INACTIVE状態の導入は、5G NRにおけるUEのモビリティ管理と電力効率を大幅に向上させます [1]。ASコンテキストがUEとgNBに保持されるため、RRC_IDLE状態からのフル接続確立と比較して、RRC_CONNECTED状態への遷移がはるかに高速になります [1]。これは、シグナリングオーバーヘッドと遅延の削減に直結します [1]。さらに、既存のASセキュリティコンテキストを再利用できる能力は、セキュリティ手順を簡素化し、鍵導出や認証の再実行の必要性を最小限に抑えることで、遷移プロセス全体の効率性を高めます [16]。この設計は、UEが非アクティブ期間中に頻繁にセル間を移動するシナリオにおいて、特に有利に機能します。
6. RNA更新のためのコアネットワーク(5GC)シグナリング
RRC接続がgNB (Target)で再開された後、ネットワークはUEの場所情報をコアネットワーク(5GC)内で更新します。
6.1. UEコンテキスト再開要求 (gNB_Tgt → AMF)
gNB (Target)は、UEとのRRC接続が確立されると、AMF(Access and Mobility Management Function)に対してNGAP: UE Context Resume Request
メッセージ(TS 38.413
)を送信します [23]。このメッセージは、NG-C(N2)インターフェースを介して送信され、UEの移動とRRC接続再開をAMFに通知します [19]。メッセージには、I-RNTI、ターゲットセルID、RRC再開理由、Allowed NSSAI、およびRNA情報が含まれます [1]。このステップにより、AMFはUEの現在のサービスgNBを更新し、UEのモビリティ状態を調整できます。
-
プロトコル: NGAP (
TS 38.413
) [23] - インターフェース: NG-C (N2) [19]
6.2. 加入者データ更新 (AMF ↔ UDM)
AMFは、UEのサービスgNB情報が更新されたことを受けて、UDM(Unified Data Management)に対してNudm_SDM_Update: Subscriber Data Update
サービス操作(TS 29.503
)を開始します [28]。この操作により、UDMに格納されているUEの加入者データ(SUPI(Subscription Permanent Identifier)、サービスAMF ID、サービスPLMN ID、RNA情報など)が更新されます [28]。UDMは更新が完了すると、Nudm_SDM_Update Response
をAMFに返信します [28]。
-
プロトコル:
Nudm_SDM_Update
(TS 29.503
) [28] - インターフェース: Nudm
6.3. PDUセッションコンテキスト更新 (AMF ↔ SMF)
AMFは、PDUセッションの状態をネットワークとUE間で同期する必要がある場合、SMFに対してNsmf_PDUSession_UpdateSMContext Request
メッセージ(TS 29.502
)を送信することがあります [31]。このメッセージはNsmfインターフェースを介して送信され、PDUセッションID、UEの位置情報、UPF(User Plane Function)のN3インターフェース用F-TEID(Fully Qualified Tunnel Endpoint Identifier)などの情報が含まれる場合があります [30]。本シナリオではUEにアクティブな通信がないため、ユーザープレーンパスの確立や変更は通常発生しませんが、SMFはUEの新しい位置を認識し、必要に応じてPDUセッションコンテキストを更新します [30]。SMFは更新が完了すると、Nsmf_PDUSession_UpdateSMContext Response
をAMFに返信します [31]。
-
プロトコル:
Nsmf_PDUSession_UpdateSMContext
(TS 29.502
) [31] - インターフェース: Nsmf
6.4. 最小限のコアネットワークへの影響
RRC_INACTIVE状態におけるUEのモビリティ管理は、フル登録手順と比較して、コアネットワークへの影響を最小限に抑えるように設計されています [1]。AMF、SMF、UPFはUEのコンテキストを保持しているため、UEがRNA内を移動する限り、コアネットワークレベルでの位置更新は不要です [2]。RNA更新が必要な場合でも、AMFとUDM、AMFとSMF間のシグナリングは、UEの完全な登録やPDUセッション確立に比べて限定的です。PDUセッションがアクティブでない場合、QFIからDRBへのマッピングやUPFのデータパスには変更が生じません [3]。これにより、シグナリング負荷が軽減され、UEのモビリティ時のリソース消費が最適化されます。
7. UEコンテキスト解放コマンド (AMF → gNB_Src)
UEのモビリティが完了し、gNB (Target)がUEのサービスを引き継いだ後、AMFは以前のサービスgNB(gNB (Source))に対してNGAP: UE Context Release Command
メッセージ(TS 38.413
)を送信します [23]。このコマンドは、gNB (Source)が保持していたUEコンテキストと関連リソースを解放するよう指示します [36]。通常、解放の理由は「UE relocated(UEが移動した)」と示されます。gNB (Source)はリソースの解放が完了すると、NGAP: UE Context Release Complete
メッセージ(TS 38.413
)をAMFに返信します。
-
プロトコル: NGAP (
TS 38.413
) [23] - インターフェース: NG-C (N2) [19]
8. 最終状態
この一連のRNA更新手順が完了すると、UEはgNB (Target)との間でRRC_CONNECTED状態にあります。UEのCM状態は引き続きCM-CONNECTEDであり、コアネットワークはUEが新しいgNB (Target)の管轄下にあることを認識しています。RNA情報はネットワーク内で適切に更新され、UEは新しいRNA内でのモビリティを継続できます。
9. 結論
本報告書で詳述したRRC_INACTIVE状態におけるRNA更新手順は、5Gシステムにおける効率的なモビリティ管理とリソース最適化の実現に不可欠な要素です。UEがRRC_INACTIVE状態から新しいセルに移動し、RNA外に出た際に、RRCResumeRequest
メッセージをRA手順のMsg3に統合することで、迅速なRRC接続再開が可能となります。この設計は、ASコンテキストの保持と既存のセキュリティコンテキストの再利用と相まって、RRC_IDLE状態からのフル接続確立に比べて、シグナリングオーバーヘッドと遅延を大幅に削減します。
コアネットワーク側では、AMFとUDM、AMFとSMF間の限定的なシグナリングにより、UEの場所情報が効率的に更新され、PDUセッションコンテキストの同期が維持されます。PDUセッションがアクティブでない場合、UPFのデータパスへの影響は最小限に抑えられ、ネットワーク全体の負荷が軽減されます。
RRC_INACTIVE状態とそれに伴うRNA更新メカニズムは、UEの電力消費を抑えつつ、ユーザー体験を損なうことなく、より応答性の高いネットワークアクセスを可能にする5G NRの重要な特徴です。これは、特にIoTデバイスや間欠的な通信を必要とするアプリケーションにとって、大きな利点をもたらします。この最適化されたモビリティ管理は、5Gネットワークの拡張性と効率性を支える基盤となっています。
10. 引用文献
- UE RRC States and State Transitions - How LTE Stuff Works?: 5G NR
- RRC Inactive state in 5G-NR - Techlteworld
- RRC CONNECTED <-> INACTIVE Transition - 5G | ShareTechnote
- 5G NR Inactive-RNTI (I-RNTI) for RRC_INACTIVE State - Techplayon
- WO2018145661A1 - Mobility management for rrc_inactive user equipment - Google Patents
- RNA - RAN Based Notification Area - Mpirical
- 5G NR Mobility – RRC Inactive - Itelcotech
- inside TS 38.300: Mobility in RRC_INACTIVE - Tech-invite
- 5G NR RRC Inactive State - 3G4G
- Random Access - NR Explained
- 5G NR RACH - 5G | ShareTechnote
- LTE channel mapping | logical,transport,physical channels - RF Wireless World
- 5G Physical And MAC Layer Procedures Part-2 Updated In 2024 - Apeksha Telecom
- 38.331 RRC - NR Explained
- Channel mapping - NR Explained
- US10555168B2 - Security handling for RRC resume from inactive state - Google Patents
- TS 138 300 - V15.10.0 - 5G; NR - ETSI
- TS 138 413 - V15.1.0 - 5G; NG-RAN - ETSI
- 單元2 5G行動網路技術
- Specification # 33.501 - 3GPP
- TS 33.501 Security Architecture and Procedures for 5G System - Tech-invite
- TS 133 501 - V16.9.1 - 5G; Security architecture and ... - ETSI
- NGAP/NAS Server - Black Duck
- 3GPP TS 38.413 | PDF | 3 Gpp | Computer Standards - Scribd
- 3GPP TS 29.413
- Specification # 38.413 - 3GPP
- Access and Mobility Management Function [1] - Magma India Documentation!
- Specification # 29.503 - 3GPP
- inside TS 29.503: Scope, References, Definitions, Abbreviations - Tech-invite
- inside TS 23.502: User Profile management procedures - Tech-invite
- Specification # 29.502 - 3GPP
- inside TS 29.502: Content Part, 2 out of 45 - Tech-invite
- 3GPP TS 23.502
- inside TS 23.502: 5GS PDU Session Modification procedures - Tech-invite
- RrcReconfiguration - 5G | ShareTechnote
- inside TS 23.502: 5GS AN Release procedure - Tech-invite