泛流機制相關研究探討

1. 基本泛流(Simple Flooding)：

當節點收到可傳輸範圍內其他節點傳送來的封包時，會先查看封包中的 TTL(Time to Live)值，TTL若是大於零即為有效封包，收到封包的節點就會 查詢其歷史紀錄是否已接受過此封包，若是第一次接收的封包，才繼續將此 封包之TTL值遞減再傳遞出去，直到TTL值歸零時，收到封包的節點才不再

繼續傳遞資料給其他節點 (Dube, Rais, Wang, & Tripathi, 1996)。

此種基本泛流方法雖然簡易，但若是處於一個節點之間都非常接近的無 線網路環境中，由於節點密度過高，造成容易在短時間之內收到大量的廣播 封包，使封包之間容易產生碰撞與競爭，進而導致大量的封包被重傳，所以 持續造成封包不斷碰撞與重傳之惡性循環，也就是廣播風暴問題(Tseng, Ni, Chen, & Sheu, 2002)。

針對廣播風暴問題，許多研究中提出了利用不同的系統架構或環境參數 來降低發送廣播封包的次數，以避免廣播風暴的發生。接下來的介紹的其他 機制即是為了解決此問題而被提出。

2. 機率機制 (Probabilistic Scheme)：

基於基本泛流之傳播決策方式，但是在節點接收到封包時，首先產生一 個介於0至1之間之機率亂數，再將其與系統規定之臨界值比較，若此機率亂 數大於臨界值則再依基本泛流機制傳送此封包。

此種機制之實用性完全取決於臨界值的選擇，若臨界值太大，則容易造 成封包傳遞距離過短；但若臨界值太小，則幾乎每一個封包都會被判斷可以 繼續傳輸，造成機率機制完全沒有產生防止廣播風暴的效用。即使找到一個 最適合系統狀況的臨界值，但由於是根據機率產生決策，仍然有機會發生廣 播風暴或是封包傳遞距離過短。

3. 計數機制 (Counter-Based Scheme)：

由於純以機率決定是否傳遞封包有以上提到的缺點，所以可以仿照一般 無線網路中之作法，在收到需要廣播的封包之後並不立即廣播，而是等待系

統中之倒數器產生一個亂數時間並開始倒數，在倒數完成前若是收到重複的 封包，再產生一個臨界值，當倒數到達此亂數時間之後，收到重複封包的數 量若小於臨界值，則視為沒有廣播風暴現象而傳送此封包；若是收到重複封 包的數量大於臨界值則相反，不傳送封包。

對於此臨界值的設定，可以經由分析無線網路的環境提出了以依節點通 訊範圍與覆蓋範圍作比較(Tseng, Ni, Chen, & Sheu, 2002)，並就時間內收到 封包的數量與覆蓋範圍之關係，作為設定臨界值的標準。

4. 距離機制 (Distance-Based Scheme)：

在此方法中以距離取代時間作為主要的判斷依據 (Dube, Rais, Wang, &

Tripathi, 1996)。距離機制主要依收到封包之訊號強度，用以 換算封包來源節 點的距離。當接收到重複的封包時，若是接收到的重複封包距離過於接近而 小於系統規定的臨界值，則不會繼續廣播此封包；若是封包距離大於臨界值 則繼續廣播之。

5. 位置機制 (Location-Based Scheme)：

與距離機制類似，但是將判斷節點間距離的來源由封包強度改為額外的 附加工具，如透過全球衛星定位系統(Global Positioning System, GPS)取得節 點之絕對位置，再依幾何方法算出兩點之間的距離，並使用前段所提之距離 機制進行決策，判斷是否要廣播封包。

6. 鄰近節點機制 (Neighbor Knowledge Scheme)：

在每一個節點中皆建立一張鄰居表，記錄所有在可傳輸範圍內之節點ID。

若是接收到封包並需要加以廣播時，比對自己的鄰居節點是否是封包來源的

鄰居節點，若為兩者之鄰居節點則不傳送封包 (Lim & Kim, 2000)。

以圖4為例，雖然節點B接收到了來自發送端節點S之封包，並要再廣播 出去，但因節點A與節點C亦同時為節點B與節點S之鄰居，且只有節點B能 傳送封包制節點D，故節點B只會負責廣播資訊給節點D，而不會廣播資訊 給節點B與節點C。

圖 4. 鄰近節點機制與資訊散佈關係

7. 叢集化機制 (Cluster-Based Scheme)：

此機制主要是藉由蒐集鄰近節點之封包，並利用節點所發出的封包之標 頭檔案(Header)資料取得來源節點ID。在一定區域ID最小的車輛會擔任叢集 管理者(Cluster Head)，管理 叢集(Cluster)內部的訊息管理與對外之訊息傳遞，

而其他非叢集管理者之節點則被稱為叢集成員(cluster member) (Basu, Khan,

& Little, 2001)。若是一個叢集成員同時處在兩個叢集之間，則會成為兩個叢 集之溝通管道，負責分配與調控叢集間的封包往返，稱為叢集閘道(Cluster

Gateway)。下圖5即為叢集架構示意圖。

圖 5. 叢集架構示意圖

由於此種叢集化機制依貪婪演算法選出叢集管理者，可能會因為叢集管理者 實際地理位置或與其他車輛之相對位置，造成仍有不必要的訊息傳遞產生，這也 是本論文計畫要改進之處。