專利名稱：接口遞送報(bào)告消息的傳輸方法
技術(shù)領(lǐng)域：
本發(fā)明涉及通信技術(shù)領(lǐng)域，并且特別地，涉及一種接口遞送報(bào) 告消息的傳輸方法。
背景技術(shù)：
多4某體消息業(yè)務(wù)(Multimedia Messaging Service, MMS )是一 種能夠在手才幾和手才幾之間以及手沖幾和Email月良務(wù)器等其〗也應(yīng)用之間 傳送多媒體內(nèi)容的消息服務(wù)。當(dāng)今，多媒體消息業(yè)務(wù)正在快速發(fā)展。 目前，國內(nèi)的很多省份都新建了多媒體消息中心(MMSC),并且有 些省份還建立了多套多媒體消息中心。隨著3G業(yè)務(wù)的開展，多媒 體消息業(yè)務(wù)會得到更大的發(fā)展，多媒體消息中心的容量和多媒體消 息中心的lt量都將會大大的增加。
目前，在一個(gè)省內(nèi)有幾套多媒體消息中心的情況很多，由于一 個(gè)省的多個(gè)用戶歸屬于不同的多媒體消息中心，而一個(gè)省內(nèi)用戶之 間發(fā)送的消息在整個(gè)多媒體消息中所占的比例很高，這樣就使多媒 體消息中心之間的消息轉(zhuǎn)發(fā)量大大增加。另外，由于消息在目前的 網(wǎng)絡(luò)中各個(gè)多媒體消息中心的情況不一樣，例如，某些多媒體網(wǎng)絡(luò) 中心之間的網(wǎng)絡(luò)情況不理想，因此，在這些多々某體消息中心之間相 互遞送報(bào)告時(shí)往往無法接收，導(dǎo)致報(bào)告遞送的成功率很低。
目前，多媒體消息MM4接口遞送報(bào)告消息通常采用簡單郵件 傳輸協(xié)議(SMTP )進(jìn)行傳輸，由于SMTP本身協(xié)議需要進(jìn)行HELO、
MAILFROM、 RECPTO、 DATA、 QUIT等命令的交互，導(dǎo)致交互 過程進(jìn)行緩慢，因此，在交互的過程中交互的雙方需要相互等待。 其具體地表現(xiàn)是一條消息在交互過程中發(fā)送前后的時(shí)延很大。另外， 在目前的網(wǎng)絡(luò)運(yùn)行中多媒體消息中心經(jīng)常出現(xiàn)某些異常，導(dǎo)致遞送 報(bào)告發(fā)送失敗。
然而，目前尚未提出能夠解決上述問題的方案。

發(fā)明內(nèi)容
考慮到上述問題而做出本發(fā)明，為此，本發(fā)明的主要目的在于 提供一種接口遞送報(bào)告消息的傳輸方案。
根據(jù)本發(fā)明的實(shí)施例，提供了 一種接口遞送報(bào)告消息的傳輸方法。
該方法包括步驟S202，目的多+某體消息中心生成文件，將多 媒體消息中心之間接口的接口遞送報(bào)告消息寫入文件中；以及步驟 S204，源多媒體消息中心獲取寫入消息后的文件，并從寫入消息后 的文件中得到接口遞送寺艮告消息。
其中，在步驟S202之前，進(jìn)一步包括步驟A,源多士某體消 息中心根據(jù)其本身的配置判斷源多^某體消息中心是否支持獲取文件 形式的接口遞送報(bào)告消息；如果判斷結(jié)果為支持，則執(zhí)行步驟S202 和步驟S204;如果判斷結(jié)果為不支持，則執(zhí)行步驟B;以及步驟B,
目的多媒體消息中心直接將接口遞送報(bào)告消息發(fā)送至源多媒體消息中心。
在上述步驟S202中，定時(shí)和/或定量生成文件，并將一條或多 條4妄口遞送才艮告消息寫入文件。
此外，在步驟S204中，源多媒體消息中心從目的多々某體消息 中心內(nèi)的配置目錄獲取寫入消息后的文件。
此外，在該方法中，源多々某體消息中心可以通過文件傳輸協(xié)i義 獲耳又寫入消息后的文件。
此時(shí)，在步驟S204之前，進(jìn)一步包括設(shè)置源多媒體消息中 心的文件傳，命妨4義用戶名、文件傳llT協(xié)i義密碼，以及在目的多々某體 消息中心內(nèi)設(shè)置配置目錄。其中，在目的多媒體消息中心分別對每 個(gè)源多媒體消息中心設(shè)置配置目錄。
此外，在步驟S204之后，該方法可以進(jìn)一步包括源多媒體 消息中心查詢源用戶終端原始^是交的源用戶終端與多々某體消息中心 之間接口的接口遞送報(bào)告消息的相關(guān)信息和發(fā)送狀態(tài)，并才艮據(jù)相關(guān) 信息和發(fā)送狀態(tài)生成源話單。
在步-驟A之前，還可以進(jìn)一步包括當(dāng)源用戶終端要求將原始 才是交的源用戶終端與多々某體消息中心之間4妄口的4妄口遞送才艮告消息 發(fā)送至源用戶終端時(shí)，源用戶終端發(fā)出獲取源用戶終端與多々某體消 息中心之間接口的接口遞送報(bào)告消息的請求。
根據(jù)本發(fā)明的另 一 實(shí)施例，提供了 一種接口遞送報(bào)告消息的傳 輸方法。
該方法包括第一步驟，目的多々某體消息中心生成文件，將多 媒體消息中心之間接口的接口遞送報(bào)告消息寫入文件中；以及第二 步驟，源多媒體消息中心以文件傳輸協(xié)議的方式獲取寫入消息后的 文件，并從寫入消息后的文件中得到接口遞送報(bào)告消息。
其中，在第一步驟之前，進(jìn)一步包括源多4某體消息中心根據(jù) 其本身的配置判斷源多々某體消息中心是否支持以文件傳輸協(xié)議方式
獲取接口遞送報(bào)告消息；如果判斷結(jié)果為支持，則執(zhí)行第一步驟和 第二步驟；如果判斷結(jié)果為不支持，則^U于第三步驟；以及第三步 驟，目的多媒體消息中心直接將接口遞送報(bào)告消息發(fā)送至源多媒體 消息中心。
通過本發(fā)明以文件形式傳輸多媒體消息中心之間接口的接口遞 送報(bào)告消息，可以提高多媒體消息中心之間接口的接口遞送報(bào)告消 息的傳輸成功率，減小多媒體消息中心之間的信息量，并且提高了 處理遞送才艮告的效率。


此處所說明的附圖用來提供對本發(fā)明的進(jìn)一步理解，構(gòu)成本申 請的一部分，本發(fā)明的示意性實(shí)施例及其說明用于解釋本發(fā)明，并 不構(gòu)成對本發(fā)明的不當(dāng)限定。在附圖中
圖1是根據(jù)本發(fā)明實(shí)施例的多媒體消息中心系統(tǒng)的框圖2是根據(jù)本發(fā)明實(shí)施例的接口遞送報(bào)告消息的傳輸方法的流 禾呈圖；以及
圖3是根據(jù)本發(fā)明實(shí)施例的接口遞送報(bào)告消息的傳輸方法的處 理實(shí)例的信令流程圖。
具體實(shí)施例方式
在本實(shí)施例中，提供了 一種接口遞送報(bào)告消息的傳輸方法。
在描述該方法之前，首先將描述可以實(shí)現(xiàn)#4居本實(shí)施例的方法 的系統(tǒng)。圖1示出了根據(jù)本發(fā)明實(shí)施例的多々某體消息中心系統(tǒng)的結(jié)構(gòu)。
如圖1所示，該系統(tǒng)包4舌
多媒體消息中心(MMSC)，用于保存和轉(zhuǎn)發(fā)多媒體消息，并 負(fù)責(zé)用戶關(guān)于多々某體業(yè)務(wù)的管理；
用戶終端，用于編輯多媒體消息，并通過WAP網(wǎng)關(guān)發(fā)送，接 收多媒體消息，其與MMSC之間通過MM1接口連接；
EMAIL服務(wù)器，其與多媒體消息中心之間通過MM3接口相聯(lián)， 用于發(fā)送和接收多々某體郵件；
其它MMSC,其間通過MM4接口相聯(lián)，主要用于互相轉(zhuǎn)發(fā)不 同歸屬的多々某體消息中心的用戶的消息；
用戶數(shù)據(jù)庫，其與多媒體消息中心之間通過MM6接口相聯(lián)， 用于集中進(jìn)行用戶信息的保存和查詢；
增值應(yīng)用，其與多媒體消息中心之間采用MM7接口相聯(lián)，增 值應(yīng)用提供商實(shí)體負(fù)責(zé)發(fā)送和接收消息；以及
計(jì)費(fèi)中心，其與多4某體消息中心之間采用MM8接口相聯(lián)，計(jì) 費(fèi)詳細(xì)話單的獲取。
基于上述系統(tǒng)，下面將詳細(xì)描述才艮據(jù)本發(fā)明實(shí)施例的方法。
如圖2所示，根據(jù)本發(fā)明實(shí)施例的多媒體消息中心之間接口遞 送報(bào)告消息的傳輸方法包括步驟S202,目的多媒體消息中心生成 文件，將多4某體消息中心之間接口 (即，上述的MM4接口，并且 如果沒有特別限定，下文中出現(xiàn)的接口遞送報(bào)告消息均指MM4接 口遞送報(bào)告消息)的接口遞送報(bào)告消息寫入文件中；以及步驟S204 ， 源多媒體消息中心獲取寫入消息后的文件，并從寫入消息后的文件 中得到接口遞送才艮告消息。
其中，在步驟S202之前，進(jìn)一步包括步驟A,源多々某體消 息中心根據(jù)其本身的配置判斷源多媒體消息中心是否支持獲取文件 形式的接口遞送報(bào)告消息；如果判斷結(jié)果為支持，則執(zhí)行步驟S202 和步驟S204;如果判斷結(jié)果為不支持，則執(zhí)行步驟B;以及步驟B, 目的多媒體消息中心直接將接口遞送報(bào)告消息發(fā)送至源多媒體消息 中心。
其中，步驟A中判斷的目的是為了防止某些多4某體消息中心不 能處理文件形式的接口遞送報(bào)告消息，導(dǎo)致不能接收文件。在步驟 B中可以采用傳統(tǒng)的SMTP方式，進(jìn)行SMTP所需的信令交互，不 將該消息寫入文件，而是直接發(fā)送接口遞送報(bào)告消息到源多媒體消 息中心。
并且，在上述步驟S202中，定時(shí)和/或定量生成文件，并將一 條或多條接口遞送報(bào)告消息寫入文件。
此外，在步驟S204中，源多々某體消息中心從目的多i某體消息 中心內(nèi)的配置目錄獲取寫入消息后的文件。
此外，在該方法中，優(yōu)選地，源多4某體消息中心可以通過文件 傳輸協(xié)議(FTP)獲取寫入消息后的文件，這是因?yàn)镕TP是常用的 文件傳輸方式，具有4艮好的通用性，并且具有理想的傳輸效率。
此時(shí)，在步驟S204之前，進(jìn)一步包括設(shè)置源多々某體消息中 心的文件傳輸協(xié)議用戶名、文件傳輸協(xié)議密碼，以及在目的多媒體 消息中心內(nèi)設(shè)置配置目錄，這樣源多媒體消息中心就能夠提取配置 目錄中文件中的消息。其中，在目的多少某體消息中心可以分別對每
個(gè)源多媒體消息中心設(shè)置配置目錄，優(yōu)選地，配置目錄可以與目的
多々某體消息中心的ID相對應(yīng)。
并且，在步驟S204之后，可以進(jìn)一步包括源多媒體消息中 心查詢源用戶終端的原始提交消息的相關(guān)信息和發(fā)送狀態(tài)，即，查 詢源用戶終端原始提交的接口 MM1的接口遞送報(bào)告消息(即，圖3 中步驟3.1中發(fā)送的MM1接口遞送報(bào)告消息)的相關(guān)信息和發(fā)送狀 態(tài)，并一艮據(jù)得到的相關(guān)信息和發(fā)送狀態(tài)生成源話單。
此外，在上述步驟A之前，還可以進(jìn)一步包4舌當(dāng)源用戶終端 要求將原始提交的接口 MM1的接口遞送報(bào)告消息發(fā)送至源用戶終 端時(shí)，源用戶終端發(fā)出獲取該原始提交的MM1的接口遞送報(bào)告消 息的請求。
圖3示出了在終端向終端發(fā)送消息時(shí)上述方法的具體處理的詳 細(xì)過禾呈。結(jié)合圖1中所示的系統(tǒng)，3口圖3所示，其可以包4舌以下步 驟
步驟3.1，源用戶終端將MM1 -接口的多々某體消息^是交到源多々某 體消息中心；
步驟3.2,源多々某體消息中心接收到該消息后返回MM1接口提 交消息響應(yīng)；
步驟3.3,源多媒體消息中心根據(jù)目的終端號碼的路由信息將多 媒體消息轉(zhuǎn)發(fā)到目的多媒體消息中心；
步驟3.4,目的多々某體消息中心將MM4接口轉(zhuǎn)發(fā)消息響應(yīng)返回 至源多媒體消息中心；
步驟3.5 ，目的多媒體消息中心將MM1接口通告消息發(fā)送至目 的用戶終端；
步驟3.6，目的用戶終端將MM1接口通告響應(yīng)消息返回至目的 多媒體消息中心；
步驟3.7，目的用戶終端根據(jù)通告消息將MM1接口獲取多媒體 消息請求發(fā)送到目的多媒體消息中心；
步驟3.8，目的多媒體消息中心將MMl接口獲取多媒體消息響 應(yīng)發(fā)送至目的用戶終端；
步驟3.9,目的用戶終端將MM1接口確認(rèn)消息發(fā)送至目的多媒 體消息中心；
步驟3.10,目的多媒體消息中心產(chǎn)生目的方話單(即，目的話 單(T話單))，源多媒體消息中心根據(jù)其本身的配置判斷其是否支 持文件形式的多媒體消息MM4接口遞送才艮告消息，如果支持，則 將遞送報(bào)告消息信息寫到文件中，該文件可以定時(shí)、定量產(chǎn)生，并 且可以一個(gè)文件寫入多條多媒體遞送報(bào)告信息內(nèi)容；如果不支持， 則采用傳統(tǒng)的SMTP方式，即，不將MM4遞送凈艮告消息寫入文件， 而是直接將該消息發(fā)送至源多媒體消息中心；
步驟3.U,源多媒體消息中心根據(jù)設(shè)置定時(shí)通過FTP提取目的 多媒體消息中心內(nèi)的配置目錄下的遞送報(bào)告消息信息文件；(即，通 過步驟3.10和步驟3.11實(shí)現(xiàn)了根據(jù)本發(fā)明的MM4接口遞送才艮告消 息的傳輸方法)
步驟3.12，源多媒體消息中心根據(jù)獲取的遞送報(bào)告消息信息文 件進(jìn)行處理，查詢之前步驟3.1中發(fā)送的MM1接口遞送消息的相關(guān) 信息(字段)和發(fā)送狀態(tài)(例如，發(fā)送成功、和發(fā)送失敗等狀態(tài))、
生成源話單話單(即，發(fā)送方(O話單)，該話單與步驟3.10中的 話基本相同)、并根據(jù)源用戶終端是否要求將步驟S3.1中發(fā)送的 MM1的接口的遞送報(bào)告消息發(fā)送至源用戶終端來發(fā)送獲取該消息 的請求。
綜上所述，本發(fā)明采用FTP協(xié)議來承載多媒體消息MM4接口 遞送報(bào)告消息，源多媒體消息中心從目的多媒體消息中心主動獲取 寫入MM4接口的接口遞送才艮告消息的文件，可以有效克月良由于 SMTP協(xié)議中HELO、 MAIL FROM 、 RECP TO、 DATA、 QUIT等 命令交互所引起的緩慢，降低了時(shí)間延遲，同時(shí)減少多媒體消息中 心在MM4接口處理遞送報(bào)告時(shí)所占用的鏈接數(shù)量和相關(guān)資源占用； 另夕卜，可以避免在相關(guān)技術(shù)中出現(xiàn)的導(dǎo)致MM4接口遞送報(bào)告消息 發(fā)送失敗的MMSC異?，F(xiàn)象。
本發(fā)明成本低、實(shí)現(xiàn)簡單，借助于本發(fā)明的技術(shù)方案，可以提 高多媒體消息中心之間MM接口遞送報(bào)告消息的傳輸成功率，減小 多媒體消息中心之間的信息量，提高了處理遞送報(bào)告的效率，從而 有助于整個(gè)多媒體消息中心性能的提升。
以上所述僅為本發(fā)明的優(yōu)選實(shí)施例而已，并不用于限制本發(fā)明， 對于本領(lǐng)域的4支術(shù)人員來i兌，本發(fā)明可以有各種更改和變化。凡在 本發(fā)明的精神和原則之內(nèi)，所作的任何修改、等同替換、改進(jìn)等， 均應(yīng)包含在本發(fā)明的保護(hù)范圍之內(nèi)。
權(quán)利要求
1.一種接口遞送報(bào)告消息的傳輸方法，其特征在于，包括步驟S202，目的多媒體消息中心生成文件，將多媒體消息中心之間接口的接口遞送報(bào)告消息寫入所述文件中；以及步驟S204，源多媒體消息中心獲取所述寫入消息后的文件，并從所述寫入消息后的文件中得到所述接口遞送報(bào)告消息。
2. 根據(jù)權(quán)利要求1所述的接口遞送報(bào)告消息的傳輸方法，其特征 在于，在所述步驟S202之前，進(jìn)一步包括步驟A，所述源多媒體消息中心根據(jù)其本身的配置判斷所 述源多媒體消息中心是否支持獲取文件形式的所述接口遞送 報(bào)告消息；如果判斷結(jié)果為支持，則沖丸行所述步驟S202和所述步驟 S204;如果判斷結(jié)果為不支持，則執(zhí)行步驟B;以及所述步驟B，所述目的多媒體消息中心直接將所述接口遞 送報(bào)告消息發(fā)送至所述源多媒體消息中心。
3. 根據(jù)權(quán)利要求1所述的接口遞送報(bào)告消息的傳輸方法，其特征 在于，在所述步驟S202中，定時(shí)和/或定量生成所述文件，并 將一條或多條所述4妄口遞送才艮告消息寫入所述文件中。
4. 根據(jù)權(quán)利要求1所述的接口遞送報(bào)告消息的傳輸方法，其特征 在于，在所述步驟S204中，所述源多媒體消息中心從所述目 的多媒體消息中心內(nèi)的配置目錄獲取所述寫入消息后的文件。
5. 根據(jù)權(quán)利要求1至4中任一項(xiàng)所述的接口遞送報(bào)告消息的傳輸 方法，其特征在于，所述源多媒體消息中心通過文件傳輸協(xié)議 獲耳又所述寫入消息后的文件。
6. 根據(jù)權(quán)利要求5所述的接口遞送報(bào)告消息的傳輸方法，其特征 在于，在所述步驟S204之前，進(jìn)一步包括i殳置所述源多々某 體消息中心的文件傳輸協(xié)議用戶名、文件傳輸協(xié)議密碼，以及 在所述目的多媒體消息中心內(nèi)設(shè)置所述配置目錄。
7. 根據(jù)權(quán)利要求6所述的接口遞送報(bào)告消息的傳輸方法，其特征 在于，在所述目的多媒體消息中心內(nèi)分別對每個(gè)所述源多媒體 消息中心i殳置所述配置目錄。
8. 根據(jù)權(quán)利要求1至4中任一項(xiàng)所述的接口遞送報(bào)告消息的傳輸 方法，其特征在于，在所述步驟S204之后，進(jìn)一步包括所 述源多i某體消息中心查詢源用戶終端的原始^是交的所述源用 戶終端與多媒體消息中心之間接口的接口遞送報(bào)告消息的相 關(guān)信息和發(fā)送狀態(tài)，并根據(jù)所述相關(guān)信息和所述發(fā)送狀態(tài)生成 源話單。
9. 根據(jù)權(quán)利要求2所述的接口遞送報(bào)告消息的傳輸方法，其特征 在于，在所述步驟A之前，進(jìn)一步包括當(dāng)所述源用戶終端 要求將所述原始提交的源用戶終端與多媒體消息中心之間接 口的4妄口遞送才艮告消息發(fā)送至所述源用戶終端時(shí)，所述源用戶 終端發(fā)出獲取所述源用戶終端與多媒體消息中心之間接口的 接口遞送報(bào)告消息的請求。
10. —種接口遞送報(bào)告消息的傳輸方法，其特征在于，包括第一步驟，目的多媒體消息中心生成文件，將多媒體消息 中心之間*接口的4妄口遞送才艮告消息寫入所述文件中；以及 第二步驟，源多媒體消息中心以文件傳輸協(xié)議的方式獲取 所述寫入消息后的文件，并從所述寫入消息后的文件中得到所 述接口遞送報(bào)告消息。
11.根據(jù)權(quán)利要求10所述的接口遞送報(bào)告消息的傳輸方法，其特 征在于，在所述第一步驟之前，進(jìn)一步包括所述源多媒體消息中心根據(jù)其本身的配置判斷所述源多 媒體消息中心是否支持以文件傳輸協(xié)議方式獲取所述接口遞 送報(bào)告消息；如果判斷結(jié)果為支持，則執(zhí)行所述第一步驟和第二步驟； 如果判斷結(jié)果為不支持，則扭J于第三步艱《；以及所述第三步驟，所述目的多媒體消息中心直接將所述接口 遞送報(bào)告消息發(fā)送至所述源多媒體消息中心。
全文摘要
一種多媒體消息中心之間接口遞送報(bào)告消息的傳輸方法，包括步驟S202，目的多媒體消息中心生成文件，將多媒體消息中心之間接口的接口遞送報(bào)告消息寫入文件中；以及步驟S204，源多媒體消息中心獲取寫入消息后的文件，并從寫入消息后的文件中得到接口遞送報(bào)告消息。通過使用本發(fā)明，可以提高多媒體消息中心之間MM接口遞送報(bào)告的傳輸成功率，減小多媒體消息中心之間的信息量，并且提高了處理遞送報(bào)告的效率。
文檔編號H04W4/12GK101098509SQ200710129460
公開日2008年1月2日 申請日期2007年7月17日 優(yōu)先權(quán)日2007年7月17日
發(fā)明者翔 周, 王景祥, 王永銀 申請人:中興通訊股份有限公司