Software development crucial for multistandard radios

Software development crucial for multistandard radios
As we look into the future of wireless connectivity, software will become an important element that bridges the various wireless standards. It will be the key to creating exactly the network needed to provide the required connectivity. However, when developing software for multistandard radios there are some critical areas that must be considered, several factors that designers need to consider: designing with integration in mind, interoperability, hardware/software co-design and prior experience.

To build a multistandard chip set, it is necessary to start from individual components. While one architecture may be well suited for a particular standard, it may encounter numerous problems when integrating with the other standards. From a user's perspective, integration typically implies having two standards running concurrently. Integrated designs are more difficult to achieve than combination designs, which put a few standards onto one device; however, only one of them works as selected by users.

As a result, it is very important to adopt an architecture that leaves hooks for other standards. Although it sometimes means more overhead for one application, the time and cost saved during future integration periods will well justify the efforts invested up front.

A good example of the mentality of designing to integrate is the Wireless Internet Networks project, known as WINE, sponsored by the European Commission under the framework V Information Society Technologies program. By looking at Internet Protocol (IP) as a pivoting point for all of these wireless standards, an additional wireless adaptation layer (WAL) can be introduced between the IP and the bottom two layers, multiple access and physical. The WAL adapts its behavior according to the higher layer's requirements and the lower layer's channel condition. It also provides a uniform interface to the IP.

At the high level, the WAL provides an architecture for different wireless standards to integrate and communicate with each other. Additional differentiating features, such as the bridging function, can be added within this layer. With the introduction of Bluetooth Network Encapsulation Protocol in the Bluetooth Personal Area Network Profile, which provides a clear interface between Bluetooth and IP, the WAL concept has become a very interesting part of the architecture.

Consider devices with both Bluetooth and 802.11 wireless connectivity technology. At any given environment, we could encounter several 802.11 and Bluetooth devices, just a few devices or perhaps just one. Depending on the availability of the link, different services and applications should be provided accordingly. For example, a phone call can be routed using a GSM/CDMA network or VoIP network — using 802.11 or Bluetooth. The choice of routing depends on the cost as well as the achievable quality of the call. To attain this kind of functionality, software running on the device has to become intelligent enough to interpret the environment dynamically along with the needs of the application.

The software solutions operate mainly at Layer 2 — referred to in IEEE terms as the multiple access layer — and Layer 3 of the architecture. Layer 2 helps in coexistence solutions by providing a more fine control on the medium access, while Layer 3 provides the intelligence needed for interoperability and other user-friendly features. Some interoperability requirements will even go beyond Layer 3 at times.

The challenge of hardware and software co-design is not new. Co-design becomes even more challenging when building a multistandard chip set: one that costs significantly less than the sum of individual chips. This is achieved by intelligently reusing the same hardware.

It is often believed that the process to design a multistandard chip set does not typically begin until the completion of individual standard chip sets. However, this may not always be true. Take the recent 802.11g standard. Companies interested in developing chip sets using 802.11g are moving directly to this new standard. Also, most people are designing 802.11a and "b" combination chip sets, instead of building a standalone 802.11a solution, since the hardware technology has advanced by one to two years. For example, IC process technology has become smaller in size and CPU technology has become more advanced. As a result, some of the computation-intensive functions can be ported to the hardware if flexibility is no longer an issue for these functions. However, the software should have taken this into account so that these functions could be easily decoupled from the rest of the code without a major overhaul.

Experience implementing each of the standards is the most valuable asset. It is difficult to translate the specifications into the number of million instructions per second, or Mips, initially. But with software running, it is now possible to measure the dynamics of CPU activities, not only for the purpose of the next-generation product, but also for gaining knowledge on integration.

For instance, it is possible to have one CPU run all the software if some of the functions can be started earlier or later. A small hardware accelerator can be added if there is no way to move around these functions. Another possibility is to partition the software into time-critical and nontime-critical pieces. While detailed partition is difficult with only specifications, it is quite feasible now with implemented software. If a host processor exists and still has Mips left, the nontime-critical software can be moved up to accommodate other standards' software.

All these options are impossible without experience on the implementations of individual standards. Fully utilizing what exists within the organization can give a competitive edge over other products.

If an individual standard is regarded as being implemented vertically, integrating multiple standards will be like adding them in parallel. While the knowledge on the vertical axis has been explored extensively, it is also crucial to investigate various issues horizontally.

Take the example of the adaptive frequency hopping for Bluetooth being considered in IEEE 802.15.2. Because both Bluetooth and 802.11b are operating in the same 2.4-GHz ISM band, they are interfering with each other. The frequency hopping modulation scheme of Bluetooth has inadvertently caused more problems to 802.11b, which uses the direct sequence modulation scheme. Although theoretically both are considered spread spectrum technologies, which should coexist without any problems, frequency hopping signals, unfortunately, saturate the RF front-end of the DS receiver, which cripples the following demodulation circuits. To solve this problem, Bluetooth can horizontally retrieve frequency information from the 802.11b side, so it can adapt the hopping pattern around the DS signal. Both links can then operate at the same level.