[feature phone系列]彩信的架构和实现原理

彩信的架构和实现原理

MMS的标准是由WAP Forum和3GPP这两个组织制定的.

MMS可以通过MS发送

MMS可以通过网站发送，因为使用的是SMTP协议.

MMSC, Multimedia Message Service Center. // 存储转发机制

MMS内容服务部分完全通过互联网和MMSC相连

MMS采用类似HTML的SMIL语言来编辑短信内容 // 方便SP使用简单工具开发图文并茂的彩信.

MMS reference architecture[Referenced from wiki]:



MM1: the interface between MMS User Agent and MMS Center

MM2: the interface between MMS Relay and MMS Server

MM3: the interface between MMS Center and external servers

MM4: the interface between MMS Centers

MM5: the interface between MMS Center and HLR

MM6: the interface between MMS Center and user databases

MM7: the interface between MMS VAS[Value-added service] applications and MMS Center

MM8: the interface between MMS Center and the billing systems

MM9: the interface between MMS Center and an online charging system

MM10: the interface between MMS Center and a message service control function

MM11: the interface between MMS Center and an external transcoder

MMS Architectural Elements[Reference from 3GPP_TS_23.140]

shows that multimedia messaging may encompass many different network types. The basis of connectivity between these different networks shall be provided by the Internet protocol and its associated set of messaging protocols. This approach enables messaging
in 2G and 3G wireless networks to be compatible with messaging systems found on the Internet.



MMS Architectural Elements

MMSE, Multimedia Message Services Environment.

MSISDN,Mobile Subscriber International ISDN/PSTN number[移动用户号码]

Protocol Framework



Protocol Framework to provide MMS

MM1提交Multimedia Message从MMS user agent到MMS Relay/Server, MMS Relay/Server派发MM通知信息到MMS user agent.

MM1接口分为两部分：

1.用户终端和WAP网关之间的接口:基于WAP或IP协议实现;

2.WAP网关和MMSC之间的接口:基于IP协议实现，承载层协议为HTTP;

基于WAP的协议栈，如下图



基于IP的协议栈, 如下图



MM2

基于MMS Relay和MMS Server之间的接口，属于内部接口，不同的厂家设备有不同的实现方式.

MM3主要是MMS Relay/Server和External Server交互[发送or获取MM]

该接口基于已经成熟的应用于Internet网上的协议来实现,承载层基于IP,应用层基于SMTP.

MM4, Interworking of different MMSEs,MMS Relay/Server之间的交互基于SMTP协议[STD 10 RFC 2821]

基于IP协议栈实现,应用层协议为HTTP.

MM5, HLR[归属寄存器]

基于No.7协议实现,业务层协议是移动应用MAP协议.在目前组网中,一般用不到MM5接口.

MM6, MMS User Databases

3GPP协议没有对MM6接口的实现协议做具体规定,属于内部接口.

MM7,MMS VAS Applications

基于IP协议栈实现,应用层协议是HTTP和SOAP[Simple Object Access Protocol]

MM8,Post-processing system,MMSC和Billing之间用于计费的接口

基于IP协议栈实现，应用层协议是FTP/FTAM等



业务流流程：

点到点业务流程，



PUSH接口：MMSC和SMSC之间的接口,如上图,主要是对需要接收彩信的用户发起PUSH短信通知.

SGSN, Service GPRS Supporting Node [GPRS业务支持节点]

GGSN, Gateway GPRS Support Node[网关GPRS支持节点]

ISMG, Internet Short Message Gateway[互联网短信网关]

网络架构：

实现原理：

端到端流程图：引用自[http://blog.csdn.net/gnuhpc/article/details/4906798]



引用自[http://blog.csdn.net/gnuhpc/article/details/4906798]

发送过解析

Step1：

-MMS用户代理发送多媒体短信，信息以WAP WSP 的协议进行编码，通过GPRS网络传送到WAP网关

Step2：

-WAP网关通过向重定向器发送请求，获得发送方用户的归属 MMSC地址，并以HTTP协议将消息内容传送给归属MMSC的 MMS中继器

Step3：

-MMS中继器通过向号码域名解析器发送请求，获得接收方用户的归属MMSC地址，若该地址不是当前MMSC，则将消息内容传送给接受方归属MMSC的MMS中继器

Step4：

- 接受方归属MMSC的MMS中继器将消息内容送往MMS服务器

Step5：

-MMS服务器从数据库获得用户路由信息、终端信息等，根据终端承载能力对MM进行不同的处理，将MM内容转换成MIME[Multipurpose Internet Mail Extensions]格式并存储在消息存储器中一直保存到确认接收方用户已接收 了信息通知

Step6：

-MMS中继器通过WAP网关连接到短消息中心SMSC， 利用WAP PUSH功能将消息体通过短消息的方式通知 用户 获取

Step7：

- 接收方MMS用户代理通过GPRS网络和WAP网关从归 属MMSC处获取到多媒体消息

Step8：

- 接收方MMS用户代理向MMS中继器发送接收确认消息 报告

Step9：

-MMS中继器通过WAP网关利用WAP PUSH功能向源 MMS用户代理报告MMS传递结果

术语解释：

DNS-ENUM, [DNS,Domain Name Server] ,ENUM(tElephone NUmber Mapping),是当今计算机资源寻址定位方式的热点。它采用符合E.164标准的电话号码为用户通讯的入口，采用DNS技术和运行框架为用户提供便捷的解析服务。用户可以采用电话号码完成VoIP的寻址定位，以及HTTP访问，电子邮件，目录服务等网络应用，并完成访问限制，查询重定向等一系列功能。

MM点到点的流程图：引用自[http://blog.csdn.net/gnuhpc/article/details/4906798]



MM的基本结构：

MM在发送过程中，其实是发送MM的PDU到WSP PDUs或者HTTP，关于WSP或者HTTP要看你使用的是那种传输协议.

比如： application/vnd.wap.mms-message是MMS PDU对应的content-type.



Model of MMS PDU containing a multipart/related message body

从上面图中我们可以看到，整个MM PDU由两部分组成：下面内容引自[http://cnetwei.iteye.com/blog/618885]

彩信头：

由一系列的域组成，包括PDU类型，接受方，发送方，发送时间等等。Header域中的项分为可选 项和必选项，并且在编码MM头域时，X-Mms-Message-Type，X-Mms-Transaction-ID 和 X-Mms-MMS-Version必须位于MM头的最开始，而且要严格按照所列顺序，Content-Type头域必须在MMS头域的最后，其后为消息 体，其它域的顺序可以随意安排。

彩信体：

是多个不同类型的多媒体对象组成的，每个对象占据一个部分——Part(参见RFC2387标准)，根据各个部分是否有序，消息的组装方式分为：

.application/vnd.wap.multipart.mixed ：所有的消息内容混合在一起，没有时间上的顺序，终端同一时间一次就把所有的消息内容显示出来。

.application/vnd.wap.multipart.related ：消息内容的各部分之间有一定的关系，该关系可能是显示时间上的先后，或者显示位置的不同，等等。这使得消息能够像“幻灯片”一样的显示。

消息体的内容组成

在application/vnd.wap.multipart.mixed类型的PDU中，仅包含有组成MM的所有多媒体内容，而在application/vnd.wap.multipart.related类型的PDU中还会包括Presentation —— 即消息内容的显示控制部分，该部分使用SMIL标记语言编写，用来描述MM中各部分的播放次序，显示/播放时间，结束时间以及在屏幕中 的 显示位置，等控制信息 。

通常， Presentation部分是消息体的第一个part，若不是则必须使用start 字段指出其所在位置， Presentation部分并不会被显示出来，而仅仅是让终端根据它获取一些控制信息，这些信息决定了其它内容的显示大小、先后顺序、位置等 。

最后 采用 MIME标准（ Multipurpose Internet Mail Extensions - 多用途互联网邮件扩展 ）将 完整的MM（包括： SMIL 、 文本、图像、声音、视频等 各个独立部分） 打包封装在一起，并发送。 MIME标准定义在RFC2045 、RFC2046 、RFC2047 、RFC2048 、RFC2049 等多个RFC标准之中。

MM的二进制编码封装

大多数情况下，MM都基于WAP协议进行传输，它将MMS PDU被封装在WSP/PDU之中 作为WSP的消息体进行传输，并采用WAP/WSP协议作为传输内容的二进制编码（binary encoding）机制，进行消息的封装（Encapsulation）。

在OMA-TS-MMS-ENC-V1_3-20080128-C.pdf文档所在规范中，详细定义了每个PDU所涉及的Header域和值，以及为它们分配的二进制码的一一对应关系。采用此二进制编码规范，节约了无线领域的带宽资源，并最优化其在空中传播的数据量。

具体对应关系请参阅相关文档。

MMS业务模型：

Sending,



Example MMSM Transaction Flow – Sending

在MMS Client向MMS Relay提交的PDU（Protocol Data Unit）中，包含有能唯一标识其自身的ID字段，该字段使得请求/回应（req/resp）被对应关联起来。

当 MMS Relay服务器 收到一个M-Send.req PDU时，它会回应一个M-Send.conf数据包，其中包含有请求处理结果的状态代码。如果MMS Relay能够成功处理该请求，那状态代码将为'OK'，并会返回一个message-ID作为MM的唯一标识。

Retrieval



Example MMSM Transaction Flow – Immediate Retrieval

M-Retrieve业务是MMS Client发送给 MMS Relay服务器以收取MM的请求，该请求的PDU传输在WSP/HTTP协议之上。取决于收取方式（即时收取or延时收取）的不同，在MMS-Relay服务器和MMS Client之间需要一个确认环节。

Delay retrieval



Example MMS Transaction Flow – Delayed Retrieval