FOTA update over CoAP in lossy network

[Nicholas Braaten]

Hi, we are using the nrf_cloud_fota_poll library with CoAP to interface the nRF Cloud for FOTA updates for nrf9160.

In lossy mobile network with bad reception, the FOTA download may have a tendency to fail often, making it hard to do a FOTA job. This makes us need to manually restart FOTA-jobs.

I'm working on making the FOTA download more tolerant for lossy network

This documentation page https://docs.nordicsemi.com/bundle/ncs-3.1.1/page/nrf/libraries/networking/nrf_cloud_coap.html describes some configs that can be tweaked. I also found a couple others that I wanted to tweak. I have now:

CONFIG_NRF_CLOUD_COAP_MAX_RETRIES=50

CONFIG_COAP_INIT_ACK_TIMEOUT_MS=15000

CONFIG_COAP_MAX_RETRANSMIT=15

CONFIG_FOTA_SOCKET_RETRIES=20

What values would you recommend, or is there any values that may be "too high"? Could I for example have retries of 1000 to make it tolerant in lossy network?

The page also describe this config that can be tweaked: CONFIG_COAP_MAX_RETRANSMIT. However, I cannot see it do any change, and looking in the source code in the library, it seems not have any effect.

There is also an issue that when download fails, I can restart the FOTA job in the cloud. The nrf9160 will then continue where it left, i.e. if it failed at 20%, it will continue on 20%. But if I instead of restarting the same job, start a new FOTA job with an other firmare, the nrf9160 will still continue on 20%. The downloaded firmware is then not valid, and I must once again restart that new job. Is this the intentional behaviour?

[Nicholas Braaten]

The thing is that CONFIG_COAP_MAX_RETRANSMIT only affects the polling from nRF Cloud, but not the downloader. So the max_retransmission for the downloader is always equal to 4. It would be nice if the retransmission and packet size for the downloader could be set from a kconfig.