Неотдавна в различни други ресурси и в собствения си блог споделих, че 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 изглежда по следния начин:
Нес-HT преамбула и краткий фрагмент OFDM с модуляцией 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 МГц из полосы 20 МГц… «ЭТО ЖЕ РАСТОЧИТЕЛЬСТВО!» — скажете вы и будете правы. Но нет, ВОТ НАСТОЯЩЕЕ РАСТОЧИТЕЛЬСТВО!
Стандарт предполагает возможность использования подканалов 40 МГц и 80 МГц. При этом битрейты каждого подканала могут отличаться, а для синхронизации времени передачи в конец фрейма добавляется Padding. То есть, устройство может занять эфирное время на всех 80 МГц, а использовать только 16 МГц. Вот это уже настоящее расточительство.
Кстати, у окружающих Wi-Fi устройств нет шансов понять, что именно транслируется в эфир. Потому что для кодирования 802.11ba фреймов НЕ используется привычный им OFDM. Да, альянс так смело отказался от того, что безотказно работало много лет. Вместо классического OFDM применяется модуляция Multi-Carrier (MC)-OOK. Канал 4 МГц делится на 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
