目次

1. エグゼクティブサマリー
2. 音声サービスのための5Gスタンドアローン（SA）アーキテクチャの概要
3. UEトリガーによるサービス要求手順（CM-IDLEからCM-CONNECTEDへ）
- 3.1. RRC接続確立
- 3.2. NASサービス要求メッセージとセキュリティ
4. 音声のためのIMS PDUセッション変更（専用QoSフロー設定）
5. IMSシグナリングおよびRTPメディアパス確立
6. メッセージシーケンスチャート
- 6.1. シーケンス図の詳細説明と推測
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. メッセージシーケンスチャート

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要件を持つ革新的なリアルタイムアプリケーションの展開を可能にするでしょう。

引用文献