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

## 目次
- [1. エグゼクティブサマリー](#1-エグゼクティブサマリー)
- [2. 音声サービスのための5Gスタンドアローン（SA）アーキテクチャの概要](#2-音声サービスのための5gスタンドアローンsaアーキテクチャの概要)
  - [2.1. 5Gコアネットワーク（5GC）およびNew Radio（NR）コンポーネントの概要](#21-5gコアネットワーク5gcおよびnew-radionrコンポーネントの概要)
  - [2.2. 5G SAにおけるVoNRとその重要性](#22-5g-saにおけるvonrとその重要性)
  - [2.3. UEの初期状態：電源オン、SIB受信、初期登録、およびCM-IDLE/RM-REGISTEREDへの移行](#23-ueの初期状態電源オンsib受信初期登録およびcm-idlerm-registeredへの移行)
- [3. UEトリガーによるサービス要求手順（CM-IDLEからCM-CONNECTEDへ）](#3-ueトリガーによるサービス要求手順cm-idleからcm-connectedへ)
  - [3.1. RRC接続確立](#31-rrc接続確立)
  - [3.2. NASサービス要求メッセージとセキュリティ](#32-nasサービス要求メッセージとセキュリティ)
- [4. 音声のためのIMS PDUセッション変更（専用QoSフロー設定）](#4-音声のためのims-pduセッション変更専用qosフロー設定)
  - [4.1. IMSの役割](#41-imsの役割)
  - [4.2. PDUセッション変更要求（UE発信）](#42-pduセッション変更要求ue発信)
  - [4.3. Nsmf_PDUSession_UpdateSMContext（AMFからSMFへ）](#43-nsmf_pdusession_updatesmcontextamfからsmfへ)
  - [4.4. Npcf_SMPolicyControl_Update（SMFからPCFへ）](#44-npcf_smpolicycontrol_updatesmfからpcfへ)
  - [4.5. PFCPセッション変更要求（SMFからUPFへ）](#45-pfcpセッション変更要求smfからupfへ)
  - [4.6. NGAP PDUセッションリソース変更要求（AMFからgNBへ）](#46-ngap-pduセッションリソース変更要求amfからgnbへ)
- [5. IMSシグナリングおよびRTPメディアパス確立](#5-imsシグナリングおよびrtpメディアパス確立)
- [6. メッセージシーケンスチャート](#6-メッセージシーケンスチャート)
  - [6.1. シーケンス図の詳細説明と推測](#61-シーケンス図の詳細説明と推測)
- [7. 結論](#7-結論)
- [引用文献](#引用文献)

---

## 1. エグゼクティブサマリー

本レポートは、5Gスタンドアローン（SA）ネットワークにおいて、ユーザー機器（UE）が電源オンからSIB受信完了、初期登録を経て待受中（`CM-IDLE`および`RM-REGISTERED`）の状態から、アプリケーションからの音声発信によって通話中になるまでの複雑なシグナリング手順を詳細に解説します。分析は、アクセスネットワーク（`gNB`）、アクセス・モビリティ管理機能（`AMF`）、セッション管理機能（`SMF`）、ユーザープレーン機能（`UPF`）、ポリシー制御機能（`PCF`）、およびIPマルチメディアサブシステム（`IMS`）間の重要な相互作用を網羅しています。

このプロセスは、UEがサービス要求手順を通じて`CM-IDLE`から`CM-CONNECTED`へ移行することから始まり、続いて音声メディアのための専用のQuality of Service（QoS）フローが確立されます。この確立には、3GPPが定める`NAS`、`NGAP`、`PFCP`、および`Nsmf/Npcf`インターフェースが活用されます。レポートでは、キャリアグレードの音声品質を保証する上で、QoSパラメータ（例：会話型音声には`5QI=1`、音声/ビデオライブストリーミングには`5QI=7`）が果たす極めて重要な役割に焦点を当てています。また、NASおよびASのセキュリティモードコマンドや鍵導出を含むセキュリティメカニズムもフローに組み込まれています。最後に、IMSシグナリング（`SIP`）および`RTP`メディアパスの確立が詳細に説明され、VoNR（Voice over New Radio）通話のエンドツーエンドの包括的な視点を提供します。

5G SAアーキテクチャは、そのモジュール式でサービスベースの設計により、無線インターフェースからコアネットワークおよびIMSに至るまで、専用リソースを動的に確立および管理することで、高効率かつQoS保証された音声サービス（VoNR）を実現します。これは、従来の回線交換音声やLTEのVoLTEにおけるEPSフォールバックとは明確に対照的であり、通話設定時間の短縮、音声品質の向上、およびサービス継続性の優位性を提供します。

## 2. 音声サービスのための5Gスタンドアローン（SA）アーキテクチャの概要

### 2.1. 5Gコアネットワーク（5GC）およびNew Radio（NR）コンポーネントの概要

5Gシステム（5GS）は、5Gコアネットワーク（5GC）と5G New Radio（NR）で構成されます。音声サービスに関与する主要なネットワーク機能には、ユーザー機器（`UE`）、`gNB`（次世代NodeB）、アクセス・モビリティ管理機能（`AMF`）、セッション管理機能（`SMF`）、ユーザープレーン機能（`UPF`）、ポリシー制御機能（`PCF`）、およびIPマルチメディアサブシステム（`IMS`）が含まれます [1]。

5GCアーキテクチャは、制御プレーンとユーザープレーンの分離（CUPS）を特徴としており、これは5Gネットワークに不可欠な要素です。CUPSは、制御プレーンとユーザープレーンの独立したスケーリングを可能にし、ネットワークの柔軟な展開を促進します [2]。これにより、ネットワーク事業者は、異なるトラフィックタイプやサービスを異なるユーザープレーンに分離しながら、共通または単一の制御プレーンを維持することができます [2]。

### 2.2. 5G SAにおけるVoNRとその重要性

VoNR（Voice over New Radio）は、5Gのネイティブな音声通話ソリューションであり、5G SAのためにゼロから構築されています。VoNRは、よりクリアな音声を提供し、通話中に4Gへのフォールバックが発生しないという利点があります [4]。これは、5GC機能とIMSを活用して音声処理を行います [1]。VoNRとVoLTEは同じIMSネットワークを音声通話に利用しますが、NR、5GC、および5Gデバイスにおける技術的進歩により、VoLTEと比較してVoNRでは優れたユーザーエクスペリエンスが期待されています [1]。5Gのユニークな特性である1ミリ秒未満の応答時間と迅速なデータ信号交換は、信号および画質の向上に貢献します [1]。

### 2.3. UEの初期状態：電源オン、SIB受信、初期登録、およびCM-IDLE/RM-REGISTEREDへの移行

本シナリオにおけるUEの初期状態は「待受中」であり、これは5GSコネクション管理（CM）状態の`CM-IDLE`および登録管理（RM）状態の`RM-REGISTERED`に対応します [5]。

`CM-IDLE`状態では、UEのAN（アクセスネットワーク）シグナリング接続、N2接続（`gNB`と`AMF`間）、N3接続（`gNB`と`UPF`間）はアクティブではありません [5]。この状態は、UEの電力効率とシグナリング効率を最適化するために設計されています [5]。UEがデータを送受信しない期間が続くと、通常この状態に移行し、UEのバッテリー消費とネットワークリソースの節約に寄与します [6]。

`RM-REGISTERED`状態では、UEはネットワークに正常に登録されており、`AMF`はUEのロケーション情報（少なくともトラッキングエリアコード/リストレベルまで）を保存しています [6]。この状態にあるUEは、サービスを要求することが可能です [6]。

> `CM-IDLE`状態は、UEのバッテリー寿命を延ばし、ネットワークリソースを効率的に利用するために、接続を解放する設計がなされています。しかし、音声通話のようなリアルタイムサービスを開始する際には、迅速なリソース割り当てが不可欠です。この設計は、深いアイドル状態が電力節約に優れる一方で、サービス開始までの遅延を引き起こすという根本的なトレードオフを内包しています。サービス要求手順は、このトレードオフを管理し、必要な時にUEを迅速に`CM-CONNECTED`状態に移行させることで、電力効率と応答性のバランスを確保するように考案されています。このバランスの取り方は、モバイルネットワーク設計の中心的な課題であり、5Gにおける柔軟な接続管理状態と迅速なシグナリング手順の必要性を強調しています。

## 3. UEトリガーによるサービス要求手順（CM-IDLEからCM-CONNECTEDへ）

サービス要求手順は、UEが`CM-IDLE`状態にあるときに、アップリンクシグナリングメッセージ（例：音声通話のため）やユーザーデータを送信するため、またはネットワークからのページング要求に応答するために開始されます [7]。その主な目的は、`AMF`とのセキュアな接続を確立し、UEを`CM-IDLE`状態から`CM-CONNECTED`状態へ移行させることです [5]。

### 3.1. RRC接続確立

UEは`gNB`との間でRRC（Radio Resource Control）接続確立を開始します。RRCは、UEと基地局の間で使用される5G NRのレイヤー3プロトコルです [9]。

#### RRC接続要求（RRC Connection Request）
UEは、アップリンクの`CCCH`（Common Control Channel）論理チャネル上で`RRCSetupRequest`メッセージを`gNB`に送信します [10]。このメッセージには、UEのコンテキスト検索と下位レイヤーによる競合解決を容易にするための`ue-Identity`（例：`ng-5G-S-TMSI-Part1`または`randomValue`）が含まれます [10]。特に、RRC接続確立の理由を示す`establishmentCause`が含まれており、音声通話の場合には`mo-VoiceCall`が指定されます [10]。

#### RRC接続設定（RRC Connection Setup）
`gNB`は、ダウンリンクの`CCCH`論理チャネル上で`RRCSetup`メッセージをUEに送信します [10]。このメッセージは`SRB1`（Signaling Radio Bearer 1）を確立するために使用され、`SRB1`の構成情報である`radioBearerConfig`や`masterCellGroup`の構成が含まれます [10]。

#### RRC接続設定完了（RRC Connection Setup Complete）
UEは、アップリンクの`DCCH`（Dedicated Control Channel）論理チャネル上で`RRCSetupComplete`メッセージを`gNB`に送信します [10]。このメッセージはRRC接続確立の成功を確認するもので、`selectedPLMN-Identity`、`registeredAMF`、およびサービス要求を含む`dedicatedNAS-Message`が含まれる場合があります [10]。

> RRC接続確立の初期段階では、`RRCSetupRequest`や`RRCSetup`といったメッセージが共通チャネル（`CCCH`）を使用します。これは、専用接続がまだ確立されていないため、迅速かつ効率的な初期ハンドシェイクを可能にするためです。これにより、初期接続のオーバーヘッドが最小限に抑えられます。`SRB1`が確立されると、その後のメッセージ（`RRCSetupComplete`など）は専用チャネル（`DCCH`）に切り替わります。これにより、カプセル化されたNASメッセージのような、より詳細でセキュアな情報の転送が可能になります。この段階的なリソース割り当てのアプローチは、初期接続の速度と、その後の複雑なシグナリングのための容量の両方を最適化します。

### 3.2. NASサービス要求メッセージとセキュリティ

#### SERVICE REQUESTメッセージ
UEは、`SERVICE REQUEST`メッセージを`AMF`に送信し、これはRRCメッセージ内にカプセル化されます [7]。このメッセージの目的は、UEの`5GMM`（5G Mobility Management）モードを`CM-IDLE`から`CM-CONNECTED`へ変更することです [11]。

`SERVICE REQUEST`メッセージには、Service Request Message Identity、`ngKSI`（NAS鍵セット識別子）、Service Type（例：音声通話設定のための「Mobile-Originated signalling」）、`5G-S-TMSI`、Uplink Data Status、PDU Session Status、Allowed PDU Session Status、NAS Message Containerといった情報要素（IE）が含まれます [11]。
Service Typeは、UEがサービスを要求する理由を示し、例えばモバイル発信データの場合は`0x01`が指定され、ネットワークにデータ転送のためのリソース割り当てを促します [11]。
`5G-S-TMSI`は`AMF`によってUEに割り当てられた一時的な識別子であり、AMFセットIDとAMFポインタを含みます [11]。
NAS Message Containerは、Service Requestが初期NASメッセージである場合に、非クリアテキストIEをカプセル化します [8]。

初期の`SERVICE REQUEST`メッセージは、セキュリティヘッダータイプ`0x8`（サービス要求のための非標準L3メッセージ）または`0x0`（セキュリティ保護されていないプレーンなNASメッセージ）で送信されます [12]。セキュリティモードコマンドが完了すると、その後のメッセージは完全性保護され、暗号化されます（`0x2`） [11]。

#### NGAP Initial UE Message
`gNB`は、`SERVICE REQUEST`メッセージを`Initial UE Message`（NGAP）内にカプセル化して`AMF`に転送します [13]。このメッセージには、`5G-S-TMSI`、Selected PLMN ID、Location information、Establishment causeといった情報が含まれます [8]。

#### NASセキュリティモードコマンド手順
`AMF`は、セキュアなNAS通信を確立するために`SECURITY MODE COMMAND`を開始します [14]。この手順の目的は、セキュリティコンテキスト（例：一次認証後）を使用開始するか、アルゴリズムを変更することです [14]。

`SECURITY MODE COMMAND`メッセージは、暗号化されずに送信されますが、5G NAS完全性鍵（`KAMF`から導出）によって完全性保護されます [15]。このメッセージには、UEのセキュリティ能力の複製、選択されたNASアルゴリズム、および`ngKSI`が含まれます [16]。

鍵導出に関して、`KNASint`（NAS完全性鍵）と`KNASenc`（NAS暗号化鍵）は、UEと`AMF`によって`KAMF`からKDF（Key Derivation Function）を使用して導出されます [18]。これらの鍵のためのKDFへの入力には、`FC=0x69`、algorithm type distinguisher (`P0`)、およびalgorithm identity (`P1`)が含まれます [21]。

UEは、完全性保護の検証を行い、`K_AMF_change_flag`が設定されている場合は新しい`KAMF`を導出し、NAS完全性保護と暗号化を開始し、`NAS Security Mode Complete`メッセージ（暗号化され、完全性保護されたもの）を送信します [16]。

#### ASセキュリティモードコマンド手順
`gNB`は、RRCおよびユーザープレーン（UP）セキュリティの活性化のために`AS Security Mode Command`を開始します [22]。この手順の目的は、RRCおよびUPセキュリティアルゴリズムのネゴシエーションと活性化です [16]。

鍵導出に関して、`KRRCint`、`KRRCenc`、`KUPint`、`KUPenc`は、MEと`gNB`によって`KgNB`からKDFを使用して導出されます [18]。
`KgNB`自体は、MEと`AMF`によって`KAMF`から導出されます [18]。これらの鍵のためのKDFへの入力は、NAS鍵の場合と同様です [21]。

> 5Gシステムは、階層的な鍵導出構造（`K`, `CK/IK` -> `KAUSF` -> `KSEAF` -> `KAMF` -> `KgNB` -> `K_NAS/K_RRC/K_UP`鍵）を採用しています [18]。この構造は、強力な暗号学的分離を保証し、鍵の漏洩による影響を限定します。まず、UEと`AMF`間のNASセキュリティが活性化され、機密性の高いモビリティおよびセッション管理シグナリングが保護されます。その後、UEと`gNB`間のASセキュリティが活性化され、RRCシグナリングとユーザープレーンデータが保護されます。この二段階のセキュリティ活性化は、ユーザーデータが送信される前に制御プレーンメッセージのセキュアなチャネルが確立されることを保証し、接続の最初から堅牢な保護を提供します。鍵導出における`HMAC-SHA256`の使用は、暗号学的強度をさらに高めます [23]。

## 4. 音声のためのIMS PDUセッション変更（専用QoSフロー設定）

### 4.1. IMSの役割

`IMS`は5Gにおける音声サービスに不可欠であり、音声の接続管理を提供します [1]。VoNRは、IP音声処理のために`IMS`を利用します [1]。

### 4.2. PDUセッション変更要求（UE発信）

UEは、音声のための専用QoSフローを確立するために、PDU Session Modification手順を開始します [26]。この手順は、NASメッセージ（N1 SMコンテナ）内の`PDU Session Modification Request`として送信されます [26]。

このメッセージには、PDU session ID、音声トラフィックの`SDF`（Service Data Flow）を記述するPacket Filters、操作（追加/変更）、Requested QoS、Segregationといった情報が含まれます [26]。UEは、`Service Request`内のList Of PDU Sessions To Be Activatedを使用して、UP接続を活性化するPDUセッションを特定します [7]。

### 4.3. Nsmf_PDUSession_UpdateSMContext（AMFからSMFへ）

`AMF`は、`SMF`に対して`Nsmf_PDUSession_UpdateSMContext`を呼び出し、SMコンテキストIDとN1 SMコンテナ（`PDU Session Modification Request`を含む）を渡します [26]。この目的は、SMコンテキストを更新し、UEからのN1 SM情報を提供することです [27]。

`SMF`はUEからRequested QoSを受信します。音声メディアの場合、`SMF`は通常、特定の特性を持つ`GBR`（Guaranteed Bit Rate）QoSフローを設定します。

#### 音声のための5QI
- `5QI=1`：会話型音声（`GBR`、優先度レベル20、PDB 100ms、PER 10^-2） [28]。
- `5QI=7`：音声、ビデオ（ライブストリーミング）（非`GBR`、優先度レベル70、PDB 100ms、PER 10^-6） [28]。

> `5QI=1`（`GBR`）と`5QI=7`（非`GBR`）の選択は、事業者の方針と特定のサービス要件に依存しますが、`5QI=1`は伝統的に保証された音声品質と関連付けられています。

#### QFI（QoS Flow Identifier）
`QFI`はPDUセッション内で一意であり、N3/N9カプセル化ヘッダーで伝送されます。動的に割り当てられるか、`5QI`と等しくなる場合があります（64未満の場合） [31]。

#### ARP（Allocation and Retention Priority）
`ARP`は、優先度レベル（1-15、1が最高優先度）、プリエンプション能力/脆弱性に関する情報を含みます。リソース制限時のアドミッション制御やリソースプリエンプションに使用されます [31]。

### 4.4. Npcf_SMPolicyControl_Update（SMFからPCFへ）

`SMF`は、専用QoSフローのポリシー規則を取得/更新するために`PCF`と連携する場合があります [36]。`SMF`は`PCF`に対して`Npcf_SMPolicyControl_Update`を呼び出します [38]。`PCF`は`SMF`にQoSパラメータを含むPCC規則を提供します [39]。

> `PCF`は、音声サービスのためのQoSポリシーを定義し、強制する上で中心的な役割を担います。`PCF`は`SMF`と連携し、音声通話に割り当てられるネットワークリソースが、要求されるQoS特性（例：低遅延、低パケット損失）を満たすことを保証します。このポリシー駆動型のアプローチにより、事業者はサービスタイプ、ユーザーのサブスクリプション、およびネットワークの状態に基づいてネットワークリソースを動的に管理でき、リソース利用を最適化しながらキャリアグレードの音声品質を確保します。

### 4.5. PFCPセッション変更要求（SMFからUPFへ）

`SMF`は、PFCPセッションパラメータを更新し、QER（QoS Enforcement Rule）を作成/変更するために、`UPF`に`PFCP Session Modification Request`を送信します [40]。

このメッセージには、新しい音声QoSフローのQoS強制を定義するための`Create QER` IEが含まれます [42]。
`Create QER` IEには、QER ID、Gate Status（音声の場合はオープン）、`MBR`（Maximum Bit Rate）、`GBR`（Guaranteed Bit Rate）、`QFI`（QoS Flow Identifier）が含まれます [44]。
`QFI`は、`UPF`がユーザープレーンのトラフィックをQoSフローにマッピングするために使用されます [31]。

> `PFCP`（Packet Forwarding Control Protocol）は、`SMF`から`UPF`を制御する上で極めて重要であり、個々のQoSフローに対するきめ細かなQoS強制を可能にします。`PFCP Session Modification Request`内の`Create QER` IEにより、`SMF`は`UPF`に対し、音声トラフィックの処理方法（例：特定のGBR/MBRの適用、QFIを使用したパケットの優先順位付け）を指示できます。これにより、ユーザープレーンのリソースが音声の厳しいQoS要件（低遅延や保証された帯域幅など）を満たすように正確に構成され、トラフィック転送の時点で直接適用されます。

### 4.6. NGAP PDUセッションリソース変更要求（AMFからgNBへ）

`AMF`は、`gNB`に`PDU SESSION RESOURCE MODIFY REQUEST`を送信します [13]。

このメッセージの目的は、PDUセッション構成の変更、QoSフローの設定/変更、およびNG/Uu上のリソースの割り当て/変更を可能にすることです [46]。

メッセージには、音声QoSフローのための`QoS Flow Add or Modify Request List` IEと`QoS Flow Level QoS Parameters`が含まれます [47]。
`QoS Flow Level QoS Parameters`には、音声のための`5QI`（例：1または7）、`ARP`、およびその他のQoS特性が含まれます [47]。

`gNB`は、受け入れられた各QoSフローを`DRB`（Data Radio Bearer）に関連付けます [31]。

> `PDU SESSION RESOURCE MODIFY REQUEST`は、コアネットワークのQoSポリシーを無線リソース構成に変換する上で極めて重要です。特定のQoSパラメータ（`5QI=1`または`7`、`ARP`など）を`QoS Flow Level QoS Parameters` IEに含めることで、`AMF`は`gNB`に対し、音声トラフィックの厳格な要件を満たす適切な無線リソース（`DRB`）を割り当てるよう指示します。これにより、一般的なボトルネックである無線インターフェースが音声品質のために最適化され、シームレスな会話体験に不可欠な遅延とパケット損失が最小限に抑えられます。

---

## 5. IMSシグナリングおよびRTPメディアパス確立

### 5.1. SIP INVITE（UEからIMSへ）

専用QoSフローが確立されると、UEのIMSクライアントは音声通話を開始するために`SIP INVITE`メッセージを送信します [4]。このメッセージは、確立されたPDUセッションとシグナリング用の専用QoSフロー（例：IMSシグナリング用の`5QI=5` [28]）を経由して伝送されます。

### 5.2. SIPネゴシエーションとRTPパス設定

発信側および着信側のUEとIMSは、コーデック方式、IPアドレス、ポート番号、およびその他の音声サービス情報についてSIPネゴシエーションを実行します [1]。SIPネゴシエーションが成功した後、5GCは`RTP/RTCP`データフロー（実際の音声メディア）のために`5QI=1`の新しいQoSフローを設定します [1]。`gNB`は、これらのメディアQoSフローに対応する`DRB`を設定します [1]。

> IMS音声通話における重要な側面は、シグナリング（`SIP`）とメディア（`RTP`）に異なるQoSフローを使用することです。通常、IMSシグナリングは非GBR QoSフロー（例：`5QI=5`）を使用し、これは配信を優先しますが、特定のビットレートを保証しません。一方、音声メディア（`RTP`）はGBR QoSフロー（例：`5QI=1`）を使用し、保証された帯域幅と低遅延を提供します。これは、高品質な会話型音声にとって不可欠です。この分離により、ネットワークはシグナリング（信頼性、初期設定のための低遅延）とメディア（保証された帯域幅、非常に低い遅延、低いパケット損失）の特定のニーズに合わせて異なるQoS処理を適用でき、リソース利用とユーザーエクスペリエンスを最適化します。

## 6. メッセージシーケンスチャート

```plantuml
@startuml
autonumber

title 5G SA VoNR Call Flow with Detailed Protocols (TS 38.331, 24.501, etc.)

box "User Equipment (UE)" #lightgreen
    participant "App (IMS Client)" as App
    participant "5G Modem" as Modem
end box

box "Access Network" #lightcyan
    participant "gNB\n(NG-RAN)" as gNB
end box

box "5G Core Network" #lavender
    participant AMF
    participant SMF
    participant UPF
    participant PCF
end box

box "IMS Network" #lightyellow
    participant IMS
end box

' == Call Initiation and Connection Setup ==
group RRC Connection & Service Request \n(UE state: CM-IDLE -> CM-CONNECTED)
    App -> Modem: Initiate Voice Call
    Modem -> gNB: **PRACH** preamble \n// Physical Channel
    gNB --> Modem: Random Access Response
    Modem -> gNB: **RRCSetupRequest** (TS 38.331) \n(establishmentCause=mo-VoiceCall) \n// Transport: UL-SCH / Logical: CCCH (on SRB0)
    gNB --> Modem: **RRCSetup** (TS 38.331) \n(srb-ToAddModList: SRB1) \n// Transport: DL-SCH / Logical: CCCH (on SRB0)
    Modem -> gNB: **RRCSetupComplete** (TS 38.331) \n- dedicatedNAS-Message: **SERVICE REQUEST** (5GMM, TS 24.501) \n// Transport: UL-SCH / Logical: DCCH (on SRB1)
    gNB -> AMF: **INITIAL UE MESSAGE** \n(NGAP, TS 38.413) \n- RAN-UE-NGAP-ID, NAS-PDU (Service Request) \n// N2 Interface
end

' == Security Procedures ==
group Authentication & Security Establishment \n(NAS & AS)
    AMF -> Modem: **AUTHENTICATION REQUEST** (5GMM, TS 24.501) \n- Via gNB: **DOWNLINK NAS TRANSPORT** (NGAP) -> **DLInformationTransfer** (RRC) \n// N1 Interface
    Modem -> AMF: **AUTHENTICATION RESPONSE** (5GMM, TS 24.501) \n- Via gNB: **ULInformationTransfer** (RRC) -> **UPLINK NAS TRANSPORT** (NGAP) \n// N1 Interface
    AMF -> Modem: **SECURITY MODE COMMAND** (5GMM, TS 24.501) \n- Selected NAS security algorithms, ngKSI \n- (Integrity Protected) \n// N1 Interface
    Modem -> AMF: **SECURITY MODE COMPLETE** (5GMM, TS 24.501) \n- (Integrity Protected & Ciphered) \n// N1 Interface
    AMF -> gNB: **INITIAL CONTEXT SETUP REQUEST** \n(NGAP, TS 38.413) \n- Security Key (KgNB), UE-AMBR \n- PDU Session Resource to be Setup List (for existing IMS PDU Session) \n// N2 Interface
    gNB -> Modem: **RRCReconfiguration** (TS 38.331) \n- securityModeConfig (AS algorithms) \n- srb-ToAddModList (SRB2), drb-ToAddModList \n// Transport: DL-SCH / Logical: DCCH (on SRB1)
    Modem -> gNB: **RRCReconfigurationComplete** (TS 38.331) \n// Transport: UL-SCH / Logical: DCCH (on SRB1)
    gNB -> AMF: **INITIAL CONTEXT SETUP RESPONSE** \n(NGAP, TS 38.413) \n// N2 Interface
end

' == QoS Flow for SIP Signaling ==
group Dedicated QoS Flow for IMS Signaling \n(5QI=5)
    Modem -> AMF: **UL NAS TRANSPORT** (NGAP) carrying: \n**PDU SESSION MODIFICATION REQUEST** (5GSM, TS 24.501) \n- Requested QoS for IMS Signaling (5QI=5) \n// N1 Interface (on SRB2)
    AMF -> SMF: **Nsmf_PDUSession_UpdateSMContext** \n(HTTP/2, TS 29.502) \n- N1 SM container (PDU Session Mod. Req.) \n// N11 Interface
    SMF -> PCF: **Npcf_SMPolicyControl_Update** \n(HTTP/2, TS 29.512) \n// N7 Interface
    PCF --> SMF: **Npcf_SMPolicyControl_Update Response** \n- PCC Rules (QoS: 5QI=5, QFI_IMS=X) \n// N7 Interface
    SMF -> UPF: **PFCP Session Modification Request** \n(PFCP, TS 29.244) \n- Create PDR, Create QER (QFI=X, 5QI=5) \n// N4 Interface
    UPF --> SMF: **PFCP Session Modification Response** \n// N4 Interface
    SMF -> AMF: **Nsmf_PDUSession_UpdateSMContext Response** \n- N2 SM Info (QoS Profile for 5QI=5) \n// N11 Interface
    AMF -> gNB: **PDU SESSION RESOURCE MODIFY REQUEST** \n(NGAP, TS 38.413) \n- QoS Flow Add List (QFI=X, 5QI=5) \n// N2 Interface
    gNB -> Modem: **RRCReconfiguration** (TS 38.331) \n- drb-ToAddModList (DRB_IMS) \n- sdap-Config, rlc-BearerConfig \n// Transport: DL-SCH / Logical: DCCH (on SRB1)
    Modem -> gNB: **RRCReconfigurationComplete** (TS 38.331) \n// Transport: UL-SCH / Logical: DCCH (on SRB1)
    gNB -> AMF: **PDU SESSION RESOURCE MODIFY RESPONSE** \n(NGAP, TS 38.413) \n// N2 Interface
end

' == IMS Call Setup using SIP ==
group IMS Call Setup
    App -> IMS: **SIP INVITE** (RFC 3261) \n- Path: App -> Modem -> gNB -> UPF -> IMS \n- Bearer: **DRB_IMS** (Logical: DTCH), GTP-U Tunnel (N3) \n- QoS: **QFI=X, 5QI=5**
    IMS <-> IMS: SIP Negotiation \n(SDP offer/answer)
end

' == QoS Flow for RTP Media ==
group Dedicated QoS Flow for Voice Media \n(5QI=1)
    IMS -> PCF: **AF Request** \n(e.g., Diameter AAR or Npcf_PolicyAuthorization, TS 29.514) \n- Media Info (from SDP) \n// N5 (Rx) Interface
    PCF -> SMF: **Npcf_SMPolicyControl_Update** \n(HTTP/2, TS 29.512) \n- PCC Rules (QoS: 5QI=1, QFI_Voice=Y, GBR) \n// N7 Interface
    SMF -> UPF: **PFCP Session Modification Request** \n(PFCP, TS 29.244) \n- Create PDR, Create QER (QFI=Y, 5QI=1, GBR) \n// N4 Interface
    UPF --> SMF: **PFCP Session Modification Response** \n// N4 Interface
    SMF -> AMF: **Nsmf_PDUSession_UpdateSMContext Request** \n- N2 SM Info (QoS Profile for 5QI=1) \n// N11 Interface
    AMF -> gNB: **PDU SESSION RESOURCE MODIFY REQUEST** \n(NGAP, TS 38.413) \n- QoS Flow Add List (QFI=Y, 5QI=1, GBR) \n// N2 Interface
    gNB -> Modem: **RRCReconfiguration** (TS 38.331) \n- drb-ToAddModList (DRB_Voice) \n// Transport: DL-SCH / Logical: DCCH (on SRB1)
    Modem -> gNB: **RRCReconfigurationComplete** (TS 38.331) \n// Transport: UL-SCH / Logical: DCCH (on SRB1)
    gNB -> AMF: **PDU SESSION RESOURCE MODIFY RESPONSE** \n(NGAP, TS 38.413) \n// N2 Interface
end

' == Call Connection and Media Flow ==
group Call Connected & Media Flow
    IMS -> App: **SIP 200 OK** (RFC 3261) \n- Bearer: **DRB_IMS** (Logical: DTCH), GTP-U Tunnel (N3) \n- QoS: **QFI=X, 5QI=5**
    App -> Modem: Start Media Streaming
    Modem <-> UPF: **RTP/RTCP Media** \n- Path: Modem <-> gNB <-> UPF \n- Bearer: **DRB_Voice** (Logical: DTCH), GTP-U Tunnel (N3) \n- QoS: **QFI=Y, 5QI=1**
end

@enduml
```

### 6.1. シーケンス図の詳細説明と推測

上記のシーケンス図は、UEが電源オンから初期登録を経て待受状態（`CM-IDLE`および`RM-REGISTERED`）にある状況から、アプリケーションを介して音声通話を開始し、通話中になるまでの主要なメッセージフローを示しています。

**RRC接続確立 (RRC Connection Establishment)**
- **UE → gNB: `RRCSetupRequest` (`establishmentCause=mo-VoiceCall`)**: UEのアプリケーションが音声通話を開始すると、UEはまず`gNB`との無線リソース制御（RRC）接続を確立する必要があります。UEは、アップリンク共通制御チャネル（`CCCH`）上で`RRCSetupRequest`メッセージを送信します。このメッセージには、RRC接続確立の理由を示す`establishmentCause`として「`mo-VoiceCall`」（モバイル発信音声通話）が設定されます [10]。UEの識別子（`ue-Identity`）も含まれ、`gNB`がUEのコンテキストを検索し、競合解決を行うのに役立ちます [10]。
- **gNB → UE: `RRCSetup` (`SRB1 config`)**: `gNB`は、ダウンリンク`CCCH`上で`RRCSetup`メッセージを応答します。このメッセージは、UEと`gNB`間の最初のシグナリング無線ベアラーである`SRB1`（Signaling Radio Bearer 1）を確立するための無線ベアラー設定（`radioBearerConfig`）を含みます [10]。
- **UE → gNB: `RRCSetupComplete` (`Service Request`)**: UEは、`SRB1`が確立された後、アップリンク専用制御チャネル（`DCCH`）上で`RRCSetupComplete`メッセージを送信し、RRC接続の成功を`gNB`に確認します。このメッセージには、NAS（Non-Access-Stratum）メッセージである`Service Request`がカプセル化されて含まれます [10]。この段階で、UEは`CM-IDLE`状態から`CM-CONNECTED`状態に移行します [5]。

**サービス要求とNASセキュリティモードコマンド手順**
- **gNB → AMF: `Initial UE Message` (`Service Request`, `5G-S-TMSI`, `Establishment Cause`)**: `gNB`は、UEから受信した`Service Request`メッセージを、NGAP（NG Application Protocol）の`Initial UE Message`として`AMF`に転送します [13]。このメッセージには、UEの識別子である`5G-S-TMSI`と、RRC接続確立の理由である`Establishment Cause`が含まれます [8]。`AMF`はこれにより、UEが`CM-CONNECTED`状態に移行したことを認識します [5]。
- **AMF → UE: `SECURITY MODE COMMAND` (`ngKSI`, NAS algorithms)**: `AMF`は、UEとのセキュアなNAS通信を確立するために、NASセキュリティモードコマンド手順を開始し、`SECURITY MODE COMMAND`メッセージをUEに送信します [14]。このメッセージは、暗号化されずに送信されますが、5G NAS完全性鍵（`KAMF`から導出される）によって完全性保護されます [15]。メッセージには、UEのセキュリティ能力の複製、選択されたNASアルゴリズム、および`ngKSI`（NAS鍵セット識別子）が含まれます [16]。`KNASint`（NAS完全性鍵）と`KNASenc`（NAS暗号化鍵）は、KDF（Key Derivation Function）を使用して`KAMF`から導出されます [18]。
- **UE → AMF: `SECURITY MODE COMPLETE`**: UEは、`SECURITY MODE COMMAND`メッセージの完全性を検証し、NAS完全性保護と暗号化を開始した後、`NAS Security Mode Complete`メッセージを`AMF`に送信します。このメッセージは、暗号化され、完全性保護されています [16]。

**ASセキュリティモードコマンド手順**
- **AMF → gNB: `NGAP Security Mode Command` (`KgNB`)**: `AMF`は、`gNB`に対し、RRCおよびユーザープレーン（UP）セキュリティの活性化を指示します。この指示は、通常、UEコンテキスト設定手順の一部として、または別途のシグナリングによって行われ、`gNB`に`KgNB`（gNB固有の鍵）を提供します [18]。
- **gNB → UE: `RRC Security Mode Command`**: `gNB`は、`RRC Security Mode Command`メッセージをUEに送信し、RRCおよびUPセキュリティアルゴリズムのネゴシエーションと活性化を行います [16]。
- **UE → gNB: `RRC Security Mode Complete`**: UEは、RRCセキュリティモードコマンド手順の完了を確認します。`KRRCint`、`KRRCenc`、`KUPint`、`KUPenc`といったRRCおよびUPセキュリティ鍵は、MEと`gNB`によって`KgNB`からKDFを使用して導出されます [18]。

**IMSシグナリング用QoSフローのPDUセッション変更 (`5QI=5`)**
- **UE → AMF: `UL NAS Transport` (`PDU Session Modification Request` (`PDU Session ID`, `Requested QoS` (`5QI=5`)))**: UEは、音声通話開始のためのIMSシグナリング（`SIP`）トラフィックを送信するために、既存のPDUセッションのQoSフローを変更する要求を開始します。これは、`PDU Session Modification Request`メッセージをNASメッセージとして`AMF`に送信することで行われます [26]。この要求には、IMSシグナリング用のQoS特性として`5QI=5`が指定されます [28]。
- **AMF → SMF: `Nsmf_PDUSession_UpdateSMContext` (`SM Context ID`, N1 SM container (`PDU Session Modification Request`))**: `AMF`は、UEからのNASメッセージを`SMF`に転送するために、サービスベースインターフェース（SBI）を介して`Nsmf_PDUSession_UpdateSMContext`サービスオペレーションを呼び出します [27]。
- **SMF → PCF: `Npcf_SMPolicyControl_Update` (`Requested QoS for SIP`)**: `SMF`は、IMSシグナリング用のQoSポリシーを取得または更新するために、`PCF`と連携します [36]。`SMF`は`Npcf_SMPolicyControl_Update`を`PCF`に送信します [38]。
- **PCF → SMF: `Npcf_SMPolicyControl_Update Response` (`PCC rules for SIP`)**: `PCF`は、`SMF`にIMSシグナリング用のQoSパラメータを含むPCC（Policy and Charging Control）規則を提供します [39]。`PCF`は、サービスタイプやユーザーのサブスクリプションに基づいて、適切なQoS特性が適用されるようにします。
- **SMF → UPF: `PFCP Session Modification Request` (`Create QER` (`QFI_SIP`, `5QI=5`, `MBR`))**: `SMF`は、`UPF`にPFCP（Packet Forwarding Control Protocol）セッションパラメータを更新するよう指示します。`PFCP Session Modification Request`メッセージには、新しいQoSフローのQoS強制ルール（QER）を作成するための`Create QER` IEが含まれます [42]。このQERは、`QFI`（QoS Flow Identifier）と`5QI=5`、および最大ビットレート（`MBR`）などのパラメータを指定します [44]。
- **UPF → SMF: `PFCP Session Modification Response`**: `UPF`は、QERの作成/変更が完了したことを`SMF`に確認します。
- **SMF → AMF: `Nsmf_PDUSession_UpdateSMContext Response`**: `SMF`は、PDUセッションのSMコンテキストが更新されたことを`AMF`に通知します。
- **AMF → gNB: `PDU SESSION RESOURCE MODIFY REQUEST` (`QoS Flow Level QoS Parameters` (`QFI_SIP`, `5QI=5`))**: `AMF`は、`gNB`にPDUセッションリソースの変更を要求します。このメッセージには、IMSシグナリング用のQoSフローの`QoS Flow Level QoS Parameters`（`QFI_SIP`, `5QI=5`）が含まれ、`gNB`に適切な無線リソースを割り当てるよう指示します [47]。
- **gNB → AMF: `PDU SESSION RESOURCE MODIFY RESPONSE`**: `gNB`は、リソースの変更が完了したことを`AMF`に確認します。

**IMSシグナリングとRTPメディアパス確立**
- **UE → IMS: `SIP INVITE` (via PDU Session with `5QI=5`)**: UEのIMSクライアントは、確立されたPDUセッションと専用のQoSフロー（`5QI=5`）を介して、着信側への`SIP INVITE`メッセージを送信し、音声通話のセットアップを開始します [4]。
- **IMS ↔ IMS: `SIP Negotiation` (e.g., SDP offer/answer)**: 発信側および着信側のUEとIMSは、コーデック方式、IPアドレス、ポート番号、およびその他の音声サービス情報についてSIPネゴシエーション（SDPのoffer/answerを含む）を実行します [1]。

**RTPメディア用QoSフローのPDUセッション変更 (`5QI=1`)**
- **IMS → SMF: `Nsmf_PDUSession_UpdateSMContext` (Request for `GBR` QoS for `RTP`)**: SIPネゴシエーションが成功し、メディアパスの確立が必要になると、`IMS`は`SMF`にRTPメディアトラフィックのための`GBR` QoSフローを要求します。
- **SMF → PCF: `Npcf_SMPolicyControl_Update` (Requested QoS for `RTP`)**: `SMF`は、RTPメディア用のQoSポリシーを更新するために`PCF`と連携します。
- **PCF → SMF: `Npcf_SMPolicyControl_Update Response` (`PCC rules for RTP`)**: `PCF`は、RTPメディア用のQoSパラメータを含むPCC規則を`SMF`に提供します。音声メディア（`RTP`）には、通常`5QI=1`が割り当てられ、これは保証されたビットレートと低い遅延を特徴とします [1]。
- **SMF → UPF: `PFCP Session Modification Request` (`Create QER` (`QFI_RTP`, `5QI=1`, `GBR`, `MBR`))**: `SMF`は、`UPF`にRTPメディア用の新しいQERを作成するよう指示します。このQERは、`QFI_RTP`、`5QI=1`、保証ビットレート（`GBR`）、最大ビットレート（`MBR`）などのパラメータを指定します。
- **UPF → SMF: `PFCP Session Modification Response`**: `UPF`は、QERの作成/変更が完了したことを`SMF`に確認します。
- **SMF → AMF: `Nsmf_PDUSession_UpdateSMContext Response`**: `SMF`は、PDUセッションのSMコンテキストが更新されたことを`AMF`に通知します。
- **AMF → gNB: `PDU SESSION RESOURCE MODIFY REQUEST` (`QoS Flow Level QoS Parameters` (`QFI_RTP`, `5QI=1`))**: `AMF`は、`gNB`にRTPメディア用のQoSフローのPDUセッションリソースの変更を要求します。
- **gNB → AMF: `PDU SESSION RESOURCE MODIFY RESPONSE`**: `gNB`は、リソースの変更が完了したことを`AMF`に確認します。

**通話応答とメディアパス活性化**
- **UE ← IMS: `SIP 200 OK` (via PDU Session with `5QI=5`)**: 着信側UEが通話に応答すると、`IMS`は発信側UEに`SIP 200 OK`メッセージを送信し、通話が確立されたことを示します。このメッセージは、シグナリング用のQoSフロー（`5QI=5`）を介して伝送されます。
- **UE ↔ UPF: `RTP/RTCP Media` (via dedicated PDU Session with `5QI=1`)**: `SIP 200 OK`の交換後、実際の音声メディア（`RTP/RTCP`）トラフィックは、確立された専用のQoSフロー（`5QI=1`）を介してUEと`UPF`の間で直接送受信されます。これにより、高品質で低遅延の音声通話が実現されます。

> IMS音声通話における重要な設計は、シグナリング（`SIP`）とメディア（`RTP`）に異なるQoSフローを使用することです。通常、IMSシグナリングは非GBR QoSフロー（例：`5QI=5`）を使用し、これは配信の信頼性を重視しますが、特定のビットレートは保証しません。一方、音声メディア（`RTP`）はGBR QoSフロー（例：`5QI=1`）を使用し、保証された帯域幅と低い遅延を提供します。これは、高品質の会話型音声にとって不可欠です。この分離により、ネットワークはシグナリング（初期設定の信頼性と低遅延）とメディア（保証された帯域幅、非常に低い遅延、低いパケット損失で継続的な会話）の特定のニーズに合わせて異なるQoS処理を適用でき、リソース利用とユーザーエクスペリエンスを最適化します。

## 7. 結論

本レポートで詳述した分析は、5G SAネットワークにおけるUE発信の音声通話が、待受状態から通話中状態へとシームレスに移行するための、複雑かつ高度に調整された手順の集合体であることを明確に示しています。このプロセスは、無線リソースの動的な割り当て、コアネットワーク機能間の綿密な連携、および多層的なQoS制御によって特徴づけられます。

UEが`CM-IDLE`状態からサービス要求を開始し、RRC接続を確立する初期段階から、NASおよびASセキュリティモードコマンドによる堅牢なセキュリティの確立、そしてIMSシグナリングとメディアのための専用QoSフローの動的な設定に至るまで、各ステップは音声通話の品質と効率を最大化するように設計されています。特に、`5QI`（例：シグナリング用の`5QI=5`、メディア用の`5QI=1`）や`ARP`といったQoSパラメータの活用は、キャリアグレードの音声品質を保証する上で不可欠です。`PFCP`や`NGAP`といったプロトコルは、`SMF`、`UPF`、`gNB`間でQoSポリシーをユーザープレーンリソースに正確にマッピングするための重要な手段として機能します。

5G SAアーキテクチャは、VoNRサービスに優位性をもたらします。これは、通話設定時間の短縮、優れた音声品質、および中断のないサービス継続性として現れます。これらの利点は、従来のLTEにおけるVoLTEや回線交換音声と比較して顕著です。3GPP標準化団体が定める詳細な仕様に準拠することで、`UE`、`gNB`、`AMF`、`SMF`、`UPF`、`PCF`、`IMS`といった多様なネットワーク機能が調和して動作し、この複雑な相互作用を可能にしています。

この分析は、5G SAが単なる高速データ通信ネットワークに留まらず、リアルタイム通信に特化した高度なサービス基盤であることを示唆しています。将来的に、このような基盤は、ネットワークスライシングのさらなる進化と相まって、多様なQoS要件を持つ革新的なリアルタイムアプリケーションの展開を可能にするでしょう。

## 引用文献

1. [VoNR Call Flow - Voice over new Radio - TELCOMA Global](https://www.telcomaglobal.com/p/vonr-call-flow)
2. [Junos Multi-Access User Plane Overview - Juniper Networks](https://www.juniper.net/documentation/us/en/software/junos/multi-access-user-plane/topics/topic-map/cups-saegw-overview.html)
3. [Junos Multi-Access User Plane User Guide - Juniper Networks](https://www.juniper.net/documentation/us/en/software/junos/multi-access-user-plane/multi-access-user-plane.pdf)
4. [5G Step-By-Step VoNR Call Flow - 5G NR - telecomHall Forum](https://www.telecomhall.net/t/5g-step-by-step-vonr-call-flow/33824)
5. [5GS Connection Management states - Cafetele Telecom Training](https://cafetele.com/5gs-connection-management-states/)
6. [5GC - Nick vs Networking](https://nickvsnetworking.com/tag/5gc/)
7. [inside TS 23.502: 5GS Service Request procedures - Tech-invite](https://www.tech-invite.com/3m23/toc/tinv-3gpp-23-502_e.html)
8. [3GPP TS 23.502](https://www.3gpp.org/ftp/tsg_sa/wg2_arch/TSGS2_144E_Electronic/INBOX/DRAFTS/draft%20S2-2102512r02.doc)
9. [Radio Resource Control - Wikipedia](https://en.wikipedia.org/wiki/Radio_Resource_Control)
10. [38.331 RRC - NR Explained](https://www.nrexplained.com/rrc/ge0)
11. [Service Setup - 5G | ShareTechnote](https://www.sharetechnote.com/html/5G/5G_ServiceSetup.html)
12. [NAS : Security Header - 4G | ShareTechnote](https://www.sharetechnote.com/html/Handbook_LTE_SecurityHeader.html)
13. [NGAP/NAS Server - Black Duck](https://www.blackduck.com/fuzz-testing/defensics/protocols/ngap-server.html)
14. [C1-206482.docx - 3GPP](https://www.3gpp.org/ftp/tsg_ct/WG1_mm-cc-sm_ex-CN1/TSGC1_126e/Inbox/Drafts/C1-206482.docx)
15. [Rev01_C1-214343_MISC02_SMC_correction.docx - 3GPP](https://www.3gpp.org/ftp/tsg_ct/WG1_mm-cc-sm_ex-CN1/TSGC1_131e/Inbox/drafts/Rev01_C1-214343_MISC02_SMC_correction.docx)
16. [inside TS 33.501: Content Part, 16 out of 67 - Tech-invite](https://www.tech-invite.com/3m33/toc/tinv-3gpp-33-501_p.html)
17. [inside TS 24.501: Content Part, 20 out of 77 - Tech-invite](https://www.tech-invite.com/3m24/toc/tinv-3gpp-24-501_t.html)
18. [draft_S3-210415-r1 CR 33.501 AMF key derivation function v2.docx - 3GPP](https://www.3gpp.org/ftp/tsg_sa/WG3_Security/TSGS3_102e/Inbox/Drafts/draft_S3-210415-r1%20CR%2033.501%20AMF%20key%20derivation%20function%20v2.docx)
19. [inside TS 33.501: Content Part, 10 out of 67 - Tech-invite](https://www.tech-invite.com/3m33/toc/tinv-3gpp-33-501_j.html)
20. [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)
21. [inside TS 33.501: Content Part, 44 out of 67 - Tech-invite](https://www.tech-invite.com/3m33/toc/tinv-3gpp-33-501_zr.html)
22. [TS 33.501 (1Q25/342 p.) – 5GS Security Architecture and Procedures](https://www.tech-invite.com/3m33/tinv-3gpp-33-501.html)
23. [RFC 9048 - Improved Extensible Authentication Protocol Method for 3GPP Mobile Network Authentication and Key Agreement (EAP-AKA') - IETF Datatracker](https://datatracker.ietf.org/doc/html/rfc9048)
24. [5G_ciphered_NAS_decipher_tool/README.md at master - GitHub](https://github.com/jimtangshfx/5G_ciphered_NAS_decipher_tool/blob/master/README.md)
25. [RFC 9048: Improved Extensible Authentication Protocol Method for 3GPP Mobile Network Authentication and Key Agreement (EAP-AKA') - » RFC Editor](https://www.rfc-editor.org/rfc/rfc9048.html)
26. [inside TS 23.502: 5GS PDU Session Modification procedures - Tech-invite](https://www.tech-invite.com/3m23/toc/tinv-3gpp-23-502_p.html)
27. [Service: nsmf-pdusession](https://dstest.info/RestDict/Dictionary/nsmf-pdusession.html)
28. [inside TS 23.501: Standardized 5QI to QoS characteristics mapping - Tech-invite](https://www.tech-invite.com/3m23/toc/tinv-3gpp-23-501_zc.html)
29. [3GPP TS 23.287](https://www.3gpp.org/ftp/Email_Discussions/SA2/5G_AIS/QC%20S2-210xxxx%205G_AIS%205QIs%202%20CR%2023501_v2.doc)
30. [5QI - 5G | ShareTechnote](https://www.sharetechnote.com/html/5G/5G_5QI.html)
31. [inside TS 23.501: 5GS QoS Model - Tech-invite](https://www.tech-invite.com/3m23/toc/tinv-3gpp-23-501_z.html)
32. [5.7 QoS model - TechSpec](https://itecspec.com/spec/3gpp-23-501-5-7-qos-model/)
33. [inside TS 23.501: 5G QoS Parameters - Tech-invite](https://www.tech-invite.com/3m23/toc/tinv-3gpp-23-501_za.html)
34. [5G NR QoS Parameters - Techplayon](https://www.techplayon.com/5g-nr-qos-parameters/)
35. [Fixed wireless access sessions - Nokia Documentation Center](https://documentation.nokia.com/mag-c/25-3/books/cpf/fixed-wireless-access-sessions.html)
36. [C3-214045_r1.docx - 3GPP](ftp://www.3gpp.org/tsg_ct/WG3_interworking_ex-CN3/TSGC3_117e/Inbox/Draft/PCC/TEI17_DCAMP/C3-214045_r1.docx)
37. [C3-251465_was_1097.docx - 3GPP](https://www.3gpp.org/ftp/Meetings_3GPP_SYNC/CT3/Inbox/Drafts/TEI19_SliceSel/C3-251465_was_1097.docx)
38. [revision of C3-211233 29.513r16 URLLC QoS monitoring procedure_r1.docx - 3GPP](https://www.3gpp.org/ftp/tsg_ct/WG3_interworking_ex-CN3/TSGC3_114e/Inbox/Draft/PCC/en5GPccSer/revision%20of%20C3-211233%2029.513r16%20URLLC%20QoS%20monitoring%20procedure_r1.docx)
39. [revision of C3-201152 QoS parameter mapping at SMF update for V2X_V1.docx - 3GPP](ftp://www.3gpp.org/tsg_ct/WG3_interworking_ex-CN3/TSGC3_108e/Inbox/Drafts/PCC/eV2XARC/revision%20of%20C3-201152%20QoS%20parameter%20mapping%20at%20SMF%20update%20for%20V2X_V1.docx)
40. [PFCP protocol - Nokia Documentation Center](https://documentation.nokia.com/mag-c/25-3/books/pfcp/pfcp-protocol.html)
41. [General session functionality - Nokia Documentation Center](https://documentation.nokia.com/mag-c/23-10-1/books/cpf/general-functionality.html)
42. [7.5.4 PFCP Session Modification Request – TechSpec](https://itecspec.com/spec/3gpp-29-244-7-5-4-pfcp-session-modification-request/)
43. [PFCP session-related messages - Nokia Documentation Center](https://documentation.nokia.com/mag-c/24-3/books/pfcp/pfcp-session-related-messages.html)
44. [C4-204152_V1_5G_CIoT 29.244-Rate Control.docx - 3GPP](https://www.3gpp.org/ftp/tsg_ct/WG4_protocollars_ex-CN4/TSGCT4_99e_meeting/Inbox/Drafts/7.2.4/C4-204152_V1_5G_CIoT%2029.244-Rate%20Control.docx)
45. [Create-QER IE ( 7 ) - PFCP Dictionary](https://dstest.info/PfcpDict/Dictionary/Create-QER.html)
46. [3GPP TS 38.413 | PDF | 3 Gpp | Computer Standards - Scribd](https://www.scribd.com/document/696368502/38413-h60)
47. [inside TS 38.413: Content Part, 5 out of 16 - Tech-invite](https://www.tech-invite.com/3m38/toc/tinv-3gpp-38-413_e.html)
48. [3GPP Change Request](https://www.3gpp.org/ftp/tsg_ran/WG3_Iu/TSGR3_109-e/Inbox/Drafts/CB%20%23%2075_NAS_PDUcorrection/draft_R3-205672_naspdumodify413r16.doc)
49. [R3-253834 XR 38413 TP_V1_CTC_Eri.docx - 3GPP](https://www.3gpp.org/ftp/Meetings_3GPP_SYNC/RAN3/Inbox/drafts/CB%20%23%20R19XR/Encoding%20of%20Available%20bitrate-Threshold-MMSID/R3-253834%20XR%2038413%20TP_V1_CTC_Eri.docx)
50. [draft R3-252371 38413_CTC.docx - 3GPP](https://www.3gpp.org/ftp/tsg_ran/WG3_Iu/TSGR3_127-bis/Inbox/Drafts/CB%20%23%20XR/exposure%20of%20available%20data%20rate/draft%20R3-252371%2038413_CTC.docx)
51. [3GPP Change Request](https://www.3gpp.org/ftp/tsg_ran/WG3_Iu/TSGR3_109-e/Inbox/Drafts/CB%20%23%2075_NAS_PDUcorrection/draft_R3-205671_naspdumodify413r15.doc)