0 引言
    第三代移動無線通信傳輸技術，在戶外環境中能夠提供384Kb／s的傳輸帶寬，在室內最高可達2Mb／s，因此3G系統能夠承載高質量的移動流媒體業務。隨著移動用戶對影音點播業務的需求增加和運營商對3G網絡的大規模推廣，流式多媒體服務逐步發展成為最重要的移動增值業務。但是無線鏈路的時變特性和移動終端的功能限制，使流媒體業務質量遭遇了極大的挑戰。研究表明，緩存數據下溢通常會引起畫面定格、用戶播放中斷和經常性的數據緩沖，而上溢則會拋棄接收到超出緩存容量限制的數據包，從而引起丟包率的增加，破壞媒體畫面質量，嚴重影響到用戶對業務感知質量的滿意度。
    如果流媒體服務器能根據當前緩存數據的使用狀況及時調整流媒體的發送速率就可以實現對緩存數據的存貯控制，從而避免緩存數據溢出。本文闡述了一種基于RTCP反饋" title="RTCP反饋">RTCP反饋信息的流媒體速率控制" title="速率控制">速率控制算法，它可以有效地實現上述目的，實現流媒體業務的無中斷流暢播放，提高用戶的感知質量。

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多媒體的流暢播放，提高用戶對業務的感知質量。