Not so long ago, on all sorts of other resources and on my blog, I talked about the fact that ZigBee is dead and itβs time to bury the flight attendant. In order to make a good face on a bad game with Thread running on top of IPv6 and 6LowPan, Bluetooth (LE) is more adapted for this. But I will talk about this some other time. Today we will talk about how the working group of the committee thought well for the second time after 802.11ah and decided that it was time to add a full-fledged version of something like LRLP (Long-Range Low-Power) to the 802.11 standards pool, by analogy with LoRA. But it turned out not to be feasible without slaughtering the sacred cow of backward compatibility. As a result, Long-Range was abandoned and only Low-Power remained, which is also very good. The result was a mixture of 802.11 + 802.15.4 or simply Wi-Fi + ZigBee. That is, we can say that the new technology is not a competitor to LoraWAN solutions, but rather is created in order to complement them.
So, let's start with the most important thing - Now devices with 802.11ba support should have two radio modules. Apparently, after looking at 802.11ah / ax with their Target Wake Time (TWT) technology, the engineers decided that this was not enough and they needed to radically reduce power consumption. For what the standard provides for the division into two different types of radio - Primary Communication Radio (PCR) and Wake-Up Radio (WUR). If everything is clear with the first, here it is the main radio, it transmits and receives data, then the second is not very good. In fact, the WUR is mostly a listening device (RX) and is designed to consume very little power to operate. Its main task is to receive a wake-up signal from the AP and turn on the PCR. That is, this method significantly reduces the cold start time and allows you to wake up devices at a given time with maximum accuracy. This is very useful when you have, say, not ten devices, but one hundred and ten, and you need to exchange data with each of them in a short period. Plus, the logic of the frequency and frequency of awakening moves to the side of the AP. If, say, LoRAWAN uses the PUSH methodology when the executive devices themselves wake up and broadcast something, and sleep the rest of the time, then in this case, on the contrary, the AP decides when and which device should wake up, and the executive devices themselves ... not always are sleeping.
Now let's move on to frame formats and compatibility. If 802.11ah as the first attempt was created for the 868/915 MHz bands, or simply SUB-1GHz, then 802.11ba is already intended for the 2.4GHz and 5GHz bands. In previous "new" standards, interoperability was achieved through a preamble that older devices could understand. That is, the calculation has always been that old devices do not need to be able to recognize the entire frame, it is enough for them to understand when this frame will start and how long the transmission will last. It is this information that they take from the preamble. 802.11ba was no exception, since the scheme has been tested and worked out (we will omit the issue of costs for now).
As a result, the 802.11ba frame looks something like this:
The non-HT preamble and short BPSK OFDM fragment allows all 802.11a/g/n/ac/ax devices to hear the start of this frame and not interfere by going into listening mode. After the preamble, the synchronization field (SYNC) follows, which is essentially an analogue of L-STF / L-LTF. It serves to make it possible to adjust the frequency and synchronize the receiver of the device. And just at this moment, the transmitting device switches to another channel width of 4MHz. For what? Everything is very simple. This is necessary in order to be able to reduce the power and achieve a comparable signal-to-power-with-noise ratio (SINR). Or leave the power as it is and achieve a significant increase in transmission range. I would say that this is a very elegant solution, moreover, it allows to significantly reduce the requirements for power supplies. Recall, for example, the popular ESP8266. In transmit mode using 54 Mbps bit rate and 16dBm power it consumes 196 mA, which is prohibitively high for something like CR2032. If we reduce the channel width by five times and reduce the transmitter power by five times, then we will practically not lose in the transmission range, but the current consumption will be reduced by a factor of, say, to about 50 mA. Not that it was critical from the side of the AP that transmits the frame for the WUR, but still not bad. But for STA, this already makes sense, since lower consumption allows you to use just something like CR2032 or batteries sharpened for long-term energy storage with low nominal discharge currents. Of course, nothing is free, and reducing the channel width will lead to a decrease in the channel speed with an increase in the transmission time of one frame, respectively.
By the way, about channel speed. The standard in its current form provides for two options 62.5 Kbps and 250 Kbps. Do you feel ZigBee smelled? This is not easy, since it has a channel width of 2Mhz instead of 4Mhz, but a different type of modulation with a higher spectral density. As a result, the range of 802.11ba devices should be greater, which is very useful for indoor IoT scenarios.
But wait a minute... Making all the stations in the area silent, while using only 4 MHz from the 20 MHz band... "THIS IS A WASTE!" - you will say and you will be right. But no, THIS IS A REAL WASTE!
The standard includes the ability to use 40 MHz and 80 MHz subchannels. In this case, the bitrates of each subchannel can be different, and in order to match the broadcast time, Padding is added to the end of the frame. That is, the device can take airtime on all 80 MHz, and use it only on 16 MHz. Now this is real waste.
By the way, the surrounding Wi-Fi devices have no chance to understand what is being broadcast there. Because 802.11ba frames are NOT encoded with their usual OFDM. Yes, this is how famously the alliance abandoned what had been working flawlessly for many years. Instead of classic OFDM, Multi-Carrier (MC)-OOK modulation is used. The 4MHz channel is divided into 16(?) subcarriers, each of which uses Manchester coding. At the same time, the DATA field itself is also logically divided into segments of 4 ΞΌs or 2 ΞΌs, depending on the bitrate, and in each such segment, a low or high coding level can be responsible for one. This is the solution to avoid a long sequence of zeros or ones. Scrambling at the minimum.
The MAC level is also incredibly simplified. It only contains the following fields:
- frame control
It can be Beacon, WuP, Discovery, or whatever the vendor chooses.
Beacon is used to synchronize time, WuP is designed to wake up one or a group of devices, and Discovery works in the opposite direction from STA to AP and is designed to find access points that support 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 the AP or STA or group of STAs to which the given frame is intended. (Yes, you can wake devices in groups, it's called groupcast wake-ups and it's pretty cool).
- Type Dependent (TD)
Pretty flexible field. It is in it that the exact time can be transmitted, a signal about a firmware / configuration update with a version number, or something useful that the STA should know about.
- Frame Checksum Field (FCS)
Everything is simple here. This is the checksum
But in order for the technology to work, it is not enough just to send a frame of the desired format. STA and AP must agree. The STA reports its parameters, including the time it takes to initialize the PCR. All negotiation takes place using regular 802.11 frames, after which the STA can disable PCR and enter WUR activation mode. And maybe even get some sleep, if possible. Because if it is, then it is better to use it.
Then another little squeezing of precious milliamp hours called WUR Duty Cycle begins. There is nothing complicated, just STA and AP, by analogy with there, as it was for TWT, agree on a sleep schedule. After that, STA mostly sleeps, occasionally including WUR in order to listen to "Has anything useful come to me?". And only if necessary, it wakes up the main radio module for traffic exchange.
Radically changes the situation compared to TWT and U-APSD, doesn't it?
And now an important nuance that you donβt immediately think about. The WUR does not have to operate on the same frequency as the main module. On the contrary, it is desirable and recommended that it work on a different channel. In this case, the 802.11ba functionality does not interfere with the network in any way, and vice versa can be used to send useful information. Location, Neighbor List, and more in other 802.11 standards such as 802.11k/v. And what advantages are opening up for Mesh networks ... But this is a topic for a separate article.
As for the fate of the standard itself as a document, then . That is, this year we can expect a real standard, or at least the first implementations. And how much it will spread - only time will tell.
Such things ... (c) .
Recommended literature for review:
Source: habr.com