摘  要： 研究了彩信的發(fā)送過程，提出了一種基于TCP/IP的彩信發(fā)送方法。進而比較了彩信的兩種發(fā)送方式和數(shù)據(jù)傳輸過程中協(xié)議的轉換。并且在BenQM23上實現(xiàn)了基于TCP/IP的彩信發(fā)送方法，該方法無需額外實現(xiàn)WAP協(xié)議的WSP/WTP層封裝，可以直接使用GSM模塊自帶的TCP/IP協(xié)議，大大降低了嵌入式終端上彩信發(fā)送的開發(fā)難度。
關鍵詞： 彩信發(fā)送；WAP網(wǎng)關；彩信服務中心；GSM模塊；TCP/IP

    隨著計算機和無線通訊領域相關技術的飛速發(fā)展，各種多媒體應用逐漸地由有線領域跨向無線領域。通過無線技術實現(xiàn)多媒體數(shù)據(jù)的傳輸已成為焦點。彩信作為一種多媒體數(shù)據(jù)的無線傳輸方式，也越來越廣泛地得到應用。如何在嵌入式終端設備實現(xiàn)彩信的高效、方便的發(fā)送是一個非常有實用意義的研究。
    彩信的發(fā)送主要有WAP和TCP/IP兩種方式。但市場上現(xiàn)有的大部分GSM模塊只支持TCP/IP協(xié)議棧，而沒有WAP方式的彩信協(xié)議棧。若要實現(xiàn)WAP發(fā)送需要自己實現(xiàn)彩信協(xié)議，需要相當大的工作量。因此基于TCP/IP的彩信發(fā)送方式將成為今后彩信發(fā)送的主要方式。本文提出一種基于GSM模塊所攜帶的TCP/IP協(xié)議棧實現(xiàn)彩信的發(fā)送。
1 MMS的發(fā)送過程
    彩信從發(fā)送方到MMSC(彩信服務中心)需要經(jīng)過WAP網(wǎng)關。MMS在發(fā)送方和WAP網(wǎng)關之間通過無線協(xié)議傳輸，在WAP網(wǎng)關和MMSC之間使用HTTP協(xié)議傳輸。其傳輸路徑如圖1所示。

    (1)彩信發(fā)送方將欲發(fā)送的信息編輯成一個M-Send.req數(shù)據(jù)包，并根據(jù)現(xiàn)存的MMSC信息建立一個WAP連接，然后將 M-Send.req數(shù)據(jù)包通過無線傳輸協(xié)議(WAP或TCP/IP協(xié)議)編碼后傳送到WAP網(wǎng)關。WAP網(wǎng)關以HTTP方式將收到的內容傳給彩信中繼器MMS Proxy-Relay，彩信中繼器再傳至彩信服務器(彩信中繼器和彩信服務器統(tǒng)稱MMSC)。
    (2)MMSC收到信息后，將信息內容轉為MIME格式后存儲，并進行數(shù)據(jù)分析，從而得到發(fā)送方信息，同時通過WAP連接向發(fā)送方返回一個M-Send.conf的確認包。確認包中含有狀態(tài)碼，如果收到的彩信格式正確，該狀態(tài)碼為OK。至此整個發(fā)送過程結束[1-2]。
2 WAP發(fā)送方式和TCP/IP發(fā)送方式的比較
    WAP發(fā)送方式和TCP/IP發(fā)送方式的最大區(qū)別在于從發(fā)送方到WAP網(wǎng)關傳輸過程中所用到的通信協(xié)議不同，而從WAP網(wǎng)關到MMSC的傳輸方式都基于TCP/IP協(xié)議進行Internet的HTTP請求。
    WAP發(fā)送方式在發(fā)送方和WAP網(wǎng)關之間使用WAP1.x協(xié)議。該協(xié)議在發(fā)送彩信時，需要對彩信包進行WDP、WTP和WSP層的封裝。因此，若在普通的GSM模塊上進行彩信發(fā)送，需要自己編程實現(xiàn)這三層的封裝。WAP網(wǎng)關在收到彩信數(shù)據(jù)包，要進行WAP協(xié)議到HTTP協(xié)議的轉化之后才能傳輸給彩信服務中心[3]。其協(xié)議轉換過程如圖2所示。

    TCP/IP的發(fā)送方式如圖3所示。這種方法基于WAP2.0協(xié)議棧。WAP2.0采用最新的Internet標準和協(xié)議，支持TCP/IP傳送協(xié)議移動簡本，并且能與目前Internet上運行的通用TCP互操作。因此，彩信發(fā)送可以直接使用GSM模塊上自帶的TCP/IP協(xié)議棧，而不必額外實現(xiàn)WAP協(xié)議，這大大減少了工作量和開發(fā)難度。并且發(fā)送方和WAP網(wǎng)關是采用TCP協(xié)議、面向連接的可靠性傳輸方式，具有較高的成功率。WAP網(wǎng)關接收到彩信數(shù)據(jù)包之后，無需進行WAP協(xié)議到HTTP協(xié)議上的轉換，提高了發(fā)送效率。

3 基于TCP/IP協(xié)議彩信發(fā)送方法的實現(xiàn)
    基于上述原理，本文提出了一種方法直接使用GSM模塊上攜帶的TCP/IP協(xié)議實現(xiàn)彩信發(fā)送。具體實現(xiàn)方式是在開發(fā)板上通過串口向GSM模塊發(fā)送AT指令，設置GSM模塊，使其連接到WAP網(wǎng)關并獲得臨時分配的IP地址。連接成功后，開發(fā)板向串口發(fā)送添加過HTTP Header的彩信數(shù)據(jù)包。之后，GSM模塊調用自帶的TCP/IP協(xié)議棧向WAP網(wǎng)關發(fā)送彩信包。以常用的BenQM23模塊發(fā)送移動彩信為例進行說明。
3.1 GSM模塊連接GPRS網(wǎng)絡
    BenQM23模塊與WAP網(wǎng)關連接需要如下AT指令：
    (1)AT$NOSLEEP=1
    防止串口進入休眠狀態(tài)，利用TCP/IP數(shù)據(jù)連接前應使串口保持常開狀態(tài)，以免數(shù)據(jù)丟失。
    (2)AT+CGDCONT=1,"IP","CMWAP"
    該指令用于設置GPRS接入網(wǎng)關。其PDP類型為IP，接入網(wǎng)關為CMWAP，表示中國移動網(wǎng)域接入點。如果是聯(lián)通，接入點設為UNIWAP。
    (3)AT%CGPCO=1,″PAP,,″,1
    設置PAP驗證，默認的用戶名和密碼為空。
    (4)AT$DESTINFO=″10.0.0.172″,1,80,0
    第1個參數(shù)為所連接網(wǎng)關的IP地址；第2個參數(shù)表示使用TCP協(xié)議；80為連接端口號。
    (5)ATD*97#
    ATD指令撥號連接，其連接的目的主機和連接方式為第4條指令所設置。
    OK
    CONNECT
    OK
    若串口返回上面的提示信息，表明連接成功，GSM模塊獲得臨時IP地址。之后就可以向串口寫入封裝好的彩信信息，若彩信數(shù)據(jù)包成功寫入GSM模塊，BENQ23將返回OK提示信息。BENQ23G模塊AT指令的詳細說明見參考文獻[4]。
3.2 構建彩信數(shù)據(jù)包
    彩信數(shù)據(jù)包MMS PDU由MMS Header和MMS  Body構成。
    MMS Header根據(jù)WAP-209協(xié)議和RFC2378的規(guī)定，由一系列的域名和域值組成，這些域定義了PDU各種屬性，包括類型、版本號、接收方、發(fā)送方、主題、發(fā)送時間等。這些域分為可選項和必選項，根據(jù)MMS PDU的類型不同而不同。此處只實現(xiàn)彩信的發(fā)送，即M-Send.req類型PDU。圖4為一簡單的M-Send.req類型PDU的Header解碼后的結構圖。

    MMS Body采用MIME協(xié)議封裝，包含多個多媒體信息，每個多媒體信息都包含Header和Entries兩部分。根據(jù)MMS Header中Content-Type的指示， MMS Body的組裝分為application/vnd.wap.multipart.mixed和application/vnd.wap.multipart.related兩種方式。相對來講，related組裝方式會更復雜點，就以related方式為例。對于一個有圖像和文本related類型的MMS，典型的消息格式如圖5所示。

    Heardlen與Datalen分別指明該部分數(shù)據(jù)的頭部長度和數(shù)據(jù)部分長度。Content-Type表示該段多媒體數(shù)據(jù)對應的消息體的內容類型。Content-ID為該部分內容的標識，并且必須是唯一的。Content-Location類似于HTML中的URL，一個消息部分可以通過相對URL指向另外一個消息部分。例如:<img src=“image1.jpg”>，其中image1.jpg為另一個消息部分的Content-Location所對應的值[5]。接下來的Data即為該段多媒體信息的數(shù)據(jù)。
3.3 彩信數(shù)據(jù)包添加HTTP Header
    構建好的彩信數(shù)據(jù)包需要添加HTTP Header之后,才能通過TCP/IP協(xié)議以POST方式發(fā)送到WAP網(wǎng)關。WAP網(wǎng)關接收到彩信包之后，根據(jù)HTTP Header的請求，將彩信包發(fā)送到MMSC。所添加HTTP Header的實現(xiàn)代碼如下：
    POST http://mmsc.monternet.com/HTTP/1.1
    Host:10.0.0.172.80
    X-Online-Host:mmsc.monternet.com
    Cache-Control:no-cache
    Connection:Keep-Alive
    Accept-Encoding:deflate,gzip
    User-Agent: SAMSUNG-SGH-E908/NetFront3.2/WAP2.0 Profile/MIDP-2.0 Configuration/CLDC-1.1
    Accept:application/vnd.wap.mms-message,image/vnd.wap.
wbmp,image/png,image/jpeg,image/gif,text/x-iMelody,text/
ximelody,application/x-midi,audio/midi,audio/mid,audio/x-mid,
image/bmp,audio/mp3,audio/x-midi,audio/amr,application/
vnd.smaf,application/vnd.wap.mms-message x-wap-profile:
http://wap.samsungmobile.com/uaprof/e908_10.xml
    Content-Length:35294
    Content-Type:application/vnd.wap.mms-message
    POST指明彩信所要提交的彩信中心地址，移動的為“mmsc.monternet.com”，如果發(fā)送聯(lián)通的彩信，地址是“mmsc.myuni.com.cn”；Host和X-Online-Host是所要連接的服務器IP地址和域名；Cache-Control用于控制HTTP緩存，no-cache表示請求或響應消息不能緩存；Keep-Alive使客戶端到服務器端的連接持續(xù)有效；Accept-Encoding字段聲明發(fā)送方支持的編碼類型；User-Agent標識發(fā)送方的一些信息；Accept字段確定客戶端可以接收的媒體類型；Content-Length表示彩信數(shù)據(jù)包的長度，以字節(jié)為單位；Content-Type表示后面的彩信數(shù)據(jù)包屬于哪一種MIME類型。
    上述HTTP Header的構建，除了Content-Length需要根據(jù)彩信包實際長度修改外，其余部分在發(fā)送一般格式的彩信時，均可以保持不變。
    將Http_Header和MMS_PDU構建成一個數(shù)據(jù)包，就可以通過串口向GSM模塊發(fā)送了。
3.4 構建數(shù)據(jù)包的數(shù)據(jù)結構
    程序中所封裝彩信包的數(shù)據(jù)結構定義如下：
    struct Packet
    {
    unsigned int length;    //data的數(shù)據(jù)長度
    unsigned char *data;    //該層數(shù)據(jù)包
    struct Packet *SubPaket;//下一層數(shù)據(jù)包
    }
    在Packet結構中，data存儲本層協(xié)議所包含的數(shù)據(jù)包頭部，length表示本層協(xié)議數(shù)據(jù)包頭部的長度，SubPacket指向下一層數(shù)據(jù)包結構。例如，在給彩信添加HTTP頭部時，data指向HTTP Header，SubPacket指向下一層的彩信數(shù)據(jù)包。這樣在數(shù)據(jù)傳輸時可以直接從鏈表頭發(fā)送到鏈表尾部。
3.5 發(fā)送結果
    發(fā)送完成之后，等待WAP網(wǎng)關的響應。如果返回結果為HTTP 200 OK，說明得到彩信中心的響應。若返回其他狀態(tài)碼說明發(fā)送失敗，具體原因可以查看RFC 2616 協(xié)議規(guī)定。當然，僅僅只是HTTP的返回碼正確，還不能確定是否發(fā)送成功，還需查看所返回的數(shù)據(jù)包中M-Send.conf頭部的Response-Status位。若Response-Satus位為128，則說明彩信發(fā)送成功，若返回其他的狀態(tài)碼詳見參考文獻[6]。
    基于TCP/IP協(xié)議的彩信發(fā)送方法為利用現(xiàn)有的GPRS平臺下的彩信發(fā)送提供了一條簡單可行的途徑，大大減少了開發(fā)者的工作量和復雜度，也省去了WAP網(wǎng)關對WAP協(xié)議和TCP/IP協(xié)議的轉換，提高了發(fā)送速度。同時，只要GSM模塊帶有TCP/IP協(xié)議棧，就可以直接利用該方法發(fā)送彩信，無須實現(xiàn)額外的彩信發(fā)送協(xié)議。
參考文獻
[1] ROYEWO.Technical_WAP2_0_20021106[EB/OL]．(2002-11-06)[2011-09-23].http://www.openmobilealliance.org/Technical/WAPindex.aspx#WAP20.
[2] 于捷，王祖林，劉有才.BENQ23G的彩信發(fā)送及編碼格式分析[J].單片機與嵌入式系統(tǒng)應用，2009(2)：44-47.
[3] 陳亮，趙曙光，付鵬.一種基于IP的彩信收發(fā)模塊設計[J].通信技術，2011，44(3)：45-47.
[4] WANG J CW.BenQ Inc M23 AT command user guide(Version：1.75)[R].2005.
[5] 張會勇.MMS的消息格式和壓縮編碼分析[J].中國數(shù)據(jù)通信，2004，6(6)：90-92.
[6] Wireless Application  Protocol  Forum Ltd.Wireless application protocol MMS  encapsulation protocol(Version 05-jan-2002)[EB/OL].[2011-9-11].http：//www.openmobilealliance.org/tech/affiliates/LicenseAgreement.asp?DocName=/wap/wap-209-mmsencapsulation-20020105-a.pdf.