國立臺中教育大學資訊科學學系碩士論文
車載無線網路環境下最小延遲
多點轉送機制
Route Optimization for Minimizing End-to-End
Delay in Multi-hop VANET
指導教授：王讚彬 教授
研究生：呂豐旭 撰
中華民國一百年六月
致謝
首先誠摯的感謝指導教授王讚彬老師，老師悉心的教導使我獲益良多，並且不時的與我討 論並指點我正確的方向，讓我順利的完成本論文。本論文的完成另外亦得感謝口試委員竇其仁 老師、嚴力行老師、李國川老師和張林煌老師詳盡的意見及指導，使得本論文的內容能夠更完 整而嚴謹。 再來要感謝研究所的同學們，芳瑜、鈺軒、明德、雨澤和東穎等，陪我一起討論研究、寫 國科會計畫、寫論文，這裡有我們共同的生活點滴和生活樂趣。也謝謝學弟妹們，昱群、舜斌、 裕其、阿民、國唐、冠霖、博仁，你們在我研究之餘陪我吃飯聊天、陪我研究三國歷史，還有 其他實驗室的學弟妹們，天亮、和展、仲麒、瑋辰、益華，當我熬夜寫論文時，你們總是在 facebook 上陪伴著我。有大家一路上教學相長、互相扶持，你/妳們的陪伴讓兩年的研究生活 變得多采多姿。 最後，特別要感謝我的家人，謹以此文獻給我摯愛的雙親。中文摘要
IEEE 802.11p 標準是設計來讓車輛與車輛 (V2V) 之間的 ad-hoc network 可以做資料存 取。然而，因為車載無線網路 (WAVE network) 中車子的高移動性，使用時將面臨大量的換手 過程或是無法隨時的跟 RSUs 做資料存取。因此我們想透過多點轉送 (multi-hop forwarding) 機制讓車輛不管在何時何地都能存取資料。但是 IEEE 802.11p 在多點轉送機制上並沒有明確 的定義，所以我們整合 ad-hoc routing protocol (AODV) 並以 solicitation-based 的機制來讓 WAVE network 可以有 ad-hoc mode 的網路存取方式，之後我們再提出一個基於最小延遲時間 的路徑最佳化演算法設計讓多點轉送機制可以選擇最佳路徑來傳輸資料。如此一來便可以完成 我們所提出的最小延遲多點轉送機制。 最後我們利用 NS2 網路模擬軟體來做實驗，模擬結果顯示在 WAVE network 下的路由協 定，當有使用我們所提出的最小延遲多點轉送機制可以降低整體的延遲時間，封包接收率也較 高，並提高整體效能。 關鍵詞：車載無線網路、多點轉送、ad-hoc 路由協定、路徑最佳化。
Abstract
The IEEE 802.11p standard is designed to carry out vehicle-to-vehicle (V2V) communication in vehicular ad-hoc network (VANET). Because of high mobility in the WAVE network, data connection may suffer from multi-hop forwarding and crossing a lot of road-side units. Unfortunately, IEEE 802.11p removed the association operation and is unable to track the current location of vehicles. Without the support of association, solicitation-based mechanisms will be promising to request and deliver data in VANET. Therefore, we integrate ad-hoc routing protocol (AODV) and the solicitation-based mechanisms into WAVE network. Moreover, we perform route optimization for minimizing end-to-end delay, in which the transmissions of data can multi-hop forwarding by the best route.
Our simulation results show that routing protocols with route optimization not only reduce end-to-end delay time and jitter but also increase packet delivery ratio and overall throughput.
目錄
致謝... I 中文摘要 ... ... II Abstract.... ... III 目錄... IV 表目錄... VI 圖目錄... VII 第一章 緒論 ... 1 1.1. 前言 ... 1 1.2. 研究動機與目的 ... 4 1.3. 論文架構 ... 5 第二章 背景知識與相關研究 ... 7 2.1. 車載無線網路簡介 ... 7 2.2. 路由協定簡介 ... 122.2.1. Dynamic Source Routing (DSR) ... 12
2.2.2. Ad Hoc On-Demand Distance Vector (AODV) ... 13
2.3. 相關研究 ... 16
2.3.1. A Solicitation-based IEEE 802.11p MAC Protocol for Roadside to Vehicular Networks.. ... 16
2.3.2. Multi-hop Forwarding over WAVE Networks ... 20
第三章 基於最小延遲時間之路徑最佳化設計 ... 25
3.1. multi-hop forwarding 系統架構 ... 25
3.1.1. Case I：每次傳輸資料都會建立一次 WBSS... 25
3.1.2. Case II：所有節點加入同一個 WBSS ... 26
3.1.3. Case III：Dynamic WAVE-Area 選擇較近的 WBSS provider 傳輸資料 ... 27
3.2. 路徑最佳化設計 ... 28
第四章 路徑最佳化系統實作 ... 31
4.1. AODV 程式說明 ... 31
4.2. recvRequest ( ) 函數說明與系統實作... 34
4.2.2. recvRequest ( ) 系統實作 ... 36 4.3. recvReply ( ) 函數說明與系統實作 ... 37 4.3.1. recvReply ( ) 函數說明 ... 37 4.3.2. recvReply ( ) 系統實作 ... 38 4.4. rt_update ( ) 函數說明與系統實作 ... 40 第五章 實驗模擬與分析討論 ... 43 5.1. NS2 網路模擬軟體介紹 ... 43 5.2. 實驗模擬環境與參數設定 ... 45 5.3. 實驗結果與分析討論 ... 47
5.3.1. Average Delay Time ... 49
5.3.2. Packet Delivery Ratio ... 59
5.3.3. Average jitter ... 68 5.3.4. Average throughput ... 72 5.4. Summary ... 75 第六章 結論與未來工作... 77 6.1. 結論 ... 77 6.2. 未來工作 ... 78 參考文獻... 79
表目錄
表 5-1 simulation parameters setting ... 46
表 5-2 simulation variables setting ... 47
表 5-3 Performance Metric formula’s parameters ... 48
表 5-4 simulation results ... 75
圖目錄
圖 1-1 Infrastructure Network ... 1
圖 1-2 Ad-hoc Network ... 1
圖 1-3 Infrastructure WAVE Network ... 2
圖 1-4 Ad hoc WAVE Network ... 3
圖 2-1 WAVE Network Architecture ... 8
圖 2-2 The Protocol Stack of an IEEE 802.11p/1609 Network ... 10
圖 2-3 DSR route discovery ... 13
圖 2-4 AODV route discovery ... 14
圖 2-5 Format of a WAVE-Poll frame ... 17
圖 2-6 Solicitation-based data transmissions in W-UIM ... 18
圖 2-7 Optional data transmission sequence ... 19
圖 2-8 An SMFS scenario where the Sender can Directly Communicate with RSU ... 21
圖 2-9 An SMFS scenario where the Sender cannot Directly Communicate with RSU ... 22
圖 2-10 The WBSS establish and join procedure of SMFS ... 22
圖 2-11 The WBSS establish and join procedure of RMFS ... 23
圖 3-1 WBSS must be establish and join every hop ... 26
圖 3-2 Every node join the same WBSS ... 27
圖 3-3 Receiver join the recent WBSS ... 28
圖 3-4 Receiver communication with RSU1 before move ... 30
圖 3-5 Receiver communication with RSU2 after move ... 30
圖 4-1 Packet Reception Routines ... 32
圖 4-2 The procedure of recvRequest ( ) function ... 35
圖 4-4 recvRequest ( ) function of AODV with route optimization ... 37
圖 4-5 The procedure of recvReply ( ) function ... 38
圖 4-6 recvReply ( ) function of AODV with route optimization ... 39
圖 4-7 recvReply ( ) function of AODV without route optimization ... 39
圖 4-8 rt_update ( ) function of AODV without route optimization ... 40
圖 4-9 rt_update ( ) function of AODV with route optimization ... 41
圖 5-1 Simulation WAVE network topology ... 46
圖 5-2 The average delay time of routing protocol with RO by fixed amount of vehicles ... 51
圖 5-3 The average delay time of routing protocol with RO by fixed average speed ... 52
圖 5-4 The average delay time of routing protocol with RO by fixed random traffic ... 53
圖 5-5 The average delay time of routing protocol with RO ... 54
圖 5-6 Comparison of Average Delay time by fixed amount of vehicle ... 57
圖 5-7 Comparison of Average Delay time by fixed average speed ... 58
圖 5-8 The packet delivery ratio of routing protocol with RO by fixed amount of vehicles ... 61
圖 5-9 The packet delivery ratio of routing protocol with RO by fixed average speed ... 62
圖 5-10 The packet delivery ratio of routing protocol with RO by fixed random traffic ... 63
圖 5-11 Comparison of Packet Delivery Ratio by fixed amount of vehicles ... 66
圖 5-12 Comparison of Packet Delivery Ratio by fixed average speed ... 67
圖 5-13 Comparison of Average jitter by fixed amount of vehicles ... 70
圖 5-14 Comparison of Average jitter by fixed average speed ... 71
圖 5-15 Comparison of Average throughput by fixed amount of vehicles ... 73
第一章 緒論
1.1. 前言
近年來隨著網路技術的不斷成長以及無線網路存取點的廣泛布建，筆記型電腦、個人數位 助理及智慧型手機等各種高移動性裝置都可以在無線網路訊號涵蓋的範圍內輕鬆連上網際網 路 (Internet) 。目前在無線網路傳輸技術上有兩種類型：有基礎架構無線網路 (Infrastructure Network) (如圖1-1所示) 及無基礎架構無線網路 (Ad-hoc Network) (如圖1-2所示) 。另外，為 了提供智慧型運輸系統 (Intelligent transportation system，ITS [1]) 以及司機和乘客的輔助服 務，車載通訊已吸引研究界和汽車行業的注意，目前車載網路已成為一個新類型的無線網路應 用，同時也引發 更多的研究議題。車載網路主要自發形成於移動的車輛之間，而這些車輛配備 的無線設備可能產生類似的或不同的無線接口技術，車載網路採用短程到中程的通訊系統，提 供附近的車輛間的通訊和車輛跟路邊附近的固定裝置之間的通訊。
而在無線網際網路的發展中 IEEE 802.11(a)(b)(g)(n) 已經相當成熟，但是現今舊有的 圖 1-1 Infrastructure Network 圖 1-2 Ad-hoc Network
IEEE 802.11 [2] 標準並不適合用在車載無線網路環境下，因此由 IEEE 802.11 團隊所制定的 IEEE 802.11p [3][4] 應運而生。車載通訊網路除了較底層的 IEEE 802.11p 其上層還包括 IEEE 1609 系列 [5][6][7][8]，我們將其通稱為 WAVE (Wireless Access in the Vehicular Environment) 標準。另外，車載通訊網路也可稱為 WAVE network。
在 WAVE network 中 ， 資 料 傳 輸 一 樣 分 成 兩 種 模 式 ， 其 一 為 有 基 礎 架 構 模 式 (Infrastructure mode) (如圖1-3所示) ，此種模式通常會由 RSU/OBU (roadside unit / onboard unit) 建立 WBSS (WAVE Basic Service Set) ，OBU 便可以加入此WBSS 來存取 IEEE 802.11p / 1609 網路。而建立 WBSS 的 WAVE device 稱為 provider，加入 WBSS 的 WAVE device 稱 為 user。WBSS 的建立和加入是為了交換一般的 IP 封包，在沒有加入或建立 WBSS 的狀態 下 WAVE device就只能利用 WAVE standards 所制定的 WSM (WAVE Short Message) 來交 換資料。
圖 1-3 Infrastructure WAVE Network
WAVE network 中另一種資料傳輸的模式為無基礎架構模式 (Ad-hoc mode) (如圖1-4所示) 的網路存取方式。在這種網路上的所有節點都是 OBU，OBU 與 OBU 之間透過 WIBSS (WAVE independent Basic service set) 的建立來交換訊息。WIBSS 的建立不需要發送 beacons
圖 1-4 Ad hoc WAVE Network
就可以直接開始傳輸資料，所以 OBU 可以自由的交換訊息。但是因為沒有發送 beacons 就 直接傳輸資料，所以接收端 (Receiver) 和傳送端 (Sender) 必須一開始就停留在相同的頻道才 能互相通訊。另外，如果 Receiver 和 Sender 距離很遠必須要靠中介點 (Forwarder) 來幫助 封包的傳送那麼 Forwarder 也需要在此相同頻道上。因此，如果想要透過 WIBSS 的建立來 交換訊息的話所有的節點一開始就必須停留在相同的頻道。如果這樣的話將無法利用到 WAVE network 所提供的眾多頻道。 除此之外，在車載無線網路中有許多安全性以及非安全性的應用[23]，而傳送緊急訊息是 最主要的一項應用，如何快速的傳送緊急訊息以減少車禍的發生是非常重要的研究議題。依據 [24]的研究得知人體的反應時間大概為1.6秒左右。在Baker[25]的研究中，一般成年人的基本反 應時間是0.2秒，對於較複雜的狀況反應時間為0.4秒，若是較複雜且不熟悉的狀況，反應時間 至少需要0.8秒，大概為4倍的時間。Charles[26]將反應時間定義為鬆開油門至腳踩煞車的那段 時間，實驗獲得的反應時間結果為0.75秒。 反應時間一般是指當我們收到前方有車禍發生的訊息時至踩下煞車所需的時間，而開始煞 車到車子完全停止時仍需一段時間，若根據交通部公布之行車安全距離[27]，小型車為「行車 時速(km/hr) / 2」公尺，即為當時速為100公里時，安全車距必須保持50公尺以上。因此，除了 駕駛者需要保持安全距離外，如何快速的傳遞緊急訊息是一個重要的議題。
1.2. 研究動機與目的
由於在車載無線網路中，如何快速的傳遞緊急訊息是一個非常重要議題。首先，我們想要 先做到不管 OBUs 在哪裡都可以直接或間接的接收到資料。也就是說，本篇論文想要找出一 種方法來達到類似 WAVE ad-hoc mode 的網路存取方式，而在 WAVE standard 所定義的 WBSS mode 便已經內建了頻道同步的機制。 WBSS 所使用的頻道同步機制如下，provider 在 control channel (CCH) interval 時發送 beacon 通知 user 之後的 service channel (SCH) interval 雙方要到哪一個 SCH 交換訊息。在此機制下 provider 和 user 會在 CCH interval 交換控制 訊息並做 SCH 的同步，之後到達 SCH interval 時便會在同一個 SCH 交換訊息。WAVE device 會持續的在 CCH 與 SCH 間切換。
所以我們在資料傳輸上會採用 WBSS mode 來傳送資料，如圖1-3所示，由 RSU 當 WBSS provider，OBU 則為 WBSS user。如此，只要 OBU 在 RSU 的傳輸範圍內，我們就 可以傳送資料。但是 OBU 如果不在 RSU 的傳輸範圍內，就無法接收到資料，因此我們想到 可以利用 multi-hop 的方式，由周圍鄰居 OBU 當作 Forwarder 來轉送資料，或者是利用 solicitation-based 的機制由相鄰的 RSU 來轉送資料。如此，便可以讓不在 RSU 傳輸範圍內 的 OBU 接收到資料。詳細的 multi-hop 機制我們會在第三章介紹。
當我們使用 multi-hop 機制後，可以讓 OBU 不管移動到任何地方都可以接收到資料，即 使 OBU 不在 RSU 的範圍內依然可以透過 Forwarder 來轉送資料，如此一來，我們就可以 做到不管 OBUs 在哪裡都可以直接或間接的接收到資料。但是，透過 Forwarder 來轉送資料 時，因為車載無線網路環境具有高移動性，所以會使得延遲時間變長，或者是封包遺失率變高。 為了解決這個問題以及提高訊息傳遞的效能，我們提出一個基於最小延遲時間的演算法來 解決延遲時間變高的問題，並且將路徑最佳化來解決封包遺失率變高的問題。最後透過實驗模 擬結果來證明我們所提出的方法在車載無線網路的多段轉送中可以有較佳的效能，延遲時間較 小並且封包接收率較高。
1.3. 論文架構
本論文撰寫共分為六個章節，除本章外，各章節的內容如下：
第二章 背景知識與相關研究
本章內容將簡單介紹車載無線網路以及路由協定中的 Dynamic Source Routing (DSR) 和 Ad Hoc On-Demand Distance Vector (AODV) ，還有車載無線網路中一些跟多點轉送機制有關 的研究。 第三章 基於最小延遲時間之路徑最佳化設計 本章將敘述車載無線網路中多點轉送機制的系統架構，並提出一個基於最小延遲時間的演 算法設計來達到路徑最佳化，改善資料傳輸的延遲時間並提高整體的效能。 第四章 路徑最佳化系統實作 本章將詳細介紹我們所提出的路徑最佳化演算法設計，還有 AODV 程式說明以及修改， 並利用 NS2 網路模擬軟體實作我們的系統。 第五章 實驗模擬與分析討論 本章說明本論文的模擬結果與分析比較，包括實驗模擬軟體介紹、實驗環境與相關參數以 及實驗結果，並分析比較傳統的 AODV 路由協定和本篇論文實作的具有最小延遲多點轉送機 制的 AODV 路由協定兩者的平均延遲時間和封包接收率，討論其是否有達到預期結果。 第六章 結論與未來研究 本章除研究結論外，同時探討未來值得研究的議題與方向。
第二章
背景知識與相關研究
本章內容將簡單介紹車載無線網路以及路由協定中的 Dynamic Source Routing (DSR) 和 Ad Hoc On-Demand Distance Vector (AODV) ，還有車載無線網路中一些跟多點轉送機制有關 的研究。
2.1. 車載無線網路簡介
IEEE 802.11p (又稱WAVE) 是一個由 IEEE 802.11 標準擴充的通訊協定，這個通訊協定主 要用在車用電子的無線通訊上，以符合智慧型運輸系統，應用的層面包含車輛與車輛 (Vehicle to Vehicle，V2V) 以及車輛與路邊基礎設施 (Vehicle to Roadside Unit，V2R) 間的封包交換， 其使用的頻帶為 5.9GHz (5.85-5.925GHz) ，此頻帶上有 75MHz 的頻寬，以 10MHz 為單位 切割，將有七個頻道可供操作。一個控制頻道以及六個服務頻道，WAVE device 預設會停留 在 CCH 上收送 WAVE Short Message (WSM) 以及系統控制訊息 (service advertisement) ， SCH 則是用來收送一般的應用層資料 (IP data) 封包。
車載無線網路的架構主要有三種包括： (1) 一個純無線的車輛對車輛網路 (V2V) ， (2) 在有線和無線的骨幹上跳躍，可以看作是一個 WLAN，如車載無線網路， (3) 一個混合型車 輛對路上 (V2R) 的架構，可以不長時間依賴一個固定的基礎設施，車輛也可透過 single hop 或 multi-hop 的形式進行通訊，依 C2C-CC [9] 參考架構區分三個主要部分，如圖2-1所示。
圖 2-1 WAVE Network Architecture
其中車載 (In-vehicle domain) 部分包括 OBU 和一個或多個 application unit(s) (AU) ， OBU 在車子裡是個裝置具有有線或無線的通訊能力，AU 可執行一個或多個應用程式且同時 利用在 OBU 的通信能力。而 Ad hoc domain 部分是由很多台車配有許多的 OBU 和固定在 路邊的設備 (RSU) 所組成的網路，不同於移動型 Ad hoc 網路 (MANET) ，而 OBUs 至少 有一個 OBU 包括近程無線通信設備專用道路安全，而 OBUs 和 RSUs 可視為 Ad hoc 網路 的節點，分別為動態的和靜態的節點。RSUs 可連接到基礎設施，進而連到 Internet，RSUs 可 相互溝通或透過 multi-hop 溝通，其主要作用是改善道路安 全。兩種類型的 Infrastructure domain 包括 RSU 和 Hot spot，OBU 可透過 RSU 或 Hot spot 連接到 Internet。
由於車輛可不經由基礎設施直接和其他車輛通訊，所以車輛彼此間可合作和轉發些資訊。 此外，考 量車輛的節點負責收集和轉發重要訊息，車輛的收集和處理資訊可藉由智能型 sensors 來處理。
車載無線網路的特性有：
更高的計算能力。 可預測性。 車載無線網路要面對的挑戰的特性有： 潛在的巨大規模：許多研究文獻都認為是有線的網路規模，所以車載網路想達成巨大規 模原則上可延伸到整個公路網。 高移動性：在低流量時，相對速度達 300km/hr，而在高流量的話，相對速 度達 60km/hr。 分割網路：車載無線網路之間的縫隙可能會造成一些孤立的節點。 網路的拓樸和連通性。 車載無線網路在技術方面的挑戰很多，主要包括：
可靠的通訊和 MAC 協定：multi-hop 無線通訊主要的挑戰在於可靠的通訊，而 MAC 協定在某些應用上則必須考慮到訊息的優先權。 路由和傳播：目前的路由演算法上的問題主要還是因為在高密度網路中會產生廣播風暴 的問題，而訊息傳播有兩種：一種是對於安全性的應用大都採用廣播的方式，在某種程 度上確保不會有廣播風暴，另一種則為在非安全性的應用上，會採用 unicast 或 multicast 的方式傳播。 安全：安全上應該利用 Ad hoc multi-hop 認證和通信的觀念或以分散式為主的認證。 IP 配置：關於車載無線網路的特性，IP 配置是分散且自動的方式，而 IETF 的工作小 組發展了 IPv6 來解決這個問題。 移動性管理：對於高速移動的車載應用而言，這是個關鍵且廣泛被討論的問題。 分散的應用：在缺乏可靠的通訊下必須採用容錯技術。 商業模組：商業模組應該租用給電信運營商，考慮在 車載網路裡移動的用戶，節點可以 根據他們的參與得到一些報酬，為了鼓勵用戶之間的合作，根據 參與者的貢獻度可以有 一些排序的報酬 (補償) 。因此，需要特別的會計機制和計費系統。
除此之外，車載網路的應用和服務包括有即時性和安全的應用，目標在降低意外和改善交 通情況，對於安全性上的應用網 路的管理員必須有認證的機制，而非安全性上的應用則要有授 權存取的服務和使用者付費的服務。
在圖2-2中我們便可以清楚看到 WAVE 的系統架構，並且知道上述所提到的車載無線網路 技術都在 IEEE 802.11p / IEEE 1609 的標準中有詳細制定。其中一塊是 Data Plane，有 WSMP (Wave Short Message Protocol) ，WAVE MAC 和 WAVE PHY，另一塊為 Management Plane， 主要由 WME (WAVE management entity) 所構成。WAVE 能支援兩種通訊協定：車用無線存 取環境短訊息協定 WSMP 以及標準網際網路協定 IPv6 兩種資料交換的通訊協定。
圖 2-2 The Protocol Stack of an IEEE 802.11p/1609 Network
WSMP 被設計來提升在 WAVE 的傳輸效率， WSM 可以使用任意頻道傳輸 (CCH or SCH) 。他允許應用程式直接控制實體層 PHY 的能力 (例如：發送頻道、傳送功率…等) 。 WSM 的 Receiver 則是根據 WSM 所帶的 Provider Service Identifier (PSID) 來判斷要送給哪
一 個 application。每 一個 PSID 代表著不 同的 service 類 別， 它是由 IEEE Registration Authority 所管理。IPv6 僅能使用在 SCH 多重服務頻道，他允許存取一般的應用程式與網 路。 IEEE 1609 系列標準是美國電子電機工程師協會 (IEEE) 針對無線接取技術應用於車用環 境無線存取 (WAVE) 時，所定義出的通訊系統架構及一系列標準化的服務和接口。其主要目 的為制定車輛與車輛 (V2V) 間、車輛與基礎設施 (V2R) 間之標準無線通訊協定，並藉此提 供行車環境下，包括汽車安全性、自動收費、增強導航和交通管理等廣泛應用情境所需之通訊 協定標準。 IEEE1609 系列技術標準包含了有 IEEE1609.1、IEEE1609.2、IEEE1609.3、IEEE1609.4， 長久以來，受限於無線通訊技術於高速移動中的應用挑戰，以及不同車商間缺乏一致的通訊介 面，車輛與外界的溝通一直受到相當大的限制。有鑑於此，世界各國莫不以制定車用通訊標準 為其重要交通政策，如美國交通部提出智慧型運輸系統 (ITS) 關計畫便是一例。而 IEEE 便 結合了政府、車廠及電信大廠共同制定 IEEE 1609 系列技術標準，為行車環境中的各項應用 情境提供可能之解決方案。 IEEE 1609 family 包括以下： (1) IEEE1609.1：用於資源管理，包含應用程式的讀寫、RSU 和 OBU 的協定。 (2) IEEE1609.2：用於安全服務定義了 5.9GHz DSRC 的安全、匿名性、認證、和機密性。 (3) IEEE1609.3：用於網路服務定義了網路層和傳輸層的服務，包含定址和路由，可以說是整
個 WAVE device 的核心，負責整個 WAVE service 的運作流程。
2.2. 路由協定簡介
Ad-hoc Network 也就是無基礎架構設施的無線網路，在這種網路中所有的節點都是由可 移動的主機所構成 (mobile node) ，它的特點是網路拓樸結構是動態的，通常在需要通訊時才 會開始尋找路由。目前已經發展出許多的路由協定，以下將介紹比較常見的兩種路由協定： DSR [10] 和 AODV [11]。 DSR 和 AODV 擁有一個相同的特性：它們皆在需要傳輸資料封包時，才會是情況來啟 動路由發現 (route discovery) ，這類型的路由協定為 On-demand 型式的路由協定，這種使用 被動 (Reactive) 方式就是其和傳統的路由協定最大的不同處。傳統的路由協定 (例如：DSDV) 會主動 (Proactive) 尋找所有來源節點和目的節點之間的路徑，不管這些路徑是否需要用到。 所以 On-demand 型式的路由協定最大的動機就是在減少尋找這些不必要路徑所帶來的多餘 負擔 (Overhead) 。2.2.1. Dynamic Source Routing (DSR)
DSR 是一種基於來源節點路由方式的 On-demand 路由協定，它主要是由路由發現和路由 維護兩部份組成： (1) 路由發現過程主要用於幫助來源節點獲得到達目的節點的路由， (2) DSR 協定透過路由維護過程來監測當前路由的可用情況，當監測到路由故障時，將調用新的 路由發現過程。如果在路由中的節點因為移動或關機等原因無法保證到達目的節點時，當前的 路由就不再有效了。另外，為了提高系統效能，在 DSR 協定中還在每個節點引入了路由暫存 器 (Route Cache) 的技術，這個技術是跟 AODV 協定最主要的差別。
當來源節點需要傳送資料給網路上某個節點時，來源節點會先查看路由暫存器中是否有相 關的路由資訊可以到達目的節點。如圖 2-3 所示，如果路由暫存器中有到達目的節點的路由資 訊，則來源節點利用此路由資訊將資料透過此路由傳出；如果沒有目的節點的路由資訊，來源
節點會送出廣播搜尋的封包，當網路中的中間節點都收到廣播搜尋封包時，也會先檢查路由暫 存器中是否有目的節點的路由資訊存在。如果沒有，將目前節點的序號 (Node ID) 加到廣播 搜尋封包的路徑欄位中，再將修改過的封包傳送出去。直到目的節點收到或是在傳送過程中， 有中間節點知道目的節點的路由資訊時，此節點會將其路由暫存器中目的節點的路由資訊寫入 回覆路徑欄位中，並且以回覆封包依照反向路徑傳送回來源節點。當來源節點收到回覆封包 後，將回覆訊息紀錄到路由暫存器中，每當有再次傳送到目的節點的訊息時，都會在封包加上 繞送路徑傳送出去，當中間節點收到時，便可以利用封包上的繞送路徑傳送到目的節點。而每 當有路徑搜尋時，只能被一個節點廣播一次為限制，如此可以避免無窮迴圈的產生。 圖 2-3 DSR route discovery
2.2.2. Ad Hoc On-Demand Distance Vector (AODV)
AODV 是由 DSDV 演進而來的。AODV 和 DSDV 不同之處為 AODV 只在 On-demand 時才會去建立路徑，而且也不必像 DSDV 一樣需要維護整個網路的路由表。AODV 只維護選 擇路徑中的節點的路由表。
源節點會先在自己的路由表中尋找是否已有到達目的節點的路徑。如果沒有，便會開始啟動路 徑搜尋 (Route Discovery) 的程序，找到路徑之後，來源節點就會沿著這條路徑來傳送封包， 為了保證封包可以在有效的路徑上傳送，AODV 會去維護這些路徑，當路徑斷掉時會回傳 route error (RERR) 給來源節點，如果來源節點還需要此路徑就會重新啟動路徑搜尋的程序。
AODV 路徑搜尋的程序運作如圖 2-4 所示。一開始來源節點會廣播 route request (RREQ) 給鄰居節點，鄰居節點收到之後在廣播出去，以此類推，直到目的節點收到 RREQ 為止，或 是傳送 RREQ 的過程中某個中間的節點已有到達目的節點的路徑資訊，並且此路徑還是有效 的，此時 RREQ 的廣播才會停止，之後便開始依反向路徑回傳 route reply (RREP) 給來源節 點，RREP 的傳送方式為單播。
圖 2-4 AODV route discovery
RREQ 所 帶 的 資 訊 有 source_addr 、 source_sequence_num 、 broadcast_id 、 dest_addr 、 dest_sequence_num 和 hop_count。每一個唯一的 RREQ 可以用 source_addr 在加上 broadcast_id 來辨識。每個節點有 node sequence number 和 broadcast id 兩個計數器。
播出去。如果節點收到重複的 RREQ，則直接丟棄掉，避免發生 flooding。RREQ 中的 source_sequence_num 以及 dest_sequence_num，分別用來代表正向以及反向路徑的時效。如果 收到 RREQ 的節點發現目的節點路徑已經紀錄在自己的路由表中，會先檢查 RREQ 中的 source_sequence_num 是否比自己路由表中所紀錄的還要大或是 source_sequence_num 相同但是 hop_count 比自己小，如果是則會更新路由表並繼續廣播 RREQ，如果不是則往反向路徑回傳 RREP 給來源節點。
RREP 所帶的資訊有 source_addr、dest_addr、dest_sequence_num、hop_count 和 lifetime。 RREP 在沿著反向路徑回傳到來源節點的過程中，每一個在此路徑上的節點會設定一個轉送點 指向送來 RREP 的節點，並且更新路由表中此路徑的時效。 當節點收到 RREP 並且其中的路徑已經被紀錄在自己的路由表中時，如果 RREP 中的 dest_sequence_num 比自己小則直接丟棄掉，如果比自己大或是 dest_sequence_num 相同但是 hop_count 比自己小的節點才會更新路由表，並且把 RREP 傳送出去。除此之外，每一條路徑 都有一個 timer 如果在 lifetime 內都沒有用到這條路徑，便會將這條路徑刪除。 另外，當網路拓樸改變時，如果移動的是路徑中的來源節點則來源節點會重新做路由發現 的程序，如果移動的是路徑中的中間節點則所有轉送點所指向它的鄰居節點會發現節點移動 了，然後會依照反向路徑把 RERR 傳送給前一個節點直到來源節點收到為止，告知所有在此 路徑上的節點此條路徑已經失效，必須從路由表中刪除。當來源節點收到 RERR 時，如果來 源節點還需要此路徑，便會重新啟動路由發現的程序。
2.3. 相關研究
自從 WAVE standard 被發表之後，其相關研究便不曾間斷過。其中，大部分的研究是著 重在 IEEE 802.11p 以及 IEEE 1609.4 ，這部分研究比較偏向底層的資料傳輸效能以及 WAVE MAC 的特性，其中還可以分成非安全性相關 [12][13] 和與安全性相關 [14]的研究或者是在 IEEE 802.11p 的環境下測量封包的碰撞機率、delay time 以及 throughput 來比較效能的研 究。另外，還有一部分是著重在 Network Mobility [15][16] 。
本節將介紹跟底層的資料傳輸部分的相關研究，並且著重在 MAC protocol和 multi-hop forwarding。
2.3.1. A Solicitation-based IEEE 802.11p MAC Protocol for Roadside to Vehicular Networks
在車載無線網路中因為移動性較高，所以會產生一些重大的問題及挑戰，因此論文 [17] 的 作者們為了使 IEEE 802.11p 的標準更有效率，提出了三個必須去克服的重要挑戰：
(1) Stateless Channel Access：
因為在WBSS中沒有 authentication和association，所以當 WBSS user 離開WBSS provider 的通訊範圍時，WBSS provider 並不會知道 WBSS user 是否還在它的通訊範圍內。在這種環 境下，如果 WBSS provider 的 buffer 裡仍然有資料要傳送給 WBSS user，便會一直重傳直到 重傳的次數達到預設的門檻值才會停止，會導致無線資源的嚴重浪費。
(2) Caching for Handoff：
因為 WBSS user 的移動速度很快，所以當接收資料時常常會需要從一個WBSS 換到另一 個 WBSS，因此 IEEE 802.11p 需要支援在多個 WBSS providers 之間的快速換手。在 Inter-Access Point Protocol (IAPP) [18] 中提到當節點因為移動必須重新交換它的 associated AP 時可以利用主動式的 caching 來減少 re-association 程序中訊號的 delay time。然而這個方法
不能在 IEEE 802.11p 中使用，因為在 IEEE 802.11p 中沒有 association，所以我們需要利用 別的方法來解決這個問題。
(3) Opportunistic Frame Scheduling：
當 WBSS user 在 WBSS 內移動時，WBSS user 和 WBSS provider 之間的連線情況，會 因為高移動性導致通道情況有巨大且快速的變異性。在這種環境下，又加上建築物或是水泥牆 的阻礙，導致 WBSS user 和 WBSS provider 之間的連線會常常有暫時性斷線的問題。因此， 資料傳輸的發生必須取決於通道狀態，而且是隨機性的。除此之外，無線頻道瞬間狀態的 bit rate 也要即時的被決定，以便於處理頻道的迅速轉換。
因此 論 文 [17] 的作者們提出了兩個方法：WBSS User Initiation Mode (W-UIM) 和 Dynamic WBSS-Area 來解決上述所提到的挑戰。
(1) WBSS User Initiation Mode：
在 W-UIM 中，WBSS provider 僅僅只是宣告他存在的位置，並不會啟動資料傳輸給 WBSS user，所有的資料傳輸都由 WBSS user 來啟動。為了達到這個目的，論文 [17] 的作者 們提出了一個新的 WAVE-Poll frame，如圖2-5所示。在 WAVE-Poll frame 中 WAVE Mode 欄 位代表W-UIM是否啟動，PHY Tx Rate 欄位會根據 WBSS user 的通道狀態提供一個傳輸速率 給WBSS provider傳輸料。
當站台收到一個新的WBSS announcement 時，站台可以根據這個 WBSS announcement 來加入變成WBSS user。然後 WBSS user 會傳送 WAVE-Poll frame 給 WBSS provider 並將 WAVE Mode 欄位設定為 1 代表啟動 W-UIM 模式。除此之外，WBSS user 會根據 WBSS provider 最近一次傳輸資料的通道狀態在 PHY Tx Rate 欄位紀錄一個適當的傳輸速率。
每當 WBSS user 想從 WBSS provider 接收資料時，都必須先傳輸 WAVE-Poll frame 給 WBSS provider ， 並將 每個 WAVE-Poll frame 的 WAVE Mode 欄位設 定為 1 代表啟 動 W-UIM。如果 WBSS provide 成功收到 WAVE-Poll frame 會有以下兩種處理方式：
如果 WBSS provider 的 buffer 中存有要傳給 WBSS user 的資料，那麼它會在等待 SIFS 的時間後依據 WBSS-Poll frame 中指定的傳輸速率開始傳輸資料。當 WBSS user 成功收到資料後會再等待 SIFS 的時間後傳送回應訊息回去 (如圖2-6(a)所示)。 如果 WBSS provider 的 buffer 中沒有要傳給 WBSS user 的資料，那麼它會在等待 SIFS 的時間後直接傳送回應訊息回去，這個回應訊息代表已經成功收到 WBSS-Poll frame (如圖2-6(b)所示)。
(a) (b) 圖 2-6 Solicitation-based data transmissions in W-UIM
另外，如圖2-7所示，如果傳給 WBSS user 的資料在等待 SIFS 的時間後還沒準備好要傳 送，那麼 WBSS provider 會先傳送一個跟 WBSS-Poll frame 一致的回應訊息回去代表收到 WBSS-Poll frame，之後在等待 SIFS 的時間後再開始傳送資料。這是一個可選擇性的資料傳 輸順序。
圖 2-7 Optional data transmission sequence
(2) Dynamic WBSS-Area：
在 W-UIM 中，相鄰的 WBSS provider 可以組成一個可以高速緩存和轉發的區域，叫做 Dynamic WBSS-Area。透過 Dynamic WBSS-Area，即使在高速的換手中也能夠轉發資料。當 WBSS user 在相鄰的 WBSSs 之間換手時，資料可以透過 Dynamic WBSS-Area 快速的轉 發，轉發的時候有主動式和被動式兩種模式。
在主動模式中，儲存在 WBSS provider 緩存區中的資料如果快接近門檻值時，會預先轉 發給 Dynamic WBSS-Area 中相鄰的 WBSS providers。當 WBSS provider 成功傳送資料訊框 時，在 Dynamic WBSS-Area 中相鄰的 WBSS providers 必須更新 buffer 中緩存的資料。因 此，相鄰的 WBSS providers 會丟棄這個已經成功傳送的資料訊框，然後繼續緩存之後的資料 訊框。
在被動模式中，如果 WBSS user 收到其他 WBSS announcement，是跟目前加入的 WBSS 不同的，那麼它可以發送一個轉發的請求給目前的 WBSS provider。然後目前的 WBSS provider 會將在它 buffer 中要給 WBSS user 的資料轉發給相鄰的 WBSS user 可以收到它的 announcement 的 WBSS provider。因此，被動模式透過除去不必要的轉發和緩存可以減少 buffer overhead，但是缺點是在相鄰的 WBSSs 之間的訊框碰撞會較容易發生。
最後，[17] 透過實驗模擬分析吞吐量，發現使用 W-UIM 的方法可以達到較穩定且較高 的吞吐量，也就是說作者們提出的 IEEE 802.11p W-UIM 的效能比 IEEE 802.11 還好。
2.3.2. Multi-hop Forwarding over WAVE Networks
在 WAVE system 上兩個節點可以透過 WBSS 的建立來傳輸一般的 IP 封包，但是在 Receiver 和 Sender 距離兩個 hop 以上的情況下，而且 Receiver 和 Sender 之間的節點都沒 有提供服務時該怎麼傳輸資料？
Multi-hop forwarding 就是為了解決這個問題而設計出來的。Multi-hop forwarding 有兩 種形式。一種為以 Sender 為中心的形式 (sender-centric multi-hop forwarding scheme: SMFS)， 另一種為以 Receiver 為中心的形式 (receiver-centric multi-hop forwarding scheme: RMFS) [19][20]。SMFS 表示由 Sender 來建立 WBSS 讓 Receiver 加入以提供封包傳輸的服務， RMFS 則相反，它是由 Receiver 來建立 WBSS 讓 Sender 加入以提供封包傳輸的服務。 SMFS 由 Sender 建立 WBSS 是很自然的一件事，但是 RMFS 由 Receiver 來建立 WBSS 必須透過其他的幫助，因為在服務還沒建立前不能傳送 IP 封包，Receiver 也不會知道自己是， Receiver 因此必須由 Sender 在 CCH 先發送一個 WSM 給 Receiver，請求 Receiver 建立 WBSS。
另 外 ，RMFS 以及 SMFS 都有提供服務頻道的選擇方式。SMFS 必須由 Sender (provider) 來決定，RMFS 則可以由 Sender (user) 或 Receiver (provider) 來決定。如果頻道的 選擇是 由 provider 來 決定，則 provider 必 須收集其他 advertisement 所帶來的 channel number 來紀錄頻道的使用狀況，如果頻道的選擇是由 user 來決定，則 user 必須收集其他 WSM 所帶的 channel number。
(1) SMFS：
SMFS 是較 為直 接的 multi-hop forwarding 方式。 當某個 OBU 想要 透過 WAVE network 傳送 IP 封包給另一個 OBU 時，首先 OBU (original sender) 會檢查另一個 OBU (target receiver)，是否在自己的傳輸範圍內。如果是的話，那就直接由 original sender 建立一 個 WBSS，並且等待 target receiver 加入，即可開始傳輸資料。如果 target receiver 距離
original sender 兩個 hop 以上，那麼 original sender 會先把封包傳送到 original sender 附近的 RSU 在由 RSU 透過基礎網路將封包送到 target original 附近的 RSU，最後在由 RSU 傳送 給 target receiver。一般的 RSU 通常都會有固定的 WAVE 服務。因此，OBU 只要加入便可 以透過 RSU 來傳送封包，而 RSU 在背後使用基礎網路來傳送資料，網路的品質較為可靠， 速度也較快。
另外，但是如果 original sender 和 RSU 的距離大於一個 hop，那麼 original sender 便 要透過 SMFS 來將封包送到距離 RSU 較近的 forwarding OBU，在由此 forwarding OBU 將 封包送到 RSU，之後便可以透過基礎網路傳輸資料。這種情況下，每經過一個 forwarding OBU 都要處理一次 SMFS 的運作流程，會浪費掉相當多的時間。
SMFS 的運作流程如圖2-8以及圖2-9所示。在圖2-8的環境中 OBU 並不需要 SMFS 的 機制，由 original sender 直接將封包送至 RSU，在透過基礎網路送至 target receiver 附近的 RSU，最後由 target receiver 附近的RSU 直接轉送至 target receiver 即可。而在圖2-9的環境 中，original sender 和RSU的距離過遠沒有辦法直接使用 RSU 所提供的服務，必須利用 SMFS 的機制將封包傳到附近的 OBU (forwarder)，再由 forwarder 送至 RSU，之後再透過基礎網路 送至 target receiver 附近的 RSU，最後由 target receiver 附近的RSU 轉送至 target receiver 即 可。
圖 2-9 An SMFS scenario where the Sender cannot Directly Communicate with RSU
SMFS 的內部運作如圖 2-10 所示。首先由 sender (original sender or forwarder) 在 CCH interval 發送 advertisement，通知 receiver (forwarder or target receiver)，加入 WBSS 以收取封 包。等到 SCH interval 時在由 sender 將要傳送的 IP 封包廣播出去，在這個步驟中，因為 sender 不知道哪一個 receivers 會加入 WBSS，receivers 也不知道自己是否是目前加入此 WBSS 中 離 RSU 最 近 的 節 點 ， 所 以 必 須 要 使 用 廣 播 。 因 此 ， SMFS 只 能 將 封 包 利 用 MAC-layer 的廣播送出去，讓所有加入此 WBSS 的 user 都能收到，如此才能讓封包逐漸轉 發至 target receiver。
(2) RMFS：
RMFS 的 WBSS 建立過程與 SMFS 正好相反。如圖 2-11 所示，首先由 sender (original sender or forwarder) 在 CCH interval 發送 WSM (廣播) 告知 receiver (forwarder or target receiver)，receiver 收到此 WSM 之後便開始建立 WBSS，sender 便可以利用此服務在 SCH interval 傳送 IP 封包。使用廣播 WSM 的理由是最接近 RSU 的 OBU 不一定有機會成為 forwarder，因此只要在附近收到此 WSM 的 OBU 都可以提供服務讓 sender 選一個最接近 RSU 的 WBSS 加入。
另外，forwarder 也可以藉由收到其他 forwarder 所發出的 advertisement 來判斷自己是否 比別的 forwarder 更接近 RSU，如此 forwarders 也可以自行判斷是否有必要繼續提供服務讓 sender 傳送封包。
第三章 基於最小延遲時間之路徑最佳化設計
如前一章所述，在車載無線網路中兩個節點可以透過 WBSS 的建立與加入來傳輸資料， 但是如果節點之間距離超過兩個 hop 以上的情況下，就必須使用 multi-hop forwarding 的機制 來傳輸資料。本篇論文的主要目的就是使用 [17] 所提出的機制搭配 AODV 路由協定來達到 類似 WAVE ad-hoc mode 的網路存取方式，並且利用最小延遲時間演算法來做路徑最佳化， 以降低在車載無線網路中傳輸資料的延遲時間，並提高效能。 本章節會介紹我們在 multi-hop forwarding 系統架構上的想法和所做的改變，以及路徑最 佳化演算法的設計。
3.1. multi-hop forwarding 系統架構
在車載無線網路中因為每個節點在同一時間只能建立或加入一個 WBSS，並且每一次 WBSS 建立與加入都需要有相對應的 provider 和 user，所以我們考慮以下三種作法： 3.1.1. Case I：每次傳輸資料都會建立一次 WBSS 如圖 3-1 所示，我們不考慮在傳輸路徑上的 Receiver、Sender 和 Forwarder 是否加入同一 個 WBSS，而是在每次要傳輸資料或轉發資料時都必須由相鄰兩個節點建立和加入 WBSS 才 能開始傳輸資料，而 Receiver 和 Sender 需要 Forwarder 的幫助來傳輸資料，Sender 必須先透過 WBSS 的建立將封包送至 Forwarder 之後，再一個 hop 一個 hop 傳遞出去直到目的地 (Receiver) 為止，也就是說每傳輸一個 hop 都要重新建立一次 WBSS，經過數次 WBSS 的 建立與加入最後才能將封包送達 Receiver。這個作法每傳輸一個 hop 就必須執行一次 WBSS 的建立與加入流程，所以會有資源浪費以及延遲時間較長的缺點。優點是用此作法的話，只在需要傳輸資料的時候才會建立與加入 WBSS，不會一直佔用節點的資源。
圖 3-1 WBSS must be establish and join every hop
3.1.2. Case II：所有節點加入同一個 WBSS 如圖 3-2 所示，為了解決 Case I 的缺點，我們考慮在傳輸資料的路徑上每一個節點都加 入同一個 WBSS，此種作法下只需要由 Sender 建立一次 WBSS ，轉送資料的所有 Forwarders 和 Receiver 都必須加入此 WBSS，就可以開始傳輸資料。或者是由 Receiver 建立 WBSS， 當 Receiver 收到 Sender 的 WSM 廣播訊息便可以開始建立 WBSS，然後傳輸路徑上的 Sender 和 Forwarders 都加入此 WBSS 便可以開始傳輸資料。 用此作法的話可以解決 Case I 需要每次都建立 WBSS 的缺點，但是因為在車載無線網路 環境下 Receiver 會高速移動，會使得傳輸路徑變長，forwarding 次數也會變多，那麼會有延 遲時間變長以及封包遺失的機率變高的缺點。而且當 WBSS 開始建立與加入時，便會開始佔 用節點資源，直到資料傳輸完為止。
圖 3-2 Every node join the same WBSS
3.1.3. Case III：Dynamic WAVE-Area 選擇較近的 WBSS provider 傳輸資料
我們希望可以解決 Case I 和 Case II 缺點，所以考慮可以動態的建立與加入 WBSS，還 有為了避免傳輸路徑過長，我們利用 [17] 的 Dynamic WAVE-Area 的機制來緩存和轉發資 料，如此一來 Receiver 便可以選擇離自己較近的 RSU 傳輸資料，避免傳輸路徑過長。
如圖 3-3 所示，在車載無線網路中，Receiver 快速移動時，透過 Dynamic WAVE-Area 的 機制 ，相鄰 的 WBSS providers 會組成一個 Dynamic WAVE-Area 來緩存和轉發資料給 Receiver，所以當 Receiver 要接收資料時便可以選擇離自己較近的 WBSS provider 來建立連 線。此種作法在傳輸資料時 WBSS 的建立與加入是採用 Case II 的方法，亦即 WBSS 不需 要每傳輸一個 hop 就建立一次，可以避免 Case I 的缺點。
另外因為可以選擇離 Receiver 較近的 WBSS provider 傳輸資料，不會因為 Receiver 移 動使得傳輸路徑變長，所以也可以解決 Case II 的缺點。但是如果相鄰的 WBSS providers 太 多可能會發生訊框的碰撞。
圖 3-3 Receiver join the recent WBSS
分析以上三種不同的 WBSS 的建立與加入之作法，我們發現 Case III 的作法在車載無線 網路的資料傳輸上會有較佳的效能，因為 Case III 的作法 Receiver 會先搜尋離自己最近的 RSU 來做資料傳輸，而如果需要透過 Forwarder 來轉送資料的話，還可以配合其他 Ad-hoc Routing Protocol (例如：AODV 或 DSR 等) 來做路徑最佳化，以減少無線資源的浪費並且提 高傳輸效能。下一節將介紹我們所提出的路徑最佳化的作法。
3.2. 路徑最佳化設計
如前文所述，我們希望在車載無線網路環境中的資料傳輸可以有 WAVE ad-hoc mode 的 網路存取方式，因此需要 Forwarders 的幫忙，我們在路徑搜尋上選擇使用 AODV 協定，因 為 AODV 是一種簡單容易實作的行動路由協定，通常可以用於各種無線網路環境中。它是一 種隨需求啟動的路由協定，當 Sender 需要傳送資料時才會開始尋找路徑，並且在尋找的過程 中會將路徑資訊儲存在節點的路由表中，如此一來便可以節省電力和網路頻寬的消耗。在 AODV 中，每一個行動節點需要維護自己的路由資訊，當行動節點需要傳送資料且同時在路 由表內找不到路徑，又或者該筆路徑已經失效的時候，將會啟動路徑搜尋程序 (Route Discovery)
來搜尋路徑並且更新路由表資訊。
由於我們希望傳輸資料的過程中，不要在轉送和重傳浪費太多時間，並且縮短傳送的延遲 時間，所以我們提出最小延遲時間演算法來使得車載網路中 multi-hop forwarding 的路徑最佳 化並且縮短整體的延遲時間。因此，在車載無線網路中我們假設 Receiver 透過 multi-hop forwarding 可以跟 n 個 RSUs 作通訊，令 Di 為 Receiver 使用 AODV 找到第 i 個 RSU
並與之傳輸資料的延遲時間，i = 1, 2, 3, ..., n。那麼，如公式 (1) 所示，D 即為 Receiver 跟所 找到的 RSU 建立通訊的最小延遲時間。
………(1)
也就是說 Receiver 透過 multi-hop forwarding 可以跟很多的 RSUs 作通訊，透過此演算法我 們找到其中延遲時間最小的 RSU 來做通訊，以達到較佳的傳輸效率，因為延遲時間較低，所 以我們稱之為路徑最佳化演算法設計。 再來我們舉一個簡單的例子來說明路徑變化過程，在圖 3-4 中 Receiver 一開始是從 RSU1 接收資料，當 Receiver 移動後變成圖 3-5 的網路環境時，首先我們會考慮 Receiver 是否繼續 跟 RSU1 做通訊。如果透過我們的演算法設計後，得到 D = D1，表示 Receiver 仍然可以與 RSU1 做通訊，則繼續與 RSU1 傳輸資料，不重新尋找新的路徑，可以節省時間。反之，則重 新尋找與 Receiver 通訊時延遲時間較低的 RSU 來傳輸資料，尋找的方式有分被動式和主動 式兩種。被動的方法是透過 AODV 路由協定中的任何方式偷聽到路徑資訊，再透過公式 (1) 選擇較適當的路徑來建立通訊，而因為鄰近的節點並不一定隨時都在做資料傳輸，所以不一定 能偷聽到我們所需的路徑資訊。因此，還要透過主動搜尋的方式來尋找路徑，也就是路由發現 的程序，尋找符合我們在公式 (1) 中所定義的 D 值之路徑。在重新找到與 Receiver 做通訊 時延遲時間較小的 RSU 之後 (圖 3-5 中的 RSU2)，Receiver 會發送轉發資料的請求給 RSU1，
RSU1 收到後會透過 Dynamic WAVE-Area 的機制將資料轉發給 RSU2，RSU2 再將資料傳給
圖 3-4 Receiver communication with RSU1 before move
第四章
路徑最佳化系統實作
在第三章有提到，我們選擇 AODV 路由協定來做路徑最佳化設計，而在章節 2.2.2 中已 經提過 AODV 路由協定路徑搜尋的程序運作。因此，在本章節我們將介紹如何修改 AODV 路由程式的原始碼，來實作路徑最佳化系統以達到最小延遲時間的目的。
為了簡單起見，我們在系統實作的地方只列出 recvRequest( )、recvReply( )、rt_update( ) 這三個主要的函數。
4.1. AODV 程式說明
在傳統的 AODV 路由協定是使用最小跳躍數 (Minimum hop count) 作為 Routing Metric 來選擇路徑，但是車載無線網路環境中因為有 fading、multi-path、interference 和 movement 等 問題，嚴重影響到無線網路的鏈結品質 (Link Quality)，導致封包遺失率變高或是傳輸延遲時 間變高。因此我們將鏈結品質考慮進去並以延遲時間作為 Routing Metric 來選擇路徑。所以 我們將修改 NS2 中 AODV 的原始碼以達成我們的最佳路徑化系統實作。 首先我們將介紹 AODV 路由協定的流程圖，如圖 4-1 所示，在程式中 AODV 的封包接收 運作流程都由 recv ( ) 函數開始執行。當 recv ( ) 收到封包後，會先判斷此封包的類型是否為 AODV 協定的封包，如果是的話則交由 recvAODV ( ) 函數來執行，在此函數中可以看到分 為四個主要的 Case 來執行：recvRequest ( )、recvReply( )、recvError ( ) 和 recvHello ( )。我 們先說明 recvError ( ) 和 recvHello ( ) 函數的運作過程，recvRequest ( ) 和 recvReply( ) 函數 會分別在章節 4.2 和章節 4.3 詳細介紹。
圖 4-1 Packet Reception Routines recvError ( )： 如果收到的是路由錯誤的封包，意即鄰居節點已經離開傳輸範圍而無法到達，則會調 用此 recvError ( ) 進行處理。首先，節點會清除所有受到影響的路由表，丟棄所有受影響 的封包。然後，如果 precursor list 中存在有此無法到達的節點，則會將其從鄰居清單中 移除，並且依反向路徑轉發錯誤訊息 (sendError ( ) 函數) 給反向路徑上的所有節點，直 到來源節點為止。最後，所有收到 sendError ( ) 的節點都會將此無法到達的節點資訊從 路由表中移除，透過這個步驟可以做到 AODV 中的路徑維護。
recvHello ( )：
如果收到的是 Hello message 的封包，就會調用此 recvHello ( ) 函數進行處理，節點 會將 發送 Hello message 的該鄰居節點的訊息加入鄰居列表中或是更新該鄰居節點的訊 息。
如果在 recv ( ) 函數中判斷到的封包類型不是 AODV 協定的封包，那麼即為資料封包。 首先，會判斷此資料封包是否已經發送過，如果是的話會將此封包丟棄，避免造成 routing loop。然後檢查 TTL (Time To Live) 值是否為 0，如果是的話一樣將此封包丟棄。最後，封包 不是已經發送過的，也不是 TTL 值為 0 的封包的話，節點將會根據封包的目的地做不同處 理。 如果目的節點路由未知，則調用 rt_resolve ( ) 函數進行路由解析和轉送。 在 rt_resolve ( ) 函數中，如果目的節點路由在路由表中存在，則直接調用 forward ( ) 函數轉送。如果封包是由節點本身產生，亦即節點為來源端，則將封包緩存到 Queue 中， 並調用 sendRequest ( ) 函數查詢目的路由。如果目的路由已知，但是正在進行本地修復， 則將封包緩存到 Queue 中。否則，丟棄該封包，並調用 sendError ( ) 函數做錯誤回報。 如果目的節點路由已知，則調用 forward ( ) 函數進行轉送。 在此函數中，節點會先丟棄 TTL 為 0 的封包，並根據封包類型決定下一步操作。 如果接收到的是資料封包，且自身為目的節點，表示封包已送達目的地，結束處理。否則， 節點會將封包往目的節點轉送出去。 以 上 就 是 AODV 路 由 協 定 在 節 點 收 到 封 包 後 的 一 個 處 理 程 序 ， 接 下 來 我 們 來 看 recvRequest ( ) 和 recvReply( ) 函數的詳細運作程序。
4.2. recvRequest ( ) 函數說明與系統實作
4.2.1. recvRequest ( ) 函數說明 圖 4-2 為 recvRequest ( ) 函數的流程圖。首先，如果該封包是由節點自身產生或已經接收 過的，則會被節點丟棄，並結束處理。否則，節點將緩存該封包的序列號碼，並查詢節點是否 存在反向路由，如果沒有的話，則建立反向路由並將該封包發送來的路由添加到反向路由中。 如果節點存在反向路由，則檢查反向路由是否需要更新。需要更新的話，會調用 rt_update ( ) 函 數進行更新。然後，節點根據該封包的目的位址進行判斷並調用不同函數進行處理，會有以下 三種不同的處理情況。 如果節點自身即為目的節點，則調用 sendReply ( ) 函數傳送回應訊息。 如果節點不是目的節點，但知道通往目的節點的路由，則調用 sendReply ( ) 函數傳 送回應訊息，並在往來源節點和往目的節點的 precursor list 中分別插入到來源節點 和到目的節點的下一跳節點位址。 如果節點不是目的節點，而且也不知道通往目的節點的路由，就沒辦法直接傳送回應 訊息回應該請求，那麼會將 hop count 加 1，並調用 forward ( ) 函數轉發該封包。4.2.2. recvRequest ( ) 系統實作
在上述 recvRequest ( ) 函數的流程圖中，我們可以看到其中有判斷路由表是否需要更新 的步驟。圖 4-3 為 AODV without route optimization 中 recvRequest ( ) 函數的程式片段，在傳 統的 AODV 路由協定中，路由表是否需要更新主要是依據 hop count 來判斷，如果 hop count 較小表示路徑較短，因此會更新路由表。
在第三章我們所提到的路徑最佳化設計是基於最小延遲時間演算法，因為在傳統的基於最 小 hop count 的判斷方式中，如果因為鏈結品質不好或是頻道壅塞可能會導致延遲時間過長， 以至於效能降低。因此我們所提出的基於最小延遲時間之路徑最佳化設計可以在 route discovery 的過 程中選 擇延 遲時 間 較小 的路徑 來 傳送資料 。圖 4-4 為 AODV with route optimization 中我們修改過後 recvRequest ( ) 函數的程式片段，我們將其原本用 hop count 來 判斷是否需要更新路由表改成使用 delay time 來判斷。
void AODV::recvRequest (Packet *p) {
struct hdr_ip *ih = HDR_IP (p);
struct hdr_aodv_request *rq = HDR_AODV_REQUEST (p); aodv_rt_entry *rt0;
rt0 = rtable.rt_lookup(rq->rq_src);
if ( (rq->rq_src_seqno > rt0->rt_seqno) || ( (rq->rq_src_seqno == rt0->rt_seqno) && (rq->rq_hop_count < rt0->rt_hops) ) )
{
rt_update ( rt0, rq -> rq_src_seqno, rq -> rq_hop_count, ih -> saddr ( ),
max ( rt0 -> rt_expire, ( CURRENT_TIME + REV_ROUTE_LIFE ) ) ) ; }
}
4.3. recvReply ( ) 函數說明與系統實作
4.3.1. recvReply ( ) 函數說明 圖 4-5 為 recvReply ( ) 函數的流程圖。當收到回應訊息時，節點首先會查詢正向路由表 中是否有到目的地的路由，如果沒有的話則新增一條正向路由項。然後，檢查正向路由表是否 需要更新，如果需要更新的話，會調用 rt_update ( ) 函數進行更新。之後，節點根據該封包的 目的位址進行判斷並調用不同函數進行處理，一樣會有以下三種不同的處理情況。 如果節點自身即為目的節點，則更新 route discovery 的延遲時間，並將所有緩存在 buffer 中目的地為此節點的封包發送給此節點。 如果節點不是目的節點，但是知道通往目的節點的路由，則將通往來源節點的 nexthop 插入 precursor list 中 ，再將 hop count 加 1 並調用 forward ( ) 函數轉發該 封包給來源節點。void AODV::recvRequest (Packet *p) {
struct hdr_ip *ih = HDR_IP (p);
struct hdr_aodv_request *rq = HDR_AODV_REQUEST (p); aodv_rt_entry *rt0;
rt0 = rtable.rt_lookup (rq->rq_src);
if ( ( rq->rq_src_seqno > rt0->rt_seqno ) || ( ( rq->rq_src_seqno == rt0->rt_seqno ) && ( (CURRENT_TIME - rq->rq_timestamp) < rt0->rt_delaytime ) ) )
{
rt_update ( rt0, rq->rq_src_seqno, (CURRENT_TIME - rq->rq_timestamp), ih->saddr ( ), max ( rt0->rt_expire, ( CURRENT_TIME + REV_ROUTE_LIFE ) ) );
} }
如果節點不是目的節點，也不知道通往目的節點的路由，則丟棄該封包。
圖 4-5 The procedure of recvReply ( ) function
4.3.2. recvReply ( ) 系統實作
如章節 4.2.2 所述，在 recvReply ( ) 函數中一樣也有類似的判斷路由表是否需要更新的 步驟。圖 4-6 為 AODV without route optimization 中 recvReply ( ) 函數的程式片段，我們可以
看到判斷路由表是否需要更新的主要依據一樣是 hop count。
圖 4-7 為 AODV with route optimization 中我們修改過後 recvReply ( ) 函數的程式片段， 我們一樣用基於最小延遲時間之路徑最佳化設計的方法將原本用 hop count 來判斷是否需要更 新路由表改成使用 delay time 來判斷。
圖 4-6 recvReply ( ) function of AODV with route optimization void AODV::recvReply (Packet *p)
{
struct hdr_ip *ih = HDR_IP (p);
struct hdr_aodv_reply *rp = HDR_AODV_REPLY (p); aodv_rt_entry *rt;
rt = rtable.rt_lookup(rp->rp_dst);
if ( (rt->rt_seqno < rp->rp_dst_seqno) || ( (rt->rt_seqno == rp->rp_dst_seqno) && (rt->rt_hops > rp->rp_hop_count) ) )
{
rt_update (rt, rp->rp_dst_seqno, rp->rp_hop_count, rp->rp_src, (CURRENT_TIME + rp->rp_lifetime) );
} }
void AODV::recvReply (Packet *p) {
struct hdr_ip *ih = HDR_IP (p); struct hdr_aodv_reply *rp = HDR_AODV_REPLY (p);
aodv_rt_entry *rt;
rt = rtable.rt_lookup(rp->rp_dst);
if ( (rt->rt_seqno < rp->rp_dst_seqno) || ( (rt->rt_seqno == rp->rp_dst_seqno) && (rt->rt_delaytime > (CURRENT_TIME - rp->rp_timestamp) ) ) )
{
rt_update(rt, rp->rp_dst_seqno, (CURRENT_TIME - rp->rp_timestamp), rp->rp_src, (CURRENT_TIME + rp->rp_lifetime) );
} }
4.4. rt_update ( ) 函數說明與系統實作
在章節 4.2 和 4.3 中我們可以看到 AODV 路由協定的路由表如果需要更新時，會調用 rt_update ( ) 函數來進行處理，所以此函數在 route discovery 的運作程序中是非常重要的。圖 4-8 為 rt_update ( ) 函數的原始碼，在此函數中所儲存的資訊即為 AODV 路由表中每個欄位 的資訊，我們可以看到其中 metric 為 rt->rt_hops，亦即 hop count 為判斷路由表是否需要更 新的重要依據。
圖 4-9 為 AODV with route optimization 中我們修改過後 rt_update ( ) 函數的程式碼，我們 將 metric 改為 rt->rt_delaytime，表示我們使用延遲時間來代替原本的 hop count。如此便可以 實作基於最小延遲時間之路徑最佳化設計。
圖 4-8 rt_update ( ) function of AODV without route optimization void AODV::rt_update (aodv_rt_entry *rt, u_int32_t seqnum, u_int16_t metric,
nsaddr_t nexthop, double expire_time) { rt->rt_seqno = seqnum; rt->rt_hops = metric; rt->rt_flags = RTF_UP; rt->rt_nexthop = nexthop; rt->rt_expire = expire_time; }
void AODV::rt_update (aodv_rt_entry *rt, u_int32_t seqnum, double metric, nsaddr_t nexthop, double expire_time)
{ rt->rt_seqno = seqnum; rt->rt_delaytime = metric; rt->rt_flags = RTF_UP; rt->rt_nexthop = nexthop; rt->rt_expire = expire_time; }
第五章
實驗模擬與分析討論
在本章節我們將介紹實驗模擬所使用的軟體。再來，說明我們的實驗環境以及各項參數設 定。最後，我們分析與討論使用 AODV routing protocol without route optimization (RO) 和 AODV routing protocol with RO 的實驗模擬結果。
5.1. NS2 網路模擬軟體介紹
NS2 [21][22] 是一種針對網路技術的源代碼公開的且免費的軟件模擬平台，研究人員使用 它可以很容易的進行網路技術的開發，而且發展到今天，它所包含的模組已經非常豐富，幾乎 涉及到了網路技術的所有方面。所以，NS2 成了目前學術界廣泛使用的一種網路模擬軟體。 在每年國內外發表的有關網路技術的學術論文中，利用 NS2 做實驗模擬結果的文章最多，通 過這種方法得出的研究結果也是被學術界所普遍認可的，此外，NS2 也可作為一種輔助教學 的工具，已被廣泛應用在網路技術的教學方面。因此，目前在學術界和教育界，有大量的人正 在使用或試圖使用 NS2。 NS2 是一個離散事件模擬器，由 UC Berkeley 開發而成。離散事件模擬是幾種常用的系 統模擬模型之一。簡單的說，它本身有一個虛擬時鐘，所有的模擬都由離散事件驅動的，目前 NS2 可以用於模擬各種不同的網路傳輸協定。 NS2 使用 C++ 和 Otcl 作為開發語言。NS2 可以說是 Otcl 的腳本解釋器，它包含模擬 事件調度器 (Scheduler)、網路組件對象庫以及網路構建模型庫等。事件調度器計算模擬時間， 並且啟動事件隊列中的當前事件，執行一些相關的事件，網路組件通過傳遞封包來相互通信， 但這並不耗費模擬時間。所有需要花費模擬時間來處理封包的網路組件都必須要使用事件調度器。它先為這個分組發出一個事件，然後等待這個事件被調度回來之後，才能做下一步的處理 工作。事件調度器的另一個用處就是計時。NS2 是用 Otcl 和 C++ 編寫的。由於效率的原因， NS2 將數據通道和控制通道的實現相分離。為了減少封包和事件的處理時間，事件調度器和 數據通道上的基本網路組件對象都使用 C++ 寫出並編譯的。當模擬完成以後，NS2 將會產生 一個或多個基於文本的 trace 文件。只要在 Tcl 腳本中加入一些簡單的語句，這些文件中就 會包含詳細的跟蹤信息。這些數據可以用於下一步的分析處理，也可以使用 NAM 將整個模擬 過程展示出來。 進行網路模擬前，首先分析模擬涉及哪一個層次，NS2 模擬分為兩個層次：一個是基於 OTcl 編譯的層次。利用 NS2 已有的網路元素實現模擬，無需修改 NS2 本身，只需編寫 OTcl 腳本。另一個是基於 C++ 和 OTcl 編譯的層次。如果 NS2 中沒有所需的網路元素，則需要 對 NS2 進行擴展，添加所需網路元素，即添加新的 C++ 和 OTcl 類，編寫新的 OTcl 腳本。 假設用戶已經完成了對 NS2 的擴展，或者 NS2 所包含的構件已經滿足了要求，那麼進行一 次模擬的步驟大致如下： (1) 開始編寫 OTcl 腳本。首先配置模擬網路拓撲結構，此時可以確定鏈路的基本特性，如延 遲、頻寬和丟失策略等。 (2) 建立協定代理，包括端設備的協定綁定和通信業務量模型的建立。 (3) 配置業務量模型的參數，從而確定網路上的業務量分佈。 (4) 設置 Trace 對象。NS2 通過 Trace 文件來保存整個模擬過程。模擬完後，用戶可以對 Trace 文件進行分析研究。 (5) 編寫其他的輔助過程，設定模擬結束時間，至此 OTcl 腳本編寫完成。 (6) 用 NS2 解釋執行剛才編寫的 OTcl 腳本。 (7) 對 Trace 文件進行分析，得出有用的數據。 (8) 調整配置拓撲結構和業務量模型，重新進行上述模擬過程。 NS2 採用兩級體系結構，為了提高代碼的執行效率，NS2 將數據操作與控制部分的實現
相分離，事件調度器和大部分基本的網路組件對象後台使用 C++ 實現和編譯，稱為編譯層， 主要功能是實現對數據包的處理；NS2 的前端是一個 OTcl 解釋器，稱為解釋層，主要功能 是對模擬環境的配置、建立。從用戶角度看，NS2 是一個具有模擬事件驅動、網路構件對象 庫和網路配置模塊庫的 OTcl 腳本解釋器。NS2 中編譯類對象通過 OTcl 連接建立了與之對 應的解釋類對象，這樣用戶間能夠方便地對 C++ 對象的函數進行修改與配置，充分體現了模 擬器的一致性和靈活性。 因此我們使用 NS2 來作為論文的實驗模擬工具，利用 NS2 的網路模擬功能以及內建的 網路路由協定，在加入我們提出的 Route Optimization 機制來完成路徑最佳化的設定。透過 NS2 所獲得的實驗數據在利用 Excel 來繪圖已呈現最後的結果並分析討論。
5.2. 實驗模擬環境與參數設定
本篇論文我們選擇使用 NS-2.34 版本來進行實驗。網路拓樸如圖 5-1 所示，在我們的實 驗環境中是以一井字型雙向道路為例，每一條道路全長 2000 公尺，在道路的交叉路口，亦即 4 個角落有 4 個 RSUs 其座標分別為 (1800,1800)、(400, 1800)、(400, 400)、(1800, 400)，RSU 的通訊範圍約為 250 公尺。中間的 Host 為傳輸資料的來源端，其透過 mobile router 可以跟 4 個 RSUs 連結，有線的 point-to-point link 頻寬為 5Mbps，在實驗中 RSUs 會透過 mobile IP 的機制將封包傳給移動中的車子 (目的端)，即 mobile node (MN)。MN 的移動速度為每秒 20 公尺，移動路徑為從右上角座標位置（2000, 2000）開始逆時針依正方形路徑移動，途中經過 （200, 2000）、（200, 200）、（2000, 200），直到實驗結束，本實驗每次測量時間為 360 秒。詳細 的實驗參數設定如表 5-1 所示。 除了 MN 之外，在道路上我們會隨機佈建數量不等的車子，並且讓這些車子依不同速度 隨機移動，這些車子在我們的實驗中是當作 Forwarder 來轉送資料。另外，我們還會在這些 車子之中隨機產生流量，用來觀察當頻寬壅塞時，平均延遲時間和封包接收率的變化情況。圖 5-1 Simulation WAVE network topology
表 5-1 simulation parameters setting
Parameters type Parameters values
MAC protocol IEEE 802.11p
Simulation time 360 sec
Simulation area 2000 m x 2000 m
MN speed 20 m/s
Mobility model Manhattan model
Traffic type CBR
Radio frequency 5.9 GHz
本實驗另外還利用三種不同的環境變數設定來分析在不同環境下的效能，如表 5-2 所示， 我們將考慮道路中隨機佈建的車子總數、這些車子的平均移動速度以及在這些車子之間所產生 的隨機流量數這三種變數，並且每種變數有五種可能的值，我們會將所有可能產生的情況都考 慮進去，因此全部總共有 5x6x5 = 150 種情況。其中，random traffic 表示我們在隨機佈建的 車子中，任選兩台來互相傳送 CBR 封包的連線數。每一個連線的 CBR 封包大小固定為 512 bytes，速度為每秒送出去 10 個封包。我們將分析在這 125 種不同環境下 routing protocol with RO 和 routing protocol without RO 的實驗數據，來瞭解不同變數對我們所提出的機制的影響 以及在相同變數下 routing protocol with RO 和 routing protocol without RO 的效能比較。
表 5-2 simulation variables setting
Variables Type Variables Values
Amount of Vehicles 20 40 60 80 100
Average speed (m/s) 5 10 15 20 25 30
random traffic (connections) 5 10 15 20 25
5.3. 實驗結果與分析討論
我們想要知道在 IEEE 802.11p 的網路環境下，使用我們所設計的機制對於 routing protocol 路徑的建立有何影響。在此將依照上述的變數設定分別比較 routing protocol with RO 和 routing protocol without RO 在 IEEE 802.11p 網路上的效能，我們觀察 Average Delay Time、Packet Delivery Ratio、Average jitter 和 Average throughput 的數據變化來分析我們所提 出的機制效能是否有比較好，以及在何種道路環境下效能會比較好。所以我們的 Performance
