目录

简介

背景信息

问题

解决方案

STP链路接收的流量过多

IMSIMGR处于警告状态

HLR故障

建议

流量传输

SGSN中M3UA拥塞警报的触发器

简介

本文档介绍在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计时器。