Не так давно на всяческих других ресурсах и в своем блоге я рассказывал о том что ZigBee мертв и стюардессу пора бы уже закопать. Для того чтобы делать хорошую мину при плохой игре с Thread, работающим поверх IPv6 и 6LowPan, достаточно более приспособленного для это Bluetooth(LE). Но об этом я расскажу как-нибудь в другой раз. Сегодня речь пойдет о том как в рабочей группе комитета упоролись хорошо подумали второй раз после 802.11ah и решили что настало время добавить в пулл стандартов 802.11 полноценный вариант чего-то вроде LRLP (Long-Range Low-Power) по аналогии с LoRA. Но это оказалось не реализуемо без того чтобы зарезать священную корову обратной совместимости. В итоге от Long-Range отказались и осталось только Low-Power, что тоже весьма хорошо. Получилась смесь 802.11 + 802.15.4 или по-простому Wi-Fi + ZigBee. То есть, можно сказать о том что новая технология не является конкурентом LoraWAN решениям, а наоборот создается для того чтобы их дополнять.
Итак, начнем с самого главного — Теперь в устройствах с поддержкой 802.11ba должно быть два радиомодуля. Видимо, посмотрев на 802.11ah/ax с их технологией Target Wake Time (TWT), инженеры решили что этого недостаточно и нужно радикально снизить энергопотребление. Для чего стандарт предусматривает разделение на два разных типа радио — Primary Communication Radio (PCR) и Wake-Up Radio (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 выглядит как-то так:
Non-HT преамбула и короткий фрагмент OFDM c модуляцией BPSK позволяет всем устройствам 802.11a/g/n/ac/ax услышать начало передачи этого кадра и не вмешиваться, уходя в режим прослушивания эфира. После преамбулы следует поле синхронизации (SYNC) по сути являющееся аналогом L-STF/L-LTF. Оно служит для того чтобы дать возможность подстроить частоту и синхронизировать приемник устройства. И вот именно в этот момент передающее устройство переходит на другую ширину канала в 4MHz. Зачем? Все очень просто. Это необходимо для того чтобы можно было снизить мощность и добиться сопоставимого отношения сигнала к мощности с шумом (SINR). Либо оставить мощность как есть и добиться значительного увеличения дальности передачи. Я бы сказал что это весьма элегантное решение, к тому же, позволяющее значительно снизить требования к источникам питания. Вспомним, например, народный ESP8266. В режиме передачи с использованием битрейта 54 Mbps и мощностью 16dBm он потребляет 196 mA, что запредельно много для чего-то вроде CR2032. Если в пять раз снизить ширину канала и в пять раз снизить мощность передатчика, то мы практически не потеряем в дальности передачи, но ток потребления получится кратно снизить, скажем, примерно до 50 mA. Не то чтобы это было критично именно со стороны AP которая передает фрейм для WUR, но всё равно неплохо. А вот для 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 устройств нет никаких шансов понять что там такое вещается в эфир. Потому что для кодирования 802.11ba фреймов НЕ используется привычный им OFDM. Да, вот так вот лихо альянс отказался от того что безотказно работало много лет. Вместо классического OFDM применяется модуляция Multi-Carrier (MC)-OOK. Канал 4MHz делится на 16(?) поднесущих, каждая из которых использует манчестерское кодирование. При этом само поле DATA еще и разделено логически на отрезки по 4 μs или 2 μs в зависимости от битрейта, а в каждом таком отрезке за единицу может отвечать низкий или высокий уровень кодирования. Такое вот решение для избежания длинной последовательности нулей или единиц. Скремблирование на минималках.
MAC уровень тоже запредельно упрощен. Он содержит только следующие поля:
- Frame Control
Может принимать значения Beacon, WuP, Discovery или любое другое на выбор вендора.
Beacon служит для синхронизации времени, WuP предназначены для пробуждения одного или группы устройств, а Discovery работает в обратную сторону от STA к AP и создан для поиска точек доступа, поддерживающих 802.11ba. Также в этом поле передается длина фрейма если он превышает 48 бит. - ID
В зависимости от типа фрейма может идентифицировать AP, либо STA или группу STA которым предназначается данный фрейм. (Да, можно будить устройства группами, это называется groupcast wake-ups и достаточно прикольно).
- Type Dependent (TD)
Довольно гибкое поле. Именно в нем может передаваться точное время, сигнал об обновлении прошивки/конфигурации с номером версии или что-то полезное о чем STA стоит знать.
- Frame Checksum Field (FCS)
Тут все просто. Это контрольная сумма
Но для того чтобы технология работала, мало просто отправить кадр нужного формата. STA и AP должны договориться. STA сообщает свои параметры, в том числе и время которое необходимо для инициализации PCR. Всё согласование происходит с использованием обычных фреймов 802.11, после чего STA может отключить PCR и перейти в режим активации WUR. А может даже и немного поспать, если есть такая возможность. Потому что если она есть, то лучше ею воспользоваться.
Дальше начинается еще небольшое выжимание драгоценных миллиампер часов под названием WUR Duty Cycle. Ничего сложного нет, просто STA и AP по аналогии с там как это было для TWT договариваются о расписании сна. После этого STA преимущественно спит, изредка включая WUR для того чтобы послушать «А не пришло ли чего-нибудь полезного для меня?». И только в случае необходимости пробуждает основной радиомодуль для обмена трафиком.
Радикально меняет ситуацию по сравнению с TWT и U-APSD, не правда ли?
А теперь важный нюанс о котором не сразу задумываешься. WUR не обязательно должен работать на той же частоте что и основной модуль. Наоборот, желательно и рекомендуется чтобы он работал на другом канале. В таком случае функциональность 802.11ba никаким образом не мешает работе сети и наоборот может использоваться для рассылки полезной информации. Location, Neighbour List и много всего другого в рамках других стандартов 802.11, например 802.11k/v. А уж какие преимущества открываются для Mesh сетей… Но это тема отдельной статьи.
Что касается судьбы самого стандарта как документа, то . То есть, в этом году можно ожидать самый настоящий стандарт или хотя бы первые реализации. А на сколько он получит распространение — это покажет только время.
Такие дела… (с) .
Рекомендуемая литература для ознакомления:
Источник: habr.com