Server ack unconfirmed data up


#1

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.


#2

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


#3

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.


#4

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.


#5

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


#6

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


#7

As far as I know.

unconfirm:

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

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

confirm:

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

I ADR OFF, ACK OFF.

This is my downlink packet.

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


#8

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.


#9

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

You can turn it off here:


#10

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.


#11

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.


#12

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

Tony


#13

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


#14

I follow your instruction.

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

And thanks your answer, too.


#15

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