Region: retransmission limitations not accounting for MAC reset

[JordanYates]

The LoRaWAN spec for retransmission backoffs (https://lora-alliance.org/wp-content/uploads/2020/11/lorawan1.0.3.pdf, Section 7) provides the following backoff table:

Together with this note:

Combined, it can be implied that the reset mentioned in the first box is a MAC layer reset (rejoin), not a hard power reset (which is already covered by power-up). The current backoff algorithm is however only considering the total time since boot in the algorithm, not the time since the synchronization event.

LoRaMac-node/src/mac/region/RegionCommon.c

Lines 146 to 160 in f9bb6f9

	if( joined == false )
	{
	if( elapsedTimeSinceStartup.Seconds < BACKOFF_DUTY_CYCLE_1_HOUR_IN_S )
	{
	observation = BACKOFF_DUTY_CYCLE_1_HOUR_IN_S * 1000;
	}
	else if( elapsedTimeSinceStartup.Seconds < BACKOFF_DUTY_CYCLE_10_HOURS_IN_S )
	{
	observation = ( BACKOFF_DUTY_CYCLE_10_HOURS_IN_S * 1000 );
	}
	else
	{
	observation = ( BACKOFF_DUTY_CYCLE_24_HOURS_IN_S * 1000 );
	}
	}

The limits as they currently exist are too restrictive for devices that attempt to rejoin after detecting a lost connection, as opposed to simply rebooting.

[mluis1]

The current implementation is done according to the current LoRaWAN specification version 1,0,4/1.1.1.
The power-up and reset events as specified represent a similar event. The reset meaning a MCU reset.

However, I full agree with your observation and actually proposed to the LoRa-Alliance technical committee to change this behavior description for the next LoRaWAN specification revision.
This new specification will have a slightly revised behavior description which will be inline with your observations. In addition with the new specification this back off algorithm will be applied not only to JoinReq or ReJoinReq but to other kind of events.

Therefore, once this project gets updated to support the next LoRaWAN specification it will be inline with your expectations.