3 - Receiving Messages
Messages sent from a network server to an end device are referred to as downlinks. These are sent to the end device via a single gateway. If there are multiple gateways near a device, the network server will select the most suitable gateway to broadcast from. This means the end device does not need to consider de-duping.
Devices operating in Class A mode only receive downlinks during the receive windows opened following an uplink, as described in the section Opening Receive Windows of the Sending Messages Book.
Devices that support Class B mode as well as Class A can receive additional downlinks in receive windows opened at fixed time slots. Read more about Class B mode in the Class B Book.
Devices that support Class C mode as well as Class A can receive additional downlinks at any time. Read more in the Class C: Continuously Listening for Downlinks book.
Todo
Fix link
In this book, you learn how to receive and handle downlink packets using the LoRaWAN® 1.0.4 specification.
Retransmitting Uplinks
There are two slightly different approaches to retransmission which depend on whether the uplink was a confirmed uplink or an unconfirmed uplink.
For both confirmed and unconfirmed uplinks, the number of times the end device retransmits the original uplink frame is defined by a value referred to as NBTrans. The default value of NBTrans must be set to 1, as described in section Step 3D: End Device Handles Join Accept of the End Device Activation Book.
When the end device uses ADR, it may receive the LinkADRReq MAC command with the NBTrans field which requests the end device update its NBTrans value. Learn how to locate and process the LinkADRReq NBTrans field in section Retrieve NBTrans Updates of the Implementing Adaptive Data Rate Book.
Note
The end device is required to reset the NBTrans value back to 1 during the ADR backoff procedure, as described in section ADR Backoff of the Implementing Adaptive Data Rate Book.
For unconfirmed uplinks, if no downlink message is received within the Class A receive windows, the uplink is retransmitted NBTrans times, or until a downlink is received within the Class A receive windows. Once a downlink is received, no further retransmissions must be made. It is recommended that the time between retransmissions is randomized and follows a different sequence for every end device, ensuring that groups of end devices do not all broadcast at the same time. Read more in Section 3.8, ‘Avoiding Congestion Collapse’ (page 16) of TR007 Developing LoRaWAN® Devices V1.0.0.
For confirmed uplinks, if no downlink message with the ACK value set is received within the Class A receive windows, and the NBTrans value is greater than 1, the end device must wait at minimum RETRANSMIT_TIMEOUT seconds after the RECEIVE_DELAY2 seconds have run out before attempting to retransmit. RETRANSMIT_TIMEOUT is defined as a random delay between 1 and 3 seconds in Section 2.3, ‘Default Settings’ (page 26) of the LoRaWAN Link Layer Specification v1.0.4. In addition, you may increase the delay, enforcing additional randomness per end device in that delay, as described in Section 3.8, ‘Avoiding Congestion Collapse’ (page 16) of TR007 Developing LoRaWAN® Devices V1.0.0. Once a downlink with the ACK bit is received, no further retransmissions must be made.
For both confirmed and unconfirmed uplinks, the FCntUp value must not be incremented on the device and the FCnt value in the uplink packet must remain the same as the original transmission.
Retransmissions must be broadcast by following the same channel, data rate, and TX Power rules as would be followed when sending a new uplink, continuing to iterate through the channel list and continuing through the backoff process if the end device is working through a backoff process. You must not simply use the exact same transmit settings as the previous uplink, since this would not increase the likelihood of the message getting through.
No new uplinks may be transmitted during retransmission, until retransmissions are complete or have been stopped due to the receipt of the expected downlink.