0 前言
目前,Kakao Talk、WhatsAPP、iMessage等互联网应用的广泛使用,令运营商的短信收入急剧下降。微软主推的Skype、苹果公司提供的FaceTime等应用也对运营商的语音收入带来严重威胁,而谷歌和美国运营商Sprint的合作,让用户可基于电话号码使用谷歌的VoIP服务,则进一步预示了传统CS电话业务的衰退。为了应对互联网业务的挑战,GSMA积极推进富通信套件(RCS)标准的制定和产业化活动。
RCS是一种基于手机地址本的,集语音、即时消息、文件传输、内容共享、呈现、位置服务等多种通信方式于一体的融合通信服务。但RCS不仅仅局限于上述所列功能,它的版本仍在更新中,后续版本将继续补充其他新功能。同时RCS也进行了API开放的相关研究,包括网络地址本、即时消息、文件传输等能力都将开放给第三方,以便基于RCS提供更多、更丰富的业务。因而,RCS是运营商提升竞争力,提高单个用户ARPU值的重要途径。
本文将从标准规范、开放API、产业情况等方面介绍RCS的情况,并对RCS的网络部署、可能存在的问题提出相关建议。
1 RCS标准规范
RCS从2007年开始成立工作组,截至目前,按照时间顺序其功能规范的版本经历了RCS 1/2/3/4/RCS-e/5/5.1共7个阶段。其中RCS-e是RCS 2的简化版,是一个较为特殊的版本,其产生的主要原因是在前期推动RCS商用时,发现功能过多导致终端开发速度慢、网络难以迅速适应等问题。因而欧洲五大运营商Deutsche Telekom、Orange-FT、Telecom Italia、Telefonica、Vodafone 从2011 年初开始启动RCS-e 的研究,对RCS 2的功能进行简化。但是从RCS 5开始,RCS-e和RCS 4又进行了整合,统一于一个版本,不再另行发展。
RCS 1发布于2008年12月,该版本定义了通话中内容共享、通话或消息聊天时进行文件传输、增强型消息、社会呈现、服务能力信息、高可用性、黑名单、网络地址簿等基本业务。
RCS 2发布于2009年6月,在业务功能上较RCS 1进行了增强,主要体现在:支持用户通过宽带接入的方式使用RCS业务,但此时用户可以发送短信,不可接收短信;支持使用多终端;支持基于运营商管理的网络地址簿及对用户进行自动配置。RCS 2的亮点在于支持多终端,用户不仅可以在手机上使用RCS,还可以在PC上使用,从而拓展了RCS的使用范围。
RCS 3发布于2009年底,对RCS 2的功能进行了增强:宽带接入的设备作为主要设备;支持非通话期间的内容共享、支持把共享内容传递给传统终端;增强的呈现信息,包括地理位置、URL标签等;增强的消息,允许宽带接入的终端发送和接收彩信/短信;网络增值服务;对用户透明的开户和配置过程。
RCS 4发布于2010年底,最重要的变化是提出支持LTE,另外也提出支持大文本消息、与短信的后向兼容、视频共享的暂停和恢复等功能。RCS 4引入LTE,契合了LTE迅速发展的潮流,也使RCS可以得到更多运营商的支持。
RCS-e 1.1版本发布于2011年4月,最终版本v1.2.2发布于2012年7月。它是RCS 2的简化版本,去掉了社会呈现、心情短语等功能。目前欧洲运营商向用户所提供的RCS业务,均是基于此版本。RCS-e的功能如图 1所示[1],图中的左边部分是RCS-e不支持的功能。
RCS 5.0发布于2012年4月,它基于RCS 1~4和RCS-e 1.2,包括了RCS 1~4和RCS-e 1.2的所有功能,融合了欧洲和北美的RCS标准。相比之前的各版本,RCS 5.0扩展了1对1聊天、群组聊天、文件传输的功能,新增了IP Video Call、HD Voice Call、地址位置交换,支持OMA CPM 和OMA SIMPLE IM。RCS 5.0可以称作是RCS的集大成者,不仅包括了之前各RCS版本的功能,还新增了许多功能,是一个十分受人关注的版本。
RCS 5.1发布于2012年8月,随后几个月还仍然在进行修订,预计2013年上半年会最终定稿。相比RCS 5.0,RCS 5.1主要是增加文件的存储转发、静态群组消息的存储转发、在地图上显示位置等功能。
总的来说,从RCS 1到RCS 5.1,标准规范所定义的功能越来越丰富,有效地扩展了运营商的基本电信业务范畴,有利于运营商基于高速的网络环境向用户提供更多业务。
同时,从上述标准的进展可以看出,GSMA近几年一直致力于推进RCS的发展,标准更新速度非常之快。在OTT应用对运营商传统业务的大量侵蚀情况下,RCS被认为是运营商应对OTT竞争的强有力武器,备受全球运营商、设备商、终端厂家的关注,因而GSMA加大对RCS标准制定的投入也在情理之中。下面分别从用户、运营商、第三方开发者的角度介绍RCS的优势。
对于用户而言,相比OTT等互联网应用,RCS具有以下优势。
a) 集成到手机中,用户无需安装,直接使用。RCS的使用方式类似于短信,例如,十多年前的手机可能并不支持短信,当出现短信这个新业务后,短信功能被内置于手机中,用户直接使用即可。需要注意的是,目前用户所使用的手机绝大部分未内置RCS功能,对于这些手机,可以下载安装RCS客户端。
b) 全球运营商均遵循GSMA标准,可快速实现66亿多移动用户的互通。还以短信为例,短信是所有运营商均支持的业务,用户可以给任何一个移动手机用户发送短信,而不用考虑接收方是否支持短信功能。
c) 运营商级的业务,可以保证良好的服务质量。相比OTT应用提供的IP语音、即时消息等功能,RCS是运营商的自营业务,运营商可以在业务质量方面提供有效保证。
对于运营商,RCS具有以下优点。
a) 业务种类丰富,可以提升运营商在用户中的形象。
b) 开放API,使运营商可提供特色业务或让第三方开发新业务。
c) 终端产业链共同遵循GMSA标准,减少定制终端的工作量。
d) 全球统一品牌,识别度高,可迅速进行推广。
对于第三方开发者而言,RCS的API在全球统一,基于RCS开发的新应用,一旦在某个运营商网络中开发成功,则在全球所有运营商网络中均可推广。
2 RCS API
RCS API的目的在于开放网络能力,便于开发新的应用,让RCS业务延伸到新的用户群体,开创新的盈利机会和商业模式。RCS API包括的内容有授权框架、一般通知、网络地址簿、能力发现、消息、文件传输、内容共享。
《RCS-e Network API Detailed Requirements 1.0》与《RCS API Detailed Requirements 1.1》均发布于2011年10月,其中1.0版本主要针对RCS-e,而1.1版本则主要针对RCS 1/2/3。《RCS Network API Detailed Requirements 2.0》发布于2012年5月,融合了1.0和1.1版本,解决了同时存在多个API规范的混乱局面。
RCS API 2.1发布于2012年7月,对RCS API 2.0中的一些错误进行了修订。2.2版本发布于2012年11月,添加了长时间存活群组的API、VoIP和Video Over IP的API。目前GSMA正在基于RCS 5.1标准规范制定RCS API的2.3版本,截至2013年2月底,2.3版本的API已完成初稿,正在征求各运营商、设备商、终端厂家的意见。
需要注意的是,在研究RCS API之前,GSMA于2008年曾提出了One API项目,这个项目与RCS API有许多相同之处,也是关注运营商应该开放哪些网络能力以及如何开放这些能力,以吸引Web开发者。One API与RCS API的工作流程有许多相同的地方,均是提出相应的API需求,然后提交给OMA,由OMA挑选确定后,形成一个新的规范或加入到对应的已有API规范中。
One API项目提出了Messaging(消息),Payment(支付)和Location(地理位置)等API的需求,并提交给OMA进行标准化。2010年,One API项目还在加拿大3家运营商的网络中进行了开放的试验,该试验运行2年,共有超过400个注册开发者,创造的价值超过1 800万加元。从这个应用案例可以看出,One API在网络能力开放方面,做了一些十分有意义的工作。
2012年以后,由于RCS API逐渐受到大家的重视,一些工作与One API有重复之处,而One API本身的标准化工作也逐渐减少,因而2013年1月底,GSMA的产品与服务管理委员会(PSMC)决定关闭One API,相关标准化工作转交给其他工作组。
在One API和RCS API之前,对于开放电信网络能力方面的研究,曾经出现过基于CORBA的Parlay API和基于SOAP的Parlay X API,但均由于过于复杂而未获得大范围推广。而One API和RCS API则是基于目前流行的REST风格进行描述和设计,可以让第三方开发者使用HTTP调用电信能力,十分简单易行。因而,虽然One API已经停止工作,但是在2013年年初的GSMA会议上,专家们提出,IMS网络正在逐渐得到部署,其能力开放的研究还未完成,需要成立专门的工作组进行研究,以弥补关闭One API项目带来的缺陷。由于RCS基于IMS,RCS API可以看成是IMS API(即IMS网络能力的开放),因而专家们建议即将成立的IMS API工作组可重点关注RCS API。
综上所述,RCS API的工作在未来一段时间仍是运营商关注的焦点,其与IMS API密切相关,可以这样认为,RCS API的开放即相当于IMS网络能力的开放。
3 产业情况
为了保证RCS业务的全球互通性以及给用户以统一的感知,GSMA提出了基于RCS-e的“Joyn”品牌。“Joyn”分为对终端的认证和对运营商网络的认证。对于用户而言,所有获得“Joyn”品牌使用权的终端或运营商网络均具备和其他“Joyn”终端或网络进行互通的能力。通过这种方式,RCS可以在全球范围内快速获得用户的认可,并可保证用户所能使用的业务是一致的。
当前,通过“Joyn”认证的终端有10多款,既包括内置RCS-e的终端,也包括RCS-e软终端;通过“Joyn”认证的网络则有西班牙沃达丰、德国沃达丰、西班牙移动之星等6个网络。
在2012年,欧洲、美国、韩国的一些运营商已向用户正式提供“Joyn”服务。其中,西班牙3家处于领先位置的移动网络运营商Movistar、Orange和Vodafone在2012年11月开始提供“Joyn”业务。美国的MetroPCS同期亦开始向用户提供基于LTE的RCS业务。而韩国的SK、KT和LG Uplus 则在2012年12月开始向用户提供RCS业务。
除了上述已经正式对外宣布提供“Joyn”服务的运营商外,法国与意大利的运营商预计2013年上半年也将会向用户提供RCS业务。基于目前RCS的发展趋势,预计未来2~3年内,将是RCS快速发展的时期。
关于在我国如何开展RCS业务,建议国内运营商参考西班牙、韩国的方式,联合起来共同推广,以形成规模优势。RCS是运营商未来的基本电信业务,其目标是应对OTT的竞争,因而在RCS的应用方面,运营商间并不是竞争关系,而是相互支撑、相互合作,共同扩大市场规模的关系。对于国内运营商间的RCS互通,可以考虑运营商各自设立网关,通过网关实现RCS的互通,具体内容可参考《RCS Interworking Guidelines》,该文档在GSMA中对应的文档编号是IR.90。另外,鉴于目前国内用户所使用的手机均未内置RCS功能,因而在推广初期,可以建议用户下载安装RCS客户端,而对于未来的入网手机,则要求其必须支持RCS功能。通过这种方式,可以有效地扩大RCS用户规模。
4 RCS部署建议
随着GSMA持续推进RCS的研究及商用,越来越多的运营商对RCS均表达出了浓厚的兴趣,着手制定RCS的商用部署方案。下面对制定部署方案中需考虑的问题进行介绍。
4.1 RCS与自营OTT应用的关系
目前许多运营商均有自营的OTT应用,这些应用也向用户提供即时消息、文件传输的功能,与RCS的一些基本功能完全重合。因而,运营商在考虑部署RCS时,需要考虑如何处理RCS与已有自营应用的关系。
a) 部署RCS后,是否减少对自营应用的投资。
b) RCS和自营应用如何同时推广。
c) 两者之间是否考虑互通。
d) 随着RCS API的开放,新业务是基于RCS开发还是添加到自营的OTT应用中。
4.2 RCS标准业务及特色业务的提供
由于RCS的标准一直在不断演进,因而需要事先确定使用哪个版本进行商用,是Joyn、Joyn Blackbird 还是Joyn Crane。在确定版本之后,由于RCS的开放性,运营商还可以定制一些特色业务,以便给用户更好的体验。但需要注意的是,这些特色业务将无法与其他运营商的RCS用户互通,同时还需要对设备、终端进行定制,不能直接采用标准的RCS设备和终端。因而在特色和成本之间需要进行论证。
4.3 服务器全国集中部署或分省部署
对于我国运营商而言,由于用户数目庞大,若参照欧洲、美国、韩国等运营商的部署架构,对RCS服务器进行集中部署,则有可能无法保证业务质量。因为各省RCS用户的信令、媒体需要先连接到统一的RCS服务器,才可到达接收端,路由过长导致时延较大;另外所有用户的流量汇聚到统一的服务器进行处理,对服务器的性能要求也较高。虽然有上述缺点,但集中部署的优势在于投资小、业务开展速度快。若RCS服务器分省部署,则QoS可以得到保证,但投资规模大,各省单独测试耗费时间长,业务开展速度将相对较慢。
4.4 用户的开户
运营商事先为所有用户均开通RCS功能,用户只要安装RCS客户端或新购买有内置RCS功能的手机即可使用,这种方式对用户而言是最便捷的方式,运营商也不需要针对RCS开发业务开通流程。此方式在西班牙几家运营商、美国MetroPCS得到应用,但这些运营商的共同特点都是用户较少,大约为几百万,事先为所有用户进行开户成本不高。对于中国的运营商,由于用户规模均以亿计,事先为所有用户进行开户显然无法做到。因而建议在用户首次使用RCS时,由用户触发开户流程,RCS客户端和服务器共同配合,实现用户无感知的开户流程。但需要注意的是,某些手机操作系统不允许第三方应用读取手机的MSISDN和IMSI,因而如何方便快捷地获取用户信息,并为用户实现自动开户是必需解决的问题。
4.5 RCS业务质量保证
从功能上看,RCS业务与许多OTT应用的业务并无区别,为了吸引更多用户使用,运营商有必要考虑保证RCS的业务体验高于OTT应用。实现此目标的方式有很多,例如可以给RCS业务分配专门的APN,或者基于DPI技术,对RCS的业务流提供较高的优先级。
4.6 计费考虑
目前已提供RCS业务的运营商均是把RCS所产生的流量归到用户的流量套餐中,不进行单独计费。但是RCS的即时消息、VoIP等业务对短信、语音有较大的冲击,因而在制定计费策略时需根据实际情况进行考虑,如可能的话,可针对不同业务实施区别计费。
4.7 开放RCS的API
RCS的最终目标是打造一个生态系统,基于RCS提供的核心能力,让第三方开发者实现更多应用,如游戏、移动支付等。
除了上述所描述的步骤之外,运营商在部署RCS时还需要考虑目前的3G网络对SIP、MSRP、TCP等协议的支持程度,确保网络方面不存在问题。
5 结束语
RCS重新定义了运营商的核心产品和业务组合,并且支持网络能力的开放,可以为用户提供更多的选择;但是RCS同时也存在业务部署周期长、生态环境成长缓慢、更新不及时、终端类型较少等不足之处。另外,目前RCS规范所定义的许多业务均与OTT应用类似,在用户看来可能缺乏创新性,只是把这些业务的提供者从互联网公司改为运营商而已。因而,在RCS部署之后,如何培养用户习惯,鼓励用户从OTT应用转移到使用RCS上,这是一个需要解决的问题。而关于RCS的推广,需要众多运营商的积极参与,如果只有少数运营商进行商业应用,不能形成规模优势,则RCS的前途堪忧。
虽然RCS存在着许多缺陷,面临着各种问题,但面对OTT应用的步步紧逼,RCS仍然是运营商突破重围,创立一片新天地的重要途径,甚至可以说是唯一的途径。运营商如果不考虑基于RCS增加业务范围、构建生态圈,则沦为纯粹的管道提供商几乎是必然的事情,而借力于RCS,则有可能遏制OTT应用的持续进逼,甚至会增加新的利润增长点。
参考文献:
GSMA. RCS-e - Advanced Communications: Services and Client Specification Version 1.2[EB/OL]. [2012-12-27]. http://zh.scribd.com/doc/74792363/Rcs-e-Advanced-Comms-Specification-v1-2.