Confirmed uplinks aren't acknowledged while the downlink queue is blocked

[jamesl-dm]

Summary

When there is a large downlink in the downlink queue, which cannot be sent at the current data rate, it stays in the queue until the end node increases data rate, and the downlink becomes deliverable. During this time:

• MAC commands addressed to the end node, like LinkADRReq's to increase its data rate, work as expected
• However, if the device sends a confirmed uplink, the network will NOT send an acknowledgement, which seems wrong

I suspect that a downlink is being prepared with the acknowledgement bit set, and the queued downlink payload. And then that downlink is being deferred because it is too large. The expected behaviour is to send an empty downlink with the ACK bit set instead.

Steps to Reproduce

1. Disable ADR on an end node, and fix it to a high spreading factor
2. Queue a large downlink, ie. 100 bytes, that cannot be downlinked at the selected spreading factor
3. Then send a confirmed uplink from the end node

What do you see now?

The confirmed uplink is ignored.

What do you want to see instead?

An empty downlink with the ACK bit set.

Environment

I've tested in AU915.

How do you propose to implement this?

In generateDataDownlink, if device requires ack, ensure downlink is always generated (e.g. with empty payload, as suggested). Make sure that no MAC-layer spec-defined guarantees are broken this way.

How do you propose to test this?

By verifying that the ACK is sent, even if the downlink queue is blocked.

Can you do this yourself and submit a Pull Request?

No

[adriansmares]

I can confirm this bug - I'll take a look.

@johanstokking what should we do in these cases where the frame is too big - drop the downlink or stall the queue ? (we need to send the ACK always, but just as a general question)

[johanstokking]

@johanstokking what should we do in these cases where the frame is too big - drop the downlink or stall the queue ? (we need to send the ACK always, but just as a general question)

Then fail that downlink message.

[adriansmares]

I've ran the tests again and this has been fixed in the meantime. Test procedure on AS923 device:

• Erase mac-settings.use-adr and mac-settings.adr-margin.
• Set mac-settings.adr.mode.static.data-rate-index to 2 and mac-settings.adr.mode.static.nb-trans to 1.
• Wait for the device to switch to DR2 (SF10) and NbTrans 1.
• Schedule 100 bytes downlink (DR2 allows for maximum 11 bytes of application payload).
• The downlink is failed on the next uplink and the acknowledgement is sent.