CMACast流媒體廣域網轉播方案的設計

周帆　曾繼榮　繆星宇　萬占蠢　郭海峰

摘要：為解決在CMACast衛星廣播系統中，氣象流媒體組播數據在局域網轉發時存在的高帶寬占用，以及無法轉發到其他局域網或廣域網的問題。本論述通過合理劃分和配置VLAN 并使用QoS 技術，達到降低帶寬占用、保障網絡流暢傳輸的目的。另外，通過設計開發組播代理軟件，利用組播技術，解決組播數據只能在本地局域網轉發的問題，實現更靈活、可靠的網絡架構設計，驗證了可以用最小的帶寬占用和系統資源，實現CMACast流媒體數據跨網段傳輸的可行性。

關鍵詞：通信網絡;CMACast轉播;廣播風暴;組播代理;流媒體轉播

中圖分類號：TP393.07文獻標志碼：A

0 引言

目前CMACast（China Meteorological Administration Cast，中國氣象局衛星廣播）系統下發的流媒體數據主要有兩種，一種是氣象頻道，另外一種是全國天氣會商的實時轉播，只有同 VLAN（Virtual Local Area Network，虛擬局域網）的計算機能夠收看CMACast接收機以組播方式轉播的氣象頻道和全國天氣會商的實時畫面[1]。組播在局域網中會以廣播的方式轉發數據造成廣播風暴，嚴重影響局域網性能。但如果將CMACast接收機與業務機劃分在不同的 VLAN 中，業務機又無法收看流媒體畫面。經過與中國局相關技術人員溝通也沒有得出有效的解決方案，因此需要分析問題原因，研究設計一套可行的CMACast流媒體廣域網轉播方案。

1 背景及需求

1.1 背景

各級氣象部門通過CMACast衛星小站接收流媒體數據，如圖1 所示。為使氣象臺業務機能夠順利調取資料、觀看全國天氣會商，一般CMACast接收機與氣象臺業務機會劃分在同一個 VLAN 中。正因此，我局曾出現過因CMACast流媒體廣播風暴導致局域網癱瘓的先例，這種情況在全國其他的氣象部門都有發生。

省氣象局發文明確要求各級氣象部門在汛期收看CMACast全國天氣會商，但因CMACast系統維護成本大、縣局技術力量欠缺、氣象數據集約化要求，該系統在許多縣局已停止運行，在現有技術條件下，無法滿足省局的要求。

1.2 需求

對于技術能力較強的省、市級氣象部門，需要解決CMACast接收機廣播風暴問題，提升局域網性能。對于技術力量較弱縣級氣象部門，需要在現有網絡架構下不增加額外成本解決縣局收看全國天氣會商的需求。

2 目標、內容及難點分析

2.1 目標

從先進性、實用性、可靠性、擴展性、低成本等方面著手，綜合系統性能等多方面因素，在不影響其他核心業務（如自動站數據實時傳輸、全省天氣會商系統、實時資料調取等）的前提下，使用最小的帶寬、最小的系統資源消耗以及可控的流量實現CMACast流媒體數據跨網段流暢傳輸，是本方案的主要設計目標。

2.2 內容

該方案從網絡架構、組播代理到流量控制3 方面著手，設計內容如下：

（1） 優化現有網絡結構，將CMACast接收服務器與氣象臺局域網劃分到不同的 VLAN 中[2-3]，以實現 CMA? Cast 接收服務器與氣象臺業務網絡的邏輯隔離，從而減少廣播對網絡帶寬的占用，提高網絡傳輸效率，同時防止因局域網爆發廣播風暴而導致服務器無法訪問的風險。

（2） 利用組播技術解決CMACast流媒體數據的跨網段傳輸問題[4]，實現全國天氣會商、氣象頻道向市縣廣域網及其他 VLAN 的實時轉播。

（3）利用 QoS（Quality of Service，服務質量）技術提高CMACast流媒體數據的轉發質量[5]，提升視頻畫面的流暢度和清晰度，并且防止組播數據占用大量帶寬從而影響其他正常業務數據的傳輸。

2.3 難點分析

（1） 在組播網絡配置之前，根據現有條件從先進性、實用性、可靠性、擴展性、低成本等方面做好組播數據網絡的架構設計，是實現組播數據廣域網轉發的基礎。

（2） 在測試中發現CMACast組播數據默認 TTL （ Time To Live，生存時間值）值為1，也就是說組播數據只能在局域網中傳播，不能跨網段傳輸，修改CMACast流媒體數據流的 TTL 值是該方案的一個難點。

（3）組播屬于點到多點的傳輸，如果設計不當，極易出現整個廣域網組播數據流的泛濫，這將極大影響其他業務的數據傳輸，因此合理的針對組播數據進行流量控制，使用最小的帶寬、最小的系統資源消耗以及可控的流量來實現CMACast流媒體數據跨網段的流暢傳輸也是本方案設計的難點之一。

3 技術方法介紹

3.1 組播技術

組播是將信息發送給多個有接收需求的主機而非所有主機，其基本思想是：源主機只發送一份數據，其目的地址為組播組地址。組播組中的所有接收者都可收到同樣的數據拷貝，并且只有組播組內的主機可以接收該數據。組播技術有效地解決了單點發送、多點接收的問題，實現了 IP （Internet Protocol，網際互連協議）網絡中點到多點的高效數據傳送，能夠大量節約網絡帶寬、降低網絡負載。

組播協議主要包含主機和路由器之間的協議，路由器和路由器之間的協議，以及組播域之間的協議?？紤]到兼容性以及應用擴展，本方案使用目前應用廣泛的協議技術，組播組管理協議使用 IGMP（Internet Group Management Protocol，Internet 組管理協議），組播路由協議使用 PIM （Protocal Independent Multicast，無協議組播）。

3.2 QoS技術

在通信網絡領域，服務質量的衡量標準主要有帶寬、延遲、抖動、以及丟包率這四個方面，不同的業務應用對網絡服務質量的要求有很大區別，見表1 所列。視頻點對于帶寬的要求比較高，對網絡延遲和抖動很敏感。所有的應用對丟包率的要求都較高，視頻應用中過多的丟包會造成圖像錯位和“馬賽克”等多方面的問題。

QoS 就是利用有限的網絡資源針對不同的業務應用優化網絡轉發，利用增加緩沖、對數據包進行壓縮、優先轉發某些數據流的數據包等方法提升網絡服務質量[6]。優先轉發某些數據流的數據包是 QoS 一個主要的功能，本方案中針對視頻點播需求采用 EF （Expedit? ed Forwarding，加速轉發）技術。

4 方案設計實現

4.1 調整優化現有網絡結構

如圖2 所示，將CMACast接收服務器、CMACast數據服務器、國突系統等對內服務器歸類到 VLAN310中，氣象臺 VLAN30專門用于氣象臺業務使用，這樣就實現了服務器與業務的廣播域隔離，氣象臺業務機內的廣播數據不影響服務器帶寬的使用，同樣，服務器內的廣播數據也不影響氣象臺業務機的使用。

4.2 利用組播技術實現組播數據的廣域網轉發

在接收者直連的三層接口上啟動 IGMP 協議，實現組播組成員的管理，如圖 2所示。在 VLAN20、 VLAN40、VLAN50對應的 VLAN 接口上啟動 IGMP 協議。然后在核心層（S7506E、S5800）、主干路由器（MSR5660）以及縣局的專線路由器以及核心層之間的三層接口上配置 PIM-SM 協議，從而實現組播報文轉發路徑的構建。

4.3 利用QoS實現組播報文的加速轉發以及帶寬限制

在本方案中，CMACast多媒體數據主要有兩路，一路為氣象頻道，一路為全國天氣會商視頻，而全國天氣會商視頻是雙流視頻，因此可以說一共有三路組播流數據。在組播數據源到核心交換機的入口處部署 QoS 流量監管[7]、流量重標記限制組播數據流使用帶寬和組播數據流的分類標記，在 MSR5660到縣局的專線出接口使用 EF 技術。為組播數據流提供低延遲、低抖動、低丟包率的保證帶寬的優先轉發服務，同時限制組播流量占用過多的網絡帶寬，從而達到組播流的順暢播放的同時不影響其他關鍵性業務的數據傳輸的目的。4.4 使用組播代理方法實現CMACast組播數據的二次轉發

在前期配置調試階段，遇到了一個比較難解決的問題。路由器及三層交換機均已正確配置，PIM- SM（Protocol- independent multicast sparse mode，協議無關組播稀疏模式）、IGMP 等協議都已啟用，但是CMACast流媒體數據始終收不到，這是因為組播默認的 TTL 值為 1。數據每次經過路由器時 TTL 值都會減1，減到0 時這個報文就被丟棄了。這就是組播數據不能在廣域網傳播的原因。

解決方法有兩種：一種是修改CMACast接收軟件，將 TTL 值改大。但這需要和CMACast接收機軟件開發商聯系，協商修改源程序，這種很難實現。因此我們采用第二種，自主開發一套組播代理軟件，將從CMACast接收到的流媒體數據修改其 TTL 值以及組播組、端口號等信息后再進行二次組播轉發，如圖3 所示。

5 驗證

5.1 測試環境說明

組播源服務器 IP 地址為10.169.206.11（以下簡稱 S1），所在的 VLAN 為 VLAN310，氣象頻道組播組地址為 239.0.1.45，全國天氣會商組播組地址為239.0.1.46。在此次驗證測試中，以靈臺縣局為例，各接收端詳細信息見表3 所列。

5.2 驗證組播功能

在靈臺縣局接收主機（PC3）上啟用 VLC 播放器并打開氣象頻道（udp：//@239.0.1.45：8000），在縣局核心交換機 S5560上查看組播路由表，如圖4 （a）所示。在核心交換機 S5560組播路由對應的出接口為Vlan-inter? face4，該接口下連縣局 MSR3640路由器。在縣局MSR3640路由器（PL_LT_XianJu_MSR3640）查看組播路由表，如圖4 （b）所示。發現氣象頻道組播數據出接口為 GE0/2.20，GE0/2.20與 PC3直連，說明組播數據已轉發至 PC3。

5.3 驗證組播代理功能

在圖3 自主開發的組播代理工具的界面中，設置 TTL 值為8 。那么在到達 PC3時TTL 應該會變為3，因為從組播源 S1到 PC3經過的路由器為：S1—— S7506E——MSR5660——靈臺縣站 MSR3640——靈臺縣站 S5660——靈臺縣局 MSR3640——PC3，共經過5 個路由器。抓取 PC3上的數據包發現，如圖5 所示， TTL 值變為3 。因此，利用組播代理工具實現了 TTL 值得修改以及組播數據的二次轉發。

5.4 驗證QoS對組播流量的控制

在 MSR5660去往各縣局的出接口處配置了 QoS 的 EF策略，配置及運行情況如圖6所示，從圖中紅色框中可以看到組播流的轉發速率為1.8 Mbps，而配置的EF CIR 平均帶寬為4 Mbps，能夠達到組播數據的流暢轉發。

通過以上測試，組播轉發、流量控制等功能都已經完全實現，CMACast流媒體數據不僅得到精準轉發，而且使得組播流量變得可控，不僅阻止了組播流量過大的問題，還對組播流量進行了加速轉發，有效的解決了流媒體數據對網絡延遲、抖動敏感的問題。

6 結論

該方案利用了最小的帶寬、最小的系統資源消耗以及可控的流量，在不影響其他核心業務傳輸性能的前提下，實現了CMACast流媒體數據跨網段的流暢傳輸。解決了縣局無法實時觀看全國天氣會商的難題，以及因氣象臺網絡結構優化后導致CMACast流媒體數據無法收看的問題，為市縣氣象服務提供了有力的保障。

但是在測試的過程中因為條件所限，只選擇了一個縣局進行了測試，沒能測試六縣一區同時接收 CMA? Cast 流媒體數據時流媒體數據是否能夠流暢播放，這需要在今后業務應用過程中再進行測試，若出現流媒體播放不流暢的問題，只需重新修改 QoS 策略中的參數即可解決。

參考文獻：

[1]董如根，杜世燁，孫雪麗. 局域網CMACast流媒體數據的正常播控[J]. 軟件導刊，2011，10（10）：114-115.

[2]杭州華三通信技術有限公司. 路由交換技術：第3 卷[M].北京：清華大學出版社，2012.

[3]杭州華三通信技術有限公司. 路由交換技術：第4 卷[M].北京：清華大學出版社，2012.

[4]劉玄. 組播路由控制與轉發分離機制的設計與實現[D]. 北京：北京郵電大學，2018.

[5]孟學軍，于紅增，郭巍，等. 基于區分服務的專用 IP 網 QoS部署策略設計[J]. 計算機與網絡，2020，46（17）：66-69.

[6]湯萍萍. QoS 感知的網絡流分類和聚集方法研究[D]. 南京：南京郵電大學，2021.

[7]趙政權. 面向服務的端到端 QoS 路由策略研究[D]. 北京：北京郵電大學，2021.