网络优化专题四隐性故障处理.doc

网络优化专题四隐性故障处理2008.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鹿泉南高基D上下行电平差34五、总结36一、概述基站存在隐形故障，会造成掉话，通话质量差，呼叫困难等种种网络问题，引起用户投诉。减少存在隐形故障的基站是提高网络质量的基础。为此，优化期间，我们通过对CTRX统计，话务统计和用户投诉分析，通过及时上站核查，共解决了68个基站的隐形故障，大大提高了通话质量，改善了用户感知度。问题基站的工作异常，会带来指标下降和用户感受差，并且会反映在日常的话务统计，CTRX统计，路测和用户投诉中。我们针对这些方面可以对基站是否正常工作做出初步的判断，具体如下：1 通过CTRX统计发现载频上下行电平和上下行质量异常；2 小区突发高掉话；3 小区TCH分配失败率较高；4 小区切换统计中电平质量切换比例过高；5 邻小区向该小区切换失败次数较多；6 路测中占用TCH电平衰减快，下行质量差或者频繁的切换；7 用户投诉所反映的问题。二、查站流程2.1通过话务统计或CTRX统计发现可能存在隐形故障的基站。对于基带跳频的小区，如果观察到整个小区质量差，需要关跳频功控观察才能定位（TRX与CU一一对应）。如果是载频有问题，能定位到具体载频或与之相关的硬件。如果是频率干扰导致质量差，则能定位到哪个频点受干扰。对于综合跳频的小区，一般只用于定位隐性硬件问题。对每个TRX采样点数越多越准确，对于采样点少的TRX，多个小时累加再平均。经验值:平均质量大于2.5，硬件问题可能性较大。质量在1到2.5之间，干扰可能性较大。上下行电平差在15db内属正常，太大了一般存在连线等硬件问题。最好一个小区多个TRX进行比较。郊区质量一般应在1以下，城区质量在1.5以下属正常。建议:每次扩容载频或更换载频合路器后建议对此小区的CTRX统计进行跟踪。2.2查站基本流程 一、基站外部环境检查：包括基站经纬度，基站周围地理环境（周围是否存在电厂或微波等容易造成电磁干扰的建筑），天线挂高，天线方向是否正确，天线方向上是否被遮挡（如被楼群包围,被广告牌阻挡等）。如有路测设备，最好围绕基站进行拨打测试，观察每个小区的电平，质量及切换情况，通过测试可及时发现是否有明显的天线接反，发射功率不足，或严重上下行干扰与载频故障问题。二、机房内部环境检查：包括机房温度检查，察看机房内空调是否正常；机房湿度检查，是否有漏水或进水现象；机房用电检查，是否正常接电池，是否正常接地等。三、基站设备检查：检查模块所插糟位是否与数据配置一致，各模块温度，各模块状态指示灯是否正常，各模块之间连线是否正确，是否有接反接串的，连接头是否松动或断裂的，连线有没有断裂或打了死弯的，基站是否带有直放站设备，是什么类型直放站。如有频谱测试仪表（如TEK），测试各载频的发射与接收，检查是否有输出功率明显不足或上行接收问题，如果有外部干扰也能通过频谱测试发现。基站天馈线与天线检查 ：包括天馈线连接是否正确，接在合路器上的接头是否有松动，天馈线驻波比是否在正常范围（需中断小区业务测试）。尤其是现在许多基站配置很高，连接在设备的天馈线很多，特别需要细致耐心的检查。还要检查室外发射与接收天线的天线类型，天线倾角，天线是否有破损是否进水，如果是单极化天线要检查发射与接收天线方向是否一致。如因载频配置高而增加了天线，要检查新增天线是否与原天线方向一致。COBA或COSA软件或硬件故障：COBA与COSA出现软件或硬件故障的情况很少，只是在排除掉所有其他的问题后，才会考虑COBA或COSA软件或硬件故障问题，可以通过更换硬件，重新下载软件解决。三、问题基站的故障分类在通过以上方法发现的基站工作异常情况中，经过我们长期优化工作的总结，一般基站会存在以下几类情况：1. 硬件故障1） CU或者合路器的隐性故障；2） 硬件连接故障：接线连接松动；硬件连线与数据不符； 2基站工程参数和基站地理位置的经纬度与规划不符； 3天馈系统中天线接反； 4频点干扰；5异常小区的高掉话现象；6其他故障。以下是对这次专题中发现的问题基站处理的分类比例：四、网络隐性故障处理情况新入网BSC5存在较多的remote掉话问题描述：BSC:5割接入网后,该BSC Remote transcoder failure(远端解码掉话)掉话一直较高,晚忙时段基本在180次左右,并且这些掉话分布在不同的小区。问题分析：提取BSC5告警文件如下：提取分析其中7100相关的告警文件信息如下:时间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:197100H0028H0c1d10: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:16: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:107100H0028H0f1a10: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 transfailure 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日期时间remotetranscoderfailure掉话次数BSC52008-10-420129BSC52008-10-520146BSC52008-10-620185BSC52008-10-720178BSC52008-10-8200BSC52008-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后及时去激活。分析Error log文件（以BR60为例，参看BSCOML.pdf）Error ID:7100AP Connection Failure(68)Information(15个十六进制数）dddd:为十六进制数eeee:为十六进制数，前两位为PCMA ,后两位Time Slot numberffff: 为十进制数，前两位为BTSM,后两位BTSgggg: 为十六进制数正定综合楼sequence高掉话问题描述：正定综合楼1小区、2小区连续一周出现较高的sequence掉话，详细指标如下表如示：_DateCIsiteTCH_dropsSequenceerrorDistancelimitexceededHandoveraccessfailureRadiolinkfailure2008-8-411431正定综合楼24230012008-8-421431正定综合楼2625001问题分析：按照常规一般关闭上行不连续发射即：DTXUL=SHNFSHNH小区的掉话数应该明显下降，但是本小区没有明显的变化，仍然每个小时存在23个左右的sequence掉话。上基站检查硬件，更换了小区合路器及载波，更换后观察KPI发现小区掉话数仍然存在，且没有明显的变化。解决方案：检查正定综合楼附近的同频同BSIC复用距离，发现2小区的同频BSIC太近。修改2小区的BSIC由2-5调为2-6。优化后结果：_DateCIsiteTCH_dropsSequenCeerrorDistancelimitexceededHandoveraccessfailureRadioLinkfailure2008-8-611431正定综合楼100012008-8-621431正定综合楼10001修改2小区的BSIC后二个小区的sequence掉话都降为0，可见同频同BISC太近不但影响小区的切换成功率同时也会造成较高的sequence掉话。市区运管处sequence高掉话市区运管处（41441,61441)9月25日、26日连续两天两出现Sequenceerror高掉话,分别达到100次和60次。 SequenceError掉话属于无线射频掉话的一种，主要是由于BTS监测到第二层信令确认模式中有不规则的信息流控制功能（错误的消息队列）。此后BTS向BSC发送ERRIN（Error Indication），原因是Sequence Error（队列错误）。解决该问题一般情况下可将该小区的上行DTX关掉,或采取修改BSIC、BCCH办法解决。为此于9月26日将市区运管处（41441)小区BSIC由26修改为21，观察两日未出现Sequenceerror掉话,问题得到解决。处理前后小区指标对比如下：_DateCIname_hour话务量每线话务量掉话率Sequenceerror掉话次数2008-9-2541441市区运管处204.190.0912.94%1062008-9-2641441市区运管处203.480.0711.38%852008-9-2741441市区运管处203.120.060.00%02008-9-2841441市区运管处203.960.080.00%02008-9-2561441市区运管处204.890.138.83%602008-9-2661441市区运管处205.150.149.48%572008-9-2761441市区运管处205.160.140.32%02008-9-2861441市区运管处205.620.150.27%0行唐左市同不能正常主被叫但可以切入产生话务量问题描述：行唐左市同基站由阿尔卡基站替换为西门子基站后出现客户投诉，投诉内容是有信号不能打电话，现场测试占用本小区信号不能正常作主叫或被叫，但是可以通过在1小区或2小区起呼后切入3小区进行通话。观察KPI指标如下表如示：CI_hourTCHtrafficallTCH_Blocking_NUMTCH_AttemptTCH_Blocking_rate_HandoverTCHAssSuccTCHAssAttemptTCHAssSuccRate35068201.15057000问题分析：按照常规一般这种TCH没有分配尝试数的小区和CELL_BARR=TRUE或合路器故障有关。检查小区参数正常，更换小区合路器及载波后本小区没有明显的变化，仍然占用35068小区后不能正常起呼，小区仍然没有TCH分配尝试数。分析主叫第三层信令发现该小区channel request-immedidate assignment-CM service request后不能进行鉴权,然后就出现CM service reject-channel release;分析被叫第三层信令发现该小区也是不能进行鉴权后出现channel release。详细情况如下所示： 主叫手机 被叫手机解决方案：从上图可以看出无线部分的流程正常，无论主叫或被叫一旦到了开始进行鉴权的时候就会出现拒绝。由于鉴权是由MSC下发的，与MSC人员联系进行交换数据检查该小区定义数据，发现基站替换后遗漏了35068小区相关交换数据更新。优化后结果：CI_hourTCHtrafficallTCH_Blocking_NUMTCH_Blocking_rate_HandoverTCHAssSuccTCHAssAttemptTCHAssSuccRate35068202.90023423599.60%MSC更新了数据后小区KPI恢复正常。无极北合庄不能正常主被叫但可以切入产生话务量问题描述：无极北合庄900基站-3小区，现场拨打及锁频测试不能占用本小区信号。观察KPI指标如下表如示：CI_hourTCHtrafficallTCH_Blocking_NUMTCH_AttemptTCH_Blocking_rate_HandoverTCHAssSuccTCHAssAttemptTCHAssSuccRate38768200.080255000问题分析： 从KPI指标看TCH指配成功次数为0，TCH指配尝试次数位0，本小区没有呼出呼入，怀疑本小区有硬件故障或MSC数据定义错误。 解决方案：与MSC人员联系进行交换数据检查该小区定义数据无误，对该站现场检查并更换该站更换了合路器，RXAMCOG,TPU,DCPA,DCTPU等有故障硬件。优化后结果：CI_hourTCHtrafficallTCH_Blocking_NUMTCH_Blocking_rate_HandoverTCHAssSuccTCHAssAttemptTCHAssSuccRate38768202.3563.61%929398.92%更换该站更换了合路器，RXAMCOG,TPU,DCPA,DCTPU恢复正常。栾城赵卜口塔下大面积质差Logfiles Name：2环01.log问题描述：当车辆在南2环由西向东行驶时，测试手机在栾城赵卜口（CI=13628）的主覆盖区域内，电平较差导致通话严重质差。问题分析：主服务小区在空闲模式下电平信号平稳，起呼后电平急剧下降较频繁，导致通话质量恶劣，图中显示电平流向为锯齿状，判断为栾城赵卜口基站硬件故障。解决方案：更换栾城赵卜口基站的合路器及载频。优化后结果： 更换栾城赵卜口（CI=13628）的载频后，基站发射电平信号平稳，通话质量明显改善。供水总公司电平突然衰落Logfiles Name：0911-02.log问题描述：当车辆行驶至建设南大街和槐南路交界时，被叫手机占用供水总公司5（CI=55241）时，电平信号急剧下降并伴随信号断续现象，导致通话质量持续恶劣。问题分析：手机在空闲模式下电平信号平稳，起呼后占用供水总公司5（CI=55241）电平信号急剧下降并伴随信号断续现象，并且供水总公司5（CI=55241）扇区的原规划覆盖方位与实际路测范围不符，初步怀疑供水总公司5（CI=55241）基站连线问题或硬件故障。解决方案： 建议实地进站查看硬件连线或硬件故障。优化后结果： 实地进站后发现，供水总公司基站DSC1800的2、3小区，馈线连接有误造成鸳鸯线现象，调整2、3小区馈线连接后，复测该主覆盖路段，电平良好通话质量明显改善。 栾城大酒店质量差问题描述：通过CTRX发现栾城大酒店-2小区上下行电平正常，但TRX1上下行质量不好，怀疑有隐性故障。Cell NameCItrx下行平均电平上行平均电平下行与上行电平差值下行平均质量上行平均质量下行与上行质量差值栾城大酒店20288071.088186.144615.05640.2029820.288493-0.0855119栾城大酒店20288181.126496.669115.54282.14553.17828-1.03278栾城大酒店20288275.516285.613410.09721.247251.100480.146767栾城大酒店20288077.290895.025317.73440.09514560.778391-0.683245栾城大酒店20288181.952497.722815.77032.174253.78852-1.61427栾城大酒店20288280.632591.492510.861.390261.64705-0.256789栾城大酒店20288071.074685.179814.10520.2508960.311968-0.0610726栾城大酒店20288178.648294.196215.5481.818872.47436-0.655485栾城大酒店20288275.975387.034611.05921.481791.047910.433875问题分析：用TEMS拨测发现测试手机不能占用900基站2小区起呼。上站检查，发现900基站2、3小区CU1跳线交叉接反。解决方案：调整900基站2、3小区跳线连接。优化后结果：现场处理后，小区指标恢复正常，如下所示：CIcellname_Date_hourTCH_trafficTCH_Assign_Fail_NumTCH_Assign_Fail_rate20288栾城大酒店2008-10-10203.87176.32%20288栾城大酒店2008-10-11203.944215.79%20288栾城大酒店2008-10-12203.5219792%20288栾城大酒店2008-10-13206.6430.94%同时CTRX统计指标也有较大幅度提高，如下所示：Cell NameCItrx下行平均电平上行平均电平下行与上行电平差值下行平均质量上行平均质量下行与上行质量差值栾城大酒店20288067.953584.625616.67210.3111850.1979680.113218栾城大酒店202881-74.813-85.66910.8561.050360.9711760.079186栾城大酒店20288274.519286.029511.51031.285230.9070130.378219调整后用TEMS测试也恢复正常，如下图所示：藁城市政府D电平突然衰落测试文件：藁城02.log问题描述： 1、当测试车辆行驶至藁城市政府附近时，主叫手机在Idle模式下占用藁城市政府D（CI=18922）小区的BCCH=691的频点，此时电平为-64dbm。 2、主叫手机占用藁城市政府D（CI=18922）小区开始起呼，TCH分配完成后主叫手机被分配到的该小区的TCH=710频点的TS=5，此后电平急剧衰落到-95dbm且持续约5秒左右，直到主叫切换进藁城市政府（CI=18928）小区。 3、被叫手机占用藁城市政府（CI=18928）通话时，测量到邻区内藁城市政府D（CI=18922）BCCH=691的电平为-69dbm，强于主服小区电平且满足切换门限条件时发起一次切换。 4、切换完成后被叫手机切换进藁城市政府D（CI=18922）小区的TCH=710的频点的TS=7，此时电平急剧衰落到-96dbm且持续约5秒左右，直到被叫再次切进藁城市政府（CI=18928）小区。CTRX分析：CellBSCIDbtsmbtsnLACCItrx下行平均电平上行平均电平下行与上行电平差值下行采样点总数上行采样点总数藁城市政府D1115831889189220-65.95 -90.04 24.10 1194312194藁城市政府D1115831889189221-85.53 -88.51 2.98 27983025藁城市政府D1115831889189220-72.23 -96.08 23.85 91089249藁城市政府D1115831889189221-95.26 -98.95 3.70 14901620藁城市政府D2115841889289220-71.10 -96.68 25.59 1513215393藁城市政府D2115841889289221-89.22 -96.58 7.36 47005128藁城市政府D2115841889289220-69.65 -96.16 26.51 1611016253藁城市政府D2115841889289221-89.12 -96.50 7.39 26722889藁城市政府D3115851889389220-68.14 -93.85 25.71 85598709藁城市政府D3115851889389221-80.63 -96.24 15.61 46244780藁城市政府D3115851889389220-72.42 -98.05 25.63 65726662藁城市政府D3115851889389221-79.31 -95.12 15.81 34793636通过查看话统和CTRX发现藁城市政府D（CI=18922、18922、18922）三个小区的TRX都存在上行电平差，上下行电平相差25dBm左右且上、下行质量切换比例高的现象，我们怀疑藁城市政府D基站的载频或载频连线有问题。9月19日我们在基站周边DT测试中发现，藁城市政府D1800基站2、3扇区的实际覆盖方位与原规划中的方位不相符，覆盖情况如下图所示：1、藁城市政府D（CI=18922）第1扇区覆盖情况：2、 藁城市政府D（CI=28922）第2扇区覆盖情况：3、藁城市政府D（CI=38922）第3扇区覆盖情况： 从上图中可以看出藁城市政府D1800基站的2、3扇区的覆盖方位与原规划的覆盖方位不一致，第1扇区的覆盖方位与原规划的覆盖方位一致。调整方案：随即对该站各小区天馈系统进行检查，检查发现该站2、3小区天线交叉接反，立即对基站天馈系统进行了整改。优化结果：藁城市政府D处理后，随即对该站进行了DT测试，测试结果表明整改后的藁城市政府D 1800基站各扇区覆盖方位与原规划中的覆盖方位一致，整改后各扇区覆盖方位如下图所示：1、藁城市政府D（CI=18922）第1扇区覆盖情况：2、藁城市政府D（CI=28922）第2扇区覆盖情况：3、藁城市政府D（CI=38922）第3扇区覆盖情况：白佛客运站D反向覆盖9月18日我们在基站周边DT测试中发现，白佛客运站D1800基站1、2扇区的实际覆盖方位与原规划中的方位不相符，覆盖情况如下图所示：1、白佛客运站D（CI=41291）第1扇区覆盖情况：3、 白佛客运站D（CI=51291）第2扇区覆盖情况： 从上图中可以看出白佛客运站D 1800基站的1、2扇区的覆盖方位与原规划的覆盖方位不一致。调整方案：随即对该站各小区天馈系统进行检查，检查发现该站1、2小区天线交叉接反，建议对基站天馈系统进行了整改。优化结果：白佛客运站D处理后，随即对该站进行了DT测试，测试结果表明整改后的白佛客运站D1800基站各扇区覆盖方位与原规划中的覆盖方位一致.整改后各扇区覆盖方位如下图所示：1、白佛客运站D（CI=41291）第1扇区覆盖情况：2、白佛客运站D（CI=51291）第2扇区覆盖情况：66296招待所反向覆盖9月22日我们在基站周边DT测试中检查，66296招待所900基站1、2、3扇区的实际覆盖方位与原规划中的方位不相符，覆盖情况如下图所示：66296招待所(CI=13308)第1扇区覆盖情况：2、66296招待所(CI=213308)第2扇区覆盖情况：3、66296招待所(CI=33308)第3扇区覆盖情况：从上图中可以看出66296招待所900基站的2、3扇区的覆盖方位与原规划的覆盖方位不一致。调整方案：随即对该站各小区天馈系统进行检查，检查发现该站2、3小区天线交叉接反，建议对基站天馈系统进行了整改。优化结果：66296招待所处理后，随即对该站进行了DT测试，测试结果表明整改后的66296招待所900基站各扇区覆盖方位与原规划中的覆盖方位一致，整改后各扇区覆盖方位如下图所示：1、66296招待所(CI=23308)第2扇区覆盖情况：2、66296招待所(CI=33308)第3扇区覆盖情况：正定吴家营D反向覆盖9月25日我们在基站周边DT测试中发现，正定吴家营D1800基站2、3扇区的实际覆盖方位与原规划中的方位不相符，覆盖情况如下图所示：1、正定吴家营D(CI=40711)第1扇区覆盖情况：2、 正定吴家营D(CI=50711)第2扇区覆盖情况：3、正定吴家营D(CI=60711)第3扇区覆盖情况：从上图中可以看出正定吴家营D 1800基站的2、3扇区的覆盖方位与原规划的覆盖方位不一致。调整方案：调整2小区机柜所有软跳连至3小区机柜；3小区机柜顶所有软跳连至2小区机柜；1小区机柜顶所有软跳不变.优化结果：正定吴家营D处理后，随即对该站进行了DT测试，测试结果表明整改后的正定吴家营D 1800基站2、3扇区覆盖方位与原规划中的覆盖方位一致，整改后各扇区覆盖方位如下图所示：1、正定吴家营D(CI=50711)第2扇区覆盖情况：2、正定吴家营D(CI=60711)第3扇区覆盖情况：南栗村上下行链路不平衡测试文件：南栗村调前.log问题描述：新站测试前通过CTRX发现南栗村（CI=50581）TRX02上下行质量正常，但上下行电平差值相差20个dB，怀疑有硬件故障。电平如下图所示：Cell NameLACCItrx下行平均电平上行平均电平下行与上行电平差值下行平均质量上行平均质量下行与上行质量差值南栗村12545505810-72.52 -88.35 15.84 0.17 0.11 0.06 南栗村12545505811-82.79 -90.18 7.39 0.16 0.02 0.13 南栗村12545505812-82.18 -88.88 6.70 0.38 0.06 0.33 南栗村12545605810-56.17 -78.90 22.73 0.07 0.07 0.00 南栗村12545505810-71.87 -89.56 17.69 0.27 0.14 0.13 南栗村12545505811-83.43 -91.37 7.94 0.40 0.09 0.31 南栗村12545505812-83.21 -89.59 6.38 0.90 0.09 0.80 南栗村12545605810-56.99 -80.97 23.98 0.10 0.15 -0.05 南栗村12545505810-78.69 -91.46 12.77 0.37 0.16 0.21 南栗村12545505811-82.93 -90.53 7.60 0.48 0.11 0.37 南栗村12545505812-81.97 -88.41 6.44 0.61 0.09 0.52 南栗村12545605810-57.32 -82.88 25.56 0.11 0.15 -0.03 问题分析： 测试发现主叫手机占用南栗村（CI=50581）时，电平较低，且该路段并非南栗村（CI=50581）第5小区的实际覆盖路段，初步判断该小区方位角错误或基站天馈线接反。如下图所示：解决方案：随即进站检查发现南栗村D1800的5、6小区天馈线接反，立即对该站天馈系统进行了整改。调整后结果：调整后查看CTRX，南栗村（CI=50581）各参数恢复正常。Cell NameLACCItrx下行平均电平上行平均电平下行与上行电平差值下行平均质量上行平均质量下行与上行质量差值南栗村12545505810-57.35 -80.40 23.05 0.04 0.00 0.03 南栗村12545505811-78.36 -82.53 4.17 0.24 0.22 0.02 南栗村12545505812-61.76 -73.08 11.31 0.00 1.38 -1.38 南栗村12545605810-75.78 -89.79 14.00 0.17 0.09 0.08 鹿泉方台村西(长安电信)D上下行电平差问题：通过CTRX、KPI发现鹿泉方台村西(长安电信)D1800-1小区TCH=687所在载频下行电平较差，下行质量不好，该小区TCH支配成功率低，怀疑有隐性故障。Cell NameCItrx下行平均电平上行平均电平下行与上行电平差值下行平均质量上行平均质量下行与上行质量差值鹿泉方台村西(长安电信)D403410-71.64-87.1715.520.400.070.32鹿泉方台村西(长安电信)D403411-74.77-85.5710.790.080.030.05鹿泉方台村西(长安电信)D403412-97.10-80.89-16.214.560.384.17鹿泉方台村西(长安电信)D403410-71.60-88.1716.560.200.050.15鹿泉方台村西(长安电信)D403411-76.13-86.4810.350.070.010.06鹿泉方台村西(长安电信)D403412-95.70-79.45-16.254.020.213.81鹿泉方台村西(长安电信)D403410-70.89-88.0817.190.430.270.16鹿泉方台村西(长安电信)D403411-77.64-88.7411.090.090.020.06鹿泉方台村西(长安电信)D403412-96.13-84.33-11.794.720.684.04CI_hourTCHtrafficallTCH_Blocking_NUMTCH_AttemptTCH_Blocking_rate_HandoverTCHAssSuccTCHAssAttemptTCHAssSuccRate40341203.760590014317482.18%40341204.440523010613876.81%40341203041109812081.67%问题分析： 测试发现手机占用鹿泉方台村西(长安电信)D（CI=40341）时，测试手机起呼后电平突降了30dBm，怀疑有硬件故障，如下图所示：解决方案：建议更换该小区合路器和第三块CU。 调整后结果：调整后查看CTRX，KPI，鹿泉方台村西(长安电信)D（CI=40341）各参数恢复正常。Cell NameLACCItrx下行平均电平上行平均电平下行与上行电平差值下行平均质量上行平均质量下行与上行质量差值鹿泉方台村西(长安电信)D1806403410-72.01-88.1016.090.470.190.27鹿泉方台村西(长安电信)D1806403411-75.48-85.8510.370.080.020.06鹿泉方台村西(长安电信)D1806403412-75.44-85.299.840.340.070.27CI_hourTCHtrafficallTCH_Blocking_NUMTCH_AttemptTCH_Blocking_rate_HandoverTCHAssSuccTCHAssAttemptTCHAssSuccRate40341203.410361012112299.18%鹿泉南高基D上下行电平差问题：通过CTRX、KPI发现鹿泉南高基D1800-1小区TCH=702所在载频上下行电平较差，上下行质量不好，该小区TCH支配成功率低，怀疑有隐性故障。Cell NameLACCItrx下行平均电平上行平均电平下行与上行电平差值下行平均质量上行平均质量下行与上行质量差值鹿泉南高基D1806444683-80.00-89.129.110.130.20-0.07鹿泉南高基D1806444680-75.09-89.6714.580.070.29-0.22鹿泉南高基D1806444681-80.67-90.389.700.100.090.01鹿泉南高基D1806444682-98.89-99.140.243.974.19-0.21鹿泉南高基D1806444683-77.70-86.829.120.120.110.01鹿泉南高基D1806444680-78.15-91.8913.730.090.14-0.05鹿泉南高基D1806444681-78.48-89.9511.470.090.090.00鹿泉南高基D1806444682-97.72-98.130.413.984.00-0.02CI_hourTCHtrafficallTCH_Blocking_NUMTCH_AttemptTCH_Blocking_rate_HandoverTCHAssSuccTCHAssAttemptTCHAssSuccRate44468205.470501016117393.06%44468204.080440013415387.58%问题分析： 测试发现手机占用鹿泉南高基D（CI=44468）时，测试手机切换此小区后电平突降了20dBm，话音质量恶化，怀疑有硬件故障，如下图所示：解决方案：建议更换该小区合路器和第三块CU。 调整后结果：调整后查看CTRX，KPI，鹿泉南高基D（CI=44468）各参数恢复正常。Cell NameLACCItrx下行平均电平上行平均电平下行与上行电平差值下行平均质量上行平均质量下行与上行质量差值鹿泉南高基D1806444683-80.07-88.138.060.260.0190.25鹿泉南高基D1806444680-71.57-88.6217.050.100.070.028鹿泉南高基D1806444681-77.96-88.8711.090.1070.050.05鹿泉南高基D1806444682-81.03-91.9710.930.480.390.09CI_hourTCHtrafficallTCH_Blocking_NUMTCH_AttemptTCH_Blocking_rate_HandoverTCHAssSuccTCHAssAttemptTCHAssSuccRate40341203.410361012112299.18%五、总结通过为期二个月的专项故障小区测试及故障排查，对网络存在的问题小区集中进行了优化处理。处理后对后续优化及指标提升奠定了一个良好的硬件基础，对于网络质量有着较强的积极作用。