一種基于RTCP反饋的3G流媒體速率控制算法

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

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

中圖分類號(hào):TN919.3-34文獻(xiàn)標(biāo)識(shí)碼:A

文章編號(hào):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 引 言

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

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

1 RTCP反饋機(jī)制

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

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

服務(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ì)無線鏈路的吞吐量變化。在媒體會(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ù)傳輸控制[5]。在這種反饋機(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)等信息[6]。3GPP PSS規(guī)范中還定義了NADU(Next Application Data Unit，下一個(gè)應(yīng)用數(shù)據(jù)單元)反饋包，用以描述終端能力，并提供客戶端緩存狀態(tài)的信息[7]。NADU中3個(gè)主要部分分別為:

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

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

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

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

圖2 RTCP反饋過程

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

當(dāng)客戶端向服務(wù)器發(fā)出服務(wù)請(qǐng)求后，服務(wù)器通過RTSP協(xié)議為客戶端配置連接屬性，并獲得網(wǎng)絡(luò)緩存和客戶端緩存Nmax和Cmax，完成流媒體會(huì)話的建立[9]。會(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=0，則在t時(shí)間內(nèi)發(fā)送N個(gè)數(shù)據(jù)包的數(shù)據(jù)量為∑Ni=ISN=0Si。服務(wù)器收到來自客戶端的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)為:

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

(1)

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

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

(2)

這個(gè)時(shí)間偏移是RTCP反饋中NADU包從生成到被接收的時(shí)間，同時(shí)也考慮到了發(fā)生播放暫?；驍?shù)據(jù)緩沖的情況。服務(wù)器在收到反饋包后t時(shí)刻(t>tRR)可測(cè)知當(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的實(shí)際解碼時(shí)間。由于式(3)沒有考慮服務(wù)器已經(jīng)發(fā)送，但客戶端尚未接收的數(shù)據(jù)包，故對(duì)上式作如下修正:

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

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

(4)

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

Ncurr+Si≤Nmax

Si≤Cfree

(5)

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

Ncurr+Si≤Nthrehold

Si≤Cthrehold

(6)

式中:Nthrehold，Cthrehold為安全閾值，這個(gè)閾值可以保證在新的RTCP反饋到來前，不會(huì)因?yàn)椴荒芗皶r(shí)判斷發(fā)送條件而造成緩存數(shù)據(jù)溢出。

由式(1)和式(4)還可以看出，Ncurr估值略有偏高而Cfree估值略為偏低。這樣做是為了可以更有效地防止經(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è)包。無線鏈路上的最大帶寬為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ù)器對(duì)發(fā)送速率不加控制時(shí)，網(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ù)器可以及時(shí)估計(jì)緩存狀態(tài)，并控制發(fā)送速率，即使無線鏈路發(fā)生中斷也能有效地防止緩存數(shù)據(jù)上溢。從圖6和圖7可以看出，網(wǎng)絡(luò)緩存和客戶端緩存中的數(shù)據(jù)量始終控制在其存儲(chǔ)能力范圍內(nèi)。當(dāng)無線鏈路中斷后，服務(wù)器發(fā)現(xiàn)網(wǎng)絡(luò)緩存中數(shù)據(jù)量超過安全閾值時(shí)就暫停了數(shù)據(jù)發(fā)送，其發(fā)送速率如圖8所示。由于320 Kb的終端緩存可以存儲(chǔ)5.6 s的57 Kb/s媒體內(nèi)容，所以理論上可以承受5 s的無線鏈路中斷。從圖7亦可以看出，該算法兼顧了數(shù)據(jù)發(fā)送效率，較為合理地利用了終端緩存空間，保證了在媒體應(yīng)用過程中不發(fā)生數(shù)據(jù)下溢，避免了鏈路中斷對(duì)播放流暢性的影響。

圖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ù)欠載為目的實(shí)現(xiàn)的。從仿真的結(jié)果來看，該算法不僅可以避免緩存數(shù)據(jù)上溢，而且能使終端緩存保持?jǐn)?shù)據(jù)豐滿，有效地抵抗了由無線鏈路惡化或完全中斷造成的影響。如果該算法結(jié)合自適應(yīng)流和流瘦化技術(shù)可以更好地實(shí)現(xiàn)3G多媒體的流暢播放[10]，提高用戶對(duì)業(yè)務(wù)的感知質(zhì)量。

參考文獻(xiàn)

[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.