考量實際室外測量的困難性，目前我們的測試尚以室內為主。測試環境為數台筆記型 電腦，每台電腦各自連接一台 wavebox，並且安裝 GPS simulator 及地圖資料庫。GPS simulator 是用來產生虛擬的 GPS 座標，用以模擬實際道路駕駛時車輛所接收到的 GPS 訊號。我們依 據實際地圖，選擇一個小的範圍，當做模擬的場地。我們選定其中一台設定成在此範圍內 的某一定點，扮演 RSU(road-side unit)的角色，也就是封包傳送時的目的地；其餘各台電腦 上的 GPS simulator 設定成在此範圍內的街道上做等速的移動，扮演 OBU(onboard unit)的角 色。
系統啟動之後，各 OBU 皆會定時產生資料封包要送到 RSU。若 RSU 在 OBU 的傳送 範圍內，OBU 便可直接傳送給 RSU；否則則尋找一 relay node 當做 next hop。若不存在適 合的 relay node，OBU 則自行 carry 資料封包，直到到達目的地或是找到 relay node。測試 結果為 RSU 可以收到來自各個 OBU 經由各種方法所傳送的封包。
我們比較使用即時資訊更新的協定及原本的 VADD，比較各種路由協定上的度量。實 驗的地圖大小為 4000×3200m 的矩形街道地圖，MAC 層的協定是 802.11，有 DCF 功能。
車輛移動的軌跡是使用[33]產生。
Parameter Value
Simulation Area 4000×3200m
# of intersections 24 Intersection area radius 200m
# of vehicles 150
# of senders 15
Vehicle velocity 0~100 km/hr CBR rate 1 packet/second Beacon interval 0.5 sec
表一、Simulation Setting
模擬初始時車輛隨機散布在道路上，然後車輛機選擇一路口當作行駛的目的地，照最短路 徑開到該路口，權重為道路長度除以道路速限。車輛抵達目的地之後若模擬時間尚未結束，
再選下一個路口當目的地開過去。
封包傳送的目的地為設在路口的靜止點，於是我們在所有路口中隨機選擇十五個當作 封包傳送目的地，在道路上所有車輛中選十五個當作封包來源點傳 constant bit rate(CBR)資 料。在模擬時間中從五十秒後持續傳送資料，傳送速率每秒一個封包，實驗參數如上表。
形成連通，製造類似塞車或車禍之類的道路狀況異常，讓被即時資訊更新且繞路的封包數 增多，再來看改善過後的傳輸延遲，延遲時間確實有縮短。下面各圖的圖例：Conn-CP 為 先偵測連通率再決定是否傳送 CP，Always-CP 為隨時隨地都會傳送探測封包去得到最新交 通資訊。
傳輸成功率
就傳輸成功率來看，使用 CP 之後，雖然負擔增加，傳輸成功率和原本的 VADD 並沒有下降太多，約略相同，顯示送 CP 封包的負擔不會造成碰撞情形大幅增加。分 析造成傳輸成功率下降的兩個主要原因：RET 和 TTL。RET 意指在封包傳送過程中，
在路徑上的某一轉傳節點，因為碰撞而一直無法將封包傳送到下一節點，直到超過重 傳次數，封包便會被丟棄。TTL 為在限定期限內，封包無法送達到目的地。在確定連 通的道路比例越高時，使用 CP 的方法：Always-CP 和 Conn-CP 發生 RET 的次數會比 VADD 多，但可以找到更多在傳送期限內可以送達目的地的路徑，於是 TTL 發生的次 數較少，兩者相比 TTL 次數減少的量和 RET 增加的量相近，會增加在 TTL 時間內收 到封包的個數，傳輸成功率反而會比較高，但曲線相對位置沒有太大改變。Conn-CP 減少了控制封包的傳送量，讓碰撞情形稍少，所以傳輸成功率可以比 Always-CP 略高。
傳輸延遲
在傳輸延遲上可以看到隨著連通道路個數的比例變多，各協定的延遲都會下降，
因為在路徑的路段沒有車輛時，各協定就會經由這些連通的道路比較快到達目的地。
使用 CP 方法的封包傳送延遲可以比 VADD 下更低，最多可以下降 9%的傳輸延遲時 間。在道路情形沒有改變的情形下，延遲下降的情形不明顯，這是因為本來 VADD 封 包就可以行經車輛密度較高的路段，而我們只是能找到那些車輛密度變化大的道路，
如果車輛分佈情形和 VADD 在計算時使用的的歷史資料符合。沒有出現道路車輛數變 化劇烈的情況時，比較不出差異。因為所有協定的封包，在計算道路優先權時都會經 過同樣的道路。另外，Conn-CP 的延遲時間和 Always-CP 相近，可知在發現道路連通 時才做更新的動作也可以讓傳輸延遲降低，在道路連通時，封包可以快速通過路段，
這時才更新，可以讓經過更新資訊計算過後而變換路徑的封包，比較可能出現變換過 後延遲會降低的情形。原本的 Always-CP，可能會使封包變換路徑後，轉向延遲較長 的路徑。因為即使道路不連通封包也轉向，但不連通時表示這些道路有可能在傳送途 中還是會中斷，在道路上封包需要被攜帶在車輛上，或者經過傳輸和攜帶後還是停留 在路口區域內，延遲反而會增加。
協定負擔
我們分析在模擬中傳送的控制封包總量，以總位元數表示，比較各協定對於網路 造成的負擔。原本的 VADD 在行進途中只有定期發送的位置封包，這是為了知道鄰居 位置所必須的負擔。隨著車輛個數變多，會有些微增加。使用 CP 的方法需要多傳送封 包去探詢道路延遲和儲存動作，需要多一些負擔量。在 Always-CP 下，車輛會定期地 去執行探詢動作，所以會有額外負擔，在這邊看到增加的負擔量並沒有非常大，增加 的負擔約略是 VADD 的 20%。而使用 Conn-CP，可以降低控制封包總量，會比 Always-CP 降低 3~4%。
繞路封包佔總收到封包的百分比
這邊看的是和 VADD 相比，有多少比例的封包在傳送途中，因為得到即時資訊而 經過計算後，在決定道路優先權時，選擇傳往和 VADD 不同的路段，最後成功到達目 的地。可以看到在道路情形沒改變的正常情形下，大概是 10%的封包會變換路徑，但 此時這些封包造成的傳輸延遲有的比走 VADD 原路徑好，有的比走原路徑差。隨著已 知連通的道路比例增加，繞路封包的比例也會上升，也就是越多的封包因為即時資訊 而繞路。但這邊看來繞路封包的比例不會上升劇烈，最高比例就落在 13%~14%左右，
顯示繞路的情形可能還是有限。Conn-CP 的繞路封包比例稍低，因為其只有在連通情 形才會發送，所以影響的封包個數會較少。
繞路封包在延遲上的增進
我們取出那些在路徑選擇時，會行走和 VADD 不同路徑的封包，去看這些封包可 以比走 VADD 路徑的封包，延遲下降的秒數。在正常交通情形下，CP 方法並不能在 傳送延遲上增進，而且有可能因為控制封包變多，讓資料封包傳送途中可能碰撞次數 變多或者鄰居資訊不準確而導致延遲反而變差。在交通狀況有改變下，可以看到 CP 方法的延遲，可以下降 10~20 秒，Always-CP 下降的秒數會隨著連通道路個數的增加 而增加，可見連通道路越多，可以下降的秒數越多。而 Conn-CP 保守地只選擇那些連 通的道路去做更新，效果並不能隨著連通道路個數增多而上升。顯然在那些不連通的 道路去做更新得到的好處比只更新連通路段資訊的好處來得多。
在分析資料庫設計的正確性時我們利用 Monte Carlo 方法[34]來分析地圖配對的正確 性。我們從新竹市的經緯度座標裡隨機選擇了 300 個樣本。
分析方法由 Java 與 eclipse 實作。測試例子由數對(座標值，道路名)組成。驗證的方式 則是與 Google Maps 做比對。若相同則命中，反之則失敗。選擇 Google Maps 做為參考指 標的理由是一者其地圖正確性高，二者是我們的圖形介面採用的是 Google Maps 的離線地 圖。另外，在本實驗中，我們採用了 TWD97 的座標系統，此為交通部運輸研究所提供之 圖資資料。表二展示座標系統與投影方式的比較。
圖資提供者 座標系統 投影方式
Google WGS84 Mercator projection Taiwan IOT TWD97/TWD67 TM2
表二、座標系統與投影方式
實驗後發現，會有一些例子失敗，其主要原因有以下幾點: 其一，交通部運輸研究所提供 之地圖資料覆蓋率較低，其不包含道路寬度低於 6 尺的道路。因此我們無法取得其與 Google
Maps 相同之結果。其二，僅為其道路分為多段，而其道路實為同一條道路，其演算法並沒 有錯誤。其三則為座標轉換造成的誤差。實驗結果顯示，成功率為 88.67%。為提升更高成 功率，我們將擴展地圖分割方式。展示了擴展後的地圖結構。其中的數字是該區域內的道 路數。
圖二十二、延伸分割區域 在應用程式方面的開發，我們規畫了圖二十三的系統架構：
Client Server Database
圖二十三、應用程式規劃架構
Server 必須處理車輛上傳的 metadata 並做資料庫的管理和查詢，也可以針對較頻繁的 資料做快取的動作，以減少車輛間傳遞資料的流量。
在實作方面，利用一台server與三台平板做實驗，實作利用android平板電腦拍照與網路傳輸 的功能，並與server做溝通以達到街道即時預覽的服務。以下分別詳述server與client的流 程 。Server端: server會把client定期上傳的metadata記錄起來，並且接收client所發出的請求，
依照client所發出的query提供服務，圖二十四所示為server接收到請求的運作流程。a.起初 server為idle的狀態，當收到client發出的請求則尋找相對應的metadata是否存在。b.在搜尋後 發現不存在此metadata則回傳”can not find”給client端；反之則將搜尋到的metadata傳回給
client端，client端再發請求給檔案的擁有者。c.每個metadata都會有一個相對應的counter，
記錄此metadata被client所query的總和，所以當有client對某個metadata發出query時，則對應 的 counter 加 1 。 d. 當 metadata 所 對 應 的 counter 到 達 一 個 threshold 時， 則 認 定 此 file 比 較 popular，所以server會發出請求給擁有者，則server也會保留此檔案，以便未來在網路流量 的控制。
圖二十四、Server 處理流程
Client端:除了client會定期上傳自己所記錄的metadata之外，還能向server與檔案擁有者發出
Client端:除了client會定期上傳自己所記錄的metadata之外，還能向server與檔案擁有者發出