CN108353074B

CN108353074B - 用于拥塞控制的方法、多点控制单元和计算机可读装置

Info

Publication number: CN108353074B
Application number: CN201580084617.9A
Authority: CN
Inventors: 英格玛·约翰森; 布·比尔曼; 弗雷德里克·加宾; 马格纳斯·威斯特兰德
Original assignee: Telefonaktiebolaget LM Ericsson AB
Current assignee: Telefonaktiebolaget LM Ericsson AB
Priority date: 2015-11-16
Filing date: 2015-11-16
Publication date: 2021-01-26
Anticipated expiration: 2035-11-16
Also published as: US20180324237A1; CN108353074A; WO2017084691A1; EP3378207B1; EP3378207A1

Abstract

提供在多点控制单元(1、10)中执行的用于多方会议中的拥塞控制的方法(30)。所述方法(30)包括：将来自发送部(2)的媒体流的分组转发(31)给多方会议的接收部(4a、4b、4c)，所述接收部(4a、4b、4c)有两个或更多个；从每个接收部(4a、4b、4c)接收(32)关于分组接收的相应接收者反馈报告；建立(33)发送者反馈报告，所述发送者反馈报告包括针对给定分组序列号的时间戳(TSRX)的发送者反馈报告，其中，所述时间戳反映具有给定分组序列号的分组已被阈值数量的接收部(4a、4b、4c)确认时的挂钟时间；以及向发送部(2)提供(34)所建立的发送者反馈报告。还提供了多点控制单元(1、10)、计算机程序和计算机程序产品。

Description

用于拥塞控制的方法、多点控制单元和计算机可读装置

技术领域

本文公开的技术一般地涉及多方会议领域，并且具体地涉及多点控制单元中的用于多方会议中的拥塞控制的方法、多点控制单元、计算机程序和计算机程序产品。

背景技术

多方会议是可由中央服务器提供的服务，其中参与者可以例如通过拨打电话号码来加入会议，或者针对基于因特网的会议，例如通过目的地地址来加入会议。多方会议单元(MCU)，也称为多点控制单元，处理对不同媒体流的信令传输、交换、混合、过滤和转发，并控制针对会议所有参与者的交换。

这种集中式多方会议中的拥塞控制并非微不足道。存在若干常规策略。一种策略是让发送参与者(发送者)将其支持的最佳可能质量提供给MCU。然后，如果MCU和相应接收参与者(接收者)之间支持的速率对于MCU接收的流而言是不足的，则针对从MCU到该特定接收者的每条支路，MCU执行转码。转码(即对流进行解码，然后以另一种格式对其进行编码)具有下述缺陷：降低质量，增大端到端等待时间，以及通常在计算方面还是昂贵的。

另一种策略是根据MCU与特定接收者之间支持的比特率对接收者进行分组。通过这种方式，可以降低MCU需要产生的不同比特率的数量。例如，可以通过发送者的转码来获得可用于传输的比特率。该策略减少了MCU中所需的不同转码的数量，从而减少了所执行转码的次数。然而，仅就上述策略而言，转码还是需要的，如所提到的，这例如会降低质量。

多媒体自计时速率适配(SCReAM)是针对实时传输协议/实时传输控制协议(RTP/RTCP)的候选拥塞控制方案。该方案是自计时的，这意味着发送的RTP分组的数量与正被确认的RTP分组的数量成正比。这使得SCReAM在拥塞情况下固有地是稳定的。与许多其他多媒体拥塞控制方案不同，SCReAM中的接收者不会向发送者传送比特率(基于速率的方案)。相反，SCReAM发送者根据SCReAM接收者发送的确认来推断可支撑的比特率。这使得支持SCReAM的MCU的设计不同于支持其他基于速率的方案的MCU。

临时最大媒体流比特率请求(TMMBR)是可以想到的用于MCU向媒体发送者指示当前针对此流所支持的最高比特率的解决方案。然而，这种解决方案对于诸如SCReAM这样的拥塞机制来说是次优的，这样的拥塞机制不会定期达成支持比特率判决，而是使用拥塞窗并由确认来驱动。

发明内容

本教导的目的是通过提高接收到的媒体流的质量并减少在很大程度上由所需的转码引起的端到端等待时间来改进多方会议。在各种实施例中，通过提供可以避免转码的方法和设备来实现该目的。

根据一个方面，通过一种在多点控制单元中执行的用于多方会议中的拥塞控制的方法来实现该目的。所述方法包括：将来自发送部的媒体流的分组转发给多方会议的接收部，所述接收部有两个或更多个；从每个接收部接收关于分组接收的相应接收者反馈报告；建立发送者反馈报告，所述发送者反馈报告包括针对给定分组序列号的时间戳的发送者反馈报告，其中所述时间戳反映具有给定分组序列号的分组已被阈值数量的接收部确认时的挂钟时间；以及，向发送部提供所建立的发送者反馈报告。

所述方法支持无需对视频流进行转码的多点控制单元操作。这是通过向发送部提供接收部处当前支持的比特率的组合反馈报告来实现的。

根据一个方面，通过一种用于多点控制单元的在多方会议中进行拥塞控制的计算机程序来实现该目的。该计算机程序包括计算机程序代码，所述计算机程序代码当在多点控制单元实体上的至少一个处理器上执行时，使得所述多点控制单元执行上述方法。

根据一个方面，通过一种包括上述计算机程序和其上存储有所述计算机程序的计算机可读装置在内的计算机程序产品来实现该目的。

根据一个方面，通过用于多方会议中的拥塞控制的多点控制单元来实现该目的。所述多点控制单元配置为：将来自发送部的媒体流的分组转发给多方会议的接收部(4a，4b，4c)，所述接收部有两个或更多个；从每个接收部接收关于分组接收的相应接收者反馈报告；建立发送者反馈报告，所述发送者反馈报告包括针对给定分组序列号的时间戳的发送者反馈报告，其中所述时间戳反映具有给定分组序列号的分组已被阈值数量的接收部确认时的挂钟时间；以及，向发送部提供所建立的发送者反馈报告。

通过阅读以下描述和附图，本教导的实施例中的其它特征和优点将变得清楚。

附图说明

图1示出了对正在发送的字节数的计算。

图2示出了根据本发明的实施例。

图3示出了根据本发明的实施例。

图4示出了用于流间切换的MCU。

图5示出了根据本发明的多点单元中的方法实施例的步骤的流程图。

图6示意性地示出了用于实现本发明的实施例的多点单元和装置。

图7示出了用于实现本发明的实施例的包括功能模块/软件模块的多点单元。

具体实施方式

在以下描述中，出于说明而非限制的目的，阐述具体细节，例如特定架构、接口、技术等，以提供完全的理解。在其他实例中，省略了对公知设备、电路和方法的详细描述，以避免因不必要的细节使描述不清楚。在本说明书全文中，同样的附图标记指代相同或相似的元素。

为了完整起见并且为了提供对本发明的全面理解，首先描述SCReAM拥塞控制。SCReAM拥塞控制主要是针对视频设计的，且与传输控制协议(TCP)类似，不同之处在于SCReAM不确保任何直至高层的顺序传递。因此，在下面解释SCReAM的一些基础知识。

首先，描述在发送侧执行的方案，如一系列指令。网络拥塞控制执行两个主要功能：拥塞窗的计算和传输调度。拥塞窗的计算给出正在发送的字节数(即已经发送但尚未被确认的字节数)的上限。传输调度确保仅在正在发送的字节(bytes in flight)数与拥塞窗之间的关系允许的情况下才发送RTP分组。

与TCP不同，SCReAM不是面向字节的协议；相反SCReAM是面向RTP分组的协议。SCReAM保存已发送RTP分组的列表及其各自的发送时间(挂钟时间)。该列表还包括在RTP中使用的同步源标识符(表示为SSRC)，其唯一地标识流的源。此外，该列表还包括有效载荷类型(PT)，其使得在网络拥塞控制调度多个流的情况下，拥塞控制在流之间能够得以区分。反馈指示接收到的最高RTP序列号和接收到它时的时间戳(挂钟时间)。此外，包括确认(ACK)列表，以能够确定丢失的分组。

针对SCReAM协议的反馈格式正在开发中，最终标准化的使用SCReAM协议或它的基于类似ACK计时原理的某种衍生协议的拥塞控制可以使用不同的反馈格式。针对实时会话媒体的SCReAM协议可以利用实时传输控制协议(RTCP)作为反馈的载体来实现，但也可以设想使用其他协议作为反馈的载体。反馈首部字段可因选择而异。然而，给发送侧(在下文中也标为发送者)的SCReAM反馈中的与根据本教导的实施例有关的元素包括：

·时间戳(TS)：时间戳值指示何时接收到最后一个RTP分组，其使得有可能计算单向(额外)延迟(OWD)。

·SN_highest：接收到的RTP分组的最高序列号(SN)。

·ACK向量：指示序列号小于SN_highest的RTP分组的接收状态。

·N_lost：丢失的RTP分组的累积数量。

·N_ECN：标有显式拥塞通知(ECN)遇到拥塞(CE)的分组的累积数量；即互联网协议(IP)分组内的ECN字段被设置为CE。

·源抑制比特(Q)：使得有可能请求发送者减小其拥塞窗。这在下述情况下是有用的：从多个主机接收RTP分组，并且变得有必要平衡共享相同(拥塞的)传输资源的流之间的比特率。

在下文中，SCReAM反馈被标为SCFB。

图1示出了对正在发送的字节数的计算。正在发送的字节数被计算为：从最近被发送的RTP分组直至但不包括具有最高序列号的已确认分组这一范围内的RTP分组的大小的总和。在图1中，RTP分组及其序列号(SN)SN-7、SN-6、...、SN-1、SN被示出在最上面。已确认的RTP分组被示出在下面，其中具有序列号SN-4的RTP分组丢失，如叉所示。因此，对于图1所示的情况，正在发送的字节被计算为具有序列号SN-2、SN-1和SN的RTP分组的大小(以字节为单位)的总和：

正在发送的字节＝字节(分组SN-2)+字节(分组SN-1)+字节(分组SN)

SCReAM中的视频速率控制基于对发送者中的RTP分组排队延迟的测量。

接下来，描述接收侧执行的方案，例如一系列指令。接收侧(在下文中也标为接收者)为每个接收到的RTP分组打上时间戳，并准备具有反馈元素的SCFB分组。下面，仅列出与本教导相关的来自接收者的SCReAM反馈元素。

·TS_RX：接收到的具有最高序列号的RTP分组的时间戳。

·SN_highest：接收到的最高RTP序列号。

·ACK列表：指示接收到的RTP分组的32比特向量。与RTP序列号的组合有可能确认最近接收到的33个RTP分组。应该注意，可以通过使用反馈元素SN_highest(即没有ACK列表)来确认直至并包括某个RTP序列号的所有分组。但是，因为ACK列表为最近接收到的33个RTP分组提供确认，所以可以针对这33个最近收到的RTP分组选择性地获得确认。

·N_loss：丢失的RTP分组的累积数量

·N_ECN：标记有ECN CE的分组的累积数量

·SSRC：用于在流之间进行区分，以能够正确计算正在发送的字节。

·Q比特：如果要求发送者降低给定流的比特率，则设置。SCFB中的Q比特由接收者设置，以发信号通知发送者应该降低比特率。作为对此的响应，发送者将减小拥塞窗，其结果是媒体比特率下降。源抑制的典型用例是在接收者接收来自位于不同主机处的源的流时，其中通常难以在发送主机之间应用任何速率分配信令。于是一种解决方案是：接收者在给发送者的反馈中设置该Q比特，从而向发送者指示它应该降低它的速率。如果这些流共享共同的瓶颈，则通过针对在反馈中已经设置了Q比特的流减小拥塞窗所释放的带宽将被尚未设置Q比特的其他流抓取。这由SCReAM拥塞控制的机会式行为来保证。

拥塞窗的减小与设置了Q比特的SCFB反馈的数量成正比。该减小是每个往返时间(RTT)执行一次，所述返回时间即从分组的发送到接收其确认所经过的时间。

令：

N＝一个RTT中接收到的SCFB消息的数量

NQ＝一个RTT中接收到的设置了Q比特的SCFB消息的数量。

于是新的拥塞窗(CWND)表示为：

cwnd＝max(min_cwnd，cwnd*(1.0-0.5*NQ/N))

如果由于在SCFB中设置了Q比特导致CWND已经减小，则应该针对一个RTT禁止增大CWND。应该注意，CWND在每个RTT最多调整一次。极端的情况是，如果所有SCFB反馈都设置了Q比特，则在这种情况下，对于每个RTT，CWND减半。

简言之，根据本教导，来自多个不同端点的SCReAM反馈分组以下面的方式组合：发送者看到从发送者经由MCU到任何端点的当前参考路径。换言之，选择参考路径来表示发送者与不同端点之间的路径。例如，参考路径可能是质量最差的路径。在其它实施例中，参考路径可以被配置为是第N差的路径，从而以牺牲N-1个路径为代价来降低对具有较好路径的接收者的损害，其中所述N-1个路径具有甚至更差的路径并且因此将经历额外的损伤。该解决方案确保发送者能够持续调整其比特率，以适应该组接收者中的实际可用路径比特率。

在下文中，RTP用于举例说明本教导。然而，需要注意，可以使用其他协议，如快速UDP互联网连接(Quic)协议。因此，应该注意，RTP和RTP分组在说明书以及附图中纯粹作为示例用于示意说明。

MCU可以以不同的方式将媒体流(如视频流)转发给多个接收者。在图2中，在MCU 1中针对每个接收端点(也称为接收者)实现网络拥塞控制。在图3中，MCU 10没有针对接收端点的拥塞控制实例，并且MCU 10在接收时(不排队)传送来自发送者2的分组。根据本教导，使用(例如组合)来自接收端点的SCFB分组或SCFB分组中的反馈元素，并且生成公共SCFB分组并向接收者发送所述公共SCFB分组。

图2示出了根据本发明的实施例，其实现基于每个接收端点的网络拥塞控制。MCU1终止发送者2与MCU 1之间的网络拥塞控制部分。来自发送者2的RTP分组被临时存储在MCU1的RTP队列3a、3b、3c中。基本原理是：针对每个接收机4a、4b、4c(在下文中由用户设备UE示范)的RTP分组以每个相应UE所支持的速度进行转发。相应的速度由每个相应的单独的拥塞控制实例控制。针对第一接收者4a描述拥塞控制实例，但是每个接收者4a、4b、4c具有对应的拥塞控制实例。拥塞控制实例包括RTP队列3a、拥塞控制7和传输调度器6。传输调度器6向拥塞控制7提供信息，诸如：发送分组的时间戳(TS_TX)、RTP分组的序列号(由图中的RTP_SN指示)和RTP分组的大小(RTP_size)。除此信息之外，拥塞控制7还接收来自接收者4a的SCFB，确定拥塞窗CWND、RTT和正在发送的字节，并将其作为输入提供给传输调度器6。基于该输入，传输调度器6经由用户数据报协议(UDP)套接字8将来自RTP分组队列3a的RTP分组发送给第一接收者4a。每个拥塞控制实例维护已发送RTP分组的列表，以便能够计算正在发送的字节并适当地更新拥塞窗。

MCU 1还包括反馈报告生成器5和针对发送者2的UDP套接字9(或其他接口)。反馈报告生成器5可以被配置为根据本文描述的任何实施例或其组合来组合来自UE 4a、4b、4c的SCFB。

根据本教导，当所有UE 4a、4b、4c已经确认了给定(或更高)的RTP序列号时，从MCU1向发送者2发送针对给定RTP序列号的SCFB分组。接收到的具有最高序列号的RTP分组的时间戳TS_RX被设置为在所有UE 4a、4b、4c已经确认具有该RTP序列号的分组时的挂钟时间。这样，将向发送者2通知接收UE 4a、4b、4c中具有最差吞吐量的UE的可用吞吐量。

在备选实施例中，严格的“必须全部确认规则(all-must-ACK-rule)”可以稍微放松。例如，X％的UE(例如超过70％的接收者或超过90％或95％的接收者)确认给定的RTP序列号可能就足够了。如果想要降低多个UE中的处于较差覆盖的单个UE减小所有UE的比特率的风险，这可能是有益的。潜在的缺点是：尚未确认RTP序列号的UE将获得差的质量，所以这里存在一个平衡点。另外，有可能对其ACK没被考虑的具有较差覆盖的UE的视频进行转码甚至冻结。

作为具体示例，假设由MCU向10个UE转发流。MCU 1体验到10个UE中的9个通常在给定的时间跨度(T_ACK90％)内确认RTP分组，而第10个UE具有例如由于第10个UE具有差的无线电条件引起的ACK晚点到达造成的问题。下述做法可以是较优的：不同于让所有10个UE与具有较差无线电条件的UE共享速率，排除该UE参与从MCU 1到发送者2的反馈。

在一些实施例中，该第10个UE(或更多UE，如果设置了另一T_ACK90％的话)的流可以例如在相应的拥塞控制实例3a，6，7中通过下述方式处理：对具有较差无线电条件的UE(或多个UE)进行流精简(thinning)或转码成相当低的比特率。流精简是一种有选择地去除编码流的部分的方法，其目的在于在不经过转码且对解码过程的结果影响最小的情况下实现较低的比特率。

每个UE的拥塞控制实例3a，6，7可以以常规方式应对分组丢失处理，所述常规方式如使得丢失事件触发拥塞窗的减小。

让MCU 1指示在相应MCU到接收者路径中的每一个路径上丢失的所有分组的总和将是不利的，因为这会给发送者2留下比任何实际路径更差的情况的印象。相反，MCU 1可以向发送者2提供表示最差的MCU 1到接收者4a、4b、4c路径的SCFB。这可以通过报告发送者2到MCU 1路径上的丢失分组的数量与在最差的MCU 1到接收者4a、4b 4c路径上的丢失分组的数量的组合来完成。

在从UE 4a、4b、4c到MCU 1的SCFB指示RTP分组丢失并且所述RTP分组仍然存储在MCU 1处的RTP队列中的情况下，可以避免向发送者2报告所述RTP分组丢失，而是代之为从MCU 1重传它们。如果向发送者2报告分组丢失，则指示丢失分组的UE 4a、4b、4c将因而要求从发送者2发送更多的数据，这继而可能延迟后续RTP分组到给定的UE 4a、4b、4c的传输，其可能的效果是返回的确认也被延迟。如果UE 4a、4b、4c具有较差吞吐量，则从MCU 1到发送者2的确认也将因此而延迟，可能的影响是发送者2的比特率降低。

附加考虑是SCFB ACK向量(如果存在的话)只能指示对有限数量(这里是32+1＝33)的最高RTP序列号的接收。这意味着：如果重传的RTP分组再次丢失，则可能无法检测到。那么通过其他方式恢复是必要的。

源抑制比特(Q)用于减小拥塞窗。如果在报告间隔期间任何UE 4a、4b、4c已经指示设置了Q比特，则MCU 1可以在从MCU 1到发送者2的下一个反馈中设置Q比特。然而，由于非同步报告，MCU 1可能需要跟踪它是否在上一次报告中向发送者2发送了Q比特，并且不转发附加的接收者Q比特，直到一个报告间隔过去。

如前所述，可以排除与其他UE 4b，4c相比具有非常差的吞吐量的少量UE 4a参与从MCU 1到发送者2的反馈。在这种上下文中的一个附加特征是：对具有非常差的吞吐量的这些UE应用转码或其他处理，如流精简。

图3示出了根据本教导的另一实施例，其中来自接收端点4a、4b、4c的SCFB分组被再次组合并且产生公共SCFB分组。在该实施例中，与参考图2描述的实施例相比，没有针对UE 4a、4b、4c实现拥塞实例3a，6，7。SCFB反馈组合器5基于从每个UE 4a、4b、4c接收的SCFB报告来创建给发送者2的组合的SCFB报告。这样做的优点是：MCU 10中不再需要任何附加的传输队列。相反，传入的RTP分组可以立即转发，从而使延迟最小化。参照图2描述的实施例也可以针对图3的MCU 10实现，即可以使用相同的SCFB元素。这些SCFB元素的获得方式可能略有不同，从以下内容可以清楚看出这一点。

可被组合的SCFB要素包括(例如)：

1.TS_RX：即与接收到的最高RTP序列号对应的接收者时间戳

2.接收到的最高RTP序列号

3.ACK向量(如果有的话)

4.N_loss

5.N_ECN

来自不同UE 4a、4b、4c的SCFB的接收到的最高序列号和ACK列表可被组合到一个SCFB报告中以发回给发送者2。如前所述，只有当超过X％的UE 4a、4b、4c已经确认RTP序列号SN(t)时才创建具有最高序列号＝SN(t)的SCFB报告并且在时刻t将其发送给发送者2。如果期望保持高的比特率，则X可能小于100％，风险在于具有较差覆盖的UE 4a、4b、4c获得较差的性能。

例如，可以实现ACK列表的创建，使得所有比特最初都被设置为′1′。如果UE 4a、4b、4c中的任何一个已经指示了针对给定序列号的丢失分组，则组合的SCFB报告中的对应比特被设置为′0′。如前所述，必须考虑不会由于分组丢失指示的组合而造成较差吞吐量。一种备选方案是选择具有最差条件的UE 4a、4b、4c的ACK向量，或向发送者2通知关于接收者4a、4b、4c的数量。于是发送者2可以在对丢失事件采取适当的动作进行响应时考虑接收者4a、4b、4c的数量，而不会过多地减小拥塞窗。

在另一实施例中，可以实现组合的N_loss计数器，使得每当来自接收者4a、4b、4c中任何一个的N_loss反馈元素增大时，计数器就增加。与上面的推理类似，由于累积分组丢失敏感性，这可能导致较差吞吐量。因此，在一些实施例中，仅考虑来自最差接收者4a、4b、4c的N_loss个反馈元素。

对N_ECN计数器的处理可以通过与针对N_loss计数器描述的方式来实现。

根据图3的实施例，当实现MCU 10时，用于获得组合反馈分组的TS_RX的组合功能需要一些额外的努力。一个复杂的问题在于：不同UE4a、4b、4c的接收时间戳从不同的(可能是随机的)偏移开始。

令第一UE 4a成为加入会话的第一UE。该第一UE 4a的TS_RX是TS_RX(SN)，其中SN是接收到的与给定的TS_RX相对应的最高序列号。根据该向量计算UE特定的偏移。通常，偏移已经由第一个接收到的反馈给出，但是更高级的函数可以迭代地确定更精确的偏移，考虑到甚至第一个分组可能就已经经历了延迟抖动，于是需要RTP时间戳和关于RTP采样率的知识。

当新UE到达时，第二UE 4b重复用于获得新的UE特定的偏移的相同过程。在从MCU10到发送者2的组合SCFB报告中，TS_RX将使用获得的偏移量以便创建一致的TS_RX(SN)，即，当改变指示向发送者2传输反馈报告的UE时不显示不连续性。

此过程可能是需要的，因为它是设定了TS_RX的最后确认给定序列号的UE SCFB报告。由于信道条件可能变化，因此要报告的“上一次”UE 4a、4b、4c报告可能随时间而变化。

由MCU 10将来自各个接收者4a、4b、4c的Q比特的值转发给发送者2。如果任何接收者4a、4b、4c已经指示设置了Q比特，则在报告间隔期间，MCU 10应当在从MCU 10到发送者2的下一个反馈中设置Q比特。然而，由于非同步报告，MCU 10将需要跟踪它在对发送者2的上一次报告中是否发送了Q比特，并且直到至少一个报告间隔已经过去才转发附加的接收者Q比特。这与图2所示实施例的Q比特处理一致。

图4示出根据本公开的另一实施例。具体地，MCU 20被示出为针对每个接收者4a、4b(仅示出了两个)具有拥塞实例3a、6、7(特别是SCReAM拥塞控制实例)。关于图2给出了这种控制实例的描述，并参考该描述。MCU 20还包括反馈报告生成器，如已经描述的，反馈报告生成器用于实现根据本教导的组合反馈。在该实施例中，每个流具有用于向相应的发送者2a、2b提供SCFN报告的相应的反馈报告生成器5a、5b。

MCU 20还包括在流之间切换的交换机21。图4示出了在两个发送者2a、2b之间切换的示例。来自相应发送者2a、2b的流在相应的队列22a、22b中排队。MCU 20获取来自两个或更多个发送者2a、2b的视频流，并且将所选视频流转发给一个或多个接收者4a、4b。RTP序列号在转发的RTP分组中重新生成。

交换机21配置有传统的交换功能，例如向正处于接通的发送者2a、2b发送全帧内请求(FIR)，以在交换点处获得的干净的解码器开始点。SCReAM在这方面不做任何改变。媒体(例如视频)的有效压缩的编码表示通常涉及发送与先前媒体样本(如视频图片)的差异。因此，为没有收到先前样本的接收机获取“开始点”需要向媒体发送编码器发送请求，要求它发送不使用与先前样本的差异的媒体样本。应该注意，FIR仅是这种请求(即，通过不使用媒体样本的任何差异来请求发送开始点的请求)的一个具体示例。这个请求是必需的，因为发送者一般不知道它发送的媒体流何时被MCU“访问”，即，何时媒体流正被转发给不具有解码媒体所需的差异的历史的接收者。

正如已经关于图2所描述的，当前被有效转发的流被确认。为了实现这一点，应该维护在由发送者2a、2b给出的RTP序列号与由MCU 20实现的序列编号之间的映射。需要该映射，以便向活动(active)的发送者2a、2b确认正确的RTP序列号。

不活动(即，媒体未被转发)的发送者2a和2b带来额外的挑战，因为它不知道在发送者并非不活动时端到端特征会是什么。这可以被实现为使得在MCU 20接收到RTP分组时直接确认接收到的RTP分组。然而，当流被切换为活动的(即正被转发)并且SCFB报告中的信息基于始终来自下行链路接收机4a、4b的测量而不是仅来自MCU 20的测量时，这样做可能在单向延迟中产生不自然的跳跃。一种可以想到的解决方案是延迟与通过从MCU 20到接收者4a、4b的方向上的链路测量的RTT相对应的确认D_Inactive。通常，它是MCU 20与接收者4a、4b之间的具有指示延迟的最长RTT的路径，但是在例如前面描述的应用X％的接收者4a、4b的规则的情况下，该延迟可以替代地根据实际参与到对发送者2a、2b的反馈的接收者4a、4b来确定。在此情况下，发送者2a、2b测量的单向延迟受交换的影响将变得最小。

(尚)未有接收者4a、4b连接的情况施加很小的挑战，因为针对MCU 20与预期的接收者4a、4b之间的链路尚未有任何RTT估计。因此，D_Inactive被初始化为一旦接收者4a、4b连接就可能发生的RTT的估计。

上述方案的备选方案是：不管发送者2a、2b与MCU 20之间的路径的状态如何，都向不活动的发送者发送表明一切正常的SCFB报告。又一备选方案是：在SCFB报告中的比特中显式指出发送者2a、2b正在变为活动的，这意味着所报告的路径从仅MCU 20改变到现在还包括MCU到接收者路径，在这种情况下，发送者2a、2b可以采取适当的动作来确保发送者的拥塞控制正常工作。这种动作的例子可以是重置基本延迟历史。在SCReAM中基本延迟历史被用来估计排队延迟。发送者侧和接收者侧的时间戳时钟不同步。这意味着无法测量分组从发送者行进到接收者所需的准确时间。相反，所使用的方法是估计基本延迟，以便估计网络中的排队延迟。根据下式，基本延迟被计算为每个已经确认的RTP分组的TS_Tx和TS_Rx中的最小值：

baseDelay＝min(baseDelay，TS_Rx-TS_Tx)；baseDelay被初始化为非常大的值。

baseDelay可能随着时间推移(例如，由于路线变化)变为无效。由于这个原因，维护和更新(例如，每10秒更新一次)基本延迟的历史(baseDelayHistory)。向量baseDelayHistory的大小限于例如20个元素，这意味着旧的baseDelay估计值会随着时间的推移而被移出。

对于每个确认的分组，单向延迟(OWD)被计算如下：

OWD＝TS_Rx-TS_Tx-min(baseDelayHistory)

在MCU的情况下，每个主机可能发送两个或更多个代表相同内容但具有不同质量的流(同时播放)。对此的支持可以通过每个SCReAM实例的对应数目的附加RTP分组队列(寻址相应的接收机4a、4b)来实现。在这种情况下，对给发送者2a、2b的SCFB报告的管理比较简单，因为同一主机中的同时播放的所有发送者都或者被认为是“活动的”，或者被认为是“非活动的”。

已经描述的各种特征和实施例可以以不同的方式来组合，下面首先参考图5来给出其示例。

图5示出了根据本发明的多点单元中的方法实施例的步骤的流程图。提供了用于多方会议中的拥塞控制的方法30，该方法可在多点控制单元1、10中实现和执行。发送部2可被配置为使用自计时速率适配方案，其中发送部不从接收者获得比特率，而是依赖于要被发送的分组(例如RTP分组)的数量与接收者确认的分组的数量成比例。

方法30包括：将来自发送部2的媒体流的分组转发31给多方会议的接收部4a、4b、4c，所述接收部4a、4b、4c有两个或更多个。

方法30包括：从每个接收部4a、4b、4c接收32关于分组接收的相应接收者反馈报告。

方法30包括：建立33发送者反馈报告，所述发送者反馈报告包括针对给定分组序列号的时间戳TS_RX，其中，所述时间戳反映具有给定分组序列号的分组已被阈值数量的接收部4a、4b、4c确认时的挂钟时间。发送者反馈报告可被视为指示代表(或适用于)每个接收部4a、4b、4c的参考路径。具有给定分组序列号的分组可以由接收者通过针对该特定分组的确认来显式确认，或者可以通过后面的序列号来确认。换言之，可以通过以下方式确认具有给定分组序列号的分组：在反馈中指示更高的分组序列号以及对没有发生分组丢失的指示(例如，在SCReAM的情况下使用ACK向量)，因此也确认给定的分组。

方法30包括将建立的发送者反馈报告提供34给发送部2。

根据本教导，向发送者提供关于接收者组内支持的速率的信息，并将速率适配到适合所有接收者的速率。方法30不需要在多点控制单元中对例如视频流进行转码。这与现有技术形成对比，在现有技术中发送者知道每个接收者或接收者组的最佳速率，并且MCU被迫执行转码或速率转换以根据不同接收者的具体情况将比特率调整到更合适的速率。在现有技术中，也在使用同时播放的情况下，由于缺乏对当前支持的比特率的了解，会导致接收者被迫接收质量低于在发送者如果知道目标组中支持的速率的情况下能够获得的质量。

在各种实施例中，已经确认分组的接收部4a、4b、4c的阈值数量被设置为超过全部接收部4a、4b、4c的50％，或者设置为超过全部接收部4a、4b、4c的70％、90％或95％，或者设置为全部接收部4a、4b、4c的100％。

在一些实施例中，所述建立33包括：确定所述时间戳(TS_RX)，使得排除一个或多个接收者反馈报告。应该注意，接收者反馈报告可能因不同原因被排除。接收者反馈报告可能因为下述原因被排除：因为它从未被发送并因此不可能被接收，或者因为它被发送但仍未被接收到(例如在途中或丢失)，或者因为它显式排除，即被选择排除。如已经描述的，可以通过选择来排除具有非常差的接收条件的接收部的接收者反馈报告，以便该接收部不会过多地影响其他接收部的质量。

在上述实施例的变型中，方法30包括：针对一个或多个接收部4a、4b、4c中的每一个被排除了接收者反馈报告的接收部，对媒体流进行转码或流精简。

在各种实施例中，方法30包括：向已经在其反馈报告中指示分组丢失的接收部4a、4b、4c重传分组。如果多点控制单元1、10具有可用的分组，则它可以将分组发送给已经将所述分组指示为丢失的接收部4a、4b、4c，从而减轻发送者重新发送分组的需求，并且因此减小延迟。

在各种实施例中，方法30包括：当从至少两个接收部4a、4b、4c接收的至少一个反馈报告包括设置的源抑制比特时，在发送者反馈报告中设置源抑制比特。

在各种实施例中，多点控制单元1、10利用多媒体自计时速率适配(SCReAM)拥塞控制的反馈元素。

在各种实施例中，所接收的接收者反馈报告包括对丢失分组的累积数量进行计数的反馈元素N_loss，并且所述方法30包括：每当接收到的反馈报告指示反馈元素N_loss增大时增大计数器C1，并且基于所述计数器C1值在发送者反馈报告中包括反馈元素N_loss。

在各种实施例中，方法30包括：在第一发送者和第二发送者之间切换，且其中，所述提供34包括提供具有延迟的相应发送者反馈报告，所述延迟是基于在所述多点控制单元与所述接收部4a、4b、4c中的一个或多个之间的往返行程延迟计算的。

图6示意性地示出了多点单元1，10和用于实现本发明的实施例的装置。

多点单元1，10包括处理器40，处理器40包括能够执行存储在存储器41中的软件指令的中央处理单元(CPU)、多处理器、微控制器、数字信号处理器(DSP)、专用集成电路等中的一个或多个的任意组合，其中存储器41因此可以是计算机程序产品41。处理器40可以被配置为执行例如关于图5所描述的方法的各种实施例中的任意一个。

存储器41可以是读写存储器(RAM)和只读存储器(ROM)、闪存、磁带、光盘(CD)-ROM、数字多功能盘(DVD)、蓝光盘等的任意组合。存储器41还可以包括永久存储器，其例如可以是磁存储器、光存储器、固态存储器甚或远程安装的存储器中的任何单独一个或组合。

多点控制单元1、10包括用于与其他设备(特别是如前所述的发送部和接收部)进行通信的一个或多个接口8，9。这样的接口可以例如包括一个或多个UDP套接字。接口8，9可以包括诸如接口、协议栈等装置，并且多点控制单元1、10例如可以从多方会议的接收部接收接收者反馈报告，并通过这样的接口向发送部发送发送者反馈报告。

多点控制单元1、10包括反馈报告生成器5，反馈报告生成器5如之前参照例如图2和图3已经描述的那样。

在一些实施例中，多点控制单元1、10可以可选地包括拥塞控制实例45，例如，如之前参考图2所描述的，包括拥塞控制7、传输调度器6和队列处理3a。这种拥塞控制实例在这里用附图标记45表示。

在一些实施例中，多点控制单元1、10可以可选地包括交换装置21，用于在发送自两个或更多个发送部的流之间进行切换。已经参照图4描述了这种交换装置21。

多点控制单元1、10可以包括附加处理电路(其以附图标记44示意性地指示)，用于实现根据本教导的各种实施例。

本教导提供用于多点控制单元1、10的用于多方会议中的拥塞控制的计算机程序42。计算机程序42包括计算机程序代码，所述计算机程序代码当在多点控制单元1、10上的至少一个处理器40上执行时，使得多点控制单元1、10执行根据所描述的实施例中的任意一个的方法30。

本公开还包括计算机程序产品41，其包括：用于实现所描述的方法的实施例的计算机程序42，以及存储有计算机程序42的计算机可读装置。因此，所述计算机程序产品或存储器包括可由处理器40执行的指令。这样的指令可以包括在计算机程序中，或者包括在一个或多个软件模块或功能模块中。如前所述，计算机程序产品41可以是随机存取存储器(RAM)或只读存储器(ROM)、闪存、磁带、压缩盘(CD)-ROM、数字通用盘(DVD)、蓝光盘等的任意组合。

多点控制单元1、10被提供用于多方会议中的拥塞控制。所述多点控制单元1、10被配置为：

-将来自发送部2的媒体流的分组转发给多方会议的接收部4a、4b、4c，所述接收部4a、4b、4c有两个或更多个；

-从每个接收部4a、4b、4c接收关于分组接收的相应接收者反馈报告；

-建立发送者反馈报告，所述发送者反馈报告包括针对给定分组序列号的时间戳TS_RX，其中，所述时间戳反映具有给定分组序列号的分组已被阈值数量的接收部4a、4b、4c确认时的挂钟时间；以及

-向发送部2提供所建立的发送者反馈报告。

多点控制单元1、10可以被配置为例如通过包括处理器40和存储器41来执行所述实施例的步骤，存储器41包含可由处理器40执行的指令，由此多点控制单元1、10可操作以执行这些步骤。

在各种实施例中，多点控制单元1、10被配置为：通过确定时间戳TS_RX使得排除一个或多个接收者反馈报告来建立。

在各种实施例中，多点控制单元1、10被配置为：针对一个或多个接收部4a、4b、4c中的每一个被排除了接收者反馈报告的接收部，对媒体流进行转码或流精简。

在各种实施例中，多点控制单元1、10被配置为：向已经在其反馈报告中指示分组丢失的接收部4a、4b、4c重传分组。

在各种实施例中，多点控制单元1、10被配置为：当从至少两个接收部4a、4b、4c接收的至少一个反馈报告包括设置的源抑制比特时，在发送者反馈报告中设置源抑制比特。

在各种实施例中，多点控制单元1、10被配置为：利用多媒体自计时速率适配(SCReAM)拥塞控制的反馈元素。

在各种实施例中，接收的接收者反馈报告包括对丢失分组的累积数量进行计数的反馈元素N_loss，以及所述多点控制单元1、10被配置为：每当接收到的反馈报告指示反馈元素N_loss增大时增大计数器C1，并且基于所述计数器C1值在发送者反馈报告中包括反馈元素N_loss。

在各种实施例中，多点控制单元1、10被配置为在第一发送者和第二发送者之间切换，并且被配置为提供具有延迟的相应发送者反馈报告，所述延迟是基于在所述多点控制单元与所述接收部4a、4b、4c中的一个或多个之间的往返行程延迟计算的。

图7示出了用于实现本发明的实施例的包括功能模块/软件模块的多点控制单元。所述装置(例如功能模块，例如功能模块)可以使用诸如在处理器中执行的计算机程序的软件指令、和/或使用诸如专用集成电路(ASIC)、现场可编程门阵列、离散逻辑组件等硬件以及其任何组合来实现。可以提供处理电路，处理电路可以是可适配的，并且特别适用于执行已经描述的方法的任何步骤。

提供了用于多方会议中的拥塞控制的多点控制单元1、10。该多点控制单元1、10包括：第一装置51，用于将来自发送部的媒体流的分组转发给多方会议的接收部，所述接收部有两个或更多个。

多点控制单元1、10包括：第二装置52，用于从每个接收部接收关于分组接收的相应接收者反馈报告。

多点控制单元1、10包括：第三装置53，建立发送者反馈报告，所述发送者反馈报告包括针对给定分组序列号的时间戳，其中，所述时间戳反映具有给定分组序列号的分组已被阈值数量的接收部确认时的挂钟时间。

多点控制单元1、10包括：第四装置54，用于向发送部提供所建立的发送者反馈报告。

多点控制单元1、10可以包括用于实现已经描述的方法20的各种实施例的其他装置。

已经参考一些实施例在本文中主要地描述了本发明。然而，如本领域技术人员理解的，除了本文所公开的具体实施例之外的其他实施例同样可能在由所附专利权利要求限定的本发明的范围内。

Claims

1.一种在多点控制单元(1、10)中执行的用于多方会议中的拥塞控制的方法(30)，所述方法(30)包括：

-将来自发送部(2)的媒体流的分组转发(31)给多方会议的接收部(4a、4b、4c)，所述接收部(4a、4b、4c)有两个或更多个；

-从每个接收部(4a、4b、4c)接收(32)关于分组接收的相应接收者反馈报告；

-建立(33)发送者反馈报告，所述发送者反馈报告包括针对给定分组序列号的时间戳(TS_RX)，其中，所述时间戳反映具有给定分组序列号的分组已被阈值数量的接收部(4a、4b、4c)确认时的挂钟时间；以及

-向发送部(2)提供(34)所建立的发送者反馈报告。

2.根据权利要求1所述的方法(30)，其中，已经确认分组的接收部(4a、4b、4c)的阈值数量被设置为超过全部接收部(4a、4b、4c)的50％，或者设置为超过全部接收部(4a、4b、4c)的70％、90％或95％，或者设置为全部接收部(4a、4b、4c)的100％。

3.根据权利要求1或2所述的方法(30)，其中，所述建立(33)包括：确定所述时间戳(TS_RX)，使得排除一个或多个接收者反馈报告。

4.根据权利要求3所述的方法(30)，包括：针对一个或多个接收部(4a、4b、4c)中的每一个被排除了接收者反馈报告的接收部，对媒体流进行转码或流精简。

5.根据权利要求1或2所述的方法(30)，包括：向已经在其反馈报告中指示分组丢失的接收部(4a、4b、4c)重传分组。

6.根据权利要求1或2所述的方法(30)，包括：当从至少两个接收部(4a、4b、4c)接收的至少一个反馈报告包括设置的源抑制比特时，在发送者反馈报告中设置源抑制比特。

7.根据权利要求1或2所述的方法(30)，其中，所述多点控制单元(1、10)利用多媒体自计时速率适配SCReAM拥塞控制的反馈元素。

8.根据权利要求1或2所述的方法(30)，其中，所接收的接收者反馈报告包括对丢失分组的累积数量进行计数的反馈元素N_loss，并且所述方法(30)包括：每当接收到的反馈报告指示反馈元素N_loss增大时增大计数器(C1)，并且基于所述计数器(C1)值在发送者反馈报告中包括反馈元素N_loss。

9.根据权利要求1或2所述的方法(30)，包括：在第一发送者和第二发送者之间切换，且其中，所述提供(34)包括提供具有延迟的相应发送者反馈报告，所述延迟是基于在所述多点控制单元与所述接收部(4a、4b、4c)中的一个或多个之间的往返行程延迟计算的。

10.一种存储计算机程序(42)的计算机可读装置，所述计算机程序(42)用于多方会议中的拥塞控制的多点控制单元(1、10，20)，所述计算机程序(42)包括计算机程序代码，所述计算机程序代码当在所述多点控制单元(1、10，20)上的至少一个处理器上执行时使所述多点控制单元(1、10，20)执行根据权利要求1-9中任一项所述的方法(30)。

11.一种用于多方会议中的拥塞控制的多点控制单元(1、10)，所述多点控制单元(1、10)被配置为：

-将来自发送部(2)的媒体流的分组转发给多方会议的接收部(4a、4b、4c)，所述接收部(4a、4b、4c)有两个或更多个；

-从每个接收部(4a、4b、4c)接收关于分组接收的相应接收者反馈报告；

-建立发送者反馈报告，所述发送者反馈报告包括针对给定分组序列号的时间戳(TS_RX)，其中，所述时间戳反映具有给定分组序列号的分组已被阈值数量的接收部(4a、4b、4c)确认时的挂钟时间；以及

-向发送部(2)提供所建立的发送者反馈报告。

12.根据权利要求11所述的多点控制单元(1、10)，其中，已经确认分组的接收部(4a、4b、4c)的阈值数量被设置为超过全部接收部(4a、4b、4c)的50％，或者设置为超过全部接收部(4a、4b、4c)的70％、90％或95％，或者设置为全部接收部(4a、4b、4c)的100％。

13.根据权利要求11或12所述的多点控制单元(1、10)，配置为通过下述方式来进行建立：确定所述时间戳(TS_RX)，使得排除一个或多个接收者反馈报告。

14.根据权利要求13所述的多点控制单元(1、10)，配置为：针对一个或多个接收部(4a、4b、4c)中的每一个被排除了接收者反馈报告的接收部，对媒体流进行转码或流精简。

15.根据权利要求11或12所述的多点控制单元(1、10)，配置为：向已经在其反馈报告中指示分组丢失的接收部(4a、4b、4c)重传分组。

16.根据权利要求11或12所述的多点控制单元(1、10)，配置为：当从至少两个接收部(4a、4b、4c)接收的至少一个反馈报告包括设置的源抑制比特时，在发送者反馈报告中设置源抑制比特。

17.根据权利要求11或12所述的多点控制单元(1、10)，配置为：利用多媒体自计时速率适配SCReAM拥塞控制的反馈元素。

18.根据权利要求11或12所述的多点控制单元(1、10)，其中，所接收的接收者反馈报告包括对丢失分组的累积数量进行计数的反馈元素N_loss，以及所述多点控制单元(1、10)被配置为：每当接收到的反馈报告指示反馈元素N_loss增大时增大计数器(C1)，并且基于所述计数器(Cl)值在发送者反馈报告中包括反馈元素N_loss。

19.根据权利要求11或12所述的多点控制单元(1、10)，配置为在第一发送者和第二发送者之间切换，并且被配置为提供具有延迟的相应发送者反馈报告，所述延迟是基于在所述多点控制单元与所述接收部(4a、4b、4c)中的一个或多个之间的往返行程延迟计算的。