C-EVDORev.A经典案例.ppt

C-EVDORev.A经典案例,ISSUE1.01,Page2,了解1xEV-DORel0及DORevA常见问题及其处理过程掌握1xEV-DORel0及DORevA的问题处理思路，测试方法，分析手段通过案例的学习，尽快定位问题,学习完本课程，您将会：,目标,Page3,第1章EVDO接入案例第2章EVDO掉话案例第3章EVDO速率案例第4章EVDO切换案例第5章EVDO其他案例,内容介绍,Page4,EVDO接入问题分类及分析建议,影响EVDO接入的主要问题：1、会话建立过程中配置协商失败2、ANAAA/AAA鉴权失败3、接入参数设置不合理4、覆盖、容量问题5、数据配置问题6、单板异常、故障分析建议：1、为了减少不必要的流程，数据配置时应尽量使用协议规定的缺省值；2、跟踪信令确认鉴权结果（如鉴权失败，需要进一步在AAA服务器上检查用户信息）3、常用接入参数优化4、功率控制参数优化5、检查业务,Page5,EVDO接入问题分类及分析建议,Page6,EVDO接入案例ANAAA鉴权,有时终端不主动发起接入鉴权，导致会话建立总是失败，这时使用QPST工具检查终端的设置。终端必须在1xEV界面配置了NAI和Password信息才会主动发起接入鉴权。目前我司EVDO系统通过SMP软参可以关闭接入鉴权过程，以便于没有鉴权需求的展览和外部测试局点节约成本，但涉及双模切换项目时，为保证终端在EVDO系统获得正确的“IMSI”，必须提供AN-AAA并配置正确的IMSI。通过对维护台上对A12接口的消息跟踪来对分析ANAAA的鉴权问题,Page7,EVDO接入案例AcAck消息多次重发导致DO会话建立成功率低（1）,【现象描述】在DO会话建立过程中，发现大量因为HardwareIDResponse消息没有收到造成的会话建立失败，经过对比caitlog和基站主控调试台的信令，发现cait上显示发出的HardwareIDResponse在基站并没有收到。【处理过程】1、分析现场数据话统：从话统数据中，发现SessionSetupFailure的主要原因是NoHardWareIDRspReceived和NoUATICompleteReceived。2、通过对比分析现场的配置数据和实验室镜像环境的开关状态，发现现场的BTS打开了异步消息重发开关，从CAIT的消息中也可以看到BTS对异步控制信道上的ACACKMessage和HardwareIDRequestMessage都进行了重发。打开测试环境的BTS的异步消息重发开关，此时出现了AT发送了HardwareIDResponseMessage，而BTS未收到对应的这条消息的会话建立失败，因此推断异步消息的重发对会话建立成功率有很大的影响。,Page8,EVDO接入案例AcAck消息多次重发导致DO会话建立成功率低（2）,3、将此问题提交给高通，高通给出如下答复：a)Fromthelog,whileATissendingtheACMACcapsule,ANsendstheACAcktoterminatethesending.ANshouldnotdothat,ifANdoesnotreceiveanyACMACcapsules.ACmessageprintedoutinLogmeansACmessagehasbeenpacketedandreadytobesent.itdoesnotmeanthismassagehasbeensentout.b)Aswediscussed,AnshouldsendACAckwhilerecievingaccessMACcapsule.Accordingtostandard,oneACAckiscorrespondingtodedicatedoneaccessMACcapsule.ANshouldnotsendmorethanoneACAckforoneaccessMACcapsule.【结论】打开控制信道异步消息重发开关后，要将AcAck消息重发次数设置为0（默认值是2，既重发3次）。,Page9,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，将终端拿到车外，进行OUTDOORSTATIONARY测试，发现终端无法接入AN。设置DM2K连续短呼，从掉话点沿原路返回，在信号质量比较好的地方也无法接入，直到距离靠近基站约15公里的地方才能正常接入，当时的接收电平在-79至-86dBm之间波动，发射电平在-2左右波动，C/I为3db左右。【处理过程】1、通过DM2K测试数据的回放，查看15公里内的呼叫建立情况，发现信令流程正常，呼叫正常建立。但查看15公里之外的呼叫建立情况的时候，在手机发送ROUTEUPDATE和CONNECTIONREQUEST消息后，空口无AN的应答和TCA信令，因此手机提高功率继续试探，仍无法接入。2、从BSCDEBUG调试台上跟踪信息，在15公里内呼叫的时候，DEBUG看到的信令正常。但是在15公里之外呼叫的时候，BSC没有收到手机的ROUTEUPDATE和CONNECTIONREQUEST消息，说明问题出在BTS。3、查看是否有反向干扰，TELNET查看RSSI，长时间查看，结果该扇区的RSSI正常。,Page10,EVDO接入案例接入搜索窗设置问题导致终端无法接入（2）,4、从空口看，15公里外呼叫的时候，信令已经发送了，由于信号情况良好，没有反向干扰，BTS应该是收到了消息，但是不能处理或处理错误。5、怀疑为反向接入搜索窗口的设置导致了基站不能处理手机上报消息，咨询相关开发人员，了解到该版本的反向接入搜索窗口算法存在问题，导致最大的接入半径为16公里。6、该版本的小区接入搜索窗口为128CHIPS，1CHIP相当于244米，因此128*244=31.2公里左右，由于是往返，所以为15.5公里左右，因此只能在约15公里的范围内接入。而反向业务搜索窗的半径是以手机上报位置为中心，以16公里为半径的范围。该问题最终通过修改接入搜索窗口为512CHIPS（接入半径理论值为64公里），问题解决。【建议】基站的搜索窗口对覆盖的影响很大，反向的接入搜索窗口和业务搜索窗口要一致，如果两者不一致，将会导致在某些区域手机在接入过程中的接收信号显示良好，发射电平高的现象，与反向链路存在干扰问题现象类似，特别是在小区边缘，信号覆盖相对差一些的情况下，容易被误认为是反向干扰，建议在优化过程中加以关注。,Page11,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发送ROUTEUPDATE和CONNECTIONREQUEST，但是AN侧对消息没有响应，没有相应的ACACK和TRAFFICCHANNELASSIGNMENT消息，因此无法接入。3、在调试台上跟踪SPU，收到MS上报的接入请求，之后前向进行业务指配，发TRAFFICCHANNELASSIGNMENT给MS,然而手机却没有收TRAFFICCHANNELASSINMENT消息，这一点在DM2K的测试过程中从信令可以看出。因此怀疑消息在经过BTS处理的时候发生了错误。4、在BTS侧也进行ABIS口的跟踪，得到的结果显示BSC下发的TRAFFICCHANNELASSIGNMENT消息被下到另外的扇区里了，手机接不到指配消息，所以无法接入。同时发现ROUTEUPDATE消息在经过BECM板处理后，增加消息头的时候发生错误，从而导致TCA消息下发的目标小区发生错误，导致呼叫建立失败。因此故障基本定位为该BECM板内部有问题导致了无法正常接入的现象。【结论】该问题基本定位为单板内部的软件问题导致，从现象看单板在系统复位后，单独对BECM板进行一次复位，之后就不会出现这种现象，否则，可能会出现该问题。规避方法每次系统复位后，对BECM单板进行复位，以规避该问题。,Page12,EVDO接入案例1X与DO业务链路标识冲突导致DO无法上网（1）,【现象描述】N国S局CDMA1xEVDO1900网络，1PDSN/1PCF/1AN/16BTS/48carrier，使用频点613，S4/4/4配置，其中S3/3/3for1X，S1/1/1forDO。路测到某基站A（升级网方式的DO基站）掉话，之后在该基站三个扇区下始终无法建立PPP连接。该基站当前没有任何未恢复告警。BSC版本V200R001C02B018【处理过程】1、在其他区域测试可以正常上网，确定并非整网问题，可以排除PCF上层的问题；2、替换终端测试，现象依旧，排除终端问题，发生问题前终端一直使用正常，排除鉴权问题；3、知会机房人员检查该基站告警，由于不是单个载频的问题，重点检查了信道板芯片和时钟板等的状态，并没有异常；4、路测分析空口质量良好，各指标达到近点水平，但DRC一直维持在76.8kbps，终端侧的信令分析，会话建立流程没有完成，AT发送connectionrequest并没有收到TCA消息，而是收到CC（控制信道）下发的connectiondeny消息，原因值”networkbusy”以及”protocolerror”，从而结束流程；5、问题集中在AN侧为什么不能分配业务信道上以及为什么出现“协议错误”这样的错误，类似地，可能是空口、CE、地面链路资源有问题。在BSC侧继续进行用户接口跟踪，AT发的connectionrequest收到后，BSC直接释放abis链路，如图：,Page13,EVDO接入案例1X与DO业务链路标识冲突导致DO无法上网（2）,6、用LSTBTSLNK检查Abis链路配置，发现该基站一条1X链路和DO链路配置相同的业务链路标识”1-248-3”，问题找到了，该基站从S3/3/3扩容到S4/4/4时增加新的业务链路配置错误导致DO载频无法建立业务链路，DO无法上网。7、维护台上LSTBTSLNK检查，修改该基站的业务链路配置，测试DO业务恢复正常。【结论】这种链路配置错误在维护台上不会禁止执行，也不会引起告警，有一定的隐蔽性，OMC对abis的容错和性能监控方面应加强。,Page14,第1章EVDO接入案例第2章EVDO掉话案例第3章EVDO速率案例第4章EVDO切换案例第5章EVDO其他案例,内容介绍,Page15,EVDO掉话问题分类及分析建议,导致EVDO掉话的主要问题：1、覆盖不足2、空口/传输误码3、干扰4、切换失败分析建议：1、路测、CQT测试，通过测试分析掉话原因；2、收集话统数据及SPU日志，通过Nastar及OMStar分析掉话原因；3、分析掉话用户的CDR数据4、查看系统告警、基站单板告警、传输告警5、查看RSSI异常情况6、PN的检查及优化7、邻区检查及优化,Page16,EVDO掉话案例强分支加不进来引发的连接释放（1）,【现象描述】问题现象特征：a.上层数据速率为0。DRC很差，PER很高。b.激活集PN80的EcIo较差，候选集分支PN96强度为-2.5dB，但是不能够加入激活集。【处理过程】对CAIT数据的回放疑问：为什么PN96无法加到激活集？无线场景分析激活集分支PN80的信号越来越差，相邻集分支PN96的信号越来越好；但是不能够成功切换，导致掉话。,Page17,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的连接断连。在增加算法的兼容性后问题解决。,Page18,第1章EVDO接入案例第2章EVDO掉话案例第3章EVDO速率案例第4章EVDO切换案例第5章EVDO其他案例,内容介绍,Page19,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、避免频繁切换,Page20,EVDO速率问题分类及分析建议,分析DO下行速率过低，根据木桶最短板原理，应该从底层开始，一层层分析判断受限点，定位原因并解决。一般，我们采用cait定位无线链路状况，采用ping命令、iperf定位有线侧链路状态。,Page21,EVDO速率案例反向功控参数设置不合理导致的下载速率低,【现象描述】北京3G技术实验测试期间，发现定点的FTP下载速率总是不能稳定在2Mbps上。【处理过程】通过CAIT观察发现空口上前向经常有突发的NAK帧。在总部的外场观测，发现同样现象，通过调整BSC的反向功控参数，抬升终端发射功率后，突发NAK帧的情况消失，FTP下载速率趋于稳定在2Mbps以上。【结论】进行FTP下载时通过CAIT或者在BSC的调试台观察误码率是否大于1，空口是否有很多NAK帧。前向发送大量NAK帧说明反向业务信道误码过高，提高了反向业务信道发射功率可以减少反向误码，改善反向应答消息的解调成功率。这对数据业务（基于TCP/IP协议）很重要，所以可以改善前向数据速率。,Page22,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。,Page23,EVDO速率案例E1数目不足和业务链路配置错误造成EV-DO数据业务下载速率低（1）,【现象描述】M国EV-DO网络在完成所有安装和配置之后，测试时单用户使用EV-DOFTP下载业务的平均速率只有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.5Mbps。而根据经验，配置2条E1后，单用户平均下载速率应该超过1.9Mbps，问题仍然没有解决。4、在配置2条E1后，用iperf测试从PDSN到PCF和从PDSN到MS的实际物理带宽。测试结果为：PDSN和PCF之间的带宽约为73M，属于正常值；而PDSN和AT之间的带宽只有1.5M。,Page24,EVDO速率案例E1数目不足和业务链路配置错误造成EV-DO数据业务下载速率低（2）,5、检查BSC的带宽配置。用命令LSTBTSLNK查询BIE板和BTS间的带宽设置，用命令LSTALPATH查询BIE板和FMR板间的带宽设置，在这一步终于发现了问题：之前为每个EV-DO基站配置了2条业务链路，但是每个EV-DO基站只配置了一块EC板。因此是E1数目不足和业务链路配置错误造成EV-DO数据业务下载速率低。在BSC和BTS侧都删除一条业务链路后，单用户平均下载速率终于到达了2.0Mbps，问题得到解决。【结论】遇到EV-DO数据业务下载速率低的问题时，一般都可以从空口质量、服务器的TCP/IP协议窗口配置、物理链路配置、业务链路数等几个方面去查找原因。,Page25,EVDO速率案例IMA组中一条E1未工作导致EVDO下行速率较低,【现象描述】P国Z局CDMA4501X网络，某基站，站型S222，1X和EVDO各一载波，E1配置：1X一条E1，UNI方式；DO两条E1，IMA方式。进行EVDO前向空载速率测试，近站处无切换，C/I在10dB左右跳动，申请DRC为1.8-2.4Mbps，进行FTP下载，速率平均在1M左右，最高只有1.4Mbps。【处理过程】采用逐步排查进行分析：1.通过无线资源监控命令DSPDORADIORESINDICATION查看该站资源使用情况，测试扇区Active用户数为1，其他扇区无用户；并通过DSPBTSFLUS命令确认前向没有FLUS加载；排除了多用户和FLUS加载的影响;2.检查TCP参数，MTU为1500，TCP窗口为640000，没有问题；3.查看Abis传输业务带宽和PVC带宽，分别配置为3.6M（IMA方式，两条E1）和6M，依然没有有问题；4.检查历史告警，无该站E1/T1告警，但通过DSPE1T1STAT查看EVDO配置的两条E1工作状态，发觉只有一条E1处于正常工作状态；初步认为是E1故障的原因；5.通过现场基站维护工程师的检修，另一条E1工作恢复正常（据说是接口松动）；再进行测试，平均速率在1.8Mbps左右，瞬时最高速率达到2M以上。问题得到解决。【结论】基站开通后，对EVDO来说，单站的拨测不能只看是否能传输数据，应该同时关注实际传输速率，在对应的无线环境和配置下是否正常。,Page26,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的包，超过该值时，包会被拆分。初步估计路由器和3COMPDSN配合有问题，导致包被大量丢弃，速率超低。,Page27,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设置问题（最大包长问题），也有工程安装问题（接地和自环），比较典型。,Page28,EVDO速率案例传输误码率高造成EVDO数据业务速率低（1）,【现象描述】某地试验演示局，EVDO纯数据系统（无语音业务）。PDSN流媒体1BSC（小容量）2O1CBTS3606（双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的设置参数：TcpWindowSize0 x0000ffff(WINDOWSXP)排除了终端这边的设置问题；,Page29,EVDO速率案例传输误码率高造成EVDO数据业务速率低（2）,7.ABIS接口采用2对E1组成的IMA，在物理上不存在瓶颈。采用LSTCBTSLNKERRCNT命令检查ABIS接口误码统计，发现两条链路的每秒丢包个数(ERRORCONNT)基本为100200，确认ABIS传输不正常，显示如下：2005/06/09/16/35/05:LINKID=0ERRORCONNT=121,2005/06/09/16/36/05:LINKID=0ERRORCONNT=111,2005/06/09/16/37/05:LINKID=0ERRORCONNT=103,2005/06/03/18/20/51:LINKID=1ERRORCONNT=124,2005/06/03/18/21/51:LINKID=1ERRORCONNT=106,2005/06/03/18/22/51:LINKID=1ERRORCONNT=117,2005/06/03/18/23/51:LINKID=1ERRORCONNT=124,2005/06/03/18/24/51:LINKID=1ERRORCONNT=125,2005/06/03/18/25/51:LINKID=1ERRORCONNT=124,问题定位到ABIS口数据及硬件，检查ABIS数据正常。检查对应ABIS接口传输设备，发现从BSC侧DDF架到光传输之间、及BTS侧DDF架到光传输之间均未接地，在安装规范中要求光传输设备的输入、输出必须单端接地，否则将会产生相应的误码；8.在光传输设备的维护台上早已有传输误码告警，但由于原来该光传输是使用于GSM基站的ABIS接口，虽然传输的误码产生一定的话音质量差，但由于语音的误码要求(1E-4)较EVDO传输误码(1E-6)小，所以客户也未深究。但对于EVDO这样数据传输时，光传输设备的误码直接造成下行速率下降；在DDF架进行相应接地后，测试业务下行速率达到2.2M（三星手机）。【结论】1、分析DO下行速率过低，根据木桶最短板原理，应该从底层开始，一层层分析判断受限点，定位原因并解决.2、由于数据业务在传输通道中误码率及时钟同步要求比语音业务高，所以在EVDO设备开局时注意系统时钟的同步及精度。,Page30,EVDO速率案例EC板缓存太大导致频繁切换时DORev.A终端掉零,【现象描述】使用AnyDATA终端（协商为DORev.A模式）进行路测，在切换带内，经常出现速率掉零，且长时间无法自动恢复，需要手动重启FTP下载后，下载才能恢复正常。【处理过程】1、分析AT的log数据，发现在产生掉零的位置，空口环境变化非常剧烈，AT申请的DRC在0到1.2M之间剧烈波动，同时AT的RLP数据中增加了许多RLPAbort。2、分析FMR和信道板的打印信息，发现信道板此时的缓冲队列大多为满的状态。由于DRC由大到小变化非常迅速，又伴随多次虚拟软切换，每次虚拟软切换都会将缓冲区中的数据全部清空，因此，FMR下发的重传数据不能及时的发到AT，导致AT侧产生RLPAbort，将错误遗留到上层TCP层后，引发TCP的惩罚机制，导致速率降为0。3、EC板的缓存默认设置为32760byte，在大部分情况下切换是没有问题的，但对于频繁切换情况，由于产品的实现机制，在切换前需要清空原缓存，导致大量的数据靠上层的重传来保证，大量的数据如果在AT的RLP定时器超时之前来不及重传，则会产生大量的RLPAbort，传递到上层TCP层，从而导致掉零；但如果设置EC板的缓存值太小，由于拥塞控制机制，将会导致单用户下载情况下速率达不到理论值。【结论】EC板缓存为代码写死参数，无维护台命令可修改。通过多次测试发现设置EC板缓存为14000byte时，频繁切换导致掉零问题和下载速率低问题都可以得到解决。但由于网络的差异，不一定适合其它地方，对于特定的网络，需要测试验证。,Page31,EVDO速率案例FMR缓冲区不够导致频繁切换时DORel.0终端掉零,【现象描述】使用AnyDATA终端（协商为DORel.0模式）进行路测，在切换带内，经常出现速率掉零，且长时间无法自动恢复，需要手动重启FTP下载后，下载才能恢复正常。【处理过程】1、对比该时段前后Caitlog，发现在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层的重传，这会导致很大的速率波谷。【结论】BTSEC板缓存与FMR的记录相差太大是频繁切换时DORel.0路测掉零的根本原因。目前产品不支持命令修改，BSC版本V2R3C03B012最近版本已经把记录数写死为270。,Page32,EVDO速率案例HAC板不稳定问题导致的DO用户前反向速率出现周期性大的波动,【现象描述】某EVDO局BSC版本为BSC6600-OMCV200R001ENGC01B010，BTS版本为BTS3612-OMCV200R001ENGC01B011。EVDO的FTP下载传输速率很不稳定，在基站附近，信号质量很好，DRC为2.4576M和C/I为11-13的时候，单用户的下载传输速率一般在30kBps到130kBps间，波动很大，上传速率也出现类似的波动。【处理过程】1、由于本次测试使用的是局方的PDSN设备和FTPserver，而局方的该设备之前一直运行正常，所以可以先排除PDSN和FTP服务器的问题。2、对硬件安装情况进行检查，设备安装质量无问题，之后重新制作网线，逐步更换我们的LANSWITCH和局方PDSN和我司PCF之间的连接网线，每次拨号测试，故障仍存在，检查BTS的E1状态，正常无告警。3、据中研反馈，这种高通的手机由于存在下载半小时以上就会断掉业务的问题，并且该问题当时已经和高通确认。但是现场的主要问题是速率的波动和平均速率低，和描述现象不是很一致。4、检查数据配置，没有发现问题，重新安装BAM，复位，发现FTP下载速率最大可以达到180kBps左右，但存在周期性的大波谷。5、怀疑带宽的限制造成该问题，尝试修改系统PVC带宽后复位，发现波动更频繁，性能比之前还要差。由于速率十分不稳定，修改回原始带宽复位，速率变为波动从0297kBps之间，更加不稳定，不能恢复原来的相对稳定状态。6、由于多次复位系统后，每次速率变化都不太一样，数据没有变化（带宽数据已经改回），因此怀疑系统的软件或硬件部分存在不稳定的因素，想起HAC板几日来随机出现几次GE口告警，更换BSC的HAC板，重新测试，平均吞吐量可以达到近点200kBps左右，反向吞吐量也可稳定达到126kbps，问题解决。【结论】在处理问题的时候要关注告警信息，特别是新产品，出现的问题有的时候会比较多，很难定位，告警是比较重要的定位信息。,Page33,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，那么TcpWindowSize0.2*2000000/8=50000字节，则比较合适的取值就是最近的64000字节。若是WinXP，还需检查注册表中DefaultRcvWindow；此值需要设置为65535，以保证便携接收缓冲区足够大。3、分析表明，稳定时，ftp速率与带宽、延时以及发送接收窗大小相关。4、经检查TCP接收窗大小为8k，可能存在瓶颈问题。5、同理检查并调整FTP服务器TCP发送窗口大小。【结论】通过调整窗便携机TCP接收窗大小及FTP服务器TCP发送窗口大小，下载速率提高到预定目标。,Page34,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的反向速率自适应与TCPIP的慢启动协议正好产生振荡。仔细分析，反向华为不支持IP头压缩而3Com支持。将3Com的IP头压缩取消，测试结果与采用华为的PDSN现象一致。将终端反向速率采用iperf提高到76.8k，稳定一段时间，同时采用TCP下载，当iperf终止传输时，TCP下载也能稳定在1.9M以上。【结论】进行FTP下载时通过CAIT或者在BSC的调试台观察误码率是否大于1，空口是否有很多NAK帧。前向发送大量NAK帧说明反向业务信道误码过高，提高了反向业务信道发射功率可以减少反向误码，改善反向应答消息的解调成功率。这对数据业务（基于TCP/IP协议）很重要，所以可以改善前向数据速率。,Page35,EVDO速率案例服务器C盘空间不够导致EVDO下行速率低（1）,【现象描述】某试验EVDO局点，EVDO站开起来，经过多次测试调整，EVDO下载速率约为800K，速率上不去，当时C/I7，ABIS带宽3.1M，搜索窗65000。【处理过程】空口质量很好，不存在问题；确保了测试终端、测试电脑设置无误；检测设备：1、检查PVC带宽，站点的PVC带宽为4M，这已经够用，排除此原因；2、检查BTSE1工作及带宽是否足够，单个扇区共用了2两E1专给该扇区用于DO使用，而且工作正常，排除此原因；3、因为用于测试使用，网络没有AAA模块，呼叫不需要进行鉴权，分析整个呼叫信令流程未能发现异常情况；4、对服务器PC建立的ftp相关参数进行检查，检查相关参数后未能发现异常情况，在处理过程中，在外路测DO的时候（一直下载大文件），有时候会出现下载停顿的情况；给路测人员的感觉是，此情况与单PC在工作时出现内存不够的情形差不多；因此怀疑测试ftp服务器的内存配置问题；可ftp服务器的内存条配置2G左右，应该够用；,Page36,EVDO速率案例服务器C盘空间不够导致EVDO下行速率低（2）,5、无意间，用磁盘管理功能查看硬盘分区情况，系统自动告警说C盘硬盘空间不够；细查C盘空间，发现C盘剩余空间为0，删除C盘下的大量用于测试使用的多媒体文件，保留2G多的剩余空间。DO下载速率明显上升，单用户下载可以稳定处于2M左右。问题获得解决。【结论】1.实际项目中，一些很细节的问题都有可能导致网络质量提升问题，如本案例因为ftp服务器C盘空间不够引起下载速率过低，一开始并没能引起大家的注意；2.很多网络问题，在想办法排除故障的时候，往往一开始想到的就是复杂的技术问题，而忽略了小问题所带来的影响；3.一些项目现场，管理等相关制度不完善，或者是制度执行不理想。导致出现了些不该出现的问题。如此案例，在现场几乎任何一个人都可以在ftp服务上拷贝操作，最后导致C盘磁盘空间满了也不通知相关人员。,Page37,EVDO速率案例EV-DOQoS速率权重设置错误导致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优化开关LSTMAPARA，将TCP优化开关关闭后测试速率依然为580Kbps，排除此开关的影响；6、检查脚本中的其他软参，也没有问题。,Page38,EVDO速率案例EV-DOQoS速率权重设置错误导致VOD视频播放速率较低达不到理想的效果（2）,7、考虑到EV-DO可以针对同一个载频下无线环境相似的不同等级用户的数据业务呼叫前向平均传输速率，是不是这个速率设置的过小而影响到整个前向速率呢？首先使用LSTDOGP查询EV-DO全局参数，查询BSC已经打开了QoS开关；使用命令LSTDOQOS:GRADE=GOLD;查询金牌用户的前向速率限制为585.6Kbps（GRADEFWDLMTRATE=FRATE5856）使用命令MODDOQOS:GRADE=GOLD,GRADEFWDLMTRATE=FRATE23424;将速率修改为2342.4后测试，VOD播放速率正常。【结论】涉及到EV-DO的参数设置很多，希望大家在考虑正常数据配置问题的情况下，多检查一下系统的参数配置。,Page39,EVDO切换案例框间链路未配置导致EVDO切换失败（1）,【现象描述】B国某CDMA450MEV-DO局点，反馈在配置反向搜索窗24chips基站和96chips基站之间EV-DO软切换失败，现象为速率陡降或者连接中断。现场BSS版本为V200R001C02B018，S3/3/3组网，2个1X频点1个EV-DO频点。【处理过程】导致EV-DO切换失败或者速率陡降的原因有：漏配EV-DO邻区；BSC间切换区域；导频污染。通过现场反馈BAM数据分析，发现邻区漏配，进一步通过打开EV-DO邻区漏配检测开关和BSCRunlog邻区漏配记录软参，通过CBSSSTAR分析Runlog文件，检测出漏配邻区，反馈现场添加。具体命令如下：1、MODDORRMMP:DETECMISSPILOTSWITCH=ON;打开邻区漏配检测功能开关，此开关V1R3默认关闭，V2R1/V2R2默认打开。2、MODSOFTPARA:SRVMN=RRM,PRMNO=50,PRMV=0 x1;打开写日志开关，邻区漏配检测的结果就会被写入到SPU日志中，然后用工具进行分析后输出邻区脚本（与1X邻区形式一致）。（注意上述0 x1指的是将RRM第50号软参的bit0的值，由默认值0修改为1，请使用LSTSOFTPARA命令首先查询该软参设置值，然后将bit0设为1）。,Page40,EVDO速率案例框间链路未配置导致EVDO切换失败（2）,增加邻区后，测试结果表明部分切换成功，但还有很多切换失败。让现场反馈最新BAM数据，通过工程辅助系统还原检查系统参数配置，发现现场配置有两个EV-DO框，但框间未配置软切换链路，进一步发现测试区域基站分布在两个EV-DO框里，通知现场配置EV-DO框间链路，测试结果表明EV-DO切换正常，问题得到解决。【结论】BSC配置有多个EV-DO框，框间也需要配置软切换链路。EV-DO切换失败很多原因跟邻区漏配有关，要充分利用CBSSSTAR邻区漏配检测功能发现漏配邻区。,Page41,第1章EVDO接入案例第2章EVDO掉话案例第3章EVDO速率案例第4章EVDO切换案例第5章EVDO其他案例,内容介绍,Page42,EVDO切换问题分类及分析建议,影响EVDO切换的主要因素：1、邻区关系2、切换参数3、资源容量4、终端及产品问题分析建议：1、通过路测分析掉话原因；2、路测的同时在维护台进行空口信令跟踪，检查切换流程；3、检查邻区（漏配、优先级不合理）4、检查搜索窗大小（激活集、候选集、相邻集）5、检查切换门限（PILOTADD、PILOTCMP、PILOTDROP、PILOTDROPTIMER，）6、检查设备告警7、分析话统数据,Page43,EVDO切换案例FMR单板故障导致DO强分支无法加入激活集引起切换失败（1）,【现象描述】P国EV-DO网络进行AN内软切换测试，AT软切换上报RU，系统侧回复TCA，手机侧没有收到，导致强分支无法加入激活集，形成强干扰，邻区关系已经配置。【处理过程】1、分析CAIT的Log数据，当PN472为服务扇区时，AT通过RupteUpdate消息上报要求增加PN392扇区，但却一直没有收到AN下发的TrafficChannelAssignment消息。,Page44,EVDO切换案例FMR单板故障导致DO强分支无法加入激活集引起切换失败（2）,2、从维护台信息跟踪（见附件2）可看出，BSC已收到该RouteUpdate消息，并且已经下发了3条连续TrafficChannelAssignment消息。由此知，TrafficChannelAssignment消息是在下发途中丢失了。3、因为Abis链路一直存在告警，开始怀疑TrafficChannelAssignment消息可能是在Abis链路丢失的。但进一步考虑，即使Abis链路存在告警也不可能所有的TrafficChannelAssignment消息都会丢失，而且从CAIT的Log数据可看出AN下发的周期性消息和其它都是正常的，只是从来没有TrafficChannelAssignment消息。由此初步判断消息不是在Abis链路丢失的。,Page45,EVDO切换案例FMR单板故障导致DO强分支无法加入激活集引起切换失败（3）,4、进一步分析CAIT数据发现，PN472为服务扇区时，前向业务信道下发了大量的RTCAck消息（见附件3），但是其它所有的前向业务信道消息AT都没有接收到。PN392则无上述现象。协议规定RTCAck只是在空口连接建立，AN捕获反向业务信道时才会发送，其它时间都不应该发送该消息。因此判断AN侧存在问题。5、从现场了解到P国该BSC13框FMR存在内存吊死问题，会造成FMR无法得到内存用于接收其它模块发送带内消息。由此判断，TrafficchannelAssignment是由于FMR存在Bug而无法发送出去，造成切换无法成功。【结论】1、强制加载FMRDSP，看加载以后切换无法成功的问题是否仍然存在。如果问题消失，则证实前面的结论。2、进行更全面的测试，包括双向切换等，并且进一步采集数据以便分析。前方已反馈，强制加载FMRDSP后软切换成功。由此可知FMR内存吊死问题确实造成切换失败，但强制加载FMR只是临时措施，最终仍需通过版本修改（升级到V2R2）来解决。,Page46,第1章EVDO接入案例第2章EVDO掉话案例第3章EVDO速率案例第4章EVDO切换案例第5章EVDO其他案例,内容介绍,Page47,EVDO其他案例未打开BSC的AN-AAA接入认证功能会引起双模切换失败,【现象描述】1X/DO双模手机进行DO1X间的切换时失败。【处理过程】1X/DO双模手机进行DO1X间的切换时，必须配置AN-AAA并启动接入认证（将SMP的0号软参设置为0 x0），否则在DO系统中将根据手机ESN生成IMSI,很可能和AN-AAA以及手机中配置的IMSI不一致，会导致切换失败。【结论】通过CAIT观察SignalGraph，如果终端正确工作在双模模式，会主要停留在EVDO模式，并周期性的转到1x模式监听信道。双模终端的设置方法可以参考双模终端设置指导书。凡是切换，都存在时钟对齐的问题，因此接入网BTS和BSC的GPS时钟必须正常。,Page48,EVDO其他案例Cait的DIPSWITCH设置案例,【现象描述】在用高通QTP5500测试DO导频覆盖的时候，使用CAIT监测导频信道，此时手机工作在空闲状态。在某些区域高通手机表现为测试到的DO覆盖距离小。【处理过程】高通手机在空闲状态下CAIT对手机的采样会有40秒的时间休眠状态以增加手机的工作时间。也就是每40秒采样一次手机数据，这样的结果会导致信号剧烈变化的区域因为未及时采样而出现到错误的导频。所以在测试的时候需要取消手机的“sleep”模式，选择CAIT中的DIPswitchconfiguration功能，在1xEV选项中，Bit01:40ssleep选中表示取消40s休眠，改为5s休眠，因此每隔5sCAIT采样一次；Bit02:Sleep选中表示取消休眠模式，将为实时采样；【结论】需要说明的是，该设置不是存在高通终端中，因此如果高通终端重新关开机后，必须再次设置。,ThankYou,Page50,基本信息编者：胡兵参考资料,版本信息,