Can I get the ACK of a confirmed downlink in the HTTP integration?

Hello, everyone!
I use http integgration. I got downlink and uplink messages, the question is how i can get confirmed ask message in my server then I send downlink message with confirmed: true filed. I see confirmed ask in ttn console, but don’t see in my server.
Can anyone help?

The documentation clearly describes:

"confirmed": false, // Is set to true if this message was a confirmed message

However, I’m quite sure that in that case the network server (so: TTN) will send the acknowledgement for a confirmed uplink, without you having to do anything. If your application happens to be sending a downlink too (following the same documentation) then TTN will “piggy-back” on that downlink to send the ACK. But if there’s no such downlink scheduled, then TTN will create a downlink by itself.

That said: note that downlinks are bad for the network capacity and you can send at most 10 downlinks, including confirmed uplinks, per day. Sending some “true filed” for each uplink would be bad practice (even when assuming you’re not actually planning to use text for that).

May be I’m write wrong.
I send downlink with “confirmed”: true to end device, end device send confirmed ask.
Question is can I get that ask in side of my HTTP intergration?
In raw data on my integration I don’t see field “confirmed”, but in console I see confirmed ask packet.

1 Like

LoRaWAN 1.0 states:

When receiving a confirmed data message, the receiver shall respond with a data frame that has the acknowledgment bit (ACK) set.


The following diagram illustrates the basic sequence of a “confirmed” downlink.


The frame exchange is initiated by the end-device transmitting an “unconfirmed” application payload or any other frame on channel A. The network uses the downlink receive window to transmit a “confirmed” data frame towards the end-device on the same channel A. Upon reception of this data frame requiring an acknowledgement, the end-device transmits a frame with the ACK bit set at its own discretion. This frame might also contain piggybacked data or MAC commands as its payload. This ACK uplink is treated like any standard uplink, and as such is transmitted on a random channel that might be different from channel A.

Note: To allow the end-devices to be as simple as possible and have keep as few states as possible it may transmit an explicit (possibly empty) acknowledgement data message immediately after the reception of a data message requiring an acknowledgment. Alternatively the end-device may defer the transmission of an acknowledgement to piggyback it with its next data message.

So, the acknowledgment of a confirmed downlink is just a regular (possibly empty) uplink. I assume that you should receive that uplink through the HTTP integration as well.

It’s not clear to me what exact messages you’re seeing in TTN Console, and what you’re receiving using the HTTP integration for each of those messages.

Hello, again.
In first picture that I see in TTN console.

And in my http server.

But I don’t see ack confirmed message.


What we need is the Ack bit in FCtrl from the frame header (FHDR). I don’t think the TTN network server passes it to the application server. It’s not mentioned in, nor do I see it appear in our logs.
So in my opinion confirmed downlinks make no sense on TTN as acks are ignored.

1 Like

Is there any update on this please?

:thinking: on what exactly ??

Apologies, I was referring to the last post from markruys. Is there a way to get the ACK visible on the application server?

ah ok :sunglasses:

I’ll hope @htdvisser can shed some light on this ACK - HTTP integration question

No. The ACK bit is not sent to applications. The Handler will just keep trying to send the downlink until an ACK is received from the device.


Thanks for the quick reply @htdvisser. It would actually be very useful to have visibility of the ACK on application level. Is there any plan to support this? Any other workaround available?

With our upcoming v3 stack we plan to give a lot more insight into what’s going on inside the stack through an “events” side-channel that developers can use. We also plan to have signaling to the Application about confirmed downlinks being acknowledged (or not).

We do not plan to make such changes to v2.


Hello Hylke, you colleague just informed that v3 is available now. I wondered if we could get the ACK packets in the Application now. I did some tests today and observed the same thing that jset described here.

Hi @junqing, when our V3 stack receives an acknowledgement of a confirmed downlink, that will indeed be forwarded to the application layer.

A post was split to a new topic: Can field airtime be added to HTTP integration?