專利名稱：信令與承載分離的通信系統的制作方法
技術領域：
本發(fā)明涉及IMS技術領域，尤其涉及一種信令與承載分離的通信系統。
背景技術：
隨著用戶對全新多媒體，業(yè)務需求的日漸旺盛以及固定、移動網絡融合趨勢不斷 得到認可，IP多媒體子系統(IP MultimediaSubsystem, IMS)作為下一代網絡演進的關鍵 技術，正席卷全球電信行業(yè)。IMS是支持固定、移動網絡以及互聯網融合的未來網絡架構， 是網絡IP化轉型中的制高點。IMS技術的廣泛應用被視為推進全業(yè)務戰(zhàn)略過程中的重要 舉措。即時消息anstant Message, IM)系統作為IMS網絡體系下的基本業(yè)務，提供即時消 息(1對1即時消息、1對多即時消息、群組會話、聊天室、系統消息、離線消息、定時消息)、 文件傳送(在線文件傳送、離線文件傳送)、用戶的隱私策略管理、查詢歷史會話、與短/彩 信互通、消息內容(包括敏感詞)過濾等功能。IM的業(yè)務處理主要包含兩部分內容一部分是即時通訊過程中的信令協商，主要 包含通訊端口、通訊IP地址、以及通訊編碼方式等要素的協商；另一部分則是業(yè)務承載數 據，即真實消息內容的傳遞。第三代合作伙伴計劃(3GPP)和移動開放聯盟(OMA)標準組將即時消息系統的技 術架構中將業(yè)務信令和業(yè)務承載合在一起，通過IM-2接口負責會話初始化協議(Session Initial Protocol, SIP)信令的協商，IM-7接口為業(yè)務承載消息會話中繼協議(Message Session Relay Protocol, MSRP)消息的傳輸。這樣的方式存在如下缺陷(1)系統維護升級不方便。即時消息系統中多樣化的業(yè)務形態(tài)(包括1-1或者 I-N的大消息傳輸、1-1/1-N的大文件傳輸、I-ISessionMode多人會話、聊天室等業(yè)務)主要 通過業(yè)務信令進行邏輯控制，增加新的業(yè)務時，主要需要調整及更新業(yè)務信令模塊。而業(yè)務 承載模塊相對穩(wěn)定。信令和承載合設在一起時，任何業(yè)務需求的變化都需要對整個即時消 息系統進行升級維護和改造，不利于系統的升級和維護。(2)由于系統對于業(yè)務信令的處理能力比較大，而業(yè)務承載的處理能力相對低一 些，如果將二者合設在一起，服務器的部署通?；跇I(yè)務邏輯中處理能力較低的模塊配置， 這樣不利于系統資源的最大化利用。(3)即時消息系統和IMS網絡體系架構中信令和承載分離的思路不一致。

發(fā)明內容
(一)要解決的技術問題本發(fā)明所要解決的技術問題是如何實現業(yè)務信令與業(yè)務承載數據的分離，以便 于系統的升級、開發(fā)及維護，以及如何實現硬件資源的優(yōu)化及合理利用。(二)技術方案為解決上述問題，本發(fā)明提供了一種信令與承載分離的通信系統，該系統包括若 干即時消息服務器，用于系統中即時通訊的會話初始化協議信令的協商；若干消息會話中繼協議服務器，用于基于大消息傳送模式及會話模式的消息的收發(fā)及管理。其中，所述即時消息服務器與所述消息會話中繼協議服務器之間通過采用TCI/IP 協議的接口通訊。其中，一個所述即時消息服務器對應一個或多個所述消息會話中繼協議服務器； 一個所述消息會話中繼協議服務器對應一個或多個即時消息服務器。其中于，所述即時消息服務器進一步包括協議層，用于處理即時消息相關的協議 的解析和組裝；業(yè)務邏輯層，用于處理系統的各種業(yè)務邏輯；呼叫流程層，用于控制系統中 的呼叫流程。其中，所述業(yè)務邏輯層進一步包括XML文檔管理模塊，用于處理XML配置訪問協 議請求；會話初始化協議模塊，用于處理即時消息業(yè)務的會話初始化協議信令流程；消息 會話中繼協議服務器接口，用于與所述消息回話中繼協議服務器之間的接口交互，以及所 述消息回話中繼協議服務器的選擇；通用模塊，用于提供由各模塊開發(fā)調用的公共應用程 序編程接口。其中，所述業(yè)務邏輯層還包括計費模塊，用于完成系統的計費；網絡管理模塊， 用于作為簡單網絡管理協議的客戶端，完成網絡管理所需的配置、故障、性能、安全管理功 能；第一互聯模塊，用于完成與短信網關之間的互聯互通；第二互聯模塊，用于完成于彩信 網關之間的互聯互通；能力開放模塊，用于與第三方系統互通；業(yè)務管理模塊，用于通過與 數據業(yè)務管理系統相連，實現業(yè)務管理及互通功能；消息會話中繼協議服務器模塊，用于與 用戶設備進行消息會話中繼協議通信。其中，所述呼叫流程包括會話初始化協議流程的控制以及XML配置訪問協議流程。其中，所述呼叫流程層進一步包括會話初始化協議狀態(tài)機，用于處理會話初始化 協議相關的業(yè)務流程XML配置訪問協議狀態(tài)機，用于處理XCAP相關的業(yè)務流程。其中，所述消息會話中繼協議服務器進一步包括協議棧模塊，用于消息會話中繼 協議消息的解析與組裝；消息隊列，用于收發(fā)消息會話中繼協議消息；會話管理模塊，用于 處理消息會話中繼協議會話；業(yè)務邏輯模塊，用于處理消息會話中繼協議相關的業(yè)務邏輯； 存儲模塊，用于存儲消息，包括歷史消息、離線消息以及定時消息；元數據模塊，用于生成歷 史消息的元數據；即時消息服務器接口，用于與所述即時消息服務器通訊；消息遞送報告 模塊，用于發(fā)送所述大消息傳送模式以及會話模式消息的遞送報告。(三)有益效果本發(fā)明的系統采用信令和承載分離的方案，具有如下優(yōu)勢1、升級方便，便于即時消息新業(yè)務功能的開發(fā)和維護，由于主要需要調整及更新 業(yè)務信令模塊IM Server,而業(yè)務承載模塊MSRPkrver相對穩(wěn)定，這樣對于大部分業(yè)務邏 輯變化的系統升級時，只需要單獨升級IM krver即可。IM krver網元少且集中設置，升 級的工作量相對少，這樣將有助于提高升級和系統運維的效率。2、由于系統對于業(yè)務信令的處理能力比較大，容量大，但業(yè)務承載的處理能力相 對低一些，容量也比較低，同樣的業(yè)務量，IM krver比MSRP krver所需的服務器數量相 對少。分開部署兩個服務，有助于合理利用系統的硬件資源。3、將信令和承載分之后，與IMS整個網絡體系架構中信令和承載分離的思路一致，從而保證網絡層和應用層采用同樣的體系架構，網絡結構更優(yōu)化。


圖1為依照本發(fā)明一種實施方式的信令與承載分離的通信系統結構框圖；圖2為依照本發(fā)明一種實施方式的信令與承載分離的通信系統中IM Server的結 構框圖；圖3為依照本發(fā)明一種實施方式的信令與承載分離的通信系統中IM Server與 MSRP Server的關系圖；圖4為依照本發(fā)明一種實施方式的信令與承載分離的通信系統中MSRP krver的 結構框圖；圖5為依照本發(fā)明一種實施方式的信令與承載分離的通信系統中IM Server與 MSRP krver之間的交互方式示意圖；圖6為依照本發(fā)明一種實施方式的信令與承載分離的通信系統中MSRP krver需 要處理的消息示意圖。
具體實施例方式本發(fā)明提出的信令與承載分離的通信系統尤指即時消息系統，結合附圖和實施例 說明如下。本發(fā)明對3GPP/0MA所定義的即時消息系統架構進行了優(yōu)化，主要闡述了即時消 息系統在IMS網絡體系下的業(yè)務信令和業(yè)務承載分離解決方案。業(yè)務信令主要負責IM系 統中各種即時通訊的SIP信令協商，業(yè)務承載主要負責MSRP承載數據的傳輸。如圖1所示，依照本發(fā)明一種實施方式的信令與承載分離的通信系統包括即時消息服務器(IM krver)，用于系統中即時通訊的SIP信令的協商；以及消息 會話中繼協議服務器(MSRP krver)，用于基于大消息傳送模式(Large Message Mode)及 會話模式(Session Mode)的消息的收發(fā)及管理。二者之間通過自定義的通訊協議互通。優(yōu) 選地，通過采用TCI/IP協議的接口通訊。一套IM系統可以部署為多個IMServer，一個IM krver可以對應多個MSRP Server，一個MSRP Server可以為多個IM Server服務。一個 客戶端可以連接一個或多個MSRPkrver。IM krver采用模塊化結構，各模塊之間的通信按標準接口進行。各模塊業(yè)務數 據和系統運行數據均可配置，配置數據與處理程序應有相對的獨立性，配置數據的任何變 更都不會引起運行版本程序的變更。配置數據能動態(tài)加載，加載過程不需模塊重新編譯重 啟服務，實時生效，降低運營成本，為新一代的精益運營提供良好的支持。如圖2所示，IM krver主要包括三層協議層(Protocol Layer)、業(yè)務邏輯層(Service Logic Layer)、以 及呼叫流程層(Call Flow Layer) 0Protocol Layer，用于處理IM相關的各種協議的解析和組裝；Service Logic Layer，用于處理IM系統的各種業(yè)務邏輯；Call Flow Layer，用于控制IM系統中的呼叫流程，包括SIP流程的控制以及XML 配置訪問協議(XML Configuration Access Protocol, XCAP)流程的控制。其中，Protocol Layer主要處理的協議包括
6
SIP Stack (SIP棧)負責SIP消息的解析和組裝，支持的SIP請求包括INVITE， ACK, BYE,SUBSCRIBE, NOTIFY, PUBLISH, MESSAGE, REFER 等。SDP Mack:負責會話描述協議(SDP)消息的解析和組裝。XCAP Mack:負責XCAP消息的解析和組裝。SNMP Mack 負責簡單網絡管理協議(Simple NetworkManagement Protocol, SNMP)消息的解析和組裝。Diameter Stack (Ro/Rf)負責Diameter消息的解析，需要支持的接口有與 OCS (在線計費系統)的Ro接口，以及與CCF (客戶服務框架)之間的Rf接口。SMPP Stack:負責短消息點對點協議(short message peer to peer, SMPP)消息 的解析與組裝。CMPP Mack 負責中國移動點對點協議(China Mobile Peer toPeer, CMPP)消息 的解析與組裝。SOAP Mack 負責簡單對象訪問協議(Simple Object Access Protocol，SOAP)消 息的解析和組裝。Service Logic Layer 進一步包括IM XML 文檔管理模塊(XMLDocument Management Server, XDMS), SIP 模塊(SIP Module)、消息會話中繼協議服務器接口(MSRP Server Interface)、以及通用模塊(Utilities)。XDMS負責處理各種XCAP請求，主要包括下面幾部分XCAP Message Queue =XCAP 消息隊列。XCAP消息分配(XCAP Msg Dispatch)負責將各種XCAP請求根據 AUID (Application Unique Identity，應用唯一標識)分發(fā)給不同的XDMS來處理。會話歷史代理(Conversaion History Agent)管理(增加/刪除/修改)IM會 話歷史記錄。擱置消息代理(Deferred Message Agent)管理(增加/刪除/修改)離線IM消 肩、ο定時消息代理(Timed Message Agent)管理(增加/刪除/修改)定時消息。IM配置代理(IM Setting Agent)管理IM業(yè)務相關的個人配置。GM業(yè)務代理(GM Service Agent)充當與群組管理(Group Management,GM)業(yè)務 平臺的接口模塊，充當GM客戶端，利用XCAP請求從GM提取群組信息或者個人信息等。SIP Module用于處理IM業(yè)務的各種SIP信令流程，主要包括下面幾部分SIP Message Queue =SIP消息隊列，負責管理各SIP模塊收發(fā)的各種SIP消息。SIP事件處理器(SIP Event Handler)負責預處理SIP的各種事件請求，并將其 分發(fā)給各自的事件處理模塊。SIP會話管理(SIP Session Management)負責IM系統所涉及到的SIP會話的管理。消息遞送報告模塊(Message Delivery Report Module)負責消息遞送狀態(tài)的發(fā) 送(Page Mode，通過 IMDN(Instant Message Disposition Notification，即時消息處理通 知)發(fā)送)。Presence Server 代理(Presence Server Agent):負責與 Presence Server (PS)互連，充當I^esence客戶端，從PS上訂閱用戶的狀態(tài)。IM初始參與功能模塊(IM Originating Participant Function (OPF)Module)處 理呼叫發(fā)起方的各種IM業(yè)務邏輯。包括(1)從IM XDMS上讀取主叫用戶IM配置相關的數據，根據這些主叫方的配置數據 來處理相應的業(yè)務邏輯。(2)處理客戶端通過SIP PUBLISH消息發(fā)出的IM配置請求，通過IM XDMS中IM Setting Module來更新主叫方的IM相關數據的配置。(3)對來自客戶端各種SIP消息的路由轉發(fā)。(4)通過 MSRP Server hterface 與 MSRP Server 上的 OPF 通訊，為主叫端協商 MSRP傳輸模式。IM終止參與功能模塊(IM Terminating Participant Function (TPF)Module)處 理呼叫被叫方的各種SIP業(yè)務邏輯(1)從IM XDMS上讀取被叫用戶IM配置相關的數據，根據這些被叫方的配置數據 來處理相應的業(yè)務邏輯。(2)從GM XDMS上讀取被叫方的訪問策略(Access Policy)，據被叫用戶的訪問規(guī) 則(Access Rule)來決定消息的轉發(fā)。(3)將SIP請求或者響應轉發(fā)給被叫方。(4)通過 MSRP Server hterface 與 MSRP Server TPF 通訊，為被叫端協商 MSRP 傳輸模式?？刂乒δ苣K(Controlling Function(CF)Module)負責處理IM的多人會話業(yè) 務邏輯，主要功能如下(1)頁面模式(Page Mode)的多人會話邏輯。(2)kssion Mode的多人回話邏輯。(3)從GM krver上讀取群組信息。(4)會議(Conference)狀態(tài)事件的管理(SUBSCRIBE/NOTIFY)。(5)多人會話群組的管理。(6)多人會話狀態(tài)的管理。(7)臨時群組會話的的管理。(8)預定義多人會話的管理。(9)處理客戶端增加或刪除用戶的請求(SIP REFER)的業(yè)務邏輯。會話歷史消息模塊(Conversation History Message Module)負責歷史消息的 管理(Page Mode)。擱置消息處理(Deferred Message Handling)負責處理離線消息的業(yè)務邏輯 (Page Mode)定時消息處理模塊(Timed Message Handling Module)負責定時消息的業(yè)務邏 輯(Page Mode)注冊模塊(Registration Module)負責SIP請求在IM系統上的第三方注冊，注 銷邏輯。MSRP Server hterface 用于與 MSRP Server 之間的接 口交互，以及 MSRP Server的選擇。IM Server與MSRP Server之間的關系如圖3所示。MSRP Server Interface 主要包括兩部分接口(Interface)模塊，主要負責和MSRP Server之間的通訊。MSRP 服務器管理器(MSRP Server Manager)管理所有的 MSRPServer，為 IM krver 選擇合適的 MSRP Server。Utilities用于提供一些其他模塊開發(fā)能夠直接誒調用的公共應用程序編程接口 (API)，包括記錄器負責生成和管理各種Log文件，系統日志包括管理員對系統所做的操作，比如導出系統的數據、增加新的管理員等。用戶日志包括用戶操作行為日志。XML解析器(XML Parser)負責解析/組裝XML文件或者文本。呼叫詳細記錄生成器(⑶R Generator)負責生成話單文件。Socket 負責 UDP/TCP 的 Socket 相關的處理。報警(Alarm)負責根據系統的負載情況生成不同級別的報警提示。過載控制(Overload Control)負責檢測和管理系統的過量負載狀態(tài)，主要應對 一些特殊的系統超負荷情況。不同級別的負載情況將實施不同級別的控制策略。數據庫代理(DBProxy)對應用模塊提供統一的數據庫讀寫接口。Service Logic Layer jS^ —T^ftllll^:計費模塊(Billing Module)，用于完成系統的計費；網絡管理模塊(Network Management Module)，用于作為SNMP客戶端，與移動網絡 管理系統互通，完成網絡管理所需的配置、故障、性能、安全管理等功能；第一互聯模塊(IM-SMS Module)，用于完成與短信網關之間的互聯互通；第二互聯模塊(IM-MMS Module)，用于完成于彩信網關之間的互聯互通；能力開放模塊(IM-Capabilities Module)，用于與企業(yè)即時通信管理平臺或第三 方系統互通；業(yè)務管理模塊(IM-BUSSINESS Module)，用于通過SOAP協議與數據業(yè)務管理系統 相連，實現IMS客戶開戶、業(yè)務受理、業(yè)務變更、客戶服務功以及和即時通信管理平臺互通 等功能；MSRP Server模塊，用于與用戶設備(UE)進行MSRP通信。Call Flow Layer 進一步包括SIP狀態(tài)機-負責SIP相關的業(yè)務流程(I)Page Mode(2) Large Message Mode(3) Session Mode(4)第三方注冊⑶與PS狀態(tài)訂閱流程XCAP狀態(tài)機-負責XCAP相關的業(yè)務流程(1)獲取用戶個人設置
(2)獲取群組相關信息，如群組成員列表(3)處理歷史消息的XCAP請求(4)處理離線消息的XCAP請求(5)處理定時消息的XCAP請求如4所示，MSRP Server進一步包括協議棧模塊(MSRP Stack)，用于MSRP消息的解析與組裝；消息隊列(MSRP Message Queue)，用于收發(fā)MSRP消息；會話管理模塊(MSRP Session Management)，用于處理MSRP會話；業(yè)務邏輯模塊(MSRP Business Logic Module)，用于處理消息會話中繼協議相關 的業(yè)務邏輯；存儲模塊(MSRP Storage Agent)，用于存儲消息，包括歷史消息、離線消息以及定 時消息；元數據模塊(Meta-data Module)，用于生成歷史消息的Meta-data ；IM Server 接口 (IM Server Interface)，用于與 IM Server 通訊；消息遞送報告模塊(MessageDelivery Report Module)，用于發(fā)送Large Mode和 Session Mode消息的遞送報告，通過MSRP R印ort發(fā)送。IM Server與MSRP Server的交互方式如圖5所示，整個通訊模式采用Command/ Notify的模式所有的MSRP的連接請求通過Command來實現啟動關閉，MSRPServer的連接不會 自動啟動，所有由IM krver發(fā)起的命令包括 啟動/停止一個呼叫 啟動/停止一個MSRP會話·增加一個 MSRP 會話的 ChannelMSRP Server通過Notify給IM核心網回復一些處理結果，包括 連接斷開 連接錯誤 錯誤的命令·數據讀寫錯誤MSRP Server上所處理的主要消息如圖6所示MSRP Server 與 IM Server 之間的接 口采用 TCP/IP 協議，IM Server 發(fā)送 Command 給MSRP krver后，啟動一個系統定時等待MSRP krver的回應(Notify)，如果超時的時候 MSRP Server還沒有回應，IM Server需要重新選擇MSRP Server。當IM Server需要請求MSRP Server建立MSRP Session連接的時候，通過發(fā)送 Command消息給MSRP Server來指示其觸發(fā)相應的業(yè)務邏輯。Command消息包含兩部分，消息頭和消息體，格式如下消息頭/r/n/r/n消息體/r/n消息頭分為兩部分，第一行為消息起始行，格式如下0149]COMMAND MSRP_Server_URI[Port]PGM/1. O
0150]其他行為COMMAND消息的各種屬性，采用屬性-值對(Attribue-Value Pair, AVP) 的模式，每個屬性之間用“；”隔開。消息頭所包括的屬性如下所示
0151]TID (Transaction ID) :Command 的事務標識，10 位數字串(digitsstring)，例如 0000001234。
0152]MCT (MSRP Command Type, MSRP 命令類型):Command 類型。
0153]2 digitis string
0154]01-啟動呼叫
0155]02-停止呼叫
0156]03-啟動 MSRP Session
0157]04-停止 MSRP Session
0158]05- ±曾力口一個 Channel
0159]06-刪除一個 Channel
0160]07-開始存儲延遲消息
0161]08-結束存儲延遲消息
0162]09-提取延遲消息
0163]10-開始存儲定時消息
0164]11-結束存儲定時消息
0165]12-觸發(fā)某個定時消息
0166]13-開始存儲歷史消息
0167]14-結束存儲歷史消息
0168]CID (Call ID，呼叫標識)SIP呼叫標識。
0169]CHM(Conversation History Message，會話歷史消息)Flag 要不要存儲歷史消 、。1 digit string,0 = True, 1 = False。
0170]MSID (MSRP Session ID，MSRP 會話標識)MSRP 會話標識。
0171]LPT (Local Party Type，本地節(jié)點類型)1 digit string
0172]1-0PF
0173]TPF
0174]CF
0175]LPCA(Local Party Connection Attribute, ^ ft l , ； ^ M ) :ldigit string,本地MSRP節(jié)點連接屬性
0176]1-主動 & 辛$云力(Active&Passive)
0177]2-Active
0178]3-Passive
0179]LPMURI (Local Party MSRP URI):本地的 MSRP URI
0180]CT(Channel Type，通道類型)=Idigit string
0181]I-UE
0182]2-0PF
0183]3-CF
4-TPFCCA(Channel Connection Attribute,通道連接屬個生)ldigit string, Channel 的連接屬性I-Active & Passive2-Active3-PassiveCMURI(Channel MSRP URI) =Channel 的 MSRP URL·CL (Content Length) -Command 消息體的長度。消息體主要包含IM Server發(fā)送Command之前的整個SIP消息。如果SIP消息已 經在以前的Command消息發(fā)送給MSRP Server，消息體可以為空。MSRP Server 收到來自 IM Server 的 Command 之后，回送 Notify 消息給 IM Server 匯報命令的執(zhí)行結果。NOTIFY消息的格式和COMMAND消息類似。NOTIFY消息消息包含兩部分，消息頭和消息體，格式如下消息頭/r/n/r/n消息體/r/n消息頭分為兩部分，第一行為消息起始行，格式如下NOTIFY IM_Server_URI[Port]PGM/1. 0其他行為NOTIFY消息的各種屬性，采用AVP的模式，每個屬性之間用“；”隔開， 消息頭所包括的屬性如下所示TID :Command 的事務標識。10 digits string，例如0000001234。MCT Command 類型，2 digitis string。RC (Result Code,結果編碼):Command消息執(zhí)行的結果編碼00-成功01-連接失敗02-TCP 未連接03-錯誤形式的命令04-數據讀寫錯誤RD(Result Description)執(zhí) 亍結果描述。以上實施方式僅用于說明本發(fā)明，而并非對本發(fā)明的限制，有關技術領域的普通 技術人員，在不脫離本發(fā)明的精神和范圍的情況下，還可以做出各種變化和變型，因此所有 等同的技術方案也屬于本發(fā)明的范疇，本發(fā)明的專利保護范圍應由權利要求限定。
權利要求
1.一種信令與承載分離的通信系統，其特征在于，該系統包括若干即時消息服務器，用于系統中即時通訊的會話初始化協議信令的協商； 若干消息會話中繼協議服務器，用于基于大消息傳送模式及會話模式的消息的收發(fā)及管理。
2.如權利要求1所述的信令與承載分離的通信系統，其特征在于，一個所述即時消息 服務器對應一個或多個所述消息會話中繼協議服務器；一個所述消息會話中繼協議服務器 對應一個或多個即時消息服務器。
3.如權利要求1所述的信令與承載分離的通信系統，其特征在于，所述即時消息服務 器與所述消息會話中繼協議服務器之間通過采用TCI/IP協議的接口通訊。
4.如權利要求1所述的信令與承載分離的通信系統，其特征在于，所述即時消息服務 器進一步包括協議層，用于處理即時消息相關的協議的解析和組裝； 業(yè)務邏輯層，用于處理系統的各種業(yè)務邏輯； 呼叫流程層，用于控制系統中的呼叫流程。
5.如權利要求4所述的信令與承載分離的通信系統，其特征在于，所述業(yè)務邏輯層進 一步包括XML文檔管理模塊，用于處理XML配置訪問協議請求； 會話初始化協議模塊，用于處理即時消息業(yè)務的會話初始化協議信令流程； 消息會話中繼協議服務器接口，用于與所述消息回話中繼協議服務器之間的接口交 互，以及所述消息回話中繼協議服務器的選擇；通用模塊，用于提供由各模塊開發(fā)調用的公共應用程序編程接口。
6.如權利要求5所述的信令與承載分離的通信系統，其特征在于，所述業(yè)務邏輯層還 包括計費模塊，用于完成系統的計費；網絡管理模塊，用于作為簡單網絡管理協議的客戶端，完成網絡管理所需的配置、故 障、性能、安全管理功能；第一互聯模塊，用于完成與短信網關之間的互聯互通； 第二互聯模塊，用于完成于彩信網關之間的互聯互通； 能力開放模塊，用于與第三方系統互通；業(yè)務管理模塊，用于通過與數據業(yè)務管理系統相連，實現業(yè)務管理及互通功能； 消息會話中繼協議服務器模塊，用于與用戶設備進行消息會話中繼協議通信。
7.如權利要求4所述的信令與承載分離的通信系統，其特征在于，所述呼叫流程包括 會話初始化協議流程的控制以及XML配置訪問協議流程。
8.如權利要求7所述的信令與承載分離的通信系統，其特征在于，所述呼叫流程層進 一步包括會話初始化協議狀態(tài)機，用于處理會話初始化協議相關的業(yè)務流程 XML配置訪問協議狀態(tài)機，用于處理XCAP相關的業(yè)務流程。
9.如權利要求8所述的信令與承載分離的通信系統，其特征在于，所述消息會話中繼 協議服務器進一步包括協議棧模塊，用于消息會話中繼協議消息的解析與組裝；消息隊列，用于收發(fā)消息會話中繼協議消息；會話管理模塊，用于處理消息會話中繼協議會話；業(yè)務邏輯模塊，用于處理消息會話中繼協議相關的業(yè)務邏輯；存儲模塊，用于存儲消息，包括歷史消息、離線消息以及定時消息；元數據模塊，用于生成歷史消息的元數據；即時消息服務器接口，用于與所述即時消息服務器通訊；消息遞送報告模塊，用于發(fā)送所述大消息傳送模式以及會話模式消息的遞送報告。
全文摘要
本發(fā)明公開了一種信令與承載分離的通信系統，該系統包括若干即時消息服務器，用于系統中即時通訊的會話初始化協議信令的協商；若干消息會話中繼協議服務器，用于基于大消息傳送模式及會話模式的消息的收發(fā)及管理。本發(fā)明的系統可實現業(yè)務信令與業(yè)務承載數據的分離，便于系統的升級、開發(fā)及維護，且可實現硬件資源的優(yōu)化及合理利用。
文檔編號H04L12/58GK102065099SQ201010622478
公開日2011年5月18日 申請日期2010年12月28日 優(yōu)先權日2010年12月28日
發(fā)明者張文華, 徐立鈞, 李毅 申請人:北京神州泰岳軟件股份有限公司