目次

1. はじめに
2. UEの初期状態と接続管理
- 2.1 RRC_IDLE状態とRRC_INACTIVE状態
- 2.2 5GMM-REGISTERED状態
3. シーケンスチャート
4. メッセージシーケンスの詳細な説明と推測
5. 結論
引用文献

1. はじめに

本報告書は、5Gユーザー機器（UE）がすでに初期登録を完了し、待機状態（アイドル/非アクティブ）にある状況でウェブ閲覧セッションを開始する際のメッセージシーケンスについて、包括的な分析を提供するものです。高性能かつ全機能が揃った5Gシステムにおけるシグナリングとデータフローの詳細に焦点を当て、3GPP技術仕様に厳密に準拠しています。シーケンスはアプリケーションによるインターネットアクセス要求から始まり、ウェブデータの転送成功で完結します。詳細なシーケンスチャートと、各メッセージに対する具体的な説明および推測を付記することで、電気通信専門家にとって正確な理解を提供することを目指します。

1.1 シナリオ概要：待機状態からのUEウェブ閲覧

このシナリオでは、UEが5Gコア（5GC）への初期登録を正常に完了し、システム情報ブロック（SIB）を取得していることを前提としています。UEは現在、省電力の待機モード、具体的にはRRC_INACTIVE状態にあります。この状態は、RRC_IDLE状態と比較してRRC_CONNECTED状態へのより迅速な移行を可能にします。RRC_INACTIVEは、ユーザーが開始するデータ通信に対する応答性と消費電力のバランスを取るための一般的な最適化であるため、この状態が選択されています。

1.2 報告書の目的と範囲

本報告書の主な目的は、5Gスタンドアローン（SA）ネットワークにおける一般的なウェブ閲覧セッションのエンドツーエンドのシグナリングとデータフローを綿密にマッピングすることです。これには、待機RRC状態からの移行、必要な無線およびコアネットワーク接続の確立、認証、セキュリティアクティベーション、PDUセッション管理、および実際のユーザープレーンデータ転送が含まれます。本報告書は、メッセージ、インターフェース、プロトコル、チャネルに関する3GPPの命名規則に厳密に準拠し、ネットワークアーキテクト、エンジニア、研究者にとっての基礎的な理解を提供します。

1.3 使用される3GPP技術仕様とバージョン

正確性と関連性を確保するため、本報告書では、執筆時点で利用可能な主要な3GPP技術仕様の最新安定版を参照しています。これらの文書は、5Gシステム設計と運用の権威ある基盤を形成しています。

表1：使用される3GPP技術仕様とバージョン

仕様番号	タイトル	最新安定版	リリース	参照スニペット
TS 38.331	NR; Radio Resource Control (RRC); Protocol specification	V18.4.0	Release 18	1
TS 38.300	NR; NR and NG-RAN Overall description; Stage-2	V18.4.0	Release 18	3
TS 24.501	5G; Non-Access-Stratum (NAS) protocol for 5G System (5GS); Stage 3	V17.11.0	Release 17	4
TS 23.501	5G; System architecture for the 5G System (5GS)	V17.7.0	Release 17	5
TS 23.502	5G; Procedures for the 5G System (5GS); Stage 2	V18.6.0	Release 18	6

2. UEの初期状態と接続管理

本シナリオでは、UEはすでに5Gネットワークへの初期登録プロセスを完了し、待機状態にあります。この「待機状態」は、5GシステムにおけるUEの接続管理状態を指し、特にRRC_IDLEまたはRRC_INACTIVEのいずれかであると想定されます。ウェブ閲覧のようなユーザー主導のデータ通信では、RRC_INACTIVE状態が選択されることが多く、これはRRC_IDLEよりも迅速なデータ転送再開を可能にするためです。

2.1 RRC_IDLE状態とRRC_INACTIVE状態

5G NR（New Radio）では、UEの無線リソース制御（RRC）状態は、RRC_IDLE、RRC_INACTIVE、およびRRC_CONNECTEDの3つに大別されます。RRC_IDLE状態では、UEは最小限の電力消費で動作し、ネットワークはUEの正確なセル位置を認識していません。UEはシステム情報をブロードキャストで受信し、セル再選択モビリティを処理し、5GCからページングされます [3]。

一方、RRC_INACTIVE状態は、RRC_CONNECTED状態のサブ状態として位置づけられます。この状態に移行すると、UEはRAN通知エリア（RNA）を認識し、定期的なRNA更新タイマーを使用します。ネットワーク側では、UEの非アクティブなAS（Access Stratum）コンテキストがNG-RANとUEに保存され、5GCはUEがRRC_CONNECTEDとRRC_INACTIVEの間で移行しても、明示的なN2通知手順がない限り、その移行を認識しないことが一般的です [3]。この特性は、UEが頻繁に短いデータバーストを送受信するようなアプリケーション（例：ウェブ閲覧、SNS更新）において、RRC接続の確立にかかるレイテンシを大幅に削減できるという利点をもたらします。RRC_INACTIVE状態は、UEがRRC_IDLE状態に移行することなく、無線リソースを解放しつつ、迅速な再接続を可能にするための重要な最適化です。

2.2 5GMM-REGISTERED状態

UEはすでに初期登録を完了しているため、5Gモビリティ管理（5GMM）の観点からは「5GMM-REGISTERED」状態にあります。この状態は、UEが5Gシステムに正常に登録され、モビリティ管理機能（AMF）によってそのモビリティコンテキストが管理されていることを意味します [8]。ウェブ閲覧を開始する際、UEは5GMM-REGISTERED状態を維持しつつ、ユーザープレーン接続をアクティブにするための「サービス要求」手順を開始します。この手順は、UEがCM-IDLE状態またはRRC非アクティブ表示を伴うCM-CONNECTED状態にある場合に、サービスにアクセスするためにCM-CONNECTED状態に移行する必要があるときに使用されます [4]。

3. シーケンスチャート

本セクションでは、UEのウェブブラウザアプリケーションがインターネットのウェブサイトを閲覧する際のメッセージシーケンスを示します。

4. メッセージシーケンスの詳細な説明と推測

本セクションでは、上記のシーケンスチャートに示された各メッセージについて、詳細な説明と技術的な推測を提供します。

4.1 接続確立フェーズ：RRC_INACTIVEからRRC_CONNECTEDへの移行

Application -> 5G Modem: HTTP GET Request (URL)

説明: ユーザーがウェブブラウザアプリケーションでURLを入力し、ウェブサイトへのアクセスを試みると、アプリケーションはHTTP GETリクエストをUEの5Gモデム（NASレイヤー）に送信します。これは、UEがアップリンクデータを送信する必要があることを示します。
推測: UEは現在RRC_INACTIVE状態にあり、ユーザープレーンは非アクティブ化されています。このアップリンクデータ要求が、UEがRRC_CONNECTED状態に移行するためのトリガーとなります。

5G Modem -> gNB: RRC Resume Request (TS 38.331, C-RNTI, Resume ID, RRC_INACTIVE_AS_Context, Cause: "Uplink Data")

説明: アプリケーションからのデータ要求を受け、5GモデムはRRCレイヤーでRRC接続再開手順を開始します。UEは、以前にRRC_INACTIVE状態に移行する際にgNBから受信し、保存していた「UE非アクティブASコンテキスト」を利用して、RRC Resume RequestメッセージをgNBに送信します [2]。このメッセージには、UEのC-RNTI（Cell-Radio Network Temporary Identifier）、Resume ID、および再開の理由（例：「Uplink Data」）が含まれます。
チャネル: このメッセージは、専用制御チャネル（DCCH）を介してシグナリング無線ベアラー1（SRB1）で送信されます。SRB1は、RRC接続確立後にRRCメッセージとNASメッセージを伝送するために使用されます [9]。
推測: RRC_INACTIVE状態は、UEのASコンテキストがgNBに保持されているため、RRC_IDLE状態からの完全なRRC接続確立手順（Random Access Procedureなど）を回避し、より迅速な接続再開を可能にします。これにより、ウェブ閲覧のようなインタラクティブなサービスにおけるユーザー体験が向上します。

gNB -> 5G Modem: RRC Resume (TS 38.331, RadioBearerConfig, K_RRCenc, K_RRCint)

説明: RRC Resume Requestを受信したgNBは、UEの非アクティブASコンテキストを再利用し、RRC ResumeメッセージをUEに送信します。このメッセージには、無線ベアラー構成（RadioBearerConfig）が含まれ、UEがRRC_CONNECTED状態に移行するために必要な無線リソース設定を指示します。また、RRCメッセージの機密性（K_RRCenc）と完全性（K_RRCint）を保護するためのセキュリティキーも含まれます [10]。
チャネル: このメッセージは、Uuインターフェース上のDL-DCCHを介してSRB1で送信されます。
推測: この段階で、UEとgNB間のRRC接続が再確立され、無線ベアラーが設定されます。セキュリティキーの提供は、以降のRRCおよびNASシグナリングが保護されることを保証します。

5G Modem -> gNB: RRC Resume Complete (TS 38.331)

説明: UEはRRC Resumeメッセージの内容を処理し、無線リソース構成を適用した後、RRC Resume CompleteメッセージをgNBに送信して、RRC接続の再開が成功したことを確認します。
チャネル: このメッセージは、Uuインターフェース上のUL-DCCHを介してSRB1で送信されます。
推測: これにより、UEはRRC_CONNECTED状態に移行し、gNBはUEが無線アクセスネットワーク（RAN）に接続された状態であることを認識します。

gNB -> AMF: N2 Resume Request (NGAP, N2, UE Context, RRC Resume Cause)

説明: UEがRRC_CONNECTED状態に移行したことを受け、gNBはNGAPプロトコルを介してN2インターフェース上でN2 Resume RequestメッセージをAMFに送信します [6]。このメッセージには、UEのコンテキスト情報と、RRC接続再開の理由（例：アップリンクデータ）が含まれます。
推測: このメッセージは、AMFにUEが再びアクティブになり、ユーザープレーン接続の再開が必要である可能性を通知します。AMFはUEのモビリティ管理を担当するため、この情報はUEの現在の状態を更新するために不可欠です。

AMF -> SMF: Nsmf_PDUSession_UpdateSMContext Request (HTTP/2, N11, PDU Session ID, Operation Type: "UP Resume")

説明: AMFは、UEの接続が再開されたことを認識すると、HTTP/2プロトコルを介してN11インターフェース上でNsmf_PDUSession_UpdateSMContext RequestメッセージをSMFに送信します [6]。このメッセージは、特定のPDUセッションのユーザープレーンを再開するようにSMFに要求します。Operation Typeは「UP Resume」に設定されます。
推測: AMFはUEのNASレイヤーの接続状態を管理し、SMFはPDUセッションの管理とユーザープレーンの確立を担当します。このメッセージは、制御プレーンとユーザープレーンの連携を示しており、UEがデータを送受信できるようユーザープレーンのパスをアクティブにするための重要なステップです。

SMF -> UPF: N4 Session Modification Request (PFCP, N4, AN Tunnel Info to be resumed, Buffering Off)

説明: SMFは、UP Resume要求を受け取ると、PFCP（Packet Forwarding Control Protocol）を介してN4インターフェース上でN4 Session Modification RequestメッセージをUPFに送信します [6]。このメッセージは、以前に中断されていたアクセスネットワーク（AN）トンネル情報を再開し、UPFにバッファリングされていたダウンリンクデータがあれば、そのバッファリングを停止して転送を開始するように指示します。
推測: UPFはユーザーデータトラフィックを処理する機能であり、N4インターフェースはSMFとUPF間の制御プレーンインターフェースです。このメッセージは、UPFがUEとデータネットワーク（DN）間のユーザープレーンパスを再確立し、データ転送の準備を整えることを保証します。

UPF -> SMF: N4 Session Modification Response (PFCP, N4)

説明: UPFは、N4 Session Modification Requestを正常に処理した後、N4 Session Modification ResponseをSMFに返送します。
推測: これは、UPFがユーザープレーンパスを再開する準備ができたことをSMFに確認するものです。

SMF -> AMF: Nsmf_PDUSession_UpdateSMContext Response (HTTP/2, N11)

説明: SMFは、UPFからの応答を受け取ると、Nsmf_PDUSession_UpdateSMContext ResponseをAMFに返送します。
推測: これは、PDUセッションのユーザープレーンが正常に再開されたことをAMFに通知するものです。

AMF -> gNB: N2 Resume Response (NGAP, N2)

説明: AMFは、ユーザープレーンの再開が確認された後、N2 Resume ResponseをNGAPプロトコルを介してN2インターフェース上でgNBに送信します。
推測: このメッセージは、UEの接続再開要求がコアネットワークによって承認され、ユーザープレーンの準備が整ったことをgNBに通知します。

4.2 NASサービス要求とユーザープレーンの確立

5G Modem -> gNB: SERVICE REQUEST (TS 24.501, 5G-S-TMSI, Uplink data status, Service Type: Mobile Originating Data)

説明: UEは、アップリンクデータが保留中であることをネットワークに明示的に通知するために、SERVICE REQUEST NASメッセージをgNBに送信します [11]。このメッセージには、UEの一時識別子である5G-S-TMSI、アップリンクデータのステータス、およびサービスタイプ（例：「Mobile Originating Data」）が含まれます。
チャネル: このNASメッセージは、Uuインターフェース上のUL-DCCHを介してSRB1で伝送されます。
推測: RRC接続が再開された後でも、UEはNASレイヤーでサービス要求を送信し、コアネットワークに具体的なサービスニーズ（この場合はアップリンクデータ）を通知することが一般的です。これは、RRC_INACTIVE状態からの移行におけるユーザープレーンの再アクティブ化をトリガーするNASシグナリングです。

gNB -> AMF: Uplink NAS Transport (NGAP, N2, NAS-PDU: SERVICE REQUEST)

説明: gNBは、UEから受信したSERVICE REQUEST NASメッセージを、NGAPプロトコルを介してN2インターフェース上でUplink NAS TransportメッセージとしてAMFに転送します。
推測: gNBはNASメッセージの内容を解釈せず、単にAMFへのトランスポートレイヤーとして機能します。

AMF -> SMF: Nsmf_PDUSession_UpdateSMContext Request (HTTP/2, N11, PDU Session ID, Cause: "Uplink Data")

説明: AMFは、UEからのSERVICE REQUESTメッセージを処理し、特定のPDUセッションに関連するアップリンクデータがあることを認識すると、Nsmf_PDUSession_UpdateSMContext RequestをSMFに送信します。このメッセージは、ユーザープレーンの確立または再確認をトリガーします。
推測: ユーザープレーンの再開はすでにステップ6-10で開始されていますが、このNASメッセージは、UEがデータ送信の準備ができたことを明示的に示す役割を果たします。これにより、SMFはPDUセッションのステータスを最終確認し、必要に応じてUPFへの追加の指示を出すことができます。

SMF -> UPF: N4 Session Modification Request (PFCP, N4, PDU Session ID, QFI, PDRs)

説明: SMFは、PDUセッションのユーザープレーンを完全にアクティブにするため、PFCPを介してN4インターフェース上でN4 Session Modification RequestをUPFに送信します。このメッセージには、PDUセッションID、QoSフロー識別子（QFI）、およびパケット検出ルール（PDRs）が含まれます [4]。PDRsは、特定のデータフローを識別し、対応するQoSフローにマッピングするためにUPFによって使用されます。
推測: このステップは、UEとデータネットワーク間のデータパスが、定義されたQoS（Quality of Service）ポリシーに従って確立されることを保証します。QFIは、5GシステムにおけるQoS転送処理の最も細かい粒度であり、同じQFIにマッピングされたすべてのトラフィックは同じ転送処理を受けます [7]。

UPF -> SMF: N4 Session Modification Response (PFCP, N4)

説明: UPFは、N4 Session Modification Requestを正常に処理した後、N4 Session Modification ResponseをSMFに返送します。
推測: これは、UPFがデータ転送の準備が完全に整ったことをSMFに確認するものです。

SMF -> AMF: Nsmf_PDUSession_UpdateSMContext Response (HTTP/2, N11)

説明: SMFは、UPFからの応答を受け取ると、Nsmf_PDUSession_UpdateSMContext ResponseをAMFに返送します。
推測: これは、PDUセッションのユーザープレーンが完全にアクティブ化されたことをAMFに通知するものです。

gNB -> 5G Modem: RRC Reconfiguration (TS 38.331, DRB Setup, QoS Rules, QFI, K_UPenc, K_UPint)

説明: gNBは、AMFおよびSMFとの連携により、UEとgNB間のユーザープレーンデータ転送に使用されるデータ無線ベアラー（DRB）を確立するために、RRC ReconfigurationメッセージをUEに送信します [10]。このメッセージには、DRBの設定、QoSルール、QFI、およびユーザープレーンデータ（K_UPenc）の暗号化と整合性保護（K_UPint）のためのセキュリティキーが含まれます [10]。
チャネル: このメッセージは、Uuインターフェース上のDL-DCCHを介してSRB1で送信されます。
推測: このステップは、無線インターフェース上でユーザープレーンセキュリティをアクティブ化し、ウェブ閲覧データが安全に伝送されることを保証するために不可欠です。DRBは、アプリケーション層のデータ（この場合はHTTPトラフィック）を伝送するための専用の無線リソースを提供します。

5G Modem -> gNB: RRC Reconfiguration Complete (TS 38.331)

説明: UEはRRC Reconfigurationメッセージの内容を処理し、DRBを設定し、ユーザープレーンセキュリティをアクティブ化した後、RRC Reconfiguration CompleteメッセージをgNBに送信して、設定変更が成功したことを確認します。
チャネル: このメッセージは、Uuインターフェース上のUL-DCCHを介してSRB1で送信されます。
推測: これにより、UEとgNB間の無線インターフェース上でユーザープレーンの準備が整い、データ転送を開始できるようになります。

4.3 データ転送フェーズ

Application -> 5G Modem: HTTP GET Request (Data Packet)

説明: ウェブブラウザアプリケーションは、UEの5Gモデム（ユーザープレーン）にHTTP GETリクエストのデータパケットを送信します。
推測: これは、ユーザーがウェブページを要求した結果として、実際のデータ転送が開始されることを示します。

5G Modem -> gNB: UL Data (IP Packet, QFI)

説明: 5Gモデムは、アプリケーションから受信したIPパケットを、適切なDRBにマッピングし、ユーザープレーンセキュリティ（暗号化と完全性保護）を適用して、gNBにアップリンクデータとして送信します。このデータには、関連するQoSフローを識別するためのQFIが含まれます。
チャネル: このデータは、Uuインターフェース上のUL-SCH（Uplink Shared Channel）を介してDTCH（Dedicated Traffic Channel）でDRBを介して送信されます。UL-SCHはHARQ、ビームフォーミング、動的リンク適応をサポートするトランスポートチャネルです [3]。
推測: UEとgNB間の無線リンクは、ユーザープレーンデータを効率的かつ安全に伝送するために最適化されています。QFIの存在は、gNBがこのデータに適切なQoS処理を適用できることを保証します。

gNB -> UPF: UL Data (GTP-U, N3, QFI)

説明: gNBは、UEから受信したアップリンクデータを、GTP-U（GPRS Tunnelling Protocol for User Plane）を介してN3インターフェース上でUPFに転送します。このGTP-Uトンネルには、QFIが含まれており、UPFが適切なQoS処理とルーティングを行うための情報を提供します。
推測: N3インターフェースは、gNBとUPF間のユーザープレーンインターフェースであり、GTP-Uは5Gシステムにおけるユーザープレーンデータ転送の標準プロトコルです。QFIの伝送は、エンドツーエンドのQoSが維持されることを保証します [7]。

UPF -> DN: UL Data (IP Packet)

説明: UPFは、受信したGTP-UパケットからIPパケットを抽出し、それをデータネットワーク（DN、この場合はインターネット）に転送します。
推測: UPFは、ユーザープレーンのアンカーポイントとして機能し、UEからのトラフィックを外部ネットワークにルーティングします。ウェブブラウザのHTTP GETリクエストがインターネット上のウェブサーバーに到達するパスが確立されます。

DN -> UPF: DL Data (IP Packet)

説明: ウェブサーバーからのHTTPレスポンス（ウェブコンテンツ）を含むダウンリンクIPパケットが、データネットワークからUPFに到達します。
推測: これは、ユーザーが要求したウェブコンテンツがネットワークを介してUEに戻るパスを示します。

UPF -> gNB: DL Data (GTP-U, N3, QFI)

説明: UPFは、ダウンリンクIPパケットをGTP-Uでカプセル化し、N3インターフェースを介してgNBに転送します。ここでも、QFIが含まれており、gNBが適切なDRBにデータをマッピングするための情報を提供します。
推測: UPFは、ダウンリンクデータに対してもPDRsに基づいてQoSフローにマッピングし、QFIをカプセル化ヘッダーに含めます [7]。これにより、gNBは受信したデータに適切な無線リソースとQoS処理を適用できます。

gNB -> 5G Modem: DL Data (IP Packet, QFI)

説明: gNBは、UPFから受信したGTP-UパケットからIPパケットを抽出し、ユーザープレーンセキュリティ（復号化と完全性検証）を適用して、UEの5Gモデムにダウンリンクデータとして送信します。
チャネル: このデータは、Uuインターフェース上のDL-SCH（Downlink Shared Channel）を介してDTCHでDRBを介して送信されます。DL-SCHはHARQ、動的リンク適応、ビームフォーミング、動的/半静的リソース割り当てをサポートするトランスポートチャネルです [3]。
推測: UEは受信したデータを復号化し、ブラウザアプリケーションに渡す準備をします。

5G Modem -> Application: HTTP Response (Web Content)

説明: 5Gモデムは、受信したウェブコンテンツを含むHTTPレスポンスをウェブブラウザアプリケーションに渡します。
推測: これにより、ユーザーは要求したウェブページを閲覧できるようになります。

4.4 非アクティブ化とRRC接続解放フェーズ

5G Modem - 5G Modem: Inactivity Timer Expires (Internal)

説明: UE内部で、データ通信の非アクティブ期間を監視するタイマー（例：SRB/DRB非アクティブタイマー）が満了します [13]。
推測: このタイマーの満了は、UEがアクティブなデータ転送を必要としなくなったことを示唆し、ネットワークリソースの最適化とUEの省電力化のためにRRC接続を解放するトリガーとなります。

gNB -> 5G Modem: RRC Release (TS 38.331, suspendConfig)

説明: gNBは、UEからのデータ非アクティブを検知すると、RRC ReleaseメッセージをUEに送信し、RRC接続の解放を指示します。このメッセージには、UEがRRC_INACTIVE状態に移行するためのsuspendConfig情報要素が含まれます [2]。suspendConfigには、将来のRRC接続再開のためにUEが保存すべきASコンテキスト情報（例：nextHopChainingCount、現在のKgNBおよびKRRCintキー、ROHC状態、QoSフローとDRBのマッピングルールなど）が含まれます [2]。
チャネル: このメッセージは、Uuインターフェース上のDL-DCCHを介してSRB1で送信されます。
推測: RRC_INACTIVE状態への移行は、UEの消費電力を削減しつつ、将来のデータ通信に対する迅速な応答性を維持するための重要なメカニズムです。これにより、UEはネットワークリソースを占有することなく、必要に応じて迅速にRRC_CONNECTED状態に戻ることができます。

5G Modem - 5G Modem: (Implicitly enters RRC_INACTIVE)

説明: RRC Releaseメッセージ（suspendConfig付き）を受信したUEは、内部的にRRC_INACTIVE状態に移行します。この際、UEは将来の再開のためにASコンテキストを保存します [2]。
推測: この移行は、UEが無線リソースを解放し、省電力モードに入ることを意味します。

gNB -> AMF: UE Context Release Request (NGAP, N2, Cause)

説明: gNBは、UEのRRC接続を解放した後、NGAPプロトコルを介してN2インターフェース上でUE Context Release RequestメッセージをAMFに送信し、UEのコンテキストを解放するように要求します。
推測: gNBはUEの無線リソースを解放しましたが、AMFは引き続きUEのモビリティおよびNASコンテキストを管理する必要があります。このメッセージは、AMFにUEがRRC_INACTIVE状態に移行したことを通知し、AMFがUEのCM状態を更新できるようにします。

AMF -> SMF: Nsmf_PDUSession_UpdateSMContext Request (HTTP/2, N11, PDU Session ID, Operation Type: "UP Suspend")

説明: AMFは、UEのRRC接続が解放されたことを認識すると、HTTP/2プロトコルを介してN11インターフェース上でNsmf_PDUSession_UpdateSMContext RequestメッセージをSMFに送信し、関連するPDUセッションのユーザープレーンを中断するように要求します [6]。Operation Typeは「UP Suspend」に設定されます。
推測: これは、UEが非アクティブになったため、ユーザープレーンのリソースを解放し、ネットワークの効率を向上させるためのステップです。

SMF -> UPF: N4 Session Modification Request (PFCP, N4, AN Tunnel Info to be suspended, Buffering On)

説明: SMFは、UP Suspend要求を受け取ると、PFCPを介してN4インターフェース上でN4 Session Modification RequestメッセージをUPFに送信します [6]。このメッセージは、アクセスネットワーク（AN）トンネル情報を中断し、将来のダウンリンクデータのためにUPFにバッファリングを開始するように指示します。
推測: UPFはユーザープレーンのトラフィックを処理するため、このメッセージはUPFがUEへのデータ転送を停止し、UEが再びアクティブになった場合に備えてデータをバッファリングする準備を整えることを保証します。

UPF -> SMF: N4 Session Modification Response (PFCP, N4)

説明: UPFは、N4 Session Modification Requestを正常に処理した後、N4 Session Modification ResponseをSMFに返送します。
推測: これは、UPFがユーザープレーンを中断し、バッファリングを開始する準備ができたことをSMFに確認するものです。

SMF -> AMF: Nsmf_PDUSession_UpdateSMContext Response (HTTP/2, N11)

説明: SMFは、UPFからの応答を受け取ると、Nsmf_PDUSession_UpdateSMContext ResponseをAMFに返送します。
推測: これは、PDUセッションのユーザープレーンが正常に中断されたことをAMFに通知するものです。

AMF -> gNB: UE Context Release Command (NGAP, N2)

説明: AMFは、ユーザープレーンの中断が確認された後、NGAPプロトコルを介してN2インターフェース上でUE Context Release CommandをgNBに送信し、UEのコンテキストを完全に解放するように指示します。
推測: これにより、gNBはUEのASコンテキストを解放し、無線リソースを他のUEのために利用できるようになります。

gNB -> AMF: UE Context Release Complete (NGAP, N2)

説明: gNBは、UEコンテキストの解放を完了した後、UE Context Release CompleteメッセージをAMFに送信します。
推測: これにより、UEのRRC接続が完全に解放され、UEはRRC_INACTIVE状態に移行し、ネットワークリソースの効率的な利用が図られます。

5. 結論

本報告書では、5G UEが待機状態（RRC_INACTIVE）からウェブ閲覧を開始する際のエンドツーエンドのメッセージシーケンスを、3GPPの技術仕様に基づき詳細に分析しました。この分析を通じて、5GシステムがUEの接続状態をRRC_INACTIVEのような中間状態に維持することで、省電力と迅速なデータアクセス応答性のバランスをどのように実現しているかが明確になりました。

RRC_INACTIVE状態からの復帰は、RRC_IDLE状態からの完全なRRC接続確立と比較して、シグナリングオーバーヘッドとレイテンシを大幅に削減します。これは、UEがRRC_INACTIVE ASコンテキストを保持し、gNBもUEコンテキストを維持しているためであり、これにより無線リソースの効率的な再割り当てとユーザープレーンの迅速な再アクティブ化が可能になります。

認証とセキュリティモード制御は、UEとネットワーク間のすべてのシグナリングおよびユーザープレーンデータが機密性と完全性を持って保護されることを保証する上で不可欠な要素です。5Gシステムは、これらのセキュリティメカニズムを、UEの接続確立およびPDUセッションアクティブ化プロセスに深く統合しています。

PDUセッション管理とQoSフローの概念は、ウェブ閲覧のような多様なサービス要件を持つトラフィックに対して、ネットワークがどのようにきめ細やかなリソース制御と優先順位付けを提供するかを示しています。QFIの使用は、UPFからgNB、そしてUEに至るまで、データパス全体で特定のQoS処理が維持されることを保証します。

最終的に、データ非アクティブ後のRRC接続解放とRRC_INACTIVE状態への移行は、ネットワークリソースの最適化とUEのバッテリー寿命の延長に貢献します。この一連のプロセスは、5Gが提供する高性能かつ高機能なモバイルブロードバンド体験の基盤を形成しており、ユーザーの期待に応えるためのシステムの複雑かつ洗練された設計を浮き彫りにしています。

引用文献

ETSI TS 138 331 V18.4.0 (2025-01) - iTeh Standards (2025年6月14日アクセス)
TS 138 331 - V18.4.0 - 5G; NR; Radio Resource Control ... - ETSI (2025年6月14日アクセス)
ETSI TS 138 300 V18.4.0 (2025-01) (2025年6月14日アクセス)
ETSI TS 124 501 V17.11.0 (2023-07) - iTeh Standards (2025年6月14日アクセス)
ETSI TS 123 501 V17.7.0 (2023-01) - 5G; System architecture for the ... (2025年6月14日アクセス)
TS 123 502 - V18.6.0 - 5G; Procedures for the 5G System ... - ETSI (2025年6月14日アクセス)
ETSI TS 123 501 V17.7.0 (2023-01) (2025年6月14日アクセス)
3GPP TS 24.501 (2025年6月14日アクセス)
5G RRC Connection (Signalling Radio Bearer: SRB) - 5G NR - telecomHall Forum (2025年6月14日アクセス)
Security for 5G - ShareTechnote (2025年6月14日アクセス)
TS 124 501 - V17.11.0 - 5G;Non-Access-Stratum (NAS ... - ETSI (2025年6月14日アクセス)
QoS Model in 5G | Award Solutions (2025年6月14日アクセス)
RRC Inactive State and Resume Procedure Requirements - 5G NR ... (2025年6月14日アクセス)