HLR MAP_RESET による SGSN での STP の輻輳、IMSIMGR オーバー状態、SCTP リンクのフラップ

はじめに

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

背景説明

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

1. 11月21日、午前6:25:MAP_RESETがホームロケーションレジスタ(HLR)によって送信されました。
   
   
2. 11月21日、午前8:13:Signal Transfer Point 2(STP-2)で輻輳アラームが発生します。
   
   
3. 11月21日、午前8:23:STP-1およびSTP-2で輻輳アラームが発生します。
   
   
4. 11月21日、8:48 AM:International Mobile Subscriber Identity Manager(IMSIMGR)がwarn状態に移行します。
   
   
5. 11月21日午前10:07：リンクがSTP-2からSGSNにリセットされます。
   
   
6. 11月21日、午前10時15分:SGSN Location Update(LU)統計で改善が確認されました。
   
   
7. 11月21日10:00 € 10:30 AM：統計情報は“午前10:00に向上し始めます。
   
   
8. 11月21日、11:15 AM: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はGLUメッセージをHLRに送信します。

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はモバイル加入者を強制的に切断し、再接続を要求します。その後、切断されたすべてのサブスクライバがアタッチを試行し、その結果、インバウンドのアタッチ要求数が急増します。ネットワーク過負荷保護が適用されるため、接続の試行のほとんどは輻輳のために拒否され、モバイル加入者は新しい試行を強制的に行います。

この一連のイベントが展開されると、カスケード効果が生じます。多くの送信認証情報(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ロードシェアリングメカニズムに従い、SGSNはMessage Transfer Part(MTP)Level 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

Warn状態の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処理がhigh状態に達します。

SGSNが1秒間に設定された数を超えるアタッチ要求を受信した場合、その要求はペーシングキューにバッファされ、高い着信アタッチレートが原因でバッファがオーバーフローしたときにのみドロップされます。キュー内のメッセージは、キューに入れられたメッセージの有効期間が設定された待機時間を超えてエージングアウトするまで、First-In, First-Out（FIFO；先入れ先出し）プロセスに従って処理されます。

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

HLR障害

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

HLRが再起動すると、HLRは1つ以上のMobile Station（MS；モバイルステーション）が登録されている各SGSNにリセットメッセージを送信します。これにより、SGSNとモバイルスイッチングセンター(MSC)および訪問先場所レジスタ(VLR)の関連付けが存在する場合、SGSNは関連するモバイル管理コンテキストを無効としてマークします。最初の有効なLogical Link Control（LLC；論理リンク制御）フレーム（A/Gbモードの場合）を受信した後、またはマーキングされたMobile Stationから最初の有効なGPRS Tunneling Protocol User(GPT-U)パケットまたはアップリンクシグナリングメッセージ（Iuモードの場合）を受信した後、SGSNはアタッチ要求またはSGSN間ルーティングエリア(RA)の更新手順のようにHLRにULを実行します。また、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ミリ秒）に変更します。たとえば、4,000のTPSを持つ2つのSTPの場合、SGSNからのアタッチ要求を1秒あたり最大1,000までサポートできます。

注：アタッチ要求が発生するたびに、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によってトリガーされる内部フロー制御フラグも表示されません。

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

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

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

ランダム データの例は次のとおりです。

1. SCTPは、フロー制御開始インジケータ(FXS)を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タイマーが高くなっています。