内容

概要

背景説明

問題

解決方法

STPリンクが受信するトラフィックが多すぎる

IMSIMGRが警告状態

HLR障害

推奨事項

Traffic flow

SGSNのM3UA輻輳アラームのトリガー

概要

このドキュメントでは、Cisco 5000シリーズアグリゲーションサービスルータ(ASR)のServing General Packet Radio Service(GPRS)サポートノード(SGSN)で発生する問題について説明します。 この問題に対して考えられる回避策についても説明します。

背景説明

このドキュメントでは、ASR SGSNに関するこの特定のイベントチェーンについて説明します。

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

2. 11月21日午前8時13分:信号転送ポイント2(STP-2)の輻輳アラームが発生します。

3. 11月21日午前8時23分:STP-1とSTP-2に対して輻輳アラームが発生します。

4. 11月21日午前8時48分:International Mobile Subscriber Identity Manager(IMSIMGR)がwarn状態に移行します。

5. 11月21日午前10時7分:STP-2からSGSNに向けてリンクがリセットされます。

6. 11月21日午前10時15分:改善は、SGSNロケーション更新(LU)統計情報で確認されます。

7. 11月21日、10:00   10:30 AM:統計は午前10時に改善し始める。

8. 11月21日午前11時15分:SGSN LU統計情報で低下が確認されます。

9. 11月21日午前11時41分:STPチームは、STP-2のシグナリングリンクコード(SLC)-1がトラフィックを受信せず、SLCがリセットされ、トラフィックが正常に戻ることを報告します。

10. 11月21日午前11時42分:STPのSLC-1のSGSNで輻輳アラームが発生します。

11. 11月21日、午後12時:SLC-3がリセットされると、GPRS LU統計情報が改善されます。

問題

HLRはMAP_RESETメッセージを受信すると、GPRS Location Update(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個のPacker Data Protocol(PDP)コンテキストが存在し、UEは日の経過に応じてそれらをブラウズしようとします。

最初のアップリンクパケットが受信されると、SGSNはGLUメッセージをトリガーします。数十万のUEが存在するため、STPは生成されるトラフィック量を処理できず、永続的な輻輳状態に移行します。

メッセージはSGSNでキューに入れられ、最大再送タイムアウトが発生します。すべてのGLUメッセージがSGSNからHLRに渡されないため、SGSNはモバイル加入者を強制的に切り離し、再接続を要求します。その後、切断されたすべてのサブスクライバが接続を試み、着信接続要求の数が急増します。ネットワーク過負荷保護が適用されるため、ほとんどの接続試行は輻輳のために拒否され、モバイル加入者は新しい試行を行わざるを得なくなります。

この一連のイベントが展開すると、カスケード効果が発生します。多くのSend Authentication Information(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の特定のリンクが大量のトラフィックを受信します。STP-2の最初の3つのリンクが輻輳状態に移行し、回復しないことが確認できます。したがって、1つのリンクだけが使用可能で、SLC-3（またはpeer-server-2-peer-server-process-4）で輻輳アラームがクリアされます。

SGSNロードシェアリングメカニズムに従って、メッセージ転送部(MTP)レベル3(MTP3)User Adaptation Layer(M3UA)パケットを4つのリンクすべてで均等に送信する必要があります。ただし、Simple Network Message Protocol（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

この出力は、問題発生時の1秒あたりの接続解除を示しています。

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に基づく1秒あたりのアタッチ数を示しています。

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 Temporary Mobile Subscriber Identity(P-TMSI)アタッチおよびルーティングエリアアップデート(RAU)要求は、IMSIMGRによって処理される必要があります。

控えめな見解として、システムは1秒あたり6,850 2-Gの接続要求と1秒あたり約5,313 3-Gの接続要求のピーク値を受信します。ネットワーク過負荷保護に設定できる最大値は、1秒あたり5,000の接続要求です。IMSIMGRを動作可能な状態に維持するために、システムはUEからこのような多数のコールを処理できません。

この問題は、キューのサイズが1秒あたり1,500のアタッチリクエストに達した午前8時から始まります。

network-overload-protection sgsn-new-connections-per-second 500 action

reject-with-cause congestion queue-size 1500 wait-time 5

1秒あたり約12,000の接続要求があるため、約9,000のコールがIMSIMGRによって処理され、拒否されます。これにより、IMSIMGR CPU処理が高状態になります。

SGSNが設定された数を超えるアタッチリクエストを1秒間に受信した場合、そのリクエストはペーシングキューにバッファリングされ、高いインバウンドアタッチレートのためにバッファオーバーフローが発生した場合にのみ廃棄されます。キュー内のメッセージは、キューイングされたメッセージのライフタイムが設定された待機時間を超えた場合にエージングアウトするまで、先入れ先出し(FIFO)プロセスに従って処理されます。

プリファレンスに基づいて拒否または廃棄オプションを選択する場合、ネットワーク内の輻輳を示すために拒否原因コードを使用することを推奨します。これにより、アップリンク手順を試す前にネットワークの状態を理解できます。

HLR障害

第3世代パートナーシッププロジェクト(3GPP)技術仕様(TS)23.060に従い、このセクションでは、HLR再起動時のSGSNの動作について説明します。SGSNがMAPリセットを受信するたびに、加入者のHLRに対してUL要求を送信することが予想されます。

HLRは、再起動時に、1つ以上のモバイルステーション(MS)が登録されている各SGSNにリセットメッセージを送信します。これにより、SGSNとモバイルスイッチングセンター(MSC)/ビジターロケーションレジスタ(VLR)の関連付けが存在する場合、SGSNは関連するモバイル管理コンテキストを無効としてマークします。最初の有効なLogical Link Control(LLC)フレーム（A/Gbモード）の受信後、またはマークされたモバイルステーションから最初の有効なGPRS Tunneling Protocol User(GPT-U)パケットまたはアップリンクシグナリングメッセージ（Iuモード）の受信後、HLRへのULルーティングエリア(RA)の更新手順。また、Non-GPRS Alert Flag (NGAF)が設定されている場合、Non-GPRS Alert句の手順に従います。MSC/VLRに対するUL手順と手順は、高いシグナリング負荷を回避するために、その時点でのリソースの使用に応じて、最大オペレータ設定のSGSNによって遅延される可能性があります。

注：TS 23.007 [5]で説明されているように、不揮発性ストレージへのHLRデータの定期的なバックアップが必須です。

推奨事項

この問題を解決するには、次の手順を実行することを推奨します。

1. 1秒あたりの新しい接続数を増やします。これは、アタッチ要求の平均数に基づいて計算できます。

2. STPリンクのTransactions Per Second(TPS)を理想的な値に増やします。

3. デフォルトのSCTP-RTO-MAX値を600(600*100 = 60,000)から5(5*100 ms)に変更します。 たとえば、TPSが4,000の2つのSTPでは、SGSNからの最大1,000の接続要求を1秒あたりサポートできます。

注：各付加要求はSTPに対して4つのトランザクションを行います。つまり、1秒あたり1,000の付加要求は4,000のTPSを生成します。

各STPには4つのリンクがあり、STPリンクごとに125の接続要求を処理できることが理想的です。これは、すべてのSTPリンクに均等に分散されます。ただし、リンクの1つがダウンすると、多くの再接続試行が見られ、キューがいっぱいになり、パケットの廃棄が発生します。さらに多くのリンクがダウンすると、トラフィックが不均等に分散されます。

Traffic flow

UEトラフィックは直線的な方式に従いません。通常はバーストで発生し、多くの再接続試行が発生します。SGSNはバンドル内のトラフィックをSTPに送信します。その時点で、トラフィック量はSTPで設定されているTPSを超えています。これにより、STP内の一部のリンクは、すでに多くのコールを処理している場合に低いウィンドウサイズのアドバタイズを開始し、SGSNは、キューイングされているSCTPデータチャンクのキューイングを開始します。その後、RTO MAXタイマーが期限切れになるまで待機します。

STPが正常なアドバタイズウィンドウサイズを定期的に送信する場合、SCTP_RTO_MAX値が5秒以下に減らされると、より多くのSCTPデータチャンクを送信できるはずです。キューはより高速にクリアされ、M3UA輻輳アラームはトリガーされません。さらに、パケットフローを制御するためにSCTPによってトリガーされる内部フロー制御(IRC)フラグが表示されないようにします。

SGSNは、アドバタイズされたウィンドウサイズに基づいて、STPが受け入れ可能な量のパケットだけを送信します。STPリンクごとにTPSを増やすと、STPの輻輳を回避し、SCTP_RTO_MAXタイマーを減らすことができます。

SGSNのM3UA輻輳アラームのトリガー

Stream Control Transmission Protocol(SCTP)Selective Acknowledgement(SACK)メッセージのアドバタイズされたウィンドウサイズがゼロ（またはゼロ）に近い場合、SGSNは、そのピアエンドポイントにメッセージを送信しないことを示すためにM3UAアラームを生成します。これにより、リンクがフラップしたり、輻輳状態に移行したりします。SGSNはより大きなウィンドウサイズを送信するため、ピアノードからのM3UAデータの受信を継続し、ピアポイントコードが輻輳状態から決して外れない場合は、これらのパケットが待機キューにドロップされる可能性があります。

以下が一例です。

1. SCTPはM3UAにフロー制御開始指示を送信します。

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

3. 関連付けがフロー制御中は、QUEUE_SIZEが8,000に達するまで、その関連付けの将来のデータ要求をキューに入れます。その時点で、関連付けの将来のメッセージは破棄されます。

4. STPが適切なアドバタイズされたウィンドウサイズを送信すると、M3UAは5,000に達するまでキューに入れられたメッセージを空にしようとします。RTOタイマーもこの役割を果たします。

SCTPメッセージは、フロー制御フラグがTrueになるアソシエーションに対してのみキューイングされ、SGSNはSTP応答に従って処理します。

*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)を超え、60秒のRTO最大タイマーに達したため、SCTPデータ要求が廃棄されるためです。また、より高いRTOタイマーがあります。