IEEE 802.11a 以及 IEEE 802.11p 車間通訊網路效能之比較

國

立

交

通

大

學

資訊科學與工程研究所

碩

士

論

文

IEEE 802.11a 以及 IEEE 802.11p 車間通訊網路

效能之比較

Performance comparison between IEEE 802.11(a)-based and

IEEE 802.11(p)-based wireless vehicular networks.

研 究 生：洪維駿

指導教授：王協源 教授

二

IEEE 802.11a 以及 IEEE 802.11p 車間通訊網路效能之比較

Performance comparison between IEEE 802.11a-based and IEEE

802.11p-based wireless vehicular networks

研 究 生：洪維駿 Student：Wei-Jyun Hong

指導教授：王協源 Advisor：Shie-Yuan Wang

國 立 交 通 大 學

資 訊 科 學 與 工 程 研 究 所

碩 士 論 文

Submitted to Institute of Computer Science and Engineering College of Computer Science

National Chiao Tung University in partial Fulfillment of the Requirements

for the Degree of Master

in

Computer Science

June 2009

Hsinchu, Taiwan, Republic of China

中文摘要

IEEE 802.11p/1609 標準為了讓車與車 (V2V) 之間的 ad-hoc 網路做訊息的 交換而定義了 WIBSS (WAVE Independent Basic Service Set) 。但是，這種設計無 法善用 802.11p/1609 網路 multi-channel 的特性。如果我們想使用 multi-channel 勢必要有一種機制來溝通並且同步 nodes 所使用的 channel，但這可能會增加 MAC layer 設計的複雜度。 有鑑於此，我們找設計一種更為簡單的方法來解決 channel 同步的問題。本 篇論文首先利用模擬的方法來觀察常用的 ad-hoc 路由協定 (AODV，DSDV) 在 802.11p/1609 網路上的效能。在我們的模擬結果中發現，如果將一般路由協定所 傳送/廣播的控制訊息藉著 WBSS (WAVE Basic Service Set) 的建立來傳送，將造成 路由協定的效能低落。為了解決此問題我們最終將這些路由協定所傳送/廣播的控 制訊息以 WSM 格式來包裝傳送。另外為了將封包正確的送達收端，我們在

WBSS-based 網 路 採 用 了 兩 種 MAC 層 的 multi-hop forwarding 機 制 來 幫 助 WBSS 的建立。最後我們比較這兩種機制在 802.11p/1609 網路下運行的效能，並 以 802.11a 網路為基準做比較。

我們的模擬結果顯示，在 802.11p/1609 networks 所運作的 routing protocol 效 能上與 802.11a ad-hoc networks 並沒有太大的差異。這是由於我們將所有路由協 定所 傳送/廣播 的控制訊息利用 WSM 的格式來發送。另外，雖然 WBSS-based V2V networks 相較於 802.11a 網路只能利用一半的頻寬來傳輸資料，但是因為運 用到為 802.11p/1609 網路所設計的 multi-channel，在某些情況下傳輸資料的效率 反而優於 802.11a ad-hoc networks。

關鍵字：車間通訊網路，802.11p/1609 網路，路由協定，無線網路，ad-hoc， multi-hop forwarding，802.11a networks。

ABSTRACT

The IEEE 802.11p/1609 standards define the WAVE Independent basic service set (WIBSS) for vehicular ad-hoc networks to carry out vehicle-to-vehicle (V2V) communication. However, the design of a WIBSS cannot utilize the multi-channel property of an 802.11p/1609 network. To make use of these channels, an extra protocol is needed to negotiate and synchronize the channel used among nodes, which may complicate the design of the MAC layer.

These observations motivated us to find an easy-to-implement solution for it.In this thesis, we first observed the performances of several common routing protocols (such as, AODV and DSDV) in 802.11p/1609 networks using simulations. From our simulation results, we concluded that transmitting/broadcasting control messages of routing protocols in WAVE Basic Service Sets (WBSSs) is inefficient for routing protocols. To solve this problem, we propose a framework that transmits/broadcasts routing control messages using WSMs while data are still transmitted in WBSSs. Based on this framework, we further propose two MAC-layer WBSS-creating schemes to realize multi-hop data forwarding in WBSS-based networks. We compare the performances of 802.11p/1609 networks using these two WBSS-creating schemes with those of 802.11a networks.

Our simulation results show that the performances of routing protocols under 802.11p/1609 networks can be the same as those over 802.11a networks as long as in 802.11p/1609 networks routing control messages can be transmitted using WSMs. Because 802.11p/1609 networks only use a half of link bandwidth to transmit data, the bandwidth that can be used to transmit data is a half of the bandwidth that can be used in 802.11a networks. However, due to the multi-channel design WBSS-based V2V networks, can outperform 802.11a ad-hoc networks in several conditions.

Keywords: Vehicle networks, 802.11p/1609 networks, routing protocol, wireless

致謝

目錄

Chapter 2 Related Work ... 4

Chapter 3 Background... 5

3.1 Wireless Access in the Vehicular Environment ... 5

3.1.1 IEEE 1609.0 ... 6

3.1.2 IEEE 1609.3 ... 13

3.1.3 IEEE 1609.4 ... 19

3.2 Ad-hoc Routing Protocol ... 21

3.2.1 DSDV (Destination Sequence Distance Vector) ... 21

3.2.2 AODV (Ad-hoc On-Demand Distance Vector Routing) ... 25

3.3 Multi-hop Forwarding over WAVE Networks ... 27

3.3.1 SMFS ... 27

3.3.2 RMFS ... 30

Chapter 4 Design and Implementation ... 32

4.1 IEEE 1609.3 Implementation ... 32

4.1.1 WME Implementation ... 32

4.2 Support WBSS-based V2V Networks ... 42

4.2.1 Support Ad-hoc Routing Protocol ... 43

4.2.2 Support Multi-hop Forwarding Scheme ... 44

4.2.3 RMFS Implementation ... 46

4.2.4 SMFS Implementation ... 53

4.2.5 The priority design for SMFS and RMFS ... 56

4.2.6 SCH Selection for RMFS and SMFS ... 57

Chapter 5 Performance Evaluation ... 59

5.1 Simulation Setting ... 59 5.1.1 Simulation Tool ... 59 5.1.2 Simulation Topology ... 59 5.1.3 Simulation Metrics ... 62 5.1.4 Traffic Generation ... 63 5.2 Simulation Results ... 63

5.2.1 Routing Protocol Performance Results over Chain Topology ... 63

5.2.2 Routing Protocol Performance Results over Broken Link Topology... 65

5.2.3 Data Transfer Performance Results over Chain Topology ... 67

5.2.4 Data Transfer Performance Results over One-to-one Topology ... 71

5.2.5 Data Transfer Performance Results over Grid Topology ... 73

Chapter 6 Future Work ... 76

Chapter 7 Conclusion ... 77

圖目錄

圖 3.1 The Protocol Stack of an IEEE 802.11p/1609 Network ... 6

圖 3.2 The Bandwidth Division of an 802.11p/1609 Network ... 8

圖 3.3 The Message Encapsulation for a WAVE Service Advertisement (WSA) 10 圖 3.4 An Example Scenario of the 802.11p/1609 Network ... 11

圖 3.5 The Data Exchange Process between a RSU and OBU ... 12

圖 3.6 The Data Exchange Process between an End Host and OBU (The RSU serves as a Relay Node) ... 12

圖 3.7 The Data Exchange Process between an End Host and OBU (Across a Subnet) ... 12

圖 3.8 The Transmission Flow of an IP Packet ... 14

圖 3.9 The Transmission Flow of a WSM ... 14

圖 3.10 Service Request Information Flow ... 16

圖 3.11 An Example of Channel Access in 802.11p/1609 Network ... 16

圖 3.12 The Format of a WSA ... 18

圖 3.13 The Format of the WSM Header ... 18

圖 3.14 The Internal Structure of an 802.11p MAC ... 20

圖 3.15 An Example of the DV Algorithm ... 22

圖 3.16 Bellman-Ford algorithm-WIKI ... 23

圖 3.17 An Example of Route Looping ... 24

圖 3.18 NODE X’s DSDV Routing Table ... 24

圖 3.20 An SMFS scenario where the Sender node can Directly Communicate with

RSU node ... 28

圖 3.21 An SMFS scenario where the Sender node cannot Directly Communicate with RSU node ... 29

圖 3.22 The Procedure of SMFS ... 30

圖 3.23 The Procedure of RMFS ... 31

圖 4.1 The Protocol Stack of a WAVE Device in NCTUns ... 33

圖 4.2 WME Primitive Setting File ... 35

圖 4.3 Recording Available Services in CCH intervals ... 38

圖 4.4 The Processing of IP Packets in WME ... 39

圖 4.5 Send/Receive a WSM ... 40

圖 4.6 Construction of the WME_REG_INFO Structure ... 41

圖 4.7 WAVE Application for Sending or Receiving WSMs ... 42

圖 4.8 WME Broadcast Control Packets for Routing ... 44

圖 4.9 The Processing Flow of an IP packet in MAC ... 46

圖 4.10 The State-transition Table of RMFS ... 51

圖 4.11 The State-transition Diagram of RMFS ... 52

圖 4.12 The State-transition Diagram of RMFS from the Perspectives of a Sender and a Receiver ... 52

圖 4.13 The State-transition Table of SMFS ... 55

圖 4.14 The State-transition Diagram of SMFS ... 55

圖 4.15 The State-transition Diagram of SMFS from the Perspectives of a Sender and a Receiver ... 56

圖 4.16 2-hop forwarding example ... 57

圖 4.17 The scenario for SCH selection ... 58

圖 5.1 Chain Topology ... 60

圖 5.2 Broken Link Topology ... 61

圖 5.3 One-to-one Topology ... 61

圖 5.4 Grid Topology ... 62

圖 5.5 AODV Path Finding Time over Chain Topology ... 65

圖 5.6 DSDV Path Finding Time over Chain Topology ... 65

圖 5.7 Path Recovery Time over Broken Link Topology... 67

圖 5.8 Throughput over Chain Topology ... 69

圖 5.9 Throughput over Chain Topology with Best SCH Selection ... 69

圖 5.10 Percentage of Throughput Reduction Caused by Imperfect SCH Selection over Chain Topology ... 70

圖 5.11 Percentage of Throughput Reduction Caused by Center-Centric Design over Chain Topology ... 70

圖 5.12 Average Flow Throughput over One-to-one Topology ... 72

圖 5.13 Total Flow Throughput over One-to-one Topology ... 73

圖 5.14 Average Flow Throughput over Grid Topology ... 74

表目錄

Chapter 1

Introduction

在無線網路的發展領域中 IEEE 802.11(a)(b)(g) 已經相當成熟，但是考量到現

今車間通訊網路的需求，舊有的 IEEE 802.11 標準並不適合用在這類型的網路，因

此由 IEEE 802.11 團隊所制定的 IEEE 802.11p [1][2] 應運而生。車間通訊網路除

了較底層的 IEEE 802.11p 其上層還包括 IEEE 1609 [3][4][5][6][7][8][9] 系列，我

們將其通稱為 WAVE (Wireless Access in the Vehicular Environment) standards。另外，

車間通訊網路也可稱為 WAVE network。

WAVE network 有兩種模式，其一為 Infrastructure mode，在一般的情形下，

通常會由 RSU/OBU (roadside unit/onboard unit) 建立 WBSS，OBU 便可藉由加入

此 WBSS (WAVE Basic Service Set) 來存取 802.11p/1609 網路。通常建立 WBSS

的 WAVE device 稱之為 provider 而加入 WBSS 的 WAVE device 稱之為 user。

WBSS 的建立或是加入是為了交換一般的 IP 封包，在沒有加入或是建立 WBSS

的狀態下 WAVE device 就只能利用 WAVE standards 所制定的 WSM (WAVE

short message) 來交換資料。

IEEE 802.11p 另外定義了一種 ad-hoc mode 的網路存取方式。在這種網路上

的所有的節點都是 OBU，OBU 與 OBU 之間透過 WIBSS (WAVE independent

Basic service set) 的建立來交換訊息。WIBSS 的建立不需要發送 beacons 就可以

直接開始傳輸資料，意即 OBU 可以自由的交換訊息。

如果 WAVE network 的 ad-hoc mode 只是單純的使用上述的方式來達成，那

將無法善用到 WAVE network 所擁有的眾多 channels，這是因為 WIBSS 在建立

之前並沒有發送 beacons 就直接傳輸資料。在上述的情形下，送端以及收端必頇

一開始就停留在相同的 channel 才能互相通訊。另外，如果送端和收端距離很遠

必頇要靠中介點 (forwarder) 來幫助封包的傳送那麼 forwarder 也需要固定在此

channel 上。因此，如果想要透過 WIBSS 的建立來交換訊息最保險的方式便是所

如果我們想要在 WAVE network 的 ad-hoc mode 上使用 multi-channel 來交

換訊息也是可以的，但這需要一種機制來溝通與同步 node 與 node 之間的

channel。如此勢必會增加 MAC layer 設計與實作的複雜度。

有鑒於此，本篇論文的目的便是要找出一種簡單得方法來解決上述的問題，

並且使用 multi-channel 來傳輸資料。經過我們的研究後發現， WAVE standard 所

定義的 WBSS mode 便已經內建了 channel 同步的機制。WBSS 所使用的方法如

下，provider (WBSS 的建立者) 在 control channel(CCH) interval 時發送 beacon

通知 user (WBSS 的加入者) 之後的 service channel (SCH) interval 双方要到哪一

個 SCH 交換訊息。在此機制下 provider 和 user 會在 CCH interval 交換控制訊

息並做 SCH 的同步，之後到達 SCH interval 時便轉換到同一個 SCH。WAVE

device 會持續的在 CCH 與 SCH 間切換。

但是這樣還不足以達到類似 WAVE ad-hoc mode 的能力。如果送端和收端需

要中介點的幫助來交換訊息，送端必頇先透過 WBSS 的建立將封包送至中介點之

後再經過數次 WBSS 的建立與加入最後才將封包送達收端。每一次的 WBSS 建

立與加入都需要有相對應的 provider 與 user ，因此我們需要一種機制來 做

provider 與 user 的 選 擇 。 我 們 最 終 選 擇 [10] 所 設 計 的 機 制 (multi-hop

forwarding)，並且修改它以適用在我們所建立的網路環境 (WBSS-based V2V

networks) 之上。

另 外 為 了 在 WBSS-based V2V network 上 交 換 訊 息 我 們 還 需 要 routing

protocol (AODV [11] 以及 DSDV [12]) 的幫助，為我們選擇封包的傳送路徑。 但是 routing protocol 的運行必頇要 傳送/廣播 IP 封包來尋找路徑。而在我們的 WBSS-based 架構中傳送 IP 封包必頇要建立或是加入 WBSS。如果大家都想廣播 IP 封包，那麼所有的 node 都需要建立 WBSS，另一方面如果想要收到這些廣播 的 IP 封包，所有的 node 也都需要加入其他 node 所建立的 WBSS。最後這個 WBSS 又該由誰建立呢？為了解決這個問題我們將 routing protocol 所廣播的 IP

慮到 WBSS 建立的問題。

透過 WBSS 的建立我們可以自由的運用到 WAVE network 上所有 channel，

但是為了讓收端與送端間溝通好下次要到哪個 SCH 來傳送資料，OBU 必頇要常

常在 CCH 以及不同 SCH 間切換，對於資料傳送的 delay 也會比較大，當然也

只能利用到一半的時間來傳輸資料。相較於原本 WAVE ad-hoc mode 透過 WIBSS

的建立來交換訊息，本篇論文所使用機制卻可以讓資料分散在不同 channel 上傳

送，使得 WAVE network 理論上可以多出 3 倍的頻寬。這是因為 WBSS-based

V2V networks 可 使 用 的 channel 資 源 為 WAVE ad-hoc mode 的 6 倍 ， 但

WBSS-based V2V networks 能利用 SCH interval 來交換訊息，可使用的時間資源

為 WAVE ad-hoc mode 的 0.5 倍。

WSM 是 WAVE standard 專門為 WAVE network 所定義。WSM 的能力相當

強大，applications 在傳送 WSM 時可以直接指定要在哪一個 channel 上傳送 WSM。另外 WSM 也可以在任何的 channel 上傳送，比起只能在 SCH 上傳送的 IP data 顯然 WSM 的運用可以相當的靈活。如果上層所有的資料都利用 WSM 的格式來傳送，我們就可以直接利用到所有的 channel 資源。但是如果將所有的 資料包裝成 WSM 的格式來傳送，那麼在此之前利用 IP 封包來傳送資料的 application 將要全部改寫，這顯然不太可行。

Chapter 2

Related Work

自從 WAVE Standard 被發表以來，在其上的研究便不曾間斷過。其中，有一

部分的研究是注重在 IEEE 802.11p 以及 IEEE 1609.4。這部分的研究偏向較底層

的資料傳輸效能以及 WAVE MAC 的特性，其中還可分成非安全性相關 [13][14]

與安全性相關 [15] 的研究。[13] 的研究內容是在 802.11p 環境下測量封包的碰

撞機率，傳輸 delay 以及 throughput。[14] 的研究內容是改善 WAVE MAC layer

的 protocol，使得在其上運作的 application 可以達到更佳的封包傳送效率。[15] 的研究內容是 MAC layer 利用自己所設計的演算法有效率的將重要的安全性訊 息 broadcast 到整個網路。 有一部分的研究是專注在較上層 IEEE 1609.1 以及 IEEE 1609.3 與安全性向 關的研究題目 [16][17]，另外也有研究題目是與 WBSS 相關的論文 [18]。[16] 的 研究是利用 roadside unit 來收集車輛所傳出來的訊息，並且利用這些訊息來分析 每兩台車輛的相對移動方向以及位置，最後計算兩台車是否有發生碰撞的可能性。 [17] 的研究是改善車輛碰撞偵測系統的效能，這種系統是利用 GPS 服務來得知 車輛位置，並且與附近車輛交換這些 GPS 訊息，藉以分析自己是否有遭受碰撞的 危險。[18] 的研究是在 WBSS 的架構下建立一種封包傳送的機制，使得每個封包 的發送者都可以享有較高而且穩定的 throughput。 我們所做的研究與 [10] 的研究有相當大的相關性，但其中的不同點在於 [10]

所設計的 multi-hop forwarding 演算法與上層的 routing protocol 必頇有非常密切

的關聯，而且 [10] 所使用的 topology 上必頇要有 RSU 的存在。我們改善了 [10]

所 使 用 的 multi-hop forwarding 機 制 ， 並 且 適 當 的 運 用 在 我 們 所 支 持 的

Chapter 3

Background

3.1

Wireless Access in the Vehicular Environment

IEEE 802.11p (又稱 WAVE；Wireless Access in the Vehicular Environment) 標準，

是由 IEEE 802.11 標準所擴充的通訊協定，這個通訊協定主要是使用在車用電子

上的無線通訊系統。WAVE 是從 IEEE 802.11 標準來擴充延伸，來符合智慧型運

輸系統(ITS：Intelligent Transportation System)的相關應用，應用的層面包含高速率

的車輛與車輛 (Vehicular-to-Vehicular：V2V) 以及車輛與路邊基礎設施(Vehicular to

Roadside Unit：V2R) 間的封包交換，其使用的波段為 5.9 千兆赫(5.85-5.925 千兆

赫)，而 IEEE 1609 標準則是以 IEEE 802.11p 通訊協定為基礎的高層標準。

在 IEEE 801.11p/IEEE 1609 標準中詳細制定了 WAVE device 中 protocol 層

面的溝通方式，其架構如圖 3.1 所示。IEEE 1609.0 定義的整個 WAVE 系統的架

構，參考圖 3.1，它將整個 WAVE 系統分成兩大塊，其中一塊是數據平面 (Data

Plane)，有 WSMP (Wave Short Message Protocol)，WAVE MAC 以及 WAVE PHY，

另為一塊是管理平面 (Management Plane)，主要由 WME (WAVE management entity)

所構成。本篇論文的所探討的範圍主要為 IEEE 1609.0，IEEE 1609.3 以及 IEEE

圖 3.1 The Protocol Stack of an IEEE 802.11p/1609 Network

3.1.1 IEEE 1609.0

IEEE 1609.0 規劃了整個 WAVE 系統功能以及的規則，在此分成 WAVE 系

統概要以及 WAVE 系統操作兩部分來介紹。

WAVE 系統概要：

 WAVE device 以及 WAVE service

WAVE device 分成車載裝置 (onboard unit：OBU) 以及路邊基礎設施

(roadside unit：RSU)兩種。WAVE service 是由應用程式 (applications) 透過

WAVE device 所提供。提供 service 的裝置稱做提供者 (provider)，使用

service 的裝置則稱為使用者 (user)。當 applications 下的 WAVE device 形成

provider 以及 user 的關係必定是兩個 WAVE device 上的 applications 有交

換資料的需求。另外 OBU/RSU 的身分可以是 provider 或是 user。

 頻道種類

CCH 上收送 Wave Short Message (WSM) 以及系統控制訊息( service 廣播：

service advertisement)，SCH 則是用來收送一般的應用層資料 (IP data) 封包。  通訊協定

WAVE 系統提供 WSMP 以及 IPv6 兩種資料交換的通訊協定，WSM

可以在任何 WAVE 所定義的頻道上傳輸，IP 封包的傳輸則只能在 SCH 上。

WSMP 提供送端 (source) application 直接控制 WAVE PHY 的能力 (例如：

發送頻道，傳送功率 …)，WSM 的收端 (destination) 則是根據 WSM 所帶

的 Provider Service Identifier (PSID) 來判斷要送給哪一個 application。每一個

PSID 代表著不同的 service 類別，它是由 IEEE Registration Authority 所管理。

WSMs 是專門為 WAVE 所設計。  通訊服務

Application 可以自行選擇是否要使用 WAVE services 來交換資料封包，

如果使用的話 application 就可以在 SCH 上交換一般的 IP 封包，否則

application 就只能在 CCH 上利用 WSM 來交換資料。  Device 規則

一個 WAVE deivce 在某一個 service 中只能扮演 provider 或是 user

其中一個角色，至於扮演哪一種角色則是由 application 來決定。Provider 必

頇定時 (以每個 CCH interval 為單位) 發出 service advertisement 並且選定

一 個 SCH 作 為 資 料 傳 輸 所 用 。 User 則 根 據 CCH 上 收 到 的 service advertisement 來決定是否要加入這個 service 。  優先權 在 WAVE device 上有兩種類型的優先權  Application 有自己的優先權等級，主要是利用在網路的 service 上，這 可以用來讓 user 選擇高優先權的 service。

 WAVE MAC 對於不同的封包給定其不同的優先權，IP 封包的優先權以 發送的 application 為依據來決定，WSM 封包則是以每個封包為單位來

給定優先權，即使發送不同 WSM 封包的 application 為同一個。

 頻道同步

當 WAVE device 間要使用 SCH 來傳輸資料時必頇同步頻道切換的時間，

它會利用一個大家都可以存取到的時間資源來做同步，例如：由全球定位系

統 (Global Positioning System：GPS) 所提供的國際標準時間 (Universal Time

Coordinated：UTC) 。被同步的間隔 (interval) 如圖 3.2 所示，其中包含一個

CCH interval 後面再接著一個 SCH interval。在 CCH interval 時 WAVE

device 監聽著 CCH，而在 SCH 時加入某 service 的 WAVE device 就可以

利用 SCH 來交換訊息。WAVE device 一旦切換到 SCH 就無法收到 CCH

上的封包。

圖 3.2 The Bandwidth Division of an 802.11p/1609 Network

 服務開始

WAVE service 的起始是由某個 provider application 向 WME 發出要求，

provider 要把選定的 SCH 資訊加在 advertisement 中。如果選擇的 service

是持續的 (persistent) 那麼發送出 advertisement 的 destination MAC address

必頇是廣 播的 (broadcast) 而且要決定 每個 CCH interval 要發送多 少次

(repeats) advertisement。如果不是 persistent service 則 destination 的 MAC

address 可以是 broadcast 或是單點傳播 (unicast)，而且只有在第一個 CCH

WAVE device 在收到 advertisement 後根據其內的 PSID 來判斷是哪種

provider application，並且檢察 service 的優先權 (priority)，認證 (credentials)

等等。如果條件符合那麼 WME 就會告知 MAC 下次 SCH interval 要轉換

到 advertisement 所提供的 SCH。

Service advertisement 的 destination 不需要發送確認 (acknowledgement ：

ACK) 給 source，所以 provider application 不會知道有哪些 WAVE device 收

到了 advertisement，也不會知道有哪些 WAVE device 成為 user 加入了這個

service。

WAVE 系統操作：

 無 service 狀態下運行

WAVE device 在沒有建立 service 的情況下就只能使用 WSMs 在 CCH

上交換資料。以下從 source 以及 destination application 的實際運行的情境來

介紹。

 Source 把想送出的資料準備好之後設定其目地的 MAC address 為 broadcast MAC address，之後設定 WSMP 的參數。透過 WME 所提供

的基本操作 (primitive) WSM-WaveShortMEssage.request 把資料以及參

數告知 WME。WME 會幫助 application 將 WSM 送到底層，最後資料

會以 WSMP 封包的形式在 CCH 上傳送。

 Destination 收 到 WSM 後 ， WSMP 會 跟 據 其 中 所 帶 的 PSID 來 將 WSM 轉送給正確的 application，同時 destination 也會知道 source 的

WAVE device 位置。之後 destination 就可以根據此來發送封包，MAC

address 則可以選擇用 unicast 或是 broadcast MAC address。  在 service 下運行

WAVE service 是利用時間以及 channel 所提供的資源來分配給這些

WAVE device 所建立的 service。WAVE service 的起始是由某個 application

的成立。

在之前有提到 WAVE service 分成 persistent 以及 non-persistent 兩種，

persistent service 為持續性的 service (例如：路況報告)，non-persistent service

則為臨時性的 service (例如：碰裝偵測通知)。

WAVE advertisement 為 application 用來發佈 provider service 建立的公告，

其組成步驟如圖 3.3 所示。所有 provider service 的相關訊息都包含在由

WME 所提供的 WAVE Service Advertisement (WSA)。

上層的協定 (Higher layer) 會監視由 WME 維護的有效的服務 (available

service) 選出其中有興趣的來加入。

WAVE device 停止提供 service 時，它並不會發出任何的訊息來告知其

他 WAVE device。它只會在 device 內部利用 primitive 告知 WME 結束

service。User 端的 WME 會利用一些機制來得知 service 已經不存在了，並

將此 service 從 available service 列表中刪除。

不同的 service 可以在選擇同一個 SCH 來交換資料，而且在 service 的

運作期間可以切換到其他的 SCH 來傳送封包，只要把取代的 SCH 填在

WAVE advertisement 告知其他 WAVE device 即可。

 RSU/OBU 上的發散系統 (Distribution System) RSU/OBU 不僅可以在 WAVE 網路上傳送封包它還可以透過固網連接 其他 WAVE device，透過其他的裝置在和遠端電腦溝通如圖 3.4 所示。這代 表著遠端的電腦不但可以用任何型態的網路來存取 RSU/OBU 上的封包，甚 至可以提供或是使用 WAVE service，只要中介的裝置支援即可。此項功能賦 予使用者極大的便利性，以中央氣象局所提供的氣象預報 service 為例，中央 氣象局不需要為 WAVE 而特別開發一套硬體設備，只要將提供 service 的那 台電腦連接上 WAVE device 即可。

以下介紹幾種 WAVE device 配合 Distribution System 的情境：

 圖 3.5 展示了標準的 service 模式，RSU 為 provider 以及 advertiser OBU 為 user。

 圖 3.6 的 Host 為提供 service 的 provider，RSU 為 advertiser，OBU 為 user。

 圖 3.7 的 provider，advertiser 以及 user 同圖 3.6 只是 Host 和 RSU 間多了一個 router，host 可以透過任何 router 所支援的網路來與 OBU

傳送資料。

圖 3.5 The Data Exchange Process between a RSU and OBU

圖 3.6 The Data Exchange Process between an End Host and OBU (The RSU serves

as a Relay Node)

圖 3.7 The Data Exchange Process between an End Host and OBU (Across a

3.1.2 IEEE 1609.3

IEEE 1609.3 規 範 了 WME 所 具 備 的 功 能 ， WME 向 上 提 供 application

primitive，像下連結 WAVE MAC 與 WAVE PHY，可以說是管理整個 WAVE

device 的核心。其負責整個 WAVE service 的運作流程，以下將個別介紹 WME

所需具備的能力：

 服務廣播監視(Advertised service monitoring)

WME 必頇收取其他 WAVE device 所發出來的 service advertisement，提

供給上層以及 WME 自己的管理函式運作。藉由 advertisement 的收集，

WME 利用 management information base (MIB) 作 available service 的維護。

WME 利 用 連 結 品 質 (link quality) 來 判 斷 service 是 否 為 available

service 目前 IEEE 1609.3 提供兩種方式來決定 link quality：

 RCPI 以及平均 RCPI。WME 可以利用 RCPI 來計算兩個 WAVE device 間的無線訊號強度。WME 可以將 RCPI 轉換成 advertised WAVE device

與自己所在的 WAVE device 間的 link quality。至於 RCPI 將會在稍後的

項目做詳細的介紹。

 WSA count (這次 CCH interval 所收到的 WSA 個數)。WME 利用 WSA 所 帶 的 repeats (WSA 在 一 次 CCH interval 所 發 送 的 次 數 - 1) ，

persistence (WSA 是否要在每次 CCH interval 都發送) 以及 WSA count

來轉換成自己所需要的 link quality。例如 repeats 為 3 WSA count 為 4

表示 provider 所發出的 WSA 都被收到了，link quality 為最佳。

 服務的需求以及頻道的分配(Service requests and channel assignment)

WME 必頇處理 Higher layer 所要求的 service request，以及規劃 SCH 給

這個 service 使用。如果 service request 的類別為 provider 那麼 WME 則要

開始送出 service advertisement。

以 下 將 分 別 介 紹 WAVE device 所 提 供 的 management service ， data

 WAVE data service 提供資料傳輸的能力，必頇配合 WAVE management service 才能將資料正確的送到 destination。資料類型有 IP data 以及

WSM data 兩種，它們與 WAVE management service 配合傳送的流程請

如圖 3.8 以及圖 3.9 所示。

圖 3.8 The Transmission Flow of an IP Packet

圖 3.9 The Transmission Flow of a WSM

 WAVE management service 是由 WME 來提供。其中包含 provider service， user service，WSM service 以及 CCH service 四種類型的 service request

primitive。這四種 service 都包含了新增 (add) service 以及刪除 (delete)

service 的選項，provider service 另外提供了修改 (change) 的功能用來做

示，以下將分別介紹四種 service request：

 Provider service request 是 application 告知 WME 提供 service 的 需求，WME 收到之後便將 application 所提供的資訊包成 WSA 送

給下層，並且在 CCH 上傳送 service advertisement。之後到了 SCH

interval，device 會留在 SCH，CCH interval 則會留在 CCH。Channel

的切換如圖 3.11 所示。

 User service request 是 higher layer 告知 WME 它對哪些 service 有興趣。如果 WME 收到關於這些 service 的 advertisement 可以告

知 higher layer 或是自動加入這些 service。

 WSM service request 為 higher layer 向 WME 註冊哪些 WSM 要 向上送。WSM 則以 PSID 來分類。

 CCH service 為以 WAVE device 建立/加入 service 的前提下，higher layer 要求在 CCH interval 時 WAVE device 留在 CCH 的 priority。

如果 CCH priority 大於 service 的 priority，WAVE device 將會在

CCH interval 時強制切回 CCH，但是在 SCH interval WAVE device

必頇留在 SCH。當 WAVE device 使用 Access Immediate 或是

Access Indefinite 這兩種方式切換 channel 時，CCH service 才會發

圖 3.10 Service Request Information Flow

 在 WAVE device 中 各 個 協 定 間 的 控 制 / 資 料 訊 息 的 交 換 是 依 靠 primitive。Primitive 整理於表 3.1。SAP 為 service access point 代表著協

定與協定之間的介面，primitives 便是連接這些協定的基本操作。這些

primitive 大致上可以分成封包傳送，service 操作以及 MIB 的存取三

類。

WME-ProviderService.request 的操作中會導致 WSA 的產生或修改，其

封包格式如圖 3.12 所示。

WSM-WaveShortMessage.request 的操作會產生 WSM 封包，其封包格式

如圖 3.13 所示。

SAP Primitive SAP Primitive

WSMP WSM-WaveShortMessage.request LSAP DL-UNITDATA WSM-WaveShortMessage.indication MLME MLME-DELETETXPROFILE WME WME-ProviderService.request MLME-REGISTERTXPROFILE

WME-ProviderService.confirm MLME-WSA WME-UserService.request MLME-WSADIGEST WME-UserService.confirm MLME-WSAEND WME-WSMService.request MLME-SCHSTART WME-WSMService.confirm MLME-SCHEND WME-CchService.request MLME-GET WME-CchService.confirm MLME-SET WME-Notification.indication MLME-MREPORT WME-Get.request MLME-MREQUEST WME-Get.confirm MAC MA-UNITDATA

WME-Set.confirm WME-RCPIREQUEST.request WME-RCPIREQUEST.indication

表格 3.1 Summary of WAVE Primitives

圖 3.12 The Format of a WSA

 評估服務頻道的品質(Service channel quality evaluation) WME 提供一些機制來選擇品質較好的 SCH。  IPv6 設定(IPv6 configuration)

WME 設定自己的 IPv6 協定堆疊，用來收取其他 WAVE device 所發出

的 IP 封包。

 輪詢頻道功率的指示(Received Power Indicator(RCPI) polling)

WME 可以和其他 WAVE device 上的 WME 交換特殊的封包來計算兩

者間的訊號強度。

 MIB 的維護(MIB maintains)

WME 維護自己的 MIB 其中包含 WAVE device 的設定以及狀態，WME

必頇根據 primitive 的指示來 存取/修改 MIB 的內容。

3.1.3 IEEE 1609.4

1609.4 定義了 WAVE multi-channel 運作以及 MAC 對於資料的處理，以下將

分別介紹 WAVE MAC 以及 multi-channel access：

 WAVE MAC

WAVE MAC 是基於 IEEE Std 802.11 修改而來。目前 WAVE MAC 標準

分兩部分，其一為 IEEE 1609.4 另一為 IEEE 802.11p，IEEE 1609.4 較偏重

與 WME 間的溝通以及 WAVE system 的運行相關，IEEE 802.11p 則較偏重

MAC 與 WAVE phy 間的溝通。

WAVE system 為了讓封包在不同的 channel (CCH/SCH) 上傳送。MAC

必頇將封包 (IP/WSM) 在正確的 channel 上傳送 (channel routing)，在 CCH

傳送控制封包 (例如：WSA) 以及 WSM，在 SCH 上傳送 WSM 以及 IP 封

包。這些封包可能要在不同的頻道上傳送，而且這些封包的優先權也許都不

盡相同。為了解決這些特殊的要求 IEEE 1609.4 提供一個範例架構如圖 3.14

據個別的 priority 最後進入不同的 queue，每個 queue 有不同的參數設定導

致在不同 queue 內的封包有不同的傳送機率。

圖 3.14 The Internal Structure of an 802.11p MAC

 Multi-channel access

當 WAVE service 開始被提供或是使用時，WME 會要求 WAVE device

切換到 SCH 以收送資料。WAVE device 共提供三種 SCH 的存取方式：

 一般模式 (Normal service channel access)

即使 WME 在 CCH interval 要求存取 SCH，WAVE device 會等到

SCH interval 才切換到 SCH，直到 CCH interval 才會切換回 CCH。CCH

WME 一要求存取 SCH，WAVE device 馬上切換到 SCH，即使目

前是 CCH interval，等到 CCH interval 時才會切換回 CCH。除了一開始

之外其他都跟一般模式一樣。

 無限模式 (Indefinite SCH access)

WME 一要求存取 SCH，WAVE device 馬上切換到 SCH，即使目前是 CCH

interval。之後就一直留在 SCH。

3.2

Ad-hoc Routing Protocol

Ad-hoc 網路是一個沒有有線基礎設施 (Infrastructure) 所支持的網路，所有的

節點都是由可移動的主機 (mobile node) 所構成。這種網路的特點是動態的拓樸結

構，通常在需要通訊時才會開始尋找路由 (on-demand routing)。目前已經發展出許

多的路由協定，以下將介紹常用的幾種 Ad-hoc 路由協定 (AODV，DSDV)。

3.2.1 DSDV (Destination Sequence Distance Vector)

DSDV 是 以 Bellman-Ford 演 算 法 所 改 進 而 來 。 Bellman-Ford 演 算 法 是

Distance Vector (DV) Routing 演算法的一種，以下將個別介紹。

DV 演算法是一種反覆、非同步和分散式的演算法，每個 node 會從一個或多

個相鄰的 node 取得資訊，並做處理最後將結果送回相鄰 node，直到相鄰 node 間

不再交換資訊為止。其中每個 node 都維護一個表格記錄著自己到所有可到達的

node 距離，並且定期 broadcast 給相鄰的 node，node 收到相鄰 node 的 routing

資訊之後反映到自己的表格，最後根據最小路徑的原則來決定每個目的地的 next

hop node。當 node 要把封包送往目的地時他只是往 next hop node 丟。DV 演算

法範例如圖 3.15 所示。

Bellman-Ford 演算法的演算法如圖 3.16 所示。演算法最終的目的便是計算出發到

回合 X 只知道相到鄰點的花費，X-Y 花費 2 (暫定)，X-Z 花費 9 (暫定)。第二

回合將 X 花費最小可到達的點 Y 納入考量，並且不再改變 X-Y 的路徑花費，

再將 Y 的相鄰點花費納入考量，Y-Z 花費 1。此時便可以得知 X-Y 再由 Y-Z 花

費會比 X-Z 小因此修正 X-Z 的花費為 3。第三回合將 Z 納入考量後發現沒有

剩餘的相鄰點演算結束。

圖 3.16 Bellman-Ford algorithm-WIKI

當 Bellman-Ford 演算法穩定之後 routing table 就不會改變，只有當 topology

改變或是收到的 routing table 有所改變時才需要更新自己的 routing table。

DSDV 以 Bellman-Ford 演算法為基礎並加以改良。與一般的 DV routing 演

算法相同，每個 node 都要維護自己的 routing table，詴圖包含網路中所有可到

node 的路徑資訊，而且要定期 broadcast route update。與一般 DV routing 演算法

不同的地方是，每一筆路徑資訊會附加一個目的 node 所指定的數字 (sequence

number)，作為保證路徑資訊的時效性以及正確性。Node 收到路徑資訊後和自己

得路徑資訊相比，保留 sequence number 較大者並以其作為新的路徑資訊。若是

sequence number 相同則保留最短路徑得那筆路徑資訊。此舉不但可以確定路徑資

訊是最新的，也可以避免發生 route looping。Loop 發生的原因為連結成本的改變。

如圖 3.17 所示。當 Y-X 花費從 4 變為 60 時，Y 由之前 Z 送來的 routing

送回給 Z。Z 收到之後發現 Y-X 的花費改變了因此 Z 改變 Z-X 的花費為 Z-Y

加上 Y-X 為 7。此時可以明顯發現 loop 發生了，因為 Y-X 會經過 Z 而 Z-X 會

經過 Y。DSDV 因為額外帶了其他的 routing information 因此可以避免 loop。

DSDV 的 routing table 如圖 3.18 所示。

DSDV 的缺點為當 topology 非常大時，控制訊息的傳送將會佔掉很大的網路

頻寬。另外每個 node 所維護的 routing table 也會非常的大，某些封包永不會經

的 node 也要去維護其路徑，不僅浪費了儲存空間也浪費了 CPU 的資源。

圖 3.17 An Example of Route Looping

3.2.2 AODV (Ad-hoc On-Demand Distance Vector Routing)

AODV 是由 DSDV 演進而來。AODV 和 DSDV 不同之處為 AODV 只在

有需求時 (on-demand)才會去建立路徑 (以 source 和 destination 來區別不同的

路徑)， 而且也不必像 DSDV 一樣需要維護整個網路的 routing table。AODV 只

維護選擇路徑中的 node，也不會和非選擇路徑上的 node 交換 routing table。

在開始時，整個網路都是靜止的狀態，直到有傳送封包的要求 AODV 才會開

始運行。首先 source 會先在自己的 routing table 尋找是否已有到達 destination

的路徑。若無，便會開始啟動路徑尋找 (path discovery) 的程序，找到路徑之後

source 就會沿著這條路徑來送封包，為了保證封包可以在有效的路徑上傳送

AODV 會去維護這些路徑，當路徑斷掉時 route error (RERR) 會傳回給 source，

如果 source 還需要此條路徑就會重新啟動 path discovery。

Path discovery 的運作如圖 3.19 所示。一開始 source node 會 broadcast route

request (RREQ) 給相鄰的 node，相鄰 node 收到之後再 broadcast 出去，以此類

推，直到 RREQ 到達 destination 為止，或是傳送 RREQ 的過程中某個中間的

node 已有到達 destination 的 path，並且此 path 還是有效的，此時 RREQ 的

broadcast 才會停止，之後便開始回覆 route reply (RREP) 給 source。RREP 的傳

送方式為 unicast。

RREQ 所 帶 的 資 訊 有 source_addr ， source_sequence_num ， broadcast_id ，

dest_addr，dest_sequence_num 以及 hop_count。每個唯一的 RREQ 可以利用

source_addr 加上 broadcast_id 來辨識。每個 node 有 node sequence number 以及

broadcast id 兩個計數器 (counter)。

在轉送 RREQ 的過程中，每個 node 會自動設定反向的路徑 (例如 node B

收到 node A 的 RREQ，node B 會把 node A 的 IP 紀錄在自己的 routing table

中)，之後把 hop_count 加 1 再 broadcast 出去。如果 node 收到重複的 RREQ

則直接丟掉即可，避免發生 flooding。RREQ 中的 source_sequence_num 以及

dest_sequence_num，分別用來代表正向以及反向路徑的時效。如果收到 RREQ 的

node 發現 destination path 已經紀錄在自己的 routing table 中，先檢查 RREQ 中

的 dest_sequence_num 是否比自己 routing table 中所記錄的還大，如果是則繼續

broadcast RREQ，如果不是則往反向路徑回覆 RREP。

RREP 所帶的資訊有 source_addr，dest_addr，dest_sequence_num，hop_count

以及 lifetime。RREP 沿著反向路徑回到 source 的過程中，每一個在此路徑上的

node 會設定一個轉送點 (forward point)，指向送來 RREP 的 node，並且更新

routing table 中此路徑的時效 (timeout)。

當 node 收到 RREP 其中的路徑已經被記錄在自己的 routing table 中時。如

果 RREP 中的 dest_sequence_num 比自己小則直接丟棄，如果比自己的大或是

dest_sequence_num 相同但是 hop_count 比自己的小 node 才會更新 routing table

並且把 RREP 傳送出去。另外每一條路徑都有一個 timer 如果在 lifetime 內都沒

有用到這條路徑，才會刪除之。

當 topology 改變了，如果移動的是路徑中的 source node 則 source 會重新

做 path discovery，如果移動的是路徑中的 node 則所有 forwarding point 指向它

的相鄰 node 會發現，然後依照反向路徑把 RERR 傳送給前一個 node 直到

重新啟動 path discovery。

3.3

Multi-hop Forwarding over WAVE Networks

在 WAVE system 上兩個 node 可以透過 WBSS 的建立來傳輸一般的 IP 封

包，但是在兩個 node 距離 1 個 hop 以上的情形下，而且 node 之間的 node 都

沒有提供 service 時該怎麼辦呢 ?

Multi-hop forwarding 正 是 為 了 解 決 此 問 題 而 設 計 出 來 的 。 Multi-hop

forwarding 有兩種形式。其一為以送端為中心的形式 (sender-centric multi-hop

forwarding scheme ： SMFS) ， 另 一 種 為 以 收 端 為 中 心 的 形 式 (receiver-centric

multi-hop forwarding scheme：RMFS)。SMFS 的意義是，由 sender 來建立 WBSS

讓 receiver 加入以提供封包傳輸的 service，RMFS 則相反，是由 recevier 來建

立 WBSS 讓 sender 加入以提供封包傳輸的 service，SMFS 由 sender 自主建立

WBSS 是很自然的一件事，但是 RMFS 由 receiver 來建立 WBSS 卻要通過其他

的幫助，因為在 service 還未建立前不能傳送 IP 封包，receiver 也不會知道自己

是 receiver，因此必頇要由 sender 在 CCH 先發送一個 WSM 給 receiver，請

receiver 建立 WBSS。

RMFS 以及 SMFS 都有提供 service channel 的選擇方式。SMFS 必頇由 sender

(provider) 來決定。RMFS 則可以由 sender (receiver：channel 選擇資訊帶在 WSM)

或是 receiver (provider) 來決定，如果 channel 的選擇是由 provider 來決定，則

provider 必頇收集其他 advertisement 所帶的 channel number 來記錄 channel 的

使用情況，如果 channel 的選擇是由 user 來決定，則 user 必頇收集其他 WSM

內所帶的 channel number。

3.3.1 SMFS

WAVE network 傳送 IP 封包給另一個 OBU 時，首先 OBU (original sender) 會檢

查另一個 OBU (target receiver)，是否在自己的傳輸範圍內 (one hop)。如果是的話

那就直接由 original sender 建立一個 WBSS，並且等待 target receiver 加入即可。

如果 target receiver 距離 original sender two hop 以上那麼 original sender 會詴圖

把封包先傳送到 original sender 附近的 RSU 再由 RSU 透過固網將封包送至

target receiver 附近的 RSU，最後再由 RSU 送給 target receiver。

RSU 通常都會有固定的 WAVE service 運作。因此，OBU 只要直接加入便可

以透過 RSU 來傳送封包。RSU 在背後使用固網來傳送資料，網路的品質較為可

靠，速度也較快。重要的是如果 original sender 和 target receiver 的 forwarding

point 都是 OBU 的話，每經過一個 forwarding OBU 都要經歷一次 SMFS 的運

作，會浪費掉相當多的時間。但是若 original sender 和 RSU 的間隔距離過遠 (大

於 1 hop)，那麼 original sender 還是要透過 RMFS 來將封包送至距離 RSU 更

近的 forwarding OBU，再由此 forwarding OBU 將封包送至 RSU。

SMFS 的運作情形如圖 3.20 以及圖 3.21 所示。在圖 3.20 的情境 OBU 並

不需要 SMFS 的機制，由 original sender 直接將封包送至 RSU，再由附近的 RSU

(轉)送至 target receiver 即可。圖 3.21 中，original sender 沒有辦法直接使用 RSU

所提供的 service，而只能利用 SMFS 的機制將封包傳到附近的 OBU (forwarder)，

再由 forwarder 送至 RSU，最後由 target receiver 附近的 RSU 轉送至 target

receiver。

圖 3.20 An SMFS scenario where the Sender node can Directly Communicate with

圖 3.21 An SMFS scenario where the Sender node cannot Directly Communicate with

RSU node

SMFS 的內部運作如圖 3.22 所示。首先由 sender (original sender or forwarder)

在 CCH interval 發送 advertisement，通知 receiver(forwarder or target receiver)，加

入 WBSS 以收取封包。等到 SCH interval 時再由 sender 將要送出的 IP data

broadcast 出去。在此必頇要使用 broadcast，因為 sender 不知道哪一個 receivers

會加入 service，receivers 也不會知道自己是否是目前加入此 WBSS 中離 RSU

最近的。Receivers 只知道自己是不是比 sender 更接近 RSU (使用 position-based

routing)。因此 SMFS 只能將封包利用 MAC-layer 的 broadcast 送出去，讓所有

圖 3.22 The Procedure of SMFS

3.3.2 RMFS

於 SMFS 中 sender 使用 MAC-layer 的 broadcast 封包，所以即使 A 或 B 的

封包掉了，也不會被發現。

RMFS 運作的時機與 SMFS 相同，但是 RMFS 的 WBSS 建立的過程與

SMFS 正好相反。如圖 3.23 所示，首先由 sender (original sender or forwarder) 在

CCH interval 發送 WSM (broadcast) 告知 receiver (forwarder or target receiver)，

Receiver 收到此 WSM 之後便開始建立 WBSS。如此 sender 便可利用此 service

在 SCH interval 傳送 IP data。使用 broadcast WSM 的理由是最接近 RSU 的

以提供 service 讓 sender 選一個最接近 RSU 的 WBSS 加入。另外， forwarder

也可以藉由收到其他 forwarder 所發出的 advertisement 來判斷自己是否比別的

forwarder 更接近 RSU，如此 forwarders 也可以自行判斷是否有必要繼續提供

service 讓 sender 傳送封包。

Chapter 4

Design and Implementation

如同第一章的介紹，本篇論文的目的便是，在 WBSS-based V2V networks 上

交換訊息，其中包含了利用 routing protocol 來尋找路徑以及使用 multi-hop

forwarding 機制來傳輸資料。本章節會介紹我們所做的改變，設計，想法以及實 作。本篇論文使用了 NCTUns [19] 平台來實做這些功能。

4.1

IEEE 1609.3 Implementation

4.1.1 WME Implementation

在 NCTUns 中，大部分的硬體設施都是實作成 module 的形式來模擬。WME

是 WAVE device 的一部分，因此我們將它實做成 NCTUns module。由於 WME

向下負責控制 WAVE MAC 向上負責與 application 溝通，因此我們將 WME

module 的位置放在 WAVE MAC module 之上 ARP module 之下。如圖 4.1 所示，

4.1(a) 是一般的 OBU 它只有 WAVE device 這個介面，4.1(b) 則是 RSU，其除

了可以透過 WAVE network 傳送封包，也可以透過有線網路來傳送封包，因此包

圖 4.1 The Protocol Stack of a WAVE Device in NCTUns

WME 透過 primitive 與 higher layer 以及 MAC layer 溝通，但是我們實做的

WME 並 沒 有 完 整 的 支 援 WME 與 higher layer 間 的 溝 通 。 目 前 只 能 支 援

application 單 向 的 透過 primitive 來 告知 WME WAVE service 的訊息 ( 例如

provider service 的新增)，其原因要從 WAVE standard 的發展歷史來說明。一開始

IEEE 1609.1 定義了 application 以及 WME 的中介層，稱為 resource manager，

application 必頇透過 resource manager 來存取 WAVE device 所提供的資源，而在

IEEE 1609.3 所說的 higher layer 正是 resource management。但是，IEEE 1609.0 在

之 後 卻 被 部 分 的 人 認 為 制 定 失 敗 。 雖 然 後 來 又 制 定 了 IEEE 1609.5 的

communications manager 來取代 IEEE 1609.0 中 resource management，但是在實

application 透過 higher layer 與 WME 間動態使用 primitive 溝通的功能。最後，

我們選擇了折衷的辦法，那就是，一開始就必頇設定好 higher layer 何時去使用

WME 提 供 的 primitives 。 實 際 的 情 形 為 使 用 者 必 頇 一 開 始 就 在 指 定 的 檔 案

(primitive file) 中說明 WME 要在何時執行何種 primitives。在我們的實作中只提

供 WME-ProviderService.request ， WME-UserService.request ，

WME-CchService.request 以及 WME-WSMService.request 四種較重要的 service

request primitive。檔案的格式如圖 4.2 所示，SIB_Begin 以下 SIB_End 以上為設

定檔的內容，所有 node 的 primitives 都設定在此檔案內。NID X 以下 NID Y 以

上為 NID X 的 primitives 設定。CDB 與 CDE 中間所夾的內容就是一筆完整的

primitive 設定，其中時間 (Time) 的單位為 10(-7) second，表示 primitive 啟動的 時間。

圖 4.2 WME Primitive Setting File

一開始每個 node 的 WME module 會去讀取 primitive file，並且把屬於自己

的 primitives 設定按照時間順序存在 queue 中，直到 primitive 的啟動時間到了，

WME 就依照 primitive 的 type 去執行不同的 function。

所 有 service 的 新 增 ， 移 除 或 是 修 改 都 是 藉 由 primitives file 所 指 定 的

primitives 來運作。以下將詳細介紹這些 service request 的運作流程：  Provider Service：

若 provider service request 的 Action 為 add ， 其 代 表 的 意 思 為

application 想提供 service，請 WME 幫助它完成。收到此 primitive 之後，

始 準 備 發送 advertisement 。 如 果 WAVE device 之前 就 是 provider 那麼

WME 就要修改之前的 WSA，並且在原本的 WSA 之後附加此 provider 的

資訊，否則就要自己建立新的 WSA。WSA 建立完成之後就要根據 primitive

中所帶的 persistence 以及 repeats 來發送 WSA。最後便是告知 MAC 到達

SCH interval 時要跳到哪個 SCH。

若 provider service request 的 Action 為 change ， 其 代 表 的 意 思 為

application 想改變 service 的參數，請 WME 幫助它完成。此時 WME 會根

據 primitive 的內容來修改 MIB 中相對應的欄位，並且修改已存在的 WSA

成為 primitive 所要的樣子。如果 SCH 有改變的話則要重新通知 MAC，另

外 WSA 的發送頻率有改變的話也要做處理。

若 provider service request 的 Action 為 del ， 其 代 表 的 意 思 為

application 想停止 service 的提供，請 WME 幫助它完成。此時 WME 會根

據 primitive 的內容來刪除 MIB 中相對應的欄位，並且將 WSA 中相應的

provider 訊息刪除。如果 WSA 內沒有其他的 provider 的訊息則停止發送

WSA，並且告知 MAC SCH interval 請留在 CCH。  User Service：

WME-UserService.request 有 新 增 與 刪 除 兩 種 action 。 新 增 表 示

application 對於 primitive 所指定的 service (以 PSID 來區分) 有興趣，刪除

則相反。收到 user service request 時 WME 一開始只會去修改 MIB 的欄位，

之後如果 WME 收到 WSA 中包含 application 所感興趣的 service， WME

會自動加入此 service 直到此 service 不再提供，或是 application 對這類型

的 service 不再感興趣為止。如果 application 對很多 service 都感到興趣的話，

WME 會選擇最高 priority 的 service 加入。  Cch Service：

priority。WME 收到此 primitive 時只會去修改 MIB 的欄位，直到 SCH

interval 轉換到 CCH interval 那一瞬間，如果 WAVE device 想要繼續留在

SCH 它必頇去比較目前所使用的 provider service 的 priority 是否比 CCH

priority 大，如果是則會在繼續留在 SCH 否則就會切換回 CCH。  WSM service：

WME-WSMService.request 有 新 增 與 刪 除 兩 種 action ， 新 增 或 是 刪 除

PSID 。 WME 可 以 用 PSID 來 判 別 WSM 由 哪 一 種 application 送 出 ，

application 可以藉此決定只收哪種 PSID 的 WSM。WME 收到此 primitive

時只會去修改 MIB 的欄位，直到 WAVE device 收到 WSM 時，WME 會根

據 application 之前所註冊的 WSM 的 PSID，來決定要不要收此 WSM。

目前 WME 只能服務一個有能力收發 WSM 的 application，因此只要是

WSM service 有註冊過的 PSID 都會送到同一個 application，WME 並沒有

route WSM 到正確 application 的能力。使用這種作法的原因是因為在實做

WME 當時考慮到 WAVE 標準對於 application 的定義並不明確。

WME 必頇要維護 available service。在此使用的方法為收集其他 WAVE

device 所發出的 advertisement，如果在此次 CCH interval 有收到關於某 service

的 advertisement 表示此 service 可以使用，WME 會在 CCH interval 結束時搜尋

MIB 中記錄的 available service，如果 available service 中有對應到 application 使

用 user service request primitive 註冊的 service 則 WME 會自動加入此 service，

圖 4.3 Recording Available Services in CCH intervals

IEEE 1609.3 定義了 WAVE system 發送 IP 封包的條件限制，這個機制目前

實作在 WME 中。其實際運作情況如圖 4.4 所示，如果 IP 封包是由 higher layer

送往 WME，則 WME 會檢查目前 WAVE device 是否有加入或是提供 service

(user or provider )。若 WAVE device 目前為 user 則只能將封包送往提供自己

service 的 provider，若 WAVE device 為 provider 則直接將封包送出去，發生其

他的情況則直接將封包丟棄。如果 IP 封包是由 lower layer 送往 WME，WME 同

樣要檢查目前 WAVE device 是否有加入或是提供 service (user or provider )。若

WAVE device 目前為 user 則只能收取自己 provider 所發出的封包，若 WAVE

圖 4.4 The Processing of IP Packets in WME

4.1.2 WSMP Implementation

WSMP 是專門為了 WAVE system 所設計的 protocol，它與 IP protocol 的地

位 相同。在 NCTUns 所使用的 IP protocol 是修改 Linux kernel 內建的 IP

protocol 而來，但是 Linux kernel 並沒有內建 WSMP，因此必頇自行實作。為了

讓 WAVE applications 可以透過 function call 的方式來發送 WSM，以下有兩種方

法來實作 WSMP。第一種方法比較直覺，將 WSMP 實作在 Linux kernel 中，但

是缺點是實作的難度較高以及每次 Linux 改版都要重新維護。第二種方法是將

WSMP 實作在 NCTUns 中，application 要發送 WSM 時利用 IPC 將 WSM 送

至 NCTUns 內。

在此使用上述的第二種實作方式。 WSM 收送的情形如圖 4.5 所示，當

application 要發送 WSM 時，其會透過 IPC 將 WSM 送至相對應的 WME，之

後再由 WME 將 WSM 送出。當另一方的 WME 收到 WSM 時，它會透過 signal

圖 4.5 Send/Receive a WSM

NCTUns 透過其內的 command server 來收送 WSM，之後再由 command

server 來將 WSM 送 至 相 對 應 的 WME module 或是 application ， 也 就 是 由

command server 來負責做 IPC。

NCTUns 在開始模擬前會先將其所有將要運行的 module 初始化，接下來才

會開始 fork 出即將要在 NCTUns 上模擬執行的 process。為了要讓 application

將 WSM 送到正確的 WME，以及 WME 將 WSM 送到正確的 application，因

此我們利用 NCTUns 會先初始化完所有的 module 後才會 fork process 的特性。

其細節如圖 4.6 所示，在 WME 作初始化時先在 command server 內建立一個資

料結構 WME_REG_INFO，記錄 WME 所在的 node id 以及 WME module 所在

的位置。當 application 被 fork 出來時 application 會透過 IPC 向 command

server 告知此 application 是由哪個 node 所執行，application 和 command 間溝

通所利用的 file descriptor 以及 application 的 process id (PID)。Command server

會根據 application 所給的訊息 (node id) 去找相對應的 WME_REG_INFO，找到

之後便將 application 的 PID 紀錄在內。如此，WME_REG_INFO 內便有 WME

以及 application 的共同資訊，以及個別資訊 (共同資訊為 node id，個別資訊為

WME module 位置以及 application 之 PID)。

commander 去尋找相對應的 WME_REG_INFO，利用其內的資訊將 WSM 送至

正確的 WME module。

WME module 想把 WSM 傳給 application 時，WME 直接將 WSM 交給

command server 處理，讓 command server 去尋找相對應的 WME_REG_INFO，

利用其內的資訊將 WSM 透過 IPC 送至正確的 application process，並且發送一

個 signal (kill(PID, SIGANL_TYPE)) 通知此 application 來收取 WSM。

圖 4.6 Construction of the WME_REG_INFO Structure

為了配合 WME 的設計因此所有想發送 WSM 的 application 都必頇依照圖

4.7 的格式撰寫。首先 application 要先利用 IPC 開通和 NCTUns 間的通道，接

下來要傳送註冊訊息給 NCTUns，並且要對 NCTUns 所發出的 signal 做處理

(signal handler)。Application 收到 NCTUns 所發出的 signal 表示 NCTUns 已經

將 WSM 送到之前所建立的 IPC 通道，此時 application 要中斷目前程式的執行，

並起去執行 signal handler 以收取 WSM。另外 application 只要把想送的 WSM

圖 4.7 WAVE Application for Sending or Receiving WSMs

4.2

Support WBSS-based V2V Networks

forwarding 是建立在 sender OBU 可以特過 RSU 所提供的 WAVE service 來傳

送封包給 receiver OBU，但是本篇論文所討論的東西有點不太一樣。首先所有在

topology 上的 node 都是 OBU，而且必頇要透過一般的 ad-hoc routing protocol

來尋找路徑，因此我們必頇要對原本 multi-hop forwarding 的設計做修正。

我們即將要介紹的內容有兩部分，其中一項為我們是如何讓 ad-hoc routing

protocol 在 WAVE networks 上運作，另一項為，在已知封包傳送路徑的情形下，

我們如何修改 multi-hop forwarding scheme 來將封包傳給 next hop node。

4.2.1 Support Ad-hoc Routing Protocol

一般的 routing protocol 在尋找路徑時都會發出一種特殊的 broadcast IP 封包，

以章節 3.2.1 所介紹的 DSDV 為例，DSDV 會定時和鄰居做 routing table 的交

換。從整個 topology 的觀點來看，所有的 node 都會定時 broadcast IP packet，而

在 WAVE 網路上如果想傳送 IP 封包必頇加入或是提供 service，但是 topology

上只有 OBU，而且 OBU 也不會自動去建立 service。

Multi-hop forwarding scheme 解決了一部分 routing protocol 會定期 broadcast

IP packet 的問題，以 SMFS 加上 DSDV 為例，DSDV 可以利用 SMFS 來定期

broadcast routing table 封包給鄰居。但是萬一所有的 node 都同時想 broadcast

routing table 時，根據 SMFS 的設計，此時所有的 node 都應該要成為 provider

並且建立 WBSS，但是為了收到其他 node 的 broadcast 訊息所有的 node 也應

該加入在自己附近的 WBSS。如果我們沒辦法決定最終 WBSS 該由哪些 node 來

建立，那麼 broadcast routing table 就會失敗。另外，根據 WAVE 標準的定義，IP

封包都只能在 SCH interval 發送，DSDV 所 broadcast 的 routing table 其鄰居指

必頇要等到 SCH Interval 才有機會收到，這也許會對 DSDV 的路徑建立造成很

大的 delay。

上述的兩個問題可能會拖慢甚至造成 routing protocol 尋找路徑的失敗，為了

WSM 不受 channel 以及 WBSS 的限制，因此我們固定讓這些 routing protocol

的 hello message 以 WSM 的形式在唯一 CCH 上傳送，如此一來只要到了 CCH

interval 時所有的 node 都可以自由的交換這些 hello message。

但是，如果只是將 broadcast 封包以 WSM 的形式來發送還是會對 routing

protocol 造成影響。我們在測詴中發現 routing protocol 還有一些 control message

是 unicast 傳送的，例如 AODV 的 RREP。如過我們忽略了這種封包那麼還是會

對某些 routing protocol 的運作造成影響，因此我們最終決定將所有 routing

protocol 所使用的 control message 一律包裝成 WSM 的格式來發送。

我們的實作方法為，當 WME 抓到上層 routing protocol 要傳送的 control 封

包時就將之包裝成 WSM 的格式，WME 將整個 IP 封包放在 WSM header 中的

WSM data，並且將其中的 WSM version 填入自定義的數字 2 來告知 WSM 的收

端，此封包為 routing protocol 所 broadcast 的 control 封包。當 WME 收到

WSM version 為 2 的 WSM，就將其中的 WSM data 取出送給上層的 routing

protocol。WME 對於此類型封包的處理流程圖請參見圖 4.8。

圖 4.8 WME Broadcast Control Packets for Routing

4.2.2 Support Multi-hop Forwarding Scheme

制改掉，原本的 WME 會在沒有加入或是建立 WBSS 的情形下把所有送入

WME 的 IP 封包丟掉，除非使用者主動在 primitive setting file 要求 WME 建立

或是加入 WBSS。我們將這種限制拿掉，並且加入自動建立 WBSS 的機制，當

WME 收到封包時它會依據 RMFS 或是 SMFS 的機制選擇來建立 WBSS，而且

其它的 WAVE device 也必頇要自動的加入相對應的 WBSS。

原本 WAVE MAC 有維護一個 priority queue，在 MAC de-queue 時就是我們

要發動 RMFS 或是 SMFS 的時機。另外，為了使 WAVE device 可以充分的利用

SCH interval，我們必頇調整 MAC queue 的 size，使得 MAC 將 queue 中的封包

全部傳給對方的總時間大於 SCH interval (50 ms) 。整個系統的運作流程如圖 4.9

所示。

原本的 [10] 定義的 multi-forwarding scheme 中 sender 要將資料送往哪個

forwarder 是依據 position based routing protocol 來決定。現在因為在上層有

ad-hoc routing protocol，因此我們將就可以將封包的傳輸路徑交由其決定。

另外，為了將大家所使用的 channel 錯開，provider 在建立 WBSS 之前會先

去尋找目前使用率最小的 channel 來使用。我們使用的方法為，平常就去收集其

他 node 所發出的 WSA，並且找出此 WSA 所帶的 channel 參數，藉此紀錄

圖 4.9 The Processing Flow of an IP packet in MAC

4.2.3 RMFS Implementation

首先我們先定義 RMFS 中的 sender 與 receiver，在此所說的 sender 是表示

想傳輸 MAC queue 中 data 的 node，sender 可能是原本封包的發送者也可能是

forwarder，receiver 則是要接收 sender 送出 data 的 node，receiver 可能最後 data

的目的端也可能是 forwarder。

以下將介紹 RMFS 中 sender 和 receiver 的狀態。每個 node 同時只能在一

個狀態上停留，不論是 sender 或是 reveiver 其初始狀態都是 RMFS_NONE。所

有的狀態除了初始狀態外其餘都是由其中一種狀態轉變而來。

Sender：

 RMFS_SENDER_WAIT_WBSS

表示 sender 正在等 receiver 建立 WBSS。

 RMFS_SENDER_IS_USER

表示 sender 已經加入 receiver 所建立的 WBSS 成為 user。

Reveiver：