Class C Downlink Retries

ChirpStack Network Server
1

Hi again
I need clarification on whether Chirpstack will try and retransmit a confirmed Class C downlink if no ack received from node. My testing determines that is does not attempt any retries.

I see my confirmed downlink message in the device queue and i also see my initial downlink frame in the Chirpstack Lorawan Frames panel in the web browser.

No subsequent downlink messages are sent and the downlink message is deleted from the queue after the expiry of the Class-C downlink retries time set in the device profile.

In an 2017 message on the forum Brocaar mentioned maybe implement a retries parameter on the downlink MQTT/restAPI message but it doesn’t appear as an option as far as i can see from the API definition.

Is it up to the application to implement retry functionality - if so what is the purpose of keeping the item on the queue?

Thanks for any clarity around this.

regards

2

No, ChirpStack Network Server does not perform any re transmissions, that is up to the final application. The downlink will be hold in the queue until it has been ACKed or the Class C timeout has occurred (see Device Profile). The reason for this is that it provides context when an ACK has been received + the frame can be marked as pending, so that the NS can wait before scheduling the next queue items.

3

hey, i am facing off the same issue!!

I cannot understand why the Network Server not try to resend downlink? and what interface can notify me the downlink is recieved or not?

4

Hi
I ended up adding a lot of code to my application. Basically I check TXACK msgs received via MQTT. I use Nodered as application platform.

5

hi
Can you explain me more:

  1. Where the TXACK you told come frome? From the nodes? In my gateway, i don’t see any uplink from node in Semtech packetforwarder?
  2. If NetworkServer don’t retry to send downlink, so how Lorawan implement adapted datarate in downlink?
    Thanks!