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

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

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

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

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

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

    Heardlen與Datalen分別指明該部分數據的頭部長度和數據部分長度。Content-Type表示該段多媒體數據對應的消息體的內容類型。Content-ID為該部分內容的標識，并且必須是唯一的。Content-Location類似于HTML中的URL，一個消息部分可以通過相對URL指向另外一個消息部分。例如:<img src=“image1.jpg”>，其中image1.jpg為另一個消息部分的Content-Location所對應的值[5]。接下來的Data即為該段多媒體信息的數據。
3.3 彩信數據包添加HTTP Header
    構建好的彩信數據包需要添加HTTP Header之后,才能通過TCP/IP協議以POST方式發送到WAP網關。WAP網關接收到彩信包之后，根據HTTP Header的請求，將彩信包發送到MMSC。所添加HTTP Header的實現代碼如下：
    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”，如果發送聯通的彩信，地址是“mmsc.myuni.com.cn”；Host和X-Online-Host是所要連接的服務器IP地址和域名；Cache-Control用于控制HTTP緩存，no-cache表示請求或響應消息不能緩存；Keep-Alive使客戶端到服務器端的連接持續有效；Accept-Encoding字段聲明發送方支持的編碼類型；User-Agent標識發送方的一些信息；Accept字段確定客戶端可以接收的媒體類型；Content-Length表示彩信數據包的長度，以字節為單位；Content-Type表示后面的彩信數據包屬于哪一種MIME類型。
    上述HTTP Header的構建，除了Content-Length需要根據彩信包實際長度修改外，其余部分在發送一般格式的彩信時，均可以保持不變。
    將Http_Header和MMS_PDU構建成一個數據包，就可以通過串口向GSM模塊發送了。
3.4 構建數據包的數據結構
    程序中所封裝彩信包的數據結構定義如下：
    struct Packet
    {
    unsigned int length;    //data的數據長度
    unsigned char *data;    //該層數據包
    struct Packet *SubPaket;//下一層數據包
    }
    在Packet結構中，data存儲本層協議所包含的數據包頭部，length表示本層協議數據包頭部的長度，SubPacket指向下一層數據包結構。例如，在給彩信添加HTTP頭部時，data指向HTTP Header，SubPacket指向下一層的彩信數據包。這樣在數據傳輸時可以直接從鏈表頭發送到鏈表尾部。
3.5 發送結果
    發送完成之后，等待WAP網關的響應。如果返回結果為HTTP 200 OK，說明得到彩信中心的響應。若返回其他狀態碼說明發送失敗，具體原因可以查看RFC 2616 協議規定。當然，僅僅只是HTTP的返回碼正確，還不能確定是否發送成功，還需查看所返回的數據包中M-Send.conf頭部的Response-Status位。若Response-Satus位為128，則說明彩信發送成功，若返回其他的狀態碼詳見參考文獻[6]。
    基于TCP/IP協議的彩信發送方法為利用現有的GPRS平臺下的彩信發送提供了一條簡單可行的途徑，大大減少了開發者的工作量和復雜度，也省去了WAP網關對WAP協議和TCP/IP協議的轉換，提高了發送速度。同時，只要GSM模塊帶有TCP/IP協議棧，就可以直接利用該方法發送彩信，無須實現額外的彩信發送協議。
參考文獻
[1] ROYEWO.Technical_WAP2_0_20021106[EB/OL]．(2002-11-06)[2011-09-23].http://www.openmobilealliance.org/Technical/WAPindex.aspx#WAP20.
[2] 于捷，王祖林，劉有才.BENQ23G的彩信發送及編碼格式分析[J].單片機與嵌入式系統應用，2009(2)：44-47.
[3] 陳亮，趙曙光，付鵬.一種基于IP的彩信收發模塊設計[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].中國數據通信，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.