Unconfirmed data down to Confirmed data

ChirpStack Network Server
1

LoRa_sequence
LoRa_sequence.png1280×1024 225 KB

  1. Issue is for Confirmed UP data, Unconfirmed Down data is sent from LoRa server.
  2. Is there a delay in sending Unconfirmed Down for the Unconfirmed up ?
  3. Should LoRa server respond for Unconfirmed Up sent from LoRa Node?
  4. LoRaWAN 1.0.x packet decoder is used to debug data.
2

It is perfectly valid that a confirmed uplink is acknowledged by an unconfirmed downlink. Note that regardless of the message-type, the frame contains ack: true|false indicating the acknowledgement of the previous (confirmed) frame.

3

We have attached LoRa Decoder image for reference.
For Unconfirmed up

unconfirmed_data_up
unconfirmed_data_up.png1920×1080 622 KB

4

For Confirmed Data Up

confirmed_data_up
confirmed_data_up.png1920×1080 648 KB

5

For Unconfirmed Data down

unconfirmed_data_down
unconfirmed_data_down.png1920×1080 804 KB

6

From the attached images,

For Confirmed data up we see there is false Fctrl.ACK and for Unconfirmed Down, we could see Fctrl.ACK is true

What does this 2 acknowledgement means. Can you please explain.

Is the 2 ack is valid ?

7

This is all valid. I advice you to read the LoRaWAN specification for the meaning of these fields as it contains the most complete documentation of the protocol :slight_smile: https://lora-alliance.org/lorawan-for-developers.

8

We have gone through the document lorawantm_specification_-v1.1.pdf . Its mentioned in Section 4.2.1.2 for Confirmed Data message must be acknowledged by receiver but didn’t mention whether it should be unconfirmed data down or confirmed data down.

Our Customer here is expecting the below,
For Confirmed Data Up Message , Confirmed Data Down message should be come as acknowledge," but you are saying like ACK will be Unconfirmed Data Down.

Does LoRaWAN protocol works like our customers requirement ?

We also would like to know when and what case Confirmed Data Down will be received from receiver ?

9

If you need an ACK for an ACK, then that ACK needs an ACK too and you’ll end up in a loop of confirmed messages with ACKs :wink:

The downlink confirmed message is there for the same reason as the uplink. E.g. when an application wants to send a downlink payload which needs an acknowledgement.

It could be that when a confirmed downlink is scheduled, that it too contains an ACK to acknowledge a confirmed uplink, but please note that the downlink message-type serves a different purpose than the ACK in the downlink payload. In this case the ACK is there to acknowledge the previous uplink (confirmed) and the confirmed downlink is to request the device to send an ACK.

1 Like