Server ack unconfirmed data up

As far as I know, according to specification my node send to “unconfirmed data up” packet.
The server probably not send ACK(unconfirmed data down) to my node. But I watch my server why my node setup “unconfirmed data up”, the server can send ACK to me?

Have any one can tell me why,very thanks.

That is because your device has ADR active. After some messages devices send a LINKADR to check if server is still there for them.

If you make a join and send some data you will see more Downlinks trying to set the device SpreadFactor and TX Power

I turned off the ADR. But still will “unconfirmed data down”.

I don’t know why. I use the ABP method to access the network.

And I use “confirmed data up” ,but server response me “unconfirmed data down”.

So I think this is probably a bug. Or is there any other opinion? Thanks.

If you send a Confirmed Data Up you receive an ACK (the downlink you see) that is tagged as UnconfirmedDataDown Because your device does not have to confirm the ACK.

If you unfold the Downlink you can check what’s inside the downlink packet

In my case this is a normal send:

ADR on, server lowering DR and TxPower

But I still can’t understand why it is different from the specifications.

As far as I know.


 Node-------------------------------------------Gateway ----------------------------------------------- Server
   |---------(Send unconfirm data up )----------->|-----------(Send unconfirm data up )------------------->|

Server doesn’t send Send “unconfirm data down” to Node.


    Node-------------------------------------------Gateway ----------------------------------------------- Server
      |---------(Send confirm data up )--------------->|-----------(Send confirm data up )------------------>|
      |<---------(ACK confirm data down )--------------|<-----------(ACK confirm data down )-----------------|


This is my downlink packet.

An uplink(confirm data up) corresponds to a downlink(unconfirm data down)

As far as I understand, the issue of uplink acknowledgement and downlink acknowledgement are separate.

if the node sends an “Unconfirmed Data Up” then this would result in nothing coming down from the server.

If the node sends a “Confirmed Data Up” then an acknowledgement is sent back. In your example the Acknowledgement is an “Unconfirmed Data Down”

As a result of this the node does nothing.

Now let’s examine the scenario if the server had sent its acknowledgement as a “Confirmed Data Down” then the node would be required to acknowledge with a further packet in the Up Direction. This would continue until one or other does not require an acknowledgement.

In your example the Node requested an acknowledgement and the server responded. The server did not require its down packet to be acknowledged. If the node does not receive an acknowledgement (uplink or downlink failure) then it will resend. There is no need for the Server’s message to be acknowledged.

That is a DevStatusReq, Server is asking some parameters to device,

You can turn it off here:

In summary, if you send ConfirmedDataUp, you should at least expect an UnconfirmedDataDown with ack true. I say at least because it could carry some mac commands too.
On the other hand, if you send an UnconfirmedDataUp, you should not expect a corresponding downlink to acknowledge it, but there could be a downlink which piggybacks from your uplink to send mac commands.

Beware that in practice this can work out a little bit differently than intended - because it’s entirely possible that the node fails to hear the network’s ACK, even though the network heard the uplink and advanced the uplink frame counter as a result.

A typical node implementation may then try to retransmit the uplink with the same frame counter. Because the network has already seen that frame count, and already acked it, the retransmission will be ignored - the node can re-transmit as many times as it likes and it will never get an ack because as far as the server is concerned, it already did!

So if you’re going to re-transmit on lack of an ACK, it’s probably preferable to send fresh readings with an incremented frame count number, and not merely re-send the same exact packet, or at least, sharply limit the number of resends before incrementing the frame counter.

(A possible alternate behavior would be to make the server willing to re-ack the most recently seen uplink frame, with the same exact downlink count - but that’s probably only worthwhile if you have an application where getting 100% of a perhaps increasingly stale data set through is more important than getting current data through often enough.

@cstratton, thanks for adding in the detail. Appreciate you pointing that out.


@cstratton @iegomez Thanks your answer. I have to re-recognize the Server and Node LoRaWAN specification.

I follow your instruction.

But still had ACK “unconfirm data down” to my node.

And thanks your answer, too.

Well that is a Confirmed Data Up
As they told you a Confirmed is answered with an Unconfirmed Carrying at least the ACK for your node

I am using Arduino + LoRa shield as end node and using LMIC library. And dragino as gateway. I am using single channel ABP for uplink. I am receiving Unconfirmed Data Up. Although i turned off ADR from loraserver.toml script. What else should i do to receive correct payload. The lorawan frames that is being received are

Expand one of the downlink packets and see what’s in it, particularly look at fCtrl and fOpts, and of course see if there’s any application payload

Loraserver will always trigger a downlink chance after uplink, for classA and classC, then it does:

  1. Assume that there is a downlink frame will be sent, set all tx info for it.
  2. If the uplink is confirmed, set this chance as must be sent, and set an ACK flag to the frame.
  3. If device ADRis true, load ADR command to frame and set this chance as must be sent.
  4. If application set report status to the server and it is time to do, load DevStatusReq command to the frame, set this chance as must be sent.
  5. Other mac command like RXParamSetupReq,RXTimingSetupReq,NewChannelReq and etc.
  6. If the device’s queue has an item to downlink, load it to frmpayload and set fPort, then set this chance as must be sent.
  7. Sent it to Lora-gateway-bridge, if there is not any frame must be sent, return nothing to do.

So, you will see a downlink after uplink for the reason above.

With ADR on (turned on in loraserver.toml, and on node with " LMIC_setAdrMode(1);") i’m getting both unconfirmedDataUp, and then unconfirmedDataDown.


With ADR off, im getting only unconfirmedDataUp, with no DataDown respose.

I believe my Gateway, and server is running correctly as I don’t see any warnings or errors. I suspect my problems could be on the node, so I am getting info with the following function:
void showInformation() {
Serial.println(“LMIC parameters”);

Which returns in the serial monitor:
521413: EV_TXCOMPLETE (includes waiting for RX windows)
Rx1 window
LMIC parameters

“netid=0” does’nt look to good.

Not sure what parts of my server + node are misaligned, any guidance would be amazing.

What about this seems problematic to you? It looks like it’s your first post in this thread so unclear what overall issue you are reporting or why you consider this behavior odd?

The downlink you show is the ADR response containing that information in FOpts, it doesn’t have any payload.

Things seem to be working as designed.