一種基于RTCP反饋的3G流媒體速率控制算法
加入技術交流群
2 發送速率控制算法
當客戶端向服務器發出服務請求后，服務器通過RTSP協議為客戶端配置連接屬性，并獲得網絡緩存和客戶端緩存Nmax和Cmax，完成流媒體會話的建立。會話建立后，服務器將媒體內容分割打包，標記序列號。并發送給客戶端。設第i個數據包的大小為Si，當服務器在會話初始時刻發送的第一個數據包序號為ISN=O，則在t時間內發送N個數據包的數據量為。服務器收到來自客戶端的RTCP反饋后，可以獲知RTCP RR報告產生時客戶端已接收的包序號HRSN，以及本地記錄的發送包序號，即當前已發送的最大包序號HTSN。序號HTSN與HRSN的差值表示為正在網絡中傳輸的數據包數目，假設這些數據包都暫存在網絡緩存中，那么可估計當前網絡緩存存儲狀態為：
因此，服務器每收到一個RTCP反饋包就可以由上式求得網絡緩存狀態?？蛻舳耸盏降臄祿A先存貯在終端緩存中，然后按時間戳順序送入解碼器解碼播放?？蛻舳松蒒ADU反饋與序號為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％?？蛻舳薘TCP反饋包的發送間隔為1 s。如果服務器對發送速率不加控制時，網絡緩存與客戶端緩存中的數據量如圖3，圖4所示。客戶端在41 s左右緩存開始發生數據溢出，網絡緩存在45～50 s之間由于無線鏈路發生中斷，網絡緩存中數據量急劇上升并發生數據上溢。圖5為服務器的發送速率。
評論