專利名稱：一種發(fā)送多媒體消息的遞送報告的方法及裝置的制作方法
技術(shù)領(lǐng)域：
本發(fā)明涉及多媒體移動通信技術(shù)，尤其是指 一種發(fā)送多媒體消息的遞送 報告的方法及裝置。
背景技術(shù)：
多媒體消息服務(wù)(MMS )是短信息服務(wù)(SMS )和增強型消息服務(wù)(EMS ) 的進一步發(fā)展，為個人多媒體移動通信服務(wù)提供了完整的端到端解決方案。 從通信內(nèi)容上講，多媒體消息包括圖像、音頻、視頻和數(shù)據(jù)等；從功能上講， 多媒體消息服務(wù)涵蓋了終端到終端、終端到應用設(shè)備(例如，增值業(yè)務(wù)提供 商SP、 Email服務(wù)器等)、應用設(shè)備到終端的多媒體消息通信。它不僅實現(xiàn) 了終端之間、終端和應用設(shè)備之間的信息傳遞，還實現(xiàn)了內(nèi)容的多樣性，包 括圖片、語音、圖像、數(shù)據(jù)和文本的各種組合。作為一個開放的媒體接入平 臺，MMS可以在移動用戶和互聯(lián)網(wǎng)內(nèi)容提供商的互動下，衍生出更豐富多 彩的內(nèi)容服務(wù)應用。由于用戶既可以是MMS的消費者，又可以是內(nèi)容開發(fā) 者，所以無疑會提高用戶對業(yè)務(wù)的使用興趣。
在運營商實際開展業(yè)務(wù)時，經(jīng)常需要使用多個多媒體消息服務(wù)中心 (MMSC)分別向用戶提供MMS業(yè)務(wù)，各個MMSC分別管理部分用戶， 提供相應用戶的接入功能。圖1所示為現(xiàn)有技術(shù)中MMSC與相關(guān)的各個網(wǎng) 絡(luò)設(shè)備之間的協(xié)議接口的示意圖。如圖1所示，MMSC與終端之間通過WAP 網(wǎng)關(guān)進4亍交互，所^^用的協(xié)-漢為MM1; MMSC與郵件l良務(wù)器之間采用MM3 協(xié)議進行交互，承載協(xié)議為電子郵件傳輸協(xié)議(SMTP) ; MMSC與服務(wù)商 提供商/內(nèi)容提供商(SP/CP)之間采用MM7協(xié)議進行交互，承載協(xié)議一般 為超文本傳輸協(xié)議(HTTP ),也可以使用其它的協(xié)議。以增值業(yè)務(wù)提供商(SP)到某個終端的業(yè)務(wù)為例，在現(xiàn)有技術(shù)中的彩信
業(yè)務(wù)中，現(xiàn)有彩信業(yè)務(wù)的遞送報告的處理流程為
步驟1, SP將需要發(fā)送給某個終端的彩信提交給彩信服務(wù)器； 步驟2,彩信服務(wù)器根據(jù)上述終端的號碼下發(fā)彩信通知給該終端； 步驟3，該終端根據(jù)接收到的彩信通知從彩信服務(wù)器提取彩信； 步驟4，彩信服務(wù)器向SP發(fā)送遞送報告，告知該終端已經(jīng)接收了彩信。 然而，在彩信業(yè)務(wù)中SP可以一次給多個用戶發(fā)送彩信，例如，SP—次
給10000個用戶發(fā)送天氣預報彩信。此時，在上述的處理流程中，步驟1只
需執(zhí)行1次，但步驟2~4則必須執(zhí)行10000次。由于彩信服務(wù)器每次只能
向SP發(fā)送1個遞送報告，因此彩信服務(wù)器就需要分10000次將各個終端提
取彩信的遞送報告返回給SP。
在日漸繁忙的移動通信網(wǎng)絡(luò)中，頻繁的發(fā)送遞送報告，將會降低發(fā)送遞送
報告的成功率，而且由于每次僅能發(fā)送一個遞送報告，因此發(fā)送效率較低，對
系統(tǒng)性能和網(wǎng)絡(luò)資源也造成較大的浪費。

發(fā)明內(nèi)容
有鑒于此，本發(fā)明實施例提供了一種發(fā)送多媒體消息的遞送報告的方法及 裝置，使得MMSC可以一次發(fā)送多個遞送報告。 本發(fā)明實施例中的技術(shù)方案是這樣實現(xiàn)的 一種發(fā)送多媒體消息的遞送報告的方法，該方法包括 緩存所需發(fā)送的多媒體消息的遞送報告；
使用預先設(shè)置的方式獲取至少兩個需發(fā)送的多媒體消息的遞送報告； 生成包括至少兩個需發(fā)送的多媒體消息的遞送報告的集合體； 輸出所述集合體。
本發(fā)明的實施例中還提供了 一種發(fā)送多媒體消息的遞送報告的裝置，該裝 置包括獲取模塊、生成模塊和輸出模塊；
所述獲取模塊，用于獲取至少兩個需發(fā)送的多媒體消息的遞送報告；所述生成模塊，用于根據(jù)獲取模塊所獲取的多媒體消息的遞送報告，生成
包括至少兩個需發(fā)送的多媒體消息的遞送報告的集合體；
所述輸出模塊，用于輸出所述的集合體。 綜上可知，本發(fā)明的實施例中提供了 一種發(fā)送多媒體消息的遞送報告的方 法及裝置。通過上述的方法和裝置，可首先緩存所需發(fā)送的遞送報告，并將所
緩存的多個遞送報告一次輸出，從而可以實現(xiàn)MMSC —次同時發(fā)送多個遞送報 告，因而提高了發(fā)送遞送報告的成功率，提高了對遞送報告的處理效率，同時 還減少了對網(wǎng)絡(luò)資源的浪費，提高了系統(tǒng)性能。


圖1所示為現(xiàn)有技術(shù)中MMSC與相關(guān)的各個網(wǎng)絡(luò)設(shè)備之間的協(xié)議接口 的示意圖。
圖2為本發(fā)明實施例中發(fā)送多媒體消息的遞送報告的方法的流程圖。 圖3為本發(fā)明實施例中發(fā)送多媒體消息的遞送報告的裝置的結(jié)構(gòu)圖。
具體實施例方式
為使本發(fā)明的技術(shù)方案和優(yōu)點表達得更加清楚明白，下面結(jié)合附圖及具 體實施例對本發(fā)明再作進一步詳細的i兌明。
圖2為本發(fā)明實施例中發(fā)送多媒體消息的遞送報告的方法的流程圖。如 圖2所示，本發(fā)明實施例中方法的流程包括如下所述的步驟
步驟201,緩存所需發(fā)送的多媒體消息的遞送報告。
即MMSC在接收到遞送報告時，并不馬上將所接收到的遞送報告發(fā)送 給相應的應用設(shè)備，而是緩存該所需發(fā)送的遞送報告，暫不發(fā)送。
步驟202,使用預先設(shè)置的方式獲取至少兩個需發(fā)送的多媒體消息的遞 送報告。
在本步驟中，所述的預先設(shè)置的方式可以為定時方式或定長方式，或是 上述兩種方式的結(jié)合。例如，所述的定長方式可以為根據(jù)預先設(shè)定的時間間隔(例如，5分鐘)從上述緩存的多媒體消息的遞送報告中獲取至少兩個
需發(fā)送的多媒體消息的遞送報告；所述定長的方式可以為當上述緩存的多 媒體消息的遞送報告的總長度達到預先設(shè)定的閾值(例如，2M)時，獲取 至少兩個所述緩存的多媒體消息的遞送報告。
步驟203,生成包括至少兩個需發(fā)送的多媒體消息的遞送報告的集合體。 在上述的步驟203中，可根據(jù)步驟202中所獲取的多媒體消息的遞送報 告生成一個包括上述至少兩個緩存的多媒體消息的遞送報告的消息或文件。 也就是說，可將所緩存的所需發(fā)送的至少兩個多媒體消息的遞送報告設(shè)置在 同一個消息或文件中，形成包括至少兩個遞送^^告的消息或文件。例如可 以對現(xiàn)有的遞送報告請求消息進行擴展，形成一個包括至少兩個遞送報告的 擴展后的遞送報告請求消息；也可以直接建立一個包括至少兩個遞送報告的 文件。具體的對現(xiàn)有的遞送報告請求消息的設(shè)置方式，以及包括至少兩個遞 送報告的文件的建立方式將分別在以下的第 一 、第二較佳實施例中進行詳細 地說明。
步驟204,輸出所述集合體。
以下將結(jié)合具體實施例對上述的發(fā)送多媒體消息的遞送報告的方法進 行更進一步的介紹。為了敘述的方便，在以下的實施例中，將以所述的MMSC 為彩信服務(wù)器，所述的多媒體消息的遞送報告為彩信的遞送報告為例對本發(fā) 明的技術(shù)方案進行詳細的介紹。由于對于其他的非彩信服務(wù)器的MMSC以 及其他的多媒體消息的遞送報告，所使用的方法是相同的，因此將不再贅述。
第一較佳實施例
現(xiàn)有的遞送報告支持多種協(xié)議接口 ，例如，超文本傳輸協(xié)議(HTTP) 接口 、簡單對象訪問協(xié)議(SOAP, Simple Object Access Protocol )接口等，
即所述的遞送報告可通過多種協(xié)議接口進行傳送。為了實現(xiàn)一次傳送多個遞 送報告，在本實施例中，需要對現(xiàn)有的對傳送遞送報告的協(xié)議接口進行擴展。 為了敘述的簡便，在如下所述的本發(fā)明實施例中，將以SOAP接口為例進行說明，對于其他協(xié)議接口的擴展方法與對SOAP接口的擴展方法相同，因此 將不再贅述。
在SOAP協(xié)議接口中，常用的遞送報告請求消息的格式如表1所示
表1
信息單元位置單元名稱備注
Transaction ID標題TransactionID
Message-Type正文MessageType
Version正文Version取值為此規(guī)范的編號，例如5.2.0。
MMS Relay/Server ID正文MMSRelayServerID
Message ID正文MessageID
Recipient address正文Recipient
Sender address正文Sender
Date and time正文TimeStamp
MM Status正文MMStatus枚^_可能值已超時、已接收、已拒 絕、不確定、已轉(zhuǎn)發(fā)。
MMS Status Error Code正文MMS Status Error Code具體的錯誤代碼請參見設(shè)備規(guī)范
Status text正文StatusText存放多條遞送報告的必選信息
其中，表1中遞送報告中的各個字段的名稱分別為Transaction ID為 事務(wù)標識，Message-Type為消息類型，Version為版本，MMS Relay/Server ID
為月良務(wù)器標識，Message ID為消息標識，Recipient address為4妄收方:l也址， Sender address為發(fā)送方地址，Date and time為曰期和時間，MM Status為多 媒體消息狀態(tài)，MMS Status Error Code為多媒體消息服務(wù)狀態(tài)錯誤碼，Status text為^犬態(tài)文本。
在SOAP協(xié)議接口中，常用的遞送報告響應消息的格式如表2所示
表2
信息單元位置單元名稱備注
Transaction ID標題TransactionID
Mcssag6-Typ6正文MessageType
MM7 Version正文MM7Version取值為此規(guī)范的編號，例如5.2.0。
Request Status正文StatusCode
Request Status text正文StatusText&Details
其中，MM7 Version為MM7協(xié)i義的版本，Request Status為請求信息狀
態(tài)，Request Status text為請求信息狀態(tài)文本，StatusCode為狀態(tài)碼。
對于遞送報告請求消息來說，保證業(yè)務(wù)可以正常處理的遞送報告中的五 個必選字,殳分另ll為Sender address、 Recipient address、 MessageID、 MMStatus和StatusText。在SOAP協(xié)議接口中， 一個現(xiàn)有的遞送報告請求消息中，僅 包括一個遞送報告的上述的五個必選字段，因此一個遞送報告請求消息只能 傳送一個遞送報告。所以，如果對上述遞送報告請求消息進行擴展，使得在 被擴展后的遞送報告請求消息中，能夠包括多個遞送報告的上述五個必選字 段，就可實現(xiàn)在一個遞送報告請求消息中傳送多個遞送報告。
對遞送報告請求消息的具體擴展方法為將遞送報告請求消息中記錄遞 送報告的五個必選字段信息的部分進行擴展，在該擴展部分中，連續(xù)記錄n (n>l )個遞送報告的上述五個必選字段信息。所記錄的遞送報告的數(shù)目n 可根據(jù)實際應用情況預先進行設(shè)置。此外，為了進行區(qū)別和標識，可為上述 擴展部分設(shè)置一個新標簽，該新標簽的名稱可設(shè)為"MultiDR"，即在上述 擴展部分的首部和尾部分別i殳置"<MultiDR>"和"</MultiDR>"的標簽， 接收方根據(jù)上述的新標簽即可知該遞送報告請求消息為擴展后的包括多個 遞送報告的遞送報告請求消息。
在具體的實施方式中，首先在本地內(nèi)存中緩存上述所需發(fā)送的多個遞送 報告；然后根據(jù)預先設(shè)置的定時和/或定長的方式從本地內(nèi)存中獲取多個需 發(fā)送的多媒體消息的遞送報告；根據(jù)所獲取的多個遞送報告以及上述的擴展 方法，生成上述擴展后的包括多個遞送報告的遞送報告請求消息；接著輸出 上述擴展后的遞送報告請求消息。在上述的實施方式中，所述定時的方式為 根據(jù)預先設(shè)定的時間間隔(例如，5分鐘)，從上述緩存的多媒體消息的遞 送報告中獲取多個需發(fā)送的多媒體消息的遞送報告；所述定長的方式為當 上述緩存的多媒體消息的遞送報告的總長度達到預先設(shè)定的閾值(例如， 2M)時，從上述緩存的多媒體消息的遞送報告中獲取多個需發(fā)送的多媒體 消息的遞送報告。在實際應用時，可單獨使用上述的定時方式或定長方式獲 取多個需發(fā)送的多媒體消息的遞送報告，也可同時使用上述的定時方式和定 長方式獲取多個需發(fā)送的多媒體消息的遞送報告。
在對遞送報告請求消息進行擴展后，還需對與遞送報告請求消息相對應 的遞送報告響應消息進行擴展，即根據(jù)擴展后的遞送報告請求消息，在與之相應的遞送報告響應消息中記錄StatusCode字段信息的部分，順序記錄n 條StatusCode字段，所記錄的n條StatusCode字段與相應的擴展后的遞送才艮 告請求消息中的n條遞送報告——對應，且排列順序也相同。
以SOAP接口為例，上述擴展后的遞送報告請求消息的SOAP接口報文 如下所示
< xml version="1.0" encoding="UTF-8" >
<env:Envelope xmlns:env="http:〃schemas.xmlsoap.org/soap/envelope/"> <env:Header>
<mm7: TransactionID
xmlns:mm7="http:〃www.3gpp.org/ftp/Specs/archive/23—series/23.140/schema/REL-6-MM7-1-0" env:mustUnderstand=" 1">0110000000006020908131404302</mm7:T腦sactionID〉
</env:Header>
<env:Body>
<DeliveryReportReq
xmlns="http:〃www.3gpp.org/ftp/Specs/archive/23—series/23.140/schema/REL-6-MM7-l-0"〉 <MM7 Version>6.3. 0</MM7 Version> <TimeStamp>2002-09-08T05:14:04-04:00</TimeStamp> <MMSRelayServerID>913000</MMSRelayServerID〉 <Sondor>51512l 1</Sender> -<Recipient>
-<Numb Or>+8613810211231 </Numb cr>
-</Recipient>
-<MossageID>0908131糊913 00001101 </MossagoID>
-<MMStatus>Rotriovod</MMStatus>
-<StatusToxt> 1000</StatusText>
<MultiDR>
<Sender>8888001</Sender>
<MessageID>082715595591300001146</MessageID>
<Recipient><Number>+8613701050001</Number></Recipient>
<MMStatus>Retrieved</MMStatus>
<StatusText> 1000</StatusText>
<Sender>7777123</Sender>
<MessageID>082716035691300001190</MessageID><Recipient><Number>+8613 810240001 </Number></Recipient> <MMStatus>Retrieved</MMStatus> <StatusText> 1000</StatusText> <Sender>6666007</Sender>
<MessageID>0827165900913 0000123 5</MessageID> <Recipient><Number>+8613501051234</Number></Recipient> <MMStatus>Retrieved</MMStatus> <StatusText>l 000</StatusText> </MultiDR> </DeliveryReportReq> </env:Body> </env:Envelope>
在上述報文中，以橫線為刪除線進行標識的部分內(nèi)容，即為擴展前的遞 送報告請求消息中記錄遞送報告的五個必選字段信息的部分；而〈MultiDR〉 和々MultiDR〉之間所記錄的內(nèi)容，即為擴展后的遞送報告請求消息中的擴展部分。
與上述擴展后的遞送報告請求消息相對應的遞送報告響應消息的SOAP
接口報文如下所示
< xml version="1.0" encoding="UTF-8" >
<soap-env:Envelope xmlns:soap-env="http:〃schemas.xmlsoap.org/soap/envelope〃'> <soap-env:Pieader> <mm7:TransactionID
xmlns:mm7="http:〃www.3 gpp.org/ftp/Specs/archive/23_series/23.140/schema/REL-6-MM7-1-0"
soap-env:mustUnderstand="r>0110000000006020908131404302</mm7:TransactionID> </soap-env:Header> <soap-env:Body> <DeliveryReportRsp
xmlns="http:〃www.3gpp.org/ftp/Specs/archive/23—series/23.140/schema/REL-6-MM7-l-0"> <MM7Version>6.3.0</MM7Version> <Status>
<StatusCode>1000</StatusCode> <StatusCode> 1000</StatusCode><StatusCode> 1000</StatusCode> </Status> </DeliveryReportRsp> </soap-env:Body> </soap-env:Envelope>
現(xiàn)有的遞送"R告響應消息中只有一條StatusCode，而上述擴展后的遞送 報告響應消息中具有多條StatusCode,即針對上述擴展后的遞送報告請求消 息中的每一條遞送報告，在擴展后的遞送報告響應消息中都會有一條對應的 StatusCode。而且，擴展后的遞送報告響應消息中的多條StatusCode的排列 順序與擴展后的遞送報告請求消息中的多條遞送報告的排列順序是一致的。
此外，如果擴展后的遞送報告響應消息中僅有一條StatusCode,且返回 的錯誤信息為"消息格式錯誤"，則說明該應用設(shè)備不支持批量傳輸遞送報 告，此時，多媒體消息服務(wù)中心(MMSC)仍將以原來的單條發(fā)送方式發(fā)送 遞送報告。
第二較佳實施例
在本實施例中，彩信服務(wù)器可將要發(fā)送的多條遞送報告的字段信息按照 預先設(shè)定的排列順序記錄到同一個本地文件中，該文件可稱之為記錄文件。 在所述的記錄文件中，每一條記錄均對應一個遞送報告并包含該遞送報告的 所有字段信息。所述的記錄文件可以是文本文件，也可以是二進制文件。當 所述的記錄文件為文本文件時，所述記錄文件中的每條記錄的才各式可以為如 下所示的格式
Message-Type | MM7 Version | MMS Relay/Server ID | Date and time | Sender address | Message ID | Recipient address | MM Status | Status text
由上述記錄的格式可知，記錄文件中的每條記錄中都包括了某條遞送報
告中所有的字段信息。例如， 一個具有三條記錄的記錄文件的內(nèi)容可為
DRReq|6.3. 234|Retrieved|1000 DRReq|6,3.(001|Retrieved|1000
DRReq|6.3.0|910000|20070527075956|6666007|082716590091300001235|+8613810240 001|Retrieved|1000
上述的文本文件中的記錄格式只是一個較佳的實施方式，在實際應用情 況中，可根據(jù)需求設(shè)置文本文件中的記錄格式。
此外，還可將上述所需記錄的多個遞送報告的所有字段信息，編譯成二 進制格式，并按照預先設(shè)置的排列順序記錄在一個二進制文件中。
在具體的實施方式中，首先在彩信服務(wù)器的本地內(nèi)存中緩存上述所需發(fā) 送的多個遞送報告；然后根據(jù)預先設(shè)置的定時和/或定長的方式從本地內(nèi)存 中獲取多個需發(fā)送的多媒體消息的遞送報告；根據(jù)所獲取的多個遞送報告以 及上述的方法，建立上述包括多個遞送報告的記錄文件；接著輸出上述記錄 文件。在上述的實施方式中，所述定時的方式為根據(jù)預先設(shè)定的時間間隔 (例如，5分鐘)，從上述緩存的多媒體消息的遞送報告中獲取多個需發(fā)送 的多媒體消息的遞送報告；所述定長的方式為當上述記錄文件的長度達到 預先設(shè)定的閾值(例如，2M)時，從上述緩存的多媒體消息的遞送報告中 獲取多個需發(fā)送的多媒體消息的遞送報告。在實際應用時，可單獨使用上述 的定時方式或定長方式獲取多個需發(fā)送的多媒體消息的遞送報告，也可同時 使用上述的定時方式和定長方式獲取多個需發(fā)送的多媒體消息的遞送報告。 所述的輸出記錄文件可以是將上述記錄文件輸出到應用設(shè)備所提供的存放 目錄中。
除了上述的主動輸出的模式外，還可使用多種傳送方式將上述記錄文件 傳送到應用設(shè)備上，例如
方式1、發(fā)起方應用設(shè)備按照預先設(shè)定的時間間隔(例如，5分鐘)， 定期到彩信服務(wù)器的指定位置獲取上述記錄文件，并在成功獲取上述記錄文 件后刪除彩信服務(wù)器中的所述記錄文件。上述獲取文件的方法可以為使用文 件傳輸協(xié)議(FTP)等多種手段。
方式2、當輸出上述記錄文件后，可發(fā)送一個修改后的遞送報告請求消息給應用設(shè)備，在該修改后的遞送報告請求消息中，Sender address、 Recipient address、 MessageID、 MMStatus等四個字段的內(nèi)容為空，而字段StatusText 中的內(nèi)容為上述記錄文件在彩信服務(wù)器中的存放路徑；所述應用設(shè)備在接收 到上述經(jīng)過修改的遞送報告請求消息后，如果直接返回一個遞送報告響應消 息，且返回的是一個內(nèi)容為"消息格式錯誤"的錯誤碼，則說明所述應用設(shè) 備不支持上述傳輸多條遞送報告的方法，則仍需以單條的方式發(fā)送遞送報 告；如果所述應用設(shè)備支持上述傳輸多條遞送報告的方法，則所述應用設(shè)備 將根據(jù)上述修改后的遞送報告請求消息中的存放路徑到彩信服務(wù)器中提取 相應的記錄文件；成功提取后，所述應用設(shè)備再向彩信服務(wù)器返回遞送報告 響應消息。所述的提取方式可以有多種，例如文件傳輸協(xié)議(FTP)、超 文本傳輸協(xié)議(HTTP)、上傳/下傳(POST/GET)或其他可實現(xiàn)文件內(nèi)容 傳送的方式。
此外，由于是連續(xù)地產(chǎn)生不同的記錄文件，因此需要通過文件名稱來區(qū) 分不同的記錄文件，因此，可根據(jù)如下所示的命名方法來命名不同的記錄文 件MMSDeviceIDyyyymmddHHMISS.XXXX。例如，某個記錄文件的名稱 可為91000020070606174500.0019。
圖3為本發(fā)明實施例中發(fā)送多媒體消息的遞送報告的裝置的示意圖。如 圖3所示，本發(fā)明實施例中發(fā)送多媒體消息的遞送報告的裝置包括獲取模 塊、生成模塊和輸出模塊；
所述獲取模塊，用于獲取至少兩個需發(fā)送的多媒體消息的遞送報告；并 將所獲取的多媒體消息的遞送報告發(fā)送給生成模塊；
所述生成模塊，用于根據(jù)獲取模塊所獲取的多媒體消息的遞送報告，生 成包括至少兩個需發(fā)送的多媒體消息的遞送報告的集合體；并將所生成的集 合體發(fā)送給輸出模塊；
所述輸出模塊，用于輸出所述的集合體。
其中，所述獲取模塊還包括閾值設(shè)定模塊。
所述閾值設(shè)定模塊，用于根據(jù)設(shè)定的時間間隔向獲取模塊發(fā)送獲取命令；或者，用于當所述緩存的所需發(fā)送的多媒體消息的遞送報告的總長度達到設(shè)定
的閾值時，向獲取模塊發(fā)送獲取命令；或者，用于當間隔的時間達到設(shè)定的時
間間隔時，或當所述緩存的所需發(fā)送的多媒體消息的遞送報告的總長度達到設(shè)
定的閾值時，向獲取模塊發(fā)送獲取命令；
所述獲取模塊，還用于根據(jù)接收到的獲取命令，獲取至少兩個需發(fā)送的多
媒體消息的遞送報告。
此外，所述發(fā)送多媒體消息的遞送報告的裝置還可以包括一個存儲模塊。
所述存儲模塊，用于緩存多個所需發(fā)送的多々某體消息的遞送報告；
而所述獲取模塊，還用于從存儲模塊中獲取至少兩個需發(fā)送的多媒體消
息的遞送報告。
綜上可知，通過上述本發(fā)明實施例中所提供的方法和裝置，當需要發(fā)送 多個多媒體消息的遞送報告時，可首先緩存所需發(fā)送的遞送報告，并將所緩 存的多個遞送報告一次輸出，從而可以實現(xiàn)一次同時發(fā)送多個遞送才艮告，因 而提高了發(fā)送遞送報告的成功率，提高了對遞送報告的處理效率，同時還減 少了對網(wǎng)絡(luò)資源的浪費，提高了系統(tǒng)性能。
以上所述，僅為本發(fā)明的較佳實施例而已，并非用于限定本發(fā)明的保護 范圍。凡在本發(fā)明的精神和原則之內(nèi)，所作的任何修改、等同替換、改進等， 均應包含在本發(fā)明的保護范圍之內(nèi)。
1權(quán)利要求
1、一種發(fā)送多媒體消息的遞送報告的方法，其特征在于，該方法包括緩存所需發(fā)送的多媒體消息的遞送報告；使用預先設(shè)置的方式獲取至少兩個需發(fā)送的多媒體消息的遞送報告；生成包括至少兩個需發(fā)送的多媒體消息的遞送報告的集合體；輸出所述集合體。
2、 根據(jù)權(quán)利要求1所述的方法，其特征在于，所述生成包括至少兩個需發(fā) 送的多媒體消息的遞送報告的集合體包括生成包括至少兩個需發(fā)送的多媒體消息的遞送報告的遞送報告請求消息； 或者，生成包括至少兩個需發(fā)送的多媒體消息的遞送報告的記錄文件。
3、 才艮據(jù)權(quán)利要求2所述的方法，其特征在于，所述生成包括至少兩個需發(fā) 送的多媒體消息的遞送報告的遞送報告請求消息包括在遞送^R告請求消息中記錄遞送才艮告的必選字,殳信息的部分，連續(xù)記錄至 少兩個遞送報告的必選字段信息；并在所述記錄必選字段信息的部分的首部和 尾部分別設(shè)置一個用于標識該部分的新標簽。
4、 根據(jù)權(quán)利要求3所述的方法，其特征在于，所述輸出所述集合體之后還 包括在與所述包括至少兩個遞送報告的遞送報告請求消息相對應的遞送報告響 應消息中記錄StatusCode字段信息的部分，按所述至少兩個遞送報告的順序記
5、 根據(jù)權(quán)利要求2所述的方法，其特征在于，所述生成包括至少兩個需發(fā) 送的多媒體消息的遞送報告的記錄文件包括將所述至少兩個遞送報告的字段信息按照設(shè)定的排列順序記錄到記錄文件中。
6、 根據(jù)權(quán)利要求2或5所述的方法，其特征在于所述記錄文件為文本文 件或二進制文件。
7、 根據(jù)權(quán)利要求1所述的方法，其特征在于，所述使用預先設(shè)置的方式獲取至少兩個需發(fā)送的多媒體消息的遞送報告包括根據(jù)設(shè)定的時間間隔獲取至少兩個所述緩存的多媒體消息的遞送報告； 或者，當所述緩存的所需發(fā)送的多媒體消息的遞送報告的總長度達到設(shè)定的閾值時，獲取至少兩個所述緩存的多媒體消息的遞送報告；或者，當間隔的時間達到設(shè)定的時間間隔時，或當所述緩存的所需發(fā)送的多媒體消息的遞送報告的總長度達到設(shè)定的閾值時，獲取至少兩個所述緩存的多媒體消息的遞送報告。
8、 根據(jù)權(quán)利要求2所述的方法，其特征在于，輸出所述集合體包括 將所述記錄文件輸出到指定位置，所述記錄文件的接收方根據(jù)設(shè)定的時間間隔到所述指定位置獲取所述記錄文件。
9、 根據(jù)權(quán)利要求2所述的方法，其特征在于，輸出所述集合體包括 將所述記錄文件輸出到指定位置，發(fā)送一個通知信息給所述記錄文件的接收方，所述記錄文件的接收方根據(jù)所述通知信息到所述指定位置獲取所述記錄 文件。
10、 一種發(fā)送多媒體消息的遞送報告的裝置，其特征在于，該裝置包括 獲取模塊、生成模塊和輸出模塊；所述獲^^莫塊，用于獲取至少兩個需發(fā)送的多媒體消息的遞送報告； 所述生成模塊，用于根據(jù)獲取模塊所獲取的多媒體消息的遞送報告，生成 包括至少兩個需發(fā)送的多i某體消息的遞送報告的集合體； 所述輸出模塊，用于輸出所述的集合體。
11、 根據(jù)權(quán)利要求IO所述的裝置，其特征在于，該裝置還包括閾值設(shè)定 模塊；所述閾值設(shè)定模塊，用于根據(jù)設(shè)定的時間間隔向獲取模塊發(fā)送獲取命令； 或者，用于當所述緩存的所需發(fā)送的多媒體消息的遞送報告的總長度達到設(shè)定 的閾值時，向獲取模塊發(fā)送獲取命令；或者，用于當間隔的時間達到設(shè)定的時 間間隔時，或當所述緩存的所需發(fā)送的多i某體消息的遞送4艮告的總長度達到設(shè)定的閾值時，向獲取模塊發(fā)送獲取命令；所述獲取模塊，還用于根據(jù)接收到的獲取命令，獲取至少兩個需發(fā)送的多 媒體消息的遞送報告。
12、根據(jù)權(quán)利要求10或11所述的裝置，其特征在于，該裝置還包括存 儲模塊；所述存儲模塊，用于緩存所需發(fā)送的多媒體消息的遞送報告； 所述獲^^莫塊，還用于從存儲模塊中獲取至少兩個需發(fā)送的多媒體消息的 遞送報告。
全文摘要
本發(fā)明的實施例中公開了一種發(fā)送多媒體消息的遞送報告的方法，該方法包括緩存所需發(fā)送的多媒體消息的遞送報告；使用預先設(shè)置的方式獲取至少兩個需發(fā)送的多媒體消息的遞送報告；生成包括至少兩個需發(fā)送的多媒體消息的遞送報告的集合體；輸出所述集合體。本發(fā)明的實施例中還公開了一種發(fā)送多媒體消息的遞送報告的裝置，該裝置包括獲取模塊、生成模塊和輸出模塊。通過上述的方法和裝置，使得MMSC可以一次發(fā)送多個遞送報告，從而提高了發(fā)送遞送報告的成功率，提高了對遞送報告的處理效率，同時還減少了對網(wǎng)絡(luò)資源的浪費，提高了系統(tǒng)性能。
文檔編號H04W4/12GK101448207SQ20071016739
公開日2009年6月3日 申請日期2007年11月26日 優(yōu)先權(quán)日2007年11月26日
發(fā)明者李小強 申請人:華為技術(shù)有限公司