华为——CDMA性能案例分册（DO部分）

1、cdma性能案例分册（do部分）内部公开资料编码产品名称使用对象华为工程师产品版本编写部门cdma网络性能研究部资料版本1.1cdma性能案例分册（do部分）拟 制：cdma&wimax网络性能研究部日 期：整 理：日 期：审 核：日 期：批 准：日 期：华 为 技 术 有 限 公 司版权所有 侵权必究修订记录日期修订版本描述作者2010-03-27华为机密，未经许可不得扩散第ii页, 共26页cdma性能案例分册（do部分）内部公开目 录第1章 连接建立类案例31.1 pcf丢包导致at重激活时延长31.2 相邻载频的搜索窗配置不相等导致ev-do接入失败5第2章 切换类案例102.

2、1 框间链路未配置导致ev-do切换失败10第3章 do速率低案例123.1 abis传输乱序导致do rev.a单用户下载速率低123.2 ec板缓存太大导致频繁切换时do rev.a终端掉零143.3 fmr缓冲区不够导致频繁切换时do rel.0终端掉零153.4 ev-do qos速率权重设置错误导致vod视频播放速率较低达不到理想的效果173.5 e1数目不足和业务链路配置错误造成ev-do数据业务下载速率低19第4章 其他案例214.1 actix统计工具有误导致路测大量rlp reset212010-03-27华为机密，未经许可不得扩散第23页, 共26页关键词：do 连接建立

3、切换 下行速率 鉴权摘 要：本文收集了网优工程师现场处理无线性能问题的案例，并按照连接建立、切换、do速率、其他等将案例分成四大类。详细介绍了每一个案例的问题描述、原因分析、解决方案、经验总结和备注，目的是让网络优化人员学习前人的经验从而达到快速处理类似问题的能力，并从中积累网优经验，少走弯路。缩略语清单：缩略语 英文全名中文解释abisabis interfaceabis接口（an-bts）a1a interfacea接口（msc-an）anaccess network接入网络apaccess point接入点ataccess terminal接入终端bambackground admini

4、stration module后管理模块bscbase station controller基站控制器btsbase transceiver station基站收发信台drcdata rate control数据速率控制dridata ready indication数据准备指示ecenhanced channel processing board增强信道处理板ev-doevolution data optimized增强速率优化fmrframe processing (fp mac rlc) board帧处理板ftpfile transfer protocol文件传输协议ipinternet

5、 protocol因特网协议nidnetwork identification网络标识pcfpacket control function分组控制功能pdsnpacket data serving node分组数据服务节点pzidpacket zone identification分组区标识qosquality of service业务质量qxdmqualcomm extensible diagnostic monitor高通do a测试工具rlpradio link protocol无线链路协议rrmradio resource management无线资源管理sidsystem ident

6、ification系统标识tcptransmission control protocol传输控制协议umair interface空中接口vodvideo on demand视频点播第1章 连接建立类案例1.1 pcf丢包导致at重激活时延长作者：吴钰峰（45700）最小部门：cdma & wimax网络性能研究部所属产品：cdma bss来源：比拼测试关键字：at 重激活【现象、问题描述】r国比拼测试前，做at重激活预测试，发现重激活时延非常不稳定，有时只需要500ms左右，有时却需要4000ms。【关键过程、根本原因分析】拨号连接，看到at进入idle后，使用下列命令ping f

7、tp服务器：ping -n 1，测试10次，发现at进入dirmant态的时间变化也非常大（fmr的去激活定时器为30s）。分析用户接口跟踪，发现存在两种呼叫流程，一种正常，一种异常，异常流程中bsc没有收到pcf发送的a9-update-a8-ack消息，如下图：图1-1 呼叫信令流程查询ccm的a9 update a8超时定时器发现，使用的是默认值2000（单位为ms，即2s），正常的a9-update-a8响应时间应该为ms级的。我们修改该定时器为5000，经过多次测试，还是出现该问题。在pcf抓包，发现存在丢包现象。【结论、解决方案及效果】与开发人员进行确认，发现

8、pcf的内部处理存在问题，修改之后问题得到解决。发现问题版本为v2r3c03b011，合入到了v2r3c03b012版本。【经验总结、预防措施和规范建议】无。【备注】无。1.2 相邻载频的搜索窗配置不相等导致ev-do接入失败作者：黄辽（42271）最小部门：cbss产品技术服务部所属产品：cdma bss来源：网络优化关键字：接入失败 位置更新 搜索窗【现象、问题描述】r局点有用户投诉，ev-do呼叫接入时偶尔出现接入失败的情况。对该地区进行路测，发现该小区有些地区的接入成功率非常高，但是有些地区则常常出现ev-do接入失败的问题。同时在跟踪该用户的时候发现该用户的at发送位置更新消息非常频

9、繁。【关键过程、根本原因分析】1、通过分析信令来检查什么原因导致了呼叫接入失败，发现在失败时有如下异常流程出现：bsc连续发起两次a9-setup-a8的消息图1-2 bsc连续发起两次a9-setup-a8的消息的信令在上述的流程中，an在2ms的时间之内给同一个pcf发送了两条a9-setup-a8 dri（数据准备指示）分别为1和0，要求建立a8链路。在bsc的v200r001c02b018sp0x系列的版本中，由于pcf的处理缺陷，如果pcf在极短的时间之内连续收到为同一个at的建立a8连接的请求，pcf会认为pcf与an的资源状态不一致，所以pcf就通过第二条a11注册请求消息，释放

10、相关的资源，把呼叫释放到null态，在5秒之后，an给at发送了连接拒绝消息。2、分析为什么an会在极短的时间之内给pcf发送两条a9-setup-a8。通过消息内容的分析，这两条a9-setup-a8的dri分别等于1和0，由于用户有数据要传，因此an会发送dri=1的a9-setup-a8消息，要求建立a8链路，在何种情况下会发送dri=0的a9-setup-a8消息呢？分析协议知道发送dri=0的a9-setup-a8消息原因有：l 用户在休眠态下发生an间切换l 用户在休眠态下发生1x与do之间的切换l 用户在激活态的时候释放呼叫l 会话进行配置协商后，发起的a8建立很明显，前面的三种

11、情况都不符合。3、分析相关的信令流程，可以看到，确实是在会话配置协商的同时，用户发起了do呼叫接入，因此an在2ms的时间之内给pcf发送了两条a9-setup-a8。图1-3 an在2ms的时间之内给pcf发送了两条a9-setup-a8的信令4、由此得到这个问题的根本原因：由于an在极短的时间内，对于同一个at的a8链路建立，给pcf发送了两条a9-setup-a8，在v2r1的版本中，pcf对于这种特殊的场景的处理存在缺陷，拒绝了呼叫的接入。因此这个问题的产生与at频繁进行会话的配置协商有关。at可能发起位置更新的场景：l 位置信息发生变化，比如：sin、nid和pzid，这三个id中的

12、任何一个发生变化，at都会发起位置更新。l 会话的配置协商完成后，如果an支持位置更新，at就会发起位置更新。首先对at发送的locationnotification消息进行分析，可以发现所有的消息中的sid、nid和pzid的值都是一样的，据此可以排除位置信息发生变化这种原因。再通过对跟踪的信令流程进行分析，可以发现at与an不断地对搜索窗口的大小进行协商，对其中的两条routeupdconfigrequest进行分析，可以看到相邻集搜索窗口在8和9之间来回变动。图1-4 rur消息相邻集搜索窗口不同搜索窗的大小是会话建立时需要协商的参数，如果协商好的参数发生变化，那么肯定需要重新进行会话的

13、配置协商。另外，根据abis-do-bts setup消息，我们找到了这个区域几个主要的载频，发现在配置脚本中，它们相邻集的搜索窗口确实是不相等的：mod docnp: cn=2054, sctid=1, crrid=10, pilotincrement=4, srchwina=5, srchwinn=9, srchwinr=14, confirm=y;mod docnp: cn=2169, sctid=2, crrid=10, pilotincrement=4, srchwina=5, srchwinn=8, srchwinr=14, confirm=y;mod docnp: cn=2169

14、, sctid=1, crrid=10, pilotincrement=4, srchwina=5, srchwinn=8, srchwinr=14, confirm=y;【结论、解决方案及效果】覆盖这个区域的几个主要载频的相邻集搜索窗口配置不相等，导致了会话重新发起配置协商。分析频繁位置更新的信令流程，发现at频繁发起位置更新的原因：在一个切换区域中，几个主要的载频的搜索窗配置不相等，导致频繁发起会话的配置协商过程，随带着at频繁发起位置更新。图1-5 频繁位置更新的信令流程分析把这几个载频的相邻集搜索窗口修改相等，修改后上述问题全部解决。【经验总结、预防措施和规范建议】无。【备注】无。第2

15、章 切换类案例2.1 框间链路未配置导致ev-do切换失败作者：唐明通（39938）最小部门：俄罗斯代表处所属产品：cdma bss来源：网络优化关键字：ev-do切换 框间链路 邻区漏配 cbssstar【现象、问题描述】b国某cdma450m ev-do局点，反馈在配置反向搜索窗24chips基站和96chips基站之间ev-do软切换失败，现象为速率陡降或者连接中断。现场bss版本为v200r001c02b018，s3/3/3组网，2个1x频点1个ev-do频点。【关键过程、根本原因分析】导致ev-do切换失败或者速率陡降的原因有：l 漏配ev-do邻区；l bsc间切换区域；l 导频污

16、染。通过现场反馈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邻区形式一致）。（

17、注意上述0x1指的是将rrm第50号软参的bit0的值，由默认值0修改为1，请使用lst softpara命令首先查询该软参设置值，然后将bit0设为1）。【结论、解决方案及效果】增加邻区后，测试结果表明部分切换成功，但还有很多切换失败。让现场反馈最新bam数据，通过工程辅助系统还原检查系统参数配置，发现现场配置有两个ev-do框，但框间未配置软切换链路，进一步发现测试区域基站分布在两个ev-do框里，通知现场配置ev-do框间链路，测试结果表明ev-do切换正常，问题得到解决。【经验总结、预防措施和规范建议】bsc配置有多个ev-do框，框间也需要配置软切换链路。ev-do切换失败很多原因跟

18、邻区漏配有关，要充分利用cbssstar邻区漏配检测功能发现漏配邻区。【备注】无。第3章 do速率低案例3.1 abis传输乱序导致do rev.a单用户下载速率低作者：吴钰锋(45700)、叶国骏（47562）最小部门：cdma & wimax网络性能研究部所属产品：cdma bss来源：比拼测试关键字：速率低 乱序【现象、问题描述】在b市无线环境非常好的情况下（drc申请速率为3.1mbps），使用do rev.a终端进行单用户下载，即使同时使用两个线程进行下载，平均下载速率也不超过2.5mbps。【关键过程、根本原因分析】考虑到组网的特殊性，bsc和bts分别与两个汇聚路由相联，

19、两个汇聚路由之间预留有3根e1口通过微波传输（如下图），先在a市进行无线环境很好情况下单用户下载，发现下载速率正常，可达2.8mbps。图3-1 网络结构图使用ping测试abis传输的误包率，发现误包率非常低，没有问题。通过qxdm测试发现，下载速率比正常情况低300kbps的主要原因为abis口存在大量的rlp重传，at侧统计的总的重传字节和接收到的新包字节数量几乎相当，有大量数据是重复字节。采用逐段排除的方法，将fmr的接收、发送数据、ec板的接收数据，与at的接收数据进行对比，找出吞吐量损失的大致位置，然后通过该处的信息跟踪进行精确定位，定位出丢失的包实际上是由于abis链路上产生了乱

20、序，而rlp层无法分辩乱序还是丢包，从而引发了大量的rlp重传。【结论、解决方案及效果】下载速率低主要原因是：abis口路由间ip传输导致数据乱序，最终导致大量rlp重传。解决方案：1）推动客户检查了网络，发现两个汇聚路由器之间，3根e1中的1根存在时钟配置问题，修改后乱序包的比例从2%下降到0.1%以下，网络质量得到优化；2）信道板增加了排序功能（bts计划合入到v3r2c01版本中），rlp重传大大减少。【经验总结、预防措施和规范建议】在定位一些速率低等网上问题时，一定要考虑实际的网络结构。由于我司产品验证主要是在实验室完成，而通常情况下实验室无法考虑各种各样的实际组网情况，所以在商用网中

21、通常会出现这样那样的问题。【备注】无。3.2 ec板缓存太大导致频繁切换时do rev.a终端掉零作者：吴钰锋(45700)、叶国骏（47562）最小部门：cdma & wimax网络性能研究部所属产品：cdma bss来源：比拼测试关键字：频繁切换 掉零【现象、问题描述】使用anydata终端（协商为do rev.a模式）进行路测，在切换带内，经常出现速率掉零，且长时间无法自动恢复，需要手动重启ftp下载后，下载才能恢复正常。【关键过程、根本原因分析】分析at的log数据，发现在产生掉零的位置，空口环境变化非常剧烈，at申请的drc在0到1.2m之间剧烈波动，同时at的rlp数据中增

22、加了许多rlp abort。分析fmr和信道板的打印信息，发现信道板此时的缓冲队列大多为满的状态。由于drc由大到小变化非常迅速，又伴随多次虚拟软切换，每次虚拟软切换都会将缓冲区中的数据全部清空，因此，fmr下发的重传数据不能及时的发到at，导致at侧产生rlp abort，将错误遗留到上层tcp层后，引发tcp的惩罚机制，导致速率降为0。【结论、解决方案及效果】ec板的缓存默认设置为32760byte，在大部分情况下切换是没有问题的，但对于频繁切换情况，由于产品的实现机制，在切换前需要清空原缓存，导致大量的数据靠上层的重传来保证，大量的数据如果在at的rlp定时器超时之前来不及重传，则会产生

23、大量的rlp abort，传递到上层tcp层，从而导致掉零；但如果设置ec板的缓存值太小，由于拥塞控制机制，将会导致单用户下载情况下速率达不到理论值。通过多次测试发现设置ec板缓存为14000byte时，频繁切换导致掉零问题和下载速率低问题都可以得到解决。注意：ec板缓存为代码写死参数，无维护台命令可修改。14000byte适用于r国，但由于网络的差异，不一定适合其它地方，对于特定的网络，需要测试验证。【经验总结、预防措施和规范建议】为了兼顾频繁切换导致掉零问题和下载速率低问题，需要合理设置一个平衡值。【备注】无。3.3 fmr缓冲区不够导致频繁切换时do rel.0终端掉零作者：吴钰锋(45

24、700)、叶国骏（47562）最小部门：cdma & wimax网络性能研究部所属产品：cdma bss来源：比拼测试关键字：频繁切换 路测 掉零【现象、问题描述】使用anydata终端（协商为do rel.0模式）进行路测，在切换带内，经常出现速率掉零，且长时间无法自动恢复，需要手动重启ftp下载后，下载才能恢复正常。【关键过程、根本原因分析】对比该时段前后cait log，发现在gps时间15:44:06.203时，at发送了连续发送了两条反向rlp消息，空洞长度分别为31842和25668字节，这样的大空洞是导致速率掉零的直接原因。回放cait数据，在上述大片空洞产生之前都发生了

25、虚拟软切换：图3-2 在大片空洞产生之前发生了虚拟软切换分析fmr调试台打印也可以看到，这段时间内切换很频繁，开始的时候是0号分支作为主分支。当2号分支发起req时，基站缓冲区被清除，此时可以看到基站缓冲区数据量很大，几乎是满的。另外刚切换到2号分支，就发现2号分支连续几秒钟收到的反向帧都是误帧。此时处于无主分支状态。基站又清除缓冲区，在这540ms内有损失了200多个前向包和200多个重传包。基站上报的从空口发出去的frameid和fmr发给bts的frameid相差很大。在虚拟软切换时，基站会清空发送缓冲区，基站的缓冲区设定是32760字节，相当于263个rlp包，而fmr只会记录已发给b

26、ts的10个包记录，当基站大量数据被清除时，要求传输的数据在fmr中找不到（基站刚把缓冲区填满，就发生了虚拟软切换），此时会在at的rlp层产生一个大小为200多个包的空洞，只能依靠于tcp层的重传，这会导致很大的速率波谷。【结论、解决方案及效果】bts ec板缓存与fmr的记录相差太大是频繁切换时do rel.0路测掉零的根本原因。通过修改fmr的记录（从10改为270），频繁切换时do rel.0路测掉零问题得到了解决。注：fmr的记录数需要调整的可能性非常小，目前产品不支持命令修改，bsc版本v2r3c03b012最近版本已经把记录数写死为270。【经验总结、预防措施和规范建议】无。【备

27、注】无。3.4 ev-do qos速率权重设置错误导致vod视频播放速率较低达不到理想的效果作者：张柏林最小部门：cbss产品技术服务部 所属产品：cdma bss来源：网络优化关键字：vod 金牌用户 qos dogp【现象、问题描述】某局点对bsc6600,bts3606、pdsn升级后利用三星e159手机拨号后进入vod视频点播网站进行视频播放，通过速度测试软件测试的播放速率只有580kbps，而升级前稳定为1.4mbps。现场版本：bsc6600v200r003c02b014(061110)，bts3606-0r001engc04b01520061110),pdsn9660v800r1

28、05c01b011,组网：1个bsc6600、1个bts3606、1个pdsn、1业软的流媒体服务器。【关键过程、根本原因分析】1、检查ev-do基站的业务链路带宽，分配给do的物理e1为两条业务链路。带宽设置没有问题；2、检查便携机参数设置，tcp窗口、ip头压缩等设置的均没有问题；3、由于只用一个手机连接到便携机上进行测试，所以不可能是由于用户数过多引起的速率下降；4、手机上信号满格，并且测试手机就在离基站不到5米的地方，排除了无线环境差的原因；5、检查bsc参数设置：l 检查tcp优化开关lst mapara，将tcp优化开关关闭后测试速率依然为580kbps，排除此开关的影响；l 检查

29、脚本中的其他软参：mod softpara: srvmn=smp, prmno=0, prmv="0x01"mod softpara: srvmn=ccm, prmno=31, prmv="0x0"mod softpara: srvmn=pcu, prmno=3, prmv="0x1"mod dofmr: fn=4, inactivetlen=255, confirm=y;设置没有错误；l 考虑到ev-do可以针对同一个载频下无线环境相似的不同等级用户的数据业务呼叫前向平均传输速率，是不是这个速率设置的过小而影响到整个前向速率呢？&#

30、174; 首先使用lst dogp查询ev-do全局参数，查询bsc已经打开了qos开关；® 使用命令lst doqos: grade=gold;查询金牌用户的前向速率限制为585.6kbps（gradefwdlmtrate=frate5856）® 使用命令mod doqos: grade=gold, gradefwdlmtrate=frate23424;将速率修改为2342.4后测试，vod播放速率正常。【结论、解决方案及效果】金牌用户速率的前向设置为frate5856，那么这个载频下的用户最高就只能以585.6的最高速率接入了，无法以其他更高速率接入。qos速率权重设置

31、错误导致vod视频播放速率偏低。修改此参数后vod播放速率恢复正常。【经验总结、预防措施和规范建议】涉及到ev-do的参数设置很多，希望大家在考虑正常数据配置问题的情况下，多检查一下系统的参数配置。【备注】无。3.5 e1数目不足和业务链路配置错误造成ev-do数据业务下载速率低作者：陈世进（60653）最小部门：无线网络规划部所属产品：cdma bss来源：网络优化关键字：ev-do ftp下载 速率低【现象、问题描述】m国ev-do网络在完成所有安装和配置之后，测试时单用户使用ev-do ftp下载业务的平均速率只有700800kbps，使用内部ftp服务器下载，单用户平均速率依然很低。【

32、关键过程、根本原因分析】造成ev-do数据业务速率低的原因一般有如下几点：l 空口质量差；l abis带宽不足；l bsc、pcf和pdsn间pvc带宽设置不合理；l bsc和bts配置业务链路数不一致；l 连接终端和ftp服务器的pc配置错误。1、用cait测试空口质量。测试结果表明c/i超过10db，drc始终为2.4mbps，而且测试过程中没有收到相邻扇区或者基站的信号。这说明空口质量很好，不是造成下载速率低的原因。2、检查连ftp服务器和接终端以及ftp服务器的pc的配置。确认配置无误后，单用户平均下载速率依然保持在700800kbps。3、检查配置的e1数，发现每个ev-do基站只配

33、置了一条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。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协议窗口配置、物理链路配置、业务链路数等几个方面去查找原因。【备注】无。第4章