Workshop on Position Dependent Information Services
Phone.com Position Paper
Peter King
peter.king@corp.phone.com
Michael Luna
mluna@corp.phone.com
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.