ダウンリンク データ通知

機能の概要と変更履歴

要約データ

該当製品または機能エリア 5G-UPF
該当プラットフォーム

VPC-SI

SMI
機能のデフォルト設定 無効：設定が必要
このリリースでの関連する変更点 N/A
関連資料 UCC 5G UPF 構成およびアドミニストレーション ガイド

マニュアルの変更履歴

改訂の詳細

リリース

最初の導入。

2021.02.0

機能説明

DDN Delay と DDN Throttling をサポートする Downlink Data Notification (DDN) メッセージおよび 5G-UPF で UE がアイドル状態の場合、SAEGW でのバッファリングが 5G-UPF でサポートされます。

機能の仕組み

この項では、この機能の仕組みを紹介します。

  • バッファリングは SAEGW-U でサポートされています。

  • Release Access Beare によって UE がアイドル状態に遷移すると、バッファリングのサポートが開始されます。

  • アクティブ状態からアイドル状態への遷移：

    • SAEGW はバッファリング機能をサポートし、セッションの SAEGW-U でバッファリングをアクティブ化することを決定するため、UE が ECM-IDLE 状態に遷移すると、SAEGW-C は Sx セッション変更を介して SAEGW-U に通知します。

    • バッファリングが開始された後、最初のダウンリンクパケットがいずれかのベアラーに到着すると、SAEGW-U は SAEGW-C に通知します。 SAEGW-U は、特に指定されていない限り、Sx レポートメッセージを SAEGW-C に送信し、ダウンリンクパケットの受信先の S5/S8 ベアラーを識別します。

    • SAEGW-C は、レポートメッセージを受信すると、3GPP TS 23.401 [2] での定義に従って、DDN メッセージを MME に送信するかどうかを決定します。DDN 通知は、Sx 使用状況レポートとともに送信されます。

  • アイドル状態からアクティブ状態への遷移：

    • UE が ECM-CONNECTED 状態に遷移すると、SAEGW-C は eNodeB/RNC/SGSN の F-TEIDu を使用して Sxa インターフェイスを介して SAEGW-U を更新します。バッファリングされたデータパケットがある場合は、SAEGW-U によって eNodeB/RNC/SGSN に転送されます。

  • Apply Action が BUFFER で、SGW-U が回復した場合、SGW-U はダウンリンクデータパケットの到着時に Sx レポート（Report Type：DLDR）を開始します。

  • SGW-U には、各 Sx レポート（Report Type：DLDR）が送信された後に開始するタイマーが実装されています。Apply Action が変更されていない場合、タイマーの期限が切れると、Sx Report（DLDR レポートタイプ）が再開されます。

  • ベアラーの ARP は DDN メッセージに含まれます。

  • マルチ PDN セッションでは、ある PDN に対して DDN が開始され、ベアラーの優先順位が高い別の PDN でデータが受信された場合、DDN は優先順位がより高い ARP 値で再度開始されます。

ダウンリンクデータ通知：遅延（DDN-D）のサポート

特定の条件下では、UE がサービス要求をトリガーすると、アップリンクおよびダウンリンクデータがトリガーされ、ベアラー変更要求（MBR）を受信する前に SGW-C で受信され、不要なダウンリンクパケット通知メッセージが送信されて、MME の負荷が増加します。

このような場合、MME はこれらのイベントの発生レートをモニターします。レートがオペレータの設定値より大きくなり、MME の負荷がオペレータの設定値を超えた場合、MME はパラメータ D を使用して「Delay Downlink Packet Notification Request」を Serving Gateway に表示します。D は要求された遅延で、50 ミリ秒の倍数の整数、または 0 で指定します。S-GW では、ダウンリンクデータを受信してからダウンリンクデータ通知メッセージを送信するまでの間、この遅延が使用されます。

ダウンリンクデータ通知は、Collapsed コールと Pure-S コールの両方でサポートされています。

システムの分散型の性質により、特定の MME からのセッションは異なるセッションマネージャにオフロードされるため、セッションがオフロードされると、すべてのセッションマネージャに通知されます。また、この機能は、すべてのセッションマネージャから DEMUX マネージャにメッセージを送信できないように設計されています。

  • DDN 遅延機能では、DDN 遅延タイマーは、セッション管理機能でサポートされます。

  • 最初のデータパケットが到着すると、Sx/N4 Report メッセージが開始されますが、DDN メッセージは遅延タイマーの終了後にセッション管理機能から開始されます。

  • DDN 遅延機能はピアレベルの機能であるため、DDN 遅延値の受信元であるピアのすべてのセッションに適用されます。

  • 以前にピアから遅延値を受信していて、現在のメッセージに含まれていない場合、遅延値は 0 と見なされます。

DDN のセッションリカバリと ICSR がサポートされています。

5G SMF コール

ダウンリンクデータ通知：5G UE

UE が 5G コールモードでアイドル状態になると、SMF は FAR Apply Action が BUFFER 値に設定された Sx_Modify-Request を送信します。すべての QFI（デフォルト/専用）に対して、FAR Apply Action は BUFFER 値に設定されます。

サーバーからダウンリンクパケットを受信すると、UPF は、パケットルールの一致に従って、ルール ID（PDR ID）/QFI を含むダウンリンクデータ通知とともに Sx_Report_Request を送信します。UPF は、すべての FAR でパケット制限が 5 に達するまで、パケットのバッファリングを継続します。

UE がアクティブな場合、Sx_Modify_Request は、FAR Apply Action が FWD（転送）および TEID（トンネルエンドポイント識別子）に設定された状態で UPF に到達します。UPF はパケットをバッファリングし、FIFO として UE に送信します。各パケットでは、ルール照合はデバッファリングプロセスの後に行われます。

DDN スロットリングのサポート

MME から SGW-C への DDN 要求が多すぎると、MME での処理が過負荷になる可能性があります。この負荷を軽減するために、MME は SGW-C に対して、所定の期間に送信される DDN メッセージを一定の割合で減らすよう動的に要求します。

DDN スロットリングの場合、S-GW は、所定の期間に一定の割合の DDN をドロップする必要があります。S-GW は、各セッションマネージャで確率的アルゴリズムを使用することで、この機能を実装します。

一方、DDN スロットリングの従来の実装では、各セッションマネージャが、低優先ベアラーの保留中の DDN リストを中央エンティティと共有する必要があります。中央エンティティは保留中の DDN の正味負荷を計算し、各セッションマネージャがドロップする必要がある DDN の数を決定します。この実装では、セッションマネージャでの DDN メッセージのバッファリングが必要になります。また、シャーシ内におけるソフトウェアサブシステムの分散処理の性質上、セッションマネージャと中央エンティティ（Boxer の場合は demuxmgr）間で定期的に大量のメッセージングが必要になります。

確率的アルゴリズムを実装すると、セッションマネージャでのバッファリングと、demuxmgr とのメッセージングの必要性がなくなります。セッションマネージャでの ARP 優先順位が低いページング負荷が増加すると、確率的アルゴリズムの精度が向上します。ページング負荷が低くても、指定されたスロットリング係数にかなり近い精度となります。

リリース 10 に準拠していない MME の場合、SGW_C には CLI を使用してスロットリングを有効にするオプションがあります。

低優先ベアラーの ARP しきい値は、S-GW サービス設定を使用して設定する必要があります。たとえば、設定された ARP 値が「9」の場合、ARP が 9 を超えるベアラーはすべて、低優先ベアラーと見なされます。DDN スロットリングは、この設定によって有効になります。SGW サービス設定を通じて DDN スロットリングが有効になっている場合、MME への各 DDN メッセージには ARP IE が含まれます。

ユーザー接続タイマーのサポートなし

  • 肯定的なダウンリンクデータ通知の確認応答後にベアラー変更要求を受信しない場合、タイマーが設定されます。

  • タイマーは、DDN 確認応答を受信したときに SGW-C で開始されます。

  • ベアラー変更要求の到着時に、SGW-C はこのタイマーを停止します。

  • タイマーの期限が切れると、SGW-C はバッファリングされたパケットをドロップするように SGW-U に通知します。

DDN コールフロー

DDN の成功シナリオ

  1. MME が、その UE に対するすべてのベアラーのダウンリンクリモート TEID を解放するために、SGW-C にアクセスベアラー解放要求を送信します。

  2. アクセスベアラー解放要求を受信すると、SGW-C はすべての PDN への Sx 変更要求の Apply Action を BUFFER にして FAR を更新することで、同じ情報を SGW-U に通知します。

  3. SGW-U が、対応する PDN に対して SGW-U でバッファリングを適用後、Sx 変更応答を送信します。

  4. SGW-C が MME にアクセスベアラー解放応答を送信します。

  5. SGW-U が受信する最初のダウンリンクデータにより、SGW-C に対する Sx レポート要求（[Report Type] が「Downlink Data Report」）がトリガーされます。

  6. Sx レポート要求メッセージを受信すると、SGW-C が MME へのダウンリンクデータ通知要求メッセージを開始します。

  7. SGW-C が、SGW-U に向けて Sx レポート応答メッセージを送信します。

  8. MME は、UE にページング要求を送信できる場合、ダウンリンクデータ通知確認応答メッセージで [Cause] を「Request Accepted」に設定して、SGW-C に送信します。

  9. ページングが成功すると、SGW で S1-U 接続を設定する eNodeB TEID を使用して、MME が S-GW にベアラー変更要求を送信します。

  10. SGW-C が、新しい TEID 情報に関する更新された FAR を含む Sx 変更要求を SGW-U に送信します。SGW-U は、バッファされたすべてのデータを eNodeB を介して UE に転送できるようになりました。

  11. SGW-U が、SGW-C に Sx 変更応答を送信します。

DDN の失敗シナリオ

  1. MME が、その UE に対するすべてのベアラーのダウンリンクリモート TEID を解放するために、SGW-C にアクセスベアラー解放要求を送信します。

  2. アクセスベアラー解放要求を受信すると、SGW-C はすべての PDN への Sx 変更要求の Apply Action を BUFFER にして FAR を更新することで、同じ情報を SGW-U に通知します。

  3. SGW-U が、対応する PDN に対して SGW-U でバッファリングを適用後、Sx 変更応答を送信します。

  4. SGW-C が MME にアクセスベアラー解放応答を送信します。

  5. SGW-U が受信する最初のダウンリンクデータにより、SGW-C に対する Sx Report 要求（[Report Type] が「Downlink Data Report」）がトリガーされます。

  6. Sx Report 要求メッセージを受信すると、SGW-C は、MME に対して Downlink Data Notification 要求メッセージを開始します。

  7. SGW-C が、SGW-U 対して、Sx Report 応答メッセージを送信します。

  8. MME が UE をページングできない場合、関連する原因でダウンリンクデータ通知要求を拒否できます。

    または

    MME がダウンリンクデータ通知要求を受け入れた場合、UE がページングに応答しなかったことを SGW-C に示すために、後でダウンリンクデータ通知の失敗通知を送信します。

  9. SGW-C が DDN エラーを受信すると、次の DDN の送信をすぐに停止するために、SGW-C は、DDN エラータイマーを開始します。SGW-C は、DROBU フラグが立った Sx Modification 要求を送信し、バッファリングされたパケットと DROP としての Apply Action を破棄し、後続パケットとドロップします。

  10. SGW-U が、SGW-C に Sx 変更応答を送信します。

  11. DDN 失敗タイマーの期限が切れると、SGW-C はバッファリングを再開するために、Apply Action を BUFFER にして Sx 変更を開始します。

DDN の成功シナリオ コールフローの手順 3 以降の手順が続きます。

ユーザー接続タイマーのサポートなし

  1. MME が、その UE に対するすべてのベアラーのダウンリンクリモート TEID を解放するために、SGW-C にアクセスベアラー解放要求を送信します。

  2. アクセスベアラー解放要求を受信すると、SGW-C はすべての PDN への Sx 変更要求の Apply Action を BUFFER にして FAR を更新することで、同じ情報を SGW-U に通知します。

  3. SGW-U が、対応する PDN に対して SGW-U でバッファリングを適用後、Sx 変更応答を送信します。

  4. SGW-C が MME にアクセスベアラー解放応答を送信します。

  5. SGW-U が受信する最初のダウンリンクデータにより、SGW-C に対する Sx レポート要求（[Report Type] が「Downlink Data Report」）がトリガーされます。

  6. Sx レポート要求メッセージを受信すると、SGW-C が MME へのダウンリンクデータ通知要求メッセージを開始します。

  7. SGW-C が、SGW-U に向けて Sx レポート応答メッセージを送信します。

  8. ダウンリンクデータ通知確認応答が MME から受信されます。SGW-C が no-user-connect を開始します。

  9. eNodeB TEID 情報を含むベアラー変更要求が受信されず、no-user-connect タイマーが期限切れになった場合、SGW-C はダウンリンク データ通知を再度送信します。

  10. MME からダウンリンクデータ通知確認応答を受信します。SGW-C は、no-user-connect タイマーを再度開始します。

  11. SGW-C はメッセージに DROBU フラグを付けて、SGW-U への Sx セッション変更要求を開始します。SGW-U はこのフラグを受信すると、バッファされたデータをドロップします。新しいデータはバッファリングされ、後続の最初のパケットは、ダウンリンクデータ通知メッセージを開始するための Sx レポートメッセージを開始します。

  12. SGW-U が Sx 変更応答を送信します。

DDN 遅延タイマー

  1. MME が、その UE に対するすべてのベアラーのダウンリンクリモート TEID を解放するために、SGW-C にアクセスベアラー解放要求を送信します。

  2. アクセスベアラー解放要求を受信すると、SGW-C はすべての PDN への Sx 変更要求の Apply Action を BUFFER にして FAR を更新することで、同じ情報を SGW-U に通知します。

  3. SGW-U が、対応する PDN に対して SGW-U でバッファリングを適用後、Sx 変更応答を送信します。

  4. SGW-C が MME にアクセスベアラー解放応答を送信します。

  5. SGW-U が受信する最初のダウンリンクデータにより、SGW-C に対する Sx レポート要求（[Report Type] が「Downlink Data Report」）がトリガーされます。

  6. Sx レポート要求メッセージを受信すると、SGW-C が MME へのダウンリンクデータ通知要求メッセージを開始します。

  7. SGW-C が、SGW-U に向けて Sx レポート応答メッセージを送信します。

  8. DDN 遅延タイマー値に従い、MME からダウンリンクデータ通知確認応答を受信します。この遅延タイマー値はこのピア用に保存されるため、その後、このピアに対するすべてのダウンリンクデータ通知は、この遅延の後に開始する必要があります。

  9. ページングが成功すると、SGW で S1-U 接続を設定する eNodeB TEID を使用して、MME が SGW にベアラー変更要求を送信します。

  10. SGW-C が、新しい TEID 情報に関する更新された FAR を含む Sx 変更要求を SGW-U に送信します。 SGW-U は、バッファされたすべてのデータを eNodeB を介して UE に転送できるようになりました。

  11. SGW-C が、ベアラー変更応答を MME に送信します。

  12. SGW-U が、SGW-C に Sx 変更応答を送信します。

  13. MME が、その UE に対するすべてのベアラーのダウンリンクリモート TEID を解放するために、SGW-C に Release Access Bearer 要求を送信します。

  14. Release Access Bearer 要求の到着時に、SGW-C がすべての PDN の Sx 変更要求の Apply Action として BUFFER を使用して FAR を更新することで、同じ情報を SGW-U に通知します。

  15. SGW-U が、対応する PDN に対して SGW-U でバッファリングを適用後、Sx 変更応答を送信します。

  16. SGW-C が MME に Release Access Bearer 応答を送信します。

  17. SGW-U に到着した最初のダウンリンクデータにより、SGW-C に対する Sx レポート要求（レポートタイプはダウンリンクデータレポート）がトリガーされます。

  18. Sx レポート要求メッセージの到着時に、SGW-C が DDN 遅延タイマーを開始します。DDN 遅延タイマーが期限切れになると、SGW-C が MME へのダウンリンクデータ通知メッセージを開始します。

Sx インターフェイス

Sx セッションレベルのレポート手順

アイドルモード UE の最初のダウンリンクデータの検出（SAEGW-U が実行）：

SAEGW-U はダウンリンクパケットを受信するが、送信用の S1 ベアラーを受信せず、バッファリングが SAEGW-U によって実行される場合、UE をページングするために、最初のダウンリンクデータの検出を SAEGW-C に報告します。

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

PFCP セッションレポート要求は、PFCP セッションに関連する情報をコントロールプレーン機能に報告するために、ユーザープレーン機能によって Sxab インターフェイスを介して送信されます。

情報要素

P

条件/コメント

アプリケーション

IE タイプ

Sxa

Sxb

Sxc

N4

Report Type

M

この IE は、レポートのタイプを示します。

X

X

X

X

 Report Type

Downlink Data Report

C

この IE は、レポートタイプが Downlink Data Report を示している場合に存在します。

X

-

-

X

Downlink Data Report

PFCP セッションレポート要求内の Downlink Data Report IE

Downlink Data Report のグループ化された IE は、次の表に示すようにエンコードされます。

オクテット 1 および 2

Downlink Data Report IE タイプ = 83（10 進数）

オクテット 3 および 4

長さ = n

情報要素

P

条件/コメント

アプリケーション

IE タイプ

Sxa

Sxb

Sxc

N4

PDR ID

M

この IE は、UP 機能で受信されたダウンリンクデータパケットの PDR を識別します。

ダウンリンクデータパケットを受信した複数の PDR を表すために、このタイプの IE を複数含めることができます。

X

-

-

X

PDR ID

ユーザープレーン機能への DDN 障害に関する通知

コントロールプレーン機能はユーザープレーン機能に障害を通知します。これにより、バッファリングされたパケットがドロップされ、PFCP Sx 変更メッセージの DROBU フラグを介して DDN 関連フラグをリセットできます。

PFCPSMReq-Flags

C

DROBU（Drop Buffered Packets）：この PFCP セッションで現在バッファリングされているパケットをドロップするように UP 機能が要求された場合、CP 機能はこのフラグを設定します（注 1 を参照）。

制限事項

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

  • SAEGW バッファリングは、PDN セッションごとに 5 つのデータパケットに対して実行されます。

  • DDN プロファイル設定はサポートされていません。

  • フローアイドルタイムアウトまたはその他のケースが原因で削除されるバッファ データ（データパケットストリーム）のサポートはありません。

リリース 10 非準拠 MME の DDN スロットリング

リリース 10 以外の MME の DDN スロットリングを設定するには、次の設定を使用します。

configure 
   context context_name 
      sgw-service service_name 
         ddn throttle arp-watermark arp_value [ rate-limit limit time-factor seconds throttle-factor percent increment-factor percent [ poll-interval seconds ] throttle-time-sec seconds [ throttle-time-min minutes ] [ throttle-time-hour hour ] stab-time-sec seconds [ stab-time-min minutes ] [ stab-time-hour hour ] 
         no ddn throttle 
         end

注：

  • rate-limit ：1 秒あたりに許可される DDN。

  • time-factor ：SGW がスロットリングを決定する秒単位の期間（有効な範囲：1 ～ 300 秒）。

  • arp-value ：1 ～ 15 の有効な ARP 値。設定された値よりも大きい ARP を持つパケットはすべて、スロットリング係数に従ってスロットリングされます。

  • throttling-factor ：DDN サージの検出時にドロップされる DDN のパーセンテージ（有効範囲：1 ～ 100）。

  • throttling-time-sec ：SGW で DDN がスロットリングされる秒単位の期間（有効な範囲：0 ～ 59 秒）。

  • throttling-time-min ：SGW で DDN がスロットリングされる分単位の時間（有効な範囲：0 ～ 59 分）。

  • throttling-time-hour ：SGW で DDN がスロットリングされる時間単位の期間（有効な範囲：0 ～ 310 時間）。

  • increment-factor ：既存のスロットリング係数では DDN の急増を抑制するには不十分な場合に、スロットリング係数を動的に増加させるパーセンテージ値。

  • poll-interval ：秒単位の時間（オプションの引数、デフォルト値：1 秒、ポーリング間隔 < time-factor）

  • stab-time-sec/min/hours ：安定化時間係数。DDN レートが正常に戻った場合に、スロットリング期間全体でスロットリングを適用する必要がない期間。

リリース 10 に準拠していない MME の DDN スロットリングは、SGW での既存のリリース 10 スロットリング実装を利用します。SGW サービスの設定メカニズムを提供することで、オペレータは DDN スロットリングを適用する際に MME からのフィードバックを必要としません。この機能の重要なポイントを以下に説明します。

  1. CLI 設定は、MME/S4-SGSN ごとに適用されます。スロットリングパラメータは、MME/S4-SGSN ごとに個別に追跡されます。

  2. CLI を使用してこの機能を設定すると、demuxmgr は送信された DDN の数について各 sessmgr をポーリングします。デフォルトでは、ポーリングは毎秒実行されます。この時間間隔は、poll-interval 時間を設定することで変更できます。ポーリング間隔を長くすると、シャーシ内の内部メッセージの数が少なくなります。ただし、DDN サージの検出には時間がかかります。

  3. 時間係数を設定することで、オペレータは必要に応じて S-GW がスロットリングを適用する時間間隔を指定できます。実質的な DDN レートが時間係数の時間間隔で指定された制限内にある場合、DDN のサージがある程度許容されます。たとえば、time-factor = 10 秒、ddn rate = 1000、poll interval = 2 秒の場合について説明します。Demux は 2 秒ごとに各 sessmgr をポーリングします。許容される DDN レート制限は、1000*10 = 10 秒ごとに 10000 DDN です。たとえば、2 秒後に 4000 DDN が送信されたとします。この場合、10000 DDN のレート制限を 10 秒以内に超えるまで、S-GW はスロットリングを適用しません。これにより、DDN の断続的なバーストが可能になります。

  4. DDN レート制限は CLI を使用して設定します。たとえば、DDN レート制限が 1000 で、ポーリング間隔が 1 秒、時間係数が 5 秒の場合、許容可能なレート制限は 5 秒間で 5000 DDN です。S-GW によって送信された DDN の数が 5 秒後に 5000 を超えた場合、demuxmgr はすべての sessmgr にスロットリングを開始するように要求します。

  5. スロットリングされる DDN の割合は、スロットリング係数を使用して設定されます。

  6. 既存のスロットリング係数では DDN の急増を抑制するには不十分な場合、オペレータは増分係数を指定してスロットリング係数を増やすことができます。たとえば、スロットリング係数 = 10%、DDN レート = 1000、増分係数 = 10% の場合について説明します。スロットリングが適用されると、S-GW は最大 10% の DDN をドロップします。ただし、DDN レートがさらに 1000 を超える場合、S-GW はスロットリング係数を 20% に増やします。それでも十分でない場合は、30% に増加します。スロットリング係数を増やした後、ドロップされた DDN の数が予想よりも多い場合、スロットリング係数は増分係数によって下げまれます。たとえば、このケースでスロットリング係数を 30% に増やした後、送信される DDN が 1 秒あたり 1000 未満になった場合（時間係数とポーリング間隔を考慮）、スロットリング係数は 20 に低下します。スロットリング係数低下の下限値は、設定された値（この場合は 10%）になります。

  7. オペレータは、S-GW でスロットリングが適用される期間を設定できます。これは、日数の指定順序によっては大きな値になる場合があります（例：10 日または 240 時間）。オペレータは、 DDN レートが十分に制御されている場合に、安定化時間係数を設定することでスロットリングを停止できます。スロットリングを停止すると、DDN は不必要にドロップされません。たとえば、スロットリング時間 = 10 日、スタブ時間 = 8 時間の場合について説明します。S-GW が DDN スロットリングを開始した後、8 時間で送信された DDN + ドロップされた DDN が DDN レート * 8 時間未満の場合、スロットリングは停止されます。

リリース 10 準拠 MME の DDN スロットリング

DDN スロットリングは、ARP 値を指定することで、コール制御プロファイルを介して有効になります。たとえば、指定された ARP 値が 10 の場合、ARP 値が 10 ～ 15 であるベアラーはすべて優先順位が低いベアラーとして扱われ、スロットリング処理が行われます。S-GW サービス設定で ARP 値が指定されていない場合、スロットリングは有効になりません。また、DDN スロットリングが S-GW サービスを使用して設定されていない限り、MME への DDN メッセージに ARP IE は含まれません。MME がリリース 10 に準拠している場合、DDN 確認応答にスロットリング IE があるため、ユーザーが期間値を設定する必要はありません。準拠していない場合は、期間値を設定することで、S-GW でスロットリングを有効にできます。0 に設定されている場合、S-GW はスロットリングを繰り返し適用します。特定の期間のみスロットリングを有効にするには（リリース 10 非準拠の MME）、ユーザーが時間と分で値を設定する必要があります。設定時から、タイマーの期間が終了するまでスロットリングが S-GW で適用されます。たとえば、ユーザーが時間を 10、分を 30 と設定した場合、S-GW は次の 10 時間 30 分後にスロットリングを適用します。

再設定時に、すべてのパラメータが新しい値で設定されますが、ポーリング時間と時間係数を除き、次の再キャリブレーションからのみ適用されます。

リリース 10 MME の DDN スロットリングを設定するには、次の設定を使用します。

configure 
   context context_name 
      sgw-service service_name 
         [ no ] ddn throttle arp-watermark arp_value 
         end

注：

  • arp-value：1 ～ 15 の有効な ARP 値。設定された値よりも大きい ARP を持つパケットはすべて、スロットリング係数に従ってスロットリングされます。

SAE-GW セッションのアイドルタイマー

アイドルタイマーは、SAE-GW で発生するアイドルセッションを識別して削除するためにサポートされています。

セッションが他のネットワークノードから削除されても、セッションがアイドル状態になる場合があります。技術的な不具合により、セッションが SAE-GW に残り、こうしたアイドルセッションによってリソースが保持される可能性があります。

アイドルタイマーを設定すると、設定された時間制限よりも長くアイドル状態のままになっているセッションが削除されるため、システムのキャパシティを効果的に使用できます。


Important

この機能は現在、Pure-P および Collapsed Call に制限されています。

制限事項

アイドルタイマー機能は、冗長性イベントが発生した場合にアイドルタイマーの回復をサポートしていません。

SAE-GW セッションのアイドルタイマーの設定

アイドルタイマーは、APN レベルで設定できます。

SAE-GW セッションのアイドルタイマーを設定するには、次のコマンドを使用します。

configure 
   context context_name 
      apn apn_name 
         timeout idle timeout_value 
         no timeout idle 
         default timeout idle 
         end

  • no ：アイドルタイマー設定を無効にします。

  • default ：サブスクライバのタイムアウト設定のデフォルト値を設定します。デフォルトのアイドルタイムアウト値は 0 です。

  • idle timeout_value ：システムによりセッションが自動的に終了されるまでに、セッションがアイドル状態を維持できる時間の上限を秒単位で指定します。続けて 0 ～ 4294967295 までの秒数を指定する必要があります。「0」は、機能が無効であることを示します。

S-GW セッションのアイドルタイムアウト

この章では、S-GW セッションのアイドルタイムアウト処理機能について説明します。ASR5500 プラットフォームでは、サブスクライバセッションはコールラインで表されます。S-GW 製品のコールラインは、S11/S4 の MME/S4-SGSN および S5/S8 の P-GW を介してピアに接続します。一部のシナリオでは、ピアセッションはそれぞれのピアによって削除されます。S-GW は削除メッセージを受信も除外もしないため、その結果、S-GW セッションはアイドル状態のままになります。このようなアイドル状態のセッションや古いセッションは、効率的にリソースを消費して、キャパシティを減らすため、システム内の有効なコールラインにカウントされます。このような場合、S-GW は新しいサブスクライバ セッションの取得をトリガーします。その結果、同じサブスクライバの古いセッションが削除されます。アイドルタイムアウト処理のサポートにより、このようなセッションの識別が可能になり、リソースを解放するために削除が開始されます。

次に、S-GW セッションのアイドルタイムアウト処理について説明します。

  • サブスクライバのデータ トラフィック アクティビティがない場合、サブスクライバセッションはアイドル状態です。セッションマネージャは、コールラインの状態を追跡します。コールラインのデータトラフィックが記録されていない場合、そのようなセッションはアイドル状態に遷移します。

  • アイドルタイムアウトと呼ばれる定義されたタイムフレームの間アイドル状態にあるセッションは、アイドルタイムアウト処理の対象と見なされます。アイドル タイムアウト セッションでは、S-GW はピアへのセッションの削除を開始します。

  • アイドルタイムアウトは、ネットワーク要件に応じて秒単位で設定されます。タイムアウトの範囲は 1 ～ 4294967295 秒です。

  • アイドルタイムアウトの設定は、S-GW サービスレベルで適用され、そのサービスによって処理される一連のサブスクライバのアイドル タイムアウト処理を有効にします。

セッション アイドル タイムアウトの設定

S-GW セッションのセッションアイドルタイマーは、S-GW サービスから設定できます。

S-GW のセッション アイドル タイムアウトを設定するには、次の設定を使用します。


configure 
   context context_name 
      sgw-service service_name 
         [ no | default] timeout idle timeout_duration 
         end

注：

  • timeout idle timeout_duration ：システムがセッションを自動的に終了する前に、セッションがアイドル状態を維持できる最大時間を秒単位で指定します。timeout_duration は 1 ～ 4294967295 の範囲の整数である必要があります。0 を指定すると、この機能が無効になります。デフォルトでは、この機能は S-GW サービスで無効になっています。

show コマンドの入力と出力

この項では、この機能のサポートにおける show コマンドおよびコマンドの出力について説明します。

show subscribers user-plane-only full all

このコマンドの出力には、この機能をサポートする次のフィールドが表示されます。

  • buffered pkts

  • buffered bytes

  • buffer overflow drop pkts

  • buffer overflow drop bytes

show subscribers user-plane-only full callid <call_id>

サブスクライバごとのバッファリングを確認するには、次の設定を使用します。

  • DDN バッファ済みパケット

  • DDN バッファ済みバイト

  • DDN バッファ オーバーフロー ドロップ パケット

  • DDN バッファ オーバーフロー ドロップ バイト

バッファリングされたパケットがバッファリング解除されると、状態はゼロに戻ります。

パケット制限が 5 に達するたびに、その他のパケットは、オーバーフロー ドロップとしてドロップされます。