Firmware Over-the-Air (FOTA) in Narrowband IoT (Part 2/2 - in Practice)

Because, in the Internet of Things “IoT”, the possibility of a subsequent software update of IoT devices is mandatory to provide. For example, to fix bugs afterwards, to roll out new functionalities and last but not least for cybersecurity reasons.

What should be considered with FOTA?

FOTA has many variants. In the simplest case, exactly one file with a new firmware version is played on exactly one device. In practice, however, FOTA often involves an individual and comprehensive range of requirements. Generally it is a matter of equipping entire fleets of devices with the latest version of the software.

Sometimes, however, only defined parts of the fleet are to be equipped with new firmware. This is relevant, among other things, if different device hardware is used in the field and the firmware is then only to be rolled out for a specific device type.

Sometimes you also want to provide special firmware versions with particularly many or particularly few functions to certain customers or customer groups. Or it is a matter of closing newly identified security gaps in certain hardware/firmware combinations by means of an over-the-air update.

In some cases, it is necessary to check which version of the firmware is on the device, because new firmware can only be rolled out on defined, already installed software versions. In case the firmware of the device does not have a suitable version, but if, intermediate updates have to be executed, so that the condition for a successful installation of the latest firmware is then fulfilled. Last but not least, what is challenging is that NB-IoT devices are often deployed in a low-power manner. If the devices are in NB-IoT energy saving modes such as PSM or eDRX, these devices are not accessible at all times. In these modes, the devices are “sleeping” and therefore cannot be accessed by the grid. For such cases it must be monitored when the devices wake up, because only then there are corresponding time windows in which the devices can also be addressed.

How is the new version started?

Once the file has been successfully transferred, the new firmware is installed immediately. For this purpose, the newly downloaded firmware is written to a separate designated partition on the device. The original firmware version remains untouched. After the reboot, the device recognizes that there is a new firmware and tries to boot from the corresponding partition. If this succeeds, then the device uses the new firmware and the old firmware can be deleted or overwritten. If the reboot with the new firmware fails (signature check failed, defective image…), the bootloader automatically boots again from the previous firmware version. **This prevents a device from becoming unusable in the field due to FOTA problems.

What does fleet or device management do?

With fleet or device management, device status and versioning can be managed. This can ensure that the right devices are supplied with the right software at the right time. As mentioned above, an appropriate device management (in the backend) must determine the need for firmware updates for the defined devices. After that, there is a need to monitor their status in terms of accessibility, start the FOTA process and register successful completion.

The versioning and fleet management requirements described above are usually addressed via **specialized FOTA systems such as Eclipse Hawkbit in conjunction with network-side FOTA process support (e.g. via LwM2M).

Which application-specific requirements are relevant for firmware over-the-air?

Furthermore, in practice there are additional requirements that depend on the area of application. Common requirements from the automotive/e-bike sector, for example, are that updates can be transmitted at will, but must only be installed when the devices are not in operation. On the one hand, this must be functionally ensured, since the devices boot with the existing firmware until the new firmware is completely installed. On the other hand, appropriate signaling to the user must also be ensured.

Here it is common to display a running firmware update process either on the device (diode), screen or in an app. After that, the execution of the update is triggered by the user.

How does grandcentrix support FOTA for NB-IoT?

grandcentrix offers a connectivity service „NB-IoT+“ integrated into the Vodafone network. With the Platform-as-a-Service (PaaS) “Cellular Hub”, this supports not only SIM card management, protocol conversion of NB-IoT user data to MQTT, but also the FOTA process in particular.

Due to the very different requirements, only the central functions of the software update are supported here in a focused manner. With the current feature set, it is possible to assign a firmware file to a Cellular Hub device identified by its mobile number (“UCCID”) and trigger a download. This update process is currently applied manually to individual devices via a customer service process. In this process, the firmware version provided is transferred to the device without further testing.

The FOTA process is triggered via the Cellular Hub Management Console (hubctl). grandcentrix employees with appropriate permissions (customer service, CIOT team, integration engineers working on a customer project) are able to initiate a FOTA process. For this purpose, there is documentation on how to perform the FOTA process.

Alternatively, the transfer process can also be initiated by the customer’s backend. The customer’s backend then selects which file should be transferred to which device at which time for the FOTA process. This is necessary to support more complex FOTA processes. For example, when devices are not online at all times or when working with different hardware and software versions in the field.

What are the planned enhancements for NB-IoT FOTA from grandcentrix ?

File management

It is intended to set up a dedicated file management for different files. This feature will mainly allow to handle different firmware files and allow the customer backend to take complete control of the FOTA process via API.

Machine-to-Machine API

File management is to be made available to external (web) services via an open API. This will allow customer projects to integrate FOTA functionality into their customer solution. With the API it will also be possible to script the FOTA process, e.g. to perform a stage rollout or to update a whole fleet of devices at once.

Fleet Management Perspective

Due to the different requirements, fleet management will also perspectively be in the customer’s scope. For this, the CoAP URL of the firmware file provided by the file management will be forwarded to the relevant devices and the handling of the LwM2M firmware update status will be done by themselves. To make this successful, the relevant infrastructure and transmission processes are provided. Furthermore, documented examples of FOTA processes are provided by grandcentrix’s Cellular IoT team.