在NCTUns 網路模擬器上支援IEEE 802.11 無線感知網路並進行效能評估

國

立

交

通

大

學

網路工程研究所

碩

士

論

文

在 NCTUns 網路模擬器上支援 IEEE 802.11 無線感知

網路並進行效能評估

Supporting and Evaluating Performances of IEEE 802.11 Cognitive

Radio Networks over the NCTUns Network Simulator

研 究 生：黃昱銘

指導教授：王協源 教授

1

在 NCTUns 網路模擬器上支援 IEEE 802.11 無線感知網路並進行

效能評估

Supporting and Evaluating Performances of IEEE 802.11 Cognitive Radio

Networks over the NCTUns Network Simulator

研 究 生：黃昱銘 Student：Yu-Ming Huang

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

國 立 交 通 大 學

網 路 工 程 研 究 所

碩 士 論 文

A Thesis

Submitted to Institute of Network Engineering College of Computer Science

National Chiao Tung University in partial Fulfillment of the Requirements

for the Degree of Master

in

Computer Science

July 2010

Hsinchu, Taiwan, Republic of China

i

在 NCTUns 網路模擬器上支援 IEEE 802.11 無線感知網路並進行

效能評估

研 究 生：黃昱銘

指導教授：王協源 教授

國立交通大學 網路工程研究所 碩士班

摘 要

隨著無線網路愈來愈深入的研究與探討，目前可為人所用的無線網路傳輸之協定與 其所使用之頻譜也隨之增加。根據現有的頻段用途與其分配方式，部份頻段需要經過申 請執照的程序後才可使用。但在目前現有的研究就指出，並非所有頻段皆被充份的使用， 這種情況在需要頻段使用執照的頻段更為明顯。因此，在近年來開始發展出一套稱作無 線感知網路的技術，透過這種技術，無線感知網路的使用者可以在不干擾其他頻段的主 要使用者來進行該頻段的使用；而當該位主要使用者欲使用此頻段時，無線感知網路的 使用者便會主動退讓，使主要使用者在頻段的使用上不受干擾。 然而，在現階段對於無線感知網路的研究中所擁有的測詴工具並不多，而且對於更 高層的網路通訊協定之應用程式的支援也相當的有限，使得研究人員在驗證上難以利用 更為複雜的情境來進行效能的評比。因此，本篇論文主要將透過 NCTUns 這套網路模擬 器來進行平台的開發，並從目前既有的無線感測網路的相關研究進行實作，以提供給研 究人員一套完整的無線感測網路之模擬環境，藉此能夠在沒有實體設備的狀況下進行通 訊協定的開發。此外，本文也將基於該無線感測網路之通訊協定，從隱匿終端機問題的 角度進行分析，並且對此通訊協定進行改善，期望能藉此使其效能提升。 關鍵字：無線感知網路、終端機隱匿問題、網路模擬器

ii

Supporting and Evaluating Performances of IEEE 802.11 Cognitive Radio

Networks over the NCTUns Network Simulator

Student: Yu-Ming Huang

Advisor: Dr. Shie-Yuan Wang

Institute of Network Engineering

National Chiao Tung University

Abstract

According to a report about the utilization of spectrum, not all the range of spectrum is fully utilized, especially in licensed bands. In order to solve this problem, the concept of cognitive radio is proposed. Cognitive Radio is a technique which allows cognitive radio users to use channels that are not owned by them without interfering the primary users of channels. In other words, when a cognitive radio user is using a channel without any authorization, it should switch to other channels immediately if a licensed user wants to use this channel so that the licensed user will not be interfered by the cognitive radio users.

Nowadays, simulators that can support the research of cognitive radio networks are very rare. In addition, most of them can only simulate the physical and MAC layers of a cognitive radio network and lack the ability to simulate a cognitive network with high-layer protocols such as TCP/IP. In this thesis, we implement an IEEE 802.11 cognitive radio module on the NCTUns network simulator so that researchers can use it as a base to test their novel ideas. We also study the effects of hidden-terminal scenarios on the performances of cognitive radio networks and propose several enhancements to the basic scheme to improve its performances under hidden-terminal conditions.

iii

誌 謝

在這兩年的研究所生涯中，首先我要感謝我的指導教授王協源老師，不斷的在研究 上給予我指導，也在學術研究上教給我不少知識，使得我對於所鑽研的領域的根基能夠 穩固且紮實。此外老師總是能在我退卻時鼓勵我再對於研究進行更深入的探討，使得我 總是能夠持續進行研究，並且獲得非常豐碩的成果。 此外，在此也要感謝周承復老師、趙禧綠老師、鄭振牟老師，感謝你們願意擔任這 次碩士口詴的口詴委員，並願意給予許多的意見，使得我能注意到很多疏漏的地方，或 是考慮不盡周詳之處。有了各位老師們的指教，相信這篇論文會更好，感謝各位老師在 口詴時給予的指點。 另外，也要感謝實驗室的學長、同學與學弟妹們在這段時間內的支持與幫助，學長 們總是會在平常給予我們一些方向，並且肯花費自己的時間與我們進行討論，使我學到 了很多的東西，也更能釐清自己的思路。而同學與學弟妹們總是能夠協助我分擔一些工 作，並且在適當時機給予我意見或討論，感謝你們陪伴了這兩年的時光。 最後，我要感謝我的父母、以及以前在清華大學與中興大學的老師與同學們，在這 兩年的時間內給予我不少的鼓勵與關心，使我能夠沒有任何的後顧並且往前衝刺，若沒 有了你們，這段生活與研究的成果也將黯淡不少，感謝各位的陪伴。

iv

目 次

摘 要 ... i Abstract ... ii 誌 謝 ... iii 目 次 ... iv 表目錄 ... vi 圖目錄 ... vii 1. 介紹 ... 1 2. 背景 ... 3 2.1. 相關研究... 3 2.2. NCTUNS網路模擬器介紹 ... 5 3. 無線感知網路模擬模組之實作... 8 3.1. 實作之無線感知網路機制介紹 ... 8 3.1.1. 介紹 ... 8 3.1.2. 封包傳輸之前置作業：快速頻道感測... 9 3.1.3. 傳輸之後置作業：主動釋放頻道 ... 11 3.2. 無線感知網路模組之實作 ... 12 3.2.1. 概要 ... 13 3.2.2. NCTUns 相關節點與模組 ... 13 3.2.3. 實作 ... 15 4. 原有機制之改良 ... 26 4.1. 原有機制之效能增討論 ... 26

v 4.2. 改進之方法與其設計實作 ... 31 4.2.1. 頻段挑選機制 ... 31 4.2.2. 資料傳輸頻段感測機制之改良 ... 33 4.2.3. SIFSCR後資料傳輸之改良... 34 5. 效能評估與分析 ... 36 5.1. 理論值之推導與估計 ... 37 5.2. 無終端機隱匿問題的模擬情境之效能評估 ... 45 5.3. 在終端隱匿之情境之效能比較 ... 60 6. 未來展望 ... 75 7. 結論 ... 77 8. 參考文獻 ... 78

vi

表目錄

表 1、於效能評估中的參數設定。 ... 37 表 2、改良機制與原有機制對無線感知網路在無終端機隱匿問題的 MAC 層之流量傳輸 效能比較。 (單位：Mbps) ... 51 表 3、改良機制與原有機制對於無線感知網路在無終端機隱匿問題以 MAC 層之協定直 接進行流量傳輸的 Round-Trip Delay 比較。 (單位：ms) ... 53 表 4、改良機制與原有機制對無線感知網路在無終端機隱匿問題的 TCP 之流量傳輸效能 比較。 (單位：Mbps) ... 57 表 5、改良機制與原有機制對於無線感知網路在無終端機隱匿問題以 TCP 通訊協定來進 行流量傳輸的 Round-Trip Delay 比較。 (單位：ms) ... 60 表 6、改良機制與原有機制對無線感知網路在終端機隱匿問題的 MAC 層之流量傳輸效 能比較。 (單位：Mbps) ... 65 表 7、改良機制與原有機制對於無線感知網路在終端機隱匿問題下以 MAC 層之協定直 接進行流量傳輸的 Round-Trip Delay 比較。 (單位：ms) ... 67 表 8、改良機制與原有機制對無線感知網路在終端機隱匿問題的 TCP 之流量傳輸效能比 較。 (單位：Mbps) ... 72 表 9、改良機制與原有機制對於無線感知網路在終端機隱匿問題下以 TCP 通訊協定來進 行流量傳輸的 Round-Trip Delay 比較。 (單位：ms) ... 74

vii

圖目錄

圖 1、NCTUns 模組化之平台。 ... 6

圖 2、實作之無線感知網路模組之機制流程圖。... 9

圖 3、遭遇某一頻段無法使用之狀況的處理。 ... 11

圖 4、在 NCTUns 中對於 IEEE 802.11b Ad-hoc 模式之節點的通訊協定堆疊。 ... 14

圖 5、本次實作之類別圖。 ... 16 圖 6、RTSCR之表頭結構。 ... 17 圖 7、RTI 之表頭結構。 ... 17 圖 8、發送端之行為狀態循環圖。 ... 19 圖 9、接收端之行為狀態循環圖。 ... 20 圖 10、不適用於原先 NCTUns 感測頻段忙碌流程之實例。 ... 22 圖 11、由終端機隱匿問題之情境來考慮決策者的選定。 ... 27 圖 12、當頻段感測到 ACK 後，即使頻段接下來無任何使用者使用，仍需切換頻段。 ... 28 圖 13、在終端隱匿問題下，傳送端的行為反應。 ... 30 圖 14、閒置記錄與評分方式之示意圖。 ... 31 圖 15、修改後的 RTSCR之結構。 ... 32 圖 16、修改後的 CTSCR之結構。 ... 33 圖 17、修改後的頻段感測之決策機制。 ... 34 圖 18、無終端機隱匿問題情境下的拓樸。 ... 46 圖 19、原有機制於無終端機隱匿問題之情境下，在封包到達率為 1 之流量樣式中，無線 感知網路使用者的效能。 ... 47 圖 20、原有機制於無終端機隱匿問題之情境下，主要使用者的效能。 ... 48 圖 21、改良之機制於無終端機隱匿問題之情境下，在封包到達率為 1 之流量樣式中，無

viii 線感知網路使用者的效能。 ... 49 圖 22、改良機制於無終端機隱匿問題之情境下，主要使用者的效能。 ... 49 圖 23、原始之機制於無終端機隱匿問題之情境下，在封包到達率為 1 之流量樣式中，無 線感知網路使用者的 Round-Trip 延遲時間。 ... 52 圖 24、原始之機制於無終端機隱匿問題之情境下，在封包到達率為 1 之流量樣式中，無 線感知網路使用者的 Round-Trip 延遲時間。 ... 52 圖 25、原有之機制於無終端機隱匿問題之情境下，無線感知網路使用者以 TCP 做為傳 輸協定的效能。 ... 54 圖 26、原有之機制於無終端機隱匿問題之情境下，無線感知網路使用者以 TCP 做為傳 輸協定時，主要使用者的效能。 ... 54 圖 27、改良之機制於無終端機隱匿問題之情境下，無線感知網路使用者以 TCP 做為傳 輸協定的效能。 ... 55 圖 28、改良之機制於無終端機隱匿問題之情境下，無線感知網路使用者以 TCP 做為傳 輸協定時，主要使用者的效能。 ... 56 圖 29、原始之機制於無終端機隱匿問題之情境下，以 TCP 作為進行封包之方法時，無 線感知網路使用者的 Round-Trip 延遲時間。 ... 58 圖 30、改良之機制於無終端機隱匿問題之情境下，以 TCP 作為進行封包之方法時，無 線感知網路使用者的 Round-Trip 延遲時間。 ... 59 圖 31、終端機隱匿問題情境下的拓樸。 ... 61 圖 32、原有機制於無終端機隱匿問題之情境下，在封包到達率為 1 之流量樣式中，無線 感知網路使用者的效能。 ... 62 圖 33、原有機制於無終端機隱匿問題之情境下，主要使用者的效能。 ... 62 圖 34、改良之機制於無終端機隱匿問題之情境下，在封包到達率為 1 之流量樣式中，無 線感知網路使用者的效能。 ... 63 圖 35、改良之機制於無終端機隱匿問題之情境下，主要使用者的效能。 ... 64

ix 圖 36、原始之機制於無終端機隱匿問題之情境下，無線感知網路使用者的 Round-Trip 延遲之量測。 ... 66 圖 37、改良之機制於無終端機隱匿問題之情境下，無線感知網路使用者的 Round-Trip 延遲之量測。 ... 66 圖 38、原有之機制於無終端機隱匿問題之情境下，無線感知網路使用者以 TCP 做為傳 輸協定的效能。 ... 69 圖 39、原有之機制於無終端機隱匿問題之情境下，主要使用者的傳輸效能。 ... 69 圖 40、改良之機制於無終端機隱匿問題之情境下，無線感知網路使用者以 TCP 做為傳 輸協定的效能。 ... 70 圖 41、改良之機制於無終端機隱匿問題之情境下，主要使用者的傳輸效能。 ... 71 圖 42、原始之機制於無終端機隱匿問題之情境下，無線感知網路使用者以 TCP 做為傳 輸協定時的 Round-Trip 延遲時間。 ... 73 圖 43、改良之機制於無終端機隱匿問題之情境下，無線感知網路使用者以 TCP 做為傳 輸協定時的 Round-Trip 延遲時間。 ... 73

1

1. 介紹

隨著無線網路愈來愈深入的研究與探討，目前可為人所用的無線網路傳輸之協定與 其所使用之頻譜也隨之增加。然而隨著技術與其搭配的頻譜的不同，這些可使用的頻譜 也被切割成多個區塊，並且被分配給特定的使用者，並給予其執照，這類使用者在本論 文中稱之為主要使用者 (Primary User，簡稱 PU)；此外，某些頻段也被劃分成為一般使 用者皆可使用之頻段，如 2.4 GHz、5.8 GHz 等。但是，根據近年來對於這些頻譜使用情 形之研究指出多數的頻段其使用率並不高，亦即這些頻段的使用者並非完整運用這份資 源，而是這個頻段在多半的時間均維持在閒置的狀態，這樣的狀況尤其在需要持有合法 執照才能使用的頻段較為嚴重；但在其他頻段中卻容易出現頻段使用擁塞之情況，使得 在此頻段之可用資源嚴重不足[1]。因此在考慮在一般較少持有執照之主要使用者的情況 下，若此處的使用者均使用某些特定頻段，但這些頻段無法承受如此多之使用者，在這 樣的狀況下可見頻段的使用並不合實際需求。因此，便有人想到了無線感知網路 (Cognitive Radio) 之概念，希望在不影響正式使用者的情況下，能夠借用其頻段的資源 來進行傳輸，藉此能夠使一般使用者能順利進行資料傳輸，也能提高其頻段的使用效 能。

無線感知網路的實作概念最早是由 Joseph Mitola III 與 Gerald Q. Maguire, Jr 在 1999 年於[2]提出，內容主要是提出一套無線電知識表示語言 (Radio Knowledge

Representation Language)並搭配軟體無線電 (Software Radio) 之硬體平台來使得無線網 路設備能利用軟體調整參數的方式來控制硬體所使用的頻段與訊號強度等之控制，如此 能協助無線網路設備得以取得或分享其所需要之資訊，進而讓其能夠擁有找尋自己所需 要之傳輸頻段的能力。

而無線感知網路的定義方面，在第一段中曾提及在近年來頻譜已受特定之機構進行 切割與配置，因此在每個已分配的頻段中都會存在一些擁有合法使用執照的使用者，稱 為主要的使用者 (Primary Users，簡稱 PU)。而對比於這些使用者，另外還有一些使用

2

者則為次要的使用者 (Secondary Users，在本論文中這些使用者被稱作 CR Users)，這些 使用者他們若需要使用那些需要授權才能使用的頻段時，需要進行一些偵測的動作以找 出主要使用者在傳輸時的空閒時間，藉此以避免干擾到主要使用者利用這些頻段的動作， 畢竟這個頻段本身就並非這些次要的使用者獲得授權而可以使用的。 然而，在現階段對於無線感知網路的研究中所擁有的測詴工具並不多，而且對於更 高層的網路通訊協定之應用程式的支援也相當的有限，使得研究人員在驗證上難以利用 更為複雜的情境來進行效能的評比。因此，本篇論文主要由目前既有的無線感測網路的 相關研究進行實作，以提供給研究人員一套完整個無線感測網路的模擬環境，藉此能夠 在沒有實體設備的狀況下進行通訊協定的開發。此外，本文也將基於該無線感測網路之 通訊協定進行改善，期望能藉此使其效能提升。 因此，接下來的章節配置如底下所示：在第二章中將會介紹目前已有的無線感測網 路的相關研究；此外，也會針對本篇論文於實作時所使用的網路模擬器── NCTUns [3] 進行介紹。第三章將會介紹在本篇論文中用以實作的無線感知網路之通訊協定，並會介 紹如何將其實作於 NCTUns 這套網路模擬器內。而在接下來第四章的部份則會對於這一 個通訊協定進行改善，使得在終端機隱匿問題 (Hidden-Terminal Problem) 的情境下依然 能夠維持其良好的傳輸效能。在第五章的部份，本篇論文將提出數個模擬情境，並針對 於第三章與第四章進行之模組開發設計的結果進行模擬與分析。而在最後兩章則分別為 結語與未來發展的部份。

3

2. 背景

承接第一章的部份，無線感知網路自概念發表至今已歷經了不短的時間，在這幾年 之間，各種想法與實作技巧也日益增加與成熟，因此在本章節中將展示在進行此篇論文 之研究過程中所進行的相關研究之探討。此外也將介紹在本論文中用以實作之模擬器─ ─ NCTUns。

2.1. 相關研究

在相關研究的調查上，由於本篇論文在最初著重於開發無線感知網路之模擬環境， 因此在進行探討上主要是先以無線感知網路相關模擬器為主，接著是進行是否有與此研 究相關的論文提出了幾種不錯的設計機制。而在相關模擬器的部份，目前大多數已發表 的期刊論文中大多都是以自行撰寫一支程式，並且套用自行研究之無線感知網路之模型 以進行驗證。除此之外，仍然還有一些組織詴圖進行更精細的模擬平台之開發，如[4] 與[5]。在目前[4]已在 NS-2 進行相關的模組開發，當中設計了無線感知網路路由模組、 MAC 模組、以及透過多重頻段之機制設計了 PHY 模組。但由於 NS-2 中對於較高層應 用程式的支援在使用上較為繁雜，因此在此考慮使用其他模擬器來進行環境的開發。而 在[5]中則提供了另一種稱作 Agent-Based 的模擬機制，並以訊號的角度進行精細的模擬， 以挑選合適的頻段，但這可能無法對於更高層應用程式進行支援。 除了模擬平台的設計之外，目前已有不少成熟的無線感知網路在 MAC 機制之設計。 其中在[6][7][8]中對無線感知網路提供了一個完整的介紹，並且探討了很多對於無限感 知網路中的某些機制設計的相關文章。[6]本身較著重提供一個完整的流程，使得在進行 相關的研究中可以知道無線感知網路之研究領域約可以劃分成哪些項目，並從中進行相 關文章之整理。此外，[7]主要是針對頻段感測之演算法來進行相關研究的分類與探討， 這篇文章對於這份論文在改進機制的設計與研究上給予了相當大的啟發。而[8]是針對多

4 頻段的無線感知網路之 MAC 來進行目前研究上探討並分類。而於[9][10][11]這幾篇論文 中各自提供了一套完整的機制，藉著使用這套機制能使得感知網路的使用者在不干擾主 要使用者的情況下進行傳輸。特別是在[9]中介紹了一套機制，使得在傳輸的過程中並不 需要額外仰賴控制資料傳輸頻段。除此之外，在研讀這些相關研究中也發現，目前現存 透過控制資料傳遞頻段進行無線感知網路機制設計之研究中，大多數的設計上均是透過 類似 RTS-CTS 的機制先行在控制頻段進行溝通，之後才切換至資料控制頻段，如[10] 與[11]中即如此。其中[10]這篇在無線感知網路的設計上保留了不少的彈性，使得無線感 知網路的使用者在其效能上仍然有一定的水準，使人印象深刻。最後是[11]中提供了以 統計的方式來進行頻段配置的一種無線感知網路的機制。 而除了完整的 MAC 機制設計之外，頻段的決定往往會影響日後無線感知網路的使 用者在進行傳輸時的效能，為了檢視是否能有可以運用並與前段所找出的 MAC 機制結 合的頻段存取機制，在頻段存取的相關研究方面也進行了一些相關研究的研讀，其中， [12][13][14]則是提出了多種頻段存取的演算法，藉由這些演算法能使得在進行頻段存取 更有效率。其中[12]提出了基於傳輸能量與以實體層之 Preamble 封包為底的頻段存取與 分析之演算法；而[13]則是提出了一套稱作預測性的動態頻段存取 (PDSA) 的想法，透 過此想法可對主要使用者進行頻段使用進行分析，並嘗詴找出可用的空閒頻段；[14]則 是以分析與歷史記錄的角度詴圖逼近頻段預測的方式建造出一套預測模型。這些方式均 有助於無線感知網路使用者進行頻段使用的規劃。 透過這些相關研究的研讀，可以了解到目前無線感知網路的機制設計上大略可分為 頻譜的感測、頻譜的使用與頻譜的共享機制，透過這些機制的統合能夠給予無線感知網 路的使用者一套完整的傳輸方式，使其能透過使用多個頻段來進行資料傳輸。而在經過 仔細研讀後，由於[10]中在設計上具有清楚且完整的架構，此外其機制也提供了不小的 彈性，因此本篇論文將接續[10]的研究，將此環境設計在 NCTUns 網路模擬器上，並在 此環境中對此機制進行改良。

5

2.2. NCTUns 網路模擬器介紹

在本篇論文的實作主要是採用 NCTUns 網路模擬器，這一套網路模擬器主要是由國 立交通大學所發展出的一套網路模擬器，至今支援了多種網路架構如：Ethernet、光纖 網路、IEEE 802.11 a/b/e/p、GPRS、WiMAX (IEEE 802.16 d/e/j)、衛星網路 DVB-RCS 等， 使得使用者能夠按照其所設計的模擬情境以進行模擬。而這套網路模擬器具備以下之優 點，這也是在本篇論文研究中採用此模擬器之主因：

 其使用了真實世界中所用的傳輸層與網路層的協定堆疊 (Protocol Stack)，進而 能產生更精確的模擬結果。

 真實世界的應用程式大多在不經修改的情形下可以直接運行於此模擬器上。  具有高度整合性的使用者圖形化介面 (Graphical User Interface) ，使得模擬情境

的設計更為簡潔。

而為了支援以上的優點，在其架構的設計上則包括了幾個基本的元件：(1) 修改後 的 GNU/Linux 核心、(2) NCTUns 圖形化使用者介面、(3) NCTUns 模擬引擎、(4) NCTUns 協定模組 (Protocol Modules)。透過對於 GNU/Linux 核心的修改，其可讓真實世界中所 用的利用 Socket 介面撰寫之網路應用程式能夠在不經修改的情況下，使其可直接做為模 擬情境中的某一部網路設備上所運行的應用程式，藉此可模擬其在各種網路下的運作行 為。而在圖形化使用者介面的部份則提供了一般使用者可直接以所見即所得的方式進行 拓樸的設計規劃，使得使用者可以在不用學習任何腳本 (Script) 設計的情況下進行拓樸 規劃。而在 NCTUns 模擬引擎的部份，則提供了對於時間、事件、排程、封包裝填等重 要的部份一套完整的 API，，使得開發者能夠對此容易上手。最後則是協定模組的部份， 其對於任意模擬的網路設備的協定堆疊 (Protocol Stack) 採用了模組化的設計，透過此

6 設計可以使得使用者在開發自己所需的模組後，只需要以替換或加入此模組的方式，即 可使得其所設計之模組得以直接在模擬世界中運行。 圖 1、NCTUns 模組化之平台。 圖 1 呈現了 NCTUns 之模組化模擬平台，這張圖分為上半部份與下半部份，其中上 半部份為作業系統中使用者層級的應用程式，其中包括了流量產生的應用程式，在此稱 為 Traffic Generator、NCTUns 模擬引擎，而底下的部份則為系統核心的部份。而由圖片 左邊開始，可以看到一個在使用者層級之 Traffic Generator，這個程式是以 Socket 介面 來撰寫的，並詴圖透過 TCP/IP 的通訊協定將封包傳往圖片右側的應用程式接收端。當 左方的應用程式送出封包時，它會先透過系統核心的 Socket 層，接下來則是傳輸層的 TCP 表頭 (Header) 的包裝與處理、網路層 IP 表頭的包裝，最後到達系統核心內的一個 虛擬的網路介面卡稱作 Tunnel 介面，透過此介面送出的封包將會被導至 NCTUns 模擬 引擎內進行模擬。當封包傳入模擬引擎時，此時封包會先經由 Interface 模組進入模擬引 擎，並且經過模擬的協定堆疊：ARP、FIFO、802.3、PHY 及 LINK 模組，然後轉往中

7 間模擬的交換器 (Switch) ，同樣的這個封包也會遵守裡面所配置的模組，並依：LINK、 PHY、802.3、FIFO、Switch 模組順序往上收，接下來再由交換器送出，並傳至右端的 用戶端設備，其所經模組可以此類推。直至傳到右端的 Interface 模組，此時此模組會將 此封包透過寫入 Tunnel 介面的方式送至系統核心，系統核心會進行判斷此是否為該設 備之封包，是的話會往上層送；不是的話則會協助此封包之路由轉送。而接收的部份仍 是經由 IP 層、TCP 層、Socket 層，最後會由右方 Traffic Generator 的 read()讀取。

而根據這樣的流程，為了在設計上的一致性與便利性，因此每一模組均繼承自 nslobject 這個類別，並根據模組在設計規劃上的不同，實作出不同的 send 與 recv 兩個 成員函式，使得封包在抵達此模組時能夠順利的被處理。而在這些函式內可透過如計時 器、事件的產生、新增封包的方式來達到在各種不同網路規格書內所刊載的處理程序， 使得各式各樣的網路能夠輕易的在此平台上進行開發設計並模擬。 而由於本節主要用於概略介紹 NCTUns 這套網路模擬器，且在本論文中實作的部份 主要是著重在模組的改寫上，因此更多關於模組設計上的細節則在此不進行更深入的描 述，詳細的模組開發與設計方法可參考[15]。

8

3. 無線感知網路模擬模組之實作

本章主要將介紹在本論文中將實作之無線感知網路的通訊機制，並且說明如何將此 實作於 NCTUns 這套網路模擬器上，使得一般研究人員能夠運用此模擬器與相關模組， 進行更進一步的研究與效能評估。

3.1. 實作之無線感知網路機制介紹

3.1.1. 介紹

在第二章的相關研究成果的部份，其中，[10]在 IEEE 802.11 之無線網路中提供了一 套極為清楚且簡單的機制，並在機制中留下了一些可進行設定與的變數。這套機制主要 分成兩個階段：快速頻道感測 (Fast Channel Sensing) 與主動釋放頻道。透過這兩階段 的評估與無線感知網路之使用者的行為，可以達到在不干擾主要使用者的情況下，無線 感知網路之使用者在傳輸上的效能也能夠有一定的水準。因此，在本篇論文中將以這個 協定為基礎，將其實作於 NCTUns 這套網路模擬器中。 而在這套機制中，它將使用之頻段分為控制封包傳輸頻段 (Control Channel) 與資 料傳輸頻段 (Data Channel) ，在最初的狀態中，所有的無線感知網路使用者均在控制封 包傳輸頻段中交換訊息，直到當有使用者需要進行資料傳輸時，才會透過控制封包傳輸 頻段向接收者約定接下來應該要在哪一個資料傳輸頻段進行資料傳輸。在約定完成後， 雙方即會切換使用頻段至該資料傳輸用之頻段以進行資料傳輸，待傳輸完成，兩位使用 者才會逕行回到控制封包傳輸頻段等待其他的資料傳輸。 整體傳輸之流程圖如下所示：

9 圖 2、實作之無線感知網路模組之機制流程圖。

3.1.2. 封包傳輸之前置作業：快速頻道感測

如圖 2 所示，這一套機制中提出了三種新型態的控制封包，這三種控制封包分別稱 作 RTSCR、CTSCR、RTI。而在其中進行握手動作 (Handshaking) 的控制封包則如下所示： (1) RTSCR：如同在 IEEE 802.11 中制訂的 RTS 控制封包類似，RTSCR本身是用來進行資 料交換前的溝通，但這個控制封包主要是由無線感知網路的發送端送出， 使其能與接收端在控制封包傳輸頻段進行在後續資料的交換上的握手動作 (Handshaking) ，如此能讓接收端得知接下來所使用的資料傳輸頻段之資訊。 而在本設計機制中，在此使用了一套稱作快速頻段感測 (Fast Channel Sensing) 之機制，這套機制中，使用者僅需要提供兩種資料：初始頻段 (Initial Channel) 、切換頻段遞增值。這兩個值與快速頻段感測之機制將會 在之後介紹。 (2) CTSCR：如同在 IEEE 802.11 中制訂的 CTS 控制封包類似，CTSCR本身是用來進行 資料交換前的溝通，但和前面 RTSCR不同的地方則是：它本身是接收端用

10 以回應傳送端 RTSCR所用的，在內容的部份則不帶有任何與頻段相關之訊 息。 快速頻段感測之機制內容主要由初始使用頻段、切換頻段遞增值構成，其代表的意 義是在需要使用資料傳輸頻段時，最一開始使用的頻段即由初始頻段 (Initial Channel) 來決定。但若因為某些特殊理由而無法使用這些頻段，則代表傳送者與接收者需要再找 下一個資料傳輸頻段來進行資料傳輸，此時它們所用到的頻段將會是目前所在頻段加上 切換頻段遞增值，若相加後的值大於總使用之頻段數，則會以取餘數加一的方式處理。 以數學示表示如下：〈Ch(i)代表第 i 次切換所使用的頻段，其值域為 ；h 則代表切換頻段遞增值；N 則為總頻段數。〉 而為了避免在切換頻段時所切換的頻段只集中在某些特定頻段，因此另外的規定則 是 N 與 h 需互質，亦即 G.C.D(N, h) = 1。

11 圖 3、遭遇某一頻段無法使用之狀況的處理。 而在此處所提到的「為某些特殊理由而無法使用這些頻段」的例子如圖 3 所示，圖 中可以看到，在此無線感知網路之機制下，當傳送端與接收段切換至資料傳輸頻段時， 它們會進行頻段感測的動作，之後並判斷是否能夠使用該頻段。若無法使用該頻段，則 會在等待的時間區間 (Waiting Period) 之後，雙方一起切換至下一個頻段。而等待時間 區間則是用以讓無線感知網路的使用者在資料控制頻段進行 RTS、CTS 之握手動作用的， 若在此時間內未完成 RTS、CTS 之訊息交換，則代表此頻段可能正有使用者在使用中。

3.1.3. 傳輸之後置作業：主動釋放頻道

而在一次的資料傳輸完成後，為了避免干擾到此頻段的主要使用者，因此在 ACK 控制封包傳輸完成後，感知網路使用者的傳送端會送出一種控制封包稱作 RTI

12 〈Ready-To-be-Interrupted〉。當這個控制封包送出時，感知網路使用者的傳送端與接收 端雙方均要等待一段稱作 SIFSCR的時間。這段時間主要是用以讓主要使用者有辦法表 達他想要使用該頻段的意願，亦即標題的「主動釋放頻道」。因此，若無線感知網路的 使用者在此時間區間內收到任何的訊息，那很有可能就代表有主要使用者想使用該頻段， 他們應該要回到控制封包傳輸頻段重新約定接下來應該要使用哪個頻段進行傳輸。 但是若此時沒有任何使用者在此頻段，或是主要使用者沒有意願傳輸的情況下，若 只傳了一個資料封包即需要重新再次決定下一個封包應該使用哪一個頻段，這樣的情況 下需要再次切換回控制封包交換頻段、交換 RTSCR、CTSCR、切換至資料傳輸頻段、進 行頻段感測，如此會需要額外再花費時間進行這些動作。因此為了減少這些時間的花費， 在此定義一種稱作 TxOPCR的參數，這個參數的意義主要是定義允許無線感知網路能在 同一個資料傳輸頻段內進行資料傳輸的最大次數，當無線感知網路之使用者在等待完 SIFSCR之時間間隔後，若此時沒有其他使用者進行資料傳輸，則傳送端即可直接再送出

一個 DATA 封包給接收端，而後續動作仍為 ACK 與 RTI 的交換，如此即使用了第二次

的傳送機會。若接下來仍然沒有其他使用者，則此狀況將會持續到其使用了第 TxOPCR 次的傳輸機會為止，屆時此二使用者仍需回到控制封包傳輸頻段再次進行 RTSCR、CTSCR 的交換。

3.2. 無線感知網路模組之實作

在了解所要實作的無線感知網路之機制後，本節將介紹如何將此實作於 NCTUns 這套網路模擬器內。因此本節會先為本篇論文實作的內容進行概略性的介紹，接下來會 針對 NCTUns 內的環境進行更進一步的介紹，再來會說明如何進行實作。

13

3.2.1. 概要

根據 3.1 節的敘述，可以了解該無線感知網路之機制。而這些有別於原始 IEEE 802.11 DCF MAC 的部份可簡單區分為底下幾點：  控制封包 RTSCR、CTSCR、RTI 的新增。  多重頻段之切換與感測。  Ready-To-be-Interrupted 之機制的實作。 這套機制主要是以 IEEE 802.11 所制定的規格為基礎來進行延伸。而在目前 NCTUns 這套模擬器上對於 IEEE 802.11 系列之網路的支援為 IEEE 802.11a、IEEE 802.11b、與無 線車載網路 IEEE 802.11p，其中前二者的 MAC 層在實作時均為 DCF 的實作，與目前之 情境較為相似，因此本次即先從中挑選其一。而為了進行驗證本身的實作的正確性，因 此在此先以 IEEE 802.11b 的實作為主。此外，在此模擬器內使用 IEEE 802.11b 的節點中 支援了 Infrastructure 模式與 Ad-hoc 模式，考慮到往後對於多段 (Multi-hop) 傳輸研究上 的彈性，因此在本次的實作中會以 Ad-hoc 的網路節點為主。 而在實際應用的情況，這些機制可以在單一天線與多天線之情況下均適用。但考慮 到 IEEE 802.11b 的實作中均以單一傳送接收設備為主，亦即在同一時間點內只能使用單 一頻段。因此在實作中主要著重在「在同一時間點只能感測與使用單一頻段」的情境下， 使得此無線感知網路之機制能以在此模擬器上運作。

3.2.2. NCTUns 相關節點與模組

如 3.2.1 中所述，在此實作中主要是以 IEEE 802.11b 的 Ad-hoc 模式做為實作之主要 對象，而在原本的節點中其在 IP 層以下的通訊協定之堆疊如圖 4 所示：

14

圖 4、在 NCTUns 中對於 IEEE 802.11b Ad-hoc 模式之節點的通訊協定堆疊。 於先前 2.2 節提到，NCTUns 本身使用了利用 GNU/Linux 本身所提供於真實世界中 所使用的傳輸層與網路層的通訊協定堆疊的方式，協助我們避免需要自己模擬這些部份 進而使得模擬嚴重失真的狀況。當一個封包由某個節點發送時，它會經過系統核心，並 且送到對應的 Tunnel 介面。在送至 Tunnel 介面時，此時，該 Tunnel 介面的裝置驅動程 式會發出通知，使得在圖 4 中最頂端的 Interface 模組會從對應的介面中將此封包導引至 模擬的世界中。而在圖 4 所呈現的通訊協定堆疊模組各自的功用則如下所示：  Interface 模組：用以記錄 IP 位址與 MAC 位址對應之關係，此外也協助處理封包自 Tunnel 介面的讀取與寫入之工作，使得封包能順利被引導至模擬的 世界中，或是送至系統核心內進行路由處理、甚至是被對應的應用 程式接收。

 GOD 模組：此模組用以協助 Ad-hoc 模式下，MAC 層路由的處理。這個模組主要 會透過 NCTUns 使用者圖形化介面在模擬前即計算好在模擬時哪些節 點之間有能力直接進行傳輸，並在模擬時實際根據此運算結果進行處 理。

15

 ARP 模組：此模組用以處理 ARP (Address Resolution Protocol) 之相關行為的模擬。  FIFO 模組：用以模擬由網路層與資料連結層之間的緩衝佇列。

 MNode 模組：MNode 即為 Mobile Node，在此模組中主要負責從網路層傳下來的封 包進行包裝 MAC 表頭 (Frame) 的處理；此外也隨著節點的不同，此 模組會協助其發送 MAC 層的封包，如 BEACON 等，但不包括 RTS、 CTS、ACK 等涉及於其動作行為封包的產生。  MAC80211 模組：用以模擬 IEEE 802.11 DCF 之行為的模組。  WTCPDUMP 模組：用以協助 tcpdump 這支工具程式對於無線網路封包的支援，使 其能捕捉到在模擬世界中的封包。  Wphy 模組：用以模擬 IEEE 802.11 之規格下所定義的實體層。  CM 模組：用以模擬無線傳輸中訊號衰減處理的模組，目前支援多個在期刊與會議 中已發表的理論或實際量測而得到的訊號模型。 由於在本次實作的內容均與 MAC 之行為與實體層之訊號感測之部份相關，因此在 實作上只需要更改 MAC80211 與 Wphy 這兩個模組，其他模組可維持不變，如此即可完 成整個系統的設計。在下一個段落中將介紹本論文對於這兩個模組進行哪些修改與設計， 使得欲模擬的機制得以順利進行模擬。

3.2.3. 實作

承接 3.2.1 所描述的通訊協定堆疊，在本次的實作中僅需針對 MAC80211 與 Wphy 這兩個模組進行更改。但為了使得一般的使用者與使用無線感知網路的使用者能夠並存， 因此勢必需要產生新的模組。因此，在最一開始即複製整個 MAC80211 與 Wphy 模組，

16

並在其後加入_CR 之字串以示區隔。而完成後的類別名稱則為 mac802_11dcf_CR 與 wphy_CR。而整個的修改架構則如圖 5 的簡化後之類別圖所示：

mac802_11dcf_CR

- Log File Pointers: FILE* - Related counter:Integer - Contention Window Size: Integer - Related Timers: timerObj* - Related Packet Buffer: ePacket_*

- nav: 64-bit Unsigned Integer [0..MAX_USABLE_CHANNEL] - mhSense: timerObj* - mhWait: timerObj* - mhRTI: timerObj* - mhSIFS_CR: timerObj* - epktTxBuf: TxQueue* - epktRTS_CR: ePacket_* - epktCTRL_CR: ePacket_* - txOP_CR: Integer - channel_ctrl: CRChannel_Ctrl* - action_state: enum ActionState + init() + send() + recv() + log() + SwitchChannel() - check_pktCTRL_CR(): Integer - check_pktRTS_CR(): Integer - senseChHandler(Event_ *): Integer - waitHandler(Event_ *): Integer - RTIHandler(Event_ *): Integer - sensePUHandler(Event_ *): Integer - sendRTS_CR(u_char*): Void - sendCTS_CR(u_char*): Void - sendRTI(u_char*): Void - retransmitRTS_CR(): Void - recvRTS_CR(ePacket_*): Void - recvCTS_CR(ePacket_*): Void - recvRTI(ePacket_*): Void - start_sensetimer(u_int32_t): Void - start_waittimer(u_int32_t): Void - start_RTItimer(u_int32_t): Void - start_SIFS_CRtimer(u_int32_t): Void - start_fastSensetimer(u_int32_t): Void CRChannel_Ctrl - mac_module_: mac802_11dcf_CR* - wphy_module_: wphy_CR* - current_channel_: Integer - control_channel_: Integer - initial_channel_: Integer - inc_per_hop_: Integer

- nav: Unsigned 64-bit Integer[0..MAX_USABLE_CHANNEL] + GetCurrentChannel(): Integer + GetInitialChannel(): Integer + GetIncPerHop(): Integer + SetControlChannel(Integer): Void + SwitchToTheNextChannel(): Integer + BackToTheControlChannel(): Void + SetChannelInf(Integer, Integer): Void + GenerateChannelInf(Integer&, Integer&): Void + UpdateChannelStatus(Packet*): Void + IsCurrentChannelIdle(): Boolean

1 1

- Log File Pointers: FILE* - Physical Attributes: double - channel_: Integer

- channel_ctrl: CR_ChannelCtrl * + init(): Integer

+ recv(): Integer + send(): Integer

+ command(int, char*[]): Integer + log(): Integer

+ BitError(double): Integer

+ Link Flag Related Functions(): Void + SwitchChannel(int): Void + getCurrentChannel(): Integer + InitChannelCtrlPtr(CR_ChannelCtrl*): Void Wphy_CR 1 1 - epktTxBuf: std::list<ePacket_*> - max_size: Integer + Enqueue(ePacket_*): Void + Dequeue(): ePacket_* + GetCurrentQueueLen(): Integer + IsEmpty(): Boolean + IsFull(): Boolean

+ SetSize(unsigned int): Void + Clear(): Void TxQueue 1 1 圖 5、本次實作之類別圖。 其中為了簡單呈現，因此在類別成員與類別方法僅詳細列出本次所新增的部份，其 餘部份則予以簡化。從中可以看到在修改後，主要是以 mac802_11dcf_CR 做為

17

MAC80211CR 模組之實作類別，而 Wphy_CR 則為 WphyCR 模組之實作類別。至於其 他尚有 CRChannel_Ctrl 與 TxQueue 這兩個類別，第一個類別主要是用來進行頻段操作 之相關動作；而第二個類別 TxQueue 則是用來做為連續資料封包的緩衝區維護之類別。 這兩個類別將分別在 3.2.3.2 與 3.2.3.3 中詳加描述。

3.2.3.1. 控制封包的新增與行為狀態之維護

 控制封包的新增 在這次的實作中一共有三個控制封包需要新增，分別為 RTSCR、CTSCR、RTI。針對 前二者之封包，可利用原先之 RTS、CTS 封包進行更改。其中，由於 CTSCR僅用為回應 傳送端，使傳送端了解接收端已同意這次的傳輸，因此整個表頭的設計與原本的 CTS 一樣之外，RTSCR則配合了該無線感知網路的機制而做些許修改，其表頭結構如下： Frame

Control Receiver Address Transmitter Address

Initial Channel Inc Per Hop Frame Duration 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 FCS 21 22 23 24 圖 6、RTSCR之表頭結構。 Frame

Control Receiver Address FCS last

Frame Duration 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 圖 7、RTI 之表頭結構。 修改後的結構仍與 RTS 相似，不同之處在於 RTSCR需要帶的兩個參數則置於最後 面。而除了 RTSCR與 CTSCR之外，尚有 RTI 之控制封包。這個封包的部份以 ACK 之控 制封包來進行實作，並加上通知接收端是否還有封包要傳送的資訊。

18 在決定完控制封包的資料結構後，僅需要參考之前處理 RTS、CTS、ACK 的設計， 即可將此部份的產生控制封包、傳送控制封包的行為處理完成。對應先前的設計，為了 產生與填寫控制封包，在此需要實作 sendRTS_CR、sendCTS_CR 與 sendRTI 這三個填 寫表頭欄位之相關的函式，其中 sendRTS_CR 負責產生 RTSCR；sendCTS_CR 則是用以 產生 CTSCR之封包；最後 sendRTI 則是產生 RTI 而使用的。在實作完成後，需將此三個 函式填入對應的地方，以使其能在正確的時間點被執行。其中 sendRTS_CR 主要是在當 有封包抵達此模組時第一個進入的函式 send 進行呼叫；而 sendCTS_CR 則是在收到 RTSCR時對應的處理函式 recvRTS_CR 進行呼叫；最後在接收到 ACK 時的處理函式 recvACK 則是檢查是否還有其他封包要傳送與呼叫 sendRTI 函式。 除了填寫表頭欄位之相關函式外，由於這些封包仍需要送出至其他節點，因此需要 進行封包傳輸函式之實作。實作的內容包括了：check_pktRTS_CR、check_pktCTRL_CR 這兩個函式，前者主要用來處理 RTSCR之封包，而後者則是負責傳送 CTSCR與 RTI 這兩 種封包。而這兩個函式需要放在 deferHandler 與 backoffHandler 這兩個計時器逾時處理 函式進行呼叫。 最後還需要增加 recvRTS_CR、recvCTS_CR、recvRTI 這三個接收 RTSCR、CTSCR 與 RTI 封包的對應處理函式，這些函式會透過送來的控制封包的內容來更新其狀態與頻 段使用決策的相關參數。而被呼叫的位置則是在封包接收的處理函式 recvHandler 內。  行為狀態的維護 但單純加入產生封包、送出封包的處理函式是不夠的，這樣的實作很有可能發生狀 態錯亂的狀況，原因是在 3.2.3 介紹的部份曾提到 MAC80211CR 並沒有與頻段相關的概 念。此外，在先前的設計中，傳送端與接收端的定義主要是由封包類型的傳送優先順序 來維護的。在這樣的狀態下，很有可能造成當傳送端與接收端進入資料傳輸頻段時，在 頻段感測完成並進入 RTS-CTS 握手機制的狀況下，此時接收端有封包需要進行傳輸，

19 因此它隨即產生了一個 RTSCR，之後在傳送端還沒送出 RTS 封包時，即偵測到目前頻段 是沒有人用的，因而將 RTSCR這一個控制封包傳送出去。以這樣的情況來看，接收端在 此時產生狀態上的錯亂，因為它本來沒有任何機制告訴它它在此時不能送這個封包。 因此在這個問題的處理上，則將有限狀態機中對於狀態的概念引入，在此實作中稱 作行為狀態 (Action State) 。透過行為狀態的維護，會使得在處理過程中對於狀態的檢 查更為精確，而非僅利用離散的資訊來進行狀態的檢查。這樣的設計也有助於後面在 3.2.3.2 對於頻段感測行為的實作。而在此所制定之狀態如下所示： STATE IDLE STATE SEND CTSCR STATE WAIT RTS STATE SEND CTS STATE WAIT DATA STATE SEND ACK STATE WAIT RTI STATE WAIT RTI IDLE STATE WAIT RTI BUSY STATE WAIT SENSE IDLE STATE WAIT SENSE BUSY Receive a RTSCR / Produce a CTSCR Frame CTSCR Send Timeout /

Start mhSense Timer

Sense channel busy / None

Sense channel busy / None

mhSense Timeout / start mhWait timer

mhWait Timeout / Switch to the next

channel And start mhSense

timer

mhSense Timeout / Switch to the next

channel And start mhSense

timer

Finish sending CTS / None

Receive a DATA /

Produce an ACK frame Finish sending an ACK / Start mhRTI timer and update has_more_data

flag

Receive a RTI / Cancel mhRTI timer and start mnSIFSCR

Timer mhSIFSCR Timeout and

txop <= TxOPCR and

has_more_data is true / None

mhSIFSCR Timeout and

(txop > TxOPCR or

has_more_data is false) / None Sense channel busy /

None mhSIFSCR Timeout / None Receive a RTS Frame / Produce a CTS frame 圖 8、發送端之行為狀態循環圖。 〈註：未標示之輸入者表示維持原本狀態，並且無任何輸出。〉

20 STATE IDLE STATE SEND RTSCR STATE WAIT CTSCR STATE SEND RTS STATE WAIT CTS STATE SEND DATA STATE WAIT ACK STATE SEND RTI STATE SEND RTI IDLE STATE SEND RTI BUSY STATE SEND SENSE IDLE STATE SEND SENSE BUSY

RTSCR Send Timeout / None

Detect a packet to be sent / Produce a RTSCR Frame Finish sending RTSCR / None Receive a CTSCR / Switch to the data

channel And start mhSense

timer

Sense channel busy / None

Sense channel busy / None

mhSense Timeout / Produce a RTS Frame And start mhWait timer

mhWait Timeout / Switch to the next

channel And start mhSense

timer

mhSense Timeout / Switch to the next

channel And start mhSense

timer

Finish sending RTS /

None Receive a CTS Frame / _{cancel mhWait timer} Finish sending DATA /_None

Receive an ACK / Produce a RTI Frame

Finish sending RTI / start mnSIFSCR Timer

mhSIFSCR Timeout and

txop <= TxOPCR and

epktTx != NULL / None

mhSIFSCR Timeout and (txop > TxOPCR or epktTx == NULL) / None Sense channel busy /

None mhSIFSCR Timeout / None 圖 9、接收端之行為狀態循環圖。 〈註：未標示之輸入者表示維持原本狀態，並且無任何輸出。〉 如圖 8、圖 9 所示，在 MAC80211CR 內，透過加入行為狀態的維護，可使得封包 傳輸時能夠按照既定的流程進行，而不會產生行為狀態錯亂的狀況。此外也可協助於頻 段感測階段進行頻段狀態之記錄，能夠有效的將各種資訊整合以方便設計實作此模組。

3.2.3.2. 頻段感測行為之實作與封包傳輸的特殊狀況的處理

 頻段的切換與感測機制 在頻段的切換中，由於切換的決定權在 MAC80211CR 模組中，但目前使用之頻段 資訊則是由 WphyCR 模組所維護，MAC80211 模組本身對於頻段是沒有概念的。因此在 此處，本實作提出了在 MAC80211CR 模組中增加一個稱作 Cognitive Radio Channel Control 的類別 CRChannel_Ctrl，這個類別主要是在 MAC80211CR 模組中產生，負責與

21 頻段相關的處理事件。但是只有這樣的模組是不夠的，若需要更動目前所使用頻段還需 要 WphyCR 模組之支援。故在此增加設定與取得目前相關頻段的函式，使得該類別之物 件能直接呼叫相關函式 SwitchChannel 以協助 MAC80211CR 模組進行切換頻段之動作； 此外在切換的過程中，為了避免切換頻段後仍在接收前一頻段資料之狀況，因此，在 MAC80211CR 內也另外實作一個函式 SwitchChannel 以處理這些動作。整體設計如圖 5 的 Wphy_CR 與 CRChannel_Ctrl 之類型描述區塊所示。 但在頻段的感測中，目前 NCTUns 對於本部份的實作主要是透過實體層模組來判斷 這個封包是否與自己所屬之頻段符合，符合者則將此封包往上層送，如此 MAC 模組即 能知道此時存在某些使用者正在使用該頻段；若不符合即直接將該封包丟棄。這樣的狀 況在原本的使用情境──即該無線網路使用設備僅在某一特定頻段使用是沒有問題的 設計方法，但應用在無線感知網路的情境中卻會導致極大的問題。 而這個問題的解釋主要在於模擬封包接收的方法上，承接上一段的敘述，若接收的封包 與自己所在的頻帶吻合，則在 MAC 模組收到後，其流程主要為：

1. 由 MAC 模組的 recv 函式將此封包儲存在接收的緩衝區 epktRx 內，並且利用其封

包大小與實體層相關參數來計算其接收時間，並利用此接收時間來啟動接收時所用 的計時器 mhRecv。

2. 當 mhRecv 之計時器計時完畢時，此時該封包會透過 recvHandler 這個函式來判斷該

封包是否為自己的，是的話即呼叫對應的處理函式；不是的話則在設定完 NAV (Network Allocation Vector) 後丟棄。

在這樣的處理下，由 mhRecv 是否正在倒數計時以及 MAC 的接收狀態即可判斷此 時是否能夠感應得到資料的進入，但若考慮圖 10 之情境，這一套設計可能就無法正常 運作。

22 圖 10、不適用於原先 NCTUns 感測頻段忙碌流程之實例。 在圖 10 中，一開始無線感知網路的使用者正在控制封包傳輸頻段中進行封包的傳 輸，而在同時，第一個資料傳輸頻段也有一個主要使用者正在傳送資料。假設此情境下， 這三位使用者皆能完整接收到其它使用者所傳輸之封包，則在該時間點，無線感知網路 之使用者均會收到由第一個資料傳輸頻段傳送來的封包，但是在實體層卻會因為它不是 屬於目前使用之頻段的封包為理由而將其丟棄。之後，兩位無線感知網路之使用者切換 至第一個資料傳輸頻段，在他們進行頻段感測時卻無法知道目前有一位主要使用者正在 使用該頻段，因為該位使用者傳來的封包已被丟棄。 為了解決這樣的問題，最簡單的方式是改寫 WphyCR 模組，讓其完全不用判斷所用 頻段，直接將其往上層送，但是這樣即不符合 MAC 的行為定義。因此在此處的設計主 要是透過 CRChannel_Ctrl 來實作一個稱作 UpdateChannelStatus 的函式，任何進入 WphyCR 模組的封包都會被交由該函式處理，而該函式主要會計算出若要接收這個封包， 則至少要到哪個時間點才能被接收完畢，並將該時間點儲存於該類別中負責儲存對應頻 段的陣列中。此時若 MAC80211CR 模組需要檢查現在頻段是否為閒置狀態，則可直接 透過 CRChannel_Ctrl 這個類別的物件來進行查詢，若現在時間比所記錄的時間小，則代

23 表此時仍有封包在傳輸。因此，此機制搭配原先儲存在 MAC80211CR 的 NAV 的機制在 多重頻段上的改寫，即可正確判斷出目前頻段是否為忙碌狀態。  頻段感測時間區間之實作 在頻段由控制封包傳輸頻段切換至資料傳輸頻段後，根據[10]所提的機制，無線感 測網路之傳送端與接收端雙方均要進行頻段感測之動作。若此時頻段為忙碌，則接下來 應該要切換至下一個資料傳輸頻段；但若此時頻段為空閒，則傳輸可順利繼續進行。 在此部份的實作中，主要行為則是當接收端回應 CTSCR完成與傳送端收到 CTSCR 後，雙方會切換至約定好的資料傳輸頻段。此時雙方即啟動一個稱作 mhSense 的計時器， 並更動行為狀態為 STATE_SEND_SENSE_IDLE 或 STATE_WAIT_SENSE_IDLE，此外 也會將 MAC80211CR 內用以記錄接收狀況之變數設為 MAC_SENSE 以代表它們將進入 感測狀態。在此同時，MAC 模組會先檢查這個頻段是否為閒置狀態，若不是則會將行 為狀態會更動為 STATE_SEND_SENSE_BUSY 或 STATE_WAIT_SENSE_BUSY。而計時 器完成計時前，每一個傳送至 recv 函式的封包即會被丟棄，並且行為狀態會更動為 STATE_SEND_SENSE_BUSY 或 STATE_WAIT_SENSE_BUSY。 當 mhSense 這個計時器完成計時後，則會呼叫一個稱為 senseChHandler 的函式。這 個函式會檢查目前的行為狀態是否為 IDLE，若是則會讓傳送端在此時填入 RTS 控制封 包，並將行為狀態更動為 STATE_SEND_RTS 或 STATE_WAIT_RTS，使得後續的 RTS-CTS 握手動作能順利完成；若不是，則只單純將行為狀態更動為 STATE_SEND_RTS 或 STATE_WAIT_RTS。而在以上動作完成後，一個稱作 mhWait 的計時器會被啟動，若 此計時器計時完成，RTS-CTS 握手動作卻沒有完成，則代表在這個頻段上的握手動作失 敗，需要到下一個頻段重新進行頻段感測與 RTS-CTS 握手動作。  於接收時例外情況的處理

24 在封包的接收方面，為了避免發生在資料傳輸頻帶收到並非給自己的封包，以及收 到並非本次傳輸時的傳輸對象之封包，因此在進行 RTSCR與 CTSCR的握手動作時，會另 外將對方端的 MAC 位址記錄下來。若在接收完封包時，發現此封包並非本次傳送對象 的狀況，則該位無線感知網路之使用者會直接將目前使用頻段切換至控制封包傳輸頻段。 而若此狀況只有傳輸與接收兩端的其中一端知道，則按照原始機制，會使得原本的流程 無法順利進行。 考慮到原本流程無法順利進行的狀況，例如：傳輸尚未完成，在接收端發生碰撞之 狀況、沒有收到某些特定封包，如 ACK、RTI 等狀況，在實作的部份均是讓發生端在該 時段回到控制封包傳輸頻段，使得其能重新進行封包的傳輸動作。

3.2.3.3. 主動釋出頻段之設計

而在最後的設計則是在進行完原始的資料傳輸程序，即 RTS-CTS-DATA-ACK 之後， 在 3.2.3.1 曾提到 RTI 這個表頭的設計。為了讓接收端知道在等待完 SIFSCR之後是否仍 要繼續在資料傳輸頻段繼續等待下一個資料，因此在 RTI 的設計上則是加入了 last 這一 個欄位來表示這個資料是否為最後一個傳輸的資料，以及在這個 RTI 結束後，是否要返 回控制封包傳輸頻段。為了能讓 RTI 內的欄位填入正確的值，因此在收到 ACK 之後， 接收端需要在此時檢查他是否還有資料要傳、以及是否還有能夠運用此頻段的機會 (即 本次在此頻段的傳輸次數是否小於 TxOPCR的定義值) 。 而傳送端傳送完 RTI 與接收端在收到 RTI 後，如同在 3.2.3.2 提到的頻段感測之機制， 兩者均需設定其接收狀態為 MAC_SENSE，並將行為狀態設為 STATE_SEND_RTI_IDLE 與 STATE_WAIT_RTI_IDLE 以表示它們兩位使用者進正在進行頻段感測，並啟動 SIFSCR 的計時器。之後若感測到頻段有人在使用時，則將狀態切換為 STATE_SEND_RTI_BUSY 與 STATE_WAIT_RTI_BUSY。

25

當 SIFSCR的計時器逾時，即需要針對目前的狀態以及還有沒有資料封包需要傳輸。

若目前的狀態為 STATE_SEND_RTI_IDLE 或 STATE_RECV_RTI_IDLE，且在 RTI 封包 中註明還有封包需要傳輸，則雙方繼續待在目前的資料傳輸頻道內；否則應該要回到控 制封包傳輸頻帶再次決定應該要使用到哪個資料傳輸頻段進行後續的資料傳輸。 此外，為了避免只有傳送端發現有主要使用者想使用此資料傳輸頻帶之狀況，接收 端在繼續待在此頻段時需要啟動 mhWait 之計時器，並在接收到任意封包時取消此計時 器的計時動作；若在計時器逾期前仍未取消使用此計時器，則表示傳送端可能偵測到主 要使用者之訊號，並跳回控制封包傳輸頻段，故此時接收端應回到控制封包傳輸頻段進 行等待或競爭傳輸之機會。而在此為了避免等待時間太短而造成接收端過早回到控制封 包傳輸頻段，因此在此對於時間的設定與完成頻段感測時的等待時間區間相同。 在完成這些機制設計後，MAC80211CR 與 WphyCR 的模組即告完成，而模擬也能 夠順利進行。但是，在進行模擬實驗的同時，也發現了在此機制下可能遭遇的某些問題 使其效能降低，或是存在某些使其效能提升之可能機制，而這些議題的討論與其改良方 案將於下一章中描述。

26

4. 原有機制之改良

4.1. 原有機制之效能增討論

在前一章中進行[10]之無線感知網路機制之設計時，發現有幾個部份的設計中存在 著對於某些情境下效能的改良點。這些改良的部份根據其位於流程中位置來分類，可概 略性分為三個部份：  快速頻段感測之頻段挑選機制

在 3.1.2 中曾提到快速頻段感測 (Fast Channel Sensing) 的機制，這個機制在實作上 主要是採取亂數來做為決定初始頻段 (Initial Channel) ，並且任取一個與可用資料頻段 個數互值之數 h 來做為頻段切換遞增值。這樣的設計的好處是容易實作且在決策上較不 耗費時間，但考慮到其取得之初始頻段正有使用者進行傳輸時，它將損失頻段感測所需 時間外加等待時間區間的時間。如果很不湊巧的在切換頻段之後，仍舊感測到存在任意 使用者正在使用該頻段，還是會造成該段時間的損失。因此，在這種情況下，若能夠找 到一種方式來進行使用資料頻段的挑選會是較佳的解決方案。

27

圖 11、由終端機隱匿問題之情境來考慮決策者的選定。

此外，在此機制下由於決策者為無線感知網路傳送端，若此時存在如圖 11 之終端 機隱匿問題 (Hidden Terminal Problem) ，假設目前已存在一種機制能使得傳送端能找到 最適合自己的頻段，但由於傳送端無法知道接收端是否會被其他使用者干擾，因此傳送 端仍舊無法保證接收者能夠順利接收到 RTS 控制封包，進而達到減少感測到頻段切換之 損失。 因此，在解決方案的部分將設計兩個機制：第一個機制為建構於歷史感測資料之評 分機制，透過此機制可以協助無線感知網路使用者挑選適合自己的頻段；第二個機制則 是改寫 RTSCR與 CTSCR的設計，使得傳送端可以將「較適合自己使用」的頻段透過 RTSCR

告知接收端，而接收端在此時會啟動「頻段感測快照 (Channel Sensing Snapshot) 」的 機制，使得接收端能在此時先了解目前周遭頻段使用情況，以決定頻段切換順序。此部 份更進一步的設計說明將會在 4.2.1 中詳述。

 資料傳輸頻段感測之機制

接下來則是探討在於頻段感測機制中對於資料傳輸感測頻段的部份，在這個部份中 的設計中，原本的設計主要是在切換至任何資料傳輸頻段時需要進行頻段感測，以確定

28 是否存在主要使用者欲使用該頻段之狀況；若此時感測到任何訊息，則代表此時可能存 在某些使用者欲使用此頻段。這樣的機制的設計主要是希望能儘量避免干擾主要使用者 使用此頻段，不過在某些情境下它可能會降低無線感知網路使用者在進行傳輸時的效能。 情境如下圖所示： 圖 12、當頻段感測到 ACK 後，即使頻段接下來無任何使用者使用，仍需切換頻段。 圖 12 展示了一種特殊的情境，在這種情境下，當無線感知網路使用者切換到資料 傳輸頻段 1 時，此時存在一對主要使用者正在進行資料傳輸，並將進入尾聲。此時主要 使用者中的接收端因為收到該資料後回傳 ACK 給傳送端，兩者在此後短時間內不再傳 輸封包。但是在這個時候，無線感測網路之使用者卻感測到附近正有其它使用者在進行 資料傳輸，於是在頻段感測完成且等完等待時間區間後隨即會放棄在此頻段的使用情況， 直接切換至下一頻段。在此種情境下，無線感知網路的兩位使用者仍然損失了頻段感測

29 所需時間外加等待時間區間的時間，因此在此部份的機制是可以考慮進行改良的。 而在改良的方案主要有一個假設，這個假設即是在這些頻段內的使用者均為 IEEE 802.11 無線網路之使用者，亦即每一位使用者所傳的封包型態是所有使用者都知道的。 因此，在此情況下，只需要針對頻段感測時所收到的封包進行型態的檢查，並且進行對 應的處理即可。詳細的內容將在 4.2.2 中詳細描述。  SIFSCR之後的資料傳遞與終端機隱匿問題之討論 最後則是在 SIFSCR之後關於資料傳輸方面的議題，這一部份的議題在原始的機制 中主要是：在本次資料封包傳輸完成後，無線感知網路接收端會回應一個 ACK 以代表 收到此資料傳輸封包，之後無線感知網路傳送端會發出一個稱作 RTI 的控制封包。在接 下來 SIFSCR的時間內，雙方均需要進行頻段的感測，以確定此時是否存在主要使用者 需要進行資料傳輸。 考慮到先前於圖 11 的終端隱匿問題之情境，在主要使用者的訊號只有無線感知網 路接收者能夠感知的情況下，若此時確實存在任意主要使用者需要進行封包的傳輸，則 該位使用者會發出 RTS 之控制封包。在此時此 RTS 只有無線感知網路接收端能夠感測 到，傳送端則是維持認定「此頻段尚無其它使用者使用」之狀態。這樣的情境下，雖然 在無線感測網路接收端返回控制資料傳輸頻段後，當無線感測網路傳送端送完資料封包 卻沒有收到 ACK 控制封包時，傳送端能夠正常的返回控制資料傳輸頻段。整體流程可 參考圖 13。

30 圖 13、在終端隱匿問題下，傳送端的行為反應。 現在假設資料封包的內容大小為 2048 bytes，且無線感知網路傳送端位於資料傳輸 率上限為 2 Mbps 的環境中，則傳送端至少需要約 8000 微秒的時間進行此資料封包之傳 輸，而且必定是在這之後才有機會知道接收端無法接收此資料。在如此之情境下，其返 回控制封包所在頻段之代價相較之下似乎有點過高，因此若能在此更動其機制，勢必有 機會能讓無線感測網路之使用者其效能提升，達到更有效的頻段使用率。而在改善方案 的規劃上，本篇論文之設計主要是再次進行 RTS-CTS 握手動作為主，詳細設計於 4.2.3 中將詳細說明。

31

4.2. 改進之方法與其設計實作

4.2.1. 頻段挑選機制

在頻段挑選過程中一共有兩個機制，第一個機制稱為頻段評分機制，第二個則稱作 頻段感測快照機制。底下將分別針對此二機制進行詳細的設計說明與實作方式：  頻段評分機制 在頻段評分機制的設計上主要是運用一種基於歷史資料觀測的方式來進行評分，在 歷史資料觀測的部份，對於同一無線感知網路使用者，針對所使用的每一個頻段各有一 組 32 位元稱作閒置記錄的記錄值，在每次的頻段感測中，皆會更新此記錄值。而在實 作中，選擇最大 bit 數為最近一次的偵測結果，在每次進行偵測時，會先將此數值往右 遞移一位元，之後當偵測到頻段為閒置狀態時即標示為 1，而偵測到忙錄狀態時則為 0。 如圖 14 所示： 圖 14、閒置記錄與評分方式之示意圖。 圖 13 展示了一個例子，在某一個時間點，閒置記錄的記錄內容如圖中的 IDLE Record(n-1) 所示，內容為由 1010…10 循序組成，而在下一個時間點，該無線感知網路

32

使用者偵測到此頻段處於閒置狀態，則其會將該記錄往右移 1 位元，並且在最高位元的 值填入 1，即如圖 14 中 IDLE Record(n)所示。

而在進行評分值的方面，在此給與閒置記錄值的每 1 bit 一個權重，由最高的 bit 開 始為 31，依序遞減。計算方式即是將所有的位元與其權重相乘後加總，即可得到一個值。 以圖 14 為例，由 IDLE Record(n-1)可以得到其分數為 256，而 IDLE Record(n)則為 271。 若其值愈大，則代表其具有在愈近的時間點具有較多的閒置機會，或是在歷史記錄中其 閒置次數頻繁的特質。這樣的設計可以避免只有最後一個位元來決定評分的狀況。因此 在此處主要將利用這個評分標準來進行閒置頻段的評估。 而在頻段選定的部份則交由無線感知網路傳送端按照評分的分數由高到低進行評 分，並從中挑選部份頻段填入 RTSCR的控制封包內。為支援傳遞這些訊息，RTSCR的控 制封包需要進行改變，改變的內容主要是將原先儲存於原機制的欄位所佔用的 4 個位元 組改為儲存被選中的頻段。儲存方式主要是利用該欄位中一共 16 個位元分別代表不同 的頻段已挑選或未挑選。而表頭的部份則如圖 15 所示： 圖 15、修改後的 RTSCR之結構。 當無線感知網路使用者之接收端收到此 RTSCR的控制封包後，接收端即能知道傳送 端選擇那些頻段，並且也能從這些頻段中挑選適合本次傳輸之頻段。而挑選的方式除了 透過這套評分方式之外，尚還有在下個段落會提及的頻段感測快照機制。在挑選完畢之 後，接收端會將接下來想要使用的頻段按照順序填入 CTSCR的控制封包內，以告知傳送 端接下來的資料頻段切換順序，如此則可由接收端決定較有可能為空閒之頻段。而修改 後的 CTSCR 的結構則如圖 16 所示：

33 圖 16、修改後的 CTSCR之結構。  頻段感測快照機制 在上一段的無線感知網路接收端決定頻段切換順序時曾提到還需要配合頻段感測 快照機制的使用，這個機制主要是為了讓感測者能夠以較短的時間為代價，藉此取得某 些頻段的頻段使用情況。 當接收端收到 RTSCR之後，接收端會知道哪些頻段是傳送端所選擇的。此時接收端 會對這些頻段進行快速的頻段感測。對於每個頻段，其感測時間為 100 微秒，並在這 100 微秒的時間結束時更新閒置記錄值，並切換到下一頻段。在此若該頻段有任何封包傳輸， 則直接將該頻段標示為有其他使用者正在進行傳輸的情況；而未偵測到任何封包，則標 示其為閒置狀態。藉由此方法，能夠讓接收端在短時間內對於可能用到的頻段進行其最 近情況的分析，使得接收端判斷所用之資訊能夠更為準確。

4.2.2. 資料傳輸頻段感測機制之改良

在 4.1 的圖 12 中提到對於資料頻段感測時的某種特殊情境，這個情境主要發生在頻 段感測時若接收到 ACK，且在此 ACK 之後，主要使用者在短期間內均不使用此頻段。 若此時因為此 ACK 而導致頻段使用上的浪費則不太划算，因此在改善方案的部份則是 著重在觀看封包內容並判斷接下來是否該使用。 根據各個接收到封包的意義，當收到一個 RTS 封包、CTS 封包或 DATA 封包，則 代表接下來直到接收到一個 ACK 之前都不能使用此頻段。因此此處主要是利用頻段感

34 測時的最後一個封包來決定是否可以使用此頻段。但是封包的接收是需要時間的，若存 在一個封包來不及在頻段感測時間結束前被接收完畢，則為了避免誤判的狀況，因此最 後仍然不應該使用此頻段。根據以上的分析，可將決策以底下的圖來表示： 圖 17、修改後的頻段感測之決策機制。

4.2.3. SIFS

CR

後資料傳輸之改良

在 4.1 中，圖 13 顯示了在不考慮接收端的情況下，當 SIFSCR的等待時間過後可能 會因為隱匿終端問題而導致傳送端需要不少的時間才能返回控制封包傳輸頻段的情境。 而在解決方案的部份則是提出了「再次於同一頻段進行 RTS-CTS 握手動作」的方案做 為解決方法。 而這樣的方案主要是為了能讓傳送端迅速察覺接收端出現異常，原因主要是因為這 樣的程序所需要的時間約為 600 微秒，對比於先前提到在 DATA 為 2048 bytes 的情況下， 如此可大幅縮小反應的時間；此外，利用 RTS 與 CTS 的優點也包括了能讓其他使用者 知道這個頻段目前有其他使用者正在進行傳輸，使得本次的傳輸不會因為有其他使用者 干擾而中斷，搭配原有機制在 RTI 的處理，將會使得有意願的使用者在這段時間之後能 夠表達它們有使用此頻段的需求，使得整個無線感知網路的傳輸程序能順利完成，也能 降低對於主要使用者的干擾程度。相信這樣的改良機制能使得無線感知網路使用者在此 情境下的效能能夠提升。

35 在實作上，則只要在等待完 SIFSCR的處理函式中，針對傳送端的部份加入產生 RTS 控制封包的呼叫函式，並且讓傳送端與接收端各自將其行為狀態更動為 STATE_SEND_RTS 與 STATE_WAIT_RTS，如此在接下來的流程中，整個機制即會按照 改良後的流程運作。 到此，對於整個機制的改良已告一段落，在接下來的章節中，本篇論文將呈現以原 本的方法與改良後的方法在不同情境下的效能比較並進行分析。