はじめに
このドキュメントでは、Cisco CUPS製品で使用可能なFARバッファリング制限機能の概念、実装、および利点について説明します。
前提条件
要 件
次の項目に関する知識があることが推奨されます。
- Long Term Evolution(LTE)モビリティ
- コントロールプレーンおよびユーザプレーン機能(CUPS)アーキテクチャ
使用するコンポーネント
このドキュメントの内容は、特定のソフトウェアやハードウェアのバージョンに限定されるものではありません。
このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されたものです。このドキュメントで使用するすべてのデバイスは、クリアな(デフォルト)設定で作業を開始しています。本稼働中のネットワークでは、各コマンドによって起こる可能性がある影響を十分確認してください。
環境
環境
FARの基本概念
Forwarding Action Rule(FAR;転送アクションルール)では、ユーザプレーン機能(Serving Gateway(SGW)-UまたはPDN Gateway(PGW)-U)が、対応するPacket Detection Rule(PDR;パケット検出ルール)に一致するパケットに対して実行するアクションを指定します。 FARで指定できるアクションは次のとおりです。
- 指定された宛先(インターネット/パケットデータネットワーク(PDN)またはeNodeBなど)にパケットを転送します。
- パケットを廃棄
- パケットの複製(合法的傍受またはトラフィックミラーリングの目的で使用)
- パケットをバッファリングする。この場合、関連するバッファリングアクションルールで、バッファリングおよびコントロールプレーン機能への通知に使用するパラメータを指定できる
基本的にFARにより、コントロールプレーンでは、ユーザプレーンのトラフィックフローとポリシーの適用をリモートかつ動的に管理できます。これは、CUPSアーキテクチャの柔軟性とスケーラビリティのメリットにとって重要です。
バックグラウンド情報
User Equipment(UE;ユーザ機器)がアイドル状態になると、Mobility Management Entity(MME;モビリティ管理エンティティ)は、UEのすべてのS1-Uベアラをリリースするために、SGW-CにRelease Access Bearer Request(RAQ)を送信します。同時に、SGW-CはSGW-Uにすべてのダウンリンクパケットをドロップし、ベアラ状態をアイドルに更新するように通知し、ユーザプレーン機能はデフォルトでダウンリンクデータのバッファリングを特定の制限に開始します。
すべてのユーザプレーンが応答すると、コントロールプレーンはサブスクライバコンテキストを更新し、ベアラが解放されたことをMMEに通知します。この手順により、サブスクライバが非アクティブな間、必要な消費リソースがすべて解放されます。このメカニズムにより、UEの状態遷移とネットワーク内のリソース使用率を効率的に管理できます。
問題の説明
通常のシナリオでは、UEがアイドル状態になるたびに、ユーザプレーン機能がダウンリンクデータのバッファリングを開始します。デフォルトでは、CUPSプラットフォームで最大5つのパケットがFARごとにバッファリングされます。SGW-Uで最初のダウンリンクデータパケット(DDP)を受信すると、SGW-Cはダウンリンクデータ通知(DDN)要求をMMEに送信して、ダウンリンク(DL)トラフィックを受け入れるための可用性をチェックするためにUEのページングを開始します。ページングが成功すると、MMEはSGW-CにModify Bearer Request(MCR)を送信します。これにより、すでにキューに入っているデータパケットのバッファリングを解除し、以前と同様にDLパケットの転送を開始することがSGW-Uに通知されます。
何らかの理由でMMEがUEにページングできない場合、またはSGW-Uでのこの5つのパケットバッファ制限しきい値に達する前にMMEがUEからページング成功応答を取得できなかった場合は、ダウンリンク方向のDDNバッファオーバーフロー廃棄パケットが増加する可能性があります。その結果、エンドユーザのモバイルデータサービスの品質が低下する可能性があり、ネットワーク全体のパフォーマンスとユーザエクスペリエンスに影響を与える可能性があります。
DDN成功シナリオコールフロー
DDN成功シナリオコールフロー
- MMEは、そのUEのすべてのベアラのダウンリンクのリモートトンネルエンドポイント識別子(TEID)をリリースするために、SGW-Cにリリースアクセスベアラ要求(RAQ)を送信します。
- リリースアクセスベアラ要求が到着すると、SGW-Cは、すべてのPDNのSx Modification Requestのバッファとして適用アクションを使用してFARを更新することにより、同じことをSGW-Uに通知します。
- SGW-Uは、対応するPDNのSGW-Uでバッファリングを適用した後にSx Modification応答を送信します。
- SGW-CはMMEにリリースアクセスベアラ応答を送信します。
- SGW-Uに到着する最初のダウンリンクデータは、SGW-CへのSxレポート要求(ダウンリンクデータレポートのレポートタイプ)をトリガーします。
- Sx Report Requestメッセージが到着すると、SGW-CはMMEへのDDN要求メッセージを開始します。
- SGW-CがSGW-UにSx Report Responseメッセージを送信
- MMEがUEに向けてページング要求を送信できる場合、DDN確認応答メッセージで原因を「Request Accepted」として設定し、SGW-Cに送信します。
- ページングが成功すると、MMEはSGWでS1-U接続を設定するeNodeB TEIDを使用してModify Bearer要求をS-GWに送信します。
- SGW-CがSGW-Uに対し、新しいTEID情報に関する更新されたFARを含むSx変更要求を送信します。SGW-UはバッファされたすべてのデータをeNodeB経由でUEに転送できるようになりました。
- SGW-UがSGW-CにSx Modification応答を送信します。
DDN障害シナリオのコールフロー
DDN障害シナリオのコールフロー
- MMEは、そのUEのすべてのベアラのダウンリンクリモートTEIDをリリースするために、SGW-Cにリリースアクセスベアラ要求を送信します。
- リリースアクセスベアラ要求が到着すると、SGW-Cは、すべてのPDNのSx Modification RequestのバッファとしてApply Actionを使用してFARを更新することで、同じことをSGW-Uに通知します。
- SGW-Uは、対応するPDNのSGW-Uでバッファリングを適用した後にSx Modification応答を送信します。
- SGW-CはMMEにリリースアクセスベアラ応答を送信します。
- SGW-Uに到着する最初のダウンリンクデータは、SGW-CへのSxレポート要求(ダウンリンクデータレポートのレポートタイプ)をトリガーします。
- Sx Report Requestメッセージが到着すると、SGW-CはMMEへのDDN要求メッセージを開始します。
- SGW-CがSGW-UにSx Report Responseメッセージを送信
- MMEがUEにページングできない場合、関連する原因でDDN要求を拒否できます。
または
MMEがDDN要求を受け入れると、UEがページングに応答しなかったことをSGW-Cに示すために、後でDDN障害表示を送信します。
- SGW-CはDDN障害を受信したため、次のDDNの送信を即座に停止するために、SGW-CはDDN障害タイマーを開始します。SGW-Cは、バッファされたパケットを破棄するためにDrop Buffered(DROBU)フラグを付けてSx Modification Request(SCOR)を送信し、後続のパケットをドロップするために「drop」としてアクションを適用します。
- SGW-UがSGW-CにSx Modification Responseを送信
- DDN障害タイマーが期限切れになると、SGW-Cはバッファリングを再開するためにバッファとしてApply Actionを使用してSx変更を開始します。
- 「DDN成功シナリオ」コールフローのステップ3から続くステップがあります。
ソリューションの概要
ユーザプレーンのFARごとにバッファされるパケットの数は、Cisco CUPSコントロールプレーンで設定できます。これにより、Active Charging Service(ACS)サブシステムで使用可能なCLI buffering-limit far-max-packets <num>を使用して、この5つのパケットバッファの制限を克服できます。オペレータは、コールモデルに応じてFARバッファ制限を制御するために1 ~ 128の範囲の値を決定し、Quality of Service(QoS)を最適化してパケットドロップを削減することで、UEエクスペリエンスを向上させ、ネットワーク全体のパフォーマンスを向上させることができます。
コンフィギュレーション
local]hostname# configure
[local]hostname(config)# active-charging service ecs
[local]hostname(config-acs)# buffering-limit far-max-packets <num>
[local]hostname(config-acs)# end
[local]hostname#
[local]hostname# push config-to-up all
検証
show user-plane-service statistics drop-counter
Packet Drop Data Statistics:
-----------------------------------------------
NAT packets processing failure:
NAT on demand handling: 0
IP allocation is in progress: 0
ICMP Packet translation: 0
Invalid Callid: 0
Invalid Header: 0
ICMP Payload Parse Failure: 0
FIREWALL packets processing failure:
Policy not found: 0
No Matching GX rule found: 32362
Flow apply action:
Discard: 0
Readdress Failure: 0
Redirect-URL: 0
Packet exceeds the MTU size: 1007742185
Failure in processing FAR Buffer packets: 21
FAR Apply Action Drop: 28792512
Traffic Steering Failure: 0
QER Gate Status Closed: 0
Content-filtering Discard Action: 0
IP Header Validation Failed: 6020295
ADF level failure:
UL TEID/QFI key mismatch: 0
DL TFT mismatch: 0
DL QFI mismatch: 0
URL Blacklisting Discard Action: 0
DDN buffer overflow drop packets: 11
APN AMBR Packets Drop: 5
ITC Packets Drop: 263040006
ACL Drop: 31149173
CC Dropped Packets: 1513522
FastPath Misc Drops:
Overload Protection: 0
Invalid Client: 0
Stream ID 0: 0
Invalid Stream ID: 145
OHR Mismatch Packet Drops: 7091753
「DDNバッファオーバーフロー廃棄パケット」カウンタを、デフォルトのbuffering-limit far-max-packetsの値(5つ)と、同じコールモデルフレーバーと継続時間を持つ、5よりも高い別の値と比較します。値が5より大きい場合は、このカウンタの値が減少します。
関連情報