行政院國家科學委員會專題研究計畫 成果報告
以安全,節能及遊憩為目的之車載網路系統--子計畫四：車
載通訊網路繞徑技術(3/3)
研究成果報告(完整版)
計 畫 類 別 ： 整合型 計 畫 編 號 ： NSC 100-2219-E-009-003- 執 行 期 間 ： 100 年 08 月 01 日至 101 年 07 月 31 日 執 行 單 位 ： 國立交通大學資訊工程學系（所） 計 畫 主 持 人 ： 陳健 計畫參與人員： 碩士班研究生-兼任助理人員：楊文翔 碩士班研究生-兼任助理人員：劉郁鈞 博士班研究生-兼任助理人員：陳盈羽 博士班研究生-兼任助理人員：陳坤定 博士班研究生-兼任助理人員：張哲維 報 告 附 件 ： 出席國際會議研究心得報告及發表論文 公 開 資 訊 ： 本計畫可公開查詢中 華 民 國 101 年 10 月 31 日
中 文 摘 要 ： 近年來，由於其潛在的用路安全以及商業應用，車載通訊網 路已成為相當熱門的研究對象。 目前許多的研究以及真實應用都還侷限於單躍(one-hop)或者 少數 hop 以內的通訊，然而， 多躍(multi-hop)的傳送方式亦是具備相當的重要性。例如， 駕駛者可能在路途中欲預先 得知目的地附近的停車位數，或者向某餐廳預約訂位，這些 應都可以藉由 multi-hop 的傳 送方式將封包送至目的地。 利用車際網路上的車間通訊開發的各種應用，可以幫助人 們生活更加便利且安全。這些 應用要得以實現，都需要依靠路由機制讓資料可以在兩車輛 間順利傳送。在路由機制的設計 上，先前已經有很多研究出現，各種選擇最佳路徑時的考慮 因素，如道路上的車子數量，道 路長度等都已被提出。本文提出一個利用即時交通資訊的路 由協定，藉由路段上位於路口的 車輛發動探測封包，經由路段上的車輛攜帶和傳送到達同一 路段上的另一路口，由此測量得 到各條路段上最新的封包傳送延遲時間，並且考慮車輛在道 路路口轉彎時會集中，車輛數較 多的特性，在不加入額外路邊單元的情況下，設計機制將收 集到的延遲時間資訊暫時儲存在 路口範圍內，同時嘗試將此資訊擴散到鄰近路口並暫存。當 封包經由車輛轉傳到路口，需要 對下一個即將轉傳的路段作優先權計算時，便可得到此資 訊，在沒有得到即時延遲資訊的路 段，因為車輛上有預先紀錄的歷史交通資料(車輛數，道路速 限)，車輛可以依據其他研究中 的算式估算各路段的傳輸延遲時間，混合有即時延遲時間資 訊路段的和經由歷史資料計算出 延遲的路段，得到最短延遲時間的路徑。進一步考慮更新即 時交通資訊所帶來的大量網路負 擔，我們研究各個路段的連通性，先判斷路段是否為接近連 通，也就是使用無線傳輸可以快 速傳送資料經過此路段，中途不會傳輸中斷而需要由車輛攜 帶，這些路段對傳送延遲時間的 影響較大，此時才針對這些路段進行即時資訊更新的動作， 藉以減少網路負擔量同時增進傳 輸延遲時間。連通性的考慮方法為利用車輛在行駛的特性， 當車輛自由行駛時，道路上車輛
的分佈呈現指數分佈。道路上每隔一段長度內有車輛的機率 可以用道路上的車密度得到。於 是只要在傳輸範圍內存在有一台以上車輛出現的機率極高 時，便代表可以往前傳送。連續數 個傳輸範圍內都有車輛可以幫忙轉傳，這些傳輸的總長度大 於道路長度時，道路接近於完全 連通。但考慮車輛在道路上的分佈並非均勻且實際每次往前 轉傳時跳躍距離不等於傳輸範圍 ，必須針對轉傳時跳躍的長度做計算，最後以連續數個期望 跳躍距離內皆有車輛的機率當作 連通機率，可得出車輛密度和連通機率的關係。 透過模擬比較和其他路由協定的傳輸延遲時間，傳輸成功率 和協定本身對網路造成的負擔。在正常交通情況下結果略 好，但當交通情況出現和統計資料有重大差異時，本協定可 以增進封包傳輸的延遲時間。 在實作方面，我們並設計了離線電子地圖與地理資訊資料 庫，以提供使用 者發出請求的介面。在資料傳輸的部份則與工研院合作，使 用其 IWCU 作為實 作平台 (Implementation)。在應用程式方面以使用者請求各 路口影像畫面
為主要目標，我們利用了車機 (On Board Unit)來時做電子 地圖，並利用 電子地圖來收集及分享地理資訊。並且，我們也設計了循環 錄影的功能，以防 止存取空間不足的問題，實作的環境為 ASUS EeePad 與 ITRI 的 IWCU。依 據我們的設計，則使用者可以透過車用行動通訊網路取得各 路口或是有各輛車 所見的即時影像，對於追蹤及監視都有莫大幫助。 中文關鍵詞： 車載通訊網路、多躍、繞徑、即時交通資訊、道路連通性， 資料探勘，多媒體資料 英 文 摘 要 ：
Recently, due to its potential road safety
applications and commercial applications, vehicular ad-hoc networks (VANETs) have drawn a great amount of research attention. Currently, most of the research and real applications are limited to communication within only one-hop or a few hops away. However, it is also important to send data to a remote
destination using a multi-hop manner. For example, a driver may need to send a query to the parking lot for the available parking space, or a reservation message to the destined restarrant. Applications like these may send packets to their destinations via the multi-hop transmission manner.
Vehicles on intersections were triggered to send connectivity packets to vehicles on adjacent
intersections conditionally. These packets traverse road segments by two ways, forwarding and carrying, and then we can measure latest road delivery delay. We consider the feature that vehicles slow down and gather on intersection, so the number of cars is more. We try to design a mechanism to store delay information on intersection area without Road side unit. Meanwhile, we will disseminate it to cars on neighbor intersections and store on them in the same way.
In the implementation, we adopted on board unit (OBU) designed by ITRI. Moreover, the main feature of the application is letting drivers query videos captured at roads intersection. User Interface is implemented with ASUS EeePad and off-line digital map. The
digital map is not only used for display geographic information but also for information collection. Furthermore, circular recording scheme has been
designed in order to overcome the issue occurred with limited storage. With the design, drivers can get geographical information including real-time capturing videos.
英文關鍵詞： Terms-VANET, Intersection-based routing, Real-time information, Road connectivity, VANET, multi-hop, routing, metadata, multimedia
行政院國家科學委員會補助專題研究計畫
■ 成 果 報 告
□期中進度報告
以安全，節能及遊憩為目的之車載網路系統
-子計畫四：車載通訊網路繞徑技術
計畫類別：□個別型計畫
■整合型計畫
計畫編號：NSC 100－2219 －E －009－003
－
執行期間： 98 年 08 月 01 日至 101 年 07 月 31 日
執行機構及系所：國立交通大學資訊工程學系
計畫主持人：陳健
共同主持人：張適宇、簡榮宏
計畫參與人員：陳盈羽、汪岱錡、蔡世仁、劉郁均、魏伯庭
成果報告類型(依經費核定清單規定繳交)：□精簡報告
■完整報告
本計畫除繳交成果報告外，另須繳交以下出國心得報告：
□赴國外出差或研習心得報告
□赴大陸地區出差或研習心得報告
■出席國際學術會議心得報告
□國際合作研究計畫國外研究報告
處理方式：
除列管計畫及下列情形者外，得立即公開查詢
□涉及專利或其他智慧財產權，□一年■二年後可公開查詢
中
華
民
國 101
年 10
月
29 日
中文摘要 近年來，由於其潛在的用路安全以及商業應用，車載通訊網路已成為相當熱門的研究 對象。目前許多的研究以及真實應用都還侷限於單躍(one-hop)或者少數 hop 以內的通訊， 然而，多躍(multi-hop)的傳送方式亦是具備相當的重要性。例如，駕駛者可能在路途中欲預 先得知目的地附近的停車位數，或者向某餐廳預約訂位，這些應都可以藉由 multi-hop 的傳 送方式將封包送至目的地。。 利用車際網路上的車間通訊開發的各種應用，可以幫助人們生活更加便利且安全。這 些應用要得以實現，都需要依靠路由機制讓資料可以在兩車輛間順利傳送。在路由機制的 設計上，先前已經有很多研究出現，各種選擇最佳路徑時的考慮因素，如道路上的車子數 量，道路長度等都已被提出。本文提出一個利用即時交通資訊的路由協定，藉由路段上位 於路口的車輛發動探測封包，經由路段上的車輛攜帶和傳送到達同一路段上的另一路口， 由此測量得到各條路段上最新的封包傳送延遲時間，並且考慮車輛在道路路口轉彎時會集 中，車輛數較多的特性，在不加入額外路邊單元的情況下，設計機制將收集到的延遲時間 資訊暫時儲存在路口範圍內，同時嘗試將此資訊擴散到鄰近路口並暫存。當封包經由車輛 轉傳到路口，需要對下一個即將轉傳的路段作優先權計算時，便可得到此資訊，在沒有得 到即時延遲資訊的路段，因為車輛上有預先紀錄的歷史交通資料(車輛數，道路速限)，車 輛可以依據其他研究中的算式估算各路段的傳輸延遲時間，混合有即時延遲時間資訊路段 的和經由歷史資料計算出延遲的路段，得到最短延遲時間的路徑。進一步考慮更新即時交 通資訊所帶來的大量網路負擔，我們研究各個路段的連通性，先判斷路段是否為接近連通， 也就是使用無線傳輸可以快速傳送資料經過此路段，中途不會傳輸中斷而需要由車輛攜 帶，這些路段對傳送延遲時間的影響較大，此時才針對這些路段進行即時資訊更新的動作， 藉以減少網路負擔量同時增進傳輸延遲時間。連通性的考慮方法為利用車輛在行駛的特 性，當車輛自由行駛時，道路上車輛的分佈呈現指數分佈。道路上每隔一段長度內有車輛 的機率可以用道路上的車密度得到。於是只要在傳輸範圍內存在有一台以上車輛出現的機 率極高時，便代表可以往前傳送。連續數個傳輸範圍內都有車輛可以幫忙轉傳，這些傳輸 的總長度大於道路長度時，道路接近於完全連通。但考慮車輛在道路上的分佈並非均勻且 實際每次往前轉傳時跳躍距離不等於傳輸範圍，必須針對轉傳時跳躍的長度做計算，最後 以連續數個期望跳躍距離內皆有車輛的機率當作連通機率，可得出車輛密度和連通機率的 關係。 透過模擬比較和其他路由協定的傳輸延遲時間，傳輸成功率和協定本身對網路造成的 負擔。在正常交通情況下結果略好，但當交通情況出現和統計資料有重大差異時，本協定 可以增進封包傳輸的延遲時間。 在實作方面，我們並設計了離線電子地圖與地理資訊資料庫，以提供使用者發出請求 的介面。在資料傳輸的部份則與工研院合作，使用其 IWCU 作為實作平台 (Implementation)。在應用程式方面以使用者請求各路口影像畫面為主要目標，我們利用了 車機 (On Board Unit)來時做電子地圖，並利用電子地圖來收集及分享地理資訊。並且，我 們也設計了循環錄影的功能，以防止存取空間不足的問題，實作的環境為 ASUS EeePad 與 ITRI 的 IWCU。依據我們的設計，則使用者可以透過車用行動通訊網路取得各路口或是有 各輛車所見的即時影像，對於追蹤及監視都有莫大幫助。
關鍵字：車載通訊網路、多躍、繞徑、即時交通資訊、道路連通性，資料探勘，多媒體資
英文摘要
Recently, due to its potential road safety applications and commercial applications, vehicular ad-hoc networks (VANETs) have drawn a great amount of research attention. Currently, most of the research and real applications are limited to communication within only one-hop or a few hops away. However, it is also important to send data to a remote destination using a multi-hop manner. For example, a driver may need to send a query to the parking lot for the available parking space, or a reservation message to the destined restarrant. Applications like these may send packets to their destinations via the multi-hop transmission manner.
Vehicles on intersections were triggered to send connectivity packets to vehicles on adjacent intersections conditionally. These packets traverse road segments by two ways, forwarding and carrying, and then we can measure latest road delivery delay. We consider the feature that vehicles slow down and gather on intersection, so the number of cars is more. We try to design a mechanism to store delay information on intersection area without Road side unit. Meanwhile, we will disseminate it to cars on neighbor intersections and store on them in the same way. When packets are forwarded to vehicles on intersection, routing protocol will calculate road priority and assign packets to vehicles on higher priority road as possible. In this time, if vehicles can get real-time delay information, we use it and statistic density data to decide next forwarding road. Otherwise, vehicles only have preloaded data, and we still can decide road priority with non-real-time data with the same way as previous work. Furthermore, we take periodical update overhead into account. We discuss road connectivity probability and find out the relation between this probability and the number of car on road. During the traversal process of connectivity packets, we judge whether a road segment is connected. If a road is connected, then we update road delay of the road. Because we think packet transmission on connective road is quickest. Packets can be sent on one intersection to another intersection by wireless transmission without carrying on vehicles. These roads have significant impact on end-to-end delay, thus we focus and do update action on them. Then we can have benefit of reducing overhead and improving delay in the same time. To research on connectivity, we assume the distribution of inter-distance of cars is exponential when drivers go on road freely, referencing traffic research. For one car, if there is another one within its wireless transmission range, it can forward packets to that car and packets can be forwarded in some forwarding distance. We use average vehicle spacing to find the forwarding distance.Wecalculate theprobability ofhaving carsin onecar’stransmission range. When this situation happens many times, the total forwarding distance exceeds road length. We say the road is connected and use this process to find out connectivity probability. In traffic congestion cases, simulation result shows that compared with other routing protocols, our method can improve delay and reduce overhead.
In the implementation, we adopted on board unit (OBU) designed by ITRI. Moreover, the main feature of the application is letting drivers query videos captured at roads intersection. User Interface is implemented with ASUS EeePad and off-line digital map. The digital map is not only used for display geographic information but also for information collection. Furthermore, circular recording scheme has been designed in order to overcome the issue occurred with limited storage. With the design, drivers can get geographical information including real-time capturing videos.
Keywords: Terms-VANET, Intersection-based routing, Real-time information, Road connectivity,
一、 前言
隨著網路快速發展，在智慧運輸系統(Intelligent Transportation Systems)以及車用行動通 訊網路或稱車載網路 (Vehicular Ad Hoc Networks-簡稱 VANET) 在近幾年中被廣泛的運用 在行車安全及車用相關技術當中，車載通訊網路藉由無線通訊與資料傳遞技術，串聯交通 工具以及路邊交通設施，藉由車輛之間的無線傳輸形成網路，資料可以在道路上快速流通， 任意車輛之間可以直接或經由多重跳躍傳送封包在車載網路當中，並透過搭載車機(On Board Unit-簡稱 OBU)的交通工具被視為一個節點，能與方圓 100 到 300 公尺左右的其他節 點進行網路傳輸。而主要的目標是提升道路的安全性及交通運輸的有效性。為了提升道路 安全性及有效的運輸率，許多國家已經設置特別的網路頻段提供給車載網路使用。例如美 國聯邦通訊委員會 (Federal Communications Commission, FCC)已經為 DSRC(Dedicated short-range communications[1])傳輸保留了 5.85~5.925GHz 的無線電頻段。裝置 OBU 的車輛 可以透過廣播的方式傳遞各種交通相關的資訊。以交通安全應用程式為例，當某個節點偵 測到塞車或是交通意外時，它可以產生安全訊息，並廣播給後方來車。其主要應用都是產 生即時性資料供作參考。而在資訊追蹤上，則可以透過各節點先分析有效資訊後，再傳遞 資訊給其他節點，諸如該車可視的車牌號碼…或是加強行車安全性的車輛防撞警告，到實 用性的車隊通訊，停車位告知，甚至是娛樂性的即時交通流量資訊、旅遊規劃等等各種在 車際網路上的應用紛紛被開發出來[2][3]，這些應用不但改善了便利性更提升了人們的生活 品質。在車載網路中，主要的架構有兩大類，其一為車間通訊 (Vehicle-to-vehicle, V2V)車 輛對車輛之間，好處是資料可以在道路上快速流通，任意車輛之間可以直接或經由多重跳 躍傳送封包，而另一類則是車機與基礎建設間的通訊 (Vehicle-to-Infrastructure, V2I)可以選 架設其他基礎設施來幫助資料的傳送。透過車輛的移動性可將資料送達其他網路架構無法 送達之處，好處為成本低且傳輸快速。 要讓這些應用得以實現，許多研究議題紛紛被提出。基本的網路構成要件，MAC 層的 存取機制設計和封包如何在相鄰兩車間傳送的問題已經廣泛的被討論。除了這些要件外， 車輛可能需要傳送資料到數公里外的車輛或固定點，此時需要實現遠距離兩車之間多重跳 躍資料傳送，必須要有一個可靠且可以符合傳輸延遲時間要求的協定。簡單的應用如車輛 行駛在道路上，可以向遠方的商店訂購物品，當車輛到達商店便可拿取所需商品。在車際 網路中的路由協定設計上會遇到一些困難。雖然車際網路是隨意式網路的一種，但車際網 路有其不同於傳統隨意網路的特性。首先，車輛是以高速移動，網路拓樸變化較大，隨意 式網路上的節點移動速度較慢，網路拓樸變化較小，無法利用紀錄網路上所有節點間的位 置建立一條長期存在的路徑，兩車輛間的無線傳輸也不穩定，因為節點間的位置隨時在變 化。再來因為車輛被限制在道路上，被道路間區塊分隔的車輛無法進行傳輸，只有在特定 區域上有車輛可以進行無線傳輸，隨意式網路的節點可以分散在各處，每個節點周圍都可 能有節點可以傳輸，比較起來車際網路如果在車輛密度不夠高的道路上，容易出現周圍無 節點，傳輸中斷無法再往目的地轉傳的情形。 先前研究的路由協定，一開始提出的方法是直接套用隨意式網路上既存的方法，如 AODV[4]，DSR[5]。這些協定是以拓樸為基礎，也就是紀錄路徑上的每一個經過的節點， 路徑選擇的依據是最短延遲時間，當封包要傳送時，依據路徑上紀錄的節點逐點傳輸，最 後到達目的地。這種方法在隨意式網路上有不錯的效能，但是在車際網路上因為網路拓樸 變化大，路徑上的節點時常且快速移動，傳送過程中紀錄的路徑會時常斷裂，此時需要啟 動路徑復原機制重新尋找路徑，產生大量的控制封包負擔，封包傳送延遲時間也增加，傳 送成功率下降。而且需要在封包來源點啟動查詢封包才能在路徑上節點都留下路徑紀錄，
發送查詢封包需要時間，產生的封包無法即時快速的送出，需要等待一段時間，增加封包 傳輸延遲時間。另一種也是隨意式網路上的協定改以位置為基礎，如 GPSR[6]，這類協定 不需在封包從來源點送出前建立路徑，來源點知道目的地的位置和周圍鄰居節點的位置之 後，以貪婪法選擇位置最靠近目的地的鄰居節點送出，鄰居節點收到後也是作相同動作直 到送到目的地。如果傳送途中某一節點附近沒有更靠近目的地的鄰居節點可以轉傳，使用 右手法則繞路而行。如此在鄰居節點快速變動的情形下也可以有路徑到達目的地，只要中 間轉傳節點都有更靠近目的地的節點，每次封包傳送經過的節點不必相同，這類協定的缺 點是沒有考慮到道路性質，只用位置來選擇下一節點，容易傳送到車輛密度低的道路或和 目的地所在道路沒有相接的道路，增加傳送延遲時間。 近來新出現的車際網路路由利用到新出現的技術數位地圖和車輛與道路之間的關係。 首先假設車輛都裝載有行車裝置，可以裝載地圖。有了地圖資訊後，在計算最佳路徑時可 以考慮道路拓樸，車輛密度，車速等交通資訊，傳送封包時盡量經過車輛密度高且實際上 可以連接到目的地所在道路的那些路段，避免傳送到無法到達目的地的道路。再者因為有 地圖，可以將車輛在可能行走的道路抽象化為圖形，將路口轉化成節點，路口間的路段以 有權重的邊代表，這邊的權重可以是傳輸延遲時間、車密度、連通機率，路段長度等。原 本路徑是以路徑經過的節點表示，現在可以用簡單的圖形，路口和路段組成，不需確切知 道每一節點的位置，只要決定到達路口時，要往那一個路口轉傳，決定之後，依靠路段上 的車輛轉傳，只要有車輛位於路段上且在傳輸範圍內便可幫忙轉傳到下一路口，計算上簡 單快速，也不需在節點紀錄路徑。在這種架構下，在選定下一個路口優先順序時有些許不 同，像 GyTAR[7][8]僅僅是傳送到路口時，貪婪法將和現在路口相接的道路作優先權計算， 並未將現在路口到目的地所在路口的中間的所有路段加以計算。改良過後的協定如 MDDV[9]，VADD[10]，SADV[11]等，會將封包現在所在路口到目的地所在路口間的所有 道路轉化成圖，根據歷史統計資料的交通資訊(車輛密度，道路速限)計算出每條路段的權 重，但並不是直接套用常見最短路徑演算法，因為每個路段不一定都存在有車輛，還要再 加上每個路口可以轉傳到下一鄰近路口的機率，利用方程式求解。這樣可以盡量將封包依 據車輛數較多的道路傳送，維持傳送延遲時間的最佳。這些協定已經考慮到全域最佳解， 但是仍有其缺點存在，在 SADV 中提到，像 VADD 這種協定在估計每個路段的傳輸延遲時 間時，是使用統計資料(平均車輛密度)。當車輛數隨著時間變化而不同時，計算出的延遲不 能反應出即時的最佳路徑。於是提出了即時交通資訊的概念，就是利用車輛收集個路段傳 輸延遲時間，在資料封包傳送時附加欄位測量路段傳輸時間，然後在計算路徑時加以利用， 但其特點為使用到路邊單元，也就是要在路口多架設數個無線裝置，負責測量路段延遲時 間，這樣就需增加額外成本，而且並不是隨時都有資料封包經過路口，不能隨時都能得到 路段延遲資訊。類似概念，在 RBVT[12]中也想要利用交通資訊，但其中提到的交通資訊是 指道路是否連通，先去測量哪些路段是連通的，也就是在路段中都持續有車輛可以幫忙轉 傳，中途不需由車輛攜帶後等到有車輛在傳輸範圍內才能轉傳，傳輸延遲時間極短，然後 在計算路徑時直接將那些不連通的路直接排除，只考慮有連通的路，並未提到會利用時間 資訊。這些使用即時資訊的協定，會需要使用額外控制封包去得到即時資訊，對於網路造 成額外負擔。於是我們想要改良使用即時交通資訊的路由協定，首先我們考慮車輛在路口 時的數量會比在路段上較多的特性，不使用路邊單元，設計機制讓車輛在路口自己形成暫 存單位將收集到的即時交通資訊儲存在路口。同時為了解決收集道路資訊時需要傳送大量 控制封包造成網路負擔過大，我們研究道路連通性和車輛密度的關係，想要利用這個關係 當作門檻，利用道路上的車輛分散式的去偵測道路密度，當車輛密度到達一定值，整條路 段呈現極高機率連通時才進行更新動作，只針對那些目前交通情況適合作無線傳輸的路段
更新，其他交通狀況變化不大的道路不做更新，藉此減少需要頻繁更新的負擔。
除此之外，近年來，雲端運算技術 [13][14] 運用隨意取得且相對便宜的高速網路，來 實現虛擬化技術，並運用分散式 (distributed) 計算與平行 (parallel) 計算技術讓使用者覺得 有無限的運算資源並願意為運算付出經費。主要的雲端服務共分為三種類型 [15]: 基礎設 施即服務 (Infra-structure as a Service, IaaS)、平台即服務 (Platform as a Service, PaaS)和軟體 即服務 (Software as a Service)。其中，IaaS 主要為服務提供者提供顧客相關的運算、網路 或存取資源。PaaS 則提供一個開發平台，讓顧客能透過網路存取該開發平台。最後，SaaS 則是提供顧客所需的應用程式服務。現在，車用行動通訊網路可以形成一個雲端網路。其 主要原因是車用網路上的資料多半是即時的。當使用者需要資訊時，即向該網路申請所需 要的服務。在 [16, 17] 中，作者首先提出了在車用行動通訊網路中提供雲端存取服務的概 念。例如: VANET 中的 IaaS 服務。所有的節點提供使用者計算、網路及存取的資源，像是 將所見的影像直接發送到網路上做儲存。在我們的研究中，我們不僅在 VANET 上實現雲 端服務，更為使用者實作整套系統。
二、 研究目的
本子計畫環繞著三個主軸，其一是在探討車載通訊網路之 unicast 繞徑問題，也就是利 用 multi-hop 的方式使得訊息可以傳遞至目的地，本子計畫所探討的繞徑問題與其他子計畫 有著密切的關係；例如子計畫七車的載網路多媒體串流服務中，無論點對點的傳輸或是 application layer multicast 的應用，二點之間的傳輸都需藉由 multi-hop 的傳輸方式來達成； 而子計畫一的車群管理服務與子計畫三的車載網路之位置感知服務等應用中的訊息傳遞， 都可藉由 unicast 繞徑技術的輔助來達成，其二是我們研究道路連通性和車輛密度的關係， 想要利用這個關係當作門檻，利用道路上的車輛分散式的去偵測道路密度，當車輛密度到 達一定值，整條路段呈現極高機率連通時才進行更新動作，只針對那些目前交通情況適合 作無線傳輸的路段更新，其他交通狀況變化不大的道路不做更新，藉此減少需要頻繁更新 的負擔。最後實作車間網路的通訊應用，除了與工研院合作外，設計車間網路封包路由的 規則以提升應用程式的效能。另外，為了提升一般民眾的使用率，我們也提出了圖形化的 人機界面，搭配電子地圖的運用，讓駕駛人能便利的操作該系統。此外，我們也實作了離 線地圖以降低網路流量，並於地理資料系統中提升其效能。不僅將為交通的安全性及實用 性帶來便利，更將讓應用程式的發展延伸到車間通訊的領域。 在此報告中接下來的部份包括，第三章介紹車際網路上和本論文相關的路由協定及研究 為 了 驗 證 車 載 通 訊 網 路 繞 徑 的 可 行 性 ， 我 們 參 考 由 Zhao 等 人 所 提 出 之 VADD (vehicle-assisted data delivery)[1]車載通訊網路繞徑方法，期望能藉由實際的硬體與軟體，實 現一可行的車載通訊網路繞徑，第四章提出我們改良過後的路由協定和使用到的收集道路 資訊機制，道路連通性與車輛數的關係，第五章透過模擬實驗的結果比較我們的方法和其 他先前研究的方法，在各項度量上的分析，在實做部分呈現 VADD 時的硬體架構、軟體架 構，並將呈現實做車載網路上的相關應用開發系統架構。
三、 文獻探討
現今已經有很多在車際網路路由的研究被提出，根據特性不同可以分類為以下二種， 以拓樸資訊為基礎和以位置資訊為基礎的路由協定。 以拓樸資訊為基礎的路由，必須在封包送出前先發出要求去知道網路上來源點至目的 地之間節點的連結情形，每個節點紀錄到目的地的最佳下一個轉傳點.封包送出後,依據各中 繼節點紀錄的位置找下一轉傳點,路徑是由節點組成。簡單來說就是各個節點都需要維持自 己可以知道的全域路徑表，紀錄到哪個節點要經過的下一轉傳點是誰以及經過多少轉傳次 數才能到達，這種方法被認為在車際網路上比較不可行，因為車輛會在道路上快速移動， 路徑會快速地改變，要在路徑表中維持任兩點的正確連結紀錄是很困難的事。 以位置資訊為基礎的路由，節點需要知道自己的位置、鄰近單跳節點的位置，和目的 地的位置，之後再經由不同的最佳最佳化條件(傳輸延遲最短,傳輸成功率最高).在封包送出 後依照位置去選擇下一轉傳點,不必要傳給某一特定節點,只要有位置更接近目的地的點存 在即可轉傳。而且因為現今 GPS 裝置的普及性快速增加，使得以位置為基礎的路由更加可 行實用。在以位置為基礎的路由協定中，近來新的研究方向著重於利用更多有關車際網路 特性的資訊來判斷要選擇哪條路徑，藉以達到傳輸成功率較高和傳輸延遲較短的結果。目 前新提出的方法中，有一類是加入數位地圖資訊，包括道路分佈及連接情形，道路速限， 路口是否有紅綠燈，各時段的平均車速和車輛數，利用車際網路上一些可預測的移動性來 幫助資料傳送，當作選擇路徑的參考依據。同時在路徑的建立上，捨棄以往以車輛當作路 徑紀錄的基本單位，改以路口為路徑的紀錄單位。就是每條路徑建立完成後，是紀錄中間 經過的路口編號，根據此順序從起點到達目的地，在路口依據優先順序找對應道路上的車 輛前往下一個路口，中間經過的車輛，是從在路口與路口中間道路上的車輛中，根據當時 情況選擇數台車輛繞行過這條道路即可。所以路徑不必紀錄中間要經過哪幾台車，符合車 際網路車輛快速移動導致車與車之間的連結快速變化經常斷裂的情形，連結紀錄會快速改 變所以紀錄的連結會消失效用的特性。而且車輛本身就被限制在道路上行走，只有在路口 才有可能改變行進方向，所以只要規定在路口時候決定下一步要傳送到哪一個路口即可， 在道路中間傳輸不太可能會超出道路範圍，這樣整條路徑要紀錄的資訊就只有路口順序， 資料量大幅減少。在這類路由方法中，較知名的方法有 VADD，另外還有 GPCR[18]、 GyTAR、A-STAR[19]等。 VADD 是在車際網路中利用多重跳躍的路由協定，它將道路地圖抽象化成圖，其中路 口當作頂點，道路當作邊，道路會將路口連接起來。道路就成為頂點之間的連結，道路的 權重就是預測的傳送延遲。利用已知數位地圖上的統計資料(車輛速限、車輛密度)計算封包 傳送過每一條路段的延遲時間。在傳送時可以使用的方法有藉由車輛間的無線傳輸和 carry-and-forward。基本概念是當往目的地的方向決定好後，有車輛在當前車輛的前方且在 傳輸範圍內時使用無線傳輸，若無則當前車輛暫存封包直到遇到其他可以幫助傳送的車輛 才轉傳，這樣在車輛密度較低的情況下，讓封包不會馬上被丟棄而是可以繼續等待更好的 車輛幫忙轉傳，增加封包傳成功的機率。每次當有車輛要傳送封包時，起點車輛先要利用 Location service 等方法知道目的地車輛位置，然後將起點到目的地圍成一矩形，取出地圖 上這個範圍的道路，計算每條道路預估的延遲時間，根據車輛在各個路口的停留時間和轉 彎機率，計算封包在路口會轉傳到鄰近路段的機率。對於每一個和起點路口相接的路段， 計算使用此路段到達目的地路口的預計延遲時間。經由此路段到目的地路口的延遲等於此 路段的延遲加上到達路口後轉傳到各路段的機率乘上用各路段走到目的地的延遲，被圍成矩形內的所有路段的到達目的地預計延遲時間列出來後，可得到方形矩陣，對於矩陣求解 得到每一路段到目的地的延遲時間的解，這樣將起點到目的地的最短時間路徑計算出來， 決定各相鄰路段的優先順序然後往較佳的路段傳送。封包傳送途中，會根據現在攜帶封包 車輛是在路口範圍或是道路中間分成兩種模式：在路口範圍時就計算各相鄰路段的優先權 並依路口優先順序找鄰接道路上是否有車輛可以幫忙傳送，若都沒有車輛可以幫，就暫存 封包在記憶體。在道路中間時則使用 GPSR 找尋在同一條道路上更接近目的地的車輛轉 傳，若沒有車輛可以幫忙一樣是暫存。當接近到終點一定範圍內後，就使用單純的 greedy-forwarding 找尋地理位置上更接近目的地的車輛並轉傳。這個方法有考慮道路的連 通性和車輛只有在路口才會變換方向的特性，節省路徑紀錄的大小。在道路密度中等以上 且穩定的情形下有很好的效果，但在道路密度低且變化大的情形下效果會變差。原因之一 是在道路上車輛密度低時，在封包到達路口時，優先權較高的道路上都沒有車，導致最後 只能利用優先權較低的道路傳送，造成傳送的路徑不是最佳。另外因為估計的道路延遲時 間是根據統計的平均道路密度計算出來，但道路密度會隨時間變化，導致估計的延遲時間 不準確。
因為以上原因，SADV 改善了 VADD 的缺失，SADV 考慮到其一當封包傳送到路口時， 優先權最高的路段上此時不一定有車輛。想要利用在路口擺設靜止的節點(RSU)來幫助封包 傳送，當封包在路口要做下一個路口的選擇時，如果優先權最高的路段上沒有車輛可以轉 傳過去，可以先暫存在靜止節點，等待到有車輛出現時再轉傳出去，這樣可以盡量保持在 最佳路徑上傳送。其二 VADD 方法中無法從車流的變化得到延遲時間，而是利用統計計算 得到，SADV 可以利用這些節點來做延遲時間的測量，更新的方法是當有封包從一個路口 要送到另一路口時，在封包中插入時間欄位，當封包到達另一路口時，將當前時間和封包 中的時間紀錄相減得到這條路的延遲。然後收到的路口靜止節點再將此延遲時間資訊包裝 成延遲時間更新封包，用廣播方式告訴其他節點，其它節點收到根據加權公式計算後修改 自己的延遲時間紀錄。當有封包要送出時，分成兩種模式：道路和路口模式，在道路時， 使用 geographic forwarding 傳送到路口的靜止節點，就是選擇地理位置上最接近路口靜止節 點的車輛幫忙傳送。在路口時，利用延遲時間紀錄和 VADD 的公式計算最佳路徑，當前往 最佳路徑上的下一個路段上有車輛可以幫忙傳送就將封包送出，沒有的話靜止節點此封包 暫存。直到最佳路徑上有車輛可以幫忙傳送或暫存空間滿了，因為暫存管理策略從暫存中 拿出並根據路口優先權選擇當時次佳路徑上的車輛傳送。這個方法因為有在路口放置節點 幫忙，即使在道路上沒有車輛的情況下還是可以暫存，更增加封包選到最佳路徑的機率， 而且有近乎即時的延遲資訊更新，可以根據道路的變化計算出和統計值不同的最佳路徑， 得到的路由效果會比之前的 VADD 較佳。但其缺點是必須在路口增設類似 RSU(Road Side Unit)的裝置，成本增加，另外在延遲資訊的更新方法中，要有封包需要被傳送時才會有機 會更新節點的延遲資訊，更新的資訊在有資料封包送出前無法得到，傳播延遲時間更新封 包是利用廣播方式沒有明確限制傳播範圍，造成一些多餘的負擔。後來有研究 RBVT-P 對 於更新封包的更新方式做了不一樣的用法。RBVT 的基本概念是想利用即時的交通資訊製 造出以路口為基礎的路徑，在路口中間則是可以自由選擇車輛傳送，不必紀錄路徑中每一 台經過的車輛，同時考慮到路口間連通的機率。 這邊提出的路由方法有兩種，RBVT-R 和 RBVT-P，RBVT-R 的方式是需要路徑時才啟 動機制，當有封包要從來源點送出時，用 flooding 方式發送要求封包去找到到達目的地的 路徑，為了避免造成太大的負擔，重覆起點和重覆序號的要求封包會被丟棄，中間各個點 收到後，並不馬上廣播，而是等待一段和前一個節點距離成倒數的時間，如果這段時間內
沒有聽到其他節點廣播，自己才廣播，確保每次傳輸都可以走最遠距離和減少網路上的交 通量。來源點送要求封包出去，一開始封包內路徑紀錄為空，中間收到的節點檢查是否到 達和前一個節點不同的路段，如果是的話，把新多出的路口加入路徑紀錄中，直到到達目 的地。目的地回傳回覆封包給來源點，紀錄來源點到目的地以路口構成的路徑，來源點收 到回覆封包後開始傳送資料。另外針對車輛會移動的問題，有路徑維持的機制，來源點或 目的地移動到新的路段時，原本路徑上必須經過的路口便不需要再經過，此時來源點或目 的地會發送路徑更新封包到目的地或來源點，將不必要的路口從路徑紀錄中刪除。在路徑 途中遇到沒辦法再往前轉傳的情形時，起點也有錯誤處理機制，來源點等待一段時間，嘗 試使用這條路徑，直到時間過後還是無法傳送便重新發起要求機制。這個方法和之前在 MANET 上的 AODV 相似，只是將其轉化成以地圖路口為基礎的方式。 較之前不同的是第二種路由方式 RBVT-P，RBVT-P 是周期性的去探尋道路上的路徑， 然後使用看到的近乎即時的道路圖計算路口間的最短距離路徑。以道路為基礎的拓樸探索 是利用周期性的、隨機選出一些點發送 connectivity packet(CP)。每一個節點獨立地決定是 否要產生 CP，決定的依據是看現在網路上車輛數量，歷史的交通資訊，和上一次收到 CP 的時間。當決定要發送 CP 時，會定義要包含的範圍，也就是要探索多大的區域然後送出， 中間利用 DFS(Depth First Search)繞行整個範圍，收集道路上是否為連通的資訊，最後返回 發起 CP 的路段，在路段上第一個收到返回 CP 的車輛再將 CP 的內容散發出去。散發的範 圍是之前 CP 規定的探詢範圍，散發的內容是道路的拓樸，和道路上是否有車輛經過，是 否為連通，收到的車輛會更新自己的路由表，並依照此路由表來計算距離最短路徑。計算 時只使用那些被標記為連通的路段，計算好的結果放在封包中，封包便依照此路徑選擇路 口間的車輛來幫忙傳送，但是當經過的節點有更新的路由資訊，就會使用更新的資訊得到 的路徑來傳送。在車輛和車輛之間的轉傳，這邊比較不同的是採用 receiver-based forwarding，就是不指定下一個轉傳點，每一次傳輸都是廣播，收到的一群車輛中，會根據 條件經函式算出各自的等待時間，這邊考慮的條件有可以前進到目的地的距離，無線傳輸 的最佳距離，和接收到的功率，這三項的加權，最短等待時間的車輛廣播將封包往前傳， 其他等待時間較長的車輛聽到廣播後便將封包丟棄表示已經有人幫忙往前傳送。RBVT-P 的好處是可以隨著交通的變化，即時的收集道路資訊來計算最短路徑，但是在車輛分布較 低時，CP 封包的傳送變得較困難，因為要傳送繞經整個區域，需要整個區域內有足夠車輛 讓封包可以繞完並回到發起的路段，整個資訊才能收集完全並散發，而且繞行的時間可能 過久讓更新的資訊的新鮮度下降。在發送 CP 的參數上，要多頻繁發送且發送範圍要多廣 也無明確定義，這些參數會影響網路效能。頻繁的發送 CP/RU 封包可能會導致網路上的負 擔過重，反而導致真正的資料無法送達，而且在交通沒有多大變異性的情形，如果用已知 統計值就可以得知道路上的情況而且也和事實近似符合的話，其實不用頻繁的送封包去探 詢，真正有需要時再探詢即可。 基於以上論文中所產生的問題，我們尋找以下幾篇論文做參考，期望可以解決其中幾 個重要問題，並發展出較符合實際情形的效能提高的路由協定。 BojinLiu [20]探討車際網路上儲存局部資訊之能力並分析不同交通狀況下的結果和效 能。想法是在傳輸範圍內的車輛形成一個小型的 Mesh network，其中每一台車輛都至少和 mesh 當中的任一車輛可以透過單跳或轉傳互相通訊，在這個 VMesh 當中的每一台車輛都 擁有相同的資訊，只要有一台得到特定資訊，便可以用廣播或多次轉傳送給其他在同一 mesh 的其他車輛。實際運作流程如下，道路上隨時隨地可能有特定情形發生，如車禍，當 事件發生的同時，有一定的機率剛好有一個 mesh 內的車輛經過並收到事件發生的訊息，事
件發生的訊息可以被保留在事件發生的一定範圍內，藉由 mesh 之間的互相傳送和暫存，就 是當任一 mesh 的任一車輛收到事件發生的資訊後，車輛會傳送給同一 mesh 中的車輛並一 直保存此訊息，如果有新成員加入此 mesh，便分享給它。當遇到其他 mesh 時，將資訊送 給其他 VMesh。在快要離開這個範圍時，即將離開範圍的 mesh 會尋找有無即將進入範圍 內的車輛並將資訊傳送出去，在離開後將資訊刪除。只要一直有 mesh 進入事件發生的周遭 範圍內，資訊便可以被保存在這個範圍，類似暫時的儲存裝置，讓進入這個範圍內的車輛 都可以得到這個資訊，可以用做安全或其他用途。給定車輛速度、交通密度、和儲存在事 件發生周圍多大的距離，推算出訊息可以儲存住的時間(MTTIL)，和事件發生後會被任一 mesh 收到的機率(Pc)。經過模擬後，Pc 和推出的公式大致符合，MTTIL 依據參數不同從 十秒到數十秒，歸納出影響 MTTIL 的參數有無線傳輸距離和保存範圍的大小。這篇文章提 出利用車際網路將某些資訊保留在特定區域的方法，並分析實際效能，這個特點可以拿來 幫助車際網路上的路由方法。
文章[21]中，Link-state 是介於 proactive routing(隨時任兩個節點互傳資訊更新路徑表， 移動性大時負擔較重)和 reactive routing(需要傳送資料時發送要求封包，到達目的地之後回 傳回覆封包，節點數量多時負擔較重)的方法，就是當節點發現自己和周圍節點的連結發生 變化，連結斷掉或新產生連結時，傳送更新訊息給周圍幾個跳躍內的節點讓節點可以知道 最新拓樸，進而選擇路徑。本篇文章分析了在無線隨意網路上使用 link-update 的路由方法， 藉由限制更新的範圍和時間減少造成網路的負擔，使其可以適用於範圍較大的網路，並詳 細地定義路由方法造成的各種負擔，在最佳化負擔的情形下找出適當的更新跳躍數和時 間，並非傳送給每個點，讓所有點都更新成最新資訊，而是讓整個網路上的各個點在所知 拓樸不同的情形下選擇路徑。首先各個點每隔一段區間才送 link-update 到周圍 h 跳躍內的 節點，累積一段時間內的所有連結變化，減少了更新時所需產生的負擔，但還是有些許控 制封包的產生，而且因為這樣並不是所有點都在知道最新拓樸的情形下選擇路徑，會導致 選擇的路徑不是最佳的，造成資料封包在網路上須經過較多次傳送才能到達目的地，於是 就多產生了一些負擔。經過定義傳送更新訊息的封包和選擇到次佳路徑造成的負擔，兩者 相加為總負擔，對於此函數微分，最後得到最佳更新傳送距離和時間。根據時間，每隔一 段時間，如果有連結情形改變，就發送更新訊息到傳送距離內的節點。當有封包要傳送時， 起點檢查路由表中是否有到目的地的路徑，下一個轉傳點是誰，中繼的轉傳點根據收到封 包時自己知道的路由表選擇下一點，依此到達目的地。所以一開始離目的地遠時所知的路 由資訊比較不準確，越靠近目的地，越可以得到較精確的路由資訊，選擇較佳路徑。利用 link-update 特性，在車際網路上，或許可以採用這種方式，在造成網路負擔不大的情形下， 利用更新方式得到較好的路徑。 在探討車際網路中車輛間因為持續快速的移動導致車輛間距離過大,無線傳輸中斷的 問題中，[22]利用觀察實際交通流量畫出車輛間距的機率分佈,再使用統計學上的 K-S test 說明道路上車輛間距近似為指數分佈.並指出車輛間距超過傳輸範圍的情形在非尖峰時段 發生機率極高.接下來有一堆研究探討車際網路的連通性問題.重要的議題為探討網路上任 兩點之間存在有完全連通的路徑和就一個路段而言,在兩路口的車輛可以讓這兩台車用無 線傳輸互傳得到這兩個問題。就路段連通性而言，CAR[23]想要利用先計算出每條道路的 連通機率當作最短路徑演算法中的權重來找起點至目的地的最佳路徑。於是要利用統計資 料得到的車輛數配合連通率模型得到機率。使用的模型是排列組合將所有可能不連通的情 形得到並找出其機率 Pdis，連通率就等於 1-Pdis。計算 Pdis 的方法大致如下：將道路長以
車長 d 為單位切成格子狀共 m 個格子，傳輸範圍 R。當出現 n0=R/d 個連續空格都沒有車子 存在，代表這段道路有不連通的部分。 這樣的方式雖然將所有情形都考慮到，計算複雜度極高，當路長越長時，使用到的階 層數就越大。而且並未考慮車輛在道路上其實是有機率分佈的，此法的計算是假設車輛隨 意的散佈在道路上，如果考慮車輛在道路上的分佈，可以用較簡單的方法分析連通率。綜 合以上研究的問題和解法，我們想要利用即時的交通資訊，讓封包在傳送時可以依照當時 道路上交通狀況來計算出最佳路徑，在不多加入 RSU(Road side unit)，只利用道路上的車輛 的情形下節省成本。規定更新的方法讓更新的資訊可以有效且盡快的收集道路上的交通資 訊，同時可以儲存在路口區域讓經過路口的封包都可以因為知道最新的資訊而選擇較佳路 徑。另外針對更新的頻率做改良，並非每隔一段時間就更新交通資訊，而是在車輛密度有 重大改變的情形，可能影響傳送延遲時，利用車輛數和連通性的關係找出那些連通機率極 高適合無線傳輸的路段才進行更新。進而減少負擔又能增進路由效能。
四、 研究方法
我們所需的硬體包含了工研院所研發的 IWCU (ITRI WAVE/DSRC Communications Unit)、筆記型電腦、以及 GPS 接收器。IWCU 為一符合美國電氣與電子工程師協會 (Institute of Electrical and Electronics Engineers；IEEE) 所制定的 WAVE/DSRC (Wireless Access in Vehicular Environments/Dedicated Short Range Communications) 標準的高階應用平台。 WAVE/DSRC 所代表的是 IEEE 802.11p[24]與 IEEE 1609[25]國際通訊標準，應用於車用環 境的專用短距離通訊。在本文中我們又稱 IWCU 為 wavebox。
在我們的實作中，一個 host(即車輛)上的基本配置為一台 IWCU、一台筆記型電腦、 以及一個 GPS 接收器。應用程式以及 routing 程式執行於筆記性電腦上；筆記型電腦與 wavebox 以 Ethernet 連接；應用程式或 routing 程式欲送出封包時，必須先經由 Ethernet 送 至 wavebox，wavebox 將封包標頭格式轉換成 WSMP(Wave Short Message Protocol)的標準 格式後用利用無線傳輸傳送出去，由 wavebox 所傳送出去的封包稱之為 WSM(Wave Short Message)；IWCU 主要是負責封包的收送。
如圖一所示為一傳送封包時的簡易 protocol stack 流程。Host A 上的應用程式要經由 Host B 來轉傳封包給遠端 Host C 上的應用程式。首先，在筆記型電腦上的應用程式先將封 包傳送給我們的 Routing 程式，封包最後會經由 Ethernet 傳送到 wavebox， wavebox 收到 此封包後會將 IP 的標頭除去並轉換成 WSMP 格式的封包，然後透過 WAVE MAC 傳送出 去，Host B 藉由 wavebox 接收到此封包，將此封包傳送到我們的 routing 程式，routing 再藉 由 wavebox 將封包傳送給 Host C，Host C 最後則將此封包傳送給本地端的應用程式。
圖一、協定堆疊 主程式架構
Multi-hop Routing 程式負責處理封包的 Routing，決定將本地的應用程式要傳的封包轉 傳給特定鄰居或是自行攜帶，並且接收或轉送其他車輛所傳送的封包，以及定時傳送及接 收車輛資訊，維護鄰居列表，此程式架構如圖二，分成四個部分：Sender、Receiver、Service Handler 及 Delay Estimator。Sender 是負責與 GPS 溝通、取得車輛資訊後，將其加入 beacon 然後廣播。Receive 是負責接受、處理來自 wavebox 的封包，收到 beacon 封包則從中取得 車輛資訊並更新鄰居列表。若收到 RouteRequest 則根據其標頭內的資訊做對應的動作，可 能直接將封包送給目的地、找尋 relay node 幫忙傳送封包、將資料放進暫存區或是將封包傳 送給相對應的本地程式。Service Handler 是負責與應用程式溝通，提供一個傳送資料的介 面，當 handler 收到應用程式的 RouteRequest 便會檢查其鄰居列表，接著可能直接將封包送 給目的地、找尋 Relay node 幫忙傳送封包、將資料放進暫存區。Delay Estimator 是負責找 尋適當的 relay node，當 Receiver 或 ServiceHandler 須要透過 relay 來傳送資料時，Delay Estimator 便會啟動，根據目的地的位置資訊及存在資料庫中的地圖、交通資訊，做為 VADD 方法的參數，接著取得利用各條路傳送封包的優先順序，因此便可利用此優先順序從鄰居 列表中挑出最適當的 node 當作 Relay。
圖二、程式架構 應用程式則是要透過Routing程式與遠端應用程式溝通，應用程式將其所欲傳送的資料 包成特定資料結構(RouteRequest)，傳送給Routing程式，再由其幫忙轉送。如圖三，當應用 程式有資料要傳送，它必須將資料，以及目的地的ID、Port等資訊，打包成為一個request 物件，接著便可利用此request將資料傳送給Routing程式。遠端程式傳送的資料經轉送到目 的地端的Routing程式後，Routing程式會再將此資料傳送給本地的應用程式。 圖三、應用程式流程 圖四為 beacon 封包格式，此封包內容為車輛的相關資訊，各車輛皆會定時廣播給其周 圍鄰居，鄰居收到 Beacon 後便可以將發送者的資訊從封包中取出，更新其鄰居列表，利用 此一方法，各車輛皆可以得知其 one-hop 鄰居的資訊，各欄位用途如下：封包型態，標示 封包的型態以利接收者對封包解碼。發送者 ID，標示封包的來源。發送者緯度、經度，標 示發送者位置，供接收者計算與發送者之間的相對關係，如距離等。發送者速度，標示發 送者的速度，目前尚未使用到，為一延伸欄位，日後研究或改進方法時，可能會用到。發 送者所在路 ID，標示發送者所在路的編號，需要此欄位的原因：VADD 計算 Routing 優先
權時，回傳值為路的編號，因此必須在從鄰居列表中依據優先權選擇車輛。 封包型態 (int) 發送者 ID (int) 發送者緯度 (double) 發送者經度 (double) 發送者速度 (double) 發送者所在 路 ID (int) 圖四、beacon 封包格式 圖五說明 RouteRequest 的封包格式，為應用程式需要將資料送往遠端應用程式所用的 封包，發送者 ID 及 Sequence number 可以用來判斷封包是否重複，目的地 ID、port 為遠端 應用程式的相關資訊，目的地經緯度則是遠端使用者的位置資訊，可以用來計算 Routing 路徑，Relay ID 用來標記此封包的 next hop，資料欄位則是應用程式實際要傳送給遠端應用 程式的資料，各欄位用途如下：封包型態，標示封包的型態，以利接收者對封包解碼。發 送者 ID，標示封包的來源。Sequence number：標示封包的編號，與發送者 ID 結合後，可 以用來判斷此封包是否重複。目的地 ID，標示封包的目的地。目的地緯度、經度：標示目 的地的位置，供接收者計算 Routing 路徑，為 VADD 的參數之一。Relay ID，標示發送者 經由 VADD 計算後選擇的 Relay node 的 ID，若接收者非指定的 Relay 則可將此封包濾掉。
封包型態 (int) 發送者 ID (int) Sequence number (int) 目的地 ID (int) 目的地 port (int) 目的地緯度 (double) 目的地經度 (double) Relay ID (int) 資料 圖五、RouteRequest 封包格式 道路資料庫之建立：
由於 VADD 需要利用道路資訊來計算封包傳遞時的 next hop，因此本子計畫利用交通 部運輸研究所路網數值[26]，擷取我們 routing 程式實際所需要的道路資訊，建立成一資料 庫提供 routing 程式存取。我們利用交通部運輸研究所路網數值圖中的道路圖層和道路節點 圖層的資料，建立道路模型。由於每一筆原始道路資訊都是互相獨立，沒有提供道路連結 的關係，所以我們必須去分析每條道路的起終點經緯度座標來判斷道路的連接情形。我們 透過路網數值圖，建立起新竹市的所有道路的道路模型，將所有提供的每一條道路資訊串 接起來，成為一個完整且可連通的地圖道路模型。圖六為交通部運輸研究所路網數值圖使 用手冊上對於道路圖層道路節點圖層的說明。 圖六、道路圖層道路節點圖層的說明
以下是所建立的資料庫 Table 及所儲存的資料: Table Name 儲存資料 1. road_table 儲存道路資訊、道路端點的路口型態和經緯度。 2. roadnode 儲存全台灣的路口 ID 和型態。 3. tude_tm2 儲存道路的 tm2 資料。 4. tude 儲存道路的經緯度資料。 5. tudenode 儲存全台灣的節點資訊道路的經緯度。 6. road_length 儲存計算一段路的長度。 7. DandV 儲存計算一段路的速度及密度。 8. connection 儲存計算一段路與哪些道路相連接。 9. equation_tm2 儲存一段路的道路方程式係數。 10.intersection 儲存計算一段路與哪些道路相連接。 11.neighbor_node 儲存路口與哪些路口相鄰。 12.neighbor_road 儲存路口與哪些道路相連接。 圖七展示了道路主要的資訊。該表格紀錄了每條道路的兩端點以及道路編號。每條道 路利用二維的經緯度值來表示線的端點，而用一端戶相連接的線來表示一條道路，而頭尾 的端點即整條道路的起點與終點。當然，在轉折處會多一個節點來表示轉折點的經緯度座 標，其中的 count 代表該道路由幾個節點依序連接而成。
Road ID Count Endpoint 119.675968 , 23.556624 119.677085 , 23.556954 73 3 119.676533 , 23.558804 119.676533 , 23.558804 119.676350 , 23.559425 119.676174 , 23.559912 74 4 119.674693 , 23.560501 圖七、道路主要的資訊 GPS 定位： GPS 定位指的是由 GPS 所取得的經緯度取得車輛目前所在道路。VADD 中，車輛必須 能得知其所在的位置位於哪條路上，以便判斷與計算封包的 next hop。我們可以利用所建 立的道路資料庫以及車輛本身所取得的 GPS 資訊實現此目的。我們所採用的方式，是依目 前車輛的所在位置，計算其與每段路段的投影點與垂直距離，若投影點落在某一線段所形 成的矩形範圍內且垂直距離為最短，該路段即為所求。由於每一路段都有兩個端點，可藉
此求得路段的線性方程：若 為目前車輛所在位置， 為某一道 路的直線方程式，d 為 P 到 L 的垂直距離，P代表 P 在 L 上的投影點座標，則 例如，圖八中的 P 點，其與道路 L1的投影點並沒有落在 L1所形成的矩形內，因此可知 P 點必不在道路 L1上，但可能在道路 L2或 L3上；P 點與 L2和 L3的垂直投影距離分別為 d2 與 d3，而 d2< d3，因此例中判斷的結果為 P 點在道路 L2上。 圖八、P 點投影在道路 L2 圖九、座標，定位的流程 地圖切割： 我們將提出一個地圖分割方法，以加快道路配對的速度。由上一小節，我們可以確保找 到任一經緯度座標點所配對的道路，但是，由於要對所有道路做運算，其花費時間與成本 過高，再加上，實際做此運算的是一嵌入式設備，對於太長的回應時間，會讓使用者誤以 為系統已經當機。因此，我們提出一個地圖分割的方式，僅針對所需要的區域做尋找。我 們利用二分搜尋的方式從 n 平方的區域中找出我們的目標區域。 圖九中展示了地圖如何分割成區域 [27]。首先，利用 x 軸，將所有資料依據個數分割 成 n 塊相同大小區域，接著再針對 y 軸再平分成 n 塊相同大小區域。這樣一來就能將所 有資料分割成 n 平方塊區域。舉例來說，假設我們有 100 筆資料，而預計分成 2 平方 (4) 塊區域。假定有 50 筆資料的 x 座標小於 34.2251，則我們便從 34. 2251 將整塊資料分 割成 x 大於 34.2251 的區塊與小於 34.2251 的區塊，其中，這兩塊區塊裡的資料數量相 同。依據此分類方法，則我們可以得到我們一開始最想搜尋的區域。僅有少部分的例子顯 示，我們還是必須搜尋整個資料庫才能找到我們要找的道路。另外，由於地理資訊變異性 很少，我們可以將其先行計算，並且改由表格儲存索引值，則未來僅需以索引值存取資料 庫，則執行速度將獲得提升。另外，此索引值我們以欄排列為主 (column-based)，也就是 index = rowIndex + n* (columnIndex-1)，如此一來，若要延伸向其四面八方的鄰居區域做延 展，僅需增減其所引值即能達到效果。
搭配以上過濾的加速機制，我們針對交通部運輸研究所提供的地圖資訊，設計了我們的 離線地圖資料庫，並且在嵌入式系統上進行存取動作，其執行效能能順暢的執行於個人電 腦與嵌入式電腦中。 圖九、地圖資料庫分割 測試定位精準度： 以下為我們針對新竹市區，對於我們實作的定位方法所作的精準度測試。測試方式為 於 Google map 上隨機選取任一道路上的任一點，記錄該點所在的道路名稱以及該點的座 標；然後再利用我們實作的定為方法，以剛才所選取的該點座標為輸入，判斷出該點所在 的道路，若與所記錄的 Google map 上的道路名稱相符，則視為成功，否則為失敗。圖十為 測試結果。 點選 Google map 的道 路名稱 是否正確定位，若 錯誤，則判斷為 距道路的距 離 錯誤原因 1. 中華路二段 是 3.599(m) 2. 西大路 是 5.067 (m) 3. 中正路 是 0.900 (m) 4. 東門街 是 1.72952 (m) 5. 中央路 是 1.082 (m) 6. 光復路二段 是 12.260 (m) 7. 水源街 是 5.5518 (m) 8. 建中一路 23 巷 否，建中一路 68.515 (m) 資料庫無此道路 9. 新源街 16 巷 否，光復路二段 66(m) 資料庫無此道路 10. 東山路 61 巷 是 2.795 (m)
11. 竹蓮街 101 巷 否，南大路 50.3634 (m) 資料庫無此道路 12. 明湖路 28 巷 否，其他道路 3.469 (m) 資料庫無此道路， 名稱，標明為其他道路 13. 林森路 210 巷 否，林森路 200 巷 43.81 (m) 資料庫無此道路 14. 德高街 158 巷 否，林森路 158 巷 2.3925 (m) 資料庫與 Google Map 道路地點資訊不符 15. 南外街 否，其他道路 22(m) 資料庫與 Google Map 道路地點資訊不符 16. 園區一路 是 1.355176(m) 17. 科技二路 是 10.500(m) 18. 湖濱三路 是 1.8889(m) 19. 民有街 22 巷 否，其他道路 2.7213(m) 資料庫無此道路，名 稱，標明為其他道路 20. 民享一街 28 巷 否，民享一街 36 巷 4.9165(m) 資料庫與 Google Map 道路地點資訊不符 21. 光復路一段 607 巷 1 弄 是 1.96649(m) 22. 長春街 108 巷 否，長春街 98 巷 20.7933(m) 資料庫無此道路 23. 新莊街 122 巷 否，新莊街 180 巷 4.259283(m) 資料庫與 Google Map 道路地點資訊不符 24. 關東路 376 巷 是 2.8782(m) 25. 光復路一段 544 巷 否，光復路 544 巷 89.391(m) 資料庫無此道路 圖十、測試定位精準度 分析以上的測試結果，可約略得知正確率約八成。判斷錯誤可能來自於以下原因： 1. 交通部-運輸研究所路網數值圖有許多道路，尤其是小巷弄(道路寬度小於 6M)者並無 建立資料庫，所以在判斷道路精確度上有所出入。 2. 有一些在路網數值圖的道路資訊與 Google map 的資訊道路名稱並不相同，研判可能 其中一個的資料有所輸入錯誤。 統整地圖與系統： 為了最後的驗證部分，我們必須整合我們的地圖與整個系統，並且為測試環境做設定， 其中的測試環境為 Google 離線地圖。另外，我們對於不同的座標系統與球體投影到二維 平面地圖亦作了轉換分析的動作。其中， 台灣的地圖有幾種不同的座標系統，像是 TWD67、TWD97 與 WGS84。其使用的球體投影方法也有所不同，像是 TWD97 採用的 是橫梅投影 (Mercator projection)，其主要方式為利用一圓柱體將球體外切，再由球心對球 面所有點連線至圓柱體，將球面的點對應到圓柱體上，最後展開圓柱體的側面，即形成一 個二維的地圖座標系統。此方法被普遍用於相當多的地圖繪製系統上。 在使用者的畫面呈現上，我們便展示一個二維平面地圖，當使用者點下地圖上任一點，其 二維地圖座標便經過反向的橫梅投影，而得到其於世界座標中的經緯度值。此時，便會由 該點像附近廣播尋求處在該位置的節點所拍攝到的行車畫面。若得到附近節點所拍攝的畫 面，則使用者會先暫存一塊緩衝區 (buffer) 的影片後，開始撥放得到的影片資訊。整個系 統如圖十一所示。
圖十一、統整地圖與系統 其他與資料庫相關的實作，總結如下： 將道路資訊、全台灣"的路口資訊…等等 insert 到資料庫。 透過二度分帶(TM2)的座標系(單位為公尺)，計算一段路的長度。 與全台灣的路口資訊跟新竹的起點、終點路口資訊代碼比對找出新竹"起點" 路口 的節點型態，得知道路相連的情形。 計算出新竹市所有道路方程式儲存在資料庫中，並利用以下GPS定位方法得知目 前所在位置。 將所有道路資訊封裝成 object 傳給前端運算程式。 應用程式系統架構： 透過上述建立的道路資料庫，我們結合行車紀錄器和車載通訊技術，開發出一個即時 路況預覽系統。例如，駕駛者前方視線若被大型車輛擋住，則可透過其他車輛之行車紀錄 器鏡頭，觀看其前方路況；亦可與雲端技術結合，將影像或影像之詮釋資料(metadata)上傳 至雲端，提供後端伺服器分析或協助警方搜尋辦案所需之影像證據。本計畫基於行車紀錄 器的日益普及，期望藉由車載資通訊技術，使眾多車輛上之行車紀錄器所記載之交通資訊 得以依據應用上的需求相互分享。如圖十二所示，為一結合行車紀錄器、GPS 接收器、智 慧型手機/平板電腦、以及車上機(OBU)之道路影像預覽系統。此系統提供駕駛者於行進間 可以預覽其計畫路徑上或他處之道路影像，以利駕駛提早作出行車路徑之規劃。駕駛者可
於行進間，以手指點取螢幕地圖上欲預覽之地點，車上機接著會發送一詢問封包至一特定 範圍，要求擁有該點選地點影像之車輛回傳該影像。
圖十二、結合 GPS 行車紀錄器，OBU
系統如圖十三，所有車輛定期上傳 metadata(包含時間戳、路名 ID、經緯度等)給 server， 當有車輛發出請求時會先從 server 的資料庫中查詢是否有對應的檔案，再依照對應的車輛 發出請求。 圖十三、車輛透過基地台存取雲端服務 車輛會定期上傳自己的拍攝到的照片和所在經緯度合成的 metadata 當有車輛對藍色區塊有興趣發出請求時，server 會查詢自己資料庫中是否有此筆資 料(檔案)，若有則 server 直接回傳給車輛，若沒有則回傳擁有此資料的車輛 ID。 該車輛收到 server 給予的車輛 ID 後會向該車輛發出請求，而收到請求的車輛會將 擁有的資料傳給該車輛。 當同區塊的 Metadata 要求頻繁時，Server 會主動和擁有此資料的車輛要求資料。 在車載網路上，移動中的車輛要持續傳送封包給位於道路上的靜止點，要想辦法使得 封包傳輸的延遲時間變短，封包更快到達目的地。 本協定主要是想利用道路上的車輛去作道路即時交通資訊(路段傳輸延遲時間)的更新 並且在路口製造暫時儲存機制讓收集到的道路資訊可以增加其被利用到的機會。我們認為 道路上的交通情況是瞬間變化極大的，如果封包在傳送途中有某些路段的車輛數增加或減 少，和統計得到的結果相差到一定量時，此時在路徑的選擇上是否應該不同。也就是說， 在封包傳送途中如果可以一直收到來自各路段的即時延遲，可能可以得到延遲更短的路
徑。決定是否發動更新機制的門檻值由道路連通性決定，我們認為當道路已經被判定為連 通，代表此時往此路段傳送可以快速傳送經過整個路段，這時交通情況一定是和統計資料 相差極大。當分散式的機制偵測道路密度到達一定值，連通機率極高時，才進行更新動作。 總結本協定大致分為以下三部份： 1.如何由道路車輛密度得知連通機率和分散式偵測機制 2.透過路口車輛發動更新機制並將收集到的資訊儲存在路口區域 3.將即時延遲時間配合統計資料計算的延遲時間計算道路優先權 連通性偵測： 以無線傳輸的假設，只要兩輛車在彼此的傳輸範圍內，傳送資料時便可以順利傳送給 對方。於是從路口一端開始，每隔傳輸範圍內有一台車以上，便可向前轉傳一段距離，我 們稱之為傳送距離。將道路用傳輸範圍內切成若干等份，每隔傳輸範圍內都有至少一台車 輛以上，需要轉傳(路長/傳送距離)次數恰可直接傳送經過整段路而不會在傳送途中某一段 沒有車輛在欲轉傳的方向而傳輸中斷，封包需要由車輛攜帶才能傳送過整個路段。對任一 台車而言，我們先得到其前方傳輸範圍內有一台車以上的機率，然後在此情況下，它可以 往前傳送經過傳送距離，當以傳送距離轉傳了(路長/傳送距離)次時，表示已經傳輸經過整 條道路。 已知車輛在道路上自由行駛的情形，車輛在路上的分佈為指數分佈[10]。也就是說，給 定一段長度，會出現一台車輛的機率為指數，參數為道路車輛密度。如果要知道對於一段 道路長為 L 的路段，傳輸範圍 R，要達到連通機率為 Pcon所需的車輛數，必須計算達到此 連通機率所需道路車輛密度，再將此密度乘上道路長度就可得到所需車輛數。對於任一台 車輛，ρi為道路車輛密度，它前方傳輸範圍 R 內有一台車以上出現的機率為 1 i i R s R i o e ds e
如果要成功由一端路口到達另一路口，至少需要轉傳 L/R 次跳躍。但這是假設每次轉 傳都可以成功往前轉傳到前方 R 公尺處。如果在轉傳過程中每次都可以以傳輸範圍前進的 話，那只要對於每隔 R 公尺的那些車輛而言，其前方 R 公尺內都有至少有一台車輛存在即 可，於是就是連乘。
R L R con i e P 1 在這邊我們要求的是給定一個 Pcon,想要知道i。因此可以透過以下推導
R L R con i e P 1 => R L con R P e i 1 => R R i L con e P 1 => ln 1 L R con i P R 1/ s s => R P R L con i 1 ln 最後得到的車輛數便是iL 但是由於車輛在道路上的位置不會是均勻的，前方傳輸範圍內有至少一台車，不代表 每次往前傳輸都可以往前進 R 公尺。於是我們想要知道每次轉傳時平均往前的傳輸距離是 多少。首先根據[28]車輛之間的距離為指數分佈。fS
s sess，s t/V，s:平均每公尺 的車輛數，t:道路上平均每秒觀察到的車子數量，要知道在傳輸範圍 R 內最遠的車輛距離 依照指數分佈，平均車間距為 期望傳輸距離便是傳輸範圍內可以轉傳到的 最遠車輛的距離，每次轉傳時可以轉傳這段距離。計算上看傳輸範圍內，車輛以平均車間 距相隔，累計這些車輛間距的總和，在不超過傳輸範圍的情況下，可以存在幾台車。以傳 輸範圍減去車輛間距的總和便是傳輸範圍內最遠的車輛離當前車輛的距離，也就是在找下 一轉傳點時，可以轉傳前進的傳輸距離。
R s
R Range Tx E[ _ ] mod 將此當作每次傳送可以往前前進的距離，原本求連通率的式子會變成 R P Range Tx E L con i ] _ [ ' 1 ln 修改過後真正所需的車輛數為i'L 圖十四、Connected example 以上圖十四而言，要由路段的一端傳送封包給另一端，如果在傳輸範圍內有一台車以 上，連續數個跳躍都有車輛往前傳，直到跳傳過整個路口，此路段為連通。在此我們對這 種用車輛分布來推導車輛連通機率的結果做模擬實驗，目的是要看預測的結果和實際值， 也就是車輛真的在路口傳送封包的結果，以及和其他方法中提到的模型計算出來的結果做 比較 。越接近真實車輛產生的曲線代表能越準確地知道車輛數大於某一定值 ，道路上車 輛就有很高的機率一定會連通。 Parameter Value MAC 802.11 Tx_Range 250m Packetsending rate 1 packet/second
1000m,1600m Vehicle Speed 0~18m/s(avg:15m/s), 0~8m/s(avg:5m/s) 我們使用 NS2(ns-2.31)[29]來模擬實際傳輸的結果以驗證理論連通率計算的準確性。比 較實際傳輸的連通率，Qing Yang[30]提出的方法 CAR 以及[31]一樣是以指數分佈分析，但 是以每次期望傳輸都可以前進傳輸範圍來比較。我們用車輛移動產生器[32]產生車輛的移 動，模擬不同的道路密度，模擬時間 500 秒，分別在路段的兩個路口，都各自由路口一端 往另一路口傳送封包，看有多少封包不會在傳送過程中遭遇到傳送路徑斷裂現象，然後除 以總共送出的封包數當作連通率。針對不同道路長，不同速限，不同車輛密度，每個情境 重複十次。 在圖十五在路長為 400m 時，用我們機率分佈得到的曲線在同樣連通率下，會預測出 需要多一點車輛才會連通，和實際值有所誤差，使用期望傳輸距離在道路長度短時沒有發 揮作用，反而會高估所需的車輛數而產生誤差，表示車輛在道路長度不長，車輛分佈密集 時，還是可以每次轉傳時都跳躍傳輸範圍。在路長 750m 時，使用期望跳躍距離後，我們 可以比原本每次都以傳輸範圍跳躍的結果和 CAR 更接近真實值。在道路長度逐漸變長 1000m,1600m,用機率分佈的結果會比 CAR 差，因為車輛散佈在道路上的位置情形變化較 大，分佈情形不均勻，實際上的車輛分佈和期望的指數分佈有所落差，車輛的連通性比較 差無法照機率分佈這樣理想。CAR 會將車輛在道路上所有位置的可能性都計算出，但當道 路長度越長，所需計算的階層數會隨之增大，計算上較為複雜。但當車輛數變多時，車輛 有越高的機率平均散佈在各處，預測的結果就越靠近實際值。總體來說使用期望傳輸距離 會比使用傳輸範圍較符合實際值。
