1、802.11基本數據傳輸機制理解1. 802.11網絡基本概念1.1 802.11網絡元素Station (STA):具有802.11無線網卡的設備，包括手機、筆記本電腦等。Access Point (AP):實現無線網絡與固定網絡連接功能的設備，通常也稱作“熱點”，它主要完成STA與STA之間數據的轉發、STA與骨干網之間數據的轉發以及必要的管理工作。本文中將AP和STA通稱為Node（節點）。Wireless Medium (WM):STA之間以及STA與AP之間傳遞數據的通道，即無線鏈路。無線鏈路一詞相對直觀和容易理解，本文中的用無線鏈路只帶WM。Distribution System

2、(DS):8023.11中的一個邏輯概念，通常包括兩部分：骨干網以及AP的幀分發機制。這里的骨干網指的是連接各AP的固網，通常可以理解為以太網；AP的幀分發機制則完成骨干網與STA、以及STA與STA之間的數據幀轉發工作。1.2 802.11組網方式Independent Basic Service Set (IBSS) IBSS中只有STA和WM，沒有AP和DS IBSS內的通信只能發生在STA直接通信距離內 IBSS內STA間的通信都是點到點直接通信，沒有轉發圖1 IBSS網絡結構Infrastructure Basic Service Set (BSS) BSS內有STA、AP和WM，但

3、沒有DS BSS的范圍由AP的覆蓋范圍決定 BSS內的各STA的通信均由AP中轉，不能直接通信 BSS內STA在通信前必須先與AP進行關聯 (associate)，建立STA-AP的對應綁定關系 STA總是關聯的發起方，AP是響應方并決定是否允許STA的加入 一個STA同一時刻最多只能與一個AP進行關聯 AP的存在使得各STA可以以省電 (power-saving: PS) 模式工作圖2 BSS網絡結構Extended Service Set (ESS) 多個BSS串在一起組成一個ESS，同一ESS內的所有AP使用同一個SSID (Service Set Identifier) 一個ESS內的

4、各BSS由DS連接起來圖3 ESS網絡結構2. 802.11數據傳輸的基本問題及解決方案2.1 數據傳輸的可靠性將數據準確無誤地送達目的地是任何通信技術的基本要求。802.11中引入多種機制來保證數據傳輸的可靠性。2.1.1 ACK機制接收方成功接收到一個幀后，向發送方回復一個Ack幀進行確認。這里的成功接收意味著MAC幀已經收到且FCS校驗結果正確。圖4 引入ACK后的幀交互機制一般情況下有兩種幀要求Ack幀的確認：n 單播幀：單播幀的接收者必須向發送者回復Ack進行確認n ToDS域為1的多播/廣播幀：ToDS為1意味著這個報文需要由AP轉發到DS里去，AP向發送方確認報文已收到并會被轉到

5、DS里去。此時其他STA不回復。多播/廣播幀不要求、也不能要求收到該幀的每個節點都ACK回復，因為這樣既無必要，AP也無法處理。發送方收不到Ack幀的可能情況有：n 接收方未接收到幀，所以沒有回復Ackn 接收方收幀過程出錯，或是對幀的FCS校驗失敗，沒有回復Ackn 接收方成功收到幀，但發送方沒有成功收到Ack幀不管是那種情況，發送方都會認為發送失敗并啟動重傳。2.1.2 重傳機制802.11中提供一個門限值RTSThreshold，長于或等于該門限值的幀被認為是長幀，而短于該門限值的幀被認為是短幀。系統為每一個即將傳輸的幀（impending frame）都相應地配備有一個重發計數器（Re

6、try Counter），長幀則為LRC（Long RC），短幀則為SRC（Short RC）。每重傳一次，相應的RC就加1。系統中對幀的重傳次數是有限制的。如果重傳次數達到上限但傳輸依然沒有成功，該幀將被丟棄。此外系統對每一幀的有效時間也是有限制的，也就是說每一幀都應該在一定時間內被成功發出，否則該幀就失效了，系統會將其丟棄。綜上所述，幀的重傳不會無限制的重復下去，當發生下述情況之一時，重傳終止：n 得到了接收方的Ack，發送成功；n 重傳次數達到上限但仍未收到接收方的Ack，發送失敗，棄幀；n 當前幀已經過了有效時期但仍未收到接收方的Ack，發送失敗，棄幀。重傳意味著對幀的緩沖，意味著對系

7、統內存及其他資源的占用。而幀越長，對系統內存的占用就越多。因此按幀的的長短進行分類，降低長幀的重傳上限，有利于提高系統資源的利用效率。鑒于發送方沒收到Ack的可能原因，重傳有可能導致接收方收到重復幀，因此接收方需要相應的重復幀過濾機制。2.1.3 重復幀過濾機制802.11網絡中的每一個節點，包括STA和AP，都會根據所收到的幀來緩存并更新組合，對于每一個對端地址，只需要保存最近收到的幀的組合。收幀過程中，如果接收端發現當前幀是一個重傳幀（幀中的RetryBit為1），則根據當前幀的發送者地址找到緩存中對應的。如果當前幀的幀序號小于或等于組合中的幀序號，或者幀序號相同但是分片序號小于或等于組合

8、中的幀序號，接收方會將該幀認為是重復幀而將其丟棄。如果當前幀中的RetryBit為0，接收端將不會啟動重復幀過濾機制。對重復幀，接收方依然回復ACK幀，以免發送方不斷重傳。2.1.4 分片機制根據幀格式的定義，802.11幀中負載的最大長度為23424字節。對于更長的數據，則需要將其分片成多個幀組成分片序列來完成傳輸。802.11的分片序列中，除了最后一片，所有分片大小都應一樣，且應該是偶數個字節。整個分片序列共享一個幀序號，幀序號表示各分片在整個序列中的位置。除了最后一片外，所有分片中的MoreFrag域都應設為0以告知接收者還有后續分片。根據幀格式的定義，分片號由4比特的二進制序列表示，說

9、明一幀數據最多只能有16個分片。接收方先將所收到的分片緩存，收齊所有分片后按照分片號的先后順序重新組裝。如果未能收齊所有分片或者重組失敗，接收方將直接丟棄整個分片序列。在正常情況下，接收者應對每一個收到的分片立即回復ACK，收到ACK后發送方繼續發送下一個分片。如果某個分片沒有被ACK，發送方將對該分片啟動重傳機制。顯然，任何一個分片的發送失敗都會導致整個序列的發送失敗。對大的數據包進行分片處理，可以提高傳輸的可靠性。2.2 隱藏節點（hidden node）問題考慮下圖所示的情況：node1和node3都在node2的收發區域內，但node1不在node3的收發區域，因此對于node3相對于

10、node1而言是一個“隱藏節點”。同樣，node3也是node1的“隱藏節點”。如果不加任何約束的話，node1和node3很有可能同時向node2發送數據，而node2無法區分并成功接收，因而發生沖突。圖5 隱藏節點問題802.11中RTS/CTS機制可以很好的解決這個問題。2.2.1 RTS/CTS機制引入RTS/CTS機制后，節點之間的數據發送過程如下圖所示：圖6 引入RTS/CTS機制后的幀交互當Node1要向Node2發送數據時，先發送一個RTS (Request To Send) 幀，如果Node2可以接收，則回應一個CTS (CTS) 幀。收到CTS幀后，Node1就可以放心地將

11、數據幀發出并等候Node2的ACK。RTS幀一方面發出了一個對node2信道資源的預留請求，另一方面，收到該RTS幀的其他node將“沉默”，在RTS幀Duration域中所要求的時間內不發送數據，以確保node1能成功發送完數據并收到ACK幀。同樣地，CTS幀一方面響應了node1的預留請求，另一方面，收到該CTS幀的其他node (如Node3) 也將“沉默”，在CTS幀Duration域中要求的時間內不發數據，確保Node2能成功接收完數據幀并回復ACK。RTS/CTS幀大大降低了數據沖突發生地可能性，不過由于RTS/CTS交互增加了額外的數據交互量，對于一些小數據幀的交互來說，這部分額

12、外的數據量明顯降低了鏈路的有效利用率。因此802.11系統中提供了一個門限值RTSThreshold，大于該門限值的數據幀的交互才使用RTS/CTS機制。而且該門限值也是可以改變的，如果該門限值設為0，那么就意味著所有的數據幀交互都會采用RTS/CTS機制，而如果該門限值大于802.11幀的最大值，那么就意味著所有的數據幀交互都不采用RTS/CTS機制而是直接發送。RTS/CTS機制對于單幀的數據交互可以起到很好的保護作用，但何時可以發送RTS幀？當前幀發送完畢之后，其它節點又該如何發起下一次數據交互并且沒有數據沖突？簡單的RTS/CTS機制并不能解決這個問題。Hidden Node的問題其實

13、鏈路/信道復用問題的一種體現。我們需要一種全面的機制來實現對無線鏈路的互斥訪問和公平分配。802.11中該機制是通過協調函數（CF：Coordination Function）來實現的。802.11支持三種協調函數：DCF（Distributed CF）、PCF（Point CF）和HCF（Hybrid CF）。其中DCF是其他兩種協調函數的基礎，是802.11中最基本的無線鏈路管理和控制機制。3. DCFDCF采用CSMA/CA機制來監測無線鏈路的忙閑狀態，采用隨機退避時間（random backoff time）來完成對空閑鏈路的爭奪和分配。3.1 IFS（InterFrame Spaci

14、ng）802.11中的幀間距不僅僅是連續發送的各幀之間用于彼此區分的間隔，還是對不同類型數據幀提供不同服務優先級的重要組成部分，是DCF機制重要的一部分。802.11中定義了五種幀間距：SIFS(Short IFS)、PIFS（PCF IFS）、DIFS（Data IFS）、EIFS（Extended IFS）和AIFS（Arbitration IFS），其中PIFS和AIFS不在DCF中使用，此處先不討論。802.11中的IFS是以時間為單位來表示的，SIFS、DIFS和EIFS的具體值會因PHY層定義的不同而不同，但相對于具體一種PHY而言，它們的值都是固定的。SIFS時間最短，它只應用在

15、以下幾種數據幀之前：n ACK幀n 回復RTS的CTS幀n 一個分片序列中的各分片DIFS較SIFS更長，是節點開始競爭之前鏈路必須連續空閑的最短時間。在最近一次的數據包接收無誤的情況下，當節點檢測到介質的連續空閑時間達到DIFS時，才能啟動退避算法。如果最近一次的數據包接收發生了錯誤，節點只能在檢測到截止連續空閑時間達到EIFS后才能啟動退避算法。EIFS較DIFS要長。3.2 沖突檢測機制沖突檢測機制用于監測無線鏈路的忙閑狀況。理論上，沖突檢測機制既可以在物理層實現，也可以在MAC層實現。然而由于天線的半雙工特性，物理層沖突檢測機制實現難度大且成本高昂。因此一般都采用MAC層提供的虛擬沖突

16、機制（Virtual CS）。虛擬沖突機制引入NAV（Network Allocation Vector），并通過對NAV的更新與檢測來確認鏈路的忙閑狀況。NAV可以看作是一個時鐘，它記錄的其實是鏈路上當前的數據交互還要持續的時間。NAV不為0就意味著當前鏈路上有數據交互在發生。802.11的MAC幀頭中有一個2字節的Duration/ID域，絕大多數的幀（除了用于PCF中的PS-Poll幀外）都在該域中設置當前的數據交互的持續時間。收到MAC幀的各節點根據幀中的Duration域以一定規則更新本節點的NAV值，從而保證當前數據交互的順利完成。采用DCF的STA/AP在發送數據幀時，通常會采用

17、RTS/CTS來通知后續數據交互的發生。其他節點根據RTS/CTS幀中的Duration值來更新自己的NAV值。因此，NAV機制其實是通過“預訂”鏈路來保證當前數據交互不被干擾。3.2.1 NAV的更新在討論NAV的更新之前，我們有必要弄清楚一個問題：每個節點上應維護多少個NAV？是應該為網絡中其它每一個節點維護一個對應的NAV，還是只需要維護一個NAV？觀察下圖所示的情況：四個節點都處在各自的收發范圍內，且Node1和Node2正在進行數據通信，而Node3有數據要發往Node4。如果Node3為網絡中的其他每一個節點都維護一個對應的NAV，則此時NAV1和NAV2應該顯示鏈路忙，而NAV4

18、應該顯示鏈路空閑，因此給Node4的數據可以直接發送。圖7 每個節點維護一個NAV這種方式顯然不可行。無線傳輸本質上是廣播的，某個節點發出信號/數據可以被其接收范圍內的所有其他節點接收到。此時如果允許Node3發送數據，一方面Node3發出的數據對Node1和Node2之間的通信產生干擾（參見Hidden Node問題），另一方面Node1和Node2之間的數據交互對Node4的接收也產生干擾，最后的結果是大家都無法正常通信。因此每個節點上應該也只能維護一個NAV。這樣，當Node1和Node2在通信時，Node3和Node4上的NAV都顯示鏈路正忙，此時它們將所要發送的數據緩存，等到鏈路空閑

19、的時候再發送。這樣才能避免干擾和鏈路沖突。當收到一幀數據時，各節點需要根據的幀中的Duration值來更新其NAV，規則如下n 如果數據幀的發送者就是節點本身，則不更新NAV。n 如果數據幀的發送者不是節點本身，則比較Duration域值和當前NAV值。如果當前NAV值更小，則將NAV值更新為Duration域值n 如果該節點是根據RTS幀中的Duration域值來更新自己的NAV值，那么它會要求在一定的時間內收到相應的CTS幀或是RTS幀發送端發出的下一幀。否則，它會將自己的NAV值復位為0。當某節點收到目的地不是本節點的RTS幀時，它肯定在RTS幀的接收范圍之內，但它有可能在CTS發送端的

20、接收范圍之外。RTS幀承載著對鏈路的“預訂”請求，只有收到了對端的CTS幀，請求才算得到允許。而收到CTS幀后，RTS發送端會以最快的速度開始發送數據。所以收到RTS幀的其他節點會在一定的時間要么里收到CTS幀，要么收到后續數據幀，否則就有理由相信本次鏈路“預訂”失敗，因而將NAV值歸0。3.2.2 NAV更新舉例3.2.2.1 RTS/CTS/DATA/ACK交互過程中的NAV設置圖8 RTS/CTS/DATA/ACK交互中NAV的設置n Source端搶占到空閑鏈路，以一個RTS幀向Destination端發起通信請求并將幀中Duration域值設定為本次交互所需的時間。n 收到RTS后，

21、Destination端在SIFS后回復CTS幀確認可以接收數據。其它節點根據RTS幀中的Duration值將NAV更新為：NAV = 3*SIFS + aCTSTime + aDataTime + aAckTime這包括了本次數據交互還需要的時間。n Destination端收到RTS幀，在間隔SIFS后，回復一個CTS幀。n Source端收到CTS幀，在間隔SIFS后開始發送數據。其他節點根據CTS幀中的Duration值將NAV值更新為：NAV = 2*SIFS + aDataTime + aAckTimen Destination端成功收到數據，在SIFS后回送ACK。整個交互過程中

22、，其他節點上的NAV值設定顯示鏈路忙。n 不管Source端是否接收到ACK，本次數據交互到此結束。鏈路空閑DIFS后，各節點又開始對鏈路的競爭。這個過程中有可能出現CTS幀已經發出，但只有Source端沒有收到的情況，如下圖：圖9 CTS幀丟失此時其他節點依然按照CTS幀的要求更新了NAV，但Source端由于沒有收到CTS幀而不發送數據，這就造成了鏈路資源的浪費。這是最壞的情況。此時Source端在等待一定時間后可能會比其他節點更早啟對對鏈路的競爭。3.2.2.2 分片序列發送過程中的NAV設置圖10分片序列發送過程中NAV的設置這和單一幀的發送的區別在于，每一個分片中的Duration域

23、都指明了下一個分片的傳輸所需的時間，且后續分片在上一個ACK后的SIFS后立即發送，如果每一分片都發送無誤，這個過程一直會持續到所有分片發送完畢。這個過程中也有可能發生某分片的ACK沒有被Source端收到的情況，如下圖所示：圖11 分片的ACK幀丟失此時其它節點中的NAV因分片/ACK中的Duration值更新而顯示鏈路忙。Source端在等待ACK超時后，有可能搶先啟動對空閑鏈路的競爭。3.3 退避算法802.11采用退避算法解決空閑鏈路在各節點之間的分配問題。當鏈路空閑時間超過DIFS/EIFS之后，各節點并不馬上發起數據傳輸，而是啟動一個退避（backoff）時鐘，進入競爭窗口（Con

24、tention Window）。在backoff時鐘超時之前，節點不進行任何的數據發送，同時監測鏈路的忙閑狀況。當下列情況之一發生時，競爭窗口關閉：n backoff時鐘超時n backoff時鐘未超時，但檢測到鏈路忙（即檢測到鏈路上開始了數據交互，比如收到RTS幀或是不采用RTS/CTS機制而直接開始發送的數據幀）。如果backoff時鐘未超時之前檢測到鏈路忙，此時節點會暫停backoff時鐘的運行（也稱作backoff時鐘的掛起），設置自己的NAV值并啟動NAV時鐘，此時節點進入延時等待（defer）階段。在defer期內，系統會根據3.2.1中的規則對NAV值進行的更新。當NAV超時時，

25、系統認為鏈路空閑。當鏈路連續空閑時間達到DIFS/EIFS時，系統重新繼續（resume）backoff時鐘的運行并同時監測鏈路的忙閑狀況。backoff時鐘超時意味著當前節點獲得了鏈路的控制權，此時它可以立即開始數據的傳輸（對長幀要采用RTS/CTS機制，短幀則直接發送）。而其他節點會根據該節點發送的幀暫停自己backoff時鐘的運行并對NAV值進行相應地設置和更新。很顯然，各節點上的backoff時長必須不同，它是下述方式產生的一個隨機值：BackoffTime = Random() * aSlotTime其中，aSlotTime是802.11物理層定義的一個常量，不同的物理層中該常量的具

26、體定值不一樣。Random()則是在0, CW之間產生的一個隨機的整數。3.3.1 CW的取值CW在CWmin, CWmax區域內按照一定規律變化。CWmin和CWmax是802.11系統中定義的兩個常量，分別表示CW值得下限和上限。CW的值總是2的N次方減1，N的值與節點中幀的重傳次數有關系。在2.1.2 重傳機制一節中我們提到系統為每一個即將傳輸的幀（impending frame）都相應地配備有一個重發計數器（Retry Counter），長幀則為LRC（Long RC），短幀則為SRC（Short RC）。除此之外，系統還維護著兩個獨立的重傳計數器，分別是SSRC（STA Short

27、Retry Counter）和SLRC（STA Long Retry Counter），它們分別記錄著系統中當前短幀和長幀總的連續重傳次數。SSRC和SRC的區別在于，后者對應于某一短幀，而前者對應于系統中所有短幀。SSRC和SRC有可能是一樣的，也有可能是不一樣的。每一次短幀的重傳都會引起SRC和SSRC的遞增。當SRC的值達到上限時，其對應的幀被丟棄，該SRC也將丟棄。此時系統啟動下一幀的發送，同時啟動新的SRC并將SRC的值置為0，而SSRC的值則不會清0，而且會伴隨著新幀的重傳而繼續遞增。當以下情況之一發生時，SSRC會被清0：n 收到以本節點為目的地址的CTS幀n 收到對短幀進行確認

28、的ACK幀n 發送組播/廣播報文成功SLRC和LRC之間也有著類似的區別和聯系。當一下情況之一發生時，SLRC會被清0：n 收到以本節點為目的地址的CTS幀n 收到對短幀進行確認的ACK幀n 發送組播/廣播報文成功不難看出，只有發幀成功時SSRC和SLRC才會被清0，也就是說SSRC/SLRC分別記錄著截至目前短幀和長幀的連續重發次數。下圖給出了CW的取值和SSRC/SLRC之間的關系：圖12 CW值隨重傳次數增長而增長n 初始時，CW=CWminn 每一次數據重傳，SSRC/SLRC加1，CW的值上一個“臺階”，即N=N+1n 當達到CWmax之后，CW的值不再隨重傳次數的增加而增加n 當下

29、述情況之一發生時，CW值被復位為CWmin： 幀發送成功 SSRC/SLRC達到上限從CW的取值規則我們不難發現：n 鏈路狀態越差，幀重傳的幾率越大，CW的值就可能越大，因此backoff時間值就有可能越長，節點對鏈路的競爭能力就越差。n 重傳幀發送的優先級較低，因為其backoff時鐘可能更長3.3.2 backoff時鐘的掛起前已述及，如果在backoff時鐘超時前鏈路已被其他節點占用，那么競爭窗口關閉，NAV值被設置，backoff時鐘暫停運行（即被掛起）。下一次競爭窗口開啟時，backoff時鐘繼續運行，如此周而復始直至backoff時鐘超時。下圖舉例說明了這種場景：圖13 backo

30、ff時鐘的掛起3.4 DCF總結采用DCF機制的節點有數據要發送時，首先要根據NAV的值判斷當前鏈路的忙閑狀態。如果鏈路忙，當前的發送操作被掛起，系統進入DEFER期。當鏈路連續空閑時間達到DIFS/EIFS后，節點啟動backoff時鐘進入對鏈路的爭奪。backoff時鐘超時就意味著鏈路控制權的獲得，此時該節點就可以開始數據發送。所有幀都只能在鏈路空閑的時候（NAV為0）發送，但ACK幀例外。當某個節點收到一個幀并被要求要立即回復時，不管鏈路是否空閑，它都會在SIFS之后立即回復ACK。因為不及時回復ACK會導致幀的重傳，對系統和整個網絡資源造成消耗，而回復ACK雖然可能對其他數據交互造成影

31、響，但在DCF機制下，這種影響相對要小很多。3.4.1 NAV和Backoff二者都可以被看成是時間計數器（或簡單稱之為時鐘），不過NAV的值可能隨著鏈路上的數據傳輸狀況而改變，而backoff的值則在backoff時鐘重啟的時候確定，在下次超時之前不會更改。3.4.2 幀交互的“元操作”性元操作在匯編中是一個常見的概念，它表示著一個不能被打斷的操作，也就是該操作要么不執行，要么就執行完畢，其結果只有執行成功和失敗，不存在中間狀態。802.11中通過NAV機制和IFS機制的設定，盡量保證一次幀交互的元操作性。在3.2.2.1中所示的單幀交互過程中，一方面通過RTS/CTS交互使得所有可能干擾本

32、次幀交互的節點“噤聲”，另一方面由于其他節點都必須在鏈路連續空閑至少DIFS后才啟動鏈路競爭，而CTS、Data和ACK都以SIFS做間隔，保證交互過程中雙方一定能“爭”到鏈路。因此保證了幀交互的元操作性。同樣，在3.2.2.2中所示的分片序列發送過程中，一方面RTS/CTS幀以及每個分片中的Duration域值對其他節點NAV的設置使得所有可能干擾本次發送的節點“噤聲”，另一方面此過程中的CTS、ACK以及個分片都以SIFS做間隔，保證交互過程中雙方一定能“爭”到鏈路。所以每片的發送都是“元操作”，而且如果所有分片都成功傳輸，整個分片序列的交互也具有元操作性。3.4.3 DCF的不足DCF大

33、大降低了HiddenNode問題和鏈路沖突問題的發生幾率，但并不能徹底解決。由于backoff時鐘的時長是隨機產生的，理論上講有可能兩個節點產生的backoff值一樣，從而在二者的backoff時鐘在同一時刻超時，因而發生鏈路沖突。再看下圖所示場景：Node3處于兩個BSS的交界處，此時AP1正在與Node1通信，而AP2正在與Node2通信，這種場景并不違反DCF機制，但此時在Node2處卻確實發生了HiddenNode的問題。圖14 BSS交界處的干擾盡管如此，DCF機制還是提供了一個很好的鏈路管理和分配機制，是802.11最基本的協調函數，所有STA/AP都必須支持。PCF和HCF都是基

34、于DCF機制的。4. PCFDCF機制解決了鏈路的沖突，提供了鏈路的競爭規則，但是網絡中的每個節點，包括STA和AP，都是鏈路爭奪的個體。DCF提供的是基于競爭的鏈路共享機制（Contention-Based Service），因為每次幀交互之前都必須爭奪鏈路，這在一定程度上降低了鏈路的利用率。802.11中提供了另外一種無競爭（Contention-Free）的鏈路共享機制，稱為PCF（Point Coordination Function）。PCF 的原理是，首先由AP遵照DCF的原則，網絡中所有STA的NAV值設定成同一個數值，從而開辟一段無競爭時段（CFP：Contention-Fre

35、e Period）。在CFP中，鏈路完全由AP控制，由AP來控制某個時段哪個STA可以發數據。顯然，IBSS網絡中不能提供PCF服務。PCF中，AP也被稱為PC（Point Coordinator）。4.1 CFP的開啟、維持和結束4.1.1 Beacon幀Beacon幀是802.11中最常見最重要的管理幀之一，它以固定的間隔（Beacon Interval）發送，向網絡中傳遞管理信息。Beacon幀中的具體內容與使用的場合有關，其中與PCF機制相關的主要信息有：CF參數集（CF Parameters Set）。4.1.1.1 CF參數集信息圖15 CF參數集格式CFP Count：表示距離開

36、啟下一次CFP還有多少個DTIM間隔，0值則表示CFP由當前Beacon幀開始。DTIM是Beacon幀中可能的內容之一，它以固定的間隔（DTIM Interval）出現在Beacon幀中。顯然，DTIM_Interval = n * Beacon_Interval。CFP Period：表示相鄰兩次CFP的開啟時間的間隔，以DTIM_Interval為單位。CFP MaxDuration：表示系統允許的一個CFP的最大時間，以1024us為單位。CFP DurRemaining：表示從最近一次TBTT（Target Beacon Transmission Time）開始到本次CFP結束之間的

37、時間，以1024us為單位。TBTT表示Beacon幀按計劃應該出現的時間。由于Beacon幀的發送間隔是固定的，因而TBTT應該也是固定的。在一個時間同步的網絡中，所有節點的TBTT都應該是一致的。Beacon幀對網絡的同步起著至關重要的作用。然而由于要遵守DCF規定的鏈路訪問規則，而另一方面每幀的長度是不固定的，實際應用中無法保證Beacon幀在每一個TBTT時間都能準時發送。引入一個TBTT量，使得即便未能按時收到Beacon幀，必要的處理也能得以進行，而需要以Beacon幀作參照的各種同步依然也能完成。4.1.1.2 TIM圖16 TIM信息格式DTIM Count：表示在下一個DTI

38、M出現之前還有多少個Beacon幀。DTIM Period：表示DTIM Interval的值，以Beacon Interval為單位Bitmap Control和Partial Virtual Bitmap：這兩個域和PCF機制關系不大，暫不介紹。4.1.2 CF-Pollable STAPC通過CF-Poll幀來告訴網絡中哪個STA可以發數據，只有收到CF-Poll幀的STA才能發送數據。STA可以選擇響應CF-Poll，表示加入PCF機制，也可以選擇不響應。響應CF-Poll的STA也被稱為CF-Pollable STA。STA通常會事先將自己的CF-Pollability告知PC。ST

39、A加入BSS過程中有一個稱為“連接（Association）”的步驟（STA加入BSS的過程會在討論802.11網絡管理及系統管理的相關章節中詳細描述）。連接是STA加入BSS過程中的最后一步，用于在STA與該BSS的AP之間建立一種對應關系，使得在DS中進行中轉的以該STA為目的地址的幀可以準確地找到相關的AP進行轉發。連接由STA發起（Association Request），而AP處理成功后向STA發送確認。連接建立成功后，每個STA都有一個唯一的AID（AssociationID）。Association Request信息中有一個CapabilityInfo部分，其中有一個1比特的C

40、F-Pollable域，表明該STA是否是CF-Pollable的。4.1.3 CFP的開啟和維持當需要開啟一個CFP時，AP在鏈路連續空閑達到PIFS后發出一個帶有CF參數集信息和DTIM信息的Beacon幀。PIFS是專用于PCF機制中的一個幀間距類型，它長于SIFS，但小于DIFS，三者的關系式：aPIFS = aSIFS + aSlotTime；aDIFS = aSIFS + 2*aSlotTimeSTA收到該Beacon幀后，根據CFP Count域值發現PC要開啟一個CFP，就將自己的NAV值設為CFP MaxDuration，不管該STA是否是CF-Pollable。此時鏈路開始

41、完全處于PC的控制中。在4.1.1.1中討論CF參數集信息時，我們已經說過Beacon幀不能按時發送的可能性。當負責開啟一個CFP的Beacon幀不能按時發送時，就會造成該CFP延后開始，這種情況稱為foreshortened CFP，如下圖所示。Foreshortened CFP的結束時間不會相應延后。圖17 CFP的開始圖18 Foreshortened CFP在CFP內，PC依然會以DTIM Interval為間隔按時發送帶有DTIM和CF參數集的Beacon幀，其中CFP DurRemaining表示出了本次CFP還將持續的時間。此時各STA會根據CFP DurRemaining來重新設置自己的NAV值。4.1.4 CFP的結束每一個CFP都有它的最大持續時間，這在Beacon幀中的CFP MaxDuration中已經標明。當時間耗盡時，CFP將自動結束。此時各STA上的NAV逐漸遞減至0，重新進入競爭時間。還有一種情況，就