您好,欢迎访问三七文档
当前位置:首页 > 商业/管理/HR > 项目/工程管理 > CDMA掉话情况分析
CDMA掉话情况分析正常呼叫移动台接收参数特点–接收功率大于-100dBm–发射功率小于+18dBm–发射增益调整正常•具体数值与基站配置等有关–前向FER低–至少有一个导频Ec/Io大于-12dB正常呼叫的消息类型主要消息(假定呼叫由移动台发起和终止)–OriginationMessage(移动台-基站接入信道)–BaseStationAcknowledgementMessage(基站-移动台呼叫信道)–ChannelAssignmentMessage(基站-移动台呼叫信道)–BaseStationAcknowledgementMessage(基站-移动台前向业务信道)–MobileStationAcknowledgementMessage(移动台-基站反向业务信道)–……–PilotStrengthMeasurementMessage(移动台-基站反向业务信道)–HandoffDirectionMessage(基站-移动台前向业务信道)–HandoffCompletionMessage(移动台-基站反向业务信道)–……–NeighbourListUpdateMessage(基站-移动台前向业务信道)–……–ReleaseOrderMessage(移动台-基站反向业务信道)–ReleaseOrderMessage(基站-移动台前向业务信道)掉话的基本概念及掉话机制–如果移动台在连续5秒(250个帧)内没有接收到两个连续好帧,移动台将重新初始化,导致掉话–移动台在连续收到12个坏帧后将关闭发射机,当接收到两个连续好帧时重新启动发射机掉话原因及案例分析主要原因分类1.覆盖不足2.过覆盖3.邻区缺失4.邻区位序不合理5.搜索窗太小6.导频混淆7.同PN8.导频污染9.边界硬切换失败10.终端问题11.外部干扰12.其它(1)覆盖不足导致的掉话•移动台特点–接收功率小于-100dBm–发射功率大于20dBm–发射功率增益调整大于-10dB–接收Ec/Io小于-14dB–接收FER较高•解决办法–检查该区域是否在预期覆盖范围之内–如不在•忽略–如在•通过调整天线方向角、下倾角、发射功率等增强覆盖•如不能通过调整天线增强覆盖,则需要增加新的基站案例分析•掉话地点–重庆成渝高速路-中梁山隧道•问题发现–2005年重庆地区的优化过程中,在对成渝高速的路测数据分析时发现在中梁山隧道(4公里长)的中端的300米左右的区域内CDMA网络信号相当弱,极易掉话–问题主要是隧道口的基站发射功率无法满足隧道内覆盖(1)覆盖不足导致的掉话(续-1)隧道内移动台接收功率图(1)覆盖不足导致的掉话(续-2)隧道内接收电平较差掉话原因及案例分析主要原因分类1.覆盖不足2.过覆盖3.邻区缺失4.邻区位序不合理5.搜索窗太小6.导频混淆7.同PN8.导频污染9.边界硬切换失败10.终端问题11.外部干扰12.其它(2)过覆盖导致的掉话•概念–过覆盖是指某些扇区的信号覆盖超出了预期的覆盖范围,产生网络前向内部自干扰•特点–过覆盖区域接收电平正常,但Ec/Io较差,同时具有较高的FER–导频过覆盖有时会在较远的地方出现“飞地”,产生孤岛效应。在此区域移动台接收功率和Ec/Io很好,导致移动台和周围小区没有切换关系,在进行软切换时切换失败,导致掉话–过覆盖还可能会导致前反向链路不平衡、导频污染等问题•解决办法–控制覆盖案例分析•现象–嘉陵新路过覆盖并产生孤岛效应•问题发现–2005年4月18日测试鹅岭Ec/Io和FER都很差,有掉话•分析–4月18日测试鹅岭Ec/Io和FER都很差,有掉话–分析原因是沙坪坝区的松林坡1扇区以及重大A区1扇区过覆盖导致–其中松林坡1扇区(MCBTS1142_1,PN6)过覆盖信号部分区域足够强产生孤岛效应,导致掉话(2)过覆盖导致的掉话(续-1)掉话时Ec/Io覆盖图(2)过覆盖导致的掉话(续-2)移动台接收Ec/Io较差小于-16db移动台掉话后同步到PN6(MCBTS1142_1)但PN6是距掉话区域较远处基站的信号(2)过覆盖导致的掉话(续-3)同步到MCBTS1142第1扇区PN6PN6来自间隔多个基站之外的基站MCBTS1142第1扇区(2)过覆盖导致的掉话(续-4)MCBTS1142第1扇区(PN6)掉话原因及案例分析主要原因分类1.覆盖不足2.过覆盖3.邻区缺失4.邻区位序不合理5.搜索窗太小6.导频混淆7.同PN8.导频污染9.边界硬切换失败10.终端问题11.外部干扰12.其它案例分析•现象–狮子滩至云集路测过程中掉话•原因分析–由于罗维PN429小区未将云集PN126加入NL,从而导致切换失败而掉话•问题解决–完善邻小区关系解决掉话,复测该路段已无掉话(3)邻区缺失导致的掉话(续-1)狮子滩至云集掉话MobileLog(3)邻区缺失导致的掉话(续-2)移动台使用PN429进行通信,尽管信号已经很差掉话后,移动台同步到PN126掉话原因及案例分析主要原因分类1.覆盖不足2.过覆盖3.邻区缺失4.邻区位序不合理5.搜索窗太小6.导频混淆7.同PN8.导频污染9.边界硬切换失败10.终端问题11.外部干扰12.其它(4)邻区位序不合理导致的掉话•问题描述–手机在完成上一次切换后需要进行邻小区列表的更新及需要进行合并–北电的算法是按照邻区列表中排序的先后进行合并,并且在选择ACTIVESET里的PN进行邻区合并的优先原则是按其PN的EcIo强度优先选择的,这就使得在activeset中的两个信号的邻区在合并后使邻区列表数很轻易就达到20,排在后面的邻区也没法加进更新的邻小区列表里面,从而即使手机有时搜索到位置靠后的PN发了PSMM也不能触发正常切换•解决办法–调整NeighbourList中邻区列表顺序案例分析•现象–在2005年5月份对重庆市区进行路测时,从玉带山到煤气公司切换时发生掉话–掉话前Ec/Io迅速变差,掉话后同步到PN312,并且Ec/Io良好•分析–经检查,“煤气公司”已经被加在“玉带山”的二、三扇区的邻小区列表,不存在邻区缺失问题–但是,“煤气公司”的PN在“玉带山”的第二,三小区邻小区列表中分别排在第19,20位–从手机掉话前的Log发现掉话前最后一次NeighbourListUpdate消息中根本没有“煤气公司”第二扇区的PN312存在,这说明在邻区合并是PN312被排在了20位之外–同时,“玉带山”的第二,三小区存在一定的过覆盖(4)邻区位序不合理导致的掉话(续-1)掉话前后的信号Ec/Io图(4)邻区位序不合理导致的掉话(续-2)掉话前掉话后重新起呼掉话点信号恢复正常(4)邻区位序不合理导致的掉话(续-3)掉话前NeighbourListUpdate消息没有PN312存在最后一次邻区列表更新•解决方案–方案1——控制玉带山第二、三小区覆盖•调整“玉带山”第二,三小区的天线俯仰角和功率设置,同时抬起“煤气公司”的第二扇区的天线角度;目的是尽量使测试的路段上“玉带山”的信号退出主导频,同时使“煤气公司”的第二扇区信号成为手机主导频•调整之后未能取得明显效果,应为地形因素和用户群的分布问题,不可能对玉带山的天线无限制的下压,这样就达不到控制信号的目的•考虑方案(2)–方案2——调整邻区位序•不调整两个基站的天线角度,但是将“煤气公司”的第二小区定义在“玉带山”的第二,三小区邻小区关系中的位置提前到第10位左右•该方案效果明显,实施后该路段上可以从“玉带山”二扇区向“煤气公司”的第二扇区发生正常切换,不再掉话(4)邻区位序不合理导致的掉话(续-4)调整了邻小区顺序后复测得到的手机log,软切换正常(4)邻区位序不合理导致的掉话(续-5)PN312进入neighborlist几秒之后顺利切换到PN312复测时Ec/Io覆盖图(4)邻区位序不合理导致的掉话(续-6)复测掉话区域覆盖良好,无掉话掉话原因及案例分析主要原因分类1.覆盖不足2.过覆盖3.邻区缺失4.邻区位序不合理5.搜索窗太小6.导频混淆7.同PN8.导频污染9.边界硬切换失败10.终端问题11.外部干扰12.其它(5)搜索窗太小导致的掉话•问题描述–如果搜索窗太小,会导致某些PN落到了搜索窗之外而不能进入成为服务导频,反而该成为内部自干扰源,使该区域Ec/Io变差,导致掉话•解决办法开rtdlog–调整相应搜索窗口案例分析•现象–打断碑与登瀛切换过程中发生掉话•原因分析–主要原因还是打断碑前向搜索窗太小,登瀛PN402落到了搜索窗之外而不能参与切换而掉话•问题解决–将打断碑的一扇区(SectorID:1762_1,PN:12)的激活集搜索窗由原来的7改为8,即搜索窗由40Chips改为60Chips,使得移动台在以PN12为主PN向PN402切换时PN402能落入激活集搜索窗–修改SWA后问题解决(5)搜索窗太小导致的掉话(续-1)登瀛PN402的PN偏移为-22Chip,不能落入当前主服务区定的40Chip的搜索窗之内(40/2=20,22〉20)(5)搜索窗太小导致的掉话(续-2)PN402的Chipset为-22,不能进入激活集调整SWA后切换正常(5)搜索窗太小导致的掉话(续)PN402进入激活集掉话原因及案例分析主要原因分类1.覆盖不足2.过覆盖3.邻区缺失4.邻区位序不合理5.搜索窗太小6.导频混淆7.同PN8.导频污染9.边界硬切换失败10.终端问题11.外部干扰12.其它(6)导频混淆导致的掉话•问题描述–移动台在其NeighbourList中已经存在某个PN,但是又接收到来自另外一个不同基站的相同PN–事实上,产生混淆的PN设计时与NeigbourList中已存在的PN偏移并不相同,只是由于传输延迟等原因被误判相同•解决办法–更改其中一个基站的PN–或者将此PN从NeighbourList中删除案例分析(6)导频混淆导致的掉话(续-1)•问题发现–通过对SBSLOG、CLFL100的分析和客户回访结果,定位出BADCELLXX709_2的一个高掉话区域,位于距离薄壁东南部2.7公里处的孟村•初步测试和分析–测试中共发起了46次呼叫,呼叫时长为3400秒,其中共发生了12次掉话–该区域接收电平和Ec/Io正常,但掉话前移动台在不停的向系统发送PIOLTSTRENGEHMESSAGE和相同的POWERMEASUREMENTMESSAGE。从这点我们可以看出前向链路在此时已经非常差,手机已经无法前向链路信息进行正常的解调,从而最终导致手机在此区域发生掉话接收功率正常接收Ec/Io正常(6)导频混淆导致的掉话(续-2)(6)导频混淆导致的掉话(续-3)掉话前不停地向系统发送PSMM和功率测量消息,这时前向链路已经非常差PN444加入到ACTIVSET中后,成为主导频(6)导频混淆导致的掉话(续-4)切换前PN216为主导频切换后PN444成为主导频•但通过对SHAKEDOWN进行分析,发现在该区域内手机只是收到了SID=14096,PN441的信号并没有收到XX732_3,PN444的信号(6)导频混淆导致的掉话(续-5)•离掉话地点最近的PN444是XX732_3,距离该区域大约23.65公里左右•同时分析邻小区列表的定义关系发现,XX712_1,PN252中定义有XX732_3,PN444•分析–SID=14096,PN441的信号被当成XX732_3,PN444的信号加入到ACTIVESET中并成为REFERENCEPN,造成手机对所测试到的其他各个PN的时延和这些PN的实际时延相差很大并且造成了PN被手机混淆–移动台使用PN444作为REFERENCEPN后使用当前的搜索窗无法正确的解调出PN216、PN252和PN378的信号,从而使得前向链路质量发生恶化。最终导致手机掉话•问题解决–修改XX732基站的PN,避免PN混淆的现象的发生:•OldPNNewPN•Alpha:10815•Beta:276183•Gamma:444351–修改后复测确认切换正常,重新测试未发现掉话(6)导频混淆导致的
本文标题:CDMA掉话情况分析
链接地址:https://www.777doc.com/doc-4466323 .html