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
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
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