Internet DRAFT - draft-gogic-geopriv-concepts
draft-gogic-geopriv-concepts
Network Working Group A. Gogic
Internet Draft: IMAP ANNOTATE Extension QUALCOMM, Inc.
Document: draft-gogic-geopriv-concepts-00.txt June 2002
Location Information and Privacy Concepts
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. Internet-Drafts are
working documents of the Internet Engineering Task Force (IETF), its
areas, and its working groups. Note that other groups may also
distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-
Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Copyright Notice
Copyright (C) The Internet Society 2002. All Rights Reserved.
1 Abstract
This paper defines and explains some geographic location concepts of
interest to GeoPriv. Many of these are of particular interest in
mobile wireless systems and Internet applications involving those
systems and devices. The interaction between location service
architecture elements is briefly described. Methods of protecting
privacy by controlling the precision with which location information
is disclosed are elaborated.
Table of Contents
1 Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . 1
2 Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
3 Architecture Elements . . . . . . . . . . . . . . . . . . . . 3
3.1 Location Computation and Distribution Processes . . . . 3
3.1.1 Location Computation . . . . . . . . . . . . . . . . 3
3.1.2 Location Distribution . . . . . . . . . . . . . . . 4
3.2 Target Object . . . . . . . . . . . . . . . . . . . . . . 4
3.3 Target Object Privacy Profile . . . . . . . . . . . . . 4
3.4 Mobile Station . . . . . . . . . . . . . . . . . . . . . 4
3.5 Base Station . . . . . . . . . . . . . . . . . . . . . . 5
3.6 Location Computation Server . . . . . . . . . . . . . . . 5
3.7 Location Distribution Server and Policy Engine . . . . . 5
3.8 Location Client . . . . . . . . . . . . . . . . . . . . . 6
4 Definitions and Abbreviations . . . . . . . . . . . . . . . 6
5 Location Information Content . . . . . . . . . . . . . . . . 7
Gogic Expires December 2002 [Page 1]
Internet Draft GeoPriv Concepts June 2002
6 Location Information Distribution . . . . . . . . . . . . . 8
6.1 Request/Requestor Authorization . . . . . . . . . . . . . 8
6.2 Location Precision Classes . . . . . . . . . . . . . . . 8
6.3 Rounding to Desired Location Precision and Return Data . 9
6.4 Speed Category and Precision Classes . . . . . . . . . . 11
6.5 Encryption . . . . . . . . . . . . . . . . . . . . . . . 11
7 Location Data Confidence . . . . . . . . . . . . . . . . . . 11
8 Security Considerations . . . . . . . . . . . . . . . . . . 12
9 References . . . . . . . . . . . . . . . . . . . . . . . . 12
10 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12
11 Author's Address . . . . . . . . . . . . . . . . . . . . . . 13
12 Full Copyright Statement . . . . . . . . . . . . . . . . . . 13
2 Introduction
The primary motivating factor for the development of location
services in wireless system has been the implementation of emergency
services encompassed in the United States by the Federal
Communications Commission (FCC) mandate for the so-called "Enhanced
911" (E911) capability (see Ref. [2]). These services were
initially defined to supply location information to a public safety
operator in conjunction with an emergency call. Re-using the same
technology for services unrelated to voice calls in general and
emergency calls in particular, is viewed as a desirable development,
particularly if accomplished in the Internet environment, with the
potential of rapid development of a variety of commercially
desirable applications.
There are many examples of TCP/IP-based location applications that
are not related to emergency assistance. Many believe that these
applications are uniquely mobile, so-called "killer apps". A
prominent class of applications is TCP/IP-based tracking and
navigation/routing assistance. For example, a user might want to
obtain his or her own location and get route directions using
interactive maps. An application or a person might want to locate
someone else, e.g., family members or "buddies" in a closed user
group. Another example is geo-fencing, allowing users to define a
permitted location perimeter and causing an automatic notification
if a mobile moves outside of this perimeter.
Availability of simple and reliable location-based services might
open up an entirely new market for un-manned devices, such as fleet
management, dispatch optimization, law enforcement, even livestock
and wildlife management.
Location may be combined with other wireless telecommunication
services to provide enhanced services, such as location-based
commerce, service tiers, etc.
With some notable exceptions (such as livestock and wildlife
management), privacy of location objects is one of the key
Gogic Expires December 2002 [Page 2]
Internet Draft GeoPriv Concepts June 2002
requirements in most of these location applications.
3 Architecture Elements
This section introduces some basic architecture elements for
location services that are applicable in the wireless domain,
illustrated in Figure 1.
BS-2
* |
d2 * |
d1 * |
BS-1 * * * * * MS |
| * |
| * | _________
| d3 * | | |
| * | | AAA |
| * | |_________|
| BS-3 | |
| | | ___|___ ________ ________
| | +----| | | LDS & | | Loc. |
| +---------+ LCS +---+ PE +---+ Client |
+----------------------------|_______| |________| |________|
Figure 1: Location Services Architecture
Legend:
BS Base Station
MS Mobile Station
LCS Location Computation Server
PE Policy Engine
LDS Location Distribution Server
Loc. Client Client requesting MS location
* * * * Wireless mobile connections between the MS and BSs
----- & | Fixed line connections between BSs and core
network elements, and among those network elements
d1, d2, d3 Distances from the MS to BS 1, 2, and 3 respectively
3.1 Location Computation and Distribution Processes
One can conceptually think of location services as consisting of two
distinct processes: Location computation, and location
distribution. Each is controlled by a separate logical entity shown
in figure 1 as Location Computation Server (LCS), and Location
Distribution Server (LDS). In practical implementations, these
servers may be combined in a single physical entity. This may be
desirable because there are close security trust considerations
among the two.
3.1.1 Location Computation
Gogic Expires December 2002 [Page 3]
Internet Draft GeoPriv Concepts June 2002
Location computation is the process of computing the location of the
target. It consists of initiation of location measurements, and
their conversion into a meaningful set of location information, such
as latitude, longitude and altitude.
There are a number of location computation technologies available
today. Each contains specific location computation procedures. In
this document, the intent is not to elaborate on any of these
specific techniques, however, in the text below, some of the
techniques have been alluded to, primarily as background
information. In general, it can be stated that the GeoPriv task
does not depend on the vagaries of these techniques.
3.1.2 Location Distribution
Location distribution is the process of proving a target's location
to a requesting client, and consists of several sub-processes:
* Receiving location requests from the location client;
* Checking if the requester is authorized to receive location data
(e.g. verifying subscription status);
* Performing location client authentication, if required;
* Applying the privacy profile of the user to the raw unfiltered
location information, to convert it into a form that is allowed
for disclosure (for example by rounding to the time zone, or to
within the city boundary where the object is located)
* Transmitting filtered location data to the location client, with
encryption, if required.
3.2 Target Object
The target object is the object whose location information is
sought. The ability to control privacy for the target object is
required. In some cases, the user can authorize each individual
location client request for the object's location information.
3.3 Target Object Privacy Profile
The profile detailing the location privacy information (policy) for
the object (e.g., authorization class, location client exception
list, level of location precision disclosure for a given location
service client, etc.)
3.4 Mobile Station
A mobile station (MS) is a peripheral device, such as a wireless
telephone handset or a PDA, which is typically the location target.
The mobile station may contain a GPS (Globile Positioning System)
receiver, or may be able to make location computations by
triangulation from transmissions from three or more base stations.
Gogic Expires December 2002 [Page 4]
Internet Draft GeoPriv Concepts June 2002
By transmitting a radio signal that is received by multiple base
stations, such triangulation may be possible by means of time of
arrival information available at the base stations, or by means of
round-trip delay involved in combining BS-MS and MS-BS transmission
timing. The mobile station may also play a location client role, as
is the case where user wants to find out where he or she is located.
3.5 Base Station
Base stations (BS) are relay points of communication between the
mobile station and the rest of the telecommunication system. Base
stations play an important role in location determination process.
In GPS-based technologies, base stations can be used as reference
locations in order to relay assistance information to the GPS
receiver in the mobile station, including satellite constellation
data, and Doppler shift due to satellite velocity relative to the
mobile station. Such assistance accelerates the GPS receiver's
ability to perform a location fix. Base station locations are known
by the system, and may be conveyed to the mobile station as well.
Using that knowledge, the mobile station location can be computed by
triangulation methods. In practical implementations, some of these
techniques can be combined to increase confidence, or to choose the
one that is most appropriate, e.g., depending on satellite
visibility in the mobile stations locale, or complexities of
multipath radio signal propagation, which may obscure actual
location.
Reference [1] can be used as an example of radio link signaling used
in location determination.
3.6 Location Computation Server
The location computation server (LCS) collects raw measurement data
related to location determination and computes the target's
location. Raw data may include latitude, longitude, and elevation
from the fix performed in the GPS based system, as well as the
number of satellites visible by the GPS receiver in the mobile
station, allowing it to ascertain measurement confidence. In
triangulation methods, the LCS uses known base station locations,
and any calibration information, such as base station transmission
timing offsets, or mobile station receive-transmit timing offset, to
make location computations.
3.7 Location Distribution Server and Policy Engine
The location distribution server (LDS) performs tasks listed in
section 3.1.2
The LDS acts as the proxy for location distribution. Requests for
location from Internet-based clients can be referred to the LDS
Gogic Expires December 2002 [Page 5]
Internet Draft GeoPriv Concepts June 2002
first. The LDS can perform client authentication, and with the
assistance from the Policy Engine (PE) determine what privacy
policies are applicable, whether or not a new fix is required, etc.
It may then decide to order a new fix. In a typical implementation,
the LDS may use encrypted transmissions of location data either on
the wireless link, the Internet link, or both. The LDS also
communicates with an AAA server to verify authorization, convey
accounting data, and retrieve authentication information, such as
authentication and encryption keys.
LDS/PE and LCS are often incorporated in a single entity.
3.8 Location Client
A location client is an entity that interacts with the location
object or its proxy to obtain location information. The interaction
may be constrained by a set of specified parameters, such as
attributes of location precision. The location client may have to
subscribe first, before being allowed access to location
information. The location client is often responsible for
formatting and presenting data and managing the user interface. The
LCS Client may also reside in the target object.
4 Definitions and Abbreviations
In addition to the entities and concepts related to system
architecture defined in the previous section, we provide herein some
useful definitions and abbreviations.
Altitude
The geodetic location of the target object expressed as distance
above World Geodetic System 1984 (WGS-84) reference ellipsoid.
Confidence
Probability estimate that the location of a target object is
within the defined geographic shape (perimeter).
Last Known Location
The time stamped location estimate stored for the target object.
Location Client Personalization
A collection of attributes related parameters assigned to a
location client.
Location Estimate
The geographic location of a target expressed in the reference
World Geodetic System 1984 (WGS-84).
Location Precision
A set of attributes associated with a request for the geographic
location of a target. The attributes include the required
Gogic Expires December 2002 [Page 6]
Internet Draft GeoPriv Concepts June 2002
horizontal accuracy, vertical accuracy, response time, and
maximum age of the target location estimate.
WGS-84
World Geodetic System -- 1984.
WGS-84 Ellipsoid
Worldwide reference system defining the surface of the Earth.
5 Location Information Content
Some examples of location information content types include:
* Geographic location (latitude, longitude, altitude, elevation)
* Time zone in which target is located
* Horizontal and vertical speed
* Heading
* Resolution and associated confidence level for each relevant
datum
* Address (Country, province or state, region, city, area such as
postal code, street, number, label)
* Time Stamp for relevant datum or a data set
In addition to the above descriptors, other location data types are
possible, but may be left out from the first release of GeoPriv work
in the interest of simplicity. An example is azimuth, which is
related, but distinct from heading, since it conveys the object's
orientation, not necessarily direction of travel.
Latitude and longitude are expressed in degrees, minutes, and
seconds from the Equator and Greenwich reference meridian
respectively. Altitude is expressed in meters above WGS-84
ellipsoid (mean sea level). Elevation is height of terrain above
mean sea level, also expressed in meters. Height above ground can
be computed by subtracting elevation from altitude.
Time zone is expressed as a number of hours and minutes relative to
the Greenwich Mean Time (Universal Coordinated Time or UTC). This
may also be accompanied with a descriptive reference, for example
Pacific Time Zone (GMT -8 hrs, Tijuana)
Horizontal and vertical velocity is expressed in meters per second.
Increasing altitude results in positive vertical velocity.
Heading is deviation from the True North of the tangential vector
along the trajectory of travel. Azimuth is the orientation of an
object relative to True North. Azimuth of a stationary object can
be defined. Azimuth may deviate from heading. For example, due to
wind direction relative to flight path, heading of a flying airplane
may deviate from its azimuth.
Gogic Expires December 2002 [Page 7]
Internet Draft GeoPriv Concepts June 2002
Address of an object is the descriptive form of that object's
location. It is the description of location of the nearest
addressable object from a map database.
Time Stamp may be associated for each location datum or a set of
data. Time stamp is expressed in local time and an offset from the
local time to UTC.
Some of the described location information types are quite advanced,
and may not be incorporated in products or services in the first go.
To keep things simple, Geopriv should initially keep to a relatively
simple subset of these location objects.
6 Location Information Distribution
Controlling distribution of location information is one of the
pillars of privacy. Some of the issues associated with distribution
control involve authorization/authentication of location clients
(requestors) by the location target or its proxy, precision control
of the disclosed location data as a function of authorization class
and possibly application, and encryption of location data to protect
it against inadvertent disclosure (e.g., protection against
eavesdropping).
In the following sections we examine each of these distribution
issues in some detail.
6.1 Request/Requestor Authorization
The applicable policy should specify how a request for location
information is to be handled. Determination can be based on the
identity of the requestor, the use to which the information is to be
put, the time of day, and other factors. The result may be to
reject the request, approve it, or prompt the user. If approved,
the policy may limit the precision of the information. When
prompted, the user may approve or reject the request. Some
implementations may also allow the user to indicate how future
requests from the same source are to be handled (for example,
"reject current and all future requests from this source").
6.2 Location Precision Classes
In addition to authorization, the primary method for privacy control
in location services is the user's ability to allow disclosure to a
certain degree of precision.
For each authorization class a precision level attribute may be
defined. Levels of precision can exist for position (e.g., location
of a stationary object, or momentary location of a moving object),
Gogic Expires December 2002 [Page 8]
Internet Draft GeoPriv Concepts June 2002
as well as for velocity and orientation of the object. These
classes are listed in the two tables below.
The user or user agent must have the capability to control the
precision (resolution) with which the location information is
conveyed to a location client. The precision category should be
indicated to the client. The following table outlines precision
categories associated with object's momentary location:
Location Precision Precision Precision
Class Descriptive (meters) (LAT) (LON)
A Very Fine 1 not bound not bound
B Fine 10 0.3" 0.3/cos(lat)
C Street Block 100 3.2" 3.2/cos(lat) sec
D City Quarter 1,000 32" 32/cos(lat) sec
E City 10,000 5' 24" 5' 24''/cos(lat)
F Province/State 100,000 54" 54/cos(lat) min
G Country 1,000,000 9 deg 9/cos(lat) deg
H Continent 10,000,000 90 deg 90 deg
I Time Zone N/A N/A ~15 deg
J Deg Latitude N/A 1 deg N/A
K Deg Longitude N/A N/A 1 deg
L - Y ... reserved reserved reserved
Z Barred N/A None None
Table 1: Location Precision Classes
Precision specifications provide the order of magnitude, and do not
indicate certifiable accuracy.
Average WGS-84 ellipsoid distance from the center of the Earth is R
= 6,367,445 meters. This figure can be used to compute latitude and
longitude arc measurements corresponding to the target precision for
each location precision class. While conversion from distance to
latitude arc is straightforward (lat_arc = d/R * 180/pi [deg]), for
distances along parallels, this conversion varies. It is inversely
proportional to cosine of latitude, with singularities at the North
and South Pole.
For example, the latitude precision for the class E (d=10,000 meters
-- "City") is d/R = 1.57 mili-radians, or 5 minutes and 24 seconds
of arc. The longitude precision depends on latitude. At latitude
of 42 degrees exactly, for class E case as above, the latitude
precision is 7 minutes and 16 seconds of arc.
6.3 Rounding to Desired Location Precision and Return Data
To implement precision control, the location information is rounded
before being returned to the location client. Values rounded to the
desired precision should be returned, accompanied by an indication
of the precision class. In principle, rounded data should have full
Gogic Expires December 2002 [Page 9]
Internet Draft GeoPriv Concepts June 2002
integrity, i.e., provision of deceitful or misleading information
should be discouraged.
The same holds true for the case when a descriptive value is
returned to the location client. For example, for a location target
object located in Miami, willing to disclose its location only to
the precision level F (100,000 meters, or Province/State), rather
than returning deliberately wrong information, e.g., "Fort
Lauderdale", it would return "Florida".
When fine level of precision for location data is required, the most
universal method would be to return a latitude, longitude, altitude
triplet. Another possibility would be to return a descriptive
location of an object, such as a street address. In fact, street
address is the method used for emergency services ("911" in the
United States) when dialed from a fixed line phone. The emergency
service infrastructure looks up the database from the fixed line
phone number, which returns the address where the line is
terminated.
Descriptive value can also be returned as a response to a location
request to a mobile communication device. Once the lat/lon location
is known by the LCS, it performs a geographic database search to
find the description of the nearest addressable object, and returns
it to the requesting location client, assuming that no rounding is
required. Returning a descriptive value can be more meaningful to a
location application than the latitude longitude pair would be.
This becomes interesting when rounding is required before returning
descriptive location information. Probably the easiest way that
this can be accomplished is to display a map segment where the
target is located, and draw a perimeter corresponding to the
required precision.
It is also possible to return a rounded descriptive location without
having to return a graphic map segment. The precision figure for
the classes listed in Table 1 should be used as an order of
magnitude, not in any rigid fashion. For example, if class D (City
Quarter) is required, the return for a target located in New York
City might be "Manhattan", i.e., a locale that is bigger than the
1,000 meters order of magnitude for the precision class.
An opposite problem of having a number of small cities located
within a radius of 10,000 meters for Class E can be solved by
returning "In one of several cities", followed by a list of cities.
Another interesting example is precision class H (Continent).
Location rounding to 10,000,000 meters yields a large section of the
globe. If a descriptive location is desired, the response might be
"Africa", or "South Pacific Ocean", and need not strictly adhere to
segments of the globe given by the geodetic return option. E.g., a
target located in Morocco may round to a geodetic area that is in
Gogic Expires December 2002 [Page 10]
Internet Draft GeoPriv Concepts June 2002
Europe. Yet, the descriptive form of the return will still be
correct -- "Africa", since the LDE knows the actual location, and
will return the correct descriptive answer, still preserving the
level of vagueness implied by the precision class H.
6.4 Speed Category and Precision Classes
The user must have the capability to control the precision
(resolution) with which the speed information is conveyed to a
location client. The speed precision category should be indicated
to the client. The following table outlines speed precision
categories:
Speed Precision Value Range
Class Descriptive (km/h) (km/h)
VA Fine 1 Any
VB Approximate 10 km/h Any
VC Surface transport 100 km/hr <100, 100-200, >200
VD Airborne transport 1,000 <500, 500-1000, >1,000
VE - VY ... reserved reserved
VZ Barred None None
Table 2: Speed Precision Categories and Classes
Table 2 lists both speed precision categories and classes of speed
by magnitude or range of values. The location client requests the
desired class depending on the nature of its interest. If it wants
the precise speed of the target, it requests VA, or for the
approximate speed of the target, VB. In order to find out if the
target is likely in a surface transport vehicle and class of vehicle
(slow car, fast car, bullet train, etc.) -- it would request VC, and
so on.
6.5 Encryption
Privacy protection generally requires encryption. This guards
against inadvertent disclosure of information, as well as
eavesdropping. The target may regard its location as very valuable
information, and may require that any location disclosure be sent
suitably encrypted. Encryption usually involves trusted entities
due to the necessity of exchanging encryption keys, or
computationaly expensive key exchange techniques.
7 Location Data Confidence
Location information is an estimate obtained by measurements, which
is subject to errors and deterioration of accuracy for a moving
object, e.g., due to age of available data. Confidence is an
attribute of location information that attempts to assess the
probability that the information provided is accurate within a
Gogic Expires December 2002 [Page 11]
Internet Draft GeoPriv Concepts June 2002
specified perimeter. The confidence attribute can be affixed to any
location datum (for example velocity), however, it is most
meaningful for the point on or near the geodetic ellipsoid surface
as a descriptor of location, which we will call location datum. One
can think of the location datum as the place at which the confidence
reaches its peak. To convey location information uncertainty, the
location information may be provided to the client accompanied by
the degree of confidence. The perimeter for evaluation of
confidence is usually a circle with the center in the location
datum, but in principle, it can be any shape. For example, it may
be of interest to assess confidence that the object is within a city
block or within an irregularly shaped sports venue.
Two questions arise:
* What is the confidence that the object is within a given
perimeter?
* What is the perimeter within which location datum is provided
with a given degree of confidence?
The first requires that the client specifies the perimeter, and the
target returns the confidence. The other requires that the client
specifies the desired confidence, while the target returns the
perimeter, which may or may not be a circle.
8 Security Considerations
This document addresses manipulation and transport of the geographic
location of a target object. The target object may be closely
associated with a person, such is the case for a portable cellular
handset, or for a sensitive object. Inadvertent disclosure of
location information, particularly if the information is accurate,
can be damaging to the person's privacy, and possibly dangerous.
Security aspects are discussed in some detail throughout this
document.
9 References
[1] 3GPP2 C.S0022-0-1 (a.k.a. TIA/EIA/IS-801) Position
Determination Service Standard for Dual Mode Spread Spectrum
Systems, February 2001
[2] TIA/EIA/J-STD-036-A Enhanced Wireless 9-1-1 Phase 2, August 2000
(Rev. A March 2002)
[3] 3GPP TS 22.071V5.1.1, Location Services (LCS) Service
Description, Stage 1, March 2002
Gogic Expires December 2002 [Page 12]
Internet Draft GeoPriv Concepts June 2002
10 Acknowledgments
The author would like to thank the following people who contributed
to the text and provided many ideas for this draft, as well as
participated in reviewing it. All are affiliated with QUALCOMM,
Incorporated.
* Suzanne Arcens, sarcens@qualcomm.com
* Randall Gellens, rg+ietf@qualcomm.com
* John W Noerenberg II, jwn2@qualcomm.com
* Len Sheynblat: lens@qualcomm.com
In addition, some of the topics discussed in this draft appear in
documents [1], [2], and [3].
11 Author's Address
Aleksandar M. Gogic
QUALCOMM, Incorporated
5775 Morehouse Drive
San Diego, CA 92121-1714
USA
e-mail: agogic@qualcomm.com
12 Full Copyright Statement
Copyright (C) The Internet Society 2002. All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
Gogic Expires December 2002 [Page 13]
Internet Draft GeoPriv Concepts June 2002
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Gogic Expires December 2002 [Page 14]
