華為交換機MSCPOOL IMSI尋呼問題分析

【摘要】本文介紹了交換機組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，移動通信技術以飛快的速度發展和演進，給用戶帶來更快速、更豐富的業務體驗，同時，也會產生我們沒有預見的新的問題，設備也可能存在缺陷。因此，從事移動通信的技術人員，需要及時掌握新的技術、新的網絡架構，深入研究新的業務流程和設備處理機制，這樣才能有效解決新問題，并從中積累豐富的經驗，進一步優化完善網絡質量，屏蔽漏洞，提升客戶感知。