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 傳送封包，也可以透過有線網路來傳送封包，因此包 含了兩種介面。在章節 3.1.1 曾經介紹過此種情並且稱之為 Distribution System。

圖 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，但是在實 做 WAVE system 時 IEEE 1609.5 還未發表，因此我們捨棄了在 WAVE device 上

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 之後，

WME 首先會將 WME-ProviderService.request 的內容記錄在 MIB 中並且開

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

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

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 所示。

圖 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 device 為 provider 則直接將封包向上送，其他情況則直接將封包丟棄。

圖 4.4 The Processing of IP Packets in WME