某移动TD-SCDMA网络ATU测试FTP掉线问题分析

admin

本文摘自《电信工程技术与标准化》2013年2期。作者：赵冲 作者单位：中国移动通信集团河北有限公司邢台分公司

2012 年8月省公司例行ATU 数据业务测试中，某地发现多次FTP 掉线的异常事件，从软件统计的掉线时间点来看，正常下载一段时间后无数传导致3 min 无速率，其中有35 次完全在TD-SCDMA，3次在GSM。

1 问题分析

下载无速率导致平台统计为掉线，同时影响整体下载速率。现场针对问题发生的无线环境以及涉及无线参数进行验证未能定位问题环节，启动全流程问题处理。

1.1 网络组网情况分析

某地 TD-SCDMA网络 PS域组网由现网Node B、RNC、CE GGSN、华为交换机 S9306、防火墙 Eudemon1000E以及 CMNET等设备组成。如图 1所示。

网络接口包括 IUB、 IU-PS、 Gn、Gi、 Ga、 O&M、 Gn+Gi、 Gn+Ga、 Gn+Gi+Ga。

1.2 处理流程

成立联合处理小组：成员为各网元负责人：地市公司网优中心、省公司网优中心 /SGSN维护、华为公司研发二线支持、数通维护，进行问题逐段分析，查找不同点。复现信令跟踪以及抓分组工作，定位问题发生环节。

PS数据业务属于端到端的业务， PS业务经过的网元实体较多，组网结构复杂。中间任一环节出现异常或者在传输过程中出现错分组、丢分组等，均有可能导致数据的速率下降。

1.2.1 覆盖分析

问题发生区域不固定，全网均存在鼎利 ATU设备测试统计掉线。通过对掉线问题发生区域分析，覆盖良好。

典型问题中终端测试覆盖良好， PCCPCH电平-65 dBm， H业务功率也正常， C/I良好。

同时进行 CQT测试问题同样复现，问题原因应与无线环境无关。

1.2.2 终端分析

发生问题终端：鼎利 ATU测试终端、华星 ATU测试终端。

测试正常终端：联芯 8142测试终端。

从终端表现分析，只要终端发起 PDP去激活再激活后测试正常，因此联芯 8142测试结果正常（每次业务完成均进行 PDP去激活激活），商用终端未发现异常。

1.2.3 操作核查

近期调整参数不影响测试结果，使用鼎利 ATU测试设备测试均存在掉线问题。

1.2.4 告警分析

无全网影响 PS业务告警。

1.2.5 IU-PS接口分析

在 RNC、SGSN以及 GGSN进行信令跟踪并转换用户面报文分析，经各环节联合定位，发现出现问题点：GGSN、 SGSN和RNC上抓到的数据报文分析，对于FTP服务器发送的某一个特定的报文GGSN上可以抓到 (包括它的重传报文 )，但 SGSN和 RNC上则看不到该报文 (包括重传报文 )，因此初步判断丢分组是在GGSN以下特别是GGSN到SGSN的Gn接口。

在 RNC侧 CE进行抓分组工作和 RNC-CDT跟踪消息转换报文，结果与 SGSN侧信令转换报文结果基本一致。

问题发生环节应在 RNC以上。

1.2.6 Gn+Gi+Ga接口分析

通过跟踪消息转换报文、 RNC侧 CE抓分组工作分析以及防火墙等分析，深入定位需要重点在 Gn接口涉及数通设备抓分组。

S9306业务交换机分别到 GGSN04和 GGSN05的Gn接口各一个，共两个端口；到 SGSN10的 Gn接口共 3个端口。这两组端口需要分别镜像到两个不同端口进行抓分组。可以在开始测试后通过用户跟踪确定 GTP隧道两端地址，再根据地址设置过滤条件减少抓到报文的数量便于分析。 SGSN侧 CE路由器到 SGSN11的Iu-u共 3个端口镜像到一个端口进行抓分组。也可以在开始测试后通过用户跟踪确定 GTP隧道两端地址，再根据地址设置过滤条件减少抓到报文的数量便于分析。共需要 2个抓分组点，如果所有主用端口在同一台设备则只需要一个抓分组点。 9306业务交换机为抓分组重点。

抓分组后分析结果如下：针对 9月 4日下午的一次问题重现时间段进行分析，用户信令跟踪转换成数据报文发现，终端一直在发确认消息，希望收到实际序号为04524973（相对序号为 2549177）的报文，而 SGSN的用户跟踪显示一直没有收到该序号的报文。

通过在分析 S9306交换机 Gn接口的抓分组发现，该序号的报文是分片报文，但是首片和尾片都发给了SGSN，检查 SGSN的错分组统计没有异常，但是从日志看到了数据分组的重组超时信息，而现场 FTP的测试数据分组由于超过 S9306设置 MTU1500的限制而产生了分片。通过分析用户信令跟踪发现，该用户在Gn接口的路径是 V0版本，而 GTPV0的数据分组是根据 GTP头的 IMSI通过 hash算法定位 PDP上下文的，如果根据 IMSI计算的 hash没有冲突，就不需要访问hash冲突的链表，也即不会触发问题；当存在 hash冲突时，就需要访问 hash冲突链表，目前的 SPH322版本在定位 hash冲突链表时存在代码缺陷，会导致查找不到 PDP上下文，查找不到 PDP上下文， SGSN就会丢弃该数据分组。

关于 SGSN和 GGSN GTP路径版本协商机制：在开机接入网络或 SGSN复位 EPU进程组等情况下，会首先协商 V1版本路径，当由于网络或其它原因导致协商失败时会降版本协商 V0版本，此后只要协商出的 GTP路径存在激活的 PDP该路径就保持存在，而新 PDP激活时会随机选择已存在的路径承载。现网做EPU进程组双复位等操作时，导致 OSPF进程中断，由于 OSPF进程重启后学习路由会消耗一段时间，根据上面的原理可能导致 GTPV1路径协商失败，而协商出较多的V0的路径。

2 问题处理

由 SGSN研发人员给出结论。

最终结论： SGSN重组分片报文失败的原因如下：版本缺陷导致 GTPV0数据分组根据 IMSI生成的 hash键值冲突； Gn接口协商的为 GTP V0路径。

解决措施：由于 GTPU V0板的路径无法直接删除，建议设置 BYTE 95号软参为 1（软参开启后只使用 V1版本建立路径，不再使用 V0版本创建路径）；然后复位所有的 GTP进程，即可规避问题，命令如下： SET SOFTPARA: DT=BYTE, PARANUM=95, VALUE="1"; RST PROCESSGRP: RSTTYPE= PROCTYPE, PROCTYPE=GTP, RS=ALL;保定清苑局点虽然采用的二层组网，但也协商了少部分GTPV0隧道，建议与其它局点一并实施。 GTPV0的数据分组定位上下文错误的问题，将在 V9R10C2SPH346版本中解决。（当前版本： V900R010C02SPC300）

3 问题验证

2012年 9月 11日使用相同鼎利测试设备在当地进行复测验证，结果如表 1所示。完成参数调整后测试统计无掉线事件发生， DT测试速率正常。

4 问题处理经验总结

通过对某地 TD-SCDMA网络的 ATU设备掉线问题的分析以及推动处理过程中对 PS端到端问题分析处理进行经验汇总。本次问题最大难点是中间涉及网元太多，造成分析处理难度大，无法做到向单网元问题处理时现场和二线即能完成分析处理，需要把多个网元的问题分析串联到一起。

PS端到端问题分析处理流程：优先成立问题处理小组，明确各网元问题分析责任人，对各自网元情况进行分析，以及对整体流程中消息跟踪 /抓分组等关键动作进行协同处理。问题处理小组主要分为无线（ RNC/网优 /研发等）、 SGSN/GGSN、数通、问题推动实施（维护项目经理 /地市接口 /省公司网优 /SGSN等）。

熟悉 PS组网以及各环节网元处理， PS业务为终端和应用服务之间交互，业务流经 Node B/RNC/SGSN/GGSN/防火墙 /CMNET/外网等主要环节处理，任一节点出现问题均有可能对终端用户造成影响。问题分析中可以按照业务流程进行消息跟踪和抓分组分析，进行逐段排查。联合抓分组配合流程中最重要的环节为数通环节，需要提前准备高性能电脑（避免海量数据处理无法完整保存消息）和对应的端口镜像方案，需要数通工程师大力配合。