Interactive content could lead companies out of the current UMTS predicament. According to research conducted by Forrester Research, consumers in Europe spent some 101 billion Euros on communication via fixed network, mobile phone, and post in 1999. The research also uncovered an interesting fact: New interactively assisted content could produce a host of successful services. Frost & Sullivan ascribe a further lion's share of the revenue to mobile gaming. By 2008, it predicts that 178.8 million mobile gamesters will exist.

Interactive content places highly complex requirements on mobile systems. It involves a combination of flexibility and wide-ranging functionality with minimal memory size, processor, and battery power. Memory protection also is part of the mix. Hardware restrictions have to be offset by means of intelligent software. As a result, the profitable development of mobile communications systems calls for fundamental importance to be assigned to six main requirements.

Before delving into the six requirements, it's important to note that ensuring cost-efficient production can be difficult. Over the long term, however, it does safeguard investments in development. The use of a common basic platform for differing handset models presents an ideal solution (FIG. 1). In the 3G handset, for example, the hardware and software platform will become like the chassis of a car. The same chassis can be used for several types of car models.

In this way, 3G-handset applications can be compared to the features of a car, such as air conditioning, electric moon roof, dual air bags, etc. The 3G mobile phones that are built on one general platform will host different and varying applications. The handset manufacturer will differentiate the devices so that they range from low-end to high-end. That manufacturer will also design handsets for different user profiles.

A 3G platform cannot be exactly the same for all types of terminals. For example, the memory configurations and possibly the CPU extensions are different when comparing a voice-only mobile telephone and a multimedia terminal. For various applications, however, the basic design and architectural versions can be used more than once. A significant potential for savings can be gained by reusing the system software in the various hardware configurations. Such software includes telephone protocols, baseband software, a call control system, and voice coding and decoding.

In general, six requirements exist that must be met in order to obtain successful GPRS/UMTS terminals. These requirements assume the use of a common basic platform. They comprise the following:

Dynamic Program Loading In Real Time
A key feature of 3G is the ability to update the software inside the telephone at any time. This aspect gives manufacturers and end users higher flexibility. The hardware and operating-system platform must therefore support the dynamic loading and unloading of programs in run time (FIG. 2). In addition, the handset must be upgradable at any type of usage by equipping it with different applications. The manufacturer can then update software with new versions at a very late stage in the production cycle—or even after the unit is shipped. For the user, this translates into the ability to get a new phone simply by purchasing new applications to add to the existing factory-installed capabilities. Subsequently, the user's handset can be turned into anything: a phone, a PDA, or perhaps even something not yet imagined. Business-to-business applications also are sure to appear on the market.

Cost Efficient Use Of Memory
Saving memory is probably the most significant cost-saving factor for a 3G handset. To compensate for limited memory, more demand is placed on the handset software. This is particularly true for the platform software. As a result, the operating system itself must be compact, modular, and highly configurable. It should consist of several modules that can be included or excluded, depending on the required functionality.

For example, in the OSE for Wireless Devices operating system, each component's footprint (code only, no data) ranges from 60 to 150 kB. An extensive choice of modules usually results in a system of approximately 700 kB. Each component should offer several configuration options that can scale the component up or down in both functionality and size. The operating system also must consume as little RAM as possible when executing. It can achieve this goal by limiting the use of buffering and advanced memory management, including efficient methods of preventing memory fragmentation. If all operating-system components are able to execute out of either RAM or Flash, costly RAM is saved.

Another mechanism that saves space is shared libraries. This approach allows several applications to run the same code with different data. When implementing shared libraries, keeping the real-time characteristics of an RTOS can become a somewhat complicated process. But in OSE for Wireless Devices, shared libraries can be used without the typical traditional shortcomings, such as longer interrupt latency.

Transparency In Distributed Systems
A 3G terminal is a good example of a typical multiprocessor design in which application programs can run more efficiently. To attain this efficiency, the processor operations are distributed over CPUs and DSPs. With one standardized RTOS that supports both general-purpose CPUs and DSPs, the software can be used repeatedly in different hardware configurations. The same system software, like telephone protocols, works with one or the other microprocessor on both the CPU and DSP at the same time. Or, it works on one DSP. If the RTOS offers a common application programming interface (API) and transparent communication over CPUs, the CPU boundaries become invisible. Applications can then be easily moved from one CPU to another with little to no changes required (FIG. 3).