Не так даўно на ўсялякіх іншых рэсурсах і ў сваім блогу я распавядаў аб тым што 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 ўзровень таксама залімітава спрошчаны. Ён змяшчае толькі наступныя палі:
- Кадр кіравання
Можа прымаць значэння 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