For PC users, automated software updates (where installed programs automatically check for available updates, download and apply them) are simply routine. Many PC-based software programs, especially Web browsers, are performing these automated updates silently and in the background without requiring user intervention. The user typically does need to adjust some settings to accept those silent updates, but with so many different applications being used on a daily basis, it is a relief for many users to have those applications running the latest and greatest version with little to no effort required on their part.

So why is it that as the world becomes more “mobile” by the day, millions and millions of device users still need to plug into a PC to receive updates? It is astounding that as consumers use their mobile devices now more than ever, for a wide variety of uses, that many devices have not yet reached that point – but clearly the need is there as outlined by the following examples:

• Firmware updates are increasingly made available by OEMs and platform providers to deliver new features, improved performance, and new applications, as well as occasional bug fixes to improve feature stability, security etc.

• OEMs increasing include their own apps on the devices (for example, Samsung Galaxy S) as do the network operators. These applications may need to be updated more than once to provision new features or enhance performance. Since these apps are usually stored in the “protected zone” (e.g., /system partition on Android), updating them actually requires a firmware update, independent of the Android release schedule.

• There are a growing number of smartphones such as the Sony Ericsson X8, Samsung Europa and others that target mainstream users. Announcements of soon-to-be-available Android devices priced at less than $100 are a strong indication that the number of less technically savvy users of smartphones will continue to grow. And a number of these less technical users tend to be suspicious and/or at loss when messages pop up asking them whether they want to update their “firmware” as they may be unsure of the consequences or the benefits.

• Even the most advanced users that value the always-connected nature of their mobile devices and rely on them for 24-hour e-mail, messaging, news, etc., may not wish to be disturbed for an update and may feel reluctant to put their devices offline for the time it takes to do a firmware update in the way they are commonly implemented today (for example, via a software update download onto a PC  that requires users to plug the mobile device into the PC to implement the update, which can cause several hours of down time for the device.)

In order to increase user adoption of continuous firmware updating of mobile devices, updates need to happen automatically and in the background, as transparently as possible to the consumer, similar to the way PC software updates happen today. There are many approaches to implementing this, and the best solution will likely be a combination of some of them. Here are some examples of common approaches:

• Pushing the updates to the devices in the background, transparently to the user, until they are ready to be deployed. For the MNO who has the user’s phone number (MSISDN), this can be done via WAP-push (assuming that OMA-DM is used). For device and platform manufacturers who do not have the phone number, the device can periodically check for updates and download one if it is available. (This is already implemented by SEMC and Nokia).

• Minimizing bandwidth charges and network congestion by prioritizing download over Wi-Fi.

• Applying the updates automatically, without asking the user permission – but performing the mandatory device reboot in the “non-active” hours. This will mean adapting the restart time to each user’s individual schedule, so that device downtime will occur at night for the office worker, in the early morning hours for an entertainer, etc. However, this still should not be done without alerting the user first, to account for emergencies, holidays and other changes to the normal schedule.

• Alerting the user that the device will be updated (unconditionally) and allowing selection between “Now” and “Later” – where later is that inactive time slot at night. As a more advanced alternative, it is possible to allow the user a choice of the update schedule between “Now,” “At night (2 a.m. to 4 a.m.),” or setting the time (within 24 hours). This is an approach taken by some Japanese MNOs – however it has its drawbacks since at the scheduled time the device is updated and restarted unconditionally. It would help to minimize the restart time as much as possible.

• Waiting to perform the update until the user restarts the phone – it is bound to happen eventually – and updating the device then. However, this may postpone the update for quite a long time since many users rarely restart their phones unless there is some problem. Once restarted, the phone will be offline for as few as three to as long as 40 or more minutes (e.g., see this VodaphoneHelpCenter video), to accommodate the updating process.

• Updating the software in the background – e.g., taking advantage of paged architectures that use virtual memory and run the device software in RAM, making it possible to update the flash while the device is operational. A restart will still be required, but it would take the same time as a regular restart operation, with minimal overhead (less than a minute) for the update operation.

Most of the elements listed above fall into the “best practices” category and can be implemented as part of the device management application. However, background updating technology (BGU), i.e., updating the device software and firmware while the device is being actively used and is online, is more technically challenging and requires closer attention. Implementing background updating of device firmware requires a profound understanding of mobile device architecture and memory management, as well as tight integration into the device firmware by the OEM. It must be resource-efficient and adaptive to device activity to ensure minimal performance degradation while the updating process is active. It must support updating the firmware image as well as file systems.

Firmware updating still requires a device restart – the one phase of the firmware update process that cannot be completely transparent to the user. Since BGU is the one single element of the automated update solution that can reduce the device downtime during that restart, it should be of interest to everyone who wants to create a user-friendly updating solution for mobile phones. Hopefully, the millions of mobile device users will soon have the choice of the same painless, transparent user experience with updating their phones that the PC users already enjoy.

Ilana Bogomolny is senior product manager at Red Bend Software.