第5章多媒体通信中的关键技术资料.docx
- 文档编号:11360586
- 上传时间:2023-05-31
- 格式:DOCX
- 页数:57
- 大小:365.92KB
第5章多媒体通信中的关键技术资料.docx
《第5章多媒体通信中的关键技术资料.docx》由会员分享,可在线阅读,更多相关《第5章多媒体通信中的关键技术资料.docx(57页珍藏版)》请在冰点文库上搜索。
第5章多媒体通信中的关键技术资料
第5章多媒体通信中的关键技术
5.1多媒体通信中的关键问题
在多媒体通信中,不同的业务有不同的QoS要求,如比特率、传输延时与延时抖动、误码率等。
此外,还有实时性、同步性及多点通信等需求。
而网络故障、网络拥塞、网络瓶颈点和缓冲区容量等在一定程度上会影响多媒体通信系统的性能。
例如,实时音频和视频可在带宽足够宽的条件下正常工作,信息包的时延和抖动都非常小。
但当遇到拥挤链路时,声音和图像的质量有可能下降到无法接受的程度。
因此,多媒体通信应该解决包括提高网络带宽、减少时延、减少抖动、改善服务质量等问题。
此外,多媒体通信在遵守通信基本原则的基础上,还需要考虑多媒体信息带来的新问题:
多媒体框架结构、QoS、同步机制以及多媒体信源模型和数据库管理等技术。
5.2多媒体通信框架
随着多媒体技术的成熟,通信已从过去单纯的传送声音发展到文字、视频、图像等多种媒体信息,由此产生了多种典型的多媒体应用模式,如视频点播(VOD)、远程教学、计算机辅助协同、视频会议等,依托互联网的多媒体应用也越来越多。
此外,从用户、系统和网络的不同角度来看,多媒体通信系统的需求也各不相同。
多媒体通信需要提供多种类型、不同QoS的通信服务。
因此,对多媒体框架结构模型的研究也至关重要。
5.2.1基于服务质量的多媒体通信系统框架结构
多媒体通信系统的服务质量不仅要考虑到通信网络的支持,而且要对端系统提出服务质量的要求。
基于服务质量的多媒体通信系统框架分为应用层、应用支撑平台层、协调层、网络层和多媒体设备层,以及QoS控制与管理部分,其通信系统结构模型如图5-1所示。
1.应用层
应用层的主要模块包括用户界面、应用构件和信息内容,其功能是完成用户提出的应用需求,包括多媒体会议、多媒体邮件、多媒体信息查询、VOD播放、交互电视、文件传输等。
2.应用支持平台层
应用支持平台层包含媒体代理和控制构件,不同的媒体(音频、视频、共享数据等)和不同的控制功能(会话控制、QoS控制、安全控制等)都有特定的代理构件,可根据需求进行组合。
该层采用主动服务和应用自适应相结合的方式来面向新应用,如果下面的多媒体网络提供可编程服务,则应用可以选择主动服务,否则只能采用自适应网络所提供的服务。
此外,该层次还将应用的QoS请求抽象映射到可编程网络,将下层网络提供的服务抽象提交给应用层,从而使多媒体应用与底层使用何种网络进行传输无关。
这样就给应用程序提供了一系列的透明性,即应用层对于位置、网络通信协议是透明的。
此外,应用支撑平台层还应该提供多种分布式多媒体应用设计模型,以满足应用的多样性。
3.协调层
多媒体通信的复杂性主要来源于连续媒体数据。
在处理连续媒体数据时,不仅需要保持统一媒体内的时间连续性,而且常常需要维持不同媒体间的同步关系。
协调层支持这种媒体间同步关系的实现,提供实时同步机制以控制时间定序和多媒体交互作用之间的准确定时。
同时,协调层还需要提供对分布式多媒体应用所需的多方同步的支持。
4.网络层
网络层的功能是向网络层用户提供通信服务,该层并不关心传输数据所表示的内容。
对于每个通信会话,端到端的通信特性由QoS参数决定。
而这些参数由网络层用户传递给网络层,即从应用支撑平台层、协同层或者应用层传递而来。
网络层提供了一系列网络服务接口以完成对网络的访问和服务。
5.多媒体设备层
多媒体设备层提供了应用程序或应用支撑平台中可使用的函数和过程,从而控制多媒体设备。
多媒体设备服务接口提供了控制这些设备的通用接口,以及控制由这些设备产生或接收的信息流接口。
6.QOS控制与管理
服务质量允许用户指定所需要的服务质量级别,在不同层的接口中,这个服务质量级别的含义是不同的,各个层次所采用的服务质量参数也不完全相同。
用户QoS参数指明了用户希望听到/看到的服务质量(如电话质量的音频、电视质量的视频)。
应用层QoS参数描述了应用服务的请求,以及可能为媒体质量或面向应用的端到端传输服务所能提供的等级说明(如端到端的延迟界限),它们可以由用户QoS参数映射过来或直接来自于用户的QoS参数说明。
系统层的QoS参数描述了应用层QoS定义的对通信服务和操作系统服务的请求。
操作系统服务要求的资源(处理时间、辅助存储器、缓存区)被应用层和网络层任务用于解决与媒体有关的输入/输出以及发送/接收等问题。
5.2.2基于TCP/IP的多媒体通信模型
多媒体通信中的媒体数据除了具有实时性、等时性等基本特点外,还需要保证各种媒体间的同步关系。
因此,多媒体通信对最大时延、延时抖动等QoS参数都有严格要求。
下面介绍的模型通过对互联网的传输控制协议/互联协议(TransmissionControl Protocol/Internet Protocol,TCP/IP)参考模型的增强来提高多媒体通信的服务质量。
图5-2基于TCP/IP的多媒体通信系统结构模型
为了实现互联网多媒体通信的QoS保证,在TCP/IP参考模型的传输层和应用层之间增加一个通信控制层,以实现对多媒体通信的支持。
通信控制层分为三个子层,如图5-2所示。
传输层采用的协议为用户数据报协议(UserDataProtocol,UDP)。
1.数据获取子层
数据获取子层的功能包括以下两点:
(1)从应用层获取各种媒体数据,并按照其获取时间排队,然后提交给媒体同步子层;
(2)分解由媒体同步子层获取的多媒体数据,并根据同步信息,将不同的媒体信息提交给相应的播放设备。
2.媒体同步子层
媒体同步子层的功能包括:
(1)将数据获取子层获得的各种媒体信息合成为多媒体信息,交给通信子层发送;
(2)分解通信子层接收的信息包,提取相应的媒体信息和同步信息,然后提交给数据获取子层;
(3)实现多媒体同步失调监测和强制同步。
3.通信子层
完成多媒体信息的发送和接收。
5.2.3异构环境下的多媒体通信模型
下一代网络(NGN)以软交换为核心,采用开放、标准体系结构,能够提供话音、视频、数据等多媒体综合业务,是未来网络发展的方向。
对未来网络的研究离不开当前网络的现状以及技术条件。
目前,由于多种接入技术并存,各标准之间的竞争愈演愈烈,因此很难在短时间内统一标准;同时,多种网络并存也能解决不同用户以及不同业务的需求,如不同的用户业务速率和响应速度以及质量需求等。
而如何充分利用现有的网络资源,实现资源共享、协同工作、降低信息使用成本也成为业界备受关注的问题。
异构环境下的多媒体通信模型应融入到NGN整体框架的研究和发展中,NGN是一个基于交换技术、分组方式、开放结构的融合网络。
在NGN中,软交换起到业务控制节点的作用,并提供媒体网关间或与IP端点间的智能融合,从而实现异构环境下的多媒体通信和服务。
5.3多媒体通信中的恒、变比特率传输
多媒体传输可分为恒比特率传输和变比特率传输两种方式。
电路交换网络的信道性能、信息速率是恒定的,所以采用恒比特率传输,即多媒体信源按给定比特率提供码流;分组交换网络的信道特性是统计复用的,因而能够支持变比特率传输,即多媒体信源按给定目标比特率要求提供码流,码流速率可根据应用需求和信道条件发生变化,从而获得最优质量。
实际应用中,不同的应用经编码后所产生的比特率通常会有很大差异,如果不经过缓存器平滑和速率控制,码流必然是变速率的。
如果信道允许理想的变比特率传输,则可以在编码过程中保持量化阶不变。
当随着图像活动性变化而产生的变比特率码流直接进入信道时,由于没有经过缓存器的平滑,信噪比将会大大提高。
恒比特率和变比特率传输的比较:
(1)速率控制方面:
采用恒比特率传输时,为了适应恒定速率信道的要求,在编码器中必须进行速率控制,而速率控制往往是以牺牲多媒体数据的质量为代价的;采用变比特率传输时,编码器则不必进行非常严格的速率控制,速率控制的代价也比恒比特率传输时要小。
(2)比特率的分配方面:
在相同多媒体数据质量的情况下,采用恒比特率传输产生的平均速率约为采用变比特率传输时的50%。
5.3.1恒比特率传输
由于编码器所产生的数据流速率是变化的,当多媒体信息按恒比特率传输时,为了适应恒定速率信道的要求,在编码器和信道之间需要设置一个缓存器。
当数据流的速率高于信道的传输速率时,缓存器会越来越满;当数据流的速率低于信道速率时,缓存器会越来越空。
为了防止缓存器溢出或变空,需要对编码压缩数据流的速率进行控制,如通过改变量化器量化阶的大小方式来解决。
如果量化阶加大,则码率下降,数据质量也会因此下降。
速率控制问题就是在尽可能地保证数据质量稳定的条件下,使压缩码流的速率适应恒定信道速率的要求。
常用的恒定比特率控制方案主要有以下三种。
1.SM3速率控制
SM3(SimulationModel3)为压缩编码标准MPEG-1的仿真模型,它提供了一种简单的速率控制方法,包括目标比特分配和码率调整两个过程。
(1)目标比特分配:
根据多媒体数据编码所产生的码流平均速率应该与信道速率相匹配的原则,为每帧数据预先规定编码的比特数。
(2)码率调整:
在每一帧的编码过程中,通过调整量化阶的大小,使该帧编码实际产生的比特数接近其预分配值。
在每一帧中,帧目标比特数平均地分配给该帧中的所有各块。
然后,根据缓存器的充满程度来改变当前量化阶的大小。
当缓存器数据增多时,即实际编码比特数超过预定值时,增大量化阶,从而使码率下降。
通过以上两个步骤,可以基本达到使编码器输出码流与信道速率相匹配的目的。
2.TM5速率控制
TM5(TestModel5)为压缩编码标准MPEG-2测试模型,如图5-3所示。
其原理是根据虚拟缓冲区饱和度情况调节量化因子,尽量降低目标分配比特数和实际使用比特数之间的偏差,从而达到控制码率的目的。
TM5码率控制过程可分为3个步骤:
图5-3TM5速率控制图
(1)目标比特分配:
在编码前,根据预测的图像复杂度,为不同编码类型帧分配一个目标比特数;
(2)码率控制:
根据当前帧目标比特数和虚拟缓冲区饱和程度,计算每个宏块量化参数的参考值;
(3)自适应量化:
根据当前宏块的空间活动性,调节量化参考值,直至得到最终的量化阶。
在TM5中,图像复杂度是根据前一个相同编码类型帧预测得到的,一旦序列中发生场景切换,则两帧之间的相关性就会降低,复杂度将偏离实际情况,导致目标比特数分配不合理,最终引起图像质量恶化。
场景切换后,由于前一帧平均活动性不能准确反映当前帧活动性状况,使得码率控制过程的第3步失效,造成图像质量不稳定。
TM5为3种类型编码帧分别设立了虚拟缓冲区,在场景变化较小或图像复杂度较小,且编码时间较短时,TM5能够基本保证缓冲区的约束要求和图像质量的相对稳定。
但当图像复杂度变化较大,且编码时间较长时,由于不同的缓冲区之间控制不同步,就有可能导致缓冲区溢出。
3.基于DCT域复杂度计算的速率控制
视频压缩码流MPEG-2由量化后的离散余弦变换(DCT)系数和运动信息编码后复合形成。
通常,DCT系数编码比特数占整个码流的绝大部分,因而用DCT域信息反映编码复杂度是非常合理的。
基于DCT域复杂度计算的速率控制方法的控制流程如图5-4所示。
(1)帧复杂度计算和目标比特数分配:
首先计算帧复杂度,再根据帧复杂度和编码类型(I、P、B)分配不同的目标比特数;
(2)根据虚拟缓冲区饱和度及所分配目标比特数计算量化参数的参考值:
与TM5不同的是,虚拟缓冲区不再按编码帧类型设置,而是使用同一个虚拟缓冲区,从而保证了虚拟缓冲区的一致性;
(3)自适应量化:
根据宏块复杂度调节量化阶的大小;
(4)更新:
在完成一帧编码后,更新虚拟缓冲区状态及填充比特。
图5-4基于DCT域复杂度的速率控制框图
5.3.2变比特率传输
由于分组交换网络在多媒体通信方面表现出极强的竞争力,使得变比特率传输得到了越来越广泛的应用。
为了支持变比特率传输业务,网络需要一种反馈机制以通知信源端可以发送的数据量,即网络状态由资源管理(ResourceManagement,RM)分组带回给源节点,源节点根据反馈信息得知网络的状态,从而相应地增大或减少发送速率,防止网络发生拥塞,保证网络正常运行和各用户的服务质量。
目前两种主要的控制方法为基于速率的流量控制和基于凭证的流量控制。
这两种控制方法都为闭环控制,其工作原理是通过反馈网络中的拥塞状况动态地调整发送速率,以提高剩余带宽的利用率并及时消除网络拥塞。
漏桶法是比较常用的基于速率的流控方法。
使用该方法时,发送方将数据输入到桶中,随后在网络上按一定速率发送数据,直到数据逐渐排出桶底。
数据实际进入网络的速率由位于桶底的调节器控制。
令牌桶法是比较常用的基于凭证的流控方法。
在这种方法中,漏桶中装的不是数据,而是令牌。
每隔一个固定的时间间隔就有一个令牌产生并装入漏桶,每个数据包必须取走一个令牌才能进入网络。
若主机在某段时间内空闲(不产生数据),桶中的令牌就会增多。
当令牌数超过桶的容积时,多余的令牌将被丢弃;若主机在某段时间内产生突发性数据,这些数据将会消耗集存在桶中的令牌,但连续发送的数据包的个数不会超过桶的容积。
漏桶法是将输出流的速率严格控制在平均速率中,而令牌桶法则允许输出流有一定的突发性,突发长度由令牌桶的大小确定。
因此,如何将基于速率的流量控制和基于凭证的流量控制结合起来将显得十分重要。
5.4服务质量
随着高速网络技术和多媒体技术的飞速发展,人们越来越多地提出了包括多媒体通信在内的综合服务要求。
在高速网络中按照用户的要求提供QoS控制已成为普遍的要求,多媒体信息传输与管理中的QoS控制技术是下一代网络的核心技术之一。
多媒体通信的QoS是多媒体通信能够大规模发展和应用的前提,多媒体通信的QoS问题面临很多新的挑战,如连续媒体的同步问题、端到端的QoS问题、QoS的层次化自适应问题等。
5.4.1QoS概述
QoS具有多种等价或互补的定义形式。
互联网通信协议文档(RequestForComments,RFC)2386中描述为:
QoS是网络在传输数据流时要求满足的一系列服务请求,具体可以量化为带宽、延迟、延迟抖动、丢失率、吞吐量等性能指标。
此处的服务是指数据包(流)经过若干网络节点所接受的传输服务。
QoS反映了网络元素(应用程序、主机或路由器)在保证信息传输和满足服务要求方面的能力。
另一种描述为:
QoS是指发送和接收信息的用户之间以及用户与传输信息的综合服务网络之间关于信息传输的质量约定,包括用户的要求和网络服务提供者的行为两个方面,是用户与服务提供者两方面主客观标准的统一。
其中,用户要求是指用户在网络上进行多媒体通信时所要求的服务类型以及相应的传输性能和质量等。
网络服务提供者的行为则指在网络中针对某一类服务所能提供和达到的性能与质量。
QoS控制的目标是为互联网应用提供服务区分和性能保证。
服务区分是指根据不同应用的需求为用户提供不同的服务;性能保证则要解决诸如带宽、丢失、延迟、延迟抖动等性能指标的保证问题。
为了适应不同的应用对QoS的不同需求,系统需提供多种不同的QoS服务,主要分为三类。
1.确定型QoS
确保QoS要求,不允许对QoS要求有任何违背,否则可能会造成严重后果。
这类服务一般用于强实时、高可靠性应用。
例如,在远程医疗系统中,X光照片数据必须采用实时无差错的传输。
互联网综合服务中的保证服务和区分服务中的快速转发服务均属于确定性的QoS。
2.统计型QoS
允许对QoS要求有一定的违背,适合于准实时应用。
例如,对于网络化多媒体信息点播服务中的影片点播来说,用户通常可以容忍一定数量误比特帧的丢失。
3.尽力而为型QoS
不提供任何QoS保证,网络性能随着负载的增加而明显下降。
由于带宽的限制,广域网中的网络化多媒体服务大多属于这类服务。
不同的多媒体应用具有不同的QoS描述方法,包括定量(如吞吐量、容错率、传输延时和延迟抖动等)和定性描述(如服务等级等)。
另外,可以从不同层次描述QoS,如基于应用层的帧率和同步质量,基于传输层的流内和流间同步容限,基于网络层的比特率、差错率和延迟等。
下面介绍一种较为典型的QoS参数集定义:
QoS={吞吐量,容错率,传输延时,延迟抖动}
吞吐量:
指有效的网络带宽,定义为物理链路的传输速率减去各种传输开销,如物理传输开销以及网络冲突、瓶颈、拥塞和差错等开销,反映了网络的最大极限容量。
网络的吞吐量是随时间变化而变化的,影响吞吐量的因素主要有网络故障、网络拥塞、瓶颈、缓冲区容量和流量控制等。
容错率:
反映了网络传输的可靠性,共有三种定义:
位差错率,定义为出错的位数与所传输的位数之比;帧差错率,定义为出错的帧数与所传输的总帧数之比;分组差错率,定义为出错的分组数与所传输的总分组数之比。
传输延时:
定义为信源发送出第1个比特信号到信宿接收到第1个比特之间的时间差,其中包括信号传播延时和处理延时。
另一个常用的表示延时的参数是端到端延时,即一组数据在信源终端上准备好发送的时刻到信宿收到这组数据的时刻之间的时间差,包括网络接收这组数据的时延、传送这组数据的时间和网络传输延时三部分。
延迟抖动:
指在一条连接上分组延迟的最大变化量,即端到端延迟的最大值与最小值之差。
抖动产生的原因可能是介质访问时间的变化、流量控制的等待时间和存储转发机制中的排队时间等。
理想情况下端到端延迟是一个恒定值(零抖动),但由于网络故障、传输错误以及网络拥塞等原因,延迟抖动总是不能避免的。
具体应用中,在接收端设置足够的缓冲区容量可以缓和延迟抖动的问题。
表5-1QoS参数举例
多媒体对象
最大延迟
/ms
最大延迟抖动
/ms
平均吞吐量
/(Mb/s)
容错率
语音
0.25
10
0.064
视频
0.25
10
100
压缩视频
0.25
1
2~10
5.4.2QoS控制和管理
为了实现QoS的控制和管理,首先必须明确在设计QoS控制和管理机制时应遵循的基本原则,其次要对QoS进行准确而细致的描述,然后针对端到端QoS的控制过程制定出相应的QoS控制和管理机制,最后还要明确综合服务网络系统在不同层次的QoS实现是不同的。
5.4.2.1QoS设计的基本原则
将QoS控制过程引入网络系统必须考虑以下5个基本原则。
1.集成原则
该原则阐述了为了满足用户的端到端QoS控制要求,在所有的层次系统上QoS都必须是可配置、可预测和可维护的。
当多媒体信息流从源媒体设备产生,向下经过协议栈,并穿过网络,再向上经过接收端协议栈进入媒体播放设备时,所穿越的系统各个层次的资源模块(如CPU、内存和网络等)都必须提供QoS的可配置性(基于QoS描述)、资源担保(由QoS控制机制提供)以及流的QoS维护(由QoS的管理机制实现)。
2.分离原则
该原则阐述了媒体的传输、控制和管理是系统的不同功能行为。
这个任务的分离一方面是需要区分控制信令和媒体数据的传输,另一方面是由于两者所要求的服务不同造成的。
媒体数据流通常要求高带宽、低延迟、低抖动并容许一定丢失率的服务,而控制信令的传输通常要求低带宽、无抖动限制和高可靠性的服务。
3.透明原则
该原则阐述了应用必须被屏蔽在底层复杂的QoS控制和管理机制之外。
透明性的一个重要方面是用户期望得到的QoS能够通过一个基于QoS的应用程序接口(ApplicationProgrammingInterface,API)来描述。
透明性的优点表现在三个方面:
(1)可以将QoS功能与多媒体应用设计相分离,从而简化应用设计并增强可移植性;
(2)可以向应用层屏蔽底层网络的服务细节;(3)可以将复杂的QoS控制和管理任务交给底层的网络实现。
4.异步资源管理原则
由于在分布式通信环境中不同行为(如调度、流控、路由和QoS管理等)的产生在时间上是不同的,因此对综合服务网络系统资源的管理是异步的。
为了协调这些异步管理的资源,从而为用户应用提供一致的端到端QoS控制,必须在这些资源之间周期性地交换控制信息。
5.性能原则
该原则阐述了QoS控制和管理机制的设计必须以提高网络系统的性能为目的。
综合服务网络既要能担保多媒体应用的QoS,又要能灵活机动地支持不同的用户应用,从而使网络利用率得到较大的提高。
5.4.2.2QoS的控制和管理机制
QoS的控制和管理机制是由用户的QoS描述、资源能力以及资源管理策略所驱动的,也称为QoS保障机制。
完整的QoS保障机制应包括QoS规范和QoS机制两大部分。
QoS规范表明应用所需要的服务质量,而如何在运行过程中达到所需要的质量,则由QoS机制来完成。
QoS机制根据用户提出的QoS规范,对可利用的资源进行配置和管理。
QoS机制可以分为静态和动态两大类,静态资源管理负责处理流建立和端到端QoS再协商过程,即QoS提供机制;动态资源管理负责处理媒体传递过程,即QoS控制和管理机制。
1.QoS提供机制
QoS提供机制包括4个方面的内容。
(1)QoS映射
QoS映射完成不同级(如操作系统、传输层和网络)的QoS表示之间的自动切换,即通过映射各层都将获得适合于本层使用的QoS参数,例如将应用层的帧率映射成网络层的比特率,供协商和再协商之用,以便各层次进行相应的配置和管理。
(2)QoS协商
用户在使用服务之前应将其特定的QoS要求通知系统,进行必要的协商,以便就用户可接受、系统可支持的QoS参数值达成一致,使这些达成一致的QoS参数值成为用户和系统共同遵守的合同。
用户和系统之间的协商包括双边对等协商、双边层间协商以及三边层间协商等类型。
1)双边对等协商是在呼叫方和被呼叫方之间进行,不允许服务提供者修改由服务用户提出的建议值;
2)双边层间协商在服务用户和服务提供者之间进行;
3)三边协商在两个服务用户(呼叫方和被呼叫方)以及服务提供者之间进行,三边协商可以看作是双边对等协商和双边层间协商的合成。
(3)接纳控制
接纳控制首先判断能否获得所需的资源,这些资源主要包括端系统以及沿途各节点上的处理时间、缓冲空间和链路的带宽等。
若判断成功,则为用户请求预约所需的资源。
如果系统不能按用户所申请的QoS接纳用户请求,则用户可以通过再协商选择较低的QoS。
(4)资源预留与分配
按照用户QoS规范安排合适的端系统、预留和分配网络资源,然后根据QoS映射,在每一个经过的资源模块(如CPU、存储器和交换机等)进行控制,分配端到端的资源。
2.QoS控制机制
QoS控制机制是指在业务流传送过程中的实时控制机制,主要包括以下5个方面的内容。
(1)流调度
调度机制是向用户提供并维持所需QoS水平的一种基本手段,流调度是在终端以及网络节点上传送数据的策略。
1)最早最后期限优先(EarliestDeadlineFirst,EDF)算法。
在该算法中,调度器从已就绪但还没有完全处理完毕的任务中选择最后期限最早的任务,即首先传送时间要求最紧迫的数据,并分配资源。
(DelayEarliestDueDate,EDD)算法为排队策略一种,EDF算法可扩充为延迟EDD(DelayEarliestDueDate)算法或抖动EDD(JitterEarliestDueDate)算法。
使用延迟EDD算法时,服务提供者根据合同将分组的最后期限设置为应该发送该分组的时间,该时间实际上就是该分组的预计到达时间与交换机延迟界限两者之和。
通过预约峰值速率带宽,延迟EDD可以确保每条连接的延迟界限。
采用抖动EDD算法时,在为某个分组提供服务之后,交换机就为该分组打上一个戳,该戳用来指示该分组的最后期限和实际结束时间之差。
由此可提供最小和最大延迟保证,从而有效地控制延迟抖动。
2)加权公平排队(WeightedFairQueuing,WFQ)算法。
假设N个流汇合进入一条干线,则每个流应分享1/N的总带宽。
当
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 多媒体 通信 中的 关键技术 资料
![提示](https://static.bingdoc.com/images/bang_tan.gif)