LBS is a complicated technology. Take a look at the ins and outs, from locating a wireless user, to the importance of overlaying this information with local street and landmark data, to the actual point where a person's location shows up on a computer screen with directions.

The terminology for location-based services (LBS) is like most fields - foreign and filled with acronyms. Nonetheless, conceptually, location-based services are easy to understand. Essentially they involve variations of where am I, what is around me, and how do I get there (see Figure 1). The "I," of course, can be another person, an object, or even an event.

Locating a Wireless User
Location identification is a great convenience for cellphone users and is being addressed in a number of ways. For an LBS application to be most useful, the mobile carrier or the device needs to provide location information to the application. Including a "where am I" feature for cellphone users can be handled in a number of ways, with varying degrees of accuracy (www.wmrc.com/businessbriefing/pdf/wireless_2003/reference/ref14.pdf).

Today, not all wireless carriers provide a means of location to the handset. In cases where location is not provided, and for many LBS applications, users need to locate themselves by picking from a list of predefined locations or a set of landmarks in an area. This may be beneficial if users know where they are going before they use the service or if they can find landmarks or streets once in an area; however, it does limit the number of useful LBS applications. One thing that eliminates the need for wireless carriers to provide a location is if the user enters an address or street intersection. However, if a mobile device does not have a full keypad or some form of easy entry, this data entry can be tedious. It is possible to have the LBS application assist in the entry by providing lists of cities, then major streets, and then minor streets.

Hardware receiver costs have decreased to the point where the use of the global positioning system (GPS) is becoming common for LBS. GPS involves three or more satellites and the concept of triangulation (www.watleo.uwaterloo.ca/~piwowar/Think/GPSPrimer.html). GPS units have been used for outdoor wilderness activities for a number of years, and are becoming increasingly sophisticated with fairly detailed maps. In-vehicle navigational systems that use GPS are also quite commonplace and helpful for drivers in unfamiliar locations. A number of cellphone manufacturers are including GPS chip sets in their handsets, making it possible to get a location from the handset without any assistance from the carrier. However, keeping the GPS turned on for an accurate and quick determination of location is a drain on the battery. To get around this, carriers are determining location by providing an initial location using cell tower/antenna information.

The simplest way for carriers to pinpoint location information is to return the location of the cell antenna that's handling the mobile call as the user's position. In rural areas this may be inaccurate by many miles, but in a dense urban area where cell towers are used to hold the antennae, accuracy rates improve to a within a few city blocks. This accuracy can be fine for some simple LBS applications such as weather or local events. When even greater accuracy is necessary, knowing the cell antennae coverage areas allows the LBS application to provide lists of landmarks or street intersection information (or highway exit information) to refine a position.

The United States (U.S.) FCC e911 mandate requires the location of a handset within 50-100 meters in most cases (www.fcc.gov/911/enhanced/). Many articles and presentations are available on these selections at www.technocom-wire less.com/pdf/COMDEX_Fall2001.pdf. For U.S. carriers, the enhanced observed time difference (E-OTD) and assisted global positioning system (A-GPS) are the preferred choices. Both require assistance from the handset and have different performance characteristics. For example, A-GPS generally works better in rural areas since buildings make it difficult to get a line of sight for satellites, while E-OTD generally works better in urban areas since it relies on the antenna/cell tower. Unfortunately, accuracy issues have resulted in a move to uplink time difference of arrival (U-TDOA). U-TDOA does provide the accuracy necessary for the FCC mandate network-only system (www.wmrc.com/businessbriefing/pdf/wireless_2003/reference/ref14.pdf).

Meeting the e911 mandate has been a technical challenge. In many cases, the problem is taking longer to solve than expected due to accuracy and cost issues and regulatory compliance. A-GPS uses triangulation and will not work with legacy handsets, whereas U-TDOA does. The capital outlay of A-GPS, though, is much different from the initial cost of a network solution. A network solution is capital intensive. However, until recently GSM/GPRS systems had to go the network path. Current advances in A-GPS, though, seem to offer additional choices for GSM.

Europe lacks an e911 mandate, so an enhanced cell ID approach is being discussed to improve the LBS experience. It will not be surprising, however, to see U-TDOA used heavily for LBS in various parts of the world where LBS is seen as critical for an increase in data volume, a reduction in "ARPU", or where there are other expectations of heavy adoption. Where adoption is seen as less aggressive and assuming, A-GPS will be available for GSM and become an acceptable path.

Using Location for e911
The e911 mandate in the U.S. is based on providing safety for mobile phone users. A landline phone and associated number tends to have a fixed location, so when a 911 call originates from the phone, the address of the caller is known (although this doesn't address what can happen with a phone number "moving" with a user - number portability). For the mobile user, an "emergency location" without any mobile location technology may well be a billing address; hardly where you want help sent in most emergencies. Even with cell tower/antenna information, a location may be several miles away.

A 911 call in the U.S. involving mobile location technology is routed to a public safety answering point (PSAP) depending on the network infrastructure: CDMA, TDMA, AMPS, or GSM. In mobile cases, the location information that comes from a position determination entity (PDE) or a mobile location center (MLC) does a location query to determine which PSAP is used for the call. PSAP boundaries are irregular, so determining which PSAP to direct the call to is a "point in polygon" type of request whereby the location of the caller as expressed as a location on the Earth is compared to the service boundaries of each PSAP.

LBS software that uses the mobile network to obtain a location of the device will use a software call specific to the infrastructure manufacturer. Many standardization efforts are under way at the Open Mobile Alliance (OMA, www.openmobilealliance.org/) and the Open GIS Organization (www.opengis.org). Suffice it to say, LBS software can get a location from the network. Of course, many complicated issues such as privacy and roaming of location are a large part of the OMA standardization efforts. These revolve around a user's privacy rights and what happens to the user's location when he roams to another carrier's area.

Overlaying with Landmark and Local Street Data
A good geospatial toolbox will not only scale and handle large numbers of concurrent users as well as fit into the requirements of the IT organization, but will also have dozens of location-based operations and handle many different countries. The main operations used in several LBS applications are geocoding, where an address is turned into a location expressed as coordinates (Earth location); reverse geocoding, where a location is turned into a postal address or part of a postal address; routing, where directions of how to get from one location to another are provided; directory service (like location-relevant yellow pages), where some asset or person nearby is located; and mapping, where a map of the area of interest is displayed.

These basic operations depend on street data and landmark or points of interest (POI) data. Several of the location operations are derivatives of the street data. Geocoding and reverse geocoding for the United States and several other countries use sophisticated matching and interpolation algorithms to determine location or address information derived from local street data. Maps use local street data. Routing uses enhanced street data to determine the directions from one location to another.

It is possible to use data from multiple sources; however, unless effort has been taken to ensure the data matches, there will be errors in the LBS applications. You could end up geocoding the right address on a street, but placing the location on the wrong street in the map if different sources of street-based data are used for geocoding. This is not often a problem since major LBS providers ensure that data generally matches or is from the same data source within a country. Provided the data is updated frequently to include new streets and addresses, the results from this should match. There are differences in the quality of the more sophisticated location operations, such as geocoding, and not all vendors have the most current data. If the LBS application is to address an international market (the case for many large global corporations using LBS), then only the global location-based companies that have access to international data will provide a consistent experience for the user.

POI and landmark data can include consumer types of data such as restaurants, museums, and ATMs, as well as commercial data such as warehouses, offices, and customers. To ensure an excellent consumer LBS user experience, this type of data must be current. Users do not like to visit a closed restaurant. Commercial users of LBS will generally have control over the POI data they include, so the data should be current.

Presentation of the Data on a Computer Screen
The success of LBS not only requires that mobile location information fit well with the applications being built, but also that users aren't required to spend much time or effort using LBS applications. The end-user experience starts with a reasonable beginning location. Of course, if the user is only concerned with the weather forecast for the remainder of the day, this is not too demanding. Excessive effort or time is relevant to the utility of the application and, in part, its presentation. Screen sizes are small on many mobile devices, so the presentation needs to be suitable for the display device. Interactions have to be linear for voice presentations and not assume users will remember the lists of choices. If care is taken, LBS applications will be successful.

The LBS Street Guide Application
The following example shows the steps necessary to effectively use the application. The LBS application is a street guide that allows users to find things around their current location. It's pretty basic, but it works well and the displays are easy to read and use.

First a location is determined. In this example the user needs to refine her location from a list of streets in the immediate area (see Figure 2). Once a more specific location is available, then points of interest in the immediate area are available. This is locally specific and varies depending on the user's location. It may also be culturally or country specific with the user able to provide preferences. Once a POI is selected (see Figure 3), then the user may wish to get more details or directions on how to reach her destination (see Figures 4–9). An actual device is shown in Figure 10. The screen is relatively small here, so it is important to ensure that the presentation is appropriate for the display. In this case, considerable effort went into using metadata to ensure the display was readable with just enough detail to be useful.

LBS applications help users who need to know where they (or their assets) are, what is around them (or it), how to get to their destination, and provide a return on.