多媒體內容傳遞網路前瞻技術之研究-子計畫一多媒體內容傳遞網路封包分類排程技術之研究(2/2)

(1)

行政院國家科學委員會專題研究計畫成果報告

子計畫一：多媒體內容傳遞網路封包分類排程技術之研究

(2/2)

計畫類別：整合型計畫計畫編號： NSC93-2213-E-002-056- 執行期間： 93 年 08 月 01 日至 94 年 09 月 30 日執行單位：國立臺灣大學電機工程學系暨研究所計畫主持人：蔡志宏報告類型：完整報告報告附件：出席國際會議研究心得報告及發表論文處理方式：本計畫可公開查詢

中華民國 94 年 12 月 22 日

(2)

行政院國家科學委員會專題研究計劃成果報告

多媒體內容傳遞網路前瞻技術之研究-子計畫一

多媒體內容傳遞網路封包分類排程技術之研究(2/2)

Packet Classification and Scheduling Technologies for

Multimedia Content Delivery Network

計畫編號：

NSC93-2213-E-002-056

執行期限：93年8月1日至94年9月31日

主持人：蔡志宏國立臺灣大學電信工程研究所教授

一、摘要

多媒體內容傳遞網路的建構方式有多種，本計畫所採用稱為 overlay network 應為未來主流之一。這個架構下核心網路上的路由器和交換機，本身並不一定扮演重要角色、甚至連服務品質保證也不一定全數提供。相對的，本計畫重點在於研發 Edge Router 上的分類及排程演算法有效控制由 P2P 用戶端，例如家庭網路之用戶端，至核心節點間的網路封包遺失率、延遲、頻寬穩定度等 QoS，並過濾不受歡迎的封包，以便可提供更好的多媒體內容傳遞服務。故本計劃擬兩年時間，提出實作並實測一套可以有效支援多媒體內容傳遞網路服務品質所需的分類及排程演算法。我們所提方法與傳統 IETF Diff Serv 最大不同之處，在於分級上明確可實作於 Linux 之分級法，並運用 AcK 封包之傳輸控制協助品質提升。在分類/排程控制法上我們則以有限計算複雜度為設計目標，以利我們在 Linux 平台上進行軟體實作。本計畫所完成之 Linux 平台分類及排程核心程式，則將利用自有之測試設備，以驗證其在 Gigabit Ethernet 網路上之操作效能及容量。關鍵詞：多媒體，服務品質，內容，網路 Abstract

Although there are many approach to deploy a multimedia content delivery network, the so called “Overlay Network” approach should be one of the main streams. In this network architecture, the core routers and core switched may play no important role, as long as the backbone bandwidth is

(3)

sufficient. And thus QoS may not be required. Hence, we focus on the research of classification and scheduling algorithms required on the Edge Router that determine the QoS (such as packet loss ratio, delay, bandwidth) between the P2P multimedia application users ( such as a portable terminal in Home Multimedia network ) and the core/overlay network nodes. The Edge Router is also required to filter unsolicited packets so that multimedia content delivery can be realized with better quality.

Hence this project completes the design and implementation of an efficient/effective classification and scheduling algorithm that can better support the multimedia content delivery. The major differences between our approach and the IETF DiffServ framework is the new definition the classification and scheduling which is feasible in Linux platform, and the concept of Ack spacing in Qos control. We plan to support premium class service with a complexity limited solution on Linux platform. Our implementation result will be test in a Gigabit Ethernet based testbed so that the capacity and performance of the Linux QoS router can be measured.

Keywords: Multimedia, QoS, Content,

Networking

二、計畫背景及目的

近年來 IEEE 802.11[1]無線區域網路迅速地進入了家庭及辦公環境，不但價格低廉，而且技術不斷進步，傳輸速率愈來愈高。而隨著無線網路的普及，幾乎所有現售筆記型電腦、 PDA 等皆可具備無線區域網路存取能力，大幅改變使用者上網方式，這也使視訊串流、網路電話等多媒體服務很自然地透過無線網路來傳播，我們終於有機會享受無線網路的便利性，在移動中隨時收看視訊串流，不再受到傳統有線網路的侷限。然而，使用無線網路有其固有之特性與限制，例如頻寬不穩定性、因衰減或干擾造成的封包漏失等。而視訊影像在使用目前編碼技術，如 MPEG-2[2]，MPEG4[3]，H.264[4]，及 Quick Time[5]，RealVideo[6]等，進行編碼時各影像框架之間可能具有相依性，一旦某封包發生錯誤或漏失，不僅會影響目前播放影像框架，也會連帶傳播錯誤到其他框架直至下一個關聯框架；此性質對於無回覆 ACK 封包與重傳機制的大多數視訊串流系統來說，影響收視品質甚鉅。再者，目前視訊串流群播技術在無線網路傳播時，無法妥善調整實體層傳送速率，以適應該區域之無線頻道狀態，使收視視訊串流時之網路瓶頸常發生在最後的無線網路端。在移動性方面，現行無線區域網路尚無完備的機制以使收看視訊串流的 mobile station(STA) 在不同接取點涵蓋範圍間自由移動而達到無縫交接，以現有 IEEE 802.11 的交接程序而言，當 STA

(4)

掃描新的接取點與傳送管理封包的過程時，無線收發器會持續切換使用頻道，此期間 STA 無法接收無線區域網路中的視訊串流封包，收看中的視訊影像會停格甚至中斷。而且當 STA 遠離原接取點，靠近新接取點時，自原接取點的信號強度會持續下降，使得視訊封包發生錯誤的機率大增，受到現有 802.11 通訊協定之限制，STA 移動過程中，若尚未完成 802.11 的交接程序，即使新接取點轉送相同群播視訊串流，STA 亦無法接收來自新接取點的信號強度較好之封包，使收看視訊串流的品質下降。由此可知，現有的 802.11 交接程序無法解決收看視訊串流之移動性問題。另一方面，由於 TCP 封包流具有 bursty 的現象，容易使得傳輸效能降低，也會影響到家庭網路內的多媒體串流封包，使其延遲、Jitter 變大，造成其品質下降。藉由 ACK 的控制，可以減少 TCP bursty 現象，提升多媒體串流節目之品質。針對既有技術瓶頸，本計畫乃提供一個改善現行系統表現之原型架構。在家庭網路端，針對無線環境下之群播視訊串流，設計並實作一個能有效改善無線區域視訊播放品質之適應性播放系統。在此系統中，收看視訊的使用者能移動在不同接取點的涵蓋範圍間，不中斷地收看群播之視訊串流，實現無縫交接。我們所設計的智慧型接取點可動態調整封包轉送原則與實體層傳輸速率。視訊串流伺服器則能即時調整視訊編碼位元率，以適應無線網路頻寬限制。本系統並可相容其他使用標準無線區域網路通訊協定的使用者。在對外存取網際網路端，我們設計了「分級 ACK 間隔器」，可以在 Home Gateway、路由器或是伺服器上安裝此分級 ACK 間隔器。它的功能主要是著重在對於 ACK 之間的間隔加以控制，加以控制之後，可以減少 TCP bursty 的現象，也因此降低對於 buffer 的需求。我們採用的技術是將封包的頭檔資訊從核心中讀取出來，並加以分析與排程。此間隔器也提供了分級速率控制的機制 (Rate-controllable class-based TCP packet fair queueing)。對於不同類別(Class)的封包，分級 ACK 間隔器採用固定的優先權順序來控管。對於同一 Class，不同的 TCP Session 之間，採用 Token Round Robin (TRR) 與 Frequency-Based Rotation Priority Queue (FBRPQ) 來達到公平性的要求。

三、系統架構與分析

整體系統架構可用圖 1 來表示，在右半部的家庭網路中，使用者以無線上網的方式，透過一個閘道器(Home Gateway)存取網際網路。總體來說可分為兩大部份：一為家庭網路端的家庭無線視訊群播服務系統，支援無縫交接之可適應性視訊串流群播。另一為 Home Gateway 或伺服器端的分級 ACK 間隔器。以下分別詳述此兩系統之詳細設計架構，並分析實驗結果：

(5)

3.1 家庭無線視訊群播服務系統

此系統的基本架構如圖 2 所示，主要應用環境為家庭室內空間，由家庭多媒體中心(Home Media Center)、群播路由器(可選擇性設置)、智慧型接取點(Smart AP)及 STA 所組成。以下分別介紹家庭無線視訊群播服務系統中，各裝置所提供之功能與實作方法。 3.1.1 家庭多媒體中心 家庭多媒體中心負責整合數位家庭多媒體服務，具備網際網路連線、視訊壓縮及轉碼的運算能力以及數位影像格式之儲存能力。家庭多媒體中心能將視訊來源以現有的先進壓縮標準如 MPEG-4、H.264 等技術進行編碼，產生低位元率、高影像品質之視訊串流，發送至家庭網路。當使用者收看視訊串流時，家庭多媒體中心與使用者終端設備建立連線，使用者欲變更服務內容時，能即時變更視訊編碼來源，即時滿足使用者之要求。為了適應使用者無線網路接收狀態之變化，如遭遇障礙物、頻道干擾或是移動至接取點涵蓋範圍之邊緣，或是執行交接程序期間可能漏失封包，家庭多媒體中心應能動態改變編碼中的視訊串流位元率，讓使用者在視訊服務不中斷的情形下，收看流暢的畫面與可接受的收視品質，如圖 3 所示。此功能在進行無縫式交接程序時尤其重要，當 STA 位於兩個接取點訊號涵蓋範圍之重疊區域時，可以要求多媒體中心即時調降編碼位元率，減少不同接取點訊號干擾所造成之影像品質下降。俟交接程序完成後，再要求伺服器調高編碼位元率，收看高品質的視訊串流。在實作上，家庭多媒體中心使用開放原始碼的 VideoLAN Client(VLC，[7])作為視訊編碼伺服器軟體，我們使用 VLC 軟體來播送 MPEG-4 編碼之 UDP 群播視訊串流。家庭多媒體中心在啟動 VLC 程式時，同時開啟 telnet 連線，供使用者連入家庭多媒體中心，進而達到下列功能。(1)要求家庭多媒體中心即時動態調整編碼位元率。(2)要求改變服務內容，播送其他節目。(3)要求家庭多媒體中心啟動即時錄影(PVR)服務。 3.1.2 群播路由器 當家庭網路具有一定的規模，或是系統應用於社區環境中，設置群播路由器可讓網路資源的利用更有效率。其主要功能是利用群播路由通訊協定如 DVMRP[8] 、 MOSPF[9] 、 PIM[10]、CBT[11]等，動態建立路由樹並轉送群播視訊串流封包。當有使用者欲接收群播封包，發出加入群組訊息，群播路由器便可動態加入群播群組並轉送封包；待使用者收視結束，發出離開群組訊息，群播路由器則更新路由樹，結束封包轉送，可節省網路資源。一般小型家庭網路無須設置群播路由器，我們所設計之智慧型接取點可依使用者位置與所收看之視訊頻道動態調整封包轉送原則，故亦能有效控制群播封包在家庭網路之傳播，提升無線網路使用效率。為了研究群播路由器的運作機

(6)

制，實作過程中我們亦在兩台安裝 FreeBSD 4.9 之個人電腦上，使用 eXtensible Open Router Platform (XORP，[12])軟體，架設執行 PIM-SM 協定之群播路由器，實際觀察群播路由器之間的管理封包交換情形，並確認群播路由器能有效管理群播封包之傳送。 3.1.3 智慧型接取點 智慧型接取點會持續監聽其接收範圍內是否有 STA 發出之 beacon 訊號，其帶有使用者收看節目之資訊與接收狀態，藉以判斷是否有人欲收看群播視訊串流並調整其封包轉送原則。當使用者遠離原接取點之涵蓋範圍，智慧型接取點藉由監聽 beacon 訊號，可感應 STA 離開，停止轉送群播封包。此做法之優點為可提升無線網路使用效率。透過 STA 所發出 beacon 回授之接收狀態，智慧型接取點亦能適應性地調整實體層傳輸速率，以改善該區域內使用者之接收狀態。圖 4 為本研究實作之智慧型接取點，外殼大小為 18cm*18cm*8.5cm，內部使用 Intel Pentuim-M 2.0G Dothan 的 CPU、512Mb 的記憶體並配備 Senao NL-2511CD PLUS 802.11 b 無線區域網路卡，作業系統為 Redhat Linux 9.0，並掛載由 Jouni Malinen 所開發之 Host AP 驅動程式[13]。在此組態下，我們可實作一接取點，大多數 802.11 管理機制均由驅動程式來執行，而非使用韌體執行，因此可進行許多功能之改寫與調整；部分須要即時性的功能仍由韌體來完成，像是傳送 beacon 與 ACK 等管理訊息。 3.1.4 Mobile Station Mobile Station(STA)為使用者所持之可攜式裝置，具無線網路存取及播放視訊之能力，其具備之功能為(1) 連線至家庭多媒體中心，發出編碼位元率變更請求與即時錄影要求。 (2) 同時自兩個以上的接取點接收視訊串流封包之能力，即多路徑接收(path diversity)，以達成無縫交接。(3)將接收狀態及欲收看之節目訊息置入長週期 beacon 訊號做為與鄰近接取點之回授頻道。 STA 所具備之回授機制分為二個層面。第一層為與家庭多媒體中心之間的 TCP/IP 回授連線，可得到適當的編碼位元率；第二層為與智慧型接取點之間之 MAC 層回授頻道，可反應使用者位置與收看狀態，並得到合適的實體層傳輸速率。在實作中，我們以安裝 Linux Redhat 9.0 之筆記型電腦，配備 Senao NL-2511CD PLUS 802.11b 無線區域網路卡做為 STA 端，並掛載 Host AP 驅動程式模組，採用 VLC 作為視訊串流播放軟體。為了達到無縫交接，STA 必須能多路徑接取，我們運用 Host AP 驅動程式，實作兩種方法，說明如下。 3.1.5 運用監控模式(monitor mode)之 多路徑接收 監控模式是 Intersil Prism 2/2.5/3 系列晶片中的測試功能之一，配合 Host AP 驅動程式，啟動監控模式後可監聽無線區域網路中單一頻道的所有封包，類似有線網路中的 Sniffer 協定

(7)

分析功能。Host AP 驅動程式原本利用此功能來監控無線頻道狀態，以協助排除連線問題。因此監控模式下所接收的所有封包，均會保留 802.11 的標頭(header)資訊，這些封包除了用類似 Ethereal 等封包分析程式來進行分析之外，傳送至使用者空間(user space) 的應用程式並無法使用。因此我們將 Host AP 驅動程式進行部分改寫，使接收到的封包經過處理後，接收封包可在 VLC 軟體進行播放，如圖 5 所示。 3.1.6 運用無線分散式系統(WDS)之 多路徑接收 無線分散式系統 (Wireless Distribution System, WDS)原本用途是利用接取點與接取點之間的無線網路連結，來橋接兩個有線網路，因此又稱為無線橋接器(Wireless Bridge)。本研究提出 WDS 模式的無縫交接方式，將 STA 設定為一個可移動的接取點，在其他固定式接取點之涵蓋範圍間活動，如圖 6 所示。因為可接收到其他接取點的 beacon 訊號，STA 可動態加入或刪除 WDS 連結；而其他接取點在監聽到 STA 發出的長週期 beacon 封包後，亦可動態加入或是刪除 WDS 連結，進而改變整體系統組態。以無線視訊串流應用而言，運用 WDS 的特性可以達到很好的效果，以下描述其運作方式。 STA 可接收來自數個智慧型接取點之封包，由 VLC 進行播放，故移動過程中視訊不會中斷。當接收狀況不佳，可傳送訊息至家庭多媒體中心要求即時調整編碼位元率。STA 持續發出長週期 beacon 訊號作為回授訊息。和前述監控模式相比較，使用 WDS 模式之多路徑接收有許多優點，列舉如下。 (1) 監控模式中，多個接取點播送之群播封包因為使用同一無線頻道，無合適的協調機制，若發生 hidden terminal 效應，易導致大量的訊號碰撞。這一點在使用 WDS 模式的多路徑接收方法中獲得解決，各智慧型接取點設定為以 RTS/CTS 模式來傳送視訊封包，可減少碰撞情形發生，有效提昇接收品質。 (2) STA 設定為監控模式時，暫時無法傳送資料，而當 WDS 模式下之 STA，可透過智慧型接取點向外傳送。故 WDS 模式之多路徑接收方式除了可收看群播視訊串流，也可提供瀏覽網頁、使用 VoIP 甚至視訊電話等許多服務。 (3) WDS 模式中下 STA，本身像一個 " 會移動的接取點 "，可發出 beacon 以建立回授機制，反應使用者動向、接收狀態等資訊，有助於接收影像品質與群播封包之管理。 3.1.7 實驗環境與實驗方式 本研究透過實驗證明我們所提出之系統能達到無縫式交接並且有效改善現行標準 802.11 的 infrastructure 模式之接收視訊品質。我們比較的對象為標準 802.11 之 infrastructure 模式、監控模式多路徑接收方式與 WDS 模式多路徑接收方式。為了檢驗無線區域網路之群播視

(8)

訊串流之收視品質，我們利用標準型式之公寓空間，實際建立一個播送群播視訊串流之無線網路環境，此環境經過無線區域網路分析儀 Airopeek NX[14]掃描分析，範圍內無其他無線網路干擾，適合作為實驗環境，其空間分佈如圖 7 所示。實驗所視訊來源是一個約 190 秒的影片檔，利用 ffmpeg 軟體[15]編碼為標準 MPEG-4 格式，影像大小為 352 ×240 像素，框率為 29.97 fps，計有 5512 個視訊框架。 STA 在每一次實驗過程中的移動方式皆依中之紅色路徑所表示，說明如下。(1) t = 0 至 t = 30，使用者停留在 A 位置。(2) t = 30 至 t = 50，使用者由 A 位置移動至 B 位置。(3) t = 50 至 t = 80，使用者停留在 B 位置。(4) t = 80 至 t = 90，使用者由 B 位置移動至 C 位置。(5) t = 90 至 t = 120，使用者停留在 C 位置。(6) t = 120 至 t = 140，使用者由 C 位置移動至 D 位置。(7) t = 140 至 t = 190，使用者停留在 D 位置。在本實驗中我們比較的數據為 (1)STA 以不同接收方式在移動期間所接收到的封包數量。 (2)STA 實際接收到的影像品質，以 PSNR(Peak Signal-to-Noise Ratio)做為比較標準， PSNR 的值愈高，代表影像品質愈好。根據 Feamster 等人之研究[16]，使用 MPEG-4 壓縮標準之視訊串流，具錯誤傳遞 (error propagation) 之現象，故影像品質對封包漏失非常敏感。圖 8 可以看出不同封包漏失率對影像品質之影像，一般低於 20dB 的影像品質即無法收看，故大於 2-8_的封包漏失率可能造成影像無法收視。 3.1.8 實驗結果與分析 3.1.8.1 標準的 802.11 之 infrastructure 模式 STA 分別使用 Senao NL-2511CD +與 Orinoco 802.11b Silver 無線網路卡進行六次實驗。表 1 與表 2 分別顯示使用兩張無線網路卡之接收封包數，漏失封包數與重覆接收封包數，我們可觀察到每次實驗均有大量封包漏失。圖 9 與圖 10 為使用兩張無線網路卡之漏失封包分佈情形，可看出移動過程中 STA 並未執行標準交接程序，這是因為 STA 接收到來自原接取點的訊號強度尚未衰減到啟動標準交接程序的門檻值，而且使用 Senao NL-2511CD+ 時明顯比 Orinoco 802.11b Silver 漏失較多封包，推測主要原因為不同產品或韌體版本間，其接收能力與啟動交接程序之門檻值可能不同，故有不同表現。 STA 端所接收影像之 PSNR 如圖 11 與圖 12 所示，實驗結果呈現出一致性，當 STA 遠離原接取點，有封包漏失時，因前述之錯誤傳遞現象，影像品質嚴重下降。 3.1.82 使用監控模式與 WDS 模式之 多路徑接收 使用多路徑接收方式之接收封包情形如表 3 與表 4 所示，可看出監控模式與 WDS 模式在實驗過程中，均無封包漏失，而 WDS 模式中因為具

(9)

有第二層的重傳機制，因此接收封包數幾乎是原傳送封包的兩倍，重覆接收的封包可提昇 STA 對接收錯誤的容忍性，並減少封包延遲。因為無封包漏失，在實驗過程中 STA 接收之影像品質均與原影像相同，圖 13 為 Infrastructure 模式與多路徑接收之影像品質比較，可看出本研究所提出之方法可達到無縫交接並改善接收影像品質。 3.2 分級 ACK 間隔器 3.2.1 分級 ACK 間隔器架構設計 分級 ACK 間隔器可以安裝在伺服器、路由器、閘道器或是使用者的電腦上，也可以和家庭多媒體中心 (Home Media Center)整合在一起。其架構在參考許多研究報告後[17-20]，設計如圖 14 所示。在最基本的實驗架構下，使用者從伺服器端下載檔案，當資料封包傳送給使用者後，使用者會回覆 ACK 至伺服器端。當封包進入了 ACK 辨識模組後，若封包被辨識為 ACK，則會進入到分級 ACK 間隔器中等待安排。如果封包不是 ACK，則會進入到逆向的網路緩存區。當 ACK 封包進入了分級 ACK 間隔器模組後，ACK 分類器會將所接收到的 ACK 進行分類，利用 iptables 模組[21-22]，可以辨識 WEB、FTP 以及 P2P 類型的 ACK。不同類別的 ACK 會進入到對應的佇列中等待排程。最後，ACK 會經由 ACK 排程器排定之後，進入網路卡的輸出緩存。圖 15 則針對分級 ACK 間隔器提出精簡的佇列模型分析。ACK 封包進入了不同 class 的 ACK 佇列 QAn，並且此佇列記錄了目前 ACK 預定被傳送的時間，與上一個 ACK 被傳送的時間。 3.2.2 實作程式架構設計 如圖 16 所示，分級 ACK 間隔器程式架構分成主要三個執行緒，Read Packet、Send Packet 與 Bucket Timer。 Read Packet 主要將 ACK 資訊讀取至 userspace 供程式做分發封包的判斷。 Send Packet 將目前選擇目前發送的封包，依照所設計的演算法，加以傳送。 Bucket Timer 依照所設計的演算法，每隔固定的小時間間隔，計算需要分派給各個 class 的 token，以達到間隔器的目的。 3.2.3 Class 的排程演算法 對於不同 Class 之間的排程問題，分級 ACK 間隔器採用靜態的優先權排序。間隔器依照 VoIP、WEB、 FTP、P2P 的優先順序發送封包。在封包佇列(Waiting Queue)中的封包依照優先順序，領取 token，傳送至網卡的輸出緩存，圖 17 敘述了在程式設計上詳細的流程圖。 3.2.4 Session 之偵測與排程演算法 要針對同一 class 中的每個 session 的 ACK 控制，必須先定義 session 的起點與終點。在 passive -mode FTP 與 WEB 檔案傳輸之下，經過 Ethereal 協定分析軟體實際偵測

(10)

後，從使用者端來看，我們定義當使用者發送給伺服器端一個 SYN 封包作為資料 session 的起點，而使用者向伺服器端發送 FIN/ACK 封包定義為終點。這在這之間所有使用者端向伺服器端傳送的 ACK 封包都會受到間隔器的控制，如圖 18 所示。對同一 class 之下的 ACK，我們提出了兩種排程演算法加以管理。第一種為 Token Round Robin (TRR) 演算法。TRR 的基本概念與程式設計流程圖如圖 19、圖 20 所示。對於 class 中的每一個 session，分級 ACK 間隔器會在每個 time slot 中，輪流地得到允許傳送封包的 token，希望利用此方法希望達成較高的公平性。第二種為 Frequency-Based Rotation Priority Queue (FBRPQ) 演算法，FBRPQ 是依照 Rotation Priority Queue [23]的設計加以修改。FBRPQ 的基本概念與程式設計流程圖如圖 21、圖 22 所示。對於 class 中的每一個 session，分級 ACK 間隔器會在上一個 rotation time slot 中，計算此 session 的 ACK 傳輸量。利用這個 ACK 傳輸量來決定目前這一個 rotation time slot 中，session 發送封包的優先順序。使用量越高的 session，其優先權將會越低，藉此方法希望達到對於超量用戶的限制。Rotation time slot 即為調整優先權的時間間隔。要將分級 ACK 間隔器實作在 Linux 系統中，程式設計的架構圖如圖 23 所示。主要控制的對像是使用者端向伺服器端所發送出的 ACK。當這些 ACK 進入分級 ACK 間隔器的網路輸入介面時，會被 ACK 核心中的辨識模組辨認出來，並且將 ACK 的標頭資訊讀入 userspace 中。此時分級 ACK 間隔器會依照所寫入的演算法來決定哪些 ACK 需要被送出，並且拉開 ACK 之間的距離，再送至網路輸出介面。若要實現可調適性的控制間隔器的話，可以將 CPU 負載、網路緩存的使用量等等資訊，送交分級 ACK 間隔器。實作完成的分級 ACK 間隔器，由於 Linux 核心的 iptables 幫助，可以輕易地安裝在 Linux 系統中各個網路檢查點，來達到不同的流量控制的效果。如圖 24 所示，ACK 間隔器可以安裝在 INPUT 、 OUTPUT 以及 FORWARD 等檢查點(hook)。 3.2.5 實驗結果與分析 3.2.5.1 傳輸速率效能與結果分析 此實驗是為了量測分級 ACK 間隔器對於傳輸速率的改善效果。實驗架構圖如圖 25。主要是客戶端向伺服器端要求檔案下載，並且在伺服器的網路輸入端加裝分級 ACK 間隔器，調整 ACK 輸入的速率並且將間隔拉開。在圖 26 中，比較了不同 ACK 間隔器參數設定，對於傳輸速率的影響。利用試誤法找出間隔器最佳的參數設定，避免傳輸中的緩存溢位，可以明顯改進傳輸效能。此外，圖 27、圖 28 則展示了，在啟動了分級 ACK 間隔器後，傳輸速率由於受到掌控，變得更加穩定，速

(11)

率也有提升。 3.2.5.2 Session 公平性的改進 此實驗是為了量測分級 ACK 間隔器對於同一個 class 中各 session 之間的公平性的改善效果。實驗架構圖如圖 29。主要是兩個客戶端分別向伺服器端要求檔案下載，並且在路由器的網路介面加裝分級 ACK 間隔器。圖 30 表示了各種不同的 session 排程方法所造成的公平性參數變化。圖 31 則展示平均公平性參數的比較。兩種 session 排程演算法之下，一般而言，TRR 表現最好，FBRPQ 次之（視 rotation time slot 決定），而不加以控制的對照組在公平性上表現最差。 3.2.5.3 CPU 使用率量測 在進行實驗的同時，我們也撰寫了 CPU 使用率的偵測程式，來計算分級 ACK 間隔器所消耗的 CPU 資源，並進行比較。由圖三十二可以得知，啟動分級 ACK 間隔器後，在 CPU 使用率上：TRR 佔用資源最多，FBRPQ 次之，而不加 session 控制的情境下， CPU 使用率最低。根據數據顯示，CPU 使用率都在可接受的範圍，這代表若將此間隔器實現在家用的網路路由器上是可行的。最後，圖 33 我們則比較各個 session 排程演算法，在各方面的評價，其中包括：平均傳輸速率、傳輸穩定度、頻寬使用量、公平性、CPU 資源與設計架構複雜度。結果顯示了分級 ACK 間隔器可以藉由改善路由器中緩存溢位的現象，來穩定與增加 TCP 傳輸效能。在公平性議題方面， TRR 與 FBRPQ 也都能夠達到良好的公平性表現。最後的 CPU 測試，也代表了這個實做的可行性，CPU 資源需求並不高。

四、結論與未來展望

本研究所提出之架構，在家庭網路端有一支援無縫交接之家庭無線視訊群播服務系統。在我們的實作系統中，利用監控模式與 WDS 模式兩種多路徑接收方式使 STA 在移動過程中，同時接收來自數個智慧型接取點的群播視訊封包，不但可實現無縫交接，亦提高對接收錯誤的容忍性，改善視訊品質。在連接網際網路的對外端，我們提出了一個可行的分級 ACK 間隔器的設計，藉由此間隔器對 ACK 間隔時間的控制，可以大大提升傳輸效率，也可以減少 TCP bursty 現象對多媒體串流封包的影響，提升多媒體節目之品質。在我們的實作系統中，對於不同 class 之間我們採取了靜態的優先權設計。對於同一 class 之內，針對公平性議題出發，我們提出了 TRR 與 FBRPQ 兩種排程演算法。本研究所提出之最具創新之設計有三：第一，當運用 WDS 模式之多路徑接收時，我們將使用者之終端設備提昇為接取點模式而非 client 模式，故可利用 STA 發出之 beacon 訊號，內含收視狀態等資訊可使鄰近的智慧型接取點知道使用者動態，並調整合適之實體層傳輸速率與封包大小。

(12)

第二，在收看視訊節目的過程中，STA 與家庭多媒體中心保持連線，當無線網路頻寬不足，或準備執行交接程序時，可要求家庭多媒體中心動態調整至適當編碼位元率，應適應網路環境，此為 IP 層的回授機制。在 WDS 模式下的 STA 更可進一步與智慧型接取點進行 MAC 層之回授機制，可改善局部區域內之訊號接收情形，故本系統共有二層回授機制之設計。第三，分級 ACK 間隔器可以藉由改善路由器中緩存溢位的現象，來穩定與增加 TCP 傳輸效能。其排程演算法 TRR 與 FBRPQ 也都能夠達到良好的公平性表現。此外，由於此分級 ACK 間隔器之設計對於 CPU 資源的需求並不高，也不需消耗太多資源在時序控制上，因此大大提高了其實作的可能性。本研究所提出之家庭無線視訊服務系統，可延伸至 VoIP、網路廣播與視訊電話等多媒體應用，因此系統中的 STA 裝置不但可以在移動中收看視訊節目，還能使用無線網路與其他人進行溝通。未來的家庭多媒體中心將整合各種新奇有趣的功能，例如家庭保全監視系統與幼兒看顧系統，隨時提供使用者各項警示訊息與使用者關心的影像畫面；甚至當使用者之可攜帶裝置具備攝影鏡頭，家庭多媒體中心可即時錄製使用者透過無線網路傳回之影像。隨著創意的實現與技術的成熟，數位家庭多媒體應用將更豐富我們的生活。

五、參考文獻

[1] IEEE. Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications. IEEE Standard 802.11, 1999.

[2] CCITT Recommendation MPEG-2, “Generic Coding of Moving Pictures and Associated Audio Information,” ISO/IEC 13818, Geneva, Switzerland, 1994.

[3] ISO/IEC 14496-2 MPEG-4 Video Coding Standard, “Information technology — Generic coding of audio-visual objects – Part 2: Visual,” Oct. 1998.

[4] Joint Video Team of ITU-T and ISO/IEC JTC 1, “Draft ITU-T Recommendation and Final Draft International Standard of Joint Video Specification (ITU-T Rec. H.264 | ISO/IEC 14496-10 AVC),” Joint Video Team (JVT) of ISO/IEC MPEG and ITU-T VCEG, JVT-G050, March 2003.

[5] Apple Computer,

http://www.apple.com/quicktime/

[6] Real networks, RealVideo 10 Technical Overview,

URL:https://helixcommunity.org/realcodecs/#R ealVideo

[7] VideoLAN (free software and open source video streaming solution for every OS).

Available: http://www.videolan.org/

[8] D. Waitzman, C. Partridge, BBN STC, S. Deering, “Distance Vector Multicast Routing Protocol,” RFC1075, Stanford University, November 1988.

(13)

RFC1584, Proteon, Inc., March 1994. [10] D. Estrin et al,“Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification,” RFC2362, June 1998. [11] A. Ballardie, “Core Based Trees (CBT version 2) Multicast Routing,” RFC2189, September 1997.

[12] eXtensible Open Router Platform.

Available: http://www.xorp.org/

[13] Host AP driver for Intersil Prism2/2.5/3.

Available: http://hostap.epitest.fi/

[14] Airepeek NX,

URL:http://www.wildpackets.com/products/airo peek_nx

[15] ffmpeg, a command line tool to convert one video file format to another.

Available:http://ffmpeg.sourceforge.net/index.p

hp

[16] N. Feamster and H. Balakrishnan, “Packet Loss Recovery for Streaming Video,” 12th International Packet Video Workshop, Pittsburgh, PA, April 2002.

[17]H. B. Chiou, S. D. Chin, Z. H. Tsai, “A Hierarchical Packet Fair Queueing-Based ACK Spacing Mechanism for TCP/IP over Internet Backbone,” IEICE Transactions on Communications, Vol.E85-B No.1, Jan. 2002.

[18]S. Floyd, V. Jacobson, “Link-sharing and resource management models for packet networks,” Networking, IEEE/ACM Transactions on , Volume: 3 , Issue: 4, p.p. 365 – 386, Aug. 1995..

[19]V. Jacobson, “Flexible, efficient resource management for datagram networks,” Sun Microsystems draft, October 12, 1993.

[20]J. Aweya, M. Ouellette, D. Y. Montuno, “A Self-Regulating TCP Acknowledgment Pacing Scheme” International Journal of Network Management Archive, Volume 12, Issue 3, p.p. 145-163, May/June 2002.

[21]The netfilter/iptables: Packet Filtering HOWTO,

http://www.netfilter.org/documentation/index.ht ml, Jan. 2002.

[22]The netfilter/iptables: Netfilter Hacking HOWTO,

http://www.netfilter.org/documentation/index.ht ml, July 2002.

[23]J. Liebeherr, D. E. Wrege, “A versatile packet multiplexer for quality-of-service networks,” Proceedings of the Fourth IEEE International Symposium, High Performance Distributed Computing, p.p. 148 - 155, Aug. 1995.

(14)

六、圖表

圖 1 此系統架構圖中使用者在家庭網路端使用 WDS mode 無線網路，收看多媒體串流節目，並透過一個具有分級 ACK 間隔器功能的閘道器存取網際網路。圖 2 家庭無線視訊群播服務系統架構：由家庭多媒體伺服器、群播路由器、智慧型接取點與 STA 所組成，其中群播路由器可依家庭網路規模大小選擇性設置。圖 3 執行交接程序時，動態變更編碼位元率示意圖：此機制可使視訊編碼位元率適應無線網路頻寬限制或避免執行交接程序期間之信號碰撞。圖 4 本研究實作之智慧型接取點，外殼大小為 18cm*18cm*8.5cm，內部使用 Intel Pentuim-M 2.0G Dothan 的 CPU、512Mb 的記憶體並配備 Senao NL-2511CD PLUS 802.11 b 無線區域網路卡。圖 5 監控模式多路徑接收示意圖：在此模式下，STA 可同時接收來自數個接取點之封包，但暫時無法向外傳送封包。

(15)

圖 6 WDS 模式之多路徑接收。STA 被設定為接取點，以 WDS 模式與數個智慧型接取點相連結，達到無縫式交接。圖 7 實驗環境之空間分佈與移動路徑：實驗過程中，STA 在 A、B、C 處各停留 30 秒，最後移動至 D 處。圖 8 不同封包漏失率對影像品質之影響，一般低於 20dB 的影像品質即無法收看，故大於 2-8_{的封包漏失率可能} 造成影像無法收視。圖 9 實驗中封包漏失分佈情形 (infrastructure 模式，使用 Senao NL2511CD+)：當 STA 遠離原接取點，封包出現連續漏失，且並未執行標準交接程序。圖 10 實驗中封包漏失分佈情形 (infrastructure 模式，使用 Orinoco 802.11b Silver)：在此次實驗中 STA 在二接取點之間漏失較多封包，但仍有零星封包漏失，影響影像品質。

(16)

圖 11 PSNR(infrastructure 模式，使用 Senao NL2511CD+) ：因封包大量漏失，遠離原接取點後，影像品質迅速下降。圖 12 PSNR(infrastructure 模式，使用 Orinoco 802.11b Silver)：因視訊壓縮之錯誤傳遞現象，封包漏失或發生錯誤仍嚴重影響影像品質。圖 13 WDS 模式與 Infrastructure 模式接收影像之 PSNR 比較：使用多路徑接收方式因無封包漏失，影像品質均等同於原始影像，優於使用標準 Infrastructure 之接收方式。圖 14 分級 ACK 間隔器架構圖，使用者向伺服器端要求檔案之後，ACK 便通過分級 ACK 間隔器回到伺服器端。圖 15 分級 ACK 間隔器的佇列模型，作為數學排隊理論分析的依據， ACK 進入依照類別進入不同的佇列中。圖 16 程式架構流程圖，主要程式分為三個執行緒，分別用以讀取封包、發送封包以及時序控制，彼此用信號控制。

(17)

圖 17 對於不同 Class 的排程流程圖，主要採取靜態的優先權排序。依照優先權高低領取 token，等待被發送。圖 18 Session 偵測流程，起點在於使用者端向伺服器端發送一個 SYN 封包，終點在於使用者向伺服器端發送 FIN/ACK 封包。

圖 19 Token Round Robin 基本概念，利用固定量的 token 在目標 session 之間輪流傳遞。擁有 token 的 session 可以立刻傳送。

圖 20 Token Round Robin 程式設計流程圖，作為程式設計的參考，主要分成發送封包與時序控制兩大部分。

圖 21 Frequency-Based Rotation Priority Queue 基本概念，主要是在每一個 rotation time slot 依照頻寬使用量調整 session 的優先權。

(18)

圖 22 Frequency-Based Rotation Priority Queue 程式設計流程圖，作為程式設計的參考，主要分成發送封包與時序控制兩大部分。圖 23 在 iptables 架構下的分級 ACK 間隔器，描述了在 Linux 系統中，所使用到的程式區塊，以及 ACK 的流程。圖 24 在 iptables 架構下的分級 ACK 間隔器，可以掛載在各種網路介面上，譬如使用者端的 OUTPUT、路由器的 FORWARD 以及伺服器端的 INPUT。圖 25 傳輸速率實驗架構圖，主要是客戶端向伺服器端要求檔案下載，並且在伺服器的網路輸入端加裝分級 ACK 間隔器，調整 ACK 輸入的速率並且將間隔拉開。

Throughput Analysis with WEB and FTP Class

2.742 5.258 7.759 7.664 7.009 2.620 2.739 6.049 0 1 2 3 4 5 6 7 8 9 FTP without Spacer FTP 2tok/2ms FTP 4tok/2ms FTP 6tok/2ms FTP 8tok/2ms FTP 10tok/2ms FTP+WEB without Spacer FTP+WEB 4tok/2ms Dat a Rat e ( M B /se c) 圖 26 平均傳輸速率比較。利用試誤法找出間隔器最佳的參數設定，避免傳輸中的緩存溢位，可以明顯改進傳輸效能。圖 27 啟動分級 ACK 間隔器前傳輸速率圖，有 WEB 與 FTP 傳輸進行中，速率並不穩定。

(19)

圖 28 啟動分級 ACK 間隔器後傳輸速率圖。有 WEB 與 FTP 傳輸進行中，速率較為穩定而且略有增加。圖 29 不同 session 排程演算法下公平性實驗架構圖。主要是兩個客戶端分別向伺服器端要求檔案下載，並且在路由器的網路介面加裝分級 ACK 間隔器。

Fairness Index vs. Time Graph

0.5 0.6 0.7 0.8 0.9 1 1 6 11 16 21 26 31 36 41 46 51 56 61 66 71 76 Time (sec) Fa irness Index No Session Control Token Round Robin FBRPQ RTS=10ms FBRPQ RTS=200ms FBRPQ RTS=500ms 圖 30 不同 session 排程演算法下公平性參數變化圖。由程式觀察每段時間內的公平性參數。 0.714 0.998 0.946 0.911 0.904 0.693 0.65 0.70 0.75 0.80 0.85 0.90 0.95 1.00 Without Session control Token Round Robin FBRPQ RTS=10ms FBRPQ RTS=200ms FBRPQ RTS=500ms FBRPQ RTS=1sec F a irn ess In d e x 圖 31 不同 session 排程演算法下，平均公平性參數。比較兩種 session 排程演算法之下，一般而言，TRR 表現最好，FBRPQ 次之（視 rotation time slot

決定），而不加以控制的對照組在公平性上表現最差。 3.261 5.376 5.682 4.651 7.865 10.870 10.112 9.195 6.330 7.701 7.935 6.984 3 4 5 6 7 8 9 10 11 12

No Session Control Token Round Robin FBRPQ RTS=10ms FBRPQ RTS=2sec

CP U L o a d ( % )

Minimum CPU Load Maximum CPU Load Average CPU Load

圖 32 不同 session 排程演算法下 CPU 使用率比較。啟動分級 ACK 間隔器後，在 CPU 使用率上：TRR 佔用資源最多，FBRPQ 次之，而不加 session 控制的情境下，CPU 使用率最低。圖 33 各個 session 排程演算法，在各方面的評價，其中包括：平均傳輸速

(20)

率、傳輸穩定度、頻寬使用量、公平性、CPU 資源與設計架構複雜度。(5 分為最高、1 分為最差。) 接收封包數漏失封包數重覆封包數 01 8380 898 0 02 7600 1678 0 03 8787 491 0 04 7894 1384 0 05 9214 64 0 06 7982 1296 0 伺服器共傳送 9278 個封包表 1 接收封包數(infrastructure 模式，使用 Senao NL2511CD+)：各次實驗中均有大量封包漏失。接收封包數漏失封包數重覆封包數 01 8363 915 0 02 9050 228 0 03 9022 256 0 04 9000 278 0 05 8905 373 0 06 8651 327 0 伺服器共傳送 9278 個封包表 2 接收封包數(infrastructure 模式，使用 Orinoco 802.11b Silver)：封包漏失數較使用 Senao 網路卡少，但仍有部份封包漏失。接收封包數漏失封包數重覆封包數 01 16676 0 7398 02 16680 0 7402 03 16547 0 7269 04 16906 0 7628 05 16852 0 7574 06 16873 0 7595 伺服器共傳送 9278 個封包表 3 接收封包數(運用監控模式之多路徑接收)：實驗過程中 STA 可接收許多重覆視訊封包，提高對接收錯誤的容忍性。接收封包數漏失封包數重覆封包數 01 18384 0 9106 02 18179 0 8901 03 18173 0 8895 04 18395 0 9117 05 16800 0 7522 06 18208 0 8930 伺服器共傳送 9278 個封包表 4 接收封包數(運用 WDS 模式之多路徑接收)：因為具有 MAC 層重傳機制，STA 在各次實驗中幾乎均收到原始封包的兩倍。