Queuing unconfirmed messages

#1

Hello all together,

is it possibile to queue unconfirmed LoRa messages? As far as I understand, the CubeCell is able to retry a few times and lowers the datarate:

/*!

  • Number of trials to transmit the frame, if the LoRaMAC layer did not
  • receive an acknowledgment. The MAC performs a datarate adaptation,
  • according to the LoRaWAN Specification V1.0.2, chapter 18.4, according
  • to the following table:
  • Transmission nb | Data Rate
  • ----------------|-----------
  • 1 (first) | DR
  • 2 | DR
  • 3 | max(DR-1,0)
  • 4 | max(DR-1,0)
  • 5 | max(DR-2,0)
  • 6 | max(DR-2,0)
  • 7 | max(DR-3,0)
  • 8 | max(DR-3,0)
  • Note, that if NbTrials is set to 1 or 2, the MAC will not decrease
  • the datarate, in case the LoRaMAC layer did not receive an acknowledgment
    */

But is it possible to realize a buffer such that unconfirmed messages are queued even after four trials and are being sent whenever there is a confirmation? So whenever the LoRa device is able to send a confirmed message, all queued messages are sent at once.

Best regards,
Stephan

#2

I don’t understand why the unconfirmed message is still queued?

#3

Hello,
for the application it is crucial that the sensor measurements are not lost. However, if the sensor loses connection to the gateway or TTN, the sensor readings will be forcibly lost. The idea is that if the message is not acknowledged, the message is queued until the next message is successfully sent. So if the sensor has a connection to the TTN, the entire queue is sent at once (including timestamp).

Best,
-S

Translated with www.DeepL.com/Translator (free version)

#4

You can implement this function yourself at the application layer.