趙文賢 劉小華 黃琳

摘要：通過分析永遠(yuǎn)在線業(yè)務(wù)對移動網(wǎng)絡(luò)帶來的問題，創(chuàng)新性地從網(wǎng)絡(luò)系統(tǒng)角度提出了一種移動網(wǎng)絡(luò)對永遠(yuǎn)在線業(yè)務(wù)的服務(wù)機(jī)制。該機(jī)制基于策略及計費(fèi)控制（PCC）架構(gòu)，由永遠(yuǎn)在線業(yè)務(wù)服務(wù)器通知PCC系統(tǒng)對該永遠(yuǎn)在線業(yè)務(wù)流進(jìn)行網(wǎng)絡(luò)地址轉(zhuǎn)換（NAT）保活及承載通道?；羁刂疲源藢?shí)現(xiàn)移動網(wǎng)絡(luò)對永遠(yuǎn)在線業(yè)務(wù)的承載通道及NAT資源的有效保證，降低永遠(yuǎn)在線業(yè)務(wù)對網(wǎng)絡(luò)負(fù)荷的影響，從而提高網(wǎng)絡(luò)的利用率。

關(guān)鍵詞： 永遠(yuǎn)在線；PCC；策略與計費(fèi)規(guī)則功能；端口控制協(xié)議；NAT

Abstract： This paper discribes mobile network problems caused by always-online services. We propose a mechanism for implementing the always-online service in the mobile network， from a network point of view. The mechanism， based on the policy and charging control （PCC） architecture， allows the server to tell the PCC system to implement NAT keep-alive and bearer-channel keep-alive. These guarantee that the bearer channels and network address translation （NAT） resources are available for the always-online service. The mechanism reduces the effect of the service on network load and improves network use.

Key words： always online； PCC； policy and charging rules function（PCRF）； port control protocol （PCP）；NAT

智能終端在全球的快速普及，推動了移動互聯(lián)網(wǎng)時代的真正到來。智能終端以其豐富多彩的應(yīng)用/業(yè)務(wù)吸引了越來越多的用戶加入移動寬帶業(yè)務(wù)（MBB）使用者的行列，這給MBB運(yùn)營商帶來了豐厚收益，但同時也給移動網(wǎng)絡(luò)帶來了新的挑戰(zhàn)。尤其智能終端上的QQ、微博等永遠(yuǎn)在線業(yè)務(wù)對MBB網(wǎng)絡(luò)的資源容量、網(wǎng)元信令處理能力、數(shù)據(jù)轉(zhuǎn)發(fā)帶寬等都造成了極大的影響，MBB網(wǎng)絡(luò)已經(jīng)或正在面臨著因永遠(yuǎn)在線業(yè)務(wù)產(chǎn)生的網(wǎng)絡(luò)信令風(fēng)暴以及網(wǎng)絡(luò)擁塞的一系列問題。

如何解決永遠(yuǎn)在線業(yè)務(wù)帶來的網(wǎng)絡(luò)信令風(fēng)暴及網(wǎng)絡(luò)資源被長期占用的問題，已經(jīng)成為運(yùn)營商緊迫的研究課題。

1 永遠(yuǎn)在線問題分析

造成網(wǎng)絡(luò)擁塞、信令風(fēng)暴主要有下面幾個方面的原因：

（1）PDP自動激活帶來容量壓力

絕大多數(shù)智能終端開機(jī)后自動激活分組報文協(xié)議（PDP），并保持PDP長期在線，以達(dá)到隨時隨地訪問網(wǎng)絡(luò)、獲取實(shí)時信息的目的。智能終端的激活附著比、PDP在線時長等話務(wù)模型指標(biāo)遠(yuǎn)高于普通終端。隨著智能終端滲透率的提高，網(wǎng)絡(luò)PDP數(shù)將快速增長，MBB網(wǎng)絡(luò)將面臨越來越大的容量壓力。

（2）快速休眠產(chǎn)生大量信令需求

大屏幕、長時間連接、多任務(wù)等特性都會消耗大量電能，導(dǎo)致終端待機(jī)時間縮短。為了提供更長的待機(jī)時間，智能終端采用了快速休眠技術(shù)。短時間內(nèi)（通常3 —10 s）沒有數(shù)據(jù)傳輸，智能終端便會自動釋放無線連接，從無線資源連接態(tài)轉(zhuǎn)換到空閑態(tài)，以達(dá)到省電的目的。后續(xù)如有數(shù)據(jù)發(fā)送，必須再次建立無線連接，發(fā)送完畢后又再次釋放。如此周而復(fù)始，則會產(chǎn)生了大量無線連接建立和釋放信令。

（3）應(yīng)用永遠(yuǎn)在線長期占用資源

隨著智能終端的普及，即時通信（IM）、社交網(wǎng)絡(luò)（SNS）等“永遠(yuǎn)在線”應(yīng)用在MBB用戶中迅速流行。應(yīng)用永遠(yuǎn)在線不僅需要長期占用網(wǎng)絡(luò)資源（如無線承載資源、PDP資源和IP資源），更嚴(yán)重的是，這類應(yīng)用的客戶端每隔幾秒或幾分鐘就會向服務(wù)器發(fā)送“心跳消息”以維持其在線狀態(tài)。這種行為將導(dǎo)致無線連接反復(fù)建立和釋放，帶來大量信令負(fù)荷。

為解決網(wǎng)絡(luò)信令風(fēng)暴及網(wǎng)絡(luò)資源被長期占用的問題，目前很多運(yùn)營商都通過施加壓力促使手機(jī)操作系統(tǒng)如Android、iOS修改快速休眠時間，以及促使永遠(yuǎn)在線業(yè)務(wù)應(yīng)用如QQ等減少“心跳”頻率甚至是取消“心跳”檢測消息，但同時會帶來如下的兩個問題：

（1）防火墻業(yè)務(wù)流映射表失效問題（NAT保活）

在運(yùn)營商網(wǎng)絡(luò)中，移動接入網(wǎng)絡(luò)與業(yè)務(wù)網(wǎng)絡(luò)之間存在一個防火墻系統(tǒng)，如圖1所示。如果永遠(yuǎn)在線業(yè)務(wù)取消“心跳”消息，并且在防火墻系統(tǒng)中如果一個業(yè)務(wù)流的轉(zhuǎn)換映射長時間不使用的情況下，防火墻系統(tǒng)則會釋放該映射關(guān)系條目。此后如果業(yè)務(wù)產(chǎn)生下行報文，由于防火墻找不到業(yè)務(wù)流映射表則會丟棄該報文，從而導(dǎo)致業(yè)務(wù)中斷情況。

（2）承載管道長時間無數(shù)據(jù)時釋放問題（承載通道?；睿?/p>

無線網(wǎng)絡(luò)會為業(yè)務(wù)流建立承載通道，比如W3G的 PDP上下文，這些承載自身也有一些保護(hù)措施，比如承載通道中長時間無業(yè)務(wù)流的時候，也會釋放承載通道。同樣，此后如果業(yè)務(wù)產(chǎn)生下行報文時，由于防火墻找不到業(yè)務(wù)流映射表則會丟棄該報文，從而導(dǎo)致業(yè)務(wù)中斷情況。

2 永遠(yuǎn)在線方案分析

通過分析可以發(fā)現(xiàn)，解決網(wǎng)絡(luò)信令風(fēng)暴及網(wǎng)絡(luò)資源被長期占用的問題的關(guān)鍵是解決防火墻業(yè)務(wù)流映射表失效問題（NAT?；睿┖统休d管道長時間無數(shù)據(jù)時釋放問題（承載通道?；睿?，下面將重點(diǎn)分析研究如何解決兩個問題。

（1）防火墻業(yè)務(wù)流映射表失效問題（NAT保活）應(yīng)對分析

系統(tǒng)需要控制防火墻業(yè)務(wù)流映射表?xiàng)l目是否失效。當(dāng)前，Internet工程任務(wù)組（IETF）正在制訂的一個叫端口控制協(xié)議（PCP）的協(xié)議[1]。對于經(jīng)過網(wǎng)絡(luò)地址轉(zhuǎn)換（NAT）或防火墻系統(tǒng)的外部報文，該協(xié)議能夠讓一個IPv4或IPv6主機(jī)控制如何尋找到本機(jī)，以及優(yōu)化NAT映射保持。

在移動網(wǎng)絡(luò)中，移動網(wǎng)關(guān)（GW）如網(wǎng)關(guān) GPRS支持節(jié)點(diǎn)（GGSN）、P-GW在防火墻后面，我們可以通過GW支持PCP客戶端協(xié)議，發(fā)送RCP請求通知NAT設(shè)備或防火墻完成對用戶永遠(yuǎn)在線業(yè)務(wù)流的映射并對該映射保持一定的時長，從而解決防火墻業(yè)務(wù)流映射表失效問題。

（2）承載管道長時間無數(shù)據(jù)時釋放問題（承載通道保活）應(yīng)對分析

系統(tǒng)需要能夠控制業(yè)務(wù)承載通道長時間無數(shù)據(jù)報文而釋放的問題。此時要求控制業(yè)務(wù)流承載通道的GW能夠除維持一個系統(tǒng)的定義時長。

在此時長內(nèi)，GW必須保持承載管道不被釋放。同時這個時長也應(yīng)該與該業(yè)務(wù)流的NAT映射時長相匹配或者相等。

第三代合作伙伴計劃（3GPP）定義了策略及計費(fèi)控制（PCC）[2]。圖2所示為非漫游場景的PCC網(wǎng)絡(luò)架構(gòu)圖。

在此架構(gòu)中，應(yīng)用功能（AF）提供業(yè)務(wù)流信息，并通過Rx接口要求PCC系統(tǒng)對該業(yè)務(wù)流提供業(yè)務(wù)承載網(wǎng)絡(luò)的資源授權(quán)，PCC接收到Rx口的業(yè)務(wù)流承載授權(quán)請求后通過本地規(guī)則生成承載網(wǎng)資源授權(quán)決策并通過Gx口下發(fā)給GW網(wǎng)元進(jìn)行控制。

在永遠(yuǎn)在線業(yè)務(wù)控制中，我們借鑒此架構(gòu)，由AF網(wǎng)絡(luò)感知永遠(yuǎn)在線業(yè)務(wù)，并由AF通知PCC系統(tǒng)對該永遠(yuǎn)在線業(yè)務(wù)流進(jìn)行NAT?；罴俺休d通道?；羁刂疲琍CC則根據(jù)本地?；畈呗陨杀；顩Q策并通過Gx口通告GW，最后再由GW完成前述的PCP NAT及承載管道的?；羁刂?。

3永遠(yuǎn)在線方案及原理

GW支持PCP客戶端控制NAT設(shè)備或者防火墻，對永遠(yuǎn)在線業(yè)務(wù)流所對應(yīng)的IP轉(zhuǎn)換映射關(guān)系保持一定時間，同時GW保持永遠(yuǎn)在線業(yè)務(wù)流所對應(yīng)的承載通道如GTP PDP上下文在對應(yīng)時間內(nèi)不釋放，就可以解決網(wǎng)絡(luò)信令風(fēng)暴及網(wǎng)絡(luò)資源被長期占用的問題。在此基礎(chǔ)上，我們提出了如圖3的架構(gòu)，實(shí)現(xiàn)對永遠(yuǎn)在線業(yè)務(wù)的管控。

永遠(yuǎn)在線業(yè)務(wù)的服務(wù)器充當(dāng)AF，當(dāng)此類應(yīng)用服務(wù)器發(fā)現(xiàn)用戶建立永遠(yuǎn)在線業(yè)務(wù)連接時，將通過Rx接口向策略與計費(fèi)規(guī)則功能（PCRF）請求該業(yè)務(wù)流的承載網(wǎng)絡(luò)的NAT及承載通道的?；睢?/p>

考慮到Rx接口非常復(fù)雜，永遠(yuǎn)在線類業(yè)務(wù)服務(wù)器提供Rx接口的可行性不高，同時永遠(yuǎn)在線業(yè)務(wù)服務(wù)器如何尋找用戶所在的接入網(wǎng)絡(luò)中的PCRF設(shè)備也是一個難題，所以可以在永遠(yuǎn)在線類應(yīng)用及PCRF設(shè)備間引入專門的應(yīng)用功能設(shè)備，用于完成簡單對象訪問協(xié)議（SOAP）接口到Rx接口協(xié)議的一系列轉(zhuǎn)換，從而降低永遠(yuǎn)在線業(yè)務(wù)服務(wù)器的實(shí)現(xiàn)難度。優(yōu)化的永遠(yuǎn)在線業(yè)務(wù)控制的方案結(jié)構(gòu)如圖4所示。

3.1 網(wǎng)元說明

·移動網(wǎng)關(guān)

GW指3G核心網(wǎng)中的GGSN，4G核心網(wǎng)中的分組數(shù)據(jù)網(wǎng)絡(luò)網(wǎng)關(guān)（P-GW）。在永遠(yuǎn)在線控制中，GW主要支持PCP客戶端控制NAT設(shè)備或者防火墻對永遠(yuǎn)在線業(yè)務(wù)流所對應(yīng)的IP轉(zhuǎn)換映射關(guān)系保持一定時間；同時GW控制永遠(yuǎn)在線業(yè)務(wù)流所對應(yīng)的承載通道如GTP PDP上下文保持對應(yīng)時間不釋放。

·策略與計費(fèi)規(guī)則功能網(wǎng)元

PCRF主要接收AF下發(fā)的永遠(yuǎn)在線業(yè)務(wù)?；钫埱?，并根據(jù)本地?；畈呗陨杀；顣r長決策并通過Gx口通告GW，再由GW完成PCP NAT及承載管道的保活控制。

·應(yīng)用功能

AF主要有兩個功能：接收永遠(yuǎn)在線業(yè)務(wù)應(yīng)用服務(wù)器通過SOAP接口下發(fā)的永遠(yuǎn)在線業(yè)務(wù)?；钫埱?，并根據(jù)用戶國際移動用戶識別碼（IMSI）或者業(yè)務(wù)源IP尋找PCRF；將SOAP接口轉(zhuǎn)換為3GPP 標(biāo)準(zhǔn)Rx接口。

·永遠(yuǎn)在線應(yīng)用服務(wù)器

主要包含QQ、新浪微博等應(yīng)用服務(wù)器，主要完成用戶永遠(yuǎn)在線業(yè)務(wù)會話管理，并通過SOAP接口向本地AF請求用戶所在移動接入網(wǎng)絡(luò)的業(yè)務(wù)?；钐幚?。

3.2接口說明

·Rx接口

Rx接口是PCRF與AF之間的接口，用于實(shí)現(xiàn)AF將應(yīng)用業(yè)務(wù)流信息發(fā)送給PCRF，以便針對該業(yè)務(wù)流進(jìn)行相應(yīng)的PCC控制。

Rx接口遵循3GPP PCC規(guī)范[3]，并進(jìn)行永遠(yuǎn)在線能力增強(qiáng)。

·Gx接口

Gx接口是GW/PCEF （GGSN、SAE-GW等）與PCRF之間的PCC會話接口，用于實(shí)現(xiàn)策略的動態(tài)請求和下發(fā)[4]。

Gx接口遵循3GPP PCC規(guī)范[5]，并進(jìn)行永遠(yuǎn)在線能力增強(qiáng)。

·PCP接口

PCP接口是GW與NAT/防火墻設(shè)備之間的接口，用于GW控制NAT設(shè)備或者防火墻對永遠(yuǎn)在線業(yè)務(wù)流所對應(yīng)的IP轉(zhuǎn)換映射關(guān)系保持一定的時間。

·SOAP接口

該SOAP接口是永遠(yuǎn)在線應(yīng)用服務(wù)器與AF設(shè)備之間的接口，用于在線業(yè)務(wù)應(yīng)用服務(wù)器請求永遠(yuǎn)在線業(yè)務(wù)保活請求。

3.3 實(shí)現(xiàn)原理

永遠(yuǎn)在線業(yè)務(wù)實(shí)現(xiàn)原理流程圖如圖5所示。

永遠(yuǎn)在線業(yè)務(wù)的相關(guān)實(shí)現(xiàn)流程說明如下：

（1）UE建立/修改承載。

（2）GW向PCRF請求初始控制的策略。

（3）用戶訪問永遠(yuǎn)在線業(yè)務(wù)服務(wù)器SP/CP，如果業(yè)務(wù)服務(wù)器SP/CP判斷需要NAT?；?，則通過SOAP接口通知PCRF該業(yè)務(wù)需要?；?，PCRF完成業(yè)務(wù)?；顣r長策略后，將時長返回SP/CP。

（4）PCRF根據(jù)本地配置策略，生成該業(yè)務(wù)NAT及業(yè)務(wù)承載通道如GTP的?；畈呗裕⒏鶕?jù)移動用戶識別號碼（MSISDN）號碼查詢Gx會話實(shí)例，下發(fā)業(yè)務(wù)NAT及業(yè)務(wù)承載通道?；畈呗浴?/p>

（5）GW 收到PCRF業(yè)務(wù)?；畈呗院笙騈AT發(fā)送地址為A的PCP NAT?；钫埱?，請求NAT進(jìn)行?；?。

永遠(yuǎn)在線業(yè)務(wù)可能存在的流程為：業(yè)務(wù)服務(wù)器SP/CP在業(yè)務(wù)流保活時間將到期時，如判斷業(yè)務(wù)流仍需要?；睿瑒t通知PCRF繼續(xù)?；?。

（6）業(yè)務(wù)結(jié)束時，業(yè)務(wù)服務(wù)器SP/CP通告PCRF業(yè)務(wù)結(jié)束。

（7）PCRF通知GW取消NAT及業(yè)務(wù)承載通道?；?。

（8）GW 通知防火墻/NAT取消NAT?；睢?/p>

4 結(jié)束語

隨著智能的終端的快速普及，運(yùn)營商解決在線業(yè)務(wù)對網(wǎng)絡(luò)資源沖擊的問題越來越迫切，從網(wǎng)絡(luò)系統(tǒng)角度提出解決方案遵循標(biāo)準(zhǔn)架構(gòu)及實(shí)現(xiàn)原理，為運(yùn)營商解決問題提供了很好的思路，可以很好解決永遠(yuǎn)在線類應(yīng)用在減少或取消“心跳”報文的情況下永遠(yuǎn)在線業(yè)務(wù)中斷問題。

該方案有以下創(chuàng)新及亮點(diǎn)：

（1）從網(wǎng)絡(luò)控制架構(gòu)出發(fā)，相比其他永遠(yuǎn)在線方案產(chǎn)業(yè)鏈較短，易于推廣。

（2）借助標(biāo)準(zhǔn)架構(gòu)做少量增強(qiáng)，方案簡單高效。

（3）永遠(yuǎn)在線業(yè)務(wù)所需移動網(wǎng)絡(luò)資源授權(quán)由移動網(wǎng)絡(luò)PCC統(tǒng)一決策，統(tǒng)一調(diào)度。

參考文獻(xiàn)

[1] Wing D，Cheshire S， Boucadair M，et al.Port control protocol （PCP）[S].IETF RFC 6887.

[2] 3GPP TS 23.203. Policy and Charging Control Architecture[S].

[3] 3GPP TS 29.214. Policy and Charging Control over Rx Reference point[S].

[4] 3GPP TS 29.213. Policy and charging control signaling flows and QoS Parameter Mapping[S].

[5] 3GPP TS 29.212. Policy and Charging Control （PCC）； Reference Points[S].