Indoor Signal Position Conveyance
draft-jones-geopriv-sigpos-survey-00
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Author | Kipp Jones | ||
| Last updated | 2012-06-07 | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-jones-geopriv-sigpos-survey-00
Geographic Location/Privacy K. Jones
Internet-Draft Skyhook Wireless
Intended status: Standards Track May 31, 2012
Expires: December 2, 2012
Indoor Signal Position Conveyance
draft-jones-geopriv-sigpos-survey-00
Abstract
Location Information Servers rely on signal surveys to create a
signal map allowing for subsequent device location determination.
This document describes a method by which a Survey Device is able to
provide indoor location related measurement data to a LIS for
positioning purposes. Location related measurement information
comprises observations concerning properties related to the position
of a Survey Device and the radio, electromagnetic, and other
observable environmental measures as perceived by the Survey Device.
These measurements could be data about Wi-Fi signals, Bluetooth
signals, barometric pressure, or any other environmental measurement
which could sent to a LIS for subsequent processing to help determine
the location of devices that later enter the venue. A basic set of
location-related measurements, data rights disclosure and location
types are defined.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on December 2, 2012.
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.
Jones Expires December 2, 2012 [Page 1]
Internet-Draft Signal Position Survey May 2012
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Jones Expires December 2, 2012 [Page 2]
Internet-Draft Signal Position Survey May 2012
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 7
4. Description . . . . . . . . . . . . . . . . . . . . . . . . . 7
5. Out of Scope . . . . . . . . . . . . . . . . . . . . . . . . . 10
6. Using PIDF-LO Location . . . . . . . . . . . . . . . . . . . . 10
6.1. Device Orientation . . . . . . . . . . . . . . . . . . . . 11
7. Session . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
7.1. Venue . . . . . . . . . . . . . . . . . . . . . . . . . . 12
7.1.1. Venue Name/Address . . . . . . . . . . . . . . . . . . 13
7.1.2. Owner . . . . . . . . . . . . . . . . . . . . . . . . 14
7.1.3. Data Rights Management . . . . . . . . . . . . . . . . 16
7.1.3.1. License Expiry . . . . . . . . . . . . . . . . . . 16
7.1.3.2. License URI . . . . . . . . . . . . . . . . . . . 16
7.1.3.3. License Type . . . . . . . . . . . . . . . . . . . 16
7.1.4. Map Metadata . . . . . . . . . . . . . . . . . . . . . 18
7.2. Survey Device . . . . . . . . . . . . . . . . . . . . . . 18
7.2.1. Configuration Object . . . . . . . . . . . . . . . . . 20
7.2.2. Example Device Configuration . . . . . . . . . . . . . 21
7.3. Survey Data . . . . . . . . . . . . . . . . . . . . . . . 22
7.3.1. Ground Truth . . . . . . . . . . . . . . . . . . . . . 23
7.3.1.1. PIDF-LO Location . . . . . . . . . . . . . . . . . 24
7.3.1.2. Raw Location Data . . . . . . . . . . . . . . . . 30
7.3.2. Beacons . . . . . . . . . . . . . . . . . . . . . . . 33
7.3.3. Signal Measurements . . . . . . . . . . . . . . . . . 34
7.3.3.1. WiFi Measurements . . . . . . . . . . . . . . . . 34
7.3.3.2. Bluetooth Measurements . . . . . . . . . . . . . . 37
7.3.3.3. Other Signal Measurements . . . . . . . . . . . . 38
8. Example Surveys . . . . . . . . . . . . . . . . . . . . . . . 38
8.1. WiFi Access Point Location Survey . . . . . . . . . . . . 38
8.2. WiFi Signal Survey . . . . . . . . . . . . . . . . . . . . 41
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 45
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 45
10.1. IANA Registry for Data License Types . . . . . . . . . . . 45
11. Schemas . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
12. Security Considerations . . . . . . . . . . . . . . . . . . . 47
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 47
13.1. Normative References . . . . . . . . . . . . . . . . . . . 47
13.2. Informative References . . . . . . . . . . . . . . . . . . 48
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 49
Jones Expires December 2, 2012 [Page 3]
Internet-Draft Signal Position Survey May 2012
1. Introduction
This document describes a format for the expression of the measure
and location of signals (SigPos) within a venue for purposes of
providing location services.
The format includes a venue description, signal information, and data
usage specifications.
A venue is defined as an area of interest for providing location
services. Examples of a venue include a campus, a building, or a
room. A venue should have a single administrative contact.
Signal information is inclusive of the specific description and
measures of the signal (e.g. 802.11 Wi-Fi signals), a description the
device used to measure the signals, as well as the location and
orientation of the device.
Multiple methods for providing location are defined including civic
locations, geodetic locations, absolute locations, relative
locations, and locations with error estimates.
In addition to the signal information, on optional section provides
the ability to specify the data usage rights to be conferred to
another entity. One right would be to grant a Location Information
Service (LIS) rights to make use of the signal information to provide
location services.
1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
2. Overview
This document describes a common method to record, distribute and
grant rights on signal location information related to the geospatial
measurement of wireless RF signals. The document sets forth the
motivation behind the effort, the basic design of the data format,
the reasoning and technical approach for managing the ownership of
the information, and provides various usage scenarios to further
describe the architecture.
The primary motivation for this work is in providing a common
framework for capturing and sharing information related to the
geospatial measurement of RF signals for purposes of providing
Jones Expires December 2, 2012 [Page 4]
Internet-Draft Signal Position Survey May 2012
locative services based on the transmitters associated with these
signals. There may be other uses such as network optimization and
interference analysis that could be provided via this specification
but these are not the primary goal.
Historically, each vendor or entity interested in using sensors
(WiFi, cellular, sound ranging) to determine the location of a device
has been required to know the geospatial location and attributes
associated with a set of transmitters in order to provide location
services based on these transmitters. If the locations of the
transmitters were not known, the entity would need to 'map' these
transmitters and their associated signals through various means and
assign them a set of geospatial coordinates and some estimate of the
signal map and signal properties of each transmitter.
The problem has grown in scale as the number of mobile devices has
rapidly expanded along with the proliferation of location-based or
location-enhanced applications. This problem can largely be solved
for outdoor and coarse indoor positioning using a number of
techniques such as drive scanning and end-user device reported
information combined with GPS. These techniques have enabled a large
portion of the global WiFi signal set to be modeled and used for end-
user positioning.
However, these methods, even when based on GPS information, have
limits on the accuracy to which they can determine the location of a
device solely on these signals. The problem is further exacerbated
and compounded by the desire to provide indoor positioning with
accuracy below 10 meters.
Outdoor scanning via vehicles and end-user devices is possible due to
the reliable and global reach of GPS. Signals captured in open-air
environments can be assigned geospatial coordinates based on the
availability of a reliable GPS reading. However, the ability to
leverage an existing positioning technology is severely limited when
the scanning equipment moves indoors. The availability of GPS is
reduced and in many places eliminated. This requires that the
scanning equipment use some other means to determine the relative or
absolute geospatial position within a building in order to associate
the signal measurement with the location in the building.
This problem has been addressed by various means in what is generally
referred to as a 'site survey'. Often times specialized hardware
with professional grade GPS systems, highly calibrated sensors for
dead reckoning, laser range finders or other techniques have been
deployed to accomplish these site surveys. These techniques provide
a professional surveyor with the tools and capability to produce a
highly accurate signal map of a given building. Unfortunately this
Jones Expires December 2, 2012 [Page 5]
Internet-Draft Signal Position Survey May 2012
process has several drawbacks:
o the use of specialized hardware with highly trained engineers is
expensive. By requiring the design and manufacture of specialized
hardware as well as trained individuals to operate the hardware,
the ability to scale the process and realize mass production
reductions in costs are foregone
o the process is, in general, a proprietary venture. The resulting
information is in a proprietary format and is intended to work
with a specific vendor provided location system
o it doesn't account for changes. Venues change, the radio, visual,
and acoustical environment changes and the transmitters themselves
are moved and replaced over time. Coping with this level of
entropy and maintaining an up-to-date signal map is both time
consuming and costly
o the value is locked in a vendor. To exploit the investment
further is problematic at best and impossible at worst. The value
that is obtained from the effort to create a signal map may be
realized by the vendor and not the venue owner. Even if the
vendor made a portion of the investment, the venue owner may be
excluded from additional revenue sources as new ways to leverage
the data and additional location services are created
o high quality venue maps have not been readily accessible. Having
location is an important part of the puzzle, but having the
ability to pin the dot on a map creates innumerable additional
opportunities
o mobile devices and applications have traditionally been locked to
the vendor that did the site survey. This made it impossible to
scale across many different apps on many different mobile
operating systems
o context is more important for indoor positioning while latitude,
longitude, and altitude are less valuable. In other words, it is
more important from a user perspective to identify the floor, the
room, the aisle, etc. than it is to provide only x, y, z
coordinates
The goal of this specification is to reduce these friction points and
provide a common method for specifying, encoding, conveying, and
granting usage rights to signal survey information.
Jones Expires December 2, 2012 [Page 6]
Internet-Draft Signal Position Survey May 2012
3. Open Issues
This document contains a number of open issues that need to be
addressed or items that need further refinement, including:
1. Additional Privacy Considerations - what additional privacy and
security issues need to be considered?
2. Survey Device Configuration Specification - is there a better way
to declare device/sensors? SenML?
3. Specification of Licensing Options - are these sufficient? IANA
registration for others? Do we need a more formal definition?
4. Formal xsd definition
4. Description
The basic premise for the SigPos data format is to preserve the
concept of a 'survey session'. A survey session generally represents
a set of contiguous location and sensor scan records that were
gathered by a given device. For example, this could represent a
survey of the floor of a building, a single point survey, or a survey
of a room.
This document defines a container for the conveyance of location-
related measurement parameters or specifications related to beacon
locations and their related signal patterns within an indoor venue.
This is an XML container that identifies parameters by type and
allows the Device to provide the results of any measurement it is
able to perform. A set of measurement schemas are also defined that
can be carried in the generic container. Lastly, it allows for the
manual specification of both the beacons as well as their location.
A number of additional concepts are included in this standard such as
the identification of the equipment conducting the survey and the
inclusion of both explicit and implicit location information. These
will be detailed further in following sections.
The interpretation of the survey data is left to the implementer of
the location service and is not explicitly part of this
specification. For example, how to correlate a particular WiFi
signal sample with an interpolated location, or how much time lapse
between a WiFi signal reading and a GPS sample is permissible. These
are choices that are decoupled from the data gathering and
transmission, but every attempt has been made to provide the facility
to include sufficient information in this standard to enable
Jones Expires December 2, 2012 [Page 7]
Internet-Draft Signal Position Survey May 2012
downstream algorithms to make appropriate choices.
Each capture document corresponds to a 'session'. Each session can
have a 'venue' section, a 'survey device' section, and a 'survey'
section. The venue describes the venue, the location of the venue,
the owner organization as well as the data rights applicable to the
survey. The Venue Section (Section 7.1) describes the venue or
location of the survey, and the Survey Device section (Section 7.2)
describes the device being used to capture the survey data.
The Survey Data section (Section 7.3) describes a method for the
actual survey data to be formatted in a standardized format. Each
capture session is meant to take place within a single building or
structure corresponding to the venue described in the venue section.
A session may be composed of many 'survey points'. Each survey point
can have a location description, location elements, WiFi keys, WiFi
readings and 'other' sensor readings.
Note, where possible, location-info objects as described within
PIDF-LO and extensions are used to express location information.
An overview of the document structure is provided in the following
figure.
Jones Expires December 2, 2012 [Page 8]
Internet-Draft Signal Position Survey May 2012
+---------------+
__| Name |
| |_______________|
|
+-----------+ | +---------------+
__| Venue |__|_| Address |
| |___________| | |_______________+ +--------------+
| | _| Name |
| | +---------------+ | |______________|
| |_| Owner |__|
| | |_______________| | +--------------+
| | |_| Address |
| | +---------------+ |______________|
| |_| License |
| |_______________|
+---------+ |
| Session | -|
|_________| |
| +---------------+
| __| Configuration |
| | |_______________|
| |
| +-----------+ | +---------------+ +--------------+
|_| Survey |__|_| Survey |____| Sensor |__
| | Device | | Sensors | |______________|
| |___________| |_______________|
|
| +--------------+
| __| Ground Truth |__
| | |______________|
| |
| +-----------+ +---------------+ | +--------------+
+-| Survey |____| Survey Point |__|_| Beacons |__
|___________| |_______________| | |______________|
|
| +--------------+
|_| Measurements |__
|______________|
Document structure overview.
Figure 1
Jones Expires December 2, 2012 [Page 9]
Internet-Draft Signal Position Survey May 2012
5. Out of Scope
There are several items that are explicitly out of scope for this
document. These include:
o Dead reckoning and other sensor data such as gyroscope, barometric
pressure and accelerometer readings are expected to be
incorporated into the positioning computation by the device prior
to encoding the location object, and
o Computation of interpolated locations/readings are left for the
downstream processor such as a LIS.
6. Using PIDF-LO Location
All location information in this container are specified using the
GEOPRIV Presence Information Data Format Location Object. This
includes the basic definition of the PIDF-LO [RFC4119] object,
PIDF-LO Clarification [RFC5491], Revised Civic Location Format
[RFC5139], Dynamic Extensions to PIDF-LO [RFC5962], PIDF-LO Relative
Location [I-D.ietf-geopriv-relative-location], and Civic Address
Extensions [I-D.ietf-geopriv-local-civic].
The PIDF-LO object provides a variety of mechanisms to indicate
position. This may refer to the location of the venue, the location
of a beacon or the location of the survey device itself. Several of
the capabilities of the PIDF-LO object are discussed in this section.
For a full specifications refer to the relevant RFCs and Internet
Drafts.
The PIDF-LO object allows for specification of elements that
encompass:
o Position
o Timestamp
o Provider
o Uncertainty
o Bearing
o Speed
o Orientation
Jones Expires December 2, 2012 [Page 10]
Internet-Draft Signal Position Survey May 2012
For purposes of signal positioning survey, we define several classes
of PIDF-LO objects:
o Manual geolocation - human manipulation or specification of a
geolocation
o Integrated geolocation - system generated geolocation (e.g. via
GPS)
o Relative location - geolocation based on a defined reference point
Each of these methods of providing location can be encoded within the
constructs provided by the PIDF-LO structure when combined with the
necessary extensions mentioned above and described in more detail in
subsequent sections.
6.1. Device Orientation
The optional orientation elements allows the surveyor to provide
precise information with respect to the orientation of the scanning
device at the time the readings were made. This orientation
information can be used to differentiate signal information when the
device is held at different angles at each survey point.
From the "Dynamic Extensions to the Presence Information Data Format
Location Object (PIDF-LO)" [RFC5962], we find:
"The <orientation> element describes the spatial orientation of the
presentity -- the direction that the object is pointing. For a
device, this orientation might depend on the type of device."
This proposed extension to the PIDF-LO object allows for the
inclusion of device orientation within each PIDF-LO object.
An example specifying device orientation:
Jones Expires December 2, 2012 [Page 11]
Internet-Draft Signal Position Survey May 2012
<presence
xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model"
xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
xmlns:dyn="urn:ietf:params:xml:ns:pidf:geopriv10:dynamic"
xmlns:gml="http://www.opengis.net/gml"
entity="pres:alice@example.com">
<dm:device id="abc123">
<gp:geopriv>
<gp:location-info>
<dyn:Dynamic>
<dyn:orientation>-3 12</dyn:orientation>
<dyn:speed>24</dyn:speed>
<dyn:heading>278</dyn:heading>
</dyn:Dynamic>
</gp:location-info>
<gp:usage-rules/>
<method>gps</method>
</gp:geopriv>
<timestamp>2009-06-22T20:57:29Z</timestamp>
<dm:deviceID>mac:1234567890ab</dm:deviceID>
</dm:device>
</presence>
7. Session
The session element creates a container for the other elements of the
survey. There should be a single survey per document.
The session tag includes two required attributes: the sessionID and
the sessionDate.
SeesionID: contains an opaque string which provides a globally unique
identifier for this survey.
SessionDate: contains the date the survey was performed.
<session sessionID="X88278xskkw" sessionDate="2009-06-22T20:57:29Z">
...
</session>
7.1. Venue
The venue section describes the venue itself and also provides for
two additional elements: the definition of the owner and the
definition of the policy for the included data.
Jones Expires December 2, 2012 [Page 12]
Internet-Draft Signal Position Survey May 2012
+---------------+
| Venue xCard |
__| Name/Address |
| |_______________|
|
+-----------+ | +---------------+
| Venue |__|_| Owner xCard |
|___________| | | Name/Address |
| |_______________|
|
| +---------------+
|_| License |
| |_______________|
|
| +---------------+
|_| Map Metadata |
|_______________|
Venue structure overview.
Figure 2
The venue section of the document provides for the ability to
identify the venue in which the survey took place as well as the
location of the venue.
7.1.1. Venue Name/Address
This optional element provides the ability to specify the name and
address of the venue for identification purposes. This element uses
the xCard [RFC6351] XML format to provide the necessary structure for
these elements.
Jones Expires December 2, 2012 [Page 13]
Internet-Draft Signal Position Survey May 2012
<?xml version="1.0" encoding="UTF-8"?>
<vcards xmlns:vc="urn:ietf:params:xml:ns:vcard-4.0">
<vc:vcard>
<vc:fn><vc:text>Example Building</vc:text></vc:fn>
<vc:adr>
<vc:parameters>
<vc:type><vc:text>work</vc:text></vc:type>
<vc:label><vc:text>Example Building
1 South Boston Street
Boston, MA USA 02210</vc:text></vc:label>
</pvc:arameters>
<vc:pobox/>
<vc:ext/>
<vc:street>1 South Boston Street</vc:street>
<vc:locality>Boston</vc:locality>
<vc:region>MA</vc:region>
<vc:code>02210</vc:code>
<vc:country>USA</vc:country>
</vc:adr>
</vc:vcard>
</vcards>
7.1.2. Owner
The optional ownership section allows for the definition of the
organization or individual that originated the data. The ownership
section also makes use of the xCard [RFC6351] format for encoding
information about the name and address of the owner entity.
Jones Expires December 2, 2012 [Page 14]
Internet-Draft Signal Position Survey May 2012
<?xml version="1.0" encoding="UTF-8"?>
<vcards xmlns:vc="urn:ietf:params:xml:ns:vcard-4.0">
<vc:vcard>
<vc:fn><text>Rober Builder</vc:text></vc:fn>
<vc:n>
<vc:surname>Builder</vc:surname>
<vc:given>Robert</vc:given>
<vc:additional/>
<vc:prefix/>
<vc:suffix/>
</vc:n>
<vc:adr>
<vc:parameters>
<vc:type><text>work</vc:text></vc:type>
<vc:label><text>Rober Builder
1 South Boston Street
Boston, MA USA 02210</vc:text></vc:label>
</vc:parameters>
<vc:pobox/>
<vc:ext/>
<vc:street>1 South Boston Street</vc:street>
<vc:locality>Boston</vc:locality>
<vc:region>MA</vc:region>
<vc:code>02210</vc:code>
<vc:country>USA</vc:country>
</vc:adr>
<vc:tel>
<vc:parameters>
<vc:type>
<vc:text>work</vc:text>
<vc:text>voice</vc:text>
</vc:type>
</vc:parameters>
<vc:uri>tel:+1-555-555-1212;ext=102</vc:uri>
</vc:tel>
<vc:email>
<vc:parameters>
<type><text>work</vc:text></vc:type>
</vc:parameters>
<vc:text>reober.builder@example.com</vc:text>
</vc:email>
</vc:vcard>
</vcards>
Jones Expires December 2, 2012 [Page 15]
Internet-Draft Signal Position Survey May 2012
7.1.3. Data Rights Management
The license object allows the venue owner or site surveyor the
ability to manage the ownership, distribution, and usage rights of
the survey data. This document includes a mechanism for including
copyright and licensing terms. The licensing models are described in
more detail below.
The <license> object is optional. If missing, the license type is
assumed to be 'unrestricted' with a default expiration.
7.1.3.1. License Expiry
The optional License Expiry tag allows the surveyor to set time
limits on the usage granted by the License Type. By default the data
license expires 30 days after the date identified in the sessionDate.
<licenseExpiry>2008-04-29T14:33:58</licenseExpiry>
7.1.3.2. License URI
The License URI provides an optional element to identify the terms of
a 'Private' license type. This allows
7.1.3.3. License Type
The optional policy element is intended to allow the venue owner/
manager or the entity in charge of data gathering for a given venue
to provide granular control over the use and subsequent derivative
works based on the venue's infrastructure. In the event that no
policy is specified, it is assumed that the data is released using
the unrestricted policy.
There are eight pre-defined Data License Types grouped into three
categories.
7.1.3.3.1. Unrestricted License
The unrestricted policy allows for the use and unrestricted
derivative products based on the data set. If the data expires, the
original data can no longer be used, but any derivative products that
were generated during the granted use of the data remains valid.
Example of an unrestricted license delcaration:
Jones Expires December 2, 2012 [Page 16]
Internet-Draft Signal Position Survey May 2012
<license>
<licenseExpiry>2108-04-29T14:33:58</licenseExpiry>
<licenseType>unrestricted</licenseType>
</license>
7.1.3.3.2. Creative Commons License
The Creative Commons [CC] provide a number of licensing options
which, in some cases, permit the owner of the data to restrict
commercial use and/or derivative works. Valid types include:
o CC BY - This license lets others distribute, remix, tweak, and
build upon your work, even commercially, as long as they credit
you for the original creation.
o CC BY-ND - This license allows for redistribution, commercial and
non-commercial, as long as it is passed along unchanged and in
whole, with credit to you.
o CC BY-NC-SA - This license lets others remix, tweak, and build
upon your work non-commercially, as long as they credit you and
license their new creations under the identical terms.
o CC BY-SA - This license lets others remix, tweak, and build upon
your work even for commercial purposes, as long as they credit you
and license their new creations under the identical terms.
o CC BY-NC - This license lets others remix, tweak, and build upon
your work even for commercial purposes, as long as they credit you
and license their new creations under the identical terms.
o CC BY-NC-ND - This license is the most restrictive of our six main
licenses, only allowing others to download your works and share
them with others as long as they credit you, but they can't change
them in any way or use them commercially.
<license>
<licenseExpiry>2008-04-29T14:33:58</licenseExpiry>
<licenseType>CC BY-ND</licenseType>
</license>
7.1.3.3.3. Private License
The private license is intended to provide full control over the
ownership, usage, and derivative usage of the data. Any use of the
data would be governed under a separate agreement between the owner
and the party wishing to make use of the data. By default, no rights
are granted for private data.
Jones Expires December 2, 2012 [Page 17]
Internet-Draft Signal Position Survey May 2012
<license>
<licenseType>private</licenseType>
<licenseURI>http://www.example.com/mylicense.html</licenseURI>
<licenseExpiry>2008-04-29T14:33:58</licenseExpiry>
</license>
7.1.4. Map Metadata
The optional "map" URL can be used to provide a user or system with a
visual reference for the location information. This URL
specification is based on that provided in Section 4.11 of PIDF-LO
Relative Location [I-D.ietf-geopriv-relative-location] specification.
For purposes of the overall Venue map, the offset SHOULD provide the
offset to the starting location on the map for the survey.
<rel:map>
<rel:url type="image/jpeg">
http://example.com/map.jpg
</rel:url>
<rel:offset> 200 210</rel:offset>
<rel:orientation>68</rel:orientation>
<rel:scale>2.90 -2.90</rel:scale>
</rel:map>
7.2. Survey Device
The specification includes elements to describe the capabilities of
the hardware and software of the scanning device as well as the
hardware and software for the sensors that were used to capture the
scan data. This can allow further downstream processing by
discriminating source data based on capabilities and known device/
sensor profiles and behaviors.
The Survey Device section SHOULD contain one device configuration
record. It MAY contain 0-n sensor configuration elements.
Jones Expires December 2, 2012 [Page 18]
Internet-Draft Signal Position Survey May 2012
_+-------------+ +-----------------+
| | Hardware |____|| Configuration ||
| |_____________| ||_______________||
|
|_+-------------+ +-----------------+
| | Software |____|| Configuration ||
| |_____________| ||_______________||
+---------+ |
| Survey |__|
| Device | |
|_________| | +-------------+ +-------------+ +-----------------+
|_| Sensor (0-n)|____| Hardware |___|| Configuration ||
|_____________| | |_____________| ||_______________||
|
| +-------------+ +-----------------+
|_| Software |___|| Configuration ||
|_____________| ||_______________||
Survey Device structure overview.
Figure 3
Jones Expires December 2, 2012 [Page 19]
Internet-Draft Signal Position Survey May 2012
7.2.1. Configuration Object
+-----------------+
__| Type |
| |_________________|
|
| +-----------------+
|_| Id |
| |_________________|
|
| +-----------------+
|_| Name |
| |_________________|
+-----------------+ |
| Configuration |__| +-----------------+
|_________________| |_| Manufacturer |
| |_________________|
|
| +-----------------+
|_| Model |
| |_________________|
|
| +-----------------+
|_| Version |
| |_________________|
|
| +-----------------+
|_| Vendor |
| |_________________|
|
| +-----------------+
|_| Capability |
|_________________|
Survey Device Configuration structure overview.
Figure 4
The configuration object allows for the description of a various
hardware components used to perform the survey. This allows for the
description of the survey device itself as well as any sensors or
radio components that are used in performing the survey.
The configuration object can contain various elements as described
below. Required items are noted.
Jones Expires December 2, 2012 [Page 20]
Internet-Draft Signal Position Survey May 2012
o id - (required) - provides a locally unique identifier for the
component being described. For example, this could be the MAC
address if describing a WiFi Network Interface Card.
o name - (required) - the name of the device/sensor
o vendor - (0-1) - a human readable description of the component
vendor
o model - (0-1) -the model and model number of the component
o capability - (0-n) - a name/value pair to allow arbitrary
configuration and capability declarations for each configuration
object.
7.2.2. Example Device Configuration
An example <device> object is shown below.
<device>
<hardware>
<configuration>
<type>device</type>
<name>mapit</name>
<version>1.2</version>
<id>abc</id>
<model>900</model>
<capabiity name="chipset">Intel Q965</capability>
<capabiity name="power">12 volt</capability>
</configuration>
</hardware>
<software>
<configuration>
<type>software</type>
<name>Centos6</name>
<version>2.6.18-308.1.1.el5 #1 SMP x86_64 GNU</version>
</configuration>
</software>
<sensor>
<hardware>
<configuration>
<id>000FFA9870BC</id>
<name>External WiFi</name>
<version>1.23</version>
<vendor>aetheros</vendor>
<capability name="antenna">omni-directional</capability>
Jones Expires December 2, 2012 [Page 21]
Internet-Draft Signal Position Survey May 2012
<capability name="gain">10</capability>
<capability name="chipset">aetheros</capability>
<capability name="standard">a,b,g,n</capability>
<capability name="frequencyband">1-13</capability>
</capabilities>
</configuration>
</hardware>
<software>
<configuration>
<name>atheros driver</name>
<version>ath9k</version>
</configuration>
</software>
</sensor>
<sensor>
<hardware>
<configuration>
<type>gps</type>
<id>gm39211</id>
<version>4.23a</version>
<vendor>unknown</vendor>
<capability name="antenna">combined</capability>
<capability name="chipset">qualcomm</capability>
</configuration>
</hardware>
</sensor>
</device>
7.3. Survey Data
The survey section represents all of the scanned or input data
gathered about the venue in this session. Within a 'survey', there
may be 0-n 'readings' which will contain a complete set of
information about a subset of the survey. For example, a single room
could be captured within a 'readings' segment.
This document defines location-related measurement data types for a
range of common sensor types.
All included measurement data definitions allow for arbitrary
extension in the corresponding schema. As new parameters that are
applicable to location determination are added, these can be added as
new XML elements in a unique namespace. Though many of the
underlying protocols support extension, creation of specific XML-
based extensions to the measurement format is favored over
accommodating protocol-specific extensions in generic containers.
Note, the "time" attribute records the time that the measurement or
Jones Expires December 2, 2012 [Page 22]
Internet-Draft Signal Position Survey May 2012
observation was made. This time can be different from the time that
the measurement information was reported. Time information can be
used to populate a timestamp on each ground truth element and to the
root "measurement" element. If it is necessary to provide multiple
sets of measurement data with different times, multiple "measurement"
elements SHOULD be provided.
+--------------+
__| Ground Truth |__
| |______________|
|
+-------------+ +---------------+ | +--------------+
-| Survey Data |___| Survey Point |__|_| Beacons |__
|_____________| |_______________| | |______________|
|
| +--------------+
|_| Measurements |__
|______________|
Document structure overview.
Figure 5
Survey Points describe a subset of the survey information and
potentially include Ground Truth, Beacon IDs, and Signal
Measurements. These categories of information are detailed further
in the following sections.
7.3.1. Ground Truth
Ground truth is a term that describes the location of the Survey
Device.
The 'ground truth' element is designed to allow the specification and
recording of the location at which the survey point was captured. To
encompass various survey and usage scenarios, there are currently
three GroundTruth types available for each survey point. These
include PIDF-LO location object, a Contextual Location object, and/or
a Raw Location object. These are described further below.
Multiple Ground Truth objects are allowed for interpolation between a
starting point and an endpoint without explicitly declaring each scan
position. The interpolation of the survey data is left to the
downstream processor such as an LIS server.
Jones Expires December 2, 2012 [Page 23]
Internet-Draft Signal Position Survey May 2012
groundTruth MUST have at least 1 SurveyPoint object as defined below.
+----------------+ +----------+
_| Basic Location |- -| Civic |
| |________________| | Location |
+-------------+ | |__________|
| GroundTruth |___| +----------------+
|_____________| |_| Raw Location |
| Data |
|________________|
Groundtruth structure overview.
Figure 6
7.3.1.1. PIDF-LO Location
This section describes the primary PIDF-LO method types that are
supported by this specification. While all PIDF-LO location
'methods' are possible, the following are the only methods that MUST
be supported.
o GPS
o A-GPS
o Triangulation
o Cell
o Manual
In addition, support MUST be provided for relative locations as
described below for each of the above PIDF-LO location methods.
7.3.1.1.1. Basic Location
Basic location represents a location as provided by the Survey
Device. This could be from a location API, WiFi positioning, an
integrated GPS, or any other mechanism that computes or determines
the location of the survey device. To encompass this variety of
locative technologies, the structure of the object provides numerous
constructs.
An example of an integrated GPS location including dynamic
orientation extensions is shown below. More examples of encodings
can be found in PIDF-LO Usage [RFC5491].
Jones Expires December 2, 2012 [Page 24]
Internet-Draft Signal Position Survey May 2012
<presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
xmlns:cl="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
xmlns:rel="urn:ietf:params:xml:ns:pidf:geopriv10:relative"
xmlns:dyn="urn:ietf:params:xml:ns:pidf:geopriv10:dynamic"
xmlns:gml="http://www.opengis.net/gml">
<tuple id="abcd123456">
<status>
<gp:geopriv>
<gp:location-info>
<gs:Ellipsoid srsName="urn:ogc:def:crs:EPSG::4326">
<gml:pos>42.5463 -73.2512 26.3</gml:pos>
<gs:semiMajorAxis uom="urn:ogc:def:uom:EPSG::9001">
7.7156
</gs:semiMajorAxis>
<gs:semiMinorAxis uom="urn:ogc:def:uom:EPSG::9001">
3.31
</gs:semiMinorAxis>
<gs:verticalAxis uom="urn:ogc:def:uom:EPSG::9001">
28.7
</gs:verticalAxis>
<gs:orientation uom="urn:ogc:def:uom:EPSG::9102">
90
</gs:orientation>
<dyn:Dynamic>
<dyn:orientation>-3 12</dyn:orientation>
<dyn:speed>24</dyn:speed>
<dyn:heading>278</dyn:heading>
</dyn:Dynamic>
</gs:Ellipsoid>
</gp:location-info>
<gp:usage-rules/>
<method>gps</method>
<gp:usage-rules/>
</gp:geopriv>
<timestamp>2009-06-22T20:57:29Z</timestamp>
</status>
</tuple>
</presence>
7.3.1.1.2. Relative Location
A relative location is based on the topology of the venue and is
specified by first declaring one or more anchors that contain a
geospatial reference.
Jones Expires December 2, 2012 [Page 25]
Internet-Draft Signal Position Survey May 2012
Relative Location MUST be defined using "Internet Draft Relative
Location Representation" [I-D.ietf-geopriv-relative-location].
An example of a PIDF-LO geopriv object with relative location
extensions included is shown below.
Jones Expires December 2, 2012 [Page 26]
Internet-Draft Signal Position Survey May 2012
<presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
xmlns:cl="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
xmlns:rel="urn:ietf:params:xml:ns:pidf:geopriv10:relative"
xmlns:dyn="urn:ietf:params:xml:ns:pidf:geopriv10:dynamic"
xmlns:gml="http://www.opengis.net/gml">
<tuple id="abcd123456">
<status>
<gp:geopriv>
<gp:location-info>
<gml:Circle srsName="urn:ogc:def:crs:EPSG::4326">
<gml:pos>-34.407 150.883</gml:pos>
<gs:radius uom="urn:ogc:def:uom:EPSG::9001">
50.0
</gs:radius>
</gml:Circle>
<rel:relative-location>
<rel:reference>
<gml:Point srsName="urn:ogc:def:crs:EPSG::4326">
<gml:pos>-34.407 150.883</gml:pos>
</gml:Point>
</rel:reference>
<rel:offset>
<gml:Circle xmlns:gml="http://www.opengis.net/gml"
srsName="urn:ietf:params:geopriv:relative:2d">
<gml:pos>500.0 750.0</gml:pos>
<gml:radius uom="urn:ogc:def:uom:EPSG::9001">
5.0
</gml:radius>
</gml:Circle>
</rel:relative-location>
<map:map>
<map:urltype="image/png">
https://www.example.com/flrpln/123South/flr-2</gp:url>
<map:offset> 2670.0 1124.0 1022.0</gp:offset>
<map:orientation>67.00</gp:orientation>
<map:scale>10</gp:scale>
</map:map>
</gp:location-info>
<gp:usage-rules/>
<gp:method>Triangulation</gp:method>
</gp:geopriv>
<timestamp>2007-06-22T20:57:29Z</timestamp>
</status>
</tuple>
</presence>
Jones Expires December 2, 2012 [Page 27]
Internet-Draft Signal Position Survey May 2012
7.3.1.1.3. Manual Location
The manual location object allows the surveyor to specify the
geospatial coordinate and/or a civic address to be associated with
the 'readings' data.
This element contains any valid location, using the rules for a
"location-info" element, as described in RFC 5491 [RFC5491].
Location information in a survey may be described in a geospatial
manner based on a subset of Geography Markup Language (GML) 3.1.1
[OGC-GML3.1.1] or as civic location information RFC 5139 [RFC5139]
and refined in RFC 5774 [RFC5774]. An OGC GML [OGC-GML3.1.1] profile
for expressing geodetic shapes in a PIDF-LO is described in GML
GeoShape Application Schema [GeoShape].
Below are several examples of manual location objects.
<presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
xmlns:cl="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
xmlns:rel="urn:ietf:params:xml:ns:pidf:geopriv10:relative"
xmlns:dyn="urn:ietf:params:xml:ns:pidf:geopriv10:dynamic"
xmlns:gml="http://www.opengis.net/gml">
<tuple id="abcd123456">
<status>
<gp:geopriv>
<gp:location-info>
<gml:Point srsName="urn:ogc:def:crs:EPSG::4326">
<gml:pos>-43.5723 153.21760</gml:pos>
</gml:Point>
</gp:location-info>
</gp:geopriv>
<timestamp>2007-06-22T20:57:29Z</timestamp>
</status>
</tuple>
</presence>
Sample manual location using a point.
Jones Expires December 2, 2012 [Page 28]
Internet-Draft Signal Position Survey May 2012
<presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
xmlns:cl="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
xmlns:rel="urn:ietf:params:xml:ns:pidf:geopriv10:relative"
xmlns:dyn="urn:ietf:params:xml:ns:pidf:geopriv10:dynamic"
xmlns:gml="http://www.opengis.net/gml">
<tuple id="abcd123456">
<status>
<gp:geopriv>
<gp:location-info>
<gs:Circle srsName="urn:ogc:def:crs:EPSG::4326">
<gml:pos>42.5463 -73.2512</gml:pos>
<gs:radius uom="urn:ogc:def:uom:EPSG::9001">
5.24
</gs:radius>
</gs:Circle>
</gp:location-info>
</gp:geopriv>
<timestamp>2007-06-22T20:57:29Z</timestamp>
</status>
</tuple>
</presence>
Sample manual location using a circle with a radius to represent
error estimate.
7.3.1.1.4. Civic Location
To support adding contextual information to survey points during the
survey process, this specification includes the ability to add
extended civic addresses as defined by
the optional Contextual Location object is provided. This object
enables the capture of contextual information with resepect to a
survey point.
For example, an office building may have floors, wings, rooms, and
cubes while an amusement park will have rides, booths, food stands
and arcades. The civic address extensions provide a mechanism for
extending these attributes and maintaining interoperability.
Example of civic location:
Jones Expires December 2, 2012 [Page 29]
Internet-Draft Signal Position Survey May 2012
<presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
xmlns:cl="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
xmlns:rel="urn:ietf:params:xml:ns:pidf:geopriv10:relative"
xmlns:dyn="urn:ietf:params:xml:ns:pidf:geopriv10:dynamic"
xmlns:gml="http://www.opengis.net/gml">
<tuple id="abcd123456">
<status>
<gp:geopriv>
<gp:location-info>
<gml:Point srsName="urn:ogc:def:crs:EPSG::4326">
<gml:pos>-43.5723 153.21760</gml:pos>
</gml:Point>
<civicAddress xml:lang="en-US"
xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
xmlns:post="http://postsoftheworld.net/ns"
xmlns:ap="http://example.com/airport/5.0">
<country>US</country>
<A1>CA</A1>
<post:lamp>2471</post:lamp>
<post:pylon>AQ-374-4(c)</post:pylon>
<ap:airport>LAX</ap:airport>
<ap:terminal>Tom Bradley</ap:terminal>
<ap:concourse>G</ap:concourse>
<ap:gate>36B</ap:gate>
</civicAddress>
</gp:location-info>
</gp:geopriv>
<timestamp>2007-06-22T20:57:29Z</timestamp>
</status>
</tuple>
</presence>
The optional civicAddress object can be included in any of the
PIDF-LO objects defined above.
7.3.1.2. Raw Location Data
To support the capture and conveyance of underlying raw location
data, a common optional container is defined for the expression of
this location measurement data.
Currently only the 'GNSS' raw location type has been defined. Global
Navigation Satellite System (GNSS) readings provide location
measurements based on satellite navigation systems such as that
provided by GPS.
Rather than decomposing GNSS output during the survey, the sentences
Jones Expires December 2, 2012 [Page 30]
Internet-Draft Signal Position Survey May 2012
from the GNSS systems are transported as is allowing full downstream
processing of the data.
The type attribute specifies the GNSS system type which is
responsible for the reading, e.g. GPS.
The GPS system generally uses the NMEA 0183 [NMEA0183] protocol for
output and many systems have been built to handle this type of
output. To provide the most transparent transport mechanism, the
NMEA sentences are packaged as-is.
The possible sentence names are described below.
The REQUIRED set of sentences include:
$GPGGA - Global Positioning System Fix Data (required)
$GPGSA - GPS DOP and Active Satellites (recommended)
$GPRMC - Recommended Minimum Specific GPS/TRANSIT Data (recommended)
The remaining OPTIONAL sentences are detailed below:
$GPAAM - Waypoint Arrival Alarm
$GPALM - GPS Almanac Data<
$GPAPA - Autopilot Sentence "A"
$GPAPB - Autopilot Sentence "B"
$GPASD - Autopilot System Data
$GPBEC - Bearing & Distance to Waypoint, Dead Reckoning
$GPBOD - Bearing, Origin to Destination
$GPBWC - Bearing & Distance to Waypoint, Great Circle
$GPBWR - Bearing & Distance to Waypoint, Rhumb Line
$GPBWW - Bearing, Waypoint to Waypoint
$GPDBT - Depth Below Transducer
$GPDCN - Decca Position
$GPDPT - Depth
$GPFSI - Frequency Set Information
$GPGLC - Geographic Position, Loran-C
$GPGLL - Geographic Position, Latitude/Longitude
$GPGSV - GPS Satellites in View
$GPGXA - TRANSIT Position
$GPHDG - Heading, Deviation & Variation
$GPHDT - Heading, True
$GPHSC - Heading Steering Command
$GPLCD - Loran-C Signal Data
$GPMTA - Air Temperature (to be phased out)
$GPMTW - Water Temperature
$GPMWD - Wind Direction
$GPMWV - Wind Speed and Angle
$GPOLN - Omega Lane Numbers
Jones Expires December 2, 2012 [Page 31]
Internet-Draft Signal Position Survey May 2012
$GPOSD - Own Ship Data
$GPR00 - Waypoint active route (not standard)
$GPRMA - Recommended Minimum Specific Loran-C Data
$GPRMB - Recommended Minimum Navigation Information
$GPROT - Rate of Turn
$GPRPM - Revolutions
$GPRSA - Rudder Sensor Angle
$GPRSD - RADAR System Data
$GPRTE - Routes
$GPSFI - Scanning Frequency Information
$GPSTN - Multiple Data ID
$GPTRF - Transit Fix Data
$GPTTM - Tracked Target Message
$GPVBW - Dual Ground/Water Speed
$GPVDR - Set and Drift
$GPVHW - Water Speed and Heading
$GPVLW - Distance Traveled through the Water
$GPVPW - Speed, Measured Parallel to Wind
$GPVTG - Track Made Good and Ground Speed
$GPWCV - Waypoint Closure Velocity
$GPWNC - Distance, Waypoint to Waypoint
$GPWPL - Waypoint Location
$GPXDR - Transducer Measurements
$GPXTE - Cross-Track Error, Measured
$GPXTR - Cross-Track Error, Dead Reckoning
$GPZDA - Time & Date
$GPZFO - UTC & Time from Origin Waypoint
$GPZTG - UTC & Time to Destination Waypoint
The sentences contain the name of the sentence in the content so
there is no reason to add additional identifying information beyond
the sentence itself.
The GPS configuration may optionally be detailed in the device sensor
descriptions section.
Jones Expires December 2, 2012 [Page 32]
Internet-Draft Signal Position Survey May 2012
Example:
<rawlocation>
<gnss type="gps">
<sentences>
<type>GPGGA</type>
<value>
$GPGGA,092750.000,5321.6802,N,00630.3372,W,1,8,1.03,61.7,M,55.2,M,,*76
</value>
<type>GPGSA</type>
<value>
$GPGSA,A,3,10,07,05,02,29,04,08,13,,,,,1.72,1.03,1.38*0A
</value>
<type>GPSV</type>
<value>
$GPGSV,3,1,11,10,63,137,17,07,61,098,15,05,59,290,20,08,54,157,30*70
</value>
<type>GPSV</type>
<value>
$GPGSV,3,2,11,02,39,223,19,13,28,070,17,26,23,252,,04,14,186,14*79
</value>
<type>GPRMC</type>
<value>
$GPRMC,092750.000,A,5321.6802,N,00630.3372,W,0.02,31.66,280511,,,A*43
</value>
</sentences>
</gnss>
</rawlocation>
7.3.2. Beacons
The intent of the <beacon> object is to allow the surveyor to
identify individual beacons and specify the location of that beacon.
In other words, in a site survey where beacon A is located at x1, y1
and beacon B is located at x2, y2, this construct would allow for
that. This is for those instances where exact beacon position is
useful for the LIS to compute device locations.
Beacon Identification
<beacon type="wifi","bluetooth",...>
The beacon object allows the identification of a specific set of
beacons. A beacon is specified as an object to be used for
positioning which can be identified by a unique identifier. For
example in an Infrastructure WiFi network, the basic service set
identifier (bssid) is the 48 bit MAC address of the access point.
This specification allows for the possibility of manually identifying
Jones Expires December 2, 2012 [Page 33]
Internet-Draft Signal Position Survey May 2012
beacons and including that information in the survey.
The type attribute is required.
<beacon type="wifi">
<id>
<mac>003200A475C5</mac>
</id>
</beacon>
The elements include:
o id (required) - indicates the key(s) necessary to uniquely
identify the beacon of the given type
7.3.3. Signal Measurements
Signal-Related Measurement Data Types
A common container is defined for the expression of location
measurement data, as well as a simple means of identifying specific
types of measurement data for the purposes of requesting them.
The following example shows a measurement container with measurement
time included. A WiFi measurement is enclosed.
<lm:measurements xmlns:lm="urn:ietf:params:xml:ns:geopriv:lm"
time="2008-04-29T14:33:58">
<wifi xmlns="urn:ietf:params:xml:ns:geopriv:lm:wifi">
<ap serving="true">
<bssid>00-12-F0-A0-80-EF</bssid>
<ssid>wlan-home</ssid>
</ap>
</wifi>
</lm:measurements>
The "measurement" element is used to encapsulate measurement data
that is collected at a certain point in time. It contains time-based
attributes that are common to all forms of measurement data, and
permits the inclusion of arbitrary measurement data.
7.3.3.1. WiFi Measurements
WiFi Measurements are based on the proposed measurements defined in
the IETF I-D Held Measurements [I-D.ietf-geopriv-held-measurements]
document.
In WiFi, or 802.11 [IEEE.80211.2007], networks a Device might be able
Jones Expires December 2, 2012 [Page 34]
Internet-Draft Signal Position Survey May 2012
to provide information about the access point (AP) that it is
attached to, or other WiFi points it is able to see. This is
provided using the "wifi" element, as shown in Figure 6, which shows
a single complete measurement for a single access point.
WiFi scan elements contain a single record for each Access Point
which was scanned for each time stamp that that AP was scanned.
APs should be scanned as rapidly as feasible to obtain as many
samples as possible.
Jones Expires December 2, 2012 [Page 35]
Internet-Draft Signal Position Survey May 2012
<measurements xmlns="urn:ietf:params:xml:ns:geopriv:lm"
time="2011-04-29T14:33:58">
<wifi xmlns="urn:ietf:params:xml:ns:geopriv:lm:wifi">
<nicType>Intel(r)PRO/Wireless 2200BG</nicType>
<ap serving="true">
<bssid>AB-CD-EF-AB-CD-EF</bssid>
<ssid>example</ssid>
<channel>5</channel>
<location>
<gml:Point xmlns:gml="http://opengis.net/gml">
<gml:pos>-34.4 150.8</gml:pos>
</gml:Point>
</location>
<type>a</type>
<band>5</band>
<regclass country="AU">2</regclass>
<antenna>2</antenna>
<flightTime rmsError="4e-9" samples="1">2.56e-9</flightTime>
<apSignal>
<transmit>23</transmit>
<gain>5</gain>
<rcpi dBm="true" rmsError="12" samples="1">-59</rcpi>
<rsni rmsError="15" samples="1">23</rsni>
</apSignal>
<deviceSignal>
<transmit>10</transmit>
<gain>9</gain>
<rcpi dBm="true" rmsError="9.5" samples="1">-98.5</rcpi>
<rsni rmsError="6" samples="1">7.5</rsni>
</deviceSignal>
</ap>
</wifi>
</measurements>
802.11 WiFi Measurement Example
A wifi element is made up of one or more access points, and an
optional "nicType" element. Each access point is described using the
"ap" element, which is comprised of the following fields:
Required:
o bssid: The basic service set identifier. In an Infrastructure BSS
network, the bssid is the 48 bit MAC address of the access point.
The "verified" attribute of this element describes whether the
device has verified the MAC address or it authenticated the access
point or the network operating the access point (for example, a
Jones Expires December 2, 2012 [Page 36]
Internet-Draft Signal Position Survey May 2012
captive portal accessed through the access point has been
authenticated). This attributes defaults to a value of "false"
when omitted.
o rcpi: The received channel power indicator for the access point
signal, as measured by the Device. This value SHOULD be in units
of dBm (with RMS error in dB). If power is measured in a
different fashion, the "dBm" attribute MUST be set to "false".
Signal strength reporting on current hardware uses a range of
different mechanisms; therefore, the value of the "nicType"
element SHOULD be included if the units are not known to be in dBm
and the value reported by the hardware should be included without
modification. This element includes optional "rmsError" and
"samples" attributes.
Optional (as defined in the IETF I-D Held Measurements
[I-D.ietf-geopriv-held-measurements] document.
o ssid
o channe
o location
o type
o band
o regclass
o antenna
o flightTime
o apSignal
7.3.3.2. Bluetooth Measurements
Note: these need to be clarified and added to held-measurements.
Bluetooth devices provide an alternative method for determining
location. The bluetooth object provides a method to capture
measurements related to bluetooth devices discovered during the
survey.
o Address/UUID - 48-bit unique identifier
Jones Expires December 2, 2012 [Page 37]
Internet-Draft Signal Position Survey May 2012
o Name
o Version
o Manufacturer
o Features
o Class
o Signal Strength
o Link Quality
7.3.3.3. Other Signal Measurements
The container allows for the definition of other measurements to be
captured. These could include measurements of such things as sound
ranging or echolocation signals, cellular signals, or other
electromagnetic signal measurement.
8. Example Surveys
Below are examples of several types of surveys.
8.1. WiFi Access Point Location Survey
A simple example of a small survey composed of two survey points is
illustrated by the example message below. This uses the static
beacon key survey model.
<sigpos xmlns="jones:sigpos"
xmlns:pidf="urn:ietf:params:xml:ns:pidf"
xmlns:cl="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
xmlns:dyn="urn:ietf:params:xml:ns:pidf:geopriv10:dynamic"
xmlns:rel="urn:ietf:params:xml:ns:pidf:geopriv10:relative"
xmlns:vc="urn:ietf:params:xml:ns:vcard-4.0"
xmlns:ap="http://example.com/airport/5.0"
xmlns:gml="http://www.opengis.net/gml">
<session sessionID=?axxwe82737?>
<venue>
<vc:vcard>
<vc:fn><vc:text>Example Building</vc:text></vc:fn>
<vc:adr>
<vc:parameters>
Jones Expires December 2, 2012 [Page 38]
Internet-Draft Signal Position Survey May 2012
<vc:type><vc:text>work</vc:text></vc:type>
<vc:label><vc:text>Example Building
1 South Boston Street
Boston, MA USA 02210</vc:text></vc:label>
</pvc:arameters>
<vc:pobox/>
<vc:ext/>
<vc:street>1 South Boston Street</vc:street>
<vc:locality>Boston</vc:locality>
<vc:region>MA</vc:region>
<vc:code>02210</vc:code>
<vc:country>USA</vc:country>
</vc:adr>
</vc:vcard>
<owner>
<vc:vcard>
<vc:fn><text>Rober Builder</vc:text></vc:fn>
<vc:n>
<vc:surname>Builder</vc:surname>
<vc:given>Robert</vc:given>
<vc:additional/>
<vc:prefix/>
<vc:suffix/>
</vc:n>
<vc:adr>
<vc:parameters>
<vc:type><text>work</vc:text></vc:type>
<vc:label><text>Rober Builder
1 South Boston Street
Boston, MA USA 02210</vc:text></vc:label>
</vc:parameters>
<vc:pobox/>
<vc:ext/>
<vc:street>1 South Boston Street</vc:street>
<vc:locality>Boston</vc:locality>
<vc:region>MA</vc:region>
<vc:code>02210</vc:code>
<vc:country>USA</vc:country>
</vc:adr>
<vc:tel>
<vc:parameters>
<vc:type>
<vc:text>work</vc:text>
<vc:text>voice</vc:text>
</vc:type>
</vc:parameters>
<vc:uri>tel:+1-555-555-1212;ext=102</vc:uri>
</vc:tel>
Jones Expires December 2, 2012 [Page 39]
Internet-Draft Signal Position Survey May 2012
<vc:email>
<vc:parameters>
<type><text>work</vc:text></vc:type>
</vc:parameters>
<vc:text>reober.builder@example.com</vc:text>
</vc:email>
</vc:vcard>
</owner>
<license>
<license-type>CC BY</license-type>
</license>
</venue>
<survey>
<survey-point>
<groundtruth>
<pidf:presence>
<pidf:tuple id="abcd123456">
<pidf:status>
<gp:geopriv>
<gp:location-info>
<gml:Point xmlns:gml="http://opengis.net/gml">
<gml:pos>-34.4 150.8</gml:pos>
</gml:Point>
<cl:civicAddress>
<cl:country>US</cl:country>
<cl:A1>CA</cl:A1>
<ap:airport>LAX</ap:airport>
<ap:terminal>Tom Bradley</ap:terminal>
<ap:concourse>G</ap:concourse>
<ap:gate>36B</ap:gate>
</civicAddress>
</gp:location-info>
</gp:geopriv>
<pidf:timestamp>2012-02-21T14:33:58:05</pidf:timestamp>
</pidf:status>
</pidf:tuple>
</pidf:presence>
</groundtruth>
<beacon type="wifi">
<mac>FF00FF723CBA</mac>
<mac>FF00FF723CBB</mac>
</beacon>
</survey-point>
<survey-point>
<groundtruth>
<pidf:presence>
<pidf:tuple id="abcd123456">
<pidf:status>
Jones Expires December 2, 2012 [Page 40]
Internet-Draft Signal Position Survey May 2012
<gp:geopriv>
<gp:location-info>
<gml:Point xmlns:gml="http://opengis.net/gml">
<gml:pos>-34.35 150.83</gml:pos>
</gml:Point>
</gp:location-info>
</gp:geopriv>
<pidf:timestamp>2012-02-21T14:33:58:06</pidf:timestamp>
</pidf:status>
</pidf:tuple>
</pidf:presence>
</groundtruth>
<beacon type="wifi">
<mac>FF00FF723A00</mac>
</beacon>
</survey-point>
</survey>
</session>
</sigpos>
802.11 WiFi Beacon Survey
8.2. WiFi Signal Survey
A simple example of wifi scan data conveyance using gps for ground
truth is illustrated by the example message below.
<sigpos xmlns="jones:sigpos"
xmlns:pidf="urn:ietf:params:xml:ns:pidf"
xmlns:cl="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
xmlns:dyn="urn:ietf:params:xml:ns:pidf:geopriv10:dynamic"
xmlns:rel="urn:ietf:params:xml:ns:pidf:geopriv10:relative"
xmlns:vc="urn:ietf:params:xml:ns:vcard-4.0"
xmlns:ap="http://example.com/airport/5.0"
xmlns:gml="http://www.opengis.net/gml">
<session sessionID="axxwe82737">
<venue>
<vc:vcard>
<vc:fn><vc:text>Example Building</vc:text></vc:fn>
<vc:adr>
<vc:parameters>
<vc:type><vc:text>work</vc:text></vc:type>
<vc:label><vc:text>Example Building
1 South Boston Street
Boston, MA USA 02210</vc:text></vc:label>
Jones Expires December 2, 2012 [Page 41]
Internet-Draft Signal Position Survey May 2012
</pvc:arameters>
<vc:pobox/>
<vc:ext/>
<vc:street>1 South Boston Street</vc:street>
<vc:locality>Boston</vc:locality>
<vc:region>MA</vc:region>
<vc:code>02210</vc:code>
<vc:country>USA</vc:country>
</vc:adr>
</vc:vcard>
<owner>
<vc:vcard>
<vc:fn><text>Rober Builder</vc:text></vc:fn>
<vc:n>
<vc:surname>Builder</vc:surname>
<vc:given>Robert</vc:given>
<vc:additional/>
<vc:prefix/>
<vc:suffix/>
</vc:n>
<vc:adr>
<vc:parameters>
<vc:type><text>work</vc:text></vc:type>
<vc:label><text>Rober Builder
1 South Boston Street
Boston, MA USA 02210</vc:text></vc:label>
</vc:parameters>
<vc:pobox/>
<vc:ext/>
<vc:street>1 South Boston Street</vc:street>
<vc:locality>Boston</vc:locality>
<vc:region>MA</vc:region>
<vc:code>02210</vc:code>
<vc:country>USA</vc:country>
</vc:adr>
<vc:tel>
<vc:parameters>
<vc:type>
<vc:text>work</vc:text>
<vc:text>voice</vc:text>
</vc:type>
</vc:parameters>
<vc:uri>tel:+1-555-555-1212;ext=102</vc:uri>
</vc:tel>
<vc:email>
<vc:parameters>
<type><text>work</vc:text></vc:type>
</vc:parameters>
Jones Expires December 2, 2012 [Page 42]
Internet-Draft Signal Position Survey May 2012
<vc:text>reober.builder@example.com</vc:text>
</vc:email>
</vc:vcard>
</owner>
<license>
<license-type>unrestricted</license-type>
<licenseExpiry>2012-10-29T14:33:58</licenseExpiry>
</license>
</venue>
<device>
<configuration>
<id>00EFDA7200B004</id>
<name>lumina</name>
<type>smartphone</type>
<model>900</model>
<version>1.2</version>
</configuration>
<sensor>
<configuration>
<type>wifi</type>
<id>ath0</id>
<antenna>omni-directional</antenna>
<chipset>aetheros</chipset>
<manufacturer>newco</manufacturer>
<capabilities>
<standard>a,b,g,n</standard>
<frequencyband>1-13</frequencyband>
</capabilities>
</configuration>
</sensor>
<sensor>
<configuration>
<type>gps</type>
<id>gps3210</id>
<antenna>combined</antenna>
<chipset>qualcomm</chipset>
<manufacturer>newco</manufacturer>
<capabilities>
<type>standard</type>
</capabilities>
</configuration>
</sensor>
</device>
<survey>
<survey-point>
<groundtruth>
<pidf:presence>
<pidf:tuple id="abcd123456">
Jones Expires December 2, 2012 [Page 43]
Internet-Draft Signal Position Survey May 2012
<pidf:status>
<gp:geopriv>
<gp:location-info>
<gml:Point xmlns:gml="http://opengis.net/gml">
<gml:pos>-34.35 150.83</gml:pos>
</gml:Point>
</gp:location-info>
</gp:geopriv>
<pidf:timestamp>2012-02-21T14:33:58:06</pidf:timestamp>
</pidf:status>
</pidf:tuple>
</pidf:presence>
<rawlocation>
<gnss type="gps">
<sentences>
<type>GPGGA</type>
<value>
$GPGGA,092750.000,5321.6802,N,00630.3372,W,1,8,1.03,61.7,M,55.2,M,,*76
</value>
<type>GPGSA</type>
<value>
$GPGSA,A,3,10,07,05,02,29,04,08,13,,,,,1.72,1.03,1.38*0A
</value>
<type>GPSV</type>
<value>
$GPGSV,3,1,11,10,63,137,17,07,61,098,15,05,59,290,20,08,54,157,30*70
</value>
<type>GPSV</type>
<value>
$GPGSV,3,2,11,02,39,223,19,13,28,070,17,26,23,252,,04,14,186,14*79
</value>
<type>GPRMC</type>
<value>
$GPRMC,092750.000,A,5321.6802,N,00630.3372,W,0.02,31.66,280511,,,A*43
</value>
</sentences>
</gnss>
</rawlocation>
</groundtruth>
<lm:measurements xmlns:lm="urn:ietf:params:xml:ns:geopriv:lm"
time="2008-04-29T14:33:58">
<wifi xmlns="urn:ietf:params:xml:ns:geopriv:lm:wifi">
<ap serving="true">
<bssid>00-12-F0-A0-80-EF</bssid>
<ssid>wlan-home</ssid>
<rcpi>-85</rcpi>
</ap>
<ap>
Jones Expires December 2, 2012 [Page 44]
Internet-Draft Signal Position Survey May 2012
<bssid>00-11-F0-A0-80-EF</bssid>
<ssid>wlan-other</ssid>
<rcpi>-92</rcpi>
</ap>
</wifi>
</lm:measurements>
</survey-point>
</survey>
</session>
</sigpos>
802.11 WiFi Signal Scan Survey
9. Acknowledgements
This template was derived from an initial version written by Pekka
Savola and contributed by him to the xml2rfc project. Thanks to
Richard Barnes and Stephane Terrenoir for initial reviews and
valuable feedback.
10. IANA Considerations
This section creates a registry for Data License types
(Section 7.1.3.3) and registers the namesapces and schema defined in
the Schemas (Section 11) secction.
All drafts are required to have an IANA considerations section (see
the update of RFC 2434 [RFC5226] for a guide). If the draft does not
require IANA to do anything, the section contains an explicit
statement that this is the case (as above). If there are no
requirements for IANA, the section will be removed during conversion
into an RFC by the RFC Editor.
10.1. IANA Registry for Data License Types
This document establishes a new IANA registry for the for Data
License types (Section 7.1.3.3). This reegistry includes tokens for
the Data License type. Referring to the [RFC5226], this registry
operates under "Specification Required" rules. The IESG will appoint
an Expert Review who will advice IANA promptly on each request for a
new or updated Data License type.
Each entry in the registry requires the following information:
Jones Expires December 2, 2012 [Page 45]
Internet-Draft Signal Position Survey May 2012
o Data License name: the name of the data license
o Brief Description: a brief description of the data license
o URI: optional URI to the license definition
This section pre-registers 8 new 'licenseType' tokens associated with
the 'licenseType'
unrestricted: allows for the use and unrestricted derivative products
based on the data set
1. unrestricted: this license allows for the use and unrestricted
derivative products based on the data set
2. CC BY: this license lets others distribute, remix, tweak, and
build upon your work, even commercially, as long as they credit
you for the original creation.
3. CC BY-ND: this license allows for redistribution, commercial and
non-commercial, as long as it is passed along unchanged and in
whole, with credit to you.
4. CC BY-NC-SA: this license lets others remix, tweak, and build
upon your work non-commercially, as long as they credit you and
license their new creations under the identical terms.
5. CC BY-SA: this license lets others remix, tweak, and build upon
your work even for commercial purposes, as long as they credit
you and license their new creations under the identical terms.
6. CC BY-NC: this license lets others remix, tweak, and build upon
your work even for commercial purposes, as long as they credit
you and license their new creations under the identical terms.
7. CC BY-NC-ND: this license is the most restrictive of our six main
licenses, only allowing others to download your works and share
them with others as long as they credit you, but they can't
change them in any way or use them commercially.
8. private: this license is intended to provide full control over
the ownership, usage, and derivative usage of the data. Any use
of the data would be governed under a separate agreement between
the owner and the party wishing to make use of the data. By
default, no rights are granted for private data.
Jones Expires December 2, 2012 [Page 46]
Internet-Draft Signal Position Survey May 2012
11. Schemas
This section provides a formal definition of the combined XML schema
for encoding survey data.
12. Security Considerations
Location-related measurement data can be as privacy sensitive as
location information.
Survey data is effectively equivalent to location information if the
contextual knowledge necessary to generate one from the other is
readily accessible. Even where contextual knowledge is difficult to
acquire, there can be no assurance that an authorized recipient of
the contextual knowledge is also authorized to receive location
information.
In order to protect the privacy of the subject of location-related
survey data, this implies that survey data is protected with a
similar degree of protection as location information.
Survey Data Privacy Model
In general, survey data represents a smaller privacy risk than
personal location information. It does however represent potential
privacy risks especially with respect to venues which have security
risks or wish to maintain control over the exposure of detailed
location information.
No entity is permitted to redistribute survey data except as
specified in the data license. The Device directs other entities in
how survey data is used and retained.
13. References
13.1. Normative References
[I-D.ietf-geopriv-held-measurements]
Thomson, M. and J. Winterbottom, "Using Device-provided
Location-Related Measurements in Location Configuration
Protocols", draft-ietf-geopriv-held-measurements-04 (work
in progress), October 2011.
[I-D.ietf-geopriv-local-civic]
Winterbottom, J., Thomson, M., Barnes, R., Rosen, B., and
R. George, "Specifying Civic Address Extensions in
Jones Expires December 2, 2012 [Page 47]
Internet-Draft Signal Position Survey May 2012
PIDF-LO", draft-ietf-geopriv-local-civic-03 (work in
progress), February 2012.
[I-D.ietf-geopriv-relative-location]
Thomson, M., Stanley, D., Rosen, B., Thomson, A., and G.
Bajko, "Relative Location Representation",
draft-ietf-geopriv-relative-location-02 (work in
progress), October 2011.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object
Format", RFC 4119, December 2005.
[RFC5139] Thomson, M. and J. Winterbottom, "Revised Civic Location
Format for Presence Information Data Format Location
Object (PIDF-LO)", RFC 5139, February 2008.
[RFC5491] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV
Presence Information Data Format Location Object (PIDF-LO)
Usage Clarification, Considerations, and Recommendations",
RFC 5491, March 2009.
[RFC5962] Schulzrinne, H., Singh, V., Tschofenig, H., and M.
Thomson, "Dynamic Extensions to the Presence Information
Data Format Location Object (PIDF-LO)", RFC 5962,
September 2010.
[RFC6351] Perreault, S., "xCard: vCard XML Representation",
RFC 6351, August 2011.
13.2. Informative References
[CC] Creative Commons, "Creative Commons LIcenses", 2012,
<https://creativecommons.org/licenses/>.
[GeoShape]
"GML GeoShape Application Schema for use in internet
standards developed by the IETF", 2006, <http://
portal.opengeospatial.org/files/?artifact_id=17591>.
[IEEE.80211.2007]
"Information technology - Telecommunications and
information exchange between systems - Local and
metropolitan area networks - Specific requirements - Part
11: Wireless LAN Medium Access Control (MAC) and Physical
Layer (PHY) specifications", 2007, <http://
Jones Expires December 2, 2012 [Page 48]
Internet-Draft Signal Position Survey May 2012
standards.ieee.org/getieee802/download/802.11-2007.pdf>.
[NMEA0183]
"NMEA 0183", 2007,
<http://www.nmea.org/pub/0183/index.html>.
[OGC-GML3.1.1]
"Geography Markup Language (GML) 3.1.1", 2003,
<http://www.opengeospatial.org/standards/gml>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
[RFC5774] Wolf, K. and A. Mayrhofer, "Considerations for Civic
Addresses in the Presence Information Data Format Location
Object (PIDF-LO): Guidelines and IANA Registry
Definition", BCP 154, RFC 5774, March 2010.
Author's Address
Kipp Jones
Skyhook Wireless
34 Farnsworth Street
Boston, 02210
US
Phone: +1 (617) 234-9802
Email: kjones@skyhookwireless.com
Jones Expires December 2, 2012 [Page 49]