> 本筆記主要紀錄 802.11ax 中有關於 Medium Access Control 有關的知識,若你有疑問或是看到錯誤的地方,歡迎留言發問或指證 :+1: > 持續更新中... # 簡介 首先要釐清一件事,802.11ax 在設計的時候,需要考慮到 Legacy Devices,所以之後的很多設計如果看不懂 or 不知道為甚麼要這麼做,或許可以往這方面思考。 ## Interfrmae Space (IFS) ### Short Interframe Space (SIFS) 在 802.11 中,SIFS 是固定的值,並且是最小的 IFS。使用 IFS 的節點必可以搶到下一次的使用權。 SIFS 約等於節點在==發送狀態與接收狀態之間切換所需要的時間==,在 SIFS 過後可能發送的 frame 包括 ACK 或 CTS。 ### DCF Interframe Space (DIFS) 在 DCF 中,節點必須確保 channel 在 idle DIFS 時間後,才能進行 backoff,backoff 到 0 即可直接發送。 計算方式:**DIFS = SIFS + (2 * Slot time)** #### Slot time 在 CSMA/CA 的 backoff 中,節點每經過一個 Slot time,就會監聽一次 channel,如果 channel 是 idle,就會將 backoff 值減一。下圖是一個大小為 $9us$ 的 slot time。 ![image](https://hackmd.io/_uploads/BJMsw7uAa.png =70%x) 在整個 slot time 中,只有 CCA 的階段會真正在監聽 channel,同時節點也會檢查是否有傳送給自己的 frame,以方便在第三階段轉換接收或傳送狀態。 ### PCF Interframe Space (PIFS) PIFS 會略短於 DIFS,目的是==讓 AP 有更高的優先級==。 計算方式:**PIFS = SIFS + Slot time** ## 上行隨機接入 在 802.11ax 出現以前,裝置的 Uplink Transmission 是採用典型的 **CSMA/CA** 機制,也就是 random access。引入 OFDMA 之後,此機制也需改變。 因此 802.11ax 設計了基於 ALOHA 的隨機接入方法,但我們先介紹這兩個機制: - TF (Trigger Frame) - TF-R (Trigger Frame for Random Access) ### TF (Trigger Frame) 這是一個非常簡單的過程,AP 使用全部的 RU 發送 Trigger Frame,STA 收到後就可以根據其中的訊息來得知他接下來要使用的 RU 是哪個。 ![image](https://hackmd.io/_uploads/HkzZ5u_na.png =80%x) 這是 Trigger Frame 裡面包含的訊息,STA 會有屬於自己的 AID,如果出現在 User ID 欄位中,代表STA要看的是這個 Trigger Frame。而 RA 是給 Random Access 使用。 ![image](https://hackmd.io/_uploads/HJ7V5OOn6.png =80%x) 要注意的是,在 TF 機制中,STA不像先前競爭到 Channel 後就可以啟動上行傳輸,只有在 AP 發送 Trigger Frame 後才可以開始上傳 or 競爭。 ### TF-R (Trigger Frame for Random Access) 在上述的 TF 機制中,新增了競爭的機制。注意,此機制是在上述的 TF 機制==之前==執行的。 ![image](https://hackmd.io/_uploads/SJazA__3a.png) 每個 STA 擁有一個初始的 OBO 值,且在每輪 backoff 中會減去此輪==空閒的 RU 數量== (不是像之前是減 1 )。 RU 1、RU 2、RU 3 目前還沒有人使用,共有 3 個空閒的 RU,所以此次 backoff 中,OBO 值會一次減去 3。當 STA 的 OBO 變為 0,他可以隨機選擇一個 RU 作為上行傳輸的資源。 此過程可以一直重複,直到 TF-R 中沒有 Random Access 的 RU 後,回到上面的 TF 機制。 ## Operating Mode Indication (OMI) 如果 AP 想要啟動一次 UL-OFDMA 傳輸,那麼它也是需要與其他==裝置==競爭 Channel,這代表 802.11ax 的 STA 如果有資料想上傳,必須等到 AP 競爭成功,才有機會使用 Channel。 為此 802.11ax 制定了 OMI 功能,讓 STA 可以透過發送 TOM(Transmit Operating Mode)給 AP,在 **Single User** 與 **Multi User** 模式之間切換。 在 Single User mode 中,STA 就不會參與由 AP 主導的 UL-OFDMA 傳輸,需像 Legacy device 一樣自己競爭 Channel。 ## OFDMA 802.11ax 最大的進步就是 **OFDMA** 的引進,在過往 802.11c 以下的 uplink 傳輸,都只支援單一用戶上傳,==OFDMA 可以做到在同一時間內讓多個用戶同時上傳==。 > 註:Legacy device 是不支援的 上面有提到,任何裝置(包含AP)在發送之前都需要競爭,且也有可能會發生碰撞。 802.11ax 的裝置遵守 EDCA,AP 實際上比其他的 STA 擁有更大的機會競爭到 Channel。 裝置從偵測到 Channel 是 idle 到它可以開始 backoff 事實上還需要再等待一段時間,即 **xIFS**,而 EDCA 中規定 AP 可以擁有比其他 STA 還更小的 IFS值。 在 AP 競爭到 Channel 後,AP 可以選擇開啟由它控制的 UL-OFDMA 以及 DL-OFMDA,其中的訊息交換由 Trigger Frame 來達成。共有以下幾種: ![image](https://hackmd.io/_uploads/HyVukqO2a.png =80%x) ### Down Link OFDMA 由於網路中存在的 Legacy device,AP 發送的控制/管理 frame 都會使用傳統的 OFDM 形式:也就是占據整個 Channel。 ![image](https://hackmd.io/_uploads/BJkK-5O3p.png =80%x) 當 AP 競爭成功後,發送 MU-RTS frame,這有兩個功能: - ==保留競爭到的 TXOP==,因為包含 Legacy device 內的所有 STA 都可以接收到這個 frame,這些 STA 就會偵測到 channel 是 busy 的情況。並且設定其他裝置的 NAV 值,確保在預定的時間內,其他裝置不會參與競爭。 - 分配後續 STA 傳輸 CTS 時的 ==RU allocation scheme==。 後續的過程就如圖所示。 ### Up Link OFDMA 上行傳輸對於下行來說更為複雜,原因是 AP 並不知道各個 STA 有多少資料要傳輸,因此需要透過額外的 trigger frame 來獲取必要的訊息。 下圖中分別有3個不同功能的 trigger frame :  ![image](https://hackmd.io/_uploads/B1-BOc_3a.png =80%x) - **BSRP (Buffer Status Report Poll)**:用於獲取 STA 有多少資料要傳送,AP 根據這些資訊來進行後續的 RU allocation。 - **MU-RTS**: - 設定 legacy device 的 NAV,確保他們不會在剩餘時間內競爭 channel。 - 告訴 STA 上行傳輸的 ==RU allocation scheme==。 - **Trigger**:通知 STA 可以在指定的 RU 上傳輸,其中包含本次傳輸的時間,如果 STA 沒有這麼多資料要傳送,它需要透過 padding 把剩餘時間填滿。 ## TXOP TXOP 的概念允許裝置可以「一次競爭,多次傳輸」。 在 802.11ax 中,TXOP 的大小與傳輸的 data 大小有關。 >In an MU-RTS Trigger frame, the Duration/ID field is set to the estimated time, in microseconds, required to transmit the pending frame(s), plus one CTS frame, plus the time to transmit the solicited HE TB PPDU if required, plus the time to transmit the acknowledgment for the solicited HE TB PPDU if required, plus applicable IFSs. 標準中提到,這個時間就是以下 4 個加總: - Trigger Frame 本身的時間 - CTS 時間 - <font color=red>傳輸 data 時間</font> - ACK 時間 其中最重要的是傳輸 data 的時間,如果是在 **downlink** 的情況,AP 知道自己要傳多長的資料,且所有 RU 的傳輸速率都是已經確定的。 而 **uplink** 則需要事先得知一些必要的訊息,AP 才能計算出這個 TXOP 時間。 - 在 OFDMA 傳輸時,所有裝置的傳輸速率是 AP 來指定的 - BSRP/BSR 步驟可以讓 AP 知道 STA 有多少資料要傳送 但是 UORA 中卻沒有 BSRP/BSR 這個步驟,如果此次 TXOP 時間不夠傳輸一個完整的 frame,STA 通常會選擇不傳輸,但是這樣會讓網路的整體效率變低,甚至讓 throughput 變為 0。 <!-- ### Dynamic Fragmentation --> ## Primary channel & Secondary Channel 從 802.11n 與 802.11ac 開始,裝置可以藉由==合併== 2 個鄰近的頻道,來獲得更大的頻寬以進行傳輸。而在這些合併起來的大頻道中,其中一個 20 MHz 的頻道會被稱為 **Primary Channel**,其餘的則會被稱為 **Secondary Channel**。 AP 首先會決定這個 BSS 所要使用的==頻寬==,以及 ==Primary Channel 的號碼==。假設現在使用 160MHz 的頻道,他被劃分如下。在所有的小頻道中,只會有一個 20MHz 的 Primary Channel。 首先, AP 會先檢查 Secondary 80MHz,如果是 idle,如果 Primary 20 MHz 與 Secondary 20 MHz 都是 idle,則他們可以合併為 Primary 40MHz,然後再去檢查 Secondary 40MHz。 ![image](https://hackmd.io/_uploads/S1xPgzVRp.png) AP 大多會將控制訊框傳送在 Primary Channel 而不是 Secondary Channel。 在不同的的 BSS 中,可能會選擇不同的頻道作為 Primary Channel,卻也有可能重複。 ## Bandwidth selection 節點選擇 bandwidth 的過程是在 backoff ==即將==結束的 PIFS/DIFS 時間中。 ![image](https://hackmd.io/_uploads/Sk2R-QuRT.png =80%x) > **Primary Channel:** A channel that includes the primary 20 MHz channel. According to the channel bandwidth, primary 20, 40, 80, and 160 MHz channels are available. > > **Secondary channel:** A neighboring channel of a primary channel that bonds with the primary channel to form another primary channel of the next wider bandwidth. According to the bandwidth, secondary 20, 40, and 80 MHz channels are available. 一旦一個 BSS 決定了 Primary 20MHz (P20) 的 channel 號碼,後續的 Secondary 20 MHz (S20)、 S40 與 S80 的 channel 號碼也會一併決定好。 ### 流程: 首先,當剩餘的 backoff time 等於 PIFS 時,節點需要==同時==偵測 primary channel 與所有其他的 ==20MHz channel==。 當 backoff 完成後,節點也同時完成對其他 secondary channel 的偵測,判斷哪些 channel 能使用後,就可以決定這次傳輸所使用的頻寬,後續在 preamble frame 裡面告知接收者這個訊息。 :::warning Q:在拓展 bandwidth 的過程中,如何確保之間偵測到是 idle 的 channel 不會突然變成 busy ? ::: ### 加入 puncturing 的功能 由於在 802.11ax 中加入了 puncturing 的功能,當 STA 要選擇傳輸的 bandwidth 時,必須要知道目前可以使用的 RU 有哪些,才能避免去偵測到 busy 的 RU。 但要這麼做必須由 AP 使用 preamble frame 來告知 STA,所以至少得有一個空閒的 channel 留給 AP 使用。 AP 會偵測==每一個== 20MHz 的 channel,並在 P20 上進行 backoff,接著告訴所有 STA 目前哪些 channel 要打洞,這樣就可以避免偵測到 busy 的 channel 而導致失去使用更多 channel 的機會。