基于多流的重傳策略論文
摘 要 在本篇論文中，針對現(xiàn)有RTP/UDP在傳輸流媒體的不足，我提出了一種新的傳輸技術(shù)：MSSR-RTP（Multiple Stream Selective Retransmission-Realtime Transmission Protocol，多流選擇性重傳實(shí)時(shí)傳輸協(xié)議）應(yīng)用層協(xié)議，然后利用這個協(xié)議建立了在Internet中傳輸H.264/AVC架構(gòu)體系。在實(shí)際項(xiàng)目中成功應(yīng)用，并顯示出其很好的網(wǎng)絡(luò)特性以及TCP友好特性。
關(guān)鍵詞 RTP/RTCP；多流；選擇性重傳
現(xiàn)有的Internet網(wǎng)的“盡力傳輸模式”并不能很好的滿足Qos的需求，大家都在不斷尋求解決方案，著名的Diffserv體系和Intserv體系都是在IP網(wǎng)絡(luò)中研究Qos提出的，但由于與現(xiàn)有網(wǎng)絡(luò)的兼容性以及兩者體系架構(gòu)的復(fù)雜性，其到目前都沒能應(yīng)用到實(shí)際Internet網(wǎng)絡(luò)中，在對網(wǎng)絡(luò)有特殊Qos需求的流媒體領(lǐng)域，如何在現(xiàn)有網(wǎng)絡(luò)體系中最大限度的解決延時(shí)，延遲抖動，丟包等問題一直是大家研究的熱點(diǎn)。目前的主流解決方案中：RTP/UDP架構(gòu)在一定程度上解決問題，但其存在不足，針對它的不足，我提出了MSSR-RTP應(yīng)用層協(xié)議，利用這個協(xié)議建立了MSSR-RTP/UDP的架構(gòu)體系。
1 介紹
在Internet上的流媒體應(yīng)用越來越廣泛，但現(xiàn)有的傳輸層UDP和TCP協(xié)議都不能很好的支持流媒體的傳輸，其主要原因跟壓縮技術(shù)和現(xiàn)有的網(wǎng)絡(luò)體系架構(gòu)有關(guān)。目前在流媒體領(lǐng)域的主流解決方案是：RTP/UDP[1]，即在UDP層上封裝RTP層，通過應(yīng)用層來加強(qiáng)和改善多媒體數(shù)據(jù)在Internet傳輸上的性能。但目前這個方案仍有不足，我們以目前的主流視頻壓縮算法：H.264/AVC[2]為例：
a．RTP沒有分優(yōu)先權(quán)的字段。
H.264/AVC有3種類型的幀（依據(jù)不同的軟件，其提供的幀類型可能更多）：I幀，進(jìn)行幀內(nèi)獨(dú)立編碼，可以看作參考幀；P幀，為前向預(yù)測幀，參考前面的I幀和P幀進(jìn)行編碼，采用運(yùn)動補(bǔ)償預(yù)測幀間誤差；B幀編碼依賴于前面的和后面的I或P幀。在傳輸中I幀和P幀數(shù)據(jù)出現(xiàn)錯誤，接收端視頻流回顯質(zhì)量會受到嚴(yán)重影響。特別是I幀數(shù)據(jù)，通過實(shí)際項(xiàng)目的測試發(fā)現(xiàn)，I幀的丟失將使畫面出現(xiàn)花屏，并且出現(xiàn)動畫效果，畫面不夠流暢。同時(shí)，由于網(wǎng)絡(luò)資源限制，我們又不能把所有視頻數(shù)據(jù)同樣對待，必須對其分類，使得關(guān)鍵數(shù)據(jù)能得到最大限度保障，而一些不重要的數(shù)據(jù)就不需要進(jìn)行重傳以減輕網(wǎng)絡(luò)負(fù)擔(dān)，但RTP機(jī)制并沒提供對信息分類的功能。在我提出的模型中，利用多流的特點(diǎn)，為每個流設(shè)置重傳時(shí)間，在重傳時(shí)間內(nèi)的數(shù)據(jù)進(jìn)行重傳，超過重傳時(shí)間的數(shù)據(jù)進(jìn)行丟棄，通過這種方法達(dá)到對不同優(yōu)先權(quán)的數(shù)據(jù)進(jìn)行分類處理。
b．RTP無法滿足分片的需要。
由于視頻數(shù)據(jù)幀通常很大，如果不進(jìn)行分片的話，分片和重組將給路由器和目的主機(jī)增加了額外的負(fù)擔(dān)。花費(fèi)額外的精力去創(chuàng)建數(shù)據(jù)報(bào)分片和分片重組。由于這個原因，需要將分片保持為最小，這里通過將應(yīng)用層的數(shù)據(jù)段限制在一個較小的范圍內(nèi)實(shí)現(xiàn)。由于所有IP支持的數(shù)據(jù)鏈路協(xié)議的MTU都被認(rèn)為至少有576字節(jié)，所以可以使用548字節(jié)的MSS、8字節(jié)的UDP數(shù)據(jù)段頭部和20字節(jié)的IP數(shù)據(jù)報(bào)報(bào)頭的分片方法。
c．無法通過RTP/RTCP來提供擁塞控制和流量管理。
網(wǎng)絡(luò)資源的公平共享提出了要終端提供擁塞控制以防止網(wǎng)絡(luò)惡化。為了防止接收端被數(shù)據(jù)“淹沒”，也需要發(fā)送端提供流量管理的功能，但標(biāo)準(zhǔn)RTP機(jī)制沒有提供這種功能。
針對現(xiàn)有架構(gòu)的不足，提出一種在RTP基礎(chǔ)上進(jìn)行擴(kuò)展的體系：MSSR-RTP/UDP。利用在終端增加多流技術(shù)，分片/重組功能，增加CWND/RWND變量對現(xiàn)有的不足進(jìn)行改進(jìn)。
2 體系架構(gòu)
根據(jù)H.264/AVC和現(xiàn)有Internet的特點(diǎn)，我擴(kuò)展了RTP/RTCP的功能，提出了MSSR-RTP（Multiple stream selective retransmission-Realtime transmission protocol）模型，其圖如圖1。
系統(tǒng)的研究對象是H.264/AVC，它為網(wǎng)絡(luò)開發(fā)者提供的是I，P，B幀，我把每一幀作為一個發(fā)送對象，取名：ADU（Application Data Unit應(yīng)用程序數(shù)據(jù)單元）。由于通常視頻數(shù)據(jù)都很大，需要進(jìn)行分片。分片后通過控制模塊添加MSSR-RTP頭信息，并把封裝后的數(shù)據(jù)放入緩存，在發(fā)送方，無論數(shù)據(jù)屬于哪個流，都放入同一個緩存中。最后由調(diào)度中心將數(shù)據(jù)調(diào)入傳輸層，然后發(fā)送到接收方，接收方通過重組分片，收集丟失數(shù)據(jù)，依據(jù)流的特性，將需要重傳的數(shù)據(jù)通過MSSR-RTCP回饋到發(fā)送方，進(jìn)行數(shù)據(jù)重傳。如果一幀的每個分片都到達(dá)接收端，則重組為一幀數(shù)據(jù)上傳給解碼器。
2.1 MSSR-RTP，MSSR-RTCP的頭格式以及流結(jié)構(gòu)
圖2是MSSR-RTP的頭格式，作為對標(biāo)準(zhǔn)RTP的擴(kuò)充，有其新特點(diǎn)。頭部信息中，順序號是用于分片重組的。流序號表示分片是屬于哪個流的。流順序號表示在一個流中的順序號，如果一個大的ADU分片，那不同片擁有相同的流順序號。ADU長度是表示此分片對應(yīng)的ADU的長度。ADU偏移量是表示此分片在對應(yīng)的ADU中的偏移量。
圖3是MSSR-RTCP的頭格式。MSSR-RTCP是在流媒體傳輸中與MSSR-RTP協(xié)同工作的協(xié)議。MSSR-RTCP定期發(fā)送供控制模塊使用的發(fā)送端或則接收端的統(tǒng)計(jì)報(bào)告。包括發(fā)送分組數(shù)、丟失分組數(shù)、間隔到達(dá)的抖動等。對于每個正在發(fā)送的RTP分組，發(fā)送方會創(chuàng)建并傳送RTCP發(fā)送方報(bào)告分組，在本體系中，與標(biāo)準(zhǔn)的RTCP一致。對于每個正在接收RTP分組的接收方，作為對標(biāo)準(zhǔn)RTCP的擴(kuò)展，MSSR-RTCP還提供了RWND字段和ACK GAP字段，前者用于在發(fā)送端進(jìn)行流量控制，后者用于進(jìn)行重傳。省略部分與標(biāo)準(zhǔn)RTCP一致，參考文獻(xiàn)[1]。
圖4是流數(shù)據(jù)結(jié)構(gòu)。作為我提出的結(jié)構(gòu)的核心，它是決定屬于此流的數(shù)據(jù)的重傳時(shí)間，對于流媒體，它并不需要所有的數(shù)據(jù)都到達(dá)，對于某些延遲超過設(shè)定的時(shí)間的幀并不需要重傳，這是由流媒體自身特點(diǎn)決定，并且，比其傳統(tǒng)單流，可以避免頭阻塞。
2.2 數(shù)據(jù)傳輸以及重傳策略
ADU傳到MSSR-RTP層，會首先進(jìn)行分片處理，然后由控制模塊加上MSSR-RTP報(bào)頭，由調(diào)度策略進(jìn)行數(shù)據(jù)發(fā)送，發(fā)送的數(shù)據(jù)依據(jù)其所在流的重傳時(shí)間決定發(fā)送后是否放入緩存。如果重傳時(shí)間不為0，發(fā)送后將緩存，如果重傳時(shí)間為0，則發(fā)送后就丟棄。緩存的數(shù)據(jù)依據(jù)MSSR-RTCP回饋進(jìn)行重傳和移除。其數(shù)據(jù)傳輸示意圖如下：
圖5 數(shù)據(jù)傳輸
服務(wù)器端通過函數(shù)SR_CREATE創(chuàng)建端口，然后調(diào)用函數(shù)SR_LISTEN進(jìn)行偵聽，客戶端一旦需要接收數(shù)據(jù)，通過調(diào)用函數(shù)SR_CONNECT與服務(wù)器端建立連接，連接建立后將使用兩個端口，一個端口用于傳輸帶有MSSR-RTP頭的視頻數(shù)據(jù)，另一個用于傳輸MSSR-RTCP控制信息。
數(shù)據(jù)發(fā)送規(guī)則如下：
a. 如果發(fā)送出去未被確認(rèn)的數(shù)據(jù)已經(jīng)達(dá)到或者超過CWND的時(shí)候，數(shù)據(jù)發(fā)送者不能再傳送任何數(shù)據(jù)到網(wǎng)絡(luò)中。
b. 當(dāng)RWND為0的時(shí)候，數(shù)據(jù)發(fā)送者不能再傳送任何數(shù)據(jù)到網(wǎng)絡(luò)中。當(dāng)未被確認(rèn)的數(shù)據(jù)未超過CWND的時(shí)候，數(shù)據(jù)發(fā)送者必須保證有一個包在網(wǎng)絡(luò)中未被確認(rèn)。
c. 當(dāng)選擇發(fā)送數(shù)據(jù)的時(shí)候，重發(fā)的數(shù)據(jù)要比新數(shù)據(jù)優(yōu)先。
通過以上的數(shù)據(jù)發(fā)送規(guī)則，能夠進(jìn)行擁塞控制與流量控制，滿足對網(wǎng)絡(luò)資源公平共享的原則，同時(shí)也能防止大量視頻數(shù)據(jù)“淹沒”接收端。
重傳規(guī)則如下：
a. 超時(shí)重傳。
b. 接收端通過MSSR-RTCP回饋指示重傳。
超時(shí)重傳的原理與TCP中采用的方法一樣，RTT的時(shí)間計(jì)算采用Karn’S算法，參考文獻(xiàn)[3]。
3 接收端丟失判斷和重傳策略
依據(jù)H.264/AVC的網(wǎng)絡(luò)特點(diǎn)，我們只對I幀數(shù)據(jù)進(jìn)行數(shù)據(jù)重傳，并且依據(jù)實(shí)際項(xiàng)目對實(shí)時(shí)性的不同要求設(shè)置流中重傳時(shí)間大小。
使用MSSR-RTP，接收端通過到達(dá)包的MSSR-RTP頭部信息來判斷包的丟失。通過順序號，如果沒發(fā)生數(shù)據(jù)丟失，則順序號必定是連續(xù)的。如果不連續(xù)，則說明發(fā)生丟失。對于需要重傳的流中，由于需要時(shí)間信息來決定是否需要重傳，因此必須要知道丟失的'分片的時(shí)間信息，由于I幀數(shù)據(jù)量大，通常化分成幾十上百個片，所以可以通過發(fā)現(xiàn)在同一個I幀中其他分片（它們擁有相同的流順序號）來找出丟失分片的時(shí)間信息。
a. 一個幀中的分片的丟失判斷：通過在流中重組ADU的時(shí)候來檢測，如果發(fā)現(xiàn)順序號不連續(xù)，則說明有分片丟失。這時(shí)候的重傳策略由這個幀所在的流決定。時(shí)間信息通過缺失此順序號但有相同流順序號的那些分片提供。
b. 一個幀中的開始分片的丟失判斷：通過在流中重組ADU的時(shí)候來檢測。這時(shí)通過重組ADU發(fā)現(xiàn)找不到偏移量為0的分片知道有開始分片丟失。這時(shí)候的重傳策略由這個幀所在的流決定。時(shí)間信息通過缺失此順序號的但有相同流順序號那些分片提供。
c. 一個幀中的結(jié)尾分片的丟失判斷：在重組ADU時(shí)，通過發(fā)現(xiàn)ADU長度和重組后長度不相等，但順序號是連續(xù)的，則說明一個幀中的結(jié)尾分片的丟失，時(shí)間信息通過在同一個ADU的其它分片（即：有相同流順序號的那些分片）提供。這時(shí)候的重傳策略由這個幀所在的流決定。
d. 一個幀中的所有分片丟失判斷：在重組ADU時(shí)，通過發(fā)現(xiàn)不連續(xù)的流順序號說明有一個幀中的所有分片丟失。這種情況，我們將不重傳此幀的任何數(shù)據(jù)。原因是因?yàn)镮幀數(shù)據(jù)量大，分片多，全部丟失可能性很小和重傳整個I幀代價(jià)昂貴。
4 結(jié)論語
此體系架構(gòu)已經(jīng)應(yīng)用在為重慶某集團(tuán)開發(fā)的“重大危險(xiǎn)源實(shí)時(shí)視頻監(jiān)控系統(tǒng)”中，通過實(shí)際測試，發(fā)現(xiàn)其有很好的網(wǎng)絡(luò)適應(yīng)性以及TCP友好特性，并且性能比其傳統(tǒng)的RTP/UDP有比較多的改善。
參考文獻(xiàn)
[1] Henning Schulzrinne’s RTP site,
http://www.cs.columbia.edu/~hgs/rtp/,1999
[2] M.-T. Sun and A. R. Reibman, Compressed Video Over Networks.Marcel Dekker Inc., 2001
[3] Karn,P., and C.Partridge.1987.Improving round-trip time estimates in reliable transport protocols. Presentation. SIGCOMM’87
【基于多流的重傳策略論文】相關(guān)文章：
本文來源：http://www.nvnqwx.com/shiyongwen/3061312.htm