專利名稱：代理功能性的制作方法
技術(shù)領(lǐng)域：
本發(fā)明涉及用于IPTV機頂盒從IPTV服務(wù)提供商的域之外的外部域訪問內(nèi)容的方 法和設(shè)備。
背景技術(shù)：
IPTV鋪展已正在發(fā)生，并將將隨著高速接入技術(shù)繼續(xù)部署而增長。同時諸如 Joost和BBC的iPlayer等內(nèi)容聚合器(content aggregator)正成為合法在線內(nèi)容的確立 源。寬帶的滲透帶來的增加帶寬和增強的終端能力、內(nèi)容創(chuàng)建和發(fā)布工具的可用性 極大地增大了用戶生成的內(nèi)容在因特網(wǎng)上的可用性，例如樸111\11^、Podcasting等。諸如 Joost, BBC iPlayer等內(nèi)容聚合器也正變?yōu)楹戏ㄔ诰€內(nèi)容的確立源。對等技術(shù)已顯示自己是用于分發(fā)用戶生成的內(nèi)容和選擇內(nèi)容聚合器的技術(shù)的一 項可行技術(shù)。例如，iPlayer利用IMP P2P客戶端。經(jīng)常簡稱為對等或縮寫為P2P的對等 架構(gòu)是一種網(wǎng)絡(luò)類型，其中每個工作站具有相等的能力和責任。這不同于一些計算機專用 于服務(wù)其它計算機的客戶端/服務(wù)器架構(gòu)。P2P網(wǎng)絡(luò)在網(wǎng)絡(luò)中連接的對等體之間分發(fā)計算 功率，并利用例如網(wǎng)絡(luò)可用帶寬的聚合資源來用于高效的內(nèi)容分發(fā)。P2P經(jīng)常用作描述一 個用戶與另一用戶鏈接以通過使用下載材料(例如軟件升級件或媒體文件)的共同P2P客 戶端來傳輸信息和文件的術(shù)語。然而，這只是一種類型的P2P連網(wǎng)。通常，P2P網(wǎng)絡(luò)用于共 享文件，但P2P網(wǎng)絡(luò)也能表示網(wǎng)格計算或即時消息傳遞。一旦P2P客戶端被下載并安裝在 例如PC中，并且如果連接到因特網(wǎng)，則啟動該實用程序并連接到中央索引服務(wù)器便可能實 現(xiàn)。此中央服務(wù)器將為當前在線連接到服務(wù)器的所有用戶編排索引。此服務(wù)器不為下載主 管任何文件。P2P客戶端將包含一個區(qū)域，在該區(qū)域中能夠搜索特定文件。實用程序查詢 索引服務(wù)器以發(fā)現(xiàn)具有您正在查找的文件的其它連接用戶。在找到匹配項時，中央服務(wù)器 將通知客戶端在何處找到請求的文件。隨后，您能夠從搜索查詢來選擇結(jié)果，并且您的實用 程序隨后將嘗試與主管您請求的文件的對等體建立連接。如果連接成功，則您將開始下載 文件。P2P客戶端的第二種模型以相同的方式工作，但沒有中央索引服務(wù)器。在此情形中， P2P軟件只搜索使用相同程序的其它因特網(wǎng)用戶，并通知它們您的在線存在，從而在更多的 用戶安裝和使用該軟件時構(gòu)建計算機的大網(wǎng)絡(luò)。IPTV規(guī)范(例如，OpenIPTV論壇)定義用于將多種多媒體和交互服務(wù)供應(yīng)到基于 零售的消費者設(shè)備的架構(gòu)。兩個主要服務(wù)能夠被區(qū)分廣播內(nèi)容服務(wù)(也稱為，常規(guī)TV)和 按需內(nèi)容服務(wù)(也稱為，視頻點播)。常用的協(xié)議包括用于VoD的RTSP和用于實況流傳送 (live streaming)的RTP/IGMP。今天大部分IPTV運營商依賴輸送視頻內(nèi)容到已資助給客 戶的機頂盒。通常，這捆綁有服務(wù)預(yù)訂。目的是能夠到達大量的客戶(例如，至2007年第 1季度0!1)，Telia IPTV具有超過37萬9000的預(yù)訂)，因此，存在STB向消費者的大規(guī)模 鋪展。因而，對運營商而言，保持使用已經(jīng)部署的STB至關(guān)重要，因為考慮到大規(guī)模部署，更 換這些裝置的成本能夠是相當高的。
如已經(jīng)提及的，P2P技術(shù)廣泛用于文件共享、視頻流傳送、視頻和內(nèi)容下載。P2P技 術(shù)已顯示自己是用于分發(fā)用戶生成的內(nèi)容和選擇許多內(nèi)容聚合器的技術(shù)的一項可行技術(shù)。 然而，當前IPTV STB部署不能利用新的分發(fā)方法。IPTV STB具有有限的能力有限的執(zhí)行 環(huán)境能力，即，不能成本低地添加諸如P2P客戶端等新應(yīng)用。STB也可能具有有限的或沒有 存儲能力或有限的處理能力。過量的基于因特網(wǎng)的內(nèi)容當前不可供ITPV STB訪問。一些 服務(wù)提供商(例如，Telia的IPTV供應(yīng))允許使用IPTV STB進行Web瀏覽，但由于格式不 兼容性和只是因為STB中沒有執(zhí)行內(nèi)容下載的正確客戶端應(yīng)用，這并不使得用戶能夠訪問 基于因特網(wǎng)的純內(nèi)容。

發(fā)明內(nèi)容
本發(fā)明涉及由機頂盒訪問IPTV服務(wù)提供商的域外內(nèi)容的有限能力所造成的問題。這些問題和其它問題由本發(fā)明通過用于IPTV機頂盒從IPTV服務(wù)提供商的內(nèi)容域 之外訪問內(nèi)容的方法和設(shè)備而得以解決。本發(fā)明指定一種能夠由IPTV機頂盒訪問并且能 從IPTV服務(wù)提供商的內(nèi)容域外訪問內(nèi)容的網(wǎng)絡(luò)節(jié)點。本申請?zhí)貏e指定但不限于一種用于 P2P內(nèi)容域和Wfeb內(nèi)容域中的可用內(nèi)容可經(jīng)IPTV STB訪問的方式。更詳細地說，所述方法包括從外部域檢索要求內(nèi)容和將其轉(zhuǎn)換成經(jīng)IPTV機頂盒 可訪問的格式。由此引入代理功能性，該功能性能夠從IPTV服務(wù)提供商的內(nèi)容域外取得內(nèi) 容、轉(zhuǎn)換內(nèi)容并使用例如多播-IGMP和單播-RTSP等指定的傳輸協(xié)議和STB支持的媒體格 式將視頻內(nèi)容發(fā)送到IPTV STB。本發(fā)明的一個目的是定義IPTV獲取系統(tǒng)，由此當前部署的IPTVSTB能夠有能力從 除服務(wù)提供商的供應(yīng)外的新興媒體內(nèi)容分發(fā)網(wǎng)絡(luò)訪問內(nèi)容。此目的和其它目的通過方法、 設(shè)備、節(jié)點、系統(tǒng)及制造的物品來實現(xiàn)。本發(fā)明有關(guān)的一些優(yōu)點是服務(wù)提供商能夠提供更佳的服務(wù)，并且最終用戶能夠使 用現(xiàn)有STB欣賞范圍更廣的各種內(nèi)容。這延長了現(xiàn)有STB的使用壽命，推遲或可能消除了 新的高端STB備選的投資成本?，F(xiàn)在將連同附圖，借助于優(yōu)選實施例更詳細地描述本發(fā)明。


圖1公開包括例如P2P代理的網(wǎng)絡(luò)節(jié)點的系統(tǒng)的示意框圖，該網(wǎng)絡(luò)節(jié)點能夠訪問 運營商網(wǎng)絡(luò)和因特網(wǎng)網(wǎng)絡(luò)。圖2更詳細地公開P2P代理的示意框圖。圖3公開表示用于STB從因特網(wǎng)域取得要求的內(nèi)容的方法的信號序列圖。圖4公開包括例如MCDN代理的網(wǎng)絡(luò)節(jié)點的系統(tǒng)的示意框圖，該網(wǎng)絡(luò)節(jié)點能夠訪問 運營商網(wǎng)絡(luò)和因特網(wǎng)網(wǎng)絡(luò)中不同的MCDN。圖5公開MCDN代理的示意框圖。圖6公開示出本發(fā)明一些基本方法步驟的流程圖。
具體實施例方式圖1公開根據(jù)本發(fā)明的第一實施例的包括運營商的寬帶網(wǎng)絡(luò)2和因特網(wǎng)網(wǎng)絡(luò)3的 內(nèi)容分發(fā)系統(tǒng)。運營商網(wǎng)絡(luò)2由兩個邏輯部分組成保證部分，IPTV多播業(yè)務(wù)通過其輸送 到STB ；以及無QoS的盡力而為部分，其通常攜帶預(yù)期業(yè)務(wù)。IPTV機頂盒4能夠在運營商的 管理域內(nèi)看到。在此示例中，為IPTV STB做了一組假設(shè)-無存儲當前IPTV服務(wù)提供商以資助費率向用戶提供STB。運營商對這些裝置提 出的主要要求之一是它們盡可能地便宜，因此存儲裝置通常從此類裝置缺少以保持成本低。-無P2P應(yīng)用或額外視頻播放器由于成本問題，裝置上的軟件通常是最少的。此 外，軟件通常是為STB定制的。P2P應(yīng)用和視頻播放器兩者的一個共同特征是其不斷變化的 特征集合。這因而意味著如果STB中能夠?qū)崿F(xiàn)此的應(yīng)用過時，則能夠訪問P2P或web內(nèi)容 將變得極為困難。-一個有關(guān)遺留STB的假設(shè)是對單播和多播協(xié)議的支持。單播RTSP和HTTP。多 播IGMP和可選的FLUTE。因特網(wǎng)網(wǎng)絡(luò)包括大量的服務(wù)器。在圖1中，能夠見到第一 PC P2P客戶端5、附連 到緩沖器7的第二 PC P2P客戶端6及能夠獲取例如視頻內(nèi)容到其中的實況內(nèi)容獲取點8。 服務(wù)器5、6和8在此示例中相互為P2P關(guān)系，意味著它們以P2P方式交換內(nèi)容。圖2中公 開了一種網(wǎng)絡(luò)節(jié)點。網(wǎng)絡(luò)節(jié)點在此示例是P2P代理1，能夠訪問因特網(wǎng)網(wǎng)絡(luò)側(cè)和運營商網(wǎng)絡(luò) 側(cè)。根據(jù)本發(fā)明，代理功能性能夠通過使用傳輸協(xié)議(例如，多播-IGMP和單播-RTSP)和 STB支持的媒體格式，轉(zhuǎn)換和發(fā)送從因特網(wǎng)(從P2P)域取得的視頻內(nèi)容。這將在下面的實 施例中進一步解釋。圖2更詳細地公開對等P2P代理1。該代理具有到開放因特網(wǎng)網(wǎng)絡(luò)(在此示例中 到因特網(wǎng)的P2P網(wǎng)絡(luò)部分)的接口。代理1還具有到運營商網(wǎng)絡(luò)、到STB 4的接口。代理 1是服務(wù)運營商維護的服務(wù)器。代理1包括P2P模塊10。基本上，將有多個此模塊，因為每 個模塊將對應(yīng)于現(xiàn)有網(wǎng)絡(luò)。這將在后面與第二實施例一起的描述中進一步舉例說明。P2P 模塊包括幾個視頻隊列11和代理表12，所述隊列即在運行時間期間在P2P模塊的存儲器 中創(chuàng)建的數(shù)據(jù)結(jié)構(gòu)實例。已從P2P網(wǎng)絡(luò)取得的內(nèi)容段將放置在視頻隊列11中，并且代理 表12將用于確定將使用哪種分發(fā)方法(多播或單播)通過受管理網(wǎng)絡(luò)將內(nèi)容輸送到端終 端，即，到機頂盒。P2P模塊附連到流傳送模塊13，該流傳送模塊能夠通過P2P在多播與單 播協(xié)議之間進行轉(zhuǎn)化。流傳送模塊包括互工作模塊14?；スぷ髂K將接收來自STB的用 戶的取請求(這將與圖3 —起進一步描述)。取請求將在互工作模塊中映射到P2P請求。 互工作模塊隨后執(zhí)行向外到P2P網(wǎng)絡(luò)的請求。流傳送模塊還包括轉(zhuǎn)碼器15，轉(zhuǎn)碼器能夠進 行接收內(nèi)容的轉(zhuǎn)碼，將內(nèi)容更改為適合機頂盒4使用的格式。流傳送模塊13具有兩個分派 (casting)模塊單播模塊16和多播模塊17。根據(jù)機頂盒如何請求內(nèi)容，如果它是RTSP請 求，則流傳送模塊將單播內(nèi)容到STB，并且如果STB進行對于多播的IGMP加入，則流傳送模 塊將多播內(nèi)容到機頂盒。代理1在此示例中還包括電子內(nèi)容指南ECG門戶18。電子內(nèi)容 指南ECG是STB用于允許用戶瀏覽和訪問傳統(tǒng)與新P2P內(nèi)容的工具。因此，ECG將必須利 用現(xiàn)有STB能力。ECG包括基于例如YouTube、Joost和iPlayer等媒體內(nèi)容分發(fā)網(wǎng)絡(luò)上當 前可用內(nèi)容的動態(tài)內(nèi)容。兩種方法能用于生成ECG:靜態(tài)或按需。靜態(tài)生成的ECG將預(yù)先 行進(pre-crawl)到內(nèi)容站點并將在每個站點可用的內(nèi)容編入索引。這可定期進行以保持ECG最新。按需方法可利用向內(nèi)容站點的標準化接口(例如Web服務(wù))以在每次用戶想要 訪問內(nèi)容清單時訪問它。這確保ECG內(nèi)容始終是最新的。兩種方法均將利用ECG服務(wù)器能 用于查詢媒體內(nèi)容分發(fā)網(wǎng)絡(luò)MCDN或允許MCDN將更新推送到ECG服務(wù)器的預(yù)定義接口。這 些接口的細節(jié)在本專利的范圍之外，但能夠利用諸如Web服務(wù)等標準化接口。STB 4包括 STB視頻解碼器STB VD 4X、能夠從ECG門戶接收信息的STB電子內(nèi)容指南STB ECG 4Y及 STB中間件STB MW，用戶請求從該中間件發(fā)送到互工作模塊?？傊?，P2P代理1具有接口的集合、向P2P網(wǎng)絡(luò)的外部集合和內(nèi)部集合以及接口之 間的轉(zhuǎn)碼功能性。接口的外部集合構(gòu)成運營商希望連接到的不同內(nèi)容分發(fā)網(wǎng)絡(luò)的軟件客戶 端。例如，客戶端能夠包括BittorentDNA客戶端、Naspter客戶端及其它P2P應(yīng)用客戶端。 內(nèi)部接口構(gòu)成能夠使用包括用于多播的IGMP上的RTP和用于單播的RTSP的傳統(tǒng)方法實現(xiàn) 內(nèi)容輸送的模塊。轉(zhuǎn)碼器15中的轉(zhuǎn)碼功能性使得外部接口上接收的內(nèi)容能夠在內(nèi)部接口 發(fā)送出。該功能性由規(guī)則的集合組成，這些規(guī)則描述特定P2P應(yīng)用的內(nèi)容如何先轉(zhuǎn)碼為給 定媒體格式，然后經(jīng)標準傳輸協(xié)議分發(fā)到STB。因此，代理由媒體解碼器和編碼器的集合組 成。P2P代理進行媒體轉(zhuǎn)碼，將諸如比特率、分辨率和編解碼器等參數(shù)考慮在內(nèi)。圖3公開表示用于STB從因特網(wǎng)域取得所要求的內(nèi)容的方法的信號序列圖。圖3 中公開的實體已全部通過圖1和2的解釋一起解釋。媒體內(nèi)容分發(fā)網(wǎng)絡(luò)MCDN對應(yīng)于圖2 中的P2P網(wǎng)絡(luò)。現(xiàn)在將與圖3 —起更詳細地描述根據(jù)本發(fā)明第一實施例的方法。圖3要與 圖2—起解讀。該方法包括以下步驟-用戶接通21機頂盒4。-STB 4中的ECG客戶端4Y執(zhí)行對電子內(nèi)容指南ECG門戶18的內(nèi)容的取操作22。 取請求由此從STB發(fā)送到P2P代理1?？蛇x的是包括用戶的身份。-電子內(nèi)容指南如本申請更早如所述在ECG門戶中生成23。可選的是，用戶的身 份能用于個性化。-ECG數(shù)據(jù)從P2P代理1輸送到STB 4。ECG數(shù)據(jù)包括可用資源的列表。-用戶從可用資產(chǎn)的列表選擇25內(nèi)容。備選的是，如更早已提及的，能在此處執(zhí)行 搜索過程。-前一步驟中的用戶選擇將產(chǎn)生多播或單播取請求命令(例如，用于多播的IGMP 加入、用于單播的RTSP播放或HTTPGET)。如果用戶進行了搜索而不是從內(nèi)容的預(yù)定義集 合中選擇，則此步驟將僅在請求的視頻資產(chǎn)的成功發(fā)現(xiàn)后發(fā)生。此步驟的重要性在于它利 用現(xiàn)在STB上當前實現(xiàn)的現(xiàn)有內(nèi)容檢索方法。在此示例中，單播取請求從STB 4中的中間 件MW 4Z發(fā)送沈到流傳送模塊中的單播/多播模塊16/17。除有關(guān)期望的分派方法的信息 外，取請求還包括另外的元數(shù)據(jù)，例如，諸如期望媒體格式等信息，如比特率、編碼等。-檢索所要求的內(nèi)容的請求27從單播/多播模塊16/17發(fā)送到互工作模塊14。內(nèi) 部消息由此從單播/多播模塊16/17發(fā)送到互工作模塊14。這用信號通知互工作模塊在對 內(nèi)容的請求與媒體內(nèi)容分發(fā)網(wǎng)絡(luò)MCDN特定方法之間轉(zhuǎn)化。它是觸發(fā)消息，用信號向互工作 模塊通知STB已發(fā)出請求，并且互工作模塊應(yīng)將請求轉(zhuǎn)化為要發(fā)送到P2P模塊的P2P請求 (艮P，圖3中能看到的消息29)。-會話ID在互工作模塊14中生成08)以便識別當前會話。會話ID用于識別以 后將從媒體內(nèi)容分發(fā)網(wǎng)絡(luò)MCDN檢索的數(shù)據(jù)，以便來自用戶的請求能與從MCDN的內(nèi)容的實際檢索帶在一起?；スぷ髂K14保持會話狀態(tài)信息以確定例如視頻的接收內(nèi)容是否要作 為單播或多播發(fā)送到STB。-互工作模塊將包含會話ID、內(nèi)容名稱和諸如比特率、編碼等另外的元數(shù)據(jù)的消 息發(fā)送四到？2 模塊10以進行處理。在此示例中，另外的元數(shù)據(jù)在取請求中接收，但可能 的變化將是使它在P2P代理中預(yù)存。-P2P模塊使用30來自互工作模塊14的消息中的數(shù)據(jù)，例示包括會話ID、對數(shù)據(jù) 隊列的指針及另外的信息(即，步驟9中接收的或可在管理內(nèi)容檢索過程時使用的元數(shù)據(jù)) 的代理表12中的條目和視頻隊列11中的數(shù)據(jù)隊列。-在P2P模塊10與MCDN之間執(zhí)行協(xié)商31，使得內(nèi)容從MCDN下載31并放置在視 頻隊列11中。用于例如從多個源或單個源下載內(nèi)容的方法將確定如何填充數(shù)據(jù)隊列。數(shù) 據(jù)在到用戶的分發(fā)發(fā)生之前例如可能被排隊，直至收到全部內(nèi)容，或者數(shù)據(jù)可在下載期間 分發(fā)到用戶。-互工作模塊14收到內(nèi)容被下載的通知32。此通知帶有會話ID。此步驟有兩種 備選。選擇使用哪種備選可由P2P代理中的策略來指示。在內(nèi)容已完全下載時，P2P模塊發(fā) 送通知，或者在內(nèi)容的各個段已下載時它發(fā)送通知。由于內(nèi)容將流傳送到最終用戶，因此， 如果使用第二備選，則假設(shè)通知將是用于順序的段。-互工作功能使用會話ID來確定33內(nèi)容是否需要轉(zhuǎn)碼，即，將視頻信號轉(zhuǎn)換為不 同格式的另一信號，如不同比特率、幀速率、幀大小或甚至不同壓縮標準，以及向客戶的流 將是單播還是多播。在此示例中，流將是單播。-轉(zhuǎn)碼細節(jié)與到要轉(zhuǎn)碼的內(nèi)容的視頻隊列11的指針一起發(fā)送34到轉(zhuǎn)碼器15。-命令從互工作模塊14發(fā)送35到P2P模塊，向P2P模塊請求剩余視頻序列要直接 發(fā)送到轉(zhuǎn)碼器15。-轉(zhuǎn)碼器15將從視頻隊列11中的P2P模塊數(shù)據(jù)隊列獲得36要轉(zhuǎn)碼的內(nèi)容。此數(shù) 據(jù)隨后從其原始格式轉(zhuǎn)碼到對STB和始發(fā)請求適當?shù)母袷?。例外情況在一些情況下，內(nèi)容 可能已經(jīng)在正確格式中，由此轉(zhuǎn)碼器將只檢索內(nèi)容，并且將不操縱內(nèi)容。-內(nèi)容發(fā)送37到單播/多播模塊16/17。-單播/多播模塊16/17將流傳送38內(nèi)容到STB解碼器。在此示例中，將單播內(nèi)容。-內(nèi)容由STB解碼以便顯示39。要注意的是，上面所示信令是一個示例，并且變化是可能的。圖4公開本發(fā)明的第二實施例中包括運營商的寬帶網(wǎng)絡(luò)2B和因特網(wǎng)網(wǎng)絡(luò):3B的 內(nèi)容分發(fā)系統(tǒng)。移動IPTV機頂盒4B能夠在運營商的管理域內(nèi)看到。因特網(wǎng)網(wǎng)絡(luò)在此示 例中包括但不限于諸如Joost 5B, You Tube 6B和BitTorrent 7B等不同媒體內(nèi)容分發(fā)網(wǎng) 絡(luò)MCDN。圖4中公開了一種網(wǎng)絡(luò)節(jié)點。該網(wǎng)絡(luò)節(jié)點是MCDN代理1B，其能夠訪問因特網(wǎng)網(wǎng) 絡(luò)側(cè)和運營商網(wǎng)絡(luò)側(cè)。根據(jù)本發(fā)明，代理功能性在此示例中能夠轉(zhuǎn)換和發(fā)送從Joost、You Tube,BitTorrent域取得的視頻內(nèi)容。電子內(nèi)容指南ECG門戶18B在此實施例中位于MCDN 代理外。ECG是遺留STB用于允許用戶瀏覽和訪問傳統(tǒng)與新內(nèi)容(此示例中的Joost、You Tube、BitTorrent內(nèi)容)的工具。因此，ECG將必須利用現(xiàn)有STB能力。如前面所述，兩種 方法能用于生成ECG 靜態(tài)或按需。兩種方法均將利用ECG服務(wù)器能用于查詢MCDN或允許MCDN將更新推送到ECG服務(wù)器的預(yù)定義接口。圖5示意地公開MCDN代理1B。該代理具有到開放因特網(wǎng)網(wǎng)絡(luò)(在此示例中到因 特網(wǎng)的JoostJou Tube、BitTorrent部分)的接口。代理IB還具有到流傳送服務(wù)器的接 口，該服務(wù)器能夠使用例如多播或單播等適合的傳輸協(xié)議將內(nèi)容輸送到STB 4B。ECG門戶 18位于MCDN代理與STB 4B之間。代理IB包括MCDN模塊IOB。實際上，如在圖5中能看到的，MCDN模塊在此示例 中包括三個不同模塊Joost模塊、^u Tube模塊和BitTorrent模塊。每個模塊對應(yīng)于現(xiàn) 有網(wǎng)絡(luò)之一。每個MCDN模塊的功能性對應(yīng)于已更早在圖2中解釋的P2P模塊。每個MCDN 模塊附連到互工作模塊14B，而互工作模塊又附連到轉(zhuǎn)碼器15B?；スぷ髂K和轉(zhuǎn)碼器均 具有與圖2中前面所述對應(yīng)實體相同的功能性。MCDN代理經(jīng)轉(zhuǎn)碼器附連到流傳送服務(wù)器 17B，而該服務(wù)器又附連到STB 4B。像第一實施例中一樣，互工作模塊將從STB 4B的用戶 接收取請求。該取請求將在互工作模塊中映射到Joost、^u Tube、BitTorrent請求?；?工作模塊隨后執(zhí)行向外到所述網(wǎng)絡(luò)的請求。轉(zhuǎn)碼器15B使得外部接口上接收的內(nèi)容能夠 在內(nèi)部接口上發(fā)送出。轉(zhuǎn)碼功能性由規(guī)則的集合組成，這些規(guī)則描述特定應(yīng)用Joost、You Tube.BitTorrent的內(nèi)容如何先轉(zhuǎn)碼為給定媒體格式，然后經(jīng)標準傳輸協(xié)議分發(fā)到STB。流 傳送服務(wù)器17B可包括一個或兩個模塊、單播模塊和/或多播模塊。根據(jù)機頂盒如何請求 內(nèi)容，如果它是RTSP請求，則流傳送服務(wù)器將單播內(nèi)容到STB，并且如果STB進行對于多播 的IGMP加入，則流傳送服務(wù)器將多播內(nèi)容到機頂盒。ECG門戶附連到STB 4b和MCDN代理。 在ECG與代理之間必須存在關(guān)系。ECG維護到每個內(nèi)容項目的鏈接。在從STB到ECG的內(nèi) 容請求后，作為請求的一部分，鏈接指定從STB轉(zhuǎn)發(fā)到MCDN代理(例如，在RTSP播放命令 中)。作為備選，ECG可向MCDN代理指定到內(nèi)容的鏈接。由STB 4B用于從因特網(wǎng)域取得所要求的內(nèi)容的信號序列的一個基本示例可如下 所示-在STB從ECG已收到可用內(nèi)容后，用戶選擇要下載的期望內(nèi)容。在此示例中，選 擇來自MCDN Joost的內(nèi)容。-取請求從STB4B發(fā)送到MCDN代理IB中的互工作模塊14B。-會話ID在互工作模塊14B中生成以便識別當前會話。-互工作模塊14B將包含會話ID、內(nèi)容名稱和另外的元數(shù)據(jù)的消息發(fā)送到MCDN Joost模塊IOB以進行處理。-數(shù)據(jù)隊列和代理表中的條目在MCDNJoost模塊IOB中例示。-內(nèi)容從M⑶NJoost網(wǎng)絡(luò)下載并且放置在M⑶N Joost模塊IOB中。-互工作模塊14B收到內(nèi)容被下載的通知。-轉(zhuǎn)碼細節(jié)與到要轉(zhuǎn)碼的內(nèi)容的指針一起從互工作模塊14B發(fā)送到轉(zhuǎn)碼器15B。-命令從互工作模塊14B發(fā)送到MCDNJoost模塊10B，向模塊請求視頻序列要直 接發(fā)送到轉(zhuǎn)碼器15B。-接收到轉(zhuǎn)碼器15B的數(shù)據(jù)從其原始格式轉(zhuǎn)碼為對STB4B和始發(fā)請求適當?shù)母袷健?內(nèi)容被發(fā)送到流傳送服務(wù)器17B。-流傳送服務(wù)器將內(nèi)容流傳送到STB4B并且內(nèi)容將被顯示。
圖6公開了示出本發(fā)明一些基本方法步驟的流程圖。該流程圖要與前面所示圖形 一起解讀。該流程圖包括以下步驟-將從外部域檢索內(nèi)容的請求從機頂盒接收到網(wǎng)絡(luò)節(jié)點。此步驟在圖中通過框 101示出。-所要求的內(nèi)容從外部域檢索到網(wǎng)絡(luò)節(jié)點。此步驟在圖中通過框102示出。-所要求的內(nèi)容在網(wǎng)絡(luò)節(jié)點中轉(zhuǎn)換為可經(jīng)機頂盒訪問的格式。此步驟在圖中通過 框103示出。-轉(zhuǎn)換的內(nèi)容從網(wǎng)絡(luò)節(jié)點輸送到機頂盒。此步驟在圖中通過框104示出。能用于實行本發(fā)明的節(jié)點和系統(tǒng)已在圖1、2、4和5中示出。列舉的項在圖中示為 各個要素。然而，在本發(fā)明的實際實現(xiàn)中，它們可能是諸如數(shù)字計算機(處理器)等其它電 子裝置的不可分開的組件。因此，上述動作可在軟件中實現(xiàn)，而軟件可在包括程序存儲媒 體的制造的物品中實施。程序存儲媒體包括一個或多個載波中包含的數(shù)據(jù)信號、計算機盤 (磁或光(例如，CD或DVD或兩者))、非易失性存儲器、磁帶、系統(tǒng)存儲器或計算機硬盤驅(qū) 動器。本發(fā)明不限于以上所述和附圖所示的實施例，而是可在隨附權(quán)利要求范圍內(nèi)進 行修改。本發(fā)明的系統(tǒng)和方法例如可在第三代合作伙伴項目(3GPP)、歐洲電信標準協(xié)會 (ETSI)、美國國家標準協(xié)會(ANSI)或其它標準電信網(wǎng)絡(luò)架構(gòu)的任何架構(gòu)上實現(xiàn)。其它示例 是電氣和電子工程師協(xié)會(IEEE)或因特網(wǎng)工程任務(wù)組(IETF)或?qū)拵д搲?。為了解釋而不是限制的目的，說明書陳述了特定的細節(jié)，如特定的組件、電子電 路、技術(shù)等，以便提供本發(fā)明的理解。但本領(lǐng)域的技術(shù)人員將理解，本發(fā)明可在脫離這些特 定細節(jié)的其它實施例中實踐。在其它情況下，省略了公知方法、裝置和技術(shù)等的詳細描述以 免因不必要的細節(jié)混淆描述。在一個或多個圖形中顯示了各個功能塊。本領(lǐng)域的技術(shù)人員 將理解，功能可使用分立組件或多功能硬件來實現(xiàn)。處理功能可使用編程的微處理器或通 用計算機來實現(xiàn)。本發(fā)明不限于以上所述和附圖所示的實施例，而是可在隨附權(quán)利要求的 范圍內(nèi)進行修改。當然，本發(fā)明不限于以上所述和附圖所示的實施例，而是可在隨附權(quán)利要求的范 圍內(nèi)進行修改。
權(quán)利要求
1.一種用于IPTV機頂盒G，4B)從所述IPTV服務(wù)提供商的域Q，2B)之外的外部域 (3，3B)訪問內(nèi)容的方法，所述方法特征在于以下步驟從所述外部域檢索要求的內(nèi)容和將 所述要求的內(nèi)容轉(zhuǎn)換成經(jīng)所述IPTV機頂盒可訪問的格式。
2.如權(quán)利要求1所述的用于IPTV機頂盒G，4B)訪問內(nèi)容的方法，所述方法包括以下 另外步驟-將從所述外部域(3，3B)檢索內(nèi)容的請求從所述機頂盒G，4B)接收到網(wǎng)絡(luò)節(jié)點(1，1B)；-將所述要求的內(nèi)容從所述外部域(3，3B)檢索到所述網(wǎng)絡(luò)節(jié)點(1，1B)； -在所述節(jié)點(1，1B)中將來自所述外部域的要求的內(nèi)容轉(zhuǎn)換成經(jīng)所述機頂盒可訪問 的格式；-將所轉(zhuǎn)換的內(nèi)容從所述節(jié)點(1，1B)輸送到所述IPTV機頂盒G，4B)。
3.如權(quán)利要求2所述的用于IPTV機頂盒訪問內(nèi)容的方法，所述方法包括以下另外步驟-從所述機頂盒G，4B)將取請求接收到所述節(jié)點(1，1B)，所述請求包括所述要求的內(nèi) 容的指定和指定的輸送細節(jié)；-將要求的內(nèi)容從所述外部域(3，3B)中的媒體內(nèi)容分發(fā)網(wǎng)絡(luò)(MCDN)下載到所述節(jié)點 (LIB)；-在所述節(jié)點(1，1B)中執(zhí)行要求的輸送細節(jié)。
4.如權(quán)利要求3所述的用于IPTV機頂盒訪問內(nèi)容的方法，其中所述取請求在所述網(wǎng)絡(luò) 節(jié)點中轉(zhuǎn)化到適合于所述媒體內(nèi)容分發(fā)網(wǎng)絡(luò)(MCDN)的格式。
5.如權(quán)利要求3或4所述的用于IPTV機頂盒訪問內(nèi)容的方法，由此所述要求的輸送細 節(jié)包括轉(zhuǎn)碼指定，例如多播或單播。
6.如權(quán)利要求3-5的任一項所述的用于IPTV機頂盒訪問內(nèi)容的方法，由此所述要求的 輸送細節(jié)包括適合于所述機頂盒的要求的內(nèi)容格式，例如比特率、分辨率、編解碼器。
7.如權(quán)利要求6所述的用于IPTV機頂盒訪問內(nèi)容的方法，其中所述要求的輸送細節(jié)的 至少部分已預(yù)存儲在所述網(wǎng)絡(luò)節(jié)點(1，1B)中。
8.如前面權(quán)利要求3-7的任一項所述的用于IPTV機頂盒訪問內(nèi)容的方法，所述方法包 括以下另外的步驟-在所述節(jié)點(1)中生成要用于識別會話的會話ID，所述會話源于對來自所述媒體內(nèi) 容分發(fā)網(wǎng)絡(luò)(MCDN)的內(nèi)容的內(nèi)部信令請求。
9.如權(quán)利要求8所述的用于IPTV機頂盒訪問內(nèi)容的方法，其中所述會話ID在所述網(wǎng) 絡(luò)節(jié)點中用于將所述會話與輸送細節(jié)和內(nèi)容格式放在一起。
10.如權(quán)利要求8或9所述的用于IPTV機頂盒訪問內(nèi)容的方法，所述方法包括以下另 外步驟-例示所述網(wǎng)絡(luò)節(jié)點(1，1B)中表(12)中的條目，包括所述會話ID和到啟動的數(shù)據(jù)隊 列的指針。
11.一種適合于IPTV機頂盒G，4B)從所述IPTV服務(wù)提供商的域Q，2B)之外的外部 域(3，3B)訪問內(nèi)容的設(shè)備，所述設(shè)備特征在于能夠從所述外部域檢索內(nèi)容和將所述內(nèi)容 轉(zhuǎn)換成經(jīng)所述IPTV機頂盒可訪問的格式的網(wǎng)絡(luò)節(jié)點(1，1B)。
12.如權(quán)利要求11所述的適合于IPTV機頂盒G，4B)訪問內(nèi)容的設(shè)備，所述設(shè)備包括 -用于將從所述外部域(3，3B)檢索內(nèi)容的請求從所述機頂盒G，4B)接收到所述網(wǎng)絡(luò)節(jié)點(1，1B)的部件；-用于將所要求的內(nèi)容從所述外部域(3，3B)檢索到所述網(wǎng)絡(luò)節(jié)點(1，1B)的部件； -用于在所述節(jié)點(1，1B)中將來自所述外部域的要求的內(nèi)容轉(zhuǎn)換成經(jīng)所述機頂盒可 訪問的格式的部件；-用于將所轉(zhuǎn)換的內(nèi)容從所述節(jié)點(1，1B)輸送到所述IPTV機頂盒G，4B)的部件。
13.如權(quán)利要求12所述的適合于IPTV機頂盒訪問內(nèi)容的設(shè)備，所述設(shè)備還包括 -用于從所述機頂盒G，4B)將取請求接收到所述節(jié)點(1，1B)的部件，所述請求包括所要求的內(nèi)容的指定和指定的輸送細節(jié)；-用于將要求的內(nèi)容從所述外部域(3，3B)中的媒體內(nèi)容分發(fā)網(wǎng)絡(luò)(MCDN)下載到所述 節(jié)點(1，1B)的部件；-用于在所述節(jié)點(1，1B)中執(zhí)行要求的輸送細節(jié)的部件。
14.如權(quán)利要求13所述的適合于IPTV機頂盒訪問內(nèi)容的設(shè)備，其中所述取請求在所述 網(wǎng)絡(luò)節(jié)點中轉(zhuǎn)化到適合于所述媒體內(nèi)容分發(fā)網(wǎng)絡(luò)(MCDN)的格式。
15.如權(quán)利要求13或14所述的適合于IPTV機頂盒訪問內(nèi)容的設(shè)備，由此所述要求的 輸送細節(jié)包括轉(zhuǎn)碼指定，例如多播或單播。
16.如權(quán)利要求13-15的任一項所述的適合于IPTV機頂盒訪問內(nèi)容的設(shè)備，由此所 述要求的輸送細節(jié)包括適合于所述機頂盒的要求的內(nèi)容格式，例如比特率、分辨率、編解碼器。
17.如權(quán)利要求16所述的適合于IPTV機頂盒訪問內(nèi)容的設(shè)備，其中所述要求的輸送細 節(jié)的至少部分已預(yù)存儲在所述網(wǎng)絡(luò)節(jié)點(1，1B)中。
18.如前面權(quán)利要求13-17的任一項所述的適合于IPTV機頂盒訪問內(nèi)容的設(shè)備，所述 方法包括以下另外步驟-用于在所述節(jié)點(1)中生成要用于識別會話的會話ID的部件，所述會話源于對來自 所述媒體內(nèi)容分發(fā)網(wǎng)絡(luò)(MCDN)的內(nèi)容的內(nèi)部信令請求。
19.如權(quán)利要求18所述的適合于IPTV機頂盒訪問內(nèi)容的設(shè)備，其中所述會話ID在所 述網(wǎng)絡(luò)節(jié)點中用于將所述會話與輸送細節(jié)和內(nèi)容格式放在一起。
20.如權(quán)利要求18或19所述的適合于IPTV機頂盒訪問內(nèi)容的設(shè)備，所述設(shè)備還包括 -用于在所述網(wǎng)絡(luò)節(jié)點(1，1B)中例示表(12)中的條目、包括所述會話ID和到啟動的數(shù)據(jù)隊列的指針的部件。
21.一種適合于IPTV機頂盒G，4B)從所述IPTV服務(wù)提供商的域Q，2B)之外的外部 域(3，3B)訪問內(nèi)容的網(wǎng)絡(luò)節(jié)點(1，1B)，所述節(jié)點特征在于-用于接收從所述外部域(3，3B)檢索內(nèi)容的請求的部件； -用于從所述外部域(3，3B)檢索所要求的內(nèi)容的部件；-用于將來自所述外部域的要求的內(nèi)容轉(zhuǎn)換成經(jīng)所述機頂盒可訪問的格式的部件； -用于從所述節(jié)點(1，1B)輸送所轉(zhuǎn)換的內(nèi)容的部件。
22.—種可加載到網(wǎng)絡(luò)節(jié)點的處理器中的計算機程序，其中所述計算機程序包括適合 于執(zhí)行權(quán)利要求1-10的一項或多項的代碼。
全文摘要
本發(fā)明涉及用于IPTV機頂盒4、4B從IPTV服務(wù)提供商的域2、2B外的外部域3、3B訪問內(nèi)容的方法和設(shè)備，該方法特征在于以下步驟從外部域檢索要求的內(nèi)容和將其轉(zhuǎn)換成經(jīng)IPTV機頂盒可訪問的格式。
文檔編號H04N7/173GK102084661SQ200880130296
公開日2011年6月1日 申請日期2008年7月7日 優(yōu)先權(quán)日2008年7月7日
發(fā)明者A·達莫拉, J·奧爾森 申請人:愛立信電話股份有限公司