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

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 ] ] : Configure the required domain-based-services value.domain-based-services には次のオプションが含まれます。

  • domain-delimiter ：ドメインの決定に使用するデリミタを指定します。このオプションは必須であり、次の値を使用できます。

    • @：ドメインデリミタが「@」の場合、ユーザー値は <user> @<domain> 形式になります。

    • /：ドメインデリミタが「/」の場合、ユーザー値は次の形式になります。<domain> /<user> 。

    • \：ドメインデリミタが「\」の場合、ユーザー値は <domain>\<user> 形式になります。

  • domain-service ：ドメインおよびそのドメインのグループ マッピングのリストを指定します。キーはドメインの名前で、グループはドメインに割り当てられたグループです。このリストの少なくとも 1 つのオプションを構成する必要があります。

  • no-domain ：ドメインを持たないグループを指定します。またはドメインがドメインサービス マッピングで使用できない場合、このグループが受け入れ応答で送信されます。

  • nso-service-account ：ID とグループを持つ NSO サービスアカウントを指定します。このパラメータを構成する場合は、ID フィールドとグループ フィールドを構成する必要があります。ID とグループには文字列値が必要です。

SMF は enable-direct-encdec CLI コマンドを使用して、GTPC エンドポイント ポッドに関連付けられている IE のエンコードとデコードを最適化します。この最適化により、メモリ管理が向上し、ガベージ コレクション時間が短縮されます。

この機能は、実行時に有効にすることができます。デフォルトでは、この機能は無効になっています。

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

config 
   instance instance-id instance_id 
      endpoint gtp 
      interface s5e 
         enable-direct-encdec true | false 
      interface s11 
         enable-direct-encdec true | false 
      exit 
   exit 

注：

• enable-direct-encdec true | false : エンコーダとデコーダを有効にするには、値を true として選択します。デフォルトでは、このフィールドの値は false です。

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

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

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

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

• 新しいピアの場合、ピア グループはETCDですぐに保持されます。

• 既存のピアのタイムスタンプの変更の場合、ピア グループは 3 秒ごとに 1 回更新されます。次の更新：

  • 各ピア グループ内でタイムスタンプが変更された多くのピアの累積的なグループ更新が発生します。

  • etcd の頻繁な更新を削減します。

ETCD クライアントでは、次のコンポーネントが実装されています：

• ETCD クラスタへの gRPC 接続を確立するバランサ。

• ETCD サーバーに RPC を送信する API クライアント。

• 失敗した要求を再試行するか、エンドポイントを切り替えるかを決定するエラー ハンドラ。

5G のメモリ キャッシュを使用するアプリインフラベースのポッドは、ETCD サーバーと通信します。この通信は、ETCD クライアント ロード バランサを介して分散システムに重要なデータを保存するためのものです。メモリ キャッシュは、clientv3-grpc1.7 ライブラリを実装する ETCD クライアント 3.3 バージョンを使用します。

SMF は、clientv3-grpc1.14 ライブラリを実装する ETCD クライアント バージョン 3.4.21 をサポートしています。このライブラリには下位互換性があります。

clientv3-grpc1.14 ライブラリには、次の重要なポイントがあります。

• 異常なエンドポイントのリストを維持するのではなく、バランサーのフェールオーバー ロジックを簡素化します。

• 複数のエンドポイントが使用可能な場合は、複数のサブ接続を作成します。これは、エンドポイントごとに 1 つのサブ接続を意味します。たとえば、5 ノードクラスタでは、clientv3-grpc1.14 バランサーには 5 つの TCP 接続が必要です。

• TCP 接続のプールを保持することで、より優れたフェールオーバー パフォーマンスと柔軟なロードバランサを提供します。

• デフォルトのラウンドロビン負荷分散ポリシーを拡張し、パワーオブツーやピックリーダーなどの他の種類の負荷分散方式をサポートするようにします。

• gRPC リゾルバ グループを使用し、バランサー ピッカー ポリシーを実装して、複雑なバランシング作業をアップストリーム gRPC に委任します。

• gRPC 内部エラーを自動的に処理し、バックオフなどの高度な再試行ポリシーを有効にする gRPC インターセプタ チェーンに再試行を導入します。

PUT 要求のエラーを受信すると、ETCD クライアントはこの要求を 3 回再試行します。ETCD クライアントは、各再試行を 1 秒のタイムアウト後に実行します。ETCD クライアントは、3 回の再試行すべてを 3 秒以内に完了し、アプリケーションの既存の SLA を満たします。3 回の再試行の後、ETCD クライアントは結果をアプリケーションに返します。

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

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

フラグ DB データベースは、次の SMF プロシージャのために更新されます：

• ULI 変更のみの MBR：SMF は、応答を送信するステートレスな方法で、URI 変更のみの MBR を処理します。応答の送信後、smf サービスは CDL を更新します。これは、CPU 使用率に影響します。CPU 使用率を最適化するために、ULI については、部分的な更新でのみ SMF が CDL に通知します。

• 4G RAT ハンドオーバー：S-GW 間ハンドオーバー中に、smf サービスは ULI の変更と TEID の変更を含む MBR を受信します。CPU 使用率を最適化するために、SMF は、すべてのベアラーの引き継ぎが成功した場合、部分的なアップデートのみを使用してピア TEID と ULI について CDL に通知します。

• N2 ハンドオーバー：N2 ハンドオーバー手順が終了すると、smf-service は CPU 使用率に影響を与える CDL を更新します。CPU 使用率を最適化するために、SMF は既存のすべての QFI の引き継ぎが成功した場合、部分的なアップデートで ULI と TEID のみについて CDL に通知します。

無線リソース制御（RRC）は、5G NR プロトコル スタック内のレイヤです。コントロール プレーン、UE、gNB にのみ存在します。PDU セッションの既存の状態により、RRC の動作と機能が制御されます。

PCF によって開始された変更中に、AMF は、次の条件で、SmContextUpdate メッセージの N2 コンテンツに含まれる受信した失敗した転送無線ネットワーク原因コードを SMF に送信します。

• XN ハンドオーバーが進行中の場合。

• AN が解放された場合。

• UE が RRC 非アクティブ状態の場合。

• UE が到達不能な場合。

N2 原因コードを含む SmContextUpdate メッセージは、AMF から SMF、または SMF から AMF へのブリッジとコンバータとして機能します。

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

PCF によって開始された変更中に、Xn ハンドオーバーが進行中の場合、次のシナリオが通知されます。

• AN が解放されるか、UE が RRC 非アクティブ状態になっていて到達不能になっています。

• AMF は、 SmContextUpdate メッセージの N2 コンテンツで、受信した転送に失敗した無線ネットワークの原因コードを SMF にリレーします。

• これらの原因コードは、標準の無線ネットワークの原因である可能性もありますが、gNBから送信されたカスタマイズされた無線ネットワーク原因コードの可能性もあります。

以前は、これらの原因コードは SMF によって拒否され、PCF は同じ PCF の変更を複数回試行していました。SMF はすぐに拒否されず、PCF からの複数の再試行を回避するために、新しい N2 トリガー構成に基づいて、さまざまな原因コードに対して異なる動作をするようになりました。

受信した N2 原因コードに基づいて、PDU 変更手順の SMF では次のシナリオがサポートされます：

• 原因コードが Xn ハンドオーバーが進行中であることを示しているか、AN が解放された場合、次のアクティビティが発生します。

  • SMF は進行中の PDU セッションの変更を一時停止します。

  • Xn ハンドオーバーまたは AN リリース後に再開されます。

• 原因コードが、UE が RRC 非アクティブで到達不能であることを示している場合、次のアクティビティが発生します。

  • SMF が PDU セッションの変更を拒否します。

  • ルール違反を PCF に報告する。

デフォルトでは、この機能は、デフォルトのガードタイムアウトと最大再試行がゼロのいくつかの標準 RRC 非アクティブ原因コードに対してアクティブになります。

次の原因コードの場合、SMF はセッション変更を一時停止し、Xn-handover アクティビティが終了した後にのみセッション変更を再開します。

• _RadioNetwork_NG_intra_system_handover_triggers

• _RadioNetwork_NG_inter_system_handover_triggers

次の原因コードの場合、SMF はセッション変更を拒否します。

• _RadioNetwork_UE_in_RRC_INACTIVE_state_not_reachable

標準の原因コードとともに、新しい N2 トリガー CLI が導入され、さまざまなカスタマイズされた無線ネットワーク原因コードと対応する SMF アクションを構成できるようになりました。

（注）	非ローミング PCF によって開始された変更シナリオは、この機能の一部としてサポートされています。

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

config 
profile access access_profile_name 
    n2 trigger { ho-in-progress | temp-not-reachable } { guard-timeout timeout | max-retry retry_count | value retry_count_range } 
    n2 trigger ue-not-reachable value notreachable_count_range 
    end 

注：

• profile access access_profile_name ：アクセス プロファイルの名前を選択します。

• n2 trigger ：N2 トリガ タイプを指定します。[トリガ（Trigger）] はトラフィック タイプです。以下のいずれかである必要があります。

  • ho-in-progress ：原因コードのハンドオーバー進行中トリガ構成リストを指定します。

  • temp-not-reachable ：原因コードの一時的な到達不能トリガ構成リストを指定します。

  • ue-not-reachable ：原因コードの UE 到達不能トリガ構成リストを指定します。

• guard-timeout timeout ：Handover in progress ガードのタイムアウトを 500 ～ 30000 ミリ秒の範囲で指定します（ミリ秒単位）。デフォルト値は、10000 ミリ秒です。

• max-retry retry_count ：進行中のハンドオーバーまたは一時的に到達不能なオプションの最大再試行回数を 0 ～ 64 の範囲で指定します。デフォルト値は 0 です。

• value { notreachable_count_range } | { retry_count_range } ：最大再試行範囲の UE カウントの範囲の数値。

（注）

定義された構成は、受信した失敗した転送（無線ネットワーク標準およびカスタマイズ状態）を照合するために使用され、コードが RRC 非アクティブアクションを決定するようになります。シナリオは次のとおりです。 ue-not-reachable 、 ho-in-progress 、および temp-not-reachable の場合、PCF によって開始された変更は拒否されます。ANリリースにおける xn ハンドオーバー処理の後、一時停止され、その後再開されます。 RRC 非アクティブ アクションが ho-in-progress または temp-not-reachable トリガ プロファイルのいずれかにある場合、ガード タイマーが開始されます。進行中の PCF によって開始された変更が一時停止するのを待ちます。指定された時間内に AN リリースの xn ハンドオーバー アクティビティを再開します。このアクションが失敗すると、PCF によって開始された変更は拒否されます。その結果、このアクションはルール失敗メモとして PCF に報告されました。 最大再試行回数により、最初の試行が失敗した後、最大連続再試行回数を再試行できます。これは、試行ごとに同じトリガ カテゴリの原因コードを繰り返し受信した結果です。このアクションが失敗すると、PCF によって開始された変更は拒否されます。その結果、このアクションは、最大再試行回数に達した後、PCF にルール失敗メモとして報告されました。 この機能は、デフォルトのガード タイムアウトと最大再試行がゼロの標準 RRC 非アクティブ原因コードに対してアクティブになります。

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

• sgw-service ポッド

• smf-service ポッド

• gtpc-ep ポッド

• protocol ポッド

• diameter-ep ポッド

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

• 複雑なコール フローおよびコリジョン処理

• セッション状態に整合性がありません

• セッション状態に対する着信メッセージの不適切な処理

• 受信メッセージ内の予期しないコンテンツや未処理のコンテンツ

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

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

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

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

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

• クリーンアップ：障害が発生した場合、このアクションでは障害が発生しているサブスクライバ セッションをクリアし、コールを解放します。これは、 smf-service ポッドおよび sgw-service ポッドに適用されます。

• グレースフル リロード：障害が発生すると、このアクションはポッドを再起動します。これは、 gtpc-ep、 protocol、および diameter-ep ポッドに適用されます。障害信号を処理して、キープアライブ ポートなどのリソースをクリーンアップし、早期に閉じます。また、checkport スクリプトはポッドの状態を検出し、対応するポッドの VIP スイッチ処理を開始できます。

• リロード：ポッドがクラッシュすると、リロード アクティビティが開始されます。これは、すべてのポッドに適用されるデフォルトの設定または値です。

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

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

注：

• system-diagnostics { diameter | gtp | pfcp | service | sgw-service } ：システム診断に必要なサービス ポッドのタイプを指定します。使用可能なポッド オプションは、diameter、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 ：ポッドの正常なリロードのためのオプションを指定します。サービス ポッドは、障害信号を処理してキープアライブ ポートなどのリソースをクリーンアップし、クラッシュ処理（ポッド再起動処理）を続行します。

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

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

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