Overview
The OTA (Over-The-Air) upgrade system enables IoT devices to remotely receive and install new firmware without manual intervention. For widely distributed and numerous IoT devices (such as smart meters, in-vehicle terminals, and industrial gateways), OTA is the only feasible way to fix vulnerabilities, add features, and optimize performance. The OTA system needs to support full-process capabilities including firmware version management, upgrade task orchestration, staged release, batch push, progress tracking, and rollback on failure. Differential upgrades can transmit only the differences between old and new versions, saving bandwidth, which is particularly important for devices using IoT SIM cards — the data cost directly affects upgrade costs. OTA is widely used in scenarios such as smart homes, connected vehicles, industrial equipment, and smart meters.
OTA and the relation with SimtoLink: Devices connect to the network via IoT SIM cards, and OTA downloads consume data traffic. SimtoLink's IoT SIM cards support data pools, directional data, etc., which can optimize the data costs in OTA scenarios. At the same time, the status of IoT SIM cards (activated, deactivated, overdue) affects device connectivity, so OTA tasks need to consider device online rates and network conditions.
Core Functions
Firmware Management
Version upload, MD5/SHA256 verification, storage (object storage or CDN), distribution URL generation. Supports multiple products, multiple versions, multiple hardware models. Firmware packages can be encrypted and signed to prevent tampering. Full packages and differential packages can coexist.
Upgrade Tasks
Create tasks by device, group, product, or gray percentage. Supports immediate execution, scheduled execution, and conditional triggers (e.g., check when device comes online). Task statuses: pending, in progress, successful, failed, canceled. Supports pausing, retrying, and rolling back tasks.
Differential upgrade
Differential packages generated based on algorithms like BSDiff and HDiff, only transmitting the changed parts. Can save 50%-90% of data traffic, especially important for narrowband scenarios like NB-IoT and 2G. The device side needs to support differential restoration and consider exceptions such as power loss and insufficient storage.
Progress Tracking and Rollback
Devices report download progress, verification results, and installation status. The platform displays task progress and success/failure statistics. In case of failure, it supports automatic rollback to the previous version or manual intervention. It needs to work with the OTA Agent on the device side, supporting breakpoint resume, power-off recovery, and dual-partition switching.
Typical IoT Applications
Smart locks, smart meters, in-vehicle T-Box, industrial gateways, agricultural sensors, etc. The device side needs to implement an OTA Agent: version check, firmware download, verification, installation, reboot, and result reporting. In weak network scenarios, breakpoint resume is required; for embedded devices, storage and power constraints need to be considered.
Conditions to check before a version switch
How the device confirms the version after reboot
Track one upgrade as a transaction. The platform holds the target version and the hardware list it applies to. The agent on the device downloads, verifies, writes, and reboots, then reports the version that is actually running after the reboot. The transaction ends when the new version is running and has finished its self-check. A notice that the download completed, or a device that went offline and came back online, is not enough to record the version as in effect. A dual-partition device waits until the new partition passes boot confirmation before the boot flag leaves the old partition. A single-partition device must still let the bootloader find the previous usable image.
A task selects devices by product, hardware revision, and current version, then decides whether to push immediately, check when the device comes online, or release in percentage batches. The hardware revision should come from the model record in the Device Management System, not from a verbal check against a shipping spreadsheet. If the first batch's observation window shows a failure to boot, an interruption of critical business, or a reported version that does not match the target, later batches should stay in the queue. Record progress as five separate steps: download, verify, write, reboot, and confirm. The step where it stopped decides whether the next attempt resumes or downloads the whole package again.
A delta package depends on an exact baseline
A delta package describes only the byte difference from one baseline version to the target version. Reconstruction is defined only when the device's current version, the image actually in the partition, and the baseline written in the delta header all match. As soon as the field has a board replaced in repair, or an intermediate version flashed by hand, the delta unpacks to the wrong image. The entry condition for a delta task is therefore that the version the device reports can be trusted, and that the platform still keeps the original full package for that version, so a failed delta can be replaced by the full package.
Models with a confused baseline, a very small difference, or a bootloader that cannot yet reconstruct should receive the full package. Both the full package and the delta must have signature and digest checked before writing, and the digest algorithm must match the one used when the task was built. When a download breaks, retransmit only the unfinished pieces. Pieces that already passed verification do not need to be fetched again. If the image is kept in Distributed Storage, the download address should be valid for a limited time, so a long-lived object address is not written into device firmware or logs.
Power loss, flash space, and signature checks
Recording "the file has reached the device" as "the device is already running the new version" is the most common wrong entry in an upgrade log. If power is lost between erase and write, a single-partition device stops in a state that cannot boot, and the bootloader must recognize an incomplete image and stay on the old version. If free flash is smaller than the decompressed image plus runtime logs, the write returns out of space halfway, and retrying the same image only fails again. Before creating a task, record for that model the minimum free space and the lowest battery level at which an upgrade is allowed. Devices that do not meet those figures stay in a waiting-for-conditions queue.
A signing key that does not match, a certificate check that fails because of the device clock, or the same hardware revision with different peripherals can pass the digest while the business is unusable. If a canary list is drawn at random and happens to include every critical node on one production line, the observation window no longer represents the fleet. Split the list by hardware revision, region, and business importance. While the device is in an action that must not be interrupted, the agent should refuse the switch and report the reason. If the version report still sends a cached old string, the platform marks a device that already succeeded as failed and pushes again, which causes repeated reboots. The report must read the version that is actually running after boot.