By using AWS re:Post, you agree to the AWS re:Post Terms of Use
AWS re:Postre:Post

AWS LoRaWan Class C Downlink Delay

0

Hello, I'm trying to send an unconfirmed downlink to a 868MHz Class C device. The downlink stays in the downlink queue and is only sent after an 8 second delay. When I try to send a downlink to a Class A device, the downlink is sent after an uplink without any delay. I have also noticed that during the 8 seconds before the downlink message is sent to my Class C device, the AWS LoRaWan device seems to work in Class A, because if my Class C device sends an uplink message during those 8 seconds, the message is sent immediately after the uplink message, just like a Class A device. Is this delay normal? If so, is there any way to reduce this delay? If not, what could be the reason and how can I remove this delay?

Topics
Internet of Things (IoT)
Tags
AWS IoT CoreInternet of Things (IoT)
Language
English
frer
asked a month ago119 views
1 Answer
1

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-second delay is a fixed value defined in the specification to ensure compatibility and correct operation between different LoRaWAN devices and networks.

Key Source:

profile picture
EXPERT
Osvaldo Marte
answered a month ago
  • frer
    25 days 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.

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.

Guidelines for Answering Questions

Relevant content