WAP 彩信业务多层数据重组和图像重建方法

雒江涛，杨 叶，舒忠玲，袁 亮

(1.重庆邮电大学通信与信息工程学院，重庆 400065;2.重庆高校通信网测试技术工程研究中心，重庆 400065;3.重庆中天重邮通信技术有限公司，重庆 401121)

0 引言

随着移动通信网络基础设施和智能手机技术的不断发展，基于无线应用协议(wireless application protocol，WAP)的手机上网业务已逐渐成为现代人们工作和生活中的重要组成部分。同时，它也是未来物联网发展的基础技术之一和重要的应用［1］。其中，移动彩信业务即多媒体消息服务(multimedia messaging service，MMS)，是承载这一应用有效的服务形式，也是目前应用最广泛的移动数据业务类型之一。它不但支持移动用户终端、监测终端和服务器之间互相发送文本、语音、图像或视频等多种媒体的混合，而且支持服务提供商(service provider，SP)向移动用户推送多媒体新闻或娱乐内容(比如手机报)。然而，彩信业务给用户带来便利的同时，也给违法人员提供了可趁之机，常被用来传递非法信息，还被用于在3G网络中传递手机病毒［2］。因此，对彩信业务的内容进行适当的监控非常必要，也已经引起了政府有关部门的高度重视。

目前移动通信网络的监测主要基于信令监测系统［3-4］，它将多个网络接口的信令和业务数据复制下来进行关联分析，对网络运行状况和业务质量水平进行评估，为管理维护人员提供参考依据。监测系统已经成为移动通信网络运行的重要支撑系统和必不可少的工具。然而，目前的监测系统主要面向信令面，缺乏业务面分析能力，这主要是由于业务面数据涉及多层协议数据分片重组，处理起来非常困难，一直缺乏有效的业务内容还原方法。实践中，往往需要另外新建专门的内容监控系统，采集更靠近业务中心的网络接口，这势必造成重复建设和巨大的浪费。

为此，本文深入研究了GPRS/WCDMA分组域核心网无线应用协议(wireless application protocol，WAP)彩信业务即MMS的协议栈和业务流程，设计出面向Gn接口的多层业务数据分片重组和数据图像文件的重建方法。它能够基于GPRS核心网Gn接口的用户面数据还原得到原始图像文件，从而基于现有的监测系统即可实现数据业务的内容监测。

彩信业务有WAP 1.x和WAP 2.0两种承载方式，本文针对协议层次更多、更复杂的WAP 1.x。

1 原理

1.1 WAP 1.x彩信

WAP 1.x彩信业务流程如图1所示，彩信发送和接收过程各构成一个无线会话协议(wireless session protocol，WSP)会话［5-8］。无线会话协议使用Connect/Connect Reply消息建立会话，用Disconnect消息释放会话。会话的建立和释放分别采用一个无线事务协议(wireless transaction protocol，WTP)2类和0类事务承载;会话存续期间使用一个或多个WTP的2类事务完成彩信的发送、提取及其确认过程［5-6］。无线事务协议支持分片重组，它采用分段调用(segmented invoke)消息支持将较大的Invoke消息分片发送;同时，也支持用分段结果(segmented result)消息将调用结果分片返回［5］。较大的彩信文件正是利用这种机制进行传递的。WTP同时还利用按组(Group)确认、否定确认(Nack)、选择性重传等机制保证WTP分段按顺序可靠传送［5］。

图1 WAP 1.x彩信业务流程Fig.1 Service process of MMS on WAP 1.x

在彩信发送过程中，彩信文件由MMS层MSend.req消息携带;接收过程中，由 M-Retrieve.conf消息携带。MMS消息封装在WSP Post或WSP Reply操作的数据部分，其内容类型为“application/vnd.wap.mms-message”，编码规则遵从文献［8］。

多媒体对象位于MMS消息的多部分消息体(multipart body)中，采用类似电子邮件的MIME Multipart/Related结构［9］。每个多媒体对象作为一个独立的部分，可能是 image/jpeg，text/plain，audio/wave 等不同类型。彩信图像文件对应image/jpeg类型。

1.2 多层分片重组原理

Gn接口是GPRS核心网信令和业务最集中的接口，也是监测系统最重要的采集接口。它位于服务GPRS 支持节点(serving GPRS support node，SGSN)和关口GPRS支持节点(gateway GPRS support node，GGSN)之间。应用协议是由UDP/IP承载的GPRS隧道协议(GPRS tunnelling protocol，GTP)。它又分为控制面和用户面两个平面，控制面为GTP-C，用户面为GTP-U。GTP-U隧道内透传的是移动终端和应用服务器之间的业务内容。对基于WAP 1.x的彩信业务，GTP-U内业务数据的协议栈为MMSE/WSP/WTP/UDP/IP［6，8］，如图 2 所示。

图2 Gn接口协议栈(含隧传的WAP彩信)Fig.2 Protocol stack on the interface Gn(including tunneled WAP MMS)

要从GTP PDU重组得到MMS文件，必须考虑WTP和两层IP协议的分片重组(segmentation and re-assembly)。WTP层分片重组的主要目的是为了实现选择性重传，并提高空中接口的传送效率［5］;两层IP分片包括GTP下层的IP和WAP下层的IP分片，主要是受其下链路层帧长的限制，比如以太网帧长必须小于1 500 Byte。

在支持分片重组的情况下，完整的WTP消息被分割成多个包(Packet)逐个发送，多个连续包构成一个包组(Packet Group)，接收端按包组进行确认。WTP利用消息头中的GTR/TTR组合标志位来指示包组或消息的结束:GTR置位时，指示一个包组发送结束;TTR置位时，表示整个消息发送完毕。接收端在收到GTR指示后，对该包组进行检查确认，发送端收到肯定确认(Ack)后才继续后续包的发送。

WTP利用选择性重传机制保证数据的可靠性传递。每个包携带一个序列号(packet sequence number，PSN)来指示该包在整个消息中的顺序。如果接收端发现收到的包组不完整，则会向发送端回送Nack消息，携带缺失包的个数和PSNs。发送端据此重发缺失的包。

为适应互联最大传送单元(maximum transmission unit，MTU)大小不一样的网络，IP层支持分片重组是必需的。IP分片情况下，属于同一个数据报的各个分片，其IP 头部下面 4个字段(“identification”，“source”，“destination”和“protocol”)全部一样。每个片段在整个数据报中位置偏移量由“fragment offset”指示，单位为Byte。“fragment offset”为0的是第一个片段，最后一个片段的“more-fragments”设置为0。

2 分片重组算法

由于Gn接口同时存在数千个数据流，因此，在进行分片重组之前，首先需要将数据按不同用户、不同的业务流程进行分类，然后并行进行处理。数据流分类通过源/目的IP地址加两端的隧道端点标识符(tunnel endpoint identifier，TEID)过滤来实现［10］。本算法面向已分类好的数据流。

数据处理按照协议栈层次由低到高，从以太帧开始，经过 IP1/UDP/GTP-U/IP2/UDP/WTP/WSP，中间IP1，IP2和WTP可能的分片重组，以及可能的乱序、丢包重传等处理，最终得到MMS PDU。具体步骤如下。

1)以太帧处理:检查“Type”字段，如果为“IP”(0x80)，则取净荷数据作为IP包(Packet)，继续下一步;否则返回，取下一帧数据。

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 第一片(F=0x01且FO=0x00):记下数据报的标识参数:S，D，P，I(记为S－D －P －I));并提取净荷作为第一片暂存起来，同时记下该片的长度(Li，i=1)和FO。检索之前是否已有不完整的分片，如果SD－P－I参数相同，则属于同一个数据报(注:由于路由不同，可能会发生后发先至的情况)。

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

d 最后一片(F=0x00且FO!=0x00):记下数据报的标识参数:S，D，P，I(记为S－D－P－I));并提取净荷作为最后一片暂存起来，同时记下该片的长度(Li，i=1)和FO。检索已有的分片，如果合并后能构成完整的数据报，则以合并后的净荷作为UDP PDU，跳转至第3)步;否则，返回继续处理下一帧。

3)UDP报文处理:提取源端口(SrcPort)和目的端口(DstPort)号，如果 SrcPort=DstPort=2 152(GTP-User)，则提取净荷部分作为GTP-U PDU(GPDU)，继续下一步处理;否则，返回，取下一帧数据。

4)G-PDU处理:提取净荷(T-PDU)作为IP包，继续下步处理。

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

6)UDP报文处理:提取源端口(SrcPort)和目的端口(DstPort)号，如果 SrcPort=9 201或 DstPort=9 201(wap-wsp-wtp)，则提取净荷部分作为 WTP PDU，继续下一步处理;否则，返回，取下一帧数据。

7)WTP PDU处理:提取“PDU Type”和事务标识(TID)，TID由两部分构成:TID字段的最高位比特，记为TIDRsp，用来指示消息方向(0代表从请求者到接收者);其余比特记为TIDValue，代表TID的值，用于关联属于同一个事务的应答(Ack，Nack，Result和Segmented Result)和请求消息(Invoke，Segmented Invoke)。使用变量MS(message status)来表示消息重组的全局状态，它有3个状态:GI(group intermediate)，GE(group end)和ME(message end)。根据PDU的不同的类型，做相应的处理。

a Invoke/Result:记录TIDValue作为全局事务ID:gTID;取GTR/TTR组合标志，记为TR，分以下几种情况。

i TR=0x01(表示本PDU为消息的最后一个包):即没有分片，设定MS=ME。如果有净荷部分，则取净荷部分作为WSP PDU，执行第8)步;否则，返回继续处理下一帧;

ii TR=0x00(本PDU既不是组的最后一个包，也不是消息的最后一个包):即后续有其他分片，则提取净荷部分，作为该消息的第一个分片，序列号PSN记为0，并设MS=GI;返回，继续处理下一帧;

iii TR=0x10(表示本PDU是组的最后一个包):即本消息的第一组只有一个包，后续有其他组，则提取净荷部分，作为该消息的第一个分片，PSN记为0，并设MS=GE;返回，继续处理下一帧。

b Segmented Invoke/Segmented Result:取TR标识位和分组序列号PSN，继续下面的处理。

i TR=0x01(表示本PDU为消息最后一个包):设MS=ME。则取净荷部分作为该消息最后一个分片，记下PSN，TIDValue;检查PSN是否完整，如果完整，跳转到c)，进行WTP重组;

ii TR=0x00(后续有其他分片):则提取净荷部分，作为该消息的中间一个分片，记下PSN，TIDValue，并设MS=GI;返回，继续处理下一帧;

iii TR=0x10(表示本PDU是组的最后一个包，后续有其他组):则提取净荷部分，作为该消息的中间的一个分片，记下PSN，TIDValue，并设MS=GE;返回，继续处理下一帧。

c WTP重组:使用链表暂存每个分片，记录每个分片的TIDValue和PSN，当分片收集完整时，按PSN顺序合并全部分片的净荷，作为WSP PDU跳转至8)。

8)WSP处理:取Data部分，如果其Content-type为 application/vnd.wap.mms-message，则提取数据部分，即MMS PDU，继续重建图像文件部分的处理。否则，返回。

如1.1节所述，MMS图像文件封装在 MMS PDU的多部分消息体中，最常见的内容类型为im-age/jpeg，其编码采用与JPEG兼容的JFIF(JPEG file interchange format)［11-12］。彩信图像文件数据包含在JFIF数据部分，文件名包含在“content-type”头部‘name’字段。因此，在图像文件重建时，提取JFIF部分的二进制图像数据，以‘name’字段来重命名，扩展名为“jpg”。

3 测试和分析

算法验证在已有的信令监测系统上补充开发完成，测试系统如图3所示。Gn接口数据首先经过分光比为2∶8的分光器，能量较小的部分经数据采集模块完成数据捕获和格式转换，然后送给识别模块，将GTP-C和GTP-U分开处理，其中GTP-C信令处理部分完成监测系统原有功能，而GTP-U部分数据处理用于新增的业务面分析。用C/C++语言实现第2节算法，封装为分片重组模块，采用多个实例并行处理多个GTP-U业务流，输出彩信图像文件。

这里以一条彩信记录为例，详细分析各帧数据分片重组情况。样本数据有7帧，各帧数据的分片情况见表1，对应的原始数据可以与作者联系取得，其格式为业界最常用的 Libpcap［13］。它包含一个24 Byte长的全局头部(global header)或称文件头，之后是按时间顺序排列的各帧数据;每帧数据包含一个16 Byte长的包头(packet header)和长度可变的包数据(packet data)。

图3 测试系统示意图Fig.3 Diagram of monitoring system testbed

如表1所示，各帧数据分片情况总结如下。

1)第1帧数据是WTP消息的第一片(PSN=0)，PDU类型为WTP Invoke，单独构成WTP的一个包组，净荷长1 112 Byte;

2)第3帧和第4帧属于IP1分片，合并构成WTP消息的第2片(PSN=1)，PDU类型为 WTP Segmented Invoke，净荷长1 400 Byte;

3)第5帧和第6帧属于IP1分片，合并构成WTP消息的第3片(PSN=2)，PDU类型为Segmented Invoke，净荷长1 400 Byte;其中2帧数据存在倒序情况;

4)第7帧是WTP消息的最后一片(PSN=3)，PDU类型为Segmented Invoke，净荷长638 Byte。

分片重组程序通过自动分析各帧数据，合并WTP消息分片净荷，得到WSP Post消息和MMS m-Send.req消息;进一步通过提取image/jpeg部分JFIF净荷，成功得到彩信的图像文件—ca12d700.jpg，如图4所示。

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

4 结论

论文深入研究了WAP彩信业务流程和多协议层次分片重组机理，设计并实现了多层协议分片重组和图像重建算法;并基于已有的信令监测系统完成补充开发，利用现网数据对算法进行了验证，成功实现了WAP彩信图像文件的还原。论文详细分析了包括IP分片、WTP分片和乱序情况的样本数据，并展示了清晰的重建结果。

应用论文成果，现有的监测系统就可以直接完成Gn接口用户面数据处理，实现移动数据业务内容监控，而不需要另外建设新的系统。通过对业务数据进一步的挖掘，还可以提取到用户号码、IP地址、访问服务器等信息;与信令面关联，还可以进一步获得用户网络位置、终端类型等信息，这样能为全面的用户业务感知和内容监控提供更有力的支持。

表1 样本数据分析表Tab.1 Analysis of sample data

［1］刘强，崔莉，陈海明.物联网关键技术与应用［J］.计算机科学，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］王东扬，孙瑜，胡杰.3G手机通信领域安全隐患与防范措施［J］.信息网络安全，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信令集中监测系统在网络质量管理中的应用［J］.电信科学，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］韦薇，张扬.信令监测系统架构规范的演进［J］.电信工程技术与标准化，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.