專利名稱：短消息狀態(tài)報告的處理方法及系統(tǒng)的制作方法
技術領域：
本發(fā)明涉及通信行業(yè)的核心網(wǎng)技術領域，尤其涉及短消息狀態(tài)報告的處理方法及 系統(tǒng)。
背景技術：
隨著短信業(yè)務的發(fā)展，通過各種應用平臺下發(fā)短信的業(yè)務越來越廣泛，業(yè)務范圍 包括互聯(lián)網(wǎng)增值短消息業(yè)務、行業(yè)應用短消息業(yè)務、各種自有短信業(yè)務、PUSH消息等等。這 些應用平臺通常接入短信網(wǎng)關，包括互聯(lián)網(wǎng)短信網(wǎng)關、行業(yè)應用網(wǎng)關等，通過短信網(wǎng)關將短 消息下發(fā)至短信中心，再由短信中心下發(fā)至手機終端，然后短信中心向網(wǎng)關返回狀態(tài)報告， 短信網(wǎng)關進行原始消息與狀態(tài)報告的匹配，然后根據(jù)狀態(tài)報告生成計費話單，并將狀態(tài)報 告返回給應用平臺圖1為現(xiàn)有技術短信業(yè)務組網(wǎng)結(jié)構(gòu)示意圖。如圖1所示，應用平臺(Service Platform，簡稱SP)將短信下發(fā)給互聯(lián)網(wǎng)短信網(wǎng)關Qnternet Short Message Gateway，簡 稱ISMG)，短信網(wǎng)關將消息下發(fā)到短信中心(Short Message Service Center，簡稱SMSC)， 或前轉(zhuǎn)到外省的短信網(wǎng)關(若SP接入短信網(wǎng)關所在省與被叫號碼所屬省不同)，然后由短 信中心通過專線或局域網(wǎng)，依照短消息點對點傳輸協(xié)議(Short Message Peer to Peer，簡 稱SMPP協(xié)議)將短信下發(fā)至用戶終端。圖2為現(xiàn)有技術短信下發(fā)的流程圖。如圖2所示， 應用平臺下發(fā)流程包括步驟S002 =SP 給接入 ISMG 發(fā)送消息 “CMPP_Submit” ；步驟S004 接入ISMG根據(jù)被叫號碼把消息路由到用戶的歸屬ISMG “CMPP_Fwd”， 若接入ISMG和歸屬ISMG是同一個，則直接進行步驟S006 ；步驟S006 歸屬ISMG把消息提交給自己接入的SMSC "SUBMIT_SM"；步驟S008 =SMSC給目的用戶發(fā)送短信；步驟S010 目的用戶接收到該短信，或者該短信超過了有效期，用戶仍然沒有接 收到該短信，用戶終端發(fā)送短消息應答至SMSC ；步驟S012 =SMSC把表示短信是否成功發(fā)送給目的用戶的狀態(tài)報告“DELIVER_SM” 發(fā)送給歸屬ISMG，歸屬ISMG進行原始消息和狀態(tài)報告的匹配，根據(jù)狀態(tài)報告生成成功或失 敗的話單，用來計費及結(jié)算；步驟S014 歸屬ISMG接收到SMSC發(fā)送給自己的狀態(tài)報告消息“DELIVER_SM”后， 把狀態(tài)報告轉(zhuǎn)發(fā)給接入地ISMG，接入地ISMG進行原始消息和狀態(tài)報告的匹配，根據(jù)狀態(tài)報 告生成成功或失敗的話單，用來計費及結(jié)算；步驟S016 接入ISMG接收到歸屬ISMG轉(zhuǎn)發(fā)過來的狀態(tài)報告“CMPP_Fwd”消息后， 把狀態(tài)報告?zhèn)鬟f給SP “CMPP_Deliver”。在上述流程中，對ISMG而言，一個重要的步驟就是進行原始消息與狀態(tài)報告的匹 配，以此確認消息下發(fā)成功與否，并生成成功或失敗的話單，用來計費及結(jié)算。圖3為現(xiàn)有 技術IMSG確認消息下發(fā)狀態(tài)方案一的示意圖。如圖3所示，流程包括
步驟S052 =ISMG服務器接收SP提交消息；步驟SOM =ISMG下發(fā)短消息后，在服務器內(nèi)存或硬盤中保留該短消息原始消息的 記錄，包括消息的MSG_ID ；步驟S056 服務器接收到下級網(wǎng)元返回的狀態(tài)報告；步驟S058 根據(jù)原始消息與狀態(tài)報告消息的MSG_ID相同的原則，將原始消息與狀 態(tài)報告在內(nèi)存中進行匹配(若在硬盤則需先調(diào)入內(nèi)存)；步驟S060 根據(jù)狀態(tài)報告(表明短消息下發(fā)成功或失敗)生成成功或失敗的話 單；其工作方式如圖所示步驟S062 服務器將狀態(tài)報告返回給SP。方案一僅適用于單節(jié)點的網(wǎng)關結(jié)構(gòu)，網(wǎng)關核心服務器由一個或一套主備雙機服務 器組成，處理能力有限，并且可擴展能力差。在另外一種技術方案中，采用多臺IMSG服務 器，并將原始消息記錄保存才后臺數(shù)據(jù)庫中。圖4為現(xiàn)有技術IMSG確認消息下發(fā)狀態(tài)方案 二的示意圖。如圖4所示，實現(xiàn)流程包括步驟S082 短信網(wǎng)關服務器接收SP提交消息；
步驟S084 ISMG下發(fā)短消息；步驟S086 服務器將原始消息記錄保存在后臺數(shù)據(jù)庫中，包括消息的MSG_ID ；步驟S088 服務器接收到下級網(wǎng)元返回的狀態(tài)報告；步驟S090 服務器將狀態(tài)報告轉(zhuǎn)發(fā)到后臺數(shù)據(jù)庫；步驟S092 后臺數(shù)據(jù)庫根據(jù)原始消息與狀態(tài)報告消息的MSG_ID相同的原則進行 原始消息與狀態(tài)報告的匹配，然后根據(jù)狀態(tài)報告生成成功或失敗的話單；步驟S094 服務器將狀態(tài)報告返回給SP。方案二使得服務器的數(shù)量得到了擴展，網(wǎng)關可以由多臺核心服務器組成，提高了 處理能力，但是由于所有的狀態(tài)報告匹配均要在數(shù)據(jù)庫中完成，而數(shù)據(jù)庫處理能力有限，所 以數(shù)據(jù)庫成為了系統(tǒng)處理能力的瓶頸，使得短信網(wǎng)關無法向更高的規(guī)模擴展。隨著業(yè)務的發(fā)展，現(xiàn)網(wǎng)對大容量短信網(wǎng)關的需求日趨強烈。在實現(xiàn)本發(fā)明過程中， 發(fā)明人發(fā)現(xiàn)現(xiàn)有技術短消息狀態(tài)報告的處理方式中存在如下問題現(xiàn)有的狀態(tài)報告處理方 式不能充分發(fā)揮多臺核心服務器的處理優(yōu)勢，業(yè)務擴展能力受限。
發(fā)明內(nèi)容
本發(fā)明的目的是狀態(tài)報告處理方法不能充分發(fā)揮多臺核心服務器處理優(yōu)勢的問 題，提出一種短消息狀態(tài)報告的處理方式及系統(tǒng)，以大規(guī)模擴大短信網(wǎng)關的處理能力。為實現(xiàn)上述目的，根據(jù)本發(fā)明的一個方面，提供了一種短消息狀態(tài)報告的處理方 法，包括接收短消息狀態(tài)報告；根據(jù)短消息狀態(tài)報告中短消息標識，向索引服務器查詢短 消息標識對應的服務器標識；將短消息狀態(tài)報告發(fā)送至服務器標識對應的核心服務器。本技術方案中，接收短消息狀態(tài)報告的步驟之前還包括核心服務器接收短消息 發(fā)送請求，保存原始短消息；將短消息通過下級網(wǎng)元接口發(fā)送至用戶終端；下級網(wǎng)元接口 將短消息狀態(tài)報告發(fā)送至服務器標識對應的核心服務器的步驟之后還包括核心服務器進 行原始短消息和短消息狀態(tài)報告的匹配。本技術方案中，核心服務器接收短消息發(fā)送請求的步驟之后還包括核心服務器發(fā)送映射信息至索引服務器，映射信息包括短消息標識與服務器標識的映射關系；索引服 務器存儲映射關系；下級網(wǎng)元接口向索引服務器查詢短消息標識對應的服務器標識的步驟 具體包括下級網(wǎng)元接口向索引服務器發(fā)送查詢請求，查詢請求包括短消息標識；根據(jù)短 消息標識和映射關系，索引服務器獲取短消息標識對應的服務器標識；索引服務器向下級 網(wǎng)元接口返回包括服務器標識的查詢響應。優(yōu)選地，本技術方案中，當索引服務器有多臺時，核心服務器發(fā)送映射信息至索引 服務器的步驟具體包括根據(jù)負載均衡算法，核心服務器發(fā)送映射信息報文至短消息標識 對應的索引服務器；下級網(wǎng)元接口向索引服務器發(fā)送查詢請求的步驟具體包括根據(jù)負載 均衡算法，下級網(wǎng)元接口向短消息標識對應的索引服務器發(fā)送查詢請求。本技術方案中，負載均衡算法為通用分組算法。本技術方案中，短消息標識為MSG_ID ；服務器標識為服務器IP地址。為實現(xiàn)上述目的，根據(jù)本發(fā)明的另一個方面，提供了一種短消息狀態(tài)報告的處理 系統(tǒng)，包括索引服務器、下級網(wǎng)元接口、核心服務器，其中索引服務器，用于保存短消息標 識與服務器標識的對應關系；下級網(wǎng)元接口，用于接收短消息狀態(tài)報告，根據(jù)短消息狀態(tài)報 告中短消息標識，向索引服務器查詢短消息標識對應的服務器標識，并將短消息狀態(tài)報告 發(fā)送至服務器標識對應的核心服務器；核心服務器，用于接收短消息狀態(tài)報告。本技術方案中，核心服務器包括接收模塊，用于接收短消息發(fā)送請求；處理模 塊，用于保存原始短消息，并將短消息通過下級網(wǎng)元接口發(fā)送至用戶終端；映射模塊，用于 發(fā)送映射信息至索引服務器，映射信息包括短消息標識與核心服務器標識的映射關系；匹 配模塊，用于接收短消息狀態(tài)報告，進行原始短消息和短消息狀態(tài)報告的匹配。本技術方案中，當索引服務器有多臺時，核心服務器還包括存儲負載均衡模塊， 用于根據(jù)負載均衡算法和短消息標識，確定存儲映射關系的索引服務器；下級網(wǎng)元接口對 應包括查詢負載均衡模塊，用于根據(jù)負載均衡算法，向短消息標識對應的索引服務器發(fā)送 查詢請求。本技術方案中，負載均衡算法為求余算法或Hash算法。本技術方案中，短消息標識為MSG_ID ；服務器標識為服務器IP地址。本發(fā)明各實施例的短消息狀態(tài)報告的處理方式及系統(tǒng)，采用狀態(tài)報告索引機制， 能充分發(fā)揮多臺核心服務器處理優(yōu)勢，解決業(yè)務擴展能力受限的問題。本發(fā)明的其它特征和優(yōu)點將在隨后的說明書中闡述，并且，部分地從說明書中變 得顯而易見，或者通過實施本發(fā)明而了解。本發(fā)明的目的和其他優(yōu)點可通過在所寫的說明 書、權利要求書、以及附圖中所特別指出的結(jié)構(gòu)來實現(xiàn)和獲得。下面通過附圖和實施例，對本發(fā)明的技術方案做進一步的詳細描述。
附圖用來提供對本發(fā)明的進一步理解，并且構(gòu)成說明書的一部分，與本發(fā)明的實 施例共同用于解釋本發(fā)明，并不構(gòu)成對本發(fā)明的限制。在附圖中圖1為現(xiàn)有技術短信業(yè)務組網(wǎng)結(jié)構(gòu)示意圖；圖2為現(xiàn)有技術短信下發(fā)的流程圖；圖3為現(xiàn)有技術IMSG確認消息下發(fā)狀態(tài)方案一的示意圖4為現(xiàn)有技術IMSG確認消息下發(fā)狀態(tài)方案二的示意圖；圖5為本發(fā)明實施例一短消息狀態(tài)報告處理方法的流程圖；圖6為本發(fā)明實施例二短消息狀態(tài)報告處理方法的流程圖。
具體實施例方式以下結(jié)合附圖對本發(fā)明的實施例進行說明，應當理解，此處所描述的實施例僅用 于說明和解釋本發(fā)明，并不用于限定本發(fā)明。實施例一本發(fā)明針對的是存在多臺核心服務器處理短消息的情況。由于不同的短消息是由 不同的核心服務器進行處理和原始消息保存，在返回短消息狀態(tài)報告后，必須將短消息狀 態(tài)報告發(fā)送至對應的核心服務器，才能完成原始短消息和短消息狀態(tài)報告的匹配，進而進 行計費或者其他操作。為了識別上述多臺核心服務器，本發(fā)明引入了索引服務器，用于存儲 短消息標識和服務器的對應關系。圖5為本發(fā)明實施例一短消息狀態(tài)報告處理方法的流程圖。如圖5所示，本實施 例包括步驟S102 接收短消息狀態(tài)報告；步驟S104 根據(jù)短消息狀態(tài)報告中短消息標識，向索引服務器查詢短消息標識對 應的服務器標識；步驟S106 將短消息狀態(tài)報告發(fā)送至服務器標識對應的核心服務器。上述步驟只是描述了當接收到短消息狀態(tài)報告后的處理步驟，在短消息發(fā)送階 段，本實施例還可以包括核心服務器接收短消息發(fā)送請求，保存原始短消息；發(fā)送映射信 息至索引服務器，映射信息包括短消息標識與服務器標識的映射關系；將短消息通過下級 網(wǎng)元接口發(fā)送至用戶終端；索引服務器存儲映射關系。對應的，步驟S104中，下級網(wǎng)元接口 向索引服務器查詢短消息標識對應的服務器標識的步驟具體包括下級網(wǎng)元接口向索引服 務器發(fā)送查詢請求，查詢請求包括短消息標識；根據(jù)短消息標識和映射關系，索引服務器獲 取短消息標識對應的服務器標識；索引服務器向下級網(wǎng)元接口返回包括服務器標識的查詢 響應。本實施例中，短消息標識為MSG_ID ；服務器標識為服務器IP地址。本實施例增加了索引服務器，用來保存原始消息當前保存的核心服務區(qū)地址，從 而在接收到短消息狀態(tài)報告后，能將短消息狀態(tài)報告發(fā)送至對應的特定核心服務器，從而 能充分發(fā)揮多臺核心服務器處理優(yōu)勢，解決了大容量短信網(wǎng)關狀態(tài)報告處理的問題。實施例二在實施例一的基礎上，為確保網(wǎng)關的高處理能力，同時又能保證狀態(tài)報告索引服 務器的安全可靠性，可設置多組狀態(tài)報告索引服務器，每一組對應特定的MSG_ID范圍。圖 6為本發(fā)明實施例二短消息狀態(tài)報告處理方法的流程圖。如圖6所示，在短消息發(fā)送階段， 本實施例包括步驟S202 核心服務器接收短消息發(fā)送請求，保存原始短消息；步驟S204:獲取上述短消息的MSG_ID，根據(jù)負載均衡算法，核心服務器發(fā)送映射 信息報文至短消息標識對應的索引服務器，指示索引服務器對映射關系進行存儲；映射信息包括短消息標識與服務器標識的映射關系；步驟S206 將短消息通過下級網(wǎng)元接口發(fā)送至用戶終端。在短消息狀態(tài)報告階段，本實施例包括步驟S212 下級網(wǎng)元接口接收短消息狀態(tài)報告；步驟S214:根據(jù)負載均衡算法，下級網(wǎng)元接口向短消息標識對應的索引服務器發(fā) 送查詢請求，查詢請求包括短消息標識；步驟S216 根據(jù)短消息標識和映射關系，索引服務器獲取短消息標識對應的服務 器標識；索引服務器向下級網(wǎng)元接口返回包括服務器標識的查詢響應；步驟S218 下級網(wǎng)元接口將短消息狀態(tài)報告發(fā)送至服務器標識對應的核心服務 器；步驟S220 核心服務器進行原始短消息和短消息狀態(tài)報告的匹配，生成相應話單。本實施例中，負載均衡算法為求余算法或Hash算法等通用分組算法。以求余算法 為例由核心服務器根據(jù)MSG_ID對最大組數(shù)η求余數(shù)，并根據(jù)余數(shù)等于0到(η_1)分別將 索引報文發(fā)送至1到η的狀態(tài)報告索引服務器組中，并由此保證了狀態(tài)報告索引服務器的 負載均衡。本實施例中，為滿足大容量的需求，狀態(tài)報告索引服務器可以設置多組，具體數(shù)量 可根據(jù)容量情況而定。由于狀態(tài)報告索引服務器可根據(jù)短信網(wǎng)關容量需求不斷增加，不存 在能力瓶頸，使得短信網(wǎng)關的容量可以不斷擴展。同時，本方法支持高可靠性設計，當某一 索引服務器出現(xiàn)故障時，協(xié)同工作的備用索引服務器能夠立即接管索引服務，保證了業(yè)務 的安全可靠。實施例三本實施例將在實施例一、二的基礎上，對具體步驟進行細化，并結(jié)合實際場景的描 述。圖7為本發(fā)明實施例三短消息狀態(tài)報告處理方法的示意圖。如圖7所示，根據(jù)軟件邏 輯，將系統(tǒng)劃分為SP接口、核心服務器組、下級網(wǎng)元接口 ；同時，增加索引服務器，用來保存 原始消息當前保存的核心服務器地址。為滿足大容量的需求，并保證索引服務器的安全可 靠性，索引服務器設置多組。本實施例包括一、SP提交短信后，首先通過SP接口將消息負荷分擔至核心服務器層。核心服務 器將消息通過下級網(wǎng)元接口層將消息發(fā)送至下級網(wǎng)元后，向索引服務器發(fā)送一個報文，該 報文標明該條短消息的MSG_ID與處理該消息的服務器IP地址的映射關系。一個簡單的報 文格式示例如下
權利要求
1.一種短消息狀態(tài)報告的處理方法，其特征在于，包括接收短消息狀態(tài)報告；根據(jù)所述短消息狀態(tài)報告中短消息標識，向索引服務器查詢所述短消息標識對應的服 務器標識；將所述短消息狀態(tài)報告發(fā)送至所述服務器標識對應的核心服務器。
2.根據(jù)權利要求1所述的方法，其特征在于，所述接收短消息狀態(tài)報告的步驟之前還 包括核心服務器接收短消息發(fā)送請求，保存原始短消息；將所述短消息通過下級網(wǎng)元接口 發(fā)送至用戶終端；所述下級網(wǎng)元接口將短消息狀態(tài)報告發(fā)送至所述服務器標識對應的核心服務器的步 驟之后還包括核心服務器進行原始短消息和短消息狀態(tài)報告的匹配。
3.根據(jù)權利要求2所述的方法，其特征在于核心服務器接收短消息發(fā)送請求的步驟之后還包括核心服務器發(fā)送映射信息至索引 服務器，所述映射信息包括短消息標識與服務器標識的映射關系；所述索引服務器存儲所 述映射關系；所述下級網(wǎng)元接口向索引服務器查詢所述短消息標識對應的服務器標識的步驟具體 包括下級網(wǎng)元接口向索引服務器發(fā)送查詢請求，所述查詢請求包括所述短消息標識；根 據(jù)所述短消息標識和映射關系，所述索引服務器獲取所述短消息標識對應的服務器標識; 所述索引服務器向所述下級網(wǎng)元接口返回包括所述服務器標識的查詢響應。
4.根據(jù)權利要求3所述的方法，其特征在于，當所述索引服務器有多臺時，所述核心服 務器發(fā)送映射信息至索引服務器的步驟具體包括根據(jù)負載均衡算法，所述核心服務器發(fā) 送映射信息報文至短消息標識對應的索引服務器；所述下級網(wǎng)元接口向索引服務器發(fā)送查詢請求的步驟具體包括根據(jù)所述負載均衡算 法，所述下級網(wǎng)元接口向所述短消息標識對應的索引服務器發(fā)送查詢請求。
5.根據(jù)權利要求4所述的方法，其特征在于，所述負載均衡算法為通用分組算法。
6.根據(jù)權利要求1-5中任一項所述的方法，其特征在于，所述短消息標識為MSG_ID；所 述服務器標識為服務器IP地址。
7.一種短消息狀態(tài)報告的處理系統(tǒng)，其特征在于，包括索引服務器、下級網(wǎng)元接口、核 心服務器，其中所述索引服務器，用于保存所述短消息標識與服務器標識的對應關系；所述下級網(wǎng)元接口，用于接收短消息狀態(tài)報告，根據(jù)所述短消息狀態(tài)報告中短消息標 識，向所述索引服務器查詢所述短消息標識對應的服務器標識，并將所述短消息狀態(tài)報告 發(fā)送至所述服務器標識對應的核心服務器；所述核心服務器，用于接收所述短消息狀態(tài)報告。
8.根據(jù)權利要求7所述的系統(tǒng)，其特征在于，所述核心服務器包括接收模塊，用于接收短消息發(fā)送請求；處理模塊，用于保存原始短消息，并將所述短消息通過下級網(wǎng)元接口發(fā)送至用戶終端；映射模塊，用于發(fā)送映射信息至索引服務器，所述映射信息包括短消息標識與核心服務器標識的映射關系；匹配模塊，用于接收所述短消息狀態(tài)報告，進行原始短消息和短消息狀態(tài)報告的匹配。
9.根據(jù)權利要求7所述的系統(tǒng)，其特征在于，當所述索引服務器有多臺時，所述核心服 務器還包括存儲負載均衡模塊，用于根據(jù)負載均衡算法和短消息標識，確定存儲映射關系 的索引服務器；所述下級網(wǎng)元接口對應包括查詢負載均衡模塊，用于根據(jù)所述負載均衡算法，向所述 短消息標識對應的索引服務器發(fā)送查詢請求。
10.根據(jù)權利要求9所述的系統(tǒng)，其特征在于，所述負載均衡算法為求余算法或Hash算法。
11.根據(jù)權利要求7-10中任一項所述的系統(tǒng)，其特征在于，所述短消息標識為MSG_ID； 所述服務器標識為服務器IP地址。
全文摘要
本發(fā)明公開了一種短消息狀態(tài)報告的處理方法及系統(tǒng)。該方法包括接收短消息狀態(tài)報告；根據(jù)短消息狀態(tài)報告中短消息標識，向索引服務器查詢短消息標識對應的服務器標識；將短消息狀態(tài)報告發(fā)送至服務器標識對應的核心服務器。本發(fā)明各實施例中，增加了索引服務器，用來保存原始消息當前保存的核心服務區(qū)地址，從而在接收到短消息狀態(tài)報告后，能將短消息狀態(tài)報告發(fā)送至對應的特定核心服務器，從而能充分發(fā)揮多臺核心服務器處理優(yōu)勢，解決了大容量短信網(wǎng)關狀態(tài)報告處理的問題。
文檔編號H04W28/08GK102045668SQ200910236560
公開日2011年5月4日 申請日期2009年10月26日 優(yōu)先權日2009年10月26日
發(fā)明者孫金霞, 尤夢, 張承輝, 李偉 申請人:中國移動通信集團公司