多方视频会议系统的分布式QoS管理(六)

多方视频会议系统的分布式QoS管理(六)

六、方法的实施

6.1 GCSVA系统的体系结构

        所提出方法的实现需要每个参与者主机的管理组件以及对其交互的协议支持。 图3显示了参与者主机上Gcsva的架构。 由于视频和音频流需要的服务与发送组通信数据所需的服务非常不同,因此我们将架构分为两部分:数据处理部分和信令部分。 它们由两种不同的协议支持:用于传输音频和视频流的MCM-TP(多播连续媒体传输协议),以及用于群组通信的GCP(组通信协议)。 两种协议都直接通过ATM适配层5(AALS)运行。

enter image description here

        数据处理部分包括处理传入和传出的视频和音频流的所有任务。这是在视频和音频管理器中完成的。 视频管理器还包含输出过滤器,用于根据系统配置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管理

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

5.1系统参数的计算

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

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

enter image description here

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

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

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

enter image description here

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

enter image description here

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

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

enter image description here

        如果未输出本地视频流,则必须引入(n-2)而不是(n-1)。

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

enter image description here

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

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

5.2 计算局部QoS参数

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

enter image description here

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

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

我们应该考虑软电话客户端还是手机?

对于在办公室以外工作的员工,软电话客户端或手机是最佳选择吗?电话专家Jon Arnold解释了软电话和移动电话之间的区别,以及使用软电话客户端的好处。

我公司的很多人只在兼职办公室工作,因此我们正在考虑购买软电话,以便他们可以随身携带手机。购买软电话有什么好处,而不仅仅是让这些员工使用手机?这是一个很好的问题,有些事情需要澄清以提供有用的回应。首先,类似SparkleComm这样的软电话不是像桌面电话那样的物理设备。其次,它不是您作为独立产品购买的东西。

enter image description here

您需要知道的第一件事是,顾名思义,软电话是一种软件应用程序。简而言之,此应用程序允许您使用宽带连接端点,就像使用桌面电话一样。最初,软件是为PC开发的,但随着移动宽带的出现,它们现在可以部署在智能手机或平板电脑上。例如劳格科技的SparkleComm

在所有情况下,我们的想法是将这些端点作为桌面电话的扩展。除了拨打和接听电话外,还可以在这些环境中使用电话系统的功能集。考虑呼叫者ID,呼叫转移,会议和保持呼叫者等功能。虽然有许多免费的网络电话选项,如Skype和Google Talk,但它们并不依赖于您的电话系统,因此这些功能无法使用。此外,对于日常商业用途,通话质量不够好或不够可靠。

市场上有许多软电话客户端,SparkleComm是最著名的例子。许多产品只是将软电话客户端的成本与其他通信应用程序捆绑在一起作为月度服务计划。因此,关于成本没有简单的答案。要获得高质量的软电话体验,您通常需要投资外围设备 - 即耳机和扬声器。

虽然使用移动设备对于商务电话来说很方便,但它们通常不与您的电话系统集成,也不会向客户投射专业图像。SparkleComm软电话解决了这个问题,并提供了更丰富的功能集,使您的员工无论身在何处都能提高工作效率。

多方视频会议系统的分布式QoS管理(四)

多方视频会议系统的分布式QoS管理(四)

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

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

enter image description here

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

多方视频会议系统的分布式QoS管理(三)

多方视频会议系统的分布式QoS管理(三)

三、地面控制

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

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

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