[New WiFi] Dueling NAVs in 802.11ax
在之前的文章中,
介紹了在新 WiFi 協定中討論的空間重複利用方案,
而在這一篇文章中, 則是介紹在 802.11ax 實作的方案,
主要內容來自: https://blog.aerohive.com/dueling-navs-in-802-11ax/
在介紹 802.11ax 特殊的 NAV 機制之前,
我們先介紹標準 802.11 下的標準 NAV 機制 (RTS-CTS 機制),
原始的 RTS-CTS 機制
在 802.11ax 的機制下, 可以針對此兩種 NAV 設定不同的門檻,
換句話說, 對於 Intra-BSS NAV, 可以設置一較高的門檻,
只有其能量夠高 (隱含距離較近), 才設置 NAV 的保護,
而對於相同 AP 下的 NAV, 門檻較低, 避免干擾他人的傳輸.
藉由不同 NAV 門檻的設置,
在 802.11ax 中可以解決一定程度的 explored node 問題,
(上圖即是一個 explored node 的範例)
至於要如何判別 NAV 是 Intra-BSS NAV, 還是 Inter-BSS NAV,
我們就要介紹 802.11ax 中的 BSS coloring 的機制,
可以參考至一篇文章:
https://note-on-clouds.blogspot.com/2018/12/wifi-80211ax-bss-coloring.html
介紹了在新 WiFi 協定中討論的空間重複利用方案,
而在這一篇文章中, 則是介紹在 802.11ax 實作的方案,
主要內容來自: https://blog.aerohive.com/dueling-navs-in-802-11ax/
在介紹 802.11ax 特殊的 NAV 機制之前,
我們先介紹標準 802.11 下的標準 NAV 機制 (RTS-CTS 機制),
原始的 RTS-CTS 機制
NAV 為 Network Allocation Vector 的簡寫,
當使用 RTS-CTS 傳出機制時,
在 RTS, CTS 封包中, 都會在 duration field 中填入 NAV 的長度,
當其他使用者收到 RTS/CTS 封包時, 會根據 NAV 的長度, 凍結 backoff window,
換句話說, 在宣告的 NAV 時間內, 都不會嘗試傳送封包
原本的 RTS-CTS 機制是為了解決 hidden node/explore node 問題,
然而, 考慮其實作的方式, 只可以解決 hidden node (潛在的干擾),
但是, 對於 explore node (潛在的傳送機會), 卻沒有幫助,
在此保守的設計下, 使用者當聽到附近基地台的訊號時, 也會停止嘗試傳送封包,
特別是在一般 WiFi 網路下, 由於 AP 使用的功率高於使用者不少,
容易發生由 AP 發送的 RTS 阻斷多數使用者傳輸機會的狀況,
對於密集佈建的 WiFi 網路而言, 將減低網路效率.
因此, 802.11ax 設計了一個新的 NAV 機制,
將 NAV 分成 Intra-NAV 以及 Basic NAV,
對應於鄰近網路的 NAV 以及所屬網路的 NAV, 如下圖所示:
在 802.11ax 的機制下, 可以針對此兩種 NAV 設定不同的門檻,
換句話說, 對於 Intra-BSS NAV, 可以設置一較高的門檻,
只有其能量夠高 (隱含距離較近), 才設置 NAV 的保護,
而對於相同 AP 下的 NAV, 門檻較低, 避免干擾他人的傳輸.
藉由不同 NAV 門檻的設置,
在 802.11ax 中可以解決一定程度的 explored node 問題,
(上圖即是一個 explored node 的範例)
至於要如何判別 NAV 是 Intra-BSS NAV, 還是 Inter-BSS NAV,
我們就要介紹 802.11ax 中的 BSS coloring 的機制,
可以參考至一篇文章:
https://note-on-clouds.blogspot.com/2018/12/wifi-80211ax-bss-coloring.html
留言
張貼留言