TDSCDMA 资料TDSCDMAOMC告警屏蔽功能失效问题总结.doc

OMC告警屏蔽功能问题总结 一 工程问题： nodeb网元升级或传输割接等大批量断站工程之后一定要做的三件事： 要及时处理维护通道不通的问题。 传输割接后由于RNC侧单板IP改变，nodeb到omc的路由若没能及时建立，将导致大批基站维护通道不通，后台无法维护，同步无法保障。所以割接后及时协调省网管相关人员处理路由问题 及时检查并确保网元同步。 我们的TD设备投入使用为时不久，维护资料不完善，维护人员对各网元操作不甚了解。造成漏洞百出。以下是我总结的同步方法，不足之处欢迎大家批评指正。 保证OMC要与网元同步： 检查并配置数据同步自动同步 root@osssvr-1 # ntpq -p remote refid st t when poll reach delay offset jitter ================================================================= *10.47.0.161 10.46.58.1 2 u 24 64 377 0.600 0.855 0.490 root@osssvr-1 # b. 保证RNC与核心网同步，时钟源设置为LINE1_8KHZ；保证RNC与OMC同步：在RNC侧打开SNTP服务，使用命令“SET SNTPCLTPARA: SP=60, SW=ON;” c. 保证NODEB侧时钟源设置正确, 设为GPS,具体命令为：”SET TIMESRC: TIMESRC=GPS;”保证nodeb与OMC同步，即打开NTPC同步，使用命令“SET NTPC: SYNCCYCLE=60, SYNCSWITCH=ON;” C． 及时手动删除所有告警。 鉴于我们软件许多问题，建议大批量断站工程之后，及时保存告警信息并删除当前所有告警一次。以便消除误告问题。 NodeB割接完要在网元侧执行清除告警的操作。割接完了，肯定是要做健康检查的，检查完了历史告警就没什么价值，不如割接当晚全删掉（谨慎的话导出来做个备份） 软件问题包括OMC主拓扑中“……_deleted”站名产生问题,和Nodeb侧工程装多少正常硬件就做多少数据；RNC侧对不能完全开通的站点只做传输信令数据。并且形成一个规范，执行下去。争取在升级前完成这项工作，以免升级后造成许多工程麻烦。这样的话，网优就不会每天拿着许多垃圾数据来找我们的麻烦了。我们各网元工程师的负担也会减少许多。如果工程没有来自移动站点数要求的压力，建议工程日报把原来作假记录剔除，以便大家维护一个有效的表格，提高工作效率。 D. 发现问题及时上报。现场及时总结问题非常重要。 各网元工程师及时发现问题，总结问题，上报问题。网元维护需要大家共同努力。新设备组网初期，有的网元还是测试版本，任何一个现场工程师都可能遇到研发所不曾遇到的问题。只有发现问题，才能解决问题。最近发现基站工程师排障日报不能及时提交。没有人主动提交现场问题总结报告。这说明工程师没有积极性。 二 软故障维护问题 告警屏蔽失效的原因分析： 屏蔽失效原因之一：系统进程运行故障 请尝试将OMC的FaultService进程重启一下，再做测试看是否能屏蔽掉告警。 重启步骤如下： 用root帐号telnet登录到OMC服务器，执行如下命令： # . /opt/OMC/svc_profile.sh # svc_adm -cmd restartsvc FaultService 重启完后，检查OMC状态 # svc_adm -cmd status 最后一行not running的进程数必须是0，如果有进程是not running的，可用 svc_adm -cmd startsvc Serivce启动之。 例如： # svc_adm -cmd startsvc NHCServer 根据经验，FaultService服务重起时会引起告警大量上传。重启后建议及时删除所有告警一次 屏蔽失效原因之二：个别网元定位信息漏洞 如果查看历史的告警，发现有很多告警的“MO对象”没有定位到具体的MO，而只定位到RNC。这可能导致屏蔽失效。 解答：请先在OMC主拓扑图上手工做一下配置同步，同步结束后，可查一下iMAP.cdmc_agent.trace日志，看看同步是否成功 # cd /opt/OMC/var/logs # grep ManualSynch iMAP.cmdc_agent.trace 如果有类似如下的信息，则配置同步成功 Svr.Syn: NeEntity[3221287267]: Synch[ManualSynch]: Synch_InProgress -- Synch_Success! Svr.Syn: