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

1. RTCP反饋機制
    3GPP PSS規(guī)范提供了一個完整的基于移動網(wǎng)絡(luò)的點對點流媒體結(jié)構(gòu)框架，如圖1所示。


    服務(wù)器實現(xiàn)流媒體內(nèi)容封包，并經(jīng)由公共網(wǎng)Internet和移動核心網(wǎng)組成的全IP網(wǎng)絡(luò)發(fā)送給用戶終端。在核心網(wǎng)中，網(wǎng)絡(luò)緩存一般存在于SGSN或RNC 中，其作用是應(yīng)對無線鏈路的吞吐量變化。在媒體會話期間，RTP提供了端到端的實時傳輸功能，但不保證服務(wù)質(zhì)量，而RTCP提供關(guān)于當前網(wǎng)絡(luò)狀況和數(shù)據(jù)接收質(zhì)量的反饋。服務(wù)器根據(jù)這些信息可以實現(xiàn)針對網(wǎng)絡(luò)狀態(tài)變化的數(shù)據(jù)傳輸控制。在這種反饋機制中，客戶端產(chǎn)生RTCP RR(RTCP Receiver Report，RTCP接收方報告)，服務(wù)器產(chǎn)生RTCP SR(RTCP Sender Report，RTCP發(fā)送方報告)。它們分別提供了丟包率、間隔抖動、最大接收包序號和最大發(fā)送包序號等信息。3GPP PSS規(guī)范中還定義了NADU(Next Application Data Unit，下一個應(yīng)用數(shù)據(jù)單元)反饋包，用以描述終端能力，并提供客戶端緩存狀態(tài)的信息。NADU中3個主要部分分別為：
    播放延時(Play-out Delay，PD)，它是下一個應(yīng)用數(shù)據(jù)單元的預定播放時間和生成NADU包的時間差。
    下一個包序號(Next Sequence Numher，NSN)，它是緩存中下一個即將被解碼的數(shù)據(jù)包序號。
    可利用的緩存空間(Free Buffer Space，F(xiàn)BS)，它反映了當前緩存可用空間的大小。
    基于RTCP的反饋過程，如圖2所示。當服務(wù)器與客戶端完成會話建立之后，服務(wù)器便啟動流媒體傳輸過程，RTP協(xié)議負責實現(xiàn)媒體數(shù)據(jù)從服務(wù)器到客戶端的傳輸?？蛻舳藢⒔y(tǒng)計的丟包率、最大接收包序號(HRSN)、播放延遲、可用的緩存空間和即將送入解碼器的包序號(NSN)分別放入RTCP SR和NADU中對應(yīng)的參數(shù)域，構(gòu)成RTCP混合包。RTCP混合包周期性地發(fā)送給服務(wù)器，用以估計網(wǎng)絡(luò)狀態(tài)以及客戶端緩存空間的占用狀態(tài)。服務(wù)器還可以利用發(fā)送包序列號的統(tǒng)計值與RTCP RR中的HRSN對SGSN或RNC上的緩存狀態(tài)做出判斷，調(diào)整數(shù)據(jù)包的發(fā)送速率，實現(xiàn)發(fā)送速率控制。



2 發(fā)送速率控制算法
    當客戶端向服務(wù)器發(fā)出服務(wù)請求后，服務(wù)器通過RTSP協(xié)議為客戶端配置連接屬性，并獲得網(wǎng)絡(luò)緩存和客戶端緩存Nmax和Cmax，完成流媒體會話的建立。會話建立后，服務(wù)器將媒體內(nèi)容分割打包，標記序列號。并發(fā)送給客戶端。設(shè)第i個數(shù)據(jù)包的大小為Si，當服務(wù)器在會話初始時刻發(fā)送的第一個數(shù)據(jù)包序號為ISN=O，則在t時間內(nèi)發(fā)送N個數(shù)據(jù)包的數(shù)據(jù)量為。服務(wù)器收到來自客戶端的RTCP反饋后，可以獲知RTCP RR報告產(chǎn)生時客戶端已接收的包序號HRSN，以及本地記錄的發(fā)送包序號，即當前已發(fā)送的最大包序號HTSN。序號HTSN與HRSN的差值表示為正在網(wǎng)絡(luò)中傳輸?shù)臄?shù)據(jù)包數(shù)目，假設(shè)這些數(shù)據(jù)包都暫存在網(wǎng)絡(luò)緩存中，那么可估計當前網(wǎng)絡(luò)緩存存儲狀態(tài)為：
  
    因此，服務(wù)器每收到一個RTCP反饋包就可以由上式求得網(wǎng)絡(luò)緩存狀態(tài)?？蛻舳耸盏降臄?shù)據(jù)包預先存貯在終端緩存中，然后按時間戳順序送入解碼器解碼播放。客戶端生成NADU反饋與序號為NSN的數(shù)據(jù)包預定播放時間之間的延遲為tPD，服務(wù)器接收到RTCP反饋的時間為tRR，序號為i的數(shù)據(jù)包預定播放時間即時間戳Ti，故有時間偏移toff：
  
    這個時間偏移是RTCP反饋中NADU包從生成到被接收的時間，同時也考慮到了發(fā)生播放暫?；驍?shù)據(jù)緩沖的情況。服務(wù)器在收到反饋包后t時刻(t>tRR)可測知當前客戶端緩存的空余量為：
   
    式中：FBS為NADU反饋的緩存可用空間；TNSN+toff為數(shù)據(jù)包NSN的實際解碼時間。由于式(3)沒有考慮服務(wù)器已經(jīng)發(fā)送，但客戶端尚未接收的數(shù)據(jù)包，故對上式作如下修正：
   
    利用式(1)和式(4)，服務(wù)器在發(fā)送下一個數(shù)據(jù)包i=HTSN+1前，應(yīng)做如下判斷：
   
    當上述兩式同時成立時，表明網(wǎng)絡(luò)緩存和客戶端緩存尚有余量接收新的數(shù)據(jù)包，服務(wù)器繼續(xù)發(fā)送新的數(shù)據(jù)包是安全的。否則，服務(wù)器暫停發(fā)送直至上式中條件成立。進一步考慮發(fā)送速率控制的有效性，對式(5)做如下修正：
   
    式中：Nthrehold，Cthrehold為安全閾值，這個閾值可以保證在新的RTCP反饋到來前，不會因為不能及時判斷發(fā)送條件而造成緩存數(shù)據(jù)溢出。由式(1)和式(4)還可以看出，Ncurr估值略有偏高而Cfree估值略為偏低。這樣做是為了可以更有效地防止經(jīng)常性的網(wǎng)絡(luò)緩存數(shù)據(jù)上溢和移動終端數(shù)據(jù)下溢的發(fā)生。

3 算法仿真
    根據(jù)上述算法，用Matlab仿真，時長為42 s的媒體內(nèi)容以57 Kb／s的速率編碼，在服務(wù)器端均分為360個包。無線鏈路上的最大帶寬為64 Kb／s，在鏈路數(shù)據(jù)傳輸過程中有5 s的中斷。SGSN或RNC上的緩存最大值為160 Kb，客戶端緩存最大值為320 Kb，并在媒體應(yīng)用前有3 s的預緩沖。設(shè)定安全閾值Nthrehold，Cthrehold分別為最大值的95％和90％?？蛻舳薘TCP反饋包的發(fā)送間隔為1 s。如果服務(wù)器對發(fā)送速率不加控制時，網(wǎng)絡(luò)緩存與客戶端緩存中的數(shù)據(jù)量如圖3，圖4所示?？蛻舳嗽?1 s左右緩存開始發(fā)生數(shù)據(jù)溢出，網(wǎng)絡(luò)緩存在45～50 s之間由于無線鏈路發(fā)生中斷，網(wǎng)絡(luò)緩存中數(shù)據(jù)量急劇上升并發(fā)生數(shù)據(jù)上溢。圖5為服務(wù)器的發(fā)送速率。


    基于RTCP反饋控制算法的服務(wù)器可以及時估計緩存狀態(tài)，并控制發(fā)送速率，即使無線鏈路發(fā)生中斷也能有效地防止緩存數(shù)據(jù)上溢。從圖6和圖7可以看出，網(wǎng)絡(luò)緩存和客戶端緩存中的數(shù)據(jù)量始終控制在其存儲能力范圍內(nèi)。當無線鏈路中斷后，服務(wù)器發(fā)現(xiàn)網(wǎng)絡(luò)緩存中數(shù)據(jù)量超過安全閾值時就暫停了數(shù)據(jù)發(fā)送，其發(fā)送速率如圖 8所示。由于320 Kb的終端緩存可以存儲5．6 s的57 Kb／s媒體內(nèi)容，所以理論上可以承受5 s的無線鏈路中斷。從圖7亦可以看出，該算法兼顧了數(shù)據(jù)發(fā)送效率，較為合理地利用了終端緩存空間，保證了在媒體應(yīng)用過程中不發(fā)生數(shù)據(jù)下溢，避免了鏈路中斷對播放流暢性的影響。



4 結(jié)語
    本文所闡述3G流媒體速率控制算法，是基于3GPP PSS規(guī)范中RTCP RR和NADU反饋信息，以防止網(wǎng)絡(luò)緩存和終端緩存數(shù)據(jù)欠載為目的實現(xiàn)的。從仿真的結(jié)果來看，該算法不僅可以避免緩存數(shù)據(jù)上溢，而且能使終端緩存保持數(shù)據(jù)豐滿，有效地抵抗了由無線鏈路惡化或完全中斷造成的影響。如果該算法結(jié)合自適應(yīng)流和流瘦化技術(shù)可以更好地實現(xiàn)3G多媒體的流暢播放，提高用戶對業(yè)務(wù)的感知質(zhì)量。