基于智能管道引擎的網(wǎng)絡(luò)能力開放研究

林奕琳，張琳峰，王慶揚，蔡 康

（中國電信股份有限公司廣東研究院 廣州 510630）

1 引言

近年來智能終端的普及極大地推動了移動互聯(lián)網(wǎng)的發(fā)展，工業(yè)和信息化部運行監(jiān)測協(xié)調(diào)局發(fā)布的數(shù)據(jù)顯示，2013年第一季度，全國移動互聯(lián)網(wǎng)接入流量達(dá)到27 316.0萬GB，同比增長56.5%，且已連續(xù)3個月增長率超過50%，移動互聯(lián)網(wǎng)接入流量呈爆發(fā)式增長趨勢。但另一方面，運營商收入增速卻遠(yuǎn)小于流量增速，運營商面臨被管道化的趨勢。推動網(wǎng)絡(luò)管道智能化，開展流量經(jīng)營，積極探索商業(yè)模式創(chuàng)新，是運營商應(yīng)對這一趨勢的積極方式。本文針對智能管道的一個方面，從管道能力向應(yīng)用開放，支持后向業(yè)務(wù)保障的角度，研究了基于智能管道引擎實現(xiàn)固移融合管道能力開放的架構(gòu)和技術(shù)方案。

2 移動和固定寬帶網(wǎng)絡(luò)策略控制體系

在移動寬帶網(wǎng)絡(luò)中，通過PCC（policy and charging control，策略與計費控制）架構(gòu)可實現(xiàn)智能化的策略和計費控制，應(yīng)用功能（AF）服務(wù)器可通過Rx接口向PCRF（policy and charging rules function，策略和計費規(guī)則功能）提出業(yè)務(wù)QoS保障需求，PCRF通過與網(wǎng)絡(luò)承載網(wǎng)元交互，實現(xiàn)對應(yīng)用的帶寬保障、資源優(yōu)先級保障等服務(wù)。PCC架構(gòu)如圖1所示，圖中PCRF為移動網(wǎng)策略控制系統(tǒng)，PCEF（policy and changing enforcement fuction,策略和計費執(zhí)行功能）為策略執(zhí)行網(wǎng)元，一般部署在核心網(wǎng)網(wǎng)關(guān)中，如LTE網(wǎng)絡(luò)的PGW、HRPD網(wǎng)絡(luò)中的PDSN、eHRPD網(wǎng)絡(luò)中的HSGW等。

圖1 移動網(wǎng)PCC架構(gòu)

在實際部署時，PCRF網(wǎng)元一般為分省設(shè)置，第三方應(yīng)用服務(wù)器需要與各省PCRF對接，部署難度較大，另外Rx接口采用的是Diameter協(xié)議，而不是互聯(lián)網(wǎng)應(yīng)用常用的Web Services協(xié)議，不利于規(guī)模推廣部署。

在固定寬帶網(wǎng)絡(luò)中，應(yīng)用通過與固網(wǎng)策略控制系統(tǒng)（DACS）交互，發(fā)起對業(yè)務(wù)的保障請求，固網(wǎng)策略控制系統(tǒng)根據(jù)用戶簽約情況，與寬帶承載網(wǎng)網(wǎng)元交互，實現(xiàn)對用戶的提速功能，提升用戶業(yè)務(wù)使用體驗。固網(wǎng)策略控制系統(tǒng)架構(gòu)如圖2所示。與移動網(wǎng)類似，固網(wǎng)策略控制系統(tǒng)一般為分省設(shè)置，應(yīng)用需要與多個系統(tǒng)對接，增加了規(guī)模推廣部署的難度。

圖2 固網(wǎng)策略控制系統(tǒng)架構(gòu)

3 固移融合管道能力開放架構(gòu)

3.1 系統(tǒng)架構(gòu)

為了解決上述移動寬帶和固定寬帶網(wǎng)絡(luò)策略控制系統(tǒng)在后向業(yè)務(wù)保障方面的不足，本文提出了基于智能管道引擎的固移融合管道能力開放架構(gòu)，如圖3所示。通過在網(wǎng)絡(luò)中引入智能管道引擎，向應(yīng)用提供統(tǒng)一的網(wǎng)絡(luò)能力開放接口，對應(yīng)用屏蔽網(wǎng)絡(luò)內(nèi)部架構(gòu)，應(yīng)用只需要“一點接入”，即可面向全網(wǎng)用戶提供差異化的網(wǎng)絡(luò)資源保障服務(wù)。智能管道南向與固網(wǎng)和移動網(wǎng)策略控制系統(tǒng)對接，接口采用策略控制系統(tǒng)現(xiàn)有北向接口。

智能管道引擎主要包括以下主要功能。

圖3 固移融合管道能力開放架構(gòu)

·會話管理：主要提供會話創(chuàng)建管理、會話邏輯控制、會話狀態(tài)維護(hù)等功能。

·業(yè)務(wù)控制：主要提供準(zhǔn)入策略控制、固移路由控制、PCRF路由控制、DACS路由控制、話單控制等功能。

·狀態(tài)管理：主要提供用戶狀態(tài)管理和網(wǎng)絡(luò)狀態(tài)管理功能。

·接口管理：主要包括網(wǎng)元接口管理及適配功能、應(yīng)用接口管理及適配功能，其中網(wǎng)元接口管理及適配包括與DACS的接口、與PCRF的接口，應(yīng)用接口管理及適配主要包括應(yīng)用平臺API的管理及適配功能。

·系統(tǒng)配置管理：主要提供權(quán)限配置、策略配置、網(wǎng)元配置等功能。

·統(tǒng)計報表管理及查詢：主要提供用戶準(zhǔn)入策略信息、業(yè)務(wù)話單等信息的查詢，提供業(yè)務(wù)資源保障能力調(diào)用情況統(tǒng)計等功能。

·監(jiān)控與告警管理及查詢：主要提供接口監(jiān)控、系統(tǒng)監(jiān)控、業(yè)務(wù)監(jiān)控功能。

3.2 關(guān)鍵技術(shù)

3.2.1 路由選擇方案

SPE收到來自應(yīng)用的業(yè)務(wù)保障請求時，需區(qū)分用戶來自固定網(wǎng)還是移動網(wǎng)，從而確定將QoS保障指示下發(fā)給DACS還是PCRF。根據(jù)應(yīng)用平臺所能獲取的用戶信息不同，具體有以下兩種方案確定用戶類型：

·根據(jù)所攜帶的用戶標(biāo)識類型，確定用戶類型，如業(yè)務(wù)保障請求中攜帶了用戶IMSI，則可確定用戶為移動網(wǎng)用戶；

·根據(jù)用戶IP地址段，確定用戶類型，一般運營商對固網(wǎng)和移動網(wǎng)用戶會分配不同的IP地址段，根據(jù)用戶IP地址，可進(jìn)行區(qū)分。為支持各種不同場景，SPE應(yīng)同時支持上述兩種方式。除了確定用戶接入網(wǎng)絡(luò)類型外，當(dāng)SPE同時與多個DACS或PCRF對接時，還應(yīng)能將相應(yīng)的QoS保障指示下發(fā)給為用戶服務(wù)的具體DACS或PCRF。

由于一般情況下，特定的DACS所服務(wù)的區(qū)域內(nèi)IP地址段是確定，因此SPE可根據(jù)IP地址確定用戶歸屬的DACS。但對于PCRF的路由選擇，SPE選擇PCRF的方式應(yīng)與Gx接口中PCEF選擇PCRF的路由選擇方式一致。具體有如下幾種方案。

·DRA （Diameter routing agent，Diameter路由代理）方案：當(dāng)網(wǎng)絡(luò)中部署了DRA，PCEF通過DRA為用戶選擇服務(wù)PCRF，則SPE也應(yīng)直接將消息發(fā)送給DRA系統(tǒng)，由DRA完成PCRF的選擇并將消息路由到具體的服務(wù)PCRF。

·IMSI號段方案：當(dāng)網(wǎng)絡(luò)中未部署DRA且部署了多臺PCRF時，如果PCEF也采用了IMSI號段方案選擇PCRF，SPE在能夠獲得用戶IMSI的場景下，也應(yīng)通過IMSI號段方案進(jìn)行PCRF的選擇。

·IP地址段方案：當(dāng)PCRF分區(qū)域為用戶提供服務(wù)，各區(qū)域的用戶IP地址段不重疊的情況下，SPE可根據(jù)用戶IP地址段選擇合適的PCRF。

3.2.2 PCRF的Rx與Gx會話關(guān)聯(lián)方案在PCRF中，一般情況下通過用戶IP地址實現(xiàn)用戶的Rx會話與Gx會話的關(guān)聯(lián)，但由于在網(wǎng)絡(luò)具體部署時，一般情況下網(wǎng)關(guān)（如PGW）為用戶分配的為私網(wǎng)IP地址，而應(yīng)用平臺看到的用戶IP地址為經(jīng)過NAT后的公網(wǎng)IP地址，同時不同省份間的私網(wǎng)IP地址也可能存在復(fù)用的情況，導(dǎo)致為不同用戶分配相同的私網(wǎng)IP地址。上述兩種情況都會導(dǎo)致對于同一個會話，PCRF在Rx接口和Gx接口看到的用戶IP地址不一致，從而無法實現(xiàn)會話關(guān)聯(lián)。對于該問題，目前主要有以下解決方案：

·應(yīng)用平臺通過與應(yīng)用客戶端的信令交互，從客戶端獲得網(wǎng)關(guān)為用戶實際分配的私網(wǎng)IP地址，并在Rx接口中傳遞給PCRF，從而解決NAT帶來的問題；

·應(yīng)用平臺通過與應(yīng)用客戶端的信令交互，從客戶端獲得用戶的IMSI，并在Rx接口中傳遞給PCRF，PCRF通過IMSI和IP地址實現(xiàn)會話關(guān)聯(lián)；

·當(dāng)應(yīng)用平臺或SPE分省部署時，可以在Rx接口中增加服務(wù)域標(biāo)識，PCRF通過服務(wù)于標(biāo)識和IP地址實現(xiàn)會話關(guān)聯(lián)，從而解決不同省用戶私網(wǎng)IP地址重復(fù)的問題。

3.3 業(yè)務(wù)保障流程

基于智能管道引擎的固移融合管道能力開放架構(gòu)的主要功能之一，即是實現(xiàn)對應(yīng)用的后向資源保障。移動網(wǎng)絡(luò)接入情況下，利用該架構(gòu)實現(xiàn)業(yè)務(wù)后向資源保障的流程如圖4所示，具體說明如下：

圖4 移動寬帶網(wǎng)后向業(yè)務(wù)資源保障流程

（1）用戶接入移動網(wǎng)絡(luò)網(wǎng)絡(luò)，并建立會話，網(wǎng)絡(luò)中PCEF與PCRF交互建立Gx會話；

（2）用戶開始使用業(yè)務(wù)；

（3）業(yè)務(wù)平臺調(diào)用智能管道引擎能力API，向智能管道引擎發(fā)送業(yè)務(wù)保障請求，消息中包含用戶信息、業(yè)務(wù)信息、QoS信息；

（4）智能管道引擎根據(jù)上述信息判斷用戶為移動網(wǎng)絡(luò)接入，同時確定用戶所屬服務(wù)PCRF；

（5）智能管道引擎將業(yè)務(wù)保障請求進(jìn)行協(xié)議轉(zhuǎn)換，向所屬服務(wù)PCRF發(fā)送Diameter AAR消息，并在AAR消息中通過specific-action AVP訂購相應(yīng)的事件通知；

（6）PCRF存儲業(yè)務(wù)信息，判斷所屬的Gx會話；

（7）PCRF針對請求檢查簽約信息，識別相關(guān)的IP地址流，關(guān)聯(lián)用戶的Gx會話，與BBERF/PCRF交互，修改用戶QoS，進(jìn)行QoS授權(quán)，并向智能管道引擎發(fā)送Diameter AAA響應(yīng)消息；

（8）資源分配成功后，PCRF通過Diameter RAR消息上報給智能管道引擎；

（9）智能管道引擎在收到Diameter RAR消息后，向PCRF發(fā)送Diameter RAA響應(yīng)；

（10）智能管道引擎向應(yīng)用發(fā)送業(yè)務(wù)保障響應(yīng)，指示業(yè)務(wù)保障結(jié)果，并在響應(yīng)消息中攜帶業(yè)務(wù)保障關(guān)聯(lián)ID；

（11）用戶結(jié)束使用業(yè)務(wù)；

（12）業(yè)務(wù)平臺調(diào)用智能管道引擎API，向智能管道引擎發(fā)送業(yè)務(wù)保障撤銷請求，包括對應(yīng)用戶標(biāo)識、業(yè)務(wù)保障關(guān)聯(lián)ID等；

（13）智能管道提取業(yè)務(wù)保障關(guān)聯(lián)ID，判斷用戶為移動網(wǎng)接入，確認(rèn)歸屬的服務(wù)PCRF；

（14）智能管道引擎進(jìn)行協(xié)議適配，向服務(wù)PCRF發(fā)送Diameter STR消息；

（15）PCRF存儲業(yè)務(wù)信息，判斷所屬Gx會話等；

（16）PCRF針對請求檢查簽約信息，識別相關(guān)的IP流，關(guān)聯(lián)用戶的Gx會話，與BBERF/PCRF交互，刪除相應(yīng)QoS規(guī)則，向智能管道引擎發(fā)送Diameter STA響應(yīng)；

（17）智能管道引擎接收到從PCRF發(fā)送的響應(yīng)后，向業(yè)務(wù)平臺發(fā)送業(yè)務(wù)保障撤銷響應(yīng)，指示業(yè)務(wù)保障撤銷結(jié)果。

固網(wǎng)寬帶接入情況下，利用該架構(gòu)實現(xiàn)業(yè)務(wù)后向資源保障的流程如圖5所示，說明如下：

（1）用戶接入固網(wǎng)寬帶，并建立會話；

（2）用戶開始使用業(yè)務(wù)；

（3）業(yè)務(wù)平臺調(diào)用智能管道引擎API，向智能管道引擎發(fā)送業(yè)務(wù)保障請求，消息中包含用戶信息、業(yè)務(wù)信息、QoS信息；

圖5 固定寬帶網(wǎng)后向業(yè)務(wù)資源保障流程

（4）智能管道引擎根據(jù)上述信息判斷用戶為固網(wǎng)寬帶接入，同時判讀用戶所屬服務(wù)固網(wǎng)策略控制系統(tǒng)；

（5）智能管道引擎將業(yè)務(wù)保障請求進(jìn)行協(xié)議轉(zhuǎn)換，向所屬服務(wù)固網(wǎng)策略控制系統(tǒng)下發(fā)保障服務(wù)策略；

（6）固網(wǎng)策略控制系統(tǒng)針對請求檢查簽約信息，與寬帶承載網(wǎng)交互，下發(fā)保障業(yè)務(wù)策略；

（7）固網(wǎng)策略控制系統(tǒng)向智能管道引擎發(fā)送服務(wù)策略響應(yīng)，指示策略保障結(jié)果；

（8）智能管道引擎向業(yè)務(wù)平臺發(fā)送業(yè)務(wù)保障響應(yīng)，指示業(yè)務(wù)保障結(jié)果，并在響應(yīng)消息中攜帶業(yè)務(wù)保障關(guān)聯(lián)ID；

（9）用戶結(jié)束使用業(yè)務(wù)；

（10）業(yè)務(wù)平臺調(diào)用智能管道引擎API，向智能管道引擎發(fā)送業(yè)務(wù)保障撤銷請求，包括對應(yīng)用戶標(biāo)識、業(yè)務(wù)保障關(guān)聯(lián)ID等；

（11）智能管道提取業(yè)務(wù)保障關(guān)聯(lián)ID，判斷用戶為固網(wǎng)寬帶接入，確認(rèn)所屬服務(wù)固網(wǎng)策略保障系統(tǒng)；

（12）智能管道引擎進(jìn)行協(xié)議適配，向固網(wǎng)策略保障系統(tǒng)發(fā)送撤銷保障服務(wù)策略消息；

（13）固網(wǎng)策略保障系統(tǒng)與寬帶承載網(wǎng)交互，恢復(fù)原有業(yè)務(wù)策略；

（14）固網(wǎng)策略保障系統(tǒng)向智能管道引擎發(fā)送撤銷服務(wù)策略響應(yīng)，指示撤銷結(jié)果；

（15）智能管道引擎向業(yè)務(wù)平臺發(fā)送業(yè)務(wù)保障撤銷響應(yīng)，指示業(yè)務(wù)保障撤銷結(jié)果。

3.4 應(yīng)用場景

基于本文提出的架構(gòu)，可以便捷地實現(xiàn)對固移融合應(yīng)用的網(wǎng)絡(luò)資源保障。本節(jié)列出了基于智能管道引擎實現(xiàn)融合視頻會議應(yīng)用保障的案例，具體流程如圖6所示。在本案例中，會議建立成功或邀請會議參與者成功時，會議應(yīng)用服務(wù)器將觸發(fā)業(yè)務(wù)保障請求，對會議主席和參與者進(jìn)行業(yè)務(wù)保障，且業(yè)務(wù)保障結(jié)果會提示會議主席。會議結(jié)束或會議參與者退出會議時，會議服務(wù)器將觸發(fā)業(yè)務(wù)保障撤銷請求，此外，會議應(yīng)用服務(wù)器在將相關(guān)請求送往智能管道引擎過程中，需要經(jīng)過業(yè)務(wù)網(wǎng)和IT系統(tǒng)相關(guān)網(wǎng)元，完成能力調(diào)用權(quán)限的認(rèn)證以及計費等功能，限于文章篇幅，對具體流程不做詳細(xì)闡述。

4 結(jié)束語

本文提出的基于智能管道引擎的固移融合管道能力開放架構(gòu)，通過在網(wǎng)絡(luò)中引入智能管道引擎，實現(xiàn)對移動寬帶和固網(wǎng)寬帶網(wǎng)絡(luò)資源保障能力的統(tǒng)一封裝和向應(yīng)用的開放。智能管道引擎主要實現(xiàn)能力封裝、協(xié)議適配、路由管理等功能，同時負(fù)責(zé)與應(yīng)用的對接，而移動網(wǎng)、固網(wǎng)策略控制系統(tǒng)不需要與每個應(yīng)用直接對接，主要實現(xiàn)各自網(wǎng)絡(luò)的策略控制，使得網(wǎng)元或系統(tǒng)間層次清晰，分工明確，符合運營商網(wǎng)絡(luò)架構(gòu)需求。

圖6 融合視頻會議業(yè)務(wù)資源保障流程

本架構(gòu)的原型已經(jīng)在實驗室實現(xiàn)并進(jìn)行測試，證明了該體系架構(gòu)的可實施性，能夠?qū)崿F(xiàn)對第三方應(yīng)用的后向資源保障，有助于運營商與第三方應(yīng)用提供商合作，實現(xiàn)商業(yè)模式的創(chuàng)新。

1 3GPP TS23.203.Policy and Charging Control Architecture，2013

2 3GPP TS29.212.Policy and Charging Control(PCC)over Gx/Sd Reference Point，2013

3 3GPP TS29.213.Policy and Charging Control Signaling Flows and Quality of Service(QoS)Parameter Mapping，2013

4 3GPP TS29.214.Policy and Charging Control over Rx Reference Point，2013