專利名稱：保障流媒體業(yè)務服務質量的方法及系統(tǒng)的制作方法
技術領域：
本發(fā)明涉及一種基于IP多媒體子系統(tǒng)(IMS, IP Multimedia Subsystem)網絡的對等網中業(yè)務服務質量保障技術，尤其涉及一種保障流媒體業(yè)務服務質量的方法及系統(tǒng)。
背景技術：
對等網(P2P, Peer to Peer)技術為對等互聯或者點對點技術。相對于傳統(tǒng)的客戶端/服務器(C/S，Client/Server)模式而言，P2P網絡中的不同Peer節(jié)點之間無需經過中繼設備而直接交換數據 或服務，每個節(jié)點的地位都是對等的，擁有對等的權利和義務。圖I為P2P網絡原理圖，如圖I所示，在P2P網絡中，每個節(jié)點既可以從其他節(jié)點得到服務，也可以向其他節(jié)點提供服務。由于P2P技術能夠極大緩解傳統(tǒng)C/S架構中服務器端的壓力，解決單一失效點等問題，又能充分利用終端的豐富資源，所以P2P技術在文件共享、流媒體、語音通信及在線游戲支撐平臺等方面已經獲得廣泛應用。P2P流媒體業(yè)務主要是采用P2P技術進行流媒體傳輸。目前互聯網工程任務組(IETF, Internet Engineering Task Force)也在制定相關規(guī)范和協議,其中最為普遍接受和被廣泛研究的是P2P流媒體協議(PPSP，P2P Streaming Protocol)。圖2為支持PPSP協議的架構示意圖，主要包含如下實體Tracker :負責存儲內容分片的索引。Peer P2P網絡中的對等節(jié)點，負責存儲內容分片。Peer可以是用戶終端也可以是運營商部署的專門的內容存儲服務器。PPSP具體由tracker協議和peer協議組成，Peer通過tracker協議向tracker注冊自身存儲的內容分片，或通過tracker協議向tracker查詢獲取存儲目標資源的Peer節(jié)點。Peer和Peer之間通過Peer協議互通,獲取所需的內容分片。圖3為應用PPSP協議進行流媒體業(yè)務的基本流程圖，如圖3所示，進行流媒體業(yè)務的基本流程包括以下步驟步驟301 步驟302,用戶設備(UE, User Equipment)首先從Tracker獲取擁有所需內容分片的peer節(jié)點列表。步驟303 步驟305, UE從這些節(jié)點列表中選擇一個或多個目標peer節(jié)點，向所選擇的目標Peer節(jié)點請求內容，目標peer節(jié)點接受請求后將所需內容發(fā)送給UE。當流媒體業(yè)務在電信網絡中實現時，一種較好的實現方式是在MS網絡基礎之上構建PPSP 網絡，S卩基于 MS 的內容傳輸業(yè)務 aMS based CDSjIMS based Content DeliveryService)，該網絡是一種內容分發(fā)網絡，其主要原理是將Tracker作為應用服務器(AS，Application Server)接入到IMS網絡，UE通過IMS網絡進行注冊和計費，UE和Tracker之間的PPSP tracker協議需要承載在會話初始協議(SIP, Session Initiation Protocol)中，并且UE和Tracker之間的消息交互都需要經過MS核心網，而UE和Peer之間的交互則不需要經過MS核心網而直接通過PPSP Peer進行交互。在這種架構下，既能充分利用現有的頂S網絡來實現對流媒體業(yè)務的控制，又能在媒體面?zhèn)鬏敃r充分利用P2P技術的優(yōu)勢。在電信網絡中，為了保證業(yè)務質量，運營商需要對網絡進行服務質量(QoS，Quality of Service)策略控制。目前現有技術中流媒體業(yè)務QoS控制主要是針對流媒體業(yè)務類別采用提前預留固定帶寬的方式，這種方式存在的問題是策略單一且粗略，無法針對不同的用戶、不同的UE和不同的流媒體業(yè)務QoS需求來實現有針對性的QoS策略控制。

發(fā)明內容
有鑒于此，本發(fā)明的主要目的在于提供一種保障流媒體業(yè)務服務質量的方法及系統(tǒng)，能為基于MS網絡的對等網中的業(yè)務提供服務質量保證。為達到上述目的，本發(fā)明的技術方案是這樣實現的一種保障流媒體業(yè)務服務質量的方法，包括
Tracker接收到UE的業(yè)務請求消息，觸發(fā)向所述UE發(fā)送候選內容緩存服務器列表;所述UE將選取的至少一個內容緩存服務器的連接信息通知接入網絡；所述接入網絡根據所述連接信息修改承載信息，使所述UE與所述目的內容緩存服務器之間通過所述承載建立媒體連接，通過所述媒體連接獲取流媒體。優(yōu)選地,所述Tracker接收到UE的業(yè)務請求消息后,所述方法還包括所述Tracker或中間網元通過資源控制功能實體RCF通知所述接入網絡進行資源預留，并在資源預留完成后，由所述Tracker或中間網元向所述UE返回所述候選內容緩存服務器列表。優(yōu)選地，所述方法還包括所述Tracker或中間網元向所述RCF發(fā)送資源預留請求消息；所述RCF接收到所述資源預留請求消息后，生成QoS策略和TFT，通知所述接入網絡進行資源預留。優(yōu)選地，所述資源預留請求消息中包含業(yè)務QoS信息、UE標識、以及UE的媒體面地址和端口信息；所述RCF根據業(yè)務QoS信息、UE用戶QoS簽約信息和運營商策略生成QoS策略，根據UE的媒體面地址和端口信息生成缺省TFT。優(yōu)選地，所述Tracker接收到所述UE的業(yè)務請求消息后，所述方法還包括所述Tracker根據所述業(yè)務請求消息攜帶的UE終端能力信息以及本地策略生成業(yè)務QoS需求。優(yōu)選地，所述UE將選取的至少一個內容緩存服務器的連接信息通知接入網絡，為所述UE與選取的至少一個內容緩存服務器協商媒體面IP地址和端口，將協商的媒體面IP地址和端口信息作為所述接入網絡連接信息通知所述接入網絡。優(yōu)選地，所述媒體面IP地址和端口信息包含協商后的目標內容緩存服務器的媒體面IP地址和端口列表信息；或者，所述媒體面IP地址和端口信息包含協商后的目標內容緩存服務器的媒體面IP地址和端口列表信息，以及，協商后的目標內容緩存服務器的媒體面IP地址和端口列表信息協商后的UE媒體面IP地址和端口列表信息。 優(yōu)選地，所述Tracker根據所述業(yè)務請求消息攜帶的請求資源ID和資源類型的信息獲取存儲所述資源的內容緩存服務器的地址列表。優(yōu)選地，所UE向所述接入網絡發(fā)送承載資源修改請求消息；所述承載資源修改請求消息中攜帶協商后的目標內容緩存服務器的媒體面IP地址和端口列表信息；或者，所述承載資源修改請求消息中攜帶協商后的目標內容緩存服務器的媒體面IP地址和端口列表信息、以及所述UE的媒體面IP地址和端口列表信息。優(yōu)選地，所述目標內容緩存服務器的媒體面IP地址和端口列表信息和/或UE媒體面IP地址和端口列表信息承載于所述承載資源修改請求消息中的TAD參數中。優(yōu)選地，所述UE向所述接入網絡的移動性管理實體MME發(fā)送承載資源修改請求消息；
所述MME接收到所述承載資源修改請求消息后，通過承載資源命令通知所述資源執(zhí)行網關修改承載資源，所述承載資源命令中攜帶所述TAD參數。優(yōu)選地,所述UE將所述接入網絡連接信息通知所述Tracker或中間網元；所述Tracker或中間網元將所述接入網絡連接信息通知所述RCF，由所述RCF將所述接入網絡連接信息通知所述接入網絡。優(yōu)選地，所述UE通過所述SIP消息將所述接入網絡連接信息通知所述Tracker或中間網元；所述Tracker或中間網元通過承載資源修改請求消息將所述接入網絡連接信息通知所述RCF ;所述承載資源修改請求消息中攜帶協商后的目標內容緩存服務器的媒體面IP地址和端口列表信息；或者，所述承載資源修改請求消息中攜帶協商后的目標內容緩存服務器的媒體面IP地址和端口列表信息、以及所述UE的媒體面IP地址和端口列表信息。優(yōu)選地，所述RCF接收到所述承載資源修改請求消息后，根據所述目標內容緩存服務器的媒體面IP地址和端口列表信息和/或UE媒體面IP地址和端口列表信息更新TFT信息；所述RCF向所述資源執(zhí)行網關發(fā)送策略修改請求消息，所述策略修改請求消息中攜帶更新后的所述TFT信息。優(yōu)選地，所述使所述UE與所述目的內容緩存服務器之間通過所述承載建立媒體連接，為所述資源執(zhí)行網關接收到所述承載資源命令或所述策略修改請求消息后，根據所述TAD信息或所述TFT信息更新本地的TFT，并通知所述UE進行承載更新；所述資源執(zhí)行網關使用新的TFT進行承載綁定。優(yōu)選地，所述方法還包括所述UE通過承載資源修改過程將所述接入網絡連接信息通知所述接入網絡時，在所述UE完成承載更新后，通過更新后的承載建立與所述目的內容緩存服務器之間的媒體連接，獲取流媒體；由所述RCF將所述接入網絡連接信息通知所述接入網絡時，所述UE完成承載更新后，由所述RCF通知所述Tracker或中間網元完成承載更新,所述Tracker或中間網元通知所述UE完成承載更新，所述UE通過更新后的承載建立與所述目的內容緩存服務器之間的媒體連接，獲取流媒體。
一種保障流媒體業(yè)務服務質量的系統(tǒng)，包括UE、Tracker、目的內容緩存服務器、RCF和接入網絡，所述Tracker與所述RCF設置有連接接口，其中Tracker，用于接收UE的業(yè)務請求消息，觸發(fā)向所述UE發(fā)送候選內容緩存服務器列表；UE，用于將選取的至少一個內容緩存服務器的連接信息通知接入網絡；接入網絡，用于根據所述連接信息修改承載信息，使所述UE與所述目的內容緩存服務器之間通過所述承載建立媒體連接，通過所述媒體連接獲取流媒體。優(yōu)選地，所述系統(tǒng)還包括中間網元；所述Tracker或中間網元進一步用于，通過所述RCF通知所述接入網絡進行資源 預留，并在資源預留完成后，向所述UE返回所述候選內容緩存服務器列表。優(yōu)選地,所述Tracker或中間網元進一步用于向所述RCF發(fā)送資源預留請求消息；所述RCF進一步用于在接收到所述資源預留請求消息后，生成QoS策略和缺省流量模板TFT，通知所述接入網絡進行資源預留。優(yōu)選地，所述資源預留請求消息中包含業(yè)務QoS信息、UE標識、以及UE的媒體面地址和端口信息；所述RCF進一步用于，根據業(yè)務QoS信息、UE用戶QoS簽約信息和運營商策略生成QoS策略，根據UE的媒體面地址和端口信息生成缺省TFT。本發(fā)明中，Tracker接收到UE的業(yè)務請求消息后，由Tracker或中間網元通過RCF通知所述接入網絡進行資源預留，而在此過程中，RCF會生成QoS策略和缺省TFT，并在接收到資源預留完成的通知后，向接入網絡中的資源執(zhí)行網關發(fā)送策略執(zhí)行請求消息；資源執(zhí)行網關接收到策略執(zhí)行請求消息后進行資源預留，并通知UE創(chuàng)建承載。這樣，就實現對業(yè)務媒體流的QoS控制。本發(fā)明實現了更為靈活和精細化的流媒體QoS策略控制，從而滿足了不同的用戶、不同的終端或不同的流媒體內容傳輸的QoS需求。


圖I為P2P網絡原理圖；圖2為支持PPSP協議的架構示意圖；圖3為應用PPSP協議進行流媒體業(yè)務的基本流程圖；圖4為本發(fā)明實施例的保障流媒體業(yè)務服務質量的系統(tǒng)的結構示意圖；圖5為本發(fā)明實施例一的保障流媒體業(yè)務服務質量的方法的流程圖；圖6為本發(fā)明實施例二的保障流媒體業(yè)務服務質量的方法的流程圖；圖7為本發(fā)明實施例三的保障流媒體業(yè)務服務質量的方法的流程圖；圖8為本發(fā)明實施例四的保障流媒體業(yè)務服務質量的方法的流程圖。
具體實施例方式本發(fā)明的基本思想為=Tracker接收到UE的業(yè)務請求消息后，由Tracker或中間網元通過RCF通知所述接入網絡進行資源預留，而在此過程中，RCF會生成QoS策略和缺省TFT，并在接收到資源預留完成的通知后，向接入網絡中的資源執(zhí)行網關發(fā)送策略執(zhí)行請求消息；資源執(zhí)行網關接收到策略執(zhí)行請求消息后進行資源預留，并通知UE創(chuàng)建承載。這樣，就實現對業(yè)務媒體流的QoS控制。為使本發(fā)明的目的、技術方案和優(yōu)點更加清楚明白，以下舉實施例并參照附圖，對本發(fā)明進一步詳細說明。 圖4為本發(fā)明實施例的保障流媒體業(yè)務服務質量的系統(tǒng)的結構示意圖，如圖4所示，本發(fā)明示例的保障流媒體業(yè)務服務質量的系統(tǒng)包括UE 401、MME 402、P-GW 403、PCSCF404、SCSCF 405、Tracker 406、Cache 407、RCF 408 和 REF 409，其中UE 401，用于發(fā)起業(yè)務請求并進行終端側相應的業(yè)務處理。移動管理實體(MME,Mobility Management Entity) 402,為接入側網兀，主要負責移動性管理、承載管理等功能。分組數據網絡網關(P-GW, Packet Data Network Gateway) 403,為接入側網元,用于管理3GPP接入和non-3GPP接入間的移動，還負責策略執(zhí)行、計費等功能。代理呼叫控制功能實體(PCSCF,ProxyCall Session Control Function) 404,為IMS核心網網元,用于負責終端接入到MS核心網。會話呼叫控制功能實體(SCSCF,Session Call Session Control Function) 405,為MS核心網網元，用于進行用戶的認證鑒權、會話控制和業(yè)務觸發(fā)。Tracker 406，為內容跟蹤服務器，用于存儲資源索引信息，如某個特定的緩存(Cache)中存儲的資源信息。Cache 407，內容緩存服務器，存儲具體的資源，如影片內容分片等。資源控制功能實體(RCF, Resource Control Function) 408,負責接收來自業(yè)務實體的業(yè)務QoS請求，結合運營商策略和用戶簽約等信息制定相應的資源控制策略，并下發(fā)給策略執(zhí)行功能實體(REF, Resource Enforcement Function)執(zhí)行。此外，RCF還可以接收REF上報的事件，發(fā)送給相應的業(yè)務層功能實體。REF 409，根據RCF下發(fā)的資源控制策略進行QoS策略實施和門控、事件上報等功能。REF是邏輯功能實體，可以部署在多個網元中。在本架構中REF部署在P-GW網元中。與RCF對接的網元可以是PCSCF或者Tracker，在實際部署時二選一即可。PCSCF和RCF之間的接口和協議為現有技術，該接口使用Diameter協議。PCSCF將業(yè)務層的QoS需求承載在Diameter消息中下發(fā)給RCF，RCF向其返回執(zhí)行結果。Tracker和RCF之間的接口是新增的接口，該接口使用Diameter協議；其中，Tracker網元新增如下功能I)根據用戶終端能力等信息決策出業(yè)務QoS需求；2)與RCF交互，將業(yè)務層的QoS需求承載在Diameter消息中下發(fā)給RCF，RCF向其返回執(zhí)行結果。下面結合附圖和實施例對本發(fā)明作進一步詳細說明。為方便描述，下面將PCSCF和RCF對接的架構稱為PCSCF作AF (Application Function,應用功能)，將Tracker和RCF對接的架構稱為Tracker作AF。在下述實施例中分別描述了 PCSCF作AF和Tracker作AF的情況。REF部署在P-GW中，P-Gff和RCF之間通過REF功能進行交互，為簡便起見，實施例圖中沒有示出REF功能。圖5為本發(fā)明實施例一的保障流媒體業(yè)務服務質量的方法的流程圖，如圖5所示，本示例為Tracker作AF架構下的一種實現流程。在該實施例中,Tracker向RCF發(fā)送的資源預留請求消息中攜帶UE的媒體面IP地址和端口信息，但可以不攜帶Cache的媒體面地址和端口信息，RCF根據這些信息生成默認的流量模板(TFT，Traffic Flow Template)信息，該默認的TFT信息中不包含Cache具體的媒體面IP地址和端口信息，后續(xù)UE通過承載修改過程對該TFT進行修改，修改后的TFT包含明確的Cache媒體面IP地址和端口列表信息。本示例的保障流媒體業(yè)務服務質量的方法具體包括以下步驟步驟501 UE向PCSCF發(fā)送會話請求(INVITE)消息，該消息是為了向Tracker請求擁有目標資源的節(jié)點列表。消息中攜帶UE的終端能力信息(如UE的數據處理能力、屏幕分辨率等)、UE的媒體面IP地址和端口信息，該信息可以包含O個、I個或多個端口，該媒體面IP地址和端口可以是默認設置的也可以是UE為該業(yè)務動態(tài)分配的，后續(xù)UE可以更改所述媒體面IP地址和端口信息，此外該INVITE消息中還包括UE要請求的內容信息，如所需的資源ID及資源類型(如影片是否是高清)等。步驟502 步驟503 =PCSCF接收到INVITE消息后，向SCSCF轉發(fā)該消息。SCSCF 將該消息發(fā)給Tracker。此為現有技術。步驟504 =Tracker接收到SCSCF發(fā)送的INVITE消息后，根據INVITE中的資源ID和資源類型等信息獲取存儲了該資源的Cache的地址列表，所述Cache的地址列表中包含Cache的信令面地址信息,但可以不包含Cache的媒體面地址信息。步驟505 =Tracker根據INVITE消息中攜帶的UE終端能力結合本地策略生成業(yè)務QoS需求。所述本地策略由運營商自身確定，可以采用但不限于以下方法=Tracker根據INVITE消息中攜帶的UE終端能力結合該影片推薦帶寬確定業(yè)務QoS需求，該業(yè)務QoS需求包括傳輸該影片資源時所需最低保障帶寬和速率。所述影片業(yè)務提供商(SP，ServiceProvider)推薦帶寬是指提供該影片資源的業(yè)務提供商根據一定算法結合該影片播放速度和各分片大小算出的一個相對最優(yōu)值，能保障正常播放時影片的大部分分片能被及時下載。Tracker獲取該影片SP推薦帶寬信息的方式可以采用但不限于1)分片信息中攜帶了該影片SP推薦帶寬，Tracker通過查詢分片信息可獲知相應的影片SP推薦帶寬信息。2)各個影片對應的SP推薦帶寬信息存儲在某個服務器中，在需要時Tracker和該服務器交互獲取該信息。上述步驟504和步驟505之間無嚴格的先后順序關系。步驟506 :Tracker在生成業(yè)務QoS需求后，向RCF發(fā)送資源預留請求,消息中攜帶業(yè)務QoS相關信息、UE標識和UE的媒體面地址和端口信息。所述業(yè)務QoS相關信息根據所述業(yè)務QoS需求產生。步驟507 =RCF接收到Tracker發(fā)送的資源預留請求后，根據業(yè)務QoS相關信息結合用戶QoS簽約和運營商策略生成QoS策略，根據UE的媒體面地址和端口信息生成缺省TFT,由于Tracker沒有向RCF提供Cache的媒體面地址和端口，因此在該TFT中Cache地址對應的參數設為any，端口省略。之后RCF向P-GW發(fā)送策略執(zhí)行請求消息，消息中攜帶UE標識、QoS策略、TFT信息等。步驟508 :P-GW接收到RCF發(fā)送的策略執(zhí)行請求后，并根據消息中攜帶的QoS策略信息分配演進分組系統(tǒng)(EPS, Evolved Packet System)承載QoS,所述EPS承載QoS是指承載層QoS參數，包括QCI、ARP、GBR和MBR。P-Gff向MME發(fā)送創(chuàng)建承載請求消息，消息中攜帶UE標識、EPS承載QoS信息、TFT、EPS承載標識等。所述TFT用于IP流的承載綁定。
步驟509 =MME通知UE進行無線承載建立過程。MME在該過程中將無線承載QoS信息和TFT等參數通知UE。UE根據QoS參數進行資源預留，根據TFT進行承載綁定。步驟510 :完成承載建立相關過程后，MME向P_GW返回創(chuàng)建承載響應消息，帶上EPS承載標識等信息。步驟511 :P-GW接收到MME返回的創(chuàng)建承載響應消息后，向RCF發(fā)送策略執(zhí)行響應消息，通知RCF策略已經執(zhí)行完成。步驟512 :RCF接收到策略執(zhí)行響應消息后，向Tracker返回資源預留響應消息，通知Tracker資源已經預留完成。步驟513 步驟515 =Tracker接收到RCF發(fā)送的資源預留響應消息后，通過SCSCF和PCSCF向UE發(fā)送應答(2000K)消息，消息中攜帶UE所請求的Cache列表。
步驟516 :所述UE獲取到Cache列表后從中選擇一個或者多個Cache作為內容獲取節(jié)點，以下稱為目標Cache。步驟517 :UE和選擇的目標Cache之間協商媒體面IP地址和端口，在該過程中，UE重新分配新的媒體面IP地址和端口列表，Cache也可以動態(tài)分配自身的媒體面IP地址和端口列表，所述UE和\或Cache的媒體面IP地址和端口列表包含一個或多個端口。通過該過程，UE和目標Cache之間通知并獲知了對方的媒體面IP地址和端口列表。本實施例中以UE和一個Cache之間協商為例,多個Cache的情況類似。該協商過程可以通過步驟521 步驟522的內容請求流程實現，也可以通過其他單獨的消息流程實現。步驟518 步驟519 UE通過承載修改流程通知P_GW修改TFT。UE啟動承載修改的流程是，所述UE根據所選擇的目標Cache媒體面地址和端口生成流量聚合描述(TAD，Traffic Aggregate Description)信息，所述TAD信息中包含步驟517中協商確定的UE媒體面IP地址和端口列表以及目標Cache媒體面IP地址和端口列表，并在TAD中指明請求的操作是通知對端修改TFT信息。如果步驟517的協商過程中沒有更改UE之前分配的媒體面IP地址和端口信息，那么所述TAD信息中也可以不攜帶UE媒體面IP地址和端口列表。之后UE向MME發(fā)送承載資源修改請求消息，該承載資源修改請求消息中攜帶承載標識和TAD等信息。MME向P-GW發(fā)送承載資源命令，攜帶承載標識和TAD等信息。步驟520 =P-Gff接收到承載資源命令后，根據TAD信息修改TFT，并通知UE進行承載更新過程。P-GW通知UE進行承載更新的具體過程為現有技術，在此不贅述。此時，TFT中已經有明確的五元組信息，P-Gff可據此進行承載綁定。步驟521 步驟523 UE向所選擇的Cache發(fā)送內容請求,Cache向其返回內容請求響應，之后Cache通過之前建立的EPS承載開始向UE發(fā)送媒體流。在該過程中，媒體流將會通過TFT綁定到之前已經建好的專用承載上，從而保障流媒體的QoS。步驟521 步驟522可以在步驟520之后實現，也可以在步驟518之前實現，也可以在517步驟中實現。當和517步驟合并實現時，即UE和Cache在內容請求交互的同時進行媒體面IP地址和端口協商。圖6為本發(fā)明實施例二的保障流媒體業(yè)務服務質量的方法的流程圖，如圖6所示，本示例為PCSCF作AF架構下的一種實現流程。該實施例和圖5所示實施例一的基本思想相同，區(qū)別點在于，本實施例為Tracker通過PCSCF通知RCF業(yè)務QoS信息，后續(xù)也是由PCSCF和RCF直接進行交互。本實施例的保障流媒體業(yè)務服務質量的方法包括以下步驟步驟601 步驟605 :同步驟501 步驟505。步驟606 步驟607 =Tracker向SCSCF發(fā)送應答(2000K)消息，該2000K消息中攜帶業(yè)務QoS相關信息、UE的媒體面地址和端口信息以及Tracker選擇的Cache列表等信息。SCSCF將應答(2000K)消息轉發(fā)給PCSCF。步驟608 =PSCSF在接收到應答消息后，向RCF發(fā)送資源預留請求。消息中攜帶業(yè)務QoS相關信息、UE標識和UE的媒體面地址和端口信息。步驟609 步驟613 :同步驟507 步驟511。步驟614 :RCF接收到策略執(zhí)行響應消息后，向PCSCF返回資源預留響應消息，通知PCSCF資源已經預留完成。 步驟615 =PCSCF接收到資源預留響應消息后，向UE發(fā)送應答消息，消息中攜帶Tracker選擇的Cache列表。步驟616 步驟623 :同步驟516 步驟523。圖7為本發(fā)明實施例三的保障流媒體業(yè)務服務質量的方法的流程圖，如圖7所示，本示例為Tracker做AF的實現流程。該實施例和圖5所示實施例一的區(qū)別在于UE通知P-Gff修改TFT的方式不同，實施例一是UE通過MME通知P-GW修改TFT，而實施例三是UE通過Tracker去通知RCF修改TFT，RCF再通知P-GW更新TFT。本實施例的保障流媒體業(yè)務服務質量的方法具體包括以下步驟步驟701 步驟717 :同步驟501 步驟517。步驟718 :所述UE將步驟717中協商確定的UE媒體面IP地址和端口列表以及目標Cache媒體面IP地址和端口列表承載在信息消息(INFO)中發(fā)送給PCSCF。如果步驟717的協商過程中沒有更改UE之前分配的媒體面IP地址和端口信息，那么所述INFO消息中也可以不攜帶UE媒體面IP地址和端口列表。步驟719 步驟720 :所述PCSCF接收到INFO消息后，通過SCSCF將消息發(fā)送給Tracker。步驟721 =Tracker接收到INFO消息后，獲取其中的UE媒體面IP地址和端口列表以及目標Cache媒體面IP地址和端口列表信息，并向RCF發(fā)送資源修改請求消息，資源修改請求消息中攜帶獲取的UE媒體面IP地址和端口列表以及目標Cache的媒體面?zhèn)鬏數刂泛投丝诹斜硇畔?。其中如果INFO消息中沒有攜帶UE媒體面IP地址和端口列表，那么資源修改請求消息中就不用攜帶UE媒體面IP地址和端口列表信息。步驟722 :RCF接收到資源修改請求消息后，獲取資源修改請求消息中攜帶的UE和/或Cache媒體面IP地址和列表信息，并根據這些信息更新TFT信息。之后RCF向P-GW發(fā)送策略修改消息，消息中攜帶更新后的TFT信息。步驟723 =P-Gff接收到策略修改消息后，獲取其中的TFT信息更新本地存儲的TFT信息，此時，TFT中已經有明確的五元組信息，P-GW可據此進行承載綁定。之后P-GW通知UE進行承載更新過程。P-GW通知UE進行承載更新的具體過程為現有技術，在此不贅述。步驟724 :完成承載更新過程后，P-Gff向RCF發(fā)送策略修改完成消息。步驟725 :RCF在接收到策略修改完成消息后，向Tracker發(fā)送資源修改確認消息，通知Tracker資源已經修改完成。步驟726 步驟728 =Tracker在接收到資源修改確認消息后，通過SCSCF、PCSCF向UE發(fā)送確認消息。步驟729 步驟731 :UE接收到確認消息后，可知承載TFT已經修改完成。之后UE同目標Cache進行交互并開始媒體流傳輸過程，同步驟521 步驟523。圖8為本發(fā)明實施例四的保障流媒體業(yè)務服務質量的方法的流程圖，如圖8所示，本示例為PCSCF做AF的實現流程，與前述實施例四的基本思想相同，其區(qū)別點在于，實施例四是Tracker通過PCSCF通知RCF業(yè)務QoS信息，后續(xù)也是由PCSCF和RCF直接進行交互。 本實施例的保障流媒體業(yè)務服務質量的方法具體包括以下步驟步驟801 步驟817 :同步驟601 步驟617。步驟818 :UE將選擇的目標Cache的媒體面地址和端口信息承載在信息消息(INFO)中發(fā)送給PCSCF。所述UE將步驟817中協商確定的UE媒體面IP地址和端口列表以及目標Cache媒體面IP地址和端口列表承載在信息消息(INFO)中發(fā)送給PCSCF。如果步驟817的協商過程中沒有更改UE之前分配的媒體面IP地址和端口信息，那么所述INFO消息中也可以不攜帶UE媒體面IP地址和端口列表。步驟819 =PCSCF接收到INFO消息，并向RCF發(fā)送資源修改請求消息，消息中攜帶INFO消息中獲取的UE媒體面IP地址和端口列表以及目標Cache的媒體面?zhèn)鬏數刂泛投丝诹斜硇畔ⅰＦ渲腥绻鸌NFO消息中沒有攜帶UE媒體面IP地址和端口列表，那么資源修改請求消息中就不用攜帶UE媒體面IP地址和端口列表信息。步驟820 步驟822 :同步驟722 步驟724。步驟823 :RCF在接收到策略修改完成消息后，向PCSCF發(fā)送資源修改確認消息，通知PCSCF資源已經修改完成。步驟824 步驟827 :同步驟728 步驟731。從上述方案的分析可知，采取本發(fā)明的方法，實現了更為靈活和精細化的流媒體QoS策略控制，并且解決了現有技術中無法進行精細化策略控制的問題。本發(fā)明同時記載了一種保障流媒體業(yè)務服務質量的系統(tǒng)，包括UE、Tracker、目的內容緩存服務器、RCF和接入網絡，所述Tracker與所述RCF設置有連接接口，其中 Tracker,用于接收UE的業(yè)務請求消息，觸發(fā)向所述UE發(fā)送候選內容緩存服務器列表；UE，用于將選取的至少一個內容緩存服務器的連接信息通知接入網絡；接入網絡，用于根據所述連接信息修改承載信息，使所述UE與所述目的內容緩存服務器之間通過所述承載建立媒體連接，通過所述媒體連接獲取流媒體。其中，所述系統(tǒng)還包括中間網元；所述Tracker或中間網元進一步用于，通過所述RCF通知所述接入網絡進行資源預留，并在資源預留完成后，向所述UE返回所述候選內容緩存服務器列表。其中，所述Tracker或中間網元進一步用于向所述RCF發(fā)送資源預留請求消息；所述RCF進一步用于在接收到所述資源預留請求消息后，生成QoS策略和缺省流量模板TFT，通知所述接入網絡進行資源預留。其中，所述資源預留請求消息中包含業(yè)務QoS相關信息、UE標識、以及UE的媒體面地址和端口信息；所述RCF進一步用于，根據業(yè)務QoS相關信息、用戶QoS簽約信息和運營商策略生成QoS策略，根據UE的媒體面地址和端口信息生成缺省TFT。其中，所述UE進一步用于，與選取的至少一個內容緩存服務器協商媒體面IP地址和端口，將協商的媒體面IP地址和端口信息作為所述接入網絡連接信息通知所述接入網絡。其中，所述媒體面IP地址和端口信息包含協商后的目標內容緩存服務器的媒體面IP地址和端口列表信息；或者，所述媒體面IP地址和端口信息包含協商后的目標內容緩存服務器的媒體 面IP地址和端口列表信息，以及，協商后的目標內容緩存服務器的媒體面IP地址和端口列表信息協商后的UE媒體面IP地址和端口列表信息。其中，所述RCF進一步用于向所述接入網絡中的資源執(zhí)行網關發(fā)送策略執(zhí)行請求消息；所述資源執(zhí)行網關用于，接收到策略執(zhí)行請求消息后進行資源預留，通知所述UE創(chuàng)建承載。其中，所述策略執(zhí)行請求消息包含UE標識、QoS策略、TFT信息；所述資源執(zhí)行網關進一步用于，根據所述策略執(zhí)行請求消息中的QoS策略信息和TFT信息預留資源，通知所述UE創(chuàng)建承載。其中，所述資源執(zhí)行網關進一步用于，在完成資源預留后，通知所述RCF ；所述RCF進一步用于,通知所述Tracker或中間網元資源預留完成；所述Tracker或中間網元進一步用于,接收到完成資源預留的通知后，向所述UE返回所述候選內容緩存服務器列表。其中，所述UE進一步用于，通過承載資源修改過程將所述接入網絡連接信息通知所述接入網絡。其中，所UE進一步用于向所述接入網絡發(fā)送承載資源修改請求消息；所述承載資源修改請求消息中攜帶協商后的目標內容緩存服務器的媒體面IP地址、端口列表信息；或者，所述承載資源修改請求消息中攜帶協商后的目標內容緩存服務器的媒體面IP地址和端口列表信息、以及所述UE的媒體面IP地址和端口列表信息；其中，所述目標內容緩存服務器的媒體面IP地址和端口列表信息和/或UE媒體面IP地址和端口列表信息承載于所述承載資源修改請求消息中的流量聚合描述TAD參數中。其中，所述接入網絡還包括MME ;所述UE進一步用于向所述接入網絡的移動性管理實體MME發(fā)送承載資源修改請求消息；MME進一步用于，在接收到所述承載資源修改請求消息后，通過承載資源命令通知所述資源執(zhí)行網關修改承載資源，所述承載資源命令中攜帶所述TAD參數。其中，所述UE進一步用于將所述接入網絡連接信息通知所述Tracker或中間網元；所述Tracker或中間網元將所述接入網絡連接信息通知所述RCF，由所述RCF將所述接入網絡連接信息通知所述接入網絡。其中，所述UE進一步用于，通過所述SIP消息將所述接入網絡連接信息通知所述Tracker或中間網元；所述Tracker或中間網元進一步用于，通過承載資源修改請求消息將所述接入網絡連接信息通知所述RCF ;所述承載資源修改請求消息中攜帶協商后的目標內容緩存服務器的媒體面IP地址和端口列表信息；或者，所述承載資源修改請求消息中攜帶協商后的目標內容緩存服務器的媒體面IP地址和端口列表信息、以及所述UE的媒體面IP地址和端口列表信息；所述RCF進一步用于，在接收到所述承載資源修改請求消息后，根據所述目標內容緩存服務器的媒體面IP地址和端口列表信息和/或UE媒體面IP地址和端口列表信息更新TFT信息；所述RCF向所述資源執(zhí)行網關發(fā)送策略修改請求消息，所述策略修改請求消息中攜帶更新后的所述TFT信息。 其中，所述資源執(zhí)行網關進一步用于，在接收到所述承載資源命令或所述策略修改請求消息后，根據所述TAD信息或所述TFT信息更新本地的TFT，通知所述UE進行承載更新；所述資源執(zhí)行網關使用新的TFT進行承載綁定。其中，所述UE進一步用于，通過承載資源修改過程將所述接入網絡連接信息通知所述接入網絡時，在所述UE完成承載更新后，通過更新后的承載建立與所述目的內容緩存服務器之間的媒體連接，獲取流媒體；由所述RCF將所述接入網絡連接信息通知所述接入網絡時，所述UE進一步用于，完成承載更新后，由所述RCF通知所述Tracker或中間網元完成承載更新,所述Tracker或中間網元通知所述UE完成承載更新，所述UE通過更新后的承載建立與所述目的內容緩存服務器之間的媒體連接，獲取流媒體。其中，所述中間網元中設置有REF ;所述中間網元為PCSCF。本領域技術人員應當理解，本發(fā)明保障流媒體業(yè)務服務質量的系統(tǒng)對現有網絡系統(tǒng)的結構并無實質性改變，只是利用Tracker與RCF之間設置的連接接口，實現了由RCF針對流媒體業(yè)務制定相應的QoS策略并執(zhí)行對接入流媒體業(yè)務的QoS控制。本發(fā)明保障流媒體業(yè)務服務質量的系統(tǒng)中各網元的功能，可結合圖4至圖8相應的描述而理解。以上所述，僅為本發(fā)明的較佳實施例而已，并非用于限定本發(fā)明的保護范圍。
權利要求
1.一種保障流媒體業(yè)務服務質量的方法，其特征在于，所述方法包括 跟蹤服務器Tracker接收到用戶終端UE的業(yè)務請求消息，觸發(fā)向所述UE發(fā)送候選內容緩存服務器列表； 所述UE將選取的至少一個內容緩存服務器的連接信息通知接入網絡； 所述接入網絡根據所述連接信息修改承載信息，使所述UE與所述目的內容緩存服務器之間通過所述承載建立媒體連接，通過所述媒體連接獲取流媒體。
2.根據權利要求I所述的方法，其特征在于，所述Tracker接收到UE的業(yè)務請求消息后，所述方法還包括 所述Tracker或中間網元通過資源控制功能實體RCF通知所述接入網絡進行資源預留，并在資源預留完成后，由所述Tracker或中間網元向所述UE返回所述候選內容緩存服務器列表。
3.根據權利要求2所述的方法，其特征在于，所述方法還包括 所述Tracker或中間網元向所述RCF發(fā)送資源預留請求消息； 所述RCF接收到所述資源預留請求消息后，生成服務質量QoS策略和缺省流量模板TFT，通知所述接入網絡進行資源預留。
4.根據權利要求3所述的方法，其特征在于，所述資源預留請求消息中包含業(yè)務QoS信息、UE標識、以及UE的媒體面地址和端口信息； 所述RCF根據業(yè)務QoS信息、UE用戶QoS簽約信息和運營商策略生成QoS策略，根據UE的媒體面地址和端口信息生成缺省TFT。
5.根據權利要求I所述的方法，其特征在于，所述Tracker接收到所述UE的業(yè)務請求消息后，所述方法還包括 所述Tracker根據所述業(yè)務請求消息攜帶的UE終端能力信息以及本地策略生成業(yè)務QoS需求。
6.根據權利要求I所述的方法，其特征在于，所述UE將選取的至少一個內容緩存服務器的連接信息通知接入網絡，為 所述UE與選取的至少一個內容緩存服務器協商媒體面IP地址和端口，將協商的媒體面IP地址和端口信息作為所述接入網絡連接信息通知所述接入網絡。
7.根據權利要求6所述的方法，其特征在于，所述媒體面IP地址和端口信息包含協商后的目標內容緩存服務器的媒體面IP地址和端口列表信息； 或者，所述媒體面IP地址和端口信息包含協商后的目標內容緩存服務器的媒體面IP地址和端口列表信息，以及，協商后的目標內容緩存服務器的媒體面IP地址和端口列表信息協商后的UE媒體面IP地址和端口列表信息。
8.根據權利要求6所述的方法,其特征在于,所述Tracker根據所述業(yè)務請求消息攜帶的請求資源ID和資源類型的信息獲取存儲所述資源的內容緩存服務器的地址列表。
9.根據權利要求7所述的方法，其特征在于，所UE向所述接入網絡發(fā)送承載資源修改請求消息；所述承載資源修改請求消息中攜帶協商后的目標內容緩存服務器的媒體面IP地址和端口列表信息；或者，所述承載資源修改請求消息中攜帶協商后的目標內容緩存服務器的媒體面IP地址和端口列表信息、以及所述UE的媒體面IP地址和端口列表信息。
10.根據權利要求9所述的方法，其特征在于，所述目標內容緩存服務器的媒體面IP地址和端口列表信息和/或UE媒體面IP地址和端口列表信息承載于所述承載資源修改請求消息中的流量聚合描述TAD參數中。
11.根據權利要求10所述的方法，其特征在于，所述UE向所述接入網絡的移動性管理實體MME發(fā)送承載資源修改請求消息； 所述MME接收到所述承載資源修改請求消息后，通過承載資源命令通知所述資源執(zhí)行網關修改承載資源，所述承載資源命令中攜帶所述TAD參數。
12.根據權利要求6所述的方法，其特征在于，所述UE將所述接入網絡連接信息通知所述Tracker或中間網元；所述Tracker或中間網元將所述接入網絡連接信息通知所述RCF,由所述RCF將所述接入網絡連接信息通知所述接入網絡。
13.根據權利要求12所述的方法，其特征在于，所述UE通過所述SIP消息將所述接入網絡連接信息通知所述Tracker或中間網元； 所述Tracker或中間網元通過承載資源修改請求消息將所述接入網絡連接信息通知所述RCF ;所述承載資源修改請求消息中攜帶協商后的目標內容緩存服務器的媒體面IP地址和端口列表信息；或者，所述承載資源修改請求消息中攜帶協商后的目標內容緩存服務器的媒體面IP地址和端口列表信息、以及所述UE的媒體面IP地址和端口列表信息。
14.根據權利要求13所述的方法，其特征在于，所述RCF接收到所述承載資源修改請求消息后，根據所述目標內容緩存服務器的媒體面IP地址和端口列表信息和/或UE媒體面IP地址和端口列表信息更新TFT信息；所述RCF向所述資源執(zhí)行網關發(fā)送策略修改請求消息，所述策略修改請求消息中攜帶更新后的所述TFT信息。
15.根據權利要求9至14任一項所述的方法，其特征在于，所述使所述UE與所述目的內容緩存服務器之間通過所述承載建立媒體連接，為 所述資源執(zhí)行網關接收到所述承載資源命令或所述策略修改請求消息后，根據所述TAD信息或所述TFT信息更新本地的TFT，并通知所述UE進行承載更新；所述資源執(zhí)行網關使用新的TFT進行承載綁定。
16.根據權利要求15所述的方法，其特征在于，所述方法還包括 所述UE通過承載資源修改過程將所述接入網絡連接信息通知所述接入網絡時，在所述UE完成承載更新后，通過更新后的承載建立與所述目的內容緩存服務器之間的媒體連接，獲取流媒體； 由所述RCF將所述接入網絡連接信息通知所述接入網絡時，所述UE完成承載更新后，由所述RCF通知所述Tracker或中間網元完成承載更新,所述Tracker或中間網元通知所述UE完成承載更新，所述UE通過更新后的承載建立與所述目的內容緩存服務器之間的媒體連接，獲取流媒體。
17.一種保障流媒體業(yè)務服務質量的系統(tǒng)，包括UE、Tracker、目的內容緩存服務器、RCF和接入網絡，其特征在于，所述Tracker與所述RCF設置有連接接口，其中 Tracker,用于接收UE的業(yè)務請求消息，觸發(fā)向所述UE發(fā)送候選內容緩存服務器列表; UE，用于將選取的至少一個內容緩存服務器的連接信息通知接入網絡； 接入網絡，用于根據所述連接信息修改承載信息，使所述UE與所述目的內容緩存服務器之間通過所述承載建立媒體連接，通過所述媒體連接獲取流媒體。
18.根據權利要求17所述的系統(tǒng)，其特征在于，所述系統(tǒng)還包括中間網元； 所述Tracker或中間網元進一步用于，通過所述RCF通知所述接入網絡進行資源預留，并在資源預留完成后，向所述UE返回所述候選內容緩存服務器列表。
19.根據權利要求17所述的系統(tǒng)，其特征在于，所述Tracker或中間網元進一步用于向所述RCF發(fā)送資源預留請求消息； 所述RCF進一步用于在接收到所述資源預留請求消息后，生成QoS策略和缺省流量模板TFT，通知所述接入網絡進行資源預留。
20.根據權利要求19所述的系統(tǒng)，其特征在于，所述資源預留請求消息中包含業(yè)務QoS信息、UE標識、以及UE的媒體面地址和端口信息； 所述RCF進一步用于，根據業(yè)務QoS信息、UE用戶QoS簽約信息和運營商策略生成QoS策略，根據UE的媒體面地址和端口信息生成缺省TFT。
全文摘要
本發(fā)明公開了一種保障流媒體業(yè)務服務質量的方法，包括跟蹤服務器Tracker接收到用戶設備UE的業(yè)務請求消息，觸發(fā)向所述UE發(fā)送候選內容緩存服務器列表；所述UE將選取的至少一個內容緩存服務器的連接信息通知接入網絡；所述接入網絡根據所述連接信息修改承載信息，使所述UE與所述目的內容緩存服務器之間通過所述承載建立媒體連接，通過所述媒體連接獲取流媒體。本發(fā)明同時公開了一種保障流媒體業(yè)務服務質量的系統(tǒng)。本發(fā)明實現了更為靈活和精細化的流媒體QoS策略控制，從而滿足了不同的用戶、不同的終端或不同的流媒體內容傳輸的QoS需求。
文檔編號H04L29/08GK102904859SQ201110210570
公開日2013年1月30日 申請日期2011年7月26日 優(yōu)先權日2011年7月26日
發(fā)明者吳建華, 陶全軍, 郝振武, 謝振華 申請人:中興通訊股份有限公司