search

TheThingsIndustries / lorawan-stack-docs

Documentation for The Things Stack
Apache License 2.0
32 stars 65 forks source link

Document confirmed uplinks behaviour in The Things Stack #1126

Closed ymgupta closed 9 months ago

ymgupta commented 1 year ago

Summary

The Things Stack users are confused with the confirmed uplinks behaviour in The Things Stack. It should be very helpful for TTS users to have documentation on confirmed uplink behaviour similar to the confirmed downlink behaviour documentation in TTS.

Why do we need this ?

To clarify users on the confirmed and unconfirmed uplinks behaviour in TTS.

What is already there? What do you see now?

...

What is missing? What do you want to see?

Documentation on confirmed and unconfirmed uplinks behavior in TTS.

How do you propose to document this?

...

Can you do this yourself and submit a Pull Request?

No, @nejraselimovic

nejraselimovic commented 11 months ago

@adriansmares is there any place you can refer me to to where I can learn about how this works?

adriansmares commented 11 months ago

Hi @nejraselimovic,

I don't think that the flow is explicitly written down anywhere, even in the LoRaWAN specification. The flow for confirmed uplinks is as follows:

  1. The end device sends an uplink which is confirmed. This is a distinct frame type (confirmed uplink).
  2. If the Network Server receives the uplink: 2.1. The Network Server generates a downlink with the ACK flag set in the frame header. This downlink is a class A downlink - acknowledgements never come via class B or C. 2.2. If the end device actually receives the downlink, there is nothing more to do. 2.3. If the end device did not receive the downlink: Devices with a version lower than LoRaWAN 1.0.4 may retry this uplink multiple times, without any upper bound on the number of retries. Devices with versions greater or equal 1.0.4 will retry this uplink at most NbTrans times. The important part here is that the same frame counter will be used - the application will see this uplink at most once, but the Network Server may see it multiple times if the downlink did not reach the end device.
  3. If the Network Server does not receive the uplink, the end device basically is in the same state as 2.3, and will retry.

Points which confuse users:

  1. Since the Network Server is forced to generate a downlink in order to acknowledge the uplink, they will see a downlink after every confirmed uplink. There is no way around this.
  2. Since in virtually every LoRaWAN deployment the gateways are an order of magnitude less than the actual end devices, if too many devices send confirmed uplinks very often, they may consume the duty cycle of the gateway due to the required acknowledgements. This in turn may cause them to try to transmit the same uplink again, which won't be acknowledged and so forth - using confirmed uplinks for large fleets of devices is not recommended.
  3. The Network Server cannot force the end device to stop using confirmed uplinks. There is no MAC command that says 'stop using confirmed uplink messages'. However, some end devices have application layer commands which allow confirmed messages to be disabled.

You can look at an end device which sends confirmed uplinks contiguously here.