GSM硬件故障排查MOTO分册.docx

上传人:b****6 文档编号:6998184 上传时间:2023-01-15 格式:DOCX 页数:29 大小:1.69MB
下载 相关 举报
GSM硬件故障排查MOTO分册.docx_第1页
第1页 / 共29页
GSM硬件故障排查MOTO分册.docx_第2页
第2页 / 共29页
GSM硬件故障排查MOTO分册.docx_第3页
第3页 / 共29页
GSM硬件故障排查MOTO分册.docx_第4页
第4页 / 共29页
GSM硬件故障排查MOTO分册.docx_第5页
第5页 / 共29页
点击查看更多>>
下载资源
资源描述

GSM硬件故障排查MOTO分册.docx

《GSM硬件故障排查MOTO分册.docx》由会员分享,可在线阅读,更多相关《GSM硬件故障排查MOTO分册.docx(29页珍藏版)》请在冰豆网上搜索。

GSM硬件故障排查MOTO分册.docx

GSM硬件故障排查MOTO分册

MOTO硬件故障分析排查

 

目录

第1章概述3

第2章BSS告警分析处理3

2.1告警分类3

2.1.1按告警类型分类3

2.2.2按告警严重程度分类4

2.2.3按告警网元分类5

2.2查看告警信息6

2.2.1用事件窗口查看事件日志记录6

2.2.2OMCR告警及事件信息识别9

2.2.3在事件日志窗口中过滤相关事件11

2.2.4相关事件/告警的显示12

2.2.5用行命令cel查看事件日志文件14

2.2.6用qfes进行相关事件的过滤15

2.3常见告警处理16

2.3.1设备常见告警处理16

2.3.2内部告警处理21

2.3.3外部告警处理21

2.3.4常见告警代码及告警信息21

第3章隐性告警排查处理23

3.1发现隐性故障的的方法23

3.1.1话务统计23

3.1.2路测29

3.1.3历史告警记录30

3.1.4用户投诉31

第1章概述

在无线网络的日常优化维护中,硬件设备是我们关注的最基本部分,因此对于硬件告警和设备故障是否能及时发现和处理,不仅关系到系统运行的稳定,而且也关系到系统性能的好坏与是否能提供各种业务服务。

及时处理告警故障设备也能解决其他优化方式无法发现的网络问题,对整个网络的优化,提高全网系统性能都有很帮助。

对于硬件的各种故障按照不同的呈现方式可以分为显现故障和隐形故障两大类。

第2章BSS告警分析处理

在日常维护优化中碰到的告警事件,有些事系统运行,操作维护中产生的,例如新加网元、客户巡检、更换设备等都会产生告警;有时告警是瞬时性的,如传输闪断;有些告警对网络系统影响不大。

如部分EAS外部告警、IAS内部告警;而有些告警虽然出现的次数较少,但是往往一出现就给系统带来严重的后果,如果严重将导致系统重启,如GPROC、BSP、KSW等的一些告警,因此在日常优化过程中对这严重的告警要实时监控,对这些告警尽早发现、分析、定位、解决,让网络保持良好的运行。

2.1告警分类

硬件故障按照起告警类型、告警的严重程度以及网元可以进行不同层面的分类。

通过分类以便针对不同的告警类型制定不同的处置策略。

2.1.1按告警类型分类

BSS告警就是可以通过OMS-R终端查看的告警。

BSS告警可分为故障告警和事件告警两类。

∙故障告警

设备出现故障和异常后向网管设备上报的告警(如单板故障)。

通过采取相应的处理措施,可以使产生此类告警的故障和异常恢复。

∙事件告警

设备运行时的偶然性事件告警,是设备运行时的一个瞬间状态,只表明系统在某一时刻发生了某一预定义的特定事件(如通路拥塞),不一定代表故障状态。

一些事件告警是定时重发的,比如资源核查类事件告警,因为会定时核查,发现资源还是不满足的话,就会重发告警。

事件告警只起知会作用,无需处理。

2.2.2按告警严重程度分类

告警级别用于标识一条告警对业务的影响的严重程度。

BSC告警按严重程度递减分为四级:

紧急告警、重要告警、次要告警和提示告警。

如下表所示:

告警级别的定义及处理方法

告警级别

定义

处理方法

紧急告警

此类级别的告警影响到系统提供的服务,必须立即进行处理。

即使该告警在非工作时间内发生,也需立即采取措施。

如某设备或资源完全不可用,需对其进行恢复。

需要紧急处理,否则系统有瘫痪危险。

重要告警

此类级别的告警影响到服务质量,需要在工作时间内处理,否则会影响重要功能的实现。

如某设备或资源服务质量下降,需对其进行恢复。

需要及时处理,否则会影响重要功能的实现。

次要告警

此类级别的告警未影响到服务质量,但为了避免更严重的故障,需要在适当时候进行处理或进一步观察。

发送此类告警的目的是提醒维护人员及时查找告警原因,消除故障隐患。

提示告警

此类级别的告警指示可能有潜在的错误影响到提供的服务,此类告警无需处理。

只是对系统的运行状态的报告。

 

2.2.3按告警网元分类

不同的告警属于不同的网管类型。

按照各种告警的网元类型可以将告警分为以下几类,如下表所示:

网管分类说明

网管分类

相关告警

电源系统

有关电源系统的告警。

环境系统

有关机房环境(温度、湿度、门禁等)的告警。

信令系统

有关随路信令和共路信令的告警。

中继系统

有关中继电路及中继板的告警。

硬件系统

有关单板设备的告警(如时钟、CPU等)。

软件系统

有关软件方面的告警。

运行系统

系统运行时产生的告警。

通信系统

有关通信系统的告警(如前后台通信)。

业务质量

有关服务质量的告警。

处理出错

其它异常情况的告警。

2.2查看告警信息

OMCR上提供了无线网络和OMCR系统本身的事件/告警日志记录和管理功能,使运维人员能及时方便的了解系统在运行过程中所发生的故障和事件。

事件/告警管理窗口在OMCR的图形用户界面上的位置如下图所示

2.2.1用事件窗口查看事件日志记录

1、用鼠标左键点击图形用户界面上的事件日志窗口,弹出下图所示事件日志查询窗口。

如下图:

2、如下图所示,在事件日志记录窗口中点击菜单Options->LoadEventLog选项,选择装载事件日志文件。

如下图:

3、在弹出的文件选择窗口上选择想打开的日志记录文件的路径/usr/gsm/ne_data/ev_logs/和相应的文件名,将其变黑,点击OK按键,打开日志文件。

备注:

事件日志记录文件名的形式为“enyyyymmddhhmmss”,其中时间戳为时间日志文件生成时间。

摩托罗拉OMCR一个事件日志文件只能记录5000个事件记录,超过5000个记录时系统会自动生成下一个日志记录文件。

4、打开事件记录窗口如下所示,可以在事件记录窗口中对事件进行事件分类、排序、相关告警事件及过滤等预处理。

2.2.2OMCR告警及事件信息识别

OMCR上事件/告警的格式

第1行:

ØOMCidnumber:

事件标识号

ØAlarmState:

告警状态

ØOperater:

事件操作者

第2行:

ØAlarmtype:

告警类型

ØDevicetype:

设备类型

ØDeviceid:

设备id号

ØDate:

日期

ØTime:

时间

第3-5行:

ØErrorid:

告警出错id号

ØAlarmmessage:

出错告警消息

ØAlarmclearingtype:

告警清除类型

ØSeverity:

告警严重级别

Ø5.AdditionalInfo:

其他消息

事件的可分类型

在事件记录窗口中点击Sort菜单,可看到Sort的下拉菜单如下图所示:

由分类排序菜单可以看到事件可按下列类型分类排序:

Øid:

事件id号

Østate:

事件操作状态

Øoperator:

事件操作者

Øcomment:

事件注释

Øtype:

事件类型

Øclass:

告警的设备类型

Øinstance:

具体的告警设备

Ødate/time:

告警的日期和时间

Øalarmtype:

具体的告警类型说明

Øseverity:

告警的级别

Øascend:

由低到高的升序排列

Ødesecend:

由高到低的降序排列

2.2.3在事件日志窗口中过滤相关事件

在打开的事件日志窗口里点击菜单Option->Filter弹出DefineFilterCriteria窗口,在该窗口里定义想过滤的事件特性,点击OK。

2.2.4相关事件/告警的显示

1、在事件记录窗口中用鼠标左键点击一事件,使其颜色变红。

选中的事件日志如下图:

2、点击事件窗口菜单LogsSearch->AssociatedAlarms选项,弹出下图所示的相关告警事件窗口。

2.2.5用行命令cel查看事件日志文件

1.在omc_splat上点击用户图形界的xterm图标或用鼠标右键点击CDE桌面选择NewWindows打开xterm窗口。

2.改变系统的当前路径到/usr/gsm/ne_data/ev_logs/目录下

cd/usr/gsm/ne_data/ev_logs

3.在/usr/gsm/ne_data/ev_logs目录下用ls行命令找到需打开的事件日志文件。

4.用cel命令即可打开相应的事件日志文件。

celev20000201000005

2.2.6用qfes进行相关事件的过滤

格式:

celevqfes“eventtype”“devicetype”“deviceinstance”“startTime”“endTime”[“infostring”]

例:

查看2000年1月21日BSS02上发生的critical告警

somcsys1:

omcadmin>celev20000121*|qfes"""""BSS02""""""Critical"|more

#0-NOTAPPL-*NONE*.

communicationFailureEvent-MTL-BSS02(BSS02:

SITE-0:

):

0MTL0-21/01/

200000:

05:

47.

[0]SignallingLinkFailure-FMIC-Critical-/-.

ConfigTag801232

00000000FFFF.

#1-NOTAPPL-*NONE*.

communicationFailureEvent-MTL-BSS02(BSS02:

SITE-0:

):

0MTL0-21/01/

200000:

05:

54.

[0]SignallingLinkFailure-FMIC-Critical-/-.

Fault-Enable-MTL0-ReconfigPending-ConfigTag801232

Atthetimeofthealarmthesubscriberimpactwas:

SITE0:

Pending

00000000FFFF.

2.3常见告警处理

常见告警故障处理及分析MOTOROLA基站的告警按故障设备可分为三类:

设备告警、内部告警、外部告警。

以下就对这三类告警中的常见多发告警进行分析处理。

2.3.1设备常见告警处理

设备告警是硬件告警最常见也是最重要的告警,告警设备一般为基站的主要器件,它的告警类型就是它的设备类型。

1. DRI29:

[FrontEndProcessorFailure -WatchdogTimerExpired]前端处理器故障

DRI硬件故障,出现此告警时DRI可能会反复自启,可能会退服,应先resetorinsDRI应进行INS或RESET处理,若告警未消失,更换TCU。

2.DRI40-47:

[ChannelCoderTimeslot0(-7)Failure]0-7时隙信道编码器失败。

M-CELL基站经常出现此类告警,应进行INS或RESET处理,不行再更换TCU900。

3.DRI51:

[BasebandHoppingTDMLink Error]基带跳频TDM链路错误。

此告警有几种可能性:

TDM-HighwayBUS或KSW可能有问题。

DRIM的FEP,CCDSP可能有问题。

此告警须在现场具体测试分析。

测试后判定故障点。

4. DRI81:

[TransmitterSynthesizerFailure]收发单元故障

此告警为收发单元TCU故障,故障原因有可能为:

●接收Calibration频点丢失

●信道盘的CEB故障

●射频电缆连接失败

处理方法:

远程ins或resetTCU,告警消失并监测;若告警未消失,更换TCU

5.DRI86:

[TransmitterFailure]输出功率失败,引起DRI退出服务。

状态:

D-U。

此告警是信道盘的功率放大器失败。

应更换信道盘。

6.DRI91:

[PowerAmplifierPowerLowButFunctioning]信道盘的功率放大器输出功率低于门限,状态B-U。

此告警有可能由于高温等原因引发,有些站经常性出现DRI[91]的盘则需要更换,以免因小区功率不平造成掉话。

有时侯在现场看不见此告警,须从OMC的事件窗口检查。

7.DRI92:

[PowerAmplifierTemperatureHighButFunncioning]信道盘的功率放大器高温告警,但可以工作。

信道盘的功率放大器的高温多数是因机房高温,或机箱内的风扇故障造成的。

在出现此告警后,信道盘的性能会下降。

如温度过高,信道盘会自动闭塞。

因此常出现此告警的信道盘应于以更换8.DRI112(114)[ReceiverSynthesizerFailure]接收单元合成器故障

此告警为收发单元内部故障,其主要原因大概有:

●收发信单元内部直流供电故障

●收发信单元内部硬件故障

处理方法:

远程ins或resetTCU,告警消失并监测;若告警未消失,更换TCU

9.DRI150:

[ReceiveMatrixBranch1controlLinkFailure]接收矩阵支路控制失败,状态:

B-U

此告警M-CELL和Horizon中均有出现,伴随切换掉话,切换成功率低,呼叫建立成功率低导致的话务量减少。

有时也会导致信道盘的path_balance值偏高。

其主要原因有:

●有故障的接收矩阵即SURF;

●收发信单元与接收矩阵之间的同轴电缆断路;

●收发信单元与接收矩阵之间的同轴电缆短路;

●信道盘中的均衡器板控制电路出现故障;

●SURF内部前-后端接口短路;

●SURF内部前-后端接口断路

处理方法:

根据现场判断具体情况更换硬件。

10.DRI152:

[ControlProcessortoPowerAmplifierCommunicationFailure]处理器与功率放大器的通信失败

此告警是信道盘中的CEB及对PA的控制失败。

首先对信道盘进行INS或RESET处理,不行再更换信道盘。

11.DRI 209:

[TimeslotConfigurationFailure]信道分配失败 D-U

小区资源管理器CRM为MS分配无线信道时在射频硬件上分配时隙失败。

产生的原因有:

●收发信单元TCU故障;

●DRI软件故障;

处理方法:

远程ins或resetTCU,告警消失并监测;若告警未消失,更换TCU

12.DRI218:

[TimeslotConfigurationFailure]不健全的信道接收校验数值

此告警的出现时用指令:

disp_cal_data 

看到基站接收数据校准值中出现80(错误的校准数据),还找到根本的原因,远程对硬件reset或ins均无作用,现场人员有时需更换新硬件设备而有时只需对信道盘开关电即可恢复,初步判断为硬件TCU(Horizon目前还未发现)接收单元问题。

13.DRI234:

[ActiveLinkConnection Failure]主用链路与BTP的链接失败。

状态:

D-U

此告警主要发生在M-CELL上,是主用BTP到DRI/TCU900的链接失败。

其原因主要分为:

●FOX/FMUX/BTP之间的连接和使用的光纤类型的问题。

●TCU900/FOX/FMUX/BTP本身的问题。

●还有则是由于某种原因,使处理机运行过程出现问题,使其与TCU900失去联系。

处理方法:

这类情况可用LOCK-UNLOCK恢复。

14.DRI235:

[StandbyLinkConnection Failure]备用链路与BTP的链接失败。

对网络不造成影响。

但如果出现整个机柜告警应当引起重视。

以免基站主用出现故障倒换到备边时,出现整个机柜不能工作。

此告警只出现在M-CELL,是备用BTP到DRI/TCU900的链接失败。

其原因主要分为:

●FOX/FMUX/BTP之间的连接和使用的光纤类型的问题。

●TCU900/FOX/FMUX/BTP本身的问题

●有时侯如有大部分DRI出现此告警,有可能是没将BTP做成冗余形式。

DRI239:

[ProcessSafeTestAudit Failure]有可能是因为机房内高温造成,若不及时进行处理,会继续出现92#告警。

15.DRI243:

[UnlockedDeviceNotInService]信道盘退服,状态:

D-U

此告警出现在没有主告警的情况下信道盘退服可能的原因是:

系统错误导致的信道盘退服。

处理方法:

发现告警后,RESETTHEDRI观察,如果告警仍然存在这更换信道盘。

1

16. GCLK2:

[ClockReferenceFailure]时钟参考失败

此告警为基站MSI板的时钟提取丢失其主要原因有:

●E1/T1链路故障

●没有MSI/NIU的时钟信号

●没有XCDR的时钟信号

●GCLK时钟提取电路失败

处理方法:

更换MCU或NIU,若仍然出现告警则需通过传输处理

17.GCLK4:

[PhaseLockLost]时钟参考信号锁相丢失

此告警有时会引起切换掉话或切换成功率低,有时没有影响,大多数是因为传输大网与移动网对时钟要求相距较大引起。

其主要原因有:

●大多数情况是在E1/T1链路上偏移或不稳定的时钟超过所允许的极限而引起的时钟失锁。

●不正确的时钟源或GCLK硬件故障

●GCLK晶体振荡器由于老化不能长时间对信号源进行锁相

处理方法:

一般情况下先进行时钟重新校准或SWAPBTP到备边,若无作用则请传输中心处理。

18.GCLK[8]:

主备时钟频差过大。

此告警是由BTS的本振时钟主备频率偏差过大,应及时对时钟进行校准。

M-CELL:

 8000HZ.

19.GCLK14:

[PhaseLockFailure]时钟参考信号锁相失败

此告警有大多数时间会引起切换掉话或切换成功率低,其主要原因有:

●GCLK硬件故障

●有问题的前时钟源

●规范问题

20.GCLK18:

[NotOperational]主时钟不工作

此告警是由于基站主控板MCU不能建立正常的同步时钟初始化。

出现的原因:

可能是由于固件故障,或是硬件老化。

出现此问题时应resetMCU,若告警未消失则需更换MCU;若告警消失,则不需在作进一步的观察。

21.GCLK24[BadClockSourceorOCXO(oscillator)]:

不精准的时钟源或有故障的时钟振荡器。

出现此告警时先resetsite或主控倒到备边,若还存在告警则需传输帮助解决。

22.GCLK26:

[GCLKCalibrationRequest]GCLK校准失败

此告警有大多数时间会引起切换掉话或切换成功率低其主要原因有:

●GCLK校准超出要求范围(即不能进行校准)

●有问题的GCLK时钟源或时钟源超出传输要求规范

●在MCU第一次加电时不能进行校准,因此不能计算LTA值

●GCLK长时间不能进行锁相,超出允许时间

●GCLK硬件故障

处理方法:

更换MCU

23.BTP[39]:

软件故障

此告警出现时会引起BTPD-U CodeLoadFailure或反复codeload,其主要原因有:

●下载的软件故障

●主控GPROC故障

处理方法:

●进emonresetsite,并观察

●更换MCU(或SWAPBTP)

2.3.2内部告警处理

内部告警的告警设备一般为基站的辅助设备如风扇、保险、开关、电源模块等。

1.IAS86#[cabinetfanfailure]:

基站风扇故障

2.IAS[81]:

PSU供电单元输出失败。

通过计算机检测电源模块,判定故障及时更换。

3.IAS[95]:

低噪音放大器保险坏。

M-CELL对于G**900的选件中没有采用低噪音放大器。

所以此告警对DCS1800基站有影响。

解决措施为:

更换对应的保险。

对于内部告警,除一般的高温和风扇告警,其他一些内部告警一般为假告警,不与处理。

2.3.3外部告警处理

外部告警一般为假告警,一般不作处理。

2.3.4常见告警代码及告警信息

常见告警代码及告警信息如下表:

类型

序号

设备

告警号

告警内容

描述

级别

B

S

C

1

GCLK

232

GCLK:

ProcessorBusCommunicationFailure

GCLK退服

2

GPROC

35

GPROC:

LANConnectionFailure

GPROC退服

3

KSW

232

KSW:

ProcessorBusCommunicationFailure

KSW退服

4

KSW

225

KSW:

InternalLoopbackAuditFailure

KSW自检失败

5

KSW

224

KSW:

SafeTestAuditFailure

KSW自检失败

6

LAN

1

LAN:

LANFailure

LAN退服

7

MTL

0

MTL:

SignallingLinkFailure

MTL退服

8

PCU

0

PCU:

LastGSLFailed

PCU退服

9

BSS

27

BSS:

LastGBLFailed

所有GBL退服

10

BSS

21

BSS:

TrunkMajorThresholdExceeded

过多的CIC退服,通常由于A口中断

11

XBL

10

XBL:

LinkDisconnected

XBL退服

B

T

S

1

Site

0

0.SITE:

LastRSLLinkFailure

对应基站退服。

2

Site

21

21.SITE:

NoClockReferencesAvailable

基站不能获取时钟。

3

CELL

1

1.CELL:

CellRadioTimeslotCapacityLoss

无线信道资源减少:

通常由Path中断造成。

4

CELL

8

8.CELL:

GPRSunavailable-NoPRPavailable

PRP容量不足/退服造成GPRS不可用

5

CELL

9

9.GPRSunavailable-NoGDSavailable

GDS时隙不足/退服造成GPRS不可用

6

DR

展开阅读全文
相关资源
猜你喜欢
相关搜索

当前位置:首页 > 工程科技 > 信息与通信

copyright@ 2008-2022 冰豆网网站版权所有

经营许可证编号:鄂ICP备2022015515号-1