search

TheThingsArchive / ttn

The Things Network Stack V2
https://www.thethingsnetwork.org
MIT License
461 stars 279 forks source link

Please put an explanation of "retry" label on the device console #779

Closed HouzuoGuo closed 3 years ago

HouzuoGuo commented 4 years ago

This is a feature request for the console.

What do you want to do?

Understand what the term "retry" means in the

What steps did you take?

Create a simple program that sends short packets to TTN and inspect uplink data packets in the console.

The data packets are regular packets without confirrmation requirement.

What went wrong or what is missing?

The console shows a perculiar term "retry" next to several uplink data packets. The label "retry" is not accompanied by an explanation or prompt, and the terminology of "retry" is not used in LoraWAN libraries such as https://github.com/matthijskooijman/arduino-lmic and https://github.com/mcci-catena/arduino-lmic.

As a courtesy to TTN users please explain what "retry" is on the console along with how it might or might not have an impact on the transmission.

Do you have Screenshots?

image

What kind of OS/Browser/Gateway are you using? Which version? Chrome

jpmeijers commented 4 years ago

Interesting question. It's however not a simple answer. I'm not part of the TTN team, but I will try and explain how I interpret this "retry" message. This is also on the V2 stack, and development focuses on V3 now.

In normal situations a device sends uplink packets, every time incrementing the frame counter. It should therefore never happen that you see more than one packet with the same frame counter. On some older devices if you sent an uplink message, requiring an ack, and you do not receive the ack, the device will retry sending the exact same packet with the same frame counter. This is incorrect and is fixed in the later LoRaWAN standards and libraries.

On the TTN Console a packet is normally only shown if it passes a frame counter check. This is a check that makes sure that packets aren't "replayed". In cases where a device sends the same packet more than once, TTN should only show the first one and discard any future ones. If you disabled frame counter checks, TTN will not discard these "replayed" packets, but list them with the "retry" label.

It can also happen that a packet is received by more than one gateway. TTN will wait 200ms for all gateways to forward the packet, merging all the copies of the same packet together and only show one on the console. If a gateway's internet connection has a high latency, that gateway's copy of the packet might arrive after this 200ms de-duplication window, and the packet will be seen as a "replay". The packet will either be discarded or marked as "retry", depending on if you disabled frame counter checks or not.

HouzuoGuo commented 4 years ago

@jpmeijers thanks :) your thorough explanation is magnitudes more helpful than the rudimentary "retry" label, now I understand that in the screenshot retry simply means that the device is sending packets while reusing frame counter value.