Moreover, handset designs are far less flexible than they could be. It's almost impossible to modify today's commercial handsets in either hardware or software, to take advantage of features not implemented at the time of design.

Software-defined radio has the opportunity to address these problems. SDR is used to describe wireless handset systems that provide software control of a variety of modulation techniques, band operation, communications security functions, and waveform requirements of current and evolving standards over a broad frequency range. SDR handsets can be dynamically programmed to reconfigure operations for better performance, richer feature sets, new services to the end user and new business for the service provider.

SDR has a 10-year road map, according to the Software-Defined Radio Forum. But so far, the economics of SDR have not been proven for handset designs. The cost of hardware components makes SDR an unattractive near-term alternative to the less expensive but short-lived designs of today.

But as traditional designs become more feature-rich, it may pay to reevaluate SDR as a platform that can deliver competitive value over an extended product lifetime. Part of that reevaluation will include alternative hardware designs, and part will include software infrastructures and architectures.

SDR handsets require an operating system that can be scaled from basic operation to support complex feature sets and interactive applications. The ability to use a single OS across a handset product line, while supporting a wide range of applications reliably, has the potential to make SDR an attractive and cost-effective alternative as advanced designs incorporating 2.5- and third-generation technologies emerge into the market.

The handset is the natural place to locate the SDR logic. This approach enables the handset to perform the required signal conversions on a single voice channel. Building the logic into the basestation, on the other hand, requires setting aside a block of spectrum for each signal and performing the conversion there for the standard the handset supports.

An option to a pure SDR handset is one that is simply multimode. This type of phone is actually hardware defined, since the existing communications protocols are burned into ASICs, but they are software selectable based on the standard used. Such handsets are in existence today, but in limited and special-purpose uses. While a CDMA/AMPS phone is currently feasible, one that supports a multitude of protocols such as CDMA, TDMA, GSM, GPRS and W-CDMA is not so simple, so research and development continue.

Many of the major handset vendors, such as Nokia and Motorola, are starting to see success in integrating multiple radios on a single chip. Qualcomm also has detailed plans to make GSM/CDMA chip sets that will couple their technology with the worldwide GSM community. These advances indicate that SDR is technologically feasible, at least from the hardware side. The next challenge is to determine a software infrastructure that fulfills the promise of SDR in software reliability and application development and use.

Besides software infrastructure, the issue of processing power also looms large. Power management may become an even greater issue when multiple custom chips are used in the hardware design. Alternatively, commercial processors and DSPs have known power consumption and in many cases low-power variants, making it possible to minimize the use of special-purpose chips.

Further, the use of commercial processors enables handset vendors to leverage existing software infrastructures, including the real-time operating system. An RTOS offers some significant advantages over custom-designed operating software. First, it is typically highly stable and has years of proven use in high-reliability systems. It can take a significant amount of time and effort to write system software from scratch that equals the reliability of an RTOS, and the reward for doing so is to maintain and enhance it throughout its useful life.

The common reason for writing a custom software platform is that the commercial RTOS doesn't provide needed features or has too large a footprint. In some cases this used to be true, but many modern RTOSes are modular, with highly customizable features. It's increasingly likely that one or more products will meet the requirements of designers of SDR handsets.

The commercial RTOS can also provide a known platform for software development, with a well-defined application programming interface and tools for software development and debugging. At the very least, engineers can take advantage of high-quality free and open-source compilers and cross-compilers, editors and debuggers that speed the development of reliable applications.

Application developers can also gain the efficiency and reliability of the commercial embedded operating system, which is likely to have a proven record of high reliability in embedded networking systems. Rather than having to depend on a process with less reliability than the embedded system it monitors, this alternative can extend the advantages of the embedded OS to the entire application.

In contrast, custom-designed system software often has poorly defined boundaries between the operating system and applications. Often an application contains elements of both system and user components. These applications have few system services to draw upon, and must either implement low-level routines themselves or in tight integration with the system software.

The result is application software that is closely tied to a specific hardware configuration, a setup seemingly opposed to both the spirit and the promise of SDR design. Further, both the application and its accompanying system software will require a significant engineering effort to reach the level of reliability that's required to be able to ship the handset.

A number of characteristics of an RTOS can support a range of handset applications while improving system reliability and performance. While it may be possible for a wide variety of RTOSes to meet the requirements of SDR handsets, certain characteristics are especially useful for system designers and application developers.

The processing power required of SDR handsets makes it likely that a design would consist of multiple processors for designated purposes, including one or more DSPs for signal processing and conversion. With most RTOSes, the interprocess communications (IPC) between the primary processor and DSP is done with special-purpose mechanisms, such as shared memory spaces, remote procedure calls or pipes. Because these mechanisms are typically added on or customized after the fact, they are not necessarily consistent with the performance and reliability goals of the system as a whole.

Further, many RTOSes use one mechanism for same-processor calls and a second for processor-to-processor calls. This interdependence creates trouble for the handset software developer who needs to embrace both single- and dual-processor architectures. Because the IPC methods for local and distributed communications differ, developers switching architectures need to modify their code to take into account different IPC mechanisms. The interdependence of the processes makes those adjustments both time-consuming and error-prone.

The direct-message-passing RTOS avoids all of these problems. A message-passing RTOS provides a simple-to-use and consistent method of exchanging information among components of a distributed application. These components can be executing on the same processor using separate memory spaces, or on two or more processors. If the message-passing mechanism is consistent, there is no effective limit on the number of processes or processors with such an RTOS.

Instead of creating mailboxes, a sending process in the direct-message-passing RTOS allocates messages from the RTOS' memory manager. The allocating process invariably owns the message and uses its own memory area as needed. To send that message, the process calls the RTOS to submit the message address and identify the destination process. Ownership of the message passes to the destination process when the message is received by that process. Memory protection, error handling and other supervisory activities are all provided by the RTOS itself.

An advantage of this scheme is that message handling is the same whether the processes are on the same or different CPUs. The RTOS transparently copies messages from one memory space to another if needed. The application does not need to take any action, as this is all handled by the RTOS. As a result, processes don't need to know where other processes reside. Whether a system has one CPU or several, the application code isn't affected. As a result, porting code between the two architectural approaches is simple.

Dynamic redirection
Message passing also enables applications to be more easily modularized and distributed. This has the potential to improve the overall software development process through the use of smaller individual software components and separate memory spaces for them. Message passing for an SDR-handset RTOS can also support live software replacement, so that new versions of programs can be loaded onto the system and clients can be redirected to the new instance at any time. Relinking, reloading and rebooting the system are no longer necessary with this feature, enabling the SDR handset to dynamically upload patches, application enhancements and new applications while still in operation.

One operating system that meets many of the requirements for SDR is OSE, a message-passing RTOS with a proven long-term record in telecommunications and wireless applications. Developed by OSE Systems (San Jose, Calif.), the RTOS is based on a message-passing architecture that provides asynchronous interprocess communication and manages to deliver and buffer ownership as messages are passed from process to process.

The operating system includes a full system and software development solution for building and deploying complex, mission-critical embedded systems. It supports dynamic software updates to devices running it. New versions of applications that support new wireless features can be loaded onto the system and clients can be redirected to the new instance at any time.

OSE also has an advanced, built-in error detection system. Should an error be detected, OSE automatically invokes a user-defined error handler. This simple feature replaces the complex code and inconsistencies that often result when programmers handle errors differently throughout the application, if at all. The result is high application performance, while maintaining stability and reliability across the entire system.

Handsets with integrated pro-cessors and DSPs for data conversions can benefit from the fact that OSE and its compact sibling OSEck can be used on both commercial microprocessors and several different DSPs. For dual-processor handsets, OSE implements message passing through the OSE Link Handler.

The Link Handler acts as a high-level supervisor across all nodes of the distributed system. It assures reliable delivery of messages and also monitors the status of running processes. Message passing across CPU and DSP assures high application performance, while maintaining stability and reliability across the device.

Tool backup
The RTOS is not the entire story, however. An RTOS and its associated tools should also support the application development process needed to implement features on the handset. With a powerful tool chain, developing reliable applications that take advantage of the features of the RTOS can be faster and less error-prone than with custom solutions.

An effective development tool chain consists of industry-standard compilers and debuggers, powerful host-target tools and accurate simulators, all supported by a comprehensive integrated development and debugging environment.

Over the next several years, it seems likely that an SDR handset supporting the several major wireless communications standards will be both technologically ready and cost-effective to deploy worldwide. Hardware designs are fleshing out the details of the best approaches, while the SDR Forum and other industry initiatives keep technical activities coordinated.

There is no question that the need is there. Supporting the major standards ensures that handsets can work worldwide, extending life and better supporting customers. And, SDR handsets are better equipped to be enhanced with new applications that can extend their range of features.

The operating platform will play a key role in the development of SDR. Handsets with multimode operation and Internet access using high-speed packet-based data transmission technology require operating systems with extraordinary performance, reliability and flexibility.

Further, reliable and high-performing applications delivering those features to users are a prerequisite of SDR success. The advanced commercial RTOS offers the best opportunity to deliver on those goals, with proven reliability, support for distributed operation and a tool chain for application development.

See related chart