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
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
Comentarios
Comments powered by Disqus