标签: 群组通信

六、方法的实施

6.1 GCSVA系统的体系结构

        所提出方法的实现需要每个参与者主机的管理组件以及对其交互的协议支持。 图3显示了参与者主机上Gcsva的架构。 由于视频和音频流需要的服务与发送组通信数据所需的服务非常不同，因此我们将架构分为两部分：数据处理部分和信令部分。 它们由两种不同的协议支持：用于传输音频和视频流的MCM-TP（多播连续媒体传输协议），以及用于群组通信的GCP（组通信协议）。 两种协议都直接通过ATM适配层5（AALS）运行。 成的。 视频管理器还包含输出过滤器，用于根据系统配置QoS *调整输出视频流。通过MCM-TP执行从一个发送者到另一个参与者的音频和视频数据的传输。它提供连接定向的不可靠多播服务。 MCM-TP层包含输入滤波器，它可以将发声器的输入流从FRs *缩小到F R s /，并且分别从FRL *到FR L /缩小听众的输入流。

        信令部分负责组和QoS管理。它由QoS Manager，Monitor和Group Management Module组成。 QoS管理器计算系统配置QoS *的QoS参数，以及如上所述的本地过滤参数FRs /和FRL /。监视器支持QoS管理器的工作。监视器观察当前的CPU负载。它定期将此信息发送到QoS管理器以计算过滤器参数。当参与者改变或参与者加入或离开会议时，组管理模块会触发重新计算QoS参数。 ATM级的QoS管理组织如下。在连接建立期间确定ATM连接的QoS参数。之后不能改变它们。在所有参与者之间以最佳质量传输流的网络资源的预留将浪费网络资源并导致更高的成本。由于在Gcsva中，所有参与者并不总是以尽可能高的质量发送，因此在ATM级别的连接建立期间仅需要QoS参数的平均质量。

        集团管理模块监督集团的状态。 他们交换关于组的组成（参与者的加入和离开）的消息以及用于控制组的消息（进入说话者队列，从说话者队列中移除，交换QoS要求）。 组管理模块应该使用户免于任何QoS管理，因为用户通常不具备对QoS参数及其之间关系的深入了解。

        对于组管理模块之间的通信，设计了组播协议GCP。 它确保了参与者站点的QoS参数和组管理信息的一致性。 GCP是我们分散的集团管理的基础。

6.2集团通信协议（GCP）

        GCP协议是在仔细分析并部分调整现有多播协议和组通信方法的想法之后设计的。 为了确保组管理模块中组管理数据的一致性，支持协议必须满足以下要求：

        可靠性

        与视频数据的传输相反，其中一些帧可能丢失，失真或丢弃，因此必须能够交换控制数据。 消息可能不会失真，丢失或无序。

        原子性

        消息必须传递给所有参与者或者不传递给所有参与者。

        订购交货

        如果订单影响结果，则不同发件人的消息必须以相同的顺序传递给不同的接收者。 根据应用的不同，可能需要不同级别的订购。

        动态加入和离开

        应允许参与者随时加入并离开会议。

        GCP满足这个要求。它提供可靠的、原子的、有序的交付服务。

        为了提供有序的传递，GCP应用类似于基于令牌的机制。 所有参与者形成令牌旋转的逻辑环。 只允许令牌持有者发送。 所有参与者都必须承认这些PDU的接收。 超时后最多三次重传未确认的PDU。 收到所有确认后转发令牌。 必须同时接收令牌的接收。 如果没有要发送的消息，则会立即转发令牌。

        如果在一段时间后有任何未完成的确认，则会触发所谓的强制休假机制。 它从组中删除这些参与者（即他们必须离开会议）。 因此可以保证原子性的实现，因为剩下的参与者被重新感知到PDU。令牌丢失和重复的处理方式类似。

        由于在发送方和接收方之间仅发生一次消息交换（数据PDU传送和相关的知识），因此两个令牌移动之间的消息的交叉和超越是不可能的。 所有参与者都以相同的顺序接收所有消息。 这确保了完全有序的交付。

        旋转令牌机制进一步保证了所有参与者之间的公平性。 即使不必传输数据，令牌的移位也支持早期检测参与者的失败。

五、QOS管理

        此节将描述如何计算QoS参数以支持上面介绍的缩放方案。 为了使决策过程尽可能简单，仅考虑QoS参数帧速率和像素分辨率。 以下决定适用于说话者和听众之间的关系。 记录扬声器的视频流并以更高的帧速率和更高的像素分辨率发送。 其他参与者以较低的帧速率和像素分辨率发送，因此当前认为这些参数对于所有听众来说是相等的。

5.1系统参数的计算

        Gcsva的会议相继成立，即新的参与者一个接一个地加入会议。 随着每个新加入，包括新的参与者在内的所有参与者通过QoS请求分组交换其QoS参数（帧速率和像素分辨率）。 QoS参数由监视器提供，监视器观察CPU负载并获得QoS值。 假设主机上没有运行其他应用程序，即参与者仅将计算机用于视频会议。

        每个参与者指示其可以接收扬声器的视频流和其他听众的视频流的质量。 QoS管理已知参与者的数量。 每个参与者的QoS-Request-包包含以下值：

        其中FR和FS表示所需的帧速率和扬声器视频流的帧大小（像素分辨率，像素x像素）。 FRL是听众视频流的所需帧速率，FSL是相关像素分辨率。

        在交换QoS-Request-packets之后，计算整个系统的QoS参数。 如第4节所述，它们与最强大的参与者有关。由于帧速率和帧大小可能不同，因此必须找到一种措施来比较参与者的QoS要求。

        在视频会议期间，通常仅传送谈话者的头肩透视图像。 例如，与电影不同，连续帧中只有少数变化。 因此，在下面的讨论中可以忽略帧间编码对传输速率的影响。 因此，视频流的传输速率由帧速率和像素分辨率决定。 依赖关系是线性的（参见图2）。

        为了表达说话者拥有最高优先级，我们引入了权重。 与听众相比，扬声器被赋予双倍值。 所有听众都拥有相同的体重。 所有参与者的权重之和为1.然后，n为参与者数量，Wx为参与者x的权重

        WS是说话者和WL听众的权重。

        在下文中，我们确定值C，其被用作比较参与者的QoS要求的度量。 参与者i的QoS要求是

        如果未输出本地视频流，则必须引入（n-2）而不是（n-1）。

        与发送相关的系统QoS配置QoS *由参与者k的QoS要求Ck确定，其中计算所有Ci的最大Cmax：

         如果新参与者加入会议或参与者离开会议，则必须重新计算QoS *。

        在更换扬声器之后，新扬声器必须使用新的QoS参数QoS *发送包括前一个扬声器在内的所有其他参与者的听众参数QOSL *。 所有参与者都必须接受这一点在接收视频流时更改帐户。

5.2 计算局部QoS参数

        收到有效的系统参数QoS * =（QoSS *，QOSL *）（（FRs *，FSs *），（FRL *，FSL *））用于发送视频流，每个参与者必须自己确定它是如何的 必须过滤传入的视频流。 到达（已记录的）视频流的帧大小只能通过部分解压缩来改变。 这需要额外的计算工作，这应该在接收器站点避免。 因此，我们决定所有参与者分别接收和处理系统帧大小为FSs *和FSL *的输入视频流。 因此缩放减少了调整输入滤波器中的帧速率。 设FR，即参与者i可以接受的扬声器的视频流的帧速率然后通过以下公式基于帧速率和帧大小之间的线性相关性（参见图1）来计算减少：

        过滤器必须缩小传入扬声器流的帧速率，从FRs *到FRs /。 相同的缩放原理应用于收听者FRL /的视频流的帧速率。

        必须分别针对组或扬声器的组成的每次更改重新计算这些参数。

四、视频流的动态可扩展性

        在视频会议系统中，每个参与者接收来自所有其他参与者的视频流。它必须在这些流被释放出来之前先对它们进行减压。多个视频流同时解压会使终端系统过载。缩放视频流可以减少解压开销。这可以在不同的点上完成，通过这些点可以应用不同的方法:分层的、受发送者限制的和受接收者限制的。根据路径末端接收者的要求，在网络节点上进行分层计算。由于我们的系统是直接运行在ATM上的，这种方法是不可行的。

        在发送者限制方法中，发送者调整视频流的方式使所有参与者包括较弱的参与者都能接收视频流。该方法适用于群组信道的概念。组通道为整个组定义了一个QoS级别，将会议的总带宽限制为组中最慢工作站的性能。当参与者的性能几乎相同时，该方法很有效，但是当会议中包含了非常不同的性能参数时，它会极大地限制强大机器上的传输质量。

        受接收者限制的方法假设网络带宽不是瓶颈。 主机可以以尽可能高的性能发送。 接收器根据输入流的数量及其当前负载来缩小它们。 然而，该方法取决于所应用的压缩方法。 缩放也可能使功能较弱的主机过载。

        在我们的方法中，我们应用了一个组合方案。会议的总带宽与容量最大的参与者有关。 如上所述，在所有参与者之间划分带宽，使得当前的发言者具有更大的份额。 参与者的视频流根据其在总带宽上的配额发送。如有需要，视频流由输出滤波器调整。接收器必须根据性能参数对流进行过滤。扬声器流以尽可能高的服务质量播出，即更高的帧速率和更高的像素分辨率。它比听众的视频流过滤更少。在过载的情况下，仅可以显示听众的静止图像。

        由于参与者的动态加入和离开，要解压缩的视频流的数量可能会在会议期间发生变化。 因此，系统必须动态地调整过滤方案。 当参与者加入或离开会议时，在参与者之间重新协商总带宽及其分裂。

        图1给出了特定缩放情况的示例。 我们假设参与者c具有最高容量。 它能够处理每秒60帧（F / s）。 这是总带宽。 发言者（参与者b）获得20 Fls的配额，其他参与者（包括参与者c）可以10 F / s发送。 参与者a必须从60 Fls过滤到40 F / s。 这取决于参与者如何在单个视频流之间共享这40个Fls。 例如，扬声器可以用20 Fls播放，其他3个参与者获得6 F / s。 参与者d仅显示发言者。 对于其他参与者，它会显示静止图像。

        应用的缩放方法取决于缩放目的和应用的压缩技术。 存在不同的可能性，诸如时间缩放，空间缩放，频率缩放，振幅缩放和颜色空间缩放。 我们的缩放方法的目标是减少解压缩工作，从而减少视频流的接收器站点处的计算开销。 因此，需要大量计算的缩放方法是不合适的。 我们在输出滤波器中使用时间和空间缩放（参见图3），用于发送端站点的缩放，而在接收端站点的输入滤波器中只使用时间缩放。 对于时间缩放，采用帧丢弃滤波器。 使用的压缩方法是CellB。 我们首先为MPEGI流实现了过滤器，但是实现的性能太差了。

三、地面控制

        在会议中，通常只有一位发言者在特定的时间段内发言。其他参与者听它的演讲。Gcsva的QoS管理就是基于这一原则。它假设存在一个特定的扬声器，其视频和音频流处理特别小心。这避免了对扬声器进行大规模识别的方法，因为当前的扬声器是已知的。发言权的分配是通过一个联合发言者队列来完成的。队伍的头部是发言者。其他参与者可以在短时间内打断发言者的提问或发言。他们的音频流与扬声器的音频流合并。但是，这不会改变扬声器和任何QoS参数。中断选项可以关闭。还有其他方法可以尽可能自然地模仿会议中的社交行为。在Gcsva发展的当前状态下，我们不考虑任何精细的发言权控制机制，因为我们主要关注分布式组和QoS管理方法的细化。这计划用于后期的开发阶段。

        扬声器队列显示在每个参与者的屏幕上。 队列可以由参与者操纵。 例如，当讨论使其注释不必要时，它可以随时将自己从队列中删除。 每个参与者屏幕上的队列一致性由分布式组管理确保。

        由于发言者在这个会议场景中扮演着重要的角色，因此当前发言者的视频流传输的服务质量要高于其他参与者(听众)。它的视频流比听者的视频流有更大的带宽配额。在接收端，只有当所有侦听器的流都缩小了时，才会对其进行过滤。此外，扬声器的窗口大小大于侦听器的窗口大小(使用相同的窗口大小)。在尽力而为的基础上以较低的QoS处理侦听器的视频流。这些视频流首先在接收端缩小，如果需要，直到静止图像。由于带宽要求低，所有参与者的音频流都以保证的QoS传输。

（二）多方会议系统的QOS管理要求

        大多数现有的会议系统几乎不支持为不同的视频流和音频流灵活地分配QoS参数以控制带宽分配。如果参与者的表现非常不同，这一点尤其重要。应该实现具有不同性能参数的endsystems能够以可接受的服务质量处理多媒体流。它们必须防止过载。同时，避免了网络资源的浪费。因此，视频会议系统应该提供根据参与者的主机和网络的性能可能性动态缩小多媒体流的手段。

        在此提出，源提供具有3种不同质量的多媒体流用于参数帧速率，颜色空间和像素分辨率。 接收器可以根据他们的期望和性能参数选择适当的质量。这种方法对于按需服务或远程教学是有用的，其中通常一个源发送给几个接收器。 在会议系统中，每个发送者必须接受并实时发送几个不同质量的流，这会使网络和参与者过载。

        一种可能的方法是在中描述的接收器驱动的分层多播。 每个源发送包含不同QoS级别的流。 接收者选择他们想要接受的频道，从而确定接收流的质量。 此外，接收器可以为发送者分配权重。 这些权重（优先级）定期公布。 因此，更重要的来源（从接收者的角度来看）可以区别于不太重要的来源。 根据它们的权重，源可以在不同的网络信道上发送其视频流（信号层）的不同级别。 但是，对于这种方法，应用了特定的视频压缩方法。

        一种可能的方法是接收驱动的分层组播。每个源发送一个包含不同QoS级别的流。接收者选择他们想要接受的频道，从而决定接收的流的质量。此外，接收者可以为发送者分配一个权重。这些权重(优先级)定期公布。因此，更重要的消息源(从接收者的角度来看)可以从不那么重要的消息源中分离出来。根据其权重，源可以通过不同的网络通道传输不同级别的视频流(信号层)。对于这种方法，应用了一种特定的视频压缩方法。

        在纯视频会议系统中，使用所谓的组信道概念。 组通道为每个参与者分配带宽配额，从而为发言者和听众定义不同的配额。 要以最低性能主机未过载的方式选择要传输的所有视频流的总带宽。 因此，保护接收器免受过载并节省网络资源。 这种方法的不足之处在于，在参与者的性能参数变化很大的情况下，服务质量由最弱的主机确定。 对于能够处理高质量视频的强大工作站，这是不能令人满意的。 这里需要更灵活的可扩展性方法。

        另一个重要的设计决策涉及为会议系统选择的管理方案。大多数现有的视频会议系统使用集中式服务器进行组和QoS管理，就像系统中的系统一样。服务器控制整个会议。通常，发起会议的参与者将接管服务器角色。当它离开会议时，会议大多结束。集中式解决方案易于实施，因为所有管理功能都集中在一个系统中。如果应用复杂的控制算法，例如将传输的视频流适应于接收端系统的当前性能情况(负载)，尤其如此。集中式方法的主要缺点是服务器可能出现故障，从而立即终止会议。此外，当许多客户端同时处理服务器时，服务器可能会成为性能瓶颈。另一个问题是当持有该功能的参与者离开会议时，服务器功能的转移，但不希望终止会议。为了避免这些问题，分布式管理方法似乎更适合我们。当在广域网上建立视频会议服务作为互联网时，分布式方法是不可避免的。在分布式组中，还应用了管理方法，但它不包括扩展机制。

（一）概述及动机

        分布式交互式多媒体应用的QoS管理目前主要基于集中式方法，其中单个组服务器管理所有参与者的QoS要求。组服务器处理起来比较简单，但由于服务器故障或性能瓶颈，它们可能成为系统的弱点。为了避免这些问题并更好地支持终端系统中的应用程序，应用程序级别的分布式QoS管理似乎更合适。于是提出了这种分布式QoS管理。它是为多方视频会议系统GcsvA设计和实现的。我们的方法的基本思想包括分散计算和分配扬声器和听众的带宽配额，从而将最强大的参与者的接收能力作为衡量标准。功能较弱的接收器通过根据其性能参数进行过滤来缩小传入视频流的数据速率。通过专用的组通信协议确保终端系统中QoS数据的一致性，该协议提供可靠的，原子的和有序的递送服务。

        越来越多地使用分布式交互式多媒体应用作为CSCW应用（计算机支持的协同工作）的联合编辑或视频会议，需要适当的机制来管理和监督服务质量（QoS）要求。 大多数现有的视频会议系统不为QoS和带宽管理提供广泛的系统支持。 特别是，它们不支持与会议参与者的数量和所使用的终端系统的性能相关的视频流的缩放。用户常常被迫通过“试错”来确定最佳工作提供的可接受的服务质量。

        在多方会议系统中，多媒体流不仅从一个或几个选定的源流向不同的接收者，而且从每个协商参与者流向所有其他参与者，即每个参与者必须同时处理几个到达的流。与通常在硬件中执行的视频流压缩相反，解压缩在软件中实现，这对CPU造成了相当大的负担。几个视频流的同时解压缩可能导致终端系统的性能过载。因此，QoS管理必须考虑到终端系统的性能能力。在所有通信伙伴和不同流的网络之间协商传统意义上的QoS参数变得过于复杂。在一般情况下，当改变协商或网络参数的组成时，它必须被重复。为了达到这个目的，它似乎更有用，而不是应用通用的QoS框架来设计专用应用程序的专用解决方案，而这些应用程序恰好满足它们的需求。

        在此篇中，提出了一种用于多方多媒体会议系统的分布式QoS管理的方法。 该方法已经为视频会议系统Gcsva（ATM上的视频会议中的组通信和可扩展性）设计和实施。 Gcsva专为支持CSCW应用和远程教学而设计，尤其适用于远程研讨会。 它针对的是小型封闭式讨论组。 Gcsva的特点是分布式组织原则。 它直接在ATM上运行。