CN1864335A - 基于前向纠错(fec)的可靠性控制协议 - Google Patents

基于前向纠错(fec)的可靠性控制协议 Download PDF

Info

Publication number
CN1864335A
CN1864335A CNA2004800286287A CN200480028628A CN1864335A CN 1864335 A CN1864335 A CN 1864335A CN A2004800286287 A CNA2004800286287 A CN A2004800286287A CN 200480028628 A CN200480028628 A CN 200480028628A CN 1864335 A CN1864335 A CN 1864335A
Authority
CN
China
Prior art keywords
receiver
transmitter
coding unit
control protocol
reliability control
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
CNA2004800286287A
Other languages
English (en)
Other versions
CN100550652C (zh
Inventor
M·路比
M·道克雷夫
A·威德森
S·拉森
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Qualcomm Inc
Original Assignee
Digital Fountain Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Digital Fountain Inc filed Critical Digital Fountain Inc
Publication of CN1864335A publication Critical patent/CN1864335A/zh
Application granted granted Critical
Publication of CN100550652C publication Critical patent/CN100550652C/zh
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/18—Automatic repetition systems, e.g. Van Duuren systems
    • H04L1/1812—Hybrid protocols; Hybrid automatic repeat request [HARQ]
    • H04L1/1819—Hybrid protocols; Hybrid automatic repeat request [HARQ] with retransmission of additional or different redundancy
    • H—ELECTRICITY
    • H03—ELECTRONIC CIRCUITRY
    • H03M—CODING; DECODING; CODE CONVERSION IN GENERAL
    • H03M13/00—Coding, decoding or code conversion, for error detection or error correction; Coding theory basic assumptions; Coding bounds; Error probability evaluation methods; Channel models; Simulation or testing of codes
    • H03M13/65—Purpose and implementation aspects
    • H03M13/6522—Intended application, e.g. transmission or communication standard
    • H03M13/6547—TCP, UDP, IP and associated protocols, e.g. RTP
    • H—ELECTRICITY
    • H03—ELECTRONIC CIRCUITRY
    • H03M—CODING; DECODING; CODE CONVERSION IN GENERAL
    • H03M7/00—Conversion of a code where information is represented by a given sequence or number of digits to a code where the same, similar or subset of information is represented by a different sequence or number of digits
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/18—Automatic repetition systems, e.g. Van Duuren systems
    • H04L1/1867—Arrangements specially adapted for the transmitter end
    • H04L1/1887—Scheduling and prioritising arrangements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/163—In-band adaptation of TCP data exchange; In-band control procedures
    • H—ELECTRICITY
    • H03—ELECTRONIC CIRCUITRY
    • H03M—CODING; DECODING; CODE CONVERSION IN GENERAL
    • H03M13/00—Coding, decoding or code conversion, for error detection or error correction; Coding theory basic assumptions; Coding bounds; Error probability evaluation methods; Channel models; Simulation or testing of codes
    • H03M13/37—Decoding methods or techniques, not specific to the particular type of coding provided for in groups H03M13/03 - H03M13/35
    • H03M13/3761—Decoding methods or techniques, not specific to the particular type of coding provided for in groups H03M13/03 - H03M13/35 using code combining, i.e. using combining of codeword portions which may have been transmitted separately, e.g. Digital Fountain codes, Raptor codes or Luby Transform [LT] codes

Abstract

在一种传输系统中，通过将要传送的数据组织成数据块、将第一数据块的编码单元从发送器传送给接收器、并在发送器上检测接收器接收编码单元的确认，数据可靠地从发送器传送给接收器，其中每个数据块包括多个编码单元。在发送器上，检测接收器接收足够的用以在接收器上恢复第一数据块的第一数据块的编码单元的概率，且该概率根据概率阈值进行测试来确定是否满足预定测试。在测试步骤之后并在接收器接收第一数据块在接收器上恢复的确认之前，当满足预定测试时，从发送器传送第二数据块的编码单元。如果在发送器上接收到了恢复第一数据块失败的指示，则从发送器向接收器发送更多的第一数据块的编码单元。在一些实施例中，预定测试是概率与概率阈值的比较，且当概率大于概率阈值时满足预定测试。

Description

基于前向纠错(FEC)的可靠性控制协议
相关申请
本申请声明对于2003年10月8日提交的题为“FEC-based Reliability ControlProtocols(基于前向纠错(FEC)的可靠性控制协议)”的共同待批的美国临时专利申请60/509,976的优先权，该申请通过引用结合于此用于所有目的，如同在本文中完整阐述。
技术领域
本发明涉及数据通信网络上终端系统之间数据的快速传送问题。
许多数据通信系统和高级数据通信协议提供可靠数据传输的方便通信抽象，并提供速率控制，即它们基于网络条件自动调整其分组传输速率。它们传统的根据诸如无所不在的传输控制协议(TCP)的低层分组化数据传输的基础实现，在以下情形的至少之一发生时会遭遇困难：(a)发送器和接收器之间的连接有较长的往返时间(RTT)；(b)数据量较大且网络遭受突发和瞬时的丢失。
当今最广泛使用的可靠传输协议之一是传输控制协议(TCP)。TCP是具有确认机制的通用的点对点分组控制方案。TCP在发送器和接收器之间几乎没有丢失且发送器和接收器之间的RTT较小时对一对一可靠通信能起很好的作用。然而，TCP的吞吐量在即使只有很少丢失时，或者发送器和接收器分开较远时急剧下降。
使用TCP，发送器传送有序分组而接收器确认每个分组的接收。如果分组丢失，则不向发送器发送确认，而发送器将重发该分组。使用诸如TCP的协议，确认模式允许分组丢失而不会整体失败，因为可响应于缺少确认或响应于来自接收器的显式请求，只重发丢失了的分组。
TCP提供可靠性控制和速率控制，即它确保全部原始数据被传送给接收器，并且它基于诸如拥塞和分组丢失的网络条件自动调整分组传输速率。对于TCP，可靠性控制协议和速率控制协议是相互交织且不可分的。此外，TCP的作为渐增RTT和分组丢失的函数的吞吐量性能远未达到最优。
许多研究显示：当使用TCP时，数据传送的吞吐量与RTT和端对端连接上丢失速率的倒数的平方根的积成反比。例如，典型的美国和欧洲之间的端对端地面连接具有200毫秒的RTT和2％的平均分组丢失。在这些情形下，不管端对端有多少带宽可用，TCP连接的吞吐量最多都约为300-400千比特/秒(kbps)。该情形对卫星链接更为严重，其中除了高RTT之外，信息还因各种大气效应而丢失。这些类型情形中TCP的较差性能的主要原因是，由TCP使用的速率控制协议在这些情形中不能起很好的作用，并且因为TCP使用的可靠性控制协议和速率控制协议是不可分的，这暗示整个TCP协议在这些情形中都不能起很好的作用。此外，对传输的不同应用的要求会变化，然而TCP是全球普遍地用于所有网络条件中的各种应用，从而导致许多情形中的较差性能。
所期望的是，如果整体传输协议所使用的可靠性控制和速率控制协议是独立的，且相同的可靠性控制协议可与各种不同的速率控制协议一起使用，则实际的速率控制协议可基于应用要求和应用所运行的网络条件而选择。Micah Adler、YairBartal、John Byers、Michael Luby、Danny Raz在1997年6月第5届以色列计算和系统理论研讨会会议录上的论文“A modular Analysis of Network TransmissionProtocols”(网络传输协议的模块化分析)(下文中称为“Adler”并通过引用结合于此)，介绍了建立提倡将可靠传输协议分成独立的可靠性控制和速率控制协议的传输协议的模块化方法。
对于任何可靠性控制协议，其性能的两个主要度量是需要多少缓冲，以及其“实际吞吐量”(goodput)是什么。在发送器和接收器上缓冲都被引入到可靠性控制协议中。在例如数据开始发送后数据缓存直到发送器得到确认在接收器方已接收到了该数据时，发送器上的缓冲发生。接收器上的缓冲也因类似原因发生。出于两个原因缓冲是令人感兴趣的：(1)它直接影响发送器和接收器可靠性控制协议使用多少存储器；(2)它直接影响发送器和接收器可靠性控制协议引入多少等待时间。实际吞吐量被定义为要传送数据的大小除以在传送期间接收器终端系统接收到的传送数据量。例如，如果用传送原始数据的分组发送的数据量是原始数据的大小，则实际吞吐量＝1.0，且实际吞吐量＝1.0可在不传送冗余数据时实现。
Adler概述了一种与所使用的速率控制协议相当独立的可靠性控制协议，该协议在下文中称为“无码可靠性控制协议”。该无码可靠性控制协议与内嵌于TCP中的可靠性控制协议有些相似，即原始数据被分成多个块且每个块在分组的有效载荷中发送，然后需要接收每个块的精确副本以确保可靠传输。该无码可靠性控制协议的问题是，尽管实际吞吐量达最优(基本等于1)，但无码可靠性控制协议引入的缓冲在有分组丢失时会相当多。Adler证实该无码可靠性控制协议在不使用编码来传送数据的可靠性控制协议中最优的一常数因子范围内，即该协议具有最优的实际吞吐量，并根据使发送器和接收器上所需缓冲的量最小来说，该协议可证明在最优的一常数因子范围内。
已在可靠性控制协议中使用的一种方案是前向纠错(FEC)码，诸如里德索罗门(Reed-Solomon)码、龙卷风(Tornado)码、或连锁反应码(是信息附加码)。使用FEC码，原始数据被分成比分组有效载荷大的块，然后编码单元从这些块中产生，并用分组来发送这些编码单元。该方法与不使用编码的可靠性控制协议相比的一个基本优点是，反馈会简单得多并且不太频繁，即，对于每个块接收器仅需向发送者指示所接收编码单元的数量，而不是所接收编码单元的准确列表。此外，聚合产生并发送比原始数据块的长度更多的编码单元的能力是设计可靠性控制协议时的强大工具。
诸如Reed-Solomon码或Tornado码的删除校正码对固定长度的块产生固定数量的编码单元。例如，对于包括B个输入单元的块，可产生N个编码单元。这N个编码单元可包括B个原始输入单元和N-B个冗余单元。如果存储允许，则发送器可对每个块计算编码单元集一次，并使用转盘协议来传送编码单元。
一些FEC码的一个问题是它们需要额外的计算能力或存储器来作运算。另一个问题是所需编码单元的数量必需在编码过程之前确定。这可在高估分组的丢失速率时导致低效，并可在低估分组的丢失速率时导致故障。
对于传统的FEC码，能产生的可能编码单元的数量与将块分成输入单元的数量在同一数量级上。通常，但并非排他地，这些编码单元的大多数和全部在发送步骤之前的预处理步骤中产生。这些编码单元具有这样的属性：全部输入单元可从长度等于原始块或长度略大于原始块的编码单元的任何子集中再生。
在美国专利6,307,487(下文中称为“Luby I”并通过引用结合于此)中所述的连锁反应解码可提供解决以上问题的前向纠错的一种形式。对于连锁反应码，能产生的可能编码单元的池比输入单元的数量有更高数量级，且从概率池中随机地或伪随机地选择的编码单元可极快地产生。对于连锁反应码，编码单元可在按需基础上与发送步骤并发地即时产生。连锁反应码允许内容的所有输入单元能从长度略大于原始内容的随机或伪随机产生的编码单元集或子集中再生。
诸如美国专利6,320,520、6,373,406、6,614,366、6,411,223、6,486,803、和公开号为20030058958的美国专利(下文中称为“Shokrollahi I”)的其它文件描述了各种连锁反应编码方案，并通过引用结合于此。
使用连锁反应码的发送器可连续产生所发送的每个块的编码单元。这些编码单元可通过用户数据报协议(UDP)单播传送(或可应用的UDP多播传送)传送给接收器。假设每个接收器都装有解码单元，它解码适当数量的用分组接收的编码单元以获取原始块。
可从Digital Fountain公司购买的Transporter FountainTM网络设备中可用的若干传输之一是使用一种可靠传输协议，它使用可与各种速率控制协议组合的一种简单的基于FEC的可靠性控制协议。该简单的基于FEC的可靠性控制协议在下文中称为“TF可靠性控制协议”。TF可靠性控制协议传送给定数据块的编码单元，直至从接收器接收已接收了足够的用以恢复该块的编码单元的确认，然后发送器继续到下一个块。
设RTT是从发送器发送分组直到发送器从接收器接收到分组已到达的确认的秒数，设R是以分组/秒为单位的发送器的当前发送速率，并设B是以分组为单位的块的大小。使用TF可靠性控制协议，在恢复该块所需的最后一个分组之后发送的包含块的编码单元的无用分组的数量为N＝R*RTT。因而，所发送分组的一部分f＝N/(B+N)被浪费，因而实际吞吐量至多为1-f。例如，如果R＝1,000分组/秒，RTT＝1秒，且B＝3,000分组，则f＝0.25，即25％的接收分组被浪费。因而，该示例中的实际吞吐量为很低的0.75(与最大可能的实际吞吐量1.0相比)。
在该示例中，还要注意，块的大小B连同速率R隐含该简单的基于FEC的可靠性控制协议所引入的等待时间至少是4秒(每个块共传送4秒)，并需要缓冲至少一个块，即3000个数据分组。此外，要增大实际吞吐量需要增加缓冲，或者相反减少缓冲需要降低实际吞吐量。
根据以上内容，可靠性控制中的改进是所期望的。
发明内容
在根据本发明各实施例的传输系统中，通过将要传送的数据组织成数据块、将第一数据块的编码单元从发送器传送给接收器、并在发送器上检测接收器接收编码单元的确认，数据可靠地从发送器传送给接收器，其中每个数据块包括多个编码单元。在发送器上，检测接收器接收足够的用以在接收器上恢复第一数据块的第一数据块的编码单元的概率，且该概率根据概率阈值进行测试来确定是否满足预定测试。在测试步骤之后并在接收器接收第一数据块在接收器上恢复的确认之前，当满足预定测试时，从发送器传送第二数据块的编码单元。如果在发送器上接收到了恢复第一数据块失败的指示，则从发送器向接收器发送更多的第一数据块的编码单元。在一些实施例中，预定测试是概率与概率阈值的比较，且当概率大于概率阈值时满足预定测试。
附图说明
图1是可使用本发明所述内容的网络、发送器终端系统和接收器终端系统的一个实施例的框图。
图2是模块化可靠传输协议体系结构以及使用该协议运行的相关系统的视图。
图3是发送器的基于FEC的可靠性控制协议体系结构以及使用该协议运行的相关系统的视图。
图4是接收器的基于FEC的可靠性控制协议体系结构以及使用该协议运行的相关系统的视图。
图5示出可由实现TF可靠性控制协议的系统使用的一个可能格式集。
图6是实现发送器的TF可靠性控制协议的系统的逻辑框图。
图7是实现接收器的TF可靠性控制协议的系统的逻辑框图。
图8是活动块的视图。
图9是可由交织可靠性控制协议使用的一个可能格式集的示图。
图10是实现基本发送器的交织可靠性控制协议的系统的逻辑的一说明性实施例。
图11是实现基本接收器的交织可靠性控制协议的系统的逻辑的一说明性实施例。
具体实施方式
在本发明的各个实施例中，交织可靠性控制协议用来提供对TCP、TF可靠性控制协议和无码可靠性控制协议的改进。使用一种可靠性控制协议，数据块作为一系列编码单元从发送器发送到接收器，并且接收器确认编码单元或块的恢复，从而允许发送器确定接收器是否接收到数据，且如果未接收到，则重新传送该数据、或传送其它可用于恢复该接收数据的数据。一些交织可靠性控制协议的属性是用交织方式发送不同块的编码单元。交织可靠性控制协议具有一个属性，当与实际上任何速率控制协议组合时，它们提供一种有效的可靠数据传输，使终端系统上的缓冲(及结果等待时间)最小并使传输的实际吞吐量最大。
交织可靠性控制协议可与适当速率控制协议一起使用，以甚至在高丢失和/或有较大RTT时，确保数据的可靠传送同时保持高吞吐量。例如，速率控制协议可像以固定速率发送一样的简单，并且交织可靠性控制协议将确保数据以等于固定速率乘以成功到达分组的比例的速率传送，同时使传送期间的缓冲和等待时间最小。
作为在此介绍的交织可靠性控制协议所提供的定量改进的一个示例，假设速率控制协议是以每秒R个分组的固定速率发送分组，发送器和接收器之间往返时间为RTT秒，因而N＝R*RTT为进行中未获确认分组的数量。对于无码可靠性控制协议，发送器上的总缓冲区大小至少为N*ln(N)，且实际吞吐量约为1.0，且在缓冲和实际吞吐量的所需数量之间没有其它可能权衡点。在此，ln(x)被定义为x的自然对数。使用TF可靠性控制协议，发送器上的总缓冲区大小至少为B且实际吞吐量约为B/(B+N)，其中B是以分组为单位的选定块大小，并可为了根据实际吞吐量权衡所需缓冲而作选择。相反，对于交织可靠性控制协议，发送器上总的缓冲区大小最多为B，且实际吞吐量约为N/(N+X)，其中X是为根据实际吞吐量权衡所需缓冲而选择的正整数参数，而B＝N*(1+ln((N/X)+1))是以分组为单位的缓冲区大小。
作为示例，如果速率R为1,000分组/秒而RTT为1秒，则N＝1,000分组。对于无码可靠性控制协议，发送器上的缓冲区大小为至少7,000个分组。对于TF可靠性控制协议，如果B被选为4,000个分组，则实际吞吐量约为0.80。对于其中X选为50的交织可靠性控制协议，B＝4,000个分组(与TF可靠性控制协议具有相同的值)且实际吞吐量超过0.95，即至多5％的接收分组被浪费。因而，在该示例中，交织可靠性控制协议需要比无码可靠性控制协议少得多的缓冲，而几乎有相同的最优实际吞吐量，且对于相同量的缓冲则远超过TF可靠性控制协议的实际吞吐量，即，交织可靠性控制协议的至多5％浪费传送对TF可靠性控制协议的25％的浪费。
实际上任何速率控制协议都可与交织可靠性控制协议一起使用，来提供一种可靠传输协议，例如以固定速率发送、使用与TCP相似的基于窗口的拥塞控制、使用诸如TCP友好速率控制(TFRC)的基于公式的拥塞控制协议、或使用实质上任何其它速率控制协议。
3.可靠传输协议
在本说明书中，可靠传输协议是一种以甚至在有可能未接收发送分组的一部分时传送所有数据的方法在基于分组的网络上将数据从发送器终端系统可靠地传送到接收器终端系统的协议。图1是其中可运行可靠传输协议的网络130、以及一组发送器终端系统100(1)、……、100(J)和接收器终端系统160(1)、……、160(K)。通常，这种协议还包括用于调整分组发送速率的一些机制，其中该发送速率可取决于各种因素，包括其中协议内建于其中的应用、用户输入参数、以及发送器和接收器终端系统之间的网络条件。
诸如TCP的可靠传输协议，通常包括若干步骤。这些步骤包括终端系统用来广告数据的可用性、发起数据向其它终端系统的传送、通知要传送哪些数据、并执行数据的可靠传送的方法。有各种各样的标准方法可使终端系统广告可用性、发起传送、并通知要传送什么，例如会话通告协议、会话发起协议等。因为这些步骤是众所周知的，所以不必在此赘述。
分组数据的可靠传送包括在传送的每一点上判断要在分组中发送什么数据，以及用什么速率发送这些分组。在每一点上及时作出的判断可取决于从接收器终端系统发送的反馈和其它因素。通常，数据作为数据流在发送器终端系统上出现，且可靠传输协议旨在将该流以发送它的相同顺序可靠地传送给接收器终端系统。常常有在发起传送前并不知道流的总长度的情形。
4.可靠传输协议的模块化体系结构
Adler描述了任何可靠传输协议可如何视为可靠性控制协议和速率控制协议的组合。可靠性控制协议是在传送期间判断要将什么数据置入每个分组的整体传输协议的一部分。速率控制协议判断何时发送每个数据分组。在许多传输协议中，可靠性控制和速率控制协议在运行时是交织在一起不可分的，即如TCP的情形。然而，即使在这种交织协议中仍然有在概念上可分成可靠性控制协议和速率控制协议的情形。
Adler提倡通过独立设计可靠性控制协议和速率控制协议来设计可靠传输协议。这种方法的优点是同一可靠性控制协议可与各种速率控制协议一起使用，从而同一可靠性控制协议可与适合该应用和其中使用该整体可靠传输协议的网络条件的速率控制协议一起使用。对该设计的模块化方法可相当有利，因为同一可靠性控制协议可与速率控制协议的不同集一起在不同应用和网络环境中使用，从而避免对每个应用和网络环境的整个可靠传输协议的完全再设计。例如，TCP用于不同网络环境的各种应用，且因为由其速率控制协议确定而获得的较差吞吐量，它对这些应用和网络环境的一部分运行得较差。不幸地是，因为可靠性控制协议和速率控制协议在TCP体系结构中作这样的交织，所以在运行较差的那些情形中只在TCP内使用不同的速率控制协议就改进其吞吐量性能是不可能的。
图2示出Adler中提倡的模块化可靠传输协议体系结构的示图。发送器传输协议210被分成发送器可靠性控制协议220和发送器速率控制协议230。发送器可靠性控制协议220确定在每个数据分组中发送什么，而发送器速率控制协议230确定何时发送每个数据分组。发送器可靠性控制协议220可将另外的可靠性控制信息置入由接收器传输协议290内的接收器可靠性控制协议280使用的每个数据分组中。发送器可靠性控制协议220还可从接收器传输协议290内的相应接收器可靠性控制协议280中，接收用来帮助确定在每个数据分组中发送什么的可靠性控制信息250。类似地，发送器速率控制协议230可将另外的速率控制信息置入可由接收器传输协议290内的接收器速率控制协议270使用的每个数据分组中。发送器速率控制协议230还可从接收器传输协议290内的相应接收器速率控制协议270中，接收用来帮助确定何时发送每个数据分组的速率控制信息250。
在发送器可靠性协议220和接收器可靠性协议280之间传送的可靠性控制信息可取决于诸如分组丢失的各种因素，并可包含各种信息，如下详细解释。类似地，在发送器速率协议230和接收器速率协议270之间传送的速率控制信息可取决于诸如分组丢失和实测往返时间(RTT)的各种因素。此外，可靠性控制信息和速率控制信息可部分重叠，即在数据分组240或在反馈分组250中发送的信息可用于可靠性控制和速率控制两者。一般而言，从发送器传输协议210发送到接收器传输协议290的可靠性控制和速率控制信息可与数据分组240中的数据一起发送，或用独立的控制分组240发送，或用两种分组发送。这些协议应设计成使在发送器和接收器之间发送所需控制信息的量最少。
对于许多应用，数据要作为流来传送，即，当数据到达发送器终端系统时，数据要以到达发送器终端系统的相同顺序尽可能快地可靠传送给接收器终端系统。对于一些应用，整体传输协议引入的等待时间应最小，例如，对于流式应用、或对于较小数据组尽可能快地在两个终端系统之间往返传送的交互式应用。因而，传输协议引入的整体等待时间应最小。
发送器可靠性控制协议220和接收器可靠性控制协议280通常都需要缓冲器来暂存数据。通常，在发送器可靠性控制协议220上缓存的数据包括：至少发送器可靠性控制协议220尚未接收到从接收器可靠性控制协议280中恢复的确认的流中的最早数据，直到发送器可靠性控制协议220已开始用数据分组发送的流中的最晚数据。接收器可靠性控制协议280上缓冲器的大小通常至少是流中从尚未恢复的最早数据到已接收数据分组的最晚数据的数据量。
发送器可靠性控制协议220的缓冲需求对发送器可靠性控制协议220需要多少暂存空间、以及发送器可靠性控制协议220向整体可靠数据传送引入多少等待时间有直接影响。接收器可靠性控制协议280的缓冲需求也有相似影响。因而，使发送器可靠性控制协议220和接收器可靠性控制协议280的缓冲需求最小是重要的。
可靠性控制协议确定在每个数据分组中发送什么。为了有效地利用终端系统之间的连接，重要的是发送器可靠性控制协议220在分组中发送尽可能少的冗余数据；为了确保在接收器可靠性控制协议280上接收什么数据分组，恢复原始数据流的各个部分是有用的。可靠性控制协议的实际吞吐量被定义为原始数据流的长度除以接收器可靠性控制协议280在恢复原始数据流期间接收的数据分组的总长度。实际吞吐量的目标是对于可靠性控制协议实际吞吐量结果在1.0左右，在该情形中为恢复原始数据流仅接收最少量的数据。在一些可靠性控制协议中，实际吞吐量可比1.0小，在该情形中所传送的数据分组的一部分被浪费。因而，将可靠性控制协议设计成使实际吞吐量尽可能地接近1.0，以便于有效地使用由从发送器终端系统传播到接收器终端系统的数据分组所消耗的带宽，是重要的。
5.基于FEC的可靠性控制协议
已用于可靠性控制协议的一种方案是前向纠错(FEC)码，诸如Reed-Solomon码、Tornado码、或连锁反应码(是信息附加码)。原始数据被分成比分组有效载荷大的块，然后编码单元从这些块中产生，并用分组来发送这些编码单元。诸如Reed-Solomon或Tomado码的删除校正码对固定长度的块产生固定数量的编码单元。例如，对于包括输入单元的块，可产生N个编码单元。这N个编码单元可包括B个原始输入单元和N-B个冗余单元。
基于FEC的可靠性控制协议是使用FEC码的可靠性控制协议。图3是发送器的基于FEC的可靠性控制协议220的说明性实施例，而图4是接收器的基于FEC的可靠性控制协议280的说明性实施例。发送器可靠性控制逻辑310将原始数据流分成多个数据块330，然后指示FEC编码器320产生每个块的编码单元。发送器可靠性控制逻辑310确定编码单元和可靠性控制信息340如何被传递给处理发送器速率控制协议230的设备，并且它还处理由图4所示的接收器的基于FEC的可靠性控制逻辑410发送的可靠性控制信息350。
发送器可靠性控制逻辑310应确保足够的编码单元由图4所示的接收器的基于FEC的可靠性控制协议280接收，以确保恢复每个块。所有块基本上长度相同，或者块的长度可在传送期间作为众多参数的函数动态变化，这些参数包括数据流对发送器可用的速率、数据分组的发送速率、网络条件、应用要求和用户要求。
假设给定数据块的长度是B个编码单元。对于一些FEC码，恢复原始数据块所需的编码单元数量正好为B，而对于其它FEC码，恢复原始数据块所需的编码单元数量略大于B。为了简化基于FEC的可靠性控制协议的描述，假设B个编码单元足以恢复数据块，其中可以理解，为了解码块，需要B个以上编码单元的FEC码可用于略减的实际吞吐量和略增的缓冲需求。
图4中的接收器可靠性控制逻辑负责确保为了解码数据块接收B个编码单元，然后FEC解码器420用来恢复数据块430。接收器可靠性控制逻辑410负责接收从发送器的基于FEC的可靠性控制协议220中发送的编码单元和可靠性控制信息340，并负责产生和发送可靠性控制信息350，该可靠性控制信息350最终发送给发送器可靠性控制逻辑310，并由其进行处理。
6.TF可靠性控制协议
TF可靠性控制协议将数据流分成一般相等大小的块。整个体系结构是：在任何时间点上都有一个活动数据块，且发送器产生并发送该数据块的编码单元，直到它从接收器接收到表示已有足够的用以重构块的编码单元到达的消息，此时发送器继续到下一个块。因而，在后续块的任何编码单元产生和发送之前，产生和发送给定块的所有编码单元，并恢复该块。
图5示出可由TF可靠性控制协议使用的一个可能格式集。发送器数据格式描述发送器的TF可靠性控制协议向接收器的TF可靠性控制协议发送编码单元和相应可靠性控制信息的格式。这包括：块号510，指示编码单元从哪个块中产生；编码单元ID 520，指示编码单元如何从该块中产生；以及编码单元530，可由接收器的TF可靠性控制协议内的FEC解码器用来恢复该块。接收器反馈格式描述接收器的TF可靠性控制协议向发送器的TF可靠性控制协议发送可靠性控制信息的格式。这包括：块编号540，即接收器的TF可靠性控制协议正在接收的编码单元用来恢复的当前块的块号；以及所需编码单元550，是接收器的TF可靠性控制协议恢复该块所需的附加编码单元的数量。
图6是用于实现发送器的TF可靠性控制协议的过程的一说明性实施例。该过程持续检查现在是否是发送发送器数据的时间(步骤610)，这由相应的发送器速率控制协议确定。如果是发送发送器数据的时间，则从活动块中产生编码单元并发送该发送器数据(620)。发送器数据形式的一个示例如图5所示。该过程还持续检查是否接收到了接收器反馈(630)。接收器反馈数据形式的一个示例如图5所示。如果有接收器反馈，则处理之以更新接收器恢复该活动块需要多少附加编码单元的信息。然后检查是否所需编码单元的数量为零(640)，如果是则查看数据流的下一块是否可用(650)。如果不可用，则在下一框660中做准备直至已准备完毕，然后停用当前活动块，并激活下一块(670)。一般而言，下一个块可在传送当前活动块时做准备。
应理解，在此所述的协议的每一种都可以由适当处理器执行的设备、或软件、或固件来实现。例如，可使用诸如路由器和主计算机的网络设备来实现，并在无线传送器、中继传送器和其它无线设备上实现。在此所述的协议可用软件实现，并具有实配置为现这些协议的方法和/或装置。
图7是用于实现接收器的TF可靠性控制协议的过程的一说明性实施例。接收器的TF可靠性控制协议持续检查是否已接收图5所示的发送器数据格式的发送器数据(710)。如果是，则检查发送器数据内的编码单元是否来自活动块(720)。如果编码单元并非来自该活动块，则丢弃(760)，从而这是浪费了的发送器数据，因为它并未用于恢复任何块。如果编码单元来自该活动块，则将其添加到已为活动块接收的编码单元集中，并且块的编码单元的所需数量减1(730)。然后检查所需编码单元的数量是否为零(740)，且如果是，则它使用FEC解码器恢复该活动块，并准备接收下一活动块的编码单元(750)。接收器的TF可靠性控制协议还持续检查现在是否是发送接收器反馈的时间(770)，这由相应的接收器速率控制协议确定。如果是时间，则准备并发送图5所示的接收器反馈格式的接收器反馈(780)。
注意，这是整体TF可靠性控制协议的部分描述。例如，它未指定由接收器TF可靠性控制协议发送接收器反馈的条件。这可通过接收已接收的发送器数据、通常中断的定时器、或这些事件或由接收器速率控制协议确定的任何其它事件的任意组合触发。一般而言，接收器反馈的发送常常频繁到足以使发送器TF可靠性控制协议在经常性基础上得到有关在接收器的TF可靠性控制协议上接收编码单元的进度的通知，却仍然不够频繁以消耗与包含编码单元的发送器数据从发送器的TF可靠性控制协议发送到接收器的TF可靠性控制协议一样多的带宽。
注意，TF可靠性控制协议在以下意义上可被视为“浪费”。设B为以编码单元为单位的每个数据块的大小，设R为分组通过速率控制协议发送的速率，设RTT为发送和接收器终端系统之间的往返时间，并设N＝R*RTT。假设在发送器和接收器之间没有分组丢失。则在发送器的TF可靠性控制协议已发送了活动块的B个编码单元(足以恢复该块)之后，它继续发送N个额外的编码单元直到它从接收器TF可靠性控制协议接收到接收器反馈，指示足够的用以恢复该块的编码单元已到达以及全部这N个编码单元被浪费。为了恢复长度为B的块需要发送B+N个编码单元，因而实际吞吐量为B/(B+N)。如果B与N相比相对较小，则实际吞吐量远低于最优，且发送器和接收器之间的大量使用带宽被浪费。另一方面，如果B与N相比较大，则发送器和接收器的TF可靠性控制协议中缓冲器的大小会较大，这也隐含接收器上数据流的传送中等待时间会较长。作为一个示例，假设编码单元的大小为1千字节，速率R是1,000个编码单元/秒＝1兆字节/秒＝8兆比特/秒，而RTT为1秒。然后N＝R*RTT＝1兆字节。如果块的大小被设置为B＝3兆字节，则实际吞吐量约为(B/(B+N))＝0.75，即所发送编码单元的25％被浪费。为了将实际吞吐量升至例如0.98使仅约2％的所发送编码单元被浪费，需要极大的缓冲器大小B＝49兆字节。这样大小的缓冲器可导致可靠性控制协议添加的等待时间至少为50秒。
上述TF可靠性控制协议有许多变体。例如，发送器TF可靠性控制协议可在已从块发送B个编码单元之后停止发送编码单元，并等待接收接收器反馈，以指示是否已接收足够编码单元来恢复该块。如果没有丢失，则该变体甚至在每个块的之间有RTT时间间隔时，也将不发送任何将被浪费的编码单元，并且如果该带宽未用于任何其它目的，则该协议仍然导致R*RTT的带宽浪费量。此外，整体传送时间将比理想状况慢B/(B+N)的系数。如果有丢失，则该变体将添加更多等待时间，并使传送变慢，因为实际上将不得不发送附加编码单元以代替丢失的编码单元来恢复该块。
7.交织可靠性控制协议
TF可靠性控制协议具有优于无码可靠性控制协议的一个优点，因为任何丢失的编码单元都可通过从同一块产生的任何随后接收的编码单元进行补偿，而无需接收器反馈。TF可靠性控制协议浪费的主要原因在于该协议的连续本质，即每个块的传送在下一个块的传送开始之前完成。在此所述的经改进的可靠性控制协议可用来以智能方式交织多个块的处理。
交织的一个说明性示例如图8所示。在该示例中，有两个活动块一第一活动块AB 1(810)和第二活动块AB 2(820)。图8的下半部分示出随时间发送的数据分组的模式的一个示例，其中每个分组取决于相应分组是否包含AB 1或AB 2的编码单元而标示为AB 1或AB 2。在该示例中，首先发送包含AB 1的编码单元的4个分组(830(1)、830(2)、830(3)和830(4))，然后是包含AB 2的编码单元的2个分组(830(5)、830(6))，随后是包含AB 1的编码单元的1个分组(830(7))、包含AB 2的编码单元的1个分组(830(8))、以及包含AB 1的编码单元的1个分组(830(9))。一般而言，不同块的编码单元之间的交织应被设计成使实际吞吐量最大，并使总的缓冲要求(和结果所引入的等待时间)最小。
图9示出可由交织可靠性控制协议使用的一个可能格式集。发送器数据格式描述发送器的交织可靠性控制协议能将编码单元和相应可靠性控制信息发送给接收器的交织可靠性控制协议的格式。该示例包括：块号910，指示编码单元从哪个块产生；序列号920，指示多少编码单元已从该块发送；编码单元ID 930，指示编码单元如何从该块中产生；以及编码单元940，可由接收器的交织可靠性控制协议的FEC解码器用来恢复该块。接收器反馈格式描述接收器的交织可靠性控制协议可向发送器的交织可靠性控制协议发送可靠性控制信息的格式。对于每个活动块，这包括块号(950(1)、950(2))、需要多少附加编码单元来恢复该块(960(1)、960(2))、以及从该块接收的最高序列号(970(1)、970(2))。
图10是基本发送器的交织可靠性控制协议的逻辑的一说明性实施例。在该协议的这个版本中，基本发送器的交织可靠性控制协议持续检查现在是否是发送发送器数据的时间(1005)，这由相应的发送器速率控制协议确定。如果是发送发送器数据的时间，则该基本发送器的交织可靠性控制协议使用以下的一组规则来确定从哪个活动块来产生和发送编码单元。
基本发送器的交织可靠性控制协议跟踪每个活动块i的以下变量(1010)：B_i是恢复该块所需的编码单元的数量；R_i是基本发送器的交织可靠性控制协议基于所接收的接收器反馈，知道基本接收器的交织可靠性控制协议已从该块接收的编码单元的数量；L_i＝B_i-R_i是基本发送器的交织可靠性控制协议知道基本接收器的交织可靠性控制协议需要接收、用以恢复该块的剩下未经确认的编码单元的数量；U_i是为该块发送的但确认尚未由基本发送器的交织可靠性控制协议接收的编码单元的数量；X_i是确定基本发送器的交织可靠性控制协议将如何积极发送该块的编码单元的参数。
这些变量可确定如下：B_i的值由块的大小和每个编码单元的大小确定。一般而言，每个编码单元的大小都相同，且大小被选为适合数据分组的有效载荷，例如，编码单元的长度可以是1024字节。每个块的大小通常可相同，或者可变化，或者它可取决于发送器上数据流的到达速率，或者它可取决于数据分组的发送速率，或者它可取决于这些和其它因素的组合。R_i的值基于在步骤1030接收的接收器反馈确定。U_i的值是所发送的包含块的编码单元的最后发送器数据中的序列号与在块的接收器反馈中接收的最高序列号之间的差值。
X_i的值是整体可靠性控制协议的函数，并如下所述在选择X_i时有权衡。X_i的值可在发送块的所有编码单元时可保持为常数，或者它能用各种不同方法改变值，其中一些方法在后面作解释。实际上，每个时间点上的X_i是基本发送器的交织可靠性控制协议愿意在恢复该块所需的最少量之外发送多少附加编码单元，而无需来自基本接收器的交织可靠性协议的任何附加接收器反馈的度量。因为L_i是除已确认接收的编码单元之外恢复块i所需编码单元的数量，并且因为U_i是块i的进行中但尚未确认的编码单元的数量，所以L i+X_i-U_i是基本发送器的交织可靠性控制协议在该时间点上愿意发送的块i的附加编码单元的数量。对X_i值的权衡如下。当X_i增加时实际吞吐量减少，因为可能除恢复活动块i所需的最少量之外可能有最多达X_i个编码单元可由基本接收器的交织可靠性控制协议接收。另一方面，当X_i增加时活动块的总大小减少，因为当X_i增加时用以完成活动块i的可靠接收的分组时隙的数量减少。这是因为块i的X_i个编码单元可能丢失，而基本接收器能恢复该块而无需等待接收器反馈来触发附加编码单元的传送。结果是，总缓冲区大小和实际吞吐量之间的权衡作为X_i的函数，比诸如TF可靠性控制协议或无码可靠性控制协议的其它可靠性控制协议的相应权衡要好得多。
在步骤1015，作测试以确定是否有活动块i满足不等式L_i+X_i-U_i＞0。L_i的值表示基于接收器反馈已确认的编码单元，接收器将需要多少编码单元来恢复该块。U_i是该块的进行中的未经确认编码单元的数量，从而L_i-U_i是进行中的所有编码单元都未丢失时必须发送的附加编码单元的数量，因此如果该数量为零或更小，则在进行中的该块的所有编码单元都到达时接收器将能够恢复该块。另一方面，部分解码单元可能会丢失，并且X_i是发送器愿意事先发送的附加编码单元的数量，以免遭在随后接收器反馈触发后不得不传送该块的附加编码单元的损失。因而，如果L_i+X_i-U_i＞0，则发送器愿意发送块i的更多编码单元，并且如果它是0或负数，则发送器不愿意发送块i的更多编码单元。因而，如果在步骤1015有满足L_i+X_i-U_i＞0的活动块i，则在步骤1020产生编码单元并发送最早的这种活动块的相应发送器数据。如果没有这样的活动块，则在步骤1025产生编码单元并从所有活动块中的最早活动块发送相应的发送器数据。各参数最好设置成尽可能地避免没有块满足步骤1015中的条件而迫使执行步骤1025，因为实际上步骤1025应作为最后一步完成以清除基本发送器的交织可靠性控制协议内的缓冲器。
该协议的一种变体如下。活动块的数量从1开始，即数据流的第一个块被激活。仅当没有活动块满足步骤1015中的条件时，才激活数据流中的新块。使用该简单策略，各块仅在需要时变成活动块，从而活动块的数量以及因此缓冲器的大小都自己调节成保证块i的实际吞吐量B_i/(B_i+X_i)所需的数量。
该协议的另一种变体如下。在该变体中，总的缓冲器大小总是保持相同(如果所有的块大小都相同，则表示总是有固定数量的活动块)，而实际吞吐量可变。在没有满足步骤1015条件的活动块的任何时候，活动块的X_i值增加直到出现满足步骤1015条件的活动块。在任何适当时候，活动块i的X_i值减小，其约束是总有一个活动块满足步骤1015的条件。有许多种增减X_i的值的可能方法，例如同等地增加所有值、比例相同地增加所有值、使第一活动块的值比最后一个活动块的值增加更多、使最后一个活动块的值比第一活动块的值增加更多。相似的策略可用来减少X_i的值。本领域技术人员也可想到其它变体。
有太多而难以一一描述的该协议的这些变体的许多其它组合和扩展，但对本领域技术人员是显而易见的。
在步骤1030，检查是否接收到任何接收器反馈，并且如果是，则在步骤1035基于此更新全部的参数，即全部活动块i的参数R_i、U_i和X_i。在步骤1040检查最早的活动块是否已被确认为完全恢复，并且如果是，则在步骤1045和1050准备下一个块，并在步骤1055使最早的活动块停用并激活下一个块。一般而言，下一个块或若干块可在传送当前活动块的同时作准备，并在停用最早活动块时或之前准备激活。
图11是基本接收器的交织可靠性控制协议的逻辑的一说明性实施例。在该协议的这个版本中，基本接收器的交织可靠性控制协议持续检查是否已接收发送器数据(1105)，这例如可以是图9所示的发送器数据格式。如果是，则在步骤1110更新其有关所有活动块的信息，并检查发送器数据内的所接收编码单元是否来自活动块(1115)。如果编码单元来自已恢复的块或来自在数据流中太靠前而暂不会成为当前活动块的块，则在步骤1135丢弃之。否则，在步骤1120，编码单元被添加到它从中产生的活动块的编码单元池中，并更新恢复该活动块需要多少编码单元。
块i的所需编码单元的数量被计算为B i减去所接收编码单元的数量。有将B_i的值传送给基本接收器的交织可靠性控制协议的各种方法，例如，B_i的值可包括在每个发送器数据内，B_i的值可用独立控制消息发送，B_i的值可对所有块相同并在会话发起期间传送。
然后在步骤1125检查最早激活块的编码单元的所需数量是否为零，且如果是，则它在步骤1130使用FEC解码器恢复该活动块，并准备接收新的下一活动块的编码单元。基本接收器的交织可靠性控制协议还持续检查现在是否是发送接收器反馈的时间(1140)，这由相应的接收器速率控制协议确定。如果是，则在步骤1145准备并发送接收器反馈，例如可以是图9所示的发送器数据格式。
注意，以上是整体的基本交织可靠性控制协议的部分描述。例如，它未指定接收器反馈由基本接收器的交织可靠性控制协议发送的条件。这可通过所接收发送器数据的接收、通过经常中断的计时器、或通过这些事件或由接收器速率控制协议确定的任何其它事件的任何组合来触发。一般而言，接收器反馈的发送常常频繁到足以使基本发送器交织可靠性控制协议在经常性基础上得到有关基本接收器交织可靠性控制协议上接收编码单元的进度的通知，却仍然不够频繁以消耗与包含编码单元的发送器数据从基本发送器交织可靠性控制协议发送到基本接收器交织可靠性控制协议一样多的带宽。
基本的交织可靠性控制协议可在实际吞吐量和缓冲器的大小之间比TF可靠性控制协议或无码可靠性控制协议有好得多的权衡。例如，假设对基本的交织可靠性控制协议有至多两个活动块。设B为以编码单元为单位的每个数据块的大小，设R为速率控制协议发送分组的速率，设RTT为发送器和接收器终端系统之间的往返时间，并设N＝R*RTT，并假设X是对所有活动块的固定常数。在该示例中，假设所有这些参数都具有固定值，尽管一般而言它们可在数据传送期间动态变化，并假设B＞＝N。
假设在发送器和接收器之间没有分组丢失。然后，基本的发送器交织可靠性控制协议发送最早活动块的B+X个编码单元，然后从下一活动块发送编码单元直到它通过基本的接收器交织可靠性控制协议接收到指示最早活动块已成功恢复的接收器反馈。此时基本发送器交织可靠性控制协议停用最早活动块，已发送一些编码单元的下一活动块变成最早活动块，并激活下一个块变成活动块。因而，B+X个编码单元被用来恢复长度为B的块，从而所发送的X个编码单元被浪费。另一方面，如果B＞＝N，则总是会有一个活动块满足图9步骤1015中所示的不等式。因而，实际吞吐量为(B/(B+X))，而如果有两个活动块则缓冲器的总大小为2*B。作为示例，假设编码单元的大小为1千字节，则速率R为1,000编码单元/秒＝1兆字节/秒＝8兆比特/秒，且RTT为1秒。然后N＝R*RTT＝1兆字节。如果块的大小被设置成B＝1兆字节，而X被设置成10，则实际吞吐量约为(B/(B+X))＝0.99，即至多浪费所发送编码单元的1％，而总的缓冲器大小仅为2MB，这意味着基本的发送器交织可靠性控制协议在该示例中添加约2秒的等待时间。注意，该缓冲器大小比相同情形中发送器的TF可靠性控制协议的小，约为其25分之一。
在上述没有分组丢失的示例中，X值可被设置为零，将实际吞吐量增至最高达1.0。然而，当有任何分组丢失时，结果是设置X＞0可具有相当多的优点。例如，如果在以上示例中每1,000个发送的编码单元中至多有10个丢失，则分析显示相同的实际吞吐量和缓冲器大小用X＝10实现，而对X＝0则未必如此了。当分组丢失更为可变和未知时，特别是当每B个分组中所丢失分组的数量大于X时，结果是可由基本的交织可靠性控制协议实现的实际吞吐量和缓冲器大小相当好，并且可计量地优于使用TF可靠性控制协议或无码可靠性控制协议可实现的实际吞吐量和缓冲器大小。
作为另一示例，假设以分组/秒为单位的发送速率R和往返时间RTT保持不变，且N＝R*RTT。假设分组丢失是随机的，从而每个分组有p的丢失概率。还假设每个大小为B_i的块i具有相同的以分组为单位的大小C，且每个X_i都具有相同的值Y。再假设使用上述在需要时仅激活一新块的协议的变体。考虑从首次激活块时到因为确认已恢复而停用该块时从接收器接收该块。在已确认该块的C-N个分组的某时间t，有F＝N+Y个尚未确认的进行中分组，且发送器知道接收器需要这些分组中的N＝F-Y个来完成该块。在t+RTT时，时间t时块的进行中的F个分组中，接收器已接收到全部分组的(1-p)*F，且发送器已接收到确认。因而，在t+RTT时，发送器知道接收器所需的剩余分组的数量是N-(1-p)*F＝p*F-y，从而进行中分组的数量为p*F。继续该逻辑，在t+i*RTT时，发送器知道接收器需要的分组数量为p^i*F-y，从而进行中分组的数量为p^i*F。当发送器知道接收器所需的分组数量变成小于0时，则该块完成，且在时间t+i*RTT时i满足p^i*F-Y＜＝0。当该不等式为真时i的最小值是i约为ln((N+Y)+1)/ln(1/p)时。因为每个RTT中接收器接收约(1-p)*N个分组，这表示在确认接收该块时发送器协议能在数据流中处理的离所考虑块最远的为至多(ln((N/Y)+1)/ln(1/p))*(1-p)*N个分组。注意，对于所有的p值，(1-p)/ln(1/p)＜＝1，这表示缓冲器的大小在长度上最多为C+ln((N/Y)+1)*N个分组。当然，这都基于随机过程像其期望行为一样动作的假设，但这的确给出了该协议如何动作的大概思路，至少在Y不那么小时。在该情形中，实际吞吐量为C/(C+Y)。因而，例如，如果RTT＝1，R＝1,000，C＝1,000，Y＝50，则缓冲器大小约为至多4,000，且实际吞吐量为0.95。
有关上述基本交织可靠性控制协议的许多变体在阅读本说明书后应显而易见。例如，如上所述，发送器可靠性控制协议一次可使用两个以上活动块，并具有以管理更多活动块的更大复杂性为代价，减少在发送器和接收器可靠性控制协议上使用的缓冲器的整体大小的可能优点。
作为另一个变体示例，使用随机过程来确定编码单元从哪个活动块发出是有利的。这是因为分组丢失模式可以是系统的且不一定是随机的，所以对于选择接下来要发送哪个编码单元的任何确定性过程，有一些块永远不恢复但仍然有分组被传送给发送器的分组丢失模式。例如，考虑这样一种丢失模式：在确定性过程发送来自特定活动块的编码单元的任何时候该编码单元丢失，而在它发送任何其它活动块的编码单元的任何时候该编码单元到达接收器。则在该示例中，即使接收器仍然接收编码单元，接收器也永远不恢复该活动块。为了克服此类系统性丢失，对于发送器可靠性控制协议而言使从哪个活动块发送下一编码单元随机化是有利的。一种简单的实现方法是发送器可靠性控制协议一起缓存多批要发送的Q个编码单元，然后以随机顺序发送每批Q个编码单元。也可使用更复杂的方法，例如，对于每个要发送的编码单元，分配下次发送要发送编码单元的动态变化概率，其中概率随未被选中的次数增加。另一个变体是更改基本发送器的交织可靠性控制协议的图10所示步骤1020，使所发送的编码单元从满足步骤1015中条件的活动块中随机产生(使用可偏向更早活动块、并可随时间动态改变的适当选择的概率分布)。
如果参数X_i用来确定何时发送活动块i的编码单元，则有很多有关如何在传送期间调整X_i的变体。一个示例是使X_i固定为一个值，并在传送期间保持该值。例如，X_i可被设置成0，或像10的一些其它固定值。另一个示例是在开始从活动块i传送编码单元时将X_i固定为一个值，然后在每发送一个编码单元时以及不满足从活动块i发送编码单元的条件时就使X_i增大。有关X_i如何增大有很多变体。作为一个示例，X_i在前N次时可增大0，而在随后每一次增大N/B。在某些步骤上X_i的增大还可能是负的。
作为其它变体，与如基本交织可靠性控制协议中所述地仅对每个活动块i使用参数X_i相反，可使用其它确定编码单元是否应从特定活动块发送的方法。例如，分组丢失概率的平均值可得到保持，且允许从活动块发送的编码单元的数量可基于最近的分组丢失概率是对当前分组丢失概率的较好预测值的假设来确定。例如，如果目前平均丢失概率为p，则一种策略是更改基本发送器的交织可靠性控制协议的图10所示步骤1015，使条件为L_i+X_i/(1-p)-U_i*(1-p)＞0。该特定选择后面的基本原理是：如果有活动块i的U_i个编码单元在进行中，则仅有其1-p部分将到达基本接收器的交织可靠性控制协议，并且如果发送X_i/(1-p)个附加分组，则X_i将在基本接收器的可靠性控制协议上到达。因而，基本接收器的交织可靠性控制协议总的平均将接收活动块i的B_i+X_i个编码单元，且X_i个附加编码单元的值可被设置成足以考虑分组丢失速率的可变性，以避免依赖对足够数量编码单元的传送的接收器反馈来恢复该块。
交织可靠性控制协议的其它变体考虑分组在接收器上不以与发送顺序相同的顺序到达的可能性。因而，随后来自接收器的接收器反馈可例如报告返回比先前接收器反馈更多数量的给定活动块的接收编码单元，即使从该块接收的最高序列号是相同的。因而，基本交织可靠性控制协议中的逻辑可在发送器和接收器中更改，以容纳对重新排序分组的说明。
如前所述，如图10所示的基本发送器的交织可靠性控制协议的步骤1025通常通过适当地设置参数使在每个时间点上都有至少一个活动块满足条件1015来避免。步骤1025的变体是改变选择从中产生和发送编码单元的活动块。例如，在步骤1025可随机选择活动块，或者该选择可通过活动块的集合来循环。
图10的步骤1045表示一旦最早活动块停用就立即激活下一个块。可节省总缓冲器大小和结果等待时间的变体是，在从除最近当前活动块之外的块中发送编码单元时只激活下一个块。
如上所述的基本交织可靠性控制协议隐含地假设，在任何时间点上的活动块数量是固定的。一种变体是允许活动块的数量根据各种因素变化，包括数据可以什么速率进行传送、发生多少分组丢失、分组发送速率中的可变性等。例如，在低分组丢失条件和低发送速率条件下，活动块的数量可保持较少，而当丢失条件变差或者发送速率增大时，可允许活动块的数量暂时增加。因而，缓冲和等待时间取决于协议运行的条件而动态地变化。
即使活动块的数量保持固定，也可允许活动块的聚合大小变化。在该情形中，每个随后活动块的大小可与前一个块的不同。例如，当数据可用性速率增大时随后活动块的大小也增大，并且当发送速率增大时随后活动块的大小也增大。每个活动块的长度可以是时间的函数，例如在形成一个新块之前至多会过去这么长时间，可以是长度的函数，即每个块可以至多就这么长，或者它可以是这些和其它因素的组合。
一个块的结束和下一个块的开始可由交织可靠性控制协议自动判断，它可根据应用、或这些和其它因素的组合确定。例如，数据流的块可具有应用的逻辑意义，例如图像组块或MPEG流的I-帧，因而交织可靠性控制协议将数据流分成多个块的方法可考虑逻辑应用块的界限。或者，应用可向交织可靠性控制协议指示各块之间的较佳界限，且交织可靠性控制协议尝试尽可能好地考虑这些界限，但仍然得到允许在应用提供的点旁边设置各块之间的界限。
交织可靠性控制协议的另一种变体是允许协议不向接收器可靠地按顺序传送所有块，而相反尽可能地尝试服从其它约束地实现该目标。例如，在流式应用中，尽可能可靠地传送数据流是重要的，但也有诸如数据流定时约束的其它约束。例如，会是这样的情形：在某时间之后数据的某一部分不再相关，或者对交织可靠性控制协议在例如交互式视频会议应用中能引入多少等待时间有较强限制。在这些情形中，发送器的交织可靠性控制协议和接收器的交织可靠性控制协议可更改，以允许在块完全恢复之前跳过部分块。例如，发送器的交织可靠性协议可受到只允许活动块活动给定时间的限制，或者它对应用提供的每个块都可有严格的时间约束，在该时间之后不再允许发送该块的编码单元，或者它仅允许发送所提供的每个块的最大数量编码单元，或这些约束的任何组合。类似的约束也可应用于接收器的交织可靠性控制协议。对于这些应用，交织可靠性控制协议可进行更改以考虑这些约束。
在交织可靠性控制协议的一些变体中，有一个发送器和一个接收器。其它变体包括但不限于：一个发送器和多个接收器；一个接收器和多个发送器；多个发送器和多个接收器。例如，在一个发送器/多个接收器的变体中，当发送信道是广播或多播信道时，发送器可靠性控制协议可更改，从而发送器为每个活动块i计算R_i值，作为在图10的步骤1010中来自任何接收器的获接收确认的编码单元的最少数量。作为一个发送器/多个接收器的变体的另一示例，当发送器向每个接收器发送独立的分组流时，发送器可靠性控制协议可更改，从而发送器为每个活动块i和每个接收器j计算R_ij值，作为来自接收器j的对活动块i的获接收确认的编码单元的数量，并计算图10步骤1010中的L_ij＝B_i-R_ij，且U_ij可被计算为发送给接收器i的活动块i的已发送但未确认编码单元的数量，然后步骤1015中的条件可改变以确定是否有活动块i，从而对于一些接收器j，L_ij+X_i-U_ij＞0。作为另一示例，对于多个发送器/一个接收器的变体，接收器可靠性控制协议可更改，从而接收器从多个发送器并发地接收相同或不同活动块的编码单元，并通过广播或多播信道向所有发送器发送接收器反馈，或者对每个发送器使用具有可能独立的接收器反馈的独立分组流。作为另一示例，对于多个发送器/多个接收器变体，可组合以上对一个发送器/多个接收器情形和多个发送器/一个接收器情形描述的更改后步骤。
另一个变体是发送器可并发地发送多个数据流，每个数据流使用发送器交织可靠性控制协议的一个独立实例，或者考虑不同数据流的发送器交织可靠性控制协议的一个版本，例如，所有流的所有分组的聚合发送速率可受到限制，因而发送器可决定使得一些数据流的分组比其它的优先发送。类似地，接收器可并发地接收多个数据流，每个数据流使用接收器交织可靠性控制协议的一个独立实例，或者考虑不同数据流的接收器交织可靠性控制协议的一个版本，例如，所有流的所有分组的聚合接收速率可受到限制，因而发送器可决定使得一些数据流的分组比其它的优先接收，并使得一些数据流的接收器反馈比其它的优先处理和发送。
以上变体的任一个可彼此组合。例如，一些块因为例如定时和/或带宽限制而不能可靠传送给接收器的协议可与多个发送器/多个接收器的变体组合。

Claims (9)

1.一种可靠地从发送器向接收器传输数据的方法，所述方法包括：
将要传送的数据组织成数据块，其中每个数据块包括多个编码单元；
将第一数据块的编码单元从发送器传送给接收器；
在发送器上检测接收器接收编码单元的确认；
在发送器上，确定接收器接收足够的用以在接收器上恢复第一数据块的第一数据块的编码单元的概率；
根据概率阈值测试所述概率来确定是否满足预定测试；
在测试步骤之后并在接收器接收第一数据块在接收器上恢复的确认之前，当满足预定测试时，从发送器传送第二数据块的编码单元；以及
如果在发送器上接收到了恢复第一数据块失败的指示，则从发送器向接收器发送更多的第一数据块的编码单元。
2.如权利要求1所述的方法，其特征在于，每个编码单元都是IP分组。
3.如权利要求1所述的方法，其特征在于，失败的指示是从接收器发送并由发送器接收的明确失败通知。
4.如权利要求1所述的方法，其特征在于，失败的指示是响应于发送器上未能接收到来自接收器的在所确定时段内成功恢复第一数据块的确认而为发送器产生的。
5.如权利要求1所述的方法，其特征在于，第一数据块的其它编码单元是不同于在所述测试步骤之前发送的编码单元的附加编码单元。
6.如权利要求1所述的方法，其特征在于，第一数据块的其它编码单元是测试步骤之前发送的编码单元的近期副本。
7.如权利要求1所述的方法，其特征在于，编码单元使用连锁反应编码过程编码。
8.如权利要求1所述的方法，其特征在于，编码单元使用Tornado编码过程编码。
9.如权利要求1所述的方法，其特征在于，编码单元使用具有预定码率的前向纠错编码过程编码。
CNB2004800286287A 2003-10-08 2004-10-08 基于前向纠错(fec)的可靠性控制协议 Expired - Fee Related CN100550652C (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US50997603P 2003-10-08 2003-10-08
US60/509,976 2003-10-08

Related Child Applications (1)

Application Number Title Priority Date Filing Date
CN200910165996.0A Division CN101656731B (zh) 2003-10-08 2004-10-08 基于前向纠错(fec)的可靠性控制协议

Publications (2)

Publication Number Publication Date
CN1864335A true CN1864335A (zh) 2006-11-15
CN100550652C CN100550652C (zh) 2009-10-14

Family

ID=34435044

Family Applications (2)

Application Number Title Priority Date Filing Date
CN200910165996.0A Expired - Fee Related CN101656731B (zh) 2003-10-08 2004-10-08 基于前向纠错(fec)的可靠性控制协议
CNB2004800286287A Expired - Fee Related CN100550652C (zh) 2003-10-08 2004-10-08 基于前向纠错(fec)的可靠性控制协议

Family Applications Before (1)

Application Number Title Priority Date Filing Date
CN200910165996.0A Expired - Fee Related CN101656731B (zh) 2003-10-08 2004-10-08 基于前向纠错(fec)的可靠性控制协议

Country Status (6)

Country Link
US (2) US7447235B2 (zh)
EP (1) EP1671424B1 (zh)
JP (1) JP4685787B2 (zh)
KR (1) KR101035219B1 (zh)
CN (2) CN101656731B (zh)
WO (1) WO2005036361A2 (zh)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN104579550A (zh) * 2013-10-29 2015-04-29 三星Sds株式会社 数据传送装置及方法
WO2021227781A1 (zh) * 2020-05-13 2021-11-18 华为技术有限公司 数据帧的传输方法和通信装置

Families Citing this family (56)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CA2701502C (en) 2003-06-18 2014-08-05 Nippon Telegraph And Telephone Corporation Wireless packet communication method
JP4685787B2 (ja) 2003-10-08 2011-05-18 デジタル ファウンテン， インコーポレイテッド Ｆｅｃベース信頼度制御プロトコル
US8077743B2 (en) * 2003-11-18 2011-12-13 Qualcomm Incorporated Method and apparatus for offset interleaving of vocoder frames
US20050187979A1 (en) * 2004-02-09 2005-08-25 Microsoft Corporation System and method for message-level connection management
US8184657B2 (en) * 2004-09-23 2012-05-22 Sony Corporation Reliable audio-video transmission system using multi-media diversity
US8374087B2 (en) * 2004-09-23 2013-02-12 Sony Corporation Reliable audio-video transmission system using multi-media diversity
US7788393B2 (en) * 2005-02-23 2010-08-31 Cisco Technology, Inc. Switching a client from unicasting to multicasting by increasing the unicast stream rate to the client
US8140699B2 (en) * 2005-02-23 2012-03-20 Cisco Technology, Inc. Switching a client from unicasting to multicasting by simultaneously providing unicast and multicast streams to the client
US7657816B2 (en) * 2005-07-13 2010-02-02 Leanics Corporation Low-complexity hybrid LDPC code encoder
US7596673B2 (en) * 2005-12-08 2009-09-29 Sony Corporation Failure tolerant data storage
JP4722693B2 (ja) * 2005-12-16 2011-07-13 Ｋｄｄｉ株式会社 通信システム
US8713195B2 (en) 2006-02-10 2014-04-29 Cisco Technology, Inc. Method and system for streaming digital video content to a client in a digital video network
JP4808054B2 (ja) * 2006-03-17 2011-11-02 富士通株式会社 データ転送方法及び，これを適用する通信システム及びプログラム
WO2008013528A1 (en) * 2006-07-25 2008-01-31 Thomson Licensing Recovery from burst packet loss in internet protocol based wireless networks using staggercasting and cross-packet forward error correction
US7895347B2 (en) * 2007-07-27 2011-02-22 Red Hat, Inc. Compact encoding of arbitrary length binary objects
US8442070B1 (en) * 2008-02-01 2013-05-14 Hobnob, Inc. Fractional threshold encoding and aggregation
FR2935862B1 (fr) * 2008-09-08 2014-09-05 Canon Kk Procede de prediction du taux d'erreurs de transmission dans un reseau de communication et serveur mettant en oeuvre un tel procede
US20100142522A1 (en) * 2008-12-04 2010-06-10 James Gardner Methods and apparatus for adaptive error correction in networks
EP2396989B1 (en) * 2009-02-10 2016-08-17 Telefonaktiebolaget LM Ericsson (publ) A network element and a method of operating a network element in a telecommunications network
JP2010213150A (ja) * 2009-03-12 2010-09-24 Nec Corp 送信装置、大容量ファイル配信システム、同システムにおけるファィル再送制御方法、再送制御プログラム
EP2302845B1 (en) 2009-09-23 2012-06-20 Google, Inc. Method and device for determining a jitter buffer level
JP2011193434A (ja) 2009-10-28 2011-09-29 Panasonic Corp パリティパケットを用いた通信方法、通信装置及び中継器
TWI421871B (zh) * 2009-11-27 2014-01-01 Macronix Int Co Ltd 定址一記憶積體電路之方法與裝置
US8477050B1 (en) 2010-09-16 2013-07-02 Google Inc. Apparatus and method for encoding using signal fragments for redundant transmission of data
JP5664229B2 (ja) * 2010-12-28 2015-02-04 ソニー株式会社 送信装置、送信方法、及びプログラム
JP5529177B2 (ja) * 2011-01-19 2014-06-25 ネイバー ビジネス プラットフォーム コーポレーション Ｐ２ｐ基盤のストリーミングサービスでバッファリングを行うシステムおよび方法、並びにクライアントでバッファリングを処理するアプリケーションを配布するシステム
US8539319B2 (en) * 2011-01-28 2013-09-17 Cisco Technology, Inc. Providing capacity optimized streaming data with forward error correction
US8856212B1 (en) 2011-02-08 2014-10-07 Google Inc. Web-based configurable pipeline for media processing
US8681866B1 (en) 2011-04-28 2014-03-25 Google Inc. Method and apparatus for encoding video by downsampling frame resolution
US9106787B1 (en) 2011-05-09 2015-08-11 Google Inc. Apparatus and method for media transmission bandwidth control using bandwidth estimation
US8661323B2 (en) 2011-05-09 2014-02-25 Google Inc. Method and apparatus for generating packet mask
US9490850B1 (en) 2011-11-28 2016-11-08 Google Inc. Method and apparatus for decoding packetized data
US9185429B1 (en) 2012-04-30 2015-11-10 Google Inc. Video encoding and decoding using un-equal error protection
US10034023B1 (en) 2012-07-30 2018-07-24 Google Llc Extended protection of digital video streams
US9172740B1 (en) 2013-01-15 2015-10-27 Google Inc. Adjustable buffer remote access
US9413494B2 (en) * 2013-01-17 2016-08-09 Qualcomm Incorporated FEC-based reliable transport control protocols for multipath streaming
US9311692B1 (en) 2013-01-25 2016-04-12 Google Inc. Scalable buffer remote access
US9225979B1 (en) 2013-01-30 2015-12-29 Google Inc. Remote access encoding
US20140269359A1 (en) * 2013-03-14 2014-09-18 Google Inc. Reduction of retransmission latency by combining pacing and forward error correction
CN104426636A (zh) * 2013-09-11 2015-03-18 松下电器产业株式会社 通信控制装置及通信控制方法
US9641592B2 (en) 2013-11-11 2017-05-02 Amazon Technologies, Inc. Location of actor resources
US9805479B2 (en) 2013-11-11 2017-10-31 Amazon Technologies, Inc. Session idle optimization for streaming server
US9582904B2 (en) 2013-11-11 2017-02-28 Amazon Technologies, Inc. Image composition based on remote object data
US9604139B2 (en) 2013-11-11 2017-03-28 Amazon Technologies, Inc. Service for generating graphics object data
US9596280B2 (en) 2013-11-11 2017-03-14 Amazon Technologies, Inc. Multiple stream content presentation
US9578074B2 (en) 2013-11-11 2017-02-21 Amazon Technologies, Inc. Adaptive content transmission
US9634942B2 (en) 2013-11-11 2017-04-25 Amazon Technologies, Inc. Adaptive scene complexity based on service quality
US9794311B2 (en) 2014-03-18 2017-10-17 Qualcomm Incorporated Transport accelerator implementing extended transmission control functionality
US9596323B2 (en) 2014-03-18 2017-03-14 Qualcomm Incorporated Transport accelerator implementing client side transmission functionality
US9350484B2 (en) 2014-03-18 2016-05-24 Qualcomm Incorporated Transport accelerator implementing selective utilization of redundant encoded content data functionality
US9596281B2 (en) 2014-03-18 2017-03-14 Qualcomm Incorporated Transport accelerator implementing request manager and connection manager functionality
US10536382B2 (en) * 2017-05-04 2020-01-14 Global Eagle Entertainment Inc. Data flow control for dual ended transmission control protocol performance enhancement proxies
US10638366B2 (en) * 2018-06-18 2020-04-28 Verizon Patent And Licensing Inc. Flow level pacing by controlling socket send buffer size
US11088968B2 (en) * 2019-09-10 2021-08-10 Verizon Patent Licensing Inc. Controlling socket receive buffer for traffic optimization
CN110855400B (zh) * 2019-11-29 2022-02-25 江苏方天电力技术有限公司 基于纠错码的自适应丢包恢复方法、计算设备及存储介质
US11863317B2 (en) * 2021-08-25 2024-01-02 BitRipple, Inc. Methods for reliable low latency data delivery using erasure codes and feedback

Family Cites Families (26)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH05292150A (ja) * 1992-04-10 1993-11-05 Canon Inc 通信処理装置
JPH06350575A (ja) * 1993-06-11 1994-12-22 Fujitsu Ltd 移動通信用のデータ通信プロトコル
WO1996034463A1 (en) 1995-04-27 1996-10-31 Trustees Of The Stevens Institute Of Technology High integrity transport for time critical multimedia networking applications
ZA965340B (en) * 1995-06-30 1997-01-27 Interdigital Tech Corp Code division multiple access (cdma) communication system
JP3391251B2 (ja) * 1998-03-25 2003-03-31 三菱電機株式会社 適応確率推定方法及び適応符号化方法並びに適応復号方法
AU3351499A (en) 1998-03-30 1999-10-18 Telefonaktiebolaget Lm Ericsson (Publ) An interleaving scheme for blocks in a packet switched system
US7068729B2 (en) 2001-12-21 2006-06-27 Digital Fountain, Inc. Multi-stage code generator and decoder for communication systems
US6307487B1 (en) 1998-09-23 2001-10-23 Digital Fountain, Inc. Information additive code generator and decoder for communication systems
US6320520B1 (en) 1998-09-23 2001-11-20 Digital Fountain Information additive group code generator and decoder for communications systems
KR100687119B1 (ko) 1998-10-23 2007-02-27 텔레호낙티에볼라게트 엘엠 에릭슨(피유비엘) 결합된 하이브리드 자동 재전송 요구 스킴
US6621796B1 (en) * 1999-03-22 2003-09-16 Telefonaktiebolaget Lm Ericsson (Publ) Discard mechanism for selective repeat automatic repeat request
US6757654B1 (en) * 2000-05-11 2004-06-29 Telefonaktiebolaget Lm Ericsson Forward error correction in speech coding
US6486803B1 (en) 2000-09-22 2002-11-26 Digital Fountain, Inc. On demand encoding with a window
US6411223B1 (en) 2000-10-18 2002-06-25 Digital Fountain, Inc. Generating high weight encoding symbols using a basis
US7095729B2 (en) * 2000-12-22 2006-08-22 Intel Corporation Method for multimedia communication over packet channels
JP2003008553A (ja) * 2001-06-22 2003-01-10 Mitsubishi Electric Corp 送信機、受信機、送受信機および通信システム
US7068726B1 (en) * 2001-08-30 2006-06-27 3Com Corporation Near end cross-talk and echo avoider for bi-directional digital communications
JP2003087225A (ja) * 2001-09-12 2003-03-20 Nippon Telegr & Teleph Corp <Ntt> データ転送方法、データ転送システム、端末装置、データ転送プログラム、および記録媒体
US20030103459A1 (en) * 2001-11-16 2003-06-05 Connors Dennis P. Method and implementation for a flow specific modified selective-repeat ARQ communication system
US7254140B1 (en) * 2002-01-14 2007-08-07 Xilinx, Inc. Method and apparatus for transceiving data in a micro-area network
US6677864B2 (en) * 2002-04-18 2004-01-13 Telefonaktiebolaget L.M. Ericsson Method for multicast over wireless networks
US7483408B2 (en) * 2002-06-26 2009-01-27 Nortel Networks Limited Soft handoff method for uplink wireless communications
US7168022B2 (en) * 2002-12-27 2007-01-23 Ntt Docomo, Inc. Transmission control method and system
US6954617B2 (en) * 2003-03-31 2005-10-11 Sony Corporation Apparatus and method to improve goodput in unreliable networks
US7385954B2 (en) * 2003-07-16 2008-06-10 Lucent Technologies Inc. Method of transmitting or retransmitting packets in a communication system
JP4685787B2 (ja) * 2003-10-08 2011-05-18 デジタル ファウンテン， インコーポレイテッド Ｆｅｃベース信頼度制御プロトコル

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN104579550A (zh) * 2013-10-29 2015-04-29 三星Sds株式会社 数据传送装置及方法
WO2021227781A1 (zh) * 2020-05-13 2021-11-18 华为技术有限公司 数据帧的传输方法和通信装置
CN113676736A (zh) * 2020-05-13 2021-11-19 华为技术有限公司 数据帧的传输方法和通信装置

Also Published As

Publication number Publication date
US20050226272A1 (en) 2005-10-13
WO2005036361A2 (en) 2005-04-21
JP2007508750A (ja) 2007-04-05
CN101656731A (zh) 2010-02-24
EP1671424A4 (en) 2010-12-22
US8458567B2 (en) 2013-06-04
US7447235B2 (en) 2008-11-04
JP4685787B2 (ja) 2011-05-18
WO2005036361A3 (en) 2006-03-30
KR20070004517A (ko) 2007-01-09
CN100550652C (zh) 2009-10-14
US20090144601A1 (en) 2009-06-04
EP1671424B1 (en) 2012-06-06
EP1671424A2 (en) 2006-06-21
KR101035219B1 (ko) 2011-05-18
CN101656731B (zh) 2015-04-15

Similar Documents

Publication Publication Date Title
CN1864335A (zh) 基于前向纠错(fec)的可靠性控制协议
US9413494B2 (en) FEC-based reliable transport control protocols for multipath streaming
CN102687448B (zh) 网络中可靠实时数据流传输的高效应用层自动重复请求重发的方法
CN101861709B (zh) 用于具有合并的自动重复请求的自适应前向纠错以在无线局域网中进行可靠多播的方法和装置
US7584404B2 (en) Method and apparatus for multimedia communication over packet channels
JP4513725B2 (ja) パケット送信装置、通信システム及びプログラム
CN1640076A (zh) 媒体流式传输分发系统
CN101849378B (zh) 用于流传输可缩放多媒体数据流的方法和装置
CN1647440A (zh) 在接收器端具有决定可能重传请求的拥塞控制的传输系统
CN101061659A (zh) 自适应前向纠错
CN101030838A (zh) 一种在iptv网络中动态自适应前向差错控制的系统及方法
CN1482779A (zh) 互联网多媒体实时通信中的前向纠错方法
CN1208936C (zh) 数据发送装置和数据接收装置
JP4666309B2 (ja) 送信装置、受信装置、中継装置及びパケット伝送システム
CN1391374A (zh) 在发射机端具有定时控制的选择性分组重传
JP2008092213A (ja) 受信機、パケット再送方法及びプログラム
Hou et al. Performance analysis of differentiated ARQ scheme for video transmission over wireless networks
Dresler et al. Adaptive Error Correction to Support Heterogeneous Multicast Groups
CN116980077A (zh) 数据传输的fec方法及装置
CN114422864A (zh) 一种音视频抗弱网传输方法及系统
Al-Suhail et al. A Cross-Layer Model for Video Multicast Based TCP-Adaptive FEC over Heterogeneous Networks

Legal Events

Date Code Title Description
C06 Publication
PB01 Publication
C10 Entry into substantive examination
SE01 Entry into force of request for substantive examination
C14 Grant of patent or utility model
GR01 Patent grant
TR01 Transfer of patent right

Effective date of registration: 20180417

Address after: American California

Patentee after: Qualcomm Inc.

Address before: American California

Patentee before: Digital Fountain Inc.

TR01 Transfer of patent right
CF01 Termination of patent right due to non-payment of annual fee

Granted publication date: 20091014

Termination date: 20181008

CF01 Termination of patent right due to non-payment of annual fee