STP拥塞，在状态和SCTP林克飘荡的IMSIMGR在SGSN由于HLR MAP_RESET

简介

本文描述在服务通用分组无线业务(GPRS)支持节点的问题(SGSN)遇到Cisco 5000系列聚集的服务路由器(ASR)。此问题的一些可能的应急方案也描述。

背景信息

此特定事件链在ASR SGSN的在本文描述：

1. 十一月第21，上午6:25 ：MAP_RESET由位置记录器(HLR)发送。
   
   
2. 十一月第21，上午8:13 ：拥塞报警为信号转发点2 (STP-2)发出。
   
   
3. 十一月第21，上午8:23 ：拥塞报警为STP-1和STP-2发出。
   
   
4. 十一月第21，上午8:48 ：国际移动用户标识管理器(IMSIMGR)搬入警告状态。
   
   
5. 十一月第21，上午10:07 ：链路从往SGSN的STP-2重置。
   
   
6. 十一月第21，上午10:15 ：改进在SGSN位置更新(LU) stats被观察。
   
   
7. 十一月第21， 10:00 ？上午10:30 ：统计信息开始改善在上午10:00。
   
   
8. 十一月第21，上午11:15 ：拒绝在SGSN LU stats被观察。
   
   
9. 十一月第21，上午11:41 ：STP团队报告信令链接编码(STP-2 SLC)-1不收到流量， SLC重置和流量回归到正常。
   
   
10. 十一月第21，上午11:42 ：拥塞报警在STP的SLC-1的SGSN发出。
    
    
11. 十一月第21，下午12:00 ：在SLC-3重置后， GPRS LU stats改善。

问题

当HLR收到MAP_RESET消息时，设置GPRS位置更新的(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

 
如示例输出所显示，有950,000装箱员数据协议(PDP)上下文在SGSN和UEs尝试通过他们浏览作为天进度。

当第一上行链路数据包接收时， SGSN触发GLU消息。因为有数十万UEs， 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负载，它在所有四条链路必须发送相等消息传输部分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

IMSIMGR警告状态

必须由IMSIMGR处理其中每一新的呼叫IMSI/Packet临时移动用户标识(P-TMSI)附上和路由区域更新(RAU)请求。

使用一保守的观察，系统收到峰值6,850 2-G附上请求每秒和大约5,313 3-G附上请求每秒。您能为网络超载保护设置的最大值是5,000附上请求每秒。为了在一可行的状态保留IMSIMGR，系统不能处理从UEs的这样很大数量的呼叫。

此问题开始，在上午8点后，当队列大小到达1,500附上请求每秒时：

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在第二内比附上请求配置的号码接收更多，则请求在定步队列缓冲和只丢弃，当缓冲区溢出由于高入站附上对估计时。当排队的消息寿命交叉已配置的等待时间时，在队列的消息处理符合直到他们的先入先出(FIFO)进程超龄。

当您选择拒绝或下降根据您的首选时的选项，思科建议您使用拒绝原因代码为了指示在网络的拥塞，允许您了解网络状况，在您尝试一个上行链路步骤前。 

HLR失败

根据第3个生成合伙企业项目(3GPP)技术规范(TS)在HLR重新启动期间， 23.060，此部分描述SGSN行为。每当SGSN接收MAP重置，预计发送往HLR的一UL请求其用户的。

当HLR重新启动，它传送重置信息对每个SGSN对哪个或更多其移动站点(MS)注册。这造成SGSN指示相关移动管理上下文如无效，如果SGSN对莫比尔转换中心(MSC) /Visiting位置寄存器(VLR)关联存在。在第一有效逻辑链路控制(LLC)帧的收据后(A/Gb模式)或，在第一个有效GPRS隧道协议用户(GPT-U)后数据包或上行链路信令消息的收据(Iu模式)从一个明显移动站点， SGSN执行UL对HLR正如在附上请求或相互的SGSN路由的区域(RA)更新步骤。并且，如果非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的四处理，因此意味着1,000附上请求每秒导致4,000 TPS。

理论上来讲，每个STP有四条链路，以便125附上请求可以每条STP链路处理。这在所有STP链路间均等地被分配。然而，如果其中一条链路断开，许多重新连接尝试被看到，队列变得全双工，并且信息包丢弃出现。如果更多链路断开，则参差不齐分配流量。

通信流

UE流量不跟随一个线性方式。它通常发生在突发流量和在许多重新连接尝试。SGSN发送在套件的流量对STP。那时，流量总数超出在STP的已配置的TPS。这的STP导致一些链路开始通告低窗口大小，如果他们已经处理更多呼叫，并且SGSN开始排队排队的SCTP数据大块。它然后等待RTO最大值计时器超时。

如果STP周期地发送好通告的窗口大小，则您应该能发送更多SCTP数据大块，如果SCTP_RTO_MAX值到五秒或降低。队列被清除的更加快速，并且M3UA拥塞报警没有被触发。另外，您不应该看到SCTP触发的内部流动控制标志为了控制数据包流。

SGSN只发送在STP能接受，根据通告的窗口大小的数量的数据包。如果增加TPS每条STP链路，帮助避免STP拥塞并且降低SCTP_RTO_MAX计时器。

M3UA拥塞报警的触发在SGSN

如果在流控制传输协议(SCTP)选择性应答(SACK)消息的通告的窗口大小是接近零(或零)，则SGSN发出M3UA报警为了表明不应该为该对等体终端传送信息。这导致链路摆动或搬入拥塞的状态。因为SGSN发送更高的窗口大小，您继续接收从对等体节点的M3UA数据，并且那些数据包也许丢弃到等待的队列，如果对等体点代码从未从拥塞的状态出来。

示例如下：

1. SCTP发送流量控制启动征兆对M3UA。
   
   
2. M3UA设置关联的拥塞活动标志并且开始周期地轮询SCTP关于其流量控制状态。
   
   
3. 当关联在流量控制中时，排队该关联的将来数据请求，直到QUEUE_SIZE到达了8,000。那时，关联的将来消息丢弃。
   
   
4. 如果STP发送适当的通告的窗口大小，则M3UA尝试倒空排队的消息，直到到达5,000。RTO计时器在此也扮演一个角色。

SCTP消息为流量控制标志变得真的那些关联仅排队和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计时器。