Hi,
does the session information of a node when using OTAA expire after some given time?
I found some old discussion here: LoRaWAN Session Termination/Expiration?, but nothing up to date.
Background: We experience some strange behavior where node uplinks are shown on the gateway traffic page but are not received on the application traffic page after the node idled (did not send data) for a few weeks.
All the best,
Matthias
Follow up: Looks like we ran into the maximum FCnt gap, as explained here: Troubleshooting Devices | The Things Stack for LoRaWAN
As far as I’m aware, TTS indefinitely stores the latest state of a device. The maximum FCnt gap only occurs when a device has sent 16k uplinks without being heard, which is a very rare situation. (Are you sending that many uplinks?)
If you are the builder of these devices, you could make it check once a week ( / every few-hundred or -thousand uplinks) whether it is being heard by requesting DeviceTime or doing a confirmed uplink, and if it fails once or twice, do a rejoin. Some off-the-shelve devices also have a similar strategy implemented.
But the most likely culprit would be that the (only) gateway that heard your device went offline for an extended period, which is the thing you would have to fix (and probably monitor with a quick check once a week).
BTW - how did you conclude that you run into the maximum FCnt gap?
If you are running into the maximum fcnt gap in weeks you should look at the uplink period.
Assuming 5 minutes between transmissions (which in 90% of the cases is already bordering on or exceeding the FUP limit) you would get 5 * 60 * 16383 =4.914.900 seconds. Which equals to 4914900/(606024)=56,885 days, so a little over 8 weeks.
No need for any recent LoRaMAC node based stack or LMIC as those have build in mechanisms to do this. Also ADR enabled devices should recover automatically if not already on SF12 (which a device uplinking that frequently should never be as it will exceed legal limits (at least in EU)).
Before non-Dutchies trip over this notation: in NL, we swap the . and , in decimal notation… go figure 
(yes, I ran the same calculation and was tripping on this difference as my computer is mostly configured in English but apparently the calculator uses Dutch notation…)
Yes, we are sending that many uplinks in this very special case. We are on a private, self-hosted TTN-based network and do not exceed the 1% max duty cycle (far away from it). But the gateway is a mobile one and only drives to the area every few months to collect the accumulated data (“drive by”).
@stevencellist We concluded that because in the end it exactly matched. We ran a calculation like @kersing did. Everything checked out. And all other source of error was checked before.
Glad to see that, because with a relatively small number of devices at the 1% limit you would render LoRaWAN unusable at a location. With 800 devices at 1% all 8 frequencies of a gateway would be in use 100% of the time, however due to the randomness of transmission times and frequency use, at about 25% of that number (so 200 devices) you start running into too many collisions (if using 1% airtime) for LoRaWAN to be usable at that location.
Given those numbers you can infer that even if not at 1% you can quickly cause issues for other LoRaWAN users in the vicinity.
Do the nodes know about the next window a gateway will be present? Because not transmitting between visits would greatly reduce RF pollution. Or you could consider mounting permanent gateways and reduce the transmission interval (which I’m sure you already considered but because of your issues with the counter window might become more pressing)