Not long ago, I shared on various other resources and in my blog that ZigBee is dead and it's time to bury the technology. To put on a brave face while dealing with Thread, which operates over IPv6 and 6LowPan, Bluetooth (LE) is a more suitable alternative. But I'll discuss that another time. Today, I want to talk about how the working group of the committee revisited their second thoughts after 802.11ah and decided that it was time to add a comprehensive version of something like LRLP (Long-Range Low-Power) to the 802.11 standards pool, similar to LoRA. However, this proved impractical without sacrificing the sacred cow of backward compatibility. Ultimately, they abandoned Long-Range, leaving us with only Low-Power, which is also quite good. This resulted in a hybrid of 802.11 + 802.15.4, or simply Wi-Fi + ZigBee. In other words, we can say that the new technology is not meant to compete with LoRaWAN solutions, but rather to complement them.
So, let's start with the most important point ā now devices supporting 802.11ba must have two radio modules. Apparently, after looking at 802.11ah/ax with their Target Wake Time (TWT) technology, engineers decided that this was not enough and needed to radically reduce power consumption. Therefore, the standard provides for a division into two different types of radio ā Primary Communication Radio (PCR) and Wake-Up Radio (WUR). It is clear what the first one is; it is the main radio that transmits and receives data, but the second one is less clear. In fact, WUR primarily operates as a listening device (RX) and is designed to consume very little power during operation. Its main task is to receive a wake-up signal from the AP and activate the PCR. This method significantly reduces cold start time and allows devices to be woken up at a specified time with maximum accuracy. This is very useful when you, say, have not ten devices, but one hundred and ten, and need to exchange data with each of them within a short period. Additionally, the logic of frequency and wake-up periodicity shifts to the AP side. For instance, in LoRAWAN, the PUSH methodology is employed, where the executing devices wake up and transmit something over the air on their own, while the rest of the time they sleep. In this case, the AP decides when and which device should wake up, while the executing devicesā¦ do not always sleep.
Now let's move on to frame formats and compatibility issues. While 802.11ah was created as the first attempt for the 868/915 MHz ranges, or simply SUB-1GHz, 802.11ba is already intended for the 2.4GHz and 5GHz ranges. In the previous 'new' standards, compatibility was achieved through a preamble that older devices could understand. That is, the assumption was that older devices did not need to recognize the entire frame; they only needed to understand when the frame would start and how long the transmission would last. This information is taken from the preamble. 802.11ba is no exception, as this scheme has been tried and tested (we will set aside the question of costs for now).
As a result, a frame in 802.11ba looks something like this:
The non-HT preamble and a short OFDM fragment with BPSK modulation allows all 802.11a/g/n/ac/ax devices to catch the beginning of the transmission of this frame and refrain from interfering, going into a listening mode. Following the preamble is the synchronization field (SYNC), which essentially serves as an equivalent to L-STF/L-LTF. Its purpose is to enable frequency adjustment and synchronize the receiver of the device. At this moment, the transmitting device switches to a different channel width of 4MHz. Why? Itās quite simple. This is necessary to reduce power and achieve a comparable signal-to-noise ratio (SINR). Alternatively, the power can remain the same, significantly increasing the transmission range. I would say this is a very elegant solution, also allowing significant reductions in power source requirements. Take, for example, the popular ESP8266. In transmission mode using a bitrate of 54 Mbps and a power of 16dBm, it consumes 196 mA, which is excessively high for something like a CR2032. If we reduce the channel width by five times and the transmitter power by five times, we will lose almost nothing in transmission range, but the current consumption will drop significantly, say to around 50 mA. While it's not critical on the AP side transmitting the frame for WUR, it's still good. However, for the STA, this makes sense as lower consumption allows the use of something like a CR2032 or batteries designed for long-term energy storage with low nominal discharge currents. Of course, nothing comes for free, and the reduction in channel width will lead to a decrease in channel speed with an increase in the transmission time of a single frame accordingly.
Speaking of channel speed. The standard in its current form provides for two options: 62.5 Kbps and 250 Kbps. Do you feel the hint of ZigBee? This isn't by chance, as it has a channel width of 2MHz instead of 4MHz, but a different modulation type with greater spectral density. As a result, the range of 802.11ba devices should be greater, which is quite advantageous for indoor IoT scenarios.
But wait a secondā¦ Forcing all the stations in the area to stay silent while using just 4 MHz from a 20 MHz bandā¦ "THIS IS WASTEFUL!" ā you might say, and you would be right. But no, THIS IS TRUE WASTEFULNESS!
The standard includes the possibility of using 40 MHz and 80 MHz subchannels. At the same time, the bitrates of each subchannel can be different, and to align the transmission timing, Padding is added at the end of the frame. So, a device can occupy the airtime for all 80 MHz, but use it only on 16 MHz. Now that's real wastefulness.
By the way, surrounding Wi-Fi devices have no chance of understanding what is being broadcast over the air. This is because the coding of 802.11ba frames does NOT use the familiar OFDM. Yes, just like that, the alliance abandoned what had worked reliably for many years. Instead of classic OFDM, Multi-Carrier (MC)-OOK modulation is used. The 4 MHz channel is divided into 16(?) subcarriers, each of which uses Manchester encoding. Additionally, the DATA field is also logically divided into segments of 4 Ī¼s or 2 Ī¼s depending on the bitrate, with each segment representing a low or high level of encoding. This solution prevents long sequences of zeros or ones. Scrambling at its minimum.
The MAC level is also drastically simplified. It contains only the following fields:
- Frame Control
May take values such as Beacon, WuP, Discovery, or any other vendor choice.
Beacon is used for time synchronization, WuPs are intended for waking one or a group of devices, and Discovery works in reverse from STA to AP and is created to find access points supporting 802.11ba. The length of the frame is also transmitted in this field if it exceeds 48 bits. - ID
Depending on the type of frame, it can identify either AP, STA, or a group of STAs to which this frame is intended. (Yes, devices can be awakened in groups, it's called groupcast wake-ups and it's pretty cool).
- Type Dependent (TD)
A fairly flexible field. It can transmit the exact time, a signal about firmware/configuration updates with the version number, or something useful that the STA should know.
- Frame Checksum Field (FCS)
It's straightforward. This is the checksum.
However, for the technology to work, simply sending a frame of the right format is not enough. STA and AP need to agree. STA communicates its parameters, including the time required to initialize PCR. All agreements occur using standard 802.11 frames, after which STA can disconnect PCR and switch to WUR activation mode. It can even take a short nap if the opportunity arises because if it's available, it's better to take advantage of it.
Next, thereās a slight squeeze on the precious milliamp-hours called the WUR Duty Cycle. It's not complicated; STA and AP negotiate a sleep schedule, similar to how it was done for TWT. After that, STA predominantly sleeps, occasionally waking WUR to listen for āHas anything useful come for me?ā. Only when necessary does it wake the main radio module for traffic exchange.
This radically changes the situation compared to TWT and U-APSD, doesnāt it?
Now, an important nuance that is not immediately considered. WUR does not necessarily have to operate on the same frequency as the main module. On the contrary, it is preferable and recommended that it operates on a different channel. In this case, the functionality of 802.11ba does not interfere with network operations and can instead be used to disseminate useful information. Location, Neighbour List, and much more within other 802.11 standards, such as 802.11k/v. The advantages this opens up for Mesh networks are substantialā¦ but that's a topic for another article.
As for the fate of the standard document itself, This means that this year we can expect a genuine standard or at least the first implementations. How widely it will be adopted will only be revealed with time.
That's the situationā¦ (c) .
Recommended literature for your reference:
Source: habr.com
