巴基斯坦PTCL DOA前反向速率低.doc

巴基斯坦PTCL DOA前反向速率低的案例分析拟制刘威日期2009-3-6审核日期审核日期批准日期本文中的所有信息归中兴通讯股份有限公司所有，未经允许，不得外传速率低的案例分析目 录1 案例现象描述12 实际测试情况13 前向速率低定位分析过程34 反向速率低定位分析过程104.1 现象104.2 关键参数解析124.2.1 PSAxis124.2.2 TxT2PmaxPSAxis125 总结161 案例现象描述在无线环境很好（DRC申请速率在3.1Mbps）的点进行单用户前反向吞吐量测试。发现前向平均只有1.1Mbps，反向只有250Kbps.2 实际测试情况PTCL客户反映DOA前反向速率非常差，前向只有1.1Mbps,反向只有250Kbps.并且开始怀疑我司提供的网络并非DOA，而是DO0。针对这种情况我们进行了DT测试 图1 前向发包统计。 图2 前向RLP统计从上面2张图可以看出，无线环境很好，DRC申请速率为3.1Mbps，前向几乎都是以DRC=14的包格式发送数据，且都是1个子包就终止。且RLP重传率也比较低。从下图统计应用层速率为800Kbps. 图3 TCP IP序号分析3 前向速率低定位分析过程从RLP 统计中的NAK TIMEOUT/NAK ABORT为0可以推断所有的空口的RLP重传都已成功，而且RLP重传率也比较低，这说明空口质量很不错。影响前向吞吐量低的原因可能有以下下几个：1） 各个网元之间的带宽2） 网络中存在丢包3） 网络拓扑结构复杂，造成传输时延大和丢包4） PDSN流量受限我们逐一排查。由于PDSN为华为设备，是否对ZTE网络的用户做了手脚我们不得而知，故我们从上面前3点进行排查。3.1 排查网元间带宽因素采用UDP方式进行排查，发现前向速率维持在2.9Mbps,这说明网元之间的带宽不存在问题。从Iperf打印来看发现前向包存在乱序，且误包率非常高。于是下一步就是通过FTP下载，在各个网元之间进行抓包。图4 UDP发包记录打印3.2 多点抓包分析通过Etheral多点抓包，可以分析出丢包或者乱序发生在哪里。抓包点确定在如下几点：FTP Server, PC client, RP口，PDSN。组网图如下：图5 现网组网图图6 多点抓包位置由于现网的网元设备并不完全是中兴的，其中PDSN和交换机是华为的设备，而且BSC机房与FTP，PDSN所在的机房分别在不同的城市，4点抓包实现起来较难。故开始我们只在Client，RP口，FTP这3点抓包。下面是具体的分析过程：1）TCP序号乱序图7 数据包（乱序前） 图7中左边序号为9169的包其TCP Sequence number为8887969（0x 10 b6 4b ae），期望的下一个包的Sequence number为8889329。图8 数据包（乱序）图8中#9172的包为下一个数据包，它的Sequence number为8890689（0x10 b6 56 4e）,并非#9169包所期望的。图9 数据包（乱序后） 图9中#9174的包的Sequence number为8889329（0x10 b6 50 fe），期望的下一个包的Sequence number为8890689。显然，#9174包应该位于#9170包和#9172包之间，但是现在乱序到达。分析这几个包的GRE序号，如下图：图10 GRE数据包序号 图10中GRE的Seq值从197559到197563依次对应图7-9中的#9169，#9170，#9172，#9173，#9174，这五个包的GRE序号是连续的，这就表明这些数据从PDSN出来到PCF没有出现丢包和乱序，TCP的乱序只能是发生在FTP server到PDSN这段链路或者PDSN内部。该乱序包引起了FTP server的TCP快速重传。图11-12为FTP server抓包数据。图11 FTP数据包图5中#193包显示FTP Sever顺序发送了Sequence number为0x10 b6 50 fe包。图12 FTP数据包图12中#227-#229为手机侧返回的三次值为0x10 b6 50 fe的ACK ，#230包表明FTP server对其进行了快速重传。2）TCP存在丢包图13 ftp server data-1图13中FTP server发出的#5594、#5597、#5598的包TCP sequence number分别为：0x10 f9 88 7e、0x10 f9 8d ce、0x10 f9 93 1e。（图中只显示了#5597包的Sequence number）图14 数据包（丢包前）图 15 数据包（丢包后）图14和图15是RP口的抓包，我们可以注意到图中#13757和#13760包分别对应图7中的#5594和#5598包，而图7中的#5597包没有正确到达RP口，后面也没有发生乱序的情况。#13757和#13760的GRE序号分别是200984、200985，也是连续的，这就说明数据从PDSN出来到PCF没有出现丢包和乱序，TCP的丢包只能是发生在FTP server到PDSN这段链路或者PDSN内部。因为图13中的#5597包的丢失，同样也引起了FTP server的TCP快速重传。图 16 the 快速重传包（FTP）图16中#5612即是FTP Server对该丢失包的快速重传。图17 快速重传包（RP口）图17为RP口包，显示收到了该丢失包的重传。结论：FTP下载过程中，存在较多的TCP乱序以及丢包，这势必影响速率，上面已经分析得出：空口重传比率较低，且空口重传都已成功。PDSN到BSC这段传输没有问题，那么乱序、丢包就应该在FTP与PDSN之间，这中间经过了一个交换机。于是对比FTP的下行数据和交换机送往PDSN的数据发现下行数据在送入PDSN之前就已经发生了乱序，那么问题就出在华为的交换机。但为什么华为的下行速率能够达到2.8Mbps呢？而我们只有1.2mbps。按照上面的分析，华为网络的下行速率因该和我们的速率差不多才对。难道是测试方法与我们不同，于是我们尝试使用FLASHGET多线程下载。速率也能稳定在2.7mbps左右。其实该问题并没有完全解决，只是多线程下载掩盖了单线程下载出现的乱序和丢包带来的负面影响。换句话说多线程能够抵消乱序和丢包带来的副作用。问题总算水落石出，但是中间的过程相当漫长，也相当的曲折。经历了这件事情以后，也提醒我们以后的DOA吞吐量测试因该把单线程与多线程结合起来。问题可能就解决了，我们也就从客户无休止的投诉中解脱出来。4 反向速率低定位分析过程4.1 现象从下图CNT的前向包统计来看，反向发送的最大的包格式为PS11，不存在PS12的大包。这是否和反向T2P参数设置有关呢？需要如何设置才能让终端发送12288的大包呢？DuMeter统计反向速率只有250kbps。观察CNT的反向统计，发现反向的数据包全部都为小包，不存在PS12（12288）的大包。且Tx T2P Maximum 取值非常小，只有17到19左右（正常值为2527）。经观察发现C/I维持在13dB，但是对应的Ec/Io小于-2dB,怀疑终端存在信号质量测量不准的问题。导致测试的Ec/Io偏小，导致TxT2PMax受限，终端无法按照大包（12288）的格式发送。4.2 关键参数解析4.2.1 PSAxis【字段描述】 PilotStrengthAxis, In conjunction with NumPilotStrengthAxisValues, this parameter defines the range of pilot strength values to which the function is responsive to. This defines the region of coverage that reverse link rate shaping is to be applied to.【配置约束】： If the combination is set such that the range is high, then a larger region of the coverage would have reverse link rate shaping applied to thereby increasing the potential number of users whose QoS might be affected. However, other cell interference from outlying users is reduced. If the combination is set such that the range is low, then a smaller region of the coverage is affected, thereby affecting a smaller potential number of users. The start and end points of the range are also defined by this parameter depending on the distribution of the Ec/Io of the coverage region for which rate shaping is to be in effect. 因为NumPSAxisValues缺省配置为2，对应PilotStrengthAxis有2维取值，缺省值（60，0），单位为-0.25dB。4.2.2 TxT2PmaxPSAxis【字段描述】 This is the factor by which the maximum value of transmitted T2P (TxT2P) is scaled based on Forward Link Pilot Ec/Io. .【配置约束】： If set high, adjacent cell and in-cell interference may be increased and overall system capacity reduced. However, MAC flows requiring large amounts of T2P for large payload transmissions would be allowed to transmit, benefiting the performance of the flow. If set low, interference to other cells is limited, but MAC flows requiring large payload transmissions would not be allowed to transmit enough T2P for the payload. In conjunction with PilotStrengthAxisX, the combination decides the amount of reduction in the maximum value TxT2P for a given coverage conditions represented by pilot strength measured in terms of Ec/Io. This attribute does not have a great performance impact on VoIP users or other applications utilizing small payload sizes. This attribute has a greater affect on applications that generally require large payload sizes. 取值范围0127，缺省值（24，44，54），单位为0.5dB。针对以上分析，查询BSC的DO参数，发现下面两套参数取值都为默认值。并无异常，考虑到前向链路质量的检测可能存在问题于是对这两个参数做了如下修改，修改后发现，在无线环境良好的情况下，反向绝大多数数据包都是按照大包格式（PS12288）发送，且Tx T2P Maximum已经恢复到正常值（在2527之间波动）。用户感受大幅提升由之前的250Kbps提升至800Kbps。但是后来一琢磨，客户使用的是华为的终端，投诉中兴的网络速率低，故可以推断，该问题并非终端原因导致，应该是TxT2PmaxPilotStrength参数设置的比较保守所导致。修改后：修改前：5 总结通过这次DOA的前反向速率定位过程，可以把吞吐量问题定位思路大致归结为如下几点：5.1 前向速率定位1、 首先检查空口，已确认速率问题是否为空口质量差导致2、 若空口没有问题，检查客户端和服务器端的TCP_WindwosSize，推荐取值为65535。一般来说服务器会安装FTP服务器软件，比如Ser_U等软件，软件设置里有一个名为发送缓冲区的参数设置。3、 检查链路的带宽，是否为速率异常的瓶颈。可通过UDP以3M/s的速率不断的发包。若速率非常稳定，固定