Adaptive Data Rate (ADR)

  • 10 augustus 2016
  • 9 reacties
  • 1316 keer bekeken

Reputatie 2
Badge +1
This post has become obsolete as it was incorporated in the Spreading factor (SF), Time on Air and (Adaptive) Data Rate topic.

To save battery devices should minimize used spreading factor, and therefore time-on-air (ToA). When a LoRa device has ADR enabled, the network measures signal strength and replies to the device what SF to use from now on. LoRa devices can be set ADR ON or OFF. Switching ADR OFF is only advised for continually moving objects.

Apart from battery considerations, added advantage of ADR is the increased network capacity: when a specific spot has many LoRa devices sending at a high SF is fitted with an extra gateway, that gateway can reroute the traffic and drastically decrease ToA of the devices around the gateway.

9 reacties

Reputatie 1
Badge +1
@michieljol, @Rick S., I have a technical question about ADR. In the reply from the network on an uplink message, you find the MAC command LinkADRReq, (MAC command 0x03). This MAC command gives an advice on SF and TX, power, and it also contains a channel mask, defining the channels available for uplink messages.
I notice this channel mask is always 0x00 0x07, or binary 0000000000000111, and this means if I interpret correctly only channels 1, 2 and 3 are available for uplink messages.
However in practise, I think there are 8 channels available for uplink messages, at least my software use all 8 and messages arrive correctly, and in the messages from KPN's backend system this is indicated by the parameter Channel which has values LC1.... LC8.
My question is: why is the channel mask in MAC command 0x03 indicating that only 3 channels are available while in fact there are 8? I would like to design a proper mechanism to use a certain channel or not, but this MAC command does not seem to provide helpful information.
Reputatie 6
Badge +6
Hi @rharte,

Thank you for your question!
I reached out to Michiel Jol and i found out that we have a new productmanager for LoRa.
I sent an e-mail with your question to our new productmanager and i'm trying to get an answer to your question today. I've tried to answer the question myself, but this is a bit too technical for me 🙈
Reputatie 6
Badge +6
Hi @rharte,

I received a response from one of the technical specialists and I received the following answer:

'Once the device has answered all NewChannelReq messages, the network will also turn on those new channels in the channel mask.'

Does this information answer your question?
Reputatie 1
Badge +1
@Rick S., Ok it is some logic explanation, but still the mechanism seems a bit cumbersome. I see for instance when I turn a device on, after sending the first uplink message, the channel mask communicated is 0x0007 meaning ch1, ch2 and ch3 are available, while in this same downlink reply the device receives two NewChannelReq messages for ch3 and ch4.
So a NewChannelReq for ch3 which is already included in the channel mask? A NewChannelReq for ch4 I understand but then what about ch5..... ch8?
I think a lot of airtime goes wasted this way on handshake on these parameters, while they are the same for every channel anyway, and all 8 frequencies can be known upfront to all devices, right?
Reputatie 1
Badge
I notice this channel mask is always 0x00 0x07.
BTW, what is the value of the Redundancy field?

the device receives two NewChannelReq messages for ch3 and ch4.

Do you mean that ChIndex field values are 3 and 4? If so, these 're settings for ch4 and ch5. Actually, it shall be impossible to change ch3 settings with NewChannelReq command.
Reputatie 1
Badge

I think a lot of airtime goes wasted this way on handshake on these parameters, while they are the same for every channel anyway, and all 8 frequencies can be known upfront to all devices, right?


This seems to be an example of The Art of Capacity Planning :-)


However in practise, I think there are 8 channels available for uplink messages, at least my software use all 8 and messages arrive correctly, and in the messages from KPN's backend system this is indicated by the parameter Channel which has values LC1.... LC8.

You're bragging that your device doesn't follow the specs, aren't you? 🙂
Reputatie 1
Badge +1

You're bragging that your device doesn't follow the specs, aren't you? :-)


😂 Well actually if you read the spirit of my post, I am trying hard to comply to the spec, but in the grey area of network behaviour where the LoraWan specification does not provide, I find it sometimes hard to follow the logic.
Luckily, KPN answers quickly and thoroughly on my detailed technical questions, so I gladly stand corrected when that means I receive another piece of the puzzle 😉
Reputatie 6
Badge +6
Hi @rharte,

Thank you for your patience!
It took a little while, but I received extra information from the specialists again.
I hope this gives some more logic and clarity about the use of the different channels.

The answer:

The first LinkADRReq message is not for setting the channel mask, but for setting the data rate. The channel mask in this message still assumes the device knows only the first three channels and can therefore not enable the others. When a new channel is send to the device with the NewChannelReq mac-command, the device can immediately use this channel according to the LoRaWAN specifications. At the end, when all other channels are communicated to the device, the channel mask will enable all channels except channel 6, which we disable due to interferences.

This is all the case with ABP devices. According to the LoRaWAN specs, the network cannot assume the device knows all channels. Therefor the device communicates all channels 4-8 through the NewChannelReq messages, which indeed takes some time. That is why OTAA is the preferred method of joining the network. When using OTAA, all channel, adr and rx info is put in the JoinAccept message, such that the device knows all the network settings from the first downlink message.
Reputatie 1
Badge +1
Excellent @Rick S.! 👍🏼 Thank you very much!

Reageer