During ADR operation, device lost after datarate == minTxDatarate (v1.0.3)

[lsleungast]

Issue / symptoms

After a long period of no service / no downlink responses, end device becomes unreliable in uplink communication attempts after service re-established.

Root cause analysis

Debugging traces to a point in code where the channel mask is changed from previous network configuration.

LoRaMacAdr.c (v4.4.7)

.
.
  if( datarate == minTxDatarate )
  {
      // We must set adrAckReq to false as soon as we reach the lowest datarate
      adrAckReq = false;
      if( adrNext->UpdateChanMask == true )
      {
          InitDefaultsParams_t params;
          params.Type = INIT_TYPE_ACTIVATE_DEFAULT_CHANNELS;
          RegionInitDefaults( adrNext->Region, &params );
      }
  }
.
.

When datarate reduction reaches minTxDatarate, the channel mask gets reset to default, which activates all channels. As a result the end device subsequently sends uplinks on potentially unavailable channels. This can lead to detrimental behaviour such as the following:
-degraded service
-energy waste / battery impact
-unnecessary Tx/noise

Specification reference

According to specification v1.0.3,

454 The end-device will further lower its data rate step by step every time ADR_ACK_DELAY is
455 reached. The ADRACKReq SHALL not be set if the device uses its lowest available data rate
456 because in that case no action can be taken to improve the link range.

There is no requirement to reset the channel mask, and appears to be exceeding the spec. description.

Further research reveals that according to specification v1.1,

551 provides a longer radio range. The end-device MUST further lower its data rate step by step
552 every time ADR_ACK_DELAY is reached. Once the device has reached the lowest data
553 rate, it MUST re-enable all default uplink frequency channels.
554 The ADRACKReq SHALL not be set if the device uses its default data rate and transmit
555 power because in that case no action can be taken to improve the link range.

This reset of channel mask in v1.0.3 appears to be an artifact of v1.1.

Resolution

Compliance with v1.0.3 can be achieved by removing code resetting the channel mask when minTxDatarate is reached, thereby adhering more strictly to the spec. description.

[mluis1]

The provided implementation is correct and complies with LoRaWAN 1.0.3 specification plus the LoRa-Alliance errata note concerning the ADR – harmonize state transitions

In addition the certification process verifies that the errata implementation is in place.

If you don't mind I move this issue to the Discussions tab.

[harvhundal]

I agree with the OP here. We have encountered this situation in practise, resulting in severely degraded uplink communications (down from virtually 100% successful uplink communications to around only 30% successful after the channel mask is reset to the regional defaults).

In this case, instead of setting the channel mask to the region defaults, I think it would make more sense to put the device in a "Network JOIN" state. In this "Network JOIN" state, the application can implement backoffs in case of no reply from the LNS to conserve battery life. Eventually when LNS communications resume, the node will get the correct channel mask and use the recommended data rate from the LNS. Even if the device is not put into JOIN mode after this issue, it would be still be preferable to at least leave the channel mask as is, instead of changing it to the region defaults.

Setting the channel mask to region defaults in this scenario results in unnecessary uplink message loss once LNS communications are restored, since the device is inadvertently sending on frequencies that the gateways are not listening on.

Whether the LoRaWAN spec is being followed or not is a technicality, however, the implementation is certainly not ideal from a system performance/reliability perspective.