FOTA over BLE : Smart devices always up-to-date

In our previous post about FOTA best practice we described why FOTA is one of the key features in providing new functionalities and fixing the possible issues found in the product life. However, not all smart devices may be continuously connected to the cloud due to limited access or security restriction at home or companies’ locations. Based on the already proven best practices, Concept Reply has provided a new approach to allow firmware update using one of the most common interfaces in smart devices: Bluetooth low energy (BLE).

FOTA Protocol over BLE

BLE is a connectivity interface most established in the IOT industry due to its key features like low power consumption and wide Bluetooth availability in smartphones and other personal devices.

The BLE payload size restriction is 512 bytes, maximum per attribute PDU, which sounds like a challenge when considering a transfer of megabytes of the firmware payload.

To handle this limitation, Concept Reply developed a special protocol that fragments the firmware package in meaningful parts and transfers them to the device over BLE interface with transfer status verification on the mobile side. Another feature offered by the protocol is the possibility to perform FOTA off-line by downloading the new Firmware to mobile SD Card and transferring it to the device or fetching the Firmware from a Web server in chunks and transferring them over BLE without storing the whole package in Smartphone’s non-volatile memory.

This approach allows the end user to be able to safely update its non-connected device on their own, like laundry units, coffee machines or even industrial IoT equipment in premises with data restriction, or technical/maintenance support responsible for solving issues on customer sites.

Integrity check on both sides

Due to fragmentation of new firmware size, the protocol developed by us includes integrity checks for verifying whether the checksum matches with mobile and smart devices after firmware transmission.

Firmware size, checksum, software version and other important characteristics of new packages are shared in the beginning of transmission using the JSON manifest files.

In case of invalid software version, incorrect firmware size or wrong checksum, the device under update rejects new packages providing feedback to mobile applications.

In case of invalid software version, incorrect firmware size or wrong checksum, the device under update can reject the new firmware, providing feedback to the mobile application.

In order to show how robust this architecture is, Concept Reply has executed tests using the most probable fail scenario like loss of packet, invalid order and wrong firmware integrity.