6 - Class C: Continuously Listening for Downlinks
End devices in Class C mode listen for downlinks except when they are broadcasting Class A uplinks, or the Class A receive windows are open.
Class C mode is enabled by identifying the end device as a Class C capable device when you register it on the network server. The network server will then immediately send any downlinks it receives over a single gateway.
Processing Class C Downlinks
Class C downlinks use the same format and can be interpreted in the same way as Class A downlinks, with the following exception:
-
Class C downlinks may not contain MAC commands. A downlink containing MAC commands must be ignored.
If the Class C downlink was multicast, in addition to the above exception, the following apply:
-
The end device must 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.
-
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.
Read the Processing the Downlink Packet of the Receiving Messages Book to learn how to interpret Class A, B, and C downlinks.
Responding to Confirmed Class 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 CLASS_C_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 following algorithm, defined in Section 15, ‘Continuously Listening End-Device (Class C)’ (page 75) of the LoRaWAN Link Layer Specification v1.0.4:
CLASS_C_RESP_TIMEOUT * NbTrans + RECEIVE_DELAY2 * (NbTrans-1)
The variables referenced in this algorithm are:
-
Class C response timeout (CLASS_C_RESP_TIMEOUT)
Defined as 8 seconds.
-
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 uplinks in section 9.3.1, ‘Unicast downlink ping frame format’ (page 55), of the LoRaWAN Link Layer Specification v1.0.4.