杨学华1, 2 李炜1, 2

(1 北京邮电大学网络与交换技术国家重点实验室北京100876，

2. 东信北邮信息技术有限公司北京 100191)

摘要：传情酷秀业务（3G Cool Show service）是3G网络中可视通话过程中的一种新兴个性化视频业务。如何处理好传情酷秀业务与多媒体彩铃业务(Multimedia Ring Back Tone)的关系，成为传情酷秀业务发展的关键。本文首先介绍了传情酷秀业务在3G R4网络中的实现方案，并分析了与多媒体彩铃业务冲突的原因，然后重点讨论了解决冲突的几种方法。

关键字 ：传情酷秀 多媒体彩铃 业务冲突 R4

Study of the cooperation between the 3G Cool Show service and the MRBT service in 3GPP R4 network

Yang Xuehua1, 2 Li Wei1, 2

(1. State Key Laboratory of Networking and Switching Technology, Beijing University of Posts and Telecommunications, Beijing 100876

2. EBUPT Information Technology Co. Ltd., Beijing 100191)

【Abstract】The 3G Cool Show service is a kind of personalized video service. It works in the process of video calls. Handling the interaction of the 3G Cool Show service and the Multimedia Ring Back Tone service (MRBT) well is very important. This paper introduces what the 3G Cool Show service is in 3G R4 network, analyzes the conflicts between the two services, and provides several solutions of the conflicts. At last, the solutions are compared and evaluated comprehensively.

【Key words】3G Cool Show service, MRBT, service conflicts, R4

 

引言

 

      在3G增值业务的建设中，各家运营商为了体现出自身业务的差异性，把发展个性化视频业务，培养用户的视频使用习惯，放到了推动3G业务发展的战略地位。

      多媒体彩铃业务，作为最典型的个性化视频业务，较好地满足了用户可视通话建立前的个性化需求。而传情酷秀业务，满足了用户可视通话过程中的个性化。传情酷秀业务目前向主叫开放，用户可以事先通过管理网站设置好卡通形象或视频动画，在可视通话过程中通过按键的方式控制其显示在被叫的手机终端上，以达到通话过程中灵活展现自己的形象或心情的目的。如何处理好传情酷秀业务与多媒体彩铃业务的关系，已经成为传情酷秀业务发展推广的关键问题。

 

1.传情酷秀业务的现状

 

      在本论文中，我们所讨论的传情酷秀业务是在TD-SCDMA网络的核心网，即3G R4网络中实现的。目前，浙江省、广东省、山西省传情酷秀平台均是基于3G R4网络进行建设的。

 

1.1.UMTS R4网络

 

      3G R4网络作为2G 核心网向全IP 网络过渡的一个版本，相对于R99版本，其核心网电路域变化较大，将原来的MSC拆分为MSC Server（移动端局软交换机）和MGW（媒体网关），实现了控制与承载的分离。MSC Server是UMTS移动通信系统中电路交换网向分组交换方式演进的核心设备，它独立于底层承载协议，主要完成呼叫控制、媒体网关接入控制、移动性管理、资源分配、协议处理、路由、认证、计费等功能。除了支持原有的MAP，CAP等协议外，还支持R4特有的H.248和BICC协议。

 

1.2.传情酷秀业务实现方案

 

      在中国移动的引导下，由东信北邮承建的传情酷秀平台已经在浙江、广东等省落地。为了实现用户的个性化服务，给主被叫播放视频文件，传情酷秀业务采用媒体跨接的方式，即主、被叫的媒体都与传情酷秀平台进行媒体链接，由业务平台控制主被叫媒体间的互通。这样，对于多媒体彩铃用户，其通话的信令与媒体均经过传情酷秀平台和多媒体彩铃平台[1]的两次跨接。

      以浙江省的传情酷秀业务为例，用户拨打“17274 +被叫号码”的方式将呼叫触发至传情酷秀平台。其信令流程如图1所示：

图1 目前传情酷秀与多媒体彩铃叠加信令流程

      关键信令说明:

      5) 传情酷秀平台附属的MSC SERVER收到IAM，根据被叫号码查询被叫HLR，发现携带了多媒体彩铃业务签约信息(SS_CODE值254[2])，在被叫号码前加上17254前缀后将IAM发往MRBT平台。

      9-20)媒体信息协商。通过13和14，完成了多媒体彩铃平台与被叫侧之间的媒体承载控制信息的交换；通过15、16、17、18，传情酷秀平台被叫侧与多媒体彩铃平台主叫侧完成媒体承载控制信息的交换；通过19、20，主叫用户与传情酷秀平台间完成了媒体承载控制信息的交换。

      22-25)将被叫的ACM消息依次发送至MRBT平台、传情酷秀附性MSC Server、传情酷秀平台、主叫MSC Server。多媒体彩铃平台向主叫侧(即传情酷秀平台被叫侧)发起H.245协商；传情酷秀平台收到被叫的ACM，但并未发现被叫是多媒体彩铃用户，未对被叫侧（即多媒体彩铃平台主叫侧）发起H.245协商。此将导致多媒体彩铃平台发起的H.245协商失败。

 

2.传情酷秀与多媒体彩铃业务冲突

 

2.1.冲突原因

 

      从信令流程来看，如果被叫签约了MRBT业务，尽管呼叫可触发到MRBT平台，但是MRBT平台在与主叫侧进行H.245协商时并不能成功。对MRBT平台而言，此时的主叫用户已经成了传情酷秀平台。交换机在收到ACM后，尽管检测到被叫是签约了MRBT业务，

      但并不能向传情酷秀平台提前下发Connect命令以打开媒体通道。因此，MRBT平台单侧发起的H.245协商并不能成功，传情酷秀平台与MRBT平台之间的媒体链接建立不起来。此时主叫用户听到的仍然是“嘟嘟嘟……”的回铃音。只有当收到被叫的摘机ANM消息后，传情酷秀平台与MRBT平台分别向主被叫侧发起H.245协商，此时才能协商成功。协商成功后，两平台分别对主被叫侧的媒体进行桥接操作，完成主被叫媒体的交换，使主被叫用户达到通话的目的。

 

2.2.如何兼容

 

      可见，传情酷秀业务用户丧失MRBT业务体验能力的关键在于，传情酷秀平台不知道被叫用户签约了MRBT业务，未在被叫用户摘机前提前进行H.245协商。目前，多媒体彩铃业务已经在四川搭建全国统一的业务平台，并在全国范围内推出商用多时。要达到传情酷秀、MRBT两业务的兼容，需要传情酷秀平台解决如下两个问题：

      1、传情酷秀平台在被叫摘机前成功打通主叫侧的3G-324M通道，即成功进行H.245协商；

      2、传情酷秀平台获取被叫是否触发了MRBT业务；

 

3.提前打开主叫3G-324M逻辑通道

 

      在正常情况下，主叫终端是在收到被叫ANM摘机消息时向被叫侧发起H.245媒体协商。当媒体链接的双方均发起H.245协商时，才能协商成功，建立3G-324M逻辑通道。

      在多媒体彩铃业务中，主叫侧3G-324M通道能够提前打开的原因是，各主叫终端所在的交换机做了改造。当主叫发起呼叫时，由主叫所在交换机查询被叫的HLR[3] [4]。如发现被叫签约了多媒体彩铃业务，在将呼叫路由至多媒体彩铃平台的同时，在收到多媒体彩铃平台回送的ACM消息后，由主叫交换机提前向终端自动发起connect操作，向被叫侧发起H.245协商。

为了触发打开主叫的3G-324M逻辑通道，这里提出两种方式，并对两种方式的优缺点进行了比较，如表1所示：

      一种方式是通过改造各端局交换机使其收到某特定DTMF消息时，由主叫交换提前向主叫下发Connect命令；

      另一种方式是由传情酷秀平台在被叫摘机前提前向主叫下发ANM消息。

表1 提前打开主叫3G-324M逻辑通道的两种方法比较

 

      不管是端局改造，还是业务平台提前下发ANM应答的方式，都将引起用户手机终端提前进行通话计时，不过此问题在多媒体彩铃业务建设时已经解决。只需在主叫侧H.245逻辑

      通道打开成功时，向主叫交换机发送DTMF(C)，既可指示终端停止计时。在被叫终端摘机后，再向主叫交换机发送DTMF(D)，指示终端开始计时[1]。

      对比两种方式的优缺点，通过传情酷秀平台提前下发ANM的方式具有较低的风险系数，明显优于对交换端局的改造方案。

 

4.感知被叫已触发多媒体彩铃业务

 

      为了感知被叫已触发MRBT业务，以下提出两种方式进行解决：提前尝试H.245协商，或根据号码查询被叫是否触发了多媒体彩铃。根据号码查询被叫是否触发了多媒体彩铃，又包括查询HLR与查询MRBT平台两种基本方案。

 

4.1.提前尝试H.245协商

 

      在传情酷秀平台收到被叫侧的ACM（消息24）之后，在将ACM转发给主叫的同时向被叫侧发起H.245协商。如果被叫用户是多媒体彩铃用户，则MRBT平台也会在此时向主叫侧（即传情酷秀平台）发起H.245协商。

       传情酷秀平台收到被叫侧H.245协商成功的结果，即认为被叫是MRBT用户且本次呼叫已经触发了MRBT业务。此种情况，平台可提前向主叫下发ANM，并向主叫发起H.245协商。待主被叫H.245均成功后，传情酷秀平台再对主被叫侧的媒体进行桥接操作，此时主叫将可看到被叫用户所设置的多媒体彩铃。

      传情酷秀平台收到被叫侧H.245协商失败的结果，表示被叫不是MRBT用户，或者未触发MRBT业务。此时传情酷秀平台不向主叫用户提前下发ANM，呼叫流程仍按图1中原流程继续。当传情酷秀平台收到被叫摘机ANM后，再向主被叫发起H.245协商。

      因此，对于未触发多媒体彩铃的用户，传情酷秀平台需要向被叫侧发起两次H.245协商操作，而且第一次是失败的。这需要媒体板卡俱备多次协商的能力。

      对于已触发多媒体彩铃的用户，由传情酷秀平台在被叫侧H.245协商成功后，再向主侧发起H.245的协商，此两次协商串行进行。根据TD-SCDMA现网的经验，并行协商时间约1~2秒，此串行协商时间预计将达到3秒左右。

 

4.2.根据号码查询是否触发了多媒体彩铃

 

      在多媒体彩铃业务与呼转类业务叠加规范中，用户A拨打用户B，发生前转至用户C的情况：当被叫用户B设置了无条件前转到C时，主叫A听到C设置的多媒体铃音；当B无应答前转到C时，A听到B设置的多媒体铃音直至C用户接听；当B不可及、遇忙前转时，A无法听到B和C的多媒体铃音[5]。在中国移动的BICC技术规范中，对呼叫改发原因值做出了如下定义：0x0未知，0x1用户忙， 0x2无应答，0x3无条件，0x4指示期间改向，0x5改向立即响应，0x6移动用户不可及，0x7-0xf尚未定义[6]。

      为了根据号码获取传情酷秀被叫侧是否触发了多媒体彩铃，需要传情酷秀平台获取被叫侧的呼转信息。

在BICC协议中，呼转信息可通过ACM消息或是CPG消息携带[7]。消息的Call diversion information参数和Refirection Number参数分别提示呼转的原因与呼转号码C。如图2所示：

 

                                                                           Call diversion  information : 0x9

                                                                           Redirection  Number : 13403007020

 

图2 BICC消息中呼转参数示例

     

      根据多媒体彩铃业务与呼转类业务的叠加规则，可以得出结论：在未发生呼转的情况下，需要查询B是否是多媒体彩铃用户；发生无条件呼转至C时，可以查询C是否是多媒体彩铃用户；发生不可及、遇忙呼转时，被叫的多媒体彩铃不会触发。

      查询被叫HLR签约信息方式，传情酷秀平台与多媒体彩铃平台间建立内部通信机制方式，均是查询某用户是否签约多媒体彩铃的方法。

      如果查询得用户是多媒体彩铃用户，此时需要提前向主叫下发ANM，并向主、被叫发起H.245协商。其信令流程如图3（已省略ACM前面的消息）所示：

图3 提前下发ANM与H.245协商

      如果查询得用户不是多媒体彩铃用户，或者根本不符合多媒体彩铃触发条件(无需查询)，则按图1中的原信令流程继续。

 

4.2.1.通过HLR查询MRBT签约状态

 

      多媒体彩铃业务是采用SS_CODE签约的方式，此签约数据存放于被叫用户的HLR。考虑到被叫HLR可能分布在不同省分，通过传情酷秀业务平台查询HLR将涉及到对各HLR的改造，成本非常大。如果改造与传情酷秀直连的MSC Server，通过MSC Server代理查询的方式，将可以避免对各HLR的改造工作。

图4 MSC Server代理查询HLR

      通过MSC Server代理查询HLR的信令流程如图4所示。在查询结果SRI_ACK中将带有被叫的SS_CODE签约信息[4]。如果SS_CODE中包含了值254，表示用户是多媒体彩铃用户。

 

4.2.2.与MRBT平台建立查询接口

 

      在传情酷秀平台与多媒体彩铃平台间建立内部通信机制，如SOCKET，Web Service等均可。目前，多媒体彩铃平台为全国统一建设，因此也只涉及到对一个MRBT业务后台的改造。

图5 传情酷秀平台向MRBT平台发起SOAP查询

     

      以Web Service为例，如图5所示，传情酷秀平台将Web Service请求发送至多媒体彩铃后台，由多媒体彩铃后台对请求鉴权后查询数据库，返回用户的多媒体彩铃注册信息。

 

4.3.三种方法的比较

 

      如表2所示，对比4.1与4.2中提到的三种方案。为了感知被叫用户是否触发多媒体彩铃业务，三种方案各有优缺点：

表2 感知被叫MRBT的三种方法比较

 

5.结束语

 

      在3G增值业务百花绽放的今天，一个新业务的建设在契合用户新需求的同时，与已有主流业务的兼容问题也成了新业务推广的关键。传情酷秀业务，与多媒体彩铃业务、彩像业务，一并提供了可视通话各个阶段的个性化视频能力。多媒体彩铃已经得到广大用户的认可，

      传情酷秀与彩像业务当前均处于业务建设中，处理好各业务的叠加问题，是新业务从建设至发展、成熟的必经之路。本文粗略地讨论了传情酷秀业务与多媒体彩铃业务的叠加问题，希望能起到抛砖引玉的作用，意在推动传情酷秀业务的进一步发展。

 

参考文献

[1]杨军. 3G网络中多媒体彩铃的设计与实现. 北京. 北京邮电大学硕士学位论文. 2006年

[2]于金杨,李亮亮. 彩铃平台接入R4核心网的改造方案研究. 科技资讯. 2008年05期. 2008年05月: 142-143

[3]沈奇威,廖建新,王纯,蔡斌. 多媒体回铃音业务研究. 计算机工程. 32卷(18期) . 2006年09月: 231-233+236

[4]Zhou Junfeng, Wang Jing. Liao Jianxin. The design and implementation of mobile intelligent location services. Proceeding of the International Conference on Telecommunications. v 1. 2002: 523-527

[5]中国移动通信企业标准. 多媒体彩铃业务总体技术要求v2.0.0. 2008年11月25日: 63

[6]中国移动通信企业标准. BICC技术规范 PART 2：BICC的消息、参数的基本功能和格式v2.0. 2005年5月: 56

[7]王文林,廖建新,沈奇威. 彩铃业务与呼叫转移补充业务间的冲突解决. 电信工程技术与标准化. 2004年08期. 2004年08月: 80-85

 

————————————————————

*基金项目：国家杰出青年科学基金（No. 60525110）；国家973计划项目（No.2007CB307100，2007CB307103）；国家自然科学基金（No. 60902051）；中央高校基本科研业务费专项资金（BUPT2009RC0505）；电子信息产业发展基金项目（基于3G的移动业务应用系统）