16. 16But... how do we do this?
1. Instruct devices to use a new set of keys (same for everyone)
2. Instruct devices to wake up at the same time.
3. Gateway can transmit to all devices with one message.
Problem: low QoS and uni-directional
17. 17Setting up the device
Device Address: 2632AB09
Multicast Key: 9310E28FA291...
18. 18Setting up the device
Packet size: 204 bytes
Packet count: 491
Padding: 16 bytes
20. 20Dealing with low QoS
CRC hash of firmware
(sent with device's own credentials)
OK!
21. 21Dealing with low Quality of Service
http://www.inference.phy.cam.ac.uk/mackay/gallager/papers/ldpc.pdf
CRC hash of firmware
(sent with device's own credentials)
OK!
Forward error correction
25. 25Link layer security is not good enough
Firmware manifest
Contains firmware hash
Contains manufacturer and device class ID
Signed with private key
29. 29Network congestion
Sending a lot of data has negative effect
on network
Higher data rate is better
RX sensitivity is useless when someone
screams next to you
Spread spectrum helps against narrowband
interference
30. 30Gateway selection
Plan updates in advance, reserve slot on the
Network Server
Gateway selection strategies, combination
possible:
1.Use highest data rate
2.Round-robin between gateways
3.Drive over to site and deploy temporary
gateway
31. 31Gateway selection
Use highest data rate
Limits number of devices that gets covered
by one gateway
But: higher capacity on gateway
(less channel utilization)
And: highest throughput
32. 32Gateway selection
Round-robin between gateways
Define group of devices that are covered by the
same set of gateways
Downlink scheduling round robin across gateways
May result in higher packet loss on specific
gateway-device links
But: higher capacity per gateway (less channel
utilization)
33. 33Gateway selection
Temporary gateway
Dedicated to firmware update
Expensive, but cheaper than replacing the
device or performing a manual per-device
update through cable (if even available)
34. 34Spectrum regulations in EU
Unlicensed does not mean unregulated
1% duty cycle in 868 MHz band, except at
869.525 MHz
Downside: it's the RX2 channel
36. 36Update Server
• Update scheduling
• Multicast groups
• Fragmentation sessions
• Device status and progress reporting
• Performs binary diff
• Performs forward error correction
• Exposes an API
37. 37Update Server
Performs binary diffs:
• Device registry with current firmware version
• Has access to images of firmwares
• Calculates diff of device’s current firmware and
new firmware image using JojoDiff
38. 38Update Server
REST API
Integration with existing update flow
(e.g. Arm Mbed Cloud, Eclipse Hawkbit)
Single call to start
Device status and update progress
40. 40Real world example of required network capacity
EU868 DR3 (SF9, 125 KHz)
US915 DR11 (SF9, 500 KHz)
Total time
3m36s
2m09s
Incremental update: 36 KB, no round robin, 10% packet loss
Packets Correction
336
170 25
51
Time p/p
262 ms.
559 ms.
500 mAh battery, 15 mA RX current = 0.18% of battery per update
42. 42Device side
Multi-Tech xDot (Cortex-M3, 32K RAM)
Application on top of LoRaWAN 1.0.2
Mbed OS 5.5
L-TEK FF1705, available from Nov. 2017
https://os.mbed.com/platforms/L-TEK-FF1705/
43. 43Device side
Device client and bootloader
Open source, Apache 2.0
No security audit!
Requires flash (on-chip or external)
https://github.com/armmbed/fota-lora-radio
44. 44Device side
Forward error correction
C++ library
Uses less than 2K of RAM, flash as storage layer
https://github.com/janjongboom/mbed-lorawan-frag-lib
45. 45Device side
JANPatch
Portable C library
Made for embedded devices
Everything in flash (<1K of RAM required)
https://github.com/janjongboom/janpatch
46. 46Network side
Network and update server
Multicast and data block specs
Forward error correction
Network planning
https://github.com/TheThingsNetwork
49. 49Conclusion
Firmware updates are essential
Possible, even with duty-cycle constraints
Reference implementation available today
For the specs: LoRa Alliance FUOTA WG