It has been said that mobile is recapitulating the development of the desktop PC. We are seeing the same blossoming of hardware, the same evolution of software, and the same growth in overall user experience and capabilities. Of course with greater complexity comes the mathematical likelihood of a greater number of bugs and vulnerabilities.
Microsoft, to their credit, has done good work on the desktop with the automated delivery of patches and updates over the network via Windows Update. We have come a long way from the early horrors of things like Windows NT 4.0 Service Pack 2, in terms of delivering needed updates in a seamless, timely manner that supports security and functionality while providing a painless user experience.
Similar things are happening in the mobile space. Mobile devices are growing in sophistication and complexity. System images, which were once a few hundred kb, are now 100mb or more. The sheer complexity and sophistication of these devices, combined with the extreme competitive pressures to quickly ship devices and the compressed test and QA schedules that go with those pressures, result in devices shipping with bugs.
In the past, with simpler devices, there were fewer high-priority bugs; typically the phone either worked or it did not. This was fortunate because the solution to firmware bugs was to carry the device to a brick and mortar store and have someone in the back room manually flash the device. This was not only expensive, but it was also inconvenient for the subscriber. Just like updating the firmware on many other devices, an interruption of power or cable connectivity would likely brick the device, rendering it unusable and necessitating repair or replacement. Similarly, some handset vendors enabled side loading, where a consumer-owned PC would download an update package and then flash the device. While this avoided a trip to the brick and mortar, it did require the user to have a PC and still presented risk in the event that power was lost or the update was otherwise interrupted.
An advancement that circumvents the risk of updates, while also addressing the risk of not updating devices with usability, functionality, or security issues, is Firmware Over The Air (FOTA). FOTA, first deployed on the advanced feature phones of Japan nearly a decade ago, enables the network operator or device manufacturer to push updates over the air. While it would be possible with the right hardware and enough bandwidth to push entire system images, it is more common to take a more efficient approach and push a diff file that captures the differences between the old and the new version of the software.
The way this type of update works is the device manufacturer develops a new version of the firmware, V2, to replace the original version, V1. The manufacturer then uses a tool to extract the difference between the two versions to create a diff file. The diff file is used to build a FOTA package, which contains not only the diff file but also versioning information and other metadata. The FOTA package is delivered over the air to the device. The device, which has a FOTA client, is contacted via a binary SMS message that causes it to download the FOTA package. In some cases operators will restrict the delivery of these packages to their wireless networks, in other cases they don’t care.
The FOTA client, after downloading the package, boots into a special mode and uses information within the FOTA package to modify the existing system image. After building the new system image the device reboots, this time booting the new image. At this point the phone is patched and/or has new functionality and is ready to go. When properly performed, user data and settings can typically be preserved—but this is not always the case.
To make things more complex, there are differences between how FOTA is executed on smartphones—such as Android devices—and feature phones—such as the Casio G’z One series or the old classic Motorola Razr—mainly due to the fact that feature phones running a real-time operating system (RTOS) have a block-based memory system and not a file-based system. Highly sophisticated compression and block shifting algorithms are employed—due to the need to do things like change where pointers go when blocks of code are moved to different places—making FOTA fairly easy to describe at a high level, but very complex to implement when building a client.
Another advantage FOTA presents is that, in contrast to flashing a device using a PC, the FOTA client will be able to recover from a botched update and revert to the prior system image in the event that something bad happens—such as the user drops the phone and the battery falls out during an update.
Usually FOTA is delivered as a campaign that is orchestrated by the network operator who has dedicated servers in their datacenter for such purposes. Typically the operator will throttle updates, so that the updates are spread geographically and temporally in order to avoid overwhelming the network. They also tend to update a test batch before doing a full run, which can be hundreds of thousands of devices.
A FOTA update is triggered by the FOTA server, which contains a database of all the devices that are within its scope. The FOTA server typically communicates with an short message service (SMS) gateway, or short message service center (SMSC), using short message peer-to-peer (SMPP) (a protocol that allows a remote host to trigger an SMSC to send SMS messages, binary, or text, to one or more handsets). The SMSC then sends a binary SMS to the client device(s), which then “phone home” by contacting the FOTA server. The address and authentication details of the server are preconfigured on the phone in a process known as bootstrapping. This process allows the phone, when pinged via binary SMS, to know which server to contact. As the operator controls the system image on the device as well as the bootstrap configuration, security is not a problem because the phone will never contact anything but the operator-defined, FOTA server.
Usually it is possible to define severity levels within the update, which could impact the ability of the user to defer the update (or not). In some cases the user can opt-out or defer, and in other cases there may be only a limited ability to defer—particularly for issues that can impact the network.
It is important to note, that for the sake of brevity, many complexities have been glossed over. For example, in the case of generic devices, it may be the manufacturer who provides updates. In the case of Android devices, it may be Google, the operator, or the device manufacturer who delivers the updates. The number of different possible variations, when you consider the number of operators, manufacturers, and platform providers, quickly becomes very large.
However, for the user, FOTA provides several advantages that include fixed bugs, patched vulnerabilities, and the possibility of more and better functionality. FOTA delivers these advantages without the requirement of an additional device, such as a laptop or a PC, and eliminates the dangers of a traditional side load flash.
For the network operator and the device manufacturer, FOTA allows for devices that often end up spending many weeks or months on ships and shelves before reaching end users to ship earlier with the knowledge that the devices will ship with bugs but the understanding that once activated the devices can be updated as part of the initial activation workflow. This strategy effectively buys several weeks of additional time for final development and testing, weeks in which a hypercompetitive environment where first-to-market can be the difference between zero and hero are critical. FOTA also gives the ability to provide new functionality or add services after the client has shipped. Additionally, there could be cases where an issue may impact some subscribers, but not merit a full FOTA campaign. In these cases FOTA can be used to reactively patch subscribers who contact customer care, addressing those who are impacted without having to update all users.
Automated patches and updates have resulted in a vastly safer and better experience for hundreds of millions of Windows users all over the world. With the complexity of mobile devices quickly catching up to PCs, the utility of FOTA patches and updates for those devices is increasingly clear. While the specifics in the execution, delivery, and underlying technology may vary across different platforms, operators, and devices, it is the network operators, platform providers, device manufacturers, and end-users that benefit from these updates and in the end that is what matters.