Would it make sense to purge the previous sessions redis devaddr when a new join occurs?

ChirpStack Network Server
1

Would it make sense to purge the previous sessions redis devaddr when a new join occurs? We have a high volume of keys with lora:ns:devaddr.

We had an instance where we had latency within our chirpstack such that confirmed acks were not making it back to the devices and they were rejoining the network very frequently causing our redis keyspace to go up to 100% with millions of keys very quickly. We have the TTL on device sessions at 31 days (which i believe is the default) and under normal circumstances we’d like to keep it that way. However, if the old keys could be purged we would not have had an issue with our key space.

1 Like
2

Note that the DevAddr space is smaller than the DevEUI space. Therefore it is not unlikely that two devices (with different DevEUIs) share the same DevAddr. That is the reason why the DevAddr key in Redis is a set of DevEUIs.

(If you are using a LoRa Alliance assigned NetID, then the DevAddr space also depends on the NetID type that was assigned to you. The different NetID types are documented by the LoRaWAN Backend Interfaces Specifications)

1 Like