SMF は、IE で障害を検出した場合、4G プロシージャの GTP 原因コード処理をサポートします。

ここでは、原因からクラスへのマッピングおよびクラスから原因へのマッピングを構成する方法について説明します。

送信元インターフェイスの障害の場合、 cause-map-class プロファイルは、対応するターゲット インターフェイスに適用する必要がある class-map-cause プロファイルを決定します（ただし、アクセス プロファイルでプロファイルが構成されている場合のみ）。それぞれの CLI 構成は、送信元インターフェイスの障害と原因の値に基づいて、ターゲット インターフェイスにユーザー定義の原因の値を送信します。CLI コマンドが構成されていない場合、ターゲット インターフェイスは、指定駆動の原因値をデフォルト値として送信します。

GTP 原因コードの構成には、次の手順が含まれます：

• 原因からクラスへのマッピング構成

  • cause-map-class プロファイルでの Cause-to-Class マップの構成

  • ネットワーク イーサネット プロファイル下の原因からクラスへのマッピングの構成

• マッピング構成を原因とするクラス

  • class-map-cause プロファイルでの Class-to-Cause マップの構成

  • アクセス プロファイルでのクラス/ケースマップの構成

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

このセクションでは、4G および 5G の手順における GPRS トンネリング プロトコル バージョン 2（GTPv2）の IE と原因コードについて説明します。

smf_gtpc_msg_stats

この機能は、GTPC メッセージに関連する次の統計をサポートしています：

説明：GTPC インターフェイス メッセージの統計

サンプル クエリ：'smf_gtpc_msg_stats{message_type="modify_bearer_request"}'

ラベル

• ラベル： message_type

  ラベルの説明：GTPC メッセージ タイプ

  例：modify_bearer_request, delete_bearer_request, delete_session_request

• ラベル：status

  ラベルの説明：GTPC メッセージ ステータス

  例：試行、成功、失敗

• ラベル：reason

  ラベルの説明：失敗に関連付けられた理由。

  Example: ipc_failed, sgw_failure, EGTP_CAUSE_LOCAL_DETACH, EGTP_CAUSE_RAT_CHANGED_FROM_3GPP_TO_NON_3GPP, EGTP_CAUSE_COMPLETE_DETACH, EGTP_CAUSE_ISR_DEACTIVATION, EGTP_CAUSE_ERROR_IND_RCVD_RNC_ENODE, EGTP_CAUSE_IMSI_DETACH_ONLY, EGTP_CAUSE_REACTIVATION_REQUESTED, EGTP_CAUSE_PDN_RECONNECTION_TO_THIS_APN_DISALLOWED, EGTP_CAUSE_ACCESS_CHANGED_FROM_NON_3GPP_TO_3GPP, EGTP_CAUSE_PDN_CONN_INACTIVITY_TIMER_EXPIRED, EGTP_CAUSE_PGW_NOT_RESPONDING, EGTP_CAUSE_NETWORK_FAILURE, EGTP_CAUSE_QOS_PARAMETER_MISMATCH, EGTP_CAUSE_REQ_ACCEPTED, EGTP_CAUSE_REQ_ACCEPTED_PARTIALLY, EGTP_CAUSE_NEW_PDN_TYPE_NETWORK_PREFERENCE, EGTP_CAUSE_NEW_PDN_TYPE_SINGLE_ADDR_BEARER_ONLY, EGTP_CAUSE_CONTEXT_NOT_FOUND, EGTP_CAUSE_INVALID_MESSAGE_FORMAT, EGTP_CAUSE_VERSION_NOT_SUPPORTED_BY_NEXT_PEER, EGTP_CAUSE_INVALID_LENGTH, EGTP_CAUSE_SERVICE_NOT_SUPPORTED, EGTP_CAUSE_MANDATORY_IE_INCORRECT, EGTP_CAUSE_MANDATORY_IE_MISSING, EGTP_CAUSE_SYSTEM_FAILURE, EGTP_CAUSE_NO_RESOURCES_AVAILABLE, EGTP_CAUSE_SEMANTIC_ERROR_IN_TFT_OPERATION, EGTP_CAUSE_SYNTACTIC_ERROR_IN_TFT_OPERATION, EGTP_CAUSE_SEMANTIC_ERROR_IN_PKT_FILTERS, EGTP_CAUSE_SYNTACTIC_ERROR_IN_PKT_FILTERS, EGTP_CAUSE_MISSING_OR_UNKNOWN_APN, EGTP_CAUSE_UNEXPECTED_REPEATED_IE, EGTP_CAUSE_GRE_KEY_NOT_FOUND, EGTP_CAUSE_REALLOCATION_FAILURE, EGTP_CAUSE_DENIED_IN_RAT, EGTP_CAUSE_PREFERRED_PDN_TYPE_UNSUPPORTED, EGTP_CAUSE_ALL_DYNAMIC_ADDR_OCCPUPIED, EGTP_CAUSE_UE_CTX_WO_TFT_ALREADY_ACTIVATED, EGTP_CAUSE_PROTOCOL_TYPE_NOT_SUPPORTED, EGTP_CAUSE_UE_NOT_RESPONDING, EGTP_CAUSE_UE_REFUSES, EGTP_CAUSE_SERVICE_DENIED, EGTP_CAUSE_UNABLE_TO_PAGE_UE, EGTP_CAUSE_NO_MEMORY_AVAILABLE, EGTP_CAUSE_USER_AUTHENTICATION_FAILED, EGTP_CAUSE_APN_DENIED_NO_SUBSCRIPTION, EGTP_CAUSE_REQUEST_REJECTED, EGTP_CAUSE_PTMSI_SIGNATURE_MISMATCH, EGTP_CAUSE_IMSI_IMEI_NOT_KNOWN, EGTP_CAUSE_SEMANTIC_ERROR_IN_TAD_OPERATION, EGTP_CAUSE_SYNTACTIC_ERROR_IN_TAD_OPERATION, EGTP_CAUSE_RESERVED_MESSAGE_VALUE_RECEIVED, EGTP_CAUSE_PEER_NOT_RESPONDING, EGTP_CAUSE_COLLISION_WITH_NETWORK_INIT_REQUEST, EGTP_CAUSE_UNABLE_TO_PAGE_UE_DUE_TO_SUSPENSION, EGTP_CAUSE_CONDITIONAL_IE_MISSING, EGTP_CAUSE_INCOMPATIBLE_APN_REST_TYPE, EGTP_CAUSE_INVALID_LENGTH_WITH_PIGGYBACK_MSG, EGTP_CAUSE_DATA_FORWARDING_NOT_SUPPORTED, EGTP_CAUSE_INVALID_REPLY_FROM_REMOTE_PEER, EGTP_CAUSE_FALLBACK_TO_GTPV1, EGTP_CAUSE_INVALID_PEER, EGTP_CAUSE_TEMP_REJECTED_DUE_TO_HANDOVER_IN_PROGRESS, EGTP_CAUSE_REQ_REJECTED_FOR_PMIPV6_REASON, EGTP_CAUSE_APN_CONGESTION, EGTP_CAUSE_BEARER_HANDLING_NOT_SUPPORTED, EGTP_CAUSE_UE_ALREADY_REATTACHED, EGTP_CAUSE_MULTI_PDN_CONNECTION_FOR_APN_NOT_ALLOWED, EGTP_CAUSE_MME_SGSN_REFUSES_DUE_TO_VPLMN_POLICY, EGTP_CAUSE_GTPC_ENTITY_CONGESTION, EGTP_CAUSE_TARGET_ACCESS_RESTRICTED_FOR_THE_SUBSCRIBER, EGTP_CAUSE_UE_TEMP_NOT_REACHABLE_DUE_TO_POWER_SAVING, EGTP_CAUSE_RELOC_FAILURE_DUE_TO_NAS_MSG_REDIRECTION, EGTP_CAUSE_MISSING_TIMESTAMP_OPTION, EGTP_CAUSE_MULTIPLE_HNP_NOT_ALLOWED, EGTP_CAUSE_SN_MALFORMED_MSG, EGTP_CAUSE_INT_TIMEOUT

• ラベル： qos_5qi

  ラベルの説明：QoS フローに適用される 5Qi

  例: 1、2、5

• ラベル： rat_type

  ラベル説明：要求に関連付けられた無線アクセスのタイプ

  例：EUTRA、NR、WLAN、rat_type_unknown

• ラベル：smf_current_procedure

  ラベルの説明：メッセージレベル統計の現在のプロシージャ名

  例：nr_to_untrusted_wifi_handover, eps_fb_ded_brr, PdnDisconnectProcedure, enb_to_untrusted_wifi_handover, pcf_req_ded_brr_create, pcf_req_ded_brr_delete, pcf_req_ded_brr_mod, smf_initiated_pdn_detach, untrusted_wifi_to_enb_handover, upf_sess_report_srir_sess_rel, utn3gpp_to_5g_handover

P-GW ユーザープレーンは、さまざまなトリガーの使用状況レポートを送信します。たとえば、ボリューム、時間クォータ、しきい値、有効時間、クォータ保持時間、トラフィック開始（SoT）などです。それ以外の場合、SMF は、課金状態イベントを検出した後、または SMF での PCC ルール削除の一環として使用状況レポートルール（URR）の削除を検出した後、クエリ使用状況レポートを送信します。

使用状況レポートを受信すると、コントロール プレーンは URR を対応する Charging Multiple-Service Credit Control（MSCC）にマッピングします。そして、コントロール プレーンは、それぞれの MSCC のクレジット制御更新要求を開始します。使用状況レポートは、同期または非同期のいずれかです。SMF は、N4 変更応答または N4 削除応答メッセージを介して同期使用状況レポートを受信します。SMF は、N4 セッション レポート要求メッセージを介して非同期使用状況レポートを受信します。

Gy インターフェイスの使用状況レポートには、次の使用状況レポート手順が含まれます。

• クレジット制御要求のトラフィック開始（SoT）- 最初の（CCR-I）要求が最初のアタッチまたはベアラーの作成中に送信されません。

• SoT を含む使用状況レポート：初期接続またはベアラーの作成中にクォータ要求なしで CCRI が送信される

• 事前定義済みルールおよび静的ルール用の SoT

• N4 クエリ URR の応答を変更します。

• N4 セッション レポート リクエスト。

• URR を削除するための N4 変更応答。

• N4 削除セッション応答。

Diameter 障害処理テンプレートは、さまざまな Diameter サービスに関連付けられています。Diameter エンドポイント ポッドが、OCS から Gy メッセージのコマンド レベルの障害を受信します。次に、Diameter エンドポイント ポッドがエラー処理設定を処理します。

次の表に、Gy インターフェイスでサポートされている失敗処理テンプレートのアクションとサブアクションを示します。

このセクションでは、一時的な障害（4xxx）および永続的な障害（5xxx）の結果コードを「MSCC レベルで受信した障害結果コード」を受信した場合の SMF の動作について説明します。

次の表では、さまざまな SMF の一時的および永続的な障害結果コードについて説明します。

SMF は CCAI のすべての永続的な障害結果コードと一時的な障害結果コード 4010 および 4012 を受信します。

• SMF は PFCP_SESSION_ESTABLISHMENT_REQUEST でゼロの時間とボリュームのクォータを送信します。SMF は、CCAU の永続的な障害結果コードと一時的な障害結果コード 4010 および 4012 をすべて受信します。

• SMF が PFCP_SESSION_MODIFICATION_REQUEST でゼロの時間とボリュームのクォータを送信する：SMF は、CCAI で一時的な障害結果コードを 4011 として受信します。

• SMF が PFCP_SESSION_ESTABLISHMENT_REQUEST で高い（最大の）時間とボリュームのクォータを送信する：SMF は、CCAU で一時的な障害結果コードを 4011 として受信します。

このセクションでは、Gy インターフェイスから受信したクレジット制御アプリケーション（CCA）メッセージでの、MSCC レベルでの複数サービス クレジット制御（MSCC）失敗結果コードの処理に関連する詳細のキャプチャについて説明します。この機能により、SMF は、 CCAI および CCAU メッセージの Gy インターフェイスから MSCC レベルで一時的な障害（4xxx）と永続的な障害（5xxx）を処理できます。

次の表に、一時的な障害（4xxx）および永続的な障害（5xxx）の結果コードのさまざまな結果コードと動作を示します。

（注）	SMF が URRS でサポートされている障害コードを受信します。ローカル トリガの構成または OCS から受信したトリガに基づいて、URR に対して操作が実行されることはありません。

この機能の一部として、次の機能が SMF に追加されます。

• SMF は、 CCAI および CCAU メッセージの Gy インターフェイスから クォータ有効期間 を受信できます。処理後、SMF は、「timq 」をトリガとしてこの情報をメッセージ PFCP_SESSION_ESTABLISHMENT_REQUEST および PFCP_SESSION_MODIFICATION_REQUESTで UPF に送信します。

  PFCP_SESSION_REPORT_REQUEST メッセージが「timq」トリガを使用した使用状況レポートを受信した場合、SMF は時間クォータ情報を含む USU を含む CCRU メッセージを送信し、TGPPReportingReason を「VALIDITY_TIME」として追加します。

• SMF は、 CCAI および CCAU メッセージの Gy インターフェイスから クォータ保持時間 を受信できます。処理後、SMF はこの情報を「quehti 」としてトリガするメッセージ PFCP_SESSION_ESTABLISHMENT_REQUEST および PFCP_SESSION_MODIFICATION_REQUESTで UPF に送信します。

  PFCP_SESSION_ESTABLISHMENT_REQUEST PFCP_SESSION_MODIFICATION_REQUEST

  PFCP_SESSION_REPORT_REQUEST メッセージが「quihti」トリガで使用状況レポートを受信した場合。SMF は、USU に時間クォータ情報を含む CCRU メッセージを送信し、TGPPReportingReason を「QHT」として追加します。

Quota-Validity-Time

これはオプションの AVP であり、CCA コマンドでのみ発生する可能性があります。これは、Multiple Services-Credit-Control AVP に含まれています。このフィールドは、特定のカテゴリ インスタンスに対して付与されたクォータの有効性を制限する時間を定義します。

SMF では、次の要件がサポートされています：

• Gy CCAI/CCAU メッセージの確立または変更で受信した「有効期間」を受信しました

• SMF プロセスが有効時間を受け取りました（UPF に情報を送信できる場合）。

  SMF は、PFCP_IE_TIME_QUOTA に有効時間を「tm_quata」として送信し、PFCP_IE_REPORTING_TRIGGERS の: PFCP_SESSION_ESTABLISHMENT_REQUEST および PFCP_SESSION_MODIFICATION_REQUEST にトリガーを tmqとして設定します。

• SMF は、PFCP_SESSION_REPORT_REQUEST メッセージの「durton_msrt 」のトリガーおよび期間として timq を使用して、PFCP_IE_USAGE_REPORT_REP_REQ を受信できます。

• SMF プロセス使用状況レポートは、Used-Service-Unit および CCRU の Multiple-Services-Credit-Control AVP で VALIDITY_TIME として追加された 3GPP-Reporting-Reason 内で、受け取った「durton_msrt」を「CC-Time」として送信します。

• SMF が「durton_msrt」とともに「volume_msrmt」を受信した場合、Used-Service-Unit 内の「CC-Time」とともに「CC-Total-Octets」、「CC-Input-Octets」、「CC-Output-Octets」が入力され、および 3GPP-Reporting-Reason が CCRU の Multiple-Services-Credit-Control AVP に VALIDITY_TIME として追加されました。

• cnPGW が Gy CCAI/CCAU メッセージで「有効期間」を受信しない場合、課金プロファイル構成から読み取り、適用します。

Quota-Holding-Time

これはオプションの AVP であり、CCA コマンドでのみ発生する可能性があります。これは、Multiple Services-Credit-Control AVP に含まれています。これは、付与された時間クォータと付与されたボリューム クォータに等しく適用されます。

SMF では、次の要件がサポートされています：

• Gy CCAI/CCAU メッセージの確立または変更で「3GPP-Quota-Holding-Time」を受信しました

• SMF は PFCP_IE_QUOTA_HOLDING_TIME 内で「quma_hldg_tm」として保持時間を送信し、PFCP_IE_REPORTING_TRIGGERS の PFCP_SESSION_ESTABLISHMENT_REQUEST および PFCP_SESSION_MODIFICATION_REQUEST の PFCP_IE_REPORTING_TRIGGERS でトリガーを qhti として構成します。

• SMF は、 qhti をトリガーとして使用して PFCP_IE_USAGE_REPORT_REP_REQ を受信できます。

• CCRU の Multiple-Services-Credit-Control AVP で SMF プロセス使用状況レポート 3GPP-Reporting-Reason が QHT として追加されました。

Volume-Quota-Threshold

これはオプションの AVP であり、CCA コマンドでのみ発生する可能性があります。これは、Multiple Services-Credit-Control AVP に含まれています。cnPGW が Gy CCAI/CCAU メッセージで「3GPP-Volume-Quota-Threshold」を受信していない場合、課金プロファイル構成から情報を読み取り、適用します。

SMF は、PFCP_IE_TIME_QUOTA IE の「tm_quata」で N4 に対してクォータの有効時間を送信します。SMF が CCAI/CCAU からクォータの有効時間のみを受信する場合、または cc-Time と validity-time の両方を受信する場合、有効時間は短くなります。両方の値が等しい場合、SMF は tm_quata で cc-Time 値を送信します。クォータの有効期間が選択されている場合、SMF は 3GPP-Time-Quota-Threshold を N4 に転送しません。

受信したクォータ保持時間が有効な場合、SMF はクォータ保持時間を N4 に送信します。

（注）

ゼロ有効期間： SMF では、CCRI/CCRU から受信した有効時間または保持時間の値が 0 の場合、有効時間または保持時間の値が N4 に転送されます。0 が UPF でアームド タイマーを無効化するメカニズムであるため、SMF は 0 をリレーします。CCRI/CCRU から受信した有効時間または保持時間の値が 0 の場合、QVT および QHT の実装は SMF と連携します。 QHTトリガーを受信しました。 SMF では、volume_msrmt、duration_msrmt が quehti トリガーとともに受信され、CCRU は USU 内で volume_msrmt、duration_msrmt を送信し、レポートの理由を MSCC レベルの QHT として更新して、「Requested-Service-Unit」も送信します。volume_msrmt、duration_msrmt が qhti トリガーと共に受信される場合、QHT の実装は SMF と連携します。

次のデバッグ ログは、Gy インターフェイスから有効時間が受信された場合、さまざまなシナリオで存在します。

• validity-Time のみを受信しました：

  「有効期限があり、時間クォータではありません」

• Validity-Time と cc-Time を受信しました：

  「時間クォータが有効時間よりも小さい」

  「時間クォータが有効時間よりも大きくなっています」

  「時間クォータは有効時間と等しくなります」

タリフ切り替え時間機能は、サブスクライバがあるタリフ プランから別のタリフ プランに切り替わるときに適用されます。Tariff-Time-Change AVP はタリフ切り替え時間を決定するために使用され、Monitoring-Time IE はタリフ時間サポート機能をサポートするために使用されます。

タリフ タイマーが終了すると、ゲートウェイは別途、使用量を課金バケットに累積し、引き続き元のクォータ値から消費します。次回のレポート時（クォータの枯渇またはその他の制御イベント発生時）に、ゲートウェイはこの課金バケットの 2 つの使用量（タリフ時間変更の前後）をレポートします。

SMF は、CCAI メッセージと CCAU メッセージの Gy インターフェイスからの付与されたサービス ユニット（GSU）レベルの Tariff-Time-Change AVP を処理します。SMF では、UPF から使用状況レポートを受信すると、CCRU および CCRT メッセージの Used-Service-Unit（USU）内に Tariff-Change-Usage AVP が含まれます。

以下のシナリオがサポートされています：

• Tariff-Time-Change with Quota-Holding-Time Expired Trigger

• Tariff-Time-Change with Validity-Time Expired Trigger

• Tariff-Time-Change with Volume/Time-Quota Exhausted Trigger

• Tariff-Time-Change with Volume/Time-Quota Exhausted Trigger

• Tariff-Time-Change with Immediate Reporting Trigger

• Tariff-Time-Change with Terminate Reporting Trigger

この SMF の機能の一部として、次の機能が追加されました：

• OCS は、CCAI/CCAU メッセージで「Tariff-Time-Change」AVP を提供します。処理後、SMF は、PFCP_IE_MONITORING_TIME IE を使用して、PFCP セッション確立要求および PFCP セッション変更要求で UPF にこの情報を送信します。

• SMF は、URR ごとに次の 2 つの使用状況レポートを受信します：

  • 1 つは、「Usage Report Trigger」は「MONIT」として、「 PFCP_IE_USAGE_INFORMATION」は、「PFCP_IE_VOLUME_MEASUREMENT」と「PFCP_IE_DURATION_MEASUREMENT」と一緒の「bef」としてです。

  • 他の使用レポートは、「Usage Report Trigger」は「TIMQU」として、「 PFCP_IE_USAGE_INFORMATION」は、「PFCP_IE_VOLUME_MEASUREMENT」と「PFCP_IE_DURATION_MEASUREMENT」と一緒の「aft」としてです。

• SMF は異なる USU を使用して、MSCC 内の両方の使用状況レポートを CCRU/CCRT メッセージの OCS に転送します。

  .

  • 最初の使用状況レポート。これは「MONIT」トリガーがあるものは、「Tariff-Change-Usage: UNIT_BEFORE_TARIF_CHANGE」で USU1 に転送されます。

  • そして 2 番目の使用状況レポート。これは「TIMQU」トリガーで、「Tariff-Change-Usage: UNIT_AFTER_TARIFF_CHANGE」と共に USU2 に転送されます。

ルーティング データ サポート機能により、SMF は次のことが可能になります。

• OCS から CCA-I/CCA-U で受信したルーティングデータの処理

• Diameter セッションごとに ChargingSubData にルーティングデータ情報を上書きして保存します。Smf-service には、次の後続の CCR-U または CCR-T メッセージに格納されたルーティング データ値が含まれます。SMF は常に OCS からの CCA-I/CCA-U のルーティングデータを想定しています。

モニタリングおよびトラブルシューティング

このセクションには、機能操作時に発生する可能性がある問題のトラブルシューティングに関する情報が記載されています。

次に、サブスクライバの Gy Diameter セッションごとのルーティングデータの出力例を示します。

"gyDiamSession": {
                            "brrId": 1,
                            "sessionID": ":2:69:ocs-prof:64c37b62:1",
                            "originHost": "dummyOriginHost",
                            "originRealm": "dummyOriginRealm.com",
                            "destRealm": "dummyGyDestRealm.com",
                            "destHost": "Gy-server",
                            "RoutingData": {
                                "primaryHost": "10.105.34.14",
                                "primaryRealm": "dummyGyDestRealm.com",
                                "boundPeer": "Gy-server"
                            }
                        },

レガシー インターフェイスを使用した SMF は、オフライン アカウンティング機能を有効にするために、デフォルトのベアラーの Gz インターフェイスを使用したパケット データ ネットワーク（PDN）接続をサポートします。

動作

Gx CCA-I を介して PCRF からオフライン ルールを受信すると、Diameter インターフェイスを備えた SMF はオフライン URR を作成し、対応する課金バケット（SDF）にマッピングし、レガシー インターフェイスを使用して SMF に N4EstablishmentRequest を送信します。

オフライン SDF/ベアラーレベルの URR の使用状況レポートを受信すると、UPF からの N4 セッション削除応答で、GTPP データレコード転送要求を GTPP に送信します。Gz 通信量レポートの詳細については、 「回線の課金」 > 「GTPP での Gz 通信量レポートの取り扱い」の セクションを参照してください。

Gz インターフェイス機能を備えた PDN のアタッチとデタッチを使用して、次のことを行います。

• アタッチ手順:

  • オフライン ルールのみ（Gx + Gz）

  • オフライン ルールとオンライン ルール（Gx + Gy + Gz）

• 次による切断手順:

  • オフライン ルールのみ（Gx + Gz）

  • オフライン ルールとオンライン ルール（Gx + Gy + Gz）

PDN 接続および切断機能は、次の情報要素（IE）をサポートします。

• オフライン ルールのレポート レベル IE：ダイナミック ルールの ReportingLevel は、Gx CCA-I の PCRF から受信されます。その他の条件は次のとおりです：

  • ダイナミック オフライ ンルールで ReportingLevel が存在しない場合、SMF は、受信した RG とサービス ID に基づいてレポート レベルを考慮します：

    • RG のみを受信した場合は、レポート レベルは RatingGroupLevel になります。

    • RG と ServiceID の両方を受信した場合のレポート レベルは ServiceIdentifierLevel です。

  • 動的オフライン ルールに ReportingLevel が存在する場合、同じものと見なされます。

  （注）	デフォルトの offlineReportingLevel 構成は Gz には適用できません。

動的ルールのオフライン AVP の処理

次の表は、ダイナミック ルールのオフライン AVP の機能について説明します。

Gz が無効になっている場合のオフライン ダイナミック ルールの処理

ルールベースで Gz が無効になっている場合、オフラインのダイナミック ルールに対して SDF およびベアラー レベルの URR は作成されません。次の表に、入力値の可能な組み合わせを示します。

コントロール プレーンまたはユーザー プレーンのいずれかからパス障害が発生した場合、次のいずれかの理由により、異常なリリースを含む GTPP レコード終了メッセージが送信されます。

• UPF セッションレポート ERIR

• UPF セッション レポート SRIR

• GTPU ピア パス障害

• UPF リカバリ リリース

• UPF パス ピアの障害

• GTPC ピア パスのリリース失敗

• GTPC ピア再起動リリース

次のコール フローと手順では、オフラインを含むダイナミック ルールが Gx および Gz インターフェイスを介して有効になっている場合の PDN アタッチについて説明します。

次のコール フローと手順では、オンラインとオフラインの両方を含むダイナミック ルールが Gx、Gy、および Gz インターフェイスを介して有効になっている場合の PDN アタッチについて説明します。

以下のコール フローと手順は、セッション削除応答における使用状況レポートを説明しています。

Gz インターフェイスを有効にするために構成コマンドを使用します。オフライン AVP がルールおよびコマンド レベルで存在しない場合、デフォルトのオフライン課金方式が動的ルールに適用されます。Gz インターフェイスが有効になっている場合、動的ルールのデフォルトのオフライン課金方式が有効になります。それ以外の場合、デフォルトのオフライン課金は無効になります。

config 
   active-charging service service_name 
      rulebase rulebase_name 
         billing-records egcdr value  
   profile gtpp-profile   profile_name  gtpp dictionary dictionary_num 
   profile network-element ofcs  ofcs_name  gtpp-profile profile_name  
   profile dnn intershat network-element-profiles ofcs ofcs_name | 
end  

注：

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

  （注）	ルールベースは、フローと一致するプロトコル ルール、および一致したフローに対して実行される関連アクションのコレクションです。

• billing-records egcdr value ：eG-CDR 請求を有効にする場合に True に指定します。これにより、対応するルールベース プロファイルの Gz インターフェイスに CnPGW-C が関連付けられます。さらに、PCRF が Gx CCA-I で別のルールベースを送信すると、Gz インターフェイスは、新しいルールベースで受信した billingRecord EGCDR 構成に従って有効または無効になります。

• profile gtpp-profile profile_name gtpp dictionary dictionary_num ：ディクショナリを使用して gtpp プロファイルを構成します。正しいディクショナリは gtpp dictionary custom24です。 profile_name は 、セッションのラウンド ロビン方式で使用される関連 GTPP プロファイル名のリストを指定します。最大 gtpp プロファイル数は 4 です。

• profile network-element ofcs ofcs_nameprofile_name gtpp-profile ： ネットワーク プロファイル ofcs を構成します。OFCS プロファイル構成では、複数の gtpp プロファイルを構成することができます。

  （注）	network profile ofcs を構成する前に gtpp-profile. を構成してください

構成コマンドを使用して、ベアラー レベルのしきい値を設定します。

config 
   active-charging service service_name 
      rulebase rulebase_name 
         egcdr threshold volume { downlink | total | uplink }  bytes  
end  

注：

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

• egcdr threshold volume { downlink | total | uplink } bytes ：ベアラー レベルの URR しきい値を指定します。ダウンリンク、合計、またはアップリンクのオクテットの数の制限は、100000 ～ 4000000000 の範囲の整数である必要があります。例： egcdr threshold volume downlink 100000 uplink 100000 total 200000

サービス データ フロー（SDF）レベルのしきい値を設定するには、 構成コマンドを使用します。

config 
    active-charging service service_name 
       charging-action charging_action 
          egcdr service-data-flow threshold volume { downlink | total | uplink } bytes  
          egcdr service-data-flow threshold interval interval   60
    end 

注：

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

• egcdr service-data-flow threshold volume { downlink | total | uplink } bytes ：SDF レベルのオフライン URR しきい値を指定します。ダウンリンク、合計、またはアップリンクのオクテットの数の制限は、100000 ～ 4000000000 の範囲の整数である必要があります。

• egcdr service-data-flow threshold interval interval ：オフライン充電のしきい値を構成します。60 ～ 40000000 の範囲の整数である必要があります。

コンフィギュレーション コマンドを使用して、構成した maxlosdv 値に相当する数のサービス データ フロー（SDF）コンテナの数で GTPP データ レコードを作成します。maxlosdv が構成されていない場合、デフォルト値は 1 です。

config 
    active-charging service service_name 
       charging-action charging_action 
          egcdr losdv-max-containers container_num  
    end 

注：

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

• egcdr losdv-max-containers container_num ：GTPP データ レコードを作成するサービス データ コンテナ（LOSDV）の最大リストを指定します。

次のコマンドを使用して、GTPP データ レコードで送信する終了理由を構成します。終了理由は、管理介入または通常のリリースです。デフォルトの終了理由は mgmt-intervention です。

config 
    active-charging service service_name 
       charging-action charging_action 
          egcdr closure-reason { admin-disconnect | normal-release |  }     
    end 

注：

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

• egcdr closure-reason { admin-disconnect | normal-release | } ：終了理由を構成します。

統合ユーザー プレーン機能の実行時に、P-GW（ユーザー プレーン）は、オフライン課金のボリュームまたは時間しきい値などのトリガに関する使用状況レポートを送信します。統合型コントロール プレーン機能中に、P-GW（コントロール プレーン）は、SMF でのポリシー制御および課金（PCC）ルールの削除の一環として課金状態イベントが検出された場合、または URR が削除された場合に、使用状況レポートをクエリします。

使用状況レポートを受信すると、コントロール プレーンは URR を対応するオフライン課金パラメータにマッピングします。オフラインの課金パラメータが使用できない場合は、静的ルールまたは事前定義されたルールに対してサービス データ フロー（SDF）またはベアラー レベルの課金パラメータが作成され、それぞれの SDF に対して GTPP データ レコード転送要求が開始されます。つまり、N4 変更応答または N4 削除応答メッセージを介して同期使用状況レポートを受信します。N4 セッション レポート要求メッセージを介して非同期使用状況レポートを受信します。

詳細については、『UCC 5G cnSGWc 構成および管理ガイド』>「インターフェイス サポート」の章を参照してください。

Gz インターフェイスの使用状況レポートには、次の使用状況レポート手順が含まれます。

• オフライン ベアラーまたはオフライン ベアラーと SDF レベル、またはダイナミック ルールの SDF レベルの URR

• オフライン ベアラーまたはオフライン ベアラーと SDF レベル、またはスタティック/事前定義済みルールの SDF レベルの URR

• オンラインまたはオフライン URR

• N4 削除セッション応答。

ここでは、SFM のインターフェイスのサポートに関する操作、管理、およびメンテナンスに関して説明します。

SMF は、ユーザーの場所とタイムゾーンの変更、変更通知について、S-GW からベアラー要求の変更を受信します。次の機能は、トリガによってサポートされます。

• タイムゾーン トリガ：CHANGE_IN_UE_TIMEZONE トリガを使用して、タイムゾーンの変更を特定します

• ULI トリガ：CHANGE_IN_LOCATION、CHANGEINLOCATION_TAC、および CHANGEINLOCATION_ECGI を使用してロケーションの変更を特定します。

タイムゾーン情報は、CDR レベルでのみ送信されます。次のコール フローは、SMF のタイムゾーンの変更を示しています。

N4 変更要求例

PFCP_SESSION_MODIFICATION_REQUEST (52)
'Retransmit flag'  : 0
'Seid'             : 17293822569102704642
'Length'           : 71
'Sequence Number'  : 3
'Number of IEs'    : 5
    PFCP_IE_SUB_PARAMS (226)
      'sub_params' : {'rat_type': 6, 'sgsn_v4': '10.105.38.134', 'uli_len': 13, 'uli': {'spare': 0, 'ecgi': 1, 'tai': 1, 'nrtai': 0, 'nrcgi': 0, 'tai-mcc': 123, 'tai-mnc': 456, 'tai-tac': 2347, 'ecgi-mcc': 123, 'ecgi-mnc': 456, 'ecgi-spare': 0, 'ecgi-eci': 1234567}, 'ggsn_v4': '10.21.82.217'}

    PFCP_IE_QUERY_URR (77)

            PFCP_IE_URR_ID (81)
                  'urr_id' : 55

    PFCP_IE_PFCPSMREQFLAGS (49)
           'spare' : 0
           'qaurr' : 1
           'sndem' : 0
           'drobu' : 0

    PFCP_IE_QUERY_INTERFACE (253)
    'query_interface' : {'spare_3bit': 0, 'offline_urr': 0, 'online_urr': 0, 'radius_urr': 0, 'bearer_urr': 1, 'sess_urr': 0}

    PFCP_IE_RECALCULATE_INTERFACE (264)
    'recalculate_interface' : {'spare_3bit': 0, 'offline_urr': 1, 'online_urr': 0, 'radius_urr': 0, 'bearer_urr': 1, 'sess_urr': 0}


        MESSAGE BUFFER:
                2134 0047 F000 0000 0000 0002 0000 0304
                00E2 001C 0100 012A 060A 6926 860D 1821
                6354 092B 2163 5400 12D6 870A 1552 D904
                004D 0008 0051 0004 0000 0037 0031 0001
                0400 FD00 0110 0108 0001 10

ユーザーの位置情報は、CDR と SDF の両方のコンテナ レベルで送信されます。接続が実行されると、1 つの CDR が現在のレコード開始時刻と現在の ULI で開かれます。CDR が生成されると、現在のレコード開始時刻と最後のユーザーの位置情報で別の CDR が開かれます。

次のコール フローは、SMF のユーザロケーション情報（ULI）の変更を示しています。

N4 変更要求例

PFCP_SESSION_MODIFICATION_REQUEST (52)
'Retransmit flag'  : 0
'Seid'             : 17293822569102704642
'Length'           : 71
'Sequence Number'  : 3
'Number of IEs'    : 5
    PFCP_IE_SUB_PARAMS (226)
      'sub_params' : {'rat_type': 6, 'sgsn_v4': '10.105.38.134', 'uli_len': 13, 'uli': {'spare': 0, 'ecgi': 1, 'tai': 1, 'nrtai': 0, 'nrcgi': 0, 'tai-mcc': 123, 'tai-mnc': 456, 'tai-tac': 2347, 'ecgi-mcc': 123, 'ecgi-mnc': 456, 'ecgi-spare': 0, 'ecgi-eci': 1234567}, 'ggsn_v4': '10.21.82.217'}

    PFCP_IE_QUERY_URR (77)

            PFCP_IE_URR_ID (81)
                  'urr_id' : 55

    PFCP_IE_PFCPSMREQFLAGS (49)
           'spare' : 0
           'qaurr' : 1
           'sndem' : 0
           'drobu' : 0

    PFCP_IE_QUERY_INTERFACE (253)
    'query_interface' : {'spare_3bit': 0, 'offline_urr': 1, 'online_urr': 0, 'radius_urr': 0, 'bearer_urr': 0, 'sess_urr': 0}

    PFCP_IE_RECALCULATE_INTERFACE (264)
    'recalculate_interface' : {'spare_3bit': 0, 'offline_urr': 1, 'online_urr': 0, 'radius_urr': 0, 'bearer_urr': 0, 'sess_urr': 0}


        MESSAGE BUFFER:
                2134 0047 F000 0000 0000 0002 0000 0304
                00E2 001C 0100 012A 060A 6926 860D 1821
                6354 092B 2163 5400 12D6 870A 1552 D904
                004D 0008 0051 0004 0000 0037 0031 0001
                0400 FD00 0110 0108 0001 10

サービス条件変更の理由

ULI 変更のサービス条件変更理由は次のとおりです。

• TAI が ULI で変更された場合、CDR の ServiceConditionChange の理由は「tailChange」です。

• ECGI が ULI で変更された場合、CDR の ServiceConditionChange の理由は「EcgiChange」です。

• TAI と ECGI の両方が ULI で変更された場合、CDR の ServiceConditionChange の理由は一般的な「UserLocationChange」です

次のコール フローと手順では、SMF での変更通知について説明します。

次の表では、クエリ インターフェイスと再計算インターフェイス IE について説明します。

Gz トリガーを構成するには、次の構成例を使用します。

config 
    active-charging service service_name 
       charging-action charging_action 
          egcdr  losdv-max-containers   service-data-flow triggers { ms-timezone-change [ true | false ] | qos-change [ true | false ] | uli-change [ true | false ] }  
    end 

注：

• egcdr losdv-max-containers ：1 つの EGCDR 内の LoSDV コンテナの最大数を構成します。losdv-max-containers value は1〜255の範囲の整数である必要があります。デフォルト値は 1 です。

• egcdr service-data-flow ：サービス データフ ローを構成します。

• egcdr triggers { ms-timezone-change [ true | false ] | qos-change [ true | false ] | uli-change [ true | false ] }

  • egcdr triggers ：CDR のトリガーのリストを構成します。デフォルトでは、次のトリガーが有効になっています：

    • triggers ms-timezone-change [ true | false ] ：CDR デフォルトの MS タイム ゾーン トリガーを有効または無効にします。

    • triggers qos-change [ true | false ] ：CDR のデフォルトの QoS 変更トリガーを有効または無効にします。

    • triggers uli-change [ true | false ] ：CDR のデフォルトのユーザーの場所の変更トリガーを有効または無効にします。

SMF は、Gx CCR-U および Gx RAR を介してデフォルトのベアラーの PCRF によって開始される変更をサポートしています。次の機能を実行できます。

• デフォルトのベアラーにルールを追加する

• デフォルトのベアラーからルールを削除する

• ルールベースの変更

• デフォルト ベアラー QoS の変更

• APN-AMBR の変更

このセクションでは、SMF での Gz デフォルト ベアラー変更機能に関連するコール フローについて説明します。

SMF と UPF は、eNB の通信量を追跡して、NSA デバイスの NR 通信量と LTE 通信量を区別します。SMF は、S5 インターフェイスに関するさまざまなメッセージで使用状況データ レポートを受信し、オフラインの使用状況レポートとともに OFCS サーバーに対する使用状況を報告します。

SMF は、Intended Receiver PGW-C（IPGW）フラグに基づいて、ベアラー要求の変更、通知要求、セッションの削除要求、およびベアラー応答の削除の S5 または S8 インターフェイスを介して MME から定期的に送信されるセカンダリ RAT データ ボリューム レポート メッセージを処理します。 SMF は、IRGW = 1 の場合に使用状況レポートを保持します。

SMF は、Secondary RAT Usage Data レポート IE の複数のインスタンスをサポートしています。トリガーに基づいて OFCS に送信されるまで、レポートを保存します。SMF は、課金トリガーのいずれかが満たされると、保存されているセカンダリ RAT 使用量データ レポートを gtpp-ep エンドポイントを介して送信します。課金プロファイルで、保存されるセカンダリ RAT 使用レポートの最大数を構成できます。SMF は、オフライン使用状況レポートが原因で CDR が閉じられた場合、保存されているセカンダリ RAT 使用状況データ レポートをオフライン使用状況レポートとともに送信します。

次の図は、定期的なセカンダリ RAT 使用状況レポートのコール フローを示しています。

OFCS に送信する前に、次の構成例を使用して、セカンダリ RAT 使用状況レポートを構成します。

config 
   profile charging profile_name 
      max-secondary-rat-reports report_range 
      exit 

注：

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

• max-secondary-rat-reports report_range ：GTPP（Gz）更新をトリガするセカンダリ RAT 使用率レポートの最大数を構成します。 report_range は 、0 ～ 50 の範囲の整数である必要があります。 max-secondary-rat-reports のセカンダリ RAT 使用制限の推奨値は 25 です。

  （注）	累積セカンダリ RAT 使用量が構成された制限を超えると、制限を超えたセカンダリ RAT 使用量の数が 1 回の使用にまとめられます。

SMF が DNN プロファイルを使用して処理されるセッションの DCNR 機能をサポートできるようにするには、次の構成例を使用します：

config 
   profile dnn profile_name  intershat dcnr  
      dcnr { false | true } 
      exit 

注：

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

• intershat dcnr ：新しい無線とのデュアル接続のサポートを有効にします。

  （注）	DCNR 構成が有効になっており、UE のセッション作成要求に「UP プレーン インジケータ IE」がある場合、セカンダリ RAT 使用レポートの処理が実行されます。

• dcnr { false | true } :

  • false ：DCNR フラグが false に設定されるように DNN プロファイルを構成します。デフォルトでは、この DCNR 構成は無効になっています。

  • true ：DCNR フラグが true に設定されるように DNN プロファイルを構成します。

    この構成により、SMF が DCNR 機能をサポートできるようになります。DCNR 機能が有効になっている場合、UE は DCNR フラグを送信してデュアル接続をサポートしていることを示します。

デフォルトでは、サブスクライバ セッションの終了に対して複数の CDR が生成された場合、すべての CDR でレコード クロージャの原因が同じになります。

SMF は、CLI オプションの closing-cause を介して、最終的な CDR でレコードが閉じられる原因を制御します。サブスクライバ セッションの終了時に複数の CDR が生成された場合、最終的な CDR レコード クロージャ理由は NormalRelease に設定され、他のすべての CDR レコード クロージャ理由は MaxChangeConditionに設定されます。

次のシナリオで CDR レコードを抑制できます：

• CLI 構成に基づいてボリューム使用率がない場合

• CDR のボリュームがゼロで、構成されたトリガーと一致している場合。

• CDR のボリュームがゼロで、構成されたトリガーと一致しない場合。 egcdr suppress-cdrs zero-volume CLI が構成されていない場合、SDF コンテナのない CDR が送信されます。

  （注）	UPF からのセッション使用状況レポートにボリュームがゼロの SDF レベルの使用状況が含まれている場合、SDF コンテナはデフォルトで抑制されます。

egcdr suppress-cdrs zero-volume CLI は、通話終了の使用状況レポートまたはベアラー レベルの使用例にのみ適用されます。たとえば、コールがゼロ ボリューム レポートで終了した場合、またはボリュームがゼロのベアラー レベルの同期または非同期使用レポートがある場合、CDR が送信されるかどうかは CLI 構成に基づいて決定されます。

CDR がボリューム使用状況を報告しない場合に CDR レコードを抑制するには、次の CLI 構成を使用します。

config 
    active-charging service service_name 
       charging-action charging_action 
          egcdr suppress-cdrs zero-volume   triggers [ internal-trigger-cdr |  final-cdr | external-trigger-cdr ]  
   end 

注：

• egcdr suppress-cdrs zero-volume ：CDR を抑制

• triggers ：ゼロ ボリュームで CDR を抑制するために使用できるトリガーのリストの 1 つを構成します。

  • egcdr suppress-cdrs zero-volume trigger internal-trigger-cdr ：非同期ボリューム使用率レポートが PFCP セッション使用状況レポートを介して UPF から取得されるように指定します。

  • egcdr suppress-cdrs zero-volume trigger final-cdr ：通話が終了することを指定します。

  • egcdr suppress-cdrs zero-volume trigger external-trigger-cdr ：同期ボリュームの使用状況レポートがクエリ URR を介して UPF から取得されることを指定します。

SMF は、このリリースの 3GPP TS 24.501 に定義されているように、無効なプロトコル データ処理に準拠する NAS メッセージです。

無効なプロトコル データ処理機能に準拠する NAS メッセージの動作は次のとおりです。

• SMF は、完全なメッセージ タイプ情報要素（IE）を含むには短すぎる NAS メッセージを無視します。

• SMF は、3GPP 仕様で定義されている最大制限よりも長い NAS メッセージを無視します。

• SMF は NAS メッセージ内の不明な IE を無視します。

• SMF は、NAS メッセージ内のシーケンスが正しくない IE を無視します。

• T、TV、TLV、または TLV-E フォーマットの情報要素が、IE の繰り返しが指定されていないメッセージ内で繰り返される場合、SMF は、最初に表示される情報要素の内容だけを処理します。さらに、SMF は後続の情報要素の繰り返しを無視します。

• SMF は、メッセージの構文が正しくないオプションの IE を使用できないメッセージと見なします。

• ネットワークは次のメッセージのいずれも無視し、原因 #100 "条件付き IE エラー"のステータス メッセージを返します。

  • SMF が NAS メッセージを受信し、条件付き IE エラーが欠落している場合

  • SMF が予期しない条件付き IE エラーを受信した場合

  • SMF が、少なくとも 1 つの構文的に正しくない条件付き IE を含むメッセージを受信した場合

SMF または vSMF では、UE によって開始された手順とネットワークによって開始された手順の 5G セッション管理（5GSM）の原因処理をサポートしています。

サポートされている手順は次のとおりです。

• PDU セッション確立

• PDU セッション変更

• PDU セッションの解放

SMF は、PDU セッション確立、PDU セッション変更、および PDU セッション リリースの手順に関する 5GSM の原因処理をサポートします。適切な SM 原因が N1 メッセージを介して UE に送信されます。

vSMF は、前述のシナリオですべてのセッション クリーンアップのために PDU セッションと関連技術情報を解放するように指示を hSMF に送信します。

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