WAP 彩信業(yè)務(wù)多層數(shù)據(jù)重組和圖像重建方法

雒江濤，楊 葉，舒忠玲，袁 亮

(1.重慶郵電大學(xué)通信與信息工程學(xué)院，重慶 400065;2.重慶高校通信網(wǎng)測(cè)試技術(shù)工程研究中心，重慶 400065;3.重慶中天重郵通信技術(shù)有限公司，重慶 401121)

0 引言

隨著移動(dòng)通信網(wǎng)絡(luò)基礎(chǔ)設(shè)施和智能手機(jī)技術(shù)的不斷發(fā)展，基于無(wú)線應(yīng)用協(xié)議(wireless application protocol，WAP)的手機(jī)上網(wǎng)業(yè)務(wù)已逐漸成為現(xiàn)代人們工作和生活中的重要組成部分。同時(shí)，它也是未來(lái)物聯(lián)網(wǎng)發(fā)展的基礎(chǔ)技術(shù)之一和重要的應(yīng)用［1］。其中，移動(dòng)彩信業(yè)務(wù)即多媒體消息服務(wù)(multimedia messaging service，MMS)，是承載這一應(yīng)用有效的服務(wù)形式，也是目前應(yīng)用最廣泛的移動(dòng)數(shù)據(jù)業(yè)務(wù)類(lèi)型之一。它不但支持移動(dòng)用戶終端、監(jiān)測(cè)終端和服務(wù)器之間互相發(fā)送文本、語(yǔ)音、圖像或視頻等多種媒體的混合，而且支持服務(wù)提供商(service provider，SP)向移動(dòng)用戶推送多媒體新聞或娛樂(lè)內(nèi)容(比如手機(jī)報(bào))。然而，彩信業(yè)務(wù)給用戶帶來(lái)便利的同時(shí)，也給違法人員提供了可趁之機(jī)，常被用來(lái)傳遞非法信息，還被用于在3G網(wǎng)絡(luò)中傳遞手機(jī)病毒［2］。因此，對(duì)彩信業(yè)務(wù)的內(nèi)容進(jìn)行適當(dāng)?shù)谋O(jiān)控非常必要，也已經(jīng)引起了政府有關(guān)部門(mén)的高度重視。

目前移動(dòng)通信網(wǎng)絡(luò)的監(jiān)測(cè)主要基于信令監(jiān)測(cè)系統(tǒng)［3-4］，它將多個(gè)網(wǎng)絡(luò)接口的信令和業(yè)務(wù)數(shù)據(jù)復(fù)制下來(lái)進(jìn)行關(guān)聯(lián)分析，對(duì)網(wǎng)絡(luò)運(yùn)行狀況和業(yè)務(wù)質(zhì)量水平進(jìn)行評(píng)估，為管理維護(hù)人員提供參考依據(jù)。監(jiān)測(cè)系統(tǒng)已經(jīng)成為移動(dòng)通信網(wǎng)絡(luò)運(yùn)行的重要支撐系統(tǒng)和必不可少的工具。然而，目前的監(jiān)測(cè)系統(tǒng)主要面向信令面，缺乏業(yè)務(wù)面分析能力，這主要是由于業(yè)務(wù)面數(shù)據(jù)涉及多層協(xié)議數(shù)據(jù)分片重組，處理起來(lái)非常困難，一直缺乏有效的業(yè)務(wù)內(nèi)容還原方法。實(shí)踐中，往往需要另外新建專(zhuān)門(mén)的內(nèi)容監(jiān)控系統(tǒng)，采集更靠近業(yè)務(wù)中心的網(wǎng)絡(luò)接口，這勢(shì)必造成重復(fù)建設(shè)和巨大的浪費(fèi)。

為此，本文深入研究了GPRS/WCDMA分組域核心網(wǎng)無(wú)線應(yīng)用協(xié)議(wireless application protocol，WAP)彩信業(yè)務(wù)即MMS的協(xié)議棧和業(yè)務(wù)流程，設(shè)計(jì)出面向Gn接口的多層業(yè)務(wù)數(shù)據(jù)分片重組和數(shù)據(jù)圖像文件的重建方法。它能夠基于GPRS核心網(wǎng)Gn接口的用戶面數(shù)據(jù)還原得到原始圖像文件，從而基于現(xiàn)有的監(jiān)測(cè)系統(tǒng)即可實(shí)現(xiàn)數(shù)據(jù)業(yè)務(wù)的內(nèi)容監(jiān)測(cè)。

彩信業(yè)務(wù)有WAP 1.x和WAP 2.0兩種承載方式，本文針對(duì)協(xié)議層次更多、更復(fù)雜的WAP 1.x。

1 原理

1.1 WAP 1.x彩信

WAP 1.x彩信業(yè)務(wù)流程如圖1所示，彩信發(fā)送和接收過(guò)程各構(gòu)成一個(gè)無(wú)線會(huì)話協(xié)議(wireless session protocol，WSP)會(huì)話［5-8］。無(wú)線會(huì)話協(xié)議使用Connect/Connect Reply消息建立會(huì)話，用Disconnect消息釋放會(huì)話。會(huì)話的建立和釋放分別采用一個(gè)無(wú)線事務(wù)協(xié)議(wireless transaction protocol，WTP)2類(lèi)和0類(lèi)事務(wù)承載;會(huì)話存續(xù)期間使用一個(gè)或多個(gè)WTP的2類(lèi)事務(wù)完成彩信的發(fā)送、提取及其確認(rèn)過(guò)程［5-6］。無(wú)線事務(wù)協(xié)議支持分片重組，它采用分段調(diào)用(segmented invoke)消息支持將較大的Invoke消息分片發(fā)送;同時(shí)，也支持用分段結(jié)果(segmented result)消息將調(diào)用結(jié)果分片返回［5］。較大的彩信文件正是利用這種機(jī)制進(jìn)行傳遞的。WTP同時(shí)還利用按組(Group)確認(rèn)、否定確認(rèn)(Nack)、選擇性重傳等機(jī)制保證WTP分段按順序可靠傳送［5］。

圖1 WAP 1.x彩信業(yè)務(wù)流程Fig.1 Service process of MMS on WAP 1.x

在彩信發(fā)送過(guò)程中，彩信文件由MMS層MSend.req消息攜帶;接收過(guò)程中，由 M-Retrieve.conf消息攜帶。MMS消息封裝在WSP Post或WSP Reply操作的數(shù)據(jù)部分，其內(nèi)容類(lèi)型為“application/vnd.wap.mms-message”，編碼規(guī)則遵從文獻(xiàn)［8］。

多媒體對(duì)象位于MMS消息的多部分消息體(multipart body)中，采用類(lèi)似電子郵件的MIME Multipart/Related結(jié)構(gòu)［9］。每個(gè)多媒體對(duì)象作為一個(gè)獨(dú)立的部分，可能是 image/jpeg，text/plain，audio/wave 等不同類(lèi)型。彩信圖像文件對(duì)應(yīng)image/jpeg類(lèi)型。

1.2 多層分片重組原理

Gn接口是GPRS核心網(wǎng)信令和業(yè)務(wù)最集中的接口，也是監(jiān)測(cè)系統(tǒng)最重要的采集接口。它位于服務(wù)GPRS 支持節(jié)點(diǎn)(serving GPRS support node，SGSN)和關(guān)口GPRS支持節(jié)點(diǎn)(gateway GPRS support node，GGSN)之間。應(yīng)用協(xié)議是由UDP/IP承載的GPRS隧道協(xié)議(GPRS tunnelling protocol，GTP)。它又分為控制面和用戶面兩個(gè)平面，控制面為GTP-C，用戶面為GTP-U。GTP-U隧道內(nèi)透?jìng)鞯氖且苿?dòng)終端和應(yīng)用服務(wù)器之間的業(yè)務(wù)內(nèi)容。對(duì)基于WAP 1.x的彩信業(yè)務(wù)，GTP-U內(nèi)業(yè)務(wù)數(shù)據(jù)的協(xié)議棧為MMSE/WSP/WTP/UDP/IP［6，8］，如圖 2 所示。

圖2 Gn接口協(xié)議棧(含隧傳的WAP彩信)Fig.2 Protocol stack on the interface Gn(including tunneled WAP MMS)

要從GTP PDU重組得到MMS文件，必須考慮WTP和兩層IP協(xié)議的分片重組(segmentation and re-assembly)。WTP層分片重組的主要目的是為了實(shí)現(xiàn)選擇性重傳，并提高空中接口的傳送效率［5］;兩層IP分片包括GTP下層的IP和WAP下層的IP分片，主要是受其下鏈路層幀長(zhǎng)的限制，比如以太網(wǎng)幀長(zhǎng)必須小于1 500 Byte。

在支持分片重組的情況下，完整的WTP消息被分割成多個(gè)包(Packet)逐個(gè)發(fā)送，多個(gè)連續(xù)包構(gòu)成一個(gè)包組(Packet Group)，接收端按包組進(jìn)行確認(rèn)。WTP利用消息頭中的GTR/TTR組合標(biāo)志位來(lái)指示包組或消息的結(jié)束:GTR置位時(shí)，指示一個(gè)包組發(fā)送結(jié)束;TTR置位時(shí)，表示整個(gè)消息發(fā)送完畢。接收端在收到GTR指示后，對(duì)該包組進(jìn)行檢查確認(rèn)，發(fā)送端收到肯定確認(rèn)(Ack)后才繼續(xù)后續(xù)包的發(fā)送。

WTP利用選擇性重傳機(jī)制保證數(shù)據(jù)的可靠性傳遞。每個(gè)包攜帶一個(gè)序列號(hào)(packet sequence number，PSN)來(lái)指示該包在整個(gè)消息中的順序。如果接收端發(fā)現(xiàn)收到的包組不完整，則會(huì)向發(fā)送端回送Nack消息，攜帶缺失包的個(gè)數(shù)和PSNs。發(fā)送端據(jù)此重發(fā)缺失的包。

為適應(yīng)互聯(lián)最大傳送單元(maximum transmission unit，MTU)大小不一樣的網(wǎng)絡(luò)，IP層支持分片重組是必需的。IP分片情況下，屬于同一個(gè)數(shù)據(jù)報(bào)的各個(gè)分片，其IP 頭部下面 4個(gè)字段(“identification”，“source”，“destination”和“protocol”)全部一樣。每個(gè)片段在整個(gè)數(shù)據(jù)報(bào)中位置偏移量由“fragment offset”指示，單位為Byte?！癴ragment offset”為0的是第一個(gè)片段，最后一個(gè)片段的“more-fragments”設(shè)置為0。

2 分片重組算法

由于Gn接口同時(shí)存在數(shù)千個(gè)數(shù)據(jù)流，因此，在進(jìn)行分片重組之前，首先需要將數(shù)據(jù)按不同用戶、不同的業(yè)務(wù)流程進(jìn)行分類(lèi)，然后并行進(jìn)行處理。數(shù)據(jù)流分類(lèi)通過(guò)源/目的IP地址加兩端的隧道端點(diǎn)標(biāo)識(shí)符(tunnel endpoint identifier，TEID)過(guò)濾來(lái)實(shí)現(xiàn)［10］。本算法面向已分類(lèi)好的數(shù)據(jù)流。

數(shù)據(jù)處理按照協(xié)議棧層次由低到高，從以太幀開(kāi)始，經(jīng)過(guò) IP1/UDP/GTP-U/IP2/UDP/WTP/WSP，中間IP1，IP2和WTP可能的分片重組，以及可能的亂序、丟包重傳等處理，最終得到MMS PDU。具體步驟如下。

1)以太幀處理:檢查“Type”字段，如果為“IP”(0x80)，則取凈荷數(shù)據(jù)作為IP包(Packet)，繼續(xù)下一步;否則返回，取下一幀數(shù)據(jù)。

2)IP1包處理:提取“Source”(記為 S)，“Desti-nation”(記為 D)，“Protocol”(記為 P)，“Identification”(記為I)，“Flags”(記為F)和“Fragment Offset”(記為FO)，分下面幾種情況。

a 不存在分片(F=0x00，且FO=0x00):如果P=UDP(17)，則提取凈荷作為UDP報(bào)文，繼續(xù)下一步;否則返回，取下一幀數(shù)據(jù);

b 第一片(F=0x01且FO=0x00):記下數(shù)據(jù)報(bào)的標(biāo)識(shí)參數(shù):S，D，P，I(記為S－D －P －I));并提取凈荷作為第一片暫存起來(lái)，同時(shí)記下該片的長(zhǎng)度(Li，i=1)和FO。檢索之前是否已有不完整的分片，如果SD－P－I參數(shù)相同，則屬于同一個(gè)數(shù)據(jù)報(bào)(注:由于路由不同，可能會(huì)發(fā)生后發(fā)先至的情況)。

c 中間的某一片(F=0x01且FO!=0x00):處理方式，同b);

d 最后一片(F=0x00且FO!=0x00):記下數(shù)據(jù)報(bào)的標(biāo)識(shí)參數(shù):S，D，P，I(記為S－D－P－I));并提取凈荷作為最后一片暫存起來(lái)，同時(shí)記下該片的長(zhǎng)度(Li，i=1)和FO。檢索已有的分片，如果合并后能構(gòu)成完整的數(shù)據(jù)報(bào)，則以合并后的凈荷作為UDP PDU，跳轉(zhuǎn)至第3)步;否則，返回繼續(xù)處理下一幀。

3)UDP報(bào)文處理:提取源端口(SrcPort)和目的端口(DstPort)號(hào)，如果 SrcPort=DstPort=2 152(GTP-User)，則提取凈荷部分作為GTP-U PDU(GPDU)，繼續(xù)下一步處理;否則，返回，取下一幀數(shù)據(jù)。

4)G-PDU處理:提取凈荷(T-PDU)作為IP包，繼續(xù)下步處理。

5)IP2包處理:同第2)步。

6)UDP報(bào)文處理:提取源端口(SrcPort)和目的端口(DstPort)號(hào)，如果 SrcPort=9 201或 DstPort=9 201(wap-wsp-wtp)，則提取凈荷部分作為 WTP PDU，繼續(xù)下一步處理;否則，返回，取下一幀數(shù)據(jù)。

7)WTP PDU處理:提取“PDU Type”和事務(wù)標(biāo)識(shí)(TID)，TID由兩部分構(gòu)成:TID字段的最高位比特，記為T(mén)IDRsp，用來(lái)指示消息方向(0代表從請(qǐng)求者到接收者);其余比特記為T(mén)IDValue，代表TID的值，用于關(guān)聯(lián)屬于同一個(gè)事務(wù)的應(yīng)答(Ack，Nack，Result和Segmented Result)和請(qǐng)求消息(Invoke，Segmented Invoke)。使用變量MS(message status)來(lái)表示消息重組的全局狀態(tài)，它有3個(gè)狀態(tài):GI(group intermediate)，GE(group end)和ME(message end)。根據(jù)PDU的不同的類(lèi)型，做相應(yīng)的處理。

a Invoke/Result:記錄TIDValue作為全局事務(wù)ID:gTID;取GTR/TTR組合標(biāo)志，記為T(mén)R，分以下幾種情況。

i TR=0x01(表示本PDU為消息的最后一個(gè)包):即沒(méi)有分片，設(shè)定MS=ME。如果有凈荷部分，則取凈荷部分作為WSP PDU，執(zhí)行第8)步;否則，返回繼續(xù)處理下一幀;

ii TR=0x00(本PDU既不是組的最后一個(gè)包，也不是消息的最后一個(gè)包):即后續(xù)有其他分片，則提取凈荷部分，作為該消息的第一個(gè)分片，序列號(hào)PSN記為0，并設(shè)MS=GI;返回，繼續(xù)處理下一幀;

iii TR=0x10(表示本PDU是組的最后一個(gè)包):即本消息的第一組只有一個(gè)包，后續(xù)有其他組，則提取凈荷部分，作為該消息的第一個(gè)分片，PSN記為0，并設(shè)MS=GE;返回，繼續(xù)處理下一幀。

b Segmented Invoke/Segmented Result:取TR標(biāo)識(shí)位和分組序列號(hào)PSN，繼續(xù)下面的處理。

i TR=0x01(表示本PDU為消息最后一個(gè)包):設(shè)MS=ME。則取凈荷部分作為該消息最后一個(gè)分片，記下PSN，TIDValue;檢查PSN是否完整，如果完整，跳轉(zhuǎn)到c)，進(jìn)行WTP重組;

ii TR=0x00(后續(xù)有其他分片):則提取凈荷部分，作為該消息的中間一個(gè)分片，記下PSN，TIDValue，并設(shè)MS=GI;返回，繼續(xù)處理下一幀;

iii TR=0x10(表示本PDU是組的最后一個(gè)包，后續(xù)有其他組):則提取凈荷部分，作為該消息的中間的一個(gè)分片，記下PSN，TIDValue，并設(shè)MS=GE;返回，繼續(xù)處理下一幀。

c WTP重組:使用鏈表暫存每個(gè)分片，記錄每個(gè)分片的TIDValue和PSN，當(dāng)分片收集完整時(shí)，按PSN順序合并全部分片的凈荷，作為WSP PDU跳轉(zhuǎn)至8)。

8)WSP處理:取Data部分，如果其Content-type為 application/vnd.wap.mms-message，則提取數(shù)據(jù)部分，即MMS PDU，繼續(xù)重建圖像文件部分的處理。否則，返回。

如1.1節(jié)所述，MMS圖像文件封裝在 MMS PDU的多部分消息體中，最常見(jiàn)的內(nèi)容類(lèi)型為im-age/jpeg，其編碼采用與JPEG兼容的JFIF(JPEG file interchange format)［11-12］。彩信圖像文件數(shù)據(jù)包含在JFIF數(shù)據(jù)部分，文件名包含在“content-type”頭部‘name’字段。因此，在圖像文件重建時(shí)，提取JFIF部分的二進(jìn)制圖像數(shù)據(jù)，以‘name’字段來(lái)重命名，擴(kuò)展名為“jpg”。

3 測(cè)試和分析

算法驗(yàn)證在已有的信令監(jiān)測(cè)系統(tǒng)上補(bǔ)充開(kāi)發(fā)完成，測(cè)試系統(tǒng)如圖3所示。Gn接口數(shù)據(jù)首先經(jīng)過(guò)分光比為2∶8的分光器，能量較小的部分經(jīng)數(shù)據(jù)采集模塊完成數(shù)據(jù)捕獲和格式轉(zhuǎn)換，然后送給識(shí)別模塊，將GTP-C和GTP-U分開(kāi)處理，其中GTP-C信令處理部分完成監(jiān)測(cè)系統(tǒng)原有功能，而GTP-U部分?jǐn)?shù)據(jù)處理用于新增的業(yè)務(wù)面分析。用C/C++語(yǔ)言實(shí)現(xiàn)第2節(jié)算法，封裝為分片重組模塊，采用多個(gè)實(shí)例并行處理多個(gè)GTP-U業(yè)務(wù)流，輸出彩信圖像文件。

這里以一條彩信記錄為例，詳細(xì)分析各幀數(shù)據(jù)分片重組情況。樣本數(shù)據(jù)有7幀，各幀數(shù)據(jù)的分片情況見(jiàn)表1，對(duì)應(yīng)的原始數(shù)據(jù)可以與作者聯(lián)系取得，其格式為業(yè)界最常用的 Libpcap［13］。它包含一個(gè)24 Byte長(zhǎng)的全局頭部(global header)或稱(chēng)文件頭，之后是按時(shí)間順序排列的各幀數(shù)據(jù);每幀數(shù)據(jù)包含一個(gè)16 Byte長(zhǎng)的包頭(packet header)和長(zhǎng)度可變的包數(shù)據(jù)(packet data)。

圖3 測(cè)試系統(tǒng)示意圖Fig.3 Diagram of monitoring system testbed

如表1所示，各幀數(shù)據(jù)分片情況總結(jié)如下。

1)第1幀數(shù)據(jù)是WTP消息的第一片(PSN=0)，PDU類(lèi)型為WTP Invoke，單獨(dú)構(gòu)成WTP的一個(gè)包組，凈荷長(zhǎng)1 112 Byte;

2)第3幀和第4幀屬于IP1分片，合并構(gòu)成WTP消息的第2片(PSN=1)，PDU類(lèi)型為 WTP Segmented Invoke，凈荷長(zhǎng)1 400 Byte;

3)第5幀和第6幀屬于IP1分片，合并構(gòu)成WTP消息的第3片(PSN=2)，PDU類(lèi)型為Segmented Invoke，凈荷長(zhǎng)1 400 Byte;其中2幀數(shù)據(jù)存在倒序情況;

4)第7幀是WTP消息的最后一片(PSN=3)，PDU類(lèi)型為Segmented Invoke，凈荷長(zhǎng)638 Byte。

分片重組程序通過(guò)自動(dòng)分析各幀數(shù)據(jù)，合并WTP消息分片凈荷，得到WSP Post消息和MMS m-Send.req消息;進(jìn)一步通過(guò)提取image/jpeg部分JFIF凈荷，成功得到彩信的圖像文件—ca12d700.jpg，如圖4所示。

圖4 合成出的彩信圖像文件(ca12d700.jpg)Fig.4 Synthesized file of MMS image(ca12d700.jpg)

4 結(jié)論

論文深入研究了WAP彩信業(yè)務(wù)流程和多協(xié)議層次分片重組機(jī)理，設(shè)計(jì)并實(shí)現(xiàn)了多層協(xié)議分片重組和圖像重建算法;并基于已有的信令監(jiān)測(cè)系統(tǒng)完成補(bǔ)充開(kāi)發(fā)，利用現(xiàn)網(wǎng)數(shù)據(jù)對(duì)算法進(jìn)行了驗(yàn)證，成功實(shí)現(xiàn)了WAP彩信圖像文件的還原。論文詳細(xì)分析了包括IP分片、WTP分片和亂序情況的樣本數(shù)據(jù)，并展示了清晰的重建結(jié)果。

應(yīng)用論文成果，現(xiàn)有的監(jiān)測(cè)系統(tǒng)就可以直接完成Gn接口用戶面數(shù)據(jù)處理，實(shí)現(xiàn)移動(dòng)數(shù)據(jù)業(yè)務(wù)內(nèi)容監(jiān)控，而不需要另外建設(shè)新的系統(tǒng)。通過(guò)對(duì)業(yè)務(wù)數(shù)據(jù)進(jìn)一步的挖掘，還可以提取到用戶號(hào)碼、IP地址、訪問(wèn)服務(wù)器等信息;與信令面關(guān)聯(lián)，還可以進(jìn)一步獲得用戶網(wǎng)絡(luò)位置、終端類(lèi)型等信息，這樣能為全面的用戶業(yè)務(wù)感知和內(nèi)容監(jiān)控提供更有力的支持。

表1 樣本數(shù)據(jù)分析表Tab.1 Analysis of sample data

［1］劉強(qiáng)，崔莉，陳海明.物聯(lián)網(wǎng)關(guān)鍵技術(shù)與應(yīng)用［J］.計(jì)算機(jī)科學(xué)，2010，37(6):1-4.LIU Qiang，CUI Li，CHEN Hai-ming.Key Technologies and Application of Internet of Things［J］.Computer Science，2010，37(6):1-4.

［2］王東揚(yáng)，孫瑜，胡杰.3G手機(jī)通信領(lǐng)域安全隱患與防范措施［J］.信息網(wǎng)絡(luò)安全，2010，(7):14-15.WANG Dong-yang，SUN Yu，HU Jie.Security Risks and Preventation in the Area of 3G Mobile Communication［J］.Netinfo Security，2010，(7):14-15.

［3］王迎春，王薇.NO.7信令集中監(jiān)測(cè)系統(tǒng)在網(wǎng)絡(luò)質(zhì)量管理中的應(yīng)用［J］.電信科學(xué)，2005，(7):63-66.WANG Ying-chun，WANG Wei.Application of NO.7 Signaling Centralized Monitoring System in the Management ofNetwork Quality［J］.Telecommunications Science2005，(7):63-66.

［4］韋薇，張揚(yáng).信令監(jiān)測(cè)系統(tǒng)架構(gòu)規(guī)范的演進(jìn)［J］.電信工程技術(shù)與標(biāo)準(zhǔn)化，2011，(4):48-52.WEI Wei，ZHANG Yang.Evolution of Architecture Specification in Signaling Monitoring System［J］.Telecom En-gineering Technics and Standardization，2011，(4):48-52.

［5］OMA WAP Forum.WAP-201-WTP，Wireless Application Protocol:WirelessTransaction ProtocolSpecification［EB/OL］.(2000-02-19)［2011-09-10］.http://www.openmobilealliance.org/Technical/wapindex.aspx.

［6］OMA WAP Forum.WAP-203-WSP，Wireless Application Protocol:Wireless Session Protocol Specification［EB/OL］.(2000-05-04)［2011-08-10］.http://www.openmobilealliance.org/Technical/wapindex.aspx.

［7］OMAWAPForum.WAP-206-MMSCTR-20020115-a，WAP MMS Client Transactions［EB/OL］.(2002-01-15)［2011-09-11］.http://www.openmobilealliance.org/Technical/wapindex.aspx.

［8］OMA WAP Forum. WAP-209-MMSEncapsulation-20020105-a，Wireless Application Protocol:MMS Encapsulation Protocol［EB/OL］.(2002-01-05)［2011-08-05］.http://www.openmobilealliance.org/Technical/wapindex.aspx.

［9］IETF.RFC2387，The MIME Multipart/Related Contenttype［EB/OL］.(1998-08-10)［2011-08-15］.http://www.rfc-editor.org/rfc/rfc2387.txt.

［10］3GPP Organization Partners.3GPP TS 29.060，GPRS Tunneling Protocol(GTP)across the Gn and Gp interface(Release 9)［EB/OL］.(2010-12-22)［2011-08-15］.http://www.3gpp.org/ftp/Specs/html-info/29060.htm.

［11］IETF.RFC2046，Multipurpose Internet Mail Extensions(MIME)Part Two:Media Types［EB/OL］.(1996-11-10)［2011-09-01］.http://www.rfc-editor.org/rfc/rfc2046.txt.

［12］W3C.JPEG File Interchange Format［EB/OL］.(1992-09-01)［2011-08-12］.http://www.w3.org/Graphics/JPEG/jfif3.pdf.

［13］WIRESHARK Wiki.Libpcap File Format［EB/OL］.(2011-03-20)［2011-08-15］.http://wiki.wireshark.org/Development/LibpcapFileFormat.