郭 軍，王 煜

(天津泰達(dá)有線電視網(wǎng)絡(luò)有限公司 天津300456)

信息時(shí)代

IP互動電視快速頻道切換的解決方案與實(shí)現(xiàn)

郭 軍，王 煜

(天津泰達(dá)有線電視網(wǎng)絡(luò)有限公司 天津300456)

采用單播方式的快速頻道切換技術(shù)(ICC)，通過獨(dú)立的單播輔助頻道來降低用戶在頻道切換時(shí)產(chǎn)生的緩沖延遲。通過仿真實(shí)驗(yàn)驗(yàn)證單播ICC頻道切換速度的提升，同時(shí)驗(yàn)證單播ICC在大量用戶收看相同頻道時(shí)所形成的突發(fā)流量對網(wǎng)絡(luò)帶寬和服務(wù)器負(fù)載的影響。

IPTV 快速頻道切換 組播 單播ICC

0 引 言

隨著三網(wǎng)融合業(yè)務(wù)的快速發(fā)展，基于 IP部署的實(shí)時(shí)電視(IPTV)已經(jīng)成為現(xiàn)實(shí)。IPTV是指通過對一系列視頻服務(wù)(包括實(shí)時(shí)直播和視頻點(diǎn)播)進(jìn)行視頻壓縮，并通過一個(gè) IP分組數(shù)據(jù)網(wǎng)絡(luò)傳輸給用戶。最近的一份研究顯示，用戶的IP流量(公共互聯(lián)網(wǎng)和內(nèi)網(wǎng) IP)將以每年 57%的速度增長，這其中視頻流量占有非常大的比例。因此，通過對 IP網(wǎng)絡(luò)的設(shè)計(jì)優(yōu)化來支撐視頻流的長期增長是十分必要的。

本文描述的系統(tǒng)中，標(biāo)清頻道消耗2～3,Mbps帶寬，而高清頻道要消耗 8～10,Mbps帶寬，系統(tǒng)中一共包含 200套境內(nèi)及境外頻道(其中標(biāo)清 190套，高清10套)和大量的IPTV電視用戶，因此IPTV會依據(jù)實(shí)際的網(wǎng)絡(luò)條件來設(shè)計(jì)帶寬分布。IPTV分為常態(tài)和瞬時(shí)兩種流的需求模式，其中常態(tài)的帶寬需求來自大量用戶的累積，根據(jù) IPTV網(wǎng)絡(luò)結(jié)構(gòu)中組播的技術(shù)模式，常態(tài)帶寬需求對于骨干網(wǎng)的要求比較恒定，而瞬時(shí)帶寬需求的來源是客戶切換頻道與大量的點(diǎn)播需求產(chǎn)生的。為了滿足客戶的用戶體驗(yàn)，瞬時(shí)產(chǎn)生的網(wǎng)絡(luò)帶寬需求和后臺視頻服務(wù)器的I/O容量至關(guān)重要。

1 快速頻道切換基本原理

IPTV通常使用 IP組播來提供內(nèi)容，每個(gè)電視頻道使用不同的組播組。用戶的終端設(shè)備(機(jī)頂盒STB)通過加入不同頻道的組播組實(shí)現(xiàn)切換到具體電視頻道。由于組播的機(jī)制，加入組播組需要一定時(shí)間，因此會在頻道切換時(shí)產(chǎn)生延遲，更主要的導(dǎo)致延遲的原因是，終端設(shè)備需要等待接收一個(gè) I-幀，然后填補(bǔ)新頻道(新加入的組播組)的播放器Buffer。根據(jù)不同的網(wǎng)絡(luò)環(huán)境，頻道切換延遲可達(dá)到幾秒鐘，這會造成非常差的用戶體驗(yàn)。相反，傳統(tǒng)的廣播或以同軸電纜為基礎(chǔ)的模擬系統(tǒng)，采用廣播的方式，機(jī)頂盒(STB)可以同時(shí)接收所有的頻道，當(dāng)用戶切換頻道時(shí)，機(jī)頂盒會立即調(diào)到新的頻道上，并馬上在屏幕上顯示出來。因此，該系統(tǒng)中的頻道變化時(shí)間最小，但系統(tǒng)對網(wǎng)絡(luò)資源的使用造成了很大浪費(fèi)。

為了盡量減少這種延遲，ICC(Instant Channel Change)技術(shù)解決方案被提出。在 IPTV系統(tǒng)切換頻道時(shí)，希望最大限度地減少用戶對延遲的體驗(yàn)。一種方法是當(dāng)用戶切換到一個(gè)新頻道時(shí)，后臺服務(wù)器發(fā)送一個(gè)完整的高比特率的單播流數(shù)據(jù)。高比特率可以提高終端播放器 Buffer的填充速率，與此同時(shí)單播流也會掩蓋組播的加入延遲，ICC技術(shù)的出現(xiàn)使得用戶得到更好的切換頻道體驗(yàn)。

2 單播快速頻道切換原理與實(shí)現(xiàn)

在數(shù)字電視環(huán)境中頻道切換速度原理上就比在模擬系統(tǒng)中切換頻道慢。延遲主要是用戶在顯示電視節(jié)目之前，要等待畫面組(GOP)或關(guān)鍵幀啟動而造成的。造成延遲的另一個(gè)原因是，客戶端要緩存足夠的幀，以防止緩沖區(qū)下溢。

單播 ICC技術(shù)為使延遲降至最短，由分發(fā)服務(wù)器(Distribution Servers)維護(hù)一個(gè)不斷更新的循環(huán)緩沖區(qū)，其中包含所有視頻流的內(nèi)容。當(dāng)用戶終端向后臺傳輸系統(tǒng)請求頻道切換時(shí)，其中一臺DServer會以I幀作為開始畫面，以一個(gè)高于標(biāo)準(zhǔn)比特率的速率將緩存的視頻流內(nèi)容以單播的方式發(fā)送到用戶終端設(shè)備。因?yàn)?DServer發(fā)送的視頻流的第一幀始終是I幀，所以節(jié)省了用戶終端等待I-frame的時(shí)間，如圖1所示。同樣，用戶終端等待充分緩沖的時(shí)間也大為縮短，因?yàn)閿?shù)據(jù)到達(dá)的速率比正常數(shù)據(jù)速率快，這使客戶端開始播放緩存內(nèi)容的時(shí)間能夠早于直播服務(wù)器(Acquisition Server)發(fā)送過來的組播視頻流。

圖1 DServer工作原理Fig.1 Operating principle of DServer

當(dāng) DServer發(fā)送了足以滿足用戶終端設(shè)備播放的緩存內(nèi)容后，便開始以標(biāo)準(zhǔn)的流比特率發(fā)送新的視頻內(nèi)容。這種突發(fā)的單播請求持續(xù)時(shí)間因流的內(nèi)容、其相關(guān)聯(lián)的 GOP間隔以及系統(tǒng)時(shí)鐘/解碼時(shí)間戳(STC/DTS)的最大延遲而異。一般說來，這些數(shù)值越小，單播ICC突發(fā)持續(xù)時(shí)間越短。目前系統(tǒng)中部署的視頻流的突發(fā)持續(xù)時(shí)間在6～15,s之間。

DServer所需傳輸帶寬根據(jù)預(yù)期的客戶端活躍程度來設(shè)置。如果 10,000個(gè)客戶端每天更改一次頻道且時(shí)間各不相同，則無需在DServer中按照近似每個(gè)客戶端每秒更改一次頻道的情況來設(shè)置帶寬。為每個(gè)單播 ICC突發(fā)保留的帶寬越大，頻道更改之間存在的重疊越小，但每個(gè)用戶終端設(shè)備的可用帶寬就必須越大。ICC頻道切換機(jī)制如圖2所示。

圖2 單播ICC頻道切換機(jī)制Fig.2 Mechanism of unicast ICC

圖3顯示了單播 ICC方案的動態(tài)緩沖機(jī)制。用戶切換頻道，同時(shí) STB發(fā)送 Leave信息；STB向DServer發(fā)送單播請求；DServer收到請求后，開始向STB發(fā)送單播數(shù)據(jù)流，STB收到后立即開始緩沖；因?yàn)閱尾チ饕?I幀開始，所以 STB迅速在屏幕上顯示高質(zhì)量的視頻內(nèi)容；當(dāng)STB緩沖到足夠的視頻數(shù)據(jù)，就開始向上層邊緣路由器發(fā)送 JoinGroup消息；經(jīng)過網(wǎng)絡(luò)層的處理，AServer開始向新組播組發(fā)送組播視頻流，同時(shí)STB收到組播視頻流后開始緩沖；STB緩沖到足夠的組播視頻流，切斷單播視頻流的同時(shí)，在屏幕上無縫顯示組播流視頻。

圖3 STB緩沖機(jī)制Fig.3 STB buffering mechanism

3 實(shí)驗(yàn)仿真

本次實(shí)驗(yàn)在 IPTV平臺上引入視頻源，并使用Cisco三層交換機(jī)與STB搭建的測試網(wǎng)絡(luò)環(huán)境，測試了用戶在單播 ICC機(jī)制下頻道加入延遲和頻道切換延遲。根據(jù)實(shí)驗(yàn)需求對交換設(shè)備進(jìn)行配置以達(dá)到實(shí)際應(yīng)用的仿真，并對實(shí)驗(yàn)數(shù)據(jù)進(jìn)行分析。

3.1 仿真拓?fù)洵h(huán)境

實(shí)驗(yàn)拓?fù)涫紫葟?IPTV互動電視系統(tǒng)中引入組播節(jié)目源，并從AServer將組播視頻流引入測試交換機(jī)，同時(shí)使用測試交換機(jī)連接一臺DServer，使用11臺PC模擬用戶終端設(shè)備 STB，其中 10臺用于模擬真實(shí)用戶，1臺用于測試并安裝 Wireshark軟件抓取所有所需數(shù)據(jù)報(bào)并加以分析，實(shí)驗(yàn)拓?fù)淙鐖D4所示。

圖4 單播ICC實(shí)驗(yàn)拓?fù)銯ig.4 Topology of unicast ICC experiments

3.2 實(shí)驗(yàn)1：ICC與基本IPTV的比較

3.2.1 測試方法

測試場景1選取一臺Cisco3750模擬一個(gè)小區(qū)，不同的STB代表不同的用戶，使用一臺開啟ICC的STB以每15,s切換一個(gè)頻道的頻率收看所有200套節(jié)目，每次切換頻道的操作就是一個(gè)離開組和加入組的過程，同時(shí)使用 Wireshark抓取數(shù)據(jù)報(bào)的具體數(shù)值，并與基本IPTV參數(shù)進(jìn)行比較。

3.2.2 測試結(jié)論

從圖5中可以看到開啟單播ICC功能的STB的頻道切換時(shí)間基本在 300～400,ms，如表 1所示，且抖動較小，較之 NOICC的頻道切換速度穩(wěn)定了許多，單播ICC的頻道切換延遲較之基本IPTV提高了大概5倍左右。

圖5 單播 ICC頻道切換時(shí)間與基本 IPTV頻道切換的比較Fig.5 Comparison between switching time of unicast ICC and basic IPTV channel changing

300～400,ms使得用戶在切換頻道時(shí)，基本沒有定格或卡屏的感知，可迅速收看到想看的視頻內(nèi)容。

表1 頻道延遲比較Tab.1 Comparison of channel changing delays

3.3 實(shí)驗(yàn)2：DServer的I/O

3.3.1 測試方法

本場景模擬黃金時(shí)段大量開啟 ICC的用戶同時(shí)切換頻道 DServer的I/O負(fù)載情況。在 10個(gè)節(jié)點(diǎn)中隨機(jī)抽取STB，在200個(gè)節(jié)目源隨機(jī)切換頻道，分別測試STB同時(shí)切換10～80個(gè)頻道時(shí)DServer的I/O。

3.3.2 測試結(jié)論

如圖 6所示，在單播 ICC的機(jī)制下，DServer的I/O肯定與頻道切換的數(shù)量成正比，DServer的I/O會根據(jù)頻道切換的次數(shù)而累積增加。

圖6 單播ICC-DServer的I/OFig.6 I/O of unicast ICC-Dserver

根據(jù)單播 ICC的機(jī)制，本次實(shí)驗(yàn)只包含直播內(nèi)容，DServer的I/O增加，必然會加大骨干帶寬的使用率，雖然骨干網(wǎng)上運(yùn)行的直播內(nèi)容因?yàn)榻M播的原因比較恒定，但是點(diǎn)播業(yè)務(wù)的內(nèi)容同樣是單播，再加上DServer傳送的單播視頻，在用戶使用高峰時(shí)期所占用的總帶寬還是非?？捎^的。

4 總 結(jié)

單播 ICC方法確實(shí)減少了用戶換臺所需的時(shí)間。然而，這種解決方案設(shè)計(jì)的初衷是讓并行的單播ICC請求數(shù)盡量小。當(dāng)并行單播ICC請求較多時(shí)(例如在黃金時(shí)段，出現(xiàn)大量用戶的單播請求)，這種方法會給網(wǎng)絡(luò)造成較大的負(fù)荷。此外，有限的 DServer的I/O容量也不得不支撐大量的同時(shí)傳輸?shù)膯尾チ?，有可能需要ISP額外部署服務(wù)器來滿足峰值需求。同樣核心層與骨干網(wǎng)的帶寬也必須在系統(tǒng)建設(shè)前期根據(jù)用戶數(shù)量做好預(yù)估，在系統(tǒng)進(jìn)入運(yùn)營期，還要不斷根據(jù)用戶數(shù)的提升擴(kuò)容DServer與網(wǎng)絡(luò)帶寬。

On Instant Channel Changing Solution for IP TV and Its Realization

GUO Jun，WANG Yu
(Tianjin TEDA Cable TV Network Co.，Ltd.，Tianjin 300456，China)

With adoption of the unicast Instant Channel Change(ICC)technology，an independent unicast auxiliary channel was used to reduce the buffering generated by users while switching channels. Through simulation experiments，the enhancement of unicast ICC speed was proved and the effect on network bandwidth and server load from Unicast ICC caused by burst traffic when large numbers of users are watching the same channel was verified.

IPTV；instant channel changing；multicast；unicast ICC

TN943.6

A

1006-8945(2014)06-0029-04

2014-05-09