基站隐性故障处理

基站隐性故障排除TOC\o"1-5"\h\z\o"CurrentDocument"基站隐性故障处理的一般方法及案例分析 3\o"CurrentDocument"发现问题的方法 3基站故障的分类 3\o"CurrentDocument"基站隐性故障处理的一般方法 4看基站当前的状态及告警 4\o"CurrentDocument"检查基站传输的状态 12\o"CurrentDocument"检查基站的数据定义 17检查并分析孩人0人LOG 18\o"CurrentDocument"对基站进行检查 20\o"CurrentDocument"使用仪表设备对基站进行检测. 35关于时隙同步失败(TSSYNCFAULT)问题的分析 38\o"CurrentDocument"什么是TSSYNCFAULT告警。 38关于时隙环路测试失败(TSLOOPTESTFAIL)问题的分析 43\o"CurrentDocument"对时隙进行环路测试的目的。 44\o"CurrentDocument"时隙环路测试的工作原理。 44\o"CurrentDocument"对时隙进行环路测试的方法 44\o"CurrentDocument"对TS和TRA设备的检测 45关于单通问题的基站部分故障的查找与分析 46关于使用MODP对级连传输进行监控的原理与实现 46\o"CurrentDocument"为什么要使用MODP 46\o"CurrentDocument"什么是MODP 47\o"CurrentDocument"MODP的设置和使用方法 47效果验证 48\o"CurrentDocument"一点建议 501 基站隐性故障处理的一般方法及案例分析所谓基站的隐性故障是指那些没有明显的告警但对基站的性能有影响的故障，或者是那些反复出现后又往往能自行消失的告警。这些告警的存在将使得系统的性能指标受到影响。由于这些问题的隐蔽性，往往无法直接发现它们，因此我们需要借助其他方法才能发现这些潜在的故障。1.1发现问题的方法话务统计话务统计提供了各种指标去衡量系统服务的好坏。基站的很多故障都会反映到话务统计的某项指标上来。常用的指标有信道完好率，掉话，切换，无线接入性等。如果基站存在问题，则有可能影响到其中一项或者几项指标。因此如果这些指标的变化，特别是在没做任何参数修改的情况下发生了变化，我们应该考虑基站硬件的因素。路测路测能够最直接的反映系统真实运行情况和最终用户的感知。因此对路测文件的分析也往往能帮助我们发现问题。BSC中基站的历史告警记录有些告警产生了之后能够自行恢复，因此当打印网络中现存的故障的时候不一定能发现这些故障。但是它们往往会在BSC的历史告警记录中留下痕迹。通过分析这些记录，能够帮助发现一些基站潜在的问题。用户投诉用户的投诉可能会是由基站的硬件引起，如基站的发射功率不稳定导致用户手机信号不稳。对投诉信息加以提炼和分析，能帮助我们发现存在问题的区域。在下面的案例分析中我们可以看到这几种发现问题的方法的具体应用。

就基站的故障对系统指标的影响而言，我们可以将它们分为话务敏感型故障和非话务敏感型故障。象天馈线驻波比过高的告警，能够直接影响下行信号的输出强度，影响通话质量，属于话务敏感型故障。而象风扇告警这类故障，不会对话务产生直接的影响，属于非话务敏感型故障。但这类故障往往会间接的影响到系统的性能，更具隐蔽性，所以同样不能忽视它们。从基站对信号的处理流程来看，我们又可以将基站的故障分为两大类。一类是对基带信号处理时产生的告警。另一类是发生在射频信号处理时的故障。基站中处理基带信号的硬件有DXU和TRU中的部分功能模块，DXU中包括CF，TF，IS，CON，DP等功能模块。TRU中处理基带信号的功能模块是TRXC。基站中对射频信号的处理主要是由TRU，CDU和天馈线来完成的。TRU内部是由TX和RX两个功能模块来完成对基带信号的调制和解调功能的。RBS2000DTTI-mDXUTRX-X-0 I RBS2000DTTI-mDXUIts-ti TRXr_Ftk RX_|TS-(|/IIIpCDU1RX-X-1 I TOC\o"1-5"\h\zTS-7.* .IittxcIr^_fkx_|is-q|/IIII OH?IRX-X-l1 /TS-TiItrxc_Ftn_[rx_Itk-o #HU业aw分清楚告警的类型有助于我们分析问题，不至于产生方向性的错误。1.3基站隐性故障处理的一般方法当我们发现某个基站可能存在问题时，我们一般从以下几个方面着手来处理。常用的命令如下：RXTCP：MOTY二RXOTG,CELL=ZHEYMY2；从小区名找到相连的TG号。RXCDP：MO=RXOTG-69；检查TG下面的MO的配置情况。RXMSP：MO=RXOCF-69；检查MO的状态。关于MO状态的含义见下面详细说明。RXASP：MO=RXOTG-69；检查TG下面的MO是否有告警。RXMFP：MO=RXOTRX-69-0；检查有故障的MO的告警代码。再根据告警代码查找相应解释。RLCRP：CELL=ZHEYMY2；检查小区的资源使用情况。如是否有人占用小区，小区的时隙是否有BLOCKED的，小区是否存在上行干扰等。RLSLP：CELL=ZHEYMY2；检查小区信道使用的情况。通过以上命令，我们可以大致知道一个基站当前的工作状态。关于MO状态的详细说明。熟练掌握这些MO状态的含义对我们分析网络中存在的隐性问题很有帮助。因为很多基站问题并没有明确的告警指示，而是通过MO状态的变化反映出问题的存在的。RXMSP:MO=RXOTRX-3-4;RADIOX-CEIVERADMINISTRATIONMANAGEDOBJECTSTATUSGLOBLESTATE:从BSC的角度来看的MO的状态。GLOBLESTATE有以下几种状态：DEF：MO在BSC中被定义。COM：MO已经和BSC建立起通讯。PREOP:这是MO由COM到OPER的一个过渡状态。OPER：MO处于正常工作状态。NOOP：MO暂时处于非工作状态。FAIL：MO永久性地处于非工作状态。BLOCKSTATE:表明MO是由于何种原因处于BLOCK的状态的。BLOCKSTATE有以下几种状态：MBL:人工将MO闭掉的。BLO：MO自动被闭掉的。如MO产生错误，或者OMLLINK断了等等。BLA:由于需要对MO进行操作而进入BLOCK的状态。BLL：MO在下载软件时的状态。BLT：MO由于测试而进入的BLOCK状态。BLOCKREASON：通过代码解释BLOCK的原因。BLCBLALMOBiodcingReasonHexhdOneeds:FlexLit]lockeduueta:[001Ownsup,PerrranDntlyaooiRssetsndUClaad町-[002Ownsup,Tempor^nlyaoo;Resetandloadcheck00020004Ownsup,F^ultsuspected阿LoadCheck004□03Blockedf-oniTjaooEFFIh口□308mi1Rln^kfrif-nmnmrTestnrjnunrn?iEllmksdfromTGCnn?rIrrtemittprttestm?nConUcuraliononaDincmilBlockedfromDMInn4rIlirjqtircnfkindq：qniiohrnTRMrtomnlPlrnniNriTrn时gnnsir匚习rl□aaoC10JBlockedfromL\1To^ocManualdeblocking□100orTSC20JBlockedfromCF7020CLooptest□200LTFECOLocalmode(only012)0100FSLC2DJFailedlooptestQJOOFDLT1JOO削mfaultinTRA.2300Hullin3T5值得注意的是LMO代码，其含义是指从TRAFFIC的角度来看，MO已经不能承载话务了，虽然从O&M的角度来这个MO还是工作正常的。常见的问题有TSSYNCFAULT。这时候用RXMSP查看该时隙的状态即可看到为LMO2000oBTSSTATE：MO的状态。可分为四类：RES MO出于RESET状态STA MO出于STARTED状态DIS MO出于DISABLED的状态ENA MO处于ENABLED的状态在RBS2000系统中这四种状态对应于不同类别的MO其含义是不一样的。总结起来有如下规律：对于SOCF和TRXC：RESET意味着该MO在重新启动，其应用软件还在运行但功能受到了限制，没有告警监测，也无法和相应的AO保持联系，RSL(RadioSignalingLink)中断。MO的这种状态往往在硬件上代表着DXU或TRU发生了重启。STARTED则表明MO的应用软件在运行而且各种功能均已启动，OML和RSL能建立通讯。基站正常工作时CF和TRXC一定处于START的状态。对于AOTF，TX，RX和TS：RESET表明该AO重启，和其相应的SO的联系中断。DISABLED的状态表明该AO已和相应的SO取得联系，告警监测功能已激活，但还不能承载业务。例如TX处于DISABLED状态则表明该TRU的发射机处于关闭状态，在TRU的面板上可看到TXNOTENABLED的指示灯亮。ENABLED的状态表明该AO已和相应的SO取得联系，告警监测功能已激活，并且已经能够承载业务了。例如对TF而言，ENABLED状态则表明TF可以发布同步信息。基站正常工作时，TF，TX，RX和TS都应该处于ENABLED的状态。对于AOIS,CON：RESET表明该AO重启，和其相应的SO的联系中断。DISABLED表明AO处于可以处理业务，同时也可以对其进行配置的状态。ENABLED表明AO可以处理业务，但不能被配置。注意：基站正常工作时，通常是将IS和CON置于DISABLED状态。对于AODP：RESET表明该AO重启，和其相应的SO的联系中断。DISABLED表明AO对PCM进行监测的功能没有被激活。ENABLED表明AO对PCM进行监测的功能已被激活。案例分析：由载频引起的上行干扰。故障现象：用户投诉在ZHEWJA1小区所覆盖的区域内存在打电话困难的现象。故障分析：用RXCDP查看小区各MO配置正常。<RXCDP:MO=RXOTG-109;RADIOX-CEIVERADMINISTRATIONMANAGEDOBJECTCONFIGURATIONDATAMORESULTARFCNMISMATCHRXORX-109-0CONFIGHOPNONERXORX-109-1CONFIGHOPNONERXORX-109-2CONFIGHOPNONERXORX-109-3CONFIGHOPNONERXORX-109-4CONFIGHOPNONERXORX-109-5CONFIGHOPNONEMORESULTARFCNTXADTNBPCCHCOMBOFFSXRAICMRXOTS-109-0-5CONFIGHOPHOP12398TCH0NOONRXOTS-109-0-6CONFIGHOPHOP02395TCH0NOONRXOTS-109-0-7CONFIGHOPHOP22290TCH0NOONRXOTS-109-1-0CONFIGHOPHOP72423TCH0NOONRXOTS-109-1-1CONFIGHOPHOP62419TCH0NOONRXOTS-109-1-2CONFIGHOPHOP52415TCH0NOONRXOTS-109-1-3CONFIGHOPHOP42411TCH0NOONRXOTS-109-1-4CONFIGHOPHOP32407TCH0NOONRXOTS-109-1-5CONFIGHOPHOP12399TCH0NOONRXOTS-109-1-6CONFIGHOPHOP02396TCH0NOONRXOTS-109-1-7CONFIGHOPHOP22291TCH0NOONRXOTS-109-2-0CONFIGHOPHOP22405SDCCH80NOONRXOTS-109-2-1CONFIGHOPHOP72424TCH0NOONRXOTS-109-2-2CONFIGHOPHOP62420TCH0NOONRXOTS-109-2-3CONFIGHOPHOP52416TCH0NOONRXOTS-109-2-4CONFIGHOPHOP42412TCH0NOONRXOTS-109-2-5CONFIGHOPHOP32408TCH0NOONRXOTS-109-2-6CONFIGHOPHOP12400TCH0NOON

但用RLCRP查看发现ZHEWJA1小区上总有部分时隙受到干扰。<RLCRP:CELL=ZHEWJA1;CELLRESOURCESCELLBCCHCBCHSDCCHNOOFTCHZHEWJA11032 43-86CHGRBPCCHANNELCHRATESPVSTATEICMBANDCHBAND64K02425TCH-4742FR1,2IDLE1P900NONETCH-17729HR1IDLE1P900TCH-17728HR1IDLE1P9002424TCH-4741FR1,2IDLE1P900NONETCH-17727HR1IDLE1P900TCH-17726HR1IDLE1P9002423TCH-4740FR1,2IDLE4P900NONETCH-17725HR1IDLE4P900TCH-17724HR1IDLE4P9002422TCH-4739FR1,2IDLE1P900NONETCH-17723HR1IDLE1P900TCH-17722HR1IDLE1P9002396TCH-4717FR1,2IDLE4P900NONETCH-17679HR1IDLE4P900TCH-17678HR1IDLE4P9002399TCH-4720FR1,2IDLE4P900NONETCH-17685HR1IDLE4P900TCH-17684HR1IDLE4P9002400TCH-4721FR1,2IDLE1P900NONETCH-17687HR1IDLE1P900TCH-17686HR1IDLE1P9002406TCH-4723FR1,2BUSY1P900NONETCH-17691HR1LOCK1P900TCH-17690HR1LOCK1P9002407TCH-4724FR1,2IDLE4P900NONETCH-17693HR1IDLE4P900TCH-17692HR1IDLE4P9002408TCH-4725FR1,2IDLE1P900NONETCH-17695HR1IDLE1P900TCH-17694HR1IDLE1P900END不难发现，受干扰的时隙都集中对应为同一个TRX所控制的时隙。具体方法如下:RLCRP的打印列表中BPC为2423的时隙的ICM=4。

在RXCDP的打印列表中BPC为2423所对应的时隙为：RXOTS-109-1-0。用类似的方法将所有的受干扰的时隙找出来，可以发现它们都是TRX-109-1所控制的时隙。将跳频关掉，情况更明显。所有受干扰的时隙仍然都集中在TRU1上。<RLCRP:CELL=ZHEWJA1;CELLRESOURCESCELLBCCHCBCHSDCCHNOOFTCHZHEWJA11032 43-86CHGRBPCCHANNELCHRATESPVSTATEICMBANDCHBAND64K12770TCH-1452FR1,2IDLE4E900NONETCH-11673HR1IDLE4E900TCH-11672HR1IDLE4E9002773TCH-1453FR1,2IDLE5E900NONETCH-11675HR1IDLE5E900TCH-11674HR1IDLE5E9002776TCH-1479FR1,2IDLE4E900NONETCH-11679HR1IDLE4E900TCH-11678HR1IDLE4E9002774TCH-1478FR1,2IDLE4E900NONETCH-11677HR1IDLE4E900TCH-11676HR1IDLE4E9002779TCH-1480FR1,2IDLE4E900NONETCH-11681HR1IDLE4E900TCH-11680HR1IDLE4E9002780TCH-1481FR1,2IDLE4E900NONETCH-11683HR1IDLE3E900TCH-11682HR1IDLE4E9002782TCH-1482FR1,2IDLE4E900NONETCH-11685HR1IDLE3E900TCH-11684HR1IDLE4E9002783TCH-1483FR1,2IDLE4E900NONETCH-11687HR1IDLE4E900TCH-11686HR1IDLE4E900END

<RXCDP:MO=RXOTG-109;RADIOX-CEIVERADMINISTRATIONMANAGEDOBJECTCONFIGURATIONDATAMORESULTARFCNMISMATCHRXORX-109-0CONFIGHOPNONERXORX-109-1CONFIGHOPNONERXORX-109-2CONFIGHOPNONERXORX-109-3CONFIGHOPNONERXORX-109-4CONFIGHOPNONERXORX-109-5CONFIGHOPNONEMORESULTARFCNTXADTNBPCCHCOMBOFFSXRAICMRXOTS-109-0-0CONFIG1018472861TCH0NOONRXOTS-109-0-1CONFIG1018462860TCH0NOONRXOTS-109-0-2CONFIG1018452859TCH0NOONRXOTS-109-0-3CONFIG1018442858TCH0NOONRXOTS-109-0-4CONFIG1018432857TCH0NOONRXOTS-109-0-5CONFIG1018422856TCH0NOONRXOTS-109-0-6CONFIG1018412854TCH0NOONRXOTS-109-0-7CONFIG1018402853TCH0NOONRXOTS-109-1-0CONFIG1000572783TCH0NOONRXOTS-109-1-1CONFIG1000562782TCH0NOONRXOTS-109-1-2CONFIG1000552780TCH0NOONRXOTS-109-1-3CONFIG1000542779TCH0NOONRXOTS-109-1-4CONFIG1000532776TCH0NOONRXOTS-109-1-5CONFIG1000522774TCH0NOONRXOTS-109-1-6CONFIG1000512773TCH0NOONRXOTS-109-1-7CONFIG1000502770TCH0NOONEND该载频使用的是1000号频点，用FAS查看，其受干扰的情况和其它频点差不多。不应该单单这个频点产生这么高的上行干扰。但为了保险起见，还是通过FAS选择了一个更好的频点1021号频点。但发现该载频上的干扰仍然很强。

图三于是将该载频所对应的时隙全部闭掉。RXBLI：MO二RXOTS-109-1-0&&-7,FORCE;此时用RLCRP观察，发现干扰基本消失了。再将闭掉的时隙解闭，发现干扰又重新出现，而且都集中在该载频上。于是确认是由于载频内部电路发生故障而引起的上行干扰。如果用户的手机被分配使用该载频所对应的时隙则肯定会受到影响。1.3.2检查基站传输的状态传输作为基础性建设，对基站的正常工作起着重要的作用。很多问题看似离奇，其实就是由传输引起。因此我们对传输问题应该予以重视。用以下命令可以检查基站的传输是否工作正常。RXAPP：MO=RXOTG-69；打印TG使用的传输设备号。RADEP：DEV=RBLT-819；从传输设备号得到其所属的DIP号。DTSTP：DIP=RBLT25；打印DIP的工作状态。DTQUP：DIP=RBLT25；打印DIP的传输质量。关于此命令参数的解释如下:DTQUP:DIP=RBLT12;DIGITALPATHQUALITYINCOMINGANDOUTGOINGDIRECTIONDIPT1T2SLIPSLIP2UASUASRUAV1UASB1UAV2UASB2RBLT1231002690000 00SECTIONESVSESVDMVESVRSESVRDMVRSFVSFTI000026924SECTIONES2VSES2VDM2VES2VRSES2VRDM2VRSMI360000END各参数的含义：T1：传输性能劣化到不可接受的程度(Unacceptablelevel)的时间一直到目前为止的时间间隔。以分钟为单位。T2：传输性能发生劣化(Degradeperformancelevel)的时间一直到目前为止的时间间隔。以小时为单位。SLIP:在T1时间间隔内发生的滑码的个数。所谓滑码指的是在2M的PCM码流中任何一帧(256bits)出现丢失或重复，即产生一次滑码。SLIP2:在T2时间间隔内发生滑码的数目。UAS：在接收方向上，T1时间间隔内发生不可用秒的数目。所谓不可用秒是指在任何一秒的时间间隔内出现业务中断的问题，该秒即被记为不可用秒。UASR:在发送方向上，T1时间间隔内发生不可用秒的数目。UAV1：在收发两个方向上，T1时间间隔内发生不可用事件的数目。不可用事件包括几次或者连续的不可用的状态。UAV2：在收发两个方向上，T2时间间隔内发生不可用事件的数目。不可用事件包括几次或者连续的不可用的状态。UASB1：在收发两个方向上，T1时间间隔内发生不可用秒的数目。UASB2:在收发两个方向上，T2时间间隔内发生不可用秒的数目。ESV:在接收方向上，T1时间间隔内发生误码秒的数目。所谓误码秒指的是在一秒中内发生了任何一件下列事情：至少一帧出现误码，帧失步，LOS，SLIP，AIS，收到远端传过来的A_BIT为1。ESVR:在发射方向上，T1时间间隔内发生误码秒的数目。ES2V:在接收方向上，T2时间间隔内发生误码秒的数目。ES2VR：在发射方向上，T2时间间隔内发生误码秒的数目。SESV:在接收方向上，T1时间间隔内发生严重误码秒的数目。所谓严重误码指的是在一秒内发生了至少一次下面的事件：至少N4帧出现误码，帧失步，LOS，SLIP，AIS，收到远端传过来的A_BIT为1。N4缺省值为28。SESVR:在发射方向上，T1时间间隔内发生严重误码秒的数目。SES2V:在接收方向上，T2时间间隔内发生严重误码秒的数目。SES2VR:在发射方向上，T2时间间隔内发生严重误码秒的数目。DMV：在接收方向上，T1时间间隔内发生性能下降分钟(Degradedminutes)的数目。所谓性能下降分钟指的是在一分钟内至少发生了下面一件事：丢失了二个帧同步字。DMVR:在发射方向上，T1时间间隔内发生性能下降分钟(Degradedminutes)的数目。DM2V:在接收方向上，T2时间间隔内发生性能下降分钟(Degradedminutes)的数目。DM2VR:在发射方向上，T2时间间隔内发生性能下降分钟(Degradedminutes)的数目。SFV:在SFTI时间段内积累的滑帧的数目。所谓滑帧指的是帧同步的丢失。SFTI：定义监测滑帧的时间间隔，一般设为24小时。SMI：在T2的时间段内怀疑有问题的T1的时间段的数目。需注意的一点是用DTQUP命令来监测传输质量的传输段的有效范围是从BSC到传输网这一段传输，从传输网的另一侧到基站或基站之间的级连传输则无法被监测。为了能使这一段传输质量也可以被检测到，需要引入MODIP的概念，这在后面的专题“关于使用MODP对级连传输进行监控的原理与实现”有详细描述。总之，传输质量的好坏能直接影响基站的同步性能，Abis接口上的信令和数据。对网络的稳定，通话质量以及掉话等都会产生重要影响。案例分析：由传输质量差引起来的通话过程中出现单通现象故障现象：10月20日在君悦来站A小区覆盖的范围内几乎同一时刻有三个通话发生单通的现象，最后都引起掉话。但单通时通话的具体方向又各有不同。有些为上行方向出现问题，有些为下行方向出现问题。故障分析：用DTQUP命令读取传输质量的监测数据。发现传输存在滑码和误码。DTQUP:DIP=RBLT11;DIGITALPATHQUALITYINCOMINGANDOUTGOINGDIRECTIONDIPT1T2SLIPSLIP2UASUASRUAV1UASB1UAV2UASB2RBLT1191601200 0 0 1 37SECTIONESVSESVDMVESVRSESVRDMVRSFVSFTI

SECTIONES2VSES2VDM2VES2VRSES2VRDM2VRSMI65101057000012 24END12 24再读取DXU和TRU的LOG文件，发现在产生单通现象时有传输出现问题的记录。并且LAPD信令链路出现中断。[03-10-2014:57:05.902]RTS_TFrts_tf_ctrl.c:3532TRACEH:PCM_UPDATE_RPTarived,110022[03-10-2014:57:08.972]P_LAPD_OMLlapd_common.c:1771TRACEH:LAPDprotocolerror:12[03-10-2014:57:09.940]P_LAPD_OMLlapd_common.c:1771TRACEH:LAPDprotocolerror:1[03-10-2014:57:09.940]PLS_SWITCHscan.c:1343TRACEH:SUSCANreceivedreleaseonlinkCF[03-10-2014:57:18.968]PLS_SWITCHscan.c:1291TRACEH:SUSCANreceivedestablishonlinkCFicp=40ts=10br=5[03-10-2014:57:19.382]RTS_TFrts_tf_ctrl.c:3532TRACEH:PCM_UPDATE_RPTarived,010000其中PCM_UPDATE_RPTarived,110022这一项每一位的含义如下：Bit1:PCMAerror(0=noerror,1=error)Bit2:PCMAavailable(0=notavailable,1=available)Bit3:PCMBerror(0=noerror,1=error)Bit4:PCMBavailable(0=notavailable,1=available)Bit5:PCMsynchronisationsource1(0=PCM_A,1=PCM_B,2=optionaloscillator)Bit6:PCMsynchronisationsource2(0=PCM_A,1=PCM_B,2=optionaloscillator)receivedreleaseonlinkCF则表明LAPD信令中断了，需重新建立。故障处理：更换该站的传输后，在该站覆盖的区域内进行拨打测试显示通话质量很好。1.3.3检查基站的数据定义在BSC上对基站的数据定义错误也会造成各种各样的问题，这就需要我们对每个参数的作用及应用范围有清楚的了解。常用的检查基站数据的命令如下：RXMOP：MO=RXOTG-69；检查MO的定义数据。MOW为TG，CF，TRX，TX，RX等。RLDEP：CELL=ZHBJYL2；检查小区的定义。如CGI，BCCHNO，BSIC等。RLCFP：CELL=ZHBJYL2；检查小区的频率设置。案例分析：由小区数据定义错误造成的高掉话故障现象：ZHBZHL1在10月21日上午突然出现不正常的高掉话。基站时隙都工作正常，无任何告警。A| AHAlAJCELLTFDISSS5TFSUDLOSTFSUDLOSSlZHBZHL1 !0300ZHBZHL2010ZHBJZM5000ZHBJWY5000ZHBZHL3010ZHBSHL5000ZHBHYD5000ZHBDA01 000故障分析:检查基站的数据定义，发现问题所在。RLCFP：CELL=ZHBZHL1；CHGRSCTYPESDCCHSDCCHACTNCCHPOSCBCHHSNHOPDCHNO0302BCCHNO5ON11241002TNNO7OFF53该小区定义了两个频率组。CHGR0使用P-GSM频段的频率，CHGR1使用E-GSM频段的频率。但在CHGR1中却发现配置了一个P-GSM频段的频率。当不支持E-GSM频段的手机被分配到CHGR1时，由于开了跳频，手机可能会被要求使用E-GSM的频率，因此产生掉话。1.3.4检查并分析ERRORLOGERRORLOG在基站隐性故障排除中起着非常重要的重用，它不仅可用来发现网络潜在的问题，还可以帮助分析已经发现的问题。因此熟练掌握ERRORLOG的分析方法在基站故障处理中意义十分重大。在这里将重点阐述如何读取和分析ERRORLOG。RXELP：MO=RXOTG-69；打印某TG的所有历史告警记录。RXELP：MOTY=RXOTG；则打印一个BSC中所有TG的历史告警记录。然后这些数据可以使用一些工具进行处理使之可读性更强。ERRORLOG的分析方法MO BTSSWVER DATE TIME BTSRXOTRX-217-3 ERA-G02-R04V01*03-09-1817-34-34 STAREPLMAP000000000000000000000001REPLMAP0000000000000000000000011BMAP000000000000000000000000EXT1BMAPEXT2BMAP1AMAP0000000000000000000000002AMAP0000000000000000000040000000 0000DATE和TIME项记录了告警产生或消失的时间。BTS项记录了当时MO的状态。1AMAP，1BMAP和2AMAP对应内部告警的不同级别。EXT1BMAP和EXT2BMAP对应外部告警的不同级别。REPLMAP表示REPLACEUNIT的意思。ERRORLOG中的记录翻译到故障代码采用的是如下机制。Bit15AcliveFanjliCad^D□□oaoD2£oaQBit15Aclive— 1JIIl_t=—1r~ ——I-1IT4744▼43-40T3S-36TJ5-3231-2B▼27-24T23■20r19-16T15-12T11-8i7-443000000002a00DHBxade^imallIoBinaryConvertlion47-4443-4039-3615-3231-胡27-2423■H19・1615-1287-430000000028000OMC00000000DDOOGOOD00000烦0010-IODOoooo0000MOO根据以上规则，上例中的2AMAP000000004000则应翻译为I2A14，对应的MO为RXOTRX-217-3，再查TRX的I2A14的告警解释为“VOLTAGESUPPLYFAULT”。在后面有关于此告警的详细解释。案例分析：由TRU射频环路失败造成的可用率不完整的故障。故障现象：ZHEHSS1在10月31日上午忙时取统计时发现ACRATE=97.7%，用ALLIP看不到基站的任何告警。故障分析：取该小区的ERRORLOG。RXELP:MO=RXOTG-87;MOBTSSWVER DATETIMEBTSMOBTSSWVER DATETIMEBTSRXOTRX-87-0ERA-G02-R04V01*03-10-3110-32-22RESRXOTRX-87-01AMAPREPLMAP1AMAP000000000000000000000001 000000000000 0000000020001BMAP 2AMAP000000000000000000000000 000000000000 000000000000EXT1BMAPEXT2BMAP0000 0000该告警对应的告警代码为TRX1A13,查告警解释表可知为“RFLOOPTESTFAIL”的告警。此告警引起TRU在忙时重启，因此导致信道可用率低。这种类型的告警是由于TRU内部的TX或RX硬件模块出现了故障造成的。对TRX解闭，或对TRU重启都能暂时清除这个告警，但该载频性能下降，而且这个故障还将不定期的出现。因此建议对凡是产生了此告警的载频都予以更换。1.3.5对基站进行检查在BSC终端上对基站的状态及告警进行分析完毕后，应该已经基本清楚问题可能出现在哪几个部分。到基站上就可围绕着这几个方面重点检查。一般来说，检查基站硬件故障可以从以下几个方面入手。1.3.5.1检查基站的硬件安装检查接线是否正确基站手册中对每一种接线方式都有明确的规定，在对基站进行检查的时候我们应注意这些连线是否符合规范。检查射频电缆的接头是否拧紧正常的接头损耗大约为0.1dB。但如果接头拧得不紧，将引入更多的损耗。严重的甚至将引起分极接收丢失的告警或驻波比高的告警。检查基站的接地状况基站如果接地不良，危害是很大的，基站有可能被雷电损坏，也有可能造成传输受到干扰的情况发生。检查LOCALBUS终端头是否安装每个机柜内有两套LOCALBUS系统，一套用于主柜，一套用于连接扩展柜。如果不采用主柜/扩展柜的方式，在主柜的LOCALBUS接头出应该用一个120欧母的终端头将其屏蔽。否则干扰信号很可能通过悬空的接头对LOCALBUS总线进行干扰，造成基站工作不稳定。检查各射频终端接头是否已将悬空的射频信号端口接地按照爱立信的基站安装规范，凡是悬空的射频信号端口都应该用一个50欧母的终端头接地，否则可能引起干扰。

检查天馈线系统的安装是否符合规范一般对天馈系统的检查主要包括这几个方面：馈线的接头是否拧紧，天线的方位角和下倾角是否正确。比较容易忽略的一点是空间分极天线之间的间距和夹角。案例分析：由接线方式错误引起的有信号但打不了电话的故障。故障现象：10月28日上午接到用户投诉，在ZHASXD2小区覆盖的范围内出现了有信号但是打不了电话的现象。

故障分析:检查基站的数据定义，未发现问题。检查基站的告警，基站工作正常，无告警。检查基站的历史告警记录，除了前一天扩容产生的记录以外未见任何异常。于是决定到基站去检查硬件。首先检查基站的硬件安装。发现接线方式错误。导致两路上行信号都不能送到TRU的RX端口。因此也就出现有下行信号却打不了电话的情况了。错误的接线方式：0^^|痴。皇0^^|痴。皇正确的接线方式:wA HafeOCtg瞄FWdFra-1WwA HafeOCtg瞄FWdFra-1W心地FWdFran-J-ff-^8^0000eftae01.3.5.2检查基站的IDB数据基站的IDB数据中包括了基站本身的配置参数，如果配置错误将可能导致基站开通不起来，或者部分功能不正常。检查IDB数据可以从以下几点入手：检查传输的定义如果采用的是传输级连的方式，对有DEV要让给后面基站用的节点，它的NETWORKTOPOLOGY一项应该选择CASCADE。如果已经没有DEV要让给其他基站用了，那么这个基站的NETWORKTOPOLOGY这一项应选择STANDALONE。另外还有一个值得注意的事项。若一个基站使用的DEV来至两条传输链路，那么它的SYNCSOURCE一项应该PCMA和PCMB。原理是这样的，假设PCMA的传输断了，使用PCMA中DEV的时隙肯定会停止工作，但原来使用PCMB中DEV的时隙即使PCMB传输正常也会因为没有同步源而退出服务。所以在这种情况下两个同步源都要选取。案例分析：由基站中传输定义错误引起的部分时隙开不起来的问题。故障现象：ZHENPG2小区只有一半左右的时隙能正常工作，另一部分时隙处于LMO2000的状态，并有TSSYNCFAULT的告警。

故障分析：检查该小区的数据没有发现什么问题。检查历史告警记录也没发现什么问题。该站使用两条传输，其中ZHENPG2使用的DEV分别是从ZHENPG1和ZHENPG3对应的传输级连过来的设备。检查这两条传输质量都没问题。对有问题的时隙检查它们对应的传输设备，发现这些传输设备都是来自ZHENPG3所对应的那条传输（DIP120）。而那些没问题的时隙所使用的传输设备都是来自ZHENGP1所对应的传输（DIP119）。RBLT120RBLT119RBLT120ZHENPG2ZHENPG2使用的命令如下：RXMDP：MO=RXOTS-165-5-7；得到该时隙对应的DEV。RADEP：DEV=RBLT-3861；得到该DEV所属的DIP。通过以上的分析，可以得到初步的结论：该故障和两条传输没有关系，应该是机柜之间的传输级连出了问题。两个机柜之间的传输级连涉及的硬件有DXU，机柜内的传输线，以及机柜间的传输级连线。它们中间的任何一个部分出现问题都会使级连的传输链路受到影响。基站的IDB中对传输的设置不当也会造成级连传输不通。在基站上检查基站数据定义时发现ZHENGP3的NETWORKTOPOLOGY项被设为STANDALONE。这种设置表明ZHENPG3已经是这条传输的终结点了，即使在这条传输上还有多余的DEV，它也不会往下传了。ZHENPG2上那些使用从ZHENPG3级连过来的DEV的时隙由于无法占用传输设备而产生TSSYNCFAULT告警，并且被置成LMO2000状态。ZHENPG3的传输方式正确的设置应该是CASCADE。ZHENPG2的传输方式正确的设置应该是STANDALONE。1.3.5.3检查基站的LOG文件在DXU和TRU，ECU内部各有一个64K的内存芯片，在这个内存中记录了基站过去所发生的任何事情，包括基站产生过的告警，传输状态的变化，基站重启的原因和发生时间等等。对分析和查找基站故障起着非常重要的作用。但由于容量限制的原因，后面的信息可能会把前面的信息冲掉。下面将介绍LOG文件的读取和分析方法。读取LOG文件的方法SystemCabinet0|HardwareCDUD\SystemCabinet0|HardwareCDUD\ppppsssscuuuuuLIDMTTTTTTRRRRRRUUUUUU999999DU9DisplayIrforrridtionDisplaySoftwareVersionsDisplayStatusDefineTE[...5日v日LogResetChangeLocal/RemoteState取出来的LOG文件的样例[03-09-2921:15:07.616]OMS_HWUmps_temp.c:185TRACEH:DXLR091S(PLS-DXU/R8CXC1121202_1.R8_12),STARTCAUSE:RESET_SWITCH,APPL.TYPE:1[90-01-0100:00:00.034]NONAMEdebug_main.c:2492TRACEH:Norestartinfo[90-01-0100:00:00.036]NONAMEdebug_main.c:2505TRACEH:RESETTIME:03-09-2921:15:07.616[90-01-0100:00:00.036]NONAMEdebug_main.c:2520TRACEH:DXLR091S(PLS-DXU/R8CXC1121202_1.R8_12),STARTCAUSE:1(RESET_SWITCH),APPL.TYPE:1常用的LOG文件中的记录的解释[90-01-0100:00:00.034]:表明DXU,TRU或ECU发生了重启。RESETTIME:记录了重启的时间。STARTCAUSE:记录了产生重启的原因。PCM_UPDATE_RPTarrived:表明基站检测到传输的状态发生了变化。它后面会跟一串数字，每个数字有一定的含义。Bit1:PCMAerror(0=noerror,1=error)Bit2:PCMAavailable(0=notavailable,1=available)Bit3:PCMBerror(0=noerror,1=error)Bit4:PCMBavailable(0=notavailable,1=available)Bit5:PCMsynchronisationsource1(0=PCM_A,1=PCM_B,2=optionaloscillator)Bit6:PCMsynchronisationsource2(0=PCM_A,1=PCM_B,2=optionaloscillator)receivedreleaseonlinkCF则表明LAPD信令中断了，要重新建立。LAPDprotocolerror表明LAPD数据链路层出现错误。它后面跟一个数字，代表一定的意思。12：表明从基站的角度来看，LAPD链路已经断开。这意味着下行或两个方向的传输链路已经断开。1：表明基站已确信LAPD链路已经断开。14：表明从基站角度来看LAPD链路已经建立起来，但从BSC的角度来看链路还没建立起来。一般来说，14对应着上行传输链路出错的情况。案例分析：对两例TRU自动重启的故障的处理。案例一：故障现象：ZHEYMY1小区连续几天出现TCH可用率低的情况，基站上面没有任何告警。故障分析：首先检查该小区的历史告警记录。从ERRORLOG中我们发现有如下记录。MOBTSSWVERDATE TIMEBTSRXOTRX-69-1ERA-G02-R04V01*03-10-1420-39-45RESREPLMAP0000000000000000000000001AMAP0000000000000000000000001BMAP0000000000000000000000002AMAP000000000000000000000000EXT1BMAPEXT2BMAP0000 0000MOBTSSWVERDATETIMEBTSRXOTRX-69-3 ERA-G02-R04V01*03-10-1420-39-45REPLMAP 1AMAP000000000000000000000000 0000000000000000000000001BMAP 2AMAP000000000000000000000000 000000000000000000000000EXT1BMAPEXT2BMAP0000 0000RES如前面所叙，ERRORLOG中BTS这一项目反映了MO的状态，RXOTRX处于RES状态表明这个TRU正在重启。从上面ERRORLOG中的记录可以看出该小区的四个载频均有重启的现象，而且发生的时间为10月14日20点39分45秒。由此造成了当晚统计的TCH可用率低的现象。现在的问题是：到底是什么原因造成了该小区TRU及ECU的自启动故障？我们检查了该TG的MO数据定义，没有发现问题。我们检查该TG对应的DIP的质量，也没发现问题。<DTQUP:DIP=RBLT28;DIPT1T2SLIPSLIP2UASUASRUAV1UASB1UAV2UASB2RBLT28129 00000000SECTIONESVSESVDMVESVRSESVRDMVRSFVSFTI0000024SECTIONES2VSES2VDM2VES2VRSES2VRDM2VRSMI00000END读取DXU，ECU和TRU的LOG文件进行分析。在DXU的LOG文件中我们发现有如下记录。[03-10-1420:38:37.212]PLS_SAP_MAINsap_main.c:1615TRACEH:TRU0DISCONNECTED[03-10-1420:38:37.222]OMS_SO_MAINso.c:19798TRACEH:SAPdisconnected[03-10-1420:38:37.242]PLS_SAP_MAINsap_main.c:1615TRACEH:TRU1DISCONNECTED[03-10-1420:38:37.270]OMS_SO_MAINso.c:19798TRACEH:SAPdisconnected[03-10-1420:38:37.272]PLS_SAP_MAINsap_main.c:1615TRACEH:TRU2DISCONNECTED[03-10-1420:38:37.296]OMS_HWUhwu.c:33071FAULT:LB:0,raisei2aMISSINGRUTRU0[03-10-1420:38:37.302]PLS_SAP_MAINsap_main.c:1615TRACEH:TRU3DISCONNECTED[03-10-1420:38:37.322]OMS_SO_MAINso.c:19798TRACEH:SAPdisconnected[03-10-1420:38:37.322]OMS_SO_MAINso.c:19798TRACEH:SAPdisconnected[03-10-1420:38:37.332]PLS_SAP_MAINsap_main.c:1615TRACEH:ECU0DISCONNECTED[03-10-1420:38:37.338]RTS_ENV_SERVERrts_environment.c:228TRACEH:LostlinktoECUTOC\o"1-5"\h\z0,tryingtoregaincontact 、[03-10-1420:38:37.362]PLS_MUNICHmun_isl.c:1064TRACEH:======>(ResettingISLJchannel.IslResetCnt=10(sincelastDXUreset) 、 "[03-10-1420:38:37.482]OMS_SO_MAINso.c:19798TRACEH:SAPdisconnected[03-10-1420:38:37.492] OMS_HWU hwu.c:33071 FAULT: LB:0, raise i2a MISSING RU TRU 1[03-10-1420:38:37.670] OMS_HWU hwu.c:33071 FAULT: LB:0, raise i2a MISSING RU TRU 2[03-10-1420:38:37.772] OMS_HWU hwu.c:33071 FAULT: LB:0, raise i2a MISSING RU TRU 3[03-10-1420:38:37.852] OMS_HWU hwu.c:33071 FAULT: LB:0, raise i2a MISSING RU ECU 0在四个TRU中都读到如下记录。[03-10-1420:38:37.332]PLS_HX_INT0hx_int.c:3494TRACEH:ISLprotocolerror[03-10-1420:38:37.576]PLS_HX_MAINhx_main.c:376TRACEH:DXUlostActivatecommandinstateconnected[03-10-1420:38:37.588]PLS_HX_MAINmps_temp.c:185TRACEH:TRLR091S(PLS-TRU/R8CXC1121202_1.R8_12),STARTCAUSE:DXU_LOST,APPL.TYPE:1[90-01-0100:00:00.034]NONAMEdebug_main.c:2492TRACEH:Norestartinfo在ECU中读到如下记录。[03-10-1420:38:37.366]PLS_HX_INT0hx_int.c:3494TRACEH:ISLprotocolerror[03-10-1420:38:37.580]PLS_HX_MAINhx_main.c:376TRACEH:DXUlostActivatecommandinstateconnected[03-10-1420:38:37.594]PLS_HX_MAINmps_temp.c:185TRACEH:ECLR091S(PLS-ECU/R8CXC1121202_1.R8_12),STARTCAUSE:DXU_LOST,APPL.TYPE:1[90-01-0100:00:00.046]NONAMEdebug_main.c:2492TRACEH:Norestartinfo可以看出四个TRU和ECU都检测到ISLPROTOCOLERROR的错误，触发重启动的条件都是DXU_LOST。当DXU检测到和TRU，ECU失去联系后，发出RESETTINGISLCHANNEL的命令。我们可以看出从上次DXU重启以来ISLCHANNEL共重启了10次(IslResetCnt=10)。关于ISL的简介。ISL(InternalSignalingLink)是一种点对多点的信令协议，用于DXU和TRU及ECU之间的通讯。例如在基站启动时传递IDB配置参数，各子系统之间的通信都要用到ISL。读取ECU和TRU的LOG文件也是通过ISL进行的。ISL和LAPD信令一起在LOCALBUS上传递。LOCALBUS是基站内部用于在DXU和TRU，ECU之间传递语音及信令的一条串行总线，其带宽为2.048Mbit/s，也分为32个时隙°ISL占用TSO-TS2时隙，LAPD信令占用TS3—TS8时隙，TS15-TS26则分配给TCH(每个TRU占用两个时隙)。

其逻辑结构如图所示。ISLLAPDTCHISLLAPDTCH在DXU中ISL是由ConcentratorHW来处理，在TRU中则是由PLS(PlatformSubsystem)子系统来实现的。如图所示。话音和信令通过LOCALBUS传到TRU，在TRU内部ISL和LAPD(OML和RSL)是由CPU来处理的。而话音数据则是由TORA模块来处理。因此从物理上来看，和ISL相关的硬件有DXU，背板连线及插座，TRU和ECU。任何相关的部分出现错误都有可能引起ISLPROTOCOLERROR的告警。鉴于所有的TRU及ECU上都检测到该错误，我们首先怀疑是DXU中处理ISL的功能模块出现问题。于是我们将1小区的DXU和3小区的DXU进行互换，然后观察是否还有自动重启的现象。到目前为止，1小区和3小区都没有观察到TRU/ECU有自动重启的记录。这说明原1小区的ISLPROTOCOLERROR的告警应该是由该小区的DXU和背板插座之间接触不良造成的。案例二：故障现象：十二村站2小区（ZHESEC2）经常出现载频自启动的现象。并且TRU有XBUS出错的告警。故障分析：上站检查时，发现将2小区的DXU置于LOCALMODE时，TRU和ECU仍然循环自启动。读取TRU和ECU,DXU的LOG文件进行分析。发现TRU和ECU重启的原因都是ISLPROTOCALERROR。我们将基站掉电，重新插拔DXU后故障现象仍然存在。更换此DXU后，故障排除。估计这是由于DXU内部处理ISL协议部分硬件损坏引起的载频工作不稳定。在TRU重启的过程中产生了XBUSFAULT的告警。1.3.5.4使用OMT对基站的性能进行监测基站对一些重要的性能提供了实时监测功能，如发射功率，反射功率，驻波比等。通过对这些数据的监测，我们可以知道基站目前的工作是否正常。对TRU和CDU的输出功率进行监测

TRU9TRU9gU3DUCU9DisplayInrarm^tisnDisplaySoftwareVersions5aveLogDisplayStatusResetChangeLocal/RemoteStateMonitor...TRTRFANpsUpsUpsUpsUpsUpsUpsUpsU可以监测的项目有TRU的前向功率和反向功率，CDU的前向功率和反向功率，天馈线的驻波比。注意：只有发射共用或单发射天线才能监测出它的驻波比，单接收天线是不能用这种方法来监测其驻波比的。对基站的同步性能进行监测读取完基站的IDB后在MO所指的页面上，选中TF图标，然后单击鼠标右键，选择MONITOR，可以看到有些选项，其中比较重要的是：PHASEDIFFERRORPCM_A，TUINTERNALSTATE和VCOCONTROLVALUE等项目。PHASEDIFFERRORPCM_A用来检测基站内部时钟源和外部时钟源之间的相位差。正常情况下测量值应该是在0附近波动。如果测量值的绝对值很大并且保持恒定则有可能是DXU内部时钟源有问题产生了漂移，但还在可控制的范围内。如果测量值波动太大则有可能由于传输信号不稳定造成的。TUINTERNALSTATE表示基站的内部时钟源的同步状态，它有几种取值，0表示正在建立同步，1表示已经建立同步，2表示基站是处于HOLDOVER状态，也就是用基站自己的时钟源。VCOCONTROLVALUE这个测量值反映了对基站内部VCO电路调控的情况。正常的范围是273-16111,超出这个范围将产生告警。案例分析：驻波比高引起的手机接收信号不稳的案例。故障现象：在ZHAXMS小区所覆盖的范围内进行路测时发现手机接收信号有时很强，有时很弱，变化很大。故障分析：在分析该基站的ERRORLOG时发现该小区时不时的出现驻波比过高的告警。驻波比是一个反映天馈线对无线信号藕合程度的指标。驻波比比值越接近1，表明天馈系统的藕合程度越高，也就有越多的无线信号发射到空中。反过来，驻波比比值越高，则表明有更多的无线信号在天馈线系统中损耗了，实际发射到空中的无线信号强度也就越弱。在爱立信基站中设置了两个告警门限值。缺省情况下当驻波比超过1.8时产生A3的告警，当驻波比超过2.2时产生A2的告警。这两个门限值可以根据需要适当的调整。

在基站上可用OMT对有信号发射的天线的驻波比进行监测。对ZHAXMS站进行检测的结果如图。该检测值的正常范围为1.2左右。而这里的检测值已经快接近告警门限值了。当时隙使用这个发射机发射时，它的有效输出功率肯定比采用其它发射机时要弱。因此也就造成了手机的接收信号变化很大的情况。该故障已通知代维公司对天馈线进行检查。1.3.6使用仪表设备对基站进行检测在无法有效分清楚故障是由外界因素引起还是内部因素引起的情况下，可以通过仪表对基站进行测试。下面将描述使用两种仪表对基站进行测试的方法。1.3.6.1使用扫频仪检查上行干扰当基站出现上行十扰时，可能是由载频工作不正常引起，也可能真正存在外来的上行十扰信号。这时候我们可以通过扫频仪很快的分清问题来自哪里。案例分析：如何使用扫频仪快速诊断上行干扰是受外界引起还是由基站工作不正常引起。故障现象：ZHBJZG2一直存在较多的上行质量掉话。用RLCRP可以看见ICMBAND值较大。故障分析：在OSS上对该小区做FAS，结果表明该小区所有频率基本上都受到了干扰。4.在BSC上用以下命令也可确认这一点。RLCHC：CELL二ZHBJZG2,HOP=OFF；先将跳频关闭。RLCRP：CELL=ZHBJZG2；找出受干扰比较大的BPC。RXCDP：MO=RXOTG-69；找出和BPC相对应的时隙，和使用的频率。重复使用以上命令，可以发现每个频率都不同程度地受到了干扰。5.为了确定干扰是否来自外界，使用扫频仪进行实地勘查。该站位于山上，位置较高。在山脚下测量，未发现有上行干扰，背景噪声为-120dBm左右，很正常。但是将一根天线从CDUD的RXANT端口断开，接到扫频仪上时就发现上行干扰是很强的。而且宽频干扰，几乎所有频点都受到了干扰。如图：|G5M900d嗥■回Cnanncl:|Freq(MHz):?91.14C0SpectrumSpectrogramTrace2:|MaxHeld三］膏导，M—1膏导，M—1溟<5^-mca百10〔一史岂O391.140MHzRace2-742dBmOAH上日匚［VHZMl-6Z.UdBm□b^y.ibJ［/1HZ「修-tJ.HCbn6口 己43工MHIl.tdtDatE：03-10-2916:53:04Technician:Note:这就证明了上行干扰来自外部。因此精力应花在外部干扰源的查找上面来。1.3.6.2使用SATT对基站进行检测

某些情况下基站的故障和传输的故障夹杂在一起，或者出现了单通等比较少见的故障，为了验证故障是否出在基站本身。我们可以使用SATT对基站进行全面的测试。例如这次为了验证某基站是否存在单通的故障就使用了SATT对该基站进行测试。详细情况可参考“基站单通故障的查找”部分，以及SATT的操作手册。22.1关于时隙同步失败(TSSYNCFAULT22.1关于时隙同步失败(TSSYNCFAULT)问题的分析什么是TSSYNCFAULT告警。TRAUFRAME介绍BSC RBSBSC RBSBSC中的TRAU设备负责将64Kbits/s的语音信号转换成13Kbits/s的语音信号。然后封装在TRAUFRAME中通过Abis接口传至基站。DXU负责将这些帧分发到相应的TRU，再由TRU内部的GSM信号处理模块(TORA)处理这些TRAUFRAME帧中的信息，对其进行卷积，交织等处理，生成BURSTS在XBUS上传送。TRAUFRAME的帧结构如下图。一个TRAUFRAME长度为320bits（40Bytes），携带20ms的话音数据（260bits）和60bits的同步信息及带内信令信息。一个TRAUFRAME占用一个16k的子信道进行传送。每个TRAUFRAME总是以HEADWORD（0000H）开始的。TSSYNCFAULT告警产生的原理TRA或TS实时地监测Abis接口上的TRAUFRAME，如果在TRAUFRAME的HEADWORD（0000H）该出现的地方检测不到该WORD，则认为TRA和TS之间的同步丢失，也就产生TSSYNCFAULT（TSEC1B3）的告警，同时将该TS的状态标为LMO2000，以防止系统在分配信道资源时再使用该时隙。当时隙处于这种状态时，用RXCDP是看不出有问题的时隙来的。用RLCRP可以看到有问题的时隙所对应的BPC为BLOC状态。下面我们分别讨论TS被占用和TS空闲两种状态下所发生的情况。TS被占用时的情况。在TS被占用时，TS和TRA设备之间有承载着语音信息的TRAUFRAMES在相互传递。同时双方也都在监测TRAUFRAMES的完整性。如果上行或下行任何一侧TRAUFRAMES检测不出来，即产生TSSYNCFAULT的告警。TS空闲时的情况。在TS空闲时，没占用TRA设备，此时BSC自动将TS发送过来的TRAUIDLEFRAMES（UPLINK）经GS/SRS环回给TS，所以我们可以看到在下行链路上传送的也是同一TRAUIDLEFRAMES（UPLINK）。在这个链路上，任何一个环节出现问题使得TS检测不到环回的TRAUIDLEFRAMES，都将引起TSSYNCFAULT的告警。对现网中存在的TSSYNCFAULT告警的分析从以上的理论分析我们可以看出引起TSSYNCFAULT告警的因素有很多，TRU硬件，传输质量，SRS设备，TRA设备都有可能引起这类告警。因此我们收集了现网中存在的TSSYNCFAULT告警以及产生告警时的相关参数，如产生告警的时间，当时的话务量，传输质量，以及所使用的信令压缩方式等等。这样做的目的是为了找到引起这类告警的某种线索。由传输引起来的TSSYNCFAULT告警君悦来站（ZHBJYL）出现此类告警的机率较高。因此我们着重检查了这个站的情况。10月17日上午我们观察到该站三个小区均出现有时隙同步错误的告警，我们记录下了这些出现错误的时隙。TOC\o"1-5"\h\z:<RXMFP:MOTY=RXOTS,FAULTY; :: RADIOX-CEIVERADMINISTRATION :: MANAGEDOBJECTFAULTINFORMATION ::MO BTSSWVER ::RXOTS-27-2-5 ERA-G02-R04V01* :i RURUREVISION RUSERIALNO i-0 :: RUPOSITION RULOGICALID ::STATE BLSTATE INTERCNT CONCNT CONERRCNTLASTFLTLFREASON::OPER 00000 01992 02814 :i EXTERNAL FAULT CODESCLASS1B :i 3 :查找该时隙的历史记录。:<RXELP:MO=RXOTS-27-2-5;:WOZHB1BSC91/FA/0/0/02/06AT-3TIME0310171017:RADIOX-CEIVERADMINISTRATION:ERRORLOGDATA!FAULTINFORMATIONLOGiMO BTSSWVER DATE TIME BTS:RXOTS-27-2-5 ERA-G02-R04V01*03-10-1708-58-30 ENA:REPLMAP 1AMAP! 000000000000 000000000000 000000000000 000000000000:1BMAP 2AMAPi 0000