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.
Processing the Downlink Packet
Process the Bit Fields
The bit fields described in this section and shown in Figure 1, are returned with each downlink inside the Frame Control Octet and must be acted upon as described.
Figure 1: Bit fields highlighted in the LoRaWAN® downlink packet structure
Frame Acknowledge Bit (ACK)
The ACK bit is found in the Frame Control Octet inside the Frame Header within the MAC Payload, as shown in Figure 1, and is used to acknowledge receipt of a confirmed uplink.
Note
Learn how to send a confirmed uplink in the section Metadata of the Sending Messages Book.
After the end device has sent a confirmed uplink, it should await a downlink from the network server with the ACK bit set. The network server will only send the acknowledgement during the receive windows directly after the uplink was sent. If the end device is awaiting an acknowledgement, it should check that the ACK field in the downlink received in the Class A windows is set to 1. If the ACK bit is set to 1, the end device should consider the confirmed uplink responded to and execute any actions that are awaiting this confirmation.
Warning
If the end device receives a downlink following a confirmed uplink and the ACK bit is not set to 1, the uplink must have been received by the network server, but either the application data being transmitted could not be processed, or there is an issue with the network server confirming receipt of uplinks. If the receipt of the ACK is critical to the application use case, the application could resend the data in a new uplink but must not attempt retransmission of the original uplink. The FCntUp value passed in the FCnt field must be incremented. The application should not attempt to resend the data immediately to avoid bombarding the network but wait a period of time. You should define an upper limit to the number of attempts to send the data made, to avoid continually sending the same message indefinitely in the case of a network server issue.
Read more in Section 4.3.1.2, ‘Frame acknowledge bit and acknowledgment procedure’ (page 20) of the TS001-1.0.4 LoRaWAN® L2 1.0.4 Specification.
Frame Pending Bit (FPending)
The FPending bit is found in the Frame Control Octet inside the Frame Header within the MAC Payload, as shown in Figure 1.
If the downlink message being processed was received in one of the Class A receive windows then the FPending bit set to 1 indicates that the network server has more data to send. Unless there is a good reason not to, the end device may send an empty unconfirmed uplink as soon as possible, for the purpose of opening additional downlink windows and receiving this remaining data. This empty uplink would not need to contain any MAC commands nor any application data. Learn how to send an empty uplink in section Application Data and MAC Command Fields of the Sending Messages Book.
If the downlink message being processed was received in a Class B ping slot, the FPending bit is used to optimize Class B operations, as described in Section 4.3.1.4, ‘Frame Pending Bit’ (page 22) of the TS001-1.0.4 LoRaWAN® L2 1.0.4 Specification.
If the downlink message being processed was received in a Class C RXC window, the FPending bit must be ignored.
Warning
Take care when programming your device to ensure that the FPending bit is handled differently based on the type of receive slot the downlink arrived in. If you accidentally process the FPending bit received in a Class B ping slot or Class C window as if it were received in a Class A receive window, your end device could send unnecessary uplinks, believing there to be more data to receive when there is none.
Learn more about the FPending bit in Section 16.4, ‘Downlink Timing for Frame-Pending Frames’ (page 82) of the TS001-1.0.4 LoRaWAN® L2 1.0.4 Specification.
Adaptive Data Rate Control Bit (ADR)
The ADR bit is found in the Frame Control Octet inside the Frame Header within the MAC Payload, as shown in Figure 1.
The ADR bit is used by the adaptive data rate (ADR) feature. If the ADR bit is set to 1, this indicates that the network server can send ADR commands. If the ADR bit is set to 0, this indicates that the network is not able to use ADR currently.
Note
Typically, the network server only temporarily suspends supporting ADR, so the end device should continue passing up the ADR bit in uplinks if ADR is being used, even if the ADR bit is not set in a downlink. Learn more about ADR in the Implementing Adaptive Data Rate Book.