点对点多媒体消息业务网间互通协议分析

来源：泰尔网作者：出处：巧巧读书 2007-07-01 进入讨论组

黄颖王坤

摘要

随着电信技术的不断发展，具有良好表现能力的信息服务——多媒体消息业务进入到人们的生活中，同时也为运营商间业务的互通增加了新的课题。本文主要从多媒体消息业务的网间结构入手，对多媒体消息业务网间互通协议进行了分析。

1、引言

多媒体消息业务（MMS）可以支持多媒体功能，借助高速传输技术传送视频片段、图片、声音和文字多媒体信息，不仅可以在手机之间进行多媒体传输，而且可以在手机和电脑之间传输。

随着多媒体消息业务的不断发展，不同运营商网间的业务互通也越来越被提到日程上来，业务能否互联互通是移动多媒体产业发展壮大的关键。业务的互联互通能够为广大的用户使用业务提供方便，能够进一步扩大用户群，使多媒体消息业务逐步成为移动增值业务新的增长点。

网间多媒体消息业务互通采用的是利用互联网关（IWGW）的方式，网间IWGW互联可以由两个运营商的IWGW直接连接，也可以经过第三方互联网关转接。IWGW之间采用基于TCP/IP的专线连接方式或互联网连接。多媒体消息互通结构如图1、图2所示。

图1 点对点多媒体消息业务网间互联网络结构示意图

图2 点对点多媒体消息业务网间互联网络结构示意图

2、承载协议分析

不同运营商的多媒体消息业务的互通首先要解决互通协议问题，即多媒体消息互联网关之间采用标准的统一的互通协议。目前，有SMTP和HTTP+SOAP两个协议可作为互通网关之间接口承载协议。

相对于HTTP+SOAP的方式，SMTP协议是使用的比较成熟的协议。SMTP（简单邮件传输协议）是3GPP多媒体消息规范中业务互通接口MM4使用的承载协议，目前在网内多媒体消息业务系统的部署中都使用了该接口承载协议。但作为承载协议，SMTP协议效率比较低，它完成一个消息流程需要多个信令过程：包含HELLO，NOOP，RSET，QUIT。MAILFROM，RCPTTO，DATA等信令。

为了解决接口效率低的问题，目前HTTP+SOAP方式的承载协议得到了广泛的青睐，它的信令过程比较简单，完成一个消息流程就只有一个数据请求和响应，没有SMTP协议中间多次的信令来回。

但考虑到协议使用的成熟度、广泛性及网间业务量，在点对点多媒体消息业务互通网关间的承载协议建议采用3GPP规定的MM4接口使用的SMTP协议。HTTP+SOAP协议的方式可以在网内试用，在协议成熟后，且网间业务量达到一定程度后可以考虑采用HTTP+SOAP的方式替代SMTP的方式。在现阶段互通采用SMTP作为承载协议的情况下，为了提高承载协议的效率，建议使用长连接的方式建立承载，即指在一次SMTP连接中，SMTP命令DATA可以发送多次。SMTP协议本身是支持这种行为的：在发送完一次消息后，不关闭该连接，当一方要求正常关闭该连接时，发送QUIT消息；为了防止连接超时，客户端可以定期使用SMTP命令NOOP刷新及检测连接的有效性。

下面阐述的互联网关间的消息与承载协议无关，无论采用哪种承载方式都应该提供以下必要的业务消息，保证网间业务的互通，对于不同的承载协议只是在建立连接及消息的字段映射方面存在差别。

3、业务协议分析

3.1协议流程

互联网关间业务消息主要是依据3GPP的MM4接口定义的，互联网关间发送的消息类型包括：

（1）MM4_forward.REQ路由前转请求；

（2）MM4_forward.RES路由前转响应；

（3）MM4_delivery_reportREQ路由前转递送报告请求；

（4）MM4_delivery_reportRES路由前转递送报告响应；

（5）MM4_read_reply.REQ路由前转阅读报告请求；

（6）MM4_read_reply.RES路由前转阅读报告响应。

消息流程如图3所示。

图3 消息流程示意图

多媒体消息的始发方互联网关会使用一个包含多媒体消息业务控制信息和多媒体消息内容的MM4_forward.REQ消息，将网内多媒体消息中心转发过来的多媒体消息路由转发至接收方互联网关。发送方互联网关如果请求了响应MM4_forward.RES，接收方互联网关将在收到MM4_forward.REQ消息后响应一个提供请求状态的MM4_forward.RES消息给发送方互联网关。

接收方互联网关将MM4_forward.REQ转换成网内的消息进一步转发给接收用户归属的多媒体消息中心（MMSC），接收用户归属的多媒体消息中心根据系统及接收用户情况返回一个递送报告给发送方，首先转发至接收方互联网关，接收方互联网关在收到递送报告后，转换成网间的消息MM4_delivery_report.REQ转发给多媒体消息发送方互联网关，接收方互联网关如果请求了响应MM4_delivery_report.RES，发送方互联网关将在收到MM4_delivery_report.REQ消息后响应一个提供请求状态的MM4_delivery_report.RES消息给接收方互联网关。

如果发送用户请求了阅读报告，且接收用户同意发送阅读报告，那么接收用户提取多媒体消息后会向接收用户归属的多媒体消息中心发送阅读报告请求：同意向发送用户返回阅读报告。接收用户归属的多媒体消息中心向接收方互联网关转发多媒体消息阅读报告，接收方互联网关在收到阅读报告后，转换成网间的消息MM4_read_reply_report.REQ转发给发送方互联网关，接收方互联网关如果请求了响应MM4_read_reply_report.RES消息，发送方互联网关将在收到MM4_read_reply_report.REQ消息后响应一个提供请求状态的MM4_read_reply_report.RES消息给接收方互联网关。

3.2协议中关键问题分析

多媒体消息业务的开展各国有各国的具体运营情况，因此根据国内现网运营及网络结构情况需要对现有的MM4的接口协议做相应地调整以适应现网业务的互通。

（1）MessageID如何规定

MessageID在协议中用来标识一个消息，把一个消息及其响应联系在一起，该标识必须惟一。由于网间业务互通，各个运营商在网内的消息标识在网内虽然是惟一的，但可能在网间出现重复（如果两个运营商的编码方式类似），因此在网间业务互通过程中要对MessageID的编码方案进行标准化，以确保MessageID的惟一性。

目前，网内消息MessageID是在多媒体消息中心产生，编码方式为：

●日期+源多媒体消息中心代码+序列号；

●日期：月日时分秒占10位；

●多媒体消息中心代码：业务代码（1位）+区号（3位）+省内序号（2位）；

●序列号：占5位，顺序增加，步长为1，循环使用。

MessageID的编码总共是21位。

目前，很多厂家是多媒体消息中心与网关合设，MessageID的编码方式还涉及到设备本身下层的程序处理，为了使网间业务互通对现网的设备影响最小，建议不改变MessageID的位长21位，编码方案采用类似的原则，建议采用以下编码方式：

●日期+源互联网关代码+序列号；

●日期：月日时分秒占10位；

●源互联网关代码：运营商代码（1位）+区号（3位）+网关序号（2位）；

●序列号：占5位，顺序增加，步长为1，循环使用。

（2）确定递送报告各个状态的含义

在网间业务互通中，递送报告的状态非常重要，因为不同运营商间的结算要依靠递送报告的状态。在3GPP的协议规范中，没有对递送报告的状态含义做详细的规定：根据各个厂家开发设备的情况，可扩展相应的规定，具体的状态含义参见表1。

表1 递送报告状态含义

（3）是否区分固定和移动MMS-address（多媒体消息业务地址）

在协议中有个字段要带上多个媒体消息业务系统地址，该地址表示消息层多媒体消息业务的用户地址，3GPP的规范中只考虑了移动网的情况。目前在国内，固定网也在发展多媒体消息业务，因此需要考虑固定网的情况。

在3GPP的规范中规定的MMS-address格式为：MMS-address=（“+”E.164“/TYPE=PLMN”）。

PLMN含义是公众陆地移动电话网，在固定网中应当使用PSTN公共交换电话网络，但考虑到现网设备都是按照3GPP的规范开发的，因此这里建议还是采用PLMN，主要通过E.164号码来区分固定网和移动网。

在固定网中，电话号码前面是没有“+”的，因此针对固定网的情况，MMS-address的格式应当为：MMS-address=（E.164“/TYPE=PLMN”）。

移动用户E.164号码格式为：“861XXH0H1H2H3ABCD”。

固定用户E.164号码格式暂建议定为：“1060（长途区号）（固定本地电话网用户号码）”，在SP号码调整或运营商协商之后，固定用户E.164号码格式为“0（长途区号）（固定本地电话网用户号码）”。

4、结束语

点对点多媒体消息业务互通涉及多方面的问题，本文仅从协议的角度对多媒体消息业务互通进行了分析，包括承载协议的选择和业务协议的改进等方面。随着后续设备试验和测试的开展，多媒体网间互通协议可能会暴露出新的问题，需要通过不断地改进来进一步完善互通协议。随着运营商间多媒体消息业务的逐步互联互通，多媒体消息业务将越来越丰富，多媒体业务必将会像短消息业务一样成为人们日常交流的新的媒体手段。（后卫编辑）

保留地址 http://www.qqread.com/net-protocol/z319451.html