CN1735075B

CN1735075B - 多媒体数据传输速率的自适应估算方法

Info

Publication number: CN1735075B
Application number: CN2005100893464A
Authority: CN
Inventors: 徐光德
Original assignee: LG Electronics Inc
Current assignee: LG Electronics Inc
Priority date: 2004-07-23
Filing date: 2005-07-22
Publication date: 2012-09-05
Anticipated expiration: 2025-07-22
Also published as: RU2305908C2; US7746780B2; EP1619840A1; CN1735075A; EP1619840B1; DE602005011367D1; JP2006042335A; KR20060008076A; US20060018257A1; RU2005123415A; KR100641159B1; JP4299275B2; BRPI0503015A; ATE416539T1

Abstract

所揭示的是多媒体传输速率的自适应估算方法。多媒体数据传输系统的发送单元通过RTP分组向接收单元发送多媒体数据；接收单元通过RTCP接收器报告分组向发送单元发送网络的状态信息；以及发送单元从RTCP接收器报告分组中检测丢包率，并且通过根据所检测的丢包率所落入的范围而变化的计算方法来估算可利用的传输速率。因此，当丢包大时所述的估算方法能迅速地解决网络拥挤。

Description

多媒体数据传输速率的自适应估算方法

技术领域

本发明涉及基于有线IP(互联网协议)中的实时传输协议(RTP)/实时传输控制协议(RTCP)的多媒体数据传输系统，尤其涉及一种用于通过使用监控RTCP网络状态的功能来自适应地估算多媒体数据传输速率的方法。

背景技术

通常，应该保证如充足的带宽、小延迟和较少的丢包等等这样的条件以通过像互联网这样的有线IP网络来发送多媒体数据。但是，目前有线IP网络中的网络层不能提供适宜于满足视频传输所要求的服务质量(QoS)的功能。因此，应该由网络层的更高层来保证QoS。为了这个目的，已经提出了在传输层上运行的实时传输协议(RTP)和实时传输控制协议(RTCP)。

RTP是一种用于像实时产生的音频和视频这样的实时多媒体数据的互联网协议。尽管RTP本身并不保证数据的实时传输，但是通过使用RTP，在实时多媒体数据传输系统中用于发送/接收的应用程序可以支持流数据。一般在UDP(用户数据报协议)之上执行RTP。RTCP是用于维持RTP的QoS(服务质量)的一种协议。RTP仅和数据传输相关，而RTCP涉及数据传输的监控和会话相关信息的发送。为了分析网络状态以及周期性地报告网络是否拥挤，RTP节点之间彼此发送着RTCP分组。由于RTP和RTCP的使用，可以考虑与在发送多媒体数据中的时间限制相应的特征，并且有可能解决网络中所产生的损失。

在一般的多媒体数据传输系统中，多媒体应用程序(应用层)通过RTCP来检测网络状态并且控制将要被发送的实时多媒体数据的编码速率。通过传输速率控制，进行实时多媒体数据的编码速率的控制，并且通过由RTCP使用网络状态信息来估算有效传输速率的一般方法使用下面的方程1。

R (t) = \frac{1.22 \times s}{RTT (t) \times \sqrt{p (t)}}

(方程1)

R(t)表示有效传输速率，p(t)表示丢包率并且是通过从接收方发送过来的RTCP获得的。RTT(t)表示往返延迟时间，并且s表示分组的大小。

当给出了往返延迟时间(RTT(t))和丢包率(P(t))时，由方程1来估算一般有效传输速率。即，在通过使用方程1来估算传输速率的一般方法中，当分组大小(s)固定时，所估算的传输速率是根据往返延迟时间(RTT(t))和丢包率(P(t))而变化的。

图1示出了当丢包率(p(t))和分组大小(s)固定并且往返延迟时间(RTT(t))为线性变化时由方程1所估算的可用传输速率的变化。当丢包率固定为p(t)≡0.015、s≡625以及往返延迟时间(RTT(t))线性地从80毫秒增长到380毫秒时，用户的最小传输速率是50kbps以及最大传输速率是500kbps。如图1所示，随着往返延迟时间(RTT(t))的增加，所估算的可用传输速率在适当地减少。

图2示出了当往返延迟时间(RTT(t))和分组大小(s)固定并且丢包率(p(t))为线性变化时由方程1所估算的可用传输速率的变化。当往返延迟时间(RTT(t))固定为100毫秒、分组大小(s)固定为625并且丢包率(p(t))从0.1％变化到20％时，用户的最小传输速率是50kbps以及最大传输速率是500kbps。

如图2所示，在通过使用方程1来估算有效传输速率的一般方法中，没有考虑像由于很大的丢包而发生的超时这样的现象。因此，当丢包率很小时，可用传输速率被估计在一适当的数值处。但是，如果丢包率增加，则可用传输速率就会被过高估计。即，尽管丢包率10％是相当的大，但是可用传输速率被一般的传输速率估算方法不尽人意地高估为大约200kbps。

而且，一般的传输速率估算方法的缺点是：网络拥挤不能够快速地被解决，以及多媒体数据的接收质量在丢包率很大时因可用传输速率被高估而变差。

发明内容

因此，本发明的目标是提供一种多媒体数据传输速率的自适应估算方法，该方法能够通过从接收方发送过来的RTCP接收器报告分组之中检测丢包率来改善所估算的可用传输速率值的精确度，并且还能够根据丢包率变化可用传输速率的估算方法。

为了达到这些和其它优点并且与本发明的目的相一致，如此处所体现的和概括性描述的那样，提供了一种多媒体数据传输速率的自适应估算方法，包括：从多媒体数据接收单元中接收实时传输控制协议(RTCP)接收器报告分组；从RTCP接收器报告分组中检测丢包率；以及根据丢包率所落入的范围自适应地估算可用传输速率。

结合附图，本发明的前述和其它目标、特征、方面和优点将会从下面的本发明的详细描述中变得更加明白。

附图说明

所包括的附图用于提供对本发明的进一步理解并且包括在本说明书中且组成了本说明书的一部分。所述附图说明了本发明的实施例，并且与说明一起用于解释本发明的原理。

在所述的图中：

图1是说明当丢包率固定并且往返延迟时间为线性变化时由一般估算方法所估算的可用传输速率的变化图。

图2是说明当往返延迟时间固定并且丢包率为线性变化时由一般估算方法所估算的可用传输速率的变化图。

图3是说明使用RTP和RTCP的一般实时多媒体数据传输系统的配置图。

图4说明了与本发明一致的多媒体数据传输速率的自适应估算方法。

图5示出了由根据丢包率的大小而改变的一种计算方法所估算的传输速率值的图。

具体实施方式

现在将详细给出本发明较佳实施例，其例子在附图中加以说明。

图3示出了使用RTP和RTCP的一般实时多媒体数据传输系统的配置。

如所示的那样，一般的实时多媒体数据传输系统的发送单元和接收单元被各自地分成传输域和压缩域(被包括在应用层)。

发送单元的压缩域包括一个根据所估算的传输速率来编码多媒体数据的视频编码器；以及一个用来压缩编码的多媒体数据的视频压缩单元。发送单元的传输域包括一种实时传输协议层(RTP层)，该协议层可以：控制从视频压缩单元、UDP(用户数据报协议)层和IP(互联网协议)层传输过来的多媒体数据的传输，用于把从RTP层以及与RTP层相连的传输速率控制单元所传输过来的多媒体数据发送到接收单元；从接收单元所发送的RTCP接收器报告(RR)分组中检测丢包率；通过使用RTCP RR分组来测量往返延迟时间(RTT)；通过使用丢包率和往返延迟时间来估算传输速率；以及为视频编码器提供所估算的传输速率。

接收单元的传输域包括IP层和UDP层、用于控制从UDP层发送过来的多媒体数据的传输的RTP层、用于通过RTP层的RTP分组的标题中所包括的信息来监控多媒体数据QoS(服务质量)的服务质量监控单元、以及用于基于所监控到的QoS向发送单元报告信道信息的信道报告单元。信道报告单元把信道信息通过RTCP RR分组发送到发送单元。

RTCP RR分组包括用于向发送单元反馈的接收报告模块、从发送单元发送过来的RTP分组的统计信息。接收报告模块进一步包括丢包率和LSR(最后SR时间标志)。LSR表示上一个RTCP发送器报告(SR)分组的传输时间。

接收单元的压缩层包括用于解码从RTP层发送过来的多媒体数据的视频解码器。

由具有如此配置的一般多媒体数据传输系统的发送单元所发送的多媒体数据分组可能会在互联网上丢失或者可能由于过多的时间延迟而被接收单元抛弃。其它按时到达接收单元的分组通过IP/UDP/RTP层被发送到视频解码器并且接着被解码。

接收单元接收多媒体数据分组，然后通过在多媒体数据分组的RTP标题中存在的各种信息来计算关于网络状态的信息，比如丢包率、延迟等等，从而监控QoS(服务质量)。所监控的信息通过信道报告单元的实时传输控制协议(RTCP) 被反馈到发送单元。发送单元通过使用已经被反馈的信息来预测目前信道的可用带宽；并且该预测的可用带宽，即可用传输速率，被发送到视频解码器。已经接收到所预测的可用传输速率的视频解码器控制多媒体数据比特流的输出解码速率，该比特流与所预测的传输速率相对应。

本发明提出了一种新的传输速率估算方法，其中当发送单元从多媒体数据传输系统中的接收单元接收RTCP RR分组时，通过包括在RR分组中的信息来估算传输速率，而本方法并不违背TCP(传输控制协议)-友好的传输速率估算的基本概念。

在本发明应用于多媒体数据传输系统中，每当发送了预定数目的RTP分组格式的多媒体数据分组时，就发送一个RTCP分组，并且所述的预定数目作为一个例子可以是20。

图4示出了多媒体数据传输速率的自适应估算方法。

在多媒体数据传输系统中，发送单元以RTP分组格式向接收单元(S11)发送多媒体数据。此处，每当发送了预定数目的RTP分组(比如，20个RTP分组)时，就发送一个RTCP分组。因而，每当发送单元发送20个RTP分组时，它就向接收单元发送一个RTCP SR分组。RTCP SR分组包括与SR分组的传输时间相关的信息，即，在SR分组发送时NTP(网络时间协议)时间标志的值。

当接收到RTCP SR分组时，接收单元基于RTCP SR分组的NTP时间标志值获得了SR分组的传输时间；此时，接收单元还在LSR字段上记录所获得的SR分组的传输时间以产生RTCP RR分组；并向发送单元(S13)发送所产生的RTCP RR分组。RTCO RR分组包括丢包率。

已经收到RTCP RR分组的发送单元从RTCP RR分组(S15)中检测丢包率并且通过一种计算方法来估算可用传输速率(R(t_n))，该计算方法根据所检测到的丢包率而变化，如下面的方程2所示。

R (t_{n}) &equiv; \{\begin{matrix} R_{1} (p (t_{n})) = \frac{1.22 \times s}{RTT (t_{n}) \times \sqrt{p (t_{n})}} & (p (t_{n}) \leq 0.05) \\ R_{2} (p (t_{n})) = \frac{s \times 20 \times (1 - α \times p (t_{n}))}{LSR (t_{n}) - LSR (t_{n - 1})} + β & (0.05 < p (t_{n}) < 0.1) \\ R_{3} (p (t_{n})) = MinimumRate (ex . 50 kbps) & (p (t_{n}) &GreaterEqual; 0.1) \end{matrix}

(方程2)

即，当所检测的丢包率没有超过5％(p(t_n)≤0.05)时，发送单元估算可用传输速率(R₁(t_n))；当所检测的丢包率大于5％并且小于10％时，发送单元估算可用传输速率(R₂(t_n))；以及当丢包率不小于10％(p(t_n)≥0.1)时，发送单元估算可用传输速率(R₃(t_n))。

换句话说，当所检测的丢包率没有超过5％(p(t_n)≤0.05)时，发送单元通过使用方程1的一般估算方法来估算可用传输速率(R₁(t_n))。

当所检测的丢包率大于5％并且小于10％(0.05＜p(t_n)＜0.1)时，传输速率用发送20个分组所需的时间来除正常到达接收单元的、20个RTP分组的全部数据的大小，从而估算可用传输速率(R₂(t_n))。

通过使用包括在RTCP RR分组中的LSR值来计算发送20个RTP分组所需的时间。即，从当前所接收的RTCP RR分组的LSR值(LSR(t_n))中减去之前所接收的RTCP RR分组的LSR值(LSR(t_n-1))，从而获得发送20个RTP分组所需的时间。即，发送单元通过第n个反馈RR分组(RR(t_n))的LSR值(LSR(t_n))获得第n个发送的SR分组(SR(t_n))的传输时间，并且从第n个SR分组(SR(t_n))的传输时间中减去第n-1个SR分组(SR(t_n-1))的传输时间，从而获得发送20个RTP分组所需的时间(LSR(t_n)-LSR(t_n-1))。

同样，已经正常到达接收单元的全部数据的大小计算如下。发送单元检查在第n-1个SR分组(SR(t_n-1))的发送时间和第n个SR分组(SR(t_n))的发送时间之间已经正常发送的RTP分组的数目，并且通过使用所检查的正常发送的RTP分组的数目来计算正常到达的数据的大小。在第n-1个SR分组(SR(t_n-1))和第n个SR分组(SR(t_n))之间的一段时间内所正常发送的RTP分组的数目是s.20·(1-p(t_n))。p(t_n)表示从第n个RTCP RR分组中所检测的丢包率，以及s表示分组大小。

给出权重因子α和β是为了允许由不同的方程所估算出的传输速率具有连续值而并非在当丢包率是5％和10％时之间具有太大的差别。当从接收单元发送过来的RTCP RR分组的丢包率是5％并且RTCP RR分组的丢包率是10％时，通过使用方程3中的三个表达式可计算α和β。

此处，如果发送数据所需的时间是常量，用于估算可用传输速率(R₂(t_n))的方程相对于丢包率p，定义为线性表达式。

如果步骤S15中所检测的丢包率不小于10％(p(t_n)≥0.1)，那么传输单元按用户所设定的最小传输速率估算可用传输速率(R₃(t_n))。

图5示出了用一种计算方法所估算的传输速率，该方法对应于根据本发明的丢包率的大小而变化。

特别地，当s≡625、RTT≡100ms以及LSR(t_n)-LSR(t_n-1)≡RTT/2*20时，在图5中示出了与丢包率p的增长相对应的所估算的可用传输速率。此处，α＝44，β＝39560。

如图5所示，当丢包率不超过5％时，由方程3所估算的可用传输速率与方程1的结果数值(由一般的传输速率估算方法所获得的结果数值)是一样的。当丢包率大于5％并且小于10％时，由方程3所估算的可用传输速率低于方程1的结果数值；以及当丢包率不小于10％时，所估算的可用传输速率是由用户所输入的最小传输速率。

因此，根据本发明的传输速率估算方法中，当丢包率大时，所估算的可用传输速率的数值小于由一般的传输速率估算方法所获得的估算值。

如至此所描述的那样，在本发明中，从接收单元所发送的RTCP RR分组检测丢包率，并且根据所检测的分组速率所落入的范围来自适应地选择可用传输速率的估算方法，使得当丢包率大时可用传输速率被估算为较小的数值。因此，网络拥挤可以迅速解决并且可以改进由丢包引起的多媒体数据接收质量。

因为在不脱离本发明的精神和本质特点的情况下，可以以若干形式实施本发明，因此也应该理解为上述实施例并不受限于前述的任何细节，除非另有说明，否则应该广义地解释为在所附的权利要求书中所定义的构思和范围之内，且因此所有落在权利要求书的界限或这种界限的等价物以内的变化和修正都确定为由所附权利要求书所包括。

Claims

1.一种多媒体数据传输速率的自适应估算方法，包括：

从多媒体数据接收单元接收实时传输控制协议RTCP接收器报告分组，每当发送预定数目m个RTP分组时就发送一个RTCP发送器报告分组并且接收一个RTCP接收器报告分组；

从RTCP接收器报告分组中检测丢包率；以及

根据丢包率所落入的范围来自适应地估算可用的传输速率，

其中，所述估算过程包括：

当所述丢包率落入第一范围之内时由第一方程来估算所述的可用传输速率；

当所述丢包率落入第二范围之内时由第二方程来估算所述的可用传输速率；以及

当所述丢包率落入第三范围之内时由第三方程来估算所述的可用传输速率，

其中，所述第一方程包括：

R_{1} (p (t_{n})) = \frac{1.22 \times s}{RTT (t_{n}) \times \sqrt{p (t_{n})}}

R₁(p(t_n))：可用传输速率

s：分组大小

RTT(t_n)：往返延迟时间

p(t_n)：从第n个RTCP接收器报告RR分组中所检测的丢包率，

其中，所述第二个方程包括：

R_{2} (p (t_{n})) = \frac{s \times m \times (1 - α \times p (t_{n}))}{LSR (t_{n}) - LSR (t_{n - 1})} + β

R₂(p(t_n))：可用传输速率

s：分组大小

p(t_n)：从第n个RTCP接收器报告RR分组中所检测的丢包率

LSR(t_n)：第n个RTCP发送器报告SR分组的传输时间

α，β：使得由不同方程所估算出的传输速率具有连续值的权重因子，

其中，所述第三个方程包括使估算的可用传输速率为由用户所设定的最小传输速率，

所述第一范围为5％或更少，所述第二范围在5％到10％之间，以及所述第三范围为10％或更大。

2.如权利要求1所述的方法，其特征在于，所述的预定数目m是20。

3.如权利要求1所述的方法，其特征在于，所述RTCP接收器报告分组是由接收单元在LSR字段上记录所获得的所述RTCP发送器报告分组的传输时间产生的并且包括丢包率，其中所述LSR表示上一个RTCP发送器报告分组的传输时间。