摘 要:在3G流媒體業(yè)務(wù)中，緩存數(shù)據(jù)溢出嚴(yán)重地影響了多媒體畫面質(zhì)量和媒體播放的流暢性，降低了用戶對流媒體業(yè)務(wù)感知的滿意度。為了解決這個問題，根據(jù)3GPP PSS提出的反饋機制，闡述了一種基于RTCP反饋信息的3G流媒體速率控制算法。通過計算機仿真證明，該算法不僅有效防止了緩存數(shù)據(jù)上溢，而且保證了發(fā)送效率，避免了緩存數(shù)據(jù)欠載，從而實現(xiàn)了高質(zhì)量的流媒體服務(wù)。

關(guān)鍵詞:RTCP反饋; 網(wǎng)絡(luò)緩存上溢; 客戶緩存下溢; 速率控制

中圖分類號:TN919.3-34文獻標(biāo)識碼:A

文章編號:1004-373X(2010)21-0021-03

Rate Control Algorithm for 3G Streaming Media Service Based on RTCP Feedback

RONG Wei， KANG Gui-hua， LI Hui

(Institute of Computer Information Engineering， Hohai University， Changzhou 213022， China)

Abstract: The buffer data under-run seriously affected the quality of multimedia images and media playback smooth， and reduced the user perceived streaming media business satisfaction in the 3G streaming media services. To solve this problem， the RTCP feedback-based 3G streaming media rate control algorithm according to 3GPP feedback mechanism is introduced. The simulation proves that the algorithm not only effectively prevented the buffer overflow， and ensured the efficiency of transmission to avoid buffer underflow， in order to achieve the high-quality streaming media services.

Keywords: RTCP feedback; network buffer overflow; client buffer underflow; rate control

0 引 言

第三代移動通信無線傳輸技術(shù)，在戶外環(huán)境中能夠提供384 Kb/s的傳輸帶寬，在室內(nèi)最高可達2 Mb/s[1]，因此3G系統(tǒng)能夠承載高質(zhì)量的移動流媒體業(yè)務(wù)。隨著移動用戶對影音點播業(yè)務(wù)的需求增加和運營商對3G網(wǎng)絡(luò)的大規(guī)模推廣，流式多媒體服務(wù)逐步發(fā)展成為最重要的移動增值業(yè)務(wù)[2]。但是無線鏈路的時變特性和移動終端的功能限制，使流媒體業(yè)務(wù)質(zhì)量遭遇了極大的挑戰(zhàn)。研究表明，緩存數(shù)據(jù)下溢通常會引起畫面定格、用戶播放中斷和經(jīng)常性的數(shù)據(jù)緩沖，而上溢則會拋棄接收到超出緩存容量限制的數(shù)據(jù)包，從而引起丟包率的增加，破壞媒體畫面質(zhì)量，嚴(yán)重影響到用戶對業(yè)務(wù)感知質(zhì)量的滿意度[3]。

如果流媒體服務(wù)器能根據(jù)當(dāng)前緩存數(shù)據(jù)的使用狀況及時調(diào)整流媒體的發(fā)送速率就可以實現(xiàn)對緩存數(shù)據(jù)的存貯控制，從而避免緩存數(shù)據(jù)溢出。本文闡述了一種基于RTCP反饋信息的流媒體速率控制算法，它可以有效地實現(xiàn)上述目的，實現(xiàn)流媒體業(yè)務(wù)的無中斷流暢播放，提高用戶的感知質(zhì)量。

1 RTCP反饋機制

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

圖1 基于移動網(wǎng)絡(luò)的點對點流媒體結(jié)構(gòu)框架

服務(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)于當(dāng)前網(wǎng)絡(luò)狀況和數(shù)據(jù)接收質(zhì)量的反饋。服務(wù)器根據(jù)這些信息可以實現(xiàn)針對網(wǎng)絡(luò)狀態(tài)變化的數(shù)據(jù)傳輸控制[5]。在這種反饋機制中，客戶端產(chǎn)生RTCP RR(RTCP Receiver Report，RTCP接收方報告)，服務(wù)器產(chǎn)生RTCP SR(RTCP Sender Report，RTCP發(fā)送方報告)。它們分別提供了丟包率、間隔抖動、最大接收包序號和最大發(fā)送包序號等信息[6]。3GPP PSS規(guī)范中還定義了NADU(Next Application Data Unit，下一個應(yīng)用數(shù)據(jù)單元)反饋包，用以描述終端能力，并提供客戶端緩存狀態(tài)的信息[7]。NADU中3個主要部分分別為:

播放延時(Play-out Delay，PD)，它是下一個應(yīng)用數(shù)據(jù)單元的預(yù)定播放時間和生成NADU包的時間差。

下一個包序號(Next Sequence Number，NSN)，它是緩存中下一個即將被解碼的數(shù)據(jù)包序號。

可利用的緩存空間(Free Buffer Space，F(xiàn)BS)，它反映了當(dāng)前緩存可用空間的大小。

基于RTCP的反饋過程，如圖2所示。當(dāng)服務(wù)器與客戶端完成會話建立之后，服務(wù)器便啟動流媒體傳輸過程，RTP協(xié)議負(fù)責(zé)實現(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ā)送速率控制[8]。

圖2 RTCP反饋過程

2 發(fā)送速率控制算法

當(dāng)客戶端向服務(wù)器發(fā)出服務(wù)請求后，服務(wù)器通過RTSP協(xié)議為客戶端配置連接屬性，并獲得網(wǎng)絡(luò)緩存和客戶端緩存Nmax和Cmax，完成流媒體會話的建立[9]。會話建立后，服務(wù)器將媒體內(nèi)容分割打包，標(biāo)記序列號。并發(fā)送給客戶端。設(shè)第i個數(shù)據(jù)包的大小為Si，當(dāng)服務(wù)器在會話初始時刻發(fā)送的第一個數(shù)據(jù)包序號為ISN=0，則在t時間內(nèi)發(fā)送N個數(shù)據(jù)包的數(shù)據(jù)量為∑Ni=ISN=0Si。服務(wù)器收到來自客戶端的RTCP反饋后，可以獲知RTCP RR報告產(chǎn)生時客戶端已接收的包序號HRSN，以及本地記錄的發(fā)送包序號，即當(dāng)前已發(fā)送的最大包序號HTSN。序號HTSN與HRSN的差值表示為正在網(wǎng)絡(luò)中傳輸?shù)臄?shù)據(jù)包數(shù)目，假設(shè)這些數(shù)據(jù)包都暫存在網(wǎng)絡(luò)緩存中，那么可估計當(dāng)前網(wǎng)絡(luò)緩存存儲狀態(tài)為:

Ncurr=∑HTSNi=ISNSi-∑HRSNj=ISNSj

(1)

因此，服務(wù)器每收到一個RTCP反饋包就可以由上式求得網(wǎng)絡(luò)緩存狀態(tài)。客戶端收到的數(shù)據(jù)包預(yù)先存貯在終端緩存中，然后按時間戳順序送入解碼器解碼播放?？蛻舳松蒒ADU反饋與序號為NSN的數(shù)據(jù)包預(yù)定播放時間之間的延遲為tPD，服務(wù)器接收到RTCP反饋的時間為tRR，序號為i的數(shù)據(jù)包預(yù)定播放時間即時間戳Ti，故有時間偏移toff:

toff=tRR+tPD-TNSN

(2)

這個時間偏移是RTCP反饋中NADU包從生成到被接收的時間，同時也考慮到了發(fā)生播放暫?；驍?shù)據(jù)緩沖的情況。服務(wù)器在收到反饋包后t時刻(t>tRR)可測知當(dāng)前客戶端緩存的空余量為:

Cfree=FBS+SNSN， TNSN+toff

FBS，TNSN+toff>t

(3)

式中:FBS為NADU反饋的緩存可用空間;TNSN+toff為數(shù)據(jù)包NSN的實際解碼時間。由于式(3)沒有考慮服務(wù)器已經(jīng)發(fā)送，但客戶端尚未接收的數(shù)據(jù)包，故對上式作如下修正:

Cfree=FBS+SNSN-Ncurr， TNSN+toff

FBS-Ncurr，TNSN+toff>t

(4)

利用式(1)和式(4)，服務(wù)器在發(fā)送下一個數(shù)據(jù)包i=HTSN+1前，應(yīng)做如下判斷:

Ncurr+Si≤Nmax

Si≤Cfree

(5)

當(dāng)上述兩式同時成立時，表明網(wǎng)絡(luò)緩存和客戶端緩存尚有余量接收新的數(shù)據(jù)包，服務(wù)器繼續(xù)發(fā)送新的數(shù)據(jù)包是安全的。否則，服務(wù)器暫停發(fā)送直至上式中條件成立。進一步考慮發(fā)送速率控制的有效性，對式(5)做如下修正:

Ncurr+Si≤Nthrehold

Si≤Cthrehold

(6)

式中:Nthrehold，Cthrehold為安全閾值，這個閾值可以保證在新的RTCP反饋到來前，不會因為不能及時判斷發(fā)送條件而造成緩存數(shù)據(jù)溢出。

由式(1)和式(4)還可以看出，Ncurr估值略有偏高而Cfree估值略為偏低。這樣做是為了可以更有效地防止經(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的預(yù)緩沖。設(shè)定安全閾值Nthrehold，Cthrehold分別為最大值的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ā)送速率。

圖3 無速率控制的網(wǎng)絡(luò)緩存數(shù)據(jù)量

圖4 無速率控制的客戶端緩存數(shù)據(jù)量

圖5 無控制的服務(wù)器發(fā)送速率

基于RTCP反饋控制算法的服務(wù)器可以及時估計緩存狀態(tài)，并控制發(fā)送速率，即使無線鏈路發(fā)生中斷也能有效地防止緩存數(shù)據(jù)上溢。從圖6和圖7可以看出，網(wǎng)絡(luò)緩存和客戶端緩存中的數(shù)據(jù)量始終控制在其存儲能力范圍內(nèi)。當(dāng)無線鏈路中斷后，服務(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ù)下溢，避免了鏈路中斷對播放流暢性的影響。

圖6 有速率控制的網(wǎng)絡(luò)緩存數(shù)據(jù)量

圖7 有速率控制的客戶端緩存數(shù)據(jù)量

圖8 有控制的服務(wù)器發(fā)送速率

4 結(jié) 語

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

參考文獻

[1]張建華，王瑩.WCDMA無線網(wǎng)絡(luò)技術(shù)[M].北京:人民郵電出版社，2007.

[2]ELSEN I， HARTUNG F， HOM U et al. Streaming technology in 3G mobile communication systems [J]. IEEE Computer， 2001: 46-52.

[3]CURCIO Igor D D， LEON David. Application Rate Adaptation for Mobile Streaming [C]//IEEE International Symposium on a World of Wireless， Mobile and Multimedia Networks， Taormina/Giardini Naxos， Italy: WoWMoM’05， 2005: 13-16.

[4]FRJDH Per， HORN Uwe， KAMPMANN Markus， et al. Adaptive streaming within the 3GPP packet-switched streaming service [J]. IEEE Network， 2006: 34-40.

[5]SIVABALAKRISHNAN M， MANJULA D. Analysis of decision feedback using RTCP for multimedia streaming over 3G [J]. Proceedings of the International Conference on Computer and Communication Engineering 2008， 2008: 1023-1026.

[6]IETF RFC 3550. RTP: A transport protocol for real-time applications [S]. [S.l.]: The Internet Society， 2003.

[7]3GPP TS 26.234. Transparent end-to-end packet-switched streaming service (PSS): protocols and codes (Release 8) [S]. [S.l.]: [s.n.]， 2001.

[8]BALDO N， HORN U， KAMPMANN M， et al. RTCP feedback based transmission rate control for 3G wireless multimedia streaming [J]. PIMRC， 2004: 1817-1821.

[9]LUNDAN Miikka， CURCIO Igor D D. Mobile streaming services in WCDMA networks [C]. 10th IEEE Symposium on Computers and Communications， 2005: 27-30.

[10]SCHIERL T， KAMPMANN M， Wiegand T. 3GPP Compliant Adaptive Wireless Video Streaming using H.264/AVC [C]. IEEE Int′l. Conf. Image Proc.， Genova.， 2005.