[LoRaWAN] Just for convenience: Add a frmPending field in LoRaWANEvent_t

[VolkerChristian]

Add a frmPending bit from FCtrl as a field in LoRaWANEvent_t.

This bit signals that further downlink frames are pending on the server side.

LoRaWAN class A devices, in case further frames are pending, shall initiate another uplink immediately in order to trigger the downlink of this pending frame on the server side. Using this frmPending bit, the initiation of one or more further uplinks can then easily be formulated as a loop in the user code.

Have a look at this quick and dirty example based on radiolib-persistent starting at line 201 (currently) .

[StevenCellist]

This is literally the second item on my todo list.. thank you!

Although to be clear: it is up to the user to decide what to do with that bit - it is definitely not mandatory to immediately trigger uplinks, merely a recommendation. The wording of this differs between places, but it is not a requirement.

I take it you tested this, given the linked example?

[VolkerChristian]

Lesson learned - thank you! I thought it is mandatory to initiate the downlink in this case.
And yes, I have tested it. As weak evidence I include a log.

Initalise the radio
Recalling LoRaWAN nonces & session
Succesfully restored session - now activating
Aquire data
Sending uplink
Downlink received
[LoRaWAN] Payload:	0x48 0x61 0x6C 0x6C 0x6F -> Hallo
[LoRaWan] Signal:
[LoRaWAN]     RSSI:               -85.00 dBm
[LoRaWAN]     SNR:                8.00 dB
[LoRaWAN] Event information:
[LoRaWAN]     Confirmed:          0
[LoRaWAN]     Confirming:         0
[LoRaWAN]     FrmPending:         1
[LoRaWAN]     Datarate:           5
[LoRaWAN]     Frequency:          867.700 MHz
[LoRaWAN]     Frame count:        1
[LoRaWAN]     Port:               15
[LoRaWAN]     Time-on-air:        119 ms
[LoRaWAN]     Rx window:          1
Sending uplink
Downlink received
[LoRaWAN] Payload:	0x48 0x61 0x6C 0x6C 0x6F -> Hallo
[LoRaWan] Signal:
[LoRaWAN]     RSSI:               -90.00 dBm
[LoRaWAN]     SNR:                10.25 dB
[LoRaWAN] Event information:
[LoRaWAN]     Confirmed:          0
[LoRaWAN]     Confirming:         0
[LoRaWAN]     FrmPending:         0
[LoRaWAN]     Datarate:           5
[LoRaWAN]     Frequency:          867.300 MHz
[LoRaWAN]     Frame count:        2
[LoRaWAN]     Port:               15
[LoRaWAN]     Time-on-air:        47 ms
[LoRaWAN]     Rx window:          1
Sleeping```

[StevenCellist]

Awesome! I wasn't sure yet how I'd easiest test this but looks like you had it figured out. But nobody cares if you wait one minute or one day for the next uplink - while being somewhat good practice to resolve pending stuff, pretty much nothing is affected by waiting a little longer.
The only 'real' usecase I could imagine if e.g. user-configuration couldn't be downlinked due to a pile of MAC commands being prioritized, and as such the device is not aware of a modified configuration potentially including the uplink interval.
I do vaguely remember that Class B does something with this, but that's a far, far away land for now.

Either way, thanks for implementing - merging!

[StevenCellist]

On a small side note: I may actually use this myself for Relay implementation - Relay MAC commands are huge (up to 26 bytes each) and as such a Relay requires multiple downlinks to get configured. Which is why it was high up on the to-do list!

[StevenCellist]

As another remark why you may consider waiting to resolve pending frames is dutycycle limitations. The stack cannot manage this since the only actual way would be to resolve pending frames internally, but then there may be tens of downlinks queued that would result in way too many bytes for the user to process at once. But aggregating over user-controlled uplinks is virtually impossible.

[VolkerChristian]

On a small side note: I may actually use this myself for Relay implementation - Relay MAC commands are huge (up to 26 bytes each) and as such a Relay requires multiple downlinks to get configured. Which is why it was high up on the to-do list!

That pleases me!

Testing was pretty easy. In case the device is joined to TTN (sandbox or not) one can simply use mqtt to push some downlinks into the downlink queue off TTN.

And yes, I am aware of a potential duty cycle problem. That's why it's up to the user to decide to run the loop or not.

At least the widely used mcci-lmic library initiates downlinks immediately. I don't know if this behavior can be disabled in mcci-lmic.

[StevenCellist]

Ah, finally a usecase for the "add to downlink queue"-button on TTN, hadn't thought of that!

It sure is a debatable part of the spec, but if you queue 100 downlinks of 250 bytes each, the stack can't just assume you have 25kB of space available / assigned, so it can only really return you the latest downlink payload which definitely is not the intended behaviour.

[VolkerChristian]

Ah, finally a usecase for the "add to downlink queue"-button on TTN, hadn't thought of that!
😂

I agree and that makes completely sense (mostly). E.g. for mqtt retained qos=0 messages on reconnect only the last retained message is delivered. Retained qos=1 and qos-2 messages behave different.