Gebruiksscenario's en overwegingen voor LoRaWAN

Belangrijke opmerking: Link Labs is de maker van Symphony Link, een alternatief protocol voor LoRa gericht op zeer betrouwbare industriële en zakelijke use-cases. Hieronder meer.

Wanneer u LoRaWAN en zijn ideale gebruiksscenario's en beperkingen wilt begrijpen, is het belangrijk om een ​​beetje geschiedenis te begrijpen. LoRaWAN (toen LoRaMAC genoemd) is ontwikkeld door Semtech (de enige eigenaar van de LoRa PHY IP) in samenwerking met IBM Research (zij verlieten het project vervolgens). De aannames bij het ontwerpen van het protocol waren:

• Te gebruiken door mobiele netwerkoperatoren
• In één gecoördineerd netwerk
• In de 868 MHz-band zonder licentie

Dit zijn belangrijke aannames, omdat het resulterende protocol:

• 1% Duty Cycle Limit (voor zowel alle zenders als de gateway)
• Kaart van gemeenschappelijke frequentiekanalen
• MAC (laag 2) verwerking alleen in de cloud

Om de beperking van de inschakelduur van 1% voor met name de gateway te ondersteunen, zijn veel afwegingen nodig:

• Bijna alle uplink-berichten zijn niet bevestigd
• Alle gateways binnen bereik zien al het uplinkverkeer
• Alle codering wordt afgehandeld met behulp van statische sleutels

Aangezien alle uplink-berichten niet erkend en ongecoördineerd zijn, wordt LoRaWAN beschouwd als een "pure-aloha"-schema. Zo'n netwerk heeft ongeveer 18% efficiëntie. Dit betekent dat 82% van de pakketten verloren gaat wanneer een LoRaWAN-netwerk volledig wordt gebruikt. Aangezien de meeste berichten niet worden bevestigd, weet het eindknooppunt niet dat het bericht is gemist. Om dit te voorkomen, kunnen sommige gebruikers vaker zenden, waardoor het probleem nog groter wordt. Lees dit gemakkelijk te begrijpen bericht over Aloha Networks.

Als er dankbetuigingen aan dit systeem worden toegevoegd, faalt de efficiëntie nog meer. Dit komt omdat wanneer het basisstation aan het zenden is, het niet kan luisteren. De eindknooppunten weten niet dat de gateway ze niet kan horen. Aangezien de gateway slechts 1% van de tijd kan verzenden, resulteert dit slechts in ongeveer 1,65% extra pakketverlies.

Bovendien, als iemand anders een LoRaWAN-netwerk gebruikt, telt al zijn verkeer ook mee voor uw capaciteit. Dit komt omdat alle gateways zijn afgestemd op dezelfde gemeenschappelijke frequenties.

Een andere belangrijke overweging voor LoRaWAN is het dichtbij/veraf-probleem. Aangezien LoRa slechts 20-30dB co-channel dynamisch bereik heeft, overstemmen knooppunten die zich dicht bij de gateway bevinden, knooppunten die ver weg zijn. Dit is minder een probleem in grote MNO-netwerken, aangezien idealiter meerdere gateways binnen bereik zijn.

Onze vrienden bij The Things Network hebben dit stuk ook over LoRaWAN Limitations samengesteld.

Dat gezegd hebbende, de ideale use case voor LoRaWAN is:

• Eenvoudige sensoren die niet vaak moeten zenden
• Het is oké om soms 5-85% van de gegevens te missen
• Weinig vermogen om dit apparaat te bedienen
• Geen mogelijkheid om apparaatfirmware draadloos bij te werken
• In de tientallen tot honderden ingezet
• Kan meerdere gateways inzetten om elk knooppunt te dekken

Sommige automatische meteruitlezingen zijn een goed voorbeeld van een goede use-case voor LoRaWAN. Voor meters die de uitlezing bijwerken, zeg maar één keer per uur, maakt het niet uit of sommige meetwaarden worden gemist, zolang sommige er maar doorkomen.

Symphony Link lost veel van deze problemen op. In het kort, hier is hoe:

1. Inlijsten: De gateway verzendt elke 2 seconden een frameheader, die informatie bevat over welke uplinkkanalen beschikbaar zijn en wanneer het uplinkvenster wordt geopend.

2. Gecomprimeerde bevestigingen: In Symphony Link worden standaard alle uplinkberichten bevestigd. Om dit te bereiken, worden alle bevestigingen samengevoegd tot één gecomprimeerd bericht dat alle knooppunten (die zojuist zijn verzonden) ontvangen.

3. Variabele uplink/downlink tijdslots: De gateway beslist hoe lang hij moet verzenden op basis van downlink-verkeer in de wachtrij. Het vertelt knooppunten wanneer het downlinkvenster is voltooid, zodat de knooppunten nooit zenden wanneer de gateway niet luistert

4. Uplink-tijdslot: Vanwege de synchrone framing zijn de uplink-vensters gesleufd, wat ongeveer 100% meer capaciteit toevoegt. Dit wordt nog vergroot door voor elke verzending een variabel CSMA-venster toe te voegen.

5. Variabele kracht en spreidingsfactor: Het eindknooppunt ontvangt de RSSI van het framingbericht van de gateway en past dynamisch zijn vermogen en spreidingsfactor aan om overeen te komen met de link plus een instelbare margefactor. Dit maximaliseert de capaciteit, vermindert snelle vervaging en voorkomt het bovengenoemde probleem van dichtbij/veraf.

6. Kwaliteit van service: Knooppunten registreren een QOS-factor (0-15) bij de gateway, en dit beperkt hun mogelijkheid om toegang te krijgen tot kanalen in elk frame. Het biedt ook een manier voor de gateway om de uplink te beperken in tijden van congestie.

7. Multicasting: Door groepen knooppunten toe te wijzen aan multicast-groepen, is de hoeveelheid downlink die nodig is voor besturing en bestandsstreaming beperkt.

8. MTU van 256 bytes opgelost: 12 bytes is te klein voor de meeste toepassingen. Symphony Link biedt een vaste MTU van 256 bytes en verwerkt alle subpacketization (door SF) en nieuwe pogingen op de MAC-laag.

9. Firmware via de ether: Dankzij de krachtige multicast-functies in Symphony Link kunnen firmwarebestanden naar nodes worden gestoomd.

10. PKI-gebaseerde sessie AES-sleutels: Symphony Link maakt geen gebruik van versleuteling met vaste sleutels. Elk knooppunt heeft een beveiligde AES-sessie tot stand gebracht met behulp van Diffie-Helmann, met de openbare sleutel van het knooppunt die door de server wordt verstrekt. Dit staat in de hele branche bekend als het veiligste versleutelingsschema voor kanalen.

Meer weten? Neem contact op.