在http服务器之间分配源数据和修复数据的内容传送系统的制作方法

文档序号:7993763阅读:526来源:国知局
在http服务器之间分配源数据和修复数据的内容传送系统的制作方法
【专利摘要】通过分组交换网络来传送数据对象,接收机接收具有足够信息的经编码的符号(诸如修复符号、广播或多播),以便基于需要什么源符号或子符号,或者丢失了什么源符号或子符号,形成针对所需要的其它符号的请求。这些请求可以是以单播或者请求方式来进行。请求和广播可以由不同的实体来执行。广播服务器可以生成和存储修复符号,而源服务器可以以源形式来存储内容。请求可以是以位置和长度开始的单播HTTP字节范围请求(例如,URL)。可以将请求与文件的起始位置进行对齐。接收机可以计算符号或者子符号在文件中的起始和结束字节位置,获得传统的HTTP服务器可用于文件修复的指示。当来自多个接收机的字节范围请求重叠时,修复服务器可以请求修复数据的广播。
【专利说明】在HTTP服务器之间分配源数据和修复数据的内容传送系 统
[0001] 相关申请的交叉引用
[0002] 本申请要求以下专利申请的优先权,并是其非临时申请:2011年11月1日提交 的、题目为 "Unicast Repair Service and Server Augmenting Broadcast File Delivery System"的美国临时专利申请No. 61/554,434(代理案号为No. 121519P1) ;2012年1月 23 日提交的、题目为 "Unicast Repair Service and Server Augmenting Broadcast File Delivery System" 的临时专利申请 No.61/589,855(代理案号为 No. 121519P2) ;2012 年 3 月 22 日提交的、题目为 "Unicast Repair Service and Server Augmenting Broadcast File Delivery System" 的临时专利申请 No. 61/614, 408(代理案号为 No. 121519P3) ;2012 年 5 月 10 日提交的、题目为 "Content Delivery System with Allocation of Source Data and Repair Data Among HTTP Servers" 的美国临时专利申请 No. 61/645, 562 (代理案号 为 No. 121519P4);以及 2012 年 5 月 15 日提交的、题目为 "Content Delivery System with Allocation of Source Data and Repair Data Among HTTP Servers" 的美国临时专利申请 No. 61/647, 414(代理案号为No. 121519P5),故出于所有的目的以引用方式将上述临时申 请的全部内容并入本文。
[0003] 本公开内容可以涉及以下共同转让的专利或申请,故出于所有目的,以引用方式 将这些专利或者申请中的每一个的全部内容并入本文:
[0004] 1)授予 Michael G. Luby 的、题目为 "Information Additive Code Generator and Decoder for Communication Systems" 的美国专利 No. 6, 307, 487(下文称为 "Luby I");
[0005] 2)授予Michael G. Luby 的、题目为"Information Additive Group Code Generator and Decoder for Communication Systems" 的美国专利 No. 6, 320, 520 (下文称为 "Luby Π ");
[0006] 3)授予 Μ· Amin Shokrollahi 的、题目为 "Systems and Processes for Decoding a Chain Reaction Code Through Inactivation" 的美国专利 No. 6, 856, 263 (下文称为 "Shokrollahi I");
[0007] 4)授予 Μ· Amin Shokrollahi 的、题目为 "Systematic Encoding and Decoding of Chain Reaction Codes"(hereinafter "Shokrollahi II" 的美国专利 No. 6, 909, 383 (下文 称为 "Shokrollahi II");
[0008] 5)授予 Μ· Amin Shokrollahi 的、题目为 "Multi-Stage Code Generator and Decoder for Communication Systems" 的美国专利 No. 7, 068, 729 (下文称为"Shokrollahi III");
[0009] 6)授予 Michael G. Luby、Μ· Amin Shokrollahi 和 Mark Watson 的、题目为 "File Download and Streaming System" 的美国专利 No. 7, 418, 651 (下文称为 "Luby III");
[0010] 7)专利人为 Michael G. Luby 和 Μ· Amin Shokrollahi 的、题目为 "In-Place Transformations with Applications to Encoding and Decoding Various Classes of Codes"的美国专利公开No. 2006/0280254 (下文称为"Luby IV");
[0011] 8)专利人为 Μ· Amin Shokrollahi 的、题目为"Multiple-Field Based Code Generator and Decoder for Communications Systems" 的美国专利公开 No. 2007/0195894(下文称为 "Shokrollahi IV");
[0012] 9)以M. Amin Shokrollahi等人的名义在2009年10月23日提交的、题目为 ^Method and Apparatus Employing FEC Codes with Permanent Inactivation of Symbols for Encoding and Decoding Processes" 的美国专利申请 No. 12/604, 773 (下文称为 "Shokrollahi V");
[0013] 10)以Michael G. Luby的名义在2009年8月19日提交的、题目为"Methods and Apparatus Employing FEC Codes with Permanent Inactivation of Symbols for Encoding and Decoding Processes" 的美国临时申请 No. 61/235, 285 (下文称为 "Luby V");
[0014] 11)以 Michael G. Luby、M. Amin Shokrollahi 的名义在 2010 年 8 月 18 日提交的、 题目为"Methods and Apparatus Employing FEC Codes with Permanent Inactivation of Symbols for Encoding and Decoding Processes" 的美国专利申请 No. 12/859, 161 (下文称 为 "Shokrollahi VI");
[0015] 12)以MichaelG.Luby、ThadiM.Nagaraj 的名义在 2011 年8 月 9 日提交的、题目 为 "Broadcast Multimedia Storage and Access Using Page Maps when Asymmetric Memory is Used"的美国专利申请No. 13/206, 418(下文称为"Luby VI");
[0016] 13)以 Michael G. Luby、Nikolai Leung、Ralph Gholmieh、Thomas Stockhammer 的 名义在 2012 年 5 月 10 日提交的、题目为 "Content Delivery System with Allocation of Source Data and Repair Data Among HTTP Servers" 的美国专利申请 No. 61/645, 562 (下文 称为 "Luby VII");
[0017] 参考文献
[0018] 出于所有目的,以引用方式将下列参考文献中的每一个的全部内容并入本文:
[0019] [Albanese96]或[PET],"Priority Encoding Transmission",Andres Albanese、 Johannes Blomer、Jeff Edmonds、Michael Luby 和 Madhu Sudan,IEEE Transactions on Information Theory,vo 1. 42, no. 6 (1996 年 11 月);
[0020] [Albanese97]或[PET-Patent],授予 A. Albanese,Μ· Luby,J. Blomer,J. Edmonds 的、题目为 "System for Packetizing Data Encoded Corresponding to Priority Levels Where Reconstructed Data Corresponds to Fractionalized Priority Level and Received Fractionalized Packets" 的美国专利 No. 5, 617, 541 (1997 年 4 月 1 日发布);
[0021] [ALC], Luby, M. Watson, M. Vicisano, L. , uAsynchronous Layered Coding(ALC) Protocol Instantiation",IETF RFC5775 (2〇10 年 4 月);
[0022] [FEC BB] , Watson, M. , Luby, M. , and L. Vicisano, "Forward Error Correction(FEC)BuildingBlock",IETFRFC5052(2007 年8月);
[0023] [FLUTE],Paila,T.,Luby,M.,Lehtonen,R.,Roca,V.,Walsh,R.,"FLUTE-File Delivery over Unidirectional Transport",IETF RFC3926 (2〇04 年 10 月);
[0024] [LCT],Luby,Μ·,Watson,Μ·,Vicisano, L.,"Layered Coding Transport (LCT) Building Block",IETF RFC5651 (2〇〇9 年 10 月);
[0025] [Luby2007]或[Raptor-RFC-5053],M. Luby,A. Shokrollahi,M. Watson,Τ· Stockhammer, "Raptor Forward Error Correction Scheme for Object Delivery",IETF RFC5〇53(2〇〇7 年 9 月);
[0026] [Luby2002] , Luby, Μ·,Vicisano, L.,Gemmel 1,J.,Rizzo, L.,Handley, Μ·,和 J. Crowcroft, "The Use of Forward Error Correction (FEC) in Reliable Multicast", IETF RFC3453(2〇〇2 年 l2 月);
[0027] [Mat suoka]或[LDPC-Ext ens i ons]," Low-Dens i ty Par i ty-Check Code Extensions Applied for Broadcast-Communication Integrated Content Delivery",Hosei Matsuoka, Akira Yamada 和 Tomoyuki Ohya, Research Laboratories, NTT DOCOMO, Inc.,3-6, Hikari-N〇-〇ka, Yokosuka, Kanagawa, 239-8536,日本;以及
[0028] [RaptorQ-RFC-6330] , M. Luby,A. Shokrollahi,M. Watson, T. Stockhammer,L. Minder, "RaptorQ Forward Error Correction Scheme for 0bject Delivery,',IETF RFC633〇, Reliable Multicast Transport (2〇ll 年 8 月);
[0029] [Roca]或[LDPC-RFC-5170],V. Roca,C. Neumann, D. Furodet,"Low Density Parity Check(LDPC)Staircase and Triangle Forward Error Correction(FEC)Schemes",IETF RFC5170(2008 年 6 月)。

【技术领域】
[0030] 概括地说,本发明涉及通信系统中对数据的编码和解码,更具体地说,涉及对数据 进行编码和解码,以便以高效的方式考虑所通信的数据中的错误和差距以及处理不同的文 件传送方法的通信系统。

【背景技术】
[0031] 用于通过通信信道在发送方和接收方之间传输文件的技术是许多文献的主题。优 选地,接收方期望以某种确定的程度,接收由发送方通过信道所发送的数据的准确拷贝。在 信道不具有完美的保真度的情况下(这涵盖几乎所有物理可实现的系统),一个考虑的问 题是如何处理传输中丢失或乱码的数据。与损坏的数据(错误)相比,丢失的数据(擦除) 通常更容易处理,这是由于接收方无法总是告知损坏的数据是错误接收的数据。已开发了 许多纠错编码来纠正擦除和/或错误。
[0032] 典型地,基于与通过其来发送数据的信道的失真有关的某些信息以及所发送的数 据的本质来选择使用的具体编码。例如,在已知信道具有较长时段的失真的情况下,突发错 误编码可能最适合于这种应用。而在失真仅是短暂的情况下,预计有稀少的错误,则简单的 奇偶校验码可能是最佳的。
[0033] 如本文中所使用的"源数据"指在一个或多个发送方处可获得以及使用接收机获 得(通过从具有或者不具有错误和/或擦除等的发送的序列中恢复)的数据。如本文中所 使用的"经编码的数据"指被传送的并且可以用于恢复或者获得源数据的数据。在简单的 情况下,经编码的数据是源数据的拷贝,但如果所接收的经编码的数据与发送的经编码的 数据不相同(由于差错和/或擦除),则在该简单情况中,由于缺少关于源数据的额外数据, 因此该源数据可能无法被完整地恢复。传输可以通过空间或者时间。在更复杂情况下,经 编码的数据是基于源数据变换生成的,并且是从一个或多个发送方发送给接收方的。如果 发现源数据是经编码的数据的一部分,则可以将编码称为"系统化的"。在系统化编码的简 单示例中,将关于源数据的冗余信息附加到该源数据的尾部以形成经编码的数据。
[0034] 此外,如本文中所使用的"输入数据"指出现在FEC(前向纠错)编码器装置或者 FEC编码器模块、组件、步骤等的输入端的数据,而"输出数据"指出现在FEC编码器的输出 端的数据。相应地,期望输出数据出现在FEC解码器的输入端,并且期望FEC解码器基于其 处理的输出数据来输出该输入数据(或其对应数据)。在一些情况下,输入数据是(或者包 括)源数据,而在一些情况下,输出数据是(或者包括)经编码的数据。例如,如果在FEC 编码器的输入端之前没有进行处理,则输入数据是源数据。然而,在一些情况下,将源数据 处理成不同的形式(例如,静态编码器、逆编码器或者另一种处理),以生成提供给FEC编码 器的中间数据而不是源数据。
[0035] 在一些情况下,发送方设备或者发送方程序代码可以包括一个以上的FEC编码 器,即,在一系列的多个FEC编码器中将源数据转换成经编码的数据。类似地,在接收机处, 可以存在一个以上的FEC解码器,以用于根据所接收的经编码的数据来生成源数据。
[0036] 数据可以被认为是划分成了符号。编码器是根据源符号或输入符号的序列来生成 经编码的符号或输出符号的计算机系统、设备、电子电路等,而解码器是根据接收的或恢复 的经编码的符号或输出符号来恢复源符号或输入符号的序列的对应方。编码器和解码器在 时间和/或空间上被信道间隔开,并且任何接收的经编码的符号可能不是与相应发送的经 编码的符号完全一样,其可能没有如其被发送地以完全相同的序列被接收。符号的"大小" 可以以比特来测量,无论该符号是否实际被分解成一个比特流,其中,当一个符号是从2 M个 符号的字母表中选出的时,该符号具有Μ个比特的大小。在本文的很多示例中,以八位字节 来测量符号,并且代码可能跨越256种可能的字段(在每一个八位字节中,存在256种可能 的8比特模式),但应当理解的是,可以使用不同单位的数据测量,并且公知的是以各种方 式来测量数据。在一般文献中,术语"字节"有时与术语"八位字节"互换使用,用以指示8 比特值,虽然在一些上下文中,"字节"指示X比特值,其中X不等于8 (例如,X = 7)。在本 文中,术语"八位字节"和"字节"可以互换使用。除非另外指出,否则本文中的示例并不限 于每一符号具有特定整数的比特或者非整数的比特。
[0037] Luby I描述了用于以计算高效、存储高效和带宽高效的方式,来解决纠错的编码 (例如,链式反应码)的使用。链式反应编码器所产生的经编码的符号的一种属性在于:只 要接收到足够的经编码的符号,接收机就能够恢复原始文件。具体而言,为了以较高的概率 来恢复原始的K个源符号,接收机需要近似K+A个经编码的符号。
[0038] 针对给定情形的"绝对接收开销"使用值A来表示,而"相对接收开销"可以计算 成比率A/K。绝对接收开销是指除了信息理论的最小数据数量之外,还需要接收多少额外 数据的测量值,其取决于解码器的可靠性,根据源符号的数量(K)进行变化。类似地,相对 接收开销(A/K)是指:相对于要恢复的源数据的大小,除了信息理论的最小数据数量之外, 还需要接收多少额外数据的测量值,其也取决于解码器的可靠性,并根据源符号的数量(K) 进行变化。
[0039] 对于基于分组的网络上的通信来说,链式反应码是非常有用的。但是,其有时是计 算量相当地大。如果在使用链式反应码或者另一种无速率码进行编码的动态编码器之前, 使用静态编码器对源符号进行编码,则解码器可能能够更频繁或者更容易地进行解码。例 如,在Shokrollahi I中示出了这些解码器。在其所示出的示例中,源符号是静态编码器的 输入符号,静态编码器产生用于动态编码器的输入符号的输出符号,动态编码器产生作为 经编码的符号的输出符号,其中该动态编码器是无速率编码器,无速率编码器可以按照相 对于输入符号的数量,不具有固定的速率的数量,来生成多个输出符号。静态编码器可以包 括一个以上的固定速率编码器。例如,静态编码器可以包括Hamming编码器、低密度奇偶校 验("LDPC")编码器、高密度奇偶校验("HDPC")编码器等。
[0040] 链式反应码具有下面的属性:由于一些符号是解码器根据所接收的符号来恢复 的,因此这些符号能够用于恢复额外符号,这些额外符号随后可以用于恢复更多的符号。优 选地,在解码器处求解的符号的链式反应可以继续进行,使得在使用完接收符号池之前,恢 复出所有期望的符号。优选地,执行链式反应编码和解码处理的计算复杂度是较低的。所 期望的符号可以是对所有原始的源符号进行恢复所需要的所有符号,或者某种期望的完整 程度(其与所有原始源符号相比更低)。
[0041] 解码器处的恢复过程可以涉及:确定接收到哪些符号、生成用于将这些原始输入 符号映射到接收的那些经编码的符号的矩阵、随后对该矩阵进行求逆、执行该逆矩阵和接 收的经编码的符号的向量的矩阵相乘。在典型的系统中,这种过程的强力实施可能消耗过 多的计算工作和存储器要求。当然,对于特定的接收的经编码的符号集来说,可能不能恢复 出所有的原始输入符号,即使可以恢复,可能也需要非常大的计算量来计算出该结果。
[0042] 前向糾错("FEC")对象传输信息("0ΤΙ")或"FEC0TI"
[0043] 基于接收机接收的FEC 0ΤΙ (或者能够推断),该接收机可以确定文件传输的源 块和子块结构。在[Raptor-RFC-5053]和[RaptorQ-RFC-6330]中,FEC有效载荷ID是 (SBN,ESI),其中在[Raptor-RFC-5053]中,源块编号(SBN)是16比特,经编码的符号 ID (ESI)是16比特,而在[RaptorQ-RFC-6330]中,SBN是8比特,ESI是24比特,如本申请 的图1中所示出的。这种FEC有效载荷ID格式的一种缺点在于:必须预先确定用于向SBN 和向ESI分配的FEC有效载荷ID的比特的数量,有时很难确定足够用于所有文件传输参数 的适当混合。
[0044] 例如,当使用[Raptor-RFC-5053]时,仅具有216 = 65, 536个可用的ESI在一些情 形下可能是受限的,这是由于在一些情况下,可能存在具有8, 192个源符号的源块,因此, 经编码的符号的数量只是8个更大的一个因子,对于可以使用的可能编码速率进行限制, 以便在该情况下,被限于不下降到低于1/8。在该示例中,可以是有2 16 = 65, 536个可用的 源块,其可以是大于所使用的(例如,每一个具有1,024字节的8, 192个源符号),能够支持 的文件的大小是524GB,在很多应用中,与所需要的相比,其是幅度的两倍量级。
[0045] 再举一个例子,当使用[RaptorQ-RFC-6330]时,仅具有28 = 256个可用的SBN, 在一些情形下可能是受限的,这是由于对于4GB文件,如果将每一个源块限制于8MB(其可 以是这种情况:如果最大子块大小是256KB,最小子符号大小是32个字节,则符号大小是 1,024个字节),则将源块的数量限制于256,则将文件大小限制为2GB。在该示例中,其可 以是,与所使用的相比,可用的2 24 = 16, 777, 216个可能的经编码的符号更多,例如,具有 8, 192个源符号,可能的经编码的符号的数量更大2, 048倍,在一些应用中,不需要使用这 些经编码的符号。
[0046] 另一种期望的属性是提供用于在文件的不同部分之间,对编码的传输划分优先次 序的能力(其有时称为不等错误保护("UEP")。例如,可能期望的是,与剩余的90%相比, 对文件的前10%进行更强的防止分组丢失的保护。例如,[LDPC-Extensions]描述了如何 对[LDPC-RFC-5170]进行扩展,以便提供UEP的支持。在该情况下,对实际的FEC编码自身 进行修改,以便针对文件的不同部分,提供不同程度的奇偶校验。但是,该方法存在着一些 缺陷。例如,可能不期望必须对FEC编码自身进行修改来提供UEP,这是由于其使实现和测 试FEC编码自身变得复杂。此外,作为[LDPC-Extensions]的图6中所示的结果,就针对文 件的不同部分所提供的抵御丢包而言,该方法所获得的性能远远不是最佳的。
[0047] 用于提供UEP文件传输能力的一种方式(如[PET]和[PET-Patent]中所描述的), 是根据文件的不同部分的优先级和大小,为该文件的不同部分分配每一个分组的不同部 分。但是,关注的是如何以下面的方式对这些UEP方法进行综合:独立于文件的其它部分, 将文件的每一个不同部分划分到一些源块和子块,例如以便支持该文件的每一个部分的小 内存解码,同时在每一个分组中提供FEC有效载荷ID,这使接收机能确定在每一个分组中 包含该文件的每一个部分的什么符号。使用格式(SBN,ESI)的FEC有效载荷ID来支持这 种能力是非常困难的,至于文件的每一个部分,用于文件的第一部分的分组中的符号的相 应SBN和ESI,可以与用于该文件的第二部分的分组中的符号的SBN和ESI不相同。
[0048] 在一些情况下,需要专用的服务器,使用更通用、传统的硬件系统来实现、支持和 维持该专用服务器,以支持内容传送是更昂贵的。因此,期望具有实现起来不太复杂、用于 传送内容和修复符号的方法。


【发明内容】

[0049] 在文件传输方法和装置的实施例中,将内容提供给文件传输系统,使得表不该内 容的源块和符号能以单播方式可用,以广播或者多播方式来提供修复块和符号。可以提供 其它途径和冗余。可以通过一个实体来实现源块和符号的单播供应,在具有或者不具有第 一实体执行的特定处理的情况下,广播或多播部分由另一个实体来提供。
[0050] 在特定的实施例中,使一组内容(数据、图像、音频、视频等)可用于由很大数量的 用户进行操作或者使用的很大数量的终端用户设备("UE"),以便向这些用户呈现该内容, 通常在给定的用户异步地请求该内容之后不久,就开始向该用户进行呈现,并优选地继续 该呈现直到其结束为止(除非用户终止其)。在该实施例中,将内容以源形式存储在一个或 多个单播服务器,用于该内容的修复符号在广播服务器处生成和存储,并从其向多个UE进 行广播或多播。替代地,不进行存储,只要生成了修复符号,就对该内容进行广播。随后,UE 从广播服务器接收一些数量的修复符号,确定在该过程中是否有修复符号丢失,确定(至 少近似地)为了根据额外符号和所接收的修复符号来完全地恢复该内容,而所需要的多个 另外符号,随后从单播服务器请求该数量的符号。再举一个例子,从广播服务器广播或者多 播至少一些源符号,确定(至少近似地)为了完全地恢复该内容的一部分(该UE将要播放 的部分)所需要的多个另外符号,随后从单播服务器请求该数量的符号或者子符号(其可 以是修复子符号或者修复符号)。
[0051] 在一些情况下,针对单播服务器的请求具有HTTP字节范围请求的形式。当HTTP 字节范围请求指定文件的URL、该文件中的起始位置和该请求的长度(例如,请求的符号的 数量、或者请求的子符号的数量、或者与一组连续的子符号或符号相对应的字节范围请求) 时,可以对这些请求进行配置,使得这些请求中的全部或者大部分将该文件的初始位置用 作起始位置。这将允许下游高速缓存更频繁地履行请求,这是因为一旦其关于给定的文件, 对最大的请求进行了高速缓存,则其便具有要提供的所有必需数据(这是由于所有更小的 请求是该高速缓存的字节范围的一个子集)。
[0052] 在特定的实施例中,单播服务器是能够担任字节范围请求的简单、传统HTTP web 服务器。因此,可以在无需了解有任何特定的广播被执行的情况下,对这些单播服务器进行 设计。
[0053] 下面结合附图的详细描述将提供对于本发明的本质和优点的更好理解。

【专利附图】

【附图说明】
[0054] 图1是示出传统FEC有效载荷ID的图;图1A示出了针对Raptor-RFC5053的FEC 有效载荷ID,而图1B示出了针对RaptorQ-RFC-6330的FEC有效载荷ID。
[0055] 图2是示出用于基本通用文件传输("UFD")方法的FEC有效载荷ID的图。
[0056] 图3是示出发送方基本UFD方法的流程图。
[0057] 图4是示出接收方基本UFD方法的流程图。
[0058] 图5A-图5B是示出文件的符号的(SBN、ESI)标识,以及文件的符号的映射到和映 射自相对应的通用文件符号标识符("UFSI")的示例。
[0059] 图6是示出发送方通用文件传输、不等错误保护("UFD-UEP")方法。
[0060] 图7是示出接收方UFD-UEP方法的流程图。
[0061] 图8A-8B示出了包括两个部分的文件的(SBN、ESI)标识的示例,其中每一个部分 具有不同的优先级。
[0062] 图9示出了与图8A和图8B相对应的、在来自文件的两个部分的经编码的符号的 (SBN、ESI)标识符之间的映射的示例,这些分组包含针对这些部分的经编码的符号连同在 每一个分组中包括的UFSI。
[0063] 图10示出了使用[RaptorQ-RFC-6330]的简单UEP文件传输方法的性能。
[0064] 图11示出了简单UEP文件传输方法和UFD-UEP文件传输方法之间的示例性能比 较,其中这两种方法均使用[RaptorQ-RFC-6330]。
[0065] 图12不出了一个文件的文件传输、多个文件的文件传输和UFD绑定的文件传输方 法之间的示例性能比较,其中所有这些方法均使用[RaptorQ-RFC-6330]。
[0066] 图13是可以用于生成、发送和接收Raptor、RaptorQ或者作为文件传输的一部分 的其它分组的通信系统的框图。
[0067] 图14是一种可以进行文件传输的通信系统的视图,其中一个接收机从多个发送 方(其通常是独立的)接收输出符号。
[0068] 图15是一种可以进行文件传输的通信系统的视图,其中多个接收机(其可以是独 立的)从多个发送方(其通常是独立的)接收输出符号,以便与只使用一个接收机和/或 只使用一个发送方相比,以更少的时间来接收输入符号。
[0069] 图16描述了可以用于使用HTTP流媒体服务器来提供文件传输的块请求流媒体系 统的示例。
[0070] 图17示出了图16的块请求流媒体系统的单元,其示出了客户端系统的单元中的 更多细节,所述客户端系统耦合到块服务基础设施("BST")以接收由内容摄取系统所处理 的数据,如可以用于文件传输的。
[0071] 图18示出了可以用于准备进行文件传输的文件的摄取系统的硬件/软件实现。
[0072] 图19示出了客户端系统的硬件/软件实现,其中该客户端系统可以用于接收向该 客户端系统传送的文件。
[0073] 图20示出了一种通用FEC 0ΤΙ元素格式的示例。
[0074] 图21示出了一种特定于方案的FEC 0ΤΙ元素格式的示例。
[0075] 图22示出了基本FLUTE文件传输。
[0076] 图23示出了基本FLUTE分组格式。
[0077] 图24示出了在使用子块的发送方处发生的子块编码。
[0078] 图25示出了在使用子块的接收机处发生的子块解码。
[0079] 图26示出了使用子块的文件传输。
[0080] 图27示出了多个源块的处理。
[0081] 图28示出了使用FEC和FLUTE的工作流。
[0082] 图29示出了广播/修复、单播/源配置。
[0083] 图30示出了系统如何在MBMS承载上只广播修复符号。
[0084] 图31示出了通过HTTP字节范围请求,使用单播修复。
[0085] 图32示出了用于第一源块的子块范围请求计算的示例。
[0086] 图33示出了用于第二源块的子块范围请求计算的示例。
[0087] 图34示出了原始顺序HTTP文件格式和分区结构的示例。
[0088] 图35示出了具有U0SI顺序的源符号的示例。
[0089] 图36示出了具有U0SI顺序的修复符号的示例。
[0090] 图37示出了扩展原始顺序HTTP文件格式的示例。
[0091] 图38示出了扩展原始顺序HTTP文件格式的另一个示例。
[0092] 图39示出了用于不具有子块的原始顺序HTTP文件格式的字节范围计算的示例。
[0093] 图40示出了用于不具有子块的扩展原始顺序HTTP文件格式的字节范围计算的示 例。
[0094] 图41示出了用于具有子块的扩展原始顺序HTTP文件格式的字节范围计算的示 例。

【具体实施方式】
[0095] 在本申请的实施例中,文件传输通过用于发送文件的编码器/发射机系统和用于 接收文件的接收机/解码器系统来执行。对进行的传输的格式进行协调,使得解码器理解 编码器怎样进行了编码。如下面的各个示例中所示,除非另外指出,否则文件传输是通用对 象传输的一个示例,通过这些示例,显而易见的是,可以将对象处理成文件,反之亦然。
[0096] 在分组传送系统中,将数据组织成一些分组,并发送成分组。每一个分组具有允许 接收机确定该分组中有什么内容,以及其如何布局的元素。使用本申请所描述的技术,提供 了用于当使用前向纠错("FEC")时,发送分组的灵活性。
[0097] 使用这些技术,可以提供不等FEC保护,以及文件的绑定传输。公知的是,与将多 个文件连接在一起形成更大的文件,并在传输时保护该更大的文件相比,当将多个文件传 送成单独的文件时,传输时发生分组丢失的弹性更小。但是,需要作为较小文件的组合的该 大型文件的结构的信令,接收机通常需要恢复整个大文件,来恢复该大文件中的较小文件 里的任何一个,即使接收机只是对恢复这些较小文件的一个子集感兴趣。
[0098] 因此,优选的文件传输系统或者方法应当允许多个源块和每一个源块的多个经编 码的符号的任意灵活组合,该组合用作一个文件的文件传输结构。在典型的实现中,一个源 块是FEC操作(例如,生成修复符号)的范围。例如,可以根据全部来自一个源块的一个或 多个源符号,来生成修复符号。在这些情况下,每一个源块是可以独立解码的。这在解码 器处是有用的(如果在接收到所有数据之前,需要对被传输的一些数据进行解码和处理的 话)。通过本发明公开内容,应当显而易见的是,如果源块非常的小,则接收的修复符号将可 用于恢复较小数量的源符号,但是,其源块非常大,这使接收机解码和/或处理和/或使用 该源块中的任何源符号都要花费更多的时间,这是因为其要花更长的时间对更大的源块进 行解码。
[0099] 文件传输方法应当提供防止分组丢失的高效保护,在按照不同的优先级来保护文 件的不同部分的情况下,支持文件的传输,其中文件的每一个部分可以与该文件的其它部 分具有不同的源块结构和子块结构。同样,在一些情况下,将文件视作为对象的特定示例, 但在本申请,应当理解的是,本申请使用的用于描述文件的传输和处理的示例,还可以用于 或许没有称为文件的数据对象,例如,来自于数据库的大量的数据、视频序列的一部分等。
[0100] 文件/对象传输系统或方法应当在下面能力的基础上,提供多个小型文件/对象 的传输:大型文件/对象的保护高效、小型文件/对象结构的简单信令、以及接收机在无需 恢复所有这些小型文件/对象的基础上,独立地恢复这些小型文件/对象的一个子集的能 力。
[0101] 文件传输系统可以包括广播部分和单播部分。为了易读性起见,"广播"可以是意 味着"广播、多播和/或用于向多个用户服务共同数据的其它机制"。"单播"指代数据从一 个源移动到一个目的地,但一个逻辑源可以包括多个组成部分,一个逻辑目的地可以包括 多个组成部分。在单播配置中,通常存在一个源服务器和一个目的地客户端,其中源服务器 等待来自客户端的请求,通过专门向请求的客户端发送所请求的数据(如果准许的话),对 接收的请求进行响应。如本领域所公知的,针对大量目的地的单播传输,与针对这些相同数 量的目的地的广播传输相比,可能产生更多的可扩展性挑战。通常,对于HTTP传输来说,贯 穿整个网络部署多个高速缓存的服务器,以增加服务器传输伸缩能力。但是,这种方法并不 必然地增加网络容量,网络容量是用于向移动设备传送内容的通常瓶颈。
[0102] 现在描述具有这些期望的质量的系统的示例。
[0103] 某本通用f件传输("UFD")方法和系统
[0104] 现在描述基本通用文件传输("UFD")方法和相应的系统,其中UFD与现有的文 件传输方法相比,具有显著的优点。用于基本UFD方法的前向纠错("FEC")有效载荷ID 包括通用文件符号标识符("UFSI")字段,例如,其可以是32比特字段。现在描述用于 基本UFD方法的发送方和接收方方法。同样,当文件称为对象时,"UFSI"可以替代地称为 "U0SI "(通用对象符号标识符)。
[0105] 图1是示出传统FEC有效载荷ID的图;图1A示出了用于Raptor-RFC5053的FEC 有效载荷ID,而图1B示出了用于RaptorQ-RFC-6330的FEC有效载荷ID。
[0106] 图2是示出用于基本通用文件传输("UFD")方法的FEC有效载荷ID的图。后一 种方法可以是更灵活的。
[0107] 图3示出了发送方基本UFD方法。发送方可以使用现有的方法来生成FEC对象传 输信息("0ΤΙ"),例如,如[Raptor-RFC-5053]或者[RaptorQ-RFC-6330]中所描述的(例 如,参见[RaptorQ-RFC-6330]的第4. 3节),使用该FEC 0ΤΙ来确定发送该文件时将使用 的源块和子块结构,确定(SBN、ESI)对和该文件的经编码的符号之间的关系(例如,参见 [RaptorQ-RFC-6330]的第 4. 4 节)。
[0108] 例如,如[RaptorQ-RFC-6330]中所描述的,所生成的FEC 0ΤΙ可以是 (F,Al,Τ,Ζ,Ν),其中F是要发送的文件的大小,Α1是用于确保子符号在存储边界对齐的对 齐因子,其中存储边界是Α1的倍数,Τ是生成的并在该传输中发送的符号的大小,Ζ是为了 对该文件进行传输而划分成的源块的数量,Ν是为了传输而将每一个源块所划分成的子源 块的数量。如图3的步骤300中所示出的。
[0109] 发送方可以用分组来形成要发送的经编码的符号,基于源块,使用现有的方法来 生成用于这些经编码的符号的SBN和ESI,如果使用子块划分的话,则还使用子块结构,例 如,如[RaptorQ-RFC-6330]中所描述的。在发送经编码的符号的每一次,发送方都确定针 对该经编码的符号要生成的SBN A和ESI B,如图3的步骤310中所示,随后发送方可以使用 现有的技术(例如,[RaptorQ-RFC-6330]中所描述的那些技术),基于(SBN, ESI) = (A,B) 来生成该经编码的符号的值,如图3的步骤320中所示。随后,将用于该经编码的符号的 UFSI C计算成C = B*Z+A,如图3的步骤330中所示。
[0110] 发送方可以在分组中发送该经编码的符号,其中该分组的FEC有效载荷ID被设置 为该经编码的符号的UFSI C,如图3的步骤340中所示。随后,发送方可以确定是否有更多 的经编码的符号要发送,如图3的步骤350中所示,如果是的话,则发送方可以生成另外的 经编码的符号来发送,如去往图3的步骤310的"是"分支所示出的,如果没有,则发送方可 以完成操作,如去往图3的步骤360的"否"分支所示出的。
[0111] 存在发送方基本UFD方法的多种变型。例如,发送方可以在至少一些分组中,发送 一个以上的经编码的符号,在该情况下,可以将FEC有效载荷ID设置为该分组中所包含的 第一经编码的符号的UFSI,可以对该分组中所包含的其它符号进行选择,使得其相应UFSI 值是连续的。例如,如果在该分组中携带有三个经编码的符号,第一个这种符号具有UFSI =4, 234,那么其它两个经编码的符号可以是分别具有UFSI4, 235和4, 236。举一些其它替 代的示例,发送方可以预先确定要生成多少经编码的符号,在生成这些经编码的符号中的 任何一个之前,确定用于要生成的所有经编码的符号的(SBN,ESI)值。再举一个例子,可以 在无需生成(SBN,ESI)值的中间步骤的情况下,直接生成UFSI值。
[0112] 再举一种变型的示例,可以生成其它形式的FEC 0ΤΙ。例如,可以将基UFSI BU包 括在用于该文件的FEC 0ΤΙ中,其可以如下所述地使用:FEC发送方和接收机针对于一个分 组中所包含的经编码的符号而使用的UFSI是U+BU,其中U是在携带该经编码的符号的分组 中所携带的UFSI。因此,例如,如果一个分组携带U = 1,045,在FEC 0ΤΙ中的基UFSI是BU =2, 000, 000,那么该经编码的符号是2, 001,045。基UFSI的使用具有一些优点。第一,在 [FLUTE]、[ALC]、[LCT]、[FEC BB]中描述的协议簇将传输对象标识符(其还称为Τ0Ι)与要 传输的文件或对象的FEC ΟΤΙ进行关联。可以在不同的时间,或者在不同的会话中,发送同 一文件的经编码的符号,这些经编码的符号可以与不同的Τ0Ι相关联。此外,有利的是,针 对与每一个不同的Τ0Ι相关联的分组,能够发送以UFSI = 0起始的编码分组。通过具有将 基UFSI指定成FEC ΟΤΙ的一部分的能力,不同的基UFSI可以与针对该文件将发送的经编 码的符号的每一个Τ0Ι相关联,而无需针对不同的Τ0Ι,发送重复的经编码的符号。例如, 可以在与Τ0Ι = 1相关联的分组和与Τ0Ι = 2相关联的分组中,发送同一文件的经编码的 符号,其中与Τ0Ι = 1相关联的基UFSI被设置为0,与Τ0Ι = 2相关联的基UFSI被设置为 1,000,000。随后,T0I = 1和T0I = 2的编码分组,可以包含UFSI0、1、2等的序列,只要针 对具有T0I = 1的文件,发送少于1,000, 000个经编码的符号,那么在与这两个T0I相关联 的发送的经编码的符号之中,不存在重复的经编码的符号。
[0113] 参照图4,描述了接收机基本UFD方法。接收机可以使用现有的技术,来确定具有 与上面针对发送方所描述的相同格式的FEC0TI(F,A1,T,Z,N),如图4的步骤 400 中所示。 例如,可以将FEC 0ΤΙ嵌入在FLUTE会话描述中,或者可以将FEC 0ΤΙ编码到URL中,或者可 以通过SDP消息来获得FEC 0ΤΙ。在步骤410中,接收机查看是否接收到更多的经编码的符 号,其可以停留在该步骤,直到满足下面条件为止:接收机接收到另一个经编码的符号(在 该情况下,接收机转到步骤430),或者接收机确定将会接收到更多的经编码的符号,在该情 况下,接收机转到步骤420,并尝试使用其它方式来恢复该文件,例如使用针对文件修复服 务器的HTTP请求,或者接收机可以等待另一个会话,以便在稍后时间接收更多的经编码的 符号,或者接收机可以确定该文件不能被恢复。
[0114] 当另一个经编码的符号可用时,在步骤430,接收机确定该经编码的符号的UFSI C,接收该经编码的符号的值。在步骤440,接收机基于源块的数量Z和UFSI C,计算A = C 模Z,以及B = floor (C/Z),在步骤450,接收机将用于该经编码的符号的(SBN,ESI)设置为 (A,B),在步骤460,接收机存储该经编码的符号的值和(A,B),以便用于文件恢复。在步骤 470,接收机确定是否接收到足够的经编码的符号来恢复该文件,如果是,则转到步骤480 来恢复该文件,否则的话,转到步骤410来接收更多的经编码的符号。
[0115] 存在接收机基本UFD方法的多种变型。例如,接收机可以在至少一些分组中,接收 一个以上的经编码的符号,在该情况下,可以将FEC有效载荷ID设置为该分组中所包含的 第一经编码的符号的UFSI,该分组中的其它符号可以具有连续的相应UFSI值。例如,如果 在该分组中携带有三个经编码的符号,第一个这种符号具有UFSI = 4, 234,那么其它两个 经编码的符号可以是分别具有UFSI4, 235和4, 236,在该分组中携带的UFSI可以是第一经 编码的符号的UFSI = 4, 234。举一些其它替代的示例,接收机可以在尝试恢复之前,预先 确定要接收多少经编码的符号。再举一个例子,接收机可以做一些特定于FEC编码的处理, 其用于确定是否接收到足够的经编码的符号来恢复该文件。再举一个例子,在恢复过程中, 可以在无需生成(SBN,ESI)值的中间步骤的情况下,直接地使用UFSI值。再举一个例子, 文件的恢复可以与经编码的符号的接收同时地发生。再举一个例子,可以使用其它形式的 FEC 0ΤΙ 信息。
[0116] 将基本UFD方法与在[RaptorQ-RFC-6330]中描述的技术进行组合,以确定源块和 子块结构提供很多种利益。例如,先前的方法所称的源符号(为了发送文件,其通过SBN和 ESI的组合来进行标识),可以被视作为通过UFSI来标识的文件符号(当使用基本UFD方 法时)。使F表示要发送的文件的以字节计算的大小,使T表示在发送该文件时,用于FEC 编码/解码目的的符号大小,因此KT = ceil (F/T)是该文件中的符号的总数,其中ceil (X) 是大于或等于X的最小整数。
[0117] 当确定源块结构和子块结构时(例如,如在[RaptorQ-RFC-6330]中所描述的),使 用上面所描述的基本UFD方法,将符号的标识从(SBN,ESI)格式转换成UFSI格式和从UFSI 格式转换成(SBN,ESI)格式,用于文件符号的UFSI的范围是0, 1,2,…,KT-1,根据该文件 生成的任何修复符号将具有范围KT,KT+1,KT+2等中的UFSI。这种属性允许通过简单地将 一个符号的UFSI与KT的值进行比较,来确定该符号是原始文件的一部分,还是根据该文件 所生成的修复符号。例如,这可以用于使不支持FEC解码的接收机,能够基于在分组中携带 的UFSI值,以及基于用于该文件的KT的值,来确定哪些符号是原始文件的一部分(以及其 在该文件中的位置),哪些符号可以忽略成修复符号。
[0118] 图5A和图5B示出了一种示例,在该情况下,文件大小是F = 28, 669个字节,符号 大小是T = 1,024个字节,因此KT = ceil(F/T) = 28。在这两个附图中,源块的数量是Z =5。在图5A和图5B中,在顶部和/或旁边,示出了文件的符号的(SBN,ESI)标签,其中每 一行对应于一个源块,每一列对应于具有相同ESI值的符号。在底部示出了这些符号的相 应UFSI标签。在该情况下,UFSI = 27的符号(S卩,关于UFSI标签的第28个符号)具有 为了 FEC编码和解码的目的,而以零填充的其最后(KT*T)-F = 3个字节,但是不发送该符 号的这最后三个填充的字节。在该示例中,具有UFSI28或者更大值的任何经编码的符号是 修复符号,其中具有UFSI28的经编码的符号是根据SBN = 3的源块来生成的,具有UFSI29 的经编码的符号是根据SBN = 4的源块来生成的,具有UFSI30的经编码的符号是根据SBN =〇的源块来生成的等。这种属性具有多种其它的优点,如本领域普通技术人员所认识到 的。
[0119] 基于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个经编码的符 号等。应当理解的是,贯穿本说明书,除非另外指出,否则"随机"可以包括伪随机。
[0120] 相比于先前已知的方法,使用基本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,经编码的符号的数量可以是该文件大小的两倍。在所有情况下,针对该文件所生成的 经编码的符号的数量,都独立于该文件的子块结构(如果使用子块结构的话)。
[0121] 用于不等错误保护f件传输服备的通用f件传输方法
[0122] 大部分的先前文件传输方法都不支持不等错误保护("UEP")文件传输。存在着 一些通过改变实际的FEC编码(其中该实际FEC编码用于对文件的不同部分进行编码), 来支持UEP的现有方法,例如,当前在ISDB-Tmm(陆地移动多媒体)标准中所指定的那些方 法、使用[LDPC-Extensions]中所示出的方法。除了在使用UEP时,必须改变实际的FEC编 码的缺点之外,另外的缺点在于:这些方法所提供的保护与理想差距很大。
[0123] 举例而言,考虑在[LDPC-Extensions]的图6中示出其结果的示例。在该示例中, 将以分组来发送的大小为1,〇〇〇ΚΒ的文件具有两个部分,每一个分组包含1KB符号:该文 件的第一部分具有30KB的大小,通过100个奇偶校验、或者修复分组来保护,该文件的第二 部分具有970KB的大小,针对该文件发送了总共1,000个源分组和1,000个奇偶校验分组。 所提供的保护由于两种原因而与理想差距很大。一种原因在于:基于[LDPC-RFC-5170],使 用的FEC编码通常需要显著的接收开销来恢复源块,S卩,与一个文件中存在的源分组相比, 需要接收更多的分组来恢复该文件。第二种问题在于:该方法本质上使用与用于发送和保 护该文件的第二部分不相同的分组集,来发送和保护该文件的第一部分。对于第二种问题 来说,在接收针对该文件的第一部分所发送的130个分组之外的30个分组时的方差可能很 大,这是由于该文件的第一部分是通过这种较少数量的分组来发送的。
[0124] 可以通过一种扩展来改进在[LDPC-Extensions]中所描述的UEP文件传输方法, 本申请称为"简单UEP"文件传输方法。该简单UEP文件传输方法使用用于文件传输的现 有技术,并且基于优先级,针对该文件的每一个部分,使用不同数量的保护,将该文件的各 部分作为单独文件来传送,随后可以发送该文件的各部分之间的逻辑连接,使得接收机知 道所传送的文件是同一文件的一部分。例如,该简单UEP文件传输方法可以使用上面的示 例中的[RaptorQ-RFC-6330],通过发送总共130个分组来传送该文件的前30KB部分,其每 一个分组包含根据该第一部分所生成的大小为1,024个字节的经编码的符号,随后可以通 过发送总共1870个分组,将该文件的第二部分970KB传送成单独的文件,其每一个分组包 含根据该第二部分所生成的大小为1,024个字节的经编码的符号。因此,针对发送成单独 文件的该文件的两个部分,发送了总共2, 000个分组。该简单UEP文件传输方法是相对于 [LDPC-Extensions]中描述的方法的改进,这是由于不对FEC编码自身进行修改,并且由于 与[LDPC-Extensions]的图6中所示出的相比,在不同的分组丢失状况下来传输该文件的 两个部分的性能更出众,如本申请的图10中所示出的。
[0125] 这种差别的一种可能来源是由于:在[RaptorQ-RFC-6330]中所详细说明的FEC编 码,相比在[LDPC-RFC-5170]中所详细说明的FEC编码具有更优的恢复属性。但是,这种简 单UEP文件传输方法仍然承受上面所描述的第二种问题。
[0126] [PET]和[PET-Patent]提供了用于提供UEP文件传输服务的潜在改进方法,其中 每一个分组包含:基于该文件的每一个部分的优先级,来自于该部分的指定数量的经编码 的数据。[PET]的直接合并将会在每一个分组中包括针对该文件的每一个部分的适当大 小的经编码的符号,随后包括单独的FEC有效载荷ID,其包括针对该文件的每一个部分的 (SBN,ESI)对。但是,该方法由于几种原因而不具有优势。
[0127] 例如,当使用FEC有效载荷ID (其包括针对每一个部分的预定大小的SBN和ESI 字段)时,针对该文件的每一个部分的每一个源块,存在单独的预定数量的可能源块或者 多个可能的经编码的符号。例如,针对d个部分的每一个部分具有8比特的SBN和24比特 的ESI,导致(32*d)比特的FEC有效载荷ID,其将每一部分的可能的源块数量限制于256, 将每一个源块的可能的经编码的符号的数量限制于16, 777, 216。此外,如果针对d个部分 的每一个部分,FEC有效载荷ID大小是32比特,那么这意味着在每一个分组中,针对所有 部分具有总共32*d比特的FEC有效载荷ID,例如,如果d = 10,那么仅对于每一个分组中 的FEC有效载荷ID报头来说,这将是320比特,或者等同地40个字节。
[0128] 可以将用于文件传输的基本UFD方法进行扩展,以便提供不等错误保护(UEP)文 件传输服务,如下面所详细描述的,其相对于先前的UEP文件传输方法,提供显著的优点。 这里,这些扩展的方法称为"UFD-UEP"文件传输方法。这些UFD-UEP文件传输方法可以使 用在[PET]和[PET-Patent]中所描述的方法里的一些。
[0129] 现在更详细地描述一种示例性的UFD-UEP文件传输方法。在该方法中,发送方将 大小为F的文件划分成大小为匕,Fi,…,Fh的d>l个部分,因此F等于关于i的Fi之和。 发送方将分组大小T划分成大小为I,?\,…,的d个部分,因此T等于关于i的凡之 和。这种T的划分是基于匕,Fi,…,Fh和相应的文件部分的优先级。比率Fi/Ti确定为了 恢复该文件的第i部分,需要接收多少个分组(其假定使用理想的FEC编码将该文件的第 i部分保护成一个源块),因此比率匕/1\越小,则文件的第i部分的优先级越高。在实现 时,可能需要比匕/%稍微更多的分组,来恢复该文件的第i部分,例如,由于FEC编码是不 完美的,并呈现某种接收开销,或者由于该文件的该部分被划分成多个源块,用于一些源块 的经编码的符号按照与其它源块相比更高的比率丢失,或者由于不是整数。举一个 UEP 的例子,假定 F = 1MB, T = 1,024octets, d = 2, FQ = 32KB, Fi = F-F。= 992KB, and T0 =64octets, ?\ = T-TQ = 960个字节。在该示例中,FQ/TQ = 512,因此512个分组的理想 接收允许该文件的第〇部分的恢复,而匕/1\ = 1,058. 13,因此1,059个分组的理想接收允 许该文件的第1部分的恢复。因此,在该示例中,可以根据恢复该文件的第1部分所需要的 多个分组的大约一半,来恢复该文件的第〇部分。
[0130] 应当注意,在该示例中,如果不使用UEP(即,d = 1,因此FQ = F = 1MB,TQ = T = 1,024个字节),那么需要匕/%= 1,024个分组来恢复该文件。因此,在前面的段落中所描 述的UEP示例中,与不使用UEP时相比,文件的第1部分的恢复需要稍微更多的分组,这是 由于该文件的第〇部分的优先级更高。可以在中找到这种基础平衡的分析研究。
[0131] 存在着发送方UFD-UEP方法基于匕,Fi,…,Fh和不同的文件部分的优先级,来生 成T的划分H,…,的多种方式。应当注意,如果选择Ti,使得F/Ti ?F/T,那么认为 该文件的第i部分具有平均优先级,分别根据是F/I^F/T,还是Fi/TAF/T,第i部分的优先 级可以是相对更高或者更低。
[0132] 现在参照图6来描述用于生成FEC 0ΤΙ的发送方UFD-UEP方法。给定cUFpFi、…、 IVi、Τ。、?\、…、L、Al、WS的值,可以独立于使用现有的方法,例如使用在第4. 3中的
[RaptorQ-RFC-6330]里描述的方法,将FEC ΟΤΙ计算成应用于该文件的d个部分中的每一 个的,也就是,对于每一个i = 〇,…,d-Ι,发送方可以生成用于文件第i部分的FEC 0TI,其 确定如何使用在第4. 3中的[RaptorQ-RFC-6330]里描述的方法,将其划分成源块和子块, 将匕处理成文件大小,将?\处理成用于在每一个分组中携带针对第i部分的信息的符号大 小。因此,独立于文件的其它部分,发送方来生成针对该文件的第i部分的FEC ΟΤΙ。在本 申请的图6的步骤600中,示出了该过程。
[0133] 此外,发送方还可以生成该文件的第i部分向源块和子块的划分,以及针对该文 件的第i部分的经编码的符号的(SBN,ESI)之间的映射,如何使用现有的方法(例如,在第 4. 4节和第5节中的[RaptorQ-RFC-6330]里描述的方法)来根据该文件的第i部分来生 成经编码的符号。独立于该文件的其它部分,将这些UFD-UEP方法应用于该文件的第i部 分,因此该文件的不同部分可以具有不同的源块和子块结构,具体而言,每一个源块可以存 在不同数量的源符号,在该文件的不同部分之间存在不同数量的源块,这是由于将这些方 法独立地应用于该文件的每一个部分。
[0134] 优选地,对齐因子A1对于文件的所有部分来说是相同的,具体而言,优选的是,对 于每一个部分i,Ti的值是A1的倍数。此外,例如,若使用在[RaptorQ-RFC-6330]的第4. 5 节中描述的方法,来导出FEC 0ΤΙ,则优选的是,当导出针对该文件的每一个部分的源块和 子块结构时,使用相同的A1和WS的值。针对A1使用相同的值,确保在接收机处,在按照 A1的倍数字节对齐的存储器上进行解码,针对WS使用相同的值,确保在接收机处需要在随 机存取存储器(RAM)中进行解码的最大块大小,对于该文件的所有部分来说是相同的。但 是,这里不需要本申请所描述的方法,即,如果将不同的A1值用于不同的文件,则这些方法 在无需修改的情况下进行应用,如下面所进一步描述的。存在着一些应用,在这些应用中, 针对文件的不同部分使用不同的WS值,对于导出FEC 0ΤΙ来说是优选的,例如,如果期望使 用更少的存储器来恢复该文件的更高优先级部分。
[0135] 存在一些应用,在这些应用中,针对不同的部分使用不同的对齐因子是有利的。例 如,具有4字节对齐的存储器的低端接收机和具有8字节对齐的存储器的高端接收机,可以 对高优先级部分进行解码,而低优先级部分只能由高端接收机进行解码。在该示例中,有利 的是,针对高优先级部分使用Α1 = 4,使得低端接收机可以对这些部分进行高效地解码,有 利的是,针对低优先级部分使用Α1 = 8,使得与具有Α1 = 4的部分相比,高端接收机可以对 于对具有Α1 = 8的这些部分进行更高效地解码。
[0136] 特定于文件第i部分的发送方UFD-UEP方法所生成的相应FEC 0ΤΙ,包括FpTpZi、 Ni,其中Zi是将该文件的第i部分所划分到的源块的数量,Ni是将该文件的第i部分的每 一个源块所划分到的子块的数量。因此,整体上,发送方UFD-UEP方法针对该文件所生成的 FEC 0ΤΙ 可以包括:(d,Al,F。,T。,Z。,N。,Fi,1\,Zi,&,…,Fh,Th,Zh,U。其它版本的 FEC ΟΤΙ也是可用的,例如,当d是固定的,并因此不需要在FEC ΟΤΙ中显式地列出时,或者当使 用其它方法来指示源块结构和子块结构时(如果使用的话)。
[0137] 使用UFD-UEP方法的发送方,将针对该文件的每一个部分的一个经编码的符号进 行组合,以便在一个分组中进行发送,用于该分组的FEC有效载荷ID包括UFSI值C。当要 发送一个分组时,发送方确定将用作用于该分组的FEC有效载荷ID的UFSI值C,如图6的 步骤610中所示出的。例如,将使用的UFSI值可以是连续的,例如,UFSI值0、1、2、3、…、 等。对于给定的UFSI值C,在针对文件的第i部分的分组中,将放置在分组的第i部分中 的大小为凡的经编码的符号,具有SBN Ai和ESI Bp其计算成Ai = C模Zp Bi = fl〇〇r(C/ ZJ,如图6的步骤620中所示出的。对于,针对分组的d个部分中的每一个,生成这些d个 经编码的符号,随后将UFSI C与聚合大小为T的这些d个经编码的符号一起在分组中进行 发送,如图6的步骤630、640和650中所示出的。发送方UFD-UEP方法继续生成和发送编 码分组,如在图6的步骤660中进行的确定所示出的。
[0138] 参照图7,来描述接收机UFD-UEP方法。接收机可以使用现有的技术,来确定 具有与上面关于发送方所描述的相同格式的FEC 0ΤΙ (d,A1,匕,?;,&,%,Fp ?\,Ζρ &,… ,IVp ?^,Z^,U,如图7的步骤700中所示出的。例如,可以将FEC ΟΤΙ嵌入在FLUTE会 话描述中,或者可以将FEC ΟΤΙ嵌入到URL中,或者可以通过SDP消息来获得FEC ΟΤΙ。在步 骤710中,接收机查看是否接收到更多的分组,其可以停留在该步骤,直到满足下面条件为 止:接收机接收到另一个分组(在该情况下,接收机转到步骤730),或者接收机确定将不会 接收到更多的分组,在该情况下,接收机转到步骤720,并确定是否恢复了该文件的足够部 分并进行停止,或者尝试使用其它方式来恢复该文件的其它部分,例如使用针对文件修复 服务器的HTTP请求,或者接收机可以等待另一个会话,以便在稍后时间接收更多的分组。
[0139] 当另一个分组可用时,在步骤730,接收机确定所接收的分组的UFSI C,对于每一 个i = 0、…、d-Ι,从针对每一个i = 0、…、d-Ι的分组中提取大小为?\的经编码的符 号。在步骤740,对于每一个i = 0、…、d-Ι,接收机基于源块的数量21和耶51 C,计算Ai =C模Zy以及& = flooHC/Zi),在步骤750,接收机将用于第i部分的经编码的符号的 (SBN,ESI)设置为(ApBi),在步骤760,接收机存储用于第i部分的经编码的符号的值和 %,,以便用于该文件的第i部分的恢复。在步骤770,针对每一个i = 0、"·、(1-1,接收 机确定是否接收到足够的经编码的符号来恢复该文件的第i部分,如果是,则转到步骤780 来恢复该文件的第i部分,否则的话,转到步骤710来接收更多的分组。
[0140] 存在接收机UFD-UEP方法的多种变型。例如,发送方可以在至少一些分组中,发送 针对文件的每一个部分的一个以上的经编码的符号,接收机可以在至少一些分组中,接收 针对文件的每一个部分的一个以上的经编码的符号,在该情况下,可以将FEC有效载荷ID 设置为与该分组中所包含的针对每一个部分的第一经编码的符号相对应的UFSI,针对该分 组中的每一个部分的其它符号可以具有连续的相应UFSI值。例如,如果在该分组中携带 有针对该文件的每一个部分的三个经编码的符号,针对每一个部分的第一符号与UFSI = 4, 234相对应,那么针对每一个部分的其它两个经编码的符号可以是分别与UFSI4, 235和 4, 236相对应,在该分组中携带的UFSI可以是UFSI = 4, 234。
[0141] 举一些其它替代的示例,接收机可以在尝试恢复之前,预先确定要接收多少经编 码的符号,或者可以计算在该会话期间的分组丢失统计,并基于此来决定将尝试恢复该文 件的哪个部分。再举一个例子,接收机可以做一些特定于FEC编码的处理,其用于确定是否 接收到足够的经编码的符号来恢复该文件的各个部分。再举一个例子,在针对各个文件部 分的恢复过程中,可以在无需生成(SBN,ESI)值的中间步骤的情况下,直接地使用UFSI值。 再举一个例子,文件的一部分的恢复可以与经编码的符号的接收同时地发生。
[0142] 再举一个例子,可以使用其它形式的FEC 0ΤΙ信息。例如,可以独立于其它部分, 将基UFSI 指定在用于第i部分的FEC 0ΤΙ中,其可以如下所述地使用:FEC发送方和 接收机针对于一个分组中所包含的第i部分的经编码的符号而使用的UFSI是υ+ΒΑ,其中 U是在携带该经编码的符号的分组中所携带的UFSI。因此,例如,如果一个分组携带U = l,045,在针对第i部分的FEC0TI中的基UFSI是BUi = 2,000,000,那么该经编码的符号 是 2, 001,045。
[0143] 基UFSI的使用具有一些优点。例如,在针对于不同的部分,仅发送一个修复符号 的情况下(由于稍后描述的原因),设置ΒΑ = Κ?\是有利的,其中Κ?\是第i部分中的文件 符号的数量。在该情况下,在发送的分组序列中的UFSI序列可以是0、1、2、3等,而不管对 于每一个部分来说,在分组中只发送根据该部分所生成的修复符号。
[0144] 本段描述基UFSI的使用的另一种示例性优点。在[FLUTE]、[ALC]、[LCT]、[FEC BB]中描述的协议簇将传输对象标识符(其还称为Τ0Ι)与要传输的文件或对象的FEC ΟΤΙ 进行关联。可以在不同的时间,或者在不同的会话中,发送针对相同部分的经编码的符号, 这些经编码的符号可以与不同的Τ0Ι相关联。此外,有利的是,针对与每一个不同的Τ0Ι相 关联的分组,能够发送以UFSI = 0起始的编码分组。通过具有针对每一个部分,能够独立 地将基UFSI指定成FEC 0ΤΙ的一部分的能力,针对各个部分的不同的基UFSI可以与针对 该文件将发送的经编码的符号的每一个Τ0Ι相关联,而无需针对不同的Τ0Ι,发送重复的经 编码的符号。例如,可以在与Τ0Ι = 1相关联的分组和与Τ0Ι = 2相关联的分组中,发送针 对相同部分的经编码的符号,其中与Τ0Ι = 1相关联的针对该部分的基UFSI被设置为0, 与Τ0Ι = 2相关联的针对相同部分的基UFSI被设置为1,000, 000。随后,Τ0Ι = 1和Τ0Ι =2的编码分组,可以包含UFSI0、1、2等的序列,只要针对具有Τ0Ι = 1的该部分,发送少 于1,000, 000个经编码的符号,那么在与这两个Τ0Ι相关联的发送的经编码的符号之中,不 存在该部分的重复的经编码的符号。此外,还有利的是,具有将被FEC 0ΤΙ中的所有部分都 使用的基UFSI,而不是针对每一个部分,指定不同的基UFSI,这是由于这可以减少传输FEC 0ΤΙ所需要的字节数量,同时共享针对该FEC 0ΤΙ中的每一个部分,指定单独的基UFSI的多 种优点,特别是当结合该方法使用的FEC编码是信息增加的FEC编码(例如,在Luby I中所 描述的FEC编码)时,这是由于在该情况下,针对所有部分的UFSI的有效范围可以是非常 的大。
[0145] 将基本UFD-UEP方法与在[RaptorQ-RFC-6330]中描述的技术进行组合,以确定 源块和子块结构提供很多种利益。具体而言,基本UFD方法的所有优点,在UFD-UEP方法 中仍然持有。例如,先前的方法所称的源符号(为了发送文件的UEP部分中的一个,其通 过SBN和ESI的组合来进行标识),可以被视作为通过UFSI来标识的文件符号(当使用 UFD-UEP方法时)。应当注意,KT = ceil (F/T)是该文件的第i部分中的文件符号的总数。 当针对文件的每一个部分,确定源块结构和子块结构时(例如,如在[RaptorQ-RFC-6330] 中所描述的),使用上面所描述的UFD-UEP方法,将针对于文件的一个部分的符号的标 识从(SBN,ESI)格式转换成UFSI格式和从UFSI格式转换成(SBN,ESI)格式,用于文 件符号的UFSI的范围是0, 1,2, ·'KTi-l,根据该文件生成的任何修复符号将具有范围 Κ?\,KTi+Ι,Κ?\+2等中的UFSI。这种属性允许通过简单地将符号的UFSI与Κ?\的值进行比 较,来确定该符号是文件的原始第i部分的一部分,还是根据该文件的第i部分所生成的修 复符号。例如,这可以用于使不支持FEC解码的接收机,能够基于在分组中携带的UFSI值, 以及基于用于该文件的每一个部分i的?\和Κ?\的值,来确定分组的哪些部分包含原始文 件的部分(以及其在该文件中的位置),分组的哪些部分包含可以忽略的修复符号。
[0146] 图8A和图8B示出了一种示例,在该情况下,该文件包括两个部分。第一部分被划 分成5个源块,其中这些源块中的前3个的每一个都具有6个源符号,剩余的2个源块中的 每一个具有5个源符号,其中这些符号中的每一个的大小是例如48个字节,因此第一部分 的大小是28*48 = 1,344个字节。第二部分被划分成4个源块,其中这些源块中的前3个 的每一个都具有4个源符号,剩余的1个源块具有3个源符号,其中这些符号中的每一个的 大小是例如256个字节,因此第二部分的大小是15*256 = 3, 840个字节。
[0147] 图9示出了用于图8A和图8B中所示出的文件结构的一种可能信息分组。在该示 例中,每一个分组都包括UFSI C、基于C来根据图8A和图8B中所示的文件结构的第一部分 所生成的大小为?\ = 48个字节的第一经编码的符号(如先前参照图6所描述的)、以及基 于C来根据图8Α和图8Β中所示的文件结构的第二部分所生成的大小为Τ 2 = 256个字节 的第二经编码的符号(如先前参照图6所描述的)。这些分组的无阴影部分携带该文件的 相应部分的源符号,而有阴影部分携带根据该文件的相应部分所生成的修复符号。在该示 例中,为了恢复该文件的第一部分所需要的最小数量的分组是28,而为了恢复该文件的第 二部分所需要的最小数量的分组是15。
[0148] 图9描述了具有UFSIsO,…,27的28个分组,因此在这些分组中携带的针对文件 的第一部分的所有经编码的符号是源符号。使用至少28的UFSI值所生成的任何其它分组, 携带针对该文件的第一部分的修复符号。
[0149] 基于UFD-UEP方法的另一种优点在于:如果按照其UFSI的顺序(S卩,以UFSI顺序 0、1、2、3、4、…、)来发送经编码的符号,那么用于文件的第i部分的Ζ,个源块的经编码的 符号是以交织顺序来发送的,即,首先发送这Zi个源块中的每一个里具有ESI0的Zi个经编 码的符号,接着发送这Zi个源块中的每一个里具有ESI1的Zi个经编码的符号等。这种属 性对于文件的所有部分来说都是成立的,即使每一个部分具有独立的源块结构。对于大部 分传输来说,这种简单的发送顺序是足够的和优选的。但是,如果分组丢失经历某种周期性 (其可能与源块的数量Zi相同步),则潜在的更佳发送顺序是在发送这些符号之前,对每一 组的Z个UFSI连续经编码的符号进行随机地置换(其中,Z是所有的Zi值之中的最小值, i = 0,…,d-1),S卩,以随机置换的顺序来发送具有UFSI0,…,Z-1的前Z个经编码的符号, 随后,以随机置换的顺序来发送具有UFSI Z,…,2*Z-1的下面Z个经编码的符号等。另一 种潜在发送顺序是:在发送经编码的符号之前,对要发送的所有经编码的符号进行随机地 置换。
[0150] 相比于先前已知的方法或者先前方法的简单扩展,使用UFD-UEP方法能提供多种 其它的优势。例如,使用包括UFSI字段的FEC有效载荷ID字段的UFD-UEP方法,针对文 件的每一个部分的可能经编码的符号的总数仅受到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个源块。
[0151] 图10示出了使用[RaptorQ-RFC-6330]的简单UEP文件传输方法的性能。在该示 例中,UEP文件传输是针对于30个源分组(其使用100个修复分组进行保护)和970个源 分组(其使用900个修复分组进行保护)。
[0152] 图11示出了相对于图10的简单UEP文件传输方法,UFD-UEP文件传输方法提供 的改进的示例。在该示例中,将1MB的文件划分成32KB的第一部分和992KB的第二部分。 对于这两种方法,使用在[RaptorQ-RFC-6330]中所指定的FEC编码,用于携带经编码的符 号的每一个分组中的大小是1,024个字节,发送了总共2, 048个分组。
[0153] 对于图11中所示的简单UEP文件传输方法示例,对文件的第一部分和文件的第二 部分进行独立地处理和传输,其中在这两种情况下,在每一个分组中携带大小为1,024个 字节的准确地一个经编码的符号。用于该文件的第一部分的源在32个分组中进行携带,发 送包含经编码的符号的总共128个分组。用于该文件的第二部分的源在992个分组中进行 携带,发送包含经编码的符号的总共1,920个分组。
[0154] 对于图11中所示出的UFD-UEP文件传输方法,以组合的方式对文件的第一部分和 文件的第二部分进行处理和传输,即,发送的每一个分组包含针对这两个部分中的每一个 的经编码的符号,其中对于第一部分来说,经编码的符号的大小是64个字节,对于第二部 分来说,经编码的符号的大小是960个字节。用于该文件的第一部分的源在512个分组中 进行携带,所有2, 048个分组都包含针对第一部分的经编码的符号。用于该文件的第二部 分的源在1059个分组中进行携带(在源的最后一个分组中的经编码的符号,使用零来填充 以达到全部符号大小为992个字节的第二部分的经编码的符号),所有2, 048个分组都包含 针对第二部分的经编码的符号。
[0155] 如图11中所观察到的,根据丢包率而言,对于文件的第二部分来说,简单UEP文件 传输方法和UFD-UEP文件传输方法的恢复性能实际上是相同的,S卩,在两种情况下,对文件 的第二部分进行公平地恢复,以一致地达到接近48%的丢包率。另一方面,对于文件的第 一部分而言,UFD-UEP文件传输方法的恢复性能显著地比简单UEP文件传输方法更佳:简单 UEP文件传输方法可以以小于65 %的丢包率来一贯地恢复文件的第一部分,而UFD-UEP文 件传输方法可以以接近75%的丢包率来一贯地恢复文件的第一部分。
[0156] 用于绑定的f件传输服备的通用f件传输方法和系统
[0157] 大部分的先前文件传输方法不支持绑定的文件传输,即,将多个文件传输成单一 的绑定文件。传输几个文件的一种简单明了方法就是独立地传送每一个文件。但是,这种 简单明了的方法具有一些缺点。例如,如果这些文件很小,则提供的保护与理想差距很远, 这是由于:当包含针对每一个文件的经编码的符号的分组的数量很小时,丢包率统计存在 较大的方差。
[0158] 图12示出了这种问题。在图12中,根据在传输期间,网络中的丢包的百分比, 来示出32KB文件的文件传输的可靠性。在该文件传输示例中,符号的大小是1,024,使用 [RaptorQ-RFC-6330]中所指定的FEC编码,将该文件的32个源符号编码成64个经编码的 符号,每一个经编码的符号使用一个单独的分组来发送。如在图12中所观察到的,由于这 种变化,在可以实现文件的可靠传输情况下的丢包百分比远远小于50%。
[0159] 此外,如果对很多较小的文件进行独立地编码和发送,那么在可靠地接收所有文 件的情况下的丢包百分比甚至更小。图12示出了用于32个文件的传输的这种行为,其中每 一个文件的大小为32KB,使用与在先前的段落中所描述的相同参数,独立于其它文件来执 行各个文件的编码和传输。如可以观察到的,当丢包率低于大约25% (其远远小于50%) 时,才可以可靠地实现全部32个文件的传输。
[0160] 可以如下所述地对UFD-UEP文件传输方法进行扩展,以便提供一种UFD绑定的文 件传输方法。该UFD绑定的文件传输方法可以使用与UFD-UEP文件传输方法相同的方法,但 不是发送同一文件的d个部分的传输,而是替代地发送:每一个部分是一个单独的文件,将 d个文件传输成一个绑定。假定发送机希望提供大小分别为匕,匕,…,Fh的d个文件的绑 定传输。该发送机UFD绑定的方法将分组大小T划分成大小为?;,?\,…,的d个部分, 因此T等于关于i的?\之和。T的这种划分是基于匕,匕,…,Fh,以及相应文件的优先级。
[0161] 比率匕/%确定为了恢复第i文件,需要接收多少个分组(其假定使用理想的FEC 编码来将该文件的第i部分保护成一个源块),因此比率匕/1\越小,则文件的第i部分的优 先级越高。在实现时,可能需要比F/Ti稍微更多的分组,来恢复该文件的第i部分,例如, 由于FEC编码是不完美的,并呈现某种接收开销,或者由于该文件的该部分被划分成多个 源块,用于一些源块的经编码的符号按照与其它源块相比更高的比率丢失,或者由于匕/% 不是整数。如果期望将要传输的所有文件的优先级是相同的,那么设置?\,使得F/Ti?F/ T。对于发送方和接收机来说,该UFD绑定的文件传输方法的很多细节几乎与UFD-UEP文件 传输方法相同,故进行了省略。
[0162] 可以对该UFD绑定的文件传输方法进行扩展,以便同时地提供绑定的文件传输和 UEP文件传输,S卩,可以差别化地设置该绑定中的每一个文件的优先级。此外,该UFD绑定的 文件传输方法可以在具有适当的信令的基础上,支持多个文件的具有优先级的传输和一个 文件的一部分具有优先级的传输。例如,如果使用UFD绑定的文件传输方法,对三个对象进 行编码和发送,那么前两个对象可以是具有不同优先级的同一文件的不同部分,第三对象 可以是具有不同优先级的不同文件。接收机可以基于多种因素,来决定其对于恢复该绑定 的文件中的哪个文件或者文件部分感兴趣,并且独立于其它文件或者文件的其它部分,只 对这些文件或者文件的部分进行恢复。如本领域普通技术人员所应当认识到的,在阅读本 发明公开内容之后,存在该UFD绑定的文件传输方法的多种可能的替代版本。
[0163] 举一个UFD绑定的文件传输的简单示例,假定要传输32个文件的绑定,每一个文 件的大小为32KB,各个文件具有相同的优先级。假定T= 1,024字节。在该情况下,对于每 一个i = 0,…,31,?\的值=32个字节。每一个分组包含:针对这32个文件中的每一个文 件的32字节经编码的符号,以及用于标识该分组中的32个经编码的符号的UFSI。在该示 例中,存在1,024个分组,其包含来自于32个相同大小的文件中的每一个文件的源符号,这 些是UFSI范围为0到1,023的分组。假定在该示例中,针对每一个文件,生成1,024个另 外的修复符号,并在UFSI范围为1,024到2, 047的另外1,024个分组中进行发送。
[0164] 图12根据丢包率,示出了该UFD绑定的文件传输示例的恢复属性。在该示例中, 可以以丢包率接近50%,使用该UFD绑定的文件传输方法来可靠地恢复所有32个文件,其 相对于近似25%的丢包率,实现了一种本质的改进,这允许使用每一个文件的单独编码和 发送,来进行所有32个文件的可靠传输。
[0165] UFD和UEP文件传输方法可以具有多种其它应用。例如,可以通过多播或者广播 网络(例如,根据3GPP eMBMS标准的网络),来传输DASH格式的内容的分段。在该情况下, DASH格式的内容的每一个分段可以包括:按照1Mbps进行编码的8秒的视频内容,S卩,每一 个分段的大小是1MB。
[0166] 当该DASH格式的内容最终由移动设备上的终端用户进行播放时,期望全保真度 的这种播放(即,不具有伪影或者跳过或者缓冲),终端用户可能仅期望播放被传输的内容 的一部分。为了在传输和播放时获得效率和灵活性(例如,能够将内容一次格式化成DASH 格式,在不进行重新格式化的基础上,通过多种传输方式进行传输),期望将每一个分段传 输成一个单独的文件。
[0167] 对于网络效率而言,期望的是,每一个DASH分段都是FEC保护的,并与其它分段进 行完全交织地传输,其中,优选地可以使用UFD和UEP传输方法在分组中所提供的交织。例 如,假定要传输150个分段,因此要传输的DASH内容的大小是包括1200秒的150MB,或者 等同地20分钟的播放呈现时间。假定在各分组的有效载荷为1200字节的分组中,发送该 内容。那么,使用本申请所描述的UFD和UEP传输方法,可以将每一个分组的8字节分配给 150个分段中的每一个,S卩,每一个分组携带这150个DASH分段中的每一个分段的一个8字 节符号。那么,独立于丢包模式,可以在到达移动接收设备近似131,072个分组之后,S卩,这 150个分段中的每一个分段到达1MB的数据之后,恢复各个DASH分段。在该示例中,在接收 移动设备处,可以在无需对其它DASH分段进行解码的情况下,对这150个DASH分段中的每 一个进行解码并进行可选地播放。
[0168] 再举一个本申请所描述的UFD和UEP文件传输方法的示例,假定传输通过多播或 者广播网络(例如,根据3GPP eMBMS标准的网络)传送的DASH格式的内容,其中DASH内容 包括视频分段和音频分段序列,每一个视频分段包括按照1Mbps编码的8秒视频内容(即, 每一个视频分段的大小是1MB),每一个音频分段包括按照32Kbps编码的8秒的相应音频内 容(即,每一个音频分段的大小是32KB),其中视频分段和相应的音频分段包含主要用于相 同8秒的时间间隔的呈现时间的内容。
[0169] 在该示例中,DASH内容将被流水化,S卩,每一个视频分段和相应的音频分段将按照 其呈现时间的顺序,来按顺序地传输。假定在各分组的有效载荷为1200字节的分组中发送 该内容。那么,使用本申请所描述的UFD和UEP传输方法,可以将每一个分组的1160字节 分配给一个视频分段,将每一个分组的剩余40字节分配给相应的音频分段,S卩,每一个分 组携带视频分段的一个1160字节符号和相应的音频分段的40字节符号。那么,独立于丢 包模式,可以通过接收包含用于视频分段的近似905个分组,来恢复该视频分段,可以从包 含用于相应的音频分段的符号的近似820个分组中,恢复该相应的音频分段。
[0170] 因此,整体上,与8秒时段的呈现时间相对应的任何820个分组(其存在相应的 视频分段和音频分段)的接收,允许移动接收设备恢复该音频分段,另外85个分组的接收 (或者总共905个分组)还允许相应的视频分段的恢复。在该示例中,与视频相比,对音频 进行更多的保护,这在大多情况下是优选的,例如,其是由于视频播放的定时是通过音频播 放的定时来指示的,在大多情况下,优选的是,如果没有接收到足够的数据来播放音频和视 频二者,则至少能对音频进行播放。
[0171] 用于单播修复请求的本地HTTP支持的方法
[0172] 可以对文件或者文件部分进行组织并可用成具有相关联的URL的"HTTP文件",标 准HTTP web高速缓存服务器可以使用该URL来存储和提供接收机对于该文件或者文件部 分的访问。这种文件或者文件部分按照其原始顺序可用成HTTP文件,称为"原始顺序HTTP 文件"。通常,一种用于单播修复请求的本地HTTP支持的方法,可以基于SBN和ESI,将用 于HTTP文件的源块的符号和子符号的修复请求,在HTTP文件中转换成标准HTTP (例如,本 地HTTP/1. 1)字节范围请求(其通常称为具有指定的字节范围的HTTP的HTTP部分GET请 求)。这使标准HTTP web高速缓存服务器能够服务这些修复请求,避免大规模地部署专用 的HTTP web高速缓存服务器的需要,其中这些专用的HTTP web高速缓存服务器理解如何将 一个HTTP文件划分成源块和源块中的源符号。
[0173] 在这些场景中,当系统FEC编码在使用时,通常有利的是,仅在这些会话中的一些 会话(例如,广播/多播会话)里发送修复符号,由于这允许接收机在单播修复请求中只请 求源符号。这具有下面的优点:只需要HTTP文件,或者该HTTP文件的简单重新排序转换 (如下面所更详细描述的)被提供给单播修复服务器(其可以是标准HTTP web高速缓存服 务器),使规定HTTP文件和分发该HTTP文件更简单的逻辑,由于这些逻辑独立于FEC编码。 另一种优点在于:如果在会话中没有发送源符号,则由于所有的源符号都"丢失",因此接收 机可以在单播修复请求中请求任何顺序的源符号,因为这允许针对连续序列的源符号的修 复请求,因此其是优选的。例如,假定使用具有理想的恢复属性的FEC编码,一个部分的源 块包括1,〇〇〇个源符号,接收到该源块的700个修复符号(即使这些修复符号中的一些在 传输过程中丢失,因此接收的修复符号的ESI的模式可能远远不是连续的)。随后,接收机 可以在单播修复请求中,请求该源块的前300个连续源符号,对这些源符号与所述700个修 复符号进行组合,以恢复该源块。如果这些源符号在HTTP文件中是连续的,那么可以使用 单一 HTTP字节范围请求来请求和接收所有300个连续的源符号。
[0174] 接收机不需要执行前缀请求(即,针对文件的以第一字节起始的、设置数量的字 节的请求),但需要所有UE执行前缀请求,随着从UE所获得的请求发生极大地重叠,显著地 提高HTTP服务器中的高速缓存效率,即使当存在很多接收设备,不同的接收设备经历任意 不同的丢包模式(当通过广播或多播会话来获得分组)。
[0175] 基于所描述的这些利益中的一些,上面所描述的技术可以有利于网络或者网络设 备向接收机说明仅正在广播修复符号。当发送该指示时,接收机不需要跟踪其接收到什么 源符号,只需要跟踪其接收的符号的数量。例如,基于接收的符号总数,接收机可以随后确 定要从修复服务器请求多少更多的符号。为了提高高速缓存效率,接收机可以被配置为:基 于其对于只有修复符号被广播的指示的了解,针对丢失数量的源符号,进行前缀请求。
[0176] 替代地,可以向进行前缀请求的接收机给予单独的信令指示。在另一个实施例中, 可以对接收机进行配置,使得只要接收机具有在丢失的源块的不同子集之间进行选择的灵 活性,其就始终选择具有最低符号索引值的丢失的源符号(即,最靠近源块或者子块的开 始的源符号)。这可以是通过广播信道来发送源符号和修复符号的情况。
[0177] 在另一个实施例中,接收设备跟踪接收的符号标识符、ESI,并基于例如FEC 0ΤΙ或 者在接收分组中携带的FEC有效载荷ID,来确定其是否接收与仅修复符号相对应的ESI。 如果是这种情况,则这些接收机可以进行前缀请求。在该实施例中,无需使用显式信令,接 收机将在修复请求中,发送针对源块和子块的前缀的请求(如果其仅接收修复符号的话)。 即使在接收设备从广播信道接收修复符号的情况下,根据接收的符号的模式,以及进行简 单请求和潜在地接收已经通过广播信道接收的冗余数据之间的平衡,这些修复请求仍然是 很大或者完全的前缀请求。
[0178] 当发送仅修复符号被广播的信息,并且发送接收机进行前缀请求的信息时,在使 用HTTP字节范围文件修复请求或者基于符号的文件修复请求时,存在一些优点。因此,这 些方法可以应用于支持任意一种、或者这两种请求格式的接收机和网络。
[0179] 用于指示仅修复符号被广播的信令,可以在带外发送(通过单播)或者带内发送 (通过广播)。根据期望的粒度级别,该指示可应用于服务级别、会话级别、媒体级别或者 甚至文件级别。例如,可以将该信令增加在用户服务描述("USD")中。USD可以指示:为 了传输所有的识别的服务,仅修复符号被广播。此外,还可以将该信令增加在媒体呈现描述 ("MPD")中,其中MH)指示使用仅修复符号来广播哪个媒体。可以将该信令增加在会话描 述协议("SDP")中,以指示其应用于整个会话的传输,还是应用于该会话中的媒体组成部 分。此外,还可以将该信令增加在文件描述表("FDT")中,以指示修复符号的广播仅在文 件级别上应用。
[0180] 用于需要接收机进行针对修复数据的前缀请求的信令,还可以通过带内和带外传 输来进行传送。此外,根据期望的粒度级别,该指示还可以应用于服务级别、会话级别、媒体 级别或者甚至文件级别。
[0181] 因此,存在着用于提供这种指示的多种方法和装置,接收机可以被编程和/或配 置为:在接收到这种指示和没有接收到这种指示的情况下,进行差别化响应。
[0182] 该请求可以是针对于特定数量的字节或者符号。在一些情况下,接收机将基于接 收的修复符号的数量,以及预期在将要进行接收的文件或对象中包含的源符号的数量,来 确定要请求的源符号的数量。在其它情况下,接收机可以执行调度操作,其中接收机确定如 何使用其已经接收到的仅修复符号来进行解码,并因此可以注意到需要的更具体数量的源 符号。例如,修复符号中的一些是其它修复符号的冗余,在该情况下,可能需要更多的源符 号。在其它实例中,也许会发现需要更少的源符号。
[0183] 接收机可以基于FEC 0ΤΙ,将针对与特定的(SBN,ESI)对相对应的原始顺序HTTP 文件的源符号的请求,转换成HTTP字节范围请求。例如,假定针对一个文件的FEC ΟΤΙ是 (F,Al,Τ,Ζ,Ν),要请求的源符号的SBN是Α,针对源符号的ESI是Β,为了简单起见,假定 N= 1,即在该示例的文件结构中,不再将源块划分成子块。随后,接收机可以使用例如在 [RaptorQ-RFC-6330]的第4. 4节中所描述的方法来确定(KL,KS,ZL,ZS),其中第一 ZL源块 具有KL个源符号,剩余的ZS个源块具有KS个源符号。随后,基于A、B和符号大小T,接收 机可以确定该文件中的源符号的起始字节索引SI是如式1中所示,该文件中的源符号的结 束字节索引是El = SI+T-1。随后,接收机可以使用针对于源符号的标准HTTP字节范围请 求,来请求字节SI到EI。
[0184] SI = T* (KL*min {A, ZL} +KS*max {A-ZL,0} +B)(式 1)
[0185] 存在对于这些方法的多种扩展和改进,如本领域普通技术人员所认识到的。例如, 如果在没有使用子块划分的情况下,从原始顺序HTTP文件请求多个连续的源符号,则可以 进行单一 HTTP字节范围请求。再举一个例子,HTTP web高速缓存服务器除了具有或者替代 原始顺序HTTP文件之外,还可以具有包含修复符号的文件,或者原始顺序HTTP文件可以已 经被扩展到包含修复符号,接收机可以使用类似于本申请所描述的那些的方法,来进行针 对修复符号的HTTP字节范围请求。再举一个增强的示例,可以将这些方法扩展到使用子块 划分的情况,使用类似的方法,如本领域普通技术人员所认识到的。例如,接收机可以使用 例如在[RaptorQ-RFC-6330]的第4. 4节中所描述的方法来确定(1^5,1,呢),其中源块 的前NL子块的大小为TL*A1,源块的剩余NS个子块的大小为TS*A1。那么,基于A、B和符 号大小T,接收机可以确定该文件中的与源符号相对应的N个子符号的起始和结束字节索 弓丨,使用标准HTTP字节范围请求,进行针对这些字节的请求。
[0186] 再举一个例子,接收机可以基于FEC 0ΤΙ,将针对于与特定的UFSI相对应的文件或 者文件部分的源符号的请求,转换成HTTP字节范围请求。
[0187] 下面的方法可以通过接收机恢复HTTP文件的符号,同时使用标准HTTP web高速缓 存服务器来向接收机传输所请求的字节范围请求,来极大地增强使用标准HTTP字节范围 请求的效率。
[0188] -种用于支持如上所述的HTTP字节范围请求的简单明了方法,是使用原始顺序 HTTP文件。该方法具有下面的优点:不需要原始文件或者文件部分的转换,来生成针对 HTTP web高速缓存服务器的原始顺序HTTP文件,但可能需要多种不同的HTTP字节范围请 求来请求源符号,即使当针对每一个源块,仅请求连续的源符号。为此,存在至少两个原因: (1)可能存在多个源块,存在来自于各个源块的丢失的源符号,在该情况下,针对每一个源 块,可能需要单独的字节范围请求;(2)可能每一个源块存在多个子块,因此甚至从一个源 块请求单一的源符号,也需要针对包括源符号的所述多个子符号的多个HTTP字节范围请 求,这是由于一个源符号的子符号在原始顺序HTTP文件中是非连续的。
[0189] 一种用于支持上面所描述的HTTP字节范围请求的有利方法,首先基于原始文件 或者文件部分的FEC0TI,将该文件或者文件部分重新组织成一种新格式(本申请称为 "UFSI顺序HTTP文件")。当存在多个源块和/或每一个源块存在多个子块时,该方法是有 用的。UFSI顺序HTTP文件中的数据的顺序是:UFSI0的文件符号、UFSI1的文件符号、UFSI2 的文件符号等,即,将UFSI顺序HTTP文件中的数据的顺序组织成,根据增加的连续UFSI进 行排序的文件符号,如FEC 0ΤΙ所确定的。URL可以与UFSI顺序HTTP文件相关联,可以将 URL提供给HTTP web高速缓存系统。随后,接收机可以根据需要,使用HTTP字节范围请求, 来请求UFSI顺序HTTP文件的一部分。UFSI顺序HTTP文件的一种优点在于:如果接收机 从每一个源块接收到近似相同数量的修复符号,那么获得足够的源符号来恢复原始文件或 者文件部分而所需要的HTTP字节范围请求的数量可以是最小的,例如,如果接收到每一个 源块的准确相同数量的修复符号,那么一个HTTP字节范围请求可以是足够的。例如,针对 UFSI顺序HTTP文件的前L*T*Z个连续字节的请求,足够用于从原始文件或者文件部分的 Z个源块中的每一个源块接收前L个大小为T的源符号。如果在针对Z个源符号的每一个 的一个或多个会话中接收到K-L个修复符号,并且FEC编码具有理想的恢复属性,那么从该 HTTP字节范围请求接收的L*T*Z个字节,足够用于对该HTTP文件进行FEC解码,其中在该 示例中,推测K是在Z个源块中的每一个源块里的源符号的数量。
[0190] 另一种用于支持上面所描述的HTTP字节范围请求的有利方法,首先基于原始文 件或者文件部分的FEC 0ΤΙ,将该文件或者文件部分重新组织成一种不同的新格式(本申请 称为"SS顺序HTTP文件")。当每一个源块存在多个子块时,该方法是有用的,这是由于在 该情况下,每一个源符号可能不是该原始文件或者文件部分的一个连续部分,即,一个源符 号的子符号可以按照原始文件排序,分散在整个源块之中。SS顺序HTTP文件中的数据的顺 序是具有下面的顺序:第一源块的所有源符号、接着是第二源块的所有源符号、接着是第三 源块的所有源符号等,即,将SS顺序HTTP文件中的数据的顺序组织成,根据在源块中的增 加的连续ESI进行排序的源符号,其是按照增加的连续SBN顺序的源块的串联,如FEC ΟΤΙ 所确定的。URL可以与SS顺序HTTP文件相关联,可以将URL提供给HTTP web高速缓存系 统。随后,接收机可以根据需要,使用HTTP字节范围请求,来请求SS顺序HTTP文件的一部 分。如果接收机从每一个源块接收到不同数量的修复符号,则SS顺序HTTP文件是特别有 利的。例如,如果存在两个源块,每一个源块具有1,〇〇〇个源符号,如果接收机从一个或多 个会话接收到第一源块的900个修复符号,第二源块的100个修复符号,那么接收机可以执 行一个针对SS顺序HTTP文件的前T*100个字节的请求,并接收第一源块的100个源符号, 接收机可以进行另一个针对SS顺序HTTP文件的字节Τ*100到Τ*1,900 - 1的请求,接收第 二源块的900个源符号,其中在该示例中,Τ是用于这两个源块的字节的符号大小。
[0191] 此外,还可以使用刚刚所描述的两个方法的组合,即,通过针对接收机的不同URL, UFSI顺序HTTP文件和SS顺序HTTP文件是可用的,转而接收机可以向两个不同的格式的 HTTP文件,使用HTTP字节请求的组合。例如,如果存在10个源块,每一个源块具有1,000 个源符号,并且如果在一个或多个会话中,接收到前8个源块中的每一个的800个修复符 号,接收到第9个源块的820个修复符号,接收到第10个源块的500个修复符号,那么接收 机可以向UFSI顺序HTTP文件进行HTTP字节范围请求,以便接收10个源块中的每一个源 块的200个源符号,向SS顺序HTTP文件进行另外的HTTP字节范围请求,以便接收第10个 源块的另外300个源符号。在该示例中,接收机可以接收第9个源块的不需要的20个源符 号(其假定具有理想恢复属性的FEC编码),但在一些情况下,与准确地请求每一个源块的 所需要的数量的源符号(其需要更大数量的不同的HTTP字节范围请求)相比,使用更少数 量的HTTP字节范围请求来请求一些源块的多于最小需要的字节,可以是更高效的。
[0192] 有利的是,发送接收机可以使用该HTTP字节范围请求来修复文件的时间。这实现 将该特征逐渐引入到当前针对文件修复使用其它请求消息的已部署网络中。计划将其网络 操作转换到传统的基于HTTP的文件修复服务器的系统运营商,可以在该特征在其整个网 络或者漫游的合作伙伴网络上被完全地支持之前,开始部署能够进行HTTP字节范围请求 的接收机。随后,随着部署的具有HTTP能力接收机的数量增加,运营商可以开始部署HTTP 服务器,以便与来自这些终端的估计的请求有效载荷相匹配。在特定的网络中可以使用信 令来向接收机指示:其可以在该网络中使用HTTP字节范围请求。
[0193] 用于向网络发送HTTP字节范围请求的支持的另一种方法,是除了提供修复服务 器URI之外,还提供指示该服务器只支持HTTP字节范围请求的描述符(例如,将服务器URI 标签成"byteRangeServiceURI"类型对象)。在已经部署了仅接受基于符号的请求的修 复服务器的网络中,这种方法是有用的,其通常用" serviceURI "描述符来标识。这种新的 "byteRangeServiceURI"的规定,使新的接收机能够使用与这些服务器的字节范围请求,同 时防止不认识该描述符的传统接收机从这些HTTP服务器错误地进行基于符号的请求。
[0194] 用于向网络发送HTTP字节范围请求的支持的另一个实施例,是除了提供修复服 务器URI之外,还提供指示该服务器是只支持HTTP字节范围请求,还是支持HTTP字节范围 请求和其它请求格式(例如,基于符号的请求)的描述符。在另一个实施例中,该描述符指 示三种可能中的一种:(1)该修复服务器是否只支持HTTP字节范围请求;(2)该修复服务 器是否只支持另一种类型的请求格式(例如,基于符号的请求);(3)该修复服务器是否同 时支持HTTP字节范围请求和其它请求格式。此外,该描述符还指示这些请求格式中的哪一 种是优选的,或者需要进行使用(如果该接收机支持的话)。可以将服务器所支持的请求格 式的这种描述符,连同修复服务器URI的列表一起发送。
[0195] 此外,还可以向接收机发送另一个描述符(例如,"useFileURI"元素),其指示其 可以使用HTTP字节范围请求,直接从存储文件的内容服务器(例如,互联网上的位置)获 取该文件的一部分或者该文件的全部。这实现了一种体系结构,在该体系结构中,网络运营 商(例如,移动网络运营商)不需要部署专用的文件修复服务器,而可以依赖于这些文件 的内容服务器来提供修复过程的源数据。当通过广播信道下载文件时,可以使用包括文件 的 URI (例如,www.〈news providersite〉· com/latest_news. 3gp)的文件描述符表来发送 这些文件。"useFileURI"元素的存在将向终端指示其可以使用HTTP字节范围请求,来从 www.〈news providersite〉· com/latest_news. 3gp获取源数据。因此,不是向接收机指出w ww. <mobile-〇per-cached-file-server-〇f-news>. com/newsfile_0〇3· 3gp,而是接收机可以 直接进入该内容已经可用的站点,其通常用于使用传统的HTTP协议来访问该内容的浏览 器。可以存在发送文件格式的另一种元素,例如原始顺序或者UFSI顺序或者SS顺序或者 扩展的原始顺序HTTP文件格式。
[0196] 独立于专用修复过程,除了广播的内容之外,内容传输系统可以包括用于向接收 机发送信号的装置,文件的内容的一些或者全部是单播可用的。这种信令可以是提供成广 播的一部分的数据,其中该数据指向单播位置。例如,该广播数据可以包括文件可用性的指 示和用于该文件的URL。不同的实施例可以差别化地使用这些可用的文件。例如,被广播的 URL所指示的文件,可以是用于修复过程的文件,其用于加速下载和/或支持更快速的初始 播出。
[0197] 在一些实施例中,文件存在于一个以上的网络或者物理位置。为此,广播信道上的 信令可以包括:指示可访问该文件的多个位置的URL列表。在一些实施例中,存在实际指向 同一物理位置,因此指向相同的文件或对象的多个URL。
[0198] URL所指示的源可以是受到限制的,例如,只可用于有限数量的时间。有益的是, 实现对象(其在广播分发中通过标识符来指定)到可能的多个URL的映射。对于这些URL 中的每一个,可以提供另外的信息,例如,一个文件在一个位置可使用HTTP协议来物理地 访问,在其它位置或者相同的位置可使用其它协议来访问的指示。这种另外信息的其它示 例包括:该资源可在特定的URL处访问的时间、和/或关于在访问该资源的多个URL之间选 择一个URL时的优先级的规则(例如,优先级列表、或者取决于接入网络可用性的优先级列 表)等。
[0199] 还可以连同服务器URI列表来发送另一种描述符,以便提供当接收机请求 修复数据时,其应当首先尝试哪个服务器或者域的优先级。在一个优选的实施例中, "priorityURI"可以与某些URI相关联,以便指示:接收机在选择服务器时,其应当具 有优先级。这实现了两种层级的优先级划分,从而接收机首先尝试具有"priorityURI" 的服务器,仅当具有优先级的服务器无响应时,才向其它服务器发送请求。在另一个 实施例中,可以将服务器URI的组结构化成具有按照优先级下降的顺序所列出的组的 "priortyGroups"。这向接收机指出其应当首先从最高优先级组中进行选择。如果针对所 有这些服务器的请求都失败,则接收机转到从下一组的服务器中进行选择等,从而实现多 个层级的优先级划分。
[0200] 现在描述可以向接收机发送描述符和服务器URI列表的两种通用方法。在一种方 法中,该信令是通过针对于所有接收机的广播信道(带内),在另一种方法中,该信令是通 过针对每一个接收机的单播信道(带外)。可以将该信息增加到在文件修复特征中使用的 多种现有消息类型,例如,关联过程描述(配置文件)、用户服务描述("旧0")、媒体呈现描 述("MPD")、会话描述协议("SDP")或者文件描述表("FDT")。
[0201] 当服务器被配置为发送FDT和USD,以便分发该信息,接收机被配置为读取和理解 这些FDT和USD时,这提供了用于发送各种有用信息的工具。
[0202] 例如,该信息可以在FLUTE中的文件元素中包括"替代内容位置",其可以包括用 于相同文件的多个替代URL。可以对该元素进行扩展,以便还增加其它参数(例如,资源可 用性的指示符、其可用的格式、其可用的时间、优先级等)。
[0203] 再举一个例子,可以将"BaseURL"元素包括在FDT元素中(并因此在文件元素中 不需要),以便向接收机指示可以根据这些BaseURL元素中的任何一个来解析FDT中的每 一个文件。也可以存在如上的标志和定时。这可以覆盖多种部署选项。在一种变型中,在 USD层级而不是FLUTE上,呈现该BaseURL元素。因此,可以将USD提供成用于进行MBMS的 BaseURL解析,同时与FLUTE相兼容的方式。
[0204] 在另一个实施例中,将一些可选元素(例如,"替代内容位置1"元素和"替代内容 位置2"元素)引入到文件传输表(FDT)的文件元素中。这些元素中的每一个元素可以用 于在内容服务器上或者在公共专用服务器上提供文件的URL。在一个实施例中,当存在这些 元素中的任意一个时,在从基于符号的文件修复服务器进行请求之前,终端对这些URL划 分优先级。此外,还可能的是,当这两个元素存在时,在"替代内容位置2"元素之前,选择 "替代内容位置1"元素。这些URL是绝对URL或者如RFC3986中所描述的相对引用。
[0205] 在另一个实施例中,可选的"可用时"元素与上面的"替代内容位置X"属性中的每 一个相关联,以便指示可用时间(如果知道的话)。
[0206] 在另一个实施例中,可以在文件传输表中使用可选的元素"Base-URL-Ι"和 "Base-URL-2"。当存在时,"Base-URL-Ι"提供用于对FDT文件元素的任何"替代内容位置 1"元素中包括的相对引用进行解析的基URL。当存在时,"Base-URL-2"提供用于对FDT文 件元素的任何"替代内容位置2"元素中包括的相对引用进行解析的基URL。
[0207] 可以考虑其它选项,也可以考虑上面选项的组合。例如,将文件格式类型嵌入在根 据可用的文件格式来组合的其它URL中。
[0208] 随着运营商的网络中的终端自动产生,更多的接收机能够进行HTTP字节范围请 求,运营商可以将文件修复容量的大部分转移到传统HTTP服务器,并通过该信令方法来指 示其能力。
[0209] 在接收到某些修复服务器支持HTTP字节范围请求的指示之后,支持HTTP字节范 围请求的终端可以使用该字节范围消息,来从支持服务器中的一个请求数据。
[0210] 在另一个实施例中(在该实施例中,描述符指示要使用的请求格式的优选或者要 求),接收机遵循所指示的该优选或者要求。
[0211] 另一种方法是向接收机发送:修复服务器支持HTTP字节范围请求,而无需标识哪 个具体的服务器具有该能力。这种信令指示所有修复服务器都能够只进行字节范围请求、 或者所有都能够进行HTTP字节范围请求和其它请求消息格式(例如,基于符号的请求)。
[0212] 在另一个实施例中,该信号指示如上面所列出的三种可能中的一种:(1)所有修 复服务器是否只支持HTTP字节范围请求;(2)该修复服务器是否只支持另一种类型的请求 格式(例如,基于符号的请求);(3)该修复服务器是否同时支持HTTP字节范围请求和其它 请求格式。当使用这种简化的信令时,运营商可以在向接收机发送该信息之前,对所有的文 件修复服务器进行升级,以支持所指示的请求格式。此外,还可以发送文件格式类型,例如, 原始顺序、UFSI顺序、SS顺序、扩展的原始顺序或者其它类型的HTTP文件格式。如果没有 显式地发送文件格式类型,则可以存在缺省的文件格式类型,例如,在没有发送文件格式类 型的情况下,原始顺序HTTP文件格式可以是缺省文件格式类型。
[0213] 类似于描述符和服务器URI信息,也可以使用两种通用方法来向接收机发送该 信令。在一种方法中,该信令是通过针对于所有接收机的广播信道(带内),在另一种方 法中,该信令是通过针对每一个接收机的单播信道(带外)。可以将该指示增加到在文件 修复特征中使用的多种现有消息类型中,例如,关联过程描述(配置文件)、用户服务描述 ("USD")、媒体呈现描述("MPD")、会话描述协议("SDP")或者文件描述表("FDT")。
[0214] 现在描述可以向接收机发送描述符和服务器URI的列表的两种通用方法。
[0215] 如本领域普通技术人员所认识到的,存在这些方法的多种变型。例如,原始顺序 HTTP文件、UFSI顺序文件和SS顺序HTTP文件全部都可用于请求。再举一个例子,可以对 SS顺序HTTP文件进行分割,并可用成多个HTTP文件,一个这种HTTP文件对应于每一个源 块。举一些变型的其它示例,可以使用不同于基于HTTP的方法和协议的方法和协议(例如, 基于RTP/UDP的方法),或者可以使用建立在UDP之上的专有协议。
[0216] 硬件系统和示例
[0217] 上面所描述的方法和系统可以用硬件、软件和/或包含程序代码或者其它指令的 适当组织的计算机可读介质来实现。程序代码可以提供在非临时性介质上,或者发送成下 载等,以便在适当的硬件平台上执行。本申请提供了可以使用上面的内容的系统的一些示 例。
[0218] 图13是使用多阶段编码的通信系统1300的框图,如可以用于作为文件传输系统 的一部分来发送分组,如本申请所描述的。当然,也可以使用其它编码和/或硬件。
[0219] 在通信系统1300中,将输入文件1301或者输入流1305提供给输入符号生成 器1310。输入符号生成器1310根据该输入文件或者流,生成一个或多个输入符号的序列 (IS (0)、IS (1)、IS (2)、…),其中每一个输入符号具有一个值和一个位置(在图13中描述 成用括号括起来的整数)。如上面所解释的,用于输入符号的可能值(即,其字母表)通常 是2"个符号的字母表,使得每一个输入符号编码对应于输入文件的Μ个比特。通常,Μ的 值通过使用通信系统1300来确定,但通用系统可以包括针对输入符号生成器1310的符号 大小输入,使得Μ可以在使用之间发生变化。将输入符号生成器1310的输出提供给编码器 1315。
[0220] 静态密钥生成器1330产生静态密钥的流SpSi、…。生成的静态密钥的数量通常 是受限的,其取决于编码器1315的具体实施例。随后,将更详细地描述静态密钥的生成。动 态密钥生成器1320针对要由编码器1315生成的每一个输出符号,生成动态密钥。对每一 个动态密钥进行动态生成,使得用于相同输入文件的动态密钥的很大部分是唯一的。随机 数生成器1335可以向生成器1320和/或生成器1330提供输入。例如,Luby I描述了可以 使用的密钥生成器的实施例。将动态密钥生成器1320和静态密钥生成器1330的输出提供 给编码器1315。
[0221] 根据动态密钥生成器1320所提供的每一个密钥I,编码器1315从输入符号生成 器所提供的输入符号,生成具有值B(I)的输出符号。下面将更详细地描述编码器1315的 操作。每一个输出符号的值是基于其密钥、基于输入符号中的一个或多个的某种函数、以及 根据输入符号所计算的可能的一个或多个冗余符号来生成的。导致特定的输出符号的输入 符号和冗余符号的集合,本申请称为输出符号的"关联符号"或者仅其的"关联"。该函数 ("值函数")和关联的选择,是根据下面所更详细描述的处理来进行的。通常(但不是始 终),Μ对于输入符号和输出符号来说是相同的,S卩,其均对应于相同数量的比特的编码。
[0222] 在一些实施例中,编码器1315使用输入符号的数量K来选择所述关联。如果K是 提前未知的,例如当该输入是流媒体文件时,K可以只是某个估计量。此外,编码器1315还 可以使用值K,来为输入符号和编码器1315所生成的任何中间符号来分配存储空间。
[0223] 编码器1315向发送模块1340提供输出符号。此外,还从动态密钥生成器1320向 发送模块1340提供每一个这种输出符号的密钥。发送模块1340发送输出符号,并根据使 用的密钥方法,发送模块1340还可以通过信道1345向接收模块1350发送关于所发送的输 出符号的密钥的某种数据。假定信道1345是擦除型信道,但对于通信系统1300的适当操 作来说,这并不是必须的。
[0224] 模块1340U345和1350可以是任何适当的硬件组件、软件组件、物理介质或者其 任意组合,只要发送模块1340用于向信道1345发送输出符号和关于其密钥的任何必需数 据,接收模块1350用于从信道1345接收符号和关于其密钥的潜在某种数据。K的值(如果 使用其来确定所述关联的话)可以通过信道1345来发送,或者其可以通过编码器1315和 解码器1355的协商来提前设置。在图13(和本申请的其它地方)所示出的其它元素(无 论其被描述成模块、步骤、处理等),也可以使用硬件、软件和/或在电子可读介质上存储的 程序代码来实现。
[0225] 如上面所解释的,信道1345可以是实时信道,例如,通过互联网或者广播链路从 电视发射机到电视接收者的路径或者从一个点到另一个点的电话连接,或者信道1345可 以是诸如CD-ROM、磁盘驱动器、Web站点等之类的存储信道。信道1345甚至可以是实时信 道和存储信道的组合,例如,当一个人通过电话线从一个个人计算机向互联网服务提供商 (ISP)发送输入文件时所形成的信道,该输入文件存储在Web服务器上,并随后通过互联网 发送给接收者。
[0226] 由于假定信道1345是擦除型信道,因此通信系统1300不假定离开接收模块1350 的输出符号和进入发送模块1340的输出符号之间的一对一对应关系。事实上,当信道1345 包括分组网络时,通信系统1300甚至不能够假定在通过信道1345来发送时,保持任何两个 或更多分组的相对顺序。因此,输出符号的密钥通过使用上面所描述的密钥方案中的一个 或多个来确定,不需要通过这些输出符号离开接收模块1350的顺序来确定。
[0227] 接收模块1350向解码器1355提供输出符号,任何数据接收模块1350接收关于向 动态密钥重新生成器1360提供的这些输出符号的密钥。动态密钥重新生成器1360重新生 成用于所接收的输出符号的动态密钥,将这些动态密钥提供给解码器1355。静态密钥生成 器1363重新生成静态密钥&、Si、…,并将其提供给解码器1355。静态密钥生成器访问在 编码和解码处理期间使用的随机数生成器1335。这可以具有访问相同的物理设备的形式 (如果随机数是在该设备上生成的话),或者具有访问用于生成随机数以实现相同行为的 相同算法的形式。解码器1355使用动态密钥重新生成器1360和静态密钥生成器1363所 提供的密钥以及相应的输出符号,来恢复输入符号(同样的IS(0)、IS(1)、IS(2)、…)。解 码器向输入文件重组器1365提供所恢复的输入符号,重组器1365生成输入文件1301或者 输入流1305的拷贝1370。
[0228] 可以使用多个接收机和/或多个发送方来进行文件传输。在图14-15中示出这些 概念。
[0229] 图14示出了一个接收机2402通过三个信道2406,从三个发射机2404 (其分别地 表示为和"C")接收数据的布置。可以使用该布置对可用于接收机的带宽增至三 倍,或者处理发射机没有足够长的可用时间来从任何一个发射机获得完整的文件。如上所 述,每一个发射机2404发送值S()的流。每一个S()值代表输出符号B(I)和密钥I,上面 解释了其的使用。例如,值S(A,n A)是在发射机2402(A)处所生成的输出符号的序列中的第 "%"个输出符号和第"nA"个密钥。来自于一个发射机的密钥序列,优选地与来自其它发射 机的密钥序列不相同,使得发射机不会重复工作。根据序列SO是发射机的函数的事实,在 图14中示出了该内容。
[0230] 应当注意,发射机2402不需要为了不进行重复工作,而进行同步或者协调。事实 上,在没有协调的基础上,每一个发射机可能处于其序列中的不同位置(即,n A尹nB尹r〇。
[0231] 在图15中,将一个输入文件2502的拷贝提供给多个发射机2504(在图中示出了 其中的两个)。发射机2504通过信道2506向接收机2508独立地发送根据输入文件2502 的内容所生成的输出符号。在接收机的解码器能够恢复整个输入文件之前,所示出的两个 发射机中的每一个发射机可以只需要发送(K+A)/2个输出符号。
[0232] 使用两个接收机和两个发射机,接收机单元2510所接收的信息的总量可以是在 一个信道2506上可用的信息的四倍。该信息量可以小于单一信道信息的四倍(例如,如果 发射机向两个接收机广播相同的数据的话)。在该情况下,接收机单元2510处的信息的量 至少是两倍(通常是更多倍数,如果在任何信道中丢失有数据的话)。应当注意的是,即使 这些发射机只广播一个信号,但接收机处于不同的时间的视角,有利的是一个以上的接收 机对各个发射机进行监听。在图15中,接收机单元2510执行与图13中所示出的接收模块 1350、解码器1355、动态密钥重新生成器1360和输入文件重组器1365的功能相类似的功 能。
[0233] 在一些实施例中,在具有两个编码器的一个计算设备中,对输入文件2502进行编 码,使得计算设备可以为一个发射机提供一个输出,为另一个发射机提供另一个输出。在阅 读了本发明之后,这些示例的其它变型应当是显而易见的。
[0234] 应当理解的是,本申请所描述的编码装置和方法也可以用于其它通信情形,并且 不限于诸如互联网之类的通信网络。例如,光盘技术还使用擦除型和纠错编码来处理划伤 磁盘的问题,在其上存储信息时,将通过使用链式反应码来获益。再举一个例子,卫星系统 可以使用擦除型编码,以便平衡用于传输的功率需求,通过减少功率来有目的地允许更多 的差错,链式反应编码在该应用情形下是有用的。此外,已使用擦除型编码来开发RAID(独 立磁盘冗余阵列)系统,以便可靠地进行信息存储。因此,本发明证明在诸如上面的示例之 类的其它应用中是有用的,其中在这些情形下,使用编码来处理潜在有损数据或错误数据 的问题。
[0235] 在一些优选的实施例中,向两个或更多的多目的计算机器提供用于执行上面所描 述的通信过程的指令集(或者软件),其中这些计算机器通过可能的有损通信介质进行通 信。机器的数量可以从一个发送方和一个接收者到任意数量的发送和/或接收的机器进行 变化。连接这些机器的通信介质可以是有线、光纤、无线等。上面所描述的通信系统具有多 种用途,这些根据本申请的描述将是显而易见的。
[0236] 使用HTTP流服务器的块请求流媒体系统,可以如上所述地传输文件。下面,将描 述该系统的一个示例性实现。使用HTTP流媒体,源可以是标准的web服务器和内容传输网 络(⑶N),可以使用标准的HTTP。
[0237] 在客户端,可以使用HTTP,针对各个分段进行请求,客户端可以将这些分段无缝地 拼接在一起。HTTP流媒体的优点包括:使用标准化和现有的基础设施。
[0238] 图16示出了可以传送文件的块请求流媒体系统的简化图。在图16中,示出了块 流系统1600,其包括块服务基础设施("BST")1601,该块服务基础设施("BST")1601转 而包括摄取系统1603,该摄取系统1603用于摄取内容1602、准备该内容,通过将该内容存 储到可由摄取系统1603和HTTP流服务器1604访问的内容存储器1610,来对该内容进行封 装以便由HTTP流服务器1604进行服务。如图所示,系统1600还可以包括HTTP高速缓存 1606。在操作中,诸如HTTP流客户端之类的客户端1608向HTTP流服务器1604发送请求 1612并且从HTTP流服务器1604或HTTP高速缓存1606接收响应1614。在各种情况下,图 16中所示的元件可以至少部分地用软件来实现,其中所述软件包括在处理器或者其它电子 器件上执行的程序代码。
[0239] 如图17中所示,可以将媒体块存储在块服务基础设施1601(1)中,该块服务基础 设施1601 (1)可以是例如HTTP服务器、内容传送网络设备、HTTP代理、FTP代理或者服务 器、或者某种其它媒体服务器或系统。块服务基础设施1601(1)连接到网络1722,该网络 1722可以是例如互联网协议("IP")网络(例如,互联网)。将块请求流系统客户端示出 为具有六个功能组件,也叫做:块选择器1723,其被提供有上面所描述的元数据,并且执行 要从由元数据所指示的多个可用块中选择要请求的块或者部分块的功能;块请求器1724, 其从块选择器1723接收请求指令,并且通过网络1722执行向块服务基础设施1601 (1)发 送针对所规定的块、一个块的一部分或者多个块的请求所必需的操作,以及转而接收包括 块的数据;以及块缓冲器1725、缓冲器监测器1726、媒体解码器1727、以及有助于媒体消费 的一个或多个媒体转换器1728。
[0240] 将块请求器1724所接收的块数据传送到用于存储媒体数据的块缓冲器1725,以 进行临时存储。替代地,可以直接将所接收的块数据存储到块缓冲器1725。块缓冲器1725 向媒体解码器1727提供媒体数据,媒体解码器1727对该数据执行为了向媒体转换器1728 提供适当输入所必需的这些转换,该媒体转换器1728以适当的形式将媒体呈现给用户或 者其它消费。媒体转换器的示例包括视觉显示设备(例如,在移动电话、计算机系统或者电 视中所建立的那些),并且还可以包括诸如扬声器或耳机之类的音频呈现设备。
[0241] 缓冲器监测器1726接收涉及块缓冲器1725的内容的信息,并基于该信息和可能 的其它信息,提供对块选择器1723的输入,该块选择器1723用于确定要请求的块的选择, 如本申请所描述的。
[0242] 块请求流系统(BRSS)包括对一个或多个内容服务器(例如,HTTP服务器、FTP服 务器等)进行请求的一个或多个客户端。摄取系统包括一个或多个摄取处理器,其中摄取 处理器接收内容(实时地或非实时地),对于由BRSS所使用的内容进行处理,并且将该内容 以及还有可能连同由摄取处理器所生成的元数据存储到可由内容服务器访问的存储器中。
[0243] BRSS还可以包含与内容服务器进行协调的内容高速缓存。内容服务器和内容高速 缓存可以是接收针对具有HTTP请求形式的文件或分段的请求的传统HTTP服务器和HTTP 高速缓存,其中所述HTTP请求包括URL并且还可以包括字节范围,以便请求与该URL所指 示的所有文件或分段相比更少的内容。客户端可以包括传统HTTP客户端,该传统HTTP客户 端进行HTTP服务器的请求并且处理对这些请求的响应,其中HTTP客户端是由新型客户端 系统驱动的,该新型客户端系统形成请求,将这些请求传送到HTTP客户端,从HTTP客户端 获得响应,对这些响应进行处理(或者存储、转换等)以便将这些响应提供给呈现播放器, 以便由客户端设备进行播放。一般情况下,客户端系统事先不知道将需要哪些媒体(这是 因为这些需求依赖于用户输入、用户输入的变化等),所以其被称为"流"系统,在所述"流" 系统中,一接收到媒体或者在接收到媒体后不久,就"消费"该媒体。结果,响应延迟和带宽 约束可能造成呈现的延迟,例如,造成呈现的暂停(由于流赶上用户在消费该呈现所处的 地方)。
[0244] 为了提供能觉察到具有良好质量的呈现,可以在BRSS中(在客户端终端处、在摄 取终端处、或者二者)实现多个细节。在一些情况下,实现的细节是在考虑或处理位于网 络的客户端-服务器接口的情况下完成的。在一些实施例中,客户端系统和摄取系统都意 识到增强,而在其它实施例中,仅一方意识到增强。在这些情况下,整个系统从增强中获益 (即使一方没有意识到该情况),而在其它情况下,只有双方都意识到时才产生该益处,但 是当一方没有意识到时,其仍然进行操作而不会失败。
[0245] 如图18中所示,可以根据各种实施例,将摄取系统实现成硬件和软件组件的组 合。该摄取系统可以包括能被执行以使系统执行本申请所讨论的方法中的任何一个或多 个的指令集。可以将该系统实现成具有计算机形式的特定机器。该系统可以是服务器计算 机、个人计算机(PC)、或者能够执行指令集(串行或其它方式)的任何系统,其中该指令集 规定了要由该系统采取的动作。此外,虽然仅示出了单个系统,但是术语"系统"应当还包 括:单独地或者联合地执行一个(或多个)指令集以执行本申请所讨论的方法中的任何一 个或多个方法的任何系统集合。
[0246] 摄取系统可以包括摄取处理器1802(例如,中央处理单元(CPU))、存储器1804以 及磁盘存储器1806,其中存储器1804可以在执行期间存储程序代码,所有这些部件通过总 线1800与进行相互通信。该系统还可以包括视频显示单元1808(例如,液晶显示器(IXD) 或阴极射线管(CRT))。该系统还可以包括字母数字输入设备1810(例如,键盘)、以及用于 接收内容源和传输内容存储的网络接口设备1812。
[0247] 磁盘存储器1806可以包括机器可读介质,其中在该机器可读介质上,可以存储体 现本申请所描述的方法或功能中的任何一个或多个的一个或多个指令集(例如,软件)。这 些指令还可以完全地或者至少部分地位于存储器1804中、和/或在系统执行期间位于摄取 处理器1802中,其中存储器1804和摄取处理器1802也构成机器可读介质。
[0248] 如图19中所示,可以根据各种实施例,将客户端系统实现成硬件和软件组件的组 合。客户端系统可以包括能被执行以使系统执行本申请所讨论的方法中的任何一个或多个 的指令集。可以将该系统实现成具有计算机形式的特定机器。该系统可以是服务器计算机、 个人计算机(PC)、或者能够执行指令集(顺序的或者其它方式)的任何系统,其中该指令集 规定要由该系统采取的动作。此外,虽然仅示出了单个系统,但是术语"系统"还应当包括: 单独或者联合地执行一个(或多个)指令集以执行本申请所描述的方法中的任何一个或多 个的任何系统集合。
[0249] 客户端系统可以包括客户端处理器1902(例如,中央处理单元(CPU))、存储器 1904以及磁盘存储1906,其中存储器1904可以在执行期间存储程序代码,所有这些部件通 过总线1900进行相互通信。该系统还可以包括视频显示单元1908(例如,液晶显示器(IXD) 或者阴极射线管(CRT))。该系统还可以包括字母数字输入设备1910(例如,键盘)、以及用 于发送请求和接收响应的网络接口设备1912。
[0250] 磁盘存储1906可以包括机器可读介质,其中在该机器可读介质上可以存储体现 本申请所描述的方法或功能中的任何一个或多个的一个或多个指令集(例如,软件)。这些 指令还可以完全地或者至少部分地位于存储器1904中、和/或在由系统对其执行期间位于 客户端处理器1902中,其中存储器1904和客户端处理器1902也构成机器可读介质。
[0251] 特定实施例的示例
[0252] 使用在[RaptorQ-RFC-6330]中详细说明的RaptorQ FEC方案,在该节的针对通用 对象传输的详细说明的FEC方案中,示出了一个特定的实施例。可以将UOSI FEC有效载荷 ID与[RaptorQ-RFC-6330]中的RaptorQ FEC方案一起使用(本申请称为"UOD-RaptorQFEC 方案"),以便提供简化的和增强的对象传输能力。具体而言,提供了用于基本对象传输的 更灵活和更简单支持,此外还提供了针对不等错误保护(UEP)对象传输、针对绑定的对象 传输和针对UEP和绑定的对象传输的组合的支持。应当理解的是,可以使用适当的硬件和 /或软件来实现通信设备之间的"UOD-RaptorQ FEC方案"。
[0253] FEC有效载荷ID格式是如图2中所示的4字节字段,其中在该特定的实现中,32 比特、无符号整数的通用文件符号标识符(UFSI),通过也是32比特、无符号整数的通用对 象符号标识符(U0SI)来概括。该U0SI是非负数整数,其结合FEC0TI来用于标识在携带该 有效载荷ID的分组中包含的经编码的符号。
[0254] 为了传输单一对象、或者多个对象、或者被划分成具有不同优先级的部分的单一 对象、或者这些的任意组合,FEC 0ΤΙ是如下所述的。应当注意的是,对于传输的每一个对 象,FEC 0ΤΙ可以与RaptorQ FEC方案所指定的相同。一种传输可以包括d个对象,其中d是 某个正整数。每一个对象可以包括同一文件的不同部分、或者不同的文件、或者其的组合。 对象i的大小Fi和用于对象i的经编码的符号的大小?\之间的关系,可以用于确定对象i 在该传输中的优先级。
[0255] 图20示出了一种通用FEC ΟΤΙ字段的示例。如本申请所使用的,对于传送的多个 (d个)对象,存在8比特、无符号的整数,所示出的示例对应于d = 2。缺省值可以是d = 1。其它子字段包括:对于这d个对象中的每一个(即,i = 1,. . .,d),特定于对象i的通用 FEC 0ΤΙ元素包括:用于符号大小的16比特无符号整数,其是小于216的正整数(其以字 节为单位来指示用于对象i的符号的大小);用于对象i的传送长度匕的40比特无符号整 数,其是至多的非负整数,以字节为单位来指示对象i的传送长度。提供了适当的填充。
[0256] 与通用FEC 0ΤΙ字段相比,可以存在特定于方案的FEC 0ΤΙ元素,例如,如图21中 所示。如图所示,在该示例中,特定于方案的FEC 0ΤΙ元素包括:符号对齐参数(Α1) (8比特, 无符号整数)、用于每一个对象的特定于方案的FEC 0ΤΙ元素(其包括用于对象i的源块的 数量Zi (12比特,无符号整数))、以及用于对象i的子块的数量队。该编码的特定于方案的 对象传输信息是(l+3*d)字节字段。图21中的示例对应于d = 2。转而该编码的FEC 0ΤΙ 可以是(2+10*d)字节字段,其包括编码的通用FEC ΟΤΙ和编码的特定于方案的FEC ΟΤΙ元 素的串联。
[0257] 使用编码的FEC 0ΤΙ的内容传输可以涉及:使用UOD-RaptorQ FEC方案和利用 UOD-RaptorQ FEC方案进行对象传输的内容传输协议(" CDP "),在系统的设备、计算机、程序 之间进行信息的交换。CDP应当向编码器设备和解码器设备提供d、A1,以及对于每一个对 象,F^Ti (A1的倍数)A和队。向编码器提供通过i进行索引的各个对象。使用UOD-RaptorQ 编码器方案的编码器设备将提供CDP,针对要发送的每一个分组,该分组的U0SI和用于这d 个对象的经编码的符号。
[0258] 参数选择的示例
[0259] 在一个示例中,可以使用在[RaptorQ-RFC-6330]的第4. 3节中所描述的示例性参 数推导,其独立地应用于d个对象中的每一个。举例而言,A1 = 4字节,SS = 8 (其意味着 每一个子符号至少是SS*A1 = 32字节),对象i的Ti优选地是至少SS*A1字节,其中是 A1的倍数,而每一个编码分组的有效载荷大小优选地具有至少T的大小,其中T是?\的关 于 i = 1,. . .,d 之和。
[0260] 对于源块构造来说,在[RaptorQ-RFC-6330]的第4. 4. 1节点中的过程可以独立地 应用于d个对象中的每一个。
[0261] 对于编码分组构造来说,每一个编码分组都包含U0SI和用于d个对象的经编码 的符号。为了实现[RaptorQ-RFC-6330]的RaptorQ FEC方案所使用的FEC有效载荷ID的 (SBN,ESI)格式,和UOD-RaptorQ FEC方案所使用的U0SI格式之间的兼容性,其可以是特定 的格式。例如,对于每一个对象,从U0SI值C到针对对象i的相应(SBN,ESI)值(A, B)的映 射,可以是B = floor (C/ZJ,A = C - 类似地,对于每一个对象,从对象i的(SBN,ESI) 值(A,B)到相应的U0SI值C的映射,将是C = A+B*Zit)
[0262] 对于每一个对象i = 1,. . .,d而言,从0到KTi-1的U0SI值以源块交织的顺序来 标识源块中的对象i的源符号,其中Κ?\ = ceil汜/1\)。从Κ?\向上的U0SI值标识使用 RaptorQ编码器,根据对象i的源符号所生成的修复符号。
[0263] 编码分组可以包含源符号、修复符号或者源符号和修复符号的组合。一个分组可 以包含来自于对象i的同一源块的任意数量的符号。当用于对象i的源分组中的最后源符 号包括为了 FEC编码目的所增加的填充字节时,这些字节应当包括在该分组中,使得在每 一个分组中只包括完整的符号。
[0264] 在每一个编码分组中携带的通用对象符号标识符(C),是在该分组中携带的针对 每一个对象的第一经编码的符号的U0SI。该分组中针对各个对象的后续经编码的符号,具 有串行顺序的、编号为从C+1到C+G-1的U0SI,其中是该分组中针对各个对象的经编码的符 号的数量。在其它实施例中,可以针对每一个对象i,存在被指定成FEC 0ΤΙ信息的一部分 的基U0SI仏,在该情况下,在该分组中用于对象i的第一符号的U0SI是C+Uit)
[0265] 在优选的实现中,在每一个编码分组中,对应于d个对象中的每一个,存在一个经 编码的符号。在优选的实现中,根据下面的过程来生成和发送编码分组。对于每一个U0SI 值C = 0, 1,2, 3,...,编码器如下所述地生成和发送编码分组,其中该编码分组的FEC有效 载荷ID的值被设置为U0SI值(C),对于每一个对象i (其中i = 1,. . .,d),编码器确定与 U0SI 值 C 相对应的(SBN,ESI)值 %,Β),根据 RaptorQ FEC 方案[RaptorQ-RFC-6330]的 过程,生成与对象i的(SBN,ESI)值(A。相对应的大小为凡的经编码的符号Ερ将经编 码的符号加到编码分组的有效载荷中,并发送该编码分组。应当注意,不需要接收机 知道编码分组的总数。
[0266] 单播源服备器和广播修复服备器
[0267] 在本节所描述的大部分实施例中,以广播方式来发送修复符号,响应于针对源符 号的某些集合的UE请求,以单播方式来发送源符号。存在一些其它实施例,在该节所描述 的一些以及在本申请的其它地方所描述的一些(其中至少一些源符号以广播方式进行发 送),还存在响应于UE请求,以单播方式来发送至少一些修复符号的一些实施例。
[0268] -种不例性广播文件传输系统是eMBMS文件传输系统。一种不例性单播文件传输 系统是具备HTTP字节范围请求能力的系统。但是,可以使用只能请求并提供整个文件的单 播系统,但将会丧失很多利益。本申请的更早部分示出了一些示例系统。
[0269] 在该节的示例中,在广播会话中发送修复数据,在单播修复会话中只发送源数据。 单播修复请求是针对于原始文件的一部分的标准HTTP1. 1字节范围请求。由于广播会话只 具有修复符号,因此在两个会话之间不具有重叠的数据。应当注意的是,在一些实现中,先 前描述的系统和该节的系统可以共存和/或进行组合。
[0270] 如上面所解释的,UE(例如,诸如移动用户设备之类的终端用户设备)可以被配置 为:确定该UE丢失了哪些源符号,其转换自源块编号,将丢失的源符号的符号ID编码成标 准HTTP1. 1字节范围请求,并进行这些请求。
[0271] 通过在广播会话中发送修复符号,单播修复服务器只需要该文件的原始拷贝,这 些请求是针对于连续范围的源符号的简单请求,或者是针对于连续的更大范围的连续字节 的请求,而不是针对于各个符号的请求或者针对于多个较小范围的字节的请求。UE可以基 于简单地统计接收到多少符号和需要多少符号,或者基于运行解码调度来确定例如源符号 的前缀数量(其允许源块的解码)、或者允许源子块的解码的源子符号的前缀数量、或者允 许子块或者源块的解码的前缀字节范围大小,来确定要请求多少符号。应当注意,在该上下 文和本申请的其它上下文中,"前缀"意味着指定"与一个子块相对应的文件的部分的前缀" 或者"与一个源块相对应的文件的部分的前缀",即,"前缀"可以不指代整个文件的前缀,而 是指代该文件的有关部分的前缀,其中该有关部分可以根据使用"前缀"的上下文来进行推 断。
[0272] 当不使用子块划分时,可以将针对一个源块的连续源符号的请求,转换成针对一 个连续的字节序列的请求。当使用子块划分时,可以将针对一个子块的连续数量的源子符 号的请求,转换成针对该文件的连续的字节序列的请求。
[0273] 如本申请所解释的,UE可以根据针对一个子块的连续数量的源子符号的请求,来 导出在该文件中的字节范围请求。
[0274] 在一些实现中,不同的广播服务器具有不同的修复符号集,其或许是基于不同的 地理。这对于在广播传输期间从一个地理位置移动到另一个地理位置,以便确保不存在针 对同一设备的重复接收的UE来说是有益的。
[0275] UE在HTTP请求中请求一个子块(或者块,在不使用子块的情况下)的字节范围 前缀,极大地独立于其在广播会话中接收的修复子符号(符号,在不使用子块的情况下;下 面的括号也应用此含义),其仅取决于其在广播会话中接收到多少修复符号。对于一些编 码(例如,在IETF RFC5510中详细说明的Reed-Solomon编码),所请求的字节范围前缀可 以完全独立于在广播会话中接收的修复符号。对于其它编码(例如,在IETF RFC6330中详 细说明的RaptorQ编码),字节范围前缀的大小只很弱地取决于在广播会话中接收到哪些 修复符号。例如,如果在一个源子块中存在K个源子符号,并且接收到该子块的K-L个修复 子符号,则请求与前L个源子符号相对应的字节范围前缀,将允许以至少99%的概率进行 解码,请求L+1个子符号,将允许以至少99. 99%的概率进行解码,请求L+2个子符号,将允 许以至少99. 9999%的概率进行解码。是否进行解码可以是取决于用于解码的子符号的模 式,接收设备在进行该请求之前,确定具体的接收子符号序列是否允许进行解码,因此确定 要进行哪些请求以保证解码。因此,针对修复所请求的前缀的大小,可能只很弱地取决于在 广播会话中的接收子符号的模式。
[0276] 但是,为了简单起见,接收设备可以针对L+2个子符号进行请求,在该情况下,请 求大小独立于在广播会话中接收到哪些子符号,以接收潜在的2个冗余子符号的开销为代 价,以及以很小概率的不能进行解码为代价,即,为了恢复K个源子符号,总共接收K+2个子 符号,其中K-L个子符号来自于广播会话,L+2个子符号来自于该修复请求。独立于接收到 哪些数据,进行该大小和模式的请求的一些原因,仅取决于在广播会话中接收到多少数据, 其包括:
[0277] (a)UE请求可以是简单的,始终从源子块(块)的开始进行请求,每一个源子块 (块)至多一个字节范围请求(在一些情况下,如果在广播会话中接收到足够的修复子符号 (符号),那么不需要另外的HTTP请求)。
[0278] (b)UE可以在通过HTTP从修复服务器下载的同时,开始播出该子块(块)的内容, 转而一旦其下载了足够的内容,就可以使用通过广播已经接收的修复子符号来恢复该子块 的剩余部分(剩余子块的大小本质上是在广播会话中接收的针对该子块(块)的修复子符 号(符号)的大小)。
[0279] 甚至可能的情况是,接收机同时通过广播接收修复数据时,在同一时间尝试播放 该内容,通过HTTP下载足够的各个子块,直到与通过广播已经接收的内容相组合后,足够 用于对该子块的剩余部分进行解码和恢复。在该情况下,随着广播继续进行,随着UE通过 广播接收到针对所有子块(块)的越来越多的修复子符号(符号),针对每一个子块(块) 所需要下载的HTTP的量开始变得更小。
[0280] (c)由于UE正在请求源子块的前缀,针对于文件的一部分的UE请求之间的重叠 尽可能地高,例如,接收针对于一个源子块(块)的相同数量的修复子符号(符号)的两个 UE,针对该源子块(源块)准确地进行相同的字节范围请求,即使当接收到的修复符号的模 式是独立的,并且可以是完全不同的。
[0281] 当不同的UE从针对一个子块的广播会话接收到不同数量的修复子符号时,接收 到最小数量的修复子符号的UE,通常针对该源子块进行最大的前缀字节范围请求,来自于 其它UE的所有请求将是该请求的一个子集。因此,如果HTTP服务器已经取得和服务一个 UE针对一个子块(块)的字节范围请求,那么该HTTP服务器可以对该响应进行高速缓存, 使其可用于针对相同的子块(块)进行修复请求的下一个UE。与UE所请求的相比,HTTP 高速缓存的服务器可以主动地从上游服务器请求更大的字节范围,因此减少在该请求的大 小之外的数据变得可用的时间(如果存在来自相同UE或者其它UE针对超出当前请求之外 的数据部分的另外请求)。因此,如果一个UE从文件的有关部分,进行针对数据的前缀的请 求,那么当后续的UE从文件的相同有关部分,进行针对数据的更大前缀的请求时,HTTP高 速缓存服务器可能已经具有了该高速缓存,并能够立即使用数据的相应前缀对该请求进行 响应。
[0282] 如果HTTP修复服务器接收到针对重叠的字节范围的多个请求(例如,超过某个门 限),那么服务器还可以被配置为:决定将一个请求转发给请求该字节范围的数据的广播 的BMSC,以避免将这些单播信道冗余地装载到这些接收机。修复服务器只需要向每一个接 收机单播将不会由BMSC进行广播的源数据。BMSC可以将该字节范围请求转换到所需要的 必需的源符号,随后广播这些源符号,或者更佳的是,广播这些更多的新修复符号。这使终 端能够接收足够的非冗余符号,以便在很少装载到单播信道的情况下,对其文件进行修复。
[0283] 在一些情况下,有利的是,当UE准备播放与一个源块(子块)相关联的内容,UE只 针对该源块(子块)的源符号(子符号)进行单播请求,即,使用"流模式"进行请求。一种 原因在于:UE只请求其实际将要播放的内容的修复数据,如果由于某种原因,其不再播放 该内容中的一些,那么其不再请求针对该块(子块)的数据,以避免浪费该单播网络资源。
[0284] 例如,UE可以从中间位置处开始播放一个内容(文件),仅播放该内容的四分之 一。在该示例中,仅当该播放临近时,才进行这些请求,将单播网络资源减少到:如果在播放 之前为了恢复整个内容文件而进行单播修复请求时所需要的内容的大约四分之一。当然, 一旦接收到一个源块(子块)的足够的源符号(子符号),那么不需要该UE针对该源块(子 块),从单播修复服务器请求另外的数据。
[0285] 系统运营商可以从这些方法中受益。例如,可以使单播修复服务器的部署简化,并 且使费用更加的合理。此外,还消除了需要购买、部署和操作专用的修复服务器,而不是更 多的更便宜和更容易地依赖于部署和管理HTTP web服务器的需求。再举一个例子,运营商 可以部署一种服务,通过该服务,透明地捕获互联网内容文件,将针对其FEC修复数据广播 给UE,随后UE包括一些方法以便使用向其所广播的所接收的FEC修复数据,确定结合通过 广播所接收的FEC修复数据进行什么HTTP1. 1字节范围请求,以便使其能够恢复将要进行 播放的该文件的一部分,针对已经在现有的CDN中高速缓存的互联网可用的内容文件的一 部分(其不需要由运营商进行操作,也不是由运营商所必须产生的内容),通过互联网进行 适当的HTTP1. 1字节范围请求。
[0286] 通过这样操作,运营商可以提供有价值的服务,提供更佳的用户体验(这是由于 文件能更加可靠和更加快速地可用),同时减少传输这些文件所需要的在其网络上的整体 网络业务量(这是由于广播数据对于所有UE都是有用的,与通过针对各个UE的很多个别 单播连接来发送数据相比,在发送数据时占用更少的网络资源),同时运营商可以避免部署 任何单播修复服务器来支持其服务的费用,这是由于该内容已经可以从其它方所提供的标 准HTTP web服务器处可用,并且其用于支持单播修复。
[0287] 系统运营商还可以重新设定现有的HTTP web服务器的用途,生成新的服务机会, 例如截获和广播用于通过HTTP web服务器从其它内容提供商向UE传输的文件的修复符号。
[0288] 另外,该方法可以保存运营商网络带宽容量。该成本是在网络上发送的广播数据 的量,而利益则是所有UE的效益之和,其中这些UE都播放在本UE上接收的广播数据的量 的内容。这可以在运营商网络上提供更佳的用户体验,以及内容的更快速和更可靠传输。
[0289] 会话描述和MBMS下载传输协议(FLUTE)向客户端(S卩,UE)提供足够的信息,来 确定每一个文件的源块和经编码的符号结构。据此,客户端能够确定请求和使用哪些源符 号来恢复该文件。因此,MBMS客户端能够识别完成(文件的)源块的重建而所需要的源符 号的数量。
[0290] 当使用MBMS FEC方案时,如3GPP TS26. 346中所详细说明的,MBMS客户端可以在确 定所需要的另外的源符号时,考虑已经接收的修复符号。在该情况下,客户端应当识别(该 文件的)每一个源块数量(r),针对允许MBMS FEC解码器恢复该文件的该源块的前r个源 符号,进行修复请求。
[0291] 一旦识别出丢失的文件数据,MBMS客户端就向文件修复服务器发送一个或多个消 息,这些消息请求传输能恢复丢失的文件数据的数据。针对特定的MBMS传输的所有文件修 复请求和修复响应,可以使用HTTP协议在单一 TCP会话中发生。替代地,可以将字节范围 请求划分成不同的潜在重叠的HTTP/TCP连接、或者FTP连接、或者RTP连接等上的多个请 求。可以根据网络可用性,以及接收设备的繁忙程度以及其能力,按照非常慢或者高的比特 速率,来传输针对修复请求的响应。可以将修复请求路由到根据所选定的"serviceURI"来 解析得到的文件修复服务器IP地址。打开与服务器的TCP连接的时间,以及特定的MBMS 客户端的第一次修复请求,可以随机化在某个时间窗上,使得不是所有UE都同时地进行其 单播请求。
[0292] 当MBMS UE识别在修复请求中要请求的符号时,答复可以是所识别的相应符号,其 应当包括在该请求中所标识的有关源块的所有符号。当使用子块划分时,MBMS UE可以替代 地请求源子块的子符号。替代地,如本申请所描述的,可以进行字节范围请求,以请求符号 或者子符号。
[0293] MBMS UE可以将该方法与其它方法进行组合。例如,MBMS UE可以在广播会话中接收 数据,在不对原始源文件进行解交织或解码的情况下,将其存储在长期存贮器中,如在Luby VI中所描述的。响应于终端用户请求播放该源文件的一部分(例如,当源文件是视频文件 时),MBMS UE可以触发原始源文件的这些部分的解交织和解码。如果MBMS UE没有从广播会 话中接收到足够的数据,来恢复该原始源文件的被请求进行播放的部分,那么MBMS UE可以 针对终端用户请求进行播放的该源文件的有关部分,进行如本申请所描述的修复请求。因 此,仅当在广播会话中没有接收到足够的数据来恢复该部分时,MBMS UE才可以进行请求, 以接收针对某些子块或者源块的额外数据,按照或者接近终端用户期望播放源文件的一部 分(其与请求的子块或源块相交叉)的时间,才进行这些请求。该实施例将网络资源减到最 小,这是由于仅当终端用户请求播放这些部分时,才请求该源文件的这些部分的修复数据, 因此如果文件的一部分永远不被播放,那么就从不进行针对这些部分的修复请求。此外,该 实施例将从长期存贮器中读取数据,以及对该数据进行解交织和解码以便恢复子块或者源 块,而所需要的设备资源减到最小,这是由于仅当终端用户请求播放源文件的这些部分时, 才执行这些操作。
[0294] 替代地,当MBMS UE具有适当的网络连接和空闲容量来执行修复请求时,MBMS UE 可以针对没有从广播会话中接收到足够的数据来实现恢复的子块或者源块,执行修复请 求,随后MBMS UE除了存储从广播会话中接收的针对这些子块或源块的数据之外,还将该响 应数据存储到长期存贮器以便用于这些子块或源块的稍后恢复。当用户请求播放原始文件 的一部分时,MBMS UE可以从长期存贮器中读回从广播会话接收的被交织和经编码的数据 与来自于针对这些子块或源块的数据(其与用户请求的该文件的部分相交叉)的组合,恢 复这些子块或者源块,将其直接提供给视频播放器以用于播出。这种替代方式具有下面的 优点:当MBMS UE连接到适当的网络来进行修复请求和接收响应时,可以请求修复数据,而 当用户请求播放时,MBMS UE可能没有连接到适当的网络。此外,针对于用户对于播放的请 求的播放响应时间更小,这是由于在该设备上进行用户请求的时间,用于播放所需要的所 有数据都是本地存储的,而不是需要通过网络进行传输。
[0295] 再举一个例子,MBMS UE可以针对需要另外的数据以便进行恢复的所有子块或者 源块,来请求修复数据,并且恢复该文件的全部,将其存储在长期存贮器中以便稍后播放或 者使用。MBMS UE可以按照任何顺序,在任何时间点执行这些操作,S卩,在一些情况下,可以 在从广播会话接收到数据之前,对修复数据进行请求,例如,如果已知没有通过广播会话发 送足够的数据来完整地恢复该文件的这些子块或者源块,或者如果终端用户期望在广播会 话结束之前(并潜在地在该广播会话开始之前),就开始播放内容。
[0296] 在一些实施例中,存在着不执行FEC的UE (因此宁愿所有的源符号,而不需要修复 符号)。在这些情况下,UE将使用"无编码FEC",在广播会话和任何修复请求响应中接收源 符号,但由于多个不同的UE经历不同的丢失模式,所以进行不同的源符号修复请求,因此 这种方式不是可扩展的。
[0297] 在一些实施例中,修复广播会话在UE处使用如Luby VI中所示出的广播数据的部 分重新排序。这里,可以将使用如上所述的HTTP的单播修复服务的组合,与Luby VI中描述 的方法进行组合。可以将在广播传输中接收的符号/子符号,存储到如Luby VI中所描述的 闪存或其它存储器中。在一些情况下,优选的是,仅在广播会话中才发送修复符号,但在其 它情况下,优选的是,在广播会话中发送源符号中的至少一些(如果不是全部的话)。当通 过具有字节范围请求或者具有其它MBMS方法的HTTP,在修复服务中请求符号或者子符号 时,出现两种不同的可能性(这两者可以同时地使用) :
[0298] (1)可以使用在Luby VI中描述的方法,将从广播会话中接收的符号或者子符号写 入到闪存中,随后当要恢复源块或者子块时,可以使用在LubyVI中描述的方法,将来自于 广播会话的在闪存中存储的针对该源块或子块的符号或者子符号读入到RAM中。随后,可 以将其与通过HTTP接收并直接存储到RAM中的符号或子符号进行组合,使用这些符号或子 符号的组合,在RAM中对该源块或子块进行解码,转而可以直接提供所恢复的源块或子块 以用于播放。
[0299] (2)可以使用在Luby VI中描述的一些方法,将通过HTTP接收的符号或者子符 号写入到闪存中,对于通过广播会话接收的符号或者子符号执行相同的操作,随后在任何 时间点,可以通过将基于HTTP请求而存储在闪存中的源块或子块的符号或子符号,与来自 于广播会话的在闪存中存储的针对该源块或子块的符号或者子符号的组合,从闪存读入到 RAM中,来及时地恢复源块或者子块。
[0300] 在上面的实施例中,优选的是,通过广播会话接收的符号或者子符号,以及在修复 会话中接收的符号或者子符号,是极其不同的符号或者子符号集。
[0301] 图22示出了基本FLUTE文件传输。应当注意,FEC有效载荷ID可以替代地包括 本申请所描述的U0SI或U0FI。
[0302] 图23示出了基本FLUTE分组格式的一些部分。
[0303] 图24示出了在使用子块的发送方处发生的子块编码。如上所述,可以将一个文件 组织成一个或多个源块(在该示例中,组织成一个源块),并划分成一些子块,其中对这些 子块进行布置以便根据子符号来形成符号。
[0304] 图25示出了在使用子块的接收机处发生的子块解码。在一些情况下,在接收机处 进行存储之前,存在部分的重新排序。这可能是用的,例如,当在读取和写入之间的存储单 兀中,存在不对称时。
[0305] 图26示出了使用子块的文件传输。在典型的情况下,接收机在每一个子块中,观 察到相同的丢失模式。从传输的角度来看,一个文件可以是一个源块,每一个分组可以包含 一个符号。从解码的角度来看,对于所有子块来说,解码操作的调度可以是相同的,每一个 子块的子符号具有相同的丢失或者接收模式,接收机一次针对所有的子块来计算该调度。 随后,将解码操作的调度单独地应用于每一个子块,对子符号进行操作,并向所有子块应用 相同的调度。即使对很大的源块进行操作,解码器的CPU也可以很好地执行,其只使用很少 量的划伤RAM存储器,允许媒体的子块的访问和解码(当其被播放时)。
[0306] 图27示出了多个源块的处理的示例。在一些情况下,为了实现良好的网络效率, 以循环方式来发送这些符号,其中每一轮发送来自每一个源块的一个符号。在其它情况下, 为了更容易地客户端恢复或者端到端时延的原因,以顺序方式来发送这些符号,即,对于每 一个源块来说,以连续的顺序来发送所有符号,而不插入来自其它源块的符号。在所有情况 下,都可以使用子块划分。
[0307] 图28示出了使用FEC和FLUTE的工作流。在步骤1,对文件进行规定,以便在FLUTE 会话中进行携带。在步骤2,可以将该文件分割成一些块。根据FEC方案可以处理的最大尺 寸,来导出用于分段的需求。
[0308] 在步骤3,将FEC应用于一个块,每一个块被划分成K个相同大小的系统符号,生成 Ri+R2个修复FEC符号。在步骤4,1(+?个符号在广播传输上,通过FLUTE来发送,或者替代 地,使用UDP通过单播来发送,或者使用HTTP通过单播来发送。根据符号大小,每一个IP/ UDP/LCT分组携带一个或多个符号。在步骤5,接收机收集足够的分组,使得有K+δ个符 号可用于FEC解码。在一些实施例中,使用RaptorQ,S =2。但是,其它值也是可以的,例 如,δ =〇或者δ =〇.〇1*Κ。在步骤3中所生成的另外的R2个符号,可以提供给HTTP服 务器,以便为没有从步骤4中的传输接收到K+ δ个符号的接收机,提供基于HTTP的修复服 务。
[0309] 图29示出了上面所描述的广播/修复、单播/源配置。可以生成很大数量的修复 符号。为了成功地进行FEC解码,UE需要这些符号中的任何Κ+δ个。在所示出的实施例 中,每一个广播BM-SC发送一个文件的Ν个不同的Raptor修复符号,每一个BM-SC只发送 修复符号,即,ESI在范围{K,K+1,···}之中的那些符号。
[0310] 上面的实施例的一种优点在于:当UE在不同的BM-SC的覆盖区域之间漫游时,UE 可以使用来自不同BS-SC的符号,不用担心符号的重复接收,这允许更高效的FEC解码。UE 可以针对源符号,进行简单的修复请求(但这可能需要专用的修复请求服务器),但还可以 使用传统的HTTP web服务器(其中传统的HTTP web服务器只具有如在本申请的其它地方 所更详细描述的原始源文件),进行HTTP字节范围请求。这允许更加成本有效融合的互联 网/MBMS解决方案。
[0311] 图30示出了系统如何在MBMS承载上只广播修复符号,以及UE只请求一组连续的 源符号。通常,UE需要Κ+δ个符号来成功地对源块进行解码,但其通过MBMS承载只接收 到Κ+ δ -R个修复符号。为了恢复该源块,UE请求该源块的前R (或者Κ,当R>K时)个源符 号。它可以请求某些其它的R个源符号,但如果所有UE请求重叠的源符号集合,那么下游 高速缓存更可能能够将所请求的源符号从其本地的高速缓存传输到更多的接收机。
[0312] 这提供了在修复服务器处,实现简单和高效的高速缓存。由于通过广播信道只发 送修复符号,源块的源符号与UE已经接收的符号完全地不同。因此,修复服务器只需要存 储源块的源符号,不需要存储或者生成新的修复符号。这允许更简单的修复服务器,这种更 简单的修复服务器不需要实现FEC方案或者存储新的修复符号。
[0313] 可以对接收的符号进行简单的UE处理。UE只需要跟踪其接收到的修复符号的数 量,转而计算其需要的源符号的数量(R,当R小于或等于K时,或者K,当R大于K时)。UE 不需要跟踪哪些具体的源符号丢失了,并随后针对这些丢失的源符号来生成请求。
[0314] 另外,UE可以使用初始的ESI+(R的值),从修复服务器请求一组连续的源符号。 这使得这些请求保持非常简单和简短。此外,这还可以简化服务器响应构造,这是由于服务 器不需要获取和添加非连续的源符号集合。由于服务器只需要处理连续的源符号请求,因 此这在不使用"无编码"FEC方案的部署中非常有利。
[0315] 图31示出了当使用子块划分时,通过HTTP字节范围请求,使用单播修复。
[0316] 使用HTTP字节范围修复请求,UE可以针对同一源块的每一个子块,请求相同数量 的字节。当在广播会话中没有发送源符号时,可以在大部分环境中,使用每一个子块对应于 一个字节范围的请求。
[0317] 可以在"按需"的基础上,进行HTTP请求。当到达播放各个子块中的内容的时间 时,UE可以进行针对该子块的请求。UE可以在HTTP上请求和播放针对子块的内容,直到结 合接收机通过其它传输途径(例如,广播会话)接收的子符号,具有足够的子符号来解码和 恢复该子块为上。一旦对足够的子符号进行了接收和解码,UE就可以从本地恢复的子块开 始,无缝地继续进行播放。UE不需要针对从不被播放的子块,进行HTTP请求。
[0318] 字节范闱计算的示例
[0319] 接收机可以执行在本节中所解释的计算,以便确定要请求什么字节范围。这种计 算可以依赖于FEC结构。随后,接收机可以向服务器发送请求,以便获得该接收机基于字节 范围请求所需要的符号。
[0320] 在优选的实施例中,接收机使用FEC对象传输信息("FEC 0ΤΙ ")来认识其没有接 收到哪些符号。FEC 0ΤΙ确定文件的源块、子块、符号和子符号结构,其包括对象传输大小F、 对齐因子Α1、符号大小Τ、源块的数量Ζ、以及每一个源块的子块的数量Ν。接收机使用所有 这些信息以及FEC编码自身的属性,来准确地确定其需要多少符号和需要什么符号,其中 每一个符号或者子符号通过SBN、ESI和SuBN(分别为源块数量、经编码的符号标识符、子块 数量)来标识。在该实施例中,对源符号或者源子符号进行请求。接收机使用FEC 0ΤΙ信息 来计算该文件中与这些符号或子符号相对应的字节范围,如下面所描述的。
[0321] 当不使用子块划分时(即,当Ν = 1时),对于给定的SBN和ESI,接收机可以计算 (SBN,ESI)对所标识的相应源符号在该文件中的起始字节编号和结束字节编号。
[0322] 现在描述计算过程。这可以通过接收机中的一个程序或者接收机中的逻辑单元来 执行。使KT = ceil(F/T)是文件中的源符号的数量(向上取整到最近的整数,其中最后的 源符号可以被认为是用零填充成的一个完整源符号)。
[0323] 使 KL = ceil (KT/Z)并且 KS = floor (KT/Z),ZL = KT_KS*Z 并且 ZS = Z - ZL,其 中KL是前ZL个源块中的源符号的数量,KS是剩余的ZS个源块中的源符号的数量。
[0324] 对于每一个i =0,···,2-1,使&是源块i中的源符号的数量,S卩,& = KL,其中i =0,…,ZL-1,& = KS,其中 i = ZL,…,Z-l。
[0325] 随后,与SBN和ESI所标识的符号相关联的起始字节,可以如式2中所示地进行计 算。可以通过将T-1增加到起始字节位置,来计算该子符号的结束字节位置。
[0326]

【权利要求】
1. 一种使用耦合到分组交换网络的电子设备或系统来接收一个或多个数据对象的方 法,其中,所述一个或多个数据对象的源数据是通过分组中的经编码的符号表示的,使得所 述源数据可至少近似地根据所述经编码的符号恢复的,所述方法包括: a) 通过广播信道来接收经编码的符号,其中,经编码的符号的值是至少部分地根据源 符号的值来导出的; b) 确定将内容恢复到期望的完整程度所需要的额外符号的数量; c) 确定一个或多个文件的一个或多个字节范围的相应集合,其中,所述相应集合与恢 复所述内容所需要的额外符号相对应; d) 使用指向服务器的、指定所述一个或多个字节范围的相应集合的请求,生成针对至 少所述数量的额外符号的请求; e) 发送所述请求; f) 接收所请求的额外符号中的至少一些;以及 g) 在恢复所述内容时,使用所接收的额外符号结合通过所述广播信道接收的所述经编 码的符号。
2. 根据权利要求1所述的方法,其中,所述期望的完整程度是所述内容的完全恢复。
3. 根据权利要求1所述的方法,其中,所述请求是HTTP字节范围请求,并且多个请求中 的至少一个请求是HTTP字节范围请求、是针对于非连续字节范围。
4. 根据权利要求1所述的方法,其中,所述请求是针对于额外符号的连续集合。
5. 根据权利要求4所述的方法,其中,所述额外符号的连续集合以源符号起始,所述源 符号是针对远程地接收内容的多个设备中的每个设备的相同的起始符号。
6. 根据权利要求1所述的方法,其中,所述请求是单播HTTP字节范围请求。
7. 根据权利要求1所述的方法,其中,所述额外符号是源符号。
8. 根据权利要求1所述的方法,其中,所述额外符号是源符号和修复符号。
9. 根据权利要求1所述的方法,其中,所述经编码的符号全部是修复符号,并且所述额 外符号全部是源符号。
10. 根据权利要求1所述的方法,其中,所述源数据包括源符号的源块的有组织集合, 并且被进一步组织成源子块和源子符号的集合。
11. 根据权利要求10所述的方法,其中,所述请求是针对于子符号的字节范围。
12. 根据权利要求10所述的方法,其中,所述请求是针对于额外子符号的连续集合。
13. 根据权利要求12所述的方法,其中,所述连续集合以源子符号起始,所述源子符号 是针对远程地接收内容的多个设备中的每个设备的相同的起始子符号。
14. 根据权利要求10所述的方法,其中,所述请求是针对于源子符号。
15. 根据权利要求10所述的方法,其中,所述请求是针对于源子符号和修复子符号。
16. -种呈现远程接收的内容的设备,包括: 电子接口,其用于从广播信道接收数据; 用于通过所述广播信道来接收经编码的符号的逻辑单元,其中,经编码的符号的值是 至少部分地根据与要远程接收的所述内容相对应的源符号的值来导出的; 用于确定将内容恢复到期望的完整程度所需要的额外符号的数量的逻辑单元; 用于确定一个或多个文件的一个或多个字节范围的相应集合的逻辑单元,其中,所述 相应集合与恢复所述内容所需要的额外符号相对应; 用于使用指向服务器的、指定所述一个或多个字节范围的相应集合的请求,生成针对 至少所述数量的额外符号的请求的逻辑单元; 用于发送所述请求的接口; 用于接收所请求的额外符号中的至少一些的逻辑单元;以及 解码器,其在恢复所述内容时,使用所接收的额外符号结合通过所述广播信道接收的 所述经编码的符号。
17. 根据权利要求16所述的设备,其中,所述期望的完整程度是所述内容的完全恢复。
18. 根据权利要求16所述的设备,其中,所述请求是HTTP字节范围请求,并且多个请求 中的至少一个请求是HTTP字节范围请求、是针对于非连续字节范围。
19. 根据权利要求16所述的设备,其中,所述请求是针对于额外符号的连续集合。
20. 根据权利要求19所述的设备,其中,所述额外符号的连续集合以源符号起始,所述 源符号是针对远程地接收内容的多个设备中的每个设备的相同的起始符号。
21. 根据权利要求16所述的设备,其中,所述额外符号是源符号。
22. 根据权利要求16所述的设备,其中,所述额外符号是源符号和修复符号。
23. 根据权利要求16所述的设备,其中,所述经编码的符号全部是修复符号,并且所述 额外符号全部是源符号。
24. 根据权利要求16所述的设备,其中,所述源数据包括源符号的源块的有组织集合, 并且被进一步组织成源子块和源子符号的集合。
25. 根据权利要求16所述的设备,其中,所述请求是针对于子符号的字节范围。
26. 根据权利要求16所述的设备,其中,所述请求是针对于额外子符号的连续集合。
27. 根据权利要求26所述的设备,其中,所述连续集合以源子符号起始,所述源子符号 是针对远程地接收内容的多个设备中的每个设备的相同的起始子符号。
28. 根据权利要求16所述的设备,其中,所述请求是针对于源子符号。
29. 根据权利要求16所述的设备,其中,所述请求是针对于源子符号和修复子符号。
30. 根据权利要求16所述的设备,还包括: 用于从所述网络接收HTTP字节范围请求是否被文件服务器支持的指示的逻辑单元。
31. 根据权利要求16所述的设备,还包括: 用于从所述网络接收服务器支持哪些格式的指示的逻辑单元。
32. 根据权利要求31所述的设备,还包括: 用于从所述网络接收所述设备应当尝试从向其进行请求的服务器的优先次序的指示 的逻辑单元。
33. 根据权利要求16所述的设备,还包括: 用于当所述设备支持一种以上的请求格式时,接收指示要使用哪种请求格式的偏好选 择或要求的逻辑单元。
34. 根据权利要求16所述的设备,还包括: 用于接收仅向所述设备广播修复符号的指示的逻辑单元。
35. 根据权利要求34所述的设备,其中,当所述设备接收到所述指示时,所述设备被限 制于始终使用针对额外数据的前缀请求。
36. 根据权利要求16所述的设备,还包括: 用于接收要求所述设备使用针对额外数据的前缀请求的指示的逻辑单元。
37. 根据权利要求16所述的设备,还包括: 用于计算符号或者子符号的文件中的起始字节位置,以及所述符号或者所述子符号的 所述文件中的结束字节位置的逻辑单元。
38. -种通过分组交换网络从电子设备或系统传送一个或多个数据对象的方法,其中, 所述一个或多个数据对象的源数据是通过分组中的经编码的符号表示的,使得所述源数据 可至少近似地根据所述经编码的符号恢复的,所述方法包括: a) 如果所述源数据尚未被组织成源符号的源块,则将所述源数据组织成源符号的源块 的有组织集合; b) 生成经编码的符号,其中,经编码的符号的值是至少部分地根据源符号的值来导出 的,并且其中,是修复符号的经编码的符号具有用于进行与源块相对应的生成的范围; c) 以广播方式,将修复符号和/或源符号作为经编码的符号提供给目的设备,其中,所 述广播为目的设备确定所广播的数据的符号和块结构提供足够的信息, 其中,所述足够的信息至少包括:将所述源符号的源块的有组织集合中的源符号映射 到可用于向支持文件请求与字节范围请求的服务器进行字节范围请求的字节范围的信息。
39. 根据权利要求38所述的方法,还包括: d) 在所述目的设备处,确定哪些源符号是不可根据所接收的广播符号来解码的; e) 在所述目的设备处,确定可使用具有字节范围修饰符的文件请求来请求的文件的一 个或多个字节范围的集合;以及 f) 使用所述字节范围修饰符进行所述文件请求。
40. 根据权利要求38所述的方法,其中,所述文件请求是包括URL和字节范围的HTTP 客户端请求。
41. 根据权利要求40所述的方法,其中,所述字节范围在被请求的文件的起始处开始。
42. 根据权利要求38所述的方法,还包括: d) 根据接收的请求,确定所接收的请求是否是响应于用于针对源自于广播过程的丢失 的修复符号的恢复的修复过程; e) 根据所接收的请求,确定所接收的请求是否是响应于来自与广播过程无关的客户端 的直接请求;以及 f) 记录确定结果。
43. 根据权利要求42所述的方法,其中,通过读取在所接收的请求中使用的URL的全部 或者一部分,来执行确定。
44. 根据权利要求38所述的方法,其中,所述源符号的源块的有组织集合被进一步组 织成源子块和源子符号的集合。
45. -种使用耦合到分组交换网络的电子设备或系统来接收一个或多个数据对象的非 暂时性计算机程序产品,其中,所述一个或多个数据对象的源数据是通过分组中的经编码 的符号表示的,使得所述源数据可至少近似地根据所述经编码的符号恢复的,所述产品包 括: a)用于通过广播信道来接收经编码的符号的程序代码,其中,经编码的符号的值是至 少部分地根据源符号的值来导出的; b)用于确定将内容恢复到期望的完整程度所需要的额外符号的数量的程序代码; C)用于确定一个或多个文件的一个或多个字节范围的相应集合的程序代码,其中,所 述相应集合与恢复所述内容所需要的额外符号相对应; d) 用于使用指向服务器的、指定所述一个或多个字节范围的相应集合的请求,生成针 对至少所述数量的额外符号的请求的程序代码; e) 用于向所述服务器发送所述请求的程序代码; f) 用于接收所请求的额外符号中的至少一些的程序代码;以及 g) 用于使用所接收的额外符号结合通过所述广播信道接收的所述经编码的符号,来恢 复所述内容的程序代码。
46. 根据权利要求45所述的产品,其中,所述期望的完整程度是所述内容的完全恢复。
47. 根据权利要求45所述的产品,其中,所述请求是HTTP字节范围请求,并且多个请求 中的至少一个请求是HTTP字节范围请求、是针对于非连续字节范围。
48. 根据权利要求45所述的产品,其中,所述请求是针对于额外符号的连续集合。
49. 根据权利要求48所述的产品,其中,所述额外符号的连续集合以源符号起始,所述 源符号是针对远程地接收内容的多个设备中的每个设备的相同的起始符号。
50. 根据权利要求45所述的产品,其中,所述经编码的符号全部是修复符号,并且所述 额外符号全部是源符号。
51. 根据权利要求45所述的产品,其中,所述源数据包括源符号的源块的有组织集合, 并且被进一步组织成源子块和源子符号的集合。
52. 根据权利要求51所述的产品,其中,所述请求是针对于子符号的字节范围。
53. 根据权利要求53所述的产品,其中,所述连续集合以源子符号起始,所述源子符号 是针对远程地接收内容的多个设备中的每个设备的相同的起始子符号。
【文档编号】H04L29/08GK104067594SQ201280062414
【公开日】2014年9月24日 申请日期:2012年11月1日 优先权日:2011年11月1日
【发明者】M·G·卢比, N·K·利昂, R·A·戈尔米, T·施托克哈默 申请人:高通股份有限公司
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1