專利名稱：互聯(lián)網(wǎng)流量內(nèi)容分發(fā)的系統(tǒng)、設備及其方法
技術領域：
本發(fā)明總體涉及內(nèi)容分發(fā)，具體涉及互聯(lián)網(wǎng)流量內(nèi)容分發(fā)的系統(tǒng)、設備及其方法。背景資料近年來，應用移動設備的媒體消費大幅度增加。因此，由于流量的爆炸性增長，電信網(wǎng)絡擁擠不堪。這一現(xiàn)象在移動寬帶(MBB)網(wǎng)絡上更為明顯，其基礎設施的成本比固定寬帶(FBB)網(wǎng)絡的成本高出許多(大約超出20至30倍)。近期，移動設備，諸如智能手機、 平板電腦、上網(wǎng)本和筆記本電腦等得以普及使用，開創(chuàng)了無線接入高速全網(wǎng)絡的新紀元。因此，多媒體通信流量的增長預計比FBB網(wǎng)絡前5年(例如從2000年到2005年)在流量方面的增長更加迅速。但是，MBB和FBB網(wǎng)絡運營商并沒有從流量增幅中受益。大多數(shù)這種快速增長的流量并不會為MBB和FBB網(wǎng)絡運營商帶來利益，因為這種流量被直接歸類為消費者流量，而消費者流量通常視為OTT(Over-The-Top)流量。因此，降低快速增長的OTT流量的影響，已經(jīng)成為MBB和FBB網(wǎng)絡運營商的當務之急。OTT流量不同于其他流量，如企業(yè)對企業(yè)(B2B)或企業(yè)對消費者(B2C)流量，其中， OTT內(nèi)容和流量特征對運營商來說都是未知的。這些未知的特征包括媒體源、媒體類型、所使用的交付協(xié)議/方式、受保護與明確內(nèi)容、動態(tài)與靜態(tài)內(nèi)容等。因此，由于技術的復雜性、 網(wǎng)絡成本和OTT處理上的不確定性，使得應對并降低OTT流量的影響變得困難。

發(fā)明內(nèi)容
一般情況下，通過本發(fā)明的實施例可以解決或繞過這些問題和其他問題，并實現(xiàn)主要的技術優(yōu)勢。根據(jù)本發(fā)明的實施例，媒體流方法包含從接入網(wǎng)的L3節(jié)點收到用戶配置文件，以及收到將媒體內(nèi)容發(fā)到用戶設備的請求。用戶配置文件包括用戶賬號相關信息和/或用戶設備的網(wǎng)絡特性。該方法還包括使用用戶配置文件中的用戶設備信息，在某個層次的媒體服務器中分配第一類媒體服務器為用戶設備提供服務，如果將要提供的媒體內(nèi)容可緩存的話。媒體服務器層次集包括部署在多個層二(U)接入網(wǎng)的多個第一類媒體服務器。用戶設備通過多個L2接入網(wǎng)的L2接入網(wǎng)與內(nèi)容分發(fā)網(wǎng)絡相耦合。
根據(jù)本發(fā)明的另一個實施例，一種提供媒體服務的方法包括從內(nèi)容分發(fā)網(wǎng)絡的一個媒體控制器中接收用戶配置文件。用戶配置文件包括用戶賬號相關信息和/或用戶設備的網(wǎng)絡特性。接收向用戶設備提供可緩存媒體內(nèi)容服務的請求。用戶設備通過接入網(wǎng)與內(nèi)容分發(fā)網(wǎng)絡相耦合。通過使用用戶配置文件中的用戶設備信息可以確定用戶設備的體驗質(zhì)量。本方法還包括基于用戶設備的體驗質(zhì)量將可緩存媒體內(nèi)容提供給用戶設備。下文將詳細列出本發(fā)明實施例的特點，以便使以下發(fā)明的詳細說明更易懂。后文將說明本發(fā)明實施例的其它功能和優(yōu)勢，構成本發(fā)明權利要求的主題。本技術領域的人員應深知，本文所透露的概念和指定實施例可被用作為修改或設計與本發(fā)明擁有相同目的的其他結構或流程的基礎。上述技術人員還應認識到，這些等效結構并不違背追加申請中闡述的發(fā)明的精神和范疇。
附圖簡介為提供更完整的本發(fā)明見解及其優(yōu)勢說明，現(xiàn)為以下說明提供參考信息，請參閱與其相對應的附圖，其中

圖1說明了采用Gi卸載方法來處理OTT流量的在先技術接入網(wǎng)卸載解決方案；圖2說明了一種在先技術方法(“基于Gi卸載的流量卸載功能(TOF) ”)，根據(jù)TR 23. 829標準，這種方法在第4實施例中還被稱為“移動邊緣接入網(wǎng)關(MEAG) ” ；圖3依據(jù)當前3GPP標準說明了一種在MBB網(wǎng)絡中使用的在先技術方法(“本地網(wǎng)關GPRS支持節(jié)點(GGSN)方法”)；圖4根據(jù)本發(fā)明的其中一個實施例說明了用于MBB和/或FBB網(wǎng)絡的統(tǒng)一內(nèi)容分發(fā)網(wǎng)絡解決方案；圖5包括圖5A至圖5D，說明了根據(jù)本發(fā)明實施例所進行的L2網(wǎng)絡的配置；圖6包括圖6A至圖6D，說明了根據(jù)本發(fā)明實施例所進行的L3網(wǎng)絡和內(nèi)容分發(fā)網(wǎng)絡的配置；圖7說明了根據(jù)本發(fā)明實施例應用于MBB網(wǎng)絡的統(tǒng)一內(nèi)容分發(fā)解決方案； 圖8包括圖8A至圖8D，說明了根據(jù)本發(fā)明實施例對內(nèi)容分發(fā)網(wǎng)絡中的組件所進行的配置；圖9說明了根據(jù)本發(fā)明實施例所部署的媒體服務器的層次結構；圖10說明了根據(jù)本發(fā)明實施例對媒體控制器中存儲的分組數(shù)據(jù)協(xié)議(PDP)上下文數(shù)據(jù)所制定的表；圖11說明了根據(jù)本發(fā)明實施例可在一般情況下進行的控制和媒體消息流操作；圖12說明了當UE在多個網(wǎng)絡中或跨多個網(wǎng)絡重定位/漫游時，根據(jù)本發(fā)明多個實施例可對資源進行的重新分配；圖13說明了當UE在多個網(wǎng)絡中或跨多個網(wǎng)絡重定位/漫游時，根據(jù)本發(fā)明實施例可對資源進行的重新分配，并強調(diào)了可能的影響；圖14說明了根據(jù)本發(fā)明實施例可在MBB網(wǎng)絡中對其進行重定位和漫游的一般網(wǎng)絡體系結構，其中，圖14A說明了圖12中方案II下的漫游實施例，圖14B說明了圖13中方案III下的漫游實施例；圖15說明了根據(jù)本發(fā)明的實施例，跨SGSN進行UE重定位的已修改程序；
圖16說明了一種供用于根據(jù)3GPP 33. 107進行分組交換合法監(jiān)聽(Li)的在先技術參考配置，據(jù)此并入本發(fā)明，以供參考；圖17說明了一種適用于實施合法監(jiān)聽方法的實施例；圖18包括圖18A和圖18B，說明了另一個適用于合法監(jiān)聽方法的實施例，其中，層 2網(wǎng)絡中的媒體服務器決定并分發(fā)與目標UE的通信，圖18A說明了實施LI的環(huán)境圖，及圖 18B說明了 LI消息流；圖19包括圖19A和19B，說明了合法監(jiān)聽方法的第三種實施例，其中，層2網(wǎng)絡中的媒體服務器決定并分發(fā)(但通過媒體控制器)與目標UE的通信，圖19A說明了實施LI 的環(huán)境圖，及圖19B說明了 LI消息流；圖20說明了用于根據(jù)本發(fā)明實施例進行計費、報告和分析的一般網(wǎng)絡體系結構以及體驗質(zhì)量的規(guī)定；圖21說明了用于根據(jù)本發(fā)明實施例對媒體服務器故障進行處理的一般網(wǎng)絡體系結構；圖22說明了實施上述發(fā)明實施例的)(DSL網(wǎng)絡；圖23說明了實施上述發(fā)明實施例的有線寬帶網(wǎng)絡；圖M說明了符合本發(fā)明實施例的代表性媒體服務器；圖25說明了用于根據(jù)本發(fā)明實施例提供媒體服務的媒體控制器的組件；圖沈說明了用于根據(jù)本發(fā)明實施例提供媒體服務的媒體服務器的組件；圖27說明了用于根據(jù)本發(fā)明實施例提供媒體服務的內(nèi)容處理器的組件；圖觀說明了用于根據(jù)本發(fā)明實施例提供媒體服務的互通功能單元的組件；圖四說明了用于根據(jù)本發(fā)明實施例串流媒體的第二媒體服務器的組件；圖30說明了用于根據(jù)本發(fā)明實施例串流媒體的媒體控制器的組件；圖31說明了用于根據(jù)本發(fā)明實施例串流媒體的層3節(jié)點3100的組件；圖32說明了用于根據(jù)本發(fā)明實施例串流媒體的媒體服務器的組件；圖33根據(jù)本發(fā)明實施例說明了深層分組檢測節(jié)點的組件；圖34根據(jù)本發(fā)明實施例說明了媒體服務器的組件；圖35根據(jù)本發(fā)明實施例說明了媒體服務器的組件；圖36根據(jù)本發(fā)明實施例說明了媒體控制器的組件；圖37根據(jù)本發(fā)明實施例說明了媒體服務器的組件；圖38根據(jù)本發(fā)明實施例說明了媒體數(shù)據(jù)功能的組件；圖39根據(jù)本發(fā)明實施例說明了層2接入網(wǎng)中的媒體服務器的組件；圖40根據(jù)本發(fā)明實施例說明了媒體控制器的組件；圖41根據(jù)本發(fā)明實施例說明了互通功能單元的組件；圖42根據(jù)本發(fā)明實施例說明了媒體控制器的組件。不同圖片中的相應數(shù)字和符號一般指相對應的部件，除非另有說明。這些圖片雖未按比例繪制，但可清晰說明實施例的相關部分。示例實施例的詳細說明下文將詳細討論多種實施例的制備和使用。但這應理解為，本發(fā)明中的許多適用的發(fā)明概念都能體現(xiàn)在各種具體的環(huán)境中。所討論的具體實施例只是說明本發(fā)明的具體制備和使用方法，而不限制本發(fā)明的范圍。下文將說明在下列描述中使用的基本功能實體的定義和首字母縮略詞以及實體之間的接口。首字母縮略詞AAA-認證、授權及賬務ADMF-合法監(jiān)聽的管理功能B2B-企業(yè)對企業(yè)(運營商向另一個企業(yè)提供服務的一種模型)B2C-企業(yè)對消費者(運營商向其終端用戶提供服務的一種模型)BC-計費和收費策略服務器BG-邊界網(wǎng)關(互聯(lián)網(wǎng)對等點)CC-CDN Control (control function that decides which MS to handle a given request) CC-CDN控制(決定哪個MS來處理給定請求的控制功能)CDN-內(nèi)容分發(fā)網(wǎng)絡(支持OTT、B2B和B2C的開放式CDN)CG-計費網(wǎng)關(負責計費方面的服務)DF-分發(fā)功能(Li基礎設施術語)DPI-深層分組檢測(一種檢查分組的功能)DPI-C-內(nèi)容請求級別DPI (包括深層HTTP頭、URL分析)DSL-數(shù)字用戶線FBB-固定寬帶0CDSL、電纜網(wǎng)絡等)GGSN-網(wǎng)關GPRS支持節(jié)點GPRS-通用分組無線業(yè)務GSN-GPRS 支持節(jié)點(或是 SGSN 或 GGSN)IffF-互通功能(一種用于連接L2節(jié)點和媒體服務器的特殊功能)L2Node-層2節(jié)點(如MBB中的RNC和節(jié)點B、FBB網(wǎng)絡中的DSLAM等)
L3Node-層3節(jié)點(如MBB中的GGSN或FBB中的BRAS等)LEMF-執(zhí)法監(jiān)聽功能LI-合法監(jiān)聽(為LI的接口，如MBB的LIG)LIG-合法監(jiān)聽網(wǎng)關LIMS-LI 管理系統(tǒng)MBB-移動寬帶(2. xG、3G、4G 或 WiMax 網(wǎng)絡)MC-媒體控制(與⑶N控制功能相同)MD-媒體數(shù)據(jù)(數(shù)據(jù)分析、日志和報告)MS-媒體服務器(提供媒體流、緩存和適配功能)MX-媒體開關(與MS相同的功能)NB-節(jié)點B (3GPPRAN功能，即另稱為BS、eNB的無線基站)OCS-在線計費系統(tǒng)OTT-Over The Top (網(wǎng)絡運營商未知的內(nèi)容和流量類型)PCC-策略計費和控制PCRF-策略、計費規(guī)定功能
PS-策略服務器(如MBB中的PCRF)QoE-體驗質(zhì)量(終端用戶體驗質(zhì)量)QoS-服務質(zhì)量RNC-無線網(wǎng)絡控制器(3GPP標準中的RAN控制功能)SGSN-為GPRS支持節(jié)點提供服務SUR-用戶使用報告UE-用戶實體(終端用戶設備/客戶端)XDSL-DSL技術(如ADSL和HDSL)的所有變體。圖1至圖3將說明關于處理OTT流量的不同在先技術方法。但是，發(fā)明者已經(jīng)認識到這些在先技術方法具有不同的優(yōu)點和缺點，在下文我們將對這些優(yōu)點和缺點做詳細探討。下文描述的申請使用縮寫詞GGSN和SGSN的目的僅在于舉例說明。這些術語還可以是在網(wǎng)絡中執(zhí)行這些操作的服務器。例如，在3GPP LTE/4G網(wǎng)絡中執(zhí)行GGSN操作的服務器是指系統(tǒng)體系結構進化網(wǎng)關(SAE-GW)，在3GPP LTE/4G網(wǎng)絡中執(zhí)行SGSN操作的服務器是指移動管理實體(MME)。因此，執(zhí)行GGSN、SAE-Gff和相似等效服務器操作的服務器的類別可指網(wǎng)關服務器節(jié)點，執(zhí)行SGSN、MME和相似等效服務器操作的服務器的類別可以指服務/ 管理節(jié)點。僅出于說明的目的，描述中使用了 GGSN和SGSN。本文描述的各種實施例中可使用任何相對應的服務器。圖1說明了采用Gi卸載方法來處理OTT流量的現(xiàn)有的接入網(wǎng)卸載和緩存解決方案；圖1說明了一種通過層2 (L2)網(wǎng)絡20與互聯(lián)網(wǎng)70相耦合的用戶設備(UE 10)，如無線接入網(wǎng)、層2(L2)節(jié)點21。L2節(jié)點21可以是基站、NB、eNB、無線網(wǎng)絡控制器等。L2網(wǎng)絡20通過層3(U)網(wǎng)絡30與互聯(lián)網(wǎng)70相耦合。L3網(wǎng)絡30提供諸如計費網(wǎng)關(CG) 31、合法監(jiān)聽(Li) 32和策略服務器(PQ 33等服務。Gi卸載方法在移動寬帶(MBB)網(wǎng)絡中廣泛使用。在Gi卸載方法中，通過IP流量網(wǎng)絡40引入了緩存媒體服務器MS 41。MS 41可作為獨立的緩存功能或作為⑶N網(wǎng)絡中的媒體服務器發(fā)揮功能性。深層分組檢測DPI 37功能可以獨立于L3節(jié)點36(如網(wǎng)關GPRS 支持節(jié)點(GGSN))或作為其中的一部分。然而，Gi卸載方法在DPI功能下不能幫助緩解流量壓力，因為網(wǎng)絡路徑中緩存有大量內(nèi)容。為了解決這一問題，圖2中引入了第二種方法， 但僅作說明之用。圖2說明了一種現(xiàn)有方法(“基于Gi卸載的流量卸載功能(TOF)，，)，這種方法還被稱為“移動邊緣接入網(wǎng)關(MEAG) ”。在MEAG方法中，卸載位置自L3節(jié)點36 (例如GGSN位置上的Gi)轉(zhuǎn)移至L2節(jié)點 (例如，RNC)。Gi是GGSN和公共數(shù)據(jù)網(wǎng)絡(PDN)之間基于IP的接口。如圖2所示，L2網(wǎng)絡20引入TOF 22。因而，本方法能在TOF 22上方實現(xiàn)帶寬節(jié)省(即在TOF 22上方的所有 L3節(jié)點中實現(xiàn)節(jié)省)。但是為了支持所有其它與MBB接入網(wǎng)相關的支持類服務，例如，合法監(jiān)聽(Li)、實時計費服務和基于策略的QoS服務(PCRF)，T0F22需要支持與圖2中描述的 CG 31、LI 32和PS 33功能支持直接接口。MS 41(點線機)是一個MS可選功能，可作為獨立的緩存服務器或⑶N網(wǎng)絡中的媒體服務器予以插入。卸載功能和緩存功能可進行固有解耦，但二者可結合用于實現(xiàn)其它優(yōu)
點ο但是，本方法具有很多缺點。首先，所有流量都要在TOF 22上使用深層分組檢測 (DPI)類型的方法進行分析。這會極大地削弱L2網(wǎng)絡20的性能。第二點，為了支持與MBB 相關的服務，例如，CG 31、LI 32和PS 33，自TOF 22至上述功能的接口須加以維護，使得 CG 31、LI 32和PS 33的交互復雜化；第三點，為了實現(xiàn)上述的第一點和第二點，TOF 22可能成為一個復合功能，其中具有MBB的SGSN和GGSN功能中之常見功能。即使存在上述缺點，本方法已采納為TR23. 829標準的備用項。下一個方法旨在改善這第二個方法中的上述缺點。圖3說明了一種在MBB網(wǎng)絡中使用的在先技術方法(“本地網(wǎng)關GPRS支持節(jié)點 (GGSN)方法”)。在本方法中，L2節(jié)點是無線網(wǎng)絡控制器(RNC)，L3節(jié)點是本地GGSN。本方法(再次應用于MBB域)旨在使用標準GSN處理已呼叫的直接隧道，有利于 L2網(wǎng)絡20中的L2節(jié)點21 (例如，RNC)創(chuàng)建至本地L3節(jié)點26，例如，本地GGSN,的直接隧道。因此，本地GGSN位于RNC (L2節(jié)點21) —側(cè)，從而有利于RNC通過本地GGSN(本地L3 節(jié)點26)將某些類型的流量(如網(wǎng)絡流量)卸載到互聯(lián)網(wǎng)。在本方法中，現(xiàn)有SGSN和GGSN 功能位于非卸載路徑中。已針對本方法提出了兩種稍微不同的配置靜態(tài)卸載和動態(tài)卸載。首先，在靜態(tài)卸載配置中，設置之后，卸載流量會以靜態(tài)方式通過本地L3節(jié)點沈(本地GGSN)，非卸載流量將繼續(xù)通過L3節(jié)點36(GGSN)。如圖3所示，在設置分組數(shù)據(jù)協(xié)議(PDP)時，SGSN(另一個L2/L3節(jié)點)可以確定靜態(tài)配置。這需要對SGSN進行修改，以處理卸載策略和確認本地 GGSN?；蛘撸瑒討B(tài)卸載配置用虛線顯示在本地L3節(jié)點沈和L3節(jié)點36之間。在這一情況下，所有數(shù)據(jù)流量流入本地L3節(jié)點沈(本地GGSN)，其會作出卸載決定，包括在單個PDP 內(nèi)的不同數(shù)據(jù)流上適用不同的卸載策略。SGSN總會選擇L3節(jié)點36(SGGSN)和本地L3節(jié)點沈(本地GGSN)作為宏GGSN的代理。在向核心L3節(jié)點(MBB環(huán)境中的SGSN和GGSN)提供服務方面，本方法與第二個方法具有相似的優(yōu)勢。但是，因為GGSN是一種標準的MBB功能，而且其與CG 31、LI 32和PS 33等等之間的接口已經(jīng)定義且標準化，所以在L2節(jié)點21位置上引入本地GGSN(例如，RNC) 似乎可解決許多上述問題。然而本方法存在其它缺點，具體可見下方的描述。第一，L3節(jié)點36，例如GGSN，是一種復合功能，其實施過程相對昂貴且難以管理。 因而，部署多個GGSN節(jié)點并不符合成本效益。第二，網(wǎng)絡中若有多個GGSN JUCG 31、LI 32 和PS 33等等之間的交互會變得更加復雜。例如，實時計費功能將須要接收兩個GGSN(本地L3節(jié)點沈和L3節(jié)點36)的輸入，以確定活動會話是否已達到額定限值。第三，在其中所有服務使用單個APN的單一接入點名稱(APN)的設置過程中，這一方案可能會面臨挑戰(zhàn)。 尤其是自包數(shù)據(jù)協(xié)議(PDP)設置好后，上述的靜態(tài)卸載配置，即自L2節(jié)點21 (RNC)至本地 L3節(jié)點沈(本地GGSN)之間靜態(tài)確定的卸載不可更改。在本發(fā)明的各實施例中，我們將描述任何層2接入網(wǎng)(如RAN網(wǎng)絡或)(DSL接入網(wǎng)，亦或電纜網(wǎng)絡)中基于層3的內(nèi)容分發(fā)網(wǎng)絡(CDN)媒體服務器(MQ的部署方法。這種 ⑶N媒體服務器的部署可在維持具有處理面向MBB網(wǎng)絡和FBB網(wǎng)絡的0TT、B2B和B2C服務能力的CDN網(wǎng)絡的統(tǒng)一、通用和開放的同時，還可用于緩存和處理更接近于用戶裝置的媒體內(nèi)容。如果⑶N媒體服務器在緩存通過接入網(wǎng)(MBB或FBB)向終端用戶分發(fā)的OTT內(nèi)容時位于更接近終端用戶裝置的位置，則現(xiàn)有網(wǎng)絡基礎設施的成本節(jié)約潛能會更大。這是因為無線接入網(wǎng)(RAN)節(jié)點的基礎設施成本相較于分組交換(PS)網(wǎng)絡來說過于沉重。因此， 沿著接入路徑，將媒體服務器向終端用戶裝置進一步移動，會比較有利。然而，最后一英里的接入網(wǎng)可是層2網(wǎng)絡或者是非IP閉環(huán)網(wǎng)絡，如RAN(在3G無線網(wǎng)絡中)或)(DSL。媒體服務器在這些網(wǎng)絡中的部署至少會面臨兩種挑戰(zhàn)。第一，媒體服務器(通常它會是一個層3節(jié)點)需要特殊接口使其與層2網(wǎng)絡相交互。第二，定期卸載 (TOF)方式，需要一種DPI流程來確定OTT流是否可緩存，然后進行本地卸載或緩存。這種 DPI流程可要求相當密集的CPU處理，并可以降低接入節(jié)點的功能。通過將層3媒體服務器部署到具有解耦功能的層2接入網(wǎng)中，本發(fā)明的實施例克服了這些問題和其他問題。尤其是，如OTT流量檢測、緩存決定和OTT流量請求路由決定等部分功能，均保留在層3⑶N網(wǎng)絡中。本發(fā)明的實施例還包括對MBB網(wǎng)絡域中以下多種功能的獨特處理如合法監(jiān)聽(Li)、與處理相關的在線計費系統(tǒng)(OCS)、QoS處理和支持，以及 MBB和FBB網(wǎng)絡的很多其它功能支持。本發(fā)明的實施例首先采用圖4的系統(tǒng)基礎設施架構進行描述。各單元的詳細結構實施例將采用圖5-6和圖8-9進行描述。本發(fā)明適用于移動寬帶網(wǎng)絡、XDSL網(wǎng)絡、電纜寬帶網(wǎng)絡的實施例將分別采用圖7、圖22和圖23進行描述。適用于MBB網(wǎng)絡的流操作實施例將采用圖11進行描述。本發(fā)明涉及有關處理漫游/重定位的實施例將采用圖12-15進行描述。本發(fā)明適用于合法監(jiān)聽的實施例將采用圖17-19進行描述。本發(fā)明適用于處理計費、報告和分析以及體驗規(guī)定的質(zhì)量的實施例將根據(jù)圖20進行描述。本發(fā)明適用于處理媒體服務器故障的實施例將根據(jù)圖21進行描述。圖4根據(jù)本發(fā)明的其中一個實施例說明了用于MBB和/或FBB網(wǎng)絡的統(tǒng)一內(nèi)容分發(fā)網(wǎng)絡解決方案。在圖4中，UE 10表示終端用戶裝置，如移動裝置或具有無線網(wǎng)卡的裝置。關于圖4，具有多個L2節(jié)點21的L2網(wǎng)絡20和具有多個L3節(jié)點36的L3網(wǎng)絡30形成了一個通向互聯(lián)網(wǎng)70的接入網(wǎng)絡。除L2節(jié)點21之外，各實施例在L2網(wǎng)絡20內(nèi)都包含一個互通功能IWF 23和一個基于L3的媒體服務器MS-A 24。IffF 23在L2網(wǎng)絡20中的層2節(jié)點與 MS-A24之間充當接口和路由功能。位于L2網(wǎng)絡中的媒體服務器將標記為MS-A，而位于L3網(wǎng)絡中的媒體服務器將標記為MS-B，以便于區(qū)分不同類型的媒體服務器。在L3網(wǎng)絡30中，深層分組檢測(DPI)37功能檢查UE的簽名匹配請求，以確定請求是否須轉(zhuǎn)移至內(nèi)容分發(fā)網(wǎng)絡(CDN)80繼而進行下一步處理。因而，DPI 37將UE請求轉(zhuǎn)移至⑶N 80，以便進行下一步處理。經(jīng)配置，DPI 37可檢測其中通過的分組，例如搜索協(xié)議違規(guī)、病毒、垃圾郵件、入侵，或預定義標準以決定對數(shù)據(jù)包采取哪些，包括收集統(tǒng)計信息。DPI 37可新增對OSI模型層2至層7的檢查功能，這可包括標頭、數(shù)據(jù)協(xié)議結構和消息的實際有效載荷?；趶姆纸M數(shù)據(jù)部分中提取的信息的簽名數(shù)據(jù)庫，DPI 37可識別流量并對其進行分類，從而實現(xiàn)較之僅基于標頭信息的分類更精細的控制。在其它實施例中，DPI 37可識別流量是否包含OTT類別。經(jīng)分類的分組可以在網(wǎng)絡中重定向，加以標記/標簽、進行攔截、設置額定限制和/ 或報告給報告代理。⑶N 80通常是一組經(jīng)戰(zhàn)略部署于所有IP網(wǎng)絡的一組服務器，可分層也可不分層。 ⑶N 80可具有多個可在地理上分布開來的不同設備。示例中，⑶N 80中的典型設備包括位于⑶N 80中不同點上的服務器。例如，UElO可訪問距其最近的服務器的數(shù)據(jù)副本，而可選擇不從中心服務器進行訪問?；蛘呶挥谙嗨莆恢玫亩鄠€用戶可從不同服務器訪問相同的文件，從而防止單個倉庫服務器超載。CDN 80中存儲的內(nèi)容類型可包括網(wǎng)絡對象、可下載對象 (媒體文件、軟件和文檔)、應用程序、實時媒體流和網(wǎng)絡分發(fā)的其他組件(DNS、路由和數(shù)據(jù)庫查詢)。在多個實施例中，內(nèi)容分發(fā)網(wǎng)絡(CDN)SO中異常路徑內(nèi)容層級的深層分組檢測單元(DPI-C)Sl理解OTT請求并決定由哪一個媒體服務器為提出媒體請求的UE提供服務。。 通過使用外部DPI-C 81，最大程度地降低對現(xiàn)有網(wǎng)絡組件的影響。這是因為DPI 37通常已整合至L3節(jié)點36。因而現(xiàn)有DPI 37會與其它功能區(qū)別開來。在多個實施例中，MS-A M被引入到更加接近UE 10的L2網(wǎng)絡20中，，同時盡可能對⑶N 80與L2網(wǎng)絡20及L3網(wǎng)絡30的功能進行解耦。在不同實施例中，密集型操作， 如DPI-C 81功能，在⑶N 80上予以處理，這相比L2節(jié)點21，其裝備更優(yōu)良，更適合執(zhí)行復雜任務。這避免了為執(zhí)行密集型操作而向L2節(jié)點新增昂貴資源的需要。有利的方面是，通過結合上一點，接入網(wǎng)(MBB或FBB)和⑶N 80可保持自身相對的功能獨立性，同時進行合作以最大程度地提高OTT流量的處理效能，并在常見的統(tǒng)一方法中存在B2B和B2C服務的情況下，最大程度地提高該類服務的效能。L2網(wǎng)絡20和L3網(wǎng)絡30中經(jīng)插入的功能可處理圖5和圖6中所示的多份不同的
配置表單。圖5包括圖5A至圖5D，說明了根據(jù)本發(fā)明實施例所進行的L2網(wǎng)絡的配置。圖5A說明了其中L2節(jié)點21、IffF 23和MS-A 24作為獨立單元(如物理上獨立的機器)的一個實施例。在圖5B中，L2節(jié)點21和IWF 23是同一個集成單元(同一個箱 /機器)，而MS-AM則獨立構成。在圖5C中，IWF 23和MS-A 24作為一體化單元，而L2節(jié)點21是獨立單元。在圖5D中，所有組件都整合至同一個物理單元。在圖5中，圖5A和圖5C所示的配置具有將MS-A M透明引入L2網(wǎng)絡20而不會對L2節(jié)點21造成任何影響的優(yōu)勢。這要求IWF 23在L2網(wǎng)絡20引入MS-AM的情況下賦予L2節(jié)點21完全的透明性。這一點的優(yōu)勢之一是L2節(jié)點21與IWF 23及MS-A M可由不同的提供商提供。相反的是，圖5B中的配置可大大簡化IWF 23，因為L2通信的消息和數(shù)據(jù)流信息已大部分存在于L2節(jié)點21。圖6包括圖6A至圖6D，說明了根據(jù)本發(fā)明實施例所進行的L3網(wǎng)絡和內(nèi)容分發(fā)網(wǎng)絡的配置。圖6A說明了其中L3節(jié)點36、DPI 37和DPI-C 81作為獨立單元(例如，另一臺機器)的一個實施例。在圖6B中，L3節(jié)點36和DPI 37是同一個集成單元(同一個箱/機器)，而DPI-C 81則獨立構成。在圖6C中，DPI 37和DPI-C 81作為一體化單元，而L3節(jié)點36是獨立單元。在圖6D中，所有組件都集成到單個的物理單元中。
參閱圖6可看到，圖6A和圖6B的配置賦予非OTT流量最小時延，而且在接入網(wǎng) 30 (L3節(jié)點36和DPI 37)及⑶N網(wǎng)絡80 (DPI-C 81)之間進行解耦的優(yōu)勢。為了實現(xiàn)OTT 流量識別而對內(nèi)容層級DPI和基本DPI進行解耦，具有優(yōu)勢性，原因在于用于處理OTT的內(nèi)容層級DPI要求對DPI簽名進行持續(xù)調(diào)諧，并不斷準備DPI算法，以應對OTT內(nèi)容和流量剖析中的變動。因而，圖6C和圖6D所示的配置無法實現(xiàn)這些優(yōu)勢。因為當前已經(jīng)部署的許多L3 節(jié)點36也具備執(zhí)行DPI 37的能力，所以圖6B的配置具備另一個優(yōu)勢，即是重新使用內(nèi)置于L3節(jié)點36的DPI 37的功能。但是圖6C和圖6D所示的配置可部署于新的架構場景，其中向后兼容性和之前存在的設備問題不復存在。L3網(wǎng)絡30頂部位置上的相關功能(CG 31、LI 32和PS 33)提供計費、合法監(jiān)聽和策略服務器功能，以使接入網(wǎng)服務更加完整。關于與上述功能之間的交互，存在其它幾種創(chuàng)新功能，具體可參見下文的討論。出于清晰的目的，若功能與本發(fā)明的說明及理解性不存在密切關聯(lián)性，則予以省略。圖7說明了根據(jù)本發(fā)明實施例應用于MBB網(wǎng)絡的統(tǒng)一內(nèi)容分發(fā)解決方案。本發(fā)明應用于MBB網(wǎng)絡的實施例尤其具有許多優(yōu)勢，即使圖4，其說明了一種通用方法和設備，相關描述提及的本發(fā)明實施例既適用于移動寬帶(MBB)網(wǎng)絡，又適用于固定寬帶(FBB)網(wǎng)絡。圖7說明了該類與圖4的通用說明對應的MBB功能組件。參閱圖7可看到，在這一實施例中，節(jié)點B(NB) 121和/或RNC 122可以是圖4的L2節(jié)點21，而GGSN 136可以是圖4中的L3節(jié)點36。正如圖4所示，緩存媒體服務器MX-A IM部署在無線接入網(wǎng)120。 圖7中的虛線是緩存媒體服務器的替代性MX-A 124’ (與替代性IWF 123’ 一并)部署位置 (在NB位置上)，即使出于實用目的，仍將MX-A IM部署于RNC 122中。圖4中的⑶N控制(CC)82功能可以是圖7中的媒體控制器(MC) 182功能。MC 182會選擇和分配最佳定位的媒體服務器MX(MX-A和MX-B)來為UE 110中的給定請求提供服務。IffF 123與MX-A IM之間的連接為L2/L3連接，以使流向和來自MX_A IM中的流量可以通過IWF 123正確路由到L2網(wǎng)絡中以及從L2網(wǎng)絡中路由出來。實際上，可以將所有MX-A 1 的IP地址規(guī)定為適用于RNC 122和IWF 123 (如在無線應用協(xié)議網(wǎng)關WAP Gff 中的情況下)的相同地址，但是MX-A IM具有指向網(wǎng)絡的⑶N/互聯(lián)網(wǎng)一側(cè)的單獨且唯一的可路由IP地址。如下文更深入的描述，在其他實施例中，也可以按照后文描述，采用其他通過IP地址池為MX-A分配IP地址的方法。MX-A 124和⑶N 180之間的虛線表示大多數(shù)MBB部署中可能可用的所有IP傳輸網(wǎng)絡。在另一個實施例中，通過RNC 122/IWF 123-SGSN 135-GGSN 136-DPI 137的信道/ 路徑可用于與⑶N 180中的組件進行通信。這一實施例要求IWF 123在信道協(xié)議(如適用于傳輸用戶數(shù)據(jù)GTP-U的GPRS信道協(xié)議)的限制下提供所需的MX-A IM和⑶N 180之間的路由轉(zhuǎn)換。因此，如果IWF 123與RNC 122相集成，這種方法會更有效，從而使GTP消息和上下文的分組在從MX-A 124中路由消息時即可落實。在各實施例中，GGSN 135與MC 180之間的通信至少可以采用兩種形式。在第一個實施例中，正如圖7所示，GGSN 136和MC 182可設計有直接的專用接口 Gmc (簡單的RESTful API，即符合表述性狀態(tài)轉(zhuǎn)移約束的應用程序編程接口)以便GGSN 136向MC 182提供相關的PDP上下文信息，進而請求處理。這種專用接口有兩種額外的操作模式。在多個實施例中，在GGSN 136和MC 182之間提供了直接接口，這樣就可使用本技術領域人員所熟知的其它類型的請求處理協(xié)議。首先，GGSN 136可以將活動PDP上下文的新創(chuàng)建、更新和刪除等操作推送到MC 182。假設每個GGSN直接與至多一個MC 182連接，則每個GGSN 136只需將信息推送到與其相連的MC 182。其次，MC 182可隨時將UE 110的當前IP地址用作查詢密鑰，查詢GGSN 136以獲取PDP上下文信息。MC 182僅查詢直接與MC 182連接的GGSN 136。除非DPI 137包含 GGSN 136在先前請求中的信息，并且MC 182針對此目的進行解析，否則，在將多個GGSN連接到單個MC的情況下，可以將查詢一并發(fā)送到多個GGSN上。在第二個實施例中，如圖7所示，可以依據(jù)UEHTTP消息參數(shù)擴充，通過DPI 137和 DPI-C 181將PDP信息從GGSN 136傳遞到MC 182。在這種情況下，GGSN 136包含擴充的 HTTP標頭中的該類相關的PDP上下文參數(shù)(參見表1)。這一選項可能會影響GGSN 136的性能，因為HTTP消息在GGSN 136中擴充時需要進行額外處理。圖8(包括圖8A至圖8D)根據(jù)本發(fā)明實施例，說明了用于配置內(nèi)容分發(fā)網(wǎng)絡組件的各種配置。在多個實施例中，DPI-C 181、MC 182和MX-B 184可以在單獨的單元中實施(例如另一臺計算機)或集成。圖8A說明了 DPI-C 181、MC 182和MX-B 184在CDN 180中作為單獨單元實施的實施例，而圖8D則說明了它們集成到單個單元中的實施例。在圖8B中， DPI-C 181和MX-B184在單個單元中同時實施，而在圖8C中，DPI-C 181和MC 182同時集成。圖9說明了根據(jù)本發(fā)明實施例所部署的媒體服務器層次結構；本發(fā)明的實施例包括一組具有層次結構的媒體服務器位于無線接入網(wǎng)絡120中的第一個媒體服務器MX-A 124，位于⑶N 180中第二個媒體服務器MX-B 184，以及位于較高層級，例如，分組分發(fā)網(wǎng)絡 (PDN)對等點或邊界網(wǎng)關中的第三個媒體服務器MX-C 194。⑶N 180中的媒體控制器(圖 7中的MC 182)在為UE請求提供服務時會選擇適當?shù)拿襟w服務器MX。因此，本發(fā)明的實施例創(chuàng)建了一個可在⑶N控制下從MBB RAN網(wǎng)絡向PDN的對等點的分層緩存網(wǎng)絡。媒體服務器的層次結構會為⑶N 180提供一種處理MBB網(wǎng)絡獨有特征的功能。例如，熱、溫和冷內(nèi)容(最常請求的是熱內(nèi)容)可在緩存層次結構的不同層級上進行緩存。在一個或多個實施例中，可以分配MX-A、MA-B和MC來分別保持本地、地區(qū)和整體內(nèi)容的熱度， 從而在各種級別上優(yōu)化緩存效率和在CDN網(wǎng)絡中平衡請求處理。圖10說明了根據(jù)本發(fā)明實施例對媒體控制器中存儲的分組數(shù)據(jù)協(xié)議(PDP)上下文數(shù)據(jù)所制定的表；根據(jù)圖10中的表，MC 182可以在表中保存PDP上下文數(shù)據(jù)子集，例如，讓MC 182 負責處理的那些用戶根據(jù)UE IP地址進行索引，從而與GGSN 136中的PDP狀態(tài)同步。在第一個實施例以及上述探討的第一個操作模式中，GGSN 136可僅在PDP上下文中發(fā)生任何更改時促成對MC182的更新。MC 182可使用當前的UE IP地址來維護其PDP上下文表。圖4-9、12、14、15、17-M的實施例還可根據(jù)包含功能步驟和/或非功能操作的方法進行描述或說明。下列(及上述)描述和相關流程圖說明了本發(fā)明實施例實踐中使用的步驟和/或操作。通常情況下，功能步驟從所取得的成效這一角度來描述本發(fā)明，而非功能操作更加詳細地描述旨在實現(xiàn)特定成效或達到特定步驟的操作。盡管功能步驟和/或非功能操作可按特定順序進行描述或聲明，但是當前發(fā)明不必限定于任何特定順序或步驟和 /或操作的組合。另外，所列舉的權利要求及下方對圖11、18B和19B流程圖的描述中使用 (或非使用)“步驟”和/或“操作”，用于指明須具體使用(或非使用)此類用詞。圖11說明了根據(jù)本發(fā)明實施例可在一般情況下進行的流操作。當UE，如圖4中的UE 10或圖7中的UE 110，請求查看某個視頻門戶網(wǎng)站，如 youtube、hulu、amazon,的視頻，時，會向視頻門戶網(wǎng)站發(fā)送一條HTTP消息。這將要求先在 UE和視頻流服務器之間建立一個DNS查詢和一個相對應的TCP連接。在多個實施例中，建立和/或激活(第201步)UE與GGSN之間的PDP上下文。PDP 上下文存儲用于請求UE所包含的PDP上下文數(shù)據(jù)。在一個或多個實施例中，PDP上下文包括RAN端MX IP地址，如圖7中RAN 120 一端的MX-AIP地址。PDP上下文還可以包括如圖 10中描述的標準參數(shù)。接著，UE 通過 RNC/IWF (消息 210 和消息 211)將 HTTP GET REQUEST 傳輸?shù)?GGSN/ DPI。GGSN/DPI節(jié)點處理收到的HTTP GET請求。DPI可搜索HTTP請求的特定簽名，例如， 目的地IP地址和端口 #，并在此請求是獲取OTT內(nèi)容的情況下，將它們與預存儲的OTT簽名列表進行對比。對于某些OTT站點，簽名分析可不僅僅涉及五元組分析，而且可要求HTTP 標頭參數(shù)分析的實際DPI，這會要求一種不同類型的簽名。在流程圖中，假設本請求與存儲于DPI的簽名相匹配(DPI確定請求是否為OTT內(nèi)容)。DPI通過DPI與DPI-C功能之間的IP連接(消息212)將本HTTP GET請求提交到 DPI-C (深層內(nèi)容URL DPI)。DPI將不對本HTTP GET請求消息的任何部分作出更改。在一些實施例中，本次提交可通過通用路由封裝(GRE)隧道或網(wǎng)絡緩存通信協(xié)議(WCCP)進行實施。接著，DPI-C決定內(nèi)容是否為可緩存內(nèi)容。DPI-C功能從DPI接收經(jīng)提交的HTTP GET請求。DPI-C進行深層URL和HTTP標頭分析，以將DPI-C功能上所存儲的簽名與所提交的消息進行匹配。必需的DPI-C簽名和算法可以根據(jù)待處理的特定視頻門戶網(wǎng)站(適用于^utube、BBC、Hulu等視頻)和/或軟件下載網(wǎng)站(適用于windows更新等大文件)的不同而變化。在一個或多個實施例中，DPI-C集中于HTTP的消息類型和用戶代理，而其他參數(shù)可包括在各個實施例中。在圖11的說明中，假設對于此串流，初始視頻門戶媒體請求(以及大多數(shù)其它視頻網(wǎng)站)與上文描述的簽名不匹配(例如，DPI-C確定內(nèi)容不可緩存)。例如，此請求可發(fā)送到將要初始化的媒體播放器所在的HTML頁面上，媒體播放器會初始化單獨的請求，從而 “獲取”視頻文件。DPI-C以不計費的方式將此請求提交至MBB分組數(shù)據(jù)網(wǎng)絡(PDN)中的 BG(或路徑上的路由器)，HTTP請求繼續(xù)傳送至Youtube服務器(消息213)。在其它多條HTTP消息交換之后，DPI從UE接收另一條HTTP Get請求，確定請求是OTT內(nèi)容，并將其提交給DPI-C(消息220、222和224)。此時，GET請求來自媒體播放器 (如Shockwave播放器)。GET請求可包含與DPI-C上所存儲的簽名相匹配的簽名。因而 DPI-C決定內(nèi)容是否為可緩存內(nèi)容。接著，DPI-C就其對內(nèi)容是否可緩存所進行的評估通知MC。在多個實施例中，如圖8所示，DPI-C可在MX-B、MC或獨立的DPI-C框之上運行，具體取決于運營商的流量規(guī)劃方案。為了便于進行本討論，我們假設DPI-C、MX-B和MC在IP層級上互連且可路由，而 DPI-C、MX-B和MC之間內(nèi)部連接和轉(zhuǎn)發(fā)不在此處進行詳述。如果DPI-C在MX-B上運行，而且適用于需要由CDN提供服務的請求，則請求消息將從MX-B/DPI-C傳遞到MC，因為MC會選擇用于服務任何給定請求的媒體服務器(MX)。在DPI-C確定請求為可緩存內(nèi)容并且MC收到來自DPI-C的HTTP請求之后，⑶N就必須要參與對本請求的服務。在一個或多個實施例中，位于CDN中的MC會執(zhí)行以下一系列 MBB網(wǎng)絡任務，從而為服務本HTTP請求而選擇適合的緩存媒體服務器(MX)。如上所述，MC會存儲其通過Gmc ( 一個指向GGSN的RESTful控制信息API，請參見圖7)獲取的PDP信息子集。在各實施例中，MC可以使用不同的替換方法來確定哪一個 MX-A位于服務當前UE的PDP路徑中。在一個實施例中，可以使用位置信息(如路由器區(qū)域標識或服務區(qū)域標識(RAI/ SAI))來選擇媒體服務器。例如，根據(jù)RAI/SAI選擇RNC，例如，可使用一張包含RNC和RAI/ SAI之間映射關系的表。由RNC決定媒體服務器的位置。MC可存儲一張包含所有RNC-RAI/ SAI映射關系的MC表。在另一個實施例中，如果存在這種確定性關系，可使用UE IP范圍和指向RNC的映射。在另一個替換實施例中，RAN端MX-A IP地址是一種可選的參數(shù)，可以在GGSN中添加到PDP上下文，在初始PDP設置或參數(shù)的任何隨后更改期間轉(zhuǎn)發(fā)給MC。在另一個替換實施例中，通過GGSN與SGSN之間的通信，可以獲得RNC IP地址或ID，MC會保持RNC IP/ID與其本地MX-A IP之間的映射表。如圖9所示，MC從媒體服務器層次集中選擇媒體服務器。下文將進一步描述此選擇所用的方法。MX作為⑶N MX云的一部分，會與MC(在MC云中)保持狀態(tài)和心跳，因此， 在MC中可立即知曉MX的加載條件和可用性。在一個實施例中，MC可以隨著UE在RNC中重定位/漫游，決定將當前請求重定向到眾多MX-A (RAN側(cè)的MX-A)之一。在另一個實施例中，MC在GGSN層級上，從多個MX-B中選擇其一，或者在一個分組數(shù)據(jù)網(wǎng)絡(PDN)對等點或BG層級(如圖7和9所示)選擇其中一個 MX-C。在多個實施例中，可以使用多種方式來執(zhí)行用于確定最佳服務MX的策略和/或探
試ο在一個實施例中，MC可具有這樣的一種策略除非MX-A過載，否則將不斷恢復當前MX-A向給定UE( S卩，UE的PDP路徑上的IWF/MX-A)提供的服務。隨著UE經(jīng)過RNC的 RAI/SAI,當前提供服務的MX-A可基于重定位的方案進行改變。下文漫游/重定位中將對此進行更深入的探討。根據(jù)本策略，MC總是會選擇當前提供服務的MX-A。下文策略處理中將對此進行更深入的探討。在另一個實施例中，運營商可以擁有多個CDN請求服務策略，根據(jù)傳統(tǒng)的CDN實施可以作為B2B和B2C服務的一部分。同樣地，它們可以通過相同的方法引入特定于OTT的路由請求策略。這些方法的實施形式包括通過CDN的網(wǎng)絡操作中心(NOC)，或通過下載至 MX的配置表，或結合以上兩種形式，分配給MC的一組策略。如果在MX-A中存在緩存缺失這種情況，則可以配置本地配置表以提高緩存分層結構，從而嘗試獲取請求內(nèi)容或咨詢MC對該內(nèi)容是否作為配置表中的一個條目的意見。
1
在多個實施例中，選擇用于服務UE的MX之后，HTTP GET請求將重定向到面向此 UE提供服務的MX-A上(消息226、228、230、240和M2)。在一個或多個實施例中，MX-A重定向的執(zhí)行方式如下所述。MC或DPI-C會建立重定向消息并將其發(fā)送給UE。MC或DPI-C會創(chuàng)建一個HTTP 302(或HTTP 303重定向)消息，其中的目的地IP為UE、源IP為視頻門戶網(wǎng)站服務器IP 地址(例如，正在處理的當前HTTP GET的目的地)。URL會根據(jù)原始服務URL而擴充，這對 MX-A在緩存缺失情況下檢索內(nèi)容會非常有用。由于MC/DPI-C和GGSN/DPI現(xiàn)已存在TCP連接，因此MC僅可將這條HTTP 302假消息轉(zhuǎn)發(fā)給GGSN/DPI (即消息226)，這樣，便能夠通過 UE與媒體門戶網(wǎng)站服務器之間現(xiàn)有的TCP連接，將請求路由到目標UE (消息2 和230)。 這種情況是假設通過在DPI功能進行分析，使TCP序列號與媒體門戶端相匹配。如果上述的重定向不可能實現(xiàn)或者難以實現(xiàn)，那么在替換實施例中，UE與媒體門戶服務器之間的TCP連接已損壞(強制斷開連接)，并且在DPI-C上采用兩個單獨的TCP連接建立了 TCP代理。通過GGSN/DPI在UE與DPI-C之間建立第一個連接，通過BG在DPI-C 與媒體門戶網(wǎng)站服務器之間建立第二個連接。使用上述方法，UE將從DPI-C/MC中接收一個HTTP 302 (或30 重定向消息。UE 將嘗試聯(lián)系新的URI/IP地址，該地址指向連接到RNC和IWF且正提供服務的MX (MX-A)。UE 會向RNC/IWF發(fā)射一個HTTP GET (消息M0)。RNC/IWF接收UE HTTP GET，然后將其轉(zhuǎn)發(fā)給媒體服務器MX_A。在多個實施例中， 可使用以下實施例其中之一來執(zhí)行此操作。在一個或多個實施例中，如果IWF嵌入在RNC中，那么IWF功能將嘗試打開GTP-U 消息的用戶數(shù)據(jù)以查找UE通信的目的地IP地址。如果目的地IP地址映射到預存儲在RNC/ IWF上的IP地址中，可假設消息將會被傳送到已連接到RNC/IWF且正提供服務的MX-A。此預存儲的IP表須分配到所有RNC/IWF中，因為MX-A已部署在RAN網(wǎng)絡中，且RNC/IWF必須將GTP-U消息重新封裝為HTTP/TCP/IP消息才可以轉(zhuǎn)發(fā)給MX-A0或者，在另一個實施例中，IWF可以是位于IuPS接口路徑上RNC以外的一個單獨的框。IWF會透傳RNC與SGSN之間的所有RANAP或GTP-C消息。相反，IWF會攔截GTP-U 消息并打開用戶數(shù)據(jù)以篩選目的地IP地址如果與預存儲的IP表中的IP地址相匹配，那么 IWF功能會重新封裝消息并將其轉(zhuǎn)發(fā)到與其相連的MX-A上。MX-A接收HTTP GET,這便是UE的HTTP請求(根據(jù)MC進行重定向)(消息M2)。 由于MX-A已經(jīng)收到UE的HTTP請求(根據(jù)MC進行重定向)，MX-A會在多個實施例中執(zhí)行以下HTTP請求處理。MX-A會生成一個代表服務內(nèi)容的索引。MX-A會為URL解析HTTP請求和其它相關信息，以獲得內(nèi)容的索引關鍵字。視頻門戶網(wǎng)站的URL結構沒有既定的標準，其變更相對頻繁。在多個實施例中，可以采用任何常見的標識方法，只要這種方法能夠針對每個給定的內(nèi)容文件生成獨一無二的ID即可。例如，URL都可以存在差別，但是內(nèi)容標識部分需保持一致。因此，在多個實施例中，可以提取內(nèi)容標識部分，并將其用作緩存內(nèi)容文件的索引關鍵字(可能需要使用hashing算法來處理)?？赡苄枰獙线m的HTTP分發(fā)做進一步的調(diào)整， 因為MX-A需要查看大量的小型視頻片段文件。在MX-A上會生成一個獨特的文件名。MX-A會從HTTP GET請求的URL中獲得一個獨特的內(nèi)容/文件ID。這一獨特的URL部分將用于創(chuàng)建獨特的哈希關鍵字，這個關鍵字可用于在MX-A緩存系統(tǒng)中定位內(nèi)容/文件。這可能不是100%可靠，并可能隨時變動，因為媒體的內(nèi)容為0ΤΤ。因此，內(nèi)容/文件都相同的兩個請求可以映射到不同的文件ID，這樣就可以創(chuàng)建相同內(nèi)容/文件的多個副本。在某些情況下，內(nèi)容/文件相同的兩個請求可以映射到相同內(nèi)容中。如果MX-A在MX-A緩存中找到數(shù)據(jù)，便可以在緩存中檢索該數(shù)據(jù)并將其傳輸至 UE (消息244和M6)。如果有匹配的緩存，那么MX-A將嘗試按照UE請求為UE文件提供服務。在多個實施例中，可應用CDN媒體適配(轉(zhuǎn)碼、碼流轉(zhuǎn)換、文件格式適配等)、PCRF QoS 導向處理(根據(jù)用戶或等級分組的QoS保證和帶寬的限制/極限)。在下文有關策略處理的討論中將進行深入的探討。在根據(jù)需要而應用媒體適配后，MX-A會將第一個HTTP響應連同媒體數(shù)據(jù)一起發(fā)送到UE。這可以憑借RNC/IWF節(jié)點的 GTP-U的路由功能，通過UE與GSN之間的現(xiàn)有GTP-U信道，使用RNC/IWF上正確的GTP-U序列號來實現(xiàn)。如果IWF功能是IuPS接口上獨立于RNC的節(jié)點，且結合的RNC/IWF功能不要求復制此GTP處理功能就能夠?qū)X-A發(fā)送給UE的消息路由至UE現(xiàn)有的GTP信道時，IffF 功能便需要自行保存序列號。在多個實施例中，在與UE的會話終止之后，會計算日志，并將日志發(fā)送到⑶N以執(zhí)行各種操作，如記賬、計費和分析等。從MX-A到UE的媒體分發(fā)將會繼續(xù)，直到會話結束；在任何情況下，MX-A都會生成分發(fā)日志。這些分發(fā)日志會發(fā)送到CDN網(wǎng)絡的媒體數(shù)據(jù)(MD) 云，按下述計費、報告和分析方法進行處理。但是，如果MX-A緩存中沒有請求數(shù)據(jù)(例如發(fā)生緩存缺失)，MX-A會遵循其已存儲的策略規(guī)則(現(xiàn)有CDN/MX功能)，嘗試在緩存分層結構的下一個緩存服務器或原始服務器(媒體門戶網(wǎng)站服務器，303/302重定向消息中列出了其URL)中查找內(nèi)容。GGSN/DPI會接收來自MX-A的消息250。DPI和DPI-C會識別出，來自MX-A的本HTTP請求(消息250) 路由不是UE請求，然后將此請求轉(zhuǎn)發(fā)給媒體門戶網(wǎng)站服務器(消息25幻。這樣可以避免再次為MC造成無限循環(huán)的可能性。媒體門戶網(wǎng)站服務器會將在GGSN/DPI上作為HTTP響應(消息254)而接收到的請求數(shù)據(jù)發(fā)送出去。GGSN/DPI會通過GTP信道將數(shù)據(jù)轉(zhuǎn)發(fā)給 MX-A(消息256和258)。MX-A會將內(nèi)容緩存在其緩存系統(tǒng)中并為UE提供數(shù)據(jù)(消息沈0)。但是，在某些實施例中，MX-A還會聯(lián)系MC以在⑶N網(wǎng)絡中查找內(nèi)容的位置。對于這種從上層緩存服務器進行提取的操作，MX-A可能會使用原始用戶HTTP請求URL(嵌入在 MC發(fā)出的重定向消息中)，需使用通過IP傳輸網(wǎng)絡而與上層緩存服務器或原始服務器建立起來的新TCP連接，如圖7所示。本發(fā)明的實施例具有幾個獨特的優(yōu)勢。使用本發(fā)明的實施例，有利于實現(xiàn)對接入網(wǎng)和用于OTT流量緩存的CDN網(wǎng)絡有效解耦。本發(fā)明的實施例能夠在層2網(wǎng)絡中部署基于層3的媒體服務器(媒體緩存和適配)，這有利于更接近終端用戶，又不會像層2DPI和決策制定那么復雜。本發(fā)明的實施例支持在單一CDN上實現(xiàn)更集中化的內(nèi)容層級DPI (DPI-C)和決策，它能夠同時為MBB和FBB提供服務，從而避免在接入網(wǎng)絡中加入DPI-C (內(nèi)容層級)。 本發(fā)明的實施例可能會利用分層緩存網(wǎng)絡以增加緩存匹配率和降低緩存缺失檢索時間。本發(fā)明的實施例還會在已分發(fā)MS服務器之間提供緩存分層結構(MQ備份，以備有任何MS服務器發(fā)生故障。本發(fā)明的實施例采用擁有相同網(wǎng)絡配置的、常見、統(tǒng)一的⑶N，通過MBB和FBB網(wǎng)絡以支持0TT、B2B和B2C服務，大幅簡化網(wǎng)絡部署、管理和操作。圖12和13說明了根據(jù)本發(fā)明實施例的重定位和漫游方案。尤其是，會話過程中，UE可能會在多個網(wǎng)絡之間漫游。本發(fā)明的實施例描述了在漫游過程中/之后進行緩存的方法。取決于UE的行為，可采用不同的方案。圖13列出這些方案，圖12則對其做出了說明。圖12說明當UE在多個網(wǎng)絡中/之間漫游時，可實行的資源重新分配。圖13說明了當UE在多個網(wǎng)絡中/之間漫游時，根據(jù)本發(fā)明實施例可對資源進行的重新分配，并強調(diào)了可能的影響。在第一個方案(方案I)中，UE的重定位可能需要重定位服務基站，例如， 在相鄰的基站(NBl 1211和NB2 121 之間。第二個方案(方案II)涉及到一次重定位， 它要求在RNC中重定位，例如從RNCl 1221到RNC2 1222。第三種方案(方案III)涉及到在不更改GGSN的情況下，在SGSN中的重定位，從SGSNl 1351到SGSN2 1352。在第四個方案(方案IV)中，要重定位服務GGSN，例如從GGSNl 1361到GGSN2 1362。最后，部分UE重定位可能會涉及到從MBB向FBB網(wǎng)絡的更改，反之亦然(圖中未有顯示)。參閱圖12-13可看到，在第一個方案(方案I)中，在相同的RAN 120中，UE從第一個基站(NBl 1211)移動到另一個基站(NB2 1212)。但是，NBl 1211和NB2 1212受同一個RNC 1221控制。因此，這個重新定位對IWFl 1231和MX-Al 1241來說是透明的，因為 MX-Al 1241和IffFl 1231通過常見的RNCl 1221(圖12中未顯示，請參見14A)實現(xiàn)共享。 因此，無需進行修改。參閱圖12-13可看到，在第二個方案中，UE從第一個SGSN(SGSm 1221)移動到第二個SGSN(SGSN2 1222)。此方案具有多個處理選項。圖14說明了根據(jù)本發(fā)明實施例可在MBB網(wǎng)絡中重新定位和漫游的一般網(wǎng)絡體系結構，其中，圖14A說明了圖12中方案II下的漫游實施例，圖14B說明了圖13中方案III 下的漫游實施例。在第一個實施例中，會話可能已中斷，MC 182將請求重定向到RNC2 1222本機上的新MX-A(MX-A2 1242)。因此，在此實施例中，重定位時需要遵照標準的3GPP流程，而且 MX-Al 1241與UE 110之間的會話也可能會中斷。UE的自動重試方式(存在于大多數(shù)媒體播放器中)會重試通過新的RNC2 1222發(fā)送HTTP GET請求，而RNC2 1222會將請求轉(zhuǎn)發(fā)到 MC 182。MC 182會將該請求重定向到新的MX-A2 1242 (RNC2 1222本機上)。如上所述，新的MX-A2 1242會繼續(xù)從該位置進行內(nèi)容分發(fā)。但是，媒體會從頭重新開始，而不是從UE中斷的地方開始。在第二個實施例中，繼續(xù)使用與RNCl 1221關聯(lián)的舊MX-Al 1241。然后執(zhí)行經(jīng)修改的標準3GPP流程，該流程在SGSN 135上限制了重新定位流程。因此，舊MX-Al 1241會繼續(xù)通過舊的順序(即 RNCl 1221/IWF1 1231 — IuR —新的RNC2 1222—新的NB2 1212 —UE 110)分發(fā)，直到會話自然結束為止。但是，來自UE的任何新請求都會重定向到新的MX-A2 1M2，并通過新的RNC2/IWF2提供服務。如上文提到，SGSN 135修改后用于實施該選項，即識別出MX-Al 1241與UE 110之間仍然持續(xù)進行分發(fā)會話，因此，SGSN 135沒有發(fā)出重定位請求。RNCl 1221和RNC2 1221需要重新配置，讓它們能夠?qū)E請求轉(zhuǎn)發(fā)回到舊RANl 1201 網(wǎng)絡中的舊MX-Al 1241。與第一個實施例相似，在第三個實施例中會話同樣會中斷，但由于采用了智能緩存管理，UE 110會收到一段不間斷的流暢視頻。與第一個實施例相似，在會話終端后，需執(zhí)行標準的3GPP流程。特殊媒體播放器會隱瞞錯誤，讓用戶會看到流暢的播放效果，而在后臺進行重定向過程。在一個實施例中，媒體播放器包含了智能緩存管理，可提供充足的緩沖區(qū)。在多個實施例中，媒體播放器還擁有使用修改后的Byte Range參數(shù)重試發(fā)送無響應 HTTP請求的能力，讓UE的媒體播放器可以從停止的位置重新嘗試開始。由于UE目前位于 RNC2 1222下的新的RAN2 1202中，重試消息會被DPI 137/DPI-C 181/MC 182截獲，且MC 182會將要求重定向到新的MX-A2 1242.其余的分發(fā)內(nèi)容在收到UE的Byte Range請求后會繼續(xù)開始發(fā)送。如此一來，便可讓UE避免從會話開頭重新開始媒體。在第四個實施例中，MC 182被通知即將進行重定位，然后MC 182和/或MX-Al 1241會使用智能會話在串流中段進行重新定向。因此，MC 182和/或MX-Al 1241會收到即將重新定位的通知(通過SGSN 135或RNCl 1221)。MC 182和/或MX-Al 1241會發(fā)出中段重新定向請求，以重新定位UE 110。通信過程可以通過現(xiàn)有的順序(即IWFl 1231/RNC1 1221 —NBl 121—UE 110 或 IWFl 1231/RNC1 1221 — IuR — RNC2 1222 — NB2 122 — UE 110)進行傳輸。UE 110媒體播放器將接受配置，以支持該中段重新定向請求。媒體播放器將接受配置，以便向新的MX-A2 1242提出請求(Byte Range從當前播放時間編碼偏移開始)，以此作為對發(fā)自MC 182和/或MX-Al 1241的重定向指令的響應。同時，UE會接收來自媒體播放器緩沖區(qū)的播放內(nèi)容，且不會發(fā)生中斷。來自新的MX-A2 1242的分發(fā)會在播放器緩沖區(qū)耗盡前開始，從而為用戶帶來流暢的播放體驗。參閱圖12-13可看到，在第三個方案中，UE從第一個SGSN(SGSm 1351)移動到第二個SGSN(SGSN2 135 中。此方案的處理方式與之前方案的處理方式相似，但在標準 3GPP消息流方面有一些差別。因此，在多個實施例中，可以通過以下方式實施第三個方案 (a)中斷會話并重新定向到新的MX-A 1241 ； (b)使用當前的(舊的)MX-A 1M1，直到會話終止；(c)使用智能會話管理流程，同時中斷會話并重新定向到新的MX-A 1242 ；或(d)使用智能會話管理流程和串流中段重新定向流程。圖15說明了根據(jù)本發(fā)明的實施例，在SGSN間進行UE重新定位的一套經(jīng)修改的程序；雖然描述內(nèi)容與方案III相關，下文描述的流程也可實施在方案II的第二個實施例中。MX-A只與分組數(shù)據(jù)相關。因此，MBB網(wǎng)絡緩沖重定位流程中的所有其他信號消息都與3GPP的重定位流程相同。分組數(shù)據(jù)轉(zhuǎn)發(fā)中的不同之處，在上述的消息交換流程圖中用虛線表示。在SRNS重新定位流程中，源RNCl 1221和目標RNC2 1222通過LuR(各RNC之間接口)轉(zhuǎn)發(fā)舊MX-Al 1241與UE 110之間的分組數(shù)據(jù)。如圖15中的第六步所示，來自舊 MX-A 1241的分組數(shù)據(jù)會被傳輸?shù)皆碦NCl 1221。在第七步中，來自源RNCl 1221的分組數(shù)據(jù)會通過IuR被傳輸?shù)侥繕薘NC2 1222。在第八步中，來自目標RNC2 1222的分組數(shù)據(jù)被傳輸?shù)経E 110。上述重定位方案(圖15中的第六步、第七步和第八步)在不同實施例中可以通過不同的方式實施。在第一個實施例中，會對源RNCl 1221和目標RNC2 1222進行修改。尤其是，源 RNCl 1221會被配置為在重新定位狀態(tài)時，將分組數(shù)據(jù)(其目的地是MX-Al 1241地址)轉(zhuǎn)發(fā)到MX-A2 1242.新RNC2會被配置為在重新定位狀態(tài)時，將分組數(shù)據(jù)(其目的地是MX-Al 地址)轉(zhuǎn)發(fā)到RNCl 1221。在第二個實施例中，目標RNC2 1222可以使用服務MX-Al IMl (舊的)的IP地址， 路由穿越連接所有RNC和PS核心的VPN/IP運輸網(wǎng)絡。在這種情況下，為了使路由生效，每個MX-A都會有一個唯一的IP地址。圖16-19將描述用于實現(xiàn)合法監(jiān)聽的本發(fā)明實施例。圖16說明了一種供用于根據(jù)3GPP 33. 107進行分組交換合法監(jiān)聽(Li)的在先技術參考配置，據(jù)此并入本發(fā)明，以供參考。在圖16中，參考配置僅可從邏輯上表示合法監(jiān)聽涉及的實體，而不能對獨立的物理實體實施監(jiān)管。這可實現(xiàn)高度的集成。執(zhí)法監(jiān)聽設備(LEMF)連接到管理功能實體ADMF和兩個具有調(diào)解功能的分發(fā)功能實體DF2和DF3。網(wǎng)絡中有一個管理功能實體(ADMF)。ADMF與攔截網(wǎng)絡中需要監(jiān)聽的所有 LEA相連。ADMF會將各個LEA的監(jiān)聽活動區(qū)分開來并連接到攔截網(wǎng)絡。由同一個目標上不同執(zhí)法機構(LEA)執(zhí)行的多種激活和分發(fā)功能，對于3G攔截控制元件(ICE)它們都是隱藏起來的。ICE可以是3G MSC服務器、3G GMSC服務器、P-CSCF、 S-CSCF, SGSN、GGSN、HLR、AAA 服務器、PDG、MME, S-Gff, PDN-GW、HSS。管理功能和分發(fā)功能分別通過標準化轉(zhuǎn)換接口 HI1、HI2和HI3連接到LEMF，并會通過接口 X1、X2和X3連接到電信系統(tǒng)(GSN，可以是SGSN或GGSN)。ADMF通過HIl和Xl接口連接，DF2通過HI2和X2接口連接，而DF3則通過HI3和X3接口連接。通過HI1接口從LEMF發(fā)送到ADMF的消息，以及通過Xl接口從ADMF發(fā)送到GSN的消息，都包含了需要監(jiān)控的目標的標識。DF2通過X2接口從網(wǎng)絡接收監(jiān)聽相關信息(IRI)， 并通過HI2接口將IRI分發(fā)到相關執(zhí)法機構。分發(fā)功能DF3收到通信內(nèi)容CC(例如通過X3 接口收到對話和數(shù)據(jù))，并通過HI3接口將CC分發(fā)到LEA。圖17-19依據(jù)本發(fā)明的實施例說明了適用于MBB網(wǎng)絡和⑶N的合法監(jiān)聽實施例。圖17說明了一種適用于實施合法監(jiān)聽方法的實施例。該實施例最容易實施，所以占據(jù)優(yōu)勢。在本實施例中，如果某個UE成為監(jiān)聽目標，則不會把該UE分配到緩存媒體服務器(如MX-A 124) 0因此，包括來自UE和發(fā)送給UE的OTT流量在內(nèi)的所有通信都可以在 GGSN 136(和/或SGSN 135)上進行攔截，并根據(jù)上述描述與LEMF進行通信。要實施本實施例，可以將附加功能添加到DPI 137中，以確定UE 110是否受到監(jiān)聽。DPI 137會審查UE請求并確定UE請求是否屬于含有LI標志設置(如UE為LI目標) 的PDP上下文。如果UE為目標，則DPI 137不會將UE請求轉(zhuǎn)發(fā)給⑶N 180，從而對緩存媒體服務器進行內(nèi)容深層分組檢測和分配。相反，該UE請求轉(zhuǎn)發(fā)給BG 160或路徑中路由器，以便使用GGSN 136對本請求加以處理，而不會緩存。為確定UE是否為目標，DPI 137檢查GGSN 136是否包含將源IP地址用作索引的 PDP上下文。如上所述，GGSN 136可以與LEMF相接合，并可具有關于被鎖定為目標的UE的最新信息。在某些實施例中，只要UE請求與分配的簽名相匹配，則DPI 137就會檢查GGSN 136，以獲取LI信息。這是因為DPI 137僅轉(zhuǎn)發(fā)那些與分配的簽名相匹配的UE請求(請參見圖11)。例如，如圖6所示，DPI 137和GGSN 136可以是單個設備或位于不同設備中。如下所述，LI的監(jiān)聽檢測功能所在地點可以有多個分支結構。如果GGSN 136和DPI 137集成在同一設備中，信息交換會更為便捷，原因是PDP 上下文數(shù)據(jù)可輕易獲取；此外，UE的IP地址與國際移動用戶識別碼(IMSI)之間的映射也很容易建立，原因是該數(shù)據(jù)也可從GGSN 136獲取。該選項在圖17中被顯示為選項A?；蛘?，若DPI 137是與GGSN 136無關的獨立功能，則也可能至少出現(xiàn)兩個實施例。在第一個實施例中，專有API經(jīng)構造可從GGSN 136獲取將UE IP用作索引的PDP 數(shù)據(jù)。這可具有與Gmc接口相似的構造，其可為拉或推模型。如果DPI 137與DPI-C 181 實現(xiàn)了集成，則可以使用現(xiàn)有的Gmc接口。在第二個實施例中，DPI 136可能只會延遲對DPI-C 181和/或MC182的檢測。 DPI-C 181和/或MC 182會從GGSN 136提取強制更新的LI信息，例如通過Gmc接口提取。 在圖17中，這種方案附有參考標簽選項B。不過，由于監(jiān)聽點就位于GGSN 136所在位置，圖17中描述的實施例仍有一些局限，因此在通過MX-A 124建立UE會話后，對LI標志進行任何更新都不會影響到在會話期間監(jiān)聽通信內(nèi)容的能力。不過，在UE成為監(jiān)聽目標后，可以對任何新的UE會話要求進行監(jiān)控。也就是說，無法對UE上正在進行的會話進行監(jiān)控，而只能對從該時間點開始的新會話進行監(jiān)控。不過，在大多數(shù)LI規(guī)定中，這種限制還是可以接受的，例如在北美地區(qū)就可以接受。圖18和圖19描述了本發(fā)明的實施例，這些實施例用于克服上述限制及其他限制的合法監(jiān)聽。圖18包括圖18A和圖18B，說明了另一個適用于合法監(jiān)聽方法的實施例，其中，層 2網(wǎng)絡中的媒體服務器決定并分發(fā)與目標UE的通信，圖18A說明了實施LI的環(huán)境圖，及圖 18B說明了 LI消息流；參閱圖18A可看到，要實施該實施例，需要提供另外兩個接口 ΧΓ和X3’。在本實施例中，配置GGSN 136以將服務MX-A 124的任何更新通知給LEA的LI請求。MX-A IP地址會根據(jù)Gmc接口的要求在PDP上下文中進行定期維護。因此，GGSN 136 會將服務MX-A IM的任何新LI激活通知給任何UE，這種激活將由UE IP進行確定。GGSN 136還會通知LI目標UE的任何去激活狀況。因此，MX-A會存儲一個列有所有LI目標UE 的列表。在各實施例中，我們會配置MX-A 124，使其具有執(zhí)行詢問的能力，這方面的內(nèi)容我們將在下文進行描述。尤其是MX-A IM經(jīng)配置可對UE標記為目標的任何來往分組數(shù)據(jù)進行鏡像分發(fā)。在多個實施例中，ΧΓ和X3’接口可以通過不同方式實施。在多個實施例中，XI’ 接口可以用來傳輸來自GGSN的控制消息，例如在ADMF做出控制決策后。X3’接口可以用來與GGSN傳輸媒體數(shù)據(jù)，例如監(jiān)聽期間的數(shù)據(jù)。在一個實施例中，例如，RNC 122和GGSN 1 之間的GTP_U/GTP_C消息隧道可通過使用IWF 123實現(xiàn)。在另一個實施例中，可以使用連接MX-A IM和⑶N 180的IP傳輸。不過，要使用 IP傳輸，處于安全方面的原因，必須使用VPN或IPSec協(xié)議。另外，GGSN經(jīng)配置可正確識別 MX-A 124的IP連接上的分組數(shù)據(jù)流是有效的UE流量并轉(zhuǎn)發(fā)至DF3。圖18A所述的LI架構的LI消息流可見圖18B中的說明。消息1801、1803、1805、1806和1808是指符合3GPP標準(TS 3GPP 33. 107)的消息。消息1802、1804和1807根據(jù)本發(fā)明的實施例添加在此處。首先會描述目標激活的過程。ADMF將“目標激活” 1801(目標ID和報告類型等等) 發(fā)送至GGSN。GGSN為PDP上下文中的監(jiān)聽目標設置標志。GGSN將響應結果發(fā)送到ADMF。GGSN檢查監(jiān)聽目標是否具有激活的PDP上下文。如果目標有一個激活的PDP上下文，則GGSN會通知MX-A (目標ID、GGSN IP等)對該目標(消息1802)進行監(jiān)控。如果該目標沒有激活的PDP上下文，則GGSN會等待，直到下一次該目標建立起激活的PDP上下文為止。接下來會描述目標去激活的過程。ADMF將“目標去激活”(目標ID等等)發(fā)送至 GGSN(消息1803)。GGSN會清除監(jiān)聽目標的標志。GGSN對ADMF做出響應，確認進行去激活 (消息1803)。GGSN通知MX-A (目標ID等)清除該目標(消息1804)的監(jiān)控標志。MX-A 為正在去激活的UE清除標志。接下來會對目標查詢過程進行描述。ADMF將“目標查詢”(目標ID等等)發(fā)送至 GGSN(消息1805)。GGSN將響應結果發(fā)送到ADMF。接下來會對監(jiān)控的通信內(nèi)容報告過程進行描述。UE從MX-A接收到所要求的分組數(shù)據(jù)(消息1806)。MX-A還會將分組數(shù)據(jù)(包括目標ID、發(fā)到UE的分組內(nèi)容、GSN IP等) 報告給GGSN，如果將該UE標志為受到監(jiān)聽的話(消息1807)。在多個實施例中，MX-A會向 GGSN輸出分發(fā)流鏡像，其中的數(shù)據(jù)與發(fā)送到UE的數(shù)據(jù)相匹配。GGSN從MX-A將受監(jiān)控的分組數(shù)據(jù)(如包含的目標ID、內(nèi)容、GGSN的IP地址等)報告給DF3。在另一個實施例中，MX-A會直接向DF3發(fā)送詢問(X3)，而不是使用GGSN傳遞接收詢問的分組數(shù)據(jù)流。要實現(xiàn)這一過程，必須將MX-A配置為使用以下X3消息頭信息發(fā)送詢問。X3消息標頭包含目標身份、關聯(lián)編號和可選時間戳。另可包含方向(包括T-PDU是否為移動臺發(fā)起的(MO)或移動臺終結的(MT))和目標位置(若有)。但是此類參數(shù)通常都位于GGSN，因而自MX-A至DF3之間的直接連接可能實用性不夠。圖19包括圖19A和19B，說明了合法監(jiān)聽方法的第三種實施例，其中，層2網(wǎng)絡中的媒體服務器決定并分發(fā)(但通過媒體控制器)與目標UE的通信，圖19A說明了實施LI 的上下文圖，及圖19B說明了 LI消息流；與之前實施例不同，本實施例中，媒體控制器MC具有MX-A與GGSN之間的接口。參閱圖19A可看到，要實施該實施例，需要提供另外三個接口 X1”、X3’和X3”。參閱圖19A 可看到，MC 182 是 GGSN 136 而非 MX-A 124 的接口。GGSN 136 和 MC 182之間的Gmc接口予以利用。因而，并非由GGSN136直接從MC 182通知MX-A 124。本實施例還簡化了接入網(wǎng)與⑶N網(wǎng)絡之間的交互。這是因為Gmc接口已為MC 182提供更新的 LI通知(通過PDP上下文更新進行LI激活、去激活等等)。因此，我們不需要用于傳送控制信息(關于LI激活和取消激活等)的ΧΓ接口。X3，接口是MC 182與GGSN 136之間的詢問分組數(shù)據(jù)流，并針對目標LI UE提供。MC 182與MX-A IM之間的XI”接口可用于傳遞有關LI激活和取消激活的控制信息。圖19A所述的LI架構的LI消息流可見圖19B中的說明。如上所述，ADMF可與將UE激活為目標UE的GGSN進行通信(第1901步)。目標激活可通過Gmc接口與MC通信(第1902步)，還可通過Xl ”接口與MX-A通信(第1903 步)。同樣地，取消目標激活與GGSN通信(第1904步)，再與MC通信(第1905步)，然后轉(zhuǎn)發(fā)到MX-A (第1906步)。然后，ADMF可以請求目標詢問(第1907步)。MX-A可以使用標記為目標的UE來初始化分組數(shù)據(jù)傳輸(第1908步)。MX-A生成與UE之間所進行的分組數(shù)據(jù)通信相匹配的流鏡像。MX-A會通過X3”接口將鏡像分組數(shù)據(jù)傳輸?shù)組C (第1909步)。 MC將鏡像分組數(shù)據(jù)轉(zhuǎn)發(fā)給GGSN (第1910步)。GGSN將從MC中收到的已攔截分組數(shù)據(jù)轉(zhuǎn)發(fā)給DF3(第1911步)?；蛘?，MX-A與DF3之間具有直接接口，防止通過MC和GGSN (第1912 步)O如果正提供服務的MX-A更改為另一 MX-A(例如，安裝在同一 SGSN下)，本實施例甚至可大大有利于漫游過程中的合法監(jiān)聽。這是因為MC收悉本次更改，因而對提供服務的新MX-A進行重定向，以繼續(xù)合法監(jiān)聽。但是如果UE再定位在新GGSN下或MX-A出現(xiàn)故障， 本實施例則可能無效。在本實施例中，與之前實施例不同的是，MC和GGSN之間的接口 X3’是媒體路徑， 而非控制路徑，且可能存在一些限制。因而在一些實施例中，MX-A中受監(jiān)聽的分組數(shù)據(jù)可如之前實施例所述的方式直接發(fā)送至GGSN。在另一個替換實施例中，提供服務的MX-A對MX-B執(zhí)行中流重定向，該操作在GGSN 層級進行部署，從而使所有流量都受到監(jiān)控，并從GGSN發(fā)送到DF3。在多個實施例中，UE不能檢測對當前會話的任何明顯更改，但是提供服務的媒體服務器會被移動到位于網(wǎng)絡中較高層級的媒體服務器上。這可能依次取決于MX-A執(zhí)行中流重定向的方式、媒體類型和分發(fā)協(xié)議(假設視頻內(nèi)容HTTP分發(fā)、MX-B上相同內(nèi)容的可用性和UE客戶端對中流重定向的支持)以及在視頻重定向點的MX-B上開始執(zhí)行的能力。有必要注意的是，這些詢問過程屬于資源密集型和安全敏感型操作。因此，在一些實施例中，將圖17-19中描述的實施例結合起來也許會比較有利。例如，圖17中的實施例可以用于正常處理，而圖18和/或圖19中的實施例則可以用于極端情況下。例如，LEA可能會要求對帶有一些選定目標UE的所有會話進行監(jiān)聽。在此類極少數(shù)情況下，可以部署圖 18和/或圖19中描述的實施例。這樣可確保優(yōu)化資源消耗，而不會影響到合法監(jiān)聽通信內(nèi)容的能力。圖20根據(jù)本發(fā)明的實施例說明了計費、報告和分析方法的處理事宜。在多個實施例中，計費和收費可以包括后付費和預付費兩種計費/收費支持。下圖對計費和其它一些后臺管理功能的環(huán)境進行了說明。本發(fā)明的實施例包括離線收費和實時計費，下文將做進一步描述。首先會描述與離線計費相關的本發(fā)明的一個實施例。經(jīng)過一定的預定時間(如 10分鐘，可配置)后，⑶N 180中的媒體數(shù)據(jù)(MD) 186會收集使用信息并上報到計費中心 (BC)191。根據(jù)本發(fā)明的實施例，可以使用濾波算法。對于費率套餐(即無限制的數(shù)據(jù)套餐) 用戶，可能不需要進行控制。相反，對于其他用戶，其費用取決于所使用的數(shù)據(jù)量，實際監(jiān)控可以取決于用戶規(guī)劃的類型。即使某些用戶的流量超過了合同上規(guī)定的限額，仍可能會允許這些用戶使用流量。不過，被稱為溢出流量的此類流量的計費方式有所不同。本發(fā)明實施例促成對具有分層流量訂閱包的用戶適用準實時計費。根據(jù)一個或多個實施例，MD 186會從所有MX-A節(jié)點收集用戶信息，并每隔一段時間(預定義的分鐘數(shù))將該信息報告給BC 191。因此，若用戶設備會話的流量超過預分配限額或其它限額，會通過準實時計費的方式予以終止。準實時計費要求面向BC 191對用戶活動的持續(xù)通信。對于此類計費方式，用戶流量使用量超額被視為可容許的?；蛘撸瑢τ跊]有任何合同(預付)的用戶或當運營商可能想避免此類用戶的流量超額，可要求進行實時收費。因此將會描述與實時計費相關發(fā)明的實施例。GGSN 136通過Gmc接口通知MC 182新UE的PDP包括在線收費網(wǎng)關(OCG)標志， 該標識指明此特定的UE需要實時收費。將此UE請求重定向到MX-A 124前，MC 182會檢查本地PDP信息是否帶有OCG標志。根據(jù)本發(fā)明的實施例，如果OCG標志顯示有必要進行實時計費，則MC 182不會將該請求重定向到MX-A 124，而會將其轉(zhuǎn)發(fā)到BG 160或路徑中路由器，這樣便可以使用GGSN 136對該請求進行實時計費。因此，在實時計費模式下就不會使用緩存。接下來會對與報告和分析方法相關的實施例進行描述。出于非計費目的生成報告(例如，NOC/運營量、網(wǎng)絡優(yōu)化和DPI簽名/算法調(diào)諧) 可通過MD 186進行。在多個實施例中，MD 186可為基于云的聯(lián)機分析處理(OLAP)，該處理流程適用于處理⑶N網(wǎng)絡的記錄和運營數(shù)據(jù)。根據(jù)本發(fā)明的實施例，由于MBB網(wǎng)絡和⑶N 180之間的交互，故可收集其它數(shù)據(jù) (MBB數(shù)據(jù))。此類其它數(shù)據(jù)可包括用戶的PDP上下文數(shù)據(jù)，例如，存儲在MC 182的數(shù)據(jù)、其它PCRF數(shù)據(jù)(其中一部分已可從Gmc接口獲得)、從PCRF 133獲取其它QoS策略規(guī)定和參數(shù)的直接接口，以及AAA 231和SUR 232 二者功能中的數(shù)據(jù)。在MD 186上可新增并支持與AAA 23USUR 232和PCRF 133之間的接口，以訪問此類其它數(shù)據(jù)。本發(fā)明實施例還包括 AAA23USUR 232,PCRF 133和MD 186之間的接口。使用此類其它數(shù)據(jù)及通過進一步處理， 網(wǎng)絡運營能更好地理解OTT流量(或B2B、B2C流量等等)。與QoS方法相關的發(fā)明的實施例將通過結合使用以下方法和圖20進行說明。QoS策略是通訊網(wǎng)絡中的一個重要因素。與固定寬帶網(wǎng)絡相比，在移動網(wǎng)絡下表現(xiàn)得更為明顯。這是因為相比FBB網(wǎng)絡基礎設施，移動基礎設施受限更多，且成本更高，例如空中接口和遠程回程。在要求對付費更多的用戶進行區(qū)分對待的MBB網(wǎng)絡中，從VIP用戶獲得的收入要比從低端用戶獲得的收入高出100倍或更多。參閱圖20可看到，在第一種方法中，MC 182接收QoS/PCC參數(shù)并將其用于向用戶提供區(qū)別待遇。在MC 182可以傳遞很多QoS/PCC參數(shù)，并通過Gmc接口定期更新。例如， 基于用戶配置文件的計費方式、基于服務類型的計費方式、基于位置的計費方式、基于擁塞的計費方式、基于時間范圍的計費方式、基于用戶累積使用量的計費方式、基于終端類型的計費方式等QoS/PCC參數(shù)MC 182可在MC 182上獲取。MC 182可以使用上述信息，并根據(jù)這些QoS/PCC參數(shù)以及MBB和⑶N網(wǎng)絡的狀況來分配或選擇合適的媒體服務器(MX-A、MX-B或MX-C)。在一個實施例中，通過結合路由請求策略/探試和PCRF 133或GGSN136的UE配置文件和/或QoS參數(shù)，可提高UE的體驗質(zhì)量(QoE)。例如，對于VIP用戶，MC 182上的PDP上下文數(shù)據(jù)子集可指明UE作出的UE請求具有VIP身份，并應適用特殊請求路由處理。 例如，此類VIP總可優(yōu)先路由至正提供服務的MX-A，例如，通過更多(暗示/明示)的向UE 提供最高比特率(適用于有多種比特的情況下)的指令，其中的比特率與PS/RAN鏈路中受保證的吞吐量相匹配。相似的是，如果UE不是VIP用戶，則此類請求可轉(zhuǎn)發(fā)至其它媒體服務器，例如，MX-B 184或MX-C (位于對等點/BG)或在服務提供商(SP)站點，檢索內(nèi)容，以及在PS網(wǎng)絡中吞吐量較低的情況下，保留資源以提供給VIP用戶。在第二個實施例中，MC 182直接從PCRF檢索信息并將此信息用于向MBB和FBB 網(wǎng)絡提供服務。在本實施例中，MC 182通過使用IP承載的線徑上方PCRF 133的直接接口 (AAA/半徑狀接口)，從PCRF 133獲取策略規(guī)定。這有利于MC獲取其他不可從專用GGSN Gmc接口獲取的策略規(guī)定。例如，PCRF 133可控制MBB和FBB QoS策略規(guī)定，因而MC182可獲取適用于特定用戶的常用策略規(guī)定。所以在本實施例中，⑶N 180在MBB和FBB之間直接與一組常見的PCRF節(jié)點運作。在第三個實施例中，MC 182將QoS數(shù)據(jù)子集轉(zhuǎn)發(fā)至正在提供服務的媒體服務器 (例如，MX-A 1M)，之后將該信息用于區(qū)別地向UE提供服務。也可以將QoS策略參數(shù)和規(guī)定從MC 182轉(zhuǎn)發(fā)到(供分析之用的)其他功能組件 (如MX-A 124、MX-B 184、MX-C和MD 186)，并/或轉(zhuǎn)發(fā)到用于B2B和B2C業(yè)務的媒體存儲云。這些組件可以根據(jù)轉(zhuǎn)發(fā)的QoS參數(shù)和規(guī)則、功能/節(jié)點的當前條件以及其他相關環(huán)境參數(shù)做出不同的反應，從而為每個UE類型提供適當QoS。將QoS規(guī)定和參數(shù)轉(zhuǎn)發(fā)到媒體服務器的目的之一在于，這些媒體服務器有能力適應日益變化的隨時分發(fā)要求。例如，比特率適配(已緩存的多速率文件/段)、MX上的按需碼流轉(zhuǎn)換或?qū)γ襟w文件格式或特點的更改(例如，解像度、比特率、移動屏幕尺寸、媒體檔案等等)等方法可動態(tài)予以執(zhí)行，以向UE提供PCRF 133等策略實體要求的最合適的QoS。本發(fā)明實施例還包括對媒體播放器和/或媒體服務器MX-A或MX-B等等的配置， 以便用戶享有更高效的服務，同時享有以下高級功能快速啟動、流暢播放適用的智能緩沖控制、HTTP率上限、對另一臺媒體服務器的中流重定向、媒體服務器故障恢復和/或旨在改善操作并積累業(yè)務智能，從媒體服務器向CDN 180進行的QoS數(shù)據(jù)收集與分發(fā)。圖21說明了根據(jù)本發(fā)明實施例處理媒體服務器的故障。如多個實施例所述，每一個MX-A都向大量的用戶提供實時服務。因而，MX-A的故障可對許多用戶造成重大影響，除非緩解程序準備就緒。首先會描述故障恢復的第一個實施例。如圖21所示，IffF 123被配置為立即檢測 MX-A IM是否出現(xiàn)故障或停止為UE 110提供服務(請參閱圖21中的標為“2201”的虛線部分)。IffF 123或保持與MX-A IM —致的心跳，或每一次IWF 123將消息自UE 110轉(zhuǎn)發(fā)至MX-A IM時設置一個定時器。如果MX-A IM未在心跳定時器之后作出響應或消息響應定時器失效，則IWF IM經(jīng)配置可將此UE請求(或UE重試消息)轉(zhuǎn)發(fā)給位于穿過DPI 137 和DPI-C 181的PS路徑(圖21中的線2211)上提供服務的MC 182。DPI 137和DPI-C181 經(jīng)配置都可將此消息轉(zhuǎn)發(fā)給MC 182，后者也可與出現(xiàn)故障的MX-AlM保持不一致的心跳。 MC 182選擇MX-B 184等另一臺不同的媒體服務器，后者可能與GGSN 136/DPI 137/DPI-C 181相連，并將UE請求重定向至新的媒體服務器MX-B 184。UE 110目前繼續(xù)獲取從MX-B184(圖21中的線2221)分發(fā)的媒體。上述描述方法需要在IWF 123和/或RNC 122上加強，從而檢測MX-A 124故障并將請求正確路由到MC 182。下面我們將描述故障恢復方法的第二個實施例。本實施例說明了上述實施例在 RNC 122和/或IWF 123未修改情況下的簡化。在本實施例中，MC 182檢測MX-A IM故障，例如，由于MX-A IM心跳中斷。MC 182根據(jù)上述描述選擇一個新的媒體服務器，例如，可以選擇MX-B 184。MC182構建一條直接定向至每一臺當前受影響的UE的HTTP消息 (HTTP302)，同時將源地址掩飾為MX-A IM的IP地址。這可能是因為MC 182可輕松獲取 UE中具有IP地址的活動的PDP的列表。MC 182將此類消息傳輸至各個UE。當IWF 123/ RNC 122位置上接收到MC 182的每一條此類消息，IWF 123/RNC 122僅將它們轉(zhuǎn)發(fā)至指定的UE，因為消息是通過正確GTP-U隧道和正確的隧道端點標識符(TEID)而進行傳輸?shù)?。UE 接收此類消息，會為了實現(xiàn)分發(fā)而接觸新的媒體服務器，例如，MX-B 184。上述的第一個及第二個實施例可能存在一些局限。例如，用戶的媒體會話可能突然終止，而且在新媒體服務器MX-B 184開始串流的情況下，新會話可能從媒體剪輯處開始。在使用HTTP自適應串流方式的實施例中，媒體播放器可自上一次會話故障點請求新反饋，因而使用戶無須從開頭觀看媒體剪輯。但是，在本發(fā)明中使用常規(guī)HTTP漸進式下載的第一個及第二個實施例中難以避免這一問題。建議接下來的第三個實施例至少須克服第一個及第二個故障恢復實施例的上述局限。下方的第三個實施例是對第一個及第二個實施例的完善。根據(jù)本實施例，可以增強媒體服務器來處理會話從第一個媒體服務器(MX-A 124) 向另一個媒體服務器(MX-B 184)的轉(zhuǎn)移。如果UE 110上的媒體服務器檢測到其在回放會話中間階段正重定向到另一個媒體服務器(意思是服務中斷)，那么媒體播放器會包括關于該會話的其它信息。例如，媒體播放器可通過始于當前時間代碼(TC)或字節(jié)范圍的BYTE RANGE請求修改面向新媒體播放器(如MX-B 184)的HTTP Get請求。對于HTTP自適應串流方式，僅獲取當前段(幾秒的內(nèi)容)就已足夠，而剩下部分將繼續(xù)取自MX-B 184。本發(fā)明的實施例還包括用于在備份媒體服務器(MX-B 184)出現(xiàn)故障的情況下， 最大程度地控制用戶體驗惡化的方法。例如，根據(jù)本發(fā)明的一個實施例，如果備份媒體服務器MX-B 184也出現(xiàn)故障，則上述的第一個、第二個和/或第三個實施例可以實現(xiàn)。例如， IWF 123或MC 182可檢測到MX-B 184的故障并將UE請求重分配至新的媒體服務器，例如在運營商的PDN的對等點上與BG 160或核心路由器相連的MX-C?；蛘?，MC 182可重定向至CDN 180中的其它MX-B。上述網(wǎng)絡功能和組件有一部分需要重新配置和分配，具體可見下方說明。下方討論可能不包括本發(fā)明實施例實施可能所需的所有配置更改。在一個或多個實施例中，互通功能和無線網(wǎng)絡控制器可能須要予以配置，以識別 IWF可能相連(例如，可能基于)的本地MX-A，例如，IP范圍。IWF/RNC可能須要予以配置， 以識別本地媒體服務器的故障，例如，按照上述說明使用定時器等等。IWF/RNC可能須要予以配置，以識別媒體控制器的IP地址，從而能在本地媒體服務器出現(xiàn)故障的情況下轉(zhuǎn)發(fā)UE 請求。IWF/RNC可能須要配置有服務對象UE適用的IP地址映射關系和隧道端點標識符 (TEID)。IWF/RNC可能須要予以配置，以將新的RNC數(shù)據(jù)包從IuR轉(zhuǎn)發(fā)至IWF/MX-A，例如，促成持續(xù)的串流漫游/重定位或媒體故障。在一個或多個實施例中，GGSN可能須要予以配置，以識別媒體控制器的IP地址。 GGSN可能須要予以配置，以識別GGSN范圍內(nèi)的MX-AIP地址。GGSN可能須要予以配置，從而在DPI查詢GGSN以獲得決策制定所需的上下文信息的情況下識別DPI。GGSN可能須予以配置，以將PDP上下文更新(創(chuàng)建、修改及刪除)發(fā)送至提供服務的MC。GGSN可能須要予以配置，以維護當前面向任何給定的PDP上下文(UE)提供服務的MX-A。在一個或多個實施例中，SGSN可能須要予以配置，以防止在重定位過程中或在其之后出現(xiàn)終止，從而使得先前的MX-A可繼續(xù)向UE分發(fā)媒體流。在一些實施例中，SGSN無法更改，除非我們通過GTP擴展名將其用于RNC IP或ID，從而將該信息傳遞至GGSN并將其作為一個定制參數(shù)用于PDP上下文字段。在一個或多個實施例中，層2接入網(wǎng)中的本地媒體服務器(MX-A)可能須要配置有其為實現(xiàn)LI相關功能而必須予以相連的GGSN IP地址。MX-A可能須要配置有⑶N默認內(nèi)容檢索算法和CDN網(wǎng)絡運營中心向MX-A動態(tài)分配的更新。本配置文件可用于UE請求服務過程中緩存缺失的情況下。MX-A可能須予以配置，以將MX-A本地日志發(fā)送至CDN的MD服務器(例如，用于計費、收費和分析的服務器)。為了合法監(jiān)聽，MX-A可能須要予以配置，以在方法與所使用的DF3存在直接聯(lián)系的情況下識別DF3。在一個或多個實施例中，MX-A可能須予以配置，以接收PDP相關的信息，從而支持朝向DF3的X3接口，例如，目標身份、相關編號和可選時間戳，還可能包含方向(指出傳輸協(xié)議數(shù)據(jù)單元(T-PDU)是移動臺發(fā)起的還是移動臺終結的)，以及目標位置(如果有)。在一個或多個實施例中，媒體控制器可能須配置有其正提供服務的目標GGSN IP 地址，每一個媒體控制器可向多個GGSN提供服務。媒體控制器可能須予以配置，以識別較高層級媒體服務器(MX-B)和DPI-C功能及它們用于轉(zhuǎn)發(fā)消息的IP地址。媒體控制器可能須配置有RNC IP/ID和其MX-A IP地址之間靜態(tài)映射的列表。媒體控制器可能須配置有 PCRF的IP地址。在一個或多個實施例中，媒體數(shù)據(jù)功能可能須予以配置，以識別計費服務器(BS) IP地址并能與IP承載的RESTfUl接口的上方的BS進行通信。媒體數(shù)據(jù)功能可能須予以配置，以識別PCRF IP地址、AAA服務器IP地址和SUR服務器IP地址。在一個或多個實施例中，BS、PCRF, AAA和SUR可能須予以配置，以識別⑶N組件 (例如，MD和MC)。在一個或多個實施例中，用于合法監(jiān)聽的DF3可能須予以配置，以在使用了 “將MX-A導向至DF3選項”方法的情況下識別MX-AIP地址。上述發(fā)明實施例可適用于MBB網(wǎng)絡之外其他類型的網(wǎng)絡。在多個實施例中，MBB網(wǎng)絡可以為2G、2. 5G、3G、4G或更高的蜂窩無線網(wǎng)絡。本發(fā)明的實施例可適用于其它的無線網(wǎng)絡，如WiMAX網(wǎng)絡(或更高的網(wǎng)絡)。同樣，本發(fā)明的實施例還適用于FBB網(wǎng)絡，其中包含數(shù)字用戶線路O(DSL)網(wǎng)絡、有線帶寬網(wǎng)絡、光纖到家/戶 (FTTX)網(wǎng)絡、電力線通信(PLC)網(wǎng)絡等。如WiMAX和其它固定寬帶網(wǎng)絡或有限移動網(wǎng)絡等無線網(wǎng)絡可能都會具有由于OTT流量引起的類似壓力，而這種壓力可以通過上述描述的本發(fā)明實施例來降低。圖22說明了實施上述發(fā)明實施例的)(DSL網(wǎng)絡。如圖22所示，多個UE 2410(如 UE-UUE-2和UE-3)通過接入網(wǎng)絡2320接收服務，該網(wǎng)絡與核心網(wǎng)絡2350通過城域網(wǎng)2330實現(xiàn)耦合。接入網(wǎng)絡2320包含數(shù)字用戶線接入復用器(DSLAM) 2321，后者是一個層2交換機，使用多工技術將多個數(shù)字用戶線路(DSL) (UE 2310)連接至高速互聯(lián)網(wǎng)主干線。DSLAM 2321的流量將切換到2322(在此位置上，終端用戶流量繼而路由至互聯(lián)網(wǎng)2370的ISP網(wǎng)絡)上。BRAS 2322通過業(yè)務路由器2336(其可具有DPI 2337)實現(xiàn)耦合?；蛘撸珼PI 2337 可為城域網(wǎng)2330中的獨立單元。DPI 2337與核心網(wǎng)絡2350中的核心路由器2361及⑶N 2480 中的 DPI-C 2381 耦合。根據(jù)本發(fā)明實施例，具有DPI-C 2381的⑶N 2380決定UE請求是否涉及可緩存內(nèi)容，之后CDN 2380中的MC 2382是否分配媒體服務器向UE 2310提供服務。MC 2382可在接入網(wǎng)2320中分配MX-AMM等本地媒體服務器。在一個實施例中，MX-A 23 如多個實施例所述通過IWF 2323實現(xiàn)耦合，以至于MX-A 23M成為提供服務的媒體服務器，而且運行多個實施例所述的緩存功能。如上述多個實施例所述，DPI-C M81可與DPI 2337、MX-B 2384和/或MC 2382集成。圖23說明了實施上述發(fā)明實施例的有線寬帶網(wǎng)絡。如圖23所示，多個UE 2410 (如UE-l、UE-2和UEI)通過頭端M20接收服務，該頭端與核心網(wǎng)絡M50通過城域網(wǎng) 2430實現(xiàn)耦合。頭端M20包含正交調(diào)幅單元(QAM) 2421，后者使用多工技術將UE 2410連接至高速互聯(lián)網(wǎng)主干線。QAM M21的流量通過層3節(jié)點M22(在此位置上，終端用戶流量繼而路由至互聯(lián)網(wǎng)M70的ISP網(wǎng)絡)進行切換。層3節(jié)點M22通過業(yè)務路由器M36 (其可具有DPI 2437)實現(xiàn)耦合?；蛘撸珼PI M37可為城域網(wǎng)M30中的獨立單元。DPI 2437 與核心網(wǎng)絡M50中的核心路由器M61及CDN2480中的DPI-C 2481相耦合。根據(jù)本發(fā)明的實施例，具有DPI-C M81的CDN2480決定UE是否涉及可緩存內(nèi)容。 CDN 2480中的MC 2482分配媒體服務器向UE 2410提供服務。MC 2482可在頭端M20中分配MX-A MM等本地媒體服務器。在有線寬帶網(wǎng)絡(例如，用于CATV網(wǎng)絡之上)中，纜線頭端可以是MX-AMM的一個良好位置。在一個實施例中，MX-AMM如多個實施例所述通過IWF M23實現(xiàn)耦合，以至于MX-A MM成為提供服務的媒體服務器，而且運行多個實施例所述的緩存功能。如上述多個實施例所述，DPI-C M81可與DPI 2437、MX-B M84和 /或MC 2482集成。如上所述，本發(fā)明的實施例包括PLC網(wǎng)絡。在PLC網(wǎng)絡中，本地媒體服務器(MX-A) 可部署在PLC網(wǎng)絡的低電壓或中等電壓頭端單元中。圖M說明了符合本發(fā)明實施例的代表性媒體設備。媒體設備MOO包括接收器M10，其可包括無線天線接收器和/或(例如，在媒體內(nèi)容存儲在遠程位置的情況下)用于接收媒體內(nèi)容的有線網(wǎng)絡連接端口。媒體設備MOO 還包括存儲器對30，其可包括非易失性存儲器和易失性存儲器。在一個實施例中，圖4-15 及圖17-23所述操作的相關指令可存儲于非臨時性存儲介質(zhì)，例如，存儲器對30中的磁存儲介質(zhì)或固態(tài)存儲介質(zhì)。媒體設備MOO可包括更多用于輸入及輸出數(shù)據(jù)的I/O設備M50。例如，I/O設備 2450可包括諸如激光可讀介質(zhì)之類的光盤(例如，壓縮碟播放器、藍光碟播放器和/或數(shù)字視頻播放器等)。在一個實施例中，圖4-15及圖17-23所述操作的相關指令可存儲于光盤，后者是非臨時性存儲介質(zhì)。媒體設備MOO還可包括顯示器M60和用于發(fā)射壓縮數(shù)據(jù)的發(fā)射器M40。發(fā)射器M40可包括多個無線天線和/或有線端口。發(fā)射器M40和接收器MlO可在一些實施例中進行一并整合。媒體設備MOO包括處理器M20 (經(jīng)配置，其可執(zhí)行圖4-15及圖17_23所述操作的指令)。處理器M20可包含單個處理器或多個處理器。在多個實施例中，媒體設備MOO可以是L2節(jié)點(例如，無線網(wǎng)絡控制器和/或 eNB、IWF)，可以是諸如網(wǎng)關服務器等L3節(jié)點(例如，GGSN、SGSN、包括MX-A、媒體控制器、媒體數(shù)據(jù)功能、DPI、DPI-C、PCRF, CG、DSLAM、BRAS、SRC、QAM,以及多個實施例中所述的其他單元的媒體服務器)(例如，參閱圖4、7、20、22-23)。圖25說明了用于根據(jù)本發(fā)明實施例串流媒體的媒體控制器的組件。媒體控制器可包括圖M所述的一般組件。另外，根據(jù)圖25，媒體控制器(例如，圖M中的處理器M20) 包含接收器2510，后者經(jīng)配置可接收向用戶設備提供媒體服務的請求。經(jīng)配置，緩存信息接收器2520可接收有關媒體內(nèi)容的緩存信息。緩存信息包括有關用戶設備請求的媒體內(nèi)容是否可以緩存的信息。媒體控制器2500還包含分配器2530，后者經(jīng)配置可分配媒體服務器層次集中的第一媒體服務器，使其在待接受服務的媒體內(nèi)容可緩存的情況下向用戶設備提供服務。媒體服務器層次集包含部署在多個層2 (U)接入網(wǎng)的多個第一類媒體服務器。用戶設備通過多個L2接入網(wǎng)的其中一個L2接入網(wǎng)與內(nèi)容分發(fā)網(wǎng)絡耦合。在一個實施例中，媒體控制器的處理器包含多個如接收器2510執(zhí)行一個或多個功能的多個獨立芯片、緩存信息接收器2520和分配器2530。在另一個實施例中，接收器 2510、緩存信息接收器2520和分配器2530的功能可由同一處理器在不同時間執(zhí)行。換而言之，處理器在媒體處理不同階段作為接收器2510、緩存信息接收器2520和分配器2530執(zhí)行操作。圖沈說明了用于根據(jù)本發(fā)明實施例串流媒體的媒體服務器沈00的組件。媒體控制器沈00可包括圖M所述的一般組件。另外，根據(jù)圖沈，媒體控制器沈00 (例如，圖M中的處理器2420)包含接收器沈10，后者經(jīng)配置可接收向用戶設備提供可緩存媒體內(nèi)容服務的請求。用戶設備通過L2接入網(wǎng)與內(nèi)容分發(fā)網(wǎng)絡耦合。經(jīng)配置，測定裝置沈20可確定可緩存媒體內(nèi)容是否存儲于第一媒體服務器中。第一媒體服務器2600不會確定可緩存媒體內(nèi)容是否為可緩存內(nèi)容。如果媒體內(nèi)容已存儲在第一媒體服務器的緩存中，服務器沈30經(jīng)配置便會從緩存將可緩存媒體內(nèi)容提供給用戶設備。在一個實施例中，媒體控制器沈00的處理器包含多個如接收器沈10執(zhí)行一個或多個功能的多個獨立芯片、緩存信息接收器2620和分配器沈30。在另一個實施例中，接收器沈10、緩存信息接收器沈20和分配器沈30的功能可由同一處理器在不同時間執(zhí)行。換而言之，處理器在媒體處理不同階段作為接收器沈10、測定裝置沈20和服務器沈30執(zhí)行操作。圖27說明了用于根據(jù)本發(fā)明實施例串流媒體的內(nèi)容處理器2700的組件。內(nèi)容處理器2700可包括圖M所述的一般組件。另外，根據(jù)圖27，內(nèi)容處理器2700 (例如，圖M 中的處理器2420)包含接收器2710，后者經(jīng)配置可接收向用戶設備提供媒體內(nèi)容服務的請求。用戶設備通過多個L2訪問網(wǎng)絡的L2訪問網(wǎng)絡與內(nèi)容分發(fā)網(wǎng)絡相耦合。經(jīng)配置，測定裝置2720可確定待提供的媒體內(nèi)容是否可緩存。關于向第一媒體服務器提供可緩存媒體內(nèi)容服務的請求，重導器2730經(jīng)配置可對其進行重定向。第一媒體服務器是媒體服務器層次集中的一臺媒體服務器。媒體服務器層次集包括部署在多個L2接入網(wǎng)的多個第一類媒體服務器。在一個實施例中，內(nèi)容處理器2700包含多個如接收器2710執(zhí)行一個或多個功能的多個獨立芯片、測定裝置2720和重導器2730。在另一個實施例中，接收器2710、測定裝置2720和重導器2730的功能可由同一處理器在不同時間執(zhí)行。換而言之，處理器在媒體處理不同階段作為接收器2710、測定裝置2720和重導器2730執(zhí)行操作。圖觀說明了用于根據(jù)本發(fā)明實施例串流媒體的交互功能單元觀00的組件。交互功能單元觀00可包括圖M所述的一般組件。另外，根據(jù)圖觀，交互功能單元觀00包含接收器觀10，后者經(jīng)配置可接收向用戶設備提供可緩存媒體內(nèi)容服務的請求。經(jīng)配置，測定裝置觀20可確定請求的目的地IP地址。經(jīng)配置，轉(zhuǎn)發(fā)器觀30可在目的地IP地址與存儲列表中的目的地IP地址相匹配的情況下，將收到的請求轉(zhuǎn)發(fā)至L2接入網(wǎng)的第一媒體服務器。經(jīng)配置，重新打包工具觀40可將收到的請求重新打包至TCP/IP消息。經(jīng)配置，轉(zhuǎn)發(fā)器 2830可將收到的請求轉(zhuǎn)發(fā)至第一媒體服務器。在一個實施例中，交互功能單元觀00的處理器包含多個如接收器觀10執(zhí)行一個或多個功能的多個獨立芯片、測定裝置觀20、轉(zhuǎn)發(fā)器觀40和重新打包工具觀40。在另一個實施例中，接收器觀10、測定裝置觀20、轉(zhuǎn)發(fā)器觀40和重新打包工具觀40的功能可由同一處理器在不同時間執(zhí)行。換而言之，處理器在媒體處理不同階段作為接收器觀10、測定裝置 2820、轉(zhuǎn)發(fā)器觀40和重新打包工具觀40執(zhí)行操作。圖四說明了用于根據(jù)本發(fā)明實施例串流媒體的第二媒體服務器四00的組件。第二媒體服務器四00包含接收器四10，后者經(jīng)配置可接收向用戶設備提供可緩存媒體內(nèi)容服務的請求。上述請求接收時間的前后，用戶設備自首個層2接入網(wǎng)中的首個層2節(jié)點切換至第二個層2接入網(wǎng)中的第二個層2節(jié)點，而且會自第一媒體服務器終止用戶設備的可緩存媒體內(nèi)容的串流會話。第二媒體服務器四00還包含一個測定裝置2920(經(jīng)配置，其可確定可緩存媒體內(nèi)容是否存儲在儀器緩存中)和一個服務器2930(經(jīng)配置，在媒體內(nèi)容存儲在儀器緩存中的情況下，其可從緩存向用戶設備提供可緩存媒體內(nèi)容的服務)。第二媒體服務器四00可包括圖M所述的一般組件。在一個實施例中，第二媒體服務器四00的處理器包含多個如接收器四10執(zhí)行一個或多個功能的多個獨立芯片、測定裝置四20和服務器四30。在另一個實施例中，接收器 2910、測定裝置四20和服務器四30的功能可由同一處理器在不同時間執(zhí)行。換而言之，處理器在媒體處理不同階段作為接收器四10、測定裝置四20和服務器四30執(zhí)行操作。圖30說明了用于根據(jù)本發(fā)明實施例串流媒體的媒體控制器3000的組件；媒體控制器3000可包括圖M所述的一般組件。媒體控制器3000包含一個接收器3010，后者經(jīng)配置可接收用戶設備的串流媒體內(nèi)容的請求。第二請求接收時間的前后，用戶設備自第一層2接入網(wǎng)中的第一層2節(jié)點切換至第二層2接入網(wǎng)中的第二層2節(jié)點，而且會自第一媒體服務器終止用戶設備的可緩存媒體內(nèi)容的串流會話。經(jīng)配置，分配器3020可指定第二個層2接入網(wǎng)中的第二流媒體服務器來服務用戶設備。在一個實施例中，媒體控制器3000的處理器包含多個如接收器3010執(zhí)行一個或多個功能的多個獨立芯片和分配器3020。在另一個實施例中，接收器3010和分配器3020 的功能可由同一處理器在不同時間執(zhí)行。換而言之，處理器在媒體處理不同階段作為接收器3010和分配器3020執(zhí)行操作。圖31說明了用于根據(jù)本發(fā)明實施例串流媒體的L3節(jié)點3100的組件。L3節(jié)點 3100可包括圖M所述的一般組件。L3節(jié)點3100包含一個監(jiān)控器3110，后者經(jīng)配置可監(jiān)控用戶設備是否正進行切換。經(jīng)配置，L3節(jié)點3100可停止用戶設備與為用戶設備提供服務的第一媒體服務器之間的會話。經(jīng)配置，識別器3120可識別在用戶設備自首個L2節(jié)點至第二個L2節(jié)點進行切換時，正從第一媒體服務器向用戶設備串流的媒體內(nèi)容。經(jīng)配置，L3 節(jié)點3100可向首個L2節(jié)點和第二個L2節(jié)點提供服務。如果用戶設備自首個L2節(jié)點切換至第二個L2節(jié)點，則L3節(jié)點3100經(jīng)配置可不停止自第一流媒體服務器對流媒體內(nèi)容進行串流。在一個實施例中，L2節(jié)點3100的處理器包含多個如監(jiān)控器3110執(zhí)行一個或多個功能的多個獨立芯片和識別器3120。在另一個實施例中，監(jiān)控器3110和識別器3120的功能可由同一處理器在不同時間執(zhí)行。換而言之，處理器在媒體處理不同階段作為監(jiān)控器3110 和識別器3120執(zhí)行操作。圖32說明了用于根據(jù)本發(fā)明實施例串流媒體的媒體服務器3200的組件。媒體服務器3200可包括圖M所述的一般組件。媒體服務器3200包含服務器3210，后者經(jīng)配置可向安裝在第一接入網(wǎng)服務區(qū)的用戶設備提供服務。經(jīng)配置，在用戶設備自第一接入網(wǎng)切換至第二接入網(wǎng)之后，服務器3210可向安裝在第二接入網(wǎng)服務區(qū)的用戶設備提供服務。上述服務包含通過第一接入網(wǎng)中的第一層2節(jié)點、第二接入網(wǎng)中第一層2節(jié)點和第二層2節(jié)點之間的接口，第二層2節(jié)點以及用戶設備與用戶設備的通信。在一個實施例中，媒體控制器3200的處理器包含多個如服務器3210執(zhí)行一個或多個功能的多個獨立芯片。在另一個實施例中，服務器3210的功能可由同一處理器在不同時間執(zhí)行。換而言之，處理器在媒體處理不同階段作為服務器3210執(zhí)行操作。圖33根據(jù)本發(fā)明實施例說明了深層分組檢測節(jié)點3300的組件；深層分組檢測節(jié)點3300可包括圖M所述的一般組件。深層分組檢測節(jié)點3300包含接收器3310 (經(jīng)配置， 其可接收向用戶設備提供媒體內(nèi)容服務的請求)和測定裝置3320(經(jīng)配置，其可確定用戶設備是否為合法監(jiān)聽的目標)。經(jīng)配置，測定裝置3320可確定上述待提供的媒體內(nèi)容在用戶設備為合法監(jiān)聽目標的情況下不可緩存。經(jīng)配置，轉(zhuǎn)發(fā)器3330可在用戶設備為合法監(jiān)聽目標的情況下，對于提供媒體內(nèi)容服務而不造成緩存的請求予以轉(zhuǎn)發(fā)。在一個實施例中，深層分組檢測節(jié)點3300的處理器包含多個如接收器3310執(zhí)行一個或多個功能的多個獨立芯片、測定裝置3320和轉(zhuǎn)發(fā)器3330。在另一個實施例中，接收器3310、測定裝置3320和轉(zhuǎn)發(fā)器3330的功能可由同一處理器在不同時間執(zhí)行。換而言之， 處理器在媒體處理不同階段作為接收器3310、測定裝置3320和轉(zhuǎn)發(fā)器3330執(zhí)行操作。圖34根據(jù)本發(fā)明實施例說明了媒體服務器3400的組件；媒體服務器3400可包括圖M所述的一般組件。媒體服務器3400包含接收器3410，后者經(jīng)配置可接收有關用戶設備的合法監(jiān)聽(Li)的信息。經(jīng)配置，接收器3410還可接收向用戶設備提供可緩存媒體內(nèi)容服務的請求。上述用戶設備通過L2接入網(wǎng)進行耦合。經(jīng)配置，測定裝置3420可基于所接收的LI信息，確定上述用戶設備是否為合法監(jiān)聽的目標。經(jīng)配置，服務器3430可向用戶設備提供可緩存媒體內(nèi)容的服務。經(jīng)配置，生成器3440可生成分發(fā)流鏡像，以在上述用戶設備為合法監(jiān)聽目標的情況下，與上述用戶設備進行所有通信傳輸。
在一個實施例中，媒體服務器3400的處理器包含多個如接收器3410執(zhí)行一個或多個功能的多個獨立芯片、測定裝置；3420、服務器3430和生成器3440。在另一個實施例中，接收器3410、測定裝置3420、服務器3430和生成器3440的功能可由同一處理器在不同時間執(zhí)行。換而言之，處理器在媒體處理不同階段作為接收器3410、測定裝置3420、服務器 3430和生成器；3440執(zhí)行操作。圖35根據(jù)本發(fā)明實施例說明了媒體服務器3500的組件；媒體服務器3500可包括圖M所述的一般組件。媒體服務器3500包含接收器3510，后者經(jīng)配置可從L3節(jié)點接收有關用戶設備的合法監(jiān)聽(Li)的信息。經(jīng)配置，接收器3510還可接收向用戶設備提供可緩存媒體內(nèi)容服務的請求。經(jīng)配置，分配器3520可分配第一媒體服務器來向用戶設備提供媒體內(nèi)容服務。經(jīng)配置，發(fā)射器3530可將LI信息發(fā)射至第一媒體服務器。經(jīng)配置，在用戶設備為合法監(jiān)聽目標的情況下，接收器3510還可接收與用戶設備之間的所有通信的分發(fā)流鏡像。經(jīng)配置，發(fā)射器3530還可將分發(fā)流鏡像發(fā)射至L3節(jié)點。在一個實施例中，媒體服務器3500的處理器包含多個如接收器3510執(zhí)行一個或多個功能的多個獨立芯片、分配器3520和發(fā)射器3530。在另一個實施例中，接收器3510、 分配器3520和發(fā)射器3530的功能可由同一處理器在不同時間執(zhí)行。換而言之，處理器在媒體處理不同階段作為接收器3510、分配器3520和發(fā)射器3530執(zhí)行操作。圖36根據(jù)本發(fā)明實施例說明了媒體控制器3600的組件；媒體控制器3600可包括圖M所述的一般組件。媒體控制器3600包含接收器3610，后者經(jīng)配置可從接入網(wǎng)中的 L3節(jié)點接收用戶配置文件。用戶配置文件包括用戶賬號相關信息和/或用戶設備的網(wǎng)絡特性。經(jīng)配置，接收器3610還可接收向用戶設備提供媒體內(nèi)容服務的請求。經(jīng)配置，分配器 3620可分配從用戶配置文件使用用戶設備信息的第一媒體服務器。經(jīng)配置，在待提供的媒體內(nèi)容可緩存的情況下，分配器3620可分配媒體服務器層次集中的第一媒體服務器來向用戶設備提供服務。媒體服務器層次集包括部署在多個層2 (U)接入網(wǎng)的多個第一類媒體服務器。用戶設備通過多個L2接入網(wǎng)的其中一個L2接入網(wǎng)與內(nèi)容分發(fā)網(wǎng)絡相耦合。在一個實施例中，媒體控制器3600的處理器包含多個如接收器3610執(zhí)行一個或多個功能的多個獨立芯片和分配器3620。在另一個實施例中，接收器3610和分配器3620 的功能可由同一處理器在不同時間執(zhí)行。換而言之，處理器在媒體處理不同階段作為接收器3610和分配器3620執(zhí)行操作。圖37根據(jù)本發(fā)明實施例說明了媒體服務器3700的組件；媒體控制器3700可包括圖M所述的一般組件。媒體控制器3700包含接收器3710，后者經(jīng)配置可從內(nèi)容分發(fā)網(wǎng)絡中的媒體控制器接收用戶配置文件。用戶配置文件包括用戶賬號相關信息和/或用戶設備的網(wǎng)絡特性。經(jīng)配置，接收器3710還可接收向用戶設備提供可緩存媒體內(nèi)容服務的請求。 用戶設備通過L2接入網(wǎng)與內(nèi)容分發(fā)網(wǎng)絡相耦合。經(jīng)配置，測定裝置3720可通過使用用戶配置文件的用戶設備信息，測定用戶設備的體驗質(zhì)量。經(jīng)配置，服務器3730可基于用戶設備的體驗質(zhì)量將可緩存媒體內(nèi)容提供給用戶設備。在一個實施例中，媒體控制器3700的處理器包含多個如接收器3710執(zhí)行一個或多個功能的多個獨立芯片、緩存信息接收器3720和分配器3730。在另一個實施例中，接收器3710、緩存信息接收器3720和分配器3730的功能可由同一處理器在不同時間執(zhí)行。換而言之，處理器在媒體處理不同階段作為接收器3710、測定裝置3720和服務器3730執(zhí)行操作。圖38根據(jù)本發(fā)明實施例說明了媒體數(shù)據(jù)功能3800的成分。媒體數(shù)據(jù)功能3800可包括圖M所述的一般組件。媒體數(shù)據(jù)功能3800包含接收器3810，后者經(jīng)配置可在用戶設備的每個第一時間間隔之后接收流量使用的分發(fā)記錄。用戶設備是用戶準實時計費類別的一部分。流量使用包含用戶設備在層2接入網(wǎng)中與媒體服務器通信期間的數(shù)據(jù)使用情況。 經(jīng)配置，發(fā)射器3820可將分發(fā)記錄中的用戶流量信息發(fā)射至計費及收費策略服務器。經(jīng)配置，接收器3810還可從計費及收費策略服務器接收賬戶狀態(tài)信息。用戶設備在超出用戶帳戶的度量值時會收到帳戶狀態(tài)信息。經(jīng)配置，發(fā)射器3820還可基于賬戶狀態(tài)信息發(fā)射會話終止信息。在一個實施例中，媒體數(shù)據(jù)功能3800的處理器包含多個如接收器3810執(zhí)行一個或多個功能的多個獨立芯片和發(fā)射器3820。在另一個實施例中，接收器3810和發(fā)射器3820 的功能可由同一處理器在不同時間執(zhí)行。換而言之，處理器在媒體處理不同階段作為接收器3810和發(fā)射器3820執(zhí)行操作。圖39根據(jù)本發(fā)明實施例說明了 L2接入網(wǎng)中的媒體服務器3900的組件；媒體服務器3900可包括圖M所述的一般組件。媒體服務器3900包含生成器3910，后者經(jīng)配置可生成其中包含與用戶設備之間正在進行的會話的流量使用情況的分發(fā)記錄。經(jīng)配置，生成器3910可在每隔第一個時間間隔之后定期生成分發(fā)記錄。經(jīng)配置，發(fā)射器3920每隔第二個時間間隔定期發(fā)射分發(fā)記錄。經(jīng)配置，接收器3930可接收會話終止信息。用戶設備在超出用戶帳戶的度量值時會收到會話終止信息。經(jīng)配置，終止器3940可終止與用戶設備之間正在進行的會話。在一個實施例中，媒體服務器3900的處理器包含多個如生成器3910執(zhí)行一個或多個功能的多個獨立芯片、發(fā)射器3920、接收器3930和終止器3940。在另一個實施例中， 接收器3910、發(fā)射器3920、接收器3930和終止器3940的功能可由同一處理器在不同時間執(zhí)行。換而言之，處理器在媒體處理不同階段作為接收器3910、發(fā)射器3920、接收器3930 和終止器3940執(zhí)行操作。圖40根據(jù)本發(fā)明實施例說明了媒體控制器4000的組件。媒體控制器4000可包括圖M所述的一般組件。媒體控制器4000包含接收器4010，后者經(jīng)配置可接收向用戶設備提供媒體內(nèi)容服務的請求。經(jīng)配置，接收器4010可接收分組數(shù)據(jù)協(xié)議(PDP)子集的信息。 PDP包含一種可表示用戶設備收費類型的標志。經(jīng)配置，測定裝置4020可基于上述標志測定用戶設備的收費類型。經(jīng)配置，測定裝置4020可確定上述待提供的媒體內(nèi)容在用戶設備收費類型為實時收費類型的情況下不可緩存。經(jīng)配置，轉(zhuǎn)發(fā)器4030可在用戶設備收費類型為實時收費類型的情況下，對于提供媒體內(nèi)容服務而不造成緩存的請求予以轉(zhuǎn)發(fā)。在一個實施例中，媒體控制器4000的處理器包含多個如接收器4010執(zhí)行一個或多個功能的多個獨立芯片、測定裝置4020和轉(zhuǎn)發(fā)器4030。在另一個實施例中，接收器4010、 測定裝置4020和轉(zhuǎn)發(fā)器4030的功能可由同一處理器在不同時間執(zhí)行。換而言之，處理器在媒體處理不同階段作為接收器4010、測定裝置4020和轉(zhuǎn)發(fā)器4030執(zhí)行操作。圖41根據(jù)本發(fā)明實施例說明了互通功能單元4100的組件?；ネüδ軉卧?100可包括圖M所述的一般組件?；ネüδ軉卧?IWF)4100包含第一數(shù)據(jù)庫4110(經(jīng)配置，其可維護一列部署在首個L2接入網(wǎng)中的本地媒體服務器)和第二數(shù)據(jù)庫4120 (經(jīng)配置，其可維護內(nèi)容分發(fā)網(wǎng)絡中媒體控制器的互聯(lián)網(wǎng)協(xié)議(IP)地址)。經(jīng)配置，媒體控制器可分配媒體服務器來向用戶設備提供服務?；ネüδ軉卧?100還包含故障監(jiān)控器4130 (經(jīng)配置，其可測定一列本地媒體服務器中的一個本地媒體服務器是否出現(xiàn)故障)、接收器4140和轉(zhuǎn)發(fā)器 4150。經(jīng)配置，接收器4140可從用戶設備接收提供媒體內(nèi)容服務的請求。經(jīng)配置，在IWF 4100測定本地媒體服務器已出現(xiàn)故障的情況下，轉(zhuǎn)發(fā)器4150可將用戶設備的請求轉(zhuǎn)發(fā)至媒體控制器。在一個實施例中，互通功能單元4100的處理器包含如第一數(shù)據(jù)庫4110執(zhí)行一個或多個功能的多個獨立芯片、第二數(shù)據(jù)庫4120、故障監(jiān)控器4130、接收器4140和轉(zhuǎn)發(fā)器 4150。在另一個實施例中，第一數(shù)據(jù)庫4110、第二數(shù)據(jù)庫4120、故障監(jiān)控器4130、接收器 4140和轉(zhuǎn)發(fā)器4150的功能可由同一處理器在不同時間執(zhí)行。換而言之，處理器在媒體處理不同階段作為第一數(shù)據(jù)庫4110、第二數(shù)據(jù)庫4120、故障監(jiān)控器4130、接收器4140和轉(zhuǎn)發(fā)器4150執(zhí)行操作。另外，第一數(shù)據(jù)庫4110和第二數(shù)據(jù)庫4120可存儲在圖M中的存儲器 2430 中。圖42根據(jù)本發(fā)明實施例說明了媒體控制器4200的組件。媒體控制器4200可包括圖M所述的一般組件。媒體控制器4200包含分配器4210 (經(jīng)配置，其可分配第一媒體服務器來向用戶設備提供服務，以對向用戶設備提供可緩存媒體內(nèi)容服務的請求作出響應) 和故障監(jiān)控器4220 (經(jīng)配置，其可監(jiān)控第一媒體服務器的狀態(tài)，以確定第一媒體服務器是否出現(xiàn)故障)。媒體控制器4200還包含生成器4230和發(fā)射器4240。經(jīng)配置，生成器4230 可面向用戶設備生成具有第一媒體服務器的源消息的重定向消息。經(jīng)配置，發(fā)射器4240可發(fā)射重定向消息。如果故障監(jiān)控器4220測定第一媒體服務器出現(xiàn)故障，則分配器4210分配第二媒體服務器來向用戶設備提供服務。如果故障監(jiān)控器4220測定第一媒體服務器出現(xiàn)故障，則生成器4230生成重定向消息。重定向消息將用戶設備重定向到第二媒體服務器上。如果故障監(jiān)控器4240測定第一媒體服務器出現(xiàn)故障，則生成器4230發(fā)射重定向消息。在一個實施例中，媒體服務器4200的處理器包含多個如分配器4210執(zhí)行一個或多個功能的多個獨立芯片、故障監(jiān)控器4220、生成器4230和發(fā)射器4240。在另一個實施例中，分配器4210、故障監(jiān)控器4220、生成器4230和發(fā)射器4240的功能可由同一處理器在不同時間執(zhí)行。換而言之，處理器在媒體處理不同階段作為分配器4210、故障監(jiān)控器4220、生成器4230和發(fā)射器4240執(zhí)行操作。如上述具體說明，本發(fā)明的多個實施例具有許多優(yōu)勢。第一，使用本發(fā)明的實施例，能夠有效地實現(xiàn)接入網(wǎng)和⑶N網(wǎng)絡的解耦，以便緩存OTT流量。第二，本發(fā)明的實施例能有利于在L2網(wǎng)絡中部署基于L3的媒體服務器(媒體緩存和適配)，其優(yōu)勢在于能夠免去平時的L2DPI復雜性和決策，而更接近終端用戶。第三，本發(fā)明的實施例支持在單一 CDN 上實現(xiàn)更集中化的內(nèi)容層級DPI (DPI-C)和決策，它能夠同時為MBB和FBB提供服務。因而 DPI-C(內(nèi)容層級深層分組檢測)功能不是接入網(wǎng)中的必要項。第四，本發(fā)明的實施例可能會利用分層緩存網(wǎng)絡以增加緩存匹配率和降低緩存缺失檢索時間。本發(fā)明的實施例還會在已分發(fā)的服務器之間提供緩存媒體服務器備份的分層結構，以備有任何特定服務器發(fā)生故障。第五，本發(fā)明的實施例采用擁有相同網(wǎng)絡配置的、常見、統(tǒng)一的⑶N，通過MBB和FBB網(wǎng)絡以支持0TT、B2B和B2C服務，大幅簡化網(wǎng)絡部署、管理和操作。雖然詳細描述了實施例和它們的優(yōu)勢，但仍請明白這一點可以在不背離專利申請中定義的發(fā)明實質(zhì)和范疇的情況下，進行各種變化、變動和替換。例如，上述的許多特性及功能可在軟件、硬件、固件或以上組合中進行實施。 另外，本申請的范圍并不局限于規(guī)格中描述的流程、機器、制造、物質(zhì)成分、工具、 方法和步驟的特定實施例。這些流程、機器、制造、物質(zhì)成分、工具、方法或步驟，不管是目前已存在還是有待日后開發(fā)，只要是能夠與本文描述的相應的實施例發(fā)揮本質(zhì)上相同的功能或取得本質(zhì)上相同的結果，都可以根據(jù)本發(fā)明而予以采用，作為相關技術中的一個普通技巧。本發(fā)明披露后，技術人員應對這一點有所理解。相應地，隨附的權利要求書旨在將這些流程、機器、制造、物質(zhì)成分、工具、方法或步驟納入權利要求的范圍中。
權利要求
1.一種流媒體服務的方法，其特征在于，所述方法包括從接入網(wǎng)的L3節(jié)點接收用戶配置文件，所述用戶配置文件包括用戶賬號相關信息和/ 或用戶設備的網(wǎng)絡特性；接收向所述用戶設備提供媒體內(nèi)容服務的請求；及使用所述用戶配置文件中的用戶設備信息指定流媒體服務器層次集中的第一流媒體服務器在待提供的流媒體內(nèi)容可緩存的情況下向所述用戶設備提供服務，所述流媒體服務器層次集包括部署于多個層2 (U)接入網(wǎng)中的多個第一類流媒體服務器，所述用戶設備通過所述多個層2接入網(wǎng)中的一個層2接入網(wǎng)與內(nèi)容分發(fā)網(wǎng)絡進行耦合。
2.根據(jù)權利要求1所述的方法，從所述內(nèi)容分發(fā)網(wǎng)絡中的網(wǎng)絡流媒體控制器接收所述用戶配置文件。
3.根據(jù)權利要求1所述的方法，所述用戶配置文件中至少包括下述信息之一，用戶服務套餐信息、用戶設備類型、用戶大概位置、用戶漫游狀態(tài)、用戶組類型和用戶計費偏好類型。
4.根據(jù)權利要求1所述的方法，若所述用戶配置文件包括極重要用戶的用戶服務套餐，則分配第一類媒體服務器；若所述用戶配置文件包括一般重要用戶的用戶服務套餐，則不會分配第一類媒體服務器。
5.權利要求1所述的方法，還包括將所述用戶設備信息發(fā)送至第一類媒體服務器。
6.權利要求1所述的方法，還包括將所述用戶設備信息發(fā)送到媒體數(shù)據(jù)功能，用于對所述用戶設備的流量使用量進行收集和分析。
7.根據(jù)權利要求1所述的方法，所述用戶配置文件包括服務質(zhì)量配置文件。
8.根據(jù)權利要求1所述的方法，所述用戶配置文件接收自網(wǎng)關服務器節(jié)點。
9.根據(jù)權利要求1所述的方法，所述用戶配置文件接收自實施策略與計費規(guī)則功能 (PCRF)。
10.根據(jù)權利要求1所述的方法，還包括接收與所述媒體內(nèi)容相關的緩存信息，所述緩存信息包括有關所述用戶設備所請求的所述流媒體內(nèi)容是否可緩存的信息。
11.根據(jù)權利要求1所述的方法還包括將所述提供流媒體內(nèi)容服務的請求重定向至第一流媒體服務器。
12.根據(jù)權利要求1所述的方法，所述第一類媒體服務器是第一種類型的媒體服務器。
13.根據(jù)權利要求1所述的方法，所述緩存信息接收自內(nèi)容深層數(shù)據(jù)包檢測(DPI-C)節(jié)點ο
14.根據(jù)權利要求13所述的方法，所述DPI-C位于內(nèi)容分發(fā)網(wǎng)絡中。
15.根據(jù)權利要求1所述的方法，所述接收請求包括從媒體控制器接收轉(zhuǎn)發(fā)的GET請求。
16.根據(jù)權利要求15所述的方法還包括通過所述用戶設備將GET請求重定向到第一類媒體服務器上，其中重定向GET請求包括生成包括自用戶設備的所述GET請求HTTP重定向消息；且通過層2接入網(wǎng)中的互通功能節(jié)點將所述GET請求轉(zhuǎn)發(fā)到所述第一類媒體服務器。
17.根據(jù)權利要求1所述的方法，所述分配第一類媒體服務器包括 從以下服務器中選擇所述第一類媒體服務器部署在多個L2接入網(wǎng)中的多個第一類媒體服務器； 部署在多個L3接入網(wǎng)中的多個第二類媒體服務器； 部署在邊界網(wǎng)關的多個第三類媒體服務器，以及部署在對等點的多個第四類媒體服務器。
18.根據(jù)權利要求1所述的方法，所述分配第一類媒體服務器包括在所述用戶設備的分組數(shù)據(jù)協(xié)議(PDP)路徑中選擇媒體服務器，所述媒體服務器部署在層2接入網(wǎng)中。
19.一種流媒體服務的方法，其特征在于，所述方法包括從內(nèi)容分發(fā)網(wǎng)絡中的媒體控制器接收用戶配置文件，所述用戶配置文件包括用戶賬號相關信息和/或用戶設備的網(wǎng)絡特性；接收向用戶設備提供可緩存流媒體內(nèi)容服務的請求，所述用戶設備通過接入網(wǎng)耦合到所述內(nèi)容分發(fā)網(wǎng)絡；使用所述用戶配置文件中的用戶設備信息，確定用戶設備的體驗質(zhì)量，并基于所述用戶設備的體驗質(zhì)量將可緩存媒體內(nèi)容提供給所述用戶設備。
20.根據(jù)權利要求19所述的方法，所述用戶配置文件接收于部署在接入網(wǎng)的層2接入網(wǎng)中的第一媒體服務器。
21.權利要求20所述的方法，還包括確定所述可緩存媒體內(nèi)容是否存儲于所述第一媒體服務器的緩存區(qū)中，所述第一媒體服務器無法確定所述可緩存媒體內(nèi)容是否為可緩存內(nèi)容；且如果所述可緩存媒體內(nèi)容已存儲在所述第一媒體服務器的緩存中，從所述緩存將所述可緩存媒體內(nèi)容提供給所述用戶設備。
22.根據(jù)權利要求21所述的方法，所述提供可緩存流媒體內(nèi)容服務包括選擇與所述接入網(wǎng)所保證的吞吐量相匹配的比特率。
23.根據(jù)權利要求21所述的方法，所述提供可緩存流媒體內(nèi)容服務從轉(zhuǎn)碼視頻速率列表中選擇視頻速率。
全文摘要
在一個實施例中，一種提供媒體服務的方法包括從接入網(wǎng)中的L3節(jié)點(如GGSN 136)接收用戶配置文件，并接收用于向用戶設備110提供媒體內(nèi)容的請求。用戶配置文件包括用戶賬號相關信息和/或用戶設備110的網(wǎng)絡特性。所述的方法還包括使用用戶配置文件中的用戶設備信息，從媒體服務器層次集中分配第一類媒體服務器(如MX-A 124)向用戶設備提供服務，如果媒體內(nèi)容可緩存的話。媒體服務器層次集包括部署在多個層2(L2)接入網(wǎng)的多個第一類媒體服務器。用戶設備110通過多個L2接入網(wǎng)的L2接入網(wǎng)120與內(nèi)容分發(fā)網(wǎng)絡180相耦合。
文檔編號G06F15/16GK102473163SQ201180002746
公開日2012年5月23日 申請日期2011年5月12日 優(yōu)先權日2010年5月13日
發(fā)明者李三琦, 林奎, 田洪波, 錢濤, 韓厚曉 申請人:華為技術有限公司