ワイヤレス : Cisco SGSN(Serving GPRS Support Node)

STP 輻輳、HLR MAP_RESET による SGSN の状態および SCTP リンク フラップ上の IMSIMGR

2015 年 11 月 26 日 - 機械翻訳について
その他のバージョン: PDFpdf | 英語版 (2015 年 8 月 22 日) | フィードバック

概要

この資料は Cisco 5000 シリーズ サポートするサービング General Packet Radio Service (GPRS)で集約されたサービス ルータ(ASR)のノード(SGSN)を直面する問題を記述したものです。 この問題のためのいくつかの可能性のある回避策はまた記述されています。

Krishna Kishore D V によって貢献される、Cisco TAC エンジニア。

背景説明

ASR SGSN のこの特定の一連の出来事はこの資料に説明があります:

  1. 11 月 21 日、6:25 AM: MAP_RESET はホーム ロケーション レジスタ(HLR)によって送信 されました。

  2. 11 月 21 日、8:13 AM: 輻輳 アラームはシグナル トランスファ ポイント 2 (STP-2)のために発します。

  3. 11 月 21 日、8:23 AM: 輻輳 アラームは STP-1 および STP-2 のために発します。

  4. 11 月 21 日、8:48 AM: IMSI マネージャ(IMSIMGR)は警告状態に移動します。

  5. 11 月 21 日、10:07 AM: リンクは SGSN の方の STP-2 からリセットしました。

  6. 11 月 21 日、10:15 AM: 機能強化は SGSN Location アップデート(LU)統計で観察されます。

  7. 11 月 21 日、10:00 – 10:30 AM: 統計情報は 10:00 AM で改良し始めます。

  8. 11 月 21 日、11:15 AM: 低下は SGSN LU 統計で観察されます。

  9. 11 月 21 日、11:41 AM: STP チームはリンク コードに信号を送ることを報告します(STP-2 の SLC)-1 はトラフィックを受信しません、SLC は、標準へのトラフィック戻りリセットされ。

  10. 11 月 21 日、11:42 AM: 輻輳 アラームは STP の SLC-1 のための SGSN で発します。

  11. 11 月 21 日、12:00 PM: SLC-3 がリセットされた後、GPRS LU 統計は改良します。

問題

HLR は MAP_RESET メッセージを受け取るとき、GPRS Location アップデート(GLU)のためのフラグを設定 します。 ユーザ設備(UE)が最初アップリンク パケットを送信するとき、SGSN は HLR に GLU メッセージを送ります。

At  7 AM SGSN , Nov 21st 2014 had
******** show subscriber summary *******
Total Subscribers: 2386266
Active: 2386266
sgsn-pdp-type-ipv4: 942114

 
出力例に示すように、日進行状況としてそれらによって参照する SGSN の 950,000 の包装業者データ プロトコル(PDP)コンテキストおよび UEs 試みがあります。

最初のアップリンク パケットが受信されるとき、SGSN は GLU メッセージを引き起こします。 数十万が UEs あるので、STP は生成される不断の輻輳 状態に移動しますトラフィック量を処理できないし。

メッセージは SGSN で並べられ、最大 再送信 タイムアウトは発生します。 GLU メッセージすべてが SGSN から HLR に通じないので、SGSN はモバイル サブスクライバを取り外し、再び取付けるように要求させます。 受信添付ファイル要求の数で突然サージを引き起こす孤立したサブスクライバ全員はそれから接続するように試みます。 ネットワーク の 過負荷 保護が適用するので、接続する試みのほとんどは輻輳が拒否された原因であり、モバイル サブスクライバは新しい試みを試みさせます。

この一連の出来事が開くと同時に、カスケードする影響を生成 します。 多数は認証情報(SAI)メッセージを、GLU メッセージ 送信 し、MAP-IMEI_CHECK メッセージは SGSN キューでスタックしているか、または廃棄されます。 従って、STP-1 すべておよび STP-2 リンクは輻輳 状態に達します。 各 STP に 4 つのシグナリング リンクがありますが、このシナリオで、STP-2 の最初の 3 つのリンクは非常に長くのために回復 しません。

STP リンクすべては STP-2 の輻輳 状態に移動することがわかる輻輳 アラームはここにあります:

Fri Nov 21 08:13:14 2014 Internal trap notification 1074 (M3UAPSPCongested)
ss7-routing-domain-1 peer-server-2 peer-server-process-1 (point-code-782)
congested congLevel-1
Fri Nov 21 08:13:14 2014 Internal trap notification 1074 (M3UAPSPCongested)
ss7-routing-domain-1 peer-server-2 peer-server-process-2 (point-code-782)
congested congLevel-1
Fri Nov 21 08:13:14 2014 Internal trap notification 1074 (M3UAPSPCongested)
ss7-routing-domain-1 peer-server-2 peer-server-process-3 (point-code-782)
congested congLevel-1
Fri Nov 21 08:13:29 2014 Internal trap notification 1074 (M3UAPSPCongested)
ss7-routing-domain-1 peer-server-2 peer-server-process-4 (point-code-782)
congested congLevel-1
Fri Nov 21 08:18:48 2014 Internal trap notification 1074 (M3UAPSPCongested)
ss7-routing-domain-1 peer-server-2 peer-server-process-4 (point-code-782)
congested congLevel-1
Fri Nov 21 08:20:00 2014 Internal trap notification 1074 (M3UAPSPCongested)
ss7-routing-domain-1 peer-server-2 peer-server-process-4 (point-code-782)
congested congLevel-1
Fri Nov 21 08:22:52 2014 Internal trap notification 1074 (M3UAPSPCongested)
ss7-routing-domain-1 peer-server-2 peer-server-process-4 (point-code-782)
congested congLevel-1
Fri Nov 21 08:22:55 2014 Internal trap notification 1074 (M3UAPSPCongested)
ss7-routing-domain-1 peer-server-2 peer-server-process-4 (point-code-782)
congested congLevel-1
Fri Nov 21 08:23:22 2014 Internal trap notification 1074 (M3UAPSPCongested)
ss7-routing-domain-1 peer-server-2 peer-server-process-4 (point-code-782)
congested congLevel-1
Fri Nov 21 08:26:33 2014 Internal trap notification 1074 (M3UAPSPCongested)
ss7-routing-domain-1 peer-server-2 peer-server-process-4 (point-code-782)
congested congLevel-1
Fri Nov 21 08:28:06 2014 Internal trap notification 1074 (M3UAPSPCongested)
ss7-routing-domain-1 peer-server-2 peer-server-process-4 (point-code-782)
congested congLevel-1
Fri Nov 21 08:28:45 2014 Internal trap notification 1074 (M3UAPSPCongested)
ss7-routing-domain-1 peer-server-2 peer-server-process-4 (point-code-782)
congested congLevel-1
Fri Nov 21 09:27:27 2014 Internal trap notification 1074 (M3UAPSPCongested)
ss7-routing-domain-1 peer-server-2 peer-server-process-4 (point-code-782)
congested congLevel-1

示されているように、ピアサーバ プロセスだけ(PSP) 4 クリアされ、他は輻輳 状態にまだあります:

Fri Nov 21 08:18:47 2014 Internal trap notification 1075 (M3UAPSPCongestionCleared)
ss7-routing-domain-1 peer-server-2 peer-server-process-4 (point-code-782)
congestion cleared congLevel-0

解決策

このセクションは前のセクションに説明がある問題を解決する方法を記述します。

STP リンクはたくさんのトラフィックを受信します

前のセクションに記述されているように、STP の 1 つの特定のリンクは多量のトラフィックを受信します。 です利用可能、1 そうリンクだけ STP-2 の最初の 3 つのリンクが輻輳 状態に移動し、決して回復 しないこと表示でき、輻輳 アラームは SLC-3 クリアされます(または peer-server-2-peer-server-process-4)で。 

SGSN ロード シェアリング メカニズムによって、それはすべての 4 つのリンクで均等に Message Transfer Part (MTP) レベル 3 (MTP3)ユーザ アダプテーション層(M3UA)パケットを送信する必要があります。 ただし、シンプルネットワーク メッセージ プロトコル(SNMP)トラップから、最初の 3 つの STP-2 リンクは永遠に混雑します、つまりトラフィックすべてが SLC-3 リンクにルーティングされることを意味します(トラフィックをルーティングする唯一の利用可能 な STP リンク)。 これはトラフィック ディストリビューションが STP-2 リンクの間でなぜスキューイングされるか説明します。

輻輳状況では、1つ以上のリンクは混雑させ、切り替わます非輻輳状態の間で、利用可能 なリンクだけそうトラフィックを共有します。 従って、リンクの 1 つにより多くの利用があります。 これはリンクがリンクを回復 するためにリセットするように要求します。

次の出力は M3UA レベル統計情報を表示し、統計情報を取り外したものです。 考慮するべき重要な統計情報は異常なトラフィックが見られる場合があるところに、STP-2 PSP 例 4 です: 

Time   #1:ss7rd-m3ua-psp-data-tx   #2:ss7rd-m3ua-psp-error-tx  #3:ss7rd-m3ua-psp-data-rx
21-11-14 7:30 37409 0 37942
21-11-14 8:00 43677 0 43866
21-11-14 8:30 190414 0 71844
21-11-14 9:00 547418 0 104135
21-11-14 9:30 536019 0 102477
21-11-14 10:00 376797 0 132227
21-11-14 10:30 100394 0 97302
21-11-14 11:00 119652 0 114809
21-11-14 11:30 107073 0 95354

STP データはここにあります:

   DATE             TIME     LSN     LOC  SLC    LINK        TX %     RX %
11/21/2014 9:00 sgsncisco 5216 3 A IPVL 11.26 62.07
11/21/2014 9:00 sgsncisco 5213 0 A1 IPVL 11.29 4.86
11/21/2014 9:00 sgsncisco 5214 1 A1 IPVL 11.27 4.85
11/21/2014 9:00 sgsncisco 5215 2 A IPVL 11.23 4.7

この出力は問題の時に毎秒を取り外すことをことを示します:

Time                 #13:2G-ms-init-detach      #14:2G-nw-init-detach

21-11-14 6:30 136465 7400
21-11-14 7:00 149241 9557
21-11-14 7:30 165788 12630
21-11-14 8:00 179311 16963
21-11-14 8:30 125564 44759
21-11-14 9:00 112461 95299
21-11-14 9:30 240341 112461
21-11-14 10:00 288014 116298
21-11-14 10:30 203261 123300
21-11-14 11:00 67788 122945

この出力は WEM によって大使館員に毎秒を、示したものです:

Time           #3:2G-total-attach-req-all  Request/Second

21-11-14 8:00 738279 205.078
21-11-14 9:00 14053511 3903.753
21-11-14 10:00 24395071 6776.409
21-11-14 11:00 24663454 6850.959
21-11-14 12:00 17360687 4822.413

IMSIMGR は状態に警告します

各々の新しいコール IMSI/Packet 一時モバイル サブスクライバ識別(P-TMSI)付加およびルーティング エリア アップデート(RAU)要求は IMSIMGR によって処理する必要があります。

保守的な観測によって、システムは 6,850 の 2-G 付加要求 毎秒およびおよそ 5,313 の 3-G 付加要求 毎秒のピーク値を受け取ります。 ネットワーク の 過負荷 保護のために設定できる最大値は 5,000 の付加要求 毎秒です。 IMSIMGR を操作可能な状態で保存するために、システムは UEs からのそのような多数の呼び出しを扱うことができません。

この問題はキューサイズが 1,500 の付加要求 毎秒に達するとき 8 AM 後始まります、:

network-overload-protection sgsn-new-connections-per-second 500 action
reject-with-cause congestion queue-size 1500 wait-time 5

およそ 12,000 の付加要求 毎秒があるので、ほぼ 9,000 の呼び出しは IMSIMGR によって処理され、拒否されます。 これにより IMSIMGR CPU 処理は高い状態に達します。

SGSN が付加要求の設定された番号より多くをすぐに受け取る場合、要求はペーシング キューで高い受信付加によるバッファオーバーフローが評価するときだけバッファリングされ、廃棄されます。 キューのメッセージはまでの First In First Out (FIFO; 先入れ先出し) プロセスに従ってキューメッセージ ライフタイムが設定された待ち時間を交差させるときエージング アウト処理されます。

リジェクトを選択するか、またはプリファレンスに基づいてオプションを廃棄するとき Cisco はアップリンク プロシージャを試みる前にネットワークの状態を理解することを可能にするネットワークの輻輳を示すためにリジェクト原因コードを使用することを推奨します。 

HLR 失敗

第 3 世代別パートナーシップ プロジェクト(3GPP)技術仕様(TS)によって 23.060、このセクションは HLR 再始動の間に SGSN 動作を記述します。 SGSN は MAP リセットを受け取る時はいつでも、サブスクライバのための HLR の方の UL 要求を送信 することを期待します。

HLR は再起動するとき、登録されているモバイル ステーション(MS)のどれまたは多く各 SGSN にリセット メッセージをに送ります。 これにより SGSN は SGSN にモービル交換局(MSC) /Visiting Location レジスタ(VLR)アソシエーション 存在 無効として関連したモービル管理 コンテキストを示します。 後最初の有効な論理リンク制御 (LLC) フレームの受信またはマーク付きモバイル ステーションからの最初の有効な GPRS トンネリング プロトコル ユーザ(GPT-U)パケットまたはアップリンク シグナリングメッセージの受信が(Iu モードのために) HLR 次に、SGSN UL を付加要求または相互SGSN ルーティング エリア(RA)アップデート手順行った後(A/Gb モードのために)。 また非 GPRS アラート フラグ(NGAF)が設定 されれば、非 GPRS アラート句のプロシージャは続かれます。 MSC/VLR の方の UL プロシージャおよびプロシージャは最大 オペレータ 設定のための SGSN によって高いシグナリング ロードを避けるために、リソースの使用に依存その当時遅れるかもしれません。

: 持久記憶装置への HLR データの定期的なバックアップは TS 23.007 [5] に記述されているように必須、です。

推奨事項

Cisco はこの問題を解決するためにこれらのステップを完了することを推奨します:

  1. 新しい接続 毎秒の数を増加して下さい。 これは付加要求の平均数に基づいて計算することができます。

  2. 理想値に STP リンクの Transactions Per Second (TPS)を高めて下さい。

  3. 5 に 600 というデフォルト SCTP-RTO-MAX 値を(600*100 = 60,000)変更して下さい(5*100 ms)。 たとえば、4,000 TPS の 2 STP のために、SGSN からの 1,000 付加要求 毎秒までサポートできます。

: 各付加要求は STP の方の 4 つのトランザクションという結果に終ります、つまり 1,000 の付加要求 毎秒が 4,000 TPS という結果に終ることを意味します。


理想的には 125 の付加要求が STP リンクごとに処理することができるように、各 STP に 4 つのリンクがあります。 これは STP リンクすべてを渡って均等に配られます。 ただし、リンクの 1 つがダウン状態になれば、多くの再接続試みは見られます、キューは一杯になり、パケット破棄は発生します。 より多くのリンクがダウン状態になる場合、トラフィックは不均等に分散されます。

トラフィック フロー

UE トラフィックはリニア方式に続きません。 それは通常バーストにおよび多くの再接続試みと発生します。 SGSN は STP にバンドルのトラフィックを送信 します。 その当時、トラフィック量は STP の設定された TPS を超過します。 既により多くの呼び出しを処理している、SGSN は並べられる SCTP データ チャンクを並べ始めます場合これにより STP でいくつかのリンクは低いウィンドウ サイズをアドバタイズし始めます。 それは切れるためにそれから RTO 最大タイマーを待っています。

STP が定期的によいアドバタイズされたウィンドウ サイズを送信 する場合、SCTP_RTO_MAX 値が 5 秒にまたはより少なく下がる場合より多くの SCTP データ チャンクを送信できるはずです。 キューはより速くクリアされ、M3UA 輻輳 アラームは引き起こされません。 さらに、パケットフローを制御するために SCTP によって引き起こされる 内部 フロー 指揮 旗を見ないで下さい。

SGSN はアドバタイズされたウィンドウ サイズに基づいている、受け入れる STP がことができる量のパケットだけを送信します。 STP リンクごとの TPS を増加する場合、STP 輻輳を避けるのを助け、SCTP_RTO_MAX タイマーを値を小さくします。

SGSN の M3UA によって混雑させるアラームのためのトリガー

Stream Control Transmission Protocol (SCTP) 選択確認応答(SACK)メッセージのアドバタイズされたウィンドウ サイズがゼロ(かゼロ)に密接なら、SGSN によってはメッセージがそのピア エンドポイントのために送信 するべきではないことを示すために M3UA アラームが発します。 これによりリンクは混雑した状態にフラップするか、または移動します。 SGSN がより高いウィンドウ サイズを送信 するので、ピア ノードから M3UA データを受け取り続けピア ポイント コードが決して混雑した状態から出ない場合それらのパケットは待っているキューに廃棄されるかもしれません。

次に例を示します。

  1. SCTP は M3UA にフロー制御 開始する示す値を送ります。

  2. M3UA はアソシエーションのための輻輳アクティブなフラグを設定 し、フロー制御ステータスについての SCTP を定期的にポーリングし始めます。

  3. アソシエーションはフロー制御にある間、QUEUE_SIZE が 8,000 に達するまでそのアソシエーションのための未来のデータ要求を並べます。 その時、アソシエーションのための未来のメッセージは廃棄されます。

  4. STP が適切なアドバタイズされたウィンドウ サイズを送信 する場合、M3UA は 5,000 に達するまで並べられるメッセージを空にするように試みます。 RTO タイマーはまたこれのロールを担います。

SCTP メッセージはフロー制御 フラグが本当になる、および STP 応答に従って SGSN そしてプロセス並べられますそれらのアソシエーションのためにだけ:

*Peer Server Id :        2   Peer Server Process Id:        2 

Association State : ESTABLISHED

Flow Control Flag : TRUE
Peer INIT Tag : 20229
SGSN INIT Tag : 3315914061
Next TSN to Assign to
Outgoing Data Chunk : 3418060778
Lowest cumulative TSN acknowledged : 3418060634
Cumulative Peer TSN arrived from peer : 103253660
Last Peer TSN sent in the SACK : 103253658
Self RWND : 1048576
Advertised RWND in received SACK : 8
Peer RWND(estimated) : 8
Retransmission counter : 0
Zero Window Probing Flag : FALSE
Last Tsn received during ZWnd Probing : 0
Bytes outstanding on all
addresses of this association : 19480
Congestion Queue Length : 143
Ordered TSN assignment Waiting QLen : 8050
Unordered TSN assignment Waiting QLen : 0
Total number of GAP ACKs Transmitted : 279
Total number of GAP ACKs Received : 58787


Path No. : 1

Current CWND : 11840
SSThresh : 11840
Partial Bytes Acked : 0
Bytes Outstanding for this Path : 19480
Current RTO for this Path(in ms) : 60000

示されているように、輻輳の後ろの理由は送信固まりの総数が 5,000 限界(8050+143=8193)を超過し、廃棄された SCTP データ要求という結果に終る 60 秒 RTO 最大タイマーを見つけることです。 また、より高い RTO タイマーがあります。


関連するシスコ サポート コミュニティ ディスカッション

シスコ サポート コミュニティは、どなたでも投稿や回答ができる情報交換スペースです。


Document ID: 118937