午夜毛片免费看,老师老少妇黄色网站,久久本道综合久久伊人,伊人黄片子

用于內(nèi)容下載和內(nèi)容上載的策略的制作方法

文檔序號:7915000閱讀:189來源:國知局
專利名稱:用于內(nèi)容下載和內(nèi)容上載的策略的制作方法
技術(shù)領(lǐng)域
本發(fā)明涉及用于用戶設(shè)備和IPTV控制節(jié)點(diǎn)上載IPTV媒體內(nèi)容到媒體內(nèi)容服務(wù)器或從媒體內(nèi)容服務(wù)器下載IPTV媒體內(nèi)容的方法及用戶設(shè)備和IPTV控制節(jié)點(diǎn)。
背景技術(shù)
最終用戶可從諸如TV、PC (個(gè)人計(jì)算機(jī))或移動(dòng)電話等不同類型的UE (用戶設(shè)備),例如經(jīng)由MS (因特網(wǎng)協(xié)議多媒體子系統(tǒng))訪問IPTV (因特網(wǎng)協(xié)議電視)服務(wù),條件是UE具有可例如根據(jù)開放IPTV論壇規(guī)范指定的適合功能性。常規(guī)上,在諸如使用單播流的視頻點(diǎn)播會(huì)話或使用多播流的常規(guī)電視廣播會(huì)話等會(huì)話的設(shè)置期間,帶寬能夠預(yù)留。帶寬預(yù)留將確保在到訂戶的“最后一英里”中及在聚集網(wǎng)絡(luò)中有足夠的帶寬,以便向用戶提供適當(dāng)?shù)捏w驗(yàn),而無服務(wù)的任何中斷或干擾。此外,兩個(gè)會(huì)話可一起超過最后一英里內(nèi)的可用帶寬。這將造成在兩個(gè)會(huì)話中的分組相互競爭,并導(dǎo)致在兩個(gè)會(huì)話中均將丟棄ー些分組。因此,重要的是一旦為現(xiàn)有會(huì)話預(yù)留了帶寬,便不允許新會(huì)話影響現(xiàn)有會(huì)話。媒體內(nèi)容例如能夠通過漸進(jìn)式下載、通過流傳送下載或通過自適應(yīng)流傳送下載從媒體內(nèi)容服務(wù)器下載到充當(dāng)客戶端終端的UE,在漸進(jìn)式下載中,媒體內(nèi)容存儲(chǔ)在本地緩沖器中以便使能在下載完成前播出媒體文件,在流傳送下載中,媒體內(nèi)容以播出速率從內(nèi)容服務(wù)器流傳送并且不涉及存儲(chǔ),在自適應(yīng)流傳送下載中,內(nèi)容能夠以不同比特率下載。以類似方式,媒體內(nèi)容能夠從UE上載到內(nèi)容服務(wù)器,并且隨后可共享到使用下載的其它用戶。然而,媒體內(nèi)容的常規(guī)HTTP漸進(jìn)式下載只支持盡力而為的服務(wù)質(zhì)量,即,無保證的QoS,并且?guī)挷豢梢允亲畲髱?。因此,如果媒體內(nèi)容的分辨率高,并且網(wǎng)絡(luò)具有有限帶寬,則播出的用戶體驗(yàn)可能很差。例如,從眾所周知的網(wǎng)站YouTube下載的媒體內(nèi)容在它被下載的同時(shí),只使用盡力而為服務(wù)質(zhì)量顯示。如果分辨率有限并且不太高,則可用帶寬可足夠,并且播出媒體內(nèi)容的用戶體驗(yàn)可接受。然而,在其它情況下,用戶體驗(yàn)可能很差。此外,漸進(jìn)下載的媒體文件的正確重放要求UE,即客戶端終端能夠緩沖大量的媒體內(nèi)容。因此,它仍提出了實(shí)現(xiàn)播出的媒體內(nèi)容的可接受用戶體驗(yàn)的問題。

發(fā)明內(nèi)容
本文中后面所述實(shí)施例的目的是解決至少ー些上面概述的問題,并且此目的和其它目的通過根據(jù)隨附獨(dú)立權(quán)利要求的方法和設(shè)備和通過根據(jù)從屬權(quán)利要求的實(shí)施例而得以實(shí)現(xiàn)。根據(jù)第一方面的實(shí)施例提供一種用于用戶設(shè)備設(shè)置從內(nèi)容服務(wù)器下載IPTV內(nèi)容 的策略或上載IPTV內(nèi)容到內(nèi)容服務(wù)器的策略的方法。用戶設(shè)備生成包括內(nèi)容下載或內(nèi)容上載的類型的指示的請求,并將請求傳送到IPTV控制節(jié)點(diǎn)。根據(jù)第二方面的實(shí)施例提供一種用于IPTV控制節(jié)點(diǎn)設(shè)置從內(nèi)容服務(wù)器下載IPTV內(nèi)容到用戶設(shè)備,或者從用戶設(shè)備上載IPTV內(nèi)容到內(nèi)容服務(wù)器的策略的方法。IPTV控制節(jié)點(diǎn)從用戶設(shè)備接收請求,請求包括內(nèi)容下載或內(nèi)容上載的類型的指示。根據(jù)第三方面的實(shí)施例提供ー種布置成設(shè)置用于從內(nèi)容服務(wù)器下載IPTV內(nèi)容和/或用于上載IPTV內(nèi)容到內(nèi)容服務(wù)器的策略的用戶設(shè)備。用戶設(shè)備包括提供有處理電路的通信裝置,并配置成生成包括內(nèi)容下載和/或內(nèi)容上載的類型的指示的請求,并將請求傳送到IPTV控制節(jié)點(diǎn)。根據(jù)第四方面的實(shí)施例提供布置成設(shè)置用于從內(nèi)容服務(wù)器下載IPTV內(nèi)容到用戶設(shè)備和/或從用戶設(shè)備上載IPTV內(nèi)容到內(nèi)容服務(wù)器的策略的IPTV控制節(jié)點(diǎn)。IPTV控制節(jié)點(diǎn)包括提供有處理電路的通信裝置,并配置 成從用戶設(shè)備接收請求,并且請求包括內(nèi)容下載和/或內(nèi)容上載的類型的指示。示范實(shí)施例有關(guān)的優(yōu)點(diǎn)是使能媒體內(nèi)容的可靠下載或上載,使得播出的用戶體驗(yàn)不受例如網(wǎng)絡(luò)中擁塞的影響。


下面將參照附圖并且更詳細(xì)地描述本發(fā)明,其中
圖Ia是示出用于媒體內(nèi)容的下載和上載的示范IMS IPTV體系結(jié)構(gòu)的框 圖Ib示出OITF使能的UE ;
圖2a和2b是以示意圖方式示出在IMS IPTV體系結(jié)構(gòu)中示范UE發(fā)起的內(nèi)容下載會(huì)話的信令 圖2c和2d是以示意圖方式示出用于普通IPTV的示范UE發(fā)起的內(nèi)容下載會(huì)話的信令
圖3是以示意圖方式示出用干與內(nèi)容上載或內(nèi)容下載有關(guān)的UE的方法的流程 圖4是以示意圖方式示出用干與內(nèi)容上載或內(nèi)容下載有關(guān)的IPTV控制節(jié)點(diǎn)的方法的流程 圖5是以示意圖方式示出示范UE的框圖,以及 圖6是以示意圖方式示出示范IPTV控制節(jié)點(diǎn)的框圖。
具體實(shí)施例方式在下面,將參照某些實(shí)施例和附圖更詳細(xì)地描述本發(fā)明。為說明而不是限制的目的,陳述了特定的細(xì)節(jié),如特殊的情形、技術(shù)等,以便提供對本發(fā)明的透徹理解。然而,本領(lǐng)域的技術(shù)人員明白,可在脫離這些特定細(xì)節(jié)的其它實(shí)施例中實(shí)踐本發(fā)明。此外,本領(lǐng)域的技術(shù)人員將領(lǐng)會(huì),可使用結(jié)合按照編程的微處理器或通用計(jì)算機(jī)起作用的軟件和/或使用專用集成電路(ASIC)來實(shí)現(xiàn)本文下面所說明的功能和部件。也將領(lǐng)會(huì)的是,雖然主要以方法和裝置的形式來描述本發(fā)明,但也可在計(jì)算機(jī)程序產(chǎn)品中及在包括計(jì)算機(jī)處理器和耦合到處理器的存儲(chǔ)器的系統(tǒng)中實(shí)施本發(fā)明,其中存儲(chǔ)器編碼有可執(zhí)行本文中公開功能的ー個(gè)或多個(gè)程序。本文后面所述實(shí)施例的概念是在來自用戶設(shè)備的初始請求中指示內(nèi)容下載或內(nèi)容上載的類型,以便設(shè)置用于媒體內(nèi)容的下載和/或上載的策略,例如,以預(yù)留適合的帶寬。
根據(jù)另外實(shí)施例,由請求中的傳遞類型屬性來指示內(nèi)容下載或內(nèi)容上載的類型,該屬性被包括在初始請求中包含的SDP提議(SDP Offer)中。根據(jù)另ー實(shí)施例,建議帶寬的帶寬屬性可選地被包括在初始請求中。
所述傳遞類型屬性例如向IMS和向本地傳輸策略指示將設(shè)置帶有特定要求的會(huì)話。例如,如果傳遞類型屬性指示流傳送下載,并且在帶寬屬性中指示特定帶寬,則流傳送下載會(huì)話將被設(shè)置,帶有根據(jù)帶寬屬性中指示帶寬的保證帶寬。因此,在帶寬屬性中指示的帶寬指示為獲得順暢傳送而需要的預(yù)期最大帶寬。根據(jù)另外實(shí)施例,在要求用于請求中指示的傳輸類型的帶寬在網(wǎng)絡(luò)中不可用的情況下,將拒絕包括傳輸類型屬性和可選地包括建議的帶寬的請求。如果這樣,則用戶設(shè)備可在下一請求中包括不同的傳輸類型屬性。在基于IMS的IPTV解決方案中,根據(jù)示范實(shí)施例,例如,如根據(jù)TISPN RACS體系結(jié)構(gòu)所定義的一祥,可確保QoS (服務(wù)質(zhì)量)。例如在TISPAN規(guī)范和在OITF (開放IPTV論壇)規(guī)范中指定用于線性TV和用于視頻點(diǎn)播的要求信令。示范實(shí)施例在內(nèi)容下載、內(nèi)容上載和例如頂S/RACS提供的上面提到的QoS機(jī)制之間提供聯(lián)系,以便確保最小傳送速度可用于支持在例如漸進(jìn)式下載、流傳送下載和自適應(yīng)流傳送下載類型的下載期間媒體內(nèi)容的不間斷觀看。因此,根據(jù)本發(fā)明的ー實(shí)施例,上面提到的傳遞類型屬性被包括在用于內(nèi)容下載的SDP提議中,以便設(shè)置專門用于內(nèi)容下載的策略。此屬性使能靈活地控制在頂S/RACS中的本地策略,如預(yù)留帶寬,在路徑中添加BGF (邊界網(wǎng)關(guān)功能)或在接入網(wǎng)絡(luò)中選擇適當(dāng)?shù)膬?yōu)先級。例如根據(jù)標(biāo)準(zhǔn)化SPDF (基于服務(wù)的策略判定功能)來設(shè)置RACS策略。通常,由用戶設(shè)備基于最終用戶的動(dòng)作和用戶設(shè)備的配置來確定用于HTTP內(nèi)容下載的傳輸類型。如果用戶選擇要觀看的內(nèi)容,并且用戶設(shè)備未配置成存儲(chǔ)內(nèi)容,則將使用內(nèi)容的流傳送下載以來自用戶設(shè)備的播出的速率從內(nèi)容服務(wù)器取回內(nèi)容。然而,如果用戶設(shè)備配置成存儲(chǔ)內(nèi)容,則將使用漸進(jìn)式下載從內(nèi)容服務(wù)器取回內(nèi)容,即,內(nèi)容在用戶設(shè)備中存儲(chǔ)或緩沖并且同時(shí)播出。在自適應(yīng)流傳送下載中,最終用戶請求內(nèi)容將作為自適應(yīng)流可用,使得能夠根據(jù)特別方案以不同比特率下載內(nèi)容。例如,如果用戶設(shè)備檢測到緩沖器正變空,則它可假設(shè)缺少用于更高比特率流的帶寬,并轉(zhuǎn)移到更低的下載比特率。如上所述,常規(guī)HTTP內(nèi)容下載是盡力而為類型的傳送,并且下載的速率受可用帶寬限制。然而,為實(shí)現(xiàn)在不同類型的內(nèi)容下載和內(nèi)容上載之間的區(qū)別,根據(jù)本發(fā)明的實(shí)施例,在來自用戶設(shè)備的初始請求中包括傳遞類型屬性。用比盡力而為QoS稍微更高的QoS來區(qū)分不同類型的內(nèi)容下載,這是因?yàn)楸M力而為QoS沒有最小傳送要求。如上所述,描述的概念不但適用于下載,而且能夠用于例如用戶生成的內(nèi)容的上載。上載的內(nèi)容可隨后與使用下載的其它用戶共享,并且因此將要求一致的傳遞。圖Ia是示出用于從內(nèi)容服務(wù)器下載媒體到UE或者上載媒體內(nèi)容到內(nèi)容服務(wù)器的示范MS IPTV體系結(jié)構(gòu)和MS IPTV中的適用協(xié)議(S卩,SIP (會(huì)話發(fā)起協(xié)議)和HTTP (超文本傳遞協(xié)議))的框圖。體系結(jié)構(gòu)包括OITF使能的UE IUMS網(wǎng)關(guān)2、如圖中頂S/RACS圓圈3所指示的MS媒體服務(wù)器或視頻點(diǎn)播泵、IPTV控制器4及包括媒體控制功能(MCF)的內(nèi)容服務(wù)器5。IPTV控制器4可例如包括如在開放IPTV論壇中定義的IPTV應(yīng)用平臺(tái)(IAP)。圖Ib是以示意圖方式示出OITF使能的用戶設(shè)備I的框圖,其包括用于如開放IPTV論壇規(guī)范中所定義的聲明型應(yīng)用環(huán)境(Declarative Application Environment,DAE)及本地對象代碼(local object code)的功能性,DAE包括UE的瀏覽器。
更具體地說,在示范UE發(fā)起的單播內(nèi)容下載會(huì)話中,始發(fā)UE生成初始邀請(INVITE)請求。請求URI (統(tǒng)ー資源標(biāo)識符)包含在單播定位器中及在去往(TO)報(bào)頭中的下載內(nèi)容URI,從服務(wù)選擇信息中取回所述標(biāo)識符。另外,來自(FROM)報(bào)頭指示用戶的公共用戶身份。根據(jù)媒體能力和可用于內(nèi)容下載會(huì)話的要求帶寬,SDP提議被包括在邀請請求中。因此,在媒體級示范典型SDP提議可例如包括以下元素
-用于HTTP下載的“ m=”行,例如具有以下格式
m=〈媒體〉〈端ロ〉〈傳輸〉媒體字段具有“application”的值,端ロ字段設(shè)為值9,其是丟棄端ロ,以及傳輸字段設(shè)為TCP。另外,包括fmt參數(shù)并設(shè)為iptv_http,導(dǎo)致‘-m=application 9 tcp iptv_http,,。- “a=setup,,屬性設(shè)為 “active,,,例如,a=setup: active。- “a=connection” 屬性設(shè)為 “new,,,例如, a=connection: new。- “c=”行被包括在網(wǎng)絡(luò)類型中,值設(shè)為IN,地址類型設(shè)為IP4或IP6,以及有關(guān)HTTP信道的流的IP地址,例如,c=IN IP4〈IP地址>)。根據(jù)本發(fā)明的ー實(shí)施例,SDP提議的“b=”行可以可選地包含指示建議的帶寬的帶寬屬性。如果用戶在服務(wù)選擇過程期間已取得要求用于此特殊內(nèi)容輸送信道的帶寬,則在媒體級的帶寬屬性在“b=”行中設(shè)為此值,例如,b=AS: 15000。相應(yīng)地,內(nèi)容服務(wù)器的MCF (媒體控制功能)將經(jīng)由IPTV控制器接收SDP提議,SDP提議可包含傳遞類型屬性及指示建議的帶寬的帶寬屬性(在“b=”行中)。內(nèi)容服務(wù)器的MCF將幫助IPTV控制器為下載或上載準(zhǔn)備內(nèi)容,并且將接收的傳遞類型屬性復(fù)制到SDP應(yīng)答中,其被轉(zhuǎn)發(fā)到IPTV控制器。另外,根據(jù)本發(fā)明的示范實(shí)施例,如上所述,在初始邀請請求中例如通過在SDP提議中包含的傳遞類型屬性(如“fmtp: iptv_http transfer-type”屬性)指示內(nèi)容下載的類型。根據(jù)本發(fā)明的第一實(shí)施例,適用于傳遞類型屬性的值是“漸進(jìn)式”(“progressive”)和“流傳送”(“streaming”)及“自適應(yīng)”(“adaptive”)。“漸進(jìn)式”內(nèi)容下載類型指示在下載期間觀看的內(nèi)容,并且在UE中存儲(chǔ)或緩沖內(nèi)容,其要求相對大的帶寬。例如HTTP流傳送等“流傳送”內(nèi)容下載類型指示觀看而不存儲(chǔ)的內(nèi)容或類似于RTSP流傳送,在UE中帶有有限緩沖的內(nèi)容。例如HTTP自適應(yīng)流傳送等“自適應(yīng)”內(nèi)容下載類型指示可以在不同帶寬和用不同質(zhì)量觀看的內(nèi)容?!癰=”行是可選帶寬屬性,并且指示用于最佳質(zhì)量流傳送的帶寬。根據(jù)另外示范實(shí)施例,傳遞類型屬性的各種其它值能夠用于指示內(nèi)容下載的其它專有類型,例如,a=fmt: iptv_http transfer-type =〈傳遞類型〉。
圖2a和2b示出說明用于在MS IPTV體系結(jié)構(gòu)中充當(dāng)客戶端終端的用戶設(shè)備I的示范信令序列的信令圖。根據(jù)本發(fā)明的實(shí)施例,圖形示出用戶設(shè)備從內(nèi)容服務(wù)器5下載媒體內(nèi)容,下載涉及帶寬預(yù)留。圖形也示出可涉及的邏輯單元。UE (OITF)框I指示OITF使能的用戶設(shè)備,包括用于如在開放IPTV論壇中所定義的聲明型應(yīng)用環(huán)境(DAE)及本地對象代碼(LOC)的功能性。另外,IG框2對應(yīng)于MS網(wǎng)關(guān),IMS/RACS框3對應(yīng)于MS媒體服務(wù)器或視頻點(diǎn)播泵,以及IPTV控制器4包括IPTV應(yīng)用平臺(tái)(IAP)。內(nèi)容服務(wù)器5包括媒體控制器功能(MCF)。在圖2a中的信號Sll中,UE I發(fā)起在信號S12中創(chuàng)建的下載會(huì)話。在信號S13中,SIP邀請從MS網(wǎng)關(guān)2轉(zhuǎn)發(fā)到MS媒體服務(wù)器3,并且在信號S15中,進(jìn)ー步轉(zhuǎn)發(fā)到IPTV控制器4,SIP邀請包括SDP (會(huì)話描述協(xié)議)提議,并且在步驟16中,內(nèi)容由IPTV控制器4和內(nèi)容服務(wù)器5準(zhǔn)備以供下載。在前面的步驟14中,由IMS/RACS檢查并應(yīng)用用于下載的策略,并且可執(zhí)行帶寬預(yù) 留。這涉及由RACS檢查接入網(wǎng)絡(luò)中的網(wǎng)絡(luò)拓?fù)湟员愦_定在SIP邀請的SDP提議中指示的傳輸類型要求的帶寬是否可用。如果可用,則預(yù)留帶寬,并且在信號S15中將SIP邀請轉(zhuǎn)發(fā)到IPTV控制器。然而,如果要求的帶寬不可用,則SIP邀請將被拒絕,并且不轉(zhuǎn)發(fā)到IPTV控制器。在IPTV控制器接收非被拒絕的SIP邀請時(shí),將在上面提到的步驟16中準(zhǔn)備內(nèi)容以供下載。接著,在信號S17中,IPTV控制器將用在信號S19中轉(zhuǎn)發(fā)到MS網(wǎng)關(guān)的SDP應(yīng)答及到會(huì)話的URL做出響應(yīng),并且在前面的步驟18中,帶寬預(yù)留被確認(rèn)。之后,在信號S20中創(chuàng)建會(huì)話。在圖2b中的信號S21、S22和S23中,UE使用接收的會(huì)話URL從內(nèi)容服務(wù)器5下載內(nèi)容。在信號S24-S30中,終止下載會(huì)話,包括在步驟26中釋放網(wǎng)絡(luò)資源,并且最終在信號S31和S32中,播出下載的內(nèi)容。上述圖2a和2b示出下載會(huì)話。然而,類似的信令過程可用于上載會(huì)話。其它示范實(shí)施例針對使用例如SOAP (簡單對象訪問協(xié)議)或DIAMETER協(xié)議的其它協(xié)議而不是SIP的非MS網(wǎng)絡(luò)中的普通IPTV。因此,圖形2c和2d示出用于無MS網(wǎng)關(guān)、使用SOAP并且具有到IPTV控制器4的RACS接ロ 3的普通IPTV體系結(jié)構(gòu)的示范信令圖。在圖2c中的信號SllO中,UE I發(fā)起在信號S120中創(chuàng)建的下載會(huì)話。在信號S130中,IPTV控制器向RACS接ロ發(fā)出SOAP預(yù)留帶寬。如果在步驟140中確認(rèn)預(yù)留,則在信號S150中,將SOAP響應(yīng)發(fā)送到IPTV控制器。在步驟160中,IPTV控制器準(zhǔn)備內(nèi)容以供下載,并且在信號S170中創(chuàng)建會(huì)話。在圖2d中的信號S180、S190和S200中,UE使用接收的會(huì)話URL從內(nèi)容服務(wù)器5下載內(nèi)容。在信號S210-S260中,終止下載會(huì)話,包括在步驟230中釋放網(wǎng)絡(luò)資源,并且最終在信號S270和S280中,播出下載的內(nèi)容。圖3是以示意圖方式示出根據(jù)本發(fā)明的實(shí)施例的一種用于用戶設(shè)備設(shè)置媒體內(nèi)容的上載或下載的策略的方法的流程圖。在步驟35中,UE生成指示內(nèi)容下載或內(nèi)容上載的類型的請求,并在步驟36中將請求傳送到IPTV控制節(jié)點(diǎn)。根據(jù)另外實(shí)施例,策略是帶寬預(yù)留,并且由在初始請求的SDP提議中包括的傳輸類型屬性來指示類型。根據(jù)又另外實(shí)施例,傳遞類型屬性具有如上所定義的值“漸進(jìn)式”、“流傳送”或“自適應(yīng)”之一。在針對下載時(shí),圖3中的步驟35和36基本上對應(yīng)于圖2a中的信號S11-S15。
圖4是以示意圖方式示出根據(jù)本發(fā)明的實(shí)施例的一種用于IPTV控制節(jié)點(diǎn)設(shè)置媒體內(nèi)容的上載或下載的策略的方法的流程圖。在步驟41中,IPTV控制節(jié)點(diǎn)從UE接收請求,該請求指示內(nèi)容下載或內(nèi)容上載的類型。在步驟42中,IPTV控制節(jié)點(diǎn)經(jīng)由內(nèi)容服務(wù)器的MCF (媒體控制功能)將下載或上載的類型復(fù)制到SDP應(yīng)答中。根據(jù)另外實(shí)施例,策略是帶寬預(yù)留,其是基于如在上面提到的步驟41中從UE接收的初始請求的SDP提議中包括的傳輸類型屬性所指示的內(nèi)容下載或上載的類型根據(jù)預(yù)期傳送速度設(shè)置的。根據(jù)又另外實(shí)施例,傳遞類型屬性的值例如是漸進(jìn)式、流傳送或自適應(yīng)。
圖5是示出根據(jù)本發(fā)明的實(shí)施例的用戶設(shè)備I的框圖。UE I例如是OITF使能的移動(dòng)電話、PC或TV,包括適合的用戶接ロ,并且它提供有處理器電路和例如對應(yīng)于如在開放IPTV論壇中所定義的聲明型應(yīng)用環(huán)境(DAE)及本地對象代碼的適當(dāng)軟件。軟件還配置成執(zhí)行根據(jù)本發(fā)明的實(shí)施例的方法。UE也提供有包括傳送器、接收器和處理電路52的常規(guī)通信裝置51以便例如經(jīng)由MS網(wǎng)關(guān)和MS媒體服務(wù)器與IPTV控制器進(jìn)行通信。根據(jù)ー示范實(shí)施例,UE生成并傳送包括SDP提議的請求,SDP提議指示內(nèi)容下載和/或內(nèi)容上載的類型。圖6是示出包括IPTV應(yīng)用平臺(tái)(IAP)的示范IPTV控制節(jié)點(diǎn)4的框圖。IPTV控制節(jié)點(diǎn)還提供有包括傳送器、接收器和處理電路62的通信裝置61,并且借助通信裝置和其它適當(dāng)?shù)挠布蛙浖?,IPTV控制節(jié)點(diǎn)配置成從UE接收指示內(nèi)容下載或內(nèi)容上載的類型的請求,例如,在SDP提議中包括的傳遞類型屬性中。根據(jù)另外實(shí)施例,通信裝置配置成經(jīng)由在內(nèi)容服務(wù)器中包含的MCF (媒體控制功能),將傳遞類型屬性復(fù)制到SDP應(yīng)答中。根據(jù)ー優(yōu)選實(shí)施例,策略是帶寬預(yù)留,并且IPTV控制節(jié)點(diǎn)布置成基于接收的傳遞類型屬性,設(shè)置帶有根據(jù)預(yù)期傳送速度的帶寬的會(huì)話。參照圖5和6的上述實(shí)體和單元是邏輯單元,其不一定對應(yīng)于單獨(dú)的物理単元。因此,根據(jù)用于針對媒體內(nèi)容的下載的用戶設(shè)備的方法的實(shí)施例,用戶設(shè)備I通過生成包括內(nèi)容下載類型的指示的請求并將請求傳送到IPTV控制器4,設(shè)置用于從服務(wù)器下載IPTV內(nèi)容的策略。根據(jù)示范實(shí)施例,策略是帶寬預(yù)留,并且由標(biāo)準(zhǔn)化傳遞類型屬性來指示內(nèi)容下載類型,例如,表示漸進(jìn)式下載的漸進(jìn)式、表示流傳送下載的流傳送或表示自適應(yīng)流傳送下載的自適應(yīng)。根據(jù)另外示范實(shí)施例,IPTV是基于MS的,并且內(nèi)容下載類型的指示被包含在請求中包括的SDP提議中。另外,SDP提議可包括指示建議的帶寬的帶寬屬性。根據(jù)又另外實(shí)施例,如果傳輸類型屬性指示的傳輸類型所要求的帶寬不可用,則用戶設(shè)備將接收對請求的拒絕,并且用戶設(shè)備可在接收拒絕時(shí)生成包括不同傳輸類型屬性的請求。根據(jù)用于針對上載的用戶設(shè)備的類似方法的實(shí)施例,用戶設(shè)備I通過生成包括內(nèi)容上載類型的指示的請求并將請求傳送到IPTV控制器4,設(shè)置用于上載IPTV內(nèi)容到服務(wù)器的策略。根據(jù)另外示范實(shí)施例,策略是根據(jù)預(yù)期傳送速度設(shè)置的帶寬預(yù)留,并且由例如“漸進(jìn)式”、“流傳送”或“自適應(yīng)”(屬性分別表示漸進(jìn)式上載、流傳送上載和自適應(yīng)流傳送上載)等標(biāo)準(zhǔn)化傳遞類型屬性來指示內(nèi)容上載類型。
根據(jù)其它示范實(shí)施例,IPTV是基于MS的,并且內(nèi)容上載類型的指示被包含在請求中包括的SDP提議中。另外,SDP提議可包括指示建議的帶寬的帶寬屬性。根據(jù)又另外實(shí)施例,如果傳輸類型屬性指示的傳輸類型所要求的帶寬不可用,則用戶設(shè)備將接收對請求的拒絕,并且用戶設(shè)備可在接收拒絕時(shí)生成包括不同傳輸類型屬性的請求。用戶設(shè)備與IPTV控制節(jié)點(diǎn)進(jìn)行通信以便設(shè)置用于上載和下載的策略。根據(jù)用于針對下載的IPTV控制節(jié)點(diǎn)的方法的實(shí)施例,IPTV控制節(jié)點(diǎn)4設(shè)置用于從內(nèi)容服務(wù)器5下載IPTV內(nèi)容到用戶設(shè)備I的策略,IPTV控制器從用戶設(shè)備接收請求,該請求包括內(nèi)容下載類型的指示。根據(jù)另外示范實(shí)施例,策略是帶寬預(yù)留,其是由IPTV控制節(jié)點(diǎn)4基于接收的內(nèi)容下載的類型的指示根據(jù)預(yù)期傳送速度設(shè)置的。所述內(nèi)容下載類型由例如“漸進(jìn)式”、“流傳送”或“自適應(yīng)”(屬性分別表示漸進(jìn)式上載、流傳送上載和自適應(yīng)流傳送上載)等標(biāo)準(zhǔn)化傳遞類型屬性指示。根據(jù)又其它實(shí)施例,IPTV是基于MS的,并且內(nèi)容下載類型的指示被包含在從UE接收的請求中包括的SDP提議中。另外,SDP提議可包括指示建議的帶寬的帶寬屬性,并且內(nèi)容下載類型的指示可復(fù)制到SDP應(yīng)答中。根據(jù)用于針對上載的IPTV控制節(jié)點(diǎn)的方法的實(shí)施例,IPTV控制節(jié)點(diǎn)4設(shè)置用于從UE I上載IPTV內(nèi)容到內(nèi)容服務(wù)器5的策略,IPTV控制器從用戶設(shè)備接收請求,該請求包括內(nèi)容上載類型的指示。根據(jù)示范實(shí)施例,策略是帶寬預(yù)留,其是基于接收的內(nèi)容上載的類型的指示根據(jù)預(yù)期傳送速度設(shè)置的。所述內(nèi)容上載類型由例如“漸進(jìn)式”、“流傳送”或“自適應(yīng)”(屬性分別表示漸進(jìn)式上載、流傳送上載和自適應(yīng)流傳送上載)等標(biāo)準(zhǔn)化傳遞類型屬性指示。根據(jù)另外示范實(shí)施例,IPTV是基于MS的,并且內(nèi)容上載類型的指示被包含在請求中包括的SDP提議中。另外,SDP提議包括指示建議的帶寬的帶寬屬性,并且內(nèi)容上載類型的指示被復(fù)制到SDP應(yīng)答中。根據(jù)用戶設(shè)備I的實(shí)施例,UE布置成設(shè)置用于從內(nèi)容服務(wù)器5下載IPTV內(nèi)容的策略,用戶設(shè)備包括提供有處理電路62的通信裝置61,并且配置成生成包括內(nèi)容下載類型的指示的請求,以及將請求傳送到IPTV控制節(jié)點(diǎn)4。另外,根據(jù)用戶設(shè)備的實(shí)施例,用戶設(shè)備I布置成設(shè)置用于上載IPTV內(nèi)容到服務(wù)器5的策略,用戶設(shè)備包括提供有處理電路62的通信裝置61,并且配置成生成包括內(nèi)容上載類型的指示的請求,以及將請求傳送到IPTV控制節(jié)點(diǎn)。因此,根據(jù)本發(fā)明的用戶設(shè)備優(yōu)選布置成設(shè)置用于下載和上載兩者的策略,但可備選布置成設(shè)置用于下載或上載的策略。根據(jù)所述用戶設(shè)備的另外示范實(shí)施例,策略是帶寬預(yù)留,并且內(nèi)容下載類型和/或內(nèi)容上載類型由例如“漸進(jìn)式”、“流傳送”或“自適應(yīng)”(屬性分別表示漸進(jìn)式上載、流傳送上載和自適應(yīng)流傳送上載)等標(biāo)準(zhǔn)化傳遞類型屬性指示。根據(jù)又另外示范實(shí)施例,IPTV是基于MS的,并且傳遞類型屬性的指示被包含在請求中包括的SDP提議中。另外,SDP提議還包括建議的帶寬,并且UE是OITF使能的。類似于如關(guān)于上述示范方法,用戶設(shè)備配置成與IPTV控制節(jié)點(diǎn)進(jìn)行通信以設(shè)置、用于上載和下載的策略。根據(jù)IPTV控制節(jié)點(diǎn)4的實(shí)施例,IPTV控制節(jié)點(diǎn)4布置成設(shè)置用于從內(nèi)容服務(wù)器5下載IPTV內(nèi)容到用戶設(shè)備I的策略,IPTV控制節(jié)點(diǎn)包括提供有處理電路52的通信裝置51,并且配置成從用戶設(shè)備接收請求,該請求包括內(nèi)容下載類型的指示。另外,根據(jù)IPTV控制節(jié)點(diǎn)4的實(shí)施例,IPTV控制節(jié)點(diǎn)布置成設(shè)置用于從內(nèi)容服務(wù)器5上載IPTV內(nèi)容到用戶設(shè)備I的策略,所述節(jié)點(diǎn)包括提供有處理電路52的通信裝置51,并且配置成從用戶設(shè)備接收請求,該請求包括內(nèi)容上載類型的指示。根據(jù)另ー示范實(shí)施例,策略是帶寬預(yù)留,并且IPTV控制節(jié)點(diǎn)布置成基于接收的內(nèi)容下載和/或內(nèi)容上載的類型的指示根據(jù)預(yù)期傳送速度來設(shè)置帶寬預(yù)留。所述內(nèi)容下載類型和/或內(nèi)容上載類型由例如“漸進(jìn)式”、“流傳送”或“自適應(yīng)”(屬性分別表示漸進(jìn)式上載、流傳送上載和自適應(yīng)流傳送上載)等標(biāo)準(zhǔn)化傳遞類型屬性指示。根據(jù)又另外示范實(shí)施例,IPTV是基于MS的,并且傳遞類型屬性被包含在請求中包括的SDP提議中,SDP提議還包括建議的帶寬。IPTV控制節(jié)點(diǎn)還可布置成經(jīng)由內(nèi)容服務(wù)器的MCF將接收的內(nèi)容上載類型和/或內(nèi)容下載類型的指示復(fù)制到SDP應(yīng)答中。因此,根據(jù)實(shí)施例的IPTV控制節(jié)點(diǎn)優(yōu)選布置成設(shè)置用于下載和上載兩者的策略,但可備選布置成設(shè)置用于下載或上載的策略。如結(jié)合圖2c和2d進(jìn)ー步所述,示范實(shí)施例適用于非MS網(wǎng)絡(luò),例如在所謂的普通或傳統(tǒng)IPTV中。然而,在使用非IMS網(wǎng)絡(luò)的情況下,要求類似于SIP的単獨(dú)協(xié)議以便與后端創(chuàng)建會(huì)話以進(jìn)行帶寬的分配和解除分配,例如,SOAP或DIAMETER協(xié)議。備選地,能夠添加包括建議的帶寬和傳遞類型的新HTTP報(bào)頭,或者能夠在HTTP請求URI中封裝信息而不要求任何単獨(dú)的協(xié)議。此外,只作為示例給出上面提到和描述的實(shí)施例,并且不應(yīng)限制本發(fā)明。本領(lǐng)域的技術(shù)人員應(yīng)該明白如附帯專利權(quán)利要求書中要求保護(hù)的本發(fā)明范圍內(nèi)的其它解決方案、使用、目的和功能??s略詞
OITF =開放IPTV論壇
SDP =會(huì)話描述協(xié)議
MCF =媒體控制功能
IAP = IPTV應(yīng)用平臺(tái)
RACS =資源和準(zhǔn)入控制子系統(tǒng)
SPDF =基于服務(wù)的策略判定功能
DAE =聲明型應(yīng)用環(huán)境
QoS =服務(wù)質(zhì)量
URI =統(tǒng)ー資源標(biāo)識符
SOAP =簡單對象訪問協(xié)議
HTTP =超文本傳遞協(xié)議
SIP =會(huì)話發(fā)起協(xié)議
權(quán)利要求
1.一種用于用戶設(shè)備(I)設(shè)置從內(nèi)容服務(wù)器(5)下載IPTV內(nèi)容的策略或者上載IPTV內(nèi)容到內(nèi)容服務(wù)器(5)的策略的方法,所述方法包括 -生成(31)包括內(nèi)容下載或內(nèi)容上載的類型的指示的請求,以及 -將所述請求傳送(32)到IPTV控制節(jié)點(diǎn)(4)。
2.根據(jù)權(quán)利要求I的方法,其中所述策略是帶寬預(yù)留。
3.根據(jù)權(quán)利要求I或2的方法,其中由傳遞類型屬性來指示內(nèi)容下載或內(nèi)容上載的所述類型。
4.根據(jù)權(quán)利要求3的方法,其中所述傳遞類型屬性具有值漸進(jìn)式、流傳送或自適應(yīng)之o
5.根據(jù)前面權(quán)利要求中任一項(xiàng)的方法,其中所述IPTV是基于MS的,并且所述傳遞類型屬性被包含在所述請求中包括的SDP提議中。
6.根據(jù)權(quán)利要求5的方法,其中所述SDP提議還包括建議的帶寬。
7.根據(jù)權(quán)利要求2-6中任一項(xiàng)的方法,還包括如果傳輸類型屬性要求的帶寬不可用,則所述用戶設(shè)備接收對所述請求的拒絕。
8.根據(jù)權(quán)利要求7的方法,包括如果接收到拒絕,則生成包含不同傳輸類型屬性的請求。
9.一種用于IPTV控制節(jié)點(diǎn)(4 )設(shè)置從內(nèi)容服務(wù)器(5 )下載IPTV內(nèi)容到用戶設(shè)備(I)或者從用戶設(shè)備(I)上載IPTV內(nèi)容到內(nèi)容服務(wù)器(5)的策略的方法,所述方法包括 -從所述用戶設(shè)備接收(41)請求,所述請求包括內(nèi)容下載或內(nèi)容上載的類型的指示。
10.根據(jù)權(quán)利要求9的方法,其中由傳遞類型屬性來指示內(nèi)容下載或內(nèi)容上載的所述類型。
11.根據(jù)權(quán)利要求9或10的方法,其中所述策略是帶寬預(yù)留,其是基于內(nèi)容下載或內(nèi)容上載的所述類型根據(jù)預(yù)期傳送速度設(shè)置的。
12.根據(jù)權(quán)利要求10或11的方法,還包括 -經(jīng)由所述內(nèi)容服務(wù)器(5)的MCF (媒體控制功能),將所述傳遞類型屬性從所述請求中包括的SDP提議復(fù)制(42)到響應(yīng)中包括的SDP應(yīng)答中。
13.—種布置成設(shè)置用于從內(nèi)容服務(wù)器(5)下載IPTV內(nèi)容和/或上載IPTV內(nèi)容到內(nèi)容服務(wù)器(5)的策略的用戶設(shè)備(1),所述用戶設(shè)備包括提供有處理電路(52)的通信裝置(51),并配置成執(zhí)行以下操作 -生成包括內(nèi)容下載和/或內(nèi)容上載的類型的指示的請求,以及 -將所述請求傳送到IPTV控制節(jié)點(diǎn)(4)。
14.根據(jù)權(quán)利要求13的UE,其中所述策略是帶寬預(yù)留。
15.根據(jù)權(quán)利要求13或14的UE,其中由傳遞類型屬性來指示內(nèi)容下載和/或內(nèi)容上載的所述類型。
16.根據(jù)權(quán)利要求15的UE,其中所述傳遞類型屬性具有值漸進(jìn)式、流傳送或自適應(yīng)之o
17.如權(quán)利要求15或16的UE,其中所述IPTV是基于MS的,并且所述傳遞類型屬性被包含在所述請求中包括的SDP提議中。
18.根據(jù)權(quán)利要求17的UE,其中所述SDP提議還包括建議的帶寬。
19.一種布置成設(shè)置用于從內(nèi)容服務(wù)器(5)下載IPTV內(nèi)容到用戶設(shè)備(I)和/或用于從用戶設(shè)備(I)上載IPTV內(nèi)容到內(nèi)容服務(wù)器(5)的策略的IPTV控制節(jié)點(diǎn)(4),所述IPTV控制節(jié)點(diǎn)包括提供有處理電路(62)的通信裝置(61),并配置成執(zhí)行以下操作 -從所述用戶設(shè)備接收請求,所述請求包括內(nèi)容下載和/或內(nèi)容上載的類型的指示。
20.根據(jù)權(quán)利要求19的IPTV控制節(jié)點(diǎn)(4),其中由傳遞類型屬性來指示內(nèi)容下載和/或內(nèi)容上載的所述類型。
21.根據(jù)權(quán)利要求19或20的IPTV控制節(jié)點(diǎn),其中所述策略是帶寬預(yù)留,其是基于內(nèi)容下載或內(nèi)容上載的所述類型根據(jù)預(yù)期傳送速度設(shè)置的。
22.根據(jù)權(quán)利要求20或21的IPTV控制節(jié)點(diǎn),還配置成經(jīng)由所述內(nèi)容服務(wù)器(5)的MCF(媒體控制功能),將所述傳遞類型屬性從在所述請求中包括的SDP提議復(fù)制到響應(yīng)中包括的SDP應(yīng)答中。
全文摘要
用于設(shè)置從內(nèi)容服務(wù)器(5)下載IPTV媒體內(nèi)容到用戶設(shè)備(1)和/或從用戶設(shè)備上載媒體內(nèi)容到內(nèi)容服務(wù)器的策略的方法和設(shè)備。策略通常是帶寬預(yù)留,并且內(nèi)容下載/上載的類型將被包括在從用戶設(shè)備發(fā)送到IPTV控制節(jié)點(diǎn)(4)的初始請求中,例如在SDP提議中。
文檔編號H04N21/643GK102652421SQ201080055870
公開日2012年8月29日 申請日期2010年11月30日 優(yōu)先權(quán)日2009年12月9日
發(fā)明者J.E.林德奎斯特, M.塞德瓦爾 申請人:瑞典愛立信有限公司
網(wǎng)友詢問留言 已有0條留言
  • 還沒有人留言評論。精彩留言會(huì)獲得點(diǎn)贊!
1