《网络优化专题四 隐性故障处理》由会员分享，可在线阅读，更多相关《网络优化专题四 隐性故障处理（33页珍藏版）》请在金锄头文库上搜索。
1、网络优化专题四隐性故障处理2021.10.15诺西移动通信目 录一、概述3二、查站流程3三、问题基站的故障分类4四、网络隐性故障处理情况5新入网BSC5存在较多的remote掉话5正定综合楼sequence高掉话10市区运管处sequence高掉话11行唐左市同不能正常主被叫但可以切入产生话务量12无极北合庄不能正常主被叫但可以切入产生话务量13栾城赵卜口塔下大面积质差14供水总公司电平突然衰落15栾城大酒店质量差17藁城市政府D电平突然衰落18白佛客运站D反向覆盖2466296招待所反向覆盖26正定吴家营D反向覆盖28南栗村上下行链路不平衡31鹿泉方台村西(长安电信)D上下行电平差32鹿泉南
2、高基D上下行电平差34五、总结36一、概述基站存在隐形故障，会造成掉话，通话质量差，呼叫困难等种种网络问题，引起用户投诉。减少存在隐形故障的基站是提高网络质量的根底。为此，优化期间，我们通过对CTRX统计，话务统计和用户投诉分析，通过及时上站核查，共解决了68个基站的隐形故障，大大提高了通话质量，改善了用户感知度。问题基站的工作异常，会带来指标下降和用户感受差，并且会反映在日常的话务统计，CTRX统计，路测和用户投诉中。我们针对这些方面可以对基站是否正常工作做出初步的判断，具体如下：1 通过CTRX统计发现载频上下行电平和上下行质量异常；2 小区突发高掉话；3 小区TCH分配失败率较高；4 小
3、区切换统计中电平质量切换比例过高；5 邻小区向该小区切换失败次数较多；6 路测中占用TCH电平衰减快，下行质量差或者频繁的切换；7 用户投诉所反映的问题。二、查站流程2.1通过话务统计或CTRX统计发现可能存在隐形故障的基站。对于基带跳频的小区，如果观察到整个小区质量差，需要关跳频功控观察才能定位TRX与CU一一对应。如果是载频有问题，能定位到具体载频或与之相关的硬件。如果是频率干扰导致质量差，那么能定位到哪个频点受干扰。对于综合跳频的小区，一般只用于定位隐性硬件问题。对每个TRX采样点数越多越准确，对于采样点少的TRX，多个小时累加再平均。经验值:平均质量大于2.5，硬件问题可能性较大。质量
4、在1到2.5之间，干扰可能性较大。上下行电平差在15db内属正常，太大了一般存在连线等硬件问题。最好一个小区多个TRX进行比拟。郊区质量一般应在1以下，城区质量在1.5以下属正常。建议:每次扩容载频或更换载频合路器后建议对此小区的CTRX统计进行跟踪。2.2查站根本流程 一、基站外部环境检查：包括基站经纬度，基站周围地理环境周围是否存在电厂或微波等容易造成电磁干扰的建筑，天线挂高，天线方向是否正确，天线方向上是否被遮挡如被楼群包围,被广告牌阻挡等。如有路测设备，最好围绕基站进行拨打测试，观察每个小区的电平，质量及切换情况，通过测试可及时发现是否有明显的天线接反，发射功率缺乏，或严重上下行干扰与
5、载频故障问题。二、机房内部环境检查：包括机房温度检查，观察机房内空调是否正常；机房湿度检查，是否有漏水或进水现象；机房用电检查，是否正常接电池，是否正常接地等。三、基站设备检查：检查模块所插糟位是否与数据配置一致，各模块温度，各模块状态指示灯是否正常，各模块之间连线是否正确，是否有接反接串的，连接头是否松动或断裂的，连线有没有断裂或打了死弯的，基站是否带有直放站设备，是什么类型直放站。如有频谱测试仪表如TEK，测试各载频的发射与接收，检查是否有输出功率明显缺乏或上行接收问题，如果有外部干扰也能通过频谱测试发现。基站天馈线与天线检查 ：包括天馈线连接是否正确，接在合路器上的接头是否有松动，天馈线
6、驻波比是否在正常范围需中断小区业务测试。尤其是现在许多基站配置很高，连接在设备的天馈线很多，特别需要细致耐心的检查。还要检查室外发射与接收天线的天线类型，天线倾角，天线是否有破损是否进水，如果是单极化天线要检查发射与接收天线方向是否一致。如因载频配置高而增加了天线，要检查新增天线是否与原天线方向一致。COBA或COSA软件或硬件故障：COBA与COSA出现软件或硬件故障的情况很少，只是在排除掉所有其他的问题后，才会考虑COBA或COSA软件或硬件故障问题，可以通过更换硬件，重新下载软件解决。三、问题基站的故障分类在通过以上方法发现的基站工作异常情况中，经过我们长期优化工作的总结，一般基站会存在
7、以下几类情况：1. 硬件故障1） CU或者合路器的隐性故障；2） 硬件连接故障：接线连接松动；硬件连线与数据不符； 2基站工程参数和基站地理位置的经纬度与规划不符； 3天馈系统中天线接反； 4频点干扰；5异常小区的高掉话现象；6其他故障。以下是对这次专题中发现的问题基站处理的分类比例：四、网络隐性故障处理情况新入网BSC5存在较多的remote掉话问题描述：BSC:5割接入网后,该BSC Remote transcoder failure(远端解码掉话)掉话一直较高,晚忙时段根本在180次左右,并且这些掉话分布在不同的小区。问题分析：提取BSC5告警文件如下：提取分析其中7100相关的告警文件
8、信息如下:时间HddddHeeee告警代码信令失败原因，28：远端解码失败前两位为PCMA号 ,后两位为Time Slot number10:29:267100H0028H0f1b10:29:177100H0028H0c1a10:29:147100H0028H0c1b10:29:057100H0028H0c1b10:27:527100H0028H0c1b10:27:437100H0028H0c1b10:27:357100H0028H0c1c10:27:037100H0028H0c1c10:26:597100H0028H0c1c10:26:477100H0028H0c1d10:26:197100
9、H0028H0c1d10:26:067100H0028H0c1e10:26:067100H0028H0c1e10:25:087100H0028H0c1e10:25:017100H0028H0d1a10:24:547100H0028H0d1a10:24:517100H0028H0d1a10:24:457100H0028H0d1a10:24:237100H0028H0d1b10:24:157100H0028H0d1b10:24:067100H0028H0d1b10:22:507100H0028H0d1c10:22:507100H0028H0d1c10:22:217100H0028H0d1c10:1
10、6:297100H0028H0d1d10:16:287100H0028H0d1e10:16:267100H0028H0d1e10:16:207100H0028H0e1a10:16:057100H0028H0e1b10:15:177100H0028H0e1b10:14:457100H0028H0e1b10:14:417100H0028H0e1c10:14:137100H0028H0e1d10:14:077100H0028H0e1d10:13:577100H0028H0e1e10:13:337100H0028H0e1e10:13:257100H0028H0e1e10:12:107100H0028H
11、0f1a10:11:397100H0028H0f1a10:11:267100H0028H0f1a10:11:157100H0028H0f1a10:11:157100H0028H0f1a10:11:027100H0028H0f1b10:10:537100H0028H0f1c10:10:527100H0028H0f1c10:10:337100H0028H0f1d10:10:177100H0028H0f1d10:09:537100H0028H0f1e10:09:377100H0028H0f1e10:09:367100H0028H0f1e从上面的dddd列可以看出其原因主要是28-remote tra
12、nsfailure code。红色16进制数字是掉话发生的PCMA-SLOT，发生掉话的时隙主要是以下时隙：pcma12-slot26 27 28 29 30，pcma13-slot26 27 28 29 30，pcma14-slot26 27 28 29 30，pcma15-slot26 27 28 29 30,这些时隙对应硬件模块是BSC:5/TRAU:3/TRAC:2。解决方案：将这些时隙占用的模块切换到备份模块BSC:5/TRAU:3/ TRAC:5，建议对存在隐性故障的BSC:5/TRAU:3/TRAC:2进行全面检测或更换TRAC板。优化后效果：统计前后结果比照方下:BSCID日期
13、时间remotetranscoderfailure掉话次数BSC52021-10-420129BSC52021-10-520146BSC52021-10-620185BSC52021-10-720178BSC52021-10-8200BSC52021-10-9200由统计结果来看,掉话消除,问题得到解决。附提取告警及分析7100告警的方法：提取BSC告警的方法：在BSS Sum双击BSCBSCE Sum(图1)中点BSC点右键中选择Set(图2)Set Bsc BasicProcessingFailureEvent(图3)FERMAINT确定等待大约40分钟 BSCE Sum(图1)中点BSC点右键中选择action(图2)选择Seelogs.提取BSC的Logs提取这40分钟内的alarmlogs(图5)确定存在相关目录下然后通过ftp登陆此终端下载此告警文件将ProcessingFailureEvent恢复至原来值major。图片说明如下：图1图2图3图4图5注意：激活PROCESSING FAILURE EVENT 后信令负荷会很大，建议收集完ERRORLOG后及时去激活。分析Erro
