I am building a device that connects to chirpstack over OTAA. The device goes into a deep sleep mode for 5 minutes, and only sends data every 5 minutes. The deep sleep clears the SRAM of the node, so the Network and Application session keys are lost. I could store them in EEPROM or flash memory, so after waking up, the device uses the existing ones, and doesn’t have to go through the JOIN process every 5 minutes. The downside is the session keys would never get renewed. What would you guys recommend me to do? JOIN again every 5 minutes (with the added traffic as a result), or just use the same session keys indefinitely (less secure I guess)? Or is there a provision for this in the LoraWAN standard that enforces a rejoin periodically?
Cheers.
if your mcu has fram you can use it to store this keys.
Joining should probably be only be done after battery replacement or after pressing a button or something.
I would think deep sleep is a bit overkill when sending every 5 minutes unless you can store the keys in non-volatile memory. Perhaps choose a MCU with efficient sleep modes.
I guess I didn’t ask my question right (wasn’t exactly sure what to ask). I know I can store the data in flash, or indeed go to a less deep sleep mode and keep RAM. I meant to ask more about the LoraWAN standard/chirpstack side of things.
So I guess there is no specific provision for this in LoraWAN right? I read on some forum post (for TTN) that I would need to do OTAA the first time, and then store the application and network session keys and frame count, and do an ABP join in subsequent boots? Is that right? Someone also mentioned somewhere I may need to store ADR frequency stuff on the MCU? If I make a device profile in chirpstack that supports OTAA, it will still support ABP as well right?
Is this an uncommon use case? On one hand I don’t want to do anything very exotic that isn’t supported and may likely result in issues that are hard to diagnose/solve. But on the other hand, I want to stretch battery life as much as I can. I appreciate the input!
After reading the answers, I turned the question upside down and googled for the embedded side of things instead of googling the LoraWAN standard/chirpstack side of things, and that gave me a lot more interesting results.
This is a good discussion, for those interested: https://www.thethingsnetwork.org/forum/t/deep-sleep-and-otaa-m328p-lmic/27199/5
Basically, my use-case is wrong indeed. A low power sleep current of <1uA is fine, because the wake power consumption will weigh much more on the total battery life than the sleep power consumption. So like @darkfader said, the deep sleep mode that looses flash is probably overkill and I should just keep RAM intact and avoid the whole issue.