點(diǎn)對點(diǎn)多媒體消息業(yè)務(wù)網(wǎng)間互通協(xié)議分析

黃穎 王坤 2007/06/25

圖1 點(diǎn)對點(diǎn)多媒體消息業(yè)務(wù)網(wǎng)間互聯(lián)網(wǎng)絡(luò )結構示意圖

圖2 點(diǎn)對點(diǎn)多媒體消息業(yè)務(wù)網(wǎng)間互聯(lián)網(wǎng)絡(luò )結構示意圖

　　2、承載協(xié)議分析

　　不同運營(yíng)商的多媒體消息業(yè)務(wù)的互通首先要解決互通協(xié)議問(wèn)題，即多媒體消息互聯(lián)網(wǎng)關(guān)之間采用標準的統一的互通協(xié)議。目前，有SMTP和HTTP+SOAP兩個(gè)協(xié)議可作為互通網(wǎng)關(guān)之間接口承載協(xié)議。

　　相對于HTTP+SOAP的方式，SMTP協(xié)議是使用的比較成熟的協(xié)議。SMTP（簡(jiǎn)單郵件傳輸協(xié)議）是3GPP多媒體消息規范中業(yè)務(wù)互通接口MM4使用的承載協(xié)議，目前在網(wǎng)內多媒體消息業(yè)務(wù)系統的部署中都使用了該接口承載協(xié)議。但作為承載協(xié)議，SMTP協(xié)議效率比較低，它完成一個(gè)消息流程需要多個(gè)信令過(guò)程：包含HELLO，NOOP，RSET，QUIT。MAILFROM，RCPTTO，DATA等信令。

　　為了解決接口效率低的問(wèn)題，目前HTTP+SOAP方式的承載協(xié)議得到了廣泛的青睞，它的信令過(guò)程比較簡(jiǎn)單，完成一個(gè)消息流程就只有一個(gè)數據請求和響應，沒(méi)有SMTP協(xié)議中間多次的信令來(lái)回。

　　但考慮到協(xié)議使用的成熟度、廣泛性及網(wǎng)間業(yè)務(wù)量，在點(diǎn)對點(diǎn)多媒體消息業(yè)務(wù)互通網(wǎng)關(guān)間的承載協(xié)議建議采用3GPP規定的MM4接口使用的SMTP協(xié)議。HTTP+SOAP協(xié)議的方式可以在網(wǎng)內試用，在協(xié)議成熟后，且網(wǎng)間業(yè)務(wù)量達到一定程度后可以考慮采用HTTP+SOAP的方式替代SMTP的方式。在現階段互通采用SMTP作為承載協(xié)議的情況下，為了提高承載協(xié)議的效率，建議使用長(cháng)連接的方式建立承載，即指在一次SMTP連接中，SMTP命令DATA可以發(fā)送多次。SMTP協(xié)議本身是支持這種行為的：在發(fā)送完一次消息后，不關(guān)閉該連接，當一方要求正常關(guān)閉該連接時(shí)，發(fā)送QUIT消息；為了防止連接超時(shí)，客戶(hù)端可以定期使用SMTP命令NOOP刷新及檢測連接的有效性。

　　下面闡述的互聯(lián)網(wǎng)關(guān)間的消息與承載協(xié)議無(wú)關(guān)，無(wú)論采用哪種承載方式都應該提供以下必要的業(yè)務(wù)消息，保證網(wǎng)間業(yè)務(wù)的互通，對于不同的承載協(xié)議只是在建立連接及消息的字段映射方面存在差別。

　　3、業(yè)務(wù)協(xié)議分析

　　3.1協(xié)議流程

　　互聯(lián)網(wǎng)關(guān)間業(yè)務(wù)消息主要是依據3GPP的MM4接口定義的，互聯(lián)網(wǎng)關(guān)間發(fā)送的消息類(lèi)型包括：

　　（1）MM4_forward.REQ路由前轉請求；

　　（2）MM4_forward.RES路由前轉響應；

　　（3）MM4_delivery_reportREQ路由前轉遞送報告請求；

　　（4）MM4_delivery_reportRES路由前轉遞送報告響應；

　　（5）MM4_read_reply.REQ路由前轉閱讀報告請求；

　　（6）MM4_read_reply.RES路由前轉閱讀報告響應。

　　消息流程如圖3所示。

圖3 消息流程示意圖

　　多媒體消息的始發(fā)方互聯(lián)網(wǎng)關(guān)會(huì )使用一個(gè)包含多媒體消息業(yè)務(wù)控制信息和多媒體消息內容的MM4_forward.REQ消息，將網(wǎng)內多媒體消息中心轉發(fā)過(guò)來(lái)的多媒體消息路由轉發(fā)至接收方互聯(lián)網(wǎng)關(guān)。發(fā)送方互聯(lián)網(wǎng)關(guān)如果請求了響應MM4_forward.RES，接收方互聯(lián)網(wǎng)關(guān)將在收到MM4_forward.REQ消息后響應一個(gè)提供請求狀態(tài)的MM4_forward.RES消息給發(fā)送方互聯(lián)網(wǎng)關(guān)。

　　接收方互聯(lián)網(wǎng)關(guān)將MM4_forward.REQ轉換成網(wǎng)內的消息進(jìn)一步轉發(fā)給接收用戶(hù)歸屬的多媒體消息中心（MMSC），接收用戶(hù)歸屬的多媒體消息中心根據系統及接收用戶(hù)情況返回一個(gè)遞送報告給發(fā)送方，首先轉發(fā)至接收方互聯(lián)網(wǎng)關(guān)，接收方互聯(lián)網(wǎng)關(guān)在收到遞送報告后，轉換成網(wǎng)間的消息MM4_delivery_report.REQ轉發(fā)給多媒體消息發(fā)送方互聯(lián)網(wǎng)關(guān)，接收方互聯(lián)網(wǎng)關(guān)如果請求了響應MM4_delivery_report.RES，發(fā)送方互聯(lián)網(wǎng)關(guān)將在收到MM4_delivery_report.REQ消息后響應一個(gè)提供請求狀態(tài)的MM4_delivery_report.RES消息給接收方互聯(lián)網(wǎng)關(guān)。

　　如果發(fā)送用戶(hù)請求了閱讀報告，且接收用戶(hù)同意發(fā)送閱讀報告，那么接收用戶(hù)提取多媒體消息后會(huì )向接收用戶(hù)歸屬的多媒體消息中心發(fā)送閱讀報告請求：同意向發(fā)送用戶(hù)返回閱讀報告。接收用戶(hù)歸屬的多媒體消息中心向接收方互聯(lián)網(wǎng)關(guān)轉發(fā)多媒體消息閱讀報告，接收方互聯(lián)網(wǎng)關(guān)在收到閱讀報告后，轉換成網(wǎng)間的消息MM4_read_reply_report.REQ轉發(fā)給發(fā)送方互聯(lián)網(wǎng)關(guān)，接收方互聯(lián)網(wǎng)關(guān)如果請求了響應MM4_read_reply_report.RES消息，發(fā)送方互聯(lián)網(wǎng)關(guān)將在收到MM4_read_reply_report.REQ消息后響應一個(gè)提供請求狀態(tài)的MM4_read_reply_report.RES消息給接收方互聯(lián)網(wǎng)關(guān)。

　　3.2協(xié)議中關(guān)鍵問(wèn)題分析

　　多媒體消息業(yè)務(wù)的開(kāi)展各國有各國的具體運營(yíng)情況，因此根據國內現網(wǎng)運營(yíng)及網(wǎng)絡(luò )結構情況需要對現有的MM4的接口協(xié)議做相應地調整以適應現網(wǎng)業(yè)務(wù)的互通。

　　（1）MessageID如何規定

　　MessageID在協(xié)議中用來(lái)標識一個(gè)消息，把一個(gè)消息及其響應聯(lián)系在一起，該標識必須惟一。由于網(wǎng)間業(yè)務(wù)互通，各個(gè)運營(yíng)商在網(wǎng)內的消息標識在網(wǎng)內雖然是惟一的，但可能在網(wǎng)間出現重復（如果兩個(gè)運營(yíng)商的編碼方式類(lèi)似），因此在網(wǎng)間業(yè)務(wù)互通過(guò)程中要對MessageID的編碼方案進(jìn)行標準化，以確保MessageID的惟一性。

　　目前，網(wǎng)內消息MessageID是在多媒體消息中心產(chǎn)生，編碼方式為：

• 日期+源多媒體消息中心代碼+序列號；
• 日期：月日時(shí)分秒占10位；
• 多媒體消息中心代碼：業(yè)務(wù)代碼（1位）+區號（3位）+省內序號（2位）；
• 序列號：占5位，順序增加，步長(cháng)為1，循環(huán)使用。

　　MessageID的編碼總共是21位。

　　目前，很多廠(chǎng)家是多媒體消息中心與網(wǎng)關(guān)合設，MessageID的編碼方式還涉及到設備本身下層的程序處理，為了使網(wǎng)間業(yè)務(wù)互通對現網(wǎng)的設備影響最小，建議不改變MessageID的位長(cháng)21位，編碼方案采用類(lèi)似的原則，建議采用以下編碼方式：

• 日期+源互聯(lián)網(wǎng)關(guān)代碼+序列號；
• 日期：月日時(shí)分秒占10位；
• 源互聯(lián)網(wǎng)關(guān)代碼：運營(yíng)商代碼（1位）+區號（3位）+網(wǎng)關(guān)序號（2位）；
• 序列號：占5位，順序增加，步長(cháng)為1，循環(huán)使用。

　　（2）確定遞送報告各個(gè)狀態(tài)的含義

　　在網(wǎng)間業(yè)務(wù)互通中，遞送報告的狀態(tài)非常重要，因為不同運營(yíng)商間的結算要依靠遞送報告的狀態(tài)。在3GPP的協(xié)議規范中，沒(méi)有對遞送報告的狀態(tài)含義做詳細的規定：根據各個(gè)廠(chǎng)家開(kāi)發(fā)設備的情況，可擴展相應的規定，具體的狀態(tài)含義參見(jiàn)表1。

表1 遞送報告狀態(tài)含義

　　（3）是否區分固定和移動(dòng)MMS-address（多媒體消息業(yè)務(wù)地址）

　　在協(xié)議中有個(gè)字段要帶上多個(gè)媒體消息業(yè)務(wù)系統地址，該地址表示消息層多媒體消息業(yè)務(wù)的用戶(hù)地址，3GPP的規范中只考慮了移動(dòng)網(wǎng)的情況。目前在國內，固定網(wǎng)也在發(fā)展多媒體消息業(yè)務(wù)，因此需要考慮固定網(wǎng)的情況。

　　在3GPP的規范中規定的MMS-address格式為：MMS-address=（“+”E.164“/TYPE=PLMN”）。

　　PLMN含義是公眾陸地移動(dòng)電話(huà)網(wǎng)，在固定網(wǎng)中應當使用PSTN公共交換電話(huà)網(wǎng)絡(luò )，但考慮到現網(wǎng)設備都是按照3GPP的規范開(kāi)發(fā)的，因此這里建議還是采用PLMN，主要通過(guò)E.164號碼來(lái)區分固定網(wǎng)和移動(dòng)網(wǎng)。

　　在固定網(wǎng)中，電話(huà)號碼前面是沒(méi)有“+”的，因此針對固定網(wǎng)的情況，MMS-address的格式應當為：MMS-address=（E.164“/TYPE=PLMN”）。

　　移動(dòng)用戶(hù)E.164號碼格式為：“861XXH0H1H2H3ABCD”。

　　固定用戶(hù)E.164號碼格式暫建議定為：“1060（長(cháng)途區號）（固定本地電話(huà)網(wǎng)用戶(hù)號碼）”，在SP號碼調整或運營(yíng)商協(xié)商之后，固定用戶(hù)E.164號碼格式為“0（長(cháng)途區號）（固定本地電話(huà)網(wǎng)用戶(hù)號碼）”。

　　4、結束語(yǔ)

　　對點(diǎn)多媒體消息業(yè)務(wù)互通涉及多方面的問(wèn)題，本文僅從協(xié)議的角度對多媒體消息業(yè)務(wù)互通進(jìn)行了分析，包括承載協(xié)議的選擇和業(yè)務(wù)協(xié)議的改進(jìn)等方面。隨著(zhù)后續設備試驗和測試的開(kāi)展，多媒體網(wǎng)間互通協(xié)議可能會(huì )暴露出新的問(wèn)題，需要通過(guò)不斷地改進(jìn)來(lái)進(jìn)一步完善互通協(xié)議。隨著(zhù)運營(yíng)商間多媒體消息業(yè)務(wù)的逐步互聯(lián)互通，多媒體消息業(yè)務(wù)將越來(lái)越豐富，多媒體業(yè)務(wù)必將會(huì )像短消息業(yè)務(wù)一樣成為人們日常交流的新的媒體手段。

泰爾網(wǎng)