WAP Based Location Services

Slim Souissi and Garland Phillips

Motorola

The present contribution outlines location services from an end-to-end system perspective. It classifies services into three different classes based on requirements and functionality. The paper suggests that an open, flexible, and extensible architecture be used in order to support all classes of location services.

The purpose of the present document is to provide guidance on how to architect end-to-end location services in a WAP environment. Location services are classified into three different classes. Each class includes a set of services which share the same requirements and have the same functionality.

AGPS:   Assisted Global Positioning System

EOTD:   Enhanced Observed Time Difference

MS:         Mobile subscriber

TOA: Time of arrival

WAP:     Wireless application protocol

W3C: World wide web consortium

Location services provide content information to the end user based on the geographic location of the mobile station (MS). Many location services share the same features, requirements, and functionality. Therefore they can be grouped into classes. A class of service is defined as a set of services that can be implemented based on the same requirements and message flow. For example a child locator service, an asset locator service, or a stolen vehicle recovery service generally belong to the same class. Once the carrier implements a single service from a given class, the entire class is enabled.

There are mainly three classes of service that need to be supported by WAP. Table 1 shows the classification of the most popular location services.

Table 1. Location services classification

Class 1: Positioning or self location search: "Here I am"

The mobile subscriber (MS) locates itself first and requests the content server to send him information that relates to his position. During the location phase, the mobile subscriber may have its position locally available or may ask the network for assistance.

Class 2: Tracking on demand and continuous tracking

Two use cases should be considered for this class:

· Tracking on demand: "Where is he?"

An authorized application tracks the MS. The location request goes to the MS. The MS determines its location by whatever means is supported and reports this information back to the requestor. A WAP gateway simply performs transformations and does not need to know that location information is being passed through the system.

· Continuous tracking: " Where is he? …Where is he? …Where is he?"

The content server requests the device to return its position continuously. The time interval between consecutive location fixes may be specified by the server. The content server may send a command to the device to request a pause or the termination of the continuous tracking mode.

Class 3: Registration or self location report: "He is here"

The mobile subscriber receives pushed information based on the area where it is located. Typically the area is predefined by the Internet application. For example, it may be desirable to push advertisements to devices which are inside the shopping mall.

Going back to the previous section, it is clear that for a given class of service, the message flow chart depends on who owns the location information and who asks for it. In this section we try to answer the question about who owns the location information.

It is anticipated that the location information will reside either at the mobile station (example: autonomous GPS technology) or at the wireless network side (example: TOA, AGPS, E-OTD technologies). In most situations, the network operator owns the location information and therefore has the authority to put restrictions on its usage. Some operators may not allow third party services to access the location information. They will exclusively support location services on their own network (active operators). Other operators may opt to make the location information accessible to third party service providers, thus promoting an open client-server architecture (passive carrier). It is important that WAP architecture supports both active and passive use cases.

Table 2 below lists the owner of the location information for different location finding technologies.

(· : Owner, [] Virtual owner: someone who may have access permission from the owner)

It is important that the location standardization efforts which are currently taking place within the WAP Forum and the W3C support the following architectural aspects:

· Privacy and security of the information: Provide means to ensure that location information is not divulged to a third party without authorization.

· Openness and flexibility of the architecture

· Extensibility of the architecture

The intention of the present paper is to provide guidance on how to support location services in a WAP environment. The paper shows that location services can be grouped into three different classes. Flow charts were used to show possible message flows for each category. It is recommended that the architecture be open, flexible and extensible and that the security and the privacy of the location information is guaranteed across the network.