I have a question about the default behaviour: Lets assume some devices worked normally. Now, we disable the gateways or switch the LNS or whatever, so the devices do not receive any downlinks any more, neither MAC command downlinks nor application downlinks.
I am aware that default ADR implementation will cause the device to go up one SF per 64 uplinks without any received downlink and I can observe that pattern.
But: What does happen when the device reaches SF12?
Does it keep on sending uplinks on SF12 forever
or does it attempt to rejoin after X SF12 uplinks without any answer from the LNS?
I searched the LoRaWAN 1.0.3 specs but did not find anything in there about this.
To answer your thread title first - yes or no! It is entirely down to how the node is programmed to behave. Some will if you have programmed them to do so. Some commercially available nodes use a ‘watchdog’ like mechanism to monitor occasional downlinks to then trigger a new join in the event of a predetermined number of missed downlinks of after a predetermined time, or atleast trigger SF back off. (Example would be say Laird RS1xx t&h sensors). Note use of occasional word here as downlinks should be avoided/used sparingly due to impact on GW and rest of community. (Note TTN FUP is max 10 dl /day - and even that should be treated exceptionally/sparingly) More usually the device watchdog will trigger the device to step up tx power, at SF7, to legal limits and then start to step up through the SF’s, before finally triggering a rejoin as last resort. Which brings us to
More usually ADR is there to step down the SF’s and then to reduce Tx power for a fixed device to optimise/minimise air time and battery life. The actual number of messages used to determine where the node moves to in terms of TXpwr and SF is usually set by Network policy - it may not neccessarily be 64. e.g. IIRC TTN moves settings on ADR enabed devices via MAC command after approx 20/22 messages. A similar mechanism might be used by the node - under local watchdog/programming control - to back off if it feels it is loosing connection to the network.
Again, what have you or vendor programmed the node to do? Some will carry on until battery exhausted in vain hope it might eventually get a connection, others will retry backing of the time period before next attempt under some algorythm control in order to conserve battery, with some sleeping for extended periods before retrying. Perhaps in the hope that a blocking object eventually moves (a technique often used by say in ground sensors (parking, water/other meters etc.) in hope that say a temporary refuse skip dropped on top will eventually go away! ). Note also (again IIRC) LoRaWAN calls for NS to not allow devices to join at SF11 or SF12 - they can back off to that where needed, some networks enforce this others dont.
). Note also (again IIRC) LoRaWAN calls for NS to not allow devices to join at SF11 or SF12 - they can back off to that where needed, some networks enforce this others dont.