內(nèi)容遞送系統(tǒng)及方法
【專利說明】內(nèi)容遞送系統(tǒng)及方法
[0001 ] 本發(fā)明涉及多播路由的領域。
[0002] 諸如音頻和/或視頻的數(shù)字媒體可以以單播或多播傳輸模式在數(shù)據(jù)通信網(wǎng)絡上 從源到主機（終端用戶）進行流式傳輸。示例應用包括電視和視頻服務（包括所謂的"點 播"服務）以及視頻會議。在單播傳輸中，媒體從源到由唯一的地址確定的單個網(wǎng)絡目的地 被流傳輸。在多播傳輸中，媒體在單個傳輸中同時從源到一組主機被流傳輸。
[0003] 多播網(wǎng)絡分為以下兩部分操作：一個是使用諸如因特網(wǎng)組成員協(xié)議（IGMP)的協(xié) 議管理對組的主機的成員，并且第二個是管理對在網(wǎng)絡中預訂內(nèi)容源的組的路由器的成 員。本領域的技術人員將理解，存在許多使用不同技術以建立組成員樹的多播路由協(xié)議。本 工作是可適用的，但絕不限于，獨立多播協(xié)議-稀疏模式（PM-SM)路由，RFC 4601。
[0004] 在單播模式中，當主機（終端用戶）需要一段媒體內(nèi)容時，它使用帶有它想接收的 所述內(nèi)容或播放列表的統(tǒng)一資源標識符（URI)的媒體流協(xié)議發(fā)送請求。典型的協(xié)議的示例 包括無狀態(tài)HTTP流或者有狀態(tài)的實時流協(xié)議（RTSP)。RTSP通常使用實時傳輸協(xié)議（RTP) 來傳送內(nèi)容本身，然而HTTP在它的對GET消息的響應中使用HTML主體傳送內(nèi)容。這使用 IP來封裝并且被路由到媒體服務器。然后，使用單播將內(nèi)容發(fā)送到主機。如果高速緩存就 位，則繼對該段內(nèi)容的進一步請求被指向高速緩存而不是數(shù)據(jù)源之后，對短時間段內(nèi)的同 一內(nèi)容的多個請求觸發(fā)對內(nèi)容的緩存過程。然而，每個源從高速緩存或者源接收數(shù)據(jù)的單 播流。這通過網(wǎng)絡導致數(shù)據(jù)復制，期望該數(shù)據(jù)復制最小化以便對網(wǎng)絡容量進行更有效的使 用。觸發(fā)多播是解決該問題的一種方法。
[0005] 按照慣例，這樣的觸發(fā)響應于被交叉的上和/或下使用閾值被反應性地發(fā)起。如 果上閾值被超過，那么傳輸從單播切換到多播。當使用低于下閾值時，那么傳輸返回到單 播。
[0006] 根據(jù)本發(fā)明的第一方面，提供了一種在內(nèi)容遞送網(wǎng)絡中從源分發(fā)內(nèi)容的方法，該 方法包括：監(jiān)視對內(nèi)容項的傳送的請求；獲得針對所述內(nèi)容的未來需求的預測；應用單播 至多播切換決定算法，切換決定算法考慮未來需求的預測并且被設置為確定至少一個觸發(fā) 條件是否被滿足；并且根據(jù)單播至多播切換決定算法的結(jié)果，開始針對內(nèi)容項的多個單播 數(shù)據(jù)流到一多播數(shù)據(jù)流的轉(zhuǎn)換，其中，針對所述內(nèi)容的未來需求的預測是基于與針對所述 內(nèi)容的實際需求無關的數(shù)據(jù)。與對所述內(nèi)容的實際需求無關的數(shù)據(jù)包括從社會數(shù)據(jù)源獲得 的數(shù)據(jù)和/或從搜索引擎獲得的數(shù)據(jù)。
[0007] 通過以這種方式使用未來需求的預測，多播流可以主動地和自主地被發(fā)起，從而 改善網(wǎng)絡資源的分配。
[0008] 可選地，該方法還可以包括保持針對所述內(nèi)容項的針對指向所述源的所述請求的 統(tǒng)計記錄，并且使用所述記錄中的至少某些所述數(shù)據(jù)來獲得所述未來需求的預測。
[0009] 通過例舉的方式，未來需求的預測可以是基于先前時間段上的激活的會話的數(shù) 量。另選地，它可以是基于先前時間段上的激活的會話的平均數(shù)量，通過在所述時間段內(nèi)的 時刻確定激活的會話的數(shù)量以及確定其平均來評價激活的會話的平均數(shù)量。
[0010] 未來需求的預測可能被限定于一天的時間（例如，關于每小時的新聞廣播）、和/ 或一周的天。
[0011] 可選地，切換決定算法可以考慮統(tǒng)計記錄中的數(shù)據(jù)。
[0012] 可選地，切換算法可以考慮統(tǒng)計記錄中的一個或多個參數(shù)，所述參數(shù)選自包括以 下項的組：激活的會話的當前數(shù)量；在給定的時間段期間對所述內(nèi)容的請求的總數(shù)；平均 會話持續(xù)時間；會話過早地結(jié)束的概率；所述內(nèi)容的數(shù)據(jù)大小。
[0013] 該方法還可以包括保持選自包括以下項的組的一個或多個背景動作：周期性地選 擇引導路由器不考慮在網(wǎng)絡中正進行多播；候選引導路由器將他們的候選狀態(tài)告知給所選 擇的引導路由器；多播路由器向彼此發(fā)送"hello"消息，而不考慮在網(wǎng)絡中正進行多播。
[0014] 可選地，將多個單播流轉(zhuǎn)換為多播流的過程可以包括：生成組地址系統(tǒng)；創(chuàng)建針 對將被切換到多播的內(nèi)容的會話描述信息；并且將主機加入多播數(shù)據(jù)流。
[0015] 轉(zhuǎn)換過程還可以包括生成關于所述內(nèi)容的多播特定的統(tǒng)一資源指示符。
[0016] 生成組地址系統(tǒng)可以包括分配針對每個統(tǒng)一資源標識符的一組地址，或者為主機 組和源的每個地理位置組合分配組地址。
[0017] 此外，生成組地址系統(tǒng)可以包括使用一組現(xiàn)有的組地址，或使用動態(tài)的地址池。另 選地，可以從地址分配服務器接收一組地址。
[0018] 轉(zhuǎn)換過程還可以包括在被發(fā)送到各自的會合點的登記消息中封裝來自源的分組。
[0019] 如果主機已經(jīng)請求單播數(shù)據(jù)流并且還沒有開始接收該流，則轉(zhuǎn)換過程還可以包括 響應于發(fā)送到主機處的瀏覽器的代碼嵌入新的多播統(tǒng)一資源標識符，或者向主機發(fā)送包括 組地址或者統(tǒng)一資源標識符的消息以獲得該組地址。
[0020] 如果主機已經(jīng)開始接收單播流，則轉(zhuǎn)換過程還可以包括使用反向信道來向主機發(fā) 送組地址或者統(tǒng)一資源標識符以獲得組地址。如果RTSP正被用于單播中，則該過程還可以 包括使用宣告（Announce)、重定向或者設置參數(shù)（Set_Parameter)請求向主機宣布變化。
[0021] 此外，轉(zhuǎn)換過程可以包括響應于來自主機的請求使得多播內(nèi)容在給定的時間開 始。
[0022] 另選地，如果HTTP正在被用于單播中，轉(zhuǎn)換過程還可以包括響應于來自主機的針 對流方法的當前狀態(tài)的請求，提供新的統(tǒng)一資源標識符或者主機可以建立成員關系的組地 址。
[0023] 轉(zhuǎn)換過程還可以包括觸發(fā)支持多播的擴展的IP模塊的上層協(xié)議以發(fā)出成員加入 請求。
[0024] 可選地，轉(zhuǎn)換過程還可以包括響應于主機檢測到正經(jīng)由單播和經(jīng)由多播接收到基 本上相同的內(nèi)容，終止單播會話，從而對網(wǎng)絡容量進行更有效的使用。
[0025] 可以在諸如路由器（具體地，源的指定路由器）或服務器的網(wǎng)絡設備上或者通過 諸如路由器（具體地，源的指定路由器）或服務器的網(wǎng)絡設備執(zhí)行上述方法。
[0026] 根據(jù)接收關于內(nèi)容項的請求，該方法還可以包括服務器確定是否任何其它服務器 具有關于所述內(nèi)容的任何激活的會話并且，如果有，合并對不同的服務器進行的多個會話 請求，使得單個服務器處理多個會話請求。該合并的多個會話請求可以足夠觸發(fā)多播，然 而，在合并之前，由單獨的服務器處理的會話請求的數(shù)量可能還沒有完成。因此，該合并過 程可以進一步改善網(wǎng)絡資源的分配。
[0027] 可選地，觸發(fā)條件可以包括針對內(nèi)容的預測的未來需求的閾值。
[0028] 根據(jù)本發(fā)明的第二方面，提供了一種具有配置成根據(jù)本發(fā)明的第一方面執(zhí)行方法 的邏輯的網(wǎng)絡設備（例如，路由器或服務器）。
[0029] 根據(jù)本發(fā)明的第三方面，提供了一種計算機可實現(xiàn)指令產(chǎn)品，該計算機可實現(xiàn)指 令產(chǎn)品包括用于使得可編程計算設備實現(xiàn)本發(fā)明的第一方面的方法或者被配置為本發(fā)明 的第二方面的網(wǎng)絡設備的計算機可實現(xiàn)指令。
[0030] 在此描述了系統(tǒng)的許多實施方式。對本領域的技術人員清楚的是，這些實施方式 中的每一個可以被獨立地實現(xiàn)。然而，實施方式彼此結(jié)合更好地實現(xiàn)以提供多個優(yōu)點作為 大型系統(tǒng)的一部分。一個實施方式的優(yōu)選特征可以被直接應用于系統(tǒng)的其它實施方式。此 外，方法特征可以被直接應用于裝置的方面。
[0031 ] 具體地，在上述所有方面中，在多播網(wǎng)絡中，目的地可以是主機或者主機指定路由 器（H-DR)。主機可以是與末端用戶或者內(nèi)容的消費者有關的末端用戶終端，或者可以是向 用戶的設備供應內(nèi)容的中間設備。例如，目的地可以是接收用于流傳輸?shù)街T如互聯(lián)網(wǎng)連接 的電視機、計算機、平板或電話的用戶的終端的內(nèi)容的家庭網(wǎng)絡內(nèi)的集線器。
[0032] 類似地，在上述所有方面中，源可以是在網(wǎng)絡中供應內(nèi)容的設備，或者可以是處理 到目的地的內(nèi)容的路由的網(wǎng)絡中的情報路由部件。內(nèi)容可以穿過情報路由部件，或者部件 可以控制網(wǎng)絡中的其它部件（諸如，源）以實現(xiàn)在此描述的方法。
[0033] 此外，在上述的所有實施方式中，內(nèi)容優(yōu)選地是視頻內(nèi)容和/或者音頻內(nèi)容，具體 地響應于來自用戶的請求傳送的點播內(nèi)容。然而，技術人員將理解，本文描述的系統(tǒng)和方法 同樣可以被應用于網(wǎng)絡針對諸如文本或圖像數(shù)據(jù)的數(shù)據(jù)或軟件的分發(fā)。
[0034] 下面將僅通過示例的方式并且參照附圖描述本發(fā)明的實施方式，其中：
[0035] 圖1是具有多個單播流的網(wǎng)絡的示意圖；
[0036] 圖2是其中多個單播流已經(jīng)被轉(zhuǎn)換為自主多播的圖1的網(wǎng)絡的示意圖；
[0037] 圖3示出了在源的指定路由器上操作的"多播使能器"；
[0038] 圖4示出了與多播使能器相關的切換算法的操作；
[0039] 圖5示出了與多播使能器相關的預測算法的操作；以及
[0040] 圖6是根據(jù)一個實施方式的實現(xiàn)多播路由的網(wǎng)絡的示意圖。
[0041] 本實施方式代表對于將本發(fā)明付諸實踐的申請人所已知的最佳方式。然而，它們 并不是實現(xiàn)該目的唯一方式。
[0042] 定義
[0043] 如在此使用的下面術語具有下面的定義：
[0044] 主機：從可以通過單播或者多播傳送的源請求一些內(nèi)容的末端用戶設備。
[0045] 源：經(jīng)由單播發(fā)送到主機或者經(jīng)由多播推入網(wǎng)絡的一些內(nèi)容的提供者。
[0046] 內(nèi)容：電子媒介，包括但不限于視頻文件/流、線性TV、音頻文件/流（會議、廣播、 播客）、大文件下載等。
[0047] 播放器：在可以從源下載內(nèi)容并且將其顯示在主機處的主機上運行的軟件程序。 可以經(jīng)由瀏覽器插件（例如，Adobe Flash播放器）將播放器嵌入到網(wǎng)頁中。
[0048] 固定流：以順序的方式經(jīng)由一些下載或者流機制進行一段內(nèi)容的傳輸。主機將從 向前與由源的請求的接收一致的特定的起始位置接收內(nèi)容。主機不能從該起始位置之前請 求內(nèi)容。
[0049] 靈活流：以順序的方式經(jīng)由一些下載或者流機制進行一段內(nèi)容的傳輸。主機自由 地從任意起始位置請求內(nèi)容并且可以在內(nèi)容中的位置之間自由切換，導致當前內(nèi)容傳送到 主機以在所請求的位置停止和恢復。
[0050] DR:指定路由器。
[0051] 網(wǎng)絡體系結(jié)構(gòu)
[0052] 在圖6中示意性地示出了本系統(tǒng)的方面可以被實現(xiàn)于其中的網(wǎng)絡800。多播網(wǎng)絡 可以被用于從多個內(nèi)容服務器或者源810、812、814中的一個向多個目的地或者主機816、 818、820中的每個傳送諸如視頻點播內(nèi)容的內(nèi)容。多播網(wǎng)絡概念上可以被分為兩個部分，其 中一個826包括主機和相鄰的路由器822、824,該部分使用諸如因特網(wǎng)組管理協(xié)議（IGMP) 的協(xié)議進行通信以建立并且管理主機的多播組成員。在IPv6網(wǎng)絡中，網(wǎng)絡的該部分可以使 用多播監(jiān)聽發(fā)現(xiàn)（MLD)和ICMPv6(互聯(lián)網(wǎng)控制消息協(xié)議）消息傳送操作，并且在此對IGMP 和其它IPv4協(xié)議的參考旨在包括和涵蓋等同的IPv6協(xié)議。
[0053] 多播網(wǎng)絡828的其它概念上的部分通常使用諸如獨立多播協(xié)議的協(xié)議通常在稀 疏模式（P頂-SM)下在網(wǎng)絡的其余部分中從源810、812、814到與主機822、824相鄰的路由 器路由和實現(xiàn)多播。具體地，本領域的技術人員將知道的PM-SM或者類似協(xié)議被用于對于 多播組管理路由器的成員