[信息与通信]浙江联通WCDMA网典型案例分析.doc

中国联通浙江分公司WCDMA网典型案例分析中国联通浙江分公司WCDMA网典型案例分析（20091016-20091105）（第三期）目录案例一：杭州光模块接收功率恶化告警分析案例3案例二：杭州lu_cs接口数据配置隐患分析案例6案例三：湖州用户VC VP均环回案例13案例四：嘉兴跨海大桥存在同扰码小区造成的PS频繁掉话案例16案例五：嘉兴联通综合楼WSF1-1室分出现CE配置不足拥塞现象案例21案例六：宁波VSWR值超过告警门限却不上报案例25案例七：宁波WCDMA直放站引起HSUPA上传速率低问题案例28案例八：宁波CS/PS异系统切换指标提升案例33案例九：宁波接地排不等电位造成E1T1帧失步告警案例37案例十：绍兴越城斗门基站时钟未锁定导致出现掉话分析案例39案例十一：绍兴RNC4下挂基站时钟源大频偏差异常告警定位和处理案例43案例十二：绍兴RNC6周期性位置更新定时设置不合理导致被叫提示手机关机案例47案例十三：绍兴RNC1、RNC2 Iu-Ps接口业务地址协商存在出入导致数据业务近50%概率性建立不成功案例50案例十四：绍兴PROBE路测软件进程吊死导致掉话分析案例51案例十五：绍兴MGW2-HZSS19出现885告警的处理分析案例61案例十六：台州两个不同的传输设备数据不一致引起的告警分析案例64案例十七：台州修改下行AMR业务最大业务信道发射功率提升信号较差区域MOS值案例66案例十八：台州阿朗传输接入设备7670中配置的E1数和workorder中配置的PCM数不一致导致小区激活失败分析案例74案例十九：温州中兴网管环路部分接入层设备断纤后无法监控问题案例79案例二十：舟山观看优酷视频时延案例分析案例86案例二十一：舟山利用2/3G共机柜解决3G弱覆盖案例95案例一：杭州光模块接收功率恶化告警分析案例案例编写人：金一庆 联系电话：156571781081、 问题简述 出现光模块接收功率恶化告警，该告警持续时间为2分钟左右，之后自动恢复，但是40分钟之后将重复出现，通过查看历史告警，发现该告警共有几千条，且已经出现一个多月，M2000上显示光模块接收功率恶化告警。出现该告警会对系统产生重要影响，当重要告警时该光口下配置的RRU与基带框间的链路中断，承载业务中断，告警表现为次要告警时该光口下配置的RRU与基带框间的链路质量下降，承载业务受影响。2、 发生时间和地点发生时间：2009年10月15日发生地点：WD杭州大有女装广场SF3、 原因分析（1） BBU或RRU中某个光模块损坏。（2） 光纤链路异常。（3） BBU或RRU光模块接触不好。（4） 尾纤弯曲半径过小导致损耗增加（5） 光纤接头被污染或光纤损坏。（6） 光模块和光纤不配套，即传输光纤为多模光纤，而光模块类型是1.25G单模的，或反之。4、 解决方案（1） 将预留的尾纤重新按照规范捆扎，保证半径足够大，告警仍存在。（2） 将光纤拔出重新接到光模块，看是否没有接触好，再仔细检查光纤接头是否干净，没有发现有任何异常情况，各个接头连接良好，光纤接头也很干净，初步定位为光模块的问题。（3） 现场检查光纤为橙红色多模光纤，而拔出光模块后发现BBU侧和RRU侧光模块均为单模光模块，立即将两侧光模块换为多模光模块，1个小时后通过机房侧查看告警，光模块接收功率恶化告警没有再出现，问题解决，故障排除。5、 经验总结（1） 通过两个站点的处理结果及其它几个站点光纤和光模块类型的检查发现，很多都是传输光纤为多模光纤，而光模块的类型为1.25G单模的，出现光纤和光模块的不配套，原则上应该是选择1.25G多模的光模块，即多模光纤应配多模的光模块，而单模光纤配单模的光模块，造成配套的原因是当时安装没有按照规范来实施，导致多个站点出现该问题。（2） 故障出现时可以通过历史告警查询以分析故障产生的时间及出现的频率帮助定位问题，缩小故障可能性；然后从易到难入手，逐一定位。（3） 定位问题时，可以根据告警上所提示的原因及告警的定位信息来分析，对于某些告警还可以通过所给的处理建议来进行排查，对产生故障的各种可能原因都要进行分析和验证。（4） 安装过程中一定要避免出现光模块不匹配的问题，前期地谨慎和认真可以避免后期维护的很多不必要的麻烦。正确的区分单双模光纤和光模块，一般情况下我们使用的单模光纤是黄色的，多模光纤是橙色的，单模光模块的拉环是蓝色的，且标签上标注的传输距离为10km，且波长为1310nm；而多模光纤的拉环是黑色的，且标签上标注的传输距离为0.5km，且波长为850nm。（5） 当RRU级联的时候，单双模光纤、光模块均可用；但光纤和光模块的使用必须单、双模一致，不能混合使用。案例二：杭州lu_cs接口数据配置隐患分析案例案例编写人：金一庆联系电话：156571781081、 问题简述 杭州联通RNC设备在工程建设期的lu_cs接口信令链路配置存在分配不均隐患，分别是RNC01、RNC02、RNC03、RNC04、RNC05、RNC08、RNC09、RNC10、RNC11 ，目前每套RNC配置6条lu_cs信令，其中4条信令配置在一组SPU单板上，如这组SPU出现故障将直接导致整个RNC出现语音限制接入，甚至可能造成剩余两条lu_cs接口信令无法承担全部语音业务引发的业务全阻故障。2、 状态描述RNC逻辑上由交换子系统、业务处理子系统、传输子系统、时钟同步子系统、操作维护子系统、供电子系统和环境监控子系统组成。业务处理子系统由信令处理单元（SPUa）和数据处理单元（DPUb）组成，1块SPUa单板包含4个独立的子系统，每个框中有一个子系统作为MPU子系统进行用户面资源管理以及呼叫过程中的资源分配，其余的所有子系统负责处理IuCS/Iur/Iub/Uu接口信令消息，完成信令处理功能。 SPU有四个CPU子系统，采用母板和扣板结构，有两块扣板，每块扣板上有2个CPU 子系统，通过加载不同的软件，SPUa单板可分为主控SPUa单板和非主控SPUa单板。主控SPUa单板用于管理本框用户面和信令面的资源，完成信令处理功能。非主控SPUa单板只用于完成信令处理功能。（1） 杭州的RNC01 lucs 分配 0-3信令链路 承载在0框0槽位这块SPU上，4-5信令链路承载在1框0槽位这快SPU上，而整个RNC01包含两个插框，分别是RSS RBS，在每个插框上分别都有4块SPU，两两形成主备。总共6条信令其中有4条分配在同一块SPU，而整个RNC有4块SPU，这就涉及到万一某天承载4条那块SPU出现故障，那是否另外2路信令链路能否承载整套RNC业务，这涉及到优化分配信令链路问题。而RNC01的0框0槽，0框2槽，1框0槽，1框2槽分别配置了SPU单板。根据现实最好能对6条信令进行平均分配。能平均承载在各个SPU单板上，避免因为1块板卡故障导致信令处理整个出现问题。Air Defense Subrack1Rear Panel 1415161718192021222324252627AOUaAOUaAOUaAOUaGOUaUOIaUOIaFront PanelSPUaSPUaSPUaSPUaSCUaSCUaDPUbDPUbDPUbDPUb0123456789101112130Rear Panel 1415161718192021222324252627AOUaAOUaAOUaAOUaAOUaOMUaOMUaGOUaGOUaUOIaUOIaFront PanelSPUaSPUaSPUaSPUaSCUaSCUaDPUbDPUbDPUbDPUbGCGaGCGa012345678910111213 （2） 杭州的RNC02 lucs分配 0-3信令链路承载在0框0槽这块SPU单板上，4-5信令链路承载在1框0槽位，而RNC02配置了两个插框，分别在0框0槽，0框2槽，1框0槽配置了SPU单板，而luCS信令只承载在两个槽的SPU单板，并未进行平均承载分配。Air Defense Subrack1Rear Panel 1415161718192021222324252627AOUaAOUaAOUaGOUaUOIaUOIaFront PanelSPUaSPUaSCUaSCUaDPUbDPUb0123456789101112130Rear Panel 1415161718192021222324252627AOUaAOUaAOUaAOUaOMUaOMUaGOUaGOUaUOIaUOIaFront PanelSPUaSPUaSPUaSPUaSCUaSCUaDPUbDPUbDPUbDPUbGCGaGCGa012345678910111213（3） 杭州的RNC03 lucs分配0-3信令链路承载在0框0槽这SPU单板上，4-5信令链路承载在1框0槽位这块SPU单板Air Defense Subrack1Rear Panel 1415161718192021222324252627AOUaAOUaGOUaUOIaUOIaFront PanelSPUaSPUaSCUaSCUaDPUbDPUb012345678910111213Air Defense Subrack0Rear Panel 1415161718192021222324252627AOUaAOUaOMUaOMUaGOUaGOUaUOIaUOIaFront PanelSPUaSPUaSCUaSCUaDPUbDPUbGCGaGCGa012345678910111213（4） 杭州RNC05 lucs分配0-3信令链路承载在0框0槽这SPU单板上，4-5信令链路承载在1框0槽位这块SPU单板（5） 杭州RNC08 lucs分配0-3信令路承载在0框0槽这块SPU单板上，4信令链路承载在1框0槽位，5信令链路承载在1框2槽，而RNC08的0框0槽，0框2槽，1框0槽，1框2槽分别配置了SPU单板（6） 杭州RNC09 lucs分配 0-3信令链路承载在0框0槽这块SPU单板上，4-5信令链路承载在1框0槽位，而整个RNC配置了1个交换框，2个业务框，在0框0槽，0框2槽，1框0槽，1框2槽，2框0槽，2框2槽，分别配置了SPU单板，而现在lu_cs只分配在0框和1框。（7） 杭州RNC10 lucs分配0-3信令路承载在0框0槽这块SPU单板上，4-5信令链路承载在1框0槽位，而RNC08的0框0槽，0框2槽，1框0槽，1框2槽分别配置了SPU单板（8） 杭州的RNC11 lucs分配 0-3信令链路承载在0框0槽这块SPU单板上，4-5信令链路承载在1框0槽位，而RNC02配置了两个插框，分别在0框0槽，0框2槽，1框0槽配置了SPU单板，而luCS信令只承载在两个槽的SPU单板，并未进行平均承载分配。3、 解决方案 需要对分配不均匀的RNC设备，进行重新信令分配，对每套RNC进行重新规划，lu_cs 信令链路能均匀承载在各个SPU单板上，消除安全隐患。例如对RNC01进行均匀分配，每个槽位SPU都承载相应的信令链路，避免1个槽位SPU出现故障后，剩余槽位SPU还可以承载尽可能多承载的lu_cs信令链路重新分配后如图 对于杭州RNC在lu_cs 信令链路上的配置错误问题已提交华为公司及省公司移动运维部,并已确认为数据配置欠缺考虑,存在一定隐患,计划将在11月底完成lu_cs数据配置修改,此问题经华为反馈可能全省的数据配置都有存在问题,需全面解决。案例三：湖州用户VC VP均环回案例案例编写人：沈忠惠联系 方式：156572726891、 问题简述湖州安吉地区一嘉兴漫游用户反映在一段时间内拨打VC听到自己回音，VP电话时也只能看到自己图像和听到自己声音。2、 发生时间和地点时间：2009年8月17日地点：安吉外国语学院3、 原因分析现场测试：（1） 用户手机拨打测试测试人员现场把测试SIM卡放到用户手机里进行拨打测试，此时一切业务测试均正常。（2） 用户SIM卡拨打测试测试人员接着把用户的SIM卡放到测试手机中拨打测试，网管在后台对该用户进行跟踪，发现确实是存在用户描述的现象。分析：（1） 首先怀疑是基站内部问题，但是经过用测试较多次数的现场拨打测试，均无此种现象复现；（2） 怀疑是用户开卡属性问题，到本地VLR上查找该用户信息也发现并无任何异常，而且据用户反映之前该SIM卡使用一直正常。（3） 怀疑是网管人员在RNC侧针对单用户做了特别操作，而且发现当网管人员退出RNC管理平台后使用该用户SIM卡测试时业务又恢复正常。而RNC管理平台上只有使用了跟踪功能后才能针对单用户进行操作。当再次登录RNC管理平台进入跟踪对话框后发现单用户跟踪中的一个IU UP环回选项已被选中。而使用该选项跟踪测试人员号码时发现测试人员也出现与该用户一样的现象。此时怀疑此种现象是该选项被选上之后导致。为了进一步验证该猜想而在该选项被选中状态下跟踪了多个测试号码，这些测试号码无疑一例外的均出现了和用户一样现象。据网管人员回忆在用户投诉之前一段时间，曾因该用户的号码在KPI监控中造成较多PS RAB异常释放而曾经跟踪过该用户号码，跟踪时间与用户反映此种现象出现时间基本一致。4、解决方案跟踪单用户时把用户跟踪中IU UP环回选项选择去掉之后该现象立即消失。一段时间后与该用户再次取得联系，用户反映此种现象没有再次出现。5、经验总结网管人员在RNC侧操作时对不清楚的功能要谨慎的使用，避免因网管侧误操作而引起问题。案例四：嘉兴跨海大桥存在同扰码小区造成的PS频繁掉话案例案例编写人：方少俊， 联系 电话：156573720771、 问题简述嘉兴侧基站与宁波跨海大桥存在同扰码小区造成的PS频繁掉话。2、 发生时间和地点10月21日和10月22日海盐秦山核电站3、 原因分析查看每日话统，发现：10月21日和10月22日海盐秦山核电站PS掉话次数异常。10月21日和10月22日两天海盐秦山核电站_2小区PS掉线次数异常地多，查看海盐秦山核电站_2小区覆盖区域，发现在不远处就是海面，远处即为宁波慈溪市和杭州湾跨海大桥。测量从海盐秦山核电站到慈溪边界和跨海大桥的距离，均为20km。由于海盐秦山核电站本身为高站，加上海面无阻挡和海水的镜面反射，信号可以飘到很远的地方，容易在远处形成不连续的强覆盖区域。于是怀疑是否因为慈溪区域或者跨海大桥的原因导致的掉线。从宁波方获取宁波地区WCDMA网络的站点信息，结合嘉兴地区的站点信息，在电子地图中显示如下图所示：从上图中可以很清楚地看出，海盐秦山核电站的1、2小区和跨海大桥1的2、3小区均使用32和33号扰码，且跨海大桥1站点就在秦山核电站_2小区方向上。小区同扰码会产生一些不可预料的结果，在之前的案例中已出现过因为同扰码而导致的切换超时掉话，掉话的原因大致如下：如用户在海盐秦山核电站_2（SC33）上起呼，且用户所处位置可以收到跨海大桥1_2（SC32）的信号。因为海盐秦山核电站_1小区的扰码同样为32，此时只要信号达到切换门限，RNC就会判决发起软切换。由于海盐秦山核电站_2与跨海大桥1_2实际未配置邻区关系，在切换时就会因为超时而导致掉话。然而加错同扰码的其它小区为邻区为何出现以上的激活集反复增删现象，分析如下：（1） 软切换链路增加的正常流程如下图所示：也就是说RNC在做出软切换判决后会先建立起到目标Node B的Iub链路，然后再下发Active Set Update给UE。UE收到Active Set Update命令，将此扰码加入激活集，立即回复Active Set Update Complete，然后进行上下行无线链路同步过程。（2） 秦山核电的场景出现的问题过程简化的问题过程示意图如下：1） UE测量到33号扰码的导频信号，且满足1A条件；2） UE上报1A事件测量报告；3） RNC根据目前最优小区秦山核电3的邻区列表判断应该切换到秦山核电2小区，于是先建立到秦山核电2的Iub链路；4） RNC向UE发送Active Set Update，增加小区秦山核电2到激活集；5） UE通过原来的链路回Active Set Update Complete，这时候UE和NodeB都已经开始发射和接收信号，但是这条分支还需要一段时间同步确认；6） 因为实际上秦山核电2收不到UE的信号，因此上行同步会失败，因此上报同步失败指示；7） RNC删除此链路；8） UE从活动集中删除秦山核电2小区。此过程不断重复，所以看到如前所述的现象。（3） 影响及判断方法如果出现此类的邻区配错，可能造成一下影响，同时这些影响也可以作为发现此类问题的判据：1） 软切换分支的反复增删；2） 软切换成功率降低；错配的小区链路失步增加。针对上述情况，可以采取重新规划海宁秦山核电站的扰码来避免其发生的可能性。4、 解决方案对海盐秦山核电站3个小区的扰码重新规划，分别使用149、150、151号扰码，避免出现与周边站点产生同扰码的情况。跟踪观察海盐秦山核电站3个小区在接下来几天的性能指标：海盐秦山核电站_2小区PS频繁掉话现象已得到解决，1、3小区指标相比重新规划之前也有明显改善。5、 经验总结在空旷地区，天线应具有足够的下倾角来控制覆盖范围。覆盖范围过大，在覆盖边缘地区形成大范围的弱覆盖区域和不连续覆盖区域，会产生接入及掉话问题；如果周边有其他站点，就有可能因覆盖半径过大而同时收到两个同扰码的小区，产生切换等问题。此外，此问题虽然原因及处理简单，但是比较有典型的意义，尤其是对于某些站点密集扰码复用距离较小的城区优化中，在增加漏配邻区时有可能会加错相同扰码的小区。因此本案例对于此问题的现象和过程进行了详细的分析，以便能为实际中遇到的此类问题提供一个迅速定位问题的借鉴思路。案例五：嘉兴联通综合楼WSF1-1室分出现CE配置不足拥塞现象案例案例编写人：方少俊， 联系 电话：156573720771、 问题简述联通综合楼WSF1-1室分出现CE配置不足拥塞现象2、 发生时间和地点10月25日嘉兴市洪兴西路987号，联通公司综合楼起始时间周期对象名称小区中由于无线网络原因导致CS域RAB建立失败的个数小区中由于空口失败导致CS域RAB建立失败的个数小区中上行CE拥塞导致的PS域RAB建立失败的个数小区中PS域因空口失败引起的RAB指配建立失败的RAB的个数小区中PS域由于无线网络层失败导致RAB指配建立失败的RAB数目小区中PS域RAB指配建立失败的RAB数目（能力不支持）26/10/2009 09:30:0030JXRNC31HW/无线小区:Label=嘉兴联通综合楼WSF1_1, CellID=31241004904949发生具体位置如下：3、 原因分析检查告警，经过维护台核实，联通综合楼WSF1-1小区无告警。排除此因素。检查联通综合楼WSF1-1是否带有直放站，因为直放站对上行会有噪声积累，会直接影响HSUPA速率。经确认，该小区无直放站。检查联通综合楼WSF1-1小区各个业务参数是否配置正常，结果验证是正常的。 对联通综合楼WSF1-1小区覆盖的房间经行覆盖情况测试。测试结果RSCP和Ec/Io均正常。查看其CE资源分配情况：UL CEDL CELocal CellHSDPAHSDPA RRMHS-PDSCH CodeHSUPAHSUPATTICE Mapping rule 1PA43dBm44431113010655331因为联通综合楼WSF1-1用户多，针对分配原则发现，CE资源分配较少。华为设备CE资源分配原则如下：CE Consume Rule Of R99ULConsume CE NoDLConsume CE No3.4K(SF256)13.4K(SF256)1AMR12.2K (SF64)1AMR12.2K (SF128)1PS32K(SF32)1.5PS32K(SF64)1CS64K(SF16)3CS64K(SF32)2PS64(SF16)3PS64(SF32)2PS144(SF8)5PS144(SF16)4PS384(SF4)10PS384(SF8)8CE Consume Rule Of HSUPA(RAN 6.0 feature)Min SFHSUPA Phase1HSUPA Phase2SF642CE1CESF322.5CE1.5CESF164CE2CESF86CE4CESF411CE8CE2*SF421CE16CE2*SF2Not support32CE2*SF2+2*SF4Not support48CENote：1、HSUPA share CE resource with R99 services.2、UPA Phase1 is based on current hardware and could support maximum 1.44Mbps, 10msTTI; E-DPCCH will consume 1 CE and E-DPDCH consumes more processing capability.3、HSUPA Phase2 is based on new hardware supporting maximum 5.76Mbps, 2ms/10ms TTI. The processing capability is optimized. E-DPCCH will not consume CE and E-DPDCH consumes less processing capability. The consumption rule for HSUPA service is described as the table.（1） HSUPA与R99服务资源共享。（2） UPA Phase1基于当前硬件，可以支持最大1.44Mbps 10msTTI; E-DPCCH消耗1个CE资源,E-DPDCH需要消耗更多资源。（3） HSUPA Phase2基于新的硬件，支持最多5.76Mbps, 2ms/10ms TTI。线程性能得到优化。E-DPCCH不会消耗CE资源，E-DPDCH消耗更少资源。HSUPA业务的CE消耗规则被描述为上表。（4） 注：注:HSDPA和R99一样有UL认证,它使用DL中的指定代码,因此不需要消耗CE资源,但同时专用传输信道（DCH）将消耗CE资源。4、 解决方案经过讨论，提出修改CE资源分配。分配后情况如下UL CEDL CELocal CellHSDPAHSDPA RRMHS-PDSCH CodeHSUPAHSUPATTICE Mapping rule 1PA43dBm56431113010655331调整后测试结果为，无拥塞现象发生。5、 经验总结该问题发生在建站时期的可能性是较大的，因为无法估量该站用户量和信道消耗状况，出现CE资源分配不合理导致的拥塞问题。所以经过测试排除干扰和覆盖等原因时，可以在NODEB侧查看CE资源分配情况，对于CE（channel element.）信道处理能力的配置，UL和DL的配置需要合理才能保证上行和下行H业务正常，才能保证业务信道资源充足，避免拥塞。案例六：宁波VSWR值超过告警门限却不上报案例案例编写人：林杰锋 联系 电话：156574762791、 问题简述驻波告警的上报门限值是1.5，却发现一个基站中的一个RRU的VSWR值已经达到了4.4仍不上报驻波告警。2、 发生时间和地点 发生时间 ：2009-10-25发生地点： 宁波联通新大楼5楼 3、 原因分析（1） 首先检查该RRU的VSWR值是否确实为4.4。通过“DSP VSWR”进行软件查询，又拿专业设备进行现场测试，得出的结果均是4.4左右。（2） 再来检查驻波告警的上报门限：DSP VSWRALMPARAM，查得告警门限值是1.5。按照这个值，驻波告警是理应上报的。（3） 前2步均未查出异常，怀疑RRU硬件有问题。拿该RRU与本基站的正常小区的RRU进行更换测试，发现更换后，问题又转移到新的RRU上，可见不是RRU的问题。（4） 现在来看，只可能是软件内部的一些机制问题了，求助于华为总部专家。从反馈的该RRU的输出功率实时检测的结果来看，该RRU的发射功率过于小，这个就是VSWR告警不上报的真正原因。原来是RRU对驻波比上报作了限制的，SRRU的上报限制是最大发射功率-14.5dbm的门限，比如，SRRU硬件的物理最大发射功率是48dbm，那么只有在该RRU实际的发射功率大于33.5dbm时，才会上报驻波比告警。也就是：(实际发射功率)-48-14.5时，才会上报驻波比告警。本案例中的问题RRU的实际发射功率均在21dbm左右，显然不满足上述公式，故无法上报VSWR告警。Time Typical Output Channel No. Carrier No. Carrier Power Power(0.1dBm) (0.1dBm)2009-10-25 11:30:13 212 0 0 2102009-10-25 11:30:15 212 0 0 2092009-10-25 11:30:17 213 0 0 2102009-10-25 11:30:19 213 0 0 2112009-10-25 11:30:21 212 0 0 2102009-10-25 11:30:23 212 0 0 209（5） 现在仅是知道了由于RRU的输出功率偏低而导致无法上报VSWR告警，但并不知道是什么原因导致了该RRU的输出功率偏低。第3点中的测试已经证实了RRU的硬件是没有问题的，现在只有查软件。经过检查该基站的配置文件，发现该RRU上所承载的小区的PCPICH功率参数偏低：ADD PCPICH:CELLID=40301, PHYCHID=2, PCPICHPOWER=360, MAXPCPICHPOWER=378, MINPCPICHPOWER=342;ADD PCPICH:CELLID=40302, PHYCHID=2, PCPICHPOWER=180, MAXPCPICHPOWER=378, MINPCPICHPOWER=150;ADD PCPICH:CELLID=40303, PHYCHID=2, PCPICHPOWER=330, MAXPCPICHPOWER=378, MINPCPICHPOWER=316;从上面的配置可以看出：小区40302的“PCPICHPOWER”和“MINPCPICHPOWER”两个参数都配置的太低，和另两个小区的配置明显有差距。4、 解决方案 使用命令将小区的“PCPICHPOWER”和“MINPCPICHPOWER”两个参数修改成和其他两个小区的参数相近后，该小区的发射功率增大，VSWR值变得低于了上报告警门限，没有驻波告警产生，一切正常。5、 经验总结驻波告警的上报对于RRU的实际发射功率有一定的门限要求。出现类似问题时，可以实时检测RRU的实际发射功率。案例七：宁波WCDMA直放站引起HSUPA上传速率低问题案例案例编写人：宁波网优中心 1、 情况概述针对目前部分室分站点HSUPA速率低的情况，无线网优中心经过统计分析这些问题主要是由于RTWP不达标引起的，经核实这些站点都属于RRU下挂光纤直放站的站点。为彻底调查事件真相，无线网优中心组织了光纤直放站设备厂家、集成商、测试人员、华为技术人员一起配合对5个站点进行了现场问题定位。5个室分站点信息及前期测试情况：站名RTWP厂家站点属性功率光纤直放站厂家配置测试问题雅戈尔厂区7号楼-100广州京信直放站5W京信鄞雅戈尔_1HSUPA速率过小海洋世界正常广州京信直放站10W三维信息学院1扇区HSUPA速率过小蓝天宾馆RTWP正常杭州银河直放站10W三维五交化公司2扇区HSUPA速率过小海曙科创大厦27861RTWP:100,27862RTWP:101;上海东洲RRU级联光纤直放站20W京信S222HSUPA速率过小天合家园-100上海东洲RRU级联光纤直放站20W京信S11HSUPA速率过小通过检查这些站点的H数据配置正确，首先排除了数据配置问题。对这些HSUPA速率低的室分站点统计分析得到，这些室分站点都属于RRU级联光纤直放站的情况，再通过LMT查看这些CELL的RTWP情况，发现RTWP明显偏高，RTWP值在-95dBm与-100dBm。一个CELL正常的RTWP值应该在-105dBm与-107dBm，若小区的RTWP值大于-100dBm，则该小区的HSUPA速率受影响很大，基本上达不到HSUPA正常的速率。但是海洋世界和蓝天宾馆RTWP正常，HSUPA速率过小，这个问题需要需要现场测试再确认。2、 现场排查情况（1） 雅戈尔厂区7号楼 通过现场工程师调测光纤直放站的上行衰减，机房操作人员配合查看RTWP值，同时进行HSUPA测试，对应的调试过程如下表：光纤直放站上行衰减量dBRTWP值HSUPA速率kb/sec3-100706-102758-102.77510-103.287关闭直放站-107580从以上表格可以得出通过调整光纤直放站上行衰减量对应RTWP的值从-100改善到-103，但是改善效果并不明显，HSUPA的速率也没有上去。当关闭直放站的时候RTWP为-107，RTWP值比较理想，同时HSUPA速率有明显改变，达到580kb/sec。 通过调整光纤直放站上行衰减量并没有达到预期的效果，现场工程师没有找到更好的方法，此站调测失败。（2） 海洋世界 此站属于旅游地区，物业人员态度坚决，无法进入现场调测。（3） 蓝天宾馆 到现场复测此站点HSUPA速率在700-800 kb/sec左右，速率正常。（4） 海曙科创大厦 由于物业要求有施工单，沟通无果，无法进入现场调测。（5） 天合家园a) 经华为机房操作人员跟踪RTWP确认该站点RRU底噪偏高问题，两台RRU底噪在-97或-98左右。b) 关闭站点上四台光纤近端机，即相当于RRU下不存在光纤直放站，经测试第一台RRU依然底噪值基本没变化，第二台RRU底噪在正常范围内。为此可判断第一台RRU底噪偏高问题非光纤直放站直接引起，而是在该分支分布系统中存在另外的干扰源；第二台RRU的底噪为光纤直放站引起；c) 调试第二台RRU下的光纤直放站：近端机连机发现原先东洲调试时上下行衰减没进行设置，远端机上下行衰减值分别设置为5dB和0dB，输出功率约37dBm左右；经过设置调整(远端机上下行衰减值分别设置为1和0，近端机上下行衰减值分别设置为18和10，远端机输出功率为30dBm)后，华为技术人员在该覆盖范围内测试该第二台RRU底噪值为-104到-105左右，该测试是为在覆盖区域存在单用户情况下，即该测试人员的上网卡正在使用，因此该值为正常值，当测试人员关闭上网卡后，经机房确认，第二台RRU底噪在-106左右，因此判断该RRU底噪值已经正常；d) 根据第二台RRU的调测判断后，先把第一台RRU下挂的光纤直放站按第二台那样如样调试，然后需要上海东洲解决第一台RRU覆盖范围内(包括下挂光纤直放站的覆盖范围)存在另外干扰源的问题。3、 总结（1） 干扰引起的HSUPA速率低的问题是在室分验证中遇到的最为常见的现象，上行干扰导致的HSUPA速率异常主要表现为上传数速波动且没有达到理论要求，在网管上表现为RTWP异常，主要是偏高或者异常波动。如下图所示：图1：RTWP异常波动具体表现为未做业务时RTWP就已经不正常，做业务时又有较大抬升。在上图中，在未做任何业务时RTWP在-104和-85之间来回波动，而正常情况下应该是一条平滑的直线，值在-106附近，上图很明显是底噪太高（2） 导致RTWP抬升的原因分类： 设备本身质量问题，包括RRU、光纤直放站、合路器、耦合器等器件指标不合格导致的RTWP抬升； b.施工质量问题,如天线、馈线连接头没有拧紧或者做工太粗糙,跳线弯曲太大等都会造成RTWP抬升。 c.光纤直放站引入系统中，若上下行衰减没有调整到位，会明显抬升整个系统的底噪，RTWP抬升明显。（3） 问题建议 室分施工过程中需要确保有源器件、无源器件的施工质量； 直放站功率与增益调节时需要符合实际情况，要与设计方案完全对应。 在3G光纤直放站不是很成熟的阶段尽量不采用级联光纤直放站的方案，优先选择级联RRU。案例八：宁波CS/PS异系统切换指标提升案例案例编写人：周浩联系 电话：156574774971、 问题简述PS异系统切换指标低于达标值。2、 发生时间和地点 时间：2009年10月前。3、 原因分析下图为09年9月宁波网络异系统切换成功率的趋势图: 从上图可以看出，CS异系统切换成功率五周以来走势稳定，且呈现小幅上升的态势。截至上周为止达到98.16%，超出终验指标1。且五周指标均高于终验指标。而对于PS异系统切换成功率五周以来小幅波动，基本在8890左右浮动。选取了所有RNC一周的统计指标如下所示：序号RNC IDCS异系统硬切换成功率(3G到2G)(97%)指标统计12342CS异系统硬切换成功率(3G到2G)(97%)96.35%(2951/3070)22338CS异系统硬切换成功率(3G到2G)(97%)96.72%(1819/1889)32344CS异系统硬切换成功率(3G到2G)(97%)97.95%(1667/1705)42352CS异系统硬切换成功率(3G到2G)(97%)98.26%(845/861)52356CS异系统硬切换成功率(3G到2G)(97%)98.39%(1458/1487)62336CS异系统硬切换成功率(3G到2G)(97%)98.55%(3996/4061)72350CS异系统硬切换成功率(3G到2G)(97%)98.72%(846/862)82348CS异系统硬切换成功率(3G到2G)(97%)98.87%(2964/3007)92340CS异系统硬切换成功率(3G到2G)(97%)98.94%(3172/3215)102358CS异系统硬切换成功率(3G到2G)(97%)99.02%(1825/1844)112354CS异系统硬切换成功率(3G到2G)(97%)99.07%(1277/1291)122346CS异系统硬切换成功率(3G到2G)(97%)99.20%(1738/1756)4、 解决方案针对RNC2342进行专项分析发现如下：IMSI原因值源小区目标小区460015740608139（36）1854689551945316030,4864460015740608139（12）1854689551901216030,4864460015740608115（1）1854689551901216030,4864460015740608005（1）1854689551901216030,4864460015740608139（9）1854689551945116030,4864460015740608139（1）1852723681945116030,46992460015740608139（7）1854689551931316030,4864460015740611158（1）1854689551931316030,4864主要是由于460015740608139 这一个IMSI引起的且都为切入到4864小区，因此，对4864的2G的基本信息与3G定义的进行对比发现如下：GSMCELLINDEX检查GSMCELLINDEX结果 检查LAC结果检查Bsic结果 检查BCCHARFCN结果48644864True16030True560119False更改此2G小区的BCCHARFCN到正确配置。并重新对2G基本信息核对，修改63条BSIC修改，47条BCCHARFCN进行修改，对下周指标将有所提升。通过修改参数配置错误的小区后，目前各个RNC CS/PS异频、异系统小区的指标如下所示：2009-10-28（更改后宁波现网CS/PS异系统指标汇总）RNC2358CS异系统硬切换成功率(3G到2G)(97%)98.28%(285/290)PS异系统硬切换成功率(3G到2G)(90%)97.08%(131/137)RNC2356CS异系统硬切换成功率(3G到2G)(97%)98.18%(270/275)PS异系统硬切换成功率(3G到2G)(90%)93.48%(86/92)RNC2354CS异系统硬切换成功率(3G到2G)(97%)99.55%(218/221)PS异系统硬切换成功率(3G到2G)(90%)95.80%(655/691)RNC2352CS异系统硬切换成功率(3G到2G)(97%)97.47%(154/158)PS异系统硬切换成功率(3G到2G)(90%)96.51%(83/86)RNC2350CS异系统硬切换成功率(3G到2G)(97%)99.21%(125/126)PS异系统硬切换成功率(3G到2G)(90%)92.15%(457/497)RNC2348CS异系统硬切换成功率(3G到2G)(97%)99.18%(483/488)PS异系统硬切换成功率(3G到2G)(90%)95.19%(744/790)RNC2346CS异系统硬切换成功率(3G到2G)(97%)9