LoginSignup
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@InvisibleSmartphone

16. 生成AIで作成する5Gシステムのサンプルメッセージシーケンス概要 : インターネットアクセス(RRC_IDLE状態) 編

Posted at

目次

1. 序論

本報告書は、一般的な大規模モバイルキャリアの5Gシステムにおいて、UE（User Equipment）が電源投入後、SIB（System Information Block）受信と初期登録を完了し、RRC_IDLE状態（無線リソース制御アイドル状態）にある状況から、アプリケーション（ブラウザ）を使用してインターネット上のWebサイトを閲覧する際のエンドツーエンドのメッセージシーケンスを分析することを目的とする。このシナリオは、5Gネットワークがアイドル状態のUEに対して効率的かつ迅速にデータサービスを提供するために不可欠なプロセスを示すものである。

5Gシステムは、UE、gNB（次世代基地局）、および5GC（5Gコアネットワーク）で構成され、高度な接続性と多様なサービスをサポートするために設計されている。特に、UEがRRC_IDLE状態にある場合、無線リソースは解放されており、バッテリー消費を抑えながら待機している。ユーザーがWebサイト閲覧を開始すると、UEは無線リソースを再確立し、データパスを活性化する必要がある。本報告書では、この一連のプロセスにおける各エンティティ間のメッセージ交換、プロトコル、インターフェース、およびチャネルを、3GPPの技術仕様に基づいて解説する。

本分析では、以下の主要な3GPP技術仕様を参照する。これらの仕様は、5Gシステムの動作原理を理解するための基盤となる。

TS番号 領域
38.331 RRCプロトコル (無線リソース制御)
38.413 NGAPプロトコル (gNBとAMF間の制御プレーン)
24.501 NASプロトコル (UEとAMF/SMF間の非アクセス層)
23.502 5Gシステム手順 (サービス要求、PDUセッション確立など)
29.509 Nausfサービス (認証サーバー機能)
29.503 Nudmサービス (統合データ管理)
29.512 Npcfサービス (ポリシー制御機能)
29.244 PFCPプロトコル (SMFとUPF間の制御プレーン)
29.281 GTP-Uプロトコル (ユーザープレーンデータ転送)

2. シーケンスチャート

3. メッセージシーケンスの説明

UEがRRC_IDLE状態からWebサイト閲覧を開始する際のメッセージシーケンスは、大きく4つのフェーズに分けられる。各フェーズでは、UE、gNB、および5Gコアネットワークの各機能エンティティが連携し、無線接続の確立、セキュリティの確保、データパスの活性化、そして最終的なユーザーデータ転送を実現する。

3.1 フェーズ1: RRC接続確立 (RRC_IDLEからRRC_CONNECTEDへ)

このフェーズは、UEのアプリケーション（ブラウザ）がインターネットアクセスを試みることで開始され、5Gモデムが無線接続を確立するトリガーとなる。UEはRRC_IDLE状態にあるため、NASメッセージをコアネットワークに送信する前に、まずRRC接続を確立する必要がある[1]。

3.1.1 RRCSetupRequest (UE -> gNB)

UEは、RRC接続確立手順を開始するために、RRCSetupRequestメッセージをgNBに送信する。このメッセージは、論理チャネルであるCommon Control Channel (CCCH)上で送信され、トランスポートチャネルであるUplink Shared Channel (UL-SCH)にマッピングされ、Physical Uplink Shared Channel (PUSCH)を介して物理層で伝送される[2]。

RRCSetupRequestには、接続要求の理由を示すEstablishmentCauseが含まれており、このシナリオでは「MO-data」（Mobile Originated data）に設定される[3]。この情報はgNBに対し、ユーザープレーンのリソースが必要となることを事前に通知する。

EstablishmentCauseは単なる情報提供に留まらず、ネットワーク最適化にとって極めて重要な要素である。gNBおよびその先のAMF（N2インターフェース経由）は、「MO-data」のシグナリングを即座に受け取ることで、ユーザープレーンリソースが必要となることを事前に把握できる。これにより、汎用的なシグナリング接続として扱うのではなく、データ無線ベアラ（DRB）やユーザープレーンのトンネル設定を予測し、場合によっては迅速化することが可能となる。このようなプロアクティブなシグナリングは、Webブラウジングのようなユーザーが開始するデータサービスの全体的な遅延を低減させる効果がある。EstablishmentCauseは、AMFによるその後のService Request処理に直接影響を与え、アクティブなデータ転送のための接続であることが分かれば、PDUセッションのアクティベーションプロセスを優先したり、効率化したりする可能性がある[5]。

3.1.2 RRCSetup (gNB -> UE)

RRCSetupRequestに応答して、gNBはRRCSetupメッセージをUEに送信する。このメッセージもCCCH論理チャネルで伝送され、Downlink Shared Channel (DL-SCH)トランスポートチャネルにマッピングされ、Physical Downlink Shared Channel (PDSCH)を介して物理層で伝送される[2]。このメッセージには、UEがネットワークリソースにアクセスするために必要な初期の無線リソース設定、具体的にはSignaling Radio Bearer 1 (SRB1)の確立に関する情報が含まれる[3]。

3.1.3 RRCSetupComplete (UE -> gNB)

RRCSetupの設定を正常に受信し適用した後、UEはRRCSetupCompleteメッセージをgNBに送信する。このメッセージはRRC接続の確立が成功したことを示し、UEはRRC_CONNECTED状態に移行する。このメッセージは、SRB1が確立されたため、Dedicated Control Channel (DCCH)論理チャネルで伝送され、UL-SCHにマッピングされ、PUSCHを介して送信される[2]。重要な点として、このメッセージは最初のNASメッセージであるService Requestを内包して送信される[3]。

UEとネットワーク間のUuインターフェースにおけるチャネルマッピングは、以下の表にまとめることができる。

レイヤ チャネルタイプ 論理チャネル トランスポートチャネル 物理チャネル
制御プレーン 共通制御 CCCH UL-SCH, DL-SCH PUSCH, PDSCH
専用制御 DCCH (SRB1, SRB2) UL-SCH, DL-SCH PUSCH, PDSCH
ユーザープレーン 専用トラフィック DTCH (DRB) UL-SCH, DL-SCH PUSCH, PDSCH

3.2 フェーズ2: NASサービス要求とセキュリティ確立

このフェーズでは、UEがコアネットワークにサービス要求をシグナリングし、NASメッセージのためのセキュアな通信チャネルを確立する。

3.2.1 Service Request (UE -> AMF経由gNB)

Service Requestは、UEが5GMM-IDLE状態からAMFへのセキュアな接続の確立と、既存のPDUセッションのユーザープレーン接続の活性化を要求するために開始されるNASメッセージ（5GMM）である[5]。このService Request NASメッセージは、gNBによってNGAP: INITIAL UE MESSAGEにカプセル化され、N2インターフェースを介してAMFに送信される[5]。

このメッセージに含まれる主要な情報要素（IEs）は以下の通りである。

  • 5GMM SERVICE REQUEST: これは主要なNASメッセージである[5]。
  • 5G-S-TMSI: AMF選択のために使用されるUEの一時的な識別子[5]。
  • Establishment Cause: RRCメッセージから引き継がれ、「MO-data」であることを確認する[5]。
  • List Of PDU Sessions To Be Activated: このIEは、UEの既存のPDUセッションのうち、ユーザープレーンの活性化が必要なものを指定する[5]。これはデータパスの設定が必要であることを示すため、Webブラウジングにとって極めて重要である。

Service Request手順は、「確立済みのPDUセッションのユーザープレーン接続を活性化する」ために使用されると明示されている[5]。これは、完全なPDUセッション確立（例：IPアドレス割り当て、DNN選択）とは異なる重要な点である[11]。UEが既に登録済みでPDUセッションを保持しているため、IPアドレス割り当てなど、PDUセッション確立の全手順を回避できる。これにより、シグナリングのオーバーヘッドが大幅に削減され、遅延も短縮されるため、アイドル状態からアクティブなデータ転送への移行がはるかに迅速になり、Webブラウジングのようなインタラクティブなアプリケーションにとって極めて重要となる。5GのService Requestは、既存のPDUセッションのユーザープレーンリソースを再活性化するための高度に最適化された手順であり、より広範なPDUセッション確立手順とは対照的である。この設計選択は、アイドル状態からの低遅延かつ効率的な接続管理を実現するための5Gの基本的な要素である。

3.2.2 認証手順 (AMF <-> AUSF <-> UDM)

Service Requestを受信すると、AMFは認証手順を開始する可能性がある[5]。これはUEとネットワーク間の相互認証プロセスであり、通常は5G AKA（Authentication and Key Agreement）またはEAP-AKA'が使用される[13]。AMFはSecurity Anchor Function (SEAF)として機能し、AUSFと連携し、AUSFはUDM/ARPFと通信して認証ベクトルを取得する[13]。

  • AMF -> AUSF: Nauthf_UEAuthentication_Authenticate Request: AMFはUEの識別子（SUCI）とサービスネットワーク名を含む認証要求をAUSFに送信する[13]。これはSBI（Service-Based Interface）メッセージであり、通常はHTTP/2を介して行われる[18]。
  • AUSF -> UDM: Nudm_UEAuthentication_Get Request: AUSFはUDMから認証データを要求する。UDMは加入者情報を格納している[16]。これもHTTP/2を介したSBIメッセージである。
  • UDM --> AUSF: Nudm_UEAuthentication_Get Response: UDMは認証ベクトル（AV）を取得し、これにはRAND（ランダムチャレンジ）、AUTN（認証トークン）、XRES*（期待される応答）、およびK_AUSF（AUSF用キー）が含まれ、AUSFに送信する[13]。
  • AUSF --> AMF: Nauthf_UEAuthentication_Authenticate Response: AUSFは認証チャレンジ（RAND、AUTN）とngKSI（NAS Key Set Identifier）をAMFに転送する[15]。
  • Modem <- AMF: NGAP: DOWNLINK NAS TRANSPORT / 5GMM AUTHENTICATION REQUEST: AMFはRAND、AUTN、およびngKSIを含むAUTHENTICATION REQUEST NASメッセージをgNB経由でUEに送信する[13]。
  • Modem -> AMF: NGAP: UPLINK NAS TRANSPORT / 5GMM AUTHENTICATION RESPONSE: UEはRANDとAUTNに基づいて応答（RES）を計算し、AUTHENTICATION RESPONSEメッセージでAMFに返信する[13]。
  • AMF -> AUSF: Nauthf_UEAuthentication_5G_AKA_Confirmation: AMFはUEの応答（RES*）をAUSFに送信し、検証を要求する[17]。
  • AUSF --> AMF: Nauthf_UEAuthentication_5G_AKA_Confirmation Response: AUSFは認証結果をAMFに確認する。

この認証手順は条件付きで実行される[5]。有効な5G NASセキュリティコンテキストが既に存在する場合（ngKSIによって識別される[21]）、完全な認証はスキップされる可能性がある。これは5Gの効率性重視の設計を反映している。AMF、AUSF、UDM間のSBIとHTTP/2の使用は[18]、ネットワーク機能間のモジュール性、柔軟性、スケーラビリティの高い相互作用を可能にし、迅速な認証とコンテキスト取得を促進する。5Gのセキュリティアーキテクチャは、条件付き認証を重視し、SBIを活用してコアネットワーク機能間の効率的でモジュール化された相互作用を実現している。これにより、サービス活性化における遅延を最小限に抑えるために、セキュリティコンテキストの迅速な確立または再利用が可能となる。

3.2.3 NASセキュリティモードコマンド (AMF -> UE経由gNB)

認証が成功した後（または有効なコンテキストのために認証がスキップされた場合）、AMFはNASセキュリティモード制御手順を開始する。AMFは5GMM SECURITY MODE COMMAND NASメッセージをUEに送信し、これをNGAP DOWNLINK NAS TRANSPORTメッセージにカプセル化する。このメッセージは完全性保護されているが、暗号化はされていない[21]。

このメッセージに含まれる主要な情報要素（IEs）は以下の通りである。

  • ngKSI: 現在の5G NASセキュリティコンテキストを識別する[21]。
  • 5G-EA (5GS encryption algorithm): 選択された暗号化アルゴリズム（例：128-5G-EA1-3）[24]。
  • 5G-IA (5GS integrity algorithm): 選択された完全性保護アルゴリズム（例：128-5G-IA1-3）[24]。

NASセキュリティは、完全性保護と暗号化の両方を含む[21]。SECURITY MODE COMMANDメッセージ自体は完全性保護されているが、暗号化はされていない。これは意図的な設計選択である。完全性保護はメッセージの認証性と改ざん防止を保証し、暗号化（より計算負荷が高い）はコマンドが確認された後に有効化される。この段階的な有効化により、すべての後続のNASメッセージに完全な機密性が適用される前に、重要なセキュリティパラメータが確実に交換される。5GのNASセキュリティは段階的なアプローチを採用しており、SECURITY MODE COMMAND自体に対して完全性保護を優先することで、セキュリティコンテキストの信頼性の高い設定を保証し、その後にすべてのNASメッセージに対して完全な暗号化を適用する。

3.2.4 NASセキュリティモード完了 (UE -> AMF経由gNB)

UEはSECURITY MODE COMMANDを処理し、必要なキーを導出し、選択されたセキュリティアルゴリズムを適用する。その後、UEは5GMM SECURITY MODE COMPLETE NASメッセージをAMFに返信し、これをNGAP UPLINK NAS TRANSPORTメッセージにカプセル化する。このメッセージは、新しく確立されたNASセキュリティコンテキストを使用して、完全性保護および暗号化の両方が施される[21]。

NASメッセージに含まれる主要な情報要素は以下の通りである。

メッセージ名 情報要素 (IE) 名 意義/目的
5GMM SERVICE REQUEST 5G-S-TMSI UEの一時的な識別子。AMF選択に利用される。
Establishment Cause RRC接続確立の理由（例: MO-data）。ネットワークにデータパスの必要性を通知。
List Of PDU Sessions To Be Activated ユーザープレーンの活性化が必要な既存のPDUセッションのリスト。
5GMM AUTHENTICATION REQUEST RAND (Random Challenge) ネットワークからUEへの認証チャレンジ。
AUTN (Authentication Token) ネットワークの認証性を示すトークン。UEによるネットワーク認証に利用。
ngKSI (NAS Key Set Identifier) 使用するNASセキュリティコンテキストを識別するキーセット識別子。
5GMM AUTHENTICATION RESPONSE RES (Response) UEが計算し、ネットワークに送信する認証応答。
5GMM SECURITY MODE COMMAND ngKSI 適用されるセキュリティコンテキストを識別。
5G-EA (5GS Encryption Algorithm) 選択されたNASメッセージ暗号化アルゴリズム。
5G-IA (5GS Integrity Algorithm) 選択されたNASメッセージ完全性保護アルゴリズム。
5GMM SECURITY MODE COMPLETE (なし) コマンドの受領とセキュリティモードの適用を通知。

3.3 フェーズ3: PDUセッションアクティベーションとユーザープレーン設定

NASセキュリティが確立された後、PDUセッションのユーザープレーンを活性化し、データ転送を可能にすることに焦点が移る。

3.3.1 Nsmf_PDUSession_UpdateSMContext Request (AMF -> SMF)

AMFは、UEから受信したService Request（これにはList Of PDU Sessions To Be Activatedが含まれていた）に基づいて、該当するPDUセッションを担当するSMFにNsmf_PDUSession_UpdateSMContext Requestを送信する[5]。これはHTTP/2を介したSBIメッセージであり[18]、Operation Typeが「UP activate」に設定され、ユーザープレーンリソースの活性化が必要であることを示す。

この要求に含まれる主要な情報要素（IEs）は以下の通りである。

  • PDU Session ID: 活性化される特定のPDUセッションを識別する。
  • Operation Type: 「UP activate」に設定される。
  • UE location information: UEの現在の位置情報。
  • Access TypeおよびRAT Type: アクセスネットワーク（3GPP、NR）に関する情報。

3.3.2 SMポリシー変更 (SMF <-> PCF)

動的なPCC（Policy and Charging Control）が展開されており、特定のポリシー制御要求トリガー条件（例：アクセスタイプやUE位置の変更、QoS要件）が満たされる場合、SMFはPCFとの間でSMF initiated SM Policy Modification手順を開始する可能性がある[5]。PCFはUDM/UDRから加入者ポリシーデータを取得し[19]、Npcf_SMPolicyControlサービス操作を介して更新されたポリシー規則をSMFに提供する[26]。これにより、活性化されたユーザープレーンに対してQoSおよび課金ポリシーが正しく適用されることが保証される。

PCFとの相互作用は条件付きであり、Service Request中に常にポリシー更新が必要となるわけではない。しかし、トリガーされた場合、これは5Gの動的なポリシー適用能力を示すものである。これにより、ネットワークは、特定のサービス（Webブラウジング）、UEの加入情報、およびネットワークの状態に基づいて、ユーザープレーン活性化の瞬間に、きめ細やかなQoSおよび課金規則を適用できる。これは、多様な5Gユースケースをサポートするための柔軟性を提供する。ユーザープレーン活性化中のPCFとの条件付きだが強力な相互作用は、5Gの動的なポリシー制御能力を際立たせ、コンテキストと加入者プロファイルに基づいてリアルタイムのQoSおよび課金調整を可能にする。

3.3.3 N4セッション変更/確立 (SMF <-> UPF)

SMFは、PDUセッションのユーザープレーンのトンネルを確立または変更するようUPFに指示する。この通信は、N4インターフェース上でPFCP（Packet Forwarding Control Protocol）を使用して行われる[29]。SMFはPFCP Session Modification Request（または、新しいUPFの場合や最初のPDUセッションの場合はEstablishment Request）をUPFに送信し、パケット検出、転送、および報告のための規則（PDRs, FARs, QERs）を提供する。UPFはPFCP Session Modification Responseで応答し、自身のトンネルエンドポイント情報を提供する。

主要な情報要素（IEs）は以下の通りである。

  • UE IP Address: このPDUセッションのためにUEに割り当てられたIPアドレス。
  • PDRs (Packet Detection Rules): UPFがパケットを識別し、処理する方法に関する規則。
  • FARs (Forwarding Action Rules): UPFがパケットを転送する方法に関する規則（例：gNBへ、DNへ）。
  • QERs (QoS Enforcement Rules): パケットにQoSを適用するための規則。
  • DL CN Tunnel Info: N3インターフェースのためのダウンリンクコアネットワークトンネル情報（GTP-Uトンネルエンドポイント識別子 - TEID、IPアドレス）。
  • UL CN Tunnel Info: N3インターフェースのためのアップリンクコアネットワークトンネル情報（GTP-U TEID、IPアドレス）。

3.3.4 Nsmf_PDUSession_UpdateSMContext Response (SMF -> AMF)

UPFの設定後、SMFはNsmf_PDUSession_UpdateSMContext ResponseをAMFに送信する[25]。この応答にはN2 SM情報が含まれており、gNBがユーザープレーンのための無線ベアラを設定するために必要な詳細が含まれる[5]。

主要な情報要素（IEs）は以下の通りである。

  • N2 SM Information: PDU Session ID、QFI（QoS Flow Identifier）、QoS Profile、およびCN N3 Tunnel Info（N3インターフェースのためのGTP-U TEIDとIPアドレス）を含む[5]。

3.3.5 N2 Request (AMF -> gNB)

AMFは、SMFから受信したN2 SM情報をNGAP N2 REQUESTメッセージでgNBに転送する[5]。このメッセージには、UEのセキュリティコンテキスト、モビリティ制限、およびUEの集約最大ビットレート（UE-AMBR）も含まれる。

主要な情報要素（IEs）は以下の通りである。

  • N2 SM Information: SMFから受信した情報（PDU Session ID, QFI, QoS Profile, CN N3 Tunnel Info）。
  • Security Context: gNBがASセキュリティを適用するための情報。
  • UE-AMBR: UEの集約最大ビットレート。
  • MM NAS Service Accept: UEのサービス要求の承認を示し、AMFにおけるPDUセッションの状態を含む場合がある[5]。

3.3.6 RRCConnectionReconfiguration (gNB -> UE)

AMFから必要な情報を受け取ったgNBは、RRCConnectionReconfigurationメッセージをUEに送信する。このメッセージは、Uuインターフェース上でユーザープレーンのトラフィックを伝送するデータ無線ベアラ（DRB）を確立するために不可欠である[31]。これはDCCH論理チャネルで送信され、DL-SCHにマッピングされ、PDSCHを介して伝送される。

主要な情報要素（IEs）は以下の通りである。

  • Radio Bearer Configuration: DRBの設定、PDCP/RLC設定、セキュリティ設定、SDAPを介したQoSマッピングなどを指定する[31]。
  • QoS Flow to DRB mapping: gNBはQoSフロー（QFIによって識別される）を特定のDRBにマッピングする[32]。単一のDRBは複数のQoSフローを伝送できる。

QoSフローからDRBへのマッピング[32]は、4G LTEと比較して5Gにおける重要なアーキテクチャの強化点である。LTEでは、EPSベアラとDRBの間には1対1のマッピングがあった。5Gでは、単一のPDUセッションに複数のQoSフローを含めることができ、これらはすべて単一のN3 GTP-Uトンネルを介して伝送される[32]。gNBはこれらのQoSフローを1つ以上のDRBに柔軟にマッピングできる。これにより、よりきめ細やかなQoS制御と無線リソースの効率的な利用が可能となる。なぜなら、同じPDUセッション内の異なるサービスが、それぞれ個別のトンネルや無線ベアラを必要とせずに、差別化された処理を受けることができるためである。5Gの柔軟なQoSフローからDRBへのマッピングと、N3 GTP-UトンネルとDRB間の1対多の関係は、単一のPDUセッション内で多様なサービスに対してきめ細やかなQoS差別化と無線リソース利用の最適化を実現するための基本的な要素である。

3.3.7 RRCConnectionReconfigurationComplete (UE -> gNB)

UEはRRCConnectionReconfigurationをRRCConnectionReconfigurationCompleteメッセージをgNBに送信して確認する。これにより、DRBが正常に設定され、UEがユーザーデータ転送の準備ができたことが確認される。このメッセージはDCCHで送信され、UL-SCHにマッピングされ、PUSCHを介して伝送される[6]。

3.3.8 N2 Request Ack (gNB -> AMF)

gNBは、NGAP N2 REQUEST ACKメッセージを送信して、無線リソースの確立が成功したことをAMFに通知する。このメッセージには、AN（Access Network）トンネル情報が含まれており、これはN3インターフェースのためのgNBのGTP-Uトンネルエンドポイント識別子（TEID）とIPアドレスである。また、承認されたQoSフローの状態も示す[5]。

3.3.9 Nsmf_PDUSession_UpdateSMContext Request/Response (AMF -> SMF)

AMFは、gNBから受信したANトンネル情報をNsmf_PDUSession_UpdateSMContext RequestでSMFに転送する[5]。SMFはこの情報を使用して、gNBのトンネル情報でUPFを更新することにより、ユーザープレーンパスを最終的に確立し、N3を介してgNBとUPF間でユーザーデータが流れるようにする。SMFはNsmf_PDUSession_UpdateSMContext Responseで応答する。

5GのQoSフローからDRBへのマッピングを以下の表にまとめる。

要素 識別子 関係性 備考
PDUセッション PDU Session ID 複数QoSフローを包含 UEとデータネットワーク間の論理接続。
QoSフロー QFI (QoS Flow Identifier) 複数SDFを包含、DRBへマッピング 5G QoSの最小粒度。ポリシーと課金が適用される。
データ無線ベアラ DRB ID 1つ以上のQoSフローを伝送 UEとgNB間の無線リソース。
GTP-Uトンネル TEID (Tunnel Endpoint Identifier) PDUセッションごとに単一 gNBとUPF間のN3インターフェースでユーザーデータを伝送。

3.4 フェーズ4: ユーザーデータ転送

RRC接続が確立され、NASセキュリティが有効化され、PDUセッションのユーザープレーンが設定されたことで、UEはアプリケーションデータを送受信できる状態になる。

3.4.1 HTTP/HTTPS Request (App -> 5G Modem -> gNB -> UPF -> DN)

UE上のブラウザアプリケーションは、HTTP/HTTPS要求（例：WebページのGET要求）を生成する。このデータは5Gモデムに渡される。モデムはIPパケット（HTTP/HTTPSデータを含む）をGTP-Uパケットにカプセル化する。

  • UE -> gNB: ユーザーデータ（HTTP/HTTPS）は、確立されたデータ無線ベアラ（DRB ID）および関連するQoSフロー（QFI）を介してUuインターフェース上で送信される。論理チャネルはDedicated Traffic Channel (DTCH)であり、UL-SCHにマッピングされ、PUSCHを介して伝送される[2]。
  • gNB -> UPF: gNBはUEからGTP-Uカプセル化されたデータを受信し、N3インターフェースを介してUPFに転送する。これはGTP-Uトンネルである[34]。GTP-Uヘッダには、QoSフローを識別するためのTEID（Tunnel Endpoint Identifier）とQFIが含まれる[32]。
  • UPF -> DN: UPFはGTP-Uパケットをデカプセル化し、IPパケットを抽出し、N6インターフェースを介して外部データネットワーク（インターネット）に転送する[29]。

アプリケーション（ブラウザ）の視点から見ると、それは標準的なTCP/IP接続を介してHTTP要求を送信しているに過ぎない[18]。RRC、NAS、NGAP、SBI、PFCP、GTP-Uといった5Gの複雑なシグナリングプロセス全体は、5Gモデムとネットワークによって抽象化されている。これは、下位層が信頼性が高くQoS対応のトランスポートサービスを提供し、アプリケーションが基盤となるモバイルネットワークの具体的な詳細を意識する必要がないという、階層型アーキテクチャの特性を明確に示している。5Gネットワークは、その基盤となる複雑性を効果的に抽象化し、アプリケーションに標準的なIPインターフェースを提供する。これにより、既存のインターネットサービス（Webブラウジングなど）がシームレスに動作し、同時に5Gの高度な性能とQoS能力が活用される。

3.4.2 HTTP/HTTPS Response (DN -> UPF -> gNB -> 5G Modem -> App)

データネットワーク内のWebサーバーは、要求されたWebページコンテンツを含むHTTP/HTTPS応答を返す。

  • DN -> UPF: HTTP/HTTPS応答（IPパケット）は、N6インターフェースを介してDNからUPFに到達する。
  • UPF -> gNB: UPFはIPパケットをGTP-Uパケットにカプセル化し、確立されたGTP-Uトンネルを介してN3インターフェース上でgNBに転送する[34]。QFIはGTP-Uヘッダに含まれる[32]。
  • gNB -> 5G Modem: gNBはGTP-Uカプセル化されたデータを受信し、デカプセル化し、確立されたデータ無線ベアラ（DRB ID）および関連するQoSフロー（QFI）を介してUuインターフェース上でユーザーデータ（HTTP/HTTPS）を送信する。論理チャネルはDTCHであり、DL-SCHにマッピングされ、PDSCHを介して伝送される[2]。
  • 5G Modem -> App: 5Gモデムは受信したHTTP/HTTPS応答をブラウザアプリケーションに配信する。

4. 推測と主要な考慮事項

4.1 RRC_IDLE状態と接続管理の効率性

Webブラウジングのようなデータ中心のアプリケーションにおけるRRC_IDLEからRRC_CONNECTEDへの移行は、5Gにおいて高度に最適化されている。完全な初期登録やアタッチとは異なり、Service Request手順[5]は、既に確立されているPDUセッションのユーザープレーンリソースを活性化することを特に目的としている。これにより、ID管理、認証（有効なコンテキストが存在する場合）、およびPDUセッション確立のための冗長なシグナリングが回避され、データアクセスが高速化し、UEのバッテリー寿命が向上する。

UEがRRC_IDLE状態[1]にあるということは、UEはアクティブに接続されていないが、以前に登録を完了していることを意味する。データが必要になったとき、UEはService Requestを送信する[5]。このメッセージは、既存のPDUセッションのユーザープレーンを再活性化するように設計されている。もしUEが毎回完全な登録を実行しなければならないとしたら、それははるかに遅く、より多くの電力を消費することになる。この設計は、断続的なデータフロー（例：バックグラウンドアプリの更新、短いWebブラウジングセッション）が多い現代において、効率的な接続管理の必要性への直接的な対応である。

4.2 NASセキュリティの重要性（認証、完全性、暗号化）

認証およびセキュリティモード制御手順は、その後のすべてのNASおよびユーザープレーン通信を保護するための基本的な要素である。ngKSI[21]は、セキュリティコンテキストを管理するための重要な識別子であり、ネットワークとUEが確立されたセキュリティパラメータを迅速に参照できるようにする。NASメッセージを最初に完全性保護し、次に暗号化するという段階的なアプローチ[21]は、セキュアなチャネルの堅牢で検証可能な設定を保証する。これがなければ、ネットワークは様々な攻撃に対して脆弱になり、ユーザーデータの機密性は損なわれるだろう。

セキュリティは、ユーザーからの要求において明示的に求められている。提供された情報では、認証（AMF、AUSF、UDM）に続いてセキュリティモードコマンド/完了（UE、AMF）という明確なシーケンスが示されている。5GSMメッセージが、セキュリティ保護された5GMMメッセージによって間接的にセキュリティ保護されるという事実[21]は、5GMM層（モビリティ管理）で確立されたセキュリティが、5GSMメッセージ（セッション管理）のためのセキュアなトンネルを提供することを強調している。この統合されたセキュリティアプローチは、実装を簡素化し、制御プレーンのシグナリングのエンドツーエンド保護を保証する。

4.3 QFIとDRBによる動的なQoS管理

QFIによって識別されるQoSフローを中心とした5GのQoSアーキテクチャ[32]は、以前の世代よりも大幅にきめ細かく柔軟性がある。gNBが複数のQoSフローを1つ以上のDRBにマッピングできる一方で、N3上ではPDUセッションごとに単一のGTP-Uトンネルを維持する能力[32]は、効率的なリソース割り当てと差別化されたサービス処理を可能にする。これは、同じPDUセッション内であっても、異なる遅延、帯域幅、信頼性要件を持つ多様な5Gサービスをサポートするために不可欠である。PCFがポリシーを動的に更新する役割[27]は、この適応性をさらに高める。

ユーザーからの要求では、QFIと無線ベアラIDが具体的に求められている。提供された情報[32]は、5GのQoSモデルを明確に説明している。重要なのは、N3 GTP-UトンネルとDRB間の「1対多」の関係、およびQoSフローがQFIによってどのように識別されるかである。これは、各QoSクラスに個別のベアラが必要だった4Gとは異なり、5Gでは異なるQoSフローをより少ない無線ベアラに多重化できることを意味し、無線リソースの利用を最適化する。Webブラウジングの場合、これは同じPDUセッション内で、重要なコンポーネント（例：HTML）をそれほど重要でないコンポーネント（例：広告）よりも優先することを意味する可能性がある。

4.4 制御プレーン（NAS、NGAP、SBI）とユーザープレーン（GTP-U、PFCP）の相互作用

このシーケンスは、制御プレーン（シグナリングとセッション管理を担当）とユーザープレーン（データ転送を担当）間の複雑な連携を明確に示している。NASメッセージはUEとコアネットワーク間のシグナリングを処理し、NGAPはgNBとAMF間のシグナリングを処理し、SBI（HTTP/2）はコアネットワーク機能間の通信を容易にする[18]。PFCP（N4インターフェース）は、SMFがUPFのユーザープレーン動作を制御するための専用プロトコルであり[29]、GTP-U（N3インターフェース）は実際のユーザーデータを伝送する[34]。この明確な分離と定義されたインターフェースは、5Gのモジュール型でスケーラブルなアーキテクチャの特徴である。

5Gのアーキテクチャは、制御プレーンとユーザープレーンの堅牢な分離に基づいて構築されており、標準化されたインターフェースとプロトコル（制御用のNAS、NGAP、SBI、UP制御用のPFCP、UPデータ用のGTP-U）によって実現されている。このモジュール性は、スケーラビリティ、柔軟性、および制御プレーンとユーザープレーンの機能を独立して進化させる能力を向上させる。

4.5 セッションおよびモビリティ管理におけるネットワーク機能の役割

各5GCネットワーク機能は専門的な役割を担っている。AMFはモビリティとアクセスを管理し、SMFはPDUセッションを管理し、UPFはユーザーデータ転送を処理し、AUSF/UDMは認証と加入者データを管理し、PCFはポリシー制御を処理する。これらの機能がSBIを介して相互作用することで、柔軟で分散型のコアネットワークが実現され、特定のユーザーやアプリケーションのニーズに合わせて動的なリソース割り当てとサービス提供が可能となる[18]。

ユーザーからの要求には複数のNFが明示的にリストされている。メッセージを追跡することで、各NFがどのように貢献しているかが明確になる。AMFはモビリティと初期アクセスの中心点である。SMFはPDUセッションのライフサイクルを処理する。UPFはデータ転送を担う。AUSF/UDMはセキュリティを担当する。PCFはポリシーを管理する。この分散型でサービスベースのアプローチは[18]、モノリシックなアーキテクチャとは対照的であり、ネットワークスライシングやよりアジャイルなサービス展開を可能にする5Gの主要な利点である。

5. 結論

5.1 エンドツーエンドフローの要約

UEがRRC_IDLE状態からWebブラウジングを開始する際のメッセージシーケンスは、プロトコルとネットワーク機能の高度に調整された相互作用を示している。このプロセスは、UEが効率的にRRC接続を確立することから始まり、続いてAMFへのService Requestを通じてPDUセッションのユーザープレーンを再活性化する。これにより、NAS通信を保護するための条件付き認証およびセキュリティモード手順がトリガーされる。その後、AMFはSMFと連携し、SMFはPFCPを介してUPFを設定してデータパスを確立する。最終的に、gNBはRRC再設定を介してデータ無線ベアラ（DRB）を確立し、GTP-Uトンネルを介したインターネットへのシームレスなユーザーデータ転送を可能にする。

5.2 データサービスにおける5Gのアーキテクチャ上の利点の強調

この複雑なフローは、5Gの主要なアーキテクチャ上の利点を明確に示している。

  • 効率性: アイドル状態からの最適化された移行（例：ユーザープレーン活性化のためのService Request）は、シグナリングオーバーヘッドを削減し、バッテリー寿命を向上させる。
  • モジュール性とスケーラビリティ: サービスベースアーキテクチャ（SBA）により、ネットワーク機能は明確に定義されたAPI（HTTP/2 over SBI）を介して相互作用し、独立したスケーリングと展開を可能にする。
  • 動的なQoS: QFIと柔軟なDRBマッピングを備えたフローベースのQoSモデルは、多様なサービスに対してきめ細やかな制御と効率的なリソース利用を提供する。
  • 堅牢なセキュリティ: 統合された認証、完全性保護、および暗号化メカニズムにより、すべての層でセキュアな通信が保証される。

これらの機能は、Webブラウジングのような現代のアプリケーションにとって不可欠な、高性能、低遅延、高信頼性のデータサービスを提供するという5Gの約束に、総合的に貢献している。

引用文献

[1] argd_C1-210804_24501_INACTIVE_LIMITED_Service_01.docx - 3GPP, 6月 23, 2025にアクセス, https://www.3gpp.org/ftp/tsg_ct/WG1_mm-cc-sm_ex-CN1/TSGC1_128e/Inbox/drafts/argd_C1-210804_24501_INACTIVE_LIMITED_Service_01.docx
[2] 5G NR Protocol Structure Changes - An Overview | Keysight Blogs, 6月 23, 2025にアクセス, https://www.keysight.com/blogs/en/inds/2020/07/23/5g-nr-protocol-structure-changes-an-overview
[3] inside TS 38.331: Content Part, 6 out of 71 - Tech-invite, 6月 23, 2025にアクセス, https://www.tech-invite.com/3m38/toc/tinv-3gpp-38-331_f.html
[4] draft R3-21xxxx_38413_CR0xxx_(Rel-17) rapporteur.docx - 3GPP, 6月 23, 2025にアクセス, https://www.3gpp.org/ftp/Email_Discussions/RAN3/RAN3_114-e/rapporteur%20work/draft%20R3-21xxxx_38413_CR0xxx_(Rel-17)%20rapporteur.docx
[5] inside TS 23.502: 5GS Service Request procedures - Tech-invite, 6月 23, 2025にアクセス, https://www.tech-invite.com/3m23/toc/tinv-3gpp-23-502_e.html
[6] update of R2-2103034 TS 38.331 CR on RRC processing delay (r16).docx - 3GPP, 6月 23, 2025にアクセス, ftp://www.3gpp.org/tsg_ran/WG2_RL2/TSGR2_113bis-e/Inbox/Drafts/[Offline-025][NR17]%20R4%20related%20I%20(ZTE)/Phase%202/1.%20Handover%20with%20PSCell/update%20of%20R2-2103034%20TS%2038.331%20CR%20on%20RRC%20processing%20delay%20(r16).docx
[7] SA Initial Attach Sequence In Detail - 5G | ShareTechnote, 6月 23, 2025にアクセス, https://www.sharetechnote.com/html/5G/5G_CallProcess_InitialAttach.html
[8] NGAP/NAS Client - Black Duck, 6月 23, 2025にアクセス, https://www.blackduck.com/fuzz-testing/defensics/protocols/ngap-client.html
[9] sigscale/5g-ngap: NG Application Protocol (NGAP) (3GPP TS 38.413) - GitHub, 6月 23, 2025にアクセス, https://github.com/sigscale/5g-ngap
[10] My 3GPP 24.501 notes - GotOpinion, 6月 23, 2025にアクセス, https://wiki.gotopinion.info/wiki/index.php?title=My_3GPP_24.501_notes
[11] PDU Session Establishment Request - 5G | ShareTechnote, 6月 23, 2025にアクセス, https://www.sharetechnote.com/html/5G/5G_PDUSessionEstablishment.html
[12] 3GPP TS 24.501, 6月 23, 2025にアクセス, ftp://www.3gpp.org/tsg_ct/WG1_mm-cc-sm_ex-CN1/TSGC1_124e/inbox/drafts/C1-20iafa-was-C1-203068-v04-RA.doc
[13] Authentication Mechanisms in the 5G System - Journal of Web Engineering, 6月 23, 2025にアクセス, https://journals.riverpublishers.com/index.php/JICTS/article/download/5707/5725
[14] TS 33.501 Security Architecture and Procedures for 5G System - Tech-invite, 6月 23, 2025にアクセス, https://www.tech-invite.com/3m33/tinv-3gpp-33-501.html
[15] Authentication Mechanisms in the 5G System - Journal of Web Engineering, 6月 23, 2025にアクセス, https://journals.riverpublishers.com/index.php/JICTS/article/download/5707/5725/25323
[16] AUSF Software Architecture - free5GC, 6月 23, 2025にアクセス, https://free5gc.org/doc/Ausf/design/
[17] nausf-auth Service, 6月 23, 2025にアクセス, https://dstest.info/RestDict/Dictionary/nausf-auth.html
[18] Open-source 5G: Service Based Architecture: HTTP/2 & OpenAPI - Ryan Decker, 6月 23, 2025にアクセス, https://nuradiocncpts.wordpress.com/2024/01/23/open-source-5g-service-based-architecture-http-2-openapi/
[19] TS29503_Nudm_NIDDAU.yaml - 3GPP, 6月 23, 2025にアクセス, https://www.3gpp.org/ftp/specs/archive/OpenAPI/Rel-16/TS29503_Nudm_NIDDAU.yaml
[20] TS29503_Nudm_RSDS.yaml - jdegre/5GC_APIs - GitHub, 6月 23, 2025にアクセス, https://github.com/jdegre/5GC_APIs/blob/Rel-18/TS29503_Nudm_RSDS.yaml
[21] inside TS 24.501: NAS Security - Tech-invite, 6月 23, 2025にアクセス, https://www.tech-invite.com/3m24/toc/tinv-3gpp-24-501_d.html
[22] C1-21xxxx (rev of 0994)_5GProtoc17_24.501_Consistent ngKSI IE name-v1.docx - 3GPP, 6月 23, 2025にアクセス, https://www.3gpp.org/ftp/tsg_ct/WG1_mm-cc-sm_ex-CN1/TSGC1_128e/Inbox/drafts/C1-21xxxx%20(rev%20of%200994)_5GProtoc17_24.501_Consistent%20ngKSI%20IE%20name-v1.docx
[23] Content for TS 24.501 Word version: 19.2.0, 6月 23, 2025にアクセス, https://www.tech-invite.com/3m24/toc/tinv-3gpp-24-501_zu.html
[24] 3GPP TS 24.501, 6月 23, 2025にアクセス, https://www.3gpp.org/ftp/tsg_ct/WG1_mm-cc-sm_ex-CN1/TSGC1_136e/Inbox/Drafts/EriDraft02_C1-22abcd_was3458_MISC01_SSCmode_24501_r15_v5.doc
[25] C4-221xxx_v1_TEI16, ETSUN 29.502 Smf URI R16.docx - 3GPP, 6月 23, 2025にアクセス, ftp://www.3gpp.org/tsg_ct/WG4_protocollars_ex-CN4/TSGCT4_108e_meeting/Inbox/Drafts/6.3_19_SMF/C4-221xxx_v1_TEI16,%20ETSUN%2029.502%20Smf%20URI%20R16.docx
[26] 3GPP TS ab.cde, 6月 23, 2025にアクセス, https://www.3gpp.org/ftp/tsg_ct/WG3_interworking_ex-CN3/DRAFT_SPEC_IMPLEMENTATIONS/CT_92e/Draft/Final-29523-g50-cl_mcc.doc
[27] 3GPP TS 29.512, 6月 23, 2025にアクセス, ftp://www.3gpp.org/tsg_ct/WG3_interworking_ex-CN3/TSGC3_130_Xiamen/Inbox/Drafts/XRM/C3-234075r2%20XRM%20Introduction%20of%20new%20features%20for%20PDU%20set%20handle%20and%20RT%20latency%2029.512%20Rel-18.doc
[28] Specification # 29.512 - 3GPP, 6月 23, 2025にアクセス, https://www.3gpp.org/dynareport/29512.htm
[29] PFCP - Wikipedia, 6月 23, 2025にアクセス, https://en.wikipedia.org/wiki/PFCP
[30] PFCP protocol - Nokia Documentation Center, 6月 23, 2025にアクセス, https://documentation.nokia.com/mag-c/24-3/books/pfcp/pfcp-protocol.html
[31] RrcReconfiguration - 5G | ShareTechnote, 6月 23, 2025にアクセス, https://www.sharetechnote.com/html/5G/5G_RRC_Reconfiguration.html
[32] 5G QoS | PDF | Quality Of Service | 4 G - Scribd, 6月 23, 2025にアクセス, https://de.scribd.com/document/725746594/5G-QoS
[33] QoS in 5G Networks | Award Solutions, 6月 23, 2025にアクセス, https://www.awardsolutions.com/portal/resources/qos-in-5g
[34] Specification # 29.281 - 3GPP, 6月 23, 2025にアクセス, https://www.3gpp.org/dynareport/29281.htm
[35] GTP Overview - Palo Alto Networks, 6月 23, 2025にアクセス, https://docs.paloaltonetworks.com/service-providers/10-1/mobile-network-infrastructure-getting-started/gtp/gtp-basics
[36] Demystifying 5G Data Transfer Part 1: Networking Basics - Ryan Decker - WordPress.com, 6月 23, 2025にアクセス, https://nuradiocncpts.wordpress.com/2024/12/18/demystifying-5g-data-transfer-part-1-networking-basics/
0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?