CN104836748B - 拥塞控制比特率算法 - Google Patents

Abstract

本公开涉及拥塞控制比特率算法，包括方法、发送器计算系统以及体现有计算机可读指令的非临时性计算机可读介质。该方法可包括通过网络经由不可靠协议向至少一个接收器设备发送数据包流。该数据包流可以包括源包和前向纠错(FEC)包。该方法可包括在所述发送期间，从至少一个接收器设备接收一个或多个反馈报告，每个所述周期性反馈报告表征在对应时间周期内的包丢失。该方法还可包括：在所述发送期间，响应于所述反馈报告的至少一个反馈报告，调整所述数据包在该流中发送的速率。调整速率可以包括响应于所述反馈报告中将所述包丢失表征为在可接受水平内的反馈报告，增加发送所述FEC包的FEC速率同时保持发送所述源包的源速率。

Description

拥塞控制比特率算法

领域

本公开涉及在网络上的数据传输。具体地，本公开的各个方面涉及使用包交换网络中的不可靠传输协议控制拥塞的系统和方法。

背景技术

随着数字流媒体服务和各种基于云的计算解决方案的日益流行，在远程设备之间快速而准确地传送大量数据的能力是关键的任务。通过网络例如互联网、广域网(WAN)或局域网(LAN)的共享资源向目标系统发送数字数据通常包括数据转换为格式化块的安排，该格式化块被称为包，其可以具有固定或可变的长度。每个数据包一般包括有效载荷或主体，其具有被输送到目的地的基本用户数据以及通常至少部分被包含在该数据包的报头内、用于路由和控制目的的某些增补信息。笼统来说，网络、发送系统和接收系统可以使用该增补信息以确保将有效载荷正确路由并输送到期望的目的地。

以这种方式通过包交换网络传输数据通常不可避免的的结果是包丢失，这在一个或多个数据包不能正确地到达其目的地时发生。包丢失可能是由于包括信道拥塞、信号衰减的各种因素和其他原因而产生。为了防止导致包丢失发生的某些网络状况，同时也有效地使用网络信道中的可用带宽，各种拥塞控制技术已被开发出来。此外，存在一定范围的传输协议，其可以并入工具以处理包丢失，且当发生包丢失时用于处理包丢失的特定方法取决于在数据传送期间使用的特定传输协议。一般来说，这些传输协议可被分为两种类型，即可靠的协议和不可靠的协议，其中，每种传输协议提出某些折衷，并且用于任何实例的特定协议选择可取决于数据传送的性质。

可靠协议并入将每个数据包依次输送到目的地并在包丢失的情况下重传丢弃包的保证。可靠协议往往(但不总是)是面向连接的协议，而输送保证通常通过建立用于特定通信会话的从接收器回到发送器的反向信道来实现，接收器可以使用该反向信道发送某种类型的确认接收来验证包被正确输送。当指示数据包未能正确地到达其目的地时，发送器可以使用这些确认以引导重传过程。可靠协议的流行和众所周知的示例是传输控制协议(TCP)，该协议也是面向连接的。可靠的协议(例如TCP)很适合数据的准确传送是首要关注并且为了验证数据包被正确地输送可容许一定量的延迟的任务，诸如发送基于文本的电子邮件、数字内容下载和音频/视频可以被缓存在目标系统的媒体流服务。不幸地，数据验证性能和重传数据引入相当大的开销，使得许多可靠协议不受时间敏感应用(包括实时数据传送，诸如现场音频和/或视频流、在线视频游戏和互联网电话)的欢迎。

相反，如上所述，不可靠协议通常放弃对特定包的数据输送验证的类型，并且通常特征在于它们不保证每个包到达其目的地并且它们也不保证以正确顺序输送包的事实。不可靠的协议往往是(但不总是)无连接的，并且通常在任何特定通信会话期间不建立固定的信道。每个数据包可以改为基于包含在每个数据包中的增补信息而独立地路由。不可靠协议的流行和众所周知的示例是用户数据报协议(UDP)，这也是无连接的。由于不可靠协议如UDP通过放弃上述的可靠性特性而具有相对减少的开销，它们更适于将延迟减到最小是首要关注的时间敏感应用，诸如上述的实时应用。

由于不可靠协议通常放弃数据包的重传，被称为前向纠错(FEC)的技术通常用于处理当使用不可靠服务传输数据时的包丢失。FEC为接收设备提供独立地重构丢失的数据而不需要发送器重传未能正确输送的源包的能力。当使用前向纠错时，原始源数据通常以FEC包的形式被冗余编码在发送器侧，FEC包与源包被同时传送到接收器。在丢失源包的情况下，接收器设备可以使用包含在FEC包中的冗余编码数据重构丢失的数据而不必等待重传。

重要的是，网络状况往往随时间变化，导致网络信道上可供发送器使用的最大比特率基于信道上的当前载荷改变。当发送器系统尝试以高于信道的当前可用带宽的比特率发送数据包时，作为响应，它可引起触发严重包丢失的拥塞状况。这对于涉及可靠数据传输(例如TCP)的不太时间敏感应用可能是可容许的，因为丢失数据的重传得到保证；然而，这对于许多实时应用和涉及不可靠传输的其他应用可能是不能接受的，因为包丢失可能达到使得接收器无法重构丢失数据、导致不良结果(诸如信号丢失)的程度。另一方面，当最大可用比特率改为远远超过由发送器提供的比特率时，这也是不希望的，因为结果导致网络信道的全传输能力被低效使用并且在接收器侧的信号质量可能不必要地差。

不幸地，以有效使用网络信道的可用带宽而不引起导致不可接受的包丢失的拥塞状况的方式使用不可靠协议传送数据是巨大的挑战。传统的拥塞控制技术往往只适合可靠协议(例如TCP)，该技术具有到内置发送器的传输层的反馈，但对许多不可靠协议(例如UDP)是无效的，不可靠协议通常缺乏所需的反馈，除非由使用户在传输层上单独添加。此外，设计用于TCP或其他可靠协议的拥塞控制或拥塞避免算法一般不会快到用于实时流媒体应用或和可能不适合于涉及不可靠协议的许多数据传送应用，因为响应于拥塞比特率指数降低可能导致实时信号的质量受过大影响的结果。此外，虽然由比特率增加到拥塞点导致的包丢失可以在不太时间敏感的应用(其使用TCP或其他可靠协议以重传数据)中是可容许的，但是在许多实时应用中可能是不可接受的，这是由于导致接收器无力重构数据。

因此，在本领域需要一种适合与UDP和其他不可靠传输协议使用的有效拥塞控制和拥塞避免技术。正是在这样的背景下，产生了本公开的各个方面。

发明内容

根据本公开的某些实施，由发送器计算系统执行的方法可以包括通过网络经由不可靠协议向至少一个接收器设备发送数据包流。该数据包流可以包括源包和前向纠错(FEC)包。该方法可包括在所述发送期间，从至少一个接收器设备接收一个或多个反馈报告，每个所述周期性反馈报告表征在对应时间周期内的包丢失。该方法还可包括：在所述发送期间，响应于所述反馈报告的至少一个反馈报告，调整所述数据包在该流中发送的速率。调整速率可以包括响应于所述反馈报告中将所述包丢失表征为在可接受水平内的反馈报告，增加发送所述FEC包的FEC速率同时保持发送所述源包的源速率。

根据本公开的某些实施，发送器计算系统可以包括至少一个处理器单元和耦接到至少一个处理器单元的至少一个存储器单元。该至少一个处理器单元和至少一个存储器单元可以经配置执行一种方法。该方法可包括通过网络经由不可靠协议向至少一个接收器设备发送数据包流。该数据包流可以包括源包和前向纠错(FEC)包。该方法可包括在所述发送期间，从至少一个接收器设备接收一个或多个反馈报告，每个所述周期性反馈报告表征在对应时间周期内的包丢失。该方法还可包括：在所述发送期间，响应于所述反馈报告的至少一个反馈报告，调整所述数据包在该流中发送的速率。调整速率可以包括响应于所述反馈报告中将所述包丢失表征为在可接受水平内的反馈报告，增加发送所述FEC包的FEC速率同时保持发送所述源包的源速率。

根据本公开的某些实施，非临时性计算机可读介质可体现有计算机可读指令。计算机可读指令可以经配置以在执行时实施一种方法。该方法可包括通过网络经由不可靠协议向至少一个接收器设备发送数据包流。该数据包流可以包括源包和前向纠错(FEC)包。该方法可包括在所述发送期间，从至少一个接收器设备接收一个或多个反馈报告，每个所述周期性反馈报告表征在对应时间周期内的包丢失。该方法还可包括：在所述发送期间，响应于所述反馈报告的至少一个反馈报告，调整所述数据包在该流中发送的速率。调整速率可以包括响应于所述反馈报告中将所述包丢失表征为在可接受水平内的反馈报告，增加发送所述FEC包的FEC速率同时保持发送所述源包的源速率。

附图说明

本公开的教义可以通过考虑下面结合附图的具体实施方式很容易理解，其中：

图1示出了根据本公开的某些方面的示例数据传输和前向纠错技术的示意图。

图2示出了根据本公开的某些方面的示例拥塞控制技术的流程图。

图3示出了根据本公开的某些方面响应于来自至少一个接收器设备的反馈而调整发送器设备的比特率速率的详细示例的流程图。

图4示出了根据本公开的某些方面的示例系统的框图。

具体实施方式

虽然为了说明的目的，下面的详细描述包含了许多特定细节，但是本领域的任何普通技术人员应理解，对以下细节的许多变化和改变都在本发明的范围之内。因此，以下描述的本公开的说明性实施在对所要求保护的发明没有任何一般性损失且不会对其强加限制的情况下进行阐述。

导言

本公开的各个方面涉及可与不可靠传输协议(例如UDP)使用的拥塞控制和/或拥塞避免技术。

根据某些方面，一个或多个发送器设备可以使用不可靠传输协议(例如UDP)将数据包发送到一个或多个接收器设备。数据包可以包括源包(含有所需的源数据)以及FEC包(含有在源包中一个或多个无法到达一个或多个接收器设备的情况下用于纠错的源数据的冗余)两者。周期性反馈报告可从一个或多个接收器设备发送到一个或多个发送器设备。反馈报告可以识别在对应时间周期内的包丢失，并且发送器可以使用该反馈报告以识别包丢失是否发生在该时间周期内，和/或识别在该对应时间周期内包丢失的程度。包丢失可(例如)由于发送器提供太高的比特率到数据流而发生。

根据某些方面，一个或多个发送器设备可以使用周期性反馈报告以调整被发送到一个或多个接收器设备的流中的数据包的比特率的方面。比特率的方面可以按优化接收器设备的能力以获得源数据的方式进行调整。在某些方面，响应于指示包丢失在可接受水平内的反馈报告，FEC包的比特率可增大，同时响应于初始反馈报告保持源包在流中的并发比特率。根据某些方面，因为比特率可仅通过增加用于纠错的FEC包的数量来调整，所以即使比特率的增加导致拥塞和包丢失增加，一个或多个接收器设备也能够重构源数据。例如，因为FEC包与源包的比率可增大，所以FEC包很可能被成功输送足以重构由于输送期间源包丢失而丢失的数据的数量。

更多细节

现转向图1，根据本公开的某些方面描绘数据传输和前向纠错(FEC)技术的说明性示例。在图1的示例中，一个或多个发送器设备102可以通过网络106向一个或多个接收器设备104发送数据，并且该数据可以按多个数据包108的形式传输。数据包108可以是使用不可靠协议(例如UDP)发送的数据报，在UDP协议中，无论是依次输送每个包108还是依次输送多个包108均不受该协议保证。因此，在包丢失的情况下，发送器设备102不重传丢失的包；相反，接收器设备104可试图使用通过使用的特定FEC技术编码进数据流中的冗余来重构丢失的源数据。

如图1所示，数据包108可以包括源包(图1中的阴影框)和FEC包(图1中的白色/空白框)两者，源包包含被输送至接收器设备104的原始源数据110，FEC包是奇偶校验包，其包含只要有足够可用的其他源或奇偶校验包就允许其取代任何丢失的源包的信息。FEC包可以包含原始的源数据110的冗余并且在源包中的一个或多个无法正确到达接收器104(例如，因为它们被网络106丢弃)的情况下，可被接收器设备104用于重构源数据110。在所传输的数据包括音频和视频流的某些实施中，数据包108还可以包括前述两种类型的音频包和视频包两者，例如数据包108可以包括音频源包、音频FEC包、视频源包和视频FEC包，并且音频包通常可小于(即，含有较少量的数据)视频包。

在某些实施中，源数据110可以是被实时传输到接收器设备104的数据流，并且源数据110可以通过在发送器设备102上运行的应用生成。在这类实施中，实时源数据110可以由按顺序输出的数据的多个帧组成，并且帧可以由生成源数据的应用定义。例如，源数据110可以是从在发送器设备102上运行的应用输出的实时音频/视频(A/V)流(诸如视频游戏、视频电话程序或其他A/V源程序)并且该应用可以定义每个帧。

在图1的示例中，所示的源数据110的块可对应于单帧(例如单A/V帧)，对于其多个源包和FEC包被生成并且通过网络106被传送至接收器设备104。数据流可以由多个帧110组成，所述多个帧可在发送器设备102按顺序生成，并且多个数据包108可被形成用于每个帧用于传送至接收器设备104。

需要注意的是，当数据使用UDP或其他不可靠协议传输时，数据包108(例如，数据报)可以通过网络106被路由通过不同的相应路径并可以不按顺序到达接收器设备。为了便于在接收器设备104重构数据，每个数据包108可被发送器设备标记特定的识别信息。例如，每个数据包108可用帧标识符(例如，帧号，其指示该数据包属于序列中的哪个帧)以及序列标识符(例如，序列号，其指示数据包在每个帧内(和/或跨帧)的序列中属于何处)标记。因此，发送器设备102可递增所形成的每个新数据包的序列号，并且对于所形成的每个新帧可递增该数据包的帧号。可选地，数据包108还可以被标记另外的识别信息(诸如类型标识符，其在例如数据流是具有音频和视频分量两者的实时数据流的实施的情况下识别包是音频包还是视频包)。接收器设备104可以根据被标记到每个包的这个增补信息汇编该数据，并可以相应解码该数据(例如，用于在接收器侧向终端用户呈现)。

在源包中的一个或多个被网络106丢弃或者以其它方式无法到达它们的目的地的包丢失的情况下，接收器设备104可以利用冗余编码的FEC奇偶校验包重构源数据110而无需发送器设备102重传，如图1所示。需要注意的是，任何数量的FEC奇偶校验包可以使用不同的算法从一个或多个源包生成。在某些实施中，FEC数据可以使用纠删码生成。在某些实施中，纠删码可以是里德所罗门编码(Reed-Solomon code)。支持纠删编码并且可被用于实施本公开的开源库的一个非限制性示例(其中之一)被称为Jerasure。在某些实施中，纠错方案可以是使得对于无法到达接收器的每个源包，可能需要一个FEC包重构特定数据集的纠错方案。例如，对于被输送给接收器设备的特定数据帧，FEC技术可以是以下技术：其中在包丢失的情况下为了完全重构帧，正确到达接收器设备的FEC包的数量需要至少等于丢失源包的数量。否则，帧可能被损坏。换句话说，如果存在N个源包并且生成M个奇偶校验包，则源数据可在至少总共N个包(源和奇偶校验)被接收时恢复。在图1的例证中，为简化说明，由发送器发送的源包的数量等于所发送的FEC包的数量，即由发送器102传输的源包与FEC包的比率简单是1∶1。不过，应当注意的是，可以使用许多其他的比率，并且根据本公开的某些方面，源包与FEC包的比率可以是动态的并在流期间随时间改变，如下所述。

为了在数据传送期间优化如何有效地利用可用带宽以及避免以触发不可接受的包丢失的方式使网络信道过载，发送器设备102和/或接收器设备104可以经配置根据本公开的方面实施拥塞控制算法。

现转向图2，描绘在一个或多个发送器设备202与一个或多个接收器设备204之间的拥塞控制技术的说明性示例的流程图。在某些实施中，拥塞控制技术可以在如图1所示的数据传输和纠错技术的至少一些方面具有相似性。

根据本公开的不同方面，发送器设备202可以经配置通过网络206向至少一个接收器设备204发送原始的源数据212。作为示例，并且不作为限制，网络206可以是互联网、WAN、LAN或使用包交换将数据包路由至其目的地的其他网络。在某些实施中，发送器设备202可以从应用接收源数据212，该应用可以运行在该发送器设备上，并且发送器设备可以经配置使用不可靠传输协议(例如UDP)向接收器设备204实时传输源数据212。

在某些实施中，源数据212可以是在通过网络传输之前需要被压缩的类型，并且发送器设备可以经配置压缩该源数据，如在214所指示。作为示例但不是限制，源数据可包括实时音频流、实时视频流或二者(即，实时音频/视频流)，并且发送器设备可以使用音频和/或视频编码器将该数据压缩为各种压缩格式的任一种。在某些实施中，源数据可以使用低延迟编解码器来编码。例如，作为低延迟视频编解码器的示例，源数据可以包括根据h.264格式编码的实时视频流。进一步举例来说，以及作为地延迟音频编解码器的示例，源数据可包括根据CELT格式编码的实时音频流。

接着发送器设备202以准备源数据(例如从应用接收的压缩或非压缩形式的源数据)用于通过形成多个数据包进行传输，如在216和218所指示。形成数据包可以包括将源数据集合划分成多个离散的有效载荷并向每个有效载荷添加增补数据以形成数据包。通过发送器设备202形成的数据包可以包括源包(如在216所指示)，其可以包含源数据212(以压缩格式，如图2所示的示例)和FEC包(如218所指示)，其包含源数据212的冗余并可以根据某种纠错码来形成。

根据本公开的某些方面，源数据212可以由多个帧组成，帧可以由在发送器设备202上运行的应用定义，并且发送器设备可以形成用于每个帧的多个数据包(包括源包和FEC包)。在本公开的某些实施中，在发送数据包之前，发送器设备202可使用用于传输过程中的特定识别信息标记每个数据包。根据某些方面，被添加到每个数据包的标记信息(如在216和218所指示)可包括帧标识符(例如，帧号，其指示每个数据包属于哪个帧)以及序列标识符(例如，序列号，其指示每个数据包在帧内和跨帧延伸的序列内属于何处)。因此，发送器设备可以经配置对每个不同数据包递增序列号，并且可对每个不同的数据帧递增帧号。在某些实施中(例如源数据包括实时音频和视频流的实施)，标记信息还可任选地包括媒体类型标识符，其可以识别特定数据包是包含音频数据还是视频数据。接着发送器设备可以在数据包形成并被标记后将其发送(如在220所指示)，通过网络206将将数据包输送到一个或多个接收器设备204。

可对每个新包递增预定量(例如，递增1)的序列号。接收器设备204可以使用接收包的序列号来确定多少个包丢失。该标记信息还可以包括额外的信息以确定(例如)多少个包在帧内以及给定的包在该帧内是哪个包索引。

接收器设备204可以接收被正确输送的这些数据包(例如，未被网络206丢弃的数据包)，并且接收器设备204可以在数据包到达时累积该数据包，如在222所指示。接收器设备204可以使用每个包包含的增补信息(包括例如帧和序列标识符信息)以相应汇编所接收的数据。接收器设备204也可以根据所使用的特定纠错技术使用FEC包重构任何丢失的源包。

根据某些方面，接收器设备204可以经配置从每个包包含的标记信息周期性地确定给定时间周期内的包丢失，如在224所指示。在某些实施中，接收器设备204可以将在一定时间周期内所接收的数据包的总数与该时间周期内被标记为已接收包的序列信息比较以确定该特定周期内包丢失的比率。例如，由于序列标识符可以随每个新的包递增，如果所有的数据包被正确输送，那么序列标识符可以表示在特定时间周期内应该已接收的数据包的总数。接收器设备204可以将这个从序列标识符确定的预期包数量与该时间周期内实际接收的包的数量比较，以便计算该时间周期内的包丢失。接着接收器设备204可以向发送器设备202发送包丢失作为特定时间周期内的反馈信息，如在226所指示。

需要注意的是，用于将反馈信息从接收器设备发送回发送器设备的传输协议可以是与用于将数据包从发送器传输到接收器的不可靠协议相同的协议，或它可以是不同的协议。例如，用于从发送器向接收器传输数据包的不可靠协议可以是无连接协议(例如，UDP)。在某些实施中，从接收器设备到发送器设备的可靠信道可以通过UDP创建。用于通过UDP创建可靠信道并可被用于本公开的某些实施的开源解决方案的示例是usrsctp。在其他实施中，用于将反馈报告从接收器设备发送回发送器设备的可靠反向信道可以使用完全单独的连接(诸如单独的可靠协议(例如TCP))建立或可靠信道使用某种其他可靠协议建立。在某些实施中，与从发送器发送至接收器的源数据相比，可靠发送反馈信息可以是优选的，这是由于这种数据的不同特性和目的。

在某些实施中，发送器设备202可以标准化从接收器设备接收的反馈信息中的包丢失，如在228所指示。这可以通过将该包丢失标准化为预定量的包来实现，这可以与在常规流传输周期期间所发送包的预期数量相对应。例如，如果接收器设备将包丢失确定为所接收包与预期包的比率(如从序列信息所确定的)，那么如果实际发送的数据包的量远远少于发送器设备可能已经发送的量，则该比例可能往往高估包丢失。作为更具体的示例，如果发送器设备发送四个包，但是接收器设备仅在特定周期接收三个包，那么该接收器设备可以确定包丢失是25％。不过，如果发送器设备可在该周期发送100个包，但是仅发送四个是因为这是需要发送的所有数据，则真实的包丢失可以被更准确表述为100个包中丢失1个包，而不是4个包中丢失1个包，即1％代替25％。作为更一般的示例，可以预先确定在常规的流传输期间，在时间周期X内应该接收N个包。如果在X期间，接收器设备基于N/2包(例如基于数据包的序列号)报告包丢失，则任何丢失应当由发送器标准化为N个包中丢失若干包，而不是N/2个包中丢失若干包。因此，发送器设备可以经配置将从一个或多个接收器设备204接收的包丢失标准化为在时间周期内预期传输的数据包的预定量。

根据某些方面，响应于从接收器设备204接收的反馈信息(任选地进一步标准化在发送器侧)，发送器设备202可以根据本文所述的拥塞控制的某些原理调节其发送数据包的速率，如在230所指示。在某些情况下，响应于指示在该对应时间周期内包丢失在可接受水平内的一组反馈信息，发送器设备可以经配置增加流的比特率，但是也可以通过仅在最初增加发送FEC包的比特率同时保持或以其它方式不增加发送源包的比特率来实现。关于响应于反馈信息可如何调整比特率的另一方面在本说明的其他地方有描述。

重要的是要注意，在图2中描绘的示例方法可以是连续或重复的过程，并且只要源数据212在传输就可以继续。在某些实施中，反馈信息可以在数据传输期间由接收器设备204向发送器设备202周期性地发送，使得发送器设备202可以直接响应于反馈信息而周期性地调整发送数据包的比特率。需要注意的是，更频繁地发送反馈信息可以增加流的响应，但是以降低上行带宽(即，从接收器到发送器)说明所述反馈信息来折衷。在某些实施中，反馈报告可以以每秒5次(即，每200毫秒(ms))的速率发送。在另外的实施中，反馈报告可以以每100ms和每1秒的范围发送。如果反馈过于频繁地发送，例如每100ms一次以上，则接收器可能不具有足够的时间累积可用的包数量来确定包丢失，并且这对于样品大小来说太小。相反，如果不是足够频繁地发送(例如少于每一秒一次)，则可能是往往不足以有用。

需要注意的是，在某些实施中，发送器设备可以向多个接收器设备发送数据包，并且可以响应于来自多个不同目标系统的反馈报告而调整比特率。在某些实施中，这可以借助用于每个相应接收器设备的发送器设备上的相应编码器来实现，在此情况下，发送器设备可以经配置基于它们的相应反馈信息来独立地调整用于相应接收器设备的比特率。在其他实施中，发送器设备可以包括服务于多个接收器设备的一个编码器，在此情况下，用于所有接收器设备的比特率可以基于最低质量传输进行调整。

需要注意的是，由发送器设备响应于从接收器设备接收到的反馈信息来调整比特率的方式可以取决于用于任何特定反馈报告的包丢失的特性。根据本公开的某些方面响应于反馈可如何调整比特率的某些说明性方面在图3中进行描绘。具体地，图3描绘根据本公开的某些实施用于响应于反馈信息调整通过不可靠协议传送数据的比特率的示例流程图。需要注意的是，图3中描绘的调整比特率的示例方法330可以与图2中的230处所指示的比特率调整在一个或多个方面有共同之处。重要的是还需注意，图3的示例是仅用于说明可以根据本公开如何调整速率的某些方面的目的的简化示例。

在最初，重要的是要注意，由发送器发送所有数据包的速率所定义的流的总比特率包括源比特率(由发送源包的速率定义)和FEC比特率(由发送FEC包的速率定义)两者。如图3所示，响应于发送器从一个或多个接收器设备接收的反馈信息332如何调整比特率可以大体取决于该反馈信息332是否指示在相应的时间周期内包丢失在可接受水平内，如在334所指示。需要注意的是，在334所指示的可接受水平可以相对于现有条件来定义。例如，如果所指示的包丢失相对于现有条件是稳定的(例如，包丢失的水平相对恒定并且相对于现有反馈报告所指示的包丢失没有波动)，则所指示的包丢失可以在可接受水平内。如何调整比特率也可以取决于反馈信息是否指示包丢失在某个预定的总包丢失阈值之上，如在344所指示。

根据某些方面，在来自接收器设备的特定反馈报告332指示在相应周期内的包丢失在可接受水平内的情况下，这可以指示由发送器传输的总比特率可以增加，例如因为网络信道的最大可用带宽未被传输流填满。在某些实施中，当所指示的包丢失相对于即刻回传的现有反馈报告相同或在可接受的改变量内时，则所指示的包丢失可以在可接受水平内。因此，在某些实施中，只要丢失不在波动，包丢失就可增加。不过，盲目增加比特率(即使是递增)可能触发包丢失，这通常会导致不可接受的结果(例如坏帧或信号在接收器设备丢失)。

因此，本公开的某些实施可以应对这些挑战，其通过响应于指示包丢失未增加或以其它方式在某种可接受水平内(例如当指示为稳定时)的反馈报告，初始仅增加FEC比特率同时保持源比特率来增加比特率，如在338所指示。重要的是，因为即使比特率的增加导致包丢失(例如由于信道拥塞)，结果也将是更大量的FEC包，所以接收器设备将能够或至少很可能能够由于流中所得更大量的FEC包而重构任何丢失的源包。例如，将更可能是正确输送的FEC包的数量大于或至少等于传输期间所丢失的源包的数量。此外，这样的数据传输速率的增加可以向发送器设备提供所需的反馈，这是因为由发送器设备接收的后续反馈报告332将反映流中的更高总比特率并指示总比特率的增加是否(例如)由于信道拥塞引起包丢失波动。

如果包丢失响应于增加的比特率继续是稳定的(例如，响应于所提供的数据包，它不波动或增加，如一个或多个后续反馈报告332指示)，对比特率的下一次调整可以是以FEC比特率先前增加的步调进行源比特率的增加，例如与先前FEC增加的量相同，如在342所指示。在某些实施中，这可以响应于紧接着的反馈报告或者可以在具有一个以上反馈报告的某个其它时间间隔后，只要包丢失在整个时间间隔内保持为可接受的，如反馈332所指示。换句话说，如在340所指示，如果最近变化是FEC比特率增加同时保持源比特率，那么如果包丢失继续是可接受的，这种下一次调整可以是源比特率增加与先前FEC增加的量相同的量。然后这种总比特率可以继续递增增加，只要反馈332指示包丢失是稳定的。

作为示例但并不作为限制，如果最近的调整(如在340所指示)不是总比特率的增加，那么流的可用带宽可以通过增加FEC比特率100kb/s来测试，如在338所指示。如果一个或多个后续反馈报告指示没有包丢失(如在334所指示)，那么下一个次调整可以是增加源比特率100kb/s(如在342所指示)，并且FEC比特率可以在源比特率以这种方式增加时保持不变，从而产生总比特率的另外增加。总比特率可以继续以这种方式增加直到包丢失响应于增加的比特率而波动。FEC包领先以确保在由总比特率的初始增加触发包丢失的情况下，接收器设备将能够重构丢失的源数据。而且，FEC包的领先增加可以生成所需的反馈以确定源比特率是否可以增加。

作为示例但并不作为限制，假设流的总比特率是2000kb/s并且其中100kb/s是FEC包，使得1900kb/s是源包。为了测试带宽，FEC速率可以初始增加至200kb/s。现在总带宽为2100kb/s。当确定没有附加丢失时，源速率可以增加先前FEC速率增加的量。然后，源速率变成1900kb/s+100kb/s＝2000kb/s，总速率是(2000kb/s的源速率)+(100kb/s的FEC速率)＝2100kb/s的总速率，但是可使FEC再次变为200kb/s来立即测试带宽。因此，有2000kb/s的源速率+200kb/s的FEC速率。下一次迭代可以是2100kb/s的源速率+200kb/s的FEC速率在下一次迭代上，随后是2200kb/s的源速率+200kb/s的FEC速率等等，直到包丢失响应于所提供的数据而增加。

根据某些方面，需要指出的是，增加比特率的方式(例如在338，增加FEC比特率)可以取决于多种因素。例如，增加的量可以根据需要而变化。此外，在具有不同类型的源数据从而产生不同类型的源和FEC包的实施中，比特率增加分布的方式可以根据这些包的特性(例如，基于每种不同类型包的相对大小)来改变。

例如，在包括音频/视频流的实时传输的某些实施中，总比特率也可以由音频比特率(由发送音频包的速率定义)和视频比特率(由发送视频包的速率定义)定义。在这些实施中，总比特率可以包括至少四种不同类型的比特率(音频源比特率、视频源比特率、音频FEC比特率以及音频源比特率)。因为每个视频包通常可远远大于每个音频包，所以仅通过增加视频FEC包的速率来增加比特率可能导致对于甚至相对少量包的过大增加，从而导致由此增加触发的过多拥塞。因此，在此类实施中，比特率的每次增加(例如，如在338所指示)可以包括每帧的视频FEC包的数量和每帧的音频FEC包的数量两者的增加。重要的是，增加这两种不同类型的包的比特率的速率可以在需要时根据它们的相对大小(例如，为了考虑到音频包较小的事实)来调整并因此有利于总带宽的微调。作为示例但并不作为限制，每次迭代时增加的音频FEC比特率与增加的视频FEC比特率的比率可以在2:1至10:1的范围。换句话说，在338增加FEC比特率或在342增加源比特率可以包括在每帧每发送一个附加视频包时发送2-10个附加的音频包。

按照本公开的另外方面，当反馈报告相反指示包丢失不再可接受时(例如，由于相对于现有条件波动或增加，如在334所指示)，流的比特率可以以不同于当包丢失是可接受时的方式进行调整。在某些实施中，响应于指示存在包丢失的反馈报告，初始调整可以包括增加FEC包与源包的比率同时保持总比特率不变，如在346所指示。因为这个说明性的初始步骤不包括降低由发送器设备发送的总比特率，只是改变FEC包与源包的比率，所以这可能并不降低包丢失(如果这类丢失是由于信道中的拥塞造成)。不过，由于流中有更多量的FEC包，故接收器设备可以被更好地配备以处理包丢失。此外，在导致包丢失的条件是瞬时的情况下，这允许发送器在降低总比特率之前继续获得附加的反馈。

如果包丢失继续是问题并且它超出某个总预定义阈值(如在344所指示)，那么比特率可以通过使总比特率下降来调整(如在348所指示)。总比特率可以下降预定义的量或可以下降到最近能工作的任何比特率(例如，产生指示包丢失是可接受的反馈332的比特率)。

需要注意的是，在某些情况下，发送器通过网络传输的可用源数据的量可能不足以填充当前可用带宽的量。作为示例但不是作为限制，如果实时视频当前产生黑屏，那么源数据的比特率可能是低的，这是因为应用简单地不产生足够的数据来填充可用比特率。不过，拥塞控制算法继续获取关于流中的最大可用比特率的反馈仍然是可取的，以便有效量的可用带宽在需要时是可用的。在这些情况下，系统可以经配置不仅如上所述增加总比特率以在下一步骤测试带宽，而且用FEC包填充未被用于源数据的剩余可用带宽。

这可以通过以下示例来说明。假定进程当前正以6MB/s传输数据包，并且来自接收器设备的反馈仍然指示包丢失处于可接受范围内，使得可增加传输带宽。下一个步骤可以将FEC比特率增加另一个100kb/s，使得总带宽在6.1MB/s。不过，源数据可能只以1MB/s产生，例如，因为应用目前正产生是黑屏的视频。在这种情况下，该进程可以经配置通过以5.1MB/s的比特率传输FEC包来用FEC包填充测试的带宽的剩余部分。因此，当目前正产生的源数据的比特率再次增加时(例如，由于视频从黑屏再次改变为活动图像)，系统仍然可以有效利用最大可用比特率，这是因为该算法继续获取反馈并逐渐增加传输带宽(即使源比特率瞬间下降)。

要强调的是，在图3中描绘的示例技术仅用于说明的目的为了强调本公开的某些方面而提供。实际上，本公开的实施可以考虑到图3示例未描绘的另外或替代形式，而且可以比图3所描绘的简化方案更复杂。

从图3的示例可以明白，本公开的某些方面包括响应于来自至少一个接收器设备的反馈报告而增加FEC包与源包的比率。这可以是如下的方式，即，响应于指示在相应时间周期内包丢失是可接受的反馈，增加FEC包的量同时保持源包的量以增加总比特率(例如，如在338所指示)。这也可以是如下的方式，即，响应于指示包丢失波动或是不可接受的反馈报告，通过增加FEC比特率并减少源比特率来增加FEC与源的比率以便保持总比特率不变(如在346所指示)。在任一情况下，流中增加FEC包的相对量可以更好配备接收器设备来处理包丢失，同时还向发送器设备提供可允许该发送器设备确定网络中的可用带宽的使用是否能够被更有效利用的反馈。

本公开的某些实施包括经配置根据本公开的某些方面实施拥塞控制和/或数据传输方法的系统，如图4所示。图4描绘分布式计算系统，该系统包括至少一个发送器计算系统402和至少一个接收器计算系统404，并且计算系统402和计算系统404经配置根据本公开的某些方面通过网络传送数据。在某些实施中，发送器计算系统402可以在一个或多个方面与图1-3的一个或多个发送器具有共同之处。在某些实施中，接收器计算系统404可以在一个或多个方面与图1-3的一个或多个接收器具有共同之处。发送器系统402和接收器系统404中的任一个或两者可以配置有实施本文所述的方法的各个方面的合适软件和/或硬件。发送器系统402和接收器系统404中的任一个或两者可以是服务器、嵌入式系统、移动电话、个人计算机、膝上型计算机、平板计算机、便携式游戏设备、工作站、游戏控制台、可佩戴设备(例如智能表)等等。

根据某些实施，发送器系统402可以是云计算服务器，以及接收器设备404可以是服务器402的云计算客户端，并且发送器402可以经配置使用不可靠协议通过网络499向客户端设备提供数据流。作为示例但并不作为限制，发送器402可以是经配置通过网络499(例如互联网)向至少一个客户端设备404提供实时数据流(例如实时音频流、实时视频流或实时音频/视频流)的服务器。发送器系统402可以经配置向接收器系统发送数据，其呈以源包452的形式，其包含被输送到接收器系统404的基本用户数据，和FEC包454的形式，该FEC包包含被包含在源包中的源数据的冗余。发送器系统402可以根据本公开的各个方面向接收器设备404并发发送这些FEC包和源包。接收器系统404可以经配置累积这些数据包并通过网络499向发送器系统402周期性地发送回反馈报告456。发送器系统402可以经配置根据本文所述的各个方面响应于这些反馈报告456而调整发送数据包452、454的速率。

系统402和系统404中的任一个(即，发送器系统402、接收器系统404或二者)可以包括一个或多个处理器单元470，该处理器单元可以根据公知的架构(例如单核、双核、四核、多核、处理器-协处理器、微处理器等等)来配置。系统402和系统404中的任一个还可以包括一个或多个存储器单元472(例如，RAM、DRAM、ROM等等)。处理器单元470可执行一个或多个程序474，该程序可以被存储在存储器472中，并且处理器470可操作耦接至存储器472(例如经由数据总线476访问存储器)。存储器单元472可以包括数据477以及处理器单元470可以在实施程序474时利用数据477。根据本公开的各个方面，用于系统402和系统404中的任一个的数据477可以包括(例如)从发送器系统402传送至接收器系统404的源数据和从接收器404传送至发送器402的反馈信息。程序474可以包括指令，当该指令由处理器执行时，该指令执行与名人视频游戏会话相关联的一个或多个操作，例如，与图2和/或图3的方法在一个或多个特征上具有共同之处的方法。例如，发送器系统402的程序474可以包括指令，当该指令由处理器470执行时，根据图2所示方法的发送器侧的方面和/或图3所示速率调整技术，促使发送器系统向至少一个接收器设备404发送数据和/或响应于从接收器设备404接收的反馈控制拥塞。接收器系统404的程序474可以包括指令，当该指令由处理器470执行时，根据图2所示方法的接收器侧的方面，促使接收器系统累积数据包、确定包丢失和/或向发送器402发送反馈信息。

系统402和404中的任一个还可以包括公知的支持电路478，例如输入/输出(I/O)电路479、电源(P/S)480、时钟(CLK)481和高速缓存482，它们可以(例如)经由总线476与系统的其他部件通信。系统402和404中的任一个可任选地包括大容量存储装置484(诸如磁盘驱动器、CD-ROM驱动器、磁带驱动器、闪存等等)，并且大容量存储装置484可以存储程序和/或数据。系统402和404中的任一个也可任选地包括显示单元486。显示单元486可以是阴极射线管(CRT)、平板屏幕、触摸屏或显示文字、数字、图形符号或其它视觉对象的其他设备的形式。系统402和404中的任一个还可以包括促进系统402/404与用户交互的用户接口488。用户接口488可包括键盘、鼠标、光笔、游戏控制垫、触摸界面或其他装置。用户接口还可包括音频I/O设备(例如扬声器和/或麦克风)。

用户可以通过用户接口488与任一个计算机系统交互。作为示例，发送器402可以是云游戏服务器，以及接收器系统404可以是云游戏客户端，并且视频游戏用户可以通过用户接口488与由服务器402执行并流传送至客户端404的视频游戏交互。数据从服务器传送到客户端的速率可以根据本公开的多个方面来优化，以增强用户的体验并保持在客户端侧接收的信号的质量。用户接口488的部分可包括图形用户界面(GUI)，其可以在显示单元486上显示，以便有利于用户与系统402/404交互。系统402/404可包括网络接口490，其经配置能够使用Wi-Fi、以太网端口或其他通信方法。网络接口490可以并入合适的硬件、软件、固件或其一些组合，以有利于经由电信网络进行通信，并且可以根据本公开的某些方面使用不可靠协议支持数据传输。网络接口490可经配置通过局域网和广域网(例如互联网)实现有线或无线通信。系统402和404中的任一个可通过网络499经由一个或多个数据包发送和接收文件的数据和/或请求。

上述的部件可以在硬件、软件、固件或其一些组合中实施。

虽然上文是本公开的各种说明性实施的完整描述，但是可能使用各种替换、修改和等同物。因此，本发明的范围不应该解释为通过上面的说明书来限定，而是应该参考所附的权利要求书以及其等同物的全范围来确定。本文所述的任何特征(不论是否优选)可与本文所述的任何其他特征(不论是否优选)组合。在所附权利要求书中，不定冠词“一个(a/an)”指代跟随冠词的一个或多个项目的数量，除非另外明确陈述。所附权利要求书不应解释为包括手段或步骤加功能的限制，除非此类限制在给定权利要求中使用短语“用于...的手段”或“用于...的步骤”的明确描述。

Claims (27)

1.一种发送器计算方法，其包括，使用发送器计算系统：

通过网络经由不可靠协议向至少一个接收器设备发送数据包流，所述数据包流包括源包和前向纠错(FEC)包；

在所述发送期间，确定在与用于周期性反馈报告的常规流传输周期相对应的相应时间周期内预期传输的数据包的预定量；在所述发送期间，从所述至少一个接收器设备接收一个或多个反馈报告，每个所述周期性反馈报告表征在相应时间周期内的包丢失；

将在所述反馈报告中的至少一个反馈报告中的所述包丢失标准化为在所述相应时间周期内预期传输的数据包的预定量；并且

在所述发送期间，响应于所述反馈报告中的至少一个，调整所述数据包在所述流中发送的速率。

2.根据权利要求1所述的方法，

其中所述不可靠协议是用户数据报协议(UDP)。

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

利用所述发送器计算系统，用序列号标记每个所述数据包。

4.根据权利要求1所述的方法，其还包括：

利用所述发送器计算系统，用序列号标记每个所述数据包，

其中所述至少一个接收器设备通过下述步骤表征在每个所述反馈报告中的所述包丢失：通过在所述相应时间周期内累积所述数据包并通过从在所述相应时间周期内由所述接收器设备接收的所述数据包的所述序列号确定实际接收的所述数据包的数量和预期接收的所述数据包的数量。

5.根据权利要求1所述的方法，其还包括：

利用所述发送器计算系统，用序列号标记每个所述数据包；

利用所述接收器设备，通过下述步骤表征在每个所述反馈报告中的所述包丢失：通过在所述相应时间周期内累积所述数据包并通过从在所述相应时间周期内由所述接收器设备接收的所述数据包的所述序列号确定实际接收的所述数据包的数量和预期接收的所述数据包的数量。

6.根据权利要求1所述的方法，其中所述调整速率还包括：

响应于所述反馈报告中将所述包丢失表征为超出可接受水平的特定反馈报告，增加所述FEC速率与所述源速率的比率同时保持发送所属数据包的总速率。

7.根据权利要求1所述的方法，

其中所述数据包包括音频包和视频包，

其中所述调整速率包括增加发送所述FEC包的FEC速率，其中所述增加发送所述FEC包的FEC速率包括增加发送所述FEC音频包的FEC音频速率和发送所述FEC视频包的FEC视频速率两者，

其中所述增加所述FEC音频速率和所述FEC视频速率两者包括使所述FEC音频速率增加的程度大于所述FEC视频速率。

8.根据权利要求1所述的方法，

其中所述数据包包括音频包和视频包，

其中所述调整速率包括增加发送所述FEC包的FEC速率，其中所述增加发送所述FEC包的FEC速率包括增加发送所述FEC音频包的FEC音频速率和发送所述FEC视频包的FEC视频速率两者，

其中所述增加所述FEC音频速率和所述FEC视频速率两者包括使所述FEC音频速率增加比所述FEC视频速率增加多2至10倍。

9.根据权利要求1所述的方法，

其中所述一个或多个反馈报告是在生成所述反馈报告中的每个反馈报告之间具有预定义时间间隔的多个周期性反馈报告。

10.根据权利要求1所述的方法，

其中所述一个或多个反馈报告是在生成所述反馈报告中的每个反馈报告之间具有预定义时间间隔的多个周期性反馈报告，

其中所述时间间隔在100毫米与1秒之间。

11.根据权利要求1所述的方法，

其中所述至少一个接收器设备是多个接收器设备。

12.根据权利要求1所述的方法，

其中所述不可靠协议是无连接的。

13.根据权利要求1所述的方法，

其中所述调整速率包括响应于所述反馈报告中将所述包丢失表征为在可接受水平内的特定反馈报告，增加发送所述FEC包的FEC速率同时保持发送所述源包的源速率，其中所述反馈报告中将所述包丢失指示为在所述可接受水平内的所述特定反馈报告将所述包丢失指示为相对于所述反馈报告中的先前反馈报告是稳定的。

14.一种发送器计算系统，其包括：

至少一个处理器单元；

耦接至所述至少一个处理器单元的至少一个存储器单元；

其中所述至少一个处理器单元和所述至少一个存储器单元经配置执行一种方法，所述方法包括：

通过网络经由不可靠协议向至少一个接收器设备发送数据包流，所述数据包流包括源包和前向纠错(FEC)包；

在所述发送期间，确定在与用于周期性反馈报告的常规流传输周期相对应的相应时间周期内预期传输的数据包的预定量；

在所述发送期间，从所述至少一个接收器设备接收一个或多个反馈报告，每个所述周期性反馈报告表征在相应时间周期内的包丢失；

将在所述反馈报告中的至少一个反馈报告中的所述包丢失标准化为在所述相应时间周期内预期传输的数据包的预定量；并且

在所述发送期间，响应于所述反馈报告中的至少一个，调整所述数据包在所述流中发送的速率。

15.根据权利要求14所述的计算系统，其还包括：

体现在所述至少一个存储器单元的计算机可读指令，其中所述指令由所述至少一个处理器单元执行以促使所述计算系统执行所述方法。

16.根据权利要求14所述的计算系统，

其中所述不可靠协议是UDP。

17.根据权利要求14所述的计算系统，所述方法还包括：

用序列号标记每个所述数据包。

18.根据权利要求14所述的计算系统，所述方法还包括：

用序列号标记每个所述数据包，

其中所述至少一个接收器设备通过下述步骤表征在每个所述反馈报告中的所述包丢失：通过在所述相应时间周期内累积所述数据包并通过从在所述相应时间周期内由所述接收器设备接收的所述数据包的所述序列号确定实际接收的所述数据包的数量和预期接收的所述数据包的数量。

19.根据权利要求14所述的计算系统，其中所述调整速率还包括：

响应于所述反馈报告中将所述包丢失表征为超出可接受水平的特定反馈报告，增加所述FEC速率与所述源速率的比率同时保持发送所属数据包的总速率。

20.根据权利要求14所述的计算系统，

其中所述数据包包括音频包和视频包，

其中所述调整速率包括增加发送所述FEC包的FEC速率，其中所述增加发送所述FEC包的FEC速率包括增加发送所述FEC音频包的FEC音频速率和发送所述FEC视频包的FEC视频速率两者，

其中所述增加所述FEC音频速率和所述FEC视频速率两者包括使所述FEC音频速率增加的程度大于所述FEC视频速率。

21.根据权利要求14所述的计算系统，

其中所述数据包包括音频包和视频包，

其中所述调整速率包括增加发送所述FEC包的FEC速率，其中所述增加发送所述FEC包的FEC速率包括增加发送所述FEC音频包的FEC音频速率和发送所述FEC视频包的FEC视频速率两者，其中所述增加所述FEC音频速率和所述FEC视频速率两者包括使所述FEC音频速率增加比所述FEC视频速率增加多2至10倍。

22.根据权利要求14所述的计算系统，

其中所述一个或多个反馈报告是在生成所述反馈报告中的每个反馈报告之间具有预定义时间间隔的多个周期性反馈报告。

23.根据权利要求14所述的计算系统，

其中所述一个或多个反馈报告是在生成所述反馈报告中的每个反馈报告之间具有预定义时间间隔的多个周期性反馈报告，

其中所述时间间隔在100毫米与1秒之间。

24.根据权利要求14所述的计算系统，

其中所述至少一个接收器设备是多个接收器设备。

25.根据权利要求14所述的计算系统，

其中所述不可靠协议是无连接的。

26.根据权利要求14所述的计算系统，

其中所述调整速率包括响应于所述反馈报告中将所述包丢失表征为在可接受水平内的特定反馈报告，增加发送所述FEC包的FEC速率同时保持发送所述源包的源速率，其中所述反馈报告中将所述包丢失指示为在所述可接受水平内的的所述特定反馈报告将所述包丢失指示为相对于所述反馈报告中的先前反馈报告是稳定的。

27.一种体现有计算机可读指令的非临时性计算机可读介质，所述计算机可读指令经配置在被执行时实施一种方法，所述方法包括：

通过网络经由不可靠协议向至少一个接收器设备发送数据包流，所述数据包流包括源包和前向纠错(FEC)包；

在所述发送期间，确定在与用于周期性反馈报告的常规流传输周期相对应的相应时间周期内预期传输的数据包的预定量；

在所述发送期间，从所述至少一个接收器设备接收一个或多个反馈报告，每个所述周期性反馈报告表征在相应时间周期内的包丢失；

将在所述反馈报告中的至少一个反馈报告中的所述包丢失标准化为在所述相应时间周期内预期传输的数据包的预定量；并且

在所述发送期间，响应于所述反馈报告中的至少一个，调整所述数据包在所述流中发送的速率。