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

發(fā)明內(nèi)容
有鑒于此，本發(fā)明的主要目的在于提供一種保障流媒體業(yè)務(wù)服務(wù)質(zhì)量的方法及系統(tǒng)，能為基于MS網(wǎng)絡(luò)的對(duì)等網(wǎng)中的不同業(yè)務(wù)和/或不同用戶提供差異化的服務(wù)質(zhì)量保證。為達(dá)到上述目的，本發(fā)明的技術(shù)方案是這樣實(shí)現(xiàn)的一種保障流媒體業(yè)務(wù)服務(wù)質(zhì)量的方法，包括
內(nèi)容緩存服務(wù)器Cache將自身默認(rèn)的媒體面地址信息通知內(nèi)容跟蹤服務(wù)器Tracker ；所述Tracker接收到用戶終端UE的業(yè)務(wù)請(qǐng)求消息后，將業(yè)務(wù)QoS信息、UE的媒體面地址信息和候選Cache的媒體面地址信息發(fā)送給資源控制功能RCF ；所述RCF根據(jù)業(yè)務(wù)QoS信息和候選Cache的媒體面地址信息生成QoS策略和流量模板TFT信息后，通知接入網(wǎng)絡(luò)預(yù)留資源；所述Tracker向所述UE返回候選Cache列表；所述UE從候選Cache列表中選擇至少一個(gè)Cache,通過(guò)預(yù)留資源建立與所選擇的Cache之間的媒體連接，獲取所需流媒體。優(yōu)選地,所述Cache將自身默認(rèn)的媒體面地址信息通知Tracker,為所述Cache設(shè)置有缺省媒體面地址和端口信息，在向所述Tracker注冊(cè)內(nèi)容時(shí)，將缺省媒體面地址和端口信息通知所述Tracker ；所述Tracker保存所述Cache的缺省媒體面地址和端口信息。優(yōu)選地，所述業(yè)務(wù)請(qǐng)求消息中攜帶有UE的終端能力信息、UE的媒體面IP地址和端口信息、UE請(qǐng)求的內(nèi)容信息。優(yōu)選地，所述方法還包括所述Tracker接收到所述UE的業(yè)務(wù)請(qǐng)求消息后，獲取候選Cache列表,并確定業(yè)務(wù)QoS需求后，向所述RCF發(fā)送業(yè)務(wù)QoS信息、UE的媒體面地址信息和候選Cache的媒體面地址信息。優(yōu)選地，所述Tracker根據(jù)所述業(yè)務(wù)請(qǐng)求消息攜帶請(qǐng)求資源ID和資源類(lèi)型的信息獲取存儲(chǔ)所述資源的Cache的地址列表。優(yōu)選地，所述Tracker接收到所述UE的業(yè)務(wù)請(qǐng)求消息后，所述方法還包括所述Tracker根據(jù)所述業(yè)務(wù)請(qǐng)求消息攜帶的UE終端能力信息以及本地策略生成業(yè)務(wù)QoS需求。優(yōu)選地,所述Tracker直接向所述RCF或通過(guò)所述中間網(wǎng)元向所述RCF發(fā)送業(yè)務(wù)QoS信息、UE的媒體面地址信息和候選Cache的媒體面地址信息。優(yōu)選地，所述Tracker直接向所述RCF發(fā)送資源預(yù)留請(qǐng)求消息；其中，所述資源預(yù)留請(qǐng)求消息中攜帶業(yè)務(wù)QoS信息、UE的媒體面地址信息和候選Cache的媒體面地址信息。
優(yōu)選地,所述Tracker將業(yè)務(wù)QoS信息、UE的媒體面地址信息和候選Cache的媒體面地址信息通知所述中間網(wǎng)元；所述中間網(wǎng)元接收到通知后向所述RCF發(fā)送資源預(yù)留請(qǐng)求；其中，所述資源預(yù)留請(qǐng)求消息中攜帶業(yè)務(wù)QoS信息、UE的媒體面地址信息和候選Cache的媒體面地址信息。優(yōu)選地，所述中間網(wǎng)元為PCSCF ；所述Tracker將業(yè)務(wù)QoS信息、UE的媒體面地址信息和候選Cache的媒體面地址信息通知所述中間網(wǎng)元，為所述Tracker通過(guò)會(huì)話控制功能SCSCF向所述PCSCF發(fā)送通知消息,所述通知消息中攜帶業(yè)務(wù)QoS信息、UE的媒體面地址信息和候選Cache的媒體面地址信息；其中，所述通知消息承載于SIP信令中發(fā)送。優(yōu)選地，所述RCF根據(jù)業(yè)務(wù)QoS信息、UE用戶的QoS簽約信息和運(yùn)營(yíng)商策略生成 QoS策略，根據(jù)UE的媒體面地址和端口信息，以及候選Cache服務(wù)器的媒體面地址信息生成TFT。優(yōu)選地，所述RCF通知接入網(wǎng)絡(luò)預(yù)留資源，為所述RCF生成QoS策略和TFT后，向接入網(wǎng)絡(luò)中的資源執(zhí)行網(wǎng)關(guān)發(fā)送策略執(zhí)行請(qǐng)求消息；所述資源執(zhí)行網(wǎng)關(guān)接收到策略執(zhí)行請(qǐng)求消息后進(jìn)行資源預(yù)留，并通知所述用戶終端創(chuàng)建承載。優(yōu)選地，所述策略執(zhí)行請(qǐng)求消息攜帶有UE標(biāo)識(shí)、QoS策略和TFT的信息；所述資源執(zhí)行網(wǎng)關(guān)根據(jù)所述QoS策略信息和TFT信息預(yù)留資源，并通知所述UE創(chuàng)建承載。優(yōu)選地,所述Tracker向所述UE返回候選Cache列表,為所述資源執(zhí)行網(wǎng)關(guān)在完成資源預(yù)留后通知所述RCF，所述RCF進(jìn)一步通知所述Tracker或所述PCSCF資源預(yù)留完成，所述Tracker或所述PCSCF向所述UE返回候選Cache列表。優(yōu)選地，所述資源執(zhí)行網(wǎng)關(guān)為部署有資源執(zhí)行功能REF的網(wǎng)關(guān)；所述資源執(zhí)行網(wǎng)關(guān)為分組數(shù)據(jù)網(wǎng)絡(luò)網(wǎng)關(guān)P-GW。一種保障流媒體業(yè)務(wù)服務(wù)質(zhì)量的系統(tǒng)，包括UE、Tracker、Cache、RCF和接入網(wǎng)絡(luò)，所述Tracker與所述RCF設(shè)置有連接接口，其中Cache,用于將自身默認(rèn)的媒體面地址信息通知Tracker ；Tracker，用于接收到UE的業(yè)務(wù)請(qǐng)求消息后，將業(yè)務(wù)QoS信息、UE的媒體面地址信息和候選Cache的媒體面地址信息發(fā)送給RCF ；以及，向所述UE返回候選Cache列表；RCF,用于根據(jù)業(yè)務(wù)QoS信息和候選Cache的媒體面地址信息生成QoS策略和TFT信息，并通知接入網(wǎng)絡(luò)預(yù)留資源；UE,用于從候選Cache列表中選擇至少一個(gè)Cache,通過(guò)預(yù)留資源建立與所選擇Cache之間的媒體連接，獲取所需流媒體。優(yōu)選地，所述Cache進(jìn)一步用于，設(shè)置缺省媒體面地址和端口信息，并在向所述Tracker注冊(cè)內(nèi)容時(shí),將缺省媒體面地址和端口信息通知所述Tracker ；所述Tracker進(jìn)一步用于保存所述Cache的缺省媒體面地址和端口信息。
優(yōu)選地，所述業(yè)務(wù)請(qǐng)求消息中攜帶有UE的終端能力信息、UE的媒體面IP地址和端口信息、UE請(qǐng)求的內(nèi)容信息；所述Tracker進(jìn)一步用于,在接收到所述UE的業(yè)務(wù)請(qǐng)求消息后，獲取候選Cache列表，并確定業(yè)務(wù)QoS需求后，向所述RCF發(fā)送業(yè)務(wù)QoS信息、UE的媒體面地址信息和候選Cache的媒體面地址信息。優(yōu)選地,所述Tracker接收到所述UE的業(yè)務(wù)請(qǐng)求消息后,進(jìn)一步根據(jù)所述業(yè)務(wù)請(qǐng)求消息攜帶的UE終端能力信息以及本地策略生成業(yè)務(wù)QoS需求。優(yōu)選地,所述Tracker進(jìn)一步用于,直接向所述RCF或通過(guò)所述中間網(wǎng)元向所述RCF發(fā)送業(yè)務(wù)QoS信息、UE的媒體面地址信息和候選Cache的媒體面地址信息。優(yōu)選地,所述Tracker進(jìn)一步用于,直接向所述RCF發(fā)送資源預(yù)留請(qǐng)求消息；其中，所述資源預(yù)留請(qǐng)求消息中攜帶業(yè)務(wù)QoS信息、UE的媒體面地址信息和候選Cache的媒體面地址信息； 或者，所述Tracker進(jìn)一步用于,將業(yè)務(wù)QoS信息、UE的媒體面地址信息和候選Cache的媒體面地址信息通知所述中間網(wǎng)元；所述中間網(wǎng)元接收到通知后向所述RCF發(fā)送資源預(yù)留請(qǐng)求；其中，所述資源預(yù)留請(qǐng)求消息中攜帶業(yè)務(wù)QoS信息、UE的媒體面地址信息和候選Cache的媒體面地址信息。優(yōu)選地，所述中間網(wǎng)元為PCSCF ；所述Tracker進(jìn)一步用于,通過(guò)SCSCF向所述PCSCF發(fā)送通知消息,所述通知消息中攜帶業(yè)務(wù)QoS信息、UE的媒體面地址信息和候選Cache的媒體面地址信息；其中，所述通知消息承載于SIP信令中發(fā)送。優(yōu)選地，所述RCF進(jìn)一步用于，根據(jù)業(yè)務(wù)QoS信息、UE用戶的QoS簽約信息和運(yùn)營(yíng)商策略生成QoS策略，根據(jù)UE的媒體面地址和端口信息，以及候選Cache服務(wù)器的媒體面地址信息生成TFT。優(yōu)選地，所述接入網(wǎng)絡(luò)還包括資源執(zhí)行網(wǎng)關(guān)；所述RCF進(jìn)一步用于，在生成QoS策略和TFT后，向接入網(wǎng)絡(luò)中的資源執(zhí)行網(wǎng)關(guān)發(fā)送策略執(zhí)行請(qǐng)求消息；所述資源執(zhí)行網(wǎng)關(guān)用于，在接收到策略執(zhí)行請(qǐng)求消息后進(jìn)行資源預(yù)留，并通知所述用戶終端創(chuàng)建承載。優(yōu)選地，所述資源執(zhí)行網(wǎng)關(guān)為部署有REF的網(wǎng)關(guān)；所述資源執(zhí)行網(wǎng)關(guān)為P-GW。本發(fā)明中，Tracker接收到UE的業(yè)務(wù)請(qǐng)求消息后，由Tracker或中間網(wǎng)元通過(guò)RCF通知所述接入網(wǎng)絡(luò)進(jìn)行資源預(yù)留，而在此過(guò)程中，RCF會(huì)生成QoS策略和缺省TFT，并在接收到資源預(yù)留完成的通知后，向接入網(wǎng)絡(luò)中的資源執(zhí)行網(wǎng)關(guān)發(fā)送策略執(zhí)行請(qǐng)求消息；資源執(zhí)行網(wǎng)關(guān)接收到策略執(zhí)行請(qǐng)求消息后進(jìn)行資源預(yù)留，并通知UE創(chuàng)建承載。這樣，就實(shí)現(xiàn)對(duì)業(yè)務(wù)媒體流的QoS控制。由于RCF能根據(jù)UE的簽約數(shù)據(jù)、UE自身能力信息和QoS流媒體的QoS需求制定相應(yīng)的QoS策略，因此，所制定的流媒體的QoS策略更精細(xì)，能提供更精細(xì)化的QoS控制。本發(fā)明實(shí)現(xiàn)了更為靈活和精細(xì)化的流媒體QoS策略控制，從而滿足了不同的用戶、不同的終端或不同的流媒體內(nèi)容傳輸?shù)腝oS需求。


圖I為P2P網(wǎng)絡(luò)原理圖；圖2為支持PPSP協(xié)議的架構(gòu)示意圖；圖3為應(yīng)用PPSP協(xié)議進(jìn)行流媒體業(yè)務(wù)的基本流程圖；圖4為本發(fā)明實(shí)施例的保障流媒體業(yè)務(wù)服務(wù)質(zhì)量的系統(tǒng)的結(jié)構(gòu)示意圖；圖5為本發(fā)明實(shí)施例一的保障流媒體業(yè)務(wù)服務(wù)質(zhì)量的方法的流程圖；圖6為本發(fā)明實(shí)施例二的保障流媒體業(yè)務(wù)服務(wù)質(zhì)量的方法的流程圖。
具體實(shí)施例方式本發(fā)明的基本思想為=Tracker接收到UE的業(yè)務(wù)請(qǐng)求消息后，由Tracker或中間 網(wǎng)元通過(guò)RCF通知所述接入網(wǎng)絡(luò)進(jìn)行資源預(yù)留，而在此過(guò)程中，RCF會(huì)生成QoS策略和缺省TFT，并在接收到資源預(yù)留完成的通知后，向接入網(wǎng)絡(luò)中的資源執(zhí)行網(wǎng)關(guān)發(fā)送策略執(zhí)行請(qǐng)求消息；資源執(zhí)行網(wǎng)關(guān)接收到策略執(zhí)行請(qǐng)求消息后進(jìn)行資源預(yù)留，并通知UE創(chuàng)建承載。由于RCF能根據(jù)UE的簽約數(shù)據(jù)、UE自身能力信息和QoS流媒體的QoS需求制定相應(yīng)的QoS策略，因此，所制定的流媒體的QoS策略更精細(xì)，能提供更精細(xì)化的QoS控制。為使本發(fā)明的目的、技術(shù)方案和優(yōu)點(diǎn)更加清楚明白，以下舉實(shí)施例并參照附圖，對(duì)本發(fā)明進(jìn)一步詳細(xì)說(shuō)明。圖4為本發(fā)明實(shí)施例的保障流媒體業(yè)務(wù)服務(wù)質(zhì)量的系統(tǒng)的結(jié)構(gòu)示意圖，如圖4所示，本發(fā)明示例的保障流媒體業(yè)務(wù)服務(wù)質(zhì)量的系統(tǒng)包括UE 401、MME402、P-Gff 403、PCSCF404、SCSCF 405、Tracker 406、Cache 407、RCF 408 和 REF 409，其中UE 401，用于發(fā)起業(yè)務(wù)請(qǐng)求并進(jìn)行終端側(cè)相應(yīng)的業(yè)務(wù)處理。移動(dòng)管理實(shí)體(MME,Mobility Management Entity) 402,為接入側(cè)網(wǎng)元,主要負(fù)責(zé)移動(dòng)性管理、承載管理等功能。分組數(shù)據(jù)網(wǎng)絡(luò)網(wǎng)關(guān)(P-GW, Packet Data Network Gateway) 403,為接入側(cè)網(wǎng)元,用于管理3GPP接入和non-3GPP接入間的移動(dòng)，還負(fù)責(zé)策略執(zhí)行、計(jì)費(fèi)等功能。代理呼叫控制功能實(shí)體(PCSCF,ProxyCall Session Control Function) 404,為IMS核心網(wǎng)網(wǎng)元,用于負(fù)責(zé)終端接入到MS核心網(wǎng)。會(huì)話呼叫控制功能實(shí)體(SCSCF,Session Call Session Control Function) 405,為MS核心網(wǎng)網(wǎng)元，用于進(jìn)行用戶的認(rèn)證鑒權(quán)、會(huì)話控制和業(yè)務(wù)觸發(fā)。Tracker 406，為內(nèi)容跟蹤服務(wù)器，用于存儲(chǔ)資源索引信息，如某個(gè)特定的內(nèi)容緩存服務(wù)器(Cache)中存儲(chǔ)的資源信息。Cache 407，內(nèi)容緩存服務(wù)器，存儲(chǔ)具體的資源，如影片內(nèi)容分片等。資源控制功能實(shí)體(RCF, Resource Control Function) 408,負(fù)責(zé)接收來(lái)自業(yè)務(wù)實(shí)體的業(yè)務(wù)QoS請(qǐng)求，結(jié)合運(yùn)營(yíng)商策略和用戶簽約等信息制定相應(yīng)的資源控制策略，并下發(fā)給策略執(zhí)行功能實(shí)體(REF, Resource Enforcement Function)執(zhí)行。此外，RCF還可以接收REF上報(bào)的事件，發(fā)送給相應(yīng)的業(yè)務(wù)層功能實(shí)體。REF 409，根據(jù)RCF下發(fā)的資源控制策略進(jìn)行QoS策略實(shí)施和門(mén)控、事件上報(bào)等功能。REF是邏輯功能實(shí)體，可以部署在多個(gè)網(wǎng)元中。在本架構(gòu)中REF部署在P-GW網(wǎng)元中。與RCF對(duì)接的網(wǎng)元可以是PCSCF或者Tracker，在實(shí)際部署時(shí)二選一即可。PCSCF和RCF之間的接口和協(xié)議為現(xiàn)有技術(shù)，該接口使用Diameter協(xié)議。PCSCF將業(yè)務(wù)層的QoS需求承載在Diameter消息中下發(fā)給RCF，RCF向其返回執(zhí)行結(jié)果。Tracker和RCF之間的接口是新增的接口，該接口使用Diameter協(xié)議；其中，Tracker網(wǎng)元新增如下功能I)根據(jù)用戶終端能力等信息策略出業(yè)務(wù)QoS需求；2)與RCF交互，將業(yè)務(wù)層的QoS需求承載在Diameter消息中下發(fā)給RCF，RCF向其返回執(zhí)行結(jié)果。下面結(jié)合附圖和實(shí)施例對(duì)本發(fā)明作進(jìn)一步詳細(xì)說(shuō)明。為方便描述，下面將PCSCF和RCF對(duì)接的架構(gòu)稱(chēng)為PCSCF作AF (Application Function,應(yīng)用功能)，將Tracker和RCF對(duì)接的架構(gòu)稱(chēng)為T(mén)racker作AF。在下述實(shí)施例中分別描述了 PCSCF作AF和Tracker作AF的情況。REF部署在P-GW中，P-Gff和RCF之間通過(guò)REF功能進(jìn)行交互，為簡(jiǎn)便起見(jiàn)，實(shí)施例圖中沒(méi)有示出REF功能。 圖5為本發(fā)明實(shí)施例一的保障流媒體業(yè)務(wù)服務(wù)質(zhì)量的方法的流程圖，如圖5所示，本示例描述了 Tracker作AF架構(gòu)下的一種實(shí)現(xiàn)流程，本示例的保障流媒體業(yè)務(wù)服務(wù)質(zhì)量的方法具體包括以下步驟步驟501 UE向PCSCF發(fā)送會(huì)話請(qǐng)求(INVITE)消息，該INVITE消息是為了向Tracker請(qǐng)求擁有目標(biāo)資源的節(jié)點(diǎn)列表。INVITE消息中攜帶UE的終端能力信息(如UE的數(shù)據(jù)處理能力、屏幕分辨率等)、UE已分配的媒體面IP地址和端口列表，該列表包含一個(gè)或多個(gè)端口、以及UE要請(qǐng)求的內(nèi)容信息，如所需的資源ID及資源類(lèi)型(如影片是否高清)
坐寸ο步驟502 步驟503 =PCSCF接收到INVITE消息后，向SCSCF轉(zhuǎn)發(fā)該消息。SCSCF將該消息發(fā)給Tracker。此為現(xiàn)有技術(shù)。步驟504 =Tracker接收到SCSCF發(fā)送的INVITE消息后，根據(jù)INVITE中的資源ID和資源類(lèi)型等信息獲取存儲(chǔ)了該資源的Cache的地址信息列表，所述地址信息列表包括Tracker選擇的所有Cache的媒體面地址和端口。Tracker獲取Cache的媒體面地址和端口可米取但不限于如下方式Cache在本地設(shè)置了缺省媒體面地址和端口列表，Cache在向Tracker注冊(cè)內(nèi)容時(shí)，在內(nèi)容注冊(cè)請(qǐng)求消息中攜帶本地設(shè)置的缺省媒體面地址和端口列表，Tracker保存相關(guān)信息。步驟505 =Tracker根據(jù)INVITE消息中攜帶的UE終端能力結(jié)合本地策略生成業(yè)務(wù)QoS需求。所述本地策略由運(yùn)營(yíng)商自行確定，可以采用但不限于以下策略=Tracker根據(jù)INVITE消息中攜帶的UE終端能力結(jié)合該影片推薦帶寬確定業(yè)務(wù)QoS需求，該業(yè)務(wù)QoS需求包括傳輸該影片資源時(shí)所需最低保障帶寬和速率。所述影片業(yè)務(wù)提供商(SP，ServiceProvider)推薦帶寬是指提供該影片資源的業(yè)務(wù)提供商根據(jù)一定算法結(jié)合該影片播放速度和各分片大小算出的一個(gè)相對(duì)最優(yōu)值，能保障正常播放時(shí)影片的大部分分片能被及時(shí)下載。Tracker獲取該影片SP推薦帶寬信息的方式可以采用但不限于1)分片信息中攜帶了該影片SP推薦帶寬，Tracker通過(guò)查詢分片信息可獲知相應(yīng)的影片SP推薦帶寬信息。2)各個(gè)影片對(duì)應(yīng)的SP推薦帶寬信息存儲(chǔ)在某個(gè)服務(wù)器中，在需要時(shí)Tracker和該服務(wù)器交互獲取該信息。上述步驟504和步驟505無(wú)嚴(yán)格的先后執(zhí)行順序關(guān)系。步驟506 =Tracker在生成業(yè)務(wù)QoS需求后，向RCF發(fā)送資源預(yù)留請(qǐng)求消息,資源預(yù)留請(qǐng)求消息中攜帶業(yè)務(wù)QoS相關(guān)信息、UE標(biāo)識(shí)、UE的媒體面地址和端口列表以及Tracker選擇的Cache的媒體面地址和端口列表。這里Cache可以是多個(gè)。步驟507 :RCF接收到Tracker發(fā)送的資源預(yù)留請(qǐng)求消息后，獲取資源預(yù)留請(qǐng)求消息中的業(yè)務(wù)QoS相關(guān)信息，結(jié)合用戶QoS簽約和本地策略生成QoS策略，并根據(jù)UE的媒體面IP地址和端口列表以及Cache的媒體面地址和端口列表生成TFT，之后向P-GW發(fā)送策略執(zhí)行請(qǐng)求消息通知?jiǎng)?chuàng)建承載，策略執(zhí)行請(qǐng)求消息中攜帶UE標(biāo)識(shí)、QoS策略信息以及TFT等信息。步驟508 =P-Gff接收到RCF發(fā)送的策略執(zhí)行請(qǐng)求消息后，并根策略執(zhí)行請(qǐng)求據(jù)消息中攜帶的QoS策略信息分配EPS承載QoS，所述EPS承載QoS是指承載層QoS參數(shù)，包括QCI、ARP、GBR和MBR。P-Gff向MME發(fā)送創(chuàng)建承載請(qǐng)求消息，消息中攜帶UE標(biāo)識(shí)、EPS承載QoS信息、TFT、EPS承載標(biāo)識(shí)等。所述TFT用于IP流的承載綁定。步驟509 =MME通知UE進(jìn)行無(wú)線承載建立過(guò)程。MME在這個(gè)過(guò)程中將無(wú)線承載QoS 信息和TFT等參數(shù)通知UE。UE根據(jù)QoS參數(shù)進(jìn)行資源預(yù)留，根據(jù)TFT進(jìn)行承載綁定。步驟510 :完成承載建立相關(guān)過(guò)程后，MME向P-GW返回創(chuàng)建承載響應(yīng)消息，創(chuàng)建承載響應(yīng)消息中攜帶有EPS承載標(biāo)識(shí)等信息。步驟511 :P-GW接收到MME返回的創(chuàng)建承載響應(yīng)消息后，向RCF發(fā)送策略執(zhí)行響應(yīng)消息，通知RCF策略已經(jīng)執(zhí)行完成。步驟512 :RCF接收到策略執(zhí)行響應(yīng)消息后，向Tracker返回資源預(yù)留響應(yīng)消息，通知Tracker資源已經(jīng)預(yù)留完成。步驟513 =Tracker接收到RCF發(fā)送的資源預(yù)留響應(yīng)消息后，向SCSCF發(fā)送應(yīng)答(2000K)消息，2000K消息中攜帶有Tracker獲取的Cache地址列表。步驟514 步驟515 =SCSCF接收到應(yīng)答消息后，通過(guò)PCSCF將該應(yīng)答消息轉(zhuǎn)發(fā)給
UE0步驟516 :UE接收到應(yīng)答消息后，從應(yīng)答消息中攜帶的Cache列表中選擇一個(gè)或者多個(gè)Cache作為內(nèi)容獲取節(jié)點(diǎn)。本實(shí)施例以UE選取一個(gè)Cache為例。步驟517 步驟519 UE向所選擇的Cache發(fā)送內(nèi)容請(qǐng)求,Cache向其返回內(nèi)容請(qǐng)求響應(yīng)，之后Cache通過(guò)之前建立的EPS承載開(kāi)始向UE發(fā)送媒體流。在該過(guò)程中，媒體流將會(huì)通過(guò)TFT綁定到之前已經(jīng)建好的專(zhuān)用承載上，從而保障流媒體的QoS。圖6為本發(fā)明實(shí)施例二的保障流媒體業(yè)務(wù)服務(wù)質(zhì)量的方法的流程圖，如圖6所示，本示例描述了 PCSCF作AF架構(gòu)下的一種實(shí)現(xiàn)流程。本示例與前述實(shí)施例一的基本思想相同，主要區(qū)別點(diǎn)在于，前述實(shí)施例一是Tracker作AF和RCF進(jìn)行交互，而本示例是PCSCF作AF與RCF進(jìn)行交互。本示例的保障流媒體業(yè)務(wù)服務(wù)質(zhì)量的方法具體包括以下步驟步驟601 步驟605 :同步驟501 步驟505。步驟606 步驟607 =Tracker向SCSCF發(fā)送應(yīng)答(2000K)消息，應(yīng)答消息中攜帶有業(yè)務(wù)QoS相關(guān)信息、UE的媒體面地址和端口列表以及Tracker選擇的Cache的媒體面地址和端口列表。SCSCF把應(yīng)答(2000K)消息轉(zhuǎn)發(fā)給PCSCF。步驟608 =PSCSF在接收到應(yīng)答消息后，向RCF發(fā)送資源預(yù)留請(qǐng)求消息。該資源預(yù)留請(qǐng)求消息中攜帶有業(yè)務(wù)QoS相關(guān)信息、UE標(biāo)識(shí)、UE的媒體面地址和端口列表以及Tracker選擇的Cache的媒體面地址和端口列表。這里Cache可以是多個(gè)。
步驟609 :步驟609 步驟613，RCF觸發(fā)P-GW建立承載過(guò)程。同步驟507 步驟511。步驟614 :RCF接收到策略執(zhí)行響應(yīng)消息后，向PCSCF返回資源預(yù)留響應(yīng)消息，通知PCSCF資源已經(jīng)預(yù)留完成。同步驟512。步驟615 步驟619 :同步驟515 步驟519。從上述方案的分析可知，采取本發(fā)明的方法，實(shí)現(xiàn)了更為靈 活和精細(xì)化的流媒體QoS策略控制。本發(fā)明同時(shí)記載了一種保障流媒體業(yè)務(wù)服務(wù)質(zhì)量的系統(tǒng)，包括UE、Tracker,Cache、RCF和接入網(wǎng)絡(luò)，所述Tracker與所述RCF設(shè)置有連接接口，其中Cache,用于將自身默認(rèn)的媒體面地址信息通知Tracker ；Tracker，用于接收到UE的業(yè)務(wù)請(qǐng)求消息后，將業(yè)務(wù)QoS信息、UE的媒體面地址信息和候選Cache的媒體面地址信息發(fā)送給RCF ；以及，向所述UE返回候選Cache列表；RCF,用于根據(jù)業(yè)務(wù)QoS信息和候選Cache的媒體面地址信息生成QoS策略和TFT信息，并通知接入網(wǎng)絡(luò)預(yù)留資源；UE,用于從候選Cache列表中選擇至少一個(gè)Cache,通過(guò)所述預(yù)留資源建立與所選擇Cache之間的媒體連接，獲取所需流媒體。 所述Cache進(jìn)一步用于,設(shè)置缺省媒體面地址和端口信息，并在向所述Tracker注冊(cè)內(nèi)容時(shí)，將缺省媒體面地址和端口信息通知所述Tracker ；所述Tracker進(jìn)一步用于保存所述Cache的缺省媒體面地址和端口信息。所述業(yè)務(wù)請(qǐng)求消息中攜帶有UE的終端能力信息、UE的媒體面IP地址和端口信息、UE請(qǐng)求的內(nèi)容信息；所述Tracker進(jìn)一步用于,在接收到所述UE的業(yè)務(wù)請(qǐng)求消息后，獲取候選Cache列表，并確定業(yè)務(wù)QoS需求后，向所述RCF發(fā)送業(yè)務(wù)QoS信息、UE的媒體面地址信息和候選Cache的媒體面地址信息。所述Tracker接收到所述UE的業(yè)務(wù)請(qǐng)求消息后,進(jìn)一步根據(jù)所述業(yè)務(wù)請(qǐng)求消息攜帶的UE終端能力信息以及本地策略生成業(yè)務(wù)QoS需求。所述Tracker進(jìn)一步用于,直接向所述RCF或通過(guò)所述中間網(wǎng)元向所述RCF發(fā)送業(yè)務(wù)QoS信息、UE的媒體面地址信息和候選Cache的媒體面地址信息。所述Tracker進(jìn)一步用于,直接向所述RCF發(fā)送資源預(yù)留請(qǐng)求消息；其中,所述資源預(yù)留請(qǐng)求消息中攜帶業(yè)務(wù)QoS信息、UE的媒體面地址信息和候選Cache的媒體面地址信息；或者，所述Tracker進(jìn)一步用于,將業(yè)務(wù)QoS信息、UE的媒體面地址信息和候選Cache的媒體面地址信息通知所述中間網(wǎng)元；所述中間網(wǎng)元接收到通知后向所述RCF發(fā)送資源預(yù)留請(qǐng)求；其中，所述資源預(yù)留請(qǐng)求消息中攜帶業(yè)務(wù)QoS信息、UE的媒體面地址信息和候選Cache的媒體面地址信息。所述中間網(wǎng)元為PCSCF ；所述Tracker進(jìn)一步用于,通過(guò)SCSCF向所述PCSCF發(fā)送通知消息,所述通知消息中攜帶業(yè)務(wù)QoS信息、UE的媒體面地址信息和候選Cache的媒體面地址信息；其中，所述通知消息承載于SIP信令中發(fā)送。
所述RCF進(jìn)一步用于，根據(jù)業(yè)務(wù)QoS信息、UE用戶的QoS簽約信息和運(yùn)營(yíng)商策略生成QoS策略，根據(jù)UE的媒體面地址和端口信息，以及候選Cache服務(wù)器的媒體面地址信息生成TFT。所述接入網(wǎng)絡(luò)還包括資源執(zhí)行網(wǎng)關(guān)；所述RCF進(jìn)一步用于，在生成QoS策略和TFT后，向接入網(wǎng)絡(luò)中的資源執(zhí)行網(wǎng)關(guān)發(fā)送策略執(zhí)行請(qǐng)求消息；所述資源執(zhí)行網(wǎng)關(guān)用于，在接收到策略執(zhí)行請(qǐng)求消息后進(jìn)行資源預(yù)留，并通知所述用戶終端創(chuàng)建承載。所述資源執(zhí)行網(wǎng)關(guān)為部署有REF的網(wǎng)關(guān)；
所述資源執(zhí)行網(wǎng)關(guān)為P-GW。本領(lǐng)域技術(shù)人員應(yīng)當(dāng)理解，本發(fā)明保障流媒體業(yè)務(wù)服務(wù)質(zhì)量的系統(tǒng)對(duì)現(xiàn)有網(wǎng)絡(luò)系統(tǒng)的結(jié)構(gòu)并無(wú)實(shí)質(zhì)性改變，只是利用Tracker與RCF之間設(shè)置的連接接口，實(shí)現(xiàn)了由RCF針對(duì)流媒體業(yè)務(wù)制定相應(yīng)的QoS策略并執(zhí)行對(duì)接入流媒體業(yè)務(wù)的QoS控制。本發(fā)明保障流媒體業(yè)務(wù)服務(wù)質(zhì)量的系統(tǒng)中各網(wǎng)元的功能，可結(jié)合圖4至圖6相應(yīng)的描述而理解。以上所述，僅為本發(fā)明的較佳實(shí)施例而已，并非用于限定本發(fā)明的保護(hù)范圍。
權(quán)利要求
1.一種保障流媒體業(yè)務(wù)服務(wù)質(zhì)量的方法，其特征在于，所述方法包括 內(nèi)容緩存服務(wù)器Cache將自身默認(rèn)的媒體面地址信息通知內(nèi)容跟蹤服務(wù)器Tracker ； 所述Tracker接收到用戶終端UE的業(yè)務(wù)請(qǐng)求消息后，將業(yè)務(wù)QoS信息、UE的媒體面地址信息和候選Cache的媒體面地址信息發(fā)送給資源控制功能RCF ； 所述RCF根據(jù)業(yè)務(wù)QoS信息和候選Cache的媒體面地址信息生成QoS策略和流量模板TFT信息后，通知接入網(wǎng)絡(luò)預(yù)留資源； 所述Tracker向所述UE返回候選Cache列表； 所述UE從候選Cache列表中選擇至少一個(gè)Cache,通過(guò)預(yù)留資源建立與所選擇的Cache之間的媒體連接，獲取所需流媒體。
2.根據(jù)權(quán)利要求I所述的方法，其特征在于，所述Cache將自身默認(rèn)的媒體面地址信息通知Tracker,為 所述Cache設(shè)置有缺省媒體面地址和端口信息，在向所述Tracker注冊(cè)內(nèi)容時(shí)，將缺省媒體面地址和端口信息通知所述Tracker ； 所述Tracker保存所述Cache的缺省媒體面地址和端口信息。
3.根據(jù)權(quán)利要求I所述的方法，其特征在于，所述業(yè)務(wù)請(qǐng)求消息中攜帶有UE的終端能力信息、UE的媒體面IP地址和端口信息、UE請(qǐng)求的內(nèi)容信息。
4.根據(jù)權(quán)利要求3所述的方法，其特征在于，所述方法還包括 所述Tracker接收到所述UE的業(yè)務(wù)請(qǐng)求消息后,獲取候選Cache列表,并確定業(yè)務(wù)QoS需求后，向所述RCF發(fā)送業(yè)務(wù)QoS信息、UE的媒體面地址信息和候選Cache的媒體面地址信息。
5.根據(jù)權(quán)利要求4所述的方法,其特征在于,所述Tracker根據(jù)所述業(yè)務(wù)請(qǐng)求消息攜帶請(qǐng)求資源ID和資源類(lèi)型的信息獲取存儲(chǔ)所述資源的Cache的地址列表。
6.根據(jù)權(quán)利要求4所述的方法,其特征在于，所述Tracker接收到所述UE的業(yè)務(wù)請(qǐng)求消 息后，所述方法還包括 所述Tracker根據(jù)所述業(yè)務(wù)請(qǐng)求消息攜帶的UE終端能力信息以及本地策略生成業(yè)務(wù)QoS需求。
7.根據(jù)權(quán)利要求4所述的方法，其特征在于，所述Tracker直接向所述RCF或通過(guò)所述中間網(wǎng)元向所述RCF發(fā)送業(yè)務(wù)QoS信息、UE的媒體面地址信息和候選Cache的媒體面地址信息。
8.根據(jù)權(quán)利要求7所述的方法，其特征在于，所述Tracker直接向所述RCF發(fā)送資源預(yù)留請(qǐng)求消息；其中，所述資源預(yù)留請(qǐng)求消息中攜帶業(yè)務(wù)QoS信息、UE的媒體面地址信息和候選Cache的媒體面地址信息。
9.根據(jù)權(quán)利要求7所述的方法，其特征在于，所述Tracker將業(yè)務(wù)QoS信息、UE的媒體面地址信息和候選Cache的媒體面地址信息通知所述中間網(wǎng)元； 所述中間網(wǎng)元接收到通知后向所述RCF發(fā)送資源預(yù)留請(qǐng)求；其中，所述資源預(yù)留請(qǐng)求消息中攜帶業(yè)務(wù)QoS信息、UE的媒體面地址信息和候選Cache的媒體面地址信息。
10.根據(jù)權(quán)利要求9所述的方法，其特征在于，所述中間網(wǎng)元為PCSCF； 所述Tracker將業(yè)務(wù)QoS信息、UE的媒體面地址信息和候選Cache的媒體面地址信息通知所述中間網(wǎng)元，為所述Tracker通過(guò)會(huì)話控制功能SCSCF向所述PCSCF發(fā)送通知消息,所述通知消息中攜帶業(yè)務(wù)QoS信息、UE的媒體面地址信息和候選Cache的媒體面地址信息；其中，所述通知消息承載于SIP信令中發(fā)送。
11.根據(jù)權(quán)利要求I所述的方法，其特征在于，所述RCF根據(jù)業(yè)務(wù)QoS信息、UE用戶的QoS簽約信息和運(yùn)營(yíng)商策略生成QoS策略，根據(jù)UE的媒體面地址和端口信息，以及候選Cache服務(wù)器的媒體面地址信息生成TFT。
12.根據(jù)權(quán)利要求11所述的方法，其特征在于，所述RCF通知接入網(wǎng)絡(luò)預(yù)留資源，為所述RCF生成QoS策略和TFT后，向接入網(wǎng)絡(luò)中的資源執(zhí)行網(wǎng)關(guān)發(fā)送策略執(zhí)行請(qǐng)求消息； 所述資源執(zhí)行網(wǎng)關(guān)接收到策略執(zhí)行請(qǐng)求消息后進(jìn)行資源預(yù)留，并通知所述用戶終端創(chuàng)建承載。
13.根據(jù)權(quán)利要求12所述的方法，其特征在于，所述策略執(zhí)行請(qǐng)求消息攜帶有UE標(biāo)識(shí)、QoS策略和TFT的信息； 所述資源執(zhí)行網(wǎng)關(guān)根據(jù)所述QoS策略信息和TFT信息預(yù)留資源，并通知所述UE創(chuàng)建承載。
14.根據(jù)權(quán)利要求I所述的方法，其特征在于，所述Tracker向所述UE返回候選Cache列表，為所述資源執(zhí)行網(wǎng)關(guān)在完成資源預(yù)留后通知所述RCF，所述RCF進(jìn)一步通知所述Tracker或所述PCSCF資源預(yù)留完成,所述Tracker或所述PCSCF向所述UE返回候選Cache列表。
15.根據(jù)權(quán)利要求12至14任一項(xiàng)所述的方法，其特征在于，所述資源執(zhí)行網(wǎng)關(guān)為部署有資源執(zhí)行功能REF的網(wǎng)關(guān)； 所述資源執(zhí)行網(wǎng)關(guān)為分組數(shù)據(jù)網(wǎng)絡(luò)網(wǎng)關(guān)P-GW。
16.一種保障流媒體業(yè)務(wù)服務(wù)質(zhì)量的系統(tǒng)，包括UE、Tracker、Cache、RCF和接入網(wǎng)絡(luò)，其特征在于，所述Tracker與所述RCF設(shè)置有連接接口，其中 Cache,用于將自身默認(rèn)的媒體面地址信息通知Tracker ； Tracker，用于接收到UE的業(yè)務(wù)請(qǐng)求消息后，將業(yè)務(wù)QoS信息、UE的媒體面地址信息和候選Cache的媒體面地址信息發(fā)送給RCF ；以及，向所述UE返回候選Cache列表； RCF,用于根據(jù)業(yè)務(wù)QoS信息和候選Cache的媒體面地址信息生成QoS策略和TFT信息，并通知接入網(wǎng)絡(luò)預(yù)留資源； UE,用于從候選Cache列表中選擇至少一個(gè)Cache,通過(guò)預(yù)留資源建立與所選擇Cache之間的媒體連接，獲取所需流媒體。
17.根據(jù)權(quán)利要求16所述的系統(tǒng)，其特征在于，所述Cache進(jìn)一步用于，設(shè)置缺省媒體面地址和端口信息，并在向所述Tracker注冊(cè)內(nèi)容時(shí)，將缺省媒體面地址和端口信息通知所述 Tracker ； 所述Tracker進(jìn)一步用于保存所述Cache的缺省媒體面地址和端口信息。
18.根據(jù)權(quán)利要求16所述的系統(tǒng)，其特征在于，所述業(yè)務(wù)請(qǐng)求消息中攜帶有UE的終端能力信息、UE的媒體面IP地址和端口信息、UE請(qǐng)求的內(nèi)容信息； 所述Tracker進(jìn)一步用于,在接收到所述UE的業(yè)務(wù)請(qǐng)求消息后,獲取候選Cache列表，并確定業(yè)務(wù)QoS需求后，向所述RCF發(fā)送業(yè)務(wù)QoS信息、UE的媒體面地址信息和候選Cache的媒體面地址信息。
19.根據(jù)權(quán)利要求18所述的系統(tǒng)，其特征在于，所述Tracker接收到所述UE的業(yè)務(wù)請(qǐng)求消息后，進(jìn)一步根據(jù)所述業(yè)務(wù)請(qǐng)求消息攜帶的UE終端能力信息以及本地策略生成業(yè)務(wù)QoS需求。
20.根據(jù)權(quán)利要求18所述的系統(tǒng),其特征在于,所述Tracker進(jìn)一步用于,直接向所述RCF或通過(guò)所述中間網(wǎng)元向所述RCF發(fā)送業(yè)務(wù)QoS信息、UE的媒體面地址信息和候選Cache的媒體面地址信息。
21.根據(jù)權(quán)利要求20所述的系統(tǒng)，其特征在于，所述Tracker進(jìn)一步用于，直接向所述RCF發(fā)送資源預(yù)留請(qǐng)求消息；其中，所述資源預(yù)留請(qǐng)求消息中攜帶業(yè)務(wù)QoS信息、UE的媒體面地址信息和候選Cache的媒體面地址信息； 或者，所述Tracker進(jìn)一步用于,將業(yè)務(wù)QoS信息、UE的媒體面地址信息和候選Cache的媒體面地址信息通知所述中間網(wǎng)元；所述中間網(wǎng)元接收到通知后向所述RCF發(fā)送資源預(yù)留請(qǐng)求；其中，所述資源預(yù)留請(qǐng)求消息中攜帶業(yè)務(wù)QoS信息、UE的媒體面地址信息和候選Cache的媒體面地址信息。
22.根據(jù)權(quán)利要求21所述的方法，其特征在于，所述中間網(wǎng)元為PCSCF； 所述Tracker進(jìn)一步用于,通過(guò)SCSCF向所述PCSCF發(fā)送通知消息,所述通知消息中攜帶業(yè)務(wù)QoS信息、UE的媒體面地址信息和候選Cache的媒體面地址信息；其中，所述通知消息承載于SIP信令中發(fā)送。
23.根據(jù)權(quán)利要求16所述的系統(tǒng)，其特征在于，所述RCF進(jìn)一步用于，根據(jù)業(yè)務(wù)QoS信息、UE用戶的QoS簽約信息和運(yùn)營(yíng)商策略生成QoS策略，根據(jù)UE的媒體面地址和端口信息，以及候選Cache服務(wù)器的媒體面地址信息生成TFT。
24.根據(jù)權(quán)利要求23所述的系統(tǒng)，其特征在于，所述接入網(wǎng)絡(luò)還包括資源執(zhí)行網(wǎng)關(guān)； 所述RCF進(jìn)一步用于，在生成QoS策略和TFT后，向接入網(wǎng)絡(luò)中的資源執(zhí)行網(wǎng)關(guān)發(fā)送策略執(zhí)行請(qǐng)求消息； 所述資源執(zhí)行網(wǎng)關(guān)用于，在接收到策略執(zhí)行請(qǐng)求消息后進(jìn)行資源預(yù)留，并通知所述用戶終端創(chuàng)建承載。
25.根據(jù)權(quán)利要求24所述的系統(tǒng)，其特征在于，所述資源執(zhí)行網(wǎng)關(guān)為部署有REF的網(wǎng)關(guān); 所述資源執(zhí)行網(wǎng)關(guān)為P-GW。
全文摘要
本發(fā)明公開(kāi)了一種保障流媒體業(yè)務(wù)服務(wù)質(zhì)量的方法，包括Cache將自身默認(rèn)的媒體面地址信息通知Tracker；Tracker接收到UE的業(yè)務(wù)請(qǐng)求消息后，將業(yè)務(wù)QoS信息、UE的媒體面地址信息和候選Cache的媒體面地址信息發(fā)送給RCF；RCF根據(jù)業(yè)務(wù)QoS信息和候選Cache的媒體面地址信息生成QoS策略和流量模板TFT信息后，通知接入網(wǎng)絡(luò)預(yù)留資源；Tracker向UE返回候選Cache列表；UE從候選Cache列表中選擇至少一個(gè)Cache，通過(guò)預(yù)留資源建立與所選擇的Cache之間的媒體連接，獲取所需流媒體。本發(fā)明同時(shí)公開(kāi)了一種保障流媒體業(yè)務(wù)服務(wù)質(zhì)量的系統(tǒng)。本發(fā)明實(shí)現(xiàn)了更為靈活和精細(xì)化的流媒體QoS策略控制，從而滿足了不同的用戶、不同的終端或不同的流媒體內(nèi)容傳輸?shù)腝oS需求。
文檔編號(hào)H04L29/06GK102891830SQ201110202060
公開(kāi)日2013年1月23日 申請(qǐng)日期2011年7月18日 優(yōu)先權(quán)日2011年7月18日
發(fā)明者吳建華, 陶全軍, 郝振武 申請(qǐng)人:中興通訊股份有限公司