FOTA Best Practices. 5 Steps For Successful FOTA Implementation. White Paper

FOTA Best Practices 5 Steps For Successful FOTA Implementation

vrapid Mobile Notice Copyright 1999-2013, Red Bend Software. All Rights Reserved. Patented: www.redbend.com/red-bend-patents.pdf This Software is the property of Red Bend Ltd. and contains trade secrets, know-how, confidential information and other intellectual property of Red Bend Ltd. vrapid Mobile, Red Bend, and other Red Bend names, as well as the Red Bend Logo are trademarks or registered trademarks of Red Bend Ltd. All other names and trademarks are the property of their respective owners. The Product contains components owned by third parties. Copyright notices and terms under which such components are licensed can be found at the following URL, and are hereby incorporated by reference: www.redbend.com/red-bend-legal-notices.pdf

Table of Contents 1 Introduction... 4 1.1 FOTA Global Adoption...5 2 Overview of a FOTA System... 7 3 Step 1: Planning a FOTA System... 8 3.1 Back-End Management Considerations...8 3.2 Mobile Device Considerations...9 4 Step 2: Testing a FOTA System... 11 4.1 Prerequisites for the Tests... 12 4.2 Suggested Tests... 12 5 Step 3: Optimizing the User Experience... 14 6 Step 4: Operation of a FOTA Campaign... 16 7 Step 5: Measuring the Impact of FOTA... 18 8 Summary... 20 About Red Bend Software... 20 Table of Tables Table 3 1: Increase in Android Version Size... 10 Table of Figures Figure 1-1: OEMs FOTA Commitment...6 Figure 2-1: Overview of a FOTA System...7 Figure 4-1: Version Flow... 11 Figure 5-1: Example for User Experience... 14 Figure 5-2: FOTA Methods Time Comparison... 15 Figure 6-1: How to Start a FOTA Campaign... 17 Figure 7-1: Motorola Not Updating Devices to Newer Version... 18 2013, Red Bend Software [3 of 20] Confidential

1 Introduction Firmware over the air (FOTA) is proven to be the most cost-effective, reliable, and secure method for updating a mobile phone or wirelessly connected device. The volume of FOTA usage is increasing significantly as more and more updates are performed successfully every year on more and more device types. FOTA is now a standard feature of mobile phones, tablets, and other connected devices, since consumers expect their devices to stay up-todate with the latest features and performance improvements. In fact, consumers eagerly anticipate new firmware releases and become frustrated if their device doesn t receive timely updates. News about new software updates delivered over the air are published daily in telecom media channels, and when it comes to major versions of Android or ios, even in the mainstream media. In this white paper, Red Bend Software describes five steps for successful FOTA implementation, leveraging Red Bend s vast experience in providing FOTA to nearly 1,500 different device models over the last 10 years. By 2013, Red Bend predicts that the number of devices updated globally using FOTA will exceed 300 million and, given the growing percentage of FOTA-enabled smartphones and machines in the market, FOTA usage will continue to increase substantially in the coming years. Currently, most FOTA updates are provided through two sources: Mobile operators They use FOTA to keep devices up-to-date in order to reduce customer care costs. Operators typically use their own delivery infrastructure, mostly based on the OMA DM standard. They require manufacturers to include a FOTA client in their devices so that the operator can push software updates over the air to all devices in the network. Device OEMs In countries where control of the operators is not strict, most OEMs prefer to take responsibility for FOTA to ensure their customers get updates in a timely manner. The OEMs build their own delivery infrastructure, integrate a FOTA client, and push updates over the air to their devices. The growing amount and frequency of updates introduce new challenges for mobile operators and OEMs, such as selecting the delivery infrastructure, choosing the best FOTA client technology, and planning the scope and process of testing and validating updates. The need to implement effective processes for FOTA updating is especially important for Android-based devices, considering the growing problem of Android fragmentation. This white paper is intended to assist operators and OEMs in making these key decisions to ensure a successful FOTA implementation. 2013, Red Bend Software [4 of 20] Confidential

1.1 FOTA Global Adoption The usage of FOTA is taking place almost everywhere in the globe on all types of mobile phones and connected devices. Flash Networks, a global provider of intelligent mobile Internet solutions, published an analysis showing that the bandwidth consumed by software updates sometimes exceeds YouTube 1. This demonstrates the adoption and the impact of software updates and the fact that most of the leading OEMs and tier one operators are using FOTA. The following examples show the commitment of some key OEMs and operators about their FOTA adoption. 2 3 1 http://www.fiercetelecom.com/press_releases/flash-networks-releases-data-showingbottleneck-effect-mobile-operating-sys 2 http://www.businessinsider.com/how-ios-5-copied-android-2012-5?op=1 3 http://www.eyes4tech.com/2012/05/sprint-samsung-galaxy-nexus-ota-update 2013, Red Bend Software [5 of 20] Confidential

4 Figure 1-1: OEMs FOTA Commitment 4 http://www.nttdocomo.co.jp/english/support/utilization/software_update/ 2013, Red Bend Software [6 of 20] Confidential

2 Overview of a FOTA System A typical FOTA system comprises three main elements: FOTA Update Generator A PC-based tool that creates the update to be sent to the device. It identifies the essential changes between the existing firmware version and the new, updated version, and creates an extremely compact update file, called a delta package, of these changes. The Update Generator creates delta packages of a device image and its file system, which typically stores images, sounds, configuration data, settings, design themes, icons, menus, system status, and other information that affects device appearance, configuration, and branding. Communications Protocol Once the delta package is created, the file is sent to the device using a communications protocol. A back-end management system uses this communications protocol to enable service providers (operators or OEMs) to centrally manage firmware, applications, and mobile devices over the air. The OMA DM (Open Mobile Alliance Device Management) standard is the common protocol used to communicate between the management system and an OMA DM client on the device. This protocol, which is optimized for mobile communication, provides as part of the standard, all the management aspects of the software update process including key security functionality and the ability to perform device provisioning (bootstrap). FOTA Update Installer Once the delta package is successfully received by the device, it is installed using a FOTA Update Installer. This software resides on the mobile device itself and performs the update installation. Optimized for the limited memory available within a mobile device, it applies the updates in-place on the device s firmware accurately and reliably. It performs this update on devices with monolithic firmware images and on smartphones with compressed, multi-section images. The update installer also performs file system updates. Figure 2-1: Overview of a FOTA System 2013, Red Bend Software [7 of 20] Confidential

3 Step 1: Planning a FOTA System When an OEM or an operator wants to start a FOTA service, they should consider a broad range of factors on the mobile device itself, at the back-end management system and the connectivity between them in order to plan the FOTA system properly. 3.1 Back-End Management Considerations There are many parameters that can influence the back-end management infrastructure used for delivering FOTA updates. The list below describes the most important factors to consider: Type of devices what device portfolio exists in the network for example, M2M, smartphones, tablets) today and what is the forecast for the next three years Device operating systems which types and percentages of OSs exist in the network today and how may that change over the next three years Service area is it limited to one area or country, or is it a global FOTA service based on where devices will be used/installed Communications protocol what will be the protocol to communicate between the back-end management system and the mobile devices a proprietary protocol or based on the OMA DM standard Percentage of devices that will be updated by FOTA all or some the forecast should be for the next three years Expected size of the firmware what is the average size of firmware that will be sent to devices now and how can that be predicted over the next three years Frequency of the updates how many times on average will the devices get an update, and will updates need to be sequential or non-sequential Transport technology what is the common transport technology that will deliver the updates (for example, Wi-Fi, 3G, LTE) and will users/devices be roaming Bearer download rate what is the average download rate on the network that will be used to perform the update Duration of the update campaign how long should it take to update devices, both from the expectation of consumers as well as for M2M devices that are revenue-generating and therefore downtime is problematic Hosted solution will the FOTA back-end management system be part of a hosted solution in the cloud or operated internally Update strategy what is the preferred update option, either Push or Pull, or both 2013, Red Bend Software [8 of 20] Confidential

Determining answers to these important questions will provide a much better understanding about the dimension of the FOTA service, the server configuration, the required bandwidth, and the main functions of the management system. It is very important to select a system that will support all three stages in a FOTA campaign: Planning understanding which devices need to receive the update, developing business processes to create the needed delta packages (automated where possible), planning the update duration, estimating the impact on the data network and communicating with consumers/customers about the forthcoming update. Campaign execution running the update campaign over the set duration to the defined devices, monitoring the status, and providing alerts on predefined events. Analysis and reporting analyzing the results of the campaign. 3.2 Mobile Device Considerations A FOTA-enabled mobile device must have a FOTA Update Installer, also called a FOTA client, preintegrated with the bootloader of the device at the time of development, before the device ships into the market. This is because a FOTA client operates at a low level and is not like an application that can be downloaded later. The decision regarding the communications protocol between the device and the back-end management system also must be decided during the development stage, as it may require additional software to be pre-integrated into the device before it ships. For example, when choosing the OMA DM protocol for communications between the device and the management system, there is a need to install on the device an OMA DM client that will communicate with the back-end system. Today, most mobile operators include in their device portfolio many kinds of devices, from feature phones up to top-of-the-line smartphones and tablets, to numerous machines and consumer electronics. To simplify the operation of the update and ensure a uniform update process, it is recommended to use a FOTA client that can be easily integrated with as many device types and different platforms (for example, Android, ios, Linux). The fast introduction of new mobile devices requires OEMs to optimize their development activity in order to bring devices to the market on time and on budget. Activities with a potential to interrupt the development process should be carefully considered. Therefore, an update technology that is not intrusive to the development process and does not require changes to the manufacturing tool-chain is very important for meeting product launch schedules and still benefitting from having FOTA inside the device for the future. 2013, Red Bend Software [9 of 20] Confidential

With the volume of data traffic from software updates increasing rapidly, the unpredictable size of future OS version growth and the frequency of updates unknown, OEMs and operators face a huge challenge in planning their FOTA services. For example, the Android firmware image has grown to more than 200MB, before manufacturer or operator customizations. Table 3 1: Increase in Android Version Size 5 Release Android SDK Percentage of Growth Éclair 72M Froyo 76M 6% Gingerbread 87M 14% Honeycomb 110M 26% Ice Cream Sandwich 171M 55% Jelly Bean 203M 19% The way to mitigate these challenges on the device side is to select a FOTA solution that uses: Efficient delta technology achieves the smallest possible delta when comparing two versions of firmware, so that the update package (file size) that must be distributed over the network is at a minimum. Smart bearer logic manages the bearer selection to determine if the update will be downloaded either by cellular or by Wi-Fi, depending on defined criteria. Memory repartitioning allows OEMs to dynamically adjust during the update process the flash memory partitions on deployed devices to address the increasing and unexpected growth in OS size. Optimized user experience performs updates in a non-sequential manner (version 3 to version 5), instead of requiring sequential updates (version 3 to version 4 to version 5), which takes longer and causes user frustration. 100% reliability provides a fail-safe mechanism to guarantee the integrity and completion of the update process in the event of power loss or communication failure. Imagine the financial and credibility impact to an OEM or operator if devices cannot function because of an issue in the update process and as a result, require devices to be returned by consumers to a service center, or send a technician onsite to repair and troubleshoot the device. 5 Source : Android Developer Site 2013, Red Bend Software [10 of 20] Confidential

4 Step 2: Testing a FOTA System Updating the firmware of a device over the air adds additional tests to the process of introducing a new software version. On top of normal testing and validation performed by OEMs and operators when introducing a new device firmware version, there are several FOTA-specific tests that are crucial to perform to guarantee the integrity of the process. However, when developing FOTA testing procedures, it is important to be thorough but without causing delay in the introduction of the new software. It is recommended that OEMs and operators build a matrix that will measure key elements in the update process for each device category (for example, smartphone, tablet, M2M) and operating system (for example, ios, Android, Blackberry, and so on). Those elements should take into consideration not only technical parameters such as fail-safe and delta package size but also aspects that relate to the FOTA experience such as the download time and update time, and the UI during the FOTA process. There are two main approaches on how to conduct the tests, depending on whether the operator is using its own infrastructure to deliver the update or the OEM is responsible for doing the updates. Trigger for a new version OEM creates a new version and the associated delta packages OEM tests the new version with FOTA OEM/Operator performs the FOTA campaign Operator tests the new version with FOTA and approves it Figure 4-1: Version Flow This process was described in a blog 6 that was published by Chris May Head of Terminal Technology in Vodafone UK: Firmware testing can typically take anywhere from one day to one week, depending on our previous experience with an individual manufacturer, and the complexity of the upgrade itself, May says. Security releases and bug fixes are usually quickest to test, but platform upgrades with new features take longer. 6 http://blog.vodafone.co.uk/2012/07/17/firmware-testing/ 2013, Red Bend Software [11 of 20] Confidential

4.1 Prerequisites for the Tests Before the operator or the OEM performs its FOTA validation tests, it should perform all the standard communication tests between the client and the server. In the case where OMA DM is used, the operator or the OEM should include tests that are related to the communication and the management of the update process, according to the OMA DM standard (for example, FUMO 7 ). The operator or the OEM should provide the FOTA update package together with the full software whenever there is new software version for a particular mobile device. In addition, they should provide an update package for all the existing software versions of the device. For example, if the new version number is 5 and there are two versions deployed in the field, two update packages should be created one from version 3 to version 5 and the second from version 4 to version 5. For test purposes and to speed up the process (no need to manually reflash the device), the OEM or the operator should also provide an update package to downgrade the device software from the new test version to the older test version, for example from 5 to 3 and from 5 to 4. In addition, the operator or the OEM should set the required parameters of the devices that are included in the update campaign and load the delta packages on the device management server. There are few delta packages that are recommended to prepare for the tests: Firmware upgrading package the delta package that will be used for performing the update campaign Firmware downgrade package for test only purposes Large delta package for test purposes only, verifying update behavior if the size of the delta package is larger than the reserve area in the device memory Corrupt package for test purposes only, checking the update behavior if the package is corrupted The update packages will be used to perform test cases that validate the correct functionalities of the FOTA process and that test also the resilience of the system with extreme use cases such as a corrupted package or oversized package. 4.2 Suggested Tests This guide provides suggested test guidelines for evaluating FOTA updating solutions and is designed as a reference to be used by OEMs and operators in the technical evaluation of a FOTA solution. Silent download Verifies that the device supports Silent Download capability and not only the download approved by the consumer Successful update Verifies that the device can successfully complete the update process which includes two main steps: the download of the package and the update of the device Normal behavior after update Verifies that the device behaves normally after a successful FOTA update. The definition of normal behavior should be defined by the operator or OEM and can be limited to the area of the update or to the full extent of the device functionality. Ability to manage large FOTA update packages Verifies that the device is able to process a large FOTA update package even when the memory allotted for the FOTA update cannot accommodate the large update package. 7 http://h71028.www7.hp.com/enterprise/downloads/omadmfumov1.0.pdf 2013, Red Bend Software [12 of 20] Confidential

Server notification during a phone call Verifies the device behavior when it receives an update notification during a voice call. Corrupted update package Checks the device successfully detects an incorrect or corrupt update package before proceeding with the update process. The device should gracefully manage it and notify both the user and the back-end management system. Postpone/Accept/Reject update Verifies that the device allows the user to postpone, accept, or ignore the software update. In case of postpone, it should be able to set a reminder when to activate it again. In case of accept, it should start the update process. And in case of ignore, it should cancel the process. User initiated update Verifies that the device provides the ability in the device menu to check the software version and perform a software update and complete it successfully. Restoration of user data Verifies that the device successfully restores user data and preferences after a software update. Low battery during the update stage Verifies that the device does not start the update process if there is a low battery. The definition of low battery is defined by the OEM. Battery removal during the update process Verifies that the FOTA client can handle battery removal during the update process, simulating a loss of power due to battery drainage or battery falling out. This test can be performed a few times during the update process, for example every 10-20% of the elapsed update time. Battery charger connection/removal during the update process Verifies that the update process continues uninterrupted when the battery charger is connected and or disconnected from the device Incoming voice call during the update process Verifies that all incoming voice calls are routed to voice mail (if enabled) during the update process. If voice mail is not enabled on the subscription then the calling party should get a busy tone. Mobile originated a voice call during the update process Verifies the behavior of the device when a voice call is originated by the user during the update process. Incoming/originated SMS during the update process Verifies that incoming or originated SMSs during the update process do not cause any interruptions or failure of the update process. Touch the touch screen during the update Verifies that the FOTA client can handle any action in the touch screen or by the soft or hard buttons which exists on the device. Event reminder during the update process Verifies that the FOTA client can handle any preset event reminders such as calendar or alarm clock during the update process. Perform FOTA update on a locked device Verifies that a FOTA update is successfully performed on a locked device. This means that the device is locked before the update process starts and needs to be unlocked in order for the update process to proceed. Following the successful completion of these suggested tests, the operator or OEM can start a friendly update campaign where the new software version will be updated on a group of devices that belongs to company employees. The feedback from the friendly test will be analyzed and can be important in determining whether the update campaign can start. 2013, Red Bend Software [13 of 20] Confidential

5 Step 3: Optimizing the User Experience One of the important factors in a successful device update strategy is to understand how to make this process as easy as possible for the users. As described in Red Bend s previous white paper about FOTA usage in the US, FOTA is by far the most convenient and simple way for consumers to update the firmware on mobile phones and connected devices. In the example below, an LG Lucid device on the Verizon network is getting a software update by a push method, meaning that the back-end management system is initiating the FOTA update campaign. The user has the flexibility to decide when to perform the update and, if the decision is to apply the update now, it means that in only two clicks the device will have a new version. Figure 5-1: Example for User Experience Since some mobile subscribers are hesitant to install new versions, the way to remove this barrier is to ensure that the update message comes from a trusted source, such as the operator or the OEM. In this message, it is important to provide customers with a brief explanation of the content of the update, the benefits to the user for performing the update, and how much time it is expected to take (for example, in the Lucid case it is seven minutes). One of the methods to improve the user experience is by reducing the time needed to perform the updates, because during this time mobile subscribers cannot use their device. The proposed method is updating the device firmware in the background while the device is fully operational. In this approach, all of the software on the device must be available for the user, while in parallel the FOTA client updates the software on flash memory. The background update capability must provide a consistent view of the phone software, to the OS and to the user, throughout the update process. The user must see a consistent version of the software, regardless of the actual state of the flash memory while the update is happening. The user experience of launching any application must not be degraded, in comparison to a phone that is not performing an update. The below chart demonstrates the main consumer benefit of background updating it reduces significantly the time when the device is not functional to around one minute without any dependency on the size of the update. 2013, Red Bend Software [14 of 20] Confidential

Figure 5-2: FOTA Methods Time Comparison Downloading the software update package in the background is sometimes mistakenly referred to as background updating, but downloading and updating are two different steps in the FOTA process. Background downloading improves the overall FOTA process, but is not actually related to the software update itself. Downloading the update package while the device is operational takes advantage of the multi-channel nature of most 3G networks, which typically have three channels: control (cell management, SMS, and so on), data (e-mails, browser, and so on), and voice. A properly designed device management client based on the Open Mobile Alliance Device Management (OMA DM) protocol should be able to receive an update package that has been pushed by the service provider without interfering with the consumer s usage of the phone, including the ability to make and receive phone calls. Background downloading and updating is particularly important for M2M and connected devices that are used to deliver revenuegenerating services, because it significantly reduces the amount of time that the device is offline. 2013, Red Bend Software [15 of 20] Confidential

6 Step 4: Operation of a FOTA Campaign There are several prerequisites before starting a FOTA update campaign: The tests and QA for the new version should be completed successfully, typically taking 2-3 days to complete The IMEI/IMSI of the target devices should be in the database Generation of the delta packages for the various combinations Estimation of the impact of the update campaign on the transmission network Decisions for the campaign strategy (for example, how many devices in each group, is it going to use only Wi-Fi, push or pull, and so on) After the campaign has started, monitoring the success rate and the feedback regarding the new version As described in section 2 Overview of a FOTA System, the FOTA system includes two main subsystems: the FOTA client and the back-end management system. While the FOTA client is responsible for performing the actual update in the most secure and reliable way, the back-end management system is responsible for the end-to-end operation and the management of the FOTA campaign. In the example below, which was taken from the Red Bend Software Management Center, starting an update campaign is quite easy and requires only a few steps. The first step is to define the campaign name, the device population and the start and end dates/times of the campaign. This will determine how many devices will be updated every hour across the defined period. It is possible to define if the campaign is critical or not, which will prioritize the campaign over the other campaigns, and if the update will be silent or not (meaning, not require user acceptance). The administrator can select the devices that will take part in this campaign based on several options, such as device model or manufacturer s name. After this, the campaign is ready to go. One of the main points that can guarantee a smoother and safer FOTA campaign is the use of OMA DM as the management protocol between the devices and the back-end management system. The OMA DM protocol was designed for mobile networks and enables key benefits to both OEMs and operators: Fast time to market there are already off-the-shelf OMA DM clients with only minimal customization needed Interoperability independence between the client and the back-end Security the connection between the device and the back-end is secured with TLS or SSL 3.0 protocols Portability easy implementation to any platform or device type Supporting the device lifecycle the protocol supports provisioning, configuration and software management Reliability in case of low reception levels in case of an error during the download of a package the process will continue from when it stopped and not from the beginning 2013, Red Bend Software [16 of 20] Confidential

Figure 6-1: How to Start a FOTA Campaign 2013, Red Bend Software [17 of 20] Confidential

7 Step 5: Measuring the Impact of FOTA The FOTA user experience depends on several factors, such as the quality of the update process and the timeliness of updates. From a consumer s point of view, FOTA is no longer a special feature of only the highest end devices. Consumers expect to get timely software updates to their mobile phones and connected devices similar to their PCs and laptops, and the FOTA reputation of the OEM can impact a consumer s next buying decision. Recently Motorola announced 8 that three of its devices will not get an update to the next version of Android, and based on the comments to the article, some customers were really unsatisfied about it. Figure 7-1: Motorola Not Updating Devices to Newer Version For Motorola consumers in the U.S. that will not receive the Android Jelly Bean update, Motorola is offering a $100 rebate to trade-up to another Motorola phone. 9 This is evidence of the growing problem of Android fragmentation, where new Android updates do not become available to all Android devices, leaving the Android installed base on disparate firmware versions. From the perspective of the operator, it is important to control the update process regardless whether it is done internally or by the OEM, since if there will be any issue, consumers will probably approach the operator first and not the OEM. This is the reason why it is important to first understand the customer motivation to perform the updates and their awareness and usage of FOTA, and based on that together with other considerations to develop an update strategy and plan its associated implementation. Two surveys were conducted in 2012, one for Red Bend and the other for Skype, which provide detailed information about consumers and their software update behavior. In Red Bend s survey, which was conducted in the U.S. together with a leading market research company, consumers were asked about their awareness and usage of FOTA. The survey exposed very interesting facts about which consumers perform the most updates and on which devices. Key highlights from this survey are: 18% of U.S. mobile phone consumers are aware of the term FOTA. Awareness is significantly higher among smartphone users (27%). Most consumers (69%) receive pushed updates as opposed to pull an update themselves (28%). Minor to modest differences exist in FOTA awareness among OEM and operator subscribers. Sprint (47%), HTC (46%), and Motorola (50%) smartphone users all report higher FOTA usage compared to the smartphone average (35%). 8 http://news.cnet.com/8301-1023_3-57523823-93/motorola-wont-update-three-4g-phonesto-ice-cream-sandwich/?part=rss&subj=news&tag=2547-1_3-0-20 9 http://www.motorola.com/blog/2012/10/19/trade-up-to-a-new-motorola-smartphone-andyou-may-qualify-for-100-back/ 2013, Red Bend Software [18 of 20] Confidential

Demographics play a large role: Awareness declines steadily as age increases. 27% of 25-34 year olds are aware of FOTA, compared with 13% of those 55+. Men are significantly more aware of FOTA. 40% of male smartphone owners are aware of the process, compared to 19% of women who own a smartphone. Women smartphone owners show some confusion about the update process. 29% do not know if they have ever participated in a phone update. On the other hand, only 14% of men indicate they do not know if they have participated in a firmware update on their smartphone. Although the Skype survey can be related more to PC users, the relevancy of this survey to mobile devices is quite high. This survey was conducted for Skype, Symantec, and TomTom as part of the International Technology Upgrade Week 10. The key highlights are: 40% of adults do not always upgrade software when prompted to Top reasons for upgrading were: To keep my computer safe and secure 76% Ensure my software is free of bugs 67% I want to make sure that I have the latest and greatest features 47% Top Reason for not upgrading were: I worried about the security of my computer 47% They take too long to do 27% There is no real benefit for me 25% Men are more likely to update their software About a quarter of adults say they need to see a prompt twice before upgrading software About a quarter of adults say they do not know how to check if their software needs to be upgraded 10 http://www.multivu.com/mnr/56965-skype-norton-tomtom-invite-consumers-to-updatesoftware-for-free 2013, Red Bend Software [19 of 20] Confidential

8 Summary The value that consumers see in improving their mobile devices with FOTA updates is pushing OEMs and operators to think about how to improve their FOTA update strategy. Planning a winning FOTA system is similar to planning any cellular system which starts first by analyzing the customer s requirements, proper dimensioning, deciding which technology to use, and finalizing the business logic that will determine what will be the user experience. The information that exists in this white paper can be very valuable to OEMs and operators for enhancing their FOTA update strategy and for improving customer satisfaction. Red Bend recommends communicating clearly with consumers about when updates are coming and what content is included in the update. In addition, it is beneficial to promote security functionality that is part of the new version, since this is one of the main drivers for customers to perform the update. Testing the process is very important, as one of risks to perform an update over the air is to lose control over the process and, more seriously, cause the device to become a brick. With the right tests combined with a reliable FOTA client this uncertainty can be removed. Finally, it s important to measure the FOTA experience the same as operators measure other KPIs such as speed and coverage. One way operators and OEMs can measure FOTA is to check the percentage of consumers that accept each update. Using Red Bend s experience in providing its FOTA solution for more than 1.6 billion mobile phones and connected devices, and its experience working with more than 80 customers, OEMs and operators can learn how to build and operate a successful FOTA service. About Red Bend Software Red Bend Software, the leader in Mobile Software Management (MSM) with more than 1.6 billion Red Bend-Enabled devices, makes mobile devices and services continuously better in a rapidly changing world. Red Bend is the only company that provides standards-based products and solutions for software management, device management, and mobile virtualization that work on any mobile phone and connected device uniformly, efficiently, and securely over the air. Red Bend enables its customers to stay competitive in a fast-moving market by helping them deliver highvalue services on an increasing number of connected devices with growing software complexity. More than 80 leading device manufacturers, mobile operators, semiconductor vendors and automotive companies worldwide trust Red Bend with their most important assets the mobile and connected devices their consumers depend on. 2013, Red Bend Software [20 of 20] Confidential