Ack for confirmed downlink - A Class

ChirpStack Application Server
1

[Edited]
If I send a confirmed downlink to the end node, I get Ack message in next turn.

Q1. Is it correct work that the server receives the ack in next turn? I have expected that if the server sends a confirmed downlink I can get Ack immediately, not in next uplink.

Q2. I receive Ack for confirmed downlink with either * acknowledged:false or true.
Is it from the end node or gateway?
I think that the gateway is saying depending on communication between the gateway and end node.
Is it correct?

Please give me advice.

2

If I send a confirmed downlink to the end node, I get Ack message in next turn.

Q1. Is it correct work that the server receives the ack in next turn? I have expected that if the server sends a confirmed downlink I can get Ack immediately, not in next uplink.[/quote]

The only way a node could ACK would be to send an uplink packet. It could be a packet with no application content and just the ACK bit, but it would still be an uplink.

Q2. I receive Ack for confirmed downlink with either * acknowledged:false or true.
Is it from the end node or gateway?
I think that the gateway is saying depending on communication between the gateway and end node.
Is it correct?

The key thing to realize about LoRaWAN gateways is that they really don’t “do anything” - they are just proxies to let the server access the airwaves at one or more geographic locations.

I am not 100% certain but I believe the message you are receiving is effectively from the server trigged upon receipt of the next uplink from the node, and tells you that the previous confirmed downlink was confirmed (if the triggering uplink has the ack bit set) or was not confirmed, if an uplink packet was received that does not have the ack bit set.

I’m not aware of a “timeout” in the LoRaWan spec at which point you’d get a failure-of-confirmation message absent any uplink from the node, though it would be possible for a server or even your application to decide for itself that an unreasonable amount of time had elapsed indicating probable failure.

3

Thanks Chris.
I think that Ack(uplink) tells the previous confirmed downlink was confirmed.
One thing still I’m confused is that the ack has the acknowledged key and sometimes the value is false or true.
I’m not sure what exactly the key/value means.

4

I believe that was covered in the previous message, if still unclear please give a specific example, ie, quote the JSON published over MQTT or show a screen shot or something.

5

This is a point what I’m curious.
See below screenshot.
There are two up&down link communications.

twoCmomm
twoCmomm2000Ă—487 155 KB

Before #1: I added data as confirmed downlink using MQTT
#1: Ther server received a confirmed uplink from a node and the server sent a confirmed downlink including ack for the previous uplink.
This is the payload of the confirmed downlink. I beileve that “ack”: true means the acknowlegement for the previous uplink. Usually the downlink is unconfirmed if I don’t add data in queue like #2 sequence.

{
        "downlinkMetaData": {
            "txInfo": {
                "gatewayId": "00956901000000b8",
                "frequency": 922500000,
                "power": 23,
                "modulation": "LORA",
                "loraModulationInfo": {
                    "bandwidth": 125,
                    "spreadingFactor": 12,
                    "codeRate": "4/5",
                    "polarizationInversion": true
                },
                "board": 0,
                "antenna": 0,
                "timing": "DELAY",
                "delayTimingInfo": {
                    "delay": "1s"
                },
                "context": "XvTb/A=="
            }
        },
        "phyPayload": {
            "mhdr": {
                "mType": "ConfirmedDataDown",
                "major": "LoRaWANR1"
            },
            "macPayload": {
                "fhdr": {
                    "devAddr": "015054d1",
                    "fCtrl": {
                        "adr": true,
                        "adrAckReq": false,
                        "ack": true,
                        "fPending": false,
                        "classB": false
                    },
                    "fCnt": 3,
                    "fOpts": [
                        {
                            "cid": "LinkADRReq",
                            "payload": {
                                "dataRate": 0,
                                "txPower": 5,
                                "chMask": [
                                    true,
                                    true,
                                    true,
                                    true,
                                    true,
                                    true,
                                    true,
                                    true,
                                    false,
                                    false,
                                    false,
                                    false,
                                    false,
                                    false,
                                    false,
                                    false
                                ],
                                "redundancy": {
                                    "chMaskCntl": 0,
                                    "nbRep": 1
                                }
                            }
                        }
                    ]
                },
                "fPort": 10,
                "frmPayload": [
                    {
                        "bytes": "W0Mv8u/YVi+HFj5+"
                    }
                ]
            },
            "mic": "62a6c5e5"
        }
    },

#2: I recieved second confirmed uplink from the node. There are two data types(ack and uplink) on DEVICE DATA log.
I assume the ack in #2 is from frmPayLoad. I’m not sure.
Anyway, my question is what “acknowledged”: false means in the ack data. Sometimes it’s “true”
Does that mean that the server didn’t receive an acknowledgment from the node for the previous confirmed downlink?
For now, I can’t know whether the node received data or not. That’s why I’m having this question to figure out where the problem has.

{
    "type": "ack",
    "payload": {
        "acknowledged": false,
        "applicationID": "1",
        "applicationName": "Test",
        "devEUI": "0095690e00000674",
        "deviceName": "Sensor674",
        "fCnt": 3
    }
},
{
    "type": "uplink",
    "payload": {
        "adr": true,
        "applicationID": "1",
        "applicationName": "Test",
        "data": "AkQAEwgCDwYUAQAAACMmAAAAIyYAAAAjJgAAAAAAAAAAAAAIOXcD",
        "devEUI": "0095690e00000674",
        "deviceName": "Sensor674",
        "fCnt": 3,
        "fPort": 10,
        "txInfo": {
            "dr": 0,
            "frequency": 922100000
        }
    }
}
6

It looks to me like this is generated when you have sent confirmed downlink traffic, and then the server receives another uplink from the node. If that uplink has the ack bit set indicating that the node has received a confirmed downlink, then acknowledged would be true, otherwise it would be false indicating that the node has sent new uplink traffic that does not acknowledge having received a confirmed downlink.

7

False means that the server is telling that no ack from the node. Right?

8

Approximately. The actual situation was explained in the previous post

1 Like