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

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为服务器的发送速率。