MSCPOOL解决方案应急预案(DOC 65页).doc

1、MSOFTX3000&UMG8900 MSCPOOL 应急指导书1 概述1.1 目的MSOFTX3000&UMG8900产品在MSCPOOL组网时，可能会因为POOL中的某个网元单点故障或承载网故障导致整个POOL范围内业务受到影响，这种情况发生时造成的后果将比单MSC组网时更为严重。本文专门针对MSC POOL组网情况制定应急处理措施。1.2 使用对象一线用服人员；二线用服人员；MSOFTX3000&UMG产品开发、维护人员。1.3 MSCPOOL组网时故障处理的基本思想针对以上POOL组网的特点，在对POOL网络进行故障处理时，需要：1）树立全局观，从网络层面观察问题现象，尽量从网管上进行

2、话统和告警信息收集和分析；若网管上的信息不全，则需要尽快使用信息收集工具并行收集POOL内所有MSC Server的信息；2）通过对POOL内所有MSC Server和MGW网元上的告警和话统进行综合分析，来界定故障网元（也包括故障的承载网路径）并进行故障隔离；3）了解POOL组网情况下网元间的信令消息广播和重传机制，必要时切断广播路径；4）对IP承载网的Qos质量检查手段、承载网平面倒换方法充分掌握；5）对SIGTRAN链路在承载网质量下降或中断时的处理机制、外在表现和定位手段充分了解。POOL组网下，事故处理总流程：关键点：1）明确POOL网络级组网方案；2）故障网元或故障承载网路径的定界

3、；1.4 POOL组网时网络维护所需提前准备的工作1.4.1 准备并配置好M2000网管解决方案版本MSOFTX3000版本UMG8900M2000版本CS8.1R007C05/R008C03V200R008C03SPC100（推荐）V200R008C02B027V200R007C03B048V200R007C03B041V200R006C03B045公共层：M2000-II V200R009C00SPC230适配层：iManagerM2000_MSOFTX3000_MATCH_CHS_V200R008C03SPC002CS8.0R007C03/R008C02V200R008C02（推荐）V2

4、00R008C01B032V200R007C03B045V200R007C03B041V200R005C10B039V200R005C10B048V200R005C02B065公共层：M2000V200R008C03SPC110（推荐）M2000V200R006C01B060SPC007M2000V200R008C01B060SPC008适配层：iManagerM2000_MSOFTX3000_MATCH_CHS_V200R008C02SPC002CS7.0R007C01V200R007C03B041（国内使用推荐版本）V200R007C03B045（海外使用推荐版本）公共层：iManager

5、M2000V200R008C01B060 SP05（推荐）iManagerM2000V200R006C01B060 SP03适配层：iManagerM2000(MSOFTX3000_MATCH_ENG)V200R007C01B011iManagerM2000(MSOFTX3000_MATCH_CHS)V200R007C01B011CS6.5R006C05iManagerM2000V200R006C01B060SP03CS6.2R006C02iManagerM2000V200R006C01B022SP01注：M2000的V200R008版本需要安装专门的RPS模块才能支持POOL性能统计功能；因

6、此M2000的版本使用V200R009C00版本更合适。1.4.2 获取MSC POOL组网图和MSCPOOL规划数据方法1：从M2000上查看MSCPOOL网络拓扑在M2000上一般已经设置了MSC POOL的网络拓扑关系，从M2000上可以直观的查看POOL中各种网元（MSC和MGW）的数量；且可以查询简单的MSC POOL的全局规划数据，如CN-ID、NRI、NullNRI、以及CN-ID与NRI的对应关系等配置信息。（仅能收集到最简单的拓扑关系，网管上可能尚未配置）方法2：从网规网设文档中查看MSCPOOL网络拓扑（网规网设文档可能无法及时获取，网规网设文档中的信息可能不是最新）；方法

7、3：咨询一线人员，临时获取网络拓扑（速度慢，准确度低）； 方法4：手工从数据库获取MSCPOOL的网络组网情况（效率低，速度慢）；1.4.3 在M2000上设置实时监控在M2000上，可以创建MSCPOOL实时监控任务来查看POOL的实时运行状态，具体方法：通过选择“维护 Pool操作维护”菜单，打开“Pool操作维护”界面。在导航树中选中要监控的MSC Pool，右键选择“实时监控”。下面是在M2000上创建的MSC POOL实时监控的输出结果图例：1.4.4 在M2000上查询MSC POOL话统注意：在M2000上查询MSCPOOL的话统前提是已经使用M2000在POOL内各网元上已经登

8、记所依赖的话统任务。在网元上所需要预先登记的话统任务如下表所示：M2000上的MSCPOOL话统依赖的MSX3000网元上话统任务POOL内全局话务量入局话务测量GSM用户发话话务测量UMTS用户发话话务测量中继局向入局话务测量POOL内本地话务量局内话务测量中继局向入局话务测量入POOL话务量入局话务测量中继局向入局话务测量出POOL话务量出局话务测量中继局向出局话务测量移动局向入局话务量移动局向入局话务测量移动局向出局话务量移动局向出局话务测量VLR各类用户数测量VLR各类用户数测量MSC POOL切换测量MSC切换测量位置区话务分布测量位置区话务分布测量GSM掉话率GSM掉话测量WCDM

9、A掉话率TD-SCDMA/WCDMA掉话测量短消息业务测量短消息业务测量寻呼测量寻呼过程测量位置更新测量位置管理业务测量BSC局向指配测量GSM指配过程测量RNC局向指配测量TD-SCDMA/WCDMA指配过程测量在M2000上，可以通过“Performance- Query Result”菜单项开启话统查询导航树，导航树种会列出POOL支持的话统任务，通过右键菜单即可开始进行话统结果查询。查询话统时需要选择对象类别、查询对象、查询时间段。M2000上查询话统的界面如下图所示：1.4.5 在MSC Server和MGW上登记以LAI或BSC为对象的话统任务在MSC POOL组网情况下，以LAI

10、/BSC为单位的话统可以正确反映故障网元的表现情况，因此需要在MSC Server上登记下列以LAI或BSC为对象的话统任务：1）承载话务量-MSC CSSR话务测量；2）全局组件-BSC话务分布测量3）全局组件-RNC话务分布测量4）全局组件-位置区话务分布测量5）MSC基本测量-位置管理业务测量6）MSC基本业务测量-TMSI重分配业务过程测量7）MSC基本业务测量-寻呼过程测量8）全局组件-接入侧动态流控测量9）信令与接口-H248_MGW事务测量需要在MGW上登记下列话统：1）MSC Pool CN节点统计2）MSC Pool NRI统计以上话统结果建议使用CMC【M2000】上集成的

11、信息收集工具或版本配套的信息收集工具来收集。2 MSC POOL组网时各种事故场景2.1 MGW退服问题2.1.1 MSCPOOL组网时如何判断MGW退服的场景通过M2000告警进行检查n M2000上出现MSC网元的“MGW退出服务”告警（告警ID：1522），或出现MGW的“MGC失去连接”告警（告警ID：1802）通过MSC Server告警进行检查n ALM-1522 MGW退出服务n ALM-1453 H.248 SCTP链路故障或ALM-1524 H.248 UDP链路故障，所有链路全部故障n DSP MGW结果为不是“正常”状态2.1.2 MGW退服的主要原因1）承载网故障2）数

12、据配置错误3）MGW故障4）Server内部异常2.1.3 MGW退服事故恢复和处理可以归类为三种MGW退服场景：1) 所有Server上同一个MGW退服在POOL组网情况下，一旦出现单MGW在所有Server上退服故障，则可能为MGW本身故障，或MGW到IP承载网接入路由器之间承载网路径上出现故障。2）单个Server上所有MGW退服单个Server到所有MGW故障可能为Server数据配置异常，或MSC Server到IP承载网接入路由器之间承载网路径上出现故障，或者MSC Server内部异常等。3）其他场景单个Server上单MGW退服：一般是数据配置错误或维护操作导致的MGW退服。单

13、个Server上多个MGW退服：可能是承载网拥塞导致；POOL内所有Server上多个或全部MGW退服：一般是IP骨干承载网出现故障。通用处理步骤问题确认步骤1）在MSC上获取出现退服的MGW的IP地址，然后通过Ping和TraceRT跟踪观察IP承载网是否存在不通、丢包或时延过长（Ping跟踪时，包长可以设置为500左右）如果是，则记录故障的IP对，端口号，业务类型，尽快联系IP承载网解决2）观察H248链路是否正常如果H248链路故障，则按照步骤3）检查配置是否正确如果H248链路正常，则跟踪所有H248链路，观察MGW与Server交互是否正常，MGW是否上报了注册请求。如果MGW没有上

14、报注册请求或者请求内容错误，则可能为MGW内部问题，需要更进一步分析。如果MGW上报了注册请求，而Server没有返回，则可能为Server内部问题，需要Server更进一步分析。3）检查Server和MGW上数据配置是否异常，关键参数是否一致Server上：LST MGWLST H248LNKLST SCTPPARALST BCPARADSP H248VERMGW上：LST VMGWLST H248LNKLST H248PARALST SCTPINIT4）如果配置正常则分析是否IP承载网隐性故障使用IP承载网故障应急手册定位是否承载网问题。恢复措施：如果数据配置错误，则修正对应的配置如果是承

15、载网问题，则首先需要界定MGW到IP骨干承载网之间故障发生的位置，然后尽快恢复承载网。如果承载网存在主备用双平面，应该切换信令和业务的承载网平面来恢复故障（单归属情况下倒换接口板，多归属情况下，重新调整链路主备IP）。如果可能是Server或MGW内部问题，则可以在Server上尝试去激活、激活MGW，在MGW上去激活、激活VMGW。所有Server上同一个MGW退服暂时找不到原因的情况下1）复位MGW的接口板2）倒换MGW近端IP承载网平面3）可以考虑复位MGW尝试恢复单个Server上所有MGW退服1）确认故障Server的业务是否已经被接管2）如果没有被接管（可能MGW到Server的M

16、3UA路由还没中断），则尽快将该Server业务迁移到其他Server上（在所有MGW依次上将该故障Server状态设置为“卸载”）3）如果已经接管，确认业务没有影响情况下，再继续分析退服原因。4）倒换近端承载网平面；5）可以复位BSG，倒换IFM、MGC来尝试是否故障可以恢复其他场景1）多个MGW在多个Server上出现退服，则IP骨干网拥塞或故障的可能性较大，需按照IP承载网问题定位指导书进行处理。2）可以尝试在一个Server和MGW上倒换平面2.2 接通率下降问题2.2.1 如何判断接通率下降事故发生1、用户投诉或者拨测发现有呼叫困难。2、从M2000观察 “移动局向入局话务量”话统的

17、结果，确认某些B侧局向或者全部B侧局向接通率出现下降。3、如果M2000无法使用，则收集POOL内任意两个MSC Server的“MSC CSSR话务测量”话统任务的话统结果，该话统是按照B侧局向位对象进行统计的，因此可以从话统结果中确认是全部B侧局向还是部分B侧局向出现了问题（CSSR指标下降）。4、通过对比两个或更多MSC Server的CSSR话统，观察是否某个MSC的全部BSC的接通率指标下降；2.2.2 接通率下降事故的常见原因单BSC/RNC局向接通率下降的常见原因有：1、错误的数据配置2、到BSC局向链路故障3、到BSC局向电路故障4、该BSC局向话务量过高6、其他设备原因MSC

18、 POOL全网接通率下降的常见原因有：1、错误的数据配置2、到STP（HLR、SCP）链路故障，或者链路对端网元故障或过载3、BICC承载面异常导致的局间话务成功率低4、增强流控原因5、License异常6、话单池拥塞7、补丁质量问题8、其他设备原因MSC POOL中单个MSC的全部BSC接通率下降的常见原因有：1、MSC间数据配置不一致；2、该MSC在Mc接口上出现链路拥塞情况；3、MSC内部MTP/SCCP协议层出现DPC状态异常；2.2.3 接通率降低事故恢复和处理2.2.3.1 单BSC/RNC接通率下降问题解决步骤问题解决思路在POOL组网情况下，一旦出现单BSC/RNC接通率下降问

19、题，首先需要确定BSC/RNC局向，然后初步界定出故障的原因、以及发生故障的MSC/MGW网元，然后针对故障原因尝试进行恢复处理；如果在短时间内故障无法恢复、并且故障呈现蔓延之势时，需要针对故障范围采取相应措施避免故障扩散：如果故障集中在某个MSC或某个MGW网元，需要及时隔离出现问题的网元，接着将故障网元的业务转移到正常MSC/MGW网元上；如果故障涉及所有MSC、以及故障局向连接的所有MGW，那么需要考虑采用按接入网局向进行流控，必要情况下需要考虑禁止该故障局向、待故障根因排除后再做恢复。排查是否错误的数据配置导致接通率下降问题确认步骤：1）在MSX3000上，通过LST CMDLOG命令

20、获取近三天的操作日志，排查与该B侧局向相关的数据是否被更改；2）在UMG8900上，使用LST LOG命令获取近3天的操作日志，排查SET/ADD/MOD/RMV等命令的配置是否正确。注意：需设置LST LOG命令的“返回记录数”参数为1000.恢复措施：1）如果有可疑的数据配置被执行，则需要尽快评估相应的数据配置的影响，排除错误的数据配置。排查是否BSC局向链路故障问题确认步骤：1）在M2000上或MSX3000上，查询MSC Server是否出现到B侧网元M3UA链路故障（告警ID：1811）、M3UA链路拥塞（告警ID：1809）、M3UA路由不可用（告警ID：1815）、SCCP禁止（

21、告警ID：2754）等告警；2）在M2000上或UMG8900上，查询MGW是否出现到B侧网元的链路故障（告警ID：3981）、DPC不可达（告警ID：3980）等告警。如果出现以上告警，且告警的目的信令点或局向为B侧网元，则可确定MSC和BSC/RNC之间的链路出现了异常恢复措施1）对于在MSX3000上查询到M3UA链路拥塞、故障以及M3UA路由不可达的情况，需要在MSC Server上使用PING跟踪去确认MSC Server到MGW之间的承载网是否通畅。如果不能PING通，则按承载网故障进行处理。2）如果可以从MSC Server PING通MGW，则需要对故障链路和SCTP链路进行跟

22、踪，将跟踪的结果反馈到研发。3）对于在MGW上查询到的MTP3链路相关告警和N7DSP不可达告警，需要逐个排除下面原因：E1帧滑码；时钟状态；E1端口状态；E1自环测试；排查BSC局向电路故障问题确认步骤：1）在M2000上或UMG8900上，执行MGW的MML命令DSP AIETG，查看指定BSC中继群的A接口电路状态；如果出现大量端点故障，则可以断定出现了电路不可用情况；2）如果指定BSC中继群的80%以上端点处于忙状态，则需要继续使用M2000的“移动局向入局话务量”话统确认忙电路数量与该局向的呼叫话务量是否相符，若该话统的“占用话务量”远小于忙电路数量，则可以断定出现了A接口电路吊死问

23、题。2）在M2000上或MSX3000上，MSC的MML命令DSP OFTK，查看指定BSC局向的A接口电路状态；如果出现大量电路故障，则可以断定出现了电路不可用情况；如果80%以上电路处于忙状态，则需要继续使用M2000的“移动局向入局话务量”话统确认忙电路数量与该局向的呼叫话务量是否相符，若该话统的“占用话务量”远小于忙电路数量，则可以断定出现了A接口电路吊死问题。注：当MGW管理A口电路时，MSC上查询到的A口电路数不包括未安装电路数。恢复措施：1）大量电路/端点电路故障的场景的恢复措施：分析UMG上的历史配置命令，排除误配置；在UMG客户端上使用LST OFCTKC查得A口电路的E1端

24、口位置，然后使用控制面板，观察是否存在E1端口故障的情况；在UMG的客户端使用RST AIETKC命令尝试复位A接口电路；在UMG的客户端使用RMV AIETKC和ADD AIETKC命令对故障电路进行重新配置；2）A接口电路吊死的恢复措施： 注：可以通过检查MGW的日志，来证实A接口电路被吊死。 A）在UMG的客户端使用RST AIETKC命令复位A口电路； B）在UMG的客户端开启24分钟吊死定时器：SET CLRCAL: DUR=24; C）开启反向校验 UMG8900的反向校验配置为6分钟： SET TIMERX: VMGWID=0, TIMER=360, NOTI=ON; MSX30

25、00的反向校验定时器配置为5分钟： MOD MGW: MGWNAME=KAMGW1, TRNST=SCTP, HTDTIMER=300;排查MGW的TC资源是否不足问题确认步骤：1）在UMG8900网元上，出现“媒体资源占用率超过阈值”告警（告警ID：1652），且资源类型为“TC”；2）在UMG8900网元上，出现“单板资源故障”告警（告警ID：1605），且故障资源类型为“TC”；恢复措施：1）对于TC资源占用超阈值的情况，若UMG版本为V200R008C02(SPC118)及其之后版本，则可以开启“免TC功能”；否则临时扩展TC资源单板数量；注： UMG的V200R008C02SPC11

26、8补丁版本，解决了免TC与呼叫等待业务冲突的问题，因此开启免TC功能时，需要设置UMG软参P12bit14为0，软参使用详细说明参见UMG的软参说明书。2）若出现“单板资源故障”告警，则需要考虑更换相应的单板；排除2G应用时MSC上部分模块上BSC的M3DE、SCCPDSP的状态异常问题确认步骤：1）在MSX3000的DeviceAlarm.log中发现有部分特定CCU模块出现类似下面的打印：LEVEL:ERROR SN:838076 M023P157F0S02FM : aim_n_unitdata_ind(): SPC_State is SPC_WAIT_REL, sccp_state of

27、 spc(0x10e7) is 0x1. TIME : 2010-01-26 15:19:00+03:30 SX_PID_AIM以上打印的含义：MSC在向BSC发送消息时，SCCP协议层的DPC状态为Unavailable。2）在MSX3000上使用下面的命令查询指定CCU模块的M3DE、SCCPDSP是否正常：DSP M3DE: MN=22, DENM= BSC_1;DSP M3DE: MN=45, DENM= BSC_1;DSP SCCPDSP: MN=22, DPNM=BSC_1;DSP SCCPDSP: MN=45, DPNM=BSC_1;其中模块号为出现错误打印的CCU模块，BSC名

28、称要填写存在话务量异常的BSC名称；当该BSC的DPC状态为正常，而部分模块的DPC状态为异常时，需要按下面的方法进行恢复；恢复措施1）复位异常单板来恢复；排除3G应用时MSC上的RANAP SCCPSSN的状态异常问题确认步骤：1）在MSX3000上使用下面的命令查询指定RNC的SCCP子系统是否正常：DSP SCCPSSN: MN=22, NI=NATB, SPC=XXX, OPC=YYY, SSN=RANAP;DSP SCCPSSN: MN=45, NI=NATB, SPC=XXX, OPC=YYY, SSN=RANAP;其中XXX是RNC的DPC，OPC为本局与RNC对接的信令点；模块

29、号要遍历所有的CCU模块。如果“子系统状态”为“禁止”，则说明RNC的RANAP SCCP子系统被错误设置。恢复措施1）通过SET SCCPSSN命令修改RANAP的SCCP子系统为“允许”。排除过高话务量原因问题确认步骤：1）在MSX3000上出现了CCU单板的CPU过载告警（告警ID：2049）；2）在MSX3000上获取1天的话统信息，观察“MSC CSSR话务测量”话统任务的话统结果，分析话务量是否有异常升高。恢复措施1）使用局向流控方法对局向进行流控。检查有无错误的流控数据问题确认步骤：1）检查MSX3000网元的告警，查找是否产生了流控告警（告警ID：4644）2）检查单业务销峰流

30、控配置 在MSX3000客户端使用LST SRVCFG命令查询业务流控的配置；MSX3000的P94BIT8软参为0，表示增强流控功能开启；系统缺省是启动的，不需要修改。 MSX3000的P94BIT10软参为0，表示单业务销峰流控功能开启；系统缺省是启动的，不需要修改。 3）检查多业务销峰流控配置 在MSX3000的客户端，使用LST FCCFG查询多业务销峰流控配置，确认“多业务最大CPU值”为100即可。100为默认值，小于100表明数据配置有误。恢复措施1）当出现单业务销峰流控告警时，根据告警中的信息查询并修正单业务销峰流控数据；2）当多业务销峰流控配置错误时，将多业务流控的配置恢复为

31、缺省值，“多业务最大CPU值”恢复为100。排除其他设备原因问题确认步骤：1）在MSX3000上出现了BSC/RNC过载告警（告警ID：2505、2558），且告警原因为“B侧CPU过载”；2）在M2000上查询MSC POOL的“BSC局向指配测量”和“RNC局向指配测量”话统结果，观察BSC/RNC的指配成功率是否答复下降。3）在M2000上查询MSCPOOL的“寻呼测量”话统结果，分析是否指定BSC/RNC局向的寻呼成功率大幅下降。恢复措施1）对于BSC/RNC过载告警的情况，使用局向流控方法对局向进行流控。2）对于B侧指配成功率大幅下降的情况，需要协调B侧厂商进行分析。3）对于寻呼成功

32、率大幅下降的情况，需要关闭全网寻呼软参（MSX3000的P1151BIT1软参设置为1），调整MSX3000寻呼控制表中的数据（MOD PGCTRL），关闭寻呼控制表中的全网寻呼配置，修改寻呼为一次IMSI寻呼且寻呼间隔设置为7-8秒。之后协调B侧厂商进行分析。短时间内故障无法恢复短时间内故障无法恢复时，需要及时考虑对故障进行隔离、避免故障扩散。如果故障集中在某个MSC，需要及时隔离出现问题的MSC，将故障网元的业务转移到正常MSC；如果故障集中在某个MGW，需要及时隔离出现问题的MGW，接着将故障网元的业务转移到正常MGW；如果故障涉及所有MSC、以及故障局向连接的所有MGW，那么需要考虑采

33、用按接入网局向进行业务流控限制该局向移动始发业务量，必要情况下需要考虑禁止该故障局向、待故障根因排除后再做恢复。2.2.3.2 MSCPOOL全网接通率下降问题解决步骤问题解决思路在POOL组网情况下，一旦出现全网接通率下降的故障，首先需要判断是承载网故障还是NNSF业务分发机制出现故障。当MSC出现某些特定接口的链路拥塞时（如到STP、HLR或者SCP），可能会表现为CD口取路由失败/取漫游号码失败、CAP口智能IDP触发失败，需要先排除对这些链路的误配置以及对端设备故障的原因。IP承载网故障发生时，根据故障承载网影响的MSC接口不同，可能会出现A接口业务交互消息出现超时现象、M3UA链路出

34、现大量重传现象、M3UA和H248链路出现拥塞等等；因此，如果从话统结果或拨测消息跟踪观察出失败集中在上述这些场景，那么可以初步怀疑承载网发生故障。如果从拨测消息跟踪中，观察到非常异常的A接口消息流程（比如：收到首条A接口上行消息后、下发了多条A接口下行消息，但一直没有收到第二条A接口上行消息），那么可以初步怀疑为NNSF分发异常。排查是否错误的数据配置导致接通率下降问题确认步骤：1）在每一个MSX3000上，通过LST CMDLOG命令获取近三天的操作日志，排查是否有异常的ADD/MOD/RMV数据配置被更改；恢复措施：1）如果有可疑的数据配置被执行，则需要尽快评估相应的数据配置的影响，排除

35、错误的数据配置。承载网故障导致的MGW退服问题确认步骤：1）在M2000上或MSX3000上，出现MGW退服的告警（告警ID：1522）恢复措施：1）按MGW退服进行处理和恢复Mc口H248链路故障或拥塞问题确认步骤：1）在M2000上或MSX3000上，出现“H248 SCTP链路传输质量故障”告警（告警ID：1457）；2）在M2000上或MSX3000上，出现“H.248 SCTP链路拥塞”告警（告警ID：1455）；3）在M2000上或MSX3000上，出现“H.248 SCTP链路故障”告警（告警ID：1453）；4）在M2000上或MSX3000上，出现“H.248 SCTP链路负

36、荷过载”告警（告警ID：1546）；5）在MSC上，使用Ping跟踪对出现拥塞或故障的H248链路的目的地址进行PING，观察通断情况、丢包率和时延。恢复措施：1）若出现Mc接口Ping跟踪中断、丢包率大于1%、时延大于100ms，则可以断定承载网出现了故障，需要按IP承载网故障应急手册处理。2）按“信令处理板过载及链路拥塞”进行处理和恢复排除POOL内各MSC之间BICC CIC不足引起的接通率下降注：POOL改造后，较多局内呼叫转变为POOL内局间BICC呼叫，会对BICC CIC的数量要求会增加。问题确认步骤：1）任选POOL中的两个MSC Server，在MSX3000的客户端使用DS

37、P BICCOFC命令查询POOL内MSC之间BICC占用情况，如果出现占用率超过80%的情况，则可以怀疑出现了BICC CIC资源不足的情况；2）任选POOL中的两个MSC Server，获取“BICC中继局向出局话务测量”话统任务的结果，分析忙时“占用话务量”指标与“可用电路数”指标的关系，如果出现占用话务量指标较大的情况，则说明出现了BICC CIC不足问题。3）如果BICC CIC出现大比例的闭塞、故障、未安装等异常状态，也可能导致CIC不足而影响接通率；恢复措施：1）对于BICC CIC不足的情况，需要在MSX3000上通过ADD BICCCICMDU为POOL内的MSC之间增加CI

38、C配置。2）对于大量BICC CIC状态异常的情况，先使用复位命令进行恢复，若仍不成功则删除后重新增加；排除POOL内NNSF功能分发错误引起的接通率下降对于MSCPOOL的NNSF业务分发功能，原理是根据TMSI找到NRI，根据NRI找到CN-ID，根据CN-ID找到MTP(M3UA)路由进行消息路由，根据CN-ID之间的容量比例和MSC的状态进行分发。因此当POOL全网接通率下降时，需要确认分发数据配置是否有误。具体检查方法，见2.4.3节的“检查NNSF功能上各CN-ID的容量配置和POOL维护状态是否被错误更改”、“检查NNSF功能上各CN-ID与NRI的映射关系是否遗漏或错误”和“检

39、查NRI长度配置错误和NRI值冲突问题”。POOL内各MSC的BICC中继群配置不完整时导致话路迂回占用额外IP承载网带宽导致接通率下降一般的，在POOL内一个MSC到其他MSC之间的BICC中继群数量要与MSC下的MGW数量一致，若配置遗漏则会导致话路迂回耗费额外的MGW间IP承载带宽，严重时造成IP承载网拥塞以及MGW上的HBR单板过载。问题确认步骤：1）通过LST MGW和LST BICCTG来判断MSC到POOL内其他MSC之间配置的BICCTG数量，若某个MSC局向下并非每个网关都配置了BICCTG，则可以确定数据配置遗漏。恢复措施：1）MSC上增加BICCTG数据配置，使得MSC到

40、POOL内的任一其他MSC的BICC局向下BICCTG的数量与MGW的数量一致。跨区域POOL组网时区域间IP承载网带宽不足导致接通率下降如果区域间的用户交往不太紧密，跨区域POOL组网后，区域间长途承载网带宽的需求量会大量增加。典型的，对于标准话务模型下区域间长途呼叫比例为10%的组网情况，组POOL后长途承载网带宽（信令面和用户面总和）需求量会增加30%至40%。问题确认步骤：1）通过MSX3000的“BICC局向SCTP链路测量”话统结果，观察是否跨区域MSC间BICC局向的统计结果中出现大量“拥塞次数”被统计。恢复措施：1）对于跨区域MSC POOL组网时，区域间长途IP承载网带宽不足

41、的情况，可以使用用户迁移方法，将各区域的用户迁移回本地Server，以此减少区域间信令带宽需求。2.3 信令处理板过载及链路拥塞中断问题2.3.1 MSX3000的信令处理板过载和链路拥塞中断问题2.3.1.1 如何判断出现信令处理板过载和链路拥塞和中断事故出现以下告警： 单板CPU过载告警（ALM-2049），且单板类型为WBSG 链路拥塞告警（MTP缓冲区拥塞ALM-1707、M3UA链路拥塞ALM-1809） 链路负荷过载告警（MTP链路负荷发送过载ALM-1715、MTP链路负荷接收过载ALM-1717、M3UA链路负荷过载ALM-1831、M2UA链路负荷过载ALM-1801、H.2

42、48 SCTP链路负荷过载ALM-1546） 链路故障告警（MTP链路故障ALM-1705、M3UA链路故障ALM-1811、M2UA链路故障ALM-1801）2.3.1.2 信令处理板过载和链路拥塞中断的常见原因信令处理板（BSG、IFM）出现CPU过载告警（ALM-2049）时， 首先查看该单板上的链路是否出现过载告警或者拥塞告警； 如果没有链路过载或拥塞告警，则可能是某些模块业务处理过多导致CPU过载； SCON管理消息广播导致；2.3.1.4 信令处理板过载的解决方法排除信令处理板负载不均衡问题问题确认步骤：1）在MSC上分析CPU占有率话统结果，存在BSG模块之间的负载差距明显，超过

43、10%。2）在MSC上分析“SCTP负荷话统”结果，各BSC模块之间收发各类协议数据块的数量差距明显，差距在50%以上；恢复措施：1）将配置链路较多的BSG模块上的链路均衡配置到其他BSG模块上。排除大话务量导致的信令处理板过载问题问题确认步骤：1）无链路过载告警，信令处理板BSG过载，且存在CCU模块的CPU超过70%。恢复措施：1）开启局向流控功能。排除SCON管理消息广播导致的问题问题确认步骤：1）通过MSX3000的“M3UA信令链路话务测量”或“M3UA信令链路集话务测量”话统结果，观察是否“发送控制消息个数”或“接收控制消息个数”统计本体的值是否异常升高。注：一般来说，SCON消息

44、仅在0号链路上发送；恢复措施：1）对于出现SCON消息广播导致的信令处理板过载问题，需要通过下面两种办法恢复： A）在MSC上临时去激活该M3DE的所有链路，然后再重新激活； B）使用流控方法降低业务流量；2.3.1.5 信令链路拥塞或故障的解决方法排除MGW的大包缓冲区设置过小问题问题确认步骤：1）在MGW的客户端使用LST SCTPINIT命令查询“超大缓存个数”参数的值，如果存在超大缓存个数值小于10的情况，则需要进行修改。恢复措施：1）将PPU单板的SET SCTPINIT命令设置为默认值（24），在业务量小的情况下，逐块复位PPU单板。注意：请按照UMG发布的预警关于UMG8900产

45、品设置SET SCTPINIT命令中超大缓存个数过小导致MGC侧H248链路拥塞问题预警通知进行整改。排除SCON管理消息广播导致的问题问题确认步骤：1）通过MSX3000的“M3UA信令链路话务测量”或“M3UA信令链路集话务测量”话统结果，观察是否“发送控制消息个数”或“接收控制消息个数”统计本体的值是否异常升高。注：一般来说，SCON消息仅在0号链路上发送；恢复措施：1）对于出现SCON消息广播导致的信令处理板过载问题，需要通过下面两种办法恢复： A）临时去激活该M3DE的所有链路，然后再重新激活； B）使用流控方法降低业务流量；打开SCTP交叉路径消息包接收功能问题确认步骤：1）判断存

46、在SCTP路径交叉的方法：待补充；恢复措施：1）与E/对接时要开启SCTP交叉路径消息包接收功能。见MSC Server的P42BIT2和BIT3。SCTP快速重传优化当业务流量超出链路带宽等原因造成网络出现拥塞时，SCTP会进行快速重传，从而又加剧网络拥塞，最极端的情况下会引起拥塞崩溃。在MSX3000的R005C10及其后版本对SCTP快速重传进行了优化，可以缓解SCTP消息重传导致的拥塞雪崩问题。当出现SCTP链路拥塞时，可以开启SCTP快速重传优化功能。见MSC Server的P42BIT5软参。排除卫星链路的问题问题确认步骤：1）如果是通过UMG转接M2UA和卫星链路，让UMG考虑通过命令SET MTP2LNKPARA修改MTP2N2等参数的值，以提高链路发送负荷。信令处理板隔离出现故障的MGW的H248链路和M3UA链路配置到单独的一块BSG单板上。2.3.2 UMG8900的信令处理板过载和链路拥塞中断问题2.3.2.1