CN103168457A - 用于提供不等错误保护和捆绑文件传递服务的通用文件传递方法 - Google Patents

Abstract

提供通过包交换网络传递来自电子装置或系统的数据对象的方法和设备，其中源数据由包中的经编码符号表示，使得通过将所述源数据布置成多个源符号，产生多个编码包，其中编码包包括通用对象符号识别符“UOSI”和表示由所述UOSI识别的包结构的源数据的多个编码符号，且将所述多个编码包发送到所述包交换网络，可至少近似地从所述经编码符号恢复所述源数据。

Description

用于提供不等错误保护和捆绑文件传递服务的通用文件传递方法

相关申请案的交叉参考

本非临时申请案依据35USC§119(e)主张于2010年10月22日申请的标题为“用于提供不等错误保护和捆绑文件传递服务的文件传递方法(File Delivery Methods forProviding Unequal Error Protection and Bundled File Delivery Services)”的第61/406,091号美国临时专利申请案的优先权权益，所述申请案的全部内容为了所有目的以引用的方式并入本文中。

本发明可涉及以下共同转让的专利或申请案，所述专利或申请案中的每一者为了所有目的以全文引用的方式并入本文中：

1)授予麦克·G·卢比(Michael G.Luby)的标题为“用于通信系统的信息附加码产生器及解码器(Information Additive Code Generator and Decoder for CommunicationSystems)”的第6,307,487号美国专利(下文中为“Luby I”)；

2)授予麦克·G·卢比(Michael G.Luby)的标题为“用于通信系统的信息附加群码产生器及解码器(Information Additive Group Code Generator and Decoder for CommunicationSystems)”的第6,320,520号美国专利(下文中为“Luby II”)；

3)授予M·阿明·肖克罗拉西(M.Amin Shokrollahi)的标题为“用于通过钝化作用来解码链式反应码的系统和过程(Systems and Processes for Decoding a Chain Reaction CodeThrough Inactivation)”的第6,856,263号美国专利(下文中为“Shokrollahi I”)；

4)授予M·阿明·肖克罗拉西(M.Amin Shokrollahi)的标题为“链式反应码的系统编码和解码(Systematic Encoding and Decoding of Chain Reaction Codes)”的第6,909,383号美国专利(下文中为“Shokrollahi II”)；

5)授予M·阿明·肖克罗拉西(M.Amin Shokrollahi)的标题为“用于通信系统的多级码产生器和解码器(Multi-Stage Code Generator and Decoder for Communication Systems)”的第7,068,729号美国专利(下文中为“Shokrollahi III”)；

6)授予麦克·G·卢比(Michael G.Luby)、M·阿明·肖克罗拉西(M.Amin Shokrollahi)和马克·华生(Mark Watson)的标题为“文件下载和流式传输系统(File Download and StreamingSystem)”的第7,418,65l号美国专利(下文中为“Luby III”)；

7)麦克·G·卢比(Michael G.Luby)和M·阿明·肖克罗拉西(M.Amin Shokrollahi)的标题为“可应用于编码和解码各类码的就地变换(In-Place Transformations with Applicationsto Encoding and Decoding Various Classes of Codes)”的第2006/0280254号美国专利公开案(下文中为“Luby IV”)；

8)M·阿明·肖克罗拉西(M.Amin Shokrollahi)的标题为“用于通信系统的基于多字段的码产生器和解码器(Multiple-Field Based Code Generator and Decoder forCommunications Systems)”的第2007/0195894号美国专利公开案(下文中为“ShokrollahiIV”)；

9)于2009年10月23日申请的M·阿明·肖克罗拉西(M.Amin Shokrollahi)等人的标题为“用于编码和解码过程的使用具有符号的永久钝化作用的FEC码的方法和设备(Method and Apparatus Employing FEC Codes with Permanent Inactivation of Symbols forEncoding and Decoding Processes)”的第12/604,773号美国专利申请案(下文中为“Shokrollahi V”)；

10)于2009年8月19日申请的麦克·G·卢比(Michael G.Luby)的标题为“用于编码和解码过程的使用具有符号的永久钝化作用的FEC码的方法和设备(Methods andApparatus Employing FEC Codes with Permanent Inactivation of Symbols for Encoding andDecoding Processes)”的第61/235,285号美国临时申请案(下文中为“Luby V”)；及

11)于2010年8月18日申请的麦克·G·卢比(Michael G.Luby)、M·阿明·肖克罗拉西(M.Amin Shokrollahi)的标题为“用于编码和解码过程的使用具有符号的永久钝化作用的FEC码的方法和设备(Methods and Apparatus Employing FEC Codes with PermanentInactivation of Symbols for Encoding and Decoding Processes)”的第12/859,161号美国专利申请案(下文中为“Shokrollahi VI”)。

参考

下文参考中的每一者为了所有目的以全文引用的方式并入本文中：

[阿尔巴内斯96]或[PET]安德烈斯·阿尔巴内斯(Andres Albanese)、约翰内斯·布鲁默(Johannes Blomer)、杰夫·埃德蒙兹(Jeff Edmonds)、麦克·卢比(Michael Luby)和马杜·苏丹(Madhu Sudan)的“优先级编码传输(Priority Encoding Transmission)”，IEEE信息理论会刊(IEEE Transactions on Information Theory)第42卷第6期(1996年11月)；

[阿尔巴内斯97]或[PET-专利]A·阿尔巴内斯(A.Albanese)、M·卢比(M.Luby)、J·布鲁默(J.Blomer)、J·埃德蒙兹(J.Edmonds)的题为“用于分包对应于优先级编码的数据的系统，其中重构数据对应于被分成几部分的优先级和所接收的被分成几部分的包(Systemfor Packetizing Data Encoded Corresponding to Priority Levels Where Reconstructed DataCorresponds to Fractionalized Priority Level and Received Fractionalized Packets)”的第5,617,541号美国专利(于1997年4月1日授予)；

[ALC]M·卢比(Luby，M.)、M·华生(Watson，M.)、L·维奇萨诺(Vicisano，L.)的“异步分层译码(ALC)协议实例化(Asynchronous Layered Coding(ALC)Protocol Instantiation)”，IETF RFC5775(2010年4月)；

[FEC BB]M·华生(Watson，M.)、M·卢比(Luby，M.)和L·维奇萨诺(L.Vicisano)的“前向纠错(FEC)构建块(Forward Error Correction(FEC)Building Block)”，IETF RFC5052(2007年8月)；

[FLUTE]T·帕伊拉(Paila，T.)、M·卢比(Luby，M.)、R·莱赫托宁(Lehtonen，R.)、V·罗卡(Roca，V.)、R·沃尔什(Walsh，R.)的“FLUTE-通过单向输送而进行的文件传递(FLUTE--File Delivery over Unidirectional Transport)”，IETF RFC3926(2004年10月)；

[LCT]M·卢比(Luby，M.)、M·华生(Watson，M.)、L·维奇萨诺(Vicisano，L.)的“分层译码输送(LCT)构建块(Layered Coding Transport(LCT)Building Block)”，IETF RFC5651(2009年10月)；

[卢比2010]或[RaptorQ-Spec]M·卢比(M.Luby)、A·肖克罗拉西(A.Shokrollahi)、M·华生(M.Watson)、T·史托克哈默(T.Stockhammer)、L·曼代(L.Minder)的“用于对象传递的RaptorQ前向纠错方案(RaptorQ Forward Error Correction Scheme for Object Delivery)”，draft-ietf-rmt-bb-fec-raptorq-04，可靠组播输送(2010年8月24日)；

[卢比2007]或[Raptor-RFC-5053]M·卢比(M.Luby)、A·肖克罗拉西(A.Shokrollahi)、M·华生(M.Watson)、T·史托克哈默(T.Stockhammer)的“用于对象传递的猛禽(Raptor)前向纠错方案(Raptor Forward Error Correction Scheme for Object Delivery)”，IETF RFC5053(2007年9月)；

[卢比2002]M·卢比(Luby，M.)、L·维奇萨诺(Vicisano，L.)、J·盖梅尔(Gemmell，J.)、L·里索(Rizzo，L.)、M·汉德利(Handley，M.)和J·克劳克罗夫特(J.Crowcroft)的“在可靠组播中使用前向纠错(FEC)(The Use of Forward Error Correction(FEC)in Reliable Multicast)”，IETF RFC3453(2002年12月)；

[松冈]或[LDPC-扩展]法政松冈(Hosei Matsuoka)、山田明(Akira Yamada)和大矢智之(Tomoyuki Ohya)的“应用于广播-通信整合内容传递的低密度奇偶校验码扩展(Low-Density Parity-Check Code Extensions Applied for Broadcast-CommunicationIntegrated Content Delivery)”，NTT DOCOMO公司的研究实验室(3-6，Hikari-No-Oka，Yokosuka，Kanagawa，239-8536，日本)；及

[罗卡]或[LDPC-RFC-5170]V·罗卡(V.Roca)、C·诺依曼(C.Neumann)、D·弗罗德特(D.Furodet)的“低密度奇偶校验(LDPC)的阶梯和三角前向纠错(FEC)方案(Low DensityParity Check(LDPC)Staircase and Triangle Forward Error Correction(FEC)Schemes)”，IETF RFC5170(2008年6月)。

技术领域

本发明涉及在通信系统中编码和解码数据，且更具体来说，涉及以有效方式编码及解码数据以考虑到所传达数据中的错误和间隙且处置不同文件传递方法的通信系统。

背景技术

用于通过通信信道在发送器与接收者之间传输文件的技术是很多文献的主题。优选地，接收者需要以某种程度的确定性接收由发送器通过信道发射的数据的精确副本。当信道不具有理想保真度(其涵盖大多数物理可实现系统)时，所担心的是如何处理在传输中丢失或混淆的数据。丢失数据(擦除)与损坏数据(错误)相比常常更容易处理，这是因为接收者无法总是分辨出损坏数据是错误接收的数据的情况。已开发许多纠错码来对擦除和/或错误进行纠正。通常，基于关于用以发射数据的信道的失真和所发射数据的性质的某信息来选择所使用的特定码。举例来说，当已知信道具有长期的失真时，突发错误码可能最适合于彼应用。当只是预期短的不频发的错误时，简单的奇偶检验码可能是最佳的。

如本文中所使用，“源数据”指代在一个或一个以上发送器处可用且使用接收器通过从具有或不具有错误和/或擦除的所发射序列恢复而获得的数据，等等。如本文中所使用，“经编码数据”指代被传送且可用以恢复或获得源数据的数据。在简单情况下，经编码数据是源数据的副本，但如果所接收的经编码数据与所发射的经编码数据不同(归因于错误和/或擦除)，那么在这个简单情况下，在缺少关于源数据的额外数据的情况下可能无法完全恢复源数据。传输可通过空间或时间来进行。在更复杂情况下，在变换中基于源数据产生经编码数据，且将其从一个或一个以上发送器发射到接收器。如果发现源数据是经编码数据的部分，那么将编码称为“系统的”。在系统编码的简单实例中，关于源数据的冗余信息被附到源数据的末尾，以形成经编码数据。

同样如本文中所使用，“输入数据”指代存在于FEC(前向纠错)编码器设备或FEC编码器模块、组件、步骤等(“FEC编码器”)的输入处的数据，且“输出数据”指代存在于FEC编码器的输出处的数据。相应地，将预期输出数据存在于FEC解码器的输入处，且将预期FEC解码器基于其所处理的输出数据而输出输入数据或其对应物。在一些情况下，输入数据是(或包含)源数据，且在一些情况下，输出数据是(或包含)经编码数据。举例来说，如果在FEC编码器的输入之前没有处理，那么输入数据将是源数据。然而，在一些情况下，源数据被处理成不同形式(例如，静态编码器、逆编码器或另一过程)，以产生代替源数据被呈现给FEC编码器的中间数据。

在一些情况下，发送器装置或发送器程序代码可包括一个以上FEC编码器，即，在一系列多个FEC编码器中将源数据变换为经编码数据。类似地，在接收器处，可存在一个以上FEC解码器，FEC解码器被应用以从所接收的经编码数据产生源数据。

数据可被认为分割成若干符号。编码器是从源符号或输入符号的序列产生经编码符号或输出符号的计算机系统、装置、电子电路或其类似者，且解码器是从所接收或经恢复的经编码符号或输出符号恢复源符号或输入符号的序列的对应物。编码器和解码器由信道在时间和/或空间上分开，且任何所接收的经编码符号可并不与对应所发射的经编码符号精确相同，且可能不按与发射经编码符号的序列精确相同的序列接收经编码符号。符号的“大小”可按位来测量，不管符号实际上是否被分成位流，其中当符号是选自具有2^M个符号的字母表时，符号具有M个位的大小。在本文中的许多实例中，按八位字节来测量符号，且码可能在具有256种可能的字段范围内(在每个八位字节内存在256种可能的8位模式)，但应理解，可使用不同的数据测量单位，且以各种方式来测量数据是熟知的。在一般文献中，术语“字节”有时与术语“八位字节”互换地使用，以指示8位值，但在一些上下文中，“字节”指示X位值，其中X不等于8，例如，X＝7，且因此，一般来说，本文中使用术语“八位字节”。除非另外指示，否则本文中的实例不限于每符号特定整数或非整数个位。

Luby I描述使用码(例如链式反应码等)以计算高效、存储高效且带宽高效的方式来处理纠错。由链式反应编码器产生的经编码符号的一个特性是接收器能够在一接收到足够经编码符号后就恢复原始文件。具体来说，为了以高概率来恢复原始的K个源符号，接收器需要大约K+A个经编码符号。

给定情形下的“绝对接收开销”由值A表示，而“相对接收开销”可计算为比率A/K。绝对接收开销是对除信息理论最小数据量之外需要接收的额外数据量的测量，且绝对接收开销可取决于解码器的可靠性，且可依据源符号的数目K而变化。类似地，相对接收开销A/K是对除信息理论最小数据量之外需要接收的额外数据量相对于正被恢复的源数据的大小的测量，且也可取决于解码器的可靠性，且可依据源符号的数目K而变化。

对于通过基于数据包的网络的通信，链式反应码是极有用的。然而，链式反应码有时可能是在计算上相当繁重的。如果在使用链式反应或另一无码率码来编码的动态编码器之前使用静态编码器来编码源符号，那么解码器可能能够更频繁地或更容易地解码。例如，在Shokrollahi I中展示了这些解码器。在其处所示的实例中，源符号是送到静态编码器的输入符号，静态编码器产生输出符号，所述输出符号是送到动态编码器的输入符号，动态编码器产生输出符号，所述输出符号是经编码符号，其中动态编码器是可按不与输入符号的数目成固定比率的数量产生数个输出符号的无码率编码器。静态编码器可能包含一个以上固定码率的编码器。举例来说，静态编码器可能包含汉明编码器、低密度奇偶校验(“LDPC”)编码器、高密度奇偶校验(“HDPC”)编码器和/或其类似者。

链式反应码具有如下特性：在解码器处从所接收的符号恢复一些符号时，彼等符号可能能够用以恢复额外符号，额外符号又可能用以恢复更多的符号。优选地，在解码器处解出的符号的链式反应可继续，使得在用完所接收符号池之前恢复所有所要符号。优选地，执行链式反应编码和解码过程的计算复杂度低。

解码器处的恢复过程可能涉及确定接收了哪些符号，创建会将原始输入符号映射到所接收的彼等经编码符号的矩阵，接着反转矩阵，且执行反转矩阵与所接收的经编码符号的向量的矩阵乘法。在典型的系统中，此情形的强力实施可消耗过度的计算量和具有过多存储要求。当然，对于所接收的经编码符号的特定集合，恢复所有的原始输入符号可能是不可能的，但即使有可能，计算出结果的计算成本仍可能是高的。

前向纠错(“FEC”)对象传输信息(“OTI”)或“FEC OTI”

基于接收器接收(或能够推断)的FEC OTI，接收器可确定文件传送的源块和子块结构。在[Raptor-RFC-5053]和[RaptorQ-Spec]中，FEC有效负载ID是(SBN，ESI)，其中在[Raptor-RFC-5053]中，源块编号(SBN)是16个位，且编码符号ID(ESI)是16个位，而在[RaptorQ-Spec]中，SBN是8个位，且ESI是24个位，如本文中图1所图解说明。此FEC有效负载ID格式的一个劣势在于必须预先确定FEC有效负载ID的分配给SBN及分配给ESI的位数目，且有时难以确定将适用于所有文件传递参数的恰当混合。

举例来说，当使用[Raptor-RFC-5053]时，只有2¹⁶＝65,536个ESI可用在一些情形下可能有限制性，这是因为在一些情况下，可能存在具有8,192个源符号的源块，且因此经编码符号的数目只大了8倍，从而限制了可使用的可能码率，在此情况下，所述码率限制于不低于1/8。在此实例中，可能的状况是，可用的2¹⁶＝65,536个源块可能多于可能会使用的数目(例如，8,192个各具有1,024个八位字节的源符号)，可支持的文件大小是524GB，其在许多应用中比所需要的大小大两个数量级。

作为另一实例，当使用[RaptorQ-Spec]时，只有2⁸＝256个SBN可用在一些情形下可能限制性的，这是因为对于4GB文件，如果每一源块限于8MB(其可为如下情况：如果最大子块大小是256KB，最小子符号大小是32个八位字节，且符号大小是1,024个八位字节)，那么将源块的数目限于256又会将文件大小限于2GB。在此实例中，可能的状况是，有2²⁴＝16,777,216个可能经编码符号可用会多于可能会使用的数目(例如，具有8,192个源符号)，可能经编码符号的数目大了2,048倍，此在一些应用中可能从来都不需要。

另一合乎需要的特性是提供用于在文件的不同部分之间优先化编码传输的能力，所述优先化编码传输有时还被称作不等错误保护(“UEP”)。举例来说，可能需要比剩余90％更有力地保护文件的前10％以免受包丢失。举例来说，[LDPC-扩展]描述可如何扩展[LDPC-RFC-5170]以提供对UEP的支持。在此情况下，实际FEC码自身被修改，以提供对文件的不同部分的不同等级的奇偶检验保护。然而，此方法存在缺点。举例来说，不希望必须修改FEC码自身以提供UEP，这是因为此举使实施及测试FEC码自身复杂化。此外，作为[LDPC-扩展]的图6中所示结果，此方法的所得性能(就针对文件的不同部分提供的对包丢失的复原力而言)远远不是最佳。

如[PET]和[PET-专利]中所描述，提供UEP文件传递能力的一种方式是为文件的不同部分根据其优先级和大小分配每一包的不同部分。然而，所担心的是如何并入有此等UEP方法，使得文件的每一不同部分可与文件的其它部分独立地分割成源块和子块，以(例如)支持对文件的每一部分的小的存储器解码，且同时又在每一包内提供允许接收器确定文件的每一部分的哪一符号含于每一包中的FEC有效负载ID。非常难以使用具有格式(SBN，ESI)的FEC有效负载ID来支持此并入，这是因为对于文件的每一部分，针对文件第一部分的包中符号的对应SBN和ESI可能不同于针对文件第二部分的包中符号的SBN和ESI。

HTTP修复方法

在(例如)用于广播/组播文件传递的3GPP MBMS标准TS26.346中进行修复请求的方式是使用在[Raptor-RFC-5053]中指定的FEC有效负载ID，即，通过指定源块编号(SBN)和编码符号识别符(ESI)。虽然此方法在对修复请求作出响应的服务器具有要求服务器确定用于广播/组播文件传递的文件传递结构(即，要求服务器解译文件中的哪些部分是由所请求的SBN和ESI参考的)的专门方法的情况下是合理的，但是此举要求知道源块和子块结构，以及符号大小T。另一方面，可存在数百万个散布在大的地理区域之上的广播/组播接收器，且要求部署专门的响应服务器从资本费用及从操作的角度来看是既昂贵又麻烦的。广泛部署的是支持因特网传递(例如，网页、视频流式传输等)的标准HTTP网络服务器和网络高速缓存。所需要的是支持使用标准HTTP网络服务器和网络高速缓存作为广播/组播响应服务器的方法。

发明内容

在文件传递方法和设备的实施例中，通用文件符号识别符(“UFSI”)或通用对象符号识别符(“UOSI”)与包相关联，与所述包一起提供，以识别所述包内的结构，需要所述结构以用于识别含于所述包内的编码符号。当如此使用时，所述UFSI/UOSI允许对FEC和文件/对象传递的增强处置，包括：不等错误保护，其中并非所传递数据的所有部分都具有相同等级的FEC保护；以及捆绑对象传递，其中可比单独地处置多个对象的情况更有效地处置多个对象。

以下详细描述将与随附图式一起提供对本发明的性质和优势的更佳理解。

附图说明

图1是图解说明了常规FEC有效负载ID的图；图1A图解说明了用于Raptor-RFC5053的FEC有效负载ID，而图1B图解说明了用于RaptorQ-Spec的FEC有效负载ID。

图2是图解说明了用于基本通用文件传递(“UFD”)方法的FEC有效负载ID的图。

图3是图解说明了发送器基本UFD方法的流程图。

图4是图解说明了接收器基本UFD方法的流程图。

图5是图解说明了文件的符号的(SBN，ESI)标识和与文件的符号的对应通用文件符号识别符(“UFSI”)的映射的实例。

图6是图解说明了发送器通用文件传递、不等错误保护(“UFD-UEP”)方法的流程图。

图7是图解说明了接收器UFD-UEP方法的流程图。

图8图解说明了包括各自具有不同优先级的两个部分的文件的(SBN，ESI)标识的实例。

图9图解说明了来自文件的两个部分的经编码符号的(SBN，ESI)识别符与含有所述部分的经编码符号以及包含于每一包中的UFSI的包之间的映射的对应于图8的实例。

图10图解说明了使用[RaptorQ-Spec]的简单UEP文件传递方法的性能。

图11图解说明了都使用[RaptorQ-Spec]的简单UEP文件传递方法与UFD-UEP文件传递方法之间的实例性能比较。

图12图解说明了都使用[RaptorQ-Spec]的一个文件的文件传递、多个文件的文件传递与UFD捆绑文件传递方法之间的实例性能比较。

图13是通信系统的方框图，所述通信系统可用于产生、发送及接收Raptor、RaptorQ或其它包作为文件传递的部分。

图14是可在其中进行文件传递的通信系统的图示，其中一个接收器从多个通常独立的发送器接收输出符号。

图15是可在其中进行文件传递的通信系统的图示，其中多个可能独立的接收器从多个通常独立的发送器接收输出符号，接收输入文件的时间少于在只使用一个接收器和/或只使用一个发送器的情况下的时间。

图16描绘可用以使用HTTP流式传输服务器提供文件传递的块请求流式传输系统的元件。

图17图解说明了图16的块请求流式传输系统，其更详细图解说明了可用于文件传递的客户端系统的元件，客户端系统耦合到块服务基础结构(“BSI”)以接收由内容注入系统处理的数据。

图18图解说明了可用以准备文件以供文件传递的注入系统的硬件/软件实施。

图19图解说明了可用以接收传递到客户端系统的文件的客户端系统的硬件/软件实施。

图20图解说明了通用FEC OTI元素格式的实例。

图21图解说明了方案特定的FEC OTI元素格式的实例。

具体实施方式

在本文中的实施例中，文件传递由发送文件的编码器/发射器系统和接收文件的接收器/解码器系统执行。协调传输的格式，使得解码器理解编码器所编码的数据。如下文各种实例中所示，文件传递是一般对象传递的实例，且除非另外指示，否则从此等实例应显而易见，可将对象当作文件，且可能将文件当作对象。

在包传递系统中，数据被组织为包，且作为包发射。每一包具有允许接收器确定包中有什么及所述包是如何布置的元素。通过使用本文中所描述的技术，为发射使用前向纠错(“FEC”)的包提供了灵活性。

通过使用此等技术，可提供不等FEC保护，以及文件的捆绑传递。熟知的是，当许多文件被作为单独文件传递时，传递对包丢失的复原力可比在所有文件一起被连成较大文件且在传递中保护所述较大文件的情况下的复原力小得多。然而，需要发出作为较小文件的组合的较大文件的结构的信号，且为了恢复大文件内的任何较小文件，接收器通常需要恢复整个大文件，即使接收器仅关注恢复较小文件的子集也是如此。

因此，优选文件传递系统或方法应允许用作文件的文件传递结构的源块数目与每源块的编码符号数目的任何灵活组合。还应存在如下情况：文件传递方法提供针对包丢失的有效保护，且支持文件的不同部分受到不同优先级的保护的文件传递，其中文件的每一部分可具有不同于文件的其它部分的源块结构和子块结构。再一次，在一些情况下文件被视为对象的特定实例，但在本文中应理解，本文中用以描述文件的输送和处置的实例也可用于可能不被称作文件的数据对象，例如来自数据库的大数据块、视频序列的部分，等等。

文件/对象传递系统或方法应提供：具有大文件/对象的保护效率的许多较小文件/对象的传递、较小文件/对象结构的简单发信号，及接收器只独立地恢复较小文件/对象的子集而不恢复所有较小文件/对象的能力。现将描述具有此等合乎需要的性质的系统的实例。

基本通用文件传递(“UFD”)方法和系统

现将描述基本通用文件传递(“UFD”)方法和对应的系统，其中UFD包含相比于现有文件传递方法的显著优势。用于基本UFD方法的前向纠错(“FEC”)有效负载ID包括通用文件符号识别符(“UFSI”)字段，所述字段(例如)可为32位字段。现将依次描述基本UFD方法的发送器和接收器方法。再一次，当文件被称作对象时，“UFSI”可能被替代地称作“UOSI”(通用对象符号识别符)。

参看图3描述发送器基本UFD方法。发送器可使用现有方法来产生(例如)如[Raptor-RFC-5053]或[RaptorQ-Spec]中所描述的FEC对象传输信息(“OTI”)(参见(例如)[RaptorQ-Spec]第4.3章)，且使用FEC OTI来确定将用以发射文件的源块和子块结构，且确定(SBN，ESI)对与文件的经编码符号之间的关系(参见(例如)[RaptorQ-Spec]第4.4章)。

举例来说，如[RaptorQ-Spec]中所描述，所产生的FEC OTI可为(F，Al，T，Z，N)，其中F是待发射的文件的大小，Al是用以确保子符号在是Al的倍数的存储器边界上对准的对准因子，T是待产生且在传输中发送的符号的大小，Z是文件为了传输所分割成的源块的数目，且N是每一源块为了传输所分割成的子块的数目。此情形如图3的步骤300中所示。

发送器可形成将要在包中发送的经编码符号，且使用现有方法基于源块产生此等经编码符号的SBN和ESI，且如果使用子块，那么还使用子块结构，例如，如[RaptorQ-Spec]中所描述。每当将要发送经编码符号时，发送器可确定将要产生的经编码符号的SBNA和ESIB，如图3的步骤310中所示，且接着发送器可基于(SBN，ESI)＝(A，B)使用现有技术(例如，[RaptorQ-Spec]中所描述的技术)产生经编码符号的值，如图3的步骤320中所示。接着，将彼经编码符号的UFSIC计算为C＝B*Z+A，如图3的步骤330中所示。

发送器可在包中发送经编码符号，其中包的FEC有效负载ID被设定为经编码符号的UFSIC，如图3的步骤340中所示。发送器接着可确定是否要发送更多的经编码符号，如图3的步骤350中所示，且如果是这样，那么发送器可产生额外经编码符号以发送，如到图3的步骤310的“是”分支所示，且如果不是这样，那么发送器可结束，如到图3的步骤360的“否”分支所示。

可存在发送器基本UFD方法的许多变化。举例来说，发送器可在包中的至少一些包中发送一个以上经编码符号，在所述情况下，FEC有效负载ID可设定为含于包中的第一经编码符号的UFSI，且可选择含于包中的额外符号，使得其对应UFSI值为连续的。举例来说，如果在包中携带有三个经编码符号，且第一个此种符号具有UFSI＝4,234，那么其它两个经编码符号可分别为具有UFSI4,235和UFSI4,235的符号。作为其它替代方案的实例，发送器可预先确定产生多少经编码符号，且在产生任何经编码符号之前确定将要产生的所有经编码符号的(SBN，ESI)值。作为另一实例，可在无产生(SBN，ESI)值的中间步骤的情况下直接产生UFSI值。

作为变化的另一实例，可产生其它形式的FEC OTI信息。举例来说，基本UFSI BU可包含于文件的FEC OTI中，基本UFSI BU可按如下方式使用：含于包中的经编码符号的将由FEC发送器和接收器使用的UFSI是U+BU，其中U是在携带经编码符号的包中所携带的UFSI。因此，例如，如果包携带U＝1,045，且FEC OTI中的基本UFSI是BU＝2,000,000，那么经编码符号UFSI是2,001,045。使用基本UFSI具有若干优势。举例来说，[FLUTE]、[ALC]、[LCT]、[FEC BB]中所描述的协议组将又称作TOI的传输对象识别符与待输送的文件或对象的FEC OTI相关联。有可能的是，相同文件的经编码符号可在不同时间或在不同会话中发送，且可与不同TOI相关联。又，能够对于与每一不同TOI相关联的包，发送以UFSI＝O开始的经编码包是有利的。通过具有指定基本UFSI作为FEC OTI的部分的能力，不同基本UFSI可与文件的待发送的经编码符号所针对的每一TOI相关联，而不针对不同TOI发送重复的经编码符号。举例来说，相同文件的经编码符号可在与TOI＝1相关联及与TOI＝2相关联的包中发送，其中与TOI＝1相关联的基本UFSI设定为0，且其中与TOI＝2相关联的基本UFSI设定为1,000,000。接着，TOI＝1及TOI＝2两者的经编码包可含有UFSI0、UFSI1、UFSI2等的序列，且将不存在在与两个TOI相关联的所发送经编码符号当中发送的重复的经编码符号，只要针对具有TOI＝1的文件发送的经编码符号少于1,000,000个即可。

参看图4描述接收器基本UFD方法。接收器可使用现有技术来确定与上文对于发送器所描述的格式相同的格式的FEC OTI(F，Al，T，Z，N)，如图4的步骤400中所示。举例来说，FEC OTI可嵌入于FLUTE会话描述中，或FEC OTI可编码于URL中，或可通过SDP消息获得FEC OTI。在步骤410中，接收器查看是否接收到更多经编码符号，且接收器可停留在这个步骤，直到接收器接收到另一经编码符号(在所述情况下，接收器继续进行到步骤430)，或接收器确定将不会接收更多的经编码符号，在所述情况下，接收器继续进行到步骤420，且试图使用其它方法(例如，使用对文件修复服务器的HTTP请求)来恢复文件，或接收器可等待另一会话以在稍后接收更多经编码符号，或接收器可决定无法恢复文件。

当另一经编码符号可用时，在步骤430中，接收器确定经编码符号的UFSIC，且接收经编码符号的值。在步骤440中，接收器基于源块的数目Z和UFSIC，计算A＝C模Z，且B＝下限(C/Z)，且在步骤450中，接收器将经编码符号的(SBN，ESI)设定为(A，B)，且在步骤460中，接收器存储经编码符号的值和(A，B)以用于文件恢复。在步骤470中，接收器确定是否存在足以恢复文件的所接收的经编码符号，且如果是这样，那么继续进行在步骤480中恢复文件，且如果不是这样，那么继续进行在步骤410中接收更多经编码符号。

可存在接收器基本UFD方法的许多变化。举例来说，接收器可在包中的至少一些包中接收一个以上经编码符号，在所述情况下，FEC有效负载ID可设定为含于包中的第一经编码符号的UFSI，且包中的额外符号可具有连续的对应UFSI值。举例来说，如果在包中携带有三个经编码符号，且第一个此种符号具有UFSI＝4,234，那么其它两个经编码符号可分别为具有UFSI4,235和UFSI4,235的符号，且包中所携带的UFSI可能为第一经编码符号的UFSI＝4,234。作为其它替代方案的实例，接收器可预先确定在试图恢复之前接收多少经编码符号。作为另一实例，接收器可进行用以确定是否已接收到足够用来恢复文件的经编码符号的特定于FEC码的某种处理。作为另一实例，可在没有在恢复过程中产生(SBN，ESI)值的中间步骤的情况下直接使用UFSI值。作为另一实例，文件的恢复可与经编码符号的接收同时发生。作为另一实例，可使用其它形式的FEC OTI信息。

组合基本UFD方法与[RaptorQ-Spec]中所描述的技术以用于确定源块和子块结构提供了许多优势。举例来说，用于发射文件的目的的由SBN和ESI的组合识别的在先前方法中被称作源符号的符号可在使用基本UFD方法时被视为由UFSI识别的文件符号。使F为待发射的文件的大小(按八位字节计)，且使T为当发射文件时用于FEC编码/解码目的的符号大小，且因此KT＝上限(F/T)是文件中的符号的总数目，其中上限(x)是大于或等于x的最小整数。

当如(例如)[RaptorQ-Spec]中所描述地确定源块结构和子块结构，且使用上文所描述的基本UFD方法将符号的标识自(SBN，ESI)格式转换为UFSI格式及从UFSI格式转换为(SBN，ESI)格式时，文件符号的UFSI的范围是0，1，2，...，KT，且从文件产生的任何修复符号将具有在范围KT+1、KT+2等中的UFSI。此特性允许通过简单地比较符号的UFSI与值KT来确定符号是原始文件的部分还是从文件产生的修复符号。此情形可为有用的，(例如)允许不支持FEC解码的接收器基于包中携带的UFSI值，且基于文件的KT值，确定哪些符号是原始文件的部分(及其在文件内的位置)，且哪些符号可作为修复符号忽略。

图5图解说明了一个实例，其中在此情况下，文件大小是F＝28,669八位字节，符号大小为T＝1,024八位字节，且因此KT＝上限(F/T)＝28。在图5中，文件的符号的(SBN，ESI)标示展示于顶部，其中每一行对应于源块，且每一列对应于具有相同ESI值的符号。符号的对应UFSI标示展示于底部。在此情况下，具有UFSI＝27的符号(即，相对于UFSI标示的第28个符号)出于FEC编码及解码的目的而使其最后(KT*T)-F3个八位字节用零来填满，但不需要发射此符号的此等最后三个填充的八位字节。在此实例中，具有UFSI28或大于UFSI28的任何经编码符号是修复符号，其中具有UFSI28的经编码符号是从具有SBN＝3的源块产生，具有UFSI29的经编码符号是从具有SBN＝4的源块产生，具有UFSI30的经编码符号是从具有SBN＝0的源块产生，等等。如所属领域的技术人员将认识到，存在此特性的许多其它优势。

基本UFD方法的另一优势是，如果经编码符号是按由其UFSI定义的次序(即，按UFSI次序0、1、2、3、4......)发送，那么Z个源块的经编码符号是按交错次序发送(即，首先发送来自Z个源块中的每一者的具有ESI0的Z个经编码符号，接着发送来自Z个源块中的每一者的具有ESI1的Z个经编码符号，等等)。对于大多数传输，此简单发送次序是足够且优选的。然而，在包丢失经历可能与源块的数目Z同步的某一周期的情况下，潜在更佳的发送次序是在发送经编码符号之前随机置换Z个UFSI连续经编码符号的每一集合，即，按随机置换次序发送具有UFSI0、...、Z-1的前Z个经编码符号，且接着按随机置换次序发送具有UFSI Z、...、2*Z-1的接下来Z个经编码符号，等等。通过此描述，应理解，“随机”可包含伪随机，除非另外指示。

使用基本UFD方法提供相比于先前已知方法的许多额外优势。举例来说，当使用包括预先确定大小的SBN和ESI字段的FEC有效负载ID时，存在单独的预先确定数目个可能的源块或每源块的预先确定数目个可能的经编码符号。举例来说，产生32位FEC有效负载ID的8位SBN和24位ESI将可能的源块的数目限于256，且将每源块的可能的经编码符号的数目限于16,777,216。替代地，包括UFSI字段的FEC有效负载ID只限制文件的可能的经编码符号的总数，其独立于文件的源块结构。举例来说，当使用产生32位FEC有效负载ID的32位UFSI时，文件的可产生的经编码符号的总数是4,294,967,296，其独立于文件所分割成的源块的数量，且在使用子块的情况下独立于文件的子块结构。因此，如果符号的大小是1,024个八位字节，那么在此实例中，文件大小可高达4GB，且经编码符号的数目可为文件大小的1,024倍，其独立于文件是被分割成一个源块、16,384个源块还是4,194,304个源块。作为另一实例，文件大小可为2TB，且经编码符号的数目可为文件大小的两倍。在所有情况下，如果使用子块结构，那么文件的可产生的经编码符号的数目独立于文件的子块结构。

用于不等错误保护文件传递服务的通用文件传递方法

大多数先前文件传递方法不支持不等错误保护(“UEP”)文件传递。存在一些先前方法，例如，当前在ISDB-Tmm(陆地移动多媒体)标准中指定的方法，所述先前方法使用[LDPC-扩展]中所描述的方法，所述方法通过改变用以编码文件的不同部分的实际FEC码来支持UEP。除了在使用UEP时必须改变实际FEC码的劣势之外，另一劣势是由此等方法提供的保护远远不够理想。

作为实例，考虑结果展示于[LDPC-扩展]的图6中的实例。在彼实例中，存在将在包中发送的大小为1,000KB的文件的两个部分，每一包含有1KB符号：文件的第一部分具有大小30KB，且由100个奇偶检验或修复包保护，且文件的第二部分是970KB，且针对文件发送总共1,000个源包和1,000个奇偶检验包。由于两个问题，所提供的保护远远不够理想。一个问题是所使用的FEC码(基于[LDPC-RFC-5170])常常需要显著的接收开销以恢复源块，即，需要接收比文件中的源包多的包来恢复文件。第二问题是方法基本上使用与用来发送且保护文件的第二部分的包的集合独立的包的集合发送且保护文件的第一部分。对于第二问题，从针对文件的第一部分发送的130个包当中接收30个包的方差可为大的，这是因为文件的第一部分是通过此小数目个包来发送的。

可通过扩展对[LDPC-扩展]中所描述的UEP文件传递方法进行改进，所述扩展在本文中被称作“简单UEP”文件传递方法。简单UEP文件传递方法使用用于文件传递的现有技术，且基于文件的部分的优先级对于文件的每一部分使用不同的保护量而将文件的部分作为单独的文件传递来传递，且接着可发出文件的部分之间的逻辑连接的信号，使得接收器将知道所传递的文件是相同文件的部分。举例来说，简单UEP文件传递方法可使用上文实例中的[RaptorQ-Spec]来通过发送总计130个包来传递文件的前30KB部分，包中的每一者含有从第一部分产生的大小为1,024八位字节的经编码符号，且接着文件的第二970KB部分可通过发送总计1870个包而作为单独文件来传递，包中的每一者含有从第二部分产生的大小为1,024八位字节的经编码符号。因此，针对作为单独文件发送的文件的两个部分发送总计2,000个包。简单UEP文件传递方法是相对于[LDPC-扩展]中所描述的方法的改进，这是因为未修改FEC码自身，且是因为(如本文中图10中所示)在不同包丢失条件下文件的两个部分的传递性能优于[LDPC-扩展]的图6中所示的性能。

差别的一个可能来源是因为[RaptorQ-Spec]中指定的FEC码具有优于[LDPC-RFC-5170]中所指定的FEC码的恢复特性。然而，简单UEP文件传递方法仍遭受上文所描述的第二问题。

[PET]和[PET-专利]提供了用于提供UEP文件传递服务的潜在改进的方法，其中每一包含有来自文件的每一部分的基于所述部分的优先级的指定量的编码数据。[PET]的直接并入将为在每一包中包含文件的每一部分的具有适当大小的经编码符号，且接着包含文件的每一部分的包括(SBN，ESI)对的单独FEC有效负载ID。然而，此方法出于几个原因而不是有利的。

举例来说，当使用每一部分的包括预先确定大小的SBN和ESI字段的FEC有效负载ID时，对于文件的每一部分存在单独的预先确定数目个可能的源块或每源块的预先确定数目个可能的经编码符号。举例来说，d个部分中的每一者的8位SBN和24位ESI产生(32*d)位FEC有效负载ID，其将每部分的可能的源块的数目限于256，且将每源块的可能的经编码符号的数目限于16,777,216。此外，如果对于d个部分中的每一者，FEC有效负载ID大小是32位，那么此情形将意谓，只是针对每一包中的FEC有效负载ID标头，每一包中的所有部分的FEC有效负载ID总计为32*d位，例如，如果d＝10，那么32*d是320位，或等效地40八位字节。

可扩展用于文件传递的基本UFD方法，以提供如下文详细描述的不等错误保护(UEP)文件传递服务，其提供相比先前UEP文件传递方法的显著优势。在本文中，此等扩展方法被称作“UFD-UEP”文件传递方法。此等UFD-UEP文件传递方法可使用[PET]和[PET-专利]中所描述的方法中的一些方法。

现将更详细描述实例UFD-UEP文件传递方法。在此方法中，发送器将大小为F的文件分割成大小为F₀、F₁、...、F_d-1的d＞1个部分，且因此F等于i个F_i的总和。发送器将包大小T分割成大小为T₀、T₁、...、T_d-1的d个部分，且因此T等于i个T_i的总和。T的此分割是基于F₀、F₁、...、F_d-1和对应文件部分的优先级。比率F_i/T_i确定了在假定使用理想FEC码来保护作为一个源块的文件的部分i的情况下需要接收多少包以恢复文件的部分i，且因此比率F_i/T_i越小，文件的部分i的优先级越高。在实践中，可能需要略高于F_i/T_i个包以恢复文件的部分i，例如，这是因为FEC码不是理想的且会展现某一接收开销；或因为文件的部分被分割成多个源块，且一些源块的经编码符号以高于其它源块的速率丢失；或因为F_i/T_i不是整数。作为UEP的实例，假设F＝1MB，T＝1,024八位字节，d＝2，F₀＝32KB，F₁＝F-F₀＝992KB，且T₀＝64八位字节，T₁＝T-T₀＝960八位字节。在此实例中，F₀/T₀＝512，且因此理想地，接收512个包允许恢复文件的部分0，而F₁/T₁＝1,058.13，且因此理想地，接收1,059个包允许恢复文件的部分1。因此，在此实例中，可从粗略为恢复文件的部分1所需要的包的一半的包恢复文件的部分0。

注意到，在此实例中，如果未使用UEP，即d＝1，且因此F₀＝F＝1MB，且T₀＝T＝1,024八位字节，那么需要F₀/T₀＝1,024个包来恢复文件。因此，在先前段落中所描述的UEP实例中，文件的部分1的恢复需要比未使用UEP时的包略多的包，这是归因于文件的部分0的较高优先级。对此基本取舍的分析研究可在[PET]中找到。

对于发送器UFD-UEP方法，存在基于F₀、F₁、...、F_d-1和不同文件部分的优先级产生T的分割部分T₀、T₁、...、T_d-1的各种方式。注意到，如果选择T_i以使得F_i/T_i≈F/T，那么文件的部分i被认定具有平均优先级，且部分i的优先级将分别取决于F_i/T_i＜F/T或是F_i/T_i＞F/T而相对较高或较低。

现参看图6描述用于产生FEC OTI的发送器UFD-UEP方法。给定d、F₀、F₁、...，、F_d-1、T₀、T₁、...、T_d-1、Al、WS的值，可独立地使用现有方法(例如，使用[RaptorQ-Spec]第4.3章中所描述的方法)如常计算应用于文件的d个部分中的每一者的FEC OTI，即，对于每一i＝0、...、d-1，发送器可产生用于文件部分i的FEC OTI，所述FEC OTI确定如何使用(例如)[RaptorQ-Spec]第4.3章中所描述的方法将文件部分i分割成源块和子块，所述方法将F_i当作文件大小，且将T_i当作用以在每一包中携带部分i的信息的符号大小。发送器因此与文件的其它部分独立地产生用于文件的部分i的FEC OTI。此过程在本文中的图6的步骤600中展示。

发送器还可产生如下各者：将文件的部分i分割成源块和子块，及文件的部分i的经编码符号的(SBN，ESI)与如何使用现有方法(例如，[RaptorQ-Spec]第4.4章和其中的第5章中所描述的方法)从文件的部分i产生经编码符号之间的映射。此等UFD-UEP方法被与文件的其它部分独立地应用于文件的部分i，且因此，文件的不同部分可具有不同源块及子块结构，且确切地说，在文件的不同部分之间可存在每源块的不同数目个源符号及不同数目个源块，这是因为所述方法是独立于文件的每一部分来应用的。

对准因子Al优选地对于文件的所有部分是相同的，且确切地说，对于每一部分i，值T_i是Al的倍数是优选的。此外，如果(例如)使用[RaptorQ-Spec]第4.5章中所描述的方法来导出FEC OTI，那么当针对文件的部分中的每一者导出源块和子块结构时使用Al和WS的相同值是优选的。针对Al使用相同值确保了可在接收器处在存储器上与Al八位字节的倍数对准地发生解码，且针对WS使用相同值确保了在接收器处在随机存取存储器(RAM)中需要解码的最大块大小对于文件的所有部分是相同的。存在针对文件的不同部分使用不同WS值导出FEC OTI是优选的一些应用，例如，在需要使用较少存储器来恢复文件的较高优先级部分的情况下。

可存在针对不同部分使用不同对准因子是有利的若干应用。举例来说，高优先级部分可由具有4八位字节对准的存储器的低端接收器和具有8八位字节对准的存储器的高端接收器解码，而低优先级部分仅可由高端接收器解码。在此实例中，针对高优先级部分使用Al＝4，使得低端接收器可有效地解码此等部分可为有利的，而针对低优先级部分使用Al＝8可为有利的，这是因为与Al＝4相比，高端接收器可在Al＝8的情况下更有效地解码此等部分。

由特定于文件部分i的发送器UFD-UEP方法产生的对应FEC OTI包括F_i、T_i，、Z_i，、N_i，其中Z_i是文件的部分i所分割成的源块的数目，且N_i是文件的部分i的每一源块所分割成的子块的数目。因此，总的来说，发送器UFD-UEP方法针对文件产生的FEC OTI可包括：(d、Al、F₀、T₀、Z₀、N₀、F₁、T₁、Z₁、N₁、...、F_d-1、T_d-1、Z_d-1、N_d-1)。FEC OTI的其它版本也是可用的，例如，当d固定，且因此不需要明确地在FEC OTI中列出时，或当使用其它方法来指示源块结构及子块结构(如果使用的话)时。

发送器使用UFD-UEP方法在包中组装待发送的文件的每一部分的一个经编码符号，且包的FEC有效负载ID包括UFSI值C。当包将被发送时，发送器确定将用作包的FEC有效负载ID的UFSI值C，如图6的步骤610中所示。将使用的UFSI值(例如)可为连续的，例如，UFSI值0、1、2、3、...、等。对于给定UFSI值C，在文件的部分i的包中将放置在包的第i个部分中的大小为T_i的经编码符号具有SBNA_i和ESIB_i，其计算为A_i＝C模Z_i，且B_i＝下限(C/Z_i)，如图6的步骤620中所示。对于i＝0、...、d-1，针对包的d个部分中的每一者产生此等d个经编码符号，且接着在包中将UFSIC与集合大小为T的此等d个经编码符号一起发送，如图6的步骤630、640和650中所示。发送器UFD-UEP方法继续产生且发送经编码包，如图6的步骤660中进行的决定所示。

参看图7描述接收器UFD-UEP方法。接收器可使用现有技术来确定如上文所描述的与发送器的情况相同格式的FEC OTI(d、Al、F₀、T₀、Z₀、N₀、F₁、T₁、Z₁、N₁、...、F_d-1、T_d-1、Z_d-1、N_d-1)，如图7的步骤700中所示。举例来说，FEC OTI可嵌入于FLUTE会话描述中，或FEC OTI可编码于URL中，或可通过SDP消息获得FEC OTI。在步骤710中，接收器查看是否接收到更多包，且接收器可停留在这个步骤，直到接收器接收到另一包(在所述情况下，接收器继续进行到步骤730)，或接收器确定将不会接收更多的包，在所述情况下，接收器继续进行到步骤720，且确定已恢复文件的足够部分并停止，或者试图使用其它方法(例如，使用对文件修复服务器的HTTP请求)来恢复文件的额外部分，或接收器可等待另一会话以在稍后接收更多包。

当另一包可用时，在步骤730中，接收器确定所接收包的UFSIC，且对于每一i＝0、...、d-1，从包(对于每一i＝0、...、d-1)中提取大小为T_i的经编码符号。在步骤740中，对于每一i＝0、...、d-1，接收器基于源块的数目Z_i和UFSIC，计算A_i＝C模Z_i，且B_i＝下限(C/Z_i)，且在步骤750中，接收器将部分i的经编码符号的(SBN，ESI)设定为(A_i，B_i)，且在步骤760中，接收器存储部分i的经编码符号的值和(A_i，B_i)以用于恢复文件的部分i。在步骤770中，接收器对于每一i＝0、...、d-1确定是否存在足够用以恢复文件的部分i的所接收的经编码符号，且如果是这样，那么继续进行在步骤780中恢复文件的部分i，且如果不是这样，那么继续进行在步骤710中接收更多包。

可存在接收器UFD-UEP方法的许多变化。举例来说，发送器可在包中的至少一些包中发送文件的每一部分的一个以上经编码符号，且因此接收器可在包中的至少一些包中接收文件的每一部分的一个以上经编码符号，在所述情况下，FEC有效负载ID可设定为对应于含于包中的每一部分的第一经编码符号的UFSI，且包中的每一部分的额外符号可具有连续的对应UFSI值。举例来说，如果在包中携带有文件的每一部分的三个经编码符号，且每一部分的第一符号对应于UFSI＝4,234，那么每一部分的其它两个经编码符号可分别对应于UFSI4,235和UFSI4,235，且包中所携带的UFSI可能为UFSI＝4,234。

作为其它替代方案的实例，接收器可预先确定在试图恢复之前要接收的经编码符号的数量，或可计算会话期间的包丢失统计数据，且基于此统计数据来决定试图恢复文件的哪些部分。作为另一实例，接收器可进行用以确定是否已接收到足够用来恢复文件的每一部分的经编码符号的特定于FEC码的某种处理。作为另一实例，可在没有在每一文件部分的恢复过程中产生(SBN，ESI)值的中间步骤的情况下直接使用UFSI值。作为另一实例，文件的部分的恢复可与经编码符号的接收同时发生。

作为另一实例，可使用其它形式的FEC OTI信息。举例来说，可独立于其它部分，针对部分i在FEC OTI中指定基本UFSIBU_I，基本UFSI BU_I可按如下方式使用：含于包中的部分i的经编码符号的将由FEC发送器和接收器使用的UFSI是U+BU_I，其中U是在携带经编码符号的包中所携带的UFSI。因此，例如，如果包携带U＝1,045，且部分i的FEC OTI中的基本UFSI是BU_i＝2,000,000，那么经编码符号UFSI是2,001,045。

使用基本UFSI具有若干优势。举例来说，在针对不同部分将只发射修复符号(出于稍后描述的原因)的情况下，设定BU_i＝KT_i可为有利的，其中KT_i是部分i中的文件符号的数目。在此情况下，所发送的包序列中的UFSI的序列可为0、1、2、3等，然而，对于每一部分，在包中将只发送从彼部分产生的修复符号。

此段落描述基本UFSI的使用的另一实例优势。[FLUTE]、[ALC]、[LCT]、[FEC BB]中所描述的协议组将又称作TOI的传输对象识别符与待输送的文件或对象的FEC OTI相关联。有可能地是：相同部分的经编码符号可在不同时间或在不同会话中发送，且可与不同TOI相关联。又，能够对于与每一不同TOI相关联的包，发送以UFSI＝0开始的经编码包是有利的。通过具有独立地针对每一部分指定基本UFSI作为FEC OTI的部分的能力，每一部分的不同基本UFSI可与文件的待发送的经编码符号所关于的每一TOI相关联，而不针对不同TOI发送重复的经编码符号。举例来说，可在与TOI＝1相关联及与TOI＝2相关联的包中发送相同部分的经编码符号，其中与TOI＝1相关联的部分的基本UFSI设定为0，且其中与TOI＝2相关联的所述相同部分的基本UFSI设定为1,000,000。接着，TOI＝1及TOI＝2的经编码包可含有UFSI0、UFSI1、UFSI2等的序列，且在与两个TOI相关联的所发送经编码符号当中将不存在所发送部分的重复的经编码符号，只要针对具有TOI＝1的部分发送的经编码符号少于1,000,000个即可。代替针对每一部分指定不同基本UFSI，也可有利地具有将由FEC OTI中的所有部分使用的基本UFSI，这是因为此可减少传送FEC OTI所需要的八位字节的数目，而同时共享在FEC OTI中针对每一部分指定单独基本UFSI的许多优势，尤其是在结合此方法使用的FEC码是信息附加FEC码(例如在Luby I中所描述的信息附加FEC码等)时，这是因为在此情况下，所有部分的UFSI的有效范围可极大。

组合UFD-UEP方法与[RaptorQ-Spec]中所描述的技术以用于确定源块和子块结构提供了许多优势。确切地说，基本UFD方法的所有优势对于UFD-UEP方法来说也成立。举例来说，为了发射文件的UEP部分中的一者的目的而由SBN和ESI的组合识别的先前方法中被称作源符号的符号可在使用UFD-UEP方法时被视为彼部分的由UFSI识别的文件符号。注意到KT_i＝上限(F_i/T_i)是文件的部分i中的文件符号的总数目。当如(例如)[RaptorQ-Spec]中所描述，针对文件的每一部分确定源块结构和子块结构，且使用上文所描述的UFD-UEP方法来将文件的部分的符号的标识从(SBN，ESI)格式转换成UFSI格式及从UFSI格式转换成(SBN，ESI)格式时，文件符号的UFSI的范围是0、1、2、...、KT_i，且从文件产生的任何修复符号将具有在范围KT_i+1、KT_i+2等中的UFSI。此特性允许通过简单地比较符号的UFSI与KT_i值，确定符号是文件的原始部分i的部分还是从文件的部分i产生的修复符号。此情形可为有用的，(例如)允许不支持FEC解码的接收器基于包中携带的UFSI值，且基于文件的每一部分i的值T_i和KT_i，确定包中的哪些部分含有原始文件的部分(及其在文件内的位置)，且包中的哪些部分含有可忽略的修复符号。

图8图解说明了一个实例，其中在此情况下文件包括两个部分。第一部分分割成5个源块，其中此等源块中的前3个源块各自具有6个源符号，且剩余2个源块各自具有5个源符号，其中此等符号中的每一者具有(例如)48八位字节的大小，且因此第一部分的大小是28*48＝1,344八位字节。第二部分分割成4个源块，其中此等源块中的前3个源块各自具有4个源符号，且剩余1个源块各自具有3个源符号，其中此等符号中的每一者具有(例如)256八位字节的大小，且因此第二部分的大小是256*48＝3,840八位字节。

图9展示了图8中图解说明的文件结构的可能分包。在此实例中，每一包包括UFSIC、大小为48八位字节的第一经编码符号(其为基于C从图8中所示的文件结构的第一部分产生，如先前参看图6所描述)，以及256八位字节的第二经编码符号(其为基于C从图8中所示的文件结构的第二部分产生，如先前参看图6所描述)。包的无阴影部分携带文件的对应部分的源符号，而有阴影部分携带从文件的对应部分产生的修复符号。在此实例中，恢复文件的第一部分所需要的包的最小数目是28，而恢复文件的第二部分所需要的包的最小数目是15。

图9描绘具有UFSI0、...、27的28个包，且因此此等包中携带的文件的第一部分的所有经编码符号是源符号。所产生的任何额外包(其中UFSI值至少为28)将携带文件的第一部分的修复符号。

UFD-UEP方法的另一优势是，如果经编码符号被按由其UFSI定义的次序(即，按UFSI次序0、1、2、3、4......)发送，那么文件的部分i的Z_i个源块的经编码符号被按交错次序(即，首先发送来自Z_i个源块中的每一者的具有ESI0的Z_i个经编码符号，接着发送来自Z_i个源块中的每一者的具有ESI1的Z_i个经编码符号，等等)发送。此特性对于文件的所有部分都成立，即使每一部分具有独立的源块结构也是如此。对于大多数传输，此简单发送次序是足够且优选的。然而，在包丢失经历可能与源块的数目Z_i同步的某一周期的情况下，潜在较佳发送次序是在发送经编码符号之前随机置换Z个UFSI连续经编码符号的每一集合，其中Z是Z_i的最大值(对于所有i＝0、...、d-1)，即，按随机置换次序发送具有UFSI0、...、Z-1的前Z个经编码符号，且接着按随机置换次序发送具有UFSI Z、...、2*Z-1的接下来Z个经编码符号，等等。另一潜在发送次序是在发送经编码符号之前随机置换待发送的所有经编码符号。

使用UFD-UEP方法提供相比于先前方法或先前方法的简单扩展的许多额外优势。举例来说，UFD-UEP方法使用包括UFSI字段的FEC有效负载ID字段，文件的每一部分的可能经编码符号的总数只由UFSI字段的大小限制，且独立于文件的每一部分的源块结构。此外，UFSI字段的使用提供通用且简洁的FEC有效负载ID，其允许同时识别从文件的每一部分的完全不同源块结构产生的符号。举例来说，当使用产生32位FEC有效负载ID的32位UFSI时，对于文件可产生的经编码符号的总数是4,294,967,296，其独立于文件所分割成的源块的数量，且对于文件的每一部分，在使用子块的情况下独立于文件的子块结构。因此，如果文件的第一部分的符号的大小是256八位字节，且文件的第二部分的符号的大小是1,024八位字节，那么在此实例中，文件的第一部分的大小是1GB，且文件的第二部分的大小是4GB，接着经编码符号的数目可为每一文件部分的源符号的数目的1,024倍，其独立于每一文件部分是分割成一个源块、16,384个源块，还是4,194,304个源块。

UFD-UEP文件传递方法所提供的相比于简单UEP文件传递方法的改进的实例展示于图11中。在此实例中，1MB的文件被分割成32KB的第一部分和992KB的第二部分。对于两个方法，使用[RaptorQ-Spec]中指定的FEC码，在每一包内携带经编码符号的大小是1,024八位字节，且发射总计2,048个包。

对于图11中所示的简单UEP文件传递方法实例，独立地处理及传递文件的第一部分和文件的第二部分，其中在两个情况下，在每一包中携带大小为1,024八位字节的正好一个经编码符号。在32个包中携带文件的第一部分的源，且发送含有经编码符号的总计128个包。在992个包中携带文件的第二部分的源，且发送含有经编码符号的总计1,920个包。

对于图11中所示的UFD-UEP文件传递方法实例，以组合的方式处理及传递文件的第一部分和文件的第二部分，即，所发送的每一包含有两个部分中的每一者的经编码符号，其中对于第一部分，经编码符号的大小是64八位字节，且对于第二部分，经编码符号的大小是960八位字节。在512个包中携带文件的第一部分的源，且所有2,048个包含有第一部分的经编码符号。在1059个包中携带文件的第二部分的源(源的最后包中的经编码符号即第二部分的经编码符号，其被用零来填满为992八位字节的全符号大小)，且所有2,048个包含有第二部分的经编码符号。

如图11中可看出，简单UEP文件传递方法和UFD-UEP文件传递方法的恢复性能对于文件的第二部分来说实际上是相同的(依据包丢失率)，即，在两个情况下，直到接近48％的包丢失率，皆可相当一致地恢复文件的第二部分。另一方面，对于文件的第一部分来说，UFD-UEP文件传递方法的恢复性能显著优于简单UEP文件传递方法的恢复性能：简单UEP文件传递方法可一致地恢复包丢失率低于65％的文件的第一部分，而UFD-UEP文件传递方法可一致地恢复包丢失率接近75％的文件的第一部分。

用于捆绑文件传递服务的通用文件传递方法和系统

大多数先前文件传递方法不支持捆绑文件传递，即，将多个文件作为单一捆绑文件来传递。传递若干文件的直接方法是独立地传递每一文件。然而，此直接方法具有某些缺点。举例来说，如果文件小，那么所提供的保护远远不够理想，这是因为如果每一文件的含有经编码符号的包的数目小，那么在包丢失统计数据中可存在大的方差。

图12图解说明了此问题。在图12中，32KB文件的文件传递可靠性被展示为在传递期间网络中的包丢失百分比的函数。在此文件传递实例中，符号具有大小1,024，且使用[RaptorQ-Spec]中指定的FEC码将文件的32个源符号编码为64个经编码符号，且在单独包中发送每一经编码符号。如图12中可看出，归因于此方差，可达成文件的可靠传递时的丢失百分比远小于50％。

此外，如果独立地编码及发射许多小文件，那么能可靠地接收所有文件时的包丢失百分比甚至更小。图12展示了传递各自具有32KB大小的32个文件时的此特性，其中每一文件的编码和传输是使用与先前段落中所描述的参数相同的参数而与其它文件独立地执行。如可看出，仅可在包丢失低于约25％(其远低于50％)时可靠地达成所有32个文件的传递。

可如下扩展UFD-UEP文件传递方法，以提供UFD捆绑文件传递方法。UFD捆绑文件传递方法可使用与UFD-UEP文件传递方法相同的方法，但并非用信号表示相同文件的d个部分的传递，而是用信号表示每一部分是单独文件且d个文件被以捆绑方式来传递。假设发送器希望分别提供大小为F₀、F₁、...、F_d-1的d个文件的捆绑传递。发送器UFD捆绑方法将包大小T分割成大小为T₀、T₁、...、T_d-1的d个部分，且因此T等于i个T_i的总和。T的此分割是基于F₀、F₁、...、F_d-1和对应文件的优先级。

比率F_i/T_i确定了在假定使用理想FEC码来保护文件的作为一个源块的部分i的情况下，为了恢复文件i所需要接收的包的数量，且因此比率F_i/T_i越小，文件的部分i的优先级越高。在实践中，可能需要略高于F_i/T_i个包以恢复文件的部分i，例如，因为FEC码不是理想的，且展现出某一接收开销，或因为文件的部分被分割成多个源块，且一些源块的经编码符号以高于其它源块的速率丢失，或因为F_i/T_i不是整数。如果想要传递的所有文件的优先级是相同的，那么设定T_i以使得F_i/T_i≈F/T。对于发送器和接收器两者来说，UFD捆绑文件传递方法的许多细节几乎与UFD-UEP文件传递方法相同，且因此被省略。

可扩展UFD捆绑文件传递方法，以同时提供捆绑文件传递和UEP文件传递，即，可不同地设定捆绑中的每一文件的优先级。此外，UFD捆绑文件传递方法可通过恰当的信令来支持以下两种传递：多个文件的优先化传递和文件的若干部分的优先化传递。举例来说，如果将使用UFD捆绑文件传递方法编码及发送三个对象，那么前两个对象可能为相同文件的具有不同优先级的不同部分，且第三对象可为具有另一不同优先级的不同文件。接收器可基于许多因素决定其希望恢复捆绑文件和/或文件部分中的哪一些，且独立于其它文件或文件部分，只恢复彼等文件或文件部分。所属领域的技术人员在阅读本发明之后将认识到，存在UFD捆绑文件传递方法的许多可能替代版本。

作为UFD捆绑文件传递的简单实例，假设将要传递32个文件的捆绑，每一文件具有大小32KB，其中每一文件具有相同优先级。假设T＝1,024八位字节。在此情况下，对于每一i＝0、...、31，T_i的值＝32八位字节。每一包将含有32个文件中的每一者的32八位字节的经编码符号，及识别包中的32个经编码符号的UFSI。在此实例中，将存在含有来自32个相等大小文件中的每一者的源符号的1,024个包，且这些包是UFSI在0到1,023的范围中的包。假设在此实例中，针对每一文件产生1,024个额外修复符号，且在UFSI在1,024到2,047的范围中的额外1,024个包中发送所述额外修复符号。

图12依据包丢失图解说明了此UFD捆绑文件传递实例的恢复特性。在此实例中，针对接近50％的包丢失率，可使用UFD捆绑文件传递方法可靠地恢复所有32个文件，此包丢失率是相比于使用每一文件的单独编码和发送时允许可靠地传递所有32个文件的大约25％的包丢失率的实质改进。

用于单播修复请求的原生HTTP支持的方法

文件或文件部分可被组织为且可用作具有相关联的URL的“HTTP文件”，所述“HTTP文件”可由标准HTTP网络高速缓存服务器使用以存储文件或文件部分，且提供接收器对文件或文件部分的存取。按其原始次序的可用作HTTP文件的文件或文件部分在本文中被称作“原始次序HTTP文件”。通常，用于单播修复请求的原生HTTP支持的方法可基于SBN和ESI将对HTTP文件的源块的符号和子符号的修复请求翻译为HTTP文件内的标准HTTP八位字节范围请求(常常被称作具有指定字节范围的HTTP部分GET请求)。此情形使标准HTTP网络高速缓存服务器能够对此等修复请求进行服务，从而避免了大规模部署能理解如何将HTTP文件分割成源块和源块内的源符号的专门HTTP网络高速缓存服务器的需要。

在此等情形下，当系统FEC码在使用中时，常常有利地是只在会话中的一些(例如，广播/组播会话)中发送修复符号，这是因为此情形允许接收器在单播修复请求中只请求源符号。此情形具有只需要将HTTP文件或如下文更详细描述的HTTP文件的简单重排变换提供到可为标准HTTP网络高速缓存服务器的单播修复服务器的优势，从而使定义HTTP文件及分发HTTP文件的后勤工作更简单，这是因为此等后勤工作独立于FEC编码。另一优势是，如果在会话中没有发送源符号，那么因为所有源符号“缺失”，接收器可在单播修复请求中请求源符号的任何序列，此情形可为优选的，这是因为此情形允许对源符号的连续序列的修复请求。举例来说，假设使用具有理想恢复特性的FEC码，且一个部分的源块包括1,000个源符号，且针对源块接收700个修复符号(即使修复符号中的一些可在传输中丢失，且因此所接收的修复符号的ESI的模式可能远远不是连续的)。接着，接收器可在单播修复请求中请求源块的前300个连续源符号，且将此等源符号与700个修复符号组合以恢复源块。如果源符号在HTTP文件中是连续的，那么可将单一HTTP八位字节范围请求用以请求及接收所有300个连续源符号。接收器不一定需要进行前缀请求(即，对文件的从第一字节开始的设定数目的字节的请求)，但在一些情况下，这会更简单。

请求是针对特定数目个字节或符号。在一些情况下，接收器将基于所接收的修复符号的数目及预期含于待接收的文件或对象中的源符号的数目来确定要请求的源符号的数目。在其它情况下，接收器可能执行调度操作，其中接收器确定如何只使用其已经接收的修复符号来进行解码，且因此可注意到需要更特定数目个源符号。举例来说，修复符号中的一些可能是其它修复符号的冗余，在所述情况下，可能需要更多的源符号。在其它状况下，结果可能是需要较少源符号。

接收器可基于FEC OTI，将对原始次序HTTP文件的对应于特定(SBN，ESI)对的源符号的请求翻译为HTTP八位字节范围请求。举例来说，假设文件的FEC OTI是(F、Al、T、Z、N)，且将被请求的源符号的SBN是A，且所述源符号的ESI是B，且出于简单起见，假设N＝1，即，在文件结构的此实例中源块不会进一步被分割成子区块。接着，接收器可应用(例如)[RaptorQ-Spec]第4.4章中所描述的方法，以确定(KL、KS、ZL、ZS)，其中前ZL个源块具有KL个源符号，且剩余ZS个源块具有KS个源符号。接着，基于A、B及符号大小T，接收器可确定源符号在文件内的开始八位字节索引如等式1中所示，其中源符号在文件内的结束八位字节索引是EI＝SI+T。接着，接收器可使用对源符号的标准HTTP八位字节范围请求。

SI＝T*(KL*min{A，ZL}+KS*max{A-ZL，0}+B)  (等式1)

如所属领域的技术人员将认识到，存在对此等方法的许多扩展和改进。举例来说，如果在未使用子块的情况下从原始次序HTTP文件中请求多个连续源符号，那么可进行单一HTTP八位字节范围请求。作为另一实例，除了原始次序HTTP文件之外或代替原始次序HTTP文件，HTTP网络高速缓存服务器可具有含有修复符号的文件，或可已经扩展原始次序HTTP文件以含有修复符号，且接收器可使用类似于本文中所描述的方法的方法来进行对修复符号的HTTP八位字节范围请求。作为增强的另一实例，可使用如所属领域的技术人员将认识到的类似方法，扩展此等方法以处置使用子块的情况。举例来说，接收器可使用[RaptorQ-Spec]第4.4章中所描述的方法来确定(TL、TS、NL、NS)，其中源块的前NL个子块具有大小TL*Al，且源块的剩余NS个子块具有大小TS*Al。接着，基于A、B和符号大小T，接收器可确定对应于源符号的具有N个子符号的符号在文件内的开始和结束八位字节索引，且使用标准HTTP八位字节范围请求来进行对此等八位字节的请求。

作为另一实例，接收器可基于FEC OTI，将对于文件或文件部分的对应于特定UFSI的源符号的请求翻译为HTTP八位字节范围请求。

以下方法可极大地增强由接收器使用标准HTTP字节范围请求来恢复HTTP文件的符号的效率，而同时使用标准HTTP网络高速缓存服务器来将所请求的八位字节范围请求传递到接收器。

支持如所描述的HTTP八位字节范围请求的直接方法是使用原始次序HTTP文件。此方法具有不需要变换原始文件或文件部分来产生用于HTTP网络高速缓存服务器的原始次序HTTP文件的优势，但所述方法具有可能需要许多不同HTTP八位字节范围请求来请求源符号(甚至是在针对每一源块只请求连续源符号时)的劣势。此情形有至少两个原因：(1)可能存在多个源块，且缺失来自每一源块的源符号，在所述情况下，可能需要针对每一源块的单独八位字节范围请求；(2)可能存在每源块多个子块，且因此甚至从一个源块请求单一源符号也可能需要对组成源符号的多个子符号的多个HTTP八位字节范围请求，这是因为源符号的子符号可能在原始次序HTTP文件中不连续。

一种支持上文所描述的HTTP八位字节范围请求的有利方法首先基于原始文件或文件部分的FEC OTI，将文件或文件部分重新组织为新的格式，本文中称作“UFSI次序HTTP文件”。此方法在存在多个源块和/或每源块多个子块时是有用的。UFSI次序HTTP文件中的数据的次序是按具有UFSI0的文件符号、具有UFSI1的文件符号、具有UFSI2的文件符号等的次序，即，将UFSI次序HTTP文件中的数据的次序组织为根据递增的连续UFSI(如由FEC OTI所确定)而排序的文件符号。URL可与UFSI次序HTTP文件相关联，且可将URL提供给HTTP网络高速缓存系统。接收器接着可使用HTTP八位字节范围请求，来在需要时请求UFSI次序HTTP文件的部分。UFSI次序HTTP文件的一个优势是，如果接收器从源块中的每一者接收大约相同数目个修复符号，那么获得足够用以恢复原始文件或文件部分的源符号所需要的HTTP八位字节范围请求的数目可为最小，例如，如果针对每一源块接收完全相同数目个修复符号，那么一个HTTP八位字节范围请求可为足够的。举例来说，对UFSI次序HTTP文件的前L*T*Z个连续八位字节的请求就足以从原始文件或文件部分的Z个源块中的每一者接收大小为T的前L个源符号。如果在一个或一个以上会话中接收到针对Z个源符号中的每一者的K-L个修复符号，且如果FEC码具有理想恢复特性，那么从HTTP八位字节范围请求接收的L*T*Z个八位字节就足以FEC解码HTTP文件，其中在此实例中，假定K是Z个源块中的每一者中的源符号的数目。

支持上文所描述的HTTP八位字节范围请求的另一有利方法首先基于原始文件或文件部分的FEC OTI，将文件或文件部分重新组织为不同的新格式，本文中称作“SS次序HTTP文件”。此方法在存在每源块多个子块时有用，这是因为在此情况下，每一源符号可不是原始文件或文件部分的连续部分，即，源符号的子符号可散布于按原始文件排序的源块中。SS次序HTTP文件中的数据的次序是按第一源块的所有源符号，接着第二源块的所有源符号，接着第三源块的所有源符号等的次序，即，SS次序HTTP文件中的数据的次序被组织为根据源块内的递增的连续ESI次序而排序的源符号，且是按递增的连续SBN次序的源块的串接，如由FEC OTI所确定。URL可与SS次序HTTP文件相关联，且可将URL提供给HTTP网络高速缓存系统。接收器接着可使用HTTP八位字节范围请求，来在需要时请求SS次序HTTP文件的部分。如果接收器从源块中的每一者接收不同数目个修复符号，那么SS次序HTTP文件是尤其有利的。举例来说，如果存在各自具有1,000个源符号的两个源块，且如果接收器从一个或一个以上会话中接收到针对第一源块的900个修复符号及针对第二源块的100个修复符号，那么接收器可对SS次序HTTP文件的前T*100个八位字节进行一个请求，且接收针对第一源块的100个源符号，且接收器可对SS次序HTTP文件的T*1,000+1到T*1,900个八位字节进行另一请求，且接收针对第二源块的900个源符号，其中在此实例中，T是两个源块的符号大小(按八位字节计)。

还可能使用刚刚描述的两个方法的组合，即，可通过不同URL使UFSI次序HTTP文件和SS次序HTTP文件对于接收器可用，且接着接收器可使用对两个不同格式化的HTTP文件的HTTP八位字节请求的组合。举例来说，如果存在各自具有1,000个源符号的10个源块，且如果在一个或一个以上会话中，针对前8个源块中的每一者接收800个修复符号，针对第9个源块接收820个修复符号，且针对第10个源块接收500个修复符号，那么接收器可能进行对UFSI次序HTTP文件的HTTP八位字节范围请求，以接收针对10个源块中的每一者的200个源符号，且进行对SS次序HTTP文件的额外HTTP八位字节范围请求，以接收针对第10个源块的额外300个源符号。在此实例中，接收器可接收针对第9个源块的不需要的20个源符号(假定具有理想恢复特性的FEC码)，但在一些情况下，使用较小数目个HTTP八位字节范围请求来请求多于一些源块的最小所需八位字节数的八位字节可比请求每一源块的正好所需源符号数目(此可需要大得多的数目个不同HTTP八位字节范围请求)更有效率。

所属领域的技术人员将认识到，存在关于此等方法的许多变化。举例来说，HTTP文件、UFSI次序HTTP文件和SS次序HTTP文件皆可用于请求。作为另一实例，SS次序HTTP文件可被分开，且可用作许多HTTP文件，针对每一源块有一个此类HTTP文件。作为变体的其它实例，可能使用除了基于HTTP的方法和协议之外的方法和协议，例如可能使用基于RTP/UDP的方法，或基于UDP而建立的专有协议等。

硬件系统和实例

上文所描述的方法和系统可以硬件、软件和/或含有程序代码或其它指令的被恰当组织的计算机可读媒体来实施。在本文中提供可能使用上文教示的系统的一些实例。

图13是使用多级译码的通信系统1300的方框图，通信系统1300可作为如本文中所描述的文件传递系统的部分用以发送包。当然，可替代地使用其它代码和/或硬件。

在通信系统1300中，输入文件1301或输入流1305被提供给输入符号产生器1310。输入符号产生器1310从输入文件或流产生一个或一个以上输入符号(IS(0)、IS(1)、IS(2)、......)的序列，其中每一输入符号具有值和位置(在图13中表示为括弧中的整数)。如上文所解释，输入符号的可能值(即，其字母表)通常是具有2^M个符号的字母表，使得每一输入符号针对输入文件的M个位进行译码。值M通常是由通信系统1300的用途来确定，但通用系统可能包含针对输入符号产生器1310的符号大小输入，使得M可在不同的用途间变化。输入符号产生器1310的输出被提供给编码器1315。

静态键产生器1330产生静态键S₀、S₁、...的流。所产生的静态键的数目通常受限制，且取决于编码器1315的特定实施例。随后将更详细描述静态键的产生。动态键产生器1320产生将由编码器1315产生的每一输出符号的动态键。产生每一动态键，使得相同输入文件的大部分动态键是唯一的。举例来说，Luby I描述了可使用的键产生器的实施例。动态键产生器1320和静态键产生器1330的输出被提供给编码器1315。

根据由动态键产生器1320提供的每一键I，编码器1315从由输入符号产生器提供的输入符号产生具有值B(I)的输出符号。下文将更详细描述编码器1315的操作。每一输出符号的值是基于其键，基于输入符号中的一个或一个以上者及可能从输入符号计算得到的一个或一个以上冗余符号的某一函数产生。引起特定输出符号的输入符号和冗余符号的集合在本文中被称作输出符号的“相关联的符号”或仅称作其“关联物”。根据下文更详细描述的过程来进行函数(“值函数”)及关联物的选择。通常，但不总是，M对于输入符号和输出符号是相同的，即，输入符号和输出符号都针对相同数目个位进行译码。

在一些实施例中，输入符号的数目K由编码器1315使用以选择关联物。如果预先不知道K，例如当输入是流式传输文件时，那么K可能只是估计。值K还可能由编码器1315使用，来为由编码器1315产生的输入符号和任何中间符号分配存储器。

编码器1315将输出符号提供给发射模块1340。发射模块1340还被提供来自动态键产生器1320的每一此类输出符号的键。发射模块1340通过信道1345发射输出符号到接收模块1350，且取决于所使用的键控方法，发射模块1340还可能发射关于所发射的输出符号的键的某数据。假定信道1345是擦除信道，但此并非对于通信系统1300的恰当操作为必需的。

模块1340、1345和1350可为任何合适的硬件组件、软件组件、物理媒体或其任何组合，只要发射模块1340适合于将输出符号及关于输出符号的键的任何所需数据发射到信道1345，且接收模块1350适合于从信道1345接收符号及潜在地关于符号的键的某数据便可。值K在用以确定关联物的情况下可被通过信道1345发送，或可在编码器1315和解码器1355达成一致的情况下预先设定值K。其它元件展示于图13中(及在本文中别处，不管是否描述为模块、步骤、过程等，都也可使用硬件、软件和/或存储在电子可读媒体上的程序代码来实施)。

如上文所解释，信道1345可为实时信道，例如，因特网上的路径，或从电视发射器到电视接收者的广播链路，或从一点到另一点的电话连接，或者信道1345可为存储信道，例如，CD-ROM、磁盘驱动器、网站或其类似者。信道1345可能甚至为实时信道和存储信道的组合，例如，当某人通过电话线将输入文件从个人计算机传输到因特网服务供应商(ISP)，将输入文件存储在网络服务器上，且随后通过因特网传输到接收者时形成的信道。

因为假定信道1345是擦除信道，所以通信系统1300不会假定离开接收模块1350的输出符号与进入发射模块1340的输出符号之间的一一对应。事实上，在信道1345包括包交换网络的情况下，通信系统1300可能甚至不能够假定在通过信道1345的过程中保持任何两个或两个以上包的相对次序。因此，使用上文所描述的键控方案中的一个或一个以上者来确定输出符号的键，且键不一定由输出符号离开接收模块1350的次序来确定。

接收模块1350将输出符号提供给解码器1355，且将接收模块1350接收的关于此等输出符号的键的任何数据提供给动态键再生器1360。动态键再生器1360重新产生所接收的输出符号的动态键，且将此等动态键提供给解码器1355。静态键产生器1363重新产生静态键S₀、S₁、...，且将其提供给解码器1355。静态键产生器可存取在编码和解码过程期间都使用的随机数产生器1335。此可呈存取相同物理装置(如果在此类装置上产生随机数)的形式，或呈存取用于产生随机数以实现相同特性的相同算法的形式。解码器1355将由动态键再生器1360及静态键产生器1363提供的键与对应输出符号一起用来恢复输入符号(再一次IS(0)、IS(1)、IS(2)、...)。解码器1355将经恢复的输入符号提供给输入文件重新组装器1365，输入文件重新组装器1365产生输入文件1301或输入流1305的副本1370。

可通过多个接收器和/或多个发送器来进行文件传递。此等概念在图14到图15中图解说明。

图14图解说明了一个接收器2402通过三个信道2406从三个发射器2404(个别地表示为“A”、“B”和“C”)接收数据的布置。此布置可用以使接收器的可用带宽增至三倍，或应付可用时长不足以从任何一个发射器获得整个文件的发射器。如图所指示，每一发射器2404发送值S()的流。每一S()值表示输出符号B(I)和键I，上文解释了输出符号B(I)和键I的使用。举例来说，值S(A，n_A)是在发射器2402(A)处产生的输出符号序列中的第“n_A”个输出符号和第“n_A”个键。来自一个发射器的键的序列优选地与来自其它发射器的键的序列相异，使得发射器不会重复工作。此情形在图14中通过序列S()随发射器而变的事实而图解说明。

注意到，不必为了避免重复工作而对发射器2402进行同步或协调。事实上，在不进行协调的情况下，每一发射器可能在其序列中的不同位置中(即，n_A≠n_B≠n_C)。

在图15中，将一个输入文件2502的副本提供给多个发射器2504(所述发射器2504中的两者展示于图中)。发射器2504独立地通过信道2506将根据输入文件2502的内容产生的输出符号发射到接收器2508。所展示的两个发射器中的每一发射器可能只需要发射(K+A)/2个输出符号，之后接收器的解码器就能够恢复整个输入文件。

通过使用两个接收器和两个发射器，由接收器单元2510接收的信息的总量可为在一个信道2506上可用的信息的四倍。如果(例如)发射器将相同数据广播到两个接收器，那么信息量可能小于单一信道信息的四倍。在彼情况下，如果数据在任何信道中丢失，那么接收器单元2510处的信息量至少是两倍且常常更多。应注意到，即使发射器只广播一个信号，但接收器在不同时间起作用(in view)，所以有一个以上接收器侦听每一发射器具有优势。在图15中，接收器单元2510执行类似于图1中所示的接收器150、解码器155、键再生器160和输入文件重新组装器165的功能的功能。

在一些实施例中，在具有两个编码器的一个计算装置中编码输入文件2502，使得计算装置可提供用于一个发射器的一个输出和用于另一发射器的另一输出。在回顾了本发明之后，此等实例的其它变化应为显而易见的。

应理解，本文中所描述的译码设备和方法还可在其它通信情形下使用，且不限于例如因特网等的通信网络。举例来说，光盘技术也使用擦除和纠错码来处置被刮花光盘的问题，且将受益于使用链式反应码来存储信息于光盘上。作为另一实例，卫星系统可使用擦除码以便在用于传输的功率要求方面进行折衷，通过减小功率而有目的地允许更多错误，且链式反应译码在彼应用中将是有用的。又，已使用擦除码来开发RAID(冗余独立磁盘阵列)系统以用于可靠地存储信息。本发明因此可证实在使用码来处置潜在有损耗或错误数据的问题的其它应用(例如上文实例等)中是有用的。

在一些优选实施例中，将执行上文所描述的通信过程的指令集(或软件)提供给通过可能有损耗通信媒体来通信的两个或两个以上多用途计算机器。机器的数目可在一个发送器和一个接收者到任何数目个进行发送和/或接收的机器之间变化。连接机器的通信媒体可为有线的、光学的、无线的，或其类似者。上文所描述的通信系统具有应从本描述中显而易见的许多用途。

使用HTTP流式传输服务器的块请求流式传输系统可能如上文所描述地传递文件。下文中，描述了此类系统的实例实施。在HTTP流式传输的情况下，源可能为标准网络服务器和内容传递网络(CDN)，且可能使用标准HTTP。

在客户端，可使用HTTP针对由客户端无缝地拼接在一起的个别区段进行请求。HTTP流式传输的优势包含使用标准化和现有基础结构。

图16展示了可能传递文件的块请求流式传输系统的简化图。在图16中，图解说明了块流式传输系统100，其包括块服务基础结构(“BSI”)101，块服务基础结构(“BSI”)101又包括注入系统103，注入系统103用于注入内容102，准备彼内容，且通过将内容存储到可由注入系统103和HTTP流式传输服务器104存取的内容存储区110中而封装内容以用于由HTTP流式传输服务器104提供的服务。如图所示，系统100还可能包含HTTP高速缓存106。在操作时，例如HTTP流式传输客户端等的客户端108将请求112发送到HTTP流式传输服务器104，且从HTTP流式传输服务器104或HTTP高速缓存106接收响应114。在每一情况下，图16中所示的元件可能至少部分以软件来实施，软件中包括在处理器或其它电子器件上执行的程序代码。

如图17中所示，媒体块可存储在块服务基础结构101(1)内，块服务基础结构101(1)可为(例如)HTTP服务器、内容传递网络装置、HTTP代理、FTP代理或服务器，或某其它媒体服务器或系统。块服务基础结构101(1)连接到网络122，网络122可为(例如)因特网协议(“IP”)网络，例如因特网等。块请求流式传输系统客户端被展示为具有六个功能组件，即：块选择器123，其被提供了上文所描述的元数据，且执行从由元数据指示的多个可用块当中选择要被请求的块或部分块的功能；块请求器124，其从块选择器123接收请求指令，且执行必要的操作以通过网络122将对指定块、块的部分或多个块的请求发送到块服务基础结构101(1)，且接收返回的包括块的数据；以及块缓冲器125；缓冲器监视器126；媒体解码器127；和促进媒体消费的一个或一个以上媒体转换器128。

由块请求器124接收的块数据被传到存储媒体数据的块缓冲器125以用于临时存储。或者，所接收的块数据可直接存储到如图17中图解说明的块缓冲器125中。块缓冲器125向媒体解码器127提供媒体数据，且媒体解码器127对此数据执行必要变换，以将合适的输入提供给媒体转换器128，媒体转换器128使媒体呈适用于用户或其它消费的形式。媒体转换器的实例包含视觉显示装置，例如在移动电话、计算机系统或电视中发现的视觉显示装置等，且还可能包含音频呈现装置，例如扬声器或头戴式耳机等。

缓冲器监视器126接收关于块缓冲器125的内容的信息，且基于此信息和可能其它信息，将输入提供给块选择器123，如本文中所描述，块选择器123用以确定要请求的块的选择。

块请求流式传输系统(BRSS)包括向一个或一个以上内容服务器(例如，HTTP服务器、FTP服务器等)进行请求的一个或一个以上客户端。注入系统包括一个或一个以上注入处理器，其中注入处理器接收内容(实时或非实时)，处理内容以供BRSS使用，且将所述内容(可能还连同由注入处理器产生的元数据一起)存储到可由内容服务器存取的存储器中。

BRSS也可能含有与内容服务器相配合的内容高速缓存。内容服务器和内容高速缓存可能为常规HTTP服务器和HTTP高速缓存，其接收呈包含URL且还可包含八位字节范围(以便请求少于由URL指示的所有文件或区段的数据)的HTTP请求的形式的对文件或区段的请求。客户端可能包含进行对HTTP服务器的请求且处置对彼等请求的响应的常规HTTP客户端，其中HTTP客户端由新型客户端系统驱动，所述新型客户端系统表述请求，将其传到HTTP客户端，从HTTP客户端得到响应，且处理此等响应(或存储、变换等)，以便将其提供给呈现播放器(presentation player)以供客户端装置播放。通常，客户端系统预先不知道将需要何种媒体(这是因为需要可能取决于用户输入、用户输入的改变等)，因此客户端系统被称为“流式传输”系统，这是因为媒体在一被接收之后即被“消费”，或在被接收之后不久就被“消费”。结果，响应延迟和带宽约束可造成呈现的延迟，例如，在所述流赶到用户正消费所述呈现的地方时造成呈现的暂停等。

为了提供被感觉具有良好质量的呈现，可在BRSS中(在客户端处，在注入端处，或在客户端和注入端两者处)实施数种细节。在一些情况下，考虑到网络处的客户端服务器接口以及为了处理所述客户端服务器接口而实现所实施的细节。在一些实施例中，客户端系统和注入系统都感知到增强，而在其它实施例中，只有一方感知到增强。在此等情况下，即使一方未感知到增强，整个系统也可受益于增强，而在其它情况下，益处只在两方都感知到增强的情况下产生，但当一方未感知到增强时，系统仍可操作而不会出故障。

如图18中图解说明，根据各种实施例，注入系统可实施为硬件和软件组件的组合。注入系统可包括一组指令，可执行所述组指令以使系统执行本文中所论述的方法中的任何一个或一个以上者。系统可实现为呈计算机形式的特定机器。系统可为服务器计算机、个人计算机(PC)或能够执行一组指令(顺序或以其它方式)的任何系统，所述组指令指定将由彼系统采取的动作。此外，虽然只图解说明了单个系统，但是术语“系统”还应被当作包含个别或联合地执行一组(或多组)指令以执行本文中所论述的方法中的任何一个或一个以上者的系统的任何集合。

注入系统可包含：注入处理器302(例如，中央处理单元(CPU))、可在执行期间存储程序代码的存储器304，及磁盘存储装置306，其都通过总线300来相互通信。系统可进一步包含视频显示单元308(例如，液晶显示器(LCD)或阴极射线管(CRT))。系统还可包含字母数字输入装置310(例如，键盘)和用于接收内容源且传递内容存储的网络接口装置312。

磁盘存储单元306可包含机器可读媒体，在机器可读媒体上可存储体现本文中所描述的方法或功能中的任何一个或一个以上者的一个或一个以上组指令(例如，软件)。在系统执行指令期间，指令还可完全或至少部分地驻留在存储器304和/或注入处理器302内，其中存储器304和注入处理器302也构成机器可读媒体。

如图19中图解说明，根据各种实施例，客户端系统可实施为硬件和软件组件的组合。客户端系统可包括一组指令，可执行所述组指令以使系统执行本文中所论述的方法中的任何一个或一个以上者。系统可实现为呈计算机形式的特定机器。系统可为服务器计算机、个人计算机(PC)或能够执行一组指令(顺序或以其它方式)的任何系统，所述组指令指定将由彼系统采取的动作。此外，虽然只图解说明了单个系统，但是术语“系统”还应被当作包含个别或联合地执行一组(或多组)指令以执行本文中所论述的方法中的任何一个或一个以上者的系统的任何集合。

客户端系统可包含：客户端处理器402(例如，中央处理单元(CPU))、可在执行期间存储程序代码的存储器404，及磁盘存储装置406，其都通过总线400来相互通信。系统可进一步包含视频显示单元408(例如，液晶显示器(LCD)或阴极射线管(CRT))。系统还可包含字母数字输入装置410(例如，键盘)及用于发送请求且接收响应的网络接口装置412。

磁盘存储单元406可包含机器可读媒体，在机器可读媒体上可存储体现本文中所描述的方法或功能中的任何一个或一个以上者的一个或一个以上组指令(例如，软件)。在系统执行指令期间，指令还可完全或至少部分地驻留在存储器404和/或客户端处理器402内，其中存储器404和客户端处理器402也构成机器可读媒体。

特定实施例的实例

在使用[RaptorQ-Spec]中指定的RaptorQ FEC方案的用于通用对象传递的完全指定的FEC方案的此章中描述了具体实施例。UOSI FEC有效负载ID可与[RaptorQ-Spec]中的RaptorQ FEC方案一起使用(本文中被称作“UOD-RaptorQ FEC方案”)，以提供简化且增强的对象传递能力。确切地说，为基本对象传递提供了更灵活且更简单的支持，且也为不等错误保护(UEP)对象传递，为捆绑对象传递，以及为UEP和捆绑对象传递的组合提供了支持。应理解，可将合适的硬件和/或软件用以在通信装置之间实施“UOD-RaptorQ FEC方案”。

如图2中图解说明，FEC有效负载ID格式是4八位字节字段，其中在此具体实施中，通用文件符号识别符(UFSI)(32位的无符号整数)由通用对象符号识别符(UOSI)(也是32位的无符号整数)来概括。UOSI是非负整数，将UOSI与FEC OTI相结合用来识别包含于携带彼有效负载ID的包内的编码符号。

为了传递单一对象或多个对象或分割成具有不同优先级的部分的单一对象或此等对象的任何组合，FEC OTI是如下文描述。应注意到，对于所传递的每一对象，FEC OTI可与由RaptorQ FEC方案指定的FEC OTI相同。传递可能包括d个对象，d为某一正整数。每一对象可包括相同文件的不同部分、或不同文件，或其组合。对象i的大小F_i与将要用于对象i的编码符号的大小T_i之间的关系可用以确定对象i在传输中的优先级。

图20图解说明了通用FEC OTI字段的实例。如本文中所使用，对于所传递的对象的数目d，存在8位无符号整数，且所示的实例是d＝2。默认值可能为d＝1。对于d个对象中的每一者(即，对于i＝1、...、d)，其它子字段为特定针对对象i的通用FEC OTI元素，包含：用于符号大小T_i(其为小于2¹⁶的正整数)的16位无符号整数，其指示对象i的符号的大小(以八位字节为单位)；用于对象i的传送长度F_i(其为至多2⁴⁰的非负整数)的40位无符号整数，其指示对象i的传送长度(以八位字节为单位)。提供合适的填充。

与通用FEC OTI字段相对比，可能存在方案特定的FEC OTI元素，例如图21中所示的元素等。如彼实例中所示，方案特定的FEC OTI元素包含符号对准参数(Al)(8位，无符号整数)，每一对象的方案特定FEC OTI元素(其包括对象i的源块数目Z_i(12位，无符号整数)和对象i的子块数目N_i)。经编码的方案特定对象传输信息为(1+3*d)个八位字节的字段。图21中的实例是d＝2。经编码的FEC OTI接着可为(2+10*d)个八位字节的字段，其包括经编码通用FEC OTI元素与经编码方案特定FEC OTI元素的串接。

使用经编码FEC OTI的内容传递可涉及使用UOD-RaptorQ FEC方案和利用UOD-RaptorQ FEC方案进行对象传递的内容传递协议(“CDP”)在系统的装置、计算机、程序之间进行信息交换。CDP应将d、Al提供给编码器和解码器，且对于每一对象，将F_i、T_i(Al的倍数)、Z_i和N_i提供给编码器和解码器。将对象i自身提供给编码器。使用UOD-RaptorQ编码器方案的编码器将针对待发送的每一包向CDP供应包的UOSI和d个对象的编码符号。CDP将此信息传达到接收器。

现将描述参数选择的实例。

在一实例中，可能使用[RaptorQ-Spec]第4.3章中所描述的实例参数推导，其被独立地应用于d个对象中的每一者。在实例中，Al＝4八位字节，SS＝8(其暗示每一子符号将至少是SS*Al＝32八位字节)，且对象i的T_i优选地至少是SS*Al个八位字节，其中T_i是Al的倍数，而每一编码包的有效负载大小优选地具有至少T的大小，其中T是遍及T_i的总和，i＝1、...、d。

对于源块构造，可能独立地将[RaptorQ-Spec]第4.4.1章中的过程应用于d个对象中的每一者。

对于编码包构造，每一编码包将含有UOSI及d个对象的编码符号。为了实现由[RaptorQ-Spec]的RaptorQ FEC方案使用的FEC有效负载ID的(SBN，ESI)格式与由UOD-RaptorQ FEC方案使用的UOSI格式之间的兼容性，可能为特定格式。举例来说，对于每一对象，对象i的从UOSI值C到对应(SBN，ESI)值(A，B)的映射可能为B＝下限(C/Z_i)且A＝C-B*Z_i的情况。类似地，对于每一对象，从对象i的(SBN，ESI)值(A，B)到对应UOSI值C的映射将为C＝A+B*Z_i。

对于每一对象i＝1、...、d，从0到KT_i-1的UOSI值识别按源块交错次序的对象i的源符号，其中KT_i＝上限(F_i/T_i)。KT_i以后的UOSI值识别使用RaptorQ编码器从对象i的源符号产生的修复符号。

编码包可含有源符号、修复符号或源符号和修复符号的组合。包可含有来自对象i的相同源块的任何数目个符号。在对象i的源包中的最后源符号包含为了FEC编码目的而附加的填充八位字节的情况下，此等八位字节应包含于包中，以便每一包中只包含完整符号。

每一编码包中携带的通用对象符号识别符C是彼包中携带的每一对象的第一编码符号的UOSI。每一对象的包中的后续编码符号具有按顺序次序从C+1编号到C+G-1的UOSI，其中G是包中的每一对象的编码符号的数目。

在优选实施中，在每一编码包中存在用于d个对象中的每一者的一个经编码符号。在优选实施中，根据以下过程产生且发送编码包。对于每一UOSI值C＝0、1、2、3、...，编码器如下产生且发送编码包：其中编码包的FEC有效负载ID的值被设定为UOSI值C，且对于每一对象i(i＝1、...、d)，编码器确定对应于UOSI值C的(SBN，ESI)值(A_i，B_i)，根据RaptorQ FEC方案[RaptorQ-Spec]的过程从对象i产生对应于(SBN，ESI)值(A_i，B_i)的大小为T_i的编码符号E_i，将编码符号E_i附加到编码包的有效负载，且发送编码包。注意到，接收器不必知道编码包的总数。

此为一个特定实例。所属领域的一般技术人员在阅读本发明之后可预想到其它实施例。在其它实施例中，可有利地进行上文所揭示的发明的组合或子组合。为了说明的目的而展示组件的实例布置，且应理解，在本发明的替代实施例中考虑了组合、附加、重新布置及其类似者。因此，虽然已关于例示性实施例描述了本发明，但所属领域的技术人员将认识到众多修改是可能的。

举例来说，本文中所描述的过程可使用硬件组件、软件组件和/或其任何组合来实施。因此，说明书和附图应被视为说明性而非限制性的。然而，将明显看出，可对本发明进行各种修改和改变，而不脱离如权利要求书中所阐明的本发明的更广泛精神和范围，且本发明希望涵盖在以下权利要求书的范围内的所有修改和等效物。

Claims (24)

1.一种通过包交换网络传递来自电子装置或系统的一个或一个以上数据对象的方法，其中所述一个或一个以上数据对象的源数据由包中的经编码符号表示，使得可至少近似地从所述经编码符号恢复所述源数据，所述方法包括：

a)识别待传递的所述一个或一个以上数据对象中的每一数据对象的对象传输信息“OTI”，OTI包含以八位字节为单位的所述数据对象的大小F、用以表示用于表示所述数据对象的每一符号的八位字节的数目T，以及所述数据对象为了传递而被分割成的源块的数目Z；

b)产生用于所述一个或一个以上数据对象的多个包中的每一包的通用对象符号识别符“UOSI”，其中给定包的所述UOSI选自一组可能的UOSI值，其中所述组独立于所述给定包中所表示的每一数据对象的所述OTI的值；

c)从包括表示所述一个或一个以上数据对象的所述源数据的多个源符号产生多个经编码符号，所述源符号中的每一者具有在所述源数据中的位置，其中产生用于给定数据对象的给定包的经编码符号包括：

1)确定要使用的FEC编码过程；

2)从所述给定包的所述UOSI和所述给定数据对象的所述OTI，确定源块编号“SBN”和经编码符号识别符“ESI”；以及

3)至少基于以下三者针对彼经编码符号产生大小为T的经编码符号值：(a)所述FEC编码过程、(b)来自所述Z个源块中的根据彼经编码符号的所述SBN确定的源块的一个或一个以上源符号，及(c)彼经编码符号的所述ESI；

d)产生包含在步骤a)中处置的所述数据对象中的每一者的所述OTI的表示的OTI字段，其中所述OTI字段还包含由所述OTI字段表示的数据对象的数目d；

e)产生用于所述一个或一个以上数据对象的所述多个包，其中所述多个包中的每一包包括彼包的所述UOSI，及彼包中所表示的每一数据对象的使用彼数据对象的所述OTI和彼包的所述UOSI从彼数据对象产生的一个或一个以上经编码符号；以及

f)输出呈可由所述包交换网络使用的形式的所述OTI字段和所述多个包。

2.根据权利要求1所述的方法，其中每一数据对象的所述OTI还包含所述数据对象的每一源块为了传输而被分割成的子块的数目N。

3.根据权利要求1所述的方法，其进一步包括：

将SBN设定为等于UOSI模Z；以及

将ESI设定为等于小于或等于UOSI除以Z的商的最大整数。

4.一种通过包交换网络传递来自电子装置或系统的一个或一个以上数据对象的方法，其中所述一个或一个以上数据对象的源数据由包中的经编码符号表示，使得可至少近似地从所述经编码符号恢复所述源数据，所述方法包括：

a)识别待传递的所述一个或一个以上数据对象中的每一数据对象的对象传输信息“OTI”，其中当所述一个或一个以上数据对象包括一个以上数据对象时，在一次传递中的两个数据对象的OTI可不同；

b)产生用于所述一个或一个以上数据对象的多个包中的每一包的通用对象符号识别符“UOSI”，其中给定包的所述UOSI选自一组可能的UOSI值，其中所述组独立于所述给定包中所表示的每一数据对象的所述OTI的值；

c)从包括表示所述一个或一个以上数据对象的所述源数据的多个源符号产生多个经编码符号，所述源符号中的每一者具有在所述源数据中的位置，其中产生用于给定数据对象的给定包的经编码符号包括从以下三者确定彼经编码符号的值：(a)所述给定包的所述UOSI、(b)所述给定数据对象的所述OTI，及(c)一个或一个以上源符号值；

d)产生用于待传递的所述一个或一个以上数据对象的所述多个包，其中所述多个包中的每一包包括彼包的所述UOSI，及彼包中所表示的每一数据对象的使用彼数据对象的所述OTI和彼包的所述UOSI从彼数据对象产生的一个或一个以上经编码符号；以及

e)至少输出呈可由所述包交换网络使用的形式的所述多个包。

5.根据权利要求4所述的方法，其进一步包括标示符号，以使得接收器可确定符号是对应于数据对象的源符号，还是对应于可在用于恢复一个或一个以上源符号的FEC解码过程中使用的FEC修复符号，其中所述接收器通过比较包括所述符号的所述包的所述UOSI与表示数据对象中的符号的数目的值，来执行所述确定。

6.根据权利要求4所述的方法，其中所述UOSI是非负整数，且每一数据对象的所述OTI包含以八位字节为单位的所述数据对象的大小、用以表示用于表示所述数据对象的每一符号的八位字节的数目、所述数据对象为了传递而被分割成的源块的数目、源块被分割成的子块的数目，及对应于优选存储器对准的对准因子。

7.根据权利要求4所述的方法，其中

所述给定数据对象的所述OTI包含基本UOSI值；以及

从(a)所述给定包的所述UOSI、(b)所述给定数据对象的所述OTI及(c)一个或一个以上源符号值来确定彼经编码符号的值包括在确定彼经编码符号的值之前，用所述基本UOSI值来调整所述给定包的所述UOSI，从而允许实现所述UOSI的偏移值。

8.根据权利要求4所述的方法，其中确定彼经编码符号的值包括使用前向纠错“FEC”，且其中对于不同数据对象，允许不同等级的FEC保护，且从每一不同数据对象的所述OTI确定FEC保护的等级。

9.根据权利要求4所述的方法，其中所述一个或一个以上数据对象包括单一数据对象，且使用单一组OTI来产生所述一个或一个以上数据对象的每一经编码符号。

10.根据权利要求4所述的方法，其中所述一个或一个以上数据对象包括多个数据对象，且OTI字段包括：多个OTI子字段，每数据对象有一个OTI子字段；及指示所述多个数据对象中的数据对象的数目的计数子字段，其中并非所有所述OTI子字段都是相同的，且其中OTI子字段是独立于至少一个其他OTI子字段产生的。

11.根据权利要求10所述的方法，其中对于OTI子字段的数据对象，每一OTI子字段包含所述数据对象的大小、所述数据对象为了输送而被分割成的源块的数目、每源块所使用的子块的数目、所使用的符号大小，和对准因子，其中至少两个数据对象的源块的所述数目不同。

12.根据权利要求4所述的方法，其中所述一个或一个以上数据对象至少包括第一数据对象和第二数据对象，其中所述传递被组织为至少两个单独包序列，其中所述第一数据对象的编码符号在第一包序列的包中出现，且在第二包序列的包中出现，且所述第二数据对象的编码符号在所述第一包序列的包中出现，但不在所述第二包序列的包中出现。

13.根据权利要求4所述的方法，其中所述一个或一个以上数据对象中的每一者包括存储在将数据作为文件来存储的计算机可读媒体中的相异文件。

14.根据权利要求4所述的方法，其中所述一个或一个以上数据对象中的至少一者包括存储在将数据作为文件来存储的计算机可读媒体中的相异文件的部分。

15.一种使用电子装置或系统接收和解码通过包交换网络接收的一个或一个以上数据对象的方法，其中当接收到足够的经编码符号时，所接收的经编码符号被解码成表示所述一个或一个以上数据对象的源符号，所述方法包括：

a)识别所传递的所述一个或一个以上数据对象中的每一数据对象的对象传输信息“OTI”，其中当所述一个或一个以上数据对象包括一个以上数据对象时，在一次传递中的两个数据对象的OTI可不同；

b)针对要用于解码的每一经编码符号，确定所述经编码符号编码数据对象的源符号所针对的彼数据对象、经编码符号值，及包括所述经编码符号的包的通用对象符号识别符“UOSI”；

c)针对要用于解码的每一经编码符号，确定用于解码的解码参数，其中确定使用包括所述经编码符号的所述包的所述UOSI和所述对应数据对象的OTI来确定所述解码参数；

d)使用经编码符号和步骤c)中所确定的解码参数，来将所述经编码符号解码成表示数据对象的经恢复的源符号；以及

e)输出呈计算机可读形式的所述经恢复的源符号。

16.根据权利要求15所述的方法，其进一步包括通过所述所接收的经编码符号来接收所述OTI。

17.根据权利要求15所述的方法，其中所述解码参数包括源块编号和经编码符号识别符，所述方法进一步包括：

将所述源块编号设定为等于所述UOSI模所使用的源块的数目；以及

将所述经编码符号识别符设定为等于小于或等于UOSI除以所使用的源块的所述数目的商的最大整数。

18.根据权利要求15所述的方法，其进一步包括针对多个所述经编码符号中的每一者，确定所述经编码符号是对应于源符号，还是对应于可在用于恢复一个或一个以上源符号的前向纠错“FEC”解码过程中使用的FEC修复符号，其中接收器通过比较包括所述经编码符号的所述包的所述UOSI与表示数据对象中的符号的数目的值，来执行所述确定。

19.根据权利要求15所述的方法，其中所述UOSI是非负整数，且多个数据对象中的每一者的所述OTI包含以八位字节为单位的每一数据对象的大小、用以表示用于表示每一数据对象的每一符号的八位字节的数目、每一数据对象为了传递而被分割成的源块的数目、源块被分割成的子块的数目，及对应于优选存储器对准的对准因子，其中OTI值对于至少两个数据对象来说是不同的，且对于至少两个数据对象，使用不同等级的前向纠错“FEC”。

20.一种使用电子装置或系统接收和解码通过包交换网络接收的一个或一个以上数据对象的方法，其中当接收到足够的经编码符号时，所接收的经编码符号被解码成表示所述一个或一个以上数据对象的源符号，所述方法包括：

a)接收包括每一数据对象的经编码符号的一个或一个以上包；

b)确定需要数个额外符号以恢复所要数据对象；

c)从多个经编码符号文件排序中选择经编码符号文件排序，使得与在选择另一经编码符号文件排序的情况下将需要的字节范围规格相比，需要较少的字节范围规格来请求所述数个额外符号；

d)确定为了接收恢复所述所要数据对象所需要的至少所述数个额外符号要进行的一个或一个以上字节请求，所述确定是基于所述所选择的经编码符号文件排序；以及

e)将所述一个或一个以上字节请求发送到超文本输送协议“HTTP”服务器，所述HTTP服务器经配置以提供所述所选择的经编码符号文件排序。

21.根据权利要求20所述的方法，其中选择经编码符号文件排序包括基于所述所接收的一个或一个以上包的输送的类型选择所述经编码符号文件排序。

22.一种通过包交换网络传递来自电子装置或系统的一个或一个以上数据对象的方法，其中所述一个或一个以上数据对象的源数据由包中的经编码符号表示，使得可至少近似地从所述经编码符号恢复所述源数据，所述方法包括：

a)配置超文本输送协议“HTTP”服务器，所述HTTP服务器对文件请求和字节范围请求作出响应，且提供文件和字节范围；

b)基于所使用的前向纠错“FEC”确定请求模式；

c)重新排序用以对所述字节范围请求作出响应的原始次序HTTP文件；以及

d)将对所述重新排序的HTTP文件的存取提供给所述HTTP服务器，

其中所述重新排序使得基于所述所使用的FEC的预期请求将需要比在所述HTTP服务器存取所述原始次序HTTP文件而非所述重新排序的HTTP文件的情况下将需要的字节范围规格少的字节范围规格。

23.根据权利要求22所述的方法，其中

所述所使用的FEC将数据对象的源块分割成多个子块，所述源块包括源符号；以及

所述重新排序的HTTP文件是按连续源块次序，且在源块内，是按源符号次序。

24.根据权利要求22所述的方法，其中

所述所使用的FEC使用按交错次序的多个源块，且将数据对象的源块分割成多个子块，所述源块包括源符号；以及

所述重新排序的HTTP文件是按源块交错次序，且在源块内，是按源符号次序。

Images