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

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


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



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

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


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



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