目次

1. はじめに：5G SA VoNR着信呼の背景と範囲
2. VoNRにおける主要な5Gネットワーク機能とその役割
3. エンドツーエンドメッセージシーケンスチャート
4. 着信呼フローのフェーズ別分析
- 4.1 フェーズ1：ページングとRRC接続確立
- 4.2 フェーズ2：NASセキュリティ確立（認証とセキュリティモード）
5. 結論
6. 関連テーブル
7. 引用文献

1. はじめに：5G SA VoNR着信呼の背景と範囲

5Gスタンドアローン（SA）アーキテクチャは、新しい5Gコアネットワーク（5GC）と5G New Radio（NR）をアクセス技術として利用し、モバイル通信の進化を牽引しています¹。この進化したネットワークにおいて、音声サービスはVoice over New Radio（VoNR）を通じて提供されます。VoNRは、IPマルチメディアサブシステム（IMS）プラットフォームを基盤としており、IMSはセッション開始プロトコル（SIP）を呼/セッション関連のシグナリングに、セッション記述プロトコル（SDP）を音声コーデックなどのメディア詳細の記述に用いています¹。VoNRは、Adaptive Multi-Rate Wideband（AMR-WB）やEnhanced Voice Services（EVS）といった高品質なコーデックを提供することで、従来の回線交換サービスと比較して、よりクリアで自然な音声体験と、大幅に高速な呼設定時間（平均5秒から0.25～2.5秒へ短縮）を実現しています¹。VoNRサービスは、3GPP仕様のGSMAプロファイルに基づいて構築されており、グローバルな相互運用性を保証しています¹。

本報告書では、UE（User Equipment）が電源投入からSIB（System Information Block）受信を完了し、初期登録を終えて待機状態（アイドル/非アクティブ）にある状況を前提としています。この状態は、UEが5GMM-IDLEモードにあり、3GPPアクセス上でRRC_IDLEまたはRRC_INACTIVE状態にあることを意味します。5GMM-IDLEモードでは、UEとネットワーク間にN1 NASシグナリング接続は存在しません²。

本報告書の目的は、着信VoNR呼の終端間メッセージフローを詳細に分析することです。ネットワークが呼を検出してから、UEが音声セッションを確立し、通話中状態に移行するまでの完全なシーケンスを、3GPP仕様に厳密に準拠して解説します。各ステップにおけるメッセージ、プロトコル、インターフェース、およびチャネルを特定し、その技術的な意義と相互関係を明らかにします。

2. VoNRにおける主要な5Gネットワーク機能とその役割

VoNR呼フローに関与する主要な参加者とそれぞれの役割を以下に示します。

App (アプリケーション on UE): ユーザー機器（UE）上のユーザー向け音声アプリケーション（例：ダイヤラー）を表します。SIPを使用して音声呼の開始と終了を行います。
5G Modem (UE): ユーザー機器内のハードウェアおよびソフトウェアコンポーネントで、無線通信、RRC（Radio Resource Control）、およびNAS（Non-Access Stratum）プロトコル処理を担当します。UEの5GMM（5G Mobility Management）および5GSM（5G Session Management）レイヤーを内包します。
gNB (Next Generation NodeB): NG-RAN（Next Generation Radio Access Network）の一部である5G基地局です。無線リソース管理、スケジューリング、およびUEとの間のユーザープレーンデータ転送を担当します。UEとのUuインターフェース、AMFとのN2インターフェース、UPFとのN3インターフェースを扱います。
AMF (Access and Mobility Management Function): 5GCのコントロールプレーン機能で、接続管理、モビリティ管理、およびNASシグナリングを担当します。UEの登録、到達性、およびセキュリティを扱います¹。gNB（N2）、SMF（N11）、AUSF（N12）、およびUDM（N8）と連携します。
SMF (Session Management Function): 5GCのコントロールプレーン機能で、PDU（Protocol Data Unit）セッションの確立、変更、および解放を担当します。IPアドレス割り当て、QoSポリシーを管理し、UPF（N4）、PCF（N7）、およびUDM（N10）と連携します¹。
AUSF (Authentication Server Function): 5GCのコントロールプレーン機能で、UEの認証とセキュリティキーの生成を担当します。AMF（N12）およびUDM（N13）と連携します³。
UDM (Unified Data Management): 5GCのコントロールプレーン機能で、認証クレデンシャルを含む加入者サブスクリプションデータを保存し、UEコンテキストを管理します¹。AMF（N8）、SMF（N10）、およびAUSF（N13）と連携します。
UDR (Unified Data Repository): ネットワーク機能（例：UDM、PCF）向けの構造化データを保存する5GCのデータリポジトリです⁴。
PCF (Policy Control Function): 5GCのコントロールプレーン機能で、PDUセッションやQoSフローのQoSポリシーを含むネットワーク動作を制御するポリシー規則を提供します¹。SMF（N7）およびUDM（N10）と連携します。
UPF (User Plane Function): 5GCのユーザープレーン機能で、パケットルーティングと転送、QoS適用、およびPDUセッションのアンカリングを担当します¹。gNB（N3）およびSMF（N4）と連携します。
DN (Data Network): UEにサービスを提供する外部ネットワーク（例：インターネット、IMSネットワーク）を表します。VoNRの場合、主にIMSコアネットワークを指します¹。

3. エンドツーエンドメッセージシーケンスチャート

4. 着信呼フローのフェーズ別分析

このセクションでは、5G SA VoNR着信呼フローの終端間メッセージシーケンスをフェーズごとに詳細に分析し、メッセージ、プロトコル、インターフェース、チャネル、および関連する3GPP仕様について詳述します。

4.1 フェーズ1：ページングとRRC接続確立

このフェーズでは、ネットワークが省電力状態のUEへの着信呼を検出し、専用の無線接続を確立する初期ステップを扱います。

1. DN -> AMF: Nudm_UECM_Registration (SUPI, Paging Request)
- 背景: UEが5GMM-IDLEモード（待機状態）にあるときに、IMSコアネットワーク（DNの一部）に着信音声呼が到着すると、IMSはUEの位置を特定する必要があります。IMSは通常、呼要求をUDM（Unified Data Management）経由でAMF（Access and Mobility Management Function）に転送します。UDMはUEのAMFを登録しているため、AMFにUEをページングするようトリガーします⁵。5GSではPDUセッションは常にUEによって設定されると記載されていますが⁶、これは着信呼の場合、UEが音声呼のためのPDUセッション変更を開始する前に、ネットワークがUEへの接続を確立する必要があることを示唆しています。AMFがUEをページングする最も一般的なトリガーは、IMS/DNからUDMに通知される、UDMからのモバイル終端サービス要求です。Nudm_UECM_Registrationサービスは、NFがUEコンテキストをUDMに登録するために使用され、UDMがAMFに保留中のモバイル終端サービスを通知するためにも使用できます⁵。
- 詳細: このメッセージは、UEへの着信呼の通知を受信したUDMが、サービスを提供するAMFにUEをページングするよう通知する5GC内部の通信を表します。Nudm_UECM_Registrationサービスは、UDMによって提供されるNudm_UEContextManagementサービスの一部です（TS 29.503）。この相互作用は、AMFがUEに到達する必要があることを認識するために不可欠です。
- 技術的含意: AMFによるページングの開始は、IMS/DNがUDMに着信呼を通知し、UDMがAMFに通知した直接的な結果です。このことは、VoNRサービスを可能にするIMSと5GCの密接な連携を示しています。UDMはUEコンテキストと到達性情報の中心的なリポジトリとして機能し、ネットワークが開始するサービスの論理的な中心点となります。
2. AMF -> gNB: PAGING (UE ID, TAI List, Paging Priority)
3. gNB -> UE: Paging (UE ID, Paging Cause: Mobile Terminating Call)
- 背景: NGAP PAGINGメッセージを受信すると、gNBは無線インターフェースを介してページングメッセージをブロードキャストし、UEに到達させる責任を負います。
- 詳細: gNBは、Uu無線インターフェース上でRRC Pagingメッセージ（RRC, TS 38.331）をブロードキャストします¹⁵¹⁶¹⁷。このメッセージは、論理チャネルであるPCCH (Paging Control Channel)で運ばれます。PCCHは、トランスポートチャネルであるPCH (Paging Channel)にマッピングされ、物理層伝送のためにPDSCH (Physical Downlink Shared Channel)にマッピングされます。Paging Cause IEは、ページングの理由を示し、この場合は「Mobile Terminating Call」です。
- 技術的含意: 論理チャネル（PCCH）からトランスポートチャネル（PCH）、そして物理チャネル（PDSCH）へのマッピングは、無線インターフェースの階層的なアーキテクチャを示しています。この正確なマッピングにより、UEは省電力状態であっても、いつ、どこでページングメッセージを待機すべきかを正確に把握できます。
4. UE -> gNB: RRCSetupRequest (UE ID, Establishment Cause: Mobile Terminating Call)
- 背景: RRC Pagingメッセージで自身のIDを受信し、識別したUEは、ネットワークと通信するために専用の無線接続を確立する必要があります。
- 詳細: UEは、RRCSetupRequestメッセージ（RRC, TS 38.331）をgNBに送信することでRRC接続確立手順を開始します¹⁵¹⁶¹⁷¹⁸¹⁹。このメッセージは、初期のアップリンクRRCメッセージに使用される論理チャネルであるUL-CCCH (Uplink Common Control Channel)で送信されます。UL-CCCHは、専用無線ベアラが設定される前に使用されるデフォルトのSRB（Signaling Radio Bearer）であるSRB0 (Signaling Radio Bearer 0)で運ばれます¹⁵¹⁷¹⁹。UL-CCCHは、UL-SCH (Uplink Shared Channel)トランスポートチャネルにマッピングされ、物理伝送のためにPUSCH (Physical Uplink Shared Channel)にマッピングされます。メッセージ内のEstablishment Cause IEは、「Mobile Terminating Call」と明示的に示されています。
- 技術的含意: RRCSetupRequest内のEstablishment Causeは、UEがRRC接続を開始する理由をgNB、そしてAMFに直接伝えます。これにより、ネットワークは音声呼のような重要なサービスのために接続確立を優先し、効率的に処理することができます。
5. gNB -> UE: RRCSetup (SRB1 config, initial C-RNTI)
- 背景: UEの要求に応答して、gNBは専用RRC接続を確立するために必要な無線リソース構成を提供します。
- 詳細: gNBは、RRCSetupメッセージ（RRC, TS 38.331）をUEに送信します¹⁵¹⁶¹⁷¹⁸¹⁹。このメッセージは、SRB0で運ばれるDL-CCCH (Downlink Common Control Channel)で送信されます¹⁵¹⁷¹⁹。RRCSetupメッセージには、SRB1 (Signaling Radio Bearer 1)の構成とinitial C-RNTI (Cell Radio Network Temporary Identifier)が含まれます。DL-CCCHは、DL-SCH (Downlink Shared Channel)トランスポートチャネルにマッピングされ、物理伝送のためにPDSCH (Physical Downlink Shared Channel)にマッピングされます。
- 技術的含意: initial C-RNTIの割り当てとSRB1の構成は、共通の共有リソースから専用のUE固有のリソースへの重要な移行を示します。これは、安全で信頼性の高いコントロールプレーン接続を確立し、上位層のNASシグナリングに備えるための基本的なステップです。
6. UE -> gNB: RRCSetupComplete (Selected PLMN, gNB-CU UE F1AP ID)
- 背景: UEはgNBによって提供された無線リソース構成を認識し、適用することで、RRC接続確立を完了します。
- 詳細: UEは、RRCSetupCompleteメッセージ（RRC, TS 38.331）をgNBに送信します¹⁵¹⁶¹⁷¹⁸¹⁹。このメッセージは、新しく構成されたUL-DCCH (Uplink Dedicated Control Channel)で送信され、SRB1で運ばれます¹⁵¹⁷¹⁹。UL-DCCHは、UL-SCHトランスポートチャネルにマッピングされ、物理伝送のためにPUSCHにマッピングされます。メッセージには、Selected PLMNと、gNBアーキテクチャが分割されている場合（CU-CP/CU-UP）にはgNB-CU UE F1AP IDが含まれます。
- 技術的含意: RRCSetupCompleteメッセージは、UEがRRC_IDLE/RRC_INACTIVE状態からRRC_CONNECTED状態への移行が成功したことを示します。この状態は、それ以降のNASシグナリングおよびユーザープレーンデータ転送の前提条件であり、UEがネットワークのコントロールプレーンおよびユーザープレーンと完全に通信できるようになったことを示します。

4.2 フェーズ2：NASセキュリティ確立（認証とセキュリティモード）

このフェーズでは、UEとAMF間の後続のNASメッセージがすべて完全性保護され、暗号化されることを保証し、安全な通信チャネルを確立します。

7. gNB -> AMF: UL NAS TRANSPORT (5GMM: SERVICE REQUEST)
- 背景: RRC接続が確立された後、UEはNASメッセージをAMFに送信できるようになります。UEのページングへの応答は、SERVICE REQUESTメッセージにカプセル化されます。
- 詳細: gNBは、UEからSRB1（UL-DCCH）を介して受信したSERVICE REQUESTメッセージをAMFに転送します。これは、N2インターフェース上でUL NAS TRANSPORTメッセージ（NGAP, TS 38.413）を使用して行われます⁸¹³。SERVICE REQUESTメッセージ自体は、UEのページングへの応答とサービスの再開意図を示す5GMMメッセージです（TS 24.501）。
- 技術的含意: このステップは、アクセス層（AS）と非アクセス層（NAS）の明確な責任分離を示しています。gNB（AS）は、NASメッセージをUEとAMF（NAS）間で透過的に転送し、5Gアーキテクチャにおけるこれらの層のモジュール性と独立性を強調しています。
8. AMF -> UE: AUTHENTICATION REQUEST (RAND, AUTN, EAP message)
- 背景: 新しいサービス要求の場合、または既存のセキュリティコンテキストが有効でない、あるいは十分に新しいものでない場合、AMFはUEの身元を確認し、安全なNASコンテキストを確立するために、一次認証およびキー合意手順を開始します。
- 詳細: AMFは、AUTHENTICATION REQUESTメッセージ（5GMM, TS 24.501）をUEに送信します²⁰³²¹²²。このメッセージは、UL-DCCH (SRB1)上でUuインターフェースを介して送信されます。これには、RAND（ランダムチャレンジ）やAUTN（認証トークン）などの重要な認証パラメータが含まれ、EAPベースの認証（例：EAP-AKA'）が使用される場合はEAP messageも含まれる可能性があります³²¹²³。
- 技術的含意: 認証は、機密性の高いNAS通信を進める前に必須かつ基本的なステップです。これにより、正当なUEのみがネットワークサービスにアクセスできるようになり、不正なアクセスを防ぎ、加入者データを保護します。
9. AMF -> AUSF: Nausf_UEAuthentication_Authenticate Request (SUPI, Auth Type)
- 背景: AMFは認証を直接実行せず、この機能を認証サーバー機能（AUSF）に委譲します。
- 詳細: AMFは、Nausf_UEAuthentication_Authenticate RequestをAUSFに送信します（サービスベースインターフェース、N12, TS 29.503）⁵²⁴。この要求には、UEのSUPI (Subscription Permanent Identifier)とAuthentication Type（例：5G-AKA）が含まれます³²⁵²³。
- 技術的含意: この相互作用は、5GCのサービスベースアーキテクチャ（SBA）の例であり、ネットワーク機能が他のNFが利用できるサービス（例：Nausf_UEAuthentication）を公開しています。このモジュール性は、従来のポイントツーポイントインターフェースと比較して、柔軟性とスケーラビリティを向上させます。
10. AUSF -> UDM: Nudm_UEAuthentication_Get Request (SUPI, Auth Type)
- 背景: AUSFは、UEの認証クレデンシャルとベクトルを必要とします。これらはUDM（具体的には、UDMの一部である認証クレデンシャルリポジトリおよび処理機能 - ARPF）に保存されています。
- 詳細: AUSFは、Nudm_UEAuthentication_Get Request（サービスベースインターフェース、N13, TS 29.503）を使用してUDMから認証情報を要求します⁵²⁴。この要求には、SUPIとAuth Typeも含まれます。
- 技術的含意: UDM/UDRは、認証情報を含むすべての加入者データの中央リポジトリとして機能します。この一元化により、データ管理が簡素化され、ネットワーク全体で一貫性が確保され、高度な加入者サービスを可能にする重要な要素となります。
11. UDM -> UDR: Nudr_DR_Query (SUPI)
- 背景: UDMは、実際の加入者データ（認証ベクトルを含む）をUDR（Unified Data Repository）から取得します。
- 詳細: UDMは、Nudr_DR_Query（サービスベースインターフェース、N8, TS 29.504）を使用してUDRにクエリを送信します。このメッセージには、加入者を識別するためのSUPIが含まれます。
12. UDR --> UDM: Nudr_DR_Query Response (Auth Vectors, Subscriber Data)
- 背景: UDRは、要求された認証ベクトルと加入者データをUDMに返します。
- 詳細: UDRは、Auth Vectors（例：RAND、XRES*、KAUSFを含む5G HE AV）およびその他のSubscriber DataをUDMに応答します（TS 29.504）。
13. UDM --> AUSF: Nudm_UEAuthentication_Get Response (5G HE AV: RAND, XRES, KAUSF)*
- 背景: UDMは認証ベクトルをAUSFに転送します。
- 詳細: UDMは、RAND、XRES*、およびKAUSFを含む5G Home Environment Authentication Vector (5G HE AV)を含むNudm_UEAuthentication_Get ResponseをAUSFに送信します³²⁵⁵。
14. AUSF --> AMF: Nausf_UEAuthentication_Authenticate Response (5G AV: RAND, AUTN, HXRES, KSEAF)*
- 背景: AUSFは認証ベクトルを処理し、必要な情報とキーをAMFに提供します。
- 詳細: AUSFは、Nausf_UEAuthentication_Authenticate ResponseでAMFに応答します。このメッセージには、RAND、AUTN、HXRES*、および重要なKSEAF (Security Anchor Function Key)を含む5G Authentication Vector (5G AV)が含まれます³²⁵⁵。KSEAFは認証中に導出されるアンカーキーです。
15. UE -> AMF: AUTHENTICATION RESPONSE (RES, EAP message)*
- 背景: AMFからAUTHENTICATION REQUESTを受信したUEは、自身の保存されたクレデンシャル（例：USIM）を使用して独自の認証計算を実行します。
- 詳細: UEは、RANDと自身の秘密鍵に基づいてRES*（応答）を計算します。その後、AUTHENTICATION RESPONSEメッセージ（5GMM, TS 24.501）をAMFに送信し、RES*と場合によってはEAP messageを含めます²⁰³²¹²²。このメッセージはUL-DCCH (SRB1)を介して送信されます。
16. AMF -> AMF: Derive KAMF (from KSEAF, SUPI, ABBA)
- 背景: 認証が成功した後、AMFはNASシグナリングを保護するために不可欠なKAMFキーを導出します。
- 詳細: AMFは、AUSFから受信したKSEAFと、SUPIおよびABBA (Anti-Bypass Bit for Authentication)パラメータから、KAMF (Access and Mobility Management Function Key)を内部的に導出します（TS 33.501, clause 6.2 and Annex A）³²⁵。KAMFはNASおよびASセキュリティのルートキーです。
- 技術的含意: 階層的なキー導出プロセス（K -> CK/IK -> KAUSF -> KSEAF -> KAMF -> KgNB -> KRRC/KUP）は、異なるセキュリティ目的とネットワークドメインに異なるキーが使用されることを保証します。この設計原則は、NH（Next Hop）とNCC（Next Hop Chaining Count）の使用と相まって、前方セキュリティを提供します。これは、下位レベルのキーが侵害されても、上位レベルまたは将来のキーが侵害されないことを意味します³²⁵。
17. AMF -> UE: SECURITY MODE COMMAND (NAS security algorithms, ngKSI)
- 背景: KAMFが確立された後、AMFはNASセキュリティモード制御手順を開始し、NASメッセージの完全性保護と暗号化をアクティブにします。
- 詳細: AMFは、SECURITY MODE COMMANDメッセージ（5GMM, TS 24.501）をUEに送信します²⁰³²¹²²。このメッセージは、新しく導出されたKAMFを使用して完全性保護され、暗号化されます（TS 24.501, clause 4.4.2）。これには、NAS security algorithms（例：完全性保護のための128-5G-IA0/1/2/3、暗号化のための128-5G-EA0/1/2/3）と、現在の5G NASセキュリティコンテキストを示すngKSI (Next Generation Key Set Identifier)が指定されます²⁰¹¹。また、IMEISV requestが含まれる場合もあります²¹。このメッセージはUL-DCCH (SRB1)で送信されます。
- 技術的含意: NASセキュリティ（完全性と暗号化）のアクティブ化は、極めて重要です。これにより、重要なシグナリングメッセージ（モビリティやセッション管理など）が盗聴や改ざんから保護され、コントロールプレーンの機密性と完全性が保証されます。
18. UE -> UE: Derive KNASint, KNASenc (from KAMF)
- 背景: SECURITY MODE COMMANDを受信したUEは、自身のNASセキュリティキーを導出します。
- 詳細: UEは、SECURITY MODE COMMANDで示されたアルゴリズムに基づいて、KAMFからKNASint（NAS完全性キー）とKNASenc（NAS暗号化キー）を内部的に導出します（TS 33.501, Annex A）³²⁵。
19. UE -> AMF: SECURITY MODE COMPLETE (IMEISV, NAS message container)
- 背景: UEはNASセキュリティのアクティブ化を確認し、保留中のNASメッセージを安全に送信できるようになります。
- 詳細: UEは、SECURITY MODE COMPLETEメッセージ（5GMM, TS 24.501）をAMFに送信します²⁰³²¹²²。このメッセージは、新しく導出されたKNASintとKNASencを使用して完全性保護され、暗号化されます。要求された場合はIMEISV (International Mobile Equipment Identity Software Version)とNAS message containerが含まれる場合があります²¹。もし初期のSERVICE REQUESTメッセージ（またはREGISTRATION REQUESTのような他の初期NASメッセージ）に、セキュリティコンテキストの欠如のためにクリアテキストで送信された機密IEが含まれていた場合、元のメッセージ全体がこのNAS message container内に再送信され、今度は完全性保護され、暗号化されます²⁰²¹。このメッセージはUL-DCCH (SRB1)で送信されます。
- 技術的含意: SECURITY MODE COMPLETEのNAS message container内に初期NASメッセージ（機密IEが含まれていた場合）を再送信するメカニズムは、初期送信がクリアテキストであったとしても、すべての重要な情報が最終的に安全に送信されることを保証する巧妙な設計です。これは、初期アクセスセキュリティを処理するための堅牢な設計です。
20. AMF -> AMF: Establish SRB2 (for NAS messages)
- 背景: NASセキュリティが確立された後、高優先度のNASメッセージ、特にセッション管理に関連するメッセージのために、専用のシグナリング無線ベアラ（SRB2）が構成されます。
- 詳細: SRB1はRRCメッセージとNASメッセージの両方を運びますが、SRB2は通常、特定の高優先度NASメッセージ、特に5GSM（PDUセッション管理）に関連するメッセージのために確立されます¹⁵。これは、AMFがgNBにUE内のSRB2を構成するようトリガーする内部AMFアクションですが、SRB2設定のための明示的なRRCメッセージは、後のRRCReconfigurationメッセージの一部となる場合があります。
- 技術的含意: SRB1とSRB2の区別（SRB2が通常高優先度を持つ）は、コントロールプレーンシグナリングにもQoS要件があることを強調しています。音声呼設定のような高優先度NASメッセージは、VoNRが約束する高速な呼設定時間¹に合致するために、優先的な処理が必要です。

4.3 フェーズ3：初期コンテキスト設定（既存のPDUセッション用）

このフェーズでは、gNBがUEの既存のPDUセッションに必要なすべての情報とリソースを割り当て、潜在的なユーザープレーンデータに備えることを保証します。

21. AMF -> SMF: Nsmf_PDUSession_UpdateSMContext Request (SUPI, PDU Session ID, UE Context)
- 背景: UEがRRC_CONNECTED状態に移行し、NASセキュリティが確立された後、AMFはUEの既存のPDUセッションに対するサービス準備状況と状態変化をSMFに通知します。
- 詳細: AMFは、UEが既存のPDUセッションに対してCM-CONNECTED状態（5GMM-CONNECTEDモード経由）にあることをSMFに通知します。これは、Nsmf_PDUSession_UpdateSMContext Request（サービスベースインターフェース、N11, TS 23.502）を介して行われます²⁶。このメッセージには、SUPI、アクティブなセッションのPDU Session ID(s)、および関連するUE Context情報が含まれます。
- 技術的含意: このメッセージは、AMFとSMF間の重要な連携点であり、両方のコントロールプレーン機能がUEの接続状態に関して同期していることを保証します。この同期は、効率的なセッション管理とユーザープレーンのアクティブ化にとって不可欠です。
22. SMF -> UPF: PFCP Session Modification Request (PDU Session ID, F-TEID, QoS Enforcement Rules)
- 背景: UEのCM-CONNECTED状態を認識したSMFは、既存のPDUセッションのユーザープレーンパスがUPFでアクティブかつ正しく構成されていることを確認する必要があります。
- 詳細: SMFは、PFCP Session Modification Requestメッセージ（PFCP, TS 29.244）をN4インターフェース上でUPFに送信します²⁷²⁸²⁹³⁰。このメッセージは、PDU Session ID、ユーザープレーンのトンネルのためのF-TEID (F-Traffic Endpoint Identifier)、および既存のQoSフローのためのQoS Enforcement Rulesを含む、ユーザープレーンに必要な情報をUPFに更新します。これにより、ユーザープレーンリソースが割り当てられ、データ転送の準備が整います。
- 技術的含意: N4インターフェース上のPFCPプロトコルは、5Gにおけるコントロールプレーンとユーザープレーンの分離（CUPS）の基礎です。これにより、SMF（コントロールプレーン）がUPF（ユーザープレーン）を動的に制御できるようになり、コントロールプレーン機能とは独立してユーザープレーンリソースを柔軟かつスケーラブルに展開できます。
23. UPF --> SMF: PFCP Session Modification Response (PDU Session ID, Cause)
- 背景: UPFは、SMFからのセッション変更要求を認識します。
- 詳細: UPFは、PFCP Session Modification Response（PFCP, TS 29.244）でSMFに応答し、要求された変更の成功または失敗を示します²⁷²⁸²⁹³⁰。
24. SMF --> AMF: Nsmf_PDUSession_UpdateSMContext Response
- 背景: SMFは、PDUセッションコンテキストがUPFで更新されたことをAMFに確認します。
- 詳細: SMFは、Nsmf_PDUSession_UpdateSMContext ResponseをAMFに送信します（サービスベースインターフェース、N11, TS 23.502）。
25. AMF -> gNB: INITIAL CONTEXT SETUP REQUEST (PDU Session Resource Setup List, UE Aggregate Max Bit Rate, Security Indication)
- 背景: AMFは、UEのアクティブなPDUセッションについてgNBに通知し、対応するデータ無線ベアラ（DRB）を設定するようgNBに要求する必要があります。
- 詳細: AMFは、INITIAL CONTEXT SETUP REQUESTメッセージ（NGAP, TS 38.413）をgNBに送信します⁸⁹¹⁰¹¹¹²¹³¹⁴。このメッセージには、gNBがUEコンテキストを構成するために不可欠な情報が含まれており、これにはPDU Session Resource Setup List IE（既存のPDUセッションとそのQoSフローの詳細）、UE Aggregate Maximum Bit Rate IE、およびSecurity Indication IE（ユーザープレーンの完全性保護と暗号化要件を指定）が含まれます⁹。
- 技術的含意: このメッセージは、gNBがアクティブなPDUセッションのユーザープレーン接続（DRB）をUuインターフェース上で確立するためのトリガーとなります。これにより、コントロールプレーンコンテキスト（AMF/SMFによって管理される）と無線アクセスネットワークのリソース割り当てが効果的に橋渡しされます。
26. gNB -> UE: RRCReconfiguration (DRB setup for existing PDU sessions, K_gNB_ derivation)
- 背景: gNBは、既存のPDUセッションのデータ無線ベアラ（DRB）を確立するために、UEの無線リソースを構成します。
- 詳細: gNBは、RRCReconfigurationメッセージ（RRC, TS 38.331）をUL-DCCH (SRB1)を介してUEに送信します¹⁷¹⁸。このメッセージには、既存のPDUセッションのためのDRB setupの指示が含まれます。同時に、gNBとUEは、KAMFとアップリンクNAS COUNTからK_gNB_キーを導出し、その後、ASセキュリティのためにKRRCint、KRRCenc、KUPint、KUPencを導出します（TS 33.501, Annex A）³²⁵。これらのキーは、DRB上のRRCメッセージとユーザープレーンデータを完全性保護し、暗号化するために使用されます。
- 技術的含意: このステップは、アクセス層（AS）セキュリティのアクティブ化を示しており、RRCメッセージとユーザープレーンデータの完全性保護と暗号化が含まれます。これは、無線インターフェース上の実際のユーザー通信とコントロールプレーンシグナリングを盗聴や改ざんから保護するために不可欠です。
27. UE -> gNB: RRCReconfigurationComplete
- 背景: UEはRRCReconfigurationを認識し、既存のPDUセッションのDRBが設定されたことを確認します。
- 詳細: UEは、RRCReconfigurationCompleteメッセージ（RRC, TS 38.331）をUL-DCCH (SRB1)を介してgNBに送信します¹⁷¹⁸。
28. gNB --> AMF: INITIAL CONTEXT SETUP RESPONSE (PDU Session Resource Setup Response List)
- 背景: gNBは、UEコンテキストとDRBのセットアップが成功したことをAMFに通知します。
- 詳細: gNBは、INITIAL CONTEXT SETUP RESPONSEメッセージ（NGAP, TS 38.413）をAMFに送信します⁸⁹¹⁰¹¹¹²¹³¹⁴。このメッセージには、正常に確立されたPDUセッションリソースを示すPDU Session Resource Setup Response Listが含まれます。

4.4 フェーズ4：音声QoSのためのPDUセッション変更

このフェーズでは、既存のPDUセッションを変更するか、新しいPDUセッションを確立して、音声呼のための専用QoSフローを保証リソースとともに割り当てます。

29. DN -> PCF: Npcf_PolicyAuthorization_Update (UE ID, QoS Requirements for Voice)
- 背景: VoNR呼の場合、IMS（DNの一部）は、音声メディアトラフィックが適切なQoS（Quality of Service）を受信することを保証する必要があります。これは、専用のQoSフローを要求することによって達成されます。IMS内のアプリケーション機能（AF）は、PCFと連携してQoS規則を承認し、プロビジョニングします。
- 詳細: IMS（AFとして機能）は、Npcf_PolicyAuthorization_Update（サービスベースインターフェース、N7, TS 23.503）を使用してPCFからポリシー承認を要求します⁶。この要求には、UE IDと音声呼のための特定のQoS Requirements（例：会話音声のための5QI=1）が含まれます。
- 技術的含意: この相互作用は、5GにおけるQoSのポリシー駆動型特性を強調しています。IMS/AFはネットワークリソースを直接構成するのではなく、PCFに特定のQoSを要求し、PCFはこれをSMFのための実行可能なポリシー規則に変換します。これにより、サービス要件とネットワーク適用が分離され、柔軟性が提供されます。
30. PCF -> SMF: Npcf_PolicyControl_UpdateNotify (QoS Rules, QFI for Voice)
- 背景: IMSからQoS要求を受信したPCFは、音声のための専用QoSフローを含むように、特定のPDUセッションのポリシー規則を生成または更新します。
- 詳細: PCFは、更新されたポリシー規則をNpcf_PolicyControl_UpdateNotify（サービスベースインターフェース、N7, TS 23.503）を使用してSMFにプッシュします⁶。このメッセージには、新しい音声QoSフローのためのQoS RulesとQFI (QoS Flow Identifier)が含まれます。QoSフローはSMFによって制御され、PDUセッションの確立または変更によって確立される場合があります⁶。
- 技術的含意: このステップは、QoSリソースの動的なプロビジョニングを示しています。事前プロビジョニングではなく、ネットワークはサービス要件に基づいてオンデマンドでQoSフローを確立または変更でき、リソース利用を最適化し、多様な5Gユースケースをサポートします。
31. SMF -> UE: DL NAS TRANSPORT (5GSM: PDU SESSION MODIFICATION COMMAND (QoS Rules, QFI))
- 背景: SMFは、既存のPDUセッション内で音声用の新しいQoSフローをアクティブにするようUEに指示します。
- 詳細: SMFは、PDU SESSION MODIFICATION COMMAND（5GSM, TS 24.501）をUEに送信します³¹²¹²²。このメッセージは、DL NAS TRANSPORTメッセージ（5GMM, TS 24.501）にカプセル化され、UL-DCCH (SRB2)を介して送信されます。コマンドには、音声サービスのためのAuthorized QoS RulesとAuthorized QoS Flow Descriptions（QFIを含む）が含まれます。
- 技術的含意: このメッセージは、PDUセッションとその関連QoSフローをUEと直接管理する5GSMプロトコル（NASの一部）の役割を強調しています。これは、ネットワークがセッション固有の構成を端末に通信する方法です。
32. UE -> SMF: UL NAS TRANSPORT (5GSM: PDU SESSION MODIFICATION COMPLETE)
- 背景: UEはPDUセッションの変更を認識し、適用し、新しい音声QoSフローの準備ができたことを示します。
- 詳細: UEは、PDU SESSION MODIFICATION COMPLETEメッセージ（5GSM, TS 24.501）で応答します³¹²¹²²。このメッセージは、UL NAS TRANSPORTメッセージ（5GMM, TS 24.501）にカプセル化され、UL-DCCH (SRB2)を介して送信されます。
33. SMF -> UPF: PFCP Session Modification Request (PDU Session ID, QoS Enforcement Rules, QFI)
- 背景: SMFは、新しいQoSフロー情報をUPFに更新し、UPFが音声パケットを正しく識別、優先順位付け、転送できるようにします。
- 詳細: SMFは、別のPFCP Session Modification Request（PFCP, TS 29.244）をN4インターフェース上でUPFに送信します²⁷²⁸²⁹³⁰。この要求には、専用音声QoSフローのためのQoS Enforcement RulesとQFIが具体的に含まれます。これにより、UPFは音声パケットに正しいQoS処理（例：低遅延、高優先度）を適用します。
- 技術的含意: UPFへのPFCPメッセージは、QoSポリシーがユーザープレーンで適用される場所です。UPFは、QFIに基づいて、音声トラフィックが厳格な遅延とパケット損失要件を満たすように、特定の転送規則、バッファリング、およびスケジューリングを適用します。
34. UPF --> SMF: PFCP Session Modification Response (PDU Session ID, Cause)
- 背景: UPFはセッション変更を認識します。
- 詳細: UPFは、PFCP Session Modification Response（PFCP, TS 29.244）でSMFに応答します²⁷²⁸²⁹³⁰。
35. SMF -> gNB: Nsmf_PDUSession_UpdateSMContext Request (PDU Session ID, QoS Flow Information, QFI, DRB ID)
- 背景: SMFは、音声のための新しいQoSフローについてgNBに通知し、それに対応する専用データ無線ベアラ（DRB）を確立するようgNBに要求します。
- 詳細: SMFは、Nsmf_PDUSession_UpdateSMContext RequestをgNBに送信します（AMF経由、N2/N11インターフェース上、TS 23.502）³¹³²³³³⁴。このメッセージには、QoS Flow Information（QFIを含む）と、音声トラフィックのための特定のDRB IDの確立要求が含まれます。
36. gNB -> UE: RRCReconfiguration (DRB setup for Voice QoS, QFI, Radio Bearer ID)
- 背景: gNBは、音声QoSフローのための専用DRBを確立するために、UEの無線リソースを構成します。
- 詳細: gNBは、RRCReconfigurationメッセージ（RRC, TS 38.331）をUL-DCCH (SRB1)を介してUEに送信します¹⁷¹⁸。このメッセージには、音声QoSフローのための新しいDRB setupの構成が含まれており、QFIと割り当てられたRadio Bearer IDが含まれます。このDRBは、必要なQoSで音声メディアパケットを運ぶ準備が整いました。
- 技術的含意: 音声QoSフローのための専用DRBの確立は極めて重要です。これにより、無線リソースがリアルタイム音声の厳格な遅延と帯域幅の要件を満たすように特別に割り当てられ、ベストエフォート型データトラフィックと区別されます。
37. UE -> gNB: RRCReconfigurationComplete
- 背景: UEは音声DRBのためのRRCReconfigurationを認識し、適用します。
- 詳細: UEは、RRCReconfigurationCompleteメッセージ（RRC, TS 38.331）をUL-DCCH (SRB1)を介してgNBに送信します¹⁷¹⁸。
38. gNB --> SMF: Nsmf_PDUSession_UpdateSMContext Response (PDU Session ID, DRB ID)
- 背景: gNBは、音声QoSフローのためのDRBの確立が成功したことをSMFに通知します。
- 詳細: gNBは、Nsmf_PDUSession_UpdateSMContext ResponseをSMFに送信します（AMF経由、N2/N11インターフェース上、TS 23.502）³¹³²³³³⁴。これにより、音声QoSフローのための無線ベアラがアクティブになったことが確認されます。

4.5 フェーズ5：IMSセッション確立（SIPシグナリング）とユーザープレーンアクティベーション

この最終フェーズでは、UEのアプリケーションとIMSコア間の実際のSIPシグナリングが行われ、音声メディアパスが確立されます。

39. DN -> App: SIP INVITE (SDP Offer: Voice Codec, IP Address, Port)
- 背景: 専用のQoSフローとDRBが確立された後、IMSコアは実際の呼設定シグナリング（SIP）をUEのアプリケーションに送信できます。
- 詳細: IMSコア（DN）は、SIP INVITEメッセージ（SIP, TS 24.229）をUEのAppに送信します¹³⁵³⁶³⁷³⁸³⁹。このメッセージには、音声呼のための提案されたメディアパラメータを記述するSDP Offerが含まれており、これにはvoice codec（例：AMR-WB, EVS）、IP address、RTPのためのportが含まれます¹。このメッセージは、N6インターフェース（UPFとDN間）とN3インターフェース（gNBとUPF間）を介して、確立されたユーザープレーンパス（音声QoSのためのDRB）を介してUEに到達します。
- 技術的含意: このステップは、VoNRのサービス層としてのIMSを明確に示しています。5GCが基盤となる接続性とQoSを提供する一方で、IMSはアプリケーションレベルの呼制御（SIP）とメディアネゴシエーション（SDP）を処理します。この分離により、基盤となるアクセス技術とは独立して柔軟なサービス進化が可能になります。
40. App -> DN: SIP 100 Trying
- 背景: UEのアプリケーションは、SIP INVITEの受信を認識します。
- 詳細: UEのAppは、SIP 100 Trying暫定応答（SIP, TS 24.229）をDNに返します³⁵³⁹。これは、要求が利用可能なサーバーによって受信され、処理中であることを示します。
41. App -> DN: SIP 180 Ringing
- 背景: UEのアプリケーションは、着信呼をユーザーに通知します。
- 詳細: Appは、SIP 180 Ringing暫定応答（SIP, TS 24.229）をDNに送信します³⁵³⁹。これは、発呼者に、着信側の電話が鳴っていることを通知します。
42. App -> DN: SIP 200 OK (SDP Answer: Voice Codec, IP Address, Port)
- 背景: ユーザーが着信呼を受け入れます。
- 詳細: ユーザーが受け入れると、AppはSIP 200 OK最終応答（SIP, TS 24.229）をDNに送信します³⁵³⁹。このメッセージには、選択されたメディアパラメータ（例：音声コーデック、IPアドレス、ポート）を確認するSDP Answerが含まれており、メディアネゴシエーションを完了します。
43. DN -> App: SIP ACK
- 背景: IMSコアは、SIPセッション確立を完了するためにSIP 200 OKを認識します。
- 詳細: DNは、SIP ACKメッセージ（SIP, TS 24.229）をAppに送信します³⁵³⁹。これにより、SIPセッション確立のためのスリーウェイハンドシェイクが完了します。
44. App <-> DN: Voice Media (RTP/RTCP)
- 背景: SIPセッションが確立され、メディアパラメータがネゴシエートされた後、実際の音声通信が開始されます。
- 詳細: リアルタイム音声メディアは、UE上のAppとDN（IMSコア）間で、音声パケットにはRTP (Real-time Transport Protocol)、品質フィードバックにはRTCP (RTP Control Protocol)を使用して流れます。このユーザープレーンのトラフィックは、Uuインターフェース上の音声QoSフローのために確立されたDRBを通過し、その後gNB、N3インターフェースを介してUPF、そしてN6インターフェースを介してDNに到達します。
- 技術的含意: この最終ステップは、これまでのすべてのシグナリングの集大成を示しています。専用のDRBとQoSフローにより、RTP音声パケットは経路全体（UE-gNB-UPF-DN）で必要な優先度とリソース割り当てを受け、VoNRが約束する高品質な音声体験を提供します。

5. 結論

5GスタンドアローンVoNR着信呼の詳細なメッセージシーケンス分析は、シームレスで高品質な音声体験を提供するために、様々な5Gコアおよび無線アクセスネットワーク機能が高度に連携していることを明らかにしました。待機状態のUEの初期ページングから音声メディアパスの最終的な確立まで、各フェーズは3GPPで定義された正確なプロトコルとインターフェースに依存しています。

プロセスは、ネットワークがNGAP PAGINGを介してUEをインテリジェントに特定し、UEがUuインターフェース上でRRC接続（RRCSetupRequest、RRCSetup、RRCSetupComplete）を確立することから始まります。これには、共通および専用の無線ベアラ（SRB0、SRB1）が利用されます。これに続いて、NASセキュリティ確立フェーズが迅速に実行されます。このフェーズでは、5GMMメッセージ（AUTHENTICATION REQUEST/RESPONSE、SECURITY MODE COMMAND/COMPLETE）と、認証およびキー導出（KAMF、KNASint、KNASenc）のためのAMF、AUSF、UDM、UDR間の複雑な相互作用が含まれます。SRB2の確立は、優先され、安全なNASシグナリングをさらに保証します。

その後、5GCは初期コンテキスト設定（NGAP INITIAL CONTEXT SETUP REQUEST/RESPONSE）を調整し、gNBを既存のPDUセッションとその対応するDRBのために準備します。VoNR品質の核心は、音声QoSのためのPDUセッション変更を通じて実現されます。これには、IMS（DN/AFとして）がPCFにQoSを要求し、PCFがSMFにポリシーをプッシュするプロセスが含まれます。その後、SMFはUEに指示し（5GSM PDU SESSION MODIFICATION COMMAND/COMPLETE）、UPFに指示して（PFCP Session Modification Request/Response）、音声トラフィックのための専用のQoSフローとDRBを確立します。最後に、IMSセッション確立は専用のユーザープレーンパスを活用し、SIPシグナリング（INVITE、100 Trying、180 Ringing、200 OK、ACK）が呼を設定し、その後RTP/RTCP音声メディアが流れます。

この終端間フローは、5G SAのアーキテクチャの強み、すなわちサービスベースアーキテクチャ（SBA）のモジュール性、コントロールプレーンとユーザープレーンの分離（CUPS）の効率性、堅牢な多層セキュリティフレームワーク（NASおよびASセキュリティ）、および動的なQoSプロビジョニング能力を示しています。3GPP標準への準拠は、グローバルな相互運用性と高性能な音声サービスの信頼性の高い提供を保証し、リアルタイム通信における5Gの約束を実現します。

6. 関連テーブル

表1：VoNR呼フローの主要な3GPP技術仕様

この表は、VoNR呼フローに関与する各主要プロトコルと機能を管理する主要な3GPP仕様へのクイックリファレンスを提供します。これにより、読者は詳細情報のための権威ある情報源を迅速に特定できます。

分野/プロトコル	3GPP技術仕様 (TS)	説明
全体的な5GSアーキテクチャと手順	TS 23.501, TS 23.502	5Gシステムアーキテクチャと手順（モビリティ、セッション管理、QoSを含む）を定義します⁶³¹³²³³³⁴⁴⁰⁴¹⁴²⁴³⁴⁴⁴⁵。
無線リソース制御 (RRC)	TS 38.331	NR UuインターフェースのRRCプロトコルを規定し、接続管理、ページング、無線ベアラ設定をカバーします¹⁵¹⁶¹⁷¹⁸¹⁹²⁶⁴⁶⁴⁷⁴⁸⁴⁹。
5Gモビリティ管理 (5GMM)	TS 24.501	5Gモビリティ管理のための非アクセス層（NAS）プロトコルを定義し、登録、認証、セキュリティモード手順を含みます²²⁰²¹²²⁵⁰⁵¹⁵²。
5Gセッション管理 (5GSM)	TS 24.501	5Gセッション管理のためのNASプロトコルを定義し、PDUセッションの確立、変更、解放を含みます²²⁰²¹²²⁵⁰⁵¹⁵²。
5Gセキュリティアーキテクチャと手順	TS 33.501	認証とキー導出を含む5Gシステムのセキュリティアーキテクチャと手順を規定します³⁴²⁵²³⁵³⁵⁴⁵⁵⁵⁶。
NGアプリケーションプロトコル (NGAP)	TS 38.413	N2インターフェース上のNG-RAN（gNB）とAMF間のコントロールプレーンシグナリングプロトコルを規定します⁸⁷⁹¹⁰¹¹¹²¹³¹⁴⁵⁷⁵⁸。
パケット転送制御プロトコル (PFCP)	TS 29.244	SMFとUPF間のコントロールプレーンとユーザープレーンインターフェース（N4）のプロトコルを規定します²⁷²⁸²⁹³⁰⁵⁹⁶⁰⁶¹⁶²。
統合データ管理 (UDM) サービス	TS 29.503	UEコンテキスト管理と認証データ取得を含む、統合データ管理のためのサービスベースインターフェースを規定します⁴⁶³⁵²⁴³⁷⁶⁴⁶⁵⁶⁶。
IPマルチメディア呼制御プロトコル (SIP/SDP)	TS 24.229	IMSのためのSIPとSDPに基づくIPマルチメディア呼制御プロトコルを規定します³⁵³⁶³⁸³⁹。

表2：5G NRにおける無線ベアラとその利用

この表は、5G NRで使用される異なる種類の無線ベアラ、その目的、および運ばれる情報の種類を簡潔にまとめたものです。これにより、コントロールプレーンとユーザープレーンの両方のデータの基盤となる転送メカニズムが明確になります。

無線ベアラID	タイプ	目的	運ばれる情報	3GPP TS
SRB0	シグナリング無線ベアラ	初期RRCメッセージ用（例：RRCSetupRequest, RRCSetup）	暗号化されていないRRCメッセージ	38.331 ¹⁵¹⁹
SRB1	シグナリング無線ベアラ	RRC接続確立後のRRCメッセージおよび一部のNASメッセージ用	完全性保護および暗号化されたRRCメッセージ；完全性保護および暗号化されたNASメッセージ（SRB2設定前）	38.331 ¹⁵¹⁹
SRB2	シグナリング無線ベアラ	高優先度NASメッセージ用（例：5GSMメッセージ）	完全性保護および暗号化されたNASメッセージ（例：PDUセッション管理）	38.331 ¹⁵
DRB	データ無線ベアラ	ユーザープレーンデータ用（例：音声、ビデオ、インターネットトラフィック）	ユーザープレーンデータ（例：RTPパケット）	38.331

表3：5G NR Uuインターフェースにおける論理チャネル、トランスポートチャネル、および物理チャネル

この表は、Uuインターフェースにおけるチャネル階層を明確に示しており、論理チャネル（特定の種類の情報を運ぶ）からトランスポートチャネル（無線でデータを転送する方法）、そして物理チャネル（実際の無線リソース）へのマッピングを提供します。これは、メッセージが無線でどのように送信されるかを理解するための基本です。

チャネルタイプ	チャネル名	方向	目的	関連する物理チャネル
論理	PCCH	ダウンリンク	RRC_IDLE/INACTIVE状態のUEへのページングメッセージ	PDSCH (via PCH)
	CCCH	アップリンク/ダウンリンク	RRC接続確立のための共通制御メッセージ	PUSCH (UL-SCH), PDSCH (DL-SCH)
	DCCH	アップリンク/ダウンリンク	RRCおよびNASのための専用制御メッセージ	PUSCH (UL-SCH), PDSCH (DL-SCH)
	DTCH	アップリンク/ダウンリンク	専用ユーザー通信	PUSCH (UL-SCH), PDSCH (DL-SCH)
トランスポート	PCH	ダウンリンク	ページングのためのPCCHデータを運ぶ	PDSCH
	DL-SCH	ダウンリンク	DL-CCCH, DL-DCCH, DTCHデータを運ぶ	PDSCH
	UL-SCH	アップリンク	UL-CCCH, UL-DCCH, DTCHデータを運ぶ	PUSCH
物理	PDSCH	ダウンリンク	ダウンリンクトランスポートチャネル（PCH, DL-SCH）を運ぶ	N/A
	PUSCH	アップリンク	アップリンクトランスポートチャネル（UL-SCH）を運ぶ	N/A
	PDCCH	ダウンリンク	PDSCH/PUSCHのスケジューリング情報を運ぶ	N/A
	PUCCH	アップリンク	アップリンク制御情報（例：HARQ-ACK, CSI）を運ぶ	N/A

表4：5Gコアネットワークインターフェースとプロトコル

この表は、異なる5Gコアネットワーク機能間、およびRANとコア間の論理的な接続と通信プロトコルを理解する上で貴重です。5Gシステムにおける統合ポイントの概要を素早く把握できます。

インターフェース名	接続されるネットワーク機能	プロトコル	説明
N1	UE - AMF	5GMM, 5GSM	UEとAMF/SMF（AMF経由）間の非アクセス層（NAS）シグナリング。
N2	gNB - AMF	NGAP	NG-RANとAMF間のシグナリングのためのコントロールプレーンインターフェース⁸⁷。
N3	gNB - UPF	GTP-U	NG-RANとUPF間のデータ転送のためのユーザープレーンインターフェース。
N4	SMF - UPF	PFCP	ユーザープレーンセッション管理のためのSMFとUPF間のコントロールプレーンインターフェース²⁷²⁸。
N6	UPF - DN	IP	UPFとデータネットワーク間のデータ転送のためのユーザープレーンインターフェース。
N7	SMF - PCF	HTTP/2	ポリシー制御決定のためのサービスベースインターフェース⁶。
N8	AMF - UDM	HTTP/2	アクセスおよびモビリティ管理サブスクリプションデータのためのサービスベースインターフェース。
N10	SMF - UDM	HTTP/2	セッション管理サブスクリプションデータのためのサービスベースインターフェース。
N11	AMF - SMF	HTTP/2	セッション管理コンテキスト情報のためのサービスベースインターフェース。
N12	AMF - AUSF	HTTP/2	認証要求のためのサービスベースインターフェース。
N13	AUSF - UDM	HTTP/2	認証クレデンシャル取得のためのサービスベースインターフェース。
Nudm	UDM - UDR	HTTP/2	統合データリポジトリアクセス（UDMとUDR間）のためのサービスベースインターフェース。

7. 引用文献

Communication services (VoLTE/VoNR) - 3GPP, https://www.3gpp.org/technologies/volte-vonr ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸ ↩⁹ ↩¹⁰ ↩¹¹ ↩¹² ↩¹³
3GPP TS 24.501, 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 ↩ ↩² ↩³
TS 33.501 (1Q25/342 p.) – 5GS Security Architecture and Procedures, https://www.tech-invite.com/3m33/tinv-3gpp-33-501.html ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸ ↩⁹ ↩¹⁰ ↩¹¹ ↩¹² ↩¹³ ↩¹⁴
3GPP TS ab.cde, https://www.3gpp.org/ftp/tsg_sa/WG3_Security/TSGS3_113_Chicago/SA_102/33514-i20.doc ↩ ↩² ↩³
TS 129 503 - V17.10.0 - 5G; 5G System; Unified Data ... - ETSI, https://www.etsi.org/deliver/etsi_ts/129500_129599/129503/17.10.00_60/ts_129503v171000p.pdf ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷
3GPP Change Request, ftp://www.3gpp.org/tsg_sa/WG6_MissionCritical/TSGS6_041-e/inbox/Drafts/07_5_MCOver5GS/S6-210059_Rev4_pCR_TS_23.289_resource_control_using%205GS-for%20MC_service_system.doc ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶
inside TS 38.413: Content Part, 10 out of 52 - Tech-invite, https://www.tech-invite.com/3m38/toc/tinv-3gpp-38-413_j.html ↩ ↩² ↩³
3GPP TS 38.413 | PDF | 3 Gpp | Computer Standards - Scribd, https://www.scribd.com/document/696368502/38413-h60 ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶
TS 138 413 - V18.2.0 - 5G; NG-RAN; NG Application Protocol ... - ETSI, https://www.etsi.org/deliver/etsi_ts/138400_138499/138413/18.02.00_60/ts_138413v180200p.pdf ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶
ETSI TS 138 413 V17.2.0 (2022-10) - iTeh Standards, https://cdn.standards.iteh.ai/samples/67107/efdf8e3a6c734eabaaf3728a303a0957/ETSI-TS-138-413-V17-2-0-2022-10-.pdf ↩ ↩² ↩³ ↩⁴
NGAP/NAS Server - Black Duck, https://www.blackduck.com/fuzz-testing/defensics/protocols/ngap-server.html ↩ ↩² ↩³ ↩⁴ ↩⁵
TS 138 413 - V17.4.0 - 5G; NG-RAN; NG Application Protocol (NGAP) (3GPP TS 38.413 version 17.4.0 Release 17) - ETSI, https://www.etsi.org/deliver/etsi_ts/138400_138499/138413/17.04.00_60/ts_138413v170400p.pdf ↩ ↩² ↩³ ↩⁴
TS 38.413 NG-RAN — NG interface – NG Application Protocol (NGAP) - Tech-invite, https://www.tech-invite.com/3m38/tinv-3gpp-38-413.html ↩ ↩² ↩³ ↩⁴ ↩⁵
Specification # 38.413 - 3GPP, https://www.3gpp.org/dynareport/38413.htm ↩ ↩² ↩³ ↩⁴
RRC-Radio Resource Control in LTE - Techlteworld, https://techlteworld.com/rrc-radio-resource-control-in-lte/ ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸ ↩⁹ ↩¹⁰ ↩¹¹ ↩¹²
Radio Resource Control - Wikipedia, https://en.wikipedia.org/wiki/Radio_Resource_Control ↩ ↩² ↩³ ↩⁴ ↩⁵
TS 38.331 (1Q25/1668 p.) – 5G New Radio RRC Protocol - Tech-invite, https://www.tech-invite.com/3m38/tinv-3gpp-38-331.html ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸ ↩⁹ ↩¹⁰ ↩¹¹ ↩¹²
update of R2-2103034 TS 38.331 CR on RRC processing delay (r16).docx - 3GPP, https://www.3gpp.org/ftp/tsg_ran/WG2_RL2/TSGR2_113bis-e/Inbox/Drafts/%5BOffline-025%5D%5BNR17%5D%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 ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸
ETSI TS 138 331 V18.4.0 (2025-01) - iTeh Standards, https://cdn.standards.iteh.ai/samples/74068/1b775f3864f146049f7aa92595b4abfb/ETSI-TS-138-331-V18-4-0-2025-01-.pdf ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸ ↩⁹
inside TS 24.501: NAS Security - Tech-invite, https://www.tech-invite.com/3m24/toc/tinv-3gpp-24-501_d.html ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸
TS 124 501 - V16.14.0 - 5G; Non-Access-Stratum (NAS ... - ETSI, https://www.etsi.org/deliver/etsi_ts/124500_124599/124501/16.14.00_60/ts_124501v161400p.pdf ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸ ↩⁹ ↩¹⁰ ↩¹¹ ↩¹²
TS 24.501 Non-Access-Stratum (NAS) Protocol for 5GS - Tech-invite, https://www.tech-invite.com/3m24/tinv-3gpp-24-501.html ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸
Security features for Non-Public Networks - 3GPP, https://www.3gpp.org/technologies/sec-npn ↩ ↩² ↩³
inside TS 29.503: Scope, References, Definitions, Abbreviations, https://www.tech-invite.com/3m29/toc/tinv-3gpp-29-503_a.html ↩ ↩² ↩³
TS 133 501 - V18.6.0 - 5G; Security architecture and ... - ETSI, https://www.etsi.org/deliver/etsi_ts/133500_133599/133501/18.06.00_60/ts_133501v180600p.pdf ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸
3GPP TS 38.331 | PDF | 3 Gpp - Scribd, https://www.scribd.com/document/553227116/38331-g70 ↩ ↩²
PFCP - Wikipedia, https://en.wikipedia.org/wiki/PFCP ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶
PFCP protocol - Nokia Documentation Center, https://documentation.nokia.com/mag-c/24-7/books/pfcp/pfcp-protocol.html ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶
ETSI TS 129 244 V16.9.1 (2021-09), https://www.etsi.org/deliver/etsi_TS/129200_129299/129244/16.09.01_60/ts_129244v160901p.pdf ↩ ↩² ↩³ ↩⁴ ↩⁵
TS 29.244 (1Q25/477 p.) – Interface between 3GPP CP and UP Nodes, https://www.tech-invite.com/3m29/tinv-3gpp-29-244.html ↩ ↩² ↩³ ↩⁴ ↩⁵
inside TS 23.502: 5GS PDU Session Modification procedures - Tech-invite, https://www.tech-invite.com/3m23/toc/tinv-3gpp-23-502_p.html ↩ ↩² ↩³ ↩⁴ ↩⁵
S2-2001938r01.docx - 3GPP, https://www.3gpp.org/ftp/tsg_sa/wg2_arch/TSGS2_137e_Electronic/Inbox/Drafts/S2-2001938r01.docx ↩ ↩² ↩³
ETSI TS 123 502 V17.7.0 (2023-01) - iTeh Standards, https://cdn.standards.iteh.ai/samples/67681/0a0f2faededb4d0ab3fae55ae6ad6a2c/ETSI-TS-123-502-V17-7-0-2023-01-.pdf ↩ ↩² ↩³
TS 23.502 (1Q25/970 p.) – Procedures for the 5G System - Tech-invite, https://www.tech-invite.com/3m23/tinv-3gpp-23-502.html ↩ ↩² ↩³
ETSI TS 124 229 V18.7.0 (2025-01), https://www.etsi.org/deliver/etsi_ts/124200_124299/124229/18.07.00_60/ts_124229v180700p.pdf ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶
Specification #: 24.229 - 3GPP, https://www.3gpp.org/dynareport/24229.htm ↩ ↩²
C4-252094_r1.docx - 3GPP, https://www.3gpp.org/FTP/Meetings_3GPP_SYNC/CT4/Inbox/Drafts/C4-252094_r1.docx ↩ ↩²
3GPP TS 24.229, https://www.3gpp.org/ftp/tsg_ct/WG1_mm-cc-sm_ex-CN1/TSGC1_130e/Inbox/drafts/C1-213638AccessChange.doc ↩ ↩²
TS 24.229 (1Q25/1108 p.) – IMS Call Control based on SIP and SDP, https://www.tech-invite.com/3m24/tinv-3gpp-24-229.html ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶
3GPP specification series: 23series, https://www.3gpp.org/DynaReport/23-series.htm ↩
3GPP TS 23.502, https://www.3gpp.org/ftp/tsg_sa/WG2_Arch/TSGS2_143e_Electronic/INBOX/DRAFTS/5G_ProSe/S2-210xxxx_TS%2023.501-Clause%207.2.19-AF%20Services_r1.doc ↩
3GPP TS 23.502 | PDF | Computing | Communication - Scribd, https://www.scribd.com/document/547371540/23502-g30 ↩
ETSI TS 123 502 V15.17.0 (2023-09) - iTeh Standards, https://cdn.standards.iteh.ai/samples/69223/6b0e81d763054075a9bee2d676ef6f44/ETSI-TS-123-502-V15-17-0-2023-09-.pdf ↩
3GPP TS 23.502, https://www.3gpp.org/ftp/Email_Discussions/SA2/5G_ProSe/S2-210xxxx_TS%2023.502-Clause%205.2.19.X-AF%20Service%20operation_r1.doc ↩
ETSI TS 123 502 - Accuris Standards Store, https://store.accuristech.com/standards/etsi-ts-123-502?product_id=2208510 ↩
Specification # 38.331 - 3GPP, https://www.3gpp.org/dynareport/38331.htm ↩
draft R4-2002262 CR for 38133.docx - 3GPP, ftp://www.3gpp.org/tsg_ran/WG4_Radio/TSGR4_94_e/Inbox/Drafts/%2369_NR_SON_MDT_RRM/draft%20CR/draft%20R4-2002262%20CR%20for%2038133.docx ↩
3GPP TS 38.331, https://www.3gpp.org/ftp/Email_Discussions/RAN2/%5BRAN2%23124%5D/%5BPOST124%5D%5B029%5D%5BATG%5D%2038.321%20%20CR%20(CMCC)/DRAFT_38321_CR1710_(Rel-18)_MAC%20CR%20for%20NR%20ATG_v04_Rapp.doc ↩
ARIB STD-T120-38.331 V15.10.0 NR; Radio Resource Control (RRC) protocol specification (Release 15), http://www.arib.or.jp/english/html/overview/doc/T120_T23_v2_00/2_T120/ARIB-STD-T120/Rel15/38/A38331-fa0.pdf ↩
3GPP TS 24.501 | PDF | Computer Engineering | Networking Standards - Scribd, https://www.scribd.com/document/554597918/24-501-R-17 ↩ ↩²
3GPP TS 24.501, https://www.3gpp.org/ftp/tsg_ct/WG1_mm-cc-sm_ex-CN1/TSGC1_128e/Inbox/drafts/C1-21xxxx-rev1-of-210610-Req-NSSAI-24501-h10-v2.doc ↩ ↩²
Specification # 24.501 - 3GPP, https://www.3gpp.org/dynareport/24501.htm ↩ ↩²
TS 133 501 - V17.5.0 - 5G; Security architecture and procedures for 5G System (3GPP TS 33.501 version 17.5.0 Release 17) - ETSI, https://www.etsi.org/deliver/etsi_ts/133500_133599/133501/17.05.00_60/ts_133501v170500p.pdf ↩
Specification # 33.501 - 3GPP, https://www.3gpp.org/dynareport/33501.htm ↩
Directory Listing /ftp/specs/archive/33_series/33.501/ - 3GPP, https://www.3gpp.org/ftp/specs/archive/33_series/33.501/ ↩
TS 133 501 - V17.7.0 - 5G; Security architecture and procedures for 5G System (3GPP TS 33.501 version 17.7.0 Release 17) - ETSI, https://www.etsi.org/deliver/etsi_ts/133500_133599/133501/17.07.00_60/ts_133501v170700p.pdf ↩
draft_R3-253808_was3224_femtoPaper300_rev1_HW_HW2_ZTE_nok.docx - 3GPP, https://www.3gpp.org/ftp/tsg_ran/WG3_Iu/TSGR3_128/Inbox/Drafts/CB%20%23%20Femto/draft_R3-253808_was3224_femtoPaper300_rev1_HW_HW2_ZTE_nok.docx ↩
38455-h40_v3.docx - 3GPP, https://www.3gpp.org/ftp/tsg_ran/WG3_Iu/Draft_Specs/TSG-RAN99/Track%20change/38455-h40_v3.docx ↩
ETSI TS 129 244 - Accuris Standards Store, https://store.accuristech.com/standards/etsi-ts-129-244?product_id=2208667 ↩
S4-250898r03_Lenovo.docx - 3GPP, https://www.3gpp.org/FTP/Meetings_3GPP_SYNC/SA4/Inbox/Drafts/RTC/S4-250898r03_Lenovo.docx ↩
S2-2402925r01_Add KPIs and references_ Removal of input data general Note in e2e data volume transfer time .docx - 3GPP, https://www.3gpp.org/ftp/tsg_sa/wg2_arch/TSGS2_161_Athens_2024-02/INBOX/DRAFTS/S2-2402925r01_Add%20KPIs%20and%20references_%20Removal%20of%20input%20data%20general%20Note%20in%20e2e%20data%20volume%20transfer%20time%20.docx ↩
Specification # 29.244 - 3GPP, https://www.3gpp.org/dynareport/29244.htm ↩
3GPP TS ab.cde - TEC, https://tec.gov.in/pdf/3gpp/26575%202022.pdf ↩
3GPP TS 29.503 | PDF | 3 Gpp | Communication - Scribd, https://www.scribd.com/document/519289142/29503-v16-5g-udm ↩
C3-222160r1.docx - 3GPP, https://www.3gpp.org/ftp/tsg_ct/WG3_interworking_ex-CN3/TSGC3_121e/Inbox/Draft/NON-PCC/IIoT/C3-222160r1.docx ↩
Swagger Editor - jdegre.github.io, https://jdegre.github.io/loader.html?yaml=TS29503_Nudm_SDM.yaml ↩