C-EVDORev.A经典案例.ppt

C-EVDO Rev.A经典案例,ISSUE 1.01,Page 2,了解1xEV-DO Rel0及DO RevA常见问题及其处理过程 掌握1xEV-DO Rel0及DO RevA的问题处理思路，测试方法，分析手段 通过案例的学习，尽快定位问题,学习完本课程，您将会：,目 标,Page 3,第1章 EVDO接入案例 第2章 EVDO掉话案例 第3章 EVDO速率案例 第4章 EVDO切换案例 第5章 EVDO其他案例,内容介绍,Page 4,EVDO接入问题分类及分析建议,影响EVDO接入的主要问题： 1、会话建立过程中配置协商失败 2、AN AAA/AAA鉴权失败 3、接入参数设置不合理 4、覆盖、容量问题 5、数据配置问题 6、单板异常、故障 分析建议： 1、为了减少不必要的流程，数据配置时应尽量使用协议规定的缺省值； 2、跟踪信令确认鉴权结果（如鉴权失败，需要进一步在AAA服务器上检 查用户信息） 3、常用接入参数优化 4、功率控制参数优化 5、检查业务,Page 5,EVDO接入问题分类及分析建议,Page 6,EVDO接入案例AN AAA鉴权,有时终端不主动发起接入鉴权，导致会话建立总是失败，这时使用QPST工具检查终端的设置。终端必须在1xEV界面配置了NAI和Password信息才会主动发起接入鉴权。 目前我司EVDO系统通过SMP软参可以关闭接入鉴权过程，以便于没有鉴权需求的展览和外部测试局点节约成本，但涉及双模切换项目时，为保证终端在EVDO系统获得正确的“IMSI”，必须提供AN-AAA并配置正确的IMSI。 通过对维护台上对A12接口的消息跟踪来对分析AN AAA的鉴权问题,Page 7,EVDO接入案例AcAck消息多次重发导致DO会话建立成功率低 （1）,【现象描述】 在DO会话建立过程中，发现大量因为HardwareIDResponse消息没有收到造成的会话建立失败，经过对比cait log和基站主控调试台的信令，发现cait上显示发出的HardwareIDResponse在基站并没有收到。 【处理过程】 1、 分析现场数据话统：从话统数据中，发现Session Setup Failure的主要原因是NoHardWareIDRspReceived和NoUATICompleteReceived。 2、 通过对比分析现场的配置数据和实验室镜像环境的开关状态，发现现场的BTS打开了异步消息重发开关，从CAIT的消息中也可以看到BTS对异步控制信道上的ACACK Message和HardwareIDRequest Message都进行了重发。打开测试环境的BTS的异步消息重发开关，此时出现了AT发送了HardwareIDResponse Message，而BTS未收到对应的这条消息的会话建立失败，因此推断异步消息的重发对会话建立成功率有很大的影响。,Page 8,EVDO接入案例AcAck消息多次重发导致DO会话建立成功率低（2）,3、将此问题提交给高通，高通给出如下答复： a) From the log, while AT is sending the 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 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次）。,Page 9,EVDO接入案例接入搜索窗设置问题导致终端无法接入 （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至-100dBm之间波动，发射电平在+13至+23dBm之间波动，C/I总小于-10db， 将终端拿到车外，进行OUTDOOR STATIONARY测试，发现终端无法接入AN。设置DM2K连续短呼，从掉话点沿原路返回，在信号质量比较好的地方也无法接入，直到距离靠近基站约15公里的地方才能正常接入，当时的接收电平在-79至-86dBm之间波动，发射电平在-2左右波动，C/I为3db左右。 【处理过程】 1、 通过DM2K测试数据的回放，查看15公里内的呼叫建立情况，发现信令流程正常，呼叫正常建立。但查看15公里之外的呼叫建立情况的时候，在手机发送ROUTE UPDATE和CONNECTION REQUEST消息后，空口无AN的应答和TCA信令，因此手机提高功率继续试探，仍无法接入。 2、 从BSC DEBUG调试台上跟踪信息，在15公里内呼叫的时候，DEBUG看到的信令正常。但是在15公里之外呼叫的时候，BSC没有收到手机的ROUTE UPDATE和CONNECTION REQUEST消息，说明问题出在BTS。 3、 查看是否有反向干扰，TELNET查看RSSI，长时间查看，结果该扇区的RSSI正常。,Page 10,EVDO接入案例接入搜索窗设置问题导致终端无法接入 （2）,4、 从空口看，15公里外呼叫的时候，信令已经发送了，由于信号情况良好，没有反向干扰，BTS应该是收到了消息，但是不能处理或处理错误。 5、 怀疑为反向接入搜索窗口的设置导致了基站不能处理手机上报消息，咨询相关开发人员，了解到该版本的反向接入搜索窗口算法存在问题，导致最大的接入半径为16公里。 6、 该版本的小区接入搜索窗口为128CHIPS，1CHIP相当于244米，因此128*244=31.2公里左右，由于是往返，所以为15.5公里左右，因此只能在约15公里的范围内接入。而反向业务搜索窗的半径是以手机上报位置为中心，以16公里为半径的范围。 该问题最终通过修改接入搜索窗口为512CHIPS（接入半径理论值为64公里），问题解决。 【建议】 基站的搜索窗口对覆盖的影响很大，反向的接入搜索窗口和业务搜索窗口要一致，如果两者不一致，将会导致在某些区域手机在接入过程中的接收信号显示良好，发射电平高的现象，与反向链路存在干扰问题现象类似，特别是在小区边缘，信号覆盖相对差一些的情况下，容易被误认为是反向干扰，建议在优化过程中加以关注。,Page 11,EVDO接入案例BECM单板问题导致EVDO终端无法接入,【现象描述】 某EVDO局BSC版本为BSC6600-OMCV200R001ENGC01B010，BTS版本为BTS3612-OMCV200R001ENGC01B011，在测试过程中，发现PN324扇区出现信号很好但是始终无法接入的现象，在该扇区的近点，C/I达到了12-15之间，DRC达到了2.4576M的地点进行测试，结果还是不能接入，而在之前对该扇区的测试中，没有发现类似的现象。 【处理过程】 1、由于前一天对该扇区的覆盖情况进行过测试，也进行过ACCESS和单用户吞吐量的相关测试，并没有出现过该问题。硬件安装没有变，软件上只是昨天进行了一次针对BSC的软件升级，复位了BSC。 2、使用DM2K进行空口消息跟踪，发现在AT发起呼叫后，向AN发送ROUTE 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 ASSIGNMENT消息被下到另外的扇区里了，手机接不到指配消息，所以无法接入。同时发现ROUTE UPDATE消息在经过BECM板处理后，增加消息头的时候发生错误，从而导致TCA消息下发的目标小区发生错误，导致呼叫建立失败。因此故障基本定位为该BECM板内部有问题导致了无法正常接入的现象。 【结论】 该问题基本定位为单板内部的软件问题导致，从现象看单板在系统复位后，单独对BECM板进行一次复位，之后就不会出现这种现象，否则，可能会出现该问题。规避方法每次系统复位后，对BECM单板进行复位，以规避该问题。,Page 12,EVDO接入案例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、在其他区域测试可以正常上网，确定并非整网问题，可以排除PCF上层的问题； 2、替换终端测试，现象依旧，排除终端问题，发生问题前终端一直使用正常，排除鉴权问题； 3、知会机房人员检查该基站告警，由于不是单个载频的问题，重点检查了信道板芯片和时钟板等的状态，并没有异常； 4、路测分析空口质量良好，各指标达到近点水平，但DRC一直维持在76.8kbps，终端侧的信令分析，会话建立流程没有完成，AT发送connectionrequest并没有收到TCA消息，而是收到CC（控制信道）下发的connectiondeny消息，原因值”network busy”以及”protocol error”，从而结束流程； 5、问题集中在AN侧为什么不能分配业务信道上以及为什么出现“协议错误”这样的错误，类似地，可能是空口、CE、地面链路资源有问题。在BSC侧继续进行用户接口跟踪，AT发的connectionrequest收到后，BSC直接释放abis链路，如图：,Page 13,EVDO接入案例1X与DO业务链路标识冲突导致DO无法上网（2）,6、用LST BTSLNK检查Abis链路配置，发现该基站一条1X链路和DO链路配置相同的业务链路标识”1-248-3”，问题找到了，该基站从S3/3/3扩容到S4/4/4时增加新的业务链路配置错误导致DO载频无法建立业务链路，DO无法上网。 7、维护台上LST BTSLNK检查，修改该基站的业务链路配置，测试DO业务恢复正常。 【结论】 这种链路配置错误在维护台上不会禁止执行，也不会引起告警，有一定的隐蔽性，OMC对abis的容错和性能监控方面应加强。,Page 14,第1章 EVDO接入案例 第2章 EVDO掉话案例 第3章 EVDO速率案例 第4章 EVDO切换案例 第5章 EVDO其他案例,内容介绍,Page 15,EVDO掉话问题分类及分析建议,导致EVDO掉话的主要问题： 1、覆盖不足 2、空口/传输误码 3、干扰 4、切换失败 分析建议： 1、路测、CQT测试，通过测试分析掉话原因； 2、收集话统数据及SPU日志，通过Nastar及OMStar分析掉话原因； 3、分析掉话用户的CDR数据 4、查看系统告警、基站单板告警、传输告警 5、查看RSSI异常情况 6、PN的检查及优化 7、邻区检查及优化,Page 16,EVDO掉话案例强分支加不进来引发的连接释放 （1）,【现象描述】 问题现象特征： a. 上层数据速率为0。DRC很差，PER很高。 b. 激活集PN80的EcIo较差，候选集分支PN96强度为-2.5dB，但是不能够加入激活集。 【处理过程】 对CAIT数据的回放 疑问：为什么PN96无法加到激活集？ 无线场景分析 激活集分支PN80的信号越来越差，相邻集分支PN96的信号越来越好；但是不能够成功切换，导致掉话。,Page 17,EVDO掉话案例强分支加不进来引发的连接释放 （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，就增加这个分支。 安全起见，该修改用软参控制，开关可控。 CCM周期的向AT下发ResetReport消息，强制触发AT上报RU。安全起见，该修改用软参控制，开关可控。 【结论】 由于AT的行为，在未达到T_ADD门限就上报RU。而系统未作处理。当达到T_ADD门限时，AT又不上报RU，同样未得到系统处理。导致较强的分支没有及时被加入，而作为较强的干扰致使AT的连接断连。在增加算法的兼容性后问题解决。,Page 18,第1章 EVDO接入案例 第2章 EVDO掉话案例 第3章 EVDO速率案例 第4章 EVDO切换案例 第5章 EVDO其他案例,内容介绍,Page 19,EVDO速率问题分类及分析建议,影响EVDO前反向速率的主要因素： 1、无线覆盖（C/I差，Tx高） 2、带宽不足（CE不足、E1不足、业务链路带宽配置不足、PVC带宽不足、PDSN与PCF带宽不足） 3、误码及重传（空口误码、传输误码） 4、频繁切换 5、终端及系统设置问题 分析建议： 1、路测、CQT测试，通过测试分析掉话原因； 2、从空口开始逐层检查业务带宽瓶颈（见下一页图）； 3、通过ping命令、iperf工具在FMR、PCF上进行上下行时延及带宽测试； 4、查看系统告警、基站单板告警 5、检查终端设置是否正确（包括与终端相连的便携机TCP窗口设置）； 6、检查FTP服务器设置是否正确 7、检查设备的配置数据（如是否固定了用户下行最大速率） 8、避免频繁切换,Page 20,EVDO速率问题分类及分析建议,分析DO下行速率过低，根据木桶最短板原理，应该从底层开始，一层层分析判断受限点，定位原因并解决。 一般，我们采用cait定位无线链路状况，采用ping命令、iperf定位有线侧链路状态。,Page 21,EVDO速率案例反向功控参数设置不合理导致的下载速率低,【现象描述】 北京3G技术实验测试期间，发现定点的FTP下载速率总是不能稳定在2Mbps上。 【处理过程】 通过CAIT观察发现空口上前向经常有突发的NAK帧。在总部的外场观测，发现同样现象，通过调整BSC的反向功控参数，抬升终端发射功率后，突发NAK帧的情况消失，FTP下载速率趋于稳定在2Mbps以上。 【结论】 进行FTP下载时通过CAIT或者在BSC的调试台观察误码率是否大于1，空口是否有很多NAK帧。前向发送大量NAK帧说明反向业务信道误码过高，提高了反向业务信道发射功率可以减少反向误码，改善反向应答消息的解调成功率。这对数据业务（基于TCP/IP协议）很重要，所以可以改善前向数据速率。,Page 22,EVDO速率案例链路带宽受限导致的DO下行速率过低,【现象描述】 在梧州联通测试下载时，空口情况良好，不存在误帧情况，前向稳定申请2.4M，采用ftp下载，速率在1.8M到1.4M间振荡，平均值无法突破1.6M，而理论分析，ftp下载应该达到2M以上。 【处理过程】 通过iperf采用UDP发送测试，全链路带宽稳定在1.6M左右。通过分析，与2M的PVC带宽有关，由于PVC效率在80左右，正好1.6带宽 。 【结论】 通过调整DO的HAC，BPU，PPU，FMR之间的PVC带宽到4M，采用UDP下载速率突破了2M。,Page 23,EVDO速率案例E1数目不足和业务链路配置错误造成EV-DO数据业务下载速率低 （1）,【现象描述】 M国EV-DO网络在完成所有安装和配置之后，测试时单用户使用EV-DO FTP下载业务的平均速率只有700800Kbps，使用内部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也是不合理的。给测试基站再加一条E1后，单用户平均下载速率可以达到1.5 Mbps。而根据经验，配置2条E1后，单用户平均下载速率应该超过1.9Mbps，问题仍然没有解决。 4、在配置2条E1后，用iperf测试从PDSN到PCF和从PDSN到MS的实际物理带宽。测试结果为：PDSN和PCF之间的带宽约为73M，属于正常值；而PDSN和AT之间的带宽只有1.5M。,Page 24,EVDO速率案例E1数目不足和业务链路配置错误造成EV-DO数据业务下载速率低 （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协议窗口配置、物理链路配置、业务链路数等几个方面去查找原因。,Page 25,EVDO速率案例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.通过无线资源监控命令DSP 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. 通过现场基站维护工程师的检修，另一条E1工作恢复正常（据说是接口松动）；再进行测试，平均速率在1.8Mbps左右，瞬时最高速率达到2M以上。问题得到解决。 【结论】 基站开通后，对EVDO来说，单站的拨测不能只看是否能传输数据，应该同时关注实际传输速率，在对应的无线环境和配置下是否正常。,Page 26,EVDO速率案例复杂组网下，中间链路问题导致下行速率受限 （1）,【现象描述】 广西南宁EVDO实验局，通过FTP下载发现数据业务的下行速率很低，不到1Kbps，网页打不开。 【处理过程】 1、检查便携和终端设置正常。 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配合有问题，导致包被大量丢弃，速率超低。,Page 27,EVDO速率案例复杂组网下，中间链路问题导致下行速率受限（2）,5、修改PDSN的SYS_MTU值为1400后，速率达到1.3M。由于1.3Mbps的速率仍然远低于正常值，怀疑传输上仍然存在问题。 6、联系数通的技术支持人员检查后发现一台2631未接地，在路由器上有明显丢包。接地后，速率达到1.7Mbps。 7、此时离理想数值仍有差距，通过netpersec观察，速率上不去在于每次下载10M文件过程中至少有一次大幅抖动，丢包很明显。固定反向速率情况依旧。已确认空口质量没有问题，利用带宽测试工具通过UDP测试从分组域到终端的下行带宽，发现能达到2M以上。 8、检查PDSN和服务器侧没有问题，BSC配置也看不出什么问题。最后又回到了路由器上，经过工程师现场定位发现南宁和梧州两个路由器间的4对E1有1对E1自环上了，导致下载过程中速率抖动很大。修正后，速率稳定，能够达到2.1M，经最后在国际会展中心地下室机房信号最强的地方测试，速率达到2.2M，峰值2.4M。 【结论】 此案例中有PDSN设置问题（最大包长问题），也有工程安装问题（接地和自环），比较典型。,Page 28,EVDO速率案例传输误码率高造成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左右，所以排除PDSN设备及A10、A11接口问题； 3.由于基站B下行速率达到2.3M，所以排除BSC内部框间连接及数据问题； 4.DRC申请的速率基本都是2.4Mbps，这就说明空口质量非常好； 5.检查基站ABIS口信令链路及维护链路带宽为110K，业务链路带宽为3.2M，所以配置PVC带宽正常； 6.终端侧的TCP窗口的大小对速率也有很大的影响，于是检查TCP的设置参数：TcpWindowSize 0x0000ffff(WINDOWS XP) 排除了终端这边的设置问题；,Page 29,EVDO速率案例传输误码率高造成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 = 103, 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 = 124, 问题定位到ABIS口数据及硬件，检查ABIS数据正常。 检查对应ABIS接口传输设备，发现从BSC侧DDF架到光传输之间、及BTS侧DDF架到光传输之间均未接地，在安装规范中要求光传输设备的输入、输出必须单端接地，否则将会产生相应的误码； 8. 在光传输设备的维护台上早已有传输误码告警，但由于原来该光传输是使用于GSM基站的ABIS接口，虽然传输的误码产生一定的话音质量差，但由于语音的误码要求(1E-4)较EVDO传输误码(1E-6)小，所以客户也未深究。但对于EVDO这样数据传输时，光传输设备的误码直接造成下行速率下降；在DDF架进行相应接地后，测试业务下行速率达到2.2M（三星手机）。 【结论】 1、分析DO下行速率过低，根据木桶最短板原理，应该从底层开始，一层层分析判断受限点，定位原因并解决. 2、由于数据业务在传输通道中误码率及时钟同步要求比语音业务高，所以在EVDO设备开局时注意系统时钟的同步及精度。,Page 30,EVDO速率案例EC板缓存太大导致频繁切换时DO Rev.A终端掉零,【现象描述】 使用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，将错误遗留到上层TCP层后，引发TCP的惩罚机制，导致速率降为0。 3、EC板的缓存默认设置为32760byte，在大部分情况下切换是没有问题的，但对于频繁切换情况，由于产品的实现机制，在切换前需要清空原缓存，导致大量的数据靠上层的重传来保证，大量的数据如果在AT的RLP定时器超时之前来不及重传，则会产生大量的RLP Abort，传递到上层TCP层，从而导致掉零；但如果设置EC板的缓存值太小，由于拥塞控制机制，将会导致单用户下载情况下速率达不到理论值。 【结论】 EC板缓存为代码写死参数，无维护台命令可修改。通过多次测试发现设置EC板缓存为14000byte时，频繁切换导致掉零问题和下载速率低问题都可以得到解决。但由于网络的差异，不一定适合其它地方，对于特定的网络，需要测试验证。,Page 31,EVDO速率案例FMR缓冲区不够导致频繁切换时DO Rel.0终端掉零,【现象描述】 使用AnyDATA终端（协商为DO Rel.0模式）进行路测，在切换带内，经常出现速率掉零，且长时间无法自动恢复，需要手动重启FTP下载后，下载才能恢复正常。 【处理过程】 1、对比该时段前后Cait log，发现在GPS时间15:44:06.203时，AT发送了连续发送了两条反向RLP消息，空洞长度分别为31842和25668字节，这样的大空洞是导致速率掉零的直接原因。 2、回放Cait数据，在上述大片空洞产生之前都发生了虚拟软切换 3、分析FMR调试台打印也可以看到，这段时间内切换很频繁，开始的时候是0号分支作为主分支。当2号分支发起Req时，基站缓冲区被清除，此时可以看到基站缓冲区数据量很大，几乎是满的。另外刚切换到2号分支，就发现2号分支连续几秒钟收到的反向帧都是误帧。此时处于无主分支状态。基站又清除缓冲区，在这540ms内有损失了200多个前向包和200多个重传包。 4、基站上报的从空口发出去的FrameID和FMR发给BTS的FrameID相差很大。在虚拟软切换时，基站会清空发送缓冲区，基站的缓冲区设定是32760字节，相当于263个RLP包，而FMR只会记录已发给BTS的10个包记录，当基站大量数据被清除时，要求传输的数据在FMR中找不到（基站刚把缓冲区填满，就发生了虚拟软切换），此时会在AT的RLP层产生一个大小为200多个包的空洞，只能依靠于TCP层的重传，这会导致很大的速率波谷。 【结论】BTS EC板缓存与FMR的记录相差太大是频繁切换时DO Rel.0路测掉零的根本原因。 目前产品不支持命令修改，BSC版本V2R3C03B012最近版本已经把记录数写死为270。,Page 32,EVDO速率案例HAC板不稳定问题导致的DO用户前反向速率出现周期性大的波动,【现象描述】 某EVDO局BSC版本为BSC6600-OMCV200R001ENGC01B010，BTS版本为BTS3612-OMCV200R001ENGC01B011。 EVDO的FTP下载传输速率很不稳定，在基站附近，信号质量很好，DRC为2.4576M和C/I为11-13的时候，单用户的下载传输速率一般在30kBps到130kBps间，波动很大，上传速率也出现类似的波动。 【处理过程】 1、由于本次测试使用的是局方的PDSN设备和FTP server，而局方的该设备之前一直运行正常，所以可以先排除 PDSN和FTP服务器的问题。 2、对硬件安装情况进行检查，设备安装质量无问题，之后重新制作网线，逐步更换我们的LAN SWITCH和局方PDSN 和我司PCF之间的连接网线，每次拨号测试，故障仍存在，检查BTS的E1状态，正常无告警。 3、据中研反馈，这种高通的手机由于存在下载半小时以上就会断掉业务的问题，并且该问题当时已经和高通确认。 但是现场的主要问题是速率的波动和平均速率低，和描述现象不是很一致。 4、检查数据配置，没有发现问题，重新安装BAM，复位，发现FTP下载速率最大可以达到180kBps左右，但存在周 期性的大波谷。 5、怀疑带宽的限制造成该问题，尝试修改系统PVC带宽后复位，发现波动更频繁，性能比之前还要差。由于速率 十分不稳定，修改回原始带宽复位，速率变为波动从0297kBps之间，更加不稳定，不能恢复原来的相对稳定 状态。 6、由于多次复位系统后，每次速率变化都不太一样，数据没有变化（带宽数据已经改回），因此怀疑系统的软件 或硬件部分存在不稳定的因素，想起HAC板几日来随机出现几次GE口告警，更换BSC的HAC板，重新测试，平均 吞吐量可以达到近点200kBps左右，反向吞吐量也可稳定达到126kbps，问题解决。 【结论】 在处理问题的时候要关注告警信息，特别是新产品，出现的问题有的时候会比较多，很难定位，告警是比较重要的定位信息。,Page 33,EVDO速率案例由于便携机TCP接收窗及FTP服务器TCP发送窗口太小，导致下行速率过低,【现象描述】 在外场测试时，DO的下载速率只有1M左右。 【处理过程】 1、下载时，空口情况良好，不存在误帧情况，前向稳定申请2.4M，通过iperf采用UDP发送测试，前向全链路带宽确实达到2M。但FTP下载速率只有1M左右，且较稳定，说明ftp进入稳定状态，与TCP的慢启动无关。采用多进程下载能显著提高下载速率， 2、检查便携注册表的TcpWindowSize设置。Tcp窗口大小取8k字节的整数倍，并需要保证TcpWindowSize = 双向时延速率，一般设置为64000Byte。例如建立拨号连接后从便携ping网络侧服务器，如果往返时延是200ms，期望FTP下载速率为2Mbps，那么TcpWindowSize 0.2*2000000/8 = 50000字节，则比较合适的取值就是最近的64000字节。若是WinXP，还需检查注册表中DefaultRcvWindow；此值需要设置为65535，以保证便携接收缓冲区足够大。 3、分析表明，稳定时，ftp速率与带宽、延时以及发送接收窗大小相关。 4、经检查TCP接收窗大小为8k，可能存在瓶颈问题。 5、同理检查并调整FTP服务器TCP发送窗口大小。 【结论】 通过调整窗便携机TCP接收窗大小及FTP服务器TCP发送窗口大小，下载速率提高到预定目标。,Page 34,EVDO速率案例PDSN不支持TCP/IP头压缩，导致下行速率受限,【现象描述】 在北京MTNET室内测试时，采用3Com的PDSN下载速率可以达到2M左右，且较平稳，但采用华为PDSN，只能在1.9M到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头压缩取消，测试结果与采用华为的PDSN现象一致。将终端反向速率采用iperf提高到76.8k，稳定一段时间，同时采用TCP下载，当iperf终止传输时，TCP下载也能稳定在1.9M以上。 【结论】 进行FTP下载时通过CAIT或者在BSC的调试台观察误码率是否大于1，空口是否有很多NAK帧。前向发送大量NAK帧说明反向业务信道误码过高，提高了反向业务信道发射功率可以减少反向误码，改善反向应答消息的解调成功率。这对数据业务（基于TCP/IP协议）很重要，所以可以改善前向数据速率。,Page 35,EVDO速率案例服务器C盘空间不够导致EVDO下行速率低 （1）,【现象描述】 某试验EVDO局点，EVDO站开起来，经过多次测试调整，EVDO下载速率约为800K，速率上不去，当时C/I7，ABIS带宽3.1M，搜索窗65000。 【处理过程】 空口质量很好，不存在问题； 确保了测试终端、测试电脑设置无误； 检测设备： 1、 检查PVC带宽，站点的PVC带宽为4M，这已经够用，排除此原因； 2、 检查BTS E1工作及带宽是否足够，单个扇区共用了2两E1专给该扇区用于DO使用，而且工作正常，排除此原因； 3、 因为用于测试使用，网络没有AAA模块，呼叫不需要进行鉴权，分析整个呼叫信令流程未能发现异常情况； 4、 对服务器PC建立的ftp相关参数进行检查，检查相关参数后未能发现异常情况，在处理过程中，在外路测DO的时候（一直下载大文件），有时候会出现下载停顿的情况；给路测人员的感觉是，此情况与单PC在工作时出现内存不够的情形差不多；因此怀疑测试ftp服务器的内存配置问题；可ftp服务器的内存条配置2G左右，应该够用；,Page 36,EVDO速率案例服务器C盘空间不够导致EVDO下行速率低 （2）,5、 无意间，用磁盘管理功能查看硬盘分区情况，系统自动告警说C盘硬盘空间不够；细查C盘空间，发现C盘剩余空间为0，删除C盘下的大量用于测试使用的多媒体文件，保留2G多的剩余空间。DO下载速率明显上升，单用户下载可以稳定处于2M左右。问题获得解决。 【结论】 1. 实际项目中，一些很细节的问题都有可能导致网络质量提升问题，如本案例因为ftp服务器C盘空间不够引起下载速率过低，一开始并没能引起大家的注意； 2. 很多网络问题，在想办法排除故障的时候，往往一开始想到的就是复杂的技术问题，而忽略了小问题所带来的影响； 3. 一些项目现场，管理等相关制度不完善，或者是制度执行不理想。导致出现了些不该出现的问题。如此案例，在现场几乎任何一个人都可以在ftp服务上拷贝操作，最后导致C盘磁盘空间满了也不通知相关人员。,Page 37,EVDO速率案例EV-DO QoS速率权重设置错误导致VOD视频播放速率较低达不到理想的效果（1）,【现象描述】 某局点对BSC6600,BTS3606、PDSN升级后利用三星E159手机拨号后进入VOD视频点播网站进行视频播放，通过速度测试软件测试的播放速率只有580Kbps，而升级前稳定为1.4Mbps。现场版本：BSC6600V200R003C02B014(061110)，BTS3606-0R001ENGC04B01520061110),PDSN9660V800R105C01B011, 组网：1个BSC6600、1个BTS3606、1个PDSN、1业软的流媒体服务器。 【处理过程】 1、检查EV-DO基站的业务链路带宽，分配给DO的物理E1为两条业务链路。带宽设置没有问题； 2、检查便携机参数设置，TCP窗口、IP头压缩等设置的均没有问题； 3、由于只用一个手机连接到便携机上进行测试，所以不可能是由于用户数过多引起的速率下降； 4、手机上信号满格，并且测试手机就在离基站不到5米的地方，排除了无线环境差的原因； 5、检查BSC参数设置：检查TCP优化开关LST MAPARA，将TCP优化开关关闭后测试速率依然为580Kbps， 排除此开关的影响； 6、检查脚本中的其他软参 ，也没有问题。,Page 38,EVDO速率案例EV-DO QoS速率权重设置错误导致VOD视频播放速率较低达不到理想的效果（2）,7、考虑到EV-DO可以针对同一个载频下无线环境相似的不同等级用户的数据业务呼叫前向平均传输 速率，是不是这个速率设置的过小而影响到整个前向速率呢？ 首先使用LST DOGP查询EV-DO全局参数，查询BSC已经打开了QoS开关； 使用命令LST DOQOS: GRADE=GOLD;查询金牌用户的前向速率限制为585.6Kbps（GRADEFWDLMTRATE=FRATE5856） 使用命令MOD DOQOS: GRADE=GOLD, GRADEFWDLMTRATE=FRATE23424;将速率修改为2342.4后测 试，VOD播放速率正常。 【结论】 涉及到EV-DO的参数设置很多，希望大家在考虑正常数据配置问题的情况下，多检查一下系统的参数配置。,Page 39,EVDO切换案例框间链路未配置导致EVDO切换失败（1）,【现象描述】 B国某CDMA450M EV-DO局点，反馈在配置反向搜索窗24chips基站和96chips基站之间EV-DO软切换失败，现象为速率陡降或者连接中断。现场BSS版本为V200R001C02B018，S3/3/3组网，2个1X频点1个EV-DO频点。 【处理过程】 导致EV-DO切换失败或者速率陡降的原因有： 漏配EV-DO邻区； BSC间切换区域； 导频污染。 通过现场反馈BAM数据分析，发现邻区漏配，进一步通过打开EV-DO邻区漏配检测开关和BSC Runlog邻区漏配记录软参，通过CBSSSTAR分析Runlog文件，检测出漏配邻区，反馈现场添加。具体命令如下： 1、MOD DORRMMP: DETECMISSPILOTSWITCH=ON;打开邻区漏配检测功能开关，此开关V1R3默认关闭，V2R1/V2R2默认打开。 2、MOD SOFTPARA: SRVMN=RRM, PRMNO=50, PRMV=“0x1“;打开写日志开关，邻区漏配检测的结果就会被写入到SPU日志中，然后用工具进行分析后输出邻区脚本（与1X邻区形式一致）。 （注意上述0x1指的是将RRM第50号软参的bit0的值，由默认值0修改为1，请使用LST SOFTPARA命令首先查询该软参设置值，然后将bit0设为1）。,Page 40,EVDO速率案例框间链路未配置导致EVDO切换失败 （2）,增加邻区后，测试结果表明部分切换成功，但还有很多切换失败。 让现场反馈最新BAM数据，通过工程辅助系统还原检查系统参数配置，发现现场配置有两个EV-DO框，但框间未配置软切换链路，进一步发现测试区域基站分布在两个EV-DO框里，通知现场配置EV-DO框间链路，测试结果表明EV-DO切换正常，问题得到解决。 【结论】 BSC配置有多个EV-DO框，框间也需要配置软切换链路。 EV-DO切换失败很多原因跟邻区漏配有关，要充分利用CBSSSTAR邻区漏配检测功能发现漏配邻区。,Page 41,第1章 EVDO接入案例 第2章 EVDO掉话案例 第3章 EVDO速率案例 第4章 EVDO切换案例 第5章 EVDO其他案例,内容介绍,Page 42,EVDO切换问题分类及分析建议,影响EVDO切换的主要因素： 1、邻区关系 2、切换参数 3、资源容量 4、终端及产品问题 分析建议： 1、通过路测分析掉话原因； 2、路测的同时在维护台进行空口信令跟踪，检查切换流程； 3、检查邻区（漏配、优先级不合理） 4、检查搜索窗大小（激活集、候选集、相邻集） 5、检查切换门限（PILOTADD、PILOTCMP、PILOTDROP、PILOTDROPTIMER ，） 6、检查设备告警 7、分析话统数据,Page 43,EVD