4G网络中GTPC路径断告警问题分析及定位

饶轲

【摘 要】由于4G网络规模部署的不断增加，本文从设备出现大量GTPC告警入手，分析故障现象和信令流程，正对性的开展实验，最终确定由于某些ENODEB数据配置不全引发了核心网设备侧GTPC路径断告警以及切换流程的失败。

【关键词】ENODEB；TAU；GPTC路径中断

中图分类号： TN929.53 文献标识码： A 文章编号： 2095-2457（2018）30-0034-002

DOI：10.19694/j.cnki.issn2095-2457.2018.30.013

1 问题现象

近期，SGSN设备出现大量”GTPC路径断”告警，告警峰值在24H内会出现接近1000次，而且告警设备的地址几乎都为本省的SGSN GTPC地址，涉及范围为每套SGSN。

2 问题影响

本省SGSN间的GTPC路径断，具体影响用户发生RAU、TAU切换时业务会被终端，需要UE重新发起附着方可继续使用业务（概率性问题，后面有详细分析），对于没有发生切换，或者在intra内进行RAU、TAU业务的用户也不受影响。

3 问题分析

3.1 引起“GTPC路径断”的原因有两种：

1）SGSN间或者SGSN GGSN间互相发送gtp echo 交互消息，达到一定时间、一定次数后，SGSN上报“gtpc 路径断”；（T3N3定时器设置为6s，3次）

2）用户行为（包括PDP激活、RAU、TAU、QOS更新等）涉及到SGSN与GGSN间进行gtpc或者gptu交付的情况，一旦一条GTP消息没有得到对端网元的正确响应，同样将会上报“gtpc 路径断”；

3.1.1 针对第一种情况：

选取两套告警频繁的SGSN进行所有Gn接口镜像抓包：对CE1和CE2相同时间段的数据包进行echo包统计发现：SGSN1和SGSN2之间的gtp echo消息都可以一对一对应。再看设备间业务地址的ping包，也是没有丢包的。针对第一种可能产生告警的情况，对于承载网丢包的问题可以排除。

3.1.2 针对第二种情况：

返回CE1和CE2抓的镜像包结合设备告警进行分析。看到告警定位信息中接口基本都为S10，所以重点分析了GTP V2的报文，可以从抓包中看到有相当一部分relocationg request请求包是没有得到响应的。relocationg request是终端在MME间发起Handover流程时，源MME向目的MME发送的请求消息，由于源MME迟迟没有得到响应（10s），而源MME按照自己的T3N3定时器重发Forward Relocation Request消息和上报告警，最后导致流程失败。至此，初步判断这个问题并不是丢包引起的GTPC路径故障告警，而是流程失败引起的。

SGSN1的两个告警：

1）告警发生时间/告警恢复时间：2014-09-15 11：54：51+08：00/2014-09-15 11：55：07+08：00.

定位信息：本端IP=11x.xx.xx.12，对端IP=22x.xx.xx.113，路径接口类型=GTP path EPC，框号=1，槽位号=13，进程类型=PCP，同类进程序号=0，PLMN网元间的接口=S10；

2）告警发生时间/告警恢复时间：2014-09-15 11：55：51+08：00/2014-09-15 11：56：01+08：00.

定位信息：本端IP=11x.xx.xx.5，对端IP=22x.xx.xx.115，路径接口类型=GTP path EPC，框号=0，槽位号=13，进程类型=PCP，同类进程序号=0，PLMN网元间的接口=S10；

SGSN2的一个告警：

告警发生时间/告警恢复时间：2014-09-15 11：54：56+08：00/2014-09-15 11：55：37+08：00.

定位信息：本端IP=11x.xx.xx.121，对端IP=22x.xx.xx.1，路径接口类型=GTP path EPC，框号=1，槽位号=11，进程类型=PCP，同类进程序号=0，PLMN网元间的接口=S10；

针对上述三个告警，可以看到设备上响应时间段确认有三个对应的gtpc路径断告警。

注：上述的relocationg消息中涉及到的enodeb id都没有在SGSN1和SGSN2下挂。

3.1.3 根据上面的分析，结合信令分析流程，现场做了两次实验：

涉及到的TAC为：

8901（0x550F）：这个TAC对应的是一个连接了所有SGSN的Enodeb

8902（0x550F）：这个TAC对应的是只连接了SGSN3的enodeb（也就是SGSN1和SGSN2没有该enodeb的S1连接）

第一次测试：用户在8901下面进行激活，同时激活在SGSN3上，由8901->8902进行TAU测试，用户测试正常；

第二次测试：用户在8901下面进行激活，同时激活在SGSN1上，由8901->8902进行TAU测试，用户业务中断，看到的现象为：在源MME向目标MME发送relocation req后，等待10s，没有收到response消息，之后又重新发起hand over流程，与此同时SGSN上有对应SGSN1和SGN5之间的gtpc断链告警。

4 问题根因：

SGSN间大量的“S10”类型的“gtpc路徑断”告警，是由于某些Enodeb只直接入了某台SGSN，当某用户从该Enodeb接入使用4G业务并且发生TAU切换时，关于此Enodeb对应的TAC区域MME可以在DNS上解析到所有SGSN的GTPC地址，所以如果此时刚好DNS返回的地址不是enodeb原先挂接的SGSN，而是另外一套SGSN（没有挂接该Enodeb），此时由于目标SGSN没有到该enodeb的链接，向目标Enodeb发送不了hand over消息，导致源MME接收不到目标MME的relocationg response，导致流程失败，从而产生”GTPC路径断”告警。这里，向读者完整阐述下这类切换的具体流程：

MME和S-GW均改变的E-UTRAN内部TAU详细流程如下：

1、条件满足，触发TAU流程。

2、UE通过向eNodeB发送Tracking Area Update Request消息以及指示了Selected Network和old GUMMEI的RRC參数来发起一个TAU流程。

3、eNodeB通过GUMMEI（Globally Unique MME Identifier）和Selected Network找到MME，并向MME转发Tracking Area Update Request消息。

4、new MME通过GUTI获得old MME地址，并向old MME发送Context Request消息重新获取用户信息， old MME会启动一个定时器。

5、old MME向new MME返回Context Response消息。

6、new MME决定是否重新选择S-GW。new MME向old MME发送Context Acknowledge消息，消息包含：Serving GW change indication，指示已选择的new S-GW。

7、new MME继续维护从old MME收到的UE的EPS承载上下文。MME会验证来自UE的EPS承载状态，并释放非活动态EPS承载关联的网络资源。如果没有承载上下文，MME将拒绝TAU请求。

8、new S-GW向所在PDN连接的P-GW发送Modify Bearer Request消息告知其承载信息变更。

9、P-GW更新承载上下文，并向new S-GW返回Modify Bearer Response消息。

10、new S-GW更新承载上下文，并向MME返回Create Session Response消息。

11、new MME首先查看本地是否保存了UE的签约数据，使用GUTI、additional GUTI或IMSI进行标识。

12、HSS向old MME发送Cancel Location消息，消息包含：IMSI、Cancellation type，Cancellation type设置为Update Procedure。

13、如果4中的定时器已超时，old MME删除移动性管理上下文；否则，待定时器超时后再删除上下文。

14、HSS向new MME响应Update Location Ack消息。

15、当4中的定时器超时，old MME释放本地承载资源，并向old S-GW发送Delete Session Request消息告知其释放EPS承载资源。

16、old S-GW向old MME返回Delete Session Response消息并丢弃所有为UE缓存的数据包，消息包含：Cause。

17、MME向UE响应Tracking Area Update Accept消息，如果MME重新分配了GUTI，也随此消息下发给UE。

5 问题处理进展：

1）经核查无线侧有450个左右enodeb只对接了SGSN3，已经协调无线厂家人员（中兴约为200个基站，华为约为150个，贝尔约为100个）配全到所有SGSN的S1链路。

2）告警情况：

SGSN1在昨天以后就基本没有出现GTPC的闪断告警了；SGSN2和SGSN3闪断次数也明显降低，剩下的告警和某些基站断链有关。

3）业务情况

联系测试人员返回昨日测试地点进行TAU测试，反馈业务成功，问题解决。

6 经验教训及推广：

对于后续无线Enodeb对接MME要求：要求所有Enodeb后续对接MME，必须配置到所有MME的全IP互联链路。