DESIGN ISSUES
Obviously, location technologies in the U.S. are varied and available only on a limited basis. It is therefore difficult to design a device that will work in all situations. Yet these issues are only part of the problem. According to James Kind, Director of the North American LBS Division for MapInfo Corp. (www.mapinfo.com), the capabilities of the carrier's network are the biggest barrier to LBS. As he puts it, "Many carriers can only locate a user to a cell or general location level."

The network cannot tell if the device user is at the edge of a cell sector or right in the center. This can lead to position errors of up to 300 m. Say, for example, that a user is trying to locate the nearest cash machine. If the network can only locate that user within a 150-to-300-m area, the result will at best be unpleasant.

To work around the problem of limited network capabilities, the solution may be to ask for more from the user. MapInfo's LBS platform allows the user to refine his or her location based on nearby points of interest. It also presents the user with a number of street intersections that are known to be in the user's current cell. The user can then pick the intersection that is closest to his or her current location. James Kind explains that with a little ingenuity, LBS applications can still be designed in the absence of robust location technologies.

What about the device side of the LBS equation? Like any mobile wireless technology, successful LBS devices must adhere to the constraints of decreasing size and minimal power consumption. At the same time, they must maintain high performance. At a chip level, these demands are typically met by tightly integrating the front-end receiver functions.

Consider SiGe Semiconductor's (www.sige.com) SE4100 GPS RF chip (FIG. 2). To reduce the external component count, it integrates the IF filters, low-noise amplifier (LNA), voltage-controlled oscillator (VCO), phase-locked loop (PLL), and crystal oscillator. Such integration also results in cost and power-consumption advantages.

When it is combined with the appropriate software, the SE4100 GPS RF chip can support A-GPS applications. The position-determination performance is then greatly improved. In fact, the transmitting handset's time-to-first-fix (TTFF) can be reduced from 0.1 to 2 sec. over GPS-only systems.

Qualcomm's (www.qualcomm.com) gpsOne also takes the tight-integration approach. This architecture uses an integrated wireless baseband and RF front-end with GPS capabilities. The gpsOne-enabled Mobile Station Modem (MSM) chip set is essentially an integrated CDMA-based tracking-service module. Clearly, it is well suited to assisted-GPS applications.

GPS-based systems run into performance problems when it comes to signal sensitivity, however. Most of today's GPS-based position technologies don't work well in geographic areas with dense foliage or urban barriers, such as covered parking garages. To improve this sensitivity, one solution uses a combination of hardware and software components. Through the embedded use of SiRF's (www.sirf.com) Xtrac high-sensitivity global-positioning-system software, HOLUX's (www.holux.com) GM-270 Ultra GPS receiver has been able to greatly extend its operating range. This capability was achieved through software enhancements, such as changes to the signal-tracking loops. Other advances included techniques that were designed to increase the dynamic operating range.

Although performance problems may be tamed by existing solutions, LBS designers still face at least one major obstacle in the sheer variety of location-based services technologies. According to a statement made by Nikhil Deshpande, PhD, Intel's (www.intel.com) Technical Marketing Manager for the Emerging Platform Lab, "Each application developer must understand the various location technologies and 'wire' the application directly to the specific location technology used by the device."

In addition, each device may have its own special way of accessing the position data. The large variety of technologies also must be taken into account. Cellular triangulation, for example, uses E-OTD, GPS, A-GPS, and WLAN. When this diversity combines with the technologies' attendant performance issues, it becomes clear that there is no single best answer for a position-location system.

Researchers, such as Intel's Nikhil Deshpande, suspect that the best way to provide accurate and meaningful location-based services is through the simultaneous support of these multiple position-location technologies. A user's device may then rely on a GPS receiver while outside a building. Once inside, the same device may access a WLAN interface to supply location information.

Of course, supporting multiple LBS technologies means that developers must write applications on top of low-level priority interfaces. Such interfaces are specific to a particular technology. To read raw and proprietary-formatted location data from the device, for instance, GPS application developers often use a serial-communication-port application programming interface (API). For the developer, this approach is time-consuming and costly. It is analogous to the early days of PC-bus-card design.

According to Intel, a better way to deal with this issue is with the Universal Location Framework (ULF). In this framework, the sensor layer consists of location-sensing hardware and software drives for detecting raw data (FIG. 3). Further up, the measurement layer provides the necessary algorithms to convert the raw sensor data into location measurements. At this point, the fusion layer continually merges streams of measurement data into a single position estimate. This estimation data is then available to various applications via the ULF API. Prototype implementations of this API have already been done in Java.

No matter what approach is taken, it is essential that the API is standardized for the community of LBS developers. The Java Community Process (JCP), which is an open organization of international Java developers and licensees, is creating such a standard. The JSR 179 Location API for the J2ME specification defines an optional package. It will enable developers to write mobile location-based applications for resource-limited devices (www.jcp.org/en/jsr/detail?id=179).

Aside from the technical issues, several social concerns must be addressed before consumers fully embrace LBS technology. For many potential users, security remains a big issue. AT&T Wireless (www.attwireless.com), which is currently the major LBS provider in the U.S., uses a simple but effective security scheme in its "Find Friends" application. Not surprisingly, it is based on security services that have proven so successful in text-messaging applications. According to Danielle Perry, a spokesperson for AT&T Wireless, permission must be obtained before any position-location information is exchanged between friends. In addition, an LBS-enabled user can become temporarily invisible to all other users. Lastly, the same user can "dump" a friend just like in real life.

U.S. wireless companies are just beginning to realize the potential of location-based services. The telecom industry's struggles are finally giving way to renewed interest in potential revenue streams like location-based services. As a result, the future should be rich with position-aware devices and a host of useful LBS applications.