Discussion on Rejoin Implementation and Potential Improvements

[novsteph]

Hello everynone,

We are working with ESP32 using FreeRTOS and have ported the LoRaMAC-Node v4.7.0 stack. We are using LoRaWAN 1.0.4.

I would like to discuss our implementation of the rejoin process and see if it could cause issues or if there are ways to improve it. Specifically, should we use LoRaMacDeInitialization or LoRaMacReset for handling rejoin scenarios?

Our Implementation
We have a FreeRTOS task that starts as when the device boots:

static void LoRaWANProcess(void){
    LmHandlerProcess();

    if (isUplinkProcessInhibited == false)
    {
        if(LORAWAN_IsDeviceJoined() == true)
        {
            UplinkProcess();
        }
        // Device not joined to the network and no join procedure is pending
        else if(joinProcedureState != JPS_PENDING)
        {
            // Stop uplink transmission timer and try to launch join request
            StopTransmitUplinkTimer();
            JoinProcess();
        }
    }

    xTaskNotifyWait(0, ULONG_MAX, &ulNotifiedValue, loRaWANProcessNotifyTimeout);
}

Every 30 device restarts, we force a new join procedure to ensure that the device remains properly connected to the network.

To achieve this, we use the following logic, making sure that the device considers itself disconnected from the network even after a reboot (in case it did not receive a JoinAccept before shutting down) so it will try to reconnect to the network until it succeed :

void LORAWAN_ForceJoinRequest(void)
{
    ESP_LOGI(LogTitle, "LORAWAN_ForceJoinRequest");
    MibRequestConfirm_t mibReq;
    mibReq.Type = MIB_NETWORK_ACTIVATION;
    mibReq.Param.NetworkActivation = ACTIVATION_TYPE_NONE;

    LoRaMacMibSetRequestConfirm(&mibReq);

    // Ensure network information is saved in flash if not in LoRaWAN mode.
    // Otherwise, the main task process will handle it.
    if(LORAH_OperatingMode() != INVM_OM_LORAWAN)
    {
        LmHandlerProcess();
    }

    // Stop any pending join or rejoin timers to prevent unwanted behavior.
    StopJoinDelayTimer();
    StopRejoinProcedureTimer();

    joinProcedureState = JPS_OFF;
    xTaskNotifyGive(xLoRaTaskHandle);
}

Additionally, we have a mechanism that resends a Join request every hour (+/- 20%) if the device has not received a Join Accept.

Issue
With this implementation, some devices enter a Join loop, repeatedly sending Join Requests every hour even though Join Accept messages are received from the Network Server (NS) as if the device didn't received the JoinAccept answer. This results in JoinLoop alerts on our NS.

Questions

• Do you see any issues with our approach?
• Is there any interest to use LoRaMacDeInitialization or LoRaMacReset in our case?
• Do you have any recommendations to improve the process and avoid unnecessary join loops?

I can provide more informations for better understanding.

Thank you