某地市FTP下载速率慢问题分析[2]

1、.某地市 ftp 下载速率慢问题分析故障现象：根据无线部门反映，某地市中兴bsc下 ftp下载速率慢， dt 测试中速率一般为 80 多 kbit/s。原因分析：流程图：某 某 某 ftp某 某 某 某某某 某 某 某 某 某 某 某某某 某 某 某 某 某 某某某 某某1 某某某某某某 某某某 某y某某n某 某某某2 某某某 某某某某某某某 某某y某 某某n某某某 某某某 某某某某某某某 某某y某某n某某 某某某 某某 某某某y某 某某某某某分析判断可能原因：ftp下载速率慢等数传类问题本质上可以归于如下原因：丢包或者数传有延迟，对于这类问题最有效也是最根本的定位方法就是抓包和挂表进行分析，

2、观察;.数据包究竟在哪个网元丢弃或者延迟。原因排查：1、我们选取了 11 月 4 日的抓包进行了分析。其中重点分析从4 日早晨 10点到 11 点的抓包信息， 这些抓包信息有近 80 个跟踪文件，基本上反映了整体的测试情况。在这一段时间的跟踪中， 也出现了 ftp丢包和时延长的现象。 我们对这些现象进行了分析和整理，共统计出 42 次 ftp数传中断时间超过 3s 的情况，这些导致 ftp数传中断的各原因统计如下：1 由于无线侧信号不好（无线侧上报radio-status消息），导致数据无法下发和重传，出现27 次2 手机由于某个特定包没有收到，不断请求（dup ack ），出现 9 次3 c

3、ell update前后数据重传，出现5 次2、下面将分别针对这些原因值，分别选取一个典型跟踪进行分析说明：1 无线测信号不好导致数据无法下发和重传首先看一下 cap 格式的抓包文件 :从抓包上来看，至少在10 ：51 ：37 到 10 ：52 ：28 这一段时间内，;.数据下发肯定是有问题的，这一段时间只有几个重传包和两个ping 包，相隔 50 多秒。再看一下用户跟踪中这段时间出现了什么情况 :在 10 ： 51 ：31 的时候，无线侧上报无线信号不好：radiostatus的消息说明请参考协议48018 （中兴bsc上报的radio-status 消息中原因值为 radio contac

4、t lost with ms 和 radio link quality insufficient to continue communication）：radio status procedurea bss and an ms radio interface communication status may change due to the following:1) the ms goes out of coverage and is lost;this condition is signalled by setting the radio cause value to radio cont

5、act lost with ms.2) the link quality is too bad to continue the communication;this condition is signalled by setting the radio cause value to radio link quality insufficient to continue communication.sgsn 之前已经将消息下下发给bsc ，由于无线信号不好， 这些消息应该没有被正确发送给手机，从上面的抓包可以发现，手机在请求101224的包：;.这个时候由于无线信号不好，手机请求以前的报文，已经

6、导致了有10秒左右的延迟，在10 ：51 ：49 的时候，服务器发送了101224的包：但是从消息跟踪来看，手机似乎没有收到这个包，没有 ack 消息响应，这是为什么？我们再回到用户跟踪，看一下这个时间点发生了什么：;.原来这个时候又发生了小区更新（559行），按无线侧的说法，此时他们没有办法发送给手机，也就是说，服务器发给手机的包又不幸的由于小区更新丢掉了，而且由于中兴bsc 没有缓存重发等功能，只能等待服务器下一次的重传。在 10 ：52 ：27 的时候，这个包终于被下发，手机回了相应的ack 消息，但是时间已经过去了58 秒。这个情况是无线信号不好导致丢包重传的最典型的一个例子。在1 个

7、小时的跟踪中，出现了近30 次的无线信号不好，这将导致大规模的丢包和数据重传，这个问题是导致ftp 下载速率慢的最主要的原因。而其他厂商的bsc ，没有发现如此多的radio-status消息。2 手机由于某个特定包没有收到，不断请求（dup ack ）如图所示，手机在不断请求251032的包，服务器在的 286 行给手机发送了该包，但是手机一直在不断请求。;.直到 305 行，手机确认，此时消耗了3 秒。这种情况的出现一般是由于手机没有收到某个特定包导致的，从消息跟踪来看， sgsn 收到该包后已经将该包下发给了bsc ，请无线侧确认下是;.否收到该包，收到该包后是否迅速下发给了手机。这种情

8、况一般导致延迟在3-5s 左右，对速率有一定的影响。3 cell update前后数据重传如上图， 231 和 232 之间相隔了 8s 。这种情况的出现是由于此时发生了小区切换，在小区切换时，无线侧无法下发数据给手机，只能等待服务器重传。手机在10 ：38 ：26 请求 55884的数据包，这个包实际上在216行（ 10 ：38 ：23 ）已经下发过了，但是由于小区切换的原因，手机没有收到该报文。服务器在10 ： 38 ：34 将该数据包重传，期间间隔了8s 。;.3、ftp 下载速率慢的问题，主要有如上三个问题。在这三个问题中，尤其以无线信号不好和小区切换可能导致较高的时延。由于小区切换时

9、无线侧必然会导致丢包，这个是每个厂商的bsc 都会出现的。因此该地市与其他地区相比指标较差的根本原因还是在第一点所述， 无线信号不好导致丢包和重传， 在统计中，这种无线信号不好最差的情况导致数据有60 秒都无法下发，平均也有 15s 左右。因此需要无线侧彻底排查下网络情况，找到为什么会有如此多的radio-status 消息。4、为进一步排查问题，选择了石家庄华为 bsc（下文简称为华为 bsc）下进行了 dt 测试，希望通过比较华为 bsc 和中兴 bsc 下的数据传输特点，尽快解决问题地市中兴 bsc 下 ftp 速率慢问题。测试时间有 1 个多小时，这一段时间的平均速率为 120kbit

10、/s，大大优于问题地区的指标。 通过比较跟踪的 1 个多小时内的 58 个消息跟踪。我们发现在华为 bsc 下小区切换时丢包重传要明显比中兴 bsc 下小区切换要少， 同时在华为 bsc 下没有看到一个 radio-status 消息。具体的数据统计如下：在这些跟踪中，数传时小区切换 44 次。44 次小区切换中， 中断时间（包括重传数据包的时间）绝大部分都是在 3s 之内，其中 15 次切换没有中断（没有服务器重传），21 次在重传时间在 3s 之内，剩下的 8 次中，只有三次切换消耗超过了 5s ，分别是 8s,17s,21s 。;.与中兴 bsc 相比，华为 bsc 在小区切换时明显耗时

11、更少，那么我们仔细分析一下产生这种现象的原因：选取 10:20:27的跟踪为例，在此时发生了小区更新：看一 下此时的 cap包， 此时 出现了 手机 在重复请求一 个包 （第98,99,100,102,103,106,107,108），该包的序号为： 66428 ，说明该包在小区更新后手机没有收到。;.在第 101 和 105 行，服务器重传了这两个包， 其中 sequence number都是 66428 ：;.而关注下第 109 行，此时手机确认的数据包为79000 ，这意味着序号在 67888 79000 之间的数据包手机已经收到了，且此时服务器并没有重传 67888 79000 的数据

12、包。;.因此通过这个跟踪可以看出，此次小区切换时，丢了66428的包，但是大部份的其他数据包（ 67888 79000 ）仍然能够在小区切换时下发。也就是说小区切换时仅仅丢弃了少部分的包或者根本不丢包（44 次小区切换中有15 次时没有任何丢包），这样服务器只需要重传很少的包就可以了，对小区切换时的速率有很大的提高。这个跟踪说明华为bsc 做了非常好的优化机制，在小区切换时能够主动缓存和重发小区切换时的数据包。解决措施：需要无线设备厂家通过软件补丁或者参数修改问题行解决缺陷。经验总结：1 在分析数传问题时需要从整体上进行分析，而小区切换时的丢包占了整体丢包的 80以上。因此小区切换时丢包是 f

13、tp下载速率慢的根本原因。目前中兴 bsc的机制是小区切换时丢弃的 所有包都必须依靠服务器重传进行发送，而服务器重传需要消耗较多的时间， 因此在 dt 测试时中兴 bsc 下的速率一直很低。 华为 bsc则对此做了优化机制， 大幅度提高了 ftp下;.载速率。中兴 bsc如果想解决 ftp下载速率慢的问题， 必须优化其实现机制，减少小区切换时的丢包。2 中兴 bsc在小区切换时会上报大量的 radio-status消息，据中兴工程师解释，这个和小区切换有关。对于这种 radio-status消息， sgsn会根据协议将其挂起，直到等到收到上行的 llc 帧才会将状态恢复。而根据 sgsn与其他 bsc对接经验，没有发现其他厂商的 bsc会在小区切换时上报大量radio-status消息（如 7日的跟踪中，华为 bsc没有上报一条 radio-status消息）。3 在没有小区切换时， bsc仍然有几次 radio-status 消息，与中兴工程师确认，这个是无线网络不好导致。4 无线侧上报的流控消息中，每个手机的缓存大小（协议 48018中定义的bmax）达到了 40mbit ，这个明显是不合理的数值， 这将直接导致协议 48018 中的流控算法没有效果。5 中兴 bsc提到在跟踪中发现手机收到不连续的 llc