劉明亮,劉思韻,辛曉玫
(廣州珠江數碼集團有限公司,廣東 廣州 510000)
OTT TV的直播解決方案
劉明亮,劉思韻,辛曉玫
(廣州珠江數碼集團有限公司,廣東 廣州 510000)
組播技術是OTT電視直播的解決方案之一。首先介紹了OTT TV的發(fā)展現狀與存在的一些問題,然后介紹了組播的技術要點,同時,根據OTT中直播電視的使用場景,分析了直播電視的技術要求,提出了組播技術應用于直播電視的可行性方案,結果表明該方案運行良好。
OTT;組播;直播電視;Internet組管理協議
在剛剛過去的2013年中,OTT(Over The Top)成為業(yè)內最流行的一個詞語。就OTT TV的發(fā)展現狀而言,其產業(yè)鏈已逐步形成。截至2013年,廣電總局已頒發(fā)7個互聯網電視集成業(yè)務牌照和9個互聯網內容服務牌照。這些牌照持有方一方面與地方廣電合作,增強內容的本地服務,另一方面展開與電視機、機頂盒制造商的合作,布局終端市場,以此形成全產業(yè)鏈的運營。
就用戶體驗而言,最直觀的是各類OTT盒子使用戶享受互聯網電視服務變得越來越便捷,而功能和內容的多樣化也使用戶收看電視有了更多主動的選擇權。
然而,從網絡運營商的角度出發(fā),OTT盒子(或裝有直播軟件的智能電視)卻不是特別受歡迎。究其原因,除了業(yè)務層面的沖突外,還有一個技術上的問題,即OTT盒子直播節(jié)目的傳輸機制?,F有的主流解決方案中,直播節(jié)目都是使用單播進行傳輸。單播的優(yōu)點是服務器可以及時響應終端請求,但其缺點也是顯而易見的:1)對內容提供商來說,分發(fā)服務器針對每個終端發(fā)送數據流,在用戶數量龐大、單個數據流流量大的直播應用場景中,服務器將不堪重負。2)在主流的網絡模型中,大流量數據、重復數據都是盡量放在本地,并在靠下游的緩存設備上進行分發(fā),即金字塔模型。如果全部使用單播協議,將會出現大量重復數據在運營商骨干網絡上傳輸。這種情況將會造成骨干網絡不堪重負,也是運營商所不能接受的。
解決這個問題的方案之一就是使用組播技術。組播技術的優(yōu)點如下:1)需要相同數據流的終端加入相同的組共享一條數據流,大大減輕了分發(fā)服務器的負擔。2)同樣基于上述原因,骨干網絡中的直播節(jié)目流量將會維持在一定的范圍之內。而且,由于組播協議是根據接收者的需要對數據流進行復制轉發(fā),所以服務端的服務總帶寬不受客戶接入端帶寬的限制。如此即可大大減輕內容提供商出口網絡以及網絡運營商骨干網絡的壓力。3)此協議和單播協議一樣允許在In?ternet寬帶網上傳輸。
2.1 組播協議的工作原理
組播通過把224.0.0.0~239.255.255.255的D類地址作為目的地址,有一臺源主機發(fā)出目的地址是以上范圍組播地址的報文,在網絡中,如果有其他主機對于這個組的報文感興趣,可以申請加入這個組,并可以接收這個組的報文,而其他非組內成員則無法接收到這個組的報文。組播技術涵蓋的內容相當豐富,從地址分配、組成員管理,到組播報文轉發(fā)、路由建立、可靠性等諸多方面。實際應用中,比較關心的是組成員關系的維護及組播路由的維護。
2.2 組成員的維護
維護主機和網絡設備間組員關系的常用協議是互聯網組管理協議(Internet Group Management Proto?col,IGMP),負責IP組播的成員管理,用于在IP主機與其直接相鄰的組播路由器之間建立、維護組播成員關系[1]。IGMP組播協議具備雙向功能:一方面,主機利用IGMP協議通知本地路由器希望加入并接收某個特定組播組的信息,不需要等待IGMP查詢報文;另一方面,路由器利用IGMP協議周期性發(fā)送IGMP查詢報文,查詢局域網內某個已知組的成員是否處于激活狀態(tài),實現對所連網絡組成員關系的收集與維護。通過執(zhí)行IGMP組播協議,能在組播路由器中生成一張記錄路由器接口及其相應接口對應子網的成員信息的表,一旦路由器接收到某個組的數據報文,會根據該記錄表向僅有該組成員的接口進行數據轉發(fā)[2]。
2.3 組播路由協議
常見的組播路由協議有PIM。PIM協議專注于維護接收者和組播源的狀態(tài)信息,在降低協議復雜度的同時也減小了開銷。PIM協議參考了成熟的組播技術和轉發(fā)模型,將組播應用分解為松散模式協議獨立性組播(Sparse Mode,SM)和密集模式協議獨立性組播(Dense Mode,DM)。其中,PIM-DM協議假定網絡中的每一個路由器都想接收組播數據包,組播數據會轉發(fā)到組播路由器所有的下游路由器上,如果存在不需要此組播數據的下游路由器,該組播下游路由器會發(fā)送停止此路徑轉發(fā)的剪枝要求。PIM-DM協議主要用于中小型網絡。對運營商網絡,更多的是使用PIM-SM協議。PIM-SM協議先定義了匯聚點(RP),匯聚點會收集和記錄需要組播的路由器,同時匯聚點轉發(fā)對應的組播數據到上述路由器中去[3]。
3.1 網絡方面解決方案
對于運營商內部網絡,首先需要構建一個組播骨干網。這個組播骨干網可以建立在現有的數據骨干傳輸網絡上。數據骨干網內的各三層設備之間,使用PIM協議,把組播路由表傳送到各臺三層設備上。如圖1所示。
對于接入網絡,需使用IGMP協議,用以處理終端設備的接入請求,如圖2所示。
圖1 組播骨干網示例
圖2 接入網示例
3.2 終端方面解決方案
為了適應這種組播解決方案,終端設備的軟件系統也需作出相應的調整,包括:
1)終端設備的播放器需支持IGMP協議。當用戶發(fā)起轉臺時,系統可以發(fā)起相應的IGMP join請求;并在觀看過程中,當網絡設備發(fā)起維護組關系的query查詢信息時,終端設備可以返回一個ack確認信息,以保證直播流可以持續(xù)傳輸。
2)為區(qū)分不同的直播頻道,終端設備還需一個記錄了所有頻道的組播列表(本文稱為channel_list)。channel_list文件的存在也為用戶組的管理提供了方便。為不同授權的用戶提供一個不同的channel_list文件,即可實現對不同用戶組的區(qū)分。
3.3 跨運營商的運營
由于上述方案構建的組播骨干網絡都是基于同一個組播域提出,因此,該方案實際上只適用于單個運營商的內部網絡。但實際上,OTT盒子的運行情況多為跨運營商傳輸數據,因此上述方案仍需作出調整以滿足實際需求。
3.3.1 對網內網外用戶進行區(qū)分
網內用戶直接使用組播傳輸,網外用戶則依舊使用單播傳輸。為了減輕單播網絡的壓力,對單播傳輸網絡的用戶,必然只能低碼率碼流傳輸。區(qū)分網內網外用戶的方法有很多,此處列舉幾個簡單的方法,僅供參考。
1)通過終端MAC辨別。由于設備MAC是唯一的,運營商可通過記錄內網發(fā)放設備MAC的方法,對用戶進行辨別。
2)通過IP地址辨別。由于多數運營商內網終端設備都使用內網IP地址,因此,可通過內網或公網地址的方法,對用戶進行辨別。
3)通過DNS域名解析的方法來辨別。運營商可在內網建立一套完整的DNS系統,或DNS緩存系統,把某些內網的域名、地址添加到系統中。當終端設備上線注冊時,可請求訪問某些內網的域名。當設備可獲取到正確的解析時,則可被認為是內網用戶;若不能,則可被認為是外網用戶。
當用戶被正確區(qū)分之后,運營商就可以采取不同的方式來傳輸數據:
1)對全網用戶發(fā)送一份單播通道的直播頻道表(channel_list_unicast),以保證所有用戶都可以接收到直播節(jié)目。
2)對內網用戶發(fā)送一份組播通道的直播頻道表(channel_list_multicast),對內網用戶可以提供高碼率的直播節(jié)目。
3)用戶終端需對優(yōu)先級進行判斷。當終端已獲取到channel_list_multicast,則終端優(yōu)先接收組播流節(jié)目;當終端無法獲取到channel_list_multicast,或終端無法正確接收到組播流內容,則終端自動切換到chan?nel_list_unicast,以保證直播業(yè)務正常運行。
這種對用戶區(qū)分的方法,是最容易實現,也是最快可以實現的。但相應地,由于用戶被區(qū)分,其收到的服務也是被區(qū)分的,因此,勢必會造成用戶體驗的下降。
3.3.2 使用MSDP等協議
MSDP是Multicast Source Discovery Protocol(組播源發(fā)現協議)的簡稱,是為了解決多個PIM-SM域之間的互聯而開發(fā)的一種域間組播解決方案,用于發(fā)現其他PIM-SM域內的組播源信息[4]。MSDP通過在網絡中選取適當的路由器建立MSDP對等體關系,以連通各PIM-SM域的RP。通過在各MSDP對等體之間交互SA(Source Active,信源有效)消息來共享組播源信息。示意圖如圖3所示。
使用此方案,需把PIM-SM域的RP透露出去。對于同一個運營商內部的不同PIM-SM域之間互聯,這種情況是可以接受的。但對于不同運營商之間互聯的情況,由于運營商之間互信程度不一致,以及出于網絡安全的考慮,直接把RP透露出去,是不可接受的。因此,使用MSDP互聯的方案,必須增加相應的安全防護措施,如添加訪問控制列表、增加防火墻等。
圖3 MSDP使用示例
3.3.3 用硬件設備,作為專門的組播轉發(fā)網關
如圖4所示,組播轉發(fā)網關把運營商A的PIM-SM域內的組播流進行轉封裝,對PIM-SM域的RP進行修改(或可理解為隱藏起來),再傳輸到運營商B。運營商B再自建一個RP,傳輸到PIM-SM域中。
圖4 使用硬件設備作轉發(fā)網關
使用此方案的好處,在于網絡安全性的提高。當發(fā)生來自運營商B的網絡攻擊時,受到攻擊的僅為組播轉發(fā)網關,運營商A的內部業(yè)務網絡不受影響。另外,使用此方案還可達到可控可管的目的,運營商A轉發(fā)出去的組播流,是可以受其控制及監(jiān)管的。當然,使用此方案也需相應地增加必要的硬件成本。
3.3.4 各方案對比
對比上述3種方案,它們各有優(yōu)缺點,表1將進行相關的對比。
3.3.5 方案實例及驗證
組播碼流跨運營商轉發(fā)技術在廣州珠江數碼集團有限公司(下稱“珠江數碼”)已有相關的應用案例。珠江數碼現有為廣州市各區(qū)市廣電運營商傳輸高清直播碼流的任務。由于各運營商系統之間并非絕對可信,珠江數碼采用了使用硬件網關的方案,拓撲如圖5所示。
表1 應用組播技術的電視直播解決
圖5 珠江數碼組播碼流跨運營商轉發(fā)實際案例
珠江數碼的組播轉發(fā)網關,使用了思科公司DCM D9900,把珠江數碼網內的組播碼流,更換成其他組播地址后,傳輸到對方運營商的交換機。對方收到組播碼流后,再輸入到相關編碼器等設備。呈現給對方運營商的地址,僅為DCM的相關接口地址,而非珠江數碼PIM-SM域的RP地址。當發(fā)生網絡攻擊等情況時,攻擊行為僅能到DCM這臺網關,無法到達珠江數碼內部網絡,保障珠江數碼業(yè)務的正常運行。
綜上所述,對于網絡運營商而言,考慮到服務器及骨干網絡的承載能力,對內網用戶,OTT TV的直播業(yè)務可采取組播傳輸技術;由于OTT TV的跨運營商運營,兼顧到網絡安全性,可綜合考慮對外網用戶采取單播技術傳輸直播節(jié)目,或者通過增加網絡安全防護措施實現不同運營商之間組播域的互聯互通,組播傳輸直播節(jié)目以提高外網用戶的用戶體驗。具體采用何種組合方案實現OTT TV的直播節(jié)目傳輸,仍應依據具體網絡環(huán)境及使用效果而定。
[1]史蒂文斯.TCP/IP詳解[M].范建華,胥光輝,張濤,等,譯.北京:機械工業(yè)出版社,1999.
[2] 杭州華三通信技術有限公司.組播配置舉例[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].微型電腦應用,2003,19(10):54-56.
[4]Cisco Systems.域間組播解決方案[M].韋新,譯.北京:人民郵電出版社,2003.
騰訊:聯手產業(yè)上下游建W iFi聯盟
9月17日,騰訊宣布正在參與打造安全WiFi服務標準,并宣布與邁外迪、光音網絡等國內數家商用WiFi服務提供商以及星巴克、萬達廣場等商家成立“騰訊安全WiFi聯盟”。
該聯盟的成立將加速免費WiFi全國布局,助力國家國家“數字城市”戰(zhàn)略,同時,期望由此逐步規(guī)范免費WiFi服務接入標準,為網民提供隨時隨地安全上網的WiFi服務。具體來說,裝有騰訊手機管家的手機可以自動搜索和連接識別為安全的WiFi熱點,并實現免鑒權一鍵連接。并且,用戶在聯盟認證下的WiFi熱點區(qū)域可以獲得真假熱點識別、數據傳輸加密保護和DNS保護等服務。據悉,邁外迪、光音網絡、維盟、潮WiFi等國內商用WiFi服務提供商已加入該聯盟,使得免費WiFi網絡的覆蓋范圍得以延伸得更廣。該聯盟已經實現了對1萬多家商場超市,1.5萬多家咖啡館,3.5萬多家餐廳,以及45%以上的機場和火車站的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
【本文獻信息】劉明亮,劉思韻,辛曉玫.OTT TV的直播解決方案[J].電視技術,2014,38(20).
劉明亮,碩士,珠江數碼集團副總裁。