论文部分内容阅读
【摘要】本文介绍了交换机组POOL前后寻呼过程的差异，详细分析了组POOL后IMSI寻呼失败的原因，并提出了解决方法，对组POOL后网络质量分析优化、日常维护具有指导意义。
【关键词】POOL寻呼
一、前言
交换机组成MSCPOOL后，业务流程和日常维护均发生变化，可能会出现新的网络问题亟待运营商解决，在网络维护和分析优化方面也需要不断积累经验。下面以网络中出现的“华为交换机MSCPOOL IMSI寻呼失败”为例，介绍组POOL前后寻呼流程差异，及解决方案。
二、问题描述
在华为MSC POOL内，用户登记在MSC1，用户做被叫时MSC1下发寻呼后，用户的寻呼响应消息被送到了POOL内另一台交换机MSC2，MSC2判断无用户数据后发起隐式位置更新，该用户后续在MSC2上的业务正常，但本次呼叫将被释放。
三、问题分析
不管MSC是否组POOL，寻呼策略一般都是进行多次寻呼，前面几次使用TMSI进行寻呼，最后一次使用IMSI，但由于MSC Pool覆盖区域较大，Pool要求不能开启全网寻呼。MSC组POOL后寻呼流程如下图所示：
（1）TMSI寻呼：MSC1使用TMSI下发寻呼，寻呼消息经过媒体网关MGW1，BSC1在寻呼响应消息中携带TMSI并将PAGE Response消息发送给MGW2或者MGW1，MGW1或者MGW2根据TMSI中的NRI将PAGE Response发送给MSC1。（2）IMSI寻呼：MSC1使用IMSI下发寻呼，寻呼消息经过MGW1，同时MSC1将IMSI和MSC1的对应关系发送给与BSC1相连的MGW2，MGW1/MGW2根据用户IMSI和MSC1的对应关系将寻呼响应消息发送给MSC1。
通过信令监测系统查询发现，此类问题集中在IMSI寻呼的情况下，寻呼消息通过MGW1下发，寻呼响应消息通过MGW2上报，但是MSC1并没有收到寻呼响应消息。
根据组POOL后的IMSI寻呼流程，考虑到可能是由于MGW2没有获取到MSC1下发的IMSI和MSC Server对应关系而导致的。
当MSC Server将IMSI寻呼消息或者寻呼广播消息发给媒体网关MGW后，MGW会保存IMSI和MSC Server的对应关系，保存最大时长为10S。MSC POOL组网下各媒体网关之间不会对IMSI与MSC Server的对应关系进行校验和同步，各媒体网关所记录的IMSI与MSC Server的对应关系的一致性依赖于MSC Server广播消息中的信息。
华为媒体网关中的IMSI+MSC对应关系默认保存10s，最多保存2048条记录。如果2048条记录已满，再收到新的对应关系，会将最早的对应关系删除。当无线侧的寻呼响应消息分发到MGW后，MGW会根据记录的MSC Server与IMSI的对应关系将寻呼响应路由到对应MSC Server。
通过抓取大量的消息包观察，在某些情况下，华为MSC Server下发IMSI寻呼时，未将IMSI与MSC Server的对应关系发送至另外一台MGW中，导致MGW无用户IMSI与MSC Server对应关系，导致用户的寻呼响应消息被分发至其他Server。
经确认，当用户处于业务态即连接未释放时，交换机对该用户下发IMSI寻呼时存在漏洞，此时交换机没有将IMSI及MSC Server的对应关系下发给另外一台MGW，导致该MGW无法正常分发IMSI寻呼响应消息。
四、问题解决方案
针对该漏洞，华为公司已开发补丁，可彻底解决。
在补丁装载前，可采取以下措施：（1）现网中尽量采用TMSI进行寻呼，如网络中存在仅响应IMSI寻呼的终端（不符合规范），可以将IMSI寻呼配置在最后一次寻呼。（2）可以通过“MSC基本表测量话统”中“不是从本局Paging但Paging Response回复到本局的数目（次）”统计此种情况的次数，若该指标出现大幅度增加，且确认是由于MGW分发错误导致寻呼失败，可以在MSC Server上将寻呼控制策略调整为每次都使用TMSI下发寻呼。
五、经验总结
从2G到3G，到IMS，再到LTE，移动通信技术以飞快的速度发展和演进，给用户带来更快速、更丰富的业务体验，同时，也会产生我们没有预见的新的问题，设备也可能存在缺陷。因此，从事移动通信的技术人员，需要及时掌握新的技术、新的网络架构，深入研究新的业务流程和设备处理机制，这样才能有效解决新问题，并从中积累丰富的经验，进一步优化完善网络质量，屏蔽漏洞，提升客户感知。
【关键词】POOL寻呼
一、前言
交换机组成MSCPOOL后，业务流程和日常维护均发生变化，可能会出现新的网络问题亟待运营商解决，在网络维护和分析优化方面也需要不断积累经验。下面以网络中出现的“华为交换机MSCPOOL IMSI寻呼失败”为例，介绍组POOL前后寻呼流程差异，及解决方案。
二、问题描述
在华为MSC POOL内，用户登记在MSC1，用户做被叫时MSC1下发寻呼后，用户的寻呼响应消息被送到了POOL内另一台交换机MSC2，MSC2判断无用户数据后发起隐式位置更新，该用户后续在MSC2上的业务正常，但本次呼叫将被释放。
三、问题分析
不管MSC是否组POOL，寻呼策略一般都是进行多次寻呼，前面几次使用TMSI进行寻呼，最后一次使用IMSI，但由于MSC Pool覆盖区域较大，Pool要求不能开启全网寻呼。MSC组POOL后寻呼流程如下图所示：
（1）TMSI寻呼：MSC1使用TMSI下发寻呼，寻呼消息经过媒体网关MGW1，BSC1在寻呼响应消息中携带TMSI并将PAGE Response消息发送给MGW2或者MGW1，MGW1或者MGW2根据TMSI中的NRI将PAGE Response发送给MSC1。（2）IMSI寻呼：MSC1使用IMSI下发寻呼，寻呼消息经过MGW1，同时MSC1将IMSI和MSC1的对应关系发送给与BSC1相连的MGW2，MGW1/MGW2根据用户IMSI和MSC1的对应关系将寻呼响应消息发送给MSC1。
通过信令监测系统查询发现，此类问题集中在IMSI寻呼的情况下，寻呼消息通过MGW1下发，寻呼响应消息通过MGW2上报，但是MSC1并没有收到寻呼响应消息。
根据组POOL后的IMSI寻呼流程，考虑到可能是由于MGW2没有获取到MSC1下发的IMSI和MSC Server对应关系而导致的。
当MSC Server将IMSI寻呼消息或者寻呼广播消息发给媒体网关MGW后，MGW会保存IMSI和MSC Server的对应关系，保存最大时长为10S。MSC POOL组网下各媒体网关之间不会对IMSI与MSC Server的对应关系进行校验和同步，各媒体网关所记录的IMSI与MSC Server的对应关系的一致性依赖于MSC Server广播消息中的信息。
华为媒体网关中的IMSI+MSC对应关系默认保存10s，最多保存2048条记录。如果2048条记录已满，再收到新的对应关系，会将最早的对应关系删除。当无线侧的寻呼响应消息分发到MGW后，MGW会根据记录的MSC Server与IMSI的对应关系将寻呼响应路由到对应MSC Server。
通过抓取大量的消息包观察，在某些情况下，华为MSC Server下发IMSI寻呼时，未将IMSI与MSC Server的对应关系发送至另外一台MGW中，导致MGW无用户IMSI与MSC Server对应关系，导致用户的寻呼响应消息被分发至其他Server。
经确认，当用户处于业务态即连接未释放时，交换机对该用户下发IMSI寻呼时存在漏洞，此时交换机没有将IMSI及MSC Server的对应关系下发给另外一台MGW，导致该MGW无法正常分发IMSI寻呼响应消息。
四、问题解决方案
针对该漏洞，华为公司已开发补丁，可彻底解决。
在补丁装载前，可采取以下措施：（1）现网中尽量采用TMSI进行寻呼，如网络中存在仅响应IMSI寻呼的终端（不符合规范），可以将IMSI寻呼配置在最后一次寻呼。（2）可以通过“MSC基本表测量话统”中“不是从本局Paging但Paging Response回复到本局的数目（次）”统计此种情况的次数，若该指标出现大幅度增加，且确认是由于MGW分发错误导致寻呼失败，可以在MSC Server上将寻呼控制策略调整为每次都使用TMSI下发寻呼。
五、经验总结
从2G到3G，到IMS，再到LTE，移动通信技术以飞快的速度发展和演进，给用户带来更快速、更丰富的业务体验，同时，也会产生我们没有预见的新的问题，设备也可能存在缺陷。因此，从事移动通信的技术人员，需要及时掌握新的技术、新的网络架构，深入研究新的业务流程和设备处理机制，这样才能有效解决新问题，并从中积累丰富的经验，进一步优化完善网络质量，屏蔽漏洞，提升客户感知。