FTD Build Switch Requirements (OT 1.1 20201808)

[HamishBanham]

I am running an NRF52840 FTD with tight flash requirements, however, it is unclear what switches are required to operate a device safely.

I have used the Nordic supplied libraries to limited success, and have compiled the OT lib myself, based on the optimised FTD options provided by Nordic, however, it is unclear what the affect the switches will have on the device in a large network.

Please see my current build switches:
BORDER_AGENT=0 BORDER_ROUTER=0 COAP=1 COMMISSIONER=0 DISABLE_BUILTIN_MBEDTLS=1 DNS_CLIENT=0 DIAGNOSTIC=0 EXTERNAL_HEAP=1 JOINER=1 LINK_RAW=1 MAC_FILTER=1 MTD_NETDIAG=1 SERVICE=1 UDP_FORWARD=1 ECDSA=1 SNTP_CLIENT=1 COAPS=1 DHCP6_SERVER=1 DHCP6_CLIENT=1 DISABLE_EXECUTABLE=1 DISABLE_TRANSPORTS=1

Ultimately I would like to minimise build size, but still allow for the device to become a REED. Please let me know if there are suggestions to achieve this.

[jwhui]

You can disable nearly all of the listed features. Thread Commissioning is mandatory, so JOINER should be enabled.

[HamishBanham]

Do you have any logic to handle the case where the Joiner starts to communicate with the Commissioner but does not complete? In this case, you should probably restart Joiner role or restart the device itself. There is no need to perform a factory reset in this case.

How would someone approach this?
Our current process is to check the joiner state (ie, idle), wait for some period of time (usually 5-45 seconds) and check if we don't have a role and are not commissioned. If these conditions are met, the joiner is polled again.

For example:

    if ((xThisTick - last_joiner_tick) > joiner_scan_tick_time) {

        otDeviceRole    device_role   = otThreadGetDeviceRole(thread_ot_instance_get());
        otJoinerState   joiner_state  = otJoinerGetState(thread_ot_instance_get());
        bool            commissioned  = otDatasetIsCommissioned(thread_ot_instance_get());

        if (joiner_state == OT_JOINER_STATE_IDLE && device_role == OT_DEVICE_ROLE_DISABLED && !commissioned && ot_ble_shared_state.joiner_credential) {

            error = otJoinerStart(thread_ot_instance_get(), ot_shared_state.joiner_credential, ..., joiner_callback, NULL);
            ASSERT(error == OT_ERROR_NONE);
        }

        last_joiner_tick        = xThisTick;
        joiner_scan_tick_time   = nrf_bsp_generate_joiner_scan_time();
    }

[jwhui]

One thing you could try is actually restarting the device after some amount of time. The Joiner does leave some state untouched after it returns to the idle state. For example, the PAN ID remains set, which will constrain the scan operation when the Joiner is started again.

[HamishBanham]

In that case wouldn't it be better to set the state of the PAN ID to an known bad/reset state rather than resetting? Resetting the device can cause undesired side affects in my use case.

[jwhui]

You could try setting the PANID back to 0xffff, which indicates the invalid PAN ID. There may be other issues when I'm not aware of at this time. If resetting the device is not an option for you, we'll have to work through what issues remain.

[HamishBanham]

Just to update on this issue. I have not fully fixed our joiner issue, but I am confident that the issue lies with the commissioning agent; now I am unsure if the issue lies within our application code or within thread itself. More investigation on my side is required.

For more context, the network I am working on has two dense meshes, with some bridging nodes sitting in between (for a total of 46 nodes, I intend to add another 20ish soon). I have been reading a few posts to improve network coherence, (#6860, #4508, #5121), and I would like to report some feedback. Tested on NRF52840 devices running the full openthread stack, connected to an underlying device talking over a custom IPC.

• Commissioner creates huge network traffic (primarily MLE & TLS), and joining nodes should be minimized if possible
• OPENTHREAD_CONFIG_TMF_ADDRESS_CACHE_ENTRIES needs to be large to reduce the number of cache misses
  • 256 is used within the test network
• OPENTHREAD_CONFIG_MAC_DEFAULT_MAX_FRAME_RETRIES_DIRECT of 15 reduces the number of lost frames
• kFailedRouterTransmissions = 6 & kMinDowngradeNeighbors = 4 improved network coherence
• Changing kAdvertiseIntervalMin & kAdvertiseIntervalMax to lower values increased network traffic and reduced stability of the mesh

The biggest change to the system was ensuring that the openthread tasklets were actioned as soon as possible. Delaying even by 1ms caused 802.15.4 frames to be missed, and we saw 802.15.4 ACK sequence numbers not lining up with their expected data frames. For our FreeRTOS based stack we achieved this by yielding our task as often as possible, and looping until all tasklets are processed within a 2ms timeslice. It's interesting to note, that this 2ms timeslice does unpredictably timeout every now and then.

    uint32_t process_start_tick = xTaskGetTickCount();
    
    // Iterate until complete or timeout
    do {
        otTaskletsProcess(thread_ot_instance_get());
        otSysProcessDrivers(thread_ot_instance_get());

        task_timeout = (xTaskGetTickCount() - process_start_tick >= 2);
    } while (otTaskletsArePending(thread_ot_instance_get()) && !task_timeout);