叢集調整次數

在本小節中，將會在本實驗的每一回合中，當叢集調整發生時，會將 Cluster_Re-formation 變數加 1。在實驗結束後，Cluster_Re-formation 變數即為總 共發生之叢集調整次數。如同在 3.2.3 小節中所提到的，車輛在兩種情形下會進 行叢集調整：

1. 產生叢集管理者：

當一個狀態為叢集成員的車輛之可傳輸範圍內不存在狀態為叢集管理 者的車輛時，將會檢查自身所擁有的代幣數是否高於所有臨近車輛之代 幣數，若是自身所擁有的代幣數較高時，則將自身狀態修改為叢集管理 者。

2. 移除叢集管理者：

當一個狀態為叢集管理者的車輛之可傳輸範圍內存在狀態為叢集管理 者的車輛時，將會檢查自身所擁有的代幣數是否高於該叢集管理者車輛，

若是自身所擁有的代幣數較低時，則將自身狀態修改為叢集成員。

當叢集管理者改變的次數越少，則花費在管理叢集的封包數目則越少，

也是在實驗中需要比較 TBC 演算法與 LCC 演算法在不同的比例下，所需要執行 叢集調整之次數之原因。

下圖 24 至 26 分別為在交通環境中車輛密度由低至高時，在不同車輛比例之 情形下，使用 LCC 演算法與 TBC 演算法產生叢集調整次數。

圖 24. 叢集調整次數(低密度)

圖 26. 叢集調整次數(高密度)

由圖 24 可以得知，當車輛密度與比例都極低時，使用 LCC 演算法所產生的 叢集調整次數少於使用 TBC 演算法，這是因為在較少車輛使用動態路徑規劃方 法之情形下，車輛之間平均距離較大，不容易發生較小 ID 車輛進入其他叢集後 產生之無意義叢集調整。而 TBC 演算法由於計算代幣，會造成計算上較複雜，

且反而不如簡易的 LCC 演算法所產生叢集穩定。

雖然在車輛密度羽比例較低時使用 LCC 演算法之效能較佳，但是當車輛密 度或比例較高時，系統才會真正需要降低負擔。如圖 24 至圖 26 之實驗所示，當 車輛密度或比例較高時，使用 TBC 演算法所產生的叢集調整次數少於使用 LCC 演算法，故在真正面對有降低系統負擔之需求時，TCB 演算法能較有效的降低 叢集調整次數，使系統之額外負擔降低。

由於 TBC 演算法是使用 H-VADD 演算法，參考實際地理位置與資訊更新時 間後，作為交換代幣之根據，且會依車輛之代幣數目決定有何車輛擔任叢集管理 者，所以會選出最常收到與回應查詢路況請求之車輛作為叢集管理者，故相比於 LCC 演算法，TBC 演算法較不需要改變叢集管理者即可有效的減低通訊的額外 負擔。