Ei niin kauan sitten, useissa muissa lähteissä ja blogissani, puhuin siitä, että ZigBee on kuollut ja on aika haudata lentoemäntä. Jotta IPv6:n ja 6LowPanin päällä toimiva Thread toimii huonossa pelissä, riittää tähän sopivampi Bluetooth (LE). Mutta kerron tästä joskus toiste. Tänään puhumme siitä, kuinka komitean työryhmä päätti miettiä kahdesti 802.11ah:n jälkeen ja päätti, että oli aika lisätä täysimittainen versio jostain LRLP:n kaltaisesta (Long-Range Low-Power) 802.11-standardien joukkoon. LoRA:lle. Mutta tämä osoittautui mahdottomaksi toteuttaa ilman, että teurastettiin taaksepäin yhteensopivuuden pyhää lehmää. Tämän seurauksena Long-Range hylättiin ja vain Low-Power jäi jäljelle, mikä on myös erittäin hyvä. Tuloksena oli sekoitus 802.11 + 802.15.4 tai yksinkertaisesti Wi-Fi + ZigBee. Eli voidaan sanoa, että uusi teknologia ei ole LoraWAN-ratkaisujen kilpailija, vaan sitä päinvastoin luodaan täydentämään niitä.
Aloitetaan siis tärkeimmästä - Nyt 802.11ba:ta tukevissa laitteissa pitäisi olla kaksi radiomoduulia. Ilmeisesti tarkasteltuaan 802.11ah/ax:a sen Target Wake Time (TWT) -tekniikalla insinöörit päättivät, että tämä ei riittänyt ja heidän oli vähennettävä virrankulutusta radikaalisti. Miksi standardi sisältää jaon kahteen eri radiotyyppiin - Primary Communication Radio (PCR) ja Wake-Up Radio (WUR). Jos ensimmäisellä kaikki on selvää, tämä on pääradio, se lähettää ja vastaanottaa dataa, niin toisella se ei ole niin paljon. Itse asiassa WUR on enimmäkseen kuuntelulaite (RX) ja se on suunniteltu kuluttamaan hyvin vähän virtaa. Sen päätehtävänä on vastaanottaa herätyssignaali AP:lta ja mahdollistaa PCR. Tämä tarkoittaa, että tämä menetelmä vähentää merkittävästi kylmäkäynnistysaikaa ja antaa sinun herättää laitteet tiettyyn aikaan mahdollisimman tarkasti. Tämä on erittäin hyödyllistä, kun sinulla ei ole esimerkiksi kymmentä laitetta, vaan satakymmentä ja sinun on vaihdettava tietoja jokaisen kanssa lyhyessä ajassa. Lisäksi heräämisen taajuuden ja jaksoisuuden logiikka siirtyy AP:n puolelle. Jos esimerkiksi LoRAWAN käyttää PUSH-metodologiaa, kun toimilaitteet itse heräävät ja lähettävät jotain ilmassa ja nukkuvat loppuajan, niin tässä tapauksessa AP päinvastoin päättää milloin ja minkä laitteen pitäisi herätä, ja itse toimilaitteet... eivät aina nuku.
Siirrytään nyt kehysmuotoihin ja yhteensopivuuteen. Jos 802.11ah, ensimmäisenä yrityksenä, luotiin 868/915 MHz taajuuksille tai yksinkertaisesti SUB-1 GHz, niin 802.11ba on jo tarkoitettu 2.4 GHz ja 5 GHz taajuuksille. Aiemmissa "uusissa" standardeissa yhteensopivuus saavutettiin johdanto-osan avulla, joka oli ymmärrettävissä vanhemmille laitteille. Eli laskelma on aina ollut niin, että vanhempien laitteiden ei välttämättä tarvitse pystyä tunnistamaan koko kehystä, vaan niille riittää, että he ymmärtävät, milloin tämä kehys alkaa ja kuinka kauan lähetys kestää. Juuri nämä tiedot he ottavat johdannosta. 802.11ba ei ollut poikkeus, koska järjestelmä on todistettu ja todistettu (jätämme huomioimatta kustannuskysymyksen toistaiseksi).
Tämän seurauksena 802.11ba-kehys näyttää suunnilleen tältä:
Ei-HT-johdanto ja lyhyt OFDM-fragmentti BPSK-modulaatiolla sallivat kaikkien 802.11a/g/n/ac/ax-laitteiden kuulla tämän kehyksen lähetyksen alun ja olla häiritsemättä siirtyessään lähetyskuuntelutilaan. Alkuosan jälkeen tulee synkronointikenttä (SYNC), joka on olennaisesti L-STF/L-LTF:n analogi. Sen avulla on mahdollista säätää taajuutta ja synkronoida laitteen vastaanotin. Ja juuri tällä hetkellä lähettävä laite vaihtaa toiseen kanavan leveyteen 4 MHz. Minkä vuoksi? Kaikki on hyvin yksinkertaista. Tämä on välttämätöntä tehon pienentämiseksi ja vertailukelpoisen signaali-kohinasuhteen (SINR) saavuttamiseksi. Tai jätä teho ennalleen ja lisää lähetysaluetta merkittävästi. Sanoisin, että tämä on erittäin tyylikäs ratkaisu, jonka avulla voidaan myös vähentää merkittävästi virtalähteiden vaatimuksia. Muistakaamme esimerkiksi suosittu ESP8266. Lähetystilassa 54 Mbps:n bittinopeudella ja 16 dBm:n teholla se kuluttaa 196 mA, mikä on kohtuuttoman korkea esimerkiksi CR2032:lle. Jos pienennämme kanavan leveyttä viisinkertaisesti ja vähennämme lähettimen tehoa viisinkertaisesti, emme käytännössä menetä lähetysalueella, mutta virrankulutus pienenee kertoimella, vaikkapa noin 50 mA. Ei sillä, että tämä olisi kriittinen AP:lle, joka lähettää kehyksen WUR:lle, mutta se ei silti ole huono. Mutta STA:lle tämä on jo järkevää, koska alhaisempi kulutus mahdollistaa CR2032:n kaltaisten paristojen tai akkujen käytön, jotka on suunniteltu pitkäaikaiseen energian varastointiin pienillä nimellispurkausvirroilla. Mikään ei tietenkään tule ilmaiseksi ja kanavan leveyden vähentäminen johtaa kanavan nopeuden laskuun yhden kehyksen lähetysajan pidentyessä.
Muuten, kanavan nopeudesta. Nykyisessä muodossaan standardi tarjoaa kaksi vaihtoehtoa: 62.5 Kbps ja 250 Kbps. Tunnetko ZigBeen tuoksun? Tämä ei ole helppoa, koska sen kanavan leveys on 2Mhz 4Mhz:n sijaan, mutta erityyppinen modulaatio korkeammalla spektritiheydellä. Tämän seurauksena 802.11ba-laitteiden valikoiman pitäisi olla suurempi, mikä on erittäin hyödyllistä sisätilojen IoT-skenaarioissa.
Tosin, odota hetki... Pakotetaan kaikki alueen asemat olemaan hiljaa, samalla kun käytetään vain 4 MHz 20 MHz:n kaistasta... "TÄMÄ ON HAKALUA!" - sanot ja olet oikeassa. Mutta ei, TÄMÄ ON OIKEA JÄTE!
Standardi tarjoaa mahdollisuuden käyttää 40 MHz ja 80 MHz alikanavia. Tällöin kunkin alikanavan bittinopeudet voivat olla erilaisia, ja lähetysajan vastaamiseksi lisätään kehyksen loppuun täyttö. Eli laite voi varata lähetysaikaa kaikilla 80 MHz:llä, mutta käyttää sitä vain 16 MHz:llä. Tämä on todellista tuhlausta.
Muuten, ympäröivillä Wi-Fi-laitteilla ei ole mahdollisuutta ymmärtää, mitä siellä lähetetään. Koska tavallista OFDM:ää EI käytetä 802.11ba-kehysten koodaamiseen. Kyllä, juuri niin liittoutuma hylkäsi tunnetusti sen, mikä oli toiminut moitteettomasti monta vuotta. Klassisen OFDM:n sijaan käytetään Multi-Carrier (MC)-OOK-modulaatiota. 4 MHz:n kanava on jaettu 16(?) apukantoaaltoon, joista jokainen käyttää Manchesterin koodausta. Samalla myös itse DATA-kenttä on loogisesti jaettu bittinopeudesta riippuen 4 μs:n tai 2 μs:n segmentteihin, ja kussakin sellaisessa segmentissä alhainen tai korkea koodaustaso voi vastata yhtä. Tämä on ratkaisu pitkän nollien tai ykkösten sarjan välttämiseksi. Huijausta minimipalkoilla.
MAC-taso on myös erittäin yksinkertaistettu. Se sisältää vain seuraavat kentät:
- Kehyksen ohjaus
Voi ottaa arvot Beacon, WuP, Discovery tai mikä tahansa muu myyjän valitsema arvo.
Beaconia käytetään ajan synkronointiin, WuP on suunniteltu herättämään yksi tai joukko laitteita, ja Discovery toimii päinvastaisessa suunnassa STA:sta AP:hen ja on suunniteltu löytämään tukiasemia, jotka tukevat 802.11ba:ta. Tämä kenttä sisältää myös kehyksen pituuden, jos se ylittää 48 bittiä. - ID
Kehyksen tyypistä riippuen se voi tunnistaa AP:n tai STA:n tai STA:iden ryhmän, jolle tämä kehys on tarkoitettu. (Kyllä, voit herättää laitteita ryhmissä, sitä kutsutaan ryhmälähetysherätyksiksi ja se on aika siistiä).
- Tyyppiriippuvainen (TD)
Aika joustava ala. Siinä voidaan lähettää tarkka aika, signaali laiteohjelmiston/konfiguraatiopäivityksestä versionumerolla tai jotain hyödyllistä, josta STA:n pitäisi tietää.
- Kehyksen tarkistussummakenttä (FCS)
Täällä kaikki on yksinkertaista. Tämä on tarkistussumma
Mutta jotta tekniikka toimisi, ei riitä, että lähetät vain kehyksen vaaditussa muodossa. STA:n ja AP:n on oltava samaa mieltä. STA raportoi parametrinsa, mukaan lukien PCR:n alustamiseen tarvittavan ajan. Kaikki neuvottelu tapahtuu käyttämällä tavallisia 802.11-kehyksiä, minkä jälkeen STA voi poistaa PCR:n käytöstä ja siirtyä WUR-aktivointitilaan. Tai ehkä jopa nukkua, jos mahdollista. Koska jos se on olemassa, on parempi käyttää sitä.
Seuraavaksi tulee hieman enemmän arvokkaita milliampeeritunteja, nimeltään WUR Duty Cycle. Mikään ei ole monimutkaista, vain STA ja AP sopivat nukkumisaikataulusta analogisesti TWT:n tapaan. Tämän jälkeen STA enimmäkseen nukkuu ja kytkee toisinaan WUR:n päälle kuunnellakseen "Onko minulle tullut mitään hyödyllistä?" Ja vain tarvittaessa, se herättää pääradiomoduulin liikenteen vaihtoon.
Muuttaa tilannetta radikaalisti verrattuna TWT:hen ja U-APSD:hen, eikö niin?
Ja nyt tärkeä vivahde, jota et heti ajattele. WUR:n ei tarvitse toimia samalla taajuudella kuin päämoduulin. Päinvastoin, on toivottavaa ja suositeltavaa, että se toimii eri kanavalla. Tässä tapauksessa 802.11ba-toiminnallisuus ei millään tavalla häiritse verkon toimintaa ja päinvastoin sitä voidaan käyttää hyödyllisen tiedon lähettämiseen. Sijainti, naapuriluettelo ja paljon muuta muiden 802.11-standardien puitteissa, esimerkiksi 802.11k/v. Ja mitä etuja Mesh-verkoille avautuu... Mutta tämä on erillisen artikkelin aihe.
Mitä tulee sitten itse standardin kohtaloon asiakirjana . Eli tänä vuonna voimme odottaa todellista standardia tai ainakin ensimmäisiä toteutuksia. Vain aika näyttää kuinka laajalle se tulee.
Sellaisia asioita... (c) .
Suositeltavaa luettavaa:
Lähde: will.com