Yesterday our account manager spoke with one of my collegues and told him that we should be ready for ADR3 come january 2019. I cannot recall ever receiving any anouncement mentioning this and Google is not helpful as well, so a few questions:
- what is ADR 3?
- I see a few new Connectivity plans in the devicemanager, what are these for? What are the costs?
- do existing RN2483 devices support ADR 3 (e.g. 1.0.3 and 1.0.4)?
- do existing Semtech/STM LoRa stacks support ADR 3?
- If not: will this requirement break communication for non-compliant nodes?
Related to these questions I was searching for the KPN Technical Service Description (TSD) as mentioned on the kpniot.mendixcloud.com portal. But I cannot find this document. How can I receive a copy? (and fix the mendixcloud portal please!)
I also contacted the servicedesk about my kpniot.medixcloud account configuration.
Thanks for the quick and comprehensive response.
ADR v3 is the abbreviation of Adaptive Data Rate version 3 and is the replacement of the older version 2. It’s not a specific LoRa Alliance feature, but an update in our network that changes the way our algorithm for data rate adjustment works. In the previous data rate adaption algorithm, the network would adjust the data rate, based on just antenna diversity settings (how many gateways are receiving the message), in the new situation the data rate adjustment will be based more heavily on Packet Error Rate (PER).
With an antenna diversity of 4 (aka ‘optimize the device so that an uplink is always received by 4 gateways), the network would adjust the spreading factor of the device for example directly from 8 to 10 if there was only 1 gateway reached for a number of messages.
In the new algorithm, more heavily based on Packet Error Rate (PER), the network adjusts not only the data rate, but also the NbTrans (Number of Transmissions) of a device. Additionally it will consider the required antenna diversity, which is very important in the Geolocation feature. Following our previous example, the network would check first if setting NbTrans=2 (send the same message twice, over different channels) has the desired effect of reaching the required 4 gateways with at least one of the messages. If it does, it will also verify if it does so over a prolonged period of time, so that it can confirm it will for example not exceed the PER of 10%. If not, it might raise the NbTrans 1 step further or increase the Spreading Factor to 9 and retry this whole step. This new algorithm is more complex and requires a device to handle the NbTrans command and will eventually result in a device that uses less airtime than before, since sending one message on SF10 is more energy consuming than sending two on SF8. Also a lot of our future developments will make use of some mechanics that work in the background of this new release.
Regarding your other questions:
You're welcome. Good luck with the tests, if anything is unclear during your testing phase, don't hesitate to contact us.