Extending the life of your device (firmware updates over LoRa) - LoRa AMM
•
2 likes•4,706 views
This document discusses extending the lifespan of IoT devices through firmware updates and outlines some challenges and solutions. It proposes a standardized approach using multicast transmissions, forward error correction, and an update server to efficiently deliver firmware over constrained low-power wide area networks. An open-source reference implementation is available to demonstrate feasibility on current hardware within radio regulations.
Report
Share
Extending the life of your device (firmware updates over LoRa) - LoRa AMM
- 1. Extending the Life of Your Device Jan Jongboom | Johan Stokking
- 2. 2
- 3. 3
- 4. 4 IoT deployments target 10 years lifetime But 10 years is a really long time!
- 10. 10 Devices get a specific purpose Requirements change Standards change Vulnerabilities are found
- 11. 11
- 13. The road to firmware updates 13
- 14. 14Naive approach TX RX TX RX TX RX Firmware fragment Device 1 TX RX TX RX TX RX Device 2
- 15. 15Better approach RX Many firmware fragments Device 1 Device 2 RX Device N RX
- 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
- 22. 22Speed https://www.reddit.com/r/Eyebleach/comments/68r4rt/tortoise_taxi/ 220 bytes per second in real world scenario (SF9 @ 125 KHz, 2.5KM range in cities) 100KB Firmware size Transmission costs 7m30s (ideally) @ 10mA current
- 23. 23Standardization 'Remote multicast setup' and 'Fragmented data block transport'
- 24. Extensions 24
- 25. 25Link layer security is not good enough Firmware manifest Contains firmware hash Contains manufacturer and device class ID Signed with private key
- 26. 26Separate trusted and non-trusted code Secure element
- 27. 27Delta updates (from Mbed OS 5.5.7 to Mbed OS 5.6.1) © 2017 Arm Limited Full firmware update Delta update (bsdiff) Delta update (JojoDiff) Size 180 KB 6.5 KB 53 KB Delta update (JojoDiff, gzip'ed) 36 KB
- 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
- 35. Update Server 35
- 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
- 39. Example
- 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
- 47. 47Update Server Open source MIT License Available on GitHub Open API Designed for scale Built for The Things Network
- 48. 48 Demo time!
- 49. 49Conclusion Firmware updates are essential Possible, even with duty-cycle constraints Reference implementation available today For the specs: LoRa Alliance FUOTA WG