融合通信商用部署關鍵問題

吳麗華，沈蕾

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

1 引言

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

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

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

2 融合通信業務概述

2.1 融合通信業務介紹

運營商融合通信業務基于GSMA RCS標準構建，RCS從2007年開始成立工作組，其功能規范的版本經歷了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，標準規范所定義的功能越來越豐富，有效地擴展了運營商的基本電信業務范疇，有利于運營商向用戶提供更多業務。RCS被認為是運營商應對OTT競爭的重要抓手，備受全球運營商、設備商、終端廠商的關注，多家國際運營商已實現RCS產品的商用。

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

2.2 融合通信與現有業務的關系

（1）與現有語音業務的關系

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

（2）與現有短彩信業務的關系

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

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

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

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

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

3.1 技術路線選擇

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

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

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

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

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

·基于IMS的RCS架構需要部署IMS核心網，包括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，出 口網關控制功能）、HSS（home subscriber sever，歸屬用戶服務器）、ENUM（telephone number mapping，電話號碼映射）/DNS等網元，負責用戶的注冊鑒權、業務觸發、業務路由以及與其他RCS的互通。

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

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

3.2 節點部署架構

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

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

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

（2）融合通信IMS復用現網IMS核心網

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

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

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

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

·各節點的業務劃分：是按用戶號段分區、用戶行政歸屬分區，還是全局負荷分擔。

·多點設置時，某些網元需要分級設置，以便實現節點之間的業務轉發。如終端配置服務器需要分級設置，一級終端配置服務器為用戶提供統一接入點，并將請求轉發至各節點終端配置服務器。ENUM/DNS需要分級設置，二級ENUM/DNS負責分節點內部的號碼解析和域名解析，一級ENUM/DNS負責節點之間解析請求轉發。

· 多節點之間的網絡組織方案：各類互通接口及承載方案。

·多節點容災方案：節點之間應具備異地容災能力，單節點出現故障時，可由其他節點接管業務。

· 節點分裂時用戶遷移方案：涉及用戶簽約數據、業務數據、ENUM解析數據等均需進行遷移。

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

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

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

該方案需要設置互通網關，實現RCS標準協議與OTT私有協議的轉換。由于OTT平臺和接口的非標性，互通網關一般由OTT平臺廠商開發。互通網關可以實現文本消息、圖片、語音、視頻、表情、位置信息、聯系人名片等類型消息的互通。

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

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

圖3 融合通信節點部署方案，復用現網IMS

圖4 融合通信與OTT互通

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

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

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

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

融合的網絡方案有多種選擇，可根據選定的技術路線和節點部署方案，結合現網OTT平臺情況進行選擇，具體介紹如下。

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

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

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

3.4 與其他運營商互通

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

（1）基于IMS網絡的互通

運營商需要分別建設互通網關，通過互通網關實現SIP、MSRP、RTP及XCAP的互通，其中IBCF負責信令面互通，TrGW負責媒體面互通。互通網關應具備以下功能。

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

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

· 協議互通功能：SIP、MSRP、RTP 及 XCAP。

基于互通網關可實現互通的業務如下。

·RCS業務能力指示互通：通過SIP option消息及響應，或聯系人發布的SIP notify消息，攜帶通信能力種類信息，實現互通。

·RCS呈現業務互通：通過SIP publish發布更新狀態，通過SIP notify消息攜帶社交呈現信息實現互通。

·RCS即時消息業務互通：通過SIP invite消息及MSRP媒體實現互通。

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

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

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

圖5 基于IMS的互通架構

（2）基于現網短信互通網關的互通

在其他運營商未部署IMS或RCS業務的情況下，只能通過現網短信互通網關實現短消息互通。互通架構如圖6所示。

圖6 基于現網短信互通網關的互通架構

融合通信業務平臺判斷接收端為其他運營商用戶，則將消息送至IP-SM-GW，由IP-SM-GW轉為短信后，再由發送端SMSC根據現網短信路由進行下發。其他運營商用戶向融合通信用戶發送短信的流程與現網短信相同。

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

3.5 國內/國際漫游

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

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

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

4.1 業務開通

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

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

4.2 計費

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

5 結束語

微信等OTT業務超常規爆發增長，嚴重沖擊基礎語音和短信業務。融合通信作為“基礎通信升級”，是運營商應對OTT競爭的重要抓手。但目前融合通信的大部分業務功能均與OTT應用類似，在用戶看來可能缺乏創新性，只是把這些業務的提供者從互聯網公司改為運營商而已。因而，在RCS部署之后，如何培養用戶習慣，鼓勵用戶從OTT應用轉移到使用RCS上，這是一個需要解決的問題。RCS相對于OTT的優勢之一在于不同運營商的網間互通和運營商級的質量保證，因此需要眾多運營商的積極參與，才能形成規模優勢，有效應對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]王凡,沈蕾,張林.融合通信業務與OTT業務互通的研究與實踐[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.