ADR behavior in device repository

[i3mSuperMan]

Summary

Device manufacturers need to have control of selecting MACSettings while adding a device in the device repository. Refs #263 ...

Why do we need this?

To be able to assign device-specific MAC settings. ...

What is already there? What do you see now?

Option to change a few MAC settings using CLI ...

What is missing? What do you want to see?

Device repository should have MACSettings field with the following options

1. Able to set the value of nbtrans
2. Able to set the data rate range with power index for ADR
3. Able to configure downlinks to a device
4. Able to choose a specific receive window as per the signal strength. For example, when the signal is low (eg; <-120dBm) then the downlinks should be sent only on RX2 window. ...

   Can you do this yourself and submit a Pull Request?

   @johanstokking should be able to include this while setting up the device repository. ...

[johanstokking]

Thanks for reporting, that's definitely useful.

@rvolosatovs can you shed your light on whether these things are actually settings at the moment?

[rvolosatovs]

Able to set the value of nbtrans

Not currently supported, but quite trivial to add

Able to set the data rate range with power index for ADR

Not currently supported, but quite trivial to add

Able to configure downlinks to a device

Please elaborate on what is expected here exactly

Able to choose a specific receive window as per the signal strength. For example, when the signal is low (eg; <-120dBm) then the downlinks should be sent only on RX2 window

Perhaps we could have a class A-specific RX1CutOff, which would represent the minimum uplink signal strength, for which RX1 is attempted. Would that cover your use case @i3mSuperMan ?

[timgestels]

@rvolosatovs I think some information went missing in the process of communication. We are a device maker and from our experience with public LoRaWAN providers we have some requirements regarding the device profile on the network side.

Retransmissions A lot of public LoRaWAN asks the device for retransmissions when a message is sent. This means the device will not send once but two or three times. I'm not sure what the case is with TTN but for us it is important that this setting is off. Otherwise it will have a negative effect on the batterylife.

Adaptive Data Rate Since we are mostly working with moving devices that don't have an accelerometer it is important to be able to choose not to use ADR. Otherwise when a device is in a good networking environment and the ADR turns the tag to a much lower SF. Next time it is moved to a worse environment where it needs e.g. SF12 it will not be received for a certain amount of time until the device resets its SF. In most situations we prefer a fixed SF12 or be able to set a minimium ADR setting.

Technical Network Downlinks In order for the device to know it's still in network we ask for 1 technical downlink every 24 hours otherwise the device will think it's outside the network and try to rejoin another network.

Downlinks on RX2 Since the antenna of the device can never have the same gain as the antenna of the gateway (much smaller) downlinks are received worse than uplinks. To cover up for this the LoRa network allows to send downlinks on RX2 (869,525Mhz) at 27dBm instead of 14dBm which is a huge difference. This setting is only used when uplinks are received at a certain signal strength. When the ESP value for example is lower than 120 dBm (check) then always a downlink should be sent on RX2. If these settings are not good, a % of tags will not be able to join or to stay joined with the network since they have to receive at least one downlink every 24 hours.

[rvolosatovs]

Retransmissions A lot of public LoRaWAN asks the device for retransmissions when a message is sent. This means the device will not send once but two or three times. I'm not sure what the case is with TTN but for us it is important that this setting is off. Otherwise it will have a negative effect on the batterylife.

Adaptive Data Rate Since we are mostly working with moving devices that don't have an accelerometer it is important to be able to choose not to use ADR. Otherwise when a device is in a good networking environment and the ADR turns the tag to a much lower SF. Next time it is moved to a worse environment where it needs e.g. SF12 it will not be received for a certain amount of time until the device resets its SF. In most situations we prefer a fixed SF12 or be able to set a minimium ADR setting.

I think the best option here is to just set mac_settings.use_adr to false. This way Network Server will not try to configure NbTrans of the device and so the the default value (1) will be used and no data rate adaptation will be attempted. Note, that the device preferably should also unset the ADR bit in uplink when moving.

Please see LoRaWAN 1.0.4 specification as well

Technical Network Downlinks In order for the device to know it's still in network we ask for 1 technical downlink every 24 hours otherwise the device will think it's outside the network and try to rejoin another network.

It does sound like something that belongs at the application layer. Are we talking about class A devices here? For class A this behavior can be replicated by either: a. Device sending confirmed uplink b. Setting device status periodicity accordingly, even if no downlink is present, NS will schedule DevStatusReq in RX1/RX2

I don't think this is something that should be implemented at network layer, this is essentially replicating rejoin functionality from 1.1. (I assume you're using 1.0.x LoRaWAN version on your devices here, otherwise you should rely on Rejoin-requests for this purpose, I believe)

Downlinks on RX2 Since the antenna of the device can never have the same gain as the antenna of the gateway (much smaller) downlinks are received worse than uplinks. To cover up for this the LoRa network allows to send downlinks on RX2 (869,525Mhz) at 27dBm instead of 14dBm which is a huge difference. This setting is only used when uplinks are received at a certain signal strength. When the ESP value for example is lower than 120 dBm (check) then always a downlink should be sent on RX2. If these settings are not good, a % of tags will not be able to join or to stay joined with the network since they have to receive at least one downlink every 24 hours.

Please see LoRaWAN 1.0.4 specification:

In case no downlink is received in RX1, the device must open RX2 according to the spec. The only use case for such setting would be minimizing the load on the gateway, but it does not concern the device. Note, that it's up to the device to not open RX1 and only open RX2, for example, but the Network Server will always attempt both RX1 and RX2, if possible and allowed by regional payload size limitations.

[johanstokking]

Note, that it's up to the device to not open RX1 and only open RX2, for example, but the Network Server will always attempt both RX1 and RX2, if possible and allowed by regional payload size limitations.

I think that the request is that for certain devices, NS prefers RX2 over RX1, because of higher probability of arrival.

@timgestels if we're going to support RX2 preference, I'd be inclined to have a minimum data rate in RX2. Sticking to SF12 is going to drain the gateway's duty cycle in 869.525 very soon, even though it's 10%. Can you guys live with SF10 or SF9?

[rvolosatovs]

I think that the request is that for certain devices, NS prefers RX2 over RX1, because of higher probability of arrival.

What does "prefer" mean here? In class A NS will only avoid RX2 if payload it has to send exceeds RX2 payload size limitations, but fits in RX1. We can add a setting to disable this optimization, in which case RX2 will always be performed(along RX1, is possible)

[johanstokking]

What does "prefer" mean here?

Currently, NS/GS consider RX1 first, and if that doesn't work due to duty-cycle or conflict, NS considers RX2 based on size and GS makes again the consideration on duty-cycle and conflict. So RX1 is preferred over RX2 if both are available.

What is meant with "prefer RX2" is to turn that preference around.

[johanstokking]

Blocked by #263