專利名稱：上下文知曉的內(nèi)容傳送的制作方法
技術(shù)領(lǐng)域：
本發(fā)明涉及電子通信網(wǎng)絡(luò)，更具體地說，涉及分組交換通信網(wǎng)絡(luò)中的內(nèi)容傳送。
背景技術(shù)：
在當(dāng)前的通信網(wǎng)絡(luò)中，移動(dòng)運(yùn)營商和固定運(yùn)營商面臨越來越大量的“過頂傳球”(OTT)內(nèi)容，也即是說，在運(yùn)營商的主要傳送基礎(chǔ)設(shè)施的替代物上傳送的音頻、視頻或者其它內(nèi)容或應(yīng)用。因此，運(yùn)營商和網(wǎng)絡(luò)提供商逐漸淪為諸如YouTube、LLC和其它流式媒體提供商等的數(shù)據(jù)密集型內(nèi)容提供商的單純的比特管道。例如，在2009年12月，Amazon, com有限公司宣布了用于內(nèi)容傳送的CloudFront網(wǎng)絡(luò)服務(wù)，該網(wǎng)絡(luò)服務(wù)使用來自Adobe Systems有限公司的Flash流式傳送和實(shí)時(shí)消息傳送協(xié)議(RTMP)，從而使得甚至沒有經(jīng)驗(yàn)的用戶也可以容易地使用流式傳送并且進(jìn)一步增加了網(wǎng)絡(luò)中的OTT業(yè)務(wù)?？梢栽趆ttp: //aws.amazon, com/about-aws/whats-new/2009/12/15/announcing-clo udfront-streaming/ 處得至Ij 關(guān)于 CloudFront 月艮務(wù)的信息。在可以在 http://www.adobe, com/devnet/rtmp/pdf/rtmp_specification_l.0.pdf處得到的實(shí)時(shí)消息傳送協(xié)議塊流(2009年6月)中描述了 RTMP。大多數(shù)OTT內(nèi)容在某種意義上講是冗余的，即，在很多情況下，OTT內(nèi)容表示只是由不同的服務(wù)和提供商根據(jù)不同的通信協(xié)議所提供的相同的信息或者甚至相同的媒體。在客戶端設(shè)備上運(yùn)行的網(wǎng)絡(luò)瀏覽器通常用于通過互聯(lián)網(wǎng)來訪問服務(wù)器或主機(jī)、計(jì)算機(jī)上的信息，并且瀏覽器通常用作超文本傳輸協(xié)議(HTTP)客戶端。雖然瀏覽器是通用應(yīng)用，但是瀏覽器如今運(yùn)行在很多不同的設(shè)備和平臺(tái)上。移動(dòng)電話、上網(wǎng)本、平板電腦、膝上型計(jì)算機(jī)和個(gè)人計(jì)算機(jī)、電視機(jī)(TV)、機(jī)頂盒(STB)以及甚至廚房電器是可以具有網(wǎng)絡(luò)瀏覽器的客戶端設(shè)備或用戶設(shè)備(UE)的示例。當(dāng)前的瀏覽器通過統(tǒng)一資源定位符(URL)來識別信息資源，并且當(dāng)前的URL標(biāo)識信息的一個(gè)相應(yīng)表不，在最佳的情況下，恰好是適合于運(yùn)行瀏覽器的設(shè)備的表不。URL包含或編碼對于傳送相應(yīng)的信息而言所需的所有事物:資源、資產(chǎn)(asset)、傳輸和可能有助于對傳送進(jìn)行計(jì)費(fèi)的可能的傳送參數(shù)。URL最初是由互聯(lián)網(wǎng)工程任務(wù)組(IETF)的征求評議文件(RFC) 1738 (1994年12月)規(guī)定的，并且已經(jīng)被概括和更新為由IETF RFC3986 (2005年I月)規(guī)定的統(tǒng)一資源標(biāo)識符(URI)。URI可以是定位符、名稱或者這二者，并且URL是指URI的除了標(biāo)識資源以外還提供了通過描述其主要的訪問機(jī)制(例如，其網(wǎng)絡(luò)“位置”)來定位資源的方式的子集。任何信息資源可能由相應(yīng)的URL標(biāo)識，并且經(jīng)由根據(jù)適當(dāng)?shù)膮f(xié)議的消息傳送來訪問。用戶的客戶端軟件應(yīng)用(例如，瀏覽器)直接從用戶輸入或者從超鏈接讀取URL作為輸入?yún)?shù)，然后客戶端應(yīng)用下載由URL標(biāo)識的資源并且向用戶顯示該內(nèi)容(如果它能夠這樣做的話)。通常，可以按如下方式來描述URL的語法:〈protocol〉://〈host〉:〈port〉/〈path〉其中，〈protocol〉指示消息傳送的類型(例如，HTTP、文件傳輸協(xié)議(FTP)、實(shí)時(shí)流式傳送協(xié)議(RTSP)等)，〈host>通常是信息的互聯(lián)網(wǎng)地址，〈port〉通常是由主機(jī)使用以經(jīng)由〈protocol〉進(jìn)行通信的端口的號，〈path〉是信息的主機(jī)操作系統(tǒng)位置。RTSP是由IETFRFC2326(1998年4月)規(guī)定的。因?yàn)橹鳈C(jī)可以刪除或移除信息，因此URL可能失去其有效性，因而HTTP定義了針對無效URL的錯(cuò)誤消息的結(jié)構(gòu)。錯(cuò)誤消息可以聲明資源不再可用或者資源現(xiàn)在通過新的URL而可用。后一種錯(cuò)誤消息稱作HTTP重定向消息，并且重定向可以是靜態(tài)的或臨時(shí)的?，F(xiàn)代的客戶端應(yīng)用能夠解釋HTTP重定向消息并且使用HTTP從新的URL獲得資源。越來越多的客戶端支持改變傳輸協(xié)議的重定向消息。此外，資源標(biāo)識和重定向有時(shí)用于傳送調(diào)整的超文本標(biāo)記語言(HTML)信息(例如，網(wǎng)頁)，例如，具體地說，用于向移動(dòng)設(shè)備傳送該信肩、O當(dāng)前,存在用于將語義資產(chǎn)(semantic asset)和這些資產(chǎn)的實(shí)際表示分開的不同的方法。例如，持久URL (PURL)項(xiàng)目維護(hù)用作永久標(biāo)識符的地址的數(shù)據(jù)庫，而不論網(wǎng)絡(luò)基礎(chǔ)設(shè)施如何改變。PURL不是直接解析為網(wǎng)絡(luò)資源，而是提供一定程度的間接性，該間接性允許資源的潛在網(wǎng)絡(luò)地址(例如，URL和URI)在不會(huì)對依賴于它們的系統(tǒng)造成負(fù)面影響的情況下隨著時(shí)間而改變。這種能力提供了對可能由于商業(yè)、社會(huì)或技術(shù)原因而在機(jī)器之間遷移的網(wǎng)絡(luò)資源的參考的持續(xù)性。在http://purl.0clc.0rg/docs/index, html處可以得到關(guān)于PURL項(xiàng)目的信息。用于將語義資產(chǎn)和這些資產(chǎn)的實(shí)際表示分開的現(xiàn)有方法假設(shè)每一個(gè)表示具有可能隨著時(shí)間而改變的相應(yīng)的URL。因此，必須針對例如媒體節(jié)目(或者資產(chǎn))的每一個(gè)不同的編碼(或者表示)來定義新的URL。該一對一的需求導(dǎo)致多個(gè)問題。諸如文檔、照片、音頻文件、電影等的單個(gè)資產(chǎn)可以具有多種不同的可用格式(表示)，其中對于每一種格式而言具有不同的URL，但是典型的用戶僅對訪問資產(chǎn)本身而不是其很多可能的表示中的任意特定的表示感興趣。簡單地向用戶呈送用戶必須從其中進(jìn)行選擇的超鏈接列表導(dǎo)致運(yùn)營商和提供商失去對有價(jià)值的良好“帶寬”的控制，這是因?yàn)橛脩舨恢阑蛘卟豢紤]運(yùn)營商或提供商的需要。簡單的列表還減少了可用性，這是因?yàn)榈湫偷挠脩魧⒉涣私馑谐龅牟煌琔RL所表示的不同的格式以及傳輸機(jī)制之間的差別。此外，可以在多個(gè)位置(例如，內(nèi)容傳送網(wǎng)絡(luò)(⑶N)、流式傳送服務(wù)等)處得到相同的資產(chǎn)，但是用戶已知的URL可能不是在內(nèi)容位置、網(wǎng)絡(luò)帶寬和用戶位置方面適合的資產(chǎn)的表示。此外，可以通過諸如HTTP、FTP等的多個(gè)傳輸協(xié)議來得到相同的資產(chǎn)，但是用戶已知的URL可能不適合于用戶的設(shè)備的傳輸能力。因?yàn)閁RL直接尋址資產(chǎn)的一個(gè)相應(yīng)的表示，因此該表示是直接地或者通過一個(gè)或多個(gè)靜態(tài)的重定向被傳送到用戶的，因而沒有關(guān)于傳送上下文的額外信息可以被考慮以改善傳送。當(dāng)前的技術(shù)的靜態(tài)屬性缺乏在傳送時(shí)調(diào)整URL的參考的能力。為了基于RTSP的傳送建立，會(huì)話描述協(xié)議(SDP)和實(shí)時(shí)控制協(xié)議(RTCP)可以用于經(jīng)由會(huì)話邀請協(xié)議(SIP)消息傳送來協(xié)商傳送參數(shù)。SDP、RTCP和SIP分別是由IETFRFC3556 (2OO3 年 7 月)、RFC36O5 (2OO3 年 10 月)和 RFC326K2OO2 年 6 月)規(guī)定的。SIP是用于找出端點(diǎn)并且在端點(diǎn)之間路由控制信號的機(jī)制，并且是包括REGISTER、INVITE、ACK和BYE的簡單操作的集合。SDP是用于宣布媒體的協(xié)議。例如，如Magnus Svensson 等在 W02010/018421A1 中針對 “Extended TelevisionReminders”所描述的，由第三代合作伙伴計(jì)劃(3GPP)規(guī)定的蜂窩通信網(wǎng)絡(luò)中的互聯(lián)網(wǎng)協(xié)議多媒體子系統(tǒng)(MS)使用SIP和SDP作為其基本信令機(jī)制，并且媒體傳輸尤其基于RTSP。3GPP技術(shù)規(guī)范(TS) 24.229V7.11.0 (基于會(huì)話發(fā)起協(xié)議(SIP)和會(huì)話描述協(xié)議(SDP)的IP多媒體呼叫控制協(xié)議，階段3，版本7(2008年3月))的第5部分規(guī)定了 UE處的SIP使用，并且3GPP TS24.229的第6部分規(guī)定了 SDP使用。但是，基于RTSP的傳送對于客戶端而言不是透明的，這意味著用戶必須以復(fù)雜的不熟悉的方式來與用戶的設(shè)備進(jìn)行交互，并且不可用于基于HTTP的傳送。諸如YouTube等的提供商已經(jīng)向用戶提供了不同格式的資產(chǎn)并且自動(dòng)地選擇使用哪一個(gè)流式傳送格式，但是提供商當(dāng)前不能改變所選擇的流式傳送協(xié)議。選擇傳送哪一個(gè)流是基于服務(wù)器和客戶端上的可用信息來做出的，而不是基于與傳送網(wǎng)絡(luò)本身有關(guān)的信息做出的。因此，選擇錯(cuò)失了網(wǎng)絡(luò)運(yùn)營商傳送比特的重要方面，例如傳輸成本等?，F(xiàn)有的解決方案通常束縛于特定類型的資源，例如，電影片段。對于每一種其它資源類型，必須調(diào)整該解決方案。此外，由于大多數(shù)解決方案的專有的單客戶端/單服務(wù)器架構(gòu)，因此現(xiàn)有的解決方案不能容易地?cái)U(kuò)展為考慮更相關(guān)的信息。

發(fā)明內(nèi)容
我們引入了一種用于URL的靈活的且上下文知曉的傳送方案，該方案建立在可以用于向客戶端傳送不論哪一種二進(jìn)制內(nèi)容的通用表示上。該方案還可以被應(yīng)用以改善網(wǎng)絡(luò)運(yùn)營商的網(wǎng)絡(luò)操作、用戶的感知的體驗(yàn)質(zhì)量和不需要編碼和支持不同的編解碼器和傳輸機(jī)制的內(nèi)容提供商的成本。根據(jù)本發(fā)明的各個(gè)方面，提供了一種利用與要向電子通信網(wǎng)絡(luò)的用戶顯示的信息相對應(yīng)的語義URL的方法。該方法包括:生成信息請求消息，其中，所述信息請求消息包括語義URL和用戶設(shè)備的標(biāo)識符；向所述通信網(wǎng)絡(luò)中的URL邏輯節(jié)點(diǎn)發(fā)送所述信息請求消息；基于所述信息請求消息，收集對于傳送與所述語義URL相對應(yīng)的信息而言有關(guān)的信息；以及基于所收集的信息，確定適合于所述用戶設(shè)備的與所述語義URL相對應(yīng)的信息的表示。此外，根據(jù)本發(fā)明的各個(gè)方面，提供了一種用于利用與要向電子通信網(wǎng)絡(luò)的用戶顯示的信息相對應(yīng)的語義URL的URL邏輯節(jié)點(diǎn)。該節(jié)點(diǎn)包括:收發(fā)機(jī)，其被配置為與電子通信網(wǎng)絡(luò)的一個(gè)或多個(gè)實(shí)體交換電子信號；電子處理器，其被可編程地配置為管理由所述電子信號攜帶的信息；以及存儲(chǔ)器，其被配置為存儲(chǔ)可取回的信息。所述處理器被配置為收集對于傳送與從用戶設(shè)備接收的信息請求消息中包括的所述語義URL相對應(yīng)的信息而言有關(guān)的信息，并且基于所收集的信息來確定適合于所述用戶設(shè)備的與所述語義URL相對應(yīng)的信息的表不。


將通過結(jié)合附圖閱讀說明書來理解本發(fā)明的多個(gè)特征、目的和優(yōu)點(diǎn)，其中，類似的參考字符指示類似的部分，并且:圖1描繪了通信網(wǎng)絡(luò)、和通信網(wǎng)絡(luò)實(shí)體之間的信號以及通信網(wǎng)絡(luò)實(shí)體進(jìn)行的活動(dòng)的流程圖；圖2是用戶設(shè)備的框圖；以及
圖3是URL邏輯節(jié)點(diǎn)的框圖。
具體實(shí)施例方式如下面更詳細(xì)描述的，發(fā)明人已經(jīng)認(rèn)識到URL不需要暗示URL與信息資源之間的一對一的關(guān)系，但是可以定義語義項(xiàng)(例如，電影、新聞項(xiàng)等)。用戶僅需要使用這樣的語義URL,即，這些語義URL中的每一個(gè)是語義URL與語義項(xiàng)的表示的URL之間的一對多的映射。跟蹤語義URL的系統(tǒng)邏輯針對每一個(gè)請求，基于由系統(tǒng)動(dòng)態(tài)地從統(tǒng)計(jì)資源和靜態(tài)資源收集的上下文信息來決定傳送哪一個(gè)表不。本領(lǐng)域技術(shù)人員將理解到，語義URL和表示URL可以被認(rèn)為是傳統(tǒng)的URL，其中一對多映射作為重定向而向客戶端側(cè)暴露。這是有利的，其原因在于它實(shí)現(xiàn)了在客戶端側(cè)對現(xiàn)有技術(shù)的重新使用，并且使本發(fā)明的新技術(shù)對于用戶設(shè)備(UE)而言是透明的。下面在URL邏輯管理的用戶請求的示例的上下文中描述本發(fā)明，并且可以如下面所描述的來概括該示例。圖1描繪了根據(jù)本發(fā)明的方法中的通信網(wǎng)絡(luò)100中的實(shí)體之間的典型的信號流。將理解到，在IP網(wǎng)絡(luò)的上下文中采用適合于IP網(wǎng)絡(luò)的消息描繪了這些方法，但是通?？梢允褂闷渌舷挛暮推渌愋偷南?。用戶使用諸如移動(dòng)電話等的UEllO來訪問網(wǎng)頁，其中，該UEllO運(yùn)行諸如網(wǎng)絡(luò)瀏覽器等的客戶端應(yīng)用。網(wǎng)頁向用戶提供針對諸如媒體項(xiàng)等的信息資產(chǎn)的超鏈接，并且超鏈接包含或參考語義URL，該語義URL指向URL邏輯節(jié)點(diǎn)(URLLN) 120。將理解到，現(xiàn)有的網(wǎng)站上的超鏈接可被修改為包含適合的語義URL。這種修改被預(yù)計(jì)為針對靜態(tài)網(wǎng)站是容易完成的，其中，靜態(tài)網(wǎng)站通常在相應(yīng)的數(shù)據(jù)庫中存儲(chǔ)超鏈接或者通過簡單地更新超鏈接數(shù)據(jù)庫或發(fā)生器來自動(dòng)地生成超鏈接。如圖1所示，點(diǎn)擊超鏈接導(dǎo)致UE110上的客戶端軟件向URLLN120發(fā)送針對語義項(xiàng)的HTTP GET請求消息(步驟I)。HTTP GET請求包含關(guān)于與語義URL相對應(yīng)的資產(chǎn)和進(jìn)行請求的UE的信息。響應(yīng)于HTTP GET請求消息，URLLNl20收集對于用戶請求觸發(fā)的傳送過程而言有關(guān)的信息。如圖1所示，收集信息包括下面描述的步驟2-12中的各種步驟，這取決于所請求的資產(chǎn)的類型。例如，當(dāng)前認(rèn)為如果請求單純的資產(chǎn)傳送，則與靜態(tài)重定向基本相對應(yīng)的步驟4、5、10、11和12是足夠的。如果請求適合于特定設(shè)備的資產(chǎn)傳送，則添加步驟2、3、8和9。如果請求具有傳送路徑優(yōu)化的適合于特定設(shè)備的資產(chǎn)傳送，則還添加步驟6和7，其中，步驟6和7提供關(guān)于網(wǎng)絡(luò)的信息(例如，通信鏈路利用率、傳送路徑上的節(jié)點(diǎn)的處理功率等)。在步驟2，URLLNl20針對與進(jìn)行請求的UE有關(guān)的信息來查詢設(shè)備能力數(shù)據(jù)庫DevCapDB130ο如同針對UEllO的標(biāo)識符一樣，URLLN120可以根據(jù)HTTP GET請求向數(shù)據(jù)庫130提供用戶代理字符串。在步驟3，設(shè)備能力數(shù)據(jù)庫130向URLLN120提供關(guān)于UEllO支持的視頻和音頻代碼、比特速率和分辨率的信息。為了找到所請求的語義項(xiàng)的適合的表示，URLLN130查詢元數(shù)據(jù)數(shù)據(jù)庫MetaDB140 (步驟4),該MetaDB140包含關(guān)于語義項(xiàng)的可用表示的元信息。關(guān)于表示的元信息可以包括但不限于以下各項(xiàng)中的一項(xiàng)或多項(xiàng):表示的媒體語言、分辨率、編解碼器、位置和URL。在步驟5，元數(shù)據(jù)數(shù)據(jù)庫140向URLLN120提供其存儲(chǔ)的關(guān)于所請求的語義項(xiàng)的元信息。在圖1中描繪的布置中，URLLN120還可以通過使URLLN針對網(wǎng)絡(luò)信息(例如，去往UE的通信鏈路上的鏈路質(zhì)量和可用吞吐量)查詢網(wǎng)絡(luò)監(jiān)控節(jié)點(diǎn)NetMonl50來考慮關(guān)于當(dāng)前的網(wǎng)絡(luò)狀態(tài)的信息(步驟6)。響應(yīng)于URLLN的查詢，網(wǎng)絡(luò)監(jiān)控節(jié)點(diǎn)150向URLLN120提供該信息(步驟7)。關(guān)于鏈路質(zhì)量和吞吐量的信息以及其它網(wǎng)絡(luò)信息可以用于避免擁塞的鏈路，并且因此提供更好的端對端鏈路質(zhì)量，以及用于基于關(guān)于要發(fā)送的數(shù)據(jù)的已知信息來更高效地使用鏈路。包括例如抖動(dòng)和分組延遲的鏈路質(zhì)量對于媒體流式傳送而言是特別重要的參數(shù)。例如，當(dāng)通信鏈路幾乎擁塞(即，在接近其最大吞吐量處操作)時(shí)，在鏈路上提供高清(HD)電影將必然使鏈路完全擁塞，但是提供較低分辨率的電影(例如，適合于手持設(shè)備的小屏幕的電影)可以非常適合剩余的鏈路容量。NetMon節(jié)點(diǎn)150是從整個(gè)網(wǎng)絡(luò)中的不同節(jié)點(diǎn)獲取不同的信息(例如，不同的對等點(diǎn)上的對等業(yè)務(wù)的量)的網(wǎng)絡(luò)節(jié)點(diǎn)。在諸如根據(jù)第三代合作伙伴計(jì)劃的標(biāo)準(zhǔn)的長期演進(jìn)網(wǎng)絡(luò)等的典型的無線網(wǎng)絡(luò)中，當(dāng)前認(rèn)為NetMon節(jié)點(diǎn)150是最好實(shí)現(xiàn)在核心網(wǎng)絡(luò)節(jié)點(diǎn)中的或者與核心網(wǎng)絡(luò)節(jié)點(diǎn)相關(guān)聯(lián)的監(jiān)控節(jié)點(diǎn)，而不是實(shí)現(xiàn)在無線接入網(wǎng)絡(luò)中的監(jiān)控節(jié)點(diǎn)?；趤碜詳?shù)據(jù)庫130、140和節(jié)點(diǎn)150的信息，URLLN120確定適合于UEllO并且適合于優(yōu)化其它方面(例如，針對提供商和網(wǎng)絡(luò)運(yùn)營商的傳送成本)的所請求的語義項(xiàng)的表示(步驟8)。該確定可以由被實(shí)現(xiàn)為URLLN120中的硬件和軟件中的任意一個(gè)或者這二者的決策邏輯做出，其中，該決策邏輯結(jié)合用于確定適合的編解碼器(具體地說，由UEllO支持的編解碼器)的決策樹來評估預(yù)定的成本函數(shù)。所確定的表示可以包括所請求的資產(chǎn)的多于一個(gè)的表示，例如，視頻流和具有適合的語言的字幕流。適合的成本函數(shù)的示例是下式:Cost = A.Codec—Cost+B.Resolution—Cost其中，Cost是要確定的值；A和B是可選擇的權(quán)重；Codec_Cost是基于感知的編解碼器“質(zhì)量”主觀指派的值、或者是基于表示的比特速率、幀速率等客觀計(jì)算出的值；ResolutioruCost是所預(yù)計(jì)的主觀質(zhì)量的客觀測量值。網(wǎng)絡(luò)運(yùn)營商可以基于諸如網(wǎng)絡(luò)狀態(tài)、UE訂購等的多個(gè)因素通過選擇權(quán)重來調(diào)整Cost值。具體地說，權(quán)重可以根據(jù)去往UEllO的通信鏈路的當(dāng)前狀態(tài)而改變。例如，選擇使得傳送到UE的表示被高度壓縮的權(quán)重節(jié)省了網(wǎng)絡(luò)帶寬或吞吐量，同時(shí)其降低了用戶體驗(yàn)的質(zhì)量。Resolution_Cost參數(shù)的不例是下式:Resolution_Cost = 0.5.(resX_a-resX_b)/(resX_a+resX_b) +0.5.Distance—Aspect其中，resX_a是源表示的分辨率；resX_b是將在其上呈現(xiàn)表示的顯示器的分辨率；如果 aspect_ratio_b = aspect_ratio_a,則 Distance_Aspect = O,否則，Distance—Aspect = I。分辨率resX_a的公共值當(dāng)前是1920X1080個(gè)像素、1280X720個(gè)像素和720X480個(gè)像素，而分辨率resX_b的公共值當(dāng)前是960X640個(gè)像素、640 X 360個(gè)像素和480X320個(gè)像素，但是將清楚的是，可以使用任何適當(dāng)?shù)闹?。公共寬高比值?dāng)前是16: 10、16: 9和4: 3。在步驟9，URLLNl20將所確定的表示的URL封裝在HTTP重定向消息中，并且響應(yīng)于UE的HTTP GET消息，包含所確定的表示的URL的重定向消息被發(fā)送到UE110 (步驟10)。然后，UE的客戶端向源160請求由URLLN120確定的語義項(xiàng)的表示(步驟11)，并且響應(yīng)于其請求，UEllO根據(jù)SIP OK過程從源160接收信息資產(chǎn)的所確定的表示(步驟12)。本領(lǐng)域技術(shù)人員將理解的是，在圖1中所示的示例中使用的傳輸協(xié)議是HTTP，但是該協(xié)議并不總是必需的。通常，支持如所描繪的重定向消息的任何傳輸協(xié)議是可能的，例如，RTSP。此外，由URLLN120發(fā)送的重定向消息(步驟10)可能導(dǎo)致協(xié)議之間的改變(例如，從HTTP改變?yōu)镽TSP)，這對于諸如移動(dòng)電話等的可能具有有限的功率和處理能力的UE而言可能是有利的。此外，將理解的是，網(wǎng)絡(luò)節(jié)點(diǎn)110、120、130、140、150、160使用一個(gè)或多個(gè)適當(dāng)編程的電子數(shù)字信號處理器或者等同物以及管理網(wǎng)絡(luò)100中的UE和其它實(shí)體交換的信號所攜帶的信息的存儲(chǔ)器來執(zhí)行本申請中描述的功能。還將理解的是，表示的URL不需要指向諸如源160等的所請求的資產(chǎn)的實(shí)際位置，而是可以指向完全不同的位置并且再次重定向至那里而被管理。這種布置的示例是指向⑶N的表示URL，其自身將UE重定向至與UE最近的位置。URLLNl20還可以從UE自身獲取關(guān)于傳送上下文的信息(步驟6、7)。當(dāng)前，SDP可以用于協(xié)商設(shè)備特定的傳送參數(shù)，但是正在開發(fā)用于在設(shè)備自身上暴露設(shè)備能力的方法。例如，傳送上下文客戶端接口(DCCI)是萬維網(wǎng)聯(lián)盟(W3C)進(jìn)行的項(xiàng)目，該項(xiàng)目是W3C的傳送上下文本體(DCO)項(xiàng)目的子項(xiàng)目。本領(lǐng)域技術(shù)人員將理解到，在本申請中描述的方法和裝置可以實(shí)現(xiàn)在諸如移動(dòng)無線網(wǎng)絡(luò)等的很多類型的電子通信網(wǎng)絡(luò)中。圖2是用于如本申請所描述的訪問內(nèi)容的諸如移動(dòng)電話、STB、計(jì)算機(jī)等的典型的UEllO的框圖。UEllO包括收發(fā)機(jī)202，該收發(fā)機(jī)202適合于與圖1中描繪的網(wǎng)絡(luò)實(shí)體中的一個(gè)或多個(gè)交換電子信號。這些信號攜帶的信息是由處理器204管理的，該處理器204可以包括一個(gè)或多個(gè)子處理器，并且執(zhí)行包括例如網(wǎng)絡(luò)瀏覽器的一個(gè)或多個(gè)軟件模塊和應(yīng)用，以執(zhí)行上文所描述的UEllO的操作。通過鍵盤、遠(yuǎn)程控制或其它設(shè)備206來向UEllO提供用戶輸入，并且呈送給用戶的信息被提供給顯示器208。如果顯示器具有觸摸屏能力，則可以通過該顯示器來提供用戶輸入?？梢栽谶m當(dāng)?shù)膽?yīng)用存儲(chǔ)器210中存儲(chǔ)軟件應(yīng)用，并且UE還可以下載期望的信息和/或在適當(dāng)?shù)拇鎯?chǔ)器212中緩存期望的信息。UEllO還可以包括接口 214，接口 214可以用于將諸如計(jì)算機(jī)、麥克風(fēng)等的其它組件連接到UE110。用戶經(jīng)由鍵盤206或接口 214請求語義項(xiàng)，并且使用存儲(chǔ)器210、212中的信息來使得處理器204生成適當(dāng)?shù)腍TTP GET請求消息(步驟1、10)并且經(jīng)由收發(fā)機(jī)202將該消息發(fā)送給URLLN120。收發(fā)機(jī)202和處理器204還執(zhí)行SIP消息傳送以進(jìn)行內(nèi)容傳送(步驟12)，并且處理器214然后可以經(jīng)由顯示器208向用戶呈送內(nèi)容。圖3是用于如本申請中所描述的收集對于由用戶請求觸發(fā)的傳送過程而言有關(guān)的信息并且對用戶請求做出響應(yīng)的典型的URLLN120的框圖。URLLN120包括收發(fā)機(jī)302，收發(fā)機(jī)302適合于與圖1中描繪的網(wǎng)絡(luò)實(shí)體中的一個(gè)或多個(gè)交換電子信號。這些信號攜帶的信息是由處理器304管理的，處理器304可以包括一個(gè)或多個(gè)子處理器，并且執(zhí)行一個(gè)或多個(gè)軟件模塊和應(yīng)用，以執(zhí)行上文所描述的URLLN120的操作。具體地說，處理器304執(zhí)行對于查詢和接收來自數(shù)據(jù)庫130、140和節(jié)點(diǎn)150的信息以及確定適合于UEllO的所請求的語義項(xiàng)的表示而言所需的消息傳送，并且執(zhí)行對于以信號形式將所確定的表示傳送給UE而言所需的消息傳送。處理器304可以使用存儲(chǔ)在適當(dāng)?shù)拇鎯?chǔ)器306中的信息和可以存儲(chǔ)在適當(dāng)?shù)膽?yīng)用存儲(chǔ)器308中的軟件應(yīng)用來執(zhí)行這些操作。將理解的是，典型的URLLN120是網(wǎng)絡(luò)100中的服務(wù)器，因此對于用戶輸入/輸出而言，通常不需要鍵盤/顯示器310，但是這些接口可以被提供以用于管理功能。本發(fā)明通過使用URL的不同協(xié)議增加了對互聯(lián)網(wǎng)上的媒體傳送的控制。根據(jù)本發(fā)明，在客戶端側(cè)上使用現(xiàn)有的協(xié)議和技術(shù)，因此實(shí)現(xiàn)對于UE而言可以是完全透明的。網(wǎng)絡(luò)運(yùn)營商可以提供更智能的傳送路徑，并且因此減少了網(wǎng)絡(luò)中的鏈路上的業(yè)務(wù)并且通過將UE重定向至外部流式服務(wù)而節(jié)約了流式傳送能力和其它能力。此外，運(yùn)營商可以通過以最適合于客戶端的方式傳送內(nèi)容來向內(nèi)容提供商提供增值。從其在內(nèi)容傳送路徑中的位置開始，運(yùn)營商還可以為其自身以及為第三方提供額外的服務(wù)，例如，計(jì)費(fèi)和數(shù)字版權(quán)管理(DRM)。對于用戶而言有利的是他們可以將注意力集中于所請求的信息并且避免處理多個(gè)表示、格式、協(xié)議和指向相同信息的超鏈接。將清楚的是，例如如果必要的話，上文所描述的過程被重復(fù)地執(zhí)行，以對發(fā)射機(jī)和接收機(jī)交換的通信信號的時(shí)變屬性做出響應(yīng)。執(zhí)行本發(fā)明的裝配可以包括在例如計(jì)算機(jī)、服務(wù)器、無線通信網(wǎng)絡(luò)基站等中。因此，本發(fā)明可以以多種不同的形式體現(xiàn)，上文并未描述所有這些形式，并且所有這些形式被設(shè)想為落入本發(fā)明的范圍內(nèi)。應(yīng)當(dāng)強(qiáng)調(diào)的是，當(dāng)在本申請中使用時(shí)，術(shù)語“包括”和“包含”規(guī)定存在聲明的特征、整數(shù)、步驟或組件，而不排除存在或添加一個(gè)或多個(gè)其它特征、整數(shù)、步驟、組件或其組合。上文所描述的特定實(shí)施方式僅僅是說明性的而不應(yīng)當(dāng)以任意方式理解為是限制性的。本發(fā)明的范圍是由所附權(quán)利要求來確定的，并且落入權(quán)利要求的范圍內(nèi)的所有變形和等價(jià)物旨在包含在其中。
權(quán)利要求
1.一種利用與要向電子通信網(wǎng)絡(luò)(100)的用戶顯示的信息相對應(yīng)的語義統(tǒng)一資源定位符(URL)的方法，包括: (a)生成信息請求消息，其中，所述信息請求消息包括語義URL和用戶設(shè)備(110)的標(biāo)識符； (b)向所述通信網(wǎng)絡(luò)中的URL邏輯節(jié)點(diǎn)(120)發(fā)送所述信息請求消息； (c)基于所述信息請求消息，收集對于傳送與所述語義URL相對應(yīng)的信息而言有關(guān)的/[目息;以及 (d)基于所收集的信息，確定適合于所述用戶設(shè)備的與所述語義URL相對應(yīng)的信息的表不。
2.根據(jù)權(quán)利要求1所述的方法，其中，收集信息包括以下步驟中的至少一個(gè):針對與所述用戶設(shè)備相對應(yīng)的信息來查詢設(shè)備能力數(shù)據(jù)庫，針對關(guān)于與所述語義URL相對應(yīng)的所述信息的可用表示的信息來查詢元數(shù)據(jù)數(shù)據(jù)庫，以及針對關(guān)于去往所述用戶設(shè)備的通信鏈路上的吞吐量的信息來查詢網(wǎng)絡(luò)監(jiān)控節(jié)點(diǎn)(150)。
3.根據(jù)權(quán)利要求1所述的方法，還包括: 向所述用戶設(shè)備發(fā)送標(biāo)識所確定的表示以及用于訪問所確定的表示的通信協(xié)議的重定向消息。
4.根據(jù)權(quán)利要求3所述的方法，其中，所述信息請求消息的通信協(xié)議不同于在所述重定向消息中標(biāo)識的所述通信協(xié)議。
5.根據(jù)權(quán)利要求1所述的方法，其中，確定所述表示包括:評估預(yù)定的成本函數(shù)。
6.根據(jù)權(quán)利要求5所述的方法，其中，所述預(yù)定的成本函數(shù)由下式給出:`Cost = A.Codec—Cost+B.Resolution_Cost 其中,Cost是要確定的值汸和B是可選擇的權(quán)重；Codec_Cost是基于所述用戶設(shè)備中的編解碼器的值、或者是基于所述表示的比特速率和幀速率中的至少一個(gè)所計(jì)算出的值；并且Resolution_Cost值是針對所述表示所預(yù)計(jì)的主觀質(zhì)量的測量值。
7.根據(jù)權(quán)利要求6所述的方法,其中，所述Resolution_Cost值由下式給出:Resolution_Cost = 0.5.| (resX_a_resX_b)/(resX_a+resX_b) 1+0.5.Distance—Aspect其中，resX_a是源表示的分辨率；resX_b是所述用戶設(shè)備的顯示器的分辨率；如果所述源表示的寬高比與所述用戶設(shè)備的所述顯示器的寬高比基本上相同，則Distance_Aspect = O,否則，Distance_Aspect = I。
8.一種用于利用與要向電子通信網(wǎng)絡(luò)(100)的用戶顯示的信息相對應(yīng)的語義統(tǒng)一資源定位符(URL)的統(tǒng)一資源定位符邏輯節(jié)點(diǎn)(120)，包括: 收發(fā)機(jī)(302)，其被配置為與所述電子通信網(wǎng)絡(luò)(100)的一個(gè)或多個(gè)實(shí)體(110 ；130 ；140 ；150)交換電子信號； 電子處理器(304)，其被可編程地配置為管理由所述電子信號攜帶的信息；以及 存儲(chǔ)器(306 ;308)，其被配置為存儲(chǔ)可取回的信息； 其中，所述處理器被配置為收集對于傳送與從用戶設(shè)備(110)接收的信息請求消息中包括的所述語義URL相對應(yīng)的信息而言有關(guān)的信息，并且基于所收集的信息來確定適合于所述用戶設(shè)備的與所述語義URL相對應(yīng)的信息的表示。
9.根據(jù)權(quán)利要求8所述的節(jié)點(diǎn)，其中，所述處理器被配置為通過以下步驟中的至少一個(gè)來收集信息:針對與所述用戶設(shè)備相對應(yīng)的信息來查詢設(shè)備能力數(shù)據(jù)庫，針對關(guān)于與所述語義URL相對應(yīng)的所述信息的可用表示的信息來查詢元數(shù)據(jù)數(shù)據(jù)庫，以及針對關(guān)于去往所述用戶設(shè)備的通信鏈路上的吞吐量的信息來查詢網(wǎng)絡(luò)監(jiān)控節(jié)點(diǎn)(150)。
10.根據(jù)權(quán)利要求8所述的節(jié)點(diǎn)，其中，所述處理器被進(jìn)一步配置為使得所述節(jié)點(diǎn)向所述用戶設(shè)備發(fā)送重定向消息，所述重定向消息標(biāo)識所確定的表示和用于訪問所確定的表示的通信協(xié)議。
11.根據(jù)權(quán)利要求10所述的節(jié)點(diǎn)，其中，所述信息請求消息的通信協(xié)議不同于在所述重定向消息中標(biāo)識的所述通信協(xié)議。
12.根據(jù)權(quán)利要求8所述的節(jié)點(diǎn)，其中，所述處理器被配置為通過評估預(yù)定的成本函數(shù)來確定所述表示。
13.根據(jù)權(quán)利要求12所述的節(jié)點(diǎn)，其中，所述預(yù)定的成本函數(shù)由下式給出:Cost = A.Codec—Cost+B.Resolution_Cost 其中,Cost是要確定的值汸和B是可選擇的權(quán)重；Codec_Cost是基于所述用戶設(shè)備中的編解碼器的值、或者是基于所述表示的比特速率和幀速率中的至少一個(gè)所計(jì)算出的值；并且Resolution_Cost值是針對所述表示所預(yù)計(jì)的主觀質(zhì)量的測量值。
14.根據(jù)權(quán)利要求13所述的節(jié)點(diǎn),其中，所述Resolution_Cost值由下式給出: Resolution_Cost = 0.5.(resX_a_resX_b)/ (resX_a+resX_b) +0.5.Distance—Aspect其中，r esX_a是源表示的分辨率；resX_b是所述用戶設(shè)備的顯示器的分辨率；如果所述源表示的寬高比與所述用戶設(shè)備的所述顯示器的寬高比基本上相同，則Distance_Aspect = O,否則，Distance_Aspect = I。
全文摘要
一種用于統(tǒng)一資源定位符的靈活的且上下文知曉的傳送方案建立在可以用于向客戶端傳送不論哪一個(gè)二進(jìn)制內(nèi)容的通用表示上。該方案還可以被應(yīng)用以改善網(wǎng)絡(luò)運(yùn)營商的網(wǎng)絡(luò)操作、用戶的感知的體驗(yàn)質(zhì)量以及不需要編碼和支持不同的編解碼器和傳輸機(jī)制的內(nèi)容提供商的成本。
文檔編號H04L29/08GK103201734SQ201080070010
公開日2013年7月10日 申請日期2010年11月9日 優(yōu)先權(quán)日2010年11月9日
發(fā)明者彼得·沃恩德爾, 伊格納西奧·瑪斯伊瓦爾斯 申請人:瑞典愛立信有限公司