LoRaWAN sensornätverk för tillförlitlig datakommunikation och lång batteritid på sensorer

1. Introduktion

Den snabba tillväxten av Internet of Things (IoT) driver en ökad efterfrågan på tillförlitliga och energieffektiva trådlösa kommunikationslösningar som klarar långa räckvidder. LoRaWAN (Long Range Wide Area Network) har etablerat sig som en ledande teknologi inom LPWAN (Low-Power Wide-Area Network), utvecklad för att möjliggöra överföringar med låg bithastighet över stora avstånd. Genom att verka i olicensierade frekvensband erbjuder LoRaWAN flexibla och kostnadseffektiva möjligheter inom en mängd olika branscher, från smarta städer och jordbruk till industriell övervakning och byggnadsautomation.

Att implementera ett framgångsrikt LoRaWAN-nätverk kräver dock noggrann hantering av flera faktorer som påverkar prestanda och batterilivslängd hos anslutna enheter. Typiska utmaningar inkluderar förståelse för nätverkets topologi, hantering av signalstyrkemätningar (såsom RSSI och SNR) samt att motverka och hantera störningar, både från miljön och andra radiosändare.

För att uppnå pålitlig drift och maximera sensorns batterilivslängd är det avgörande att användare av LoRaWAN får goda kunskaper om teknikens grundläggande funktioner och bästa praxis för drift.

Syftet med detta white paper är därför att:

Förklara grunderna: Presentera nyckelbegrepp inom trådlös kommunikation och LoRaWAN-drift, inklusive nätverkstopologi, arkitektur och kommunikationsprinciper.

Utforska radiosignalers utbredning i verkliga miljöer, inklusive begrepp som länkbudget, störningar och dämpning, särskilt med avseende på moderna energitäta byggnader som kan reflektera eller dämpa signaler betydligt.

Beskriva hur batteridrivna LoRaWAN-sensorer kan konfigureras och optimeras för att uppnå lång batterilivslängd genom kvalitetssäkring av nätverkets prestanda.

Ge praktiska rekommendationer för nätverksplanering, konfiguration av sensorer samt felsökning, för att hjälpa användare maximera täckning, tillförlitlighet och energieffektivitet.

Genom att kombinera dessa områden fungerar detta dokument både som en introduktion för nya användare och som en praktisk referensguide för mer erfarna användare. I takt med att IoT-lösningar blir allt vanligare inom olika sektorer är förståelsen av samspelet mellan nätverksinfrastruktur, radiomiljö och sensorinställningar central för att skapa skalbara, kvalitativa och långsiktigt hållbara IoT-system.

2. Trådlös anslutning

Moderna kommunikationsnätverk använder i allt större utsträckning trådlös teknik för att ansluta allt från smartphones och bärbara datorer till IoT-sensorer och industrimaskiner. Övergången från traditionella trådbundna anslutningar drivs av flera viktiga fördelar:

Flexibilitet: Trådlösa lösningar möjliggör placering av enheter på platser där kabeldragning är opraktiskt eller kostsamt.

Skalbarhet: Att lägga till nya enheter i ett trådlöst nätverk är vanligtvis snabbare och enklare än installation av nya nätverkskablar, vilket är särskilt viktigt i större IoT-installationer med hundratals eller tusentals enheter.

Mobilitet: Enheter som kräver fri rörlighet, såsom drönare, mobila robotar och bärbar teknik, är beroende av trådlös kommunikation för kontinuerlig anslutning utan fysiska begränsningar.

Trots dessa fördelar finns det inget universellt trådlöst protokoll som passar alla scenarier. Valet av radioteknik beror på specifika krav som datamängd, räckvidd, energiförbrukning och latens. Exempelvis:

Tillämpningar med hög bandbredd och kort räckvidd, som videoströmning eller realtidskommunikation, använder ofta protokoll som Wi-Fi eller mobila nätverk (4G/5G). Dessa tekniker erbjuder hög prestanda men kräver högre effekt, vilket påverkar batteritiden negativt.

IoT-sensorer med låg energiförbrukning och lång räckvidd, exempelvis för fjärrövervakning, är beroende av protokoll som LoRaWAN, Sigfox eller NB-IoT. Dessa erbjuder låg datahastighet men utmärkt batterilivslängd och räckvidd.

Lokala mesh-nätverk och automationssystem, till exempel inom hemautomation och industriell styrning, använder ofta tekniker som Zigbee, Z-Wave eller Bluetooth Mesh, som erbjuder låg till medelhög datahastighet samt multi-hop-kommunikation.

Valet av det mest lämpade trådlösa protokollet innebär att noggrant väga faktorer som räckvidd, energiförbrukning, datahastighet, latens och nätverkskomplexitet. Varje användningsområde – från konsumentelektronik och industriell automation till jordbruksövervakning och smart stadsinfrastruktur – har specifika krav som måste mötas för optimal funktion.

I detta kapitel kommer vi att utforska nätverkstopologier, signalegenskaper och störningar i detalj för att hjälpa användare att förstå och effektivt designa robusta trådlösa nätverk som uppfyller de unika kraven i olika användningsfall.

2.1 Nätverkstopologier

Trådlösa nätverk kan delas in i olika topologier, där var och en har kompromisser vad gäller täckning, skalbarhet, feltolerans och komplexitet. Nedan beskrivs några av de vanligaste trådlösa nätverkstopologierna.

En bild som visar diagram, linje, skärmbild

AI-genererat innehåll kan vara felaktigt.

2.1.1 Stjärntopologi

I en stjärntopologi kommunicerar alla slutenheter (t.ex. sensorer, noder) direkt med en central koordinator eller gateway. Gatewayen dirigerar data mellan varje nod och det bredare nätverket.

Fördelar

Enkelhet: Enkel design där varje nod ansluter till en central punkt.

Enkel distribution: Att lägga till eller ta bort noder kräver minimal konfigurationsändringar.

Kortare svarstid: Data överförs direkt från noden till en gateway.

Nackdelar

Enskild felpunkt: Om den centrala gatewayen misslyckas går kommunikationen till alla noder förlorad.

Begränsad täckning: Noder måste befinna sig inom direkt räckhåll från en gateway.

Typiska användningsfall

LoRaWAN

Wi-Fi-hotspots

Enklare sensornätverk

2.1.2 Mesh-topologi

I en mesh-topologi kan vissa noder också fungera som routrar och vidarebefordra data mellan varandra och bildar ett sammanhängande nätverk.

Fördelar

• Hög feltolerans: Trafiken kan omdirigeras vid fel på en nod eller länk.
• Utökad täckning: Möjlighet till stora avstånd mellan noder tack vare multi-hop-kommunikation.
• Skalbarhet: Fler noder stärker nätverkets robusthet.

Nackdelar

• Komplexitet: Routningsalgoritmer och synkronisering blir mer avancerade.
• Högre effektförbrukning: Noder måste vara aktiva för att vidarebefordra trafik..
• Fördröjningar: När fler hopp är inblandade kan svarstiden och dataflödet påverkas.

Typiska användningsfall

• Zigbee, Z-Wave och Bluetooth Mesh
• Smarta hem och industriella nätverk

2.1.3 Trädtopologi

En trädtopologi är en hierarkisk struktur där en central rot-nod kommunicerar med mellanliggande noder (routrar) som i sin tur ansluter slutenheter.

Fördelar

• Strukturerad expansion: Grenar kan läggas till för att utöka täckningen.
• Hanterat trafikflöde: Tydlig hierarki underlättar trafikroutning.

Nackdelar

• Sårbarhet: Ett routerfel påverkar alla dess underordnade noder.
• Komplex samordning: Huvudnoden måste hantera hela hierarkin.

2.1.4 Peer-to-peer-topologi (ad hoc)

I en peer-to-peer-topologi kommunicerar enheter direkt med varandra utan en central koordinator.

Fördelar

• Inget centralt beroende, enheter kommunicerar direkt med varandra.
• Flexibelt.

Nackdelar

• Begränsad skalbarhet: Fler noder kan snabbt öka komplexiteten.
• Routningskomplexitet

Typiska användningsfall

• Bluetooth mellan två enheter.
• Ad hoc-nätverk för snabba insatser i fält eller vid nödsituationer.

2.1.5 Hybrida metoder

Hybridtopologier kombinerar flera topologier för ökad flexibilitet och robusthet, till exempel LoRaWAN-stjärnor kopplade via mesh eller punkt-till-punkt-länkar inom ett trädnätverk.

2.2 Signal, brus och störningar

Trådlös prestanda påverkas av betydligt mer än endast sändarens effekt, mottagarens känslighet och avståndet mellan sändare och mottagare. Faktorer som dämpning eller reflektioner av signalen och olika störningar har mycket stor betydelse för nätverkets tillförlitlighet och effektivitet.

Nyckeltal som RSSI och SNR hjälper till att kvantifiera länkkvaliteten för att optimera ett nät.

2.2.1 Indikator för mottagen signalstyrka (RSSI)

RSSI (Received Signal Strength Indicator) mäter den totala mottagna signalstyrkan vid mottagaren, ofta uttryckt i dBm. Värdet inkluderar både den önskade signalen, närliggande brus och störningar inom mottagarens bandbredd.

Ett högre RSSI-värde innebär generellt starkare mottagen signalstyrka, vilket kan vara fördelaktigt.

En hög RSSI garanterar dock inte alltid tillförlitlig kommunikation, särskilt om en stor del av signalstyrkan utgörs av störningar snarare än den önskade signalen.

Det är viktigt att mäta och förstå RSSI både vid sensorerna och vid gatewayen. Skillnader mellan dessa mätpunkter kan avslöja kritiska aspekter av den dubbelriktade kommunikationens kvalitet och ge värdefulla insikter för optimering av nätverkets prestanda.

2.2.2 Signal-brusförhållande (SNR)

SNR (Signal-to-Noise Ratio) jämför styrkan hos den önskade signalen med nivån på det underliggande brusgolvet, uttryckt i dB. Brusgolvet består av slumpmässigt brus (vitt brus) samt eventuella specifika störningar. Viktiga aspekter med SNR inkluderar:

• En högre SNR leder generellt till bättre möjlighet för mottagaren att urskilja och avkoda datasignalen från bakgrundsbruset.
• Lägre paketfelfrekvens: Minskad risk för felaktiga eller borttappade paket, vilket innebär färre återsändningar och lägre energiförbrukning.
• Ett lågt eller negativt SNR, även om RSSI är högt, tyder på att kanalen är utsatt för kraftiga störningar, vilket försämrar länkkvaliteten och ökar risken för kommunikationsproblem.

Att förstå både RSSI och SNR är centralt för att hantera signalmiljön och säkerställa robust och effektiv trådlös kommunikation.

2.2.3 Störningar

Störningar är signaler från andra sändare eller källor som överlappar i frekvens eller timing och därmed försämrar den trådlösa prestandan. Vanliga störningstyper inkluderar:

• Samkanalsstörningar: Uppstår när flera enheter eller nätverk använder samma eller närliggande frekvens samtidigt. Exempel inkluderar RFID-baserade passagesystem och trådlösa kameror som använder ISM-bandet.
• Andra störkällor: Elektriska apparater såsom elmotorer, kraftomvandlare och särskilt mobilbasstationer som använder 800 MHz-bandet (LTE-band 20). Dessa kan höja brusgolvet eller överstyra mottagaren och därigenom försämra kvaliteten på LoRaWAN-kommunikationen på 868 MHz-bandet.

2.2.4 Påverkan på trådlös prestanda

När mottagaren påverkas mer av brus eller störningar än den önskade signalen – det vill säga när SNR är lågt – kan följande problem uppstå:

• Ökat behov av återsändningar och reducerade datahastigheter: Systemet tvingas använda lägre modulationshastigheter och upprepade sändningar för att bibehålla kommunikationens tillförlitlighet.
• Försämrad räckvidd och täckning: Trots att enheten är inom det fysiska täckningsområdet kan kraftigt brus eller störningar hindra effektiv kommunikation.
• Högre energiförbrukning: Batteridrivna sensorer och enheter behöver öka sändningseffekten, sänka datahastigheten eller göra fler försök för framgångsrik kommunikation, vilket leder till snabbare batteriförbrukning och kortare batterilivslängd.
• Förlorade datapaket: Ökad mängd tappade eller förlorade datapaket på grund av störningar och brus, vilket leder till mindre tillförlitlig kommunikation.

3: Grunderna i LoRaWAN

LoRaWAN är ett LPWAN-protokoll (Low Power Wide Area Network) utvecklat för IoT-tillämpningar med låga datahastigheter, stor geografisk täckning och lång batterilivslängd. LoRaWAN utvecklas och underhålls av LoRa Alliance och används främst i stora IoT-nätverk där låg datahastighet och lång batterilivslängd är avgörande. Till skillnad från cellulära nätverk använder LoRaWAN olicensierade frekvensband, vilket gör det kostnadseffektivt och enkelt att implementera över stora geografiska områden.

I detta kapitel introduceras LoRaWAN:s fundamentala komponenter, såsom dess nätverksarkitektur, signalegenskaper och datarate-strategier. Att förstå dessa grundläggande principer är avgörande för att framgångsrikt implementera robusta, skalbara och energieffektiva LoRaWAN-nätverk.

3.1 Arkitektur

LoRaWAN bygger på en stjärntopologi där arkitekturen huvudsakligen består av tre komponenter:

• Slutenheter (sensorer eller noder) som kommunicerar direkt med gateways via LoRa-modulering.
• Gateways, som tar emot signaler från sensorerna och vidarebefordrar dessa via IP-baserad backhaul (Ethernet, mobilnät eller annan teknik).
• En central nätverksserver som hanterar och samordnar nätverkets säkerhet, paketdirigering och kommunikation med slutenheterna. Alla gateways inom räckhåll för en sensor kan vidarebefordra data till nätverksservern, vilket förbättrar redundans och tillförlitlighet.

3.1.1 Centrala komponenter

Slutenheter (noder, sensorer och aktuatorer)

• Batteridrivna enheter som använder LoRa-modulering för att skicka och eventuellt ta emot data.
• Klassificeras i tre driftklasser (A, B eller C) som avgör när och hur enheten lyssnar efter nedlänksmeddelanden (se avsnitt 5.1).

Gateways

• Agerar brygga mellan LoRaWAN-enheterna och nätverksservern.
• Kan samtidigt lyssna på flera kanaler och olika datahastigheter. Varje gateway som mottar en signal från en slutenhet vidarebefordrar denna till nätverksservern.
• Vidarebefordrar också styrdata från nätverksservern till slutenheter, inklusive konfiguration och bekräftelser.

Nätverksserver

• Central komponent som hanterar dirigering av meddelanden, säkerhetsfunktioner och enhetshantering.
• Tar bort dubbletter vid mottagning av samma meddelande från flera gateways och väljer den bästa vägen för eventuell nedlänk.
• Verifierar att endast autentiserade enheter kan delta i nätverket och säkerställer meddelandets integritet.
• IoT-plattform/IoT applikation
• Integrerad med en LoRaWAN applikationsserver.
• Innehåller den applikationsspecifika logiken och är ansvarig för behandling, visualisering eller lagring av data från slutenheter.
• Kommunicerar med nätverksservern via säkra gränssnitt och API:er.
• Hanterar även nedlänkmeddelanden för att styra aktuatorer och enheter genom nätverksservern.

3.1.2 Krypterad kommunikation

LoRaWAN säkerställer datakonfidentialitet och integritet genom end-to-end-kryptering:

• Två sessionsnycklar: NwkSKey (Network Session Key) skyddar nätverksadressen och säkerställer integritet, medan AppSKey (Application Session Key) krypterar själva data.
• Upplänk (enhet → gateway → nätverksserver): Data krypteras med AppSKey och meddelandeintegriteten säkerställs med NwkSKey.
• Nedlänk (nätverksserver → gateway → enhet): Endast avsedd enhet kan dekryptera och validera meddelandet, vilket säkerställs genom omvänd kryptering och integritetsvalidering.
• Dataskydd: Förhindrar effektivt avlyssning och manipulering, vilket möjliggör användning även över delade eller offentliga nätverk.

3.1.3 Översikt över dataflöde

• Upplänk (Broadcast): Slutenheten sänder ett LoRa-paket på vald frekvens och datahastighet.

• Gateway-mottagning: Alla gateways inom räckvidd tar emot meddelandet och vidarebefordrar det till nätverksservern via IP-baserad backhaul.

• Bearbetning av nätverksserver:

  • Eliminerar duplicerade meddelanden.
  • Validerar meddelandets integritet med NwkSKey.
  • Dekrypterar data med AppSKey vid behov och vidarebefordrar till IoT-plattformen/applikationens applikationsserver.

• IoT-plattformen: Bearbetar data, lagrar information och kan generera nedlänkskommandon.

• Nedlänk: Kommandon och data från IoT-plattformen skickas via nätverksserver och gateways tillbaka till slutenheten, som ensam kan dekryptera och validera meddelandet.

3.2 Signalerings- och kodningsscheman

LoRaWAN bygger på LoRa-modulering, en form av Chirp Spread Spectrum (CSS), vilket innebär att en smalbandssignal sprids över ett brett frekvensområde. Detta ger en mycket hög mottagarkänslighet och god motståndskraft mot störningar, vilket gör LoRaWAN optimalt för lågeffekts- och långdistanskommunikation.

---

3.2.1 Chirp Spread Spectrum (CSS)

En chirp är en signal vars frekvens kontinuerligt förändras över tid inom ett givet frekvensband.

LoRa använder olika spridningsfaktorer (SF) där högre SF ger högre mottagarkänslighet men lägre datahastighet.

3.2.2 Felkorrigering (FEC)

LoRaWAN använder framåtriktad felkorrigering (FEC) med kodningshastigheter (4/5 till 4/8) för att korrigera felaktiga bitar utan omsändningar.

3.2.3 Bandbredd och symbolhastighet

Bandbredden är vanligtvis 125, 250 eller 500 kHz, vilket påverkar symbolhastigheten.

Större bandbredd ger högre datahastighet men kortare räckvidd och känslighet.

3.2.4 Motståndskraft och lång räckvidd

CSS och FEC i kombination ger LoRaWAN stor räckvidd även vid låg effekt.

Signaler kan fortfarande detekteras även under brusgolvet.

3.2.5 NB_Trans (upprepad sändning)

LoRaWAN inkluderar funktionen NB_Trans, som innebär att nätverksservern kan instruera en enhet att skicka samma meddelande flera gånger. Detta sker vanligtvis vid dåliga signalförhållanden för att öka chansen att minst en av sändningarna når gatewayen framgångsrikt. Genom att använda NB_Trans ökar pålitligheten, men ökar också energiförbrukningen dramatiskt. Funktionen används därför främst när det är avgörande att data kommer fram.

3.3 Datahastighet (DR) och adaptiv datahastighet (ADR)

I LoRaWAN är datahastigheten (DR) direkt kopplad till spridningsfaktorn (SF) och bandbredden (BW). Adaptive Data Rate (ADR) möjliggör dynamisk optimering av både datahastighet och sändningseffekt, som vanligtvis hanteras av nätverksservern. Denna mekanism är särskilt värdefull för stationära enheter, eftersom den hjälper dem att växla till lägre SF (och när möjligt även lägre sändningseffekt) för att spara energi när en stabil länk har upprättats. Mobila enheter, vars signalförhållanden förändras kontinuerligt, kan däremot utnyttja en egen ADR-strategi med snabbare lokal anpassning.

3.3.1 Datahastigheter och spridningsfaktorer (EU868)

I EU868-regionen definieras datahastigheterna enligt följande kombinationer av spridningsfaktor och bandbredd:

DR0 → SF12 @ 125 kHz

DR1 → SF11 @ 125 kHz

DR2 → SF10 @ 125 kHz

DR3 → SF9 @ 125 kHz

DR4 → SF8 @ 125 kHz

DR5 → SF7 @ 125 kHz

En lägre SF (t.ex. SF7) ger högre datahastighet och lägre energiförbrukning per överfört paket, men kortare räckvidd och lägre mottagarkänslighet. En högre SF (t.ex. SF12) ger större räckvidd men längre överföringstid och högre energiförbrukning.

3.3.2 Inledande anslutning vid SF12

Som standard använder enheter den långsammaste datahastigheten (SF12) vid första anslutningsförsöket för att maximera chansen att nå en gateway under svåra täckningsförhållanden. Varje försök vid SF12 med hög sändningseffekt (+14 dBm) förbrukar dock betydligt mer energi än lägre SF och effektinställningar.

3.3.3 Justering av sändningseffekt

ADR kan också anpassa sändningseffekten inom regulatoriska gränser. En enhet med bra täckning kan instrueras att sänka effekten från +14 dBm till exempelvis +2 dBm eller –10 dBm, vilket kraftigt minskar batteriförbrukningen när signalkvaliteten tillåter detta.

3.3.4 Exempel på energiförbrukning: SF7 vs. SF12

För att illustrera skillnaden i energianvändning jämför vi två scenarier med en 10-byte upplänk i EU868:

SF7, –10 dBm:

Sändningstid: ~50 ms (0,05 s)

Sändningsström: ~15 mA

Energiförbrukning: ~0,000208 mAh

SF12, +14 dBm:

Sändningstid: ~1,5 s

Sändningsström: ~45 mA

Energiförbrukning: ~0,01875 mAh

Skillnaden innebär att en upplänk med SF12 och hög uteffekt använder cirka 90 gånger mer energi än motsvarande överföring med SF7 vid låg effekt.

3.3.5 Energikonsekvenser vid anslutning (Join)

Enheter som initierar en anslutning med nätverket vid SF12 förbrukar mycket ström, eftersom anslutningsprocessen omfattar minst en JoinRequest samt två mottagningsfönster för JoinAccept och dessutom potentiella återförsök om anslutningen misslyckas.

Den samlade energiåtgången för denna process är betydligt högre jämfört med vanliga datatransmissioner.

3.3.6 ADR-strategier

Nätverksstyrd ADR: Lämplig för stationära enheter med stabila radiomiljöer. Nätverksservern analyserar signalhistorik och optimerar SF och uteffekt.

Enhetsstyrd ADR: Effektivt för mobila enheter. Genom att låta enheten självständigt och snabbt justera SF och sändningseffekt baserat på lokala signalmätningar hanteras varierande radiomiljöer bättre.

Fast datahastighet (fixed DR): Kan förenkla hanteringen med ett konstant DR-värde men kan innebära kompromisser i batteritid eller täckning om radiomiljön förändras avsevärt.

4: Nätverk och miljöns påverkan

Trådlösa nätverks prestanda påverkas av miljöfaktorer som kan förbättra eller försämra signalkvaliteten. För att optimera ett LoRaWAN-nätverk är det viktigt att förstå hur signaler sprids, hur störningar uppstår och hur omgivningen påverkar täckning och batterilivslängd.

LoRaWAN:s lågeffekts- och långdistanskommunikation gör det särskilt känsligt för små förändringar i gatewayplacering, byggmaterial och störningskällor. Genom att ta hänsyn till dessa faktorer kan nätverket designas för optimal räckvidd och energieffektivitet.

4.1 Sändning av signaler

LoRaWAN använder en ”broadcast-and-forward”-metod där sensorer sänder data som tas emot av alla gateways inom räckhåll. Varje gateway vidarebefordrar sedan data till nätverksservern.

4.1.1 Upplänk (Sensor => Gateway)

En sensor sänder data på vald kanal och spridningsfaktor (SF).

Om flera gateways hör signalen skickas data vidare till nätverksservern som sedan tar bort eventuella dubbletter.

Batteriförbrukningen hos sensorn är oberoende av antalet gateways som mottar signalen, men bättre gatewaytäckning kan minska behovet av hög sändningseffekt.

En sensor sänder på sin tilldelade kanal och spridningsfaktor, med hjälp av en inställd sändningseffekt.

4.1.2 Nedlänk (Gateway => Sensor)

LoRaWAN är dubbelriktat, och gateways kan därför kommunicera tillbaka till sensorer för:

• Bekräftelse (ACK) av mottagna data.
• Konfigurationsändringar och ADR-kommandon.
• Länkkontroll och återanslutning vid dålig täckning.
• JoinAccept-meddelanden vid initial anslutning.

4.1.3 Överväganden om dubbelriktad timing och latens

De flesta LoRaWAN sensorer är klass A enheter. De lyssnar på nedlänk under två korta mottagningsfönster efter varje upplänk. Fördröjningar eller latens i nätverket (mellan gateway och nätverksserver) kan innebära att nedlänkar missas, vilket kan leda till ökad energiförbrukning och försämrad funktion. Därför är det viktigt med noggrann nätverksplanering som säkerställer låg latens mellan komponenter i nätverket.

---

4.2 Radiolänkbudgeten

En radiolänkbudget används för att uppskatta om en trådlös länk mellan en sändare (sensor) och en mottagare (gateway) fungerar. Länkbudgeten räknar samman alla förstärkningar (sändningseffekt, antennförstärkningar) och drar ifrån alla förluster (vägförluster, hinder, kablar) för att kontrollera att mottagen signal är starkare än mottagarens känslighetströskel.

4.2.1 Grundläggande koncept

En enkel länkbudgetekvation:

Länkbudget = Sändningseffekt + Antennförstärkningar – Förluster ≥ Mottagarkänslighet 

• En positiv länkbudget innebär att länken är tillförlitlig.

4.2.2 Inverkan av spridningsfaktor

LoRaWAN:s spridningsfaktor (SF) påverkar mottagarkänsligheten:

Hög SF (t.ex. SF12):

Mycket hög mottagarkänslighet (större länkbudget).

Längre sändningstid och lägre datahastighet.

Lämpligt vid långa avstånd eller svåra radiomiljöer.

Låg SF (t.ex. SF7):

Lägre känslighet (mindre länkbudget).

Kortare sändningstid och högre datahastighet.

Passar vid god täckning och kortare avstånd.

Om en gateways känslighet vid SF7 är –123 dBm och vid SF12 –137 dBm innebär det att SF12 erbjuder cirka 14 dB extra länkmarginal. Det medför dock längre sändningstider och avsevärt högre energiförbrukning per meddelande jämfört med lägre SF.

En robust länkbudget gör det ofta möjligt för fler enheter att arbeta med lägre SF, vilket minskar kollisioner och användning av sändningstid.

4.2.3 Praktiska överväganden

• Enhetens placering och miljö: Stadsområden med höga byggnader eller moderna "radiotäta" strukturer kan försämra länkbudgeten genom ökad dämpning.
• Gateway-distribution: Strategiskt placerade gateways med minimala hinder kan göra det möjligt för enheter att använda lägre SF (höja datahastigheterna och minska batteriförbrukningen).
• Adaptive Data Rate (ADR): Som förklaras i avsnitt 3.3 gör ADR det möjligt för nätverket att dynamiskt flytta enheter till lägre eller högre SF, vilket optimerar länkbudgeten i realtid.

Exempel: SF7 jämfört med SF12

Om en gateways känslighet vid SF7 är –123 dBm och vid SF12 är –137 dBm, kan enheter vid SF12 effektivt njuta av ~14 dB mer marginal för att övervinna vägförluster. Varje SF12-överföring kan dock vara 20–30 gånger längre än SF7, vilket leder till högre batteriförbrukning om den görs ofta.

4.3 Dämpning

Dämpning beskriver hur signalstyrkan minskar när radiovågor färdas genom olika material och miljöer. Genom att förstå hur dämpningen påverkar signalen kan man optimera placeringen av gateways och sensorer för att maximera räckvidden och förbättra nätverksprestandan.

4.3.1 Vanliga dämpningskällor

Byggmaterial:

• Betong och tegel: Vanligtvis 10–30 dB dämpning per vägg beroende på tjocklek.
• Armerad betong: Metallen i betongen ökar ytterligare dämpningen.

Vegetation och skog:

• Torr skog och vegetation: Ca 0,5–1 dB per meter.
• Fuktig och tät skog: Kan öka till 1–2 dB per meter.

Mark och jord:

• Torr jord: Cirka 10 dB per meter.
• Fuktig eller blöt jord: Kan öka kraftigt till 20 dB eller mer per meter.

Energisnåla byggnader:

• Isolering med metallfolie: 20–40 dB per vägg.
• Metallbelagda fönster: 10–30 dB per ruta.

Väder och fuktighet:

• Regn eller snö: Kan öka dämpningen med några dB över längre avstånd.
• Vått lövverk: Ytterligare dämpning jämfört med torr vegetation.

Människor och djur:

• Människokroppen och djur innehåller vatten som absorberar signaler vid 868 MHz, vilket kan påverka täckningen i folktäta miljöer.

Genom att ta hänsyn till dessa faktorer kan man planera gatewayplacering och sensorinstallationer så att täckningen blir stabil och energieffektiv.

4.3.2 Vertikal täckning

Vanliga antenner för LoRaWAN är oftast utformade för optimal horisontell spridning av signalen i ett 360-graders mönster. Detta innebär begränsad täckning vertikalt:

Utomhusgateways: Enheter placerade direkt under en gateway får ofta sämre signalstyrka eftersom antennernas signalutstrålning vertikalt nedåt är begränsad.

Inomhusgateways: Vanligtvis täcks 2–3 våningar ovanför och under gatewayens installationsplats, men byggmaterial som betongplattor och metallarmering minskar vertikal räckvidd ytterligare. Speciella antenner kan behövas om tydlig vertikal täckning är avgörande.

4.3.3 Antennens placering

När en LoRaWAN (eller någon sub-GHz) gateway är monterad på eller nära marknivå kan radiosignalen påverkas avsevärt av jordens yta och närliggande hinder. Några faktorer som minskar räckvidden i markmonterade scenarier:

Vid cirka 1 GHz kan den nedre delen av signalens Fresnel-zon (det elliptiska området runt den direkta siktlinjen) blockeras eller störas av själva marken.

Även mindre hinder i Fresnel-zonen kan orsaka diffraktion och ytterligare vägförlust, vilket ofta lägger till flera dB dämpning för varje blockerad länk.

Signaler som reflekteras från marken kan störa den direkta signalvägen på ett destruktivt sätt. Denna flervägseffekt är särskilt uttalad när antennen är på låg höjd, vilket skapar partiella signalavbokningar.

Gräs, buskar, stenar eller konstgjorda föremål nära marknivå bidrar också till spridning och diffraktion, vilket ytterligare försvagar siktlinjekomponenten.

I ett platt, fritt område minskar placeringen av en gateway-antenn bara 1–2 meter från marken avsevärt hur långt den kan "se" över små kullar eller vegetation. Att höja antennen till 6–10 meter (t.ex. på en mast) utökar däremot siktlinjen genom att låta signalen rensa terräng på låg nivå och skräp.

Även om de exakta siffrorna varierar, kan montering av en gateway på marknivå resultera i allt från 10–20 dB mer vägförlust jämfört med en väl upphöjd antenn, beroende på lokalt skräp och terräng. Denna extra förlust kan översättas till hälften eller till och med en fjärdedel av täckningsradien under vissa lantliga eller halvöppna förhållanden – och ännu mer drastiska minskningar av räckvidden i stads- eller skogslandskap.

5: Batteridrivna LoRaWAN-enheter

En av de främsta fördelarna med LoRaWAN är möjligheten att driva sensorer i 10 år eller längre på ett enda batteri. Detta gör tekniken särskilt lämpad för storskaliga installationer där regelbundet batteribyte är opraktiskt eller kostsamt. För att uppnå maximal batterilivslängd måste flera faktorer balanseras.

5.1 Enhetsklasser och energiförbrukning

• Klass A: Lägst energiförbrukning; enheter sover djupt och vaknar endast för att skicka data och kort lyssna efter svar.
• Klass B och C: Högre energiförbrukning eftersom enheterna oftare lyssnar efter inkommande meddelanden.

5.2 Kritiska och icke-kritiska meddelanden

Kritiska larm och meddelanden

Exempel: läckagelarm, brandlarm, säkerhetsvarningar

Dessa meddelanden skickas vanligtvis som bekräftade meddelanden och enheten fortsätter att sända tills en bekräftelse mottas från nätverket.

Rutinmässiga eller icke-kritiska data

Exempel: regelbundna temperatur- och fuktmätningar.

Skickas oftast obekräftat för att minska energiförbrukningen genom att undvika upprepade omsändningar.

Enheter med flera sensorer

Exempel: en enhet som mäter både temperatur, luftkvalitet och rörelse.

Kritiska data (t.ex. rörelse) kan skickas bekräftat, medan mindre viktiga data (t.ex. temperatur) skickas obekräftat för att spara batteri.

5.3 Operativa exempel

Här följer några praktiska exempel på hur olika typer av LoRaWAN-enheter kan användas för att balansera energiförbrukning och tillförlitlighet:

1. Periodisk temperatursensor

• Vaknar var 15:e minut, mäter temperaturen och skickar en obekräftad upplänk.
• Med fördel kan sensorn konfigureras att enbart skicka data om temperaturen har förändrats, till exempel med minst 0,2 grader sedan senaste sändningen.
• • Lyssnar kort efter eventuell nedlänk, därefter går den tillbaka till viloläge. I bra täckningsförhållanden är tillfällig paketförlust acceptabel då temperaturen inte är verksamhetskritisk.

2. Detektor för vattenläckage

• Övervakar kontinuerligt fukt med låg strömförbrukning.
• Vaknar och skickar omedelbart en bekräftad larmsignal vid upptäckt av fukt.
• Återsänder tills bekräftelse (ACK) mottagits eller tills maximalt antal försök nås.
• Kan ta emot nedlänkskommandon för ytterligare diagnostik eller ändrad konfigurering.

3. Sensor för skrivbordsbeläggning

• Övervakar beläggningen av arbetsplatser, exempelvis med PIR-sensor eller tryckplatta.
• Skickar en bekräftad upplänk vid förändringar i beläggning för att garantera att nätverket registrerar ändringen.
• Skickar periodiska obekräftade statusuppdateringar med längre intervaller för att ge en översiktsbild, även om inga förändringar skett.

5.4 Nätets påverkan på batterilivslängden

Täckningskvaliteten och miljön där LoRaWAN-sensorer placeras har en direkt och betydande påverkan på batterilivslängden. Dålig nätverkstäckning innebär att sensorer måste anpassa sig genom att använda högre spridningsfaktorer (SF), vilket leder till längre sändningstider och därmed högre energiförbrukning per meddelande. Detta kan snabbt minska batteriets livslängd från flera år till endast månader eller veckor.

Höga nivåer av störningar, såsom från andra radiokällor eller elektrisk utrustning, kan ytterligare förvärra problemet genom att sensorer måste göra fler försök att överföra samma data (omsändningar). Dessutom kan nätverksservern instruera sensorn att upprepa varje sändning (NB_Trans > 1) för att öka chansen att meddelandet når fram, vilket ytterligare ökar energianvändningen.

Även regelbundna återanslutningar (re-joins) på grund av otillförlitlig täckning kan vara extremt kostsamma ur energisynpunkt. Varje återanslutning innebär en serie av sändningar vid hög spridningsfaktor och maximal sändningseffekt, vilket signifikant ökar den totala energiförbrukningen.

För att motverka dessa problem är det avgörande att noggrant planera gateway-placeringar och nätverkets design så att sensorer kan kommunicera med lägsta möjliga SF och minimalt antal omsändningar. En väl optimerad nätverksdesign sparar energi, minskar kostnader och säkerställer maximal batterilivslängd för sensorerna.

5.5 Länkkontroll och återanslutning

Även med robust täckning kan LoRaWAN enheter förlora anslutningen på grund av miljöförändringar, gateway-avbrott, störningar eller förändringar i nätverksinfrastrukturen. Ett annat vanligt skäl är att nätverksservern har återstartats, bytts ut eller av någon anledning förlorat enhetens sessionsnycklar. För att identifiera och återställa från sådana problem kan enheter regelbundet utföra länkkontroller och, vid behov, återansluta till nätverket.

Länkkontroll

• Syfte: Att verifiera kontinuerlig kommunikation med nätverket.
• Frekvens: Kan ske periodiskt (t.ex. dagligen) eller vid tecken på försämrad täckning.
• Batteripåverkan: Begränsad påverkan, men täta kontroller ökar strömförbrukningen.

2. Återanslutning (Re-join) Syfte: Att återställa sessionens säkerhetsnycklar och nätverkssynkronisering.

• Procedur: Enheten gör ett nytt anslutningsförsök med maximal effekt vid hög SF (SF12), vilket är mycket energikrävande.
• Energikostnad: Betydligt högre än vanliga upplänkar. Upprepade återanslutningar kan drastiskt minska batteritiden, särskilt i områden med dålig täckning.

5.6 Rapportering av batteristatus

Korrekt batterirapportering är avgörande för batteridrivna LoRaWAN-enheter, vilket gör det möjligt för användare eller nätverksservrar att se återstående energi och schemalägga byten eller underhåll. Den enklaste metoden mäter batterispänningen – ofta med jämna mellanrum – och drar slutsatser om återstående kapacitet från en känd urladdningskurva. Mer avancerade tekniker inkluderar internt motstånd, temperatur och användningshistorik för att ge mer exakta uppskattningar av batteriets livslängd.

5.6.1 Grundläggande batterimodell

För batteridrivna LoRaWAN-enheter är korrekt batterirapportering avgörande för att övervaka återstående energi och planera underhåll. Den vanligaste metoden är att mäta batterispänningen i vila (OCV – Open Circuit Voltage), som beror på batteriets laddning och temperatur. Mer avancerade tekniker mäter spänningsfallet över batteriets interna motstånd vid en känd last eller genom att kontinuerligt estimera använd energi vid varje aktivitet.

5.6.2 Utbytbara kontra inbyggda batterier

Utbytbara batterier:

• Förlitar sig ofta på spänningsmätning i vila eller under belastning som en enkel indikator.
• Användare kan byta cell när spänningen faller under en viss tröskel.
• Variationer mellan fabrikat kan leda till olika spänningar i slutet av livscykeln – enheter kan tvinga fram en konservativ avstängning för att säkerställa stabil drift.

Inbyggda batterier:

• Kan använda mer sofistikerad batterimätning – som coulombräkning eller avancerade algoritmer – eftersom enhetstillverkaren känner till den exakta batterikemin och de interna egenskaperna.
• Möjliggör mer tillförlitlig batterirapportering.

5.7 Ungefärlig batteritid för en upplänk var 15:e minut (500 mAh batteri)

Med följande antaganden – standby-ström = 1,5 μA, TX-ström = 40 mA, RX-ström = 5 mA, en 10-byte-upplänk var 15:e minut (96 gånger/dag) och minimala återförsök – visar tabellen nedan grova livslängdsuppskattningar för ett 500 mAh-batteri och inkluderar inte ytterligare batteriladdning på grund av att meddelanden skickas igen i dåliga nätverk:

Spridningsfaktor	Ungefärlig sändningstid (ms)	Beräknad batterilivslängd
SF7	~50–60	~17 years
SF8	~100–110	~15 years
SF9	~180–200	~13 years
SF10	~370–410	~11 years
SF11	~740–820	~7 years
SF12	~1480–1600	~5 years

Notera: I LoRaWAN-nätverk med svag täckning och mycket störningar kan LoRaWAN servern begära att enheten skickar varje vara datapaket flera gånger (NB_Trans >1) och dessutom kan en enhet som skickar bekräftade meddelande behöva göra många omsändningar om den inte får kvittens på skickad data. Detta kan ytterligare reducera livslängden med upp till 75%.

6 Rekommendationer

6.1 Nätverk

Ett välplanerat och optimerat LoRaWAN-nätverk är avgörande för att uppnå hög tillförlitlighet, låg energiförbrukning och god skalbarhet. Genom att följa dessa riktlinjer kan kommunikationsproblem undvikas och batteridrivna enheter når förväntad livslängd.

Utvärdera miljön

• Kartlägg fysiska hinder: Identifiera väggar, metallstrukturer, folieisolerade byggnader, skogsområden och kuperad terräng som kan dämpa eller blockera signaler. - Hitta potentiella störningskällor: Leta efter industrimaskiner, annan ISM-bandutrustning (t.ex. NB-IoT, Sigfox) eller starka närliggande sändare (t.ex. mobilbasstationer) som kan höja brusnivån.
• Utför signalmätningar: Mät faktisk signalstyrka (RSSI) och signal-brusförhållande (SNR) på de platser där enheter ska installeras, särskilt i inomhus- och underjordiska miljöer.

Upprätta en stabil gateway-infrastruktur

• Strategisk placering: Placera gateways högt för att minimera hinder och säkerställa bred täckning.
• Redundans och säkerhet: Planera för överlappande täckning med flera gateways i kritiska områden för att minimera risken för enpunktsfel.
• Backhaul-anslutning: Se till att gateways har stabila och låglatenta backhaul-anslutningar (Ethernet, mobil, fiber) för snabb dataöverföring och minskad risk för paketförlust. Tillse att LoRaWAN servern är konfigurerad för att hantera fördröjningen i backhaul (RX1_Delay) som kan behöva förlängas om en eller flera gateways är anslutna via satellit eller mobilt nät.

Optimera spridningsfaktorer och nätverksbelastning

• Sikta på SF7–SF9: Enheter bör arbeta med så låg spridningsfaktor (SF) som möjligt för att minimera sändningstid, spara batteri och minska nätverksbelastningen.
• Identifiera områden med dålig täckning: Om många enheter konstant använder SF10–SF12, undersök täckningsbrister. Att justera gatewayplaceringen är oftast mer effektivt än att låta enheter använda hög SF.
• Använd inomhusgateways: Byggnader har ofta metalliserade fönster och metallfolie i väggar för att reflektera värme. Sådan metall reflekterar även radiosignaler. Därför bör inomhusgateways övervägas för att förbättra täckningen och minska behovet av hög SF.

Genomför pilottestning före fullskalig utrullning

• Installera enheter i de mest utmanande miljöerna och utvärdera deras prestanda.
• Om tester visar på hög SF, förlorade data-paket eller att NB_Trans >1 så behöver åtgärder tas.
• Verifiera redundans: Simulera bortfall av en gateway för att säkerställa att enheter fortfarande kan ansluta via närliggande gateways.

Löpande övervakning och underhåll

• Säkerställ att alla gateways är online och att deras backhaul-anslutningar är stabila.
• Använd nätverksserverns och IoT-plattformens statistikfunktioner och log för att upptäcka svaga täckningsområden eller störningskällor.
• Justera nätverksinfrastrukturen vid tillägg av nya enheter eller förändrade täckningskrav.

6.2 Utplacering av sensor

Ett väl förberett nätverk är grunden för framgångsrika smarta tjänster. När gateways är på plats och täckningen har verifierats är nästa steg att distribuera sensorer. Att se till att enheter ansluts på ett tillförlitligt sätt, välja rätt konfiguration (t.ex. rapporteringsintervall, bekräftade kontra obekräftade meddelanden) och validera länkkvaliteten kan avsevärt förbättra drifttiden och batterieffektiviteten.

6.2.1 Addera sensorer

LoRaWAN-enheter initierar normalt en anslutningsprocedur vid den högsta spridningsfaktorn och maximal effekt för att maximera täckningen. Den här processen kräver tvåvägskommunikation med nätverksservern.

• Om en sensor har svårt att ansluta (t.ex. flera misslyckade försök), indikerar det troligen täckningsproblem, felaktiga enhetsuppgifter eller fördröjningar i gateway-nätverksserverlänken (RX1_Trans kan behöva ökas)
• Ihållande anslutningsproblem kan tömma batteriet snabbt eftersom varje nytt försök vid SF12 konsumerar mycket energi.

6.2.2 Konfiguration

Planera noggrant hur ofta eller när sensorn ska rapportera data:

1. Intervall för rapportering

   • Tidsbaserat: Att skicka data var 5:e, 15:e eller 60:e minut är enkelt men kan vara överdrivet om små förändringar inträffar, vilket slösar batteri.
   • Händelsestyrd: Sensorn sänder endast när ett tröskelvärde eller en utlösare uppfylls (t.ex. läckage upptäckt, beläggningsförändring). Detta sparar batteri och ger varningar i rätt tid.

2. Bekräftat vs. obekräftat

   • Kritiska data: Larm- eller händelsebaserade meddelanden kan behöva bekräftade upplänkar för att säkerställa leverans, återsändningen fortsätter tills den bekräftas.
   • Rutinmässig data: Ofta är obekräftade meddelanden att föredra, vilket minimerar batterianvändning och nätverksbelastning.
   • Blandad strategi: En enhet kan använda bekräftade meddelanden för brådskande händelser och obekräftade för periodiska statusuppdateringar.

6.2.3 Kontroller efter utplacering

Kontroller efter utplacering

• Övervaka RSSI, SNR och SF: Låga signalvärden och hög SF kan indikera täckningsproblem.
• Analysera återsändningar och återanslutningar: Höga nivåer kan signalera dålig täckning eller störningar.
• Justera inställningar vid behov: Förändra rapporteringsintervall, bekräftelsepolicy eller flytta sensorer för att optimera prestandan.

7. Driv ett sensornätverk

Att distribuera och konfigurera LoRaWAN-sensorer är bara det första steget; Löpande drift och övervakning av nätverket är avgörande för att upprätthålla tillförlitligheten, identifiera täckningsproblem och optimera batterianvändningen. En välstrukturerad driftsplan säkerställer att mindre problem, till exempel en gateway som går offline eller sensorer som driver till högre spridningsfaktorer, upptäcks och löses innan de blir omfattande.

7.1 Övervaka sensorer

Spridningsfaktor och signalstyrka

• Övervaka SF och säkerställ att enheter inte fastnar på höga SF nivåer.
• Övervaka RSSI och SNR för att identifiera täcknings eller störningsproblem.

Upplänksfrekvens och tillförlitlighet

• Kontrollera att sensorer skickar data enligt planerat intervall.
• Kontrollera kontinuiteten i frame count för att upptäcka eventuella förlorade data.

Kanalbalans och NB_Trans

• Säkerställ att trafiken är jämnt fördelad över alla kanaler. Om vissa kanaler har mindre trafik kan det indikera störningar.
• Kontrollera att NB_Trans inte regelbundet ligger på annat än 1 för att undvika onödiga dubbelsändningar.

7.2 Övervakning av gateway

• Implementera automatiska kontroller (t.ex. ping eller SNMP-liknande övervakning) för att bekräfta att varje gateway förblir online och med hälsosam backhaul.
• Granska gateway-logg regelbundet.

7.3 Optimering vid drift

• Täckning

  • När miljön förändras (t.ex. nya byggnader, konstruktioner) kan täckningen försämras.
  • Schemalägg periodiska platsundersökningar eller samla in täckningsstatistik för att avgöra om ytterligare gateways eller ompositionering är nödvändig.

• Justering av adaptiv datahastighet

  • För statiska sensorer, se till att ADR är aktiv och inställd med lämpliga parametrar på nätverksservern. Kontrollera att enheterna faktiskt konvergerar till en låg SF efter en tid, vilket maximerar batterilivslängden.
  • Om många sensorer finns kvar på högre SF undersöker du problem med nätverks- eller enhetskonfiguration.

• Firmware- och konfigurationsuppdateringar

  • Vissa sensorer tillåter OTA-uppdateringar (over-the-air) eller omkonfiguration. Använd dessa funktioner med försiktighet och schemalägg överföringar för att undvika överbelastning i nätverket.
  • Behåll en granskningslogg för ändringar så att du kan återställa om en ny konfiguration introducerar oväntat beteende.

• Övervakning av batteri

  • Övervaka batteristatus för att åtgärda innan en enhet slutar fungera.
  • Analysera konsumtionstrender, särskilt om användningsmönstren förändras.

8. Felsökning

Trots noggrann planering och övervakning kan problem uppstå i alla LoRaWAN-distributioner. Från sensorer som inte kan ansluta till nätverket eller förlorad data till oväntat hög batteriförbrukning – ett metodiskt tillvägagångssätt för felsökning hjälper till att isolera grundorsakerna och snabbt återställa normal drift. Nedan visas vanliga problemscenarier och rekommenderade diagnostiksteg.

8.1 Vanliga symtom och orsaker

Misslyckade eller långsamma anslutningar

• Symptom: Enheter försöker upprepade gånger ansluta vid SF12, vilket förbrukar stora mängder batteri, men får aldrig en JoinAccept. Möjliga orsaker:
  • Otillräcklig täckning.
  • Lång svarstid för gateway eller nätverksserver – nedlänkar kommer efter att enhetens mottagningsfönster stängs.
  • Ogiltig konfiguration (DevEUI, AppEUI, AppKey-matchningsfel).
  • Störningar. Det kan tex vara en pulserande störning från en närliggande mobilbasstation som slår ut samtliga kanaler samtidigt och omöjliggör anslutning med långsam datahastighet.

Ihållande hög spridningsfaktor (SF10–SF12)

• Symptom: Enheterna förblir vid hög SF trots till synes rimlig närhet till gatewayen. Möjliga orsaker:
  • Lokal störning. Åtgärd: Identifiera störaren. Ta bort den, eller flytta gateway och sensor. Om störaren inte kan tas bort och bara berör någon enstaka kanal så kan den blockeras i nätverksservern.
  • Problem med gateway eller antenn (felaktig kabel, dåliga kontakter eller antennskada).
  • Kommunikation mellan gateway & LoRaWAN nätverksserver har för hög latency.
  • ADR är inte aktiverat eller felkonfigurerat på nätverksservern, vilket förhindrar att enheter växlar till lägre SF.
  • Förändrad miljö: Energirenoveringar i byggnader kan lägga till metalliserade fönster, isolering med folieskikt eller andra reflekterande barriärer som avsevärt ökar dämpningen, vilket tvingar slutenheter att använda högre SF för att upprätthålla anslutningen. Det kan också vara en förändrad interiör som ger ökad radio-dämpning.

Saknade eller sporadiska upplänkar

• Symptom: Vissa sensorer slutar rapportera under vissa tidsperioder. Möjliga orsaker:
  • Om sensorn inte får konfirmation (ACK) på skickade data så kan den gå in i en process för att återsända data och därefter försöka återansluta enheten (join).
  • Gatewayen är offline, har en långsam internetförbindelse eller är tidvis överbelastad med annan trafik.
  • Svagt batteri.

Överdrivna återförsök/frekventa återkopplingar

• Symptom: Nätverksloggar visar enheter som återsänder eller återansluter flera gånger, vilket snabbt tömmer batterierna. Möjliga orsaker:
  • Dålig täckning eller störningar som orsakar förlorade nedlänksbekräftelser.
  • Sensorn är felaktigt inställd på bekräftade meddelanden för rutindata.
  • Anslutningsfördröjningar mellan gateway och nätverksserver som leder till missade mottagningsfönster.

Snabb batteriurladdning

• Symptom: Sensorer som är avsedda att hålla i flera år töms på månader. Möjliga orsaker:
  • Höga SF-sändningar och långa sändningstider.
  • En eller flera störda kanaler har orsakat att nätverksservern begärt att sensorer ska skicka varje meddelande flera gånger (NB_Trans > 1)./
  • Hög frekvens av återanslutningsförsök och återsändningar.
  • Olämpligt rapporteringsintervall (t.ex. för ofta för applikationen).
  • Sensorn utsatt för extrema temperaturer.

8.2 Diagnostik

1. Granska data & nätverksloggar

   • Leta efter mönster av tappade eller skadade paket (Saknas frame-counts?)

   • Kontrollera hur ofta enheter skickar JoinRequests.

   • Finns tecken i log på att någon gateway har långsam internetförbindelse?

   • Lyckas obekräftade data oftast, men inte bekräftade meddelande? Det kan bero på att gateway har långsam internetförbindelse eller att sensorns mottagare är störd av en extern störkälla nära sensorn.

   • Är datatrafiken till/från varje gateway jämnt spridd över alla kanaler? Är RSSI & SNR på de olika kanalerna konsistent? Om inte så kan en eller flera kanaler vara störda.

   • Tappar man data ibland trots att flera normalt gateway hör sensorn? Störs dessa gateways samtidigt? Då finns det kanske en störkälla som periodvis skickar it en stark störning.

2. Inspektera fysisk infrastruktur

   • Gateway-status: Är gatewayen igång och backhaul stabil? Kontrollera om det finns larmtillstånd eller offlinerapporter.
   • Antennanslutningar: Inspektera kablar och kontakter för skador, fukt eller lösa anslutningar.
   • Placeringsändringar: Har gatewayen flyttats eller blockerats av nybyggnation?
   • Sitter gateway nära en annan radiosändare som till exempel en mobil basstationsantenn.

3. Verifiering av sensor

   • Firmware-inställningar: Se till att enheten är inställd på rätt region och har giltig DevEUI/AppEUI/AppKey.
   • Kontrollera sensorns konfiguration.
   • Kontrollera sensorns batterispänning.

4. Täcknings- och störningskontroller

   • RSSI/SNR-mätningar: Använd en testenhet eller platsundersökning för att mäta signalstyrkan i misstänkta områden.
   • Spektrumanalys: Om tillgängligt, leta efter starka störningar i LoRaWAN-kanalerna.
   • Överlappande radio-nät: Kontrollera att andra nätverk (tex mobilt nät) eller andra LoRaWAN-nät inte mättar bandet.

Kontakt & Support

För mer information om LoRaWAN-nätverksinställningar, sensorkonfigurationer eller täckningslösningar i radiotäta byggnader, vänligen [https://sensative.com/contact/](kontakta Sensatives supportteam)