上海通信段MSC设备应急预案.docx

上海通信段MSC设备应急预案.docx

《上海通信段MSC设备应急预案.docx》由会员分享，可在线阅读，更多相关《上海通信段MSC设备应急预案.docx（29页珍藏版）》请在冰豆网上搜索。

上海通信段MSC设备应急预案

编号：

上铁电专-共用-04-001-2015

数字移动通信系统MSC设备应急预案

上海通信段上海高铁通信车间

2016年2月

一、编制依据

1.《上海通信段应急处置管理实施细则》（上通信调[2015]230号）；

2.《上海铁路局关于进一步规范路局应急处置指挥体系建设的通知》（上铁运[2014]283号）；

3.《上海通信段铁路通信障碍（故障）管理实施细则》（上通信调发[2013]89号）

二、系统整体介绍

上海GSM-R机房MSC基于西门子EWSD平台。

所有寄存器功能，都是由软件来实现的。

在硬件设计方面，许多重要部件都设置了冗余备份，主要体现在0侧与1侧互为备份。

目前MSC网络应用情况：

与北京核心网、武汉核心网的MSC/VLR、HLRi、SCP相连，与虹桥BSC、京沪高BSC、南京BSC、温州BSC、阜阳BSC、合肥BSC、杭州BSC各局向、FAS等相连，实现了上海局下所有GSM-R客专线的GSM-R核心交换、网内移动号码的鉴权、铁路专用的位置寻址、功能寻址、调度台与GSM-R移动终端的通信等功能。

三、应急预案内容

1.故障等级（一、二、三级）

1）一级：

设备宕机、与一个或多个TMSC局向中断、与某STP的信令能力中断、突发话务量造成上海MSC负荷过高的设备过载控制、智能业务中断、与专网（PSTN）的互联互通故障、与FAS系统局向全部中断、HLRi系统故障、与BSC系统局向全部中断、与RBC机房互联全部中断、与北京武汉互联电路全部中断。

2）二级：

MSC个别进程或数据吊死、对某局向中继部分中断。

3）三级：

单板故障（影响业务）

2.关键项：

汇报、登销记

1）当虹桥GSM-R工区发现局管内GSM-R系统MSC设备发生障碍（故障）时，应在五分钟之内汇报段调度、车间主任、网调工区，并通知相关设备维护车间网调工区。

2）车间主任在接到汇报后，立即组织人员赶赴虹桥GSM-R工区，负责组织指挥处理、信息汇报、障碍（故障）分析等。

3）虹桥GSM-R工区负责障碍（故障）的指挥处理、过程信息汇报、处理报告的撰写等。

4）网调工区根据虹桥GSM-R工区的处理要求，组织做好车间管内相关配合工作。

3.针对不同设备及故障等级编制处理措施

1）上海MSC宕机的应急技术预案（一级）

（1）启动前提

交换设备瘫痪、全部能力丧失时启动MSC宕机应急技术预案。

启动前提可归结为以下三种情况：

①交换机系统掉电；

②交换机CP侧瘫痪；

③交换机MP侧瘫痪；

（2）制定方案的原则

现场操作维护人员一定要马上通知诺西公司相关技术支持人员，并且清楚地描述宕机状态的发生时间以及问题的具体详细情况，不能擅自单独处理。

在机房备有紧急故障处理的Emergency手册，以备现场处理参照。

日常维护中严格执行计表中系统备份制度，备份带务必做好详细标签。

系统在重大操作前都必须做好系统备份带。

下表是各恢复等级的描述：

恢复

等级

　重启影响

由MML启动

由SW启动

正在建立的呼叫丢失与否

已经建立的呼叫丢失与否

预计恢复时间

NSTART0

所有与呼叫处理不相关的进程的重新启动

X

X

NSTART1

所有进程重新启动

X

X

X

<5s

NSTART1B②

呼叫处理基本模式，不从硬盘装载

X

X

>50s

NSTART2

所有进程重新启动，重新装载程序代码和所有半永久数据

X

X

X

>50s

NSTART3

所有进程重新启动，重新装载程序代码和所有半永久数据以及特定的瞬态数据

X

X

X

>60s

ISTART1①

初始启动SSP：

不对外围SW（LTG/DLU）做无条件重新装载

X

X

X

X

>120S

ISTART1B②

呼叫处理基本模式

X

X

X

>120S

ISTART2①

初始启动SSP；无条件重新装载外围数据至所有应处于工作状态的LTG

X

X

X

X

>6M

ISTART2R（在修改LTG软件后使用）

带重新装载的SSP初始启动；仅通过人工操作，无条件装载不处于MBL或PLA的LTG

X

不相关

不相关.

>15M

ISTART2F（在安装APS后使用）

强制初始启动SSP，仅通过人工操作，装载处于MBL状态外所有已安装的LTG

X

不相关

不相关.

>15M

ISTART2G

初始启动SSP，倒回至旧的APSGEN;无条件重新装载所有应处于工作状态的LYG/DLU的外围程序代码和数据

X

X

X

X

>15M

①ISTART1/2的后处理恢复尝试重新装载并激活所有处于UNA的LTG/DLU。

②NSTART1B和ISTART1B不用于D900/1800移动业务交换中心MSC。

（3）应急措施

抢修组确认预案启动前提成立，参照应急通信故障的报告和通报流程制度启动应急预案。

宕机应急技术预案启动后，抢修组应马上联系诺西相关技术支持。

在诺西人员无法马上赶到现场的情况下，现场维护人员应在诺西技术支持的指导下，严格参照Emergency手册中相应的紧急流程进行分析处理。

a.交换机掉电时，影响所有GSM-R业务，系统需重新启机，启机最长用时40分钟。

D900交换机在断电后再通电会自动选择GEN重新启动至MANUAL状态，设备自动重启之后如果有不正常的状态，需尽快的将交换机恢复至ACTGEN并保证硬件设备正常，以下为具体操作流程：

若设备自动重启无法正常启动，需要用人工进行重启，详见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启机）---“”

输入命令：

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:

,;启单元：

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话务通道阻断为例）

b.技术台账

MSC局名

归属号段

武汉

北京

南昌

济南

c.操作命令行

①倒代命令（执行完后进行拨测确认）：

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倒代方案示意

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疏通话务为例）

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）应急措施

抢修组确认预案启动前提成立，参照应急通信故障的报告和通报流程制度启动应急预案。

倒代方案示意（以到上海FAS系统全部中断为例）

8）HLRi系统故障（一级）

（1）启动前提

HLRi系统故障，总部统一指挥倒代。

（2）预案原则

北京MSC具有HLR的功能，北京MSC将做成HLRi系统的冷备份，在HLRi主备用系统都宕机时，在北京MSC上进行数据修改，由北京MSC承担HLR的功能。

由于涉及全网数据，预案各步骤的执行由总部统一指挥。

（3）应急措施

抢修组确认预案启动前提成立，参照应急通信故障的报告和通报流程制度启动应急预案。

北京MSC进行数据修改，由北京MSC承担HLR的功能。

武汉STP修改HLR指向到北京MSC。

抢修组在总部指挥下开始执行倒代。

a.倒代方案示意

b.技术台帐

网元名

信令点

武汉STP

42-255-22

北京MSC

42-255-21

c.操作命令行

①倒代命令（执行完后进行拨测确认）：

MODSIGDP:

NETID=4，DPC=42-255-21，Adminstate=LOCKED;

当HLRi故障修复后，由总部统一指挥执行恢复。

②恢复命令（执行完后进行拨测确认）：

MODSIGDP:

NETID=4，DPC=42-255-21，Adminstate=UNLOCKED;

9）与BSC系统局向全部中断（一级）

（1）启动前提

MSC与BSC（TRAU）局向全部中断，影响该BSC范围的GSM-R终端无法使用。

（2）预案原则

尽快恢复通信，若原因为物理连接引起，用临时通道恢复业务；若为硬件故障，立即更换损坏硬件；若为软件故障，立即由厂家现场技术支持进行解决。

（3）应急措施

抢修组确认预案启动前提成立，参照应急通信故障的报告和通报流程制度启动应急预案。

抢修组组长汇报实时情况于领导小组，抢修组对故障进行原因排查。

①如果确认原因为物理连接引起，查找BSC的台帐，确定链路2M所在，要求传输室先代通带链路的通道，再最大限度恢复该BSC最低通信容量要求，当原有物理连接修复后恢复原状。

②若为硬件故障，立即更换损坏硬件。

③若为软件故障，立即由厂家现场技术支持进行解决。

10）与RBC机房互联电路全部中断（一级）

（1）启动前提

对RBC机房互联电路全部中断。

（2）预案原则

不能影响原有正常业务，如有影响，处理须在天窗时间进行。

（3）处理措施

目前，我们在虹桥RBC通信机房上了两套ONS3500：

RBC01和RBC02。

共布放2条光缆一条32芯、一条30芯，32芯中的1-4芯与RBC机房相连的RBC01传输设备上，30芯中的1-4芯与RBC机房相连的RBC02传输设备上。

再由传输设备RBC01、RBC02下2M电路与RBC通信设备相连。

日常维护中观察MSC网管告警信息：

1.是光纤故障，由虹桥核心网机房值班人员倒换GSM-R机房到RBC机房的两端