Separating ABP & OTAA Device Session TTL


#1

Hello,

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?

Thank you!
Best regards!


#2

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 :wink: I believe there are various topics on the forum covering this topic.


#3

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.

OK, i will search it.

Thank you.


#4

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?


#5

Yes, I know we can set TTL to a longer time. But it seems not so RAM efficiently. :grinning:


#6

How many OTAA and ABP devices are you planning to host?


#7

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?


#8
127.0.0.1:6379> memory usage lora:ns:device:0101010101010101
(integer) 444

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 :slight_smile: I’m not sure if that is worth the effort to split out the TTL in OTAA and APB devices :wink:


#9

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.

Any idea about this?


#10

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.


#11

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. :sweat_smile:

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.


#12

But this is not how you should use Redis :wink: 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.


#13

老铁,个人觉得这样做对于这个架构不是很好,因为每次更新还去查device-profile不是会很久?


#14

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.


#15

增加TTL时间总体来说是可以的,只是没办法区分OTAA和ABP,代价就是稍微多一些内存,而本身在这个eui->seesion这个关系中加一个type纬度,会提升系统复杂度,但实际上我也没仔细研究过,或许如果你要实现区分ABP让ABP设备能够活更久,可以修改逻辑,在ABP手动激活的时候特定修改这个TTL?不知道是不是这样理解。


#16

This is an English forum, please keep the conversation in English :slight_smile:


#17

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.