吳麗華，沈蕾

（中國移動(dòng)通信集團(tuán)設(shè)計(jì)院有限公司網(wǎng)絡(luò)所，北京 100080）

1 引言

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

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

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

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

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

運(yùn)營商融合通信業(yè)務(wù)基于GSMA RCS標(biāo)準(zhǔn)構(gòu)建，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個(gè)階段，從RCS 1到RCS 5.2，標(biāo)準(zhǔn)規(guī)范所定義的功能越來越豐富，有效地?cái)U(kuò)展了運(yùn)營商的基本電信業(yè)務(wù)范疇，有利于運(yùn)營商向用戶提供更多業(yè)務(wù)。RCS被認(rèn)為是運(yùn)營商應(yīng)對OTT競爭的重要抓手，備受全球運(yùn)營商、設(shè)備商、終端廠商的關(guān)注，多家國際運(yùn)營商已實(shí)現(xiàn)RCS產(chǎn)品的商用。

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

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

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

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

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

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

（3）與運(yùn)營商已有即時(shí)通信OTT應(yīng)用的關(guān)系

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

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

3 融合通信商用部署關(guān)鍵方案

3.1 技術(shù)路線選擇

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

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

圖1 融合通信技術(shù)路線選擇

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

兩種架構(gòu)的不同在于控制層，具體如下。

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

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

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

3.2 節(jié)點(diǎn)部署架構(gòu)

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

（1）集中建設(shè)獨(dú)立的融合通信IMS

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

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

圖2 融合通信節(jié)點(diǎn)部署方案，獨(dú)立設(shè)置IMS

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

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

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

·各節(jié)點(diǎn)的業(yè)務(wù)劃分：是按用戶號(hào)段分區(qū)、用戶行政歸屬分區(qū)，還是全局負(fù)荷分擔(dān)。

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

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

·多節(jié)點(diǎn)容災(zāi)方案：節(jié)點(diǎn)之間應(yīng)具備異地容災(zāi)能力，單節(jié)點(diǎn)出現(xiàn)故障時(shí)，可由其他節(jié)點(diǎn)接管業(yè)務(wù)。

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

3.3 融合通信與運(yùn)營商自有OTT整合

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

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

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

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

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

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

圖4 融合通信與OTT互通

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

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

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

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

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

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

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

·將原有OTT平臺(tái)改造為基于IMS的標(biāo)準(zhǔn)RCS架構(gòu)，該方案改造量較大，基本與完全替換相同。

3.4 與其他運(yùn)營商互通

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

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

運(yùn)營商需要分別建設(shè)互通網(wǎng)關(guān)，通過互通網(wǎng)關(guān)實(shí)現(xiàn)SIP、MSRP、RTP及XCAP的互通，其中IBCF負(fù)責(zé)信令面互通，TrGW負(fù)責(zé)媒體面互通。互通網(wǎng)關(guān)應(yīng)具備以下功能。

·安全及管理功能：信令加密、拓?fù)潆[藏、計(jì)費(fèi)結(jié)算。

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

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

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

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

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

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

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

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

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

圖5 基于IMS的互通架構(gòu)

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

在其他運(yùn)營商未部署IMS或RCS業(yè)務(wù)的情況下，只能通過現(xiàn)網(wǎng)短信互通網(wǎng)關(guān)實(shí)現(xiàn)短消息互通?；ネ軜?gòu)如圖6所示。

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

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

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

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

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

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

4 融合通信開通和計(jì)費(fèi)應(yīng)考慮的問題

4.1 業(yè)務(wù)開通

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

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

4.2 計(jì)費(fèi)

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

5 結(jié)束語

微信等OTT業(yè)務(wù)超常規(guī)爆發(fā)增長，嚴(yán)重沖擊基礎(chǔ)語音和短信業(yè)務(wù)。融合通信作為“基礎(chǔ)通信升級”，是運(yùn)營商應(yīng)對OTT競爭的重要抓手。但目前融合通信的大部分業(yè)務(wù)功能均與OTT應(yīng)用類似，在用戶看來可能缺乏創(chuàng)新性，只是把這些業(yè)務(wù)的提供者從互聯(lián)網(wǎng)公司改為運(yùn)營商而已。因而，在RCS部署之后，如何培養(yǎng)用戶習(xí)慣，鼓勵(lì)用戶從OTT應(yīng)用轉(zhuǎn)移到使用RCS上，這是一個(gè)需要解決的問題。RCS相對于OTT的優(yōu)勢之一在于不同運(yùn)營商的網(wǎng)間互通和運(yùn)營商級的質(zhì)量保證，因此需要眾多運(yùn)營商的積極參與，才能形成規(guī)模優(yōu)勢，有效應(yīng)對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è)務(wù)與OTT業(yè)務(wù)互通的研究與實(shí)踐[J].電信工程技術(shù)與標(biāo)準(zhǔn)化，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]李勇輝,呂光旭,符剛,等.電信運(yùn)營商RCS部署建議[J].郵電設(shè)計(jì)技術(shù)，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.