不久前，在各種其他資源和我的部落格中，我談到了 ZigBee 已死的事實，是時候埋葬空服員了。 為了讓 Thread 在 IPv6 和 6LowPan 之上運行的糟糕遊戲蒙上好臉，更適合於此的藍牙 (LE) 就足夠了。 但我會在其他時間告訴你這件事。 今天我們將討論委員會的工作小組在 802.11ah 之後如何決定三思而後行，並決定是時候將 LRLP（遠程低功耗）等成熟版本添加到 802.11 標準池中，類似給洛拉。 但事實證明，如果不犧牲向後相容性這頭聖牛，這是不可能實現的。 結果Long-Range被放棄了，只剩下Low-Power，這也很好。 結果是 802.11 + 802.15.4 的混合，或只是 Wi-Fi + ZigBee。 也就是說，我們可以說新技術不是 LoraWAN 解決方案的競爭對手，相反，它是為了補充它們而創建的。
那麼，讓我們從最重要的事情開始 - 現在支援 802.11ba 的設備應該有兩個無線電模組。 顯然，在研究了 802.11ah/ax 及其目標喚醒時間 (TWT) 技術後，工程師認為這還不夠，他們需要從根本上降低功耗。 為什麼該標準規定將無線電分為兩種不同類型 - 主通訊無線電 (PCR) 和喚醒無線電 (WUR)。 如果第一個一切都清楚了，這是主無線電，它傳輸和接收數據，那麼第二個就沒有那麼多了。 事實上，WUR 主要是一個監聽設備 (RX)，並且設計為消耗很少的電力來運作。 它的主要任務是接收來自AP的喚醒訊號並啟用PCR。 也就是說，此方法顯著減少了冷啟動時間，並允許您在給定時間以最大精度喚醒設備。 當您擁有的設備不是十台而是一百一十台並且您需要在短時間內與每個設備交換資料時，這非常有用。 另外，喚醒的頻率和週期的邏輯轉移到了AP側。 比如說，如果 LoRAWAN 在執行器本身喚醒並在空中傳輸某些內容並在其餘時間睡眠時使用 PUSH 方法，那麼在這種情況下，相反，AP 決定何時以及哪個設備應該喚醒，並且執行器本身....並不總是休眠。
現在讓我們繼續討論幀格式和相容性。 如果 802.11ah 作為第一次嘗試是為 868/915 MHz 頻段或簡單的 SUB-1GHz 創建的，那麼 802.11ba 已經針對 2.4GHz 和 5GHz 頻段而設計。 在先前的“新”標準中，相容性是透過舊設備可以理解的序言來實現的。 也就是說，一直以來的計算是，較舊的設備不一定需要能夠識別整個幀；它們只需了解該幀何時開始以及傳輸將持續多長時間就足夠了。 他們從序言中獲得的正是這些資訊。 802.11ba 也不例外，因為該方案已被證實（我們暫時忽略成本問題）。
結果，802.11ba 幀看起來像這樣：
非 HT 前導碼和採用 BPSK 調變的短 OFDM 片段允許所有 802.11a/g/n/ac/ax 裝置聽到該訊框傳輸的開始並且不會幹擾，進入廣播偵聽模式。 前導碼之後是同步欄位 (SYNC)，它本質上是 L-STF/L-LTF 的類似物。 它可以調整頻率並同步設備的接收器。 正是在此時，發射設備切換到另一個頻道寬度4 MHz。 為了什麼？ 一切都很簡單。 這是必要的，以便可以降低功率並實現可比較的訊號雜訊比 (SINR)。 或保持電源不變，並顯著增加傳輸範圍。 我想說，這是一個非常優雅的解決方案，它還可以顯著降低電源的要求。 例如，讓我們記住流行的 ESP8266。 在使用 54 Mbps 位元速率和 16dBm 功率的傳輸模式下，它消耗 196 mA 的電流，這對於 CR2032 等設備來說過高。 如果我們將通道寬度減少五倍，並將發射機功率減少五倍，那麼我們實際上不會損失傳輸範圍，但電流消耗將減少一個係數，例如大約50毫安培。 這對於傳輸 WUR 幀的 AP 來說並不重要，但它仍然不錯。 但對於 STA 來說，這已經很有意義，因為較低的功耗允許使用 CR2032 等電池或專為低額定放電電流長期儲能而設計的電池。 當然，沒有什麼是免費的，減小通道寬度會導致通道速度下降，同時增加一幀的傳輸時間。
順便說一下頻道速度。 目前形式的標準提供了兩個選項：62.5 Kbps 和 250 Kbps。 你感受到ZigBee的味道了嗎？ 這並不容易，因為它的通道寬度為 2Mhz 而不是 4Mhz，而是具有更高頻譜密度的不同類型的調製。 因此，802.11ba 設備的範圍應該更大，這對於室內 IoT 場景非常有用。
雖然，等一下...迫使該區域的所有電台保持安靜，同時只使用 4 MHz 頻段中的 20 MHz...“這是浪費！” - 你會說，你是對的。 但不，這才是真正的浪費！
此標準提供了使用 40 MHz 和 80 MHz 子頻道的能力。 在這種情況下，每個子通道的碼率可以不同，為了匹配廣播時間，在幀末尾添加Padding。 也就是說，設備可以佔用所有 80 MHz 上的通話時間，但僅在 16 MHz 上使用它。 這是真正的浪費。
順便說一句，周圍的 Wi-Fi 設備無法了解那裡正在廣播的內容。 因為通常的 OFDM 不用於編碼 802.11ba 幀。 是的，就這樣，聯盟放棄了多年來完美運作的東西。 使用多載波 (MC)-OOK 調變代替傳統的 OFDM。 4MHz頻道分為16（？）個子載波，每個子載波都使用曼徹斯特編碼。 同時，DATA欄位本身也根據位元率在邏輯上分為4μs或2μs的段，並且在每個這樣的段中，低或高編碼等級可以對應一個。 這是避免出現長序列 XNUMX 或 XNUMX 的解決方案。 爭奪最低工資。
MAC層也極為簡化。 它只包含以下欄位：
- 框架控制
可以採用Beacon、WuP、Discovery 值或供應商選擇的任何其他值。
Beacon 用於時間同步，WuP 旨在喚醒一個或一組設備，Discovery 的工作方向與 STA 到 AP 相反，旨在尋找支援 802.11ba 的存取點。 如果訊框超過 48 位，則該欄位也包含幀的長度。 - ID
根據訊框的類型，它可以識別該訊框所針對的 AP、STA 或 STA 群組。 （是的，您可以分組喚醒設備，這稱為組播喚醒，這非常酷）。
- 類型相關 (TD)
相當靈活的領域。 正是在其中可以傳輸確切的時間、帶有版本號的關於韌體/配置更新的信號或STA應該知道的有用的信息。
- 訊框校驗和欄位 (FCS)
這裡一切都很簡單。 這是一個校驗和
但要使該技術發揮作用，僅以所需格式發送幀是不夠的。 STA和AP必須同意。 STA報告其參數，包括初始化PCR所需的時間。 所有協商均使用常規 802.11 幀進行，之後 STA 可以停用 PCR 並進入 WUR 啟用模式。 或者如果可能的話，甚至可以睡一會兒。 因為如果它存在，那麼最好使用它。
接下來是對寶貴的毫安培小時的進一步壓縮，稱為 WUR 佔空比。 沒有什麼複雜的，只是 STA 和 AP（與 TWT 的情況類似）就睡眠時間表達成協議。 此後，STA 大部分時間都在睡覺，偶爾打開 WUR 聽聽“我有什麼有用的東西嗎？” 並且只有在必要時，它才會喚醒主無線電模組進行流量交換。
與 TWT 和 U-APSD 相比，情況發生了根本性的改變，不是嗎？
現在你不會立即想到一個重要的細微差別。 WUR 不必以與主模組相同的頻率運作。 相反，我們希望並建議它在不同的管道上工作。 在這種情況下，802.11ba 功能不會以任何方式乾擾網路的運行，相反，可以用來發送有用的信息。 其他 802.11 標準（例如 802.11k/v）中的位置、鄰居清單等。 網狀網路有哪些優點……但這是另一篇文章的主題。
至於標準本身作為文件的命運，那麼 。 也就是說，今年我們可以期待一個真正的標準，或至少第一個實施。 只有時間才能證明它的廣泛性。
這樣的事情...(c) .
推薦閱讀：
來源： www.habr.com