Hi Everyone,
I don’t have an issue, but just a couple general questions regarding frame buffering: what is the limit on the number of frames that can be buffered and what happens when that limit is reached?
If my impression that they’re stored on the SD card is accurate, capacity likely exceeds practical utility by several orders of magnitude.
LoRaWAN really isn’t designed for delayed processing, and doesn’t permit out-of-order processing, so the more delayed frames you have buffered, the more challenging it’s going to be to get them submitted before current frames bump the frame counter and make buffered frames invalid.
If the network server is getting even the occasional current frame via another gateway, all the buffered frames will be treated as out-of-order and invalid.
Understood, and thank you for the reply! We are experiencing a large scale network outage for one of our LTE providers here in Canada and I’m just curious how much buffering we can hope for.
If you want to seriously rely on buffered frames, I’d consider creating a backfill processor that is willing to decode, validate, and insert them into a historical record outside of the rules imposed by the LoRaWAN spec.
Eg instead of “is this frame counter current” it would be “is this frame plausible, and does it without conflict fill a gap in the record?”
Ideally such a processor would trigger an alarm on an attacker’s backfill frame that is not plausible - for example, one that conflicts a frame count actually received via another gateway.
I’ve found it useful to have a task which created a permanent log of both the raw traffic uplinked from gateways, and the decoded and validated traffic output from the network server. This gives both the ability to debug problems, and the ability to go back later and reprocess history with an algorithm that has more insight into what actually happened in a failure situation, or in theory more ability to filter out an attack situation.