文档名称 文档密级：
3 MSC POOL失效场景及应对措施
3.1 被叫恢复流程失效
1、 判断备份方式的主备关系及备份组网：
1) 直接向客户/一线维护人员获取当前的组网信息；
2) 通过LST POOLBKPRT查询各Server的备份路由配置，分析得到Server间当前
配置的备份关系；
2、 根据备份关系进行数据检查， 看主用MSC SERVER和备用MSC SERVER上是否
都已经正确进行了备份数据配置：
1) LST POOLBKPCTRL查看备份局是否打开备份开关、备份MSC的个数是否正
确、备份的定时周期是否正确
2) LST POOLBKPRT查看用于备份的M3UA路由是否已经配置
3) DSP M3DE/M3LNK等命令查看用于备份的路由以及链路是否可达， 也可以
通过告警查看
4) 在备份局上查询备份运行状态：DSP BKPSTATUS
3、 在备份局LST INOFFMSC，检查是否配置了主用局的MSC NO。如果配置了，那
么当主用MSC SERVER故障，备用局收到来自HLR的PRN消息， 就会根据MSC NO认为此消息应该由本局处理， 进行RESTORE流程，而不会发送PAGING消息给接入侧，导致被叫恢复流程异常，特别在集中备份方式下，被叫不能恢复。 4、 检查与周边网元(HLR/STP)的配置是否正确：
1) 检查备份MSC在主用局故障后能否收到PRN消息
在备用局上打开一个原主用局下用户的用户跟踪，呼叫该用户，观察是否收到HLR发送的PRN在主用MSC故障时， 能否把消息路由到备份MSC。 2) 检查HLR/STP到MSC的数据配置
在HLR/STP上可以通过SCCP负荷分担方式和MTP3的路由优先级两种方式的配置。检查HLR/STP到MSC和备份配置是否正确。 3) 检查MSC的配置是否正确
到MSC到周边网元（HLR/STP）的MTP3层数据、SCCPGT数据是否都已经
2014-11-26
华为机密，未经许可不得扩散
第33页, 共47页
文档名称 文档密级：
配置。 链路是否可达。
5、 检查备用局到BSC的数据是否都正常。包括MTP3的链路、路由数据，SCCPDSP,
SCCPSSN及运行状态否都正确。 如果到BSC配置错误，会导致备用局下发的PAGING消息发送不到B侧，被叫恢复流程失效。
3.2 MSC POOL负荷分担功能失效
1、 可以在M2000上通过实时监控来检测各MSC的CPU负荷情况，同时也可以通过查
看告警得到负荷是否不均。同时也可以在MGW上进行统计测量按照CN 节点为单位统计的SCCP消息处理情况来检查
2、 出现不均衡，在M2000上进行数据比较，看各MGW上的分发参数是否都一致：
1) CN ID与NRI的对应关系是否相同；针对CN ID对应的MSC标识， 需要MGW
与MSC SERVER保持一致。(MSX3000: SET POOLINFO命令中的参数：MSCIDX； MGW: ADD CNNODE命令中的MSCIDX)
2) 各MSC SERVER的可用容量设置是否正确，且在各MGW上是否配置一致； 3) CN节点状态是否设置正确，且各个MGW上的配置是否一致。如果CN节点设
置为“卸载”或者“禁止”，那么MGW就不会把业务分发到此节点 4) Iu/A-flex功能是否激活
3、 以上第2点无问题，或者问题纠正之后，可以通过用户迁移的方法来调整不同MSC
间的负荷
4、 采用MGW代理NNSF时，可以通过在MSC上使用SET POOLBC:;命令，定时把各
个MSC的负荷广播给所有MGW，用于MGW动态调整分发比例，保持POOL中各MSC的负荷均衡
3.3 MGW间的承载负荷过高
MSC POOL下，POOL内MGW间的承载建议为IP承载，否则会造成承载面的极大冗余以及组网异常复杂。 如果在这种情况下，还是发现IP承载网出现拥塞，可能原因如下：
1、 网络话务较高，超过设计的容量， 这点可以从POOL的整体话统指标进行观测，
也可以按MSC进行KPI指标的观察分析
2014-11-26
华为机密，未经许可不得扩散
第34页, 共47页
文档名称 文档密级：
2、 网络设计的IP承载带宽与实际的话务模型不匹配 3、 承载网故障，包括MGW的端口拥塞，IP承载网故拥塞
4、 跨网关呼叫没有优化处理 检查一下各个MSC SERVER上， 对于连接的同一物理
MGW， 其ADD MGW配置中的BCU ID是否一致。如果不一致，那么就有可能导致出现本来不需要跨网关的呼叫跨接了两个网关，如下图，从BSC1到BSC2的呼叫，可能就会途径VMG2与VMG3这段IP承载了，而实际上是可以在VMG1和VMG2间自环的：
MSC1MSC2VMGW1VMG2VMG3BSC1BSC2 5、 针对第1、2、3点出现的IP承载网拥塞，可以考虑通过以下方式进行处理：
1) 在MSC SERVER上打开IP QOS流控软参(P353 bit2置为1)，通过流控来保证IP
承载网的可用性。 问题解决后(承载故障恢复、承载网扩容)，把流控开关关闭。
注：IP QOS流控虽然测试过，但是在网上还未有实际应用，属未发布特性。 2) 通过多业务削峰来降低业务接入量，从而降低承载网络的负荷。但是使用这
种方法，会使所有类型的呼叫都受流控影响，包括不跨网关的呼叫。 3) 如果是全局性的拥塞， 那么可以闭塞各个BICC局向上一定比例的CIC来减
轻承载网的负荷
4) 如果只是某两个MGW之间的IP承载出现拥塞，如果采用闭塞局间BICC CIC
的方法，因为所有MGW是与所有MSC SERVER相连的，且所有BICC局向都需要包含所有的MGW， 因此就需要闭塞POOL内所有BICC局向的CIC来进行控制。这样不仅影响的是出现承载拥塞的两个MGW， 还影响到其他的MGW间的呼叫。
2014-11-26
华为机密，未经许可不得扩散
第35页, 共47页
文档名称 文档密级：
对于这种场景，可以考虑使用如下方法：在POOL内的所有MSC间的BICC局向上， 使用RMV BICCTG，把存在IP拥塞的MGW对中的一个MGW从局向上删除， 通过迂回的方法来减轻MGW间的负荷， 作此操作前需要衡量下其他迂回路径的负荷情况。
3.4 切换问题
用户在POOL内的切换都是局内切换， 与POOL外的MSC存在局间切换关系。 目前的组网配置是，POOL内的MSC需要与POOL外的所有存在切换关系MSC设置数据，即POOL内MSC SERVER的切换数据应该是一致的。如果出现POOL内某个MSC SER切换成功率低， 那么需要检查下其数据配置是否存在问题。
对于POOL外的MSC(MSC SERVER1)， 针对POOL内某一相邻位置区(LAI1)， 一般只配置POOL内的一个MSC(MSC SERVER2)为切换MSC， 即POOL外的MSC SERVER1向POOL内此LAI1切换，只可能切换到MSC SERVER2进行处理。 这样如果MSC SERVER2存在故障， 那么MSC SERVER1到LAI1的切换将全部失败。此时需要在MSC SERVER1上更改切换的数据配置为POOL内其他的MSC SERVER。 对于华为MSC SERVER， 可以在配置相邻LAI时，对应到POOL内两个MSC，进行负荷分担处理，当其中一个相邻MSC故障， 那么就会有50％的切换损失。
3.5 漫游出POOL用户的失效
POOL配置中，要求所有MSC SERVER都配置为default MSC，即配置上所有NRI-MSC的对应关系。当出现漫游用户呼叫问题的时候， 可以检查下对应的default MSC上的数据是否配全，也可以在default MSC上启动消息跟踪进行定位。
3.6 呼损的处理
出现呼损，需要先确定是整个POOL网络的问题还是单个网元的问题： 1、 通过M2000上定制的POOL全局话统指标可以观察整个POOL网络的KPI指标 2、 通过在M2000上按MSC查询方式，观察POOL内各个MSC的指标，看是否部分
MSC呼损更加明显
2014-11-26
华为机密，未经许可不得扩散 第36页, 共47页