Does ADR require the use of confirmed uplinks?

TTN Network and Services
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

21

With LMiC, if traffic uplink is confirmed (or better not) is controlled by the final argument to LMIC_setTxData2 (u1_t port, xref2u1_t data, u1_t dlen, u1_t confirmed);

That said, there are many network housekeeping reasons other than confirmed uplink why a network server would generate a dowlink, the thread subject ADR being one of them…

22

hi @cslorabox, I hope you are not tired of me, and can help-me :grin:

I am using the ABP and OTTA example from the MCCI library, in the examples already have this configuration. I also checked before writing the first time, too

LMIC_setTxData2(1, mydata, sizeof(mydata)-1, 0);

I also tried to disable link check validation before and after “case EV_JOINED” , but it did not work

LMIC_setLinkCheckMode(0);

I pointed again to the TTN, to have more access to the logs, every uplink , i get a downlink. You can see the pictures ? Thanks

https://ibb.co/8D2Wzyw // device
https://ibb.co/mhrmn0W // device
https://ibb.co/5hGqTVR // gateway
https://ibb.co/4Z5tYXQ // gateway

Below, a log of downlink on gateway Dragino-LG02

(RXPKT): [up] {“rxpk”:[{“time”:“2020-07-01T21:15:14.855718Z”,“tmst”:3384576861,“chan”:0,“rfch”:1,“freq”:915.200000,“stat”:1,“modu”:“LORA”,“datr”:“SF7BW125”,“codr”:“4/5”,“lsnr”:7.8,“rssi”:-57,“size”:26,“data”:“QFoWASaALQABy6gPr2g90WGCZw+5jXlHBWE=”}]}

(TXPKT): [down] {“txpk”:{“imme”:false,“tmst”:3386576861,“freq”:923.3,“rfch”:0,“powe”:20,“modu”:“LORA”,“datr”:“SF12BW500”,“codr”:“4/5”,“ipol”:true,“size”:22,“ncrc”:true,“data”:“YFoWASaKJgADQAIAcQM1AP8Bihrl3g==”}}
Receive(HEX):405a160126802e00013db6e37aea0c26c2e347887ff16dd767b7

23

For that uplink an online decoder shows it has its ADR bit set.

For the downlink it shows you’re seeing two LinkADRReq MAC commands in FOpts: 0340020071 and 033500FF01. This is unrelated to the topic at hand, but indeed related to ADR: see LMIC Library Always Does Unwanted Downlink.

I’d expect you can disable those LinkADRReq MAC commands by using LMIC_setAdrMode(0).

All said, the Dragino-LG02 is not a compliant LoRaWAN gateway, so you’re into many surprises, and you might even harm other network users in your neighbourhood by connecting that to a LoRaWAN network. You wrote you’re on some private network, maybe they allow/support that. But please don’t use that on TTN, not even for debugging.

1 Like
24

Hi @arjanvanb, thank you very much for the information, i’m researching everything you told me, i will also follow the recommendation on the dragino gateway, it was already off, i put it to work again just to try to get some log, something that in the private network i can’t get