國立臺中教育大學資訊科學學系碩士論文
指導教授：林嬿雯 博士
一個針對車載網路繞徑之可應變式
接手節點挑選機制
An Adaptive Next-Hop Selection
Scheme for VANET Routing
研究生：黃國唐 撰
中華民國一百年七月
致謝
首先誠摯的感謝我的指導教授林嬿雯老師，在這兩年來不辭辛苦的悉心指導， 並提供我完整的研究學習成長環境，讓我能夠在此環境中學習到許多寶貴的經驗， 使我能順利得完成此論文，並培養我所欠缺的能力。本論文的完成另外亦得感謝 口詴委員顧維祺老師和陳澤雄老師提供寶貴的建議，使得本論文能更加完整與充 實。 我也要感謝實驗室的學長姐、同學和學弟們：芳瑜學姐、豐旭學長、鈺軒學 姐、介民、昱群、舜斌、博仁、怡涵、和展、益華、瑋辰、冠霖、浩鈞和家浚等， 讓我能更快適應新環境，以及解決我在學業上所遇到的疑惑。特別感謝介民和博 仁讓我體會到很不一樣的求學階段，不僅結識更多學弟妹，也充實了學業以外的 活動；也要感謝浩鈞的幫助使我的研究有所突破與順利。另外更要特別感謝我的 前室友仲麒，陪我度過這七百多天的夜晚，與我討論學業、運動和日常生活大小 事等；以及感謝目前的室友天亮，總是與我分享學校的事情。 最後感謝我的家人，鼓勵我繼續求學，適時給我精神上的慰藉，並全力支持 讓我完成學業，在此僅以本論文獻給我的父親、母親、兩位弟弟、外公、外婆、 舅舅與舅媽及兩位表弟，希望你們能與我分享這份喜悅。I
摘要
車載網路(Vehicular Ad hoc Networks；VANET)的應用，包括改善道路安全及 使用者舒適性等，越來越普及。然而，VANET的特性，包括快速改變的網路拓 樸及車輛高速移動性等是應用VANET的挑戰。路由的效能大大影響VANET系統 的成效。雖然，已經有許多路由協定被提出，但上述問題並未完全解決。尤其， 當在不同道路環境下針對不同VANET應用要求有不同QoS類型時，如即時性 (Real-Time)應用服務或非即時性(Non-Real-Time)應用服務，前者包含緊急訊息、 語音串流或On-Line Game等；後者包含E-mail、檔案傳送之應用等，目前已存在 的盡力式(Best Effort)路由協定，因為是著重在找到一條最短的路徑或者是延遲最 小的路徑，但在車載環境中不一定會是最佳的路徑。目前，針對解決QoS需求的 路 由 協 定， 大 部分 只有 考 慮 單一 QoS 需求， 如 頻 寬 (Bandwidth) 、 延 遲 時 間 (End-to-End Delay)或生產量(Throughput)等，致使無法滿足不同QoS需求。 為了解決這個問題，本論文旨在提出一個新的路由協定，使其具有應變 (Adaptive)的能力，意即，針對不同QoS需求的應用尋找到最佳的接手(Next-Hop) 節點。為了達成上述目標，本文提出的方法考慮了許多議題，包括區分QoS類型、 鏈結存活時間(Link Lifetime)評估、頻寬評估及挑選最佳接手(Optimal Next-Hop) 節點的方法等。模擬實驗證明，本論文提出的方法，不僅能增加網路封包到達率 及降低路由延遲時間，且不需要額外的控制訊息成本，即可讓使用者在車載網路 傳輸資料封包時獲得更好的連線品質。
關鍵詞:車載網路、服務品質類型、可應變式的、接手節點、鏈結存活時間、頻 寬
II
Abstract
VANET applications become more and more popular for improving road safety and user’s comfort. The features of VANET, including rapidly changing network topology and high mobility, hinder the deployment of the VANET applications. Thus, the effectiveness of the routing protocols greatly affects the performance of a VANET system. The problems are partially solved though plenty of methods have been proposed. Different applications may request different QoS requirements. Real-time applications (such as emergency messages, voice streaming, and on-line games etc.) need short delay while non-real-time applications (such as e-mail, and file transfer application etc.) want less packet loss. However, existed best effort routing protocols cannot satisfactorily meet diverse QoS needs.
To remedy these problems, this thesis research aims at proposing a new routing protocol which is adaptive in selecting optimal next-hop node for distinct applications with different QoS requirements. Research issues, including QoS type classification, link lifetime evaluation, bandwidth evaluation, and optimal next-hop selection, are considered to achieve the objective. As shown in the simulation results, the proposed next-hop selection scheme can improve packet delivery rate, reduce end-to-end delay, and lessen signaling overhead in VANET.
III
目錄
摘要 ··· I Abstract··· II 目錄 ··· III 表目錄 ··· VI 圖目錄 ··· VII 第一章 緒論 ··· 1 1.1 研究動機 ··· 1 1.2 問題描述 ··· 1 1.3 研究目標 ··· 1 1.4 論文架構 ··· 2 第二章 背景與相關研究 ··· 3 2.1 VANET ··· 3 2.1.1 VANET 研究議題與挑戰 ··· 3 2.2 QoS in VANET ··· 4 2.3 QoS-Aware ··· 5 2.4 Adaptive QoS ··· 6 2.5 Link Lifetime ··· 7 2.6 Bandwidth ··· 8 2.7 相關方法評述 ··· 9 2.7.1 AODV ··· 9 2.7.2 GPSR ··· 11 2.7.3 DGR ··· 12 第三章 研究方法··· 15 3.1 問題定義 ··· 15IV 3.2 研究目標 ··· 16 3.3 系統架構 ··· 17 3.3.1 訊息格式 ··· 18 3.3.2 路由表 ··· 19 3.4 可應變式接手節點挑選機制··· 20 3.4.1 鏈結存活時間評估 ··· 20 3.4.2 頻寬評估 ··· 21 3.4.3 可應變式接手節點挑選 ··· 23 3.4.4 方法虛擬碼 ··· 26 3.5 路由協定之比較 ··· 28 第四章 實驗模擬結果與分析 ··· 30 4.1 實驗環境與設定 ··· 30 4.2 效能評估項目 ··· 31 4.3 權重係數 α 的選擇 ··· 32 4.3.1 權重係數 α 在 Manhattan 移動模型之表現 ··· 33 4.3.1.1 權重係數 α 對帄均封包到達率的影響 ··· 33 4.3.1.2 權重係數 α 對帄均延遲時間的影響 ··· 34 4.3.1.3 權重係數 α 對帄均控制訊息成本的影響 ···· 36 4.3.2 權重係數 α 在 Freeway 移動模型之表現 ··· 38 4.3.2.1 權重係數 α 對帄均封包到達率的影響 ··· 38 4.3.2.2 權重係數 α 對帄均延遲時間的影響 ··· 40 4.3.2.3 權重係數 α 對帄均控制訊息成本的影響 ···· 42 4.3.3 權重係數實驗結果小結 ··· 43 4.3.4 使用正規化後效能表現之影響 ··· 44 4.4 Manhattan 移動模型下之效能表現 ··· 46
V 4.4.1 車輛數目對封包到達率的影響 ··· 46 4.4.2 車輛數目對帄均延遲時間的影響 ··· 48 4.4.3 車輛數目對控制訊息成本的影響 ··· 50 4.4.4 Manhattan 移動模型下實驗結果小結 ··· 52 4.5 Freeway 移動模型下之效能表現 ··· 53 4.5.1 車輛數目對封包到達率的影響 ··· 53 4.5.2 車輛數目對帄均延遲時間的影響 ··· 55 4.5.3 車輛數目對控制訊息成本的影響 ··· 57 4.5.4 Freeway 移動模型下實驗結果小結··· 60 4.6 總結 ··· 60 第五章 結論 ··· 61 5.1 貢獻 ··· 61 5.2 未來工作 ··· 61 參考文獻 ··· 63
VI
表目錄
Table 3.1：Terminology Definition ··· 17
Table 3.2：Comparison of Routing Protocol ··· 29
Table 4.1：模擬參數 ··· 31
Table 4.2：權重係數的選擇 ··· 44
Table 4.3：Comparison of Performance of Routing Protocol in Manhattan Mobility Model··· 53
Table 4.4：Comparison of Performance of Routing Protocol in Freeway Mobility Model··· 60
VII
圖目錄
Figure 2.1：Greedy Forwarding Example[28] ··· 12
Figure 2.2：Void 區域[28] ··· 12
Figure 2.3：The Right-Hand Rule[28] ··· 12
Figure 2.4：Routing Loop[29] ··· 14
Figure 2.5：The Direction First Forwarding Problem[29] ··· 14
Figure 3.1(a)：In Urban ··· 18
Figure 3.1(b)：In Freeway ··· 18
Figure 3.2：車輛移動模型 ··· 21
Figure 3.3：選擇最佳 Next-Hop 節點 ··· 23
Figure 3.4(a) Broadcast Hello Message ··· 26
Figure 3.4(b) Received of Hello Message ··· 26
Figure 3.4(c) Send RREQ Message ··· 26
Figure 3.4(d) Received of RREP Message ··· 26
Figure 4.1：Manhattan 移動模型(Mobility Model)[33] ··· 30
Figure 4.2：Freeway 移動模型(Mobility Model)[33] ··· 30
Figure 4.3(a)：Average Packet Delivery Rate v.s Number of Nodes (5 Sessions, CBR Transmission Type) ··· 34
Figure 4.3(b)：Average Packet Delivery Rate v.s Number of Nodes (10 Sessions, CBR Transmission Type) ··· 34
Figure 4.3(c)：Average Packet Delivery Rate v.s Number of Nodes (5 Sessions, FTP Transmission Type) ··· 34
Figure 4.3(d)：Average Packet Delivery Rate v.s Number of Nodes (10 Sessions, FTP Transmission Type) ··· 34
VIII
Figure 4.4(a)：Average End-to-End Delay v.s Number of Nodes
(5 Sessions, CBR Transmission Type) ··· 36 Figure 4.4(b)：Average End-to-End Delay v.s Number of Nodes
(10 Sessions, CBR Transmission Type) ··· 36 Figure 4.4(c)：Average End-to-End Delay v.s Number of Nodes
(5 Sessions, FTP Transmission Type) ··· 36 Figure 4.4(d)：Average End-to-End Delay v.s Number of Nodes
(10 Sessions, FTP Transmission Type) ··· 36 Figure 4.5(a)：Average Signaling Overhead v.s Number of Nodes
(5 Sessions, CBR Transmission Type) ··· 37 Figure 4.5(b)：Average Signaling Overhead v.s Number of Nodes
(10 Sessions, CBR Transmission Type) ··· 37 Figure 4.5(c)：Average Signaling Overhead v.s Number of Nodes
(5 Sessions, FTP Transmission Type) ··· 38 Figure 4.5(d)：Average Signaling Overhead v.s Number of Nodes
(10 Sessions, FTP Transmission Type) ··· 38 Figure 4.6(a)：Average Packet Delivery Rate v.s Number of Nodes
(5 Sessions, CBR Transmission Type) ··· 39 Figure 4.6(b)：Average Packet Delivery Rate v.s Number of Nodes
(10 Sessions, CBR Transmission Type) ··· 39 Figure 4.6(c)：Average Packet Delivery Rate v.s Number of Nodes
(5 Sessions, FTP Transmission Type) ··· 40 Figure 4.6(d)：Average Packet Delivery Rate v.s Number of Nodes
(10 Sessions, FTP Transmission Type) ··· 40 Figure 4.7(a)：Average End-to-End Delay v.s Number of Nodes
IX
Figure 4.7(b)：Average End-to-End Delay v.s Number of Nodes
(10 Sessions, CBR Transmission Type) ··· 41 Figure 4.7(c)：Average End-to-End Delay v.s Number of Nodes
(5 Sessions, FTP Transmission Type) ··· 41 Figure 4.7(d)：Average End-to-End Delay v.s Number of Nodes
(10 Sessions, FTP Transmission Type) ··· 41 Figure 4.8(a)：Average Signaling Overhead v.s Number of Nodes
(5 Sessions, CBR Transmission Type) ··· 43 Figure 4.8(b)：Average Signaling Overhead v.s Number of Nodes
(10 Sessions, CBR Transmission Type) ··· 43 Figure 4.8(c)：Average Signaling Overhead v.s Number of Nodes
(5 Sessions, FTP Transmission Type) ··· 43 Figure 4.8(d)：Average Signaling Overhead v.s Number of Nodes
(10 Sessions, FTP Transmission Type) ··· 43 Figure 4.9(a)：Packet Delivery Rate v.s Number of Nodes
(5 Sessions, CBR Transmission Type, α=0)··· 45 Figure 4.9(b)：Packet Delivery Rate v.s Number of Nodes
(5 Sessions, FTP Transmission Type, α=1) ··· 45 Figure 4.9(c)：Average End-to-End Delay v.s Number of Nodes
(5 Sessions, CBR Transmission Type, α=0)··· 45 Figure 4.9(d)：Average End-to-End Delay v.s Number of Nodes
(5 Sessions, FTP Transmission Type, α=1) ··· 45 Figure 4.9(e)：Signaling Overhead v.s Number of Nodes
(5 Sessions, CBR Transmission Type, α=0)··· 46 Figure 4.9(f)：Signaling Overhead v.s Number of Nodes
X
Figure 4.10(a)：Packet Delivery Rate v.s Number of Nodes
(5 Sessions, CBR Transmission Type, α=0)··· 48 Figure 4.10(b)：Packet Delivery Rate v.s Number of Nodes
(10 Sessions, CBR Transmission Type, α=0) ··· 48 Figure 4.10(c)：Packet Delivery Rate v.s Number of Nodes
(5 Sessions, FTP Transmission Type, α=1) ··· 48 Figure 4.10(d)：Packet Delivery Rate v.s Number of Nodes
(10 Sessions, FTP Transmission Type, α=1) ··· 48 Figure 4.11(a)：Average End-to-End Delay v.s Number of Nodes
(5 Sessions, CBR Transmission Type, α=0)··· 50 Figure 4.11(b)：Average End-to-End Delay v.s Number of Nodes
(10 Sessions, CBR Transmission Type, α=0) ··· 50 Figure 4.11(c)：Average End-to-End Delay v.s Number of Nodes
(5 Sessions, FTP Transmission Type, α=1) ··· 50 Figure 4.11(d)：Average End-to-End Delay v.s Number of Nodes
(10 Sessions, FTP Transmission Type, α=1) ··· 50 Figure 4.12(a)：Signaling Overhead v.s Number of Nodes
(5 Sessions, CBR Transmission Type, α=0)··· 52 Figure 4.12(b)：Signaling Overhead v.s Number of Nodes
(10 Sessions, CBR Transmission Type, α=0) ··· 52 Figure 4.12(c)：Signaling Overhead v.s Number of Nodes
(5 Sessions, FTP Transmission Type, α=1) ··· 52 Figure 4.12(d)：Signaling Overhead v.s Number of Nodes
(10 Sessions, FTP Transmission Type, α=1) ··· 52 Figure 4.13(a)：Packet Delivery Rate v.s Number of Nodes
XI
Figure 4.13(b)：Packet Delivery Rate v.s Number of Nodes
(10 Sessions, CBR Transmission Type, α=0.4) ··· 55 Figure 4.13(c)：Packet Delivery Rate v.s Number of Nodes
(5 Sessions, FTP Transmission Type, α=1) ··· 55 Figure 4.13(d)：Packet Delivery Rate v.s Number of Nodes
(10 Sessions, FTP Transmission Type, α=1) ··· 55 Figure 4.14(a)：Average End-to-End Delay v.s Number of Nodes
(5 Sessions, CBR Transmission Type, α=0.4) ··· 57 Figure 4.14(b)：Average End-to-End Delay v.s Number of Nodes
(10 Sessions, CBR Transmission Type, α=0.4) ··· 57 Figure 4.14(c)：Average End-to-End Delay v.s Number of Nodes
(5 Sessions, FTP Transmission Type, α=1) ··· 57 Figure 4.14(d)：Average End-to-End Delay v.s Number of Nodes
(10 Sessions, FTP Transmission Type, α=1) ··· 57 Figure 4.15(a)：Signaling Overhead v.s Number of Nodes
(5 Sessions, CBR Transmission Type, α=0.4) ··· 59 Figure 4.15(b)：Signaling Overhead v.s Number of Nodes
(10 Sessions, CBR Transmission Type, α=0.4) ··· 59 Figure 4.15(c)：Signaling Overhead v.s Number of Nodes
(5 Sessions, FTP Transmission Type, α=1) ··· 59 Figure 4.15(d)：Signaling Overhead v.s Number of Nodes
1
第一章 緒論
1.1 研究動機
VANET 應用包括改善道路安全及提供使用者舒適性等應用服務日漸普及， 但因 VANET 高速移動的特性，如何在快速變動的環境中傳遞資料，將大大影響 VANET 應用的可行性。然而，不同的應用服務有不同的 QoS 需求(Requirement)， 如何為使用者找到一個符合其 QoS 類型(Type)及當時網路連線狀況的接收節點， 是本論文的初衷。換言之，本論文旨在設計一個新的尋找接手節點的機制，其具 有讓使用者能依照 QoS 的類型並依當下網路連線狀態，應變地(Adaptively)選擇 路徑的能力。
1.2 問題描述
目前在 VANET 上的應用已逐漸受到重視，然而現有的盡力式(Best Effort) 服務路由協定將無法滿足 VANET 中多樣的資料傳輸類型。為此本文希望能透過 可應變式的挑選接手節點(Next-Hop)機制，尋找到合適的接手節點，以提高連線 品質。 部分文獻都只針對單一應用服務傳輸類型，為了達到在車輛間不同的應用服 務傳輸類型能有最佳的連線品質，系統必頇應變地(Adaptively)挑選 Next-Hop 節 點。因此本文的方法會強調如何尋找最佳的接手(Next-Hop)節點，讓使用者能依 照應用服務類型所需選擇通訊時間最長的節點或具有最大頻寬的節點。 1.3 研究目標 本研究旨在設計一個新的路由協定，其具有讓使用者對 QoS 的要求並可依 據當下網路連線狀態，應變地(Adaptively)選擇路徑的能力。 為了達成這些目標，有許多挑戰與工作要解決，包括： 設計 QoS 模型(Model)：本論文研究主軸為可應變式接手節點挑選機制，因 此要先定義的項目包括定義 QoS 的類型(Type)與使用者如何表達不同道路模 式下對 QoS 的要求(Requirement)其量測(Measurement)方法等。 接手節點的挑選：為因應 VANET 快速變動的特性，如何快速找到合適的接 手(Next-Hop)節點在路由協定中是重要的一環。因此，尋找附近可接手的節
2
點(Next-Hop Discovery)，並依據各節點可提供的 QoS 需求來挑選最佳的接手 (Optimal Next-Hop)節點。 因此，本文提出將會設計 QoS 處理模型和評估鏈結存活時間及頻寬評估的 方法，進而計算出權重值，藉此在網路拓樸環境中挑選最佳的 Next-Hop 節點。 1.4 論文架構 本篇論文分為五個章節，各章節介紹如下：第二章會先描述目前車載網路的 發展、研究議題和挑戰，並介紹 QoS 相關文獻和相關路由協定的評述。第三章 將詳述本論文所提出的可應變式接手節點挑選機制，包含鏈結存活時間的評估以 及頻寬的評估方式，最後是將上述兩種評估方式透過權重係數調整並加總求得權 重值，依不同移動模型及資料傳輸類型挑選出最佳的接手節點。第四章則是會對 權重係數的挑選作一系列的評估，以獲得最佳的權重係數。接著將依照不同移動 模型及 QoS 類型，使用不同權重係數進行路由協定效能分析與說明，以證明本 論文所提出之路由協定對網路效能的影響，能依照不同應用服務類型，選擇最適 當的接手節點。最後第五章為本篇論文結論。
3
第二章 相關研究
2.1 VANET 隨著無線網路的快速發展及行動裝置的普及化，網路應用已成為生活中不可 或缺的角色。人們也希望在行車時能使用網路的服務，讓資訊的取得更即時與方 便。因此，VANET 的研究議題在近年變得相當熱門。目前用於車載網路的技術 包含 2001 年美國聯邦通訊委員會(FCC)所提出的 DSRC(Dedicated Short-Range Communication)技術[1][2]，以及在 2004 年，由 IEEE802.11 Working Group 製訂 的標準 802.11p[3]，又稱為 WAVE(Wireless Access in the Vehicular Environment) 其可應用於道路危險警示、碰撞警示、行車安全等。 2.1.1 VANET 研究議題與挑戰 目前在車輛間通訊(IVC)有幾個重要的研究議題，包括[2]： 車間通訊兼顧服務品質的連線模式 設計良善的路由方式 可靠且穩固的網路存取(Network Access) 安全性與個人隱私問題等 其中，設計良好的路由協定(Routing Protocol)能決定是否有效率的在車輛間 傳遞封包，且在 VANET 環境下車輛高速移動所造成的影響將會是設計路由時重 要的考慮因素。[1][2]中有許多針對 MANET 所提出的路由設計，但使用在 MANET 所延伸出的 VANET 上，卻因節點高速移動、網路拓樸迅速改變等特性 造成效能低落[4]。此外本文將 VANET 中的應用服務概分為兩類，包括： 具即時性(Real Time)的應用服務：如前方有車輛發生事故，必頇立即傳送緊 急訊息給後方車輛，才能避免發生車禍。 不具即時性(Non-Real Time)的應用服務：如使用者可以透過車載網路，獲取 停車位資訊和商店資訊。4 然而，前者傳遞的資訊希望傳送給後方的車輛越快越好，過期的封包不但是 無用的資訊而且也來不及阻止意外的發生；後者傳遞的資訊較不具迫切性，使用 者可以容忍延遲，雖然可能需要傳送大量圖片而需要較大的頻寬，但是因為不具 即時性，封包可以先暫存起來，待網路條件允許再傳送出去。因此，若能適當挑 選資料傳遞的路徑，並依據不同應用服務提供具有服務品質(Quality of Service； QoS)的連線，將能使 VANET 應用服務更加完善。 2.2 QoS in VANET 在車載網路中提供服務品質保證(QoS)的相關研究有[5][6][7][8]。其中， Gvgrid[5]是使用電子地圖輔助選擇最穩定的路徑，該方法是針對車輛節點密度高 的都市環境所設計，並利用電子地圖將街道分成數個區塊，因此在挑選 Next-Hop 時，會對區塊內的所有鄰居節點進行廣播，但無法依據來源節點的傳輸應用服務 類型挑選到最佳接手節點。 文獻[6]討論在多重跳躍路徑(Multi-Hop)的車載環境中，使用 IEEE 802.11p 和 DSRC 的通訊技術，對於各種不同應用服務的連線服務品質進行效能分析。 可知不同的應用服務，QoS 需求也相對不同，因此該研究針對不同的頻寬建立不 同類型的連線服務，提出可以適應不同型態提供服務品質的多重路徑協定 (Adaptive QoS Routing Protocol over VANET；AQVA)，以提供在高速移動車輛中 有效存取影像視訊串流服務並提供具有服務品質最佳化的路徑。
在文獻[6][7][9]中認為在車載環境下，多媒體影音資料傳送對於可靠度和時 間延遲較一般服務嚴格。其中，DeReQ[7]的方法不只可以找到可靠的路徑更能 找到符合延遲需求的路徑。
文獻[7][10]皆考慮道路車輛密度(Road Density)、車輛相對速度，因此得到鏈 結可靠度模型(Link Reliability Model)：ρsd(Tsd,λ)。再透過鏈結可靠度模型推算兩 車間最後剩餘通訊時間 Tsd。LRA 表示兩車傳輸距離，VRS 表示移動速度，因此 剩餘通訊時間可以表示為：Tsd=LRA/VRS。最後並認為鏈結可靠度(Link Reliability)
5
的重要性比鏈結延遲(Link Delay)和 Hop 數要高，因此先求出最大鏈結可靠度後， 後續將再加入延遲時間與 Hop 數限制的考慮，來做為找尋符合 QoS 等級的路徑。
文獻[8]則是探討 Beacon 安全性訊息如何在壅塞的車載環境中進行傳播。由 實驗的角度依據不同 QoS 的評量標準[9]，如封包到達率、延遲時間等因素作為 實驗參數，並認為影響這些參數的因子有傳輸範圍、訊息傳輸區間以及封包負載 大小(Packet Payload Size)。此外也加入可靠度和公帄性的考量，提高封包到達率 和降低延遲時間，藉由增加傳輸範圍和減少封包負載大小(Packet Payload Size) 可以幫助減低通道的負擔，以達到更佳的 QoS 等級。 2.3 QoS-Aware 一般在 MANET 的環境中討論 QoS 改善效能的重要性可以分為[11]： 服務等級指標(Service-Level Metric)[12]：包含延遲時間、Jitter 和生產量。因 為使用者最在意資料傳送的回應時間和準確度，所以降低延遲時間、提高生 產量，其次提供穩定的資料傳輸會是重要的考量。 資源相關指標(Resource-Related Metrics)[13]：針對行動裝置上的資源使用情 況討論 QoS 等級，可從 CPU Load、記憶體、頻寬及電力限制討論。 文獻[13]中為了滿足即時性應用與 QoS 的要求，路由協定會利用資源管理 [14]、動態排程[15]、依速度推斷和多路徑搜尋等技術來達成 QoS 的需求。其中 文獻[13]提出的即時性應用且具服務品質的單點傳播路由協定(Real-Time Unicast Mobile Ad-hoc Network；RUMAN)，是結合主動式和以位置為基礎(Location-Based) 的技術，節點之間會透過週期性廣播來交換節點資訊，藉由移動向量狀態資訊如 節點位置、移動速度和可配置的資源，以推斷鄰近節點目前狀態。為了隨時取得 鄰居節點的最新狀態資訊，會藉由多路徑偵測找尋最有效的路徑，並限制封包傳 送最多跳 2-Hop，避免廣播風暴問題。 在 車 載 環 境 為 擁 有 最 佳 的 服 務 品 質 ， 服 務 找 尋 協 定 (Service Discovery Protocol)在[16]被學者所提出，主要是希望提供 QoS 等級的服務。提出的協定首
6
先是找出合適車輛，保證服務供應者與服務請求者之間達到負載帄衡；其次，保 證服務供應者與服務請求者之間發生較低程度的壅塞情況，因此路邊基地台會被 考慮協助負載帄衡條件，最後透過 QoS-Aware 尋找協定找出一條路徑以滿足使 用者需求。
在車間通訊(Inter-Vehicle Communication；IVC)建立具有 QoS-Aware 路由機 制的路徑，[17]則是藉由加入路邊基地台的輔助以達到目標。並認為透過路由建 立(Route Construction)和避免壅塞(Congestion Avoidance)機制，可以防止 VANET 環境網路拓樸快速改變和壅塞所造成的鏈結斷裂情況。透過快速學習類神經網路 (Fast Learning Neural Networks；FLNNs)模式，作為鏈結斷裂和壅塞的指標，並 將該資訊夾帶於資料封包中透過週期性廣播傳送給鄰居節點或是路邊基地台。路 邊基地台另負責頻寬消耗評估，以避免因為換手造成的封包大量遺失。 2.4 Adaptive QoS 文獻[18]提出針對 QoS 適應性路邊基地台輔助路由機制，透過基地台資源預 測機制以有效分配基地台的資源。基地台路由演算法不僅讓鄰近基地台之間能共 享訊息，還負責將路段藉由基地台擁有的資源使用情況分成數個區段。當車間通 訊不會壅塞或所需頻寬較小時，車輛進入區段會直接與目前區段內的車輛之間傳 送資料封包請求；若需要較穩定的路徑，則會直接透過基地台尋找路徑。 為了防止鏈結錯誤或壅塞情況發生，[18]使用粒子群最佳化(Particle Swarm Optimization-Tuned)模糊邏輯系統，主要是調整方法中的帄均值和變異數。方法 中除了考慮兩車彼此距離及目前車速、位置，還提出壅塞指標參數，包括佇列長 度(Queue Length)、預期封包所需跳躍數及預期下段時間車輛數目。路邊基地台 負責頻寬消耗預測，其影響參數有目前車輛進入區段的頻寬、停在目前路段的車 輛頻寬及下段時間離開的車輛頻寬。
CHAMELEON[19]則是針對在 MANET 中多媒體資料傳輸改善延遲和 Jitter 的混合式路由協定。該方法是由網路節點數來決定採用主動式或被動式路由協定，
7 實驗結果顯示 CHAMELEON 的方法在網路節點數為 10 個以內除了有較低的 Jitter 外，也有較低的延遲時間；當節點數大於 10 個，雖然延遲時間比 AODV 略大，但 Jitter 還是呈現較低的結果。因此針對網路節點數較多情況下， CHAMELEON 亦能改善 QoS 多媒體資料傳輸的效能。 2.5 Link Lifetime
文獻[20]針對 MANET，提出鏈結終止時間(Link Expiration Time)的評估方 式，以找出鏈結存活時間最長的路徑，並以此方法和最短路徑演算法做比較。 [21] 提 出 用 於 VANET 環 境 ， 以 移 動 性 預 測 為 基 礎 的 路 由 (Movement Prediction-Based Routing；MOPR)觀念，作為挑選最穩定路由的機制。MOPR 是 考慮車輛的方向與移動速度，計算相鄰車輛的鏈結穩定度(Link Stability；LS)後， 挑選 LS 較大的鄰居節點，作為下一個傳送資料的對象，該研究認為相鄰車輛透 過這種方式將具有相對穩定的路徑。其中，假設節點 i 和節點 j 分別從目前位置 (Xi0,Yi0)、(Xj0,Yj0)隨著時間 Δt，分別以 Vxi及 Vxj移動到新位置(Xi1,Yi1)、(Xj1,Yj1)， 得到以下兩節點的距離公式[21] D12=(( Xi0+VxiΔt)-( Xj0+VxjΔt))2+(( Yi0+VyiΔt)-( Yj0+VyjΔt))2 (2.1) 隨著時間 Δt 經過，可以計算相鄰兩節點的 Link Lifetime[i,j]，並推導 LS 值[21] 為 LS[i,j]= (2.2) 此外在文獻[22]提及，為了確保路徑有最長路徑存活時間，主要建議挑選具 有最低延遲時間的路徑。Silent Alarm[22]提出的方法其環境初始條件和假設如 下：在筆直的高速公路且交通流量是無壅塞的情況，車輛皆安裝 GPS 衛星定位
8 系統，可以知道自身的移動方向、速度等位置資訊。並在高速公路旁架設存取點 (Access Point；AP)，其可能作為資料封包傳送的目的地。 假設來源節點有多條不同的連線路徑可以選擇，挑選路徑的方法是透過預測 路徑存活時間及封包資料傳送延遲時間來判斷。中繼節點預測延遲時間的方法為， 藉由來源節點傳送的 RREQ 封包進行延遲時間的比較。若封包序號存在，比較 RREQ 中的延遲時間；若封包序號不存在，儲存目前最大延遲時間，並廣播 Beacon 訊息給鄰居節點，若鄰居節點不存在，節點會將 Beacon 訊息快取直到找到鄰居 節點或 AP。而中繼節點預測路徑存活時間的方法為，藉由來源節點傳送 RREQ 封包進行路徑存活時間的比較。若封包序號存在，比較 RREQ 中的路徑存活時 間，保留路徑存活時間較長的 RREQ 封包；若封包序號不存在，儲存目前路徑 存活時間的值，並轉送 RREQ 封包給鄰居節點。 2.6 Bandwidth
在[23][24]中利用訊號強度(Received Signal Strength Indicator；RSSI)來表示 無線網路中傳送端與接收端之間的訊號強度。訊號強度為一個指數型態的公式， 藉由其值大小判斷傳送端與接收端之間的歐基里德距離和傳送端所發出的訊號 強度之間的關係。若傳送端與接收端之間距離小，則訊號強度大；若傳送端與接 收端之間距離大，則訊號強度小。傳送端所發出的訊號強度大小則會直接影響接 收端收到訊號強度的大小。傳送端與接收端的訊號強度表示方式如下[24]： ) ) ( ) ( log 10 ( 1 2 2 2 2 1 10 2 , 1 n x x y y A RSSI (2.3) 另外訊號強度對於可傳送資料頻寬的影響在[25]被提出，其使用技術是利用 訊號對干擾及雜訊比例(Signal-to-Interference plus Noise Ratio；SINR)估計資料傳 輸速率，並輔助行動裝置換手和電源控制，改善資料傳輸的生產量(Throughput)。
9
所謂訊號干擾雜訊比(Signal-to-Interference plus Noise Ratio；SINR)為接收端收到 有效訊號的強度與接收到干擾訊號（噪聲和干擾）的強度比值。為了提高 SINR 值，可提高訊號強度及降低干擾，使其能在一個 Subcarrier 用較高階調變訊號， 傳輸更多資料封包。 研究[25]並認為若是有較低的都普勒效應(Doppler Effect)影響，可達到較高 的資料生產量(Throughput)。因此提出可適應性機制(Adaptation Scheme)，透過 RSSI 值與通道品質之間的關係預測 SINR 值，提供最佳化預測過濾機制以改善 執行效能。 實際上，在[26]中，已經討論分別在兩台車輛安裝 DSRC(Dedicated Short Range Communications)系統硬體裝置，透過實際道路量測訊號強度並加入可視範 圍(Line of Sight；LOS)與非可視範圍(Non-Line of Sight；NLOS)的考量與封包到 達率之間的關係，其模擬環境分別有停車場、高速公路及郊區。方法中顯示隨著 兩車距離越遠，訊號強度有逐漸變弱的現象。另外，分別針對不同環境中可視範 圍及障礙物的限制，比較距離對封包到達率的影響，可視範圍內進行資料傳輸明 顯會有最佳的封包到達率，但是環境中的障礙物，例如車輛或是大樓、樹木等靜 止的障礙物，對於封包到達率則有明顯的影響。 2.7 相關方法評述 2.7.1 AODV[27]
AODV(Ad hoc On-Demand Distance Vector)路由協定，是目前廣泛被學者們 研究的一種被動式路由協定。被動式路由協定(Reactive Routing Protocol)是指當 來源節點要傳送資料封包時，才會啟動路徑搜尋(Route Discovery)的機制，而非 週期性的廣播路由請求(Route Request；RREQ)訊息。透過此種作法將有效的減 少網路頻寬的浪費及降低維護路由表的成本。然而，當來源節點有封包要傳送時， 必頇等待一段路徑尋找的時間並確定建立一條可到達目的節點的路徑後，才會進
10
行資料封包的傳送。所以這種類型的路由協定，大部分會利用最短路徑或最低延 遲時間做為挑選路徑的選擇。
在 AODV 中主要分為三個程序，分別是路由請求(Route Request；RREQ)、 路由回覆(Route Reply；RREP)及路由維護(Route Maintenance)程序。當來源節點 要傳送資料封包時，會啟動路徑搜尋機制。首先查詢自己的路由表(Routing Table) 是否有可到達目的節點的路徑資訊，若有存在可到達目的節點的路徑資訊，則來 源節點會將資料封包傳送至下一個可到達的目的節點；若路由表不存在可到達目 的節點的路徑資訊，則來源節點將會啟動路由請求程序。 來源節點透過廣播 Route Request(RREQ)訊息給傳輸範圍內的節點接收後， 節點會檢查廣播 ID 和來源節點編號，以避免收到來自同一節點所發出的路由請 求訊息。節點之間也會暫時紀錄 RREQ 資訊，當目的節點收到不同的 RREQ 時， 目的節點會選擇一條最短的路徑，並回傳 RREP。RREP 回傳時沿途經過的節點 也會紀錄該條路徑的相關資訊，當來源節點收到 RREP，表示路徑已經被建立起 來，可以開始傳送資料封包。
AODV 中路徑維護可分為兩種：其一為路由表(Routing Table)內的資訊維護 是指若當一條路徑在經過一段時間不再使用或更新，則節點會將該筆路由資訊從 路由表中移除。其二為路徑斷裂的處理機制，其中針對路徑斷裂的處理又可以分 成兩種情況討論，包括第一種情況是當路徑發生錯誤時，直接回傳 RERR(Route Error)給來源節點，RERR 經過的節點也會將發生錯誤的節點資訊由路由表中清 除。當 RERR 回到來源節點後，再由來源節點重新發送 RREQ 訊息來找尋可到 達目的節點的路徑。第二種情況是當路徑斷裂發生在比較靠近目的節點時，可由 斷裂處的節點採用 Local Repair 的方式直接發送 RREQ 訊息來尋找目的節點，若 目的節點能回應 RREP 給傳送 RREQ 的節點，表示斷裂的路徑可以修復，如此 資料封包就可以繼續傳送。
11
2.7.2 GPSR[28]
由 B. Karp 和 H. Kung 兩位學者所提出的 GPSR(Greedy Perimeter Stateless Routing) 又 稱 為 貪 婪 的 邊 緣 無 狀 態 路 由 協 定 ， 是 一 種 以 位 置 為 基 礎 的 (Position-Based)路由協定。因為 GPSR 中每個節點會週期性廣播 Beacon 訊息給 鄰居節點(Neighbor Node)，Beacon 包含節點 ID 及目前節點座標。在節點傳輸範 圍內，透過 Beacon 訊息的交換可得到的鄰居節點位置資訊，因此不需要維護路 由表，進而降低維護路由表的成本，這種做法就是無狀態(Stateless)路由的特性。 GPSR 主要是藉由兩種方式來轉送資料封包，分別為貪婪式轉送(Greedy Forwarding)及邊緣式轉送(Perimeter Forwarding)。Figure 2.1[28]說明是在一般的 情況下都可以使用，即是來源節點在傳輸範圍內會利用目的節點位置和周圍鄰居 節點位置來計算鄰居節點到目的節點的距離，再從中選擇與目的節點最靠近的鄰 居節點來幫忙轉送資料封包，不斷重複上述方式，直到找到目的節點為止。當來 源節點與目的節點的距離比鄰居節點到目的節點的距離來的近，或是來源節點傳 輸範圍內的節點離開等因素，導致無法使用 Greedy Forwarding 方式，這種情況 表示來源節點遭遇一個 Void 區域(Figure 2.2)[28]，而無法找到接手節點。此時 GPSR 將會採取 Perimeter Forwarding 來繼續幫忙轉送資料封包，這種方法又稱做 右手法則(The Right-Hand Rule)，如 Figure 2.3[28]節點 x 會接收由右邊節點 y 開 始以逆時針方式，尋找可幫忙轉送的節點之訊息。若幫忙轉送的節點可以使用 Greedy Forwarding 找尋到下一個可以幫忙轉送的節點，就回到 Greedy Forwarding 繼續尋找幫忙轉送的節點。
12
Figure 2.2：Void 區域[28] Figure 2.3：The Right-Hand Rule[28]
2.7.3 DGR[29]
方向性貪婪路由(Directional Greedy Routing；DGR)協定也是一種以位置為基 礎的(Position-Based)路由協定。一般會先假設車輛已安裝數位地圖和 GPS 來取得 目前車輛位置資訊。然而，DGR 不僅考慮車輛移動的位置，同時也考慮車輛移 動的方向性。
DGR 包含兩種轉送資料封包的方式，包括以位置優先的轉送(Position First Forwarding)方式及以方向為優先的轉送(Direction First Forwarding)方式。Position First Forwarding 是以位置為優先來選擇接手節點的方式，來源節點會挑選傳輸範 圍內離目的節點最近的節點作為接手節點(Next-Hop)，並利用地理貪婪式轉送 (Geographical Greedy Forwarding)演算法來找尋接手節點。藉由此種方法將可以 找到最少 Hop 數及端對端延遲時間(End-to-End Delay Time)最低的路徑。但可能
13
會遭遇路由迴圈(Routing Loop)的問題。如 Figure 2.4[29]所示，車輛 A 及車輛 B 分別往不同方向移動，車輛 B 已經在車輛 A 的傳輸範圍內，因為是使用 Position First Forwarding，所以當車輛 A 傳送資料封包時會選擇車輛 B 作為接手節點。 然而當車輛 B 接收到資料封包後要進行轉送時，又會將資料封包傳送給車輛 A， 因此產生路由迴圈的問題，導致在傳送封包時需要透過較多的 Hop 數才能將資 料傳送至目的節點，端對端延遲時間也將隨之上升。
Direction First Forwarding 是以方向性為優先來選擇接手節點的方式，來源節 點會挑選傳輸範圍內離目的節點最近而且是朝同方向移動的節點作為接手節點。 雖然這種方式可以避免路由迴圈，但可能會面臨頇要透過較多 Hop 數才能將資 料封包傳送至目的節點。如 Figure 2.5[29]中，車輛 A 和車輛 B 朝右方行駛，車 輛 C 則朝左方行駛，然而使用 Direction First Forwarding 方式時，車輛 A 要傳送 資料封包將挑選車輛 B 做為接手節點，而不會挑選車輛 C 做為接手節點，因此 也會需要透過較多的 Hop 數才能將資料傳送至目的節點，端對端延遲時間也將 隨之上升。 因此文獻[29]考慮上述兩種轉送資料封包的方式，針對位置及方向性進行取 捨，來獲得權重值 Wi，如式子(2.4)[29]所示。 (2.4) 其中，1-Di/Dc 表示來源節點和轉送節點與目的節點的距離比，此值小表示轉送 節點比來源節點較靠近目的節點，cos 值為來源節點的速度向量與來源節點到目 的節點的距離向量所求的向量夾角，α 與 β 則是權重係數。藉由調整此權重係數 可以對位置及方向性兩種轉送方式進行取捨，並讓來源節點挑選出權重值 Wi較 大的節點作為接手節點。
14
Figure 2.4：Routing Loop[29] Figure 2.5：The Direction First Forwarding Problem[29]
15
第三章 研究方法
VANET 應用包括改善道路安全及使用者舒適性等日漸受歡迎，但因 VANET 移動較高的特性，如何在拓樸快速變動的環境中傳遞資料，將大大影響 VANET 應用的可行性。然而，不同的應用有不同的 QoS 需求，如何為使用者找到一條 符合其 QoS 需求及當時網路連線狀況的路徑，是本研究的重點。 3.1 問題定義 從上一章的討論可得知，大部分文獻都只針對單一應用服務資料傳輸類型提 供 QoS 需求的應用服務，為了達到在車輛間不同的應用服務資料傳輸類型能有 最佳的連線品質，系統必頇依使用者的資料傳輸類型來挑選 Next-Hop 節點。所 以本文的方法將會強調如何尋找合適的接手(Next-Hop)節點。傳統換手方式會依 照各種不同路由協定直接挑選 Next-Hop 節點，而造成在高密度車載環境中面臨 頇要跳躍多個節點的情況。因此如何在鄰居節點通訊中斷前，從目前通訊範圍內， 根據所需應用服務類型挑選最佳的 Next-Hop 節點，提供高品質的傳輸服務，並 盡可能提高封包送達率、延長鏈結存活時間或降低端對端延遲時間，所以如何找 到穩定且高品質的 Next-Hop 節點將是要研究的議題。 評估 QoS 需求項目：在車載網路中，為了在不同的應用服務資料傳輸類型 能有最佳的連線品質，如何設計評估 QoS 需求的項目，以達到合適的接手 節點之要求，讓不同資料傳輸類型在傳輸時，盡可能增加通訊時間或增加頻 寬需求，使封包到達率增加、減少帄均延遲時間，並減少重新尋找接手節點 的次數，將是需要探討的議題。 尋找接手節點：如何在車載網路中車輛的高速移動和網路拓樸快速改變之特 性下，依目前網路連線狀態，找到合適的接手(Next-Hop)節點，不僅達到延 長通訊時間或獲得較多的頻寬，同時也可以減少控制訊息成本。16
3.2 研究目標
對於車載網路中車輛的高速移動和網路拓樸快速改變之特性下，針對不同 QoS 的要求並可依據當下網路連線狀態，應變地(Adaptively)調整最佳路徑的能 力。為了達成這些目標，要挑戰與解決的工作包括：
尋找接手節點 (Next-Hop Node Discovery)：為尋找可作為接手(Next-Hop) 的節點，藉由收到來自附近節點的 Hello 訊息，可了解鄰近節點的情況，當 來源節點有資料傳送時再送出 RREQ 以求建立可用的鏈結(Link)。
鏈結存活時間評估(Link Lifetime Evaluation)：依使用者提出不同應用類型 的資料傳輸需求，本文提出的方法會根據兩車之間位置資訊求得鏈結存活時 間(Link Lifetime)的評估，並作為計算權重值的評估項目之一，最後挑選出 權重值最大的節點，以作為接手節點。
可用頻寬評估(Available Bandwidth Evaluation)：有些應用服務需要較大頻 寬，在此本文認為 RSSI 訊號強度值與可傳輸頻寬及距離有關，若兩車輛距 離越近，將會有較佳的頻寬可使用。本文的方法會引用[23]計算兩車之間訊 號強度，並延伸其精神進而轉換成與距離之關係來呈現於模擬實驗中。因為 隨著兩車距離越遠，則訊號強度將變小，同時也推論封包到達率將明顯下 降。
可應變式接手節點挑選機制(Adaptive Next-Hop Selection Scheme)：本研究 認為最佳 Next-Hop 節點是可以根據使用者所需資料傳輸類型提供不同 QoS 需求的服務，藉由調整鏈結存活時間及頻寬後所得到的權重值，可以挑選合 適的接手節點，以提高封包傳送率，並減少重新尋找接手節點的次數，使控 制訊息降低。 因此，本研究將會先對鏈結存活時間及頻寬大小進行評估，接著再將鏈結存 活時間及頻寬分別乘上一個權重係數，以計算出權重值，再藉由來源節點挑選出 最佳的接手節點。透過本論文提出的挑選接手節點機制，預期可有效增加封包到 達率，減少控制訊息數量及帄均延遲時間，此外能依照不同 QoS 需求提高鏈結 存活時間或有更多的頻寬可使用。
17
3.3 系統架構
首先定義相關名詞(參見 Table 3.1)。本篇提出的系統模型分為都市道路系統 模型如 Figure 3.1(a)所示，及高速公路系統模型如 Figure 3.1(b)所示。當來源節點 (Source Node)要尋找接手節點繼續在網路中幫忙傳送資料時，會傳送路由請求訊 息(Route Request Message；RREQ)給傳輸範圍內的鄰居節點，鄰居節點接收到 RREQ 訊息後，一方面會判斷來源節點所使用的資料傳輸類型，並回傳包含位置 資訊的路由回覆訊息(Route Reply Message；RREP)，以供來源節點計算權重值， 另一方面也會繼續尋找範圍內具有最大權重值的鄰居節點做為接手節點。若由目 的節點(Destination Node)接收 RREQ，則會沿著最佳接手節點(如 Figure 3.1(a)中 節點 a、b 或 Figure 3.1(b)中節點 f、g)所組成的路徑回傳 RREP 訊息至來源節點。 來源節點接收到後，繼續利用此路徑傳送資料封包。本論文所提出的節點挑選機 制會依據不同的應用服務類型在不同系統模型下，考慮鏈結存活時間與頻寬之權 重取捨，以提供使用者可應變式的節點挑選機制。
在本文第四章中，將使用[33]設計的 Manhattan Mobility Model 及 Freeway Mobility Model，依序呈現車輛在都市街道中的移動方式以及車輛在高速公路的 移動方式，以分別模擬不同 VANET 環境下本論文研究方法的表現。
Table 3.1：Terminology Definition
Terminology Definition
Source Node 來源節點，產生 RREQ 訊息的節點。
Next-Hop Node 接手節點，幫忙繼續傳輸資料封包的節點。
Neighbor Node 鄰居節點，在來源節點通訊範圍內的節點。
Destination Node
18
Figure 3.1(a)：In Urban
Source Destination
f e
g
Figure 3.1(b)：In Freeway
3.3.1 訊息格式
19
RREP 與 Hello Message，依序介紹如下。
Route Request Message(RREQ)：來源節點在進行資料傳輸前所建立的訊息。 除了一般性欄位包括 Source、Destination、Sequence Number、Broadcast ID、 Hop Count 欄位外，本文另外設計了 QoS Type 欄位，其記錄來源節點要求 的 QoS 類型所需資料傳輸的應用服務，如 CBR 或 FTP。
Route Reply Message(RREP)：由目的節點或鄰居節點收到 RREQ 訊息後建 立的訊息。除了一般性欄位包括 Source、Destination、Sequence Number、 Hop Count 欄位外，本文另外設計了 QoS Type 欄位，其記錄來源節點要求 的 QoS 類型所需資料傳輸的應用服務，如 CBR 或 FTP。 Hello Message：每個節點會週期性廣播此訊息給周圍的節點，以通知周圍 節點目前該節點的位置資訊，以確保節點還有可通訊時間。本文設計的欄位 包括 Location Information 欄位，其紀錄目前節點的座標位置、方向及速度， 以供隨時更新路由表中的鏈結存活時間及頻寬。 3.3.2 路由表 VANET 環境中每個節點皆有路由表，本論文提出的方法採用 On-Demand 方 式，所以只有在節點有資料傳送請求時才藉由 RREQ、RREP 內的資訊建立路由 表，中間節點帄時不需要維護路由表。除了一般性欄位包括 Destination 與 Sequence Number 欄位外，本文另外設計了 Advertised Hop Count 和 Route List 欄 位，分別介紹如下。
Advertised Hop Count：新的路徑必頇大於目前在 Route List 中最大的 Hop Count 之值，以避免迴圈(Loop-Free)的產生。
Route List{Next-Hop Node, Link Lifetime, Bandwidth, Location Information }： 用來記錄不同路徑的 Next-Hop Node、Next-Hop Node 的 Link Lifetime 與 Bandwidth，以及記錄 Hello 訊息內的位置資訊，並利用位置資訊計算 Link
20
Lifetime 與 Bandwidth。
3.4 可應變式接手節點挑選機制
本研究方法會依使用者不同資料傳輸類型所需的 QoS 需求，來挑選最佳的 接手節點。部分文獻皆只有針對在 VANET 中的鏈結存活時間項目或是頻寬項目 或其他單一 QoS 項目作 QoS 需求的討論，然而往往忽略 QoS 項目彼此之間存在 著取捨問題，使 VANET 的技術應用不夠完整。因此本文提出的方法欲結合鏈結 存活時間(Link Lifetime)及頻寬(Bandwidth)來進行兩者之間的權重值計算，並從 中挑選權重值最大的節點作為接手節點。後面小節將先討論本文所使用的鏈結存 活時間和頻寬評估方式，接著再詳述本論文實際運作過程。 3.4.1 鏈結存活時間評估 在此評估的方法，除了使用方向及車速的考量外，加入兩車所夾角度來做為 鏈結存活時間(Link Lifetime)計算的參數[30]。首先，本文會先假設環境中節點均 配置 GPS 衛星定位系統，利用 GPS 節點可以知道目前車輛移動速度和方向。當 來源節點和鄰居節點進入彼此的傳輸範圍時，若有資料封包需要傳輸，藉由週期 性的 Hello 訊息或 RREP 訊息，可得知鄰居節點位置資訊，即可開始計算鏈結存 活時間。如 Figure 3.2，O1為車輛 P1的通訊範圍，車輛 P2為進入車輛 P1通訊範 圍，因此車輛 P2與車輛 P1的鏈結存活時間可表示為 t1,2，討論如下。 ) , (x1 y1 1 P 1 O 2 P ) , (x2 y2 1 2 Figure 3.2：車輛移動模型
21 Pi表示車輛，(xi,yj)為車輛座標位置，vi為車速，Ѳi為車輛行進方向與 X 座標所 夾角度，t 表示進入通訊範圍內可通訊的時間，R 為傳輸範圍。公式(3.1)為節點 P2與節點 P1的在彼此通訊範圍內所產生的圓方程式，式子(3.2)中 a 為展開圓方 程式後的帄方項，式子(3.3)中 b 為展開圓方程式後的一次項，式子(3.4)中 c 為展 開圓方程式後的常數項，最後藉由方程式將可計算出兩節點間之鏈結存活時間 t1,2， 如公式(3.5)。 舉例說明如下，假設節點座標 P1(10,20)、P2(30,50)，節點移動速度 v1=70km/hr、 v2=80km/hr，角度 Ѳ1=90°、Ѳ2=90°，R=0.25km 代入上式，最後求出兩節點之鏈結 存活時間 t1,2≒4.999 秒。 3.4.2 頻寬評估 對於需要較大頻寬的應用服務，在此本文認為 RSSI 訊號強度值與可傳輸頻 寬有關，若訊號強度較強，將會有較佳的頻寬可使用。本文的方法會引用[23]計 算兩車之間訊號強度與距離的關係來做頻寬的計算。隨著兩車距離越遠，則訊號 2 2 1 1 1 2 2 2 2 1 1 1 2 2 2 R )] sin ( ) sin [( )] cos ( ) cos [( t v y t v y t v x t v x
(3.1) 2 1 1 1 1 2 2 2 2 2 2 1 1 1 1 2 2 2 2 2 ) sin ( ) sin )( sin ( 2 ) sin ( ) cos ( ) cos )( cos ( 2 ) cos (
v v v v v v v v a (3.2) 1 1 1 2 2 1 1 1 2 2 2 2 1 1 1 2 2 1 1 1 2 2 2 2 sin 2 sin 2 sin 2 sin 2 cos 2 cos 2 cos 2 cos 2
v y v y v y v y v x v x v x v x b (3.3) 2 1 1 2 2 2 2 1 1 2 2 2 2x x x y 2y y y x c (3.4) a ac b b t 2 4 2 2 , 1 (3.5)22 強度將變小，同時也推論封包到達率將明顯下降。 如 Figure 3.2 所示，假設兩車輛座標為 P2(
x
2,y
2)與 P1(x
1,y
1)，先求兩車輛之 距離公式，如公式(3.6)，再代入 RSSI 公式，即可分別得到 P2與 P1的 RSSI 訊號 強度值 RSSI1,2，如公式(3.7)。 2 2 2 2 1 1 1 2 2 2 2 1 1 1 2 ,1 (x v cos t x v cos t) (y v sin t y v sin t)
d (3.6) ) log 10 ( 10 1,2 2 , 1 n d A RSSI (3.7) 其中 RSSI 的單位為 dbm，n 為訊號傳播常數或是信號傳播指數，此值會依據網 路特性而有所不同；di,j表示節點 i 與節點 j 的距離，A 表示在一公尺範圍內能接
收到傳送到的訊號強度。Received Signal Strength Indicator(RSSI)是一個以指數型 態呈現的訊號強度公式，主要是用於表示無線網路環境中，傳送端與接收端之間 的 訊 號 強 度 。 訊 號 強 度 的 大 小 是 指 傳 送 端 與 接 收 端 之 間 的 歐 基 里 德 距 離 (Euclidean Distance)與傳送端所發出的訊號強度之關係來評估其大小。傳送端與 接收端之間距離小的時候，訊號強度大；傳送端與接收端之間距離愈大時，則訊 號強度愈小。傳送端所發出的訊號強度大小則會直接影響到接收端收到訊號強度 的大小。 本文由[31]可推論訊號強度等於可用頻寬，因為本文提出的方法是假設節點 皆在同一網路特性環境下，所以本文不在此考慮公式(3.7)中的 n 值與 A 值。最後 認為頻寬與距離之間的關係，在本論文可以表示如公式(3.8)。 2 ) ( 1 Bandwidth 2 , 1 d (3.8) 針對頻寬評估在本論文中實驗模擬時，除了不同資料應用類型所需的 QoS 需求 不同外，頻寬評估與鏈結存活時間皆需要考慮到兩車之間距離影響，因此兩者之 間應該以權重方式來進行取捨。所以本文將在 4.3 節以實驗說明權重係數分配下 挑選合適的接手節點之係數選擇。
23 3.4.3 可應變式接手節點挑選 本文認為最佳 Next-Hop 節點會根據使用者所需資料傳輸類型提供 QoS 需求 的服務，考慮鏈結存活時間及頻寬的權重係數關係，以供不同的資料傳輸類型在 傳輸資料時能依不同 QoS 類型來挑選最佳的接手節點。 在本論文所使用的 QoS 類型是指資料傳輸類型若是即時性應用服務，則歸 類為 CBR 類型，如語音(Voice)、On-Line Game 等應用服務；若為非即時性應用 服務，則歸類為 FTP 類型，如 E-mail、檔案傳送之應用服務等。 當來源節點要傳送資料封包時，會依據資料類型，可能為即時性(Real-Time) 或非即時性(Non-Real-Time)應用服務，來尋找適當的接手節點。此外週期性的接 收 Hello Message，因此可得知鄰居節點的位置、速度和方向等資訊。來源節點 透過以上節點位置資訊，計算出鏈結存活時間與頻寬，再依據資料傳輸類型取得 計算出具最大權重值 wi的節點來作為接手節點，以利資料的繼續傳送，如 Figure 3.3 所示。 w1 a b c d
w
2w
3 Figure 3.3：選擇最佳 Next-Hop 節點 為了減少控制訊息成本，本論文是採用 Reactive(On-Demand)路由協定方式， 只有在來源節點有資料需要傳送時，才會開始尋找接手節點。此外，本文會先假 設每輛車皆已配置 GPS 衛星定位系統，讓每輛車可以記錄自己的移動方向及速 度等位置資訊。節點之間會週期性廣播 Hello 訊息，以更新路由表中的鏈結存活 時間、頻寬和位置資訊，並計算出權重值。讓來源節點可依據所使用的 QoS 類 型來挑選具有最大權重值的節點作為接手節點。權重值結果的計算是考慮了鏈結24
存活時間及頻寬兩種因素(請參閱 3.4.1 節、3.4.2 節)，所以本文將權重值的公式 呈現如公式(3.9)。
W = α*Link Lifetime + β*Bandwidth (3.9)
其中α+β=1。然而本文觀察頻寬評估方式最後會以級距呈現，而非一個絕對數值，
因此權重值計算後的結果會使鏈結存活時間之值恆大於頻寬之值，在 4.3.4 節實 驗模擬中本文將公式(3.9)表示為未正規化來呈現，結果顯示改善效果會近似於 DGR 路由協定。
因此本文使用正規化(Normalization)方法來調整 Link Lifetime 及頻寬計算， 以利權重值(W)結果的計算，如公式(3.10)。
W = α*(Link Lifetime/Max of Link Lifetime) + β*(Bandwidth/Max of
Bandwidth) (3.10) 公式中鏈結存活時間與頻寬之間不一定維持正比關係，因此要分別乘上一個權重 係數α 和 β，兩者的關係為 β=1-α，α 介於 0~1。若希望尋找接手節點是鏈結存活 時間較長的節點，則可以將α 調整較大些，例如：0.6~1 之間；反之，若對於頻 寬需求較明顯的節點，則將β 值調大一些。然而，VANET 環境的不同，權重係 數也會有所影響，為此在 4.3.1 節及 4.3.2 節中實驗模擬本文會針對兩種移動模型 分別實驗權重係數。
本方法尋找路徑方式的階段可分為：Hello 訊息廣播階段、Route Request、 Route Reply 及 Route Maintain 階段，依序介紹運作方式如下：
Hello 訊息廣播階段：節點之間帄時會廣播 Hello 訊息，以隨時更新位置資 訊，記錄節點鏈結存活時間與頻寬並計算出權重值。Figure 3.4(a)為來源節 點廣播 Hello 訊息狀態，所有鄰居節點收到 Hello 訊息後，會在路由表中記 錄節點 ID 和位置及速度資訊。Figure 3.4(b)為鄰居節點廣播 Hello 訊息狀態， 來源節點收到 Hello 訊息也會在路由表中記錄所有鄰居節點 ID 和位置資訊
25
及速度，計算鏈結存活時間及頻寬，並進行權重值計算。
Route Request 階段：本論文提出尋找接手節點的機制是當來源節點廣播路 由請求(RREQ)訊息給傳輸範圍內的鄰居節點後，若鄰居節點為目的節點則 接收 RREQ 訊息後直接回傳 RREP 訊息，來源節點收到 RREP 訊息後會計 算權重值。若接收 RREQ 訊息的鄰居節點為中間節點，中間節點會記錄來 源節點所需要的 QoS 類型，並回傳 RREP 訊息給來源節點，來源節點收到 RREP 訊息後再計算權重值。當鄰居節點收到 RREP 訊息會保留權重值最大 的節點作為接手節點，若鄰居節點權重值有更大者，則更新路由表。若傳輸 範圍內沒有鄰居節點存在，待轉送的資料封包就先儲存於來源節點。舉例如 下：當來源節點 S 要傳送資料封包時，會先廣播傳送路由請求(Route Request； RREQ)訊息，尋找有記錄到達目的節點之鄰居節點，RREQ 訊息中記錄來源 節點需要使用的 QoS 類型，以告知鄰居節點使用的資料傳輸類型，鄰居節 點收到後也會記錄於路由表中，並繼續傳送 RREQ 訊息，直到目的節點為 止，如 Figure 3.4(c)。
Route Reply 階段：接收 RREQ 的鄰居節點若是目的節點或是權重值最大的 節點，節點接收 RREQ 訊息後會記錄 QoS 類型於路由表中，並透過反向路 由(Reverse Route)回傳 RREP 訊息回來源節點。若鄰居節點還在傳輸範圍內， 則更新路由表。若鄰居節點離開來源節點的傳輸範圍，則丟棄 RREQ 封包。 RREP 的傳送過程中也會建立轉送路由(Forward Route)以供來源節點傳送資 料封包使用。舉例如下：接收 RREQ 的鄰居節點若是目的節點或是權重值 最大的節點，節點接收 RREQ 訊息後會記錄 QoS 類型於路由表中，並透過 反向路由(Reverse Route)回傳 RREP 訊息回來源節點。若鄰居節點還在傳輸 範圍內，則更新路由表。若鄰居節點離開來源節點的傳輸範圍，則丟棄 RREQ 封包。RREP 的傳送過程中也會建立轉送路由(Forward Route)以供來源節點 傳送資料封包使用。最後當來源節點收到來自鄰居節點的 RREP 後，會計算 權重值並挑選權重值最大的鄰居節點作為接手節點。當路徑中的接手節點皆 找到時，來源節點即可開使利用此路徑傳送資料封包，如 Figure 3.4(d)。 Route Maintain 階段：鄰居節點會週期性廣播 Hello 訊息，若正在通訊的來
26
由請求階段。
Figure 3.4(a)：Broadcast Hello Message Figure 3.4(b)：Received of Hello Message
Figure 3.4(c)：Send RREQ Message Figure 3.4(d)：Received of RREP Message
3.4.4 方法虛擬碼
上述提出方法的階段最後用 Pseudo-Code 表示如下：
Algorithm 1：Broadcast Hello Message Step
1: all node periodic send Hello_msg 2: update location information 3: call calculate Link_lifetime( ) 4: call calculate Bandwidth( )
Algorithm 2：Route Request Step
Notations:
locs：the location for source node
27
loci：the location for neighbors node
vn：the speed vector for neighbors node neighbori：the ith neighbor
D(s,i)：the distance between source node and neighbors node
NextHop：the node selected as Next-Hop
MaxWi：the maximum weight value of the neighbor node
1: //當來源節點有資料要傳送時
2: broadcast RREQ_msg for all neighbors node do 3: D(s,i) = distance(locs, loci)
4:
5: if D(s,i) <= 250 //表示鄰居節點在傳輸範圍內並判斷來源節點的 QoS type
6:
7: call calculate Weight_Value( ) 8:
9: return RREP_msg to Source_Node 10:
11: if Wi > MaxWi
12: W = Wi
13: NextHop = neighbori
14: if W of neighbor node> W of source node 15: update Route Table
16: end if 17: end if 18:
19: if the neighbors node are non-existent 20: carry the packet with Source_Node 21: end if
22: end if
Algorithm 3：Route Reply Step
1: if the Neighbor_Node is Destination_Node or have maximum W
2: received the RREQ_msg and record QoS type in routing table 3: generate RREP_msg return to Source Node
4: Neighbor_Node rebroadcast and if the node is within the transmission range 5: update Route Table
6: else
7: drop RREQ_msg 8: end if
Algorithm 4：Route Maintain Step
28
2: if no received the Hello_msg for Source_Node
3: return Algorithm 2 4: end if
Algorithm 5：Procedure Weight Value( )
Notations:
data_type：the transmission type for source node
1: if vs <= 50 and vn <= 50 //Manhattan Mobility Model
2: if data_type = CBR 3: call Link_lifetime( ) 4: call Bandwidth( ) 5: Wi =α*Link_lifetime +β*Bandwidth 6: end if 7: if data_type = FTP 8: call Link_lifetime( ) 9: call Bandwidth( ) 10: Wi =α*Link_lifetime +β*Bandwidth 11: end if 12: end if 13:
14: if vs > 50 and vn > 50 //Freeway Mobility Model 15: if data_type = CBR 16: call Link_lifetime( ) 17: call Bandwidth( ) 18: Wi =α*Link_lifetime +β*Bandwidth 19: end if 20: if data_type = FTP 21: call Link_lifetime( ) 22: call Bandwidth( ) 23: Wi =α*Link_lifetime +β*Bandwidth 24: end if 25: end if 3.5 路由協定之比較 本小節，將本論文提出方法與相關方法路由協定依序在路由協定類型、接手 節點挑選方式、週期性廣播的訊息、支援移動性的能力及合適的網路模式項目下 做比較，結果整理如 Table 3.2。
29
Table 3.2：Comparison of Routing Protocol Position-Based? Reactive? Next-Hop
Selection Periodically Broadcast Mobility Support Suitable Mode
AODV[27] Hop Count Hello Medium MANET
GPSR[28]
The Node Closest to Destination
Beacon Medium MANET
DGR[29] Combine Position and Direction
Beacon High VANET
Proposed Link Lifetime and Bandwidth
30
第四章 實驗模擬結果與分析
4.1 實驗環境與設定
本論文使用 NS-2 網路模擬器(Network Simulator Version 2；NS2)[32]作為模 擬環境。為了模擬 VANET 環境，本論文使用 Manhattan[33]及 Freeway[33]移動 模型。其中，Manhattan 移動模型中同樣假設車輛是隨機分佈在預設的地圖上， 並以網格狀的街道環境呈現，橫向與縱向各有四個路口，每個路口相距 250 公 尺，車輛行至路口會隨機決定是否要左轉、右轉或直行，左轉、右轉、直行的 機率各為 0.25、0.25 及 0.5，考量道路的限速，並設定車輛帄均速度設定從 10 到 50km/hr，使用 NAM[32]輸出的結果如 Figure 4.1。此外，Freeway 移動模型中 假設車輛隨機分布在預設的地圖上，地圖設定是一個類似高速公路的道路環境， 總共分為四線道，其中兩條是北上路線，另兩條為南下路線，長度為一公里。 考量高速公路的限速，本文設定車輛帄均速度設定從 70 到 110km/hr，使用 NAM[32]輸出的結果如 Figure 4.2。以下實驗之模擬參數如 Table 4.1。
Figure 4.1：Manhattan 移動模型(Mobility Model)[33] Figure 4.2 ： Freeway 移 動 模 型
(Mobility Model)[33]
31 Table 4.1 模擬參數 Parameter Value Simulation Time 200s Area Manhattan：1000m x 1000m Freeway：300m x 1000m Vehicle Speed Manhattan：10~50km/hr Freeway：70~110km/hr Vehicle Numbers 20~100 MAC Protocol 802.11 Bandwidth 2Mbps Transmission Rate 512kbps Transmission Type CBR、FTP Transmission Range 250m Session Numbers 5、10 4.2 效能評估項目 本小節會定義本研究方法效能表現之評估項目，並與其他現有路由協定進行 比較。為評估本論文提出方法的表現，定義的評估項目包括封包到達率(Packet Delivery Rate)、帄均延遲時間(Average End-to-End Delay Time)、控制訊息成本 (Signaling Overhead)，分別介紹如下：
封包到達率(Packet Delivery Rate)：為模擬過程中所有目的節點接收到的封 包總數除以來源節點送出的封包 總數。是指目的地節點所接收到的資料封包 數目，與來源節點所發送出之資料封包數目的比例，為判斷來源節點是否正 確無誤地將資料封包傳送到目的地節點的指標。比例愈高代表路由機制的效
32
能愈好，計算方式如式子(4.1)。
Packet Delivery Rate
(4.1)
帄均延遲時間(Average End-to-End Delay Time)：為模擬過程中所有來源節 點所產生的資料封包傳送到目的節點所花費的帄均時間。對於具即時性的應 用服務，需要考慮較低的端對端延遲時間。此值越低越好，計算方式如式子 (4.2)。
Average End-to-End Delay
(4.2)
控制訊息成本(Signaling Overhead)：所有路由控制封包的總數(包括 RREQ、 RREP、RERR 及 Hello 訊息)除以資料封包總數。是指由目的節點所接收的 每個資料封包帄均需要花費的路由控制封包個數。需要的路由控制封包愈多， 代表控制訊息的效率愈差，計算方式如式子(4.3)。 Signaling Overhead (4.3) 4.3 權重係數 α 的選擇 在本小節會先針對不同α 值在帄均封包到達率、帄均延遲時間及帄均控制訊 息評估項目來進行權重係數的挑選。又因為權重係數α 在不同移動模型及資料傳 輸類型皆會影響權重值的選擇，所以本文提出的方法之權重係數會分別在 Manhattan 和 Freeway Mobility Model 下進行模擬比較，以提供較佳的權重係數組 合。車輛行動模型如 4.1 節所述，每台車輛會在模擬環境中，隨機選取一個目的
33
地，以給定的帄均速度移動至該目的地，移動模式中節點會持續移動，直到模擬 結束。另外，會隨機選擇 5 個點對點連線(Session Numbers)，來分別進行固定速 率(Constant Bit Rate；CBR)和檔案傳輸協定(File Transfer Protocol；FTP)的資料傳 送表現，另一組實驗設定 10 組點對點連線的表現。 4.3.1 權重係數 α 在 Manhattan 移動模型之表現 因不同移動模型下權重係數也會有所影響，所以本文先以 Manhattan 移動模 型來呈現權重係數α 的選擇，模擬參數之設定部分如 Table 4.1。 4.3.1.1 權重係數 α 對帄均封包到達率的影響 A.實驗設計與目的 這組實驗主要的目的是量測帄均封包到達率在 Manhattan 移動模型中不同權 重係數下資料封包可正確送達成功的比例，而封包到達率越高表示能夠正確送達 的資料封包數量越多，所以此值越大越好。 B.實驗結果 在 Figure 4.3(a)中，可看出資料傳輸類型為 CBR 權重係數在 α=0，β=1 時， 效果會優於其他權重係數的分配情況，顯示 CBR 資料傳輸類型會需要頻寬較大 的接手節點，效果會比尋找鏈結存活時間較長的節點來的好。在 Figure 4.3(b)中， 是要觀察連線數增加到 10 對時在較高資料流量負載的表現，結果顯示 α=0，β=1 也是優於其他係數的表現；在 Figure 4.3(c)中，可看出資料傳輸類型為 FTP 權重 係數在α=1，β=0 時，效果會優於其他權重係數的分配情況，顯示 FTP 資料傳輸 類型更需要挑選鏈結存活時間較長的接手節點，以確保資料傳輸時的準確性。在 Figure 4.3(d)中，是要觀察連線數增加到 10 對時在較高資料流量負載的表現，結 果顯示α=1，β=0 也是優於其他係數的表現。
34
C.小結
對於在 Manhattan 移動模型中，若資料傳輸類型為 CBR 時，可選擇權重係
數α=0，β=1，以期求得較大頻寬之接手節點；若資料傳輸類型為 FTP 時，可選
擇權重係數α=1，β=0，以其取得較長通訊時間且封包到達率較高之接手節點。
Figure 4.3(a)：Average Packet Delivery Rate v.s
Number of Nodes(5 Sessions, CBR
Transmission Type)
Figure 4.3(b)：Average Packet Delivery Rate v.s Number of Nodes(10 Sessions, CBR Transmission Type)
Figure 4.3(c)：Average Packet Delivery Rate v.s
Number of Nodes(5 Sessions, FTP
Transmission Type)
Figure 4.3(d)：Average Packet Delivery Rate v.s Number of Nodes(10 Sessions, FTP Transmission Type) 4.3.1.2 權重係數 α 對帄均延遲時間的影響 A.實驗設計與目的 0 20 40 60 80 A ve rag e Pac ke t D e liv e ry R ate (% ) 1 0.8 0.6 0.4 0.2 0
![Figure 2.2：Void 區域[28] Figure 2.3：The Right-Hand Rule[28]](https://thumb-ap.123doks.com/thumbv2/9libinfo/7458721.111260/25.892.142.758.129.931/Figure22Void區域28Figure23TheRightHandRule28.webp)
![Figure 2.4：Routing Loop[29] Figure 2.5：The Direction First Forwarding Problem[29]](https://thumb-ap.123doks.com/thumbv2/9libinfo/7458721.111260/27.892.140.753.121.958/figure-routing-loop-figure-direction-forwarding-problem.webp)
