[For a copy of this article in PDF format, which displays figures and equations, click here. Requires Adobe Acrobat Reader, free download.]

Location and mobility are the defining characteristics of a cellular phone or personal digital assistant (PDA). Yet initial wireless Internet applications have not taken advantage of location as a form of content or service triggering.

Location-based services (LBS), however, are now beginning to emerge as one of the most exciting topics in mobile communications. Such services are based on a software platform that uses the geophysical location of the mobile unit (MU) as part of its algorithm for generating presentation content.

Location has been a critical component of network and transport layer protocols for many years. Cellular networks have long struggled to provide continuous connectivity while the MU moves between cells.

For cellular networks, mobility is a problem that has been overcome through the implementation of cellular handoff and roaming. Mobility also presents a great challenge to Internet applications using terminal connection point (TCP) and Internet protocol (IP). At the network layer, Mobile IP and IPV6 have addressed some routing problems, while others have been tackled by ad-hoc routing protocols such as data set ready (DSR) and ad-hoc on demand distance vector (AODV). At the transport layer, issues associated with TCP error recovery have been identified and patched for the mobile environment.

So, the exploration of mobility is not new to mobile computing, but the practical application of location information to end-user services is a recent innovation. The challenge is to manage, aggregate, access and present this location data to a MU.

The diversity of technologies available for MU location in the United States cannot be understood without briefly covering the Federal Communications Commission's Enhanced 911 (FCC E911) mandate. Because response time to emergency calls to fire and police is critical, the FCC has mandated that carriers implement a technology for locating their wireless customers automatically. Many carriers have complied with the Phase 1 requirements by selecting a technology to meet the FCC mandate. Deployment of the technology will begin this year to meet Phase 2 compliance by October. The E911 mandate makes a distinction between embedded GPS solutions and network-based locating methods. GPS solutions must be accurate to 50 meters, while network-based methods have a less-stringent requirement of 150 meters.

Location-based services are enabled in part by the technologies that physically locate the MU. These technologies can be grouped into two categories: global positioning system (GPS)-based methods and network-based methods. There are several subgroups within each category.

• GPS GPS-based methods use signals generated from 24 government satellites orbiting the earth to determine the position of the MU. Though accurate to a few meters, GPS signals are difficult to receive indoors. Of late, there are commercially available GPS solutions that overcome many of these problems and achieve signal lock quickly even indoors and in urban canyons.

  The main disadvantage to the GPS solution is that it requires the user to purchase a new mobile phone equipped with GPS technology. Many carriers may be averse to this churn because a customer purchasing a new phone is likely to switch carriers.

• Network-based An alternative to GPS employs network-based methods. At a high level, these methods involve triangulating the radio emission of the phone or using RF multipath fingerprinting to identify the most likely position of the radiating source. There appear to be significant performance advantages to the multipath method over triangulation in urban environments. Accuracies of 30 meters are being quoted by major manufacturers of multipath systems, which is well within the 150-meter requirement of the E911 mandate. While less accurate than GPS, and perhaps more expensive for the carrier to integrate, network-based methods work on existing phones. This means a massive locatable user base and reduced churn for the carrier.

First-generation location blind services (LBS), are those that allow users to request information about their physical surroundings. First-generation LBS require users to manually enter their location, (e.g. ZIP code or street address). Because the users are responsible for locating themselves, a first-generation LBS is decoupled from the underlying technology. That is, the LBS does not rely on the network to provide the MU's location. Consequently, first-generation LBS would typically be accessed from a stationary home computer.

Examples of first-generation LBS are MapQuest, CitySearch and other local information services. A mobile form of first-generation LBS would be a service such as that provided by AvantGo, which requires a user to download location-based information prior to arriving at that specific location. When accessed from a MU, the user follows the same steps as when accessed from a stationary PC, though often with more difficulty due to the MU's input device limitations.

Second-generation LBS, (also called location-aware), are services capable of extracting some location information from the underlying network without user entry. For example, ZIP code level or cell sector location information is currently available to developers of Palm OS applications through the Palm Net data network. Second-generation LBS are not accessible from a stationary PC because automatic locating capability is not currently available for the desktop computer.

User initiation of services is a characteristic of second-generation LBS, which operate in pull mode. All LBS deployed today, such as services provided by Vindigo, are second-generation, typically providing mobile-user to static object content (e.g. find the closest theater to the MU).

Third-generation LBS, (also called location-precise services), have the capability to automatically provide or proactively initiate services relative to the precise location of the MU without the user making an explicit input or request. Such a self-initiating service is said to operate in trigger mode. A trigger is a condition arising, in part, from the geophysical location of the MU. The trigger then allows delivery of information to be offered based on the location of that MU.

Trigger-mode services can overcome many of the current problems with mobile applications that include general user aversion to making even a simple request via keypad or stylus. Configuration of trigger-mode services can typically be completed from a traditional Web browser and have the beauty of providing the user with relevant information and services when and where the user needs them without the user having to ask.

To take advantage of the emerging location technologies, applications developers will require access platforms that specifically address the development of location-precise applications and include support for trigger mode services. These platforms will need to be built around a comprehensive, distributed and scalable software architecture based on flexible standards to allow for the rapid, flexible and robust deployment of LBS.

Worldwide, a variety of formats for location information will be produced by mobile positioning centers (MPC) for consumption by authorized external entities. While organizations such as the location interoperability forum (LIF) are working toward the development of standardization, it is expected that in the immediate future, the positioning data formats are likely to be, and will need to be, universally presented. A robust LBS platform will need to support all standards for location data.

The most obvious strategy for obtaining a location document from an MPC is to poll. That is, when the MU requests a LBS, a request is made to the MPC to report the MU's position. This works for pull-mode services that are user-activated. The scenario is more complicated for push-mode services. In push, or trigger mode, the LBS desires constant access to the most recent position of the user.

Polling multiple distributed location servers is not a realistic option for specific reasons. First, the MPC will suffer from flooding, much like a ping attack, as all of its clients attempt to position their user lists as often as possible. Additionally, the position of users is unlikely to be updated regularly in most MPCs. For example, a MPC that relies on RF signals radiated from a mobile phone may be able to position a MU only during an active call, or a system registration event. This makes periodic polling an inefficient solution for trigger mode services. Furthermore, a constant polling will create network congestion and inefficiencies at costs that might not be affordable to adequately deploy LBS. Take, for example, the case of a mere one million users whose location would be updated every five minutes. This simple scenario will require 12 million MU location updates per hour. Scalability will be challenged.

A model that will allow for automatic location information updating without being a function of changes in the users' location will quickly raise privacy concerns. Service providers and applications developers alike will need to ask and answer basic questions: How does an application gain permission to subscribe to a MU's current location? How does the MU control disclosure of the user's position to other users and services?

Several unique and complex solutions to these problems would employ either systems that are configured and controlled by the user of the MU or systems that are triggered by the user. For example, using the accepted Web-based function of user profiles, a developer working from a profile-based software platform could write an application allowing mobile users to customize their profiles to choose when and where location information is to be updated. This functionality allows the platform to perform the monitoring of location-specific data on behalf of the user. The framework is open so that content developers can easily make new local content and services available for user configuration and customization. Another method would be to deploy, for voice-enabled devices, a voice-geocode solution. Using advanced speech recognition, text-to-speech and speech-to-text technologies, a voice-geocode can be engineered to allow users to speak their location information. This ultimate privacy system allows users to benefit from location information when desired without the fear of Big Brother watching.

A detailed example can illustrate the power of location-precise profiled trigger mode services. Consider a Web site that provides local movie listings. The Web site, given a user's current location, would have the capability to list movie theaters nearest to that user, along with current show times for each movie and ticket price.

An application developer could easily create a series of triggers as a function of a user-defined profile. These triggers would leverage the data residing in the database and accessed by users of the services. The user of a MU would be provided with information only when proximate to a movie theater showing a specified movie or movie type within a specified time element. The user would also indicate the form of alert that would be initiated, such as a short message service (SMS) or browser message. Therefore, by defining a profile, a user would protect both the time and location privacy of the MU and filter only information relevant to that user's needs at certain times and in certain locations.

The net effect of the profile is that when the user's MU comes within a certain distance of a movie theater showing the latest requested movie, the MU will be sent a page message, but only if the MU's profile has defined the page as being acceptable.

In many cases, developers of a simple pull- or push-mode application may want to provide a series of value-added services to enrich the experience of the user. Services such as mapping, driving directions, city guides, Yellow Pages, weather forecasts or proximity of other points of interests (ATM, bank, parking, restaurant) may be important considerations to the user of a MU. Therefore, LBS will be driven in part by large volume of localized information maintained by a variety of organizations and distributed over the Internet. As a result, content providers will require a simple way to expose their data to developers and ultimately mobile users. A total end-to-end solution must consider these data components as probable necessities for LBS. Such an application server platform solution must easily offer this rich content via simple protocols that provide remote component access to developers of servlets, java server pages (JSP), common gateway interface (CGI) scripts or even embedded java, by passing necessary documents over hyper text transfer protocol (HTTP).

The inherent particularity of a mobile device is the simple fact of mobility-the ability to constantly move while remaining connected. To maximize the functionalities that can be delivered to a wireless device, enablers will need to adequately manage, in real time, the movement of wireless devices. The real-time database of mobile user locations presents a rich data source to allow for new functionalities for location-precise services, offering what is referred to as mobile-to-mobile and static-to-mobile services. Examples of mobile-to-mobile applications are business networking, a dating service or a mobile game that provides alerts when users come within proximity of each other. Static-to-mobile service is, for example, a retail location that wishes to advertise to mobile users who enter a polygon surrounding that location.

These services will not come without significant technology and innovations. Again, remember that a user base of one million locatable handsets in an urban area whose locations information are updated every five minutes will generate more than 12 million updates per hour. To compound the problem, a single position update may easily trigger multiple queries. This enormous base of perpetually moving data points and perpetual checking of profiles presents a completely new challenge to databases. A common oversight of young location-based enabling services is the failure to take into consideration the challenges represented by moving point data. It should be noted that, without enhancements, current professional database products simply cannot provide adequate update and query times for any large quantity of moving point data.

In order to cope with this computationally complex problem, a limited number of companies have developed proprietary software systems to significantly optimize database products to handle the management of moving point data.

Location-precise services can improve human-machine interaction by increasing the relevance of information served to mobile devices. Over the next 12 to 18 months, organizations with emerging wireless strategies will seek to location-enable their wireless services to provide differentiated proximity-based consumer services. These services will require scalable, robust and deployable location-enabling platforms. Few of these total solutions are currently under development and few have the capabilities to completely handle end-to-end functionalities. Businesses contemplating a location-based service strategy will need to carefully define their strategy. The world of LBS is complex, and choosing the appropriate enabling partner is an integral part of that strategy. The answers to six simple questions will help in the selection process: Do you understand all locating technologies? Do they have the tool set required to develop intelligent location-precise services? Do they have prior experience in live markets (Japan, Korea, Europe)? Is the solution built on an open and scalable architecture? Can they handle mobile-to-mobile queries? And finally, can they deploy applications built around trigger services?

Geoff Hendrey co-founded Gravitate in 1999. Prior to founding Gravitate, Hendrey served as a systems engineer for Trimble Navigation where he developed wireless digital modem hardware for GPS correction receivers. He holds an MS in electrical and computer engineering from Carnegie Mellon Institute of Technology. In addition, he has filed seven patents since July 1999 in m-commerce, mobile-to-mobile and location-precise wireless. He can be reached at: Gravitate Inc. 713 Linden Avenue South San Francisco, CA 94080 P: (650) 873-4373 F: (650) 873-4393 E-mail: geoff@grvt8.com