車載無線網路環境下標頭壓縮之適應性聚集封包機制

(1)

國立臺中教育大學資訊科學學系碩士論文

車載無線網路環境下標頭壓縮之適應

性聚集封包機制

An Adaptive Mechanism of Packet

Aggregation for Header Compression in

VANET

指導教授：王讚彬教授

研究生：陳昱群撰

中華民國一百年六月

(2)

致謝

首先誠摯的感謝我的指導教授王讚彬老師，不辭辛苦的悉心指導，不時的與我討論並指導我的研究方向，使我能順利得完成此論文，並培養出我所欠缺的能力，以及無論在課業或做人處事皆不厭其煩地指出我的缺失，並及時在我迷網時為我解惑。本論文的完成另外亦得感謝口試委員竇其仁老師、嚴力行老師、李國川老師和張林煌老師提供寶貴的建議，使得本論文能更加完整充實。感謝實驗室的學長與同學們：豐旭學長、介民、國唐、博仁、怡涵、益華、瑋辰和冠霖等，在日常生活上的照應及學業上的討論，特別是介民真的很謝謝你陪我度過最難熬的時間和幫忙我適應了這裡的環境。感謝實驗室的學弟妹們，裕其、佩珊，有你們的幫忙使得研究過程更為順利。碩士班兩年的生活一晃眼就過了，在經過了兩個寒暑，總算順利的畢業了，過程中雖然很辛苦，感觸也很多，需要學習的東西更多，但我會用這兩年所學到的研究方法與精神，在另一條道路上繼續前進，努力去做好每ㄧ件該做的工作，盡我所能做到最好。最後，要感謝我的父親、母親對我的支持，讓我能無憂無慮地完成我的碩士學位，僅以本論文獻給所有關心我的人，謝謝你們。昱群一百年孟夏于網路通訊實驗室

(3)

摘要

由於各種無線技術的發達，包含無線區域網路(WiFi)、第三代行動通訊(3G)、全球互通微波存取(WiMax)、短距離無線通訊(DSRC)等異質網路環境相繼建立，異質網路也就漸趨複雜，同時在車載行動網路(Vehicular Network)中，節省電源並不是主要問題，但是無線資源卻是有限的，為了使頻寬更有效率的使用，因此使用標頭壓縮不僅可以減少標頭的浪費，縮小封包大小之外並且可使用封包聚集來增加壓縮效益，但是因為車載行動網路是 multi-hop 的環境，必須考量到延遲可能變高，且因為並無連結 (association) 動作，需要接收端請求 (solicitation-based)通訊協定配合，因此我們整合接收端請求協定提出標頭壓縮之適應性聚集封包的機制，使可以在有限的 delay 下，提升壓縮的效益。本論文主要著重在車載行動網路環境下的標頭壓縮技術，而 IEEE 802.11p 標準設計來讓車輛與車輛 (V2V) 之間的 ad-hoc network 可以做資料傳輸。然而，因為車載行動網路中車速快且移動性高，路由路徑變化快，在資料傳輸上，為了能節省頻寬的使用並減少傳送封包之數量，使用標頭壓縮與封包聚集能提高在頻寬裡傳輸資料流量的使用率，且也可以提高在多媒體網路上的 throughput，所以利用我們的方法在資料傳輸的 delay 時間上和壓縮效益取得一個平衡。我們的作法在車載行動網路中，可以降低延遲時間，且也可以降低網路壅塞的情況，並提高 throughput 或 utilization，使得車載網路的傳送 traffic 成功率也可提高。

(4)

Abstract

The advances in wireless technology, such as WiFi, 3G, DSRC, and WiMax, have made the wireless networking environment heterogeneous. Parts of these wireless technologies will be deployed in vehicular mobile networks. In vehicular networks, the power saving might not be the major problem, but the wireless resources are scarce. Therefore, how to make efficient use of wireless bandwidth is one of the most important issues in vehicular networks.

Generally, header compression can be used with packet aggregation to make more efficient use of wireless bandwidth. Header compression reduces the waste of the header size, while packet aggregation reduces the number of packets. Unfortunately, packet aggregation might increase the end-to-end delay in multi-hop vehicular environment.

On the other hand, routing path might change frequently due to the high-speed and high-mobility characteristics in vehicular networks. In the literature, a solicitation-based MAC protocol is used for solving dramatic path change due to high mobility and the lack of association in IEEE 802.11p.

The goal of this thesis focuses on header compression and packet aggregation in vehicular networks. We integrate a solicitation-based protocol and propose an adaptive packet aggregation mechanism for header compression. The proposed mechanism will make use of the solicitation-based MAC protocol and make a tradeoff between delay time and compression efficiency.

(5)

目錄

中文摘要...I 英文摘要...II 目錄...III 表目錄...V 圖目錄...VI 第一章 緒論...1 1.1. 前言...1 1.2. 研究動機與目的...2 1.3. 論文架構...2 第二章 背景與相關研究...4 2.1. 車載無線網路簡介...4 2.2. 車載網路 MAC protocol 機制簡介...8

2.2.1. A solicitation-based IEEE 802.11p MAC protocol...8

2.2.2. A Distributed MAC Scheme for Emergency Message Dissemination...11

2.2.3. Clustering-Based Multichannel MAC Protocols...13

2.3. 現行標頭壓縮方法及封包聚集的觀念和作法...15 第三章 標頭壓縮之適應性聚集封包機制...22 3.1. 問題描述...22 3.2. 適應性聚集封包機制...23 第四章 數學模式的效能分析...28 4.1. 數值分析項目...28 4.2. 效能評估...29 第五章 模擬環境的修改：NS2 的實作...32 5.1. NS2 網路模擬程式介紹...32

(6)

5.2.1 節點架構的修改...33 5.2.2 適應性聚集封包機制...34 5.2.3 ping agent 模組的新增與修改...38 5.2.4 聚集的 queue...38 5.2.5 解聚集的 agent...40 第六章 實驗模擬分析與結果...41 6.1. 影響 delay time 的評估...41

6.1.1 routing protocol 對於 delay time 的影響...41

6.1.2 干擾距離對於 delay time 的影響...43

6.2. 實驗環境設置...45

6.3. String-Topology...47

6.3.1 平均 end to end delay 比較...47

6.3.2 封包到達率比較...51

6.4. Freeway-Topology...56

6.4.1 平均 end to end delay 比較...57

6.4.2 封包到達率比較...61

第七章 結論與未來工作...64

7.1. 結論...64

7.2. 未來工作...65

(7)

表目錄

表 6-1：模擬參數 ... 42 表 6-2：模擬參數 ... 43 表 6-3：共用模擬參數設定 ... 46 表 6-4：CBR 參數設定 ... 46 表 6-5：FTP 參數設定 ... 47 表 6-6：模擬參數定義 ... 57

(8)

圖目錄

圖 2-1：車載行動網路 ... 5 圖 2-2：車載行動網路的協定架構 ... 8 圖 2-3：基本的標頭壓縮方法 ... 16 圖 2-4：標頭壓縮和封包聚集 ... 19 圖 3-1：動態聚集封包 ... 23 圖 3-2：適應性聚集封包演算法 ... 25 圖 3-3：slow-start adaptive 程序 ... 26 圖 3-4：fast-recovery adaptive 程序 ... 27 圖 4-1：車載 multi-hop 環境 ... 28 圖 4-2：聚集封包數量的壓縮比率 ... 29 圖 4-3：不同 hop count 的最大聚集數量 ... 30 圖 4-4：不同 hop count 的壓縮比率 ... 30 圖 4-5：不同 hop delay 的聚集封包數量 ... 31

圖 5-1：Extended and modified node model ... 33

圖 5-2：函數 aggablesize( ) ... 35 圖 5-3：函數 add_by_Maxdelay() ... 36 圖 5-4：聚集演算法的流程圖 ... 37 圖 5-5：量測 RTT 並動態調整聚集封包的數目 ... 38 圖 5-6：函數 enque( ) ... 39 圖 5-7：節錄自函數 deque( ) ... 40 圖 6-1：String-Topology 實驗架構圖 ... 41 圖 6-2：封包 delay time 的分析 ... 43 圖 6-3：封包 delay time 的分析 ... 45 圖 6-4：String-Topology ... 47 圖 6-5：傳輸 CBR 不同環境下的平均延遲時間 ... 48 圖 6-6：減輕 traffic Rate 傳輸 CBR 的平均延遲時間... 48 圖 6-7：傳輸 FTP 不同環境下的平均延遲時間 ... 49 圖 6-8：不同 QueueingMaxDelay 時傳輸 CBR 和 FTP 的平均延遲時間得比較 ... 50 圖 6-9：傳輸 CBR 不同環境下的封包到達率 ... 51 圖 6-10：傳輸 CBR 不同環境下的平均聚集封包數目 ... 51 圖 6-11：減輕 traffic Rate 傳輸 CBR 的封包到達率 ... 52 圖 6-12：減輕 traffic Rate 傳輸 CBR 的平均聚集封包數目... 53 圖 6-13：傳輸 FTP 不同環境下的封包到達率 ... 54

(9)

圖 6-14：不同 QueueingMaxDelay 傳輸 CBR 或 FTP 的封包到達率 ... 55 圖 6-15：Freeway-Topology ... 56 圖 6-16：傳輸 CBR 在不同平均車速下的平均延遲時間 ... 58 圖 6-17：傳輸 FTP 在不同平均車速下的平均延遲時間 ... 59 圖 6-18：不同平均時速時傳輸 CBR 和 FTP 的平均延遲時間的比較 ... 61 圖 6-19：傳輸 CBR 在不同平均車速下的封包到達率 ... 62 圖 6-20：減輕 traffic Rate 傳輸 CBR 的封包到達率... 63

(10)

(11)

第一章緒論

1.1. 前言 在無線網際網路的發展中 IEEE 802.11[1] (a)(b)(g)(n) 已經相當成熟，直到最近即時性的多媒體應用也漸漸的廣泛漫延，像是網路電話的服務也逐漸被許多公司、大學、住家所接受，那麼這些應用的效能則值得我們去注意。由於無線網路使用的普及，在無線 Mesh 網路裡雖然有許多應用服務而使用 VoIP 是個重要的應用，因為無線 Mesh 網路的動態性，在設計上會有些重要的挑戰及如何最佳化這些服務，QoS 是個重要的因素，在 VoIP 裡封包的資料大小通常會小於標頭大小，考慮到網路的可用頻寬，可利用標頭壓縮來最佳化使用率，然而使用標頭壓縮卻對服務帶來一些損害，對 VoIP 來講會遺失封包。標頭壓縮技術應用在無線網路環境中可節省無線資源，避免無線資源的浪費，且隨著無線 Mesh 網路越來越普及，以 VoIP 為例，配置 VoIP 技術在這種網路上面可以提供一個重要的服務，而我們也需要考量到傳輸 VoIP 時的封包效能和 delay time，因為 VoIP 並不能容忍 delay time 太長，但使用標頭壓縮搭配封包聚集可能會增加 delay time，對於即時性或非即時性的應用服務可能會有不同的效能影響。而 Mesh 的骨幹是由無線路由器所組成，其覆蓋範圍則依賴於路由器的數量和位置，然而，因為無線網路的動態連結特性，使配置即時性的多媒體服務在 Mesh 網路上變得有點困難。

另外，目前舊有的 IEEE 802.11 標準並不適合用在高移動性的車載無線網路環境下，因此由 IEEE 802.11 團隊再將 IEEE 802.11 延伸擴充而制定了 IEEE 802.11p [2]。車載通訊網路除了較底層的 IEEE 802.11p 其上層還包括 IEEE 1609 系列[3][4][5][6]，我們將其通稱為 WAVE (Wireless Access in the Vehicular

(12)

Environment) standards。另一方面，車載通訊網路也可稱為 WAVE network。 1.2. 研究動機與目的 在本篇論文中我們的方法可適用於各種應用服務的資料傳輸而不侷限於特定的應用，而 IEEE 802.11p 標準設計來讓車輛與車輛 (V2V) 之間的 ad-hoc network 可以做資料傳輸。然而，因為 Vehicular Network 中車速快且移動性高，路由路徑變化快，在資料傳輸上，為了能節省頻寬的使用並減少傳送封包之數量，使用標頭壓縮與封包聚集能提高在頻寬裡傳輸資料流量的使用率，且也可以提高在多媒體網路上的 throughput，但封包聚集時可能會延長 end-to-end delay。由於我們使用了標頭壓縮減少了標頭的浪費，另外還將多個封包聚集成一個大的封包再傳輸，可以減少網路上封包的碰撞機率，使得封包到達率可以提高。且在目前固定式封包聚集得作法中，若在聚集時只固定聚集特定數目的封包，會造成壓縮效益不高且會有一個固定的 delay 時間在等待形成聚集封包，所以我們提出標頭壓縮之適應性聚集封包的機制，因此本論文主要著重在 Vehicular Network 環境下的封包聚集與標頭壓縮技術，利用我們的方法在資料傳輸的 delay 時間上和壓縮效益取得一個平衡。 1.3. 論文架構 本篇論文總共分為七個章節，各章節的簡介如下：第二章首先淺談目前車載網路的相關發展與研究，包括車載網路技術 VANET MAC protocol 機制。並詳細的描述現行標頭壓縮方法及封包聚集的觀念和做法；第三章將詳述本論文

(13)

所提出之適應性聚集封包機制；第四章我們透過數學模式進行了初步的效能分析，主要分析評估了壓縮比率；第五章將詳述在 NS2 裡適應性聚集封包的實作；第六章顯示了我們的實驗分析結果，實驗場景分為 2 部分，分別為 String-Topology 和 Freeway-Topology，並分析比較平均 end to end delay 和封包到達率，藉此驗證本論文所提出之機制可最小化延遲時間，且也可以使網路壅塞的情況降低，並提高 throughput；第七章為本論文的結論。

(14)

第二章背景與相關研究

本章針對本論文的背景與相關研究的部份進行一整體性的描述與說明，並為後面的章節所要解決的問題之基礎知識，以下列出本章各節的內容概述： 2.1. 車載無線網路簡介描述目前車載網路的發展。 2.2. 車載網路 MAC protocol 機制簡介描述目前車載網路裡 MAC protocol 得相關研究。 2.3. 現行標頭壓縮方法及封包聚集的觀念和作法描述現行常用的標頭壓縮方法和封包聚集得相關研究。 2.1. 車載無線網路簡介 車載網路主要自發形成於移動的車輛之間，而這些車輛配備的無線設備可能產生類似的或不同的無線介接技術，車載網路採用短程到中程的通訊系統，提供附近的車輛中的通訊和車輛跟路邊附近的固定裝置之間的通訊，車載網路採用的短程通訊系統(DSRC)，在北美所用的頻寬是75 MHz，在歐洲則用CSC-CC 標準，而IEEE 也正發展IEEE1609 的車載環境標準。車載網路的架構主要有3種包括：(i)一個純無線的車輛對車輛網路(V2V)， (ii)在有線和無線的骨幹上跳躍，可以看做是一個WLAN，如車載網路，(iii)一個混合型車輛對路上(V2R)的架構，可以不長時間依賴一個固定的基礎設施，車輛也可透過single hop 或multi-hip 的形式進行通訊，依C2C-CC 參考架構區分3 個主要部分(如圖2-1)。

(15)

圖 2-1：車載行動網路

其中車載(In-vehicle)部分包括(i) an on-board unit (OBU) and (ii) one or more application unit(s) (AU)，OBU在車子裡是個裝置具有有線或無線的通訊能力， AU可執行一個或多個應用程式且同時利用在OBU 的通信能力，而ad hoc 部分是由很多台車配有許多的OBU 和固定在路邊設備(Road Side Unit，RSU)所組成的網路，不同於移動型ad hoc(MANET)，而OBUs 至少有一個OBU 包括近程無線通信設備專用道路安全，而OBUs 和RSUs 可視為Ad Hoc 網路的節點，分別為移動型根靜態的節點，RSUs 可連接到基礎設施，而連到Internet，RSUs 可相互溝通或Multi-hop，其主要作用是改善道路安全，兩種類型的infrastructure domain 包括RSU 和熱點，OBU 可透過RSU 連接到Internet。

由於車輛可不經由基礎設施直接和其他車輛通訊，所以車輛彼此間可合作和轉發些資訊，此外，考量車輛的節點負責收集和轉發重要訊息，車輛的收集和處理資訊可藉由智能型sensors。車載網路的特性有：(i) 無限制傳輸功率，(ii) 更高的計算能力，(iii) 可預測性，車載網路要面對的挑戰的特性有：(i)潛在的巨大規模:許多研究文獻都認為是有限的網路規模，所以車載網路想達成巨大規模原則上可延伸到整個公路網。(ii)高移動性:在低流量時，相對速度達300km/h，也想有高移動性以及在高流量時，相對速度達60km/h，(iii)分割網路:車載網路

(16)

間的縫隙可能會造成一些孤立的節點，(iv)網路的拓墣和連通性。車載網路的應用和服務包括有即時性和安全的應用，目標在降低意外和改善交通情況，對於安全性上的應用網路的管理員必須有認證的機制，而非安全性上的應用則要有授權存取的服務和使用者付費的服務。

IEEE 802.11p（又稱WAVE；Wireless Access in the Vehicular Environment）是一個由IEEE 802.11標準擴充的通訊協定，這個通訊協定主要用在車用電子的無線通訊上。它基本上是從IEEE 802.11來擴充延伸，來符合智慧型運輸系統（Intelligent Transportation Systems，ITS）的相關應用。應用的層面包含高速率的車輛與車輛 (Vehicular-to-Vehicular ： V2V) 以及車輛與路邊基礎設施 (Vehicular to Roadside Unit：V2R) 間的封包交換，其使用的頻帶為5.9GHz (5.85-5.925 GHz)，此頻帶上有75MHz的頻寬，以10MHz為單位切割，將有七個頻道可供操作。其中一個頻道為控制頻道，其他則為服務頻道。

利用IEEE 802.11a規格作為實體層(Physical Layer)通訊技術，IEEE 802.11p 相關應用以DSRC原先所規畫的方向為主，並加強車用安全，包括碰撞警示或道路危險警示等。為了在運輸方面無縫、可和諧操作的服務，WAVE 網路服務提供車載裝置、管理服務以及各協定層之間的資料傳遞，其標準包括了IEEE Std 1609.1、IEEE Std 1609.2、IEEE Std 1609.3、IEEE Std 1609.4、及IEEE Std 802.11 等。 IEEE 1609 系列標準是美國電子電機工程師協會(IEEE)針對無線接取技術應用於車用環境無線存取(WAVE)時，所定義出的通訊系統架構及一系列標準化的服務和接口。其主要目的為制定車輛與車輛(V2V)間、車輛與基礎設施 (V2R)間之標準無線通訊協定，並藉此提供行車環境下，包括汽車安全性、自動收費、增強導航、交通管理等廣泛應用情境所需之通訊協定標準。 IEEE1609 系列技術標準包含了有IEEE1609.1、IEEE1609.2、IEEE1609.3、 IEEE1609.4，長久以來，受限於無線通訊技術於高速移動中的應用挑戰，以及不同車商間缺乏一致的通訊介面，車輛與外界的溝通一直受到相當大的限制。

(17)

有鑑於此，世界各國莫不以制定車用通訊標準為其重要交通政策，如美國交通部提出智慧型運輸系統(ITS)相關計畫便是一例。而IEEE 便結合了政府、車廠及電信大廠共同制定IEEE 1609 系列技術標準，為行車環境中的各項應用情境提供可能之解決方案。 z IEEE:IEEE1609 family 包括以下 z IEEE1609.1:用於資源管理，包含應用程式的讀寫、RSU 和OBU 的協定。 z IEEE1609.2:用於安全服務定義了5.9GHz DSRC 的安全、匿名性、認證、和機密性。 z IEEE1609.3:用於網路服務定義了網路層和傳輸層的服務，包含定址和路由。 z IEEE1609.4:Multichannel Operations提供了DSRC頻寬的協調和管理。在WAVE 系統[2]中，一個具有DSRC 的設備與另一個具有DSRC 設備的操作相互作用時，可以執行WBSS 或WIBSS。WBSS 是指由一個RSU 跟一個或多個OBUs 作通訊，WIBSS 是指只在OBUs之間相互通訊。也就是說WAVE 的通訊可以在RSUs 和OBUs 之間或是只在OBUs 之間。WAVE 的通訊也可以經由RSUs 繞送到廣域網路，或是經由OBU 直接在車內網路作通訊。 WAVE 能支援兩種通訊協定：車用無線存取環境短訊息協定WSMP 以及標準網際網路協定IPv6 兩種資料交換的通訊協定。 WSMP 被設計來提升在WAVE 的傳輸效率，WSM 可以使用任意頻道傳輸 (CCH or SCH)。他允許應用程式直接控制實體層PHY 的能力(例如：發送頻道、傳送功率…等)。WSM 的接收端(destination)則是根據WSM所帶的Provider Service Identifier (PSID) 來判斷要送給哪一個application。每一個 PSID代表著不同的 service 類別，它是由 IEEE Registration Authority 所管理。IPv6 僅能使用在SCH 多重服務頻道，他允許存取一般的應用程式與網路。

(18)

供優質的服務質量（QoS），不同車輛的網路應用，介質訪問控制（MAC）是其中一個主要挑戰，通訊為基礎的主動安全性將會走向主動的安全系統，這些系統可在早期階段提供了一個信息的警告在司機或車輛有潛在危險的情況下。車載網路將支持生命的關鍵安全應用，安全預警應用，電子收費，網路存取，群組通訊，路邊服務尋找，對於MAC 協定的IEEE 標準，已完成的IEEE 的標準 IEEE P1609.1，P1609.2，P1609.3，andP1609.4 於車輛網絡。

圖2-2為對於車載通訊的IEEE 協定架構:

圖 2-2：車載行動網路的協定架構

2.2. 車載網路 MAC protocol 機制簡介

2.2.1. A solicitation-based IEEE 802.11p MAC protocol [7]

為了使IEEE 802.11p的標準更有效率，論文[7]解決以下幾個問題： 1. Stateless Channel Access:

由於在WBSS裡沒有authentication and association，所以如果當WBSS使用者離開了WBSS提供者的區域時，WBSS提供者會不知道WBSS使用者是不是還在他區域裡。在這種環境裡，如果提供者的buffer裡有資料要傳給使用者，就會一

(19)

直繼續的傳，直到重傳的數目到一個門檻值。且在一個多速率WBSS的WBSS 提供者，在缺乏ACK frames，可能可以使用較低的比特率。也會導致浪費無線頻道。

2. Caching for Handoff:

因為WBSS 使用者經常性的從一個WBSS移動到另一個交換資料，且它的速度可以很高，所以, IEEE 802.11p需要支持快速換手在多個WBSS提供者。此論文提到一個提出過的方法叫Inter-Access Point Protocol (IAPP)，當移動的站台改變了他目前associated AP，它可主動的caching以減少訊號delay在re-association 的程序，但是，這不能使用，因為沒有association 的程序在IEEE 802.11p。 3. Opportunistic Frame Scheduling:

WBSS用戶在WBSS內移動時，因為高速會導致大量和快速變化的通道條件，所以WBSS使用者會經常性遇到暫時的斷線於WBSS提供者，因此資料傳輸須根據通道狀態在機會的方式裡。此外，比特率，應及時的確定，在瞬時狀態的無線通道處理其快速變化。

論文[7]提出WBSS User Initiation Mode (W-UIM)和Dynamic WAVE-Area 這 2個方法去解決這些挑戰，其中WBSS-Area是一種新的觀念，它是一個虛擬的群組由相鄰的WBSSs所組成。並假設WBSS提供者共享路邊骨幹有線網路以提供足夠頻寬。

1. WBSS User Initiation Mode

在W-UIM裡，WBSS提供者只是代表這裡有一個WBSS，它不能啟動資料傳輸給WBSS使用者，而所有的資料傳輸都是由user所啟動。此論文在這介紹了一個新的WAVE-poll frame，在WAVE-poll frame裡WAVE mode欄位代表W-UIM是否啟動，PHY Tx Rate欄位是根據WBSS使用者的通道狀態填入一個比特率，供 WBSS提供者傳輸資料。

(20)

使用者會傳輸一個WAVE-poll frame並把WAVE Mode 欄位設為1代表啟動 W-UIM，此外，WBSS使用者會根據最新和WBSS提供者傳輸時的通道狀態，紀錄適當的比特率到PHY Tx Rate欄位。每當WBSS使用者想從WBSS提供者接收資料時，都必須傳輸WAVE poll frame，而WBSS提供者收到WAVE-poll frame且 WAVE Mode欄位是1時，就可傳輸資料給WBSS使用者。

Solicitation-based data transmissions in W-UIM主要可分三種情形說明：第一種情況是，如果WBSS提供者buffer裡有資料要傳給使用者，那麼他會先等待SIFS的時間後根據WBSS-poll frame裡規定好的比特率傳輸資料，當使用者收完資料後會等待SIFS時間後傳回一個ACK frame。

第二種情況是，如果WBSS提供者沒有資料要傳給使用者，那麼他會先等待 SIFS 的時間後直接傳回一個 ACK rame ，這個 ACK rame 代表成功收到 WBSS-poll frame。第三種情況，如果資料不能在SIFS內準備好傳出，那麼WBSS提供者會先傳一個ACK代表收到WBSS-poll frame，之後再等待SIFS的時間後傳出資料。在W-UIM裡，重傳lost的資料訊框也是從WBSS使用者所啟動的，也是會先傳輸WBSS-poll frame，這是為了消除WBSS使用者移出提供者範圍時造成的問題。如果WBSS使用者不怎麼移動且傳輸速度很低，會導致很多WBSS-poll frame，這時可選擇性的把WAVE Mode欄位設為０，當WBSS提供者收到WBSS-poll frame並發現WAVE Mode為0時，它可直接傳輸資料不需再等WBSS-poll frame。 2. Dynamic WAVE-Area 在W-UIM裡，相鄰WBSS提供者可以組成一個高速cache和轉發的區域，儘管使用者fast handoff也可轉發frame，在WAVE-Area裡的WBSS提供者可以cache 資料訊框和proactively or reactively的轉發，然後，當WBSS使用者加入到新的 WBSS時，也可從新的WBSS使用者接收cached資料。在proactively模式裡，當要傳給使用者的資料有很多時(buffer快滿時)，可預先轉發給WAVE-Area裡的其他提供者，WBSS提供者也可從相鄰的提供者更新

(21)

cached資料。

在 reactively 模式裡，如果 WBSS 使用者聽到不同於目前的 WBSS announcement，使用者可能會發送一個轉發請求到目前WBSS提供者，則目前的 WBSS提供者會轉發資料給相鄰的提供者。這種模式的優點：可減少buffer的 overhead，消除些不必要的forwarding and caching。但是缺點是相鄰的WBSSs可能會經常發生訊框的碰撞。

2.2.2 A Distributed MAC Scheme for Emergency Message Dissemination [8]

緊急訊息在傳送到附近節點時必須是沒有延遲，而緊急訊息的傳輸對於 MAC協定在車載裡也是個挑戰，因為在典型的車載裡必須是完全分散的方式又因為不斷的在網路裡移動和改變節點，隨著完全分散式的MAC協定，封包可能會遇到不可預知的延遲，是由於deferrals和backoffs，長時間的MAC delay在緊急訊息的傳輸裡是不能容忍的，而不同類型的緊急訊息也會有不同的lifetime，除了延遲，封包遺失，也是一個嚴重的問題而常見的封包遺失來源則是有hidden terminals問題，所以需要lossless的MAC協定，論文[8]認為lossless的MAC協定作法是忽略因為碰撞造成的lose，並藉著pulse-based control機制，在完全分散式的方式裡論文[8]提出的方案可實現對緊急封包等級優先權排程並支持多種等級。論文[8]方法的好處： 1. 可以有效的支持車載裡的緊急訊息傳輸。 2. 可以智慧的使用一個控制通道做多種用途。

3. 可以對每個緊急封包實現低且穩定的 MAC delay ，也不會有 hidden terminals問題。

4. 提供每個緊急封包有多種等級的優先權排程。

pulses基本上是一個有著隨機長度的單頻波，控制通道在任何時間裡都被任何節點所監聽，除了當那些節點在傳輸時會停止監聽，應用層會定義出緊急封

(22)

包的等級並把這些資訊放在封包標頭，此論文提出的方案是假設共存於現有的 IEEE 802.11 MAC協定，即讓現有的協定處理正常的封包，此論文提出的MAC 則處理緊急性的封包。論文[8]提出的方法有以下步驟： 1. 當一個緊急封包到達一個節點的MAC時。 2. 如果控制通道是閒置的，節點會先啟動backoff timer。 3. 否則，表示通道忙碌，則會持續監聽控制通道。 4. backoff timer是隨機的，且是從緊急訊息的等級來定義的。 5. 當backoff timer到期時，節點會先傳輸pulses在控制通道裡，之後在廣播緊急封包在資料通道。 6. 如果在backoff timer到期前，偵測到pulse，會取消其timer，並回復到監聽控制通道。在論文[8]裡，在控制通道裡的pulse被稱為priopulses。當節點收到priopulse 時，會暫停自己的priopulse，並釋放通道，而接收緊急封包的節點也會relays priopulse抑制hidden terminals。在緊急封包有多種等級的情況時： 1. 假設一個節點要傳的緊急封包等級為Lx，但目前通道等級為Lr且忙碌，比較Lx和Lr。 2. 如果Lx > Lr，一旦priopulse暫停，就可啟動競爭的程序搶奪資料通道。 3. 否則，則會持續監聽控制通道。當節點在傳輸資料時，priopulses也會跟隨著送，priopulses會停止只有在緊急封包傳完或有人中斷。每個priopulse包含active part和pause part of random length。

active part有2個功用：

1. 抑制hidden terminals，任何節點聽到priopulse會中止其傳輸。 2. 可傳送緊急訊息的等級。

(23)

假設active part的長度為Pa即代表緊急訊息等級為level L，表示longer active part會有higher level，即L1 > L2 if Pa1 > Pa2。

另外，random pause part則是支持多層級的優先權緊急訊息，而論文[8]提出的這方法又可稱為PreempPrio–MAC，因為他有preemptive priority service提供給緊急訊息的傳輸。

2.2.3 Clustering-Based Multichannel MAC Protocols [9]

論文[9]提出一個使用 contention-free 和 contention-based MAC protocol來整合clustering的方法。並且使用 analytical model 在 the delay of safety messages 和the successful rate of delivering safety messages 中取得 tradeoff 的平衡來獲得最佳的QoS。就是在有real-time safety message在傳送時，還可以有效率的傳送 nonreal-time 的 traffic。

在此系統下，鄰近的車子會形成一個cluster並且選擇出一個cluster-head，在每個cluster-head的車子上其中一個收發器在CRC channel上使用contention-free TDMA-based MAC來收集和傳送安全性訊息，另一個收發器在ICC channel上透過contention-based MAC 在兩個鄰近cluster-head vehicles之間交換整理合併過的安全性訊息。在cluster-member vehicle中其中一個收發器在CRC channel上是專門用來和他們的cluster-head vehicle做溝通，另一個收發器在由cluster-head指派的ICD/CRD channel上傳送nonreal-time traffic。

其作法主要發展三個協定，包括Cluster Configuration Protocol、Inter-cluster Communication Protocol與Intra-cluster Coordination and Communication Protocol，來處理以下三個任務：1. cluster-membership management; 2. real-time traffic delivery; 3. nonreal-time data communications.

(24)

cluster-head會週期性的廣播invite-to-join(ITJ)的訊息，所以當有新的車子加入時，如果他有收到ITJ的訊息時，就會回傳request-to-join(RTJ)給Cluster-Head，訊息中會夾帶車子的ID和網路位址資訊，cluster-head收到RTJ之後再回傳ACK 的訊息給車子，並且將此車子加入他的cluster member list中。如果新的車子加入時無法收到ITJ的訊息，此時他就會自己成為一個Cluster-Head。

2. Intracluster Coordination and Communication Protocol

Cluster members傳送安全訊息和一個頻道保留的要求給Cluster-Head， Cluster-Head會整理這些安全訊息並且根據頻道保留的要求訊息來分配頻道，這些頻道是用來傳送或接收非即時性的訊息。

3. Intercluster Communication Protocol:

real-time safety messages: 在ICC頻道上傳送。 nonreal-time traffic: 在ICD頻道上傳送。

cluster-head: 將收集到的安全訊息整理合併之後透過競爭到的ICC頻道，傳給周圍鄰居的cluster heads。在車載無線網路中，儘管大家注意的是如何設計在車輛間緊急訊息的可靠且即時傳輸，但是在道路上也可傳輸一些非安全性的資料，像是需要 QoS 的舒適和娛樂的應用服務(例如，多媒體、網頁瀏覽、電子郵件、電子地圖、VoIP) 。 WAVE network 中，省電不是主要的問題，但是無線資源卻是有限的，為了使頻寬更有效率的使用，因此使用標頭壓縮可以增加在多媒體網路的 throughput，減少在通道裡的控制訊息和可以增加在頻寬裡傳輸資料流量的使用率，但是使用標頭壓縮會導致多媒體應用對於封包遺失的容錯減少。標頭壓縮的技術也能搭配聚集封包的方法，使壓縮效益增加，但對於某些服務例如 VoIP，聚集封包的方法會使 delay 時間變高，有鑑於此，我們設計一種適應性聚集封包方法來達到在可接受的 delay 時間底下，取得最好的壓縮效益，並使 delay 時間不會太高。

(25)

使用者離開了WBSS提供者的區域時，WBSS提供者會不知道WBSS使用者是不是還在他區域裡。在這種環境裡，如果提供者的buffer裡有資料要傳給使用者，就會一直繼續的傳，直到重傳的數目到一個門檻值。且在一個多速率WBSS的 WBSS提供者，在缺乏ACK frames，可能可以使用較低的比特率，也會導致浪費無線頻道，所以WBSS使用者須以solicitation-based論文[7]的方式去取得資料才不會有這問題。因此本論文基於 solicitation 的方式我們提出適應性聚集封包的機制，來達到在壓縮效益下和 delay 作一個平衡，以提昇在車載無線網路環境中使用標頭壓縮資料傳輸的壓縮比率，由於在 WAVE network 中，車輛如果可以 solicitation-based 的方式去向 RSU 取得資料，那麼我們可以在 sender 端(RSU) 以自然的方式加入聚集封包作為傳輸，則 receiver 端 solicitation 完成之後再去取得聚集封包，此作法在 WAVE network 環境中，可最小化 delay time，且也可以使網路壅塞的情況降低，並提高 throughput，使得車載網路的行動管理上的 traffic 成功率也可提高。 2.3. 現行標頭壓縮方法及封包聚集的觀念和作法 如圖 2-3 所示，標頭壓縮技術主要是改良傳輸資料流量的使用率，一個基本的標頭壓縮系統是由 compressor 和 decompressor 所組成，壓縮器和解壓縮器間必須總是保持同步，如果不同步，解壓縮器可能無法解壓縮每個收到的壓縮封包，而實作標頭壓縮是藉由減少封包多餘的標頭資訊，然後，在壓縮器和解壓縮器裡減少後的資訊會存到一個結構裡稱為 context。在 RFC3095[10]和 RFC4815[11]標準裡也制定了一個標頭壓縮的方法，稱為 Robust Header Compression (ROHC) ，ROHC 的壓縮方法可從較低等級的可靠度改變到完全可靠的模式， ROHC 可以實作在三種不同的模式，如下： unidirectional mode(U-mode) 、 bidirectional optimistic mode (O-mode) 、

(26)

bidirectional reliable mode (R-mode)。在 bidirectional mode 裡 ROHC 需要一個回饋的通道，但是在非對稱無線連結時，可能回饋的通道不能用，使得 ROHC 也不能使用，在 unidirectional mode 則是單純的從壓縮機送封包到解壓縮機。

圖 2-3：基本的標頭壓縮方法

2.3.1 Header Compression for VoIP [12]

由於無線網路使用的普及，在無線 Mesh 網路裡使用 VoIP 是個重要的應用，因為無線 Mesh 網路的動態性，在設計上會有些重要的挑戰及如何最佳化這些服務，Qos 是個重要的因素，在 VoIP 裡封包的資料大小通常會小於標頭大小，考慮到網路的可用頻寬，可利用標頭壓縮來最佳化使用率，然而使用標頭壓縮卻對服務帶來一些損害，對 VoIP 來講會遺失封包，在論文[12]裡，作者提出 Cooperative Header Compression (CoHC)，以增加 VoIP 電話的品質和減緩一些損害。

(27)

一. 以下介紹論文[12]提出的方法：

網路裡的遺失封包會造成壓縮器和解壓縮器之間的同步遺失，如果發生封包遺失，解壓縮器會丟掉每個收到的壓縮封包，因為無法正確的解壓縮，解壓縮器必須需要前一個封包的標頭資訊來更新 context 以達到成功的解壓縮。

CoHC 的主要想法使用多通道和附加一個額外的資訊來互助以達到避免同步遺失，每個封包會帶著一個額外資訊稱為 Additional Information Container (AIC)，而 AIC 裡會存放一些標頭資訊來復原壓縮機和解壓縮機之間的同步遺失，所以 CoHC 可以避免同步遺失卻不能復原遺失的封包資料，CoHC 可配置在單通道和雙通道。在單通道裡，通道裡的封包所攜帶的 AIC 會攜帶有關自己的 context 的資訊，在多通道互助方法裡，不同的通道可以互助幫忙藉由封包所攜帶的 AIC 裡會有其他 context 的資訊，AIC 的大小和壓縮效益間必須取得一個平衡，結構裡的資訊越多，復原同步遺失的機率就越高，所以可以說 CoHC 是一個方法而不是一個標頭壓縮的演算法，CoHC 在論文[12]裡是採用搭配 RoHC 標頭壓縮的演算法。這個作法的優點是可以避免同步遺失使通話品質可加強，缺點則是不能回復遺失的封包資料。我們可以從論文[13]和論文[14]裡看到，在過去也有提出一些關於標頭壓縮和封包聚集的論文，這些論文顯現了使用標頭壓縮和封包聚集像是可以分為2 個部分來執行。

2.3.2 An Alternative Approach for Header Compression [15]

使用標頭壓縮可以增加在多媒體網路的生產量，減少在通道裡的控制訊息和可以增加在頻寬裡傳輸資料流量的使用率，但是使用標頭壓縮會導致多媒體應用對於封包遺失的容錯減少，在論文[15]裡作者提出一個另一種方法的標頭壓縮，它不會有封包遺失產生的問題，也不使用recent memory，recent memory 指

(28)

的是由於解壓縮需要前一個收到的封包，這稱為recent memory並且使用封包聚集來增加壓縮效益。 一.以下介紹論文[15]提出的方法： 在封包標頭欄位可以分類為靜態、動態和推斷型，靜態是整個 session 裡都不會改變，動態則是 session 裡會改變，而推斷型則是一個計算值得欄位或被其他欄位所包含，目前的標頭壓縮技術則是從這 3 類都壓縮就能達到較高的壓縮等級，例如：ROHC，但是若壓縮標頭的動態欄位會對 context 資訊帶來必要的更新。當連續的封包遺失，解壓機可能會失去同步而不能正確的解壓縮，考慮到大部份的標頭欄位都是靜態的，則作者提出使用靜態壓縮，在使用靜態壓縮的情形裡，context 不需要同步也不須常常更新，因為只壓縮靜態欄位，在 session 裡不會改變，若封包遺失也不會有太大影響，而動態欄位則還是放在標頭欄位裡，這會造成比較低的壓縮效益，卻能減少 context 所需要的更新，如果封包遺失，後來的封包還是可以成功的解壓縮，因為他們有自己的動態資訊，為了增加壓縮效益，論文[15]提出了封包聚集合作的方法搭配靜態壓縮機制。如圖 2-4 所示，動態標頭欄位在連續封包裡按順序改變或很少改變可以視為是冗餘的，聚集的方法可以減少這些冗餘，在靜態壓縮之後，可以制定一個數量的封包形成一個聚集封包，在論文[15]裡採用以 2 個封包形成一個聚集封包，之後，在聚集封包間可以使用第二次壓縮，減少動態欄位的資訊，分析 VoIP 的行為，可以容易得找到在連續的封包間的動態欄位有相同的值。而這些動態欄位可以形成聚集標頭。這個作法優點是就算封包遺失，還是可以使用標頭壓縮與解壓縮，但缺點是考量在 VoIP 裡的 delay 問題，由於這個作法每次都必須等 2 個封包形成一個聚集封包之後，才送出去給目的端，所以會有一個固定的 delay，且以 VoIP 來說，在 multi-hop 環境下，delay 時間會很大，而固定 2 個封包形成聚集封包之後，其壓縮比率亦有其限制。

(29)

圖 2-4：標頭壓縮和封包聚集

2.3.3. IP Header Compression And Packet Aggregation [16]

在移動戰術網路發展通訊的技術目標是能提供在異質無線電系統裡整合資料和語音的服務，而目前移動性的網路協定多半設計為 single hop 的無線區域網路和電信網路，論文[16]主要考量了網路層協定的 overhead 例如：TCP/IP 和 UDP/IP 的 overhead，而壓縮網路層協定的標頭則是減少或消除個別資料裡不會改變或定期改變的欄位。

移動戰術裡採用 TDMA-based 的 MAC 需要固定 size 的資料大小，由於一個 MAC frame 只有一個封包，若只減少一個封包的標頭則不會有太大助益，因此論文[16]想要使用封包聚集，使得能在一個 MAC frame 裡能減少多個封包的標頭提高壓縮效益，所以封包聚集的意思是能在一個 MAC frame 裡加入多個封包，只要 MAC 可以處理分析出封包就可以克服浪費 MAC frame 空間的問題。

(30)

一. 以下介紹論文[16]提出的方法：

Packet Aggregation：

在無線網路裡使用封包聚集的方法是可以藉由聚集多個封包再發送來減少每個封包 MAC 和 physical 的 overhead ，而論文[16]利用此概念想在每個 TDMA MAC-frame 的 payload 盡可能的連接多個封包搭配壓縮標頭，使 TDMA MAC payload (TMP) 的 size 可以最大的使用，而聚集資料滿足 TMP 可以有 2 種方法，第一種是當利用較小的語音封包要來滿足一個 MAC-frame 是一個背包問題，儘管目前有許多演算法的解法卻也還是個 NP-hard，且此方法有個問題是不保證公平性即是比較大的封包會有缺乏資源不容易加入 MAC-frame 的問題，第二種是利用聚集封包的方法，允許存在一個優先權的方法，在 MAC layer 聚集封包時利用 weighted fair queuing (WFQ)來改善傳輸時的公平性，使用封包聚集的方法在戰術網路裡有 2 個主要的優點，一個是在資源有限的戰術網路裡可以減少複雜的演算 queuing，且也可以最大化 per-TMP data 的傳輸，所以此篇論文作者採用第 2 種聚集封包的方法。 標頭欄位的分類： Static (unchanging)：封包裡不會改變的欄位。 Implied (calculable) ：需要從其他欄位計算出值的欄位。 Predictable (compressible)：在封包之間定期的改變，是可以壓縮的。 Unpredictable (uncompressible)：每個封包都會改變其值，所以不可壓縮。 Required (for routing)：每個 hop 時都需要的網路層欄位以確保封包可以正確的傳遞到目的端。 Compression Methodology： 由於封包一但遺失，會造成接收端無法順利解壓縮接下來的封包，因此有 2 個方法可解決這問題，一個是若有 feedback channel 可用來通知同步已經遺失並且重傳，另一個是若無 feedback channel 則可以定期發送完整的封包標頭。因為戰術網路頻寬是有限的且有 delay 的問題，因此論文 [16] 採用

(31)

lightweight 的方法避免 feedback 並著重在 end-to-end 的壓縮，所以一開始會先送未壓縮的封包和完整的標頭直到解壓縮端發送 synchronisation acknowledgment，一但同步完成則壓縮端會移除 static 和 implied 的欄位和發送出壓縮標頭，這方法的優點在於可減少由於同步錯誤所產生的封包遺失，所以論文[16]的方法類似只做靜態壓縮。 2.4. Summary 本章節主要說明了目前標頭壓縮的作法和封包聚集的概念，而在目前固定式封包聚集得作法裡，若在聚集時只固定聚集 2 個封包，會造成壓縮效益不高，使得壓縮效益有其限制，所以我們在第三章提出標頭壓縮之適應性聚集封包的機制。

(32)

第三章標頭壓縮之適應性聚集封包機制

本章節的內容主要在說明本論文之研究方法，包括研究動機、欲研究問題之描述。此外，更詳述本論文所提出之適應性聚集封包機制，不僅可降低 end to end delay 也可增加封包到達率。 3.1. 問題描述描述研究動機及在封包聚集裡欲研究之問題。 3.2. 適應性聚集封包機制描述本論文所提出之方法。 3.1. 問題描述 在車載無線網路環境中，因為並無 association，導致當 WBSS 使用者移出了 WBSS 提供者的範圍時，WBSS 提供者無法知道 WBSS 使用者移出此範圍，因此我們整合了 solicitation-based 在車載無線網路傳輸裡，而 solicitation-based 的方式即是傳輸資料都由 WBSS 使用者所啟動發出請求，所以當車輛如果可以 solicitation-based 的方式去向 RSU 請求資料，那麼我們可以在 sender 端(RSU) 以自然的方式加入聚集封包作為傳輸，此外，當車輛在做 solicitation 的時間時可配合來做封包聚集，則 receiver 端 solicitation 完成之後再去取得聚集封包。

另外，我們的機制能傳輸一般性的各種應用服務，我們利用標頭壓縮和聚集多個封包變成一個大封包的概念，能使網路上傳輸的封包量減少自然而然也能降低封包的碰撞，那麼資料傳輸的效能也就能提高，而且我們考慮了網路上傳輸的 delay 狀況來聚集封包，因此也能降低 end to end delay。

(33)

圖 3-1：動態聚集封包由於我們希望在車載無線網路環境中為了可以使頻寬更有效率的使用，因此我們藉由標頭壓縮的技術來達成，如圖 3-1 所示，我們在第一部分也是先做靜態壓縮，而在第二部分則配合我們提出的適應性聚集封包機制並把重覆的動態欄位資訊再做壓縮，因此壓縮方式也是採用 2 個部分來執行。由於在聚集時若只固定聚集 2 個封包，會造成壓縮效益不高且會有一個固定的 delay 時間在等待形成聚集封包，所以我們基於 solicitation-based 提出適應性聚集封包演算法來提高壓縮效益，且根據 delay 時間來調整聚集的封包數目。 3.2. 適應性聚集封包機制 適應性聚集封包機制主要可分成 adaptive 與 aggregation 這 2 部分，如圖 3-2 所示，我們先找出合適的聚集封包的大小，再去做聚集的動作，由於我們分為 adaptive 程序和 aggregation 程序，使得在程式撰寫維護上可增加其便利性，

(34)

adaptive 程序是找出合適的聚集封包數目，aggregation 程序是做聚集的功能， delay 是網路的 round trip time (RTT) 時間，threshold 我們假設是 delay 時間 80ms， QueueingMaxDelay 是我們可自定的在 queue 裡最大等待時間，n 是聚集封包的數目，我們假設 n 初始值為 1，首先，我們每一個 round 都先量測 RTT 的時間，再去呼叫 adaptive 程序，在 adaptive 程序裡，當 delay 小於等於門檻值 (threshold) ，則 n=n+1，之後呼叫 aggregation 程序，一旦 n 值越加越大，delay 時間也會越來越高，當 delay 超過門檻值且 n 不等於 1 時，則做 n=n-1，之後呼叫 aggregation 程序，相當於減少聚集的封包數目，因為超過門檻值就是代表了 delay 時間目前很高，則不繼續增加聚集的封包數目，避免 delay 時間更高，而其他情況，例如 delay 大於門檻值但 n=1，則做 n=1，再去聚集封包，但 n=1 時聚集的效用不大，可當成網路上一次傳輸一個封包。

在 aggregation 程序中，packet P 代表要進入 queue 的封包，聚集封包 (A) 是正在準備的聚集封包，MTU 是最大傳輸單元，MAX_PACKET_NUM 是 MTU 時的封包數目， aggablesize function 可計算目前 queue 裡的封包數目， add_by_maxdelay function 可計算超過 QueueingMaxDelay 的封包有哪幾個，一旦 queue 裡有超過 QueueingMaxDelay 的封包就聚集 n 個封包送出，設置 QueueingMaxDelay 的目的為可避免封包等待聚集的時間過久，我們可根據傳輸不同的應用選擇不同的 QueueingMaxDelay，例如：若傳輸即時性的應用時，可設定較低的 QueueingMaxDelay。aggregation 程序一開始若接收到聚集封包數目時，如果 queue 的大小大於 n，表示 queue 有足夠大小可接收，則將流量裡的封包放入 n 個到 queue 裡，然後，若 n 大於 MAX_PACKET_NUM 則 n 等於 MAX_PACKET_NUM，避免聚集封包大小超過 MTU，首先先取得 queue 裡可聚集的封包數目，若可聚集的封包數目大於等於 n，則將 queue 裡的封包聚集起來並將聚集封包送往目的端，如果 queue 裡可聚集的封包數目小於 n，則搭配 QueueingMaxDelay 判斷有沒有在 queue 裡的時間大於 QueueingMaxDelay 的封

(35)

包，若有則將 queue 裡所有的封包聚集直到 MTU size 並將聚集封包送往目的端。

procedure adaptive(delay, threshold, n)

if delay ≦ threshold then n = n+1;

aggregation(n); else

if delay > threshold && n != 1 then n = n-1; aggregation(n); end if end if end procedure procedure aggregation(n)

// P：packet being queued at a node; //A：aggregation packet being prepared; //MTU：maximum transmission unit;

//MAX_PACKET_NUM：The number of packets MTU; //num_packets：number of packets;

find queue of P;

if size(queue) > n then

//adding the number of n-packet from flow(P); If n > MAX_PACKET_NUM then

n = MAX_PACKET_NUM; end if

num_packets = aggablesize(); if num_packets >= n then

add packet from queue; send A directly to destination;

else num_packets = add_by_maxdelay(); switch(num_packets) case 0: Send nothing; default:

add packet from queue; send A directly to destination; end switch end if end if end procedure 圖 3-2：適應性聚集封包演算法利用調整聚集封包數目，我們預期 delay 會控制在一個區間，例如當一直在

(36)

門檻值附近作 n+1 或 n-1 時，delay 的時間可能就在門檻值附近達到穩定的狀態，且由於是適應性的聚集封包大小，所以相較於固定的聚集更能提升壓縮效益。我們也根據以上的adaptive程序再作進一步的改良，我們提出了5種改良 adaptive程序的方法，以下會一一說明，如圖3-3所示，首先，每一個round都先量測RTT的時間，再去呼叫adaptive程序，當delay小於等於門檻值 (threshold) ，則n=(n*2)，之後呼叫aggregation程序，使得當delay小於等於門檻值，n會呈指數增加，當delay超過門檻值且n不等於1時，則做n=1，之後呼叫aggregation程序，相似於slow-start機制可減少聚集的封包數目，則每次一旦delay超過門檻值，聚集的封包數目就會降成1，下一個round時n則從1緩啟動指數增加。

if delay ≦ threshold then n = (n*2);

if delay > threshold && n != 1 then n = 1; aggregation(n); end if end if end procedure 圖 3-3：slow-start adaptive 程序如圖 3-4 所示，首先，每一個 round 都先量測 RTT 的時間，再去呼叫 adaptive 程序，當 delay 小於等於門檻值 (threshold) ，則 n=(n*2)，之後呼叫 aggregation 程序，使得當 delay 小於等於門檻值，n 會呈指數增加，且當 delay 小於等於門檻值一半時，用 temp 儲存 n 值，當 delay 超過門檻值且 n 不等於 1 時，則做 n=temp，之後呼叫 aggregation 程序，相似於 fast-recovery 機制可減少聚集的封包數目，所以當 delay 超過門檻值，聚集的封包數目會降低到門檻值一半時的 n 值，下一個 round 時 n 可能繼續指數增加。

(37)

if delay ≦ threshold then n = (n*2);

if delay ≦ (threshold/2) then

temp = n ;

if delay > threshold && n!=1 then n = temp; aggregation(n); end if end if end procedure 圖 3-4：fast-recovery adaptive 程序如表 1 所示，由於我們原始的 1.adaptive 程序，n 值屬於線性增加和線性減少，所以可再將ｎ值延伸變化為 2.指數增加、線性減少 3. 線性增加、指數減少 4. 指數增加、指數減少，以上這 3 種 adaptive 程序的改良和緩啟動 adaptive 程序及 fast-recovery adaptive 程序，均可能會對網路的情況造成不同的影響，例如： end to end delay 、封包到達的成功率，我們藉由實驗分析可找出一種較好的方法，使 end to end delay 降低且封包到達的成功率提升，並且能讓網路情況維持在一個良好的情況，不會使網路太擁塞導致 packet loss 情況太高。

(38)

第四章數學模式的效能分析

為了驗證本論文所提出得適應性聚集封包機制可以在有限的 delay 下，提升壓縮的效益。本章將利用數學模式的分析，利用 hop delay 和 hop 數來評估壓縮比率。 4.1 數值分析項目 本篇論文我們採用 multi-hop 的情境來進行初步的效能分析並評估了壓縮比率。如圖 4-1 所示，相鄰的車輛間可以直接的進行通訊，並考慮 hop delay 和 hop 數來評估適應性聚集封包演算法。圖 4-1：車載 multi-hop 環境我們假設原本的封包標頭為 20 byte，並假設在聚集封包時所搭配的標頭壓縮技術能將封包標頭壓縮到 8 byte。那麼，如公式 1 所示，壓縮比率 (CR) 即可計算求出，n 為即將聚集的封包數目，如公式 2 所示，end to end delay 等於要聚集封包之間的 delay (interframe delay) 加上 hop delay，我們採用的 codec 為 G.729A，所以 interframe delay 為 0.125 ms。

(39)

End_to_End_delay = Interframe_delay + Hop_delay (2) 4.2. 效能評估 如圖 4-2 所示，為依據公式 1 所計算得出的結果，我們計算出不同的聚集封包數量的壓縮比率，我們可以很明顯的看到當聚集封包數目越多時，壓縮比率也越高，且壓縮比率也會趨於穩定接近 60%。圖 4-2：聚集封包數量的壓縮比率

接下來，我們考慮 hop delay 和 Hop 數來評估適應性聚集封包演算法，在本篇論文裡，我們都是評估固定的 hop delay 的情況，如圖 4-3 所示，我們比較了 hop delay=1 ms,5 ms,10ms，在不同的 hop 數時，能聚集封包的最大數目，可以發現當 hop delay 越少時，能聚集的封包數目則是越多，隨著 hop 數越來越多， RTT 時間也越高，依據適應性聚集封包演算法，能聚集的封包數目也會降低，

(40)

以固定的 hop delay=5 ms 來說，當 hop 數目為 8 時，RTT 時間也約為 80ms，已經接近我們設定的 threshold=80 ms，所以能聚集的封包數目約為 1~2，但以固定 hop delay=1 ms，可以看到 hop 數可到 32 以上，聚集的封包數才下降到 1~2。

圖 4-3：不同 hop count 的最大聚集數量

(41)

如圖 4-4 所示，我們根據了圖 11 所顯示的聚集封包數目，利用公式 1 求出壓縮比率，我們比較了 hop delay=1 ms,5 ms,10ms，在不同 hop 數時的壓縮比率，可以看到當聚集封包數目為 2 時壓縮比率只有 30%，若是其它大量的聚集封包數目時，因為壓縮比率趨於穩定，所以壓縮比率皆可接近 60%。

如圖 4-5 所示，我們比較了 hop=1 ,5 ,10，在不同的 hop delay 時，能聚集封包的最大數目，可以看到當 hop delay 越高時，能聚集的封包數也會降低，以 hop delay=1 ms 來說，hop 數越少的也如預期的聚集封包數目越大，且當 hop delay=4 ms 時，hop 數 10 的 RTT 時間已經接近 threshold=80 ms，所以可聚集的封包數目則降為 1~2，我們也可以發現，hop 數越少的，更可以平穩的聚集封包數，如 hop=1，這也是我們可預期的，因為 hop 數越小，delay 上升不會太快，則聚集的封包數目可較多。

圖 4-5：不同 hop delay 的聚集封包數量

透過上述效能分析的結果，我們發現利用適應性聚集封包的演算法，可達到在壓縮效益下和 delay 作一個平衡，以提昇在車載無線網路環境中使用標頭壓縮資料傳輸的壓縮比率和提高 throughput 。

(42)

第五章模擬環境的修改：NS2 的實作

由於本論文將透過 NS-2 網路模擬器來實驗，所以必須在 NS-2 裡加入我們的方法，因此本章節將詳述我們新增並修改了 NS2 得哪些部份以實現適應性聚集封包機制。

5.1. NS2 網路模擬程式介紹

我們的實驗將使用 NS-2 網路模擬器(Network Simulator Version 2)[23]來模擬實驗，NS 是由 Lawrence Berkeley National Laboratory 的 Network Research Group 所發展。NS 為一可擴充，容易建構網路模擬環境，可程式化的事件驅動，而且提供多種 TCP、UDP 及路徑演算法以及已經內建 IEEE802.11 無線網路模組與部分路由協定如 AODV、DSR。 NS 的核心程式碼是由 C++撰寫，而外部介面的部份則是以 Tool Command Language(Tcl)來進行網路場景的描述。一般其核心部份是以基本上不需要常常更動及要求執行速度需求為主要考量，而以 Tcl 為介面提供一個可快速更動網路組態的設定，以避免更動核心部份而必須重新編譯核心，造成時間上的浪費，及增加網路模擬的複雜度。因此 NS-2 即是透過 C++核心部份及 Tcl 網路場景描 述的搭配，來達到網路模擬的功能。 5.2. 適應性聚集封包的實作 此節我們首先介紹節點架構須做哪些修改和新增修改 ping agent 模組，以及實作出有聚集功能的 queue 和有解聚集功能的 agent，以完成適應性聚集封包機制。

(43)

5.2.1 節點架構的修改 NS-2 的節點架構圖如圖 5-1 所示，綠色部分是修改並加入了實作聚集的方法，當封包由 entry point 進入節點後，該節點會取出進入封包的來源端位址及目的地端位址，並藉由 classifier 進行封包的傳送，如果目前節點的位址與該封包的目的地端位址相同，則該封包會在取出使用哪一個埠號，並進而將該封包送至對應的應用程式，完成封包的傳遞，若是 agent 產生的封包進入節點後則通過 routing agent 再送往 MAC 層再送出封包，而我們要實作聚集的話，則必須新增修改 agent 和 queue 的部分。

(44)

5.2.2 適應性聚集封包機制

為使 NS-2 能夠聚集封包的功能，因此我們必須對 NS-2 中的相關模組進行新增或修改，我們在 queue 的部分主要新增了一個可以聚集的 queue，agent 的部分則是新增了一個解聚集的 agent 和一個發送 ping 封包的 agent 用來測量 RTT，並利用測量到的 RTT 動態調整聚集的封包數目，以下分別說明實作聚集得主要 function。

enque()：判斷進入 queue 的封包，若是需要聚集的封包則加上 timestamp，這是為了方便之後能計算此封包在 queue 裡的時間。

deque()：此 function 則包含了以下的子 function，在這裡面完成聚集的部分。

aggablesize()：計算 queue 裡的封包數目和 size。如圖 5-2 所示，一開始會傳入 *num 的指標可存放此 function 計算後的封包數目，第 3~4 行是取得節點得 id 和位址，第 5~7 行是宣告要存取封包的指標，第 9 行是開始去搜尋 queue，第 13~20 行是先判斷封包是不是同樣得 next hop，若是則將 queue 裡的封包數目加 1 並判斷有無超過可聚集的封包數目，依此原則找尋出 queue 裡有無可聚集的封包數目，最後才回傳此數值。

001: int AggregatorAdaptive::aggablesize(int *num) { 002: int numpackets = 0, totalsize = 0;

003: Node* currentnode = Node::get_node_by_address((nsaddr_t) nodeid_); 004: int currentaddr = currentnode->address();

005: Packet *p_top = q_->lookup(0);

006: struct hdr_cmn *hdr_cmn_packet = HDR_CMN(p_top); 007: hdr_ip *hdr_ip_packet = hdr_ip::access(p_top);

008: int maxsize = getMaxSize(); 009: for (int i = 0; i < q_->length(); i++) {

(45)

010: Packet *ptmp = q_->lookup(i);

011: struct hdr_cmn *hdr_cmn_tmp = HDR_CMN(ptmp); 012: hdr_ip *hdr_ip_tmp = hdr_ip::access(ptmp);

013: if (hdr_cmn_tmp->next_hop() == hdr_cmn_packet->next_hop()) { 014: totalsize += hdr_cmn_tmp->size();

015: if (numpackets<=maxsize&&numpackets< MAX_PACKET_NUM && totalsize < mtusize_) {

017: numpackets++; 018: } else 019: totalsize -= hdr_cmn_tmp->size(); 020: } 021: } 022: *num = numpackets; 023: return totalsize; 024: } getMaxsize()：此為可以自訂要聚集的封包數目。

add_by_Maxdelay()：我們藉由可自訂 QueueingMaxDelay 封包在 queue 裡的最大等待時間來讓此 function 計算 queue 裡的封包有無超過 QueueingMaxDelay，只要有封包超過 QueueingMaxDelay，就聚集 n 個封包。如圖 5-3 所示，第 3 行是開始去搜尋 queue，第 7~17 行是先判斷封包有無同一個 next hop 並判斷此封包的時間有無超過 QueueingMaxDelay ，若有則將此封包丟入準備要聚集得 packetbuffer 裡，最後再回傳要聚集得 packetbuffer。

001: int AggregatorAdaptive::add_gt_maxdelay(Packet **packetbuffer, int *size) { 002: ...

003: for (int i = 0; i < q_->length(); i++) { 004: Packet *ptmp = q_->lookup(i);

(46)

005: struct hdr_cmn *hdr_cmn_tmp = HDR_CMN(ptmp); 006: hdr_ip *hdr_ip_tmp = hdr_ip::access(ptmp);

007: if (hdr_cmn_tmp->next_hop() == hdr_cmn_packet->next_hop() && 008: ((currenttime - hdr_cmn_tmp->timestamp())*1000) >

getMaxDelay(ptmp , Node::get_node_by_address((nsaddr_t) nodeid_))) { 009: totalsize += hdr_cmn_tmp->size();

010: if (numpackets <= maxsize && totalsize < mtusize_ && numpackets < MAX_PACKET_NUM) { 011: packetbuffer[numpackets] = ptmp; 012: q_->remove(ptmp); 013: i--; 014: numpackets++; 015: } else 016: totalsize -= hdr_cmn_tmp->size(); 017: } 018: } 019: *size = totalsize; 020: return numpackets; 021: } 圖 5-3：函數 add_by_Maxdelay()

(47)

圖 5-4：聚集演算法的流程圖如圖 5-4 所示，紫色部分為實作聚集的地方，在 deque()裡完成聚集，首先先判斷 queue 是否為空，若不為空在判斷是否為要聚集的封包，如果是要聚集的封包，則先取得 queue 裡的封包數目，之後判斷是否大於等於要聚集的封包數目，如果等於就將 queue 裡的封包聚集送出聚集封包送往目的端。如果不等於要聚集的封包數目，則根據 QueueingMaxDelay 查看目前 queue 裡的封包有沒有超過 QueueingMaxDelay，若有一個超過就將 queue 裡的封包全部聚集送出封

(48)

包型態為 Agg_pkt 的聚集封包。

5.2.3 ping agent 模組的新增與修改

我們將適應性聚集封包演算法中的 adaptive 程序實作在 ping agent 模組裡，此模組會發送 ping 封包到目的端，目的端接收到封包之後，記錄了收到的時間再回傳給接收端，接收端在計算出 RTT 的時間，我們因此可藉由此時間來實作 Adaptive 程序，我們會先宣告 2 個共用變數 agg_rtt 和 aggsize，agg_rtt 是演算法中用來判斷有無超過門檻值的時間，aggsize 是聚集封包的數目，如圖 5-5 所示，第 1 行是量測到的 RTT，第 4~10 行是利用抓取到的 RTT 判斷有無超過門檻值，若無則將 aggsize 加 1，反之則減 1。在實驗模擬中，我們會定期的去發送 ping 封包，達到動態調整聚集封包數目得目的。 001: k_rtt = ((Scheduler::instance().clock()-hdr->send_time) * 1000); 002: agg_rtt=k_rtt; 003: float threshold=80; 004: if(agg_rtt <= threshold){ 005: aggsize = (aggsize+1);

006: }else if((agg_rtt > threshold) && (aggsize!=1)){ 007: aggsize = (aggsize-1); 008: }else{ 009: aggsize = 1; 010: } 圖 5-5：量測 RTT 並動態調整聚集封包的數目 5.2.4 聚集的 queue 封包聚集裡最主要的一個部份為聚集的 queue，我們將它繼承了 PacketQueue 類別，使的它有一般 queue 的功能。

(49)

enque( ) function

連結層藉由呼叫 enque( ) function 來讓封包進入到 queue 裡，如圖 5-6 所示，第 5~6 行是將進入 queue 的封包加上一個時間標記，時間標記的目的為可讓 add_by_Maxdelay() function 判斷封包有無超過 QueueingMaxDelay，第 7~9 行是當 queue 滿的時候，此時又有新的封包進入時，新進的封包會以 drop-tail 的方式被 drop 掉。 001: void AggregatorAdaptive::enque(Packet* p) 002: { 003: struct hdr_cmn *ch = HDR_CMN(p); 004: if (ch->ptype() == PT_CBR) 005: ch->ts_ = Scheduler::instance().clock(); 006: q_->enque(p); 007: if (q_->length() > qlim_) { 008: q_->remove(p); 009: drop(p); 010: } 011: } deque( ) function 圖 5-6：函數 enque( ) 在 deque( ) function 中則實作了聚集的演算法，而若只想聚集 CBR 的封包，此聚集的 Queue 則只會聚集封包型態為 PT_CBR 的封包，其它型態的封包則會不聚集以 FIFO 的方式直接送出。如圖 5-7 所示，若有其他想被聚集的封包型態可加入在第 3 行裡，第 4 行是宣告聚集封包的 buffer，第 6 行是 aggablesize function 會回傳 queue 裡可聚集的封包有幾個，第 7 行是取得聚集封包的數目，第 8~11 行是避免聚集的數目超過 MTU size 的封包數目，maxsize 最大為 24 是因為我們實驗中預設 MTU size 為 1500bytes，封包 size 為 60bytes 因此 MTU 最大為 24 個封包，這部分可以根據 MTU size 和封包 size 去做改變。

(50)

001: Packet* AggregatorAdaptive::deque(){ 002: ...

003: if (hdr_cmn_packet->ptype() == PT_CBR ) {

004: Packet *packetbuffer[MAX_PACKET_NUM]; 005: int num = 0;

006: int aggable = aggablesize(&num); 007: int maxsize = getMaxSize(); 008: if(maxsize>=24){ 009: maxsize=24; 010: aggsize=24; 011: } 012: ... 013: } 014: } 圖 5-7：節錄自函數 deque( ) 5.2.5 解聚集的 agent 解聚集的 agent 的功用是當接收到聚集封包的型態 Agg_pkt 時，能解開此聚集封包並轉送解開後的封包到節點裡。而當有解聚集 agent 的節點在處理封包時，會根據此封包的封包型態和目的端位址來決定是否要轉送出去或要解開封包。所以當節點在處理 Agg_pkt 聚集封包的路由時，其節點在模擬時須加上以下的 Tcl 語法: $node attach [new Agent/Deaggregator]。

(51)

第六章實驗模擬分析與結果

此章將分析實驗模擬結果透過平均 end to end delay、封包到達率，來評估適

應性聚集封包機制，我們將實驗場景分為 String-Topology 和 Freeway-Topology 2 部分，String-Topology 為靜態車輛的場景，而 Freeway-Topology 是車輛移動的場景。此外，我們除了比較未聚集得情況，也將以固定式聚集 2 個做為評比對象。

6.1. 影響 delay time 的評估

6.1.1 routing protocol 對於 delay time 的影響

A.實驗設計與目的

這組實驗主要的目的是測試 routing protocol 為 AODV 或 DSR 對於傳輸的 delay time 有什麼影響。

B.實驗環境

實驗架構圖如圖 6-1 所示，詳細參數如表 6-1 所示

(52)

表 6-1：模擬參數 Name Value Number of hops 4 Transmission range 250 m Interference range 550 m Node interval 200 m Traffic packet type CBR

Simulation time 160 sec Packet Size 512 Routing Protocol AODV

C.實驗結果

如圖 6-2 所示，從 DSR 傳輸的封包序號可以看到 DSR 的 packet loss 比較高且 DSR 的 delay 時間也高達 6 秒相對於 AODV 封包遺失較小且 delay 時間頂多到 1.4 秒，因為 DSR 需要廣播尋找路徑，且不像 AODV 每個節點可以維護自己的 routing table，所以 DSR 封包遺失相對較高且連結建立所需的延遲時間比較長，故使用 AODV 傳輸效能較好。但是由於 delay 時間一樣滿高的，所以變動 routing protocol 對於降低 delay time 幫助不大。

(53)

(b)：routing protocol 為 DSR 圖 6-2：封包 delay time 的分析 6.1.2 干擾距離對於 delay time 的影響 A.實驗設計與目的這組實驗將傳輸距離和節點間隔縮小，並將干擾距離縮小主要的目的是測試干擾距離對於傳輸的 delay time 有什麼影響。 B.實驗環境實驗架構和 6.1.節一樣為 String-Topology，詳細參數如表 6-2 所示表 6-2：模擬參數 Name Value Number of hop 4 Transmission range 120 m Interference range 150 m Node interval 100 m Traffic packet type CBR

(54)

Simulation time 160 sec Packet Size 512 bytes , 700 bytes Routing Protocol AODV

C.實驗結果

如圖 6-3 所示，可以看到當傳送的封包 size 為 512 bytes 且干擾距離降低時，模擬時間接近 60 秒時，delay 時間可快速降低到約 25ms 且持續穩定的 delay。當傳送的封包 size 加大為 700bytes，模擬時間接近 20 秒時，delay 時間可快速降低到約 30ms 且持續穩定的 delay，但穩定的 delay 時間比封包 size 512 bytes 時略高。所以我們可以得知干擾範圍對於 delay 時間會有影響，且傳送的封包 size 越大，delay 時間可越快降低，這可能是因為 MTU 的影響，在 queue 裡等待封包數目可較少， delay 時間也縮短。

(55)

(b)：封包 size 為 700bytes

圖 6-3：封包 delay time 的分析

6.2. 實驗環境設置

本論文我們選擇使用 NS-2 網路模擬器(Network Simulator Version 2)[23]來模擬實驗，實驗場景分為 String-Topology 和 Freeway-Topology，我們一開始採用 NS2-2.26 的版本，並在 2.26 版本裡實作出適應性聚集封包的模組，由於 NS2-2.26 的版本並不支援 IEEE 802.11p，要在高階版本如 NS2-2.34 才有支援。所以， String-Topology 的實驗數據是由 IEEE 802.11b 的模組所取得，之後我們並將適應性聚集封包模組擴充到 NS2-2.34 的版本裡並搭配 IEEE802.11p 的模組來實驗 Freeway-Topology。 String-Topology 共用模擬參數設定如表 6-3，我們並實驗了傳輸 2 種不同的 traffic，CBR 和 FTP，其中 CBR 和 FTP 的參數設定分別由表 6-4 及表 6-5 所示。

(56)

Name Value Note General Settings:

Simulation time 160 sec

MAC/Physical Layer: Receiving Threshold 6.88081e-09 Transmission range 120m Carrier Sense Threshold 2.81838e-09 Interference range 150m Data Rate 11 Mbit/s

Basic Rate 2 Mbit/s

Routing:

Routing Protocol AODV

Aggregation Queue:

QueueingMaxDelay 5ms,15ms ,25ms MTU size 1500 bytes

Traffic Generation:

Traffic packet type CBR

Traffic Rate 0.2Mbps , 64Kbps

Packet Size 60bytes (40 bytes payload +20bytes header) 表 6-4:CBR 參數設定