本公開(kāi)一般是與計(jì)算器網(wǎng)絡(luò)有關(guān)，而且更特別地，與計(jì)算器網(wǎng)絡(luò)數(shù)據(jù)流量管理有關(guān)。

背景技術(shù)：

隨著連網(wǎng)技術(shù)的快速進(jìn)展，視頻數(shù)據(jù)已經(jīng)變成許多應(yīng)用程序中不可分開(kāi)的部分。特別是，視頻點(diǎn)播(Video on demand,VoD)是例如數(shù)字圖書(shū)館、遠(yuǎn)距學(xué)習(xí)、協(xié)作訓(xùn)練、公開(kāi)信息系統(tǒng)、電子商務(wù)及娛樂(lè)等重要應(yīng)用程序的核心技術(shù)。典型的VoD服務(wù)允許遠(yuǎn)程用戶從存儲(chǔ)在一個(gè)或多個(gè)服務(wù)器上的大量視頻中回放視頻。響應(yīng)于服務(wù)請(qǐng)求，視頻服務(wù)器以同步視頻流的方式對(duì)用戶傳送視頻。

一方面而言，無(wú)線網(wǎng)絡(luò)的日益普及，另一方面結(jié)合了對(duì)于VoD資源無(wú)所不在的接入的需求，相對(duì)于要將可從視頻服務(wù)器中獲得的不斷增加的數(shù)據(jù)量傳送到增長(zhǎng)的用戶基礎(chǔ)存在挑戰(zhàn)。

舉例而言，當(dāng)存在對(duì)數(shù)據(jù)的高度需求(例如視頻)的突然情況時(shí)，即會(huì)發(fā)生問(wèn)題。例如，流行歌手麥可杰克森的死亡引起了對(duì)他的視頻的高度興趣的時(shí)期。當(dāng)類(lèi)似這樣的情形發(fā)生時(shí)，對(duì)于相關(guān)視頻的需求的大量增加會(huì)對(duì)其他正常視頻與數(shù)據(jù)的正常接入有顯著沖擊。

已經(jīng)使用了各種方式來(lái)對(duì)大量用戶傳播大量數(shù)據(jù)(例如視頻流)。一種這樣的方式是多播技術(shù)，它允許許多用戶共享受歡迎的服務(wù)器流。然而，這種方式一般都需要所有的用戶在指定的時(shí)間觀看相同的數(shù)據(jù)，且因此無(wú)法在用戶方便時(shí)“按需(on demand)”開(kāi)始。

技術(shù)實(shí)現(xiàn)要素：

一種計(jì)算裝置可包括存儲(chǔ)器與處理器，所述存儲(chǔ)器與處理器協(xié)作以按需從至少一個(gè)數(shù)據(jù)源接收要被中繼到不同目的地的多個(gè)數(shù)據(jù)流，其中每個(gè)數(shù)據(jù)流具有與其相關(guān)聯(lián)的各自的內(nèi)容識(shí)別符。所述處理器可進(jìn)一步根據(jù)與其相關(guān)聯(lián)的各自的內(nèi)容識(shí)別符確定針對(duì)第一目的地的第一個(gè)數(shù)據(jù)流何時(shí)與針對(duì)第二目的地的第二個(gè)數(shù)據(jù)流共享相同的數(shù)據(jù)，以及基于根據(jù)所述各自的相關(guān)聯(lián)內(nèi)容識(shí)別符所確定的第一與第二數(shù)據(jù)流共享相同的數(shù)據(jù)，暫停將第二數(shù)據(jù)流中繼到所述第二目的地，并且開(kāi)始將第一數(shù)據(jù)流中繼到所述第二目的地。

更特別地，處理器可與存儲(chǔ)器協(xié)作，以將第一數(shù)據(jù)流存儲(chǔ)在存儲(chǔ)器中，并且從所述第二數(shù)據(jù)流中暫停中繼的位置處開(kāi)始，將所述存儲(chǔ)器中的所述第一數(shù)據(jù)流中繼到所述第二目的地。作為示例，存儲(chǔ)器可包括先進(jìn)先出(FIFO)存儲(chǔ)器。同樣作為示例，第一與第二數(shù)據(jù)流可包括視頻數(shù)據(jù)流。

此外，第一與第二數(shù)據(jù)流各具有與其相關(guān)聯(lián)的各自的下游節(jié)點(diǎn)識(shí)別符。更甚者，處理器也確定所述第一與第二數(shù)據(jù)流何時(shí)具有匹配的下游節(jié)點(diǎn)識(shí)別符，并進(jìn)一步基于所述匹配的下游節(jié)點(diǎn)識(shí)別符開(kāi)始從所述存儲(chǔ)器將所述第一數(shù)據(jù)流中繼到所述第二目的地。處理器進(jìn)一步用于確定何時(shí)終止將所述第一數(shù)據(jù)流中繼到所述第一目的地，以及基于確定已經(jīng)終止中繼所述第一數(shù)據(jù)流，中斷將所述第一數(shù)據(jù)流中繼到所述第二目的地并且恢復(fù)將所述第二數(shù)據(jù)流中繼到所述第二目的地。

內(nèi)容識(shí)別符可被編碼在各自的數(shù)據(jù)流中。此外，具有相同內(nèi)容識(shí)別符的數(shù)據(jù)流具有相同內(nèi)容，且處理器用于基于具有所述相同內(nèi)容識(shí)別符的第一與第二數(shù)據(jù)流確定第一與第二數(shù)據(jù)何時(shí)共享相同數(shù)據(jù)。

同時(shí)也提供了一種相關(guān)的計(jì)算器網(wǎng)絡(luò)，它可包括多個(gè)例如上文簡(jiǎn)要說(shuō)明的計(jì)算裝置。同時(shí)也提供了一種相關(guān)方法，以通過(guò)計(jì)算網(wǎng)絡(luò)而按需將來(lái)自至少一個(gè)數(shù)據(jù)源的多個(gè)數(shù)據(jù)流中繼到多個(gè)不同目的地，計(jì)算網(wǎng)絡(luò)包括多個(gè)計(jì)算裝置，例如上文簡(jiǎn)要說(shuō)明的計(jì)算裝置。

附圖說(shuō)明

本說(shuō)明是參照如附圖式加以進(jìn)行，圖式中繪示了例示具體實(shí)施例。然而，許多具體實(shí)施例都可被使用，且因此本發(fā)明不應(yīng)被解釋限于本文所提出的具體實(shí)施例。更確切地說(shuō)，這些具體實(shí)施例是為了要讓本發(fā)明更為透徹完整而提供。

圖1為計(jì)算裝置的示意圖，所述計(jì)算裝置用于執(zhí)行根據(jù)示例方面的動(dòng)態(tài)流合并操作。

圖2至圖3為一系列的示意圖，說(shuō)明了根據(jù)示例方面的動(dòng)態(tài)流合并方法。

圖4至圖9為一系列的示意圖，說(shuō)明了在示例實(shí)施例中可與動(dòng)態(tài)流合并方法一起使用的封包路由方法。

圖10為傳統(tǒng)路由方法及根據(jù)示例方面使用動(dòng)態(tài)流合并的路由方法的數(shù)據(jù)速率對(duì)流數(shù)量的比較圖。

圖11為傳統(tǒng)路由方法及根據(jù)示例方面使用動(dòng)態(tài)流合并的路由方法的傳輸?shù)淖止?jié)對(duì)鏈路數(shù)的比較圖。

圖12a至圖12d為一系列示意圖，說(shuō)明了可用于示例實(shí)施例的其他動(dòng)態(tài)流合并技術(shù)。

圖13a為示意圖，說(shuō)明了根據(jù)示例方面的多流式動(dòng)態(tài)流合并場(chǎng)景。

圖13b為示意圖，說(shuō)明了使用合并樹(shù)的根據(jù)示例方面的示例動(dòng)態(tài)流路由封包轉(zhuǎn)發(fā)方法。

圖14a至圖14d為一系列的示意圖，說(shuō)明了動(dòng)態(tài)流管理的示例緩沖管理方面。

圖15為根據(jù)示例方面的例示動(dòng)態(tài)流合并方法的狀態(tài)轉(zhuǎn)換圖。

具體實(shí)施方式

一般而言，本公開(kāi)提供了強(qiáng)健的網(wǎng)絡(luò)數(shù)據(jù)接入環(huán)境，它可被用以提供需要的數(shù)據(jù)流量管理，即使是在對(duì)數(shù)據(jù)有不尋常的高度需求的突然情況下。特別是，本公開(kāi)方法利用動(dòng)態(tài)流合并(DSM)技術(shù)，其中相同的數(shù)據(jù)流會(huì)在通訊網(wǎng)絡(luò)內(nèi)的不同節(jié)點(diǎn)或路由器處被合并或共享，以保留網(wǎng)絡(luò)資源(例如處理與帶寬資源)，而且仍在不同時(shí)間或“按需”分配給不同的用戶。更特別地，在此示出的方法可使用內(nèi)容識(shí)別符來(lái)幫助確定兩個(gè)視頻流是否相同并且共享相同數(shù)據(jù)，不管原本是否被存儲(chǔ)在不同服務(wù)器上以及具有不同的服務(wù)器目的地。類(lèi)似于URL，內(nèi)容識(shí)別符是被編碼于視頻流等中以助于重復(fù)檢測(cè)。

先參閱圖1，示例網(wǎng)絡(luò)計(jì)算裝置30(它可以是互聯(lián)網(wǎng)，或其他的計(jì)算器網(wǎng)絡(luò)節(jié)點(diǎn)，或服務(wù)器)例如示意性地包括存儲(chǔ)器31以及耦接至存儲(chǔ)器的處理器32。作為示例，處理器32可利用微處理器來(lái)被實(shí)施，而存儲(chǔ)器可包括具有計(jì)算機(jī)可執(zhí)行指令的非瞬時(shí)計(jì)算機(jī)可讀取介質(zhì)，以使處理器執(zhí)行在此所述的操作。

更特別地，處理器32可以用于按需從不同數(shù)據(jù)源接收要被中繼到不同目的地的多個(gè)數(shù)據(jù)流，其中每個(gè)數(shù)據(jù)流具有與其相關(guān)聯(lián)的各自的內(nèi)容識(shí)別符。處理器32可基于與其相關(guān)聯(lián)的所述各自的內(nèi)容識(shí)別符來(lái)確定對(duì)于第一目的地的數(shù)據(jù)流的第一個(gè)何時(shí)與對(duì)于第二目的地的數(shù)據(jù)流的第二個(gè)共享相同的數(shù)據(jù)。處理器32可基于根據(jù)與其相關(guān)的各自的內(nèi)容識(shí)別符的第一和第二數(shù)據(jù)流分享相同的數(shù)據(jù)的確定，相應(yīng)地暫停將第二數(shù)據(jù)流中繼到第二目的地，并開(kāi)始將第一數(shù)據(jù)流中繼至第二目的地。

作為示例，內(nèi)容ID可由數(shù)據(jù)內(nèi)容供應(yīng)者針對(duì)其本身各自的數(shù)據(jù)文件指定。舉例而言，大的視頻供應(yīng)者(例如“亞馬遜”(Amazon)或YouTube)可具有存儲(chǔ)在不同服務(wù)器上的相同視頻檔案的多個(gè)副本，用于服務(wù)在多個(gè)位置中或來(lái)自多個(gè)位置的用戶的冗余或效率，而且這些供應(yīng)者會(huì)對(duì)這些文件使用其本身各自的內(nèi)容ID方案。

另一種方法是，網(wǎng)絡(luò)供應(yīng)者(例如蜂窩或電信網(wǎng)絡(luò)供應(yīng)者)可對(duì)數(shù)據(jù)文件指定內(nèi)容ID，或是利用網(wǎng)絡(luò)將ID范圍分配給各自的內(nèi)容供應(yīng)者，以將它們的檔案流傳輸給用戶。類(lèi)似地，指定的內(nèi)容ID注冊(cè)服務(wù)可為以其注冊(cè)的數(shù)據(jù)文件提供內(nèi)容ID，例如類(lèi)似于域名注冊(cè)。以此方式，從不同的內(nèi)容供應(yīng)者(例如“網(wǎng)飛”(Netflix)、“葫蘆”(Hulu)等)經(jīng)由網(wǎng)絡(luò)而流傳輸?shù)南嗤募?huì)針對(duì)不同用戶而被合并或共享，用戶甚至不會(huì)知道。舉例而言，若第一用戶正在通過(guò)有線運(yùn)營(yíng)商的網(wǎng)絡(luò)上從“網(wǎng)飛”流傳輸電影，而第二用戶也通過(guò)有線運(yùn)營(yíng)商的網(wǎng)絡(luò)上從“葫蘆”流傳輸相同的電影，則有線運(yùn)營(yíng)商的服務(wù)器會(huì)暫?！昂J”流，且反而對(duì)第二用戶服務(wù)“網(wǎng)飛”流，即使所述第二用戶并非“網(wǎng)飛”訂閱者。

在一個(gè)示例實(shí)施例中，內(nèi)容ID在所有內(nèi)容供應(yīng)者間都是唯一的。亦即，供應(yīng)者可指定同一內(nèi)容ID給他們的視頻文件中的許多個(gè)視頻文件。然而，分配給視頻供應(yīng)者的內(nèi)容ID的集合可以是互相排斥的，亦即不會(huì)有兩個(gè)內(nèi)容供應(yīng)者共享相同的內(nèi)容ID。有些供應(yīng)者會(huì)故意針對(duì)他們提供的相同視頻(例如流行電影)共享內(nèi)容ID。但在示例實(shí)施例中，只有具有相同內(nèi)容的視頻文件會(huì)攜帶相同的內(nèi)容ID。

作為對(duì)比，在此示出的動(dòng)態(tài)流合并技術(shù)并不會(huì)與其他現(xiàn)有的技術(shù)(例如內(nèi)容分布網(wǎng)絡(luò)(CDN)和對(duì)等網(wǎng)絡(luò)(P2P)流傳輸)混淆。更特別地，本方法提供了智能型網(wǎng)絡(luò)覆蓋，其中可減少或消除重復(fù)的流量。更特別地參閱圖2至圖3，互聯(lián)網(wǎng)消耗全世界能源使用量的大約5％左右。此外，估計(jì)約有90％的互聯(lián)網(wǎng)流量是視頻、而且?guī)缀跏恰叭哂唷钡摹Ｗ鳛槭纠?，大概?0％的最熱門(mén)視頻占了YouTube上總觀看量的90％。因此，冗余數(shù)據(jù)會(huì)在互聯(lián)網(wǎng)上重復(fù)傳送。本方法提供了一種流量去重復(fù)技術(shù)，以供在視頻源(視頻服務(wù)器，或CDN中的代理服務(wù)器)及客戶端之間更有效率的網(wǎng)絡(luò)通訊。應(yīng)注意的是，DSM也可直接被應(yīng)用于實(shí)體網(wǎng)絡(luò)(而不是覆蓋網(wǎng)絡(luò))。

根據(jù)一個(gè)示例實(shí)施方式，裝置30可被部署為智能型覆蓋網(wǎng)絡(luò)方法的部分，亦即作為部署于互聯(lián)網(wǎng)主干上的“智能型路由器”。舉例而言，在圖2至圖4的示例中，節(jié)點(diǎn)N2可被實(shí)施作為智能型路由器。每個(gè)視頻流S₁、S₂在一系列的智能型路由器或節(jié)點(diǎn)N1、N2上從視頻源被傳送到客戶端。在任何兩個(gè)智能型路由器N1、N2之間傳送的TCP封包仍可以根據(jù)IP協(xié)議而傳送，如同在其他覆蓋網(wǎng)絡(luò)設(shè)計(jì)中。當(dāng)智能型路由器辨識(shí)出正通過(guò)的兩個(gè)視頻流實(shí)際上是相同視頻時(shí)，它會(huì)在稍后某時(shí)刻為較新的流重復(fù)使用來(lái)自較舊流的數(shù)據(jù)封包，并且請(qǐng)求上游的智能型路由器停止傳送這個(gè)較新流以節(jié)省網(wǎng)絡(luò)資源。應(yīng)注意的是，除了互聯(lián)網(wǎng)主干之外，智能型路由器還可被部署在網(wǎng)絡(luò)中的任意處。一般而言，最有利的是將它們布置在具有高流量的位置處以獲取及利用重復(fù)的流。覆蓋設(shè)計(jì)是實(shí)際的部署策略，因?yàn)槲覀儫o(wú)法一次取代互聯(lián)網(wǎng)中的所有路由器。隨著舊的路由器被智能型路由器取代，覆蓋網(wǎng)絡(luò)即可遞增地成長(zhǎng)。

在所述示例中，節(jié)點(diǎn)N1注意到流S₁和S₂有相同的視頻或內(nèi)容ID(在此示例中為“CID123”)以及對(duì)下一個(gè)躍程的相同ID(亦即節(jié)點(diǎn)N2的ID)。因此，節(jié)點(diǎn)N1通知節(jié)點(diǎn)N2它要在片段5處開(kāi)始合并兩個(gè)流的意圖。響應(yīng)于此通知，節(jié)點(diǎn)N2開(kāi)始將來(lái)自S₁的片段保留在存儲(chǔ)器中，例如FIFO緩沖器。在從流S₂轉(zhuǎn)發(fā)片段4之后，節(jié)點(diǎn)N2繼續(xù)通過(guò)重復(fù)使用緩沖器中所存儲(chǔ)的、來(lái)自流S₁的這些片段而轉(zhuǎn)發(fā)后續(xù)的片段(亦即片段5、6、7等)，而且流S₂會(huì)被阻擋或中斷。因此，在此示例中，S₂與S₁合并(S₁→S₂)。更一般而言，會(huì)是S₁→S₂→S₃→…→S_k，以保留k-1個(gè)流。

在每個(gè)智能型路由器的這種機(jī)會(huì)性流量去重復(fù)方法將覆蓋的獨(dú)立流動(dòng)態(tài)地合并到流傳輸樹(shù)中，這不同于多播樹(shù)。多播樹(shù)的所有客戶端都是在視頻流中相同的播放點(diǎn)處。相較之下，根據(jù)本方法的流傳輸樹(shù)的客戶端可以是在相同視頻流中的他們本身各自的播放點(diǎn)處。這種新的能力能夠開(kāi)發(fā)對(duì)于視頻點(diǎn)播(video on demand)的多播的效率。

此外，也應(yīng)注意的是，所提出的覆蓋與P2P流傳輸技術(shù)不同。在P2P設(shè)計(jì)中的對(duì)等點(diǎn)(例如BitTorrent)從給定視頻的不同對(duì)等點(diǎn)處接收它的數(shù)據(jù)。本方法的智能型路由器根據(jù)路由算法從指定的智能型路由器接收給定的視頻流。換言之，本方法是路由技術(shù)，而非文件共享技術(shù)。此外，P2P流傳輸并非如本方法中的去重復(fù)(de-duplication)技術(shù)，而且不會(huì)減少網(wǎng)絡(luò)流量。

此外，也應(yīng)注意本方法和CDN之間的差異。亦即，本方法是一種網(wǎng)絡(luò)通訊技術(shù)，而非緩存技術(shù)。不同的流以線路速率合并于路由器結(jié)構(gòu)中。當(dāng)流傳輸樹(shù)通信期終止時(shí)，視頻數(shù)據(jù)不需要被緩存到智能型路由器中。相反的，視頻會(huì)根據(jù)某些緩存取代策略(例如LRU)而被緩存于CDN中達(dá)一段非常久的期間。此外，使用代理服務(wù)器并不會(huì)節(jié)省這些服務(wù)器和它們的用戶之間的帶寬(亦即，并無(wú)流量去重復(fù)作用)。然而，根據(jù)本發(fā)明方法，這可利用區(qū)域性網(wǎng)絡(luò)中的智能型路由器達(dá)成，且/或可節(jié)省互聯(lián)網(wǎng)主干。

現(xiàn)將進(jìn)一步參閱圖4至圖9說(shuō)明示例合并場(chǎng)景。剛開(kāi)始，流S₁在給定的網(wǎng)絡(luò)節(jié)點(diǎn)處以封包P₁開(kāi)始(圖4)。在稍后的時(shí)刻，第二流S₂以封包P₁開(kāi)始，第一流S₁在所述點(diǎn)則達(dá)到封包P₁₀₀。在基于第一與第二流S₁與S₂的各自的內(nèi)容ID而辨識(shí)出覆蓋時(shí)，流S₁會(huì)被記錄(例如于FIFO緩沖器中)以準(zhǔn)備進(jìn)行流合并，如圖6所示。更特別地，數(shù)據(jù)是以封包P₁₀₀開(kāi)始存儲(chǔ)于緩沖器中，并且一旦第二流S₂趕上封包P₁₀₀時(shí)，第二流S₂即被封鎖或中斷，并且現(xiàn)在傳送來(lái)自緩沖器的數(shù)據(jù)封包(它們是存儲(chǔ)自第一數(shù)據(jù)流S₂)來(lái)取代以封包P₁₀₀開(kāi)始的第二流S₂，如圖7所示。這會(huì)發(fā)生直到第二流S₂達(dá)到來(lái)自第一流S₁的最后封包為止，其將正常結(jié)束(圖8)。在可選的實(shí)施方式中(圖9)，當(dāng)?shù)谝涣鱏₁早終止或結(jié)束，第二流S₂會(huì)被解除封鎖并且從當(dāng)前位置繼續(xù)，在所述示例中所述當(dāng)前位置是在封包P₃₅₀處。

上述方法因此可用以實(shí)施視頻流樹(shù)，其中視頻源可被連接至很多目的地，如同傳統(tǒng)的視頻流傳輸實(shí)施方式。然而，上述智能型路由器方法有利地為較新的流重復(fù)使用較舊的流的數(shù)據(jù)，從而控制冗余。此外，合并程序可持續(xù)地發(fā)展以為新請(qǐng)求服務(wù)并適應(yīng)用戶移動(dòng)性的動(dòng)態(tài)。這種機(jī)會(huì)性方法有助于節(jié)省珍貴的無(wú)線資源并增進(jìn)網(wǎng)絡(luò)的強(qiáng)健性，而不需要與視頻源或用戶協(xié)作。

另外參閱圖10的圖表100，為了說(shuō)明以DSM方法達(dá)到的增益，執(zhí)行使無(wú)線網(wǎng)格中的一組節(jié)點(diǎn)為可用的實(shí)驗(yàn)。使用線網(wǎng)格拓樸來(lái)允許最大數(shù)量的躍程(通常是在較大的網(wǎng)格網(wǎng)絡(luò)中遇到)。網(wǎng)格網(wǎng)關(guān)通過(guò)以太網(wǎng)而連接至校園網(wǎng)絡(luò)，并且啟用NAT(網(wǎng)絡(luò)地址轉(zhuǎn)換)服務(wù)。在示例中，有n+1個(gè)用戶，其中一個(gè)請(qǐng)求視頻x，而所有其他用戶在不同時(shí)間請(qǐng)求不同的視頻y。這些用戶被隨機(jī)地放置于節(jié)點(diǎn)n2、n3與n4間。在圖表100中，兩條繪線101與102各自顯示了實(shí)施DSM(DSM)與不實(shí)施DSM(Non-DSM)的視頻x的數(shù)據(jù)速率。如圖表線102所示，若無(wú)DSM，則對(duì)于視頻y的漸增需求會(huì)產(chǎn)生與視頻x相關(guān)聯(lián)的延遲，因此視頻x基本上是無(wú)法觀看的。

根據(jù)關(guān)于網(wǎng)絡(luò)壓力的另一實(shí)驗(yàn)，現(xiàn)參閱圖11的圖表110加以說(shuō)明，對(duì)于相同視頻產(chǎn)生有20個(gè)請(qǐng)求。圖表110中的繪線顯示了在網(wǎng)絡(luò)中每個(gè)鏈路處所傳送的累積數(shù)據(jù)。如繪線所示，無(wú)DSM時(shí)會(huì)有較多流量，并且在最接近網(wǎng)關(guān)處其變成完全飽和。另一方面，有DSM時(shí)，接近網(wǎng)關(guān)的節(jié)點(diǎn)未飽和，并且可容納更多的網(wǎng)格節(jié)點(diǎn)來(lái)支持甚至更多的流量。

網(wǎng)關(guān)負(fù)荷量的減少可產(chǎn)生較佳的網(wǎng)絡(luò)利用，并可允許較大的網(wǎng)絡(luò)部署。如上述說(shuō)明，DSM在網(wǎng)關(guān)帶寬上的需求相當(dāng)?shù)?，其留下許多帶寬供其他應(yīng)用程序與用戶使用。由于DSM并不會(huì)耗盡網(wǎng)關(guān)容量，因此可允許網(wǎng)絡(luò)中的每個(gè)網(wǎng)格節(jié)點(diǎn)參與數(shù)據(jù)轉(zhuǎn)發(fā)。換言之，更遠(yuǎn)離網(wǎng)關(guān)的用戶也會(huì)使用網(wǎng)絡(luò)并體驗(yàn)到優(yōu)良性能。相反的，無(wú)DSM方式則會(huì)快速耗盡網(wǎng)關(guān)。嚴(yán)重?fù)頂D會(huì)導(dǎo)致接近網(wǎng)關(guān)的許多封包丟失。因此，盡管在網(wǎng)絡(luò)中存在有大量的活動(dòng)流，但是更遠(yuǎn)離網(wǎng)關(guān)的網(wǎng)格節(jié)點(diǎn)仍幾乎無(wú)數(shù)據(jù)可轉(zhuǎn)發(fā)。

從前述結(jié)果可知DSM是用于流傳輸樹(shù)的漸增架構(gòu)與動(dòng)態(tài)維護(hù)的分布式技術(shù)，它涉及相對(duì)少的開(kāi)銷(xiāo)，并且不需要與視頻源或用戶協(xié)作。此外，具有動(dòng)態(tài)流合并能力的無(wú)線網(wǎng)格接入網(wǎng)絡(luò)也會(huì)更強(qiáng)健、更有效率、并且對(duì)于大規(guī)模部署可擴(kuò)展更多。

此外，關(guān)于典型對(duì)象(例如視頻)識(shí)別符(例如URL)，駐留于不同服務(wù)器上的相同視頻并不會(huì)被辨識(shí)為具有相同內(nèi)容。然而，利用本方法，相同的內(nèi)容識(shí)別符可有利地允許給定視頻的不同副本被辨識(shí)為相同項(xiàng)目的重復(fù)，并從而為流量去重復(fù)提供更多機(jī)會(huì)。

現(xiàn)另外轉(zhuǎn)向圖12a-12d，現(xiàn)將說(shuō)明示例DSM方法的進(jìn)一步實(shí)施方面。隨著連網(wǎng)技術(shù)的快速發(fā)展，如今視頻數(shù)據(jù)已經(jīng)變成許多應(yīng)用程序中不可分開(kāi)的部分。特別是，視頻點(diǎn)播(Video on demand,VoD)是例如數(shù)字圖書(shū)館、遠(yuǎn)距學(xué)習(xí)、協(xié)作訓(xùn)練、公開(kāi)信息系統(tǒng)、電子商務(wù)及娛樂(lè)(僅舉幾例)等重要應(yīng)用程序的核心技術(shù)。典型的VoD服務(wù)允許遠(yuǎn)程用戶從存儲(chǔ)在一個(gè)或多個(gè)服務(wù)器上的大量視頻中回放視頻。響應(yīng)于服務(wù)請(qǐng)求，視頻服務(wù)器以同步視頻流的方式對(duì)用戶傳送視頻。

無(wú)線技術(shù)已經(jīng)成為近年來(lái)最變革性與有威力的技術(shù)之一。利用例如802.11和WiMax的寬帶無(wú)線技術(shù)，無(wú)線網(wǎng)格網(wǎng)絡(luò)(具有網(wǎng)格拓樸的移動(dòng)自組織網(wǎng)絡(luò)(MANET)的特殊情況)已經(jīng)被使用作為用于在住宅、商業(yè)、甚至是全城市的網(wǎng)絡(luò)中提供寬帶數(shù)據(jù)接入的邊緣技術(shù)。在WMN中，無(wú)線網(wǎng)格接入路由器形成了類(lèi)網(wǎng)格無(wú)線主干網(wǎng)絡(luò)，它可允許終端用戶通過(guò)網(wǎng)格網(wǎng)關(guān)在互聯(lián)網(wǎng)或區(qū)域網(wǎng)中接入服務(wù)。用戶可通過(guò)無(wú)線網(wǎng)格主干來(lái)接入VoD服務(wù)(例如IPTV服務(wù)器或視頻共享服務(wù)器)。為求方便，這種網(wǎng)絡(luò)被稱(chēng)為無(wú)線網(wǎng)格接入(WMA)環(huán)境。特別是，需要使網(wǎng)格網(wǎng)絡(luò)中的流量達(dá)最小化，以實(shí)現(xiàn)設(shè)計(jì)更強(qiáng)健的WMA環(huán)境的可擴(kuò)展方法。

針對(duì)每個(gè)視頻服務(wù)請(qǐng)求使用專(zhuān)用的服務(wù)器流對(duì)于無(wú)線環(huán)境而言是非常昂貴的。當(dāng)有大量用戶想要流行內(nèi)容時(shí)，它也具有受限的可擴(kuò)展性。也會(huì)想要有可以承受特定視頻的需求中的突然涌入的需求的強(qiáng)健無(wú)線接入環(huán)境。當(dāng)這種事件發(fā)生，是不希望對(duì)于相關(guān)視頻的需求的實(shí)質(zhì)增加會(huì)顯著影響對(duì)于其他一般視頻的正常接入。

為了處理這個(gè)問(wèn)題，可利用多播技術(shù)以允許許多用戶共享流行的服務(wù)器流。作為有線環(huán)境的示例，修補(bǔ)技術(shù)可允許新的服務(wù)請(qǐng)求通過(guò)緩沖來(lái)自多播、正在進(jìn)行的流來(lái)利用現(xiàn)有的多播，同時(shí)針對(duì)缺少的視頻部分則從服務(wù)器播放新的“追趕”流。一旦被稱(chēng)為修補(bǔ)流的追趕流用盡，回放機(jī)制會(huì)切換為回放先前緩存于本地緩沖器中的多播數(shù)據(jù)，亦即共享多播數(shù)據(jù)。由于修補(bǔ)流非常短，它們并不昂貴且為客戶端提供了可擴(kuò)展的方式來(lái)共享進(jìn)行中的多播。然而這種技術(shù)無(wú)法有效地用于WMA環(huán)境，因?yàn)楫?dāng)前的VoD服務(wù)器(例如YouTube網(wǎng)站的視頻服務(wù)器)無(wú)法控制也無(wú)法支持邊緣的WMN中多播。DSM技術(shù)可有利地被用以在WMA環(huán)境中有效支持VoD應(yīng)用，其中視頻服務(wù)器并不直接附加至WMN(例如，視頻服務(wù)器是在互聯(lián)網(wǎng)上)。

使用DSM來(lái)支持WMN中VoD的多播可漸增地形成多播群組，并且可適應(yīng)地以分散形式在網(wǎng)格網(wǎng)絡(luò)中執(zhí)行路由，而不涉及VoD服務(wù)器。當(dāng)服務(wù)器接收視頻請(qǐng)求時(shí)，它為每一用戶分配專(zhuān)用流。然而，當(dāng)網(wǎng)絡(luò)節(jié)點(diǎn)辨識(shí)出通過(guò)它的兩個(gè)視頻流具有相同的視頻ID時(shí)，這兩個(gè)流會(huì)被合并為單一流而保留節(jié)點(diǎn)資源。因此，多播機(jī)制對(duì)于互聯(lián)網(wǎng)中的VoD服務(wù)器而言是透明的。DSM與傳統(tǒng)多播的不同處如下：在傳統(tǒng)技術(shù)中，是在服務(wù)器處作出要將用戶群組化為多播群組的確定，而DSM在不知曉服務(wù)器的情況下動(dòng)態(tài)地合并網(wǎng)絡(luò)中正在進(jìn)行的流。換言之，傳統(tǒng)的多播依賴(lài)服務(wù)器上集中化的控制邏輯，而DSM是一種分布式控制技術(shù)，并且可更好地定位以作出網(wǎng)絡(luò)感知協(xié)議的確定。

雖然下文說(shuō)明的是VoD應(yīng)用，但可理解DSM技術(shù)也可用于其他應(yīng)用，例如現(xiàn)場(chǎng)直播。在這種環(huán)境中，最初接收來(lái)自廣播源的分離的視頻流的新的用戶將會(huì)迅速看見(jiàn)在WMA環(huán)境中與另一流合并的這個(gè)流。

為了促進(jìn)流在它們的視頻中不同播放點(diǎn)的合并，我們?yōu)楹喜⒛康亩x了視頻片段作為單位。片段比網(wǎng)絡(luò)的最大傳輸單元更大。舉例而言，片段可以是視頻中的圖片群組(GOP)或用戶定義的塊(chunk)。在不失一般性的情況下，我們將視頻流建模為一序列的非相同大小片段，并且使用sid(片段id)來(lái)表示流中每一個(gè)片段的序列號(hào)。

DSM是一種網(wǎng)絡(luò)內(nèi)流合并技術(shù)。為了在不同的視頻通信期間共享數(shù)據(jù)片段(由于流合并)，可對(duì)網(wǎng)格節(jié)點(diǎn)提供每一個(gè)數(shù)據(jù)封包的sid、流ID以及視頻ID(vid)。此外，內(nèi)容ID可被用以辨識(shí)同一視頻的重復(fù)副本，如上文所述。網(wǎng)格網(wǎng)關(guān)可將這類(lèi)信息封裝在每個(gè)數(shù)據(jù)封包中。舉例而言，可針對(duì)RTP(實(shí)時(shí)傳輸協(xié)議)封包確定這些識(shí)別符如下。RTP標(biāo)頭中的序列號(hào)字段可針對(duì)作為sid的使用被調(diào)整。由于SSRC(同步源識(shí)別符)字段唯一地識(shí)別了來(lái)自在線服務(wù)器的RTP流的源，SSRC可結(jié)合源IP地址而被使用作為流ID。最后，URL(統(tǒng)一資源定位符)唯一地識(shí)別視頻文件。

網(wǎng)格網(wǎng)關(guān)可以維護(hù)轉(zhuǎn)換表，以將每一個(gè)正在進(jìn)行的視頻通信期的URL映射到視頻ID中。當(dāng)給定視頻不再被使用于網(wǎng)絡(luò)中時(shí)，它的當(dāng)前視頻ID就不再被需要，而可被循環(huán)以及未來(lái)用于另一視頻。利用每一個(gè)網(wǎng)絡(luò)包頭中的前述信息，DSM能夠在網(wǎng)絡(luò)層中識(shí)別出正在進(jìn)行的流及其片段，并基于所述信息處理封包。

圖12a至圖12d說(shuō)明了簡(jiǎn)單的2-流合并情況。流S1與S2是通過(guò)節(jié)點(diǎn)N1的同一視頻的兩個(gè)數(shù)據(jù)流。合并是發(fā)生于兩個(gè)階段，分別如圖12a與圖12b所示。在這個(gè)示例中，節(jié)點(diǎn)N1目前接收流S1上的片段5(亦即，從S1讀取的封包的最高sid為5)與流S2上的片段2。在階段1中(圖12a)，節(jié)點(diǎn)N1注意到這兩個(gè)視頻流具有相同的視頻ID，并且通知節(jié)點(diǎn)N2想要合并這兩個(gè)流的意圖。亦即，對(duì)于節(jié)點(diǎn)N2而言，到達(dá)流S1的數(shù)據(jù)封包在下游中實(shí)際上是流S1與S2兩者的“多播”封包，如圖12b所示。作為響應(yīng)，節(jié)點(diǎn)N2開(kāi)始在本地FIFO緩沖器中節(jié)省抵達(dá)于流S1上的封包，從sid等于5的封包開(kāi)始。在階段2(圖12b)，在節(jié)點(diǎn)N1轉(zhuǎn)發(fā)流S2上的片段2、3與4的封包之后，其停止轉(zhuǎn)發(fā)流S2的封包，盡管數(shù)據(jù)還持續(xù)到達(dá)(亦即，流S2被節(jié)點(diǎn)N1封鎖)。在同一時(shí)刻，節(jié)點(diǎn)N2如同之前般繼續(xù)轉(zhuǎn)發(fā)流S1上的數(shù)據(jù)，同時(shí)它也將抵達(dá)的視頻片段附加到FIFO緩沖器的后方。因?yàn)榇司彌_器被饋送來(lái)自流S1的數(shù)據(jù)，節(jié)點(diǎn)N2亦從此FIFO緩沖器的前方取回封包(從片段5的封包開(kāi)始)，并將它們于S2上轉(zhuǎn)發(fā)至下游。

在上述示例中，若流S1被它的客戶端終止(圖12c)，或流S1的路徑通過(guò)單播路由協(xié)議而從節(jié)點(diǎn)N1轉(zhuǎn)向，流S2的客戶端就不再能夠從節(jié)點(diǎn)N1接收它的數(shù)據(jù)。舉例而言，這種情況會(huì)發(fā)生在當(dāng)節(jié)點(diǎn)N1嘗試要接收流S1上的片段20時(shí)，如圖12c所示。由于在這個(gè)時(shí)刻，節(jié)點(diǎn)N1在它的緩沖器中已經(jīng)具有片段17、18與19，因此節(jié)點(diǎn)N1可繼續(xù)在流S2上轉(zhuǎn)發(fā)這些片段至下游。當(dāng)這個(gè)FIFO緩沖器被耗盡時(shí)，節(jié)點(diǎn)N1可從片段20處開(kāi)始恢復(fù)抵達(dá)流S2上的封包的數(shù)據(jù)轉(zhuǎn)發(fā)(亦即，恢復(fù)正常的轉(zhuǎn)發(fā))，如圖12d所示。我們注意到流S2的客戶端仍取得所有的視頻片段，并且不會(huì)受到在節(jié)點(diǎn)N1處的改變影響。類(lèi)似地，如果流S2是在節(jié)點(diǎn)N1處停止，則節(jié)點(diǎn)N1會(huì)通過(guò)通知節(jié)點(diǎn)N2來(lái)自流S1的封包也不再是下游中流S2的“多播封包”而簡(jiǎn)單地取消合并。

流合并對(duì)于網(wǎng)絡(luò)的動(dòng)態(tài)而言是相對(duì)地彈性的。如上述示例所示，合并和取消兩者都僅涉及兩個(gè)節(jié)點(diǎn)(且在某些實(shí)施例中，這可由單一節(jié)點(diǎn)執(zhí)行)。一般而言，多個(gè)流可被本地合并以共享無(wú)線帶寬。此外，可并行地在每個(gè)網(wǎng)格路由器處自動(dòng)運(yùn)行相同程序，并且這些流將通過(guò)分布式控制邏輯而于整個(gè)網(wǎng)絡(luò)中合并，以形成“多播”樹(shù)。

利用兩個(gè)節(jié)點(diǎn)進(jìn)行流合并會(huì)具有某些優(yōu)點(diǎn)。當(dāng)兩個(gè)流通過(guò)兩個(gè)連續(xù)節(jié)點(diǎn)時(shí)，合并是在下方節(jié)點(diǎn)執(zhí)行，并且因此可在這兩個(gè)節(jié)點(diǎn)之間節(jié)省一個(gè)流。兩個(gè)流中的“較新的”在合并之后繼續(xù)抵達(dá)上方節(jié)點(diǎn)，上方節(jié)點(diǎn)并不會(huì)將此較新的流中繼到下方節(jié)點(diǎn)。讓此流繼續(xù)抵達(dá)上方節(jié)點(diǎn)的原因是為了在較舊的流(較新的流是于下方節(jié)點(diǎn)上中繼)提早終止時(shí)(亦即，觀看者在視頻結(jié)束之前就確定要停止視頻)能快速恢復(fù)將此較新的流中繼到下方節(jié)點(diǎn)?？焖倩謴?fù)中繼是要避免在目的地的視頻回放的抖動(dòng)。此輸入也與上述的解除封鎖有關(guān)。

合并樹(shù)(M-tree)可被用以支持每個(gè)網(wǎng)格節(jié)點(diǎn)處的流合并。給定兩個(gè)網(wǎng)格節(jié)點(diǎn)之間的數(shù)據(jù)傳輸，我們稱(chēng)此傳輸?shù)陌l(fā)送者為上游節(jié)點(diǎn)(UN)，并稱(chēng)接收者為下游節(jié)點(diǎn)(DN)。每個(gè)網(wǎng)格節(jié)點(diǎn)都使用進(jìn)來(lái)的M-tree(iM-tree)與離開(kāi)的M-tree(oM-tree)來(lái)分別記錄與每個(gè)進(jìn)來(lái)的流及每個(gè)離開(kāi)的流有關(guān)的信息。M-tree的根節(jié)點(diǎn)代表正被接收或傳送的實(shí)際流。節(jié)點(diǎn)是被稱(chēng)為其子代在M-tree中的合并者。子代節(jié)點(diǎn)被稱(chēng)為是母節(jié)點(diǎn)的被合并者。樹(shù)型結(jié)構(gòu)通知網(wǎng)格節(jié)點(diǎn)對(duì)應(yīng)于被合并者的流已經(jīng)與對(duì)應(yīng)于合并者的流合并，亦即，合并者流“獲取”了被合并者流。因此，這些被合并者流需要重新使用來(lái)自合并者流的視頻數(shù)據(jù)。也就是說(shuō)，它們共享了“多播”流。

在每個(gè)網(wǎng)絡(luò)節(jié)點(diǎn)的數(shù)據(jù)轉(zhuǎn)發(fā)可根據(jù)它的oM-tree執(zhí)行如下。只有在oM-tree的根節(jié)點(diǎn)中所指示的流需要被轉(zhuǎn)發(fā)。示例則如圖13a與圖13b所說(shuō)明。如圖13a所示，節(jié)點(diǎn)N1具有來(lái)自三個(gè)不同的上游節(jié)點(diǎn)的三個(gè)進(jìn)來(lái)的流S1、S2與S3。這三個(gè)流共享相同的下一躍程，亦即節(jié)點(diǎn)N2。在通過(guò)節(jié)點(diǎn)N2之后，流S1與S2走到節(jié)點(diǎn)N3，而流S3走到節(jié)點(diǎn)N4。在這種情況中，這三個(gè)視頻流是在節(jié)點(diǎn)N1與N2之間的鏈路處被合并。流S1與S2繼續(xù)在節(jié)點(diǎn)N2與N3之間的鏈路被合并，而流S3則轉(zhuǎn)向節(jié)點(diǎn)N4。

這些活動(dòng)是在M-tree的幫助下完成，如下文所述。如圖13b所示，兩節(jié)點(diǎn)N1與N2都可具有在某單播路由協(xié)議上的處理器上運(yùn)行的DSM軟件。Pi(i＝1,2,3)表示針對(duì)流Si(i＝1,2,3)正在轉(zhuǎn)發(fā)的視頻片段的封包。節(jié)點(diǎn)1中的這三個(gè)iM-tree代表它有三個(gè)進(jìn)來(lái)的流。然而，節(jié)點(diǎn)N1僅具有一個(gè)oM-tree，且它僅需要為流S1轉(zhuǎn)發(fā)數(shù)據(jù)，如同這個(gè)oM-tree的根節(jié)點(diǎn)中所表示。在此例中，節(jié)點(diǎn)N2的iM-tree與節(jié)點(diǎn)N1的oM-tree相同。這允許節(jié)點(diǎn)N2可將進(jìn)來(lái)的流解譯為合并者流S1及它的被合并者(流S2與S3)的多播流。由于在節(jié)點(diǎn)N2處存在有兩個(gè)oM-tree，需要為這兩個(gè)oM-tree的根部中所指示的兩個(gè)流S1與S3轉(zhuǎn)發(fā)數(shù)據(jù)。封包P1是在流S1上轉(zhuǎn)發(fā)。oM-tree指示這個(gè)封包也要給被合并者流S2。節(jié)點(diǎn)N2也在流S3上轉(zhuǎn)發(fā)這個(gè)封包P3的副本。為了區(qū)別實(shí)際合并者流(例如流S1)的封包與被重新使用于被合并者流(例如流S2)的相同封包，我們并未說(shuō)明作為圖13中的離開(kāi)封包的封包P2。

現(xiàn)在將參照?qǐng)D14a至圖14d來(lái)說(shuō)明示例緩沖器管理技術(shù)以及DSM的準(zhǔn)入控制。令“塊”(chunk)作為緩沖器管理的存儲(chǔ)器單元。存儲(chǔ)器塊具有視頻片段的平均大小。在不失一般性的情況下，假設(shè)是合并兩個(gè)視頻流S1與S2的情形，其具有d個(gè)視頻片段的回放距離。亦即，在視頻服務(wù)器為流S1送出d個(gè)視頻片段之后，它開(kāi)始為流S2傳送數(shù)據(jù)。為了要在網(wǎng)格節(jié)點(diǎn)N1處合并流S2與流S1，節(jié)點(diǎn)N1需要維持有d個(gè)塊的容量的FIFO緩沖器，以保留抵達(dá)于流S1上的視頻片段而供于某時(shí)間之后在流S2上傳輸?shù)较掠喂?jié)點(diǎn)。

在所述示例中，節(jié)點(diǎn)N1、N2的左手側(cè)上的箭頭是代表流S1，往右側(cè)的箭頭描寫(xiě)流S2。這個(gè)例子的初始狀態(tài)如同圖14a所示。在這里，回放距離為3個(gè)視頻片段的兩個(gè)流正在通過(guò)節(jié)點(diǎn)N2。為了合并這兩個(gè)流，節(jié)點(diǎn)N2動(dòng)態(tài)地分配有3個(gè)塊的容量的FIFO緩沖器，如圖14b所示。在這個(gè)圖式中，節(jié)點(diǎn)N2繼續(xù)為流S1與S2接收并轉(zhuǎn)發(fā)視頻片段。然而，節(jié)點(diǎn)N2也將抵達(dá)于流S1上的進(jìn)來(lái)的片段7存儲(chǔ)至FIFO緩沖器。當(dāng)FIFO已滿，此合并處理的最后步驟如同圖14c所示。從這個(gè)時(shí)間起，節(jié)點(diǎn)N2會(huì)使用來(lái)自FIFO緩沖器的數(shù)據(jù)轉(zhuǎn)發(fā)視頻片段至下游中的流S2。在實(shí)施例中，是針對(duì)每個(gè)被合并者流使用專(zhuān)用的緩沖器，雖然也可使用其他技術(shù)以允許合并者的多個(gè)被合并者共享緩沖器。

在上述示例中，節(jié)點(diǎn)N2當(dāng)前可能不具有足夠的緩沖空間來(lái)容納合并請(qǐng)求。簡(jiǎn)單的先來(lái)先服務(wù)準(zhǔn)入控制策略被用來(lái)處理這種狀況。當(dāng)節(jié)點(diǎn)N1開(kāi)始與節(jié)點(diǎn)N2的合并請(qǐng)求時(shí)，若節(jié)點(diǎn)N2沒(méi)有足夠的緩沖空間來(lái)容納合并處理，則所述請(qǐng)求會(huì)被拒絕，且節(jié)點(diǎn)N1必須等待來(lái)自節(jié)點(diǎn)N2的合并通知，以于有較多的緩沖空間變成可用時(shí)再次嘗試。為了支持這個(gè)策略，節(jié)點(diǎn)N2維持針對(duì)等待中請(qǐng)求的等待區(qū)域。當(dāng)有較多的緩沖空間變?yōu)榭捎脮r(shí)，節(jié)點(diǎn)N2利用“最佳匹配”策略使用可用緩存空間來(lái)容納可能最大數(shù)量的等待中請(qǐng)求。

DSM可實(shí)施為在單播路由協(xié)議頂部上的非易失性計(jì)算器可讀介質(zhì)軟件模塊、或?yàn)閃MN中單播路由協(xié)議的非易失性計(jì)算器可讀介質(zhì)擴(kuò)展(例如軟件修補(bǔ))。DSM可從路由層為每個(gè)視頻流取得下一躍程節(jié)點(diǎn)的ID。這個(gè)信息可由WMN中使用的大多數(shù)單播路由協(xié)議提供，無(wú)論它們?cè)诰W(wǎng)格網(wǎng)絡(luò)中是維持完整路由、或是以逐一躍程的方式轉(zhuǎn)發(fā)封包。

表I通信期表中的字段

在DSM中，WMN中的每個(gè)節(jié)點(diǎn)會(huì)監(jiān)控目前通過(guò)節(jié)點(diǎn)的視頻流，并且維持具有用于這些流的每個(gè)的條目(entry)的通信期表。上表I列出會(huì)在通信期表中的某些字段。具體而言，在網(wǎng)格DSM中，WMN中的每個(gè)節(jié)點(diǎn)都監(jiān)控目前通過(guò)節(jié)點(diǎn)的視頻流，并且維持有用于流的每個(gè)的條目的通信期表。網(wǎng)格節(jié)點(diǎn)會(huì)將為每個(gè)流所接收到的最高sid存儲(chǔ)在字段“cur_sid”中。“merger”和“mergeelist”這兩個(gè)字段是用來(lái)實(shí)施M-tree概念，如下述。對(duì)于通信期表中所記錄的每個(gè)流S而言，“merger”字段記錄了S的合并者(若S當(dāng)前未在此節(jié)點(diǎn)的任何離開(kāi)鏈路處被任何流合并的話，則其可以是S本身)，而“mergeelist”字段則包括S的被合并者的列表(若S當(dāng)前在此節(jié)點(diǎn)的任何進(jìn)來(lái)鏈路處并未合并任何流的話，則其會(huì)是空)。舉例而言，讓我們考慮圖13a與圖13b中的節(jié)點(diǎn)N2。流S1的字段“merger”與字段“mergeelist”分別是流S1以及{S2,S3}。類(lèi)似地，流S2的字段“merger”與字段“mergeelist”分別是流S1以及空列表。一般而言，M-tree可比僅兩個(gè)層級(jí)具有更多。然而，只有根節(jié)點(diǎn)會(huì)對(duì)應(yīng)于正被接收或傳送的實(shí)際流。以下說(shuō)明通信期表中的其他字段。

兩項(xiàng)操作，也就是合并操作(Merge Operation)與取消操作(Cancel Operation)，可被用以增進(jìn)WMN中的流的動(dòng)態(tài)合并與分開(kāi)。合并操作在UN與DN之間的通訊鏈路處合并兩個(gè)流。UN與DN彼此協(xié)作以通過(guò)更新它們自己的通信期表來(lái)更新受影響的M-tree。給定正被合并的兩個(gè)流，具有較低cur-sid的流會(huì)被選擇作為被合并者，而另一個(gè)流即為合并者。令合并者為X，被合并者為Y。合并流X與Y需要在UN與DM之間的握手，如下所述。UN對(duì)DN發(fā)送合并請(qǐng)求消息，這個(gè)消息含有與合并者X及被合并者Y有關(guān)的信息。

兩種情況會(huì)產(chǎn)生。在第一種情況中，若DN準(zhǔn)許合并請(qǐng)求，其將Y加到通信期表中的X的“被合并者列表(mergeelist)”。DN接著會(huì)對(duì)UN返回“Merge ACK”(合并確認(rèn))消息。在接收到“Merge ACK”消息之后，UN就將通信期表中流Y的“合并者(merger)”字段設(shè)定為X。UN也將DN的地址記錄在Y的“merge_hop”字段中。這個(gè)字段是用于取消操作中的。另一方面，在第二種情況中，若合并請(qǐng)求無(wú)法被準(zhǔn)許，則DN會(huì)對(duì)UN發(fā)送“Merge NACK”消息。在接收到NANK之后，UN將不再試圖合并這兩個(gè)流，直到它接收到來(lái)自DN的通知為止。

當(dāng)合并操作成功時(shí)，分別位于合并者X與被合并者Y根部的兩個(gè)oM-tree會(huì)在UN處合并。類(lèi)似地，分別位于流X與Y根部的兩個(gè)iM-tree會(huì)在DN處合并。取消操作的目的在于中斷先前合并操作所建立的合并者(例如流X)與被合并者(例如流Y)之間的合并。在這個(gè)情形中，會(huì)發(fā)現(xiàn)流X與Y是在相同的M-tree中。此外，流Y對(duì)應(yīng)于子樹(shù)的根部，所述子樹(shù)完全包含于以與流X對(duì)應(yīng)的節(jié)點(diǎn)為根部的另一子樹(shù)中。

取消操作是要將以流Y為根部的子數(shù)從受影響的M-tree脫離。類(lèi)似于合并操作，取消操作可包括在UN與DN之間的握手，以確保兩個(gè)網(wǎng)格節(jié)點(diǎn)都使它的通信期表被更新。UN可在合并操作之前通過(guò)查找通信期表中流Y的“merge_hop”字段來(lái)識(shí)別被合并者Y的DN。UN接著對(duì)這個(gè)DN發(fā)送“取消請(qǐng)求”(Cancel Request)消息。這個(gè)請(qǐng)求包含有與取消中所涉及的合并者及被合并者有關(guān)的信息。當(dāng)接收“取消請(qǐng)求”消息時(shí)，DN會(huì)從合并者X的被合并者列表(mergeelist)中移除被合并者Y，并且返回“取消確認(rèn)”(Cancel ACK)消息至UN以確認(rèn)取消。UN接著將流Y的“merger”(合并者)字段設(shè)定成其自己。當(dāng)取消操作成功時(shí)，以流Y為根部的子樹(shù)會(huì)從含有流X的iM-tree和oM-tree脫離，并且分別變成新的iM-tree和oM-tree。

通信期表中的“status”(狀態(tài))字段可用以指示流的狀態(tài)。舉例而言，在DSM中會(huì)有四種狀態(tài)，亦即NM(正常模式)、BM(“合并前”模式)、TM(終止模式)以及SD(流死亡模式)。NM狀態(tài)指示正常流。根據(jù)一個(gè)示例，在合并操作中僅考慮NM模式的流。BM狀態(tài)指示被合并流正處于合并操作中(亦即，DN尚未確認(rèn)合并請(qǐng)求)。當(dāng)UN最后自DN接收到指示合并操作成功的“Merge ACK”時(shí)，被合并者流的狀態(tài)即從BM模式轉(zhuǎn)換為T(mén)M模式。若合并操作失敗，被合并者流會(huì)回到NM模式。最后、但并非最不重要的是，當(dāng)流變成閑置時(shí)，NM、BM或TM模式中的流會(huì)轉(zhuǎn)為SD模式。當(dāng)有一段特定時(shí)間都沒(méi)有進(jìn)入的封包在這個(gè)流上抵達(dá)時(shí)，DSM可辨識(shí)出閑置的流。這會(huì)是各種無(wú)線條件的結(jié)果，例如鏈接失敗、干擾或附近網(wǎng)絡(luò)擁擠。當(dāng)流的狀態(tài)變?yōu)镾D，則調(diào)用取消操作，因?yàn)椴⒉恍枰喜㈤e置的流。SD狀態(tài)僅對(duì)于給定流的正常數(shù)據(jù)轉(zhuǎn)發(fā)恢復(fù)時(shí)才轉(zhuǎn)為NM狀態(tài)。

圖15中說(shuō)明了一種例示狀態(tài)轉(zhuǎn)換圖表150。每一個(gè)網(wǎng)格節(jié)點(diǎn)都周期性地檢查通信期表，并且根據(jù)“status”(狀態(tài))字段中的數(shù)值來(lái)觸發(fā)合并操作與取消操作。根據(jù)一個(gè)示例實(shí)施例，針對(duì)合并操作，只有NM狀態(tài)中的流可以是候選者。對(duì)于具有相同vid的流而言，具有在cur_sid數(shù)值中差異最小的流的對(duì)可觸發(fā)合并操作。在合并之后，合并者保持在NM模式中，而被合并者的狀態(tài)被改變?yōu)锽M。這個(gè)程序會(huì)重復(fù)進(jìn)行，直到通信期表中已經(jīng)不再發(fā)現(xiàn)NM模式中的流為止。這個(gè)程序有助于確保流可具有多個(gè)被合并者，但只有一個(gè)合并者。

每一個(gè)網(wǎng)格節(jié)點(diǎn)也基于單播路由協(xié)議所提供的路由信息來(lái)周期性地更新通信期表中的“next_hop”(下一躍程)字段。流的下一個(gè)躍程會(huì)遭受因基礎(chǔ)網(wǎng)絡(luò)的動(dòng)態(tài)的變化，例如鏈路故障或路由改變。若合并者與被合并者的“next_hop”字段不同、或任一“next_hop”字段變成無(wú)效，則會(huì)觸發(fā)取消操作以取消受影響的合并。在執(zhí)行合并操作與取消操作時(shí)，UN和DN會(huì)交換消息。多個(gè)操作的消息會(huì)在一個(gè)控制封包中被批次化，以減少通訊開(kāi)銷(xiāo)。

遞歸函數(shù)是被用來(lái)實(shí)施先前所述的數(shù)據(jù)轉(zhuǎn)發(fā)方案。當(dāng)進(jìn)來(lái)的封包p抵達(dá)網(wǎng)格節(jié)點(diǎn)時(shí)，網(wǎng)格節(jié)點(diǎn)基于包頭中的信息而找到它的對(duì)應(yīng)流s。這個(gè)封包與它的流s被使用作為下表II提出的轉(zhuǎn)發(fā)函數(shù)的輸入。此函數(shù)呼叫的輸入層級(jí)初始化為1。

表II遞歸轉(zhuǎn)發(fā)函數(shù)

對(duì)于s的“mergee_list”(被合并者列表)中的每個(gè)流k而言，函數(shù)會(huì)產(chǎn)生p的副本(p_copy)并仿造p_copy的標(biāo)頭中的某些字段，例如“IP address”(IP地址)與“端口數(shù)”，以使其產(chǎn)生流k的封包。在行數(shù)3中，這個(gè)函數(shù)被遞歸呼叫以為流k處理p_copy。輸入層級(jí)增加1，以指示輸入封包是復(fù)制的封包、而不是來(lái)自最后躍程的封包。這種遞歸方案有助于確保在s的M-tree中的所有流都將以它們自己的封包而由這個(gè)函數(shù)處理。從行數(shù)4開(kāi)始，函數(shù)作出流s轉(zhuǎn)發(fā)確定。若流s是處于TM模式，則sid超過(guò)s的blocked_id的封包被刪除。若流s不是處于TM模式，則函數(shù)于行數(shù)6驗(yàn)證層級(jí)，以得知輸入封包是否為復(fù)制的封包。若p是復(fù)制的封包，它會(huì)針對(duì)s被存儲(chǔ)于FIFO緩沖器中，并且在后續(xù)被轉(zhuǎn)發(fā)(行數(shù)7)。否則，p就是從最后躍程抵達(dá)的封包，而函數(shù)會(huì)馬上轉(zhuǎn)發(fā)這個(gè)封包(行數(shù)9)。

根據(jù)另一示例方法，上述技術(shù)可被用于提供流量去重復(fù)技術(shù)，以在視頻源(視頻服務(wù)器或CDN中的代理服務(wù)器)及客戶端之間實(shí)現(xiàn)更有效率的網(wǎng)絡(luò)通訊。所提出的SMART(Small packet Merge-Able RouTers)覆蓋網(wǎng)絡(luò)利用了機(jī)會(huì)性流量去重復(fù)方法，并且使每個(gè)SMART路由器都可動(dòng)態(tài)地合并相同視頻內(nèi)容的獨(dú)立流，這形成視頻流傳輸樹(shù)(VST)。在最后被解復(fù)用及傳送到與TCP協(xié)議完全兼容的客戶端之前，合并的流會(huì)與TCP通信期信息一起穿隧通過(guò)覆蓋。

我們檢視SMART覆蓋與當(dāng)前覆蓋多播方法一起作業(yè)，但對(duì)客戶端與應(yīng)用提供改善的服務(wù)的實(shí)施方式。多播網(wǎng)絡(luò)是重要的通訊形式，特別是對(duì)于VOD、視頻會(huì)議與對(duì)等式網(wǎng)絡(luò)文件共享而言。這使應(yīng)用可更有效率地使用資源，并且大幅增進(jìn)了可擴(kuò)展性。目前，對(duì)于多播有受限的網(wǎng)絡(luò)層支持是受限的，且這已經(jīng)導(dǎo)致應(yīng)用轉(zhuǎn)向互聯(lián)網(wǎng)中的更高層級(jí)以取得服務(wù)。作為響應(yīng)，覆蓋多播網(wǎng)絡(luò)被發(fā)展且被當(dāng)前用于互聯(lián)網(wǎng)中。覆蓋多播節(jié)點(diǎn)與彼此及使用標(biāo)準(zhǔn)單播機(jī)制的主機(jī)通訊。覆蓋網(wǎng)絡(luò)對(duì)客戶端或應(yīng)用提供了較高端的服務(wù)，同時(shí)從基礎(chǔ)網(wǎng)際網(wǎng)絡(luò)提取數(shù)據(jù)。

SMART路由器可被安裝在核心網(wǎng)絡(luò)、以及安裝在CDN與客戶端之間，以創(chuàng)建覆蓋拓樸，它將逐漸合并冗余的視頻流，并且對(duì)客戶端形成視頻流傳輸樹(shù)(VST)。這會(huì)有助于填補(bǔ)前述技術(shù)目前無(wú)法處理的間隙。在我們的SMART覆蓋拓樸中所建構(gòu)的VST與多播樹(shù)不同。這些技術(shù)之間的兩個(gè)主要差異如下：

1)在處理重復(fù)的VOD請(qǐng)求時(shí)，所建構(gòu)的VST允許比多播樹(shù)更多流量；以及

2)多播樹(shù)通過(guò)視頻的多播等待時(shí)間來(lái)限制客戶端。相反地，VST在對(duì)客戶端發(fā)送視頻之前并不需要批次等待。

在當(dāng)前的多播覆蓋架構(gòu)中，視頻流會(huì)成為瓶頸，例如來(lái)自于視頻服務(wù)器或CDN。此外，會(huì)有較多的流量通過(guò)其余網(wǎng)絡(luò)鏈路。SMART覆蓋拓樸結(jié)合多播覆蓋將有助于減輕導(dǎo)致視頻源的資源瓶頸，并且有助于減少其余網(wǎng)絡(luò)的帶寬需求，直到抵達(dá)最后節(jié)點(diǎn)為止。覆蓋拓樸中形成的VST直接處理了互聯(lián)網(wǎng)中去重復(fù)技術(shù)的需要。

安裝有軟件的路由器(稱(chēng)為SMART路由器)仍將如同平常作用，直到檢測(cè)到視頻為止。軟件控制器將識(shí)別通過(guò)網(wǎng)絡(luò)的視頻，并且確定所述視頻是新的、存在的，及/或存在且目前正在合并程序中的。為了確定它是否為視頻，軟件剖析封包的HTTP標(biāo)頭的“Content_Type”(內(nèi)容類(lèi)型)字段。若最上層媒體類(lèi)型為視頻，則控制器為所識(shí)別的此特別的視頻指定視頻id。否則，軟件會(huì)將所述封包作為非視頻處理，并如同平常地將它轉(zhuǎn)發(fā)到下一個(gè)躍程。視頻id是存儲(chǔ)在合并表中的唯一識(shí)別符，以用于處理重復(fù)視頻的查找。接著，控制器將會(huì)從封包中提取主機(jī)與目的地字段，并同樣將它們存儲(chǔ)在合并表中。合并表被使用作為查找表，以幫助維護(hù)路由器的狀態(tài)并保持對(duì)路由器中發(fā)生的各種合并程序的追蹤。軟件的控制器部分也有助于將封包轉(zhuǎn)發(fā)至覆蓋拓樸中的鄰近SMART路由器。若在視頻ID中存在匹配，則軟件接著將已識(shí)別的視頻封包的抽象交遞到冗余控制合并算法以處理合并程序。

SMART軟件中的冗余控制合并(RCM)算法處理通過(guò)這些路由器的冗余視頻。RCM有助于形成視頻流傳輸樹(shù)。視頻流的合并是在SMART路由器的內(nèi)部路由器結(jié)構(gòu)中進(jìn)行。

在路由層級(jí)的典型互聯(lián)網(wǎng)架構(gòu)包括以路由容量降次列出的核心路由器、聚集路由器以及邊緣路由器?；ヂ?lián)網(wǎng)中的流量擁擠是通過(guò)在路由器緩沖器中維護(hù)硬件隊(duì)列加以處理。在示例實(shí)施例中，并不使用外部或代理緩沖器，而是使用可用于這些路由器中的內(nèi)部路由器結(jié)構(gòu)。這有助于減少等待時(shí)間以及在覆蓋中實(shí)施冗余控制緩沖組件。

RCM在路由器中創(chuàng)建了多個(gè)迷你緩沖貯體(buffer bucket)來(lái)處理各種重復(fù)視頻的合并。為了要幫助節(jié)省路由器上有限的緩沖器資源大小，當(dāng)識(shí)別出視頻時(shí)，合并程序并不會(huì)立刻開(kāi)始緩沖程序。一旦識(shí)別出第二個(gè)冗余視頻時(shí)，RCM將只創(chuàng)建迷你緩沖貯體。所使用的總緩沖空間是針對(duì)每個(gè)冗余視頻所創(chuàng)建的迷你貯體的總和。為能更佳理解SMART路由器中的合并程序，SMART將在遇到第一個(gè)視頻流之后執(zhí)行下述基本步驟：

1)一旦控制器將視頻流識(shí)別為原始視頻，軟件為此特別的視頻流初始化母流(P1)。

2)當(dāng)接收下一個(gè)視頻流時(shí)，控制器檢查冗余。

若所述視頻是冗余的，則流將變成第一個(gè)子代流C1，并進(jìn)行到下一個(gè)步驟。否則，軟件將會(huì)初始化另一母流。

a)對(duì)于冗余的流而言，SMART軟件記錄相對(duì)于母流封包的冗余的視頻(子代)開(kāi)始的封包字節(jié)(指針)數(shù)。此記錄被存儲(chǔ)在合并表中，且每個(gè)子代流都被給定它自己的唯一的指針。

b)兩個(gè)字節(jié)數(shù)量(P1與C1)之間的差異提供我們暫時(shí)的容量。這個(gè)暫時(shí)的容量被用來(lái)確定將用于合并對(duì)應(yīng)的子代流的第一緩沖貯體的大小。緩沖器也將被用來(lái)向各自的客戶端發(fā)送信息。

3)接著，RCM利用所記錄的暫時(shí)的容量來(lái)分配它的路由器緩沖器中的空間，并且產(chǎn)生迷你緩沖貯體以開(kāi)始存儲(chǔ)部分的母流。在圖2示例中，緩存是在第50個(gè)封包處開(kāi)始，因?yàn)楫?dāng)C1抵達(dá)時(shí)，P1是在這個(gè)點(diǎn)。

4)一旦子代流C1追上緩沖器中的起始封包，兩個(gè)流之間的合并會(huì)開(kāi)始發(fā)生。接著，路由器將警示上游節(jié)點(diǎn)合并已經(jīng)發(fā)生且現(xiàn)在可能會(huì)封鎖C1。

5)回放會(huì)繼續(xù)進(jìn)行，直到C1已經(jīng)全部被發(fā)送到客戶端為止。

6)針對(duì)所接收的每個(gè)額外視頻流(例如圖2中的C2)重復(fù)程序。

a)若P1突然中斷，則第一子代流C1將通過(guò)對(duì)服務(wù)器發(fā)送恢復(fù)請(qǐng)求而解除與從母流的合并。一旦母流中的剩下的封包(來(lái)自于緩沖器)已經(jīng)被耗盡，則視頻流將再次從視頻服務(wù)器繼續(xù)，C1也將成為C2的新的母流。

b)若C2抵達(dá)過(guò)晚而無(wú)法加入P1流，則它將變成視頻的下一個(gè)母流(若有需要)。

部分或全部視頻都可被緩沖于SMART路由器中，但路由器并不是非常長(zhǎng)久地存儲(chǔ)視頻緩存。在針對(duì)特別視頻的所有請(qǐng)求都已經(jīng)完成處理后，緩沖器貯體即被釋放。這個(gè)活動(dòng)額外地讓我們可以將路由器上有限的緩沖空間最大化，以處理更多的視頻合并請(qǐng)求。最后，路由器上可用的全部緩沖器資源并不走到合并程序。SMART軟件維持了可用于正常流傳輸?shù)谋Ａ艟彌_大小分區(qū)。

在示例實(shí)施例中，最佳的合并位置是對(duì)于在客戶端與服務(wù)器之間的網(wǎng)絡(luò)鏈路可達(dá)到的帶寬節(jié)省最大量處。在建構(gòu)的VST中，所提出的流合并策略是分散地在每個(gè)SMART路由器上運(yùn)行。因此當(dāng)從同一視頻源開(kāi)始的兩個(gè)視頻流的路由路徑在它們分開(kāi)前往兩個(gè)客戶端之前一起通過(guò)多個(gè)SMART路由器時(shí)，這些SMART路由器中的每一個(gè)都會(huì)自己獨(dú)立地進(jìn)行流合并操作。最終的合并位置可以是這些SMART路由器中的任何一個(gè)。

然而，就節(jié)省網(wǎng)絡(luò)流量的觀點(diǎn)而言，優(yōu)化的合并位置應(yīng)所述是最后一個(gè)SMART路由器，其中兩個(gè)流恰在它們分開(kāi)之前仍一起通過(guò)(如同圖1中的合并結(jié)果拓樸)。下述分析顯示，當(dāng)涉及多個(gè)SMART路由器時(shí)，所提出的分布式流合并策略將于最佳位置處達(dá)成流合并。

在不失一般性的情況下，假設(shè)可以一起合并的兩個(gè)流(S1與S2)在它們分開(kāi)之前正通過(guò)相同的兩個(gè)SMART路由器(R1與R2)，如下述圖3所示。合并的最佳位置是指：若R1與R2都有資源，則合并應(yīng)是在這兩個(gè)流要一起通過(guò)的最后一個(gè)SMART路由器上進(jìn)行，亦即在路由器R2上；若R2不具有任何合并的資源，則合并應(yīng)所述要發(fā)生于下一個(gè)SMART路由器上(朝向視頻源沿共同路由路徑往前)，亦即在路由器R1上。注意這兩個(gè)SMART路由器是獨(dú)立地進(jìn)行流合并。

現(xiàn)在說(shuō)明確定如何達(dá)到最佳合并位置的示例方法。在不失一般性的情況下，假設(shè)第二流S2將要被合并至第一流S1。對(duì)于第一種場(chǎng)景而言，若R1和R2都具有合并的資源并且獨(dú)立地進(jìn)行合并，則會(huì)有兩種可能的合并結(jié)果。若路由器R1先開(kāi)始合并，則S2在服務(wù)器與R1之間的封包將會(huì)被舍棄。注意在此時(shí)刻R2還沒(méi)有合并S2。當(dāng)路由器R2稍后開(kāi)始合并，它將會(huì)舍棄從R1接收的S2的封包，并且通知R1停止其合并活動(dòng)(亦即丟掉S2的所有封包，并且僅轉(zhuǎn)發(fā)S1的封包)。

若路由器R2先開(kāi)始合并，S2在R2與R1之間的流量鏈路將會(huì)被移除，這將導(dǎo)致路由器R1舍棄它對(duì)于S2正在進(jìn)行的合并活動(dòng)，因?yàn)閺腞1觀點(diǎn)，流S2不再會(huì)存在。

就兩種情況而言，最后合并都將會(huì)保持在路由器R2上，也就是對(duì)于兩個(gè)客戶端而言的最后一個(gè)SMART路由器，且為最佳位置。

就第二種情景而言，當(dāng)R2沒(méi)有任何合并的資源時(shí)，R1開(kāi)始合并，并且保持持有此合并，R1為這種情況的最佳合并位置。

此外，應(yīng)指出分布式合并算法也可處理互聯(lián)網(wǎng)路由中的動(dòng)態(tài)。封包可通過(guò)不同路徑而從服務(wù)器穿越到客戶端，而且只要在路徑上有一對(duì)SMART路由器，算法即可減少重復(fù)的封包。

綜合言之，所提出的分布式合并策略最終能在最佳位置處達(dá)成流合并，而且不會(huì)浪費(fèi)其他SMART路由器上的緩沖資源。

SMART覆蓋將多個(gè)TCP通信期合并為一個(gè)流以節(jié)省帶寬。一個(gè)挑戰(zhàn)在于如何讓它對(duì)于客戶端的應(yīng)用而言是透明的(亦即，對(duì)于每一個(gè)客戶端應(yīng)用而言，它仍在處理視頻服務(wù)器)。SMART隧道技術(shù)即被設(shè)計(jì)以解決這個(gè)問(wèn)題。

為了對(duì)隧道方法有更佳的理解，考慮視頻源、SMART路由器(覆蓋)與客戶端(C1-C6)。為求簡(jiǎn)化，我們可稱(chēng)路由器A與C為核心路由器，而路由器B、D與E為邊緣路由器。假設(shè)A正在為C1-C6合并視頻流。路由器A會(huì)將封包與其目的地存儲(chǔ)于合并表中。對(duì)于路由器A的合并表中的每一個(gè)封包而言，需要進(jìn)行兩件事情。首先，它查詢路由表以計(jì)算出需要什么樣的下一躍程來(lái)轉(zhuǎn)發(fā)封包。在這種情況中，A僅需要對(duì)B發(fā)送一次封包，因?yàn)镃1與C2的TCP通信期被合并了。而A到C亦然。其次，A將TCP封包封裝于IP數(shù)據(jù)報(bào)中。IP的標(biāo)頭來(lái)源被設(shè)定為路由器A的IP地址。目的地地址被設(shè)定為下一個(gè)躍程(B或C)的IP地址。IP數(shù)據(jù)報(bào)的有效載荷是UDP封包。UDP封包具有隧道標(biāo)頭及含有TCP封包的有效載荷。隧道標(biāo)頭包括下列三個(gè)部分：類(lèi)型、視頻id，以及目的地列表。

視頻id識(shí)別出正在路由器中進(jìn)行合并的特別視頻。IP標(biāo)頭中的類(lèi)型字段識(shí)別出封包是否正在轉(zhuǎn)發(fā)至下一個(gè)躍程，或者是否應(yīng)要作為隧道封包(且遭受合并程序)而被處理。類(lèi)型字段選項(xiàng)是被設(shè)定為要在封包重傳情況下轉(zhuǎn)發(fā)。最后一部分是元組的目的地列表(目的地IP、端口)。在這個(gè)例子中，其為關(guān)于封包A至B的C1與C2及A至C的C3-C6的信息。利用UDP有效載荷的IP數(shù)據(jù)報(bào)封裝允許SMART路由器識(shí)別出作為隧道封包的封包。當(dāng)路由器B(邊緣)接收封包時(shí)，它會(huì)理解它是要遞送C1與C2。SMART軟件將接著為C1與C2制造封包(利用適當(dāng)?shù)腡CP標(biāo)頭與有效載荷)，并且將封包各自傳送至C1與C2。當(dāng)C接收封包(并且為核心路由器)時(shí)，若它并未合并視頻，則它會(huì)檢查UDP標(biāo)頭。若其為隧道封包，則路由器將提取目的地并計(jì)算下一個(gè)躍程。在我們的示例中，C會(huì)以C3發(fā)送封包至路由器D，并以C4-C6發(fā)送封包至路由器E。

現(xiàn)在假設(shè)對(duì)于C1遺失了一些封包。視頻服務(wù)器會(huì)重傳這些封包，且封包會(huì)再次通過(guò)服務(wù)器A。其應(yīng)將這些封包以穿隧方式送到C1并設(shè)定類(lèi)型字段以在隧道包頭中轉(zhuǎn)發(fā)。所有的后續(xù)SMART節(jié)點(diǎn)都將僅轉(zhuǎn)發(fā)封包。我們也需要處理中斷連接與超時(shí)的TCP通信期。每個(gè)SMART路由器都為它所服務(wù)的所有客戶端監(jiān)控進(jìn)來(lái)的流量。若客戶端活動(dòng)休眠一段時(shí)間，則路由器將停止對(duì)所述客戶端轉(zhuǎn)發(fā)流量。若有超時(shí)或擁擠，視頻服務(wù)器將恢復(fù)發(fā)送封包，而我們的服務(wù)器也將恢復(fù)。

最后，為了降低SMART路由器(邊緣)和客戶端之間可能的擁擠，我們將起始修補(bǔ)技術(shù)。假設(shè)C1先到達(dá)SMART路由器，然后不久之后C2到達(dá)。當(dāng)路由器A開(kāi)始為C1與C2進(jìn)行合并時(shí)，C1的流會(huì)變成母流。假設(shè)合并是在封包100處開(kāi)始，路由器B將會(huì)接收到從100開(kāi)始、連同封包1至99的C2的緩沖封包。在此例中，B將會(huì)緩沖封包，并且僅對(duì)C2傳送先前緩沖的封包1至99(“修補(bǔ)”)。在那之后，B將對(duì)C2傳送從100開(kāi)始的緩沖封包。所述方法保證SMART覆蓋并不會(huì)在邊緣路由器及客戶端之間造成所謂“最后一公里”的過(guò)度負(fù)荷。

發(fā)明所屬技術(shù)領(lǐng)域中具有普通技術(shù)人員將可基于本文所提出的教示而得知本發(fā)明的許多修改與其他實(shí)施例。因此，應(yīng)理解本發(fā)明并不限于在此所公開(kāi)的特定示例性實(shí)施例。