LoRaWAN 1.0.4 Specification in Depth For End Device Developers

Class B downlinks use the same format and can be interpreted in the same way as Class A downlinks, with the following exceptions:

• The FPending bit in Class B downlinks does not share the same meaning with the FPending bit when sent in Class A downlinks. Read section 9.2 ‘Downlink Frames’ (page 54) of the LoRaWAN® Link Layer Specification v1.0.4 to understand how the FPending bit in a Class B downlink is used to prioritize ping slot sequences in the event of ping slot collision.

• Class B downlinks may not contain MAC commands. A downlink containing MAC commands must be ignored.

If the Class B downlink was multicast, in addition to the above considerations the end device must also verify that the ACK bit is set to 0 and the FType field is set to 011 (unconfirmed data downlink), otherwise the entire frame must be discarded.

Section Processing the Downlink Packet of the Receiving Messages Book explains how to interpret Class A, B, and C downlinks.

If the end device receives a confirmed downlink (the FType field is set to 101), the end device must send a Class A uplink with the ACK bit set to 1 (a response) within the time frame described below.

The end device must not transmit the response before the time defined by RETRANSMIT_TIMEOUT plus the maximum time on air of an uplink frame. The value of RETRANSMIT_TIMEOUT is a random delay of between 1 and 3 seconds, as defined in Section 2.3, ‘Default Settings’ (page 28) of the RP002-1.0.4 LoRaWAN Regional Parameters specification.

If the end device is not using ADR and is not setting the ADR bit in uplinks, the Class A uplink response must be sent before the end of the CLASS_B_RESP_TIMEOUT, 8 seconds, as defined in Section 2.3, ‘Default Settings’ (page 28) of the RP002-1.0.4 LoRaWAN Regional Parameters specification.

If the end device is using ADR and is setting the ADR bit in uplinks, the Class A uplink response must be sent before the end of the period derived using the algorithm in Section 9.3.1, ‘Unicast downlink ping frame format’ (page 55) of the LoRaWAN Link Layer Specification v1.0.4:

CLASS_B_RESP_TIMEOUT * NbTrans + RECEIVE_DELAY2 * (NbTrans-1)

The variables used in this algorithm are defined as follows:

• Class B response timeout (CLASS_B_RESP_TIMEOUT)

  Defined as 8 seconds, as described above.

• Number of retransmissions (NbTrans)

  NBTrans defines the number of times the end device will retransmit the original uplink frame for both confirmed and unconfirmed uplinks. 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 requesting the end device update its NBTrans value. If the end device accepts this update and responds with an LinkADRAns, it must instead use this NBTrans value. Learn how to locate and process the LinkADRReq NBTrans field in section Retrieve NBTrans Updates of the Implementing Adaptive Data Rate Book.

  During ADR backoff, the NBTrans value is reset to 1. Learn more in section ADR Backoff of the Implementing Adaptive Data Rate Book.

• RECEIVE_DELAY2

  This is the amount of time the end device waits after the end of Class A uplink transmission before opening the second receive window. RECEIVE_DELAY2 must be set to RECEIVE_DELAY1 plus one second, as defined in Section 2.3, ‘Default Settings’ (page 28) of the RP002-1.0.4 LoRaWAN Regional Parameters specification. RECEIVE_DELAY1 refers to the amount of time the end device waits after the end of Class A uplink transmission before opening the first receive window.

  Note

  Given RECEIVE_DELAY2 requires knowledge of the RECEIVE_DELAY1 value, it is important to discuss RECEIVE_DELAY1 here also.

  Following device reset, RECEIVE_DELAY1 must be set to one second, as defined in Section 2.3, ‘Default Settings’ (page 27) of the RP002-1.0.4 LoRaWAN Regional Parameters specification.

  If the end device uses OTAA, the value of RECEIVE_DELAY1 must be updated to the value communicated in the RXDelay field in the Join Accept, as described in section Step 3D: End Device Handles Join Accept of the End Device Activation Book.

  The end device may receive the RXTimingSetupReq MAC command which requests an update to the RECEIVE_DELAY1 value. If the end device accepts this update and responds with an RXTimingSetupAns, it must instead use this Del value as the RECEIVE_DELAY1. Learn how to process the RXTimingSetupReq MAC command in section Receive Window Timing Request (RXTimingSetupReq) of the Receiving Messages Book.

To ensure the response reaches the network server, it is recommended to transmit the response NbTrans times before the end of maximum allowed delay. Best practice is to broadcast each copy of the response at a random time within the permitted period.

Read more about responding to confirmed downlinks in section 9.3.1, ‘Unicast downlink ping frame format’ (page 55), of the LoRaWAN Link Layer Specification v1.0.4.