Castle on a Cloud

回顧行動網路 (telecom) 和電腦網路 (datacom) 之爭, 其中一個爭論要點, 就是分散式架構與中央式架構, 結果, 在邁向 5G 的今日, 我們可以看到兩者的融合發展, 一方面, 3GPP 陣營思考在小基地台架構下, 賦予基地台更多權力, 甚至讓資料可以不透過核心網路, 就在裝置間進行交換, 另一方面, WiFi 陣營, 在 802.11ax 的版本中, 也引入了更多 scheduling-based 的機制, 而非透過競爭解決, 以目前的趨勢觀看, 5G 的共識應該會是小基地台架構, 分散式的小基地台接取 (減少網路產生的延遲), 以及小基地台內的中央調控式資源分配 (增加頻譜利用率), 最後, 留下的問題仍然是: 要如何處理小基地台間的干擾, 對此, 雙方都有一些看法, 但最終有效方案仍未明... 好吧, 閒聊到此為止, 回到主題, 對於 downlink 的 MU-MIMO, 在之前 WiFi 的協定中已經定義完成, 主要透過 AP 將不同使用者的封包, 放在同一個 OFDM 區間中, 分時傳送不同使用者的資訊, 如下圖 (左) 所示, 原始圖片來自:  https://www.slideshare.net/CiscoCanada/cisco-connect-winnipeg-2018-optimizing-your-clients-wifi-experience-v4-public 圖右是 802.11ax 加入的新機制, 也就是 OFDMA 機制, 簡單來說, OFDMA 允許 AP 對資源做更詳細的切分 (對時間和頻率), 而不只是分時傳送資料給使用者, 增加頻譜的利用效率, 考慮到 downlink 的特性, 封包統一由 AP 配置後發出, 此部分的修改, 的確可以有效的減少使用者競爭, 但是對於 uplink 而言, 事情就沒有這麼簡單, 考慮到在舊有的 WiFi 網路中, 使用者各自競爭通道資源, 其中並沒有機制能讓 WiFi 使用者 "共同的" 在同一時間中分享通道資源, 為了解決此困難, 在 802.11ax 中定義了 uplink MU-MIMO 的機制, 如下圖所示: 來自:  https://www.ni.com/zh-tw

在之前的文章中, 介紹了在新 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, 如下圖所示: 來自:  https://blog.aerohive.com/dueling-navs-in-802-11ax/ 在 802.11ax 的機制下, 可以針對此兩種 NAV 設定不同的門檻, 換句話說, 對於 Intra-BSS NAV, 可以設置一較高的門檻, 只有其能量夠高 (隱含距離較近), 才設置 NAV 的保護, 而對於相同 AP 下的 NAV, 門檻較低