問題與討論

在這個小節中，我們將分別描 NS-2.34 的 802_11Ext 模組及 WirelessPhyExy 模組所遭遇的 問題。另外，我們也將探討，為什麼我們在模擬實驗中沒有加入 Simple Broadcast Protocol 來 做分析比較。

5.6.1 NS-2.34 中使用 802.11p 所遭遇的問題

在使用 NS2 的模擬過程中，為了要能夠順利運作 IEEE 802.11p，我們利用 NS-2.34 上所附 加的 802_11Ext 模組及 WirelessPhyExt 模組，並且利用 NS-2.34 所提供的 IEEE 802.11p 的 TCL 參數設定(路徑：/ns-allinone/ns-2.34/tcl/ex/802.11/IEEE802.11p.tcl)，來啟動 IEEE 802.11p 以進 行模擬實驗。但是，在進行實驗及模擬的過程中，我們卻發現該模組出現了一些問題，導致模 擬實驗沒辦法取得正確的數據資料。基於這個原因，因此，我們準備了另一個 MAC 模組 802_11 來進行模擬實驗。而使用 802_11Ext 及 WirelessPhyExy 模組時，所遭遇到的問題整理如下：

我們使用該模組進行模擬實驗時，發現某些節點無法正常接收 packet 的問題。由於所執 行的模擬實驗繁多，我們僅以 tcbp_nn80_s20.tcl 所產生 tr_tcbp_fwy25_nn80.tr 的為例子來描述 所面臨的問題。此外，由於模擬實驗的節點數量及 tr_tcbp_fwy25_nn80.tr 所產生的資料量繁多，

礙於篇幅限制及方便描述，我們透過幾個關鍵的資料及節點，如圖 5-23 中，node 20、node 48 進行問題描述。

圖 5-23：模擬環境中的節點位置

100

圖 5-24：tr_tcbp_fwy25_nn80.tr 中節點廣播 packet 的情況

圖 5-25：tr_tcbp_fwy25_nn80.tr 中節點接收 packet 的情況

首先，我們透過 tr_tcbp_fwy25_nn80.tr 擷取 node 20 及 node 48 的位置描述，所擷取出的 資料如圖 5-23 所示，我們可以清楚觀察到 node 20 及 node 48 彼此正在相同的無線傳輸範圍內 (環境中的無線傳輸範圍為 200m)。透過 tr_tcbp_fwy25_nn80.tr 可以清楚看到，node 20 於時間 1.001100872 廣播 packet ，如圖 5-24 所示；而在 tr_tcbp_fwy25_nn80.tr 中，如圖 5-25 所示，

我們可以看到在 node 20 傳輸範圍內的某些車輛都能確實接收到來自 node 20 所廣播的 packet，

但我們卻沒有觀察到 node 48 接收到 packet 的紀錄。實際上，不只 node 48 沒有接收到 packet，

還有一些節點也在 node 20 的無線傳輸範圍內，卻無法正確接收 packet，導致所模擬出的數據 會有誤差。另外，我們也檢查了 trace 檔各階層的 log，也沒有發現任何節點掉包的 log 出現。

而以相同的模擬場景，我們利用 NS2 舊有的 802_11 模組進行模擬實驗，在相同場景下卻 可正常執行，節點能夠正常的運作且正常接收 packet，並不會發生上面所描述的問題；因此，

101

在我們的模擬實驗中，我們額外使用了 802_11 模組進行模擬比較，藉以取得正確的數據資料，

公平比較所有的方法。

5.6.2 未加入 Simple Broadcast Protocol 實驗模擬之問題討論

在本論文第五章節中，我們分別比較了 flooding method、ACK-based Broadcast Protocol、

Fault-Tolerant Broadcast Protocol 及 Farthest Node First Protocol 的效能分析，但卻獨缺 Simple Broadcast Protocol。原因在於 Simple Broadcast Protocol 的方法是屬於 Data Link Layer 的方法 (RTS/CTS 機制)，使用到底層的 control message 讓鄰居節點競爭並挑選出 relay vehicle。而本 篇論文的方法與所比較的方法，都是屬於上層的方法(application layer)來散播警告訊息。為了 比較使用 application layer 的方法之間的效能。因此，我們沒有將 Simple Broadcast Protocol 的 方法考慮到模擬實驗中。

102