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

黃穎 王坤 2007/06/25

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

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

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

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

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

　　為了解決接口效率低的問題，目前HTTP+SOAP方式的承載協(xié)議得到了廣泛的青睞，它的信令過程比較簡單，完成一個消息流程就只有一個數(shù)據(jù)請求和響應(yīng)，沒有SMTP協(xié)議中間多次的信令來回。

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

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

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

　　3.1協(xié)議流程

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

　　（1）MM4_forward.REQ路由前轉(zhuǎn)請求；

　　（2）MM4_forward.RES路由前轉(zhuǎn)響應(yīng)；

　　（3）MM4_delivery_reportREQ路由前轉(zhuǎn)遞送報告請求；

　　（4）MM4_delivery_reportRES路由前轉(zhuǎn)遞送報告響應(yīng)；

　　（5）MM4_read_reply.REQ路由前轉(zhuǎn)閱讀報告請求；

　　（6）MM4_read_reply.RES路由前轉(zhuǎn)閱讀報告響應(yīng)。

　　消息流程如圖3所示。

圖3 消息流程示意圖

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

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

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

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

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

　　（1）MessageID如何規(guī)定

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

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

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

　　MessageID的編碼總共是21位。

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

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

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

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

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

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

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

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

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

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

　　移動用戶E.164號碼格式為：“861XXH0H1H2H3ABCD”。

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

　　4、結(jié)束語

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

泰爾網(wǎng)