Does ADR require the use of confirmed uplinks?

TTN Network and Services
1

Hi everyone.
Based on current simple ADR algorithm, do each node have to use confirmed message which requires ACK from server all the time?

However, as you know, downlink traffic is limited.
so, how can a LoRaWAN system deploy this mechanism?

regards.

2

@youngjune0594

ADR is included and implemented in LoRaWAN stack so you just need to take care if you want to use it or not.
you can find more information on ADR here
https://www.thethingsnetwork.org/wiki/LoRaWAN/ADR

1 Like
3

Why do you think that? After each uplink, a node should always listen for a possible response after exactly 1 second (receive window RX1), and if nothing was received: again after 2 seconds (RX2). So I would assume TTN can always send an ADR-related command after each uplink.

(So, also after unconfirmed uplinks, and also if your application has not scheduled any downlink itself. If it did schedule a downlink, then I think that the ADR command can even piggyback on that downlink, but I’d need to read the specifications to be sure.)

4

@arjanvanb I don’t know how TTN does it but in the KPN LoRa network, there are usually several parts piggybacked in one downlink message. For instance if you send a LinkCheckReq in your payload uplink, then you could receive the following MAC commands piggybacked:
0x02 > reply to your LinkCheckReq
0x03 > LinkADRReq, the ADR parameters
0x05 > RXParamSetupReq
0x07 > NewChannelReq
And if there is downstream payload data, it will also be combined in this message.

As a side question: the ADR ‘advice’ from the network should be acknowledged, but I don’t actually know what happens if you don’t (I don’t in any case in my implementations :slight_smile: ). Do you know why this acknowledgement is there, other than just ‘for information’ for the network operator?

5

Enabling ADR in a node does not require the use of confirmed uplinks at user level, the user can continue to use simple unconfirmed uplinks.

At MAC level, every 64+32 uplinks there will be at least one downlink needed for the ADR algorithm. (this downlink can be piggybacked with user downlinks)

The Network Server should send a downlink every 64 uplinks, but can anticipate the downlink to make the algorithm more real time. If the Network Server delays the downlink more than 64+32 uplinks, the ADR algorithm will fail.

And yes, ADR algoritm wastes a lot of downlink / duty-cycle recourses in the gateway. This is a real problem and LoRaWAN 1.1 will fix it allowing the ADR_ACK_DELAY values to be modificable, not fixed to 64+32.

3 Likes
6

In LoRaWAN 1.0, should it generate downlinks even when not asked to do so? It seems TTN is only forcing a downlink when the node is using SF12. In all other cases, it seems that TTN will only piggy-back on existing downlinks (possibly not including bare ACKs for confirmed uplinks), or generate a downlink when the node set ADRACKReq in an uplink. If the node does not set that, no ADR is received.

It seems the TTN implementation adheres to the LoRaWAN 1.0 specifications though that is not quite specific about this:

4.3.1.1 Adaptive data rate control in frame header (ADR, ADRACKReq in FCtrl)

[…]

If an end-device whose data rate is optimized by the network to use a data rate higher than its lowest available data rate, it periodically needs to validate that the network still receives the uplink frames. Each time the uplink frame counter is incremented (for each new uplink, repeated transmissions do not increase the counter), the device increments an ADR_ACK_CNT counter. After ADR_ACK_LIMIT uplinks (ADR_ACK_CNT >= ADR_ACK_LIMIT) without any downlink response, it sets the ADR acknowledgment request bit (ADRACKReq). The network is required to respond with a downlink frame within the next ADR_ACK_DELAY frames, any received downlink frame following an uplink frame resets the ADR_ACK_CNT counter.

…where “it periodically needs to validate that the network still receives the uplink frames” feels like it’s mainly about ensuring the uplinks were received, rather than describing a required part for ADR. But the specifications don’t seem to state that the network server needs to generate any downlinks itself.

7

I have a case of a node sending at SF7 (with ADR enabled) where the nearby gateway sometimes goes down.

Another gateway would be reachable with SF8 or SF9, but the node never notices. An unconfirmed uplink is sent every 15 minutes. I’d like a node to be able to “heal” from gateway downtime within about 3 hours (so every 12 packet).

Three questions:

  1. As far as I understand, the network will send a downlink after 64 packets, right? Will that downlink result in the node increasing the SF?
  2. Can I make that process faster by sending a confirmed uplink every 3h?
  3. From which gateway will the downlink be sent? What if the “failed” gateway is not disconnected, but merely unreachable (e.g. because it was taken inside without reception)? Will the network try to send the downlink via that gateway? When it’s not confirmed, will it try another gateway?

I’m wondering whether I should ditch ADR and implement automatic SF increase by myself using confirmed uplinks (and increasing SF if they’re not confirmed). The problem is that I won’t be able to “legally” use SF11 and SF12 that way, right? Also, going back down will not be possible since the node does not know the RSSI/SNR for its confirmed uplinks, right?

8
  1. If the node transmits at SF7 and the only gateways are reachable at SF8 and up, how do you expect TTN to know the node sent 64 packets? And how should the network know when your node is receiving (1 and 5 seconds after a transmission that has not been received)
  2. At least at that point you will know the data did not reach the network because you don’t get an acknowledgement.
  3. There will not be a downlink if there is no uplink. Only when TTN gets a downlink it will know which gateway(s) are within reach of a node. The back-end will send any downlinks using a gateway that received the uplink.
1 Like
9

Hehe, good point :smile:

Ah, obviously. :man_facepalming:

I think the best would probably be to disable ADR, to add a custom system with regular confirmed uplinks that allows for an auto-increase in SF, and for a way to manually reduce the SF using downlinks.

10

Just make sure you keep the downlinks (includes confirmation packets!) to <= 10 a day as per fair access policy. Don’t go the Lairdtech RS186 route and require a confirmation for each and every uplink please…

11

Why? If ADR is implemented correctly then it’s requesting confirmation for you:

(Where ADR_ACK_LIMIT is 64 in LoRaWAN 1.0, and is configurable in later versions.)

So it seems to me ADR is not configured or implemented correctly?

Don’t forget you’d also need to decrease SF when possible. And unless the device is sending some LinkCheckReq, only the server knows how well the transmissions were received, and hence only the server can determine what SF is best for your device.

12

Of course :slight_smile:

@arjanvanb ah, that’s how it works. unfortunately 64 packets is every 16h since we only send data every 15min… that’s quite a long time.

We’re using the RN2483, so I would expect that ADR should work properly.

13

“Don’t go the Lairdtech RS186 route and require a confirmation for each and every uplink please…”

As discussed on other thread for this I recently met with Laird to discuss options & suggest features and a series of updates are indeed pending…Laird will phase in new features/options capabilities over next few weeks and summer. 1st new release (before end of month?) will make confirmed uplinks optional & remove need for an initial timestamp before sending payloads :slight_smile: (Set up then no longer needs e.g supporting Node-Red instance to hand timestamp). Also looks like they will make a release with Cayenne LPP format an option - I expect in 2nd or 3rd update to follow :smile:

1 Like
14

Unfortunately Cayenne LPP is severely underspecified and will result in different incompatible implementations :confused: Maybe someone should create a better specification of a format like that. (I already thought about starting something…)

But that’s offtopic.

15

Agreed but its a good start - Cayenne seems v popular with TTNers and well understood so me thinks pat on the back to Laird if they do go that way as option. Indeed in recent meet question was asked what other payload/standards might be desired/supported so if folks have a view let me know and I will try to co-ordinate a response/feedback to Laird prod management & eng/firmware teams…:sunglasses:

…off topic as you say…

16

Even worse:

…where for LoRaWAN 1.0 ADR_ACK_DELAY is 32 for EU-868, during which the backend can wait for some other downlink to piggy back its ADR command… So even if you’d somehow decrease the 64 to become much lower, it might still take another 32 uplinks to get the ADR downlink.

But how would a custom implementation in the end-device know when to increase the data rate (decrease the SF)…? Maybe somehow triggering the ADRACKReq yourself while asking for a confirmation at the same time might be your best bet?

17

What I had in mind:

  • Every 3 hours (to stay below 10 msgs/24h), send a confirmed uplink
  • If the confirmation does not arrive, retry 2 times. Then increase the spreading factor and retry until the uplink confirmation arrives.
  • We’re monitoring our nodes. A SF increase would result in a notification. By taking a look at RSSI and SNR (as reported by the receiving gateway) we can manually judge whether the SF can be decreased again.
  • Decreasing the SF could be implemented using a custom downlink command (on the message level, not on MAC level).
18

That could be multiple gateways, but I guess you know.

I edited my earlier answer while you might already have been typing your response, so just to be sure:

I’ve no idea if the RN2483 allows for that though.

19

So far, I haven’t come across an option that would allow me to do things like that…

20

@Jeff-UK, Hi Jeff, how is it going? I’am using MCCI V 3.2.0 , How can I disable confirmed uplinks? I am using a private network that allows only 8 downlinks per day, and the ACk I receive after Uplink interrupts my connection.

thanks