RCS終端技術方案研究與驗證

摘要：跟蹤RCS標準演進情況，分析RCS相對OTT的優勢，調研國內外運營商商用情況。重點對VoLTE/RCS單雙注冊、RCSNative/APP版本功耗情況等進行研究，提出RCS原型終端技術方案建議，為國內RCS的發展奠定基礎。關鍵詞：RCS終端，Native，融合通信1引言隨著互聯網行業的不斷發展，OTT業務對運營商傳統語音和短消息業務的沖擊已經有目共睹了，運營商業務利潤正在大幅下滑。RCS(RichCommunicationSuite，富通信套件)的出現為運營商應對互聯網的挑戰提供了新的機遇。RCS是由GSMA(GroupeSpecialeMobileAssociation)發起，旨在幫助運營商豐富現有電話/信息的客戶體驗，占據無線社區市場的主動地位。RCS標準從2008年至今已發展到UP2.0，期間經歷十余個版本的演進，標準演進如圖1所示。圖1RCS標準演進其中，RCS-e是RCS2.0的簡化版，去掉了社會呈現、心情短語等功能，其產生的主要原因是在前期推動RCS商用時，發現功能過多導致終端開發速度慢，網絡難以迅速適應。RCS5.0合并了RCS1～4和RCS-e的所有功能，新增了IPVideo/VoiceCall等功能。GSMA2016年啟動RCSUniversalProfile計劃，推動全球運營商向更精簡，技術實現更統一的RCSUniversalProfile演進，RCSUP1.0保留核心業務功能，統一技術實現，旨在推動全球運營商統一標準，簡化RCS的產品開發和全球運營商部署，減少互通問題。RCSUP2.0新增MaaP能力、插件以及更多的開放API。2RCS現狀當前，OTT(如微信)等消息工具已非常強大，那么為什么運營商還要推動RCS的發展呢？首先，RCS是GSMA國際標準，有利于全球運營商互通，而OTT(微信)等均為私有標準，僅OTT(微信)APP內用戶間可以互通。其次，RCS基于電話號碼，可隨時發起消息及呼叫，而OTT(微信)等必須先成為好友，才能發起消息及呼叫。再者，RCS可以采用Native終端，復用原生消息入口，無需安裝APP，OTT(微信)等都需要安裝APP才可進行語音消息交互。最后，RCS可以與VoLTE結合，差異化語音業務體驗，另外，好友圈之外還有大量語音需求，如呼叫中心、快遞等，通過與消息協同，帶動消息業務發展。電信運營商部署RCS主要考慮業務發展需要和能力提升需要，業務發展需要包括：(1)消息與語音業務一樣，為電信運營商基礎業務；(2)僅文本短信不能滿足用戶需求；(3)多媒體消息是客戶剛性需求。能力提升需要包括：(1)短彩信業務形態和體驗遠遠落后于OTT消息；(2)VoLTE只考慮了文本短信，未考慮彩信的演進；(3)把控語音及消息原生入口。目前，引入RCS的時機已經成熟。RCS國際標準已取得階段性的成果，其中多媒體消息、增強呼叫、MaaP能力部分較為成熟。2017年9月GSMA組織遵循UP標準的全球測試，加速了全球RCS網絡及設備的統一和標準化，各運營商也都有意愿向國際標準靠攏，避免定制化需求。華為、三星、LG等大型終端廠商陸續在歐洲、北美多家運營商商用RCS，Google2018年底預計也將在Android操作系統層面預置RCS消息能力及提供RCSAPI，Sprint、AT&T、Vodafone要求終端出廠必選支持RCS能力。截至2018年6月全球共有53家運營商商用RCS，商用RCS終端398款，Samsung、LG、Motorola、Sony、HTC、ZTE、Micromax等22個終端廠商商用RCSUP版本。亞洲目前已有8家運營商商用RCS。日本三個運營商在2018年5月同時商用了RCS并實現互通。中國移動已于2017年12月商用RCS，華為榮耀10、P20/P20pro、榮耀play、三星S8/S9、移動自主品牌A4等已支持RCS，另外中國移動還與Samsung、華為、ZTE、魅族、MI、大唐電信、Lenovo、海信、朵唯、SUGAR糖果手機達成合作協議。另外，中國電信和中國聯通也在積極進行RCS方案驗證，中國電信、中國移動、中國聯通實驗室基于RCC.66的RCS基本消息能力測試已經完成，推動了在RCS領域中國區運營商的合作，體現了三家運營商共同推進RCS業務，引導產業鏈跟進的意愿。3RCS終端關鍵問題分析及建議3.1RCS終端解決方案對比及建議目前，RCS終端解決方案有如下幾種：(1)GoogleRCS方案，即采用Google的RCS客戶端AndroidMessage。該方案用戶體驗更好，與Android操作系統天然融合，并有利于以后終端間的互聯互通。但是，Google在Android內置RCS后很大可能不會開源代碼，終端廠商無法利用其RCS協議棧進行二次開發，因此RCS客戶端的業務功能取決于Google的發展路標。另外，國內自建RCS服務器與Google的客戶端互通調測不可避免會存在諸多問題。最后，Google的RCS業務路標看齊GSMARCSUP規范，不會為運營進行特殊定制，采用Google的RCS方案意味著運營商失去對業務發展的主控權。(2)第三方開發商提供RCSNative版本，統一提供版本，由廠家集成。統一方案能夠加速產品的推進，RCS廠商提供全套解決方案并提供參考UI，然后手機廠家參考UI代碼，集成RCS方案，第三方廠商負責技術支持。(3)第三方開發商提供RCSNative版本，統一提供版本，由第三方集成。第三方開發商要按照每個廠商的UI風格做適配開發和測試，在質量和專業度上與手機廠商會有些差距，手機廠商要開放UI代碼給第三方開發商，部分廠商會有些難度。根據國內現狀建議使用第二種方案，即運營商提供統一的RCS解決方案(第三方開發包含SDK、UI參考代碼)由廠家自行集成，廠商基于運營商提供的RCS解決方案適配各自的UI。3.2RCS終端具體問題分析及建議(1)VoLTE/RCS單注冊、雙注冊標準的RCS基于IMS網絡，根據網絡情況可有兩種IMS承載方案：單注冊和雙注冊。單注冊即RCS復用VoLTE的協議棧，共用IMSAPN，有QoS保障，可提供MSRP的QoS保障。與芯片平臺強關聯，需要芯片廠家封裝提供VoLTE協議棧的調用接口。其優點是保活一個注冊連接，待機的功耗和流量較低，單協議棧，理論上內存占用少。缺點是RCS和VoLTE完全耦合，開發難度大，主要依賴終端廠家開發，開發周期長，業務靈活性受限。單注冊以Native為主。相應地，雙注冊指RCS和VoLTE相互獨立，需要保活兩個注冊連接，VoLTE使用IMSAPN承載，RCS使用InternetAPN承載，IMS需要支持InternetAPN接入，待機的功耗和流量較高。雙協議棧理論上內存占用也較多。但雙注冊開發難度較小，通用性強，非終端廠家也可以參與開發。雙注冊Native和APP并存。單雙注冊架構如圖2所示。圖2單雙注冊開發架構對比除三星、華為外，多數終端廠家技術經驗積累不足，并結合國內產業鏈生態，建議采用開發難度小的雙注冊方案，加快RCS開發進程。目前，中國移動采用雙注冊，已完成VoLTE和RCS獨立IMS部署，同時發展APP及Native終端，APP重點打造企業應用，Native主要支持符合國際標準的基本消息功能。中國移動RCS已經于2017年12月正式商用。(2)RCS的Native和APP版本功耗RCS有兩種提供方式，通過Native或者是APP提供。所謂Native即通過原生終端提供，終端內置RCS，RCS與手機原生地址薄融合，且與短信等原生業務體驗一致。通過APP提供即通過客戶端下載的方式安裝，采用獨立的應用為用戶提供RCS服務，與普通OTT業務體驗類似，不同業務有更具體的要求。在體驗上，可以看出Native版本相比APP版本更具優勢。在功耗方面，通過對雙注冊過程中Native版本和APP版本的終端進行功耗測試對比發現，Native版本相對APP版本的功耗較低。功耗測試環境如圖3所示：圖3功耗測試環境由于測試例較多，本文僅列舉部分測試例。首先測試微信組、APP組及Native組待機電量，即登陸成功后待機15分鐘，求功耗平均值。然后，從4G到Wi-Fi進行網絡切換，測試時間為2分鐘，求平均功耗。最后，發送1次“微笑”表情，時間為10s，求平均功耗。測試結果如表1所示。表1雙注冊終端Native版本和APP版本功耗情況測試類別測試項目單項操作時間微信組AVG(mA/s)APP組AVG(mA/s)Native組AVG(mA/s)備注待機電量登陸成功后待機15min15min179.97182.29178.17不黑屏，Native、APP和微信停留在消息列表頁面融合通信1對1消息4G到Wi-Fi切換網絡2min228.76234.10222.29-融合通信1對1消息發送1次“微笑”表情10s248.86259.43239.17標準表情通過上面的數據，可以明顯看出Native版本的平均功耗比APP版本的平均功耗低。因此，建議RCS采用Native原生終端提供。4結束語文章首先介紹了RCS標準的演進情況以及引進RCS的必要性，然后，根據對現狀的分析提出RCS終端解決方案，即運營商提供統一的RCS解決方案，由廠家自行集成。最后，研究分析了RCS終端的單雙注冊，并通過數據對比分析發現RCSNative版本比APP版本的功耗低且體驗好，所以建議RCS采用原生終端提供。引用格式：安小靜，戴國華，張婷.RCS終端技術方案研究與驗證[J].移動通信，2018，42(10)：96-99.參考文獻：[1]謝斌.終端VoLTE和RCS的共存研究[J].電信技術，2013(9)：71-74.[2]GSMAIR.92.IMSProfileforVoiceandSMSVersion7.0[S].2013.[3]GSMAIR.94.IMSProfileforConversationalVideoService[S].2013.[4]侯賽男，嚴斌峰，周晶，等.RCS業務發展情況及分析[J].信息通信技術，2016，10(5)：67-72.[5]魯義軒.運營商聯手中興通訊推進RCS部署加速布局“能力開放”[J].通信世界，2016(18)：46.[6]李勇輝，呂光旭，符剛，等.電信運營商RCS部署建議[J].郵電設計技術，2013(4)：1-5.[7]李勇輝，呂光旭，魏群，等.RCS價值的深度分析[J].軟件，2013(8)：108-111.[8]許巧游.運營商基于平臺運營的通信能力開放[J].信息通信，2016(1)：250-251.[9]歐小鷗，陳榮斌.RCS(融合通信)技術與應用[J].中國新通信，2015