辛永輝，李 楊，林 濤

（中國科學(xué)院聲學(xué)研究所 北京 100190）

1 引言

當(dāng)今互聯(lián)網(wǎng)經(jīng)歷著從面向主機(jī)的點(diǎn)到點(diǎn)通信模式到以內(nèi)容為中心的通信模式的轉(zhuǎn)變，與內(nèi)容位置相比，客戶更關(guān)心的是內(nèi)容本身。為了適應(yīng)互聯(lián)網(wǎng)的這一改變，業(yè)界提出了以ICN（information-centric networking,信息中心網(wǎng)絡(luò)）[1]為代表的下一代網(wǎng)絡(luò)，該網(wǎng)絡(luò)架構(gòu)中的路由器具有緩存功能，以便后續(xù)為具有相同內(nèi)容的請求提供服務(wù)。

目前多媒體業(yè)務(wù)，尤其是視頻業(yè)務(wù)在整個互聯(lián)網(wǎng)的數(shù)據(jù)流量中正占據(jù)越來越大的比重。研究顯示，到2016年，視頻內(nèi)容將占據(jù)全球移動數(shù)據(jù)流量的55%以上[2]。基于HTTP的動態(tài)自適應(yīng)流媒體 （dynamic adaptive streaming over HTTP，DASH）因具有部署簡單、不受防火墻影響等優(yōu)點(diǎn)而受到廣泛關(guān)注[3]。碼率自適應(yīng)是DASH的重要特點(diǎn)之一，但選擇合適的碼率自適應(yīng)算法仍然是其研究的熱點(diǎn)和重點(diǎn)。參考文獻(xiàn)[4]提出了一種基于段抵達(dá)時間（segmentfetch time）的碼率自適應(yīng)標(biāo)準(zhǔn)（SFTM），參考文獻(xiàn)[5]也給出了兩階段式的自適應(yīng)算法，它們都能有效地改善客戶的觀看體驗(yàn)。但簡單地將傳統(tǒng)的基于端到端的自適應(yīng)算法移植到ICN中會出現(xiàn)一些問題，如參考文獻(xiàn)[6]中所示DASC（DASH over CCN）。具體來講，ICN的緩存會造成傳統(tǒng)方法對網(wǎng)速的誤判，導(dǎo)致客戶端緩沖區(qū)下溢甚至中斷，需要盡早判斷下載速度提升的原因并及時進(jìn)行處理。

本文提出了一種基于預(yù)估和中斷機(jī)制的動態(tài)自適應(yīng)流媒體算法。該算法在下一片段碼率的選取上，可以使用現(xiàn)有的任何自適應(yīng)算法，區(qū)別在于若在預(yù)估的時間內(nèi)該碼率的文件沒有下載完成，就意味著碼率過高，應(yīng)該立即中斷該碼率的下載，并對碼率進(jìn)行下調(diào)，重新發(fā)出下載請求，這樣可以盡早知道是否對網(wǎng)速進(jìn)行了誤判并進(jìn)行下一步處理。

2 DASH在ICN應(yīng)用的問題

本文在現(xiàn)有的ICN傳輸機(jī)制[7]的基礎(chǔ)上，通過修改DASH的VLC播放器的插件[8]，添加自適應(yīng)流媒體算法。這里先簡述ICN的傳輸機(jī)制和MPEG-DASH中媒體文件的自適應(yīng)算法，然后在此基礎(chǔ)上分析傳統(tǒng)自適應(yīng)算法在ICN應(yīng)用中出現(xiàn)的問題。

2.1 ICN傳輸機(jī)制

ICN架構(gòu)主要由具有緩存功能的ICN節(jié)點(diǎn)組成，這些節(jié)點(diǎn)也稱為ICN路由器，具有路由和緩存兩大功能，以目前備受關(guān)注的內(nèi)容中心網(wǎng)絡(luò)（content centric network，CCN）為例[9]。內(nèi)容的獲取采用客戶端驅(qū)動模式，網(wǎng)絡(luò)中主要有兩種數(shù)據(jù)：興趣（Interest）分組以及內(nèi)容（Data）分組，格式如圖1所示?？蛻粝蜞徑穆酚善鞴?jié)點(diǎn)發(fā)出興趣分組，若該路由器緩存中有對應(yīng)的內(nèi)容，則返回內(nèi)容分組；若沒有緩存，就按照一定的路由機(jī)制向外轉(zhuǎn)發(fā)該興趣分組，若收到數(shù)據(jù)分組則原路返回該數(shù)據(jù)。

圖1 ICN中的數(shù)據(jù)分組類型

2.2 MPEG-DASH基本模型

MPEG-DASH是一個基于HTTP的動態(tài)自適應(yīng)流媒體標(biāo)準(zhǔn)，具有簡單易用、適應(yīng)多種網(wǎng)絡(luò)環(huán)境、無需特殊代理等優(yōu)點(diǎn)。在實(shí)現(xiàn)中，媒體文件被分隔成若干個小片，并根據(jù)需要進(jìn)行N種格式的編碼，記錄在XML格式的索引文件MPD（media presentation description）中?？蛻魴C(jī)要根據(jù)MPD文件向服務(wù)器發(fā)出請求，本文假設(shè)客戶端均已獲取MPD文件。

（1）MPEG-DASH中客戶機(jī)與服務(wù)器的交互

分片文件存儲在服務(wù)器上，客戶端通過探查網(wǎng)絡(luò)可用帶寬并使用HTTP請求最優(yōu)的碼率文件，分片下載完成后，客戶端就可以順序播放。由于分片之間相互獨(dú)立，沒有間隔與重疊，故而可以平滑播放。當(dāng)網(wǎng)絡(luò)帶寬動態(tài)變化時，客戶端采用自適應(yīng)算法調(diào)整即將請求的碼率文件來實(shí)現(xiàn)“自適應(yīng)”。DASH客戶端和服務(wù)器的簡單交互流程如圖2所示，具體介紹如下。

圖2 DASH客戶端和服務(wù)器的簡單交互流程

步驟1客戶端根據(jù)已獲得的MPD文件，發(fā)出對該視頻分片為S1、碼率為R1的請求req1，服務(wù)器通過rep1響應(yīng)給客戶端該文件。

步驟2 客戶端收到rep1后，根據(jù)MPD文件，發(fā)出對分片為S2、碼率為R2的請求req2，服務(wù)器做出相應(yīng)回應(yīng)。

步驟3 客戶端收到rep2后，繼續(xù)發(fā)出對片段為Sk、碼率為Rk的請求req k，然后收到服務(wù)器回復(fù)的rep k，如此下去，直至觀看結(jié)束或終止。

（2）傳統(tǒng)的自適應(yīng)算法舉例

Liu Y N等人在參考文獻(xiàn)[6]中實(shí)現(xiàn)了MPEG-DASH在CCN中的原型，并采用rate-based自適應(yīng)策略，即根據(jù)前一片段的下載速度估算整條鏈路的帶寬，再從MPD文件中選取低于該估算帶寬的最大碼率進(jìn)行下載。

假定分片的時長都為τ，碼率為Rk的片段Sk請求開始的時間為，其中0，下載結(jié)束的時間為，則片段Sk的下載速度為片段Sk+1的請求碼率Rk+1為MPD文件的碼率集中低于VRk的最大碼率。為保證較快的啟動時延，第一片的請求碼率為MPD文件中的最低碼率Rmin。

Miller K等人在參考文獻(xiàn)[5]中提出了基于HTTP自適應(yīng)流媒體的自適應(yīng) （adaptation adaptive streaming over HTTP，HAS）算法，該算法分為快速啟動和正常狀態(tài)兩個階段，不同的階段中下一片碼率的選取、開始下載的時延需要根據(jù)最近一段時間t內(nèi)下載的n個完整片段的平均速度以及當(dāng)時整個緩沖區(qū)的長度而定。該算法為了保證碼率調(diào)節(jié)的穩(wěn)定性，設(shè)置了不同的調(diào)節(jié)系數(shù) α1,α2,…,α5，以確保穩(wěn)步調(diào)節(jié)，減少碼率的變動次數(shù)來提高客戶的視覺體驗(yàn)。為保證快速啟動，第一片段的請求碼率也是MPD文件中的Rmin。

2.3 問題分析

rate-based自適應(yīng)策略只是簡單地根據(jù)前一片段文件的下載速度，確定下一片段的請求碼率，該方法能充分利用帶寬，緊跟網(wǎng)絡(luò)變化并做出調(diào)整，但當(dāng)中間節(jié)點(diǎn)具有緩存功能時，該算法自然會將緩存節(jié)點(diǎn)的下載網(wǎng)速誤認(rèn)為整條鏈路的網(wǎng)速，導(dǎo)致發(fā)出對過高碼率片段的請求并長時間等待，這種現(xiàn)象根據(jù)緩存節(jié)點(diǎn)緩存內(nèi)容的不同發(fā)生的次數(shù)也不同。如圖3所示，假設(shè)該視頻的碼率集為R={100 kbit/s,200 kbit/s,300 kbit/s,…,900 kbit/s,1 000 kbit/s}，客戶端到ICN路由器的局域網(wǎng)帶寬為B1=1 000 kbit/s，ICN路由器到視頻服務(wù)器的外網(wǎng)帶寬B2=250 kbit/s。

客戶第一次觀看該視頻，請求最小碼率為100 kbit/s的S1，下載時間為1 s，測得的網(wǎng)速為 200 kbit/s，于是請求碼率為200 kbit/s的S2。經(jīng)過一段足夠長的時間t，ICN路由器會緩存 S1：100 kbit/s、S2～S10：200 kbit/s的文件；客戶第二次觀看時，依然請求100 kbit/s的S1，由于ICN路由器的緩存，客戶端很快收到回復(fù)，測得下載速度為1 000 kbit/s，于是請求1 000 kbit/s的S2，但I(xiàn)CN路由器沒有緩存該文件，于是向服務(wù)器轉(zhuǎn)發(fā)，客戶端會在發(fā)出請求后10 s左右完成下載，測得的網(wǎng)速又變?yōu)?00 kbit/s，繼而請求200 kbit/s的S3，如此進(jìn)行下去。其中，客戶端獲得的碼率一直在200 kbit/s和1 000 kbit/s中跳變，客戶觀看效果很差；同時下載1 000 kbit/s將會耗時10 s左右，這段時間內(nèi)播放器很可能由于緩沖區(qū)下溢導(dǎo)致播放中斷。

HAS算法使用兩階段法，能較好地對網(wǎng)絡(luò)變化做出穩(wěn)步調(diào)整，但步驟比較繁瑣，涉及的調(diào)節(jié)系數(shù)較多，而且是根據(jù)經(jīng)驗(yàn)設(shè)定。在快速啟動階段，選擇低碼率快速填充緩沖區(qū)，網(wǎng)速誤判影響較小，但在正常階段，面對有緩存的網(wǎng)絡(luò)也暴露出同樣的缺點(diǎn)，對于帶寬誤判只能長時間地等待。如圖4所示，同一個視頻被請求多次后在ICN路由器中可能緩存有多種碼率，當(dāng)客戶端執(zhí)行HAS自適應(yīng)策略后，經(jīng)過一段時間t發(fā)出對1 000 kbit/s片段S10的請求，而ICN路由器緩存的只有900 kbit/s的S10，沒緩存1 000 kbit/s，ICN路由器不得不向外網(wǎng)轉(zhuǎn)發(fā)，客戶端也因此被迫等待10 s左右，在此期間播放器的緩沖區(qū)有可能因耗盡導(dǎo)致播放中斷。

3 ICN中的動態(tài)自適應(yīng)算法

3.1 DASC架構(gòu)和網(wǎng)絡(luò)拓?fù)?/h3>

本文在DASC系統(tǒng)基礎(chǔ)上提出適用于ICN的自適應(yīng)流媒體算法[7]。因?yàn)镮CN還處于研究階段，如果能夠融合DASH應(yīng)用對于其發(fā)展有重要意義。圖5展示了DASC的架構(gòu)，其中有陰影的代表原有的DASH模型，無陰影的表示CCN或者ICN部分。

圖3 rate-based自適應(yīng)策略示例

圖4 HAS自適應(yīng)算法示例

圖5 DASC的架構(gòu)

3.2 ICN中的自適應(yīng)算法

傳統(tǒng)的自適應(yīng)算法是基于下載的速度來估算當(dāng)前的網(wǎng)速，在逐跳模式并且具有緩存的ICN中直接照搬極易誤判網(wǎng)絡(luò)帶寬，從而引發(fā)一系列問題，為了盡量避免此問題，同時也盡可能地利用網(wǎng)絡(luò)資源，提出了ICN中的動態(tài)自適應(yīng)算法。

為了充分利用信道帶寬并保證客戶觀看視頻的流暢性和高質(zhì)量，本文提出的自適應(yīng)算法遵循以下4個原則：

·盡量避免播放中斷；

·在帶寬允許的情況下盡量提供高質(zhì)量的視頻片段，即平均視頻質(zhì)量和最小視頻質(zhì)量盡量大；

·盡量使視頻切換次數(shù)少，因?yàn)閺目蛻趔w驗(yàn)出發(fā)，一直保持在低碼率的視頻比在高低碼率間不斷變化的視頻帶來的觀看體驗(yàn)要好；

·啟動時延要小，即從客戶選擇播放某個視頻到該視頻第一個切片開始播放的時間要盡量短。

在這4個標(biāo)準(zhǔn)中，第1個標(biāo)準(zhǔn)應(yīng)該具有最高的優(yōu)先級，因?yàn)樵斐煽蛻趔w驗(yàn)最差的是視頻播放的停滯或中斷，也就意味著為了保證客戶端視頻質(zhì)量的流暢性，在一定程度上可以犧牲視頻的質(zhì)量。第2個和第3個標(biāo)準(zhǔn)需要進(jìn)行權(quán)衡，充分利用帶寬的最好方法是選擇目前網(wǎng)絡(luò)支持的最高碼率的視頻，但在變化的網(wǎng)絡(luò)中這會使得視頻的切換次數(shù)大幅增加。同時第2個和第4個標(biāo)準(zhǔn)也需要進(jìn)行折中，因?yàn)橐档蛦訒r延就要求客戶端下載第一個視頻切片的時間最短，這樣第一次只能請求最低的碼率，在一定程度上造成了帶寬的浪費(fèi)，最終的判決過程是在這4個標(biāo)準(zhǔn)中權(quán)衡選擇。

具體的自適應(yīng)算法流程如圖6所示，表1對涉及的主要符號進(jìn)行了說明。

步驟1 開始時t=0，k=1，為保證最小啟動時延，請求第一片段S1的最小碼率R1=Rmin，并等待第S1_R1下載完。

步驟2 下載完Sk后，k=k+1，可以計算出下載的網(wǎng)速根據(jù)某種自適應(yīng)算法（可以是RB 或者 HAS等）得出 Rk，預(yù)估下載 Sk的時間 PTk=α·Rk·τ/V(k-1,n)。

步驟3 發(fā)出對Sk的請求，同時設(shè)定倒計時計時器Tck=PTk，Sk下載完成或Tck=0時中斷計時。

步驟4 計時中斷時若Tck>0，說明可以進(jìn)行下一片段的請求；否則說明未及時得到Sk_Rk，為了防止長時間不必要的等待，需要提前下調(diào)待請求Sk的碼率。

步驟5下調(diào)Sk的碼率可以分步進(jìn)行，先下調(diào)到較小的 Rk’，然后請求 Sk_Rk’，若 Sk第二次發(fā)生中斷，則需要立即下載到最低碼率Rk=Rmin。

圖6 ICN中動態(tài)自適應(yīng)算法流程

表1 主要符號

該算法對獲取下一片碼率的算法沒有限制，可以是傳統(tǒng)的任意自適應(yīng)算法，如rate-based或者HAS，但在后續(xù)過程中新引入了預(yù)判中斷機(jī)制和分步下調(diào)方法。具體如下。

（1）預(yù)判中斷機(jī)制

當(dāng)已知前n個片段的下載速度時，可以通過某種自適應(yīng)算法給出即將下載片段Sk的碼率Rk。這種基于下載的方式估算鏈路帶寬的方法避免不了對網(wǎng)速的誤判，尤其是當(dāng)網(wǎng)絡(luò)中有緩存節(jié)點(diǎn)時。假設(shè)算出的下載速度為V(k,n)，根據(jù)自適應(yīng)算法得到的分片碼率為Rk，已知分片時長τ、片段Sk的預(yù)估下載時間。發(fā)出對該碼率的請求后，考慮到網(wǎng)絡(luò)的未知性，認(rèn)為若能在預(yù)估時間內(nèi)下載完成，說明網(wǎng)絡(luò)鏈路跟預(yù)期接近，否則意味著鏈路狀況比預(yù)期的糟糕，或由于網(wǎng)絡(luò)中間節(jié)點(diǎn)沒緩存該高碼率片段。為了防止長時間的等待，提前終止該請求并開始對該片段的低碼率文件發(fā)出請求或許更有意義。

（2）分步下調(diào)方法

中斷后，應(yīng)該請求該片段低碼率的文件，但關(guān)于較低碼率的設(shè)定和下調(diào)的次數(shù)沒做具體的限定?？紤]到客戶觀看視頻的連續(xù)性，即客戶看完某個視頻的片段Sk，很有可能也看了片段Sk+1，這樣網(wǎng)絡(luò)中緩存片段Sk+1的可能性非常大；同樣考慮到網(wǎng)絡(luò)緩存的影響，對于同一個視頻，后請求的客戶觀看的平均質(zhì)量要比前面的好，在下調(diào)片段Sk的碼率Rk時，可以充分利用網(wǎng)絡(luò)中可能緩存的多種碼率資源 （沒有Rk，但很可能有比Rk低一個或者兩個等級的碼率Rk′），分步下調(diào)碼率，第一次下調(diào)為Rk=Rk′，請求下載。若該片段Sk不止一次發(fā)生中斷，為避免播放停滯，應(yīng)立即下調(diào)為Rk=Rmin。

4 仿真結(jié)果與分析

本仿真中采用如圖7所示的物理拓?fù)?，分為兩個場景：場景一中內(nèi)網(wǎng)帶寬為100 Mbit/s，與外網(wǎng)相連的出口帶寬穩(wěn)定在250 kbit/s，用以驗(yàn)證仿真的可行性；場景二中內(nèi)網(wǎng)帶寬也為100 Mbit/s，而出口帶寬為一個動態(tài)變化的網(wǎng)絡(luò)，用以測試本文提出的算法的準(zhǔn)確性。實(shí)驗(yàn)中調(diào)節(jié)系數(shù)α=1.5，所采用的視頻片段總數(shù)為300，每個片段默認(rèn)等時長 τ=2 s，且每個片段均有 200 kbit/s、250 kbit/s、300 kbit/s、400 kbit/s、500 kbit/s共5種碼率供選擇。

圖7 實(shí)驗(yàn)拓?fù)?/p>

場景一：圖8展示了本地節(jié)點(diǎn)沒緩存、有緩存時前兩個客戶的播放碼率。圖9給出了沒有緩存以及有緩存時前8個客戶端的碼率比例。

圖8 DASH/DASC播放碼率對比

圖9 DASH/DASC請求碼率比例對比

對比圖8和圖9，DASH客戶端請求了少量的200 kbit/s和較多的250 kbit/s碼率的片段，而DASC客戶端1請求了部分300 kbit/s碼率的片段，DASC客戶端2請求了部分400 kbit/s和500 kbit/s碼率的片段；而第7個和第8個客戶端請求的幾乎是最高碼率的片段。由于網(wǎng)絡(luò)的緩存，后續(xù)的DASC客戶端可以利用鄰近節(jié)點(diǎn)緩存的內(nèi)容進(jìn)而突破出口帶寬小的限制。然而后續(xù)的一些客戶端（第2個和第3個）卻請求了較多的低碼率（200 kbit/s）片段，這主要是因?yàn)樽赃m應(yīng)策略對網(wǎng)速進(jìn)行了誤判，誤以為從緩存節(jié)點(diǎn)下載的速度為客戶端到服務(wù)器整條鏈路的網(wǎng)速，導(dǎo)致緩存區(qū)面臨下溢的危險而被迫請求碼率較低的片段。

場景二：本次實(shí)驗(yàn)中，客戶端緩沖區(qū)默認(rèn)設(shè)置3個緩沖區(qū)閾值，當(dāng)緩沖區(qū)長度小于緩沖區(qū)最小值Buffermin=10 s時，直接請求最低碼率來填充；盡可能地將緩沖區(qū)長度控制在低值Bufferlow=20 s和高值Bufferhigh=50 s之間。動態(tài)網(wǎng)絡(luò)的帶寬變化如圖10中粗實(shí)線所示，基于已有的HAS算法，本文提出的基于預(yù)判機(jī)制的自適應(yīng)算法PHAS中也采用HAS方法，PHAS的客戶1和客戶2的請求碼率在圖10中分別用兩種虛線表示，可見能夠動態(tài)地適應(yīng)網(wǎng)絡(luò)的變化。圖11給出了前8個客戶端請求碼率的比例，由于緩沖區(qū)最小閾值的限制，每次開始請求的一些片段均為低碼率，后續(xù)階段對碼率進(jìn)行調(diào)整。

圖10 動態(tài)網(wǎng)絡(luò)中請求碼率的變化

圖11 動態(tài)網(wǎng)絡(luò)中不同客戶端請求碼率比例對比

圖12 和圖13給出了HAS和PHAS兩種自適應(yīng)算法的對比。在圖12的緩沖區(qū)對比中，當(dāng)出口帶寬降低時，由于時延特性，HAS算法繼續(xù)請求高碼率的片段，由于這些高碼率片段的鄰近節(jié)點(diǎn)沒有緩存，只能將請求轉(zhuǎn)發(fā)至源服務(wù)器獲取，客戶端也只能等待請求的內(nèi)容回來，盡管在此期間緩沖區(qū)已降到Buffermin附近，隨時有播放中斷的可能；而使用PHAS方法，可以清楚地看到緩沖區(qū)只是降到了Bufferlow附近，大大降低了播放中斷的可能性。圖13中是請求碼率的對比，在出口帶寬降低后，PHAS和HAS都做出了正確的判斷，降低了碼率，但PHAS算法比HAS算法更能充分地利用網(wǎng)絡(luò)中緩存的資源，將碼率盡快地調(diào)整回去，從而提高了客戶的觀看體驗(yàn)。

5 結(jié)束語

隨著互聯(lián)網(wǎng)視頻、IPTV等業(yè)務(wù)的快速發(fā)展，動態(tài)自適應(yīng)流媒體技術(shù)也得到了廣泛研究。本文在現(xiàn)有ICN的基礎(chǔ)上模擬了簡單的MPEG-DASH應(yīng)用，并通過仿真表明，改進(jìn)的自適應(yīng)算法要優(yōu)于傳統(tǒng)的自適應(yīng)算法，能給客戶更好的觀看體驗(yàn)。然而在ICN中部署MPEG-DASH存在的問題還有很多，還有很大的研究價值和應(yīng)用發(fā)展空間，值得進(jìn)行更深入的研究和應(yīng)用開發(fā)工作。

圖12 動態(tài)網(wǎng)絡(luò)中客戶端緩沖區(qū)的變化

圖13 動態(tài)網(wǎng)絡(luò)中客戶端請求碼率的變化

1 Ahlgren B,D’Ambrosio M,Marchisio M,et al.Design considerations for a network of information.Proceedings of the 2008 ACM CoNEXT Conference,Madrid,Spain,2008

2 Cisco.Cisco Visual Networking Index:Forecast and Methodology,2011-2016.Tech Rep,May 2012

3 Sodagar I.The MPEG-DASH standard for multimedia streaming overthe internet.IEEE Computer Society(S1070-986X),2011,4(18):62～67

4 Akhshabi S,Narayanaswamy S,Begen A C,et al.An experimental evaluation of rate-adaptive video players over HTTP.Signal Processing:Image Communication(S0923-5965),2012,4(27):271～287

5 Miller K,Quacchio E,Gennari G,et al.Adaptation algorithm for adaptive streaming over HTTP.Proceedings of 19th International Conference on Packet Video Workshop(PV),Munich-Garching,Germany,2012:173～178

6 Liu Y,Geurts J,Point J C,et al.Dynamic adaptive streaming over CCN:a caching and overhead analysis.Proceedings of 2013 IEEE International Conference on Communications(ICC),Budapest,Hungary,2013:3629～3633

7 Ccnx project v0.6.0.http://www.ccnx.org

8 Müller C,Timmerer C.A VLC media player plugin enabling dynamic adaptive streaming over HTTP.Proceedings of the 19th ACM International Conference on Multimedia,New York,NY,USA,2011:723～726

9 Jacobson V,Smetters D,Thornton J,et al.Networking named content.Proceedings of the 2009 ACM CoNEXT Conference,Toronto,Canada,2009