13. 生成AIで作成する5Gシステムのサンプルメッセージシーケンス概要 : 音声着信 編

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

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

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

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

本報告書の目的は、着信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の登録、到達性、およびセキュリティを扱います[^1]。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）と連携します[^1]。
- **AUSF (Authentication Server Function)**: 5GCのコントロールプレーン機能で、UEの認証とセキュリティキーの生成を担当します。AMF（N12）およびUDM（N13）と連携します[^9]。
- **UDM (Unified Data Management)**: 5GCのコントロールプレーン機能で、認証クレデンシャルを含む加入者サブスクリプションデータを保存し、UEコンテキストを管理します[^1]。AMF（N8）、SMF（N10）、およびAUSF（N13）と連携します。
- **UDR (Unified Data Repository)**: ネットワーク機能（例：UDM、PCF）向けの構造化データを保存する5GCのデータリポジトリです[^10]。
- **PCF (Policy Control Function)**: 5GCのコントロールプレーン機能で、PDUセッションやQoSフローのQoSポリシーを含むネットワーク動作を制御するポリシー規則を提供します[^1]。SMF（N7）およびUDM（N10）と連携します。
- **UPF (User Plane Function)**: 5GCのユーザープレーン機能で、パケットルーティングと転送、QoS適用、およびPDUセッションのアンカリングを担当します[^1]。gNB（N3）およびSMF（N4）と連携します。
- **DN (Data Network)**: UEにサービスを提供する外部ネットワーク（例：インターネット、IMSネットワーク）を表します。VoNRの場合、主にIMSコアネットワークを指します[^1]。

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

```plantuml
@startuml
autonumber

box "UE" #lightblue
participant "App" as App
participant "5G Modem" as UE
end box
box "NG-RAN" #pink
participant "gNB" as gNB
end box
box "5G Core Network" #lightgreen
participant "AMF" as AMF
participant "SMF" as SMF
participant "AUSF" as AUSF
participant "UDM" as UDM
participant "UDR" as UDR
participant "PCF" as PCF
participant "UPF" as UPF
end box
box "External Network"
participant "DN (IMS Core)" as DN
end box

group Phase 1: Paging and RRC Connection Establishment
    DN -> AMF: Nudm_UECM_Registration (Downlink Data Notification)\n(HTTP/2, TS 29.503)\n[N8 Interface]
    note right: IMS/DN triggers UDM, which notifies AMF\nof pending data for an IDLE UE.
    AMF -> gNB: PAGING (NGAP, TS 38.413)\n(UE ID, TAI List, Paging Priority)\n[N2 Interface]
    note right: AMF pages UE via gNBs in the TAI list.
    gNB -> UE: Paging (RRC, TS 38.331)\n(UE ID, Paging Cause: terminating-Access)\n PDSCH , PCH , PCCH
    note left: gNB broadcasts Paging message.
    UE -> gNB: RRCSetupRequest (RRC, TS 38.331)\n(Establishment Cause: mt-Access)\n PUSCH , UL-SCH , UL-CCCH\nBearer:SRB0
    note left: After RACH on PRACH/RA-RNTI,\nUE initiates RRC connection.
    gNB -> UE: RRCSetup (RRC, TS 38.331)\n(SRB1 config, initial C-RNTI)\n PDSCH , DL-SCH , DL-CCCH\nBearer:SRB0
    note left: gNB provides RRC configuration for SRB1.
    UE -> gNB: RRCSetupComplete (RRC, TS 38.331)\n(encapsulates NAS: SERVICE REQUEST)\n PUSCH , UL-SCH , UL-DCCH\nBearer:SRB1
    note left: RRC connection established.\nNAS message is sent piggybacked.
end group

group Phase 2: NAS Security Establishment (Authentication & Security Mode)
    gNB -> AMF: INITIAL UE MESSAGE (NGAP, TS 38.413)\n(NAS PDU: SERVICE REQUEST (5GMM, TS 24.501))\n[N2 Interface]
    note right: gNB forwards the NAS Service Request\nfrom UE to AMF.
    AMF -> UE: AUTHENTICATION REQUEST (5GMM, TS 24.501)\n(RAND, AUTN)\n PDSCH , DL-SCH , DL-DCCH\nBearer:SRB1
    note left: AMF initiates 5G-AKA authentication.
    AMF -> AUSF: Nausf_UEAuthentication_Authenticate Request (HTTP/2, TS 29.509)\n(SUPI, Auth Type: 5G_AKA)\n[N12 Interface]
    note right: AMF requests authentication vectors from AUSF.
    AUSF -> UDM: Nudm_UEAuthentication_Get Request (HTTP/2, TS 29.503)\n(SUPI, Auth Type)\n[N13 Interface]
    note right: AUSF retrieves authentication data from UDM.
    UDM -> UDR: Nudr_DR_Query (HTTP/2, TS 29.504)\n(SUPI)\n[Nudr Interface]
    UDM <-- UDR: Nudr_DR_Query Response\n(Auth Vectors, Subscriber Data)
    AUSF <-- UDM: Nudm_UEAuthentication_Get Response\n(5G HE AV: RAND, XRES*, KAUSF)
    AMF <-- AUSF: Nausf_UEAuthentication_Authenticate Response\n(5G AV: RAND, AUTN, HXRES*, KSEAF)
    UE -> AMF: AUTHENTICATION RESPONSE (5GMM, TS 24.501)\n(RES*)\n PUSCH , UL-SCH , UL-DCCH\nBearer:SRB1
    note left: UE verifies AUTN and responds with RES*.
    AMF -> AMF: Derive KAMF from KSEAF\n(TS 33.501)
    AMF -> UE: SECURITY MODE COMMAND (5GMM, TS 24.501)\n(NAS security algorithms, ngKSI)\n PDSCH , DL-SCH , DL-DCCH\nBearer:SRB1 (Integrity Protected)
    note left: AMF initiates NAS security setup.
    UE -> UE: Derive KNASint, KNASenc, KAMF\n(TS 33.501)
    UE -> AMF: SECURITY MODE COMPLETE (5GMM, TS 24.501)\n(IMEISV)\n PUSCH , UL-SCH , UL-DCCH\nBearer:SRB1 (Integrity Protected & Ciphered)
    note left: NAS security context is now active.
end group

group Phase 3: Initial Context Setup (for existing PDU Sessions)
    AMF -> SMF: Nsmf_PDUSession_UpdateSMContext Request (HTTP/2, TS 29.502)\n(SUPI, PDU Session ID, N1 SM Info)\n[N11 Interface]
    note right: AMF notifies SMF that UE is reachable.
    SMF -> UPF: PFCP Session Modification Request (PFCP, TS 29.244)\n(Update Forwarding Action Rules)\n[N4 Interface]
    note right: SMF updates UPF \nfor user plane path.
    UPF --> SMF: PFCP Session Modification Response
    SMF --> AMF: Nsmf_PDUSession_UpdateSMContext Response
    AMF -> gNB: INITIAL CONTEXT SETUP REQUEST (NGAP, TS 38.413)\n(PDU Session Resource Setup List, MobilityRestrictionList, UE-AMBR)\n[N2 Interface]
    note right: AMF requests gNB to \nsetup UE context and DRBs.
    gNB -> UE: RRCReconfiguration (RRC, TS 38.331)\n(as-Config, drb-ToaddModList, srb-ToAddModList)\n PDSCH , DL-SCH , DL-DCCH\nBearer:SRB1\nSetup:SRB2, DRB(s)
    note left: gNB configures SRB2 and DRB(s)\nfor existing PDU sessions.
    UE -> gNB: RRCReconfigurationComplete (RRC, TS 38.331)\n PUSCH , UL-SCH , UL-DCCH\nBearer:SRB1
    note left: UE confirms DRB setup.
    gNB --> AMF: INITIAL CONTEXT SETUP RESPONSE (NGAP, TS 38.413)\n(PDU Session Resource Setup Response List)\n[N2 Interface]
    note right: gNB confirms \nUE context setup.
end group

group Phase 4: PDU Session Modification for Voice QoS
    DN -> PCF: AF Request (HTTP/2, TS 29.514)\n(QoS Requirements: 5QI=1 for Voice)\n[N5/Rx Interface]
    note right: IMS (AF) requests \ndedicated QoS for voice.
    PCF -> SMF: Npcf_PolicyControl_UpdateNotify (HTTP/2, TS 29.512)\n(PCC Rules: QoS Rules, QFI=1)\n[N7 Interface]
    note right: PCF pushes policy to SMF.
    SMF -> UE: PDU SESSION MODIFICATION COMMAND (5GSM, TS 24.501)\n(Authorized QoS Rules, QFI=1)\n PDSCH , DL-SCH , DL-DCCH\nBearer:SRB2
    note left: SMF commands UE to \nadd QoS Flow for voice.
    UE -> SMF: PDU SESSION MODIFICATION COMPLETE (5GSM, TS 24.501)\n PUSCH , UL-SCH , UL-DCCH\nBearer:SRB2
    note left: UE confirms QoS Flow addition.
    SMF -> UPF: PFCP Session Modification Request (PFCP, TS 29.244)\n(Create/Update PDR/FAR/QER, QFI=1)\n[N4 Interface]
    note right: SMF updates UPF with \nnew QoS flow for voice.
    UPF --> SMF: PFCP Session Modification Response
    SMF -> gNB: PDU SESSION RESOURCE MODIFY REQUEST (NGAP, TS 38.413)\n(PDU Session ID, QoS Flow Add/Modify List, QFI=1)\n[via AMF on N11 and N2 Interface]
    note right: SMF requests gNB to establish DRB for voice QoS.
    gNB -> UE: RRCReconfiguration (RRC, TS 38.331)\n(drb-ToAddModList: DRB for Voice)\n PDSCH , DL-SCH , DL-DCCH\nBearer:SRB1\nSetup:DRB for Voice (QFI=1)
    note left: gNB configures \ndedicated DRB for voice.
    UE -> gNB: RRCReconfigurationComplete (RRC, TS 38.331)\n PUSCH , UL-SCH , UL-DCCH\nBearer:SRB1
    note left: UE confirms DRB setup for voice.
    gNB --> SMF: PDU SESSION RESOURCE MODIFY RESPONSE (NGAP, TS 38.413)\n[via AMF on N2 and N11 Interface]
    note right: gNB confirms DRB establishment for voice.
end group

group Phase 5: IMS Session Establishment (SIP Signaling) and User Plane Activation
    DN -> App: SIP INVITE (SIP, TS 24.229)\n(SDP Offer: Voice Codec, IP, Port)\n PDSCH , DL-SCH , DTCH\nBearer:DRB for IMS Signaling(QFI=5)
    note left: Incoming call signaling.
    App -> DN: SIP 100 Trying (SIP, TS 24.229)
    App -> DN: SIP 180 Ringing (SIP, TS 24.229)
    App -> DN: SIP 200 OK (SIP, TS 24.229)\n(SDP Answer: Selected Codec, IP, Port)
    note left: User accepts call.
    DN -> App: SIP ACK (SIP, TS 24.229)
    note right: SIP session established.
    App <-> DN: Voice Media (RTP/RTCP)\n PUSCH/PDSCH , UL/DL-SCH , DTCH\nBearer:DRB for Voice (QFI=1)
    note left: Voice call in progress \nover dedicated QoS flow.
end group

@enduml


```

## 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をページングするようトリガーします[^13]。5GSではPDUセッションは常にUEによって設定されると記載されていますが[^6]、これは着信呼の場合、UEが音声呼のためのPDUセッション変更を開始する前に、ネットワークがUEへの接続を確立する必要があることを示唆しています。AMFがUEをページングする最も一般的なトリガーは、IMS/DNからUDMに通知される、UDMからのモバイル終端サービス要求です。`Nudm_UECM_Registration`サービスは、NFがUEコンテキストをUDMに登録するために使用され、UDMがAMFに保留中のモバイル終端サービスを通知するためにも使用できます[^13]。
  - **詳細**: このメッセージは、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)**
  - **背景**: 着信呼を認識したAMFは、UEを特定するためにgNBに指示を出す必要があります。UEがRRC_IDLEまたはRRC_INACTIVE状態にあるため、ネットワークはUEへの専用シグナリング接続を持っていません。ページングはUEに警告を通知するメカニズムです。
  - **詳細**: AMFは、UEが登録されているトラッキングエリアをカバーするgNBに`PAGING`メッセージを送信します[^15]。このメッセージは、`N2インターフェース`上で`NGAP (NG Application Protocol)`を使用して転送されます（TS 38.413）[^5][^16][^17][^18][^19][^20][^21]。このメッセージの主要な情報要素（IE）には、`UE ID`（例：5G-GUTIまたはI-RNTI）、`TAI List for Paging IE`（ページングを行うべきトラッキングエリアを示す）、およびオプションで`Paging Priority IE`（ページング試行の優先順位付けのため）、`Paging DRX IE`、`UE Radio Capability for Paging IE`（最適化のため）が含まれます[^16]。
  - **技術的含意**: NGAP PAGINGメッセージに`TAI List`と`Paging DRX`が含まれていることは、5Gシステムが電力効率のために最適化されていることを示しています。関連するTAのみでページングを行い、UEのDRXサイクルと同期させることで、ネットワークは不要なシグナリングとUEのバッテリー消費を最小限に抑え、5Gのエネルギー効率目標の重要な側面を実現しています。

- **3. gNB -> UE: Paging (UE ID, Paging Cause: Mobile Terminating Call)**
  - **背景**: NGAP `PAGING`メッセージを受信すると、gNBは無線インターフェースを介してページングメッセージをブロードキャストし、UEに到達させる責任を負います。
  - **詳細**: gNBは、`Uu無線インターフェース`上で`RRC Paging`メッセージ（RRC, TS 38.331）をブロードキャストします[^22][^23][^24]。このメッセージは、論理チャネルである`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接続確立手順を開始します[^22][^23][^24][^25][^26]。このメッセージは、初期のアップリンクRRCメッセージに使用される論理チャネルである`UL-CCCH (Uplink Common Control Channel)`で送信されます。`UL-CCCH`は、専用無線ベアラが設定される前に使用されるデフォルトのSRB（Signaling Radio Bearer）である`SRB0 (Signaling Radio Bearer 0)`で運ばれます[^22][^24][^26]。`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に送信します[^22][^23][^24][^25][^26]。このメッセージは、`SRB0`で運ばれる`DL-CCCH (Downlink Common Control Channel)`で送信されます[^22][^24][^26]。`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に送信します[^22][^23][^24][^25][^26]。このメッセージは、新しく構成された`UL-DCCH (Uplink Dedicated Control Channel)`で送信され、`SRB1`で運ばれます[^22][^24][^26]。`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）を使用して行われます[^5][^20]。`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に送信します[^4][^9][^27][^28]。このメッセージは、`UL-DCCH (SRB1)`上で`Uuインターフェース`を介して送信されます。これには、`RAND`（ランダムチャレンジ）や`AUTN`（認証トークン）などの重要な認証パラメータが含まれ、EAPベースの認証（例：EAP-AKA'）が使用される場合は`EAP message`も含まれる可能性があります[^9][^27][^29]。
  - **技術的含意**: 認証は、機密性の高いNAS通信を進める前に必須かつ基本的なステップです。これにより、正当なUEのみがネットワークサービスにアクセスできるようになり、不正なアクセスを防ぎ、加入者データを保護します。

- **9. AMF -> AUSF: Nausf_UEAuthentication_Authenticate Request (SUPI, Auth Type)**
  - **背景**: AMFは認証を直接実行せず、この機能を認証サーバー機能（AUSF）に委譲します。
  - **詳細**: AMFは、`Nausf_UEAuthentication_Authenticate Request`をAUSFに送信します（サービスベースインターフェース、N12, TS 29.503）[^13][^30]。この要求には、UEの`SUPI (Subscription Permanent Identifier)`と`Authentication Type`（例：5G-AKA）が含まれます[^9][^12][^29]。
  - **技術的含意**: この相互作用は、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から認証情報を要求します[^13][^30]。この要求には、`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に送信します[^9][^12][^13]。

- **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)`が含まれます[^9][^12][^13]。`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`を含めます[^4][^9][^27][^28]。このメッセージは`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）[^9][^12]。`KAMF`はNASおよびASセキュリティのルートキーです。
  - **技術的含意**: 階層的なキー導出プロセス（K -> CK/IK -> KAUSF -> KSEAF -> KAMF -> KgNB -> KRRC/KUP）は、異なるセキュリティ目的とネットワークドメインに異なるキーが使用されることを保証します。この設計原則は、`NH`（Next Hop）と`NCC`（Next Hop Chaining Count）の使用と相まって、前方セキュリティを提供します。これは、下位レベルのキーが侵害されても、上位レベルまたは将来のキーが侵害されないことを意味します[^9][^12]。

- **17. AMF -> UE: SECURITY MODE COMMAND (NAS security algorithms, ngKSI)**
  - **背景**: `KAMF`が確立された後、AMFはNASセキュリティモード制御手順を開始し、NASメッセージの完全性保護と暗号化をアクティブにします。
  - **詳細**: AMFは、`SECURITY MODE COMMAND`メッセージ（5GMM, TS 24.501）をUEに送信します[^4][^9][^27][^28]。このメッセージは、新しく導出された`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)`が指定されます[^4][^18]。また、`IMEISV request`が含まれる場合もあります[^27]。このメッセージは`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）[^9][^12]。

- **19. UE -> AMF: SECURITY MODE COMPLETE (IMEISV, NAS message container)**
  - **背景**: UEはNASセキュリティのアクティブ化を確認し、保留中のNASメッセージを安全に送信できるようになります。
  - **詳細**: UEは、`SECURITY MODE COMPLETE`メッセージ（5GMM, TS 24.501）をAMFに送信します[^4][^9][^27][^28]。このメッセージは、新しく導出された`KNASint`と`KNASenc`を使用して完全性保護され、暗号化されます。要求された場合は`IMEISV (International Mobile Equipment Identity Software Version)`と`NAS message container`が含まれる場合があります[^27]。もし初期の`SERVICE REQUEST`メッセージ（または`REGISTRATION REQUEST`のような他の初期NASメッセージ）に、セキュリティコンテキストの欠如のためにクリアテキストで送信された機密IEが含まれていた場合、元のメッセージ全体がこの`NAS message container`内に再送信され、今度は完全性保護され、暗号化されます[^4][^27]。このメッセージは`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セッション管理）に関連するメッセージのために確立されます[^22]。これは、AMFがgNBにUE内の`SRB2`を構成するようトリガーする内部AMFアクションですが、`SRB2`設定のための明示的なRRCメッセージは、後の`RRCReconfiguration`メッセージの一部となる場合があります。
  - **技術的含意**: `SRB1`と`SRB2`の区別（`SRB2`が通常高優先度を持つ）は、コントロールプレーンシグナリングにもQoS要件があることを強調しています。音声呼設定のような高優先度NASメッセージは、VoNRが約束する高速な呼設定時間[^1]に合致するために、優先的な処理が必要です。

---
### 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）を介して行われます[^31]。このメッセージには、`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に送信します[^8][^14][^32][^33]。このメッセージは、`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に応答し、要求された変更の成功または失敗を示します[^8][^14][^32][^33]。

- **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に送信します[^5][^16][^17][^18][^19][^20][^21]。このメッセージには、gNBがUEコンテキストを構成するために不可欠な情報が含まれており、これには`PDU Session Resource Setup List IE`（既存のPDUセッションとそのQoSフローの詳細）、`UE Aggregate Maximum Bit Rate IE`、および`Security Indication IE`（ユーザープレーンの完全性保護と暗号化要件を指定）が含まれます[^16]。
  - **技術的含意**: このメッセージは、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に送信します[^24][^25]。このメッセージには、既存のPDUセッションのための`DRB setup`の指示が含まれます。同時に、gNBとUEは、`KAMF`とアップリンクNAS COUNTから`K_gNB_`キーを導出し、その後、ASセキュリティのために`KRRCint`、`KRRCenc`、`KUPint`、`KUPenc`を導出します（TS 33.501, Annex A）[^9][^12]。これらのキーは、DRB上のRRCメッセージとユーザープレーンデータを完全性保護し、暗号化するために使用されます。
  - **技術的含意**: このステップは、アクセス層（AS）セキュリティのアクティブ化を示しており、RRCメッセージとユーザープレーンデータの完全性保護と暗号化が含まれます。これは、無線インターフェース上の実際のユーザー通信とコントロールプレーンシグナリングを盗聴や改ざんから保護するために不可欠です。

- **27. UE -> gNB: RRCReconfigurationComplete**
  - **背景**: UEは`RRCReconfiguration`を認識し、既存のPDUセッションのDRBが設定されたことを確認します。
  - **詳細**: UEは、`RRCReconfigurationComplete`メッセージ（RRC, TS 38.331）を`UL-DCCH (SRB1)`を介してgNBに送信します[^24][^25]。

- **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に送信します[^5][^16][^17][^18][^19][^20][^21]。このメッセージには、正常に確立された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からポリシー承認を要求します[^6]。この要求には、`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にプッシュします[^6]。このメッセージには、新しい音声QoSフローのための`QoS Rules`と`QFI (QoS Flow Identifier)`が含まれます。QoSフローはSMFによって制御され、PDUセッションの確立または変更によって確立される場合があります[^6]。
  - **技術的含意**: このステップは、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に送信します[^7][^27][^28]。このメッセージは、`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）で応答します[^7][^27][^28]。このメッセージは、`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に送信します[^8][^14][^32][^33]。この要求には、専用音声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に応答します[^8][^14][^32][^33]。

- **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）[^7][^34][^35][^36]。このメッセージには、`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に送信します[^24][^25]。このメッセージには、音声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に送信します[^24][^25]。

- **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）[^7][^34][^35][^36]。これにより、音声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`に送信します[^1][^37][^38][^39][^40][^41]。このメッセージには、音声呼のための提案されたメディアパラメータを記述する`SDP Offer`が含まれており、これには`voice codec`（例：AMR-WB, EVS）、`IP address`、RTPのための`port`が含まれます[^1]。このメッセージは、`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`に返します[^37][^41]。これは、要求が利用可能なサーバーによって受信され、処理中であることを示します。

- **41. App -> DN: SIP 180 Ringing**
  - **背景**: UEのアプリケーションは、着信呼をユーザーに通知します。
  - **詳細**: `App`は、`SIP 180 Ringing`暫定応答（SIP, TS 24.229）を`DN`に送信します[^37][^41]。これは、発呼者に、着信側の電話が鳴っていることを通知します。

- **42. App -> DN: SIP 200 OK (SDP Answer: Voice Codec, IP Address, Port)**
  - **背景**: ユーザーが着信呼を受け入れます。
  - **詳細**: ユーザーが受け入れると、`App`は`SIP 200 OK`最終応答（SIP, TS 24.229）を`DN`に送信します[^37][^41]。このメッセージには、選択されたメディアパラメータ（例：音声コーデック、IPアドレス、ポート）を確認する`SDP Answer`が含まれており、メディアネゴシエーションを完了します。

- **43. DN -> App: SIP ACK**
  - **背景**: IMSコアは、SIPセッション確立を完了するために`SIP 200 OK`を認識します。
  - **詳細**: `DN`は、`SIP ACK`メッセージ（SIP, TS 24.229）を`App`に送信します[^37][^41]。これにより、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を含む）を定義します[^6][^7][^34][^35][^36][^42][^43][^44][^45][^46][^47]。 |
| **無線リソース制御 (RRC)** | TS 38.331 | NR UuインターフェースのRRCプロトコルを規定し、接続管理、ページング、無線ベアラ設定をカバーします[^22][^23][^24][^25][^26][^31][^48][^49][^50][^51]。 |
| **5Gモビリティ管理 (5GMM)** | TS 24.501 | 5Gモビリティ管理のための非アクセス層（NAS）プロトコルを定義し、登録、認証、セキュリティモード手順を含みます[^3][^4][^27][^28][^52][^53][^54]。 |
| **5Gセッション管理 (5GSM)** | TS 24.501 | 5Gセッション管理のためのNASプロトコルを定義し、PDUセッションの確立、変更、解放を含みます[^3][^4][^27][^28][^52][^53][^54]。 |
| **5Gセキュリティアーキテクチャと手順** | TS 33.501 | 認証とキー導出を含む5Gシステムのセキュリティアーキテクチャと手順を規定します[^9][^10][^12][^29][^55][^56][^57][^58]。 |
| **NGアプリケーションプロトコル (NGAP)** | TS 38.413 | N2インターフェース上のNG-RAN（gNB）とAMF間のコントロールプレーンシグナリングプロトコルを規定します[^5][^15][^16][^17][^18][^19][^20][^21][^59][^60]。 |
| **パケット転送制御プロトコル (PFCP)** | TS 29.244 | SMFとUPF間のコントロールプレーンとユーザープレーンインターフェース（N4）のプロトコルを規定します[^8][^14][^32][^33][^61][^62][^63][^64]。 |
| **統合データ管理 (UDM) サービス** | TS 29.503 | UEコンテキスト管理と認証データ取得を含む、統合データ管理のためのサービスベースインターフェースを規定します[^10][^11][^13][^30][^39][^65][^66][^67]。 |
| **IPマルチメディア呼制御プロトコル (SIP/SDP)** | TS 24.229 | IMSのためのSIPとSDPに基づくIPマルチメディア呼制御プロトコルを規定します[^37][^38][^40][^41]。 |

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

| 無線ベアラID | タイプ | 目的 | 運ばれる情報 | 3GPP TS |
| :-------------- | :--- | :------ | :------------------ | :-------- |
| **SRB0** | シグナリング無線ベアラ | 初期RRCメッセージ用（例：RRCSetupRequest, RRCSetup） | 暗号化されていないRRCメッセージ | 38.331 [^22][^26] |
| **SRB1** | シグナリング無線ベアラ | RRC接続確立後のRRCメッセージおよび一部のNASメッセージ用 | 完全性保護および暗号化されたRRCメッセージ；完全性保護および暗号化されたNASメッセージ（SRB2設定前） | 38.331 [^22][^26] |
| **SRB2** | シグナリング無線ベアラ | 高優先度NASメッセージ用（例：5GSMメッセージ） | 完全性保護および暗号化されたNASメッセージ（例：PDUセッション管理） | 38.331 [^22] |
| **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間のシグナリングのためのコントロールプレーンインターフェース[^5][^15]。 |
| **N3** | gNB - UPF | GTP-U | NG-RANとUPF間のデータ転送のためのユーザープレーンインターフェース。 |
| **N4** | SMF - UPF | PFCP | ユーザープレーンセッション管理のためのSMFとUPF間のコントロールプレーンインターフェース[^8][^14]。 |
| **N6** | UPF - DN | IP | UPFとデータネットワーク間のデータ転送のためのユーザープレーンインターフェース。 |
| **N7** | SMF - PCF | HTTP/2 | ポリシー制御決定のためのサービスベースインターフェース[^6]。 |
| **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. 引用文献
[^1]: Communication services (VoLTE/VoNR) - 3GPP, https://www.3gpp.org/technologies/volte-vonr
[^2]: Voice over 5G (Vo5G) core | Nokia.com, https://www.nokia.com/core-networks/voice-over-5g-vo5g-core/
[^3]: 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
[^4]: inside TS 24.501: NAS Security - Tech-invite, https://www.tech-invite.com/3m24/toc/tinv-3gpp-24-501_d.html
[^5]: 3GPP TS 38.413 | PDF | 3 Gpp | Computer Standards - Scribd, https://www.scribd.com/document/696368502/38413-h60
[^6]: 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
[^7]: inside TS 23.502: 5GS PDU Session Modification procedures - Tech-invite, https://www.tech-invite.com/3m23/toc/tinv-3gpp-23-502_p.html
[^8]: PFCP - Wikipedia, https://en.wikipedia.org/wiki/PFCP
[^9]: TS 33.501 (1Q25/342 p.) – 5GS Security Architecture and Procedures, https://www.tech-invite.com/3m33/tinv-3gpp-33-501.html
[^10]: 3GPP TS ab.cde, https://www.3gpp.org/ftp/tsg_sa/WG3_Security/TSGS3_113_Chicago/SA_102/33514-i20.doc
[^11]: 3GPP TS ab.cde - TEC, https://tec.gov.in/pdf/3gpp/26575%202022.pdf
[^12]: 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
[^13]: 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
[^14]: PFCP protocol - Nokia Documentation Center, https://documentation.nokia.com/mag-c/24-7/books/pfcp/pfcp-protocol.html
[^15]: 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
[^16]: 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
[^17]: 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
[^18]: NGAP/NAS Server - Black Duck, https://www.blackduck.com/fuzz-testing/defensics/protocols/ngap-server.html
[^19]: 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
[^20]: TS 38.413 NG-RAN — NG interface – NG Application Protocol (NGAP) - Tech-invite, https://www.tech-invite.com/3m38/tinv-3gpp-38-413.html
[^21]: Specification # 38.413 - 3GPP, https://www.3gpp.org/dynareport/38413.htm
[^22]: RRC-Radio Resource Control in LTE - Techlteworld, https://techlteworld.com/rrc-radio-resource-control-in-lte/
[^23]: Radio Resource Control - Wikipedia, https://en.wikipedia.org/wiki/Radio_Resource_Control
[^24]: TS 38.331 (1Q25/1668 p.) – 5G New Radio RRC Protocol - Tech-invite, https://www.tech-invite.com/3m38/tinv-3gpp-38-331.html
[^25]: 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
[^26]: 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
[^27]: 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
[^28]: TS 24.501 Non-Access-Stratum (NAS) Protocol for 5GS - Tech-invite, https://www.tech-invite.com/3m24/tinv-3gpp-24-501.html
[^29]: Security features for Non-Public Networks - 3GPP, https://www.3gpp.org/technologies/sec-npn
[^30]: inside TS 29.503: Scope, References, Definitions, Abbreviations, https://www.tech-invite.com/3m29/toc/tinv-3gpp-29-503_a.html
[^31]: 3GPP TS 38.331 | PDF | 3 Gpp - Scribd, https://www.scribd.com/document/553227116/38331-g70
[^32]: 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
[^33]: TS 29.244 (1Q25/477 p.) – Interface between 3GPP CP and UP Nodes, https://www.tech-invite.com/3m29/tinv-3gpp-29-244.html
[^34]: S2-2001938r01.docx - 3GPP, https://www.3gpp.org/ftp/tsg_sa/wg2_arch/TSGS2_137e_Electronic/Inbox/Drafts/S2-2001938r01.docx
[^35]: 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
[^36]: TS 23.502 (1Q25/970 p.) – Procedures for the 5G System - Tech-invite, https://www.tech-invite.com/3m23/tinv-3gpp-23-502.html
[^37]: 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
[^38]: Specification #: 24.229 - 3GPP, https://www.3gpp.org/dynareport/24229.htm
[^39]: C4-252094_r1.docx - 3GPP, https://www.3gpp.org/FTP/Meetings_3GPP_SYNC/CT4/Inbox/Drafts/C4-252094_r1.docx
[^40]: 3GPP TS 24.229, https://www.3gpp.org/ftp/tsg_ct/WG1_mm-cc-sm_ex-CN1/TSGC1_130e/Inbox/drafts/C1-213638AccessChange.doc
[^41]: 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
[^42]: 3GPP specification series: 23series, https://www.3gpp.org/DynaReport/23-series.htm
[^43]: 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
[^44]: 3GPP TS 23.502 | PDF | Computing | Communication - Scribd, https://www.scribd.com/document/547371540/23502-g30
[^45]: 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
[^46]: 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
[^47]: ETSI TS 123 502 - Accuris Standards Store, https://store.accuristech.com/standards/etsi-ts-123-502?product_id=2208510
[^48]: Specification # 38.331 - 3GPP, https://www.3gpp.org/dynareport/38331.htm
[^49]: 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
[^50]: 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
[^51]: 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
[^52]: 3GPP TS 24.501 | PDF | Computer Engineering | Networking Standards - Scribd, https://www.scribd.com/document/554597918/24-501-R-17
[^53]: 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
[^54]: Specification # 24.501 - 3GPP, https://www.3gpp.org/dynareport/24501.htm
[^55]: 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
[^56]: Specification # 33.501 - 3GPP, https://www.3gpp.org/dynareport/33501.htm
[^57]: Directory Listing /ftp/specs/archive/33_series/33.501/ - 3GPP, https://www.3gpp.org/ftp/specs/archive/33_series/33.501/
[^58]: 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
[^59]: 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
[^60]: 38455-h40_v3.docx - 3GPP, https://www.3gpp.org/ftp/tsg_ran/WG3_Iu/Draft_Specs/TSG-RAN99/Track%20change/38455-h40_v3.docx
[^61]: ETSI TS 129 244 - Accuris Standards Store, https://store.accuristech.com/standards/etsi-ts-129-244?product_id=2208667
[^62]: S4-250898r03_Lenovo.docx - 3GPP, https://www.3gpp.org/FTP/Meetings_3GPP_SYNC/SA4/Inbox/Drafts/RTC/S4-250898r03_Lenovo.docx
[^63]: 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
[^64]: Specification # 29.244 - 3GPP, https://www.3gpp.org/dynareport/29244.htm
[^65]: 3GPP TS 29.503 | PDF | 3 Gpp | Communication - Scribd, https://www.scribd.com/document/519289142/29503-v16-5g-udm
[^66]: 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
[^67]: Swagger Editor - jdegre.github.io, https://jdegre.github.io/loader.html?yaml=TS29503_Nudm_SDM.yaml