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?

frer
질문됨 2달 전140회 조회
1개 답변
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
전문가
답변함 2달 전
  • 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.

로그인하지 않았습니다. 로그인해야 답변을 게시할 수 있습니다.

좋은 답변은 질문에 명확하게 답하고 건설적인 피드백을 제공하며 질문자의 전문적인 성장을 장려합니다.

질문 답변하기에 대한 가이드라인

관련 콘텐츠