WIFI基本數(shù)據(jù)傳輸機制理解

1、802.11根本數(shù)據(jù)傳輸機制理解1.802.11網(wǎng)絡根本概念1.1802.11網(wǎng)絡元素Station(STA):具有802.11無線網(wǎng)卡的設備，包括手機、筆記本電腦等。AccessPoint(AP):實現(xiàn)無線網(wǎng)絡與固定網(wǎng)絡連接功能的設備，通常也稱作“熱點，它主要完成STA與STA之間數(shù)據(jù)的轉(zhuǎn)發(fā)、STA與骨干網(wǎng)之間數(shù)據(jù)的轉(zhuǎn)發(fā)以及必要的管理工作。本文中將AP和STA通稱為Node節(jié)點。WirelessMedium(WM):STA之間以及STA與AP之間傳遞數(shù)據(jù)的通道，即無線鏈路。無線鏈路一詞相對直觀和容易理解，本文中的用無線鏈路只帶WM。DistributionSystem(DS):8023.11

2、中的一個邏輯概念，通常包括兩局部：骨干網(wǎng)以及AP的幀分發(fā)機制。這里的骨干網(wǎng)指的是連接各AP的固網(wǎng)，通?？梢岳斫鉃橐蕴W(wǎng)；AP的幀分發(fā)機制那么完成骨干網(wǎng)與STA、以及STA與STA之間的數(shù)據(jù)幀轉(zhuǎn)發(fā)工作。1.2802.11a網(wǎng)方式IndependentBasicServiceSet(IBSS)一IBSS中只有STA和WM,沒有AP和DS一舊SS內(nèi)的通信只能發(fā)生在STA直接通信距離內(nèi)一舊SS內(nèi)STA間的通信都是點到點直接通信，沒有轉(zhuǎn)發(fā)ind玨endentBSS圖1IBSS網(wǎng)絡構(gòu)造InfrastructureBasicServiceSet(BSS)BSS內(nèi)有STA、AP和WM,但沒有DS一BSS的X圍

3、由AP的覆蓋X圍決定一BSS內(nèi)的各STA的通信均由AP中轉(zhuǎn)，不能直接通信一BSS內(nèi)STA在通信前必'須先與AP進展關(guān)聯(lián)(associate)建立STA-AP的對應綁定關(guān)系STA總是關(guān)聯(lián)的發(fā)起方，AP是響應方并決定是否允許STA的參加一一個STA同一時刻最多只能與一個AP進展關(guān)聯(lián)一AP的存在使得各STA可以以省電(power-saving:PS)模式工作圖2 BSS網(wǎng)絡構(gòu)造ExtendedServiceSet(ESS)一多個BSS串在一起組成一個ESS,同一ESS內(nèi)的所有AP使用同一個SSID(ServiceSetIdentifier)一一個ESS內(nèi)的各BSS由DS連接起來圖3ESS網(wǎng)絡

4、構(gòu)造2. 802.11數(shù)據(jù)傳輸?shù)母締栴}及解決方案2.1 數(shù)據(jù)傳輸?shù)目煽啃詫?shù)據(jù)準確無誤地送達目的地是任何通信技術(shù)的根本要求。802.11中引入多種機制來保證數(shù)據(jù)傳輸?shù)目煽啃浴?.1.1 ACK機制接收方成功接收到一個幀后，向發(fā)送方回復一個Ack幀進展確認。這里的成功接收意味著MAC幀已經(jīng)收到且FCS校驗結(jié)果正確。圖4引入ACK后的幀交互機制一般情況下有兩種幀要求Ack幀確實認：單播幀：單播幀的接收者必須向發(fā)送者回復Ack進展確認ToDS域為1的多播/播送幀：ToDS為1意味著這個報文需要由AP轉(zhuǎn)發(fā)到DS里去，AP向發(fā)送方確認報文已收到并會被轉(zhuǎn)到DS里去。此時其他STA不回復。多播/播送幀不要

5、求、也不能要求收到該幀的每個節(jié)點都ACK回復，因為這樣既無必要，AP也無法處理。發(fā)送方收不到Ack幀的可能情況有：接收方未接收到幀，所以沒有回復Ack接收方收幀過程出錯，或是對幀的FCS校驗失敗，沒有回復Ack接收方成功收到幀，但發(fā)送方?jīng)]有成功收到Ack幀不管是那種情況，發(fā)送方都會認為發(fā)送失敗并啟動重傳。2.1.2 重傳機制802.11中提供一個門限值RTSThreshold,長于或等于該門限值的幀被認為是長幀，而短于該門限值的幀被認為是短幀。系統(tǒng)為每一個即將傳輸?shù)膸琲mpendingframe都相應地配備有一個重發(fā)計數(shù)器RetryCounter,長幀那么為LRCLongRC，短幀那么為SRC

6、ShortRC。每重傳一次，相應的RC就加1。系統(tǒng)中對幀的重傳次數(shù)是有限制的。如果重傳次數(shù)到達上限但傳輸依然沒有成功，該幀將被丟棄。此外系統(tǒng)對每一幀的有效時間也是有限制的，也就是說每一幀都應該在一定時間內(nèi)被成功發(fā)出，否那么該幀就失效了，系統(tǒng)會將其丟棄。綜上所述，幀的重傳不會無限制的重復下去，當發(fā)生下述情況之一時，重傳終止：得到了接收方的Ack,發(fā)送成功；重傳次數(shù)到達上限但仍未收到接收方的Ack,發(fā)送失敗，棄幀；當前幀已經(jīng)過了有效時期但仍未收到接收方的Ack,發(fā)送失敗，棄幀。重傳意味著對幀的緩沖，意味著對系統(tǒng)內(nèi)存及其他資源的占用。而幀越長，對系統(tǒng)內(nèi)存的占用就越多。因此按幀的的長短進展分類，降低長

7、幀的重傳上限，有利于提高系統(tǒng)資源的利用效率。鑒于發(fā)送方?jīng)]收到Ack的可能原因，重傳有可能導致接收方收到重復幀，因此接收方需要相應的重復幀過濾機制。2.1.3重復幀過濾機制802.11網(wǎng)絡中的每一個節(jié)點，包括STA和AP,都會根據(jù)所收到的幀來緩存并更新<對端地址，幀序號，分片序號>組合，對于每一個對端地址，只需要保存最近收到的幀的<地址，幀序號，分片序號>組合。收幀過程中，如果接收端發(fā)現(xiàn)當前幀是一個重傳幀幀中的RetryBit為1，那么根據(jù)當前幀的發(fā)送者地址找到緩存中對應的<對段地址，幀序號，分片序號>。如果當前幀的幀序號小于或等于組合中的幀序號，或者幀序號一

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

9、由4比特的二進制序列表示，說明一幀數(shù)據(jù)最多只能有16個分片。接收方先將所收到的分片緩存，收齊所有分片后按照分片號的先后順序重新組裝。如果未能收齊所有分片或者重組失敗，接收方將直接丟棄整個分片序列。在正常情況下，接收者應對每一個收到的分片立即回復ACK，收到ACK后發(fā)送方繼續(xù)發(fā)送下一個分片。如果某個分片沒有被ACK，發(fā)送方將對該分片啟動重傳機制。顯然，任何一個分片的發(fā)送失敗都會導致整個序列的發(fā)送失敗。對大的數(shù)據(jù)包進展分片處理，可以提高傳輸?shù)目煽啃浴?.2隱藏節(jié)點hiddennodd問題考慮以下圖所示的情況：node1和node3都在node2的收發(fā)區(qū)域內(nèi)，但node1不在node3的收發(fā)區(qū)域，因

10、此對于node3相對于nodel而言是一個"隱藏節(jié)點"。同樣，node3也是nodel的“隱藏節(jié)點。如果不加任何約束的話，node1和node3很有可能同時向node2發(fā)送數(shù)據(jù)，而node2無法區(qū)分并成功接收，因而發(fā)生沖突。Area reachabfe by node 1Area fwfroWe by 3JUi -J q圖5隱藏節(jié)點問題802.11中RTS/CTS機制可以很好的解決這個問題。2.2.1RTS/CTS機制引入RTS/CTS機制后，節(jié)點之間的數(shù)據(jù)發(fā)送過程如以下圖所示:圖6引入RTS/CTS機制后的幀交互當Nodel要向Node2發(fā)送數(shù)據(jù)時，先發(fā)送一個RTS(Re

11、questToSend)幀，如果Node2可以接收，那么回應一個CTS(CTS)幀。收到CTS幀后，Node1就可以放心地將數(shù)據(jù)幀發(fā)出并等候Node2的ACK。ACK 。RTS幀一方面發(fā)出了一個對node2信道資源的預留請求，另一方面，收到該RTS幀的其他node將"沉默"，在RTS幀Duration域中所要求的時間內(nèi)不發(fā)送數(shù)據(jù)，以確保node1能成功發(fā)送完數(shù)據(jù)并收到ACK幀。同樣地，CTS幀一方面響應了node1的預留請求，另一方面，收到該CTS幀的其他node(如Node3)也將“沉默”，在CTS幀Duration域中要求的時間內(nèi)不發(fā)數(shù)據(jù)，確保Node2能成功接收完數(shù)據(jù)

12、幀并回復RTS/CTS幀大大降低了數(shù)據(jù)沖突發(fā)生地可能性，不過由于RTS/CTS交互增加了額外的數(shù)據(jù)交互量，對于一些小數(shù)據(jù)幀的交互來說，這局部額外的數(shù)據(jù)量明顯降低了鏈路的有效利用率。因此802.11系統(tǒng)中提供了一個門限值RTSThreshold,大于該門限值的數(shù)據(jù)幀的交互才使用RTS/CTS機制。而且該門限值也是可以改變的，如果該門限值設為0，那么就意味著所有的數(shù)據(jù)幀交互都會采用RTS/CTS機制，而如果該門限值大于802.11幀的最大值，那么就意味著所有的數(shù)據(jù)幀交互都不采用RTS/CTS機制而是直接發(fā)送。RTS/CTS機制對于單幀的數(shù)據(jù)交互可以起到很好的保護作用，但何時可以發(fā)送RTS幀？當前幀

13、發(fā)送完畢之后，其它節(jié)點又該如何發(fā)起下一次數(shù)據(jù)交互并且沒有數(shù)據(jù)沖突？簡單的RTS/CTS機制并不能解決這個問題。HiddenNode的問題其實鏈路/信道復用問題的一種表達。我們需要一種全面的機制來實現(xiàn)對無線鏈路的互斥訪問和公平分配。802.11中該機制是通過協(xié)調(diào)函數(shù)CF：CoordinationFunction來實現(xiàn)的。802.11支持三種協(xié)調(diào)函數(shù)：DCFDistributedCF、PCFPointCF和HCFHybridCF。其中DCF是其他兩種協(xié)調(diào)函數(shù)的根底，是802.11中最根本的無線鏈路管理和控制機制。3. DCFDCF采用CSMA/CA機制來監(jiān)測無線鏈路的忙閑狀態(tài)，采用隨機退避時間ra

14、ndombackofftime來完成對空閑鏈路的爭奪和分配。3.1 IFSInterFrameSpacing802.11中的幀間距不僅僅是連續(xù)發(fā)送的各幀之間用于彼此區(qū)分的間隔，還是對不同類型數(shù)據(jù)幀提供不同效勞優(yōu)先級的重要組成局部，是DCF機制重要的一局部。802.11中定義了五種幀間距：SIFS(ShortIFS)、PIFSPCFIFS、DIFSDataIFS、EIFSExtendedIFS和AIFSArbitrationIFS，其中PIFS和AIFS不在DCF中使用，此處先不討論。802.11 中的IFS是以時間為單位來表示的，SIFS、DIFS和EIFS的具體值會因PHY層定義的不同而不同

15、，但相對于具體一種PHY而言，它們的值都是固定的。SIFS時間最短，它只應用在以下幾種數(shù)據(jù)幀之前：ACK幀回復RTS的CTS幀一個分片序列中的各分片DIFS較SIFS更長，是節(jié)點開場競爭之前鏈路必須連續(xù)空閑的最短時間。在最近一次的數(shù)據(jù)包接收無誤的情況下，當節(jié)點檢測到介質(zhì)的連續(xù)空閑時間到達DIFS時，才能啟動退避算法。如果最近一次的數(shù)據(jù)包接收發(fā)生了錯誤，節(jié)點只能在檢測到截止連續(xù)空閑時間到達EIFS后才能啟動退避算法。EIFS較DIFS要長。802.12 沖突檢測機制沖突檢測機制用于監(jiān)測無線鏈路的忙閑狀況。理論上，沖突檢測機制既可以在物理層實現(xiàn)，也可以在MAC層實現(xiàn)。然而由于天線的半雙工特性，物理

16、層沖突檢測機制實現(xiàn)難度大且本錢高昂。因此一般都采用MAC層提供的虛擬沖突機制VirtualCS。虛擬沖突機制引入NAVNetworkAllocationVector，并通過對NAV的更新與檢測來確認鏈路的忙閑狀況。NAV可以看作是一個時鐘，它記錄的其實是鏈路上當前的數(shù)據(jù)交互還要持續(xù)的時間。NAV不為0就意味著當前鏈路上有數(shù)據(jù)交互在發(fā)生。802.11的MAC幀頭中有一個2字節(jié)的Duration/ID域，絕大多數(shù)的幀除了用于PCF中的PS-Poll幀外都在該域中設置當前的數(shù)據(jù)交互的持續(xù)時間。收到MAC幀的各節(jié)點根據(jù)幀中的Duration域以一定規(guī)那么更新本節(jié)點的NAV值，從而保證當前數(shù)據(jù)交互的順利

17、完成。采用DCF的STA/AP在發(fā)送數(shù)據(jù)幀時，通常會采用RTS/CTS來通知后續(xù)數(shù)據(jù)交互的發(fā)生。其他節(jié)點根據(jù)RTS/CTS幀中的Duration值來更新自己的NAV值。因此，NAV機制其實是通過“預訂鏈路來保證當前數(shù)據(jù)交互不被干擾。802.12.1 NAV的更新在討論NAV的更新之前，我們有必要弄清楚一個問題：每個節(jié)點上應維護多少個NAV?是應該為網(wǎng)絡中其它每一個節(jié)點維護一個對應的NAV,還是只需要維護一個NAV?觀察以下圖所示的情況：四個節(jié)點都處在各自的收發(fā)X圍內(nèi)，且Node1和Node2正在進展數(shù)據(jù)通信，而Node3有數(shù)據(jù)要發(fā)往Node4。如果Node3為網(wǎng)絡中的其他每一個節(jié)點都維護一個對

18、應的NAV,那么此時NAV1和NAV2應該顯示鏈路忙，而NAV4應該顯示鏈路空閑，因此給Node4的數(shù)據(jù)可以直接發(fā)送。圖7每個節(jié)點維護一個NAV這種方式顯然不可行。無線傳輸本質(zhì)上是播送的，某個節(jié)點發(fā)出信號/數(shù)據(jù)可以被其接收X圍內(nèi)的所有其他節(jié)點接收到。此時如果允許Node3發(fā)送數(shù)據(jù)，一方面Node3發(fā)出的數(shù)據(jù)對Node1和Node2之間的通信產(chǎn)生干擾參見HiddenNode問題,另一方面Node1和Node2之間的數(shù)據(jù)交互對Node4的接收也產(chǎn)生干擾，最后的結(jié)果是大家都無法正常通信。因此每個節(jié)點上應該也只能維護一個NAV。這樣，當Node1和Node2在通信時，Node3和Node4上的NAV都

19、顯示鏈路正忙，此時它們將所要發(fā)送的數(shù)據(jù)緩存，等到鏈路空閑的時候再發(fā)送。這樣才能防止干擾和鏈路沖突。當收到一幀數(shù)據(jù)時，各節(jié)點需要根據(jù)的幀中的Duration值來更新其NAV,規(guī)那么如下如果數(shù)據(jù)幀的發(fā)送者就是節(jié)點本身，那么不更新NAV。如果數(shù)據(jù)幀的發(fā)送者不是節(jié)點本身，那么比擬Duration域值和當前NAV值。如果當前NAV值更小，那么將NAV值更新為Duration域值如果該節(jié)點是根據(jù)RTS幀中的Duration域值來更新自己的NAV值，那么它會要求在一定的時間內(nèi)收到相應的CTS幀或是RTS幀發(fā)送端發(fā)出的下一幀。否那么，它會將自己的NAV值復位為0。當某節(jié)點收到目的地不是本節(jié)點的RTS幀時，它肯

20、定在RTS幀的接收X圍之內(nèi)，但它有可能在CTS發(fā)送端的接收X圍之外。RTS幀承載著對鏈路的“預訂請求，只有收到了對端的CTS幀，請求才算得到允許。而收到CTS幀后，RTS發(fā)送端會以最快的速度開場發(fā)送數(shù)據(jù)。所以收到RTS幀的其他節(jié)點會在一定的時間要么里收到CTS幀，要么收到后續(xù)數(shù)據(jù)幀，否那么就有理由相信本次鏈路"預訂失敗，因而將NAV值30。802.12.2 NAV更新舉例802.12.2.1 RTS/CTS/DATA/ACK交互過程中的NAV設置圖8RTS/CTS/DATA/ACK交互中NAV的設置Source端搶占到空閑鏈路，以一個RTS幀向Destination端發(fā)起通信請求并將

21、幀中Duration域值設定為本次交互所需的時間。收到RTS后，Destination端在SIFS后回復CTS幀確認可以接收數(shù)據(jù)。其它節(jié)點根據(jù)RTS幀中的Duration值將NAV更新為：NAV=3*SIFS+aCTSTime+aDataTime+aAckTime這包括了本次數(shù)據(jù)交互還需要的時間。Destination端收到RTS幀，在間隔SIFS后，回復一個CTS幀。Source端收至ijCTS幀，在間隔SIFS后開場發(fā)送數(shù)據(jù)。其他節(jié)點根據(jù)CTS幀中的Duration值將NAV值更新為：NAV=2*SIFS+aDataTime+aAckTimeDestination端成功收到數(shù)據(jù)，在SIFS

22、后回送ACK。整個交互過程中，其他節(jié)點上的NAV值設定顯示鏈路忙。不管Source端是否接收到ACK,本次數(shù)據(jù)交互到此完畢。鏈路空閑DIFS后，各節(jié)點又開場對鏈路的競爭。這個過程中有可能出現(xiàn)CTS幀已經(jīng)發(fā)出，但只有Source端沒有收到的情況，如以下圖:此時其他節(jié)點依然按照CTS幀的要求更新了NAV，但Source端由于沒有收到CTS幀而不發(fā)送數(shù)據(jù)，這就造成了鏈路資源的7費。這是最壞的情況。此時Source端在等待一定時間后可能會比其他節(jié)點更早啟對對鏈路的競爭。3.2.2.2分片序列發(fā)送過程中的NAV設置這和單一幀的發(fā)送的區(qū)別在于，每一個分片中的Duration域都指明了下一個分片的傳輸所需的

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

24、backoff時鐘超時之前，節(jié)點不進展任何的數(shù)據(jù)發(fā)送，同時監(jiān)測鏈路的忙閑狀況。當以下情況之一發(fā)生時，競爭窗口關(guān)閉：backoff時鐘超時backoff時鐘未超時，但檢測到鏈路忙即檢測到鏈路上開場了數(shù)據(jù)交互，比方收到RTS幀或是不采用RTS/CTS機制而直接開場發(fā)送的數(shù)據(jù)幀。如果backoff時鐘未超時之前檢測到鏈路忙，此時節(jié)點會暫停backoff時鐘的運行也稱作backoff時鐘的掛起，設置自己的NAV值并啟動NAV時鐘，此時節(jié)點進入延時等待defer階段。在defer期內(nèi)，系統(tǒng)會根據(jù)3.2.1中的規(guī)那么對NAV值進展的更新。當NAV超時時，系統(tǒng)認為鏈路空閑。當鏈路連續(xù)空閑時間到達DIFS/E

25、IFS時，系統(tǒng)重新繼續(xù)resumebackoff時鐘的運行并同時監(jiān)測鏈路的忙閑狀況。backoff時鐘超時意味著當前節(jié)點獲得了鏈路的控制權(quán)，此時它可以立即開場數(shù)據(jù)的傳輸對長幀要采用RTS/CTS機制，短幀那么直接發(fā)送。而其他節(jié)點會根據(jù)該節(jié)點發(fā)送的幀暫停自己backoff時鐘的運行并對NAV值進展相應地設置和更新。很顯然，各節(jié)點上的backoff時長必須不同，它是下述方式產(chǎn)生的一個隨機值：BackoffTime=Random()*aSlotTime其中，aSlotTime是802.11物理層定義的一個常量，不同的物理層中該常量的具體定值不一木Random(那么是在0,CW之間產(chǎn)生的一個隨機的整數(shù)

26、。3.3.1 CW的取值CW在CWmin,CWmax區(qū)域內(nèi)按照一定規(guī)律變化。CWmin和CWmax是802.11系統(tǒng)中定義的兩個常量，分別表示CW值得下限和上限。CW的值總是2的N次方減1，N的值與節(jié)點中幀的重傳次數(shù)有關(guān)系。在2.1.2重傳機制一節(jié)中我們提到系統(tǒng)為每一個即將傳輸?shù)膸琲mpendingframe都相應地配備有一個重發(fā)計數(shù)器RetryCounter，長幀那么為LRCLongRC，短幀那么為SRCShortRC。除此之外，系統(tǒng)還維護著兩個獨立的重傳計數(shù)器，分別是SSRCSTAShortRetryCounter和SLRCSTALongRetryCounter,它們分別記錄著系統(tǒng)中當前短

27、幀和長幀總的連續(xù)重傳次數(shù)。SSRC和SRC的區(qū)別在于，后者對應于某一短幀，而前者對應于系統(tǒng)中所有短幀。SSRC和SRC有可能是一樣的，也有可能是不一樣的。每一次短幀的重傳都會引起SRC和SSRC的遞增。當SRC的值到達上限時，其對應的幀被丟棄，該SRC也將丟棄。此時系統(tǒng)啟動下一幀的發(fā)送，同時啟動新的SRC并將SRC的值置為0,而SSRC的值那么不會清0,而且會伴隨著新幀的重傳而繼續(xù)遞增。當以下情況之一發(fā)生時，SSRC會被清0:收到以本節(jié)點為目的地址的CTS幀收到對短幀進展確認的ACK幀發(fā)送組播/播送報文成功SLRC和LRC之間也有著類似的區(qū)別和聯(lián)系。當一下情況之一發(fā)生時，SLRC會被清0:收到

28、以本節(jié)點為目的地址的CTS幀收到對短幀進展確認的ACK幀發(fā)送組播/播送報文成功不難看出，只有發(fā)幀成功時SSRC和SLRC才會被清0,也就是說SSRC/SLRC分另1J記錄著截至目前短幀和長幀的連續(xù)重發(fā)次數(shù)。以下圖給出了CW的取值和SSRC/SLRC之間的關(guān)系：1FirstRetrsnerniGEicnInitialAttempt圖12CW值隨重傳次數(shù)增長而增長初始時，CW=CWmin每一次數(shù)據(jù)重傳，SSRC/SLRC加1,CW的值上一個“臺階"，即N=N+1當?shù)竭_CWmax之后，CW的值不再隨重傳次數(shù)的增加而增加當下述情況之一發(fā)生時，CW值被復位為CWmin:一幀發(fā)送成功SSRC/S

29、LRC至IJ達上限從CW的取值規(guī)那么我們不難發(fā)現(xiàn)：鏈路狀態(tài)越差，幀重傳的幾率越大，CW的值就可能越大，因此backoff時間值就有可能越長，節(jié)點對鏈路的競爭能力就越差。重傳幀發(fā)送的優(yōu)先級較低，因為其backoff時鐘可能更長3.3.2 backof時鐘的掛起前已述及，如果在backoff時鐘超時前鏈路已被其他節(jié)點占用，那么競爭窗口關(guān)閉，NAV值被設置，backoff時鐘暫停運行即被掛起。下一次競爭窗口開啟時，backoff時鐘繼續(xù)運行，如此周而復始直至backoff時鐘超時。以下圖舉例說明了這種場景：圖13backof時鐘的掛起3.4DCF總結(jié)采用DCF機制的節(jié)點有數(shù)據(jù)要發(fā)送時，首先要根據(jù)NA

30、V的值判斷當前鏈路的忙閑狀態(tài)。如果鏈路忙，當前的發(fā)送操作被掛起，系統(tǒng)進入DEFER期。當鏈路連續(xù)空閑時間到達DIFS/EIFS后，節(jié)點啟動backoff時鐘進入對鏈路的爭奪。backof時鐘超時就意味著鏈路控制權(quán)的獲得，此時該節(jié)點就可以開場數(shù)據(jù)發(fā)送。所有幀都只能在鏈路空閑的時候NAV為0發(fā)送，但ACK幀例外。當某個節(jié)點收到一個幀并被要求要立即回復時，不管鏈路是否空閑，它都會在SIFS之后立即回復ACK。因為不及時回復ACK會導致幀的重傳，對系統(tǒng)和整個網(wǎng)絡資源造成消耗，而回復ACK雖然可能對其他數(shù)據(jù)交互造成影響，但在DCF機制下，這種影響相對要小很多。3.4.1 NAV和Backoff二者都可以

31、被看成是時間計數(shù)器或簡單稱之為時鐘，不過NAV的值可能隨著鏈路上的數(shù)據(jù)傳輸狀況而改變，而backof的值那么在backoff時鐘重啟的時候確定，在下次超時之前不會更改。3.4.2 幀交互的“元操作性元操作在匯編中是一個常見的概念，它表示著一個不能被打斷的操作，也就是該操作要么不執(zhí)行，要么就執(zhí)行完畢，其結(jié)果只有執(zhí)行成功和失敗，不存在中間狀態(tài)。802.11中通過NAV機制和IFS機制的設定，盡量保證一次幀交互的元操作性。在3.2.2.1中所示的單幀交互過程中，一方面通過RTS/CTS交互使得所有可能干擾本次幀交互的節(jié)點“噤聲，另一方面由于其他節(jié)點都必須在鏈路連續(xù)空閑至少DIFS后才啟動鏈路競爭，而

32、CTS、Data和ACK都以SIFS做間隔，保證交互過程中雙方一定能“爭到鏈路。因此保證了幀交互的元操作性。同樣，在3.2.2.2中所示的分片序列發(fā)送過程中，一方面RTS/CTS幀以及每個分片中的Duration域值對其他節(jié)點NAV的設置使得所有可能干擾本次發(fā)送的節(jié)點“噤聲，另一方面此過程中的CTS、ACK以及個分片都以SIFS做間隔，保證交互過程中雙方一定能“爭到鏈路。所以每片的發(fā)送都是“元操作，而且如果所有分片都成功傳輸，整個分片序列的交互也具有元操作性。3.4.3 DCF的缺乏DCF大大降低了HiddenNode問題和鏈路沖突問題的發(fā)生幾率，但并不能徹底解決。由于backoff時鐘的時長

33、是隨機產(chǎn)生的，理論上講有可能兩個節(jié)點產(chǎn)生的backoff值一樣,從而在二者的backoff時鐘在同一時刻超時，因而發(fā)生鏈路沖突。再看以下圖所示場景：Node3處于兩個BSS的交界處，此時AP1正在與Nodel通信,而AP2正在與Node2通信，這種場景并不違反DCF機制，但此日在Node2處卻確實發(fā)生了HiddenNode的問題。盡管如此，DCF機制還是提供了一個很好的鏈路管理和分配機制，是802.11最根本的協(xié)調(diào)函數(shù)，所有STA/AP都必須支持。PCF和HCF都是基于DCF機制的。4.PCFDCF機制解決了鏈路的沖突，提供了鏈路的競爭規(guī)那么，但是網(wǎng)絡中的每個節(jié)點，包括STA和AP,都是鏈路爭

34、奪的個體。DCF提供的是基于競爭的鏈路共享機制Contention-BasedService，因為每次幀交互之前都必須爭奪鏈路，這在一定程度上降低了鏈路的利用率。802.11中提供了另外一種無競爭Contention-Free的鏈路共享機制，稱為PCFPointCoordinationFunction。PCF的原理是，首先由AP遵口DDCF的原那么，網(wǎng)絡中所有STA的NAV值設定成同一個數(shù)值，從而開辟一段無競爭時段CFP:Contention-FreePeriod。在CFP中，鏈路完全由AP控制，由AP來控制某個時段哪個STA可以發(fā)數(shù)據(jù)。顯然，舊SS網(wǎng)絡中不能提供PCF效勞。PCF中，AP也被

35、稱為PCPointCoordinator。4.1 CFP的開啟、維持和完畢4.1.1 Beacor#Beacon幀是802.11中最常見最重要的管理幀之一，它以固定的間隔BeaconInterval發(fā)送，向網(wǎng)絡中傳遞管理信息。Beacon幀中的具體內(nèi)容與使用的場合有關(guān)，其中與PCF機制相關(guān)的主要信息有：CF參數(shù)集CFParametersSei。4.1.1.1 CF參數(shù)集信息ElementIDLengthCFPCountCFPPeriodCFPMaxDurati&n(TU)CFPDurRamaininQ(TU)Octets:*1I1-X-1-X1X2X2A圖15CF參數(shù)集格式CFPCou

36、nt：表示距離開啟下一次CFP還有多少個DTIM間隔，0值那么表示CFP由當前Beacon幀開場。DTIM是Beacon幀中可能的內(nèi)容之一，它以固定的間隔DTIMInterval出現(xiàn)在Beacon幀中。顯然，DTIM_Interval=n*Beacon_Interval。CFPPeriod：表示相鄰兩次CFP的開啟時間的間隔，以DTIM_Interval為單位。CFPMaxDuration:表示系統(tǒng)允許的一個CFP的最大時間，以1024us為單位。CFPDurRemaining:表示從最近一次TBTTTargetBeaconTransmissionTime開場到本次CFP完畢之間的時間，以10

37、24us為單位。TBTT表示Beacon幀按方案應該出現(xiàn)的時間。由于Beacon幀的發(fā)送間隔是固定的，因而TBTT應該也是固定的。在一個時間同步的網(wǎng)絡中，所有節(jié)點的TBTT都應該是一致的。Beacon幀對網(wǎng)絡的同步起著至關(guān)重要的作用。然而由于要遵守DCF規(guī)定的鏈路訪問規(guī)那么，而另一方面每幀的長度是不固定的，實際應用中無法保證Beacon幀在每一個TBTT時間都能準時發(fā)送。引入一個TBTT量，使得即便未能按時收到Beacon幀，必要的處理也能得以進展，而需要以Beacon幀作參照的各種同步依然也能完成。4.1.1.2 TIMElementIDLengthDTIMCountDTIMPeriodBi

38、tmapControlPartialVirtualBitmapOctets:1H1M1X1M11-251圖16TIM信息格式DTIMCount:表示在下一個DTIM出現(xiàn)之前還有多少個Beacon幀。DTIMPeriod:表示DTIMInterval的值，以BeaconInterval為單位BitmapControl和PartialVirtualBitmap:這兩個域和PCF機制關(guān)系不大，暫不介紹。4.1.2 CF-PollableSTAPC通過CF-Poll幀來告訴網(wǎng)絡中哪個STA可以發(fā)數(shù)據(jù)，只有收到CF-Poll幀的STA才能發(fā)送數(shù)據(jù)。STA可以選擇響應CF-Poll,表示參加PCF機制，也

39、可以選擇不響應。響應CF-Poll的STA也被稱為CF-PollableSTA。STA通常會事先將自己的CF-Pollability告知PC。STA參加BSS過程中有一個稱為“連接Association的步驟STA參加BSS的過程會在討論802.11網(wǎng)絡管理及系統(tǒng)管理的相關(guān)章節(jié)中詳細描述。連接是STA參加BSS過程中的最后一步，用于在STA與該BSS的AP之間建立一種對應關(guān)系，使得在DS中進展中轉(zhuǎn)的以該STA為目的地址的幀可以準確地找到相關(guān)的AP進展轉(zhuǎn)發(fā)。連接由STA發(fā)起AssociationRequest,而AP處理成功后向STA發(fā)送確認。連接建立成功后，每個STA都有一個唯一的AIDAss

40、ociations。AssociationRequest信息中有一個CapabilityInfo局部，其中有一個1比特的CF-Pollable域，說明該STA是否是CF-Pollable的。4.1.3 CFP的開啟和維持當需要開啟一個CFP時，AP在鏈路連續(xù)空閑到達PIFS后發(fā)出一個帶有CF參數(shù)集信息和DTIM信息的Beacon幀。PIFS是專用于PCF機制中的一個幀間距類型，它長于SIFS,但小于DIFS,三者的關(guān)系式：aPIFS=aSIFS+aSlotTime;aDIFS=aSIFS+2*aSlotTimeSTA收到該Beacon幀后，根據(jù)CFPCount域值發(fā)現(xiàn)PC要開啟一個CFP,就將

41、自己的NAV值設為CFPMaxDuration,不管該STA是否是CF-Pollable。此時鏈路開場完全處于PC的控制中。在4.1.1.1中討論CF參數(shù)集信息時，我們已經(jīng)說過Beacon幀不能按時發(fā)送的可能性。當負責開啟一個CFP的Beacon幀不能按時發(fā)送時，就會造成該CFP延后開場，這種情況稱為foreshortenedCFP,如以下圖所示。ForeshortenedCFP的完畢時間不會相應延后。CFPRepetitionInterval.圖17CFP的開場TBTTdotllCFPMaxDurationeaconFrameDCF TrafficNominal CF repetition

42、intervalContention Period(foreshortened)Max RTS +CTS+iMPDU +ACKtim3Contention-FreePeriod圖18ForeshortenedCFP在CFP內(nèi)，PC依然會以DTIMInterval為間隔按時發(fā)送帶有DTIM和CF參數(shù)集的Beacon幀，其中CFPDurRemaining表示出了本次CFP還將持續(xù)的時間。此時各STA會根據(jù)CFPDurRemaining來重新設置自己的NAV值。4.1.4 CFP的完畢每一個CFP都有它的最大持續(xù)時間，這在Beacon幀中的CFPMaxDuration中已經(jīng)標明。當時間耗盡時，CFP將自動完畢。此時各STA上的NAV逐