熊永華，吳敏，賈維嘉

(1. 中南大學(xué) 信息科學(xué)與工程學(xué)院，湖南 長(zhǎng)沙，410083；2. 香港城市大學(xué) 計(jì)算機(jī)科學(xué)系，香港，999077)

傳統(tǒng)的使用 UDP(User datagram protocol)作為傳輸層協(xié)議的實(shí)時(shí)流媒體傳輸方法，具有較小的端到端延時(shí)和包頭開銷等特點(diǎn)。但由于UDP本身不具有流量控制、擁塞控制和差錯(cuò)控制機(jī)制，使用UDP進(jìn)行流媒體傳輸時(shí)通常要結(jié)合 RTP(Real-time transport protocol)、RTCP(Real-time transport control protocol)和TFRC(TCP-friendly rate control)協(xié)議一起使用，且仍需在應(yīng)用層設(shè)計(jì)差錯(cuò)控制、重傳和流量控制策略，并保證傳輸?shù)?TCP友好性，因此，實(shí)現(xiàn)和維護(hù)起來較復(fù)雜。而隨著實(shí)時(shí)流媒體在 Internet上的應(yīng)用越來越多，基于UDP的流媒體在Internet上已占用較大的帶寬，使得越來越多的路由器開始阻止基于UDP的流媒體包[1]?；诖耍^多商業(yè)的流媒體軟件如RealPlayer和Skype等直接使用TCP作為其默認(rèn)的傳輸協(xié)議[2]?；赥CP協(xié)議的實(shí)時(shí)流媒體傳輸，特別是實(shí)時(shí)視頻的傳輸，已開始受到越來越多的關(guān)注[3?12]。

1 TCP實(shí)時(shí)視頻傳輸過程

1.1 實(shí)時(shí)視頻傳輸延時(shí)分析

以滿足 H.263編碼標(biāo)準(zhǔn)的實(shí)時(shí)視頻 TCP傳輸為例，H.263編碼的視頻幀通常為103～106byte，而TCP最大報(bào)文段(MSS)通常為1 460 byte，因此，1個(gè)視頻幀往往需要分成多個(gè)子幀加載在多個(gè) TCP報(bào)文段中進(jìn)行傳輸，其中，只要有1個(gè)TCP報(bào)文段在網(wǎng)絡(luò)中丟失，接收端就必須要等到重傳了丟失的報(bào)文段，并將子幀重構(gòu)成原來的幀，才能進(jìn)行正確的解碼播放。

設(shè)1個(gè)視頻幀被分為n個(gè)TCP MSS，定義Dwait為這n個(gè)報(bào)文段在TCP發(fā)送緩沖區(qū)中等待發(fā)送所產(chǎn)生的延時(shí)，Dsend為視頻幀的第1個(gè)報(bào)文段從TCP發(fā)送緩沖區(qū)進(jìn)入網(wǎng)絡(luò)到其最后1個(gè)報(bào)文段從TCP發(fā)送緩沖區(qū)進(jìn)入網(wǎng)絡(luò)的時(shí)間間隔，Dnetwork為視頻幀從發(fā)送端網(wǎng)絡(luò)層到接收端網(wǎng)絡(luò)層的延時(shí)，視頻幀的端到端延時(shí)Dframe為視頻幀從發(fā)送端采樣生成到接收端開始播放的時(shí)間間隔，則有[7]

其中：C為常量。

采用UDP傳輸時(shí)，因其沒有流量控制和差錯(cuò)控制機(jī)制，Dwait和 Dsend可以忽略，Dframe主要取決于往返時(shí)延tRTT(Round trip time, RTT)，但是，對(duì)于TCP實(shí)時(shí)視頻傳輸，等待延時(shí) Dwait和發(fā)送延時(shí) Dsend可能較大而不能忽略(如當(dāng)網(wǎng)絡(luò)丟包時(shí))，這也是TCP視頻傳輸比UDP傳輸具有更大的端到端延時(shí)的主要原因。

1.2 影響端到端延時(shí)的關(guān)鍵因素

定義 Dframe(i)，Dwait(i)，Dsend(i)和 Dnetwork(i)分別為第i(1≤i≤n)個(gè)視頻幀的端到端延時(shí)、等待延時(shí)、發(fā)送延時(shí)和網(wǎng)絡(luò)延時(shí)，可認(rèn)為Dnetwork(i)=0.5tRTT，則根據(jù)式(1)，有：

設(shè)tP為視頻幀的采樣(或編碼)間隔時(shí)間，令

則當(dāng) A(i?1)＞0時(shí)，第 i?1個(gè)視頻幀尚未全部從 TCP發(fā)送緩沖區(qū)進(jìn)入網(wǎng)絡(luò)，而后續(xù)的第i個(gè)視頻幀已經(jīng)生成并進(jìn)入TCP發(fā)送緩沖區(qū)，因此，有 Dwait(i) = A(i ? 1 )；反之，若A(i?1)≤0，則第i個(gè)視頻幀生成時(shí)，第i?1個(gè)視頻幀已經(jīng)完成發(fā)送，第i個(gè)視頻幀不需要等待，因此，有Dwait(i)=0，即

設(shè)第 1個(gè)視頻幀進(jìn)入緩沖區(qū)時(shí)不需等待，有Dwait(1)=0，將式(3)代入式(4)，有

從式(4)可知：視頻幀的等待延時(shí)具有累積效果，取決于前一幀的等待延時(shí)和當(dāng)前幀的發(fā)送延時(shí)。而從式(5)可知：等待延時(shí)的決定因素是之前所有視頻幀的發(fā)送延時(shí)。將式(5)代入式(2)有：

由式(6)可知：使用TCP傳輸實(shí)時(shí)視頻時(shí)，等待延時(shí)是端到端延時(shí)的主要構(gòu)成部分，而發(fā)送延時(shí)又是產(chǎn)生等待延時(shí)的根本原因，因此，發(fā)送延時(shí)是影響端到端延時(shí)的關(guān)鍵因素，視頻幀的發(fā)送延時(shí)不僅決定了該視頻幀自身能否在接收端按時(shí)播放，而且影響其后續(xù)視頻幀的等待延時(shí)和端到端延時(shí)。

2 TCP實(shí)時(shí)視頻傳輸局限性

設(shè)1個(gè)視頻幀可被分為n個(gè)TCP報(bào)文段(S1～Sn)，在第i(1≤i≤n)個(gè)報(bào)文段的tRTT開始時(shí)，TCP發(fā)送窗口大小為Wi個(gè)報(bào)文段，即在第i個(gè)tRTT內(nèi)，發(fā)送端最多可以發(fā)送Wi個(gè)報(bào)文段。當(dāng)Wi＜n時(shí)，視頻幀需要多個(gè)tRTT才能完成發(fā)送，TCP實(shí)時(shí)視頻傳輸過程如圖1所示，其中，Dplayout為播放緩沖區(qū)延時(shí)。

在出現(xiàn)報(bào)文段丟失時(shí)(如圖1中S2丟失)，根據(jù)TCP Reno與TCP SACK選項(xiàng)機(jī)制，發(fā)送方收到3個(gè)以上重復(fù)確認(rèn)報(bào)文段(Duplicate acknowledgement segment,即Dup ACK)后，TCP將重傳丟失的報(bào)文段(同一窗口中丟失的報(bào)文段可能有多個(gè)，但本文以TCP Reno和TCP SACK為例，TCP SACK能1次重傳所有丟失的報(bào)文段，因此，可以只考慮1個(gè)窗口中只有1個(gè)報(bào)文段丟失重傳的情形)，同時(shí)發(fā)送數(shù)目為當(dāng)前發(fā)送窗口大小一半的新的報(bào)文段，即第i個(gè)tRTT內(nèi)丟失的報(bào)文段可以在第i+1個(gè)tRTT內(nèi)和新的報(bào)文段一起發(fā)送，例如，重傳的S2報(bào)文段可以和S6，S7和S8在同一個(gè)tRTT內(nèi)發(fā)送。設(shè)在第k個(gè)tRTT時(shí)開始發(fā)送視頻幀的最后1部分報(bào)文段(此時(shí)窗口大小為Wk)，則有：

圖1 TCP實(shí)時(shí)視頻傳輸過程示意圖Fig.1 Process of transmitting real-time video using TCP

由于最后1個(gè)報(bào)文段可能是最末尾的1個(gè)報(bào)文段，如Sn，也有可能是因丟包而重傳的報(bào)文段，如S2。當(dāng)最后1個(gè)發(fā)送窗口無丟包時(shí)，Dsend=(k?1)tRTT；而當(dāng)其有丟包時(shí)，由于需要在下1個(gè)tRTT來重傳丟失的報(bào)文，因此，Dsend=ktRTT。根據(jù)Liang等[13]的研究，結(jié)合圖1可知，只有當(dāng)

時(shí)，才能消除因?yàn)門CP重傳所帶來的延時(shí)抖動(dòng)。由式(8)可得：

即當(dāng)Dplayout為常量時(shí)，1個(gè)視頻幀的發(fā)送延時(shí)需滿足式(9)，否則，該視頻幀將錯(cuò)過其播放時(shí)間，造成嚴(yán)重的延遲抖動(dòng)，視頻播放質(zhì)量差，即TCP實(shí)時(shí)視頻幀的傳輸在滿足式(9)時(shí)才具有可接受的播放質(zhì)量，此時(shí)，使用TCP傳輸實(shí)時(shí)視頻才是可行的。

發(fā)送延時(shí)Dsend取決于tRTT以及TCP擁塞窗口的大小及變化規(guī)律，這些因素是由網(wǎng)絡(luò)丟包率與TCP協(xié)議的擁塞控制、流量控制與差錯(cuò)控制機(jī)制共同決定的。因此，在不修改 TCP協(xié)議時(shí)無法對(duì)發(fā)送延時(shí)進(jìn)行控制，但是，可以利用影響發(fā)送延時(shí)的相關(guān)參數(shù)對(duì)發(fā)送延時(shí)進(jìn)行預(yù)測(cè)。當(dāng)預(yù)測(cè)的發(fā)送延時(shí)滿足要求時(shí)，可認(rèn)為該幀具有可接受的播放性能，反之，則認(rèn)為該幀不適合采用TCP傳輸。

3 遞階式馬爾可夫預(yù)測(cè)模型

3.1 假設(shè)條件

使用 TCP Reno及其 SACK補(bǔ)充版本(為當(dāng)前Windows操作系統(tǒng)默認(rèn)以及Internet上使用最為廣泛的TCP版本)，并作如下假設(shè)：TCP發(fā)送緩沖區(qū)能夠容納多個(gè)連續(xù)的視頻幀；TCP的接收緩沖區(qū)能夠及時(shí)將所收到的數(shù)據(jù)提交給應(yīng)用層；不同往返時(shí)延周期內(nèi)的丟包事件相互獨(dú)立，而同一個(gè)往返時(shí)延周期內(nèi)，若發(fā)送窗口有報(bào)文丟失，則該窗口中該報(bào)文及其以后的報(bào)文也全部丟失；接受方廣告窗口足夠大；網(wǎng)絡(luò)中的路由器使用隨機(jī)早期丟包(RED)策略。

3.2 擁塞窗口的馬爾可夫鏈

隨機(jī)過程中，有一類過程具有“無后效性”性質(zhì)，即當(dāng)若隨機(jī)過程在某一時(shí)刻t0所處的狀態(tài)為已知時(shí)，該過程在t＞t0時(shí)所處的狀態(tài)只和t0有關(guān)，而與t0以前的狀態(tài)無關(guān)，則這種隨機(jī)過程稱為馬爾可夫過程[14]。

TCP連接建立以后，首先，經(jīng)歷短暫的慢開始階段，然后，進(jìn)入擁塞避免。當(dāng)使用RED策略時(shí)，TCP出現(xiàn)RTO(Retransmission timeout)的概率顯著減小，而且由于RED的特性，即使出現(xiàn)RTO，TCP也能夠在1個(gè) RTO周期內(nèi)迅速恢復(fù)，而不像DropTail(尾部丟包策略)那樣容易出現(xiàn)連續(xù)的多個(gè)RTO，從而出現(xiàn)持續(xù)的延時(shí)峰值。因此，在使用RED策略時(shí)，從會(huì)話過程的宏觀角度看，可忽略 TCP的慢開始階段，認(rèn)為 TCP進(jìn)入一種超時(shí)重傳、線性增加和乘法減小的理想過程，則TCP的擁塞窗口大小W隨時(shí)間的變化如圖2所示。

圖2 RED策略下TCP理想狀態(tài)窗口的變化Fig.2 Transition of TCP congestion window size under ideal state using RED strategy

定義時(shí)間的最小單位為 tRTT，即 T={tRTT,2tRTT, …}，t∈T，則W(t)是一個(gè)離散時(shí)間離散狀態(tài)的隨機(jī)過程。設(shè)Wn表示W(wǎng)(t)過程第n次狀態(tài)轉(zhuǎn)移后的擁塞窗口大小，則Wn的變化規(guī)律如下。

R1：若沒有丟包現(xiàn)象發(fā)生，則Wn+1=Wn+1；

R2：若出現(xiàn)丟包，且 TCP采用快重傳機(jī)制，則Wn+1=Wn/2；

R3：若出現(xiàn)丟包，且 TCP進(jìn)入RTO，則：對(duì)于任意Wn，有Wn+1=1。

由此可見：Wn+1的狀態(tài)僅與當(dāng)前Wn的狀態(tài)有關(guān)，而與Wn以前的狀態(tài)無關(guān)。因此，W(t)是一個(gè)離散時(shí)間離散狀態(tài)的馬爾可夫過程，而{W(t), t∈T}則是1個(gè)馬爾可夫鏈，有3種狀態(tài)：(1) 線性增加；(2) 乘法減?。?3) 退回原點(diǎn)，即減小到最小值1，其狀態(tài)轉(zhuǎn)移如圖3所示，其中，pij(i, j∈{1, 2, 3})為狀態(tài)i轉(zhuǎn)移到狀態(tài)j的概率。

圖3 TCP擁塞窗口的狀態(tài)轉(zhuǎn)移圖Fig.3 State transition chart of TCP congestion window

圖3 中的虛線表示由于丟包而引起的狀態(tài)轉(zhuǎn)移，實(shí)線則表示由于收到了所需要的 ACK而引起的狀態(tài)轉(zhuǎn)移，因此，{W(t), t∈T}的狀態(tài)轉(zhuǎn)移矩陣P[t]為3行3列方陣：

3.3 狀態(tài)轉(zhuǎn)移矩陣的求解

設(shè)初始的擁塞窗口大小為W1，網(wǎng)絡(luò)丟包率為p，則P[t]中各元素的求解如下。

p11：由線性增加狀態(tài)轉(zhuǎn)為線性增加狀態(tài)，說明窗口中沒有出現(xiàn)丟包，所有報(bào)文段均成功到達(dá)接收方，因此， p11= ( 1 ? p )W1。

p12：由線性增加狀態(tài)轉(zhuǎn)為乘法減小狀態(tài)，即TCP在有丟包情況下，通過收到3次重復(fù)ACK方式進(jìn)入重傳與恢復(fù)階段概率。TCP通過2種方式判斷是否進(jìn)入重傳與恢復(fù)階段：1) 收到3個(gè)以上的ACK；2) 出現(xiàn)重傳計(jì)時(shí)器超時(shí)。

設(shè)通過方式1和方式2進(jìn)入重傳與恢復(fù)階段的概率分別為pACK和pRTO，則

因此，有：

p13：由線性增加狀態(tài)轉(zhuǎn)為退回原點(diǎn)狀態(tài)，即TCP在有丟包情況下，通過RTO方式進(jìn)入重傳與恢復(fù)階段的概率，有：

p21：由乘法減小狀態(tài)轉(zhuǎn)為線性增加狀態(tài)，窗口中沒有出現(xiàn)丟包，因此，有：

p22和 p23：由乘法減小狀態(tài)轉(zhuǎn)為乘法減小狀態(tài)，TCP收到3次重復(fù)ACK后即進(jìn)入重傳與恢復(fù)階段，而與其先前的狀態(tài)無關(guān)，因此，p22=p12。同理，有p23=p13。

p31，p32和p33：TCP經(jīng)過RTO后，窗口為1個(gè)報(bào)文段大小。在使用RED策略時(shí)，處于RTO的TCP不可能再出現(xiàn)報(bào)文段丟失，或者是收到重復(fù)ACK，因此，p32=0，p33=0，可認(rèn)為 TCP將進(jìn)入線性增加狀態(tài)，即p31=1。

為此，狀態(tài)轉(zhuǎn)移矩陣為：

其中，初始的擁塞窗口大小W1和網(wǎng)絡(luò)丟包率p為已知參數(shù)；pACK和pRTO為未知參數(shù)。

3.4 未知參數(shù)的求解

設(shè)TCP傳輸完S個(gè)報(bào)文段以后沒有出現(xiàn)丟包，則出現(xiàn)該現(xiàn)象的概率為(1?p)S，因此，在傳輸 S個(gè)報(bào)文期間至少出現(xiàn)1個(gè)丟包現(xiàn)象，即TCP進(jìn)入重傳與恢復(fù)階段的概率為1?(1?p)S。 圖4所示為丟包發(fā)生時(shí)，TCP報(bào)文段與ACK的傳輸過程以及重復(fù)ACK和RTO出現(xiàn)的情形。

圖4 TCP出現(xiàn)重復(fù)ACK與RTO的過程分析示意圖Fig.4 Schematic diagram of process analysis of occurrence of duplicated ACK and RTO of TCP

圖4 中，在tRTT(x)內(nèi)，TCP擁塞窗口大小為W個(gè)報(bào)文段，即S1～SW，其中，有k個(gè)報(bào)文段即S1～Sk成功到達(dá)對(duì)方，而Sk+1～SW個(gè)報(bào)文段丟失。因此，在tRTT(x)結(jié)束時(shí)，TCP收到了S1～Sk報(bào)文段的ACK。

若收到3次以上重復(fù)的ACK，則此時(shí)TCP通過方式1進(jìn)入重傳與恢復(fù)階段；若只有0～2次重復(fù)ACK，則由于已經(jīng)收到對(duì) k個(gè)報(bào)文段的 ACK，因此，在tRTT(x+1)內(nèi)，TCP將繼續(xù)發(fā)送k個(gè)報(bào)文段。

對(duì)于這k個(gè)報(bào)文段，設(shè)前m個(gè)報(bào)文段已被成功發(fā)送，由于在tRTT(x)內(nèi)的第k+1個(gè)報(bào)文段一直沒有被確認(rèn)收到，因此，對(duì)于這m個(gè)報(bào)文段的ACK應(yīng)該是針對(duì)tRTT(x)內(nèi)的第k+1個(gè)報(bào)文段的重復(fù)ACK，由于此時(shí)沒有延時(shí)ACK發(fā)生，tRTT(x+1)內(nèi)收到的重復(fù)ACK個(gè)數(shù)等于成功發(fā)送的報(bào)文段的個(gè)數(shù)，即重復(fù) ACK的個(gè)數(shù)為m，若m≥3，即收到了3次以上重復(fù)ACK，則TCP仍通過方式1進(jìn)入重傳與恢復(fù)階段；而若m＜3，則表明網(wǎng)絡(luò)擁塞嚴(yán)重，TCP將通過方式2進(jìn)入重傳與恢復(fù)階段。

定義A(W, k)為在tRTT(x)內(nèi)，窗口為W個(gè)報(bào)文段時(shí)收到其中k個(gè)報(bào)文段的ACK的概率，則根據(jù)條件概率的定義，有[15]：

定義B(n, m)為在tRTT(x+1)內(nèi)，有n個(gè)報(bào)文段被發(fā)送，并收到其中m個(gè)報(bào)文段的ACK的概率，則有：

因此，當(dāng)W＜3時(shí)，若在tRTT(x)內(nèi)TCP出現(xiàn)丟包，則由于收到的重復(fù)ACK個(gè)數(shù)不足3個(gè)，將出現(xiàn)RTO現(xiàn)象；當(dāng)k≤2時(shí)，在tRTT(x+1)內(nèi)發(fā)送的報(bào)文段不超過3個(gè)，因此，若在 tRTT(x+1)內(nèi)出現(xiàn)丟包，則收到的重復(fù)ACK最多也不足3個(gè)，有可能出現(xiàn)RTO；當(dāng)k＞2時(shí)，若在tRTT(x+1)內(nèi)成功傳輸?shù)膱?bào)文段數(shù)目不足3個(gè)，則TCP也有可能出現(xiàn) RTO。綜合以上 3種情況，可得TCP通過方式2進(jìn)入重傳與恢復(fù)階段的概率為：

RTO是對(duì) TCP流量波動(dòng)及延時(shí)影響最為嚴(yán)重的因素，出現(xiàn)RTO時(shí)，TCP的擁塞窗口將直接降低到最小值(通常為1)，且產(chǎn)生至少為4tRTT的額外延時(shí)，因此，應(yīng)避免發(fā)生RTO。由式(10)得到TCP通過方式1進(jìn)入重傳與恢復(fù)階段的概率為：

3.5 遞階式馬爾可夫預(yù)測(cè)算法

當(dāng)初始狀態(tài)為狀態(tài)1時(shí)，經(jīng)過1步轉(zhuǎn)移后，初始擁塞窗口W=W1的變化規(guī)律為：對(duì)于p11，有W=W1+1；對(duì)于p12，有W=W1/2；對(duì)于p13，有W=1。

當(dāng)初始狀態(tài)為狀態(tài)2時(shí)，經(jīng)過1步轉(zhuǎn)移后，窗口變化規(guī)律為：對(duì)于 p21，有 W=W1+1；對(duì)于 p22，有W=W1/2；對(duì)于p23，有W=1。

當(dāng)初始狀態(tài)為狀態(tài)3時(shí)，此時(shí)，有W1=1，經(jīng)過1步轉(zhuǎn)移后，窗口變化規(guī)律為：對(duì)于 p31，有 W=2；對(duì)于p32和p33，由于p32=p33=0，因此，可忽略。

經(jīng)過1步轉(zhuǎn)移后，擁塞窗口大小的增益矩陣R[t]為：

由于p32=p33=0，可忽略增益矩陣的R32和R33，因此，在狀態(tài)i∈{1, 2, 3}和此時(shí)的擁塞窗口大小Wi=W1時(shí)，經(jīng)過1個(gè)往返時(shí)延周期，狀態(tài)i經(jīng)過1步轉(zhuǎn)移為狀態(tài)i+1。TCP在i+1狀態(tài)下，即在下一個(gè)往返時(shí)延周期開始時(shí)，擁塞窗口大小的期望值E[Wi+1]為：

視頻幀發(fā)送延時(shí)預(yù)測(cè)算法的目的在于：當(dāng)視頻幀被發(fā)送以前，預(yù)測(cè)其經(jīng)過多少個(gè)往返時(shí)延周期才能完成發(fā)送。采用馬爾可夫理論預(yù)測(cè)發(fā)送延時(shí)，從宏觀的角度考慮整個(gè)TCP傳輸過程中擁塞窗口的變化規(guī)律，其核心思想在于：已知當(dāng)前窗口大小和狀態(tài)，利用狀態(tài)轉(zhuǎn)移矩陣和增益矩陣，預(yù)測(cè)經(jīng)過1步轉(zhuǎn)移以后，下一個(gè)周期擁塞窗口大小的期望值，再將該預(yù)測(cè)值作為初始窗口大小，并輸入狀態(tài)轉(zhuǎn)移矩陣和增益矩陣進(jìn)行遞階運(yùn)算，從而預(yù)測(cè)再下一個(gè)周期的擁塞窗口大小。

在視頻幀發(fā)送以前，設(shè)當(dāng)前的馬爾可夫鏈{W(t), t∈T}狀態(tài)為i，擁塞窗口大小為Wi，則在式(11)和式(17)中，令W1=Wi，得到：

為得到下一個(gè)狀態(tài)(即 i+1)時(shí)擁塞窗口的期望值E[Wi+1]，根據(jù)式(18)可知，需要確認(rèn)馬爾可夫鏈{W(t),t∈T}所處的初始狀態(tài) i，考慮式(18)中初始狀態(tài)為狀態(tài)1和狀態(tài)2時(shí)，經(jīng)過1步轉(zhuǎn)移以后具有相同的增益，因此，只需通過擁塞窗口大小是否為1來判斷馬爾可夫鏈?zhǔn)欠裉幱跔顟B(tài)3即可，具體的遞階式馬爾可夫發(fā)送延時(shí)預(yù)測(cè)算法如下。

Step 1：初始化遞階次數(shù)x=1；

Step 2：if Wi=1，則 i=3，if Wi＞S(S為視頻幀的長(zhǎng)度)，則x=1，進(jìn)入Step 4；if Wi＞1，則 i=1 或 i=2，

Step 3：if Wi+ E [Wi+1]＜S，則x=x+1；if x＜10 Wi= E[Wi+1]，返回到Step 2；if x＞9，進(jìn)入Step 4；if Wi+ E [Wi+1]≥S，進(jìn)入Step 4；

Step 4： E [Dsend]=x?tRTT，算法結(jié)束。

算法首次將馬爾可夫方法運(yùn)用于視頻幀的延時(shí)預(yù)測(cè)，并對(duì)常用的馬爾可夫預(yù)測(cè)方法進(jìn)行了改進(jìn)，以 1次狀態(tài)轉(zhuǎn)移后的預(yù)測(cè)值作為輸入條件進(jìn)行遞階式預(yù)測(cè)，并以預(yù)測(cè)值之和大于實(shí)時(shí)視頻幀為遞階結(jié)束條件。

4 模擬結(jié)果及分析

采用NS2對(duì)發(fā)送延時(shí)性能和預(yù)測(cè)模型進(jìn)行驗(yàn)證與分析，其模擬環(huán)境拓?fù)浣Y(jié)構(gòu)如圖5所示。

圖5 NS2模擬環(huán)境的拓?fù)浣Y(jié)構(gòu)Fig.5 Topology of NS2 simulator circumstance

TCP發(fā)送端與接收端分別與路由器R1和R2連接，設(shè)置路由器 R1隊(duì)列長(zhǎng)度為 50，鏈路最小 tRTT=60 ms，最大報(bào)文段為1 000 byte。發(fā)送端輸入一個(gè)自定義的視頻流量(Video traffic)，該流量來自于基于H.263標(biāo)準(zhǔn)的視頻追蹤(Video trace)文件[16]。Video trace文件由一段H.263編碼的視頻生成，主要記錄了視頻幀及其發(fā)送時(shí)間。視頻幀編碼間隔tP=200 ms，網(wǎng)絡(luò)往返時(shí)延tRTT=60 ms，播放緩沖區(qū)延時(shí)Dplayout=400 ms，設(shè)置丟包率分別為p=0和p=3%進(jìn)行模擬實(shí)驗(yàn)。圖6～8所示為遞階式馬爾可夫預(yù)測(cè)模型的模擬結(jié)果。

p為0時(shí)的馬爾可夫預(yù)測(cè)模型實(shí)驗(yàn)結(jié)果如圖6所示，p為3%時(shí)使用RED的馬爾可夫預(yù)測(cè)模型實(shí)驗(yàn)結(jié)果如圖7所示。由圖6可見：p=0，遞階式馬爾可夫預(yù)測(cè)判斷的準(zhǔn)確程度為100%。由圖7可見：p=3%，采用RED策略，實(shí)際值的波動(dòng)范圍較小，而預(yù)測(cè)值的波動(dòng)也較平穩(wěn)。通過實(shí)際值Dsend判斷不合要求的視頻幀有5個(gè)，編號(hào)集為Areal(40，42，73，75，91)；通過預(yù)測(cè)值E[Dsend]判斷不符合條件的視頻幀有6個(gè)，編號(hào)集為Apre(40，41，42，73，74，75)，因此，漏掉了1個(gè)不合要求的幀(91)。將 2個(gè)符合要求的幀(41，74)判斷為不合要求，即預(yù)測(cè)判斷的漏判率為 1%，準(zhǔn)確程度為97%。

p為3%時(shí)，使用DropTail的馬爾可夫預(yù)測(cè)模型實(shí)驗(yàn)結(jié)果見圖8。由圖8可見：p=3%，丟包策略為Drop Tail，Areal有20幀，Apre有8幀；其中：6幀在Areal中，漏掉了14個(gè)不符合要求的幀，并將2個(gè)符合要求的幀判為不合格。因此，預(yù)測(cè)判斷漏判率為14%，準(zhǔn)確程度為84%。

圖6 p=0時(shí)馬爾可夫預(yù)測(cè)模型結(jié)果Fig.6 Results of predicting while p=0 using Markov model

圖7 p=3%時(shí)使用RED的馬爾可夫預(yù)測(cè)模型結(jié)果Fig.7 Results of predicting while p=3% using Markov model and RED strategy

圖8 p=3%時(shí)使用DropTail的馬爾可夫預(yù)測(cè)模型結(jié)果Fig.8 Results of predicting while p=3% using Markov model and DropTail strategy

模擬實(shí)驗(yàn)結(jié)果表明：使用馬爾可夫預(yù)測(cè)模型，在路由器為DropTail丟包策略時(shí)，其漏判率約為14%，判斷的精度約為85%；在路由器為RED丟包策略時(shí)，其漏判率為1%，判斷精度可達(dá)97%。

馬爾可夫預(yù)測(cè)方法忽略了 TCP在慢開始時(shí)窗口指數(shù)的增加以及TCP經(jīng)過RTO階段的重傳與恢復(fù)以后又回到慢開始起點(diǎn)的過程，從而將TCP窗口變化近似看為一種理想化的線性增加和乘法減少狀態(tài)，這使得馬爾可夫方法對(duì)于頻繁出現(xiàn) RTO與慢開始的傳輸過程具有較低的預(yù)測(cè)判斷精度。而對(duì)于線性增加和乘法減少的 TCP快重傳、快恢復(fù)過程則具有較高的精度，因此，馬爾可夫方式更加適合于RED策略。

可見，當(dāng)網(wǎng)絡(luò)路由器采取RED丟包策略時(shí)，可以通過馬爾可夫預(yù)測(cè)模型的預(yù)測(cè)值來判斷視頻幀是否適合采用 TCP傳輸，此時(shí)，預(yù)測(cè)值可以作為制定 TCP實(shí)時(shí)視頻傳輸策略的重要因素。

5 結(jié)論

(1) 分析了使用 TCP傳輸實(shí)時(shí)視頻時(shí)端到端延時(shí)的組成部分，推導(dǎo)出發(fā)送延時(shí)是影響端到端延時(shí)的關(guān)鍵因素。

(2) 建立了一個(gè)遞階式馬爾可夫預(yù)測(cè)模型對(duì)發(fā)送延時(shí)進(jìn)行預(yù)測(cè)，并用于判斷視頻幀是否符合TCP傳輸?shù)臈l件。該模型對(duì)于DropTail和RED策略的預(yù)測(cè)判斷精度分別為84%和97%，適用于延時(shí)波動(dòng)范圍較小的RED策略。

[1]XIONG Yong-hua, WU Min, JIA Wei-jia. Delay prediction for real-time video adaptive transmission over TCP[J]. Journal of Multimedia, 2010, 5(3): 216?223.

[2]WANG Bin, Kurose J, Shenoy P, et al. Multimedia streaming via TCP: An analytic performance study[J]. ACM Trans on Multimedia Computing, Communications, and Applications,2008, 4(2): 1?8.

[3]Jammeh E A, Fleury M, Ghanbari M. Rate-adaptive video streaming through packet dispersion feedback[J]. IEEE Transanctions on Communications, 2009, 3(1): 25?37.

[4]Tullimas S, Nguyen T, Edgecomb R, et al. Multimedia streaming using multiple TCP connections[J]. ACM Transactions on Multimedia Computing, Communications, and Applications,2008, (4): 1?20.

[5]Evensen K, Petlund A, Griwodz C, et al. Redundant bundling in TCP to reduce perceived latency for time-dependent thin streams[J]. IEEE Communications Letters, 2008, 12(4):324?326.

[6]Kaner R P. TCP prediction for adaptive applications[C]//Proceeding of 32nd IEEE Conference on Local Computer Networks. Washington DC: IEEE Computer Society, 2007:989?996.

[7]XIONG Yong-hua, WU Min, JIA Wei-jia. Efficient frame schedule scheme for real-time video transmission across the Internet using TCP[J]. Journal of Networks, 2009, 4(3):216?223.

[8]Mehra P, Vleesc D E. Receiver-driven bandwidth sharing for TCP and its application to video streaming[J]. IEEE Trans on Multimedia, 2005, 7(4): 740?752.

[9]孫為, 王偉. 大數(shù)據(jù)量TCP友好視頻流傳輸擁塞控制研究[J].蘭州理工大學(xué)學(xué)報(bào), 2007, 33(2): 104?107.SUN Wei, WANG Wei. Investigation of transmission congestion control of TCP-friendly video-stream with large data-amount[J].Journal of Lanzhou University of Technology, 2007, 33(2):104?107.

[10]桑歡, 顏金堯. 面向 TCP的流媒體緩存技術(shù)的研究[J]. 中國(guó)傳媒大學(xué)學(xué)報(bào): 自然科學(xué)版, 2009, 16(1): 41?46.SANG Huan, YAN Jin-yao. Research on buffer sizing for media streaming over TCP[J]. Journal of Communication University of China: Science and Technology, 2009, 16(1): 41?46.

[11]劉夢(mèng)娟. 異構(gòu)網(wǎng)絡(luò)環(huán)境下流媒體傳輸機(jī)制的研究[D]. 合肥:中國(guó)科學(xué)技術(shù)大學(xué)信息科學(xué)技術(shù)學(xué)院, 2007: 3?24.LIU Meng-juan. Researching on streaming transmission method over heterogeneous network[D]. Hefei: University of Science and Technology of China. School of Information Science and Technology, 2007: 3?24.

[12]熊永華, 吳敏, 賈維嘉. 實(shí)時(shí)流媒體傳輸技術(shù)研究綜述[J]. 計(jì)算機(jī)應(yīng)用研究, 2009, 26(10): 3615?3620.XIONG Yong-hua, WU Min, JIA Wei-jia. Survey on Real-time multimedia streaming transmission technology[J]. Application Research on Computers, 2009, 26(10): 3615?3620.

[13]Liang S, Cheriton D. TCP-RTM: Using TCP for real time multimedia applications[C]//Proceeding of IEEE International Conference on Network Protocols. Washington DC: IEEE Computer Society, 2002: 1?20.

[14]林元烈. 應(yīng)用隨機(jī)過程[M]. 北京: 清華大學(xué)出版社, 2002:44?65.LIN Yuan-lie. Application stochastic process[M]. Beijing:Tsinghua University Press, 2002: 44?65.

[15]Padhye J, Firoiu V, Towsley D, et al. Modeling TCP Reno performance: a simple model and its empirical validation[J].IEEE/ACM Transactions on Networking, 2000, 8(2): 133?145.

[16]Fitzek F H P, Reisslein M. MPEG-4 and H.263 video traces for network performance evaluation[J]. IEEE Network, 2001, 15(4):40?54.