利用組播及QoS技術對IPTV網絡進行優化

虞炳文，白 寧，丁思煒，范利波，劉 暢

(西昌衛星發射中心，四川 西昌 615000)

0 引言

由于現代通訊網絡技術的日益發達,航天IP業務網早已不是單一的數據網絡了,是一種承載信息、聲音、圖形和視頻內容的多功能網絡系統,而隨著信息發送服務的多樣化,業務上對網絡系統的質量要求也日益嚴苛,如對網絡信息傳輸過程中的延時、抖動和丟包率等的評價標準要求也愈來愈嚴格。

航天測控網是傳統的IP數據網絡,但隨著網絡拓撲規模的逐漸擴大以及監視與控制服務類型的豐富,IPTV,即互聯網協議視頻技術，伴隨著這幾年的互聯網技術的發展中，得到了大面積的普及和應用，IPTV技術相比較傳統的有限電視技術與網絡電視技術，有著較為明顯的優勢，比如在畫質，人機交互等方面有著較為明顯的優化與提升，另外，IPTV技術的發展也得益于網絡帶寬的迅猛發展。由于航天測控網節點眾多,使用IPTV傳輸圖像信息的帶寬需求巨大,這對測控數據傳輸和網絡管理等關鍵網絡業務實時性可靠性提出了更高的要求。

1 關鍵技術介紹

1.1 IPTV技術

IPTV,即網絡協議數字電視(internet protocol television),也就是利用互聯網協議來進行包含視頻業務在內的多種數字媒體業務的服務。

IPTV是交互式網絡廣播電視,是指通過寬帶有線網絡,集合網絡、多媒體、通信等多項信息技術于一身,向家庭用戶提供包含數字電視在內的各種互動業務的新型信息技術。消費者通過家庭即可獲得IPTV業務。IPTV既不同于普通的網絡型有線電視,又不同于典型的數字電視,由于普通的網絡有線電視與典型的數字電視一樣具備了頻分制、定時、單向播出的特性。所以雖然典型的數字電視相比于普通網絡數字電視有了一些技術革新,但只有數據形態的變化,并不能觸及具體信息的傳播方式。

IPTV網絡系統主要是由IP骨干網、IP城域網、有線前端或移動電信中央站及其配套的寬帶接入網絡系統所共同完成的。骨干網與城域網的基礎主要任務,是對以IP單播或組播方法傳送的視聲音流媒介電視節目流實現路由轉換與傳送。在有線電視前段或電訊中央站可使用相關的寬帶接入網絡時,將IP視聲音流媒介電視節目流以IP over DOCSIS或IP over DSL的方法,經由位于有線電視前段的CMTS鑒定或電訊中央站的數字用戶線連接復用器(DSLAM)等裝置,向終端用戶傳送過去。

1.2 組播技術

組播，是結合了單播及廣播的特點的，可以跨過網段傳輸數據的網絡協議。通過組播技術,能夠在互聯網上更高效地進行一些多媒體業務,如網絡視頻、互聯網廣播和視頻等網絡信息業務。

IP組播功能的問世有效緩解了互聯網上用戶數量不穩定的情況。組播消息傳送方(即組播源)只傳遞一個消息,通過組播路徑技術對組播數據包構建樹型的路徑,所傳送的消息需要盡可能靠后的分叉路口才進行復用與分配。

組播實質上傳輸的也是UDP報文，UDP報文常見的兩種傳輸形式，一種是單播，即點對點傳輸，就是從一臺網絡設備發送到另一臺網絡設備，正常情況下，不會發送給第三個人，誰需要，就單獨給誰獨一份，換言之，即多少人需要這份數據，就需要發送多少份。

另一種是廣播，即點對多，就是發送方發送出去了，在一定范圍內，誰都可以接收，這個一定范圍，通常認為是不跨vlan(之所以說是通常認為，還有以路由器為界的，但其實發展到現在，路由器和交換機之間，在功能上的區別已經有些模糊了，只能說側重點不同)，即只要不涉及跨vlan，目之所及，廣播信息都能過去。

而因此存在的問題也很明顯。

單播存在的問題，因為只能一對一，如果有很多的設備都想要這個數據，那就需要每個設備自己向這個數據發送者索要，單獨給一份，因此，十個人要，發送者就要發十分，這顯然非常的冗余。

而廣播存在的問題，廣播在一定范圍內，能夠實現一對多的發送，即發送者只要發送一份，數據就在局域網內部，根據接收者需求，自行接收即可，但是其中的問題也是顯而易見的，數據跨不過vlan，就是數據怎么傳輸都只能在這個局域網內部，出不了局域網的大門。

因此，為了解決兩者的弊端，組播應運而生，組播最重要的兩個特點，通俗的講，就是走得遠并且只要傳一份。

組播技術，即組播協議，分為IMGPV1，IGMPV2，IGMPV3，根據應用場景和應用對象的不同，有所區分。組播協議有指定的IP網段，即224.XX.XX.XX-238.XX.XX.XX之間的網段，其中，232.XX.XX.XX又具備特別的用處，即用作指定源組播，即SSM模式，與之對應的，余下的組播網段稱之為ASM模式，即任意源組播。

組播的生效模式。雙方約定好組播地址。而后由數據的發送方往指定的組播地址發送數據。組播的接受方如果需要組播的數據，則需要接收方申請加入組播，加入組播的操作會在離接收設備的最近的交換機處開始，逐機往上申請加入，成功后，交換機會沿著組播交換機將數據發送至接收方。如果在同一個交換機下有多個接收者，則數據也只需要傳送一份，到末端交換機時再分發。

1.3 QoS技術

QoS(quality of service)即互聯網服務標準,它能夠保證了網絡應用程序的端到端的通信質量,并在所有互聯網數據經過的網絡路徑上保證了數據傳輸的帶寬、減少了數據傳輸的時延和降低了業務網的抖動,從而提高了業務網的數據傳輸品質[2]。本文根據航天業務網IPTV業務對網絡帶寬的安全性需求增大的現實情況,指出了帶寬問題可通過部署組播技術來處理,而網絡安全性要求采用QoS(服務質量保障)的方式處理。

當網絡系統中出現擁擠阻塞的情況,則任何的數據信息流都有可能被拋棄;而為了滿足對各種應用不同業務的需求,它就要求網絡能按照客戶的需求安排和調整設備,為不同類型的數據信息流提出差異化的服務質量:關于實時性要求高而較為重要的一類數據信息報文,優先進行數據處理;關于即時性要求并不高的一般數據信息報文,以相對較低的數據處理優先級,如果網絡擁擠阻塞則被拋棄。因此QoS業務應運而生。一個具有高QoS能力的系統,能夠實現高數據傳輸質量業務;凡是面向特定類型的數據流,系統能夠給其賦予特定等級的傳送優先權,以區分其相對重要性,并通過根據系統所具有的各種優先級轉發方式、阻塞避免措施等方式,對此類數據流進行特定的傳輸服務。采用了QoS的網絡協議方式,提高了網絡運行的可預知度,并能夠合理的安排網絡帶寬,更合理的使用網絡資源。

2 IPTV 承載網中的組播設計

2.1 組播IPTV承載網絡設計

組播流程的設計，以圖1所示拓撲圖為例。

1)CMS，即核心的媒體系統節點，為一級中心，當直播網絡視頻數據發送出來，會經過此處，而后通過單播協議下發到核心路由器，即圖中所使CR設備,CR路由器發送的數據，也是以單播協議的方式下發的，下一站就是IPTV專用的網絡交換機,而后仍舊是以單播協議的方式，發往中央媒體系統節點，即圖中HMS設備。

2)HMS中執行組播協議，具體為組播協議中的PM-SM協議，該協議用于路由器之間的組播路由表交換，將數據流量經IPTV交換機以及CR路由器發送至寬帶接入的服務器，即圖中所示BRAS，BRAS實則為一臺路由器，此時將IPTV交換機中連接HMS的端口，作為組播RP點，用作匯聚。

3)BRAS設備往下傳導數據時，是通過單播協議的發送至接收者終端所在網絡，中間傳導可以經光纖網(即圖中OLT設備)，或接入匯聚交換機(DS)。

圖1 IPTV承載網物理拓撲圖

2.2 視頻信號的組播發送

組播是一個SPT樹狀分發的結構，我們通常稱之為組播樹，從數據發送者送出數據(即從一棵樹的樹根處送出數據)，經一系列的組播路由器，即圖中的IPTV交換機、CR(可以認為是樹中的枝節)，一直到指定的樹枝處，到了末端樹枝處(BRAS路由器)下一步就是從枝節處開始分發。圖 2所示便是組播樹模型。

圖2 BRAS下IPTV 用戶對應的組播樹

通過組播傳輸數據的好處就是可以減少對帶寬的占用，同一個視頻數據，直到末端才會進行復制分發，再主干線路上，始終只需要傳輸一路視頻數據。比如,在BRAS下呈三個用戶可以一起收看發射地點的塔吊視頻,該視頻信號流量約2 Mbps。若采用單播方法傳輸,則在每一個路徑上都需要完成視頻信號所對應的數據包復制工作,需消耗帶寬為6 Mbps(3*2 Mbps);而如果有五千個用戶同時觀看,就要耗費總帶寬10 Gbps,將會超過現有路由器的線路帶寬造成阻塞。以組播方法發送的時候,組播樹BRAS中的路徑所對應的某一路視頻速率通常為2 Mbps,由BRAS按照目標用戶的具體數加以拷貝。組播形式的流量在傳播方向上要遠遠小于單播方式[5-6]。

圖3中顯示為組播與單播流量的對比。

圖3 組播和單播的流量比較

組播的缺陷是,無法對流量進行負載均衡處理。由于多媒體組播樹建立時不是環路,所以無法實現負載均衡處理。而一旦在多媒體組播樹人中的一個路徑上存在問題,例如數據傳輸品質較差或者鏈路阻塞,將會導致對IPTV視頻信號多媒體組播轉發的服務中斷,所以在多媒體組播樹人中就必須對組播流量進行服務質量保證。同時,由于PIM-SM協議是按照用戶的實際需求來分配多媒體組播數據包,當沒有用戶參與組播分組時,組廣播文不占帶寬,因而通過PIM-SM協議使用的任意源組播(ASM)模式,所有主機均能夠產生組播分組,同時接受并傳輸多媒體組播數據,使得在IPTV服務的實施過程中,非法組播資源能夠采用各種方法加入組播域中,這就需要對組播源加以控制。

3 IPTV承載網QoS設計

QoS技術的主要目的,是為了高效地向客戶提供從發送端到接收端的高質量業務或數據傳輸服務。在IP局域網上,通過QoS技術提高了網絡傳輸數據分組的效率。應用程序為了實現端到端的數據傳輸,必須同時通過幾個物理網絡,或經過幾個網絡設備。以實現整體QoS的三種服務方式:

盡力傳遞服務模型(Best-effort Service),最大能力把報文傳遞至目的地,但卻不能解決分組中發送數據包的延時、抖動和丟包等主要提問。

集成業務模型(IntServ),該模型是在數據傳輸之前，先讓數據發送者與數據接收者進行溝通，約定好數據資源，并且與沿途的交換機路由器也進行約定，直到數據傳送完畢，約定才會解除，該數據傳輸方式有高可靠性，但是對于網絡資源的占用非常的嚴重。

區別于服務模型(DiffServ),通過邊界路由器,可以按照各種情況對報文類型進行了劃分,并對各種形式的報文給出了不同的QoS支持,此方式所靈活且多樣耗費的網絡資源小。

因網絡中數據類型較多，選用區別服務模型。

QoS協議能作用在二層和三層網絡上，在二層網絡中,數據交換是以數據幀為基本單元的，可能涉及到交換機、無線接入設備(AP)、光網絡模塊(ONU)。而三層網絡交換需要路由器、三層網絡交換機、光纖終端(OLT)，當然也可以配置無線控制器(AC)實現無線功能。

典型的Qos的網絡如圖 4所示。

圖4 QoS部署網絡圖

QoS的執行步驟依次為流分類、流量監管、流量整形、擁塞管理、擁塞避免。

1)流分類。是交換機在接收數據時對數據流量的一個基本區分，二層網絡中通常可以通過數據報文中的802.1P字段進行區分，而三層網絡中，通常使用DSCP來進行區分，即根據數據包中的相應字段，通過MAC地址等信息，對數據類型進行區分，主要是網管數據、影像數據、任務數據。

2)流量監管。為了防止終端傳輸至網絡的數據流量異常而實施的一個數據監管，當數據流量超過設置的閾值后，會觸發信令捅及承諾訪問數據(CAR)功能，對指定數據進行限流操作。

3)流量整形。因為在流量監管中，通常對超出閾值的流量是進行丟棄操作，這樣對數據流量的安全性不能保證，甚至導致數據的丟失，因此設計了一套流量整形的協議，該協議下，只會對超閾值數據進行緩通行，而不會丟棄。在實驗中采用了通過流量整形技術(GTS)。

4)擁塞管理。擁塞管理是在數據流量進入網絡交換機或者路由器時，入口處已經發生堵塞時的策略設置，具體的現象可以體現在發送者與接收者之間的網絡時延上，時延明顯增大，即認為發生了堵塞，這時候對數據根據業務區分為不同數據流，根據設置的優先級，進行優先轉發，對于重要數據可以起到有效保證。通常使用優先權序列(PQ)協議在二層網絡起作用，采用加權公平序列(WFQ)在三層起作用。

5)擁塞避免。與擁塞管理不同的是，該部分內容是為了預防擁塞發生的策略，當有擁塞的趨勢時就會起作用，可以調節傳輸流量的大小來避免產生擁塞，常用的協議有隨機早期檢測(RED)。

4 IPTV網絡優化測試驗證

該部分內容介紹了如何使用OPNET軟件實現對網絡系統的仿真實驗，分別對單播、組播、組播搭配QOS策略進行仿真，對丟包率、時延和抖動等指標進行比較，從而驗證網絡優化的有效性。

4.1 仿真軟件介紹

網絡模擬領域,目前較為常用的網絡模擬軟件包括Berkeley NS,OMNet++,SSFNET,OPNET等,其中較為知名的是美國OPNET公司的OPNET系列模擬軟件,OPNET系統以面向研發的OPNET Modeler系統為核心,主要應用于大中型公司的智能化網絡系統設計涉及、環境控制等領域,其系統友好度、模擬效率、內存消耗等方面都較為突出。

OPNET是一種常見的網絡仿真技術軟件的功能包,它能夠更加精確的解析相對復雜的網絡系統的特性和行為,在常見的網絡系統建模中的任何一個地方都能夠接入自己的標準的建模,或是使用特定的探頭,用于收集特定的數據和并按需要進行計算。通過探頭所進行的模擬輸出,能夠以圖形化方法呈現、以數字方式方式進行、或是傳遞到第三方類別的軟件包中去。OPNET產品的基本架構大致有三種模板組成,能夠給用戶帶來大量的仿真模型庫,在行業,如咨詢服務、航空、行政部門、航空、工業系統集成、軍隊院校、電訊等方面都被應用。

4.2 OPNET仿真設計

4.2.1 OPNET建模流程

使用OPNET Modeler進行仿真一般可按照6個步驟進行：

1)建立網絡模型。

2)配置網絡拓撲(Topology)。使用OPNET所提供的向導,以及通過各相關編輯器進行設置環境、配置系統以及創建網絡拓撲系統等的工作操作。

3)配置業務(Traffic)。通過選定在該系統上工作的應用程序并選擇一個函數,即可向其進行系統分配工作量,即可進行系統的建模工作。

4)所收集的統計數據(Statistics)。統計測量是用來對所模擬系統進行可靠性檢查和評估的一句,通過選擇OPNET給出的所有數據指標進行選擇并獲取數據量的方法。

5)運行仿真(Simulation)。經過前三步的操作,雖然一個模擬環境場景已基本形成,但必須透過進行模擬來獲取仿真運行的信息。

6)觀察分析結果(ViewAndAnalyze Results)。利用對同一課題的各種情況(對應不同的方案)的模擬數據進行研究,即可形成研究論文,可以把有關圖表從OPNET中輸出到文檔中,以便于研究論文的參考。

為驗證網絡優化效果，使用OPNET進行仿真。

4.2.2 仿真網絡設計

4.2.2.1 網絡拓撲圖設計

1)設計一臺服務器，作為數據的發送端；

2)設計15臺設備終端，作為數據的接收端；

3)鏈路中添加兩臺路由器，作為數據轉發及路由選址。

4)鏈路中添加一臺交換機，作為15臺設備終端的集群中心，使得設備終端呈現星形。

數據運行原理設計：

1)數據從服務器發出。

2)經過兩臺路由器，一臺交換機，到達15臺數據終端。

3)15臺數據終端全部接收相同數據。

4)仿真數據選用每秒15幀，一幀為240*128像素的視頻數據。

根據如上設計，選擇網絡設備模型見表1。

表1 OPNET網絡模型選擇

在組播仿真拓撲圖中，與單播仿真拓撲圖不同的是，多了一個QoS管理的模塊：

圖5 組播及QoS仿真拓撲圖

在網絡中，各業務的帶寬流量見表2。

表2 業務流量統計表

4.2.2.2 仿真組播設計

在opnet中配置組播的基本設計需要實現如下功能。

1)配置終端設備支持組播協議，以實現組播組的加入和退出。

2)配置沿途的路由器支持組播協議，PIM和IGMP協議，實現組播成員的加入和退出，以及組播數據的轉發。

3)在某路由器上指定RP，可以指定自動或者靜態RP。動態RP需要啟動RP競選機制。

4)配置數據發送端，數據發送目的地是指定組播地址。

5)配置數據接收端，從指定組播組接收數據。

4.2.2.3 仿真QoS設計

1)配置RED策略。

2)配置流量整形，限速2 Mbps。

3)配置 CAR流量監視。

4)配置二層PQ協議，三層WFQ協議，均基于業務區分流量，即DSCP。

4.3 OPNET配置

4.3.1 應用業務配置器(Application Config)

1)即圖 5中的IPTV_application。

2)配置應用業務，可配置屬性包括但不限于，業務名稱(Name)，業務類型(如配置Video Conferencing)，具體的業務屬性(比如Video Conferencing中的每秒的幀數，每幀的像素數，決定了每秒的數據流量大小，以及該業務的網絡標值)。不同的網絡標識標識了在網絡種的不同的數據流，不同業務下就是以網絡標識區分不同的數據流，即Symbolic Destination Name，如果要用一個服務器，給不同客戶端發送數據流，需要配置不同的業務，注意要將不同的業務配置不同的策略。

3)在單播中需要配置多個業務，而組播中只需要配置一個業務流。

4.3.2 策略配置器

1)即圖 5中的IPTV_profile。

2)配置業務的策略，包含但不僅限于具體某業務的啟停時間，多個業務應當配置不同的策略。

3)一個業務的一個業務流，因此也就只需要配置一個策略。

4.3.3 服務器端配置

4.3.3.1 單播配置

1)即圖 5中的iptv_server工作站。

2)服務器端配置。屬性配置，這里需要至少配置兩部分內容，Applicaitions->Application:Destination Preferences(指定某數據流的流向，即發送目的地，在網絡設備中選擇)和Applicaitions->Application:Supported Profiles(指定發送策略，即什么數據業務什么時候發送，在策略配置器中配置好的策略中選擇)。

4.3.3.2 組播配置

1)包含單播配置。

2)需要配置啟用組播。IP->IP Host Parameters->Multicast Mode，修改值為Enabled。

3)修改目的地址為指定組播地址，如224.0.6.1。Applicaitions->Application:Destination Preferences->Actual Name->Name，修改為224.0.6.1。

4.3.4 客戶端配置

1)即圖 5中的Client_X系列工作站。

2)客戶端配置。屬性配置，主要配置Applicaitions->Application:Supported Services(支持的應用層業務，在業務配置器中配置好的業務中選擇)。

3)需要配置啟用組播。IP->IP Host Parameters->Multicast Mode，修改值為Enabled。

4)配置接收數據的組播地址。Applicaitions->Application:Multicasting Specification，配置Application Name為video，配置Membership Addresses為組播地址，即224.0.6.1。

4.3.5 路由器配置

1)啟用組播協議。IP Multicasting->IP Multicast Parameters->Multicast Routing，修改為Enabled。

2)指定使用組播協議端口。IP Multicasting->IP Multicast Parameters->Interface Information，建議添加所有UP連接著的端口，Status為enable，Routing Protocol(s)為PIM-SM。

3)啟用PIM協議。IP Multicasting->PIM Parameters->Status，修改為Enabled。

4)指定使用PIM協議的端口。IP Multicasting->PIM Parameters->Interface Information。建議添加所有UP連接著的端口，Version為2。

5)指定使用IGMP協議的端口。IP Multicasting->IGMP Parameters->Interface Information。建議添加所有UP連接著的端口，Status為Enabled， Version為2。

6)配置動態RP。IP Multicasting->PIM Parameters->Auto-RP Configuration下作幾處修改，啟用動態RP，修改Discover為Enabled，啟用映射，Map Configuration->Status為Enabled，Candidate RP Configuration下添加一行，配置Status為Enabled，Address/Interface的值，需要指定某個連接的端口，可以是這個端口的名稱，也可以是端口的IP，Candidate RP Configuration->Group Filter Configuration->Groups下添加組播組的地址，比如填寫224.0.6.1/32，添加掩碼。

4.3.6 QoS配置

1)添加QoS配置器，即QoS Attribute Config。見圖 5中的IPTV_QoS。

2)修改FIFO策略為RED。修改QoS配置器的屬性，FIFO Profiles->FIFO Profile->Details->RED Parameters，選擇RED。

3)修改需要配置QoS策略的網絡設備，選擇配置在路由器的連接服務器的端口上。與服務器連接的路由器端口為IF2，將QoS的配置，配置在端口上。IP->IP QoS Parameters->Interface Information。

4.4 網絡測試結果

4.4.1 服務器發送流量比較

以相同硬件環境仿真運行三十分鐘，在單播模式下，和以組播加QoS模式下的數據發送情況相比較，組播加QoS模式的數據發送流量約為單播模式下的九分之一，可見組播加QoS模式下，對帶寬占用更少。紅線為單播模式，藍線為組播加QoS模式。

圖6 數據總流量前后對比，單位為包數每秒

圖7 數據視頻流量前后對比，單位為位每秒

4.4.2 終端接收數據情況比較

以相同硬件環境仿真運行三十分鐘。比較數據接收情況，可以看見，在本次仿真中，單播和組播的數據接收情況幾乎一致，可以認為在本次仿真實驗中，兩者丟包情況一致，達到的效果一致。

圖8 數據接收端數據接收情況

4.4.3 時延抖動比較

以相同硬件環境仿真運行三十分鐘。比較時延方差，可以作為時延抖動的依據，可以看見組播加QoS模式的抖動幾乎為0，可以認為該模式的時延抖動遠小于單播。紅線為單播模式，藍線為組播加QoS模式。

圖9 時延抖動前后對比

4.4.4 時延值大小比較

以相同硬件環境仿真運行三十分鐘，比較時延，可以發現單播模式的時延值大約為組播加QoS模式的8倍，因此組播加QoS模式時延遠小于單播。紅線為單播模式，藍線為組播加QoS模式。

圖10 時延大小前后對比

5 結束語

用于承擔多種功能的試驗任務IP網絡,在網絡層和數據鏈路層的QoS功能是緩解網絡擁擠唯一可行的方法。本章主要講述了使用OPNET網絡的仿真軟件,以及構建基于組播和QoS技術的IPTV服務支撐網的基本流程,并分析仿真結果。網絡進行組播和QoS處理時,對IPTV承載網的大部分網絡數據進行了優化和調整,為業務網的主要服務內容節約了大量網絡資源。在這里探討了一個IP地址、VLAN和MAC物理地址的大流量QoS網絡架構,也為今后IPTV業務的維護提供了在一個大型廣域網中不同網絡接入環境下的優化維護方案。