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

.某地市FTP下载速率慢问题分析故障现象：根据无线部门反映，某地市中兴BSC下FTP下载速率慢，DT测试中速率一般为80多kbit/s。原因分析：流程图：分析判断可能原因：FTP下载速率慢等数传类问题本质上可以归于如下原因：丢包或者数传有延迟，对于这类问题最有效也是最根本的定位方法就是抓包和挂表进行分析，观察数据包究竟在哪个网元丢弃或者延迟。原因排查：1、我们选取了11月4日的抓包进行了分析。其中重点分析从4日早晨10点到11点的抓包信息，这些抓包信息有近80个跟踪文件，基本上反映了整体的测试情况。在这一段时间的跟踪中，也出现了FTP丢包和时延长的现象。我们对这些现象进行了分析和整理，共统计出42次FTP数传中断时间超过3s的情况，这些导致FTP数传中断的各原因统计如下：1 由于无线侧信号不好（无线侧上报radio-status消息），导致数据无法下发和重传，出现27次2 手机由于某个特定包没有收到，不断请求（DUP ACK），出现9次3 CELL UPDATE前后数据重传，出现5次2、下面将分别针对这些原因值，分别选取一个典型跟踪进行分析说明：1 无线测信号不好导致数据无法下发和重传首先看一下cap格式的抓包文件:从抓包上来看，至少在10：51：37到10：52：28这一段时间内，数据下发肯定是有问题的，这一段时间只有几个重传包和两个PING包，相隔50多秒。再看一下用户跟踪中这段时间出现了什么情况:在10：51：31的时候，无线侧上报无线信号不好：Radio status的消息说明请参考协议48018（中兴BSC上报的radio-status消息中原因值为Radio contact 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 contact 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的包：这个时候由于无线信号不好，手机请求以前的报文，已经导致了有10秒左右的延迟，在10：51：49的时候，服务器发送了101224的包：但是从消息跟踪来看，手机似乎没有收到这个包，没有ack消息响应，这是为什么？我们再回到用户跟踪，看一下这个时间点发生了什么：原来这个时候又发生了小区更新（559行），按无线侧的说法，此时他们没有办法发送给手机，也就是说，服务器发给手机的包又不幸的由于小区更新丢掉了，而且由于中兴BSC没有缓存重发等功能，只能等待服务器下一次的重传。在10：52：27的时候，这个包终于被下发，手机回了相应的ack消息，但是时间已经过去了58秒。这个情况是无线信号不好导致丢包重传的最典型的一个例子。在1个小时的跟踪中，出现了近30次的无线信号不好，这将导致大规模的丢包和数据重传，这个问题是导致FTP下载速率慢的最主要的原因。而其他厂商的BSC，没有发现如此多的radio-status消息。2 手机由于某个特定包没有收到，不断请求（DUP ACK）如图所示，手机在不断请求251032的包，服务器在的286行给手机发送了该包，但是手机一直在不断请求。 直到305行，手机确认，此时消耗了3秒。这种情况的出现一般是由于手机没有收到某个特定包导致的，从消息跟踪来看，SGSN收到该包后已经将该包下发给了BSC，请无线侧确认下是否收到该包，收到该包后是否迅速下发给了手机。这种情况一般导致延迟在3-5s左右，对速率有一定的影响。3 CELL UPDATE前后数据重传如上图，231和232之间相隔了8s。这种情况的出现是由于此时发生了小区切换，在小区切换时，无线侧无法下发数据给手机，只能等待服务器重传。手机在10：38：26请求55884的数据包，这个包实际上在216行（10：38：23）已经下发过了，但是由于小区切换的原因，手机没有收到该报文。服务器在10：38：34将该数据包重传，期间间隔了8s。3、FTP下载速率慢的问题，主要有如上三个问题。在这三个问题中，尤其以无线信号不好和小区切换可能导致较高的时延。由于小区切换时无线侧必然会导致丢包，这个是每个厂商的BSC都会出现的。因此该地市与其他地区相比指标较差的根本原因还是在第一点所述，无线信号不好导致丢包和重传，在统计中，这种无线信号不好最差的情况导致数据有60秒都无法下发，平均也有15s左右。因此需要无线侧彻底排查下网络情况，找到为什么会有如此多的radio-status消息。4、为进一步排查问题，选择了石家庄华为BSC（下文简称为华为BSC）下进行了DT测试，希望通过比较华为BSC和中兴BSC下的数据传输特点，尽快解决问题地市中兴BSC下FTP速率慢问题。测试时间有1个多小时，这一段时间的平均速率为120kbit/s，大大优于问题地区的指标。通过比较跟踪的1个多小时内的58个消息跟踪。我们发现在华为BSC下小区切换时丢包重传要明显比中兴BSC下小区切换要少，同时在华为BSC下没有看到一个radio-status消息。具体的数据统计如下：在这些跟踪中，数传时小区切换44次。44次小区切换中，中断时间（包括重传数据包的时间）绝大部分都是在3s之内，其中15次切换没有中断（没有服务器重传），21次在重传时间在3s之内，剩下的8次中，只有三次切换消耗超过了5s，分别是8s,17s,21s。与中兴BSC相比，华为BSC在小区切换时明显耗时更少，那么我们仔细分析一下产生这种现象的原因：选取10:20:27的跟踪为例，在此时发生了小区更新：看一下此时的cap包，此时出现了手机在重复请求一个包（第98,99,100,102,103,106,107,108），该包的序号为：66428，说明该包在小区更新后手机没有收到。在第101和105行，服务器重传了这两个包，其中Sequence number都是66428：而关注下第109行，此时手机确认的数据包为79000，这意味着序号在6788879000之间的数据包手机已经收到了，且此时服务器并没有重传6788879000的数据包。因此通过这个跟踪可以看出，此次小区切换时，丢了66428的包，但是大部份的其他数据包（6788879000）仍然能够在小区切换时下发。也就是说小区切换时仅仅丢弃了少部分的包或者根本不丢包（44次小区切换中有15次时没有任何丢包），这样服务器只需要重传很少的包就可以了，对小区切换时的速率有很大的提高。这个跟踪说明华为BSC做了非常好的优化机制，在小区切换时能够主动缓存和重发小区切换时的数据包。解决措施：需要无线设备厂家通过软件补丁或者参数修改问题行解决缺陷。经验总结：1 在分析数传问题时需要从整体上进行分析，而小区切换时的丢包占了整体丢包的80以上。因此小区切换时丢包是FTP下载速率慢的根本原因。目前中兴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帧无法组包的现象。据中兴工