随着多播技术的发展和分布式多媒体应用的普及,当前在Internet上出现了很多基于IP多播的实时视频应用。然而这些应用却面临着一个主要问题:如何针对异构和动态的网络环境,在保证TCP友好(TCPfriendliness)的基础上,支持不同接收用户的QoS要求,实现QoS过滤。在大容量的实时视频多播系统中,QoS过滤方法决定了系统整体性能的优劣。
基于网络的QoS过滤方法在网关或网络节点上实现,但要受制于数据在协议数据单元(PDU)中的封装方式,而且方法本身对网络体系结构有着较为严格的要求,受到网络实际条件的约束,目前应用起来还有一定的困难。相比较而言,终端型QoS过滤方法则更具可行性。在基于接收端驱动的终端型(Receiver driven Layered Multicast)[1,2]QoS过滤方法(缩写为RLM)中,源端将视频流分为基本层和若干增强层,通过独立的多播组发布,收端根据网络可用带宽自动增减加入的多播组数量。这种方法能够在一定程度上改善接收端的QoS,但固定的视频层次划分和层次速率无法自动适应动态变化的网络环境,从而影响了QoS过滤的效果。针对这个问题,本文提出了一种基于收发两端的双向驱动型(Sender and Receiverdriven Layered Multicast)QoS过滤方法(缩写为SRLM)。该方法充分利用了MPEG-4和H.264等视频编码标准的分层可调节码率编码技术,并建立在闭环反馈的基础上,能明显提升QoS过滤的效果。
2 方法实现原理
SRLM在源端和接收端之间构建了一个双向反馈通道,使源端能利用反馈通道收集接收端的带宽需求信息,并通过优化算法来动态调整视频分层数和各层次的编码速率,同时还能够通过前馈通道主动将当前调整的结果以多播报文的方式通知接收端。各接收端收到报文后,可以此作为调整依据,结合自身的有效接收带宽,有针对性地决定增减或保持所预订的视频分层数。而在RLM中,接收端为了最大化接收质量,必须引入协调或知识共享机制[1],以消除盲目进行增加视频分层尝试可能引起的网络拥塞。
2.1SRLM的源端部分实现算法
为了描述方便,做如下设定:
(1)源端采用累积分层方法,最大层次划分约束潍L。第一层为基本层,依次往后是各增强层。
(2)bi对应各层码率,i=1,2,…,L。各层次的码率约束为bi∈bimin,…,bimax,且均为数量有限的离散值。令ci=∑ij=1bj,j=1,2,…,i(i≤L),ci是第1层至第i层的逐层码率累积和,ci-ci-1=bi。将βl=c1,c2,…,cl定义为逐层累积码率向量,l≤L,其中c1=b1是基本层编码速率的下限。
(3)设加入多播会话的用户数量为N,相应的期望接收速率集合为r1,r2,r3,…,rN,现引入接收端公平指数定义:Jri,βl=Ψri,βlri,i≤N,其中Ψri,βl=maxc∶c≤ri,c∈c1,c2,…,cl,为接收端i当前的有效接收码率。显然Jri,βl≤1。令Jr,βl=1N∑Ni=1Jri,βl为N个接收端的总体接收公平指数。
根据上述设定,源端QoS过滤可以定义为:在条件(1)和(2)的约束下,如何确定当前最大分层数l′和逐层累积码率向量βl′,使Jr,βl′取得最大值。
算法的具体描述如下:
(1)收集RR反馈报文,拆解得到各接收端当前期望接收速率的集合r1,r2,r3,…,rN,并计算在当前分层数l和逐层累积码率向量βl=c1,c2,…,cl下的总体接收公平指数。
(2)根据条件(1)和(2)的约束,将数值超过∑Li=1bimax的ri全部合并为数值等于∑Li=1bimax的一项,对低于b1min的则进行删除,不列入平均公平指数的计算。这样,接收端有效期望接收速率集合(可有重复项)的项数实际还剩余N′=N-m-n+1,其中m为数值超过∑Li=1bimax的ri项数,n为数值低于b1min的ri项数。由此得到经过预处理的接收端期望接收速率集合r′1,r′2,…,r′N′。
(3)将公式Jr,βl=1N∑Ni=1Jri,βl修正惟Jr′,βl′=1N′∑N′i=1Jr′i,βl′,代入数据进行计算试探,搜寻使总体公平指数达到最大值的l′和βl′。定义调整容限ε,当Jr′,βl′-Jr,βl>ε时,编码器按照参数l′和βl′做相应优化调整,反之维持当前状态以保证系统的相对平稳性。
(4)返回第一步重新开始。源端在执行上述步骤的同时,每隔TSR秒通过多播方式向各接收端发送一次SR报文,报告源端当前的视频分层数、逐层累积码率向量βl。TSR的设定为:TSR=TAdj/k,k为大于1的整数,TAdj为源端执行上述算法的周期,也称为源端调整周期。 TAdj的选取不能过小,否则会加大源端的计算负担并引起调整振荡,不利于实时视频数据的传输和接收,同时也会给正确收集和统计各接收端的期望接收速率报告带来困难。分析表明,TAdj取值在10~15 s较为合理。
2.2SRLM的接收端部分算法实现
接收端算法的具体描述如下:
(1)估算参数p,tRTT和tRTO的值;
(2)如果收到SR报文转到下一步,否则返回上一步;
(3)拆解SR报文得到源端当前的βl,利用(1)计算本接收端期望接收速率r;
(4)根据βl和期望接收速率r来调整本端预订的视频层数。
(5)返回第一步。
接收端在执行上述步骤的同时,每隔TRR秒向源端发送一个RR报文,报告接收端期望的接收速率。同时该报文还用作tRTT估算的一个请求。
tRTT采用闭环估算方法。源端收到接收端RR报文时会通过多播方式返回一个SR报文作为回应,但为了降低系统开销,源端不会单独回应每一个RR报文,而是成批进行处理。也即,假设源端在本地t时刻发送了一个SR报文,并在下一个SR报文发出时刻t+TSR之前的treturn1,treturn2,…,treturnk时刻,陆续收到k个接收端返回的RR报文,这些报文都带有各自的同步源标识符SSRCi。源端在时刻t+TSR通过多播方式发送下一个SR报文,该报文除了βl参数外,还包含一个列表,列表内容为上述k个接收端的SSRCi及其对应的tdelayi。tdelayi是源端响应某个RR报文的延迟时间(即源端从收到某个报文至发送下一个SR报文的时间间隔)。
可以看出:tdelayi=t+TSR-treturni。接收端收到SR报文后,若在报文里搜索到与本端对应的SSRCi→tdelayi项,则可通过τ0=t″-t′-tdelayi得到tRTT的闭环估算值。t′和t″分别为接收端发送RR报文和收到SR报文的本地时间。当接收端发出一个RR报文经过TSR+tRTO(秒)后仍未得到相应的SR报文回应,则认为SR包已经丢失,接收端清除请求记录并发出新的RR报文。
参数tRTO可以通过tRTO=max1,4τ0来推算[4], 这个经验公式在实际应用中已经能够提供较好的TCP友好性。丢包率p的估计可以参考文献[4]中提到的方法,但当接收端接收的视频层数大于1时,有必要将每一层的视频流单独对待,因此总的丢包率p是在对各层的丢包率进行权衡计算的基础上得到的。
3 仿真实验和性能评价
本节通过网络模拟器ns-2[5]对SRLM进行了性能仿真和分析。
仿真实验建立的网络拓扑结构如图3所示,使用如下缺省设置:(1)采用FIFO/droptail调度策略,最大排队时延150 ms;(2)路由器之间的传输时延20 ms,路由器和终端之间的传输时延10 ms;(3)TCP流在整个仿真实验过程始终持续,发送最大窗口为4 000个数据包;(4)多播视频流和TCP流的数据包大小均统一为500个字节;(5)各视频接收端的初始参数设置为:tRTT=100 ms,p=0。
在验证SRLM对TCP流友好性的实验中,源端各视频分层的初始速率设为256,512,1024 kbps,处于LAN中的视频接收端为5个。
SRLM使TCP流和视频多播流能够较好地共享链路瓶颈,并保持相近的传输带宽,表现出了良好的公平性。
为了进一步验证SRLM的有效性,在仿真实验中还将其与RLM在总体接收公平指数上进行了比较。实验的基本设定如下:
(1)RLM的两种累积层码率分配方式:(a)均匀分配型(uniform allocation,图5中以RLM-UA指代),即令ci=ci-1+σ,实验中σ=(2 048-128)/L;(b)指数分配(exponential allocation,图5中以RLM-EA指代),即令ci=λci-1,实验中λ=L2048/128。(a)和(b)中的L指分层数,基本层最低速率均设置为128 kbps。
(2)SRLM的累积层码率设置同上述(b),每一层有128/L个(取整数)速率调整点,层内的调整是匀速步进的。
(3)仿真环境为1 000个多播接收端,接收端按照预定视频层数的不同呈簇群性分布,我们对各接收端的期望接收速率ri应用混合高斯分布模型[6],并假设有5个簇群(每个簇群200个接收端),簇群的平均期望接收速率集合为160,360,800,1 200,1 800。
对比结果较好地体现了SRLM的QoS过滤性能。从图中我们还可以看出,当视频分层数超过5层时,系统总体接收公平指数的改善逐渐趋于平缓,且过多的分层数会加大收发两端的计算量和计算复杂度,反而会在一定程度上降低实时视频多播的QoS过滤效果。实际应用中,3~5层已经能够很好地适应各种多播接收会话数量。
4 结束语
在当前动态异构的IP网络中,基于终端系统的视频QoS过滤方法较为可行。通过在终端系统综合应用各种拥塞和速率控制策略以及误码控制机制,我们能够为实时多播视频提供一定的QoS保证,从而提高视频流的整体接收质量。但随着网络技术的发展和进步,基于网络的QoS过滤方法将会逐渐成熟并成为主要的应用方式。
特别声明:本站注明稿件来源为其他媒体的文/图等稿件均为转载稿,本站转载出于非商业性的教育和科研之目的,并不意味着赞同其观点或证实其内容的真实性。如转载稿涉及版权等问题,请作者在两周内速来电或来函联系。