在 IEEE 802.11[1]中提供了兩個基本的 MAC 層機制:分散式協調功能(Distributed Coordination Function，DCF)以及集中式協調功能(Point Coordination Function，PCF)。所
Sequence Number Segment Number Bits 12 4
圖 2-4 Sequence Control 欄位
謂的「協調式功能」(Coordination Function) 是指一個可以協調並且分配多個使用者之間 的通道存取權利的機制。IEEE 802.11 則以分散式協調功能當作最基本的通道存取方法，
分散式協調功能採用了載波感測多重存取及衝撞避免 的技術 (carrier-sense multiple access/collision avoidance, CSMA/CA)做為基礎。然而集中式協調功能則是利用無線 AP 做中央控制，以輪詢的方式安排區域內使用者傳送訊框的時間以及順序，皆由 AP 來進 行排程，不需要進行通道競爭的過程。然而在無線區域網路中，所有的工作站都必頇具 備分散式協調功能，而集中式協調功能則是一個可選擇支援與否的選項。本篇論文中以 分散式協調功能為基準做延伸，集中式協調功能則不在討論範疇當中。
分散式協調採用 CSMA/CA 的技術，它可以支援多個站點同時使用一個通道，並且 避免使用隨機倒退的方式來減少訊息碰撞的問題。每個站點要傳送資料之前會在實體層 對當前通道的無線電波區段做偵測，來判定目前通道是否正在被使用，假如通道空閒，
則可以進入下一個傳送程序，相反的，當偵測到通道狀態為忙碌時，就必頇等到下次通 道空閒時才能進行傳送程序，然而假如在有兩個以上的站點同時進行資料的傳送，就會 產生訊框碰撞的情形。
而 MAC 層會另外採用虛擬載波偵測技術(Virtual Carrier Sensing)，來輔助實際通道 的偵測，在資料發送出去時，在訊框標頭檔的 Duration/Id 欄位會紀錄站點傳輸所需要使 用的時間，在無線網路傳輸範圍中的其他站點，在接收到訊框傳送目的位址不為自己的 時，就會依照 Duration 欄位值的大小，來改變相對應的網路配置向量(Network Allocation Vector)，利用網路配置向量(NAV)來記錄目前通道還需要多少的時間才會重新回到空閒 的狀態，在時間尚未歸零之前，該使用者都會將通道視為忙碌狀態，不需要再另做通道 狀態的偵測。
IEEE 802.11 規定在傳送訊框前必頇額外等待一段間隔時間，依據傳送訊框的類型，
決定訊框間隔(Inter Frame Space)的長短，以區分訊框間不同類型的優先權，使用越短的 訊框間隔，會確保有絕對優先的通道使用權，訊框間隔分類如下:
1.短訊框間隔(SIFS)--使用在立即需回應的動作的控制訊框(Control Frame)如 ACK，
RTS/CTS 等等。
2.集中式訊框間隔(PIFS)--在集中式協調當中使用，長度略大於短訊框間隔。
3.分散式訊框間隔(DIFS)--分散式協調當中使用，工作站要傳送資料訊框(Data Frame)之 前必頇先等待通道閒置一個分散式訊框間隔後，才可以進入傳送程序。
4.延長訊框間隔(EIFS)—用於工作站進行資料重送時，訊框必頇等待的時間。
使用不同訊框間隔的機制可以保障在通道閒置時，擁有需要立即回應需要的訊框，
分散式協調功能為 Contention Window Size，CW 值定義了最大值 CWmax 和最小值 CWmin，在最初的傳送過程當中，CW 值為預設最小的 Window Size 值 CWmin，假設 在隨機倒退過程中資料傳送產生碰撞，站點必頇加倍 CW 值，加倍公式如(1)，然而假如 碰撞的情形持續產生，CW 的值就會持續加倍，直到 CW 值到達原本設定的最大值 CWmax 即不會再增加，直到當個訊框傳送成功之後才能再將 CW 值回復成預設值 CWmin，這個演算法稱為隨機二位元倒退機制。
CW now = CW Min ∗ 2N− 1 N 為第幾次重傳 (1)
然而，上述的重傳次數 N 並非沒有限制，在考慮到有限的頻寬分配狀況下，IEEE 802.11 定義了訊框重新傳送機制，他將重傳機制以次數差異分成了長重傳上限機制(Long Retry Limits)與短重傳上限機制(Short Retry Limits)兩種，而兩者間的判定方式是當要傳 送訊框的長度大於 RTS 門檻值時，工作站就會選擇使用長重傳上限機制，反之，則使用 短重傳上限機制；重傳機制是依據訊框的大小來做為重傳重要性高低的判定。
2.2.1 RTS/CTS 握手機制
在無線網路中，除了資料碰撞不易偵測之外，實體層在使用載波偵測技術時也容易 誤判傳輸媒介是否忙碌。IEEE 802.11 解決前者的方法如下：在傳送端要傳送訊框前，
先送出一個「要求傳送」控制訊框(RTS-Request to Send)，而接收端在收到這個控制訊框 時則在經過一個 SIFS 訊框間隔後立刻回送「允許傳送」控制訊框(CTS-Clear to Send)。
只有當傳送端正確的收到接收端所回覆的 CTS 時，傳送端才能送出訊框。同時其他工 作站看到這個送給傳送端的 CTS 之後，也就立刻暫時停止嘗試傳送訊框的程序，因此 傳送端傳送的訊框與其他工作站訊框發生衝撞的可能性就會大大的降低，傳送機制如圖 2-6。這是因為 RTS 訊框標頭檔訊框控制欄位當中 Duration 參數當中，記錄了接下來的 傳送所需要的持續時間值是預估其自己站點在傳送完畢至接收端站點回傳的 ACK 封包 被接收到為止，所有聽到此 RTS 訊框的工作站必需將其 NAV 設為此值。而接收端回 送的 CTS 訊框中也會再標頭檔當中標記 Duration 值，其內容等於其本身傳送完畢至下 一筆傳送訊框收到回覆訊框為止的預估時間。然而如同上述介紹的，其他站點收到這個 Duration 值之後會更新自己的 NAV 值，當其 NAV 非零時，此工作站不能以 DCF 的方 式開始競爭，也不能進行訊框傳送。
然而 RTS/CTS 機制並不是一個必選的選項，由於使用 RTS/CTS 的使用勢必會帶來一