| Geographic Location/Privacy | K. Jones |
| Internet-Draft | Skyhook Wireless |
| Intended status: Standards Track | November 05, 2012 |
| Expires: May 09, 2013 |
Indoor Signal Position Conveyance
draft-jones-geopriv-sigpos-survey-01
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. This document also describes the use of HTTP/TLS as transport for the data object.
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 May 09, 2013.
Copyright (c) 2012 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.
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 for purposes of this document.
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.
This document describes the use of HTTP/TLS as transport for the survey data.
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].
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 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 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 process has several drawbacks:
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.
This document contains a number of open issues that need to be addressed or items that need further refinement, including:
The basic premise for the SigPos data container 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 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 [Venue] describes the venue or location of the survey, and the Survey Device section [SurveyDevice] describes the device being used to capture the survey data.
The Survey Data section [SurveyData] 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.
+---------------+
__| 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
There are several items that are explicitly out of scope for this document. These include:
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:
For purposes of signal positioning survey, we define several classes of PIDF-LO objects:
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.
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>
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>
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
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.
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>
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>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>
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.
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>
The License URI provides an optional element to identify the terms of a 'Private' license type. This allows
The optional policy element is intended to allow the licensor of the data gahtered 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.
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:
<license>
<licenseExpiry>2108-04-29T14:33:58</licenseExpiry>
<licenseType>unrestricted</licenseType>
</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 bootstrap a beacon database based on survey data. Survey data at a high quality could be used to 'seed' a location system, allowing an organization to build aeacon 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:
For commercial use:
<license>
<licenseExpiry>2008-04-29T14:33:58</licenseExpiry>
<licenseType>CC BY-ND</licenseType>
</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 application. The arrangment for providing this service could be managed out of band 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>
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>
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
+-----------------+
__| 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.
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>
<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>
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 |__
|_____________| |_______________| | |______________|
|
| +--------------+
|_| 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.
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
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.
In addition, support MUST be provided for relative locations as described below for each of the above PIDF-LO location methods.
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>
<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>
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>
<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>
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.
<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.
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:
<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.
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:
$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
$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>
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:
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.
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</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:
Optional (as defined in the IETF I-D Held Measurements [I-D.ietf-geopriv-held-measurements] document.
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.
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.
The SigPos protocol provides for the submission of signal survey data in the form of a SigPos document to a LIS. Three messages are defined to support the SigPost submission:: sigPosSubmission and sigPosResponse.
The SigPos Submission (sigPosSubmission) message is described in Section xxx. In case of success, the LIS replies with a sigPosResponse message, including a success code. In the case of an error, the LIS replies with a sigPosResponse message with an error code.
The SigPos protocol messages are defined as XML documents that MUST be encoded in UTF-8. A MIME type "application/sigpos+xml" is registered in Section xxxx to distinguish SigPos messages from other XML document bodies. This specification follows the recommendations and conventions described in [RFC3023], including the naming convention of the type (’+xml’ suffix) and the usage of the ’charset’ parameter. The ’charset’ parameter MUST be included with the XML document.
Section 9 contains a more specific definition of the structure of these messages in the form of an XML Schema [W3C.REC-xmlschema-1-20041028].
Section 10 describes the use of a combination of HTTP over TLS [RFC5246] for transporting the HELD messages.
A sigpos submission message is sent from the Device to the LIS when the Device completes a survey.
The sigpos submission is made by sending a document formed of a "sigPosSubmission" element. The LIS authenticates the Device and uses the authenticated identity for the requesting Device. It is anticipated that other Device identities may be provided through schema extensions.
The LIS MUST ignore any part of a sigpos submission message that it does not understand, except the document element. If the document element of a request is not supported, the LIS MUST return an error with the unsupportedMessage error code.
A successful response to a sigpos submission request MUST contain a successful code.
If the LIS is unable to validate the sigpos survey based on the received sigPosSubmission message, it MUST return an error message. An error indication document consists of a "sigPosResponse" element. The "sigPosResponse" element MUST include a "code" attribute that indicates the type of error. A set of predefined error codes are included in Section 8.3.1. Error responses MAY also include a "message" attribute that can include additional information. This information SHOULD be for diagnostic purposes only and MAY be in any language. The language of the message SHOULD be indicated with an "xml:lang" attribute.
All responses MUST contain a response code. All errors are application-level errors and MUST only be provided in successfully processed transport-level responses. For example, where HTTPS is used as the transport, SigPos error messages MUST be carried by a 200 OK HTTP/HTTPS response.
The value of the response code MUST be an IANA-registered value. The following tokens are registered by this document:
success: This code indicates that the request was received and successfully validated.
requestError: This code indicates that the request was badly formed in some fashion (other than the XML content).
xmlError: This code indicates that the XML content of the request was either badly formed or invalid.
generalLisError: This code indicates that an unspecified error occurred at the LIS.
unsupportedMessage: This code indicates that an element in the XML document for the request was not supported or understood by the LIS. This error code is used when a SigPos submission contains a document element that is not supported by the receiver.
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" />
<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>
<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"
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>
</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
This section describes the use of HTTP over TLS [RFC2818] as a transport mechanisms for the SigPos protocol, which a conforming LIS and Device MUST support.
Although SigPos uses HTTP as a transport, it uses a strict subset of HTTP features, and due to the restrictions of some features, a LIS is not a fully compliant HTTP server. It is intended that a LIS can easily be built using an HTTP server with extensibility mechanisms and that a HELD Device can trivially use existing HTTP libraries. This subset of requirements helps implementors avoid ambiguity with the many options that the full HTTP protocol offers.
A Device that conforms to this specification MUST support HTTP authentication [RFC2617] over TLS.
A SigPos submission is carried in the body of an HTTPS POST request.
The MIME type of SigPos request and response bodies is "application/sigpos+xml". LIS and Device MUST provide this value in the HTTP Content-Type and Accept header fields. If the LIS does not receive the appropriate Content-Type and Accept header fields, the LIS SHOULD fail the request, returning a 406 (not acceptable) response. SigPos responses SHOULD include a Content-Length header.
Devices MUST NOT use the "Expect" header or the "Range" header in HELD requests. The LIS MAY return 501 (not implemented) errors if either of these HTTP features are used. In the case that the LIS receives a request from the Device containing an If-* (conditional) header, the LIS SHOULD return a 412 (precondition failed) response.
The POST method is the only method REQUIRED for SigPos. If a LIS chooses to support GET or HEAD, it SHOULD consider the kind of application doing the GET. Since a SigPos Device only uses a POST method, the GET or HEAD MUST be either an escaped URL (e.g., somebody found a URL in protocol traces or log files and fed it into their browser) or somebody doing testing/debugging. The LIS could provide information in the SigPos response indicating that the URL corresponds to a LIS server and only responds to HELD POST requests, or the LIS could instead try to avoid any leak of information by returning a very generic HTTP error message such as 404 (not found).
The HTTP status code MUST indicate a 2xx series response for all SigPos sigPosSubmission and sigPosRespons messages.
The LIS MAY redirect a SigPos request. A Device MUST handle redirects by using the Location header provided by the server in a 3xx response. When redirecting, the Device MUST observe the delay indicated by the Retry-After header. The Device MUST authenticate the server that returns the redirect response before following the redirect, if a Device requires that the server is authenticated. A Device MUST authenticate the LIS indicated in a redirect.
Implementations of SigPos MUST implement transport over TLS [RFC2818]. TLS provides message integrity and confidentiality between the Device and LIS. The Device MUST implement the server authentication method described in Section 3.1 of [RFC2818], with an exception in how wildcards are handled. The leftmost label MAY contain the wildcard string "*", which matches any single domain name label. Additional characters in this leftmost label are invalid (that is, "f*.example.com" is not a valid name and does not match any domain name).
The Device uses the URI obtained during LIS discovery to authenticate the server. The details of this authentication method are provided in Section 3.1 of HTTPS [RFC2818]. When TLS is used, the Device SHOULD fail a request if server authentication fails.
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.
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.
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.
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.
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
<?xml version="1.0"?> <sigpos xxmlns="jones:sigpos".../>
The LIS response to the request is an sigPosResponse document. The following response shows an example error response.
HTTP/1.1 200 OK
Server: Example SigPos
Expires: Tue, 21 Feb 2013 15:23:03 GMT
Cache-control: private
Content-Type: application/sigpos+xml;charset=utf-8
Content-Length: 182
<?xml version="1.0"?>
<sigPosResponse xxmlns="jones:sigpos"
code="success">
<message xml:lang="en">Successfully validated submission
</message>
</sigPosResponse>
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>
<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>
<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
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>
<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>
<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>
<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
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 Stéphane Terrenoir, Adam Roach, Robin Wilton, and Martin Thompson for initial reviews and valuable feedback.
This section creates a registry for Data License types [LicenseType] and registers the namesapces and schema defined in the Schemas [Schemas] secction.
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
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.
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
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.
This document establishes a new IANA registry for the for Data License types [LicenseType]. 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:
This section pre-registers 8 new 'licenseType' tokens associated with the 'licenseType'
This doecument establishees a new IANA registry for sigPosResponse Codes [Code]. This registry includes tokens for the sigPosRespons codes. 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 sigPosResponse code.
Registrant Contact: <tbd>.
This section registers the following five initial error codes as described in Section 8.3.1:
| [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. |
| [NMEA0183] | NMEA 0183", 2007. | , "
| [GeoShape] | GML GeoShape Application Schema for use in internet standards developed by the IETF", 2006. | , "
| [OGC-GML3.1.1] | Geography Markup Language (GML) 3.1.1", 2003. | , "
| [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. | , "
| [CC] | Creative Commons, "Creative Commons LIcenses", 2012. |