專利名稱：用于移動tv的魯棒文件傳播的制作方法
技術領域：
本發明總體涉及內容分發，具體涉及一種用于提供有效修復機制的方法和設備。
背景技術：
本節意在向讀者介紹與以下描述和/或要求保護的本發明的各個方面可能相關的技術領域的各個方面。相信該討論有助于向讀者提供背景信息，以便于對本發明各個方面的理解。相應地，應當理解，應據此閱讀這些聲明，而不應當將其作為對現有技術的接納來閱讀。
現在，通過蜂窩網絡在移動終端上暫時觀看TV節目已經是可能的。在DVB-H中定義的廣播協議增強了服務質量和商用服務的可能性。移動TV試驗以及第一商業活動集中于傳統的實況TV服務。
可以在移動廣播網絡(例如DVB-H)和雙向網絡(例如蜂窩3G網絡)上構建推文件傳送服務。基于文件的視頻傳送服務的一個優點是網絡問題(例如帶寬約束和分組丟失)上的相對靈活性。
基于一些標準，根據智能調度，推送視頻點播(VOD)服務通過廣播多播網絡(例如，DVB-H)向終端用戶設備傳輸視頻文件，這些標準包括優先級、用戶預訂、網絡狀態(測量例如帶寬可用性)、動態內容分類、調度歷史等等。將這些與用戶偏好相匹配的文件保存到終端用戶設備上的本地存儲器。這使用戶能夠在沒有播放延遲并且幾乎不考慮底層傳送機制的情況下訪問多種內容。在標準"ETSI EN 301192 VI.4.1 (2004-11) Digital Video Broadcasting (DVB); DVBspecification for data broadcasting"和"ETSI EN 302 304 VI.1.1 (2004-11)Digital Video Broadcasting (DVB); Transmission System for HandheldTerminals (DVB-H)"中定義了 DVB扁H。
移動廣播網絡是單向網絡，其中可以使用前向糾錯(FEC)來部分地解決分組丟失。然而，使用FEC機制是消耗帶寬的，并且不保證
完全恢復的文件。這對于以下無線移動廣播網絡來說是尤其正確的在該無線移動廣播網絡中，當用戶移動至覆蓋較差的區域(例如隧道)
中時，終端可能錯過大段的數據。此外，在當前DVB-H接收器實施方式中，根據標準"ETSI TR 102 377 Vl丄l (2005-02) Digital VideoBroadcasting (DVB); DVB畫H Implementation Guidelines",如果不能使用FEC來完整地修復包括若干IP分組的分組突發(burst of packet),則忽略該分組突發。那么，可能丟失若干重要的IP分組。
另一種用于避免分組丟失的技術在于發送相同的文件若干次。該技術可以完全適用于短文件，例如在標準"DVB-IPDC ESG, ETSI TS102 471 V 1.2.1 (2006-09), Digital Video Broadcasting (DVB); IPDatacast over DVB-H: Electronic Service Guide (ESG)"中指定的電子服務指南容器。但是該技術對于視頻文件傳送來說明顯是不太有效的機制。
文件修復或魯棒文件傳播是另一種保證用無線電傳輸的視頻文件的完整性的方法。特別地，文件修復或魯棒文件傳播完全適用于增強用戶觀看體驗的推送VOD服務。
在由第三代合作伙伴計劃、多媒體廣播多播服務組
(3GPP-MBMS)制定的標準"ETSI TS 102 472 Vl.2.1 (2006-12),Digital Video Broadcasting (DVB); IP Datacast over DVB-H: ContentDelivery Protocols"中描述了后傳送文件修復協議。該協議還被描述在由數字視頻廣播-匯聚廣播多播系統組(DVB-CBMS)制定的標準
"ETSI TS 126 346 V6.1.0 (2005-06)， Universal MobileTelecommunications System (UMTS); Multimedia Broadcast/MulticastService (MBMS); Protocols and codecs (3GPP TS 26.346 version 6.1.0Release 6)"中。文件修復機制是所謂的關聯傳送過程的一部分；主要過程是基于FLUTE協議套的文件傳送，其中，基于單向傳輸的文件傳送(FLUTE)在RFC 3926中指定。文件修復協議的目標是提供一種取回丟失分組和/或先前根據文件傳送過程而接收到的文件片段的方式。每當應已經完全接收到文件時，開始文件修復過程。在FLUTE中難以檢測文件的結束。可以對文件的最后一個FLUTE分組進行標記以發信號通知文件的結束。然而，如果該分組丟失，則接收器必須依靠文件傳送表(FDT)。 FDT是與要作為FLUTE協議一部分而在頻帶中發送的文件有關的一組信息。這樣的信息可選地包含文件的大小。然而，根據RFC 3926， DVB-CBMS推薦使用指示當前基于FLUTE協議而傳輸的文件大小的FDT傳輸長度參數。 一旦據推測應接收到文件，接收器就檢測丟失的FLUTE分組并與修復服務器建立連接。根據退避(back-off)算法，接收器在正確時間發送一個或多個請求并獲得丟失的分組，并保存完全重構的文件。
可以將該機制與類似于DVB-CBMS所推薦的raptor碼的應用FEC相結合。接收器僅請求成功運行FEC解碼過程所必需的分組。
然而，接收器可能沒有接收到FDT。此外，大小信息作為強制擴展報頭而存在于FLUTE分組報頭中，該強制擴展報頭收集包括傳輸長度在內的FEC傳送信息。并且，在每一個FLUTE分組中傳送報頭擴展不是強制的。最后，如果接收器尚未檢測到任何先前信息，則可以使用監視計時器來安全地關閉文件。由于兩個分組之間經過的時間不是恒定的，因此必須謹慎地使用監視計時器。

發明內容
本發明通過提供修復網關來嘗試修正現有技術中與文件修復相關的問題中的至少一些，該修復網關對更適合請求設備的修復服務器進行選擇。
本發明涉及一種用于在以下系統中、在修復控制設備處從多個修復服務器當中選擇修復服務器的方法，在所述系統中，至少一個終端以及所述多個修復服務器收聽以推模式從至少一個文件服務器分發的至少一個文件傳送會話。
為此，所述方法包括以下步驟從所述至少一個終端接收針對修
復所述至少一個文件傳送會話的分組的請求；選擇用于修復發往所述
至少一個終端的分組的修復服務器；以及利用所選擇的修復服務器的地址，將所述請求重定向至所述至少一個終端。
文件修復機制是基于允許任意接收器修復先前通過單向廣播網絡接收到的文件的點對點協議的。該方案擴展了增強魯棒性和可擴縮
性的DVB-IPDC禾n3GPP-MBMS后傳送文件修復機制的可能性。本發明的方法提供了對修復過程的集中式控制，該集中式控制通過在發送請求時提供最佳修復服務器來改進修復過程的效率。這完全適于包括在大網絡中分散開的多個修復服務器在內的網絡。
根據實施例，所述方法包括以下步驟將來自終端的、針對修復所述至少一個文件傳送會話的分組的后續請求重定向至所選擇的修復服務器。
本發明還涉及一種用于在以下系統中、在修復控制設備處從多個修復服務器當中選擇修復服務器的方法，在所述系統中，至少一個終端以及所述多個修復服務器收聽以推模式從至少一個文件服務器分發的至少一個文件傳送會話。
為此，所述方法包括以下步驟從所述至少一個終端接收針對修
復所述至少一個文件傳送會話的分組的請求；選擇用于修復發往所述至少一個終端的分組的修復服務器；以及將所述請求轉發至所選擇的
修復服務器。
根據實施例，所述方法包括以下步驟將來自終端的、針對修復
所述至少一個文件傳送會話的分組的后續請求轉發至所選擇的修復服務器。
根據實施例，修復服務器是第一類型的或第二類型的，其中第一類型的修復服務器僅正確地接收由文件服務器傳輸的分組的一部分，而第二類型的修復服務器正確地接收由文件服務器傳輸的所有分組。
所述選擇步驟包括以下步驟對第一類型的修復服務器進行分類；從
分類的第一至最后一個修復服務器，相繼地發送針對修復分組的請求，直到接收到具有指示的響應為止，所述指示是關于修復服務器可確保
的修復的百分比的，其中所述百分比滿足閾值；如果修復服務器滿足所述閾值，則選擇修復服務器；以及如果列表的最后一個修復服務器沒有提供滿足所述閾值的百分比，則選擇第二類型的修復服務器。根據實施例，修復控制器按照從負載最少到負載最多來對修復服 務器進行分類。
根據實施例，修復控制器選擇與所述請求設備最接近的第二類型 的修復服務器。
根據實施例，所述文件傳送會話是基于單向傳輸的文件傳送會話。
根據實施例，所述選擇步驟包括以下步驟決定使用多播修復以 及選擇第二類型的修復服務器。
本發明還涉及一種修復控制設備，包括通信裝置，用于在以下 系統中與多于一個修復服務器以及至少一個終端進行通信，在所述系 統中，所述多于一個修復服務器以及所述至少一個終端收聽以推模式 從至少一個文件服務器分發的至少一個文件傳送會話；選擇裝置，用 于在從所述至少一個終端接收到修復請求時，在所述多于一個修復服 務器當中選擇用于修復發往所述至少一個終端的分組的修復服務器；
以及重定向裝置，用于將從終端接收到的、針對修復分組的請求重定 向至修復服務器，或者用于將請求轉發至修復服務器。
以下闡述與所公開的實施例在范圍上相當的特定方面。應當理解， 僅為了向讀者提供本發明可能采用的特定形式的概要而提出這些方 面，并且這些方面并不意在限制本發明的范圍。實際上，本發明可以 包含以下可能沒有闡述的多種方面。


通過非限制性的以下實施例和執行示例，參照附圖，將更好地理
解并示意本發明，附圖中
-圖1示出了具有單個服務器的系統的框-圖2示出了根據實施例的多服務器架構的框-圖3示出了根據實施例的修復控制器的框圖；以及
-圖4示出了根據實施例的選擇方法的流程圖。
在圖3中，所示出的框是完全功能性實體，其不必與物理分離的
實體相對應。即，這些實體可以以硬件或軟件的形式來開發，或者在一個或若干集成電路中實現。
具體實施例方式
示例實施例處于DVB-H架構中的視頻廣播的框架之內，但是本發 明并不限于該特定環境，而是可以應用于要在多個服務器上選擇服務 器的其他框架內。
圖1示出了具有單個服務器的系統。該系統遵循標準"ETSITS 102 472 VI .2.1 (2006-12) - Digital Video Broadcasting (DVB); IP Datacast over DVB-H: Content Delivery Protocols"。在IP網絡(1)和DVB-H網 絡(3)上向DVB-H終端(T1、 T2、 T3)廣播內容(4)。終端通過遵 循GPRS標準的3G網絡(2)向修復服務器(Rl)請求丟失的文件(5)。 修復服務器(Rl)對于文件服務器(Fl)來說是透明的。修復服務器 收聽輸出UDP業務并且應該是可靠的。修復服務器可以駐留在文件服 務器主機內。修復服務器可以是多信道的，即，修復服務器可以收聽 與FLUTE會話相關聯的若干ALC信道，ALC是在RFC 3450 -異步分層 編碼(ALC)協議實例化中定義的。
FLUTE會話與文件傳送會話相對應。FLUTE會話由傳輸會話標識 符(TSI)以及文件服務器的源地址來標識。在每一個FLUTE分組中 指示TSI。修復服務器可以專門用于收聽唯一的會話，或者可以是多會 話的，即，修復服務器可以收聽并行的若干會話。
當請求修復時，終端使用待修復的文件的統一資源標識符(URI)。 然而，接收器可能不知道該URI;承載URI與相應FLUTE傳輸標識符 之間的關聯的FDT可能丟失。根據實施例，在文件的廣播之后的文件 修復期間，可以使用正在進行的會話的傳輸對象標識符(TOO來唯 一地標識待修復的文件。TOI是嵌入FLUTE分組報頭中的FLUTE協議 套標識符。可以在FLUTE會話的使用期限期間，在不同時刻重復使用 該標識符(作為與不同URI相關的傳輸對象標識符)。某時，在由于傳 輸會話標識符(TSI)以及發送方(即，文件服務器)的源地址IP而自 身標識的FLUTE會話內，該標識符通過FDT實例與有效URI唯一地相
關聯時。FDT承載了與待傳送的文件相關的、包括文件的URI在內的重要 信息。接收器使用FDT來相應地對文件進行存儲、分類或處理。如果 已經部分地接收到FDT，則可能出現終端無法找到與接收到文件相關 聯的任何FDT信息的情況。盡管FDT可以如上所述使用FLUTE標識符 來修復文件，并可以根據私有命名方案來存儲該文件，但獲得用于更 傳統命名過程的丟失的FDT信息是有用的。根據實施例，已經如下擴 展修復請求終端可以請求FDT或至少請求與用對TSI/TOI標識的文件 相關的部分FDT。當然，優化后的請求收集用于標識文件的TSI/T01、 待修復的FLUTE分組的列表以及對同時獲得關聯的部分FDT的指示。
當前DVB-CBMS文件修復協議指定，請求修復的客戶端發送與每 一個待修復的FLUTE分組相對應的FEC有效載荷ID。該FEC有效載荷 ID由源塊編號(SBN)和編碼符號ID (ESI)構成。修復服務器在其 響應中發回所請求的有效載荷組塊的集合，每一個組塊都被加有所謂 的FEC有效載荷ID作為前綴。這迫使客戶端將輸入的、已修復的分組 作為非FLUTE分組進行處理，或者迫使客戶端重新組合FLUTE分組，
這不是件容易的任務。根據實施例，在收到客戶端請求時，修復服務 器可以返回完整的FLUTE分組而不是僅返回有效載荷部分。這簡化了 客戶端側的實施方式，這是由于當已修復的FLUTE分組來自DVB-H接 口時，可以將已修復的FLUTE分組再插入接收過程中。
圖2示出了多服務器架構。其目的是給單個服務器系統提供可擴 縮性。多服務器架構包括根據FLUTE多播傳送協議對文件進行廣播或 多播的文件服務器(Fl)。
該架構包括通過可靠連接裝置而與文件服務器相連接的至少一 個可靠修復服務器(RR)。可靠連接裝置是提供非常低差錯率或等于 零的差錯率的裝置。可靠修復服務器收聽多播業務并同時構建其內部 文件數據庫。可靠修復服務器在無任何差錯的情況下獲得所有業務。 在不同實體中表示可靠修復服務器和文件服務器。當然，它們可以位 于相同物理實體內。
該架構還包括一組非可靠修復服務器(Rl、 R2、 R3、 R4、 R5、 R6)，以下稱作修復服務器。這些修復服務器捕獲由文件服務器進行廣播的文件。在這些修復服務器在有丟失和差錯的情況下接收分組的 意義上，這些修復服務器是非可靠的。因此，這些修復服務器可能需 要與任意其他客戶端終端一樣使用文件修復協議來修復它們自己的文 件。
在IP網絡(1)和DVB-H網絡(3)上向DVB-H終端(Tl、 T2、 T3)廣播內容。終端通過遵循GPRS標準的3G網絡(2)，向修復控制 器(RC)請求丟失的文件。
該多服務器架構包括修復控制網關(RC)，其基本上是系統的 HTTP服務器前端。修復控制網關(RC)接收并分析來自客戶端終端 的修復請求。修復控制網關(RC)根據修復服務器基礎結構來決定修 復策略。在上述單個服務器系統中，可以將修復控制網關和可靠修復 服務器封裝在一起。在多服務器架構中，可以在修復服務器之一中包 括修復控制網關。備選地，可以將修復控制網關與客戶端終端并置。 通常，修復控制器有規律地輪詢(poll)服務器，以檢査哪個是活動 的或不活動的，并檢査每一個服務器的CPU負載。
根據實施例，支持兩種拓撲。
服務器農場基礎結構(11)，也稱作集中式基礎結構，包括通過 LAN連接在一起的一組修復服務器。服務器農場由修復控制網關來控 制，并還可能與客戶端直接互相連接。修復控制網關根據負載標準來 選擇修復服務器，該負載標準與由用于執行基于DNS的負載平衡的網 絡農場控制器所使用的負載標準相類似。
分布式基礎結構(10)是為了提供最有效率的響應時間而沿著大 區域分布的一組修復服務器。
修復控制網關，也稱作修復控制器，是系統基礎結構的首端 (head-end)。其用于提交的地址是終端眾所周知的僅有信息。當終端 需要修復文件時，終端向修復控制器發送修復請求。修復控制器可以 處理上述兩種拓撲服務器農場和分布式網絡。
在分布式網絡的情況下，修復控制器將請求轉發給與終端最接近 的修復服務器。轉發是基于HTTP重定向的，其中，修復控制器向客戶 端發回作為修復響應的HTTP重定向命令。在關于HTTP 1.0的RJFC1945和關于HTTP 1.1的RFC2616中定義了HTTP重定向。在接收到HTTP重 定向時，客戶端向HTTP重定向中指示的修復服務器自動發布新的 HTTP請求。該修復服務器根據修復協議來響應該請求。
在服務器農場的情況下，修復控制器將請求轉發給農場中負載較 少的修復服務器。將請求直接轉發給修復服務器。所選修復服務器可 以根據修復協議來服務該請求。請求和響應始終經過修復控制器。
根據實施例，修復控制器不僅可以由于服務器負載少或者服務器 接近發送請求的終端而選擇該服務器。修復控制器還可以選擇能保證 與特定請求相關聯的特定修復百分比的服務器。修復百分比是修復控 制器的配置參數。在該組修復服務器當中，依然存在被視為最可靠的 服務器。由于分組丟失，使得其他服務器可能部分地捕獲到來自文件 服務器的完整業務。
如圖4所示，如下對服務器進行選擇。終端與修復控制器建立TCP 連接。在S1，終端向修復控制器發送HTTP修復請求。在步驟S2、 S3， 修復控制器修改該請求。為了指示該請求用于檢查對于該修復服務器 來說修復是否可能，修復控制器改變該請求的名稱。該請求不用于修 復。然后，修復控制器將該請求轉發給最接近的修復服務器(當在分 布式網絡中時)，或者轉發給負載最少的服務器(當在服務器農場中 時)。換言之，修復控制器構建修復服務器的列表，并根據依賴于網絡 類型的標準對列表中的修復服務器進行分類；在服務器農場中，分級 是基于服務器負載的。 在接收到請求時，修復服務器分析該請求，并向修復控制器發回 應答S4以指示其可確保的修復級別。可以基于如下若干參數來估計該
修復級別
-修復服務器可修復的文件的百分比(與關聯的本地數據庫中可 用的數據相對應)；
-與接收到的請求相對應的修復百分比。
修復控制器基于閾值，使用這些參數來決定其是否維持其選擇。 如果修復服務器應答不滿足修復控制器，則修復控制器嘗試另一 個修復服務器S6，以檢查其是否將提供更好的修復比率。如果該修復過程沒有成功地提供修復服務器，則修復控制器使用
可能的負載標準來選擇可靠修復服務器之一S7。
換言之，終端請求待修復的文件的特定數目的分組。在接收到請 求時，修復控制器向修復服務器發送請求，以了解服務器是否能夠提 供分組。在接收到該請求時，服務器檢查可用分組的數目。百分比是 可用分組的數目與所請求分組的數目之比。修復控制器設立閾值。如 果該百分比低于閾值，則修復控制器向另一服務器發送請求。如果該
百分比高于閾值，則選擇該服務器。優選地，將閾值設置為值40%。
HTTP修復請求長度是有限的。可以將該長度限制為256字節的 值。如果終端請求大量數據，則單個請求是不夠的，并且終端將若干 子請求連續發送至相同會話中。在這種情況下，修復控制器基于子請 求序列的第一個請求來對服務器進行選擇。然后，修復服務器向每一 個子請求發送響應。
一旦選擇了修復服務器，修復控制器的行為就依賴于基礎結構。 在服務器農場的情況下，存在兩種可能性。
在第一種可能性中，服務器農場與客戶端的網絡不直接相連。修 復控制器將請求轉發給所選修復服務器，不是為了檢查的目的，而是 為了處理的目的。修復服務器處理該請求并向修復控制器發回其應答， 該修復控制器將該應答轉發回到終端，依此類推。
在第二種可能性中，服務器農場與客戶端的網絡直接相連。在接 收到修復請求時，修復控制器向客戶端發回HTTP重定向命令。該命令 收集所選修復服務器地址。在接收到HTTP重定向時，客戶端向HTTP 重定向中指示的地址處的修復服務器自動發送HTTP請求。修復服務器
向客戶端發回修復分組，依此類推。
在分布式基礎結構的情況下，僅第二種可能性適用。 可以將分布式基礎結構與服務器農場基礎結構相結合。結合后的
基礎結構包括一組分布式"獨立(standalone)"和"農場"服務器。
那么，控制器基于服務器(或服務器農場)的位置以及每一個單獨修
復服務器的負載的級別，使用更復雜的啟發式算法。
根據實施例，修復網關還包括單播-多播模塊。該模塊適于將修復模式從單播分發模式切換至多播分發。如上所述，網關將終端重定向 至修復服務器，或者將請求轉發給修復服務器。這是單播模式。
采用遵循ETSITS 126 346的方式，網關可以將終端重定向至廣播 /多播傳送。當切換至多播時，網關優選地選擇可靠修復服務器，該可 靠修復服務器將提供要通過該多播傳送進行廣播的修復數據。
圖3示出了修復控制網關RC。修復控制網關RC包括連接至互聯網 的通信裝置102。當然，修復控制器可以連接至允許連接至修復服務器 和終端的任何其他類型的網絡。通信裝置使網關能夠與終端和修復服 務器進行通信。
修復控制網關RC包括用于將來自終端的請求重定向至修復服務 器的地址的重定向裝置104。根據實施例，重定向裝置遵循如上所述的 HTTP重定向。
修復控制網關RC包括用于以上述方式選擇修復服務器的選擇裝 置103。
修復控制網關RC包括用于如上所述在單播模式與多播模式之間 執行切換的單播-多播模塊105。
修復控制網關RC包括以存儲器形式存在的存儲模塊lOl，用于存
儲該架構的修復服務器的列表。
修復控制網關RC包括以處理器形式存在的處理模塊106。
可以將修復控制網關與計算機設備并置。當然，修復控制網關也 可以是包括此處所述的功能性模塊的任意獨立設備。
可以獨立地或者以任意適當組合來提供說明書、權利要求以及附 圖中公開的參考。可以以硬件、軟件或者二者的組合來在適當處實現 特征。
此處對"一個實施例"或"實施例"的引用意味著，在本發明的 至少一個實施方式中可以包括結合該實施例進行描述的特定特征、結 構或特性。在說明書各處出現的短語"在一個實施例中"不必全部指 代相同的實施例，并且不必是與其他實施例互斥的單獨或備選實施例。
出現在權利要求中的參考標記僅作示意之用，而不應該對權利要 求的范圍有限制作用。
權利要求
1、一種系統中在修復控制設備(RC)處從多個修復服務器(RR、R1、R2、R3、R4、R5、R6)當中選擇修復服務器的方法，在所述系統中，至少一個終端(T1、T2、T3)以及所述多個修復服務器收聽以推模式從至少一個文件服務器(F1)分發的至少一個文件傳送會話；所述方法包括以下步驟-從所述至少一個終端接收(S1)針對修復所述至少一個文件傳送會話的分組的請求；-選擇(S5、S7)用于修復發往所述至少一個終端的所述分組的修復服務器；以及-利用所選擇的修復服務器的地址，將所述請求重定向至所述至少一個終端。
2、 根據權利要求l所述的方法，還包括以下步驟將來自所述終 端的、針對修復所述至少一個文件傳送會話的分組的后續請求重定向 至所選擇的修復服務器。
3、 一種系統中在修復控制設備(RC)處從多個修復服務器(Rl、 R2、 R3、 R4、 R5、 R6)當中選擇修復服務器的方法，在所述系統中， 至少一個終端(Tl、 T2、 T3)以及所述多個修復服務器收聽以推模式 從至少一個文件服務器分發的至少一個文件傳送會話；所述方法包括 以下步驟-從所述至少一個終端接收(Sl)針對修復所述至少一個文件傳 送會話的分組的請求；-選擇(S5、 S7)用于修復發往所述至少一個終端的所述分組的 修復服務器；以及-將所述請求轉發至所選擇的修復服務器。
4、 根據權利要求3所述的方法，還包括以下步驟將來自所述終 端的、針對修復所述至少一個文件傳送會話的分組的后續請求轉發至 所選擇的修復服務器。
5、 根據前述權利要求中任意一項所述的方法，其中，所述修復服務器是第一類型(RR)的或第二類型(Rl、 R2、 R3、 R4、 R5、 R6)的，其中第一類型的修復服務器僅正確地接收由所述文件服務器傳輸的分組的一部分，而第二類型的修復服務器正確地接收由所述文件服務器傳輸的所有分組，所述選擇步驟包括以下步驟-對第一類型的修復服務器進行分類；-從所述分類的第一至最后一個修復服務器，相繼地(S6)發送(S3)針對修復分組的請求，直到接收到(S4)具有指示的響應為止，所述指示是關于修復服務器能確保的修復的百分比的，其中所述百分比滿足閾值；-如果修復服務器滿足所述閾值，則選擇該修復服務器(S5);以及-如果列表的最后一個修復服務器沒有提供滿足所述閾值的百分比，則選擇(S7)第二類型的修復服務器。
6、 根據權利要求5所述的方法，其中，所述修復控制設備按照從負載最少到負載最多來對修復服務器進行分類。
7、 根據權利要求5或6所述的方法，其中，所述修復控制設備選擇與請求設備最接近的第二類型的修復服務器。
8、 根據前述權利要求中任意一項所述的方法，其中，所述文件傳送會話是基于單向傳輸的文件傳送會話。
9、 根據權利要求3所述的方法，其中，所述選擇步驟包括以下步驟-決定使用多播修復；以及-選擇第二類型的修復服務器。
10、 一種修復控制設備(RC)，包括-通信裝置(102)，用于在系統中與多于一個修復服務器以及至少一個終端進行通信，在所述系統中，所述多于一個修復服務器以及所述至少一個終端收聽以推模式從至少一個文件服務器分發的至少一個文件傳送會話；-選擇裝置(103)，用于在從所述至少一個終端接收到修復請求時，在所述多于一個修復服務器當中選擇用于修復發往所述至少一個終端的所述分組的修復服務器；以及-重定向裝置(104)，用于將從終端接收到的、針對修復分組的請求重定向至所述修復服務器，或者用于將所述請求轉發至所述修復服務器。
全文摘要
本發明涉及一種修復控制設備以及在用于以下系統中、在所述修復控制設備處從多個修復服務器當中選擇修復服務器的方法，在所述系統中，至少一個終端以及所述多個修復服務器收聽以推模式從至少一個文件服務器分發的至少一個文件傳送會話。所述方法包括以下步驟從所述至少一個終端接收針對修復所述至少一個文件傳送會話的分組的請求；選擇用于修復發往所述至少一個終端的分組的修復服務器；以及利用所選擇的修復服務器的地址將所述請求重定向至所述至少一個終端，或者將所述請求轉發至所選擇的修復服務器。
文檔編號H04N7/24GK101647282SQ200880010380
公開日2010年2月10日 申請日期2008年3月19日 優先權日2007年3月30日
發明者樊尚·阿洛姆, 紀堯姆·比紹 申請人:湯姆森許可貿易公司