VoLTE多廠商組網(wǎng)方案

邱巍，馮征，吳倩

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

1 引言

隨著4G牌照的發(fā)放，各運營商在加快4G網(wǎng)絡建設的同時，開始考慮部署4G語音業(yè)務的目標解決方案——VoLTE，VoLTE商用網(wǎng)絡的部署也提上了日程。VoLTE方案的部署涉及網(wǎng)絡各層面，復雜度較高，其中IMS核心網(wǎng)的建設至關(guān)重要，本文對部署VoLTE后，省內(nèi)IMS核心網(wǎng)異廠商組網(wǎng)方案進行了研究，并分析了多種組網(wǎng)方案，為VoLTE實際部署提供了參考。

2 VoLTE部署后IMS網(wǎng)絡架構(gòu)

由于VoLTE與IMS固網(wǎng)業(yè)務對于IMS核心網(wǎng)I/S/E-CSCF/BGCF功能基本相同，因此本文將以IMS核心網(wǎng)控制面采用融合組網(wǎng)方式建設的場景進行分析，以某運營商網(wǎng)絡為例，其組網(wǎng)架構(gòu)如圖1所示。

VoLTE商用后，該運營商4G網(wǎng)絡將由無線網(wǎng)絡（E-UTRAN）、分組域核心網(wǎng)、IMS核心網(wǎng)、電路域核心網(wǎng)（eMSC）、業(yè)務平臺等組成。其中IMS核心網(wǎng)負責VoLTE會話路由、業(yè)務觸發(fā)，IMS業(yè)務平臺負責為VoLTE用戶提供基礎業(yè)務和增值業(yè)務。總體設置原則為：

·控制層實現(xiàn)融合組網(wǎng)，同時滿足VoLTE用戶和固網(wǎng)用戶需求；

·功能差別較大的業(yè)務層和接入層，獨立建設VoLTE AS和VoLTE SBC滿足VoLTE用戶需求，現(xiàn)有固網(wǎng)SBC和業(yè)務平臺滿足固定用戶需求；

圖1 某運營商VoLTE部署后IMS組網(wǎng)架構(gòu)

·由于存儲的用戶數(shù)據(jù)有所不同，為避免支撐系統(tǒng)額外改造，現(xiàn)階段三融合HLR/HSS與固網(wǎng)IMS HSS分設。

3 組網(wǎng)方案

3.1 總體原則

為便于全網(wǎng)統(tǒng)一管理，建議各省采用單域組網(wǎng)，以某運營商為例，VoLTE用戶呼叫時的用戶域名為省名縮寫.ims.mnc.mcc.3gppnetwork.org。本文方案分析基于上述原則。

3.2 VoLTE AS組網(wǎng)方案

VoLTE AS采用全省集中設置的方式，同時考慮到該網(wǎng)元的重要性及網(wǎng)元特性，建議VoLTE AS采用組pool的方式實現(xiàn)容災。由于異廠商透明數(shù)據(jù)格式有差異，當省內(nèi)有多廠商VoLTE AS時，pool內(nèi)VoLTE AS應為同廠商設備。用戶開通時，需要在用戶簽約數(shù)據(jù)中標識用戶歸屬VoLTE AS pool的信息。

3.3 I/S-CSCF多廠商組網(wǎng)方案

VoLTE用戶基本注冊流程中，VoLTE SBC/P-CSCF以通用域名（ims.mnc.mcc.3gppnetwork.org）查詢DNS尋址到本省I-CSCF。I-CSCF根據(jù)用戶歸屬HSS返回的“能力集”，選擇用戶歸屬域（省）S-CSCF。

VoLTE用戶基本呼叫流程中，主叫S-CSCF根據(jù)被叫SIP URI的Realm尋址被叫域I-CSCF（對于Tel URI，S-CSCF需請求ENUM解析）。I-CSCF向HSS查詢，獲得被叫“注冊”的S-CSCF。

3.3.1 I-CSCF組網(wǎng)方案

在省內(nèi)有多廠商I-CSCF時，可有以下兩個方案：方案一，全省I-CSCF組成一個pool；方案二，I-CSCF按照片區(qū)組成不同的pool，如圖2所示。

圖2 I-CSCF組網(wǎng)方案

根據(jù)業(yè)務流程，注冊和呼叫流程中尋址I-CSCF均是根據(jù)I-CSCF的域名進行的，在目前省內(nèi)單域組網(wǎng)情況下，根據(jù)域名無法區(qū)分不同廠商片區(qū)的I-CSCF。因此在采用方案二時，需要在IMS DNS開啟視圖功能，注冊過程中IMS DNS根據(jù)發(fā)起請求的P-CSCF的地址選擇同片區(qū)的I-CSCF，省內(nèi)用戶間呼叫時也可以根據(jù)主叫S-CSCF的地址選擇同片區(qū)的I-CSCF，省間呼叫時則由主叫S-CSCF根據(jù)被叫的統(tǒng)一歸屬省域名輪選被叫歸屬省內(nèi)任意I-CSCF。由于I-CSCF選擇用戶歸屬S-CSCF時，是根據(jù)用戶簽約的能力集進行選擇，因此在用戶發(fā)生跨片區(qū)漫游時，仍會出現(xiàn)I-CSCF訪問另一片區(qū)的S-CSCF的場景。如圖3所示，用戶1為片區(qū)1用戶，用戶2從片區(qū)1漫游到片區(qū)2，此時用戶2會從片區(qū)1的I-CSCF路由至用戶歸屬的片區(qū)2的S-CSCF。

考慮開啟視圖功能會對DNS設備性能有一定影響，省內(nèi)網(wǎng)絡調(diào)整或增加網(wǎng)元時均需要調(diào)整相應配置數(shù)據(jù)，增加了局數(shù)據(jù)的復雜度。因此建議無論省內(nèi)I-CSCF為幾個廠商設備，全省多套I-CSCF組成一個I-CSCF pool。

3.3.2 S-CSCF組網(wǎng)方案

S-CSCF組網(wǎng)有以下兩個方案。

（1）方案一

I/S-CSCF均以省為單位組pool，pool內(nèi)可為不同廠商的設備，如圖4所示。

I/S-CSCF為全省統(tǒng)一規(guī)劃，有利于提高設備利用率和簡化數(shù)據(jù)配置復雜度。ISC接口需要異廠商交互。

圖3 跨片區(qū)漫游時路由

圖4 S-CSCF組網(wǎng)方案一

具體實現(xiàn)機制：省內(nèi)多套S-CSCF組成一個pool，劃分一個能力集。用戶注冊時I-CSCF根據(jù)本地配置的S-CSCF能力集與S-CSCF pool的對應關(guān)系選擇用戶歸屬的S-CSCF pool，再通過查詢IMS ENUM/DNS實現(xiàn)用戶負荷分擔，選擇pool內(nèi)的S-CSCF。省內(nèi)多套I-CSCF（與S-CSCF合設）組成一個pool，IMS DNS分擔負荷，選擇pool內(nèi)任意I-CSCF。

數(shù)據(jù)配置要求：全省應僅存在一個S-CSCF能力集信息。用戶簽約時配置此S-CSCF能力集，由S-CSCF pool內(nèi)各S-CSCF分擔疏通業(yè)務。

（2）方案二

同一省內(nèi)按片區(qū)組S-CSCF pool，如圖5所示。根據(jù)用戶規(guī)模、維護管理、ISC接口調(diào)測復雜度等因素，將同廠商S-CSCF放 在 同 一pool中，即 廠 商1的S-CSCF組 成S-CSCF pool1，負責區(qū)域1；廠商2的S-CSCF組成S-CSCF pool2，負責區(qū)域2。省內(nèi)多套I-CSCF（與S-CSCF合設）以省為單位組pool。

圖5 S-CSCF組網(wǎng)方案二

此方案將同廠商的VoLTE AS和S-CSCF劃分在同一區(qū)域，以減少異廠商ISC接口的兼容性風險。

方案二的數(shù)據(jù)配置：在IMS HSS配置用戶數(shù)據(jù)時，VoLTE AS pool1片區(qū)的用戶簽約S-CSCF pool1對應的S-CSCF能力集，VoLTE AS pool2片區(qū)的用戶簽約S-CSCF pool2對應的S-CSCF能力集。可實現(xiàn)S-CSCF pool1僅訪問VoLTE AS pool1，S-CSCF pool2僅訪問VoLTE AS pool2，即可實現(xiàn)僅存在同廠商S-CSCF與AS間ISC接口互通的需求。方案比較和分析見表1。

上述兩個方案廠商均支持，考慮目前異廠商ISC接口的兼容性較差，建議在VoLTE建設初期引入多廠商時，可按照方案二進行組網(wǎng)。

3.4 VoLTE SBC組網(wǎng)方案

IMS APN在國內(nèi)漫游時，采用漫游地SAE-GW接入方式，即根據(jù)用戶漫游地，就近接入漫游地的SAE-GW。由PGW根據(jù)本地預先配置的本省VoLTE SBC/P-CSCF的IP地址列表，向終端返回VoLTE SBC/P-CSCF的IP地址。終端根據(jù)獲得的VoLTE SBC/P-CSCF的IP地址，接入VoLTE SBC/P-CSCF。VoLTE SBC/P-CSCF以通用域名查詢DNS尋址到本省I-CSCF，后續(xù)同核心網(wǎng)路由。對于省內(nèi)設置的多套VoLTE SBC/P-CSCF設備，組網(wǎng)方案見表2。

表1 方案比較和分析

表2 VoLTE SBC組網(wǎng)方案

按照表2中的場景劃分，方案分析如下。

（1）方案一

全省VoLTE SBC/P-CSCF組一個pool，采用負荷分擔方式疏通本省業(yè)務。在此方案中，根據(jù)SAE-GW組pool方案，有SAE-GW組一個pool和SAE-GW分片區(qū)組pool兩種場景，如圖6所示。

此方案無論場景一還是場景二，所有PGW均配置VoLTE SBC pool內(nèi)所有SBC的地址信息，PGW與VoLTE SBC pool內(nèi)所有VoLTE SBC均有可能交互。當PGW、VoLTE SBC不在一個城市時，會涉及省內(nèi)長途。

（2）方案二

全省VoLTE SBC/P-CSCF分區(qū)域組pool。同樣根據(jù)SAE-GW組pool的方案，本方案中SAE-GW與VoLTE SBC的互通有以下兩個場景。

場 景 一：SAE-GW組 一 個pool。根 據(jù)SAE-GW設 置局址和接口要求，PGW設置其中某個VoLTE SBC pool內(nèi)SBC的地址信息。此方案在PGW與其接入的VoLTE SBC為同廠商時，可實現(xiàn)同廠商SGi接口互通，如圖7所示。

圖7 VoLTE SBC組網(wǎng)方案二（場景一）

場景二：SAE-GW分區(qū)域組pool。根據(jù)SAE-GW設置局址和接口要求，PGW配置其中某個VoLTE SBC pool內(nèi)SBC的地址信息。為避免路由迂回，建議SAE-GW就近接入本地VoLTE SBC pool，如圖8所示。

對于用戶漫游的場景，如圖9所示，用戶1漫游至片區(qū)2開機注冊，將經(jīng)由漫游地的SAE-GW和VoLTE SBC接入核心網(wǎng)。

對于用戶開機漫游到片區(qū)2的場景，按照目前各省分組域的路由要求，將仍由用戶初始注冊的PGW接入IMS網(wǎng)絡。

根據(jù)上述分析，按照注冊和呼叫流程，VoLTE SBC的分區(qū)與CSCF的分區(qū)無直接相關(guān)性。由于SBC負責媒體面的連接，為減少媒體面路由迂回和長途傳輸?shù)恼加茫ㄗhVoLTE SBC靠近SAE-GW設置，SAE-GW就近接入本地VoLTE SBC pool。

3.5 VoLTE PCRF組網(wǎng)方案

在用戶IMS APN承載建立過程中，LDRA將PGW的Gx接口信令消息負荷分擔地路由至省內(nèi)支持VoLTE功能的PCRF pool內(nèi)的任意PCRF。LDRA記錄并保存用戶IP地址與PCRF地址的綁定關(guān)系，并將此信息同步到配對的另一個LDRA。VoLTE呼叫時，P-CSCF通過Rx接口指示PCRF（通過1對DRA負荷分擔）為VoLTE用戶建立“專用承載”，LDRA收 到VoLTE SBC/P-CSCF發(fā)送的Rx接 口 信令消息，根據(jù)Rx接口信令消息中的用戶IP地址，查詢自身所保存的用戶IP地址與PCRF的綁定關(guān)系記錄，將Rx接口信令消息轉(zhuǎn)發(fā)至對應的PCRF。

方案一：全省組一個VoLTE PCRF pool，如圖10所示。

方案二：全省分區(qū)域組VoLTE PCRF pool。LDRA對于IMS APN應首先根據(jù)源（PGW）主機名尋址到對應的VoLTE PCRF pool，再在VoLTE PCRF pool內(nèi)進行負荷分擔地選擇PCRF，如圖11所示。

方案二要求LDRA對于IMS APN首先根據(jù)源主機名尋址到對應的VoLTE PCRF pool，再在VoLTE PCRF pool內(nèi)進行負荷分擔地選擇PCRF，LDRA數(shù)據(jù)配置復雜，建議慎重啟用。

圖8 VoLTE SBC組網(wǎng)方案二（場景二）

圖9 VoLTE SBC組網(wǎng)方案二（漫游路由）

圖10 VoLTE PCRF組網(wǎng)方案一

圖11 VoLTE PCRF組網(wǎng)方案二

4 結(jié)束語

在VoLTE網(wǎng)絡實際部署中，需要根據(jù)各個網(wǎng)元的設置以及路由原則確定具體的部署方式。根據(jù)本文分析，在VoLTE網(wǎng)絡建設初期，多廠商組網(wǎng)方案的總體編制原則如下。

·遵循運營商統(tǒng)一制定的網(wǎng)絡路由組織及碼號等局數(shù)據(jù)原則。

·網(wǎng)絡組織應兼顧遠期發(fā)展和演進需求，盡量避免后續(xù)擴容時網(wǎng)絡架構(gòu)的大規(guī)模調(diào)整。

·由于IMS網(wǎng)絡架構(gòu)的復雜度和與周邊網(wǎng)元交互較多，在進行網(wǎng)絡規(guī)劃時應綜合分析評估與所有網(wǎng)元的互通方案、路由組織、對周邊網(wǎng)元的影響等，合理編制組網(wǎng)方案。

·簡化各網(wǎng)元的局數(shù)據(jù)配置，使網(wǎng)元的選路原則盡量簡單和高效。

·對于省內(nèi)接口，可通過同廠商設備同覆蓋區(qū)的方式實現(xiàn)同廠商接口，以降低異廠商IOT的風險。

[1]IP Multimedia Subsystem(IMS):3GPP TS 23.228 V13.0.0:2014[S/OL].[2014-09-22].http://www.3gpp.org/DynaReport/23228.htm.