UCC 5G cnSGWc 構成および管理ガイド、リリース 2025.01

機能の概要と変更履歴

要約データ

表 1. 要約データ
該当製品または機能エリア	cnSGW-C
該当するプラットフォーム	SMI
機能のデフォルト設定	GTPC-EP から SGW サービスへの非同期 BG IPC：有効：常時オンバッチ ID の割り当て、リリース、調整のサポート：無効：有効にするには設定が必要ですキャッシュポッドの最適化 CDL フラッシュ間隔およびセッション有効期限のチューニング設定：有効：無効にするには設定が必要です DDN コールフローの最適化：無効：有効にするには設定が必要です DDN タイムアウトの設定：無効：有効にするには設定が必要ですエッジエコーの実装：有効：常時オン ETCD ピア最適化のサポート：有効：常時オン DB データベース更新へのフラグの設定：有効：常時オン GTPC インターフェイス分割：無効：有効にするには設定が必要です GTPC IPC クロスラックのサポート：無効：有効にするには設定が必要ですサービス間ポッド通信：無効：有効にするには設定が必要ですメンテナンスモード：無効：有効にするには設定が必要です MBR コールフローの最適化：無効：有効にするには設定が必要です最適化された GTPv2 エンコーダおよびデコーダ：有効：常時オンアイドルアクティブコールフローの部分的な CDL 更新：有効：常時オン DLDR スロットリングのサポートを含む PFCP セッションレポート：無効：有効にするには設定が必要です復元力の処理：無効：有効にするには設定が必要ですローミングピアパス管理の最適化：無効：有効にするには設定が必要です UDP プロキシ機能のプロトコルマイクロサービスへのマージ：有効：無効にするには設定が必要です
関連資料	該当なし

マニュアルの変更履歴

表 2. マニュアルの変更履歴
改訂の詳細	リリース
次のサブ機能のサポートが導入されました。キャッシュポッドの最適化のサポートが追加されました。 DLDR スロットリングのサポートを含む PFCP セッションレポート復元力処理	2023.01.0
次のサブ機能のサポートが導入されました。バッチ ID の割り当て、リリース、および調整 CDL フラッシュ間隔およびセッション有効期限のチューニング設定 DDN コールフロー最適化 DDN タイムアウト設定エッジエコーの実装 ETCD ピア最適化サポート DB データベース更新にフラグを設定する GR 分割 GTPC インターフェイス分割 GTPC IPC クロスラックサポートサービス間ポッド通信 IPv6 のサポートが導入されました。メンテナンスモードベアラー変更要求および応答（MBR）コールフローの最適化追加の要求および応答メッセージ用に、最適化された GTPv2 エンコーダおよびデコーダが提供されています。 UDP プロキシと GTPC-EP のマージ UDP プロキシと PFCP-EP のマージ	2022.04.0
最初の導入。	2021.02.3

機能説明

この章では、パフォーマンス最適化機能について説明します。

一部のパフォーマンス最適化機能は、cnSGW-C と SMF に共通です。

SMF 機能の詳細については、UCC 5G SMF 設定および管理ガイド [英語] を参照してください。

GTPC-EP から SGW サービスへの非同期 BG-IPC

機能説明

cnSGW-C は、GTPC-EP ポッドのリソースの消費を抑えることで、GTPC-EP から cnSGW-C への非同期 BG-IPC コールをサポートします。

非同期 BG-IPC コールの場合、GTPC-EP ポッドは次を使用します。

要求メッセージを SGW サービスに送信するための、app-infra の SendRequestWithCallbackAsResponseWithRequestId API。
SGW サービスから応答を受信するための GetIPCRequestCallbackResponseWithRequestId API。

バッチ ID の割り当て、リリース、および調整のサポート

機能説明

nodemgr は、接続状態にあるサブスクライバに一意の ID を割り当てます。サブスクライバが接続解除されると、一意の ID が nodemgr に解放されます。割り当て手順と割り当て解除手順が増えると、nodemgr のパフォーマンスが影響を受け、sgw-service はこれらの手順を完了するために長時間待機し続けます。

バッチ ID の割り当て、リリース、および調整サポート機能は、sgw-service と nodemgr 間のインタラクションを削減し、nodemgr のパフォーマンスを最適化するメカニズムを提供します。

機能の仕組み

ここでは、この機能の仕組みを説明します。

バッチ IDの割り当て：

バッチ ID の割り当てには、次の手順が含まれます。

sgw-service では、フリー ID をサブスクライバに割り当てることで ID ストアが管理されます。ID がストアで利用できない場合、sgw-service は Batch ID Allocation Request を nodemgr に送信します。
nodemgr は応答で、ID Reserve Report Interval で 128 の ID を一括で返します。sgw-service は、nodemgr から受信した ID で ID ストアを更新し、ID Reserve Report Interval のタイマーを開始します。
ID Reserve Report Interval で設定された期間の前にすべての ID が使用されている場合、sgw-service は、以前の要求からすべての ID を予約する通知とともに、ID Allocation Request を一括で nodemgr に送信します。
sgw-service がすべての ID を割り当てる前に ID Reserve Report Interval タイマーが期限切れになった場合、sgw-service は Reserve Report Batch 操作を介して未使用の ID を nodemgr に返します。

バッチ ID のリリース：

バッチ ID のリリースには、次の手順が含まれます。

sgw-service は、ID ストアが各 nodemgr に対して解放する ID を管理します。
sgw-service は、ID の割り当てが解除されるたびに ID を ID ストアに返します。ID ストアがいっぱいの場合、sgw-service は Batch ID Release Request とリリースされた ID をそれぞれの nodemgr に送信します。
sgw-service が ID ストアへの ID の追加を開始すると、ID リリースタイマーが開始します。
バッチ ID がリリースされる前、またはバッチがいっぱいになる前に ID リリースタイマーが期限切れになった場合、sgw-service はリリースされた ID を nodemgr に送信します。

バッチ ID の調整

バッチ ID の調整は、サービスポッドと nodemgr ポッドの再起動時に発生します。

サービスポッドの再起動時：

サービスポッドがバッチ ID を受信し、ID を割り当てる前に応答しなくなった場合、nodemgr は Batch ID Reserve Request を取得できず、ID 予約手順がタイムアウトします。このようなシナリオでは、nodemgr は予約されていないか、割り当てられていない ID を CDL と調整します。サブスクライバに割り当てられていない ID は ID ストアに解放されます。
サービスポッドは、解放された ID を収集し、無応答になった場合 ID は nodemgr に解放します。このシナリオでは、ID はドロップされます。

nodemgr ポッドの再起動時：

実行中の Batch ID Reserve Request と Batch ID Release Request に存在する ID はドロップされます。
nodemgr は、割り当てられた ID をバッチで cachemgr に通知します。ID を cachemgr に通知する前に nodemgr が応答しなくなった場合、nodemgr は再起動後に新しい ID の割り当てを開始します。nodemgr は、最後に割り当てられた ID とバッチサイズに基づいて ID を割り当てます。

機能設定

この機能を設定するには、次の構成を使用します。

config 
   sgw sgw_name 
      resmgr-batch-operation [ disable | enable ] 
      end

注：

resmgr-batch-operation [ disable | enable ] ：バッチ操作を構成します。デフォルトでは、resmgr-batch-operation は無効です。

OAM サポート

ここでは、この機能の操作、管理、およびメンテナンスサポートについて説明します。

バルク統計

バッチ ID の割り当ておよびリリースのサポート機能では、次の統計情報がサポートされています。

sgw_resource_mgmt_stats：cnSGW-C リソース管理統計情報の合計数をキャプチャします。

サンプルクエリ：

sgw_resource_mgmt_stats{app_name="smf",cluster="Local",data_center="DC",gr_instance_id="1", id_req_type="id_batch_alloc",instance_id="0",service_name="sgw-service",status="attempted"} 3 :sgw_resource_mgmt_stats{app_name="smf",cluster="Local",data_center="DC",gr_instance_id="1", id_req_type="id_batch_alloc",instance_id="0",service_name="sgw-service",status="success"} 3

sgw_resource_mgmt_stats{app_name="smf",cluster="Local",data_center="DC",gr_instance_id="1" ,id_req_type="id_batch_dealloc",instance_id="0",service_name="sgw-service",status="attempted"} 2 sgw_resource_mgmt_stats{app_name="smf",cluster="Local",data_center="DC",gr_instance_id="1",id_req_type= "id_batch_dealloc",instance_id="0",service_name="sgw-service",status="success"} 2

sgw_resource_mgmt_stats{app_name="smf",cluster="Local",data_center="DC",gr_instance_id="1", id_req_type="id_batch_dealloc_timeout",instance_id="0",service_name="sgw-service",status="attempted"} 1 :sgw_resource_mgmt_stats{app_name="smf",cluster="Local",data_center="DC",gr_instance_id="1",id_req_type ="id_batch_dealloc_timeout",instance_id="0",service_name="sgw-service",status="success"} 1

sgw_resource_mgmt_stats{app_name="smf",cluster="Local",data_center="DC",gr_instance_id="1", id_req_type="id_batch_release_timeout",instance_id="0",service_name="sgw-service",status="attempted"} 1 -:sgw_resource_mgmt_stats{app_name="smf",cluster="Local",d-ata_center="DC",gr_instance_id="1",id_req_type ="id_batch_release_timeout",instance_id="0",service_name="sgw-service",status="success"} 1

nodemgr_rmgr_batch_reconcile_stats：調整のために送信されるバッチの総数をキャプチャします。

サンプルクエリ：

nodemgr_rmgr_batch_reconcile_stats{app_name="smf",cluster="Local",data_center="DC",instance_id="0", service_name="nodemgr",status="success"} 1

nodemgr_resource_mgmt_resp_stats：調整のために解放された ID の合計数をキャプチャします。

サンプルクエリ：

nodemgr_resource_mgmt_resp_stats{app_name="smf",cluster="Local",data_center="DC",error="", gr_instance_id="0",instance_id="0",ip_ver_type="IP_TYPE_NONE",req_type="ID_REQ_REL_RECONCILE", service_name="nodemgr",status="success"} 16

バルク統計のサポートの詳細については、「UCC サービングゲートウェイコントロールプレーン機能メトリックリファレンス」を参照してください。

キャッシュポッドの最適化

機能説明

cnSGW-C は、GTPC エンドポイントでのキャッシュポッドクエリを削減するためのキャッシュポッドの最適化をサポートしています。

アフィニティの取得クエリは、GTPC エンドポイントへの発信要求または応答メッセージでアフィニティ情報を受信するために使用されます。この最適化により、GTPC エンドポイントポッドは、今後の要求メッセージのキャッシュポッドにクエリを送信しません。

このアフィニティ情報を受信するために、GTPC エンドポイントへの発信要求または応答メッセージでアフィニティクエリが使用されます。この最適化により、GTPC エンドポイントポッドは、今後の要求メッセージのキャッシュポッドにクエリを送信しません。

以前のリリースでは、cnSGW-C が DDN を送信し、MME から MBR を受信すると、GTPC エンドポイントはクエリをキャッシュポッドに送信してアフィニティ情報を取得する必要があり、その後、cnSGW-C がアフィニティ情報を使用して、MBR を正しいサービスポッドに転送できていました。

この最適化により、余分なキャッシュポッドクエリを防ぐことができます。

CDL フラッシュ間隔およびセッション有効期限のチューニング設定

機能説明

デフォルトのサービスポッドパラメータを変更して、スループットパフォーマンスを微調整し、負荷パフォーマンスを最適化できます。

機能設定

この機能を設定するには、次の構成を使用します。

config 
   profile sgw sgw_name 
      timers [ session-expiration-in-secs session_expiration | affinity-expiration-in-secs affinity_expiration | session-dbsync-interval-in-ms database_sync ] 
      end

注：

session-expiration-in-secs session_expiration ：セッションがサービスポッドにキャッシュされる期間を指定します。session_expiration は、1 ～ 600 ミリ秒の範囲の値を受け入れます。デフォルト値は 30 ミリ秒です。
affinity-expiration-in-secs affinity_expiration ：サービスポッドやその他のポッドでセッションアフィニティキーが有効である期間を指定します。affinity_expiration は、1 ～ 1200 秒の範囲の値を受け入れます。デフォルトは 80 秒です。
session-dbsync-interval-in-ms database_sync ：セッションがデータベースで同期されるまでの期間を指定します。database_sync は、1 ～ 10000 ミリ秒の値を受け入れます。デフォルトのタイムアウト値は 500 ミリ秒です。

設定例

次に、設定例を示します。

config
      profile sgw sgw1 [ timers session-expiration-in-secs 30 | affinity-expiration-in-secs 80 | timers session-dbsync-interval-in-ms 500 ]
      end

DDN コールフロー最適化

機能説明

Downlink Data Notification（DDN）コールフロー最適化機能を使用すると、指定した期間、DDN 手順の呼び出しを一時停止できます。この機能を使用すると、DDN を受信して UE がアクティブ状態に移行する前に、ネットワークが開始したサービスリクエスト手順がスケジュールされます。タイマーが期限切れになり、UE ID がアクティブであるか、または Modify Bearer Request が進行中の場合、cnSGW は DDN 手順を無視します。

機能の仕組み

ここでは、この機能の仕組みを説明します。

cnSGW-C が、次のシナリオで DDN 手順を呼び出します。

セッションがアイドル状態に急速に移行し、アップリンクとダウンリンクのデータが同時にトリガーされます。
サブスクライバがアイドル状態のときにダウンリンクデータを受信すると、cnSGW-C が DDN を MME に送信します。UE をページングし、UE 状態をアクティブに変更するよう DDN が MME に通知します。
サブスクライバがアイドル状態のときにアップリンクデータを受信すると、MME が Modify Bearer Request を SGW に送信し、UE 状態をアクティブに変更します。
SGW サービスは、開始した DNN で Modify Bearer Request を受信した場合、DDN 手順を中止し、Modify Bearer Request を処理して UE 状態をアクティブに変更します。

コールフロー

ここでは、この機能の主要なコールフローについて説明します。

現在の Downlink Data Notification 処理コールフロー

ここでは、現在の Downlink Data Notification 処理コールフローについて説明します。

表 3. 現在の Downlink Data Notification 処理コールフローの説明
ステップ	説明
1	UPF が DLDR または ERIR を含む Sx Session Report Request を UDP プロキシに送信します。
2	UDP プロキシが DLDR または ERIR を含む Sx Session Report Request を PFCP に送信します。
3	PFCP が DLDR または ERIR を含む Sx Session Report Request を SGW-SRV に送信します。
4	SGW-SRV が Downlink Data Notification（DDN）を GTP-S11 に送信します。
5	SGW-SRV が Sx Session Report Response を PFCP に送信します。
6	PFCP が Sx Session Report Response を UDP プロキシに送信します。
7	UDP プロキシが Sx Session Report Response を UPF に送信します。
8	GTP-S11 が DDN 通知を MME に送信します。
9	MME が UE のページングを開始し、DDN 確認応答を GTP-S11 に送信します。
10	GTP-S11 が DDN 確認応答を SGW-SRV に送信します。
11	ページングが失敗すると、MME が DDN Failure Indication を GTP-S11 に送信します。
12	GTP-S11 が DDN Failure Indication を SGW-SRV に送信します。

内部 DDN 遅延タイマーによる DNN 処理のコールフロー

このセクションでは、内部 DDN 遅延タイマーによる DNN 処理のコールフローについて説明します。

表 4. 内部 DDN 遅延タイマーによる DNN 処理のコールフローの説明
ステップ	説明
1	UPF が DLDR/ERIR を含む Sx Session Report Request を UDP-Proxy に送信します。
2	UDP プロキシが、DLDR/ERIR（BGIPC コール）を含む Sx セッションレポート要求をプロトコルに送信します。
3	プロトコルが、DLDR/ERIR を含む Sx セッションレポート要求を SGW-SRV に送信します。
4	SGW-SRV がプロトコルに Sx セッションレポート応答を送信します。
5	プロトコルが Sx セッションレポート要求を UDP プロキシに送信します。
6	UDP プロキシが、Sx セッションレポート要求を UPF に送信します。
7	SGW-SRV がダウンリンクデータ通知を GTP-S11 に送信します。
8	GTP-S11 がダウンリンクデータ通知を UDP プロキシに送信します。
9	UDP プロキシがダウンリンクデータ通知を MME に送信します。
10	MME が UE に対してページングを開始した後、MME はダウンリンクデータ通知の確認応答を UDP-Proxy に送信します。
11	UDP プロキシがダウンリンクデータ通知の確認応答を GTP-S11 に送信します。
12	GTP-S11 がダウンリンクデータ通知の確認応答を SGW-SRV に送信します。
13	MME がデータ PDN のベアラー変更要求を UDP プロキシに送信します。
14	UDP プロキシがデータ PDN のベアラー変更要求を GTP-S11 に送信します。
15	GTP-S11 がデータ PDN のベアラー変更要求を SGW-SRV に送信します。
16	SGW-SRV がデータ PDN のベアラー変更要求をプロトコルに送信します。
17	プロトコルと UPF が、データ PDN の Sx ベアラー変更要求を処理します。
18	プロトコルがデータ PDN の Sx 変更応答を SGW-SRV に送信します。
19	SGW-SRV がデータ PDN の Sx 変更応答を GTP-S11 に送信します。
20	GTP-S11 がデータ PDN の Sx 変更応答を UDP プロキシに送信します。
21	UDP プロキシがデータ PDN の Sx 変更応答を MME に送信します。

機能設定

この機能を設定するには、次の構成を使用します。

config 
   profile sgw sgw_name 
      ddn { delay-exclude-arplist number_priorities | delay-timer delay_duration } 
      end

注：

delay-exclude-arplist number_priorities ：DDN の遅延から除外する必要がある割り当ての優先順位レベルおよび保持の優先順位（1 〜 15）を指定します。number_priorities は最大 8 つのエントリを受け入れることができます。
delay-timer delay_duration ：DDN 手順が遅延する期間を指定します。delay_duration はミリ秒単位（0 ～ 5000）の期間を受け入れます。デフォルトの期間は 0 で、これはタイマーが無効であることを示します。

設定例

次に、設定例を示します。

config
    profile sgw sgw1
       ddn delay-timer 100 delay-exclude-arplist [ 3 4 ]
       end

OAM のサポート

ここでは、この機能の操作、管理、およびメンテナンスサポートについて説明します。

バルク統計

DDN コールフロー最適化機能では、次の統計情報がサポートされています。

sgw_tmr_stats：停止、開始、および期限切れ状態の内部 DDN 遅延タイマー。

クエリ：

sgw_tmr_stats{app_name="smf",cluster="Local",data_center="DC",gr_instance_id="1", instance_id="0",service_name="sgw-service",status="expired",timer_type="internal_ddn_delay"}
                                    1

sgw_tmr_stats{app_name="smf",cluster="Local",data_center="DC",gr_instance_id="1",instance_id="0", service_name="sgw-service",status="start",timer_type="internal_ddn_delay"}
                                    2

sgw_tmr_stats{app_name="smf",cluster="Local",data_center="DC",gr_instance_id="1",instance_id="0", service_name="sgw-service",status="stop",timer_type="internal_ddn_delay"}
                                    1

DDN タイムアウト設定

機能説明

cnSGW-C では、cnSGW-C Ops センターを介して DDN タイムアウトとピアの応答なしの構成を指定できます。

機能設定

この機能を設定するには、次の構成を使用します。

config 
   profile sgw sgw_name 
      ddn timeout-purge-session { true | false } 
      end

注：

ddn timeout-purge-session { true | false } ：MME が DDN 確認応答を送信しない場合にセッションを構成します。デフォルト値は false です。

Ops センターを使用したドメインベースのユーザー認可

機能説明

SMF と cnSGW-C は、Ops Center を使用したドメインベースのユーザー認証をサポートしています。ユーザー単位でアクセスを制御するには、Ops Center AAA で TACACS プロトコルを使用します。このプロトコルを使用すると、ルータまたは NAS へのアクセスを試みるユーザーを集中的に検証できます。

ルールリストで NETCONF アクセス制御（NACM）ルールを設定し、設定したルールを Ops Center の構成にマッピングして、グループを適切な運用許可にマッピングします。次の基準と製品に基づいた構成を使用します。

NACM ルールと SMF ドメインベースのグループを使用して、SMF ベースの構成にアクセスのみ、または更新を許可するように Ops Center を設定します。
NACM ルールと cSGW-C ドメインベースのグループを使用して、cSGW-C ベースの構成にアクセスのみ、または更新を許可するように Ops Center を設定します。
NACM ルールと cSGW-C ドメインベースのグループを使用して、CCG ベースの構成にアクセスのみ、または更新を許可するように Ops Center を設定します。

（注）

NSO サービスアカウントは、構成全体にアクセスできます。

機能の仕組み

Ops センターでこの機能設定をサポートするために、domain-based-services 設定が TACACS セキュリティ設定に追加されます。TACACS フローの変更は次のように機能します。

domain-based-services パラメータを設定している場合、TACACS プロセスに送信される設定済みのユーザー名は、ユーザー ID をユーザー ID とドメインに分割します。ドメインデリミタである分割文字は、domain-based-services で設定されます。これらの分割文字は「@」、「/」、または「\」であり、ドメインおよびユーザー ID 情報を取得するために次の形式で使用されます。
- @ — <user id>@<domain>
- / — <domain>/<user id>
- \ — <domain>\<user id>
TACACS は、既存のフローに従って認証および認可します。ただし、domain-based-services 機能が有効になっていて、TACACS がユーザーを認証および認可する場合、次のステップが TACACS フロー手順に追加されます。
- Network Services Orchestrator（NSO）が NSO サービスアカウントとしてログインすると、そのセッションは、domain-based-services nso-service-account group group-name で設定した特定の NACM グループを受け取ります。これは、機能的には NSO の動作と同じです。
- 指定したドメインがグループマッピングに存在する場合は、domain-based-services domain-service domain group group-name で設定した NACM グループが適用されます。
- ユーザーにドメインがない場合、またはドメインがドメインからグループへのマッピングに存在しない場合、domain-based-services no-domain group group-name で設定した no-domain NACM グループが適用されます。no-domain 設定が存在しない場合、ユーザー値は拒否されます。

この機能を有効にするには、次のオプションを指定して domain-based-services CLI コマンドを設定する必要があります。

NSO サービスアカウント
ドメインサービス
ドメインデリミタ
ドメインなし

機能設定

Ops センターを使用してドメインベースのユーザー認証を有効にするには、次の設定例を使用します。

config 
   tacacs-security domain-based-services [ domain-delimiter delimiter_option | domain-service domain_service_name [ group service_group_name  ] | no-domain group service_group_name | nso-service-account [ group service_group_name | id service_account_id ] ] 
   end

注：

domain-based-services [ domain-delimiter delimiter_option | domain-service domain_service_name [ group service_group_name ] | no-domain group service_group_name | nso-service-account [ group service_group_name | id service_account_id ] ] ：必要な domain-based-services 値を設定します。domain-based-services には次のオプションが含まれます。
- domain-delimiter ：ドメインの決定に使用するデリミタを指定します。このオプションは必須であり、次の値を使用できます。
  - @：domain-delimiter が「@」の場合、ユーザー値は <user> @<domain> 形式になります。
  - /：domain-delimiter が「/」の場合、ユーザー値は <domain>/<user> 形式になります。
  - \：domain-delimiter が「\」の場合、ユーザー値は <domain>\<user> 形式になります。
- domain-service ：ドメインおよびそのドメインのグループマッピングのリストを指定します。キーはドメインの名前で、グループはドメインに割り当てられたグループです。このリストの少なくとも 1 つのオプションを設定する必要があります。
- no-domain ：ドメインを持たないグループを指定します。またはドメインがドメインサービスマッピングで使用できない場合、このグループが受け入れ応答で送信されます。
- nso-service-account ：ID とグループを持つ NSO サービスアカウントを指定します。このパラメータを設定する場合は、ID フィールドとグループフィールドを設定する必要があります。ID とグループには文字列値が必要です。

設定例

次に、TACACS セキュリティモードでのドメインベースのユーザー認証の例を示します。

config
   tacacs-security domain-based-services nso-service-account id nsid
      tacacs-security domain-based-services nso-service-account group nso-group
   tacacs-security domain-based-services no-domain group read-operational
   tacacs-security domain-based-services domain-delimiter @
   tacacs-security domain-based-services domain-service etcd
      group etcd
exit
tacacs-security domain-based-services domain-service sgw
   group sgw_1
exit
tacacs-security domain-based-services domain-service smf
   group smf
exit

設定の確認

構成を確認するには、次の show コマンドを使用します。

show running-config tacacs-security

この show コマンドの出力には、TACACS セキュリティ内のドメインベースのサービスのすべての構成が表示されます。

[smf] smf# show running-config tacacs-security
tacacs-security service smf
tacacs-security server 1
address 209.165.200.234
key $8$+twbdL2ZCgmjVswgp7kFJp8+SMXDjQRTZgoPVa3oEwY=
exit
tacacs-security domain-based-services nso-service-account id nsid
tacacs-security domain-based-services nso-service-account group nso-group
tacacs-security domain-based-services no-domain group read-operational
tacacs-security domain-based-services domain-delimiter @
tacacs-security domain-based-services domain-service etcd 
group etcd
exit
tacacs-security domain-based-services domain-service sgw
group sgw_1
exit
tacacs-security domain-based-services domain-service smf
group smf
exit

エッジエコーの実装

機能説明

非マージモードでは、udp-proxy ポッドはエンドポイントとして機能し、gtpc-ep はピアノードからのエコー要求に応答します。

gtpc-ep は、システムが多数の入力 CEPS を受信した際にトラフィックを処理し、その結果として、gtpc-ep が udp-proxy からメッセージを取得する速度と、udp-proxy がメッセージを受け取る速度との間に不整合が生じます。

gtpc-ep がロードされると、udp-proxy と gtpc-ep の間のキューがいっぱいになり、udp-proxy の一部のメッセージがドロップされることがあります。これらがエコー要求メッセージである場合、エコー応答を受信していないため、ピアはパス障害を検出します。さらに、ピアは sgw サービスに送信されたすべてのセッションをクリアします。

機能の仕組み

ここでは、この機能の仕組みを説明します。

nodemgr は次の手順でエコー要求を処理します。

nodemgr には、各 GR インスタンス ID と GTPC ピアの自己再起動カウンタキャッシュが保持されます。
UDP プロキシポッドがピアからエコー要求を受信し、自己再起動カウンタ値が自己再起動カウンタキャッシュで利用できない場合、UDP プロキシポッドがエコー要求を GTPC-EP に転送します。
GTPC-EP が UDP プロキシメッセージメタデータの一部としてエコー応答で自己再起動カウンタを送信します。UDP プロキシが自己再起動カウンタを自己再起動カウンタキャッシュに保存します。UDP プロキシは、ピアからエコー要求を受信し、自己再起動カウンタ値が自己再起動カウンタキャッシュで利用可能な場合、再起動カウンタとともにエコー応答を送信します。
UDP プロキシがエコー要求メッセージを GTPC-EP に転送します。GTPC-EP がエコー要求を処理し、必要に応じて nodemgr に転送します。
ピア再起動カウンタ値が変更されると、nodemgr はパス障害を検出します。
エコー応答では、GTPC-EP が UDP プロキシメッセージメタデータの自己再起動カウンタをUDP プロキシに送信します。自己再起動カウンタが自己再起動カウンタキャッシュに保存されているカウンタとは異なる場合、UDP プロキシはキャッシュ内の自己再起動カウンタを更新し、GTPC-EP から受信したエコー応答をドロップします。

（注）

GTPC-EP がマージモードで開始された場合、エッジエコー機能はサポートされません。

Heartbeat

GTPV2 インターフェイスのエコー要求メッセージとエコー応答メッセージを処理するために、GTPC-EP と UDP プロキシポッドの間にハートビートキューが実装されます。ハートビートキューは、PFCP インターフェイスのプロトコルと UDP プロキシポッド間のハートビート要求およびハートビート応答メッセージに関与します。

OAM サポート

ここでは、この機能の操作、管理、およびメンテナンスサポートに関して説明します。

バルク統計サポート

エッジエコー実装機能では、次の統計情報がサポートされています。

ハートビートキューステータス：

sum(irate(ipc_response_total{rpc_name~=".ipc_stream_hb."}[10s])) by (service_name, instance_id, status, status_code, rpc_name, dest_host)

EdgeEcho メッセージを確認します。

sum(irate(udp_proxy_msg_total{ message_name ="edge_echo"}[30s])) by (message_name, message_direction, status)

ハートビートキューおよび EdgeEcho メッセージを有効にするには、以下を使用して udp_proxy_msg_total のトレースレベル統計を構成します。

infra metrics verbose application 
   metrics udp_proxy_msg_total level trace 
   exit

（注）

ハートビートおよび EdgeEcho 統計を有効にすると、udp-proxy ポッドのパフォーマンスが低下する可能性があります。

ETCD ピア最適化サポート

機能説明

多数の GTPC ピアが SMF または cnSGW-C に接続されている場合、ETCD のパフォーマンスに影響が出ます。各ピアは ETCD のレコードと見なされ、タイムスタンプはピア単位で 30 秒ごとに更新されるため、ETCD が継続的に更新され、システム全体のパフォーマンスに影響を与える大量のトラフィックが生成されます。

ETCD ピア最適化機能は、ピア管理の最適化を促進し、ETCD に対するパフォーマンスの影響の軽減を可能にします。

機能の仕組み

ここでは、この機能の仕組みを説明します。

各ピアを ETCD レコードエントリと見なさず、各ピアの IP アドレスのハッシュ値に基づいて、複数のピアをピアグループとしてグループ化します。これにより、ETCD のエントリの数が減少します。デフォルトでは、最大 200 のピアグループを作成できます。ピアグループ内のピアに関連する変更が行われた場合：

新しいピアの場合、ピアグループは ETCD ですぐに保持されます。
既存のピアのタイムスタンプが変更された場合、ピアグループは 3 秒ごとに 1 回更新されます。この更新により、次の影響があります。
- 各ピアグループ内でタイムスタンプが変更された多数のピアに対して、累積的なグループアップデートが行われます。
- ETCD の頻繁な更新が減少します。

最適化された GTPv2 エンコーダおよびデコーダ

機能説明

cnSGW-C は、次に対して、最適化された GTPv2 エンコーダおよびデコーダを提供します。

Modify Bearer Request メッセージを受信後にサブスクライバがアクティブ状態に移行している場合の Modify Bearer Request および Response メッセージ。
Release Access Bearer Request メッセージの受信時に、サブスクライバが IDLE 状態に移行している場合の Release Access Bearer Request および Response メッセージ。

最適化された GTPv2 エンコーダおよびデコーダは、次のメッセージに対して提供されます。

ベアラーリソースコマンド
Change Notification Request と Response
Create Bearer Request および Response
Create IDFT Request と Response
Create Session Request と Response
ベアラー削除コマンド
Delete Bearer Failure Indication
Delete Bearer Request および Response
Delete IDFT Request と Response
Delete Session Request と Response
Downlink Data Notification Acknowledgment
Downlink Data Notification Failure Indication
Download Datalink Notification Request
エコー要求およびエコー応答
Modify Bearer Request および Response
ベアラー変更コマンド
Modify Bearer Failure Indication
Update Bearer Request および Response

機能設定

S11、S5、および S5e インターフェイスでこの機能を構成するには、次の構成を使用します。

config 
   instance instance-id instance_id 
      endpoint gtp  
         replicas replica_count 
         vip-ip ipv4_address  vip-port ipv4_port_number 
         vip-ipv6 ipv6_address  vip-ipv6-port ipv6_port_number  
         dual-stack-transport { true | false }  
         enable-go-encdec { true | false } 
         interface interface_name 
            enable-go-encdec { true | false } 
            end

注：

enable-go-encdec { true | false } ：インターフェイスの Go 言語ベースの GTPv2 エンコーダおよびデコーダを有効にします。
dual-stack-transport { true | false } ：IPv6 または IPv4 アドレスを指定できるデュアルスタック機能を有効にします。この機能を有効にするには、true を指定します。

設定例

次に、設定例を示します。

config
    instance instance-id 1
       endpoint gtp
          replica 2
          vip-ip 209.165.200.224 vip-port 2022
          vip-ipv6 ipv6_address 2001:db8:1::2 22
          dual-stack-transport true
          enable-go-encdec false
          exit
       interface s5e
          replica 3
          vip-ip 209.165.200.225 vip-port 2022
          vip-ipv6 ipv6_address 2001:db8:1::3 22
          dual-stack-transport true 
          enable-go-encdec true
          exit
       interface s11
          replica 3
          vip-ip 209.165.200.226 vip-port 2022
          vip-ipv6 ipv6_address 2001:db8:1::4 22
          dual-stack-transport true 
          enable-go-encdec true
          exit
       interface s5
          replica 3
          vip-ip 209.165.200.227 vip-port 2022
          vip-ipv6 ipv6_address 2001:db8:1::5 22
          dual-stack-transport true 
          enable-go-encdec true
          end

OAM サポート

ここでは、この機能の操作、管理、およびメンテナンスサポートについて説明します。

バルク統計サポート

最適化された GTPv2 エンコーダおよびデコーダ機能では、次の統計情報がサポートされています。

Go ベースのエンコーダデコーダの Grafana クエリ：

クエリ：

sum(irate(gtpc_golang_enc_dec_stats{namespace="$namespace"}[60s])) by (gtpc_msg_type, gtpc_msg_operation, gtpc_msg_status)

凡例：

{{gtpc_msg_type}}-{{gtpc_msg_operation}}-{{gtpc_msg_status}}

GR スプリットを使用した GTPC エンドポイント

機能説明

GR スプリット機能により、スケーリングされた GTP トラフィックの処理が可能になり、CPU の最適な使用が促進されます。GR スプリット機能は、GTPC-EP の複数のアクティブインスタンスを起動し、GR インスタンスに基づいてトラフィックの分割を実行します。これは、UDP プロキシバイパス機能を支援する上で役立ちます。

機能の仕組み

ここでは、この機能の仕組みを説明します。

UDP プロキシマージモードがこの機能の前提条件です。

正常時のシナリオの場合、RACK1（GTPC-EP Active Instance-1）と RACK2（GTPC-EP Active Instance-2）は、GR-Instance-1 と GR Instance-2 からのトラフィックをそれぞれ処理します。
障害時のシナリオでは、GR インスタンス-1（S11、S5E、S5）および GR インスタンス-2（S11、S5E、S5）のトラフィックが 2 つの GTPC-EP インスタンス間で分割されます。

障害時のシナリオでは、RACK2 がダウンしていると仮定すると、RACK1 は GR Instance-1 と GR Instance-2 のすべてのトラフィックを処理します。GR スプリットの実装では、GTPC-EP Active Instance-1 は GR Instance-1 のすべてのインターフェイスの GTP トラフィックを処理し、GTPC-EP Active Instance-2 は GR Instance-2 のすべての GTP トラフィックを処理します。

S11 と S5 による GTPC エンドポイントインターフェイス分割

機能説明

GTPC インターフェイス分割機能を使用すると、インターフェイスに基づいて GTPC エンドポイントを分割できます。cnSGW-C は、GTPC ポッドを 2 つのインターフェイスである S11 と S5 に分割します。これにより、S11（SGW-Ingress）、S5E（SGW-Egress）、および S5（SMF-Ingress）のすべての GTPC 着信および発信トラフィックの処理が可能になります。

機能の仕組み

ここでは、この機能の仕組みを説明します。

GR インスタンス分割モードまたは UDP プロキシマージモードであることがこの機能の前提条件です。

この機能はデフォルトで無効に設定されています。この機能を設定する際、S11 および S5 GTPC エンドポイントに個別の内部および外部 VIP アドレスを指定し、2 つの GTPC-EP ポッドを展開します。

機能を設定すると、cnSGW-C は、GTPC インターフェイスと GR インスタンス ID に基づいて、SMF サービス、SGW サービス、およびノードマネージャから GTPC ポッドに IPC コールを送信します。

次に、GTPC インターフェイス分割機能の推奨事項を示します。

CPU コア：
- S5 インターフェイス：6
- S11 インターフェイス：18
- UDP プロキシ：2
VIP 設定：S5 および S11 インターフェイス用の個別の内部および外部 VIP
ディスパッチャの構成は、アップグレード前の既存の構成と同じにする必要があります。

次の図は、GTPC インターフェイス分割ポッドのレイアウトを示しています。

機能設定

この機能を設定するには、次の設定を使用します。

config 
   instance instance-id instance_id  
      endpoint gtp 
      interface s11 
         standalone true 
         cpu max-process cpu_core_value 
         internal-vip internal_vip_address 
         vip-ip ipv4_address vip-port ipv4_port_number 
         vip-ipv6 ipv6_address vip-ipv6-port ipv6_port_number 
         dual-stack-transport { true | false }  
         vip-interface vip_interface_value 
         exit 
      exit 
      interface s5 
         vip-ip ipv4_address vip-port ipv4_port_number 
         vip-ipv6 ipv6_address vip-ipv6-port ipv6_port_number 
         dual-stack-transport { true | false }  
         vip-interface vip_interface_value 
         end

注：

standalone true ：インターフェイス用の個別のポッドを使用してスタンドアロンモードで実行するようにインターフェイスを構成します。
cpu max-process cpu_core_value ：インターフェイスの CPU の CPU コア値を指定します。これにより、ポッドの GO_MAX_PROCS パラメータ値が設定されます。
dual-stack-transport { true | false } ：IPv6 または IPv4 アドレスを指定できるデュアルスタック機能を有効にします。この機能を有効にするには、true を指定します。

設定例

次に、設定例を示します。

config
   instance instance-id 1 
      endpoint gtp
      interface s11
         standalone true
         cpu max-process 18
         internal-vip 209.165.200.225
         vip-ip 209.165.200.226 vip-interface bd1.gtp.2131
         exit
      exit
      interface s5
      vip-ip 209.165.200.228 vip-interface bd1.gtp.2131
      end

GTPC IPC クロスラックサポート

機能説明

cnSGW-C と SMF を使用して GR セットアップアクティビティを実行する場合、次のシナリオのように、これら 2 つのラック間で GTPC メッセージの処理を最適化できます。

cnSGW-C から SMF サービスポッドへの IPC メッセージのセットは、gtpc-ep ポッドを介して 2 回流れるため、メッセージのエンコードとデコードのオーバーヘッドにつながります。
GR ペア内で、cnSGW-C や SMF などのサービスポッドが対応するピア GTPC ノードにメッセージを直接ルーティングできれば、これらの IPC メッセージは 1 つ以上の処理ステップを回避できます。

（注）

cnSGW または SMF インターフェイスで GTPC IPC を有効にする設定を適用する前に、クラスタ同期を使用してラック間ルーティングネットワークを適用する必要があります。ラックサーバー間で新しいルーティング可能なネットワークをサポートするための BGP ルートを追加するには、より多くの設定が必要です。

次の図は、機能、コアセットアップアクティビティ、およびそれらの相互接続のサポートに必要な新しいネットワークレイアウトの設計を表しています。

次の手順は、2 つのラック間での GTPC メッセージ処理の最適化とクロスラックエンドポイントの展開のために実行されます。

IMS-1 Rack-1 の cnSGW-C は、IPC 要求を、クロスラック GTPI ネットワークを介してルータに渡す DATA-2 Rack-2 の PGW GTPC-EP に内部的にルーティングします。
ルータは、要求を gtpc-ep ポッドに転送するためのネクストホップとして GTPE ネットワークを使用します。
GTPI ネットワークと GTPE ネットワークは、展開のプロセス中にラックに追加される新しいネットワークです。
また、この機能には、アクティブな gtpc-ep ポッドで受信される内部 GTPC IPC メッセージが必要です。
このプロセスでは、cnSGW-C から SMF サービスポッドへの IPC メッセージが GTPC-EP ポッドを介して流れ、メッセージのエンコードとデコードの労力が 2 発生します。

GR ペア内で、これらのサービスポッド（cnSGW-C および SMF）が対応するピア GTPC ノードにメッセージを直接ルーティングできれば、このような IPC メッセージは余分な処理を 1 つ回避できます。

（注）

設定されたプロトコルノードは、S5 および S5e VIP グループが展開されているのと同じ VIP グループにある必要があります。

機能の仕組み

ここでは、この機能の仕組みを説明します。

SMF-Ops-Center では、IMS ラックおよびデータラックの各ラックに GTPC-EP Geo エンドポイントを設定できます。

SMF-Ops-Center CLI では、IMS ラックとデータラックの各ラックに GTPC-EP Geo エンドポイントを設定できます。

（注）

GTPC メッセージの最適化は、4 つのすべてのインスタンス、またはこれらのラック内の GTPC エンドポイントのインスタンスのサブセットに適用できます。SMF および cnSGW-C サービスポッドが IPC インターフェイスを介して GTPv2 メッセージをルーティングできる IP アドレスのリストを設定するために、新しい要素が GTPC エンドポイントの下に追加されます。

ラック間 GTPC IPC のアップグレードと有効化

ここでは、ラック間 GTPC IPC をアップグレードして有効にする方法について説明します。

cnSGW-C および SMF インターフェイスで GTPC IPC 最適化を設定、アップグレード、および有効にする前に、次の手順を実行する必要があります。

ラック間ルーティングは、ブランチのコアネットワークに適用する必要があります。
ラックサーバー全体で新しいルーティング可能なネットワークをサポートするための追加ルートが加わると、GTPC、cnSGW-C、SMF など、より多くの設定パラメータが有効になります。

（注）

設定に関するポイントは次のとおりです。

S5 出力 MBR 要求の SGW サービスポッドは、リスト内の PGWc および SMF IP への IPC メッセージに使用されます。
S5 CBR、UBR、および DBR 要求の SMF サービスポッドは、リスト内の cnSGW-C への IPC メッセージに使用されます。
IPC メッセージは、ピアノードでタイムアウトが発生するたびに、メッセージを再試行するためにそれぞれのインターフェイスで N3 または T3 設定を再利用します。

コールフロー

ここでは、この機能の主要なコールフローについて説明します。

ラック間 IPC コールフローを搭載した cnSGW-C GTPC 最適化

ここでは、ラック間 IPC による cnSGW-C GTPC 最適化コールフローについて説明します。

表 5. ラック間 IPC コールフローを搭載した cnSGW-C GTPC 最適化コールフローの説明

ステップ

説明

1

MME が S11 ベアラー変更要求を R1-GTPC-EP に送信します。

2

R1-GTPC-EP が S11 ベアラー変更要求を SGW サービスに送信します。

（注）

SGW サービスセクションでは、次の機能が実行されます。

サブスクライバセッションのロード。
宛先を S5 ピアまたは S8 ピアとして選択。

3

次に、Alt SGW PGWc フローの最適化されていないシナリオのサブステップを示します。

3a

SGW サービスは、S5 または S8 ベアラー変更要求を R1-GTPC-EP に送信します。

3b

R1-GTPC-EP が、S5 または S8 ベアラー変更要求を R2-GTPC-EP に送信します。

3c

R2-GTPC-EP が、S5 または S8 ベアラー変更要求を SMF サービスに送信します。

3d

SMF サービスが、S5 または S8 ベアラー変更応答を処理して R2-GTPC-EP に送信します。

3e

R2-GTPC-EP が、R1-GTPC-EP にベアラー変更応答を送信します。

3f

R1-GTPC-EP が、SGW サービスにベアラー変更応答を送信します。

4

または、PGWc ピアシナリオをリモートリストで使用できます。

次に、このシナリオのサブステップを示します。

4a

SGW サービスが IPC 要求を R2-GTPC-EP に送信します。

（注）

R2-GTPC-EP セクションで、次の機能が実行されます。

S5 または S8 ベアラー変更要求のカプセル化。
ラック間 UDP 接続経由の送信。

4b

R2-GTPC-EP が、S5 または S8 ベアラー変更要求を SMF サービスに送信します。

4c

SMF サービスが、S5 または S8 ベアラー変更応答を処理して R2-GTPC-EP に送信します。

4d

R2-GTPC-EP が IPC 応答を SGW サービスに送信します。

（注）

SGW サービスセクションでは、次の機能が実行されます。

S5 または S8 ベアラー変更応答のカプセル化。
ラック間 UDP 接続経由の送信。

5

SGW サービスが、R1-GTPC-EP にベアラー変更応答を送信します。

6

R1-GTPC-EP が、MME にベアラー変更応答を送信します。

ラック間 IPC による SMF および PGWc GTPC 最適化コールフロー

ここでは、ラック間 IPC による SMF および PGWc GTPC 最適化コールフローについて説明します。

図 7. ラック間 IPC による SMF および PGWc GTPC 最適化コールフロー

表 6. ラック間 IPC による SMF および PGWc GTPC 最適化コールフローの説明

ステップ

説明

1

次に、Alt SMF から SGW へのフローが最適化されていないシナリオのサブステップを示します。

（注）

SMF サービスセクションで、次の手順が実行されます。

ネットワーキングイベントのトリガー。
リゾルトベアラーの作成。

1a

SMF サービスが S5 または S8 Create Bearer Request を R1-GTPC-EP に送信します。

1b

R1-GTPC-EP が S5 または S8 Create Bearer Request を R2-GTPC-EP に送信します。

1c

R2-GTPC-EP が S5 または S8 Create Bearer Request を SGW サービスに送信します。

1d

SGW サービスが S11 Create Bearer Request を処理して R2-GTPC-EP に送信します。

1e

R2-GTPC-EP が S11 Create Bearer Request を MME に送信します。

1f

MME が S11 Create Bearer Response を処理して R2-GTPC-EP に送信します。

1g

R2-GTPC-EP が S11 Create Bearer Response を SGW サービスに送信します。

1h

SGW サービスが S5 または S8 Create Bearer Response を処理して R2-GTPC-EP に送信します。

1i

R2-GTPC-EP が S5 または S8 Create Bearer Response を R1-GTPC-EP に送信します。

1j

R1-GTPC-EP が S5 または S8 Create Bearer Response を SMF サービスに送信します。

2

SMF から SGW へのフロー最適化シナリオのサブステップは次のとおりです。

2a

SMF サービスが IPC 要求を R2-GTPC-EP に送信します。

（注）

R2-GTPC-EP セクションで、次の手順が実行されます。

S5 または S8 Create Bearer Request のカプセル化。
ラック間 UDP 接続経由の送信。

2b

R2-GTPC-EP が S5 または S8 Create Bearer Request を SGW サービスに送信します。

2c

SGW サービスが S11 Create Bearer Request を処理して R2-GTPC-EP に送信します。

2d

R2-GTPC-EP が S11 Create Bearer Request を MME に送信します。

2e

MME が S11 Create Bearer Response を処理して R2-GTPC-EP に送信します。

2f

R2-GTPC-EP が S11 Create Bearer Response を SGW サービスに送信します。

2g

SGW サービスが S5 または S8 Create Bearer Response を処理して R2-GTPC-EP に送信します。

（注）

R2-GTPC-EP セクションで、次の手順が実行されます。

S5 または S8 Create Bearer Request のカプセル化。
ラック間 UDP 接続経由の送信。

2時間

R2-GTPC-EP が IPC 応答を処理して SMF サービスに送信します。

機能設定

この機能を設定するには、次の設定を使用します。

config 
instance instance_id 1 
    endpoint endpoint_name 
        interface gtp-inter-rack gtp_inter_rack_name 
            vip-ip vip_ip_address vip-port vip_port_address vip-interface vip_interface_address 
            gtpc-ipc gtpc_ipc_name 
            gtp-peer-entry gtp_peer_entry_address port port_address remote-gtp-peer-list remote_gtp_peer_list_addresses 
            end

（注）

前述の新しい設定例の拡張シナリオは次のとおりです。

S5 出力 MBR 要求の cnSGW-C サービスポッドでは、前述のリストにある PGWc または SMF IP 宛ての IPC メッセージが使用されます。
同様に、S5 CBR、UBR、および DBR 要求の SMF サービスポッドでは、前述のリストにある cnSGW への IPC メッセージが使用されます。
ピアノードでタイムアウトがある場合、メッセージを再試行するためにそれぞれのインターフェイスの N3 または T3 設定が IPC メッセージで再利用されます。

注：

instance instance_id 1 ：インスタンス ID を指定します。
endpoint endpoint_name ：エンドポイント名を指定します。
gtp-inter-rack gtp_inter_rack_name ：インターフェイス名を指定します。選択する gtp-inter-rack 名を指定します。これは、クロスラックルーティング用に追加された新しいインターフェイスです。
vip-ip vip_ip_address vip-port vip_port_address vip-interface vip_interface_address ：GTP IPC エンドポイントサーバーの IP である、vip-ip GTP IPC エンドポイントサーバーのリスニングポートである、vip-port および GTP IPC エンドポイントサーバーインターフェイス VLAN である vip-interface のアドレスを指定します。
gtpc-ipc gtpc_ipc_name ：インターフェイス名を指定します。選択する gtp-ipc 名を指定します。
gtp-peer-entry gtp_peer_entry_address port port_address remote-gtp-peer-list remote_gtp_peer_list_addresses ：他のラックまたはインスタンス（複数行）に設定されたリモート GTP IPC ピア IP である、gtp-peer-entry リモート GTP IPC ピアポートである、port および remote-gtp-peer-list のリストのアドレスを指定します。これは、gtp-peer-entry に対応するラックまたはインスタンス上の S5 および S5e リモート GTP ピアエンドポイントのリストです。

設定例

次に、設定例を示します。

config
instance instance-id 1
 endpoint GTP
   interface gtp-inter-rack
     vip-ip 209.165.202.130 vip-port 9084 vip-interface bd2.gtpe.2101
     gtpc-ipc
     gtp-peer-entry 209.165.202.131 port 9084 remote-gtp-peer-list [ 209.165.202.140 209.165.202.141 ]
     end

OAM のサポート

ここでは、この機能の操作、管理、およびメンテナンスサポートについて説明します。

KPI のサポート

GTPC IPC クロスラックサポート機能では、次の統計情報がサポートされています。

KPI 名：udp_rpc_request_total

次の表に、udp_rpc_request_total KPI の詳細を示します。


説明	機能	ラベル名	有効な値
この KPI には、UDP クライアントエンドポイントリクエストメッセージの総数が表示されます。	機能の出力はラック間 RPC 要求の合計です。	MessageName	CBR、UBR、MBR などの gptv2 メッセージタイプ
		retry	再試行かどうか
		status	要求メッセージのステータス（成功または失敗）。
		status_code	0/1/2

KPI 名：udp_rpc_response_total

次の表に、udp_rpc_response_total KPI の詳細を示します。


説明	機能	ラベル名	有効な値
この KPI には、UDP クライアントエンドポイントの応答メッセージの総数が表示されます。	機能の出力は、ラック間 RPC 応答の合計です。	MessageName	CBR、UBR、MBR などの gptv2 メッセージタイプ
		status	応答メッセージのステータス（成功または失敗）。
		status_code	0/1/2

（注）

現在の実装では、サービスポッドに存在するため、クライアント側でのみ KPI がサポートされており、パフォーマンスに影響を与えることなく KPI を有効にできます。

サービス間ポッド通信

機能説明

サブスクライバ用に選択された IMS PDN SGW サービスと SMF サービスが同じクラスタおよび同じラック上にある場合、SGW サービスが SMF サービスにメッセージを送信すると、次のメッセージフローが発生します。

メッセージは、S5e gtpc-ep インターフェイスからネットワークインターフェイスに送信されます。
メッセージは、gtpc-ep から SMF サービスへの S5 インターフェイスに戻ります。

併置されているサブスクライバの場合、通信は SGW サービスと SMF サービスの間で行われます。このアプローチにより、gtpc-ep の処理負荷が軽減されます。

（注）

SGW サービスと SMF サービス間の直接通信は、モニタープロトコルとモニターサブスクライバのメッセージ転送ではサポートされていません。

機能の仕組み

ここでは、この機能の仕組みを説明します。

sgw-service は、次の要求を処理するために smf-service と通信します。

セッション作成要求
ベアラー変更要求
セッション削除要求

smf-service は、次の要求を処理するために sgw-service と通信します。

ベアラー作成要求
ベアラー更新要求
ベアラー削除要求

sgw-service は、gtpc-ep を介して SMF にベアラー変更コマンドおよびベアラー削除コマンドメッセージを送信します。ベアラー更新要求およびベアラー削除要求がトリガーされると、コマンドメッセージが gtpc-ep を介して sgw-service に送信されます。

コールフロー

ここでは、この機能の主要なコールフローについて説明します。

SGW サービスから SMF サービスへの構成コールフローを使用したコラプストコールアタッチ

このセクションでは、SGW サービスから SMF サービスへの構成コールフローを使用したコラプストコールアタッチについて説明します。

表 7. SGW サービスから SMF サービスへの構成コールフローを使用したコラプストコールアタッチの説明
ステップ	説明
1	MME がセッション作成要求を GTP-S11 に送信します。
2	GTP-S11 がセッション作成要求を SGW-SRV に送信します。
3	SGW-SRV が Sx セッション確立要求を PFCP に送信します。
4	PFCP が Sx セッション確立要求を cnSGWu/SMFu に送信します。
5	cnSGWu/SMFu が Sx セッション確立応答を PFCP に送信します。
6	PFCP が Sx セッション確立応答を SGW-SRV に送信します。
7	SGW-SRV がセッション作成応答を SMF に送信します。サービスショート回線は TRUE に設定されます。
8	SMF がセッション作成応答を SGW-SRV に送信します。
9	SGW-SRV がSx セッション変更要求を PFCP に送信します。
10	PFCP が Sx セッション変更要求を cnSGWu/SMFu に送信します。
11	cnSGWu/SMFu がSx セッション変更応答を PFCP に送信します。
12	PFCP が Sx セッション変更応答を SGW-SRV に送信します。
13	SGW-SRV がセッション作成応答を GTP-S11 に送信します。
14	GTP-S11 がセッション作成応答を MME に送信します。併置されたサブスクライバの場合、SGW-SRV は次を受信します。ベアラー要求を変更し、MME からセッション要求を削除すると、SGW-SRV はこれらのメッセージを SMF サービスに伝達します。 SMF からベアラー作成要求、ベアラー更新要求、およびベアラー削除要求を行うと、SGW-SRV はこれらの要求メッセージに対する応答メッセージを SMF サービスに伝達します。

OAM のサポート

ここでは、この機能の操作、管理、およびメンテナンスサポートについて説明します。

統計のサポート

SMF サービスに直接送信されるメッセージを確認するには、次に示すように sgw_service_stats クエリに svc_to_svc フィールドを追加します。

クエリ：sum(irate(sgw_service_stats(status=~"attempted")[30s]) by (sgw_procedure_type,status, interface, svc_to_svc)

凡例：{{interface}} -> {{sgw_procedure_type}} | {{svc_to_svc}} | {{status}}

MBR コールフロー最適化

機能説明

cnSGW-C は、Modify Bearer Request および Modify Bearer Response（MBR）コールフローの最適化をサポートし、I/O 操作の削減、トランザクションの待機時間の短縮、およびマルチ PDN シナリオでのパフォーマンスの向上を実現します。

機能の仕組み

ここでは、この機能の仕組みを説明します。

次の機能は、MBR コールフローの最適化について説明します。

I/O 操作を削減するために、cnSGW-C は、SGW サービスに対するすべてのベアラー変更要求を単一の GRPC コールに結合し、SGW サービスポッドからプロトコルポッドへの Sx 変更要求を単一の GRPC コールに結合します。
GTPC-EP でのトランザクション待機時間を短縮するために、cnSGW-C は、ベアラー変更要求の受信後、直ちに GTPC-EP からベアラー変更応答を送信します（最後の MBR を除く）。

GTPC-EP が、単一のベアラー変更リクエストリストメッセージにすべてのベアラー変更要求を組み合わせ、SGW サービスに送信します。
SGW-service は、すべてのベアラー変更応答を単一のベアラー応答の変更リストメッセージにまとめ、GTPC-EP に送信します。

SGW サービスは、UPF へのすべての Sx 変更要求を単一の Sx 変更要求リストメッセージに結合し、プロトコルポッドに送信します。プロトコルポッドは、個々の Sx 変更要求を UPF に送信します。
プロトコルポッドは UPF からのすべての Sx 変更応答を待ち、それらを単一の Sx 変更応答リストに結合して SGW サービスに送信します。
非マージモードでは、UDP プロキシはローカル TEID とリモート TEID キャッシュ情報を維持します。マージモードでは、GTPC-EP はローカル TEID とリモート TEID のキャッシュ情報を維持します。
GTPC-EP が受信したベアラー変更要求 TEID キャッシュエントリを見つけられない場合、ベアラー変更要求はすぐに SGW サービスに転送されます。

予想されるすべてのベアラー変更要求が MBR キャッシュの有効期限内に受信されない場合、受信されたベアラー変更要求のみが SGW サービスに送信されます。

コールフロー

ここでは、この機能の主要なコールフローについて説明します。

MME 間 HO を使用したアイドル-アクティブ移行のコールフロー

ここでは、eNodeB から gNodeB に移動するための MME 間ハンドオーバー（NSA MBR）を使用した現在のコールフローについて説明します。

表 8. MME 間 HO を使用したアイドル-アクティブ移行のコールフローの説明
ステップ	説明
1	MME が SGW サービスにアクセスベアラーのリリース（RAB）要求を送信します。
2	SGW サービスが IMS PDN の Sx 変更要求を UPF に送信します。
3	UPF が IMS PDN の Sx 変更応答を SGW サービスに送信します。
4	SGW サービスがデータ PDN の Sx 変更要求を UPF に送信します。
5	UPF がデータ PDN の Sx 変更応答を SGW サービスに送信します。
6	SGW サービスが MME にアクセスベアラーのリリース応答メッセージを送信します。
7	MME が IMS PDN のサービス要求 MBRequest を SGW サービスに送信します。
8	SGW サービスが IMS PDN の Sx 変更要求を UPF に送信します。
9	UPF が IMS PDN の Sx 変更応答を SGW サービスに送信します。
10	SGW サービスが、IMS PDN（サービスリクエスト MBR）の ULI Update MBRequest を PGW に送信します。
11	PGW が、IMS PDN（サービス要求 MBR）の ULI Update MBResponse を SGW サービスに送信します。
12	SGW サービスが IMS PDN の MBResponse を MME に送信します。
13	MME がデータ PDN のサービス要求 MBRequest を SGW サービスに送信します。
14	SGW サービスがデータ PDN の Sx 変更要求を UPF に送信します。
15	UPF がデータ PDN の Sx 変更応答を SGW サービスに送信します。
16	SGW サービスが、データ PDN（サービスリクエスト MBR）の ULI Update MBRequest を PGW に送信します。
17	PGW が、データ PDN（サービス要求 MBR）の ULI Update MBResponse を SGW サービスに送信します。
18	SGW サービスが、データ PDN の MBResponse を MME に送信します。
19	MME が、データ PDN のイントラ MME HO（NSA）MBRequest を SGW サービスに送信します。
20	SGW サービスがデータ PDN（NSA MBR）の Sx 変更要求を UPF に送信します。
21	UPF がデータ PDN（NSA MBR）の Sx 変更応答を SGW サービスに送信します。
22	SGW サービスがデータ PDN（NSA MBR）の ULI Update MBRequest を UPF に送信します。
23	UPF がデータ PDN の ULI Update MBResponse を SGW サービスに送信します。
24	SGW サービスがデータ PDN（NSA MBR）の MBResponse を MME に送信します。

MBR 最適化コールフロー

ここでは、アイドルからアクティブに移行するための MBR 最適化の高度なコールフローについて説明します。

表 9. MBR 最適化コールフローの説明
ステップ	説明
1	MME が Release Access Bearer（RAB）要求を UDP プロキシに送信します。
2	UDP プロキシが RAB 要求を GTP-S11 に転送します。
3	GTP-S11 が RAB 要求を SGW サービスに転送します。
4	SGW サービスがすべての PDN の Sx Modify List を PFCP に送信します。
5	SGW サービスが RAB 応答に応答します。
6	GTP-S11 が RAB 応答を UDP プロキシに送信します。
7	UDP プロキシが RAB 応答を MME に送信します。
8	PFCP が UPF との間で IMS APN の Sx Modify を送受信します。
9	PFCP が UPF との間でデータ APN の Sx Modify を送受信します。
10	PFCP が、すべての PDN の Sx Modify Request List を SGW サービスに送信します。
11	MME が IMS PDN のサービスリクエスト MBRequest を UDP プロキシに送信します。
12	UDP プロキシが、TEID キャッシュデータを含む IMS PDN のサービスリクエスト MBRequest を GTP-S11 に転送します。
13	GTP-S11 が IMS PDN の MBResponse を UDP プロキシに送信します。
14	UDP プロキシが IMS PDN の MBResponse を MME に転送します。
15	MME がデータ PDN のサービスリクエスト MBRequest を UDP プロキシに送信します。
16	UDP プロキシが、TEID キャッシュデータを含むデータ PDN のサービスリクエスト MBRequest を GTP-S11 に送信します。
17	GTP-S11 が、IMS およびデータ PDN の MBRequest List を SGW サービスに送信します。
18	SGW サービスが IMS およびデータ PDN の Sx Modify List を PFCP に送信します。
19	PFCP が UPF との間で IMS PDN の Sx Modify を送受信します。
20	PFCP が UPF との間でデータ PDN の Sx Modify を送受信します。
21	PFCP が IMS およびデータ PDN の Sx Modify Response List を SGW サービスに送信します。
22	SGW サービスが IMS およびデータ PDN（非同期通知）の ULI Update MBRequest List を GTP-S5 に送信します。
23	SGW サービスがデータ PDN の MBResponse List を GTP-S11 に送信します。
24	GTP-S11 がデータ PDN の MBResponse を UDP プロキシに送信します。
25	UDP プロキシがデータ PDN の MBResponse を MME に転送します。
26	GTP-S5 が PGW との間で IMS PDN の ULI Update MBRequest を送受信します。
27	GTP-S5 が PGW との間でデータ PDN の ULI Update MBRequest を送受信します。
28	SGW サービスが DDN 要求を GTP-S11 に送信します。
29	S-11 が DDN 要求を UDP プロキシに転送します。
30	UDP プロキシが DDN 要求を MME に転送します。
31	MME がサービスリクエスト MBRequest を UDP プロキシに送信します。
32	UDP プロキシが、TEID キャッシュデータを含むサービスリクエスト MBRequest を GTP-S11 に送信します。
33	GTP-S11 が IMS およびデータ PDN の MBResponse List を SGW サービスに送信します。
34	MME が IMS PDN のサービスリクエスト MBRequest を UDP プロキシに送信します。
35	UDP プロキシが、TEID キャッシュデータを含む IMS PDN のサービスリクエスト MBRequest を GTP-S11 に送信します。
36	GTP-S11 が IMS PDN の MBResponse を UDP プロキシに送信します。
37	UDP プロキシが IMS PDN の MBResponse を MME に送信します。
38	SGW サービスが DDN 要求を GTP-S11 に送信します。
39	GTP-S11 が DDN 要求を UDP プロキシに転送します。
40	UDP プロキシが内部 DDN 確認応答を GTP-S11 に送信します。
41	MME がデータ PDN のサービスリクエスト MBRequest を UDP プロキシに送信します。
42	MME が TEID キャッシュデータを含むデータ PDN のサービスリクエスト MBRequest を GTP-S11 に送信します。
43	GTP-S11 が、IMS およびデータ PDN の MBRequest List を SGW サービスに送信します。

機能設定

この機能を設定するには、次の設定例を使用します。

config 
   instance istance-id instance_id  
      endpoint endpoint_name 
         mbr-optimization [ enable { false | true } | mbr-cache-expiry mbr_cache | teid-cache-expiry teid_cache ] 
         exit 
      exit 
   exit

注：

mbr-optimization [ enable { false | true } | mbr-cache-expiry mbr_cache | teid-cache-expiry teid_cache ] ：MBR 最適化構成を指定します。
- enable { false | true } ：MBR 最適化を有効または無効にします。デフォルトで、ディセーブルになっています。
- mbr-cache-expiry mbr_cache ：MBR キャッシュの有効期限の間隔を 1 ミリ秒から 6 秒の整数で指定します（ミリ秒単位）。デフォルト：50 ミリ秒。
  
  mbr-cache-expiry の値は実行時に変更できることに注意してください。
- teid-cache-expiry teid_cache ：TEID キャッシュの有効期限の間隔を、1000 ミリ秒から 1 時間の整数で指定します（ミリ秒単位）。デフォルト：120000 ミリ秒。

設定例

次に、設定例を示します。

config
   instance instance-id 1 
      endpoint gtp
         mbr-optimization enable true mbr-cache-expiry 60 teid-cache-expiry 180000
         end

設定の確認

設定を確認するには、次のコマンドを実行します。

show running-config instance instance-id 1 endpoint gtp
instance instance-id 1
endpoint gtp
  replicas                1
  nodes                   1
  mbr-optimization
   enable            true
   teid-cache-expiry 180000
   mbr-cache-expiry  60
  exit
  enable-cpu-optimization true
  ……

OAM サポート

ここでは、MBR 最適化機能の操作、管理、およびメンテナンスサポートについて説明します。

バルク統計サポート

MBR 最適化機能では、次の統計情報がサポートされています。

SGW サービスは、GTPC-EP からのベアラー変更要求リストを処理するために service_request_list 手順タイプをサポートします。

クエリ：sum(rate(sgw_service_stats{namespace=~”$namespace”, interface=”interface_sgw_ingress”,sgw_procedure_type=”service_request_list”, status=”attempted”}[1m]))

判例： IDLE -> ACTIVE (List)

MBR 短絡統計は、SGW サービスに送信されたベアラー変更要求リストの統計情報をキャプチャするように強化されています。

クエリ：sum(irate(gtpc_msg_short_circuit_stats{namespace=~"$namespace"}[60s])) by (gtpc_msg_type, gtpc_short_circuit_category)

判例：{{gtpc_msg_type}}, {{gtpc_short_circuit_category}}

この機能では、次の統計がサポートされます。

RxModifyBearerReq、SendSCMBResp：GTPC-EP から送信された早期 MB 応答の数。
RxModifyBearerReq、SendMBReqListToSrv：SGW サービスに送信された MB 要求リストの数。
RxModifyBearerReq、SendMBReqToSrv：SGW サービスに送信された MB 要求の数。
RxModifyBearerReq、MBREventExpired：MBR キャッシュで期限切れになった MB 要求の数。

メンテナンスモード

機能説明

メンテナンスモード機能により、GR セットアップ内のクラスタは、サービスを中断することなく、インサービスアップグレード（ローリングアップグレード）を実行できます。メンテナンスモードは、対応するクラスタへのトラフィックのルーティングと連携して、ソースクラスタの役割を実行します。

機能の仕組み

メンテナンスモードフラグが true に設定されている場合、クラスタロールが変更され、ラックに対して GR がトリガーされます。スタンバイクラスタは、メンテナンスモードのクラスタの役割を引き継ぎます。この間、モニタリングスレッドはフラグのランタイム値をチェックし、メンテナンスモードフラグが true に設定されている場合は実行を一時停止します。デフォルトでは、新規インストールの場合、フラグは false に設定されます。

ソースクラスタとスタンバイクラスタ（ラック）の両方を同時にメンテナンスモードにすることができます。状態に関係なく、ラックサーバーのメンテナンスモードを有効にできます。

従属クラスタに対してメンテナンス手順を実行中の場合、システムをメンテナンスモードに移行させることができます。メンテナンス作業を開始する前に、geo maintenance mode フラグの値を true に設定してください。メンテナンスが完了したら、システムの正常性を確認後、フラグを false にリセットします。

メンテナンスモードフラグの設定方法については、メンテナンスモードの有効化または無効化を参照してください。

メンテナンスモードが有効になっている場合：

ポッドモニタリングやラックサーバーからの BFD リンクモニタリングなどの自動 GR スイッチオーバーはサポートされていません。
ラック（メンテナンスモードが有効の場合）からパートナーラックへの、CLI ベースの GR スイッチオーバーのみがサポートされます。
パートナーラックからメンテナンスモードが有効になっているラックに対する、CLI ベースを含む GR スイッチオーバーはサポートされていません。
両方のパートナーラックがメンテナンスモードの場合、GR スイッチオーバーはサポートされません。
すべてのモニタリングアクティビティが一時停止します。
従属クラスタは、ローカルの障害を検出してもフェールオーバーをトリガーできません。
レプリケーションアクティビティはクラスタで続行されます。
メンテナンスモードでは、サイトのインスタンスロールは暗黙的に変更されませんが、ロールの変更は geo switch-role role CLI コマンドを使用して可能です。

メンテナンス中のクラスタとの間で GR トリガーの送受信はサポートされていません。メンテナンス中のクラスタからは、CLI ベースのフェールオーバーのみがサポートされます。

制限事項

この機能には、本リリースにおいて次の制限があります。

メンテナンスモード機能は、マルチコンピューティング障害スイッチオーバーケースを上書きしません。ただし、パートナーラックもメンテナンスモードである場合は、マルチコンピューティング障害スイッチオーバーシナリオがサポートされます。

（注）

マルチコンピューティング障害は、ラック内の複数のサーバーに障害が発生し、その結果パートナーラックがトラフィックを処理する場合に行われるスイッチオーバーケースです。

メンテナンスモードの有効化または無効化

この機能を有効または無効にするには、次のコマンドを実行します。

geo maintenance mode { true | false }

注：

geo maintenance mode { true | false } ：メンテナンスモードを有効にするか無効にするかを指定します。メンテナンスモードを有効にするには、true を指定します。メンテナンスモードフラグが true に設定されている場合、クラスタロールが変更され、ラックに対して GR がトリガーされます。

メンテナンスモードの値は、etcd ファイルに保存されます。

メンテナンスモードの有効化または無効化の例

次に、コマンドの例を示します。

geo maintenance mode true

geo maintenance mode false

メンテナンスモードの状態の確認

メンテナンスモードの状態を確認するには、次の手順を実行します。

show geo maintenance mode
result "geo maintenance mode is disabled"

アイドル/アクティブの部分的な CDL 更新コールフロー

機能説明

cnSGW-C は、サブスクライバデータの部分的な CDL 更新をサポートしています。部分的な CDL 更新は、CDL ポッドのサブスクライバデータ処理に対する CPU 要件を抑えるのに役立ちます。

サブスクライバのアイドル状態からアクティブ状態への移行およびアクティブ状態からアイドル状態への移行ごとに、cnSGW-C は次のフィールドのみを更新します。

eNodeB FTEID
サブスクライバの状態
ベアラーの状態

機能の仕組み

ここでは、この機能の仕組みを説明します。

cnSGW-C は、Update Bearer 情報を CDL のフラグデータベースに保存します。

cnSGW-C は、サブスクライバが次のように移行すると部分的な CDL 更新を使用します。

Release Access Bearer Request の受信時にアクティブ状態からアイドル状態になる
Modify Bearer Request の受信時にアイドル状態からアクティブ状態になる

部分的な CDL 更新では、session-state-flag には cdl show sessions summary slice-name <n> CLI 出力の次の値が表示されます。

sgw_active：セッションがアクティブな場合
sgw_inactive：セッションがアイドルの場合

次に、アクティブセッションの出力例を示します。

cdl show sessions summary slice-name 1
message params: {session-summary cli session {0 100  0 [] 0 0 false 4096 [] []} 1}
session {
    primary-key 2#/#imsi-123456789012348
    unique-keys [ "2#/#16777229" ]
    non-unique-keys [ "2#/#id-index:1:0:32768" "2#/#id-value:16777229"
    "2#/#imsi:imsi-123456789012348" "2#/#msisdn:msisdn-223310101010101"
    "2#/#imei:imei-123456786666660" "2#/#upf:209.165.201.1"
    "2#/#upfEpKey:209.165.201.1:209.165.201.30" "2#/#s5s8Ipv4:209.165.202.129" "2#/#s11Ipv4:209.165.201.1"
    "2#/#namespace:sgw" ]
    flags [ byte-flag1:00:13:03:53:00:00:06:85:0A:01:01:1B session-state-flag:sgw_active ]
    map-id 1
    instance-id 1
    app-instance-id 1
    version 1
    create-time 2022-01-20 11:37:15.181259564 +0000 UTC
    last-updated-time 2022-01-20 11:37:15.703032336 +0000 UTC
    purge-on-eval false
    next-eval-time 2022-01-27 11:37:26 +0000 UTC
    session-types [ SGW:rat_type:EUTRAN ]
    data-size 925

次に、アイドルセッションの出力例を示します。

cdl show sessions summary slice-name 1
message params: {session-summary cli session {0 100  0 [] 0 0 false 4096 [] []} 1}
session {
    primary-key 2#/#imsi-123456789012348
    unique-keys [ "2#/#16777229" ]
    non-unique-keys [ "2#/#id-index:1:0:32768" "2#/#id-value:16777229"
    "2#/#imsi:imsi-123456789012348" "2#/#msisdn:msisdn-223310101010101"
    "2#/#imei:imei-123456786666660" "2#/#upf:209.165.201.1" "2#/#upfEpKey:209.165.201.1:209.165.201.30"
    "2#/#s5s8Ipv4:209.165.202.129" "2#/#s11Ipv4:209.165.201.1" "2#/#namespace:sgw" ]
    flags [ byte-flag1:00:25:00:55:00:65 session-state-flag:sgw_inactive ]
    map-id 1
    instance-id 1
    app-instance-id 1
    version 3
    create-time 2022-01-20 11:37:15.181259564 +0000 UTC
    last-updated-time 2022-01-20 11:37:18.102852792 +0000 UTC
    purge-on-eval false
    next-eval-time 2022-01-27 11:37:28 +0000 UTC
    session-types [ SGW:rat_type:EUTRAN ]
    data-size 1644

制限事項

cnSGW-C は、IPv6 TEID の部分的な CDL 更新をサポートしていません。

機能設定

この機能を設定するには、次の構成を使用します。

config 
   cdl 
      datastore datastore_session_name 
         slot metrics report-idle-session-type { true | false } 
         end

注：

slot metrics report-idle-session-type { true | false } ：CDL db_records_total のアイドルセッション数またはアクティブセッション数を有効または無効にします。

設定例

次に、設定例を示します。

config
   cdl
      datastore session
         slot metrics report-idle-session-type true
         end

OAM サポート

ここでは、この機能の操作、管理、およびメンテナンスサポートについて説明します。

バルク統計サポート

部分的 CDL アップデートアイドルアクティブコールフロー機能では、次の統計情報がサポートされています。

Grafana クエリを実行して、cnSGW-C のアイドルとアクティブなセッションカウントを見つけます。

SGW ACTIVE COUNT :- (db_records_total{namespace=~"$namespace",session_type=~"sgw_active"}) SGW_IDLE COUNT : (db_records_total{namespace=~"$namespace",session_type=~"sgw_inactive"})

DLDR スロットリングのサポートを含む PFCP セッションレポート

機能説明

ライブネットワーク展開では、一部の外部イベントにより、ほとんどすべてのアイドルセッションが同時にアクティブになります。アイドルセッションがアクティブになると、UPF は、レポートタイプ DLDR のセッションレポート要求を cnSGW-C に送信します。

cnSGW-C がレポートタイプを DLDR とするセッションレポートを受信すると、cnSGW-C が UE のページングのための DDN メッセージを送信します。UE をアクティブにするため、MME が UE のページング手順を開始します。ページングが成功した場合、MME はサービス要求「ベアラー変更要求」を開始します。UE にデータが送信されると、UE はアクセスベアラーのリリース要求を開始し、アイドル状態になります。このコールフローは、システム全体の負荷を増加させます。コールフロー全体が短時間のうちにすべてのサブスクライバで発生すると、システム上で大きなプロセスオーバーヘッドが発生します。

DLDR スロットリングのサポート機能を備えた PFCP セッションレポートにより、cnSGW-C はシステムに到着するセッションレポート要求の数を制限して、プロセスの過負荷を防ぐことができます。

重要	この機能により、緊急通報もスロットルされます。

機能の仕組み

ここでは、この機能の仕組みを説明します。

cnSGW-C は、SBA 過負荷制御に app-infra 機能を使用して、着信メッセージをスロットリングします。

システムは、インターフェイスレベルのしきい値設定に基づいて着信メッセージに適切なアクションを実行します。着信メッセージはそれぞれ異なるキューに追加され、メッセージレベルの優先順位設定に基づいて処理されます。

過負荷サポートの詳細については、UCC 5G セッション管理機能の設定および管理ガイド [英語] の「SMF Overload Support」の章を参照してください。

緊急コール、音声コール、および空のコールに関するセッションレポートをスロットリングから除外できます。

これらのセッションレポートを除外するには、profile sgw. で ddn delay-exclude-arplist の設定を設定します。設定済みのいずれかの ARP に関するセッションレポートを受信すると、cnSGW-C はそのセッションレポートをセッションレポートスロットリングから除外します。

機能設定

この機能を設定するには、次の構成を使用します。

config 
    instance instance-id instance_id 
        endpoint pfcp 
            interface sxa 
                overload-control msg-type session-report 
                rate-limit rate_limit 
                queue-size queue_size 
                reject-threshold reject_threshold 
                pending-request pending_request 
                exit 
config 
    profile sgw sgw_name 
        ddn delay-exclude-arplist number_priorities 
        end

注：

overload-control msg-type session-report ：インターフェイスの過負荷に対する仮想メッセージ仕様を設定します。
rate-limit rate_limit ：仮想キューのレート制限を指定します。
queue-size queue_size ：各仮想キューのパケット数または容量を指定します。
reject-threshold reject_threshold ：保留中のリクエストがこのしきい値の割合に達した場合に、受信メッセージを拒否するための上限を指定します。
pending-request pending_request ：仮想キュー内の保留中リクエスト数を指定します。
ddn delay-exclude-arplist number_priorities ：DDN/セッションレポートスロットリングの遅延から除外する必要がある、割り当ておよび保持の優先順位のレベルを指定します（1 ～ 15）。

重要	両方の GR インスタンスに同じレート制限を設定する必要があります。セッションレポートスロットリングは、キュー内の待機時間がトランザクション SLA（保留要求/レート制限 < Txn SLA（秒単位））を超えないようにする必要があります。この設定を追加すると、プロトコルポッドが再起動されます。

設定例

次に、設定例を示します。

config
   instance instance-id 1
      endpoint pfcp
         interface sxa
            overload-control msg-type session-report
            rate-limit 4500 queue-size 2500 reject-threshold 80 pending-request 2400
            exit
         profile sgw sgw1
         ddn delay-exclude-arplist [ 9 ]
         end

設定の確認

設定を確認するには、次のコマンドを実行します。

#show running-config instance instance-id 1 endpoint pfcp
instance instance-id 1
endpoint pfcp
.
.
.
interface sxa
.
.
.
overload-control msg-type session-report
msg-priority high rate-limit 5 priority 1 queue-size 11 reject-threshold 80 pending-request 10
exit
.
.
.

OAM サポート

ここでは、この機能の操作、管理、およびメンテナンスサポートについて説明します。

バルク統計サポート

DLDR スロットリングサポート機能を備えた PFCP セッションレポートでは、次の統計がサポートされています。

プロトコルのポッドレベルの SXa 統計

クエリ：sum(irate(proto_udp_req_msg_total{interface_type="SXA", message_name=~"session_report_.*"}[1m])) by (message_name, status)

凡例：{{message_name}} | {{status}}

accepted：exclude-arp リストで ARP が設定されているため、受け入れられたセッションレポート
throttle_allow：レート制限フレームワークによって許可されるセッションレポート
throttled_pending_req_limit：レート制限フレームワークによってスロットリングされたセッションレポート。

SGW サービスレベルセッションレポートの統計

クエリ：sum(irate(sgw_sx_session_report_stats{}[30s])) by (sx_session_report_type, status)

凡例：{{sx_session_report_type}} -> {{status}}

ワンポイントアドバイス

SMF のバルク統計情報のサポートの詳細については、UCC 5G SMF メトリックリファレンス [英語] を参照してください。

cnSGW-C のバルク統計情報のサポートの詳細については、UCC 5G cnSGW-C メトリックリファレンス [英語] を参照してください。

S11 インターフェイスでのセッション作成要求に対するスロットリングのサポート

機能説明

ライブネットワーク展開では、トラフィックの多いモバイルネットワークが原因で、S11 GTPC エンドポイントは、特にピーク時や人が密集するエリアで、多数のセッション作成要求メッセージを受信する可能性があります。

GTPC は、S11 インターフェイスの GTPC ポッドで多数の CSReq を受信すると、すべての要求を受け入れて処理しようとします。そのため、システム全体の負荷が増加する可能性があります。複数の CSReqs コールが短時間に発生すると、システムに大きなプロセスオーバーヘッドが発生します。S11 GTPC エンドポイントのレート制限構成により、GTPC はシステムに入る CSReq の数を制限して、システムのメモリ不足の状態を防ぐことができます。

機能の仕組み

レート制限設定を使用すると、GTPC エンドポイントへの着信 Create Session Request メッセージのフローを制御できるため、GTPC エンドポイントで大量のトラフィックを効果的に処理できます。

GTPC ポッドは、新しいトランザクションの作成中に仮想 ID を追加する app-infra 機能を使用し、インターフェイスと要求のタイプに基づいて着信メッセージをスロットリングします。

システムは、インターフェイスレベルのしきい値設定に基づいて着信メッセージに適切なアクションを実行します。着信メッセージはさまざまなキューに追加され、設定に基づいて処理されます。

設定されたしきい値に達すると、CSReq が拒否され始めます。この設定は、GTPC エンドポイントで常に処理できる Create Session Request の数を制御することで、大量のトラフィックを管理するのに役立ちます。

セッション作成要求に対するスロットリングの有効化

レート制限設定を使用すると、S11 インターフェイスを介して GTPC エンドポイントへの着信セッション作成要求メッセージのフローを管理できるため、GTPC エンドポイントで大量のトラフィックを効率的に処理できます。

重要	レート制限設定が有効になっている場合、緊急コールと WPS セッションにも適用され、これらのコールのセッション作成要求メッセージが拒否またはドロップされる可能性があります。

注：

両方の GR インスタンスに同じレート制限を設定する必要があります。
セッション作成要求スロットリングは、キュー内の待機時間がトランザクション SLA（保留要求/レート制限 < Txn SLA（秒単位））を超えないようにする必要があります。
- cnSGW を使用しないコンバージドコア展開の場合は、S5 インターフェイスにのみセッション作成要求スロットリング設定を追加することを推奨します。
- cnSGW を使用するコンバージドコア展開の場合は、S11 および S5 インターフェイスに同時にセッション作成要求スロットリング設定を追加することを推奨します。
この設定を追加すると、gtpc-ep ポッドが再起動されます。

GTPC エンドポイントでセッション作成要求メッセージのレート制限を有効にするには、次の手順に従ってください。

手順

ステップ 1	インスタンス識別子を指定します。 instance instance-id `instance_id` 例: `[smf] smf# config [smf] smf(config)# instance instance-id 1`
ステップ 2	GTP エンドポイントを設定します。 endpoint gtp
ステップ 3	インターフェイスを指定します。 interface s11
ステップ 4	セッション作成要求メッセージの過負荷制御を有効化します。 overload-control msg-type create-session-request
ステップ 5	仮想キューの要求がしきい値に達した場合に、セッション作成要求メッセージを拒否するアクションを指定します。 reject-action reject_req
ステップ 6	必要に応じて、仮想キューのレート制限およびその他のパラメータを設定します。 rate-limit `rate_limit` queue-size `queue_size` reject-threshold `reject_threshold` pending-request `pending_requests` 例: `[smf] smf(config-interface-s5)# rate-limit 3000 queue-size 8000 reject-threshold 100 pending-request 5000`

設定例

次に、設定例を示します。


 config
   instance instance-id 1
      endpoint gtp
         interface s11
            overload-control create-session-request
            reject-action reject-req
            rate-limit 3 queue-size 10 reject-threshold 100 pending-request 2
            exit
        exit
    exit
exit

設定の確認

構成を確認するには、次の show コマンドを使用します。

#show running-config instance instance-id 1 endpoint gtp
instance instance-id 1
endpoint gtp
.
.
.
interface s11
.
.
.
overload-control msg-type create-session-request
reject-action reject-req
rate-limit 3 queue-size 10 reject-threshold 100 pending-request 2
exit
.
.
.

OAM サポート

ここでは、この機能の操作、管理、およびメンテナンスサポートについて説明します。

バルク統計サポート

作成セッション要求スロットリング機能では、次の統計情報がサポートされています。

rej_req_throttled_pending_req_limit：保留中の要求の制限に達したときに拒否された作成セッション要求メッセージの総数。
rej_req_throttled_queue_full：トランザクションキューがいっぱいのときに拒否された作成セッション要求メッセージの総数。

次に、cnSGW サービスレベルメトリックの例を示します。

virtual_message_Pending_req_total{app_name="SGW",cluster="Local",data_c
enter="DC",instance_id="0",interface="s11",msg_type="createsessionrequest",
service_name="s11-gtpc-ep1",virtual_msg_id="1"} 0
virtual_message_dequeue_rate_total{app_name="SGW",cluster="Local",data_c
enter="DC",instance_id="0",interface="s11",msg_type="createsessionrequest",
service_name="s11-gtpc-ep1",virtual_msg_id="1"} 11
virtual_message_drop_total{app_name="SGW",cause="PendingRequestsLimitReached",cluster="Local",data_center="DC",instance_id="0",interface="s11",
msg_type="createsessionrequest",service_name="s11-gtpcep1",
virtual_msg_drop_code="8004",virtual_msg_id="1"} 19 <<<<<<<virtual_message_queued_total{app_name="SGW",cluster="Local",data_cent
er="DC",instance_id="0",interface="s11",msg_type="createsessionrequest",ser
vice_name="s11-gtpc-ep1",virtual_msg_id="1"} 11 <<<<<virtual_message_rate_limit_reached_total{app_name="SGW",cluster="Local",d
ata_center="DC",instance_id="0",interface="s11",msg_type="createsessionreq
uest",service_name="s11-gtpc-ep1",virtual_msg_id="1"} 6

復元力処理

機能説明

復元力処理機能により、CLI 制御のフレームワークが導入され、システム障害を確認した場合、またはクラッシュが報告された場合に、サービスポッドのリカバリがサポートされるため、次のいずれかのサービスポッドのリカバリに役立ちます。

sgw-service ポッド
smf-service ポッド
gtpc-ep ポッド
プロトコルポッド

これらのサービスポッドは、複数のセッションメッセージを処理するロジックを含むソフトウェアモジュールです。サービスポッドは、次のいずれかのシナリオ、または複数のシナリオの組み合わせが原因で障害が発生しやすくなります。

複雑なコールフローおよびコリジョン処理
セッション状態が不整合性
セッション状態に対する着信メッセージの不適切な処理
受信メッセージ内の予期しないコンテンツや未処理のコンテンツ

システム障害やクラッシュを確認するたびに、障害の動作によってサービスポッドが強制的に再起動され、他のセッションの進行中のトランザクション処理に影響を及ぼします。ポッドの再起動後でもクラッシュは再発します。

このリスクを軽減するには、アクションが定義されている CLI ベースのフレームワークを使用し、サブスクライバセッションをクリーンアップするか、現在の処理を終了します。

機能の仕組み

ここでは、障害リカバリフレームワークを使用してクラッシュに対するアクションを定義する方法について説明します。このフレームワークでは、次のアクションのいずれかを定義できます。

[Terminate]：障害が発生した場合、このアクションは障害が発生したトランザクションを終了し、サブスクライバセッションのキャッシュをクリアします。これは、smf-service ポッドおよび sgw-service ポッドに適用されます。

（注）

ポッドは再起動されません。このアクション中にデータベースはクリアされません。

[Cleanup]：障害が発生した場合、このアクションは障害が発生しているサブスクライバセッションをクリアし、コールをリリースします。これは、smf-service ポッドおよび sgw-service ポッドに適用されます。
[Graceful reload]：障害が発生した場合、このアクションはポッドを再起動します。これは、gtpc-ep ポッド、protocol ポッド、およびポッドに適用されます。障害信号を処理して、キープアライブポートなどのリソースをクリーンアップし、初期段階で閉じます。また、checkport スクリプトがポッドの状態を検出し、対応するポッドの VIP スイッチ処理を開始できるようにします。
[Reload]：ポッドがクラッシュすると、リロードアクティビティが開始されます。これは、すべてのポッドに適用されるデフォルトの設定または値です。

機能設定

この機能を設定し、システムの障害回復を有効にするには、次の設定例を使用します。

config 
    system-diagnostics {   gtp | pfcp | service | sgw-service } 
        fault 
            action { abort | cleanup { file-detail | interval | num | skip { ims | emergency | wps } } | graceful-Reload | reload } 
            end

注：

system-diagnostics { gtp | pfcp | service | sgw-service } ：システム診断に必要なサービスポッドのタイプを指定します。使用可能なポッドオプションは、、gtp、pfcp、smf-service、および sgw-service です。
fault ：セッションの処理中に障害回復を有効にします。

action { abort | cleanup | graceful-Reload | reload } ：障害発生時に実行するアクションを次から 1 つ指定します。デフォルトアクションはリロードです。

abort ：障害のあるトランザクションを削除し、そのセッションキャッシュをクリアします。データベースはクリアされません。

（注）

これは、smf-service ポッドに対する排他的オプションです。

cleanup { file-detail | interval | num | skip } ：クリーンアップアクティビティを有効にします。障害を軽減するためのアクションとして次の選択肢があります。

file-detail ：ファイル名に行番号を付けて一覧表示します。リカバリからファイル名の詳細が除外されます。
interval ：間隔を分単位で指定します。この期間に、障害の最大数を許可する許容間隔を指定します。1 ～ 3600 の範囲の整数で指定する必要があります。
num ：1 つの間隔内で許容可能な障害の最大数を指定します。0 ～ 50 の範囲の整数で指定する必要があります。
skip { ims | emergency | wps } ：アクティブ音声コール、WPS、または緊急コールに対するサブスクライバセッションのクリーンアップのスキップを有効にします。
- アクティブ音声コールを検出するには、次のコマンドを使用します。
```
profile dnn dnn_name ims mark qci qos_class_id 
```
- クリーンアップのスキップ設定を有効にすると、SMF は問題のあるトランザクションを削除し、そのセッションキャッシュをクリアします。
- セッションのセットアップ中またはリリース状態の間に障害が発生すると、SMF は次の処理を実行します。
  
  ：セッション終了時にトランザクションを削除します。
  
  ：これらの状態の間、設定済みの障害アクションをオーバーライドします。
  
  ：障害のあるトランザクションのセッションキャッシュおよびデータベースエントリをクリアします。
- これにより、動的な設定変更が可能になります。

（注）

これは、smf-service および sgw-service ポッドの排他的オプションです。

graceful-Reload ：ポッドの正常なリロードのためのオプションを指定します。サービスポッドは、障害信号を処理してキープアライブポートなどのリソースをクリーンアップし、クラッシュ処理（ポッド再起動処理）を続行します。

（注）

これは、、gtpc-ep、および protocol サービスポッドに対する排他的なオプションです。

reload ：障害動作が原因でポッドがクラッシュした場合に、ポッドをリロードします。これは、すべてのサービスポッドに適用できるオプションです。これはデフォルトのオプションでもあります。

設定例

次の設定例では、障害発生アクションをサブスクライバのクリーンアップとして、smf-service または sgw-service ポッドのクラッシュが 10 分間隔以内で 3 回許可されます。

config
    system-diagnostics { service | sgw-service }
        fault
            num 3 interval 10
            action cleanup
            end

次の設定例では、または gtpc-ep ポッド、あるいは protocol ポッドのグレースフル障害処理で、障害信号の受信時にキープアライブポートを閉じることができます。

設定の確認

設定を確認するには、次のコマンドを実行します。

OAM のサポート

ここでは、この機能の操作、管理、およびメンテナンスサポートについて説明します。

バルク統計サポート

復元力処理機能では、次のバルク統計がサポートされています。

recover_request_total ：この統計には、次の新しいラベルが含まれています。

action ：障害アクションを定義します。
reason ：障害の理由を定義します。
status ：障害ステータスを定義します。

次に、復元力処理機能のバルク統計の例を示します。

recover_request_total{action="panic_recovery_cleanup", app_name="SMF",cluster="Local",data_center="DC",instance_id="0", reason="creating panic",service_name="sgw-service",status="success"} 1

SMF のバルク統計のサポートの詳細については、UCC 5G SMF メトリックリファレンス [英語] を参照してください。

cnSGW-C のバルク統計のサポートの詳細については、UCC 5G cnSGW-C メトリックリファレンス [英語] を参照してください。

ローミングピアパス管理の最適化

機能説明

cnSGW-C は着信ローミングをサポートします。着信ローミングが有効になっている場合、cnSGW-C はローミングのホームネットワークにあるリモート PGW と通信します。

cnSGW-C はローミングピアに向けてエコー要求メッセージを生成し、パス障害を検出することで、ローミングピアからのエコー要求メッセージを処理します。

機能の仕組み

ここでは、この機能の仕組みを説明します。

cnSGW-C は、サブスクライバポリシーとオペレータポリシーを使用して、ピアをローミングピアまたはホームピアとして分類します。cnSGW-C は、ローミングピアに次の機能を適用します。

cnSGW-C は、ローミングピアから受信したエコー要求メッセージにすぐに応答します。エコー要求で再起動カウンタ値が変更された場合、cnSGW-C はピアへのパス障害を検出しません。
cnSGW-C は、設定されたエコー間隔に達した後も、ローミングピアに対してエコー要求を生成し続けます。エコー応答で再起動カウンタ値が変更された場合、cnSGW-C はピアへのパス障害を検出します。
最初のセッション作成応答メッセージおよび SGW 再配置ベアラー変更応答メッセージで再起動カウンタ値が変更された場合、cnSGW-C はピアへのパス障害を検出します。
cnSGW-C は、ローミングピアからエコー要求を受信しても、ローミングの最後のアクティビティ時間を更新しません。
以前の実装では、Nodemgr の環境変数 ROAMING_PEER_ECHO_MODULATOR がローミングピアに対するエコー要求の生成を制御します。この環境変数の値を変更すると、変更後に毎回 NodeMgr ポッドが再起動します。

この動作を最適化するために、環境変数 ROAMING_PEER_ECHO_MODULATOR の使用は廃止され、S8e インターフェイス設定を使用してローミングピアに異なるエコー間隔を設定するためのサポートが追加されます。S8e インターフェイスのエコー設定が有効になっている場合、cnSGW-C はこの設定を使用してローミングピアに対するエコー要求を生成します。

詳細については、「ローミングピアノードのエコー要求最適化の有効化」を参照してください。
S8e インターフェイス設定が存在しない場合、cnSGW-c は環境変数 ROAMING_PEER_ECHO_MODULATOR を使用して、ローミングピアに対するエコー要求の生成を制御します。ROAMING_PEER_ECHO_MODULATOR のデフォルト値は 3 です。cnSGW-C は、 ROAMING_PEER_ECHO_MODULATOR * エコー間隔に到達した後、ローミングピアに対してエコー要求を生成します。

たとえば、ROAMING_PEER_ECHO_MODULATOR が 3 で、エコー間隔が 60 の場合、cnSGW-C は 180 秒後にエコー要求を生成します。同様に、ROAMING_PEER_ECHO_MODULATOR が 0 の場合、cnSGW-C はローミングピアに対してエコー要求を生成しません。

GTPC-EP ポッドでは、変数 GTPC_UPDATE_LAST_MSG_RECV_TIME_AFTER が最後のアクティビティ時間の更新を制御します。この変数のデフォルト値は 30 秒です。cnSGW-C は、30 秒後にピアの最後のアクティビティ時間を更新します。この値を大きくすると、NodeMgr への最後のアクティビティ時間の更新通知を減らすことができます。

機能設定

この機能の設定には、次の手順が含まれます。

ローミングステータスをローミングするオペレータポリシーを構成し、オペレータポリシーをサブスクライバポリシーに関連付けて、オペレータをローミングピアとして識別します。詳細については、オペレータポリシーおよびサブスクライバポリシーの構成を参照してください。
BGP ルートをダイナミックに追加する際に、使用するデフォルトゲートウェイを構成します。詳細については、デフォルトゲートウェイの設定を参照してください。
ローミングピアノードのエコー要求最適化を有効にします。「ローミングピアノードのエコー間隔の構成」を参照してください。

オペレータポリシーおよびサブスクライバポリシーの構成

この機能を設定するには、次の構成を使用します。

config 
   policy 
     subscriber subscriber_name 
        precedence precedence_value 
          imsi mcc mcc_value 
          imsi mnc mnc_value 
          operator-policy policy_name 
          exit 
        exit 
     operator operator_policy 
        roaming-status roamer 
        exit 
   profile sgw sgw_profile_name 
        subscriber-policy policy_name 
        end

注：

precedence precedence_value ：エントリの優先順位を指定します。1 ～ 2048 の範囲の整数で指定する必要があります。
mcc mcc_value：モバイル国コード（MCC）を指定します。3 桁の数字で指定する必要があります。
mnc mnc_value ：モバイルネットワークコード（MNC）を指定します。2 桁または 3 桁の数字で指定する必要があります。
operator-policy policy_name ：オペレータポリシー名を指定します。文字列で指定する必要があります。
policy-operator operator_policy ：オペレータポリシーを指定します。以下のいずれかを指定する必要があります。
- <any string>
- defOprPoll
- opPolHomer
- opPolRoaming
- opPolVisiting
- opPolVisiting_hrt
- opPolVisiting_hrt_overriden
roaming-status roamer ：ピアのローミングステータスを指定します。デフォルトでは、無効になっています。
subscriber-policy policy_name：サブスクライバポリシー名を指定します。文字列で指定する必要があります。

設定例

次に、設定例を示します。

config
   policy subscriber polSubSgw
      precedence 1
         imsi mcc 310
         imsi mnc 260
         operator-policy Home_op1
         exit

      precedence 2
         imsi mcc 311
         imsi mnc 660
         operator-policy Home_op1
         exit

      precedence 3
         imsi mcc 310
         imsi mnc 240
         operator-policy Home_op1
         exit

      precedence 4
         operator-policy Roaming_SGW_op1
         exit
      exit

      policy operator Roaming_SGW_op1
         roaming-status roamer
         exit

      profile sgw sgw1
         subscriber-policy polSubSgw
         end

デフォルトゲートウェイの設定

この機能を設定するには、次の構成を使用します。

config 
   router bgp local_as_number 
   policy-name policy_name 
      source-prefix source_prefix_value 
      mask-range mask_range 
      interface interface_id 
      gateWay gateway_address 
      end

注：

router bgp local_as_number ：BGP ルータの AS の ID 番号を指定します。
policy-name policy_name ：ポリシー名を指定します。
source_prefix source_prefix_value ：送信元プレフィックスの値を指定します。
mask-rangemask_range ：マスクの範囲を指定します。
gateWay gateway_address ：ゲートウェイアドレスを指定します。

設定例

次に、設定例を示します。

config
   router bgp 6500
   policy-name sgw_bgp 
      source-prefix 209.165.201.12/32 
      mask-range 32..32 
      interface ens224.2084 
      gateWay 209.165.201.28
      end

設定の確認

設定を確認するには、次のコマンドを実行します。

show subscriber namespace sgw imsi 123456789012345 full subscriber-details

{
"subResponses": [
  "pdnInfoList": {
     "pdnInfo": [
          {
           "plmnType": "VISITOR"
           "s5ePeerType": "ROAMER"
           }
      ]
   }
]
}

show peers | include S5

1 S5E 209.165.201.12:212320.20.20.124:2123Inbound nodemgr-1 Udp 2 minutes PGW MaxRemoteRcChange: N/A,Recovery: 10 S5
1 S5E 209.165.201.12:212320.20.20.127:2123Inbound nodemgr-0 Udp 35 seconds PGW MaxRemoteRcChange: N/A,Recovery: 10,S5E PeerType: Roaming

ローミングピアノードのエコー要求最適化の有効化

ローミングピアノードのエコー要求の最適化を有効にするには、次の手順を実行します。

手順

ステップ 1	S8e インターフェイスでエコー間隔を設定します。
ステップ 2	パス障害検出ポリシーを設定します。
ステップ 3	S8e インターフェイスでのパス障害検出ポリシーの関連付け。

S8e インターフェイスのエコー間隔の設定

S8e インターフェイスでエコー要求を有効にするには、次の手順を使用します。

手順

ステップ 1

インスタンス ID コンフィギュレーションモードを開始します。

instance instance-id instance_id

例:

[smf] smf# config 
[smf] smf(config)# instance instance-id 1

ステップ 2

GTPC エンドポイントを設定します。

endpoint endpoint_type

例:

[smf] smf(config-instance-1)# endpoint gtp

ステップ 3

S8e インターフェイスを設定します。

interface interface_type

例:

[smf] smf(config-endpoint-gtp)# interface s8e

ステップ 4

エコーを設定します。

echo interval echo_interval retransmission-timeout retransmission_timeout max-retransmissions max_retransmissions

例:

[smf] smf(config-interface-s8e)# echo interval 300 retransmission-timeout 10 max-retransmissions 4

（注）

echo_interval：エコー間隔を秒単位で指定します。60 〜 3600 の範囲の整数で指定する必要があります。デフォルト値は 300 です。ローミングピアへのエコー要求の生成を無効にするには、0 を使用します。
retransmission_timeout：エコー再送信のタイムアウトを秒単位で指定します。1 ～ 20 の範囲の整数で指定する必要があります。デフォルト値は 5 です。
max_retransmissions：GTP エコー要求の最大再試行回数を指定します。0 ～ 15 の範囲の整数で指定する必要があります。デフォルト値は 3 です。

ステップ 5

設定を保存してコミットします。

例:

[smf] smf(config-interface-s8e)# end

ステップ 6

（任意）show running-config instance instance-id 1 endpoint gtp interface s8e コマンドを使用して、エコー間隔が設定されているか確認します。

例:


[sgw] smf# show running-config instance instance-id 1 endpoint gtp interface s8e
Thu Dec  12 09:26:46.295 UTC+00:00
instance instance-id 1
 endpoint gtp
  interface s8e
   echo retransmission-timeout 10
   echo max-retransmissions 4
   echo interval          300
   
  exit
 exit
exit

S8e インターフェイスでのパス障害検出ポリシーの関連付け

S8e インターフェイスでエコー要求を有効にするには、次の手順を使用します。

手順

ステップ 1

インスタンス ID コンフィギュレーションモードを開始します。

instance instance-id instance_id

例:

[smf] smf# config 
[smf] smf(config)# instance instance-id 1

ステップ 2

GTP エンドポイントを設定します。

endpoint endpoint_type

例:

[smf] smf(config-instance-1)# endpoint gtp

ステップ 3

s8e インターフェイスを設定します。

interface interface_type

例:

[smf] smf(config-endpoint-gtp)# interface s8e

ステップ 4

パス障害検出ポリシーを定義します。

path-failure detection-policy detection_policy_name

例:

[smf] smf(config-interface-s8e)# path-failure detection-policy pf1

（注）

detection_policy_name：障害検出ポリシー名を指定します。文字列で指定する必要があります。

ステップ 5

設定を保存してコミットします。

例:

[smf] smf(config-interface-s8e)# end

ステップ 6

（任意）show running-config instance instance-id 1 endpoint gtp interface s8e コマンドを使用して、パス障害検出ポリシーが有効になっているか確認します。

例:


[sgw] smf# show running-config instance instance-id 1 endpoint gtp interface s8e
Thu Dec  12 09:26:46.295 UTC+00:00
instance instance-id 1
 endpoint gtp
  interface s8e
   echo retransmission-timeout 10
   echo max-retransmissions 4
   echo interval          300
   path-failure detection-policy pf1
  exit
 exit
exit

パス障害検出ポリシーの設定

パス障害検出ポリシーを設定するには、次の手順を実行します。

手順

ステップ 1

パス障害検出コンフィギュレーションモードを開始します。

path-failure detection-policydetection_policy_name

例:

[smf] smf# config 
[smf] smf(config)# path-failure detection-policy pf1

ステップ 2

max-remote-rc-change および ignore を指定して、パス障害検出ポリシーを設定します。

max-remote-rc-change max_remote_rc_change ignore ignore

（注）

ignore：再起動カウンタ値、エコータイムアウト、またはエコー障害を無視するように指定します。control-rc-change、echo-failure、または echo-rc-change にする必要があります。

例:

[smf] smf(config-path-failure-detection-pf1)# max-remote-rc-change  2 ignore echo-failure

ステップ 3

設定を保存してコミットします。

例:

[smf] smf(config-path-failure-detection-pf1)# end

ステップ 4

（任意）show running-config policy path-failure-detection コマンドを使用して、パス障害検出ポリシーが設定されているか確認します。

例:


[sgw] smf# show running-config policy path-failure-detection
Thu Dec  12 09:26:46.295 UTC+00:00
Thu Dec  12 09:27:17.678 UTC+00:00
policy path-failure-detection pf1
 max-remote-rc-change 2
 ignore echo-failure
exit

ローミングピアノード向けエコーの最適化の設定例

ここでは、S8e インターフェイスでエコー最適化を有効にする設定例を示します。


config
instance instance-id 1
 endpoint gtp
  interface s8e
   echo retransmission-timeout 10
   echo max-retransmissions 4
   echo interval          300
   path-failure detection-policy pf1
  exit
 exit
exit

config
policy path-failure-detection pf1
 max-remote-rc-change 2
 ignore echo-failure
exit

OAM のサポート

ここでは、この機能の操作、管理、およびメンテナンスサポートについて説明します。

バルク統計サポート

ローミングピアパス管理の最適化機能では、次の統計情報がサポートされています。

ローミングピアからのエコー要求処理が抑制されていることを示す gtpc-ep 統計。

gtpc_roaming_peer_path_mgmt{app_name="SGW",cluster="Local",data_center="DC", gtpc_peer_type="ROAMER",instance_id="1",interface_type="S5E",service_name="gtpc-ep", status="suppressed"} 1

bgp 追加要求の総数を示す upd_proxy 統計情報。

# HELP upd_proxy_bgp_routes_count Total number of bgp add request # TYPE upd_proxy_bgp_routes_count counter upd_proxy_bgp_routes_count{app_name="SGW",cluster="Local",data_center="DC", gr_instance_id="1",instance_id="0",service_name="udp-proxy",status="success"} 1

DB データベース更新にフラグを設定する

機能説明

cnSGW-C、サブスクライバの状態がアイドルからアクティブに変わり、URI、UeTz、UCI、またはサービングネットワークが変更されるたびに、CDL を更新します。

CDL に向けられたトランザクション要求が増加すると、cnSGW-C による CPU 使用率が高くなります。不要な CPU 使用率を防ぐために、cnSGW-C は変更された属性で CDL のサブセットのみを更新します。

DDN 手順用のフラグ DB データベース

DDN 手順が完了すると、sgw-service は CPU 使用率に影響を与える CDL を更新します。CPU 使用率を最適化するために、部分的な更新でのみ DDN が CDL に通知されます。

DDN 内部タイマー

cnSGW-C は、CDL のタイマー機能を適用することによって、DDN 再試行タイマーを実装します。すべての DDN トランザクションで、完全な CDL インスタンスを更新する必要がある DDN 再試行タイマーが開始されるため、CDL および sgw-service の CPU 使用率が増加します。

cnSGW-C は、sgw-profile から構成可能な統合 DDN 再試行タイマーを搭載するように変更されました。このアプローチにより、cnSGW-C は内部タイマーであるため、DDN 再試行タイマーを開始するために CDL と通信しないため、パフォーマンスが向上します。DDN 再試行タイマーが 10 秒間開始されます。

OAM サポート

ここでは、この機能の操作、管理、およびメンテナンスサポートについて説明します。

バルク統計サポート

フラグ DB データベース更新機能では、次の統計がサポートされています。

mbr_partial_cdl_update：Modify Bearer Request によって呼び出された部分的な CDL 更新手順の合計数をキャプチャします。

サンプルクエリ：

sgw_cdl_update_stats{app_name="smf",cdl_update_type=" mbr_partial_cdl_update",cluster="Local",data_center="DC",gr_instance_id="1", instance_id="0",rat_type="EUTRAN",service_name="sgw-service"} 1

ddn_partial_cdl_update：DDN が呼び出した部分的な CDL 更新手順の合計数をキャプチャします。

サンプルクエリ：

sgw_cdl_update_stats{app_name="smf",cdl_update_type=" ddn_partial_cdl_update",cluster="Local",data_center="DC",gr_instance_id="1", instance_id="0",rat_type="EUTRAN",service_name="sgw-service"} 1

バルク統計のサポートの詳細については、UCC サービングゲートウェイコントロールプレーン機能メトリックリファレンス [英語] を参照してください。

プロトコルマイクロサービスに統合された UDP プロキシ機能

機能説明

UDP プロキシマイクロサービスは、UDP プロトコルをトランスポート層プロトコルとして、必要とするプロトコル（PFCP、GTPC、および RADIUS）の UDP トランスポート終端を提供します。UDP プロキシは、ユーザー空間パケット転送と IPC 通信をプロトコルマイクロサービスに提供します。また、送信元 IP アドレスのオブザーバビリティのためにホストネットワーキングを使用し、アクティブ/スタンバイモードで動作します。

複数のプロトコルマイクロサービスが、UDP トランスポートの UDP プロキシに依存しているため、UDP プロキシはスケーリングのボトルネックです。メッセージの急増は、パケットのドロップにつながる可能性があります。

着信メッセージと発信メッセージでは、メッセージの転送に UDP プロキシポッドが使用されます。UDP プロキシでは、最小限のパケット処理でメッセージが GTPC-EP ポッドに転送されるため、パケットのマーシャリングまたはマーシャリング解除とともに、メッセージ転送のための IPC 通信が必要です。

スケーリングのボトルネックを軽減するために、UDP プロキシ機能が各プロトコルのマイクロサービスにマージされます。プロトコルポッドはメッセージを直接受信し、メッセージの転送と IPC 通信を回避します。

UDP プロキシバイパスでは、シグナリングパスにおいてマイクロサービス間で 1 ホップ減らすことで、CPU 使用率を向上させます。cnSGW-C は、PFCP および GTPC プロトコルの UDP プロキシバイパスをサポートしています。

UDP プロキシバイパスを使用した PFCP プロトコルエンドポイント

UDP プロキシモードでは、N4、Sxa、GTP-U などのプロトコルに対するメッセージ交換はすべて UDP プロキシを介して実行されます。UDP プロキシは、UPF との接続または接続の受信に関与します。サービスまたは UPF がすべてのノード関連またはセッション関連のメッセージを開始し、応答は UDP プロキシを通過します。UDP プロキシは、すべてのノード関連のメッセージを処理し、各メッセージをプロトコルノードに転送します。

アウトバウンド UDP プロキシバイパスモードでは、セッション関連のメッセージはプロトコルから UPF に直接渡されます。ノード関連のメッセージでは、引き続き現在のパスが使用され、UDP プロキシを経由してプロトコルポッドやノードマネージャに渡されます。

インバウンドおよびアウトバウンドの UDP プロキシバイパスモードでは、サービスは、UDP プロキシをバイパスし、プロトコルポッドを介してセッション関連のメッセージを UPF に直接送信します。プロトコルは、アプリケーションサービスが UPF 宛ての PFCP メッセージを開始する限り、UPF との接続も確立します。

PFCP 用 UDP プロキシバイパスの詳細については、UCC 5G SMF 設定および管理ガイド [英語] を参照してください。

UDP プロキシバイパスを使用した PFCP プロトコルエンドポイント

UDP プロキシモードでは、GTPv2 プロトコルに対するメッセージ交換はすべて UDP プロキシを介して実行されます。UDP プロキシは、S11 と S5e、S2b、および S5/S8 インターフェイスでの接続または受信を行います。サービスまたは GTP ピアがセッション関連またはノード関連のメッセージを開始し、応答は UDP プロキシを通過します。UDP プロキシは、すべてのノード関連のメッセージを処理し、各メッセージをプロトコルノードに転送します。

インバウンドおよびアウトバウンド UDP プロキシバイパスモードでは、サービス開始セッション関連のメッセージは、UDP プロキシをバイパスして、GTPC-EP ポッドを介して GTP ピアに直接送信されます。ノード関連のメッセージの場合、GTPC-EP は、S11、S5e、S2b、および S5/S8 インターフェイス上でピアが接続するために GTP エンドポイントを開始します。GTPC-EP ポッドは、アプリサービスが GTP ピアへの GTPv2 メッセージを開始するときに、として GTP ピアとの接続も確立します。

次の機能は、UDP プロキシから統合されます。

トランザクション SLA
GTP パケットの DSCP マーキング
ローミングサブスクライバの BGP ルートのオンザフライ追加
ディスパッチャ機能と着信再送信のサポート
DDN の SGW キャッシュの統合
MBR キャッシュ統合

次の機能は GTPC-EP から統合されます。

アウトバウンド要求の n3t3 構成に基づく再送信
プロトコルのモニタリングとサブスクライバのモニタリング
エコーメッセージ処理

UDP プロキシモードをサポートする既存の機能はすべて、UDP プロキシバイパスモードの有無にかかわらずサポートされます。

機能の仕組み

ここでは、この機能の仕組みを説明します。

バイパス機能が有効になっている場合、GTPC-EP k8 サービスは無効になります。

UDP プロキシバイパス機能を備えた GTPC プロトコルエンドポイントには、ホスト環境でアクティブ/スタンバイモードの GTPC-EP ポッドが実行されている必要があります。GTPC-EP ポッドがアクティブ-スタンバイモードのホスト環境で実行されている場合、k8-service は無効になります。さらに、ポッド（SGW-Service およびノードマネージャ）が GTPC-EP ポッドと通信する必要がある場合、GTPC-EP ポッドに追加のエンドポイントが必要です。このインフラエンドポイントは GTPC-EP アプリの起動時に初期化され、内部 IP が同じ目的で使用されます。

内部 IP が構成されていない場合、使用可能な GTP VIP がインフラエンドポイントの初期化に使用されます。

S11、S5、S5e、および S2b インターフェイスは、ベース GTP VIP IP アドレスの代わりに GTP VIP を構成するために使用されます。

UDP ソケットは、GTP パケットを処理するために GTPC-EP ポッドで作成されます。

バイパス UDP プロキシ機能を有効または無効にするための新しい CLI またはキーワードは追加されていません。既存のエンドポイント構成を次のように使用して、UDP プロキシのバイパス機能を有効または無効にします。

GTP VIP は、UDP プロキシ（バイパスなし）を使用するためにエンドポイントプロトコルで構成する必要があります。
GTP VIP は、バイパス UDP プロキシを有効にするために GTPC エンドポイントで構成する必要があります。
GTP VIP がプロトコルエンドポイントと GTP エンドポイントの両方で構成されている場合、UDP プロキシがデフォルトで使用されます。
再送信 n3t3 ベース、エコー、SLA、ディスパッチャ、および DSCP などの GTPC 機能固有の構成は、バイパス機能に関係なく、エンドポイント GTP で構成する必要があります。

（注）

この機能が導入される前は、エンドポイント GTP が構成されている場合、UDP プロキシモードがデフォルトの動作でした。この機能を使用すると、エンドポイント GTP が GTP インターフェイス VIP（s5、s11、s5e、または s2b）で構成されている場合、UDP プロキシバイパスはデフォルトで有効になります。UDP プロキシバイパスを無効にするには、エンドポイントプロトコルを GTP インターフェイス VIP（s5、s11、s5e、または s2b）で構成する必要があります。

コールフロー

ここでは、この機能の主要なコールフローについて説明します。

UDP プロキシバイパスを使用した PFCP プロトコルエンドポイントのコールフロー

このセクションでは、UDP プロキシバイパスを使用した PFCP プロトコルエンドポイントのコールフローについて説明します。

表 10. UDP プロキシバイパスを使用した PFCP プロトコルエンドポイントのコールフローの説明
ステップ	説明
1	GTP_Peer が GTPC-EP ポッドに GTP 要求を送信します。
2	GTPC-EP ポッドがメッセージをデコードし、基本的な検証を実行して、GTP 要求をサービスに転送します。
3	サービスが GTP 要求を処理し、GTP 応答を生成して、GTP 応答を GTPC-EP ポッドに送信します。
4	GTPC-EP ポッドが GTP 応答メッセージをエンコードし、GTP 応答メッセージを GTP_Peer に転送します。

機能設定

この機能の設定には、次の手順が含まれます。

内部 VIP の構成
インフラ GTP エンドポイントを初期化するためのインターフェイスでの GTP VIP の構成

内部 VIP の構成

内部 VIP を構成するには、次の設定を使用します。

config 
   instance instance-id instance_id 
      endpoint gtp 
         internal-vip  vip_ip_address 
         vip-ip ipv4_address vip-port ipv4_port_number 
         vip-ipv6 ipv6_address vip-ipv6-port ipv6_port_number 
         dual-stack-transport { true | false }  
         end

注：

internal-vip vip_ip_address ：GTPC-EP ポッドの追加エンドポイントの内部 VIP IP アドレスを指定します。サービスポッドは、この IP アドレスにメッセージを直接送信します。
dual-stack-transport { true | false } ：IPv6 または IPv4 アドレスを指定できるデュアルスタック機能を有効にします。この機能を有効にするには、true を指定します。

GTP VIP の設定

インフラ GTP エンドポイントを初期化するためのインターフェイスで GTP VIP を設定するには、次の設定を使用します。

config 
   instance instance-id instance_id 
      endpoint gtp 
         vip-ip ipv4_address vip-port ipv4_port_number 
         vip-ipv6 ipv6_address vip-ipv6-port ipv6_port_number 
         dual-stack-transport { true | false }  
      interface interface_name 
         vip-ip ipv4_address vip-port ipv4_port_number 
         vip-ipv6 ipv6_address vip-ipv6-port ipv6_port_number 
         dual-stack-transport { true | false }  
         end

注：

vip-ip ipv4_address vip-portipv4_port_number ：インターフェイスの IPv4 アドレスを指定します。
vip-ipv6 ipv6_address vip-ipv6-portipv6_port_number ：インターフェイスの IPv6 アドレスを指定します。
dual-stack-transport { true | false } ：IPv6 または IPv4 アドレスを指定できるデュアルスタック機能を有効にします。この機能を有効にするには、true を指定します。

設定例

次に、構成例を示します。

UDP プロキシバイパスが有効になっている GTPC-EP の内部 VIP の構成例：

config
    instance instance-id 1
        endpoint gtp
          internal-vip 209.165.201.15
          end

バイパス機能を有効にした（UDP プロキシがバイパスされた）構成例：

config
    instance instance-id 1
        endpoint gtp
          vip-ip 209.165.201.20
          interface s5
            vip-ip 209.165.201.20
            exit
          interface s5e
            vip-ip 209.165.201.8
            exit
          interface s2b
            vip-ip 209.165.201.20
            exit
          interface s11
            vip-ip 209.165.201.8
            end

バイパス機能が無効になっている構成例（GTP メッセージに UDP プロキシを使用）：

config
    instance instance-id 1
        endpoint protocol
          vip-ip 209.165.201.20
          interface s5
            vip-ip 209.165.201.20
            exit
          interface s5e
            vip-ip 209.165.201.8
            exit
          interface s2b
            vip-ip 209.165.201.20
            exit
          interface s11
            vip-ip 209.165.201.8
            end

偏向のない言語

翻訳について

検索結果

章のタイトル： パフォーマンス最適化のサポート

パフォーマンス最適化のサポート

機能の概要と変更履歴

要約データ

マニュアルの変更履歴

機能説明

GTPC-EP から SGW サービスへの非同期 BG-IPC

機能説明

バッチ ID の割り当て、リリース、および調整のサポート

機能説明

機能の仕組み

機能設定

OAM サポート

バルク統計

キャッシュポッドの最適化

機能説明

CDL フラッシュ間隔およびセッション有効期限のチューニング設定

機能説明

機能設定

設定例

DDN コールフロー最適化

機能説明

機能の仕組み

コール フロー

現在の Downlink Data Notification 処理コールフロー

内部 DDN 遅延タイマーによる DNN 処理のコールフロー

機能設定

設定例

OAM のサポート

バルク統計

DDN タイムアウト設定

機能説明

機能設定

Ops センターを使用したドメインベースのユーザー認可

機能説明

機能の仕組み

機能設定

設定例

設定の確認

エッジエコーの実装

機能説明

機能の仕組み

Heartbeat

OAM サポート

バルク統計サポート

ETCD ピア最適化サポート

機能説明

機能の仕組み

最適化された GTPv2 エンコーダおよびデコーダ

機能説明

機能設定

設定例

OAM サポート

バルク統計サポート

GR スプリットを使用した GTPC エンドポイント

機能説明

機能の仕組み

S11 と S5 による GTPC エンドポイント インターフェイス分割

機能説明

機能の仕組み

機能設定

設定例

GTPC IPC クロスラックサポート

機能説明

機能の仕組み

ラック間 GTPC IPC のアップグレードと有効化

コール フロー

ラック間 IPC コールフローを搭載した cnSGW-C GTPC 最適化

ラック間 IPC による SMF および PGWc GTPC 最適化コールフロー

機能設定

設定例

OAM のサポート

KPI のサポート

サービス間ポッド通信

機能説明

機能の仕組み

章のタイトル：パフォーマンス最適化のサポート

コールフロー

S11 と S5 による GTPC エンドポイントインターフェイス分割

コールフロー

コールフロー

コールフロー

メンテナンスモード

SGW サービスレベルセッションレポートの統計

デフォルトゲートウェイの設定