專利名稱：一種移動數(shù)據(jù)業(yè)務(wù)網(wǎng)絡(luò)系統(tǒng)及其通信方法
技術(shù)領(lǐng)域：
本發(fā)明涉及移動數(shù)據(jù)業(yè)務(wù)通信技術(shù)，特別是指一種能支持任意點的移動用戶與業(yè)務(wù)提供端(SP)互連互通的移動數(shù)據(jù)業(yè)務(wù)網(wǎng)絡(luò)系統(tǒng)及其通信方法。
短信息業(yè)務(wù)(SMS)是在移動用戶與業(yè)務(wù)提供端(SP)之間以短消息方式進行業(yè)務(wù)請求與受理的一種業(yè)務(wù)方式，它分為兩種一種是由移動用戶(MS)發(fā)起的短信請求，稱之為拉操作方式(PULL)；另一種是由業(yè)務(wù)提供端發(fā)起的短信請求，稱之為推操作方式(PUSH)。但是，由于前面所述的各個短信網(wǎng)關(guān)相互獨立、不能互連成一體的網(wǎng)絡(luò)結(jié)構(gòu)，如果用戶和業(yè)務(wù)提供端處于兩個不同的區(qū)域網(wǎng)中，就無法完成此種短信服務(wù)，使得短信息的雙向業(yè)務(wù)只能在本地范圍內(nèi)實現(xiàn)，而不能支持全國范圍內(nèi)移動用戶與業(yè)務(wù)提供端的短信息業(yè)務(wù)，因此，導(dǎo)致目前開展的業(yè)務(wù)基本上是PUSH類業(yè)務(wù)，而使很多雙向業(yè)務(wù)，如異地短信查分、與電臺合作進行短信有獎競猜等等業(yè)務(wù)受到地域限制，而無法順利展開。
本發(fā)明的技術(shù)方案具體是這樣實現(xiàn)的一種移動數(shù)據(jù)業(yè)務(wù)網(wǎng)絡(luò)系統(tǒng)，至少包括一個以上短信息中心(SMC)負責(zé)上傳移動用戶的短信息請求，下傳短信息到移動用戶，并提供短信息狀態(tài)報告；一個以上業(yè)務(wù)控制點(SCP)用于接受上傳的業(yè)務(wù)請求，并根據(jù)從業(yè)務(wù)數(shù)據(jù)庫中查詢的結(jié)果給出相應(yīng)的應(yīng)答；一個以上業(yè)務(wù)提供端(SP)負責(zé)提供移動用戶所需的短信息服務(wù)；至少一個業(yè)務(wù)管理訪問點(SMAP)用于提供業(yè)務(wù)管理者與業(yè)務(wù)管理點(SMP)之間的接口；至少一個業(yè)務(wù)管理點(SMP)用于實現(xiàn)業(yè)務(wù)的管理，其一端與SCP相連，另一端與SMAP相連；關(guān)鍵在于它還包括一個以上開放業(yè)務(wù)代理(OSP)通過OSP之間的互連來連接不同區(qū)域的SMC或SCP，一個OSP可同時與一個以上本地的SMC相連，且同時通過連接點(FEP)連接本地的SCP，通過應(yīng)用程序接口(API)與SP相連，作為SMC、SCP以及SP的信息中介。
其中，所述的連接點(FEP)為一個連接模塊，內(nèi)嵌于SCP之中，用于OSP與SCP間的協(xié)議轉(zhuǎn)換。所述的應(yīng)用程序接口(API)為一個應(yīng)用接口模塊，內(nèi)嵌于SP之中，用于提供統(tǒng)一的標準的編程接口和協(xié)議。
一種基于上述移動數(shù)據(jù)業(yè)務(wù)網(wǎng)實現(xiàn)的通信方法，該方法包括上行過程和下行過程；其中，上行過程是移動用戶(MS)使用短消息發(fā)起請求，經(jīng)由短信息中心(SMC)和移動數(shù)據(jù)業(yè)務(wù)網(wǎng)傳送到業(yè)務(wù)提供端(SP)，它至少包括以下的步驟a1.SMC將移動用戶提交上來的業(yè)務(wù)請求短消息發(fā)給發(fā)端開放業(yè)務(wù)代理(OSP)；b1.發(fā)端OSP將用戶信息及業(yè)務(wù)信息提交SCP，并向SCP提出短消息業(yè)務(wù)路由請求；c1.SCP對該用戶提供該業(yè)務(wù)請求的可行性進行鑒權(quán)并查詢收端SP的路由，然后返回路由信息；d1.發(fā)端OSP按照路由信息將業(yè)務(wù)請求轉(zhuǎn)發(fā)到收端OSP，同時向收端OSP發(fā)出轉(zhuǎn)發(fā)業(yè)務(wù)短消息到SP的請求；收端OSP收到轉(zhuǎn)發(fā)業(yè)務(wù)短消息到SP的請求后，向SP發(fā)送OSP下發(fā)短消息請求，得到肯定應(yīng)答后收端OSP將該業(yè)務(wù)請求提交給SP，由SP受理該請求；下行過程是SP通過移動數(shù)據(jù)業(yè)務(wù)網(wǎng)和SMC向MS發(fā)送短消息，它至少包括以下的步驟a2.SP將業(yè)務(wù)信息或處理后的響應(yīng)信息提交給所連接的源OSP，同時發(fā)SP提交短消息請求給OSP；b2.源OSP根據(jù)目的用戶信息向SCP提出用戶路由請求，SCP對該SP能否將請求發(fā)至目的用戶以及該用戶能否接受進行鑒權(quán)，并查詢目的用戶路由，然后返回路由信息；c2.源OSP按照路由信息將業(yè)務(wù)信息或響應(yīng)信息轉(zhuǎn)發(fā)給目的OSP，并向目的OSP發(fā)OSP轉(zhuǎn)發(fā)短消息到SMC的請求，目的OSP收到后，通知SCP計費，同時將收到的業(yè)務(wù)信息或響應(yīng)信息提交給SMC；d2.SMC以短消息形勢下發(fā)該業(yè)務(wù)信息或響應(yīng)信息給移動用戶，同時給目的OSP返回下發(fā)狀態(tài)報告；e2.目的OSP根據(jù)收到的下發(fā)狀態(tài)報告向SCP發(fā)出計費請求或補款請求，并將下發(fā)狀態(tài)報告轉(zhuǎn)發(fā)給源OSP，再由源OSP將下發(fā)狀態(tài)報告轉(zhuǎn)發(fā)給SP。
該上行過程和下行過程中進一步包括SMC或OSP或SCP或SP或移動用戶對相應(yīng)請求回復(fù)應(yīng)答的過程。所述的相應(yīng)請求至少包括短消息業(yè)務(wù)路由請求、轉(zhuǎn)發(fā)業(yè)務(wù)短消息到SP的請求、OSP下發(fā)短消息的請求、SP提交短消息的請求、用戶路由請求、OSP轉(zhuǎn)發(fā)短消息到SMC的請求、計費請求、補款請求、SP授權(quán)請求。
所述的下行過程是SP響應(yīng)移動用戶業(yè)務(wù)請求發(fā)響應(yīng)短信息給請求用戶的過程，或主動發(fā)送短信息給指定移動用戶的過程。
步驟b1所述的用戶信息至少包括用戶賬號、用戶路由；所述的業(yè)務(wù)信息至少包括計費方式、費率信息、業(yè)務(wù)描述。
所述OSP與SMC之間的通信采用短信息點對點協(xié)議(SMPP)標準；所述OSP、SCP、SP實體之間的通信可擴展的置標語言(XML)標準和移動數(shù)據(jù)業(yè)務(wù)網(wǎng)點對點協(xié)議(CMPP)。該CMPP協(xié)議為短消息業(yè)務(wù)協(xié)議，所述的短消息業(yè)務(wù)協(xié)議至少包括短消息業(yè)務(wù)路由請求及應(yīng)答、轉(zhuǎn)發(fā)業(yè)務(wù)短消息到SP的請求及應(yīng)答、OSP下發(fā)短消息的請求及應(yīng)答、SP提交短消息的請求及應(yīng)答、用戶路由請求及應(yīng)答、OSP轉(zhuǎn)發(fā)短消息到SMC的請求及應(yīng)答、計費請求及應(yīng)答、補款請求及應(yīng)答、SP授權(quán)請求及應(yīng)答。
一種基于上述移動數(shù)據(jù)業(yè)務(wù)網(wǎng)實現(xiàn)的商務(wù)付費方法，該方法至少包括以下的步驟a.業(yè)務(wù)提供端(SP)向所接入的開放業(yè)務(wù)代理(OSP)發(fā)出支付請求，OSP再將此支付請求轉(zhuǎn)發(fā)至SCP；b.SCP按支付請求進行計費，并向被計費的移動用戶發(fā)出支付通知。
該付費方法進一步包括以下步驟a.SP向移動數(shù)據(jù)業(yè)務(wù)網(wǎng)網(wǎng)關(guān)OSP發(fā)起登錄請求；b.OSP收到SP的登錄請求后，向SCP提出授權(quán)請求，SCP經(jīng)過鑒權(quán)后，向SP發(fā)送授權(quán)請求應(yīng)答；c.SP得到授權(quán)后，即可向OSP發(fā)出支付請求。
該方法還包括以下步驟當OSP收到SP發(fā)來的支付請求后，要向SP回復(fù)支付請求的應(yīng)答；當SCP收到OSP發(fā)來的支付請求后，要向OSP回復(fù)支付請求的應(yīng)答；當移動用戶收到SCP發(fā)來的系統(tǒng)支付通知后，要向SCP回復(fù)對系統(tǒng)支付通知的應(yīng)答。
所述OSP與SMC之間的通信采用短信息點對點協(xié)議(SMPP)標準；所述OSP、SCP、SP實體之間的通信可擴展的置標語言(XML)標準和移動數(shù)據(jù)業(yè)務(wù)網(wǎng)點對點協(xié)議(CMPP)。該CMPP協(xié)議為電子商務(wù)業(yè)務(wù)協(xié)議，所述的電子商務(wù)業(yè)務(wù)協(xié)議至少包括SP授權(quán)請求及應(yīng)答、SP向OSP提出的支付請求及應(yīng)答、OSP向SCP提出的支付請求及應(yīng)答、系統(tǒng)支付通知及應(yīng)答。
由上述技術(shù)方案可以看出，本發(fā)明的關(guān)鍵就是在原有的移動智能網(wǎng)和短信息中心(SMC)之間增加了一個開放的、統(tǒng)一的管理接口層，即在SMC與智能網(wǎng)的業(yè)務(wù)控制點(SCP)之間增加了一個開放業(yè)務(wù)代理(OSP)及相應(yīng)的連接點(FEP)和應(yīng)用接口(API)，所有實體之間的通信均通過OSP代理，其作為SMC、SCP與SP之間的中介點，可用標準的接口與協(xié)議實現(xiàn)各個區(qū)域網(wǎng)之間移動用戶與業(yè)務(wù)提供端的互連、互通，進而在該網(wǎng)絡(luò)中通過短信息方式來傳遞移動用戶和SP之間的服務(wù)請求與響應(yīng)，實現(xiàn)移動用戶與業(yè)務(wù)提供端之間的業(yè)務(wù)交互過程。讓用戶能夠通過短信息方式訪問任何一個接入網(wǎng)中的業(yè)務(wù)提供端，獲取相應(yīng)的服務(wù)，同時也讓業(yè)務(wù)提供端能夠發(fā)送信息到用戶，并且無需關(guān)心網(wǎng)絡(luò)細節(jié)，進而使移動用戶可獲得全國范圍內(nèi)的短信服務(wù)支持。
該系統(tǒng)還接受SCP的控制及使用，包括計費、支付。
本發(fā)明通信過程中所發(fā)的各種請求與應(yīng)答均基于現(xiàn)有的XML標準格式，該XML標準是一種基于文本流的協(xié)議體系，定義了互聯(lián)網(wǎng)上交換數(shù)據(jù)的標準，通常用于服務(wù)器與服務(wù)器之間、服務(wù)器與瀏覽器之間大量的數(shù)據(jù)交換，它既可以作為標準交換語言擔(dān)負描述交換數(shù)據(jù)的作用，又可以作為派生其它置標語言的元語言，方便的定義各種置標語言標準。本發(fā)明方案中所述的CMPP協(xié)議即是以XML標準為元語言擴展出的移動數(shù)據(jù)業(yè)務(wù)網(wǎng)上的傳輸標準。
可見，本發(fā)明的網(wǎng)絡(luò)系統(tǒng)不僅覆蓋范圍廣、支持任意點用戶與SP互通業(yè)務(wù)，且能配合多種靈活資費體系，為移動用戶提供方便快捷、靈活全面的短信服務(wù)。
另外，本發(fā)明采用OSP的互連來傳輸用戶與SP之間的大量互通信息，只有少量重要的信息通過SCP間的互連來傳輸，進而降低了對SCP的資源占用及整個系統(tǒng)的運營成本。
本發(fā)明所提供的方法不僅實現(xiàn)了移動網(wǎng)絡(luò)用戶與任意業(yè)務(wù)提供端之間短信息的業(yè)務(wù)互通，而且操作與應(yīng)用安全、簡單、方便、快捷，為用戶提供更多方便。
圖6為本發(fā)明中通信方法的一實施例下行過程消息流示意圖；圖7為本發(fā)明中通信方法的另一實施例消息流示意圖。
本發(fā)明所組建的移動移動數(shù)據(jù)業(yè)務(wù)網(wǎng)，能為移動用戶和SP提動短信息業(yè)務(wù)的請求與受理，以及電子商務(wù)的支付業(yè)務(wù)等服務(wù)；而移動用戶的費用支付，包括網(wǎng)絡(luò)通信費和短信內(nèi)容費用，都統(tǒng)一在SCP中進行統(tǒng)計、核算和扣除。
圖1為本發(fā)明整個移動數(shù)據(jù)業(yè)務(wù)網(wǎng)系統(tǒng)的組網(wǎng)結(jié)構(gòu)圖，如圖1所示，本發(fā)明移動數(shù)據(jù)業(yè)務(wù)網(wǎng)中的基本實體主要包括業(yè)務(wù)控制點(SCP)、開放業(yè)務(wù)代理(OSP)、短信息中心(SMC)、業(yè)務(wù)管理接入點(SMAP)、業(yè)務(wù)管理點(SMP)、業(yè)務(wù)服務(wù)提供商(SP)，每一實體具體的功能如下所述SCP(Service Control Point)業(yè)務(wù)控制點，是智能網(wǎng)的核心構(gòu)件，它用于存儲用戶數(shù)據(jù)和業(yè)務(wù)邏輯，實現(xiàn)業(yè)務(wù)邏輯的執(zhí)行、支撐用戶語音維護、記錄話單、訪問業(yè)務(wù)數(shù)據(jù)等功能。SCP通過FEP與OSP相連接，F(xiàn)EP(Front End Process)是SCP和OSP間的連接點，其作為一個連接模塊內(nèi)嵌于SCP之中，負責(zé)SCP與OSP間的協(xié)議轉(zhuǎn)換，實現(xiàn)SCP和OSP之間的通信。SCP通過FEP接收OSP送來的鑒權(quán)請求、計費請求、路由請求，根據(jù)請求查詢業(yè)務(wù)數(shù)據(jù)庫給出相應(yīng)的應(yīng)答。
OSP(Open Service Proxy)開放業(yè)務(wù)代理，作為整個移動數(shù)據(jù)業(yè)務(wù)網(wǎng)的連接核心，負責(zé)各短信息中心的連接，短信息的轉(zhuǎn)發(fā)，話單的記錄，并請求其所歸屬的SCP進行費用統(tǒng)計與扣除，通過FEP與一個SCP連接。一個OSP可以同時連接多個SMC，并且，不同區(qū)域的OSP相互連接構(gòu)成一個OSP層，通過不同OSP之間的直接互連，進而間接將所有本地、異地的SMC和SCP進行連接，形成一個完整的移動數(shù)據(jù)業(yè)務(wù)網(wǎng)絡(luò)體系，以方便地開展全國性的業(yè)務(wù)，達到一點接入，全網(wǎng)服務(wù)的目的。
SMC(Short Message Center)短信息中心，負責(zé)下發(fā)短信息到移動用戶，上傳移動用戶的短信息請求，并提供短信息狀態(tài)報告。
SMAP(Service Manage Access Point)智能網(wǎng)的業(yè)務(wù)管理訪問點，提供業(yè)務(wù)管理者與SMP間的接口，利用此接入功能能使業(yè)務(wù)管理者通過SMP管理業(yè)務(wù)。
SMP(Service Manage Point)業(yè)務(wù)管理點，主要實現(xiàn)業(yè)務(wù)的管理，包括業(yè)務(wù)管理、用戶管理、業(yè)務(wù)數(shù)據(jù)管理等，在本發(fā)明中與SMAP一起實現(xiàn)移動數(shù)據(jù)業(yè)務(wù)網(wǎng)絡(luò)系統(tǒng)的運營和管理功能。
SP(Service Provider)業(yè)務(wù)提供端，用來進行短信息服務(wù)的主動下發(fā)和對移動用戶服務(wù)請求的響應(yīng)，它通過API接口與OSP相連，API是一個移動數(shù)據(jù)業(yè)務(wù)網(wǎng)的應(yīng)用程序接口，其作為一個應(yīng)用接口模塊內(nèi)嵌于SP中，主要負責(zé)將業(yè)務(wù)提供端以統(tǒng)一的標準編程接口接入，并負責(zé)CMPP協(xié)議的轉(zhuǎn)換和透傳，實現(xiàn)SP在一點，即從一個接入OSP接入，便可提供全網(wǎng)服務(wù)。
再參見圖1所示，本發(fā)明實際上就是在智能網(wǎng)、短信息中心和業(yè)務(wù)提供端之間增加了一個OSP代理層，該代理層通過標準的開放接口可實現(xiàn)本地、異地多個SMC和SCP的互連，進而使處于任何地區(qū)的移動用戶和業(yè)務(wù)提供端都能互連互通，提供或接受對方的服務(wù)。在實現(xiàn)業(yè)務(wù)請求與受理的過程中，OSP與SMC之間的通信采用短信息點對點協(xié)議(SMPP)標準；OSP、SCP、SP實體之間的通信可擴展的置標語言(XML)標準和移動數(shù)據(jù)業(yè)務(wù)網(wǎng)點對點協(xié)議(CMPP)。
基于上述實體的結(jié)構(gòu)與功能特性，當一個移動用戶需要從SP那里獲取相關(guān)信息服務(wù)時，由移動用戶發(fā)起請求，屬于短信息業(yè)務(wù)的PULL方式，它包括移動用戶向SP發(fā)請求的上行過程如圖2所示，以及SP響應(yīng)請求下發(fā)信息的下行過程如圖3所示1)移動用戶用手機進入到相應(yīng)的移動數(shù)據(jù)業(yè)務(wù)網(wǎng)菜單項中，選擇想要獲取的服務(wù)欄目，如股票信息，手機將該短消息請求上傳到SMC。
2)SMC根據(jù)配置的路由信息，將此短消息請求發(fā)到用戶端OSP。
3)用戶端OSP收到此短消息請求后，立即向SCP發(fā)出業(yè)務(wù)路由請求，即該短消息請求是屬于哪個SP所提供的業(yè)務(wù)。
4)用戶端OSP根據(jù)業(yè)務(wù)路由的結(jié)果，將短消息請求轉(zhuǎn)發(fā)到相應(yīng)的SP的客戶端，有必要時可轉(zhuǎn)發(fā)到SP所連接的業(yè)務(wù)端OSP，由業(yè)務(wù)端OSP將請求轉(zhuǎn)發(fā)到SP。
5)之后，由SP對該請求進行處理后，將服務(wù)信息如股票信息，提交給所接入的業(yè)務(wù)端OSP，業(yè)務(wù)端OSP請求SCP對該SP進行鑒權(quán)，如判斷該SP是否有提交短消息的能力，并對此短消息請求進行用戶路由處理，即獲取該移動用戶所接入的用戶端OSP的地址。
6)業(yè)務(wù)端OSP將短消息轉(zhuǎn)發(fā)到用戶端OSP，用戶端OSP請求其接入的SCP進行計費處理，收到SCP返回的肯定應(yīng)答后，然后將短消息請求轉(zhuǎn)發(fā)到其接入的SMC處。
7)SMC將此短消息下發(fā)到移動用戶的終端--手機上，然后給業(yè)務(wù)端OSP返回短消息下發(fā)的狀態(tài)報告，業(yè)務(wù)端OSP根據(jù)狀態(tài)報告，給予SCP計費數(shù)據(jù)的確認信息，給以SP提交短消息的應(yīng)答。
當SP需要向移動用戶主動推送服務(wù)信息時，由SP主動發(fā)起請求，屬于短信息業(yè)務(wù)的PUSH方式，其具體交互過程如圖3所示1)SP將提交短消息的請求提交到其所接入的OSP處，OSP請求SCP對該SP進行鑒權(quán)，如判斷該SP是否有提交短消息的能力，并對此短消息請求進行用戶路由處理，即獲取該移動用戶所接入的OSP的地址。
2)OSP將短消息轉(zhuǎn)發(fā)到目的OSP，目的OSP請求其接入的SCP進行計費處理，收到SCP返回的肯定應(yīng)答后，然后將短消息請求轉(zhuǎn)發(fā)到其接入的SMC處。
3)SMC將此短消息下發(fā)到移動用戶的終端--手機上，然后給OSP返回短消息下發(fā)的狀態(tài)報告，OSP根據(jù)狀態(tài)報告，給予SCP計費數(shù)據(jù)的確認信息，給以SP提交短消息的應(yīng)答。
本發(fā)明的移動數(shù)據(jù)業(yè)務(wù)網(wǎng)絡(luò)系統(tǒng)還可以支持電子商務(wù)的業(yè)務(wù)，移動用戶可以用手機來進行電子商務(wù)支付活動，如SP所提供的消費服務(wù)，小件商品的購買等等，其具體的實現(xiàn)流程如圖4所示1)首先SP請求登錄到其接入的OSP上，OSP請求SCP給SP授權(quán)，SP登錄成功后才能繼續(xù)往下處理。
2)移動用戶對SP所提供的消費業(yè)務(wù)提出請求，SP進行相應(yīng)的業(yè)務(wù)處理后，向其接入的OSP提出支付請求。
3)OSP請求SCP對SP進行鑒權(quán)處理，確定是合法的SP用戶后，向SCP提出支付請求。
4)SCP進行相應(yīng)的扣費處理，然后通知移動用戶接入的OSP進行系統(tǒng)支付通知。
5)目的OSP以短消息的形式通知用戶已經(jīng)支付，并要求SMC下發(fā)短消息到用戶手機終端，并提供狀態(tài)報告。
由此可見，本發(fā)明的網(wǎng)絡(luò)架構(gòu)不僅支持移動網(wǎng)絡(luò)用戶與任意點的業(yè)務(wù)提供端通過短信方式互通業(yè)務(wù)，而且該方法的操作與應(yīng)用安全、簡單、方便、快捷，為用戶提供更多方便。
那么，在本發(fā)明的移動數(shù)據(jù)業(yè)務(wù)網(wǎng)絡(luò)系統(tǒng)中，按照上述幾種短信息業(yè)務(wù)方式通信時，以CMPP協(xié)議完成的消息流傳遞過程如圖5～圖7所示。以一個深圳用戶請求一個移動數(shù)據(jù)業(yè)務(wù)網(wǎng)服務(wù)為例，該用戶想從北京的新浪服務(wù)提供商處獲取相關(guān)的服務(wù)業(yè)務(wù)，如圖5、圖6所示，其相關(guān)的具體消息流如下1)SMC將該業(yè)務(wù)請求轉(zhuǎn)發(fā)到深圳的OSP，此時深圳OSP向其接入的SCP請求業(yè)務(wù)路由，以獲取相應(yīng)的新浪SP所連接的目的OSP的地址。此時OSP將發(fā)送如下消息體來向SCP請求業(yè)務(wù)路由<pre listing-type="program-listing"> ＜gw-scp＞ ＜！--本OSP在網(wǎng)絡(luò)中的標識，全網(wǎng)唯一＞ ＜svc-routing gw-id＝″szgw1″＞ ?。?！--請求該業(yè)務(wù)的移動用戶的手機號碼＞ ?。約rc＞＜addr val＝″13828812345″＞＜/addr＞＜/src＞ ?。?！--新浪的服務(wù)代碼，可能還有業(yè)務(wù)代碼，SP的唯一標識＞ ?。糳st＞＜addr val＝″8888001″＞＜/addr＞＜/dst＞ ＜/svc-routing＞ ＜/gw-scp＞</pre>2)SCP查詢數(shù)據(jù)庫中的路由信息后，給深圳OSP返回一個應(yīng)答，指出新浪SP所在的北京OSP的地址。比如返回如下消息體<pre listing-type="program-listing"> ＜gw-scp＞ ＜svc-routing-rsp ＜！--SP標識，如新浪為8888＞ sp-usr＝″8888″ ＜！--SP業(yè)務(wù)代碼，如股票查詢＞ srv-code＝″001″ ＜！--SP所歸屬的OSP，如北京的OSP＞ gw-id＝″bjgw1″ ＜！--此路由信息能緩存的時間＞ ttl＝″60″ ＜！--狀態(tài)碼，標識此為成功的應(yīng)答＞ stat＝″0″＞ ＜/svc-routing-rsp＞ ＜/gw-scp＞</pre>3)深圳OSP收到SCP的路由應(yīng)答后，根據(jù)結(jié)果，將深圳移動用戶的業(yè)務(wù)請求轉(zhuǎn)發(fā)到目的北京OSP。發(fā)送如下消息體到目的OSP<pre listing-type="program-listing"> ＜gw-gw＞ ?。迹?-指明SP在SCP中的帳號，源OSP和目的OSP＞ ＜sm-fwd-sp sp-usr＝″sina-sms″src＝″szgw1″dst＝″bjgw1″＞ ?。約m esm＝″0″dcs＝″0″len＝″120″＞ ＜！--業(yè)務(wù)請求最終到達的SP(新浪)的標識，全網(wǎng)唯一＞ ?。糳st＞＜addr val＝″8888″＞＜/addr＞＜/dst＞ ＜！--業(yè)務(wù)請求短消息的編碼方式和編碼后的具體內(nèi)容＞ ?。約m-cont cod＝″BASE64″data＝″AABBCCDDEEFF″＞＜/sm-cont＞ ＜/sm＞ ＜/sm-fwd-sp＞ ＜/gw-gw＞</pre>4)北京OSP直接將業(yè)務(wù)請求短消息下發(fā)給由sp-usr所標識的新浪SP，然后給深圳OSP返回一個下發(fā)成功的應(yīng)答。下發(fā)短消息的消息體如下<pre listing-type="program-listing"> ＜gw-sp＞ ＜gw-dvr＞ ?。約m esm＝″0″dcs＝″0″len＝″120″＞ ?。約rc＞＜addr val＝″13828812345″＞＜/addr＞＜/src＞ ?。糳st＞＜addr val＝″8888″＞＜/addr＞＜/dst＞ ?。?！--業(yè)務(wù)短消息編碼方式和編碼后的具體內(nèi)容＞ ?。約m-cont cod＝″BASE64″data＝″AABBCCDDEEFF″＞＜/sm-cont＞ ＜/sm＞ ＜！--計費信息，手機號碼，費率，計費方式(按月、按條)＞ ＜chg-info msid＝″13828812345″rate＝″10″type＝″1″＞ ＜desc cod＝″BASE64″data＝″FFGGHHIIJJKK″＞＜/desc＞ ＜/chg-info＞ ＜/gw-dvr＞ ＜/gw-sp＞</pre>
5)北京的新浪提供商響應(yīng)該深圳移動用戶的業(yè)務(wù)請求，該新浪SP對短消息請求進行了業(yè)務(wù)處理后，需要向用戶返回業(yè)務(wù)處理結(jié)果，則新浪SP以短消息的方式提交給其接入的北京OSP，消息體如下<pre listing-type="program-listing"> ＜gw-sp＞ ＜！--業(yè)務(wù)類型和業(yè)務(wù)操作碼＞ ＜sp-sub svc-t＝″001″op-t＝″1111″＞ ＜sm esm＝″0″dcs＝″0″len＝″100″＞ ＜src＞＜addr val＝″8888″＞＜/addr＞＜/src＞ ＜dst＞＜addr val＝″13828812345″＞＜/addr＞＜/dst＞ ＜！--業(yè)務(wù)短消息編碼方式和編碼后的具體內(nèi)容＞ ＜sm-cont cod＝″BASE64″data＝″AABBCCDDEEFF″＞＜/sm-cont＞ ＜/sm＞ ＜！--計費信息，手機號碼，費率，計費方式(按月、按條)＞ ＜chg-info msid＝″13828812345″rate＝″15″type＝″1″＞ ＜desc cod＝″BASE64″data＝″FFGGHHIIJJKK″＞＜/desc＞ ＜/chg-info＞ ?。?sp-sub＞ ＜gw-sp＞</pre>6)北京OSP向SCP請求用戶路由信息，以確定該短消息由哪個OSP進行轉(zhuǎn)發(fā)處理，轉(zhuǎn)發(fā)到移動用戶終端。路由請求消息體如下<gw-scp>
<usr-routing sp-usr＝″sina-sms″svc-t＝″001″op-t＝″1111″gw-id＝″bjgw1″>
<！--用戶的手機號碼>
<dst><addr val＝″13828812345″></addr></dst>
</usr-routing></gw-scp>
7)SCP查詢數(shù)據(jù)庫中的用戶路由信息，給北京OSP返回路由應(yīng)答，應(yīng)答消息中包含手機用戶接入的深圳OSP和深圳SMC的地址。應(yīng)答消息體如下<pre listing-type="program-listing"> ＜gw-scp＞ ＜usr-routing-rsp ＜！--手機用戶接入的SMC(深圳)的地址＞ smc-addr＝″13800755500″ ＜！--手機用戶接入的OSP(深圳)的地址，全網(wǎng)唯一標識＞ gw-id＝″szgw1″ ＜！--標識此為成功應(yīng)答＞ status＝″0″＞ ＜！--該OSP和SMC所接入的用戶號碼段＞ ＜code-area＞＜addr val＝″138288″＞＜/addr＞＜/code-area＞ ＜/usr-routing-rsp＞ ＜/gw-scp＞</pre>8)北京OSP根據(jù)路由結(jié)果，請求深圳OSP轉(zhuǎn)發(fā)此短消息到指定深圳SMC，再由深圳SMC下發(fā)短消息到移動用戶。轉(zhuǎn)發(fā)請求消息體如下<pre listing-type="program-listing"> ＜gw-gw＞ ＜sm-fwd-smc sp-usr＝″sina-sms″svc-t＝″001″op-t＝″1111″ ＜！--目的SMC(深圳)的地址＞ smc-addr＝″13800755500″ ＜！--請求轉(zhuǎn)發(fā)的源OSP(北京)標識＞ src-gw＝″bjgw1″＞ ?。約m esm＝″0″dcs＝″0″len＝″120″＞ ＜！--用戶的手機號碼＞ ＜dst＞＜addr val＝″13828812345″＞＜/addr＞＜/dst＞ ＜！--業(yè)務(wù)短消息編碼方式和編碼后的具體內(nèi)容＞ ＜sm-cont cod＝″BASE64″data＝″AABBCCDDEEFF″＞＜/sm-cont＞ ?。?sm＞ ?。?！--計費信息，手機號碼，費率，計費方式(按月、按條)＞<dp n="d14"/> ?。糲hg-info msid＝″13828812345″rate＝″15″type＝″1″＞ ?。糳esc cod＝″BASE64″data＝″FFGGHHIIJJKK″＞＜/desc＞ ?。?chg-info＞ ＜/sm-fwd-smc＞ ＜/gw-gw＞</pre>9)深圳OSP收到轉(zhuǎn)發(fā)請求后，立即請求其接入的SCP進行計費處理，再得到計費請求的肯定應(yīng)答后，才請求深圳SMC下發(fā)短消息給用戶。計費請求消息體如下<pre listing-type="program-listing"> ＜gw-scp＞ ＜sm-chg-req ＜！--SP(新浪)帳號，業(yè)務(wù)編碼，業(yè)務(wù)操作碼，記錄流水號＞ sp-usr＝″sina-sms″svc-t＝″001″op-t＝″1111″rid＝″4C0A0″ ＜！--源OSP(北京)的標識，全網(wǎng)唯一＞ src-gw＝″bjgw1″ ＜！--目的OSP(深圳)的標識，全網(wǎng)唯一＞ gw-id＝″szgw1″ ＜！--目的SMC(深圳)的地址＞ smc-addr＝″13800755500″ pri＝″0″＞ ＜！--接收短消息的手機號碼＞ ＜dst＞＜addr val＝″13828812345″＞＜/addr＞＜/dst＞ ＜！--計費信息，手機號碼，費率，計費方式(按月、按條)＞ ＜chg-info msid＝″13828812345″rate＝″15″type＝″1″＞＜/chg-info＞ ＜/sm-chg-req＞ ＜/gw-scp＞</pre>10)深圳OSP在得到計費的肯定應(yīng)答后，通過SMPP協(xié)議將短消息轉(zhuǎn)發(fā)到指定的深圳SMC，最終由深圳SMC將短消息下發(fā)到深圳移動用戶的終端---手機上。
11)當深圳SMC給予深圳OSP下發(fā)短消息的狀態(tài)報告時，深圳OSP根據(jù)報告狀態(tài)的結(jié)果向SCP發(fā)送補款確認請求，確認計費或取消計費。請求的消息體如下<gw-scp><！--請求計費時的記錄流水號，確認計費狀態(tài)，請求計費OSP標識><sm-cnfm-req rid＝″4C0A0″state＝″1″gw-id＝″szgw1″></sm-cnfm-req></gw-scp>
至此，該深圳移動用戶和北京新浪SP的整個業(yè)務(wù)交互過程，包含上行和下行過程就全部結(jié)束了。通過此通信過程，該深圳移動用戶即可獲得北京新浪服務(wù)商提供的服務(wù)，整個操作過程方便、快捷、簡單。
短消息的PUSH方式與PULL方式的下行過程完全一樣，只是短信息請求的主動發(fā)起方不同。
本發(fā)明的網(wǎng)絡(luò)結(jié)構(gòu)還支持移動用戶的電子商務(wù)的業(yè)務(wù)，比如當移動用戶消費了SP提供的服務(wù)，或者進行電子商務(wù)活動時，用戶需要向SP支付一定的費用，如圖7所示，其涉及到CMPP協(xié)議的消息流如下所述1)首先保證SP已經(jīng)登錄到了移動數(shù)據(jù)業(yè)務(wù)網(wǎng)中，即SP先向移動數(shù)據(jù)業(yè)務(wù)網(wǎng)網(wǎng)關(guān)OSP發(fā)起登錄請求，OSP接收到SP的登錄請求后，向SCP提出授權(quán)請求，經(jīng)過SCP鑒權(quán)認證后，由SCP發(fā)授權(quán)請求應(yīng)答給SP允許其登錄。為了保證SP登錄過程的安全性以及整個交易過程的可靠性，對SP登錄過程進行相應(yīng)的加密處理，因該加密過程不是本發(fā)明的重點，在此不再描述。
2)SP需要向移動用戶收取一定的費用時，就請求OSP進行支付活動，消息體如下<pre listing-type="program-listing"> ＜gw-sp＞ ＜sp-pay-req sp-usr＝″sina-sms″svc-t＝″001″op-t＝″11″sid＝″4″op＝″1″＞ ＜！--接收短消息的手機號碼＞ ＜dst＞＜addr val＝″13828812345″＞＜/addr＞＜/dst＞<dp n="d16"/> ＜！--計費信息，手機號碼，費率，計費方式(按月、按條)＞ ＜chg-info msid＝″13828812345″rate＝″50″type＝″1″＞ ＜desc cod＝”0”data＝″AABBCCDD″＞＜/desc＞ ＜/chg-info＞ ＜/sp-pay-req＞ ＜/gw-sp＞</pre>3)OSP在收到支付請求后，立即向SCP提出支付請求，對指定用戶進行扣費處理，消息體如下<pre listing-type="program-listing"> ＜gw-scp＞ ＜gw-pay-req sp-usr＝″sina-sms″svc-t＝″001″op-t＝″11″sid＝″4″＞ ＜！--接收短消息的手機號碼＞ ＜dst＞＜addr val＝″13828812345″＞＜/addr＞＜/dst＞ ＜！--計費信息，手機號碼，費率，計費方式(按月、按條)＞ ＜chg-info msid＝″13828812345″rate＝″50″type＝″1″＞ ＜desc cod＝”0”data＝”ABCD”＞＜/desc＞ ＜/chg-info＞ ＜/gw-pay-req＞ ＜/gw-scp＞</pre>4)SCP在進行扣費成功后，需要通知移動用戶支付已經(jīng)成功，SCP給被計費的手機用戶所接入的OSP發(fā)送系統(tǒng)支付通知，由OSP發(fā)往其所接入的SMC，最終再由SMC將通知發(fā)送到用戶終端上。消息體如下<pre listing-type="program-listing"> ＜gw-scp＞ ＜sys-ntf smc-addr＝″13800755500″dst-gw＝″szgw1″＞ ＜sm esm＝″0″dcs＝″0″len＝″120″＞ ＜src＞＜addr val＝”8888”＞＜/addr＞＜/src＞ ＜！--接收短消息的手機號碼＞ ＜dst＞＜addr val＝″13828812345″＞＜/addr＞＜/dst＞ ＜sm-cont cod＝″0″data＝″AABBCCDDEEFF″＞＜/sm-cont＞<dp n="d17"/> ＜/sm＞ ＜/sys-ntf＞ ＜/gw-scp＞</pre>至此，由SP方自動扣除為移動用戶提供服務(wù)的費用，同時向移動用戶發(fā)出支付通知的電子商務(wù)支付活動就已經(jīng)完成。
在本發(fā)明的網(wǎng)絡(luò)結(jié)構(gòu)中的OSP是與SMC相連，該OSP也可與非結(jié)構(gòu)化補充業(yè)務(wù)數(shù)據(jù)中心(USSDC)相連，實現(xiàn)移動用戶與業(yè)務(wù)提供端間的短信業(yè)務(wù)。
總之，以上所述僅為本發(fā)明的較佳實施例而已，并非用于限定本發(fā)明的保護范圍。
權(quán)利要求
1.一種移動數(shù)據(jù)業(yè)務(wù)網(wǎng)絡(luò)系統(tǒng)，至少包括一個以上短信息中心(SMC)負責(zé)上傳移動用戶的短信息請求，下傳短信息到移動用戶，并提供短信息狀態(tài)報告；一個以上業(yè)務(wù)控制點(SCP)用于接受上傳的業(yè)務(wù)請求，并根據(jù)從業(yè)務(wù)數(shù)據(jù)庫中查詢的結(jié)果給出相應(yīng)的應(yīng)答；一個以上業(yè)務(wù)提供端(SP)負責(zé)提供移動用戶所需的短信息服務(wù)；至少一個業(yè)務(wù)管理訪問點(SMAP)用于提供業(yè)務(wù)管理者與業(yè)務(wù)管理點(SMP)之間的接口；至少一個業(yè)務(wù)管理點(SMP)用于實現(xiàn)業(yè)務(wù)的管理，其一端與SCP相連，另一端與SMAP相連；其特征在于它還包括一個以上開放業(yè)務(wù)代理(OSP)通過OSP之間的互連來連接不同區(qū)域的SMC或SCP，一個OSP可同時與一個以上本地的SMC相連，且同時通過連接點(FEP)連接本地的SCP，通過應(yīng)用程序接口(API)與SP相連，作為SMC、SCP以及SP的信息中介。
2.根據(jù)權(quán)利要求1所述的網(wǎng)絡(luò)架構(gòu)，其特征在于所述的連接點(FEP)為一個連接模塊，內(nèi)嵌于SCP之中，用于OSP與SCP間的協(xié)議轉(zhuǎn)換。
3.根據(jù)權(quán)利要求1所述的網(wǎng)絡(luò)架構(gòu)，其特征在于所述的應(yīng)用程序接口(API)為一個應(yīng)用接口模塊，內(nèi)嵌于SP之中，用于提供統(tǒng)一的標準的編程接口和協(xié)議。
4.一種基于上述移動數(shù)據(jù)業(yè)務(wù)網(wǎng)實現(xiàn)的通信方法，其特征在于該方法包括上行過程和下行過程；其中，上行過程是移動用戶(MS)使用短消息發(fā)起請求，經(jīng)由短信息中心(SMC)和移動數(shù)據(jù)業(yè)務(wù)網(wǎng)傳送到業(yè)務(wù)提供端(SP)，它至少包括以下的步驟a1.SMC將移動用戶提交上來的業(yè)務(wù)請求短消息發(fā)給發(fā)端開放業(yè)務(wù)代理(OSP)；b1.發(fā)端OSP將用戶信息及業(yè)務(wù)信息提交SCP，并向SCP提出短消息業(yè)務(wù)路由請求；c1.SCP對該用戶提供該業(yè)務(wù)請求的可行性進行鑒權(quán)并查詢收端SP的路由，然后返回路由信息；d1.發(fā)端OSP按照路由信息將業(yè)務(wù)請求轉(zhuǎn)發(fā)到收端OSP，同時向收端OSP發(fā)出轉(zhuǎn)發(fā)業(yè)務(wù)短消息到SP的請求；收端OSP收到轉(zhuǎn)發(fā)業(yè)務(wù)短消息到SP的請求后，向SP發(fā)送OSP下發(fā)短消息請求，得到肯定應(yīng)答后收端OSP將該業(yè)務(wù)請求提交給SP，由SP受理該請求；下行過程是SP通過移動數(shù)據(jù)業(yè)務(wù)網(wǎng)和SMC向MS發(fā)送短消息，它至少包括以下的步驟a2.SP將業(yè)務(wù)信息或處理后的響應(yīng)信息提交給所連接的源OSP，同時發(fā)SP提交短消息請求給OSP；b2.源OSP根據(jù)目的用戶信息向SCP提出用戶路由請求，SCP對該SP能否將請求發(fā)至目的用戶以及該用戶能否接受進行鑒權(quán)，并查詢目的用戶路由，然后返回路由信息；c2.源OSP按照路由信息將業(yè)務(wù)信息或響應(yīng)信息轉(zhuǎn)發(fā)給目的OSP，并向目的OSP發(fā)OSP轉(zhuǎn)發(fā)短消息到SMC的請求，目的OSP收到后，通知SCP計費，同時將收到的業(yè)務(wù)信息或響應(yīng)信息提交給SMC；d2.SMC以短消息形勢下發(fā)該業(yè)務(wù)信息或響應(yīng)信息給移動用戶，同時給目的OSP返回下發(fā)狀態(tài)報告；e2.目的OSP根據(jù)收到的下發(fā)狀態(tài)報告向SCP發(fā)出計費請求或補款請求，并將下發(fā)狀態(tài)報告轉(zhuǎn)發(fā)給源OSP，再由源OSP將下發(fā)狀態(tài)報告轉(zhuǎn)發(fā)給SP。
5.根據(jù)權(quán)利要求4所述的通信方法，其特征在于所述的上行過程和下行過程中進一步包括SMC或OSP或SCP或SP或移動用戶對相應(yīng)請求回復(fù)應(yīng)答的過程。
6.根據(jù)權(quán)利要求5所述的通信方法，其特征在于所述的相應(yīng)請求至少包括短消息業(yè)務(wù)路由請求、轉(zhuǎn)發(fā)業(yè)務(wù)短消息到SP的請求、OSP下發(fā)短消息的請求、SP提交短消息的請求、用戶路由請求、OSP轉(zhuǎn)發(fā)短消息到SMC的請求、計費請求、補款請求、SP授權(quán)請求。
7.根據(jù)權(quán)利要求4所述的通信方法，其特征在于所述的下行過程是SP響應(yīng)移動用戶業(yè)務(wù)請求發(fā)響應(yīng)短信息給請求用戶的過程，或主動發(fā)送短信息給指定移動用戶的過程。
8.根據(jù)權(quán)利要求4所述的通信方法，其特征在于步驟b1所述的用戶信息至少包括用戶賬號、用戶路由；所述的業(yè)務(wù)信息至少包括計費方式、費率信息、業(yè)務(wù)描述。
9.根據(jù)權(quán)利要求4所述的通信方法，其特征在于所述OSP與SMC之間的通信采用短信息點對點協(xié)議(SMPP)標準；所述OSP、SCP、SP實體之間的通信可擴展的置標語言(XML)標準和移動數(shù)據(jù)業(yè)務(wù)網(wǎng)點對點協(xié)議(CMPP)。
10.根據(jù)權(quán)利要求9所述的通信方法，其特征在于所述的移動數(shù)據(jù)業(yè)務(wù)網(wǎng)點對點協(xié)議為短消息業(yè)務(wù)協(xié)議。
11.根據(jù)權(quán)利要求10所述的通信方法，其特征在于所述的短消息業(yè)務(wù)協(xié)議至少包括短消息業(yè)務(wù)路由請求及應(yīng)答、轉(zhuǎn)發(fā)業(yè)務(wù)短消息到SP的請求及應(yīng)答、OSP下發(fā)短消息的請求及應(yīng)答、SP提交短消息的請求及應(yīng)答、用戶路由請求及應(yīng)答、OSP轉(zhuǎn)發(fā)短消息到SMC的請求及應(yīng)答、計費請求及應(yīng)答、補款請求及應(yīng)答、SP授權(quán)請求及應(yīng)答。
12.一種基于上述移動數(shù)據(jù)業(yè)務(wù)網(wǎng)實現(xiàn)的商務(wù)付費方法，其特征在于該方法至少包括以下的步驟a.業(yè)務(wù)提供端(SP)向所接入的開放業(yè)務(wù)代理(OSP)發(fā)出支付請求，OSP再將此支付請求轉(zhuǎn)發(fā)至SCP；b.SCP按支付請求進行計費，并向被計費的移動用戶發(fā)出支付通知。
13.根據(jù)權(quán)利要求12所述的付費方法，其特征在于該方法進一步包括以下步驟a.SP向移動數(shù)據(jù)業(yè)務(wù)網(wǎng)網(wǎng)關(guān)OSP發(fā)起登錄請求；b.OSP收到SP的登錄請求后，向SCP提出授權(quán)請求，SCP經(jīng)過鑒權(quán)后，向SP發(fā)送授權(quán)請求應(yīng)答；c.SP得到授權(quán)后，即可向OSP發(fā)出支付請求。
14.根據(jù)權(quán)利要求12所述的付費方法，其特征在于該方法還包括以下步驟當OSP收到SP發(fā)來的支付請求后，要向SP回復(fù)支付請求的應(yīng)答；當SCP收到OSP發(fā)來的支付請求后，要向OSP回復(fù)支付請求的應(yīng)答；當移動用戶收到SCP發(fā)來的系統(tǒng)支付通知后，要向SCP回復(fù)對系統(tǒng)支付通知的應(yīng)答。
15.根據(jù)權(quán)利要求12所述的付費方法，其特征在于所述OSP與SMC之間的通信采用短信息點對點協(xié)議(SMPP)標準；所述OSP、SCP、SP實體之間的通信可擴展的置標語言(XML)標準和移動數(shù)據(jù)業(yè)務(wù)網(wǎng)點對點協(xié)議(CMPP)。
16.根據(jù)權(quán)利要求15所述的付費方法，其特征在于所述的移動數(shù)據(jù)業(yè)務(wù)網(wǎng)點對點協(xié)議為電子商務(wù)業(yè)務(wù)協(xié)議。
17.根據(jù)權(quán)利要求16所述的付費方法，其特征在于所述的電子商務(wù)業(yè)務(wù)協(xié)議至少包括SP授權(quán)請求及應(yīng)答、SP向OSP提出的支付請求及應(yīng)答、OSP向SCP提出的支付請求及應(yīng)答、系統(tǒng)支付通知及應(yīng)答。
全文摘要
本發(fā)明公開了一種移動數(shù)據(jù)業(yè)務(wù)網(wǎng)絡(luò)系統(tǒng)，至少包括一個以上短信息中心(SMC)，負責(zé)處理短消息；一個以上業(yè)務(wù)控制點(SCP)，用于接受業(yè)務(wù)請求并給出應(yīng)答；一個以上業(yè)務(wù)提供端(SP)，負責(zé)提供用戶所需的短信服務(wù)；至少一個業(yè)務(wù)管理訪問點(SMAP)，用于提供業(yè)務(wù)管理者與業(yè)務(wù)管理點(SMP)之間的接口；至少一個業(yè)務(wù)管理點(SMP)，用于實現(xiàn)業(yè)務(wù)的管理，同時與SCP和SMAP相連；關(guān)鍵在于它還包括一個以上開放業(yè)務(wù)代理(OSP)，通過OSP之間的互連來連接不同區(qū)域的SMC或SCP，一個OSP可同時與一個以上本地的SMC、SCP、SP相連，作為SMC、SCP及SP的信息中介。該網(wǎng)絡(luò)架構(gòu)支持任意點移動用戶與SP互通，且使用簡單方便。本發(fā)明同時公開了基于上述移動數(shù)據(jù)業(yè)務(wù)網(wǎng)的通信方法。
文檔編號H04W88/18GK1394089SQ01120019
公開日2003年1月29日 申請日期2001年7月4日 優(yōu)先權(quán)日2001年7月4日
發(fā)明者吳俊 , 車海平, 牛紅亮, 陳亮, 解彥良 申請人:華為技術(shù)有限公司