資料命名網路架構下之車載通訊緊急應用

全文

(1)國立臺灣師範大學資訊工程研究所碩士論文指導教授：. 賀耀華. 博士. 資料命名網路架構下之車載通訊緊急應用 Emergency Application for Vehicle-to-Vehicle Communication using Named Data Networking (eVNDN). 研究生：. 孫士傑. 中華民國. 104. 撰年. 8 月.

(2) 摘要命名中心網路(Named Data Networking, NDN)主要是以資料的名稱來命名而非現今網路的 IP 位址來進行資料的傳輸，他與現今封包格式最大的不同在於他所著重的地方是資料的名稱而非資料的位置。在車載網路(Vehicle Network)當中，訊息的流動大多都夾雜著像是車禍訊息及道路車流量..等，在這大量訊息流動的網路之中，使用者所考慮的內容幾乎是該訊息的名稱而非位置，這種特性也與命名中心網路的性質非常類似。在此篇論文當中，我們結合了命名中心網路與車載網路的網路架構，提出了一個能夠讓車與車間自主溝通的系統。在此系統中，訊息的名稱主要是以發送者 (車輛)的位置、預定興趣表(Pending Interest Table)中的興趣(Interest packet)為組成的主旨，讓周遭的接收者能夠迅速的判斷該訊息是否符合自身的需求並納入內容儲存庫(Content Store)之中。在此次的實驗之中，我們會去改變傳統命名中心網路的預定興趣表、內容儲存庫以及與上下層連接的介面，使其能夠符合在緊急情況下須要主動推播資訊的特性，發揮命名中心網路的功能迅速的讓周遭的車輛收到緊急訊息。依照不同類型的應用程式，生成的封包名稱也會有些許的不同，依據不同的需求，在 PIT 及 CS 做不同的事情，不管要發送或是接收任何類型的訊息，都能採取最有效的策略去進行。最後，透過我們的模擬及數據可以顯示出 eVNDN 擁有著 1) 對於各種緊急 i.

(3) 情形下更為優秀的訊息傳遞成功率 2) 更為廣闊的傳遞範圍 3) 比起傳統車載網路更為短暫的延遲時間，並利用這些實驗結果指出未來能夠改善以及研究發展的方向。關鍵字: 命名中心網路、車載隨意行動網路、802.11p/1609.3 網路. ii.

(4) ABSTRACT Unlike current network, Named Data Networking (NDN) focuses on “what” is the data instead of “where” is the data.. The major difference between NDN and. traditional packet network is that the routing is based is the name of the contents, not the location (i.e., IP address) of the content.. In vehicular network, warning message. usually included car accidents, road traffic flows, etc. When large amount of messages flow through the vehicular network, users only interest the content in the messages that are related to them.. Thus, this characteristic is very similar to the NDN.. In this thesis, we proposed a system called Emergency Application for Vehicle-to-Vehicle Communication using Named Data Networking (eVNDN).. This. enables vehicles to communicate based on the contents of the messages autonomously. In eVNDN, the name of the message is combined with the location of the senders (e.g., vehicles) and the interests of the Pending Interest Table (PIT).. This allows. nearby neighbor vehicles quickly determine whether these messages fit for their interest. If so, those messages will be included into the Content Store (CS).. In. eVNDN, we changed the PIT, CS, and both upper and bottom connecting interfaces of NDN.. This allows users (e.g., vehicles) automatically send and receive messages. related to emergency applications with the functions of NDN. In eVNDN, generated packet names are based on different emergency broadcast. iii.

(5) applications. According to different demands and applications, eVNDN will process the received packets differently (e.g., cache and drop) in PIT and CS.. Based on the. content in the packets that users (e.g., vehicles) send or receive, eVNDN will determine the optimal strategy. Finally, our experiments and simulation results to showed that eVNDN have 1) high successful delivery rate of messages for different kinds of emergency application; 2) longer range of the emergency messages can be sent and; 3) shorter delay for emergency messages in the vehicular network. With the experiment results, we showed that the eVNDN is able to improve the performance of the vehicular network for emergency applications. Key Words: Named Data Networking, Vehicular Networks, 802.11p/1609 networks. iv.

(6) 誌. 謝. 首先誠摯的感謝我的指導教授賀耀華博士以及同一間實驗室的陳伶志博士，兩位老師細心的指導與教誨使我在這兩年增進不少，不時的提攜以及指點我正確的方向，使我在這兩年之中受益良多。本論文的完成除了感謝兩位教授之外另外也得感謝國立臺灣師範大學資訊工程學系的全體師長，感謝你們這些日子以來的教導，使我能夠在該領域獲得相當的知識以及力量，因為你們的鼓勵與幫忙，使得本論文能夠更加的完整與嚴謹。兩年來的日子，實驗室裡的生活點滴與學術上的討論，使我能夠在這裡更佳的成長茁壯，感謝凱程、昱任、善合、辰叡學長們不厭其煩的指出我在研究上的缺失、且能不時在我迷惑時指點迷津，也感謝實驗室的競永、亘卓、泓褕、明宇同學們與我共同的成長，是你們讓我發展得更加出色，最後也謝謝嘉麟、俞翔、祥裕、宇融、展榮學弟以及慈郁、蕙欣學妹的協助，讓我的口試能夠順利完成。最後感謝我摯愛的雙親及女朋友，沒有你們在我身後鼓勵與支持，沒有你們的體諒與包容就無法成就現在的我，謝謝你們。. v.

(7) 目錄中文摘要英文摘要致謝目錄附表目錄附圖目錄. i iii v vi vii. 第一章簡介第二章相關研究探討第一節 Wireless Access in the Vehicular Environment……….. 第二節 Named Data Networking……………………………… 第三節 Application and use cases……………………………... 第四節 Virtual Router…………………………………………. 第三章系統架構第一節系統設計……………………………………..……….. 第二節封包命名結構……………………………………..….. 第三節 Background Service…………………………………… 第四節 Pending Interest Table……………………..………….. 第五節 Content Store……………………………………..…… 第六節 Application Scenario………..………………..……….. 第四章實驗結果第一節 Simulation Setting…………………………………….. 第二節 One hop broadcasting application…………………….. 第三節 Multi hop broadcasting application compared with Traditional and NDN………………………………….. 第四節 Multi hop broadcasting application………………….... 第五節 Intersection Warning broadcasting application……….. 第五章未來工作第六章結論參考著作. vi. viii 1 4 5 6 10 11 13 13 15 17 18 21 22 24 24 27 28 31 33 35 36 37.

(8) 附表目錄表 1 Packet’s name structure………………………….………………... 表 2 Pending Interest Table…………………………………………….. 表 3 實驗 1 設定……………………………………………………….. 表 4 實驗 2 設定……………………………………………………….. 表 5 實驗 3 設定………………………………………………………... vii. 17 19 24 25 25.

(9) 附圖目錄圖 2.1 The Protocol Stack of an IEEE 802.11p/1609 Network…………. 6 圖 2.2 命名中心網路簡單的網路拓樸………………………………… 8 圖 2.3 R1 的三個重要組件……………………………………………. 8 圖 2.4 Virtual Router...……………………………………………….. 12 圖 3.1 系統架構圖……………………………………………………… 13 圖 3.2 緊急訊息的接收與傳遞流程圖………………………………… 19 圖 3.3 One hop broadcasting application……………………………… 21 圖 3.4 Multi hop broadcasting application…………………………….. 22 圖 3.5 Intersection Warning broadcasting application………………… 22 圖 4.1 實驗 2,3 拓樸圖………………………………………………. 24 圖 4.2 實驗 2,3 車流量分佈………………………………………….. 25 圖 4.3 Throughput Result……………………………………………… 26 圖 4.4 Delay Time…………………………………………………....... 27 圖 4.5 模擬環境的原型………………………………………….......... 28 圖 4.6 CDF for Vehicles…………………………………………......... 29 圖 4.7 Error Cache…………………………………………………...... 29 圖 4.8 Success Rate…………………………………………………..... 31 圖 4.9 Hop Count…………………………………………………........ 32 圖 4.10 Intersection Warning Broadcasting………………………........ 33. viii.

(10) 第一章. 簡介. 現今社會發展迅速，人口越來越多，這也使得交通運輸工具的數量日益攀升，根據調查截至 2014 年底，中國的汽機車保有數量就多達 2.64 億台，其中汽車就佔有了 1.54 億台，那汽機車數量的攀升也成為了現在交通事故的主因。近年來智慧型運輸車輛都時常裝備著多種不同的無線通訊設備，像是 3G/LTE、 WiMAX、Wi-Fi 以及 802.11p(DSRC/WAVE) [2][3]。人們使用 Vehicle-to-Vehicle Communication (V2V)車間網路搭配 Vehicle-to-Infrastructure Communication (V2I) 車間通訊或車與公共設施通訊的方式上網也越來越普遍。但交通網路的環境相當的錯綜複雜，再加上車輛的快速移動導致車載網路的拓樸每分每秒持續的在改變。為了要有效的傳輸封包，我們需要解決像是路間基地台的轉換、封包轉換的延遲時間以及在高速移動情況封包傳輸率低落等這些 1609.3 [11]一直現存的問題。車載網路的出現給了智慧型運輸工具相當大的幫助，像是大大地增加封包傳輸的效率和成功率以及不同的情形下需要穩定的傳輸封包能力，例如: 車禍、塞車以及救護車行經路徑..等。為了要再增加車載網路普及化的可行性，我們必須要建立更加穩定、完善的網路系統，搭配現有的無線通訊設備去進行訊息的傳遞，並且盡可能的避免封包的遺失或是遞送封包給錯誤的目標增加網路的負擔。現今已有許多的車輛能夠連上網路，他們所使用的方式大多為透過蜂巢式網路，或透過路邊基地台的方式上網，這種方式已存在許久，但並未流行。車與車間的通訊又大多以短距離的緊急訊息傳輸為主，並且效率不佳，因此近年來許多 1.

(11) 的計畫發現，車載網路的系統必須要克服 TCP/IP 與生俱來的限制，才能夠讓車載網路更進一步的能使用在生活當中。雖然 IEEE 802.11p 已經定義了一種 ad-hoc mode 的網路存取方式去因應 broadcast message 載 TCP/IP 上所遇到的困難，但根據研究 [15][16] 這種網路由於封包的轉換格式繁瑣、在封包 size 較大的情況之下傳遞效率又很低落，並且有些路由方式又要配合 beacons，導致延遲時間過長，也因此在車間的緊急訊息傳遞並未是個太好的策略。有鑑於此，我們提出了一套將 Named Data Networking(NDN) 命名中心網路 [1] 運用在車載網路之上的系統，並盡力的去解決上述所提的種種問題。我們利用命名為主的封包去交換車間的訊息，他與 IP 為主的封包不同，他並不需要使用者或是接收者的位置，並且能透過它的命名讓接收者一目了然地知道發送者的目的。這一種封包所在意的重點並非是哪裡(Where)而是什麼(What)，命名中心網路是一種需求/回應形式的傳送機制，需求訊息為興趣封包(Interest Packet)，回應訊息為資料封包(Data Packet)。除此之外，我們也會去改變裡頭的架構，讓它能夠符合車間緊急訊息主動推播的特性，自動地去發送以及接送緊急訊息，好讓周遭車輛能夠第一時間得知。我們將命名中心網路系統除了安裝在車子上以外也會安裝在路邊基地台 (Road-Side Units)上，因為路邊基地台其實就是靜止不動的路由器在交通網路的環境之下。我們能夠透過路邊基地台去協助我們遞送及散佈訊息到特定的區域. 2.

(12) 或是接收者之上。本篇論文我們主要致力於在緊急情況之下的封包主動推播，利用命名網路的特性更有效的選擇最佳的無線通訊設備去推播資料封包，並透過該封包的格式去制訂幾種傳統車載網路所無法實現的程式。最後，透過 NS-3 網路模擬器，我們可以證明此系統優於傳統車載網路傳遞訊息方式，並且撰寫出多項傳統車載網路所不可行的程式，在未來可運用於無人車之上。概括上述多種論點，本篇論文所提供的貢獻如下: 1.. 我們加強並更新了傳統命名中心網路用於車載網路的系統，並可解決傳統車載網路於車對車的緊急情形下所產生的問題。. 2.. 我們證明了此系統確實比傳統方式有著更加優秀的效能及延遲時間。. 3.. 我們透過實驗證實了此論點並提供數據以及未來可改善的方向。. 3.

(13) 第二章. 相關研究探討. 自從 Wireless Access in Vehicular Environments (WAVE) Standard 問世以來，人們的議論不斷，其中，有一部份的研究就是著重於 TCP/UDP [18] 及 1609.3 [11] 由這兩種不同的封包格式來傳遞車載網路的訊息是否真的能有效的傳遞，不論是在都市或者是高速公路的情形之下，或者是研究如何利用這方面的技術使封包的發送者都可以享有較高而且穩定的傳輸功率。有一部分的研究則是著重在802.11p。這部份的研究偏向資料傳輸的效能以及 WAVE MAC的特性，其中還可以將封包依照形態分為Non IP based [11][12]與IP based [13]兩種。[13] 的研究內容是在802.11p 環境下測量封包的碰撞機率，傳輸 delay 以及throughput。[14] 的研究內容是改善WAVE MAC layer的protocol，使得在其上運作的application 可以達到更佳的封包傳送效率。[15]的研究內容是MAC layer 利用自己所設計的演算法有效率的將重要的安全性訊息broadcast 到整個網路。做的研究與 WAVE 有著相當大的關聯性，我們試著使用命名中心網路去替代掉 Network Layer 的 TCP/UDP 以及 1609.3 的傳統架構，並透過特殊的 forwarding 機制，使其能夠符合緊急訊息主動推播的特性，並且適當的運用在我們所提出的 Named Data Networking for vehicle networks，並提升了傳輸資料的效能與自由度。. 4.

(14) 2-1 Wireless Access in the Vehicular Environment IEEE 802.11p (又稱WAVE；Wireless Access in the Vehicular Environment) [2][3] 標準，是由IEEE 802.11 標準所擴充的通訊協定，這個通訊協定主要是使用在車用電子上的無線通訊系統。WAVE 是從IEEE 802.11 標準來擴充延伸，來符合智慧型運輸系統(ITS：Intelligent Transportation System)的相關應用，應用的層面包含高速率的車輛與車輛(Vehicular-to-Vehicular：V2V) 以及車輛與路邊基礎設施(Vehicular to Roadside Unit：V2R) 間封包的交換，其使用的波段為5.9 千兆赫(5.85-5.925 千兆赫)，而IEEE 1609 標準則是以IEEE 802.11p 通訊協定為基礎的高層標準。在 IEEE 801.11p/IEEE 1609 標準中詳細制定了WAVE device中protocol層面的溝通方式。IEEE 1609.0 定義的整個WAVE 系統的架構，參考圖2.1，它將整個WAVE 系統分成兩大塊，其中一塊是數據平面(Data Plane)，有WSMP (Wave Short Message Protocol)，WAVE MAC 以及WAVE PHY，另為一塊是管理平面(Management Plane)，主要由WME (WAVE management entity)所構成。. 5.

(15) 圖 2.1 The Protocol Stack of an IEEE 802.11p/1609 Network. 2-2. Named Data Networking. 近年來，各國的許多計畫都致力於推動資訊核心網路(Information Centric Networking) 的發展，像是資訊導向網路架構 (Data Oriented Network Architecture) [19]、資訊網路(Network of Information)以及命名中心網路 (Named Data Networking) [1] …等。命名中心網路是一個創新的網路架構始於 2010 年的 9 月，由國家科技基金會 (National Science Foundation)所提出，它利用它的特性以及常處去解決現有網路依靠 IP、點對點傳輸的架構所產生的問題，並且為一個更為自然的溝通方式。不同於以 IP 為主的封包，命名封包的訊息並不需要接收者的位置或是更詳細的資料，它可以再讓傳遞訊息的方式變得更有彈性、更有效率，在本篇論文當 6.

(16) 中，我們也會專注在命名中心網路以及相關的專案。如上所示，命名中心網路的封包分為兩種，分別是興趣封包 (Interest packet) 以及資料封包 (Data packet)，此外命名中心網路的主要結構也被三個最重要的組件環環相扣所組成，這些組件各司其職也囊括了像是傳遞訊息、路由、儲存.. 等各種功能，它們分別如下: . Forwarding Information Base (FIB) : 利用發送興趣封包朝向可能潛在資料的地方傳輸，而它是以命名前綴的方式路由，並提供不同的前綴不同的輸出介面，在每一個路由器的 FIB 內容也不為一致。它與傳統 IP 的 FIB 相當類似，但不同於傳統的 FIB，它所提供的輸出介面為一串名單而非單一輸出介面。. . Pending Interest Table (PIT) : 用來儲存所有傳遞出去尚未被滿足的資訊封包及其輸出的介面，持續的追蹤這些興趣封包所經過的路徑，使其得到資料封包時，能夠依照興趣封包傳遞的路徑回傳資訊。每一個 PIT 的項目都儲存一個興趣封包的名稱，往後當收到資料封包可以依照 PIT 裡面的項目知道該資料是否為自己所需。. . Content Store (CS) : 用來存放資料封包的臨時暫存器，它就與一般 IP 路由器的記憶體緩衝器相當類似，只是有著不一樣的替換策略，CS 裡面所儲存的資料主要是拿來滿足興趣封包的需求。. 7.

(17) 當需求者需要一個資料的時候，首先，它會先查看自己的 CS，若確定自己的 CS 並無此項資料的時候則透過它可使用的網路介面發送興趣封包，若有任何的使用者擁有該資料的話，則透過興趣封包傳遞的路徑回傳其資料封包，消費者收到資料封包的同時，會去確認名稱是否完全吻合，確認無誤則刪除 PIT 的該項欄位，表示該興趣已被滿足。. 圖 2.2. 命名中心網路簡單的網路拓樸. 圖 2.3 R1 的三個重要組件. 我們透過圖 2.2 一個簡單的網路拓樸去描述命名中心網路的三個組件是如何去運作，R1、R2 及 R3 為三個 NDN 的路由器，C1 與 C2 為兩個路邊基地台， V1 與 V2 則為兩個使用者(車輛)。圖 2.3 是 R1 的三個重要組件: Content Store、 Pending Interest Table 以及 Forwarding Information Base。若資料庫 DB 想要知道 C1 路間基地台周遭的交通資訊，則會送出名為 /NDN/Traffic Condition/Road_Data1/CD1 的興趣封包去取得資料，一開始會先確認自己的 CS 是否有符合的資料，若有該資料則將該資料直接傳給上層並滿足其需求，若無則會先確認 PIT 以前有無送過該興趣，有的話註記新的興趣來源並等. 8.

(18) 待該資料封包的回應，若無的話則在 PIT 增加該筆欄位並透過 FIB 將興趣封包傳遞給 R2，當 R2 收到興趣封包時也會先去確認他的 CS，若有資料則回傳資料封包，若無則去確認 PIT 是否傳遞過相同的興趣封包，若有則會透過傳遞該封包的介面去等待資料封包的回傳，若無則會在 PIT 上註記該筆興趣並透過 FIB 傳送興趣封包。在我們的範例當中，假設所有路由器及使用者的 CS 與 PIT 為空，興趣封包 I1 由資料庫所產生，並透過 FIB 所選擇的路徑 R2-R1-C1-V1 傳遞，當興趣封包抵達 V1 時，V1 會提供所需的資料封包並且透過相同路徑回傳給資料庫，當途中的路由器及使用者接收到資料封包時，會刪除 PIT 裡頭的該項欄位，並將它們放入自己的暫存器裡頭防止往後需要使用。將內容中心網路(Content Centric Networking) 運用在車載網路之上其實以前也有著一些相關的計畫進行過，像是 CRoWN [6]就提出運用 CCN 層來取代傳統車載網路的 TCP/IP 協議，放置在 WAVE Short Message Protocol (WAVE)層之中，在 CRoWN [6] 當中，車輛可以同時扮演著需求者或產生者兩種不同的角色，不同於我們上面所介紹的命名中心網路，它主要是利用塊標示、通知信息及內容提供表來儲存資料、發現提供者擁有的資料來進行傳輸並提高效率。 V-NDN [7]為第一個將命名中心網路運用在車載網路上的系統，它將傳統命名中心網路的三大組件 CS、PIT 及 FIB 移植到車載網路之上，但 FIB 與傳統 FIB 則有著些許的不同，傳統 FIB 主要是用來決定傳遞興趣封包到下一個節點的路徑， V-NDN 的 FIB 則是選擇較為適合的無線網路通訊介面當作傳遞的媒介。V-NDN. 9.

(19) 運用 L2 的 Wi-Fi 廣播當作車對車(Vehicle-to-Vehicle)的通訊方式，在車間通訊的實驗過程中，大概有 75%的封包再次傳遞次數不超過一次，這也證實了不同於傳統 IP 地址的方式，運用命名封包能夠在車載網路之中帶來更大的好處，雖然如此，未來還是有許多的困難要去克服，像是資料要如何去命名、安全問題、以及過多的興趣封包造成較大的網路負擔….等。我們這篇論文所要做的系統則是希望能夠讓命名網路運用在車載網路之上能夠順利的廣播緊急訊息，緊急訊息有別於一般訊息的傳遞，需要去主動的廣播而非需求/回饋的訊息發送，也因此需要較為特殊的系統機制去滿足它，在下一個章節我們將會介紹該系統是如何去設計並運用在各種實驗環境之下。. 2-3. Application and use cases. 根據 Vehicular Networking: A Survey and Tutorial on Requirements, Architectures, Challenges, Standards and Solutions [17]，車載網路程式的分類可以依據裝備、架構、特性、設定標準…等分類為下列三種:. 1. 道路安全 (Safety) 2. 交通管理與管制 (Intelligent Transportation) 3. 娛樂資訊 (Entertainment) . 道路安全方面的應用程式最主要的目的在於盡可能降低交通事故發生的比率及危害車輛的駕乘人員生命的事件發生，這類型的應用程式主要的用途在於能夠在第一時間提供自身訊息與其他的車輛進行溝通，並能夠在第一時間. 10.

(20) 取得其他車輛的緊急訊息，藉此去避免車禍產生。除此之外，也能與路間基地台進行溝通，交換交通狀況的訊息。像是車禍發生的提醒、方向燈提醒、緊急煞車提醒、道路狀況(打滑區、道路施工)的提醒….等都屬於該應用程式的範圍。 . 交通管理與管制應用程式用於增進交通環境上的流暢性，減少交通阻塞的情形發生及提供交通方面的協助等，像是提供周遭生活與交通資訊、或是各車道車流量上的提醒都屬於該應用程式範圍。. . 娛樂資訊方面的應用程式則是依據服務類型分為區域與全球兩種，區域提供的服務主要像是提供該地區的熱門景點、店家與娛樂資訊..等，屬於地區伺服器所提供的服務，全球提供的服務則是像一般電腦上網一般與各地的伺服器進行連結進而取的全球性的資訊。在第四章節，我們將會把焦點放在道路安全方面的應用程式之上，在我們的系統遇到緊急情形之下這些程式將會如何執行，包含封包如何遞送、與傳統方法的比較有何不同等，在第五章節則會透過模擬，讓大家知道此系統的優點及缺點、與其他方法的比較等，那在未來希望能透過這篇論文提供車載網路更好的發展環境。. 11.

(21) 2-4. Virtual Router. 根據 Routing Protocols for Inter-Vehicular Networks: A Comparative Study in High-Mobility and Large Obstacles Environments [9]，我們可以發現將地圖依照量尺大小分割成每一個區塊，並在線下進行位置的計算，得知使用者目前屬於該編號的 Virtual Router，並利用各個 Virtual Router 提供封包傳遞的來源、目的地以及傳遞路徑，如圖 2.4 所示，我們將地圖藉由設定的量尺規格切成多個區域，每一個區域皆為一個 Virtual Router，藍色點所在區域為 Source，綠色點所在區域為 Destination，紅色的多個區域則用來表示 Path，藉由該種方式提供傳遞資訊既不會浪費效能，又可以清楚地讓接收者得知傳遞資訊，實屬一舉兩得。而這種傳遞方式若利用在 Named Data Networking 之上，或許能將它的重要資訊直接使用在 Name Design 之中，讓 NDN Daemon 利用這些資訊進行封包的保留以及捨棄，這種方式或許能夠大大地減少不必要的封包傳遞以及效能的衰減。. 圖 2.4 Virtual Router 12.

(22) 第三章. 系統架構. 我們將此系統建設在 Ubuntu Linux 14.04 LTE 之上。該系統的架構圖如圖 3.1 所示:. 圖 3.1 系統架構圖. 3-1. 系統設計. Application: 上層的 NDN 車載應用程式，主要在產生需求時發送興趣封包以取得所需要的資料，或是當有資料產生將它們送往下層放置在 CS。在本篇論文當中我們設計三種不同的緊急應用程式，分別為踩緊急剎車、救護車路線提醒以及區域危險的提 13.

(23) 醒三種，以測試在不同的緊急情形之下，該系統的效率與傳統比較如何。. NDN Face: 用來與下層 NDN Daemon 進行連接的介面，用來幫助上下層進行封包的傳遞。 NDN Face 幫助上層不同 Application 的名稱註冊，並幫助上下層進行 Interest packet 與 Data packet 的傳遞。. NDN Daemon: 主要提供傳統 NDN 的主要三大元件，Content Store (CS)、Pending Interest Table (PIT)及 Forwarding Information Base (FIB)，並利用特殊的命名結構去決定封包的傳輸路徑及取捨等，該系統是預設在所有車輛都裝備著 802.11p DSRC 的無線通訊設備，並透過 Background Service 去給予 PIT 初始的興趣項目 Fixed Entry(Safety application 方面的興趣註冊)，提供需要主動傳播的資訊一個判定的標準，CS 除了與傳統 NDN 一樣暫存資料之外，也會因為緊急訊息有著主動推播的特性，採取特殊的行為，FIB 的話因為此篇論文重點是在使用 802.11p 廣播需要主動推播的資訊，所以在這邊 FIB 只有使用 802.11p 做 broadcast 一個選擇而已，因此傳遞封包的策略在此系統當中並不是亮點。. Network Face: 用來讓 NDN Daemon 與下層實體層無線通訊介面溝通的管道，通常是讓 FIB 進行 Network Face 的選擇，但在本篇論文當中主要是以 DSRC 為主軸進行傳輸的工作，所以網路介面的選擇只有一種。. 14.

(24) Location Service: 提供較高層級地理資訊上的一些協助，像是 GPS、數位地圖…等，並將這些資訊給予 Background Service 進行使用，這些資訊也會成為我們命名結構以及封包傳遞相當重要的一項數據。. Network Interface: 如緒論所說，目前車載網路都極力推薦每台車配置一個以上的無線通訊設備，像是 802.11p、802.11a 及 3G/4G 等，以對應不同的需求、不同的接收者，選擇最佳的傳遞途徑，但由於本篇論文主要致力於緊急訊息的傳遞，因此使用即使在高速移動之下，車間傳遞訊息能力還是極為穩定的 802.11p DSRC/WAVE 作為主要的網路通訊介面。. 3-2 封包命名結構由 Data naming in vehicle-to-vehicle communications [10] 我們可以得知封包名稱對於 NDN 的重要性，在加上車載網路當中，location 方面的資訊往往是對於資訊存取與否及傳遞路徑最為重要的指標，也因此我們設計了以下特殊的命名結構。封包名稱的範例為表 1，封包名稱由許多單字所組成，字與字之間由斜線隔開。 1.. Application name: 名稱階層的第二層，應用程式名稱可以讓我們迅速的判斷該程式的類別以及用途，藉此決定該封包接下來所需執行的動作。舉例來. 15.

(25) 說，在發生車禍後，必須主動推播該資訊給周遭車輛，讓其他車輛儘量避開該區域，而這時所產生的封包就是需要主動推播的封包，而非傳統 NDN 屬於需求/回饋的封包類型，並且其他車輛的 PIT 也可以藉由應用程式名稱，判定該主動推播的資料封包是否為自己所需要的資訊。 2.. Location: 名稱階層的三到六層，裡頭由許多位置的相關訊息所構成，封包路徑、封包來源、封包目的地及方向，透過位置的相關訊息可以讓途中的車輛知道該封包要如何傳遞，是否該丟棄等動作的執行，算是封包名稱最為重要的一環之一，那表示方式通常都是透過 Virtual Router 來標示。 . Path: 封包傳遞所想要經過的路徑，像是救護車傳遞封包通知前方車輛，就會在此路徑寫上他想通知的路徑。. 3.. . Source: 封包產生的位置，讓收到封包的車輛知道該封包的來源。. . Destination: 讓收到封包的車輛得知封包需要傳遞的方向。. . Direct: 產生的封包在甚麼方向的車道。 Timestamp: 該封包所可以存在的有效時間，為了避免增加負擔，每一個封包都有著有效時間，讓 CS 對於封包的去留有一個判定的標準。. 4.. Hop Count: 該封包可以傳遞的次數，一樣為一個封包傳遞的標準，該標準主要用於緊急訊息的傳遞，為了避免傳遞到不必要的節點，造成網路的負擔過大，所以才存在該標準，每傳遞一次封包就會做名稱改寫的動作，而該標準只運用於特定的應用程式名稱。. 16.

(26) 5.. Publisher Info: 產生該封包使用者的資訊，讓收到封包的車輛能夠了解該產生者的種種資訊，像是車牌號碼。. Interest NDN Application name Path Source Destination Direction Timestamp Hop Count Publisher Info. Data NDN Application name Path Source Destination Direction Timestamp Hop Count Publisher Info Data 表 1. Packet’s Name Structure. 3-3. Background Service. Background Service 用來初始使用者的 PIT，匯入需要主動推播應用程式的項目，讓它可以符合 NDN 的方式接受主動推播的資料，除此之外也會去持續的更新自己的地理位置資訊，地理位置相關資訊來源是 Location Service，藉由取得地理位置相關資訊，在 Offline 進行計算並轉換成 Virtual Router 提供給系統做使用。再來則是 Background Service 會紀錄 Content Store 當下暫存的每一個 data 的 name，Background Service 會定期的對這些 data name 進行掃描，依照 application type 以及 Virtual Router number，查看有沒有 data 是屬於需要 rebroadcast 的，若 17.

(27) 有則依照預設的 network face (for warning message)給 Content Store，藉由所預設的 Network face 進行 broadcast 的動作，使用這種方式既可以節省 application layer 重新發送 data 下來 broadcast 的時間，也可以節省查看 Pending Interest Table 所造成的 delay time，在 Vehicular Network 這種有許許多多 warning message 需要 rebroadcast 的環境當中，可以再讓效能更佳的提升。. 3-4. Pending Interest Table. 除了與傳統 NDN 相同，在收到上層或下層進來的 Interest Packet 時，首先，會先到 CS 裡頭確認是否有該項資料，若無則會到 PIT 確認之前是否有送過相同的 Interest Packet，若無該項 entry，新增該項 entry 並註記收到該封包的介面，並等待能滿足需求的 data 回覆，有的話則是依照他所進來的介面等待能滿足需求的 data 回覆。在我們的系統之中，除了這些基礎的功能之外，我們會在系統開機的時候，讓 Background Service 初始我們的 PIT，它會在我們的 PIT 中新增 Fixed Entry，也就是需要被主動推播的資料，像是踩煞車、救護車提醒等，這些屬於需要緊急推播的資料，Fixed Entry 除了有著永久存在、不會因收到相對應的 data 就刪除的特性之外，Fixed Entry 也會隨著位置的不同而改變，當使用者的 Virtual Router 改變的時候，Background Service 會通知 PIT，讓他們改變這些 Fixed Entry 的名稱，因為 Fixed Entry 只需要收到自己周遭位置的資料，這部份的 Entry 也因為 data 是屬於主動推播，所以並沒有相對應的 Interest packet 存在，並不會知道 18.

(28) data 詳細的命名情況，也因此這部分的 entry 採用命名部分符合的判斷，如 Table 2 所示，不同於傳統的 Entry 要命名全部符合才會認證。舉例來說，一開始 Background Service 初始 PIT ，新增了其中一項 /NDN/StepTheBrake/VR7 這一項 entry，StepTheBrake 是一個緊急煞車的應用程式名稱， VR7 則是你現在的位置，那當你收到從下層來的 Data ，名為 /NDN/StepTheBrake/VR7/VR7/Null/North/5/1/AB-1111/，就會因為前面三個階層的名稱有著與緊急訊息 entry 部分完全符合的地方，所以會將此 data 依照初始的項目送入相對應的介面，而該 entry 也不會被刪除，因為是緊急訊息的 entry，系統流程如圖 3.2 所示，此外詳細流程可以參照 Pseudocode 1。. Name. Interface. /NDN/StepTheBrake/VR7. 0,1. /NDN/Ambulance/VR7. 0,1. /NDN/Traffic Info/VR6,VR7,VR8/VR6/VR8/. 0,1. North/15/Null/ 表 2 Pending Interest Table. 19.

(29) 圖 3.2 緊急訊息的接收與傳遞流程圖 Pseudocode 1. PIT – Data Broadcast. /* PIT receive a Data 1: 2: 3: 4: 5:. */. Function PROCESS(Data) for all PitEntry in PIT.Lookup (Data.name) do if PitEntry.IsFixedSet then Transmit (PitEntry.incomings, Data) else if PitEntry.IsSet then. 6:. Transmit (PitEntry.incomings, Data). 7:. Pit.Entry.RemoveSeq (Data). 8:. Pit.Remove (PitEntry). 9:. else Drop (Data). 10:. end if. 11:. end for. 12:. end Function. 20.

(30) 3-5. Content Store. 在傳統的 NDN 之中，Content Store 主要就負責暫時儲存資料的工作。但是到了車載網路，每一個封包的名稱都是相當具有意義的，也因此在 Content Store，我們會依照 Background Service 給予的指令去執行不同的動作。舉例來說，當資料 /NDN/IntersectionWarning/VR7VR8VR9/VR7/Null/North/300/Null/AB-1111/ 來到 CS，Background Service 會依據它的應用程式名稱 Intersection Warning 判定它為需要持續主動推播的資料，並去檢查名稱階層第 3 項 path，看使用者目前的位置是否位於 path 之中，若是表示這個 packet 目前需要持續的繼續廣播，若為否，則不進行任何動作。不同的緊急應用程式封包也會有著不同的判斷基準，像是 Intersection Warning 的應用程式，就是在有效 timestamp 之內，每經過所設立的 broadcast time 就會判斷該封包是否需要 rebroadcast，藉由預設好的 Network face 直接進行 broadcast 的動作，不需要經過 PIT 再次判定，且由於 Network face 是事先預設好的，並不會多花時間去決定 physical interface 為何，讓需要多次不會造成時間上的延遲或是效能上的浪費。除此之外，Content Store 也還具有傳統 NDN 的功能，當封包的有效時間到期時，立即丟棄該封包，避免占用資源空間。每次從 Content Store 所主動推播的封包，都是屬於緊急訊息裡頭需要多次推播的，而每次推播的間隔時間我們希望是能夠有個標準，間隔時間太短，會造成許多車輛重覆性的收到封包，導致網路的負擔太大，間隔時間太長，則是會造成有些車. 21.

(31) 輛錯失這些封包，因此我們會藉由實驗 2 去證明間隔時間與車流量大小的負相關性，未來希望能有一個標準。. 3-5. Application Scenario. 在本章節，我們會將緊急訊息傳遞的應用程式，依照特性的不同分為三種，分別為 one-hop broadcast、multi-hop broadcast、intersection handling，對照不同的種類分別以一種應用程式介紹我們的系統如何運行。. 1. One-hop broadcasting application: 這類的緊急訊息屬於需要及時主動推播訊息給自身附近的車輛，而其推播範圍相當的小，像是踩緊急剎車、需要變換車道..等的應用程式，如圖 3.3 所示。. 2. Multi-hop broadcasting application: 這類的緊急訊息屬於須要通知周遭較大範圍的車輛一些及時的訊息，像是救護車的鳴笛通知、消防車的路線通知..等皆屬於該應用程式範圍之中，如圖 3.4 所示。. 3. Intersection Warning broadcasting application: 這類的緊急訊息屬於要維持住某個道路區域的危險訊息通知，像是發生車禍需要等待道路救援、道路臨時施工、道路結冰通知..等皆屬於該應用程式範圍之中，如圖 3.5 所示. 22.

(32) 圖 3.3. One hop broadcasting application. 圖 3.4 Multi hop broadcasting application. 圖 3.5 Intersection Warning broadcasting. 23.

(33) 第四章. 實驗結果. 在這一章節，我們會提供我們系統的實驗數據及與傳統架構的比較。本篇論文主要致力於緊急情形之下緊急訊息的傳遞，也因此提供三個不同種類的應用程式如 3-6 節所示，進行不同情形下的模擬，如 4-1。我們一開始會先測試傳統車載網路架構與使用 eVNDN 在不同的距離下進行封包上傳遞的比較，如 4-2，再來則是本系統與傳統 802.11p 在車載網路的環境之下使用 Multi hop broadcasting application 的效率比較以及對封包 cache 及 drop 的數量，如 4-3，此外我們也會對本系統進行 10 秒的短模擬，測是在 Multi hop broadcasting application 的傳遞情形，以及對 Hop count 的分析，如 4-4，最後則是進行 Intersection Warning Broadcasting 應用程式在不同的車流量，可以將封包維持住的時間，如 4-5。. 4-1. Simulation set up. 我們使用 ndnSIM [4]，一種 NS-3 為基底的 NDN 模擬器去模擬我們系統在各種實驗上的效能，在實驗環境方面則是利用 Simulation of Urban Mobility(SUMO) [5]去繪製並產生不同的車流量進行實驗。系統架設在 Ubuntu 14.04 LTE 的 Linux 作業系統之下，如圖 4.1 所示。. Mac and Physical Layer: 我們運用 NS-3 提供的 IEEE 802.11p WAVE 當作我們實驗的 wireless interface，無線通訊的範圍則是設為 150 meters。我們認為這個選擇能夠讓 V2V 的傳輸效能即使在高速無移動的情形之下依然能穩定的傳輸。 24.

(34) Mobility Model: 運用 SUMO [5] 產生出我們想要的交通模型，我們所使用的移動模型有兩種，分別為在直線同方向的高速公路，車間距離為 20,40,60,80,100 meters，測試車間傳遞緊急訊息的效率(One-hop broadcasting application)，如表３所示，另一移動模型則為在較大的模型之中，測試不同數量的車輛在 Multi-hop broadcasting 及 Intersection Warning broadcasting 的應用程式封包傳輸與接收的情況，如圖 4.1 圖 4.2 所示。. Parameter topology Number of Vehicle Wireless interface Transmission Range Vehicle Speed Mobility Model Packet Size Packet generate numbers Broadcast Interval. Value 100x 3000 meters 3 802.11p DSRC 150 meters 30 km/hr Run with one direction 300 bytes 10 1 second 表 3 實驗 1 設定. 圖 4.1 實驗 2,3 拓樸圖. 25.

(35) 圖 4.2 實驗 2,3 車流量分佈. Parameter topology Number of Vehicle Wireless interface Transmission Range Vehicle Speed Mobility Model Packet Size Packet generate numbers Broadcast Interval. Value 900 x 900 meters 50, 100 802.11p DSRC 150 meters 30 km/hr [20] 300 bytes 10 2 second 表 4 實驗 2 設定. Parameter topology Number of Vehicle Wireless interface Transmission Range Vehicle Speed Mobility Model Packet Size Packet generate numbers Broadcast Interval. Value 900 x 900 meters 10, 30, 50, 100, 200 802.11p DSRC 150 meters 30 km/hr [20] 300 bytes 10 5 second 表 5 實驗 3 設定 26.

(36) 4-2. One hop broadcasting application:. 在這個實驗當中，我們利用 100m x 3000m 的單向拓樸環境做 10 秒的模擬，由一車輛 (data provider)持續每秒丟出 10 個封包，封包的大小為 300 bytes，另外兩車輛 (data consumer)則都間隔著 data provider 依照設定的距離進行等速的車輛移動，表 3 為實驗設定。在此實驗當中，各項實驗組的速度都是 30km/h，並在每次模擬結束之後每次將距離拉長 20 metes 在繼續進行實驗，實驗周期為 10 次，將其實驗數據取平均值做為實驗結果，實驗數據為圖 4.3，在此圖我們可以清楚地看到 IEEE802.11p 的實驗數據明顯的優於 802.11a，並且在有使用 eVNDN 的情況之下，實驗數據又較為優秀，此外我們也有測試它們的 delay time，結果如圖 4.4 所示，雖然 IEEE802.11p 已經明顯了改善許多車間通訊的傳輸功率，但如前提所說，我們還是希望能改進它的 transmission delay，那使用 eVNDN 的部分大概讓 delay time 比傳統方法少上了一半左右。. 圖 4.3 Throughput Result. 27.

(37) 圖 4.4. 4-3. Delay Time. Multi hop broadcasting application. compared with traditional and NDN: 在該實驗中，我們利用 900m x 900m 的雙向拓樸如圖 4.1 所示做實驗模擬，設定如表 4 所示，圖 4.5 為拓樸的原型為復興南路、市民大道建國高架道路、忠孝東路及仁愛路所形成的小井號，為了讓模擬圖形較為簡單，好讓 Virtual Router 可以容易規劃，故自行繪畫成九宮格形狀，其車流量初始也是以真實的車流量比例分配，如圖 4.2 所示。在該實驗當中以車流量為 100 為基準比較傳統 802.11p 與 eVNDN 傳輸效率及 packet cache and drop 的比較，在該實驗當中車輛的移動速度為 30km/hr，移動的規則是模擬真實情形如 [20] 所示，並將此拓樸依照道路的不同分別從上到下、由左到右給定 VR1~VR24 不同編號的 Virtual Router，實驗方式為設定 20%的車輛為 Data Provider，剩下的車輛為 Data Consumer，在. 28.

(38) 模擬開始的時候 Provider 開始 broadcast 封包，並去觀察在模擬時間內所有車輛的接收情形，那最後再去分析哪些車輛 cache and drop 的情形，結果如圖 13、圖 14 所示。從圖 13 我們可以得知，在相同的 Wireless Network Interface 情形之下，eVNDN 的方法推播速度明顯高於傳統的方法，那這原因根據我們的分析與 4-2 節有關，此外在圖 4.7 我們可以清楚看到，對於 NDN 的方法來說，有良好的命名結構，在加上精準的位置資訊提供，在理論上可以達到 100%精準的 Packet Cache and Drop，但這只是理論上而已，因為在 Simulation 下，對於位置的經緯度資訊準確率高於 99 %。. 圖 4.5 模擬環境的原型 29.

(39) 圖 4.6 CDF for Vehicles. 圖 4.7 Cache and drop number. 30.

(40) 4-4. Multi hop broadcasting application:. 在該實驗中，我們利用 900m x 900m 的雙向拓樸如圖 4.1 所示做實驗模擬，圖 4.5 為拓樸的原型為復興南路、市民大道建國高架道路、忠孝東路及仁愛路所形成的小井號，為了讓模擬環境簡單化，使 Virtual Router 能夠容易規劃，故自行繪製成九宮格形狀，其車流量初始也是以真實的車流量比例分配，如圖 4.2 所示。在該實驗之中分別會有 10、30、50 三種不同族群的車輛的在該拓樸之中以 30km/hr 移動，移動的規則是模擬真實情形如 [20] 所示，並將此拓樸依照道路的不同分別從上到下、由左到右給定 VR1~VR24 不同編號的 Virtual Router，實驗方式為在一個節點安裝產生緊急訊息的應用程式當作 Data Provider，其他節點則是安裝接收緊急訊息的應用程式當作 Data Consumer，模擬的方式則是產生者會由 VR1 出發路線為 VR1VR2VR3VR7VR10VR9VR8VR11VR15VR16VR17VR21VR24VR23VR22 的順序移動，每當產生者到達 VR11 時會產生主動推播的資料進行 Flooding，去查看、計算 VR15、VR16、VR17 車輛的接收情況，實驗結果如圖 4.8 所示。封包名稱為: NDN/Ambulance/VR11VR15VR16VR17/VR11/VR15/South/10/5/AB-123，第二個實驗則是觀察每個 hop 的傳遞情形，測試以 hop 為傳遞基準的推播能力。並在實驗結束去查看三個區域車輛所收到的封包，實驗的結果如圖 4.9 所示。在第一個實驗當中我們可以得知，緊急訊息的推播與車流量成極大的正比，. 31.

(41) 並且在一次的主動推播當中，很難以到達 900 meters 的距離，這也證實了對於中長距離的訊息推播，必須要再有一定的車流量才具有效果，否則就需要藉由 Road-Side Units 的幫助，或是利用其他的 strategy 去推播該訊息。在第二個實驗當中我們則可以得知，車流量、距離對於 Hop count 的影響，在有著一定的車流量之下，我們可以發現 300 meters 的差距大約會影響 2 個 hop 左右的傳輸比率，而這也與我們的 transmission range 息息相關，在未來若能藉由其他方法得知 Service 所提供的當地車流量，或許能夠精確算出這次推播所需要傳遞的 Hop Count，並有效地減少推播數量以及 Network 的 Overhead。. Success Rate 1 0.9 0.8 0.7 0.6 0.5 0.4 0.3 0.2 0.1 0 VR15. VR16 Vehicle=10. Vehicle=30. VR17 Vehicle=50. 圖 4.8 Success Rate. 32.

(42) 圖 4.9 Hop Count. 4-5. Intersection Warning broadcasting application:. 在該實驗中，我們利用 900m x 900m 的雙向拓樸如圖 4.1 所示做實驗模擬，圖 4.5 為拓樸的原型為復興南路、市民大道建國高架道路、忠孝東路及仁愛路所形成的小井號，為了讓模擬圖形較為簡單，好讓 Virtual Router 可以容易規劃，故自行繪畫成九宮格形狀，其車流量初始也是以真實的車流量比例分配，如圖 4.2 所示。在該實驗之中分別會有 30、50、100 以及 200 四種不同族群的車輛如表 5 所示，在該拓樸之中以 30km/hr 移動，移動的規則是模擬真實情形如 [20] 所示，並將此拓樸依照道路的不同分別從上到下、由左到右給定 VR1~VR24 不同編號的 Virtual Router，實驗方式則是在該實境當中安排一車輛為 Provider，並 33.

(43) 當該車抵達 VR9、VR16、VR23 時停止下來並進行 10 秒鐘的封包 broadcast，之後分為依照三個不同的 Scenario (VR9、VR16、VR23)做不同車流量的實驗分析如圖 4.10 所示，看該封包可以維持的秒數為何。該次實驗的封包名稱為: NDN/Ambulance/VR8VR9VR10/VR9/Null/South/300/Null/AB-124 NDN/Ambulance/VR15VR16VR17/VR16/Null/South/300/Null/AB-124 NDN/Ambulance/VR22VR23VR24/VR23/Null/South/300/Null/AB-124 由實驗結果可以清楚得知，在尖峰時期的車流量已經可以讓該訊息維持至少 200 seconds 以上，並藉由 eVNDN 讓我們知道，將 NDN 運用在 VANET 上能夠產生許許多多以往的車載網路所無法有效利用的應用程式，而這也為車載網路的歷史先開了嶄新的一頁。. 圖 4.10 Intersection Warning Broadcasting. 34.

(44) 第五章 . 未來工作. 進行真實環境的 emulation，因為在 simulation 方面，對於各個車輛的經緯度資料準確率為 99%，但在真實情形，使用 GPS 所截取的位置資訊通常都會有著一定的誤差，因此需要進行真實環境的實驗並去找出這對 packet cache and drop 準確率的影響。. . 在加入其他的 Network Interface，像是 802.11a，進行多種不同性質應用程式的實驗，像是 Safety application 與 Entertainment application 訊息同時地傳遞，並透過不同的 Network Interface 去測量同時間大量不同類型封包傳遞對 Network Overhead 的影響。. 在本篇論文中我們所分析的 Scenario 都是屬於 Safety 方面的application，如果能在對不同方面的application 模擬資料的傳輸，並且可以完美的分析所有可能造成throughput 下降的原因，我們還可以更加完善 Named Data Networking for Vehicle Networks的設計。. 35.

(45) 第六章. 結論. 在 802.11p standard 所定義的WAVE ad-hoc network 之中我們看到它的一些缺點。雖然WAVE ad-hoc network 不用同於以往IP based的傳遞方式，不需要 Receiver的位置資訊就可以直接傳輸資料，但是從一些Survey當中我們可以發現，他封包轉換的過程有點冗長，在加上它無法有效地判斷對於broadcasting packet 準確地接收與丟棄，它僅僅能依照application的type進行接收的動作。因此我們使用了 Named Data Networking 改善了WAVE ad-hoc network 種種的缺點。為了要讓 eVNDN 能夠主動地推播緊急訊息，為此我們去改動了 Pending Interest Table以及 Content Store的設計，並利用 Background Service以及特殊的命名結構去完整的維持住整個系統的運作，最後也透過實驗證實了該系統的可行性以及在對於緊急訊息上建立良好的傳遞途徑。最後結果不但表示了我們想法的可行，也為 Named Data Networking for VANET 找到了一個新的研究方向。. 36.

(46) 參考著作 [1]. Named data networking. http://named-data.net.. [2]. The IEEE 802.11 Working Group of the IEEE 802 Committee, “Draft. P802.11p/D3.0,” July 2007. [3]. “IEEE Std 802.11-2007 (Revision of IEEE Std 802.11-1999),” June 12,. 2007. [4]. A. Afanasyev, I. Moiseenko and L. Zhang, “ndnSIM: NDN simulator for. NS-3. Technical Report NDN-0005,” NDN Project, July 2012. [5]. D. Krajzewicz, J. Erdmann, M. Behrisch and L. Bieker, “Recent. development and applications of SUMO - Simulation of Urban Mobility,” International Journal On Advances in Systems and Measurements, December 2012, 5(3&4):128–138. [6]. Marica Amadeo, Claudia Campolo, and Antonella Molinaro, “CRoWN:. Content-Centric Networking in Vehicular Ad Hoc Networks,” IEEE Communications Letters, 16(9):1380-1383 (2012). [7]. Giulio Grassi, Davide Pesavento, Giovanni Pau, Rama Vuyyuru, Ryuji. Wakikawa and Lixia Zhang, “VANET via Named Data Networking,” IEEE INFOCOM Workshop on Name Oriented Mobility (NOM), Toronto, Canada, April-May 2014. [8]. V. Jacobson et al. “Networking named content,” In Proc. of CoNEXT, 2009.. [9]. Yao H. Ho, “Routing Protocols for Inter-Vehicular Networks: A. Comparative Study in High-Mobility and Large Obstacles Environments,” 37.

(47) Computer Communications Journal (ComCom), Elsevier, volume 31, number 12, pp.2767 – 2780. July, 2008 [10]. L. Wang, R. Wakikawa, R. Kuntz, R. Vuyyuru, and L. Zhang, “Data naming. in vehicle-to-vehicle communications,” In Proceedings of INFOCOM Workshop on Emerging Design Choices in Name-Oriented Networking (NOMEN 2012), 2013. [11]. “IEEE 1609.3 Trial-Use Standard for Wireless Accesses in Vehicular. Environments (WAVE) - Networking Services,” IEEE Vehicular Technology Society, October 2006. [12]. S. Eichler, “Performance Evaluation of the IEEE 802.11p WAVE. Communication Standard,” Vehicular Technology Conference, VTC-2007 Fall, 2007 IEEE 66th, pp.2199-2203, Sept. 30 2007-Oct. 3 2007. [13]. Yunpeng Zang, L. Stibor, B. Walke, H.-J. Reumerman and A. Barroso, “A. Novel MAC Protocol for Throughput Sensitive Applications in Vehicular Environments,” Vehicular Technology Conference, VTC2007-Spring, IEEE 65th, pp.2580-2584, 22-25 April 2007. [14]. M.M.I. Taha and Y.M.Y. Hasan, “A Novel Headway-Based. Vehicle-to-Vehicle Multi-Mode Broadcasting Protocol,” Vehicular Technology Conference, VTC 2008-Fall, IEEE 68th, pp.1-5, 21-24 Sept. 2008.. 38.

(48) [15]. Farhan H. Mirani, Anthony Busson and Cedric Adjih, “Improving. Delay-Based Data Dissemination Protocol in VANETs with Network Coding,” REV Journal on Electronics and Communications, Vol. 2, No. 3–4, July – December, 2012. [16]. L. A. HASSNAWI, R.B. AHMAD, MUATAZ H. SALIH,M.N. MOHD. WARIP,M.ELSHAIKH, “MEASUREMENT STUDY ON PACKET SIZE AND PACKET RATE EFFECTS OVER VEHICULAR AD HOC NETWORK PERFORMANCE”, Journal of Theoretical and Applied Information Technology, Vol.70 No.3, 31st December 2014. [17]. Georgios Karagiannis, Onur Altintas, Eylem Ekici, Geert Heijenk, Boangoat. Jarupan, Kenneth Lin and Timothy Weil, “Vehicular Networking: A Survey and Tutorial on Requirements, Architectures, Challenges, Standards and Solutions,” IEEE COMMUNICATIONS SURVEYS & TUTORIALS, ACCEPTED FOR PUBLICATION, 2011. [18]. Shie-Yuan Wang, Hsi-Lu Chao, Kuang-Che Liu, Ting-Wei He, Chih-Che. Lin and Chih-Liang Chou, “Evaluating and improving the TCP/UDP performances of IEEE 802.11(p)/1609 networks,” Computers and Communications, 2008. ISCC 2008. IEEE Symposium, July 2008. [19]. Teemu Koponen, Mohit Chawla, Byung-Gon Chun, Andrey Ermolinskiy,. Kye Hyun Kim, Scott Shenker and Ion Stoica, “A Data-Oriented (and Beyond) 39.

(49) Network Architecture,” SIGCOMM’07, August 27–31, 2007. [20]. 焦元輝, “GIS 輔助車流量分析之研究─以台北市為例,”. http://140.112.65.130/Chinese/Education/eGIS/bb/paper_pdf/01.pdf.. 40.

(50)