Including more fields in session data

[lucasgranberg]

To be able to delete the device for power saving we need to save the session data. This was achieved a while back but we should add more stuff to the sessiondata to be able to resume when we re-create the device.

Mainly we need dl_settings but maybe also some more fields.

Here is a snippet from the join process. https://github.com/ivajloip/rust-lorawan/blob/44c1f4bd6d173e7c4cd767acca470d535756c886/device/src/async_device/mod.rs#L146-L154

I would suggest (after talking with @lulf ) that we add the fields to JoinAccept and return it from self.region.process_join_accept. Then we could even pass JoinAccept or the needed fields to SessionData::derive_new and move the derive code for the different fields out of DecryptedJoinAcceptPayload.

With "fields" I mean these (dlsettings, RxDelay...): https://www.thethingsnetwork.org/docs/lorawan/message-types/#calculating-the-message-integrity-code-mic

Is this a good approach? Is there something I am missing?

[ivajloip]

Hi Lucas,

Thank you for starting this discussion! I am not sure if I understood completely your question, so please bear with me and let me know if I got this correctly. You would like to store setting such as dl_settings in a durable storage, so that the device can safely shutdown, etc. Then you would like region.process_join_accept to return an object called JoinAccept, which itself contains the decrypted JoinAccept message. This object also contains the devnonce and the reference to the credentials, so that it can be used to obtain the app and nwk sessioni keys, the dev_addr and all the other parameters. Assuming this is correct (but I am not at all sure), could you elaborate on how this is enabling or facilitating your goal of storing more data in the durable storage and were there other approaches that you considered? Thanks! :slightly_smiling_face:

[lucasgranberg]

Yes, doesn't make any sense to me either now that I read it a week later. I wrote a long reply and in the process it got clearer to me what we need. I think we could just extract the region from the device in the same way as we with the session. The region contains the needed join-accept stuff (dlsettings, cflist).

The region is probably not so easy to save to flash but I don't think we need to. It is enough to just have the data in RAM and re-join in case of reboot. Saving to flash seems to be a requirement in LoraWan 1.0.4 but that is only for the frame counters which is already in the SessionData which already can be saved to flash.

To achieve this we either need to have a get_region fn in Device OR have the region as a borrowed mut in Device so that it is freed when the Device is dropped (but then again we would need to do the same for get_session for consistency).

API wise it might not be the most clean solution to have two objects to store outside Device (region+session) but I think it is better than messing with the JoinAccept struct belonging to the state machine.

[lulf]

I'd prefer the get_region() on Device to avoid re-introducing the lifetimes we just got rid of.

[bldh]

I think it is important for the region data were able to be serialised and stored in flash, the main reason I can think of being some processors need RAM turned off for low power states.

[lucasgranberg]

I created a draft pull request. There is still no serde on the region stuff and I am not really happy with having stuff stored in the region like this. I will continue on monday

[bldh]

Hi Lucas,

There are variable sizing requirements across the LoRaWAN regions for session related data. I personally think having the region store and handle the region specific session data cleans things up a little bit and makes it clearer when working on that part of the code.