用于数据修复的方法和装置

摘要

本发明涉及一种用于在能够进行一对多传输的系统内进行数据修复的方法。该方法包括从发送器向至少一个接收器传输数据以及提供各种发送器驱动的或接收器驱动的丢失数据修复方法。

权利要求

1.一种用于在能够进行一对多传输的系统内进行数据修复的方法，所述方法包括：从发送器向至少一个接收器以一对多的方式传输数据；

提供发送器驱动的或接收器驱动的丢失数据修复，该丢失数据涉及在该接收器丢失的数据，其中发送器驱动的和接收器驱动的修复包括从所述接收器向所述发送器发送修复请求，并且其中所述方法还包括：在适合的时间内分布与修复有关的消息传递以避免拥塞。

2.根据权利要求1所述的方法，其中修复在修复会话中实施，该修复会话包括下面的一项：重传丢失的全部数据；

仅重传丢失数据的一部分；以及

整体上重复原始的传输。

3.根据权利要求1所述的方法，其中将从发送器向接收器传输的错误率参数作为请求丢失数据修复中的阈值使用。

4.根据权利要求3所述的方法，其中所述错误率参数被用来在时间和/或数据窗内计算所述阈值。

5.根据权利要求1所述的方法，其中该方法包括向接收器指示会话或会话的一部分将以点对多点的方式进行重传。

6.根据权利要求5所述的方法，其中所述指示借助于点对多点修复令牌来实施。

7.根据权利要求1所述的方法，其中所述方法包括生成将从接收器发往发送器的随机或伪随机时间离散的修复请求。

8.根据权利要求7所述的方法，其中该方法提供相对时间段上统计的均匀分布。

9.根据权利要求1所述的方法，其中该方法包括使用接收器角色。

10.根据权利要求9所述的方法，其中一个或多个该角色包括由偏移时间以及随机时间段给出的补偿时间。

11.根据权利要求9所述的方法，其中一个或多个该角色包括标记持有者行为。

12.根据权利要求1所述的方法，其中该方法包括通过预配置在发送器和接收器之间共享时间参数和/或数据参数和/或错误参数。

13.根据权利要求1所述的方法，其中该方法包括在接收到修复请求之后，从服务器向接收器指示修复将在稍后执行。

14.根据权利要求1所述的方法，其中该方法包括在不同修复方法之间做出优先选择。

15.根据权利要求14所述的方法，其中所述方法包括首先开始点对多点修复，然后进行点对点修复。

16.根据权利要求1所述的方法，其中该方法包括修复会话/信令的起始点的使用，所述起始点从这样的组中选择，该组包括会话的结束、对象结束、对象阈值以及会话组的结束。

17.根据权利要求1所述的方法，其中该方法包括延迟发送接收器处的修复请求。

18.根据权利要求1所述的方法，其中该修复请求延迟预定的时间量。

19.根据权利要求1所述的方法，其中仅当该接收器发起使用掉该数据的需求时才执行修复请求。

20.根据权利要求1所述的方法，其中提供了最大修复可用时间。

21.根据权利要求19所述的方法，其中该方法还包括考虑数据流中第一次丢失的位置。

22.根据权利要求1所述的方法，其中在丢失数据修复中计算和使用恢复时间。

23.根据权利要求1所述的方法，其中在初始多播/广播传输结束前请求和/或开始独立的修复会话。

24.根据权利要求1所述的方法，其中该方法包括计算在请求修复之前要等待的修复请求抑制时间。

25.一种用于数据修复的装置，该装置包括：用于接收由发送器以一对多方式所传输的数据的装置；

用于发送器驱动的或接收器驱动的丢失数据修复的装置，该丢失数据涉及在接收器设备丢失的数据；

用于向该发送器发送修复请求的装置；以及用于在适合的时间内分布与修复有关的消息传递以避免拥塞的装置。

26.一种用于数据修复的装置，该装置包括：用于以一对多方式向至少一个接收器传输数据的装置；

用于发送器驱动的或接收器驱动的丢失数据修复的装置，该丢失数据涉及在该接收器丢失的数据；

用于从该接收器接收修复请求的装置；以及用于在适合的时间内分布与修复有关的消息传递以避免拥塞的装置。

27.一种用于数据修复的系统，该系统包括：用于以一对多方式从发送器设备，经网络，向至少一个接收器设备传输数据的装置；

用于提供发送器驱动的或接收器驱动的丢失数据修复的装置，该丢失数据涉及在该接收器设备丢失的数据；

用于从该接收器向该发送器发送修复请求的装置；以及用于在适合的时间内分布与修复有关的消息传递以避免拥塞的装置。

说明书

用于数据修复的方法和装置

技术领域

[0001] 本发明一般地涉及多播以及广播传输技术以及服务，即具有至少一个数据源(或发送器)和至少一个接收器的服务。

[0002] 背景技术

[0003] 对于例如IP多播、IP数据广播(IPDC)以及多媒体广播/多播服务(MBMS)的系统上的一对多(即点到多点)的服务，文件分发(或不连续媒体分发或文件下载)是一种重要的服务。用于在例如文件传送协议(FTP)以及超文本传送协议(HTTP)的点对点协议上分发文件的许多特征对于一对多的方案来说存在问题。特别地，文件的可靠分发—即文件的有保证地分发—使用类似于例如传输控制协议TCP的一对一(即点对点)确认(ACK)协议是不可行的。

[0004] 互联网工程任务组(IETF)的可靠多播传输(RMT)工作组正处于对两类错误弹性多播传输协议进行标准化的过程中。在第一类中，通过使用(主动)前向纠错(FEC)来实现可靠性，即通过发送一定数量的能够帮助接收器重建错误数据的冗余数据来实现。在第二类中，使用接收器反馈以便实现可靠的多播传输。异步分层编码(ALC，RFC3450)是属于所述第一类的一种协议实例，而面向NACK的可靠多播(NORM)协议给出了所述第二类的一个例子。ALC以及NORM协议的细节在由IETF工作组筹备，题目为“AsychronousLayered Coding(ALC)Protocol Instantiation”(IETF RFC 3450)以及“NACK-oriented Multicast Protocol”(因特网草案)的出版物中得到更为详细地讨论。将这些出版物的内容通过参考完全并入到这里。

[0005] 能够使用这些协议的接入网络包括但不限于无线接入网络，例如通用移动电信服务(UMTS)系统的无线接入网络、无线局域网络 (WLAN)、地面数字视频广播(DVB-T)网络以及卫星数字视频广播(DVB-S)网络。

[0006] 简而言之，ALC协议是允许接收器对破坏的或未接收到的一个或多个分组进行重建的一种主动的基于FEC的方案。ALC协议在多个信道上使用FEC编码，允许发送器以多个速率(信道)向可能不同类的接收器发送数据。另外，ALC协议使用拥塞控制机制来维持不同信道上的不同速率。

[0007] 由于不需要上行链路信令，所以ALC协议在用户数方面是大规模可扩展的。因此，任何量的附加接收器不会确实增加对系统的需求。但是，ALC协议由于接收没得到保证而并非100％可靠，因此通常可被描述为鲁棒的而并非可靠的。

[0008] 而NORM规定使用否定的确认(NACK)消息以便以信号传送期望到达接收器的哪些数据分组(或另外定义为“数据块”)没有在接收器接收到(或没有正确地接收)。换句话说，接收器使用NACK消息向发送器指示所传输分组的遗失或损坏。因此，在数据传输中“丢失”了一些数据块的接收器能够向发送器发送NACK消息，要求发送器重传丢失的一个或多个数据块。NORM协议还可选地允许使用分组级的FEC编码以便主动的鲁棒传输。 [0009] 单向传输上的文件分发(FLUTE)是一种一对多的传输协议，该协议建立于FEC(RFC 3452)和ALC建构块之上。其旨在单向系统上从一个或多个发送器到一个或多个接收器的文件分发。该协议具有使其适于无线点对多点(多播/广播)系统的特殊作用。FLUTE协议的细节在由上述的IETF工作组筹备的，题目为“FLUTE-FileDelivery over Unidirectional Transport”(因特网草案)的出版物中得到更为详细地讨论。这些出版物的内容通过参考完全并入到这里。

[0010] NACK消息通常并非是NORM所特有的，但它们也能够连同例如FLUTE的其他协议或系统一起使用。ACK是一种接收器在接收到一个或多个数据分组之后发送的响应消息，以确认它们已被正确地接收。NACK是一种接收器向发送器发送的与当前/曾经期望到达 但并未被接收到的分组有关的响应。

[0011] 当处于多播或广播环境中时，数据传输以一对多的方式发生。如果该传输并非无差错，并且不同的接收器遭受不同的错误率(例如在MBMS中不同小区的用户可能经历不同的信号质量，并因此经历不同的错误率)，则存在提供增强的数据可靠性的问题。这能够通过使用FEC和/或通过使用修复会话来解决。

[0012] FEC向所传输的数据提供一定量的冗余，以便允许某一程度的错误弹性使得接收器重建所传输的数据。但是FEC的一个问题是它通常不提供无差错的错误恢复，或其以数据冗余的高度使用为代价来提供全面的错误恢复，这就增加了信道的带宽需求。 [0013] 修复(在接收器和发送器之间的)会话能够被用于补充FEC(以减少或消除剩余信道的错误率)，或能够作为错误恢复的唯一方法而单独使用。修复会话能够使用独立的会话在点对点的信道上发生。在这种情况下，在该多播/广播传输期间已丢失一些数据的所有接收器，向该发送器发送NACK请求以请求所述丢失分组的重传。但是，如果所有接收器丢失至少一个数据分组，则所有接收器将同时与发送器建立点对点的连接，这将导致反馈内爆，即该网络中的拥塞(在上行链路方向由于大量NACK以及在下行链路方向由于大量的并发重传输和网络连接请求)以及该发送器的过载。当考虑例如数千的用户时，这种情况是至关重要的，正如可能在MBMS网络中出现的情况。

发明内容

[0014] 本发明的实施方式提供用于广播/多播(一对多)会话的可扩展和有效的修复。 [0015] 根据本发明的第一个方面，提供了一种用于在能够进行一对多传输的系统内进行数据修复的方法，该方法包括：

[0016] 从发送器向至少一个接收器传输数据；

[0017] 提供发送器驱动的或接收器驱动的丢失数据修复，该丢失数据涉 及在接收器丢失的数据。

[0018] 术语“一对多传输”在本申请的上下文中被认为意思是指从至少一个发送器到多于一个的接收器的任何传输。因此，此处术语“一对多”能够被解释为意思是指“一对多于一个”。术语“丢失数据”被认为意思是指接收器根本没有接收到的数据以及不正确地接收的数据。

[0019] 根据本发明的第二个方面，提供了一种用于在能够进行一对多传输的系统中进行数据修复的接收器设备，该接收器设备包括：

[0020] 用于接收发送器所传输的数据的装置；以及

[0021] 用于发送器驱动的或接收器驱动的丢失数据修复的装置，该丢失数据涉及在接收器设备丢失的数据。

[0022] 根据本发明的第三个方面，提供了一种用于在能够进行一对多传输的系统中进行数据修复的发送器设备，该发送器设备包括：

[0023] 用于向至少一个接收器传输数据的装置；以及

[0024] 用于发送器驱动的或接收器驱动的丢失数据修复的装置，该丢失数据涉及在接收器丢失的数据。

[0025] 根据本发明的第四个方面，提供了一种能够进行一对多传输的系统，该系统包括发送器设备、网络以及至少一个接收器设备，该系统包括：

[0026] 用于从所述发送器设备经由所述网络向所述至少一个接收器设备传输数据的装置；以及

[0027] 用于提供发送器驱动的或接收器驱动的丢失数据修复的装置，该丢失数据涉及在接收器设备丢失的数据。

[0028] 根据本发明的第五个方面，提供了一种在接收器设备中可执行的用于在能够进行一对多传输的系统中进行数据修复的软件应用程序，该软件应用程序包括： [0029] 用于使该接收器设备接收由发送器所传输的数据的程序代码；以及 [0030] 用于发送器驱动的或接收器驱动的丢失数据修复的程序代码，该 丢失数据涉及在接收器设备丢失的数据。

[0031] 根据本发明的第六个方面，提供了一种在发送器设备中可执行的用于在能够进行一对多传输的系统中进行数据修复的软件应用程序，该软件应用程序包括： [0032] 用于使该发送器设备向至少一个接收器传输数据的程序代码；以及 [0033] 用于发送器驱动的或接收器驱动的丢失数据修复的程序代码，该丢失数据涉及在接收器丢失的数据。

[0034] 该软件应用程序可以是计算机程序产品，包括存储于例如存储器的介质上的程序代码。

[0035] 从属权利要求涉及本发明的实施方式。包含在涉及本发明的特定方面的从属权利要求中的主题也可应用于本发明的其他方面。

附图说明

[0036] 现在将通过参考以下附图，以例子的方式描述本发明的实施方式，其中： [0037] 图1A示出了根据本发明的一个实施方式的一对多的数据传输方案； [0038] 图1B示出了根据本发明的实施方式的不同的丢失数据的修复方法； [0039] 图2A示出了根据本发明的一个实施方式的简化的协议架构；

[0040] 图2B示出了根据本发明的另一个实施方式的简化的协议架构； [0041] 图3示出了根据本发明的一个实施方式的系统和接收器设备的细节； [0042] 图4示出了根据本发明的一个实施方式的发送器设备；以及

[0043] 图5-12示出了本发明的各种实施方式。

具体实施方式

[0044] 包含于本专利申请前序部分的主题可以被用于支持详细的描述。 在下文中，将单向传输上的文件分发(FLUTE)协议作为一个例子使用而非意在将本发明限于仅涉及FLUTE。其它任何能够实现一对多多播或广播的文件分发的合适协议也可在此应用。 [0045] 提交于2003年12月24日，题目为“AN APPARATUS，SYSTEM，METHOD AND COMPUTER PROGRAM PRODUCT FOR RELIABLEMULTICAST TRANSPORT OF DATA PACKETS”的美国专利申请(序列号XX/XXX，XXX)与本申请具有相同的受让人，该申请给出了用于数据分组的可靠多播传输的方法。该申请的内容通过参考全部并入到这里。

[0046] 提交于2004年2月13日，题目为“IDENTIFICATION ANDRE-TRANSMISSION OF MISSING PARTS”的美国专利申请(序列号XX/XXX，XXX)与本申请具有相同的受让人，该申请给出了用于在能够实现一对多传输的系统内标识以及重传丢失数据的方法。该申请的内容也通过参考全部并入到这里。

[0047] 图1A示出了根据本发明实施方式的一对多数据传输方案。发送器设备10是服务器、基于IP的设备、DVB设备、GPRS(或UMTS)设备或可以使用例如ALC机制和/或FEC机制的主动前向纠错的类似设备，该发送器设备10用于以一对多的方式向接收器设备20发送多播数据块(或分组)。每个接收器设备20向发送器设备10发送与丢失块(未被接收或接收不正确的块)有关的否定应答NACK消息(或请求)。响应于该一个或多个NACK消息，该发送器设备10通常在FLUTE会话(与为原始传输所建立的原始FLUTE会话相同的会话，或后续的FLUTE会话)中向该接收器设备20重传丢失的块。可选地，使用除了FLUTE的另一种协议的会话可以被使用。在本申请的上下文中，重传会话被称为修复会话。 [0048] 数据作为对象从发送器10向一个或多个接收器20传送。举例而言，文件、JPEG图像、文件片段都是对象。会话建立于发送器设备10和一个或多个接收器设备20之间，用于文件(或数据)分发。单个的会话可以包括对单个对象或多个对象的传输。不同的标识符被 用于标识该对象以及会话。

[0049] 每个数据块具有标识每个块的称为源块号(SBN)或类似的号码。块通过一组编码符号来代表。而编码符号标识符(ESI)或类似号码指示数据分组(块)的净荷中所携带的编码符号如何从上述对象(例如文件)中产生。

[0050] 图1B示出了根据本发明的实施方式的不同丢失数据的修复方法。丢失数据的修复能够通过使用建立在该发送器10和该接收器20之间的点对点修复会话或通过使用该发送器10和多于一个的接收器20之间的点对多点会话来执行。在修复会话中丢失数据的全部或部分(取决于情况)从该发送器10向一个或多个接收器20进行重传，或可以重复整个传输。修复通过原始发送器10起作用，或通过与该原始服务器连接并且被配置成用于缓冲该传输数据/信息的“第三方服务器”或修复服务器(或仅为简单的独立服务器(未示出))而起作用。这种服务器可以例如与该原始发送器(例如MBMS(多媒体广播/多播服务))服务器放在一处，也称为BM-SC(广播多播-服务中心)，或者例如是UMTS运营商的网络中的一个独立服务器。

[0051] 通常而言，在本发明的实施方式中，FLUTE或具有除FLUTE以外的方法的独立修复会话能够用于丢失数据的修复，这些方法例如具有适合的基础协议的HTTP、SMS、FTP、SAP、GPRS等。

[0052] 图2A示出了根据本发明的一种实施方式的简化的协议架构。根据这种实施方式，为该发送器设备10以及一个或多个接收器设备20而实施的该协议栈包括应用层、FLUTE协议层、UDP层和IP层以及更低的层。FLUTE协议层建于分层编码传输(LCT)建构块(未示出)的ALC协议实例之上。可以使用FEC建构块(未示出)。FLUTE协议层连同NACK消息意在提供从该发送器设备10到该接收器设备20可靠的数据块传输。这种协议架构可以用于一对多传输(用于一对多的“首次传输”以及修复会话中一对多的重传)。 [0053] 可选地，在一种实施方式中可使用TCP层代替UDP层(见图2B)。这应用于使用独立的点对点修复会话(此处为TCP会话)进行一对 一(即点对点)重传的情况。 [0054] 通常观察到，可靠多播系统带来了需要接收器服务器控制和数据消息传递的问题，由于多播的多方性这又带来扩展性的问题。特别地，有三处应予以考虑： [0055] a)有限的无线带宽以及激活资源，其中激活一些无线信道的时间以及采用的无线带宽使多个修复同时进行难以实施；

[0056] b)有限的服务器容量，其中提供“修复内容”数据的该服务器系统能够处理有限数量的请求(消息传递)和某一时间窗内的关联会话上下文数据，以及有限量的同时数据传送会话；以及

[0057] c)有限的端到端的带宽，这是由于该整体系统内的一个或多个瓶颈。此处的数据率对于所有同时要求修复的所有用户来说应该是可用的，但该数据率在许多情况下不足以提供这项服务。

[0058] 因此，在任何或所有这些的限制之下提高可扩展性中的关键因素是在适合的时间内分布消息传递或如果可行的话则完全地避免它。

[0059] 在下文中，给出了用于多播/广播会话的有效修复的方法。该方法基于发送器判定或基于接收器判定。

[0060] 在下文的讨论中，发送器指示数据源或任何其它给定的多播/广播网络架构的附加的或联合的数据源单元(例如，应用附属实体(Application Adjunct Entity)，其定义于3GPP TS 23.246Rel.6，V.6.1.0，sec.7.1)。通常，由于二者动机大体相同，所以术语“NACK”(否定的确认)可由“修复请求”替代使用，但是这些方法中的每一种方法都可用于NACK而无需在一些实施方式中的修复的隐含请求，在这些实施方式中例如数据收集的目的才是极为重要的，而非可靠的分发。还应指出对错误/丢失数据的NACK相比于肯定的确认方案来说总体上是一种更为有效的用于可靠的多播的确认方案。但是这并不排除在有益的地方使用利用肯定的ACK方案的所述方法。

[0061] A)发送器驱动修复方法

[0062] 方法A1：

[0063] 利用这种方法，发送器在会话通告(例如使用比如SDP的会话描述协议，或任何其它方法)期间向接收器传输错误率参数(例如SDU错误率)。(比特、分组或其它数据单元增量中的其它错误率在一些实施方式中可以是优选的。)

[0064] 该接收器将接收到的参数翻译成错误率阈值，如果超过该阈值接收器不应该使用点对点会话请求修复会话。如果发送器知道平均发送器错误率和/或知道接收到错误数据的接收器的平均百分率，则能够基于阈值确定在多播/广播中向所有用户重传完整的数据流，这避免接收器反馈内爆以及过高数量的执行数据修复的点对点连接。用于使发送器知晓该平均接收器错误率以及知晓接收到错误数据的接收器的平均百分比的方法例如由网络消息给出，该网络消息通知发送器每个小区、地理区域或接收器的质量或错误率(和/或接收器的数量)。

[0065] 上文中的一个例子如下：

[0066] 发送器使用SDP通告发送错误率阈值为10％的的广播/多播会话。该广播/多播会话开始并且接收器发现接收的数据具有＞10％的错误率。接着它制止经点对点会话对丢失分组进行重传的请求。如果该发送器知晓该平均接收器错误率＞10％和/或知晓接收到错误数据的接收器的平均百分比＞50％，则可以决定在多播/广播中重传该完整数据会话(此处的10％和50％是示例性的值)。

[0067] 可选地，如果接收器知道平均接收器错误率和/或接收到错误数据的接收器的平均百分比，并且发送器已确定这就是重传整个数据会话的情况(例如，由于高的平均接收器错误率)，则发送器能够决定在该会话结束时将点对多点的修复令牌发送至接收器，从而通告该会话将——或可选地“将不”——以多播/广播方式重传(可选地列出的将被修复的一个或多个文件(和/或列出一个或多个文件中的一个或多个块))。这避免了接收器为了进行数据修复而开始点对点连接。利用ISO OSI协议栈1-7层的任一层上的任何通信协议对 该修复令牌进行传输，包括在多播/广播传输之后在独立的“通告”中经SDP传输。这也能够包括在多播/广播传输中FLUTE文件分发的最后部分(例如，完全最后的分组)之内。

[0068] 方法A2：

[0069] 正如在section 7.1 of 3GPP TS 23.246Rel.6，V.6.1.0 for MBMS中所描述的，为了避免网络过载，发送器能够在激活时间将(多个中的一个)应用附属实体(AEE)的地址以及生成上行链路业务的随机时间离散的参数分布到接收器。应指出的是尽管本说明书所述“多个中的一个”，但可以理解这也意味着“多于一个中的一个或多个”。 [0070] 方法A2依赖于这样的事实，即发送器不在激活时间(加入)发送该信息，而是在会话通告时间(经SDP或任何其它合适的方法)发送该信息。因此这种方法定义了在会话通告期间有待于向接收器分发的2个参数：

[0071] -AAE地址或类似参数(该参数的名称是示例性的)；以及

[0072] -随机时间。

[0073] 该随机时间例如可基于发送器所知的接收器位置而计算。举例来说，如果发送器知晓接收器分布于蜂窝网络(例如GPRS或UMTS)的不同网络小区，发送器将计算随机时间以便避免在相同小区中的所有接收器同时请求点对点修复(因此，这将考虑到物理位置)。作为替代，它将确定点对点连接的请求沿不同小区在不同的时刻上被分发。如果该发送器不具有与接收器位置有关的信息，则它将向接收器分发仅基于时间的(不考虑物理位置)随机时间参数。该随机时间参数指示了该点对点修复会话的开始时间。 [0074] 一种对于现有技术(3GPP TS 23.246v.6.1.0)以及上文刚描述的方法的扩展，提供了“NACK抑制参数集”而不是仅提供“随机时间”。该方法的一种情况是实施一种算法“NACK-alg-3，fast-window ＝ 500seconds；uniform，slow-window ＝ 5000seconds；
normal，error_threshold_for-slow_window”，其中该算法定义了对用于NACK抑制的2个时间窗的的使用——并且每个时间窗的时间和统计分布 参数已给定——以及用以在该2个时间窗的使用之间做出选择的输入参数(将在下文中结合方法A4和A5给出这种NACK抑制方案的更多解释)。

[0075] 方法A3：

[0076] 在本发明的另一种实施方式中，从接收器接收了一定数量的NACK请求之后，发送器可以基于其自身的阈值决定断开点对点连接并在多播/广播中重传整个(或部分)会话。这种情况发生于发送器知晓接收器已做了过多的重传请求(即，存在更高的错误率)，以及最好避免使用点对点连接而浪费网络资源。该阈值可以静态配置，例如，对于1个会话有4个不同的接收器NACK；或动态计算，例如，能够由历史数据推断出，例如3秒内来自不同接收器的足球视频服务的2个NACK指示10分钟内可预期有5000个NACK。在发送器已选择断开点对点修复数据分发并且使用点对多点重新分发该数据但又没有立即进行的情况下，一种实施方式将使发送器向接收器以信号发送该修复会话会于将来发生，并从而通知那些还未对丢失数据进行NACK操作的接收器不需要执行这样的操作。更进一步，这种向接收器发送的信令可以精确指示出是哪些数据片段要重发，并因此使得接收器能够建立它们的内容将被完成——以及对随后(点对点)修复的需要的程度。这就实现了一种混合的点对多点以及点对点修复。

[0077] 图5示出了使用修复令牌来指示在稍后时间的P-t-M(点对多点)修复，以及针对P-t-M修复数据中丢失的令牌而在后续操作中使用P-t-P(点对点)的实施方式。修复令牌可以是P-t-M或P-t-P，在这两种情况下分别由发送器(Y)以及修复发送器(Z)发起。该P-t-P或P-t-M的判定做出者(X)可以是截然不同的实体，或同发送器(Y)或修复服务器(Z)组合在一起。该P-t-P或P-t-M的判定做出者(X)可以为第三实体，该第三实体可作为单一的或独立的逻辑和/或物理设备来实施。图5(以及在其它图中)中的修复发送器可被理解为修复服务器或类似的设备。该P-t-P或P-t-M的判定做出者(或判定做 出单元)还可以被称为修复判定单元。

[0078] 方法A4：

[0079] 正如方法A1中所描述的，当达到一个或多个阈值的时候接收器不应该请求重传(发送一条NACK)。另一种实施方式将通过以下之一改变接收器的上下文： [0080] a)改变NACK抑制算法或其参数；和/或

[0081] b)改变操作模式。

[0082] 上文提到的“不应NACK”(或不准NACK)给出了改变NACK抑制算法的极端情况。另一种可选方式是以这样的方式来改变这种行为，即：

[0083] 如果错误率低于阈值，则

[0084] “在时间段X上统一对一个或多个NACK进行随机化，这开始于初始分发会话结束时”

[0085] 否则

[0086] “在初始会话结束后，必须等待直至某个时间Y之后，并且接着在时间段Z上对一个或多个NACK进行随机化”。

[0087] X，Y，Z能够选择为不同的值或甚至是相等的值。这对于使得“快修复加慢修复”对感知的用户QoS进行最大化尤其有用。其接收器在初始分发中接收到许多错误的用户很可能在任何情况中经历更差的QoS，如果他们希望在分发后立即使用掉这些内容，他们无论如何都必须等待潜在地长的修复会话。但是，接收到非常少的错误的用户因此得以在“修复资源”中被赋予优先权，并且因此他们应该能够在该初始会话后迅速使用该内容。因此，这种方法甚至使得差的初始分发能够完成，同时确保以好的用户感知QoS水平的修复来完成好的初始分发。

[0088] 上文概括的是使用错误率的数组[ER 1，ER2，...，ERn]，NACK随机化数组[X1，X2，...，Xn]，等待时间数组[Y1，Y2，...，Yn]和/NACK随机化数组[Zi，Z2，...，Zn]的一种方法，其中对于每个k＝1，...，n，n属于N+，4元组(ERk，Xk，Yk，Zk)指示对于错误率＜ERk，接收器必 须在时间段Xk上统一随机化NACK，并且对于错误率≥ERk，该接收器必须在该初始会话结束后等待直至某一时间Yk后，并且接着在时间段Zk上随机化NACK。等待时间的数组可以为零值数组。

[0089] 一些NACK抑制方案向接收器/主机分配多于一个的角色。举例来说，标记持有者方案期望该标记持有者立即对错误做出响应，而其它接收器如果没有意识到该标记持有者已NACK(类似于用于报告组员的IMGP)，则进行NACK(随机地)。本发明的一种实施方式将改变接收器的操作模式。举例来说，如果超出(或可选地未达到)阈值，则该接收器将采用另一个角色。在标记持有者的例子中，处于一个很低的阈值(例如，仅有一个错误)下的接收器可能立即NACK或在很短的时间窗内NACK，并且其它的接收器将稍后NACK。 [0090] 一种组合的实施方式将“接收器角色”与NACK抑制算法/参数结合以便某一角色(例如“低错误模式”或“高错误模式”)定义NACK的操作，并且该阈值用于计算将使用的模式。在这些类型的判定过程中还包括滞后是有益的，因此该模式可以在一定数量的连续测量之后得到改变——例如，如果接收器在100次测量中仅超过该阈值1次，这将不会改变模式。

[0091] 图6示出了补偿时间的分布。图7示出了对于所有经历错误率在阈值1之下的接收器(即，接收器1和2)，其请求分布在该会话开始后60秒上。对于所有经历错误率高于阈值1但小于阈值2的接收器(即，接收器3、5和8)，该请求在稍后的60秒发送并被分布在120秒上。

[0092] 方法A5：

[0093] 正如方法A1中所描述的，可以使用错误率阈值。另一种实施方式提供了错误率阈值并且还提供了时间窗和/或数据窗，用于在其内计算该阈值。举例而言，“10％分组错误率；任意，30秒窗，滑动”可指示出该阈值为最后30秒内10％的分组(丢失或包含错误)以及从该最后30秒用滑动时间窗连续(或伪连续)地采样。另一个例子 为“5％比特错误率，任意，2K字节的窗，封锁”，因此对于一个或多个(任意)2K字节的块来说该阈值为5％的比特错误，其中0-2KB，2-4KB，4-6KB等为采样的块。符合该准则的任何数据都是一种实施方式；然而在大数据传送中，改为提供第二等级阈值是有利的，例如“如果在一个会话中3次符合这种准则，则认为阈值已到达”。

[0094] 图8示出了用于计算阈值的值的时间窗的效果。

[0095] 方法A6：

[0096] 一些实施方式可以通过预配置来共享/分发在服务器和接收器之间讨论的参数。举例来说，诸如由运营商保存到SIM卡，该运营商发行SIM并操作多播系统。另一个例子是对熟知的参数进行预配置，并且通常这样的熟知数值将在标准中指定或由数字登记组织(例如IANA)维护。在一种实施方式中，如果还提供了分发参数的另一种方法，则对于某个会话来说，这些参数的默认值被预配置并且被替换(覆写)。

[0097] 方法A7：

[0098] 在从接收器接收到关于相当大量的内容数据的修复请求之后，本发明另外的一种实施方式将使发送器向接收器指示将“稍后对此进行修复”。该后续修复会话可以是点对点或点对多点会话。因此，在系统带宽为主要的限制扩展的因素的地方，这允许发送器考虑可首先快速得到满足的接收器，这样一来可以减少平均时间来确保目标数量的接收器(例如99％)具有完整的(无差错)数据。举例来说，该修复可以首先通过点对多点修复(以便修复最大数量的接收器)而开始，并接着进行点对点修复(以便修复较少数量的接收器)。 [0099] 方法A8：

[0100] 上文通常使用会话的结束作为修复会话以及信令的起始点。然而，在一些实施方式中使用对象(例如，文件或场景)结束，阈值(例如，每1M数据或每1000个分组或每5分钟)或会话组(例如，所有这4个相关的会话的结束)可以是有利的。

[0101] 图9示出了检测出对象结束之后修复会话的开始。

[0102] B)接收器驱动修复方法

[0103] 通常，接收器能够对用于数据修复的点对点连接建立的请求延迟一定量的时间，避免在该多播/广播会话结束之后立即执行这种请求。这避免了大量接收器同时发送用于修复的点对点连接的请求的情况，并且因此避免了网络以及发送器的拥塞。在下文中，给出了一些用于延迟点对点修复请求的方法：

[0104] 方法B1：

[0105] 所述修复可以是迟缓修复：在这种情况下，当用户想使用掉数据时(例如当该用户希望播放在多播/广播会话期间已下载的视频剪辑时)，接收器执行点对点修复请求。这需要用户等待执行完整的点对点修复的时间(即，增加了数据享用的用户延迟)。这种方法可选地还需要发送器在会话通告中传输(使用SDP或任何其他适合的方法)最大的修复可用时间，该时间是直至发送器能够成功地执行点对点修复的时限。没有规定该时间单元的格式，但它可以用各种方式表达(例如但并非限于，绝对时间或相对时间)。在该最大修复可用时间之后，并不保证点对点修复操作成功。这就向发送器给出保持存储的数据以便执行数据修复的时限。如果到最大修复可用时间时没有执行点对点修复(因为该用户还未请求数据重放)，则强制接收器在那时执行点对点修复。如果接收器被断开，并且最大修复可用时间已过去，则在连续时间上的该点对点修复并没有得到保证。在一些情况下，减少NACK在其上被随机化的时段以便允许结束处的“安全裕度(safety margin)”是有利的；例如，如果该时段为432000秒，NACK通常分布在400000秒，这就允许最大值为32000秒的时间用于“停用的”接收器被加电而不会错过保证的修复时间。

[0106] 上文的一个例子如下：

[0107] 如果发送器在其通告内发送最大修复可用时间直至2004年3月15日17:00，这意味着该接收器能够执行修复直至该指定的日期和时间。在这个日期/时间之后，修复操作得不到保证。一种可选的方 式是将该时间表达为从多播/广播传输开始的相对时间。例如发送器可以向接收器以信号发送最大修复可用时间为432000秒。这就告诉接收器进行点对点修复的最后可能是从该多播/广播传输开始的5天后。

[0108] 图10示出了迟缓修复的实施方式。

[0109] 方法B2：

[0110] 所述修复可以是迟缓回放修复：在这种情况下，当用户想使用掉数据时，接收器执行该点对点修复请求。另外，该修复考虑数据流中第一次丢失的位置。如果该数据流为语音或音频以及视频流，则接收器能够确切地计算出第一次数据丢失发生在什么媒体单元时间上。在最好的情况下，接着点对点修复可被推迟开始，甚至在该数据流的回放后开始，但其必须执行并完成得足够早以使接收器回放不会遭受连续性中断。

[0111] 如果点对点修复操作不能与回放同时执行(因为点对点修复操作需要的时间大于第一个丢失块的时间)，则当用户发出回放请求时该点对点修复可立即开始，但实际的回放被延迟必要的时间从而避免回放中断。这种方案非常类似于上述第一种方案(方法B1)，但其提供了更低的用户延迟，因为该修复操作以及回放在时间上部分重叠。 [0112] 还是在这种情况中，如同在第一种情况下(方法B1)，接收器可能可选地需要和使用该最大修复可用时间信息。

[0113] 执行点对点修复所需要的时间可由接收器基于一定的因素来估计，所述因素例如点对点连接的测量的带宽或允许的带宽，点对点信道上测量到的往返时间，以及点对点会话建立和终止延迟。

[0114] 上文的一个例子如下：

[0115] 如果发送器传输5分钟的音频/视频片断并且接收器检测到30个丢失的分组，最早的一个丢失发生在第4分钟的时刻，则用户能够立即开始该流的回放，并且接收器将充分早的与用户回放同时开始该点对点修复操作以便所有30个丢失分组在4分钟的回放之前到 达。如果30个丢失块是这样的，即第一个丢失块发生在第1分钟的时刻，并且接收器估计该点对点修复会话将用去多于1分钟的时间，则该修复会话被启动并且回放被延迟了避免回放中断所需的时间。

[0116] 图11示出了该迟缓回放修复的实施方式。

[0117] 方法B3：

[0118] 另一种情况(类似于方法A7中的接收器驱动的应用)是该NACK抑制使用错误/丢失数据的数量作为乘数以计算该恢复时间。举例而言，如果发送器指示“时间的单位”是60秒，并且丢失数据的单位是10个分组，则具有56个丢失的分组的接收器将计算出INT(56/10)×60＝300秒的时间。这些得到的时间可以用作偏移(在初始会话结束后的这么多秒的时间流逝之前，不能开始NACK)和/或作为NACK在其上分布的时间段(例如，在这个段时间上统一随机化你的NACK)。

[0119] 方法B4：

[0120] 本发明进一步的实施方式是在初始多播/广播传输结束之前开始点对点修复会话的可能性。通过这种方式，修复更快并且用户能够以更短的延迟开始无差错的“播放”会话。确切的修复开始时间可由接收器决定，或可以是数据流内第一个错误的位置和/或文件长度的函数。

[0121] 图12示出由于“早期检测”而开始的修复的实施方式。

[0122] 上文所描述的所有方法也可用于任何可能的以及功能上合适的组合。 [0123] 图3示出了根据本发明的一种实施方式的接收器设备20的系统以及细节。该系统包括发送器设备10、例如IP网络或另一种固定网络、无线网络或固定和无线(蜂窝)网络的组合等的传输网络30，以及接收器设备20。该接收器设备20可以是蜂窝电话、卫星电话、个人数字助理或蓝牙设备、WLAN设备、DVB设备、或其它类似的无线设备。设备20包括内部存储器21、处理器22、操作系统23、应用程序24、网络接口25以及NACK和修复机制26。内部存储器 21容纳有处理器22、操作系统23以及应用程序24。NACK和修复机制26实现响应于在数据传输中丢失或破坏的数据的NACK和修复进程。设备20能够与发送器设备10以及其它设备经网络接口25以及网络30进行通信。

[0124] 图4示出了根据本发明一种实施方式的发送器设备10。发送器设备10例如可以是网络服务器或旨在用于文件(或媒体)发分的任何合适的设备。设备10包括内部存储器11、处理器12、操作系统13、应用程序14、网络接口15、传输和修复机制16以及数据存储器17。内部存储器11容纳有处理器12、操作系统13以及应用程序14。传输和修复机制16实现向一个或多个接收器设备20传输数据分组。更进一步，它实现修复会话中的数据分组的重传。需要发送到接收器设备20的数据以及需重传的数据可存储在数据存储器17中。可选地，数据可存储在与接收器设备10位于一处或在其之外的独立设备中。设备10可通过网络接口15和网络30与接收器设备10以及其它设备进行通信。

[0125] 涉及丢失数据的修复的进程可由软件实施。包括存储在接收器设备20中并在处理器22中运行的程序代码的计算机程序产品可用于在传输会话的接收结束时刻实施该进程，而包括存储在发送器设备10并在处理器12中运行的程序代码的计算机程序产品能够用于在传输结束时实施该进程。

[0126] 通过逻辑发送器/服务器实体以及接收器单元的例子示出了本发明的实施方式。对运行于修复请求和修复响应(如果适当)之间的第三实体的使用也落入本发明的实施方式的范围内。这样的实体可以提供防火墙、代理和/或授权服务，例如向点对多点发送器授权修复发送器消息，要求其分发修复令牌；或作为从接收器至发送器的消息的修复请求聚合器/代理，并因此实现第三设备中透明的点对点/点对多点决定。

[0127] 在上文中已给出修复令牌的点对多点分发的使用。另外，在一些实施方式中点对点修复令牌的使用可能是有利的并且处于本发明的 实施方式的范围内(可使用与已给出的涉及点对多点修复令牌的方法对应的分发/格式化的方法，例如SDP)。如果点对点请求已经在做出由点对多点来重新发送的决定之后到达，则这种方案可以向接收器指示点对多点修复/重新发送数据正“在途中”，或可选地使得接收器为节省时间、能源而停用其多点接收，但仍能获悉即将到来的点对多点修复的响应/重新发送。

[0128] 根据本发明的实施方式，NACK抑制可提供可扩展的可靠多播。向多播/广播传输提供一种有效并可扩展的点对点修复，以避免反馈内爆以及网络/发送器过载。 [0129] 已描述了本发明的具体实现方法以及实施方式。对于本领域技术人员来说，本发明并不限于上文给出的实施方式的细节是明显的。更进一步，本领域技术人员将认识到还存在许多实现本发明的其它方式，即使并未在有限的几个例子的子集之一中加以示出，但这些方式都属于本发明的范围之内。特别地，本发明不应局限于任何协议、参数或消息的任何具体的名称。本发明能够使用等同装置在其它实施方式中实现而不偏离本发明的特性。本发明的范围仅由所附的专利权利要求书来限定。