首页> 中国专利> 计算每个流的可用带宽和比特流协调的发送多数据流的数据通信方法和系统

计算每个流的可用带宽和比特流协调的发送多数据流的数据通信方法和系统

摘要

公开了一种数据传输方法和系统,其中使用一传输速率公式计算将要发送的每个数据流的可用网络带宽。然后以各自的比特率发送多个数据流,各个比特率的总和不大于数据流的数量与所计算的每个流的可用带宽的乘积,但是在损失其他所发送的流的情况下,可以增加个别的数据流的速率。本发明特别用于流式多媒体中,并以适当的比率对每一种媒体的流式传输的速率提供控制。同时还公开了一种适合于接收该数据流的数据接收方法和系统。

著录项

  • 公开/公告号CN1557073A

    专利类型发明专利

  • 公开/公告日2004-12-22

    原文格式PDF

  • 申请/专利权人 英国电讯有限公司;

    申请/专利号CN02818401.7

  • 申请日2002-09-13

  • 分类号H04L12/56;

  • 代理机构11127 北京三友知识产权代理有限公司;

  • 代理人李辉

  • 地址 英国伦敦

  • 入库时间 2023-12-17 15:43:15

法律信息

  • 法律状态公告日

    法律状态信息

    法律状态

  • 2022-09-30

    专利权有效期届满 IPC(主分类):H04L12/56 专利号:ZL028184017 申请日:20020913 授权公告日:20090729

    专利权的终止

  • 2009-07-29

    授权

    授权

  • 2005-02-23

    实质审查的生效

    实质审查的生效

  • 2004-12-22

    公开

    公开

说明书

技术领域

本发明涉及一种用于数据通信的方法和系统,更具体而言,涉及一种用于通过网络发送多个数据流的方法和系统,以及一种用于接收上述所发送的数据的方法和系统。此外,本发明还涉及一种存储计算机程序的计算机可读存储介质,当该计算机程序在计算机上运行时,其控制计算机执行前述的数据发送和接收方法。

背景技术

近年来用于数据通信的电信网在数量、范围、和用户数量上已经有了极大的增加。先前,在这种电信网上进行的大部分数据通信的一个特征是这些数据基本上是“基于消息”的。“基于消息”的意思是那些在网络上传输的数据形成了例如电子邮件消息、在传送过程中的文件、或在客户机-服务器系统之间传递的其他应用数据的一部分。这种“基于消息”的数据的一个主要特征是它不是特别地时间关键性的,时间关键性是指为了使数据有用,数据必须在某个传输时间内到达接收机终端。相反地,倘若数据在一个合理的时间量内到达了接收机,则其仍然是对最终用户有用的。先前巳知的这种“基于消息”的数据的实例例如是标准电子邮件和使用文件传送协议(FTP)传送的文件。

新近,注意力已经从数据通信网发送传统的基于消息的数据的能力转移到了能够以连续数据流从发射机向接收机发送数据的网络和相关设备。这种数据的价值常常是时间关键性,因为网络必须尽可能平滑和快速地把数据从发射机传送至接收机终端,最好避免重发数据的需要。接下来根据图1描述在现有技术中巳知的这种数据流式传输系统的一个实例。

通常,将被流式传输的数据是多媒体数据,诸如音频和视频数据。该音频和视频数据可能来自实况视听广播,诸如新闻或体育事件,或者可能来源于,例如,当用户选择时允许他们根据他们的选择观看电视节目和电影的视频点播服务。然而,无论该数据的来源是什么,相应的音频和视频馈送数据必须首先被适当地进行数字编码,以便将该音频和视频数据信号压缩成一个适合于在网络上传输的大小。通常,依照不同的MPEG标准的其中之一来执行音频和视频编码。

在对音频和视频数据编码之后,将已编码的数据传递到网络服务器,在网络服务器中,数据在通过网络传输至客户机之前被存储在独立的音频缓冲器和视频缓冲器中。

在进行缓冲之后,如下述更详细的论述,数据通过网络被发送,并且由接收机接收,其中该数据在解码之前被缓冲。在接收机中由一个适当的解码器执行解码,并且将所解码的数据发送给在该接收机上运行的应用程序用以再现。

当前使用的最普遍的网络类型中的一种当然是那些构成因特网的网络,并且其使用网际协议(IP)在网络的网络层以IP数据报的形式传送数据。由传送层协议(传输控制协议(TCP)和用户数据报协议(UDP))提供通过网络层的数据传送。TCP和UDP都是本领域中已知的,并且在例如Tannenbaum A.S.,“计算机网络”第三版,Prentice Hall,PP521-542页中有所描述。

UDP已经被经常用于通过网络的流式数据服务,并且尤其是用于流式音频和视频数据。然而,UDP是一种无连接传输协议,并因此不提供服务质量控制机制,也不能够允许为一个用户保证特别的服务质量。此外,将UDP用于流式数据导致了其它的问题,因为它总是以相同的传输速率发送出数据,而不考虑网络拥塞状态,这很容易导致分组丢失,并由此丢失数据。也就是说,当对流式数据使用UDP时,那么如果发生网络拥塞,则UDP继续以相同的传输速率发送数据分组,从而助长了该网络拥塞。在没有用于减轻网络拥塞的机制的最坏情况下,结果可能是丢失多数或全部数据流分组。

通过使用TCP作为网络传输协议可以略微缓解上述与使用UDP进行流式数据传输相关联的问题。TCP是一种面向连接的协议,其把分组确认提供至发送终端,该发送终端允许对数据的传输速率增加控制量。更特别地,TCP包括一个解决网络拥塞的传输速率控制算法,如在上述536至539页描述的。TCP传输控制算法是已知的“加法的-增加-乘法的-减少(additive-increase-multiplicative-decrease)”类型的算法,其中一旦达到基本的阈值传输速率,则传输速率以一种加法方式,逐个分组地增加,直到发生分组丢失为止,于是传输速率随后以一种乘法的方式减少,例如,将传输速率减半。因此当发生分组丢失时,TCP传输速率算法通过减少数据流的传输速率来考虑网络拥塞,但是减少的乘法性意味着通过网络的数据吞吐量的变化会是相当高的。图2图解说明了一个使用TCP的数据吞吐量的实例,由此将领会到数据传输速率可以相对于时间产生相当大的变化。使用TCP时在传输速率中相对高的变化量意味着它不是特别地适合于流式数据应用,其中,优选的是相对于时间平滑变化的稳定状态传输速率。

当将要同时发送两个或更多包含相关数据(诸如音频和视频数据)的数据流时,与对流式数据使用TCP导致的数据传输速率的频繁变化相关的问题更加复杂化。在这种情况下,当使用TCP并且以在独立的数据流中传输音频和视频数据作为例子,由于音频流是通过与视频流分离的TCP连接发送的,于是每个相应的连接将应用它自己的传输速率控制算法,而不考虑另一个流的传输速率。最终的结果是,经过一段时间,通过网络的音频流的数据吞吐量变得基本上与视频流的相同,然而实际上对于大多数的视听源来说,通常每单位时间发送的视频数据比音频数据要多得多。通过TCP如此获得的在音频流与视频流之间的传输速率相等可以在接收机中具有这样的效果,即,影响数据的适当再现,由于因为这两个类型的数据不是分别以与音频数据和视频数据的产生比率相匹配的速率发送的,通常有足够的音频数据存储在接收机音频缓冲器中用于由视听应用程序再现,但是同时在接收机视频缓冲器中没有如音频数据一样足够的视频数据用于再现。

由于对每个相应的流应用各自的传输速率控制算法,尤其是由于标准TCP传输速率控制算法的乘法性减少的性质,产生了进一步的问题。考虑独立于视频流通过TCP连接发送音频流,而其中视频流也使用TCP发送的情况。通常,如先前所解释的,每个连接的平均吞吐量将基本相同,但是由于当在其中一个流中出现分组丢失时,传输速率会乘法性地减小,在任何特定的时刻在两个流各自的传输速率之间实际上可能存在很大的差异。这些在两个流之间的传输速率的潜在大的短期变化向数据传输引入了不确定性,并可能导致接收机中数据缓冲器的问题,因为出现临时的大的差异时,音频缓冲器例如可能充满并溢出从而丢失数据,但是相应的视频缓冲器可能已经被清空,由此阻止了AV再现的发生。此外,在这些流之间数据传输速率的潜在临时性大差异可能经常扰乱这两种类型的数据适当再现所需的传输速率比率,从而导致类似于如先前所解释的后续解码再现的问题。

先前已经通过对每个流使用无连接UDP协议,并且简单地以合适的传输速率发送每个流以保持这些流之间正确的数据比率,解决了由于对多个数据流应用TCP传输速率控制算法而导致的上述问题。但是,如先前所讨论的,UDP没有考虑网络拥塞和其后的由于这种拥塞而引起的数据丢失来控制传输速率。因此,仍然需要一种能够保持每个流的数据正确比率和传输速率稳定性的传输速率控制方法和系统,该方法和系统同时还考虑到由网络拥塞引起的问题。

发明内容

本发明通过提供一种数据传输方法和系统解决上述问题,在该方法和系统中网络服务器使用一个考虑了不同的因素(例如可能的网络拥塞)而导出的传输速率公式,计算可用于多个数据流传输的总传输速率。该服务器随后以相应的数据传输比特率发送多个数据流,控制这些流的各自的数据传输速率,以使得比特率的总和小于或等于所计算的总的可用速率,同时通过在多个流之间协调比特率,维持在这些流之间适当的传输速率。这具有为每个数据流提供平滑稳定状态传输速率同时在每一个流中维持将要发送的不同类型数据的适当比率的效果。

鉴于上述目的,根据本发明的第一方面,提供了一种通过网络传输数据方法,包括以下步骤:

使用一个传输速率公式计算用于数据传输的总传输速率;

以至少两个独立的数据流的形式把数据发送到网络以传送到接收机,每一个数据流以各自的数据传输比特率发送数据;以及

控制数据流的至少一个子集的相应数据传输速率,以在所述流之间协调比特率;

其中每个数据流的相应传输速率的总和基本上等于或小于所计算的总传输速率。

根据本发明的第二方面,还提供了一种用于通过网络传输数据的系统,包括:

传输速率计算装置,用于使用一个传输速率公式来计算数据传输的总传输速率;

数据流传输装置,用于以至少两个独立的数据流的形式把数据发送到网络以传送到接收机,每一个数据流以各自的数据传输比特率发送数据;以及

数据流控制装置,用于控制数据流的至少一个子集的相应数据传输速率,以在所述流之间协调比特率;其中该数据流控制装置可进一步操作以将每一个数据流的相应传输速率的总和控制得基本上等于或小于所计算的总传输速率。

通过使用一个用于计算可用的总传输速率的传输速率公式,本发明提供的优点在于在为多个数据流计算总的可用带宽时,可以考虑网络拥塞和由此导致的分组丢失。此外,通过把每一个数据流的相应传输速率控制在所计算的总的可用带宽内,通过在所计算的总的可用带宽内协调各个流之间的比特率,可以控制在每一个流中发送的数据比率。这具有以适于在每一个流之间保持数据比率的速率来提供每一个数据流的平滑稳定状态传输速率的效果。

优选地,每一个数据流中的数据是相关的,因为,例如,可能希望同时在接收机再现或使用该数据。在优选实施例中,其中一个流中的数据是音频数据,而另一个流中的数据是视频数据。

此外,优选地控制这些数据流的数据传输速率,以便防止接收机中的数据缓冲器以一个过大的速率进行填充,所述接收机接收数据流中的数据。通过以这种方式控制相应的传输速率,可以防止接收机中的数据缓冲器溢出而导致数据丢失。

此外,优选地,本发明进一步被设置为从接收机接收反馈数据,该反馈数据至少表示接收机接收的每一个流中所发送的数据的解码速率,并且随后响应于至少作为接收机解码速率的函数的所接收数据,控制各个数据流的至少一个子集的数据传输速率。通过从接收机接收这种信息,可以进一步动态控制每一个流各自的传输速率,不仅为了保持稳定状态传输速率和保持相应的数据比率,而且为了远程控制接收机终端中的数据缓冲器的状态,以便保证没有因缓冲器溢出而丢失分组。

在优选实施例中,计算总传输速率以给出通过网络的平均数据吞吐量,该数据吞吐量近似于使用传输控制协议而获得的吞吐量,这具有以下优点,即本发明变得TCP友好(TCP-friendly),因为它降低了分组丢失比率并改善了带宽的利用,以及对网络上竞争TCP连接的公平性。

优选地,本发明可进一步被设置为从所述接收机中接收反馈数据,该反馈数据表示往返时间(RTT)、丢失率值、和/或接收机的接收速率值中的一个或更多个,此外还计算作为由反馈数据所指示的一个或更多个所接收的值的函数的总传输速率。往返时间是数据从发射机传送到接收机并返回到发射机所需时间的度量,而丢失率值是网络中所丢失的要发送到接收机的数据量的度量。接收速率值是在往返时间内由接收机接收到的比特数。

通过提供从接收机到服务器的反馈,可以向服务器提供最新信息,该信息例如表示网络上导致分组丢失的拥塞情况。服务器则能够根据网络的当前状态,计算总的可用传输速率,从而优化传输流的传输速率。

此外,根据本发明的第三方面,进一步提供了一种存储计算机程序的计算机可读存储介质,当该计算机程序在计算机上运行时,其控制该计算机执行根据本发明第一方面的方法。

优选地,该计算机可读存储介质可以是光盘、磁盘、磁光盘、固态计算机存储器、或任何其它适合的数据存储介质中的任何一种。

根据本发明的第四方面,还提供了从网络接收数据的方法,该数据已经根据本发明的第一或第二方面发送,该方法包括以下步骤:

接收至少两个独立的数据流,所述每一个数据流以各自的数据传输速率传输;

将每一个流中所接收的数据传递到各自的数据缓冲器,以在其中进行缓冲;

计算表示所接收数据的一个或更多个特征的一个或更多个数量值;以及

将所计算的数量值发送到发射机,以用于计算从那里发送的数据的总传输速率。

通过发送表示所接收数据的特征的数量值,可以考虑当前的网络状态,更精确地计算发射机的可用于传输的总传输速率。

优选地,在第四方面中,本发明被进一步设置为在每一个缓冲器中以各自的解码速率对数据进行解码,其中将各自的数据解码速率作为所计算的数量值中的至少一个发送到发射机。

通过把每一个接收机缓冲器中的数据解码速率是多少传送到发射机,发射机可以进一步控制每一个流的数据传输速率,以保证在该接收机中的数据缓冲器不被填满,因此数据不会因此而丢失。

根据本发明的第五方面,还提供了一种用于从网络接收数据的系统,该数据已经根据本发明的第一或第二方面发送,该系统包括:数据接收装置,用于接收至少两个独立的数据流,所述每一个数据流以各自的数据传输速率传输;

至少两个数据缓冲器,这些数据缓冲器被设置为从各自接收的数据流中接收数据到其中;

计算装置,用于计算表示所接收数据的一个或更多个特征的一个或更多个数量值;以及

数据传输装置,用于把所计算的数量值发送到发射机,以用于计算从那里发送的数据的总传输速率。

在本发明的第五方面中,提出了与先前在第四方面所描述的相同的特征和优点。

此外,根据本发明的第六方面,还提供了一种存储计算机程序的计算机可读存储介质,当该计算机程序在计算机上运行时,其控制该计算机执行根据本发明的第四方面的方法。如在第三方面一样,根据本发明第六方面的存储介质可以实现为磁盘、光盘、磁光盘、固态计算机存储器等中的任何一种或更多种。

附图说明

通过下列参照附图仅仅以示例性的方式给出的本发明优选实施例的描述,本发明的其它特征和优点将变得明显,附图中相同的标号表示相同的部分,其中:

图1是说明现有技术的多媒体流式系统的单元的示意框图;

图2是说明使用现有技术的TCP协议的网络的数据吞吐量的图表;

图3是说明用于本发明的服务器和客户机设备的布置的框图;

图4是用于本发明实施例中的服务器设备中的主要单元的框图;

图5是用于本发明实施例中的在客户机设备中使用的功能单元的框图;

图6是由本发明实施例中的服务器设备执行的方法步骤的流程图;

图7是由用于本发明实施例中的客户机设备执行的方法步骤的流程图;

图8是说明用于本发明实施例中的丢失事件率(loss event rate)的计算所涉及的步骤的流程图;

图9是在本发明实施例中使用的滤波系数的图表;

图10是用于本发明实施例中的接收机设备中的滤波器单元的框图;

图11是使用本发明实施例实现的多个数据流之一的通过网络的数据吞吐量的图表。

具体实施方式

现在将参照图3-11说明构成本发明优选实施例的各种单元的构造和操作。应当注意,这里所说明的优选实施例为本发明应用到例如音频和视频数据的多媒体数据传输的非限制性示例,本发明可以在几乎任何通过网络发送多个数据流的应用中使用。

在图3中说明了构成本发明优选实施例的两个基本单元。这里,可以看出,提供了在其中设置有第一视频缓冲器42和第二视频缓冲器43的服务器40。第一视频缓冲器42被设置为存储已经以第一视频编码速率进行了编码的编码视频数据,而第二视频缓冲器43被设置为存储已经以第二视频编码速率编码的更多的编码视频数据,其中该第二视频编码速率低于存储在第一缓冲器42中的编码视频数据的编码速率。应当注意存储在两个缓冲器42和43中的编码视频数据是从相同的原始视频数据得到的,但是其仅仅是使用不同的编码速率被编码,以给出不同的编码视频数据。通常,由于用于生成存储在第一缓冲器42中的编码视频数据的编码速率更高,所以第一缓冲器42中的编码视频数据将比相应的存储在第二视频缓冲器43中的以较低编码速率编码的编码视频数据更大。优选地使用H.623编码对视频数据进行编码,尽管应当理解可以使用任何适合的视频编码技术,例如MPEG等。

在服务器40中还提供了一个用于存储编码音频数据的音频数据缓冲器44。请注意,在优选实施例中仅以单个编码速率对音频数据进行编码,因此仅需要单个音频缓冲器。优选地,使用AMR音频编码对音频数据进行编码,尽管可以使用任何其它适合的音频编码技术,例如MP3等。

除了服务器40之外,在该优选实施例中还提供了一个客户机计算机50,该客户机计算机50包括视频缓冲器52和音频缓冲器54。视频缓冲器52被设置为接收并存储从服务器40接收到的编码视频数据。视频缓冲器52存储所接收的编码视频数据,直到客户机计算机中提供的视频解码器从视频缓冲器52中取出编码视频数据,用于解码并再现其中被编码的视频信号。类似地,音频缓冲器54接收从服务器40发送的编码音频数据,对编码音频数据进行缓冲,直到在客户机计算机中提供的音频解码器从音频缓冲器54中取出编码音频数据,用于解码并再现其中被编码的音频信号。

为了在服务器计算机和客户机计算机之间提供数据通信,在服务器40和客户机50之间提供第一用户数据报协议(UDP)连接10,沿着该连接从服务器40发送编码视频数据。类似地,从服务器40到客户机50还提供了第二UDP连接20,沿着该连接发送编码音频数据。由服务器以下面将说明的方式对各个UDP连接10和20的传输速率进行控制。

除了在服务器和客户机之间的UDP连接之外,为了能够有效地控制两个UDP连接10和20的传输速率,在优选实施例中在客户机和服务器之间建立传输控制协议(TCP)连接30,以用于主要从客户机返回到服务器的控制消息的传输。稍后将讨论通过TCP连接从客户机发送到服务器的反馈数据的进一步的细节。

现在转至图4,图4以框图的形式例示了在本发明优选实施例中的服务器计算机40中所需的单元。应当注意图4仅例示了本发明的操作所必需的那些服务器组件,而没有例示服务器系统操作所需的那些其它单元,应当理解,预期的读者是本领域的技术人员,他们可以识别出完全的操作需要哪些服务器系统的附加单元。

在优选实施例中,服务器计算机40包括多媒体应用控制器41,它被设置为接收编码音频数据和编码视频数据,并如先前针对图3所述的,在缓冲器42,43和44中缓冲接收到的数据。请注意为清楚起见,这些缓冲器未在图4上显示。多媒体应用控制器41通过TCP连接30把控制消息发送到客户机计算机50,并接收来自客户机计算机50的控制消息。此外,多媒体应用控制器从适当的缓冲器向网络连接模块47提供编码视频数据和编码音频数据,该网络连接模块对数据进行分组化,用于通过网络向客户机计算机进行传输。因此,操作网络连接模块47以从多媒体应用控制器接收编码音频和视频数据,把数据分组化成适合传输的形式,并分别以适当的发送速率以两个相应的UDP数据流将数据分组发送到网络上。数据流的各个发送速率由发送速率计算器46根据稍后将讨论的适合的传输速率公式计算。发送速率计算器46把为音频和视频数据流计算的发送速率传递到网络连接模块47,以把所计算的传输速率通知给网络连接模块47。在优选实施例中,通过从客户机计算机到多媒体应用控制器的TCP连接,获得在发送速率计算器46中计算的传输速率公式的输入数据,那些输入数据通过网络连接从多媒体应用控制器传递到发送速率计算器。

进一步提供了网络控制器模块48,以控制网络连接47执行适当的数据分组化过程,以允许将音频和视频数据发送到网络上。

此外,进一步提供了作为存储器等的重传缓冲器49,其被设置为从网络连接47接收数据分组以及适当的控制信号,并且如果网络连接47必须重发缓冲分组时,缓冲其中所接收的数据分组。所发送的数据分组的缓冲和重传与本发明无关,因此没有在这里阐述进一步的细节。

尽管未在图4中显示,仍然应当注意服务器计算机40进一步包括至少一个计算机可读存储介质,该计算机可读存储介质存储用于控制服务器计算机的操作以执行本发明的计算机程序。该计算机可读存储介质可以是任何已知的类型,并且特别地可以由光盘、磁盘、磁光盘、固态计算机存储器、或任何其它适合的数据存储介质中的任何一个或其组合而形成。

图5是本发明优选实施例中所需的客户机计算机50的功能单元的框图。与服务器计算机40的说明相似,应当理解图5没有例示操作客户机计算机50所需的所有单元,而仅例示了本发明优选实施例的操作所需的那些功能块单元。作为本领域技术人员的预期读者,应当理解为了进行完整的操作需要客户机计算机的哪些附加单元。

在客户机计算机50中提供了多媒体应用控制器51,其对应于服务器中提供的多媒体应用控制器41。多媒体应用控制器51提供了在客户机计算机50中运行的多媒体应用的高级控制,并且通过由TCP连接30传递的控制消息与服务器中相应的多媒体应用控制器41进行通信。类似地,多媒体应用控制器51向构成优选实施例的客户机计算机50的其它功能单元提供控制信号。

在客户机计算机50中进一步提供了网络连接模块57,其被设置为从网络接收两个或更多个数据流中的数据分组。与接收到的两个或更多个数据流中的数据有关的控制信息被传递到用于计算数量值的量度计算器(metrics calculator)56,这些数量值表示接收到的数据流的某些特征,并且所计算的数量值被传递到反馈发射机58,用以作为控制消息通过TCP连接30在网络上传回。稍后将给出有关数量值计算的进一步信息。

网络连接57接收音频和视频数据流,并从每个流中的分组中提取编码音频和视频数据。然后编码音频和视频数据被传递给缓冲器控制器59,缓冲器控制器59把接收到的编码音频数据馈送到音频缓冲器54,并把接收到的编码视频数据馈送到视频缓冲器52。缓冲器控制器59进一步被设置为监测音频缓冲器54和视频缓冲器52的状态,以确定每个缓冲器有多满,以及每个缓冲器清空的速率,该速率表示存储在缓冲器中的数据的解码速率。进一步提供了音频解码器53,它可从音频缓冲器54中读取编码音频数据,并对编码音频数据进行解码,以提供解码音频数据作为输出。类似地,提供了视频解码器55,其从视频缓冲器52取出编码视频数据,并对编码视频数据进行解码以提供视频输出信号。

缓冲器控制器59在接收到与音频和视频缓冲器状态有关的信息后,马上将此信息传递到反馈发射机,用以将其合并到通过TCP连接30传回服务器计算机的控制消息中。

尽管未在图5中显示,应当注意客户机计算机进一步包括至少一个计算机可读存储介质,它存储用于控制客户机计算机的操作以执行本发明的计算机程序。该计算机可读存储介质可以是任何已知的类型,并特别地可以由光盘、磁盘、磁光盘、固态计算机存储器、或任何其它适合的数据存储介质中的任何一种或其组合而形成。

已经说明了构成本发明的服务器设备和客户机计算机设备的基本功能块,现在将说明本发明优选实施例的操作。

图6是根据本发明优选实施例的由服务器计算机40执行的步骤的流程图。首先,在步骤S2,发送速率计算器46为将要从服务器计算机40发送的所有各个数据流计算可用的总带宽。该值total_rate表示传输速率的上限,当每个独立的数据流各自的传输速率相加在一起时,不能超过该上限。根据下列原理计算total_rate值。

典型地,当前在互联网中使用的先前的多媒体会议应用是基于UDP传输协议的,这正如先前讨论的,没有提供服务质量控制机制,并因此不能够执行诸如对例如网络拥塞进行补偿所需的控制措施。因此,如上所述,当出现网络拥塞时竞争TCP连接减小它们的传输速率,而没有任何的UDP通信速率减小。

为了避免此问题,在本发明中,采用拥塞控制方案增强了UDP音频和视频数据流,total_rate参数的计算构成了该拥塞控制方案的一部分。更特别地,计算该参数total_rate以提供一个“TCP友好”的总传输速率,它是在时间上与通过TCP连接实现的吞吐量相类似的传输速率。

在优选实施例中,使用已经导出的传输速率公式计算总传输速率参数total_rate,以便对TCP连接在时间上的平均吞吐量建模,并由此计算总速率,以便提供TCP友好的传输速率。在优选实施例中,我们使用下面的等式1中说明的传输速率公式

>>bit>_>rate>_>stream>=>c>>(>>>packet>_>medium>_>size>>>RTT>>loss>_>rate>>>>)>>>s>

等式1

请注意,应用到普遍存在的TCP连接的上述等式的来源可参见Floyd S.“在分组交换网络中与多个拥塞网关的连接,第一部分:单向通信(Connections with Multiple Congested Gateways in PacketSwitched Networks Part 1:One Way Traffic)”,计算机通信评论(Computer Communications Review),1991年10月,卷21,第5期,30-47页。

在上面的等式中,C是在0.87到1.31范围内的常数,RTT是分组从一计算机通过网络传输到另一计算机,并返回所需的以秒为时间度量的往返时间,loss_rate是在接收机中丢失分组的度量,而packet_medium_size是作为计算对象将在流中发送的分组的平均大小。请注意稍后进一步讨论等式1的这些项以及如何计算它们以在传输速率公式中使用。

等式1给出了bit_rate_stream值,它是对当前网络状态中能够实现单个TCP连接的平均带宽的估计。然而,在优选实施例中,我们不直接使用此估计作为流的总传输速率,而是将此bit_rate_stream值如下所示代入等式2中:

total_rate_stream=min(bit_rate_stream,2*receiving_rate_stream)

                                                 等式2

参数receiving_rate_stream是通过TCP连接从客户机计算机接收到的,并且对应于由客户机接收到的在RTT秒内计算的特定流的比特数量。

上述等式2给出了使单个UDP流表现TCP友好性时可用的总带宽。但是,在本实施例中,我们关注于多个流的传输,因此必须对每个将要发送的数据流分别执行上述计算。也就是说,对每个流(即优选实施例中的音频和视频流)都依次应用等式1和2,从而得到每个流的total_rate_stream值。这样得到的每个流的各个值随后被相加以给出total_rate值,该值是可用于所有的流以提供TCP友好性的总的可用带宽,并由此考虑了可能的网络拥塞。

在计算了可用的总传输速率之后,在步骤S4,服务器中的发送速率计算器46为每一个数据流计算各自的传输速率,即在优选实施例中的音频UDP流的传输速率(audio_rate)和视频UDP流的传输速率(video_rate)。如下计算audio_rate和video_rate的值。  

如先前参照图3所述,音频数据以与视频数据分离的UDP流发送,其中视频数据通过另外一个UDP流发送,因此存在两个独立的UDP连接,每一个UDP连接都用于一个流。虽然可以认为每个流在竞争相同的网络带宽,但实际上不是这样,因为不可能在相同的时刻发送视频和音频数据分组。因此,在两个数据流是音频和视频流的情况下,先前计算的总发送比特率可以等于音频发送比特率加上视频发送比特率。此外,如将在下文中说明的,在优选实施例中,服务器从客户机接收关于视频和音频缓冲器状态的信息,以及视频和音频分组解码速率的信息。因此,可以控制音频和视频数据流的发送速率,以控制客户机中的缓冲器的填充速率。其如下实现。

首先,定义参数filling_rate_audio和filling_rate_video,它们分别是接收机中的音频和视频缓冲器填充数据的速率。在本实施例中:

filling_rate_audio=audio_rate-decoding_audio_rate       等式3

以及

filling_rate_video=video_rate-decoding_video_rate       等式4

假设需要控制接收机中的缓冲器以便以比率x∶y填充缓冲器,则:

x(filling_rate_audio)=y(filling_rate_video)            等式5

以及

total_rate=audio_rate+video_rate                        等式6

执行适当的代入,并分别解出audio_rate和video_rate,那么得出:

>>audio>_>rate>=>>>y>>(>total>_>rate>->decoding>_>video>_>rate>)>>+>x>>(>decoding>_>audio>_>rate>)>>>>x>+>y>>>>s>

等式7

>>video>_>rate>=>>>x>>(>total>_>rate>->decoding>_>audio>_>rate>)>>+>y>>(>decoding>_>video>_>rate>)>>>>x>+>y>>>>s>

等式8

这样,从上述很明显看出,可以依据在接收机中的各个音频和视频解码速率,控制各个音频发送速率和视频发送速率,以协调一个流与另一个流之间的比特率。此外,应当注意到上述参数total_rate是先前应用等式1和2计算出来的值,以给出可用于所有数据流传输的总的可用带宽,即,

total_rate=total_rate_stream_1+total_rate_stream_2+……+total_rate_stream_n其中,n是同时发送的数据流的数量。

返回到图6,在计算了每个流的音频和视频发送速率之后,在步骤S6,服务器中的网络连接47以计算的音频和视频发送速率,发送作为独立的UDP数据流的音频和视频流。应当注意,当连续发送音频和视频流时,图6中的步骤虽然是顺序地显示的,但是实际上是并行执行的,使得实际上一旦已经计算出了音频和视频传输速率的新值,就立即更新音频和视频流的传输速率。但是,当在执行新的计算时,这些流继续以先前计算的速率发送。

图11说明了当发送与由图2中描绘的TCP连接发送的相同的数据时,根据本发明优选实施例控制的一个数据流的测量的传输速率的曲线图。从图11中可以看出,在会话开始时在经历了初始的瞬态变化之后,流的传输速率稳定了,并随着时间的流逝以相对小的变化继续。此外,当与在图2中显示的TCP连接所经历的传输速率相比较时,将看到实现了一个几乎与TCP相等的平均吞吐量,但是没有由于TCP的乘法性减少控制算法所导致的大的传输速率变化。这种提供了针对时间的平滑传输速率的特性使得本发明特别适合用于发送需要连续流的数据。

在图6的步骤S8中,服务器40从客户机计算机50接收反馈数据,该反馈数据在优选实施例中是执行步骤S2和S4的总传输速率和数据流传输速率计算所需的数据。具体而言,对每一个数据流,服务器接收数据,该数据用于通知服务器当前在客户机正在经历的往返时间、在客户机的分组丢失率、客户机中音频和视频缓冲器各自的解码速率、以及在客户机的每个数据流的数据接收速率。这些数量值通过TCP连接从客户机发送回服务器。

一旦已经从客户机接收到了更新的反馈数据,该数据被传递到服务器中的发送速率计算器46,发送速率计算器再一次执行步骤S2和S4的计算,将结果传递到网络连接47,网络连接发送具有新计算的发送速率的音频和视频流。该过程在客户机会话期间持续。

现在将针对在图7中阐明的客户机计算机的操作,讨论从客户机计算机传递回服务器的数量值的计算。参照图7,在步骤S1,客户机计算机50中的网络连接57接收作为通过网络的各个UDP传输的独立的音频和视频数据流。如先前所述,网络连接57解除来自各个UDP流的编码音频和视频数据的分组化,并且将编码视频和音频数据传递至缓冲器控制器59,用于缓冲和随后的解码。

由缓冲器控制器59接收的已编码的音频和视频被分别存储在音频缓冲器54和视频缓冲器52中。在步骤S3,缓冲器控制器59分别询问音频缓冲器54和视频缓冲器52,以便确定每个缓冲器的状态。特别地,缓冲器控制器确定关于每个缓冲器有多满,以及音频和视频解码器53和55分别以多快的速率对每个缓冲器中的编码音频和视频信息进行解码的信息。这表示了音频和视频缓冲器将以多快的速度被各自的解码器清空。一旦缓冲器控制器确定了每个缓冲器的状态,所确定的信息就被传递到反馈发射机58以封装成一个控制消息,用以传回服务器计算机40。

除了把编码音频和视频数据传递到缓冲器控制器之外,网络连接57还把与接收到的数据相关的信息传递到量度计算器56,以允许量度计算器56计算由反馈发射机58传回服务器的定量的量度值。因此,在步骤S5,S7和S9,量度计算器分别为每个流计算往返时间(RTT)、丢失事件率、和每个流的接收数据速率,在服务器端需要所有这些数值作为等式l和2的输入,用于计算每个数据流的可用传输速率。应当注意,为每个接收到的数据流分别计算这三个量度,以使得为每个接收到的数据流提供一组量度。接下来将依次讨论这些数量值中的每一个的计算。

就RTT来说,如先前所述的,RTT是分组从一计算机通过网络传播到另外一计算机并返回所需时间的度量。因此,RTT是在客户机计算机的量度计算器56中测量的某个值,但是为了防止振荡,优选地如下进行计算:

RTT=0.2*RTTsample+0.8*RTTmean    等式9

RTTsample值是量度计算器最近测量的RTT的度量,而RTTmean值是所有先前RTT度量的均值。

在步骤S7中,量度计算器56计算在客户机计算机处经历的每个流的丢失事件率。丢失事件率的计算是量度计算器56所要执行的最复杂的计算,并且依赖于根据到达分组的序号检测UPD流中丢失的分组。由网络连接基于到达分组中分组序号的检测来执行此丢失分组的检测,其中如果至少有三个具有高于期望分组的序号的分组到达了接收机,而期望的分组还没有到达,那么该期望的分组被定义为丢失。因此,如果期望具有序号5的分组,则在随后将要到达的分组是分组6、分组7、随后是分组5的情况下,不把分组5定义为丢失。但是,如果接下来按顺序到达的三个分组是分组7、分组8、和分组6,则因为到达的三个分组中的每一个都具有高于期望分组5的序号,所以将分组5定义为丢失。

如上已经规定了如何将分组定义为丢失,量度计算器随后定义被称为丢失事件的另一个现象。在优选实施例中,丢失事件定义为在任何RTT度量中检测到一个或更多个分组的丢失。因此,如果在任何特定的RTT度量中,序号为4、6、7、9、10、和11的分组到达,则尽管分组5和8已经丢失,实际上在所测量的特定RTT中仅存在一个丢失事件。此方法解决了在网络中同时丢失多个分组的问题,而不会过度影响总丢失事件率的计算。

一旦如上所述检测到丢失事件,在步骤S74,量度计算器56计算最近的丢失间隔,该丢失间隔是在当前检测的丢失事件和前一次检测到的丢失事件之间接收到的分组数。量度计算器存储最新计算的丢失间隔,以及n个最近计算的丢失间隔,用于应用在加权滤波器中以给出平均丢失间隔值。如下计算该平均丢失间隔值。    

参照图9和10,图10说明了构成量度计算器和用于计算丢失率的一些功能单元。更具体而言,丢失事件检测器562如前所述检测丢失事件,并将最近计算的丢失间隔输出至多个串联丢失间隔缓冲器564中的第一个。当一个新的丢失间隔被输入至第一串联缓冲器564时,保留在第一缓冲器中的前一次的丢失间隔值被移位至下一个缓冲器,后者中的值被移位至串联缓冲器中的下一个缓冲器,等等,如在图10中显示。这样,n个最近的丢失间隔值被存储以用于计算平均丢失间隔值。每个存储在移位缓冲器564中的丢失间隔值分别与时间加权丢失间隔系数A0至An相乘,这些时间加权丢失间隔系数被存储在相应的系数存储器656中。根据图9中显示的时间加权系数函数导出系数A0到An各个值,这保证了平均丢失间隔的计算在更大程度上依赖于最近丢失间隔而不是根据先前计算存储的历史丢失间隔。应用这种加权滤波器的目的是保证所计算的丢失事件率平滑地发生变化。

在加法器566中将加权丢失间隔计算的结果相加,将其结果传递至反相器(inverter)568以计算丢失率,该丢失率是由加法器566计算的平均丢失间隔的倒数。如先前所述,这样计算的丢失率随后被传递至反馈发射机58,用于传输到服务器计算机。

量度计算器56还执行对接收到的数据速率的计算,该接收到的数据速率是在RTT秒内由客户机在数据流中接收到的比特数量的直接度量。与在任何时间在每个流中接收到的数据量相关的信息从网络连接57传递至量度计算器56,用于计算每个流的接收速率。如先前所述,随后所计算的每个流的接收速率被传递至反馈发射机58,以传输回服务器计算机。

一旦反馈发射机58已经从缓冲器控制器59和量度计算器56接收到所需的信息,它就将该信息分组化成适合于通过网络以TCP连接30传输的形式。    

应当注意,在图7的流程图中显示的步骤S1到S13仅为了进行说明,实际上客户机计算机50可以以任何希望的顺序执行这些步骤中的任何一个或所有步骤。此外,还可以并行地执行这些步骤中的若干个,例如由缓冲器控制器59执行的音频和视频缓冲器的检查和测量可以与由量度计算器56执行的计算并行进行。但是请注意,在优选实施例中接收机必须已经实际接收到了音频和视频数据流中的数据,以得到计算发送回服务器计算机的数量值所需的信息。

在服务器中,由网络控制器48和网络连接47一起通过根据计算的速率把分组实际释放到网络上来控制每个流的实际传输速率。但是在优选实施例中描述的音频和视频数据传输的特定情况下,尤其对于视频数据,所计算的速率可能不能满足所用的特定编码速率的传输速率的需求。在此情况下,如果有迹象表明所计算的视频流传输速率不得不下降,以使得以目前的视频编码速率不可能在视频流中发送足够的数据以防止接收机的视频缓冲器被清空,则网络控制器48控制网络连接47采用来自低速率编码视频缓冲器43的编码视频数据,该编码视频数据采用了更低的质量进行编码,这更适合于以更低的计算传输速率通过网络传输。在接收机中,将低率速编码视频数据置于视频缓冲器中,并且视频解码器55检测到该低编码速率,并把它自己的解码速率改变为低速率,这减小了从视频缓冲器中读取视频数据的速率。这样的措施防止了视频缓冲器被完全清空,从而使得能够在客户机计算机上连续进行视频再现。

应当注意到,由于本发明优选实施例是致力于将音频和视频数据作为多个数据流发送的,则在优选实施例中,用于设定每一个流各自的比特率的标准被选择为反映音频和视频数据的特殊需要,因为它必须在接收机中被解码以再现原始的音频和视频信号。但是,本发明不限于将音频和视频数据作为多个数据流进行传输,实际上几乎任何类型的需要以多个流发送的数据都可以利用本发明进行发送。此外,取决于要对数据进行的应用来选择在这些流之间协调比特率的特定标准。例如,可以设想本发明的其他实施例,其中数据以多个流被发送以便实现远距离控制,例如遥控一个在其上安装了多个传感器的远程运输工具。这样的运输工具例如可以是配备了无线网络连接的可潜水的海底探测运输工具等等。在这种情况下,可能需要多个数据流向潜艇的操纵单元提供操纵控制信息,并向各个传感器提供传感器控制信息。于是用于在这样的数据流之间协调比特率的标准将不同于那些在本发明优选实施例中与音频和视频数据传输相关的所要求的标准,因此很明显,为了控制协调一个数据流与另一个数据流之间的比特率所选的标准是由应用决定的。

此外,对于在本发明中可以使用的总传输带宽的计算,在优选实施例中,我们使用了一种试图模拟由标准TCP连接获得的平均吞吐量的传输速率公式。但是,应当理解该特定的公式和使用该公式的原因都不是要限制本发明,实际上,可以使用任何合适的传输速率公式计算随后用于计算各个流传输速率的可用的总传输速率。

更特别的并作为一个示例,在将通过一个因特网协议网络进行传输的情况下,则可以使用其它提供TCP友好传输速率的传输速率公式,以替代在本特定实施例中使用的公式,在本领域中已知有各种其它TCP友好的公式。此外,当使用需要不同的参数作为输入的不同公式时,则应当将客户机计算机设置用来计算和提供服务器所需要的任何参数。在不使用IP网络的情况下,则所选择的传输速率公式应当优选地是对于使用在感兴趣的特定网络上的任何传输协议有意义的公式,并且其优选地提供有意义的传输速率控制,以考虑例如网络拥塞,以及所导致的分组丢失等等的因素。在本发明的其它实施例中,对于本领域的技术人员应当明白,哪些传输速率公式是适合的要取决于本发明的特定应用领域。

接下来将说明另一个传输速率公式的示例,该传输速率公式可用于模拟TCP吞吐量,并提供如上所述的其他这样的公式的示例。

以下给出的吞吐量等式是Reno TCP的吞吐量等式的稍微简化的版本。在本发明中它可以替换等式1以计算每个流的传输速率。该吞吐量等式是:

>>X>=>>s>>R>*>sqrt>>(>2>*>b>*>p>/>3>)>>+>>(>t>_>RTO>*>>(>3>*>sqrt>>(>3>*>b>*>p>/>8>)>>*>p>*>>(>1>+>32>*>>p>^>>2>)>>)>>)>>>>.>>s>

等式10

其中:X是以字节/秒为单位的发送速率;

s是以字节为单位的分组大小;

R是以秒为单位的往返时间;

p是丢失事件率,在O到1.0之间,为分组丢失事件数量与所发送分组数量之比;

t_RTO是以秒为单位的TCP重传超时值;以及

b是由单个TCP确认所确认的分组数目。

如先前所述计算以上公式中使用的往返时间和丢失事件率。此外,我们可通过设定t_RTO=4*R来进一步简化以上计算。虽然可以对t_RTO进行更精确的计算,但是通过现有的TCP实施方式,以当前的设定值进行的实验已经获得了合理的公平性。另一个可能性是设定t_RTO=max(4R,1秒),以与RTO的推荐最小值1秒相匹配。

在使用上述等式的本发明的实施例中,如先前所述,上述等式10简单替代了在先前所述实施例中的等式1。其它的处理步骤基本上是相同的。

去获取专利,查看全文>

相似文献

  • 专利
  • 中文文献
  • 外文文献
获取专利

客服邮箱:kefu@zhangqiaokeyan.com

京公网安备:11010802029741号 ICP备案号:京ICP备15016152号-6 六维联合信息科技 (北京) 有限公司©版权所有
  • 客服微信

  • 服务号