21 November 2006 Multitasking Java Is Multitasking JavaTM the Key to Increasing Data Service Revenue and 3G Adoption? Chris Porthouse, ARM Consumer demand for data services such as email, instant messaging (IM) and music downloads is growing, with numerous email and instant messaging clients available, plus a range of mobile phones that support music downloads. However, there is general concern in the mobile industry that major network operators are still not seeing the returns from advanced data services to balance their investment into 3G networks. Many data services are equally applicable to 2.5G networks as they are to 3G networks: they simply require a high-speed download link. However, the complexity in using these applications on a typical 2.5G feature phone is woeful when compared to a 3G handset running Symbian OS or similar. The question is - will users really buy into 3G services when the current offering for data services on 2.5G mobile phones is generally so poor? However, if data services can be made to run well on feature phones, then operators may not only increase revenue from 2.5G networks, they may also seed the market for advanced services on 3G. Low Cost Drives Mass Market Adoption
High product cost means that operators face relatively high subsidies for 3G handsets. Yet, according to research company Enders, even in the early 3G adopter base, 70 percent of those with 3G phones have never made use of the 3G value-added services, such as making video calls. Most cite expense and over-complexity of these services. When it comes to 2.5G networks, the situation is no better. According to Strategy Analytics, over 80% of handsets in 2006 will be capable of using high speed data services on 2.5G or 3G networks . So, how can low-cost feature phones be enhanced for high speed data services, while also reducing the BOM cost? Providing low-cost software support for multitasking is fundamental to creating a useable handset for data services, allowing so-called background applications such as email and instant messaging to run at the same time as a game and normal voice functionality. An open OS solution supports multitasking applications extremely well, but at a price, typically adding about $5 in royalty payment to the BOM. With a software platform BOM close to a dollar, one obvious alternative is Java™. What’s more, there are some 4.5 million Java developers and more than a billion phones currently using Java for games and other applications. However, most Java-enabled feature phones today are at a distinct disadvantage when it comes to the usability of high speed data services. To see why, let’s take the simple example of a user checking email on an open OS phone and on a typical Java phone: on the open OS device, the user simply launches the email client, is able to read and respond to emails, then let the client sit in the background polling occasionally for new mails while the user does other things with the handset. Currently, on most Java phones, the JVM (Java Virtual Machine) is started and the email application is loaded and run. When the user wants to switch to a new application, the email application is exited and the JVM is shut down before the process is started again. This slow serial process is at odds with applications such as IM or email, which are naturally ‘always on’ so they can poll the server for any updates.
Proprietary Multi-tasking Solutions Increase Java fragmentation And Platform Cost
There is a trend with major handset vendors towards the development of a software platform framework that allows components such as the JVM and associated APIs for graphics, Bluetooth etc. to be easily swapped and replaced. This helps drive down pricing by increasing competition among software vendors as well as enabling in-house development where this makes commercial sense. While logical for the top 4 or 5 handset vendors in the world, the strategies of lower volume vendors, design houses and niche market suppliers is often different. Here the approach is frequently for a “one-stop-shop” supplier of multiple components, such as a complete Java stack form a 3rd party software vendor. Fragmentation of the Java platform on mobile devices is well documented, and the industry is making efforts through standardisation and the Mobile Services Architecture to resolve this. Unfortunately, for multi-tasking virtual machines (MVM) this situation may be about to get a whole lot worse: the standard for MVM is contained within MIDP 3.0 which is still some way from completion, yet all the major mobile phone vendors are expected to deploy a version of MVM ahead of this standard. In the context of multi-tasking Java, the result is multiple proprietary implementations of MVM available from multiple independent software vendors. Handset vendors who may be happy with their existing in-house developed Java platform may be forced to adopt an external proprietary solution or invest in potentially significant engineering work if they are going to move to MVM. This fragmentation and increased lock-in to proprietary solutions can only increase costs for handset vendors, and so increase operator subsidies or pricing to the consumer.
ARM MVM Solution – A Non-proprietary Approach
Clearly, an MVM approach that forces a handset manufacturer to adopt a whole new proprietary stack will not satisfy their key need for reduced costs through evolution of their existing Java platform or a componentized software framework; rather it actually increases fragmentation and cost. The ARM multitasking Java solution is based on the provision of an API between the JVM and the upper Java stack (MIDP 2.0 and other JSRs). The API is highly configurable and enables the deployment of multiple MVM upper stacks in a non-proprietary way, reducing platform fragmentation. This is a unique approach and fully supports the handset vendors' need to evolve their existing JVMs to enable MVM, while enabling deployment of the upper stack components of their choice – developed in-house or from independent software vendors. Effectively it adds MVM support as a feature to a JVM, rather than requiring wholesale change, which means that handset vendors avoid having to adopt a whole new custom-built stack. The ARM MVM also delivers a number of advanced features to support the multitasking needs of network operators and the handset consumers to whom they deliver the new data services. The VM use model will change with the arrival of MVM-enabled handsets. Instead of the JVM starting up when the user plays a game or invokes some other Java application, the MVM will start up when the phone is switched on and then run continuously, transparent to the user. Because of this, the MVM must be capable of 24/7 usage. The ARM solution includes advanced features for memory management to ensure that long-term application performance is maintained. In addition, ARM MVM software makes full use of Jazelle® technology hardware acceleration for Java, providing high performance and fast application switching times within a very low memory and power budget – reducing costs and increasing battery life. There is a major un-tapped market for high speed data services on lower cost feature phones that could increase operator revenue while also leading consumers towards future 3G handsets and more advanced data services. For Java to succeed in supporting these data services a low cost, fast and efficient multitasking virtual machine (MVM) environment is required. This will enable handset vendors to deploy compelling new data applications on their handsets at a low price-point, while increasing data traffic and hence revenue per user on existing 2.5G networks. The ARM MVM solution will ship in mobile handsets from multiple vendors worldwide from 4th quarter 2006.
| 
