障害処理サポート

機能の概要と変更履歴

要約データ

表 1. 要約データ

該当製品または機能エリア

SMF

該当プラットフォーム

SMI

機能のデフォルト設定

無効:設定が必要

このリリースでの関連する変更点

N/A

関連資料

該当なし

更新履歴

表 2. マニュアルの変更履歴

改訂の詳細

リリース

原因コード 0 ~ 255 をサポートするように N4SessionModificationReq メッセージの既存の失敗処理の構成を拡張しました。

2021.02.3

N4SessionModificationReq メッセージの既存の失敗処理の構成を拡張し、事前定義された手順に基づいてセッション終了を制御する条件を含めました。

2021.02.3

次の要求メッセージの再送信のサポートが追加されました。

  • Namef_Communication EBI 割り当て要求

  • Namef_CommunicationN1N2 メッセージ転送要求

2021.02.2

PCF および UDM 構成の response-timeout コマンドに許容される範囲の値を追加しました

2021.02.0

RAT タイプ FHT のサポートとグレースフル タイムアウトの処理、および関連する統計情報が導入されました。

2021.01.0

最初の導入。

2020.02.0 より前

機能説明

システムは、エラー コードを回復可能なエラー コードと回復不可能なエラー コードに分離することにより、エラー処理を実行します。SMF が NF 登録、NF 更新、NF ハートビートなどのメッセージで NRF サーバから回復可能なエラーを受信すると、継続的な再試行でエンドポイントの回復を試みます。この機能は、課金機能(CHF)、ネットワーク リポジトリ機能(NRF)、ポリシー制御機能(PCF)、統合データ管理(UDM)とユーザー プレーン機能(UPF)などの NRF 連携動作と SMF およびその他のネットワーク機能との相互作用中に発生するエラーを柔軟に処理する方法を提供します。

この機能は、次の機能をサポートしています。

  • NRF と他の NF との相互作用中に発生する特定のエラー コードに対する構成可能な再試行アクション。

  • NRF 内のすべてのエンドポイントを再試行した後、エラー コードの再試行アクションを柔軟に決定できます。

  • profile nf-client-failure テンプレートの下にある CLI 構成を使用して、NRF メッセージのエラー コードと対応する再試行アクションを構成します。NRF のすべてのエンドポイントを再試行した後、エラー コードのフェールオーバー オプションを設定することもできます。

  • 他の NF の障害処理テンプレートで、HTTPv2 ステータス コード範囲のサポートを提供します。

アクセスおよびモビリティ管理機能の障害処理

機能説明

SMF はアクセスおよびモビリティ管理機能(AMF)の障害処理をサポートします。要求メッセージに基づいて、SMF は同じエンドポイントへの再送信をサポートします。

機能の仕組み

SMF は、次の要求メッセージの再送信サポートを提供します:

  • Namef_Communication EBI 割り当て要求

  • Namef_CommunicationN1N2 メッセージ転送要求

SMF が上記のメッセージに対する応答を受信しない場合、SMF は同じエンドポイントにメッセージを再送信します。SMF はこれらのメッセージをAMFに送信した後、内部に構成されたタイマーを開始します。SMF が AMF からの応答を受信した後、タイマーは停止します。応答の待機中にタイマーが期限切れになった場合、SMF は、再試行回数が設定された再試行メカニズムを使用します。

要求メッセージの再送信の構成

Namef_Communication EBI Assignment および Namef_Communication EBI Assignment メッセージの再送信を設定するには、次の構成例を使用します:

config 
   profile nf-client-failure nf-type amf  
      profile failure-handling failure_handling_name 
      service name type namf-comm  
         message type { AmfCommEBIAssignment | AmfCommN1N2MessageTransfer | AmfCommSMStatusChangeNotify } 
         status-code httpv2 status_code 
         retransmit retransmit_value 
         retransmit interval retransmit_interval_value 
         retry retry_value 
         action retry-and-continue 
      exit 
   exit 

注:

  • service name type namf-comm :AMF サービス名のタイプを「namf-comm」として指定します。

  • message type { AmfCommEBIAssignment | AmfCommN1N2MessageTransfer | AmfCommSMStatusChangeNotify } :namf-comm AMF サービス名タイプのメッセージ タイプを AmfCommEBIAssignment AmfCommN1N2MessageTransfer 、または AmfCommSMStatusChangeNotify として指定します。

  • status-code httpv2 status_code :サービスのステータス コードを指定します。 status_code は 0 ~ 599 の範囲の整数である必要があります。

  • retransmit retransmit_value :同じエンドポイントの最大再送信値を指定します。retransmit_value は、1 〜 10 の範囲の整数である必要があります。

    SMF がメッセージを送信して HTTP ステータス コードのエラーを受信した場合に、有効な再送信回数が設定されていれば、その回数の再送信が同じエンドポイントに対して行われます。最大再送信回数は、HTTP ステータス コードの初回設定から使用されます。

    SMF が再送信後も失敗エラーの HTTP コードを受信する場合、SMF は次の条件で同じエンドポイントに再送信します。

    • SMF が受信した最初の HTTP ステータス コードに有効な再送信回数が設定されている場合。

    • 受信した HTTP エラー コードの有効な再送信回数(ゼロであってはなりません)が存在する場合。

  • retransmit interval retransmit_interval_value :再送信間隔の値をミリ秒単位で指定します。デフォルト値は 1000 です。

    再送信間隔が構成されている場合、SMF は再送信間のタイムアウトを待ちます。

  • retry retry_value :使用可能な別のエンドポイントへの再試行回数を指定します。 retry_value は、1 〜 10 の範囲の整数である必要があります。

  • action retry-and-continue :構成された再試行回数に従って再試行回数を指定し、セッションを続行します。

設定例

次に、Namef_Communication EBI Assignment メッセージの再送信の構成例を示します:

config 
   profile nf-client-failure nf-type amf  
      profile failure-handling FHAMF  
      service name type namf-comm  
         message type AmfCommEBIAssignment  
         status-code httpv2 504  
         retransmit 1  
         retransmit interval 1000  
         retry 1  
         action retry-and-continue 
      exit 
   exit 

充電機能の失敗の処理

機能説明

Table 3. 機能の履歴
機能名

リリース情報

説明

料金設定グループおよびアプリケーション レベルでの CHF の失敗の処理

2024.01

SMF では、構成可能なアクションを定義して、アプリケーション エラーおよび料金設定グループ ID に関連付けられた障害を処理できます。

この機能により、新しい failure-handling error-type [ rg | app ] コマンドが課金プロファイル構成に導入されました。詳細については、 profilecharge failure-handling error-type コマンドを参照してください。

デフォルト設定:無効:構成が必要

SMF は、課金機能(CHF)サーバの障害処理をサポートしています。オンライン CHF サーバで障害が発生した場合、SMF はオフラインの CHF サーバに課金情報をリレーします。

課金情報のシームレスな転送のために、SMF は CHF 障害処理プロファイルに関連付けられた構成を呼び出します。障害処理を構成済みの場合、SMF は、別のプロファイルに構成されている、選択された CHF のセッションを続行します。

SMF は、次のレベルで課金機能(CHF)サーバの障害処理をサポートします。

  • HTTP レベルのステータス コード

  • アプリケーションレベルのエラー コード

  • 料金設定グループレベルの結果コード

アプリケーション エラーに対して以下のアクションを構成できます。

  • ドロップ データ:課金 ID に対応するドロップ データ。

  • 終了:PDU セッションを解放します。

  • 続行:課金を無効にします。

料金設定グループのエラーに対して以下のアクションを構成できます。

  • オフラインへの変換:オフライン課金に変換します。

  • フローの削除:料金設定グループに関連付けられているフローまたはルールを削除します。

  • ドロップ データ:料金設定グループに対応するトラフィックをドロップします。

  • 終了:PDU セッションを解放します。

構成がなければ、SMF はデフォルトの動作を続けます。デフォルトの動作については、表 5 および表 6 を 参照してください。

課金サーバーの選択方法については、このガイドの 「サブスクライバの課金」の章の 「CHF の選択」セクションを参照してください。

機能の仕組み

このセクションは、課金機能のオフライン フェールオーバー サポートの機能の仕組みを説明します。

CHF サーバ障害の処理

CHF サーバー障害は、選択した CHF が障害応答を送信するか、応答を送信しない場合に発生します。CHF サーバーの障害の場合、NF ライブラリは障害テンプレートに基づくステータ スコードを送信します。このテンプレートは、CHF ネットワーク プロファイルに関連付けられています。smf-service は、IPC メッセージの送信中にプロファイル情報を smf-rest-ep に送信します。

失敗テンプレートには、必要に応じて、HTTP エラーコードのリストと、関連する失敗アクションと再試行回数が設定されます。この機能は、機能不全発生時のアクションをサポートしています。

  • [再試行して続行(Retry and Continue)]:この失敗アクションの場合、NF ライブラリはフォールバック前に構成された回数だけ試行します。設定された回数が完了すると、NF ライブラリは優先順位の低い CHF サーバーの IP アドレスにフォールバックします。失敗した場合、または CHF サーバーから応答を受信しない場合は、「続行」アクションが smf サービスに返されます。

  • Terminate:この失敗アクションの場合、NF ライブラリは他の CHF サーバーにメッセージの送信を試みません。ライブラリは、アクションが「terminate」として、smf-service に応答を送信します。「terminate」の失敗アクションの場合、smf-service はセッションを削除します。

  • [続行(Continue)]:この失敗アクションでは、smf-service はセッションを続行し、オフライン CHF サーバーに課金メッセージを送信します。このサーバーは、オフライン用のローカル静的 CHF プロファイルの一部として構成されています。また、オフライン CHF の障害処理プロファイルを構成します。


Note


「続行」失敗アクションの場合は、別のプロファイルの SMF でオフライン CHF サーバーを構成できます。SMF は、CHF サーバーの障害発生後、このプロファイルを使用します。オフライン CHF サーバーが構成されていない場合、セッションは課金を課さずに続行されます。


オフライン CHF サーバへのリレー

CHF サーバで障害が発生した後、SMF が続行すると、進行中の課金サービスが次のように変換されます。

  • オンラインとオフラインの両方の課金方式を持つサービスをオフラインの課金方式に変換します。

  • オンライン課金方式のサービスをオフライン課金方式に変換します。

  • オフライン課金方式のサービスに変更はありません。

HTTP 原因コードと失敗アクションのマッピング

次の表に、関連する HTTP 原因コードと失敗アクションのマッピングを示します。ネットワーク要件に基づいて、マッピングを変更できます。

Table 4. HTTP 原因コードと失敗アクションのマッピング
HTTP-2 原因コードと説明 コンバージド CHF 障害時のアクション オフライン CHF 障害時のアクション
コード 説明 CDR-I CDR-U CDR T CDR-I CDR-U CDR T
400 Bad Request Terminate 構成なし 構成なし Terminate 構成なし 構成なし
403 Forbidden Terminate 構成なし 構成なし Terminate 構成なし 構成なし
404 見つかりません Terminate 構成なし 構成なし Terminate 構成なし 構成なし
405 メソッドは許可されていません 再試行して続行 再試行して続行 再試行して続行 Terminate 構成なし 構成なし
408 Request Timeout 再試行して続行 再試行して続行 再試行して続行 Terminate 再試行して続行 再試行して続行
500 Internal Server Error 再試行して続行 再試行して続行 再試行して続行 Terminate 再試行して続行 再試行して続行
503 Service Unavailable 再試行して続行 再試行して続行 再試行して続行 Terminate 再試行して続行 再試行して続行
508 ゲートウェイのタイムアウト(Gateway Timeout) 再試行して続行 再試行して続行 再試行して続行 Terminate 再試行して続行 再試行して続行
0 サーバからの応答がありません 再試行して続行 再試行して続行 再試行して続行 Terminate 再試行して続行 再試行して続行

アプリケーション エラー コードベースの障害処理

次の表に、アプリケーション エラー結果コードと関連する SMF 障害処理を示します。

表 5. アプリケーション エラー結果コードと SMF 障害処理アクションとのマッピング

アプリケーション エラー結果コード

SMF 障害処理アクション

CHARGING_NOT_APPLICABLE セッションの終了
END_USER REQUEST_DENIED セッションの終了
QUOTA_LIMIT_REACHED セッションのトラフィックをドロップする
END_USER_REQUEST_REJECTED セッションの終了

料金設定グループレベルの失敗の処理

下表に、料金設定グループレベルのエラー結果コードと、関連する SMF 失敗の処理アクションを示します。

表 6. SMF 失敗処理アクションとの評価グループ レベルのエラー結果コードのマッピング

料金設定グループ レベルのエラー結果コード

SMF 障害処理アクション

RATING_FAILED 料金グループに該当するトラフィックをドロップする
QUOTA_MANAGEMENT_NOT_APPLICABLE オフラインに変換
USER_UNKNOWN 無視

(注)  

 

SMF は、このアクションをセッション レベルでのみサポートします。

END_USER_SERVICE_DENIED 料金グループに該当するトラフィックをドロップする
QUOTA_LIMIT_REACHED 料金グループに該当するトラフィックをドロップする
END_USER_SERVICE_REJECTED 料金グループに該当するトラフィックをドロップする

コール フロー

ここでは、CHF 障害処理に関連するコール フローについて説明します。

5G フロー削除アクションのコール フロー

このセクションでは、セッションの 5G 削除フロー アクションのコール フローについて説明します。

図 1. 5G フロー削除アクションのコール フロー
表 7. 5G フロー削除アクションのコール フローの説明
ステップ 説明

1

サブスクライバは、5G で複数のフローで接続されます。

UPF は、N4 使用状況レポートを SMF に送信します。

2

SMF は N40 課金データ更新要求を CHF に送信します。

3

CHF が料金設定グループの N40 課金データ エラーを SMF に送信します。

(注)  

 

料金設定グループ エラーの削除フロー アクションを構成します。このアクションは、フローまたは、料金設定グループに関連したルールの削除に使用されています。

4

SMF は、ルールを削除するための N7 SM ポリシー更新を PCF に送信します。

5

SMF は、N1N2 転送要求を AMF に送信します。このリクエストは、N2 PDU セッション リソース変更リクエスト転送と N1 PDU セッション変更メッセージを含みます。

6

AMF は、N1N2 転送応答を SMF に送信します。

7

AMF が SMF に SM コンテキスト更新を送信します。この更新メッセージには、N2 PDU セッション リソース変更応答転送と N1 PDU セッション変更応答が含まれます。

8

SMF は、SM コンテキスト更新応答を AMF に送信します。

9

AMF が SMF に SM コンテキスト更新を送信します。この更新には、N1 PDU セッションの変更の完了に関する詳細が含まれます。

10

SMF は N4 セッション更新を UPF に送信します。このアップデートは、削除される PDR、FAR、URR、と QER についての詳細を含みます。

11

SMF は、SM コンテキスト更新応答を AMF に送信します。

(注)  

 

UPF は、削除済み URR の最終レポートを送信した場合、SMF は、CHF にこのアップデートを送信します。

12

SMF は N40 課金データ更新要求を CHF に送信します。

4G フロー削除アクションのコール フロー

このセクションでは、セッションの 4G 削除フロー アクションのコール フローについて説明します。

図 2. 4G フロー削除アクションのコール フロー
表 8. 4G フロー削除アクションのコール フローの説明
ステップ 説明

1

サブスクライバは複数のベアラーを使用して 4G で接続されます。

UPF は N4 使用状況レポートを SMF + PGW-C に送信します。

2

SMF + PGW-C は CHF に N40 課金データ更新要求を送信します。

3

CHF が料金設定グループの N40 課金データ エラーを SMF+PGW-C に送信します。

(注)  

 

料金設定グループ エラーの削除フロー アクションを構成します。このアクションは、フローまたは、料金設定グループに関連したルールの削除に使用されています。

4

SMF+PGW-C は、ルールを削除するための N7 SM ポリシー更新を PCF に送信します。

5

SMF+PGW-C は N4 セッション更新を UPF に送信します。このメッセージには、ドロップ アクションによる FAR の更新に関する詳細が含まれています。

6

SMF+PGW-C が S-GW にベアラー要求の削除を送信します。

7

S-GW がベアラー応答 SMF+PGW-C の削除を送信します。

8

SMF + PGW-C は PCF に N4 セッション更新を送信します。このアップデートは、削除される PDR、FAR、URR、と QER についての詳細を含みます。

(注)  

 

UPF は、削除済み URR の最終レポートを送信した場合、SMF は、CHF にこのアップデートを送信します。

9

SMF + PGW-C は CHF に N40 課金データ更新要求を送信します。

障害アクションに対する SMF の動作

次の表に、CDR-(I/U/T)でさまざまな失敗(続行、無視、終了)を受信した場合の SMF の動作を示します。

CHF 障害アクション

統合された CHF

オフライン CHF

CDR-I

CDR-U

CDR T

CDR-I

CDR-U

CDR T

続行(Continue)

CDR をオフライン CHF に送信します。オフライン CHF が設定されていない場合は、課金せずにセッションを続行します。

CDR をオフライン CHF に送信します。オフライン CHF が設定されていない場合は、課金せずにセッションを続行します。

オフライン CHF が設定されている場合は、CDR をオフラインCHFに送信します

課金せずにセッションを続行する

課金せずにセッションを続行する

セッションの続行

Terminate

セッションの削除

セッションの削除

セッションの削除の続行

セッションの削除

セッションの削除

セッションの削除の続行

[無視(Ignore)]

セッションの削除

アクションは実行されません。レコードは次の CDR 要求で再試行されます。

セッションの削除の続行

セッションの削除

アクションは実行されません。レコードは次の CDR 要求で再試行されます。

セッションの削除の続行

標準準拠

課金機能のオフライン フェールオーバー サポートは、次の標準に準拠しています。

  • 3GPP TS 32.255、バージョン 15.3.0

  • 3GPP TS 32.290、バージョン 15.4.0

  • 3GPP TS 32.291、バージョン 15.3.0

制限事項

課金機能のオフライン フェールオーバー サポートには、次の制限があります。

  • セッション レベルの制限はCHFから必須であるか、ローカルで構成する必要があります。3GPP 仕様によると、オンライン URR をオフライン URR からリンク解除する必要がある場合、最後にリンクされた URR は削除できません。

料金設定グループおよびアプリケーション レベルでの CHF 失敗の処理機能には、次の制限があります。

  • vSMF では、アプリケーション エラーの terminate アクションのみが適用されます。

  • drop-data アクションは、オンライン課金でのみサポートされます。

  • 複数の料金設定グループがエラーを返し、そのうちの 1 つに terminate アクションが構成されている場合、その PDU セッションは終了します。

  • 複数の料金設定グループがエラーを返し、デフォルトフローへの料金設定グループマッピングに delete-flow アクションが構成されている場合、その PDU セッションは終了します。

  • 複数の PCC ルールと料金設定グループが 1 つのフローにマッピングされている場合、 delete-flow アクションに構成されている料金設定グループ エラーにより、フロー全体が削除されます。

  • 1つのフローにマッピングされた複数の料金設定グループの場合、以下のシナリオでは、複数の料金設定グループが失敗します。

    • terminate アクションが構成されている場合、このアクションが最も優先されます。

    • delete-flow アクションと drop-data アクションの両方が構成されている場合、delete-flow アクションが優先されます。

    • convert-to-offline アクションと drop-data アクションの両方が構成されている場合、 drop-data アクションが優先されます。

CHF 障害処理の構成

ここでは、CHF 障害処理の構成方法について説明します。

この機能には、次の手順が含まれます:

  1. 障害処理プロファイルの構成

  2. オフライン サーバ クライアントとオフライン障害処理プロファイルの構成

障害処理プロファイルの構成

CHF 作成、更新、またはリリース メッセージの対応するアクションで HTTP ステータス コードを構成できます。障害処理プロファイルの構成に基づいて、CHF サーバーの障害が発生した場合、SMF はアクションを実行します。

失敗処理プロファイルを構成するには、次の構成例を使用します:

config 
   profile nf-client-failure nf-type chf 
      profile failure-handling fh_profile_name 
         service name type servicename_type 
            message type messagetype_value 
               status-code httpv2 statuscode_value  
                  action { continue | retry-and-continue | retry-and-ignore | retry-and-terminate } retry retry_value 
                  exit 

注:

  • profile nf-client-failure nf-type chf :NF クライアント障害後に必要なネットワーク機能の名前を指定します。

  • profile failure-handling fh_profile_name :障害処理のプロファイルの名を指定します。

  • service name type servicename_type :サービス タイプの名前を指定します。 CHF の servicename_type は 、次のいずれかの値です。

    • nchf-convergedcharging

    • nchf-spendinglimitcontrol

  • message type messagetype_value :メッセージのタイプの値を指定します。 messagetype_value は、CHF の次のいずれかになります:

    • ChfConvergedchargingCreate

    • ChfConvergedchargingUpdate

    • ChfConvergedchargingDelete

  • status-code httpv2 statuscode_value :構成された障害テンプレートに従って、ステータスコードを指定します。 statuscode_value は 、0 ~ 599 の範囲の整数である必要があります。ステータス コードの範囲には、区切り文字として - または ' を使用します。

  • action { continue | retry-and-continue | retry-and-ignore | retry-and-terminate } retry retry_value :障害アクションと再試行回数を指定します。 retry_value は 1 ~ 10 の範囲の整数である必要があります。

オフライン サーバ クライアントとオフライン障害処理プロファイルの構成

選択した CHF サーバに対してオフライン クライアント プロファイルとオフライン障害処理プロファイルを設定するには、次の設定例を使用します。

config 
   profile network-element chf chf_name 
      nf-client-profile nf_client_profile_name 
      failure-handling-profile fh_profile_name 
      nf-client-profile-offline offline_server_profile_name 
      failure-handling-profile-offline fh_profile_offline_name 
      exit 

注:

  • profile network-element chf chf_name :CHF サーバーの名前を指定します。

  • nf-client-profile nf_client_profile_name :NF クライアント プロファイル名を指定します。

  • failure-handling-profile fh_profile_name :障害処理プロファイル名を指定します。

  • nf-client-profile-offline offline_server_profile_name :オフライン サーバーの NF クライアントプロファイル名を指定します。

  • failure-handling-profile-offline fh_profile_offline_name :オフライン サーバーの障害処理プロファイル名を指定します。

グループレベルおよびアプリケーションレベルのエラーの評価に対するアクションの構成

料金設定グループレベルおよび アプリケーションレベルのエラーに対するアクションを構成するには、次の構成例を使用します。

config 
   profile charging profile_name 
      failure-handling error-type [ rg | app ] error-value error_value action action_value 
      exit 

注:

  • profile charging profile_name :課金プロファイル コンフィギュレーション モードを開始します。

  • failure-handling error-type [ rg | app ] error-value error_value action action_value :障害処理エラー タイプを料金設定グループまたはアプリケーションとしてエラー値で構成します。アプリケーションレベルのエラーの場合は、action_value に次のいずれかの値を入力します。

    • drop-data :この値を指定すると、課金 ID に対応するデータをドロップできます。

    • terminate :PDU セッションを解放するには、この値を指定します。

    • continue :課金を無効にするには、この値を指定します。

    料金設定グループレベルのエラーの場合は、 action_value に次のいずれかの値を入力します。

    • convert-offline :オフライン課金に変換するには、この値を指定します。

    • delete-flow :料金設定グループに関連付けられているフローまたはルールを削除するには、この値を指定します。

    • drop-data :料金設定グループに対応するデータをドロップするには、この値を指定します。

    • terminate :PDU セッションを解放するには、この値を指定します。


(注)  


  • 料金設定グループレベルとアプリケーションレベルのエラーに対するアクションをまだ構成していない場合、SMF はデフォルトの動作を続行します。

  • SMF では、ダイナミック ルールの同じ料金設定グループに複数の QoS フローをマッピングできません。

  • drop-data アクションは、料金設定グループに関連付けられているすべてのフローに適用されます。


ネットワーク リポジトリ機能障害処理

機能説明

ネットワーク リポジトリ機能(NRF)通信障害処理ロジックは、SMF 内に実装されています。SMF は、管理 NRF グループの動作ステータスを追跡するために NF 登録メッセージを使用します。

機能の仕組み

次の図は、SMF が NRF 障害を処理する方法を示しています。

上記の図では、NRF 1 がプライマリで、NRF 2 が SMF のセカンダリです。起動時に、SMF は NRF 1 に登録(NF 登録)し、NF ハートビートを NRF 1 と開始します。SMF はハートビート応答を使用して動作ステータスを追跡します。

SMF が NF ハートビート応答を欠落していることで NRF 1 の障害を検出した場合、SMF は NRF 2(セカンダリ NRF)に登録して NF ハートビートの送信を開始します。SMF は自身のステータスを追跡するために、NF 登録メッセージを NRF 1 に送信し続けます。

SMF は NRF 1 から登録応答を受信すると、NRF 1 が再び起動したことを検出します。SMF は、回復すると NRF 1 をアクティブとしてマークし、NF ハートビートの NRF 2 への送信を停止します。


(注)  


フェールオーバーおよびフォールバック時の NF 再登録(デフォルト動作)は、構成駆動型です。NRF 2 は、SMF がハートビートの送信を停止したことを検出すると、SMF インスタンス ID を使用したディスカバリを使用して SMF 登録を受信したかどうかを NRF 1 から確認します。


管理エンドポイント グループとディスカバリ エンドポイント グループは別であるため、登録ベースの動作ステータス チェックは NF ディスカバリ中の NRF 障害処理に使用されません。NF の検出中、グループ内の構成済みの NRF エンドポイントが優先順位で試行されます。

通話フロー

次の図は、NF 登録、NF 管理、および NRF 障害処理をカバーする基本的な NF 管理コール フローを示しています。

図 3. NF 管理コール フロー

NRF 障害処理の構成

このセクションでは、その他 NFの失敗の処理に必要な NRF の構成について説明します。

障害処理テンプレートの構成

失敗処理テンプレートを構成するには、次の構成例を使用します:

config 
   profile nf-client-failure { nf-type { amf | chf | nrf | pcf | udm } 
      profile failure-handling failure_handling_name 
      end 

注:

  • profile nf-client-failure { nf-type { amf | chf | nrf | pcf | udm } :必要な NF クライアント障害プロファイルを指定し、次の構成された NF のローカル構成のサポートを提供します。

    • amf :AMF ローカル構成を有効にします。

    • chf :CHF ローカル構成を有効にします。

    • nrf :NRF ローカル 構成を有効にします。

    • pcf :PCF ローカル 構成を有効にします。

    • udm :UDM ローカル 構成を有効にします。

      たとえば、選択した NF タイプが udm の場合、このコマンドは UDM のローカル構成を有効にします。他の構成済み NF に同じアプローチが適用されます。

  • profile failure-handling failure_handling_name :失敗処理プロファイル名を指定します。例えば、「udmFail」と入力します。

設定例

次に、NRF 障害処理プロファイルの構成例を示します:

group nf-mgmt NFMGMT1
   nrf-mgmt-group nrf-nfmgmt-grp
      failure-handling-profile FHNRF 
         locality       LOC1
            heartbeat interval 50
         exit

profile nf-client-failure nf-type nrf
   profile failure-handling FHNRF
      service name type nrf-nfm
         responsetimeout 2300
            message type NRFRegistration
               failover-enabled true 
               status-code httpv2 400,500
            action retry
         exit
         status-code httpv2 401,504
         action retry-next
      exit
   exit
message type NFUpdate
   failover-enabled true   
      status-code httpv2 400,503
   action retry
exit
status-code httpv2 411,500
   action retry-next
   exit
exit
message type Heartbeat
      re-registration-enabled true 
      status-code httpv2 400,429
   action retry
exit
         status-code httpv2 411,500
            action retry-next
          exit
        exit
     exit
  exit
exit

AMF 障害が発生した場合は、障害処理テンプレートで同じ retry-action と retry-count を使用して、エラー コードの範囲に次の構成例を使用します。


Note


他の NF の障害時にも同様の構成を使用できます。


profile nf-client-failure nf-type amf
 profile failure-handling FH1
  service name type namf-comm
   message type AmfCommEBIAssignment
    status-code httpv2 100,200,300,400-410
     retry  4
     action continue
    exit
   exit
  exit
 exit
 profile failure-handling FH2
  service name type namf-comm
   message type AmfCommEBIAssignment
    status-code httpv2 401
     retry  4
     action continue
    exit
   exit
  exit
 exit

profile failure-handling FH3
  service name type namf-comm
   message type AmfCommEBIAssignment
    status-code httpv2 250-260
     retry  4
     action continue
    exit
   exit
  exit
 exit
 profile failure-handling FH4
  service name type namf-comm
   message type AmfCommEBIAssignment
    status-code httpv2 100,200,300,400-410
     action continue
    exit
   exit
  exit
 exit
 profile failure-handling FH5
  service name type namf-loc
   message type AmfCommEBIAssignment
    status-code httpv2 150,160,170-175
     action continue
    exit
   exit
  exit
 exit
exit

次の構成は、DNN への失敗テンプレート マッピングの例です。

profile dnn intershat 
 network-element-profiles chf chf1 
 network-element-profiles amf amf1 
 network-element-profiles pcf pcf1 
 network-element-profiles udm udm1 
 ssc-mode 2 allowed [ 3 ] 
 session type IPV4 allowed [ IPV4V6 ] 
 upf apn intershat 
exit 

次の構成は、SMF への失敗テンプレート マッピングの例です。

profile smf smf1 
 node-id          12b888e1-8e7d-49fd-9eb5-e2622a57722 
 locality         LOC1 
 bind-address ipv4 209.165.202.129 
 bind-port        8008 
 fqdn             example.com.apn.epc.mnc456.mcc123 
 plmn-id mcc 123 
 plmn-id mnc 456 
exit 
 
profile network-element amf amf1 
 nf-client-profile        AMF-L1 
 failure-handling-profile FH1 
 query-params [ target-nf-instance-id ] 
exit 
profile network-element pcf pcf1 
 nf-client-profile        PCF-L1 
 failure-handling-profile FH1 
exit 
profile network-element udm udm1 
 nf-client-profile        UDM-L1 
 failure-handling-profile FH1 
exit 
profile network-element chf chf1 
 nf-client-profile        CHF-L1 
 failure-handling-profile FH2 
exit 
end 

障害処理の構成アクション

各 NF サービスとさまざまなメッセージタイプの失敗した再試行とアクションを構成するには、次の構成例を使用します。

config 
   profile nf-client-failure { nf-type { amf | chf | pcf | udm } 
   profile failure-handling failure_handling_name 
      service name type service_type 
         message type message_type 
            status-code httpv2 status_code  
            retry retry_count 
            action { continue | retry-and-continue | retry-and-terminate | terminate } 
            end 

注:

  • service name type service_type :構成された NF サービスの種類を指定し、以下の構成されたNFに対してローカル構成のサポートを提供します。サービス タイプは、構成されたサービスによって異なります。

    AMF サービスは、次のサービス タイプをサポートしています。

    • namf-comm

    • namf-evts

    • namf-loc

    • namf-mt

    CHF サービスは、次のサービス タイプをサポートしています。

    • nchf-convergedcharging

    • nchf-spendinglimitcontrol

    NRF サービスは、次のサービス タイプをサポートしています。

    • nrf-nfm

    PCF サービスは、次のサービス タイプをサポートしています。

    • npcf-am-policy-control

    • npcf-bdtpolicycontrol

    • npcf-eventexposure

    • npcf-policyauthorization

    • npcf-smpolicycontrol

    • npcf-ue-policy-control

    UDM サービスは、次のサービス タイプをサポートしています。

    • nudm-ee

    • nudm-pp

    • nudm-sdm

    • nudm-ueau

    • nudm-uecm

    たとえば、選択した service_type nudm-sdm の場合、このコマンドは UDM のローカル構成を有効にします。他の構成済み NF に同じアプローチが適用されます。

  • message type message_type :構成された NF メッセージ タイプを指定し、構成された NF のローカル構成のサポートを提供します。

    メッセージ タイプは、構成されたプロファイルとサービス タイプによって異なります。

  • status code httpv2 status_code :NF サービスのステータス コードと再試行アクションを指定します。現在、「http」ステータス コードのみが提供されます。 status_code は 0 ~ 599 の範囲の整数である必要があります。

  • retry retry_count :アクションを進める前に NF サービスが再試行する必要がある回数を指定します。 retry_count は 1 ~ 10 の範囲の整数である必要があります。

  • action :アクションを指定します。次のアクションがサポートされます。

    • continue :再試行せずにセッションを続行する場合に指定します。このアクションでは、再試行回数の構成は無効です。

    • retry-and-continue :構成された再試行回数に従って再試行回数を指定し、セッションを続行します。

    • retry-and-terminate :構成された再試行回数に従って再試行し、すべての再試行が失敗した場合はセッションを終了するように指定します。

    • terminate :再試行なしでセッションを終了する場合に指定します。このアクションでは、再試行回数の構成は無効です。

      メッセージ送信の再試行とアクションは、最初に送信したステータス コードの失敗に基づいて選択されます。再試行のステータス コードが異なる場合、新しい再試行回数やアクションが選択されることはありません。

次の表に、構成されたプロファイル、サービス、およびメッセージ タイプのオプションの例を示します。

プロファイル

サービス タイプ

メッセージ タイプ オプション

amf

namf-comm

  • AmfCommEBIAssignment

  • AmfCommN1N2MessageTransfer

  • AmfCommSMStatusChangeNotify

  • range

chf

nchf-convergedcharging

  • ChfConvergedchargingCreate

  • ChfConvergedchargingDelete

  • ChfConvergedchargingUpdate

  • range

nrf

nrf-nfm

  • ハートビート

  • NFUpdate

  • NRFRegistration

pcf

npcf-am-policy-control

  • PcfSmpolicycontrolCreate

  • PcfSmpolicycontrolDelete

  • PcfSmpolicycontrolUpdate

  • range

udm

nudm-sdm

  • UdmRegistrationReq

  • UdmSdmGetUESMSubscriptionData

  • UdmSdmSubscribeToNotification

  • UdmSubscriptionReq

  • UdmUecmRegisterSMF

  • UdmUecmUnregisterSMF

  • UdmSdmUnsubscribeToNotification

  • range


Note


この例は、各プロファイルおよびサービス タイプに提供されるすべてのメッセージ オプションを網羅しているわけではありません。


NRF 登録フェールオーバー オプションの構成

NRF 登録フェールオーバー機能を使用すると、ユーザーはすべてのエラー コードに対して再試行アクションを構成できます。アクションは、SMF やその他の NF との NRF の相互作用中に発生します。

すべてのホストまたはエンドポイントを試行した後、エラー コードの構成されているフェールオーバー オプションに基づいて次のアクションが決定されます。

NRF フェールオーバー機能を構成するには、次の構成例を使用します:

config 
   profile nf-client-failure nrf 
      profile failure-handling failure_handling_name 
         service name type nrf-nfm 
            message type { Heartbeat [ re-registration-enabled { false | true } ] | NFUpdate [ failover-enabled { false | true } ] | NRFRegistration [ failover-enabled { false | true } ] }  
               status-code httpv2 status_code  action { retry | retry-next } 
               end 

注:

  • message type { Heartbeat [ re-registration-enabled { false | true } ] | NFUpdate [ failover-enabled { false | true } ] | NRFRegistration [ failover-enabled { false | true } ] } :NRF メッセージ タイプを指定して、フェールオーバー機能を有効にします。

    NRF メッセージのフェールオーバー オプションは次のとおりです:

    • NRFRegistration または NFUpdate

      • true:NRF 内のすべてのホストまたはエンドポイントを試行した後、システムは次に使用可能な NRF を選択します。

      • false:NRF 内のすべてのホストまたはエンドポイントを試した後、次に使用可能な NRF は選択されません。

      バックアップ ルーチンの生成は、エンドポイントが試行された NRF でのみ使用できます。

    • ハートビート

      • true:再登録開始オプションが有効な場合、NRF 内のすべてのホストまたはエンドポイントで試行した後に、NF クライアントの再登録プロセスが開始されます。

      • false:NRF ですべてのホストまたはエンドポイントを試行した後、システムは同じ登録済み NRF でハートビート ルーチンを続行します。

  • status-code httpv2 status_code action { retry | retry-next } :NRF サービスのステータス コードと再試行アクションを指定します。現在、「http」ステータス コードのみが提供されます。 status_code は 0 ~ 599 の範囲の整数である必要があります。

    • 再試行:システムは同じエンドポイントまたはホストに対してもう一度再試行を試みます。

    • retry-next:システムは同じエンドポイントまたはホストを再試行しませんが、次に使用可能なエンドポイントまたはホストに対して再試行アクションを試みます。

  • NF 登録、NF ハートビート、および NF 更新のエラー処理は、ステータス コードに基づいています。この機能は、サブスクリプションおよび NF 登録解除メッセージでは使用できません。ユーザーは group nrf management 、 CLI で使用可能なエンドポイント構成を使用して、サブスクリプションおよび NF 登録解除メッセージの最大再試行回数を設定できます。システムはその構成に基づいて再試行アクションを試みます。

  • failover-enabled オプションは、NF 登録メッセージと NF 更新メッセージに適用できます。

  • reregistration-enabled オプションは、NF ハートビート メッセージに適用できます。

  • failover-enabled または reregistration-enabled オプションは、NF 登録解除メッセージには適用されません。

  • フェールオーバーと再登録のオプションは、デフォルトで有効になっています。

ネットワーク要素プロファイルの障害処理の構成

ネットワーク要素プロファイルの失敗処理を構成するには、次の構成例を使用します:

config 
   profile network-element { { amf | chf | pcf | udm } nf_profile_name } 
      failure-handling-profile profile_name 
      end 

注:

  • failure-handling-profile profile_name :構成された NRF の SCP 障害処理ネットワーク プロファイルを指定します。profile_name には、対応する NRF 障害処理ネットワーク プロファイル名を表す英数字の文字列を含める必要があります。

設定例

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

group nf-mgmt NFMGMT1
   nrf-mgmt-group nrf-nfmgmt-grp
      failure-handling-profile FHNRF 
         locality       LOC1
            heartbeat interval 50
         exit

profile nf-client-failure nf-type nrf
   profile failure-handling FHNRF
      service name type nrf-nfm
         responsetimeout 2300
            message type NRFRegistration
               failover-enabled true 
               status-code httpv2 400,500
            action retry
         exit
         status-code httpv2 401,504
         action retry-next
      exit
   exit
message type NFUpdate
   failover-enabled true   
      status-code httpv2 400,503
   action retry
exit
status-code httpv2 411,500
   action retry-next
   exit
exit
message type Heartbeat
      re-registration-enabled true 
      status-code httpv2 400,429
   action retry
exit
         status-code httpv2 411,500
            action retry-next
          exit
        exit
     exit
  exit
exit

AMF 障害が発生した場合は、障害処理テンプレートで同じ retry-action と retry-count を使用して、エラー コードの範囲に次の構成例を使用します。

profile nf-client-failure nf-type amf
 profile failure-handling FH1
  service name type namf-comm
   message type AmfCommEBIAssignment
    status-code httpv2 100,200,300,400-410
     retry  4
     action continue
    exit
   exit
  exit
 exit
 profile failure-handling FH2
  service name type namf-comm
   message type AmfCommEBIAssignment
    status-code httpv2 401
     retry  4
     action continue
    exit
   exit
  exit
 exit

profile failure-handling FH3
  service name type namf-comm
   message type AmfCommEBIAssignment
    status-code httpv2 250-260
     retry  4
     action continue
    exit
   exit
  exit
 exit
 profile failure-handling FH4
  service name type namf-comm
   message type AmfCommEBIAssignment
    status-code httpv2 100,200,300,400-410
     action continue
    exit
   exit
  exit
 exit
 profile failure-handling FH5
  service name type namf-loc
   message type AmfCommEBIAssignment
    status-code httpv2 150,160,170-175
     action continue
    exit
   exit
  exit
 exit
exit

NRF 障害処理の確認

NF 管理の障害処理

次に、管理 NRF エンドポイントの構成例を示します。

product smf# show running-config group nf-mgmt
group nf-mgmt MGM
 nrf-mgmt-group mgmt_group
 locality       LOC1
exit
product smf# show running-config group nrf mgmt
group nrf mgmt mgmt_group
 service type nrf nnrf-nfm
  endpoint-profile epprof
   uri-scheme http
   endpoint-name EP1
    priority 2
    primary ip-address ipv4 209.165.200.237
    primary ip-address port 8082
    secondary ip-address ipv4 209.165.200.238
    secondary ip-address port 8082
   exit
   endpoint-name EP2
    priority 10
    primary ip-address ipv4 209.165.200.237
    primary ip-address port 8082
    secondary ip-address ipv4 209.165.200.238
    secondary ip-address port 8082
   exit
  exit
 exit
exit
product smf#

構成例では、EP1 は優先順位が EP2 よりも低いため(2 対 10)、より優先順位の高いエンドポイント名です。起動時に、SMF は EP1 [209.165.200.235:8082] のプライマリ IP:ポートに NF 登録を送信します。プライマリがダウンしている場合、SMF は EP1 のセカンダリ ip:port を使用します。SMF は、EP1 のすべての ip: ポートがダウンしている場合にのみ、EP2 へのエンドポイントのフェールオーバーを実行します。

EP1 プライマリに正常に登録されると、SMF は EP1 プライマリとのハートビートを開始します。EP1 プライマリがダウンした場合、SMF はハートビート応答の欠落でダウンを検出します。EP1 プライマリがダウンしていることが検出されると、SMF は再登録せずに EP1 セカンダリにハートビートを送信します。また、プライマリ EP1 が回復したかどうかを検出するために、NF ハートビートを定期的にプライマリに送信します。

SMF が EP1 のプライマリおよびセカンダリがダウンしていることを検出すると、SMF は EP2 へのエンドポイントのフェールオーバーを実行します。EP2 プライマリへのフェールオーバーが成功すると、再登録を送信します(デフォルトの動作)。エンドポイント名を持つすべてのエンドポイントは同じデータベースを共有することが想定されているため、再登録はエンドポイント名にまたがるフェールオーバーの場合にのみサポートされます。この場合、EP1 プライマリとセカンダリは同じデータベースを共有します。同様に、EP2 のプライマリとセカンダリは別のデータベースを共有します。EP2 プライマリへのフェールオーバーでは、定期的な NF 登録が EP1 のプライマリにのみ送信されます(リカバリを検出するため)。

より優先順位の高いエンドポイント名が回復対象であることが検出されるたびに、SMF は回復された IP:ポートにフォールバックします。たとえば、現在アクティブな NRF エンドポイントが EP2 プライマリであり、SMF が EP1 プライマリが回復したことを検出すると、SMF は EP1 プライマリへの再登録を実行し(デフォルトの動作)、EP2 プライマリのハートビートを停止します。

エンドポイント内では、NF ハートビートを使用して動作ステータスを追跡する。エンドポイント全体で、登録を使用して動作ステータスを追跡する。要求メッセージのタイムアウト、RPC エラー、および HTTP 応答コード 408、429、500、501、502、503 は、次の NRF への移動の失敗と見なされます。

NF 検出の障害処理

以下は検出 NRF エンドポイント構成の例です。

product smf# show running-config profile nf-pair nf-type UDM
profile nf-pair nf-type UDM
 nrf-discovery-group others_group
 locality client LOC1
exit
product smf# show running-config group nrf discovery others_group
group nrf discovery others_group
 service type nrf nnrf-disc
  endpoint-profile ep1
   capacity 30
   priority 50
   uri-scheme http
   endpoint-name ED1
    priority 56
    primary ip-address ipv4 209.165.201.19
    primary ip-address port 8082
    secondary ip-address ipv4 209.165.201.20
    secondary ip-address port 8082
    exit
   endpoint-name ED2
    priority 10
    primary ip-address ipv4 209.165.201.21
    primary ip-address port 8082
    secondary ip-address ipv4 209.165.201.22
    secondary ip-address port 8082
   exit
  exit
 exit
exit
product smf#

サンプル構成では、ED1 の優先順位が ED2 よりも低いため(2 対 10)、ED1 の方が優先順位の高いエンドポイント名です。NRF ディスカバリが必要な場合は常に、ED1 [209.165.201.19:8082] のプライマリ IP:ポートが試行されます。SMF は、ED1 のセカンダリ ip:port を使用します(プライマリがダウンしている場合)。SMF は、ED1 のすべての ip: ポートがダウンしている場合にのみ、ED2 へのエンドポイントのフェールオーバーを実行します。NRF エンドポイントでの NRF 検出の失敗に関する状態は維持されていません。SMF は常に ED1 プライマリから開始し、障害が発生した場合は ED1 セカンダリにフォールバックし、次に ED2 プライマリにフォールバックします。

ポリシー制御機能の失敗の処理

機能説明

SMF は NF フェールオーバー サポートを利用して PCF フェールオーバー機能を実現します。

NF フェールオーバー機能は、次の機能をサポートしています:

  • プライマリ エンドポイントとセカンダリ エンドポイントとしてのサービスの複数のエンドポイント。エンドポイントは、NRF クライアント プロファイル構成および NRF 障害プロファイル構成を使用して構成できます。

  • 以下に基づく障害の動作:

    • メッセージの種類

    • 応答メッセージの HTTP ステータス コード

PCSCF プロファイルが構成されると、SMF は PDU のアクティベーションが IMS 向けで、IMS が PCF を必要とするものと想定します。その後、SMF は失敗処理の構成に関係なく PDU を拒否します。

  • SMF は、profile dnn の下に「pccf-profile」がある場合、失敗処理設定を無視して PDU の作成を拒否します。

  • オペレータは、同じ「profile dnn」で次のパラメータを構成できません:

    • pcf-interaction false

    • pcscf-profile

機能の仕組み

このセクションでは、SMF がメッセージ レベルの障害と、対応する HTTP ステータス コード ベースの障害を処理する方法について説明します。

SMF は、次のメッセージを開始します。

  • PcfSmpolicycontrolCreate

  • PcfSmpolicycontrolUpdate

  • PcfSmpolicycontrolDelete

PDU セッションのライフサイクル中の、SMF は、さまざまな段階でメッセージを PDF と交換します。NRF 障害プロファイルに構成された HTTP ステータス コードに応じて、SMF は次のいずれかのアクションを実行します:

  • [無視(Ignore)]

  • 続行(Continue)

  • Terminate

表 9. PCF フェールオーバー メッセージとアクションとの関係

PcfSmpolicy controlCreate

PcfSmpolicy controlUpdate

PcfSmpolicy controlDelete

[無視(Ignore)]

ローカルに構成された、または UDM が提供するポリシー パラメータを続行します。

(注)  

 

後続のメッセージについては PCF に問い合わせないでください。

PCF-Interaction Status: OFF

現在利用可能なポリシー パラメータのスナップショットを続行します。

後続のメッセージについては、PCF にお問い合わせください。

PCF-Interaction Status: ON

現在の障害を無視して、セッションを削除します。

PCF-Interaction ステータス:セッション削除

続行(Continue)

ローカルに構成された、または UDM が提供するポリシー パラメータを続行します。

(注)  

 

後続のメッセージについては PCF に問い合わせないでください。

PCF-Interaction Status: OFF

現在利用可能なポリシー パラメータのスナップショットを続行します。

(注)  

 

後続のメッセージについては PCF に問い合わせないでください。

PCF-Interaction Status: OFF

現在の障害を無視して、セッションを削除します。

PCF-Interaction ステータス:セッション削除

Terminate

セッションを終了します。

セッションを終了します。

セッションを終了します。

PCF インタラクション ステータス

この機能は、SMF 開始メッセージと PCF 開始メッセージに対して次のステータス メッセージをサポートします。

  • PCF-Interaction Status: ON

    SMF 開始のメッセージ:SMF は、基準が満たされるたびに、PCF へのメッセージを開始し続けます。

    PCF によって開始されたメッセージ:SMF は、PCF から SMF へのすべてのメッセージを受け入れ続けます。

  • PCF-Interaction Status: OFF

    SMF 開始のメッセージ:SMF は、基準が満たされるたびに、PCF 向けのメッセージを開始したり、送信したりしません。SMF は PCF を利用できないものとして扱い、さらにアクションを続行します。

    PCF 開始メッセージ:PCF によって開始されるメッセージは 2 つあります。

    • SmPolicyUpdateNotifyReq:このメッセージを受信すると、SMF は応答で 404 エラーコードを送信し、セッションをクリーンアップして、削除要求を PCF に送信しません。


      (注)  


      また、SMF は、FIVEG_PDU_SESSION_RELEASE_COMMAND 内に REACTIVATION REQUESTED として FIVEGSM_CAUSE 値を 5G の UE に送信します。4G の場合、SMF は DELETE BEARER REQUEST メッセージで REACTIVATION REQUESTED を S-GW に送信します。


    • SmPolicyAssociationTerminationReq:このメッセージを受信すると、SMF は成功応答を送信し、セッションをクリーンアップします。この連携の一環として、SMF は PCF に削除要求を送信します。


      (注)  


      これは、[PCF-Interaction ステータス(PCF-Interaction Status)] が [オフ(OFF)] に設定されている場合の例外です。


PCF 障害処理機能の構成

ここでは、PCF 障害処理機能の構成方法について説明します。

PCF 障害処理機能の構成には、次の手順が含まれます:

PCF 障害処理プロファイルの構成

アクションを使用して PCF 障害処理プロファイルを構成するには、次の構成例を使用します:

config 
   profile nf-client-failure nf-type pcf 
      profile failure-handling fhprofile_name 
         service name type servicename_type 
            message type messagetype_value 
               status-code httpv2 status_code 
               action { continue | retry-and-continue | retry-and-ignore | retry-and-terminate } retry retry_value 
               exit 

注:

  • profile failure-handling fhprofile_name :障害処理プロファイル名を指定します。

  • service name type servicename_type :PCF サービス名のタイプを指定します。 servicename_type は 、次のいずれかの値です。

    • npcf-am-policy-control

    • npcf-bdtpolicycontrol

    • npcf-evenxposure

    • npcf-policy authorization

    • npcf-smpolicycontrol

    • npcf-ue-policy-control

  • message type messagetype_value :メッセージ タイプを指定します。 messagetype_value には、次のいずれかの値を指定できます。

    • PcfAmfPolicyControlCreate

    • PcfSmpolicycontrolCreate

    • PcfSmpolicycontrolDelete

    • PcfSmpolicycontrolUpdate

  • status-code httpv2 status_code :HTTPv2 ステータス コードを指定します。 status_codeは 、「-」または「,」で区切られた0〜599の範囲の整数である必要があります。

  • action { continue | retry-and-continue | retry-and-ignore | retry-and-terminate } retry retry_value :アクションと再試行回数を指定します。 retry_value は 1 ~ 10 の範囲の整数である必要があります。

障害処理プロファイルの 関連付けの構成

PCF で FH プロファイルの関連付けを構成するには、次の構成例を使用します:

config 
   profile network-element pcf pcf_profile_name 
      nf-client-profile nf_profile_name 
      failure-handling-profile fh_profile_name 
      exit 

注:

  • nf-client-profile nf_profile_name :NF クライアントプロファイル名を指定します。

  • failure-handling-profile fh_profile_name :障害処理プロファイル名を指定します。

セカンダリおよびターシャリ IP アドレスの構成

セカンダリ IP アドレスとターシャリ IP アドレスを構成するには、次の構成例を使用します:

config 
   profile nf-client nf-type pcf 
      pcf-profile pcfprofile_name 
         locality locality_name 
            service name type npcf-smpolicycontrol 
               endpoint-profile endpointprofile_name 
                  endpoint-name endpoint_name 
                     primary ip-address { ipv4 primary_ipv4_address | ipv6 primary_ipv6_address | port primary_port_number } 
                     secondary ip-address { ipv4 secondary_ipv4_address | ipv6 secondary_ipv6_address | port secondary_port_number } 
                     tertiary ip-address { ipv4 tertiary_ipv4_address | ipv6 tertiary_ipv6_address | port tertiary_port_number } 
                     end 

注:

  • primary ip-address ipv4 primary_ipv4_address :プライマリ エンドポイントの IPv4 アドレスを指定します。

  • primary ip-address ipv6 primary_ipv6_address :プライマリ エンドポイントの IPv6 アドレスを指定します。

  • primary ip-address port primary_port_number :プライマリ エンドポイントのポート番号を指定します。

  • secondary ip-address ipv4 secondary_ipv4_address:セカンダリ エンドポイントの IPv4 アドレスを指定します。

  • secondary ip-address ipv6 secondary_ipv6_address :セカンダリ エンドポイントの IPv6 アドレスを指定します。

  • secondary ip-address port secondary_port :セカンダリ エンドポイントのポート番号を指定します。

  • tertiary ip-address ipv4 tertiary_ipv4_address :ターシャリ エンドポイントの IPv4 アドレスを指定します。

  • tertiary ip-address ipv6 tertiary_ipv6_address :ターシャリ エンドポイントの IPv6 アドレスを指定します。

  • tertiary ip-address port tertiary_port_number :ターシャリ エンドポイントのポート番号を指定します。

PCF 障害処理に対する OAM サポート

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

バルク統計サポート

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

  • PcfSmpolicyControlCreate

    • 無視した応答の数

    • 続行した応答の数

    • 終了した応答の数

  • PcfSmPolicyControlUpdate

    • 無視した応答の数

    • 続行した応答の数

    • 終了した応答の数

  • PcfSmpolicyControlDelete

    • 無視した応答の数

    • 続行した応答の数

    • 終了した応答の数

  • PolicyUpdateNotifyReq

    • 承認された要求の数

    • 承認された要求の数

    • スキップされた要求の数

  • PolicyDeleteReq

    • 承認された要求の数

    • 承認された要求の数

    • スキップされた要求の数

  • PolicyUpdateRequest

    • 承認された要求の数

    • 承認された要求の数

    • スキップされた要求の数

  • ポリシー タイプが local/pcf であるサブスクライバの数のゲージ カウンタ。

統合データ管理の失敗の処理

機能説明

統合データ管理(UDM)は主にサブスクライバ データを保存する役割を果たし、SMF はネットワーク上のユーザー セッションを管理するためにこのデータにアクセスします。

SMF での UDM 障害処理のサポートでは、新しい障害処理テンプレート(FHT)プロファイルが導入されています。このプロファイルは、SMF の UDM プロファイルに関連付けられています。

FHT テンプレートにより、SMF はセッションの N10 を介して UDM との相互作用を柔軟に微調整できます。これは、新しいセッションと既存の両方のセッションについて、UDM からの応答で HTTP ステータス コードを処理する SMF をサポートしています。

NF フェールオーバーのサポートは、NF クライアントプロファイル設定と NF 障害プロファイル構成を使用して SMF で利用できます。この機能は、次の機能をサポートしています。

  • サービスの複数のエンドポイントをプライマリ エンドポイントとセカンダリ エンドポイントとして構成します。

  • 次に基づいて失敗の処理動作を指定します:

    • メッセージの種類

    • 応答メッセージの HTTP ステータス コード

機能の仕組み

SMF は NF フェールオーバーを使用して、UDM フェールオーバー サポート機能を実現します。このセクションでは、SMF がメッセージ レベルの障害と、対応する HTTP ステータス コード ベースの障害を処理する方法について説明します。

SMF は、次のメッセージを開始します。

  • UE-Connection-Management(UE-CM)

    • Nudm_UECM_Registration

    • Nudm_UECM_DeRegistration

  • UE-Subscription-Management (UE-SDM)

    • Nudm_SDM_Get

    • Nudm_SDM_Subscribe

    • Nudm_SDM_Unsubscribe

PDU セッションのライフサイクル中の、SMF は、さまざまな段階で上記のメッセージを UDM と交換します。NF 障害プロファイルに構成された HTTP ステータス コードに応じて、SMF は次のいずれかのアクションを実行します。

  • [無視(Ignore)]

  • 続行(Continue)

  • Terminate

SMF では、他の使用可能な UDM サーバに対して同じ要求を試行するための次のアクションが提供されます。

  • retry-and-terminate

  • retry-and-ignore

  • retry-and-continue

すべての再試行が失敗すると、SMF は適切な失敗処理アクションを実行します。たとえば、FH アクションが retry-and-terminate の場合、SMF はすべての試行が失敗した後に通話を終了します。


(注)  


SMF では、障害処理テンプレートの構成をダイナミックに変更できます。構成への変更が新規コールにのみ適用されます。


表 10. N10 メッセージとフェールオーバー アクションとの関係

シナリオ

サービス

メッセージ

条件

操作

成功の応答

障害敗応答の処理

Terminate

続行(Continue)

[無視(Ignore)]

5G、4G、および Wi-Fi での PDU セッションの作成手順

RAT 間ハンドオーバーの手順

UECM

Nudm_

UECM

_Registration

Nudm UECM 登録が完了しておらず、アクセス タイプが 4G でない場合

メッセージを送信する

登録が成功したことをマークする

コールの終了

通話を続行する

通話を続行する

Nudm_UECM_

登録解除

Nudm UECM 登録が完了した場合

メッセージを送信する

アクションなし

コールの終了

コールの終了

コールの終了

5G、4G、および Wi-Fi での PDU セッションの作成手順

SDM

Nudm_SDM_Get

サブスクリプション取得構成をスキップした場合は有効になっていません

メッセージを送信する

サブスクリプションの取得が成功したことをマークします

コールの終了

通話を続行する

通話を続行する

Nudm_

SDM

_Subscribe

サブスクリプションの取得が成功した場合

メッセージを送信する

アクションなし

コールの終了

サブスクリプションが完了していない場合に通話を続行

サブスクリプションが完了していない場合に通話を続行

5G、4G、および Wi-Fi での PDU セッションのリリース手順

SDM

Nudm_SDM

_Unsubscribe

サブスクリプションの取得が成功し、登録が完了していない場合

メッセージを送信する

アクションなし

コールの終了

通話を続行する

通話を続行する

  • 終了:SMF は任意のメッセージ タイプの通話を終了します。

  • 続行:SMF は現在の障害を無視し、同じサービス グループ内の他のメッセージに対する後続の操作をスキップします。

  • 無視:SMF は現在のインタラクションの失敗のみを無視してコールを続行します。SMF は、後続のメッセージのインタラクションを処理します。

  • UDM サブスクリプション取得は、EPS および NR ネットワークでのセッション確立中にのみ実行してください。

    UDM サブスクリプションの取得が失敗し、FH アクションが「無視」であるか、または通知への登録をスキップする構成が有効になっている場合、SMF は通知への登録の相互作用をスキップします。

  • UDM 障害処理テンプレートが構成されていない場合、デフォルトの障害処理アクションは「終了」です。

UDM 障害処理機能の構成

このセクションでは、UDM 障害処理機能の構成方法について説明します。

UDM 障害処理機能の構成には、次の手順が含まれます:

UDM 障害処理プロファイルの構成

次の構成例を使用して、アクションを使用して UDM 障害処理プロファイルを構成します。

config 
   profile nf-client-failure nf-type udm 
      profile failure-handling fh_profile_name 
         service name type { nudm-ee | nudm-pp | nudm-sdm | nudm-ueau 
         | nudm-uecm } 
         message type { UdmRegistrationReq | UdmSdmGetUESMSubscriptionData 
         | UdmSdmSubscribeToNotification | UdmSubscriptionReq 
         | UdmUecmRegisterSMF | UdmUecmUnregisterSMF |  
         UdmSdmUnsubscribeToNotification } 
            status-code httpv2 0 
               action { continue | retry-and-continue | retry-and-ignore 
              | retry-and-terminate | terminate } 
              end 

FH プロファイルの関連付けの構成

UDM で FH プロファイルの関連付けを構成するには、次の構成例を使用します:

config 
   profile network-element udm udm_profile_name 
      nf-client-profile nf_profile_name 
      failure-handling-profile fh_profile_name 
      failure-handling-profile-rat nr 
         failure-handling-profile fh_profile_name 
         exit 

注:

  • failure-handling-profile-rat nr :RAT タイプに固有の失敗処理プロファイルを指定します。

  • failure-handling-profile fh_profile_name :障害処理ネットワークプロファイル名を指定します。 fh_profile_name は 文字列である必要があります。

RAT ベースの FH プロファイルの確認

このセクションでは、UDM で RAT ベースの FH プロファイルを確認する方法について説明します。

show running-config profile network-element udm udm_profile_name コマンドを使用して、機能構成の詳細を確認します。

次に出力例があります。

nf-client-profile UP1
   failure-handling-profile FH1
   failure-handling-profile-rat nr
      failure-handling-profile FH4
      exit
exit

この例では、FH1 がデフォルトの障害処理プロファイルです。ただし、RAT タイプが nr に構成されている場合は、障害処理プロファイル FH4 が使用されます。

セカンダリおよびターシャリ IP アドレスの構成

セカンダリ IP アドレスとターシャリ IP アドレスを構成するには、次の構成例を使用します:

config 
   profile nf-client nf-type udm 
      udm-profile udmprofile_name 
         locality LOC 
            service name type { nudm-ee | nudm-pp | nudm-sdm | nudm-ueau | nudm-uecm } 
               endpoint-profile epprofile_name 
                  endpoint-name endpoint_name 
                     primary ip-address { ipv4 primary_ipv4_address | ipv6 primary_ipv6_address | port primary_port_number } 
                     secondary ip-address { ipv4 secondary_ipv4_address | ipv6 secondary_ipv6_address | port secondary_port_number } 
                     tertiary ip-address { ipv4 tertiary_ipv4_address | ipv6 tertiary_ipv6_address | port tertiary_port_number } 
                     end 

注:

  • primary ip-address ipv4 primary_ipv4_address :プライマリ エンドポイントの IPv4 アドレスを指定します。

  • primary ip-address ipv6 primary_ipv6_address :プライマリ エンドポイントの IPv6 アドレスを指定します。

  • primary ip-address port primary_port_number :プライマリ エンドポイントのポート番号を指定します。

  • secondary ip-address ipv4 secondary_ipv4_address:セカンダリ エンドポイントの IPv4 アドレスを指定します。

  • secondary ip-address ipv6 secondary_ipv6_address :セカンダリ エンドポイントの IPv6 アドレスを指定します。

  • secondary ip-address port secondary_port :セカンダリ エンドポイントのポート番号を指定します。

  • tertiary ip-address ipv4 tertiary_ipv4_address :ターシャリ エンドポイントの IPv4 アドレスを指定します。

  • tertiary ip-address ipv6 tertiary_ipv6_address :ターシャリ エンドポイントの IPv6 アドレスを指定します。

  • tertiary ip-address port tertiary_port_number :ターシャリ エンドポイントのポート番号を指定します。

応答タイムアウトパラメータの構成

UDM インターフェイス(N10)を介したフェールオープンサポートの応答タイムアウトを構成するには、次の構成例を使用します:

config 
   profile network-element udm udm_profile_name 
      response-timeout timeout_value 
      exit 

注:

  • response-timeout timeout_value :応答のタイムアウトをミリ秒単位で指定します。 timeout_value は 1000 ~ 30000 の範囲の整数である必要があります。

    デフォルト:4000

応答タイムアウトの構成の確認

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

[unknown] smf# show running-config profile network-element udm
profile network-element udm udm1
nf-client-profile UP1
failure-handling-profile FH4
query-params [ dnn ]
response-timeout 2000
exit
[unknown] smf#

統計

次の統計情報は、すべての UDM サービスとメッセージの組み合わせについて、ステータスが試行/成功/スキップ/失敗のすべての UDM メッセージステータスに対してサポートされています。

udm_msg_processing_status{app_name="SMF",cluster="Local",data_center="DC"
,instance_id="1",msg_status="attempted",rat_type="nr",service_name="smfservice",
udm_end_point="",udm_msg="UdmSmSubscription”} 1
udm_msg_processing_status{app_name="SMF",cluster="Local",data_center="DC",
instance_id="1",msg_status="skipped",rat_type="nr",service_name="smfservice",udm_end_point="",
udm_msg="UdSmSubscription"} 1

UDM 障害処理機能の OAM サポート

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

バルク統計サポート

SMF は、UDM 障害処理機能のサポートで、以下の統計情報を保持します。

  • Nudm_UECM_Registration

    • 無視した応答の数

    • 続行した応答の数

    • 終了した応答の数

  • Nudm_UECM_DeRegistration

    • 無視した応答の数

    • 続行した応答の数

    • 終了した応答の数

  • Nudm_SDM_Get

    • 無視した応答の数

    • 続行した応答の数

    • 終了した応答の数

  • Nudm_SDM_Subscribe

    • 無視した応答の数

    • 続行した応答の数

    • 終了した応答の数

  • Nudm_SDM_Unsubscribe

    • 無視した応答の数

    • 続行した応答の数

    • 終了した応答の数

smf-serviceの「udm_msg_processing_status」統計は、ステータスが [試行(Attempted)]、[成功(Success)]、[スキップ(Skipped)]、および [失敗(Failed)] の UDM メッセージの数を追跡します。

例:

udm_msg_processing_status
{app_name="SMF",cluster="Local",data_center="DC",instance_id="1",msg_status="attempted",
rat_type="nr",
service_name="smf-service",udm_end_point="",udm_msg="UdmSmSubscription"} 1
udm_msg_processing_status
{app_name="SMF",cluster="Local",data_center="DC",instance_id="1",msg_status="skipped",
rat_type="nr",
service_name="smf-service",udm_end_point="",udm_msg="UdSmSubscription"} 1

ユーザー プレーン機能障害の処理

ユーザー プレーン機能(UPF)の障害処理により、SMF は、新しいセッションと既存のセッションの両方中に、UPF の応答で受信したエラー原因コードを管理できます。SMF は、パケット転送制御プロトコル(PFCP)PFCP の障害処理テンプレート(FHT)プロファイルを提供します。このプロファイルは、SMF の UPF プロファイルに関連付けられています。FHT テンプレートにより、SMF はセッション中に UPF との相互作用を柔軟に微調整できます。

FHT でサポートされている構成可能なアクション

この機能は、UPF からの応答で受信したエラー原因コードに基づいて、構成可能なアクションを提供します。

  • ignore

  • terminate

  • continue

  • 再試行終了

  • retry-ignore

  • retry-continue

UPF 障害処理方法

Workflow

UPF 障害処理プロセスの段階は次のとおりです。

  1. セッションの確立中に UPF が輻輳している場合、UPF は SMF からの PFCP 確立メッセージを拒否します。

  2. UPF は、応答メッセージで原因コードを SMF に送信します。

  3. SMF はユーザー定義の障害処理テンプレートをチェックします。テンプレートで再試行が構成されている場合、SMF はコール損失を減らすために PFCP 確立メッセージの別の UPF への送信を再試行します。

  4. SMF は構成された優先順位の値とキャパシティ(UPF からの負荷情報)に基づいて UPF を選択します。

  5. SMF は FHT でのユーザー定義のアクションに基づいて、セッションを無視、終了、または続行します。

UPF 障害処理を有効にする

UPF 障害処理機能を有効にするには、次の手順を実行します。

手順


ステップ 1

UPF 障害処理プロファイルを構成します

ステップ 2

障害プロファイルの関連付けを構成します


UPF 障害処理プロファイルの構成

グローバル コンフィギュレーション モードで UPF 障害処理プロファイルを構成します。

手順

ステップ 1

障害処理プロファイルを作成するプロファイル名を指定します。

profile failure-handling fh_profile_name

例:

[smf] smf# config 
[smf] smf(config)# profile failure-handling  fh1 

ステップ 2

障害処理を構成する PFCP メッセージ タイプを指定します。

例:

[smf] smf# config 
[smf] smf(config-failure-handling-fh1)#  interface pfcp message N4SessionModificationReq  
  • N4SessionEstablishmentReq:N4SessionEstablishmentReq(新しいセッションの場合)、N4SessionModificationReq メッセージ(既存のセッションの場合)、および N4 セッション レポート要求の失敗処理を指定します。

  • N4SessionModificationReq:既存のセッションの障害処理メッセージを指定します。

  • N4SessionReportReq:セッション レポートの失敗処理メッセージを指定します。

    N4SessionReportReq キーワードが構成されている場合、SMF はセッション削除要求をトリガし、その後セッション レポートの拒否をトリガします。UPF は削除要求に応答し、セッションをクリアします。

(注)  

 

セッションが UPF ですでにアクティブであるため、UPF の再選択はメッセージ タイプ N4SessionModificationReq には適用されません。

ステップ 3

SMF が UPF からの障害応答メッセージで受信する原因コードを指定します。

cause-code cause_ID

例:
 [smf] smf(config-failure-handling-fh1)#  cause-code  pfcp-entity-in-congestion  
表 11. 原因コード

原因(Cause)コード

説明

  • pfcp エンティティの輻輳

  • peer-overload-reduction

  • pfcp-entity-in-congestion :UPF が輻輳している場合は、この原因コードを指定します。

  • peer-overload-reduction :このオプションを指定すると、OCI で受信したピアの過負荷削減のために N4 メッセージをドロップしながら、SMF 上のセッションをクリアできます。

  • システム障害

  • サービスがサポートされていない

    session-ctx-not-found

  • system-failure :メッセージ処理中の内部またはシステム障害の原因コードを指定します。

  • service-not-supported :サービスがサポートされない場合は、この原因コードを指定します。

  • session-ctx-not-found: メッセージで参照されているセッション コンテキストが存在しない場合に、この原因コードを指定します。

  • リソースなし(no-resource-available)

  • 応答を受信しませんでした

  • no-resource-available :使用可能なリソースがない場合に、この原因コードを指定します。

  • no-response-received :このオプションを指定して、SMF が UPF からの応答を受信しないシナリオを決定します。

拒否 この原因コードを指定すると、UPF からの障害応答メッセージ内の原因コードを処理します。原因コードは、この機能で使用可能な CLI コマンドを使用して構成されません。
mandatory-ie -incorrect 受信したメッセージに無効なデータが含まれている場合は、この原因コードを指定します。
  • 74

  • 2–255

  • 74 :SMF が UPF から原因コード 74 を受信し、かつ N4 障害処理プロファイルで原因コード 74 のアクション終了と構成されている場合、SMF はセッションを削除します。

  • 2–255 :複数の原因コードを指定する場合は、原因コード値を「-」または「,」のいずれか、または両方を使用して区切ります。たとえば、原因コード 72-74、76、78-100 です。

原因コード 0 ~ 255 がサポートされています。原因コードの優先順位は次のとおりです:

  1. 定義済みの文字列

  2. 番号

  3. 範囲

  4. 却下

(注)  

 

拒否がデフォルトの原因コードです。

表 12. 原因コードの構成

原因(Cause)コード

設定

0–63

対応するテンプレート構成

64-255

却下

FHT は、デフォルトの動作で構成されている以下の原因コードをサポートしていません:

  • request-reject-unspecified

  • cond-ie-missing

  • invalid-length

  • invalid-fw-policy

  • invalid-fteid-alloc-opt

  • no-established-pfcp-assoc

  • rule-creation-mod-failure

ステップ 4

障害処理の条件とアクションを構成します。

action {ignore | retry-terminate { max-retry retry_value } [condition { handover-execution | handover-preparation modify | idft | handover-cancel }]

例:
 [smf] smf(config-failure-handling-fh1)#  cause-code  pfcp-entity-in-congestion action  terminate   condition handover-execution 

condition コマンドの構成は任意です。

表 13. 構成マトリックス

メッセージ タイプ

適用可能なアクション

該当する原因コード

デフォルトの動作

N4Session EstablishmentReq

retry-terminate max-retry retry_value
  • pfcp エンティティの輻輳

  • peer-overload-reduction

  • システム障害

  • サービスがサポートされていない

  • リソースなし(no-resource-available)

  • 応答を受信しませんでした

  • 拒否

  • 74

terminate

N4Session ModificationReq

terminate

  • peer-overload-reduction

  • mandatory-ie -incorrect

  • session-ctx-not-found

  • no-response -received

  • 拒否

  • no-resource -available

  • 74

continue

N4SessionReportReq

  • ignore

  • terminate

2-255

terminate

表 14. 構成可能なアクション

アクション

説明

retry-terminate max-retry retry_value

代替 UPF への再試行回数を指定します。再試行が失敗した場合、セッションは終了します。再試行値の範囲は 1 ~ 5 です。デフォルト値は 2 です。

(注)  

 

すべての UPF が輻輳状態の場合、アクションが続行に設定されていても、コールは失敗します。

terminate

セッションを終了するようにアクションを指定します。

ignore

セッションを無視するようにアクションを指定します。

  • SMF は、N4SessionModificationReq メッセージ タイプの障害処理に対してのみ、1 つ以上の条件を構成することを許可します。。

ステップ 5

(オプション) show running-config profile failure-handling interface pfcp コマンドを使用して、UPF 障害処理構成を確認します。


[smf] smf# show running-config profile failure-handling interface pfcp
 profile failure-handling fh1
 interface pfcp message N4SessionEstablishmentReq
  cause-code pfcp-entity-in-congestion action retry-terminate max-retry 2
  cause-code system-failure action terminate
  cause-code service-not-supported action terminate
  cause-code no-resource-available action retry-terminate max-retry 3
  cause-code no-response-received action retry-terminate max-retry 1
  cause-code reject action terminate
 exit
 interface pfcp message N4SessionModificationReq
  cause-code mandatory-ie-incorrect action terminate
  cause-code session-ctx-not-found action terminate
  cause-code reject action terminate
 exit
 interface pfcp message N4SessionReportReq
  cause-code 69 action terminate
  cause-code 72-74,76,78-100 action terminate
 exit
exit

障害プロファイルの関連付けの構成

この構成により、UPF 障害プロファイルが UPF グループ プロファイルに関連付けられます。

手順

ステップ 1

グローバル コンフィギュレーション モードで UPF グループ名を定義します。

profile upf-group upf_group_name

例:

[smf] smf# config 
[smf] smf(config)# profile upf-group upfg 

ステップ 2

UPF 障害プロファイル名を指定して設定を保存します。

failure-profile failure_profile_name
例:

[smf] smf(config-upf-group-upfg)# failure-profile failure_profile_name 

UPF 障害処理の統計

SMF は、UPF 障害処理に関して、次の統計情報をサポートしています。

  • smf_sess_pdn_rel_peer_request_reject:smf_disconnect_stats が拡張され、4G コールと Wi-Fi コールの両方に適用されるこの切断理由が含まれるようになりました。

  • smf_sess_pdu_rel_peer_request_reject—smf_disconnect_stats が拡張され、この切断理由が追加されました。これは 5G コールに適用されます。