0 前言
目前，Kakao Talk、WhatsAPP、iMessage等互聯(lián)網(wǎng)應用的廣泛使用，令運營商的短信收入急劇下降。微軟主推的Skype、蘋果公司提供的FaceTime等應用也對運營商的語音收入帶來嚴重威脅，而谷歌和美國運營商Sprint的合作，讓用戶可基于電話號碼使用谷歌的VoIP服務，則進一步預示了傳統(tǒng)CS電話業(yè)務的衰退。為了應對互聯(lián)網(wǎng)業(yè)務的挑戰(zhàn)，GSMA積極推進富通信套件（RCS）標準的制定和產(chǎn)業(yè)化活動。
RCS是一種基于手機地址本的，集語音、即時消息、文件傳輸、內(nèi)容共享、呈現(xiàn)、位置服務等多種通信方式于一體的融合通信服務。但RCS不僅僅局限于上述所列功能，它的版本仍在更新中，后續(xù)版本將繼續(xù)補充其他新功能。同時RCS也進行了API開放的相關研究，包括網(wǎng)絡地址本、即時消息、文件傳輸?shù)饶芰Χ紝㈤_放給第三方，以便基于RCS提供更多、更豐富的業(yè)務。因而，RCS是運營商提升競爭力，提高單個用戶ARPU值的重要途徑。
本文將從標準規(guī)范、開放API、產(chǎn)業(yè)情況等方面介紹RCS的情況，并對RCS的網(wǎng)絡部署、可能存在的問題提出相關建議。
1 RCS標準規(guī)范
RCS從2007年開始成立工作組，截至目前，按照時間順序其功能規(guī)范的版本經(jīng)歷了RCS 1/2/3/4/RCS-e/5/5.1共7個階段。其中RCS-e是RCS 2的簡化版，是一個較為特殊的版本，其產(chǎn)生的主要原因是在前期推動RCS商用時，發(fā)現(xiàn)功能過多導致終端開發(fā)速度慢、網(wǎng)絡難以迅速適應等問題。因而歐洲五大運營商Deutsche Telekom、Orange-FT、Telecom Italia、Telefonica、Vodafone 從2011 年初開始啟動RCS-e 的研究，對RCS 2的功能進行簡化。但是從RCS 5開始，RCS-e和RCS 4又進行了整合，統(tǒng)一于一個版本，不再另行發(fā)展。
RCS 1發(fā)布于2008年12月，該版本定義了通話中內(nèi)容共享、通話或消息聊天時進行文件傳輸、增強型消息、社會呈現(xiàn)、服務能力信息、高可用性、黑名單、網(wǎng)絡地址簿等基本業(yè)務。
RCS 2發(fā)布于2009年6月，在業(yè)務功能上較RCS 1進行了增強，主要體現(xiàn)在：支持用戶通過寬帶接入的方式使用RCS業(yè)務，但此時用戶可以發(fā)送短信，不可接收短信；支持使用多終端；支持基于運營商管理的網(wǎng)絡地址簿及對用戶進行自動配置。RCS 2的亮點在于支持多終端，用戶不僅可以在手機上使用RCS，還可以在PC上使用，從而拓展了RCS的使用范圍。
RCS 3發(fā)布于2009年底，對RCS 2的功能進行了增強：寬帶接入的設備作為主要設備；支持非通話期間的內(nèi)容共享、支持把共享內(nèi)容傳遞給傳統(tǒng)終端；增強的呈現(xiàn)信息，包括地理位置、URL標簽等；增強的消息，允許寬帶接入的終端發(fā)送和接收彩信/短信；網(wǎng)絡增值服務；對用戶透明的開戶和配置過程。
RCS 4發(fā)布于2010年底，最重要的變化是提出支持LTE，另外也提出支持大文本消息、與短信的后向兼容、視頻共享的暫停和恢復等功能。RCS 4引入LTE，契合了LTE迅速發(fā)展的潮流，也使RCS可以得到更多運營商的支持。
RCS-e 1.1版本發(fā)布于2011年4月，最終版本v1.2.2發(fā)布于2012年7月。它是RCS 2的簡化版本，去掉了社會呈現(xiàn)、心情短語等功能。目前歐洲運營商向用戶所提供的RCS業(yè)務，均是基于此版本。RCS-e的功能如圖 1所示［1］，圖中的左邊部分是RCS-e不支持的功能。
RCS 5.0發(fā)布于2012年4月，它基于RCS 1～4和RCS-e 1.2，包括了RCS 1～4和RCS-e 1.2的所有功能，融合了歐洲和北美的RCS標準。相比之前的各版本，RCS 5.0擴展了1對1聊天、群組聊天、文件傳輸?shù)墓δ�，新增了IP Video Call、HD Voice Call、地址位置交換，支持OMA CPM 和OMA SIMPLE IM。RCS 5.0可以稱作是RCS的集大成者，不僅包括了之前各RCS版本的功能，還新增了許多功能，是一個十分受人關注的版本。
RCS 5.1發(fā)布于2012年8月，隨后幾個月還仍然在進行修訂，預計2013年上半年會最終定稿。相比RCS 5.0，RCS 5.1主要是增加文件的存儲轉(zhuǎn)發(fā)、靜態(tài)群組消息的存儲轉(zhuǎn)發(fā)、在地圖上顯示位置等功能。
總的來說，從RCS 1到RCS 5.1，標準規(guī)范所定義的功能越來越豐富，有效地擴展了運營商的基本電信業(yè)務范疇，有利于運營商基于高速的網(wǎng)絡環(huán)境向用戶提供更多業(yè)務。
同時，從上述標準的進展可以看出，GSMA近幾年一直致力于推進RCS的發(fā)展，標準更新速度非常之快。在OTT應用對運營商傳統(tǒng)業(yè)務的大量侵蝕情況下，RCS被認為是運營商應對OTT競爭的強有力武器，備受全球運營商、設備商、終端廠家的關注，因而GSMA加大對RCS標準制定的投入也在情理之中。下面分別從用戶、運營商、第三方開發(fā)者的角度介紹RCS的優(yōu)勢。
對于用戶而言，相比OTT等互聯(lián)網(wǎng)應用，RCS具有以下優(yōu)勢。
a） 集成到手機中，用戶無需安裝，直接使用。RCS的使用方式類似于短信，例如，十多年前的手機可能并不支持短信，當出現(xiàn)短信這個新業(yè)務后，短信功能被內(nèi)置于手機中，用戶直接使用即可。需要注意的是，目前用戶所使用的手機絕大部分未內(nèi)置RCS功能，對于這些手機，可以下載安裝RCS客戶端。
b） 全球運營商均遵循GSMA標準，可快速實現(xiàn)66億多移動用戶的互通。還以短信為例，短信是所有運營商均支持的業(yè)務，用戶可以給任何一個移動手機用戶發(fā)送短信，而不用考慮接收方是否支持短信功能。
c） 運營商級的業(yè)務，可以保證良好的服務質(zhì)量。相比OTT應用提供的IP語音、即時消息等功能，RCS是運營商的自營業(yè)務，運營商可以在業(yè)務質(zhì)量方面提供有效保證。
對于運營商，RCS具有以下優(yōu)點。
a） 業(yè)務種類豐富，可以提升運營商在用戶中的形象。
b） 開放API，使運營商可提供特色業(yè)務或讓第三方開發(fā)新業(yè)務。
c） 終端產(chǎn)業(yè)鏈共同遵循GMSA標準，減少定制終端的工作量。
d） 全球統(tǒng)一品牌，識別度高，可迅速進行推廣。
對于第三方開發(fā)者而言，RCS的API在全球統(tǒng)一，基于RCS開發(fā)的新應用，一旦在某個運營商網(wǎng)絡中開發(fā)成功，則在全球所有運營商網(wǎng)絡中均可推廣。
2 RCS API
RCS API的目的在于開放網(wǎng)絡能力，便于開發(fā)新的應用，讓RCS業(yè)務延伸到新的用戶群體，開創(chuàng)新的盈利機會和商業(yè)模式。RCS API包括的內(nèi)容有授權框架、一般通知、網(wǎng)絡地址簿、能力發(fā)現(xiàn)、消息、文件傳輸、內(nèi)容共享。
《RCS-e Network API Detailed Requirements 1.0》與《RCS API Detailed Requirements 1.1》均發(fā)布于2011年10月，其中1.0版本主要針對RCS-e，而1.1版本則主要針對RCS 1/2/3�！禦CS Network API Detailed Requirements 2.0》發(fā)布于2012年5月，融合了1.0和1.1版本，解決了同時存在多個API規(guī)范的混亂局面。
RCS API 2.1發(fā)布于2012年7月，對RCS API 2.0中的一些錯誤進行了修訂。2.2版本發(fā)布于2012年11月，添加了長時間存活群組的API、VoIP和Video Over IP的API。目前GSMA正在基于RCS 5.1標準規(guī)范制定RCS API的2.3版本，截至2013年2月底，2.3版本的API已完成初稿，正在征求各運營商、設備商、終端廠家的意見。
需要注意的是，在研究RCS API之前，GSMA于2008年曾提出了One API項目，這個項目與RCS API有許多相同之處，也是關注運營商應該開放哪些網(wǎng)絡能力以及如何開放這些能力，以吸引Web開發(fā)者。One API與RCS API的工作流程有許多相同的地方，均是提出相應的API需求，然后提交給OMA，由OMA挑選確定后，形成一個新的規(guī)范或加入到對應的已有API規(guī)范中。
One API項目提出了Messaging（消息），Payment（支付）和Location（地理位置）等API的需求，并提交給OMA進行標準化。2010年，One API項目還在加拿大3家運營商的網(wǎng)絡中進行了開放的試驗，該試驗運行2年，共有超過400個注冊開發(fā)者，創(chuàng)造的價值超過1 800萬加元。從這個應用案例可以看出，One API在網(wǎng)絡能力開放方面，做了一些十分有意義的工作。
2012年以后，由于RCS API逐漸受到大家的重視，一些工作與One API有重復之處，而One API本身的標準化工作也逐漸減少，因而2013年1月底，GSMA的產(chǎn)品與服務管理委員會（PSMC）決定關閉One API，相關標準化工作轉(zhuǎn)交給其他工作組。
在One API和RCS API之前，對于開放電信網(wǎng)絡能力方面的研究，曾經(jīng)出現(xiàn)過基于CORBA的Parlay API和基于SOAP的Parlay X API，但均由于過于復雜而未獲得大范圍推廣。而One API和RCS API則是基于目前流行的REST風格進行描述和設計，可以讓第三方開發(fā)者使用HTTP調(diào)用電信能力，十分簡單易行。因而，雖然One API已經(jīng)停止工作，但是在2013年年初的GSMA會議上，專家們提出，IMS網(wǎng)絡正在逐漸得到部署，其能力開放的研究還未完成，需要成立專門的工作組進行研究，以彌補關閉One API項目帶來的缺陷。由于RCS基于IMS，RCS API可以看成是IMS API（即IMS網(wǎng)絡能力的開放），因而專家們建議即將成立的IMS API工作組可重點關注RCS API。
綜上所述，RCS API的工作在未來一段時間仍是運營商關注的焦點，其與IMS API密切相關，可以這樣認為，RCS API的開放即相當于IMS網(wǎng)絡能力的開放。
3 產(chǎn)業(yè)情況
為了保證RCS業(yè)務的全球互通性以及給用戶以統(tǒng)一的感知，GSMA提出了基于RCS-e的“Joyn”品牌。“Joyn”分為對終端的認證和對運營商網(wǎng)絡的認證。對于用戶而言，所有獲得“Joyn”品牌使用權的終端或運營商網(wǎng)絡均具備和其他“Joyn”終端或網(wǎng)絡進行互通的能力。通過這種方式，RCS可以在全球范圍內(nèi)快速獲得用戶的認可，并可保證用戶所能使用的業(yè)務是一致的。
當前，通過“Joyn”認證的終端有10多款，既包括內(nèi)置RCS-e的終端，也包括RCS-e軟終端；通過“Joyn”認證的網(wǎng)絡則有西班牙沃達豐、德國沃達豐、西班牙移動之星等6個網(wǎng)絡。
在2012年，歐洲、美國、韓國的一些運營商已向用戶正式提供“Joyn”服務。其中，西班牙3家處于領先位置的移動網(wǎng)絡運營商Movistar、Orange和Vodafone在2012年11月開始提供“Joyn”業(yè)務。美國的MetroPCS同期亦開始向用戶提供基于LTE的RCS業(yè)務。而韓國的SK、KT和LG Uplus 則在2012年12月開始向用戶提供RCS業(yè)務。
除了上述已經(jīng)正式對外宣布提供“Joyn”服務的運營商外，法國與意大利的運營商預計2013年上半年也將會向用戶提供RCS業(yè)務�；谀壳癛CS的發(fā)展趨勢，預計未來2～3年內(nèi)，將是RCS快速發(fā)展的時期。
關于在我國如何開展RCS業(yè)務，建議國內(nèi)運營商參考西班牙、韓國的方式，聯(lián)合起來共同推廣，以形成規(guī)模優(yōu)勢。RCS是運營商未來的基本電信業(yè)務，其目標是應對OTT的競爭，因而在RCS的應用方面，運營商間并不是競爭關系，而是相互支撐、相互合作，共同擴大市場規(guī)模的關系。對于國內(nèi)運營商間的RCS互通，可以考慮運營商各自設立網(wǎng)關，通過網(wǎng)關實現(xiàn)RCS的互通，具體內(nèi)容可參考《RCS Interworking Guidelines》，該文檔在GSMA中對應的文檔編號是IR.90。另外，鑒于目前國內(nèi)用戶所使用的手機均未內(nèi)置RCS功能，因而在推廣初期，可以建議用戶下載安裝RCS客戶端，而對于未來的入網(wǎng)手機，則要求其必須支持RCS功能。通過這種方式，可以有效地擴大RCS用戶規(guī)模。
4 RCS部署建議
隨著GSMA持續(xù)推進RCS的研究及商用，越來越多的運營商對RCS均表達出了濃厚的興趣，著手制定RCS的商用部署方案。下面對制定部署方案中需考慮的問題進行介紹。
4.1 RCS與自營OTT應用的關系
目前許多運營商均有自營的OTT應用，這些應用也向用戶提供即時消息、文件傳輸?shù)墓δ�，與RCS的一些基本功能完全重合。因而，運營商在考慮部署RCS時，需要考慮如何處理RCS與已有自營應用的關系。
a） 部署RCS后，是否減少對自營應用的投資。
b） RCS和自營應用如何同時推廣。
c） 兩者之間是否考慮互通。
d） 隨著RCS API的開放，新業(yè)務是基于RCS開發(fā)還是添加到自營的OTT應用中。
4.2 RCS標準業(yè)務及特色業(yè)務的提供
由于RCS的標準一直在不斷演進，因而需要事先確定使用哪個版本進行商用，是Joyn、Joyn Blackbird 還是Joyn Crane。在確定版本之后，由于RCS的開放性，運營商還可以定制一些特色業(yè)務，以便給用戶更好的體驗。但需要注意的是，這些特色業(yè)務將無法與其他運營商的RCS用戶互通，同時還需要對設備、終端進行定制，不能直接采用標準的RCS設備和終端。因而在特色和成本之間需要進行論證。
4.3 服務器全國集中部署或分省部署
對于我國運營商而言，由于用戶數(shù)目龐大，若參照歐洲、美國、韓國等運營商的部署架構，對RCS服務器進行集中部署，則有可能無法保證業(yè)務質(zhì)量。因為各省RCS用戶的信令、媒體需要先連接到統(tǒng)一的RCS服務器，才可到達接收端，路由過長導致時延較大；另外所有用戶的流量匯聚到統(tǒng)一的服務器進行處理，對服務器的性能要求也較高。雖然有上述缺點，但集中部署的優(yōu)勢在于投資小、業(yè)務開展速度快。若RCS服務器分省部署，則QoS可以得到保證，但投資規(guī)模大，各省單獨測試耗費時間長，業(yè)務開展速度將相對較慢。
4.4 用戶的開戶
運營商事先為所有用戶均開通RCS功能，用戶只要安裝RCS客戶端或新購買有內(nèi)置RCS功能的手機即可使用，這種方式對用戶而言是最便捷的方式，運營商也不需要針對RCS開發(fā)業(yè)務開通流程。此方式在西班牙幾家運營商、美國MetroPCS得到應用，但這些運營商的共同特點都是用戶較少，大約為幾百萬，事先為所有用戶進行開戶成本不高。對于中國的運營商，由于用戶規(guī)模均以億計，事先為所有用戶進行開戶顯然無法做到。因而建議在用戶首次使用RCS時，由用戶觸發(fā)開戶流程，RCS客戶端和服務器共同配合，實現(xiàn)用戶無感知的開戶流程。但需要注意的是，某些手機操作系統(tǒng)不允許第三方應用讀取手機的MSISDN和IMSI，因而如何方便快捷地獲取用戶信息，并為用戶實現(xiàn)自動開戶是必需解決的問題。
4.5 RCS業(yè)務質(zhì)量保證
從功能上看，RCS業(yè)務與許多OTT應用的業(yè)務并無區(qū)別，為了吸引更多用戶使用，運營商有必要考慮保證RCS的業(yè)務體驗高于OTT應用。實現(xiàn)此目標的方式有很多，例如可以給RCS業(yè)務分配專門的APN，或者基于DPI技術，對RCS的業(yè)務流提供較高的優(yōu)先級。
4.6 計費考慮
目前已提供RCS業(yè)務的運營商均是把RCS所產(chǎn)生的流量歸到用戶的流量套餐中，不進行單獨計費。但是RCS的即時消息、VoIP等業(yè)務對短信、語音有較大的沖擊，因而在制定計費策略時需根據(jù)實際情況進行考慮，如可能的話，可針對不同業(yè)務實施區(qū)別計費。
4.7 開放RCS的API
RCS的最終目標是打造一個生態(tài)系統(tǒng)，基于RCS提供的核心能力，讓第三方開發(fā)者實現(xiàn)更多應用，如游戲、移動支付等。
除了上述所描述的步驟之外，運營商在部署RCS時還需要考慮目前的3G網(wǎng)絡對SIP、MSRP、TCP等協(xié)議的支持程度，確保網(wǎng)絡方面不存在問題。
5 結束語
RCS重新定義了運營商的核心產(chǎn)品和業(yè)務組合，并且支持網(wǎng)絡能力的開放，可以為用戶提供更多的選擇；但是RCS同時也存在業(yè)務部署周期長、生態(tài)環(huán)境成長緩慢、更新不及時、終端類型較少等不足之處。另外，目前RCS規(guī)范所定義的許多業(yè)務均與OTT應用類似，在用戶看來可能缺乏創(chuàng)新性，只是把這些業(yè)務的提供者從互聯(lián)網(wǎng)公司改為運營商而已。因而，在RCS部署之后，如何培養(yǎng)用戶習慣，鼓勵用戶從OTT應用轉(zhuǎn)移到使用RCS上，這是一個需要解決的問題。而關于RCS的推廣，需要眾多運營商的積極參與，如果只有少數(shù)運營商進行商業(yè)應用，不能形成規(guī)模優(yōu)勢，則RCS的前途堪憂。
雖然RCS存在著許多缺陷，面臨著各種問題，但面對OTT應用的步步緊逼，RCS仍然是運營商突破重圍，創(chuàng)立一片新天地的重要途徑，甚至可以說是唯一的途徑。運營商如果不考慮基于RCS增加業(yè)務范圍、構建生態(tài)圈，則淪為純粹的管道提供商幾乎是必然的事情，而借力于RCS，則有可能遏制OTT應用的持續(xù)進逼，甚至會增加新的利潤增長點。
參考文獻：
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. 
