このセクションでは、QoS プロファイルの作成、変更、および削除につながるさまざまな使用例のシナリオと、それに対応するアクションについて説明します。

PDU コンテキストに関連付けられた QoS プロファイルは、次のシナリオで変更されます：

• SMPolicyContextData に対する PCF からの応答

• PCF からの更新通知

• SMF から最初に送信される更新要求に代わって PCF から応答を更新

• SMF からの更新要求は、次の場合にトリガーされます：

  • UEによって変更要求がトリガーされました

  • AN トリガー変更要求

  • UDM によって変更要求がトリガーされました

UDM NF は、セッション管理サブスクリプション データで UE のサブスクライブされた QoS を維持します。PDU のセットアップ手順中に、SMF はリソース URI「/(supi)/sm-data」の HTTP2 GET 要求（ 3GPP TS 29.503を参照）を投稿して、セッション管理サブスクリプション データを取得します。サブスクリプション データには、サブスクライバがアクセスできる DNN ごとに 1 つずつの DNN 構成があります。各DNN構成は、次のパラメータで構成されます：

• セッションAMBR：各 PDU セッションのすべての非 GBR QoS フローで共有される、アップリンクおよびダウンリンク ビット レートの合計の最大値。

• 5gQosProfile：デフォルトの 5G QoS インジケータ（5QI）とデフォルトの ARP 値は、DNN 構成のこの属性でセッション管理サブスクリプション データ内の SMF に提供されます。

SMF は、サブスクライブされた QoS パラメータを保存し、SM ポリシーの関連付けの確立手順中にこれを PCF に送信します。

SMF は 、3GPP TS 23.502、セクション 4.16.4で定義されているポリシーの関連付けの確立手順を開始することにより、PCF と QoS をネゴシエートします。サブスクリプションから受信した sessionAMBR および 5gQosProfile のパラメータは、PCF への Npcf_SMPolicyControl_Create 要求に含まれます。PCF からの応答には、次のものが含まれる場合があります。

• セッション ルール：セッション ルールは、PDU セッションに関連付けられているポリシー情報要素で構成されます。QoS 関連情報は、承認されたセッション AMBR および承認されたデフォルト QoS です。

  • ポリシーの課金と制御（PCC）ルール：PCC ルールには、FlowDescription、FlowDirection、および RefQosData パラメータが含まれます。PCF からの応答に 1 つ以上の PCC ルールが含まれている場合があります。

    • FlowDescription：このパラメータには、IP フローのパケット フィルタが含まれます。IP PDU セッション タイプの場合、パケット フィルタ セットは、少なくとも次のいずれかの組み合わせに基づいてパケット フィルタリングをサポートします。

      ：送信元/宛先 IP アドレスまたは IPv6 プレフィックス

      ：送信元/宛先ポート番号

      ：IP/Next ヘッダー タイプの上のプロトコルのプロトコル ID

      - Type of Service（TOS）（IPv4）/トラフィッククラス（IPv6）とマスク

      ：フロー ラベル（IPv6）

      ：セキュリティ パラメータ インデックス

    • FlowDirection：このパラメータは、ルールを適用する必要があるデータ トラフィックの方向を示します。これは、UPLINK、DOWNLINK、または BIDIRECTIONAL のいずれかです。

    • RefQosData：このパラメータは、この PCC ルールに適用される QoS の説明を参照します。これは、PCF からの応答の QoS 説明エントリの少なくとも 1 つの QosId と一致します。

  • QoS 特性：QoS 特性には、次のパラメータが含まれます。

    • リソース タイプ（GBR、遅延クリティカル GBR、または非 GBR）

    • プライオリティレベル

    • パケット遅延バジェット

    • パケットエラーレート

    • ウィンドウの平均化

    • 最大データ バースト ボリューム（遅延クリティカル GBR リソース タイプのみ）

      PCF からの応答のこの属性は、非標準 5QI 値にのみ使用することを目的としています。標準 5QI 値の場合、特性はすでに 3GPP TS 23.501、セクション 5.7.4 に定義されています。

  • QoS の説明：[QoS の説明（QoS Description）] パラメータは、次の各パラメータで構成されます。

    • 5QI：QoS 特性属性からの標準または非標準

    • アップリンクおよびダウンリンク GBR

    • アップリンクおよびダウンリンク MBR

    • 最大パケット損失レート

    • QosId：PCC ルールで参照

    • デフォルトの QoS 表示

      PCF からの応答に複数の QoS の説明属性が含まれている場合があります。

Npcf_SMPolicyControl_Create 応答で PCF から受信した情報は、SMF で QoS フローを作成および更新するために使用されます。各 QoS フローには一意の QoS フロー ID（QFI）があり、1 つ以上の PCC ルールが単一の QoS フローにマップされます。

次の図は、SMF で QoS 情報を管理する方法を示しています。

SMF の各 QoS フローは、次の 3 セットの情報の組み合わせです。

• QoS プロファイル：QoS プロファイルには、特定の QoS フローのすべての QoS 属性が保存されます。

  • QoS フロー バインディング パラメータと呼ばれる一部の QoS パラメータは、1 つの PDU セッションの 1 つの QoS フローに一意の組み合わせを行います。つまり、PDU セッションでは、これらのパラメータの一意の組み合わせごとに個別の QoS フローを表すことになります。これらのパラメータは、5QI、ARP、優先順位、最大データ バースト ボリューム、平均ウィンドウ、および QNC です。

  • QoS フローの QoS プロファイルの 5QI が非標準の場合、リソース タイプ、パケット遅延バジェット、パケット エラー率、平均ウィンドウなどの追加の QoS 特性も QoS プロファイルに保存されます。

  • QoS プロファイルは複数の QoS の説明を維持し、それぞれが特定の PDU セッションに固有の QoSId を持ちます。各 QoS 説明には、アップリンクとダウンリンクの GBR、アップリンクとダウンリンクの MBR、最大パケット損失率、およびデフォルトの QoS 表示が含まれています。

• QoS ルール：QoS ルールは、QoS フローの QoS プロファイル内の特定の QoS の説明に関連付けられているパケット フィルタのコレクションです。パケット フィルタは、PCF からの Npcf_SMPolicyControl_Create 応答の PCC ルールで受信したフロー記述に直接マッピングされます。QoS ルールには、そのルールが関連付けられている QoS の説明の QoSId への参照が含まれています。

• PDR：各 QoS ルールは、UPF に送信される 2 つのパケット検出ルール（PDR）にマッピングされます。1 つの PDR はアップリンク方向用で、もう 1 つの PDR はダウンリンク方向用です。PDR マップ内のパケット検出情報（PDI）属性でのサービス データ フロー（SDF）フィルタは、QoS ルールのパケット フィルタをマップします。各 PDR は、SDF フィルタに一致するパケットの転送アクションを決定する転送アクション ルール（FAR）にマッピングされます。各 PDR は、QoS 情報を伝送する QoS 適用ルール（QER）にも関連付けられ、QoS ルールに関連付けられた QoS の説明にマッピングされます。

ネゴシエートされた QoS は主に UE（NAS プロトコルを使用した N1 インターフェイス）、gNB（NGAP プロトコルを使用した N2 インターフェイス）、および UPF（PFCP プロトコルを使用した N4 インターフェイス）と通信する必要があります。

• N1 Interface：N1 インターフェイスでは、AMF を介して UE と SMF の間でセッション管理メッセージが交換されます。NAS メッセージは N1 コンテナにエンコードされ、SMF に送信されるか、SMF から受信されます。

  • UE に送信する必要があるネゴシエート済みおよび認可済み QoS 関連情報はすべて、PDU セッションの確立時に、N1 コンテナ内の PDU SESSION ESTABLISH ACCEPT メッセージの認可 QoS ルールおよびセッション AMBR 属性で見つかります（ 3GPP TS 24.501、セクション 8.3.2 を参照）。

  • UE からの PDU セッション変更要求メッセージには、UE が開始した QoS 変更中に要求された QoS ルールが含まれています。

  • 認定 QoS ルールとセッション AMBR 属性は、PCF/SMF によって開始された QoS 変更中に SMF から UE に送信される PDU セッション変更コマンドメッセージにも存在します。

  • QoS ルール NAS 属性の形式は 、3GPP TS 24.501、セクション 9.10.4.9に定義されています。この属性は主に、パケット フィルタ リスト、QFI、および QoS パラメータ（個々の QoS ルール ベース）で構成されます。この情報は、QoS フロー内の QoS ルールで使用できます。

• N2 インターフェイス： N2 インターフェイスでは、SMF は AMF を介して N2 コンテナを gNB に送信します。N2 コンテナは ASN.1 エンコードデータであり、NGAP メッセージの特定の情報要素で構成されています。gNB へのすべての QoS 関連情報はエンコードされ、N2 コンテナで SMF との間で送受信されます。AMF から gNB に IE を最終的に伝送する NGAP IE および対応する NGAP メッセージは 、3GPP TS 29.502、セクション 6.1.6.4.3に記載されています。

  • PDUセッションのセットアップ中に、SMFはPDUセッション再送信元セットアップ要求転送IEのN2コンテナでN1N2MessageTransferをAMFに送信します。この IE には、PDU セッション集約最大ビットレートと QoS フロー設定要求リストが含まれています。QoS フロー設定要求リストには、QoS フローレベルの QoS パラメータ（GBR フロー情報、5QI など）が含まれます。これらは 、3GPP TS 38.413、セクション 9.3.1で定義されています。

  • 同様の情報（QoS フローレベルの QoS パラメータ）も、PCF/SMF によって開始された QoS 変更手順中に、N2 コンテナの PDU セッションリソース変更要求転送 IE で SMF によって送信されます。

    SMF で N2 コンテナを作成するために必要な情報は、前のセクションで説明したように、QoS フローの QoS プロファイルにあります。

• [N4 インターフェイス（N4 Interface）]： N4 インターフェイスでは、SMF は QoS 情報をパケット検出ルール（PDR）、転送アクションルール（FAR）、および QoS 適用ルール（QER）の形式で送信します。

  • PDR には、PDI IE の SDF フィルタが含まれます。これらの SDF フィルタは、QoS フローの QoS ルールで設定されたパケットフィルタです。

  • QER には、QoS ルールが関連付けられている QoS の説明に従って、QoS パラメータが含まれています。

    PDR、FAR、QER の内容は 、3GPP TS 29.244で定義されています。

QoS の変更により、次のシナリオのいずれかが発生する可能性があります：

• QoS フローの追加：UE が開始した変更、または PCF が開始した QoS の変更のいずれかとして、ネゴシエートされた QoS を PCF から受信するたびに、SMF は受信した QoS フロー バインド パラメータ（5QI、ARP、優先順位、最大データ バースト ボリューム、QNC）を抽出します。フロー バインディング パラメータの受信の組み合わせを持つ QoS フローがない場合、SMF は新しい QoS フローを追加し、受信した PCC ルールは新しい QoS フローに対してマッピングされます。その結果、新しい QoS フロー ルール/QoS の説明/PDR/QER が作成され、対応するインターフェイス（N1、N2、および N4）が新しいフローの作成によって更新されます。

• QoS フロー変更：UE が開始した変更、または PCF が開始した QoS の変更のいずれかとして、ネゴシエートされた QoS を PCF から受信するたびに、SMF は受信した QoS フロー バインディング パラメータ（5QI、ARP、優先順位、最大データ バースト ボリューム、QNC）を抽出します。バインディング パラメータの組み合わせが同じ QoS フローがある場合、その QoS フローの QoS プロファイル、QoS ルール、PDR、および QER が N1、N2、および N4 インターフェイスで更新されます。

SMF は、PCF との相互作用中に、Diff-Serv-Code-Point（DSCP）またはタイプオブサービス（ToS）QoS 機能をサポートします。SMF で定義されたトラフィックは、SMF が PCF から受信する tosTrafficClass 値に基づいて優先順位を付けることができます。指定された ToS 値を使用して、UPF はダウンリンク方向で DSCP パケット マッチングを実行し、UE はアップリンク方向で DSCP パケット マッチングを実行します。この機能により、FlowDescription 値が存在しない場合でも、ToS 値を使用したパケット照合が可能です。

次の機能により、この機能が有効になります。

• PCF は、PCF からの PCC ルール内の FlowInformation の一部である sTrafficClass IE を に送信します。SMF はそれをデコードし、それぞれの QoS フローの一部として保存します。

• SMF は、ダウンリンク PDR の作成中に、PDI 内の SDF IE 内の tosTrafficClass で PCF から受信した tosTrafficClass IE 値を入力します。

• UE への tosTrafficClass をサポートします。

次のコール フローでは、tosTrafficClass IE をサポートするための PCF から SMF へのフローについて説明します。

• 最小限の機能をサポートする基本的な PCF を展開できます。PCF はノースバウンド インターフェイスをサポートする必要がなく、ローカル構成に基づいた専用フローがインストールされます。

• UE は、データ、音声、およびビデオをサポートする単一のセッション（デフォルトのベアラー）のみを作成します。PCF は、PDU セッションの作成時に 4 つのフローをトリガします。1 つずつ、音声、ビデオ、データ、ネットワーク管理用です。

• ローカル構成に基づいた PCF は、N7 作成応答で sTrafficClass IE に伝送される FlowInformation をそれぞれ含む 4 つの PCC ルールを送信します。

• SMF は、tosTrafficClass のみを持ち、 FlowDescription を 持たない FlowInformationにマッピングされた PCC ルールのフロー作成をサポートします。

• PCF は、any から any への IP の許可、または any から any への IP の許可など、フィルタを使用して FlowInformation 内に FlowDescription を含めることができます。

• PCF は、関連付けられた QCI を示す各 pcc ルールの smPolicyDecision に QoS データを含みます。SMF は QCI ごとに QoS フローを作成します。

• SMF は、 sTrafficClass にマップされた PCF からルールをインストールする際に、 N4SessionEstablishmentReq のダウンリンク PDR の SDF IE 内に tosTrafficClassを UPF に含めます。

• SMF は PCF に N1 PDU 確立応答を送信します。この応答には、PCF から受信した情報に基づいて、サービス タイプまたはトラフィック クラス タイプで構成されたパケット フィルタを含む QoS ルールなどの詳細が含まれています。SMF が PCF からフロー方向を受信しない場合、パケット フィルタの方向は双方向として入力され、パケット フィルタ コンポーネント タイプ識別子は [タイプオブサービス（Type of service）] または [トラフィック クラス タイプ（Traffic class type）]として入力されます。

（注）	FlowDirection はオプションのパラメータで、そのデフォルト値は bidirectional です。

この ビット レート マッピング機能は、以下の基準に準拠しています：

• 3GPP TS 29.274、リリース 12：3GPP Evolved Packet System（EPS）、Evolved General Packet Radio Service（GPRS）Tunnelling Protocol for Control plane（GTPv2-C）、ステージ 3

次のコマンドを使用して、ビット レート マッピング機能を確認します。

show full-configuration profile network-element pcf 

PCF プロファイル内でビット レートの切り上げが有効になっている場合、 bitrates round-up という文字列が表示されます。それ以外の場合、文字列は表示されません。

以下の構成は、show コマンドの出力例です。

show full-configuration profile network-element pcf
profile network-element pcf pcf1
nf-client-profile PP1
failure-handling-profile FH1
query-params [ dnn ]
rulebase-prefix cbn#
predefined-rule-prefix crn#
bitrates rounded-up
exit

Diameter インターフェイスと GTPv2 インターフェイス間でビットレート マッピングを有効にするには、次の構成例を使用します。

（注）	MBR/GBR/APN-AMBR などの専用ベアラー ビット レート変換にも同じ構成を使用します。

config 
   profile network-element pcrf profile_name 
      bitrates rounded-down 
      diameter-client-profile Diameter Client_Profile Name  
      subscription-idsubscription-id 
      exit 

注：

• profile network-element pcrf profile_name ：PCRF のプロファイル名を指定します。

• bitrates rounded-down ：ビット レートの切り捨てを構成します。SMF は、目的のネットワーク インターフェイスを介してフロア値を送信します。

  デフォルトでは、SMF は変換中にビット レートを CEIL 値に丸め、ビット レートは切り上げられます。

次の手順では、SMF が 4G および Wi-Fi セッションでの承認されたデフォルト QoS の変更を処理する方法について説明します。

1. SMF は、AuthorizedDefaultQoS の変更された QCI/5QI や異なるセッション AMBR 値を持つ PCF から SmPolicyUpdateNotify を受信します。

2. SMF は、デフォルトのベアラーの S-GW に向けてベアラー要求の更新を開始します。

   1. ベアラーの更新要求では、デフォルトのベアラーにベアラー コンテキスト IE が含まれ、対応するベアラー QoS が変更された QCI 値で更新されます。

   2. 4G セッションでは、拡張プロトコル構成オプション（ePCO）がサポートされている場合は、Update Bearer Request メッセージに含まれます。ePCO には、セッションでインターワーキング（IWF）が有効になっている場合、デフォルトフローの更新された QCI 値を含む 5G 認定 QoS フロー情報が含まれます。それ以外の場合、PCO IE は同じ詳細とともに送信されます。

   3. Wi-Fi セッションでは、Update Bearer Request メッセージに追加のプロトコル構成オプション（APCO）が含まれています。APCO には、デフォルトフローの QCI 値が更新された 5G 認定 QoS フロー情報が含まれています。

3. SMF は、S-GW からのベアラー応答の更新を受け入れます。

4. N4 インターフェイスでは、次の変更が行われます。

   1. BearerLvlInfo IE の新しいインスタンスは、デフォルトのベアラートンネルの変更された QCI 値に含まれています。

   2. 更新 PDR は、デフォルトフローの一部であるすべての PDR に送信され、新しい BearerLvlInfo IE との関連付けを反映します。

   3. デフォルトフロー内のすべての PDR に関連付けられた FAR は、5QI-DSCP マッピング構成に、変更された 5QI の異なる値がある場合、新しい DSCP マーキング値で更新されます。

次の手順では、SMF が 5G セッションのデフォルト ベアラの承認済み QoS の変更を処理する方法について説明します。

1. SMF は、AuthorizedDefaultQoS の変更された 5QI や異なるセッション AMBR 値を持つ PCF から SmPolicyUpdateNotify を受信します。

2. SMF は、AMF を使用して N1N2MessageTransfer 手順を開始し、このメッセージで N1 PDU セッション変更コマンドおよび N2 PDU セッションリソース変更要求転送 IE を送信します。

   1. N1 メッセージでは、デフォルト QoS フローが許可された QoS フローの説明 IE で変更され、5QI 値が更新されます。

   2. N1 メッセージでは、デフォルトのベアラの QCI を更新するように、マッピングされた EPS ベアラーコンテキスト IE が変更されます。

   3. N2 メッセージでは、デフォルト フローの QoS フロー レベルの QoS パラメータが変更され、5QI 値が更新されます。

3. SMF は、N1N2Message Transfer メッセージで送信された N1 および N2 要求に対する応答とともに、AMF からの SMContextUpdate 要求を受け入れます。

4. N4 インターフェイスでは、次の変更が行われます。

   1. BearerLvlInfo IE の新しいインスタンスは、変更された 5QI から QFI へのマッピングに含まれています。

   2. 更新 PDR は、デフォルトフローの一部であるすべての PDR に送信され、新しい BearerLvlInfo IE との関連付けを反映します。

   3. デフォルトフロー内のすべての PDR に関連付けられた転送アクション ルール（FAR）は、5QI-DSCP マッピング構成に、変更された 5QI の異なる値がある場合、新しい DSCP マーキング値で更新されます。

次の手順では、SMF が Wi-Fi ハンドオーバーおよびその他のハンドオーバー時に、承認されたデフォルトの QoS 変更をどのように処理するかを説明します。

1. SMF は、各引き継ぎ手順の最後に SMPolicy 更新要求を PCF に送信します。たとえば、PCF アームで異なるポリシーがトリガされると、SMF は SMPolicy 更新要求を PCF に送信します。PCF からの応答には、セッション ルール（承認されたデフォルト QoS）で変更された QCI が含まれています。SMF は、RAN/UE に対する変更手順を開始し、N1、N2、N4、および S5 インターフェイスで同じ情報を伝達します。

2. すべてのハンドオーバー（Wi-Fi-NR/EPS および NR/EPS-WiFi を除く）の場合、SMF は SMPolicy 更新要求を PCF に送信し、RAT タイプの変更を示します。PCF からの応答には、セッション ルール（承認されたデフォルト QoS）で変更された QCI が含まれています。SMF は、RAN/UE に対する変更手順を開始し、N1、N2、N4、および S5 インターフェイスで同じ情報を伝達します。

Wi-Fi を含むハンドオーバーは、他のハンドオーバーとは異なります。SMF は、引き継ぎ後ではなく引き継ぎ中に、PCF に対して SMPolicy 更新要求をトリガします。WiFi を含むハンドオーバーの場合、ターゲット RAN は、更新ではなく、新規としてフローとベアラーをインストールします。SMF は、ハンドオーバー時にデフォルトのフローとベアラーをインストールする際に、PCF からの応答で受信した最新の QCI を送信します。

5G セッションの場合、デフォルト フローは非 GBR フローであり、QCI/5QI の変更にリソース予約は必要ないため、通常は N1 または N2 インターフェイスでの QCI/5QI の変更は失敗しません。ただし、AMF からの N1 または N2 応答がないために変更手順が失敗した場合、変更はロールバックされ、セッションは古い QCI/5QI およびセッション AMBR 値で続行されます。N2 がフロー変更を拒否すると、デフォルト フローなしではセッションを維持できないため、セッションは削除されます。

4G セッションの場合、デフォルトのベアラーの変更に対するベアラーの更新応答は失敗しません。ただし、ベアラー応答の更新が欠落しているか、または失敗した場合、変更はロールバックされ、セッションは古い 5QI およびセッション AMBR 値で続行されます。

4G と 5G の両方のセッションで、N4 更新が失敗するか、応答が受信されない場合、SMF は UPF 障害処理テンプレートの構成に従ってアクションを実行します。4G および Wi-Fi セッションでは、N4 インターフェイスに障害があると、別のベアラー要求が古い 5QI および AMBR 値とともに S-GW および ePDG に送信されます。

障害処理メカニズムは、PCF によって開始される変更手順でも同じです。

デフォルトのベアラーに関する認可された QoS の処理機能には、次の制限があります。

• 承認された QoS の QoS フロー バインディング パラメータ（5QI や ARP など）の組み合わせは、専用ベアラーまたはフローと同じになることはありません。つまり、QCI/5QI を変更しても、デフォルト フローのバインディング パラメータが別のフローと類似することはありません。

• SMF は、セッション ルールの割り当て/保持優先順位（ARP）および QCI/5QI（セッション AMBR の有無にかかわらず）を除き、すべてのバインディング パラメータの変更をサポートしていません。

• QCI/5QI が変更されると、既存のデフォルト ベアラー フローが N1、N2、および N4 インターフェイスに向けて変更されます。この場合、SMF は新しいフローを作成する代わりに、既存のフローを削除しません。

SMF は、「SESSRULE_CHANGE」というラベルを維持して、AMBR 値、QCI/5QI 値、または AMBR 値と QCI/5QI 値の両方の組み合わせに対する変更を示します。

デフォルトのベアラーとフローを作成するために、ネゴシエートされた QoS プロファイルが選択されます。

• 4G セッションで、N7 インタラクションが無効になっている場合、MME によって提供される QoS が使用されます。

• 5G セッションで N7 と N10 の連携が無効になっている場合、DNN プロファイルに関連付けられているローカル定義の QoS プロファイルが使用されます。

PCF の介入を使用せずに専用ベアラー/フローを作成するには、イベント管理ポリシーが必要です。イベント管理ポリシーと DNN プロファイルの関連付けは、構成を利用して行われます。イベントがトリガされるたびに、その DNN に関連付けられたイベント管理ポリシーが実行されます。イベント管理ポリシーで構成された各イベント ポリシーは、イベントおよびルールに基づいて一致が見つかるまで、優先順位の順に実行されます。

新しい構成では、イベント管理ポリシーを定義できます。複数の優先順位ベースのイベント処理ポリシーをイベント管理ポリシー下で構成できます。構成された各イベント ポリシーは、イベントとルールに基づいて一致が検索されるまで、優先順位の高い順に実行されます。

NR の場合、専用およびデフォルトのフロー パラメータは、N1 PDU セッション確立承認で UE に、N2 セットアップ要求で gNB に送信されます。E-UTRA の場合、デフォルトベアラーの作成はセッション作成応答の一部として実行され、GBR 専用ベアラーはセッション応答の作成送信直後にベアラー要求の作成（CBR）をトリガーすることによって作成されます。これは、SMF ですでにサポートされている PCF によってトリガーされるピギーバックされた CBR に似ています。

（注）	この機能は、CBR と CSR 応答が同じメッセージで送信される実際のピギーバック CBR をサポートしていません。

次のコール フローは、専用 GBR ベアラーの作成による 5G 接続のプロセスを示しています：

専用 GBR ベアラーを作成した 4G 接続のプロセスは、次の手順に従います：

この機能には次の既知の制限事項があります。

• この機能は、PCRF なしではなく、PCF なしの 4G コールをサポートしています。

QoS プロファイルとイベント管理ポリシーの DNN プロファイルへの関連付けは、次の構成で行うことができます。

config 
   profile dnn dnn_profile_name 
      qos-profile qos_profile_name 
      eventmgmt-policy eventmgmt_policy_name 
      exit 

注：

• eventmgmt-policy eventmgmt_policy_name ：この CLI では、DNN に関連付けられた優先順位ベースのイベント処理を構成できます。 eventmgmt-policy で構成された各イベント ポリシーは、イベントおよびルールに基づいて一致が見つかるまで、優先順位順に実行されます。

• qos-profile qos_profile_name ：この CLI を使用すると、QoS プロファイルとイベント管理ポリシーを DNN プロファイルに関連付けることができます。この QoS プロファイルは、UDM が提供しない場合、5G のデフォルト フローの QoS 値を読み取るために使用されます。

イベント管理ポリシーの追加は、次の構成によって行われます。

config 
   policy eventmgmt policy_eventmgmt_name 
      priority  event_priority [ event event_name ] ruledef ruledef_name actiondef actiondef_name 
      exit 

注：

• eventmgmt policy_eventmgmt_name ：この CLI では、イベント管理ポリシーを構成し、属性を定義できます。

• priority event_priority ：特定のイベント管理ポリシーの優先順位を定義できます。

• event event_name ：特定のアクションが実行されるイベントを定義するオプションの CLI です。イベント名として new-call のみをサポートします。セマンティックおよびシンタックス エラー処理シナリオでは、イベント名として cbr-resp がサポートされます。

  event が構成されていない場合、ルールが一致すると、すべての定義済みイベントに対して actiondef が実行されます。

• ruledef ruledef_name ：一致した場合にアクションを実行するローカル ポリシーのルールを定義します。

• actiondef actiondef_name ：実行されるアクション名を構成します。

次の構成では、ルール定義ポリシーを追加できます：

config 
   policy rulemgmt policy_rulemgmt_name 
      ruledef rule_def condition condition_string 
      exit 

• rulemgmt policy_rulemgmt_name ：ポリシーに追加するルールを定義します。

• ruledef rule_def ：ルール属性を構成します。ruledef は、条件が一致したときに宣言されます。

• condition condition_string ：ルールの使用例を定義します。 any および cause matches “cause” 条件のみサポートしています。

次の構成では、アクション定義ポリシーを追加します：

config 
   policy actionmgmt policy_actionmgmt_name 
      actiondef actiondef_name 
         priority priority_number action action_name [ attributes { rulebase rulebase_name [ rules rules_name ] } ] 
         exit 

注：

• actionmgmt policy_actionmgmt_name ：実行されるアクションを構成します。

• actiondef actiondef_name ：実行されるアクション属性を定義します。現在、アクションとして activate-rulebase のみがサポートされています。

  意味的および構文エラーの処理では、UE が 4G または 5G RAT にある場合のアクションは異なります。

• priority priority_number ：アクションが実行される優先順位を定義します。

• action action_name ：actiondef に関連付けられたアクションを優先順に定義します。GBR の作成が失敗した場合、SMF は release-session アクションをサポートします。

• attributes ：特定のアクションの属性を定義します。これは任意のコマンドです。

• rulebase rulebase_name ：フローと一致させるプロトコル ルールのコレクションと、フローと一致するために実行する関連アクションを定義します。

• rules rules_name ：実行されるルールのリストを定義します。

（注）	課金アクション、帯域幅ポリシー、およびパケット フィルタの既存の構成が、各ルールの QoS パラメータの構成に使用されます。

この機能の一部として、次のラベルが smf_service_stats に追加されています。

• policy_status：このメトリックは、構成されているローカル ポリシーに関連付けられます。

この機能が有効になっているかどうかを確認するには、show running-config profile smf CLI コマンドを使用します。有効にすると、show コマンド出力の一部として次のフィールドが表示されます。

• mode offline

SMF と PCF は、ポリシー コンテキストの作成中および PDU セッションの確立中に、サポートされている機能を交渉します。交渉された機能に基づいて、PCF は関連情報を提供します。

次の表は、3GPP 仕様 29.512 で定義されているネゴシエート可能な機能を示しています。

SMF は、Npcf_SMPolicyControl_Create メッセージで supportedFeatures 属性を送信し、さらにサポートされている機能を示すビットマップを含めます。PCF は、応答メッセージで supportedFeatures 属性も送信します。応答は、要求と一致するか、要求のサブセットである必要があります。

この文字列には、サポートされている機能を 16 進形式で示すビットマスクが含まれています。文字列内の各文字は「0」～「9」または「A」～「F」の値をとり、前の表に記載されている機能のサポートを表します。最も大きい番号の機能を表す最上位文字がストリングの最初に表示され、機能 1 ～ 4 を表す文字がストリングの最後に表示されます。機能のリストとそれらの機能の番号付け（1 から始まる）は、各 API に対して個別に定義されます。

N4 インターフェイスの場合、SMF は QoS 情報を次の形式で送信します。

• パケット検出ルール（PDR）

• 転送アクション ルール（FAR）のドロップ

• QoS 適用ルール（QER）

SessionAMBR には、各 PDU セッションのすべての非 GBR QoS フローで共有される、アップリンクおよびダウンリンク ビット レートの合計の最大値を含みます。SMF は、既存の QER とともに、非 GBR フローのセッション レベル QER を UPF に送信します。

SMF は、PDU セッションの作成中に SmPolicyDecision 内の PCF から sessionRule を受信します。sessionRule は、authSessAmbr と authDefQos で構成されます。承認された AMBR は、セッション レベルのアップリンク（UL）とダウンリンク（DL）の MBR で構成され、authDefQos にはデフォルト QoS フローの 5Qi、ARP、およびその他の QoS バインド パラメータが含まれています。

SMF は次のステップを実行します：

• authDefQoS で受信したものと同じバインディング パラメータを持つ QoS Desc が関連付けられている PCF から受信した PCC ルールは、デフォルトの QoS フローでタグ付けされます。

• N4 インターフェイスでは、デフォルトの QoS フローに関連付けられた各 PCC ルールに対して UL および DL パケット検出ルール（PDR）が作成されます。セッション AMBR の適用の場合、SMF は適切な AMBR を使用して QoS 適用ルール（QER）を作成し、非 GBR ルールのすべての PDR にそれを関連付けます。

• N1 インターフェイスでは、PDU SESSION ESTABLISHMENT ACCEPT メッセージの「QoS フロー説明」属性に、QFI、MFBR、5Qi の各値が含まれています。このメッセージには、セッション AMBR も送信されます。

• N2 インターフェイスでは、PDU セッション リソース セットアップ転送要求 IE に AMBR と「QoS フロー レベルの QoS パラメータ」（5Qi、ARP など）および QFI が含まれます。

• SMF は、UDM によって開始されたセッション AMBR の変更をサポートしています。この場合、次のように計算します。

  • SMF は、Npcf_SMPolicyControl_Update を、「subsSessAmbr」属性内の新しい登録されたセッション AMBR および「repPolicyCtrlReqTriggers」内の SE_AMBR_CH ポリシー制御要求トリガとともに PCF に送信します。セッション AMBR の変更を受信すると、PCF は、応答内で新しく承認されたセッション AMBR を SMF にプロビジョニングします。

  • セッション AMBR 適用のために、N4 インターフェイスの QER を更新します。

  • N1N2MessageTransfer を、N1 インターフェイスの PDU セッション変更コマンド メッセージの AMF および新しい AMBR を持つ N2 コンテナ内の PDU セッション リソース変更要求の転送 IE に対して AMF に対して開始します。

PCF は、複数の GBR ルールと非 GBR PCC ルールを作成、変更、または削除できます。

次のシナリオが可能です。

1. PDU セッションの確立中に複数の非 GBR および GBR PCC ルールがアクティブ化されます。この場合、次のように計算します。

   1. SMF は「QoS 管理」の項で説明されている QoS フロー バインドの原則に従って QoS フローを作成します。

   2. N4 インターフェイスでは、すべてのフローに関連付けられた PCC ルールごとに UL および DL PDR が作成されます。フローレベルの QoS 適用では、SMF は MFBR および GFBR（GBR フローの場合）の値を使用して QER を作成し、フローの各 PDR に関連付けます。

   3. N1 インターフェイスでは、PDU SESSION ESTABLISHMENT ACCEPT メッセージの「QoS ふろーの説明」属性に、QFI と MFBR、GFBR、および 5Qi の値が含まれます。各 QoS ルールに関連付けられたパケット フィルタは、「認証 QoS ルール」属性で N1 インターフェイスに送信されます。

   4. N4 インターフェイスと N1 インターフェイスの両方で、さまざまなタイプのパケット フィルタがサポートされています。このリストには、次のオプションが含まれています。

      
      Packet filter component type identifier 
      Bits 
      8 7 6 5 4 3 2 1 
      0 0 0 0 0 0 0 1 Match-all type 
      0 0 0 1 0 0 0 0 IPv4 remote address type 
      0 0 0 1 0 0 0 1 IPv4 local address type 
      0 0 1 0 0 0 0 1 IPv6 remote address/prefix length type 
      0 0 1 0 0 0 1 1 IPv6 local address/prefix length type 
      0 0 1 1 0 0 0 0 Protocol identifier/Next header type 
      0 1 0 0 0 0 0 0 Single local port type 
      0 1 0 0 0 0 0 1 Local port range type 
      0 1 0 1 0 0 0 0 Single remote port type 
      0 1 0 1 0 0 0 1 Remote port range type 
      

   5. N2 インターフェイスでは、PDU セッション リソース セットアップの転送要求 IE に、各フローの「QoS フロー レベルの QoS パラメータ」（5Qi、ARP など）と QFI が含まれます。IE の「GBR QoS フロー情報」フィールドには、GBR フローの MFBR と GFBR が含まれています。

2. PDU セッション確立後の PCC ルールの変更。このシナリオでは、次のシナリオが見られます。

   1. 1 つまたは複数の PCC ルールのパケット フィルタの変更、追加、および削除：

      1. この場合、N4 セッション変更を呼び出すことにより、N4 インターフェイス上の PDR の SDF フィルタが変更されます。

      2. SMF は、N1 インターフェイスの PDU セッション変更コマンド メッセージの「認可 QoS ルール」属性を使用して AMF に対して N1N2MessageTransfer を開始します。この属性のルール操作コードは、次のいずれかです。

         
         0 1 1 Modify existing QoS rule and add packet filters 
         1 0 0 Modify existing QoS rule and replace all packet filters 
         1 0 1 Modify existing QoS rule and delete packet filter 
         

   2. 1 つ以上の PCC ルールに関連付けられた QoS の変更：

      1. SMF は QoS フロー バインド評価を実行し、次の操作が行われます。

         1. 新しい QoS フローが追加されると、一部の PDR の N4 インターフェイスの QFI が変更されます。

         2. ある QoS フローから別の QoS フローへの PCC ルールの移動。この場合、影響を受ける PCC ルールの PDR/QER が変更され、QFI が更新されます。

         3. フローの最後の PCC ルールが別の QoS フローに移動された場合の QoS フローの削除。この場合、影響を受ける PCC ルールの PDR/QER が変更され、QFI が更新されます。

      2. 上記の場合、N1 インターフェイスでは、認定 QoS ルールおよび認定 QoS 記述子が次のいずれかの動作コードとともに送信されます。

         
         0 0 1 Create new QoS flow description 
         0 1 0 Delete existing QoS flow description 
         0 1 1 Modify existing QoS flow description 
         

      3. N2 インターフェイスでは、PDU セッション リソース変更要求転送 IE の QoS フロー レベルの QoS パラメータにより、変更された GFBR、MFBR、5Qi などを伝送します。フロー削除の場合、再リースする QoS フロー リストがこの IE に含まれます。

   3. PCC ルールの削除：

      1. この場合、SMF は N4 インターフェイス上の QoS フローに関連付けられているすべての PDR を削除します。

      2. N1 インターフェイスでは、認定 QoS ルールおよび認定 QoS 記述子が次のいずれかの動作コードとともに送信されます。

         
         0 1 0 Delete existing QoS flow description 
         

      3. N2 インターフェイスでは、PDU セッション リソース変更要求転送 IE が QoS フローをリリース リストに伝送します。

SMF は、次のように 1 つの QER を作成することで、PCC ルール（SDF）レベル、QoS フロー レベル、およびセッション レベルで QoS を適用します。

• PCC ルールレベルごとに、PCF によって提供され、特定の PCC ルールに関連付けられている関連する QoS Desc に従って MBR/GBR を適用する場合。

• QFI に関連付けられたすべての PCC ルールの MBR/GBR を集約した QoS フロー レベルでの実行。

• セッション レベルで、GBR 以外のすべての QoS フローにセッション AMBR を適用します。

これらの QER が作成されると、SMF は以下を関連付けます。

• GBR 以外の QoS カテゴリに属するすべての PDR にセッション レベル QER を実行します。

• SDF レベルの QER を個別の PCC ルールにマッピングします。

あるフローから別のフローへの PCC ルールの移動およびフロー内の QoS の変更を含む QoS の変更の場合、SMF は GFBR/MF BR（またはセッション AMBR）を変更し、それに応じて N4 インターフェイスで QER を更新します。

PCF は、SmPolicyDecision データ構造内の「policyCtrlReqTriggers」属性にトリガーを含めることで、1 つまたは複数のポリシー制御要求のトリガーを提供します。

PDU セッションの存続期間中、PCF はポリシー制御要求のトリガーを更新または削除します。トリガーを更新するために、PCF は「policyCtrlReqTriggers」属性にトリガーを含めることで、該当するポリシー制御要求のトリガーの新しい完全なリストを提供します。

PCF は、「policyCtrlReqTriggers」属性を NULL 値に設定して、以前に提供されたすべてのトリガーを削除します。この値を持つポリシー制御要求のトリガーを受信すると、SMF は、常に報告されるトリガーを除き、PCF にトリガーを通知せず、PCF からのプロビジョニングを必要としません。

PCF がトリガーをプロビジョニングするたびに、トリガーの値定義で指定されていない限り、SMF は、HTTP POST メッセージに応答として対応する現在適用可能な値（たとえば、アクセスタイプ、RAT タイプ、ユーザーの場所情報など）をUECampingRep データ構造内の PCF に送信します。この場合、「repPolicyCtrlReqTriggers」属性は含まれません。

サポートされているトリガーのリストは次のとおりです：

ハンドオーバーでの SCNN_CH トリガーのサポート

SMF は、次のハンドオーバーでのサービス ネットワークの変更トリガーをサポートしています。

• Inter AMF ハンドオーバー：「SCNN_CH」がプロビジョニングされている場合、SMF はサービスネットワーク機能（AMF など）の変更を検出すると、SMF は「repPolicyCtrlReqTriggers」属性内と現在のサービスネットワーク機能「servNfId」属性。サービス提供ネットワーク機能が AMF の場合、SMF は、「servNfInstId」属性内に AMF ネットワーク機能インスタンス識別子を含め、「guami」属性内にグローバルに一意の AMF 識別子を含めます。

• 5G から 4G へのハンドオーバー：UE が 5GS から EPC/E-UTRAN にハンドオーバーされた場合、「SCNN_CH」ポリシー制御要求トリガーがプロビジョニングされて満たされている場合、SMF には、内部の S-GW ID を含む「servNfId」属性が含まれます。 "anGwAddr" 属性。

• 4G から 5G へのハンドオーバー：SMF では、「servNfInstId」属性内に AMF ネットワーク機能インスタンス識別子が含まれ、「guami」属性内にグローバルに一意の AMF 識別子が含まれます。

• WiFi から 5G ハンドオーバー：SMF では、「servNfInstId」属性内に AMF ネットワーク機能インスタンス識別子が含まれ、「guami」属性内にグローバルに一意の AMF 識別子が含まれます。

• 5G から WiFi ハンドオーバーへの5GS から EPC への 3GPP 以外のアクセスが引き渡されると、SMF には、「SCNN_CH」ポリシー制御要求トリガーがプロビジョニングされて満たされている場合、 「servNfId」属性内の「anGwAddr」属性内の ePDG 識別子が含まれています。

ダイナミック PCC ルールの適用機能は、次の規格に準拠しています。

• 3GPP TS 29.512 バージョン 15.4.0 - 5G 5G システム。セッション管理ポリシー制御サービス。第 3 段階

ダイナミック PCC ルールの適用機能は、次の制限があります。

• SMF は次の操作の組み合わせのみをサポートします。

  • 新しい QoS フローを作成するための新しい QoS 記述子を使用した新しい PCC ルールの作成

  • 既存の QoS フローへの新しい PCC ルールの追加

  • PCC ルールの削除

  • ルールに関連付けられている GBR/MBR パラメータの更新

  • セッション AMBR の変更

Quality of Service（QoS）プロファイルのインスタンスを作成するには、次の構成例を使用します。

config 
   profile qos qos_profile_name 
   exit 

注：

• qos qos_profile_name ：QoS プロファイルを作成し、QoS パラメータを構成する [QoS プロファイル コンフィギュレーション（QoS Profile Configuration）] モードへのアクセス権を付与します。 qos_profile_name は 、QoS プロファイルを一意に識別する英数字の文字列である必要があります。

QoS パラメータを構成するには、次の構成例を使用します。

config 
   profile qos qos_profile_name 
      ambr { ul uplink_ambr | dl downlink_ambr } 
      arp { preempt-cap preemption_capability |   
      preempt-vuln preemption_vulnerability |  
      priority-level priority_level } 
      max data-burst burst_volume 
      priority qos_priority 
      qi5 5qi_value 
      exit 

注：

• ambr { ul uplink_ambr | dl downlink_ambr } ：アップリンク（サブスクライバからネットワーク）およびダウンリンク（ネットワークからサブスクライバ）トラフィックの集約最大ビットレート（AMBR）を定義します。

• arp preempt-cap preemption_capability ：プリエンプション機能フラグを指定します。次のオプションがあります。

  • MAY_PREMPT：ベアラーがプリエンプション処理される可能性がある。

  • NOT_PREMPT：ベアラーをプリエンプトできない。

• arp preempt-vuln preemption_ulnerability ：プリエンプション脆弱性フラグを指定します。次のオプションがあります。

  • PREMPTABLE：ベアラーがプリエンプション処理される可能性があります。

  • NOT_PREMPTABLE：ベアラーをプリエンプトできません。

• arp priority-level priority_level ：サービス データの割り当てと保持の優先順位（ARP）を定義します。 priority_level のデフォルト値は 8 です。

• max data-burst burst_volume ：最大データ バースト ボリュームを定義します。 burst_volume は 1 ～ 4095 の範囲の整数である必要があります。

• priority qos_priority ：5QI 優先順位レベルを指定します。 qos_priority は 、1 〜 127 の範囲の整数である必要があります。

• qi5 5qi_value ：承認された QoS パラメータの 5G QoS 識別子（5QI）を指定します。5qi_value は 0 ～ 255 の範囲の整数である必要があります。

既存の DNN プロファイル内のQoS プロファイルを構成するには、次のサンプル構成を使用します。

config 
   profile dnn dnn_profile_name 
      qos-profile qos_profile_name 
      exit 

注：

• qos-profile qos_profile_name ：ローカルに構成されたデフォルトの QoS プロファイルを定義します。このプロファイルは、既存のDNNプロファイル設定の下で構成されます。 qos_profile_name は 、構成された QoS プロファイルの名前である必要があります。

ここでは、ダイナミック PCC ルール適用機能構成の認証方法について説明します。

次の表示コマンドを使用して機能構成の詳細を認証します。

show full-configuration

次に、この show コマンドの出力例を示します。

show full-configuration 
profile dnn dnn1 
qos-profile qos1 
! 
profile qos qos1 
ambr ul 1024 
ambr dl 1024 
qi5 128 
arp priority-level 8 
arp preempt-cap NOT_PREEMPT 
arp preempt-vuln NOT_PREEMPTABLE 
priority 9 
max data-burst 2048 
exit 

サービスが制限された特定の UE（PTT デバイスなど）が 5G RAT に接続すると、PCF は、デフォルト フローに関連付けられたダイナミック PCC ルールを SMF に送信します。PCF が動的 PCC ルールで true に設定された値を持つ PacketFilterUsage IE を送信し、PCC ルールがデフォルト フローに関連付けられている場合、SMF はフロー情報を含む QoS ルールを追加し、TFT（トラフィック フロー テンプレート）を UE に送信します。

packetFilterUsage IE が false に設定されている場合、SMF は「Any-Any」フィルタを使用して QoS ルールを追加し、UE に送信します。パケットフィルタ「Any-Any」は、UEが任意のIPと通信して任意のサービスを利用できるようにするデフォルトのフィルタです。この機能の目的は、PTT サービスなどの専用 UE サービスをサポートするためのパケットの優先順位付けを可能にすることです。

この機能はダイナミック ルールにのみ対応しており、静的ルールや定義済みルールには対応しています。この機能も専用ベアラーには適用されません。

（注）	N4 インターフェイスには影響がないため、すべてのルールとフィルタは PCF から受信されたとおりに UPF に送信されます。

UE へのデフォルト フローに関連付けられた TFT パラメータの送信は、次の手順で行われます。

1. [PCC ルールの識別（PCC Rule Identification）]：デフォルトフローに関連付けられた PCC ルールを識別するために、次の 2 つの条件が使用されます。

   • PCC ルールが、authDefQos と同じバインディング パラメータ（5QI、arp）で QoS データに関連付けられている場合（authDefQos には、デフォルト QoS フローの 5QI、ARP、および他の QoS バインディング パラメータが含まれています）。

     （注）	デフォルト フローに関連付けられている PCC ルールの場合、 authDefQos パラメータのみが考慮され、他のすべての QoS パラメータは無視されます。

   • PCF から受信した PCC ルールに defQosFlowIndication IE が trueに設定されている場合。

2. [TFT 更新（TFT Update）]：SMF は、次の条件に基づいて、対応する TFT パラメータを UE に送信します。

   条件	予期される動作	説明
   packetFilterUsage IE が trueに設定されている PCC ルール。	その PCC ルールに関連付けられている TFT が、N1 インターフェイスを介して UE に送信されます。
   packetFilterUsage IE が falseに設定されている PCC ルール。	"Any-Any" TFT が UE に送信されます。
   「Any-Any」フィルタ + packetFilterUsage IE を trueに設定した新しいルールを使用した既存の TFT。	SMF は PCF から受信した新しいパケット フィルタで TFT を更新します。	以前の QoS ルールが削除され、新しい QoS ルールが UE に対して作成されます。
   TFT packetFilterUsage = true を持つ最後のルールが削除されます。	SMF は、現在のルールを削除し、「Any-Any」フィルタを使用して新しいルールを追加することで、更新 TFT をプッシュします。
   packetFilterUsage=trueのデフォルト フローに対する複数の PCC ルール。	SMF は、 packetFilterUsage IE が trueになっているルールを 1 つだけ選択します。	SMF は、 packetFilterUsage IE が trueに設定されている他のすべてのルールを拒否します。
   SMF には packetFilterUsage=true の PCC ルールがすでにあり、PCF は packetFilterUsage=trueの新しいルールを送信します。	SMF は新しいルールを拒否します。

（注）

SMF は、DQR（デフォルトの QoS ルール）= 1 およびパケットフィルタを「Any-Any」または特定の TFT として N1 インターフェイスを介してデフォルト フローに対して 1 つの QoS ルールのみを送信します。SMF は、FBR IE の PCC ルールの QoS 説明でビットレートを送信または追加しません。UE の MBR は、セッション AMBR から取得する必要があります。 SMF は、N4 インターフェイスを介して PCC ルールの QoS 記述の CREATE_QER を送信しません。PCC ルールの PDR の QER ID は、セッション ルールの QER ID に設定されます。SMF では PCC ルールの PDR に追加の QER が含まれており、ゲート ステータスのみが有効または無効になっています。QER には MBR 情報は含まれません。

N7 最適化サポートの場合、SMF は N7 作成メッセージで UE IP アドレスを送信することで、N7 更新メッセージをスキップします。CLI コマンドを使用してこの機能を有効にすると、SMF は IP アドレスを割り当て、UPF の選択を実行してから PCF との連携を開始します。IP の再割り当てが必要な代替 UPF を選択するように SMF を構成している場合、N4 の障害時に、SMF は N4 成功メッセージの後に N7 更新メッセージを送信して新しい IP アドレスを示します。

N7 最適化を構成するには、次の構成例を使用します：

config 
   profile dnn dnn_profile_name 
      policy [ local | optimized ] 
         rat-type [ nr | wlan | eutra ] 
      end 

注：

• profile dnn dnn_profile_name :：DNN プロファイル名を指定します。 dnn_profile_name 英数字の文字列である必要があります。

• policy [ local | optimized ] ：PCF とのやり取りを有効または、無効にします。

  • local ：SMF は UPF と対話しません。

    （注）	このパラメータは、セッションの作成時にのみ適用され、引き継ぎ中は変更されません。 policy local を構成する場合、PCF または PCRF の構成は必須ではありません。

  • optimized ：SMF は、N7 作成メッセージで UE IP アドレスを送信することで、N7 更新をスキップします。

  （注）	policy local と policy optimized の両方を同時に構成した場合は、 policy local が優先されます。

• rat-type [ nr | wlan | eutra ] ：このキーワードは、指定された RAT タイプについて PCF と交換されるメッセージの数を減らします。

  （注）	このキーワードは任意です。 rat-type が構成されていない場合、 policy local または policy optimized は、NR、WLAN、および EUTRA の 3 つの RAT タイプすべてに対して有効です。

次のコール フローでは、ダイナミック ADC ルールをインストールするプロセスについて説明します。

次の段階では、ダイナミック ADC ルールを変更するプロセスについて説明します。

次のコール フローは、ダイナミック ADC ルールを削除するプロセスについて説明しています。

（注）	REMOVE_FAR は、ルールが削除され、他のルール PDR がこれらの FAR に関連付けられていない場合にのみ送信されます。

Gx を介したダイナミック ADC ルールの適用機能では、次の統計情報がサポートされています。

• policy_adc_total：このメトリックは、インストールされているダイナミック ADC ルールの合計数を反映します。このメトリックは、デバッグ レベルで有効になります。この機能をサポートするために、次の新しいラベルが追加されました。

  • mute：このラベルは、ダイナミック ADC ルールに対してミュート AVP が有効になっているかどうかを指定します。このラベルに表示されるフィールド値は [TRUE] または [FALSE] です。

• policy_dynamic_pcc_rules_total：このメトリックは、PCF からプッシュされたダイナミック ルールの総数を表示します。次に、この機能をサポートするために追加された新しいラベルを示します。

  • is_adc：このラベルは、ダイナミック ルールが ADC ルールであるかどうかを指定します。このラベルに表示されるフィールド値は [TRUE] または [FALSE] です。

  • mute：このラベルは、ダイナミック ルールに対してミュート AVP が有効になっているかどうかを指定します。このラベルに表示されるフィールド値は [TRUE] または [FALSE] です。

このセクションでは、ダイナミック ADC ルールに関連する構成を表示するために使用できる show コマンドと出力について説明します。

次の monitor subscriber コマンドが拡張され、Gx インターフェイスと N4 インターフェイスの両方の ADC ダイナミック ルールの TDF App ID、TosTraffic AVP、ミュート AVP の情報が表示されるようになりました。

[unknown] smf# monitor subscriber supi imsi-* capture-duration 1000 internal-messages yes

ChargingRuleInstall: 
                            ChargingRuleInstall[0]: 
                                ChargingRuleDefinition: 
                                    ChargingRuleDefinition[0]: 
                                        ChargingRuleName: dynamicAdc1
                                        RatingGroup: 
                                            Value: 40
                                        ServiceIdentifier: 
                                            Value: 30
                                        Precedence: 
                                            Value: 70
                                        QoSInformation: 
                                            QoSClassIdentifier: 
                                                Value: QCI_7(7)
                                            MaxRequestedBandwidthUL: 
                                                Value: 2000
                                            MaxRequestedBandwidthDL: 
                                                Value: 2000
                                            GuaranteedBitrateUL: 
                                                Value: 1000
                                            GuaranteedBitrateDL: 
                                                Value: 1000
                                            AllocationRetentionPriority: 
                                                PriorityLevel: 5
                                                PreEmptionCapability: 
                                                    Value: PREEMPTION_CAPABILITY_DISABLED(1)
                                                PreEmptionVulnerability: 
                                                    Value: PREEMPTION_VULNERABILITY_ENABLED(0)
                                        ReportingLevel: 
                                            Value: RATING_GROUP_LEVEL(1)
                                        Online: 
                                            Value: ENABLE_ONLINE(1)
                                        Offline: 
                                            Value: DISABLE_OFFLINE(0)
                                        MeteringMethod: 
                                            Value: DURATION_VOLUME(2)
                                        MuteNotification: 
                                            Value: MUTE_REQUIRED(0)
                                        FlowStatus: 
                                            Value: ENABLED(2)
                                        TdfApplicationIdentifier: qci7
                                        ToSTrafficClass: 20fe

この機能は、PDU セッション ライフサイクル機能によって提供される機能を利用します。

アクティブな課金サービスの構成（ルールベース、関連するルール定義、課金アクションを含む）が完了すると、SMF は構成された値を処理し、構成された値から PCC ルール、QoSData、および ChargingData を導出します。これらのエンティティを作成するには、次の原則が使用されます。

1. QoSデータ：

   1. 設定された課金アクションごとに QoSDesc が作成されます。

   2. 課金アクションで構成される flow-limit-bandwidth は、QoSData の GBR/MBR を提供します。

   3. 課金アクションで構成された QCI と ARP は、QoS データの 5QI と ARP を構成します。QCI と ARP が構成されていない場合は、デフォルトの QoS フローの 5QI と ARP がこの QoS データに関連付けられます。

2. ChargingData：

   1. 課金アクションの下の billing-action 構成により、作成された ChargingData でオフライン課金を有効にするかどうかが決まります。

   2. 課金アクションの下の cca charging credit 構成により、作成された ChargingData でオンライン課金を有効にするかどうかが決まります。

   3. ChargingData の料金設定グループとサービス ID は、課金アクションのコンテンツ ID とサービス識別子を構成することで提供されます。

3. PCCR ルール：

   1. ルールベースの下にある各 ruledef は、PCCRule で作成されます。

   2. 課金アクションで構成された packet-filter は、PCCRule の FlowInformation に使用されます。

   3. ルールベース構成定でこの ruledef に関連付けられている QoSData と ChargingData は、この PCCrule の refQoS と refChg を形成します。

作成されたすべての PCCRules、QoSData、および ChargingData は、ルールベースごとに保存されます。

1. PDU セッションの作成中に、PCF はルールベース名（PCF が送信しない場合は upf-apn で設定された値）を PCCRule として送信します。このとき、ID が cbn# 構成済みルールベース名に設定されています。また、ID が crn# 設定済みルール定義名に設定された別の PCCRule としてアクティブ化される事前定義済みルールを送信する場合もあります。このような PCC ルールにはすべて、RuleId 属性のみが存在します。

2. このような要求を受信すると、SMF は、受信したルールベースおよびルール定義名に対応する作成済みの PCCRules、QoSData、および ChargingData を選択し、これらを使用して QoSModel で QoS フローを作成します。

3. N4 インターフェイスでは、SMF は、「rulebase」という名前の Cisco 独自の IW の CreatePDR IE でルールベース名を送信します。

4. すべてのアクティブ化された事前定義ルールについて、SMF は「事前定義されたルールのアクティブ化」IE の ruledef 名を含む 1 つのアップリンクと 1 つのダウンリンク PDR を送信します。

5. UPF にも、アクティブ課金サービス用の同様の構成があります。ルールベース名とルール定義名から、対応する QER と URR を作成できます。

6. N1 および N2 インターフェイスでは、事前定義された静的ルールの処理はダイナミック ルールの処理と同じです。

7. すべての静的ルールおよびアクティブ化された事前定義ルールについて、パケットフィルタが構成されている場合、QoSR ルールは N1 インターフェイスに送信されます。

8. フローの GFBR および MFBR は、任意の時点ですべての静的およびアクティブ化済みの事前定義済みルールに関連付けられた QoSData の GBR/MBR を使用して計算され、同じものが N2 インターフェイスの AuthorizedQoSDescription IE で N1 インターフェイスに送信されます。

1. PDU セッションの変更中に、PCF はルールベース名を PCCRule として、cbn#configured rulebase name に設定された ID とともに送信します。事前定義されたルールの場合、PCF は新しいルール crn#configured ruledef 名をアクティブにするか、既存のルール（crn#"nil"）を削除できます。このような PCC ルールにはすべて、RuleId 属性のみが存在します。

2. 新しいルール追加要求を受信すると、SMF は、受信したルールベースおよびルール定義名に対応する作成済みの PCCRules、QoSData、および ChargingData を選択し、これらを使用して QoSModel で QoS フローを作成します。

3. 既存のルールの削除要求を受信したときに、SMF が既存のものとは異なる値（nil 値）またはルールベース名を持つ ruledef 名を受け取った場合、SMF は QoSModel の以前のルールベース名または ruledef に対応する QoS フローを削除します。

4. N4 インターフェースにおいて、SMF は Cisco 独自の IW「rulebase」内の CreatePDR IE に新しいルールベース名を送信し、古いルールベース名に対応する PDR ID を伴う RemovePDR を送信します。

5. すべてのアクティブ化された事前定義ルールについて、SMF は「事前定義されたルールのアクティブ化」IE の ruledef 名を含む 1 つのアップリンクと 1 つのダウンリンク PDR を送信します。

6. 非アクティブ化されたすべての事前定義済みルールに対して、SMF は、事前定義済みルールに対応する PDR ID とともに RemovePDR を送信します。

7. UPF にも、アクティブ課金サービス用の同様の構成があります。ルールベース名とルール定義名から、対応する QER と URR を作成または削除できます。

8. N1 および N2 インターフェイスでは、事前定義された静的ルールの処理はダイナミック ルールの処理と同じです。

9. すべてのスタティック ルールおよびアクティブ化/非アクティブ化された事前定義ルールについて、パケット フィルタが構成されている場合、QoSR ルールは N1 インターフェイスに送信されます。

10. フローの GFBR および MFBR は、任意の時点ですべてのスタティックおよびアクティブ化/非アクティブ化済みの事前定義済みルールに関連付けられた QoSData の GBR/MBR を使用して計算され、同じものが N2 インターフェイスの AuthorizedQoSDescription IE で N1 インターフェイスに送信されます。

このセクションでは、課金アクションの構成方法を説明します。課金アクションは、構成されたルールに一致したときに実行されるアクションを意味します。アクションの範囲として、アカウンティング レコード（例：EDR）の生成から IP パケットのドロップなどまでが含まれます。また、課金アクションによって、使用量計算の原則を規定します。再送信されたパケットをカウントするかどうか、および課金情報にどのプロトコルフィールド（L3/L4/L7 など）を使用するかがこれに当たります。

ruledef に関連付けられた QoS および課金関連パラメータを定義するには、次の構成例を使用します。

config 
    active-charging service service_name 
       charging-action charging_action 
          allocation-retention-priority priority  [ pci pci_value 
          | pvi pvi_value billing-action egcdr cca 
          charging credit [ rating-group coupon_ id  
          ] [ preemptively-request ]  
          content-id content_id 
          flow action { discard [ downlink | uplink ] | redirect-url  
          redirect_url | terminate-flow } 
          flow limit-for-bandwidth { { direction { downlink | uplink }  
          peak-data-rate bps peak-burst-size bytes violate-action  
          { discard | lower-ip-precedence } [ committed-data-rate  
          bps committed-burst-size bytes 
          [ exceed-action { discard | lower-ip-precedence  
          } ] ] } | { id id } } 
          nexthop-forwarding-address ipv4_address/ipv6_address 
          qos-class-identifier qos_class_identifier 
          service-identifier service_id 
          tft packet-filter packet_filter_name 
          tft-notify-ue 
          tos { af11 | af12 | af13 | af21 | af22 | af23 | af31 | af32  
          | af33 | af41 | af42 | af43 | be | ef | lower-bits tos_value  
          } [ downlink | uplink ] 
          end 

注：

• charging-action charge_action_name : 課金アクションの名前を指定します。 charge_action_name は 、1 ～ 63 文字の英数字の文字列である必要があります。また、句読点を含めることができます。各家禽アクションには一意の名前が必要です。

• 指定された課金アクションが存在しない場合は作成され、CLI モードは課金アクションを構成できる ACS 課金アクション構成モードに変わります。

• 指定された課金アクションが存在する場合、CLI モードはその課金アクションの ACS 課金アクション構成モードに変更されます。

• allocation-retention-priority priority [ pcipci_value | pvi pvi_value ：割り当て保持優先順位（ARP）を構成します。 priority は 1 ～ 15 の範囲の整数値である必要があります。

  • pci pci_value ：プリエンプション機能表示（PCI）値を指定します。次のオプションがあります。

    • MAY_PREEMPT：フローをプリエンプション処理できます。これはデフォルト値です。

    • NOT_PREEMPT：フローをプリエンプション処理できません。

  • pvi pvi_value ：プリエンプション脆弱性の兆候（PVI）の値を指定します。次のオプションがあります。

    • NOT_PREEMPTABLE：フローをプリエンプション処理できません。これはデフォルト値です。

    • PREMPTABLE：フローをプリエンプション処理できます。

• billing-action ：特定のルール定義に一致するパケットの課金アクションを構成します。

• cca charging credit ：クレジット制御アプリケーション（CCA）を有効または無効にし、RADIUS/Diameter のプリペイド課金動作を構成します。

• content-id ：料金設定グループを構成します。

• flow action ：ルール定義に一致するパケットで実行するアクションを指定します。

• flow limit-for-bandwidth ：MBR や GBR などの QoS パラメータを構成します。

  • Peakdatarate（MBR）：デフォルトは 3000 bps です

  • Peakburstsize：デフォルトは 3,000 バイトです

  • [committedDataRate（GBR）]：デフォルトは 144000 bps です

  • commitedBurstSize：デフォルトは 3000 バイト

• nexthop-forwarding-address ipv4v6_address | ipv4_address | ipv6_address ：この APN のネクストホップ転送アドレスを構成します。

• qos-class-identifier qos_class_identifier ：課金アクションの QoS クラス識別子（QCI）を構成します。 qos_class_identifierは 、1 ～ 9 または 128 ～ 254 の範囲の整数である必要があります（演算子固有）。

• service_identifier service_id ：生成された課金レコードで使用するサービス ID を構成します。 service_id は 、1 ～ 2147483647 の範囲の整数である必要があります。

• tft packet-filter packet_filter_name ：現在の課金アクションに追加する、またはアクションから削除するパケットフィルタを指定します。 packet_filter_name は 、1 ～ 63 文字の英数字の文字列である必要があります。

• tft-notify-ue ：特定のトリガ条件に基づいて UE に対する TFT 更新を制御します。

• tos ：Type of Service（ToS）オクテットを構成します。

パケット フィルタを構成するには、次の構成例を使用します。

config 
   active-charging service service_name 
      packet-filter packet_filter_name 
         direction { bi-directional | downlink | uplink } 
         ip local-port { = port_number | range start_port_number to 
         end_port_number } 
         ip protocol = protocol_number 
         ip remote-port { = port_number | range start_port_number to  
         end_port_number } 
         ip tos-traffic-class = { type-of-service | traffic class } 
         mask { = mask-value} 
         priority priority 
         end 

注：

• packet-filter packet_filter_name ：UE に送信するパケットフィルタを構成します。 packet_filter_name は 、1 ～ 15 文字の英数字の文字列である必要があります。

• direction { bi-directional | downlink | uplink } ：パケット フィルタを適用する必要がある方向を設定します。デフォルト値は bi-directional です。

• ip local-port ：現在のパケット フィルタの IP 5 タプル ローカル ポートを構成します。

• ip protocol ：現在のパケット フィルタの IP プロトコルを構成します。

• ip remote-address ：現在のパケット フィルタの IP リモート アドレスを構成します。

• ip remote-port ：現在のパケット フィルタの IP リモート ポートを構成します。

• ip tos-traffic-class ：パケット フィルタ モードで、課金アクションのサービス（TOS）/トラフィック クラスのタイプを構成します。

• priority priority ：現在のパケット フィルタの優先順位を構成します。

は、プロトコル フィールドと状態情報に基づいた複数の L3 ～ L7 プロトコルにおける一連の一致条件を表します。各 ruledef は、アクティブな課金サービス内の複数のルールベースで使用できます。

ACS ルール定義を作成、設定、または削除するには、次の設定例を使用します。

config 
   active-charging service service_name 
      ruledef ruledef_name 
         ip any-match [ = | != ] [ TRUE | FALSE ] 
         ip dst-address { operator { { ipv4_address | ipv6_address 
         } | { ipv4_address/mask | ipv6_address/mask} | 
         address-group ipv6_address } | { !range | range }  

         rule-application { charging | post-processing | routing } 
         end 

注：

• ruledef ruledef_name ：追加、設定、または削除する ruledef を指定します。 ruledef_name は ACS ルールデ の名前である必要があります。また、1 ～ 63 文字の英数字の文字列である必要があり、句読点を含めることができます。各 ruledef には一意の名前を付ける必要があります。ホストプール、ポートマップ、IMSI プール、ファイアウォール、ルーティング、および課金のルール定義には一意の名前を付ける必要があります。

• 指定された ruledef が存在しない場合は作成され、CLI モードは ruledef を設定できる ACS ルールデ コンフィギュレーション モードに変わります。

• 指定された ruledef がすでに存在する場合、CLI モードはその ruledef の ACS ルールデ コンフィギュレーション モードに変わります。ACS ルール定義コンフィギュレーション モードを使用して、個々のルール定義（ruledef）でルール式を作成および管理します。

• ip any-match [= | !=] [TRUE | FALSE ：IPv4/IPv6 パケットに一致するルール式を定義します。コマンドの 演算子 と 条件 は、次を指定します。

  • operator

    • !=：等しくない

    • < =: 等しい

  • 条件

    • FALSE

    • TRUE

• ip dst-address { operator { { ipv4_address | ipv6_address } | { ipv4_address/mask |ipv6_address/mask } | address-group ipv6_address } | { !range | range } host-pool host_pool_name } ：IP ヘッダー内の IP 宛先アドレスフィールドに一致するルール式を定義します。

  • ipv4_address | ipv6_address ：発信トラフィックの宛先ノードの IP アドレスを指定します。 ipv4_address | ipv6_address は、 IPv4 ドット付き 10 進表記または IPv6 コロン区切り 16 進表記の IP アドレスである必要があります。

  • ipv4_address/mask | ipv6_address/mask ：発信トラフィックの宛先ノードの IP アドレスを指定します。 ipv4_address/mask | ipv6_address/mask は、 サブネットマスクビットを含む IPv4 ドット付き 10 進表記または IPv6 コロン区切り 16 進表記の IP アドレスである必要があります。マスク ビットは、サブネット マスクのビット数に対応する数値です。

  • address-group ipv6_address ：ワイルドカード入力や特殊な範囲入力で設定された IPv6 アドレスのグループを指定します。複数のワイルドカード文字を入力として受け入れることができますが、入力できるのは 1 つの 2 バイト範囲入力だけです。ワイルドカード文字の入力と 2 バイトの範囲の入力の両方を、特定の IPv6 アドレス内で一緒に設定できます。

  • コマンドの 演算子 は、次を指定します。

    • !=：等しくない

    • <：次の値以下

    • =：等しい

    • >=: 次の値以上

• multi-line-or all-lines ：単一の ruledef で複数の URL 式を指定できます。ruledef が評価されるときに、multi-line-or all-lines コマンドが設定されていると、論理 OR 演算子が ruledef 内のすべてのルール式に適用され、ruledef が一致するかどうかが判断されます。multi-line-or all-lines コマンドが設定されていない場合、論理 AND 演算子がすべてのルール式に適用されます。

• rule-application { charging | post-processing | routing } ：ルール定義のルール適用を指定します。

  • charging ：現在の ruledef が課金目的であることを指定します。

  • post-processing ：現在の ruledef が後処理用であることを指定します。これにより、パケットのルール照合が無効になっている場合でも、パケットを処理できます。

  • routing ：現在の ruledef がルーティング用であると指定します。アクティブな課金サービスでのルーティングには、最大 256 のルール定義を定義できます。デフォルトで、ディセーブルになっています。

group-of-ruledefs には最適化可能な ruledef を含めることができます。Ruledef グループの最適化は、ruledef のグループの ruledef の最適化機能と、ルールベースのグループの最適化の設定に依存します。

新しい ruledef を追加すると、次のチェックが行われます。

• 新しい ruledef が既存の ruledef グループの一部であるかどうかを判別します。

• 新しい ruledef が最適化を必要としているかどうかを識別します

ruledef のセットを組み合わせて同じ課金アクションを適用するには、次の設定例を使用します。

config 
   active-charging service service_name 
      group-of-ruledefs ruledef_group_name 
         add-ruledef priority ruledef_priority ruledef ruledef_name 
         exit 

注：

• group-of-ruledefs ruledef_group_name ：追加、設定、または削除の対象となる ruledef グループ名を指定します。このコマンドでは、最大 128 個の ruledef 設定グループを指定できます。

• add-ruledef ：このコマンドを使用すると、ruledef のグループに ruledef を追加または削除できます。このコマンドでは、最大 128 個の ruledef 設定が可能です。

• priority ：ruledef の現在のグループでの ruledef の優先順位を指定します。 ruledef_priority は 、1 ～ 10000 の範囲の整数である必要があります。

• ruledef ruledef_name ：現在のルール定義のグループに追加するルール定義の名前を指定します。ruledef_name は 1 ～ 63 文字の英数字の文字列である必要があります。

ルールベースおよび事前定義されたルールのプレフィックス構成は、PCF からの静的ルールのインストールに必須です。SMF は、プレフィックス付きおよびプレフィックスなしの事前定義ルールのインストールをサポートします。SMF は、事前に定義されたルールと静的ルールの両方で group-of-ruledef のインストールもサポートしています。

ルールベースのプレフィックスと事前定義されたルールのプレフィックスを構成するには、次の構成例を使用します。

config 
   profile network-element pcf pcf_service_name 
      predefined-rule-prefix predef_rule_prefix 
      rulebase-prefix rulebase_prefix 
      end 

注：

• predefined-rule-prefix predef_rule_prefix ：追加する事前定義されたルールのプレフィックスを指定します。たとえば、事前に定義されたルールのプレフィックスは cbr です。

• これは、事前定義済みルールのオプションの構成です。PCF ネットワーク要素プロファイル内に定義されたプレフィックスがない場合、事前定義されたルールの適用は 3GPP TS 29.244 仕様で定義されているように動作します。

• rulebase-prefix rulebase_prefix ：追加するルールベースのプレフィックスを指定します。たとえば、ルールベースのプレフィックスは rbn です。これは、静的ルールの必須構成です。

構成された APN を使用するサブスクライバに使用される ACS ルールベースを有効にして構成するには、次の構成例を使用します。

config 
   apn apn_name 
      active-charging rulebase rulebase_name 
      end 

注：

• active-charging rulebase rulebase_name ：ACS ルールベースの名前を指定します。 rulebase_name は 、1 ～ 63 文字の英数字の文字列である必要があります。

このセクションでは、料金設定およびサービスグループの通信量レポートルール（URR）IDを構成する方法について説明します。

config 
   active-charging service service_name 
      urr-list list_name 
         rating-group rating_id service-identifier service_id_value 
         urr-id urr_id_value 
         end 

注：

• urr-list list_name ：URR リストの名前を指定します。 list_name は 、1 ～ 63 文字の英数字の文字列である必要があります。

• rating-group Rating_id ：課金に使用される料金設定 ID を指定します。 Rating_id は 、0 ～ 2147483647 の範囲の整数である必要があります。

• service-identifier service_id_value ：サービス識別子の値を構成します。 service_id_value は 、0 ～ 2147483647 の範囲の整数である必要があります。

• urr-id urr_id_value ：料金設定/サービス グループの URR 識別子を構成します。 urr_id_value は 、1 ～ 8388607 の範囲の整数である必要があります。

• URR ID の構成は、料金設定グループおよびサービス ID ごとです。異なる料金設定グループとサービス ID の組み合わせについては、URR ID 構成を必要な回数だけ使用します。

GTPP グループの構成するには、次のサンプル構成を使用します。

config 
   gtpp group group_name 
      gtpp trigger { time-limit | volume-limit } 
      end 

注：

• gtpp group group_name ：GTPP グループ名を指定します。 group_name は 、1 ～ 63 文字の英数字の文字列である必要があります。

• gtpp trigger { time-limit | volume-limit } ：CDR のトリガーを構成します。

  • time-limit ：CDR の時間制限トリガーを有効にします。

  • volume-limit ：CDR のボリューム制限トリガーを有効にします。

このセクションでは、アクセス ポイント名（APN）テンプレートを作成する方法について説明します。この APN 構成は UPF 内のアクセスポイント構成を表し、その内でのルールベース名の構成をさらに容易にします。

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

config 
   apn apn_name 
   end 

注：

• apn apn_name ：APN テンプレートの名前を 1 ～ 62 文字の英数字の文字列として指定します。名前は、大文字と小文字が区別されません。

構成された APN に GTTP グループを関連付けるには、次のサンプル構成を使用します。

config 
   apn apn_name 
      gtpp group group_name 
      end 

注：

• gtpp group group_name ：定義済みの GTPP グループを構成済みの APN に関連付けます。

このセクションでは、ACS ルールベースを作成、設定、または削除する方法について説明します。ルールベースは、フローと一致するプロトコル ルール、および一致したフローに対して実行される関連アクションのコレクションです。サブスクライバ/APN に使用する特定のルールベースが設定されていない場合、デフォルトのルールベースが使用されます。

ルールベースの設定は、指定されたすべての設定を組み合わせて静的および事前定義された PCC ルールを構築する設定です。

ACS ルールベースを構成するには、次の構成例を使用します。

config 
   active-charging service service_name 
      rulebase rulebase_name 
         action priority action_priority { [ dynamic-only ]  
         | static-and-dynamic | timedef timedef_name ]  
         { group-of-ruledefs ruledefs_group_name | 
         ruledef ruledef_name } charging-action charging_action_name 
         [ monitoring-key monitoring_key ] [ description description ] } 
         cca quota { holding-time holding_time content-id content_id  
         | retry-time retry_time [ max-retries retries ] } 
         cca quota time-duration algorithm { consumed-time seconds  
         [ plus-idle ] | continuous-time-periods seconds | 
         parking-meter seconds} [ content-id content_id]    
         credit-control-group cc_group_name 
         dynamic-rule order { always-first | first-if-tied } 
         egcdr threshold { interval interval  
         [ regardless-of-other-triggers ] | volume { downlink | total | 
         uplink } bytes } 
         route priority route_priority ruledef ruledef_name  
         analyzer { dns | file-transfer | ftp-control | ftp-data | h323 
         | http | imap | mipv6 | mms | pop3 | pptp | radius | rtcp | rtp 
         | rtsp | sdp | secure-http | sip [ advanced | basic-and-advanced 
         ] 
         | smtp | tftp | wsp-connection-less | wsp-connection-oriented } 
         [ description description ] 
         tcp check-window-size 
         tcp mss tcp_mss { add-if-not-present | limit-if-present } 
         tcp packets-out-of-order { timeout timeout_duration| 
         transmit [ after-reordering | immediately ] } 
         end 

注：

• rulebase rulebase_name ：ACS ルールベースの名前を指定します。 rulebase_name は 、1 ～ 63 文字の英数字の文字列である必要があります。

• action priority action_priority { [ dynamic-only ] | static-and-dynamic | timedef timedef_name ] { group-of-ruledefs ruledefs_group_name | ruledef ruledef_nameCharging_action_namemonitoring_key } charging-action 説明 ] [ description ： [ monitoring-key ruledef ] } が一致する優先順位と、関連する課金アクションを構成します。

  • 優先度 は 1〜65535 の範囲の整数である必要があります

  • monitoring_key は、100000 ～ 4000000000 の範囲の整数である必要があります。

  設定した ruledef、group-of-ruledefs、Charging アクションを削除するには、 no action priority action_priority コマンドを使用します。

  Important

  現在、SMF は、ruledef、group-of-ruledefs、および課金アクションの個別の削除をサポートしていません。

• cca quota { holding-time hold_time content-id content_id | retry-time retry_time [ max-retries retries ] } ：オンライン課金のクォータを構成します。

  • holding_time は 1 ～ 4000000000 までの整数である必要があります。

  • content_id は 、1 ～ 2147483647 の範囲の整数である必要があります

  • retry_time は、0 ～ 86400 の範囲の整数である必要があります。

  • retries は 1 ～ 65535 の範囲の整数である必要があります。

• cca quota time-duration algorithm { consumed-time consumed_time [ plus-idle ] | continuous-time-periods continuous_time | parking-meter parking_meter } [ content-id content_id ]

  • consumed_time は、1 ～ 4294967295 秒の範囲の整数である必要があります

  • content-id は 1 ～ 2147483647 の範囲の整数である必要があります

  • continuous_time は、1 ～ 4294967295 秒の範囲の整数である必要があります

  • parking_meter は、1 〜 4294967295 秒の範囲の整数である必要があります

• credit-control-group cc_group_name ：このルールベースで使用されるオンライン課金のパラメータを設定します。 cc_group_name は 、1 ～ 63 文字の英数字の文字列である必要があります。

• dynamic-rule order ：ルールベース内のスタティックルールに対するダイナミックルールの照合の順序を構成します。

• egcdr threshold { interval interval [ regardless-of-other-triggers ] | volume { downlink | total | uplink } bytes } ：オフライン充電のしきい値を構成します。

  • interval は、60 ～ 40000000 の範囲の整数である必要があります。

  • downlink は、100000 ～ 4000000000 の範囲の整数である必要があります。デフォルト：4000000000。

  • uplink は、100000 ～ 4000000000 の範囲の整数である必要があります。デフォルト：4000000000。

  • total は、100000 ～ 4000000000 の範囲の整数である必要があります。

• route priority route_priority ruledef ruledef_name analyzer { dns | file-transfer | ftp-control | ftp-data | h323 | http | imap | mipv6 | mms | pop3 | pptp | radius | rtcp | rtp | rtsp | sdp | secure-http | sip [ advanced | basic-and-advanced ] | smtp | tftp | wsp-connection-less | wsp-connection-oriented } [ description 説明 ] ：このコマンドは UPF でのみ使用されます。

  • route_priority は、0 〜 65535 の範囲の整数である必要があります。

  • ruledef_name は、1 ～ 63 文字の英数字の文字列である必要があります。

• tcp check-window-size ：このコマンドは UPF でのみ使用されます。

• tcp mss tcp_mss ：このコマンドは UPF でのみ使用されます。 tcp_mss は 496 ～ 65535 の範囲の整数である必要があります。

• tcp packets-out-of-order { timeout timeout_duration | transmit [ after-reordering | immediately ] } ：このコマンドは UPF でのみ使用されます。

  • timeout_duration は 100 ～ 30000 の範囲の整数である必要があります。デフォルト値は 5000 です。

既存の DNN プロファイルで UPF APN プロファイルを構成するには、次の構成例を使用します。

config 
   profile dnn dnn_profile_name 
      upf apn apn_name 
      end 

注：

• upf apn apn_name ：UPF APN プロファイル構成を有効にします。このプロファイルは、既存の DNN プロファイル構成で構成されます。 apn_name は 、1 ～ 62 文字の英数字の文字列である必要があります。

QoS パラメータを構成するには、次の構成例を使用します。

config 
   profile qos qos_profile_name 
      ambr { ul uplink_ambr | dl downlink_ambr } 
      arp { preempt-cap preemption_capability |   
      preempt-vuln preemption_vulnerability |  
      priority-level priority_level } 
      max data-burst burst_volume 
      priority qos_priority 
      qi5 5qi_value 
      exit 

注：

• ambr { ul uplink_ambr | dl downlink_ambr } ：アップリンク（サブスクライバからネットワーク）およびダウンリンク（ネットワークからサブスクライバ）トラフィックの集約最大ビットレート（AMBR）を定義します。

• arp preempt-cap preemption_capability ：プリエンプション機能フラグを指定します。次のオプションがあります。

  • MAY_PREMPT：ベアラーがプリエンプション処理される可能性がある。

  • NOT_PREMPT：ベアラーをプリエンプトできない。

• arp preempt-vuln preemption_ulnerability ：プリエンプション脆弱性フラグを指定します。次のオプションがあります。

  • PREMPTABLE：ベアラーがプリエンプション処理される可能性があります。

  • NOT_PREMPTABLE：ベアラーをプリエンプトできません。

• arp priority-level priority_level ：サービス データの割り当てと保持の優先順位（ARP）を定義します。 priority_level のデフォルト値は 8 です。

• max data-burst burst_volume ：最大データ バースト ボリュームを定義します。 burst_volume は 1 ～ 4095 の範囲の整数である必要があります。

• priority qos_priority ：5QI 優先順位レベルを指定します。 qos_priority は 、1 〜 127 の範囲の整数である必要があります。

• qi5 5qi_value ：承認された QoS パラメータの 5G QoS 識別子（5QI）を指定します。5qi_value は 0 ～ 255 の範囲の整数である必要があります。

この項では、静的 PCC ルール サポート構成を確認する方法について説明します。

機能構成の詳細を確認するには、以下のコマンドを使用します。

show full-configuration

次に、この show コマンドの出力例を示します。

active-charging service acs 
charging-action ca1 
  arp priority-level 15 preempt-cap MAY_PREEMPT preempt-vuln PREEMPTABLE 
  cca charging credit preemptively-request 
  content-id 320001 
  flow limit-for-bandwidth direction uplink peak-data-rate 1000000 peak-burst-size 1000000 violate-action discard committedDataRate 2000000 committed-burst-size 2000000 exceed-action lower-ip-precedence 
  nexthop-forwarding-address fa00:965a:c263:25::16/128 
  qos-class-identifier 9 
  service-identifier 32000 
  tft packet-filter pf1 
  tft-notify-ue 
  tos af11 downlink 
rulebase rb1 
  cca quota time-duration algorithm parking-meter 1000 content-id 18000 
  credit-control-group cg1 
  dynamic-rule order first-if-tied 
  egcdr threshold volume total 400000 
  tcp packets-out-of-order transmit immediately 
  action priority 95 timedef ruledef rd6 charging-action ca6 description ruledef 
  action priority 96 ruledef rd3 charging-action ca5 
  action priority 97 group-of-ruledefs grd3 charging-action ca4 monitoring-key 200000 
  action priority 98 static-and-dynamic group-of-ruledefs grd2 charging-action ca2 
  action priority 99 dynamic-only ruledef rd1 charging-action ca1 monitoring-key 100000 
  action priority 100 dynamic-only group-of-ruledefs grd1 charging-action ca1 monitoring-key 100000 description gruledefs 
  route priority 1 ruledef rd1 analyzer dns description dns 
exit 
packet-filter pk1 
  direction uplink 
  ip local-port = 23 
  ip protocol = 23 
  ip remote-address = 209.165.201.0/27 
  ip remote-port = 23 
  ip tos-traffic-class = 23 mask = 10 
  priority  4 
exit 
ruledef prepaidBgl 
  multi-line-or all-lines 
  rule-application charging 
  ip any-match = TRUE 
  ip server-ip-address range host-pool 12 
  ip dst-address = 209.165.201.10 
exit 
urr-list urrlocal 
  rating-group 1 service-identifier 1 urr-id 2 
  rating-group 1 service-identifier 3 urr-id 2 
exit 
exit 

group-of-ruledefs の構成の詳細を確認するには、次のコマンドを使用します。

show running-config

次に、この show コマンドの出力例を示します。

show running-config 
profile network-element pcf pcf1 
rulebase-prefix   rbn 
predefined-rule-prefix cbr 
! 
active-charging service acs1 
group-of-ruledefs IPV6-whtlst-https_2300 
  add-ruledef priority 1 ruledef IPV6-whtlst-https_2300_01 
  add-ruledef priority 2 ruledef IPV6-whtlst-https_2300_02 
  add-ruledef priority 3 ruledef IPV6-whtlst-https_2300_03 
  add-ruledef priority 4 ruledef IPV6-whtlst-https_2300_04 
  add-ruledef priority 5 ruledef IPV6-whtlst-https_2300_05 
  add-ruledef priority 6 ruledef IPV6-whtlst-https_2300_06 
  add-ruledef priority 7 ruledef IPV6-whtlst-https_2300_07 
  add-ruledef priority 8 ruledef IPV6-whtlst-https_2300_08 
  add-ruledef priority 9 ruledef IPV6-whtlst-https_2300_09 
  add-ruledef priority 10 ruledef IPV6-whtlst-https_2300_10 
  add-ruledef priority 11 ruledef IPV6-2dns-whtlst-https_2300_01 
  add-ruledef priority 12 ruledef IPV6-2dns-whtlst-https_2300_02 
  add-ruledef priority 13 ruledef IPV6-2dns-whtlst-https_2300_03 
exit 
group-of-ruledefs rdg1 
  add-ruledef priority 10 ruledef rd2 
  add-ruledef priority 12 ruledef rd1 
exit 
exit 

この項では、事前定義済みルールとスタティック ルールの相違点を示します。

• 定義済みルールは、ルールベース構成の下の ruledef に関連付けられたアクション優先順位の dynamic-only キーワードで識別されます。

• 事前定義されたルールは自動的にアクティブになりませんが、ルールごとに PCF によって有効または無効にされます。PCF は、事前定義されたルールをアクティブにするために、ruledef 名だけで、または ruledef とルールベース名をルール ID として一緒に持つ PCC ルールを送信し、以前にアクティブになった ruledef の null エントリを含む PCC ルールマップを送信して、事前定義されたルールを非アクティブにします。

• 静的ルールとは異なり、構成時に定義済みルールに対して QoS バインディングおよびモデリングは行われません。代わりに、PDU セッションのアクティブ化または変更中に、アクティブ化された ruledef の ECS 構成がセッションに適用可能な QoS モデルを作成または変更するために考慮されます。

• N4 インターフェイスでは、PCF によってアクティブ化されたルール定義ごとに 1 つの PDR および対応する FAR が、事前定義されたルール IE のアクティブ化とルールベース名を使用して UPF に送信され、デフォルト PDR のルールベース IE で送信されます。ルールの削除時には、対応する PDR が削除されます。

Note	PCF は事前定義されたルールを送信し、UPF APN に「ルールベース」名が構成されている場合にのみこれらのルールをアクティブにします。それ以外の場合、PCF はルール名を「ルールベース」名とともに送信する必要があります。

3 つの静的ルール、事前定義済みルール、ダイナミック ルールはすべてセッションで共存できます。このような場合は、次の手順に従います。

• 事前構築された QoS モデルは、静的ルール専用に準備されています。PDU セッションのアクティブ化/変更中に、ダイナミックな事前定義されたルールが QoS モデルを変更するために評価され、それに応じて N1、N2、および N4 インターフェイスで変更が行われます。

• ダイナミック ルールのレーティング グループとサービス ID が、構成済みの事前定義済みルールと静的ルールのものと同じである場合、静的ルールと事前定義済みルールの URR ID は、ダイナミックルールに対しても保持されます。

帯域幅 ID 構成を確認するには、次の show コマンドを使用します：

show config 

この show コマンドは、削除されている構成済みの帯域幅 ID などの無効な構成を特定するのに役立ちますが、課金アクションではまだ定義されています。このような無効な構成の場合、この show コマンドは次の出力例に示すように適切なエラーを表示します：

ERROR COMPONENT      ERROR DESCRIPTION
--------------------------------------------------------------------------------------------------
RuleBase        Default bandwidth policy does not exist in rulebase <rba1> for charging action <ca1> .Dropping ruleDef <rda1>
RuleBase        Default bandwidth policy does not exist in rulebase <rba6> for charging action <ca1>.Dropping ruleDef <rda60>
RuleBase        Default bandwidth policy does not exist in rulebase <rba6> for charging action <ca1>.Dropping ruleDef <rda61>
ChargingAction  Packet filter <pkt1234> configured for charging action <ca4> associated with rulebase <rb1> does not exist
BandWidthPolicy Uplink peak data rate less than commited data rate in charging action <ca6>Dropping ruleDef <rd6>

 

SMF は、事前定義されたクエリ パラメータに基づいて、すべてのアクティブな UPF のリストから UPF を選択します。

5GS および EPS コアネットワークは、サブスクライバ セッションの作成中に、選択メカニズムを適用して UPF ノードを選択します。

UPF の選択が UPF の負荷に基づいている場合、SMF は、SMF に関連付けられたアクティブな UPF 間でコールを分散します。3GPP では、N4 リファレンス ポイントにおけるオプション機能として、負荷制御機能が指定されています。この機能により、UPF はその負荷情報を CP 機能に送信できます。

負荷ベースの UPF 選択をサポートするために、SMF は次の Packet Forwarding Control Protocol（PFCP）メッセージで UPF が提供する負荷制御情報を使用します。

• セッション確立応答

• セッションの変更応答

• セッション削除応答

• セッション レポート要求

負荷制御手順の詳細については 、3GPP TS 29.244、リリース 14 の 6.2.3 項を参照してください。SMF は CP 機能に準拠しています。

UPF は、SMF との関連付けを設定するために、N4 関連付けセットアップ要求を開始します。

次に、SMF がコア ネットワークの UPF ノードを選択する方法の概要を示します：

• SMF は、DNN プロファイル構成で構成された UPF 選択ポリシーに基づいて、EPS および 5GS セッションの UPF ノードを選択します。UPF 選択ポリシーは、次のパラメータの組み合わせを定義します：

  • DNN

  • ネットワーク スライス

  • サブスクライバ ロケーション

  • DCNR（EPS コールのみ）

  • サブスクリプション タイプ

  • PDN/PDU セッション タイプ

• UPF 選択ポリシーが DNN プロファイルの構成で定義されていない場合、SMF は 取得したロケーションの DNN または 要求された DNN に基づいて UPF を選択します。

• SMF では、適切なノードをクエリするために使用する UPF 選択基準を定義できます。

• 複数の UPF が選択基準に一致する場合、SMF はアクティブな UPF を選択し、優先順位と負荷情報に基づいてそれらをソートします。次に、SMF は N4 セッション確立が成功するまで、UPF へのアクセスを 1 つずつ試行します。

• SMF は、UPF によって提供された負荷情報を保存し、新しいセッションの UPF の選択に使用します。SMF は、（DNN ベースの）アクティブ UPF 候補の中から負荷の少ない UPF を選択します。

• SMF は、各 UPF に対して静的に構成された優先順位とキャパシティを考慮します。UPF が負荷情報を静的に送信しない場合、SMF は構成された容量を使用して UPF を選択します。

• SMF は、特定の場所でより優先される UPF を選択します。UPF の最終的なプライオリティは、UPF のプライオリティと UPF グループのプライオリティの両方を使用して決定されます。UPF グループの優先順位の構成については、 UPF グループへの優先順位の割り当て セクションを参照してください。

ここでは、UPF 選択方法の構成方法について説明します。

UPF の選択は、クエリ パラメータによって異なります。選択したクエリ パラメータに基づいて、次の構成を使用します。

• EPS の ECGI グループ プロファイルの作成

• 5GS の NCGI グループ プロファイルの作成

• トラッキング エリア ID グループの構成

• ロケーション エリア グループ プロファイルの作成

• UPF グループの定義

• UPF グループと UPF ネットワーク要素との関連付け

• UPF 選択クエリ パラメータの定義

• UPF 選択クエリ パラメータと DNN プロファイルの関連付け

• UPF アドレスの構成

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

cnSGWc および SMF を備えたコンバージド コア ゲートウェイは、コンバージェンスを実現するためのコンバージド UP ノードの選択をサポートします。この機能により、UE 向けに最適化されたデータ パスを作成できます。

SMF は、セッション作成要求（CSR）メッセージで受信した SGW-U ノード名に基づいて、同じ場所に配置された UPF の選択を実行します。

このセクションでは、4G ネットワークでの PDN セッションの確立中に SMF が同じ場所にある UPF の選択を処理する方法について説明します。

SGW-U ノード名が CSR で使用可能な場合、SMF はノード名に基づいて設定から UPF を取得します。

次に、SMF は既存の UPF 選択ロジックを使用し、それに応じて UPF のリストを取得します。SMF は、SGW-C が選択した UPF が派生した UPF リストに存在するかどうかを確認します。

SGW-C で選択された UPF が導出 UPF リストに存在し、その優先順位が導出 UPF リスト内の最も高い優先順位と一致する場合、SGW-C 選択 UPF が選択されます。それ以外の場合は、派生リストの優先順位 UPF が選択されます。

SGW-U ノード名がない場合、SMF は既存の UPF 選択アルゴリズムに従います。

共存 UPF を選択するには、次の構成例を使用します。

config 
   profile network-element upf upf_name 
      node-id value 
      end 

注：

• profile network-element upf upf_name ：UPF のプロファイル名を指定します。

• node-id value ：このキーワードは、UPF のノード ID の構成を支援します。SMF は、このノード名を SGW-U ノード名と比較して、共存 UPF を選択します。 value は英数字の文字列です。

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

upf_selection_stats

説明：同じ共存 UPF が SMF によって選択された合計回数を表示します。

Metrics-Type：カウンタ

ラベル

• upf_selection_type

• upf_fqdn

• Preferred

• upf_not_associated

• upf_profile_not_found

• upf_not_active

• n4_failed

• pdu_session_type

• pdu_subscription_type

• snssai

Status:

• attempted

• failure

理由：ステータスが失敗の場合、値は次のいずれかになります。

• upf_not_associated

• upf_profile_not_found

• upf_not_active

• n4_failed

5G コア ネットワークでの UE セッションの確立中に、SMF は既存の UPF 選択ロジックを使用し、選択された UPF のインデックスを PGW-C 制御トンネルのエンドポイント識別子（TEID）に記録します。

MME からセッション作成要求（CSR）を受信すると、cnSGWc は TEID 値がゼロかどうかをチェックします。ゼロの場合、cnSGWc はリモート手順コール（gRPC）メッセージを SMF に送信し、UP ID と UPF IP をフェッチします。

TEID がゼロ以外の場合、SMF は制御 TEID 値の 21 〜 30 のビットをチェックし、UPF インデックスを抽出します。SMF は、抽出された UPF インデックスを使用して、優先される UPF を選択します。

SGW-C は、UE セッションが EPS ネットワークに引き渡されるときに、優先 UPF としてこれを使用します。UPF 選択アルゴリズムによって返されたリストに優先される UPF が存在する場合、cnSGWc は優先順位が最も高い UPF を選択します。つまり、cnSGWc は SMF によって選択されたのと同じ UPF を選択します。この操作により、UE の最適化されたデータ パスを作成できます。

優先される UPF が返されたリストに存在しない場合、cnSGWc は別の UPF を選択します。

このセクションでは、ハンドオーバー シナリオ中に同じ場所に UPF の選択を実行する方法について説明します。

共存 UPF 選択 グループの選択のパラメータを構成するには、次の手順を実行します：

• 共存 UPF 選択を有効にします

• UPF 選択のためのインデックスの構成

PFCP ノード レポートを適切に処理するために、GTP-U ピア アドレスには一意でないセカンダリ セッション キーが含まれている必要があります。Common Data Layer（CDL）には、セッションの詳細とともにピア アドレスと UPF IP アドレスが保存されます。アイドルからアクティブへの移行手順、N2 ハンドオーバー（HO）、5G から 4G HO、または 4G から 5G HO 中に GTP-U ピア アドレスが変更された場合、CDL データベースは古いキーを削除し、新しいキーを追加します。

1. UPF は、失敗した GTP-U ピアの IP アドレスとともに、PFCP ノード レポート要求を SMF に送信します。

2. SMF プロトコルは、ノード ID、つまり要求に含まれる UPF IP アドレスをチェックします。ノード ID が見つからない場合、またはノード ID が関連付けられた状態にない場合、SMF プロトコルは失敗応答を送信します。

3. ノード ID が見つかった場合、ノード マネージャは GTP-U ピアの IP アドレスとノード ID を使用して EPS セッションの CDL をクエリします。ノード マネージャは、対応するセッションをクリアするための一括通知を CDL に送信します。

4. CDL は REST エンドポイント（REST-EP）ポッドに通知を送信して、セッションをクリアします。

5. REST-EP ポッドは、アフィニティに基づいて、サブスクライバのクリア通知を SMF サービスに送信します。SMF サービスは、すべてのインターフェイスのセッションをクリアします。

UPF は、GTER、SRIR、および SPTER とともに PFCP セッション レポートを SMF に送信します。セッションが見つかった場合、SMF は正常な PFCP セッション レポート応答を送信します。その後、SMF は PDU セッションのリリース手順をトリガし、すべてのインターフェイスでセッションを削除します。

新しくサポートされるメッセージ（ノード レポートとセッション レポート）の場合、SMF は PDU セッションの解放手順をトリガします。PDU セッションの解放手順が HO 手順と競合した場合、SMF は HO 中に GTP-U ピア IP が変更されるため、HO 手順を中止しません。これを実現するために、PDU リリース手順では、リリース要求で受信した GTP-U ピア IP アドレスを PDU セッションに存在するアドレスと比較します。2 つのアドレスが異なる場合、SMF はリリース手順を中止します。

重要	コリジョン処理は、ノード レポートによってトリガーされる着信 HO メッセージと clear subscriber コマンドの到着時刻によって異なります。

SMF は再試行タイマーを使用して、GTP-U ピアの保留中のセッションの削除をチェックし、報告します。SMF ノード マネージャの再起動後、セッションが削除されていない場合、これらのセッションはそのまま残ります。

VoWi-Fi サポート機能は、以下の基準に準拠します：

• 3GPP TS 29.244 バージョン 15.6.0：LTE、Interface between the Control Plane and the User Plane nodes

この機能には、次の制限事項があります。

• CDL 通知が失われ、セッションがクリアされない場合、SMF ノード マネージャは 10 分後に 1 回だけ一括削除操作を再試行します。

• ノード レポート要求が到着し、システムが過負荷状態になると、一部の CDL 通知がドロップされます。この場合、SMF は UPF からのエラー通知レポート要求に基づいてセッションのクリーンアップを実行します。

• UPF は現在、ノード レポート要求で 1 つのリモート GTP-U ピアのみを送信しています。そのため、SMF は 1 つのリモート GTP-U ピアだけを検証できます。

CEE Ops-Center で次の構成が実行されると、アラームが追加されます。このアラームは、特定の UPF の GTP-U ピアがダウンしたことを示しています。アラーム データには、GTP-U ピア IP アドレスと UPF IP アドレスが含まれます。

次に、UPF ノード レポート要求に関連するアラート ルールを構成するために CEE Ops-Center で実行される構成の例を示します。

config 
   alerts rules group alert_group_name 
   interval-seconds seconds 
   rule rule_name 
      expression promql_expression 
      severity severity_level 
      type alert-type 
      annotationannotation_name 
      value annotation_value 
      exit 
   exit 

注：

• alerts rules ：Prometheus アラート ルールを指定します。

• group alert_group_name ：Prometheus アラート ルール グループを指定します。1 つのアラート グループにルールの複数のリストを含めることができます。 alert-group-name はアラート グループの名前です。alert-group-name は、0 ～ 64 文字の範囲の文字列にする必要があります。

• interval-seconds seconds ：ルール グループの評価間隔を秒単位で指定します。

• rule rule_name ：アラート ルール定義を指定します。 rule_name はルールの名前です。

アラートの構成例を次に示します。

config 
   alerts rules group NodeReportGTPURemotePeer 
   interval-seconds 300 
   rule NodeReportGTPURemotePeerDown 
      expression smf_protocol_udp_res_msg_total{message_name=\"n4_node_report_req\", message_direction= \“inbound\”, status=\“accepted\”}” 
      severity major 
      type "Communications Alarm" 
      annotation summary 
      value “This alert is fired when the UPF Sends Node Report Request to SMF” 
      exit 
   exit 

show subscriber all コマンドを使用して、GTP-U ピア IP アドレスと GTP-U ピア エンドポイント キーに関連する構成を表示します。この構成データは、失敗したセッションまたは手順の衝突を特定するのに役立ちます。

次に出力例があります。

[unknown] smf# show subscriber all nf-service smf
subscriber-details
{
  "subResponses": [
    [
      "supi:imsi-123456789012345",
      "gpsi:msisdn-223310101010101",
      "pei:imei-123456786666660",
      "psid:5",
      "dnn:intershat",
      "emergency:false",
      "rat:e-utran",
      "access:3gpp access",
      "connectivity:4g",
      "udm-sdm:10.84.17.111",
      "pcfGroupId:PCF-dnn=;",
      "policy:2",
      "pcf:10.84.17.111",
      "upf:10.84.17.111",
      "upfEpKey:10.84.17.111:10.84.17.112",
      "ipv4-addr:poolv4/209.165.202.129",
      "ipv4-pool:poolv4",
      "ipv4-range:poolv4/209.165.202.129",
      "ipv4-startrange:poolv4/209.165.202.129",
      "gtp-peer:10.84.17.112",
      "peerGtpuEpKey:10.84.17.111:10.84.17.111",
      "namespace:smf"
    ]
  ]
}
 

show subscriber count peerGtpuEpKey コマンドを使用して、指定した GTP-U ピアと UPF ノードに関連付けられているセッション数を表示します。

重要	show subscriber count peerGtpuEpKey コマンドは、システム パフォーマンスに影響を与える可能性があるため、慎重に、かつ慎重に考えてください。

show subscriber count peerGtpuEpKey コマンドの出力例を次に示します。

smf# show subscriber count peerGtpuEpKey 30.30.30.63:50.50.0.58
  subscriber-details
  {
    "sessionCount": 12568
  }
 

SMF は、試行、成功、および失敗したノード レベルとセッション レベルの要求の合計数を追跡するために、次の統計情報を保持します。

• SMF_SERVICE_STATS には、次の手順タイプがあります：

  • upf_node_report_pdu_sess_rel

    [試行（attempted）]：ノード レポートがトリガーされた PDU セッションの解放要求の試行回数。

    [成功（successful）]：ノード レポートが原因でトリガーされた、成功した PDU セッションの解放要求の合計数。

    [失敗（failure）]：ノード レポートが原因でトリガーされた、失敗した PDU セッションの解放要求の合計数。

  • upf_sess_report_gter_pdu_sess_rel

    [試行（attempted）]：セッション レポート「GTER」がトリガーされた PDU セッションの解放要求の試行回数。

    [成功（successful）]：セッション レポート「GTER」によりトリガーされた、成功した PDU セッション リリース要求の合計数。

    [失敗（failure）]：セッション レポート「GTER」がトリガーされた、失敗した PDU セッション リリース要求の合計数。

• SMF_PROTOCOL_UDP_REQ_MSG_TOTAL（次のメッセージタイプの場合）。

  • n4_node_report_req

    [試行（attempted）]：ノード レポートがトリガーである試行された N4 要求の合計数。

    [成功（successful）]：ノード レポートが原因でトリガーされた成功した N4 リクエストの合計数。

    [失敗（failure）]：ノード レポートが原因でトリガーされた失敗した N4 要求の合計数。

  • n4_session_report_req

    [試行（attempted）]：セッション レポートが原因でトリガーされた試行された N4 リクエストの合計数。

    [成功（successed）]：セッション レポートが原因でトリガーされた、成功した N4 リクエストの合計数。

    [失敗（failure）]：セッション レポートが原因でトリガーされた失敗した N4 リクエストの合計数。

• 次のメッセージ タイプの SMF_PROTOCOL_UDP_RES_MSG_TOTAL。

  • n4_node_report_res

    [試行（attempted）]：ノード レポートがトリガーされた試行された N4 応答の合計数。

    [成功（successful）]：ノード レポートがトリガーされた成功した N4 応答の合計数。

    [失敗（failure）]：ノード レポートが原因で失敗した N4 応答の合計数。

  • n4_session_report_res

    [試行（attempted）]：セッション レポートがトリガーされた試行された N4 応答の合計数。

    [成功（successful）]：セッション レポートがトリガーされた成功した N4 応答の合計数。

    [失敗（failure）]：セッション レポートが原因で失敗した N4 応答の合計数。

• SMF_DISCONNECT_STATS が次の切断理由でトリガーされます。

  gtpu_peer_path_failure：この統計情報は、ノード レポートが原因でセッションが削除された場合にトリガーされます。

  upf_sess_report_gter_pdu_sess_rel：この統計は、セッション レポートが原因でセッションが削除された場合にトリガーされます。

統計情報の例を次に示します：

ノード レポート SMF サービスの統計:

smf_service_stats{app_name="SMF",cluster="Local",data_center="DC",dnn="intershat",
emergency_call="false",instance_id="0",pdu_type="ipv4",
procedure_type="upf_node_report_pdu_sess_rel",qos_5qi="",rat_type="NR",
reason="",service_name="smf-service",status="attempted",up_state=""} 

smf_service_stats{app_name="SMF",cluster="Local",data_center="DC",dnn="intershat",
emergency_call="false",instance_id="0",pdu_type="ipv4",
procedure_type="upf_node_report_pdu_sess_rel",qos_5qi="",rat_type="NR",
reason="",service_name="smf-service",status="success",up_state=""} 1
 

セッション レポート SMF サービスの統計:

smf_service_stats{always_on="",app_name="smf",cluster="smf",data_center="unknown",
dcnr="",dnn="intershat",emergency_call="false",instance_id="0",pdu_type="ipv4",
procedure_type="upf_sess_report_gter_pdu_sess_rel",qos_5qi="",rat_type="NR",
reason="",service_name="smf-service",status="attempted",up_state=""} 1 

smf_service_stats{always_on="",app_name="smf",cluster="smf",data_center="unknown",
dcnr="",dnn="intershat",emergency_call="false",instance_id="0",pdu_type="ipv4",
procedure_type="upf_sess_report_gter_pdu_sess_rel",qos_5qi="",rat_type="NR",
reason="",service_name="smf-service",status="success",up_state=""} 1 

ノード レポート SMF プロトコル統計：

smf_proto_udp_req_msg_total{app_name="smf",cluster="smf",data_center="unknown",
instance_id="0",message_direction="inbound",message_name="n4_node_report_req",
msgpriority="",service_name="smf-protocol",status="accepted",
transport_type="origin"} 15 

smf_proto_udp_res_msg_total{app_name="smf",cause="1",cluster="smf",
data_center="unknown",instance_id="0",message_direction="outbound",
message_name="n4_node_report_res",msgpriority="",service_name="smf-protocol",
status="accepted",transport_type="origin"} 15 

セッション レポート SMF プロトコル統計：

smf_proto_udp_req_msg_total{app_name="smf",cluster="smf",data_center="unknown",
instance_id="1",message_direction="inbound",message_name="n4_session_report_req",
msgpriority="",service_name="smf-protocol",status="accepted",
transport_type="origin"} 43 

smf_proto_udp_res_msg_total{app_name="smf",cause="1",cluster="smf",
data_center="unknown",instance_id="1",message_direction="outbound",
message_name="n4_session_report_res",msgpriority="",service_name="smf-protocol",
status="accepted",transport_type="origin”} 

SMF は、ノード レポートとセッション レポート タイプ（GTER、SRIR、SPTER）が原因でセッション削除された数を追跡するためのラベルも維持します。

たとえば、ラベル「LABEL_DISC_PDNREL_GTER_SESSION_REP」が追加され、GTER の存在によるセッションの削除が追跡されます。