|
Firmware Over-the-Air (FOTA) technology enables device manufacturers and network operators to deliver updated firmware to mobile phones in consumers' hands. Today's mobile devices contain enormous amounts of software, mainly firmware, to support such advanced features as digital cameras, music players and web browsers. There are inevitable issues with such complex software: software defects, missing features and design issues, often created by time-to-market demands in this highly competitive market.
The need to fix device software over-the-air has made FOTA mainstream, adopted by nearly every major manufacturer and operator. By the end of 2008, 50% of all mobile phones will include FOTA, according to U.K.-based analyst firm, ARCchart. Much can be learned from the successful embedding of FOTA in mobile handsets. However, there are software and a few hardware considerations to effectively implement a FOTA solution. This article focuses on the technology behind FOTA updating in order to assist manufacturers and operators in selecting, integrating and using such a technology. This article is based on real-world, accumulated experience in developing and integrating FOTA software on more than 100 mobile devices.
FOTA device architecture
The mobile industry has adopted a common architecture for Mobile Device Management (DM) systems, enabling mobile operators, handset manufacturers and enterprises to have remote management over the handset, its functions and visibility into its workings. A major reason for operators and OEMs to deploy DM systems is to enable Firmware Over-the-Air (FOTA)--the ability to remotely update devices' firmware.
The assumption is that the reader is familiar with the overall architecture and basic components of DM systems, which include a horizontal DM server, its vertical plug-in applications and a DM client. These systems utilize the OMA-DM 1.2 standard developed through the Open Mobile Alliance (OMA). This standard ensures that all mobile devices can communicate with and are interoperable with a DM server used by the service provider.
In contrast, the OMA-DM standards do not include any device-side implementation issues, which are strictly left 'out of scope' of the standards. Therefore, the major complexity of the FOTA update process is often not well understood by those evaluating and integrating FOTA capability into devices.
FOTA-enabled Device Architecture
FOTA implementation on a typical handset includes a standard DM client compliant to the DM protocol, which must include the Firmware Update Management Object (FUMO). FUMO is part of the complete OMA-DM protocol and the actual semantics are expected to be interpreted and carried out by a suitable plug-in added to any provided generic DM client. This plug-in is responsible for applicative details such as user experience of the update process, properly storing the downloaded Update Package, validating the integrity of and authenticating the package, and signaling the Update Agent to execute ('hand-off') the actual update.
It is the Update Agent which performs the actual FOTA update on the handset. Later on, upon termination of the update process by the Update Agent, the FOTA plug-in collects status/result information from that process and lets the DM client report it back to the server according to the DM protocol.
As shown in Figure 1, such architecture requires no API between the DM client including its FOTA plug-in and the Update Agent. The Update Agent must work as a stand-alone boot application to enable total updating of the firmware, and any direct API between DM client/plug-in and the Update Agent is almost impossible and not recommended.
|
