交易代幣式叢集化(Token-Based Clustering, TBC)演算法

3.2.1 TBC 演算法概念與設計

在一般的叢集化演算法中，通常都是選定節點上某個數值作為叢集化時選擇 叢集管理者之參考 (Basu, Khan, & Little, 2001)，如最小 ID 叢集化(Lowest ID Clustering, LIC)演算法是以節點 ID 作為叢集化時的參考，選擇 ID 最小的車輛作 為叢集管理者 (Ephremides, Wieselthier, & Baker, 1987)，而最高連接數叢集化 (Highest Connectivity Clustering, HCC)演算法則是考慮網路拓樸情形，以分支度 (Degree)最高的節點最為叢集管理者 (Gerla & Tsai, 1995)。

在 LCC 演算法中 (Chiang, Wu, Liu, & Mario, 1997; Yu & Chong, 2005)，無論 是使用 LIC 演算法或 HCC 演算法，應用在 VANET 環境中，仍有需要面對的問 題。首先，在使用 LIC 演算法的情形下，若是環境中有一車輛 ID 較其他大部分 車輛 ID 小時，因車輛 ID 並不會改變，則可發現此車輛容易持續擔任叢集管理 者，造成負擔比其他大部分車輛重，無法平衡各個車輛的負擔，若是在車輛密度 較高的環境中，可能會造成叢集管理者負擔過重，而無法有效的對叢集成員要求 作出回應。其次，若是有一 ID 較小的車輛進入了一個叢集，則叢集管理者將會 改變成此 ID 較小的車輛，在高密度的交通環境中容易造成不必要的叢集調整。

同上段所述，若是採用 HCC 演算法，也會有需要解決的問題。在 VANET 環境中，由於車輛移動速度很快，車輛節點間形成的網路拓樸容易快速且連續的 變動，造成需要不斷的改變叢集管理者。其次，若是在一個節點密度較高的環境 中，由於每一個節點分支度皆相當高，所以在叢集化時，分支度並不是相當好的 參考指標。

因為上述問題，所以本研究以 LCC 演算法為基礎，並加入了代幣交易機制 作為叢集化時的參考，提出了 TBC 演算法。車輛在加入環境中時，即配置一定 數量的代幣給該車輛，而車輛可以使用代幣向其他車輛購買路況資訊，而在車輛 購買路況資訊時，會依買方所持有的代幣數量與賣方的資訊品質計算交易價格，

並且再依車輛所持有的代幣數量進行叢集化，以持有代幣數量最高的車輛擔任叢 集管理者。

圖 20. TBC 演算法架構

如圖 20 所示，在 TBC 演算法中，主要可分為四個部分：

1. 初始化：

當車輛進入交通網路時所進行之初始化動作，如調整車輛狀態與配置預 設之代幣。

2. 叢集調整方法：

負責在交通環境中產生或移除叢集，也就是判斷車輛狀態是否該從叢集 成員改變為叢集管理者，而產生新的叢集，或是將車輛狀態由叢集管理

者改變為叢集成員，而移除舊的叢集。

3. 選擇封包傳遞對象：

車輛在自身所處叢集中，當需要發出查詢路況資訊等請求時，依其叢集 關係與地理位置，選擇車輛作為傳遞封包之對象。

4. 代幣交易機制：

再選定封包傳遞對象後，依本身買方之資訊更新時間與傳遞對象賣方所 擁有代幣數目計算交易價格。

關於以上所提到的 TBC 演算法之四個部分，每一個部份之詳細內容將在接 下來的小節中敘述。

3.2.2 初始化

演算法

initial(){

self.state←”cluster_member”

self.remained_token←100 }

說明

當車輛進入交通環境時，車輛之狀態為叢集成員，並隨即配置一定量之代幣 給自己，而在此實驗中，將進入系統車輛之代幣值設為預設值 100。

關於代幣之預設值，在本實驗中其實並不重要，因為無論代幣預設值高於或

低於整個交通環境中所有車輛代幣之平均值，也會因 TBC 演算法的特性中，擁 有較多代幣的車輛消耗代幣也會較快，而擁有較少代幣的車輛消耗代幣會較慢，

故可因此特性調整代幣從預設值至適合值。

3.2.3 叢集調整方法

演算法

generate_cluster_head(){

state result_value←”cluster_head”

for each vi ∈in_Transmit_Range(self)

if vi.state =”cluster_head”∨ self.remained_token<

vi.remained_token result_value←”cluster_member”

break end if end for each

self.state←result_value }

remove_cluster_head(){

state result_value←”cluster_head”

for each vi ∈in_Transmit_Range(self)

if vi.state =”cluster_head”∧ self.remained_token<

vi.remained_token result_value←”cluster_member”

break end if end for each

self.state←result_value }

說明

在 TBC 演算法的叢集調整方法中，主要依循 LCC 演算法中的調整規則，在 以下兩個情形時才會產生或移除一個叢集管理者車輛 (Chiang, Wu, Liu, & Mario, 1997)：

1. 產生叢集管理者：

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

2. 移除叢集管理者：

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

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

在 TBC 演算法中，當遇到 LCC 演算法所提出之兩個情形時，才會產生或移 除一個叢集管理者車輛，但是 TBC 演算法之叢集化參考值為代幣數目，而 LCC 演算法之叢集化參考值則為車輛 ID 或是分支度。

3.2.4 選擇封包傳遞對象

演算法

vehicle choose_transmit_target(){

vehicle v

if self.state = “cluster_head”

if in_Transmit_Range(self) != nil

v ← H-VADD(in_Transmit_Range(self)∩

is_cluster_member(Vehicles)) end if

end if

ifself.state = “cluster_member”

if in_Transmit_Range(self) != nil

v ← H-VADD(in_Transmit_Range(self) ∩ is_cluster_head(Vehicles)) end if

目的地的車輛。

3.2.5 代幣交易機制

演算法

double calculate_paid_token(){

return target.remained_token / degree(target) }

double calculate_returned_token(){

double paid_token

paid_token←target.remained_token / degree(target) return paid_token

}

說明

在 TBC 演算法中，最主要的精神就是將車輛的地理位置與路況資訊的更新 時間數值化成代幣數目，而讓有路況資訊需求的車輛花代幣購買這些資訊，愈接 近被查詢地點的車輛得到的路況資訊與愈新的路況資訊價格便愈高，而在本研究 中，關於代幣計算時，所參考之地理位置選擇方式主要是依據 VADD 演算法中 之混合型判斷方式(Zhao & Cao, 2008)。

當車輛所擁有之代幣數目愈多時，交換路況資訊時所花費的代幣數目也就愈 多，因為當車輛擁有代幣過多時，容易造成代幣累積不均勻，當此車輛因移動至 不佳的地點而不適合繼續擔任叢集管理者時，持有過多的代幣容易造成代幣機制 調整速度過於緩慢，無法適應快速變化的交通情形。當車輛之分支度愈高時，叢

集調整所影響到的車輛也就愈多，故在分支度較高時，所交易的代幣也就愈少，

讓代幣數目較為穩定，也可以提升叢集的穩定性。為了避免不必要的叢集調整，

故在本實驗以各車輛代幣數目為根據以調整叢集時，額外以一倍標準差值作為緩 衝值，使得不會因為極少數的代幣數目差異造成不必要的叢集調整。

如 3.1.4 小節所述，當車輛已經選定了一個目標車輛並對其傳遞查詢路況請 求之封包時，便會依買方車輛已擁有代幣數目與賣方車輛回應路況資訊之品質決 定此查詢路況資訊的交易價格。