HW-EVDO优化案例分析

1、HUAWEI TECHNOLOGIES Co., LHUAWEI Confidential Security Level: InternalHW-EVDO优化案例分析ISSUE 1.01HUAWEI TECHNOLOGIES Co., Ltd.HUAWEI Confidential Page 2了解1xEV-DO Rel0及DO RevA常见问题及其处理过程掌握1xEV-DO Rel0及DO RevA的问题处理思路，测试方法，分析手段通过案例的学习，尽快定位问题学习完本课程，您将会：HUAWEI TECHNOLOGIES Co., Ltd.HUAWEI Confidential Page 3第

2、第2章章 EVDO掉话案例掉话案例第第3章章 EVDO速率案例速率案例第第4章章 EVDO切换案例切换案例第第5章章 EVDO其他案例其他案例HUAWEI TECHNOLOGIES Co., Ltd.HUAWEI Confidential Page 4EVDO接入问题分类及分析建议接入问题分类及分析建议影响影响EVDOEVDO接入的主要问题：接入的主要问题：1、会话建立过程中配置协商失败2、AN AAA/AAA鉴权失败3、接入参数设置不合理4、覆盖、容量问题5、数据配置问题6、单板异常、故障分析建议：分析建议：1、为了减少不必要的流程，数据配置时应尽量使用协议规定的缺省值；2、跟踪信令确认鉴权

3、结果（如鉴权失败，需要进一步在AAA服务器上检 查用户信息）3、常用接入参数优化4、功率控制参数优化5、检查业务HUAWEI TECHNOLOGIES Co., Ltd.HUAWEI Confidential Page 5EVDO接入问题分类及分析建议接入问题分类及分析建议参数范围缺省值描述接入参数消息AccessParametersMessage接入信道周期持续时间AccessCycleDuration0255slots64slots表示广播时隙周期内接入周期的持续时间功率增加步长 PowerStep015（单位0.5dB）6表示连续试探的功率增长接入试探最大数ProbeNumStep115

4、5表示一个接入试探序列中的最大试探数接入前缀长度PreambleLength17帧2帧表示接入试探的前缀长度试探序列最大数ProbeSequencedMax1153一个接入尝试中允许的接入试探序列的最大数目开环功率校正因子ProbeInitialAdjust-1615（单位0.5dB） 0表示开环功率估计中，AT在接入信道上最初传送所用的校正因子 参数范围缺省值描述PCT最小值 MINPCT 取值范围：28672 12416，单位：1/1024dB21504（-21dB） BSC外环功控对PCT调整的最小取值 PCT最大值 MAXPCT 28672 12416，单位：1/1024dB 1945

5、6（-19dB） BSC外环功控对PCT调整的最大取值 PCT初始值 INITPCT 28672 12416，单位：1/1024dB 21504 (21.0dB) BSC功控以PCT的初始值开始 无数据状态下的最大PCT值 NODATAMAX 28672 12416，单位：1/1024dB 21504 (21.0dB) NoData状态下的PCT最大值，防止PCT在NoData状态下增长过大 HUAWEI TECHNOLOGIES Co., Ltd.HUAWEI Confidential Page 6EVDO接入案例接入案例AN AAA鉴权鉴权有时终端不主动发起接入鉴权，导致会话建立总是失败，

6、这时使用QPST工具检查终端的设置。终端必须在1xEV界面配置了NAI和Password信息才会主动发起接入鉴权。目前我司EVDO系统通过SMP软参可以关闭接入鉴权过程，以便于没有鉴权需求的展览和外部测试局点节约成本，但涉及双模切换项目时，为保证终端在EVDO系统获得正确的“IMSI”，必须提供AN-AAA并配置正确的IMSI。通过对维护台上对通过对维护台上对A12接口的消息跟踪来对分析接口的消息跟踪来对分析AN AAA的鉴权问题的鉴权问题问题现象处理建议A12跟踪没有结果检查终端有无配置CHAP用户名和密码A12跟踪只有请求消息，没有应答检查是否存在A12告警，告警原因有：1、AN-AAA进

7、程没有启动；2、PCF到AN-AAA的IP通道不通；3、AN-AAA没有配置相应的NAS信息，NAS的IP地址必须是ADD HACAAA中对应的PCFIPA12都跟踪到了请求和响应消息，但是鉴权失败有以下可能：1、AN-AAA配置的NAS密码和ADD ANAAA中的密钥不一致；2、终端用户名的密码和AN-AAA配置的用户名和密码不一致；HUAWEI TECHNOLOGIES Co., Ltd.HUAWEI Confidential Page 7EVDO接入案例接入案例AcAck消息多次重发导致消息多次重发导致DO会话建立成功率低会话建立成功率低 （1）【现象描述】在DO会话建立过程中，发现大量

8、因为HardwareIDResponse消息没有收到造成的会话建立失败，经过对比cait log和基站主控调试台的信令，发现cait上显示发出的HardwareIDResponse在基站并没有收到。 【处理过程】1、 分析现场数据话统：从话统数据中，发现Session Setup Failure的主要原因是NoHardWareIDRspReceived和NoUATICompleteReceived。 2、 通过对比分析现场的配置数据和实验室镜像环境的开关状态，发现现场的BTS打开了异步消息重发开关，从CAIT的消息中也可以看到BTS对异步控制信道上的ACACK Message和Hardware

9、IDRequest Message都进行了重发。打开测试环境的BTS的异步消息重发开关，此时出现了AT发送了HardwareIDResponse Message，而BTS未收到对应的这条消息的会话建立失败，因此推断异步消息的重发对会话建立成功率有很大的影响。 HUAWEI TECHNOLOGIES Co., Ltd.HUAWEI Confidential Page 8EVDO接入案例接入案例AcAck消息多次重发导致消息多次重发导致DO会话建立成功率低（会话建立成功率低（2） 3、将此问题提交给高通，高通给出如下答复：a) From the log, while AT is sending t

10、he AC MAC capsule, AN sends the ACAck to terminate the sending. AN should not do that, if AN does not receive any AC MAC capsules. AC message printed out in Log means AC message has been packeted and ready to be sent. it does not mean this massage has been sent out.b) As we discussed, An should send

11、 ACAck while recieving access MAC capsule. According to standard, one ACAck is corresponding to dedicated one access MAC capsule. AN should not send more than one ACAck for one access MAC capsule. 【结论】打开控制信道异步消息重发开关后，要将AcAck消息重发次数设置为0（默认值是2，既重发3次）。 HUAWEI TECHNOLOGIES Co., Ltd.HUAWEI Confidential Pa

12、ge 9EVDO接入案例接入案例接入搜索窗设置问题导致接入搜索窗设置问题导致终端无法接入终端无法接入 （1）【现象描述】某EVDO实验局BSC版本为BSC6600-OMCV200R001ENGC01B010，BTS版本为BTS3612-OMCV200R001ENGC01B011，组网情况为1CBSC、2BTS，其中A站为S222站型(PN:8、176、344)、B站为S22(PN:324、492)站型，EVDO采用160频点。在覆盖测试的过程中，关闭高通终端的接收分集增益，从基站处开始INCAR下载数据，业务保持到25公里左右就由于无线环境的原因产生掉话，掉话地点终端的接收电平在-90至-10

13、0dBm之间波动，发射电平在+13至+23dBm之间波动，C/I总小于-10db， 将终端拿到车外，进行OUTDOOR STATIONARY测试，发现终端无法接入AN。设置DM2K连续短呼，从掉话点沿原路返回，在信号质量比较好的地方也无法接入，直到距离靠近基站约15公里的地方才能正常接入，当时的接收电平在-79至-86dBm之间波动，发射电平在-2左右波动，C/I为3db左右。【处理过程】1、 通过DM2K测试数据的回放，查看15公里内的呼叫建立情况，发现信令流程正常，呼叫正常建立。但查看15公里之外的呼叫建立情况的时候，在手机发送ROUTE UPDATE和CONNECTION REQUEST

14、消息后，空口无AN的应答和TCA信令，因此手机提高功率继续试探，仍无法接入。2、 从BSC DEBUG调试台上跟踪信息，在15公里内呼叫的时候，DEBUG看到的信令正常。但是在15公里之外呼叫的时候，BSC没有收到手机的ROUTE UPDATE和CONNECTION REQUEST消息，说明问题出在BTS。3、 查看是否有反向干扰，TELNET查看RSSI，长时间查看，结果该扇区的RSSI正常。HUAWEI TECHNOLOGIES Co., Ltd.HUAWEI Confidential Page 10EVDO接入案例接入案例接入搜索窗设置问题导致接入搜索窗设置问题导致终端无法接入终端无法接

15、入 （2）4、 从空口看，15公里外呼叫的时候，信令已经发送了，由于信号情况良好，没有反向干扰，BTS应该是收到了消息，但是不能处理或处理错误。5、 怀疑为反向接入搜索窗口的设置导致了基站不能处理手机上报消息，咨询相关开发人员，了解到该版本的反向接入搜索窗口算法存在问题，导致最大的接入半径为16公里。6、 该版本的小区接入搜索窗口为128CHIPS，1CHIP相当于244米，因此128*244=31.2公里左右，由于是往返，所以为15.5公里左右，因此只能在约15公里的范围内接入。而反向业务搜索窗的半径是以手机上报位置为中心，以16公里为半径的范围。该问题最终通过修改接入搜索窗口为512CHI

16、PS（接入半径理论值为64公里），问题解决。【建议】基站的搜索窗口对覆盖的影响很大，反向的接入搜索窗口和业务搜索窗口要一致，如果两者不一致，将会导致在某些区域手机在接入过程中的接收信号显示良好，发射电平高的现象，与反向链路存在干扰问题现象类似，特别是在小区边缘，信号覆盖相对差一些的情况下，容易被误认为是反向干扰，建议在优化过程中加以关注。 HUAWEI TECHNOLOGIES Co., Ltd.HUAWEI Confidential Page 11EVDO接入案例接入案例BECM单板问题导致单板问题导致EVDO终端无法接入终端无法接入 【现象描述】某EVDO局BSC版本为BSC6600-OM

17、CV200R001ENGC01B010，BTS版本为BTS3612-OMCV200R001ENGC01B011，在测试过程中，发现PN324扇区出现信号很好但是始终无法接入的现象，在该扇区的近点，C/I达到了12-15之间，DRC达到了2.4576M的地点进行测试，结果还是不能接入，而在之前对该扇区的测试中，没有发现类似的现象。【处理过程】 1、由于前一天对该扇区的覆盖情况进行过测试，也进行过ACCESS和单用户吞吐量的相关测试，并没有出现过该问题。硬件安装没有变，软件上只是昨天进行了一次针对BSC的软件升级，复位了BSC。2、使用DM2K进行空口消息跟踪，发现在AT发起呼叫后，向AN发送RO

18、UTE UPDATE和CONNECTION REQUEST，但是AN侧对消息没有响应，没有相应的AC ACK和TRAFFIC CHANNEL ASSIGNMENT消息，因此无法接入。3、在调试台上跟踪SPU，收到MS上报的接入请求，之后前向进行业务指配，发TRAFFIC CHANNEL ASSIGNMENT给MS,然而手机却没有收TRAFFIC CHANNEL ASSINMENT消息，这一点在DM2K的测试过程中从信令可以看出。因此怀疑消息在经过BTS处理的时候发生了错误处理的时候发生了错误。4、在BTS侧也进行ABIS口的跟踪，得到的结果显示BSC下发的TRAFFIC CHANNEL ASS

19、IGNMENT消息被下到另外的扇区里了，手机接不到指配消息，所以无法接入。同时发现ROUTE UPDATE消息在经过BECM板处理后，增加消息头的时候发生错误，从而导致TCA消息下发的目标小区发生错误，导致呼叫建立失败。因此故障基本定位为该BECM板内部有问题导致了无法正常接入的现象。板内部有问题导致了无法正常接入的现象。【结论】该问题基本定位为单板内部的软件问题导致，从现象看单板在系统复位后，单独对BECM板进行一次复位，之后就不会出现这种现象，否则，可能会出现该问题。规避方法每次系统复位后，对BECM单板进行复位，以规避该问题。 HUAWEI TECHNOLOGIES Co., Ltd.H

20、UAWEI Confidential Page 12EVDO接入案例接入案例1X与与DO业务链路标识冲突业务链路标识冲突导致导致DO无法上网（无法上网（1） 【现象描述现象描述】N国S局CDMA 1xEVDO 1900网络，1PDSN/1PCF/1AN/16BTS/48carrier，使用频点613，S4/4/4配置，其中S3/3/3 for 1X，S1/1/1 for DO。路测到某基站A（升级网方式的DO基站）掉话，之后在该基站三个扇区下始终无法建立PPP连接。该基站当前没有任何未恢复告警。BSC版本V200R001C02B018 【处理过程处理过程】 1、在其他区域测试可以正常上网，确定

21、并非整网问题，可以排除PCF上层的问题；2、替换终端测试，现象依旧，排除终端问题，发生问题前终端一直使用正常，排除鉴权问题；3、知会机房人员检查该基站告警，由于不是单个载频的问题，重点检查了信道板芯片和时钟板等的状态，并没有异常；4、路测分析空口质量良好，各指标达到近点水平，但DRC一直维持在76.8kbps，终端侧的信令分析，会话建立流程没有完成，AT发送connectionrequest并没有收到TCA消息，而是收到CC（控制信道）下发的connectiondeny消息，原因值”network busy”以及”protocol error”，从而结束流程；5、问题集中在AN侧为什么不能分配

22、业务信道上以及为什么出现“协议错误”这样的错误，类似地，可能是空口、CE、地面链路资源有问题。在BSC侧继续进行用户接口跟踪，AT发的connectionrequest收到后，BSC直接释放abis链路，如图： HUAWEI TECHNOLOGIES Co., Ltd.HUAWEI Confidential Page 13EVDO接入案例接入案例1X与与DO业务链路标识冲突业务链路标识冲突导致导致DO无法上网（无法上网（2）6、用LST BTSLNK检查Abis链路配置，发现该基站一条1X链路和DO链路配置相同的业务链路标识”1-248-3”，问题找到了，该基站从S3/3/3扩容到S4/4/4

23、时增加新的业务链路配置错误导致DO载频无法建立业务链路，DO无法上网。7、维护台上LST BTSLNK检查，修改该基站的业务链路配置，测试DO业务恢复正常。 【结论】这种链路配置错误在维护台上不会禁止执行，也不会引起告警，有一定的隐蔽性，OMC对abis的容错和性能监控方面应加强。 HUAWEI TECHNOLOGIES Co., Ltd.HUAWEI Confidential Page 14第第1章章 EVDO接入案例接入案例第第3章章 EVDO速率案例速率案例第第4章章 EVDO切换案例切换案例第第5章章 EVDO其他案例其他案例HUAWEI TECHNOLOGIES Co., Ltd.H

24、UAWEI Confidential Page 15EVDO掉话问题分类及分析建议掉话问题分类及分析建议导致导致EVDOEVDO掉话的主要问题：掉话的主要问题：1、覆盖不足2、空口/传输误码3、干扰4、切换失败分析建议：分析建议：1、路测、CQT测试，通过测试分析掉话原因；2、收集话统数据及SPU日志，通过Nastar及OMStar分析掉话原因；3、分析掉话用户的CDR数据4、查看系统告警、基站单板告警、传输告警5、查看RSSI异常情况6、PN的检查及优化7、邻区检查及优化HUAWEI TECHNOLOGIES Co., Ltd.HUAWEI Confidential Page 16EVDO掉

25、话案例掉话案例强分支加不进来引发的连强分支加不进来引发的连接释放接释放 （1）【现象描述】问题现象特征：a. 上层数据速率为0。DRC很差，PER很高。b. 激活集PN80的EcIo较差，候选集分支PN96强度为-2.5dB，但是不能够加入激活集。【处理过程】对CAIT数据的回放疑问：为什么PN96无法加到激活集？ 无线场景分析激活集分支PN80的信号越来越差，相邻集分支PN96的信号越来越好；但是不能够成功切换，导致掉话。 HUAWEI TECHNOLOGIES Co., Ltd.HUAWEI Confidential Page 17EVDO掉话案例掉话案例强分支加不进来引发的连强分支加不进

26、来引发的连接释放接释放 （2）问题原因1. AT上报RU，要求增加PN96； 但是由于PN96的EcIo低于T_ADD，导致系统没有响应这条RU消息，没有发起切换。2. 后来，即使PN96的EcIo超过了T_ADD，AT再也不上报RU了，导致始终不能够把PN96加入激活集。3. PN96就成了一个强干扰，最终导致连接释放。问题的解决措施1. 修改切换判决算法。 当AT上报RU，RRM进行增加分支软切换判决时，缺省不使用T_ADD门限，只要是相邻集分支，AT上报的RU中的Keep指标为1，就增加这个分支。 安全起见，该修改用软参控制，开关可控。2.CCM周期的向AT下发ResetReport消息

27、，强制触发AT上报RU。安全起见，该修改用软参控制，开关可控。 【结论】 由于AT的行为，在未达到T_ADD门限就上报RU。而系统未作处理。当达到T_ADD门限时，AT又不上报RU，同样未得到系统处理。导致较强的分支没有及时被加入，而作为较强的干扰致使AT的连接断连。在增加算法的兼容性后问题解决。 HUAWEI TECHNOLOGIES Co., Ltd.HUAWEI Confidential Page 18第第1章章 EVDO接入案例接入案例第第2章章 EVDO掉话案例掉话案例第第4章章 EVDO切换案例切换案例第第5章章 EVDO其他案例其他案例HUAWEI TECHNOLOGIES Co

28、., Ltd.HUAWEI Confidential Page 19EVDO速率问题分类及分析建议速率问题分类及分析建议影响影响EVDOEVDO前反向速率的主要因素：前反向速率的主要因素：1、无线覆盖（C/I差，Tx高）2、带宽不足（CE不足、E1不足、业务链路带宽配置不足、PVC带宽不足、PDSN与PCF带宽不足）3、误码及重传（空口误码、传输误码）4、频繁切换5、终端及系统设置问题分析建议：分析建议：1、路测、CQT测试，通过测试分析掉话原因；2、从空口开始逐层检查业务带宽瓶颈（见下一页图）；3、通过ping命令、iperf工具在FMR、PCF上进行上下行时延及带宽测试；4、查看系统告警、

29、基站单板告警5、检查终端设置是否正确（包括与终端相连的便携机TCP窗口设置）；6、检查FTP服务器设置是否正确7、检查设备的配置数据（如是否固定了用户下行最大速率）8、避免频繁切换HUAWEI TECHNOLOGIES Co., Ltd.HUAWEI Confidential Page 20EVDO速率问题分类及分析建议速率问题分类及分析建议分析DO下行速率过低，根据木桶最短板原理，应该从底层开始，一层层分析判断受限点，定位原因并解决。一般，我们采用cait定位无线链路状况，采用ping命令、iperf定位有线侧链路状态。 HUAWEI TECHNOLOGIES Co., Ltd.HUAWEI

30、 Confidential Page 21EVDO速率案例速率案例反向功控参数设置不合理反向功控参数设置不合理导致的下载速率低导致的下载速率低 【现象描述】北京3G技术实验测试期间，发现定点的FTP下载速率总是不能稳定在2Mbps上。【处理过程】通过CAIT观察发现空口上前向经常有突发的NAK帧。在总部的外场观测，发现同样现象，通过调整BSC的反向功控参数，抬升终端发射功率后，突发NAK帧的情况消失，FTP下载速率趋于稳定在2Mbps以上。【结论】进行FTP下载时通过CAIT或者在BSC的调试台观察误码率是否大于1，空口是否有很多NAK帧。前向发送大量NAK帧说明反向业务信道误码过高，提高了反

31、向业务信道发射功率可以减少反向误码，改善反向应答消息的解调成功率。这对数据业务（基于TCP/IP协议）很重要，所以可以改善前向数据速率。HUAWEI TECHNOLOGIES Co., Ltd.HUAWEI Confidential Page 22EVDO速率案例速率案例链路带宽受限导致的链路带宽受限导致的DO下下行速率过低行速率过低 【现象描述】 在梧州联通测试下载时，空口情况良好，不存在误帧情况，前向稳定申请2.4M，采用ftp下载，速率在1.8M到1.4M间振荡，平均值无法突破1.6M，而理论分析，ftp下载应该达到2M以上。 【处理过程】通过iperf采用UDP发送测试，全链路带宽稳定

32、在1.6M左右。通过分析，与2M的PVC带宽有关，由于PVC效率在80左右，正好1.6带宽 。 【结论】通过调整DO的HAC，BPU，PPU，FMR之间的PVC带宽到4M，采用UDP下载速率突破了2M。 HUAWEI TECHNOLOGIES Co., Ltd.HUAWEI Confidential Page 23EVDO速率案例速率案例E1数目不足和业务链路配数目不足和业务链路配置错误造成置错误造成EV-DO数据业务下载速率低数据业务下载速率低 （1）【现象描述】 M国EV-DO网络在完成所有安装和配置之后，测试时单用户使用EV-DO FTP下载业务的平均速率只有700800Kbps，使用内

33、部FTP服务器下载，单用户平均速率依然很低。 【处理过程】1、用CAIT测试空口质量。测试结果表明C/I超过10dB，DRC始终为2.4Mbps，而且测试过程中没有收到相邻扇区或者基站的信号。这说明空口质量很好，不是造成下载速率低的原因。2、检查连FTP服务器和接终端以及FTP服务器的PC的配置。确认配置无误后，单用户平均下载速率依然保持在700800kbps。3、检查配置的E1数，发现每个EV-DO基站只配置了一条E1。但即使只有一条E1，单用户平均下载速率应该可以达到1.2Mbps，因为一条E1的有效物理带宽超过1.5M，所以E1数的限制还不是主要原因。不过每个EV-DO基站只配置一条E1

34、也是不合理的。给测试基站再加一条E1后，单用户平均下载速率可以达到1.5 Mbps。而根据经验，配置2条E1后，单用户平均下载速率应该超过1.9Mbps，问题仍然没有解决。4、在配置2条E1后，用iperf测试从PDSN到PCF和从PDSN到MS的实际物理带宽。测试结果为：PDSN和PCF之间的带宽约为73M，属于正常值；而PDSN和AT之间的带宽只有1.5M。HUAWEI TECHNOLOGIES Co., Ltd.HUAWEI Confidential Page 24EVDO速率案例速率案例E1数目不足和业务链路配数目不足和业务链路配置错误造成置错误造成EV-DO数据业务下载速率低数据业务

35、下载速率低 （2）5、检查BSC的带宽配置。用命令LST BTSLNK查询BIE板和BTS间的带宽设置，用命令LST ALPATH查询BIE板和FMR板间的带宽设置，在这一步终于发现了问题：之前为每个EV-DO基站配置了2条业务链路，但是每个EV-DO基站只配置了一块EC板。因此是E1数目不足和业务链路配置错误造成EV-DO数据业务下载速率低。在BSC和BTS侧都删除一条业务链路后，单用户平均下载速率终于到达了2.0Mbps，问题得到解决。 【结论】遇到EV-DO数据业务下载速率低的问题时，一般都可以从空口质量、服务器的TCP/IP协议窗口配置、物理链路配置、业务链路数等几个方面去查找原因。H

36、UAWEI TECHNOLOGIES Co., Ltd.HUAWEI Confidential Page 25EVDO速率案例速率案例IMA组中一条组中一条E1未工作导未工作导致致EVDO下行速率较低下行速率较低 【现象描述】 P国Z局CDMA450 1X网络，某基站，站型S222，1X和EVDO各一载波，E1配置：1X一条E1，UNI方式；DO两条E1，IMA方式。进行EVDO前向空载速率测试，近站处无切换，C/I在10dB左右跳动，申请DRC为1.8-2.4Mbps，进行FTP下载，速率平均在1M左右，最高只有1.4Mbps。 【处理过程】采用逐步排查进行分析：1.通过无线资源监控命令DS

37、P DORADIORESINDICATION查看该站资源使用情况，测试扇区Active用户数为1，其他扇区无用户；并通过DSP BTSFLUS命令确认前向没有FLUS加载；排除了多用户和FLUS加载的影响;2. 检查TCP参数，MTU为1500，TCP窗口为640000，没有问题；3. 查看Abis传输业务带宽和PVC带宽，分别配置为3.6M（IMA方式，两条E1）和6M，依然没有有问题；4. 检查历史告警，无该站E1/T1告警，但通过DSP E1T1STAT查看EVDO配置的两条E1工作状态，发觉只有一条E1处于正常工作状态；初步认为是E1故障的原因；5. 通过现场基站维护工程师的检修，另一

38、条E1工作恢复正常（据说是接口松动）；再进行测试，平均速率在1.8Mbps左右，瞬时最高速率达到2M以上。问题得到解决。【结论】基站开通后，对EVDO来说，单站的拨测不能只看是否能传输数据，应该同时关注实际传输速率，在对应的无线环境和配置下是否正常。 HUAWEI TECHNOLOGIES Co., Ltd.HUAWEI Confidential Page 26EVDO速率案例速率案例复杂组网下，中间链路问复杂组网下，中间链路问题导致下行速率受限题导致下行速率受限 （1）【现象描述】广西南宁EVDO实验局，通过FTP下载发现数据业务的下行速率很低，不到1Kbps，网页打不开。【处理过程】1、检

39、查便携和终端设置正常。2、通过终端的Debug窗口观察到Ec/Io在-1左右排除空口原因。3、检查从BTS到HAC之间沿途的带宽设置，均在4Mbps以上，现场只有1个DO单扇区，带宽足够。4、该组网特别处是PCF与PDSN间多了两个低端路由器，怀疑与路由器有关。通过PC机经路由器、PDSN连接到服务器进行FTP下载和网页浏览均正常。开始检查FMR、PPU、SPU的打印，未发现丢包。于是怀疑在路由器上可能大量丢包。联系总部了解到2631E路由器最大只能接收1.5K的包，超过该值时，包会被拆分。初步估计路由器和3COM PDSN配合有问题，导致包被大量丢弃，速率超低。HUAWEI TECHNOLO

40、GIES Co., Ltd.HUAWEI Confidential Page 27EVDO速率案例速率案例复杂组网下，中间链路问复杂组网下，中间链路问题导致下行速率受限（题导致下行速率受限（2）5、修改PDSN的SYS_MTU值为1400后，速率达到1.3M。由于1.3Mbps的速率仍然远低于正常值，怀疑传输上仍然存在问题。6、联系数通的技术支持人员检查后发现一台2631未接地，在路由器上有明显丢包。接地后，速率达到1.7Mbps。7、此时离理想数值仍有差距，通过netpersec观察，速率上不去在于每次下载10M文件过程中至少有一次大幅抖动，丢包很明显。固定反向速率情况依旧。已确认空口质量没

41、有问题，利用带宽测试工具通过UDP测试从分组域到终端的下行带宽，发现能达到2M以上。8、检查PDSN和服务器侧没有问题，BSC配置也看不出什么问题。最后又回到了路由器上，经过工程师现场定位发现南宁和梧州两个路由器间的4对E1有1对E1自环上了，导致下载过程中速率抖动很大。修正后，速率稳定，能够达到2.1M，经最后在国际会展中心地下室机房信号最强的地方测试，速率达到2.2M，峰值2.4M。 【结论】此案例中有PDSN设置问题（最大包长问题），也有工程安装问题（接地和自环），比较典型。HUAWEI TECHNOLOGIES Co., Ltd.HUAWEI Confidential Page 28E

42、VDO速率案例速率案例传输误码率高造成传输误码率高造成EVDO数数据业务速率低据业务速率低 （1）【现象描述】某地试验演示局，EVDO纯数据系统（无语音业务）。PDSN流媒体1 BSC（小容量）2 O1 CBTS3606（双E1）。在开通EVDO的CBSC及其中A基站后，测试其数据业务的速率只有1.4Mbps，而另一个B基站下行速率可达到2.3Mbps。 【处理过程】1.检查CBSC、CBTS数据及硬件，未发现错误，检查告警均正常，排除CBSS问题；2.检查由PDSN到PCF的A10、A11接口数据及数据网线均正常。同时对接在该PDSN下另一厂家的EVDO设备业务速率在2M左右，所以排除PDS

43、N设备及A10、A11接口问题；3.由于基站B下行速率达到2.3M，所以排除BSC内部框间连接及数据问题；4.DRC申请的速率基本都是2.4Mbps，这就说明空口质量非常好；5.检查基站ABIS口信令链路及维护链路带宽为110K，业务链路带宽为3.2M，所以配置PVC带宽正常；6.终端侧的TCP窗口的大小对速率也有很大的影响，于是检查TCP的设置参数：TcpWindowSize 0 x0000ffff(WINDOWS XP)排除了终端这边的设置问题； HUAWEI TECHNOLOGIES Co., Ltd.HUAWEI Confidential Page 29EVDO速率案例速率案例传输误码

44、率高造成传输误码率高造成EVDO数数据业务速率低据业务速率低 （2）7. ABIS接口采用2对E1组成的IMA，在物理上不存在瓶颈。采用LST CBTSLNKERRCNT命令检查ABIS接口误码统计，发现两条链路的每秒丢包个数(ERROR CONNT)基本为100200，确认ABIS传输不正常，显示如下：2005/06/09/16/35/05: LINKID = 0 ERROR CONNT = 121,2005/06/09/16/36/05: LINKID = 0 ERROR CONNT = 111,2005/06/09/16/37/05: LINKID = 0 ERROR CONNT = 1

45、03,2005/06/03/18/20/51: LINKID = 1 ERROR CONNT = 124,2005/06/03/18/21/51: LINKID = 1 ERROR CONNT = 106,2005/06/03/18/22/51: LINKID = 1 ERROR CONNT = 117,2005/06/03/18/23/51: LINKID = 1 ERROR CONNT = 124,2005/06/03/18/24/51: LINKID = 1 ERROR CONNT = 125,2005/06/03/18/25/51: LINKID = 1 ERROR CONNT = 1

46、24,问题定位到ABIS口数据及硬件，检查ABIS数据正常。检查对应检查对应ABIS接口传输设备，发现从接口传输设备，发现从BSC侧侧DDF架到光传输之间、及架到光传输之间、及BTS侧侧DDF架到光传输之间均未接地，在安装规范架到光传输之间均未接地，在安装规范中要求光传输设备的输入、输出必须单端接地，否则将会产生相应的误码；中要求光传输设备的输入、输出必须单端接地，否则将会产生相应的误码；8. 在光传输设备的维护台上早已有传输误码告警，但由于原来该光传输是使用于GSM基站的ABIS接口，虽然传输的误码产生一定的话音质量差，但由于语音的误码要求(1E-4)较EVDO传输误码(1E-6)小，所以客

47、户也未深究。但对于EVDO这样数据传输时，光传输设备的误码直接造成下行速率下降；在DDF架进行相应接地后，测试业务下行速率达到2.2M（三星手机）。【结论】1、分析DO下行速率过低，根据木桶最短板原理，应该从底层开始，一层层分析判断受限点，定位原因并解决.2、由于数据业务在传输通道中误码率及时钟同步要求比语音业务高，所以在EVDO设备开局时注意系统时钟的同步及精度。 HUAWEI TECHNOLOGIES Co., Ltd.HUAWEI Confidential Page 30EVDO速率案例速率案例EC板缓存太大导致频繁切板缓存太大导致频繁切换时换时DO Rev.A终端掉零终端掉零 【现象描

48、述】使用AnyDATA终端（协商为DO Rev.A模式）进行路测，在切换带内，经常出现速率掉零，且长时间无法自动恢复，需要手动重启FTP下载后，下载才能恢复正常。 【处理过程】1、分析AT的log数据，发现在产生掉零的位置，空口环境变化非常剧烈，AT申请的DRC在0到1.2M之间剧烈波动，同时AT的RLP数据中增加了许多RLP Abort。2、分析FMR和信道板的打印信息，发现信道板此时的缓冲队列大多为满的状态。由于DRC由大到小变化非常迅速，又伴随多次虚拟软切换，每次虚拟软切换都会将缓冲区中的数据全部清空，因此，FMR下发的重传数据不能及时的发到AT，导致AT侧产生RLP Abort，将错误

49、遗留到上层TCP层后，引发TCP的惩罚机制，导致速率降为0。 3、EC板的缓存默认设置为32760byte，在大部分情况下切换是没有问题的，但对于频繁切换情况，由于产品的实现机制，在切换前需要清空原缓存，导致大量的数据靠上层的重传来保证，大量的数据如果在AT的RLP定时器超时之前来不及重传，则会产生大量的RLP Abort，传递到上层TCP层，从而导致掉零；但如果设置EC板的缓存值太小，由于拥塞控制机制，将会导致单用户下载情况下速率达不到理论值。 【结论】EC板缓存为代码写死参数，无维护台命令可修改。通过多次测试发现设置EC板缓存为14000byte时，频繁切换导致掉零问题和下载速率低问题都可

50、以得到解决。但由于网络的差异，不一定适合其它地方，对于特定的网络，需要测试验证。 HUAWEI TECHNOLOGIES Co., Ltd.HUAWEI Confidential Page 31EVDO速率案例速率案例FMR缓冲区不够导致频繁缓冲区不够导致频繁切换时切换时DO Rel.0终端掉零终端掉零 【现象描述】使用AnyDATA终端（协商为DO Rel.0模式）进行路测，在切换带内，经常出现速率掉零，且长时间无法自动恢复，需要手动重启FTP下载后，下载才能恢复正常。 【处理过程】1、对比该时段前后Cait log，发现在GPS时间15:44:06.203时，AT发送了连续发送了两条反向R

51、LP消息，空洞长度分别为31842和25668字节，这样的大空洞是导致速率掉零的直接原因。2、回放Cait数据，在上述大片空洞产生之前都发生了虚拟软切换 3、分析FMR调试台打印也可以看到，这段时间内切换很频繁，开始的时候是0号分支作为主分支。当2号分支发起Req时，基站缓冲区被清除，此时可以看到基站缓冲区数据量很大，几乎是满的。另外刚切换到2号分支，就发现2号分支连续几秒钟收到的反向帧都是误帧。此时处于无主分支状态。基站又清除缓冲区，在这540ms内有损失了200多个前向包和200多个重传包。4、基站上报的从空口发出去的FrameID和FMR发给BTS的FrameID相差很大。在虚拟软切换时

52、，基站会清空发送缓冲区，基站的缓冲区设定是32760字节，相当于263个RLP包，而FMR只会记录已发给BTS的10个包记录，当基站大量数据被清除时，要求传输的数据在FMR中找不到（基站刚把缓冲区填满，就发生了虚拟软切换），此时会在AT的RLP层产生一个大小为200多个包的空洞，只能依靠于TCP层的重传，这会导致很大的速率波谷。 【结论】BTS EC板缓存与FMR的记录相差太大是频繁切换时DO Rel.0路测掉零的根本原因。 目前产品不支持命令修改，BSC版本V2R3C03B012最近版本已经把记录数写死为270。 HUAWEI TECHNOLOGIES Co., Ltd.HUAWEI Con

53、fidential Page 32EVDO速率案例速率案例HAC板不稳定问题导致的板不稳定问题导致的DO用户前反向速率出现周期性大的波动用户前反向速率出现周期性大的波动 【现象描述】某EVDO局BSC版本为BSC6600-OMCV200R001ENGC01B010，BTS版本为BTS3612-OMCV200R001ENGC01B011。 EVDO的FTP下载传输速率很不稳定，在基站附近，信号质量很好，DRC为2.4576M和C/I为11-13的时候，单用户的下载传输速率一般在30kBps到130kBps间，波动很大，上传速率也出现类似的波动。 【处理过程】1、由于本次测试使用的是局方的PDSN

54、设备和FTP server，而局方的该设备之前一直运行正常，所以可以先排除 PDSN和FTP服务器的问题。2、对硬件安装情况进行检查，设备安装质量无问题，之后重新制作网线，逐步更换我们的LAN SWITCH和局方PDSN 和我司PCF之间的连接网线，每次拨号测试，故障仍存在，检查BTS的E1状态，正常无告警。3、据中研反馈，这种高通的手机由于存在下载半小时以上就会断掉业务的问题，并且该问题当时已经和高通确认。 但是现场的主要问题是速率的波动和平均速率低，和描述现象不是很一致。4、检查数据配置，没有发现问题，重新安装BAM，复位，发现FTP下载速率最大可以达到180kBps左右，但存在周 期性的

55、大波谷。5、怀疑带宽的限制造成该问题，尝试修改系统PVC带宽后复位，发现波动更频繁，性能比之前还要差。由于速率 十分不稳定，修改回原始带宽复位，速率变为波动从0297kBps之间，更加不稳定，不能恢复原来的相对稳定 状态。6、由于多次复位系统后，每次速率变化都不太一样，数据没有变化（带宽数据已经改回），因此怀疑系统的软件 或硬件部分存在不稳定的因素，想起想起HACHAC板几日来随机出现几次板几日来随机出现几次GEGE口告警口告警，更换BSC的HAC板，重新测试，平均 吞吐量可以达到近点200kBps左右，反向吞吐量也可稳定达到126kbps，问题解决。 【结论】在处理问题的时候要关注告警信息，

56、特别是新产品，出现的问题有的时候会比较多，很难定位，告警是比较重要的定位信息。 HUAWEI TECHNOLOGIES Co., Ltd.HUAWEI Confidential Page 33EVDO速率案例速率案例由于便携机由于便携机TCP接收窗及接收窗及FTP服服务器务器TCP发送窗口太小，导致下行速率过低发送窗口太小，导致下行速率过低 【现象描述】在外场测试时，DO的下载速率只有1M左右。 【处理过程】1、下载时，空口情况良好，不存在误帧情况，前向稳定申请2.4M，通过iperf采用UDP发送测试，前向全链路带宽确实达到2M。但FTP下载速率只有1M左右，且较稳定，说明ftp进入稳定状态

57、，与TCP的慢启动无关。采用多进程下载能显著提高下载速率，2、检查便携注册表的TcpWindowSize设置。Tcp窗口大小取8k字节的整数倍，并需要保证TcpWindowSize = 双向时延速率，一般设置为64000Byte。例如建立拨号连接后从便携ping网络侧服务器，如果往返时延是200ms，期望FTP下载速率为2Mbps，那么TcpWindowSize 0.2*2000000/8 = 50000字节，则比较合适的取值就是最近的64000字节。若是WinXP，还需检查注册表中DefaultRcvWindow；此值需要设置为65535，以保证便携接收缓冲区足够大。3、分析表明，稳定时，f

58、tp速率与带宽、延时以及发送接收窗大小相关。4、经检查TCP接收窗大小为8k，可能存在瓶颈问题。 5、同理检查并调整FTP服务器TCP发送窗口大小。【结论】 通过调整窗便携机TCP接收窗大小及FTP服务器TCP发送窗口大小，下载速率提高到预定目标。 HUAWEI TECHNOLOGIES Co., Ltd.HUAWEI Confidential Page 34EVDO速率案例速率案例PDSN不支持不支持TCP/IP头压头压缩，导致下行速率受限缩，导致下行速率受限 【现象描述】在北京MTNET室内测试时，采用3Com的PDSN下载速率可以达到2M左右，且较平稳，但采用华为PDSN，只能在1.9M

59、到1.6M左右振荡，无法稳定传输。 【处理过程】下载时，空口情况良好，不存在误帧情况，前向稳定申请2.4M，通过iperf采用UDP发送测试，华为与3Com带宽一样，均达到2M，而且PDSN处理能力远大于单个终端。通过sniff观察数据包，无丢包现象，无错误断言。通过协议匹配分析以及RRI对比观察，发现采用3Com的PDSN，反向稳定在38.476.8k之间，而采用华为的PDSN在9.6k到76.8k之间振荡。可以分析得出：由于EVDO的反向速率自适应与TCP IP的慢启动协议正好产生振荡。仔细分析，反向华为不支持IP头压缩而3Com支持。将3Com的IP头压缩取消，测试结果与采用华为的PDS

60、N现象一致。将终端反向速率采用iperf提高到76.8k，稳定一段时间，同时采用TCP下载，当iperf终止传输时，TCP下载也能稳定在1.9M以上。 【结论】进行FTP下载时通过CAIT或者在BSC的调试台观察误码率是否大于1，空口是否有很多NAK帧。前向发送大量NAK帧说明反向业务信道误码过高，提高了反向业务信道发射功率可以减少反向误码，改善反向应答消息的解调成功率。这对数据业务（基于TCP/IP协议）很重要，所以可以改善前向数据速率。HUAWEI TECHNOLOGIES Co., Ltd.HUAWEI Confidential Page 35EVDO速率案例速率案例服务器服务器C盘空间