Нещодавно на всіляких інших ресурсах і в своєму блозі я розповідав про те, що 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 з модуляцією 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 рівень теж дуже спрощений. Він містить лише такі поля:
- Керування кадрами
Може приймати значення 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