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

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

OTT TV的直播解決方案

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

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

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

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

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

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

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

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

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

2 組播技術(shù)簡介

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

組播通過把224.0.0.0～239.255.255.255的D類地址作為目的地址，有一臺源主機(jī)發(fā)出目的地址是以上范圍組播地址的報文，在網(wǎng)絡(luò)中，如果有其他主機(jī)對于這個組的報文感興趣，可以申請加入這個組，并可以接收這個組的報文，而其他非組內(nèi)成員則無法接收到這個組的報文。組播技術(shù)涵蓋的內(nèi)容相當(dāng)豐富，從地址分配、組成員管理，到組播報文轉(zhuǎn)發(fā)、路由建立、可靠性等諸多方面。實際應(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é)議通知本地路由器希望加入并接收某個特定組播組的信息，不需要等待IGMP查詢報文；另一方面，路由器利用IGMP協(xié)議周期性發(fā)送IGMP查詢報文，查詢局域網(wǎng)內(nèi)某個已知組的成員是否處于激活狀態(tài)，實現(xiàn)對所連網(wǎng)絡(luò)組成員關(guān)系的收集與維護(hù)。通過執(zhí)行IGMP組播協(xié)議，能在組播路由器中生成一張記錄路由器接口及其相應(yīng)接口對應(yīng)子網(wǎng)的成員信息的表，一旦路由器接收到某個組的數(shù)據(jù)報文，會根據(jù)該記錄表向僅有該組成員的接口進(jìn)行數(shù)據(jù)轉(zhuǎn)發(fā)[2]。

2.3 組播路由協(xié)議

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

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

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

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

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

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

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

3.2 終端方面解決方案

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

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

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

3.3 跨運營商的運營

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

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

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

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

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

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

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

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

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

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

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

3.3.2 使用MSDP等協(xié)議

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

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

圖3 MSDP使用示例

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

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

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

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

3.3.4 各方案對比

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

3.3.5 方案實例及驗證

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

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

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

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

4 結(jié)束語

綜上所述，對于網(wǎng)絡(luò)運營商而言，考慮到服務(wù)器及骨干網(wǎng)絡(luò)的承載能力，對內(nèi)網(wǎng)用戶，OTT TV的直播業(yè)務(wù)可采取組播傳輸技術(shù)；由于OTT TV的跨運營商運營，兼顧到網(wǎng)絡(luò)安全性，可綜合考慮對外網(wǎng)用戶采取單播技術(shù)傳輸直播節(jié)目，或者通過增加網(wǎng)絡(luò)安全防護(hù)措施實現(xiàn)不同運營商之間組播域的互聯(lián)互通，組播傳輸直播節(jié)目以提高外網(wǎng)用戶的用戶體驗。具體采用何種組合方案實現(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ò)等國內(nèi)數(shù)家商用WiFi服務(wù)提供商以及星巴克、萬達(dá)廣場等商家成立“騰訊安全WiFi聯(lián)盟”。

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