Workshop on Position Dependent Information Services

Phone.com Position Paper

http://www.phone.com

0. Background

Phone.com is a leading provider of software that enables the delivery of Internet-based services to mass-market wireless telephones. Using our software, wireless subscribers have access to Internet-based and corporate intranet-based services, including email, news, stocks, weather, travel and sports. In addition, subscribers have access to telephony services, which may include over-the-air activation, call management, billing history information,pricing plan subscription and voice message management.

Phone.com co-founded the WAP Forum along with Ericsson, Motorola and Nokia. As a member of both the W3C and the WAP Forum, Phone.com worked with the W3C staff to establish formal liaison relations between the two organizations, and has collaborated on a number of W3C input papers and notes regarding the convergence of the WAP™ specifications with other Internet technologies.

1. Workshop Goals

The advent of position information in wireless networks and devices creates exciting opportunities to build new information services that are position dependent (or "location sensitive"). To enable the creation of these services, a standard architecture and a relatively simple set of standard interfaces and protocols must be defined to work across the entire range of mobile web devices, in a variety of use cases and network configurations.

At the Workshop, we would like to reach a common understanding of (and perhaps consensus on) the use cases and requirements for position dependent services, which will allow the attendees to assess proposed methods for position notification and to identify specification initiatives to be undertaken by the W3C and/or the WAP Forum. Specifically, we would like to discuss:

The architectural framework for position dependent services
Identification of system elements necessary to enable position dependent services
Identification of interfaces between those elements
Requirements for each element

Particular attention should be given to:

Privacy requirements
Data transfer mechanisms for the reporting of location information
Overlap with existing industry (e.g. telecommunication) standards

2. Use Cases

Two use cases have been presented to Phone.com repeatedly by service providers and wireless carriers:

Client initiated requests for position-dependent information
In this use case, an end user navigates to a location sensitive service. The end user's location is conveyed to the service and it returns information based on that location. For example, a service might provide the addresses of restaurants closest to the current location.
Network initiated requeusts for the client's current location
In this use case, an application on the network submits a query to the device to report its location. For example, a courier dispatcher might want to locate the courier closest to a high-priority customer.

Privacy considerations are significant and seemingly contradictory:

End user control over location information
The end user's current location is, for the most part, private information. It should not be reported to an information service without approval of the end user. The system should provide a scalable solution to protect the end user's privacy.
Authority access to location information
While the end user should control access to private information, there are situations where an authority must be able to access the location information regardless of end user control. For example, in a courier dispatch application, where mobile devices are actually owned by the dispatch company, it would not be appropriate for employees to override the reporting of their locations.

3. Architectural Framework

3.1. System Elements

The following elements exist in a location dependent services system:

Location: A real-world statement of position. A location can be characterized using a number of different representations, including geodetic systems (latitude/longitude/altitude/...), street addresses, etc. A location may also indicate its accuracy, granularity, rate of change (velocity).
End User: The end user is the person using the mobile device to which the location dependent services are provided.
User Agent: The user agent is software that acts on behalf of the end user as the client of the location dependent service.
Mobile Device: A mobile device hosts some or all of the user agent and can be moved from place to place. The current position of the mobile device may be the basis for the location dependent service.
Proxy Server: A proxy server may exist to enhance or manage the transactions between mobile device and origin server.
Location Server: A location server may exist in the network to provide the location of an end-user or mobile device based on information derived from the network.
Origin Server: The origin server provides the location dependent service to its clients.
Location Source: There are a variety of sources for an end user's location. The mobile device may be able to report its location by accessing it from an internal or external source (e.g., a GPS receiver). A location server in the network may be able to report the location of a mobile device by triangulating on its signal. The mobile device and location server may collaborate to produce the location with the mobile device providing a network-specific position which is mapped into a geodetic location by the location server. The end user may manually select a location to be reported by the user agent.
Location Information Owner: The end user is not always the owner of the location information. For example, some wireless network carriers consider network-specific location information to be confidential. As another example, a dispatch company may provide a mobile device to its employees for the purposes of tracking and routing them. The owner of the information in this case is the dispatch company, not the end user of the device.

3.2. Typical Network Configurations

The following network configurations are typical for providing position dependent services.

Location-Enabled User Agent

A location-enabled user agent knows its location and is able to report it in a useful representation (e.g., geodetic or street address) to the origin server directly. Examples include mobile devices with GPS capability and user agents that allow the end user to manually select their location.

Location-Enabled Proxy Server

A location-enabled proxy server retrieves the location of an end user or mobile device from the network's location server in a useful representation and attaches that information to requests passing through it.

Location-Enabled User Agent with Mapping Proxy Server

A location-enabled user agent can collaborate with a mapping proxy server. In this configuration, the user agent knows its position in a network-dependent or otherwise not generally useful representation and passes it to a mapping proxy server. The mapping proxy converts the position into a generally useful form of location (e.g., by using network topological information) and forwards the request on to the origin server.

3.3. Protocols and Interfaces

The following protocols and interfaces can be identified from the typical network configurations.

Location Data Format

A standard format for describing a location is necessary. Ideally, this format would support an extensible set of location representations. If this format does not support a variety of location representations, then the architecture must support a plurality of location data formats. Each representation or data format must be named so that negotiation of location representations can be supported.

Origin Server

The focus of the protocol work should be placed on how to provide location to the origin server. This interface should support:

Standardized (i.e., neither application dependent nor user-agent dependent) location data transfer
Negotiation of location data format parameters (acceptable representations, etc.)
Negotiation of location reporting and privacy agreements

Proxy Server

The interface to the proxy server should be based on the interface to the origin server. However, it would be quite acceptable and perhaps recommended in some cases (e.g., for a WAP Gateway) to support an optimized protocol better suited to the characteristics of the wireless network or constrained mobile devices.

Location Server

A standard format for passing position information, and requesting, or retrieving location information from the network is needed. This interface should support:

Standardized position data transfer to and from the network (i.e. not bound to a single positioning technology)
Negotiation of location data format parameters (acceptable representations and accuracy) from the network
Standardized method of requesting the current position or location of a mobile device from the network

4. Requirements

The following requirements should be addressed by a position dependent information services architecture.

An extensible set of location representations must be supported.
End users must have access control over their location data, except when overridden by an appropriate authority.
Non-anonymous access to location dependent services must be supported.
User agents must be able to handle the negotiation of privacy agreements and the reporting of location information securely and without perturbing the navigational structure of the application.
Configurations with network control over the location information must not be precluded.
The origin and proxy servers should be able to indicate the location representations they can process.
The protocol to the origin server must be standard and not application specific or device specific.
A user agent must be able to discover new position dependent services and negotiate appropriate privacy agreements with those new services.
The architecture should make the source of the location information (i.e., whether from client or network) transparent to the origin server.
The architecture should make the original format of the position information transparent to the origin server.
The architecture should make the physical network transparent to the origin server.
The architecture must support both client initiated, and origin server initiated location requests.
The security and privacy framework must support both client initiated, and origin server initiated location requests.

5. Recommendations

Phone.com recommends the following:

Define an extensible position content type based on XML that is harmonized with the origin server protocol.
Define a standard protocol and interface for triggering origin server initiated requests for location updates. This protocol should be harmonized with the WAP Push Access Protocol.
Utilize CC/PP as the location data transfer mechanism to the origin server.
Rework P3P to allow it to be a privacy-negotiation/access-control veneer on top of CC/PP. In addition to the privacy policy statements currently supported in P3P, the agreement protocol can be utilized to negotiate:
- The private data to be transferred (e.g. location)
- The data transfer mechanism (e.g. CC/PP)
- The format/representation of the data requested
Define an optimized over-the-air protocol to access location information on WAP clients without all the overhead of CC/PP and P3P.