Multiple Downlink Messages being Received on Single Uplink


We are doing some testing with the RAK 3172 module and have noticed some unexpected behavior. We have the 3172 configured in Class A mode and are testing a workflow where the end node will send an uplink and receive a downlink queued on the Lora Network Server. In situations where multiple downlink messages are queued on the network server, the 3172 will receive all of the downlink messages in succession after a single uplink message. This is not expected behavior as defined in the Lorawan specs. We would expect at most 2 downlink messages(1 per receive window). We are using confirmed uplink messages and using AWS IoT Core for Lorawan for the backend/Lora Network server. This has been tested using confirmed and unconfirmed downlinks. This behavior has been observed on multiple different gateways running as Basics stations. Can someone explain why this behavior is occurring? Is there a configuration that we are missing?

Thank you,

Depending on what exactly is happening, this may be within the spec - particularly if the node is actually listening to receive the additional downlinks.

My guess would be that when the FPending bit s set, the node’s stack is on its own queueing an extra empty uplink and sending it, to obtain the extra downlinks.

(And if the downlink was confirmed, the device would basically have to do so - the confirming uplink would implicitly double as a poll for additional downlinks)

Otherwise, even the if the network server commanded the gateway to transmit, I don’t see how the node would be listening to receive it.

You could probably confirm this by looking at the raw data, or logging the node’s output to a terminal program that timesstamps each line, presumably you’d see added time delay of the TX / RX1 cycle between each subsequent downlink.

Anyway, if there actually were any out-of-spec behavior of the network server (which there does not appear to be) that would be something you’d have to pursue with its provider, AWS.

Also FYI the RX2 window is nullified if a message was received in RX1:


Thank you Chris, this is incredibly useful. I was not aware of the Fpending bit. I looked into the packets being transmitted and it is happening exactly as you prescribed. The 3172 sends an empty packet up to trigger the retrieval of the next packet everytime the Fpending bit is set. This is not out of spec as you said , but it would be nice if we had the option of how to handle the reception of multiple downlinks in situations where we may want to limit total transmissions. Another module we have tested sets a flag that can be accessed via an AT Command denoting the Fpending bit. I see the merits in both implementations.

Thank you,

You might examine if you could make your custom downlink format able to accommodate multiple messages in one packet. In many regions downlinks have four times the bandwidth of uplinks so can move a bit more data, and while minimizing gateway transmit time is important (because a transmitting gateway cannot receive from any other node) one larger packet skips sending the rather substantial LoRaWAN protocol overhead a second time.

Yea that isn’t a bad idea. I think we need to keep our downlinks smaller for flexibility for now. Thank you for your help.

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.