在無線隨意網路環境下一個具有功率控制的方向性媒體存取控制協定

國立交通大學

電機資訊學院 資訊學程

碩 士 論 文

在無線隨意網路環境下一個具有功率控制的

方向性媒體存取控制協定

A Directional MAC Protocol with Power

Control in Wireless Ad Hoc Network

研 究 生：劉仲欽

指導教授：陳健 博士

在無線隨意網路環境下一個具有功率控制的

方向性媒體存取控制協定

A Directional MAC Protocol with Power Control in

Wireless Ad Hoc Network

研 究 生：劉仲欽 Student : Chung Chin Liu

指導教授：陳健 博士 Advisor : Dr. Chien Chen

國 立 交 通 大 學

電機資訊學院 資訊學程

碩 士 論 文

A Thesis

Submitted to Degree Program of Engineering and Computer Science

College of Electrical Engineering and Computer Science

National Chiao Tung University

in partial Fulfillment of the Requirements

for the Degree of

Master of Science

in

Computer Science

June 2005

Hsinchu, Taiwan, Republic of China

在無線隨意網路環境下一個具有功率控制的

方向性媒體存取控制協定

研究生：劉仲欽 指導教授：陳健 博士

國立交通大學電機資訊學院 資訊學程 (研究所) 碩士班

摘要

近幾年來方向性天線應用在隨意網路(ad hoc network)是很熱門的研究議題，因為 方向性(Directional)天線比全方向性(Omni-Directional)天線提供了更多的優勢，除了提 升空間的使用率之外，還可以減少 co-channel 干擾的情形、增加傳送的距離以及節省 傳送所需的電力。不過，為了充分利用方向性天線的好處，必須重新設計一個 MAC 協定，所以許多使用方向性天線的 MAC 協定相繼被提出，其中又以 D-MAC[3] 最受 到重視。另外，透過控制功率(Power Control)的方式與方向性天線皆可以有效提升空 間使用率。

在這篇論文中，我們先針對 D-MAC 所提的 Scheme 1 與 Scheme 2 來做分析，我 們發現 Scheme 1 提升了空間的使用率，但是會產生一些碰撞情形，而 Scheme 2 減少 了碰撞的發生，可是還是存在 Deafness 以及 Collision 的問題，也因此降低空間的使用 率。於是我們提出了一個改進 D-MAC Scheme 2 的新協定，叫做 F-DMAC。這一個 方法提高了空間使用率並且減少碰撞的發生。接著我們將控制傳輸功率的方式使用在 F-DMAC 中，提出了另一個改進的新協定，叫做 PCF-DMAC。PCF-DMAC 結合了控 制傳輸功率與方向性天線的優點，有效的降低碰撞情形以及提升空間使用率。使用

J-Sim 模擬實驗後，F-DMAC 在 Multi-hop、Mesh Network 的環境下，網路輸出都表 現的比 IEEE 802.11 以及 D-MAC Scheme 2 還要好，而 PCF-DMAC 在 Multi-pair 的情 況下則比 IEEE 802.11、D-MAC Scheme 2 以及 F-DMAC 都還要好。

A Directional MAC Protocol with Power

Control in Wireless Ad Hoc Network

Student：Chung Chin Liu Advisor：Dr. Chien Chen

Degree Program of Electrical Engineering Computer Science

National Chiao Tung University

ABSTRACT

Applying directional antenna to ad hoc network has been a hot research topic, because directional antenna has more advantages than omni-directional antenna, such as increase spatial reuse rate, diminution of co-channel interference, acceleration transmission distance, and saving transmission power. However, in order to fully utilize the benefit of directional antenna, MAC protocol has to be redesign, and among those directional antenna MAC protocol are successively proposed, D-MAC gets the high consideration. Except for directional antenna, spatial reuse rate can also be improved through controlling transmission power, so that studying how to apply controlling transmission power to directional antenna is glamour as well. In this thesis, we analyzed Scheme 1 and Scheme 2 the D-MAC mentioned, and discovered Scheme 1 increase in the spatial reuse rate, but there are some collision happened. For Scheme 2, nevertheless, even though the collision is diminished, it decreases the spatial reuse rate. Upon this, we proposed a new protocol named F-DMAC for meliorating D-MAC. This method not only enhances the spatial reuse rate but also reduces collision chance. After F-DMAC, we addressed the other advanced protocol, PCF-DMAC, applying controlling transmission power to F-DMAC. PCF-DMAC

combines the advantages of controlling transmission power and directional antenna, which decrease the collision and raise the spatial reuse rage.

誌謝

在兩年的研究所生涯中，從一個陌生的領域中摸索到成長，一直到此篇論文的完 成，我最要感謝的是我的指導老師，陳健博士。在這兩年的研究學習過程中，經由老 師的悉心指導與指引研究方向，使我對無線網路的理論方法有一定的認知以及在學術 研究上可以獨立思考。也因為如此，此篇論文才能順利的完成。另外也承蒙曾煜棋博 士、許健平博士以及陳志成博士於百忙中撥冗費心審閱，並對本篇論文提供建議與指 教，使學生受惠良多，也因而讓本篇論文更加的充實。另外也感謝研究室上獻綱、松 偉、俊源、奕緯、政佑、嘉仁、勤凱、咨翰、盈羽、筱筠、澤羽、上群、佩菁等學長 /學姐/同學在研究上的提攜與相互切磋，一同度過這兩年的生活。最後我要謝謝工研 院資訊中心的麗珠組長、錦坤經理、仲仁、玫宜、嘉霖、廷愷、雅卉、志源、可立等 同事，在工作上給我的幫助，讓我得已在一邊工作一邊唸書的情況下完成學業。 回首這兩年研究過程的點點滴滴，要感謝的人實在太多了，但礙於空間上的限 制，以致於無法一一列出感謝，甚感抱歉。總歸一句就是『感恩啦!』 在此僅以此篇論文獻給我最親愛的父母親與家人，以及所有關心我的師長、朋友 及同學們。

目錄

摘要 ... i ABSTRACT ...iii 誌謝 ... v 目錄 ... vi 圖目錄 ...viii 表目錄 ... x 第一章 緒論 ... 1 1.1 研究背景與目的 ... 1 1.2 研究方法 ... 2 1.3 論文架構 ... 3 第二章 相關研究 ... 4 2.1 IEEE 802.11... 4 2.1.1 分散式協調機制 ... 5 2.1.1.1 訊框格式 ... 5 2.1.1.2 訊框間隔 ... 6 2.1.1.3 碰撞偵測與虛擬載波偵測 ... 8 2.1.1.4 延後機制 ... 10 2.1.1.5 訊框之切割與組合 ... 11

2.1.2 Hidden and Exposed Terminal... 12

2.2 Omni-directional MAC ... 13 2.2.1 MACA ... 13 2.2.2 DBTMA... 14 2.2.3 MACA/BI ... 14 2.3 Directional MAC ... 15 2.3.1 D-MAC... 16

2.3.2 Directional Virtual Carrier Sensing (DVCS) ... 17

2.3.3 Circular Directional RTS/CTS ... 19

2.4 Directional MAC with Power Control ... 20

2.4.1 Two-Level Transmit Power Control... 20

2.4.2 DMACP ... 21

2.4.3 Distributed Power Control (DPC) ... 21

第三章 F-DMAC ... 23

3.1 問題定義 ... 23

3.2 F-DMAC 介紹... 26

3.3 控制封包傳送方式 ... 26

3.6 F-DMAC Handshake Mechanism ... 30 3.5.1 Directional RTS 狀態... 30 3.5.2 Blocked CTS 狀態 ... 36 第四章 PCF-DMAC... 43 4.1 問題定義 ... 43 4.2 PCF-DMAC 介紹... 45 4.3 控制封包傳送方式 ... 46

4.4 Neighbor Information Table (NIT)... 46

4.5 PCF-DMAC Handshake Mechanism ... 48

第五章 實驗模擬與效能評估 ... 54 5.1 模擬環境 ... 54 5.2 實驗結果 ... 55 5.2.1 基本情況 ... 55 5.2.2 Multiple-hop 情況 ... 57 5.2.3 Mesh Network 情況 ... 58 5.2.4 Multi-pair 情況... 58 第六章 結論 ... 60 參考文獻 ... 61

圖目錄

圖 2-1 MAC 架構圖... 4

圖 2-2 分散式協調機制... 5

圖 2-3 各種訊框間隔關係... 7

圖 2-4 CSMA/CA with four-way handshaking ... 9

圖 2-5 利用 NAV 進行虛擬載波偵測... 10

圖 2-6 Hidden terminal... 12

圖 2-7 Exposed terminal... 13

圖 2-8 MACA/BI... 15

圖 2-9 D-MAC (a) D-MAC SCHEME 1 (b) D-MAC SCHEME 1 Collision Problem ... 17

圖 2-10 Three DNAVs set for different directions [8]... 18

圖 2-11 The coverage range of a MAC protocol that uses an omni RTS transmission... 19

圖 2-12 Power Control Scenario ... 20

圖 2-13 Improving SDMA efficiency with Directional Antenna and power-controlled Directional Transmission... 21

圖 3-1 D-MAC Scheme2 Directional RTS Problem ... 24

圖 3-2 D-MAC Scheme 2 Decrease Spatial Reuse Problem... 25

圖 3-3 D-MAC Scheme 2 Transmit in Blocked Status Problem... 26

圖 3-4 方向性天線的傳送範例... 28

圖 3-5 F-DMAC Handshake Mechanism (Directional RTS) ... 31

圖 3-6 F-DMAC Small Packet Case (Directional RTS)... 34

圖 3-7 F-DMAC Large Packet Case (Directional RTS)... 36

圖 3-8 F-DMAC Handshake Mechanism (Blocked CTS) ... 37

圖 3-9 F-DMAC Small Packet Case (Blocked CTS) ... 40

圖 3-10 F-DMAC Large Packet Case (Blocked CTS) ... 42

圖 4-1 F-DMAC Decrease Spatial Reuse Problem... 44

圖 4-2 F-DMAC Power Control Directional CTS Problem ... 45

圖 4-3 方向性天線的傳送範例... 47

圖 4-5 PCF-DMAC Small Packet Case... 51

圖 4-6 PCF-DMAC Large Packet Case... 53

圖 5-1 兩個由內向外的通訊... 55 圖 5-2 兩個由外向內的通訊... 56 圖 5-3 兩個相同方向的通訊... 56 圖 5-4 兩個相同方向但不同距離的通訊... 56 圖 5-5 Multi-hop Scenario... 57 圖 5-6 Multi-hop 模擬結果... 57 圖 5-7 5*5 mesh Network ... 58 圖 5-8 250*250 topology... 59 圖 5-9 250m*250 Multi-Pair 傳輸實驗結果 ... 59

表目錄

表 2-1 802.11 MAC 訊框格式... 6

表 2-2 A record of Location Table... 20

表 3-1 F-DMAC 封包傳送方式 ... 27

表 3-2 F-DMAC Neighbor Information Table ... 27

表 3-3 Records of F-DMAC NIT ... 28

表 3-4 Delay To Send (DTS) ... 29

表 3-5 Modify Request To Send (RTS) ... 29

表 3-6 Modify Clear To Send (CTS) ... 30

表 4-1 PCF-DMAC 封包傳送方式... 46

表 4-2 PCF-DMAC Neighbor Information Table ... 46

表 4-3 Records of PCF-DMAC NIT ... 47

表 5-1 Simulation 參數 ... 54 表 5-2 兩個由內向外的通訊實驗結果... 55 表 5-3 兩個由外向內的通訊實驗結果... 56 表 5-4 兩個相同方向的通訊實驗結果... 56 表 5-5 兩個相同方向但不同距離的通訊實驗結果... 57 表 5-6 Mesh 2 個連線實驗結果 ... 58 表 5-7 Mesh 5 個連線實驗結果 ... 58

1.

第一章 緒論

1.1 研究背景與目的

無線隨意網路是一種可以自動建立節點之間連結的網路，他具有快速部署以及不 需要固定基礎網路建設支援的特性，因此非常適合用在戰場、緊急事件的救災，或是 探勘等等任務。無線隨意網路中的節點使用共同的無線頻道來傳送 Data，因此需要 一個媒體存取控制(MAC)機制來處理。目前 802.11[17] 中的 DCF 是最常被使用的一 個方法，DCF 主要是透過 RTS/CTS 的協調機制來減少因為隱藏節點或者外部節點所 造成的封包的碰撞情形。 目 前 隨 意 網 路 所 使 用 的 都 是 全 方 位 天 線 ， 透 過 RTS/CTS 的交換來通知在 sender/receiver 附近的節點不要傳送封包，也就是同一時間之內只有一對節點可以做 傳送或是接收的動作，但是這樣的方式會使的空間使用率大大降低.，因此很多研究 人員提出了一些方法[1][21][22][23]來改進這樣的情形。其中[1]透過傳輸方向的特 性，讓同一時間可以有數對節點進行傳輸，有效的提升了網路流通(Throughput)。 控制功率(Power Control)[19][20][21]藉由降低傳輸功率的方式來縮小節點的覆蓋 範圍，當節點進行 RTS/CTS 封包交換時，受到影響的節點也相對變少，也提升了空 間使用率。然而，因為非對稱的因素，Poojary 在[19]提出當節點使用不同功率傳輸時， 傳輸功率較低的節點會受到傳輸功率較高節點的影響，而有碰撞的情形發生。PCM[20] 會在資料傳輸期間，週期性的增加傳輸功率到最大值，可以有效避免碰撞的發生。 PCMA[21]則是藉由忙碌通知頻道(busy tone channel)來避免碰撞，每一個接收節點 (Receiver)會週期性的在忙碌通知頻道送出一個訊號，用來通知其他節點傳輸時所能 使用的功率上限。不過，這樣的改善還是因為全方位天線本身的特性而有所限制。

使用方向性天線，是另外一種增加空間使用率的想法，因為方向性天線可以針對 某個固定的方向來接收或者是傳送，可以有效的減少不必要的干擾，提供比全方向性 天 線 遠 的 傳 輸 距 離 ， 以 及 電 力 的 節 省 。 數 種 適 用 於 方 向 性 天 線 的 MAC 協 定 [3][5][7][8][10][11][12][13][14][15]相繼被提出，在[3]所提出的協定中，要傳送方向性 RTS 或者是全方向性 RTS，是由鄰近區域是否有正在進行中的傳輸而決定，節點之間 的傳輸方向則是透過 GPS 的方式來得知。在[5][8]所提出的協定中，Sender/Receiver 可以透過 RTS/CTS 封包交換來得知彼此的方向，而 Sender/Receiver 的鄰居節點也可 以透過這一個資訊來避免干擾的發生。 控制功率與方向型天線兩種方法的共同特性都是可以增加空間的使用率，而缺點 是都會產生隱藏節點的問題並造成碰撞的發生，因此有研究學者把控制功率運用在方 向性天線上[2][6][7][9][16]， 得到非常好的流通提升。[7]提出了一個結合方向性天線 的分散式功率控制協定(DPC)，在這一個方法中，Receiver 會收集干擾資訊並且把資 訊回送給 Sender，然後 Sender 便可以使用這個參考資料來估計下次傳送所需的功率。 經由實驗結果，可以得知這樣的結合可以有效的提升網路流量。因此我們也希望設計 出一個在無線隨意網路環境下具有功率控制的方向性 MAC 協定。

1.2 研究方法

在我們的研究之中，D-MAC[3]中的第一個 Scheme 提供了非常高的空間使用率， 不過卻會造成一些碰撞的情形發生，因此第二個 Scheme 為了解決這樣的問題而被提 出。可是 D-MAC Scheme 2 無法在 Block 狀態下傳送 CTS 封包，因此降低了空間的 使用率。針對這個問題，我們提出了一個加強 D-MAC Scheme 2 的方法，叫做 F-DMAC。F-DMAC 讓節點的狀態處於 Block 時，也可以進行 CTS 封包的傳送，因

Deafness 的情形，因此我們先利用封包大小來做為傳送與否的判斷，當新連線的傳輸 時間比現在進行中的連線短時，代表新連線不會發生 Deafness 情形;反之，新連線的 時間比較長時，可能會有 Deafness 的情形發生。我們使用 Fragmentation 的方式來切割 封包，然後 Receiver 再使用 DTS 來通知舊連線相關的 NAV 資訊，如此便可以避免碰 撞的情形發生。我們也發現 D-MAC Scheme 2 在傳輸方向性 RTS 封包時，也會有相同 的 Deafness 問題發生，而之前所提的 Fragmentation 也可以用來解決這樣的問題，不同 的是 DTS 是由 Sender 來送出。 控制方向性天線的傳輸功率也可以增加空間使用率[9]，因此我們把提出的 F-DMAC 加以改進之後，提出了另一個叫做 PCF-DMAC 的方法。在這一個方法中我們延 續了 F-DMAC 的機制，並以控制傳輸功率的方式來控制封包的傳送距離，藉以避免封 包碰撞的情形。使用 J-Sim 模擬實驗後，F-DMAC 在 Multi-hop、Mesh 的環境下，網 路輸出都表現的比 IEEE 802.11 以及 D-MAC Scheme 2 平均好 19%左右，而 PCF-DMAC 在 Multi-pair 的情況下則比 IEEE 802.11、D-MAC Scheme 2 以及 F-DMAC 平均好 20% 左右。

1.3 論文架構

本論文共分為五個章節，除了第一章緒論外，論文架構與內容概要如下：第二章 將說明IEEE 802.11的基本運作方式以及Hidden and Exposed Node的問題。對於現有的 全方性天線MAC以及方向性天線MAC做一些分析；第三章是本論文的主題，此章將 詳細介紹我們所提出的第一個方法，從控制封包的傳送方式、控制封包的格式、鄰居 節點的方向取得，到整個存取控制的流程都會做詳細的解說；第四章會介紹我們提出 的另外一個方法，說明如何結合功率控制與方向性天線；第五章則是透過模擬來分析 探討我們所提出的MAC協定；第六章則是我們的結論。

2.

第二章 相關研究

2.1 IEEE 802.11

IEEE 802.11 MAC (Media Access Control)位於各式實體層之上，用來控制資料的 傳輸，它負責核心的訊框封裝作業(core framing operation)，以及與有限骨幹網路之間 的互動。802.11 MAC 提供兩種功能不同的無線傳輸媒介存取方式：分散式協調機制 (Distributed Coordination Function ， DCF) 與 集 中 式 協 調 機 制 (Point Coordination Function，PCF)。DCF 是 802.11 MAC 的基本擷取機制，屬於競爭式服務(contention)， 因此會產生碰撞，所以 802.11 MAC 藉由載波偵測多重存取(Carrier Sense Multiple Access，CSMA)的技術來控制傳輸媒介的存取，並減少碰撞的機會。PCF 則是提供收 送有時限性的資料，屬於免競爭式服務(contention free)，所以不會發生碰撞的情形， 這類架構需與 DCF 交互搭配使用，並只能使用在基礎架構網路(infrastructure)中。圖 2-1 描述了 802.11 MAC 通訊協定的基本架構。

圖 2-1 MAC 架構圖 Required for Contention

Free Services

Used for Contention Services and basis for PCF Point Coordination Function (PCF) Distributed Coordination Function (DCF) MAC Extent

2.1.1 分散式協調機制

分散式協調機制是標準 CSMA/CA 存取機制的基礎。不管是在無基礎架構網路 (Ad hoc)或是有基礎架構網路(infrastructure)，所有工作站都應該具備有分散式協調機 制功能。DCF 透過 CSMA/CA 技術來使不同工作站之間能夠共享同一傳輸媒介，並 且避免可能發生的碰撞衝突。如圖 2-2 所示，在傳送資料之前，CSMA/CA 會先檢查 無線網路是否處於淨空狀態，也就是判斷某一頻寬中的信號能量是否達到某一個基準 點，當信號能量在某一基準點之上時，表示此傳輸媒介是處於忙碌的狀態中，在這種 情況下，工作站會隨機為每個訊框選定一段延後(backoff)時間，直到發現傳輸媒介上 的信號能量強度在基準點之下時，才能繼續進行傳送的動作。在某些情況之下，DCF 可利用 RTS/CTS 淨空技術，進一步減少碰撞發生的可能性。 圖 2-2 分散式協調機制 2.1.1.1 訊框格式 802.11 訊框主要可分為三種類型。管理訊框(management frame)負責監督，主要用 來進入或退出無線網路，以及處理工作站之間聯結的轉移事宜。資料訊框(data frame) 主要負責在工作站之間搬移資料，資料訊框會因為所處的網路環境的不同而有所差 異 。 控 制 訊 框 (control frame) 通 常 與 資 料 訊 框 搭 配 使 用 ， 負 責 區 域 的 淨 空 (area

DIFS DIFS

Busy Medium PIFS SIFS

Immediate access when medium is free>=DIFS

Backoff Window Contention Window

Next Frame Slot time

clearing) 、 頻 道 的 取 得 (channel acquisition) 以 及 載 波 偵 測 的 維 護 (carrier-sensing maintenance)，並於收到資料時予以正面的回應(positive acknowledgment of received data)，藉此促進工作站間資料傳輸的可靠性。 802.11 MAC 採用四個位址欄位，但並非所有訊框都會用到所有的位址欄位，這 些位址欄位的值會因為 MAC 訊框種類的不同而有所差異。表 2-1 為一般的 802.11 MAC 訊框。欄位的傳送順序由左至右，訊框最後欄位為紀錄訊框的檢查碼，採用 CRC 32 技術。 表 2-1 802.11 MAC 訊框格式 Frame Control Duration/ ID

Address1 Address2 Address3 Seq- Control Address4 Frame Body CRC 2.1.1.2 訊框間隔 因為 802.11 MAC 內建避免碰撞的機制，所以工作站會延遲傳輸媒介的存取，直 到傳輸媒介再度空閒。IEEE 802.11 提供了四種不同的訊框間隔(interframe spacing)優 先權等級，每種優先權等級的訊框在傳送之前都必須等待一段固定大小的時間，不同 的訊框間隔會因為不同類型的傳輸而產生不同的優先權等級。當傳輸媒介空閒時，高 度優先權等級的資料等待時間較短，因此，如有任何高度優先權等級的資料待傳，在 優先權等級較低的訊框試圖存取媒介之前，優先權等級較高的資料早就將媒介據為己 用。圖 2-3 說明了各種訊框間隔的關係。 位元組 2 2 6 6 6 2 6 0-2312 4 位元組 2 2 6 6 6 2 6 0-2312 4

圖 2-3 各種訊框間隔關係

四種訊框間隔介紹如下：

a. 短訊框間隔(short interframe space，SIFS)：

SIFS 用於高優先的傳輸場合，主要用來做立即的回應動作。例如要求傳送訊框 (Request to Send ， RTS) 、 允 許 傳 送 訊 框 (Clear to Send ， CTS) 、 回 覆 訊 框 (Acknowledgement，ACK)等等都是屬於 SIFS。經過一段 SIFS 時間，即可進行高優先 的傳輸，一旦高優先傳輸開始，媒介即處於忙碌狀態。 b. PCF 訊框間隔(PCF interframe space，PIFS)： PIFS 主要被 PCF 使用在免競爭式服務。工作站傳送某些訊框前所必須等待的時 間，在免競爭時期，有資料待傳的工作站可以等待 PIFS 期間過後加以傳送。 c. DCF 訊框間隔(DCF interframe space，DIFS)： DIFS 是競爭式服務中最短的媒介閒置時間。在進行 DCF 競爭式傳輸服務時，工 作站傳送訊框前所必須等待的時間，如果媒介閒置時間長於 DIFS，工作站可以立即 對媒介進行存取。

d. 延長訊框間隔(Extended interframe space，EIFS)：

工作站在進行重新傳送訊框時所必須等待的時間。EIFS 並非固定時間間隔，只 有在訊框傳輸出現錯誤時才會用到 EIFS。 忙碌中 DIFS PIFS SIFS 競爭期間 …… 延後時槽 傳送訊框 其他工作站暫存訊框 並暫緩訊框的傳送

為了讓使用傳輸媒介的機會加大，則其優先權等級越高的訊框的訊框間隔越短， 訊框間隔的大小排列如下：SIFS<PIFS<DIFS<EIFS。當工作站要傳送資料時發現傳輸 媒介的狀態由忙碌變成空閒時，並不能馬上送出訊框，必須要依照訊框的優先權等級 等待一段適當的訊框間隔時間，並且在這段時間內傳輸媒介仍然是持續呈線空閒的狀 態下，才能傳送訊框。 2.1.1.3 碰撞偵測與虛擬載波偵測 在無線區域網路中，存在著兩個重要的問題，一個是碰撞不易偵測，另一個是實 體層在使用載波技術時容易誤判傳輸媒介是否忙碌中。IEEE 802.11 為解決上述兩個 問題，分別提出了兩種解決方案：RTS/CTS 協定與虛擬載波偵測。 (1) RTS/CTS 協定：

IEEE 802.11 DCF 除了採用 CSMA/CA 減少碰撞機會外，也利用了 CSMA/CA four-way handshakes 的方法來克服隱藏節點的問題。如圖 2-4 所示，在傳送端 要傳送訊框之前，先送出一個要求傳送(Request to Send，RTS)的控制訊框， 當接收端在接收到這個控制訊框時，再經過一個 SIFS 訊框間隔後，會立即回 送另一種允許傳送(Clear to Send，CTS)的控制訊框。只有當傳送端正確的接 收到接收端所回傳的 CTS 時，傳送端才能開始傳送資料訊框。同時其他工作 站接收到此傳送給傳送端的 CTS 訊框時，也會暫時停止嘗試傳送訊框，因此 傳送端在傳送訊框時與其他工作站傳送訊框時發生碰撞的機會就大幅減少 了，不過相對的卻也因此減少了空間上的使用率(Spatial reuse)。

圖 2-4 CSMA/CA with four-way handshaking

(2) 虛擬載波偵測：

載波偵測(carrier sensing)主要用來判斷傳輸媒介是否處於忙碌狀態。IEEE 802.11 具 備 兩 種 載 波 偵 測 功 能 ， 一 種 是 實 體 載 波 偵 測 (physical carrier sensing)，由實體層提供，另一種是虛擬載波偵測(virtual carrier sensing)，由 MAC 層提供。只要其中有一個偵測功能顯示媒介處於忙碌狀態，MAC 就會 將此狀況回報給較高層的協定。

實體載波偵測功能是藉由分析所有偵測到的封包(packet)以及其他工作站發 出的信號強度來判斷傳輸媒介是否忙碌中。而虛擬載波偵測是利用一個網路 配置向量(Network Allocation Vector，NAV)來記載其他工作站還需要多久的 時間來傳送訊框，進而使工作站能根據這些資訊來知道傳輸媒介是否處於忙 碌中。圖 2-5 說明了 NAV 如何保障整個程序不受干擾。 Receiver Transmitter RTS CTS ACK DATA

圖 2-5 利用 NAV 進行虛擬載波偵測 RTS 和 CTS 訊框都會包含一個 duration 欄位，主要用來記載傳送端要傳送訊框 時所需要的時間，當其他工作站在接收到由傳送端送出的 RTS 訊框或是由接收端送 出的 CTS 訊框時，就會將 duration 欄位所記載的時間紀錄到自己的網路配置向量中。 網路配置向量所記載的等待時間可能會一直累積，在時間為歸零之前，工作站不能傳 送任何訊框，因此網路向量配置就好像具備了類似載波偵測的功能，用來告訴工作站 傳輸媒介是否忙碌中。 至於為什麼 RTS 與 CTS 訊框都需要記載傳送訊框的時間而不是只有 RTS 訊框記 載就可以了，這是因為在某些情況下工作站可能只收的到接收端的訊號而無法收到傳 送端的訊號，為了避免這類可能存在的隱藏工作站(hidden station)的問題，RTS 與 CTS 訊框都需要記載傳送訊框時間。 2.1.1.4 延後機制 在 DCF 機制中，當傳輸媒介處於閒置的狀態時，並不能馬上傳送訊框，必須先 等待一段訊框間隔時間(DIFS)才能接著傳送。如果傳輸媒介處於忙碌或是在 DIFS 時 間到之前有其他工作站率先傳送訊框，就必須繼續監聽此訊框之傳送，等到訊框傳送 Transmitt Receiver Network Allocation Vector (NAV) RTS CTS 訊框 ACK SIFS SIFS SIFS NAV (RTS) NAV (CTS) DIFS Contention Window Defer Access

結束後再繼續等待一段 DIFS 時間。在這一段時間中，如果仍然沒有其他工作站傳送 訊框，就會進入到所謂的競爭視窗(Contention Window，CW)期間，由於傳輸媒介在 忙碌的這段時間內，可能會有多個工作站有資料要傳送並準備爭取下一段傳輸媒介的 使用權，因此，傳輸媒介由忙碌轉為閒置的這個時間點是最有可能發生碰撞的時候。 為了在傳輸媒介轉為閒置時，讓準備競爭通道的工作站能夠分散在各個時間點上傳 輸，以減少碰撞的發生，IEEE 802.11 藉由延後機制(Backoff Time)來產生一個延後時 間。此延後時間會隨時間而遞減，工作站必須等到其延後時間減為零時才能傳送訊框。 CW 可進一步地分割為時槽(slot)，時槽的長度則會因傳輸媒介而有所不同。工作 站會隨機挑選某個時槽，並等候該時槽的到來以便存取媒介，當多部工作站同時試圖 傳送訊框時，挑到第一個時槽的工作站就可以優先傳送訊框。所以，如果所有的工作 站的延後時間都不相同，則訊框在傳送時就不會有碰撞發生的情況。CW 的大小通常 是 2 的指數倍數減一(例如 1、3、7、15、...、1023)，CW 的大小是由實體層所限制， 其最長為 1023 個傳輸時槽。 2.1.1.5 訊框之切割與組合 在自然的環境中，存在著許許多多會影響無線傳輸的干擾，為了降低可能遭受干擾的 資料量，IEEE 802.11 會將較大型的訊框進行切割，才可經由傳輸媒介加以傳送，藉 由降低可能遭受干擾的資料量，來提升訊框傳送的可靠度與提高整體的有效傳輸量。 當封包長度超過網路管理人員所設定的切割門檻值(fragmentation threshold)時，就會 對訊框進行切割，每個訊框片段(fragment)都具有相同的訊框編號，以及一個遞增的 訊框片段編號，以便於重組。在[24]、[25]中有提出 Dynamic Fragmentation 的功能， 他們讓節點可以依照傳輸環境的變化來動態調整 fragmentation threshold 的大小，以增 加網路的輸出。

所謂訊框切割(fragmentation)指的是將一個 MSDU (MAC service data unit)訊框切 割成許多較小的 MPDUs (MAC protocol data units)訊框，此部分是由傳送器負責。接 收器是負責將屬於同一個 MSDU 的媒體存取層協定資料單位 MPDU 收齊後立刻進行 重組的工作。

2.1.2 Hidden and Exposed Terminal

無線網路在本質上與有線網路有著很大的不同，因為無線網路在傳送時能量的損 失相較於有線網路要大的多，同樣的訊號會因為距離的長短而在強度上會有不同的差 距，所以基本上無線網路上每個節點所接收到的訊號無法跟有線網路上所有節點所接 收到的訊號一樣。IEEE 802.11 存在著兩個明顯的節點問題，分別是 hidden terminal 與 exposed terminal。 (1) Hidden Terminal 如圖 2-6 所示，節點 A 偵測到傳輸媒介是處於閒置的狀態，便傳送資料給節 點 B，但是對節點 B 而言，傳輸媒介並非是處於閒置的狀態，而是處於忙碌 的狀態，因為節點 C 正傳送資料給節點 D，因此節點 A 傳送資料給節點 B 時， 便會因為碰撞(collision)而無法正確接收。 圖 2-6 Hidden terminal A B D

(2) Exposed Terminal 如圖 2-7 所示，節點 B 想要傳送資料給節點 A，但是因為偵測到傳輸媒介目 前是處於忙碌的狀態而發生 Back-off，因為節點 C 正在使用傳輸媒介傳送資 料給節點 D，但是其實這個 Back-off 並非一定是必要的，因為節點 B 傳送資 料給節點 A 並不會影響到節點 C 與節點 D 之間的傳送。 圖 2-7 Exposed terminal.

2.2 Omni-directional MAC

目前來說，無線 ad hoc 網路都是使用全方向性的天線，它的優點是簡單，但是由於 是對所有方向廣播，因此會造成不必要的干擾導致降低空間使用率。下面將介紹跟全 方向性天線有關的幾個MAC協定。

2.2.1 MACA

Multiple Access Collision Avoidance (MACA)[21]是由 Karn 提出來改進 CSMA/CD 問題的新 MAC 通訊協定，透過將 IEEE 802.11 的 CSMA/CA 中的 Carrier Sense 部分去 掉，加入 RTS/CTS 這樣的 Virtual Carrier Sense 來避免 Hidden Terminals 問題的發生。 MACA 使用 Three-Way Handshake 的機制，RTS-CTS-Data，來完成資料的傳輸。首先，

A B C D

傳送者會傳送一個包含有資料長度的 RTS 出去，當接收者收到 RTS 之後，同樣會傳 送一個包含資料長度的 CTS 出去，假如在傳送者與接收者的傳輸範圍內還有其他使 用者，並且接收到 RTS 或是 CTS 其中一個訊框的話，則在資料傳送的這段期間內， 不能再傳送 RTS/CTS/Data 出去，因此就減少了碰撞的機會。

2.2.2 DBTMA

Dual Busy Tone Multiple Access (DBTMA)[22]是為了解決RTS/CTS-based的MAC 層通訊協定utilization的問題所設計出來的，透過使用Busy Tone的方式來判斷傳輸媒 介使用的情形。DBTMA將頻寬切割為兩個頻道，一個是資料頻道(data channel)，另 一個是控制頻道(control channel)，資料頻道是用來傳送資料，而控制頻道除了傳送 RTS/CTS之外，還利用兩個busy tone來區分溝通時的傳送與接收狀態，分別是BT 和_t r BT ，BT 是用來表示目前頻道正在使用中，而且是處於傳送的狀態，_t BT 則是表示_r 目前頻道是處於接收的狀態中。 當無線網路中的節點在使用頻道傳送資料時，便會送出 RTS 後在控制頻道中持 續的傳送BT 這個 Busy Tone，當節點傳送完 CTS 後也會在控制頻道中持續的傳送_t BT_r

這個 Busy Tone。DBTMA 就是透過這兩個 Busy Tone 的區別，來讓鄰近的節點知到 目前頻道的使用狀態，進而提升網路的 utilization 與降低隱藏工作站的問題，但由於 DBTMA 需要兩個分離的頻道與兩個 Busy Tone，增加了實作上的困難度。

2.2.3 MACA/BI

之前所提到的MAC通訊協定都是以Sender端為起始的溝通機制，F. Talucci and M. Gerla所提出的Multiple Access with Collision Avoidance By Invitation (MACA/BI) [23] 卻是以接收端為起始的溝通機制。MACA/BI將RTS與CTS兩個訊框結合成一個

RTR(ready to receive)訊框，其運作方式說明如下，MACA/BI是週期性的發出RTR來 詢問鄰近的節點有無資料要傳送，如果有資料要傳送則直接傳送，如果沒有資料要傳 送則再定期的發出RTR來詢問，如圖2-8 (a) 所示，節點B會送出RTR詢問鄰近節點 有無資料要傳送，當節點A有資料要傳送並接收到RTR後就直接將DATA傳送給B，如 圖2-8 (B)所示。雖然MACA/BI對於作flow control或是congestion control很有幫助，但 卻有一個明顯的問題，那就是周期性的傳送RTR，多久傳送一次RTR將會影響到整個 網路的效能，如果間隔時間太長，常常會發生有資料要傳送，但是卻要等到RTR開始 詢問時才能開始傳送資料，因此降低了網路的效能，相反的，如果間隔時間太短，鄰 近節點彼此的RTR將會很容易發生碰撞。 圖 2-8 MACA/BI

2.3 Directional MAC

方向性(Directional)天線比全方向性(Omni-Directional)天線提供了更多的優勢，除 了提升空間的使用率之外，還可以減少co-channel干擾的情形、增加傳送的距離以及 節省傳送所需的電力。方向性天線需有下列四個假設: (1)同一個區域中的所有節點共 享同一個頻道 (2)每一個節點都配備數個方向性天線 (3)一個節點如果同時使用不同 A B C D RTR RTR RTR A B C D DATA (a) (b)

的天線來接收資料會有干擾現像發生 (4)節點無法同時透過不同的方向進行傳輸，在 這些假設之下，有許多方向性的MAC[3][5][7][8][10][11][12][13][14][15]相繼被提出。 在方向性MAC中，RTS/CTS/DATA以及ACK封包可以使用方向性的方式來傳送，讓 原本在IEEE 802.11 MAC協定下，因干擾情形而無法進行傳輸的節點，可以同時進行 傳輸。所以方向性MAC顯著提升了網路流量的效能表現，下面將介紹與方向性天線 有關的幾個MAC協定。

2.3.1 D-MAC

D-MAC[3]提出了兩種不同的Scheme: D-MAC Scheme 1與D-MAC Scheme 2。 D-MAC兩個Scheme的效能表現都比IEEE 802.11好，因為它允許兩個連線同時傳輸，這 是之前IEEE 802.11所不能達成的。如圖2-9(a)所示，D-MAC Scheme 1 的RTS、DATA 與ACK封包都是採用方向性的方式來傳輸，所以節點A與節點B、節點C與節點D可以 同時進行通訊而不會互相干擾。不過，這樣的方式卻有一些問題存在，例如: 在圖2-9(b) 中，因為方向性RTS封包的關係，節點C並不知道節點A與節點B正在通訊，所以當節 點C要傳送資料給節點B時，便會發生碰撞的問題。D-MAC Scheme 2可以解決D-MAC Scheme 1所帶來的問題，如圖2-9(c)所示，D-MAC Scheme 2同時採用了方向性以及全 方向性的RTS封包，因此節點B發出全方向性的RTS封包來通知A與節點C，所以節點C 只能往節點D的方向傳送資料，如此便保留了D-MAC Scheme 1同時傳輸的優點並且避 免了碰撞的發生。另外，如圖2-9(d)，[3]也提出了使用Wait-to-Send(DWTS)封包來避 免不必要的RTS重送現像。然而，D-MAC需要依靠追蹤(tracking)或者是定位(locating) 的技術(例如: GPS或者是週期性的Location Packet)來取得其他節點的位置，因此在某 些情況下會變的不適用。

圖 2-9 D-MAC (a) D-MAC SCHEME 1 (b) D-MAC SCHEME 1 Collision Problem (c) D-MAC SCHEME 2 (d) Wait-to-Send(DWTS)

2.3.2 Directional Virtual Carrier Sensing (DVCS)

Takai提出了DVCS[8]來預防方向性天線所帶來的碰撞問題，而DVCS可以分為三 個部分：

a. AOA Caching

每個節點運用了一個Angle-of-Arrival (AOA) Table來記錄鄰近節點所在的方位，透

dRTS dRTS oCTS oCTS oCTS oCTS

dDATA dDATA dACK dACK (a) A B C D oCTS oCTS oCTS oCTS dRTS oRTS oRTS dDATA dDATA dACK dACK (c) A B C D dRTS dRTS oCTS oCTS dDATA dACK (b) A B C D dRTS oCTS oCTS oRTS oRTS dDATA dACK (d) A B C D oRTS DWTS oRTS oCTS oCTS

過Switch-Beam Antenna 將整個區域切割成多個Sector，AOA Table 紀錄節點所在的 Sector。Sender在傳送資料給Receiver前，會先尋找AOA Table中Receiver所在的Sector， 之後便朝這個Sector傳送RTS。Receiver在收到RTS後，也會先尋找AOA Table中Sender 所在的Sector，然後朝此方向回傳CTS給Sender，接著兩個節點繼續用同樣的方式來 傳送Data與ACK封包。

b. Beam Locking and Unlocking

當Receiver接收到RTS封包後，它會鎖住往Sender的方向並傳送CTS封包，當Sender 接收到CTS封包後也會鎖住往Receiver的方向。一直到Data/ACK封包傳輸完成之後， Sender/Receiver會解開原先被鎖住的方向，回到全方向接收的模式。

c. Directional Network Allocation Vector (DNAV)

DNAV主要用來取代IEEE 802.11中的NAV，每個DNAV都紀錄了一個方向以及一 個寬度，每個節點可以設定多個DNAV，節點每次接收到封包後，都會更新DNAV。 如圖2-10所示，共有三個DNAV被設定，除了這些DNAVs過期，否則這一個節點將無 法從 0°到105°或者是 270°到 330°等三個方向傳送任何訊號，但是它可以從105°到 270° 以及 330°到360°_{等方向傳送訊號。}

2.3.3 Circular Directional RTS/CTS

Circular Directional RTS/CTS[5]提出一個有效率的方向性MAC協定，所有的封包 一定都是使用方向性的方式來傳輸，因此在Handshake的過程中，如果Sender或 Receiver送出最少一個全方向性的控制封包，那麼傳輸的範圍將會因此被限制住(圖 2-11)，所以此方法中RTS/CTS/DATA/ACK封包都是使用方向性來傳送。在方向性MAC 中，如何得知鄰居節點的方向是一個必須解決的問題，比較常見的方法是每個節點都 配置一個GPS，藉由交換RTS/CTS封包時來通知對方自己的位置。[5]提出了一個 Location Table來紀錄相關的方向，節點在接收到封包後，透過Select Diversity可以由 訊號的強度來得到接收的方向，並把自己的ID、鄰居的ID、自己接收的方向以及封包 傳送的方向紀錄在Location Table(表2-2)裡。不過，由於所有的封包都是使用方向性來 傳輸，並無法確保每個節點都可以接收到封包，因此[5]還提出了一個Circular的方式 來傳送RTS/CTS封包，Sender首先傳送一個特定方向的RTS，例如Beam 1，接著在下 一個方向Beam 2傳送相同的RTS，這樣的動作會一直持續到所有的Beam都送出RTS 為止。如此一來可以保有方向性的傳輸距離，也可以讓所有鄰居節點藉由接收封包來 紀錄方向。

圖 2-11 The coverage range of a MAC protocol that uses an omni RTS transmission A B C Communication range in directional RTS Communication range in omni-directional RTS

表 2-2 A record of Location Table

Me Neighbor My Beam Neighbor’s Beam A B 4 2

2.4 Directional MAC with Power Control

使用Power Control也是一種可以同時進行傳輸的方式，如圖2-12所示，原本節點C 與節點D必須等節點A與節點B這一個進行中的通訊完成後，才能夠進行通訊;但是，在 降低節點C的傳輸功率後，節點C的傳輸便不會影響節點B，所以可以同時進傳輸。這 樣的方法也可以適用在方向性天線中，下面將介紹跟方向性天線有關的幾個MAC協定。

圖 2-12 Power Control Scenario

2.4.1 Two-Level Transmit Power Control

如圖2-13所示，方向性天線的傳輸距離比全方向性天線遠，當節點n與節點m進行 傳輸時，節點x、y、z會被鎖住而無法進行通訊，因此會造成Exposed Node的情形發 生。Saha在[9]中提出Two-Level的傳輸功率控制機制，經由控制方向性傳輸的功率讓 方向性傳輸的距離跟全方向性的距離幾乎相等，虛線就是經過控制功率之後，方向性 天線的傳輸距離。在這個情況下的節點x、y、z便不會接收到節點n所傳送的封包，因 此可以進行通訊。這一個方法可以有效減少電力的消耗，延長電池的使用時間，也提 升了空間使用率以及增加網路的流量。 A B C D

圖 2-13 Improving SDMA efficiency with Directional Antenna and power-controlled Directional Transmission

2.4.2 DMACP

[16]提出了一個使用方向性天線加上 Power Control 的方向性 MAC 協定，由於這一個 方法主要是修改 IEEE 802.11，所以他提出了幾個修改的方向: (a)尋找傳輸者/與接 收者的方向(b)設計合適的傳輸與接收方式，避免不同的通訊互相干擾(c)在傳輸資料 時，使用 Power Control 來減少 Power 的消耗。[16]也討論了使用方向性天線的好處 以及提出幾個使用方向性 RTS 與 CTS 封包的方案。

[16]的實驗結果也顯示，使用方向性天線帶來了許多好處，例如: 很明顯的節省 Power、網路流量的提升以及干擾的減少。然而，方向性天線也帶來了一些問題，例 如: 實做上的複雜度以及隱藏節點(Hidden Terminals)、Deafness 等等的問題。

2.4.3 Distributed Power Control (DPC)

[7]提出了一個適用於隨意網路的分散式 Power Control 的 MAC 協定，在這一個協定 中，接收者收集相關的干擾資訊並且將資訊回傳給傳送者，接著傳送者便可藉由這些 m n a g a h x y z

資訊來估計傳送時可以減少的 Power。這些資訊主要由傳送 RTS、CTS、DATA 以及 ACK 時所獲得的最小 SINR(signal to interference plus noise)所組成。

在這一個方法中，DATA 以及 ACK 封包是由方向性來傳送，傳送的 Power 則是由收集 的資訊計算而來，而 RTS 與 CTS 封包則是用完全電力(full power)以及全方向性來傳 送。由[7]的實驗結果看來，效能很明顯的比 IEEE 802.11 協定還要好，而且使用 SINR 所計算的 Power 與最理想的 Power 幾乎相同。

3.

第三章 F-DMAC

經由之前的相關研究與分析，我們了解到 D-MAC Scheme 2 雖然可以解決 Scheme 1 所產生的碰撞問題，卻相對的也會降低空間使用率，因此我們為了提升空間使用 率，所以提出一個新的通訊協定: Fragmentation based D-MAC(F-DMAC)。在 F-DMAC 中，我們利用方向性天線的特性，讓處於 block 狀態下的 Receiver，可以回覆 CTS 封 包給 Sender，便可增加空間的使用率。不過，在 block 狀態下傳送 CTS 封包，基本上 會發生碰撞情形，因此我們在 F-DMAC 中又增加了 DTS(Delay to Send)封包來避免這 一個問題，DTS 封包與 CTS 封包的長度一樣，因此所需的傳輸時間非常短，並不會 讓其他節點 block 太久的時間。F-DMAC 在傳送 packet 的過程中，只比 D-MAC 2 多 了一個比較 packet 傳送時間與 NAV 長短的運算，所耗費的計算時間也非常短。在下 面的章節我們會對 F-DMAC 協定做更詳細的說明。

3.1 問題定義

我們觀察到 D-MAC Scheme 2 的 Handshake 過程中，會發生降低空間使用率以及碰撞 兩個問題，說明如下: 首先，如圗 3-1 所示，是一個方向性 RTS 封包造成碰撞的情形。節點 B 與節點 C 先進行通訊，節點 D 因為收到節點 C 的 CTS 封包，所以會 block 往節點 D 的方向， 因此節點 D 會發出方向性的 RTS 封包給節點 E。因為方向性 RTS 封包的關係，節點 C 並不會知道節點 D 與節點 E 正在進行通訊，所以當節點 B 與節點 C 的通訊結束後， 要進行下一次通訊時，節點 C 會發出的全方向性的 CTS 封包。此時的節點 D 正處於 傳輸狀態，因此無法接收到節點 C 的 CTS 封包，也無法設定 NAV 以及進入 block 狀 態，這就是[3]所提到的 Deafness 現像。當節點 D 與節點 E 通訊結束，並進行下一次

通訊時，節點 D 會發出全方向性的 RTS 封包，此時會與節點 B 與節點 C 正在進行中 的通訊發生碰撞，這就是使用方向性 RTS 封包所造成的 Deafness 以及碰撞情形。

圖 3-1D-MAC Scheme2 Directional RTS Problem

另一個情況是，如圗 3-2 所示，當節點 D 與節點 E 兩個節點進行通訊時，節點 C 會接收到節點 D 的 RTS 封包，然後將自己設為 block 的狀態。此時節點 B 送出 oRTS 封包給節點 C 時，由於節點 C 處於 block 的狀態，因此無法回覆 CTS 封包給節點 B， 所以造成了節點 B 會一直發送 RTS 封包的情形，這也就是 D-MAC Scheme 2 會降低空 deafness collision 200m 200m 200m 200m 200m A B C D E F oRTS oRTS oCTS oCTS dDATA dACK dRTS oCTS oCTS dDATA dACK oRTS oRTS oCTS oCTS dDATA _oRTS oRTS oCTS oCTS

圖 3-2 D-MAC Scheme 2 Decrease Spatial Reuse Problem 如果允許節點 C 回覆 oCTS 封包給節點 B，如圖 3-3 所示，所以節點 B 可以繼續 傳送 DATA 封包給節點 C。由於之前節點 C 發出 CTS 封包時，節點 D 正楚於 deafness 狀態，因此沒有接收到節點 C 的 CTS 封包。但當節點 D 與節點 E 的資料傳輸結束後， 還要進行下一次的資料傳輸時，節點 D 會發出 oRTS 封包，但是由於節點 B 與節點 C 的通訊尚未結束，因此節點 C 會同時接收到節點 D 的 RTS 封包與節點 B 的 DATA 封 包，因而發生碰撞情形。所以，雖然在 block 狀態傳送 CTS 封包可以提升空間使用率， 卻也帶來了封包碰撞的問題。 200m 200m 200m 200m 200m A B C D E F oRTS oRTS oCTS oCTS oRTS oRTS oRTS oRTS oRTS oRTS dACK dDATA

圖 3-3 D-MAC Scheme 2 Transmit in Blocked Status Problem

3.2 F-DMAC 介紹

我們提出的 F-MDAC 可以有效解決上一個章節提到的 Directional RTS 與 Blocked CTS 問題。F-DMAC 在封包傳送時，可以使用全方向性以及方向性兩種方式來傳送，並 經由 Neighbor Information Table(NIT)來得知節點的位置，因此節點不需要配備 GPS， 而修改後的 RTS、CTS 封包以及新增的 DTS 封包，則可以避免 Deafness 以及 Collision 的情形。下面章節我們會仔細說明封包傳送方式、NIT、控制封包格式以及 Handshake Mechanism。

3.3 控制封包傳送方式

F-DMAC 在傳送 RTS、CTS、DATA、ACK 封包所採用的方式與 D-MAC Scheme 2 相 200m 200m 200m 200m 200m A B C D E F oRTS oRTS oCTS oCTS oRTS oRTS oCTS dDATA dACK dDATA oRTS oRTS oCTS deafness collision

同，表 3-1 為 F-DMAC 在傳送各種封包時，所採用的傳送方式。 表 3-1 F-DMAC 封包傳送方式

Packet Type Transmit Type

RTS dRTS, oRTS CTS oCTS DATA dDATA ACK dACK DTS dDTS d: Directional , o: Omni-directional

3.4 Neighbor Information Table (NIT)

依據 Circular Directional RTS/CTS[5]所提到的 Location Table，方向性天線的節點 可以在沒有配備 GPS 的情況下得知其它節點的位置。因此，我們也採用了[5]的 Location Table，不過我們認為 Neighbor ID 以及 Received Beam 已經足夠滿足 F-DMAC 的需求，因為我們有全方向性傳送的 RTS/CTS 封包，不需要使用 Circular Directional RTS/CTS ， 因 此 我 們 的 Location Table ， 在 此 我 們 稱 它 為 Neighbor Information Table(NIT)，只紀錄這兩個欄位，如表 3-2 所示。

每個節點所紀錄的每一筆資訊包含，Neighbor ID: 所有能正確接收到封包的節 點，Received Beam: 節點使用 selection diversity 的方法，可以判斷出訊號所接收的方 向。

表 3-2 F-DMAC Neighbor Information Table Neighbor ID Received Beam

圖 3-4 方向性天線的傳送範例

如圖 3-4 所示，當一個節點接收到其他節點傳送的封包時，會將封包中的 Source ID 以及經由 selection diversity 判斷後的接收方向紀錄在 NIT 中，表 3-3 中說明了節點 A、B、C、D 的 NIT 內容。

表 3-3 Records of F-DMAC NIT For node A

Neighbor ID Received Beam

B 3 C 3 D 2

For node B

Neighbor ID Received Beam

A 1 C 1 D 4 3 1 2 B 4 3 1 2 C 4 3 1 2 A 4 3 1 2

For node C

Neighbor ID Received Beam

A 1 B 3

For node D

Neighbor ID Received Beam

A 2 B 3

3.5 控制封包格式

為了避免碰撞情形的發生，我們新增了 DTS 這一個控制封包，如表 3-4 所示， DTS 的格式基本上與 CTS 相同，但是在 Frame Control 中的 Control Packet Type 欄位 會區別這兩個不同的控制封包，Duration 欄位則是用來通知其它節點淨空媒體的時 間，在傳送 DTS packet 時，只等待一個 SIFS 的時間，以取得更高的優先權。而 RTS/CTS 控制封包我們也加入了一個 Frag_Duration 的欄位，如表 3-5/3-6 所示。Frag_Duration 主要是用來紀錄 Receiver/Sender 可以接收/傳送的資料封包大小。而 Data/ACK 兩個 封包的格式則與 IEEE 802.11 相同。 表 3-4 Delay To Send (DTS)

Frame Control Duration RA FCS

表 3-5 Modify Request To Send (RTS)

表 3-6 Modify Clear To Send (CTS)

Frame Control Duration RA Frag_Duration FCS

3.6 F-DMAC Handshake Mechanism

在我們提出的 Handshake Mechanism 中，我們分為 Directional RTS 狀態、Blocked CTS 狀態兩個部分來做說明。在進行說明之前，我們先介紹相關數學符號代表的意 思。t_RTS 、t_CTS、t_ACK、t_DTS分別代表傳送 RTS、CTS、ACK、DTS 封包所需要的時間， 而Ant是一個常數，代表著每個節點所配備的 Antenna 個數(在這裡我們假設每個節 點配備的 Antenna 數量一樣)，t_d =t_DTS + ×3 SIFS+t_ACK代表傳送一個 DTS 封包所需要 的期間， min(NAV 代表目前 NAV 中最短的一個並且大於_i) t 。_d l_MSDU是未經過

Fragmentation 的 DATA 封包長度，l_MPDU是 Fragmentation 後要傳送的 DATA 封包長度，

而l_remain則是分割後等待下一階段傳送的 DATA 封包長度，Sn代表 MPDU 的序號。tx()

可以由封包長度計算出傳輸時間，r()則是由時間除與速率來計算封包的長度。

3.5.1 Directional RTS 狀態

我們提出了一個 Handshake Mechanism 來解決方向性 RTS 封包所帶來的碰撞問 題(如圖 3-3)，圖 3-5 為 F-DMAC 送出方向性 RTS 封包的運作流程。

圖 3-5F-DMAC Handshake Mechanism (Directional RTS)

F-DMAC 傳送方向性 RTS 封包的 Handshake Mechanism 說明如下:

Step 1: 當節點接收到上層的封包時，會先確認目前 Channel 是否楚於 Idle 狀態。所謂 Idle 狀態就是節點本身沒有傳送與接收資料等動作，並且沒有設定 NAV。當 節點楚於 Idle 狀態時，則完全依照 IEEE 802.11 的方式來進行通訊，反之進入 Step 2。

Step 2: 從 NIT 中取出 Receiver 的方向，如果 NIT 沒有 Receiver 的紀錄，則完全依照 IEEE 802.11 的方式來進行通訊，反之進入 Step 3。

Step 3: 如果往 Receiver 的方向處於 Block 狀態則進入 Step 4，反之則進入 Step 5。 Step 4: 啟動 Back-off 機制，等待下一回合的傳送。

Step 5: 如公式(1)，Sender 會比對 min(NAV 是否比整個資料封包傳送時期還短。當(1)_i)

Get Beam from NIT

Direction Blocked tx(pkt) _> NAV Send dRTS Send dRTS N Y N Y Send dDATA tx(pkt) > NAV Send dDATA Y N Back-off State

成立時，代表在 Sender 傳送資料封包的過程中， min(NAV 所代表的連線已_i) 經完成通訊。這一個連線會因為 Sender 所發出的 RTS 封包是方向性的，而沒 有設定 NAV，當這一個連線有再次通訊的需求時，便會送出全方向性

RTS/CTS 封包而造成 Sender 發生 Deafness 的情形，因此進入 Step6，反之則 代表這一個連線不會干擾到其他通訊，所以 Sender 送出 dRTS 封包，進行 CTS/DATA/ACK 通訊。

min(NAV_i)<Duration_RTS (1)

Step 6: 經由公式(2)，我們可以計算出在 min(NAV 時間之內，能用來傳送資料封包_i) 的時間，並將值填入 RTS 封包的 Frag_Duration 欄位中，然後送出 dRTS 封包。 傳送 dRTS 封包後，如公式(3)將時間除與速率可得知封包長度，再利用 Fragmentation 的方式來取得一個長度適合的資料封包，接著進入 Step 7。

_ _RTS min( _i) _{RTS CTS} 3 _ACK

Frag Duration = NAV −t −t − ×SIFS t− (2)

(

_

)

MPDU RTS

l

=

r Frag

Duration

(3)

Step 7: 當 Receiver 收到 RTS 封包後，利用公式(4)算出需要淨空媒體的時間，並把值 填入 CTS 封包的 Duration 欄位，然後把 oCTS 封包傳送出去，接著進入 Step 8。

( 1)

CTS RTS RTS d

Step 8: Sender 傳送經過 Fragment 的 dDATA 封包給 Receiver，Receiver 回傳 dACK 封 包，接著進入 Step 9。

Step 9: 此時 min(NAV 已經倒數為 0，我們經由公式(5)計算 Sender 要淨空媒體的時_i) 間並把值填入 DTS 封包的 Duration 欄位，然後把 dDTS 封包傳送出去，接著 進入 Step 10。

( ) ( 1)

DTS remain d

Duration =tx l + Ant−Sn− × −t SIFS (5)

Step 10: 如公式(6)，比對 min(NAV 是否比傳送i) lremain需要的時間還短。當(6)成立時，

代表會發生如 Step 5 所敘述 deafness 與碰撞情形，因此進入 Step 11，反之則 進行傳送 dDATA 封包。

min(NAV_i)<tx l( _remain)+SIFS+t_ACK + (6) t_d

Step 11: 我們藉由公式(7)來計算可以傳送的封包長度，然後利用 Fragmentation 的方 式來切割資料封包，接著回到 Step 8，反覆運算直到整個資料封包完全送出為止。 min ( ) MPDU ACK l =r NAV −SIFS−t (7) 下面我們用實際的範例來說明 F-DMAC 傳送方向性封包的過程: 如圖 3-6 所示，當節點 D 傳送方向性 RTS 封包時，會先確認傳輸資料封包所需 的時間是否小於 NAV，在傳輸所需時間小於 NAV 的情況下，代表節點 D 與節點 E

的通訊不會影響到節點 B 與節點 C 正在進行中的通訊，因此節點 D 可以傳送方向性 的 RTS 給節點 E。

圖 3-6 F-DMAC Small Packet Case (Directional RTS)

相反的，如圖 3-7 所示，如果傳輸資料封包所需的時間大於 NAV，代表節點 B 與節點 C 的通訊會比節點 D 與節點 E 的通訊還要早結束，因此在節點 B 與節 點 C 的下一次通訊中，會因為節點 D 處在傳輸狀態而造成 Deafness 的情形。因 200m 200m 200m 200m 200m A B C D E F oRTS oRTS oCTS oCTS dDATA dACK dRTS oCTS oCTS dDATA dACK oRTS oRTS oRTS oRTS dDATA dRTS oCTS oCTS dACK dDATA dACK

此節點 D 使用 Fragmentation 的方式把原來的資料封包分為兩個較小的 Fragment 封 包 ， 並 將 傳 輸 第 一 個 Fragment 封 包 所 需 的 時 間 記 錄 在 RTS 封 包 中 的 Frag_Duration 欄位，然後將 dRTS 封包傳送給節點 E。透過 RTS 封包中的 Frag_Duration，節點 E 可以知道這是一個方向性 RTS 封包，因此節點 E 算出需 要淨空媒體的時間，然後把它紀錄在 CTS 封包的 Duration 欄位中，再將 oCTS 封包傳送出去。當節點 D 收到 CTS 封包後，便開始傳送第一個 Fragment 封包給 節點 E，節點 E 成功接收後便回覆一個 dACK 封包給節點 D。此時節點 B 與節 點 C 的通訊結束，節點 D 會算出需要淨空媒體的時間，然後把它紀錄在 DTS 封 包的 Duration 欄位中，再將 dDTS 封包傳送給節點 C。當節點 C 收到 DTS 封包 時，會依照 DTS 封包中的 Duration 時間設定一個 NAV，一直到節點 E 收到另外 一個 Fragment 並回覆 dACK 封包之後，節點 C 才會送出下一個 CTS 封包，因 此可以避免封包碰撞的情形。

圖 3-7 F-DMAC Large Packet Case (Directional RTS)

3.5.2 Blocked CTS 狀態

經由上面的分析，我們知道經由通訊時間長短的判斷以及 DTS 封包的交換，可以 解決方向性 RTS 封包所造成的碰撞問題。另外，我們也觀察到這樣的方法可以用來 解決在 block 狀態下傳送 CTS 封包所造成的問題。圖 3-8 為 F-DMAC 在 block 狀態傳 送 CTS 封包的運作流程。 200m 200m 200m 200m 200m A B C D E F oRTS oRTS oCTS oCTS dDATA dACK dRTS oCTS oCTS dACK oRTS oRTS dDATA dDTS dRTS oRTS oRTS oCTS oCTS oCTS oCTS DATA Fragement DATA Fragement dACK

圖 3-8 F-DMAC Handshake Mechanism (Blocked CTS)

F-DMAC 在 Block 狀態傳送 CTS 封包的 Handshake Mechanism 說明如下:

Step 1: 當節點接收到 RTS 封包時，會先確認目前 Channel 是否楚於 Idle 狀態。當節 點楚於 Idle 狀態時，則完全依照 IEEE 802.11 的方式來進行通訊，反之進入 Step 2。

Step 2: 如果 RTS 封包中的 Frag_Duration 不為 0，以及 Receiver 所設定的 NAV 中有 一個以上是因為接收 CTS 而設定的，則進入 Step 3，反之則進入 Step 4。 Step 3: 啟動 Back Off 機制，等待下一回合的傳送。

Step 4: 如公式(8)，Receiver 比對 min(NAV 是否比整個資料封包傳送時期還短。當(8)_i) 成立時，代表在 Sender 傳送資料封包的過程中， min(NAV 所代表的連線已i)

Frag_Duration=0 and none direction blocked by CTS Duration > NAV Send oCTS Send oCTS Y N N Y Send dACK Send dACK Send dDTS Duration > NAV Y N Back-off State

經完成通訊。這一個連線會因為 Receiver 發出的 CTS 封包所造成的 Deafness 現象，而沒有設定 NAV，當這一個連線有再次通訊的需求時，會送出全方向 性 RTS/CTS 封包而造成在 Receiver 發生 Collision 情形，因此進入 Step 5，反 之則代表這一個連線不會干擾到其他通訊，所以 Receiver 送出 oCTS 封包， 進行通訊。

min(NAV_i)<Duration_RTS −t_RTS −SIFS (8)

Step 5: Receiver 經由公式(4)算出要淨空媒體的時間，並把值填入 CTS 封包的 Duration 欄位。接著利用公式(9)，我們可以計算出在 min(NAV 的時間之內，可用來接_i) 收資料封包的時間，並把值填入 CTS 封包的 Frag_Duration 欄位，然後把 oCTS 封包傳送出去，接著進入 Step 6。

_ _CTS min( _i) _CTS 2 _ACK

Frag Duration = NAV −t − ×SIFS−t (9)

Step 6: Sender 經由 CTS 封包中的 Frag_Duration，得知 Receiver 可以接收資料封包的 時間，並使用公式(10)來計算可以傳送的封包長度，然後利用 Fragmentation 的方式來 切割資料封包，然後利用公式(11)計算出傳送切割之後剩餘資料封包的時間，將值填 入 DATA 封包的 Duration 欄位中，然後把 dDATA 封包傳送出去，接著進入 Step 7。

( _ ) MPDU CTS l =r Frag Duration (10) ( ) MPDU remain Duration =tx l (11)

Step 7 : 當 Receiver 接收 DATA 封包後，經由 DATA 封包中的 Duration，使用公式(12) 來比對 min(NAV 是否比 Sender 傳送_i) l_remain所需要的時間還短。當(12)成立 時，代表在會有如 Step 4 的碰撞情形發生，因此進入 Step8，反之則進行傳送 dACK 封包。

min(NAV_i)<Duration_MPDU +t_ACK + (12) t_d

Step 8: 經由公式(13)計算可以接收封包的時間，並填入 ACK 封包的 Duration 欄位中， 然後將 dACK 封包送出，進入 Step 9。

min( )

ACK i ACK d

Duration = NAV −t − (13) t

Step 9: 此時 min(NAV 已經倒數為 0，我們經由公式(14) 計算出 Receiver 要淨空媒體_i) 的時間並把值填入 DTS 封包的 Duration 欄位，然後把 dDTS 封包傳送出去， 接著進入 Step 10。

( 1)

DTS MPDU d

Duration =Duration + Ant−Sn− × −t SIFS (14)

Step 10: Sender 接收到 ACK 封包，並經由公式(15)計算出資料封包的長度，並利用 Fragmentation 進行切割，然後利用公式(11)把值填入 DATA 封包的 Duration 欄位中， 然後把 DATA 封包傳送出去，接著回到 Step 7，反覆運算直到資料封包完全送出為止。

( ) MPDU ACK l =r Duration (15) 下面我們用實際的範例來說明 F-DMAC 在 Block 狀態傳送 CTS 封包的過程: 為了解決圖 3-3 的 deafness 與碰撞問題，我們利用通訊傳輸時間的長短來做為判 斷的依據。當新的通訊傳輸時間比目前正在進行中的通訊傳輸時間還長時，我們使用 DTS 來避免碰撞的發生，當新的通訊傳輸時間比目前正在進行中的通訊傳輸時間還 短時，代表不會影響現有正在進行中的通訊，因此不必做其他處理。如圗 3-9 所示， 當節點 C 收到節點 D 的 RTS 封包後，節點 C 會設定一個 NAV 來紀錄節點 D 的傳輸 時間。當節點 B 送 RTS 封包給節點 C 時，節點 C 會檢查 RTS 封包中的 Duration 是否 比之前設定的 NAV 大，在 Duration 小於 NAV 的情況下，代表節點 B 與節點 C 這一 個新的通訊，不會影響到節點 D 與節點 E 正在進行中的傳輸，所以節點 C 會傳送 oCTS 封包給節點 B，之後節點 B 便可以開始傳送資料給節點 C 了。 200m 200m 200m 200m 200m A B C D E F oRTS oRTS oCTS oCTS oRTS oRTS oCTS dACK dDATA dACK dDATA oRTS oRTS oCTS

相反的，如圖 3-10 所示，當 Duration 大於 NAV 的情況下，節點 D 與節點 E 的 這一個進行中的通訊會比節點 B 與節點 C 這一個新的通訊還要早完成。如圖 3-3 所 示，如果節點 D 還有資料要繼續傳送時，節點 D 會送出全方向性 RTS 封包，但此 時節點 B 與節點 C 的通訊尚未結束，因此會有碰撞發生。所以節點 C 在傳送 CTS 封包之前，會先計算允許節點 B 傳送資料的時間，並記錄在 CTS 封包中的 Frag_Duration 欄 位 ， 然 後 將 oCTS 封 包 傳 送 給 節 點 B 。 透 過 CTS 封 包 中 的 Frag_Duration，節點 B 使用 Fragmentation 的方式把原來的資料封包分為兩個較小的 Fragment 封包，並將傳送剩餘 DATA 需要的時間紀錄在 Fragment 的 Duration 欄位 中，再傳送給節點 C。當節點 C 接收到資料封包後，會回覆一個 dACK 封包給節點 B。此時節點 D 與節點 E 的通訊結束，節點 B 會算出需要淨空媒體的時間，然後把 它紀錄在 DTS 封包的 Duration 欄位中，再將 dDTS 封包傳送給節點 D。當節點 D 收 到 DTS 封包時，會依照 DTS 封包中的 Duration 時間設定一個 NAV，一直到節點 C 接收到另外一個 Fragment 並回覆 dACK 封包之後，節點 D 才會送出下一個 RTS 封 包，因此可以避免封包碰撞的情形。

圖 3-10F-DMAC Large Packet Case (Blocked CTS) 200m 200m 200m 200m 200m A B C D E F oRTS oRTS oCTS oCTS oRTS oRTS oCTS dACK dDATA dACK DATA Fragement dDTS oRTS oRTS DATA Fragement oCTS dACK

4.

第四章 PCF-DMAC

在 PCF-DMAC 中，我們利用控制傳輸功率的方式來減少方向性封包的傳輸距離， 讓傳送方向被 block 的 Receiver，還是可以回覆控制功率的方向性 CTS 封包給 Sender， 當 Sender 與 Receiver 的覆蓋範圍降低，自然就會提升空間使用率。不過，由於在傳送 方向被 block 時傳送 CTS 封包，基本上會發生碰撞情形，因此我們在 PCF-DMAC 中 增加了 DTS(Delay to Send)封包來避免這一個問題。在下面的章節我們會對 PCF-DMAC 協定做更詳細的說明。

4.1 問題定義

在 F-DMAC 中，如圗 4-1 所示，當節點 B 與節點 C 進行通訊時，節點 D 與節點 E 都會接收到節點 C 的 RTS 封包，然後將自己設為 block 的狀態。當節點 D 送出方 向性 RTS 給節點 E 時，節點 E 並不會回覆 CTS 封包給節點 D，因為節點 E 往節點 D 的方向被 block 了，所以會造成節點 D 會一直發送 RTS 封包的情形。因此 F-DMAC 在此情形下的空間使用率不高。

圖 4-1 F-DMAC Decrease Spatial Reuse Problem 如圖 4-2 所示，允許節點 E 傳送具有控制功率的方向性 CTS 封包，因為縮小傳 送距離的 pCTS 封包並不會與節點 B 送出的 pData 封包發生碰撞。但隨之而來的是， 節點 B 與節點 C 的通訊結束後，由於之前節點 E 的 pCTS 封包，節點 C 並沒有收到， 因此節點 C 不會設定 NAV。當節點 B 與節點 C 進行下一次通訊時，節點 C 會發出 全方向性 CTS 封包，由於節點 D 與節點 E 的通訊尚未結束，因此會在節點 E 發生 封包碰撞的情形。因此，雖然使用具功率控制的方向性 CTS 封包可以提升空間使用 率，卻也帶來了封包碰撞的問題。 100m 100m 100m 200m 200m A B C D E F oRTS oRTS oCTS oCTS dDATA dRTS dACK

圖 4-2 F-DMAC Power Control Directional CTS Problem

4.2 PCF-DMAC 介紹

我們提出的 PCF-MDAC 可以有效解決 4.1 提到空間使用率不高的問題。PCF-DMAC 在封包傳送時，可以使用全方向性、方向性以及控制功率加方向性三種方式來傳送， 並經由 Neighbor Information Table(NIT)來得知節點的位置以及 Power Level，因此節 點不需要配備 GPS，而修改後的 RTS、CTS 封包以及新增的 DTS 封包，則可以避免 Deafness 以及 Collision 的情形。下面章節我們會仔細說明封包傳送方式、NIT、控制 封包格式以及 Handshake Mechanism。 100m 100m 100m 200m 200m A B C D E F oRTS oRTS oCTS oCTS pDATA dRTS pACK _pCTS pDATA oRTS oRTS oCTS pDATA pACK oCTS collision

4.3 控制封包傳送方式

PCF-DMAC 在傳送 RTS、DATA、ACK 封包所採用的方式與 F-DMAC 相同，CTS 封 包傳送方式則有所不同，表 4-1 為 PCF-DMAC 在傳送各種封包時，所採用的傳送方 式。

表 4-1 PCF-DMAC 封包傳送方式 Packet Type Transmit Type

RTS dRTS, oRTS CTS oCTS, pCTS DATA pDATA

ACK pACK DTS dDTS D: Directional , o: Omni-directional, p: Power Control + Dir

4.4 Neighbor Information Table (NIT)

在 PCF-DMAC 中，傳送具有功率控制的方向性封包時，我們需要知道到對方的 方向以及最小傳送 Power。因此，我們採用 F-DMAC 的 NIT 來紀錄鄰居節點的位置， 並增加了一個欄位來紀錄鄰居節點的 Power Level，如表 4-2 所示。而 Power Level 的 計算方式，則是使用[10]所提出的公式(15)、(16)、(17)。

表 4-2 PCF-DMAC Neighbor Information Table Neighbor ID Received Beam Power Level

(

)

4

n r t t r

P

P

g g

d

λ

π

=

₍₁₅₎

min

(

)

4

n t r

P

P

g g

d

λ

π

=

(16) min

/

t r

P

=

PP

P

(17)

λ

Carrier wavelength

d

Distance between transmitter and receiver

n

Path loss coefficient

g

_t

/

g

_r Antenna gain of transmitter and receiver

P

t Transmit power

r

P

Receive power

P

minSmallest possible power level that nodes can receive

P

Adjusted transmit power

圖 4-3 方向性天線的傳送範例

如圖 4-3 所示，當一個節點接收到其他節點傳送的封包時，會將封包中的 Source ID、 接收的方向及經由(15)(16)(17)所計算之後的 Power Level 紀錄在 NIT 中，表 4-3 中說 明了節點 A、B、C、D 的 NIT 內容。

表 4-3 Records of PCF-DMAC NIT For node A

Neighbor ID Received Beam Power Level

B 3 0.2818 D 4 3 1 2 B 4 3 1 2 C 4 3 1 2 A 4 3 1 2

C 3 0.1214 D 2 0.0912

For node B

Neighbor ID Received Beam Power Level

A 1 0.2818 C 1 0.1124 D 1 0.2818

For node C

Neighbor ID Received Beam Power Level

A 1 0.1214 B 3 0.1124

For node D

Neighbor ID Received Beam Power Level

A 2 0.0912 B 3 0.2818

4.5 PCF-DMAC Handshake Mechanism

在 PCF-DMAC 這一個方法中節點傳送 RTS、DATA 與 ACK 封包的方式與 F-DMAC 相同。但是傳送 CTS 時則有所不同，在此方法裡 CTS 可以透過全方向性以 及控制功率的方向性等兩種方式來傳送，圖 4-4 為 PCF-DMAC 送出 CTS 封包的運作 流程。