An Mformation Whitepaper
FOTA BEST PRACTICES:
IMPROVING THE PROPORTION
OF SUCCESSFUL FIRMARE
FOTA Best Practices: Improving the
Proportion of Successful Firmware
Updates
Mformation has supported firmware update or firmware over-the-air (FOTA) services for several years. This paper outlines specific actions and techniques that can ensure best practices for mobile operators/carriers running or planning to run firmware update services.
In specified instances where best practices are used, we have seen acceptance rates of 80%-90%. In other circumstances, low acceptances rates — even rates in single figures — have been observed. This paper outlines a range of options to support efforts to increase acceptance rates.
Summary
There is a range of techniques available that increase the proportion of successful firmware updates. This paper recommends the following actions:
1. Limit user interaction and ensure good usability: Minimizing user interaction in the update process reduces the impact on the user, thereby increasing acceptance rates. The optimal outcome is a “hands free” firmware update. There is a range of options to reduce user interaction, from running the updates in the background to “1 click” acceptance.
2. Clearly communicate to customers: Marketing plays a fundamental role in increasing acceptance rates, from supporting clear communication with the user, to creating some perceived or actual value within the update campaign.
3. Utilize a range of FOTA channels: Provide users with additional update mechanisms beyond a network-initiated batch program. A “push plus pull” campaign that is well supported by marketing and customer care leads to higher
acceptance rates. Device-initiated firmware updates, for example, have high acceptance rates because the user is actually triggering the process. Customer care-initiated firmware updates also have high acceptance rates because the customer care agent is often considered a trusted advisor.
4. Carefully plan FOTA campaigns: A FOTA campaign should be treated like a development project — it needs clear objectives, milestones and deliverables. A firmware update campaign needs to be thought through and tested to ensure that all users, devices and network states have been considered, that the download and update processes work as expected, and that there are no unusual or unintended consequences.
5. Use the FOTA client optimally: Device vendors/OEMs should take care when implementing the FOTA client to make sure that it uses the technology to its optimum effect. One of the most successful times to initiate FOTA is when the SIM card is inserted or when the device discovers the home network for the first time. Additionally, it is possible for the device to initiate a FOTA session periodically to check for updates; this can be done in the background and significantly increases the success rate because there is not interaction with he consumer.
A range of techniques is available for increasing the proportion of successful firmware updates. This paper looks at both technical recommendations and marketing techniques that can improve the acceptance rates of firmware updates:
1. Technical recommendations:
MDM/FOTA server implementations Device implementations
Firmware update campaigns 2. Marketing
Mixed channels General marketing
Promotions and incentives Feedback loops
Context
The key components and interfaces of a typical firmware update deployment are outlined in the diagram to the right.
The key component is the MDM/FOTA (firmware over the air) server, which provides centralized management of the firmware update process. The MDM/FOTA server has the following interfaces:
Firmware
Package Ingestion.
The firmware packages are forwarded from the device vendors for ingestion on the platform. Firmware packages come with a set of metadata detailing items such as the source and target revisions of the firmware, the device model, the delta binary and general notes on the purpose of the firmware package.
Network Interface. This is an optional interface providing three key data points: the
phone number, the phone serial number and a shared secret. The phone number is used to contact the user. The serial number is used for different things depending on the network type: in a GSM network it is used to identify the device as it appears on the network; in a CDMA network it is used as part of a shared secret to secure the OMA DM bootstrap configuration. In GSM networks the shared secret is used as-is to secure the OMA DM bootstrap. Roaming information is also provided on this interface and can be used to restrict firmware updates to the home network.
SMS-C interface. In practical terms, for GSM and CDMA networks this is a mandatory
interface used to push a request to the device. The ability to push to a device is key, as it enables remote bootstrap and server-initiated sessions.
The Device’s Communication Interface. The device can connect to the server in two
on demand from the MDM/FOTA server, also known as a server-initiated firmware update.
Customer/Self-Care Interface. This is used to trigger network-initiated firmware
update sessions for a particular end user. It will aslo ensure that the support organsisation can respsond to any customer issues. This can be driven by a Call Center operative or via an internet portal.
Batch Submission Interface. This is used to trigger network-initiated firmware update
sessions to multiple users. The interface can be a file upload or a database query mechanism.
Management – Lifecycle Management of Firmware Packages
Device vendors/OEMs are an important part of the firmware update process. They design, source, build and market the devices, and generate the delta packages that are used for the firmware updates. Once the devices are in use, the device vendors are expected to provide delta packages for use with remote firmware update processes/systems.Most updates occur early in the life of a device. In many cases the devices are under some sort of warranty. This means that there is a business benefit to the device vendor to updating the device in the field rather than having the device returned or repaired in a service center. When the device vendor has provided the firmware package and associated metadata, it can be ingested into the firmware update server. This can be done semi-automatically if the metadata and firmware package are bundled in such a way that the firmware update server can ingest them automatically. This sort of automation has the benefit of reducing the time spent and errors associated with ingesting the firmware.
When using the OMA DM protocol, it is necessary to bootstrap the device prior to actually deploying a firmware package to that device. This enables a secure and trusted communication channel between the device and the MDM/FOTA server. There are a number of ways to bootstrap a device. The most reliable method is to bootstrap the device prior to when it enters the network; this is known as “factory bootstrap”. However, factory bootstrap may not always be possible if the MDM/FOTA server mobile operator/carrier is not able to influence the manufacturing and retail processes. The alternative is to bootstrap the device over the air (OTA); this can be achieved with varying levels of success depending on whether the user is expecting the update and what level of interaction between the MDM/FOTA server and the user is required.
Assuming that the device bootstrap task has been addressed, there are three key mechanisms for actually triggering firmware updates:
Batch submission
Customer/self-care-initiated Customer device-initiated
Batch Submission
In a batch submission, the firmware package is received from the device vendor and ingested into the MDM/FOTA server. The devices in the market that need the update are identified, and the MDM/FOTA server distributes the firmware update to the target devices. Delivery and acceptance of the update package are monitored.
Customer/Self-Care-Initiated
The customer/self-care-initiated firmware update occurs when the user contacts a customer care agent because of an issue with their device. The customer care agent has made a determination, based on a prompt from the MDM/FOTA server, that a firmware update is required to resolve the issue. The customer care agent initiates the firmware update to the user’s device and monitors delivery and acceptance.
Customer Device-Initiated
A customer device-initiated firmware update is user initiated via an on-device trigger (e.g., a repair button in menu) embedded in the device, which the user can use to trigger the MDM/FOTA server to upgrade their device. In the most common case, when a user requests a firmware update via an on-device trigger, it is to upgrade the firmware to the most recent revision supported by the MDM/FOTA server.
Recommendations
TechnicalMDM/FOTA Server Implementations
1. Network PIN is almost a mandatory requirement. The MDM/FOTA server needs to be integrated into the network in order to obtain subscriber information. When the MDM/FOTA server is informed of the identity of the user via a network PIN, the end-user experience is much improved and user interaction is minimized.
Expecting a user to input another PIN and/or requiring some other acceptance procedure will lead to lower acceptance rates.
2. It is important to be able to assess roaming status. The MDM server needs to be integrated in such a way that it can assess the roaming status of the subscriber at firmware update time. When the user is roaming, significant charges can be incurred. It is best to avoid firmware updates to subscribers when they are not in their home or partner network.
3. A customizable workflow tool should be utilized so that the firmware update customer experience can be tailored to the conditions of the particular network.
Device Requirements
Device requirements implemented by the device vendor/OEM are critical. Device requirements include:
1. The ability to run updates in the background. Updates in the background have
one of the highest acceptance rates and are fully supported by the OMA DM and FUMO standards.
2. The ability to run the update without acceptance. In this case the end user can
be presented with a status bar and notification of what is happening on their device. This is an alternative if executing in the background is not permitted due to customer, regulatory or legal reasons.
3. The ability to control the interaction. In the case where an interaction is required,
the device should always allow the OMA DM session, but the actual notification will come from the server in a user interface alert. This allows the MDM/FOTA server to provide a more friendly process (e.g., a user alert that steps the user through to the update).
4. Device interoperability. The device implementation should go through an
interoperability test with the MDM/FOTA server to ensure that the process works and complies with FOTA service requirements from end to end.
5. OMA DM bootstrap. The whole process relies on the OMA DM bootstrap. If factory
bootstrap cannot be performed, then the OTA bootstrap should be optimized without interaction from the user through the use of a network-provided shared secret. Factory bootstrap is the most reliable method of OMA DM bootstrap and the
device provider should have the devices bootstrapped to the MDM/FOTA server at manufacture.
6. The ability to initiate a firmware update from the device. In this case, a menu
item or button should be provided on the device to initiate the firmware upgrade. The location of the button or menu item should be intuitive and easy to find. Alternatively the device can initiate the pull at a certain event such as when the SIM is inserted or when the mobile operator’s/carrier’s network is detected for the first time. It is also possible to have a schedule in the device that acts at particular intervals; these types of mechanisms tend to have a very high success rate, as there is no need for consumer interaction.
Firmware Update Campaigns General:
1. Set a maximum file size and update time. If there is an explicit process that downloads then begins a foreground update process, it is not reasonable to expect the user to defer other activity while the download or update is running. The file size limit will vary by market. In some customers, the marketing group has set explicit limits on both the file size/download time and the update time.
Batch Firmware Updates:
1. The process needs to define the user device correctly using a mix of MDM and other customer data. It is necessary to have the right user and device information in order to clearly understand the full target population.
2. To control the flow of upgrades such that they do not overload the network resources, the devices to be updated should be segmented into manageable chunks. Mformation recommends a maximum of 5,000 users or devices per run. From a management point of view, the result of each run should be monitored and assessed prior to initiating the next run.
3. The size and timing of batch runs need to be within the performance parameters of both your MDM server and other network elements.
4. Retry should allow enough time for all devices to be reached in sequence before the start of the retry process. In our experience, performing the retry process 8 hours or more after the initial attempt ensures that there is no abnormal queue forming due to a short retry period.
5. Timing of batch runs is critical and needs to reflect local market conditions, from network activity and congestion to user behavior and activity.
Other:
6. Where possible, augment the batch program with other FOTA channels — the most successful campaigns combine network-initiated batch campaigns withcustomer care/self care capabilities and device-initiated updates:
Integrate with mobile operator/carrier support processes. When a firmware campaign is running, ensure that technical support or customer care can support the campaign if fielding a call. Performing FOTA updates through customer care leads to higher acceptance rates.
Device-initiated FOTA updates lead to high acceptance rates. Using the device to trigger the FOTA update is a valuable additional channel.
Test/trialing recommendations:
Trialing is a very critical part of the process — thorough trialing can ensure that acceptance rates and likelihood of success increase.
1. Thoroughly test a wide range of device, user and network states. Over time, Mformation has seen unintended consequences leading to lower acceptance rates from not testing each of these conditions (e.g., a specific device state causing the update not to run and therefore leaving the device in an un-updated state, causing non-acceptance)
2. Test with friendly user groups to road test all elements of the campaign. User groups can provide invaluable feedback on both hard and soft elements of a campaign.
3. Certified devices perform better and in an expected manner. A certification or self-certification process for devices and firmware packages will increase the certainty that firmware updates will work properly in the field. Uncertified devices will need to be tested to determine that they comply with FOTA service requirements.
Marketing
Marketing plays a fundamental role in increasing firmware update acceptance rates. A successful firmware update process often will depend on some sort of user/subscriber acceptance.
Channels: Customer-Care, User Initiated And Point-of-Sale
As noted previously, the Call Center offers a great opportunity for supporting the firmware update process. First, if the customer is ringing about a device issue, embedding the update process into the standard workflow of the Call Center agent should be a natural part of the call flow for diagnosing and resolving the issue.
For other types of calls that may be non-device-related (billing, upgrades, churn, top-ups), there is an opportunity to cross-sell the firmware update during the call. It can be presented as an opportunity to ensure that the user’s device is working/will work and can be sold as being preventative, ensuring that the subscriber does not need to contact the Call Center again.
In a number of customers, Mformation has worked on Call Center programs to embed the firmware update process into the call flow. The firmware update acceptance rate when users are on a call interacting with the Call Center is greater than 80%.
Customer-initiated firmware updates lead to high acceptance rates. The onus is on the mobile operator/carrier to directly communicate the capability and value to the user of the on-device menu. The alert on the device need to clear and prominent and should be supported by other communication. Communication channels can include all of the normal channels (e.g., website, bill insert, etc.).
As part of a wider service provider self-service program, self-care provides a operationally cost-effective mechanism for accessing firmware updates. The self-care environment can be used to communicate with the user, detailing both the issue and the solution, and should also be able to initiate the update.
Where a mobile operator/carrier has point-of-sale premises, there is a similar opportunity to embed the update process into the discussion flow on other device and non-device issues. Further, in many territories mobile operators/carriers may have dealers or agents who act on their behalf, providing another opportunity to embed the firmware update process into the discussion flow.
General Marketing
T&Cs: If possible, get acceptance for the OTA management of firmware on the device
through standard terms and conditions of service when the device, tariff or subscription is purchased or entered into. This reduces the criticality of user acceptance during the update process. At that point, the issue becomes determining the appropriate level of user communication.
Communications: The specific update interaction needs to fit within the wider relationship
between the subscriber and the mobile operator/carrier. This can apply to any piece of the program outlined below, from the use of logos, brands and brand assets, to a consistent look-and-feel for materials and the mobile operator’s/carrier’s language and terms.
Messaging: If a user needs to physically review and accept a message before the firmware
update can be accepted and successful, there are a number of specific marketing techniques that can raise the success rates of the process:
Benefits of accepting: There needs to be a clear and concise articulation of the benefit to the user of accepting the firmware update. The specific problem(s) that the update file resolves need to be highlighted; these benefits can include such things as:“The update will resolve x or y.”
“You need to accept these updates for the xx service to work.”
Clear copy: The message needs to be clearly written in non-technical language. The
message should clearly identify the sender (the mobile operator/carrier), the actions that need to be performed by the user (accept the message) and the benefits (services will work).
Trusted sender: Subscribers receive all kinds of unwanted communication — including texts — from unknown (and known) third parties. Spam and fraud via this channel are on the increase. There is significant resistance to engaging non-trusted senders. The mobile operator/carrier must reinforce their role as (trusted) service provider and ensure that the message is clearly understood to be from the mobile operator/carrier and not from some other party. Key steps include:
o Clearly branding the alert-SMS message with the mobile operator/carrier name — a necessary first step
o Reinforcing the mobile operator/carrier contact/contact name by engaging the subscriber at key trigger points (e.g., when roaming)
o Using the SMS-alert channel with some sensitivity — a mobile operator/carrier that overuses the channel may be perceived to be no different from other third parties
o MDM alerts have the advantage of being assigned to the mobile operator/carrier and of allowing control of the user flow and interactions.
It may be necessary to align multiple messaging channels in order to effectively communicate with the users, including:
General communication that includes information on the issue (e.g., website, bill insert, staff training etc.)
OMA DM or SMS alert with batch campaign
Customer care script with call workflow in call center Device menu and on-device alert
Promotions and Incentives
As has been noted previously, all interactions with the subscriber should be benefit-focused — for example, highlighting the benefit to the user of accepting the firmware update message. One very effective technique for increasing acceptance rates is to provide direct incentives to the user for accepting the firmware update. Incentives can be goods and services that are dependent on a well-set-up, bug-free device. For example, for a bug or issue related to internet access, the user might be offered free ringtones from the mobile operator’s/carrier’s portal.
This approach:
Incentivizes acceptance
Is dependent on a successful update
Promotes an advanced data service from the mobile operator/carrier
An incentive/promotion could be across any wireless service area and could include such things as: airtime, improved tariff, picture messaging, ringtones, downloadable content, etc. Depending on how well the mobile operator/carrier understands the user base, there also may be opportunities to tailor or segment the incentives/offers.
The tailoring of these incentives and promotions will be mobile operator/carrier-specific and will necessarily depend on the commercial strategy and key objectives of the device management program. All mobile operators/carriers have promotional activities occurring throughout the year. When high-priority services are being promoted into the subscriber base, this provides another opportunity to ensure the basic setup of their devices for device management. Services that work well for this are advanced data services that require
connectivity and specific settings on the device. The device management team needs to engage more widely with the organization in order to tie into these activities.
There have been countless examples of mobile operators/carriers incentivizing acceptance — this is very well understood process and has significantly increased acceptance rates for those mobile operators/carriers who have used it.
Feedback Loops
As with any program, there should be both a definition and an execution phase. For each and every element of the program, ongoing monitoring is necessary in order to assess effectiveness and outcomes (e.g., do customers/customer segments understand the message, is the mobile operator/carrier a trusted source, is trust increasing, are Call Center agents effectively supporting call flow, are incentives working, etc.). For an update program of many stages, monitoring and optimization can occur as segments or batches are run. Gathering feedback then allows further tailoring of the programs to improve outcomes and increase acceptance for the next firmware update campaign. Lessons learned in each campaign should be applied to the next one.
CONTACT US
If you would like to receive additional information on our company and our innovative mobility management
solutions, please feel free to contact us. Mformation Software Technologies, LLC 581 Main Street, Suite 640
Woodbridge, NJ 07095 Tel: +1 732 692 6200 Fax: +1 732 549 7542 www.mformation.com [email protected]
