楊 軍，孫志猛（中國聯(lián)合網(wǎng)絡(luò)通信集團有限公司，北京100033）

0 引言

隨著移動互聯(lián)網(wǎng)的高速發(fā)展，移動數(shù)據(jù)流量呈現(xiàn)爆炸式增長，運營商正逐步從語音、短信經(jīng)營轉(zhuǎn)變?yōu)槎嘣?、全方位、深層次的?shù)據(jù)流量經(jīng)營。為了能夠?qū)崿F(xiàn)對用戶移動數(shù)據(jù)流量的精細化運營，避免成為管道工具，運營商積極引入業(yè)務(wù)識別技術(shù)，能夠?qū)Σ煌N類的業(yè)務(wù)進行檢測與區(qū)分，從而為用戶提供有針對性的差異化服務(wù)，提升用戶業(yè)務(wù)體驗的同時提高運營商的收益。

1 移動網(wǎng)絡(luò)中的業(yè)務(wù)識別技術(shù)

1.1 移動網(wǎng)絡(luò)業(yè)務(wù)識別方式

目前在移動網(wǎng)絡(luò)運營商中使用的業(yè)務(wù)識別方式包括以下幾種。

a）深度流檢測（DFI）。采用基于流量行為的應(yīng)用識別技術(shù)，即不同的應(yīng)用類型體現(xiàn)在會話連接或數(shù)據(jù)流上的狀態(tài)不同，通過識別數(shù)據(jù)包的大小、速率、時延、持續(xù)時間、發(fā)送頻率以及IP 地址連接方式等內(nèi)容進行檢測，從而獲取用戶訪問業(yè)務(wù)種類。

b）淺層包檢測（SPI）。采用數(shù)據(jù)包頭分析技術(shù)，通過對OSI七層協(xié)議中的傳輸層與協(xié)議層內(nèi)容進行檢測，從而獲取用戶訪問業(yè)務(wù)種類，主要識別數(shù)據(jù)包的源IP 地址、目的IP 地址、源端口號、目的端口號、傳輸協(xié)議類型等。

c）深層包檢測（DPI）。采用數(shù)據(jù)包內(nèi)容分析技術(shù)，通過對OSI七層協(xié)議中的應(yīng)用層內(nèi)容進行檢測，從而獲取用戶訪問業(yè)務(wù)種類，主要識別數(shù)據(jù)包的內(nèi)容、應(yīng)用層協(xié)議等。

可以看出DFI與SPI識別方式主要是針對三/四層進行分析，DPI需要對七層內(nèi)容進行分析，一般情況下DFI、SPI采用內(nèi)置部署方式，DPI既可采用內(nèi)置部署方式，也可采用外置部署方式。

1.2 業(yè)務(wù)識別規(guī)則配置方式

移動網(wǎng)絡(luò)運營商業(yè)務(wù)識別技術(shù)中包括業(yè)務(wù)流特征提取模塊和業(yè)務(wù)種類匹配模塊2部分。業(yè)務(wù)流特征提取模塊將用戶業(yè)務(wù)的特性信息（例如數(shù)據(jù)包大小、時延、源IP地址、源端口號、URL、應(yīng)用層協(xié)議類型等）提取出來，發(fā)送給業(yè)務(wù)種類匹配模塊，業(yè)務(wù)種類匹配模塊將特征信息與目的業(yè)務(wù)的特征信息進行匹配，識別出用戶訪問業(yè)務(wù)種類。移動運營商在開啟業(yè)務(wù)識別功能后，需要在PGW 或PCRF 上配置業(yè)務(wù)識別規(guī)則。

a）采用靜態(tài)業(yè)務(wù)識別方式時，在PGW 上通過設(shè)備網(wǎng)管手工配置業(yè)務(wù)識別規(guī)則具體內(nèi)容，由PGW進行業(yè)務(wù)識別。

b）采用動態(tài)業(yè)務(wù)識別方式時，在PCRF 上通過設(shè)備網(wǎng)管手工配置業(yè)務(wù)識別規(guī)則具體內(nèi)容，由PCRF 將業(yè)務(wù)識別規(guī)則動態(tài)下發(fā)給PGW，由PGW 進行業(yè)務(wù)識別。

目前現(xiàn)網(wǎng)中采用通過設(shè)備網(wǎng)管的方式手工在設(shè)備上進行配置，這種配置方式存在以下問題。

a）業(yè)務(wù)識別規(guī)則管理節(jié)點分散。由于PGW/PCRF 配置節(jié)點分散，需要運維人員在全網(wǎng)PGW/PCRF 上對業(yè)務(wù)識別規(guī)則進行動態(tài)維護，尤其針對第三方OTT 業(yè)務(wù)服務(wù)器頻繁變更的場景，管理復(fù)雜度高。

b）業(yè)務(wù)識別規(guī)則容量有限。由于PGW/PCRF 設(shè)備中僅有部分硬件資源用來配置業(yè)務(wù)識別規(guī)則，因此支持的業(yè)務(wù)識別規(guī)則解析條目數(shù)量有限，僅能達到萬級條目，不能滿足大數(shù)據(jù)量級業(yè)務(wù)識別需求。

c）與第三方OTT 交互性較差。由于缺少與第三方OTT之間的自動化數(shù)據(jù)同步接口，只能采用人工工單的方式對業(yè)務(wù)識別規(guī)則進行配置，業(yè)務(wù)開通周期長，不能滿足合作業(yè)務(wù)快速開通與上線的需求。

為了能夠有效地解決以上問題，提出了業(yè)務(wù)識別規(guī)則集中管理方案。

2 業(yè)務(wù)識別規(guī)則集中管理方案

2.1 集中管理方案特點

業(yè)務(wù)識別規(guī)則集中管理方案通過引入業(yè)務(wù)識別規(guī)則集中管理網(wǎng)元實現(xiàn)對用戶業(yè)務(wù)識別規(guī)則的集中管理，同時開通與第三方OTT 之間的數(shù)據(jù)同步接口，提高與第三方OTT交互實時性，實現(xiàn)業(yè)務(wù)識別規(guī)則管理的集中化、自動化。采用業(yè)務(wù)識別規(guī)則集中管理方案可以有效解決在現(xiàn)網(wǎng)業(yè)務(wù)識別規(guī)則配置中存在的問題。

a）由于采用業(yè)務(wù)識別規(guī)則集中管理網(wǎng)元，運維人員只需要在全網(wǎng)一點進行業(yè)務(wù)識別規(guī)則管理維護，可有效提高業(yè)務(wù)識別規(guī)則管理效率，降低管理復(fù)雜度。

b）由于采用了專門的軟、硬件設(shè)備配置業(yè)務(wù)識別規(guī)則，因此支持的業(yè)務(wù)識別規(guī)則解析條目數(shù)量較高，能達到百萬級要求，可以滿足大數(shù)據(jù)量級業(yè)務(wù)識別規(guī)則需求。

c）由于開通了與第三方OTT 之間的自動化數(shù)據(jù)同步接口，第三方合作業(yè)務(wù)的開通與管理可以做到自動化，極大程度地縮短第三方合作業(yè)務(wù)開通部署周期，簡化流量經(jīng)營類業(yè)務(wù)配置步驟，滿足合作業(yè)務(wù)快速開通與上線的需求。

2.2 網(wǎng)絡(luò)架構(gòu)與接口

如圖1 所示，業(yè)務(wù)識別規(guī)則集中管理方案新建1套業(yè)務(wù)識別規(guī)則集中管理網(wǎng)元，開通與現(xiàn)網(wǎng)PGW之間的ICAP/SOAP 接口、與現(xiàn)網(wǎng)PCRF 之間的SOAP 接口、與第三方OTT之間的Restful接口。

圖1 業(yè)務(wù)識別規(guī)則集中管理方案

a）ICAP 接口。為業(yè)務(wù)識別規(guī)則集中管理網(wǎng)元與PGW 之間的接口，PGW 提供業(yè)務(wù)識別規(guī)則，發(fā)送給業(yè)務(wù)識別規(guī)則集中管理網(wǎng)元，業(yè)務(wù)識別規(guī)則集中管理網(wǎng)元查詢本地數(shù)據(jù)庫得到業(yè)務(wù)標識，將業(yè)務(wù)標識返回給PGW。

b）SOAP接口。為業(yè)務(wù)識別規(guī)則集中管理網(wǎng)元與PGW/PCRF 之間的接口，業(yè)務(wù)識別規(guī)則集中管理網(wǎng)元提供業(yè)務(wù)識別規(guī)則給PGW/PCRF，PGW/PCRF對SOAP接口消息進行處理，將其轉(zhuǎn)換為網(wǎng)元內(nèi)部配置。

c）Restful 接口。為業(yè)務(wù)識別規(guī)則集中管理網(wǎng)元與第三方OTT之間接口，第三方OTT提供業(yè)務(wù)識別規(guī)則以及業(yè)務(wù)屬性的相關(guān)描述，發(fā)送給業(yè)務(wù)識別規(guī)則集中管理網(wǎng)元，業(yè)務(wù)識別規(guī)則集中管理網(wǎng)元對Restful接口消息進行處理，鑒權(quán)第三方OTT的合法性并獲得業(yè)務(wù)識別規(guī)則的定義等其他屬性信息。

業(yè)務(wù)識別規(guī)則集中管理方案采用動態(tài)查詢與靜態(tài)查詢相結(jié)合的方式，用戶初始查詢通過ICAP接口采用動態(tài)查詢方式查詢業(yè)務(wù)識別規(guī)則與業(yè)務(wù)標識之間的關(guān)系；業(yè)務(wù)識別規(guī)則集中管理網(wǎng)元存儲業(yè)務(wù)識別規(guī)則查詢頻次等信息，依據(jù)篩選條件對業(yè)務(wù)識別規(guī)則進行條件篩選，將篩選后的業(yè)務(wù)識別規(guī)則通過SOAP 接口下發(fā)給PGW/PCRF，PGW/PCRF 轉(zhuǎn)換成內(nèi)部網(wǎng)元配置文件；用戶后續(xù)查詢時采用靜態(tài)查詢方式查詢PGW/PCRF本地配置的業(yè)務(wù)識別規(guī)則與業(yè)務(wù)標識之間的關(guān)系。

在移動運營商網(wǎng)絡(luò)中部署集中管理方案需新建業(yè)務(wù)識別規(guī)則集中管理網(wǎng)元；對現(xiàn)網(wǎng)PGW/PCRF 進行軟硬件升級改造，增加SOAP 接口機，能夠?qū)OAP 協(xié)議轉(zhuǎn)換成內(nèi)部配置文件；需要對PGW的內(nèi)部業(yè)務(wù)識別邏輯進行改動，將業(yè)務(wù)匹配模塊外置到業(yè)務(wù)識別規(guī)則集中管理網(wǎng)元中。

2.3 主要業(yè)務(wù)流程

業(yè)務(wù)識別規(guī)則集中管理方案主要包括業(yè)務(wù)識別規(guī)則生成、業(yè)務(wù)標識動態(tài)查詢和業(yè)務(wù)識別規(guī)則下發(fā)3個流程。

2.3.1 業(yè)務(wù)識別規(guī)則生成流程

第三方OTT 通過Restful 接口向業(yè)務(wù)識別規(guī)則集中管理網(wǎng)元同步業(yè)務(wù)的業(yè)務(wù)識別規(guī)則信息，包括新增/修改/刪除業(yè)務(wù)識別規(guī)則（見圖2）。

a）運營商針對第三方OTT 業(yè)務(wù)規(guī)劃業(yè)務(wù)標識信息。

圖2 業(yè)務(wù)識別規(guī)則與業(yè)務(wù)標識生成流程

b）第三方OTT根據(jù)不同場景針對業(yè)務(wù)進行新增、修改、刪除業(yè)務(wù)識別規(guī)則信息操作。

c）第三方OTT 向業(yè)務(wù)識別規(guī)則集中管理網(wǎng)元發(fā)送HTTP請求消息，消息頭中攜帶Username、Password、Operation、Seq 等參數(shù)，消息體中攜帶業(yè)務(wù)識別規(guī)則及業(yè)務(wù)屬性等信息，包括L3/4RuleContent、L7RuleContent等。

d）業(yè)務(wù)識別規(guī)則集中管理網(wǎng)元對第三方OTT 合法性進行認證與鑒權(quán)，同時更新數(shù)據(jù)庫內(nèi)部業(yè)務(wù)識別規(guī)則信息，并根據(jù)業(yè)務(wù)屬性信息決定后續(xù)對業(yè)務(wù)識別規(guī)則采取的動作。

e）業(yè)務(wù)識別規(guī)則集中管理網(wǎng)元向第三方OTT 發(fā)送HTTP響應(yīng)消息，其中攜帶返回結(jié)果，成功返回200，失敗返回500。

2.3.2 業(yè)務(wù)標識動態(tài)查詢流程

PGW提取業(yè)務(wù)識別規(guī)則特性信息，發(fā)送給業(yè)務(wù)識別規(guī)則集中管理網(wǎng)元，業(yè)務(wù)識別規(guī)則集中管理網(wǎng)元進行業(yè)務(wù)標識查詢（見圖3）。

圖3 業(yè)務(wù)標識查詢流程

a）用戶使用數(shù)據(jù)業(yè)務(wù)，PGW進行數(shù)據(jù)流解析獲取流描述信息，例如源IP 地址、源端口號、目的IP 地址、目的端口號、URL等L3/4或L7層協(xié)議特征。

b）PGW 向業(yè)務(wù)識別規(guī)則集中管理網(wǎng)元發(fā)送ICAP REQMOD Request 消息，消息中攜帶L3/4Rule?Content、L7RuleContent。

c）業(yè)務(wù)識別規(guī)則集中管理網(wǎng)元查詢本地數(shù)據(jù)庫對業(yè)務(wù)識別規(guī)則進行匹配。

d）業(yè)務(wù)識別規(guī)則集中管理網(wǎng)元向PGW 發(fā)送ICAP REQMOD Response 消息，匹配成功時，消息中攜帶Service_ID；匹配不成功時，消息中攜帶結(jié)果碼。

2.3.3 業(yè)務(wù)識別規(guī)則下發(fā)流程

由業(yè)務(wù)識別規(guī)則集中管理網(wǎng)元下發(fā)業(yè)務(wù)識別規(guī)則的靜態(tài)配置信息給PGW/PCRF，PGW/PCRF 對業(yè)務(wù)識別規(guī)則進行配置轉(zhuǎn)換（見圖4）。

圖4 業(yè)務(wù)識別規(guī)則下發(fā)流程

a）業(yè)務(wù)識別規(guī)則集中管理網(wǎng)元判斷滿足業(yè)務(wù)識別規(guī)則推送條件，例如立即推送、業(yè)務(wù)識別規(guī)則變化時推送、查詢頻次滿足一定條件時推送，發(fā)起向PGW/PCRF的業(yè)務(wù)識別規(guī)則動態(tài)推送流程。

b）業(yè)務(wù)識別規(guī)則集中管理網(wǎng)元向PGW/PCRF 發(fā)送業(yè)務(wù)識別規(guī)則推送請求消息，消息中攜帶業(yè)務(wù)識別規(guī)則及動作類型等信息，包括L3/4RuleContent、L7Ru?leContent、Action_Type等。

c）PGW/PCRF 向業(yè)務(wù)識別規(guī)則集中管理網(wǎng)元返回SOAP 響應(yīng)消息，消息中攜帶返回結(jié)果，成功返回200，失敗返回500。

d）PGW/PCRF 對SOAP 消息進行處理，將業(yè)務(wù)識別規(guī)則轉(zhuǎn)換成內(nèi)部配置文件。

e）業(yè)務(wù)識別規(guī)則集中管理網(wǎng)元向PGW/PCRF 發(fā)送處理結(jié)果響應(yīng)請求消息，消息中攜帶Message ID、Is?Success、ErrorDesc等參數(shù)。

f）PGW/PCRF向業(yè)務(wù)識別規(guī)則集中管理網(wǎng)元返回SOAP響應(yīng)消息，消息中攜帶返回結(jié)果，成功返回200，失敗返回500。

3 業(yè)務(wù)識別規(guī)則集中管理應(yīng)用

3.1 應(yīng)用了C D N技術(shù)的移動互聯(lián)網(wǎng)業(yè)務(wù)

隨著CDN技術(shù)的成熟，越來越多的第三方OTT業(yè)務(wù)商都通過使用CDN技術(shù)來提高業(yè)務(wù)服務(wù)質(zhì)量，但由于用戶訪問內(nèi)容經(jīng)過CDN 調(diào)度后對原始URL 進行了重定向，改變了用戶訪問服務(wù)器的IP 地址或URL，從而為網(wǎng)關(guān)精確識別第三方OTT 業(yè)務(wù)以及用戶精準計費帶來一定影響。

采用業(yè)務(wù)識別規(guī)則集中管理方案，第三方OTT通過Restful 接口將自營業(yè)務(wù)的業(yè)務(wù)識別規(guī)則發(fā)送到業(yè)務(wù)識別規(guī)則集中管理平臺，CDN服務(wù)提供商將CDN的服務(wù)器IP地址、重定向后的URL與第三方OTT的映射關(guān)系通過Restful 接口發(fā)送到業(yè)務(wù)識別規(guī)則集中管理平臺，業(yè)務(wù)識別規(guī)則集中管理平臺將CDN的服務(wù)器IP地址、重定向后的URL與第三方OTT的原始URL進行綁定；當用戶使用第三方OTT 業(yè)務(wù)時，將CDN 重定向后的服務(wù)器IP地址或URL發(fā)送給業(yè)務(wù)集中管理平臺，業(yè)務(wù)識別規(guī)則集中管理平臺將其與第三方OTT 的URL 進行關(guān)聯(lián)，將業(yè)務(wù)流量進行合并處理，從而做到精準計費。

與網(wǎng)關(guān)靜態(tài)配置方式相比，集中管理方案具有一定優(yōu)勢，由于現(xiàn)網(wǎng)部署的CDN 業(yè)務(wù)服務(wù)器較多，重定向后的URL也較分散，通過在網(wǎng)關(guān)上手工靜態(tài)配置第三方OTT 業(yè)務(wù)與CDN 重定向后的服務(wù)器IP 地址或URL的匹配關(guān)系十分復(fù)雜與繁瑣；業(yè)務(wù)集中管理平臺支持的業(yè)務(wù)識別規(guī)則容量大，同時具備Restful數(shù)據(jù)同步接口，同步第三方OTT業(yè)務(wù)與CDN重定向后的服務(wù)器IP地址或URL的匹配關(guān)系簡單與且匹配快速。

3.2 后向流量統(tǒng)付業(yè)務(wù)

隨著移動運營商從傳統(tǒng)的語、短信經(jīng)營轉(zhuǎn)變?yōu)閿?shù)據(jù)流量經(jīng)營，越來越多的移動互聯(lián)網(wǎng)企業(yè)提出了定向流量經(jīng)營類業(yè)務(wù)產(chǎn)品需求，例如用戶免費訪問某團購網(wǎng)站以此增加網(wǎng)站點擊率，通過廣告或第三方商家分成的方式盈利；某游戲網(wǎng)站為游戲用戶提供免費游戲流量，通過游戲中的增值業(yè)務(wù)盈利，此類商業(yè)模式的特點是后向流量統(tǒng)付，終端用戶不必顧慮費用，第三方OTT為流量付費，可以獲得更多增值業(yè)務(wù)回報。為了能夠有效支撐流量經(jīng)營類業(yè)務(wù)產(chǎn)品需求，要求移動運營商的網(wǎng)絡(luò)支持大批量互聯(lián)網(wǎng)業(yè)務(wù)的精確識別功能。

采用業(yè)務(wù)識別規(guī)則集中管理解決方案，第三方OTT 通過Restful 接口將自營業(yè)務(wù)的業(yè)務(wù)識別規(guī)則及訂購的統(tǒng)付業(yè)務(wù)發(fā)送給業(yè)務(wù)識別規(guī)則集中管理平臺；用戶在使用業(yè)務(wù)過程中，PGW將自營業(yè)務(wù)的業(yè)務(wù)特征信息發(fā)送給業(yè)務(wù)識別規(guī)則集中管理平臺，業(yè)務(wù)識別規(guī)則集中管理平臺匹配內(nèi)部數(shù)據(jù)庫完成業(yè)務(wù)識別，并下發(fā)統(tǒng)付業(yè)務(wù)所用計費標識；PGW 使用下發(fā)的RG 為用戶統(tǒng)付類業(yè)務(wù)計費。

與采用PCRF 針對用戶級別的解決方案相比，集中管理方案具有一定優(yōu)勢，由于不區(qū)分用戶，因此不需要PCRF參與，合作業(yè)務(wù)開通部署周期較快，第三方OTT只需要通過自動化配置接口將業(yè)務(wù)識別規(guī)則信息與業(yè)務(wù)訂購能力信息發(fā)送給業(yè)務(wù)識別規(guī)則集中管理平臺，運營商在業(yè)務(wù)集中管理平臺上對第三方OTT的申請進行審批開通即可，一般情況下幾天時間即可完成全網(wǎng)業(yè)務(wù)開通與應(yīng)用，極大地縮短了業(yè)務(wù)開通部署周期。

4 總結(jié)

面對著互聯(lián)網(wǎng)業(yè)務(wù)的迅猛發(fā)展，現(xiàn)網(wǎng)涌現(xiàn)出各種各樣不同種類的互聯(lián)網(wǎng)業(yè)務(wù)，如何做到互聯(lián)網(wǎng)內(nèi)容與運營商管道能力的緊密結(jié)合是目前運營商關(guān)注的一個重點。在對互聯(lián)網(wǎng)業(yè)務(wù)進行有針對性的增值處理之前，首先要做的就是對互聯(lián)網(wǎng)業(yè)務(wù)的精確識別，如何讓這個識別過程更加智能化、簡單化、自動化是研究的重點。

與現(xiàn)網(wǎng)業(yè)務(wù)識別規(guī)則配置方式相比，業(yè)務(wù)識別規(guī)則集中管理方案新增了Restful接口，增強了與第三方OTT 之間的交互性，OTT 能夠?qū)崟r地將變化的業(yè)務(wù)識別規(guī)則同步給業(yè)務(wù)識別集中管理網(wǎng)元，提高了合作業(yè)務(wù)開通效率、規(guī)避了業(yè)務(wù)識別規(guī)則頻繁變化帶來的計費風險。同時業(yè)務(wù)識別規(guī)則集中管理方案新建了一套業(yè)務(wù)識別規(guī)則集中管理網(wǎng)元，集中一點維護全網(wǎng)業(yè)務(wù)識別規(guī)則，有效降低了業(yè)務(wù)識別規(guī)則管理復(fù)雜度，大幅度提高了業(yè)務(wù)識別規(guī)則容量，可滿足百萬級業(yè)務(wù)經(jīng)營需求。

業(yè)務(wù)識別規(guī)則集中管理方案僅僅是運營商智能管道開放的一個基礎(chǔ)功能，后續(xù)還需要在識別互聯(lián)網(wǎng)業(yè)務(wù)的基礎(chǔ)上，緊密結(jié)合第三方OTT豐富多樣的互聯(lián)網(wǎng)業(yè)務(wù)內(nèi)容，為其有針對性地提供定制化服務(wù)，在提升用戶體驗的同時深入挖掘運營商的管道價值能力。

［1］ 3GPP TS 23.203 Policy and charging control architecture［S/OL］.［2015-07-22］.http：//www.3gpp.org/DynaReport/23203.htm.

［2］ 3GPP TS 29.212 Policy and Charging Control（PCC）over Gx refer?ence point［S/OL］.［2015-07-22］.http：//www.3gpp.org/DynaReport/29212.htm.

［3］ 3GPP TS 29.213 Policy and charging control signalling flows andQuality of Service（QoS）parameter mapping［S/OL］.［2015-07-22］. http：//www.3gpp.org/DynaReport/29213.htm.

［4］ 3GPP TS 29.214 Policy and charging control over Rx reference point［S/OL］.［2015- 07- 22］. http：//www.3gpp.org/DynaReport/29214.htm.

［5］ 高翔，武斌，俞學浩，等. 一種基于ICAP 的實時數(shù)據(jù)防泄露方案［J］.信息網(wǎng)絡(luò)安全，2013（11）：30-36.

［6］ 湯吳，李之棠. 基于DPI 的P2P 流量控制系統(tǒng)的設(shè)計與實現(xiàn)［J］.信息安全與通信保密，2007（6）：94-96.

［7］ 李蕓. P2P 流量識別與管理技術(shù)應(yīng)用研究［J］. 信息通信技術(shù)，2008（6）：18-24.

［8］ 黃韜，張智江，劉韻潔.PCC 策略控制機制研究［J］.現(xiàn)代電信科技，2008（9）：2-5.

［9］ 朱永慶.DPI技術(shù)應(yīng)用場景探討［J］.廣東通信技術(shù)，2007（7）：27-29.

［10］于化龍.移動運營商DPI 應(yīng)用策略分析［J］.電信技術(shù)，2012（6）：42-45.

［11］郭恩陽.DPI 在移動分組域中的應(yīng)用與展望［J］.移動通信，2012（18）：85-89.

［12］喬治.基于DPI 的內(nèi)容緩存技術(shù)及應(yīng)用［J］.信息通信技術(shù)，2011（3）：65-69.

［13］穆佳，高功應(yīng)，周曉敏.DPI 在WCDMA 中的應(yīng)用分析［J］.郵電設(shè)計技術(shù)，2015（2）：78-82.

［14］張玎.端到端的QoS 服務(wù)保障分析［J］.郵電設(shè)計技術(shù)，2013（8）：26-29.

［15］朱亞楠.基于DPI 技術(shù)的P2P 業(yè)務(wù)的識別和控制［D］.上海：上海交通大學，2008.