The future for wireless entertainment certainly looks bright. Yet it appears that worldwide network operators have spent too long promoting new technology for its own sake. This includes technologies like 2.5G or GPRS. As a result, these operators have not found a way to help cell-phone users understand what they can do with new technologies. Now, handset manufacturers and network operators have to work harder to develop and promote exciting services that will encourage mobile-phone users to upgrade from 2G to 2.5G handsets. It's time to forget the technology and start looking at what can be done with it.

In this environment, the key differentiator between products is in the phone's application space. Here, users increasingly expect user interfaces and performance that resembles what they get from their PDAs or PCs. But they're only prepared to pay mobile-phone prices.

The key applications now driving phone replacement include picture messaging or using the Multimedia Mes-saging Service (MMS) to send photos, icons, and graphics to friends. Perhaps an even more crucial application is mobile gaming. Video streaming is another area that is likely to generate interest this year. All of these applications are becoming standard applications that users expect to find on their handheld devices.

Picture messaging, for example, is currently taking Europe by storm. There are now several camera phones available with more in the pipeline. Consider the Sharp GX10 camera phone. Now available on the Vodafone Live! network in the United Kingdom, it is built on TTPCom's GPRS platform (see figure).

In addition, the Wireless Graphics Engine (WGE) from TTPCom gives the mobile-phone platform the standard of games that users expect to find on a Game-Boy Advance. Device manufacturers licensing this technology include Innostream and LG Electronics of Korea, as well as TCL Mobile of China.

What technology is required to enable these applications? For a moment, consider that delivering a PDA, handheld game, or PC-like gaming experience on a mobile phone requires a significant improvement in the quality of graphics and the speed of execution. The desktop approach is one method being espoused by silicon vendors to deal with these needs. One simply adds hardware graphics acceleration. Though this approach will deliver enhanced graphics, it has a cost in terms of material, design time, and—last but certainly not least—power consumption. Each of these aspects presents significant issues in the current competitive climate.

For applications on current phones, some manufacturers are applying software-graphics-acceleration methods. In doing so, they can avoid the need for additional processor technology. As a result, they enable faster rollout and more cost-competitive products.

Several software-acceleration approaches have been based on improving the graphics performance of Java for game playing through proprietary implementations. Obviously, this is an attractive route to take. Advanced phones already support Java. Increasingly, it's being implemented in mass-market phones. But modifying Java poses compatibility problems for developers, as each new "flavor" of Java requires slightly different game coding.

In addition, the accelerator needs to be delivered with each game for some versions of Java. So if the phone user downloads several games, the accelerator is stored on the handset each of those times. It then eats into valuable memory space. Despite that setback, the standardization of Java in gaming applications is beginning to reduce such compatibility issues. Look at the wide adoption of the MIDP 1.0 and 2.0 application programming interfaces (APIs).

Another alternative does exist. Plat-form acceleration, which is exemplified by the TTPCom WGE, presents an open API. It works to accelerate all of the handset's graphics usage in much the same way as an advanced graphics card would work in a PC. This approach improves game play through faster rendering, smoother translations, and a higher frame rate. It also gives the user the impression of better system performance through an overall improvement in graphics response.

Originally, the WGE was designed to achieve graphics performance on ARM-7-powered mobile phones, which are used in approximately 72% of the handsets in the market. It was meant to be comparable to ARM-7-powered Nin-tendo GameBoy handheld consoles. Early last year, this design goal was validated with the porting of the ITE game, "Hugo and the Evil Mirror," from the GameBoy platform to WGE-enabled equipment.

Most new handsets are now shipping with color screens. In addition, image-intensive services and downloadable games have launched. Obviously, graphics performance is growing increasingly important. This is true across the whole range of phone types—from entry level to fully featured smart phones. Game-like techniques, such as animated icons and picture menus, are now applied to enhance the user interface. Functions like run-time zooming also can be applied across a range of applications.

The MMS implementation from TTPCom is just one example. For faster message processing, it uses the Wireless Graphics Engine to increase the throughput of frames from the video codec to the display. It also provides pan and zoom functions, which let the user view images that are larger than the handset screen size. Real-time user-interface zooming on text and graphics can be applied when the handset is being used with a vehicle mount. This zooming function also can enhance usability for the visually impaired. As the mobile-user base ages, this function will become an increasingly important issue.

To guarantee the broadest possible applicability, the WGE is operating-system- (OS-) agnostic. In other words, the exact same code runs on the embedded real-time operating systems found in basic handsets, as is used on Symbian, Pocket PC, or even Windows machines. Irrespective of the OS, WGE has a memory footprint of 50k of Flash and demands just 5k of RAM. It can therefore be integrated into even the lowest-specification designs.

In addition, the graphics engine dy-namically manages processor requirements by constantly varying its frame rate. It attempts to increase the frame rate until the processor architecture imposes limits. This capability is vital to ensuring that network and call-management functions are not impaired by the graphics-processing demands.