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

郭 軍，王 煜

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

信息時代

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

郭 軍，王 煜

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

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

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

0 引 言

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

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

1 快速頻道切換基本原理

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

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

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

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

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

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

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

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

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

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

圖3 STB緩沖機制Fig.3 STB buffering mechanism

3 實驗仿真

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

3.1 仿真拓撲環(huán)境

實驗拓撲首先從 IPTV互動電視系統(tǒng)中引入組播節(jié)目源，并從AServer將組播視頻流引入測試交換機，同時使用測試交換機連接一臺DServer，使用11臺PC模擬用戶終端設備 STB，其中 10臺用于模擬真實用戶，1臺用于測試并安裝 Wireshark軟件抓取所有所需數(shù)據(jù)報并加以分析，實驗拓撲如圖4所示。

圖4 單播ICC實驗拓撲Fig.4 Topology of unicast ICC experiments

3.2 實驗1：ICC與基本IPTV的比較

3.2.1 測試方法

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

3.2.2 測試結論

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

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

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

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

3.3 實驗2：DServer的I/O

3.3.1 測試方法

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

3.3.2 測試結論

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

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

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

4 總 結

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

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