吳麗華，沈蕾

（中國移動通信集團設計院有限公司網(wǎng)絡所，北京 100080）

1 引言

運營商融合通信業(yè)務是對現(xiàn)有語音、短/彩信、通訊錄三大通信入口的升級，在保護用戶原有通信習慣、繼承運營商基礎通信業(yè)務全球可達性和電信級服務質(zhì)量的前提下，形成以新通話、新消息、新聯(lián)系為核心，功能完善、體驗優(yōu)良的基礎通信服務，是運營商應對OTT（over the top）競爭的重要抓手。

為了保證全球互通性，運營商融合通信業(yè)務基于GSMA RCS（rich communication suite，富通信業(yè)務套件）標準構建，RCS基于 IMS（IP multimedia subsystem，IP多媒體子系統(tǒng)）體系架構，在遵循RCS基礎協(xié)議和標準接口的基礎上，運營商可對RCS和IMS進行裁剪、定制和優(yōu)化，以達到提升產(chǎn)品競爭力，降低建設成本、運營和維護難度的效果。

運營商在部署融合通信時，需要先分析融合通信業(yè)務與現(xiàn)有業(yè)務的關系，根據(jù)自身需要確定RCS基礎業(yè)務功能集和擴展功能，并處理好融合通信業(yè)務與現(xiàn)有即時通信OTT業(yè)務的關系，以使業(yè)務能互促發(fā)展。在進行融合通信網(wǎng)絡架構設計時，需要進行技術路線選擇，應采用標準RCS架構還是采用SIP代理服務器（SIP proxy）提供標準接口適配，考慮節(jié)點集中部署或分散部署方案、與運營商自有OTT整合方案、與其他運營商互通漫游方案等。為了便于用戶使用，對于融合通信業(yè)務應進行用戶無感知的開通。目前，已開展融合通信業(yè)務的運營商均采用按流量計費方式，與現(xiàn)網(wǎng)語音按通話時長、短信按條計費的方式不同，應考慮優(yōu)化資費策略和話單核減方案。

2 融合通信業(yè)務概述

2.1 融合通信業(yè)務介紹

運營商融合通信業(yè)務基于GSMA RCS標準構建，RCS從2007年開始成立工作組，其功能規(guī)范的版本經(jīng)歷了RCS 1、RCS 2、RCS 3、RCS 4、RCS-e、RCS 5.0、RCS 5.1、RCS 5.2共8個階段，從RCS 1到RCS 5.2，標準規(guī)范所定義的功能越來越豐富，有效地擴展了運營商的基本電信業(yè)務范疇，有利于運營商向用戶提供更多業(yè)務。RCS被認為是運營商應對OTT競爭的重要抓手，備受全球運營商、設備商、終端廠商的關注，多家國際運營商已實現(xiàn)RCS產(chǎn)品的商用。

RCS基于IMS架構，以增強地址本為基礎，可以實現(xiàn)內(nèi)容共享、文件傳輸、增強型消息等業(yè)務。RCS可以原生手機內(nèi)置功能形式實現(xiàn)，即native終端，用戶可以將手機地址本作為統(tǒng)一入口，方便觸發(fā)語音、消息、內(nèi)容共享等業(yè)務。但僅以native終端發(fā)展RCS業(yè)務存在受限于終端型號、且推廣速度有限的問題，因此運營商可同步推出融合通信應用終端，使得不支持RCS業(yè)務的手機通過下載應用也能使用融合通信業(yè)務。此外，還可將融合通信業(yè)務擴展至PC客戶端，實現(xiàn)同一用戶多終端的協(xié)同和交互，提升用戶體驗。

2.2 融合通信與現(xiàn)有業(yè)務的關系

（1）與現(xiàn)有語音業(yè)務的關系

在LTE全面商用部署后，VoLTE將作為運營商的目標語音解決方案，未來運營商為用戶提供的通話業(yè)務也以VoLTE為核心能力。融合通信為通話業(yè)務提供增強型的功能，如便捷的多方通話、通話過程中的內(nèi)容分享、主叫信息顯示等；融合通信還可為應用終端和PC客戶端提供VoIP業(yè)務以及用戶多終端之間的通話聯(lián)動，如多終端被叫同振等。因此，VoLTE和融合通信將共同為用戶提供高質(zhì)量、便捷、豐富的新通話業(yè)務。

（2）與現(xiàn)有短彩信業(yè)務的關系

融合通信提供基于IP的即時消息服務，并兼容傳統(tǒng)短/彩信。終端存在可用IP連接的情況下（PS域或Wi-Fi），優(yōu)先使用即時消息方式發(fā)送，不發(fā)送短信、彩信，但可接收短信、彩信；終端不存在IP連接的情況下（終端僅駐留在2G/3G CS域），消息的發(fā)送體驗繼承傳統(tǒng)的短/彩信發(fā)送體驗。融合通信的即時消息業(yè)務對短/彩信業(yè)務將有較大的沖擊，未來即時消息業(yè)務將逐漸替代短/彩信業(yè)務。

（3）與運營商已有即時通信OTT應用的關系

目前運營商也開展了即時通信OTT應用，其即時消息、文件傳輸?shù)裙δ芘c融合通信的一些基本功能重合，運營商需要考慮融合通信與已有OTT應用的關系，是同時推廣、業(yè)務互通，還是進行深度融合。

運營商已有OTT應用一般是以社交好友關系為基礎，“社交”屬性較強；而融合通信是對終端固有的通信入口進行升級，以終端原生方式存在，具備“基礎通信”屬性。將融合通信與已有OTT應用進行整合，有利于將OTT已有的客戶規(guī)?？焖龠w移到融合通信，有利于融合通信在“基礎通信”屬性的基礎上疊加“社交”屬性，滿足用戶多元化的通信和社交需求，進一步應對OTT競爭。

3 融合通信商用部署關鍵方案

3.1 技術路線選擇

從GSMA RCS標準來看，RCS是基于IMS體系架構的，但IMS信令和網(wǎng)絡開銷較大，部分業(yè)務性能低于OTT應用。因此也可考慮采用輕量級的SIP代理服務器適配提供IMS相關接口，提供RCS業(yè)務，如圖1所示。

兩種架構的業(yè)務層相同。其中，即時消息服務器主要負責增強消息功能，包括一對一聊天、群組聊天以及文件傳輸?shù)裙δ?；狀態(tài)呈現(xiàn)服務器主要負責實現(xiàn)呈現(xiàn)狀態(tài)的訂閱、存儲以及發(fā)布等功能；XML文檔管理服務器主要負責用戶個人信息、聯(lián)系人列表以及用戶群組信息、授權規(guī)則等的管理，包括接入代理及驗證、搜索代理、信息保存及維護、信息變化的訂閱及通知等功能；IP-SM-GW負責即時消息與現(xiàn)網(wǎng)短信互通；終端配置服務器作為終端使用融合通信業(yè)務的第一個入口點，將各業(yè)務功能的服務入口 （包括SBC、業(yè)務平臺域名或IP地址）通過終端配置流程下發(fā)給終端。此外，運營商還可以根據(jù)業(yè)務規(guī)劃部署其他業(yè)務平臺。

圖1 融合通信技術路線選擇

兩種架構的用戶與網(wǎng)絡間UNI（user network interface，用戶網(wǎng)絡側接口）相同，均遵循RCS標準，以便經(jīng)認證的終端均能接入網(wǎng)絡使用RCS業(yè)務。終端通過HTTPS接入終端配置服務器，實現(xiàn)融合通信業(yè)務入口點發(fā)現(xiàn)；終端通過SIP（Gm接口）接入網(wǎng)絡，使用IMS類業(yè)務，如即時消息、群組等；終端通過XCAP接入業(yè)務平臺，使用非IMS類業(yè)務，如消息存儲等；終端通過MSRP（message session relay protocol，消息會話中繼協(xié)議）接入業(yè)務平臺，傳送群聊媒體。

兩種架構的不同在于控制層，具體如下。

·基于IMS的RCS架構需要部署IMS核心網(wǎng)，包括SBC （session border controller，會話邊界控制器）、P-CSCF（proxy call session control function，代理呼叫會話控制功能）、I/S-CSCF （interrogating/serving call session control function，查詢/服務呼叫會話控制功能 ）、BGCF（breakout gateway control function，出 口網(wǎng)關控制功能）、HSS（home subscriber sever，歸屬用戶服務器）、ENUM（telephone number mapping，電話號碼映射）/DNS等網(wǎng)元，負責用戶的注冊鑒權、業(yè)務觸發(fā)、業(yè)務路由以及與其他RCS的互通。

·基于SIP proxy的RCS架構采用輕量級的SIP proxy代替IMS核心網(wǎng)，將Gm接口的SIP轉換為與AS之間的私有協(xié)議。為了保證與其他IMS網(wǎng)絡、RCS系統(tǒng)的互通，SIP proxy需要適配提供相關的接口，如提供Mw接口與其他IMS互通；為了支持對終端進行AKA鑒權，還需要提供Cx接口與現(xiàn)網(wǎng)HSS互通。為了保證互通，在與其他IMS互通時，用戶碼號格式也需要符合標準要求。

基于IMS的RCS架構為標準方案，主流電信設備廠商均能提供，且其互通接口經(jīng)過商用驗證，產(chǎn)品較為成熟，缺點是需要部署的網(wǎng)元較多，且IMS信令和網(wǎng)絡開銷較大，部分業(yè)務性能低于OTT應用。基于SIP proxy的RCS架構一般由融合通信業(yè)務層廠商綁定開發(fā)，將SIP轉換之后，可采用廠商私有優(yōu)化后接口與AS交互，信令效率較高，但與其他RCS互通時可能需要聯(lián)調(diào)測試，工作量較大。

3.2 節(jié)點部署架構

國內(nèi)各運營商都已進行IMS網(wǎng)絡的部署，且均為分省部署方式。若采用基于IMS的RCS架構進行建設，需要考慮融合通信 IMS與現(xiàn)網(wǎng)IMS的部署方案。

（1）集中建設獨立的融合通信IMS

該方案融合通信IMS采用獨立域名，作為獨立的IMS域與現(xiàn)網(wǎng)各省IMS核心網(wǎng)互通。終端的VoLTE業(yè)務在各省IMS簽約，并由VoLTE AS提供服務；終端的RCS業(yè)務在融合通信IMS網(wǎng)絡簽約，并由融合通信業(yè)務平臺提供業(yè)務。終端同時使用VoLTE業(yè)務和RCS業(yè)務時，需要在兩個IMS域同時注冊，如圖2所示。

（2）融合通信IMS復用現(xiàn)網(wǎng)IMS核心網(wǎng)

圖2 融合通信節(jié)點部署方案，獨立設置IMS

該方案下融合通信業(yè)務平臺通過ISC接口接入現(xiàn)網(wǎng)各省IMS核心網(wǎng)，融合通信業(yè)務用戶根據(jù)號段歸屬在各省IMS簽約。由于VoLTE業(yè)務和RCS業(yè)務的接入不同，VoLTE業(yè)務是通過LTE的IMS APN接入的，而RCS業(yè)務是通過2G/3G/4G PS（分組交換）域CMNet APN或Wi-Fi接入的。因此，使用不同的SBC接入IMS核心網(wǎng)，在IMS核心網(wǎng)中標識為一個用戶的兩個實例，不同的實例注冊不同的業(yè)務能力，需要IMS核心網(wǎng)支持GRUU功能，如圖3所示。

集中建設獨立的融合通信IMS能減少ISC接口調(diào)測工作量，加快業(yè)務上線速度，且未來有新業(yè)務對核心網(wǎng)有改造需求時，能快速滿足需求，但媒體面也集中接入，可能影響業(yè)務質(zhì)量；復用現(xiàn)網(wǎng)IMS核心網(wǎng)方案能有效利用現(xiàn)網(wǎng)設備，且媒體面就近接入，業(yè)務質(zhì)量較有保證，但省間接口調(diào)測復雜，業(yè)務上線較慢。

若初期為保證業(yè)務快速上線采用融合通信平臺集中一點設置方式。未來隨著業(yè)務量增長，單點的機房條件無法承載大業(yè)務量，單點匯聚的流量較大可能影響業(yè)務質(zhì)量，且從容災角度考慮，應從一點部署擴張至多點部署。擴展至多點部署時，應考慮以下問題。

·各節(jié)點的業(yè)務劃分：是按用戶號段分區(qū)、用戶行政歸屬分區(qū)，還是全局負荷分擔。

·多點設置時，某些網(wǎng)元需要分級設置，以便實現(xiàn)節(jié)點之間的業(yè)務轉發(fā)。如終端配置服務器需要分級設置，一級終端配置服務器為用戶提供統(tǒng)一接入點，并將請求轉發(fā)至各節(jié)點終端配置服務器。ENUM/DNS需要分級設置，二級ENUM/DNS負責分節(jié)點內(nèi)部的號碼解析和域名解析，一級ENUM/DNS負責節(jié)點之間解析請求轉發(fā)。

· 多節(jié)點之間的網(wǎng)絡組織方案：各類互通接口及承載方案。

·多節(jié)點容災方案：節(jié)點之間應具備異地容災能力，單節(jié)點出現(xiàn)故障時，可由其他節(jié)點接管業(yè)務。

· 節(jié)點分裂時用戶遷移方案：涉及用戶簽約數(shù)據(jù)、業(yè)務數(shù)據(jù)、ENUM解析數(shù)據(jù)等均需進行遷移。

3.3 融合通信與運營商自有OTT整合

融合通信的“基礎業(yè)務”屬性與運營商已有OTT應用的“社交”屬性可以互補，因此運營商在部署融合通信時，應考慮與已有OTT應用的整合，根據(jù)業(yè)務策略和業(yè)務整合的深度，有兩種整合方案：互通方案和融合方案。

（1）融合通信與OTT互通方案

該方案需要設置互通網(wǎng)關，實現(xiàn)RCS標準協(xié)議與OTT私有協(xié)議的轉換。由于OTT平臺和接口的非標性，互通網(wǎng)關一般由OTT平臺廠商開發(fā)?；ネňW(wǎng)關可以實現(xiàn)文本消息、圖片、語音、視頻、表情、位置信息、聯(lián)系人名片等類型消息的互通。

根據(jù)互通網(wǎng)關的開發(fā)量，可以實現(xiàn)互通的業(yè)務有所不同。但該方案可實現(xiàn)互通的業(yè)務有限，而且可互通的業(yè)務也存在體驗不一致的情況。對于用戶群組、聯(lián)系人等信息，由于平臺之間數(shù)據(jù)結構差別較大，較難實現(xiàn)互通和同步，因此對于同時擁有融合通信終端和OTT客戶端的用戶來說，仍存在兩類終端業(yè)務重復、混淆的問題，不利于業(yè)務開展，如圖4所示。

（2）融合通信與OTT融合方案

圖3 融合通信節(jié)點部署方案，復用現(xiàn)網(wǎng)IMS

圖4 融合通信與OTT互通

為了深度整合融合通信業(yè)務與已有OTT業(yè)務，為用戶提供更好的業(yè)務體驗，促進融合通信業(yè)務的發(fā)展，可以將融合通信業(yè)務與OTT業(yè)務進行融合。融合后產(chǎn)品形態(tài)可以包括原生手機native終端、應用終端和PC客戶端，在以下方面進行業(yè)務融合。

·用戶融合：將原有OTT的好友、群組、用戶資料與RCS群組進行融合，融合后采用統(tǒng)一的群服務器。

·功能融合：保留原有OTT產(chǎn)品中的成熟功能，保持用戶的使用體驗。

·終端融合：支持多設備接入和并發(fā)，包括多設備同時登錄及消息同步、被叫多終端同振等。

融合的網(wǎng)絡方案有多種選擇，可根據(jù)選定的技術路線和節(jié)點部署方案，結合現(xiàn)網(wǎng)OTT平臺情況進行選擇，具體介紹如下。

·將原有OTT平臺改造支持SIP proxy，對外適配標準接口 UNI和 NNI（network to network interface，網(wǎng)絡側接口），支持RCS終端接入和與其他IMS互通，該方案改造難度較小。

·將原有OTT平臺改造為RCS AS，接入融合通信IMS核心網(wǎng)，該方案也需要增加OTT到SIP的轉換模塊，與方案一的區(qū)別是只需轉換ISC接口，與RCS終端、其他IMS互通的SIP接口由IMS核心網(wǎng)提供。

·將原有OTT平臺改造為基于IMS的標準RCS架構，該方案改造量較大，基本與完全替換相同。

3.4 與其他運營商互通

融合通信相對于OTT應用的優(yōu)勢之一在于能實現(xiàn)全球可達性，因此運營商在部署融合通信時需要考慮與其他運營商實現(xiàn)業(yè)務互通，在保證現(xiàn)有短信互通體驗的基礎上，根據(jù)其他運營商RCS網(wǎng)絡建設情況，適時引入互通網(wǎng)關（IBCF、TrGW），進一步增加互通業(yè)務類型，提升RCS業(yè)務體驗。

（1）基于IMS網(wǎng)絡的互通

運營商需要分別建設互通網(wǎng)關，通過互通網(wǎng)關實現(xiàn)SIP、MSRP、RTP及XCAP的互通，其中IBCF負責信令面互通，TrGW負責媒體面互通?；ネňW(wǎng)關應具備以下功能。

·安全及管理功能：信令加密、拓撲隱藏、計費結算。

·路由及尋址功能：路由解析與轉發(fā)、地址轉換。

· 協(xié)議互通功能：SIP、MSRP、RTP 及 XCAP。

基于互通網(wǎng)關可實現(xiàn)互通的業(yè)務如下。

·RCS業(yè)務能力指示互通：通過SIP option消息及響應，或聯(lián)系人發(fā)布的SIP notify消息，攜帶通信能力種類信息，實現(xiàn)互通。

·RCS呈現(xiàn)業(yè)務互通：通過SIP publish發(fā)布更新狀態(tài)，通過SIP notify消息攜帶社交呈現(xiàn)信息實現(xiàn)互通。

·RCS即時消息業(yè)務互通：通過SIP invite消息及MSRP媒體實現(xiàn)互通。

·RCS文件傳輸/內(nèi)容共享業(yè)務互通：發(fā)起文件傳輸/內(nèi)容共享之前需要通過SIP option查詢對方能力，若能力匹配，再通過SIP invite消息及MSRP媒體實現(xiàn)互通。

·RCS視頻共享業(yè)務互通：業(yè)務先通過SIP option查詢對方能力，若能力匹配，再通過SIP invite消息及RTP媒體實現(xiàn)互通。

若運營商同時開展 VoLTE和 RCS業(yè)務，IBCF、TrGW應同時支持通話業(yè)務與消息業(yè)務的互通；若運營商采用VoLTE IMS與融合通信IMS獨立組網(wǎng)方式，IBCF還需要支持根據(jù)業(yè)務標識路由的功能，如圖5所示。

圖5 基于IMS的互通架構

（2）基于現(xiàn)網(wǎng)短信互通網(wǎng)關的互通

在其他運營商未部署IMS或RCS業(yè)務的情況下，只能通過現(xiàn)網(wǎng)短信互通網(wǎng)關實現(xiàn)短消息互通?；ネ軜嬋鐖D6所示。

圖6 基于現(xiàn)網(wǎng)短信互通網(wǎng)關的互通架構

融合通信業(yè)務平臺判斷接收端為其他運營商用戶，則將消息送至IP-SM-GW，由IP-SM-GW轉為短信后，再由發(fā)送端SMSC根據(jù)現(xiàn)網(wǎng)短信路由進行下發(fā)。其他運營商用戶向融合通信用戶發(fā)送短信的流程與現(xiàn)網(wǎng)短信相同。

融合通信網(wǎng)絡建設初期采用基于現(xiàn)網(wǎng)短信互通網(wǎng)關互通，隨著其他運營商RCS業(yè)務的開展，適時引入IBCF、TrGW網(wǎng)元，實現(xiàn)基于IMS的互通。

3.5 國內(nèi)/國際漫游

當用戶漫游至其他運營商網(wǎng)絡接入時，終端根據(jù)內(nèi)置或IMSI推導出的終端配置服務器域名查詢DNS，經(jīng)DNS解析返回終端配置服務器IP地址，由終端配置服務器返回各業(yè)務功能的服務入口給終端，終端根據(jù)業(yè)務入口接入融合通信平臺使用業(yè)務。

需要注意的是，GSMA定義的終端配置服務器域名是通過IMSI導出的，格式為 “mnc.mcc.pub.3gppnetwork.org”，需要其他運營商DNS能識別該域名，并轉發(fā)至相應運營商DNS進行解析；國際漫游時，需要推動國際“3gppnetwork.org”級域名解析DNS的建設或由轉接商負責進行域名解析。

4 融合通信開通和計費應考慮的問題

4.1 業(yè)務開通

由于融合通信業(yè)務是基礎業(yè)務的升級，為了保證用戶體驗，應在用戶首次使用RCS業(yè)務（如首次使用帶RCS功能的手機、下載融合通信App并首次使用）時進行自動開通。若融合通信業(yè)務資費與現(xiàn)網(wǎng)語音、短信資費不同，還應在開通成功后下發(fā)短信提示用戶。

自動開通流程需要融合通信終端與平臺配合實現(xiàn)，用戶首次使用帶RCS功能的手機時，終端會向內(nèi)置或IMSI推導出的終端配置服務器域名發(fā)起終端配置請求，終端配置服務器收到請求后判斷用戶未開通融合通信用戶，向業(yè)務支撐系統(tǒng)發(fā)起開通流程。

4.2 計費

目前已提供RCS業(yè)務的運營商均采用流量計費，不再另行收取業(yè)務費。對于即時消息轉短信業(yè)務，涉及流量話單和短信話單，為避免重復計費，需要考慮進行流量核減或短信話單核減，由于在流量中無法進行區(qū)分，因此需要融合通信平臺或現(xiàn)網(wǎng)短信系統(tǒng)進行改造，支持標識即時消息轉短信的業(yè)務，以便對行業(yè)務支撐系統(tǒng)進行話單核減。

5 結束語

微信等OTT業(yè)務超常規(guī)爆發(fā)增長，嚴重沖擊基礎語音和短信業(yè)務。融合通信作為“基礎通信升級”，是運營商應對OTT競爭的重要抓手。但目前融合通信的大部分業(yè)務功能均與OTT應用類似，在用戶看來可能缺乏創(chuàng)新性，只是把這些業(yè)務的提供者從互聯(lián)網(wǎng)公司改為運營商而已。因而，在RCS部署之后，如何培養(yǎng)用戶習慣，鼓勵用戶從OTT應用轉移到使用RCS上，這是一個需要解決的問題。RCS相對于OTT的優(yōu)勢之一在于不同運營商的網(wǎng)間互通和運營商級的質(zhì)量保證，因此需要眾多運營商的積極參與，才能形成規(guī)模優(yōu)勢，有效應對OTT競爭。

[1]GSMA RCC.07.Rich Communication suite5.1 advanced communications services and client specific[S/OL].(2013-11-28).[2015-07-05].http://www.gsma.com/network2020/wp-content/uploads/2013/11/RCS_5.1_UNI_4.0.zip.

[2]GSMA IR.90.RCS interworking guidelines v9.0[S/OL].(2014-07-21).[2015-07-05].http://www.gsma.com/network2020/wp-content/uploads/2013/02/RCS_5-2_NNI.zip.

[3]王凡,沈蕾,張林.融合通信業(yè)務與OTT業(yè)務互通的研究與實踐[J].電信工程技術與標準化，2015(1):6-9.

WANG F,SHEN L,ZHANG L.Research and implementation of service connection between converged communication&OTT[J].Telecom Engineering Technics and Standardization,2015(1):6-9.

[4]李勇輝,呂光旭,符剛,等.電信運營商RCS部署建議[J].郵電設計技術，2013(4):1-5.

LI Y H,LV G X,FU G,et al.The deployment recommendations of RCS for operators [J].Design Technology of Post and Telecommunications,2013(4):1-5.