In LoRaWAN 1.0, should it generate downlinks even when not asked to do so? It seems TTN is only forcing a downlink when the node is using SF12. In all other cases, it seems that TTN will only piggy-back on existing downlinks (possibly not including bare ACKs for confirmed uplinks), or generate a downlink when the node set ADRACKReq
in an uplink. If the node does not set that, no ADR is received.
It seems the TTN implementation adheres to the LoRaWAN 1.0 specifications though that is not quite specific about this:
4.3.1.1 Adaptive data rate control in frame header (ADR, ADRACKReq in FCtrl)
[…]
If an end-device whose data rate is optimized by the network to use a data rate higher than its lowest available data rate, it periodically needs to validate that the network still receives the uplink frames. Each time the uplink frame counter is incremented (for each new uplink, repeated transmissions do not increase the counter), the device increments an ADR_ACK_CNT counter. After ADR_ACK_LIMIT uplinks (ADR_ACK_CNT >= ADR_ACK_LIMIT) without any downlink response, it sets the ADR acknowledgment request bit (
ADRACKReq
). The network is required to respond with a downlink frame within the next ADR_ACK_DELAY frames, any received downlink frame following an uplink frame resets the ADR_ACK_CNT counter.
…where “it periodically needs to validate that the network still receives the uplink frames” feels like it’s mainly about ensuring the uplinks were received, rather than describing a required part for ADR. But the specifications don’t seem to state that the network server needs to generate any downlinks itself.