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

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

Uplink Messages

• Device -> Network Server

• Relayed by one or many gateways

Downlink Messages

• Network Server -> One Device

• Relayed by a single gateway

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

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

Downlink Ping Messages

• Can be unicast or multicast

  • Devices must belong to multicast group

  • Must share the same multicast address and associated encryption keys

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