- Newest
- Most votes
- Most comments
The delay you are experiencing when sending an unconfirmed downlink to a Class C LoRaWAN device is expected and normal behavior. It is related to how Class C devices operate in the LoRaWAN specification.
Class C devices are almost always in receive mode, except when transmitting an uplink message. This allows them to receive downlink messages from the network server almost immediately after the uplink transmission. However, to ensure proper operation and avoid interference, the LoRaWAN specification introduces a delay before the network server can send the downlink message.
This delay, typically around 8 seconds, is known as the CLASS_C_RESP_TIMEOUT and is defined in the LoRaWAN 1.0.4 specification (Section 2.3) ‘Default Settings’ (page 28). The purpose of this delay is to allow the end-device to switch from transmit mode to receive mode and be ready to receive the downlink message.
The behavior you observed, where the device seems to work in Class A mode during the 8-second delay, is also expected. During this delay, the device is still in Class C mode but has not yet entered the receive window for the downlink message. If an uplink message is sent during this time, it will be treated as a Class A transmission, and any downlink message will be sent immediately after the uplink, as you observed.
Regarding reducing this delay, there is no standard way to do so within the LoRaWAN specification. The
8-seconddelay is a fixed value defined in the specification to ensure compatibility and correct operation between different LoRaWAN devices and networks.
Key Source:
Relevant content
- asked 3 years ago
AWS OFFICIALUpdated 3 years ago- AWS OFFICIALUpdated a year ago
- AWS OFFICIALUpdated 10 months ago
Thanks for the answer, but I still have a question about CLASS_C_RESP_TIMEOUT. In the LoRaWAN 1.0.4 specification the CLASS_C_RESP_TIMEOUT is mentioned in regard to responding to a confirmed downlink instead of sending an unconfirmed downlink. Another thing is that since I asked the question, when I tested it again without changing anything, the unconfirmed downlinks where sent only 1.5 seconds after being queued instead of the 8 seconds it normally takes. I don't know why it was faster, but it seems to be possible.