Internet DRAFT - draft-jones-geopriv-sigpos-survey
draft-jones-geopriv-sigpos-survey
Geographic Location/Privacy K. Jones
Internet-Draft C. Steger
Intended status: Standards Track Skyhook Wireless
Expires: November 10, 2013 May 09, 2013
Indoor Signal Position Conveyance
draft-jones-geopriv-sigpos-survey-02
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 November 10, 2013.
Jones & Steger Expires November 10, 2013 [Page 1]
Internet-Draft Signal Position Survey May 2013
Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Description . . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Using PIDF-LO Location . . . . . . . . . . . . . . . . . . . 9
5.1. Device Orientation . . . . . . . . . . . . . . . . . . . 10
6. Session . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
6.1. Venue . . . . . . . . . . . . . . . . . . . . . . . . . . 12
6.1.1. Venue Name/Address . . . . . . . . . . . . . . . . . 13
6.1.2. Licensor . . . . . . . . . . . . . . . . . . . . . . 13
6.1.3. Data Rights Management . . . . . . . . . . . . . . . 14
6.1.3.1. License Expiry . . . . . . . . . . . . . . . . . 15
6.1.3.2. License URI . . . . . . . . . . . . . . . . . . . 15
6.1.3.3. License Type . . . . . . . . . . . . . . . . . . 15
6.1.4. Map Metadata . . . . . . . . . . . . . . . . . . . . 17
6.2. Survey Device . . . . . . . . . . . . . . . . . . . . . . 18
6.2.1. Configuration Object . . . . . . . . . . . . . . . . 18
6.2.2. Example Device Configuration . . . . . . . . . . . . 20
6.3. Survey Data . . . . . . . . . . . . . . . . . . . . . . . 21
6.3.1. Ground Truth . . . . . . . . . . . . . . . . . . . . 22
6.3.1.1. PIDF-LO Location . . . . . . . . . . . . . . . . 23
6.3.1.2. Raw Location Data . . . . . . . . . . . . . . . . 28
6.3.2. Beacons . . . . . . . . . . . . . . . . . . . . . . . 31
6.3.3. Signal Measurements . . . . . . . . . . . . . . . . . 31
6.3.3.1. WiFi Measurements . . . . . . . . . . . . . . . . 32
6.3.3.2. Bluetooth Measurements . . . . . . . . . . . . . 34
6.3.3.3. Other Signal Measurements . . . . . . . . . . . . 34
7. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . 35
8. Security Considerations . . . . . . . . . . . . . . . . . . . 40
8.1. Assuring That the Proper LIS Has Been Contacted . . . . . 40
Jones & Steger Expires November 10, 2013 [Page 2]
Internet-Draft Signal Position Survey May 2013
8.2. Protecting Responses from Modification . . . . . . . . . 41
9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 41
9.1. Example of a WiFi Access Point Location Survey . . . . . 41
9.2. Example of a WiFi Signal Survey . . . . . . . . . . . . . 45
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 48
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 49
11.1. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:geopriv:sigpos . . . . . . . . . 49
11.2. XML Schema Registration . . . . . . . . . . . . . . . . 49
11.3. MIME Media Type Registration for
'application/sigpos+xml' . . . . . . . . . . . . . . . . 50
11.4. IANA Registry for Data License Types . . . . . . . . . . 51
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 52
12.1. Normative References . . . . . . . . . . . . . . . . . . 52
12.2. Informative References . . . . . . . . . . . . . . . . . 53
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 54
1. Introduction
This document describes a format for the expression of the
measurements and locations 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 for
purposes of this document.
A positioning beacon (hereafter referred to as a beacon) is a fixed
wireless device whose location and signal information may be used for
the purpose of positioning other wireless devices.
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.
Jones & Steger Expires November 10, 2013 [Page 3]
Internet-Draft Signal Position Survey May 2013
In addition to the signal information, an 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.
This document describes the use of HTTP/TLS as transport for the
survey data.
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 or constrain 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 rights
of usage for 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 and environmental signals for purposes
of providing 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
Jones & Steger Expires November 10, 2013 [Page 4]
Internet-Draft Signal Position Survey May 2013
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'. Specialized hardware with
professional grade GPS systems, highly calibrated sensors for dead
reckoning, laser range finders or other techniques have often 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
process has several drawbacks:
o the use of specialized hardware by highly trained engineers is
expensive. Scalability is reduced by requiring the design and
manufacture of specialized hardware as well as trained individuals
to operate the hardware
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 to a vendor. 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
Jones & Steger Expires November 10, 2013 [Page 5]
Internet-Draft Signal Position Survey May 2013
investment, the venue owner may be excluded from additional value
in the future
o high quality venue maps have not been readily accessible. Having
location is an important part of the puzzle, but having the
ability to lock the location to a map enables a wide range of
applications
o mobile devices and applications have traditionally been locked to
the vendor who performed the site survey. This made it nearly
impossible to scale across different applications and mobile
platforms
o context is generally more important for indoor positioning than
latitude, longitude, and altitude. 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
o there is no common way to convey the information to a LIS
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.
3. Open Issues
This document contains a number of open issues that need to be
addressed or items that need further refinement, including:
1. Survey Device Configuration Specification - this needs continued
refinement
2. Bluetooth Measurements - these need to be added to the HELD
Measurements specification
3. Specification of Licensing Options - are there more objections to
including these
4. Complete xsd definition - a partial XSD is included in this
draft, a complete specification is still needed
5. Explore use of draft-jennings-senml-10 (Media Types for Sensor
Markup Language (SENML)) for sensor data encoding
6. Update 802.11 to use 802.11-2012 spec for country code
4. Description
Jones & Steger Expires November 10, 2013 [Page 6]
Internet-Draft Signal Position Survey May 2013
The basic premise for the SigPos data container is to record 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 and their locations.
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
downstream algorithms to make appropriate choices.
This document also describes the use of HTTP/TLS as transport for the
survey container.
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 licensor organization as well as the data rights applicable to
the survey. The Venue Section (Section 6.1) describes the venue or
location of the survey, and the Survey Device section (Section 6.2)
describes the device being used to capture the survey data.
The Survey Data section (Section 6.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.
Jones & Steger Expires November 10, 2013 [Page 7]
Internet-Draft Signal Position Survey May 2013
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 & Steger Expires November 10, 2013 [Page 8]
Internet-Draft Signal Position Survey May 2013
+---------------+
__| Name |
| |_______________|
|
+-----------+ | +---------------+
__| Venue |__|_| Address |
| |___________| | |_______________+ +--------------+
| | _| Name |
| | +---------------+ | |______________|
| |_| Licensor |__|
| | |_______________| | +--------------+
| | |_| Address |
| | +---------------+ |______________|
| |_| License |
| |_______________|
+---------+ |
| Session | -|
|_________| |
| +---------------+
| __| Configuration |
| | |_______________|
| |
| +-----------+ | +---------------+ +--------------+
|_| Survey |__|_| Survey |____| Sensor |__
| | Device | | Sensors | |______________|
| |___________| |_______________|
|
| +--------------+
| __| Ground Truth |__
| | |______________|
| |
| +-----------+ +---------------+ | +--------------+
+-| Survey |____| Survey Point |__|_| Beacons |__
|___________| |_______________| | |______________|
|
| +--------------+
|_| Measurements |__
|______________|
Document structure overview.
Figure 1
5. Using PIDF-LO Location
All location information in this container is specified using the
GEOPRIV Presence Information Data Format Location Object. This
Jones & Steger Expires November 10, 2013 [Page 9]
Internet-Draft Signal Position Survey May 2013
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
[RFC6848].
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
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.
5.1. Device Orientation
Jones & Steger Expires November 10, 2013 [Page 10]
Internet-Draft Signal Position Survey May 2013
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:
<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>
Jones & Steger Expires November 10, 2013 [Page 11]
Internet-Draft Signal Position Survey May 2013
6. 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.
SessionID: contains an opaque string which provides a Universally
Unique Identifier (UUID) identifier for this survey as defined by
RFC4122 [RFC4122]A Universally Unique IDentifier (UUID) URN
Namespace.
SessionDate: contains the date the survey was completed.
<session sessionID="99FD84B9-8C0F-4E5E-B050-4E6B3D5C5D9F" sessionDate="2009-06-22T20:57:29Z">
...
</session>
6.1. Venue
The venue section describes the venue itself and also provides for
two additional elements: the definition of the licensor and the
definition of the policy for the included data.
+----------------+
| Venue xCard |
__| Name/Address |
| |________________|
|
+-----------+ | +----------------+
| Venue |__|_| Licensor xCard |
|___________| | | Name/Address |
| |________________|
|
| +----------------+
|_| License |
| |________________|
|
| +----------------+
|_| Map Metadata |
|________________|
Venue structure overview.
Figure 2
Jones & Steger Expires November 10, 2013 [Page 12]
Internet-Draft Signal Position Survey May 2013
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.
6.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.
<?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>s
<vc:code>02210</vc:code>
<vc:country>USA</vc:country>
</vc:adr>
</vc:vcard>
</vcards>
6.1.2. Licensor
The optional licensor section allows for the definition of the
organization or individual that has the right to grant another
individual or entity a license to the data. The licensor section
also makes use of the xCard [RFC6351] format for encoding information
about the name and address of the licensor entity.
<?xml version="1.0" encoding="UTF-8"?>
<vcards xmlns:vc="urn:ietf:params:xml:ns:vcard-4.0">
<vc:vcard>
<vc:fn><text>Robert Builder</vc:text></vc:fn>
<vc:n>
<vc:surname>Builder</vc:surname>
Jones & Steger Expires November 10, 2013 [Page 13]
Internet-Draft Signal Position Survey May 2013
<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>Robert 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>robert.builder@example.com</vc:text>
</vc:email>
</vc:vcard>
</vcards>
6.1.3. Data Rights Management
The license object allows the licensor the ability to manage and
grant usage rights to the survey data. This document includes a
mechanism for including 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.
Jones & Steger Expires November 10, 2013 [Page 14]
Internet-Draft Signal Position Survey May 2013
6.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>
6.1.3.2. License URI
The License URI provides an optional element to identify the terms of
a 'Private' license type. This allows the incorporation of
additional information relating to the definition of the license
terms.
6.1.3.3. License Type
The optional policy element is intended to allow the licensor of the
data gathered for a given venue to provide granular control over the
use and subsequent derivative works based on the data. 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.
6.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 remain valid.
Example of an unrestricted license delcaration:
<license>
<licenseExpiry>2008-04-29T14:33:58</licenseExpiry>
<licenseType>unrestricted</licenseType>
</license>
6.1.3.3.2. Creative Commons License
The Creative Commons [CC] provide a number of licensing options
which, in some cases, permit the licensor of the data to restrict
commercial use and/or derivative works. Derivative use of survey
data refers to the ability to build or improve a location system
based on survey data. Survey data at a high quality could be used to
Jones & Steger Expires November 10, 2013 [Page 15]
Internet-Draft Signal Position Survey May 2013
'seed' a location system, allowing an organization to bootstrap a
location database over time. At some point, the original data could
be removed but the derived database would allow the system to
continue to be functional. For data licensors who wish to protect
from this, the notion of derivative rights is included in the license
structure.
Valid Creative Common license types for this specification include
the following.
For non-commercial use:
o Attribution-NonCommercial-ShareAlike CC BY-NC-SA - This license
lets others remix, tweak, and build upon the licensor's work non-
commercially, as long as they credit the licensor and license
their new creations under the identical terms.
o Attribution-NonCommercial CC BY-NC - This license lets others
remix, tweak, and build upon the licensor's work non-commercially,
and although their new works must also acknowledge the licensor
and be non-commercial, they don't have to license their derivative
works on the same terms.
o Attribution-NonCommercial-NoDerivs CC BY-NC-ND - This license only
allows others to use the licensor's works and share them with
others as long as they credit the licensor, but they can't change
them in any way or use them commercially.
For commercial use:
o Attribution CC BY - This license lets others distribute, remix,
tweak, and build upon the licensor's work, even commercially, as
long as they credit the licensor for the original creation.
o Attribution-NoDerivs 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 the licensor.
o Attribution-ShareAlike CC BY-SA - This license lets others remix,
tweak, and build upon the licensor's work even for commercial
purposes, as long as they credit the licensor and license their
new creations under the identical terms.
<license>
<licenseExpiry>2008-04-29T14:33:58</licenseExpiry>
<licenseType>CC BY-ND</licenseType>
</license>
Jones & Steger Expires November 10, 2013 [Page 16]
Internet-Draft Signal Position Survey May 2013
6.1.3.3.3. Private License
The private license is intended to provide full control over the
usage and derivative usage of the data. Any use of the data would be
governed under a separate agreement between the licensor and the
party wishing to make use of the data. By default, no rights are
granted for private data.
For example, suppose a venue owner wishes to provide location
services within their venue, but only for their own application. The
arrangment for providing this service could be managed separately
from the protocol. However, the data itself is fully transportable
and allows for the venue owner to reprovision the service with a
different provider if they so desire. Service providers without an
arrangement could automatically determine that this data cannot be
used.
<license>
<licenseType>private</licenseType>
<licenseURI>http://www.example.com/mylicense.html</licenseURI>
<licenseExpiry>2008-04-29T14:33:58</licenseExpiry>
</license>
6.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>
Jones & Steger Expires November 10, 2013 [Page 17]
Internet-Draft Signal Position Survey May 2013
6.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.
_+-------------+ +-----------------+
| | Hardware |____|| Configuration ||
| |_____________| ||_______________||
|
|_+-------------+ +-----------------+
| | Software |____|| Configuration ||
| |_____________| ||_______________||
+---------+ |
| Survey |__|
| Device | |
|_________| | +-------------+ +-------------+ +-----------------+
|_| Sensor (0-n)|____| Hardware |___|| Configuration ||
|_____________| | |_____________| ||_______________||
|
| +-------------+ +-----------------+
|_| Software |___|| Configuration ||
|_____________| ||_______________||
Survey Device structure overview.
Figure 3
6.2.1. Configuration Object
+-----------------+
__| Type |
| |_________________|
|
| +-----------------+
|_| Id |
| |_________________|
|
| +-----------------+
|_| Name |
| |_________________|
Jones & Steger Expires November 10, 2013 [Page 18]
Internet-Draft Signal Position Survey May 2013
+-----------------+ |
| 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.
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.
Jones & Steger Expires November 10, 2013 [Page 19]
Internet-Draft Signal Position Survey May 2013
6.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>
<capability name="chipset">Intel Q965</capability>
<capability 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>atheros</vendor>
<capability name="antenna">omni-directional</capability>
<capability name="gain" units="dbm">10</capability>
<capability name="chipset">atheros</capability>
<capability name="standard">a,b,g,n</capability>
<capability name="channel">1-13</capability>
</capabilities>
</configuration>
</hardware>
<software>
<configuration>
<name>atheros driver</name>
<version>ath9k</version>
</configuration>
</software>
</sensor>
<sensor>
Jones & Steger Expires November 10, 2013 [Page 20]
Internet-Draft Signal Position Survey May 2013
<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>
6.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
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 |__
Jones & Steger Expires November 10, 2013 [Page 21]
Internet-Draft Signal Position Survey May 2013
|_____________| |_______________| | |______________|
|
| +--------------+
|_| 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.
6.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.
groundTruth MUST have at least 1 SurveyPoint object as defined below.
+----------------+ +----------+
_| Basic Location |- -| Civic |
| |________________| | Location |
+-------------+ | |__________|
| GroundTruth |___| +----------------+
|_____________| |_| Raw Location |
| Data |
|________________|
Groundtruth structure overview.
Figure 6
Jones & Steger Expires November 10, 2013 [Page 22]
Internet-Draft Signal Position Survey May 2013
6.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 Trilateration
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.
6.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].
<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>
Jones & Steger Expires November 10, 2013 [Page 23]
Internet-Draft Signal Position Survey May 2013
<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>
6.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.
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.
<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>
Jones & Steger Expires November 10, 2013 [Page 24]
Internet-Draft Signal Position Survey May 2013
<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>
6.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].
Jones & Steger Expires November 10, 2013 [Page 25]
Internet-Draft Signal Position Survey May 2013
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.
<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>
Jones & Steger Expires November 10, 2013 [Page 26]
Internet-Draft Signal Position Survey May 2013
</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.
6.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. 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:
<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>
Jones & Steger Expires November 10, 2013 [Page 27]
Internet-Draft Signal Position Survey May 2013
<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.
6.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
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:
Jones & Steger Expires November 10, 2013 [Page 28]
Internet-Draft Signal Position Survey May 2013
$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
$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
Jones & Steger Expires November 10, 2013 [Page 29]
Internet-Draft Signal Position Survey May 2013
$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.
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>
Jones & Steger Expires November 10, 2013 [Page 30]
Internet-Draft Signal Position Survey May 2013
6.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
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
6.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">
Jones & Steger Expires November 10, 2013 [Page 31]
Internet-Draft Signal Position Survey May 2013
<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.
6.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
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.
<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/g</type>
<band>5</band>
<regclass country="AU">2</regclass>
Jones & Steger Expires November 10, 2013 [Page 32]
Internet-Draft Signal Position Survey May 2013
<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
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.
Jones & Steger Expires November 10, 2013 [Page 33]
Internet-Draft Signal Position Survey May 2013
Optional (as defined in the IETF I-D Held Measurements
[I-D.ietf-geopriv-held-measurements] document.
o ssid
o channel
o location
o type
o band
o regclass
o antenna
o flightTime
o apSignal
6.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
o Name
o Version
o Manufacturer
o Features
o Class
o Signal Strength
o Link Quality
6.3.3.3. Other Signal Measurements
Jones & Steger Expires November 10, 2013 [Page 34]
Internet-Draft Signal Position Survey May 2013
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.
7. XML Schema
This section gives the XML Schema Definition [W3C.REC-
xmlschema-1-20041028] [W3C.REC-xmlschema-2-20041028] of the
"application/held+xml" format. This is presented as a formal
definition of the "application/sigpos+xml" format. Note that the XML
Schema Definition is not intended to be used with on-the-fly
validation of the presence XML document. Whitespaces are included in
the schema to conform to the line length restrictions of the RFC
format without having a negative impact on the readability of the
document. Any conforming processor should remove leading and
trailing white spaces.
The XML schema depicted below supports the Beacon Location mode of
SigPos Survey data only.
<?xml version="1.0" encoding="utf-8"?>
<xs:schema xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
xmlns:gml="http://opengis.net/gml"
xmlns:vc="urn:ietf:params:xml:ns:vcard-4.0"
xmlns:dyn="urn:ietf:params:xml:ns:pidf:geopriv10:dynamic"
xmlns:lm="urn:ietf:params:xml:ns:geopriv:lm"
xmlns:rel="urn:ietf:params:xml:ns:pidf:geopriv10:relative"
xmlns:cl="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
xmlns:ap="http://example.com/airport/5.0"
xmlns:pidf="urn:ietf:params:xml:ns:pidf"
attributeFormDefault="unqualified"
elementFormDefault="qualified"
targetNamespace="jones:sigpos"
xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:annotation>
<xs:documentation>
This document defines SigPos messages.
(draft-jones-geopriv-sigpos-survey)
</xs:documentation>
</xs:annotation>
<xs:import schemaLocation="/xsd/vcard.xsd"
namespace="urn:ietf:params:xml:ns:vcard-4.0" />
<xs:import schemaLocation="/xsd/pidf.xsd"
namespace="urn:ietf:params:xml:ns:pidf" />
Jones & Steger Expires November 10, 2013 [Page 35]
Internet-Draft Signal Position Survey May 2013
<xs:import schemaLocation="/xsd/geopriv-lm.xsd"
namespace="urn:ietf:params:xml:ns:geopriv:lm" />
<xs:complexType name="responseType">
<xs:complexContent>
<xs:restriction base="xs:anyType">
<xs:sequence>
<xs:element name="message" type="sigpos:responseMsgType"
minOccurs="0" maxOccurs="unbounded"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="code" type="xs:token" use="required"/>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
<xs:complexType name="responseMsgType">
<xs:simpleContent>
<xs:extension base="xs:token">
<xs:attribute ref="xml:lang"/>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:element name="sigPosResponse" type="sigpos:responseType"/>
<xs:element name="sigposSubmission">
<xs:complexType>
<xs:sequence>
<xs:element name="session">
<xs:complexType>
<xs:sequence>
<xs:element name="venue">
<xs:complexType>
<xs:sequence>
<xs:element ref="vc:vcard" />
<xs:element name="owner">
<xs:complexType>
<xs:sequence>
<xs:element ref="vc:vcard" />
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="license">
<xs:complexType>
Jones & Steger Expires November 10, 2013 [Page 36]
Internet-Draft Signal Position Survey May 2013
<xs:sequence>
<xs:element name="license-type"
type="xs:string" />
<xs:element name="licenseExpiry"
type="xs:dateTime" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="device" minOccurs="0">
<xs:complexType>
<xs:sequence>
<xs:element name="configuration">
<xs:complexType>
<xs:sequence>
<xs:element name="id" type="xs:string" />
<xs:element name="name" type="xs:string" />
<xs:element name="type" type="xs:string" />
<xs:element name="model"
type="xs:unsignedShort" />
<xs:element name="version"
type="xs:decimal" />
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element maxOccurs="unbounded" name="sensor">
<xs:complexType>
<xs:sequence>
<xs:element name="configuration">
<xs:complexType>
<xs:sequence>
<xs:element name="type"
type="xs:string" />
<xs:element name="id"
type="xs:string" />
<xs:element name="antenna"
type="xs:string" />
<xs:element name="chipset"
type="xs:string" />
<xs:element name="manufacturer"
type="xs:string" />
<xs:element name="capabilities">
<xs:complexType>
<xs:sequence>
<xs:element minOccurs="0"
name="type"
Jones & Steger Expires November 10, 2013 [Page 37]
Internet-Draft Signal Position Survey May 2013
type="xs:string" />
<xs:element minOccurs="0"
name="standard"
type="xs:string" />
<xs:element minOccurs="0"
name="frequencyband"
type="xs:string" />
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="survey">
<xs:complexType>
<xs:sequence>
<xs:element maxOccurs="unbounded"
name="survey-point">
<xs:complexType>
<xs:sequence>
<xs:element name="groundtruth">
<xs:complexType>
<xs:sequence>
<xs:element ref="pidf:presence" />
<xs:element name="rawlocation"
minOccurs="0">
<xs:complexType>
<xs:sequence>
<xs:element name="gnss">
<xs:complexType>
<xs:sequence>
<xs:element name="sentences">
<xs:complexType>
<xs:sequence>
<xs:choice
maxOccurs="unbounded">
<xs:element name="type"
type="xs:string" />
<xs:element name="value"
type="xs:string" />
</xs:choice>
</xs:sequence>
Jones & Steger Expires November 10, 2013 [Page 38]
Internet-Draft Signal Position Survey May 2013
</xs:complexType>
</xs:element>
</xs:sequence>
<xs:attribute name="type"
type="xs:string"
use="required" />
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="beacon" minOccurs="0">
<xs:complexType>
<xs:sequence>
<xs:element maxOccurs="unbounded"
name="mac" type="xs:string" />
</xs:sequence>
<xs:attribute name="type"
type="xs:string" use="required" />
</xs:complexType>
</xs:element>
<xs:element ref="lm:measurements"
minOccurs="0"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:sequence>
<xs:attribute name="sessionID" type="xs:string"
use="required" />
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:schema>
SigPos Partial XML Schema
Jones & Steger Expires November 10, 2013 [Page 39]
Internet-Draft Signal Position Survey May 2013
8. 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.
8.1. Assuring That the Proper LIS Has Been Contacted
Jones & Steger Expires November 10, 2013 [Page 40]
Internet-Draft Signal Position Survey May 2013
This document assumes that the LIS to be contacted is identified
either by an IP address or a domain name, as is the case for a LIS
discovered as described in LIS Discovery [RFC5986]. As the SigPos
transaction is conducted using TLS [RFC5246], the LIS can
authenticate its identity, either as a domain name or as an IP
address, to the client by presenting a certificate containing that
identifier as a subjectAltName (i.e., as an iPAddress or dNSName,
respectively). In the case of the HTTP binding described above, this
is exactly the authentication described by TLS [RFC2818]. If the
client has external information as to the expected identity or
credentials of the proper LIS (e.g., a certificate fingerprint),
these checks MAY be omitted. Any binding of SigPos MUST be capable
of being transacted over TLS so that the client can request the above
authentication, and a LIS implementation for a binding MUST include
this feature. Note that in order for the presented certificate to be
valid at the client, the client must be able to validate the
certificate. In particular, the validation path of the certificate
must end in one of the client's trust anchors, even if that trust
anchor is the LIS certificate itself.
8.2. Protecting Responses from Modification
In order to prevent a response from being modified en route, messages
must be transmitted over an integrity-protected channel. When the
transaction is being conducted over TLS (a required feature per
Section 11.1), the channel will be integrity protected by appropriate
ciphersuites. When TLS is not used, this protection will vary
depending on the binding; in most cases, without protection from TLS,
the response will not be protected from modification en route.
9. Examples
The following sections provide examples of basic HTTP/HTTPS, a simple
location request, and a location request for multiple location types,
along with the relevant location responses. To focus on important
portions of messages, the examples in Sections 10.2 and 10.3 do not
show HTTP/HTTPS headers or the XML prologue. In addition, sections
of XML not relevant to the example are replaced with comments.
9.1. Example of a WiFi Access Point Location Survey
The examples in this section show example HTTPS messages that include
the SigPos submission or response document.
POST /location HTTP/1.1
Host: sigpos.example.com:49152
Content-Type: application/sigpos+xml;charset=utf-8
Content-Length: nnn
Jones & Steger Expires November 10, 2013 [Page 41]
Internet-Draft Signal Position Survey May 2013
<?xml version="1.0"?> <sigpos xxmlns="jones:sigpos".../>
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.
<?xml version="1.0"?>
<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>
</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>
<licensor>
<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>
Jones & Steger Expires November 10, 2013 [Page 42]
Internet-Draft Signal Position Survey May 2013
<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>
</licensor>
<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>
Jones & Steger Expires November 10, 2013 [Page 43]
Internet-Draft Signal Position Survey May 2013
<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>
<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>
</xml>
802.11 WiFi Beacon Survey
Jones & Steger Expires November 10, 2013 [Page 44]
Internet-Draft Signal Position Survey May 2013
9.2. Example of a WiFi Signal Survey
A simple example of wifi scan data conveyance using gps for ground
truth is illustrated by the example message below.
<?xml version="1.0"?>
<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>
</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>
<licensor>
<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>
Jones & Steger Expires November 10, 2013 [Page 45]
Internet-Draft Signal Position Survey May 2013
<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>
</licensor>
<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>
Jones & Steger Expires November 10, 2013 [Page 46]
Internet-Draft Signal Position Survey May 2013
<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">
<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>
Jones & Steger Expires November 10, 2013 [Page 47]
Internet-Draft Signal Position Survey May 2013
<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>
<bssid>00-11-F0-A0-80-EF</bssid>
<ssid>wlan-other</ssid>
<rcpi>-92</rcpi>
</ap>
</wifi>
</lm:measurements>
</survey-point>
</survey>
</session>
</sigpos>
</xml>
802.11 WiFi Signal Scan Survey
10. 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, Adam Roach, Robin Wilton, and
Martin Thompson for initial reviews and valuable feedback.
Jones & Steger Expires November 10, 2013 [Page 48]
Internet-Draft Signal Position Survey May 2013
11. IANA Considerations
This section creates a registry for Data License types
(Section 6.1.3.3) and registers the namesapces and schema defined in
the Schemas (Section 7) secction.
11.1. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:geopriv:sigpos
This section registers a new XML namespace,
"urn:ietf:params:xml:ns:geopriv:sigpos", per the guidelines in
[RFC3688].
URI: urn:ietf:params:xml:ns:geopriv:sigpos
Registrant Contact: IETF, <TBD>.
XML
BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head>
<title>SigPos Messages</title>
</head>
<body>
<h1>Namespace for SigPos Messages</h1>
<h2>urn:ietf:params:xml:ns:geopriv:sigpos</h2>
<p>See draft-jones-geopriv-sigpos-survey</p>
</body>
</html>
END
11.2. XML Schema Registration
This section registers an XML schema as per the guidelines in
[RFC3688].
URI: urn:ietf:params:xml:schema:geopriv:sigpos
Registrant Contact: IETF, <tbd>.
Schema: The XML for this schema can be found as the entirety of
Section 9 of this document.
Jones & Steger Expires November 10, 2013 [Page 49]
Internet-Draft Signal Position Survey May 2013
11.3. MIME Media Type Registration for 'application/sigpos+xml'
This section registers the "application/sigpos+xml" MIME type.
To: ietf-types@iana.org
Subject: Registration of MIME media type application/sigpos+xml
MIME media type name: application
MIME subtype name: sigpos+xml
Required parameters: (none)
Optional parameters: charset
Same as the charset parameter of "application/xml" as specified in
RFC 3023 [RFC3023], Section 3.2.
Encoding considerations: Same as the encoding considerations of
"application/xml" as specified in RFC 3023 [RFC3023], Section 3.2.
Security considerations: This content type is designed to carry
protocol data related to the location of signal beacons, which could
include information that is considered private. Appropriate
precautions should be taken to limit disclosure of this information.
Interoperability considerations: This content type provides a basis
for a protocol. There are multiple interoperable implementations of
this protocol.
Published specification: <TBD>
Applications which use this media type: Location information
surveyors and service providers.
Additional Information:
Magic Number(s): (none)
File extension(s): .heldxml
Macintosh File Type Code(s): "TEXT"
Person & email address to contact for further information:
Mary Barnes <tbd> Intended usage: LIMITED USE
Jones & Steger Expires November 10, 2013 [Page 50]
Internet-Draft Signal Position Survey May 2013
Author/Change controller: The IETF
Other information: This media type is a specialization of application
/xml [RFC3023], and many of the considerations described there also
apply to application/held+xml.
11.4. IANA Registry for Data License Types
This document establishes a new IANA registry for the for Data
License types (Section 6.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:
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'
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.
Jones & Steger Expires November 10, 2013 [Page 51]
Internet-Draft Signal Position Survey May 2013
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 usage and derivative usage of the data. Any use of the data
would be governed under a separate agreement between the licensor
and the party wishing to make use of the data. By default, no
rights are granted for private data.
12. References
12.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-07 (work
in progress), April 2013.
[I-D.ietf-geopriv-relative-location]
Thomson, M., Rosen, B., Stanley, D., Bajko, G., and A.
Thomson, "Relative Location Representation", draft-ietf-
geopriv-relative-location-04 (work in progress), March
2013.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2617] Franks, J., Hallam-Baker, P.M., Hostetler, J.L., Lawrence,
S.D., Leach, P.J., Luotonen, A., and L. Stewart, "HTTP
Authentication: Basic and Digest Access Authentication",
RFC 2617, June 1999.
[RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media
Types", RFC 3023, January 2001.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
January 2004.
[RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object
Format", RFC 4119, December 2005.
[RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally
Unique IDentifier (UUID) URN Namespace", RFC 4122, July
2005.
Jones & Steger Expires November 10, 2013 [Page 52]
Internet-Draft Signal Position Survey May 2013
[RFC5139] Thomson, M. and J. Winterbottom, "Revised Civic Location
Format for Presence Information Data Format Location
Object (PIDF-LO)", RFC 5139, February 2008.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 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.
[RFC5986] Thomson, M. and J. Winterbottom, "Discovering the Local
Location Information Server (LIS)", RFC 5986, September
2010.
[RFC6351] Perreault, S., "xCard: vCard XML Representation", RFC
6351, August 2011.
[RFC6848] Winterbottom, J., Thomson, M., Barnes, R., Rosen, B., and
R. George, "Specifying Civic Address Extensions in the
Presence Information Data Format Location Object (PIDF-
LO)", RFC 6848, January 2013.
12.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://
standards.ieee.org/getieee802/download/802.11-2007.pdf>.
[NMEA0183]
Jones & Steger Expires November 10, 2013 [Page 53]
Internet-Draft Signal Position Survey May 2013
, "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>.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[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.
Authors' Addresses
Kipp Jones
Skyhook Wireless
34 Farnsworth Street
Boston 02210
US
Phone: +1 (617) 314-9802
Email: kjones@skyhookwireless.com
Christopher Steger
Skyhook Wireless
34 Farnsworth Street
Boston
US
Phone: +1 (617) 314-9802
Email: csteger@skyhookwireless.com
Jones & Steger Expires November 10, 2013 [Page 54]
