564501137浙江联通WCDMA网典型案例分析

1、中国联通浙江分公司wcdma网典型案例分析（20091001-20091015）（第二期）目录案例一：绍兴传输光端机未加线路时钟保护导致基站线路时钟源抖动异常案例3案例二：绍兴快阁苑基站小区功率不一致导致基站license下发失败案例5案例三：绍兴科创大厦附近弱覆盖引起掉话案例8案例四：湖州边缘小区ps异系统切换参数修改后上网速度慢案例11案例五：湖州边缘小区重选切换存在的问题案例14案例六：湖州基站误码导致基站bootp启动侦听失败案例17案例七：嘉兴多rru级联底噪未更新设置导致hsupa速率偏低问题案例21案例八：宁波rnc前后台数据不一致问题处理案例28案例九：舟山多普达d200用户掉

2、话问题案例31案例十：湖州漫游用户上网感知慢问题案例33案例十一：丽水ps业务上网速率12分钟后降低到零问题案例38案例十二：温州联通龙湾机房干扰问题案例40案例一：绍兴传输光端机未加线路时钟保护导致基站线路时钟源抖动异常案例案例编写人：潘海龙 联系电话：156575720581、 问题简述绍兴rnc6（v200r010c01b061）下新昌鼓山等14个站点开通后均有参考时钟源异常告警 ,告警id：1008。在基站近端维护终端上用命令“dsp clkstat;”查询时钟状态，显示时钟源异常，时钟处于自由震荡状态；打开实时时钟检测，显示时钟源偏差较大。2、 发生时间和地点发生时间：2009-9-

3、8发生地点：绍兴sxrnc06hw3、 原因分析wcdma基站时钟精度（0.05ppm）要求较高，绍兴基站时钟源配置的是线路时钟，基站从接入的2m线中锁定获取。（1） 从观察到的现象看，问题站点属于线路时钟失锁，基站启用了自带的晶体时钟。这些站在同一rnc下，该rnc下其它站点（约100个）均正常，基本可以排除rnc侧问题，那么问题有很大可能出现在传输和基站侧。（2） 检查基站2m线配置，和2m线状态，均正常；用“lst lnksrc:;”检查线路时钟配置，无异常；（3） 该局基站默认从配置的第一条2m线中获取时钟，考虑时钟可能受到的传输质量影响，尝试更换时钟获取线路，如改从第二条2m线中获取

4、时钟，这样做告警消失！但查询时钟状态，显示时钟始终处于“快捕”状态，无法锁定，怀疑问题可能并未彻底处理掉。观察约2小时后，告警复现。（4） 在传输网管上查询这些基站，首先发现这些站在同一传输环下，怀疑该时钟问题是同一原因所致。（5） 检查传输时钟，从传输网管“时钟透视图”中查看光端机时钟状态，发现问题站点下挂的光端机没有线路时钟保护，使用的是自带时钟，确定基站线路时钟源抖动异常由此引起。4、 解决方案传输光端机加上时钟保护，再检查基站时钟状态，并观察时钟实时监测，约10分钟，基站线路时钟锁定，并且监测到的时钟无偏差，且几个基站的时钟异常相继都消失，问题解决。5、 经验总结在sdh网中，各个网元

5、通过一定的时钟同步路径一级一级地跟踪到同一个时钟基准源，从而实现整个网络的同步，遇到传输引起的时钟问题，需要逐级，从下到上检查nodeb传输经过的传输设备时钟设置，一般检查传输设备的时钟是否跟随上级时钟，传输环路有没有异常。案例二：绍兴快阁苑基站小区功率不一致导致基站license下发失败案例案例编写人：潘海龙联系 方式：156575720581、 问题简述在w网建设过程中发现越城快阁苑（bts3900 v200r010c01b067 ）基站小区业务测试正常，除商用license未下发外，无其他异常告警。但在通过m2000 （ v2r8c01b060spc008 ）向基站下发商用license

6、时失败，提示“网元重新设置失败”。如下图所示：2、 发生时间和地点发生时间：2009-8-13发生地点：越城快阁苑基站3、 原因分析 （1） 通过m2000下发基站license失败时常见的情况有：基站断连，此时提示“网元未连接”；基站license资源分配与实际数据配置不一致，且往往问题都与小区相关，如配置了三个小区，而license控制项中只分配了两个小区，又如小区功率实际开到47dbm，而 license分配的是43 dbm的小区，等等，此种情况一般会提示“网元重新设置失败”。显然，后一种情况的可能性较大。（2） 在rnc（v200r010c01b061）侧运行lst cell，检查rn

7、c中小区配置数据 ，查到该基站配置了3个43dbm的小区，而m2000中license资源与此一致，未发现异常。（3） 在基站侧运行 dsp cellcfg 检查逻辑小区配置，3个小区，最大发射功率43 dbm，也未发现异常。（4） 询问之前与该基站的相关操作，得知该基站小区功率曾经调整到47dbm做测试，之后恢复到43dbm ，问题可能出在这次小区功率调整上。（5） 考虑到基站license的小区功率控制项控制的是基站本地小区功率，而非逻辑小区功率，并且业务正常的情况下本地小区功率和逻辑小区功率可能不一致。（6） 在rnc 侧运行 dsp cellchk查看nodeb上报的小区最大发射功率时

8、发现小区最大发射功率为47 dbm ，找到问题所在。4、 解决方案rnc侧用dea cell先闭塞小区，用mod cell修改逻辑小区功率 ；在基站侧用mod locell 把本地小区功率修改为43 dbm ；重新激活小区，并在m2000上分配基站license ，成功下发，问题得到解决。5、 经验总结在检查调整该基站功率的过程得知，原先在恢复小区功率的时候只在 rnc侧运行了mod cell把逻辑小区功率从47 dbm 调整到43 dbm，基站侧未做过任何调整，显然这样做不正确。而正确的修改基站功率的操作过程是 ：先在rnc侧用dea cell闭塞小区 ；再在基站侧用mod locell 修

9、改本地小区功率；最后激活小区。案例三：绍兴科创大厦附近弱覆盖引起掉话案例案例编写人：石贤富联系 方式：156575720481、 问题简述dt测试过程中，发现科创大厦东北角由于切换不及时产生了掉话。2、 发生时间和地点发现时间：2009-09-16。发生地点：绍兴越城城东科创大厦附近。3、 原因分析引起此弱覆盖点的主要原因：科创大厦楼层较高，并且由于天线贴着楼面安装，导致一扇区和二扇区间出现一小段的弱覆盖区域，车辆高速行驶时候可能会出现因为激活集更新超时导致的掉话现象。4、 解决方案将科创大厦第一扇区采用功分器分裂一个扇区，并采用低增益的天线，覆盖科创大厦的楼下，使问题得到解决。下图为调整后复

10、测结果。5、 经验总结天线的安装条件往往由于一些客观的外部因素，无法完全理想的进行安装。这时需要我们通过对无线知识的理解，灵活采用一些创新的方法，或将一些2g采用的方法引用到3g的建设及网优中。本案例就采用了小区分裂的方法解决了弱覆盖区。案例四：湖州边缘小区ps异系统切换参数修改后上网速度慢案例案例编写人：沈忠惠联系 电话：156572726891、 问题简述为了保证边缘小区覆盖区域业务的正常使用，现网对边缘小区的部分异系统切换门限参数进行了修改（cs业务异系统测量rscp启动门限由-100dbm改成-95dbm，ps业务异系统测量rscp启动门限由-110dbm改成-95dbm，cs业务异系

11、统测量rscp停止门限由-97dbm修改为-92dbm，ps业务异系统测量rscp停止门限由-107dbm修改为-92dbm），修改参数后能保证业务的连续使用，在覆盖很差的区域能及时切换到2g网络上。在参数修改后，个别用户反映上网速度慢，收发邮件困难。2、 发生时间和地点发生时间：2009年8月19日。发生地点：长兴科技创业园-1覆盖方向的小区。3、 原因分析修改边缘小区的异系统切换参数后，用户反应手机信号比以前好，但上网速度比以前慢了。在进行现场测试时发现该用户所在位置由于房屋阻挡，深度覆盖不足，rscp值在-100到-108dbm内波动，由于修改了异系统修换参数，该位置占用在2g网络上。2

12、g的电平波动较大，在-85dbm到-97dbm之间，从3g切换到2g上后，上网速度有明显的下降。由于2g的上网速度本来不高，加上占用在2g网络上的用户的增多，导致上网速度更加慢，有时连网页都打不开。4、 解决方案由于边缘区域rscp覆盖弱，给用户的直接感觉是信号格数少、信号差，所以调整了边缘小区的异系统切换参数，使得覆盖相对差的区域能占用在信号较好的2g网络上。但占用在2g网络上后，明显的感觉上网速度慢很多，为了保证用户的上网业务需要，我们恢复了长兴科技创业园-1小区的ps异系统切换参数。具体调整方案如下：（1） 调整边缘小区的ps业务异系统测量rscp启动门限为-110dbm。（2） 调整边

13、缘小区的ps业务异系统测量rscp停止门限为-107dbm。参数调整后，测试结果正常，能有效保证用户占用3g网络进行数据业务。5、 经验总结保证边缘小区覆盖区域业务的正常使用，对全网边缘小区异系统切换门限参数进行了调整。但对于实际各种不同的业务应用场景，需根据用户的具体使用情况对参数做一定个性化的修正。本案例中，在进行边缘小区异系统切换参数的调整时，要考虑到用户对上网速度的要求和感受，使用户尽可能多的占用在3g网络上，保持高速上网。经验证测试，在rscp值到达-105dbm时，3g网络的上网速度还可以到达3m。案例五：湖州边缘小区重选切换存在的问题案例案例编写人：沈忠惠联系 电话：156572

14、726891、 问题简述现网中边缘小区重选切换存在问题，导致边缘小区的rrc连接成功率较市区站点低，影响用户感受。2、 发生时间和地点发生时间：2009年8月。发生地点：南浔开发区西北角。3、 原因分析边缘小区由于站点稀少，网内干扰小，通常当rscp为-110dbm左右时，ec/io仍然可以保持在-10db左右。目前的3g/2g互操作策略是只要满足驻留在w的条件，就尽可能重选驻留在w。因此导致了在边缘小区，当w的rscp在-110dbm以下（手机显示1格），而g网电平为-60dbm时，仍驻留在w网。在跨省边界，如湖州南浔与江苏边界，南浔开发区西北角目前暂没有w站点，而江苏在湖州边界是全覆盖，会

15、导致该处边界2km以内的湖州3g用户长期驻留到江苏的网络，话务量也会跑到苏州去。目前，w切换电平设置也偏低，在边缘小区存在类似重选的问题，ec/io触发不了切换，要等电平很弱才切换到2g，给用户造成联通3g网络覆盖差的印象。4、 解决方案在边缘小区，由于3g/2g互操作参数设置不合理（cs业务异系统测量rscp启动门限为-100dbm，cs业务异系统测量rscp停止门限为-97dbm），当rscp值为-100dbm左右时，由于还未到达启动压模门限，手机一直驻留在w网络上，而此时rscp值已经很低。若在这时发起呼叫，会使得接入成功率较低，建议调整cs业务异系统测量rscp参数门限。具体调整方案如

16、下：（1） 调整边缘小区的cs业务异系统测量rscp启动门限为-95dbm。（2） 调整边缘小区的cs业务异系统测量rscp停止门限为-92dbm。对w ec/io要求，现网中设置为-10db，对边缘小区基本不起作用，再提高也无多大意义，边缘小区即使电平在-100dbm以下，ec/io也通常在-8db以上。5、 经验总结在边缘小区，信号一般电平低，而质量不会太差。在设置参数方面，应多考虑以rscp为参考。案例六：湖州基站误码导致基站bootp启动侦听失败案例案例编写人：顾晓江联系 电话：156572720631、 问题简述某局在开站过程中长时间无法成功启动bootp，组网情况：rnc-sdh传

17、输网络-nodeb；使用4e1传输。2、 发生时间和地点发生时间：9月26日。发生地点：德清美都现代城室分基站3、 原因分析（1） 传输工程师配合在传输网管上做环断测试正常；在nodeb近段对rnc做环断测试正常。（2） 国内w项目nodeb缺省配置文件，阻抗特性为：75欧，非平衡模式，在配置文件生效的情况下，与单板拨码开关设置无关。（3） 传输质量测试：由于传输质量的好坏直接影响承载的数据，导致bootp发包丢失或错包等，因此选择在nodeb侧进行了在线误码测试，测试结果反映设备存在高误码，参考如下：+hw-airbridge2009-03-2918:32:03o&m#42%stpe1t1o

18、nltst:srn=0,sn=7,sbt=base_board;%retcode=0执行成功。e1/t1在线性能统计-机柜编号=主柜机框编号=0槽位编号=7子板类型=基板端口编号=0线路编码类型冲突错误率=0.000000e+00同步字错误率=2.511962e-05crc检验错误率=5.263158e-05e比特错误率(e1)/block错误率(t1)=1.052632e-04-end（4） 为进一步证实传输质量引起bootp侦听失败，做如下测试：从基站缺省配置文件看出，缺省配置文件的传输数据配置在6号槽位，而实际上传输接口板在7号槽位。通过近段登录nodeb建立imagroup后，出现ai

19、s告警：hw-airbridge2009-03-2919:05:42o&m#185%addimalnk:srn=0,sn=7,sbt=base_board,imalnkn=1,imagrpsbt=base_board;%retcode=0执行成功。-end+hw-airbridge2009-03-2919:06:18o&m#188%dspe1t1:;%retcode=0执行成功。e1t1状态-机柜编号=主柜机框编号=0槽位编号=7子板类型=基板端口编号=0链路状态=存在ais告警机柜编号=主柜机框编号=0槽位编号=7子板类型=基板端口编号=1链路状态=存在ais告警-endais（alarmi

20、ndicationsignal：告警指示信号）：没有帧格式的全“1”信号。发送到对端，用来指示本端pcm设备或下游设备发生严重故障（线路已经不可用）。告警台出现此告警表示对端设备不可用。也就是说当a端发送断掉或者帧失步时，b端就会向a端发送rai告警指示信号，说明处于帧丢失或者帧失步状态。同时b端向c端发出ais告警指示信号，指示本端没有收到a端发送出的正确信号。4、 解决方案由施工队下站进行传输施工工艺整改，整改完成后，基站成功启动bootp。5、 经验总结根据以上各个方面的分析，如果站点存在较大的误码，影响传输承载的数据，这种误码存在导致bootp启动侦听失败，最终会影响到维护通道的建立。

21、建议在开通基站前，检查传输质量，特别是2m接头的制作工艺等问题，通过物理逐步逐段的环回，排查传输，消除误码影响。案例七：嘉兴多rru级联底噪未更新设置导致hsupa速率偏低问题案例案例编写人：沈越丰联系 电话： 156573720721、 问题简述桐乡巨石集团wsf2_1小区由于底噪设置不当导致hsupa业务速率偏低（平均速率150kb,峰值速率182kb），其他业务均正常。如下图所示：2、 发生时间和地点发生时间：2009年10月7日 发生地点：桐乡巨石集团3、 原因分析（1） 检查告警，经过维护台核实，该小区无告警。排除此因素。（2） 检查桐乡巨石集团wsf2_1小区是否带有直放站，因为直

22、放站对上行会有噪声积累，会直接影响hsupa速率。经确认，该小区无直放站。（3） 对桐乡巨石集团wsf2_1小区覆盖的房间经行覆盖情况测试。测试结果rscp和ec/io均正常，如下图所示： rscp for 1st best in active set ec/io for 1st best in active set（4） 在维护台查看该小区的物理拓扑结构，发现该小区由两个 rru级联组成，如下图所示：（5） 对两个rru空载时的上行总带宽接收功率（rtwp）经行测量，结果如下：时间0号载波，rx接收中心频点号0号载波主集天线rtwp(0.1dbm)2009-10-7 10:549763-10

23、602009-10-7 10:549763-10612009-10-7 10:549763-10602009-10-7 10:549763-10602009-10-7 10:549763-10612009-10-7 10:549763-10582009-10-7 10:549763-10612009-10-7 10:549763-10552009-10-7 10:549763-10592009-10-7 10:549763-10612009-10-7 10:549763-10602009-10-7 10:549763-10592009-10-7 10:549763-10612009-10-7

24、10:549763-10602009-10-7 10:549763-10602009-10-7 10:549763-10602009-10-7 10:549763-10602009-10-7 10:549763-10582009-10-7 10:549763-10592009-10-7 10:549763-1058“桐乡巨石集团sf1”rru空载时的rtwp值基本稳定在-106，属于正常范围。时间0号载波，rx接收中心频点号0号载波主集天线rtwp(0.1dbm)2009-10-7 10:549763-10682009-10-7 10:549763-10692009-10-7 10:54976

25、3-10692009-10-7 10:549763-10692009-10-7 10:549763-10682009-10-7 10:549763-10682009-10-7 10:549763-10682009-10-7 10:549763-10682009-10-7 10:549763-10682009-10-7 10:549763-10682009-10-7 10:549763-10682009-10-7 10:549763-10682009-10-7 10:549763-10682009-10-7 10:549763-10682009-10-7 10:549763-10682009-1

26、0-7 10:549763-10682009-10-7 10:549763-10682009-10-7 10:549763-10682009-10-7 10:549763-10682009-10-7 10:549763-10692009-10-7 10:549763-1069“桐乡巨石集团sf2”rru空载时的rtwp值基本稳定在-106.9，属于正常范围。由以上两个rru的测量情况，可以排除是由于外部干扰引起的hsupa速率低问题。尝试降低桐乡巨石集团wsf2_1小区的主公共导频功率：33dbm27dbm。经现场测试，hsupa速率仍无提升。将桐乡巨石集团wsf2_1小区下2个rru中的一个

27、闭塞，只留一个rru，再对覆盖区经行测试。结果如下：rru名桐乡巨石集团sf1桐乡巨石集团sf2hsupa速率rru管理状态解闭塞闭塞正常闭塞解闭塞正常解闭塞解闭塞速率偏低由此怀疑是否因为rru级联数字合路引起上报rnc的rtwp的值升高，从而导致hsupa速率低。当多个rru级联共小区时，下行多个天线发送相同的数据，上行多个rru的信号直接线型叠加送给基带处理，上行信号合路会带来底噪抬升，这样nodeb上报给rnc的rtwp数值就会偏高。但偏高的rtwp并不是真正物理意义上的底噪被抬高，因此需要在rnc维护台上修改底噪值来规避，否则rnc会认为这时上行负荷很高（w中用rtwp来表征上行负荷）

28、，导致准入拒绝或者ps的速率降低。多rru共小区时rnc上底噪计算及修改方法为：多rru共小区的rtwp的抬升量：10log（n），n为级联数。在rnc侧需要调整的背景噪声：61100log（n）。背景噪声设置值对应的rtwp：112（背景噪声设置值1）/10mml命令：add cellcac4、 解决方案桐乡巨石集团wsf2_1小区共有2个rru，根据上一节的计算方法，在rnc上将小区的背景噪声由61修改为91。修改小区底噪后对覆盖区域经行复测，hsupa的平均速率达到237.3kb，峰值速率为301.1kb，为正常水平。复测时hsdpa的平均速率达到618.67kb，峰值速率为688.82

29、kb，也正常。调整后hsupa复测速率调整后hsdpa复测速率（同调整前）5、 经验总结上行干扰是造成上行业务异常的主要原因。在处理上行问题时，对干扰的定位是处理问题的关键。wcdma系统上行异常干扰主要分为内部干扰和外部干扰。内部干扰可能由于工程质量，或者天线、连接器等器件本身质量等引起；外部干扰可能是由于直放站、手机干扰器等设备引起。定位上行干扰可通过实时测试小区或rru的rtwp来发现问题。当多rru共小区时，因多rru级联造成的底噪抬升也会影响上行业务，所以在多rru级联时，rnc上需根据级联的rru数量正确设置小区底噪，以规避级联造成的影响。案例八：宁波rnc前后台数据不一致问题处理

30、案例案例编写人：林杰锋联系 电话：156574762791、 问题简述rnc调测阶段出现actcrc输出有前后台不一致表项。2、 发生时间和地点2009年9月11日，宁波联通新大楼机房3f rnc53、 解决方案（1） 该rnc版本是bsc6810v200r010c01b061，用actcrc检查前后台数据一致性时输出如下信息：%actcrc:;%retcode=0executionsucceeded.subrackno.0slotno.6subsystemno.0boardtypescu-tablenamecheckresulttiproutetblcheckinconsistentcrcc

31、heckoperationcompleted(numberofconsistenttables=103,others=1)subrackno.0slotno.2subsystemno.0boardtypespucrccheckresult-crccheckoperationcompleted(numberofconsistenttables=395,others=0)subrackno.0slotno.2subsystemno.1boardtypespucrccheckresult-tablenamecheckresultcellhsupaparascheckinconsistentcrcch

32、eckoperationcompleted(numberofconsistenttables=394,others=1)说明0子框6槽位的scu板上的tiproutetbl表和2槽位的spu板上的cellhsupaparas两个表前后台不一致。（2） 用比较命令查看具体不一致的内容：cmptbldata:bt=scu,srn=0,tname=tiproutetbl;tiproutetbl-record1.fromfam:uliproutedest=184313347uliproutemask=4294967295uliproutenexthop=174071811uciprouteslotin

33、dex=14ucnexthopslotindex=14ucnexthopportindex=0ucpriority=80ucroutetype=0frombam:correspondingresultsnotfound(numberofresults=1)datatableoperationsucceeded根据比较的结果发现，前台fam比bam的数据多了一条iprt的数据。（3） 转换出路由的值：uliproutedestuliproutemaskuliproutenexthop1843133474294967295174071811afc6603ffffffffa60200310.252.

34、102.3255.255.255.25510.96.32.3（4） 重新下发这条路由数据到bam。（5） 用同样的方法修改第二个表的内容。（6） 再次用actcrc比较前后台数据发现已一致。4、 经验总结bam是工作在主备双机工作模式下，数据出现不同步原因主要是由于主备bam在数据不同步状态下发生异常倒换时，如果不小心误操作下发数据同步命令，会丢失少量的数据从而使前后台不一致，如果bam里数据少于fam的情况下，用复位rnc来同步会使前台的数据也丢失。所以用手工的方式修改可以避免复位rnc，也不会丢失数据。平时尽量避免倒换主备bam，如需要倒换，需在倒换之前通过dsp bam检查主备bam是否

35、正常同步，确认同步以后再进行倒换，避免出现前后台数据不一致。案例九：舟山多普达d200用户掉话问题案例案例编写人：许重九联系 电话：156570979421、 问题简述用户投诉多普达d900掉话严重2、 发生时间和地点发生时间：2009年9月-10月。发生地点：定海、普陀城区。3、 原因分析 后台chr分析发现该用户全网掉话率极高，全天掉话达30余次，现场测试ec/io、rscp均属正常，amr、vp、hspa测试正常均正常，排除ran侧问题，跟踪用户信令，发现ue信令同步失败。华为反应该终端较老，在全国普遍存在掉话严重现象，故将原因定位为终端问题。后将问题提交华为研发，研发给出分析结果如下：

36、现网ran10版本默认开启下行链路盲传输格式检测功能（*），由于多普达d900较老，该终端在amr速率格式超过ts 34.121规定必须检测的3种（12.2 kbit/s、7.95 kbit/s、1.95 kbit/s）时，手机将不支持盲传输格式检测，导致掉话。4、 解决方案由于现网ran10版本网络侧所发送的传输块包含tfci，华为研发认为关闭该开关不会对网络性能产生影响，建议关闭以解决该掉话现象。在ran侧将downlink_blind_detection_switch关闭后该问题得到解决。5、 经验总结wcdma发展多年，经历了多个版本的演进，现网共存了多种版本的ue，在处理用户投诉时需

37、结合用户终端综合分析原因，调整现网参数以提高用户感知度。（*）盲传输格式检测是指手机接收到的传输块没有包含传输格式说明（transportformatcombinationidentifier，tfci）的情况下，终端必须能正确检测出以下9种速率数据包的传输格式：12.2 kbit/s*、10.2 kbit/s、7.95 kbit/s*、7.4 kbit/s、6.7 kbit/s、5.9 kbit/s、5.15 kbit/s、4.75 kbit/s、1.95 kbit/s*，其中*标注的3种速率是ts 34.121中规定必须测试的。与其他测试项不同的是，盲检测不但要测试bler，还要测试盲检测

38、率（fdr）。测试fdr时，终端需要正确检测出下行传输格式，解码其数据并根据检测的传输格式产生相应的tfci比特，手机环回数据并带循环冗余校验，在软交换侧测试上行tfci错误的个数。盲检测需要在静态信道和动态信道多径环境case3两种情况下进行测试。接收机的ai性能测试由错误告警概率和正确检测概率共同决定，测试在静态条件下进行。盲检测和ai性能是wcdma终端测试所特有的。案例十：湖州漫游用户上网感知慢问题案例案例编写人：沈忠惠联系 电话：156572726891、 问题简述测试卡卡号imsi：460016024342902，该卡目前属于德清分公司。以下测试结果，如果

39、测试地点没有特别注明的，都在湖州太湖路联通公司办公楼，覆盖区域属于rnc2。2、 发生时间和地点发生时间：2009年7月15日发生地点：德清分公司 3、 原因分析（1） 数据速率测试上新浪视频网，打开两三个视频后，发现速率可以达到4mbps以上，如下图所示：说明该卡在湖州数据速率正常，但发现进行视频点播很慢。（2） 时延测试 湖州本地上网卡测试结果如下：ping 221.12.1.228172.31.254.9属于本地局域网地址，124.160.58.137来自浙江省网通，60.12.6.42来自杭州网通。 该漫游卡测试结果如下：ping 221.12.1.228（tracert是在德清联通分

40、公司测试的，该覆盖区域属于rnc3）经上网查询，192.192.1.21和192.192.2.9 ip来自台湾，61.148.32.109来自北京网通。另外，也用该测试卡测尝试过tracert百度、新浪、google等网站，第一跳的地址都是192.192.1.*.（3） 信令消息分析德清漫游用户cdtlog（用户感知网速慢）：本地用户cdtlog（正常）用两张不同的sim卡，在相同地点测试，用同一张上网卡（华为180e），感知漫游卡上网速度慢，而本地卡上网速度正常。从信令分析中可以看出，该测试点覆盖信号良好，漫游卡开卡速率下行在7.4mbps以上，上行开卡速率在5.9mbps。所以可以肯定原因

41、不在于无线侧，而且也不在于漫游卡的开卡速率和上网卡（终端上）。4、 解决方案在核心网上进行路由优化后，问题解决。5、 经验总结在时延测试中，漫游的用户比较本地用户，时延多110ms左右，tracert多个网址，发现第一跳地址都是192.192.1.*，这一跳花的时间都在130ms以上。在同一地点测试，用本地上网卡，测试一切正常，而用漫游外地卡，测试发现时延大，导致用户感知上网慢。通过和核心网工程师沟通，得知本省卡和外省卡的业务流程分别如下：（1） 外省卡业务流程是浙江本地sgsn1-承载网（本地承载网和联通全国gn承载网）-北京ggsn-业务网站服务器（2） 本省业务流程是浙江本地sgsn1-

42、承载网（本地承载网）-本地ggsn-业务网站服务器从时延测试结果看，北京ggsn到业务网站服务器的时延大致在30ms左右，这个应该在正常范围内，所以初步断定问题出在承载网上，需要对承载网的路由表进行优化。案例十一：丽水ps业务上网速率12分钟后降低到零问题案例案例编写人：朱轶联系 电话：156572293991、 问题简述 ps业务上网速率12分钟后降为零。2、 发生时间和地点兄弟省份出现过。3、 原因分析（1） 用两个终端(mf330数据卡和高通6280手机)同时测试，分别都在12分钟左右速率降为0，用此方法排除了终端的原因。（2） 将iub口传输承载用atm方式和ip方式都试了一遍，还是有

43、同样的问题，而且在12分钟速率降为0后查看用户面pdcp层统计，发现是cn没有下行包发下来，所以排除了iub口的原因。（3） 在rnc升级前，用306的版本时没有该问题，说明这个问题是在升级到307的版本后引入的，从另一方面也说明了不是cn的问题。（4） 将问题缩小在iu口，由于每次都是12分钟，怀疑是定时器引起的限制，而该定时器是在307系统中引入的或者在307系统中定时器的默认值设小了。（5） 抓取了信令仪码流进行分析，发现在速率降为0之前rnc向cn发了释放消息（sccp层），释放原因：expiration of receive inactivity timer，之后没有任何下行数据。在

44、ps业务建立后，rnc会定时发it消息（sccp层）给cn，但cn一直没有回，当在12分钟左右的时候接收it消息的定时器超时，sccp层发起释放。（6） 接收it消息的定时器默认值为72000秒，由于爱立信cn一直不回消息，会导致定时器超时。4、 解决方案通过修改rnc侧该定时器的值来解决，在增大了r_mpprtmrdft表中t_it_receive字段的值后问题解决。5、 经验总结日常维护和优化工作中应加深对各类参数特别是与业务相关参数的理解，发现和解决各类隐性网络问题。案例十二：温州联通龙湾机房干扰问题案例案例编写人：范昕潮联系 电话：156577900211、 问题简述联通公司内部员工反

45、映在龙湾机房门口经常打电话接不通，从统计上看，rrc连接成功率较低，部分时段甚至只有左右，但rab建立成功率基本为100%。检查网络的无线环境，发现统计上，该站附近上行干扰很强。以下为9/229/24日所有时段的上行底噪变化趋势线。attention：在载波上，上行干扰非常强，其中、载波的平均干扰强度为-86db左右；载波的方向的干扰强度为-76db左右。attention:在载波上，干扰强度明显减弱。其中4、5载波的干扰底噪在-100以下；载波在-95以下。但同时也可以看出，载波的干扰强度较其它两个方向强（与载波的方位相同），且有周期性变化。2、 发生时间和地点发生时间：9月底。发生地点：温

46、州分公司大楼。3、 原因分析（1） 干扰方向为度方位（载波）最强。（2） 干扰对fdd1的影响强烈；对fdd2的影响相对较弱。根据以上结论，按照以下方法进行干扰排查和解决用户投诉。用小天线挂接在nodeb馈线接口，然后统计上行底噪。若底噪降低，可排除设备内部产生噪声的可能。执行：2009-9-25 14:29我们将第三载波的天线断开，改用室内微蜂窝使用的吸顶天线。观察时段：2009年9月25日14:292009-9-26年9月26日9:14。rssi的统计趋势图如下：结论：可以看出，利用indoor天线替换室外大天线后，底噪下降了20db以上。这说明，现网底噪抬升源自设备外部。4、 解决方案考

47、虑到干扰排查较为困难。同时联通用户比较集中，建议目前将业务转移到fdd2上进行。待干扰源排查后，再重新将业务调整回fdd1上。为了达到以上目的，需要对参数调整如下：parameter nameold valuenew valuefdd1sintersearch616umtsneighrelationidumtsneighbouring/0 umtsneighbouringrelation/1umtsneighbouring/0 umtsneighbouringrelation/2serviceprioritygeneraltableconfclassidradioaccessservice/0 imcta/0 serviceprioritygeneraltableconfclass