Ir al contenido principal

This is my blog, more about me at marianoguerra.github.io

🦋 @marianoguerra.org 🐘 @marianoguerra@hachyderm.io 🐦 @warianoguerra

LoRaWan Overview

LoRaWAN

  • Network Protocol Candidate Specification

  • Optimized for battery powered end-devices

    • Fixed

    • Mobile (as in, they move, not phones)

  • Network Topology typically is start-of-stars

  • Network Operators can't secretly listen on application data

Topology

/galleries/misc/network-topology.jpg

Source: http://technicalbeans.com/images/Network%20Topology.jpg

Communication

All Communication is bidirectional, uplink traffic should dominate:

+---+
|   |
+---+

Device
           LoRa or FSK   +---------+   IP   +---------+
    +---+    (radio)     |         |        |         |
    |   |  <---------->  |         <-------->         |
    +---+                |         |        |         |
                         +---------+        +---------+
    Device
                           Gateway         Network Server
   +---+
   |   |
   +---+

   Device
  • Communication spread out on different frequency channels and data rates

  • Data Rates between 0.3 kbps and 50 kbps

    • Max ~ 45 tweets/s (extended ASCII only ;)

    • Just the text w/o protocol overhead

    • Don't expect audio, video or any kind of streaming

  • Encryption of payload

    • AES 128 bit key length

    • One key for each FPort

  • MAC Commands

    • For Network Management

    • Invisible to Application Layer

Devices Classes

  • Class A: Baseline

    • Uplink transmission

    • Followed by two short downlink receive windows (RX1, RX2)

  • Class B: Beacon

    • Allow more receive slots at scheduled times

    • Synchronize by a beacon from the gateway

  • Class C: Continuous

    • Nearly continuos open receive windows

    • Only closed when transmitting

    • Lower latency, but more energy usage

  • All devices implement at least class A

Receive Windows

  • After uplink at configured periods

  • If msg received for current device on RX1, RX2 doesn't happen

    • Max one downlink per uplink on Class A

  • Can't transmit from last transmit until after RX2 window

+------------------+                  +-----------+              +------------+
|                  |                  |           |              |            |
| Transmit         |                  | RX1       |              | RX2        |
|                  |                  |           |              |            |
+------------------+                  +-----------+              +------------+

<------------------><---------------->
   Transmit Time         Receive
      on Air             Delay 1

                    <------------------------------------------->
                                      Receive
                                      Delay 2

MAC Message Types

  • Join Request/Accept

    • For Over the air Activation

  • Unconfirmed Data Up/Down

    • No ACK required

  • Confirmed Data Up/Down

    • ACK required

MAC Messages

  • Can be standalone messages

    • Always encrypted

  • Or "Piggyback" on next message

    • No encryption

  • Unknown messages ignored

ACK Messages

  • Can be standalone messages

  • Or "Piggyback" on next message

End Device Activation

To participate on a LoRaWAN network

Over the Air Activation

  • Needs join procedure

  • Requires fields set on device

    • DevEUI

    • AppEUI

    • AppKey (AES 128, derived from root AppKey)

  • Network Key provided

    • Allows network roaming

Activation by Personalization

All info stored on device on setup

Information Stored after Activation

  • Device Address

    • Two parts: Network Id and Network Address

  • Application Identifier

    • Global ID, uniquely identifies owner

  • Network Session Key

    • Used for MIC generation

    • Used for MAC only message encryption/decryption

  • Application Session Key

    • Used to encrypt/decrypt payload and for MIC

Class B Devices

  • Devices mobile or fixed that require to open receive windows

    • At fixed time intervals (ping slots)

  • Class B implements Class A

  • All gateways must synchronously broadcast a beacon

  • Provides timing reference to devices

  • Devices start as Class A and can switch to B when detect a beacon

  • If no beacon is detected for 120 minutes, devices switches back to Class A

Class C Devices

  • Used for applications that have suficient power available

    • cannot implement Class B

  • Will listen with RX2 window parameters as often as possible

  • No message to tell the server that it is a class C node

    • App must know

  • Like Class B, can receive multicast downlink frames