BTS常见问题处理.docx
- 文档编号:5308107
- 上传时间:2022-12-15
- 格式:DOCX
- 页数:15
- 大小:175.91KB
BTS常见问题处理.docx
《BTS常见问题处理.docx》由会员分享,可在线阅读,更多相关《BTS常见问题处理.docx(15页珍藏版)》请在冰豆网上搜索。
BTS常见问题处理
常见问题的分析解决及预防
一、驻波比VSWR告警
二、基站BTS数据下载不正常
三、小区misalign
四、TCH分配失败
五、规范化操作
六、OMC告警显示
七、A925TC故障分析报告
八、BSC出现数据吊死处理方法
九、关于两种触发TCURestart故障的情况说明
十、RSLFLT故障分析
一、驻波比VSWR告警
驻波比故障分三种:
载频(TRE)驻波比、天线(antenna)驻波比、载频(TRE)驻波比
现象:
TRE退服,不能正常工作;
影响:
如果小区载频配置少,会引起拥塞,如此小区是单载频的话,则这个小区所覆盖的区域信号差或直接打不了电话,引起投诉。
问题的分析:
1、载频TRE硬件故障
2、TXCABLE坏引起
3、合路器(ANC)由于某1路端口不正常引起
解决方法:
1、首先调换TXCABLE,观察故障是否有转移来确认TXCABLE是否好坏;
2、更换载频TRE;
3、更换载频连接合路器(ANC)的端口,如没有端口,则需要更换合路器(ANC)天线(antenna)驻波比;
现象:
小区退服,小区所有载频退服,不能正常工作。
影响:
这个小区所覆盖的区域信号差或直接打不了电话,引起投诉;
问题的分析:
1、合路器(ANC)硬件故障;
2、馈线弯曲过大、变形及馈线与跳线接口是否拧好或进水引起;
3、天线老化、损坏;
4、载频(TRE)内部故障及TXcable引起;
5、同频或邻频干扰引起,主要是本小区的频点;
解决方法:
1、用驻波比测试仪定位是不是由天馈部分引起的驻波比,天馈部分包含:
天线、馈线、跳线、馈线与跳线接口
2、更换合路器(ANC),如是单载频小区,调换TXCABLE及载频来判断硬件是否好坏;
3、检查逻辑数据有没有错误;
二、基站BTS数据下载不正常
ØBSC方面引起
1、数据问题(数据配置不正确、创建时数据出现异常)
2、ABIS端口不正常
3、LIU板或TP板引起个别BTS数据下载不正常(情况极少)
ØBTS方面引起
1、数据配置问题
2、硬件问题,包含:
SUMA、ANC、TRE、后背排线部分、XIBM(OUTC)、机框
Ø传输问题
1、传输连接问题
2、传输误码:
开站时有误码无法开通,开通后有误码可能不影响基站功能
3、传输帧丢失
Ø传输方面:
1、检查传输链路在对BTS和BSC自环及断开的情况下是否都
正常,如基站自环不正常,需要一级一级的更换硬件(Eacb板、Eacb到SUMA板的连线、SUMA板);
2、在BTS和BSC检查传输有没有误码及帧丢失的告警,如果有,则首先检查BSC侧与BTS侧的传输2M头和连接BTS的9针串口是否有虚焊的情况,如都是正常的话,接下来就要检查基站接地、光端机接地是否良好,最好拿1根线把基站和光端机的地线连接起来;接地不好容易导致传输误码或帧丢失
3、如传输还存在问题,可以考虑更换光端机。
2、对于BSC方面:
●检查创建基站配置的数据是否正常
●切换主用的SYS-CPR(OMCP),再重新下载数据
●删创基站的数据
●在不同的LIU板上,重新创建BTS
3、对于BTS方面
●更换SUM板;
●拔出所有的硬件(ANC、TRE),不包含SUM板,从OMC-R
上重新下数据,如果还是不能下数据,则排除ANC/TRE所引起的问题,如果可以的下数据,则逐一添加小区硬件来确认是由那块硬件所引起的;
●确认基站上的硬件没有问题,可以更换基站机框上的后排
线,在更换排线的同时需检查连接排线的电路板是否短路或损坏情况,在特定的情况下,可以把排线上端的不连接机架背后的电路板,因为这块电路板有时会影响基站数据的下载;
小区Misaligned问题:
现象:
小区的alignedstatus状态为misaligned,在omcr上能够发现小区上有“!
”的标志,多发生于在对小区配置或参数进行修改的过程中。
影响:
小区及相关小区(例如同misaligned小区有切换关系的小区)无法继续修改参数,在割接过程中可能影响割接的进度。
问题的分析:
Omcr的数据库同BSC的数据库应该保持一致,不管逻辑参数的修改(以OMCR上设置的为准更新BSC的数据库)还是LOGICALAUDIT(以BSC数据库为准,更新OMCR的数据库)的过程,两个数据库之间都有一个同步的过程,若在同步过程中发生了异常,则会使数据库的更新无法实现,从而导致数据库的不一致。
系统中存在一种misaligned机制,当系统发现存在数据库不同步时,在小区上标志出Misaligned的标志,目的是提醒操作维护者数据修改(或者logical
audit)没有正常完成,需要后续工作来保证OMCR和BSC数据库记录的参数一致
我们根据misaligned出现的情况及cause,有如下办法解决小区misaligned的问题:
1.Logicalaudit时出现misaligned
Logicalaudit时需要从BSC数据库中提取逻辑参数,更新OMCR上数据库中记录的信息,如果更新时发生故障,一般是由OMCR和BSC连接故障引起的(有可能是逻辑链路),会引起对应小区misaligned,现象和解决方法有两种:
情况一:
如果在GSMalignmentcause中显示为“lostofcommunicationwithBSC”。
则需观察此时BSC-OMC的连接状况;如果连接问题得到解决,重新做audit(或UploadRadioParameter)。
情况二:
如果在GSMalignmentstatuscause中显示为“jobunsuccessfullreceivedfromtheBSC”重新做audit,如果一个BSC下有许多小区Misaligned,可以做“LogicalauditBSS”。
2.参数修改(包括PRC/SC修改)时出现misaligned
逻辑参数修改时是以OMCR上的逻辑配置为准,修改过程中需要更新对应的BSC数据库中的记录,在更新失败时,相应小区/BSC会出现misaligned,大致有三种情况及其解决方法如下:
情况一:
如果在GSMalignmentcause中显示问题原因为“lostofcommunicationwithBSC”。
则需观察此时BSC-OMC的连接状况;如果连接问题得到解决,而该BSC下出现Misaligned的小区又很多,此时则需要通过对BSC做ForceConfigBSS或对Misaligned的小区逐个来做ForceConfig
情况二:
如果在GSMalignmentstatuscause中显示为“jobunsuccessfullreceivedfromtheBSC”,则需要做BSSForceConfig(如果此时有许多小区Misaligned则还需做这些小区的ForceConfig)
情况三:
如果执行了ForceConfig后,小区依然处于Misaligned的状态,可能是由于BSC比较忙,可以等一段时间后再作,在少数情况下,需要通过PRC来删创该小区解决misaligned。
1.misaligned发生小区修改参数后,一般可以通过“forceConfig”消除,其原理是让OMCR上记录的参数强行同步到BSC数据库中,由于“forceConfig”会要求BSC数据库向OMCR同步所有小区的参数,如小区参数,邻小区参数等,BSC需要一段时间更新对应数据库,“forceConfig”需要一段时间,如果“forceConfig”消除不了,则可以切换OMCP,再做“forceConfig”的操作,如以上操作都不能解决,则需对BSC在omc-r上进行删创。
2.由于参数修改时可能发生的问题很多,如OMCR和BSC的连接瞬间出现故障(可能是逻辑链路),或者是相同操作在同一模块上,导致BSC响应混乱,或者BSC没有足够时间响应给连续的操作,等。
就会出现misaligned,我们只能通过优化OMCR到BSC的数据更新流程,规范操作维护过程来减少出现的概率,同时通过正确的维护操作,提高解决misaligned的速度。
1.建议每天或在大规模在数据的前后在OMCR上作Inconsistencies(不一致)检查,以尽早发现并纠正数据库不一致的地方原因:
提前发现并及时解决omcr上数据库中的不一致有助于减少misaligned出现的概率
2.建议操作维护人员在修改参数时出现misaligned后,及时消除;
原因:
只有操作者明确是什么操作后出现misaligned,如果没有时间处理,请做好记录后转给他人处理,如操作的简单目的描述,操作的时间等。
3.建议操作维护人员在参数修改时,观察RNUSM/BSSUSM“followup”窗口中显示其他用户的操作和本人操作的进行过程,如果有其他用户在对某网元操作,则等其结束后再做,如果有关于本人操作不成功或不完全成功时,可能会导致OMCR和BSC数据库参数出现不一致,请先消除后再继续操作;原因:
部分成功的操作不会出现misaligned,但是由于数据库更新没有完全成功,可能导致下次操作出现misaligned,绝对要避免对同一网元同时做冲突的操作;
4.建议不要在对BTS做硬件维护或硬件配置修改时,同时对相应小区修改逻辑参数;原因:
有时小区逻辑参数修改时也需要自动对硬件作操作,让参数修改到BTS/小区中,如unmapped/mapped小区时需要对BTSO&M做lock/unlock,这个操作是在PRC激活时自动完成,如果其他操作同时进行导致上述过程无法正常进行,就可能导致小区misaligned;
5.建议对多个小区修改逻辑参数,尽量用PRC方式,如果在SC中直接修改,对于和某个小区有切换关系的小区,它的参数修改就要等前面小区结束后再进行;
原因:
参数修改时,需要更新OMCR上的数据库和BSC的数据库,逻辑参数修改时首先更新OMCR上的数据库,然后更新BSC的数据库,由于更新BSC的数据库需要时间(更新DLS和网元中的记录,如TCU,DTC等),连续的操作可能使后一个操作无法及时更新BSC数据库而出现misaligned。
PRC操作时OMCR会安排一个优化的过程,而且PRC激活时会将相关小区状态保留,杜绝其他的操作同时进行。
TCH分配失败
现象:
话务统计报告中TCH的分配失败率偏高,分配失败次数有时表现为某个特定的小区,有时表现为整个BSC下的所有小区。
影响:
影响考核指标,严重时有用户投诉。
分析与解决:
TCH分配失败是在由TCH分配指派过程中发生异常而造成TCH无法分配的现象,造成TCH分配失败的现象主要有以下几种原因:
1.TCH的资源拥塞
2.无线环境的原因
3.A接口的故障(通过018报告中,C181计数器能判断)
4.相关硬件的原因(TCU,TRX等等)
5.基站割接过程中非规范的流程造成TCH分配失败
6.系统的原因造成的TCH分配失败
上述几种情况是引起TCH分配失败的可能原因,其中前3种情况一般可通过分析话务报告,采用一般的优化手段能够定位及解决,这里主要分析后三种情况
1.载频或对应TCU的硬件可能造成TCH的分配失败对于一些永久性的故障,维护人员往往能够很快的定位并解决,而某些间歇性的故障可能不易被某些维护人员发现。
2.当发现有TCH分配失败的现象,若在相关硬件上没有发现相关的实时告警,则可以观察一段时间内的历史告警,通过历史告警往往能够发现相关载频或其他相关硬件(如TCU)的一些间歇性的告警,而这些间歇性的告警往往就是TCH分配失败的主要原因。
此外,基站的一些配套模块及设施异常,可能也是TCH分配失败的间接原因,例如曾经有1个CASE,发现在基站割接至其他端口后往往能够正常运行一段时间,但持续一段时间后就有TCH分配失败的现象,排除所有直接相关的硬件,现象依旧。
在发现基站的风扇模块异常,解决后,TCH分配失败的现象也随之消失。
该CASE中TCH分配失败的现象其实是载频长期工作在高温情况下(由于风扇模块不能正常工作),发生性能异常所致,而割接BTS的过程中,载频停止工作了一段时间,因此刚开始工作时,由于工作温度符合要求因此不会马上表现为异常,但在工作过程中,由于散热效果不好,使其长时间工作于高温状态下,因此影响性能,产生TCH分配失败的现象
3.基站割接过程中非规范的流程造成TCH分配失败割接基站过程中的操作次序若同正常流程不一致将造成TCH分配失败。
基站割接基本流程:
a)检查告警,状态计算ABIS容量(对G2bsc)
b)COPYBTS
c)创建备份PRC
d)创建工作PRC
e)SHUTDOWNCELL
f)割接传输
g)UNLOCKBTS_O&M,完成AUDIT
h)激活PRC
现场在基站割接过程中往往把激活PRC的步骤提前至割接传输之前,这样在割接完成后有可能造成TCH分配失败的现象。
预防措施:
⏹按正常的流程进行割接基站
⏹若按错误的顺序先激活PRC再割接基站,需在割接完成
后,对基站做RESET,或
对O&M做lock,unlock操作
⏹由于发生系统内部相关资源的错误指向,使得所有分配在错
误资源上的链路建立请求都会发生失败,这就造成了TCH分配失败的现象。
案例:
某分配失败高的基站在软件中载频的相关状态异常
案例:
某分配失败高的基站在软件中RSL同载频的映射异常
案例:
TRX同RSL的对应关系不同造成分配失败,在工程及维护过程中注意规范化的操作能够避免这种情况。
规范化操作现网经常会在基站的配置调整过程中发现TRE/RSL对应不上,小区出现TCH分配失败等现象,这种现象的出现同配置调整过程中没有按照规范操作有很大关系。
严格按照配置调整手册描述的步骤进行操作,能最大限度的避免工程及维护过程中出现的异常所有网络配置调整的手册都能够在BSSCUSTOMERDOCUMENTATION中查阅到,这里简单介绍一下现场经常涉及到的操作及可能忽视
的地方。
涉及如下操作:
1.扩容规范操作(以4频点的BTS扩容至5频点为例)
2.替换不同类型硬件的规范操作(已TRGM替换TRAGE为例)
扩容前检查(OMCR上操作)
⏹执行AuditAlarmState
⏹检查相关网元的状态及告警
⏹检查扩容所需的资源(OMCR上操作)
⏹检查传输资源
⏹检查BTS机架容量
⏹小区逻辑数据扩容的准备
⏹创建备份PRC1(用于原来配置的备份)
⏹创建扩容PRC2(用于设置扩容所需的逻辑数据)
⏹在PRC2中设置扩容所需的逻辑数据
⏹如频点分配,跳频序列调整,逻辑信道设置等相关扩容数据
⏹硬件扩容准备(BTS侧操作)
⏹执行StartHWConfigurationModification。
⏹插入载频(TRE),ANY模块,并连接相应的射频线。
⏹硬件的配置调整(BTS侧操作)
⏹EDITSECTORMAPPING(确认的作用)
⏹InitializeSingleTRE
⏹EndCommission
⏹结束硬件配置调整
⏹FinishHWConfigurationModification(BTS侧操作)
⏹等待omcr上HWAUDIT的结束,并观察结果(OMC侧操作)
⏹检查告警状态
⏹逻辑数据调整
⏹激活创建的PRC
⏹拨打测试,检查状态告警
注意点:
现场操作时,往往忽略BTS侧相关命令的操作,只是在OMCR上完成数据后直接在BTS上进行硬件调整,这可能会引起BTS侧同BSC侧数据的不一致,造RSL/TRE对应不上,TCU分配失败等异常
替换不同硬件类型的规范化操作:
⏹替换前检查(omc上操作)
⏹AuditAlarmState
⏹检查替换前状态
⏹Shutdown相应的RSL(omc上操作)
⏹Lock相应的TRE(omc上操作)
通知基站侧可进行硬件的替换:
⏹基站侧更换模块(BTS侧操作)
⏹更换不同类型的硬件模块(如用TRGM替换TRAGE)
⏹StartHWConfigurationModification
⏹InitializeSingleTRE
⏹EndCommissioning
⏹FinishHWConfigurationModification
⏹等待OMCR上HWAUDIT结束
⏹恢复通信
⏹UnlockTRE
⏹UnlockRSL
⏹注意事项:
不同类型的载频替换现场往往采用寻常的更换tre更换流程,忽视rsl的lock/unlock,基站侧的终端上的配置调整,这可能导致BSC内部相关数据的异常而出现异常。
OMC告警显示问题
现象:
OMCR上个别告警没有及时更新
OMCR上个别网元告警丢失,无法看到告警信息
影响:
对于在OMCR上没有产生告警的故障无法及时发现及时处理
分析:
BSS中有两个队列,分别更踪着BSC/TC和BTS的所有网元的告警状态,并更新至SYSCPR(OMCP)中的告警文件中,OMCR从这两个文件中同步BSS的告警。
若在OMCR上出现告警显示异常时,我们需分析出故障点到底在哪里?
可能有如下三种情况:
1.中的告警文件正常,OMC的相关进程没有正常接收到BSC发出的告警信息
2.告警队列中的告警信息没有更新至SYSCPR(OMCP)中的告警文件
3.告警队列中没有正常更新网元的告警状态
解决方案:
1.对于第1种情况,由于SYSCPRC(OMCP)中的告警文件中有正常的告警信息,因此只要在OMCR上对此网元做ALARMAUDIT即可使OMCR上的告警数据库重新同BSC上的告警文件取得同步,从而显示正常的告警信息。
2.对于第2种情况,由于SYSCPRC(OMCP)中的告警文件中没有相关正常的告警信息因此在OMCR上执行ALARMAUDIT没有用,需把SYSCPRC(OMCP)上的告警文件删除,此时系统会自动根据告警队列中的告警信息重新生成正常的告警文件,然后再OMCR上触发ALARMAUDIT,则能重新显示正确的告警信息。
3.对于第3中情况,由于告警队列中异常,此时可对相关的模LOCK/UNLOCK操作,触发更新正常的告警状态。
保证BSC与OMC-R连接的稳定性加强网络维护,减少短时间内频繁告警的现象A925TC故障分析报告
据现场反应,一个A925TC上部分MT120模块出现重起的现象。
问题处理过程:
1.在TAC远程支持下,现场工程师断开SUBRACK3和
SUBRACK4的架内连线后,重起的模块恢复正常。
2.TAC工程师在现场处理并收集信息。
连接此前断开的连线,
模块出现重起现象,由于时间紧迫,未能继续处理下去,但是收集到了数据和告警。
之后恢复到前一天状态。
3.根据收集到的信息及此前的处理操作,判断为第四子架的
TEI74存在问题,经过插拔后,连接背板连线,重起现象未再出现。
为防止故障再次发生,更换了这个模块
操作分析:
根据TAC和现场工程师在故障发生后的操作来看,当断开第三和第四分架的总线连接后,重起现象消除,可以确认是由于总线上面或者是和总线相关的某些模块存在故障。
⏹TAC工程师在现场收集了以下的信息进行了分析:
⏹TC_TEDECFiles(subrack4isisolatedfromsubrack1/2/3,sotherearetwofiles)
⏹MT120debugtracefile(astheabove)
⏹OMC-R的历史告警
⏹subrack1/2/3:
通过TC—Terminal连接第一、二、三分架的任意一块MT120上,收集告警,均未发现有任何异常信息。
⏹subrack4:
通过TC—Terminal连接第四分架上的任意一块MT120上,收集告警,可以发现有多个模块上存在faultininternalbus的告警,additionalinfo为lossofclock。
说明在这个分架上多个模块都未能拾取到本架的时钟消息*。
⏹由于此时第三分架和第四分架之间总线已经断开,这些模块无法获得从上面下来的第一路总线上的时钟消息,但是应该拾取从本架的最右侧模块(TEI74)产生的时钟消息。
同时,在TC-TE上一直无法获得TEI74的板子信息,用PC直接连到此模块上也无法成功建立连接。
subrack1/2/3:
通过debug线连接到第一、二、三分架的多个模块上,收集trace,均未发现有异常消息。
subrack4:
通过debug线连接到第四分架的多个模块上,收集trace,发现有很多有关TCILB的警告(warning),说明在这个分架总线上存在着错误消息,应该是由某一个模块产生的.
根据上述TC-TE和debugtrace分析,可以确认是由于第四分架上的某一模块存在故障。
同时根据现象基本确定为TEI74存在故障。
OMC-R的历史告警:
根据历史告警可以看到,在与故障发生的相应的时间内,部分mt120模块存在INT_BUS_FLT_G25的告警,和TC-TE上第四分架上的模块告警是一样的。
结论:
TEI74模块由于自身的原因产生了很多错误消息,发到了总线上,导致总线消息的混乱,引起多个其他模块的重起。
⏹更换TEI74;由TAC工程师带回故障模块,在ASB机房进行模拟测试,以找出最终原因。
⏹第一分架的最左一个槽位和第四分架的最右一个槽位上插上空的MT120模块,以确保A925TC架出现类似问题时的内部总线时钟消息的正确性,从而提高总线的稳定。
⏹定期检查MT120的模块告警的状态。
⏹按照正确MT120扩容流程来做,保证OMC显示和TC上的实际硬件一致,以保证告警信息的正确解读。
BSC出现数据吊死处理方法
故障现象:
未删除完相邻关系,在做DELBTS的时候,因数据量过大,造成26个小区数据吊死,BSC在不停的做BSCDISCOVER操作中的AUDITALARM,BSC始终处于忙时,对BSC所有的操作都不能执行。
故障分析:
1、BSC上有异常告警;
2、因数据过多或进程冲突,容易引起OMC-R上的数据与BSC的数据不同步;
3、OMC-R上数据有损坏
⏹在OMC-R上stop该BSC的进程,再start进程,做完这步观察是否还出现上述的故障,如有进行第2步;
⏹在BSC上检查有没有异常告警,;
⏹用BSCTermiral查看删除的小区,在BSC上是否删除;
⏹如果BSC上无异常告警,所要删除的BTS都已经删除,则说明BSC没什么问题,就是OMC-R上数据的问题,解决方法有删创BSC、
⏹删创完BSC后,故障解决。
⏹如果删创不了BSC,则可以考虑联系OMC-R工程师,删创OMC-R上的RNIM数据库;
⏹上述方法如果未解决,可以重装OMC-R。
⏹如是现网的BSC,不能用REMOVE,而要用Forceremove命令;
⏹在删除BSC之前,要保留现有的参数(参考文档),一般是网优的参数和基站名,这些都是在OMC-R上保存的;
⏹在DeclareBSS时,记录下原BSC的参数(名称、host、TSAP、SSAP、NSAP等),还要关闭startbssauditafterdeclaration选项;
⏹BSS删创结束后,可以打开PeerEntities-Modify选项,修改参数提高X.25的传送效率;
⏹接下
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- BTS 常见问题 处理