Неотдавна в различни ресурси и в блога си споделих, че 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 изглежда по следния начин:
Нехарактерната преамбула и краткият фрагмент 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 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
