李延東
(中國移動通信集團設計院有限公司河北分公司 石家莊 050021)
隨著全業務時代的到來,作為利潤重點的集團客戶,已成為運營商爭奪的焦點。統一Centrex基于IMS網絡,能夠為集團客戶量身打造各種綜合業務,是運營商發展集團客戶的重要平臺。現有的組網方式中,統一Centrex通過虛擬專用移動網(VPMN,Virtual Private Mobile Network)的智能網方式實現IMS域和CS域的業務互通能力。這使得業務平臺組網變得復雜,并造成智能網投入的增加。
在智能終端上增強業務處理能力,將一部分業務功能推向網絡的末端,可有效化解通信網絡的復雜性,并簡化業務流程。
統一Centrex是虛擬用戶交換機業務在IMS網絡上的實現,提供全業務運營的綜合業務。群內短號呼叫是其主要業務之一,集團用戶可制定內部Centrex短號碼方案,以便記憶和管理,短號碼可以唯一標識一個集團成員。
統一Centrex覆蓋IMS和CS域用戶時,現有的組網架構包括兩個相對獨立的部分。一是由統一Centrex AS、IMS核心網、IMS用戶終端組成的IMS網絡;另一個是由實現VPMN業務的智能網SCP、CS域核心網、手機終端組成的CS域網絡。兩個部分由互通網元連接。圖1描述其組網架構。

圖1 現有統一Centrex組網架構圖
當手機撥打IMS終端的群內短號呼叫時,MSC Server根據A簽約的O_CSI信息,通過CAP消息觸發到VPMN SCP,將被叫短號翻譯成長號,再經MSC Server和MGCF呼叫至IMS網絡;S-CSCF查詢iFC規則觸發到統一Centrex AS,AS執行業務邏輯,決定來電顯示為主叫長號或短號,最后由S-CSCF路由到被叫終端。
在IMS終端撥打手機的群內短號呼叫時,由S-CSCF根據A的iFC規則觸發到Centrex AS,被叫短號翻譯成長號再送回S-CSCF;經MGCF路由到MSC Server后,根據被叫T_CSI觸發到SCP,決定來電顯示為主叫長號或短號,最后由MSC Server呼叫至被叫手機。
由以上流程分析可知,在手機主叫時,VPMN SCP的主要操作是長短號翻譯,以便MSC作進一步的路由尋址,而在手機被叫時,VPMN SCP則根據業務設置決定終端顯示長號或短號。與此相配合,附著VPMN SCP的MSC必須獲取HLR中的智能網簽約信息,以便執行業務觸發,將到來的呼叫信令轉接到VPMN SCP上去,并承接回應信令。在IMS網絡側,Centrex AS與IMS核心網存在與此類似的業務觸發過程,但采用的業務觸發機制不同。
除上述組網架構外,現有的另一種方式是將VPMN與Centrex AS合并部署為一個平臺,其它網元沒有變化,其業務機制以及信令流程與上述方式相同。
近年來,通信終端智能化已成為一種趨勢,具有代表性的智能手機已占有大比例的市場份額,而且其功能越來越強大,symbian、android等手機操作系統已經能夠支持諸多應用軟件,App Store、MMarket的商業模式預示著終端能力開發的潛力與前景。
手機終端能力的增強,為分擔通信網絡的業務邏輯處理壓力提供了條件。所需要做的包括手機終端軟件的開發以及與網絡的數據的交互和協同。
基于對VPMN SCP處理機制的分析,可以將長短號翻譯、查詢和顯示的功能外推到手機終端軟件上,同時包括一套以長短號映射表為主的通訊錄的數據管理。軟件的開發基于J2ME及特定品牌手機的專用開發工具,當前主流開發語言為C/C++或Java,并需要手機廠家軟件開發工具包(SDK,Software Development Kit)的支持。
終端軟件的邏輯架構如圖2所示。

圖2 終端軟件的邏輯架構圖
事件捕獲模塊在軟件處于開啟運行狀態時,隨時監視手機終端上發生的動作,例如用戶在手機上撥號、來電到達等事件,然后獲取相關參數,例如號碼等,再傳送給業務處理模塊。
業務處理模塊接受捕獲到的事件參數,對號碼進行分析并調用通訊錄作比對,再向終端操作模塊發出指令。
終端操作模塊執行指令,例如在手機上顯示長號或短號,或顯示呼叫對方的名稱及信息等。
通訊錄主要包含了該手機用戶所屬群的群內成員信息,例如長號和短號的對應關系。
通訊錄管理模塊維護通訊錄,并定期或不定期的與通信網絡交互,以保持群內成員間通訊錄的更新和數據同步。
在一部分業務處理功能從網絡中移走之后,即節省了智能網網元。由于數據查詢及同步的需要,在統一Centrex AS平臺中增加一套完整的通訊錄及管理模塊,并作為統一Centrex業務數據中心,為手機終端通訊錄提供參照。在網絡中的組網架構如圖3所示。
在開展業務前,需在智能手機上安裝運行統一Centrex的終端軟件,并完成通訊錄數據更新;HLR上需要為Centrex用戶啟用新的補充業務代碼SS_CODE,并且支持在位置更新時將SS_CODE同步到拜訪MSC Server中的VLR上。由于并未對IMS終端作改動,對于IMS側的業務流程基本無變化。

圖3 統一Centrex組網架構圖
2.2.1 手機撥打IMS終端的群內短號呼叫
(1)手機撥IMS終端的短號,觸發終端軟件,翻譯為長號碼,發起呼叫,送到MSC Server;
(2)MSC Server根據從主叫歸屬HLR獲取簽約信息SS_CODE,作業務觸發,通過BICC或ISUP信令將呼叫轉發至關口局,再送到MGCF。IAM消息中主被叫號碼為長號;
(3)MGCF把呼叫路由到IMS域的S-CSCF,將信令映射為SIP格式,發起Invite消息,P_Asserted_Identity及RequestURI均為主被叫的長號;
(4)S-CSCF根據從被叫歸屬的HSS得到的iFC規則,發現被叫是統一Centrex簽約用戶,于是改變SIP uri方向,觸發到統一Centrex AS業務平臺;其中,Centrex AS地址由iFC指定;
(5)統一Centrex AS處理被叫業務,如果被叫設置顯示主叫短號,AS查詢在平臺中存儲的通訊錄,發送給S-CSCF的Invite消息中P-Asserted-Identity頭域為主叫長號,From頭域為主叫短號,RequestURI為被叫長號。如果被叫用戶設置顯示主叫長號,則Invite消息中P-Asserted-Identity和From頭域均為主叫長號;
(6)S-CSCF路由Invite到被叫用戶,被叫終端根據From頭域信息顯示主叫號碼。
2.2.2 IMS終端撥打手機的群內短號呼叫
(1)IMS用 戶 撥 手 機 用戶的短號碼,Invite消息到達S-CSCF,P-Asserted-Identity頭域和From頭域是主叫長號碼,RequestURI為被叫短號;
(2)S-CSCF根據從主叫HSS中得到的iFC規則觸發到Centrex AS;
(3)Centrex AS把被叫短號翻譯為長號,改寫Invite消息并送回S-CSCF,Invite消息中被叫號碼RequestURI改為被叫用戶長號;
(4)S-CSCF發現被叫為CS域用戶,將呼叫路由到MGCF,轉發Invite;
(5)MGCF將SIP消息映射為BICC或ISUP信令,IAM消息中主被叫號碼為長號,呼叫被路由到關口局,再轉發到MSC Server;
(6)網絡尋呼到被叫手機終端,終端軟件根據用戶設置作本機處理,顯示主叫長號或短號。
2.2.3 移動終端間的群內短號呼叫
主叫撥被叫移動終端的短號,觸發終端軟件,翻譯為長號碼,發起呼叫,送到MSC Server。MSC Server發現被叫為CS域用戶,直接呼叫本地用戶或通過其它MSC Server呼叫異地長途用戶。
2.2.4 IMS終端間的群內短號呼叫
IMS用戶撥IMS被叫用戶的短號碼,業務機制遵循統一Centrex AS現有方式及IMS標準流程。

圖5 IMS終端撥打手機流程
統一Centrex的架構發生變化后,一部分用戶數據和業務處理功能外移到手機終端,導致相關的系統數據管理產生了新的變化。為保持業務體驗一致性,必須保持所有業務數據的同步。系統數據架構如圖6所示,采用Client/Server機制。
統一Centrex AS平臺作為Server,是整個統一Centrex業務系統的數據維護中心,負責全部用戶數據和業務設置的存儲與更新,是系統內業務數據的一個全集。AS負責調度并更新終端數據,響應終端請求并更新通訊錄,一對一或一對N的向終端發布最新數據。數據的傳送可采用XML協議格式,可方便的描述全量數據或增量數據。
手機終端軟件作為Client,維護某個用戶的業務設置,并保存群內用戶的通訊錄信息,是系統業務數據的一個子集。終端軟件接受從AS發布的數據,也可以主動請求一對一的發布;當用戶在終端上更改了設置時,例如更換了手機號碼,會觸發更新請求,向AS發送變更的數據。

圖6 業務數據同步架構圖
集團客戶管理員、運營商管理員通過Portal從AS獲取業務管理與業務設置數據,或向AS更新數據的修改。
BOSS系統與AS業務數據同步,便于計費結算及執行資費優惠。
增強手機終端的能力,在網絡上重新部署業務系統功能的邏輯分布,可以簡化網絡中心的邏輯復雜程度,也為簡化網絡架構提供了可能。統一Centrex業務系統在增強手機軟件能力后,有助于簡化智能網部分,也簡化了整體網絡架構、接口和業務流程。
各項功能在網絡中的分布發生變化后,也導致了一些新的問題需要解決,例如數據同步、業務管理等,需要設計一些新的機制。還有一些待解決的問題,包括用戶鑒權、終端信息安全等,需要做進一步的研究。終端的限制條件是一個需要解決的重要問題,例如必須采用智能終端,需要為各品牌各型號的終端編寫軟件。但隨著終端生產和開發產業鏈的發展,這將逐漸得到改善。