CDMA EVDO吞吐量故障定位指导书V113Word文档下载推荐.docx
《CDMA EVDO吞吐量故障定位指导书V113Word文档下载推荐.docx》由会员分享，可在线阅读，更多相关《CDMA EVDO吞吐量故障定位指导书V113Word文档下载推荐.docx（16页珍藏版）》请在冰豆网上搜索。
CR号
SectionNumber
修改章节
ChangeDescription
修改描述
Author
作者
1.0
目录
1.概述4
2.定位流程5
2.1.定位流程图5
2.2.定位流程说明6
2.3.解决方法9
2.3.1.多线程下载的作用9
2.3.2.如何解决TCPWindowSize过小问题9
2.3.3.如何解决FTP服务器发送缓冲区过小9
2.3.4.检查终端是否处在双模模式10
2.3.5.如何解决开户时的速率限制10
2.3.6.如何查看空口质量10
2.3.7.如何解决Abis链路带宽不足11
2.3.8.如何解决反向速率限制12
2.3.9.如何使用单用户流量跟踪排查吞吐量12
2.3.10.如何查看PPP连接是否存在错包13
2.3.11.如何观察RLPAbort13
2.3.12.如何使用Ethereal进行抓包分析14
2.3.13.如何使用QXDM进行空口分析14
3.案例15
3.1.FTP服务器发送缓冲区过小导致下载速率低15
3.1.1.现象15
3.1.2.原因分析15
3.1.3.定位过程15
3.2.Abis带宽受限导致下载速率低16
3.2.1.现象描述16
3.2.2.原因分析16
3.2.3.定位过程17
3.3.其他案例17
1.概述
1.1.简述
在本文里，吞吐量故障指的是吞吐量不能达到理论最大值，以及吞吐量异常波动。
本文纯粹从操作层面论述，如何定位这种故障，对涉及到理论知识的描述超出本文范畴
1.2.前置条件
达到DOA前向理论最大吞吐量2.9Mbps，需要同时满足以下4个条件
✧终端的空口C/I至少10dB以上
✧测试终端所在扇区能够独享至少2根E1
✧PCF与PDSN之间的网络不存在丢包
✧PDSN到FTPserver之间的网路不存在丢包
说明一下，一般说DOA前向最大吞吐量3.07Mbps，指的是物理层最大速率，而测速软件（比如DUMeter）只能统计应用层速率，大家知道，应用层速率是小于物理层速率的，因而，通过测速软件测得的DOA前向最大吞吐量为2.9Mbps左右
1.3.常见缺陷
虽然导致吞吐量故障的原因多种多样，但是，根据作者的经验，目前网络上出现的吞吐量故障往往是由于以下原因引入的，所以出现故障时，优先排查以下问题
✧空口不好（C/I达不到10dB以上），或者扇区内存在其他用户
✧Abis的带宽不足，不能达到
✧PCF与PDSN之间、PDSN与FTPserver之间存在丢包
✧PC机上的TCPWindowsize过小，不能满足前向最大吞吐量的需求
✧存在其他用户共享一个载频
出现吞吐量故障，首先排查以上5个问题，排查结束后，问题仍为解决，请参考下面的详细定位流程
2.定位流程
2.1.定位流程图
说明：
上面的流程图是针对下载时的吞吐量问题而画，上传时的定位方法可以参考
2.2.定位流程说明
如上面的定位流程图所示，发生吞吐量故障，一般的处理流程如下：
1.出现吞吐量故障，首先应该进行环境排查，排查的内容包括
1）终端的C/I是不是平稳维持在10dB以上
2）终端所在的扇区是不是能够独享2根E1的Abis带宽
2.完成环境排查后，确认是否使用了工具（使用FlashFTP）或者第三方软件（比如鼎立）下载；
1）【是】换用Windows命令行下载，观察现象是否消失
a）【是】问题解决，故障原因为工具或第三方软件引入
b）【否】跳转至3
2）【否】跳转至3
3.使用多个Windows命令行，进行多线程下载，观察下载速率。
多线程下载作用
1）【明显大于单线程吞吐量】跳转至4
2）【与单线程吞吐量区别不明显】跳转至7
4.单线程速率与多线程吞吐量是否平稳
1）【平稳】跳转至5
2）【不平稳】跳转至14，进入丢包排查流程
5.PC机上的TCPWindowSize是否过小
1）【是】解决TCPWindowsize过小的问题，解决方法参考如何解决TCPWindowSize过小问题，观察故障是否消失
a）【是】问题解决
b）【否】跳转至6
2）【否】跳转至6
6.FTP服务器的发送缓冲区是否过小
1）【是】解决FTP服务器的发送缓冲区过小问题，解决方法参考如何解决FTP服务器发送缓冲区过小，观察故障是否消失
b）【否】跳转至16
2）【否】跳转至16
7.速率是否在2M以上，但是达不到理论最大值
1）【吞吐量能够达到2.6M左右】检查终端是否处在双模模式，检查方法参考检查终端是否处在双模模式，将终端改为单模模式后，观察故障是否消失
b）【否】跳转至8
2）【吞吐量能够达到2.3M左右】检查终端是否协商成DO0模式，检查方法：
维护台上查询会话
8.用户开户时，是否有进行速率限制
1）【是】解决开户时的速率限制，具体方法参考如何查看开户时的速率限制，观察故障是否消失
b）【否】跳转至9
2）【否】跳转至9
9.终端的空口前向PER是否在0.5%以下，反向PER是否在1%以下
1）【是】跳转至10
2）【否】解决空口问题，查看空口质量的方法参考如何查看空口质量，观察故障是否消失
b）【否】跳转至10
10.Abis带宽是否足够
1）【是】跳转至11
2）【否】解决Abis口带宽不足问题，解决Abis带宽不足的方法参考如何解决Abis链路带宽不足，观察故障是否消失
b）跳转至11
11.反向速率是否受限到较低水平
1）【是】解决反向速率受限的问题，解决方法参考如何解决反向速率限制，观察故障是否消失
b）【否】跳转至12
2）【否】跳转至12
12.采用UDP进行Iperf传输，吞吐量是否足够
1）【是】跳转至丢包排查流程
2）【否】使用维护台上的“单用户流量跟踪排查”，使用方法参考如何使用单用户流量跟踪排查吞吐量
b）【否】跳转至13
13.观察FTPServer与PC的磁盘空间、CPU占用率是否异常
1）【是】问题解决
2）【否】跳转至丢包排查流程
14.检查PPP连接是否存在错包
1）【是】查看PPP连接是否存在丢包的方法，参考如何查看PPP连接是否存在错包，如果PPP连接存在错包，需要跳转至15
2）【否】跳转至15
15.检查RLP层是否存在NAKAbort，且数目与PPP错包数接近
1）【是】NAKAbort的观察方法，参考如何观察RLPAbort，丢包原因为Abis链路存在丢包，整改Abis链路
16.如果RLP层的NAKAbort与PPP错包数不一致，那么需要排查空口质量，排查空口的方法，参考如何查看空口质量
2）【否】跳转至17
17.终端、RP口（PDSN出口）、FTPserver三处抓包对比
1）【如果RP（PDSN出口）有丢包】PDSN到FTPserver之间的网络有丢包，抓包方法参考如何使用Ethereal进行抓包分析
b）【否】PDSN或者是FTPserver处有丢包
2）【如果RP（PDSN出口）没有丢包】PDSN到PCF之间的网络有丢包，抓包方法参考如何使用Ethereal进行抓包分析
b）【否】跳转至带宽受限排查流程
2.3.解决方法
2.3.1.多线程下载的作用
测试中，一般使用单线程进行下载，如果出现吞吐量故障，可以尝试使用多线程下载进行排查。
一般地，丢包引起的吞吐量故障，是由于TCP的惩罚机制，导致吞吐量低，使用多线程下载，能够有效地规避TCP惩罚机制对吞吐量的影响。
某一线程出现TCP惩罚，该线程的吞吐量下降；
由于其他进程同时也出现TCP惩罚的可能性小，因此，总的吞吐量应该变化不大。
因此，使用多线程下载时，如果吞吐量故障消失，说明是吞吐量故障是由于丢包导致的；
而如果故障不消失，说明网元或者接口出现了带宽受限。
2.3.2.如何解决TCPWindowSize过小问题
TCPWindowSize是TCP接收端的TCP接收窗口大小，如果PC上该值过小，会影响下载的吞吐量。
一般的解决方法是，在注册表里将下面路径里的TCPWindowSize修改为65535（十进制）；
如果PC上没有相应的项，需要手工创建DWORD属性的TCPWindowsize，并修改为65535
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\TcpWindowsize
2.3.3.如何解决FTP服务器发送缓冲区过小
Internet上共享的FTP服务器软件，不少都存在发送缓冲过小的问题。
解决该问题的一般方法是，建议使用FTP软件Serv-U，重新布设FTP服务器，该软件的性能是经过检验的。
而且该软件的发送缓冲区可以设置，可以解决FTP服务器发送缓冲区过小的问题
解决该故障有一个简单方法，就是换台服务器进行下载，或者同时在多台服务器上同时下载
2.3.4.检查终端是否处在双模模式
终端处于1x/DO双模模式时，会周期性侦听1x信道，因而对DO的吞吐量有一定的影响。
观察终端是否处于双模模式的方法很多，这里介绍一种。
打开QXDM的HDRPower，观察终端的功放是否会周期性关闭
2.3.5.如何解决开户时的速率限制
当BSC打开QOS开关后，BSC会对用户的最大前、反向带宽进行限制，前向带宽可以从PDSN-AAA获取，也可以在BSC内部设置，具体如何获取是通过软参来控制的，这里可以不讨论；
反向带宽一般根据BSC内部设定值来确定的。
查询QOS开关的命令为：
LSTDOGP:
;
查询前向限速的命令为：
LSTDOQOS:
（或者是查询PDSN-AAA里的开户值）
查询反向限速的命令为：
LSTDOAQOS:
2.3.6.如何查看空口质量
在QXDM的HDRRev.ASingle-UserForwardStatisticsSummary里，观察终端申请的包，是不是绝大多数（90%以上）为DRC13/14，且平均终止报数接近1，以及PacketErrorRate在0.5%以下，如果同时满足上面三个条件，说明空口质量好
如何解决空口环境不好？
方法如下：
✧将终端移至离基站更近的地方，观察C/I变化，是否达到10dB
C/I的观察方法如下：
观察如下截图里面C/I的最大值，最大值表示真实的C/I
2.3.7.如何解决Abis链路带宽不足
使用维护台查询Abis链路的状态
LSTBTSLNK：
查看基站使用的物理链路，这里以E1为例，即查看基站使用的E1数
DSPMPLNKSTAT；
查看基站使用的MLPPP链路的状态
DSPE1T1STAT：
查看基站使用的E1状态，确保基站使用的E1状态“可用“
同时还需要查询基站侧的配置，观察相应的MLPPP组内是否包含同样数目的E1数
需要注意的是，即使基站的Abis链路使用的E1数目达到2根，而且状态均“可用”，也不能就此定论，Abis带宽没有问题。
由于基站的各个扇区是共用Abis链路带宽，因而测试中，还要确保其他扇区没有用户下载，才能确定Abis链路带宽足够
总结一下，要想达到2.9M的理论下载
2.3.8.如何解决反向速率限制
由于TCP业务是采用基于ACK的模式进行传输的，前向的速率也要依靠反向链路的带宽与时延来保障，理论上，要保障前向2.9Mbps的速率，反向的带宽不能少于100k，反向的PER不能高于2%，在2个条件不能同时满足的情况下，前向速率是没有保障的
反向速率过低，与PER过高，一般都是由于基站的反向接收质量不好导致的，需要检查基站的反向RSSI；
另外，反向速率过低，可能还和反向负荷相关，因此需要查询反向负荷的RAB门限，命令如下
LSTDORRMP:
DORRMINF=DOARLCP;
观察是否是由于反向负荷导致的反向速率过低，需要使用QXDM的HDRRev.AReverseLinkT2PStatistics，观察FRAB（表示基站忙闲程度，越大越忙）是否在0以上
另外，反向速率过低，还可能和QOS有关，使用MODDOAQOS修改
2.3.9.如何使用单用户流量跟踪排查吞吐量
维护台上的单用户流量跟踪，可以查看PCF与DPUD的流量跟踪，比如PCF的缓冲区跟踪如下图所示，使用Iperf进行UDP灌包时，如果发现PCF缓冲包过多，说明是PCF以下出现带宽受限；
如果PCF没有出现缓冲包裹多，说明在PCF以上出现了带宽受限
2.3.10.如何查看PPP连接是否存在错包
一般而言，Abis链路有丢包的话，都会表现在PPP层上。
通过查看拨号连接的PPP错包数，大致可见端倪。
2.3.11.如何观察RLPAbort
打开QXDM的HDRMulti-FlowRLPForwardStatistics，如下图红框所示，查看终端的RLPAbort，下图中的RLPAbort的个数为6
2.3.12.如何使用Ethereal进行抓包分析
Ethereal是一个广泛应用的抓包软件。
Ethereal是免费软件，可以从互联网上十分方便地获取。
Ethereal功能强大，能够解析目前的大部分协议，其中也包括A11消息。
Ethereal之所以称之为TCP分析利器，主要在于其TCP序号分析功能，该功能能够以图形化的形式显示丢包、重传等TCP行为，对于EVDO网络的吞吐量定位十分方便。
Ethereal的详细使用方法参考下面的文档：
2.3.13.如何使用QXDM进行空口分析
QXDM（TheQUALCOMMExtensibleDiagnosticMonitor）是高通公司（Qualcomm）公司发布的可以对手机终端所发数据进行跟踪有效工具，通过对数据的分析可以诊断信令流程、分析数据包的正确与否等。
QXDM同时适用于1x或DO的空口诊断，在测试中有重要作用，正确合理的使用可以为我们测试提供便捷的定位手段。
QXDM的详细使用方法，参见下面这篇文档
3.案例
3.1.FTP服务器发送缓冲区过小导致下载速率低
3.1.1.现象
空口条件好，C/I在10dB以上。
测试的结果显示速率只能达到400多kbps
3.1.2.原因分析
用作FTPServer的PC机的FTP软件的发送缓冲区过小，只有8Kbytes左右，而PC机到FTP服务器的环回时延为160ms左右，因此速率被限制在400多kbps。
将FTP发送缓冲区改为65535bytes后，速率上升到峰值1.8M，原因为一根E1的带宽只有1.8M左右
3.1.3.定位过程
用QXDM分析终端的无线传输情况，发现RLP层没有丢包，空口上能够申请到3.1M的空口速率，但是前向每秒600个时隙，只占用了100多个，因此说明速率被限制在400多kbps与空口无关，而且说明前向包的流量不够。
为什么前向的流量不够，存在两种可能：
1、前向网元上有流控，不过400多kbps还不足以引起EC、FMR、BPU、PDSN、ROUTER流控
2、FTPserver本身发送缓冲区过小，导致流量不够，排除上面的原因，只有这种可能了
由于FTPserver缓冲区过小，我们通过注册表修改TCP的发送缓冲区，但是仍然没有效果，因此怀疑除了TCP发送缓冲区对发送流量有影响外，其他的设置参数也会有影响，后来我们发现，FTPServer软件自身还有一个发送缓冲区，它同样限制着Server的发送流量。
将软件的发送缓冲区修改为65535bytes后，流量峰值达到了1.8M
3.2.Abis带宽受限导致下载速率低
3.2.1.现象描述
测试中，发现终端在室内天线底下（C/I>
15dBm,Rx>
-35dBm）进行FTP下载测试（当时室内只有一个用户），测试软件QXDM显示的申请速率DRCRequest可以达到3Mpbs，而DUMETER显示的实际下载速率只有1.9Mpbs，在其它信号较好的地方下载速率也只有1.9Mpbs，这离DO最高峰值的下载速率3.1Mpbs还差很远。
如下图所示
而在同一BSC下的另一基站下测试，速率可以达到2.9Mbps
3.2.2.原因分析
在Abis传输接口板端口物理配置上增加了一根E1，这样就共有4M带宽了。
之后，在维护台上操作界面上进行了传输端口相应的软件配置，首先，输入命令LSTBTSLNK查询要修改的链路信息，然后输入命令MODBTSLNKBW进行修改传输链路带宽，把要修改的链路参数输入进去，带宽修改为4000k。
（注：
这里使用命令为老版本命令）
在完成上述操作后，回到议事园酒店同样的测试地点进行FTP下载测试，C/I>
14dBm，Rx>
-32dBm，DUMETER显示的实际下载速率已经可以达到2.83Mpbs。
3.2.3.定位过程
定位中发现，该室内站的Abis传输接口板端口物理上只配置了一条E1，而一条E1只有2M带宽，这样是无法满足DORA最高的下载速率要求的
3.3.其他案例
4.附录
4.1.专业名词
C/I：
DO网络中表征导频强度的指标，为有用信号与无用信号之比，与Ec/Io有换算关系
RLP：
RadioLinkProtocol，无线链路协议
DRC：
DateRateChannel，反向用于申请前向包的信道，信道上传输的申请值称为DRCValue，表征申请包大小
RP：
PCF与PDSN之间的接口
RSSI：
反向信号强度指示，一般用来表征基站反向收到的信号强度
升级会员 