|
ENGLISH
日本語 中文 한국어 |
CUSTOMER SUPPORT
SITE MAP |
![]() |
|
|
Will Mobile Operators Face a Capacity Crunch Soon?By Richard KinderVP of Technology and New Business for Europe Red Bend Software Mobile data has finally arrived. After years of hype, the volume of data on mobile networks is reported to have surpassed that of voice traffic. Whilst the majority of this traffic is driven by people with mobile broadband subscriptions, undoubtedly the new breed of data-intensive mobile devices contributes significantly to this rapid growth. This bandwidth consumption is stressing the edge of the network and backhaul, resulting in a potential field day for providers of optical and microwave infrastructure. I could successfully argue that the capacity crunch is already upon us. A frequently cited answer to congestion problems is to off-load mobile data from the mobile core network. Various techniques may be deployed to achieve this, such as WiFi or Femtocell offload. For the best results, both approaches rely on mobile devices being aware of their network context and acting accordingly. Unfortunately, the majority of handset software platforms have yet to acquire the necessary smarts to make best use of these whilst staying within the strict energy budgets imposed by today’s battery technologies. We should not forget that bandwidth usage is only one metric by which to measure mobile network capacity. As has been highlighted in numerous articles, blogs and elsewhere during and since Mobile World Congress 2010, today’s mobile devices also impose a greater signalling burden on the mobile network. Whilst I am yet to receive a clear explanation of exactly what signalling traffic is generated, one can hypothesise that the desire to preserve battery life results in these devices frequently establishing and tearing down PDP contexts, which in turn creates signalling traffic within the operator’s infrastructure. So what can the industry do about this? 4G standards such as LTE and WiMAX eventually will allow for future growth in mobile data usage – the key word being future! Prior to the halcyon days and unlimited bandwidth of 4G, network operators are committing significant amounts of money to enhancing their existing 3G infrastructure. As developers of device software, we too have a role to play, for example:
We cannot rely solely on network operators’ investments in infrastructure to address the capacity crunch. We have a responsibility to use what they provide as efficiently as possible. Services and platforms that can help operators manage their capacity concerns just may be more appealing to them. To misquote Scott McNealy (he of “the-network-is-the-computer fame”), one day datatone will be as important as dialtone. That day is here. Labels: 3G, bandwidth, LTE, mobile, mobile broadband, mobile data, mobile networks, mobile operators, mobile software management, mobile world congress, Red Bend Software, software, standards, WiFi, WiMAX
Apple Changes the Rules (again)…By Richard KinderVP, Technology Red Bend Software Another day, another business model innovation from Apple. Having shaken up the mobile world with a reported strategy of taking a cut of ARPU generated by iPhone users, Apple is now monetizing its software assets in other device types.
Not only would these improvements benefit the user experience, but making updates available more frequently and more conveniently (when not at home, for example) could help to drive the attach rate up and generate Apple additional revenues from device software. Labels: Apple, Google, iMac, iPod, iPod Touch, software
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
|
![]() |
|
Copyright ® 2010 Red Bend All Rights Reserved.
Home | Solutions | Customers | Partners | Company | Terms | Contact Us | Site Map |