由于HLR MAP_RESET导致SGSN中的STP拥塞、IMSIMGR状态转换和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：在SGSN上为STP的SLC-1发出拥塞警报。
    
    
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

处于警告状态的IMSIMGR

每个新的呼叫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)流程进行处理，直到队列中的消息寿命超过配置的等待时间时消息过期。

当您根据自己的偏好选择拒绝或丢弃选项时，Cisco建议您使用拒绝原因代码来表示网络拥塞，这允许您在尝试上行链路过程之前了解网络条件。 

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的四个事务，这意味着每秒处理1,000个连接请求会产生4,000个TPS。

理想情况下，每个STP都有四个链路，这样每个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计时器。