OTT TV的直播解決方案

劉明亮，劉思韻，辛?xí)悦?/p>

（廣州珠江數(shù)碼集團(tuán)有限公司，廣東 廣州 510000）

OTT TV的直播解決方案

劉明亮，劉思韻，辛?xí)悦?/p>

（廣州珠江數(shù)碼集團(tuán)有限公司，廣東 廣州 510000）

組播技術(shù)是OTT電視直播的解決方案之一。首先介紹了OTT TV的發(fā)展現(xiàn)狀與存在的一些問(wèn)題，然后介紹了組播的技術(shù)要點(diǎn)，同時(shí)，根據(jù)OTT中直播電視的使用場(chǎng)景，分析了直播電視的技術(shù)要求，提出了組播技術(shù)應(yīng)用于直播電視的可行性方案，結(jié)果表明該方案運(yùn)行良好。

OTT；組播；直播電視；Internet組管理協(xié)議

1 OTT TV的現(xiàn)狀與問(wèn)題

在剛剛過(guò)去的2013年中，OTT（Over The Top）成為業(yè)內(nèi)最流行的一個(gè)詞語(yǔ)。就OTT TV的發(fā)展現(xiàn)狀而言，其產(chǎn)業(yè)鏈已逐步形成。截至2013年，廣電總局已頒發(fā)7個(gè)互聯(lián)網(wǎng)電視集成業(yè)務(wù)牌照和9個(gè)互聯(lián)網(wǎng)內(nèi)容服務(wù)牌照。這些牌照持有方一方面與地方廣電合作，增強(qiáng)內(nèi)容的本地服務(wù)，另一方面展開(kāi)與電視機(jī)、機(jī)頂盒制造商的合作，布局終端市場(chǎng)，以此形成全產(chǎn)業(yè)鏈的運(yùn)營(yíng)。

就用戶(hù)體驗(yàn)而言，最直觀的是各類(lèi)OTT盒子使用戶(hù)享受互聯(lián)網(wǎng)電視服務(wù)變得越來(lái)越便捷，而功能和內(nèi)容的多樣化也使用戶(hù)收看電視有了更多主動(dòng)的選擇權(quán)。

然而，從網(wǎng)絡(luò)運(yùn)營(yíng)商的角度出發(fā)，OTT盒子（或裝有直播軟件的智能電視）卻不是特別受歡迎。究其原因，除了業(yè)務(wù)層面的沖突外，還有一個(gè)技術(shù)上的問(wèn)題，即OTT盒子直播節(jié)目的傳輸機(jī)制?，F(xiàn)有的主流解決方案中，直播節(jié)目都是使用單播進(jìn)行傳輸。單播的優(yōu)點(diǎn)是服務(wù)器可以及時(shí)響應(yīng)終端請(qǐng)求，但其缺點(diǎn)也是顯而易見(jiàn)的：1）對(duì)內(nèi)容提供商來(lái)說(shuō)，分發(fā)服務(wù)器針對(duì)每個(gè)終端發(fā)送數(shù)據(jù)流，在用戶(hù)數(shù)量龐大、單個(gè)數(shù)據(jù)流流量大的直播應(yīng)用場(chǎng)景中，服務(wù)器將不堪重負(fù)。2）在主流的網(wǎng)絡(luò)模型中，大流量數(shù)據(jù)、重復(fù)數(shù)據(jù)都是盡量放在本地，并在靠下游的緩存設(shè)備上進(jìn)行分發(fā)，即金字塔模型。如果全部使用單播協(xié)議，將會(huì)出現(xiàn)大量重復(fù)數(shù)據(jù)在運(yùn)營(yíng)商骨干網(wǎng)絡(luò)上傳輸。這種情況將會(huì)造成骨干網(wǎng)絡(luò)不堪重負(fù)，也是運(yùn)營(yíng)商所不能接受的。

解決這個(gè)問(wèn)題的方案之一就是使用組播技術(shù)。組播技術(shù)的優(yōu)點(diǎn)如下：1）需要相同數(shù)據(jù)流的終端加入相同的組共享一條數(shù)據(jù)流，大大減輕了分發(fā)服務(wù)器的負(fù)擔(dān)。2）同樣基于上述原因，骨干網(wǎng)絡(luò)中的直播節(jié)目流量將會(huì)維持在一定的范圍之內(nèi)。而且，由于組播協(xié)議是根據(jù)接收者的需要對(duì)數(shù)據(jù)流進(jìn)行復(fù)制轉(zhuǎn)發(fā)，所以服務(wù)端的服務(wù)總帶寬不受客戶(hù)接入端帶寬的限制。如此即可大大減輕內(nèi)容提供商出口網(wǎng)絡(luò)以及網(wǎng)絡(luò)運(yùn)營(yíng)商骨干網(wǎng)絡(luò)的壓力。3）此協(xié)議和單播協(xié)議一樣允許在In?ternet寬帶網(wǎng)上傳輸。

2 組播技術(shù)簡(jiǎn)介

2.1 組播協(xié)議的工作原理

組播通過(guò)把224.0.0.0～239.255.255.255的D類(lèi)地址作為目的地址，有一臺(tái)源主機(jī)發(fā)出目的地址是以上范圍組播地址的報(bào)文，在網(wǎng)絡(luò)中，如果有其他主機(jī)對(duì)于這個(gè)組的報(bào)文感興趣，可以申請(qǐng)加入這個(gè)組，并可以接收這個(gè)組的報(bào)文，而其他非組內(nèi)成員則無(wú)法接收到這個(gè)組的報(bào)文。組播技術(shù)涵蓋的內(nèi)容相當(dāng)豐富，從地址分配、組成員管理，到組播報(bào)文轉(zhuǎn)發(fā)、路由建立、可靠性等諸多方面。實(shí)際應(yīng)用中，比較關(guān)心的是組成員關(guān)系的維護(hù)及組播路由的維護(hù)。

2.2 組成員的維護(hù)

維護(hù)主機(jī)和網(wǎng)絡(luò)設(shè)備間組員關(guān)系的常用協(xié)議是互聯(lián)網(wǎng)組管理協(xié)議（Internet Group Management Proto?col，IGMP），負(fù)責(zé)IP組播的成員管理，用于在IP主機(jī)與其直接相鄰的組播路由器之間建立、維護(hù)組播成員關(guān)系[1]。IGMP組播協(xié)議具備雙向功能：一方面，主機(jī)利用IGMP協(xié)議通知本地路由器希望加入并接收某個(gè)特定組播組的信息，不需要等待IGMP查詢(xún)報(bào)文；另一方面，路由器利用IGMP協(xié)議周期性發(fā)送IGMP查詢(xún)報(bào)文，查詢(xún)局域網(wǎng)內(nèi)某個(gè)已知組的成員是否處于激活狀態(tài)，實(shí)現(xiàn)對(duì)所連網(wǎng)絡(luò)組成員關(guān)系的收集與維護(hù)。通過(guò)執(zhí)行IGMP組播協(xié)議，能在組播路由器中生成一張記錄路由器接口及其相應(yīng)接口對(duì)應(yīng)子網(wǎng)的成員信息的表，一旦路由器接收到某個(gè)組的數(shù)據(jù)報(bào)文，會(huì)根據(jù)該記錄表向僅有該組成員的接口進(jìn)行數(shù)據(jù)轉(zhuǎn)發(fā)[2]。

2.3 組播路由協(xié)議

常見(jiàn)的組播路由協(xié)議有PIM。PIM協(xié)議專(zhuān)注于維護(hù)接收者和組播源的狀態(tài)信息，在降低協(xié)議復(fù)雜度的同時(shí)也減小了開(kāi)銷(xiāo)。PIM協(xié)議參考了成熟的組播技術(shù)和轉(zhuǎn)發(fā)模型，將組播應(yīng)用分解為松散模式協(xié)議獨(dú)立性組播（Sparse Mode，SM）和密集模式協(xié)議獨(dú)立性組播（Dense Mode，DM）。其中，PIM-DM協(xié)議假定網(wǎng)絡(luò)中的每一個(gè)路由器都想接收組播數(shù)據(jù)包，組播數(shù)據(jù)會(huì)轉(zhuǎn)發(fā)到組播路由器所有的下游路由器上，如果存在不需要此組播數(shù)據(jù)的下游路由器，該組播下游路由器會(huì)發(fā)送停止此路徑轉(zhuǎn)發(fā)的剪枝要求。PIM-DM協(xié)議主要用于中小型網(wǎng)絡(luò)。對(duì)運(yùn)營(yíng)商網(wǎng)絡(luò)，更多的是使用PIM-SM協(xié)議。PIM-SM協(xié)議先定義了匯聚點(diǎn)（RP），匯聚點(diǎn)會(huì)收集和記錄需要組播的路由器，同時(shí)匯聚點(diǎn)轉(zhuǎn)發(fā)對(duì)應(yīng)的組播數(shù)據(jù)到上述路由器中去[3]。

3 應(yīng)用組播技術(shù)的直播電視解決方案

3.1 網(wǎng)絡(luò)方面解決方案

對(duì)于運(yùn)營(yíng)商內(nèi)部網(wǎng)絡(luò)，首先需要構(gòu)建一個(gè)組播骨干網(wǎng)。這個(gè)組播骨干網(wǎng)可以建立在現(xiàn)有的數(shù)據(jù)骨干傳輸網(wǎng)絡(luò)上。數(shù)據(jù)骨干網(wǎng)內(nèi)的各三層設(shè)備之間，使用PIM協(xié)議，把組播路由表傳送到各臺(tái)三層設(shè)備上。如圖1所示。

對(duì)于接入網(wǎng)絡(luò)，需使用IGMP協(xié)議，用以處理終端設(shè)備的接入請(qǐng)求，如圖2所示。

圖1 組播骨干網(wǎng)示例

圖2 接入網(wǎng)示例

3.2 終端方面解決方案

為了適應(yīng)這種組播解決方案，終端設(shè)備的軟件系統(tǒng)也需作出相應(yīng)的調(diào)整，包括：

1）終端設(shè)備的播放器需支持IGMP協(xié)議。當(dāng)用戶(hù)發(fā)起轉(zhuǎn)臺(tái)時(shí)，系統(tǒng)可以發(fā)起相應(yīng)的IGMP join請(qǐng)求；并在觀看過(guò)程中，當(dāng)網(wǎng)絡(luò)設(shè)備發(fā)起維護(hù)組關(guān)系的query查詢(xún)信息時(shí)，終端設(shè)備可以返回一個(gè)ack確認(rèn)信息，以保證直播流可以持續(xù)傳輸。

2）為區(qū)分不同的直播頻道，終端設(shè)備還需一個(gè)記錄了所有頻道的組播列表（本文稱(chēng)為channel_list）。channel_list文件的存在也為用戶(hù)組的管理提供了方便。為不同授權(quán)的用戶(hù)提供一個(gè)不同的channel_list文件，即可實(shí)現(xiàn)對(duì)不同用戶(hù)組的區(qū)分。

3.3 跨運(yùn)營(yíng)商的運(yùn)營(yíng)

由于上述方案構(gòu)建的組播骨干網(wǎng)絡(luò)都是基于同一個(gè)組播域提出，因此，該方案實(shí)際上只適用于單個(gè)運(yùn)營(yíng)商的內(nèi)部網(wǎng)絡(luò)。但實(shí)際上，OTT盒子的運(yùn)行情況多為跨運(yùn)營(yíng)商傳輸數(shù)據(jù)，因此上述方案仍需作出調(diào)整以滿(mǎn)足實(shí)際需求。

3.3.1 對(duì)網(wǎng)內(nèi)網(wǎng)外用戶(hù)進(jìn)行區(qū)分

網(wǎng)內(nèi)用戶(hù)直接使用組播傳輸，網(wǎng)外用戶(hù)則依舊使用單播傳輸。為了減輕單播網(wǎng)絡(luò)的壓力，對(duì)單播傳輸網(wǎng)絡(luò)的用戶(hù)，必然只能低碼率碼流傳輸。區(qū)分網(wǎng)內(nèi)網(wǎng)外用戶(hù)的方法有很多，此處列舉幾個(gè)簡(jiǎn)單的方法，僅供參考。

1）通過(guò)終端MAC辨別。由于設(shè)備MAC是唯一的，運(yùn)營(yíng)商可通過(guò)記錄內(nèi)網(wǎng)發(fā)放設(shè)備MAC的方法，對(duì)用戶(hù)進(jìn)行辨別。

2）通過(guò)IP地址辨別。由于多數(shù)運(yùn)營(yíng)商內(nèi)網(wǎng)終端設(shè)備都使用內(nèi)網(wǎng)IP地址，因此，可通過(guò)內(nèi)網(wǎng)或公網(wǎng)地址的方法，對(duì)用戶(hù)進(jìn)行辨別。

3）通過(guò)DNS域名解析的方法來(lái)辨別。運(yùn)營(yíng)商可在內(nèi)網(wǎng)建立一套完整的DNS系統(tǒng)，或DNS緩存系統(tǒng)，把某些內(nèi)網(wǎng)的域名、地址添加到系統(tǒng)中。當(dāng)終端設(shè)備上線(xiàn)注冊(cè)時(shí)，可請(qǐng)求訪(fǎng)問(wèn)某些內(nèi)網(wǎng)的域名。當(dāng)設(shè)備可獲取到正確的解析時(shí)，則可被認(rèn)為是內(nèi)網(wǎng)用戶(hù)；若不能，則可被認(rèn)為是外網(wǎng)用戶(hù)。

當(dāng)用戶(hù)被正確區(qū)分之后，運(yùn)營(yíng)商就可以采取不同的方式來(lái)傳輸數(shù)據(jù)：

1）對(duì)全網(wǎng)用戶(hù)發(fā)送一份單播通道的直播頻道表（channel_list_unicast），以保證所有用戶(hù)都可以接收到直播節(jié)目。

2）對(duì)內(nèi)網(wǎng)用戶(hù)發(fā)送一份組播通道的直播頻道表（channel_list_multicast），對(duì)內(nèi)網(wǎng)用戶(hù)可以提供高碼率的直播節(jié)目。

3）用戶(hù)終端需對(duì)優(yōu)先級(jí)進(jìn)行判斷。當(dāng)終端已獲取到channel_list_multicast，則終端優(yōu)先接收組播流節(jié)目；當(dāng)終端無(wú)法獲取到channel_list_multicast，或終端無(wú)法正確接收到組播流內(nèi)容，則終端自動(dòng)切換到chan?nel_list_unicast，以保證直播業(yè)務(wù)正常運(yùn)行。

這種對(duì)用戶(hù)區(qū)分的方法，是最容易實(shí)現(xiàn)，也是最快可以實(shí)現(xiàn)的。但相應(yīng)地，由于用戶(hù)被區(qū)分，其收到的服務(wù)也是被區(qū)分的，因此，勢(shì)必會(huì)造成用戶(hù)體驗(yàn)的下降。

3.3.2 使用MSDP等協(xié)議

MSDP是Multicast Source Discovery Protocol（組播源發(fā)現(xiàn)協(xié)議）的簡(jiǎn)稱(chēng)，是為了解決多個(gè)PIM-SM域之間的互聯(lián)而開(kāi)發(fā)的一種域間組播解決方案，用于發(fā)現(xiàn)其他PIM-SM域內(nèi)的組播源信息[4]。MSDP通過(guò)在網(wǎng)絡(luò)中選取適當(dāng)?shù)穆酚善鹘SDP對(duì)等體關(guān)系，以連通各PIM-SM域的RP。通過(guò)在各MSDP對(duì)等體之間交互SA（Source Active，信源有效）消息來(lái)共享組播源信息。示意圖如圖3所示。

使用此方案，需把PIM-SM域的RP透露出去。對(duì)于同一個(gè)運(yùn)營(yíng)商內(nèi)部的不同PIM-SM域之間互聯(lián)，這種情況是可以接受的。但對(duì)于不同運(yùn)營(yíng)商之間互聯(lián)的情況，由于運(yùn)營(yíng)商之間互信程度不一致，以及出于網(wǎng)絡(luò)安全的考慮，直接把RP透露出去，是不可接受的。因此，使用MSDP互聯(lián)的方案，必須增加相應(yīng)的安全防護(hù)措施，如添加訪(fǎng)問(wèn)控制列表、增加防火墻等。

圖3 MSDP使用示例

3.3.3 用硬件設(shè)備，作為專(zhuān)門(mén)的組播轉(zhuǎn)發(fā)網(wǎng)關(guān)

如圖4所示，組播轉(zhuǎn)發(fā)網(wǎng)關(guān)把運(yùn)營(yíng)商A的PIM-SM域內(nèi)的組播流進(jìn)行轉(zhuǎn)封裝，對(duì)PIM-SM域的RP進(jìn)行修改（或可理解為隱藏起來(lái)），再傳輸?shù)竭\(yùn)營(yíng)商B。運(yùn)營(yíng)商B再自建一個(gè)RP，傳輸?shù)絇IM-SM域中。

圖4 使用硬件設(shè)備作轉(zhuǎn)發(fā)網(wǎng)關(guān)

使用此方案的好處，在于網(wǎng)絡(luò)安全性的提高。當(dāng)發(fā)生來(lái)自運(yùn)營(yíng)商B的網(wǎng)絡(luò)攻擊時(shí)，受到攻擊的僅為組播轉(zhuǎn)發(fā)網(wǎng)關(guān)，運(yùn)營(yíng)商A的內(nèi)部業(yè)務(wù)網(wǎng)絡(luò)不受影響。另外，使用此方案還可達(dá)到可控可管的目的，運(yùn)營(yíng)商A轉(zhuǎn)發(fā)出去的組播流，是可以受其控制及監(jiān)管的。當(dāng)然，使用此方案也需相應(yīng)地增加必要的硬件成本。

3.3.4 各方案對(duì)比

對(duì)比上述3種方案，它們各有優(yōu)缺點(diǎn)，表1將進(jìn)行相關(guān)的對(duì)比。

3.3.5 方案實(shí)例及驗(yàn)證

組播碼流跨運(yùn)營(yíng)商轉(zhuǎn)發(fā)技術(shù)在廣州珠江數(shù)碼集團(tuán)有限公司（下稱(chēng)“珠江數(shù)碼”）已有相關(guān)的應(yīng)用案例。珠江數(shù)碼現(xiàn)有為廣州市各區(qū)市廣電運(yùn)營(yíng)商傳輸高清直播碼流的任務(wù)。由于各運(yùn)營(yíng)商系統(tǒng)之間并非絕對(duì)可信，珠江數(shù)碼采用了使用硬件網(wǎng)關(guān)的方案，拓?fù)淙鐖D5所示。

表1 應(yīng)用組播技術(shù)的電視直播解決

圖5 珠江數(shù)碼組播碼流跨運(yùn)營(yíng)商轉(zhuǎn)發(fā)實(shí)際案例

珠江數(shù)碼的組播轉(zhuǎn)發(fā)網(wǎng)關(guān)，使用了思科公司DCM D9900，把珠江數(shù)碼網(wǎng)內(nèi)的組播碼流，更換成其他組播地址后，傳輸?shù)綄?duì)方運(yùn)營(yíng)商的交換機(jī)。對(duì)方收到組播碼流后，再輸入到相關(guān)編碼器等設(shè)備。呈現(xiàn)給對(duì)方運(yùn)營(yíng)商的地址，僅為DCM的相關(guān)接口地址，而非珠江數(shù)碼PIM-SM域的RP地址。當(dāng)發(fā)生網(wǎng)絡(luò)攻擊等情況時(shí)，攻擊行為僅能到DCM這臺(tái)網(wǎng)關(guān)，無(wú)法到達(dá)珠江數(shù)碼內(nèi)部網(wǎng)絡(luò)，保障珠江數(shù)碼業(yè)務(wù)的正常運(yùn)行。

4 結(jié)束語(yǔ)

綜上所述，對(duì)于網(wǎng)絡(luò)運(yùn)營(yíng)商而言，考慮到服務(wù)器及骨干網(wǎng)絡(luò)的承載能力，對(duì)內(nèi)網(wǎng)用戶(hù)，OTT TV的直播業(yè)務(wù)可采取組播傳輸技術(shù)；由于OTT TV的跨運(yùn)營(yíng)商運(yùn)營(yíng)，兼顧到網(wǎng)絡(luò)安全性，可綜合考慮對(duì)外網(wǎng)用戶(hù)采取單播技術(shù)傳輸直播節(jié)目，或者通過(guò)增加網(wǎng)絡(luò)安全防護(hù)措施實(shí)現(xiàn)不同運(yùn)營(yíng)商之間組播域的互聯(lián)互通，組播傳輸直播節(jié)目以提高外網(wǎng)用戶(hù)的用戶(hù)體驗(yàn)。具體采用何種組合方案實(shí)現(xiàn)OTT TV的直播節(jié)目傳輸，仍應(yīng)依據(jù)具體網(wǎng)絡(luò)環(huán)境及使用效果而定。

[1]史蒂文斯.TCP/IP詳解[M].范建華，胥光輝，張濤，等，譯.北京：機(jī)械工業(yè)出版社，1999.

[2] 杭州華三通信技術(shù)有限公司.組播配置舉例[EB/OL]. [2014-03-01].http://www.h3c.com.cn/ProductsTechnology/Techno?logy/Group_Management/Other_technology/Representative_colloc?ate_enchiridion/200806/607843_30003_0.htm.

[3]章磊，程巍，高傳善，等.域間組播與PIM-SM的域間改進(jìn)[J].微型電腦應(yīng)用，2003，19（10）：54-56.

[4]Cisco Systems.域間組播解決方案[M].韋新，譯.北京：人民郵電出版社，2003.

騰訊：聯(lián)手產(chǎn)業(yè)上下游建W iFi聯(lián)盟

9月17日，騰訊宣布正在參與打造安全WiFi服務(wù)標(biāo)準(zhǔn)，并宣布與邁外迪、光音網(wǎng)絡(luò)等國(guó)內(nèi)數(shù)家商用WiFi服務(wù)提供商以及星巴克、萬(wàn)達(dá)廣場(chǎng)等商家成立“騰訊安全WiFi聯(lián)盟”。

該聯(lián)盟的成立將加速免費(fèi)WiFi全國(guó)布局，助力國(guó)家國(guó)家“數(shù)字城市”戰(zhàn)略，同時(shí)，期望由此逐步規(guī)范免費(fèi)WiFi服務(wù)接入標(biāo)準(zhǔn)，為網(wǎng)民提供隨時(shí)隨地安全上網(wǎng)的WiFi服務(wù)。具體來(lái)說(shuō)，裝有騰訊手機(jī)管家的手機(jī)可以自動(dòng)搜索和連接識(shí)別為安全的WiFi熱點(diǎn)，并實(shí)現(xiàn)免鑒權(quán)一鍵連接。并且，用戶(hù)在聯(lián)盟認(rèn)證下的WiFi熱點(diǎn)區(qū)域可以獲得真假熱點(diǎn)識(shí)別、數(shù)據(jù)傳輸加密保護(hù)和DNS保護(hù)等服務(wù)。據(jù)悉，邁外迪、光音網(wǎng)絡(luò)、維盟、潮WiFi等國(guó)內(nèi)商用WiFi服務(wù)提供商已加入該聯(lián)盟，使得免費(fèi)WiFi網(wǎng)絡(luò)的覆蓋范圍得以延伸得更廣。該聯(lián)盟已經(jīng)實(shí)現(xiàn)了對(duì)1萬(wàn)多家商場(chǎng)超市，1.5萬(wàn)多家咖啡館，3.5萬(wàn)多家餐廳，以及45%以上的機(jī)場(chǎng)和火車(chē)站的WiFi覆蓋。

Solution for Live OTT TV

LIU Mingliang,LIU Siyun,XIN Xiaomei
（Guangzhou Digital Media Group,Guangzhou 510000,China）

Multicast is one of the main solutions for live TV on Over-The-Top(OTT)box.The current states of OTT TV and the existing problems of OTT TV are introduced in this paper.Then the techniques of multicast are introduced.The technical requirements of live TV are analyzed according the use of scenarios based on OTT live TV,and the feasible solution of multicast technology used in live TV is proposed.The results show that the solution performs well.

OTT;multicast;live TV;IGMP

TN949

A

?? 京

2014-04-22

【本文獻(xiàn)信息】劉明亮，劉思韻，辛?xí)悦?OTT TV的直播解決方案[J].電視技術(shù)，2014，38（20）.

劉明亮，碩士，珠江數(shù)碼集團(tuán)副總裁。