ENGLISH
 日本語 中文 한국어
|
|
CUSTOMER SUPPORT
SITE MAP
|
 |
|
|||
|
|
|
|
Background Updating Comes to the ForegroundBy Ilana BogomolnySenior Product Manager Red Bend Software Whether we’re using a PC or a Mac, we all receive those popup windows alerting us that a software update is available. We don’t think twice about those popups because they’re common practice today in the world of computers. We know we must execute those updates in order to keep our machines healthy. The updating process is exceptionally simple. We activate the update and continue using our email or other applications, letting the update perform in the background. But we know that the more applications we are running, the slower the software updates will take to install. Periodically, we may check the progress bar and see how much time there is left to the update. Once the update is completed, we may be asked to reboot our system. All very simple! There is a similar process for updating the firmware on your mobile phone—but with a BIG difference. The update does not happen in the background—in fact, the phone is unusable until the update completes. For those of us specializing in FOTA, we understand that the time to complete the update process is dependent on several factors, including how many changes are taking place to the firmware. In some cases, it may take 15 minutes or more. With mobile phones serving as the lifeline for so many users around the world, any amount of downtime can be unacceptable, especially during emergencies. Red Bend has changed the FOTA paradigm with a new innovation called Background Updating. With Background Updating, the phone is only down for as long as it takes to reboot. The actual update happens in the background while the phone is fully operational. Since the updating process requires memory and processor resources, and these are not as abundant on the phones as they probably are on your PC, running resource-hungry applications, such as watching video or playing some games, would not be advisable during an update, as they might work somewhat sluggishly. But there is nothing to stop you from making and receiving calls, browsing the Web and generally using the phone as you normally would. There are several ways how the mobile user can interact with the Background Updating process.
With Background Updating, update time becomes irrelevant because 1) the user is still able to fully use the device and 2) the user decides when to reboot. Rebooting does not have to be executed immediately after the FOTA update. For instance, it could occur when the user shuts off the phone for its daily recharging. Because of the simplicity and ease of Background Updating—and how it mirrors software updates on computers—it is quickly coming into the foreground of operator requirements for FOTA. And with good reason. Many have service level agreements covering availability of the phone and the network. Others have legal considerations for access to emergency services, such as E911 in the United States. In addition, operators are responding to the customer needs of establishing a familiar software updating process, regardless of the type of device: PC, Mac, feature phone or smartphone. To see Background Updating in action, watch this video. Labels: firmware, FOTA, mobile software management
305 Million Mobile Phones, 29 Licensees and $10 Million in Funding to Fuel What’s NextBy Yoram SalingerCEO Red Bend Software There are many exciting developments happening here at Red Bend. Our vCurrent® Mobile FOTA software has shipped in more than 300 million mobile phones. This milestone has been reached thanks to your continued support. Over the past year and a half, we have seen our business grow rapidly as firmware updating and device management achieve mass market adoption. According to Ovum, more than half of all new mobile phones are coming to market with FOTA software, and this number is projected to increase to 84% by the end of next year. With FOTA-enabled phones now widely available, we are working closely with our customers and partners to increase usage of over-the-air software updating. Our innovative Background Updating feature, we believe, sets the new standard in FOTA and significantly improves the mobile user experience by performing the firmware update in the background while the consumer continues to use the phone, without taking the device offline. As of Q1, we now have 29 licensees of our software products. Red Bend has amassed a wealth of experience and knowledge about best practices in OTA software updating. We recently launched an effort to document best practices in creating “FOTA-friendly firmware.” I encourage you to contact us to learn more and see how we can assist you in efficiently provisioning firmware updates. Lastly, I am pleased to inform you that Red Bend has closed a funding round of $10 million. The new funds will be used for sales and marketing to grow our position in the mobile market as well as seize new opportunities in licensing our software for other connected wireless devices. In addition, the funds will be used to accelerate investment in research and development to bring you new innovations in mobile software management. Stay tuned to see what’s next. Labels: FOTA, mobile software management, Red Bend
Software on the Edge: MSM Reaches New FrontiersBy Yoram SalingerCEO Red Bend Software Having experienced the benefits of MSM for mobile phones, operators are beginning to require software management for all edge devices in the network. Mobile broadband PC cards are some the latest devices to benefit from FOTA and OMA-DM capability. With MSM, operators can provision settings over-the-air, reduce customer support costs and keep consumers satisfied with their mobile services—whether they are talking on their mobile phones or video conferencing from their PCs. The fact that operators are extending MSM to mobile PC cards shows the increasing importance that operators are placing on having full management control over their networks. Red Bend is in a unique position to give operators a consistent level of control in a world of heterogeneous terminals. We are the only company totally focused on remotely managing software inside mobile devices. Our experience working with 15 manufacturers across a dozen different mobile platforms (both open and proprietary) enables Red Bend to intimately appreciate the complexities of mobile software architectures. We recently celebrated shipping our market-leading vCurrent® Mobile solution in 200 million mobile phones worldwide. Soon, mobile broadband PC cards will come to market that are Red Bend-enabled. And after that, well… stay tuned. As operators and manufacturers become more advanced in their use of MSM, Red Bend will continue to innovate and deliver new solutions that enable our customers to derive even greater value from software on the edge. Labels: FOTA, mobile software management, OMA-DM
Best Practices in Creating Firmware for Over-the-Air Update DeploymentBy Ilana BogomolnySenior Product Manager Red Bend Software In the mobile phone market, increasing numbers of devices now support FOTA—Firmware Over-the-Air (FOTA) updating. FOTA is the most cost-effective way to maintain the device firmware and to provide new features remotely. It is already common practice for operators in Japan and the US, and is gaining momentum with OEMs and operators in Europe. However, even with wide support for FOTA capability across feature phones and smartphones, the actual deployment of firmware updates varies by operator, OEM and even by region. Updating mobile firmware over-the-air is new territory and a subtle paradigm shift for device software developers and integrators. Raising the level of awareness about best practices in creating and deploying new firmware versions using FOTA can significantly accelerate market adoption as well as improve the consumer experience and level of trust in this new technology. To optimize the FOTA user experience, the updates need to be as small as possible, and the update process should be as fast as possible. From the device manufacturer perspective, updates should be easy to create and test. For the past five years, Red Bend Software has been providing its market-leading vCurrent® Mobile FOTA solution to the industry’s top device manufacturers on more than 100 device models, implementing a wide variety of device architectures, chipset platforms and operating systems. Red Bend's Field Application Engineers have accumulated a wealth of hands-on experience in supporting our customers through successful integration, adoption and deployment of FOTA. At Red Bend, we have learned that although using vCurrent Mobile for FOTA updating does not require any changes to the manufacturer’s tool-chain, the awareness of the factors affecting firmware updates can have a significant effect on update size and speed and ultimately the consumer's experience. So what are these factors? FOTA updates are created by calculating the difference between old and new firmware versions. This means that OEM software developers and integrators should not consider each software release only as a standalone project, but should also be aware of the amount and nature of the changes introduced since previous versions. As many teams contribute components to a software release, it is often difficult for the configuration manager to figure out who is contributing most changes – Red Bend provides a set of tools which allows the configuration manager to understand who is contributing what kind of changes. The updating experience for the consumer should be as easy and brief as possible. To this end, creating and sending a single file that updates the firmware version is always preferable to sending a series of updates incrementing one version at a time. In addition to improving the user's experience, single-step, single-session updates provide less opportunity for the phone users to cancel the download process, and thus will increase the rate of successfully completed update sessions. Other factors that affect FOTA are the optimization of the FOTA Update Agent during the integration onto the device, and the optimal usage of update generation tools when FOTA updates are created and deployed. In addition, standard engineering practices for software updating involving data formats and API compatibility should be observed. In order to help industry-wide FOTA adoption, we at Red Bend are here to assist our customers in making their FOTA updates smaller and faster, ensuring FOTA-friendliness of each new firmware version, and tracking the type and quantity of changes between firmware versions. For more information, please contact your Red Bend account team or email us at inquiry@redbend.com. Labels: firmware, FOTA, mobile software management
The “Short Blanket” Effect – Engineering Challenges in Implementing FOTABy Sharon Peleg Founder and CTO Red Bend Software Updating mobile firmware is not a simple task. Some have compared it to updating software on a PC, but there are in fact many engineering challenges that make updating mobile firmware much more difficult. While the generator running on a PC in the office can practically enjoy no resource limitations, the design of the update process on mobile devices must take into account the lack of any auxiliary data, lack of extra storage to be used as temporary buffers, lack of RAM in some cases and a much weaker CPU. Ineffective approaches could easily lead to conflicts between the various resources, and result in the “short blanket” effect – if you pull it from one side, the other side is left uncovered. When evaluating, testing and integrating FOTA on mobile devices, manufacturers and operators should consider the following: · Speed, accuracy and predictability of update generation · No spare flash memory on the device · Fault tolerance · Size of the delta file and update package · Positive user experience · Updating compressed firmware · Type of flash memory In this blog entry, I will address the first three. Speed, Accuracy and Predictability of Update Generation The update algorithm must be fast enough to generate updates at a reasonable speed and should provide sufficient feedback to allow proper understanding of the behavior of the update process on the device. Another equally important requirement is the need for the update generation to be predictable. It is not only sufficient that the generator will produce a small update when few changes are introduced to the source, it must do so consistently. No Spare Flash Memory on the Device The fact that there is no spare flash memory for building two side-by-side alternating versions when updating the new version (as some embedded devices can afford to have) leaves no option but to perform an update in-place. In-place delta-updating is challenged by limited spare flash and RAM resources to hold the new version. Fault Tolerance When updating firmware on mobile devices, it is crucial to assume that the process could be interrupted at any point in time due to a power failure. Power failure during flash re-programming not only can corrupt the written flash sector but also leave the device in a useless state. In addition to having to be both in-place and fault-tolerant, the process must run at maximum speed to minimize downtime. Fault tolerance requires writing additional data when updating in order to maintain the integrity of the persistent data at any point in time. The challenge here is to minimize writing data in order to minimize the number of re-flash operations. Learn more about implementing FOTA in our new white paper, “Principles of Updating Mobile Firmware Over-the-Air”. Labels: FOTA, mobile, software
Standards Acceleration Is Sign of Growing Market Adoption for Device ManagementBy Elad GranotDirector of Standards and Alliances Red Bend Software Standards play a critical role in emerging technologies in their path towards technical maturity and in their quest for widespread market adoption. Recently I have been reviewing the OMA Device Management enablers with a focus on how the older deliverables of the OMA-DM Working Group differ from the upcoming deliverables being worked today. When examining the evolution of OMA DM papers and working procedures over the past years, I have noticed several positive signs in the development of device management enablers which show the growing market adoption of over-the-air software update services. A number of signs bring me to this conclusion, and the rest of this post will point out these factors. As a background, let’s look briefly at the DM historical milestones: · April 2002 – SyncML Specifications V1.1 are approved by SyncML Initiative. · November 2002 – The SyncML Initiative is merged into OMA · May 2003 – SyncML specs converted to OMA format, creating SyncML Common 1.1.2, Data Synchronization 1.1.2 (DS) and Device Management 1.1.2 (DM) · December 2003 – SyncML-DM 1.1.2 is approved by OMA · November 2004 – SyncML-DM renamed to OMA-DM · Jun 2005 – OMA-DM 1.2 spec reaches Candidate state · July 2006 – OMA-DS 1.2 release is approved by OMA · February 2007 – OMA-DM 1.2 release is approved by OMA Sign #1 – Established Organizational Processes Speed Time to Market In the beginning, the work was relatively slow, mainly because the establishment of OMA organizational processes was happening in parallel with the standardization of DM and Firmware Update Management Object (FUMO). This fact, along with the work that was needed to adapt the outputs of the SyncML Initiative to the overall ‘look and feel’ of OMA outputs, created a challenge for the DM Working Group that resulted in some unavoidable compromise in terms of work quality and timely delivery of the standard. The good news is that these historical constraints no longer affect the current DM Enablers (also known as Management Objects, or MO’s) being worked today in the OMA-DM Working Group. OMA process issues that were not clear in the early days of the organization have been clarified and significantly improved since, allowing faster progress. For example, recently a new type of document template (named Data Specification) was created in OMA to be used for all OMA deliverables for which there are no behavior associated. Some MO’s are perfect candidates for using this template, which will facilitate easier and quicker release of these MO’s by relaxing some of the ‘classic’ time-consuming production steps used for other standard documents which are totally redundant in the context of these Management Objects. OMA is further working on shortening the time to market for new device management technologies and has recently created an ad-hoc group dedicated to investigating and proposing further improvements. Sign #2 – The Success of FUMO 1.0 FUMO 1.0 was the first separate standard MO on top of the DM protocol. It became candidate in mid 2006 and released as an approved enabler, after a successful period of interoperability testing in February 2007. FUMO, which has been proven by extremely high success scores in interoperability fests, is the first DM application that expands OMA-DM beyond simple parameter configuration. This DM enabler is being deployed by leading vendors in the mobile industry, and provides a concrete and live environment from which the DM community can learn which design principles are working best and which concepts can be improved. Sign #3 – More Vendors Participating Leads to More Robust Technology that is More Widely Adopted Players from across the mobile value chain (and recently not only mobile, with the proliferation of OMA into the fixed environment) constantly show high interest and involvement in the DM Working Group, which implies high commitment and strong belief in that work. It also means greater motivation for companies to propose and push their initiatives, which is a vital factor in a contribution-based organization such as OMA. With the formal release of DM 1.2 (and FUMO 1.0) this level of interest is expected to sustain, if not grow. In fact, some ideas have been raised about taking DM beyond the mobile environment, in order to address some of the challenges emerging in the fixed telecom environment. Sign #4 – Expanding Use of the Technology Leads to New Requirements With this increased momentum, it should come as no surprise that there are multiple DM enablers showing nice progress: DiagMon, Scheduling, ConnMO, and DCMO. For example, the Software Component Management Object (SCOMO) Requirements reached Candidate and the Architecture is now being reviewed, while the technical specification also showed significant progress. On top of that, the recent creation of new enablers (such as Lock and Wipe MO) validates the momentum of DM being an acceptable framework for management in the mobile industry. Sign #5 – Care for High Quality, Consistency and Clarity In addition to this progress, the quality of the deliverables also improves as the DM Work Group improves the consistency across architectures of these various enablers. This consistency facilitates greater re-use of concepts, which results in better clarity, improved quality and shorter time for developing the specifications. But as an extra consequential bonus, it also suggests a greater potential for vendors to reuse some common components across their different MO implementations. Furthermore, many contributions proposed for the standard show great care for clarity and simplicity of the specification text, resulting in higher quality and ease of implementation. Summary In summary, the future of DM standardization appears to be positive. It builds on the strong foundation of standards created since 2002. With recent improvements to the process and organization around OMA, I believe the momentum surrounding DM and the various Management Objects will continue. Since OMA is a market-driven (and moreover, a contribution-driven) organization, the acceleration of the standards process is a strong indication that the business of DM is also taking off. Labels: device management, DM, FOTA, OMA, standards
|
|
|
 |
|
|
|
Copyright ® 2008 Red Bend All Rights Reserved.
Home | Solutions | Customers | Partners | Company | Terms | Contact Us | Site Map |