Strategy for LoRaWAN with deepsleep 2

[_peter]

@livius

I do not have an sd card in my project and i need the lopy when it wakes up after the deepsleep send the payload without re-join

[Camot]

I have asked myself the same quations.

@_peter An easy solution I think would be ABP with disabled frame counter check.

@livius With OTAA everytime a devices comes out of deepsleep,TTN performs a join-procedure with the network, during which a dynamic DevAddr is assigned and security keys are negotiated with the device. I think it is not hard to imagine that a wake up every 5 minutes for example with a new join procedure is not the way the network is designed. If some more devices do that, the gateway would come to the sending limitations.

With ABP, which is not the preferred way, a frame counter check wil be performed. A device just woken up from deepsleep, starts with 0. The network will not accept the connection.

Therefore, the ability to store and reload the DevAddr and keys for OTAA or the frame counter for ABP would be required. A product that requires you to disable security features of the network is not best of the art.

[_peter]

@Camot That's exactly what I meant. Normally who uses the lopy in lorawan should use these escamotage? I do not think it's possible to use it in the right way. Or miss me something?

[Thosch42]

@_peter While I was planning a board with the OEM LoPy, I run into the same problem. Currently I think about a small I2C NVRAM to save DevAddr and keys. I think there's no other way. Possibly something similar could be implemented in a future release of the Expansionboard.

Cheers,
Thomas

[_peter]

@Thosch42 What you think seems to me very clever. This means, however, that it is not possible to have full functionality with the supplied hardware now. In your opinion, what can be the best compromise at this time?

[livius]

@_peter said in Strategy for LoRaWAN with deepsleep 2:

I do not have an sd card in my project

but you have internal flash where you can write files same as into SD card.

[Thosch42]

@livius Yes, that's right. But it depends a little bit on how often the keys change. I need to reed the datasheets and specs. It would be not very clever to stress the internal flash and kill the module slowly.

Cheers,
Thomas

[livius]

@Thosch42 said in Strategy for LoRaWAN with deepsleep 2:

It would be not very clever to stress the internal flash and kill the module slowly.

Yes, as i say before it is not recommended way - but you must test how offten you need to write.
But why not SD card? It is really cheap and small :)

[jmarcelino]

SD cards tend to consume a godawful amount of power so they're not a good pairing for generally very power efficient LoRa stuff :-)

I wouldn't worry too much about flash wear, by the time you've killed the flash by writing sequence numbers a new Py with proper deepsleep (and more importantly RTC NVRAM preservation) will be out :)

[livius]

@jmarcelino
one fet for control power of SD card start it read value and deinit and "close fet" :) same for write :)
I think the same as you here:

I wouldn't worry too much about flash wear

[papasmurph]

@_peter My experience: I tried testing for whether it had already joined, but that flag doesn't seem to be set until you attempt and succeed to join, indicating it's always "unjoined" (?) after a deep sleep, so it wouldn't have helped to save state. The service I connect to doesn't mind though.

[Eric24]

@papasmurph It seems that the issue is not so much about whether it's possible to re-join, but the additional "on time" and radio power budget required to do so. Ideally, a LoRaWAN device should join very infrequently, sleep most of the time, and minimize its "on time" and radio usage (i.e. no re-joining) as much as possible. And that's not only a battery-life issue, but can also become a duty-cycle or simply system capacity issue at scale.

Ultimately, I think storing the information needed to wake-up and transmit without re-joining is a necessity (especially for battery-powered devices). How that information is stored is another matter (the RTC NVRAM would be ideal, as soon as it's supported). But the question your comment brings up is what to do about the "joined" flag? If it's always necessary to re-join after deep sleep, that would be a significant issue. Has anyone else been able to "force" a joined state after deep sleep?

[jmarcelino]

@Eric24
That's not possible yet because you have to tell the LoRa stack: "here reuse these keys I stored somewhere to connect" and that's not possible yet. Of course all the source code is out there so if anyone wants to have a go don't let me stop you. That's a functionality me and I'm sure many others will need for larger deployments so, even if Pycom doesn't get around to doing it, it'll come at some point.

The other problem - but that's more an issue with LoRa and similar protocols - is it's not possible to know if the keys generated for an OTAA session are still valid without actually getting a response from the network, something you get for "free" with a fresh join. So always doing a join is safer. It's a balancing act.

[Eric24]

@jmarcelino Right--ability to set keys will be needed. Regarding not knowing if they keys are valid, just thinking out loud...if you have some knowledge (or control) of the server behavior, you could know how long until the keys expire; let's say they last for 24 hours; given that, maybe the device (using the RTC) transmits without re-join for up to 23 hours (or so) and then re-joins on the next interval. Any flaw in that logic? Of course my objective here is to maximize battery life, and for a device that reports every 5 minutes, all that re-joining will add up.

[jmarcelino]

@Eric24 ]
If you have some control of the network some good advice I've heard - but not implemented personally yet - is to forget OTAA, run ADP with frame counters relaxed and implement your own authentication system using for example a crypto chip like the ATECC508A

[Eric24]

@jmarcelino Hmmm. I suppose so, if you have control of the network (although some would argue that this would be less secure). But I was also thinking about public networks where you don't have control, but could have specific knowledge of key lifetimes. Of course there's no technical problem with re-joining on every transmission, but it's definitely not optimal. It makes me wonder if a lot of LoRaWAN implementations are actually doing just that, because it's easier to implement?

[papasmurph]

Anyone knows what approach thingamagogs like this use? I guess ABP and pre-generated random keys, but I didn't find any details: http://ecubelabs.com/integrated-waste-management/ultrasonic-fill-level-sensor/

[Eric24]

@jmarcelino Question about the ATECC508A that you mentioned (as it relates to LoRaWAN, not "my own" authentication system): Does it support AES-128? I can't find any mention of anything other than AES-256, which makes it useless for working with LoRaWAN keys, etc. I was looking at the ATAES132A for this purpose. Any experience or thoughts on this?

[Eric24]

@jmarcelino I did some additional research on the topic of expiring keys, and based on this post at TTN (https://www.thethingsnetwork.org/forum/t/otaa-node-sleep-mode/5188/7) and a review of the LoRaWAN specs, it appears that the server will never expire the keys after a join (the node can re-join if it wants new keys or if the message counter rolls over or is about to roll over). Although I have found mentions of session key expiration, so at least that concept is "out there". Do you have specific experience with networks/servers that expire the OTAA session keys?

Bottom line, if the keys aren't expired by the server, then the idea of reusing the keys without re-joining is pretty straightforward (pending the ability to "set" the keys from some non-volatile memory).

[jmarcelino]

@Eric24
Well TTN not long ago 'expired' all OTAA keys when they moved servers to production, the expectation was that OTAA nodes would pick up the new keys automatically. From what I understand this expectation is still in place at TTN and other networks.

Also keep in mind there is a valid window for LoRaWAN frame counters - maxFCntGap = 16384 in the TTN source - for example if a node sends 16384 packets that for some reason (out of range, gateway down..) don't get picked up by TTN there will be a mismatch and TTN won't accept further data from the node - so you may want to reset those counters occasionally via rejoin.