Missing ACKs for confirmed uplinks when different RX1Delay is used

[frbehrens]

Summary

When the RX1Delay parameter is decreased (even with minor difference to 4s) the device does not receive acknowledge downlinks for all confirmed uplink messages. Furthermore, the downlinks are not even seen as scheduled in the console.

Steps to Reproduce

1. Set the RX1Delay for the device to 4 seconds.
   ttn-lw-cli dev set ... --mac-settings.desired-rx1-delay RX_DELAY_4
2. The device joins the TTN network.
3. Send 3 (or more) confirmed uplinks on after the other (without delay).

What do you see now?

All uplinks sent by the device are confirmed. But not for every uplink a confirmation downlink is scheduled, so the device repeats the uplink. For the repeated uplink a confirmation downlink is always scheduled (and received from device). In the displayed example I miss the downlink links for uplink frame counters 1 and 3.

What do you want to see instead?

I want to get ACK downlinks for every confirmed uplink. That works well when the RX1Delay is changed to 5 seconds or above.
ttn-lw-cli dev set ... --mac-settings.desired-rx1-delay RX_DELAY_5

Environment

I use a LoRaWAN 1.0.4 compatible node, that was already used on the TTN v2 stack. The region is EU-868 on eu1.cloud.thethings.network, v3.11.1. The transmission conditions are very good, there is no packet loss with DR5/SF7 and SNR on network is between 9 and 12.

How do you propose to test this?

see steps above.

Can you do this yourself and submit a Pull Request?

No, I don't have a test environment.

[adriansmares]

So we've finally analyzed this and can confirm that the Network Server behavior is racing. The bug report here is that if uplinks are sent 'as fast as possible' (as soon as RX2 closes), the NS may sometimes consider that the previous acknowledgement came after the current uplink, and avoid sending an ACK.

We will make the acknowledgement decision no longer matter on the timing of the uplink.