LTG=X-X;检查是否有很多LTG在SEZ状态.
若设备自动重启无法正常启动,需要用人工进行重启,详见CP侧瘫痪、MP侧瘫痪应急预案。
b.交换机CP侧启机,影响所有GSM-R业务,需立即对CP侧进行启机:
①准备工作:
将IOP-UNI后背板的03C295P1或04C295P1连出线为串口线连接到电脑终端COM1口;
将CP侧1侧的BAP(010101柜07框257)关电,用于必要时的备用。
在电脑终端打开BMML操作框(必须有BMML软件)。
②硬盘状态正常,在正常(MANU)模式下重启:
按0侧CMY的boot键,在BMML中输入命令“FORMAT;”出现显示(如果无显示,需要重新按boot键)----“;”---“MANU”---“IOC-0”(如果启机用1侧,则用IOC-1)---选择一个GEN的名字(一般用前期所用的GEN,本次用的为ODAGEN----FORCED----需要一段时间大约40分钟,之后查STATSSP确认启机是否完成。
③硬盘状态不正常,使用最近备份的光盘启机,在UTI模式下重启:
按0侧CMY的boot键,在BMML中输入命令“FORMAT;”出现显示(如果无显示,需要重新按boot键)----“;”---“UTI”---“MOD”---“010C23”(为MOD0启机)---“SY.INSTALL”
输入命令:
INITMD:
DEVOUT=010C01(如为MDD1则输入030C01);初始化硬盘;LABELMD:
DEVOUT=010C23;做成系统盘;TRANSFILE:
DEVIN=010C23,DEVOUT=010C01(如为MDD1则输入030C01);FILECAT=*,OLDGEN=*,NEWGEN=*;将光盘下所有文件传送到硬盘下。
使用硬盘在MANU模式下再启机。
④启机之后,使用SwitchCommander进行查看DISPGENCPMP,确认GCS一致。
查看相应的CP、MP侧状态。
确认一切正常,并修改时间(ENTRTIME)。
c.交换机MP侧瘫痪,影响所有GSM-R业务,需立即对MP侧进行启机(硬盘、光盘启机均适用):
①准备工作:
准备一台笔记本电脑,一条9针串口线,到设备前,将串口线连到0侧MP:
OAM(010102柜09框251槽);
将1侧MP:
OAM(010102柜09框271槽)拔出;
将电脑服务中的BCTCOM口release掉,打开超级终端
②操作步骤:
按0侧MP:
OAM(010102柜09框251槽)RES键,超级终端出命令,〈CTRL〉-X进入选项(1,2,9)---进入1确定IP地址、ASN等无误,确认使用MDD(MOD);---进入2选择GEN---进入9选择reboot。
启机大约20分钟。
启机之后,使用SwitchCom进行查看DISPGENCPMP,确认GCS一致。
查看相应的CP、MP侧状态。
确认一切正常,并修改时间(ENTRTIME)。
(4)全业务验证
宕机恢复后必须对全业务进行验证,包括开关机、通话(MTC/MIC/MOC/MMC)、组呼/广播、短信、短号码、列控业务(RBC)、FOLLOWME等等。
(1)启动前提:
SGSN宕机,主备的功能单元模块均不能正常工作,同时已有平时的SGSN数据备份带。
(2)应急措施:
日常维护中应该严格执行计表中的系统备份制度,做好备份带及详细标签。
系统在重大操作前都必须做好备份带。
宕机预案启动后,机房操作维护人员应该马上联系诺西相关技术支持,在诺西技术人员无法马上赶到现场情况下,现场维护人员应该严格按照诺西厂家提供的相应紧急故障处理流程进行分析处理。
紧急情况下可能需要对设备进行重启、切换操作,在进行类似操作前,应运行命令收集信息,便于故障的跟踪处理。
(3)实施步骤:
SGSN:
登录进SGSN的管理界面,按照下列步骤进行操作。
a.系统重启:
确认系统有可用的备包;
WQO:
CR;
同步数据库文件;
DBC:
GPDATA,0;
DBC:
OEDATA,0;
DBC:
EQUIPM,0;
检查数据库的一致性
DBS:
GPDATA,0
DBS:
OEDATA,0;
DBS:
EQUIPM,0;
DBD:
OMU;
确认磁盘同步任务已经全部完成
DUQ;
关闭并上传所有话单
GHA;
重启系统:
USS:
SYM:
C=DSK;
b.系统还原:
从光盘复制备包到硬盘:
IWL:
OMU:
WSB,NODEF:
FB061214,FFF0,,XY:
;
IWY:
S:
UNIT=OMU,PATH=/SG04-061214,DRIVE=FDU-N0,;
IWY:
D:
UNIT=OMU,PATH=/FB061214,DRIVE=WDU-SB,;
IBC:
,%%,,,,,,DIR:
:
;
IWX:
OMU:
WS,NODEF:
FB061214,:
%,%,;
WQC:
NAME=FB061214,DIRE=FB061214,:
CW=ALL,:
;
当defaultBU包出错时用FB包还原:
将FB包状态改为default
WSD:
NAME=FB010712
修改状态,
WSR;
WKS:
MODE,NAME=FALLBACK1,DIRE=FALLBACK1,MODE=FULL;
WQD:
NAME=BENSON1:
DIRE;
必要时确认包的内容
WQB:
NAME=FALLBACK1:
FORM=FAILED;
c.收集软件故障数据:
ZDDS:
,;//进入需采集日志的单元
ZGSC;//显示日志Computerlog
ZE;//退出
d.重启单元:
USU:
PAPU,0;
2)与一个或多个TMSC局向中断(一级)
(1)启动前提
上海MSC与一个或多个TMSC局向中断,仍有可正常通信的TMSC局向。
(2)预案原则
按照局数据设置原则应当增加到各个局向的备份话务路由。
到归属汇接区的MSC备选话务路由是本汇接区的TMSC。
到非归属汇接区的MSC的备选话务路由是第二汇接区的TMSC。
用户拨号方式不变;以保证接通为主,主叫号码规范、计费等仅尽量兼顾,在紧急情况下不做严格要求。
目前上海MSC只有与武汉TMSC和北京TMSC相连,根据实际情况武汉TMSC是归属汇接区的TMSC,北京TMSC是上海的第二汇接区核心节点。
预案的执行与恢复都必须进行拨测确认。
(3)应急措施
抢修组确认预案启动前提成立,参照应急通信故障的报告和通报流程制度启动应急预案。
抢修组根据实际情况请求与中断MSC可正常通信的TMSC执行应急预案疏通话务,当疏通TMSC放通数据后,抢修组在上海MSC执行操作定义故障TMSC的号段指向疏通TMSC疏通话务。
当故障恢复时,需要将数据恢复原状。
a.倒代方案示意(以到武汉TMSC话务通道阻断为例)
861490851
归属汇接区
第二汇接区
武汉TMSC
上海MSC
上海MSC——武汉TMSC方向的业务倒代示意图
北京TMSC
861490851
861490851
b.技术台账
MSC局名
归属号段
武汉
861490851
北京
861490821
南昌
861490818
济南
861490843
c.操作命令行
①倒代命令(执行完后进行拨测确认):
DISPCPT:
CPT=861490851;(结果显示DEST=WHMSC)
CRROUTE:
DEST=WHMSC,TGNO=BJMSC,ROUTE=2;
由于现网与北京MSC无话路,但已经创建并保留路由ROUTE和中继群TGRP数据,如果需创话路数据,可使用以下命令创建:
ENTRC7TGREL、CRC7USER、CRTRUNK
当抢修组确认修复好中断MSC的通信故障后,抢修组组长汇报实时情况于领导小组,请求执行恢复,得到领导小组同意后开始执行倒代恢复。
②恢复命令(执行完后进行拨测确认):
CANROUTE:
DEST=WHMSC,ROUTE=2;
DISPROUTE:
:
DEST=WHMSC;(确认已恢复路由中继群指向武汉),删除到北京的话路数据。
3)与某STP的信令能力中断(一级)
(1)启动前提
上海MSC与某STP信令能力中断,而到其他STP之间通信正常。
(2)预案原则
可查询在MTP层是否有备份路由,按照局数据设置原则应当增加到各个局向的备份信令路由。
到LSTP的备选信令路由是本信令区的另一个LSTP。
到HSTP的备选信令路由是另一个HSTP。
目前上海MSC只有与武汉、北京HSTP相连,并已根据实际情况定义信令路由,当到其中之一的HSTP方向信令路由全阻时,MSC会自动将信令全部转移到另一个HSTP上疏通。
预案的执行与恢复都必须进行全业务验证,包括开关机、通话(MTC/MIC/MOC/MMC)、组呼/广播、短信、短号码、列控业务(RBC)、FOLLOWME等等。
(3)应急措施
抢修组确认预案启动前提成立,参照应急通信故障的报告和通报流程制度启动应急预案。
a倒代方案示意
备选信令路由
武汉HSTP
上海MSC
上海MSC——武汉HSTP方向的业务倒代示意图
北京HSTP
首选信令路由
b.技术台帐
HSTP名
信令点
武汉
42-255-22
北京
42-255-21
c.操作命令行
①倒代命令(执行完后进行拨测确认):
MODSIGDP:
NETID=4,DPC=42-255-22,Adminstate=LOCKED;
当抢修组确认修复好中断STP的通信故障后,抢修组组长汇报实时情况于领导小组,请求执行恢复,得到领导小组同意后开始执行倒代恢复。
②恢复命令(执行完后进行拨测确认):
MODSIGDP:
NETID=4,DPC=42-255-22,Adminstate=UNLOCKED;
注:
以上命令是在武汉HSTP无法处理信令但信令点未失效时用。
4)突发话务量造成上海MSC负荷过高的设备过载控制(一级)
(1)启动前提
由于突发话务量等原因导致某些方向的呼叫难以接续;从而引起CPU负荷过高并有可能引起MSC重启。
(2)预案原则
以保证MSC通信安全为主,并最大限度保证优先级高的用户通信。
当MSC恢复正常后,条件成熟时,可以逐渐地解闭先前关闭的设备。
(3)应急措施
抢修组确认预案启动前提成立,参照应急通信故障的报告和通报流程制度启动应急预案。
并按照实际情况采取以下相应措施降低MSC负荷。
(注:
以下措施执行必须获得领导组的同意)
a.关闭鉴权
当CP负荷过高时,可以首先考虑在MSC完全关闭鉴权以大幅度降低鉴权的次数,降低A接口的负荷,也可以降低BSC的负荷及SDCCH的占用时长,减少SDCCH的拥塞,同时也会降低MSC到HLR的信令负荷。
①应急命令:
MODSERVOPT:
FEAT=AUTHENT,STAT=BLK;
②恢复命令:
MODSERVOPT:
FEAT=AUTHENT,STAT=ACT;
注意:
关闭鉴权可以降低CP负荷,但在完全关闭鉴权后,某些非法SIM卡就可能呼叫成功,所以应注意在话务高峰过去后及时恢复数据。
还需要注意的是,关闭鉴权后,是使用IMSI寻呼,CP负荷是降低了,但是基站的寻呼负荷可能会增加。
建议按实际情况操作。
b.闭塞部分电路
对于因某条或某几条路由负荷过高引起交换机负荷剧增,可考虑实际情况闭塞路由或闭塞部分电路以保证交换机的安全和其它路由话务不受影响。
①应急命令:
ENTRTGDAT:
TGNO=WHMSC,CIC=2-1,BLK=Admin;
②恢复命令:
CANTGDAT:
TGNO=WHMSC,CIC=2-1,BLK=Admin;
c.考虑限制某种业务类型
比如限制用户收发短信,通过在MSC作限制手段,限制用户接收短信。
①应急命令:
MODMSERVOPT:
TSERV=TS21,STAT=BLK;(收信息)
MODMSERVOPT:
TSERV=TS22,STAT=BLK;(发信息)
②恢复命令:
MODMSERVOPT:
TSERV=TS21,STAT=ACT;(收信息)
MODMSERVOPT:
TSERV=TS22,STAT=ACT;(发信息)
d.停止话务统计
通过停止收集话务统计,可以相应地降低CP负荷。
①应急命令:
DISPJOB;(查找话务统计任务号,例:
80)
STOPJOB:
JN=80;
②恢复命令:
CONTJOB:
JN=80;
注释:
虽然可降低负荷,但是缺乏分析系统在超负荷时运行状态的信息,影响到以后对故障的分析处理。
5)智能业务中断(一级)
(1)启动前提
与北京和武汉SCP局向全部中断业务,影响位置寻址及功能寻址。
(2)预案原则
为保证通信,用户放弃原有智能业务的拨号方式,直接拨打短号码、功能号、机车所对应的MSISDN号。
故障排除后,恢复原有拨打方式。
(3)应急措施
抢修组确认预案启动前提成立,参照应急通信故障的报告和通报流程制度启动应急预案。
抢修组立即通知温福和甬台温及武广线调度员启动备用应急通信,将短号码及功能号对应的MSISDN通知列车调度员,列车调度员把所对应的MSISDN号通知火车司机。
短号码对应MSISDN号码表:
温福和甬台温及武广线短号码对应的MSISDN号以开通业务为准。
功能号对应MSISDN号码表:
温福和甬台温及武广线机车对应的MSISDN号以开通业务为准。
当抢修组通过对智能网全业务进行验证,包括短号码、功能号、FOLLOWME等等确认已修复好智能业务通信后,抢修组组长汇报实时情况于领导小组,请求执行恢复,得到领导小组同意后开始执行倒代恢复。
抢修组立即通知温福和甬台温及武广线调度员故障已解决,停止备用应急通信。
6)与专网(PSTN)的互联互通故障(一级)
(1)启动前提
上海MSC与上海专网局向中断,有可正常通信的MSC局向,且该局向与专网(PSTN)有连接。
(2)预案原则
用户拨号方式不变;以保证接通为主,主叫号码规范、计费等仅尽量兼顾,在紧急情况下不做严格要求。
目前上海MSC只有与武汉TMSC和北京TMSC相连,武汉、北京MSC都有与PSTN相连。
预案的执行与恢复都必须进行拨测确认。
(3)应急措施
抢修组确认预案启动前提成立,参照应急通信故障的报告和通报流程制度启动应急预案。
抢修组根据实际情况请求与武汉/北京MSC执行应急预案疏通话务,当疏通MSC放通数据后,抢修组在上海MSC执行操作定义PSTN号段指向疏通MSC疏通话务。
当故障恢复时,需要将数据恢复原状。
a.倒代方案示意(以武汉MSC疏通话务为例)
901XXXXX
专网(PSTN)
上海MSC
上海MSC——PSTN的业务倒代示意图
武汉TMSC
901XXXXX
901XXXXX
b.操作命令行
①倒代命令(执行后进行拨测确认):
DISPCPT:
CPT=901;(结果显示DEST=PSTN)
DISPROUTE:
DEST=WHMSC;(结果显示中继群指向WHMSC)
MODCPT:
CPT=901,DEST=WHMSC;
当抢修组确认修复好中断STP的通信故障后,抢修组组长汇报实时情况于领导小组,请求执行恢复,得到领导小组同意后开始执行倒代恢复。
②恢复命令(执行后进行拨测确认):
MODCPT:
CPT=901,DEST=PSTN;
DISPCPT:
CPT=901;(确认已恢复DEST=PSTN)
7)与FAS系统局向全部中断(一级)
(1)启动前提
上海MSC与上海/南昌/上海FAS系统全部中断,影响上海/温福/甬台温调度台与GSM-R移动终端通信,上海MSC与专网(PSTN)通信正常。
(2)预案原则
为保证通信,临时启用调度台所在地的专网电话号码行驶调度功能。
故障排除后,恢复原拨打方式。
(3)应急措施
抢修组确认预案启动前提成立,参照应急通信故障的报告和通报流程制度启动应急预案。
901041XXXXX
上海FAS
上海MSC
上海MSC——武汉TMSC方向的业务倒代示意图
上海专网
741XXXX
上海调度
倒代方案示意(以到上海FAS系统全部中断为例)
抢修组在故障发生后立即排查故障原因,并联系西门子厂家技术支持8008208202;
8)HLRi系统故障(一级)
(1)启动前提
HLRi系统故障,总部统一指挥倒代。
(2)预案原则
北京MSC具有HLR的功能,北京MSC将做成HLRi系统的冷备份,在HLRi主备用系统都宕机时,在北京MSC上进行数据修改,由北京MSC承担HLR的功能。
由于涉及全网数