While the most recent "Internet phones" offer improved voice quality, Web access remains fraught with difficulties, many of which are associated with the user interface. On the design side, numerous issues are contributing to the ongoing user problems with handheld wireless access systems. The main issues deal with communications protocols like the Wireless Access Protocol (WAP); the processor and OS; the question of "to browse or not to browse;" and security methodologies.
A common theme is emerging to overcome such difficulties in hardware and software development: "make it architecture- and/or platform-independent." Contributions in this week's section address this growing trend in wireless Web device design.
The new Internet phones have not fulfilled their promise, in part because of their small displays and limited data bandwidth. Third-generation (3G) networks will solve the bandwidth problem, but the small display and small buffer size remain, said Randall Fahey, vice president of marketing for Morphics Technology Inc. (Campbell, Calif.).
Many of these phones are WAP-enabled systems, and WAP is not a platform-independent or portable interface, according to Chris Woodthorpe, Morphics' manager of software architectures. "Instead, you have to rewrite the script every time, because of the way the server talks to the phone: It needs to know what the phone wants in order to know what the command should be."
In addition, many internal interfaces are proprietary. In the Global System for Mobile Communications (GSM) standard, for example, the interface between OSI Layers 1 and 2 is not defined. "So in system design, you end up with lots of the functionality in the wrong place," Woodthorpe said.
At the macroscopic level of development today, a lot of Layer 1 code sits up at the higher layers because of the real-time requirement there. Down at the physical layer, there's a lot of architecturally dependent code, because the fastest way to get a DSP to work is assembly code. "But when you change platforms," Woodthorpe said, "all that work goes out the window. Now there's the intermeshing of upper-layer code, which should be architecturally independent. The further down you go on the stack, the more likely you are to see architectural dependence. So the migration of architecturally independent interfaces tends to occur from the top down," he said.
Standardized interfaces can manage the algorithmic and real-time complexity and make sure that designs are partitioned correctly. That, in turn, can then enable concurrent engineering between system designers and vendors. Morphics, for example, is putting a platform-independent interface into Layer 1, on top of its own platform, so that designers can write architecturally independent software in the upper part of Layer 1, Woodthorpe said.
Standard interfaces can help wireless system developers write architecturally independent software, says Chris Woodthorpe of Morphics Technology.
The trend is to get development into platform-independent modules, which is occurring in both hardware and software, said Ravi Subramanian, Morphics' vice president of systems architecture. "Traditionally, people have built the RF link, or pipe, and then decided what kinds of applications to shove down it, because they've been looking at voice technology as the model and/or driver," he said. "Now, we are trying to determine what kinds of applications we want to overlay on the pipes, and how to engineer the air interface to better match them."
The large-screen Japanese iMode phone, for example, runs on low data rates, but can deliver high quality because it has matched the application to the available pipe. WAP and iMode are mechanisms by which a particular application can be fitted onto a pipe transparently. But currently, neither the applications nor those mechanisms are platform-independent.
Microware Systems Corp. (Des Moines, Iowa) is taking a parallel tack in real-time operating systems (RTOSes) to deal with user interface problems. An RTOS alone is not enough for designers of multimedia Web access systems, said Curt Schwaderer, Microware's director of network technologies. "They need robust system design; a communications framework; a power management framework; and a graphics and multimedia baseline, so manufacturers can have a fighting chance at easily manipulating user displays to tune them for screen size and the type of information access that users want," Schwaderer said.
Handheld Web access systems must communicate over a variety of network topologies and interfaces, said Schwaderer. The way that Infrared Data Association (IRDA) communications was inserted into first-generation handheld systems was by "plopping it on top of the RTOS, which created a spaghetti-like entanglement. To use the same application, but with the latest technology like Bluetooth, you have to unwind the application from the IRDA code."
The communications framework that accompanies Microware's modular OS 9 RTOS formalizes everything into OSI layers, so that an application can be written through a network-independent API--which provides communication interfaces-and underlying technologies can be snapped in and out without disturbing the application. The power management framework functions in a parallel manner.
One of the reasons for the disappointing performance of the latest Internet phones is that expectations were set too high, said David Fell, chief scientist and founder of Ant Ltd. (Cambridge, England). "The expectations of what Wireless Markup Language (WML) could do were unrealistic: It's only at version 1.0. There have been issues in its implementation; sometimes it doesn't work, sometimes there are incompatibilities going through the gateways. But these are very much characteristics of an emerging market, which will be sorted out."
WAP implementations in access systems have been very reliant on the behavior of the WAP gateways, with the result that the technology's behavior is proprietary even though the technology itself isn't, Fell said. But there is a need for platform independence such as Ant's multimode browser, which consists of various components with interfaces at the edge for different markup languages, such as HTML, XML, XHTML and WML.
"The old way of writing for a platform is to include platform-specific calls littered throughout the application," Fell said. "Moving to a new application requires an enormous amount of effort. What's needed is isolation, so that the core application understands, not the platform it's on, but the consistent environment and maps that to the platform. Then, when you move to a new platform, what must be mapped to it is smaller, more defined and easier to do-porting the environment, not the whole application."
In many ways, the application can thus view Ant's Portability Environment (APE), which is an implementation of the company's API, as its OS, Fell said. Systems will thus be able to operate in multiple modes: wired, wireless, through a cell phone network or through a corporate network's HTML-based infrastructure.
The user interface is also important in security implementations, said C.J. Koomen, chairman of Pijnenburg Securalink Inc. (Campbell, Calif.). "It must be extremely simple. Security must be simply an aspect of the system, a quality-of-service (QoS) issue, much like how well your voice is being reproduced. Now that communications and transactions have become so transparent, the need for this QoS is increasing."
To achieve that, security must be approached as a system engineering problem, not just a software effort. "Any configuration with a central CPU and memory, in which the CPU runs both security and other applications, is vulnerable. Security implementations in the handset must thus be implemented in a hardware-based engine separate from the CPU," Koomen said.