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

    隨著計(jì)算機(jī)和無(wú)線通訊領(lǐng)域相關(guān)技術(shù)的飛速發(fā)展,，各種多媒體應(yīng)用逐漸地由有線領(lǐng)域跨向無(wú)線領(lǐng)域。通過(guò)無(wú)線技術(shù)實(shí)現(xiàn)多媒體數(shù)據(jù)的傳輸已成為焦點(diǎn),。彩信作為一種多媒體數(shù)據(jù)的無(wú)線傳輸方式,，也越來(lái)越廣泛地得到應(yīng)用。如何在嵌入式終端設(shè)備實(shí)現(xiàn)彩信的高效、方便的發(fā)送是一個(gè)非常有實(shí)用意義的研究,。
    彩信的發(fā)送主要有WAP和TCP/IP兩種方式,。但市場(chǎng)上現(xiàn)有的大部分GSM模塊只支持TCP/IP協(xié)議棧，而沒(méi)有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ā)送過(guò)程
    彩信從發(fā)送方到MMSC(彩信服務(wù)中心)需要經(jīng)過(guò)WAP網(wǎng)關(guān)。MMS在發(fā)送方和WAP網(wǎng)關(guān)之間通過(guò)無(wú)線協(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ù)包通過(guò)無(wú)線傳輸協(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)稱(chēng)MMSC)。
    (2)MMSC收到信息后,，將信息內(nèi)容轉(zhuǎn)為MIME格式后存儲(chǔ),，并進(jìn)行數(shù)據(jù)分析，從而得到發(fā)送方信息,，同時(shí)通過(guò)WAP連接向發(fā)送方返回一個(gè)M-Send.conf的確認(rèn)包,。確認(rèn)包中含有狀態(tài)碼，如果收到的彩信格式正確,，該狀態(tài)碼為OK,。至此整個(gè)發(fā)送過(guò)程結(jié)束[1-2]。
2 WAP發(fā)送方式和TCP/IP發(fā)送方式的比較
    WAP發(fā)送方式和TCP/IP發(fā)送方式的最大區(qū)別在于從發(fā)送方到WAP網(wǎng)關(guān)傳輸過(guò)程中所用到的通信協(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)換過(guò)程如圖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é)議,，這大大減少了工作量和開(kāi)發(fā)難度,。并且發(fā)送方和WAP網(wǎng)關(guān)是采用TCP協(xié)議、面向連接的可靠性傳輸方式,，具有較高的成功率,。WAP網(wǎng)關(guān)接收到彩信數(shù)據(jù)包之后，無(wú)需進(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)方式是在開(kāi)發(fā)板上通過(guò)串口向GSM模塊發(fā)送AT指令,，設(shè)置GSM模塊，使其連接到WAP網(wǎng)關(guān)并獲得臨時(shí)分配的IP地址,。連接成功后,，開(kāi)發(fā)板向串口發(fā)送添加過(guò)HTTP Header的彩信數(shù)據(jù)包。之后,，GSM模塊調(diào)用自帶的TCP/IP協(xié)議棧向WAP網(wǎng)關(guān)發(fā)送彩信包,。以常用的BenQM23模塊發(fā)送移動(dòng)彩信為例進(jìn)行說(shuō)明。
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)使串口保持常開(kāi)狀態(tài),，以免數(shù)據(jù)丟失。
    (2)AT+CGDCONT=1,"IP","CMWAP"
    該指令用于設(shè)置GPRS接入網(wǎng)關(guān),。其PDP類(lèi)型為IP,，接入網(wǎng)關(guān)為CMWAP，表示中國(guó)移動(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地址。之后就可以向串口寫(xiě)入封裝好的彩信信息,，若彩信數(shù)據(jù)包成功寫(xiě)入GSM模塊,，BENQ23將返回OK提示信息。BENQ23G模塊AT指令的詳細(xì)說(shuō)明見(jiàn)參考文獻(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各種屬性,，包括類(lèi)型、版本號(hào),、接收方,、發(fā)送方、主題,、發(fā)送時(shí)間等,。這些域分為可選項(xiàng)和必選項(xiàng)，根據(jù)MMS PDU的類(lèi)型不同而不同,。此處只實(shí)現(xiàn)彩信的發(fā)送,，即M-Send.req類(lèi)型PDU。圖4為一簡(jiǎn)單的M-Send.req類(lèi)型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ì)來(lái)講,，related組裝方式會(huì)更復(fù)雜點(diǎn)，就以related方式為例,。對(duì)于一個(gè)有圖像和文本related類(lèi)型的MMS,，典型的消息格式如圖5所示。

    Heardlen與Datalen分別指明該部分?jǐn)?shù)據(jù)的頭部長(zhǎng)度和數(shù)據(jù)部分長(zhǎng)度,。Content-Type表示該段多媒體數(shù)據(jù)對(duì)應(yīng)的消息體的內(nèi)容類(lèi)型,。Content-ID為該部分內(nèi)容的標(biāo)識(shí)，并且必須是唯一的,。Content-Location類(lèi)似于HTML中的URL,，一個(gè)消息部分可以通過(guò)相對(duì)URL指向另外一個(gè)消息部分。例如:<img src=“image1.jpg”>，其中image1.jpg為另一個(gè)消息部分的Content-Location所對(duì)應(yīng)的值[5],。接下來(lái)的Data即為該段多媒體信息的數(shù)據(jù),。
3.3 彩信數(shù)據(jù)包添加HTTP Header
    構(gòu)建好的彩信數(shù)據(jù)包需要添加HTTP Header之后,才能通過(guò)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ā)送方支持的編碼類(lèi)型；User-Agent標(biāo)識(shí)發(fā)送方的一些信息,；Accept字段確定客戶端可以接收的媒體類(lèi)型,；Content-Length表示彩信數(shù)據(jù)包的長(zhǎng)度，以字節(jié)為單位,；Content-Type表示后面的彩信數(shù)據(jù)包屬于哪一種MIME類(lèi)型,。
    上述HTTP Header的構(gòu)建，除了Content-Length需要根據(jù)彩信包實(shí)際長(zhǎng)度修改外,，其余部分在發(fā)送一般格式的彩信時(shí),，均可以保持不變。
    將Http_Header和MMS_PDU構(gòu)建成一個(gè)數(shù)據(jù)包,，就可以通過(guò)串口向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,，說(shuō)明得到彩信中心的響應(yīng),。若返回其他狀態(tài)碼說(shuō)明發(fā)送失敗，具體原因可以查看RFC 2616 協(xié)議規(guī)定,。當(dāng)然,，僅僅只是HTTP的返回碼正確，還不能確定是否發(fā)送成功,，還需查看所返回的數(shù)據(jù)包中M-Send.conf頭部的Response-Status位,。若Response-Satus位為128，則說(shuō)明彩信發(fā)送成功,，若返回其他的狀態(tài)碼詳見(jiàn)參考文獻(xiàn)[6],。
    基于TCP/IP協(xié)議的彩信發(fā)送方法為利用現(xiàn)有的GPRS平臺(tái)下的彩信發(fā)送提供了一條簡(jiǎn)單可行的途徑，大大減少了開(kāi)發(fā)者的工作量和復(fù)雜度,，也省去了WAP網(wǎng)關(guān)對(duì)WAP協(xié)議和TCP/IP協(xié)議的轉(zhuǎn)換,，提高了發(fā)送速度。同時(shí),，只要GSM模塊帶有TCP/IP協(xié)議棧,，就可以直接利用該方法發(fā)送彩信，無(wú)須實(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].中國(guó)數(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.