The Business of Integrated Mobile Device Management

Understanding
Firmware Over The Air -
FOTA
Introduction

Mobile phones are becoming increasingly complex, as new applications are

being added to support new and innovative operator services. For example, in
2004, there were approximately 50 applications shipping on the average consum-
er phone. As of 2006, that number had increased to almost 70. This increase,
combined with the need to improve time to market has led to a variety of difficult
decisions for OEMs. Do they increase resources to improve time to market, or
do they minimize innovation to relieve the impact on resources and increased
stability?

The industry response is Firmware Over-The-Air (FOTA). FOTA has been widely
adopted as the most cost-effective solution for delivering software updates to
mobile devices already deployed in the market. By 2008, approximately 45%
of mobile phones will be enabled with FOTA. Carriers and OEMs have already
seen decreased warranty costs and enhanced customer satisfaction with FOTA
enabled handsets.

The market presents an almost bewildering variety of options. In order to make

the best possible business decisions, an understanding of FOTA is increasingly
useful for those in the mobile industry, whether employed at an OEM or at an op-
erator. This paper will cover four basic themes which will help the reader achieve
a basic understanding of FOTA and the impact of this technology. These themes
are:

• How FOTA works

• How FOTA can reduce costs
• The impact of FOTA on the user experience
• The financial impact of FOTA on OEMs and operators

FOTA vs. FUMO vs. MDM

Within the Open Mobile Alliance Device Management group (OMA-DM),

the standard for firmware updates on the handset is known as the Firm-
ware Update Management Object, or FUMO. This standard is what permits
Firmware Over the Air (FOTA). The current standardized FUMO revision is
1.0. FOTA refers only to firmware updates, yet confusingly some vendors
use FOTA to refer to all MDM-enabled applications such as configuration,
security, and software management. InnoPath traditionally uses MDM to
refer to OMA-DM specified capabilities. Some analysts track OMA-DM en-
abled handsets as FOTA-enabled, but technically the functionality specified
by OMA-DM is a superset of FOTA, and FOTA is just one of the things a full
OMA-DM client is capable of doing.
How Does FOTA work?

The essence of FOTA is the ability to safely and securely update the firmware on
the handset. Due to bandwidth and other restrictions, it is useful to be able to send
just the updated, changed or added code; not the entire firmware package. Con-
sidering that the price for failure is a bricked (broken) phone, FOTA is a bit of a high
wire act, balancing security and efficiency.

A typical FOTA implementation generally consists of three distinct elements. The

first is the DIFF generator. The DIFF Generator is used to find the differences be-
tween two versions of code, (for example, v3 and v4). The DIFF, or Delta, contains
all the information required to change the v3 code to v4, but is usually considerably
smaller than the V4 code would be.

The technology used to generate a DIFF file is the main differentiator that a FOTA
provider has, and is key to evaluating a given vendor’s implementation. The more
efficient the technology, the faster the DIFF can be generated, and the smaller the
DIFF size will be. The smaller a DIFF size is, the less carrier network bandwidth it
will consume. This translates to lower cost of transmission to each mobile device.
The efficiency of the technology can also be seen in the number of blocks an image
requires. More blocks translate to a greater amount of time the mobile device must
take to re-flash the phone. In general, is takes 1.5 seconds to re-flash one block.
This is very important for consumers because the number of blocks dictates how
long the phone will be occupied during the re-flash.

Generating and Deploying a DIFF file to update a handset with FOTA

www.innopath.com
 Simplified workflow of a FOTA Update

Once a DIFF has been created, it is compressed and secured by the package
generator, and then over the air (OTA) via InnoPath’s iMDM Server (or any other
OMA-DM 1.2 compliant server), or via a cable based solution to the firmware
manager on the device. The iMDM server keeps track of successful and unsuc-
cessful downloads, retrying as appropriate. The FOTA client on each device then
verifies proper (uncorrupted) receipt of the delta file via checksums and other
tests, and combines the DIFF with the v3 image to create the new v4 image,
which is placed into non-volatile RAM to be loaded the next time the device is
restarted.

Key features that should always be present in a solution are:

• The ability to suspend and resume an update.

• Package encryption & compression
• 100% fault tolerance & error recovery
• self updating client
• client is flash agnostic
• multi-step DIFF handling

The InnoPath iMDM Client

The InnoPath iMDM Client supports multiple MDM applications, including FOTA.
It is based upon years of operational experience, and operates at multiple layers
within the device. Looking at the client architecture, the Delta Upgrade Agent
(DUA) is located just above the Hardware Abstraction Layer (HAL). This element
of the client consists of both the DUA itself, as well as adaptation layers down
into the hardware, and up into the operating system. The DUA is that part of the
client that is responsible for carrying out actual firmware updates.

Above the operating system is the second part of the iMDM client, the iMDM
Application Platform, responsible for all iMDM applications such as firmware
updates (FUMO), file system updates (DFS), diagnostics (RD), configuration
management (CM), security management (SM), and software management
(SCOMO). These client
applications rely upon
a set of capabilities
provided by the client
platform, including tree
management, the OMA
DL and DM agents,
and file system access.
End-user applications
on the device reside
above the iMDM client.

FOTA takes on a dif-

ferent meaning once
the device shifts from
one that is image-block
based, to one that relies
on a file system where
individual components
such as files and direc-
tories may be changed
at-will. Examples of the
latter include Symbian,
Linux, and some RTOSs
based on POSIX-like
file systems. The client
therefore has the ability
to update operating sys- Simplified iMDM Client Architecture
tem or application files.

The next logical step, where the client controls all aspects of application/software
running on the device and has awareness of the current state of an application, is
the domain of the SCOMO effort within OMA-DM. InnoPath’s solution for lifecy-
cle software management based on SCOMO is described at http://www.innopath.
com/pdf/software_manager.pdf. SCOMO operates in parallel with FOTA, control-
ling the device’s application environment in the same way that FOTA controls the
firmware. Both are under the control of the MDM server platform, and rely on
other capabilities within the MDM environment such as configuration manage-
ment, security, and interfaces to external systems such as policy management,

The Results of a FOTA update in a POSIX-like environment

www.innopath.com
knowledge bases, as well as billing and reporting. And, both are critical, in that FOTA
alone cannot provide lifecycle application management such as installation, activation,
inventory management, dependency management, and access to policy management.

How Will FOTA Save Money?

FOTA is a commercially proven technology with significant market momentum. As stated

earlier, almost 45% of shipping handsets will be FOTA-enabled in 2008. This growth is
driven by key benefits provided by deploying a FOTA solution:

• FOTA eliminates software based device recalls

• FOTA improves time to market for new services
• FOTA reduces customer service and warranty costs

As mobile devices are released into the marketplace at an ever increasing pace and en-
abled with new, more complex features, OEMs must cope with difficult software releases
and inevitable bugs with the software. FOTA provides a clean, efficient mechanism to
address software defects
before or after a handset
has been deployed into the
marketplace, avoiding costly
recalls and improving time to
market. With device recall
costs averaging $40 per
unit, not to mention the cost
to the reputation of the com-
pany producing the handset,
it is paramount that a FOTA
solution have a strong track
record for eliminating this
risk and saving device recall
costs. The best solutions
will have never “bricked”
a handset (rendered a
device inert via a failed Estimated FOTA Savings (blue) and FOTA New
update) and will have Revenue (orange) in a 20m subscriber network
enabled 10s of millions of
device re-flashes per year.

When a consumer has an issue with their mobile device, they will typically call customer
service. With the capabilities of MDM and FOTA, the customer service representative
(CSR) will have the ability to diagnose the problem and send over available updates to
the device. This avoids warranty actions like bringing in a device to solve a problem that
can be addressed through a device re-flash.

How Will FOTA Impact the User Experience?

If a FOTA client has been properly implemented, it should maximize the control given to
the operator while minimizing its impact on the device and the end user. It is important
that the user be given a great deal of control due to both the importance of cell phones
in their daily lives as well as their varied usage patterns. For example, if a user is on the
phone often during the day but not at night, they might prefer to have their cell phone
re-flash in the evening. A teenage daughter, on the other hand, might be enraged by
evening downtime.
Unfortunately, there are few standards which dictate how this is done and the implemen-
tation of FOTA around the user experience is often inconsistent. However, regardless of
how it is implemented, a good client should offer the following features:

• The carrier can schedule updates to minimize user impact

• The carrier can provide notifications that keep the user informed of what is hap-
pening
• The user can opt out of an update
• The update can be deferred for a specified period of time
• When a download is taking place, the user has a progress notification that an
update is being downloaded
• Once the download is completed, the user can defer the reflash and reboot of the
handset
• Once a device has been reflashed, it should reboot and immediately return to a
usable state
• The user receives a confirmation that the update has successfully completed
• If for some reason this has not happened, the server should be notified so action
is taken
• The user has the ability to cancel the download if there is an incoming call or the
need to make an outgoing call

There is also an additional factor which has a substantial impact upon the user - client
performance. Performance impacts the user in two important ways. First, the size of the
DIFF dictates how long it takes for it to be downloaded to the handsets. The smaller the
download, the faster the experience is for the user. For handsets that are voice or data
enabled (often referred to as Class B Devices), the amount of time it takes to download
the DIFF is particularly important because it determines how long the device will be un-
available to the user.

Second is the amount of time it takes for the client to take the image and write the new
code to the device memory. In general, it should take approximately 1.5 seconds for a
client to write one block to memory. As an example, a 30k, 5 block DIFF is being down-
loaded to the device on a network that supports downloads at 30k per second. The client
is therefore occupied for approximately 8.5 seconds (1 second for the 30k download and
7.5 seconds to write the 5 blocks at 1.5 seconds each) in addition to the time it takes to
simply reboot the phone.

Controlling the costs of FOTA

The costs associated with providing FOTA can dramatically impact both operators and
OEMs if they are not managed properly. Selecting the right FOTA vendor can provide a
mechanism for keeping those costs contained while protecting the investment in the solu-
tion. Costs for OEMs are influenced by the following factors:

• Licensing costs
• Porting effort
• Available ports
• Porting support
• Reflash time

For the OEM, controlling the impact to the handset bill of materials (BOM) is paramount to
the business model. Managing software impact to the BOM enables the OEM to control
their margins as well as keep the device at or below a specific price point. In general,
client software costs are passed on from the OEM to the operator. As a result, minimiz-

www.innopath.com
ing the upfront costs associated with the software is in the best interests of all parties. To
address this issue, it is important to find a vendor that supports activation based pricing.
Activation based pricing assures that no party is charged for the client until it is activated
and used by the carrier. Because FOTA is event driven, meaning its use has to be initi-
ated by the carrier through an MDM server, its use is tracked and can easily be accounted
for. This enables a use or activation based model.

The second impact on OEM costs is the porting effort required to integrate the client onto
the handset. This not only impacts the BOM but also the time to market for the device.
Finding a vendor capable of minimizing the porting effort for the OEM can have a dra-
matic impact on both of these issues. To address this issue, a vendor should provide a
stable API set, numerous device ports to the OEM’s software platform and direct porting
support. The client API set represents the integration point between the client and the
device software. By providing a stable API, the FOTA provider is guaranteeing that once
ported, the client can be reused on other devices based on the same platform, assuming
of course, that the client architecture is relatively stable and unchanging. A well executed
API essentially protects the OEMs porting effort and investment in FOTA technology.

The third impact on OEM costs is the availability of ports. Similar to the porting effort re-
quired to ingrate the client onto the handset, platform ports provide the same protection to
an OEM. OEMs develop their handset on a variety of software platforms; REX, Nucleus,
Symbian, Linux and Windows Mobile to name a few. By providing a port to these plat-
forms, the FOTA vendor is enabling the OEM to avoid the costly exercise of porting the
software themselves. Because most software platforms provide a mechanism for stan-
dardizing the release of software on a device, porting to them enables design re-use – the
ability to utilize the same port over and over again.

The fourth impact on OEM costs pertains to the level of support provided during the
porting process. The release of consumer electronics such as a mobile phone is a time
driven event. The features and the technology are provided to a market window that is
expected to last for a certain period of time. The longer a porting effort takes, the greater
the threat on the market window for the device. A FOTA technology provider should be
judged on the amount of support they are capable of providing for the porting effort. If the
OEMs operations are global, the FOTA vendor’s deployment teams should be global. If
the OEM is shipping on a particular network that includes the FOTA vendor’s servers, the
FOTA vendor should provide interoperability testing to assure that the client will work ef-
fectively in this operator specific environment.

In addition, selecting a FOTA vendor

should also be made on the basis of
how the upfront costs of the port are
distributed. The vast majority of an
OEM’s costs in integrating a new tech-
nology onto a handset are associated
with the first port. This is the period with
the greatest learning curve and uncer-
tainty. Picking the right FOTA vendor
can mitigate these costs, particularly
when a port for the OEM’s platform
already exists.

The final point of impact on OEM costs

stems from the performance of the cli-
Factors figuring in the cost of FOTA
ent. One of the most significant factors
for judging client performance is how fast a client can re-flash the device. During this
operation, the device is temporarily unavailable to the user. By choosing a FOTA vendor
whose technology minimizes the time it takes to download a DIFF and re-flash the device,
the OEM is helping to eliminate the perception that the phone does not meet expecta-
tions. Faster FOTA operations tend to lead to improved customer satisfaction.

For the operator, the principal cost for FOTA is centered around the amount of bandwidth
on a network that is consumed sending the DIFF to the device. A smaller DIFF size trans-
lates to less network bandwidth. It is important to understand that DIFF size is an ampli-
fied cost. When a DIFF is sent out to a group of mobile devices the numbers can range
from a single device to millions of devices. Thus, even a relatively modest DIFF can end
up consuming considerable bandwidth.

An experienced FOTA provider will address this issue using a variety of technologies
ranging from the richness of their DIFF generation tool to compression and roaming sup-
port. Compression is particularly important because the savings can be from 50-75%.
Likewise, roaming support can substantially impact the costs of operating a FOTA ser-
vice. Roaming support assures that the client will not accept a DIFF while roaming. This
is important because when a user is roaming off network, the costs of receiving data are
substantially higher than on network. This problem is particularly significant in geographic
markets like Europe where a user can move across several networks over a short dis-
tance. By providing roaming support, the carrier is assured that they are delivering the
DIFF under the most advantageous circumstances.

Summary

As handsets become more and more complex and feature laden, the ability to remotely
service and manage these devices becomes increasingly critical. With decreased costs
for both OEMs and network operators, over the air firmware updates (FOTA) as well as
more comprehensive mobile device management capabilities become more of a question
of “when and how” and less of a question of “if”.

With potentially millions of subscribers and billions of dollars in the balance, it is critical
for both the network operator and the device maker to understand both the technology
and the business logic behind FOTA in order to be able to make informed decisions best
suited for their business environment.

InnoPath, drawing on years of MDM client and server experience, offers the most com-
plete and technically advanced FOTA solution. Combined with the company’s innova-
tive go-to-market programs, both OEMs and operators minimize their FOTA deployment
expenses. The net effects are decreased operating expenses for the operator and
increased customer satisfaction and brand loyalty.

IPA - The InnoPath Advantage

InnoPath’s unique go-to-market program, The InnoPath Advantage, includes a

number of features which should reduce barriers to entry for both OEMs and
network operators. Some of these features include:
• Zero-cost basic client
• Activation-based pricing of all client applications
• Free client porting to new operating systems
• Open functional and IOT testing
Learn more about The InnoPath Advantage on our website:
http://www.innopath.com/ipa

www.innopath.com
About Innopath

InnoPath Software, the leader in Integrated Mobile Device Management (iMDM) solutions, enables wireless
carriers and mobile device manufacturers to transparently deliver and support current and future revenue pro-
ducing services.

InnoPath was the first company to commercially deploy firmware over-the-air mobile device management, and
its standards-based iMDM Solutions Suite uniquely permits carriers to combine configuration, diagnostics, se-
curity, and application management for lifecycle delivery of services into a single integrated workflow.

Hundreds of millions of active subscribers are experiencing the value of InnoPath patented solutions through
leading carriers including Cingular, KDDI, Sprint, and Softbank Mobile, and device manufacturers that include
Kyocera, LG, NEC, Panasonic, Pantech & Curitel, Samsung, Sanyo, Sharp, Sony Ericsson, and Toshiba.

Headquartered in Sunnyvale, California, InnoPath is privately held with offices in China, Japan, Korea, and
Germany.

Locations
Corporate North American Sales China Japan Korea
Headquarters 12600 Deerfield Parkway, 1106, Tower W3, Sanbancho KS Bldg, 2F, 2 6F Urban Light Bldg.
Innopath Software Suite 100 Oriental Plaza, Ban-chi, 3 Ban-cho, 249-4 Nonhyun-Dong
400 E. Caribbean Dr. Alpharetta, GA No.1 East Chang An Chiyoda-ku, Seoul 135-832, Korea
Sunnyvale, CA 30004-6108 USA Avenue, Beijing, Tokyo, Japan 102-0075
94089-1105 USA China 100738

tel: +1 408.962.9200 tel: +1 678.566.3560 tel: +86 10 8518 1058 tel: +81 3 5210 2050 tel: +82 2 514 0437
fax: +1 408.962.9299 fax: +1 678.566.3612 fax: +86 10 8518 1055 fax: +81 3 5210 2052 fax: +82 2 514 0427

www.innopath.com