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

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

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

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

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

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

    Heardlen與Datalen分別指明該部分?jǐn)?shù)據(jù)的頭部長(zhǎng)度和數(shù)據(jù)部分長(zhǎng)度。Content-Type表示該段多媒體數(shù)據(jù)對(duì)應(yīng)的消息體的內(nèi)容類型。Content-ID為該部分內(nèi)容的標(biāo)識(shí)，并且必須是唯一的。Content-Location類似于HTML中的URL，一個(gè)消息部分可以通過相對(duì)URL指向另外一個(gè)消息部分。例如:<img src=“image1.jpg”>，其中image1.jpg為另一個(gè)消息部分的Content-Location所對(duì)應(yīng)的值[5]。接下來的Data即為該段多媒體信息的數(shù)據(jù)。
3.3 彩信數(shù)據(jù)包添加HTTP Header
    構(gòu)建好的彩信數(shù)據(jù)包需要添加HTTP Header之后,才能通過TCP/IP協(xié)議以POST方式發(fā)送到WAP網(wǎng)關(guān)。WAP網(wǎng)關(guān)接收到彩信包之后，根據(jù)HTTP Header的請(qǐng)求，將彩信包發(fā)送到MMSC。所添加HTTP Header的實(shí)現(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指明彩信所要提交的彩信中心地址，移動(dòng)的為“mmsc.monternet.com”，如果發(fā)送聯(lián)通的彩信，地址是“mmsc.myuni.com.cn”；Host和X-Online-Host是所要連接的服務(wù)器IP地址和域名；Cache-Control用于控制HTTP緩存，no-cache表示請(qǐng)求或響應(yīng)消息不能緩存；Keep-Alive使客戶端到服務(wù)器端的連接持續(xù)有效；Accept-Encoding字段聲明發(fā)送方支持的編碼類型；User-Agent標(biāo)識(shí)發(fā)送方的一些信息；Accept字段確定客戶端可以接收的媒體類型；Content-Length表示彩信數(shù)據(jù)包的長(zhǎng)度，以字節(jié)為單位；Content-Type表示后面的彩信數(shù)據(jù)包屬于哪一種MIME類型。
    上述HTTP Header的構(gòu)建，除了Content-Length需要根據(jù)彩信包實(shí)際長(zhǎng)度修改外，其余部分在發(fā)送一般格式的彩信時(shí)，均可以保持不變。
    將Http_Header和MMS_PDU構(gòu)建成一個(gè)數(shù)據(jù)包，就可以通過串口向GSM模塊發(fā)送了。
3.4 構(gòu)建數(shù)據(jù)包的數(shù)據(jù)結(jié)構(gòu)
    程序中所封裝彩信包的數(shù)據(jù)結(jié)構(gòu)定義如下：
    struct Packet
    {
    unsigned int length;    //data的數(shù)據(jù)長(zhǎng)度
    unsigned char *data;    //該層數(shù)據(jù)包
    struct Packet *SubPaket;//下一層數(shù)據(jù)包
    }
    在Packet結(jié)構(gòu)中，data存儲(chǔ)本層協(xié)議所包含的數(shù)據(jù)包頭部，length表示本層協(xié)議數(shù)據(jù)包頭部的長(zhǎng)度，SubPacket指向下一層數(shù)據(jù)包結(jié)構(gòu)。例如，在給彩信添加HTTP頭部時(shí)，data指向HTTP Header，SubPacket指向下一層的彩信數(shù)據(jù)包。這樣在數(shù)據(jù)傳輸時(shí)可以直接從鏈表頭發(fā)送到鏈表尾部。
3.5 發(fā)送結(jié)果
    發(fā)送完成之后，等待WAP網(wǎng)關(guān)的響應(yīng)。如果返回結(jié)果為HTTP 200 OK，說明得到彩信中心的響應(yīng)。若返回其他狀態(tài)碼說明發(fā)送失敗，具體原因可以查看RFC 2616 協(xié)議規(guī)定。當(dāng)然，僅僅只是HTTP的返回碼正確，還不能確定是否發(fā)送成功，還需查看所返回的數(shù)據(jù)包中M-Send.conf頭部的Response-Status位。若Response-Satus位為128，則說明彩信發(fā)送成功，若返回其他的狀態(tài)碼詳見參考文獻(xiàn)[6]。
    基于TCP/IP協(xié)議的彩信發(fā)送方法為利用現(xiàn)有的GPRS平臺(tái)下的彩信發(fā)送提供了一條簡(jiǎn)單可行的途徑，大大減少了開發(fā)者的工作量和復(fù)雜度，也省去了WAP網(wǎng)關(guān)對(duì)WAP協(xié)議和TCP/IP協(xié)議的轉(zhuǎn)換，提高了發(fā)送速度。同時(shí)，只要GSM模塊帶有TCP/IP協(xié)議棧，就可以直接利用該方法發(fā)送彩信，無須實(shí)現(xiàn)額外的彩信發(fā)送協(xié)議。
參考文獻(xiàn)
[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].單片機(jī)與嵌入式系統(tǒng)應(yīng)用，2009(2)：44-47.
[3] 陳亮，趙曙光，付鵬.一種基于IP的彩信收發(fā)模塊設(shè)計(jì)[J].通信技術(shù)，2011，44(3)：45-47.
[4] WANG J CW.BenQ Inc M23 AT command user guide(Version：1.75)[R].2005.
[5] 張會(huì)勇.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.