拥塞控制比特率算法

文档序号:8514564阅读:561来源:国知局
拥塞控制比特率算法
【专利说明】拥塞控制比特率算法
[0001]领域
[0002]本公开涉及在网络上的数据传输。具体地,本公开的各个方面涉及使用包交换网络中的不可靠传输协议控制拥塞的系统和方法。
【背景技术】
[0003]随着数字流媒体服务和各种基于云的计算解决方案的日益流行,在远程设备之间快速而准确地传送大量数据的能力是关键的任务。通过网络例如互联网、广域网(WAN)或局域网(LAN)的共享资源向目标系统发送数字数据通常包括数据转换为格式化块的安排,该格式化块被称为包,其可以具有固定或可变的长度。每个数据包一般包括有效载荷或主体,其具有被输送到目的地的基本用户数据以及通常至少部分被包含在该数据包的报头内、用于路由和控制目的的某些增补信息。笼统来说,网络、发送系统和接收系统可以使用该增补信息以确保将有效载荷正确路由并输送到期望的目的地。
[0004]以这种方式通过包交换网络传输数据通常不可避免的的结果是包丢失,这在一个或多个数据包不能正确地到达其目的地时发生。包丢失可能是由于包括信道拥塞、信号衰减的各种因素和其他原因而产生。为了防止导致包丢失发生的某些网络状况,同时也有效地使用网络信道中的可用带宽,各种拥塞控制技术已被开发出来。此外,存在一定范围的传输协议,其可以并入工具以处理包丢失,且当发生包丢失时用于处理包丢失的特定方法取决于在数据传送期间使用的特定传输协议。一般来说,这些传输协议可被分为两种类型,即可靠的协议和不可靠的协议,其中,每种传输协议提出某些折衷,并且用于任何实例的特定协议选择可取决于数据传送的性质。
[0005]可靠协议并入将每个数据包依次输送到目的地并在包丢失的情况下重传丢弃包的保证。可靠协议往往(但不总是)是面向连接的协议,而输送保证通常通过建立用于特定通信会话的从接收器回到发送器的反向信道来实现,接收器可以使用该反向信道发送某种类型的确认接收来验证包被正确输送。当指示数据包未能正确地到达其目的地时,发送器可以使用这些确认以引导重传过程。可靠协议的流行和众所周知的示例是传输控制协议(TCP),该协议也是面向连接的。可靠的协议(例如TCP)很适合数据的准确传送是首要关注并且为了验证数据包被正确地输送可容许一定量的延迟的任务,诸如发送基于文本的电子邮件、数字内容下载和音频/视频可以被缓存在目标系统的媒体流服务。不幸地,数据验证性能和重传数据引入相当大的开销,使得许多可靠协议不受时间敏感应用(包括实时数据传送,诸如现场音频和/或视频流、在线视频游戏和互联网电话)的欢迎。
[0006]相反,如上所述,不可靠协议通常放弃对特定包的数据输送验证的类型,并且通常特征在于它们不保证每个包到达其目的地并且它们也不保证以正确顺序输送包的事实。不可靠的协议往往是(但不总是)无连接的,并且通常在任何特定通信会话期间不建立固定的信道。每个数据包可以改为基于包含在每个数据包中的增补信息而独立地路由。不可靠协议的流行和众所周知的示例是用户数据报协议(UDP),这也是无连接的。由于不可靠协议如UDP通过放弃上述的可靠性特性而具有相对减少的开销,它们更适于将延迟减到最小是首要关注的时间敏感应用,诸如上述的实时应用。
[0007]由于不可靠协议通常放弃数据包的重传,被称为前向纠错(FEC)的技术通常用于处理当使用不可靠服务传输数据时的包丢失。FEC为接收设备提供独立地重构丢失的数据而不需要发送器重传未能正确输送的源包的能力。当使用前向纠错时,原始源数据通常以FEC包的形式被冗余编码在发送器侧,FEC包与源包被同时传送到接收器。在丢失源包的情况下,接收器设备可以使用包含在FEC包中的冗余编码数据重构丢失的数据而不必等待重传。
[0008]重要的是,网络状况往往随时间变化,导致网络信道上可供发送器使用的最大比特率基于信道上的当前载荷改变。当发送器系统尝试以高于信道的当前可用带宽的比特率发送数据包时,作为响应,它可引起触发严重包丢失的拥塞状况。这对于涉及可靠数据传输(例如TCP)的不太时间敏感应用可能是可容许的,因为丢失数据的重传得到保证;然而,这对于许多实时应用和涉及不可靠传输的其他应用可能是不能接受的,因为包丢失可能达到使得接收器无法重构丢失数据、导致不良结果(诸如信号丢失)的程度。另一方面,当最大可用比特率改为远远超过由发送器提供的比特率时,这也是不希望的,因为结果导致网络信道的全传输能力被低效使用并且在接收器侧的信号质量可能不必要地差。
[0009]不幸地,以有效使用网络信道的可用带宽而不引起导致不可接受的包丢失的拥塞状况的方式使用不可靠协议传送数据是巨大的挑战。传统的拥塞控制技术往往只适合可靠协议(例如TCP),该技术具有到内置发送器的传输层的反馈,但对许多不可靠协议(例如UDP)是无效的,不可靠协议通常缺乏所需的反馈,除非由使用户在传输层上单独添加。此夕卜,设计用于TCP或其他可靠协议的拥塞控制或拥塞避免算法一般不会快到用于实时流媒体应用或和可能不适合于涉及不可靠协议的许多数据传送应用,因为响应于拥塞比特率指数降低可能导致实时信号的质量受过大影响的结果。此外,虽然由比特率增加到拥塞点导致的包丢失可以在不太时间敏感的应用(其使用TCP或其他可靠协议以重传数据)中是可容许的,但是在许多实时应用中可能是不可接受的,这是由于导致接收器无力重构数据。
[0010]因此,在本领域需要一种适合与UDP和其他不可靠传输协议使用的有效拥塞控制和拥塞避免技术。正是在这样的背景下,产生了本公开的各个方面。

【发明内容】

[0011]根据本公开的某些实施,由发送器计算系统执行的方法可以包括通过网络经由不可靠协议向至少一个接收器设备发送数据包流。该数据包流可以包括源包和前向纠错(FEC)包。该方法可包括在所述发送期间,从至少一个接收器设备接收一个或多个反馈报告,每个所述周期性反馈报告表征在对应时间周期内的包丢失。该方法还可包括:在所述发送期间,响应于所述反馈报告的至少一个反馈报告,调整所述数据包在该流中发送的速率。调整速率可以包括响应于所述反馈报告中将所述包丢失表征为在可接受水平内的反馈报告,增加发送所述FEC包的FEC速率同时保持发送所述源包的源速率。
[0012]根据本公开的某些实施,发送器计算系统可以包括至少一个处理器单元和耦接到至少一个处理器单元的至少一个存储器单元。该至少一个处理器单元和至少一个存储器单元可以经配置执行一种方法。该方法可包括通过网络经由不可靠协议向至少一个接收器设备发送数据包流。该数据包流可以包括源包和前向纠错(FEC)包。该方法可包括在所述发送期间,从至少一个接收器设备接收一个或多个反馈报告,每个所述周期性反馈报告表征在对应时间周期内的包丢失。该方法还可包括:在所述发送期间,响应于所述反馈报告的至少一个反馈报告,调整所述数据包在该流中发送的速率。调整速率可以包括响应于所述反馈报告中将所述包丢失表征为在可接受水平内的反馈报告,增加发送所述FEC包的FEC速率同时保持发送所述源包的源速率。
[0013]根据本公开的某些实施,非临时性计算机可读介质可体现有计算机可读指令。计算机可读指令可以经配置以在执行时实施一种方法。该方法可包括通过网络经由不可靠协议向至少一个接收器设备发送数据包流。该数据包流可以包括源包和前向纠错(FEC)包。该方法可包括在所述发送期间,从至少一个接收器设备接收一个或多个反馈报告,每个所述周期性反馈报告表征在对应时间周期内的包丢失。该方法还可包括:在所述发送期间,响应于所述反馈报告的至少一个反馈报告,调整所述数据包在该流中发送的速率。调整速率可以包括响应于所述反馈报告中将所述包丢失表征为在可接受水平内的反馈报告,增加发送所述FEC包的FEC速率同时保持发送所述源包的源速率。
【附图说明】
[0014]本公开的教义可以通过考虑下面结合附图的【具体实施方式】很容易理解,其中:
[0015]图1示出了根据本公开的某些方面的示例数据传输和前向纠错技术的示意图。
[0016]图2示出了根据本公开的某些方面的示例拥塞控制技术的流程图。
[0017]图3示出了根据本公开的某些方面响应于来自至少一个接收器设备的反馈而调整发送器设备的比特率速率的详细示例的流程图。
[0018]图4示出了根据本公开的某些方面的示例系统的框图。
【具体实施方式】
[0019]虽然为了说明的目的,下面的详细描述包含了许多特定细节,但是本领域的任何普通技术人员应理解,对以下细节的许多变化和改变都在本发明的范围之内。因此,以下描述的本公开的说明性实施在对所要求保护的发明没有任何一般性损失且不会对其强加限制的情况下进行阐述。
[0020]导言
[0021]本公开的各个方面涉及可与不可靠传输协议(例如UDP)使用的拥塞控制和/或拥塞避免技术。
[0022]根据某些方面,一个或多个发送器设备可以使用不可靠传输协议(例如UDP)将数据包发送到一个或多个接收器设备。数据包可以包括源包(含有所需的源数据)以及FEC包(含有在源包中一个或多个无法到达一个或多个接收器设备的情况下用于纠错的源数据的冗余)两者。周期性反馈报告可从一个或多个接收器设备发送到一个或多个发送器设备。反馈报告可以识别在对应时间周期内的包丢失,并且发送器可以使用该反馈报告以识别包丢失是否发生在该时间周期内,和/或识别在该对应时间周期内包丢失的程度。包丢失可(例如)由于发送器提供太高的比特率到数据流而发生。
[0023]根据某些方面,一个或多个发送器设备可以使用周期性反馈报告以调整被发送到一个或多个接收器设备的流中的数据包的比特率的方面。比特率的方面可以按优化接收器设备的能力以获得源数据的方式进行调整。在某些方面,响应于指示包丢失在可接受水平内的反馈报告,FEC包的比特率可增大,同时响应于初始反馈报告保持源包在流中的并发比特
当前第1页1 2 3 4 5 
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1