專利名稱：用于提供不等錯誤保護和捆綁文件傳遞服務的通用文件傳遞方法
技術(shù)領域：
本發(fā)明涉及在通信系統(tǒng)中編碼和解碼數(shù)據(jù)，且更具體來說，涉及以有效方式編碼及解碼數(shù)據(jù)以考慮到所傳達數(shù)據(jù)中的錯誤和間隙且處置不同文件傳遞方法的通信系統(tǒng)。
背景技術(shù)：
用于通過通信信道在發(fā)送器與接收者之間傳輸文件的技術(shù)是很多文獻的主題。優(yōu)選地，接收者需要以某種程度的確定性接收由發(fā)送器通過信道發(fā)射的數(shù)據(jù)的精確副本。當信道不具有理想保真度(其涵蓋大多數(shù)物理可實現(xiàn)系統(tǒng))時，所擔心的是如何處理在傳輸中丟失或混淆的數(shù)據(jù)。丟失數(shù)據(jù)(擦除)與損壞數(shù)據(jù)(錯誤)相比常常更容易處理，這是因為接收者無法總是分辨出損壞數(shù)據(jù)是錯誤接收的數(shù)據(jù)的情況。已開發(fā)許多糾錯碼來對擦除和/或錯誤進行糾正。通常，基于關于用以發(fā)射數(shù)據(jù)的信道的失真和所發(fā)射數(shù)據(jù)的性質(zhì)的某信息來選擇所使用的特定碼。舉例來說，當已知信道具有長期的失真時，突發(fā)錯誤碼可能最適合于彼應用。當只是預期短的不頻發(fā)的錯誤時，簡單的奇偶檢驗碼可能是最佳的。如本文中所使用，“源數(shù)據(jù)”指代在一個或一個以上發(fā)送器處可用且使用接收器通過從具有或不具有錯誤和/或擦除的所發(fā)射序列恢復而獲得的數(shù)據(jù)，等等。如本文中所使用，“經(jīng)編碼數(shù)據(jù)”指代被傳送且可用以恢復或獲得源數(shù)據(jù)的數(shù)據(jù)。在簡單情況下，經(jīng)編碼數(shù)據(jù)是源數(shù)據(jù)的副本，但如果所接收的經(jīng)編碼數(shù)據(jù)與所發(fā)射的經(jīng)編碼數(shù)據(jù)不同(歸因于錯誤和/或擦除)，那么在這個簡單情況下，在缺少關于源數(shù)據(jù)的額外數(shù)據(jù)的情況下可能無法完全恢復源數(shù)據(jù)。傳輸可通過空間或時間來進行。在更復雜情況下，在變換中基于源數(shù)據(jù)產(chǎn)生經(jīng)編碼數(shù)據(jù)，且將其從一個或一個以上發(fā)送器發(fā)射到接收器。如果發(fā)現(xiàn)源數(shù)據(jù)是經(jīng)編碼數(shù)據(jù)的部分，那么將編碼稱為“系統(tǒng)的”。在系統(tǒng)編碼的簡單實例中，關于源數(shù)據(jù)的冗余信息被附到源數(shù)據(jù)的末尾，以形成經(jīng)編碼數(shù)據(jù)。同樣如本文中所使用，“輸入數(shù)據(jù)”指代存在于FEC(前向糾錯)編碼器設備或FEC編碼器模塊、組件、步驟等(“FEC編碼器”)的輸入處的數(shù)據(jù)，且“輸出數(shù)據(jù)”指代存在于FEC編碼器的輸出處的數(shù)據(jù)。相應地，將預期輸出數(shù)據(jù)存在于FEC解碼器的輸入處，且將預期FEC解碼器基于其所處理的輸出數(shù)據(jù)而輸出輸入數(shù)據(jù)或其對應物。在一些情況下，輸入數(shù)據(jù)是(或包含)源數(shù)據(jù)，且在一些情況下，輸出數(shù)據(jù)是(或包含)經(jīng)編碼數(shù)據(jù)。舉例來說，如果在FEC編碼器的輸入之前沒有處理，那么輸入數(shù)據(jù)將是源數(shù)據(jù)。然而，在一些情況下，源數(shù)據(jù)被處理成不同形式(例如，靜態(tài)編碼器、逆編碼器或另一過程)，以產(chǎn)生代替源數(shù)據(jù)被呈現(xiàn)給FEC編碼器的中間數(shù)據(jù)。在一些情況下，發(fā)送器裝置或發(fā)送器程序代碼可包括一個以上FEC編碼器，即，在一系列多個FEC編碼器中將源數(shù)據(jù)變換為經(jīng)編碼數(shù)據(jù)。類似地，在接收器處，可存在一個以上FEC解碼器，F(xiàn)EC解碼器被應用以從所接收的經(jīng)編碼數(shù)據(jù)產(chǎn)生源數(shù)據(jù)。數(shù)據(jù)可被認為分割成若干符號。編碼器是從源符號或輸入符號的序列產(chǎn)生經(jīng)編碼符號或輸出符號的計算機系統(tǒng)、裝置、電子電路或其類似者，且解碼器是從所接收或經(jīng)恢復的經(jīng)編碼符號或輸出符號恢復源符號或輸入符號的序列的對應物。編碼器和解碼器由信道在時間和/或空間上分開，且任何所接收的經(jīng)編碼符號可并不與對應所發(fā)射的經(jīng)編碼符號精確相同，且可能不按與發(fā)射經(jīng)編碼符號的序列精確相同的序列接收經(jīng)編碼符號。符號的“大小”可按位來測量，不管符號實際上是否被分成位流，其中當符號是選自具有2M個符號的字母表時，符號具有M個位的大小。在本文中的許多實例中，按八位字節(jié)來測量符號，且碼可能在具有256種可能的字段范圍內(nèi)(在每個八位字節(jié)內(nèi)存在256種可能的8位模式)，但應理解，可使用不同的數(shù)據(jù)測量單位，且以各種方式來測量數(shù)據(jù)是熟知的。在一般文獻中，術(shù)語“字節(jié)”有時與術(shù)語“八位字節(jié)”互換地使用，以指示8位值，但在一些上下文中，“字節(jié)”指示X位值，其中X不等于8，例如，X = 7，且因此，一般來說，本文中使用術(shù)語“八位字節(jié)”。除非另外指示，否則本文中的實例不限于每符號特定整數(shù)或非整數(shù)個位。Luby I描述使用碼(例如鏈式反應碼等)以計算高效、存儲高效且?guī)捀咝У姆绞絹硖幚砑m錯。由鏈式反應編碼器產(chǎn)生的經(jīng)編碼符號的一個特性是接收器能夠在一接收到足夠經(jīng)編碼符號后就恢復原始文件。具體來說，為了以高概率來恢復原始的K個源符號，接收器需要大約K+A個經(jīng)編碼符號。給定情形下的“絕對接收開銷”由值A表示，而“相對接收開銷”可計算為比率A/K。絕對接收開銷是對除信息理論最小數(shù)據(jù)量之外需要接收的額外數(shù)據(jù)量的測量，且絕對接收開銷可取決于解碼器的可靠性，且可依據(jù)源符號的數(shù)目K而變化。類似地，相對接收開銷A/Κ是對除信息理論最小數(shù)據(jù)量之外需要接收的額外數(shù)據(jù)量相對于正被恢復的源數(shù)據(jù)的大小的測量，且也可取決于解碼器的可靠性，且可依據(jù)源符號的數(shù)目K而變化。對于通過基于數(shù)據(jù)包的網(wǎng)絡的通信，鏈式反應碼是極有用的。然而，鏈式反應碼有時可能是在計算上相當繁重的。如果在使用鏈式反應或另一無碼率碼來編碼的動態(tài)編碼器之前使用靜態(tài)編碼器來編碼源符號，那么解碼器可能能夠更頻繁地或更容易地解碼。例如，在Shokrollahi I中展示了這些解碼器。在其處所示的實例中，源符號是送到靜態(tài)編碼器的輸入符號，靜態(tài)編碼器產(chǎn)生輸出符號，所述輸出符號是送到動態(tài)編碼器的輸入符號，動態(tài)編碼器產(chǎn)生輸出符號，所述輸出符號是經(jīng)編碼符號，其中動態(tài)編碼器是可按不與輸入符號的數(shù)目成固定比率的數(shù)量產(chǎn)生數(shù)個輸出符號的無碼率編碼器。靜態(tài)編碼器可能包含一個以上固定碼率的編碼器。舉例來說，靜態(tài)編碼器可能包含漢明編碼器、低密度奇偶校驗(“LDPC”)編碼器、高密度奇偶校驗(“HDPC”)編碼器和/或其類似者。鏈式反應碼具有如下特性:在解碼器處從所接收的符號恢復一些符號時，彼等符號可能能夠用以恢復額外符號，額外符號又可能用以恢復更多的符號。優(yōu)選地，在解碼器處解出的符號的鏈式反應可繼續(xù)，使得在用完所接收符號池之前恢復所有所要符號。優(yōu)選地，執(zhí)行鏈式反應編碼和解碼過程的計算復雜度低。解碼器處的恢復過程可能涉及確定接收了哪些符號，創(chuàng)建會將原始輸入符號映射到所接收的彼等經(jīng)編碼符號的矩陣，接著反轉(zhuǎn)矩陣，且執(zhí)行反轉(zhuǎn)矩陣與所接收的經(jīng)編碼符號的向量的矩陣乘法。在典型的系統(tǒng)中，此情形的強力實施可消耗過度的計算量和具有過多存儲要求。·當然，對于所接收的經(jīng)編碼符號的特定集合，恢復所有的原始輸入符號可能是不可能的，但即使有可能，計算出結(jié)果的計算成本仍可能是高的。前向糾錯(“FEC”)對象傳輸信息(“0 ”)或“FEC ΟΤΙ”基于接收器接收(或能夠推斷)的FEC 0ΤΙ，接收器可確定文件傳送的源塊和子塊結(jié)構(gòu)。在[Raptor-RFC-5053]和[RaptorQ-Spec]中，F(xiàn)EC 有效負載 ID 是(SBN，ESI)，其中在[Raptor-RFC-5053]中，源塊編號(SBN)是16個位，且編碼符號ID(ESI)是16個位，而在[RaptorQ-Spec]中，SBN是8個位，且ESI是24個位，如本文中圖1所圖解說明。此FEC有效負載ID格式的一個劣勢在于必須預先確定FEC有效負載ID的分配給SBN及分配給ESI的位數(shù)目，且有時難以確定將適用于所有文件傳遞參數(shù)的恰當混合。舉例來說，當使用[Raptor-RFC-5053]時，只有216 = 65，536個ESI可用在一些情形下可能有限制性，這是因為在一些情況下，可能存在具有8，192個源符號的源塊，且因此經(jīng)編碼符號的數(shù)目只大了 8倍，從而限制了可使用的可能碼率，在此情況下，所述碼率限制于不低于1/8。在此實例中，可能的狀況是，可用的216 = 65，536個源塊可能多于可能會使用的數(shù)目(例如，8，192個各具有1，024個八位字節(jié)的源符號)，可支持的文件大小是524GB，其在許多應用中比所需要的大小大兩個數(shù)量級。作為另一實例，當使用[RaptorQ-Spec]時，只有28 = 256個SBN可用在一些情形下可能限制性的，這是因為對于4GB文件，如果每一源塊限于8MB (其可為如下情況:如果最大子塊大小是256KB，最小子符號大小是32個八位字節(jié)，且符號大小是1，024個八位字節(jié))，那么將源塊的數(shù)目限于256又會將文件大小限于2GB。在此實例中，可能的狀況是，有224 = 16，777，216個可能經(jīng)編碼符號可用會多于可能會使用的數(shù)目(例如，具有8，192個源符號)，可能經(jīng)編碼符號的數(shù)目大了 2，048倍，此在一些應用中可能從來都不需要。另一合乎需要的特性是提供用于在文件的不同部分之間優(yōu)先化編碼傳輸?shù)哪芰Γ鰞?yōu)先化編碼傳輸有時還被稱作不等錯誤保護(“UEP”)。舉例來說，可能需要比剩余90%更有力地保護文件的前10%以免受包丟失。舉例來說，[LDPC-擴展]描述可如何擴展[LDPC-RFC-5170]以提供對UEP的支持。在此情況下，實際FEC碼自身被修改，以提供對文件的不同部分的不同等級的奇偶檢驗保護。然而，此方法存在缺點。舉例來說，不希望必須修改FEC碼自身以提供UEP，這是因為此舉使實施及測試FEC碼自身復雜化。此外，作為[LDPC-擴展]的圖6中所示結(jié)果，此方法的所得性能(就針對文件的不同部分提供的對包丟失的復原力而言)遠遠不是最佳。如[PET]和[PET-專利]中所描述，提供UEP文件傳遞能力的一種方式是為文件的不同部分根據(jù)其優(yōu)先級和大小分配每一包的不同部分。然而，所擔心的是如何并入有此等UEP方法，使得文件的每一不同部分可與文件的其它部分獨立地分割成源塊和子塊，以(例如)支持對文件的每一部分的小的存儲器解碼，且同時又在每一包內(nèi)提供允許接收器確定文件的每一部分的哪一符號含于每一包中的FEC有效負載ID。非常難以使用具有格式(SBN，ESI)的FEC有效負載ID來支持此并入，這是因為對于文件的每一部分，針對文件第一部分的包中符號的對應SBN和ESI可能不同于針對文件第二部分的包中符號的SBN和ESI。HTTP修復方法在(例如)用于廣播/組播文件傳遞的3GPP MBMS標準TS26.346中進行修復請求的方式是使用在[Raptor-RFC-5053]中指定的FEC有效負載ID，S卩，通過指定源塊編號(SBN)和編碼符號識別符(ESI)。雖然此方法在對修復請求作出響應的服務器具有要求服務器確定用于廣播/組播文件傳遞的文件傳遞結(jié)構(gòu)(即，要求服務器解譯文件中的哪些部分是由所請求的SBN和ESI參考的)的專門方法的情況下是合理的，但是此舉要求知道源塊和子塊結(jié)構(gòu)，以及符號大小T。另一方面，可存在數(shù)百萬個散布在大的地理區(qū)域之上的廣播/組播接收器，且要求部署專門的響應服務器從資本費用及從操作的角度來看是既昂貴又麻煩的。廣泛部署的是支持因特網(wǎng)傳遞(例如，網(wǎng)頁、視頻流式傳輸?shù)?的標準HTTP網(wǎng)絡服務器和網(wǎng)絡高速緩存。所需要的是支持使用標準HTTP網(wǎng)絡服務器和網(wǎng)絡高速緩存作為廣播/組播響應服務器的方法。

發(fā)明內(nèi)容
在文件傳遞方法和設備的實施例中，通用文件符號識別符(“UFSI”)或通用對象符號識別符(“U0SI”)與包相關聯(lián)，與所述包一起提供，以識別所述包內(nèi)的結(jié)構(gòu)，需要所述結(jié)構(gòu)以用于識別含于所述包內(nèi)的編碼符號。當如此使用時，所述UFSI/U0SI允許對FEC和文件/對象傳遞的增強處置，包括:不等錯誤保護，其中并非所傳遞數(shù)據(jù)的所有部分都具有相同等級的FEC保護；以及捆綁對象傳遞，其中可比單獨地處置多個對象的情況更有效地處置多個對象。以下詳細描述將與隨附圖式一起提供對本發(fā)明的性質(zhì)和優(yōu)勢的更佳理解。


圖1是圖解說明了常規(guī)FEC有效負載ID的圖；圖1A圖解說明了用于Raptor-RFC5053的FEC有效負載ID，而圖1B圖解說明了用于RaptorQ-Spec的FEC有效負載ID。圖2是圖解說明了用于基本通用文件傳遞(“UFD”)方法的FEC有效負載ID的圖。圖3是圖解說明了發(fā)送器基本UFD方法的流程圖。圖4是圖解說明了接收器基本UFD方法的流程圖。圖5是圖解說明了文件的符號的(SBN，ESI)標識和與文件的符號的對應通用文件符號識別符(“UFSI”)的映射的實例。圖6是圖解說明了發(fā)送器通用文件傳遞、不等錯誤保護(“UFD-UEP”)方法的流程圖。圖7是圖解說明了接收器UFD-UEP方法的流程圖。圖8圖解說明了包括各自具有不同優(yōu)先級的兩個部分的文件的(SBN，ESI)標識的實例。圖9圖解說明了來自文件的兩個部分的經(jīng)編碼符號的(SBN，ESI)識別符與含有所述部分的經(jīng)編碼符號以及包含于每一包中的UFSI的包之間的映射的對應于圖8的實例。圖10圖解說明了使用[RaptorQ-Spec]的簡單UEP文件傳遞方法的性能。圖11圖解說明了都使用[RaptorQ-Spec]的簡單UEP文件傳遞方法與UFD-UEP文件傳遞方法之間的實例性能比較。圖12圖解說明了都使用[RaptorQ-Spec]的一個文件的文件傳遞、多個文件的文件傳遞與UFD捆綁文件傳遞方法之間的實例性能比較。圖13是通信系統(tǒng)的方框圖，所述通信系統(tǒng)可用于產(chǎn)生、發(fā)送及接收Raptor、RaptorQ或其它包作為文件傳遞的部分。圖14是可在其中進行文件傳遞的通信系統(tǒng)的圖示，其中一個接收器從多個通常獨立的發(fā)送器接收輸出符號。圖15是可在其中進行文件傳遞的通信系統(tǒng)的圖示，其中多個可能獨立的接收器從多個通常獨立的發(fā)送器接收輸出符號，接收輸入文件的時間少于在只使用一個接收器和/或只使用一個發(fā)送器的情況下的時間。圖16描繪可用以使用HTTP流式傳輸服務器提供文件傳遞的塊請求流式傳輸系統(tǒng)的元件。圖17圖解說明了圖16的塊請求流式傳輸系統(tǒng)，其更詳細圖解說明了可用于文件傳遞的客戶端系統(tǒng)的元件，客戶端系統(tǒng)耦合到塊服務基礎結(jié)構(gòu)(“BSI”)以接收由內(nèi)容注入系統(tǒng)處理的數(shù)據(jù)。圖18圖解說明了可用以準備文件以供文件傳遞的注入系統(tǒng)的硬件/軟件實施。圖19圖解說明了可用以接收傳遞到客戶端系統(tǒng)的文件的客戶端系統(tǒng)的硬件/軟件實施。圖20圖解說明了通用FEC OTI元素格式的實例。圖21圖解說明了方案特定的FEC OTI元素格式的實例。
具體實施例方式在本文中的實施例中，文件傳遞由發(fā)送文件的編碼器/發(fā)射器系統(tǒng)和接收文件的接收器/解碼器系統(tǒng)執(zhí)行。協(xié)調(diào)傳輸?shù)母袷?，使得解碼器理解編碼器所編碼的數(shù)據(jù)。如下文各種實例中所示，文件傳遞是一般對象傳遞的實例，且除非另外指示，否則從此等實例應顯而易見，可將對象當作文件，且可能將文件當作對象。在包傳遞系統(tǒng)中，數(shù)據(jù)被組織為包，且作為包發(fā)射。每一包具有允許接收器確定包中有什么及所述包是如何布置的元素。通過使用本文中所描述的技術(shù)，為發(fā)射使用前向糾錯(“FEC”)的包提供了靈活性。通過使用此等技術(shù)，可提供不等FEC保護，以及文件的捆綁傳遞。熟知的是，當許多文件被作為單獨文件傳遞時，傳遞對包丟失的復原力可比在所有文件一起被連成較大文件且在傳遞中保護所述較大文件的情況下的復原力小得多。然而，需要發(fā)出作為較小文件的組合的較大文件的結(jié)構(gòu)的信號，且為了恢復大文件內(nèi)的任何較小文件，接收器通常需要恢復整個大文件，即使接收器僅關注恢復較小文件的子集也是如此。因此，優(yōu)選文件傳遞系統(tǒng)或方法應允許用作文件的文件傳遞結(jié)構(gòu)的源塊數(shù)目與每源塊的編碼符號數(shù)目的任何靈活組合。還應存在如下情況:文件傳遞方法提供針對包丟失的有效保護，且支持文件的不同部分受到不同優(yōu)先級的保護的文件傳遞，其中文件的每一部分可具有不同于文件的其它部分的源塊結(jié)構(gòu)和子塊結(jié)構(gòu)。再一次，在一些情況下文件被視為對象的特定實例，但在本文中應理解，本文中用以描述文件的輸送和處置的實例也可用于可能不被稱作文件的數(shù)據(jù)對象，例如來自數(shù)據(jù)庫的大數(shù)據(jù)塊、視頻序列的部分，等等。文件/對象傳遞系統(tǒng)或方法應提供:具有大文件/對象的保護效率的許多較小文件/對象的傳遞、較小文件/對象結(jié)構(gòu)的簡單發(fā)信號，及接收器只獨立地恢復較小文件/對象的子集而不恢復所有較小文件/對象的能力?，F(xiàn)將描述具有此等合乎需要的性質(zhì)的系統(tǒng)的實例?；就ㄓ梦募鬟f(“UFD”)方法和系統(tǒng)現(xiàn)將描述基本通用文件傳遞(“UFD”)方法和對應的系統(tǒng)，其中UFD包含相比于現(xiàn)有文件傳遞方法的顯著優(yōu)勢。用于基本UFD方法的前向糾錯(“FEC”)有效負載ID包括通用文件符號識別符(“UFSI”)字段，所述字段(例如)可為32位字段?，F(xiàn)將依次描述基本UFD方法的發(fā)送器和接收器方法。再一次，當文件被稱作對象時，“UFSI”可能被替代地稱作“U0SI” (通用對象符號識別符)。參看圖3描述發(fā)送器基本uro方法。發(fā)送器可使用現(xiàn)有方法來產(chǎn)生(例如)如[Raptor-RFC-5053]或[RaptorQ-Spec]中所描述的FEC對象傳輸信息(“0ΤΙ”)(參見(例如)[RaptorQ-Spec]第4.3章)，且使用FEC OTI來確定將用以發(fā)射文件的源塊和子塊結(jié)構(gòu)，且確定(SBN，ESI)對與文件的經(jīng)編碼符號之間的關系(參見(例如)[RaptorQ-Spec]第4.4章)。舉例來說，如[RaptorQ-Spec]中所描述，所產(chǎn)生的FEC OTI可為(F，Al，T，Z，N)，其中F是待發(fā)射的文件的大小，Al是用以確保子符號在是Al的倍數(shù)的存儲器邊界上對準的對準因子，T是待產(chǎn)生且在傳輸中發(fā)送的符號的大小，Z是文件為了傳輸所分割成的源塊的數(shù)目，且N是每一源塊為了傳輸所分割成的子塊的數(shù)目。此情形如圖3的步驟300中所
/Jn ο發(fā)送器可形成將要在包中發(fā)送的經(jīng)編碼符號，且使用現(xiàn)有方法基于源塊產(chǎn)生此等經(jīng)編碼符號的SBN和ESI，且如果使用子塊，那么還使用子塊結(jié)構(gòu)，例如，如[RaptorQ-Spec]中所描述。每當將要發(fā)送經(jīng)編碼符號時，發(fā)送器可確定將要產(chǎn)生的經(jīng)編碼符號的SBNA和ESIB，如圖3的步驟310中所示，且接著發(fā)送器可基于(SBN，ESI) = (A, B)使用現(xiàn)有技術(shù)(例如，[RaptorQ-Spec]中所描述的技術(shù))產(chǎn)生經(jīng)編碼符號的值，如圖3的步驟320中所示。接著，將彼經(jīng)編碼符號的UFSIC計算為C = B*Z+A，如圖3的步驟330中所示。發(fā)送器可在包中發(fā)送經(jīng)編碼符號，其中包的FEC有效負載ID被設定為經(jīng)編碼符號的UFSIC，如圖3的步驟340中所示。發(fā)送器接著可確定是否要發(fā)送更多的經(jīng)編碼符號，如圖3的步驟350中所示，且如果是這樣，那么發(fā)送器可產(chǎn)生額外經(jīng)編碼符號以發(fā)送，如到圖3的步驟310的“是”分支所示，且如果不是這樣，那么發(fā)送器可結(jié)束，如到圖3的步驟360的“否”分支所示。可存在發(fā)送器基本UFD方法的許多變化。舉例來說，發(fā)送器可在包中的至少一些包中發(fā)送一個以上經(jīng)編碼符號，在所述情況下，F(xiàn)EC有效負載ID可設定為含于包中的第一經(jīng)編碼符號的UFSI，且可選擇含于包中的額外符號，使得其對應UFSI值為連續(xù)的。舉例來說，如果在包中攜帶有三個經(jīng)編碼符號，且第一個此種符號具有UFSI = 4，234，那么其它兩個經(jīng)編碼符號可分別為具有UFSI4，235和UFSI4，235的符號。作為其它替代方案的實例，發(fā)送器可預先確定產(chǎn)生多少經(jīng)編碼符號，且在產(chǎn)生任何經(jīng)編碼符號之前確定將要產(chǎn)生的所有經(jīng)編碼符號的(SBN，ESI)值。作為另一實例，可在無產(chǎn)生(SBN，ESI)值的中間步驟的情況下直接產(chǎn)生UFSI值。作為變化的另一實例，可產(chǎn)生其它形式的FEC OTI信息。舉例來說，基本UFSI BU可包含于文件的FEC OTI中，基本UFSI BU可按如下方式使用:含于包中的經(jīng)編碼符號的將由FEC發(fā)送器和接收器使用的UFSI是U+BU，其中U是在攜帶經(jīng)編碼符號的包中所攜帶的UFSI。因此，例如，如果包攜帶U = 1，045，且FEC OTI中的基本UFSI是BU = 2，000，000，那么經(jīng)編碼符號UFSI是2，001，045。使用基本UFSI具有若干優(yōu)勢。舉例來說，[FLUTE]、[ALC]、[LCT]、[FEC BB]中所描述的協(xié)議組將又稱作TOI的傳輸對象識別符與待輸送的文件或?qū)ο蟮腇EC OTI相關聯(lián)。有可能的是，相同文件的經(jīng)編碼符號可在不同時間或在不同會話中發(fā)送，且可與不同TOI相關聯(lián)。又，能夠?qū)τ谂c每一不同TOI相關聯(lián)的包，發(fā)送以UFSI=O開始的經(jīng)編碼包是有利的。通過具有指定基本UFSI作為FEC OTI的部分的能力，不同基本UFSI可與文件的待發(fā)送的經(jīng)編碼符號所針對的每一 TOI相關聯(lián)，而不針對不同TOI發(fā)送重復的經(jīng)編碼符號。舉例來說，相同文件的經(jīng)編碼符號可在與TOI = I相關聯(lián)及與TOI=2相關聯(lián)的包中發(fā)送，其中與TOI = I相關聯(lián)的基本UFSI設定為0，且其中與TOI = 2相關聯(lián)的基本UFSI設定為1，000, 000。接著，TOI = I及TOI = 2兩者的經(jīng)編碼包可含有UFSIO、UFSIU UFS12等的序列，且將不存在在與兩個TOI相關聯(lián)的所發(fā)送經(jīng)編碼符號當中發(fā)送的重復的經(jīng)編碼符號，只要針對具有TOI = I的文件發(fā)送的經(jīng)編碼符號少于1，000，000個即可。參看圖4描述接收器基本UFD方法。接收器可使用現(xiàn)有技術(shù)來確定與上文對于發(fā)送器所描述的格式相同的格式的FEC OTI (F，Al，T，Z，N)，如圖4的步驟400中所示。舉例來說，F(xiàn)EC OTI可嵌入于FLUTE會話描述中，或FEC OTI可編碼于URL中，或可通過SDP消息獲得FEC 0ΤΙ。在步驟410中，接收器查看是否接收到更多經(jīng)編碼符號，且接收器可停留在這個步驟，直到接收器接收到另一經(jīng)編碼符號(在所述情況下，接收器繼續(xù)進行到步驟430)，或接收器確定將不會接收更多的經(jīng)編碼符號，在所述情況下，接收器繼續(xù)進行到步驟420，且試圖使用其它方法(例如，使用對文件修復服務器的HTTP請求)來恢復文件，或接收器可等待另一會話以在稍后接收更多經(jīng)編碼符號，或接收器可決定無法恢復文件。當另一經(jīng)編碼符號可用時，在步驟430中，接收器確定經(jīng)編碼符號的UFSIC，且接收經(jīng)編碼符號的值。在步驟440中，接收器基于源塊的數(shù)目Z和UFSIC，計算A = C模Z，且B =下限(C/Z)，且在步驟450中，接收器將經(jīng)編碼符號的(SBN，ESI)設定為(A，B)，且在步驟460中，接收器存儲經(jīng)編碼符號的值和(A，B)以用于文件恢復。在步驟470中，接收器確定是否存在足以恢復文件的所接收的經(jīng)編碼符號，且如果是這樣，那么繼續(xù)進行在步驟480中恢復文件，且如果不是這樣，那么繼續(xù)進行在步驟410中接收更多經(jīng)編碼符號?？纱嬖诮邮掌骰綰FD方法的許多變化。舉例來說，接收器可在包中的至少一些包中接收一個以上經(jīng)編碼符號，在所述情況下，F(xiàn)EC有效負載ID可設定為含于包中的第一經(jīng)編碼符號的UFSI，且包中的額外符號可具有連續(xù)的對應UFSI值。舉例來說，如果在包中攜帶有三個經(jīng)編碼符號，且第一個此種符號具有UFSI = 4，234，那么其它兩個經(jīng)編碼符號可分別為具有UFSI4，235和UFSI4，235的符號，且包中所攜帶的UFSI可能為第一經(jīng)編碼符號的UFSI = 4，234。作為其它替代方案的實例，接收器可預先確定在試圖恢復之前接收多少經(jīng)編碼符號。作為另一實例，接收器可進行用以確定是否已接收到足夠用來恢復文件的經(jīng)編碼符號的特定于FEC碼的某種處理。作為另一實例，可在沒有在恢復過程中產(chǎn)生(SBN，ESI)值的中間步驟的情況下直接使用UFSI值。作為另一實例，文件的恢復可與經(jīng)編碼符號的接收同時發(fā)生。作為另一實例，可使用其它形式的FEC OTI信息。組合基本UFD方法與[RaptorQ-Spec]中所描述的技術(shù)以用于確定源塊和子塊結(jié)構(gòu)提供了許多優(yōu)勢。舉例來說，用于發(fā)射文件的目的的由SBN和ESI的組合識別的在先前方法中被稱作源符號的符號可在使用基本UFD方法時被視為由UFSI識別的文件符號。使F為待發(fā)射的文件的大小(按八位字節(jié)計)，且使T為當發(fā)射文件時用于FEC編碼/解碼目的的符號大小，且因此KT =上限(F/T)是文件中的符號的總數(shù)目，其中上限(X)是大于或等于X的最小整數(shù)。當如(例如)[RaptorQ-Spec]中所描述地確定源塊結(jié)構(gòu)和子塊結(jié)構(gòu)，且使用上文所描述的基本UFD方法將符號的標識自(SBN，ESI)格式轉(zhuǎn)換為UFSI格式及從UFSI格式轉(zhuǎn)換為(SBN，ESI)格式時，文件符號的UFSI的范圍是0，1，2，...，KT，且從文件產(chǎn)生的任何修復符號將具有在范圍ΚΤ+1、ΚΤ+2等中的UFSI。此特性允許通過簡單地比較符號的UFSI與值KT來確定符號是原始文件的部分還是從文件產(chǎn)生的修復符號。此情形可為有用的，(例如)允許不支持FEC解碼的接收器基于包中攜帶的UFSI值，且基于文件的KT值，確定哪些符號是原始文件的部分(及其在文件內(nèi)的位置)，且哪些符號可作為修復符號忽略。圖5圖解說明了一個實例，其中在此情況下，文件大小是F = 28, 669八位字節(jié)，符號大小為T = 1，024八位字節(jié)，且因此KT =上限(F/T) = 28。在圖5中，文件的符號的(SBN7ESI)標不展不于頂部,其中每一行對應于源塊,且每一列對應于具有相同ESI值的符號。符號的對應UFSI標示展示于底部。在此情況下，具有UFSI = 27的符號(即，相對于UFSI標示的第28個符號)出于FEC編碼及解碼的目的而使其最后(KT*T)-F3個八位字節(jié)用零來填滿，但不需要發(fā)射此符號的此等最后三個填充的八位字節(jié)。在此實例中，具有UFSI28或大于UFSI28的任何經(jīng)編碼符號是修復符號，其中具有UFSI28的經(jīng)編碼符號是從具有SBN=3的源塊產(chǎn)生，具有UFSI29的經(jīng)編碼符號是從具有SBN = 4的源塊產(chǎn)生，具有UFSI30的經(jīng)編碼符號是從具有SBN = O的源塊產(chǎn)生，等等。如所屬領域的技術(shù)人員將認識到，存在此特性的許多其它優(yōu)勢。基本UFD方法的另一優(yōu)勢是，如果經(jīng)編碼符號是按由其UFSI定義的次序(S卩，按
UFSI次序0、1、2、3、4......)發(fā)送，那么Z個源塊的經(jīng)編碼符號是按交錯次序發(fā)送(B卩，首
先發(fā)送來自Z個源塊中的每一者的具有ESIO的Z個經(jīng)編碼符號，接著發(fā)送來自Z個源塊中的每一者的具有ESIl的Z個經(jīng)編碼符號，等等)。對于大多數(shù)傳輸，此簡單發(fā)送次序是足夠且優(yōu)選的。然而，在包丟失經(jīng)歷可能與源塊的數(shù)目Z同步的某一周期的情況下，潛在更佳的發(fā)送次序是在發(fā)送經(jīng)編碼符號之前隨機置換Z個UFSI連續(xù)經(jīng)編碼符號的每一集合，即，按
隨機置換次序發(fā)送具有UFSI0.....Z-1的前Z個經(jīng)編碼符號，且接著按隨機置換次序發(fā)送
具有UFSI Z.....2*Z-1的接下來Z個經(jīng)編碼符號，等等。通過此描述，應理解，“隨機”可
包含偽隨機，除非另外指示。使用基本UFD方法提供相比于先前已知方法的許多額外優(yōu)勢。舉例來說，當使用包括預先確定大小的SBN和ESI字段的FEC有效負載ID時，存在單獨的預先確定數(shù)目個可能的源塊或每源塊的預先確定數(shù)目個可能的經(jīng)編碼符號。舉例來說，產(chǎn)生32位FEC有效負載ID的8位SBN和24位ESI將可能的源塊的數(shù)目限于256，且將每源塊的可能的經(jīng)編碼符號的數(shù)目限于16，777，216。替代地，包括UFSI字段的FEC有效負載ID只限制文件的可能的經(jīng)編碼符號的總數(shù)，其獨立于文件的源塊結(jié)構(gòu)。舉例來說，當使用產(chǎn)生32位FEC有效負載ID的32位UFSI時，文件的可產(chǎn)生的經(jīng)編碼符號的總數(shù)是4，294，967，296，其獨立于文件所分割成的源塊的數(shù)量，且在使用子塊的情況下獨立于文件的子塊結(jié)構(gòu)。因此，如果符號的大小是1，024個八位字節(jié)，那么在此實例中，文件大小可高達4GB，且經(jīng)編碼符號的數(shù)目可為文件大小的1，024倍，其獨立于文件是被分割成一個源塊、16，384個源塊還是4，194，304個源塊。作為另一實例，文件大小可為2TB，且經(jīng)編碼符號的數(shù)目可為文件大小的兩倍。在所有情況下，如果使用子塊結(jié)構(gòu)，那么文件的可產(chǎn)生的經(jīng)編碼符號的數(shù)目獨立于文件的子塊結(jié)構(gòu)。用于不等錯誤保護文件傳遞服務的通用文件傳遞方法大多數(shù)先前文件傳遞方法不支持不等錯誤保護(“UEP”)文件傳遞。存在一些先前方法，例如，當前在ISDB-Tmm(陸地移動多媒體)標準中指定的方法，所述先前方法使用[LDPC-擴展]中所描述的方法，所述方法通過改變用以編碼文件的不同部分的實際FEC碼來支持UEP。除了在使用UEP時必須改變實際FEC碼的劣勢之外，另一劣勢是由此等方法提供的保護遠遠不夠理想。作為實例，考慮結(jié)果展示于[LDPC-擴展]的圖6中的實例。在彼實例中，存在將在包中發(fā)送的大小為1，000ΚΒ的文件的兩個部分，每一包含有IKB符號:文件的第一部分具有大小30KB，且由100個奇偶檢驗或修復包保護，且文件的第二部分是970KB，且針對文件發(fā)送總共1，000個源包和1，000個奇偶檢驗包。由于兩個問題，所提供的保護遠遠不夠理想。一個問題是所使用的FEC碼(基于[LDPC-RFC-5170])常常需要顯著的接收開銷以恢復源塊，即，需要接收比文件中的源包多的包來恢復文件。第二問題是方法基本上使用與用來發(fā)送且保護文件的第二部分的包的集合獨立的包的集合發(fā)送且保護文件的第一部分。對于第二問題，從針對文件的第一部分發(fā)送的130個包當中接收30個包的方差可為大的，這是因為文件的第一部分是通過此小數(shù)目個包來發(fā)送的。
可通過擴展對[LDPC-擴展]中所描述的UEP文件傳遞方法進行改進，所述擴展在本文中被稱作“簡單UEP”文件傳遞方法。簡單UEP文件傳遞方法使用用于文件傳遞的現(xiàn)有技術(shù)，且基于文件的部分的優(yōu)先級對于文件的每一部分使用不同的保護量而將文件的部分作為單獨的文件傳遞來傳遞，且接著可發(fā)出文件的部分之間的邏輯連接的信號，使得接收器將知道所傳遞的文件是相同文件的部分。舉例來說，簡單UEP文件傳遞方法可使用上文實例中的[RaptorQ-Spec]來通過發(fā)送總計130個包來傳遞文件的前30KB部分,包中的每一者含有從第一部分產(chǎn)生的大小為1，024八位字節(jié)的經(jīng)編碼符號，且接著文件的第二970KB部分可通過發(fā)送總計1870個包而作為單獨文件來傳遞，包中的每一者含有從第二部分產(chǎn)生的大小為1，024八位字節(jié)的經(jīng)編碼符號。因此，針對作為單獨文件發(fā)送的文件的兩個部分發(fā)送總計2，000個包。簡單UEP文件傳遞方法是相對于[LDPC-擴展]中所描述的方法的改進，這是因為未修改FEC碼自身，且是因為(如本文中圖10中所示)在不同包丟失條件下文件的兩個部分的傳遞性能優(yōu)于[LDPC-擴展]的圖6中所示的性能。差別的一個可能來源是因為[RaptorQ-Spec]中指定的FEC碼具有優(yōu)于[LDPC-RFC-5170]中所指定的FEC碼的恢復特性。然而，簡單UEP文件傳遞方法仍遭受上文所描述的第二問題。[PET]和[PET-專利]提供了用于提供UEP文件傳遞服務的潛在改進的方法，其中每一包含有來自文件的每一部分的基于所述部分的優(yōu)先級的指定量的編碼數(shù)據(jù)。[PET]的直接并入將為在每一包中包含文件的每一部分的具有適當大小的經(jīng)編碼符號，且接著包含文件的每一部分的包括(SBN，ESI)對的單獨FEC有效負載ID。然而，此方法出于幾個原因而不是有利的。舉例來說，當使用每一部分的包括預先確定大小的SBN和ESI字段的FEC有效負載ID時，對于文件的每一部分存在單獨的預先確定數(shù)目個可能的源塊或每源塊的預先確定數(shù)目個可能的經(jīng)編碼符號。舉例來說，d個部分中的每一者的8位SBN和24位ESI產(chǎn)生(32*d)位FEC有效負載ID，其將每部分的可能的源塊的數(shù)目限于256，且將每源塊的可能的經(jīng)編碼符號的數(shù)目限 于16，777，216。此外，如果對于d個部分中的每一者，F(xiàn)EC有效負載ID大小是32位，那么此情形將意謂，只是針對每一包中的FEC有效負載ID標頭，每一包中的所有部分的FEC有效負載ID總計為32*d位，例如，如果d = 10，那么32*d是320位，或等效地40八位字節(jié)。可擴展用于文件傳遞的基本uro方法，以提供如下文詳細描述的不等錯誤保護(UEP)文件傳遞服務，其提供相比先前UEP文件傳遞方法的顯著優(yōu)勢。在本文中，此等擴展方法被稱作“UFD-UEP ”文件傳遞方法。此等UFD-UEP文件傳遞方法可使用[PET]和[PET-專利]中所描述的方法中的一些方法。現(xiàn)將更詳細描述實例UFD-UEP文件傳遞方法。在此方法中，發(fā)送器將大小為F的
文件分割成大小為匕、F1.....Fd^1的d > I個部分，且因此F等于i個Fi的總和。發(fā)送器
將包大小T分割成大小為I；、T1.....Td^1的d個部分，且因此T等于i個Ti的總和。T的
此分割是基于匕、F1.....Fd^1和對應文件部分的優(yōu)先級。比率FiZti確定了在假定使用理
想FEC碼來保護作為一個源塊的文件的部分i的情況下需要接收多少包以恢復文件的部分i，且因此比率FiZti越小，文件的部分i的優(yōu)先級越高。在實踐中，可能需要略高于FiZtiA包以恢復文件的部分i，例如，這是因為FEC碼不是理想的且會展現(xiàn)某一接收開銷；或因為文件的部分被分割成多個源塊，且一些源塊的經(jīng)編碼符號以高于其它源塊的速率丟失；或因為FiZti不是整數(shù)。作為UEP的實例，假設F = IMB, T=I, 024八位字節(jié)，d = 2, F0 =32KB，F(xiàn)1 = F-F0 = 992KB，且Ttl = 64八位字節(jié)，T1 = T-T0 = 960八位字節(jié)。在此實例中，F(xiàn)。/!； = 512，且因此理想地，接收512個包允許恢復文件的部分0，而F1Zt1 = I, 058.13，且因此理想地，接收1，059個包允許恢復文件的部分I。因此，在此實例中，可從粗略為恢復文件的部分I所需要的包的一半的包恢復文件的部分O。注意到，在此實例中，如果未使用UEPJM= I，且因此F。= F= 1MB，且Ttl = T =1，024八位字節(jié)，那么需要FcZTci = 1，024個包來恢復文件。因此，在先前段落中所描述的UEP實例中，文件的部分I的恢復需要比未使用UEP時的包略多的包，這是歸因于文件的部分O的較高優(yōu)先級。對此基本取舍的分析研究可在[PET]中找到。對于發(fā)送器UFD-UEP方法，存在基于匕、F1.....Fd^1和不同文件部分的優(yōu)先級產(chǎn)
生T的分割部分V T1.....V1的各種方式。注意到，如果選擇Ti以使得FiAi F/T，那
么文件的部分i被認定具有平均優(yōu)先級，且部分i的優(yōu)先級將分別取決于FiZti < F/T或是FiAi > F/T而相對較高或較低。現(xiàn)參看圖6描述用于產(chǎn)生FEC OTI的發(fā)送器UFD-UEP方法。給定d、F。、F1,...,,
F^、Tq、T1.....Ttw、Al、WS的值，可獨立地使用現(xiàn)有方法(例如，使用[RaptorQ-Spec]第
4.3章中所描述的方法)如常計算應用于文件的d個部分中的每一者的FEC 0TI，S卩，對于
每一 i = 0.....d-Ι，發(fā)送器可產(chǎn)生用于文件部分i的FEC 0ΤΙ，所述FEC OTI確定如何使
用(例如)[RaptorQ-Spec]第4.3章中所描述的方法將文件部分i分割成源塊和子塊，所述方法將Fi當作文件大小， 且將Ti當作用以在每一包中攜帶部分i的信息的符號大小。發(fā)送器因此與文件的其它部分獨立地產(chǎn)生用于文件的部分i的FEC 0ΤΙ。此過程在本文中的圖6的步驟600中展示。發(fā)送器還可產(chǎn)生如下各者:將文件的部分i分割成源塊和子塊，及文件的部分i的經(jīng)編碼符號的(SBN，ESI)與如何使用現(xiàn)有方法(例如，[RaptorQ-Spec]第4.4章和其中的第5章中所描述的方法)從文件的部分i產(chǎn)生經(jīng)編碼符號之間的映射。此等UFD-UEP方法被與文件的其它部分獨立地應用于文件的部分i，且因此，文件的不同部分可具有不同源塊及子塊結(jié)構(gòu)，且確切地說，在文件的不同部分之間可存在每源塊的不同數(shù)目個源符號及不同數(shù)目個源塊，這是因為所述方法是獨立于文件的每一部分來應用的。對準因子Al優(yōu)選地對于文件的所有部分是相同的，且確切地說，對于每一部分i，值Ti是Al的倍數(shù)是優(yōu)選的。此外,如果(例如)使用[RaptorQ-Spec]第4.5章中所描述的方法來導出FEC 0ΤΙ，那么當針對文件的部分中的每一者導出源塊和子塊結(jié)構(gòu)時使用Al和WS的相同值是優(yōu)選的。針對Al使用相同值確保了可在接收器處在存儲器上與Al八位字節(jié)的倍數(shù)對準地發(fā)生解碼，且針對WS使用相同值確保了在接收器處在隨機存取存儲器(RAM)中需要解碼的最大塊大小對于文件的所有部分是相同的。存在針對文件的不同部分使用不同WS值導出FEC OTI是優(yōu)選的一些應用，例如，在需要使用較少存儲器來恢復文件的較高優(yōu)先級部分的情況下?？纱嬖卺槍Σ煌糠质褂貌煌瑢室蜃邮怯欣娜舾蓱?。舉例來說，高優(yōu)先級部分可由具有4八位字節(jié)對準的存儲器的低端接收器和具有8八位字節(jié)對準的存儲器的高端接收器解碼，而低優(yōu)先級部分僅可由高端接收器解碼。在此實例中，針對高優(yōu)先級部分使用Al = 4，使得低端接收器可有效地解碼此等部分可為有利的，而針對低優(yōu)先級部分使用Al = 8可為有利的，這是因為與Al = 4相比，高端接收器可在Al = 8的情況下更有效地解碼此等部分。由特定于文件部分i的發(fā)送器UFD-UEP方法產(chǎn)生的對應FEC OTI包括FpTi, ,Zi,、Ni,其中Zi是文件的部分i所分割成的源塊的數(shù)目，且Ni是文件的部分i的每一源塊所分割成的子塊的數(shù)目。因此，總的來說，發(fā)送器UFD-UEP方法針對文件產(chǎn)生的FEC OTI可包括:
(d、Al、F。、V Z0, N0、F1' T” Z1' N1.....Fd_” ^、Zd_” Nd^1)。FEC OTI 的其它版本也是可用
的，例如，當d固定，且因此不需要明確地在FEC OTI中列出時，或當使用其它方法來指示源塊結(jié)構(gòu)及子塊結(jié)構(gòu)(如果使用的話)時。發(fā)送器使用UFD-UEP方法在包中組裝待發(fā)送的文件的每一部分的一個經(jīng)編碼符號，且包的FEC有效負載ID包括UFSI值C。當包將被發(fā)送時，發(fā)送器確定將用作包的FEC有效負載ID的UFSI值C，如圖6的步驟610中所示。將使用的UFSI值(例如)可為連續(xù)
的，例如，UFSI值0、1、2、3.....等。對于給定UFSI值C，在文件的部分i的包中將放置在
包的第i個部分中的大小為Ti的經(jīng)編碼符號具有SBNAi和ESIBi,其計算為Ai = C模Zi,且Bi =下限(C/%)，如圖6的步驟620中所示。對于i = O、...、d-l，針對包的d個部分中的每一者產(chǎn)生此等d個經(jīng)編碼符號，且接著在包中將UFSIC與集合大小為T的此等d個經(jīng)編碼符號一起發(fā)送，如圖6的步驟630、640和650中所示。發(fā)送器UFD-UEP方法繼續(xù)產(chǎn)生且發(fā)送經(jīng)編碼包，如圖6的步驟660中進行的決定所示。參看圖7描述接收器UFD-UEP方法。接收器可使用現(xiàn)有技術(shù)來確定如上文所描述
的與發(fā)送器的情況相同格式的 FEC OTI (d、Al、F。、Ttl、Ztl、N。、F1、1\、Z1、N1.....1V1、V1、Ztw、
Nd^1)，如圖7的步驟700中所示。舉例來說，F(xiàn)EC OTI可嵌入于FLUTE會話描述中，或FECOTI可編碼于URL中，或可通過SDP消息獲得FEC OT10在步驟710中，接收器查看是否接收到更多包，且接收器可停留在這個步驟，直到接收器接收到另一包(在所述情況下，接收器繼續(xù)進行到步驟730)，或接收器確定將不會接收更多的包，在所述情況下，接收器繼續(xù)進行到步驟720，且確定已恢復文件的足夠部分并停止，或者試圖使用其它方法(例如，使用對文件修復服務器的HTTP請求)來恢復文件的額外部分，或接收器可等待另一會話以在稍后接收更多包。當另一包可用時，在步驟730中，接收器確定所接收包的UFSIC，且對于每一 i =
O、...、d-l，從包(對于每一 i = O、...、d-l)中提取大小為Ti的經(jīng)編碼符號。在步驟740
中，對于每一 i = 0.....d-Ι，接收器基于源塊的數(shù)目Zi和UFSIC，計算Ai = C模21;且&
=下限(C/%)，且在步驟750中，接收器將部分i的經(jīng)編碼符號的(SBN，ESI)設定為(Ai,Bi),且在步驟760中，接收器存儲部分i的經(jīng)編碼符號的值和(AiAi)以用于恢復文件的部
分i。在步驟770中，接收器對于每一 i = 0.....d-Ι確定是否存在足夠用以恢復文件的
部分i的所接收的經(jīng)編碼符號，且如果是這樣，那么繼續(xù)進行在步驟780中恢復文件的部分i，且如果不是這樣，那么繼續(xù)進行在步驟710中接收更多包。可存在接收器UFD-UEP方法的許多變化。舉例來說，發(fā)送器可在包中的至少一些包中發(fā)送文件的每一部分的一個以上經(jīng)編碼符號，且因此接收器可在包中的至少一些包中接收文件的每一部分的一個以上經(jīng)編碼符號，在所述情況下，F(xiàn)EC有效負載ID可設定為對應于含于包中的每一部分的第一經(jīng)編碼符號的UFSI，且包中的每一部分的額外符號可具有連續(xù)的對應UFSI值。舉例來說，如果在包中攜帶有文件的每一部分的三個經(jīng)編碼符號，且每一部分的第一符號對應于UFSI = 4，234，那么每一部分的其它兩個經(jīng)編碼符號可分別對應于UFSI4, 235和UFSI4, 235，且包中所攜帶的UFSI可能為UFSI = 4，234。作為其它替代方案的實例，接收器可預先確定在試圖恢復之前要接收的經(jīng)編碼符號的數(shù)量，或可計算會話期間的包丟失統(tǒng)計數(shù)據(jù)，且基于此統(tǒng)計數(shù)據(jù)來決定試圖恢復文件的哪些部分。作為另一實例，接收器可進行用以確定是否已接收到足夠用來恢復文件的每一部分的經(jīng)編碼符號的特定于FEC碼的某種處理。作為另一實例，可在沒有在每一文件部分的恢復過程中產(chǎn)生(SBN，ESI)值的中間步驟的情況下直接使用UFSI值。作為另一實例，文件的部分的恢復可與經(jīng)編碼符號的接收同時發(fā)生。作為另一實例，可使用其它形式的FEC OTI信息。舉例來說，可獨立于其它部分，針對部分i在FEC OTI中指定基本UFSIBU1，基本UFSI BU1可按如下方式使用:含于包中的部分i的經(jīng)編碼符號的將由FEC發(fā)送器和接收器使用的UFSI是U+BR，其中U是在攜帶經(jīng)編碼符號的包中所攜帶的UFSI。因此，例如，如果包攜帶U = 1，045，且部分i的FEC OTI中的基本UFSI是BUi = 2，000，000，那么經(jīng)編碼符號UFSI是2，001，045。使用基本UFSI具有若干優(yōu)勢。舉例來說，在針對不同部分將只發(fā)射修復符號(出于稍后描述的原因)的情況下，設定BUi = KTi可為有利的，其中KTi是部分i中的文件符號的數(shù)目。在此情況下，所發(fā)送的包序列中的UFSI的序列可為0、1、2、3等，然而，對于每一部分，在包中將只發(fā)送從彼部分產(chǎn)生的修復符號。此段落描述基本UFSI的使用的另一實例優(yōu)勢。[FLUTE]、[ALC]、[LCT]、[FEC BB]中所描述的協(xié)議組將又稱作TOI的傳輸對象識別符與待輸送的文件或?qū)ο蟮腇EC OTI相關聯(lián)。有可能地是:相同部分的經(jīng)編碼符號可在不同時間或在不同會話中發(fā)送，且可與不同TOI相關聯(lián)。又，能夠?qū)τ谂c每一不同TOI相關聯(lián)的包，發(fā)送以UFSI = O開始的經(jīng)編碼包是有利的。通過具有獨立地針對每一部分指定基本UFSI作為FEC OTI的部分的能力，每一部分的不同基本UFSI可與文件的待發(fā)送的經(jīng)編碼符號所關于的每一 TOI相關聯(lián)，而不針對不同TOI發(fā)送重復的經(jīng)編碼符號。舉例來說，可在與TOI = I相關聯(lián)及與TOI = 2相關聯(lián)的包中發(fā)送相同部分的經(jīng)編碼符號，其中與TOI = I相關聯(lián)的部分的基本UFSI設定為0，且其中與TOI = 2相關聯(lián)的所述相同部分的基本UFSI設定為1，000, 000。接著，TOI = I及TOI = 2的經(jīng)編碼包可含有UFSIO、UFSIU UFS12等的序列，且在與兩個TOI相關聯(lián)的所發(fā)送經(jīng)編碼符號當中將不存在所發(fā)送部分的重復的經(jīng)編碼符號，只要針對具有TOI = I的部分發(fā)送的經(jīng)編碼符號少于1，000，000個即可。代替針對每一部分指定不同基本UFSI，也可有利地具有將由FEC OTI中的所有部分使用的基本UFSI，這是因為此可減少傳送FEC OTI所需要的八位字節(jié)的數(shù)目，而同時共享在FEC OTI中針對每一部分指定單獨基本UFSI的許多優(yōu)勢，尤其是在結(jié)合此方法使用的FEC碼是信息附加FEC碼(例如在Luby I中所描述的信息附加FEC碼等)時，這是因為在此情況下，所有部分的UFSI的有效范圍可極大。組合UFD-UEP方法與[RaptorQ-Spec]中所描述的技術(shù)以用于確定源塊和子塊結(jié)構(gòu)提供了許多優(yōu)勢。確切地說，基本UFD方法的所有優(yōu)勢對于UFD-UEP方法來說也成立。舉例來說，為了發(fā)射文件的UEP部分中的一者的目的而由SBN和ESI的組合識別的先前方法中被稱作源符號的符號可在使用UFD-UEP方法時被視為彼部分的由UFSI識別的文件符號。注意到KTi=上限(FiZti)是文件的部分i中的文件符號的總數(shù)目。當如(例如)[RaptorQ-Spec]中所描述，針對文件的每一部分確定源塊結(jié)構(gòu)和子塊結(jié)構(gòu)，且使用上文所描述的UFD-UEP方法來將文件的部分的符號的標識從(SBN，ESI)格式轉(zhuǎn)換成UFSI格式及
從UFSI格式轉(zhuǎn)換成(SBN，ESI)格式時，文件符號的UFSI的范圍是0、1、2.....KTi,且從文
件產(chǎn)生的任何修復符號將具有在范圍KTi+UKTi+2等中的UFSI。此特性允許通過簡單地比較符號的UFSI與KTi值，確定符號是文件的原始部分i的部分還是從文件的部分i產(chǎn)生的修復符號。此情形可為有用的，(例如)允許不支持FEC解碼的接收器基于包中攜帶的UFSI值，且基于文件的每一部分i的值Ti和KTi,確定包中的哪些部分含有原始文件的部分(及其在文件內(nèi)的位置)，且包中的哪些部分含有可忽略的修復符號。圖8圖解說明了一個實例，其中在此情況下文件包括兩個部分。第一部分分割成5個源塊，其中此等源塊中的前3個源塊各自具有6個源符號，且剩余2個源塊各自具有5個源符號，其中此等符號中的每一者具有(例如)48八位字節(jié)的大小，且因此第一部分的大小是28*48 = 1，344八位字節(jié)。第二部分分割成4個源塊，其中此等源塊中的前3個源塊各自具有4個源符號，且剩余I個源塊各自具有3個源符號，其中此等符號中的每一者具有(例如)256八位字節(jié)的大小，且因此第二部分的大小是256*48 = 3，840八位字節(jié)。圖9展示了圖8中圖解說明的文件結(jié)構(gòu)的可能分包。在此實例中，每一包包括UFSIC、大小為48八位字節(jié)的第一經(jīng)編碼符號(其為基于C從圖8中所示的文件結(jié)構(gòu)的第一部分產(chǎn)生，如先前參看圖6所描述)，以及256八位字節(jié)的第二經(jīng)編碼符號(其為基于C從圖8中所示的文件結(jié)構(gòu)的第二部分產(chǎn)生，如先前參看圖6所描述)。包的無陰影部分攜帶文件的對應部分的源符號，而有陰影部分攜帶從文件的對應部分產(chǎn)生的修復符號。在此實例中，恢復文件的第一部分所需要的包的最小數(shù)目是28，而恢復文件的第二部分所需要的包的最小數(shù)目是15。圖9描繪具有UFSI0.....27的28個包，且因此此等包中攜帶的文件的第一部分
的所有經(jīng)編碼符號是源符號。所產(chǎn)生的任何額外包(其中UFSI值至少為28)將攜帶文件的第一部分的修復符號。UFD-UEP方法的另一優(yōu)勢是，如果經(jīng)編碼符號被按由其UFSI定義的次序(S卩，按
UFSI次序0、1、2、3、4......)發(fā)送，那么文件的部分i的Zi個源塊的經(jīng)編碼符號被按交錯
次序(即，首先發(fā)送來自Zi個源塊中的每一者的具有ESIO的Zi個經(jīng)編碼符號，接著發(fā)送來自Zi個源塊中的每一者的具有ESIl的&個經(jīng)編碼符號，等等)發(fā)送。此特性對于文件的所有部分都成立，即使每一部分具有獨立的源塊結(jié)構(gòu)也是如此。對于大多數(shù)傳輸，此簡單發(fā)送次序是足夠且優(yōu)選的。然而，在包丟失經(jīng)歷可能與源塊的數(shù)目Zi同步的某一周期的情況下，潛在較佳發(fā)送次序是在發(fā)送經(jīng)編碼符號之前隨機置換Z個UFSI連續(xù)經(jīng)編碼符號的每
一集合，其中Z是Zi的最大值(對于所有i = 0.....d-1)，即，按隨機置換次序發(fā)送具有
UFSI0.....Z-1的前Z個經(jīng)編碼符號，且接著按隨機置換次序發(fā)送具有UFSI Z.....2*Z_1
的接下來Z個經(jīng)編碼符號，等等。另一潛在發(fā)送次序是在發(fā)送經(jīng)編碼符號之前隨機置換待發(fā)送的所有經(jīng)編碼符號。使用UFD-UEP方法提供相比于先前方法或先前方法的簡單擴展的許多額外優(yōu)勢。舉例來說，UFD-UEP方法使用包括UFSI字段的FEC有效負載ID字段，文件的每一部分的可能經(jīng)編碼符號的總數(shù)只由UFSI字段的大小限制，且獨立于文件的每一部分的源塊結(jié)構(gòu)。此外，UFSI字段的使用提供通用且簡潔的FEC有效負載ID，其允許同時識別從文件的每一部分的完全不同源塊結(jié)構(gòu)產(chǎn)生的符號。舉例來說，當使用產(chǎn)生32位FEC有效負載ID的32位UFSI時，對于文件可產(chǎn)生的經(jīng)編碼符號的總數(shù)是4，294，967，296，其獨立于文件所分割成的源塊的數(shù)量，且對于文件的每一部分，在使用子塊的情況下獨立于文件的子塊結(jié)構(gòu)。因此，如果文件的第一部分的符號的大小是256八位字節(jié)，且文件的第二部分的符號的大小是1，024八位字節(jié)，那么在此實例中，文件的第一部分的大小是1GB，且文件的第二部分的大小是4GB，接著經(jīng)編碼符號的數(shù)目可為每一文件部分的源符號的數(shù)目的1，024倍，其獨立于每一文件部分是分割成一個源塊、16，384個源塊，還是4，194，304個源塊。UFD-UEP文件傳遞方法所提供的相比于簡單UEP文件傳遞方法的改進的實例展示于圖11中。在此實例中，IMB的文件被分割成32KB的第一部分和992KB的第二部分。對于兩個方法，使用[RaptorQ-Spec]中指定的FEC碼，在每一包內(nèi)攜帶經(jīng)編碼符號的大小是
I,024八位字節(jié)，且發(fā)射總計2，048個包。對于圖11中所示的簡單UEP文件傳遞方法實例，獨立地處理及傳遞文件的第一部分和文件的第二部分，其中在兩個情況下，在每一包中攜帶大小為1，024八位字節(jié)的正好一個經(jīng)編碼符號。在32個包中攜帶文件的第一部分的源，且發(fā)送含有經(jīng)編碼符號的總計128個包。在992個包中攜帶文件的第二部分的源，且發(fā)送含有經(jīng)編碼符號的總計1，920個包。對于圖11中所示的UFD-UEP文件傳遞方法實例，以組合的方式處理及傳遞文件的第一部分和文件的第二部分，即，所發(fā)送的每一包含有兩個部分中的每一者的經(jīng)編碼符號，其中對于第一部分，經(jīng)編碼符號的大小是64八位字節(jié)，且對于第二部分，經(jīng)編碼符號的大小是960八位字節(jié)。在512個包中攜帶文件的第一部分的源，且所有2，048個包含有第一部分的經(jīng)編碼符號。在1059個包中攜帶文件的第二部分的源(源的最后包中的經(jīng)編碼符號即第二部分的經(jīng)編碼符號，其被用零來填滿為992八位字節(jié)的全符號大小)，且所有2，048個包含有第二部分的經(jīng)編碼符號。如圖11中可看出，簡單UEP文件傳遞方法和UFD-UEP文件傳遞方法的恢復性能對于文件的第二部分來說實際上是相同的(依據(jù)包丟失率)，即，在兩個情況下，直到接近48%的包丟失率，皆可相當一致地恢復文件的第二部分。另一方面，對于文件的第一部分來說，UFD-UEP文件傳遞方法的恢復性能顯著優(yōu)于簡單UEP文件傳遞方法的恢復性能:簡單UEP文件傳遞方法可一致地恢復包丟失率低于65%的文件的第一部分，而UFD-UEP文件傳遞方法可一致地恢復包丟失率接近75%的文件的第一部分。用于捆綁文件傳遞服務的通用文件傳遞方法和系統(tǒng)大多數(shù)先前文件傳遞方法不支持捆綁文件傳遞，即，將多個文件作為單一捆綁文件來傳遞。傳遞若干文件的直接方法是獨立地傳遞每一文件。然而，此直接方法具有某些缺點。舉例來說，如果文件小，那么所提供的保護遠遠不夠理想，這是因為如果每一文件的含有經(jīng)編碼符號的包的數(shù)目小，那么在包丟失統(tǒng)計數(shù)據(jù)中可存在大的方差。圖12圖解說明了此問題。在圖12中，32KB文件的文件傳遞可靠性被展示為在傳遞期間網(wǎng)絡中的包丟失百分比的函數(shù)。在此文件傳遞實例中，符號具有大小1，024，且使用[RaptorQ-Spec]中指定的FEC碼將文件的32個源符號編碼為64個經(jīng)編碼符號，且在單獨包中發(fā)送每一經(jīng)編碼符號。如圖12中可看出，歸因于此方差，可達成文件的可靠傳遞時的丟失百分比遠小于50%。
此外，如果獨立地編碼及發(fā)射許多小文件，那么能可靠地接收所有文件時的包丟失百分比甚至更小。圖12展示了傳遞各自具有32KB大小的32個文件時的此特性，其中每一文件的編碼和傳輸是使用與先前段落中所描述的參數(shù)相同的參數(shù)而與其它文件獨立地執(zhí)行。如可看出，僅可在包丟失低于約25% (其遠低于50%)時可靠地達成所有32個文件的傳遞?？扇缦聰U展UFD-UEP文件傳遞方法，以提供UFD捆綁文件傳遞方法。UFD捆綁文件傳遞方法可使用與UFD-UEP文件傳遞方法相同的方法，但并非用信號表示相同文件的d個部分的傳遞，而是用信號表示每一部分是單獨文件且d個文件被以捆綁方式來傳遞。假設
發(fā)送器希望分別提供大小為己、F1.....Fd^1的d個文件的捆綁傳遞。發(fā)送器UFD捆綁方法
將包大小T分割成大小為I；、T1.....Td^1的d個部分，且因此T等于i個Ti的總和。T的
此分割是基于匕、F1.....Fd^1和對應文件的優(yōu)先級。比率FiZti確定了在假定使用理想FEC碼來保護文件的作為一個源塊的部分i的情況下，為了恢復文件i所需要接收的包的數(shù)量，且因此比率FiZti越小，文件的部分i的優(yōu)先級越高。在實踐中，可能需要略高于FiZti個包以恢復文件的部分i，例如，因為FEC碼不是理想的，且展現(xiàn)出某一接收開銷，或因為文件的部分被分割成多個源塊，且一些源塊的經(jīng)編碼符號以高于其它源塊的速率丟失，或因為FiZti不是整數(shù)。如果想要傳遞的所有文件的優(yōu)先級是相同的，那么設定Ti以使得FiZti ^ F/T。對于發(fā)送器和接收器兩者來說，UFD捆綁文件傳遞方法的許多細節(jié)幾乎與UFD-UEP文件傳遞方法相同，且因此被省略?？蓴U 展UFD捆綁文件傳遞方法，以同時提供捆綁文件傳遞和UEP文件傳遞，即，可不同地設定捆綁中的每一文件的優(yōu)先級。此外，UFD捆綁文件傳遞方法可通過恰當?shù)男帕顏碇С忠韵聝煞N傳遞:多個文件的優(yōu)先化傳遞和文件的若干部分的優(yōu)先化傳遞。舉例來說，如果將使用UFD捆綁文件傳遞方法編碼及發(fā)送三個對象，那么前兩個對象可能為相同文件的具有不同優(yōu)先級的不同部分，且第三對象可為具有另一不同優(yōu)先級的不同文件。接收器可基于許多因素決定其希望恢復捆綁文件和/或文件部分中的哪一些，且獨立于其它文件或文件部分，只恢復彼等文件或文件部分。所屬領域的技術(shù)人員在閱讀本發(fā)明之后將認識至IJ，存在UFD捆綁文件傳遞方法的許多可能替代版本。作為UFD捆綁文件傳遞的簡單實例，假設將要傳遞32個文件的捆綁，每一文件具有大小32KB，其中每一文件具有相同優(yōu)先級。假設T= 1，024八位字節(jié)。在此情況下，對于每一 i = O、...、31，Ti的值=32八位字節(jié)。每一包將含有32個文件中的每一者的32八位字節(jié)的經(jīng)編碼符號，及識別包中的32個經(jīng)編碼符號的UFSI。在此實例中，將存在含有來自32個相等大小文件中的每一者的源符號的1，024個包，且這些包是UFSI在O到1，023的范圍中的包。假設在此實例中，針對每一文件產(chǎn)生1，024個額外修復符號，且在UFSI在1，024到2，047的范圍中的額外1，024個包中發(fā)送所述額外修復符號。圖12依據(jù)包丟失圖解說明了此UFD捆綁文件傳遞實例的恢復特性。在此實例中，針對接近50%的包丟失率，可使用UFD捆綁文件傳遞方法可靠地恢復所有32個文件，此包丟失率是相比于使用每一文件的單獨編碼和發(fā)送時允許可靠地傳遞所有32個文件的大約25%的包丟失率的實質(zhì)改進。用于單播修復請求的原生HTTP支持的方法文件或文件部分可被組織為且可用作具有相關聯(lián)的URL的“HTTP文件”，所述“HTTP文件”可由標準HTTP網(wǎng)絡高速緩存服務器使用以存儲文件或文件部分，且提供接收器對文件或文件部分的存取。按其原始次序的可用作HTTP文件的文件或文件部分在本文中被稱作“原始次序HTTP文件”。通常，用于單播修復請求的原生HTTP支持的方法可基于SBN和ESI將對HTTP文件的源塊的符號和子符號的修復請求翻譯為HTTP文件內(nèi)的標準HTTP八位字節(jié)范圍請求(常常被稱作具有指定字節(jié)范圍的HTTP部分GET請求)。此情形使標準HTTP網(wǎng)絡高速緩存服務器能夠?qū)Υ说刃迯驼埱筮M行服務，從而避免了大規(guī)模部署能理解如何將HTTP文件分割成源塊和源塊內(nèi)的源符號的專門HTTP網(wǎng)絡高速緩存服務器的需要。在此等情形下，當系統(tǒng)FEC碼在使用中時，常常有利地是只在會話中的一些(例如，廣播/組播會話)中發(fā)送修復符號，這是因為此情形允許接收器在單播修復請求中只請求源符號。此情形具有只需要將HTTP文件或如下文更詳細描述的HTTP文件的簡單重排變換提供到可為標準HTTP網(wǎng)絡高速緩存服務器的單播修復服務器的優(yōu)勢，從而使定義HTTP文件及分發(fā)HTTP文件的后勤工作更簡單，這是因為此等后勤工作獨立于FEC編碼。另一優(yōu)勢是，如果在會話中沒有發(fā)送源符號，那么因為所有源符號“缺失”，接收器可在單播修復請求中請求源符號的任何序列，此情形可為優(yōu)選的，這是因為此情形允許對源符號的連續(xù)序列的修復請求。舉例來說，假設使用具有理想恢復特性的FEC碼，且一個部分的源塊包括1，000個源符號，且針對源塊接收700個修復符號(即使修復符號中的一些可在傳輸中丟失，且因此所接收的修復符號的ESI的模式可能遠遠不是連續(xù)的)。接著，接收器可在單播修復請求中請求源塊的前300個連續(xù)源符號，且將此等源符號與700個修復符號組合以恢復源塊。如果源符號在HTTP文件中是連續(xù)的，那么可將單一 HTTP八位字節(jié)范圍請求用以請求及接收所有300個連續(xù)源符號。接收器不一定需要進行前綴請求(即，對文件的從第一字節(jié)開始的設定數(shù)目的字節(jié)的請求)，但在一些情況下，這會更簡單。請求是針對特定數(shù)目個字節(jié)或符號。在一些情況下，接收器將基于所接收的修復符號的數(shù)目及預期含于待接收的文件或?qū)ο笾械脑捶柕臄?shù)目來確定要請求的源符號的數(shù)目。在其它情況下，接收器可能執(zhí)行調(diào)度操作，其中接收器確定如何只使用其已經(jīng)接收的修復符號來進行解碼，且因此可注意到需要更特定數(shù)目個源符號。舉例來說，修復符號中的一些可能是其它修復符號的冗余，在所述情況下，可能需要更多的源符號。在其它狀況下，結(jié)果可能是需要較少源符號。接收器可基于FEC OTI，將對原始次序HTTP文件的對應于特定(SBN，ESI)對的源符號的請求翻譯為HTTP八位字節(jié)范圍請求。舉例來說，假設文件的FEC OTI是(F、Al、T、Z、N)，且將被請求的源符號的SBN是A，且所述源符號的ESI是B，且出于簡單起見，假設N=1，即，在文件結(jié)構(gòu)的此實例中源塊不會進一步被分割成子區(qū)塊。接著，接收器可應用(例如)[RaptorQ-Spec]第4.4章中所描述的方法，以確定(KL、KS、ZL、ZS)，其中前ZL個源塊具有KL個源符號，且剩余ZS個源塊具有KS個源符號。接著，基于A、B及符號大小T，接收器可確定源符號在文件內(nèi)的開始八位字節(jié)索引如等式I中所示，其中源符號在文件內(nèi)的結(jié)束八位字節(jié)索引是EI = SI+T。接著，接收器可使用對源符號的標準HTTP八位字節(jié)范圍請求。SI = T*(KL*min{A, ZL}+KS*max {A-ZL, 0}+B)(等式 I)如所屬領域的技術(shù)人員將認識到，存在對此等方法的許多擴展和改進。舉例來說，如果在未使用子塊的情況下從原始次序HTTP文件中請求多個連續(xù)源符號，那么可進行單一 HTTP八位字節(jié)范圍請求。作為另一實例，除了原始次序HTTP文件之外或代替原始次序HTTP文件，HTTP網(wǎng)絡高速緩存服務器可具有含有修復符號的文件，或可已經(jīng)擴展原始次序HTTP文件以含有修復符號，且接收器可使用類似于本文中所描述的方法的方法來進行對修復符號的HTTP八位字節(jié)范圍請求。作為增強的另一實例，可使用如所屬領域的技術(shù)人員將認識到的類似方法，擴展此等方法以處置使用子塊的情況。舉例來說，接收器可使用[RaptorQ-Spec]第4.4章中所描述的方法來確定(TL、TS、NL、NS),其中源塊的前NL個子塊具有大小TL*A1，且源塊的剩余NS個子塊具有大小TS*A1。接著，基于A、B和符號大小T，接收器可確定對應于源符號的具有N個子符號的符號在文件內(nèi)的開始和結(jié)束八位字節(jié)索引，且使用標準HTTP八位字節(jié)范圍請求來進行對此等八位字節(jié)的請求。作為另一實例，接收器可基于FEC 0ΤΙ，將對于文件或文件部分的對應于特定UFSI的源符號的請求翻譯為HTTP八位字節(jié)范圍請求。以下方法可極大地增強由接收器使用標準HTTP字節(jié)范圍請求來恢復HTTP文件的符號的效率，而同時使用標準HTTP網(wǎng)絡高速緩存服務器來將所請求的八位字節(jié)范圍請求傳遞到接收器。支持如所描述的HTTP八位字節(jié)范圍請求的直接方法是使用原始次序HTTP文件。此方法具有不需要變換原始文件或文件部分來產(chǎn)生用于HTTP網(wǎng)絡高速緩存服務器的原始次序HTTP文件的優(yōu)勢，但所述方法具有可能需要許多不同HTTP八位字節(jié)范圍請求來請求源符號(甚至是在針對每一源塊只請求連續(xù)源符號時)的劣勢。此情形有至少兩個原因:
(I)可能存在多個源塊，且缺失來自每一源塊的源符號，在所述情況下，可能需要針對每一源塊的單獨八位字節(jié)范圍請求；(2)可能存在每源塊多個子塊，且因此甚至從一個源塊請求單一源符號也可能需要對組成源符號的多個子符號的多個HTTP八位字節(jié)范圍請求，這是因為源符號的子符號可能在原始次序HTTP文件中不連續(xù)。一種支持上文所描述的HTTP八位字節(jié)范圍請求的有利方法首先基于原始文件或文件部分的FEC OTI，將文件或文件部分重新組織為新的格式，本文中稱作“UFSI次序HTTP文件”。此方法在存在多個源塊和/或每源塊多個子塊時是有用的。UFSI次序HTTP文件中的數(shù)據(jù)的次序是按具有UFSIO的文件符號、具有UFSIl的文件符號、具有UFSI2的文件符號等的次序，即，將UFSI次序HTTP文件中的數(shù)據(jù)的次序組織為根據(jù)遞增的連續(xù)UFSI (如由FEC OTI所確定)而排序的文件符號。URL可與UFSI次序HTTP文件相關聯(lián)，且可將URL提供給HTTP網(wǎng)絡高速緩存系統(tǒng)。接收器接著可使用HTTP八位字節(jié)范圍請求，來在需要時請求UFSI次序HTTP文件的部分。UFSI次序HTTP文件的一個優(yōu)勢是，如果接收器從源塊中的每一者接收大約相同數(shù)目個修復符號，那么獲得足夠用以恢復原始文件或文件部分的源符號所需要的HTTP八位字節(jié)范圍請求的數(shù)目可為最小，例如，如果針對每一源塊接收完全相同數(shù)目個修復符號，那么一個HTTP八位字節(jié)范圍請求可為足夠的。舉例來說，對UFSI次序HTTP文件的前L*T*Z個連續(xù)八位字節(jié)的請求就足以從原始文件或文件部分的Z個源塊中的每一者接收大小為T的前L個源符號。如果在一個或一個以上會話中接收到針對Z個源符號中的每一者的K-L個修復符號，且如果FEC碼具有理想恢復特性，那么從HTTP八位字節(jié)范圍請求接收的L*T*Z個八位字節(jié)就足以FEC解碼HTTP文件，其中在此實例中，假定K是Z個源塊中的每一者中的源符號的數(shù)目。
支持上文所描述的HTTP八位字節(jié)范圍請求的另一有利方法首先基于原始文件或文件部分的FEC 0ΤΙ，將文件或文件部分重新組織為不同的新格式，本文中稱作“SS次序HTTP文件”。此方法在存在每源塊多個子塊時有用，這是因為在此情況下，每一源符號可不是原始文件或文件部分的連續(xù)部分，即，源符號的子符號可散布于按原始文件排序的源塊中。SS次序HTTP文件中的數(shù)據(jù)的次序是按第一源塊的所有源符號，接著第二源塊的所有源符號，接著第三源塊的所有源符號等的次序，即，SS次序HTTP文件中的數(shù)據(jù)的次序被組織為根據(jù)源塊內(nèi)的遞增的連續(xù)ESI次序而排序的源符號，且是按遞增的連續(xù)SBN次序的源塊的串接，如由FEC OTI所確定。URL可與SS次序HTTP文件相關聯(lián)，且可將URL提供給HTTP網(wǎng)絡高速緩存系統(tǒng)。接收器接著可使用HTTP八位字節(jié)范圍請求，來在需要時請求SS次序HTTP文件的部分。如果接收器從源塊中的每一者接收不同數(shù)目個修復符號，那么SS次序HTTP文件是尤其有利的。舉例來說，如果存在各自具有1，000個源符號的兩個源塊，且如果接收器從一個或一個以上會話中接收到針對第一源塊的900個修復符號及針對第二源塊的100個修復符號，那么接收器可對SS次序HTTP文件的前T*100個八位字節(jié)進行一個請求，且接收針對第一源塊的100個源符號，且接收器可對SS次序HTTP文件的T*l，000+1到T*l，900個八位字節(jié)進行另一請求，且接收針對第二源塊的900個源符號，其中在此實例中，T是兩個源塊的符號大小(按八位字節(jié)計)。還可能使用剛剛描述的兩個方法的組合，即，可通過不同URL使UFSI次序HTTP文件和SS次序HTTP文件對于接收器可用，且接著接收器可使用對兩個不同格式化的HTTP文件的HTTP八位字節(jié)請求的組合。舉例來說，如果存在各自具有1，000個源符號的10個源塊，且如果在一個或一個以上會話中，針對前8個源塊中的每一者接收800個修復符號，針對第9個源塊接收820個修復符號，且針對第10個源塊接收500個修復符號，那么接收器可能進行對UFSI次序HTTP文件的HTTP八位字節(jié)范圍請求，以接收針對10個源塊中的每一者的200個源符號，且進行對SS次序HTTP文件的額外HTTP八位字節(jié)范圍請求，以接收針對第10個源塊的額外300個源符號。在此實例中，接收器可接收針對第9個源塊的不需要的20個源符號(假定具有理想恢復特性的FEC碼)，但在一些情況下，使用較小數(shù)目個HTTP八位字節(jié)范圍請求來請求多于一些源塊的最小所需八位字節(jié)數(shù)的八位字節(jié)可比請求每一源塊的正好所需源符號數(shù)目(此可需要大得多的數(shù)目個不同HTTP八位字節(jié)范圍請求)更有效率。所屬領域的技術(shù)人員將認識到，存在關于此等方法的許多變化。舉例來說，HTTP文件、UFSI次序HTTP文件和SS次序HTTP文件皆可用于請求。作為另一實例，SS次序HTTP文件可被分開，且可用作許多HTTP文件，針對每一源塊有一個此類HTTP文件。作為變體的其它實例，可能使用除了基于HTTP的方法和協(xié)議之外的方法和協(xié)議，例如可能使用基于RTP/UDP的方法，或基于UDP而建立的專有協(xié)議等。硬件系統(tǒng)和實例上文所描述的方法和系統(tǒng)可以硬件、軟件和/或含有程序代碼或其它指令的被恰當組織的計算機可讀媒體來實施。在本文中提供可能使用上文教示的系統(tǒng)的一些實例。圖13是使用多級譯碼的通信系統(tǒng)1300的方框圖，通信系統(tǒng)1300可作為如本文中所描述的文件傳遞系統(tǒng)的部分用以發(fā)送包。當然，可替代地使用其它代碼和/或硬件。在通信系統(tǒng)1300中，輸入文件1301或輸入流1305被提供給輸入符號產(chǎn)生器1310。輸入符號產(chǎn)生器1310從輸入文件或流產(chǎn)生一個或一個以上輸入符號(IS(O)、IS(1)、
IS(2).......)的序列，其中每一輸入符號具有值和位置(在圖13中表示為括弧中的整
數(shù))。如上文所解釋，輸入符號的可能值(即，其字母表)通常是具有2M個符號的字母表，使得每一輸入符號針對輸入文件的M個位進行譯碼。值M通常是由通信系統(tǒng)1300的用途來確定，但通用系統(tǒng)可能包含針對輸入符號產(chǎn)生器1310的符號大小輸入，使得M可在不同的用途間變化。輸入符號產(chǎn)生器1310的輸出被提供給編碼器1315。靜態(tài)鍵產(chǎn)生器1330產(chǎn)生靜態(tài)鍵Up...的流。所產(chǎn)生的靜態(tài)鍵的數(shù)目通常受限制，且取決于編碼器1315的特定實施例。隨后將更詳細描述靜態(tài)鍵的產(chǎn)生。動態(tài)鍵產(chǎn)生器1320產(chǎn)生將由編碼器1315產(chǎn)生的每一輸出符號的動態(tài)鍵。產(chǎn)生每一動態(tài)鍵,使得相同輸入文件的大部分動態(tài)鍵是唯一的。舉例來說，Luby I描述了可使用的鍵產(chǎn)生器的實施例。動態(tài)鍵產(chǎn)生器1320和靜態(tài)鍵產(chǎn)生器1330的輸出被提供給編碼器1315。根據(jù)由動態(tài)鍵產(chǎn)生器1320提供的每一鍵I，編碼器1315從由輸入符號產(chǎn)生器提供的輸入符號產(chǎn)生具有值B(I)的輸出符號。下文將更詳細描述編碼器1315的操作。每一輸出符號的值是基于其鍵，基于輸入符號中的一個或一個以上者及可能從輸入符號計算得到的一個或一個以上冗余符號的某一函數(shù)產(chǎn)生。引起特定輸出符號的輸入符號和冗余符號的集合在本文中被稱作輸出符號的“相關聯(lián)的符號”或僅稱作其“關聯(lián)物”。根據(jù)下文更詳細描述的過程來進行函數(shù)(“值函數(shù)”)及關聯(lián)物的選擇。通常，但不總是，M對于輸入符號和輸出符號是相同的，即，輸入符號和輸出符號都針對相同數(shù)目個位進行譯碼。在一些實施例中，輸入符號的數(shù)目K由編碼器1315使用以選擇關聯(lián)物。如果預先不知道K，例如當輸入是流式傳輸文件時，那么K可能只是估計。值K還可能由編碼器1315使用，來為由編碼器1315產(chǎn)生的輸入符號和任何中間符號分配存儲器。編碼器1315將輸出符號提供給發(fā)射模塊1340。發(fā)射模塊1340還被提供來自動態(tài)鍵產(chǎn)生器1320的每一此類輸出符號的鍵。發(fā)射模塊1340通過信道1345發(fā)射輸出符號到接收模塊1350，且取決于所使用的鍵控方法，發(fā)射模塊1340還可能發(fā)射關于所發(fā)射的輸出符號的鍵的某數(shù)據(jù)。假定信道1345是擦除信道，但此并非對于通信系統(tǒng)1300的恰當操作為必需的。模塊1340、1345和1350可為任何合適的硬件組件、軟件組件、物理媒體或其任何組合，只要發(fā)射模塊1340適合于將輸出符號及關于輸出符號的鍵的任何所需數(shù)據(jù)發(fā)射到信道1345，且接收模塊1350適合于從信道1345接收符號及潛在地關于符號的鍵的某數(shù)據(jù)便可。值K在用以確定關聯(lián)物的情況下可被通過信道1345發(fā)送，或可在編碼器1315和解碼器1355達成一致的情況下預先設定值K。其它元件展示于圖13中(及在本文中別處，不管是否描述為模塊、步驟、過程等，都也可使用硬件、軟件和/或存儲在電子可讀媒體上的程序代碼來實施)。如上文所解釋，信道1345可為實時信道，例如，因特網(wǎng)上的路徑，或從電視發(fā)射器到電視接收者的廣播鏈路，或從一點到另一點的電話連接，或者信道1345可為存儲信道，例如，CD-ROM、磁盤驅(qū)動器、網(wǎng)站或其類似者。信道1345可能甚至為實時信道和存儲信道的組合，例如，當某人通過電話線將輸入文件從個人計算機傳輸?shù)揭蛱鼐W(wǎng)服務供應商(ISP)，將輸入文件存儲在網(wǎng)絡服務器上，且隨后通過因特網(wǎng)傳輸?shù)浇邮照邥r形成的信道。因為假定信道1345是擦除信道，所以通信系統(tǒng)1300不會假定離開接收模塊1350的輸出符號與進入發(fā)射模塊1340的輸出符號之間的一一對應。事實上，在信道1345包括包交換網(wǎng)絡的情況下，通信系統(tǒng)1300可能甚至不能夠假定在通過信道1345的過程中保持任何兩個或兩個以上包的相對次序。因此，使用上文所描述的鍵控方案中的一個或一個以上者來確定輸出符號的鍵，且鍵不一定由輸出符號離開接收模塊1350的次序來確定。接收模塊1350將輸出符號提供給解碼器1355，且將接收模塊1350接收的關于此等輸出符號的鍵的任何數(shù)據(jù)提供給動態(tài)鍵再生器1360。動態(tài)鍵再生器1360重新產(chǎn)生所接收的輸出符號的動態(tài)鍵，且將此等動態(tài)鍵提供給解碼器1355。靜態(tài)鍵產(chǎn)生器1363重新產(chǎn)生靜態(tài)鍵Sp...，且將其提供給解碼器1355。靜態(tài)鍵產(chǎn)生器可存取在編碼和解碼過程期間都使用的隨機數(shù)產(chǎn)生器1335。此可呈存取相同物理裝置(如果在此類裝置上產(chǎn)生隨機數(shù))的形式，或呈存取用于產(chǎn)生隨機數(shù)以實現(xiàn)相同特性的相同算法的形式。解碼器1355將由動態(tài)鍵再生器1360及靜態(tài)鍵產(chǎn)生器1363提供的鍵與對應輸出符號一起用來恢復輸入符號(再一次IS(O)、IS(I)、IS (2)、...)。解碼器1355將經(jīng)恢復的輸入符號提供給輸入文件重新組裝器1365，輸入文件重新組裝器1365產(chǎn)生輸入文件1301或輸入流1305的副本1370?？赏ㄟ^多個接收器和/或多個發(fā)送器來進行文件傳遞。此等概念在圖14到圖15中圖解說明。圖14圖解說明了一個接收器2402通過三個信道2406從三個發(fā)射器2404(個別地表示為和“C”)接收數(shù)據(jù)的布置。此布置可用以使接收器的可用帶寬增至三倍，或應付可用時長不足以從任何一個發(fā)射器獲得整個文件的發(fā)射器。如圖所指示，每一發(fā)射器2404發(fā)送值S O的流。每一 S O值表示輸出符號B (I)和鍵I，上文解釋了輸出符號B (I)和鍵I的使用。舉例來說，值S(A，nA)是在發(fā)射器2402 (A)處產(chǎn)生的輸出符號序列中的第“nA”個輸出符號和第“nA”個鍵。來自一個發(fā)射器的鍵的序列優(yōu)選地與來自其它發(fā)射器的鍵的序列相異，使得發(fā)射器不會重復工作。此情形在圖14中通過序列SO隨發(fā)射器而變的事實而圖解說明。注意到，不必為了避免重復工作而對發(fā)射器2402進行同步或協(xié)調(diào)。事實上，在不進行協(xié)調(diào)的情況下，每一發(fā)射器可能在其序列中的不同位置中(即，nA古nB古nc)。在圖15中，將一個輸入文件2502的副本提供給多個發(fā)射器2504(所述發(fā)射器2504中的兩者展示于圖中)。發(fā)射器2504獨立地通過信道2506將根據(jù)輸入文件2502的內(nèi)容產(chǎn)生的輸出符號發(fā)射到接收器2508。所展示的兩個發(fā)射器中的每一發(fā)射器可能只需要發(fā)射(K+A)/2個輸出符號，之后接收器的解碼器就能夠恢復整個輸入文件。通過使用兩個接收器和兩個發(fā)射器，由接收器單元2510接收的信息的總量可為在一個信道2506上可用的信息的四倍。如果(例如)發(fā)射器將相同數(shù)據(jù)廣播到兩個接收器，那么信息量可能小于單一信道信息的四倍。在彼情況下，如果數(shù)據(jù)在任何信道中丟失，那么接收器單元2510處的信息量至少是兩倍且常常更多。應注意到，即使發(fā)射器只廣播一個信號，但接收器在不同時間起作用(in view)，所以有一個以上接收器偵聽每一發(fā)射器具有優(yōu)勢。在圖15中，接收器單元2510執(zhí)行類似于圖1中所示的接收器150、解碼器155、鍵再生器160和輸入文件重新組裝器165的功能的功能。在一些實施例中，在具有兩個編碼器的一個計算裝置中編碼輸入文件2502，使得計算裝置可提供用于一個發(fā)射器的一個輸出和用于另一發(fā)射器的另一輸出。在回顧了本發(fā)明之后，此等實例的其它變化應為顯而易見的。應理解，本文中所描述的譯碼設備和方法還可在其它通信情形下使用，且不限于例如因特網(wǎng)等的通信網(wǎng)絡。舉例來說，光盤技術(shù)也使用擦除和糾錯碼來處置被刮花光盤的問題，且將受益于使用鏈式反應碼來存儲信息于光盤上。作為另一實例，衛(wèi)星系統(tǒng)可使用擦除碼以便在用于傳輸?shù)墓β室蠓矫孢M行折衷，通過減小功率而有目的地允許更多錯誤，且鏈式反應譯碼在彼應用中將是有用的。又，已使用擦除碼來開發(fā)RAID(冗余獨立磁盤陣列)系統(tǒng)以用于可靠地存儲信息。本發(fā)明因此可證實在使用碼來處置潛在有損耗或錯誤數(shù)據(jù)的問題的其它應用(例如上文實例等)中是有用的。在一些優(yōu)選實施例中，將執(zhí)行上文所描述的通信過程的指令集(或軟件)提供給通過可能有損耗通信媒體來通信的兩個或兩個以上多用途計算機器。機器的數(shù)目可在一個發(fā)送器和一個接收者到任何數(shù)目個進行發(fā)送和/或接收的機器之間變化。連接機器的通信媒體可為有線的、光學的、無線的，或其類似者。上文所描述的通信系統(tǒng)具有應從本描述中顯而易見的許多用途。使用HTTP流式傳輸服務器的塊請求流式傳輸系統(tǒng)可能如上文所描述地傳遞文件。下文中，描述了此類系統(tǒng)的實例實施。在HTTP流式傳輸?shù)那闆r下，源可能為標準網(wǎng)絡服務器和內(nèi)容傳遞網(wǎng)絡(⑶N)，且可能使用標準HTTP。在客戶端，可使用HTTP針對由客戶端無縫地拼接在一起的個別區(qū)段進行請求。HTTP流式傳輸?shù)膬?yōu)勢包含使用標準化和現(xiàn)有基礎結(jié)構(gòu)。圖16展示了可能傳遞文件的塊請求流式傳輸系統(tǒng)的簡化圖。在圖16中，圖解說明了塊流式傳輸系統(tǒng)100，其包括塊服務基礎結(jié)構(gòu)(“BSI”) 101，塊服務基礎結(jié)構(gòu)(“BSI”)101又包括注入系統(tǒng)103，注入系統(tǒng)103用于注入內(nèi)容102，準備彼內(nèi)容，且通過將內(nèi)容存儲到可由注入系統(tǒng)103和HTTP流式傳輸服務器104存取的內(nèi)容存儲區(qū)110中而封裝內(nèi)容以用于由HTTP流式傳輸服務器104提供的服務。如圖所示，系統(tǒng)100還可能包含HTTP高速緩存106。在操作時，例如HTTP流式傳輸客戶端等的客戶端108將請求112發(fā)送到HTTP流式傳輸服務器104，且從HTTP流式傳輸服務器104或HTTP高速緩存106接收響應114。在每一情況下，圖16中所示的元件可能至少部分以軟件來實施，軟件中包括在處理器或其它電子器件上執(zhí)行的程序代碼。如圖17中所示，媒體塊可存儲在塊服務基礎結(jié)構(gòu)101(1)內(nèi)，塊服務基礎結(jié)構(gòu)101(1)可為(例如)HTTP服務器、內(nèi)容傳遞網(wǎng)絡裝置、HTTP代理、FTP代理或服務器，或某其它媒體服務器或系統(tǒng)。塊服務基礎結(jié)構(gòu)101⑴連接到網(wǎng)絡122，網(wǎng)絡122可為(例如)因特網(wǎng)協(xié)議(“IP”)網(wǎng)絡，例如因特網(wǎng)等。塊請求流式傳輸系統(tǒng)客戶端被展示為具有六個功能組件，即:塊選擇器123，其被提供了上文所描述的元數(shù)據(jù)，且執(zhí)行從由元數(shù)據(jù)指示的多個可用塊當中選擇要被請求的塊或部分塊的功能；塊請求器124，其從塊選擇器123接收請求指令，且執(zhí)行必要的操作以通過網(wǎng)絡122將對指定塊、塊的部分或多個塊的請求發(fā)送到塊服務基礎結(jié)構(gòu)101(1)，且接收返回的包括塊的數(shù)據(jù)；以及塊緩沖器125 ;緩沖器監(jiān)視器126 ;媒體解碼器127 ;和促進媒體消費的一個或一個以上媒體轉(zhuǎn)換器128。由塊請求器124接收的塊數(shù)據(jù)被傳到存儲媒體數(shù)據(jù)的塊緩沖器125以用于臨時存儲。或者，所接收的塊數(shù)據(jù)可直接存儲到如圖17中圖解說明的塊緩沖器125中。塊緩沖器125向媒體解碼器127提供媒體數(shù)據(jù)，且媒體解碼器127對此數(shù)據(jù)執(zhí)行必要變換，以將合適的輸入提供給媒體轉(zhuǎn)換器128，媒體轉(zhuǎn)換器128使媒體呈適用于用戶或其它消費的形式。媒體轉(zhuǎn)換器的實例包含視覺顯示裝置，例如在移動電話、計算機系統(tǒng)或電視中發(fā)現(xiàn)的視覺顯示裝置等，且還可能包含音頻呈現(xiàn)裝置，例如揚聲器或頭戴式耳機等。緩沖器監(jiān)視器126接收關于塊緩沖器125的內(nèi)容的信息，且基于此信息和可能其它信息，將輸入提供給塊選擇器123，如本文中所描述，塊選擇器123用以確定要請求的塊的選擇。塊請求流式傳輸系統(tǒng)(BRSS)包括向一個或一個以上內(nèi)容服務器(例如，HTTP服務器、FTP服務器等)進行請求的一個或一個以上客戶端。注入系統(tǒng)包括一個或一個以上注入處理器，其中注入處理器接收內(nèi)容(實時或非實時)，處理內(nèi)容以供BRSS使用，且將所述內(nèi)容(可能還連同由注入處理器產(chǎn)生的元數(shù)據(jù)一起)存儲到可由內(nèi)容服務器存取的存儲器中。BRSS也可能含有與內(nèi)容服務器相配合的內(nèi)容高速緩存。內(nèi)容服務器和內(nèi)容高速緩存可能為常規(guī)HTTP服務器和HTTP高速緩存，其接收呈包含URL且還可包含八位字節(jié)范圍(以便請求少于由URL指示的所有文件或區(qū)段的數(shù)據(jù))的HTTP請求的形式的對文件或區(qū)段的請求。客戶端可能包含進行對HTTP服務器的請求且處置對彼等請求的響應的常規(guī)HTTP客戶端，其中HTTP客戶端由新型客戶端系統(tǒng)驅(qū)動，所述新型客戶端系統(tǒng)表述請求，將其傳到HTTP客戶端，從HTTP客戶端得到響應，且處理此等響應(或存儲、變換等)，以便將其提供給呈現(xiàn)播放器(presentation player)以供客戶端裝置播放。通常，客戶端系統(tǒng)預先不知道將需要何種媒體(這是因為需要可能取決于用戶輸入、用戶輸入的改變等)，因此客戶端系統(tǒng)被稱為“流式傳輸”系統(tǒng)，這是因為媒體在一被接收之后即被“消費”，或在被接收之后不久就被“消費”。結(jié)果，響應延遲和帶寬約束可造成呈現(xiàn)的延遲，例如，在所述流趕到用戶正消費所述呈現(xiàn)的地方時造成呈現(xiàn)的暫停等。為了提供被感覺具有良好質(zhì)量的呈現(xiàn)，可在BRSS中(在客戶端處，在注入端處，或在客戶端和注入端兩者處)實施數(shù)種細節(jié)。在一些情況下，考慮到網(wǎng)絡處的客戶端服務器接口以及為了處理所述客戶端服務器接口而實現(xiàn)所實施的細節(jié)。在一些實施例中，客戶端系統(tǒng)和注入系統(tǒng)都感知到增強，而在其它實施例中，只有一方感知到增強。在此等情況下，即使一方未感知到增強，整個系統(tǒng)也可受益于增強，而在其它情況下，益處只在兩方都感知到增強的情況下產(chǎn)生，但當一方未感知到增強時，系統(tǒng)仍可操作而不會出故障。如圖18中圖解說明，根據(jù)各種實施例，注入系統(tǒng)可實施為硬件和軟件組件的組合。注入系統(tǒng)可包括一組指令，可執(zhí)行所述組指令以使系統(tǒng)執(zhí)行本文中所論述的方法中的任何一個或一個以上者。系統(tǒng)可實現(xiàn)為呈計算機形式的特定機器。系統(tǒng)可為服務器計算機、個人計算機(PC)或能夠執(zhí)行一組指令(順序或以其它方式)的任何系統(tǒng)，所述組指令指定將由彼系統(tǒng)采取的動作。此外，雖然只圖解說明了單個系統(tǒng)，但是術(shù)語“系統(tǒng)”還應被當作包含個別或聯(lián)合地執(zhí)行一組(或多組)指令以執(zhí)行本文中所論述的方法中的任何一個或一個以上者的系統(tǒng)的任何集合。注入系統(tǒng)可包含:注入處理器302 (例如，中央處理單元(CPU))、可在執(zhí)行期間存儲程序代碼的存儲器304，及磁盤存儲裝置306，其都通過總線300來相互通信。系統(tǒng)可進一步包含視頻顯示單元308 (例如，液晶顯示器(LCD)或陰極射線管(CRT))。系統(tǒng)還可包含字母數(shù)字輸入裝置310 (例如，鍵盤)和用于接收內(nèi)容源且傳遞內(nèi)容存儲的網(wǎng)絡接口裝置312。磁盤存儲單元306可包含機器可讀媒體，在機器可讀媒體上可存儲體現(xiàn)本文中所描述的方法或功能中的任何一個或一個以上者的一個或一個以上組指令(例如，軟件)。在系統(tǒng)執(zhí)行指令期間，指令還可完全或至少部分地駐留在存儲器304和/或注入處理器302內(nèi)，其中存儲器304和注入處理器302也構(gòu)成機器可讀媒體。如圖19中圖解說明，根據(jù)各種實施例，客戶端系統(tǒng)可實施為硬件和軟件組件的組合?？蛻舳讼到y(tǒng)可包括一組指令，可執(zhí)行所述組指令以使系統(tǒng)執(zhí)行本文中所論述的方法中的任何一個或一個以上者。系統(tǒng)可實現(xiàn)為呈計算機形式的特定機器。系統(tǒng)可為服務器計算機、個人計算機(PC)或能夠執(zhí)行一組指令(順序或以其它方式)的任何系統(tǒng)，所述組指令指定將由彼系統(tǒng)采取的動作。此外，雖然只圖解說明了單個系統(tǒng)，但是術(shù)語“系統(tǒng)”還應被當作包含個別或聯(lián)合地執(zhí)行一組(或多組)指令以執(zhí)行本文中所論述的方法中的任何一個或一個以上者的系統(tǒng)的任何集合。客戶端系統(tǒng)可包含:客戶端處理器402 (例如，中央處理單元(CPU))、可在執(zhí)行期間存儲程序代碼的存儲器404，及磁盤存儲裝置406，其都通過總線400來相互通信。系統(tǒng)可進一步包含視頻顯示單元408 (例如，液晶顯示器(LCD)或陰極射線管(CRT))。系統(tǒng)還可包含字母數(shù)字輸入裝置410(例如，鍵盤)及用于發(fā)送請求且接收響應的網(wǎng)絡接口裝置412。磁盤存儲單元406可包含機器可讀媒體，在機器可讀媒體上可存儲體現(xiàn)本文中所描述的方法或功能中的任何一個或一個以上者的一個或一個以上組指令(例如，軟件)。在系統(tǒng)執(zhí)行指令期間，指令還可完全或至少部分地駐留在存儲器404和/或客戶端處理器402內(nèi)，其中存儲器404和客戶端處理器402也構(gòu)成機器可讀媒體。特定實施例的實例在使用[Ra ptorQ-Spec]中指定的RaptorQ FEC方案的用于通用對象傳遞的完全指定的FEC方案的此章中描述了具體實施例。UOSI FEC有效負載ID可與[RaptorQ-Spec]中的RaptorQ FEC方案一起使用(本文中被稱作“UOD-RaptorQ FEC方案”)，以提供簡化且增強的對象傳遞能力。確切地說，為基本對象傳遞提供了更靈活且更簡單的支持，且也為不等錯誤保護(UEP)對象傳遞，為捆綁對象傳遞，以及為UEP和捆綁對象傳遞的組合提供了支持。應理解，可將合適的硬件和/或軟件用以在通信裝置之間實施“UOD-RaptorQ FEC方宏”
^\S: ο如圖2中圖解說明，F(xiàn)EC有效負載ID格式是4八位字節(jié)字段，其中在此具體實施中，通用文件符號識別符(UFSI) (32位的無符號整數(shù))由通用對象符號識別符(UOSI)(也是32位的無符號整數(shù))來概括。UOSI是非負整數(shù)，將UOSI與FEC OTI相結(jié)合用來識別包含于攜帶彼有效負載ID的包內(nèi)的編碼符號。為了傳遞單一對象或多個對象或分割成具有不同優(yōu)先級的部分的單一對象或此等對象的任何組合，F(xiàn)EC OTI是如下文描述。應注意到，對于所傳遞的每一對象，F(xiàn)EC OTI可與由RaptorQ FEC方案指定的FEC OTI相同。傳遞可能包括d個對象，d為某一正整數(shù)。每一對象可包括相同文件的不同部分、或不同文件，或其組合。對象i的大小Fi與將要用于對象i的編碼符號的大小Ti之間的關系可用以確定對象i在傳輸中的優(yōu)先級。圖20圖解說明了通用FEC OTI字段的實例。如本文中所使用，對于所傳遞的對象的數(shù)目d，存在8位無符號整數(shù)，且所示的實例是d = 2。默認值可能為d=l。對于d個對象中的每一者(即，對于i = 1.....d)，其它子字段為特定針對對象i的通用FEC OTI元
素，包含:用于符號大小Ti (其為小于216的正整數(shù))的16位無符號整數(shù)，其指示對象i的符號的大小(以八位字節(jié)為單位)；用于對象i的傳送長度Fi (其為至多24°的非負整數(shù))的40位無符號整數(shù)，其指示對象i的傳送長度(以八位字節(jié)為單位)。提供合適的填充。與通用FEC OTI字段相對比，可能存在方案特定的FEC OTI元素，例如圖21中所示的元素等。如彼實例中所示，方案特定的FEC OTI元素包含符號對準參數(shù)(Al) (8位,無符號整數(shù))，每一對象的方案特定FEC OTI元素(其包括對象i的源塊數(shù)目Zi (12位，無符號整數(shù))和對象i的子塊數(shù)目隊)。經(jīng)編碼的方案特定對象傳輸信息為(l+3*d)個八位字節(jié)的字段。圖21中的實例是d = 2。經(jīng)編碼的FEC OTI接著可為(2+10*d)個八位字節(jié)的字段，其包括經(jīng)編碼通用FEC OTI元素與經(jīng)編碼方案特定FEC OTI元素的串接。使用經(jīng)編碼FEC OTI的內(nèi)容傳遞可涉及使用UOD-RaptorQ FEC方案和利用UOD-RaptorQ FEC方案進行對象傳遞的內(nèi)容傳遞協(xié)議(“⑶P”)在系統(tǒng)的裝置、計算機、程序之間進行信息交換。⑶P應將d、Al提供給編碼器和解碼器，且對于每一對象，將FpTi (Al的倍數(shù))、ZJP Ni提供給編碼器和解碼器。將對象i自身提供給編碼器。使用UOD-RaptorQ編碼器方案的編碼器將針對待發(fā)送的每一包向⑶P供應包的UOSI和d個對象的編碼符號。⑶P將此信息傳達到接收器。現(xiàn)將描述參數(shù)選擇的實例。在一實例中，可能使用[RaptorQ-Spec]第4.3章中所描述的實例參數(shù)推導,其被獨立地應用于d個對象中的每一者。在實例中，Al = 4八位字節(jié)，SS = 8(其暗示每一子符號將至少是SS*A1 = 32八位字節(jié))，且對象i的Ti優(yōu)選地至少是SS*A1個八位字節(jié)，其中Ti是Al的倍數(shù)，而每一編碼包的有效負載大小優(yōu)選地具有至少T的大小，其中T是遍及Ti的總和，i = 1、...、d。對于源塊構(gòu)造,可能獨立地將[RaptorQ-Spec]第4.4.1章中的過程應用于d個對
象中的每一者。對于編碼包構(gòu)造，每一編碼包將含有UOSI及d個對象的編碼符號。為了實現(xiàn)由[RaptorQ-Spec]的RaptorQ FEC方案使用的FEC有效負載ID的(SBN，ESI)格式與由UOD-RaptorQ FEC方案使用的UOSI格式之間的兼容性，可能為特定格式。舉例來說，對于每一對象，對象i的從UOSI值C到對應(SBNjESI)值(A，B)的映射可能為B =下限{C/1,)且A = C-B^Zi的情況。類似地，對于每一對象，從對象i的(SBN，ESI)值(A，B)到對應UOSI值C的映射將為C = A+B*Zit)對于每一對象i = 1.....d，從O到KT1-1的UOSI值識別按源塊交錯次序的對象
i的源符號，其中KTi =上限(FiZti)。KTi以后的UOSI值識別使用RaptorQ編碼器從對象i的源符號產(chǎn)生的修復符號。編碼包可含有源符號、修復符號或源符號和修復符號的組合。包可含有來自對象i的相同源塊的任何數(shù)目個符號。在對象i的源包中的最后源符號包含為了 FEC編碼目的而附加的填充八位字節(jié)的情況下，此等八位字節(jié)應包含于包中，以便每一包中只包含完整符號。
每一編碼包中攜帶的通用對象符號識別符C是彼包中攜帶的每一對象的第一編碼符號的U0SI。每一對象的包中的后續(xù)編碼符號具有按順序次序從C+1編號到C+G-1的UOSI，其中G是包中的每一對象的編碼符號的數(shù)目。在優(yōu)選實施中，在每一編碼包中存在用于d個對象中的每一者的一個經(jīng)編碼符號。在優(yōu)選實施中，根據(jù)以下過程產(chǎn)生且發(fā)送編碼包。對于每一 UOSI值C = 0、l、2、3、...，編碼器如下產(chǎn)生且發(fā)送編碼包:其中編碼包的FEC有效負載ID的值被設定為UOSI值C，且對于每一對象i (i = 1、...、d)，編碼器確定對應于UOSI值C的(SBN, ESI)值(Ai, Bi)，根據(jù)RaptorQ FEC方案[RaptorQ-Spec]的過程從對象i產(chǎn)生對應于(SBN，ESI)值(AyBi)的大小為Ti的編碼符號Ei,將編碼符號Ei附加到編碼包的有效負載，且發(fā)送編碼包。注意到，接收器不必知道編碼包的總數(shù)。此為一個特定實例。所屬領域的一般技術(shù)人員在閱讀本發(fā)明之后可預想到其它實施例。在其它實施例中，可有利地進行上文所揭示的發(fā)明的組合或子組合。為了說明的目的而展示組件的實例布置，且應理解，在本發(fā)明的替代實施例中考慮了組合、附加、重新布置及其類似者。因此，雖然已關于例示性實施例描述了本發(fā)明，但所屬領域的技術(shù)人員將認識到眾多修改是可能的。舉例來說，本文中所描述的過程可使用硬件組件、軟件組件和/或其任何組合來實施。因此，說明書和附圖應被視為說明性而非限制性的。然而，將明顯看出，可對本發(fā)明進行各種修改和改變，而不脫離如權(quán)利要求書中所闡明的本發(fā)明的更廣泛精神和范圍，且本發(fā)明希望涵蓋在以下權(quán)利要求書的范圍內(nèi)的所有修改和等效物。
權(quán)利要求
1.一種通過包交換網(wǎng)絡傳遞來自電子裝置或系統(tǒng)的一個或一個以上數(shù)據(jù)對象的方法，其中所述一個或一個以上數(shù)據(jù)對象的源數(shù)據(jù)由包中的經(jīng)編碼符號表示，使得可至少近似地從所述經(jīng)編碼符號恢復所述源數(shù)據(jù)，所述方法包括: a)識別待傳遞的所述一個或一個以上數(shù)據(jù)對象中的每一數(shù)據(jù)對象的對象傳輸信息“OTI”，OTI包含以八位字節(jié)為單位的所述數(shù)據(jù)對象的大小F、用以表示用于表示所述數(shù)據(jù)對象的每一符號的八位字節(jié)的數(shù)目T，以及所述數(shù)據(jù)對象為了傳遞而被分割成的源塊的數(shù)目Z; b)產(chǎn)生用于所述一個或一個以上數(shù)據(jù)對象的多個包中的每一包的通用對象符號識別符“U0SI ”，其中給定包的所述UOSI選自一組可能的UOSI值，其中所述組獨立于所述給定包中所表示的每一數(shù)據(jù)對象的所述OTI的值； c)從包括表示所述一個或一個以上數(shù)據(jù)對象的所述源數(shù)據(jù)的多個源符號產(chǎn)生多個經(jīng)編碼符號，所述源符號中的每一者具有在所述源數(shù)據(jù)中的位置，其中產(chǎn)生用于給定數(shù)據(jù)對象的給定包的經(jīng)編碼符號包括: 1)確定要使用的FEC編碼過程； 2)從所述給定包的所述UOSI和所述給定數(shù)據(jù)對象的所述0ΤΙ，確定源塊編號“SBN”和經(jīng)編碼符號識別符“ESI” ；以及 3)至少基于以下三者針對彼經(jīng)編碼符號產(chǎn)生大小為T的經(jīng)編碼符號值:(a)所述FEC編碼過程、(b)來自所述Z個源塊中的根據(jù)彼經(jīng)編碼符號的所述SBN確定的源塊的一個或一個以上源符號，及(c)彼經(jīng)編碼符號的所述ESI ； d)產(chǎn)生包含在步驟a)中處置的所述數(shù)據(jù)對象中的每一者的所述OTI的表示的OTI字段，其中所述OTI字段還包含由所述OTI字段表示的數(shù)據(jù)對象的數(shù)目d ； e)產(chǎn)生用于所述一個或一個以上數(shù)據(jù)對象的所述多個包，其中所述多個包中的每一包包括彼包的所述U0SI，及彼包中所表示的每一數(shù)據(jù)對象的使用彼數(shù)據(jù)對象的所述OTI和彼包的所述UOSI從彼數(shù)據(jù)對象產(chǎn)生的一個或一個以上經(jīng)編碼符號；以及 f)輸出呈可由所述包交換網(wǎng)絡使用的形式的所述OTI字段和所述多個包。
2.根據(jù)權(quán)利要求1所述的方法，其中每一數(shù)據(jù)對象的所述OTI還包含所述數(shù)據(jù)對象的每一源塊為了傳輸而被分割成的子塊的數(shù)目N。
3.根據(jù)權(quán)利要求1所述的方法，其進一步包括: 將SBN設定為等于UOSI模Z ;以及 將ESI設定為等于小于或等于UOSI除以Z的商的最大整數(shù)。
4.一種通過包交換網(wǎng)絡傳遞來自電子裝置或系統(tǒng)的一個或一個以上數(shù)據(jù)對象的方法，其中所述一個或一個以上數(shù)據(jù)對象的源數(shù)據(jù)由包中的經(jīng)編碼符號表示，使得可至少近似地從所述經(jīng)編碼符號恢復所述源數(shù)據(jù)，所述方法包括: a)識別待傳遞的所述一個或一個以上數(shù)據(jù)對象中的每一數(shù)據(jù)對象的對象傳輸信息“0ΤΙ ”，其中當所述一個或一個以上數(shù)據(jù)對象包括一個以上數(shù)據(jù)對象時，在一次傳遞中的兩個數(shù)據(jù)對象的OTI可不同； b)產(chǎn)生用于所述一個或一個以上數(shù)據(jù)對象的多個包中的每一包的通用對象符號識別符“U0SI ”，其中給定包的所述UOSI選自一組可能的UOSI值，其中所述組獨立于所述給定包中所表示的每一數(shù)據(jù)對象的所述OTI的值；c)從包括表示所述一個或一個以上數(shù)據(jù)對象的所述源數(shù)據(jù)的多個源符號產(chǎn)生多個經(jīng)編碼符號，所述源符號中的每一者具有在所述源數(shù)據(jù)中的位置，其中產(chǎn)生用于給定數(shù)據(jù)對象的給定包的經(jīng)編碼符號包括從以下三者確定彼經(jīng)編碼符號的值:(a)所述給定包的所述UOSI, (b)所述給定數(shù)據(jù)對象的所述0ΤΙ，及(c) 一個或一個以上源符號值； d)產(chǎn)生用于待傳遞的所述一個或一個以上數(shù)據(jù)對象的所述多個包，其中所述多個包中的每一包包括彼包的所述U0SI，及彼包中所表示的每一數(shù)據(jù)對象的使用彼數(shù)據(jù)對象的所述OTI和彼包的所述UOSI從彼數(shù)據(jù)對象產(chǎn)生的一個或一個以上經(jīng)編碼符號；以及 e)至少輸出呈可由所述包交換網(wǎng)絡使用的形式的所述多個包。
5.根據(jù)權(quán)利要求4所述的方法，其進一步包括標示符號，以使得接收器可確定符號是對應于數(shù)據(jù)對象的源符號，還是對應于可在用于恢復一個或一個以上源符號的FEC解碼過程中使用的FEC修復符號，其中所述接收器通過比較包括所述符號的所述包的所述UOSI與表示數(shù)據(jù)對象中的符號的數(shù)目的值，來執(zhí)行所述確定。
6.根據(jù)權(quán)利要求4所述的方法，其中所述UOSI是非負整數(shù)，且每一數(shù)據(jù)對象的所述OTI包含以八位字節(jié)為單位的所述數(shù)據(jù)對象的大小、用以表示用于表示所述數(shù)據(jù)對象的每一符號的八位字節(jié)的數(shù)目、所述數(shù)據(jù)對象為了傳遞而被分割成的源塊的數(shù)目、源塊被分割成的子塊的數(shù)目，及對應于優(yōu)選存儲器對準的對準因子。
7.根據(jù)權(quán)利要求4所述的方法，其中 所述給定數(shù)據(jù)對象的所述OTI包含基本UOSI值；以及 從(a)所述給定包的所述UOS1、(b)所述給定數(shù)據(jù)對象的所述OTI及(C) 一個或一個以上源符號值來確定彼經(jīng)編碼符號的值包括在確定彼經(jīng)編碼符號的值之前，用所述基本UOSI值來調(diào)整所述給定包的所述UOSI，從而允許實現(xiàn)所述UOSI的偏移值。
8.根據(jù)權(quán)利要求4所述的方法，其中確定彼經(jīng)編碼符號的值包括使用前向糾錯“FEC”，且其中對于不同數(shù)據(jù)對象，允許不同等級的FEC保護，且從每一不同數(shù)據(jù)對象的所述OTI確定FEC保護的等級。
9.根據(jù)權(quán)利要求4所述的方法，其中所述一個或一個以上數(shù)據(jù)對象包括單一數(shù)據(jù)對象，且使用單一組OTI來產(chǎn)生所述一個或一個以上數(shù)據(jù)對象的每一經(jīng)編碼符號。
10.根據(jù)權(quán)利要求4所述的方法，其中所述一個或一個以上數(shù)據(jù)對象包括多個數(shù)據(jù)對象，且OTI字段包括:多個OTI子字段，每數(shù)據(jù)對象有一個OTI子字段；及指示所述多個數(shù)據(jù)對象中的數(shù)據(jù)對象的數(shù)目的計數(shù)子字段，其中并非所有所述OTI子字段都是相同的，且其中OTI子字段是獨立于至少一個其他OTI子字段產(chǎn)生的。
11.根據(jù)權(quán)利要求10所述的方法，其中對于OTI子字段的數(shù)據(jù)對象，每一OTI子字段包含所述數(shù)據(jù)對象的大小、所述數(shù)據(jù)對象為了輸送而被分割成的源塊的數(shù)目、每源塊所使用的子塊的數(shù)目、所使用的符號大小，和對準因子，其中至少兩個數(shù)據(jù)對象的源塊的所述數(shù)目不同。
12.根據(jù)權(quán)利要求4所述的方法，其中所述一個或一個以上數(shù)據(jù)對象至少包括第一數(shù)據(jù)對象和第二數(shù)據(jù)對象，其中所述傳遞被組織為至少兩個單獨包序列，其中所述第一數(shù)據(jù)對象的編碼符號在第一包序列的包中出現(xiàn)，且在第二包序列的包中出現(xiàn)，且所述第二數(shù)據(jù)對象的編碼符號在所述第一包序列的包中出現(xiàn)，但不在所述第二包序列的包中出現(xiàn)。
13.根據(jù)權(quán)利要求4所述的方法，其中所述一個或一個以上數(shù)據(jù)對象中的每一者包括存儲在將數(shù)據(jù)作為文件來存儲的計算機可讀媒體中的相異文件。
14.根據(jù)權(quán)利要求4所述的方法，其中所述一個或一個以上數(shù)據(jù)對象中的至少一者包括存儲在將數(shù)據(jù)作為文件來存儲的計算機可讀媒體中的相異文件的部分。
15.一種使用電子裝置或系統(tǒng)接收和解碼通過包交換網(wǎng)絡接收的一個或一個以上數(shù)據(jù)對象的方法，其中當接收到足夠的經(jīng)編碼符號時，所接收的經(jīng)編碼符號被解碼成表示所述一個或一個以上數(shù)據(jù)對象的源符號，所述方法包括: a)識別所傳遞的所述一個或一個以上數(shù)據(jù)對象中的每一數(shù)據(jù)對象的對象傳輸信息“OTI”，其中當所述一個或一個以上數(shù)據(jù)對象包括一個以上數(shù)據(jù)對象時，在一次傳遞中的兩個數(shù)據(jù)對象的OTI可不同； b)針對要用于解碼的每一經(jīng)編碼符號，確定所述經(jīng)編碼符號編碼數(shù)據(jù)對象的源符號所針對的彼數(shù)據(jù)對象、經(jīng)編碼符號值，及包括所述經(jīng)編碼符號的包的通用對象符號識別符“U0SI”； c)針對要用于解碼的每一經(jīng)編碼符號，確定用于解碼的解碼參數(shù)，其中確定使用包括所述經(jīng)編碼符號的所述包的所述UOSI和所述對應數(shù)據(jù)對象的OTI來確定所述解碼參數(shù)； d)使用經(jīng)編碼符號和步驟C)中所確定的解碼參數(shù)，來將所述經(jīng)編碼符號解碼成表示數(shù)據(jù)對象的經(jīng)恢復的源符號；以及 e)輸出呈計算機可讀形式的所述經(jīng)恢復的源符號。
16.根據(jù)權(quán)利要求15所述的方法，其進一步包括通過所述所接收的經(jīng)編碼符號來接收所述0ΤΙ。
17.根據(jù)權(quán)利要求15所述的方法，其中所述解碼參數(shù)包括源塊編號和經(jīng)編碼符號識別符，所述方法進一步包括: 將所述源塊編號設定為等于所述UOSI模所使用的源塊的數(shù)目；以及 將所述經(jīng)編碼符號識別符設定為等于小于或等于UOSI除以所使用的源塊的所述數(shù)目的商的最大整數(shù)。
18.根據(jù)權(quán)利要求15所述的方法，其進一步包括針對多個所述經(jīng)編碼符號中的每一者，確定所述經(jīng)編碼符號是對應于源符號，還是對應于可在用于恢復一個或一個以上源符號的前向糾錯“FEC”解碼過程中使用的FEC修復符號，其中接收器通過比較包括所述經(jīng)編碼符號的所述包的所述UOSI與表示數(shù)據(jù)對象中的符號的數(shù)目的值，來執(zhí)行所述確定。
19.根據(jù)權(quán)利要求15所述的方法，其中所述UOSI是非負整數(shù)，且多個數(shù)據(jù)對象中的每一者的所述OTI包含以八位字節(jié)為單位的每一數(shù)據(jù)對象的大小、用以表示用于表示每一數(shù)據(jù)對象的每一符號的八位字節(jié)的數(shù)目、每一數(shù)據(jù)對象為了傳遞而被分割成的源塊的數(shù)目、源塊被分割成的子塊的數(shù)目，及對應于優(yōu)選存儲器對準的對準因子，其中OTI值對于至少兩個數(shù)據(jù)對象來說是不同的，且對于至少兩個數(shù)據(jù)對象，使用不同等級的前向糾錯“FEC”。
20.一種使用電子裝置或系統(tǒng)接收和解碼通過包交換網(wǎng)絡接收的一個或一個以上數(shù)據(jù)對象的方法，其中當接收到足夠的經(jīng)編碼符號時，所接收的經(jīng)編碼符號被解碼成表示所述一個或一個以上數(shù)據(jù)對象的源符號，所述方法包括: a)接收包括每一數(shù)據(jù)對象的經(jīng)編碼符號的一個或一個以上包； b)確定需要數(shù)個額外符號以恢復所要數(shù)據(jù)對象； c)從多個經(jīng)編碼符號文件排序中選擇經(jīng)編碼符號文件排序，使得與在選擇另一經(jīng)編碼符號文件排序的情況下將需要的字節(jié)范圍規(guī)格相比，需要較少的字節(jié)范圍規(guī)格來請求所述數(shù)個額外符號； d)確定為了接收恢復所述所要數(shù)據(jù)對象所需要的至少所述數(shù)個額外符號要進行的一個或一個以上字節(jié)請求，所述確定是基于所述所選擇的經(jīng)編碼符號文件排序；以及 e)將所述一個或一個以上字節(jié)請求發(fā)送到超文本輸送協(xié)議“HTTP”服務器，所述HTTP服務器經(jīng)配置以提供所述所選擇的經(jīng)編碼符號文件排序。
21.根據(jù)權(quán)利要求20所述的方法，其中選擇經(jīng)編碼符號文件排序包括基于所述所接收的一個或一個以上包的輸送的類型選擇所述經(jīng)編碼符號文件排序。
22.一種通過包交換網(wǎng)絡傳遞來自電子裝置或系統(tǒng)的一個或一個以上數(shù)據(jù)對象的方法，其中所述一個或一個以上數(shù)據(jù)對象的源數(shù)據(jù)由包中的經(jīng)編碼符號表示，使得可至少近似地從所述經(jīng)編碼符號恢復所述源數(shù)據(jù)，所述方法包括: a)配置超文本輸送協(xié)議“HTTP”服務器，所述HTTP服務器對文件請求和字節(jié)范圍請求作出響應，且提供文件和字節(jié)范圍； b)基于所使用的前向糾錯“FEC”確定請求模式； c)重新排序用以對所述字節(jié)范圍請求作出響應的原始次序HTTP文件；以及 d)將對所述重新排序的HTTP文件的存取提供給所述HTTP服務器， 其中所述重新排序使得基于所述所使用的FEC的預期請求將需要比在所述HTTP服務器存取所述原始次序HTTP文件而非所述重新排序的HTTP文件的情況下將需要的字節(jié)范圍規(guī)格少的字節(jié)范圍規(guī)格。
23.根據(jù)權(quán)利要求22所述的方法，其中 所述所使用的FEC將數(shù)據(jù)對象的源塊分割成多個子塊，所述源塊包括源符號；以及 所述重新排序的HTTP文件是按連續(xù)源塊次序，且在源塊內(nèi)，是按源符號次序。
24.根據(jù)權(quán)利要求22所述的方法，其中 所述所使用的FEC使用按交錯次序的多個源塊，且將數(shù)據(jù)對象的源塊分割成多個子塊，所述源塊包括源符號；以及 所述重新排序的HTTP文件是按源塊交錯次序，且在源塊內(nèi)，是按源符號次序。
全文摘要
提供通過包交換網(wǎng)絡傳遞來自電子裝置或系統(tǒng)的數(shù)據(jù)對象的方法和設備，其中源數(shù)據(jù)由包中的經(jīng)編碼符號表示，使得通過將所述源數(shù)據(jù)布置成多個源符號，產(chǎn)生多個編碼包，其中編碼包包括通用對象符號識別符“UOSI”和表示由所述UOSI識別的包結(jié)構(gòu)的源數(shù)據(jù)的多個編碼符號，且將所述多個編碼包發(fā)送到所述包交換網(wǎng)絡，可至少近似地從所述經(jīng)編碼符號恢復所述源數(shù)據(jù)。
文檔編號H04L1/16GK103168457SQ201180051061
公開日2013年6月19日 申請日期2011年10月21日 優(yōu)先權(quán)日2010年10月22日
發(fā)明者邁克爾·G·盧比 申請人:高通股份有限公司