一种基于RTCP反馈的3G流媒体速率控制算法

摘要：在3G流媒体业务中，缓存数据溢出严重地影响了多媒体画面质量和媒体播放的流畅性，降低了用户对流媒体业务感知的满意度。为了解决这个问题，根据3GPP PSS提出的反馈机制，阐述了一种基于RTCP反馈信息的3G流媒体速率控制算法。通过计算机仿真证明，该算法不仅有效防止了缓存数据上溢，而且保证了发送效率，避免了缓存数据欠载，从而实现了高质量的流媒体服务。
关键词：RTCP反馈；网络缓存上溢；客户缓存下溢；速率控制

0 引言
    第三代移动无线通信传输技术，在户外环境中能够提供384Kb／s的传输带宽，在室内最高可达2Mb／s，因此3G系统能够承载高质量的移动流媒体业务。随着移动用户对影音点播业务的需求增加和运营商对3G网络的大规模推广，流式多媒体服务逐步发展成为最重要的移动增值业务。但是无线链路的时变特性和移动终端的功能限制，使流媒体业务质量遭遇了极大的挑战。研究表明，缓存数据下溢通常会引起画面定格、用户播放中断和经常性的数据缓冲，而上溢则会抛弃接收到超出缓存容量限制的数据包，从而引起丢包率的增加，破坏媒体画面质量，严重影响到用户对业务感知质量的满意度。
    如果流媒体服务器能根据当前缓存数据的使用状况及时调整流媒体的发送速率就可以实现对缓存数据的存贮控制，从而避免缓存数据溢出。本文阐述了一种基于RTCP反馈信息的流媒体速率控制算法，它可以有效地实现上述目的，实现流媒体业务的无中断流畅播放，提高用户的感知质量。

1. RTCP反馈机制
    3GPP PSS规范提供了一个完整的基于移动网络的点对点流媒体结构框架，如图1所示。


    服务器实现流媒体内容封包，并经由公共网Internet和移动核心网组成的全IP网络发送给用户终端。在核心网中，网络缓存一般存在于SGSN或RNC 中，其作用是应对无线链路的吞吐量变化。在媒体会话期间，RTP提供了端到端的实时传输功能，但不保证服务质量，而RTCP提供关于当前网络状况和数据接收质量的反馈。服务器根据这些信息可以实现针对网络状态变化的数据传输控制。在这种反馈机制中，客户端产生RTCP RR(RTCP Receiver Report，RTCP接收方报告)，服务器产生RTCP SR(RTCP Sender Report，RTCP发送方报告)。它们分别提供了丢包率、间隔抖动、最大接收包序号和最大发送包序号等信息。3GPP PSS规范中还定义了NADU(Next Application Data Unit，下一个应用数据单元)反馈包，用以描述终端能力，并提供客户端缓存状态的信息。NADU中3个主要部分分别为：
    播放延时(Play-out Delay，PD)，它是下一个应用数据单元的预定播放时间和生成NADU包的时间差。
    下一个包序号(Next Sequence Numher，NSN)，它是缓存中下一个即将被解码的数据包序号。
    可利用的缓存空间(Free Buffer Space，FBS)，它反映了当前缓存可用空间的大小。
    基于RTCP的反馈过程，如图2所示。当服务器与客户端完成会话建立之后，服务器便启动流媒体传输过程，RTP协议负责实现媒体数据从服务器到客户端的传输。客户端将统计的丢包率、最大接收包序号(HRSN)、播放延迟、可用的缓存空间和即将送入解码器的包序号(NSN)分别放入RTCP SR和NADU中对应的参数域，构成RTCP混合包。RTCP混合包周期性地发送给服务器，用以估计网络状态以及客户端缓存空间的占用状态。服务器还可以利用发送包序列号的统计值与RTCP RR中的HRSN对SGSN或RNC上的缓存状态做出判断，调整数据包的发送速率，实现发送速率控制。



2 发送速率控制算法
    当客户端向服务器发出服务请求后，服务器通过RTSP协议为客户端配置连接属性，并获得网络缓存和客户端缓存Nmax和Cmax，完成流媒体会话的建立。会话建立后，服务器将媒体内容分割打包，标记序列号。并发送给客户端。设第i个数据包的大小为Si，当服务器在会话初始时刻发送的第一个数据包序号为ISN=O，则在t时间内发送N个数据包的数据量为。服务器收到来自客户端的RTCP反馈后，可以获知RTCP RR报告产生时客户端已接收的包序号HRSN，以及本地记录的发送包序号，即当前已发送的最大包序号HTSN。序号HTSN与HRSN的差值表示为正在网络中传输的数据包数目，假设这些数据包都暂存在网络缓存中，那么可估计当前网络缓存存储状态为：
  
    因此，服务器每收到一个RTCP反馈包就可以由上式求得网络缓存状态。客户端收到的数据包预先存贮在终端缓存中，然后按时间戳顺序送入解码器解码播放。客户端生成NADU反馈与序号为NSN的数据包预定播放时间之间的延迟为tPD，服务器接收到RTCP反馈的时间为tRR，序号为i的数据包预定播放时间即时间戳Ti，故有时间偏移toff：
  
    这个时间偏移是RTCP反馈中NADU包从生成到被接收的时间，同时也考虑到了发生播放暂停或数据缓冲的情况。服务器在收到反馈包后t时刻(t>tRR)可测知当前客户端缓存的空余量为：
   
    式中：FBS为NADU反馈的缓存可用空间；TNSN+toff为数据包NSN的实际解码时间。由于式(3)没有考虑服务器已经发送，但客户端尚未接收的数据包，故对上式作如下修正：
   
    利用式(1)和式(4)，服务器在发送下一个数据包i=HTSN+1前，应做如下判断：
   
    当上述两式同时成立时，表明网络缓存和客户端缓存尚有余量接收新的数据包，服务器继续发送新的数据包是安全的。否则，服务器暂停发送直至上式中条件成立。进一步考虑发送速率控制的有效性，对式(5)做如下修正：
   
    式中：Nthrehold，Cthrehold为安全阈值，这个阈值可以保证在新的RTCP反馈到来前，不会因为不能及时判断发送条件而造成缓存数据溢出。由式(1)和式(4)还可以看出，Ncurr估值略有偏高而Cfree估值略为偏低。这样做是为了可以更有效地防止经常性的网络缓存数据上溢和移动终端数据下溢的发生。

3 算法仿真
    根据上述算法，用Matlab仿真，时长为42 s的媒体内容以57 Kb／s的速率编码，在服务器端均分为360个包。无线链路上的最大带宽为64 Kb／s，在链路数据传输过程中有5 s的中断。SGSN或RNC上的缓存最大值为160 Kb，客户端缓存最大值为320 Kb，并在媒体应用前有3 s的预缓冲。设定安全阈值Nthrehold，Cthrehold分别为最大值的95％和90％。客户端RTCP反馈包的发送间隔为1 s。如果服务器对发送速率不加控制时，网络缓存与客户端缓存中的数据量如图3，图4所示。客户端在41 s左右缓存开始发生数据溢出，网络缓存在45～50 s之间由于无线链路发生中断，网络缓存中数据量急剧上升并发生数据上溢。图5为服务器的发送速率。


    基于RTCP反馈控制算法的服务器可以及时估计缓存状态，并控制发送速率，即使无线链路发生中断也能有效地防止缓存数据上溢。从图6和图7可以看出，网络缓存和客户端缓存中的数据量始终控制在其存储能力范围内。当无线链路中断后，服务器发现网络缓存中数据量超过安全阈值时就暂停了数据发送，其发送速率如图 8所示。由于320 Kb的终端缓存可以存储5．6 s的57 Kb／s媒体内容，所以理论上可以承受5 s的无线链路中断。从图7亦可以看出，该算法兼顾了数据发送效率，较为合理地利用了终端缓存空间，保证了在媒体应用过程中不发生数据下溢，避免了链路中断对播放流畅性的影响。



4 结语
    本文所阐述3G流媒体速率控制算法，是基于3GPP PSS规范中RTCP RR和NADU反馈信息，以防止网络缓存和终端缓存数据欠载为目的实现的。从仿真的结果来看，该算法不仅可以避免缓存数据上溢，而且能使终端缓存保持数据丰满，有效地抵抗了由无线链路恶化或完全中断造成的影响。如果该算法结合自适应流和流瘦化技术可以更好地实现3G多媒体的流畅播放，提高用户对业务的感知质量。