基带跳频与射频跳频分析

更新时间：2023-08-14 13:34:01 阅读量：人文社科文档下载

说明：文章内容仅供预览，部分内容可能不全。下载后的文档，内容与下面显示的完全一致。下载之前请确认下面内容是否您想要的，是否完整无缺。

基带跳频与射频跳频分析

GSM常见问题的处理思路目录

GSM常见问题处理思路.....................................................2第一部分 MSC常见问题处理................................................3

1.1 业务类问题处理....................................................3

1.1.1 总体思路...................................................3

..............................................4

1.2 通话类问题处理....................................................5

1.1.2 具体案例分析

1.2.1 单通问题的处理.............................................5

第二部分 HLR常见问题处理................................................8

2.1 前置机数据类问题

..................................................8

2.1.1 前转类问题..................................................82.1.2 用户上网类问题..............................................92.2 HDB的问题处理....................................................9

2.2.1 配置文件错误引起的问题......................................92.2.2 HDB硬件问题的处理..........................................102.3 HLR SERVER的问题处理第三部分 OMC常见问题处理

3.1 OMC的程序结构

...........................................17

.............................................18..................................................18

181920222223

.............................................

3.1.2 OMC日志分析...............................................3.1.3 OMC服务器的常见的出错信息...................................3.1.4 OMC服务器的各进程的启动方式.................................3.1.5 OMC服务器的常用命令........................................3.2 常见案例分析.....................................................

3.1.1 OMC的正常进程

基带跳频与射频跳频分析

GSM常见问题处理思路

概要说明

本文主要讲述华为GSM系统NSS部分的常见问题的处理思路由于GSM系统比

较庞大涉及的技术也比较复杂因此问题的定位和处理也相应比较复杂全文分为三个部分

第一部分处理思路

MSC部分常见问题的处理

包括业务问题

通话话音问题的定位和

第二部

分HLR部分常见问题的处理SERVER的常见问题的定位和处理第三部分OMC SERVER常见问题的处理Keywords

包括HLR前置机HDB和HLR

GSM 常见问题处理思路 MSC常见问题 HLR常见问题 OMC SERVER常见问题

基带跳频与射频跳频分析

第一部分 MSC MSC常见问题处理

MSC的常见问题有业务类的问题

通话类的问题和硬件故障类的问题

要点

掌握业务类问题的处理思路掌握通话类问题的处理思路

1.1 业务类问题处理

1.1.1 总体思路

MSC常见问题主要和业务有关的问题的处理的总体思路是关数据

消息的跟踪的手段主要有以下几种

1234

用户接口跟踪接口跟踪链路跟踪

使用信令分析仪表跟踪消息

比如呼叫

漫游

切换

补充业务等

MSC的>检查相

问题处理的关键在于熟悉各种业务的流程和各接口的NO.7信令

分析现象

对于业务方面

>跟踪消息并定位问题

在实际应用中可以根据需要进行选择用户接口跟踪

用户接口跟踪适用于问题比较典型

可以通过某个用户的表现进行定位

而且

被跟踪的用户已经在我方的VLR

中登记接口跟踪

对某个接口比如A接口的跟踪主要用在开局割接前的调测中系统上某个接口的消息都特别多难以定位链路跟踪

因为在网运行的

基带跳频与射频跳频分析

链路跟踪问题

包括从维护台跟踪和适用仪表跟踪的优点在于信息全便于查找有时需要

但是缺点在于对于一些链路很多的局向很难进行全面的跟踪

人工闭塞一些LINK才能跟踪到比较完整的消息消息

直接存盘下来是文本文件的格式

对于从维护台跟踪下来的信令

难度比较大

可以使

如果直接分析

用工具将其转换为MA10的格式了不但有详细的消息解释同一个业务的过程进行跟踪

使用MA10软件进行分析这样就非常方便

还能对

而且还可以根据关键字对消息进行查找

这种方法特别适用于不能对单用户进行跟踪或者

从大量的消息中分检单个呼叫或者其他业务的情况1.1.2 具体案例分析

要点

熟悉各种业务流程熟练进行各种跟踪消息分析

数据管理中每长表格以及表格内每个字段的意义和相互关系

案例1 由于其没有配置该基站的小区号数据或配置有误造成基站服务区内

用户只能做主叫现象

Q基站开通后

其服务区内的用户只能做主叫

处理过程1

对MSC侧的数据配置进行检查

发现

BSC表

中有关该基站所在BSC的目

不知把该命令下发给哪

的信令点的数据与位置区小区表对应个BSC23

中该基站所在BSC的目的信令点的数据不

就是该错误造成了MSC在下发系统消息命令时从而导致该基站接收不到所要下发的寻呼消息

BSC

表

位置区小区表该基站能正常开工

对MSC侧的进行数据修改使该基站所在

BSC的目的信令点数据配置一致MSC数据设定以后

对该基站服务区内的用户进行主

被叫拨打测试原因分析

Q基站与N基站S5/5/5成树型连接对该基站进行数据加载后常开工

当锁定BCCH频点进行拨打测试时

该基站能正

各种呼叫都正常

发现手机用户在该服务区内只能

基带跳频与射频跳频分析

做主叫不能做被叫对ABIS接口进行信令跟踪后发现该基站BCCH没有向其

由此可判断出问题的

服务区内的用户下发寻呼消息原因可能是

PAGING MESSAGE

MSC侧在下发系统消息命令时由于其没有配置该基站所在

从

BSC的目的信令点数据或配置有误致使该基站接收不到下发的寻呼消息

而造成其服务区内的用户不能作被叫

案例2 由于BSC表配置问题引起的寻呼不能成功

故障现象

某局调测时发现有大量用户在正常状态时做被叫提示的提示音故障分析

在用户接口跟踪时发现漫游号码能正常取到消息

但是没有寻呼响应链路跟踪中不能看到寻呼消息链路中

仔细检查消息

而且MSC已经向BSC下发了寻呼

在相应的

暂时无法接通

在MSC拆线的消息中提示目的地不可达

这样故障可以定位在MSC没有将寻呼消息发到

寻呼消息都是从MSC的某一个检查MSC数据管理台中的

发现不成功的呼叫中

模块发出的BSC表

而MSC的这个模块到BSC没有链路

发现在该表中配置的所属MSC模块中配置了这个模块

问题解决

处理过程

将BSC表中的该所属模块删除后建议与总结

在BSC表中配置的所属MSC模块必须是有到BSC的链路的模块有对应BSC的链路

那么就会出现以上msc找不到bsc的情况

如果该模块没

1.2 通话类问题处理

通话类的问题主要有以下两种1.2.1 单通问题的处理

单通问题可能存在于话路的从用户端到无线接口各个设备中需要根据实际情况来定位信号不平衡

TRX故障等原因

A接口

TUP等各个环节和

鸳鸯线

CIC数

在无线侧可能是由于无线信号上下行

单通和杂音

在网络侧可能和HW连线错误

据错误网板或者DTM单板

故障有关

对于单通问题的定位使用可以监听时隙的2M误码仪进行监听定位在特定的系统上查找单通的原因了

而且可以看出单通是只有来话还是去话

不但可以将单通这样非常容易

基带跳频与射频跳频分析

案例3 在增加话路中继时

出现单通现象

现象描述

在增加A局到B局的话路中继后处理过程12析

拨测时发

现有单通现象

当发现有单通现象时闭塞大部分的原有中继

进行拨测测试确认单通现象不是偶然现象而是由于

新增的话路中继造成的

并针对网板的新增中继对应的时隙占用情况进行分

基本确认是否为新

发现当占上新增中继的其中两条时总会出现单通现象

增的中继存在问题34

闭塞一条有问题的中继

对另一条进行测试

仍然有单通现象

正常

再查看

也未

首先再次检查这两条中继对应的DTM板的指示灯状态

也很正常

NO.7电路的状态空闲发现异常5 开6

插拔中继端口

进一步核查数据和HW的连接情况

发现在断开有问题的一条中继时

未发现异常

另一条中继也随之断

说明两条中继线之间存在内在的关系再次查看中继线的收发连接情况

与B局联系对两对中继线

分别测试所示7常

发现B局那一边将两对中继线的一条相互错位即连接情况如附图

大部分工程师在调测中继时只关心DTM板的指示灯状态

实际上象上图的连接方式

如果状态正常

E1-1的左边

便认为硬件连接没有问题指示灯状态也完全正

这可能由于DTM板的RX与TX之间存在虚电路的连接例如

一路的RXTX实际是通过其他三块中继板形成一种自环灯状态正常的8

如果左边一侧的局发起呼叫

占上E1-1的中继

从而使DTM板指示

并在IAI消息中让对端局也

导

占用相同中继的相同时隙(即相同CIC的电路致对端把来话接到另一条中继上原因分析

但由于硬件的连接的错误

从而形成单通现象

单通现象是指通话的双方一方可以听到对方的声音音12

单通现象的产生可能由以下原因造成硬件问题如上例

包括HW线的某条断

开

而对方听不到自己的声

HW数据配置问题中继的连接错误

中继电路的配置与物理连接不匹配等

由于手机本身问题或基站侧的无线原因导致单通

基带跳频与射频跳频分析

3生12继

在拨打长途时建议以下几点

偶尔也会出现单通现象可能与长途传输有关

为了减少单通现象的产

从以上原因看与我们网络侧有关的主要是第一点

在铺设中继线时一定要将中继线贴好标签在调测的过程中

测试一定要细心

包括线序和收发端尽量减少中

继线连接错误的可能性

在话务小的情况下

可闭塞部分原有中

增加占用新增中继的概率同时观察网板的时隙占用情况和在用户跟踪中

观察出局所占的电路号3事4

如果出现单通现象

确保每一条中继都被占用过应仔细分析产生的原因

是否存在规律等

不要盲目行

这样更

在象开局时条件具备的情况下可对中继线一对一对进行拨打测试

容易发现有问题的中继

基带跳频与射频跳频分析

第二部分 HLR HLR常见问题处理

HLR由HLR前置机和HDB

组成成!

要点

熟悉HLR的系统工作原理

掌握HLR部分的故障的分析定位和处理

HLR对应的问题也可能是由前置机或者HDB对应的部分组

2.1 前置机数据类问题

HLR前置机的数据比较简单分析表IMSI区号对应表新被叫分析表

除了硬件配置外GT转换表等表格

对系统影响比较大的表有被叫GT转换表影响用户的位置更

禁止前转号码表影响用户呼叫转移的前转号码的合法性

登记前转时不能成功

对于前置机数据

IMSI

区号对应表如果没有包括的号段类的问题主要有下面几个方面2.1.1 前转类问题

对于用户前转不能成功的问题IMSI

区号对应表等表格案例4

联通MS无法前转移动号段

主要检查被叫分析表禁止前转号码表

故障现象

联通MS设定前转移动号段后市话和本网手机原因分析

在MS上设定前转移动的号段后码

在HLR用户数据管理台上查询所设定的前转号

由于多插入了本

做被叫时提示您拨的用户不存在

但是可以前转

发现所设定的前转号码已变为008621139xxxxxxxx的形式

地的区号(21)所以导致前转失败MS设

定前转时止前转号码表等表时缀

分析送上来的前转号码

HLR根据被叫分析表和禁

135-139

所以前转移动号段

将匹配至呼叫字冠为1的纪录查看被叫分析表

认为是本地号码所以加上了008621的前

而130的业务属性

发现被叫字冠为1的业务属性为本地

为移动网本地局

基带跳频与射频跳频分析

处理过程在被叫分析表中动属性

设定之后

加上呼叫字冠为13的纪录前转都正常

业务属性为移动网他局或其他移

2.1.2 用户上网类问题

在HLR数据中与用户上网有关的主要就是GT转换表的配置其中包括了用户的E.164和E.214编码E.214的编码即可

在HLR的数据配置中

只需要配置本HLR中用户对应的

其余的E.214的编码不用配置

2.2 HDB的问题处理

HDB使用的操作系统为UNIX数据库采用ORACLE对HDB的维护需要了解UNIX和ORACLE 的相关知识

另外对于HDB中各目录和文件的配置以及我们

的HLR常用的表格的结构必须了解

2.2.1 配置文件错误引起的问题

hdb中最常见产生问题的配置文件就是hlr.sh文件案例5户

HDB中SERVER IP地址设置不当导致在HLR用户数据管理台中不能开销户等操作

故障现象某局在调测时在进行开户原因分析

在HDB中hlr.sh文件中的OMC SERVER IP地址应该为HLRSERVER的IP地址不能是OMC SERVER的IP地址该地址如果不正确SERVER不能正常连接处理过程

检查HDB和OMC系统连接的网线连接

连接正常

排除了网络连接的问题

这说明HDB和HLR就HDB与HLR

发现登录HLR 用户数据管理台正常销户等操作时

不能成功

提示错误

能添加

删除资源

但是

然后在HLR SERVER中查看HLRCOM的进程只有一个SERVER连接有问题为129.9.200.20的该地址改正后# hareg n hlr#hareg y hlr重启后问题解决

在HDB中检查hlr.sh 文件OMC SERVER IP项地址设置

将双机中

但是实际上的HLR SERVER的IP地址为 129.9.78.2并通过以下步骤将HDB中的HLR重启

基带跳频与射频跳频分析

GSM常见问题的处理思路

2.2.2 HDB硬件问题的处理

HDB硬件配置比较复杂

2.2.2.2.2.2.1 终端连接器问题

主要包括终端连接器主机磁盘组网络连接等

确认问题

确认无硬件连接问题电源问题

问题表现

连接口忙连接无响应

故障恢复

连接口忙

关闭其它连接口再试不成功不成功不成功

关终端连接器并重启再试按安装手册对其重配置再试要求SUN公司设备维护或更换

连接无响应

要求终端连接器设备维护或更换

2.22.2.2.2 2 启动问题

确认问题

确认没有安装问题电源问题

问题表现

Telnet 到终端连接器

上UNIXUNIX启动正常

如果主备机显示ok表示没有正常启动

表示

如果双机都有hwhlr-ph1> 或hwhlr-ph2>提示

符

基带跳频与射频跳频分析

Telnet 到逻辑主机129.9.101.193上如果可以连接表示HA启动连接不通表示双机HA失效或没有

启动

问题恢复

HA没有正常启动

ping 129.9.101.193 发现 time out. 提示ping 其它物理主机如上操作表示正

常

使用检测工具检查

应该发现HA

软件没有运行

且大部

份检测项报错或报超

时此时Telnet

到一二号主机

手工启动

参考启动HA一

节

建议

使用/etc/rc3.d/S99startcluster start来

启动端监视器上的

输出常结束

后

如果不能

启动

并观察启动过程中终端和终

正若

则使用scadmin方法来

启动

应用可以恢复使用检测程序可以看到测试项都为ok

仍有测试项不通过重新定位问题

表示

使用S99startcluster程序启动不成功而scadmin启动成

功S99startcluster程序问题

要求公司重新检查程序并发送改正后的程序

双机或单机ping不通

如果显示

ok起动

本机

表示此机进入ok

状态UNIX正常

启动

UNIX没有应用启

进入在终端监视

器正常

启动动正常结

束

输入

boot

启动

系统恢

复使用检测程序可以看到

HA应用都为

若仍有测试项不通过重新定位问题

进入终端监视器查看如果本机没有显示输出或长期挂起没有运行表示主机进程发生

故障恢

复

强制本机退回到ok

状态后

按以上步骤进行

基带跳频与射频跳频分析

操作方法在终端监视器上按<Ctrl> + ] 后输入send brk;退回到ok状态输入boot启动hwhlr-ph1>lsDeftemp.txt abc.txtDump ... Error...

.....以上为输出的错误消息现提示

符^]

不成功则关本机电源后重开电源

2.22.2.2.3 网络问题

此时主机已经挂起按回车后不出

重复以上操作

确认问题

"""

确认两台主机都处理开机状态确认没有安装问题硬件连接问题确认Telnet 终端连接

器

电源问题

启动问题

发现双机已经出现提示符hwhlr-ph1>或

hwhlr-ph2>且两机都可以在终端连接器上使用用户口令登录

问题表现

#####

双机中任一机Ping Ip不通双机中任一机Ping hostname 不通双机中任一机Ping 私网IP不通

双机中任一机使用rsh登录到另一机不成功双机中任一机显示网卡有倒换

请重新判断是否为网络问题

若没有以上问题

问题恢复

双机中任一机Ping Ip不通

基带跳频与射频跳频分析

重启动观察启动是否成功

不成功则备份/etc目录到/opt/hlrsetup/backup

下hwhlr-ph1.etc.error.日期

.tar.Z新定位问题

注意

双机中的备份是不同的每台机器都备有双机的备份先确认机器名

问题仍存在

再进行恢复

请求对磁盘全面恢复

必须命名为

重

恢复早期本机上的/etc 目录并

重启

电话通知HDB项目组

双机中任一机Ping hostname

不通

但Hostname Ping 不通

表示/etc/hosts

文件有问题

如果IP能ping通与安装手册比较

恢复本机下/etc/hosts

文件

必须确认两台机器的文件名后

再用

注意双机hosts

文件不同vi

修改

双机中任一机Ping 私网IP不通确认HA已经启动

查看当前私网

状态

如果私网已经从0口转到1

口

使用hastat命

令

表示有一块私网网卡出现了倒换要求SUN公司对网卡设备进行维护如果没有以上问题的私

网情况误

仍然Ping

不通

请使用ifconfig -a命令查看本机上

则表示为HA配置文件错

如果没有hme1和qfe0

的消息

恢复HA配置文件并重启HA参考恢复HA一节

双机中任一机使用rsh登录到另一机不成功

而使用rsh连接不正

常

如果使用IP和hostname进行Telnet 连接正

常这种情况下文件损坏

HA可能不能正常工

作

这是由于双机中主机信任关系

基带跳频与射频跳频分析

修改这个文件

所以在恢复前

再根并重

先通关掉自动备份与告警功

能

据安装手册上修改/.rhosts文件一节恢复两台主机的/.rhosts

文件新安装自动备份不成功

重启动

双机中任一机显示网卡有倒换

双机中任一机的当前网卡已经倒

换过可以看到网卡已经倒

换过

约一分钟一

次

用

使用Ifconfig -a命令查

看pnmstat -l查看NAFO一

节

在终端监视器

上查看发现有hme0 link down显示

使用Pnmstat -l查看公网NAFO状态正

常情况hwhlr-ph1>/opt/SUNWpnm/bin/pnmstat -lBkggrp r_adp status fo_time live_adp

恢

复时电

先检查网线连接是否断

开双LANSWITCH中是否有一个断

LANSWITCH上连接灯是否亮

表示网卡配置文件已

坏

检查公网NAFO倒换设

置

0表示第一台主

如果连接正

常

下面为一号主机上

操作机

1表示

第二台主机

最后一位是Cluster ID

号

hwhlr-ph1>/opt/SUNWpnm/bin/pnmd -s -c hwhlr -l 0以上三种情况都表示配置错误请恢复haconf再试不成功重启网络仍有故障

按以上步骤再测试一次确保NAFO设置没有问题通知SUN公司可能要对硬件网卡进行更换

恢复后重启动本机

主用机网卡问题先倒到备机备用机网卡问题要求恢复完成后

恢复后重启动本机检测网络全部正常

基带跳频与射频跳频分析

2.22.2.2.42.4 磁盘问题

确认问题

###

发现分区有异常增大

双机中任一机不能正常启动且不能按启动问题恢

复检测程序报磁盘阵列错误

问题恢复

发现分区有异常增大

查看/var/adm/messages

文件

看是不是有异常增

大

增大过

恢

复时快

请查看里面

内容后备份/var目录到/dsk/c0t0d0s7物理设备上的

恢复出厂备份的

ohter目

录下/var

文件名为hwhlr-ph1.var.日期

.tar.Z

双机中任一机不能正常启动且不能按启动问题恢

复

这种问很有可能是由于长期没有对系统进行维护部份目录空间不够造成启动不正

常恢

复

可能不能正常进入UNIX

将有故障的一台机halt进入ok

状态按上一种方法恢复原/var

boot -s

按

关单机的方法

让系统启动到单用户模

式0

ok boot -s

重启动

INIT: SINGLE USER MODE

Type Ctrl-d to proceed with normal startup,(or give root password for system

另一种情况是可能由于意外情况造成/opt或其它分区不能挂

上系统这样可能可以进入UNIX但是运行不正

常或大量应用不能运行恢

复工挂

上

fsck命令检查并修复磁

盘哪

个分区不见了

参考安装手册将没有挂上的分区手

就挂哪

一个分区

hwhlr-ph1>mount /opt /dev/dsk/c0t0d0sX

基带跳频与射频跳频分析

以上操作都不能

成功复

通知HDB项目

组请求对本机磁盘进行全面恢

检测程序报磁盘阵列错误

表示磁盘阵列上有硬盘从组中间

脱离

或是

如果自动恢复不能

成功磁盘阵列

配置问题恢

复双机不

成功

2.2.52.5 HA HA问题

先按要求备份双机/etc

目录并恢复正确的双机/etc

目录重启

参考以上磁盘阵列

操作使用手工恢复磁盘阵列

问题

确认问题

###

确认双机UNIX都正常检测程序报HA没有启动检测程序报磁盘阵列挂接不上

问题恢复

检测程序报HA没有启动

参考启动

问题

手工启动HA

恢

复

检测程序报磁盘阵列挂接不上

恢复ccd文件备

份

按要求启动HA

系统恢

复

表示ccd文件损

恢

复坏

不

成功停本机

HA恢复

haconf重启

HA系统恢

复表示系统配

置文件

损坏不

成功

不

成功

重启动

系统恢

复

表示配置文件

损坏

系统恢

复

磁盘阵列

硬件故障

手工恢复磁盘阵列

故障

基带跳频与射频跳频分析

GSM常见问题的处理思路

不

成功盘

说明磁盘阵列磁盘出现严重

故障与SUN公司联系要求换硬

同时申请使用单机接

管

2.3 HLR SERVER的问题处理

HLR SERVER中最重要的就是HLR数据

库MSISDN和KIKC等号码资源

过HLR SERVER完成

的统和SYBASE数据库的常用

操作同的地

方部分

内容

其中包括了用户的IMSI

所有的用户数据操作包括营业厅操作都是通由于HLR SERVER和OMC SERVER有很多共

详见下一

对于HLR SERVER的问题处理必须熟悉UNIX操作系

HLR SERVER的问题和OMC SERVER的问题放在一

起

基带跳频与射频跳频分析

第三部分 OMC OMC常见问题处理

要点

熟悉OMC的程序结构和常见进程掌握OMC常见问题的处理思路

3.1 OMC OMC的程序结构

要点

熟悉OMC在正常情况下有些什么进程掌握OMC的日志文件的意义

3.1.1 OMC OMC的正常进程

OMC服务器主要包含

如下几个部分 timesvrd 时间服务器

进程该有5

个以上的进程

newswitchsvr OMC系统路由

器Bam和各服务器进程都与之相

连newlogmanager 日志服务

器newserverd 配置服务

器器节

点信息

alarmbam 告警服务

器进程

hlrserver HLR用户管理服务

器HLR用户管理窗口被打

开时管理窗

口

处理各种HLR用户

操作只有1

个进程

当浏览器上没有

为所有浏览器

的全部业务台

所有浏览

器

为他们分配唯

一的台号

产生

日志

和记录并通知浏览

也就是平常见到的OMC

的进程

正常时以ps命令查看应

为整个系统提供定时服

务

Bam和各服务器进程提供彼此间

的路由选择

存放浏览器上各种操作

日志

为整个系统提供

定时是所有告警数据存放

地

通知Bam节

点号

并进行统一分发正常时有2个

有多少浏览器上打开了HLR用户

它的进程就多起

几个

基带跳频与射频跳频分析

newbillsvr 话单服务

器录下

接收Bam传

来的话单存放在OMC用户下的billdata目

务分发的

newcommdriver 应用集中

器统一接口

正常时有2

个进程

是服务器侧各业务台申请台号和业

newfhlrsvr OMC与HLR接口程

序据

正常时有2

个进程

进行协议转换和为HLR提供一些配置业务数

接有问题

若只有1个说

正常时有2

个进程

若只有1个说明与HLR连

Mmlsvr

进程用于营业厅人机命令的接口程序

明与营业厅连

接有问题3.1.2 OMC日志分析

OMC服务器日志信息是进行日常OMC服务器维护不可缺少

的部分都对应着自己的日志

文件

具体如下

timesvrd 时间服务器进程的日志文件为timesvr.lognewswitchsvr OMC系统路由器的日志文件为switch.log

newlogmanager 日志服务器的日志文件为logman.log数据库操作日志为logdbmsg.log

newserverd 配置服务器的日志文件为newconfig.log

alarmbam 告警服务器的日志文件为newalarm.log数据库操作日志为newalarmdbmsg.log

hlrserver HLR用户管理服务器的日志文件为hlrserver.loghlrdbmsg.log

newbillsvr 话单服务器的日志文件为newbillsvr.lognewcommdriver 应用集中器的日志文件为commdrv.log

newfhlrsvr OMC与HLR接口程序的日志文件为newfhlrsvr.log数据库操作日志为Newfhlrdbmsg.log

具体到出错

行号

数据库日志

其中正常日志程序运行过程中所有异

常信息

数据库操作日志为

每个进程

信息记录程序运行过程中涉及到数据库操作的出错

信息Bam与OMC服务器连接不上或各业务台操作异

常时志

信息

定位出错原

因

步骤

如下

A查看网络情况

以ping命令看出错机器与OMC服务器之间通讯状

况 B查看进程数量

在出现浏览器或

可以查看OMC服务器日

基带跳频与射频跳频分析

首先查看newswitchsvr进程是否为两

个若不是则进入OMC用户下log

以vi命令查看switch.log文件中Fail

信息或以如下命令进行错误信息统计:

grep Fail switch.log然后根据具体出错信息进行具体解

决其

次录计再次信息

最后

查看newcommdriver进程是否为两

个

若不是则进入OMC用户下log目

或以如下命令进行错误信息统

以vi命令查看commdrv.log文件中Fail

信息

grep Fail commdrv.log然后根据具体出错信息进行具体解

决

根据出错的业务台来确定相应的服务器

进程方法同上

如果确定出错进程为newlogmanager

其数据库日志中出现与错

误信息

hlrserver

newfhlrsvr或

查看其进程数和日志出错

alarmbamC

则以ISQL命令进入sybase环

境

查看数据库

情况

查看硬盘是否写满

一般屏幕

以df -k命令看硬盘的各相关文件系统是否

写满显示

格式如下

文件系统千字节用了可用容量挂接在/dev/dsk/c0t0d0s0 96031 13689 72742 16% //dev/dsk/c0t0d0s4 336863 226223 76960 75% /usr/proc 0 0 0 0% /procfd 0 0 0 0% /dev/fd

/dev/dsk/c0t0d0s3 192807 16013 157514 10% /var/dev/dsk/c0t0d0s6 428319 266876 118613 70% /home/dev/dsk/c0t1d0s0 96031 9 86422 1% /home1/dev/dsk/c0t0d0s5 384871 205396 140995 60% /optswap 114112 40 114072 1% /tmp

注意

如果某个文件系统的容量变为100%

则可能导致程序运行

出错

3.1.3 OMC服务器的常见的出错信息

A网络通讯异

常等

B硬盘文件分区

写满下

判断方式如3.2C所述如果在CDE窗口方式

包括系统设置不

正确