由於HLR MAP_RESET導致SGSN中的STP擁塞、IMSIMGR Over State和SCTP鏈路擺動

簡介

本檔案介紹Cisco 5000系列聚合服務路由器(ASR)的服務通用封包無線服務(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:國際移動使用者身份管理器(IMSIMGR)進入警告狀態。
   
   
5. 11月21日上午10:07：鏈路從STP-2重置為SGSN。
   
   
6. 11月21日上午10:15:在SGSN位置更新(LU)統計中觀察到改進。
   
   
7. 11月21日，上午10â€10“:30：統計在上午10:00開始改善。
   
   
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:00：重置SLC-3後，GPRS LU統計資訊將改善。

問題

當HLR收到MAP_RESET消息時，它為GPRS位置更新(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)情景，UE會嘗試在當天進行瀏覽。

當接收到第一上行鏈路資料包時，SGSN觸發GLU消息。由於有數十萬個UE，STP無法處理生成的流量並進入常年擁塞狀態。

消息在SGSN中排隊，並且發生最大重傳超時。由於所有GLU消息不會從SGSN傳遞到HLR，因此SGSN必須分離移動使用者並請求他們重新連線。然後，所有已分離的使用者都會嘗試連線，從而導致入站連線請求的數量突然激增。由於應用了網路過載保護，由於擁塞，大多數連線嘗試被拒絕，並且移動使用者被迫進行新的嘗試。

隨著這一系列事件的展開，它產生了級聯影響。許多傳送身份驗證資訊(SAI)消息、GLU消息和MAP-IMEI_CHECK消息停滯在SGSN隊列中或被丟棄。因此，所有STP-1和STP-2鏈路都達到擁塞狀態。每個STP有四個信令鏈路，但在這種情況下，STP-2的前三個鏈路恢復時間不會很長。

以下是擁塞警報，其中可以看到所有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中的前三條鏈路進入擁塞狀態且永遠不會恢復，因此只有一個鏈路可用，並且擁塞警報在SLC-3（或peer-server-2-peer-server-process-4）上被清除。 

根據SGSN負載共用機制，它必須在所有四條鏈路上平均傳送消息傳輸部分(MTP)第3級(MTP3)使用者適配層(M3UA)資料包。但是，從簡單網路消息協定(SNMP)陷阱中，前三條STP-2鏈路常年擁塞，這意味著所有流量都路由到SLC-3鏈路（路由流量的唯一可用STP鏈路）。這解釋了為什麼流量分佈在STP-2鏈路之間傾斜。

在擁塞情況下，一個或多個鏈路在擁塞狀態和非擁塞狀態之間切換，因此只有可用鏈路共用流量。因此，其中一個鏈路的利用率更高。這需要鏈路重置才能恢復鏈路。

下一個輸出顯示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

處於警告狀態的IMSIGR

每個新的呼叫IMSI/資料包臨時移動使用者標識(P-TMSI)附加和路由區域更新(RAU)請求必須由IMSIMGR處理。

根據保守觀察，系統每秒接收峰值為6,850個2-G連線請求，每秒接收約5,313個3-G連線請求。可為網路過載保護設定的最大值為每秒5,000個連線請求。為了保持IMSIMGR處於可操作狀態，系統無法處理來自UE的如此大量的呼叫。

當隊列大小達到每秒1,500個附加請求時，此問題在上午8點之後開始：

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

由於每秒有約12,000個附加請求，IMSIMGR處理近9,000個呼叫並拒絕該呼叫。這會導致IMSIMGR CPU處理達到高狀態。

如果SGSN在一秒內收到的連線請求數超過配置的連線請求數，則這些請求將在步調隊列中緩衝，並且僅當緩衝區因較高的入站連線率溢位時才被丟棄。隊列中的消息根據先入先出(FIFO)過程處理，直到當排隊的消息生存期超過配置的等待時間時，消息過期。

當您根據自己的喜好選擇拒絕或丟棄選項時，思科建議您使用拒絕原因代碼來指示網路中的擁塞，這樣您就可以在嘗試上行鏈路過程之前瞭解網路狀況。 

HLR故障

根據第三代合作夥伴計畫(3GPP)技術規範(TS)23.060，本節介紹HLR重新啟動期間SGSN的行為。每當SGSN收到MAP重置時，它預計會向HLR傳送針對其使用者的UL請求。

當HLR重新啟動時，它向註冊了其一個或多個移動站(MS)的每個SGSN傳送重置消息。如果存在SGSN到移動交換中心(MSC)/訪問位置暫存器(VLR)關聯，這會導致SGSN將相關的移動管理上下文標籤為無效。在接收到第一個有效邏輯連結控制(LLC)訊框（用於A/Gb模式）後，或在從標籤的移動站接收到第一個有效GPRS通道通訊協定使用者(GPT-U)封包或上行鏈路訊號訊息（用於Iu模式）後，SGSN會像在連線請求或SGSN間路由區域(RA)更新程式中的那樣執行到HLR的UL。此外，如果設定了非GPRS報警標誌(NGAF)，則遵循非GPRS報警子句中的步驟。UL程式和指向MSC/VLR的程式可能被SGSN延遲，以獲得最大運營商配置，這取決於當時資源的使用，以避免高信令負載。

註：必須定期將HLR資料備份到非易失性儲存器，如TS 23.007 [5]中所述。

行動

思科建議您完成以下步驟以解決此問題：

1. 增加每秒的新連線數。這可基於平均連線請求數計算。
   
   
2. 將STP鏈路中的每秒交易數(TPS)增加到理想值。
   
   
3. 將預設SCTP-RTO-MAX值600(600*100 = 60,000)更改為5（5*100毫秒）。例如，對於兩個具有4,000個TPS的STP，您可以支援每秒最多1,000個來自SGSN的附加請求。

注意：每個連線請求都會產生指向STP的4個事務，這意味著每秒處理1,000個連線請求會產生4,000個TPS。

理想情況下，每個STP有4條鏈路，這樣每個STP鏈路可以處理125個連線請求。這一點在所有STP鏈路中平均分配。但是，如果其中一條鏈路斷開，則會出現多次重新連線嘗試，隊列變滿，並且發生資料包丟棄。如果更多鏈路斷開，則流量分配不均。

流量

UE流量不遵循線性方式。它通常發生在突發事件中，並且會嘗試多次重新連線。SGSN以捆綁包形式將流量傳送到STP。此時，流量量超過STP上配置的TPS。這會導致STP中的某些鏈路開始通告低視窗大小（如果它們已經處理了更多呼叫），並且SGSN開始對排隊的SCTP資料塊進行排隊。然後等待RTO MAX計時器過期。

如果STP定期傳送良好的通告視窗大小，則如果SCTP_RTO_MAX值減少到五秒或更短，您應該能夠傳送更多SCTP資料塊。隊列清除速度更快，並且不會觸發M3UA擁塞警報。此外，您不應該看到SCTP觸發的Internal Flow Control（內部流控制）標誌以便控制資料包流。

SGSN僅傳送STP可以接受的資料包，該數量基於通告的視窗大小。如果增加每個STP鏈路的TPS，將有助於避免STP擁塞，並減少SCTP_RTO_MAX計時器。

SGSN中M3UA擁塞警報的觸發器

如果在流控制傳輸協定(SCTP)選擇性確認(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計時器。