專利名稱：流媒體QoS保障方法及系統的制作方法
技術領域：
本發明涉及通信領域,具體而言,涉及一種流媒體QoS(Quality of Server,服務質量)保障方法及系統。
背景技術：
P2P是Peer-to-Peer的縮寫，常稱為對等互聯或者點對點技術。相對于傳統的C/S (client/server，客戶端/服務器)模式而言，P2P網絡中的不同Peer節點之間無需經過中繼設備直接交換數據或服務，每個節點的地位都是對等的，擁有對等的權利和義務。如圖1所示，在P2P網絡中，每個節點既可以從其他節點得到服務，也可以向其他節點提供服務。由于P2P技術能夠極大緩解傳統C/S架構中服務器端的壓力過大、單一失效點等問題，又能充分利用終端的豐富資源，所以P2P技術在文件共享、流媒體、語音通信及在線游戲支撐平臺等方面已經獲得廣泛應用。P2P流媒體業務主要是采用P2P技術進行流媒體傳輸，例如PPLive就是典型的P2P流媒體業務，即采用P2P技術實現視頻點播或者直播。當P2P流媒體業務在電信網絡實現時，為了實現對P2P業務的計費和管控，一種較好的實現方式是在現有的IMS(IPMultimedia Subsystem, IP 多媒體子系統)網絡之上構建PPSP (P2P Streaming Protocol,P2P 流媒體協議)網絡，即 MS P2P CDSGMS P2P Content Delivery Service，基于 MS 的P2P內容傳輸業務)網絡。一個典型的MS P2P⑶S系統架構如圖2所示，包含如下網元:UE (User Equipment,用戶設備):發起業務請求并進行終端側相應的業務處理功倉泛。MME (Mobility Management Entity,移動管理實體):接入側網元,主要負責移動
性管理、承載管理等功能。P-Gff(Packet Data Network Gateway,分組數據網絡網關):接入側網元，管理3GPP接入和non-3GPP接入間的移動，還負責策略執行、計費等功能。PCSCF(Proxy-Call Session Control Function,代理呼叫控制功能):IMS 核心網網元，用于終端接入到MS核心網。另外，當PCSCF作為應用層功能和RCF對接時(即由PCSCF充當AF(Application Function,應用功能)時)，還具備如下功能:PCSCF將業務層的 QoS 需求承載在 Diameter ( “直徑”)消息中下發給 RCF (Resource Control Function,資源控制功能)，RCF向其返回執行結果。SCSCF(Session-Call Session Control Function,會話呼叫控制功能):IMS核心網網元，用于對用戶的認證鑒權，會話控制和業務觸發。Tracker (內容跟蹤服務器):存儲資源索引信息，如某個特定的Cache (內容緩存服務器)中存儲的資源信息。另外，當Tracker作為應用層功能和RCF對接時(即由Tracker充當AF時)，還具備如下功能:根據用戶終端能力等信息決策出業務QoS需求；和RCF交互，將業務層的QoS需求承載在Diameter消息中下發給RCF，RCF向其返回執行結果。Cache:存儲具體的資源，如影片內容分片等。RCF:負責接收來自業務實體的業務QoS請求，結合運營商策略和用戶簽約等信息制定相應的資源控制策略，并下發給REF (Resource Enforcement Function,策略執行功能)執行。此外，RCF還可以接收REF上報的事件，發送給相應的業務層功能實體(如PCSCF或 Tracker)。REF:根據RCF下發的資源控制策略進行QoS策略實施和門控、事件上報等功能。REF是個邏輯功能，可以部署在多個網元中。在本架構中REF部署在P-GW網元中。在上述架構中，Tracker和Cache是在MS網絡基礎上增加的網元，其余都是MS中的網元。在MS P2P⑶S網絡中，運營商需要對流媒體業務提供QoS保障，以此來保證用戶體驗(例如保證用戶收看視頻的流暢度以及低延時等)。目前在傳統MS網絡中，現有的QoS保障機制可以通過如下方式實現:P-GW根據QoS策略和UE之間建立專用承載，該專用承載相當于UE和P-GW之間建立的一個專用通道，UE的媒體流承載在專用通道上，以此來保障該UE請求的業務的服務質量。由于P-GW在同一時間會同時接收到很多不同用戶的不同業務的媒體流，并且P-GW也會為很多UE建立各自不同的專用承載，為了區分收到的各個媒體流應該跑在哪個對應的承載上，P-GW需要使用TFT (Traffic Flow Template，流量模板)，TFT相當于IP過濾準則和專用承載對應關系的集合，UE的過濾準則可以由RCF發送給P-GW，過濾準則中包含UE和遠端的媒體面的IP地址和端口號等信息，這些信息可以用來標識UE的某個或多個特定的媒體流。P-GW為UE的過濾準則和將要為UE建立的專用承載的標識之間建立對應關系(即生成TFT)，由于過濾準則可以標識UE特定的媒體流，因此根據這個建立的對應關系即可以確定P-GW收到的媒體流分別應該跑在哪個專用承載上。在頂S P2P⑶S網絡，上述現有的QoS機制的實現流程如圖3所示(僅描述了 Tracker充當AF的場景，PCSCF充當AF的情況類似):步驟S302-步驟S306:UE通過IMS核心網發起內容業務請求，向Tracker請求擁有目標資源的節點列表，消息中攜帶UE要請求的內容信息等。步驟S308-步驟S310 =Tracker獲取存儲了該內容的Cache的地址信息列表，并生成業務QoS需求。步驟S312:Tracker向RCF發送資源預留請求,消息中攜帶業務QoS相關信息、UE標識、UE的媒體面地址和端口列表以及Tracker選擇的Cache的媒體面地址和端口列表，這里Cache可以是多個。步驟S314-步驟S324 =RCF生成QoS決策，之后向P-GW發送策略執行請求消息通知創建承載，消息中攜帶UE的媒體面IP地址和端口列表以及Cache的媒體面地址和端口列表等信息。P-GW根據上述信息建立TFT，并通知UE建立無線承載，之后向RCF發送策略執行響應消息，通知RCF策略已經執行完成。RCF收到后向Tracker返回資源預留響應消息，通知Tracker資源已經預留完成。步驟S326-步驟S330:Tracker向UE發送應答消息，消息中攜帶Tracker獲取的Cache地址列表。步驟S332-步驟S338:UE向所選擇的Cache發送內容請求，Cache向其返回內容請求響應，之后Cache通過之前建立的EPS承載開始向UE發送媒體流。在這個過程中，媒體流將會通過TFT綁定到之前已經建好的專用承載上，從而保障流媒體的QoS。以上是目前現有的QoS機制的實現流程。而根據3GPP的TS 24.008協議，一個UE在相同的P-GW中生成的TFT中所包含的IP過濾準則個數不能超過15個。但在IP過濾準則的生成方式中，如果端口或者IP地址是連續的，那么可以采用范圍或掩碼的方式來描述，使得具備連續端口或IP地址的多條地址信息生成一條IP過濾準則。在頂S P2P⑶S網絡中，由于P2P技術的特殊性，UE可能會從多個Cache同時下載內容分片，這些Cache的數目可能超過了 15個，并且各個Cache由于是分處于不同的位置的實體可能造成他們之間IP地址和端口不是連續的，無法簡單地用地址掩碼和端口范圍來描述，因此在P-GW為這些Cache生成TFT的時候有可能造成TFT中的IP過濾準則數目超過協議限定的15個。針對這個問題，目前尚未提出有效的解決方案。
發明內容
針對現有MS P2P⑶S網絡中，對分處于不同的位置的Cache生成TFT的時候可能造成TFT中的IP過濾準則數目超過目前協議限定的15個，從而導致流媒體QoS得不到保障的問題，本發明提供了一種流媒體QoS保障方法及系統，以解決上述問題。根據本發明的一個方面，提供了一種流媒體QoS保障方法，包括:預置的MediaProxy為存儲了 UE所需資源的Cache分配本地地址信息，并告知P_GW上述本地地址信息；P_GW使用上述本地地址信息建立專用承載并進行承載綁定；MediaPix)Xy根據Cache的地址信息與上述本地地址信息的對應關系通過上述承載在UE及Cache之間轉發媒體流。上述本地地址信息是連續或部分連續的；和/或上述本地地址信息與Cache的地址信息 對應。在MediaProxy為Cache分配上述本地地址信息之前還包括:Tracker或UE向MediaProxy發送攜帶有Cache的地址信息和/或UE的最大連接數的分配地址請求消息。P-Gff使用上述本地地址信息建立專用承載并進行承載綁定包括=MediaProxy向Tracker或UE返回攜帶有上述本地地址信息的分配地址響應消息；Tracker或UE根據上述本地地址信息生成IP過濾準則并發送給P-GW ；P-Gff根據IP過濾準則建立專用承載，并對專用承載進行綁定。MediaProxy根據Cache的地址信息與上述本地地址信息的對應關系通過上述專用承載在UE及Cache之間轉發媒體流包括:Cache將發送給UE的媒體流數據包發送至MediaProxy ；MediaProxy接收到該媒體流數據包后,根據上述對應關系將該媒體流數據包的源地址信息修改為Cache的地址信息對應的本地地址信息，由P-GW將該媒體流數據包通過上述專用承載發送至UE。MediaProxy根據Cache的地址信息與上述本地地址信息的對應關系通過上述專用承載在UE及Cache之間轉發媒體流還包括:UE獲取上述本地地址信息；UE在向Cache的媒體面發送數據包時，將上述本地地址信息作為目標地址信息，由P-GW將該數據包通過上述專用承載發送至MediaProxy ；MediaProxy收到該數據包后,根據上述對應關系將該數據包的目標地址信息由與Cache的地址信息對應的本地地址信息修改為Cache的地址信息，將該數據包發送至Cache。
UE獲取上述本地地址信息包括以下之一:UE接收MediaProxy返回的攜帶有上述本地地址信息的分配地址響應消息；Tracker接收MediaProxy返回的攜帶有本地地址信息的分配地址響應消息，再將上述本地地址信息轉發給UE。上述分配地址請求消息還攜帶有UE的地址信息；在MediaProxy為Cache分配上述本地地址信息或MediaProxy將UE發送給Cache媒體面的數據包的目標地址信息由與Cache的地址信息對應的本地地址信息修改為Cache的地址信息之后還包括:MediaProxy為UE的地址信息分配相應的UE本地地址信息，其中，UE的地址信息與UE本地地址信息
--對應；在MediaProxy將UE發送給Cache媒體面的數據包的目標地址信息由與Cache
的地址信息對應的本地地址信息修改為Cache的地址信息之后還包括=MediaProxy根據UE的地址信息與UE本地地址信息的對應關系將UE發送給Cache媒體面的數據包的源地址信息由UE的地址信息修改為與之對應的UE本地地址信息；在MediaProxy將Cache發送給UE的媒體流數據包的源地址信息修改為Cache的地址信息對應的本地地址信息之后還包括:MediaProxy根據UE的地址信息與UE本地地址信息的對應關系將Cache發送給UE的媒體流數據包的目標地址信息由與UE的地址信息對應的UE本地地址信息修改為UE的地址信肩、OMediaProxy為Cache分配上述本地地址信息之后還包括:當Cache的地址信息發生變更后，MediaProxy根據變更后的Cache的地址信息更新或新建Cache的地址信息與上述本地地址信息的對應關系。在MediaProxy根據變更后的Cache的地址信息更新上述對應關系之前還包括以下之一:MediaProxy通過DPI (Deep Packet Inspection,深度包檢測)獲取變更后的Cache的地址信息；UE通過Tracker通知MediaProxy變更后的Cache的地址信息。根據本發明的另一方面，提供了一種流媒體QoS保障系統，包括=MediaPiOxy,用于為存儲了 UE所需資源的Cache分配本地地址信息，并告知P_GW上述本地地址信息，以及根據Cache的地址信息與上述本地地址信息的對應關系通過UE對應的專用承載在UE及Cache之間轉發媒體流；P_GW，用于使用上述本地地址信息建立上述專用承載并進行承載綁定。通過本發明，采用設置MediaProxy,由MediaProxy為存儲了 UE所需資源的Cache分配連續或部分連續的本地地址信息，并記錄Cache的地址信息與上述本地地址信息的對應關系，根據上述對應關系通過UE對應的專用承載在UE及Cache之間轉發流媒體的業務數據的方案，解決了現有頂S P2P⑶S網絡中，對分處于不同的位置的Cache生成TFT的時候可能造成TFT中的IP過濾準則數目超過目前協議限定的15個的問題，達到了減少TFT中的IP過濾準則數目的效果，使得現有系統可以在不違背現有協議對于TFT和IP過濾準則數目的規定的前提下提供P2P流媒體業務的QoS機制。
此處所說明的附圖用來提供對本發明的進一步理解，構成本申請的一部分，本發明的示意性實施例及其說明用于解釋本發明，并不構成對本發明的不當限定。在附圖中:
圖1是P2P網絡原理示意圖；圖2是現有MS P2P⑶S網絡的功能結構示意；
圖3是現有MS P2P⑶S網絡中QoS保障機制的流程圖；圖4是根據本發明實施例的流媒體QoS保障方法的流程圖；圖5是根據本發明實例的流媒體QoS保障方法應用的系統結構示意圖；圖6是根據本發明實施例一的流媒體QoS保障方法流程圖；圖7是根據本發明實施例二的流媒體QoS保障方法流程圖；圖8是根據本發明實施例三的流媒體QoS保障方法流程圖；圖9是根據本發明實施例四的流媒體QoS保障方法流程圖；圖10是根據本發明實施例五的流媒體QoS保障方法流程圖；圖11是根據本發明實施例六的流媒體QoS保障方法流程圖；圖12是根據本發明實施例的流媒體QoS保障系統的結構框圖。
具體實施例方式下文中將參考附圖并結合實施例來詳細說明本發明。需要說明的是，在不沖突的情況下，本申請中的實施例及實施例中的特征可以相互組合。圖4是根據本發明實施例的流媒體QoS保障方法的流程圖。如圖4所示，根據發明實施例的流媒體QoS保障方法包括:步驟S402，預置的MediaProxy為存儲了 UE所需資源的Cache分配本地地址信息，并告知P-GW上述本地地址信息；步驟S404，P-Gff使用上述本地地址信息建立專用承載并進行承載綁定；步驟S406,MediaProxy根據Cache的地址信息與上述本地地址信息的對應關系通過上述專用承載在UE及Cache之間轉發媒體流。本實施例提供的方法，利用了 IP過濾準則的生成方式中，端口或者IP地址(即地址信息)連續時，可以采用范圍或掩碼的方式來描述，使得具備連續端口或IP地址的多條地址信息生成一條IP過濾準則的特點，為存儲了 UE所需資源的Cache再次分配了MediaProxy本地地址信息，使用該MediaProxy本地地址信息間接的表示Cache自身的地址信息，后續MediaProxy也會根據上述對應關系在UE及Cache之間轉發流媒體的業務數據，這樣，即使Cache自身的地址信息是分散的,通過控制MediaProxy本地地址信息連續的程度也可以保證最終生成的IP過濾準則不會超于目前標準規定的15個，從而保證了 UE及Cache之間的業務數據始終在UE對應的專用承載上轉發，確保了流媒體的QoS。優選地，上述本地地址信息可以是連續或部分連續的，上述本地地址信息也可以是與Cache的地址信息——對應的。由上述IP過濾準則的生成方式的特點可知，上述本地地址信息最好是連續的，或者至少是部分連續的，這樣即可大幅降低生成的IP過濾準則的數目。同時，在資源允許的情況下，最好保證上述本地地址信息是與Cache的地址信息一一對應的，以避免傳輸沖突或錯誤的出現。MediaProxy本地地址信息分配的觸發可以由現有系統中的多個實體實現，但在現有流程的基礎上，由Tracker或UE為MediaProxy提供Cache地址信息，并觸發MediaProxy為Cache分配連續或部分連續的MediaProxy本地地址信息改動最小，實現起來最為容易。優選地，在MediaProxy為Cache分配MediaProxy本地地址信息之前還可以包括:
Tracker或UE向MediaProxy發送攜帶有存儲了 UE所需資源的Cache的地址信息和/或UE的最大連接數的分配地址請求消息。獲取存儲了 UE所需資源的Cache的地址信息是MediaProxy分配MediaProxy本地地址信息的基礎，在具體實施過程中，也可以將UE的最大連接數同時發送給MediaProxy，這樣MediaProxy只分配與UE的最大連接數相同的MediaProxy本地地址信息即可,大大減少了 MediaProxy的負擔。P-Gff使用MediaProxy本地地址信息建立專用承載并進行承載綁定的方式可以是多種多樣的，但其目的都是將再分配的MediaPiOxy本地地址信息作為生成IP過濾準則的依據，本優選實施例在現有流程的基礎上給出一種優選地實施方式。優選地，P-GW使用上述本地地址信息建立專用承載并進行承載綁定可以包括:MediaProxy向Tracker或UE返回攜帶有上述本地地址信息的分配地址響應消息；Tracker或UE根據上述本地地址信息生成IP過濾準則并發送給P_GW ；P-Gff根據上述IP過濾準則建立專用承載，并對專用承載進行綁定。MediaProxy為存儲了 UE所需資源的Cache再次分配了 MediaProxy本地地址信息后，要將分配的MediaProxy本地地址信息通知Tracker或UE,使Tracker或UE根據MediaProxy本地地址信息生成IP過濾準則，再由P_GW根據上述IP過濾準則生成專用承載并進行承載綁定，最簡單的方式就是由MediaProxy直接向Tracker或UE返回攜帶有上述本地地址信息的分配地址響應消息。這里，進行承載綁定也就是使用由IP過濾準則生成的TFT將IP流綁定到不同的承載的過程，TFT實際上相當于IP過濾準則和專用承載對應關系的集合，在承載綁定后，即可保證符合某IP過濾準則的業務數據都會在由該IP過濾準則生成的TFT所綁定到的專用承載上進行轉發，從而保證了流媒體的QoS。優選地,MediaProxy根據Cache的地址信息與上述本地地址信息的對應關系通過上述專用承載在UE及Cache之間轉發媒體流可以包括:Cache將發送給UE的媒體流數據包發送至MediaProxy ；MediaProxy接收到該媒體流數據包后,根據上述對應關系將該媒體流數據包的源地址信息修改為Cache的地址信息對應的MediaProxy本地地址信息，由P-GW將該媒體流數據包通過上述專用承載發送至UE。優選地,MediaProxy根據Cache的地址信息與上述本地地址信息的對應關系通過上述專用承載在UE及Cache之間轉發媒體流還可以包括:UE獲取上述本地地址信息；UE在向Cache的媒體面發送數據包時，將上述本地地址信息作為目標地址信息，由P-GW將該數據包通過上述專用承載發送至MediaProxy ；MediaProxy收到該數據包后,根據上述對應關系將該數據包的目標地址信息由與Cache的地址信息對應的MediaProxy本地地址信息修改為Cache的地址信息,將該數據包發送至Cache。由于MediaProxy為存儲了 UE所需資源的Cache再次分配了間接的表示Cache自身的地址信息的MediaProxy本地地址信息，因此，UE在向Cache的媒體面發送數據包時會直接以該Cache對應的MediaProxy本地地址信息作為目標地址信息，這時，要想UE發送的數據包最終發送到相應的Cache，MediaProxy就需要對UE發送的數據包的目標地址信息按照上述對應關系進行修改。而Cache向UE發送數據包時源地址填寫的則是該Cache自身的地址信息,這時,要想Cache發送的數據包可以使用相應UE對應的專用承載,MediaProxy就需要對Cache發送的數據包的源地址信息按照上述對應關系進行修改，保證Cache發送的數據包符合相應的TFT。通過本優選實施例提供的方法，即可保證始終使用專用承載在Cache和UE之間進行數據轉發，從而保證了流媒體的QoS，這時MediaProxy實際上是作為了 Cache的媒體代理。優選地,UE獲取上述本地地址信息可以包括以下之一:UE接收MediaProxy返回的攜帶有上述本地地址信息的分配地址響應消息；Tracker接收MediaProxy返回的攜帶有上述本地地址信息的分配地址響應消息,再將上述本地地址信息轉發給UE。UE獲取上述本地地址信息有多種實現方式，可以是UE自身向MediaProxy申請的，也可以是Tracker向MediaProxy申請再轉發給UE的。優選地，上述分配地址請求消息還可以攜帶有UE的地址信息；在MediaProxy為Cache分配上述本地地址信息或MediaProxy將UE發送給Cache媒體面的數據包的目標地址信息由與Cache的地址信息對應的MediaProxy本地地址信息修改為Cache的地址信息之后還可以包括:MediaProxy為UE的地址信息分配相應的UE本地地址信息，其中，UE的地址信息與UE本地地址信息——對應；在MediaProxy將UE發送給Cache媒體面的數據包的目標地址信息由與Cache的地址信息對應的MediaProxy本地地址信息修改為Cache的地址信息之后還可以包括:MediaProxy根據UE的地址信息與UE本地地址信息的對應關系將UE發送給Cache媒體面的數據包的源地址信息由UE的地址信息修改為與之對應的UE本地地址信息；在MediaProxy將Cache發送給UE的媒體流數據包的源地址信息修改為Cache的地址信息對應的MediaProxy本地地址信息之后還可以包括:MediaProxy根據UE的地址信息與UE本地地址信息的對應關系將Cache發送給UE的媒體流數據包的目標地址信息由與UE的地址信息對應的UE本地地址信息修改為UE的地址信息。通過本優選實施例提供的方法，MediaProxy即可同時作為Cache和UE的媒體代理，在Cache和UE之間進行數據轉發。優選地，在MediaProxy為Cache分配上述本地地址信息之后還可以包括:當Cache的地址信息發生變更后，MediaProxy根據變更后的Cache的地址信息更新或新建Cache的地址信息與本地地址信息的對應關系。為保證數據包的正確轉發，上述對應關系應該時刻保持在最新的狀態，因此，一旦Cache的地址信息發生了變更，MediaProxy就要對上述對應關系進行更新。優選地,在MediaProxy根據變更后的Cache的地址信息更新或新建上述對應關系之前還可以包括以下之一:MediaProxy通過DPI檢測獲取變更后的Cache的地址信息；UE通過所Tracker通知MediaProxy變更后的Cache的地址信息。本優選實施例給出了兩種優選的獲取變更后的Cache的地址信息的方式，在具體實施過程中，可用的方法包括但不限于上述兩種。下面結合實例對上述優選實施例進行詳細說明。本實例中采用地址映射表表示上述對應關系。圖5是根據本發明實例的流媒體QoS保障方法應用的系統結構示意圖，如圖5所示，該系統包括:
UE:發起業務請求并進行終端側相應的業務處理功能。MME:接入側網元，主要負責移動性管理、承載管理等功能。P-Gff:接入側網元，管理3GPP接入和non_3GPP接入間的移動，還負責策略執行、計費等功能。PCSCF =IMS核心網網元，用于終端接入到MS核心網。SCSCF =IMS核心網網元，用于對用戶的認證鑒權，會話控制和業務觸發。Tracker:內容跟蹤服務器，存儲資源索引信息，如某個特定的Cache中存儲的資源信息。Tracker和MediaProxy之間增加接口，用于Tracker向MediaProxy發送Cache地址以及獲取MediaProxy為Cache分配的本地地址。Cache:內容緩存服務器，存儲具體的資源，如影片內容分片等。RCF:負責接收來自業務實體的業務QoS請求，結合運營商策略和用戶簽約等信息制定相應的資源控制策略，并下發給REF執行。此外，RCF還可以接收REF上報的事件，發送給相應的業務層功能實體。REF:根據RCF下發的資源控制策略進行QoS策略實施和門控、事件上報等功能。REF是個邏輯功能，可以部署在多個網元中。在本架構中REF部署在P-GW網元中。MediaProxy:建立UE和/或Cache的地址映射關系，并根據地址映射關系修改IP報文中的源和/或目的IP地址和/或端口信息并進行報文轉發。MediaProxy 是新增的網兀，MediaProxy 和 Tracker 之間的接口 以及 MediaProxy和P-GW之間的接口是新增的接口。REF部署在P-GW中，P-Gff和RCF之間通過REF功能進行交互，為簡便起見，下述流程圖中沒有示出REF功能。本實例中采用的是Tracker做AF的情況，PCSCF做AF的情況也類似。圖6是根據本發明實施例一的流媒體QoS保障方法流程圖，描述了 MediaProxy僅做Cache媒體代理情況下的一種實現流程，如圖6所示，包括以下步驟:步驟S602:UE向PCSCF發送會話請求(INVITE)消息，該消息是為了向Tracker請求擁有目標資源的節點列表。消息中攜帶UE的終端能力信息(如UE的數據處理能力、屏幕分辨率等)、UE要請求的內容信息，如所需的資源ID及資源類型(如影片是否高清)、UE的(媒體面)IP地址和端口信息。UE的IP地址和端口信息是指后續用于和Cache交互的地址和端口信息，可以預先默認配置，也可以臨時分配，上述端口信息包含一個端口或端口列表或端口范圍。需要注意的是，UE的IP地址和端口信息在后續媒體流傳輸過程中可能只使用部分端口。UE的IP地址和端口信息在整個業務過程中不再更改。步驟S604-步驟S606 =PCSCF收到INVITE消息后，向SCSCF轉發該消息。SCSCF將該消息發給Tracker。步驟S608:Tracker收到SCSCF發送的INVITE消息后，根據INVITE中的資源ID和資源類型等信息獲取并選擇存儲了該資源的Cache地址信息，Cache地址信息包括Tracker選擇的所有Cache的媒體面IP地址和端口信息。步驟S610 =Tracker根據INVITE消息中攜帶的UE終端能力結合本地策略生成業務QoS需求。
步驟S608和步驟S610無嚴格的先后順序關系。步驟S612:Tracker向MediaProxy發送分配地址請求,該請求中攜帶步驟S608中Tracker選擇的所有Cache的地址信息。該消息是請求MediaProxy為Cache在本地分配相應的地址信息并對兩者進行關聯。步驟S614:MediaProxy收到分配地址請求后,根據請求消息中的Cache地址信息數在本地分配相應的地址信息(即IP地址和端口)，所分配的地址信息需和Cache地址信息--對應,并在本地記錄所分配的地址和Cache地址的對應關系，即地址映射表。例如Tracker向MediaProxy發送的請求中攜帶了 30個Cache的地址信息,那么MediaProxy也需要在本地分配30個地址(一個地址包含一個IP地址和一個對應的端口)，
為了方便實現，可以采用分配同一 IP地址和連續端口的方式，MediaProxy為Cache--在
本地分配地址后，在地址映射表中記錄它們的對應關系，后續根據該地址映射表進行地址轉換。步驟S616:MediaProxy向Tracker返回分配地址響應消息,消息中攜帶本地分配的地址信息。后續Tracker將用MediaProxy的地址信息取代原先的Cache地址信息通知
UE0分配地址響應消息中攜帶的本地分配的地址信息要能體現和Cache地址信息的對應關系，例如MediaPiOxy在分配地址響應消 息中將本地分配的地址信息按照分配地址請求消息中Cache的地址信息對應的順序攜帶,或者MediaProxy在分配地址響應消息中除了攜帶本地分配的地址信息外還攜帶各MediaProxy地址對應的Cache地址信息。步驟S618:Tracker向RCF發送資源預留請求,消息中攜帶業務QoS相關信息、UE標識和UE標識和IPFilterRule (IP過濾準則)等。IP過濾準則是Tracker根據UE的IP地址和端口信息及MediaProxy的IP地址和端口信息構建的。步驟S620:RCF收到Tracker發送的資源預留請求后，獲取其中的業務QoS相關信息，結合用戶QoS簽約和本地策略生成QoS決策，根據IP過濾準則信息生成TFT (流量模板，Traffic Flow Template),之后向P_GW發送決策執行請求消息通知創建承載,消息中攜帶UE標識、QoS決策信息以及TFT等信息。后續P-GW可根據TFT進行承載綁定。由上述步驟可以看出，由于UE和MediaProxy的IP地址和端口信息在分配時均可以采用列表或者范圍的形式進行分配，所以最終可以在無需對現有的IPFilterRule及TFT進行擴展的情況下實現IPFilterRule和TFT的構建。步驟S622 =P-Gff收到RCF發送的決策執行請求后，根據消息中攜帶的QoS決策信息分配EPS (Evolved Packet System分組演進系統)承載QoS,即承載層QoS參數。P-GW向MME發送創建承載請求消息，消息中攜帶UE標識、EPS承載QoS信息、TFT、EPS承載標識等。TFT用于IP流的承載綁定。步驟S624 =MME通知UE進行無線承載建立過程。MME在這個過程中將無線承載QoS信息和TFT等參數通知UE。UE根據QoS參數進行資源預留，根據TFT進行承載綁定。步驟S626:完成承載建立相關過程后，MME向P-GW返回創建承載響應消息，帶上EPS承載標識等信息。至此，具備QoS保障的專有承載建立完成。步驟S628 =P-Gff收到MME返回的創建承載響應消息后，向RCF發送決策執行響應消息，通知RCF決策已經執行完成。步驟S630 =RCF收到決策執行響應消息后，向Tracker返回資源預留響應消息，通知Tracker資源已經預留完成。步驟S632 =Tracker收到RCF發送的資源預留響應消息后，向SCSCF發送應答(2000K)消息,消息中攜帶Tracker獲取的Cache列表。Cache列表中攜帶的地址信息是原Cache地址信息對應的MediaProxy地址信息。步驟S634-步驟S636 =SCSCF收到應答消息后，通過PCSCF將該消息轉發給UE。步驟S638:UE收到應答消息后，從消息攜帶的Cache列表中選擇一個或者多個Cache作為內容獲取節點并獲取地址信息。UE從中獲取的地址是和Cache地址信息對應的MediaProxy地址信息。后續UE將MediaProxy地址信息認為是Cache的地址信息，并通過MediaProxy地址和其進行交互。如果之前Tracker沒有通過RCF去通知P_GW建立承載，那么在選擇目標Cache之后，UE也可以主動發起承載修改流程請求P-GW根據目標Cache地址去建立承載。本實施例是Tracker已經通知了 P-GW建立承載，因此UE無需再去請求P-GW新建承載。本實施例以UE選取一個Cache為例，多個Cache的情況類似。為方便描述，將UE選擇的Cache稱為目標Cache。步驟S640:UE向目標Cache發送內容請求消息，該消息的目標IP地址和端口地址填寫與目標Cache地址信息對應的MediaProxy的IP地址和端口。后續網元根據MediaProxy的地址信息進行路由。該消息的源IP地址和端口地址填寫UE的地址信息，該地址信息在步驟S602中UE的地址信息范圍內。P-Gff收到IP包后，根據目的地址信息將其路由到MediaProxy。步驟S642-步驟S644 =MediaProxy從P-GW收到IP包后，根據本地存儲的地址映射表修改報文中的目的地址信息，將IP包中的目的地址和端口修改成對應的Cache地址和端口，源地址不變，依然是UE的地址和端口。之后MediaProxy向Cache發送修改后的IP報文。步驟S646:Cache收到內容請求消息后，向UE返回內容請求響應消息。該消息的IP包中目標地址信息填寫從內容請求消息中獲取到的UE地址和端口，源地址信息填寫Cache相應的地址和端口。該消息首先被路由到MediaProxy。步驟S648-步驟S650 =MediaProxy從Cache收到IP包后，根據本地存儲的地址映射表修改報文中的源地址信息，將IP報文中源地址信息由Cache地址和端口修改成對應的本地地址和端口，目標地址不變，依然是UE的地址和端口信息。之后MediaProxy將該IP包路由到P-GW。P-GW收到IP包后，根據目的地址信息將其轉發至UE。步驟S652 =Cache向UE發送流媒體，流媒體IP包中的源地址和目的地址信息同步驟S6463。流媒體IP包首先被路由到MediaProxy。步驟S654-步驟S656 =MediaProxy對于收到的所有流媒體IP包，均根據本地存儲的地址映射表修改報文中的源地址信息，將IP報文中源地址信息由Cache地址和端口修改成對應的本地地址和端口，目標地址不變，依然是UE的地址和端口信息。之后MediaProxy將流媒體IP包路由到P-GW。P-Gff收到流媒體IP包后，根據目的地址信息將其通過專有承載轉發至UE。
在上述過程中，由于所有P-GW接收到的流媒體IP包中源地址信息都為MediaProxy的IP地址和端口，目的地址都為UE的地址和端口，因此根據之前生成的TFT規貝1J，流媒體的IP流都被映射到專有承載上，從而保證了流媒體業務的QoS。圖7是根據本發明實施例二的流媒體QoS保障方法流程圖，描述了 MediaProxy同時做Cache和UE媒體代理情況下的一種實現流程，如圖7所示，包含以下步驟:步驟S702-步驟S710:同步驟S602-步驟S610。步驟S712:Tracker向MediaProxy發送分配地址請求,該請求中攜帶步驟S708中Tracker選擇的所有Cache的地址信息。該消息是請求MediaProxy為Cache在本地分配相應的地址信息并對兩者進行關聯。此外,該請求中還攜帶UE的(媒體面)IP地址和端口信息。步驟S714:MediaProxy收到分配地址請求后,根據請求消息中的Cache地址信息數在本地分配相應的地址信息(即IP地址和端口)，所分配的地址信息需和Cache地址信息--對應,并在本地記錄所分配的地址和Cache地址的對應關系，即地址映射表。MediaProxy還需要根據請求消息中的UE地址信息數在本地分配相應的地址，所分配的地址信息需和UE地址信息——對應，并在本地記錄所分配的地址和UE地址的對應關系，即UE地址映射表。步驟S716:MediaProxy向Tracker返回分配地址響應消息,消息中攜帶本地分配的地址信息。后續Tracker將用MediaProxy的地址信息取代原先的Cache地址信息通知
UE0
分配地址響應消息中攜帶的本地分配的地址信息要能體現和Cache地址信息的對應關系，例如MediaProxy在分配地址響應消息中將本地分配的地址信息按照分配地址請求消息中Cache的地址信息對應的順序攜帶,或者MediaProxy在分配地址響應消息中除了攜帶本地分配的地址信息外還攜帶各MediaProxy地址對應的Cache地址信息。消息中無需攜帶MediaProxy為UE分配的地址信息。步驟S718-步驟S740:同步驟S618-步驟S640。步驟S742-步驟S744 =MediaProxy從P-GW收到IP包后，根據本地存儲的地址映射表修改報文中的地址信息，將IP包中的目的地址和端口修改成對應的Cache地址和端口，源地址由UE的IP地址和端口修改成本地與其對應的IP地址端口。之后MediaProxy向Cache發送修改后的IP報文。如果此前沒有建立過UE地址映射表，那么MediaProxy也可以在此時在本地為UE分配相應的地址，所分配的地址信息需和該IP包中UE的地址信息對應,并在本地記錄所分配的地址和UE地址的對應關系，即建立UE地址映射表。步驟S746:Cache收到內容請求消息后，向UE返回內容請求響應消息。該消息的IP包中目標地址信息填寫從內容請求消息中獲取到的源地址，即MediaProxy為UE地址分配的對應的地址和端口，源地址信息填寫Cache相應的地址和端口。該消息首先被路由到MediaProxy。步驟S748-步驟S750:MediaProxy從Cache收到IP包后，根據本地存儲的地址映射表修改報文中的地址信息。MediaProxy根據Cache地址映射表將IP報文中源地址信息由Cache地址和端口修改成對應的本地地址和端口，根據UE地址映射表將目標地址由本地的IP地址和端口修改成和該地址對應的UE的IP地址和端口。之后MediaProxy將該IP包路由到P-GW。P-Gff收到IP包后，根據目的地址信息將其轉發至UE。步驟S752 =Cache向UE發送流媒體，流媒體IP包中的源地址和目的地址信息同步驟S746。流媒體IP包首先被路由到MediaProxy。步驟S754-步驟S756 =MediaProxy對于收到的所有流媒體IP包，均根據本地存儲的地址映射表修改報文中的地址信息。修改方法同步驟S748。之后MediaProxy將流媒體IP包路由到P-GW。P-Gff收到流媒體IP包后，根據目的地址信息將其通過專有承載轉發至UE。在上述過程中，由于所有P-GW接收到的流媒體IP包中源地址信息都為MediaProxy的IP地址和端口，目的地址為都UE的地址和端口，因此根據之前生成的TFT規貝1J，流媒體的IP流都被映射到專有承載上，從而保證了流媒體業務的QoS。圖8是根據本發明實施例三的流媒體QoS保障方法流程圖，描述了在MediaProxy已經建立了地址映射表的前提下(參見步驟S602-步驟S616或步驟S702-步驟S716)，Cache (媒體面)地址信息更新后，MediaProxy采用DPI方式獲取更新后的Cache地址信息，并進行地址映射表更新的一種實現流程，如圖8所示，包含以下步驟:步驟S802:UE和Cache通過PPSP消息協商進行Cache地址信息修改。MediaProxy通過DPI檢測對PPSP消息進行檢測并獲取修改后的Cache地址信息。步驟S804:MediaProxy根據新的Cache地址信息對地址映射表進行更新。步驟S806-步驟S822:后續MediaProxy根據更新后的地址映射表修改IP報文中的地址和端口信息并進行轉發。具體過程同步驟S640-步驟S656或步驟S740-步驟S756。圖9是根據本發明實施例四的流媒體QoS保障方法流程圖，描述了在MediaProxy已經建立了地址映射表的前提下(參見步驟S602-步驟S616或步驟S702-步驟S716)，Cache (媒體面)地址信息更新后,通過Tracker通知MediaProxy進行地址映射表更新的一種實現流程，如圖9所示，包含以下步驟:步驟S902:UE和Cache通過協商進行地址信息修改。步驟S904:地址協商修改完成后，UE向Tracker發送消息通知新的地址信息。消息中攜帶Cache更新后的地址信息。通知消息經過PCSCF和SCSCF等網元發送至Tracker。步驟S906:Tracker收到通知消息后，向MediaProxy發送消息通知其更新或新建地址映射信息。消息中攜帶Cache更新后的地址信息。消息中可以攜帶Cache更新前的地址信息，MediaProxy由此可以判斷需要對哪條紀錄進行更新或新建。步驟S908:MediaProxy根據Cache新的地址信息對地址映射表進行更新或新建。步驟S910:MediaProxy完成地址映射表更新后,通知Tracker更新完成。步驟S912:Tracker收到MediaProxy的通知消息后，向UE返回通知消息。步驟S914-步驟S930:同步驟S806-步驟S822。圖10是根據本發明實施例五的流媒體QoS保障方法流程圖，描述了 UE選擇了內容傳輸節點之后再通知MediaProxy建立地址映射表的過程,如圖10所示,包括以下步驟:步驟S1002-步驟 SlOlO:同步驟 S602-步驟 S610。步驟S1012:Tracker向MediaProxy發送分配地址請求。可選地,該請求消息中可以攜帶UE的最大連接數，后續MediaProxy可以參考UE的最大連接數進行地址和/端口分配。步驟S1014:MediaProxy收到請求后，向Tracker返回響應消息，其中攜帶MediaProxy為本次業務分配的地址及端口信息。此地址可以是MediaProxy默認配置的地址和端口，也可以是MediaProxy臨時分配的地址和端口。MediaProxy分配地址和/或端口的具體方法可以由策略決定，例如可以根據UE的最大連接數判斷需要分配多少個地址和/或端口。步驟S1016-步驟 S1036:同步驟 S618-步驟 S638。步驟S1038:UE通知MediaProxy建立地址映射表，消息中攜帶UE選擇的目標Cache的地址和端口信息。步驟S1040 =MediaProxy在目標Cache地址和端口和之前分配的本地地址和端口之間建立地址映射關系。步驟S1042:UE向目標Cache請求內容。步驟S 1044:Cache 向 MediaProxy 發送流媒體包。步驟S1046 =MediaProxy根據地址映射表將IP報文中源地址信息修改成地址映射表中本端的地址和端口。步驟S1048:之后MediaProxy將流媒體IP包路由到P_GW，P-Gff收到流媒體IP包后，根據目的地址信息將其通過專有承載轉發至UE。在上述過程中，由于所有P-GW接收到的流媒體IP包中源地址信息為MediaProxy的IP地址和端口，目的地址為UE的地址和端口，因此根據之前生成的TFT規則，流媒體的IP流都被映射到專有承載上，從而保證了流媒體業務的QoS。需要說明的是，以上實施例中，內容請求和內容請求響應消息也是發往UE和Cache的媒體面地址，如果這兩個消息是發向UE和Cache的信令面地址，那么這兩條消息可以經過MediaProxy轉發，也可以不經過MediaProxy而直接發往對端。圖11是根據本發明實施例六的流媒體QoS保障方法流程圖，描述了 UE選擇了內容傳輸節點(Cache)之后請求MediaProxy為所選擇的目標Cache分配地址并建立地址映射表的過程，如圖11所示，包括以下步驟:步驟S1102:UE發起業務請求并請求peerlist。步驟S1104:Tracker 返回 peerlist。步驟S1106:UE選擇內容緩存服務器。步驟SI 108:UE 通知 Mediaproxy 目標 Cache 地址，請求 Mediaproxy 為目標 Cache分配本地地址。步驟SlllO:Mediaproxy為目標Cache分配本地的地址信息建立地址映射表。步驟S1112:Mediaproxy向UE返回目標Cache對應的本地地址信息。步驟Sll 14:UE使用本地地址信息通知P_GW建立承載。步驟S1116-1122:同步驟 S1042-步驟 S1048。圖12是根據本發明實施例的流媒體QoS保障系統的結構框圖。如圖12所示，根據本發明實施例的流媒體QoS保障系統包括(現有系統中其他實體未示出):MediaProxy 122,用于為存儲了 UE所需資源的內Cache分配本地地址信息,并告知P-GW上述本地地址信息，以及根據Cache的地址信息與上述本地地址信息的對應關系通過UE對應的專用承載在UE及Cache之間轉發媒體流；P-Gff 124，與MediaProxy 122相連，用于使用上述本地地址信息建立上述專用承載并進行承載綁定。在本實施例提供的系統中，MediaProxy 122利用了 IP過濾準則的生成方式中，端口或者IP地址(即地址信息)連續時，可以采用范圍或掩碼的方式來描述，使得具備連續端口或IP地址的多條地址信息生成一條IP過濾準則的特點，為存儲了 UE所需資源的Cache再次分配了 MediaProxy本地地址信息，使用該MediaProxy本地地址信息間接的表示Cache自身的地址信息，后續MediaProxy 122會根據上述對應關系在UE及Cache之間轉發流媒體的業務數據，這樣，即使Cache自身的地址信息十分分散,通過控制MediaProxy本地地址信息連續的程度頁可以保證最終生成的IP過濾準則不會超于目前標準規定的15個，從而保證了 UE及Cache之間的業務數據始終在UE對應的專用承載上轉發，確保了流媒體的QoS。從以上的描述中，可以看出，本發明提供的技術方案可以減少TFT中的IP過濾準則數目，從而解決現有技術中存在的為P2P流媒體業務生成的TFT中的IP過濾準則數目超過協議規定的數目限制的問題，使得P2P流媒體業務可以在遵循現有協議規定的前提下提供QoS機制。顯然，本領域的技術人員應該明白，上述的本發明的各模塊或各步驟可以用通用的計算裝置來實現，它們可以集中在單個的計算裝置上，或者分布在多個計算裝置所組成的網絡上，可選地，它們可以用計算裝置可執行的程序代碼來實現，從而，可以將它們存儲在存儲裝置中由計算裝置來執行，并且在某些情況下，可以以不同于此處的順序執行所示出或描述的步驟，或者將它們分別制作成各個集成電路模塊，或者將它們中的多個模塊或步驟制作成單個集成電路模塊來實現。這樣，本發明不限制于任何特定的硬件和軟件結合。以上所述僅為本發明的優選實施例而已，并不用于限制本發明，對于本領域的技術人員來說，本發明可以有各種更改和變化。凡在本發明的精神和原則之內，所作的任何修改、等同替換、改進等，均應包含在本發明的保護范圍之內。
權利要求
1.一種流媒體服務質量QoS保障方法，其特征在于，包括: 預置的媒體代理網關功能MediaProxy為存儲了用戶設備UE所需資源的內容緩存服務器Cache分配本地地址信息，并告知分組數據網絡網關P-GW所述本地地址信息； 所述P-GW使用所述本地地址信息建立專用承載并進行承載綁定； 所述MediaProxy根據所述Cache的地址信息與所述本地地址信息的對應關系通過所述專用承載在所述UE及所述Cache之間轉發媒體流。
2.根據權利要求1所述的方法，其特征在于， 所述本地地址信息是連續或部分連續的；和/或 所述本地地址信息與所述Cache的地址信息--對應。
3.根據權利要求1所述的方法，其特征在于，在所述MediaProxy為所述Cache分配所述本地地址信息之前還包括: 內容跟蹤服務器Tracker或所述UE向所述MediaProxy發送攜帶有所述Cache的地址信息和/或所述UE的最大連接數的分配地址請求消息。
4.根據權利要求3所述的方法，其特征在于，所述P-GW使用所述本地地址信息建立專用承載并進行承載綁定包括: 所述MediaProxy向所述Tracker或所述UE返回攜帶有所述本地地址信息的分配地址響應消息； 所述Tracker或所述UE根據所 述本地地址信息生成IP過濾準則并發送給所述P-GW ； 所述P-GW根據所述IP過濾準則建立所述專用承載，并對所述專用承載進行綁定。
5.根據權利要求4所述的方法,其特征在于，所述MediaProxy根據所述Cache的地址信息與所述本地地址信息的對應關系通過所述專用承載在所述UE及所述Cache之間轉發媒體流包括: 所述Cache將發送給所述UE的媒體流數據包發送至所述MediaProxy ； 所述MediaProxy接收到該媒體流數據包后，根據所述對應關系將該媒體流數據包的源地址信息修改為所述Cache的地址信息對應的所述本地地址信息，由所述P_GW將該媒體流數據包通過所述專用承載發送至所述UE。
6.根據權利要求5所述的方法,其特征在于，所述MediaProxy根據所述Cache的地址信息與所述本地地址信息的對應關系通過所述專用承載在所述UE及所述Cache之間轉發媒體流還包括: 所述UE獲取所述本地地址信息； 所述UE在向所述Cache的媒體面發送數據包時，將所述本地地址信息作為目標地址信息，由所述P-GW將該數據包通過所述專用承載發送至所述MediaProxy ； 所述MediaPiOxy收到該數據包后，根據所述對應關系將該數據包的目標地址信息由與所述Cache的地址信息對應的所述本地地址信息修改為所述Cache的地址信息,將該數據包發送至所述Cache。
7.根據權利要求6所述的方法，其特征在于，所述UE獲取所述本地地址信息包括以下之一: 所述UE接收所述MediaProxy返回的攜帶有所述本地地址信息的分配地址響應消息； 所述Tracker接收所述MediaProxy返回的攜帶有所述本地地址信息的分配地址響應消息，再將所述本地地址信息轉發給所述UE。
8.根據權利要求6所述的方法，其特征在于， 所述分配地址請求消息還攜帶有所述UE的地址信息； 在所述MediaProxy為所述Cache分配所述本地地址信息或所述MediaProxy將所述UE發送給所述Cache媒體面的數據包的目標地址信息由與所述Cache的地址信息對應的所述本地地址信息修改為所述Cache的地址信息之后還包括:所述MediaProxy為所述UE的地址信息分配相應的UE本地地址信息，其中，所述UE的地址信息與所述UE本地地址信息--對應； 在所述MediaPiOxy將所述UE發送給所述Cache媒體面的數據包的目標地址信息由與所述Cache的地址信息對 應的所述本地地址信息修改為所述Cache的地址信息之后還包括:所述MediaProxy根據所述UE的地址信息與所述UE本地地址信息的對應關系將所述UE發送給所述Cache媒體面的數據包的源地址信息由所述UE的地址信息修改為與之對應的所述UE本地地址信息； 在所述MediaProxy將所述Cache發送給所述UE的媒體流數據包的源地址信息修改為所述Cache的地址信息對應的所述本地地址信息之后還包括:所述MediaProxy根據所述UE的地址信息與所述UE本地地址信息的對應關系將所述Cache發送給所述UE的媒體流數據包的目標地址信息由與所述UE的地址信息對應的所述UE本地地址信息修改為所述UE的地址信息。
9.根據權利要求1-8任一項所述的方法，其特征在于，在所述MediaProxy為所述Cache分配所述本地地址信息之后還包括: 當所述Cache的地址信息發生變更后,所述MediaProxy根據變更后的Cache的地址信息更新或新建所述對應關系。
10.根據權利要求9所述的方法,其特征在于,在所述MediaProxy根據變更后的Cache的地址信息更新所述對應關系之前還包括以下之一: 所述MediaProxy通過深度包檢測DPI獲取變更后的Cache的地址信息； 所述UE通過所述Tracker通知所述MediaProxy變更后的Cache的地址信息。
11.一種流媒體服務質量QoS保障系統，其特征在于，包括: 媒體代理網關功能實體MediaProxy，用于為存儲了用戶設備UE所需資源的內容緩存服務器Cache分配本地地址信息，并告知分組數據網絡網關P-GW所述本地地址信息，以及根據所述Cache的地址信息與所述本地地址信息的對應關系通過所述UE對應的專用承載在所述UE及所述Cache之間轉發媒體流； 所述P-GW，用于使用所述本地地址信息建立所述專用承載并進行承載綁定。
全文摘要
本發明公開了一種流媒體QoS保障方法及系統，上述方法包括預置的MediaProxy為存儲了UE所需資源的Cache分配本地地址信息，并告知P-GW上述本地地址信息；P-GW使用上述本地地址信息建立專用承載并進行承載綁定；MediaProxy根據Cache的地址信息與上述本地地址信息的對應關系通過上述承載在UE及Cache之間轉發媒體流。通過本發明的技術方案，解決了現有IMS P2P CDS網絡中，對分處于不同的位置的Cache生成TFT的時候可能造成TFT中的IP過濾準則數目超過目前協議限定的15個的問題，達到了減少TFT中的IP過濾準則數目的效果。
文檔編號H04N21/647GK103096180SQ20111034330
公開日2013年5月8日 申請日期2011年11月3日 優先權日2011年11月3日
發明者吳建華, 謝振華, 郝振武 申請人:中興通訊股份有限公司