故障处理案例培训.ppt

《故障处理案例培训.ppt》由会员分享，可在线阅读，更多相关《故障处理案例培训.ppt（71页珍藏版）》请在三一办公上搜索。

1、交流内容,网优常用手段介绍,1,故障处理案例,2,基站硬件故障基站软件故障直放站故障频率干扰数据定义错误参数调整TRA故障RPP故障,3,经验总结,网优常用手段介绍,NCS测量统计功能介绍NCS（BA-RECORDING）测量统计功能是ERICSSON交换机中自带的一项无线测量统计功能，它搜集MS在激活模式下的测量报告信息，包括服务小区和相邻小区信号强度、信号质量、对应的测量点数目等。该功能主要用于测量不同小区间的信号重叠覆盖情况，进行邻区拓扑结构优化及评估越区覆盖，还可用以指导天线合理性优化。MRR测量统计功能介绍MRR是爱立信系统针对测量报告处理的专用工具，能够提取全网所有手机通话的测量报

2、告，提取的内容包括：上下行通话电平、上下行通话质量、TA值分布等，通过提取MRR数据我们能够对网络场强覆盖、通话质量进行全面评估。RIR测量统计功能介绍RIR通过载波接收机对上行频段的干扰电平测量，得到指定频段所有频率的上行干扰电平。与ICM上行干扰测量统计不同的是RIR测量精度是到频率，而ICM测量只是到小区级。上行干扰可能是频率规划不当所引起的问题，更可能是直放站、微蜂窝干放或外部干扰引起的。因此利用RIR统计功能可较为全面分析现网的上行干扰分布，对每个小区所使用的频段上行干扰电平有清淅的了解。,网优常用手段介绍,CTR测量统计功能介绍CTR功能用于搜集小区通话测量报告，记录了话务行为相关

3、的信令流程和测量报告，用于分析小区的呼叫流程（事件）细节，如呼叫建立、切换操作和信道释放过程以及相应的测量报告等，CTR可以应用于定位小区故障。MTR测量统计功能介绍MTR用于搜集定义特定用户的测量任务，通过MTR，可以实时记录相关用户在通话过程当中的无线参数，包括位置更新、短信息以及通话，在通话过程中还详细记录了手机及BTS的上下行测量报告，记录的内容包含无线相关的信息如信号强度、通话质量以及相关小区信息等。MTR数据目前已在网络优化中得到了广泛应用，包括小区故障分析、用户投诉处理等。,故障处理案例,基站硬件故障1、话务量下降类1）市区安丰1、长冲1在8月14号下午扩容后均出现话务量突然下降

4、的现象，通过话务统计分析2个小区的申请次数都很少，通过MRR测量发现下行信号正常，但上行信号在-110dbm以下，如下图：安丰1处理前MRR测量情况，上行没有信号：,故障处理案例,长冲1处理前MRR测量情况，上行没有信号：,故障处理案例,由于均为上行弱信号，因为初步判断为扩容后天馈线系统的接收部分出现故障或接错连线引起，通知基站技术人员到现场检查处理，重新整理连线后指标恢复正常，处理前后指标对比如下：安丰1处理前后指标对比：,故障处理案例,长冲1处理前后指标对比：,故障处理案例,2）阳山上坪2小区从4月24日开始没有话务量，接入申请次数为0，尝试将其BCCH频点对应的载波闭掉，使BCCH频点占

5、用到另一个载波后，话务量恢复正常。由此可判断，BCCH频点对应载波存在隐性故障，导致用户无法接入该小区，已派单更换载波，处理前后两天晚忙时指标对比如下所示：,故障处理案例,3）G1碧桂园2基站从13号9点开始没有话务，对基站的设备进行定位均没有发现异常，也没有FAULTY CODE。经了解该站带有光纤分布系统，通知基站技术人员到站检查后发现该基站所带的分布系统电缆断了，重新修复后恢复正常，处理前后同时段统计对比如下：,故障处理案例,4）H2新民村1 出现没有呼叫申请，话务量变为0的情况，此基站三个小区共用机架但是新民村2、3小区正常，尝试将其BCCH频点对应的载波闭掉依然没有得到改善，怀疑是第

6、一小区天馈线出现故障，派单通知基站技术人员到现场处理发现第一小区天馈线头松了，拧紧后指标恢复正常，处理前后指标对比如下所示：,故障处理案例,总结：天馈线系统故障、BCCH载波隐性故障、基站所连接的辅助设备故障导致话务下降。,2、上行干扰类1）D2涡水存在严重的上行干扰，通过RIR测量分析，发现该小区几乎全频段均受到干扰，RIR测量图如下：,故障处理案例,经了解该小区带有一个直放站（连南涡水老福坪远端G），尝试将该直放站远程关闭后干扰消失，因此确认为该直放站出现故障引起，通知厂家到现场检查，经直放站技术人员重新调整直放站相关参数后干扰消失，处理前后指标对比如下：,故障处理案例,2）I1龙泉花园(

7、1800)2存在着3级上行干扰，通过RIR测量分析发现频点617&627&630都存在着不同程度的上行干扰，如下图：,故障处理案例,将频点更改为544&552&580后，上行干扰基本消失，处理前后指标对比如下：,故障处理案例,3）E1华冠1小区存在较严重的上行干扰，尝试逐个关闭该小区附近所有直放站，但上行干扰现象仍然没有得到改善，通过RIR测量分析得知几乎全频段均受到不同程度的干扰，其中E-GSM频段上行干扰最严重，RIR测量图如下：,故障处理案例,同时导致出现较多的掉话数、内切数、语音质量较低的情况，话务统计如下：,故障处理案例,对基站设备、直放站进行排查均没有发现问题所在，于是到现场进行扫

8、频，后发现干扰源来自于附近的联通基站，干扰885-895MHz频段导致出现上行4、5级干扰，895-915频段导致出现上行2、3级干扰，现场拍摄的干扰源图片如下（图中所示天线的可能性最大）：,联系联通公司技术人员协商处理后，上行干扰消失。,故障处理案例,4）D2九寨沟1小区有严重的上行四、五级干扰，用RLCRP实时打印干扰均集中在RXOTRX-60-2载波上，将该载波对应的频点更换为其它频点干扰仍然集中在该载波上，由此确认RXOTRX-60-2(ID：A533124229)存在隐性故障，导致出现严重的上行干扰，通知基站技术人员更换该载波（ID：TP10029088)后上行干扰消失，更换前后两天

9、晚忙时统计对比如下表所示：,直放站故障、频点干扰、载波隐性故障、外部干扰导致出现上行干扰现象。,故障处理案例,3、掉话、语音接通率低类1）B2佛岗13小区存在着上行弱信号掉话情况，通过MOTS定位发现掉话主要集中在RXOTRX-89-2和RXOTRX-89-3载波上，同时通过MRR观察存在上行弱信号的情况，如下图所示：闭载波前MRR：,故障处理案例,闭掉该两载波后，上行弱信号得到改善，如下图：,故障处理案例,可以看出闭掉该两载波后，上行信号有明显改善，处理前后指标对比如下：,故障处理案例,2）C2英华3 有用户反映不能正常上GPRS业务，观察小区指标发现信道完好率经常性在99%左右，掉话也比较

10、多，通过统计发现该小区传输链路有较多的帧重传数，如下表：,故障处理案例,经传输室将RBLT-19更换为RBLT-44后，指标恢复正常，处理前后晚忙时指标对比如下：,故障处理案例,3）G1龙塘1从29日凌晨开始出现话音接通率、指配成功率和切换成功率都较低，掉话次数较多等异常情况，经检查发现扩展架的两个载波都有TX 1B21的告警信息，将扩机架的载波闭掉后，指标恢复正常。同时，派单通知基站技术人员到现场处理后指标恢复正常，处理前后指标如下：,故障处理案例,总结：载波隐性故障、载波显性故障、传输链路引起的掉话、接通率低现象。,4、切换成功率低类1）D1称架温泉2在DT测试时发现在没有信号阻挡的情况下

11、信号电平起伏比较大，差值达到10个db。对该小区进行CTR分析发现占用到RXOTRX-3-3（ID:CB42136279）载波时下行信号很弱而上行正常，如下图所示：,故障处理案例,从而判断是该载波存在隐性故障，经更换后指标明显好转，更改前后两天同时段统计对比如下：,故障处理案例,2）D2连山供电局2 在11月5日突然出现话音接通率、指配成功率和切换成功率都较低的现象，经检查该小区的传输RBLT-105有较大误码，如下所示：,故障处理案例,通知基站技术人员到场处理（拧紧接线及更换2M头）后恢复正常，处理前后指标对比如下：,总结：载波隐性故障、传输链路引起切换成功率低等问题。,故障处理案例,基站软

12、件故障1）H2保安栋头1、2小区出现没有话务的情况，忙时申请次数为0，尝试将TG重LOAD后指标恢复正常，确认是软件掉死导致，处理前后指标对比如下：,故障处理案例,2）D1岭背2小区出现GPRS流量为0的现象，用户反映上不了GPRS。经检查硬件以及参数均没有发现异常，怀疑是PDCH信道掉死，用户所占用的信道无法正常释放引起，将该小区TG重LOAD后指标恢复正常，处理前后指标对比如下：,故障处理案例,3）C2空子3在6月4日突然出现较多的异常SDCCH申请次数，导致出现严重的SDCCH拥塞，通过电子地图查证该小区并不是位于位置区边界处，因此怀疑是信令信道掉死导致，重新配置SDCCH信道后指标恢复

13、正常，处理前后指标对比如下：,故障处理案例,4）E1泰基3在13号早上突然出现有较多异常的接入申请数，同时接入成功率也极低，尝试将该小区TG重LOAD后指标恢复正常，处理前后指标对比如下：,总结：软件掉死导致信道无法正常释放而引起指标异常，TG重LOAD后指标恢复正常。,故障处理案例,直放站故障1）5月14日20:30在清新41小区覆盖的区域附近有用户投诉出现打电话困难的现象，对在现场处理故障的直放站维护人员的手机号码进行MTR跟踪分析发现，MS占用到邻近的小区QG1QXJ1、QG1BAP3、QG1YGJ3时均出现较严重的上行质差，同时引起较多的质差紧急切换，但用RLCRP实时观察并不存在上行

14、干扰的现象，MTR分析如下图所示：,故障处理案例,经了解，该区域内有一宽带直放站，可以同时放大附近几个小区的信号，很有可能是直放站硬件出现故障引起；经直放站维护人员配合，将直放站关闭再进行MTR跟踪发现，通话时无质差现象发生，因此确定出现投诉原因是由该直放站引起，处理后通话质量较好，如下图所示：,故障处理案例,处理前后指标对比如下：,故障处理案例,2）连南大龙1存在上行弱信号掉话较多、信令接通率较低的情况，经了解该小区带有小龙林场光纤直放站，经MRR测量分析发现存在上下行不平衡的现象，上下行不平衡相差达到24db，初步判断为该直放站出现故障导致，如下图：信号强度：上下行不平衡,故障处理案例,同

15、时对该小区进行CTR分析，发现TA为2025范围内存在上行弱信号，同时上行质差较大，如下图：,故障处理案例,TA:2025为直放站覆盖范围,故障处理案例,经厂家处理后信号已恢复正常，MRR测量图如下：,故障处理案例,处理前后相关指标如下：(取晚忙时19点与20点数据),故障处理案例,3）D1江英3在2号左右开始出现话音接通率和指配成功率都较低、掉话数较多等异常情况。通过MRR测量发现，其上行信号较为正常，但是下行信号很弱，基本上集中在-110dBm左右。如下所示：,故障处理案例,通过对基站相关硬件进行定位检查均没有发现异常，经了解该基站带有延伸系统，初步判断为延伸系统出现故障导致。通知延伸系统

16、厂家到现场检查，发现延伸系统部分馈线已烧坏，同时合路器有故障。经更换新的馈线和合路器后，下行信号恢复正常，MRR信号强度图如下所示：,故障处理案例,处理后指标也恢复正常，如下所示：,故障处理案例,4）D1杜步中队2 有用户反映打电话断断续续，定MTR分析发现当TA达到16时（为直放站覆盖区域），上下行信号强度相差约30db，由此怀疑是直放站故障，派单通知直放站厂家处理后指标回复正常，具体如下：MTR:,故障处理案例,处理前后几天指标对比如下所示：,故障处理案例,5）B1鸡坑、牛皮塘基站受到较为严重的上行干扰，结合RIR分析发现全频段均受到干扰，初步怀疑可能是直放站或者外部干扰导致，经监控室配合

17、逐个关闭附近直放站进行观察，后来发现关闭京广铁路旧横石隧道近端VIPG直放站时上行干扰消失，确认为该直放站引起，派单通知厂家处理后指标恢复正常，处理前后数据对比如下所示：,故障处理案例,总结：直放站故障引起上下行不平衡，上、下行弱信号、上行干扰、通话质量较差等问题。,故障处理案例,频率干扰1）移动大楼二楼有用户反映在角落边通话不清楚，经常有杂音现象。通过对其手机号码进行MTR跟踪发现占用到的小区是QE2JJG1，同时存在上行质差，信号也相对偏弱，如下图所示：,故障处理案例,经调整QE2QY13 的功率43调为45，QE2JJG1的功率43调为41，让其尽量不占用到QE2JJG1小区（该小区由于

18、主要覆盖交警大队，经常会受到外部干扰器的影响）。经调整后再定MTR分析并通话感知话音质量，MTR测量图如下：,经调整后没有出现通话不清楚、经常有杂音等现象。,故障处理案例,2）界牌2 有上行干扰，同时内切较多，语音质量较差，经检查发现频点84与邻市三水大塘长岗的主频84同频，更换BCCH频点84为10后以上各项指标都有明显的提高，更换前后几天早忙时统计对比如下：,总结：频率干扰导致语音质量变差等异常情况。,故障处理案例,数据定义错误1）清新4（1800）基站刚开通时，对其进行数据检查时发现在BSC定义的CGI与在MSC定义的CGI不一致，这将会导致用户无法打电话而导致投诉等现象，错误数据定义如

19、下：BSC定义：,MSC定义：,故障处理案例,更正如下：,2）G1清新山塘1 有定义 EDGE 数据，即开启了EDGE功能，但由于该小区没有 STRU载波，导致该小区没有EDGE流量，估计是应急时临时拆走STRU 载波，具体如下所示：,故障处理案例,故障处理案例,经派单处理前后指标恢复正常，处理前后指标对比如下：,总结：关键数据定义错误，导致业务异常。,故障处理案例,参数调整1）C1大站3 在晚忙时存在SDCCH掉话较高，把ACCMIN=102调整为98，减少弱信号接入，调整后指标有比较明显提高，调整前后指标对比如下：,故障处理案例,2）G1长冲水库1出现信令接通率低的现象，经检查发现CHGR

20、=1的BCCD为YES，由于CHGR=1定义的频点为E-GSM频点，这样会导致部分不支持E-GSM频点的手机无法正常接入，导致信令接通率低。经修改BCCD=NO后信令接通率恢复正常，调整前后指标对比如下：,故障处理案例,TRA故障处理1、TRA故障定位方法主要思路：A、利用TRA隐性故障的特征（由于TRA引起的掉话能统计到掉话数但统计不到掉话原因）分析BSC掉话数统计与掉话原因数统计，找出差别大的局；B、对不明原因掉话比例大的BSC进行测试，结合话务情况初步定位问题所在（全速板还是 半速板）；C、通过定义合理的TRA占用时长告警门限，发现问题板；D、通过闭相应板，观察相关指标，确定问题所在；2

21、、实际网络中QYEBSCB局的TRA故障2.1 QYEBSCB掉话原因分析 取QYEBSCB网元连续4天24小时的不明原因掉话统计，由于掉话COUNTER打了补丁，部分数据为负数，故将每个时段的掉话数+520为参考数据（如下类同），如下图：,故障处理案例,从上图可以看出，5月27、28日的不明掉话数比平时有明显的增多，且出现不明原因掉话的时段发生在话务较高的时段，为此，分析该局的话务变化情况。,故障处理案例,3.2 QYEBSCB话务变化分析,结合掉话变化图可以看出，随着话务量的上升，不明原因掉话的次数也相应地增多，而这正是TRAU存在故障的表现特征（随着话务量的上升，故障TRA板被占用的机率

22、变大，不明掉话原因增多）。所以，初步判断QYEBSCB的TRA板存在故障。,故障处理案例,3.3 TRA问题定位方法：检测TRA设备占用时长设置合理的告警门限，监测E2局TRA设备的占用时长情况，看是否有部分TRA设备存在占用时长过短的情况。根据以往的经验，占用时长过短的TRA设备极有可能存在故障。对于E2局TRA告警门限的设置，其告警定义门限为7秒，门限百分比为20%，都偏小，影响到告警触发的灵敏性。为了使问题更容易凸现，修改告警门限如下：TRAPOOL SUPSTATUS ACL ALARMLEV ALPERCEFR ON A3 15 35FR ON A3 15 35HR ON A3 15

23、 35当DEV的占用时长低于15秒时触发告警 修改后E2局出现了如下的告警：,故障处理案例,故障处理案例,打印设备与SNT的对应关系如下：,出告警的设备集中在RTTGS-25这块增强全速率SNT板上，因此初步怀疑这一SNT存在问题。,故障处理案例,3.4 对SNT RTTGS-25的检验为了验证该SNT是否与E2局不明原因掉话数有关，在29日上午9：00闭掉了这块SNT板，观察当天晚忙时的掉话情况与之闭掉之前对比如下：,从上图可以看出，在5月29日9：00开始将该块SNT板闭掉后，该日为六合彩日话务量比5月27、28日（非六合彩日）多约6000爱尔兰的情况下，不明原因掉话数也比5月27、28日

24、大大减少。,故障处理案例,总掉话次数：,从上图可以看出，在5月29日9：00开始将该块SNT板闭掉后，该日为六合彩日话务量比5月27、28日（非六合彩日）多约6000爱尔兰的情况下，B2局总掉话数也比5月27、28日大大减少。,故障处理案例,总结：从以上的数据可以看出，闭掉故障SNT后，E2局掉话情况得到了极大的改善：A、大量不明原因掉话被消除 B、总掉话次数变化较平稳 C、忙时掉话率有明显的提升，且变化平稳，不出现明显的波动,故障处理案例,RPP故障处理 如果RPP板存在隐性故障，将会严重地影响了小区的GPRS性能，从而也激发了部分用户投诉。针对D1局有用户反映无法正常进行GPRS业务的情况

25、进行了跟踪，通过小区与公共资源关系的分析，追踪各RPP板的分配情况，并揭发了GPRS方面所潜在问题。GPRS投诉主要集中在D1局，从问题小区上来看，GPRS功能正常开启，均能正常占用PDCH信道，但话务统计分析这些小区均没有下行流量。开始怀疑是GPRS上行TBF吊死导致问题小区无数据流量，对于这类TBF吊死问题最直接的解决方法就是对GPRS功能的重启，对GPRS功能重启后，GPRS恢复正常并且话务统计也有相应的流量。但问题并没有彻底解决，同一网元的不同小区也陆续出现了相同状况。因此问题的真正原因不是由于TBF吊死所导致，公共资源RPP板存在问题可能性很大，虽然对问题小区进行GPRS功能的重启能

26、解决问题，但其实不然，对GPRS功能的重启只能治标不能治本，要彻底解决问题，必须从问题的根源出发，查出存在故障的RP板，将其更换。通过实时统计，将整个网元没有流量的小区全部找出，并查询该部分小区所对应的RP设备，统计情况如下：,故障处理案例,故障处理案例,从上表可以看到，分配到RP39、40的这两块板的所有小区几乎没有GPRS流量，而其PDCH占用率都很高，证明分配到这两个RP的小区没有正常地获得PCU资源的服务，另外从小区GPRS资源分配情况来看，PSET的分配很不规则：,故障处理案例,从上图可以看到，QD1JDZ3小区占用RP40的RP板，根据爱立信GPRS信道分配原则，当存在一个载波上有

27、连续的空闲信道时，其PDCH时隙（TN）分配顺序是：6-5-7-4-3-2-1-0。而该小区PSET上PDCH时隙分配没有按GPRS信道分配原则进行分配，其中EDGE载波空闲信道充足，只分配了一条EPDCH信道，并且有三个TN为5的时隙分别来自三个不同载波上。我们将这两块凝似有隐性故障的RP在2月28日、3月1日的11点至12点进行人工闭塞，闭塞后统计结果如下：,RP闭塞前,RP闭塞后,故障处理案例,将RP39、40的两块RP板闭塞后，GPRS流量比较原来数据增加了50000KB以上，无论是EDGE、GPRS的下行吞吐量也有明显的提升，PDCH分配成功率大大提高，PCU上下行掉帧数均明显减少，

28、因此，确定问题与RP39、40这两块RP板相关。但经过对有问题的RP的位置对调问题仍然存在，排除了RP板的硬件问题，由此也可以看出，问题可能是出现在RPP板的槽位上或者数据方面。最终经过交换室的协助，对RP39、40这两块的数据重新定义后，恢复了正常。总结：由于RP数据定义错误，导致严重影响数据业务性能。,经验总结,本次交流的故障处理案例涉及到了核心网部分与无线部分，核心网部分简单介绍了TRA、RPP故障处理的方法及步骤；无线部分介绍了各类异常的指标以及引起的原因，并结合各种网优工具简单介绍了相应的处理方法。对于无线部分而言，由于无线环境的复杂性，处理定位网络故障没有任何一成不变的计算公式可套、固定的处理方法可言，但有一个大概的总体思路，因此要求我们必须具备：1、熟悉无线环境；2、熟悉基站各部分工作原理；3、话务统计指标的分析能力以及问题的定位能力；4、熟悉各网络参数的作用及影响；5、网优经验。基站设备的不断运行工作，不可避免出现硬件的老化、故障；无线环境的不断变化，不可避免出现干扰等问题，因此处理网络问题是一项永恒的课题。故此，我们要做到及时发现、及时处理网络问题，保障基站设备运行性能处于良好状态，最大限度减少由于网络问题而引起的用户投诉，改善网络服务质量。,