• State Not Answered
  • Replies 6 replies
  • Subscribers 74 subscribers
  • Views 617 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 346360
Options

Matter OTA Over Thread — Image Transfer Time Optimization Guidance Needed

Kaushik Parsana

Dear Nordic,

We’re working on a Smart Door Lock project built on custom hardware that includes an nRF5340 and several other controllers. For firmware updates, we’ve adopted Nordic’s Matter OTA mechanism, with some customizations. Specifically, we modified the DFU target library and the CBOR-based multi-image bundling process to package all controller firmware — including the nRF5340’s application and network core images — into a single combined Matter OTA binary (size approx. 3.3 MBs).

This unified OTA image is then passed to the Matter OTA provider (using chip-tool or eco-system) for delivery to the OTA requestor — the smart lock device running on our Nordic-based hardware. Using the setup, we’ve successfully transferred the complete Matter OTA image from the OTA provider to the OTA requestor device. All controllers, including the Nordic cores and external controllers, were able to update and switch to the newly transferred image without issues.

We are currently facing an issue with time of Matter OTA firmware update over Thread. Specifically, transferring a 3.3 MB firmware image (approximately 3400 OTA packets, assuming a 1024-byte block size) is taking around 25–30 minutes, which seems excessively long.

Given the capabilities of the Thread protocol, we expected this transfer to complete much faster — especially since, in theory, Thread can handle around 500 KB per minute under normal conditions. We understand that protocol overhead (such as BDX, Secure CoAP, and UDP headers) contributes to some reduction in effective throughput. However, even with that accounted for, the current transfer duration is far from optimal.

Could you guide us on how we can significantly reduce the image transfer time over Matter (using OpenThread)? What strategies or optimizations can be applied to improve both the reliability and speed of the OTA process?

Also, would reducing the poll period (using otLinkGetPollPeriod() / otLinkSetPollPeriod()) help accelerate the image transfer, particularly in sleepy end devices?

Thanks & Regards
Kaushik Parsana

Parents Reply Children
  • 0 in reply to Marte Myrvold

    HI Marte,

    In our project, we have the following default polling configurations:

    • Fast Polling: 200 ms

    • Slow Polling: 1 second

    During Matter OTA, I updated the fast polling interval from 200 ms to 10 ms using the otLinkSetPollPeriod() API. However, this change doesn’t seem to improve the Matter OTA transfer time as expected.

    Could you please guide us on how to switch the Thread device's role or mode before and after the OTA process? You've already shared how to manage this for Wi-Fi, but since we’re using a Matter setup that involves both BLE and OpenThread, I’d appreciate your help with the Thread-specific approach. If you could provide guidance for handling this with OpenThread, I can implement and test it in our scenario.

    Thanks & Regards,
    Kaushik Parsana

  • 0 in reply to Kaushik Parsana

    Hi Kaushik,

    Since changing the interval did not help, you might have to change the role. 

    You can change it by setting the link mode to mRXonWhenIdle like this:

    otInstance *instance = openthread_get_default_instance();
otLinkModeConfig ot_mode = otThreadGetLinkMode(instance);
linkMode.mRxOnWhenIdle = true;
otThreadSetLinkMode=(instance, ot_mode);

    To switch back to SED again, set mRXonWhenIdle = false.

    You can see an example of this in the OpenThread CoAP sample, where you can toggle between MED and SED mode, see https://github.com/nrfconnect/sdk-nrf/blob/v3.0.2/samples/openthread/coap_client/src/coap_client_utils.c#L194-L213.

    You can switch to MED in PrepareDownload() and back to SED in Abort() and Apply(), similar to how we do it for Wi-Fi.

    Do you have any specific requirements regarding OTA and how long it takes? Matter OTA is happening in the background, so it should not impact the user experience, even if it takes a long time.

    Best regards,
    Marte

  • 0 in reply to Marte Myrvold

    Hi Marte,

    I wanted to share that switching the device role during the Matter OTA process has worked well on my end. It has significantly reduced the image transfer time—from the earlier 25–30 minutes down to just 12–14 minutes.

    I understand that this change could have an impact on battery life. However, could you please let me know if there are any other potential consequences of switching to this mode temporarily during the OTA process? Your insights on this will really help us make an informed decision about adopting this approach.

    Thanks & Regards,
    Kaushik Parsana

  • 0 in reply to Kaushik Parsana

    Hi Kaushik,

    As you mentioned, the main issue is battery life. If DFU is done rarely and the update does not take too long, it should be fine, but if the device is updated frequently and updates take 10-15 minutes, then you might see a significant impact on the device's battery life.

    Best regards,
    Marte

Related
Terms of service