上海网络HSDPA业务无速率问题分析报告

（2）6月14日4:00~18:00，在桂平路王安宾馆室内保持一个业务（RNC390下的室外小区信号）,中间没有出现速率为0后不能恢复的问题，但发生过多次网页打不开（同时FTP连接失败）的情况,在1~2分钟后都能恢复正常。

出现如上问题时,仍是DNS域名解析请求和FTP连接请求消息在终端侧看不到响应消息.，因此对核心网问题解决的效果需要持续观察

（3）6月13日在室内保持验证过程中，还发现如下几个其他问题，也建议持续关注：

业务保持1h左右时,可以正常打开网页,但连接FTP服务器失败,多次重新连接均失败,从终端侧wireshark抓包看是终端发出的FTP连接请求TCP消息没有收到响应.但2min后FTP连接突然恢复正常.此现象的原因未知

曾发现中兴数据卡MU350在业务保持过程中切换到2G网络但未弹出提示窗口，此时PS业务会释放，因此用户投诉也有可能因为网络覆盖不足而切换至2G网络导致

（4）前期验证过程中，曾数次出现中兴MU350数据卡HSDPA业务保持过程中，突然发生上行无线链路失败导致速率降为0，重新拨号，或拔出终端重新连接PC并拨号后，网页和FTP仍然连接不上；只有重起PC，再连接终端和拨号，业务才能恢复正常。这个现象在后期的定位过程中没有复现，目前初步分析主要与终端有关。

（5）从6月4日联芯在顾戴路测试的Log可以看出，切换到2G网络时，CN去激活了PDP但没有释放RAB，此后终端再次切回TD网络并再次请求激活PDP，CN下发的RAB指派消息中，RAB ID与之前未释放的RAB相同，参数中除了GTP-TEI与之前不同外，其余参数不变，RNC对此指派消息返回失败，原因为“非法的参数值”，导致终端重新发起的多次PDP激活请求均失败，业务无法恢复。经过和ASB讨论，认为CN的处理有问题，不应该出现只释放PDP上下文而不释放RAB的异常情况。ASB表示要进一步分析，此问题需要继续关注。对于RNC来说，虽然CN的处理过程不正常，但这条RAB指派消息并不违反协议，RNC是可以返回成功，从而规避这种异常情况的，此问题需要RNC研发后续改进。

此问题主要是通过析wireshark抓包数据，并结合网元的跟踪信息进行定位的，wireshark抓包的分析方法可参考西安研发部梁剑之前提供的《网页刷新慢及下载速率低问题业务面定位方法总结》。在这里针对本次问题，对wireshark抓包数据的分析方法再做一点简单的补充：

用wireshark抓包的界面如下图所示（以打开网页的正常过程为例，图中终端PDP激活后分配的IP为192.168.1.111，服务器的IP为
218.206.176.4）：

首先终端侧回向服务器发送欲打开网址的域名申请解析，服务器解析域名并返回若干个主机地址；此后浏览器一般会向其中第一个主机地址发起TCP请求消息，并交互3次，TCP消息中的标志位分别为[SYN]，[SYN,ACK]和[ACK]，这个过程即常说的TCP三次握手。此后终端侧发HTTP协议消息（GET）表示获取到主机地址，此后就是通过TCP协议数据包下载网页内容，即图中的[TCP Segment of a reassembled PDU]数据包。

同样的，如果是连接FTP服务器，可以看到封装FTP连接请求和响应消息的TCP数据包，其中可以看到请求连接的FTP服务器地址，用户名和密码等信息；如果是对某个地址进行ping操作，可以看到ICMP协议数据包（ping包）。

通过各检测位置（比如终端侧、CN内各接口）检查以上过程的完整性，可以初步判断是否某个环节存在传输丢包问题。

本次问题是由联芯投诉引发的，开始几天处理时，因联芯人员没有提供详细的问题描述，定位一直没有找到准确的方向，在后续去联芯公司定位，以及联芯测试人员来公司定位的过程中，通过进一步交流，才了解了联芯反馈问题的详细信息。后续对此类问题的处理，开始时多花一些时间了解问题的详情是很有必要的。

对于某一时间突然发生的，全网普遍出现的问题，一般都和网络汇聚节点的网元如RNC、CN、业务平台等有关。现在此类网络问题一般会从RNC日常操作和升版的影响性开始定位，但我们和ASB的沟通尚不够畅通，核心网是否进行过什么操作或版本升级我们一般无法得知，也无法就已解决的核心网问题形成有效的案例总结，也建议后续进一步增强和ASB的信息沟通，比如核心网进行某项操作或修改前，能将此活动的影响性事先知会我们。