第三章 研究方法
3.1 問題分析
3.2.1 以 RSU 為 node 的 Infrastructure-based Multi-layered Chord 架構 17
就會從中挑選出欲連線的 peer。假設我們選擇其中 connection lifetime 最長的 peer 來下載，一旦該 peer 正在與其它 peer 做傳輸，結果我們必需等待對方做完工作 後才能跟它連線，造成時間上面的浪費。因此我們會把節點手上正在進行的工作，
整併至 connection lifetime 的計算內，讓節點在選擇下載目標時，能挑選最合適 的節點。
3.2 研究方法
3.2.1 以 RSU 為 node 的 Infrastructure-based Multi-layered Chord 架構
當我們以純 ad-hoc 模式來做 p2p 檔案分享時，在做 file searching 的時候，
通常會採用 flooding 的方式，但這可能會使得網路上的 messages 過多，此外搜 尋的 peer 數有限，以致於比較不容易找到所要的檔案。而使用 Infrastructure-based 架構，利用 Chord 適合檔案搜尋的優點，讓我們有更高的機會可以找到需求的檔 案，同時也能保證在 O (log N) 個步驟中完成查詢的動作。基於上述理由，我們 採用文獻[4]中的 Infrastructure 架構並修改。由於考量到 vehicular network 中車輛 變動頻繁的特性，如採用 single ring 的 Chord 架構，會導致 finger table fault 過多，
所以採用 Multi-layered Chord 方式，做法是結合數個 RSU 成為一個 cluster，建 立 single ring 的 Chord，並於每個 single ring Chord 挑出一個 cluster head，在上 層串連為一個 superring，做跨 cluster 間的檔案搜尋。希望減少 search 的 hops 數 與維護成本，所以採用 Multi-layered Chord 的方式，該方法適用於市區的環境，
因此將以 UML-Chord (Urban Multi-layered Chord)為本論文的方法名稱。
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
Figure 3-2 為本論文提出方法的架構的示意圖。虛線下方是實際的網路情境，
三角型代表 RSU，上方則是架構於實際網路上的 overlay network。這裡有四個 clusters，同一 cluster 內的 RSU 節點由藍色圓圈串連成為一個 Chord ring，每個 RSU 分別管理所屬的車輛及檔案資訊。我們將(檔案-車輛)的配對資訊，存放於 各個 RSU 上，查尋時不需詢問行進中的車輛。圖中的粉紅色節點為各個 cluster 的 cluster head，由粉紅色線串連為上一層的 Chord，負責跨 cluster 之間的檔案 query，綠色的 RSU 節點則為 cp-head (car position head)，負責車輛位置資訊的管 理。整個運作流程簡單說明如下，左下角的 car1 想要尋找 Rebirth.mp3 的檔案，
在步驟 1 中，會先透過目前連線的 RSU，在 UML-Chord 中找尋檔案，依據 Rebirth.mp3 的 key 值，我們發現其資訊並非座落於自身的 cluster 內，因此透過 RSU C 跨至其它 cluster 去，最後在 RSU M 上找到 Rebirth.mp3 的資訊，有 car2、
car3 擁有該檔，接下來的步驟 2 則是透過 cp-head 的車輛資訊，去找到目前 car2、
car3 的所在位置，向其要求檔案。
Figure 3-2 UML-Chord 架構
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
19
3.2.2 車輛位置資訊管理
當我們在前述的 Multi-layered Chord 中找到擁有所需檔案的車輛後，便要從 該車輛取得所需檔案。為了增進搜尋車輛位置的效率，我們沿用前一小節的 Chord 分群，即每個 single ring Chord 所包含的 RSUs 為同一個 cluster，尤於考量 到每個 cluster head (如 Figure 3-3 中的紅點)會有比較高的 overhead，故我們從 cluster 內的其它 RSUs 中挑出一個，作為 cp-head (如下圖中的棕色點)，即為管理 車輛位置的 cluster head。每個 cp-head 都會掌握該 cluster 內的所有車輛位置，以 及 connection lifetime 等相關資訊，當有其它群的查尋來拜訪時，如下圖的棕色 箭頭，均會透過本群 cp-head 來擷取資訊。同樣的當本群要向它群查尋時，也會 連至該群的 cp-head，如綠色箭頭所示。
Figure 3-3 車輛位置分群示意圖 3.2.3 將路口等待的要素納入 Connection Lifetime 中
在節點眾多的市區環境中，汽車因交通號誌而等待的情形非常普遍，我們將
‧
前面討論的紅燈時間資訊納入 connection lifetime 的考量中。此外，在公式 2-2 中有考慮到道路速限，亦即汽車加速達到速限值時，速度就不再上升，因此我們
stop_start：紅燈開始的時刻
stop_end：紅燈結束的時刻
‧
connection ifetime=
{
考量 RSUs 需要管理 Multi-layered Chord 及車輛位置資訊，所以我們把 connection lifetime 的計算交由車輛節點處理，並且註記 timestamp，存放於 RSUs 上。
3.2.4 搜尋車輛資訊的回傳機制
當節點下了一個檔案 query 到我們的 p2p 網路上，經過查尋的過程後，得到 擁有該檔案的車輛清單會傳至原來的節點，之後再去尋找各車輛的位置，進而取 得我們所要的資訊後，再回傳給原始的節點，如此一來一往的傳遞，會造成許多 不必要的時間延遲，降低整個 p2p 系統的效能，所以這邊所採用的方式是，當我
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
們透過 Multi-Chord 找到檔案時，把得到的候選清單，即刻送到網路上去查尋，
收集他們的相關資訊後，傳送到原始節點手中，如下圖所示。
Original Node Multi-Chord (overlay network) ready to
search file query search file
car list
searched cars information donwload
file
results return
Figure 3-4 query 結果傳遞修改流程圖
針對前面 3.1.4 所提出的問題一，我們可以設定一個時間門檻(預設為 0.5 秒)，該 原始節點可以不需等待收集到所有目標節點的資訊，就目前所得的節點資訊來做 進一步的下載挑選動作。但如果我們的候選清單中只有一個車輛，原始節點別無 其它的選擇，所以門檻值應該較大，改為 1 秒。另一方面，若我們得到過多的清 單節點，將採擁有最高 connection lifetime 前五個節點傳送，不要一次全部性地 搜尋來減少送出的查尋資訊量。
以下為此部分之 pseudocode：
‧
getCarList to be download;
if sizeof(CarList) = 1 //
候選清單只有1
個節點setwait_threshold to 1 ;
storeCarList in list SendList;
end if;
else if sizeof(CarList) > 5 //
候選清單多，選CLtime
最高的五個setwait_threshold to 0.5 ;
select the five highest CLtime node of CarList ; store in list SendList;
end if;
else if 5 >= sizeof(CarList) > 0 //
候選清單內有0~5
個節點begin
setwait_threshold to 0.5 ; //
設定等候門檻值，並選擇storeCarListin list SendList;
end if;
sendSendList to transfer files;
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
若某節點當下正在上下載檔案，我們會將預估所需剩餘的傳送時間，從原本的 connection lifetime 中扣除，並回報告 RSU。因此之後其它節點在挑候選節點的 步驟時，便依據修正後的 connection lifetime 作來源節點的挑選工作。
以下為此部分之 pseudocode：
RSU
端:
when receiving car msg
if msg is query //
判斷收到的msg
種類search in Chord;
end if;
if msg is position update if self RUS is cp-head
updateCLtime;
end if;
else //
若自身非cp-head
，轉送給cp-head
send this msg to cp-head of this cluster;
end if;
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
25
3.3 系統架構
綜合前面的內容，我們整合出系統的流程圖，接下來對整個流程做說明。如 圖 3-5 所示，只要車輛執行本系統後，就會不斷更新自身的訊息或上下傳檔案，
等到關閉軟體或是熄火就離開系統。我們可以將整個系統分成三個部份：
Multi-layered Chord、connection lifetime 計算以及最後的傳檔階段，下面將分別 針對做說明。
車輛端：
when catching RSU (j)’s broadcast beacon begin
calculateCLtime
if this car has current download traffic //
若本身已有下載任務，對CLtime
做修正CLtime
←CLtime– remaining download time;
returnCLtime to RSU( j);
end if;
end
‧
cars send file query To Chord
search files in Chord
get the car list of file
get car
request file
from the cars transfer file return not
find file
cars update position、file list、download status to
RSUs Start
driving
if car wants to search file on the
network
‧
cars send filequery To Chord
search files in Chord
get the car list of file
found return not
find file message
not find
if car wants to search file on the
network yes
Figure 3-6 Multi-layered Chord 流程圖
Figure 3-6 是 Multi-layered Chord 的部份，當節點決定要尋找 vehicular network 上的檔案時，便會透過其所在的 RSU，在第一層的 single ring Chord 結 構裡做檔案搜尋，若搜索不到則利用從該層的 cluster head 跳到上一層的 superring 去找尋，若還是沒找到就代表目前整個 vehicular network 上並無該檔案。當找到 檔案後，我們會進一步得到儲存於該 RSU 上面的 (檔案-所有車輛) 的配對資訊，
而這些車輛就是我們下載候選清單的成員們。
calculate connection lifetime
cars update position、file list、download status to
RSUs
car information stored on RSUs
Figure 3-7 Connection Lifetime 計算
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
Figure 3-7，車輛計算自身與 RSU 間的 connection lLifetime，我們利用車輛定期 把自己更新位置上傳給 RSU 的時候，把剛才計算完畢的 connection lifetime (附加 timestamp)，還有如檔案更新的資訊，以及上下載狀態，統統整併一次送給 RSU，
避免過多的傳送，降低無線電資源的使用效率。
get car information
from RSUs
pick the most fit cars to download file
request file
from the cars transfer file
Figure 3-8 傳檔階段
最後一部分如 Figure 3-8 所示，我們會從下載候選清單中車輛節點所在的 RSUs 中取得前部分所提的資訊，如 connection lifetime、上下載狀態等，挑出最 適合的節點來下載，進入最後的檔案傳輸階段。
‧
本研究採用 Network Simulator 2.35 (NS-2)[10]模擬，它能模擬真實世界的網 路架構環境，並使用內建的 Iango Purushothaman's IEEE802.11infrastructure mode，
可讓 AP 間可透過有線網路互相溝通。另外使用 SUMO (Simulation of Urban Mobility) [11]及 MOVE (MObility model generator for vehicular networks)[12]，產 生雙向共四線道所組成的棋盤式地圖，其中包含交通號誌及車流，建置我們的市
車輛數 200,300,400,500,600,700,800 網路拓樸大小 2,500m x 2,500m
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
Figure 4-1 為 SUMO 的道路環境圖，由 5x5 個 block 所組成之市區棋盤式街 道，其中每個 block 長寬各為 500 公尺，每個路口皆設置交通號誌，時間為 60~90 秒不等。
Figure 4-1 SUMO 道路環境圖
接下來我們依照前面的環境，加入實際車流後，將 SUMO 產生之 tcl 檔以 NS-2 執行，Figure 4-2 為 Nam 的車流模擬圖呈現結果。
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
31
Figure 4-2 NS-2 Nam 車流模擬圖
4.2 評估指標
對於實驗的評估，採取 number of hops、message overhead、delay time、
download time、file complete ratio 做為我們的評估指標。
Number of hops：當我們在做檔案查詢時所經過的 hop 數目，此部分所經過 的 hop 數在 overlay network 中與實際相同。
Message overhead：為維護 Chord overlay network、檔案查詢、車輛位置管理 及檔案下載分配的 control message。
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
Query delay time：從車輛送出檔案查詢開始下載的時間，其間包括車輛資搜 集。
Download time：從車輛節點送出檔案查詢到獲得該完整檔案的時間。
File completion ratio：完成檔案下載的比例。
4.3 實驗結果與分析
實驗將 p2p 的運作分為兩個階段，第一是檔案搜尋階段，第二個是檔案傳 輸。
4.3.1 檔案搜尋
我們先比較 UML-Chord 與 Chord、Overlay-based[8]在不同 RSUs 與不同車 輛數下，query 所需的 hops 數。在以下的 Tables 中，Chord、Clustered organization 與 Overlay-based 的內容分為右左兩欄，左欄為該表格所比較的數據，右欄為與 本論文的 UML-Chord 與之比較後的改善百分比例
Figure 4-3 和 Table 2 為兩種 Chord 架構與 Overlay-based 在不同 RSUs 下的 query hop 數比較。Chord 的搜尋複雜度為 log n，故當我們增加做為 chord 節點的 RSUs 後，會造成 query hops 數的增加。由圖表結論可以看出，因為 UML-Chord 使用了 multi-layer 的 Chord，因此在平均 query hops 數上較未分層的 chord 減少 了 17%。另外由於 Overlay-based 的結構無法較有效率地搜尋檔案，所以 query hops 會隨著 RSU 的增加(亦即網路規模擴大)而提高，此部分 UML-Chord 平均好上 25%。
‧
query hop 數比較。。也因為 multi-layer 的關係，UML-Chord 在平均 query hops 數上較未分層的 chord 及 Overlay-based 分別減少 15%、26%. 另外 query hop 數Number of RSUs
UML-Chord Chord Overlay-based
20 3.20 3.30 3.03% 2.40 -33.33%
Number of Hops (per query)
Number of RSUs
UML-Chord Chord
Overlay-based
‧
Number of cars
UML-Chord Chord Overlay-based
200 3.50 4.10 14.63% 4.60 23.91% 案查詢、車輛位置管理及檔案下載分配的 control message，結果如 Figure 4-6 及 Table 4 所示。由於 UML-Chord 方法會將車量資訊的更新集中在 cp-head 上，不 同於 clustered organization [8]，為達到動態調整 clustered 的組成成員，而讓每個
2.00 3.00 4.00 5.00 6.00
200 300 400 500 600 700 800
Number of Hops (per qurey)
Number of cars
UML-Chord Chord
Overlay-based