I see that loraserver can now set DeviceSessionTTL in the config file so that ABP & OTAA device session will cache in redis for a period of time. But in practical usage, ABP devices usually need much longer session TTL.
How do you think about separating this config item into ABPDeviceSessionTTL and OTTADeviceSessionTTL?
By the way the LoRa spec also said that ABP device’s frame counter should not be reset, but for now, when we reactivate ABP device, frame counter is also reset to 0. How do you interpret that?
This is (currently) not possible, ABP and OTAA is technically the same for LoRa Server, only in the latter case the device-session is created after an OTAA request. In case of ABP this is done using an API call.
How would it affect you when for OTAA devices the TTL would be as long as ABP devices?
By the way the LoRa spec also said that ABP device’s frame counter should not be reset, but for now, when we reactivate ABP device, frame counter is also reset to 0. How do you interpret that?
As a different subject I believe there are various topics on the forum covering this topic.
For example, if we want to sale OTAA and ABP devices to consumers.
We need to test the devices before they go into warehouse.
And we don’t know when the device will go to consumer’s hand, maybe several months.
When the consumer get the device and power on it, it should work properly.
For OTTA device, it’s OK, because it will join the network and the device session will be recreated.
But for ABP device, we need to reactivate it manually so that it can send & receive data from the network.
Do you see any issue with setting the TTL to a higher value globally (thus also for OTAA devices)? The TTL is there so that eventually a session expires, but this could also be x years. This would mean that Redis potentially would store a bit more device-sessions as it would keep track of OTAA devices a bit longer too, but is that an issue?
It depends on the contract with our customer.
Let’s say, if we have 10k device, how many RAM resource will it need for loraserver to save all the device session in redis?
this is the memory usage of a test session. As there is also a DevAddr to DevEUI mapping let’s make this 500 bytes (also the device-session can grow slightly depending the stored info). So for 10k devices this would be ~ 5MB of in-memory storage I’m not sure if that is worth the effort to split out the TTL in OTAA and APB devices
For the memory usage, it is ok. I observe that, every time an OTTA device joins in the network, there will be new keys added into the redis, because it is get new addr.
So after a period time, there will be too many keys in redis.
Yes they may not cost too much memory, but it’s a bit hard to manage so many keys, and most of them will never be used.
So I still think it’s better to split the TTL for OTTA and ABP devices.
Add an item in the config file is easy. And we can use the ABP device session TTL in the ABP device activation function. It will be a new parameter in the storage.SaveDeviceSession.
What would be the hard part? Basically the extra DevAddr keys are just pointers to the DevEUI. The actual device-session is stored under the DevEUI based key. Yes, this means there will be some extra keys in Redis that might not be used and eventually will expire, but I’m not sure what “too many keys” and “hard to manage so many keys” would effectively means.
Add an item in the config file is easy. And we can use the ABP device session TTL in the ABP device activation function.
This is only a small part of the solution. Please note that every time when a device-session is saved, the TTL is reset (as you want to renew the TTL ever time when the device is sending an uplink). Thus every time when you save a device-session, you must also read the device-profile to find out if it is an ABP or OTAA device.
For us, we may want to set the TTL for quite a long time, maybe 6 months. Sometimes we will have to use redis-cli to track some problems. If there are too many keys, and someone accidentally uses the command such “KEYS *”, it will cause the redis to block for a period of time. I have encountered this myself.
OK I see, in that case we can add the activation type to the DeviceSession itself, then every time we want to update the TTL, we can just read it from the session.
But this is not how you should use Redis Please note that with the latest version, also the gateway statistics are aggregated within Redis and more stats might be coming. So even when this config option would be added, it doesn’t solve your real issue probably.
When you want to debug the Redis storage, you should query by key, not execute KEYS * to list them all. As you can see in https://redis.io/commands/keys, the complexity of this operation is N where N is the number of keys in the database.
Warning : consider KEYS as a command that should only be used in production environments with extreme care. It may ruin performance when it is executed against large databases. This command is intended for debugging and special operations, such as changing your keyspace layout. Don’t use KEYS in your regular application code. If you’re looking for a way to find keys in a subset of your keyspace, consider using SCAN or sets.
As I said before, we can set the activation type in the DeviceSession, so we don’t need to read device-profile as long as the DeviceSession is in redis.
Sorry for using Chinese here.
What i mean is that, It is possible to define a higher TTL value now, but can’t tell what type of activation it is, this will bring a little more memory usage, which does’t seem to be a matter for most of us, and i really think adding an ‘type’ dimension to the relationship mapping of eui and session is not worth of the memory.
Actually I haven’t look into that part of source code in loraserver, and don’t know if I have some comprehension mistake here, but can we add an extra config for ABP device, make then use a different TTL value, when (re)activate it by API.
I believe there are various topics on the forum covering this topic.
I’m not sure if that is worth the effort to split out the TTL in OTAA and APB devices 
