可應變式接手節點挑選

本文認為最佳 Next-Hop 節點會根據使用者所需資料傳輸類型提供 QoS 需求 的服務，考慮鏈結存活時間及頻寬的權重係數關係，以供不同的資料傳輸類型在 傳輸資料時能依不同 QoS 類型來挑選最佳的接手節點。

在本論文所使用的 QoS 類型是指資料傳輸類型若是即時性應用服務，則歸 類為 CBR 類型，如語音(Voice)、On-Line Game 等應用服務；若為非即時性應用 服務，則歸類為 FTP 類型，如 E-mail、檔案傳送之應用服務等。

當來源節點要傳送資料封包時，會依據資料類型，可能為即時性(Real-Time) 或非即時性(Non-Real-Time)應用服務，來尋找適當的接手節點。此外週期性的接 收 Hello Message，因此可得知鄰居節點的位置、速度和方向等資訊。來源節點 透過以上節點位置資訊，計算出鏈結存活時間與頻寬，再依據資料傳輸類型取得 計算出具最大權重值 wi的節點來作為接手節點，以利資料的繼續傳送，如 Figure 3.3 所示。

w

¹

a

b c

d w

²

w

³

Figure 3.3：選擇最佳 Next-Hop 節點

為了減少控制訊息成本，本論文是採用 Reactive(On-Demand)路由協定方式，

只有在來源節點有資料需要傳送時，才會開始尋找接手節點。此外，本文會先假 設每輛車皆已配置 GPS 衛星定位系統，讓每輛車可以記錄自己的移動方向及速 度等位置資訊。節點之間會週期性廣播 Hello 訊息，以更新路由表中的鏈結存活 時間、頻寬和位置資訊，並計算出權重值。讓來源節點可依據所使用的 QoS 類 型來挑選具有最大權重值的節點作為接手節點。權重值結果的計算是考慮了鏈結

24

存活時間及頻寬兩種因素(請參閱 3.4.1 節、3.4.2 節)，所以本文將權重值的公式 呈現如公式(3.9)。

W = α*Link Lifetime + β*Bandwidth

(3.9)

其中α+β=1。然而本文觀察頻寬評估方式最後會以級距呈現，而非一個絕對數值，

因此權重值計算後的結果會使鏈結存活時間之值恆大於頻寬之值，在 4.3.4 節實 驗模擬中本文將公式(3.9)表示為未正規化來呈現，結果顯示改善效果會近似於 DGR 路由協定。

因此本文使用正規化(Normalization)方法來調整 Link Lifetime 及頻寬計算，

以利權重值(W)結果的計算，如公式(3.10)。

W = α*(Link Lifetime/Max of Link Lifetime) + β*(Bandwidth/Max of

Bandwidth) (3.10)

公式中鏈結存活時間與頻寬之間不一定維持正比關係，因此要分別乘上一個權重 係數α 和 β，兩者的關係為 β=1-α，α 介於 0~1。若希望尋找接手節點是鏈結存活 時間較長的節點，則可以將α 調整較大些，例如：0.6~1 之間；反之，若對於頻 寬需求較明顯的節點，則將β 值調大一些。然而，VANET 環境的不同，權重係 數也會有所影響，為此在 4.3.1 節及 4.3.2 節中實驗模擬本文會針對兩種移動模型 分別實驗權重係數。

本方法尋找路徑方式的階段可分為：Hello 訊息廣播階段、Route Request、

Route Reply 及 Route Maintain 階段，依序介紹運作方式如下：

 Hello 訊息廣播階段：節點之間帄時會廣播 Hello 訊息，以隨時更新位置資 訊，記錄節點鏈結存活時間與頻寬並計算出權重值。Figure 3.4(a)為來源節 點廣播 Hello 訊息狀態，所有鄰居節點收到 Hello 訊息後，會在路由表中記 錄節點 ID 和位置及速度資訊。Figure 3.4(b)為鄰居節點廣播 Hello 訊息狀態，

來源節點收到 Hello 訊息也會在路由表中記錄所有鄰居節點 ID 和位置資訊

25

及速度，計算鏈結存活時間及頻寬，並進行權重值計算。

 Route Request 階段：本論文提出尋找接手節點的機制是當來源節點廣播路 由請求(RREQ)訊息給傳輸範圍內的鄰居節點後，若鄰居節點為目的節點則 接收 RREQ 訊息後直接回傳 RREP 訊息，來源節點收到 RREP 訊息後會計 算權重值。若接收 RREQ 訊息的鄰居節點為中間節點，中間節點會記錄來 源節點所需要的 QoS 類型，並回傳 RREP 訊息給來源節點，來源節點收到 RREP 訊息後再計算權重值。當鄰居節點收到 RREP 訊息會保留權重值最大 的節點作為接手節點，若鄰居節點權重值有更大者，則更新路由表。若傳輸 範圍內沒有鄰居節點存在，待轉送的資料封包就先儲存於來源節點。舉例如 下：當來源節點 S 要傳送資料封包時，會先廣播傳送路由請求(Route Request；

RREQ)訊息，尋找有記錄到達目的節點之鄰居節點，RREQ 訊息中記錄來源 節點需要使用的 QoS 類型，以告知鄰居節點使用的資料傳輸類型，鄰居節 點收到後也會記錄於路由表中，並繼續傳送 RREQ 訊息，直到目的節點為 止，如 Figure 3.4(c)。

 Route Reply 階段：接收 RREQ 的鄰居節點若是目的節點或是權重值最大的 節點，節點接收 RREQ 訊息後會記錄 QoS 類型於路由表中，並透過反向路 由(Reverse Route)回傳 RREP 訊息回來源節點。若鄰居節點還在傳輸範圍內，

則更新路由表。若鄰居節點離開來源節點的傳輸範圍，則丟棄 RREQ 封包。

RREP 的傳送過程中也會建立轉送路由(Forward Route)以供來源節點傳送資 料封包使用。舉例如下：接收 RREQ 的鄰居節點若是目的節點或是權重值 最大的節點，節點接收 RREQ 訊息後會記錄 QoS 類型於路由表中，並透過 反向路由(Reverse Route)回傳 RREP 訊息回來源節點。若鄰居節點還在傳輸 範圍內，則更新路由表。若鄰居節點離開來源節點的傳輸範圍，則丟棄 RREQ 封包。RREP 的傳送過程中也會建立轉送路由(Forward Route)以供來源節點 傳送資料封包使用。最後當來源節點收到來自鄰居節點的 RREP 後，會計算 權重值並挑選權重值最大的鄰居節點作為接手節點。當路徑中的接手節點皆 找到時，來源節點即可開使利用此路徑傳送資料封包，如 Figure 3.4(d)。

 Route Maintain 階段：鄰居節點會週期性廣播 Hello 訊息，若正在通訊的來 源節點沒有收到 Hello 訊息，表示節點已經離開傳輸範圍或故障，則回到路

26

由請求階段。

Figure 3.4(a)：Broadcast Hello Message Figure 3.4(b)：Received of Hello Message

Figure 3.4(c)：Send RREQ Message Figure 3.4(d)：Received of RREP Message

3.4.4 方法虛擬碼

上述提出方法的階段最後用 Pseudo-Code 表示如下：

Algorithm 1：Broadcast Hello Message Step

1: all node periodic send Hello_msg

2: update location information 3: call calculate Link_lifetime( ) 4: call calculate Bandwidth( )

Algorithm 2：Route Request Step

Notations:

loc

s：the location for source node

vs：the speed vector for source node

27

loc

i：the location for neighbors node

vn：the speed vector for neighbors node neighbor

i：the ith neighbor

D

(s,i)：the distance between source node and neighbors node

NextHop：the node selected as Next-Hop

MaxW

i：the maximum weight value of the neighbor node 1: //當來源節點有資料要傳送時

2: broadcast RREQ_msg for all neighbors node do 3:

D

(s,i) = distance(locs, loci)

9: return RREP_msg to Source_Node 10:

Algorithm 3：Route Reply Step

1:

if the Neighbor_Node is Destination_Node or have maximum W

2: received the RREQ_msg and record QoS type in routing table 3: generate RREP_msg return to Source Node

4: Neighbor_Node rebroadcast and if the node is within the transmission range 5: update Route Table

6:

else

7: drop RREQ_msg 8:

end if

Algorithm 4：Route Maintain Step

1: all node periodic send Hello_msg

28

2:

if no received the Hello_msg for Source_Node

3: return Algorithm 2

4:

end if

Algorithm 5：Procedure Weight Value( )

Notations:

data_type：the transmission type for source node

1:

if vs <= 50 and vn <= 50 //Manhattan Mobility Model

2: if data_type = CBR

3: call Link_lifetime( ) 4: call Bandwidth( )

5: Wi

=α*Link_lifetime +β*Bandwidth

6:

end if

7:

if data_type = FTP

8: call Link_lifetime( ) 9: call Bandwidth( )

10: Wi

=α*Link_lifetime +β*Bandwidth

11: end if

12: end if 13:

14: if vs > 50 and vn > 50 //Freeway Mobility Model 15: if data_type = CBR

16: call Link_lifetime( ) 17: call Bandwidth( )

18: Wi

=α*Link_lifetime +β*Bandwidth

19: end if

20: if data_type = FTP 21: call Link_lifetime( ) 22: call Bandwidth( )

23: Wi

=α*Link_lifetime +β*Bandwidth

24: end if

25: end if

3.5 路由協定之比較

本小節，將本論文提出方法與相關方法路由協定依序在路由協定類型、接手 節點挑選方式、週期性廣播的訊息、支援移動性的能力及合適的網路模式項目下 做比較，結果整理如 Table 3.2。

29

Table 3.2：Comparison of Routing Protocol Position-Based? Reactive? Next-Hop

Selection

Periodically Broadcast

Mobility Support

Suitable Mode AODV[27]   Hop Count Hello Medium MANET GPSR[28]

 

The Node Closest to Destination

Beacon Medium MANET

DGR[29]

 

Combine Position and Direction

Beacon High VANET

Proposed

 

Link Lifetime and

Bandwidth

Hello High VANET

30

第四章 實驗模擬結果與分析

4.1 實驗環境與設定

本論文使用 NS-2 網路模擬器(Network Simulator Version 2；NS2)[32]作為模 擬環境。為了模擬 VANET 環境，本論文使用 Manhattan[33]及 Freeway[33]移動 模型。其中，Manhattan 移動模型中同樣假設車輛是隨機分佈在預設的地圖上，

並以網格狀的街道環境呈現，橫向與縱向各有四個路口，每個路口相距 250 公 尺，車輛行至路口會隨機決定是否要左轉、右轉或直行，左轉、右轉、直行的 機率各為 0.25、0.25 及 0.5，考量道路的限速，並設定車輛帄均速度設定從 10 到 50km/hr，使用 NAM[32]輸出的結果如 Figure 4.1。此外，Freeway 移動模型中 假設車輛隨機分布在預設的地圖上，地圖設定是一個類似高速公路的道路環境，

總共分為四線道，其中兩條是北上路線，另兩條為南下路線，長度為一公里。

考量高速公路的限速，本文設定車輛帄均速度設定從 70 到 110km/hr，使用 NAM[32]輸出的結果如 Figure 4.2。以下實驗之模擬參數如 Table 4.1。

Figure 4.1：Manhattan 移動模型(Mobility Model)[33] Figure 4.2 ： Freeway 移 動 模 型 (Mobility Model)[33]

31

Table 4.1 模擬參數 Parameter Value Simulation Time 200s

Area

Manhattan：1000m x 1000m Freeway：300m x 1000m

Vehicle Speed

Manhattan：10~50km/hr Freeway：70~110km/hr Vehicle Numbers 20~100

MAC Protocol 802.11 Bandwidth 2Mbps Transmission Rate 512kbps Transmission Type CBR、FTP Transmission Range 250m Session Numbers 5、10

4.2 效能評估項目

本小節會定義本研究方法效能表現之評估項目，並與其他現有路由協定進行 比較。為評估本論文提出方法的表現，定義的評估項目包括封包到達率(Packet Delivery Rate)、帄均延遲時間(Average End-to-End Delay Time)、控制訊息成本 (Signaling Overhead)，分別介紹如下：

 封包到達率(Packet Delivery Rate)：為模擬過程中所有目的節點接收到的封 包總數除以來源節點送出的封包 總數。是指目的地節點所接收到的資料封包 數目，與來源節點所發送出之資料封包數目的比例，為判斷來源節點是否正 確無誤地將資料封包傳送到目的地節點的指標。比例愈高代表路由機制的效

32

能愈好，計算方式如式子(4.1)。

Packet Delivery Rate

(4.1)

 帄均延遲時間(Average End-to-End Delay Time)：為模擬過程中所有來源節 點所產生的資料封包傳送到目的節點所花費的帄均時間。對於具即時性的應 用服務，需要考慮較低的端對端延遲時間。此值越低越好，計算方式如式子 (4.2)。

Average End-to-End Delay

(4.2)

 控制訊息成本(Signaling Overhead)：所有路由控制封包的總數(包括 RREQ、

RREP、RERR 及 Hello 訊息)除以資料封包總數。是指由目的節點所接收的 每個資料封包帄均需要花費的路由控制封包個數。需要的路由控制封包愈多，

代表控制訊息的效率愈差，計算方式如式子(4.3)。

Signaling Overhead

(4.3)

4.3 權重係數 α 的選擇

在本小節會先針對不同α 值在帄均封包到達率、帄均延遲時間及帄均控制訊 息評估項目來進行權重係數的挑選。又因為權重係數α 在不同移動模型及資料傳 輸類型皆會影響權重值的選擇，所以本文提出的方法之權重係數會分別在 Manhattan 和 Freeway Mobility Model 下進行模擬比較，以提供較佳的權重係數組 合。車輛行動模型如 4.1 節所述，每台車輛會在模擬環境中，隨機選取一個目的

33

地，以給定的帄均速度移動至該目的地，移動模式中節點會持續移動，直到模擬 結束。另外，會隨機選擇 5 個點對點連線(Session Numbers)，來分別進行固定速 率(Constant Bit Rate；CBR)和檔案傳輸協定(File Transfer Protocol；FTP)的資料傳 送表現，另一組實驗設定 10 組點對點連線的表現。

4.3.1 權重係數 α 在 Manhattan 移動模型之表現

因不同移動模型下權重係數也會有所影響，所以本文先以 Manhattan 移動模

因不同移動模型下權重係數也會有所影響，所以本文先以 Manhattan 移動模

在文檔中 一個針對車載網路繞徑之可應變式 接手節點挑選機制 (頁 36-0)