LoRaWAN, enkelt förklarat

Hjojohan Okategoriserade

LoRaWAN står för Long Range Wide Area Network. Det är en standard för trådlös kommunikation som gör det möjligt för IoT-enheter att kommunicera över stort avstånd med minimal batterianvändning. Vid skrivandet av denna artikel fann jag att information om LoRa var ganska sparsom eller alltför komplicerad. Eftersom det tog mig tid att verkligen räkna ut vad LoRa är och hur det fungerar bestämde jag mig för att skapa detta inlägg och försöka förklara LoRaWAN på ett tekniskt men enkelt begripligt sätt.

LoRa eller LoRaWAN

Termen LoRa och LoRaWAN används ofta på ett blandat sätt men per definition är det en skillnad. LoRa definierar standarden för den fysiska (lager 1) standarden, LoRaWAN definierar allt som plus MAC-lagret och tillämpningsstandarderna.

LoRaWAN är en trådlös kommunikationsstandard. Du kan lägga den i samma kategori av Bluetooth, GSM, 3G, LTE, men det är fortfarande annorlunda. Den har din mobiltelefons utbud med flexibiliteten hos Bluetooth eller WiFi och batterilivslängden på din klocka för kostnaden för en öl.

De viktigaste egenskaperna hos LoRaWAN är:

  • Long range (> 5 km i städer,> 10 km förort,> 80 km frisikt)
  • Lång batteritid (> 10 år)
  • Låg kostnad (<$ 5 / modul)
  • Låg datahastighet (0,3 bps – 50 kbps, vanligtvis ~ 10 kB / dag)
  • Säkrer och krypterad kommunikation
  • Fungerar i olicensierat spektrum 868 Mhz
  • Lokaliseringsstöd via RSSI mätning( triangulering av position )
  • Dubbelriktad kommunikation
  • Som du kan se i listan över egenskaper låter allt enastående förutom när vi tittar på datahastigheten. Tyvärr är fysiskt begränsad, trådlös kommunikation alltid en avvägning mellan avstånd, hastighet och kraft (energi). LoRa designades med användarfall i åtanke där den här datahastigheten skulle räcka och de andra egenskaperna är betydligt viktigare.

    LoRaWAN designades också med stora tjänsteleverantörer i åtanke. Precis som med mobilnätverket: några operatörer som underhåller och kontrollerar nätverket och miljontals användare som utnyttjar nätverket och inte behöver bry sig om infrastrukturen. Eftersom LoRa är verksamt i olicensierat spektrum är det dock fullt möjligt att ställa in egna portar, få en täckning på några kilometer och driva ett eget nätverk för några 1000 kronor. Som tidigare nämnts möjliggör LoRa låg effekt, lång räckvidd men låg datahastighet. Typiska användningsfall finns i IoT (Internet of Things), IoE (Internet of Everything) eller M2M (Machine to Machine) -området. Vi tittar vanligtvis på (små) sensorer / enheter / saker som är batteridriven och kommunicerar begränsad information om ett begränsat intervall.

    Några exempel på användningsområden:

    Mätning:
    Skickar 1 till 5 meddelanden om dagen om den aktuella användningen
    Till exempel: gas / vatten / el
    > 10 år på batteriet

    Smart parkering:
    Skickar ett meddelande när ett fordon anländer eller lämnar en parkeringsplats
    Kan kombineras med en app för att hitta en fri parkeringsplats
    Ingen kabeldragning krävs, lågt underhåll

    Smarta sopkärl:
    Skickar ett meddelande när en papperskorgen är full
    Optimera rutt för insamling, spara arbete och bränsle

    Smart belysning:
    Ställ in trafikljus och status

    Miljöövervakning
    Till exempel: ljud, temperatur, förorening, strålning, fuktighet, …
    Skapa värdefulla insikter i kombination med geolocation

    Assetmanagement/förvaltning
    Kontrollera status och plats för olika tillgångar
    Styrreläer, lås, ljus, av/på, öppet/stängt …

    Sjukvård
    Till exempel: aktivitet / fall upptäckt, personligt larm, övervakning
    Inget behov av laddning, bra nätverksdäckning

    spårning
    Spåra varor, fordon, djur

    Arkitektur
    Från en hög nivå ser arkitekturen av ett typiskt LoRa-nätverk ut som följande:

    Enheter -> LoRa-radio -> Gateway -> 3G / Ethernet -> Nätverksserver -> Applikation

    För uppströms meddelanden, till exempel en sensor som skickar information till en applikation, är flödet från vänster till höger. Sensorns värde (nyttolast) blir krypterad och överförs via LoRa-radio. En eller flera gateways tar emot meddelandet och vidarebefordrar det via ett annat nätverk (vanligtvis 3G eller Ethernet) till en nätverksserver. Nätverksservern skicakar meddelandet till rätt slutprogram. För nedströms meddelanden, till exempel en signal för att slå på en lampa, är flödet från höger till vänster. Uppströms meddelanden initieras av själva apparaten och nedströms av slutanvändningen. Eftersom LoRa är konstruerad med så låg energianvändning som möjligt, lyssnar inte alla enheter alltid på inkommande meddelanden. Det beror på enhetsklasserna

    LoRa enheter
    LoRaWAN-enheter kan vara allt som skickar eller mottar information, det finns ingen riktig definition för dem men vanligtvis talar vi om sensorer, detektorer, manöverdon.

    Några exempel på enheter:

    Adeunis LorRaWAN demonstrant (http://www.adeunis-rf.com/sv/products/lorawan-products/lorawan-demonstrator-by-adeunis-rf)
    Detta är en anordning för att minska LoRa
    GPS / Temperatur / Accelerometer sensor
    Självgående och uppladdningsbara
    NKE Watteco smartplug
    Möjlighet att slå på / av ansluten enhet
    Mäter kraft, spänning och frekvens
    Abeeway
    Raspberry Pi eller Ardunio
    Kombinerad med sensorer: temperatur, tryck, fuktighet, ljus, ljud, GPS-läge, accelerometer, rörelsedetektor, luftkvalitet, mangetisk brytare, …

    ‘XXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    LoRa klasser
    A: Kan bara ta emot ett meddelande när enheten skickar ett meddelande
    B: Samma som A men lyssnar på inkommande meddelanden med jämna mellanrum
    C: Lyssnar kontinuerligt efter inkommande meddelanden
    Logiskt kan klass A-enheter vara det längsta batteriet och klass C-enheter är vanligtvis inte batteridriven.

    LoRaWAN-standarden beskriver två olika typer av meddelanden: MAC-meddelanden, för att styra radio- och nätverks- och datameddelanden, den faktiska nyttolasten som är applikation / enhetsspecifik. Eftersom vi är begränsade i tid och antal meddelanden som vi kan skicka över luften, kan MAC-meddelanden vara piggybacked (skickas ihop) med data-meddelanden och flera MAC-meddelanden kan skickas på en gång.

    Enhetsadressering
    Som med de flesta nätverksstandarder behöver enheter någon typ av adress och identifiering för att kunna kontakta dem och skilja dem från varandra. LoRa använder följande adressering.

    DevEUI: Enhetens unika hårdvaru-ID: 64 bitars adress. Jämförbar med MAC-adresser för en TCP / IP-enhet.
    DevAddr: Enhetsadress: 32 bitars adress tilldelad eller vald specifik på nätverket. Jämförbar med en IP-adress för en TCP / IP-enhet.
    AppEUI: Applikations-ID: EUI64-adressformat. Identifierar enhetens applikationsleverantör unikt. Sedan lagras AppEUI i slutenheten innan aktiveringsproceduren körs.
    Fport: identifierar slutansökan / tjänsten. Port 0 är reserverad för MAC-meddelanden. Jämförbar med ett TCP / UDP portnummer för en TCP / IP-enhet.

    LoRa-radio
    LoRa använder RF-signaler för att kommunicera. Det fungerar i olicensierat spektrum. Det innebär att alla kan använda detta band fritt utan att betala eller få en licens så länge som du följer några regler. Speciellt arbetar LoRa i ISM (Industrial, Science, Medical) -bandet. Tyvärr är områdena i ISM-bandet olika geografiskt. För att uppnå målen för LoRa när det gäller intervall och datahastighet används följande frekvenser: Europ: 868Mhz och 433 MHz, USA: 915Mhz och AS: 430 MHz. Det är uppenbarligen att detta gör portar och enheter för Europa oförenliga med de som tillverkas för USA, etc. En stor nackdel för LoRa om du frågar mig.

    LoRa använder olika tekniker för att förbättra datasäkerheten. Jag nämner de viktigaste:

    Spread Spectrum: Detta är en teknik som ursprungligen designades för militära applikationer där den faktiska informationen (till exempel en bit) sprids över en större frekvens. Genom att göra detta är signalen till brusration mycket liten och signalen (den skickade biten) är mycket mer resistent mot störningar, störningar eller störningar.
    ADR: Adaptiv datahastighet: Dynamiskt ändra datahastighet och sändningseffekt i funktion av signalkvaliteten och avståndet till gatewayen. Långsam överföring (högre spridningsfaktor) möjliggör ett längre och mer pålitligt intervall:

    FEC: Forward Error Correction: Add redundant information (recovery/parity bits) to each message to be able to correct small errors.
    Gateway
    The gateway, also called modem or access point, is the device that is receiving all LoRa radio sent by the devices in it’s range. By design, there isn’t really a association between a device and a specific LoRa gateway. Every gateway in the range of the RF signal sent out by a device will pick up the signal and process it, even if this LoRa gateway is part of a network that doesn’t know the device that sent the message.

    Some examples of LoRa gateways currently available:

    Kerlink LoRa IoT station:

    Nätverksserver
    När en enhet skickat ett meddelande som mottogs av en LoRa-gateway, kommer det troligtvis att vidarebefordras till en nätverksserver. Denna komponent är den mest intelligenta delen i LoRaWAN-nätverket. Nätverksservern ansvarar för följande taks:

  • Sammanfoga inkommande data från alla LoRaWAN-gateways i det nätverk och alla sensorer inom deras intervall.
  • Rutt / vidarebefordra inkommande meddelanden till rätt slutanvändning
  • Contral LoRa radion konfiguration till portarna
  • Välj den bästa gatewayen för nedlänksmeddelande om flera gatewayer ligger inom en enhet
  • Nedlänksbuffert: lagra meddelanden tills en LoRa-klass A- eller B-enhet är redo att ta emot ett meddelande
  • Ta bort dubbletter: eftersom det inte finns någon koppling mellan enhet och gateway finns det en god chans att flera gateways tar upp samma meddelande så dulicates måste filtreras
  • Övervaka enheter och gateways
  • Några exempel på Network LoRa Servers:

    TheThinksnetwork : https://www.thethingsnetwork.org/
    ActilityThingpark: https://www.actility.com/products/
    Loraserver: https://github.com/brocaar/loraserver
    Semtech: https://semtech.force.com/lora

    I de flesta fall kommer nätverksservern att vidarebefordra meddelandet från en viss id och fport-kombination till en fördefinierad applikation. Vanligtvis görs detta antingen genom att vidarebefordra det till en HTTP(S) webservice eller lägga in den i en MQTT-kö.

    Ansökan
    Sista objektet i flödet eller arkitekturen är den aktuella applikationen. Det här är den applikation som tillverkaren eller utvecklaren skriver för att analysera meddelanden som skickas av enheterna som är relevanta för den här applikationen. Denna applikation använder den faktiska data (nyttolast) som skickas av enheten och tolkar / använder den.

    Säkerhet
    Som jag nämnde i början av denna artikel är LoRaWAN utformad med säkerhet i åtanke. För mig personligen var det en av de svårare delarna eller LoRaWAN att förstå, även om jag inte är helt ny på detta. Grundidén är att kommunikationen ska vara säker på flera nivåer. En nätverksserver behöver inte kunna läsa det faktiska innehållet i meddelandet om det inte är relevant för nätverket eller infrastrukturen. Därför finns det två olika nycklar i bilden under normal meddelandeutbyte:

    Nätverkssessionstangenten (NwkSKey) används för att kryptera hela ramen (rubriker + nyttolast) om ett MAC-kommando skickas. När data skickas används den här tangenten för att signera meddelandet som gör det möjligt för nätverksservern att verifiera avsändarens identitet
    Programsessionstangenten (AppSKey) används för att kryptera nyttolasten i ramen. Den här nyckeln behöver inte vara känd av nätverksservern för att kunna veta vart man ska vidarebefordra meddelandet till. Applikationsservern dekrypterar sedan informationen med samma nyckel.

    Säkerhet: ansluta mot nätverketet
    Fram till här är saker fortfarande ganska förståeligt, men det sätt som en enhet kan ansluta till nätverket gör det mer komplicerat. Eftersom du inte vill ha det för varje ansökan / användarfall, att användaren är ansvarig för att konfigurera nätverksåtkomst / abonnemang / tjänsteleverantörsval men du vill inte heller att någon typ av enhet ska vara kopplad till ett visst nätverk är det i princip två sätt att aktivera en enhet på ett LoRa-nätverk.

    Målet med denna aktiveringsprocess är att få en NwkSKey, AppSKey och NwkAddr. När dessa är mottagna eller konfigurerade är resten av kommunikationen exakt densamma för båda aktiveringsmetoderna.

    Aktivering genom personalisering (ABP)
    ABP är det enklaste sättet att aktivera en LoRa-enhet i ett nätverk. Med ABP överensstämmer leverantören av enheten med nätoperatören och köper / reserverar en rad DevAddr från en nätoperatör och förutbeställer sina enheter med detta. När enheten är påslagen är den omedelbart redo att skicka data. Det finns ingen air join process

    Steg att ta:

  • Tillverkare av leverantör av LoRa-enhet köper anslutning från nätoperatören. AppSKey genereras i förväg.
  • Tjänsteleverantören levererar en NwkSKey och DevAddr för varje DevEU.
  • Innan du skickar enheter, är de förbehandlade med: NwkSKey, AppSKey och DevAddr
  • Vid första användningen är det inte nödvändigt att ansluta sig till nätverket och enheten kan kommunicera omedelbart eftersom de redan vet den nödvändiga informationen
  • Över luftaktivering (OTAA)
    OTAA är lite mer komplicerat men tillåter enheter att ansluta sig till något nätverk inom intervallet och kräver ingen särskild överenskommelse mellan nätoperatören och enhetsleverantören. Som med ABP är målet med processen att bli NwkSKey, DevAddr och AppSKey för varje enhet innan den skickar faktiska data.

    För att hämta denna information på ett säkert sätt är det en extra nyckel som är förbehandlad i enheten: Appkey. Personligen finner jag namnet mycket förvirrande eftersom det är ungefär som AppSKey. Appkey är en annan 128 bitars nyckel.

    Steg i OTAA-anslutningsprocessen:

    LoRa Device skickar JOIN_REQUEST (signerad med AppKey). Anslutningsförfrågan innehåller följande information: AppEUI, DevEUI, DevNonce.
    DevNonce är ett slumpmässigt genererat nummer.
    Nätverksservern tar emot JOIN_REQUEST och beräknar AppSKey och NwkSKey baserat på: AppKey, AppNonce, NetID och DevNonce.
    Som med DevNonce är AppNonce ett annat slumpmässigt genererat nummer.
    Nätverksserver genererar JOIN_ACCEPT och innehåller AppNonce
    Enheten tar emot JOIN_ACCEPT (krypterad med AppKey). JOIN_ACCEPT innehåller följande information: AppNonce, NetID, DevAddr, RFU, RxDely, CFList
    Eftersom både Network Server och LoRa-enheten har samma information, kan LoRa-enheten på samma sätt beräkna NwkSkey och AppSKey
    Om du läser noga kan du se att ingen framsteg i hela framstegen skickas över luften, men endast de saknade delarna av en beräkning, från båda sidor bytas ut. Detta gör det omöjligt att generera någon nyckel genom att avlyssna trafik över luften.

    Alla ovanstående förklaringar är långt ifrån fullständiga men jag hoppas att min korta förklaring av den ger en bättre förståelse för denna teknik. Jag ska försöka lägga till några klargöranden och / eller diagram / scheman inom en snar framtid.