I have a question about the downlink path from TTN to a device. If the device is off-line, sleep, out-of-range, etc and a downlink byte(s) is sent to it, either via the API or simply from the console – is there a way to get delivery status from a network routing level, not application level?
The application ACK can easily be built into one’s app but then that will require additional exchange of bytes back and forth so my question is whether the network layer ACK is somehow exposed to the end user? If yes, how?
Or is there a network layer ACK to begin with? Ping me back if I’m misunderstanding the network layer architecture of TTN on a more fundamental level
TTN implements LoRaWAN Class A only, which means that downlinks can only actually be transmitted in direct response to an uplink, exactly one or two seconds later.
So any queued downlink request would just sit in the servers untransmitted.
One should really minimize the usage of downlinks in TTN, and consider them something that will be moved unreliably when there is an opportunity.
This means there are many applications (eg, control…) for which TTN is really not suitable. In some cases other LoRaWAN implementations with class C are, in other cases they just aren’t a good fit for LoRaWAN at all.
