由于HLR MAP_RESET，SGSN中的STP拥塞、IMSIMGR Over State和SCTP链路抖动

简介

本文档介绍在Cisco 5000系列聚合服务路由器(ASR)的服务通用分组无线业务(GPRS)支持节点(SGSN)上遇到的问题。 此外，还描述了解决此问题的一些可能的解决方法。

背景信息

本文档介绍ASR SGSN上的此特定事件链：

1. 11月21日，上午6:25:MAP_RESET由归属位置寄存器(HLR)发送。
   
   
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:00 € “ 10:30:统计从上午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: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)过程进行处理，直到排队的消息生存期超过所配置的等待时间时其过期。

当您根据您的偏好选择拒绝或丢弃选项时，思科建议您使用拒绝原因代码来指示网络拥塞，这样您就可以在尝试上行链路过程之前了解网络状况。 

HLR故障

根据第3代合作伙伴项目(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执行UL到HLR，如连接请求或SGSN间请求中所述路由区域(RA)更新过程。此外，如果设置了非GPRS警报标志(NGAF)，则遵循非GPRS警报子句中的步骤。SGSN可延迟UL过程和向MSC/VLR的过程以实现最大操作员配置，这取决于当时资源的使用，以避免高信令负载。

注意：HLR数据必须定期备份到非易失性存储，如TS 23.007 [5]中所述。

建议

思科建议您完成以下步骤以解决此问题：

1. 增加每秒新连接数。这可以根据配售请求的平均数量计算。
   
   
2. 将STP链路中的每秒事务数(TPS)增加到理想值。
   
   
3. 将默认SCTP-RTO-MAX值600(600*100 = 60,000)更改为5（5*100毫秒）。 例如，对于两个STP(4,000 TPS)，您每秒最多可从SGSN支持1,000个连接请求。

注意：每个连接请求都会产生四个指向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触发的内部流控制标志以控制数据包流。

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计时器。

修订历史记录