Advertisement
Articles
Advertisement

Addressing the Challenges in the Design of High-Performance FOTA Diff Engines

Fri, 01/30/2009 - 9:05am
Firmware over-the-air (FOTA) technology makes it possible to detect bugs, defects and design flaws after the handset lands in the subscribers' hands.
By Jinsheng Gu, InnoPath Software


click to enlarge

Simplified FOTA Architecture.
Firmware over-the-air, abbreviated as FOTA, is the technology to enable wireless device manufacturers and network operators to remotely update the mobile device software, mainly firmware, already deployed in the market. At the center stage of FOTA is the diff engine, which intelligently computes, arranges the order of, encodes and compresses the differences between two given versions of mobile phone software, i.e., the existing version running on the device and the new version. The limited wireless network bandwidth, the lack of resources on the mobile device, and zero-tolerance of failures are challenges that any commercial diff engine developer has to face. This article briefly addresses the design of high performance FOTA diff engines to conquer these challenges.

Firmware over-the-air (FOTA) technology makes it possible to detect bugs, defects and design flaws after the handset lands in the subscribers' hands.
Mobile telephones have recently undergone a transition from relatively simple voice-based cellular phones to more advanced communication, entertainment, computing devices with sophisticated software and applications such as rich messaging, GPS, camera, TV and web browsing. This transition requires complex software that operates the mobile devices, which inevitably introduces quality and reliability problems to wireless device manufacturers and operators. Due to competition for time-to-market, mobile devices may be shipped with undetected bugs, defects, and even design flaws. It is now common practice that these mobile handsets can be fixed in the user's hands by FOTA technology, instead of expensive and inconvenient mobile device recalls. In addition, FOTA can deliver new features and services to customers. Since FOTA can reduce warranty cost, decrease time-to-market, enhance customer satisfaction and brand loyalty, as of now, almost every major device manufacturer and network operator has deployed FOTA technology. In this document, for simplicity, package means FOTA update package, which is used to update the existing software image on the mobile device.

The architecture of FOTA consists of a package producer, a package distributor and a package consumer, as depicted in Figure 1.

Considering the package is theoretically independent of whatever protocol or media is employed by distributor during delivery, the primary components of FOTA are a package producer and a package consumer.
The Foundation for the FOTA solution - the Diff Engine
The performance of the FOTA solution is essentially determined by the underlying technology for producing and consuming the diff package, which consists of the diff engine and the update engine. Considering the update engine on the phone just executes the commands encoded in the package, the performance of the diff engine fundamentally dictates the overall success of the FOTA solution.
Design of a High Performance Diff Engine
The mobile network environment has the following characteristics:

1. Limited network bandwidth. A larger package downloaded in the mobile network to millions of handsets will take a longer time to complete, which is a heavier load on the network and incurs more cost to the operator. Bandwidth limitation requires small diff packages.

2. Lack of resources on mobile phones. This also dictates smaller packages since device manufacturers have to allocate dedicated storage for saving the package upfront, which increases the cost of the bill of materials. This resource limitation implies non-symmetry between the diff engine and the update engine. The package producer is usually running on a PC or a workstation in a device manufacturer's facility. As of now, technically it can be assumed that enough resources are available to generate any packages, although care has to be taken when software images exceed 500MB. However, the diff engine has to consider where the package will be applied by the corresponding update engine. Handsets lack persistent storage (e.g., read-only-memory ROM) to keep the intermediate data, random access memory to be used as temporary working buffer is a precious commodity, and they usually have a much slower CPU.

3. Zero-tolerance of failure. This not only requires that after the update, the software image on the handset must be 100% bit-by-bit equal to the new version, but also requires that it must recover from any failure due to interruption so that the handset is not in a useless (bricked) state. And it also requires rollback to original running version in the event of issues with the new software release.
Design Challenges
Image Sizes
Due to more functions, applications and services added to the mobile device, the embedded software image size may now exceed 500MB. Traditional data compression approaches such as gzip and bzip2 won't suffice. Even if the compression ratio is 50%, it is not practical to download a compressed image greater than 10MB across the bandwidth-limited network and save it to the handsets. From a package size point of view, the diff engine has to follow more sophisticated approaches outlined below:

1. Delta-compression methodology: The running version on the mobile device is used as a reference to create the new version by employing a sequence of COPY/ADD commands in the package. In this way, the update package will be greatly reduced, and not proportional to the image size.

2. Content-aware technology: The diff engine must take advantage of the domain knowledge of the software image, including:

a. Most handsets are running on ARM processors. Software images contain changes not only introduced by logical source code level changes (a.k.a. primary change) but also added by the compiler/linker in the software build process due to address shift/referencing (a.k.a. secondary changes). The diff engine should encode the secondary changes in an extremely compact way to facilitate the update engine restoring it quickly in cascade manner.

b. Due to the material cost of flash, some software images contain compressed content, such as the Symbian ROFS image or CRAMFS image. Since the nonlinear effect of compression could destroy the patterns in the content, directly applying delta-compression onto compressed images ends up no gain in many cases. Of course, the diff engine should decompress the content first and then apply the delta-compression algorithms. In addition, it has to handle the compressed portion which crosses the hardware device block boundary. Otherwise, failure recovery can not be supported.

3. Don't put swapped content in the package, but back it up before updating the handset. Some content in the software image may swap from one version to another. The diff engine should have capability to instruct the update engine when and how to backup swapped content if required.

Handset Resources
Limited resources on handsets require that not only more CPU-boundary tasks should be performed on the diff engine if possible, but also that the diff engine should intelligently calculate, based on the input on target device resource configuration, that the update can go through with available resources on the handset. The so-called in-place update plays a central role in FOTA. In-place update is the ability to update the firmware in place of the existing running version with limited memory. This is because most mobile devices don't have spare flash memory for reconstructing the new version side-by-side with the existing running version. From this device resource limitation point of view, the diff engine should be designed in the following ways:

1. The diff engine computes and directs the update engine on when and how to recycle/reuse the available resource so that the package is consumed on-demand.

2. The diff engine should arrange the update instructions in appropriate order. In reality, the image has to be updated portion-by-portion. Which portion should be updated first, and which should be next? If the sequence is not handled properly, read-after-write conflict occurs. Read-after-write conflict means the old content in a specific location is intended to be read in order to reconstruct new content in another location, but it has been overwritten with new content already. Even during the update of one portion, it is necessary to consider update direction, especially if the portion occupies more than one device block of memory. The diff engine must resolve this conflict without increasing the package size or impact the update reliability and efficiency. It should analyze the dependency and compute the update sequence to arrange the content in the package so that the content of any portion on the flash is consumed first before overwritten. In a word, it is crucial to have the following information in the package:

a. Inter-portion dependency: The update sequence of all the to-be-updated portions.

b. Intra-portion dependency: The update direction of each to-be-updated portion.

c. Order the portions in a device block next to each other to minimize number of flash device block access (read/erase/write, especially write).

d. When and how to backup some content for swapped data.

Failsafe Operation
The policy of zero-tolerance of failure mandates that the diff engine includes:

1. Technology for pre-update validation to authenticating a new firmware version before the update commences. The diff engine must calculate and encode the information for the update engine to verify everything related to the update process in advance.

2. Technology to pre-calculate critical information and put it into package in order to support failure recovery and rollback. During the update process, there is the possibility that an interruption, such as power loss, could occur, which not only corrupts the written flash device block but also leaves the mobile device in useless state. In the event of interruption, the update engine can consume the critical information in the package and resume the update progress from where it fails. In the event of issue with new software release, the update engine should do rollback to the original running version on the handsets.
Conclusion
As a commercially proven technology, FOTA is becoming an even more important evolving field with smartphone growth and their complexity. Firmware update is no longer an exception, but a rule, just like windows update on a PC. As the foundation of FOTA, the diff engine has to be carefully designed to address the challenges in the mobile network environment. Mobile Device Management vendors therefore continue to evolve diff technology, bringing new and innovative techniques to market, keeping pace with handset evolution.

Jinsheng Gu is the principal research engineer and technical lead of InnoPath. He can be reached via JGu@InnoPath.com.

Mobile Services Management Software Offers Dynamic Growth

By Pankaj Gupta, President and CTO, Amtel, Inc.

Mobile Services Management Software has become very popular due to direct bottom line contribution at the organization level. Mobile services are very dynamic with new devices, new plans and new features appearing regularly. More companies are becoming educated on this software-based managed approach for their mobile services and the savings they can realize by implementing it. Enterprise buyers should look to the offerings that address the full procurement lifecycle of telecom expenses. TEM products now include sophisticated service order management, wireless mobility management services and international capabilities. The latest Gartner forecast puts this market in North America just under a 30% annual growth from 2006 to 2011.

We recently did a case study for a large utility corporation. The company had heterogeneous telecom structure with multiple carriers and services. Their employees are spread out nationwide. The management goal was to streamline order management, inventory and to reduce invoices expense. With the mobile services management software the following savings were realized:
12% savings with services optimization
6% savings with invoices audit
5% savings by higher contract negotiations as a result of detailed reports and competitive data
2.5% savings with spend accountability which eliminated wastage/fraud
Bullet List 0.1% savings on late fees
200 hrs./mo. savings on IT time for procurement/order management
160 hrs./mo. savings on automated invoice processing and cost allocation

Management software solutions for mobile and landline telecoms management does mobile policy management, inventory management, invoice management, procurement for all types of telecoms, plus cost center allocations. The software system works for all types of carriers like AT&T, Verizon, Qwest, Sprint, Tmobile and more.

Mobile management services based on the SaaS model are becoming popular due to their lower cost and constant upgrade to new features. To overcome the SaaS shortcoming of shared application, the newer applications have embraced the model where each client gets separate hosted software which allows customization, security and reliability.


Mobile Software Management Technologies Continue to Evolve

By Willie Jow, Vice President of Marketing and Business Operations, Sybase

The smart phone boom is not going to wait for an economic upswing. A recent survey by J. Gold Associates projects corporate smart phone use to double over the next three years and use of business applications on phones to grow by 71% over one year and 196% over three years. Enterprises are already experiencing persuasive ROI from mobility rollouts, including increased productivity, streamlined processes, improved customer relationships, and new business opportunities. However, as an IT manager charged with protecting an organization from hackers, this growth constitutes a very substantial threat to the security and integrity of your enterprise. Since the first mobile malware was discovered in 2004, more than 400 variants have attacked a broad range of devices, entering through the frontline of business and reaching into corporate networks.

The good news is that viable solutions are available with comprehensive security features. Security is at the heart of any good management solution and, as such, demand for a centralized approach to proactively monitor and manage devices is growing just as much as smart phones themselves. Expect enterprises to continue seeking out holistic offerings that incorporate capabilities such as corporate security policies, over-the-air data encryption, inventory and asset control, device lockdown, and push functionality for automated application and data updates.

Finally, mobile software management technologies will further evolve in 2009, moving beyond one-off, tactical deployments and becoming folded into larger, more strategic mobility initiatives. As such, what organizations need is exactly what many industry observers are proposing - a single, strategic architectural platform approach that allows organizations to mobilize data and business processes using any mobile device. As the mobile market grows, device varieties surge, and the number of back-end applications extended to frontline workers increases, we'll see more companies adopt such mobile platforms to reduce TCO, simplify application development and deployment, ease back-end integration with enterprise applications, and centralize management and security.


Advertisement

Share this Story

X
You may login with either your assigned username or your e-mail address.
The password field is case sensitive.
Loading