Indoor Signal Position Conveyance
draft-jones-geopriv-sigpos-survey-00

Abstract

Location Information Servers rely on signal surveys to create a signal map allowing for subsequent device location determination. This document describes a method by which a Survey Device is able to provide indoor location related measurement data to a LIS for positioning purposes. Location related measurement information comprises observations concerning properties related to the position of a Survey Device and the radio, electromagnetic, and other observable environmental measures as perceived by the Survey Device. These measurements could be data about Wi-Fi signals, Bluetooth signals, barometric pressure, or any other environmental measurement which could sent to a LIS for subsequent processing to help determine the location of devices that later enter the venue. A basic set of location-related measurements, data rights disclosure and location types are defined.

Status of this Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on November 30, 2012.

Copyright Notice

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.

1. Introduction
1.1. Requirements Language
2. Overview
3. Open Issues
4. Description
5. Out of Scope
6. Using PIDF-LO Location
6.1. Device Orientation
7. Session
7.1. Venue
7.1.1. Venue Name/Address
7.1.2. Owner
7.1.3. Data Rights Management
7.1.3.1. License Expiry
7.1.3.2. License URI
7.1.3.3. License Type
7.1.3.3.1. Unrestricted License
7.1.3.3.2. Creative Commons License
7.1.3.3.3. Private License
7.1.4. Map Metadata
7.2. Survey Device
7.2.1. Configuration Object
7.2.2. Example Device Configuration
7.3. Survey Data
7.3.1. Ground Truth
7.3.1.1. PIDF-LO Location
7.3.1.1.1. Basic Location
7.3.1.1.2. Relative Location
7.3.1.1.3. Manual Location
7.3.1.1.4. Civic Location
7.3.1.2. Raw Location Data
7.3.2. Beacons
7.3.3. Signal Measurements
7.3.3.1. WiFi Measurements
7.3.3.2. Bluetooth Measurements
7.3.3.3. Other Signal Measurements
8. Example Surveys
8.1. WiFi Access Point Location Survey
8.2. WiFi Signal Survey
9. Acknowledgements
10. IANA Considerations
10.1. IANA Registry for Data License Types
11. Schemas
12. Security Considerations
13. References
13.1. Normative References
13.2. Informative References
Author's Address

1. Introduction

This document describes a format for the expression of the measure and location of signals (SigPos) within a venue for purposes of providing location services.

The format includes a venue description, signal information, and data usage specifications.

A venue is defined as an area of interest for providing location services. Examples of a venue include a campus, a building, or a room. A venue should have a single administrative contact.

Signal information is inclusive of the specific description and measures of the signal (e.g. 802.11 Wi-Fi signals), a description the device used to measure the signals, as well as the location and orientation of the device.

Multiple methods for providing location are defined including civic locations, geodetic locations, absolute locations, relative locations, and locations with error estimates.

In addition to the signal information, on optional section provides the ability to specify the data usage rights to be conferred to another entity. One right would be to grant a Location Information Service (LIS) rights to make use of the signal information to provide location services.

1.1. Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].

2. Overview

This document describes a common method to record, distribute and grant rights on signal location information related to the geospatial measurement of wireless RF signals. The document sets forth the motivation behind the effort, the basic design of the data format, the reasoning and technical approach for managing the ownership of the information, and provides various usage scenarios to further describe the architecture.

The primary motivation for this work is in providing a common framework for capturing and sharing information related to the geospatial measurement of RF signals for purposes of providing 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 use of specialized hardware with highly trained engineers is expensive. By requiring the design and manufacture of specialized hardware as well as trained individuals to operate the hardware, the ability to scale the process and realize mass production reductions in costs are foregone
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
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
the value is locked in a vendor. To exploit the investment further is problematic at best and impossible at worst. The value that is obtained from the effort to create a signal map may be realized by the vendor and not the venue owner. Even if the vendor made a portion of the investment, the venue owner may be excluded from additional revenue sources as new ways to leverage the data and additional location services are created
high quality venue maps have not been readily accessible. Having location is an important part of the puzzle, but having the ability to pin the dot on a map creates innumerable additional opportunities
mobile devices and applications have traditionally been locked to the vendor that did the site survey. This made it impossible to scale across many different apps on many different mobile operating systems
context is more important for indoor positioning while latitude, longitude, and altitude are less valuable. In other words, it is more important from a user perspective to identify the floor, the room, the aisle, etc. than it is to provide only x, y, z coordinates

The goal of this specification is to reduce these friction points and provide a common method for specifying, encoding, conveying, and granting usage rights to signal survey information.

3. Open Issues

This document contains a number of open issues that need to be addressed or items that need further refinement, including:

Additional Privacy Considerations - what additional privacy and security issues need to be considered?
Survey Device Configuration Specification - is there a better way to declare device/sensors? SenML?
Specification of Licensing Options - are these sufficient? IANA registration for others? Do we need a more formal definition?
Formal xsd definition

4. Description

The basic premise for the SigPos data format is to preserve the concept of a ‘survey session’. A survey session generally represents a set of contiguous location and sensor scan records that were gathered by a given device. For example, this could represent a survey of the floor of a building, a single point survey, or a survey of a room.

This document defines a container for the conveyance of location-related measurement parameters or specifications related to beacon locations and their related signal patterns within an indoor venue. This is an XML container that identifies parameters by type and allows the Device to provide the results of any measurement it is able to perform. A set of measurement schemas are also defined that can be carried in the generic container. Lastly, it allows for the manual specification of both the beacons as well as their location.

A number of additional concepts are included in this standard such as the identification of the equipment conducting the survey and the inclusion of both explicit and implicit location information. These will be detailed further in following sections.

The interpretation of the survey data is left to the implementer of the location service and is not explicitly part of this specification. For example, how to correlate a particular WiFi signal sample with an interpolated location, or how much time lapse between a WiFi signal reading and a GPS sample is permissible. These are choices that are decoupled from the data gathering and transmission, but every attempt has been made to provide the facility to include sufficient information in this standard to enable downstream algorithms to make appropriate choices.

Each capture document corresponds to a ‘session’. Each session can have a 'venue' section, a 'survey device' section, and a 'survey' section. The venue describes the venue, the location of the venue, the owner organization as well as the data rights applicable to the survey. The Venue Section [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         |
             |                | +---------------+  | |______________|
             |                |_| Owner         |__|                    
             |                | |_______________|  | +--------------+
             |                |                    |_| Address      |                   
             |                | +---------------+    |______________| 
             |                |_| License       |                     
             |                  |_______________|                      
+---------+  | 
| Session | -| 
|_________|  |
             |                  +---------------+
             |                __| Configuration |
             |                | |_______________|
             |                |
             | +-----------+  | +---------------+    +--------------+   
             |_| Survey    |__|_| Survey        |____| Sensor       |__
             | | Device    |    | Sensors       |    |______________|   
             | |___________|    |_______________|
             |                                                         
             |                                       +--------------+ 
             |                                     __| Ground Truth |__
             |                                     | |______________|  
             |                                     |
             | +-----------+    +---------------+  | +--------------+  
             +-| Survey    |____| Survey Point  |__|_| Beacons      |__
               |___________|    |_______________|  | |______________|  
                                                   |
                                                   | +--------------+  
                                                   |_| Measurements |__
                                                     |______________|

Document structure overview.

5. Out of Scope

There are several items that are explicitly out of scope for this document. These include:

Dead reckoning and other sensor data such as gyroscope, barometric pressure and accelerometer readings are expected to be incorporated into the positioning computation by the device prior to encoding the location object, and
Computation of interpolated locations/readings are left for the downstream processor such as a LIS.

6. Using PIDF-LO Location

All location information in this container are specified using the GEOPRIV Presence Information Data Format Location Object. This includes the basic definition of the PIDF-LO [RFC4119] object, PIDF-LO Clarification [RFC5491], Revised Civic Location Format [RFC5139], Dynamic Extensions to PIDF-LO [RFC5962], PIDF-LO Relative Location [I-D.ietf-geopriv-relative-location], and Civic Address Extensions [I-D.ietf-geopriv-local-civic].

The PIDF-LO object provides a variety of mechanisms to indicate position. This may refer to the location of the venue, the location of a beacon or the location of the survey device itself. Several of the capabilities of the PIDF-LO object are discussed in this section. For a full specifications refer to the relevant RFCs and Internet Drafts.

The PIDF-LO object allows for specification of elements that encompass:

Position
Timestamp
Provider
Uncertainty
Bearing
Speed
Orientation

For purposes of signal positioning survey, we define several classes of PIDF-LO objects:

Manual geolocation - human manipulation or specification of a geolocation
Integrated geolocation - system generated geolocation (e.g. via GPS)
Relative location - geolocation based on a defined reference point

Each of these methods of providing location can be encoded within the constructs provided by the PIDF-LO structure when combined with the necessary extensions mentioned above and described in more detail in subsequent sections.

6.1. Device Orientation

The optional orientation elements allows the surveyor to provide precise information with respect to the orientation of the scanning device at the time the readings were made. This orientation information can be used to differentiate signal information when the device is held at different angles at each survey point.

From the "Dynamic Extensions to the Presence Information Data Format Location Object (PIDF-LO)" [RFC5962], we find:

"The <orientation> element describes the spatial orientation of the presentity -- the direction that the object is pointing. For a device, this orientation might depend on the type of device."

This proposed extension to the PIDF-LO object allows for the inclusion of device orientation within each PIDF-LO object.

An example specifying device orientation:

   <presence
       xmlns="urn:ietf:params:xml:ns:pidf"
       xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model"
       xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
       xmlns:dyn="urn:ietf:params:xml:ns:pidf:geopriv10:dynamic"
       xmlns:gml="http://www.opengis.net/gml"
       entity="pres:alice@example.com">
       <dm:device id="abc123">
           <gp:geopriv>
               <gp:location-info>
                   <dyn:Dynamic>
                       <dyn:orientation>-3 12</dyn:orientation>
                       <dyn:speed>24</dyn:speed>
                       <dyn:heading>278</dyn:heading>
                   </dyn:Dynamic>
               </gp:location-info>
               <gp:usage-rules/>
               <method>gps</method>
           </gp:geopriv>
           <timestamp>2009-06-22T20:57:29Z</timestamp>
           <dm:deviceID>mac:1234567890ab</dm:deviceID>
       </dm:device>
   </presence>

7. Session

The session element creates a container for the other elements of the survey. There should be a single survey per document.

The session tag includes two required attributes: the sessionID and the sessionDate.

SeesionID: contains an opaque string which provides a globally unique identifier for this survey.

SessionDate: contains the date the survey was performed.

 <session sessionID="X88278xskkw" sessionDate="2009-06-22T20:57:29Z">
  ...
 </session>

7.1. Venue

The venue section describes the venue itself and also provides for two additional elements: the definition of the owner and the definition of the policy for the included data.

                  +---------------+
                  | Venue xCard   |
                __| Name/Address  |
                | |_______________|  
                |                    
 +-----------+  | +---------------+  
 | Venue     |__|_| Owner xCard   |
 |___________|  | | Name/Address  |
                | |_______________| 
                |                                       
                | +---------------+   
                |_| License       |
                | |_______________|
                |
                | +---------------+
                |_| Map Metadata  |
                  |_______________|

Venue structure overview.

The venue section of the document provides for the ability to identify the venue in which the survey took place as well as the location of the venue.

7.1.1. Venue Name/Address

This optional element provides the ability to specify the name and address of the venue for identification purposes. This element uses the xCard [RFC6351] XML format to provide the necessary structure for these elements.

<?xml version="1.0" encoding="UTF-8"?>
<vcards xmlns:vc="urn:ietf:params:xml:ns:vcard-4.0">
     <vc:vcard>
       <vc:fn><vc:text>Example Building</vc:text></vc:fn>
       <vc:adr>
         <vc:parameters>
           <vc:type><vc:text>work</vc:text></vc:type>
           <vc:label><vc:text>Example Building
   1 South Boston Street
   Boston, MA USA 02210</vc:text></vc:label>
         </pvc:arameters>
         <vc:pobox/>
         <vc:ext/>
         <vc:street>1 South Boston Street</vc:street>
         <vc:locality>Boston</vc:locality>
         <vc:region>MA</vc:region>
         <vc:code>02210</vc:code>
         <vc:country>USA</vc:country>
       </vc:adr>
     </vc:vcard>
</vcards>

7.1.2. Owner

The optional ownership section allows for the definition of the organization or individual that originated the data. The ownership section also makes use of the xCard [RFC6351] format for encoding information about the name and address of the owner entity.

<?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>

7.1.3. Data Rights Management

The license object allows the venue owner or site surveyor the ability to manage the ownership, distribution, and usage rights of the survey data. This document includes a mechanism for including copyright and licensing terms. The licensing models are described in more detail below.

The <license> object is optional. If missing, the license type is assumed to be 'unrestricted' with a default expiration.

7.1.3.1. License Expiry

The optional License Expiry tag allows the surveyor to set time limits on the usage granted by the License Type. By default the data license expires 30 days after the date identified in the sessionDate.

7.1.3.2. License URI

The License URI provides an optional element to identify the terms of a 'Private' license type. This allows

7.1.3.3. License Type

The optional policy element is intended to allow the venue owner/manager or the entity in charge of data gathering for a given venue to provide granular control over the use and subsequent derivative works based on the venue’s infrastructure. In the event that no policy is specified, it is assumed that the data is released using the unrestricted policy.

There are eight pre-defined Data License Types grouped into three categories.

7.1.3.3.1. Unrestricted License

The unrestricted policy allows for the use and unrestricted derivative products based on the data set. If the data expires, the original data can no longer be used, but any derivative products that were generated during the granted use of the data remains valid.

Example of an unrestricted license delcaration:

   <license>
     <licenseExpiry>2108-04-29T14:33:58</licenseExpiry>
     <licenseType>unrestricted</licenseType>
   </license>

7.1.3.3.2. Creative Commons License

The Creative Commons [CC] provide a number of licensing options which, in some cases, permit the owner of the data to restrict commercial use and/or derivative works. Valid types include:

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.
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.
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.
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.
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.
CC BY-NC-ND - This license is the most restrictive of our six main licenses, only allowing others to download your works and share them with others as long as they credit you, but they can’t change them in any way or use them commercially.

   <license>
     <licenseExpiry>2008-04-29T14:33:58</licenseExpiry>
     <licenseType>CC BY-ND</licenseType>
   </license>

7.1.3.3.3. Private License

The private license is intended to provide full control over the ownership, usage, and derivative usage of the data. Any use of the data would be governed under a separate agreement between the owner and the party wishing to make use of the data. By default, no rights are granted for private data.

   <license>
     <licenseType>private</licenseType>
     <licenseURI>http://www.example.com/mylicense.html</licenseURI>
     <licenseExpiry>2008-04-29T14:33:58</licenseExpiry>
   </license>

7.1.4. Map Metadata

The optional "map" URL can be used to provide a user or system with a visual reference for the location information. This URL specification is based on that provided in Section 4.11 of PIDF-LO Relative Location [I-D.ietf-geopriv-relative-location] specification. For purposes of the overall Venue map, the offset SHOULD provide the offset to the starting location on the map for the survey.

   <rel:map>
     <rel:url type="image/jpeg">
        http://example.com/map.jpg
     </rel:url>
     <rel:offset> 200 210</rel:offset>
     <rel:orientation>68</rel:orientation>
     <rel:scale>2.90 -2.90</rel:scale>
   </rel:map>

7.2. Survey Device

The specification includes elements to describe the capabilities of the hardware and software of the scanning device as well as the hardware and software for the sensors that were used to capture the scan data. This can allow further downstream processing by discriminating source data based on capabilities and known device/sensor profiles and behaviors.

The Survey Device section SHOULD contain one device configuration record. It MAY contain 0-n sensor configuration elements.

                             
              _+-------------+    +-----------------+
             | | Hardware    |____|| Configuration ||                      
             | |_____________|    ||_______________||
             |               
             |_+-------------+    +-----------------+
             | | Software    |____|| Configuration ||                      
             | |_____________|    ||_______________||
+---------+  |                                     
| Survey  |__|                                     
| Device  |  |
|_________|  | +-------------+    +-------------+   +-----------------+  
             |_| Sensor (0-n)|____| Hardware    |___|| Configuration ||                      
               |_____________|  | |_____________|   ||_______________||
                                |
                                | +-------------+   +-----------------+  
                                |_| Software    |___|| Configuration ||                      
                                  |_____________|   ||_______________||

Survey Device structure overview.

7.2.1. Configuration Object

                       +-----------------+
                     __| Type            |
                     | |_________________|
                     |
                     | +-----------------+
                     |_| Id              |
                     | |_________________|
                     |
                     | +-----------------+
                     |_| Name            |
                     | |_________________|
+-----------------+  |
| Configuration   |__| +-----------------+               
|_________________|  |_| Manufacturer    |
                     | |_________________|
                     |
                     | +-----------------+
                     |_| Model           |
                     | |_________________|
                     |
                     | +-----------------+
                     |_| Version         |
                     | |_________________|
                     |
                     | +-----------------+
                     |_| Vendor          |
                     | |_________________|
                     |
                     | +-----------------+
                     |_| Capability      |
                       |_________________|

Survey Device Configuration structure overview.

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.

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.
name - (required) - the name of the device/sensor
vendor - (0-1) - a human readable description of the component vendor
model - (0-1) -the model and model number of the component
capability - (0-n) - a name/value pair to allow arbitrary configuration and capability declarations for each configuration object.

7.2.2. Example Device Configuration

An example <device> object is shown below.

<device>
    <hardware>
        <configuration>
            <type>device</type>
            <name>mapit</name>
            <version>1.2</version>


            <id>abc</id>
            <model>900</model>
            <capabiity name="chipset">Intel Q965</capability>
            <capabiity name="power">12 volt</capability>
        </configuration>
    </hardware>
    <software>
        <configuration>
            <type>software</type>
            <name>Centos6</name>
            <version>2.6.18-308.1.1.el5 #1 SMP x86_64 GNU</version>
        </configuration>
    </software>
    <sensor>
        <hardware>
            <configuration>
                <id>000FFA9870BC</id>
                <name>External WiFi</name>
                <version>1.23</version>
                <vendor>aetheros</vendor>
                <capability name="antenna">omni-directional</capability>
                <capability name="gain">10</capability>
                <capability name="chipset">aetheros</capability>
                <capability name="standard">a,b,g,n</capability>
                <capability name="frequencyband">1-13</capability>
                </capabilities>
            </configuration>
        </hardware>
        <software>
            <configuration>
                <name>atheros driver</name>
                <version>ath9k</version>
            </configuration>
        </software>
    </sensor>
    <sensor>
        <hardware>
            <configuration>
                <type>gps</type>
                <id>gm39211</id>
                <version>4.23a</version>
                <vendor>unknown</vendor>
                <capability name="antenna">combined</capability>
                <capability name="chipset">qualcomm</capability>
            </configuration>
        </hardware>
    </sensor>
</device>

7.3. Survey Data

The survey section represents all of the scanned or input data gathered about the venue in this session. Within a ‘survey’, there may be 0-n ‘readings’ which will contain a complete set of information about a subset of the survey. For example, a single room could be captured within a ‘readings’ segment.

This document defines location-related measurement data types for a range of common sensor types.

All included measurement data definitions allow for arbitrary extension in the corresponding schema. As new parameters that are applicable to location determination are added, these can be added as new XML elements in a unique namespace. Though many of the underlying protocols support extension, creation of specific XML-based extensions to the measurement format is favored over accommodating protocol-specific extensions in generic containers.

Note, the "time" attribute records the time that the measurement or 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.

Survey Points describe a subset of the survey information and potentially include Ground Truth, Beacon IDs, and Signal Measurements. These categories of information are detailed further in the following sections.

7.3.1. Ground Truth

Ground truth is a term that describes the location of the Survey Device.

The ‘ground truth’ element is designed to allow the specification and recording of the location at which the survey point was captured. To encompass various survey and usage scenarios, there are currently three GroundTruth types available for each survey point. These include PIDF-LO location object, a Contextual Location object, and/or a Raw Location object. These are described further below.

Multiple Ground Truth objects are allowed for interpolation between a starting point and an endpoint without explicitly declaring each scan position. The interpolation of the survey data is left to the downstream processor such as an LIS server.

groundTruth MUST have at least 1 SurveyPoint object as defined below.

 
                    +----------------+   +----------+
                   _| Basic Location |- -| Civic    |
                  | |________________|   | Location |
+-------------+   |                      |__________|
| GroundTruth |___| +----------------+  
|_____________|   |_| Raw Location   |
                    | Data           |
                    |________________|

Groundtruth structure overview.

7.3.1.1. PIDF-LO Location

This section describes the primary PIDF-LO method types that are supported by this specification. While all PIDF-LO location 'methods' are possible, the following are the only methods that MUST be supported.

GPS
A-GPS
Triangulation
Cell
Manual

In addition, support MUST be provided for relative locations as described below for each of the above PIDF-LO location methods.

7.3.1.1.1. Basic Location

Basic location represents a location as provided by the Survey Device. This could be from a location API, WiFi positioning, an integrated GPS, or any other mechanism that computes or determines the location of the survey device. To encompass this variety of locative technologies, the structure of the object provides numerous constructs.

An example of an integrated GPS location including dynamic orientation extensions is shown below. More examples of encodings can be found in PIDF-LO Usage [RFC5491].

<presence xmlns="urn:ietf:params:xml:ns:pidf"
          xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
          xmlns:cl="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
          xmlns:rel="urn:ietf:params:xml:ns:pidf:geopriv10:relative"
          xmlns:dyn="urn:ietf:params:xml:ns:pidf:geopriv10:dynamic"
          xmlns:gml="http://www.opengis.net/gml">
    <tuple id="abcd123456">
        <status>
           <gp:geopriv>
             <gp:location-info>
               <gs:Ellipsoid srsName="urn:ogc:def:crs:EPSG::4326">
                 <gml:pos>42.5463 -73.2512 26.3</gml:pos>
                 <gs:semiMajorAxis uom="urn:ogc:def:uom:EPSG::9001">
                   7.7156
                 </gs:semiMajorAxis>
                 <gs:semiMinorAxis uom="urn:ogc:def:uom:EPSG::9001">
                   3.31
                 </gs:semiMinorAxis>
                 <gs:verticalAxis uom="urn:ogc:def:uom:EPSG::9001">
                   28.7
                 </gs:verticalAxis>
                 <gs:orientation uom="urn:ogc:def:uom:EPSG::9102">
                   90
                 </gs:orientation>
                 <dyn:Dynamic>
                     <dyn:orientation>-3 12</dyn:orientation>
                     <dyn:speed>24</dyn:speed>
                     <dyn:heading>278</dyn:heading>
                 </dyn:Dynamic>
               </gs:Ellipsoid>
             </gp:location-info>
             <gp:usage-rules/>
               <method>gps</method>
             <gp:usage-rules/>
          </gp:geopriv>
          <timestamp>2009-06-22T20:57:29Z</timestamp>
       </status>
    </tuple>
</presence>

7.3.1.1.2. Relative Location

A relative location is based on the topology of the venue and is specified by first declaring one or more anchors that contain a geospatial reference.

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>

7.3.1.1.3. Manual Location

The manual location object allows the surveyor to specify the geospatial coordinate and/or a civic address to be associated with the ‘readings’ data.

This element contains any valid location, using the rules for a "location-info" element, as described in RFC 5491 [RFC5491]. Location information in a survey may be described in a geospatial manner based on a subset of Geography Markup Language (GML) 3.1.1 [OGC-GML3.1.1] or as civic location information RFC 5139 [RFC5139] and refined in RFC 5774 [RFC5774]. An OGC GML [OGC-GML3.1.1] profile for expressing geodetic shapes in a PIDF-LO is described in GML GeoShape Application Schema [GeoShape].

Below are several examples of manual location objects.

<presence xmlns="urn:ietf:params:xml:ns:pidf"
          xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
          xmlns:cl="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
          xmlns:rel="urn:ietf:params:xml:ns:pidf:geopriv10:relative"
          xmlns:dyn="urn:ietf:params:xml:ns:pidf:geopriv10:dynamic"
          xmlns:gml="http://www.opengis.net/gml">
    <tuple id="abcd123456">
      <status>
        <gp:geopriv>
          <gp:location-info>
            <gml:Point srsName="urn:ogc:def:crs:EPSG::4326">
                <gml:pos>-43.5723 153.21760</gml:pos>
            </gml:Point>
          </gp:location-info>
        </gp:geopriv>
        <timestamp>2007-06-22T20:57:29Z</timestamp>
      </status>
    </tuple>
</presence>

Sample manual location using a point.

<presence xmlns="urn:ietf:params:xml:ns:pidf"
          xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
          xmlns:cl="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
          xmlns:rel="urn:ietf:params:xml:ns:pidf:geopriv10:relative"
          xmlns:dyn="urn:ietf:params:xml:ns:pidf:geopriv10:dynamic"
          xmlns:gml="http://www.opengis.net/gml">
    <tuple id="abcd123456">
      <status>
        <gp:geopriv>
          <gp:location-info>
              <gs:Circle srsName="urn:ogc:def:crs:EPSG::4326">
                  <gml:pos>42.5463 -73.2512</gml:pos>
                  <gs:radius uom="urn:ogc:def:uom:EPSG::9001">
                      5.24
                  </gs:radius>
              </gs:Circle>
          </gp:location-info>
        </gp:geopriv>
        <timestamp>2007-06-22T20:57:29Z</timestamp>
      </status>
    </tuple>
</presence>

Sample manual location using a circle with a radius to represent error estimate.

7.3.1.1.4. Civic Location

To support adding contextual information to survey points during the survey process, this specification includes the ability to add extended civic addresses as defined by

the optional Contextual Location object is provided. This object enables the capture of contextual information with resepect to a survey point.

For example, an office building may have floors, wings, rooms, and cubes while an amusement park will have rides, booths, food stands and arcades. The civic address extensions provide a mechanism for extending these attributes and maintaining interoperability.

Example of civic location:

<presence xmlns="urn:ietf:params:xml:ns:pidf"
          xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
          xmlns:cl="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
          xmlns:rel="urn:ietf:params:xml:ns:pidf:geopriv10:relative"
          xmlns:dyn="urn:ietf:params:xml:ns:pidf:geopriv10:dynamic"
          xmlns:gml="http://www.opengis.net/gml">
    <tuple id="abcd123456">
      <status>
        <gp:geopriv>
          <gp:location-info>
              <gml:Point srsName="urn:ogc:def:crs:EPSG::4326">
                  <gml:pos>-43.5723 153.21760</gml:pos>
              </gml:Point>
              <civicAddress xml:lang="en-US"
                 xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
                 xmlns:post="http://postsoftheworld.net/ns"
                 xmlns:ap="http://example.com/airport/5.0">
                <country>US</country>
                <A1>CA</A1>
                <post:lamp>2471</post:lamp>
                <post:pylon>AQ-374-4(c)</post:pylon>
                <ap:airport>LAX</ap:airport>
                <ap:terminal>Tom Bradley</ap:terminal>
                <ap:concourse>G</ap:concourse>
                <ap:gate>36B</ap:gate>
              </civicAddress>
          </gp:location-info>
        </gp:geopriv>
        <timestamp>2007-06-22T20:57:29Z</timestamp>
      </status>
    </tuple>
</presence>

The optional civicAddress object can be included in any of the PIDF-LO objects defined above.

7.3.1.2. Raw Location Data

To support the capture and conveyance of underlying raw location data, a common optional container is defined for the expression of this location measurement data.

Currently only the ‘GNSS’ raw location type has been defined. Global Navigation Satellite System (GNSS) readings provide location measurements based on satellite navigation systems such as that provided by GPS.

Rather than decomposing GNSS output during the survey, the sentences 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>

7.3.2. Beacons

The intent of the <beacon> object is to allow the surveyor to identify individual beacons and specify the location of that beacon. In other words, in a site survey where beacon A is located at x1, y1 and beacon B is located at x2, y2, this construct would allow for that. This is for those instances where exact beacon position is useful for the LIS to compute device locations.

Beacon Identification

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:

id (required) - indicates the key(s) necessary to uniquely identify the beacon of the given type

7.3.3. Signal Measurements

Signal-Related Measurement Data Types

A common container is defined for the expression of location measurement data, as well as a simple means of identifying specific types of measurement data for the purposes of requesting them.

The following example shows a measurement container with measurement time included. A WiFi measurement is enclosed.

     <lm:measurements xmlns:lm="urn:ietf:params:xml:ns:geopriv:lm"
                      time="2008-04-29T14:33:58">
       <wifi xmlns="urn:ietf:params:xml:ns:geopriv:lm:wifi">
         <ap serving="true">
           <bssid>00-12-F0-A0-80-EF</bssid>
           <ssid>wlan-home</ssid>
         </ap>
       </wifi>
     </lm:measurements>

The "measurement" element is used to encapsulate measurement data that is collected at a certain point in time. It contains time-based attributes that are common to all forms of measurement data, and permits the inclusion of arbitrary measurement data.

7.3.3.1. WiFi Measurements

WiFi Measurements are based on the proposed measurements defined in the IETF I-D Held Measurements [I-D.ietf-geopriv-held-measurements] document.

In WiFi, or 802.11 [IEEE.80211.2007], networks a Device might be able 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:

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.
rcpi: The received channel power indicator for the access point signal, as measured by the Device. This value SHOULD be in units of dBm (with RMS error in dB). If power is measured in a different fashion, the "dBm" attribute MUST be set to "false". Signal strength reporting on current hardware uses a range of different mechanisms; therefore, the value of the "nicType" element SHOULD be included if the units are not known to be in dBm and the value reported by the hardware should be included without modification. This element includes optional "rmsError" and "samples" attributes.

Optional (as defined in the IETF I-D Held Measurements [I-D.ietf-geopriv-held-measurements] document.

ssid
channe
location
type
band
regclass
antenna
flightTime
apSignal

7.3.3.2. Bluetooth Measurements

Note: these need to be clarified and added to held-measurements.

Bluetooth devices provide an alternative method for determining location. The bluetooth object provides a method to capture measurements related to bluetooth devices discovered during the survey.

Address/UUID - 48-bit unique identifier
Name
Version
Manufacturer
Features
Class
Signal Strength
Link Quality

7.3.3.3. Other Signal Measurements

The container allows for the definition of other measurements to be captured. These could include measurements of such things as sound ranging or echolocation signals, cellular signals, or other electromagnetic signal measurement.

8. Example Surveys

Below are examples of several types of surveys.

8.1. WiFi Access Point Location Survey

A simple example of a small survey composed of two survey points is illustrated by the example message below. This uses the static beacon key survey model.

<sigpos xmlns="jones:sigpos"
        xmlns:pidf="urn:ietf:params:xml:ns:pidf"
        xmlns:cl="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
        xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
        xmlns:dyn="urn:ietf:params:xml:ns:pidf:geopriv10:dynamic"
        xmlns:rel="urn:ietf:params:xml:ns:pidf:geopriv10:relative"
        xmlns:vc="urn:ietf:params:xml:ns:vcard-4.0"
        xmlns:ap="http://example.com/airport/5.0"
        xmlns:gml="http://www.opengis.net/gml">
 <session sessionID=?axxwe82737?>
  <venue>
     <vc:vcard>
       <vc:fn><vc:text>Example Building</vc:text></vc:fn>
       <vc:adr>
         <vc:parameters>
           <vc:type><vc:text>work</vc:text></vc:type>
           <vc:label><vc:text>Example Building
   1 South Boston Street
   Boston, MA USA 02210</vc:text></vc:label>
         </pvc:arameters>
         <vc:pobox/>
         <vc:ext/>
         <vc:street>1 South Boston Street</vc:street>
         <vc:locality>Boston</vc:locality>
         <vc:region>MA</vc:region>
         <vc:code>02210</vc:code>
         <vc:country>USA</vc:country>
       </vc:adr>
     </vc:vcard>
     <owner>
       <vc:vcard>
         <vc:fn><text>Rober Builder</vc:text></vc:fn>
         <vc:n>
           <vc:surname>Builder</vc:surname>
           <vc:given>Robert</vc:given>
           <vc:additional/>
           <vc:prefix/>
           <vc:suffix/>
         </vc:n>
         <vc:adr>
           <vc:parameters>
             <vc:type><text>work</vc:text></vc:type>
             <vc:label><text>Rober Builder
   1 South Boston Street
   Boston, MA USA 02210</vc:text></vc:label>
           </vc:parameters>
           <vc:pobox/>
           <vc:ext/>
           <vc:street>1 South Boston Street</vc:street>
           <vc:locality>Boston</vc:locality>
           <vc:region>MA</vc:region>
           <vc:code>02210</vc:code>
           <vc:country>USA</vc:country>
         </vc:adr>
         <vc:tel>
           <vc:parameters>
             <vc:type>
               <vc:text>work</vc:text>
               <vc:text>voice</vc:text>
             </vc:type>
           </vc:parameters>
           <vc:uri>tel:+1-555-555-1212;ext=102</vc:uri>
         </vc:tel>
         <vc:email>
           <vc:parameters>
             <type><text>work</vc:text></vc:type>
           </vc:parameters>
           <vc:text>reober.builder@example.com</vc:text>
         </vc:email>
       </vc:vcard>
     </owner>
     <license>
       <license-type>CC BY</license-type>
     </license>
  </venue>
  <survey>
   <survey-point>
     <groundtruth>
       <pidf:presence>
        <pidf:tuple id="abcd123456">
         <pidf:status>
           <gp:geopriv>
             <gp:location-info>
               <gml:Point xmlns:gml="http://opengis.net/gml">
                 <gml:pos>-34.4 150.8</gml:pos>
               </gml:Point>
               <cl:civicAddress>
                 <cl:country>US</cl:country>
                 <cl:A1>CA</cl:A1>
                 <ap:airport>LAX</ap:airport>
                 <ap:terminal>Tom Bradley</ap:terminal>
                 <ap:concourse>G</ap:concourse>
                 <ap:gate>36B</ap:gate>
               </civicAddress>
             </gp:location-info>
           </gp:geopriv>
           <pidf:timestamp>2012-02-21T14:33:58:05</pidf:timestamp>
         </pidf:status>
        </pidf:tuple>
       </pidf:presence>
    </groundtruth>
    <beacon type="wifi">
      <mac>FF00FF723CBA</mac>
      <mac>FF00FF723CBB</mac>
    </beacon>
   </survey-point>
   <survey-point>
     <groundtruth>
       <pidf:presence>
        <pidf:tuple id="abcd123456">
         <pidf:status>
           <gp:geopriv>
             <gp:location-info>
                <gml:Point xmlns:gml="http://opengis.net/gml">
                  <gml:pos>-34.35 150.83</gml:pos>
                </gml:Point>
             </gp:location-info>
           </gp:geopriv>
           <pidf:timestamp>2012-02-21T14:33:58:06</pidf:timestamp>
         </pidf:status>
        </pidf:tuple>
       </pidf:presence>
      </groundtruth>
      <beacon type="wifi">
         <mac>FF00FF723A00</mac>
      </beacon>
   </survey-point>
  </survey>
 </session>
</sigpos>

802.11 WiFi Beacon Survey

8.2. WiFi Signal Survey

A simple example of wifi scan data conveyance using gps for ground truth is illustrated by the example message below.

<sigpos xmlns="jones:sigpos"
        xmlns:pidf="urn:ietf:params:xml:ns:pidf"
        xmlns:cl="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
        xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
        xmlns:dyn="urn:ietf:params:xml:ns:pidf:geopriv10:dynamic"
        xmlns:rel="urn:ietf:params:xml:ns:pidf:geopriv10:relative"
        xmlns:vc="urn:ietf:params:xml:ns:vcard-4.0"
        xmlns:ap="http://example.com/airport/5.0"
        xmlns:gml="http://www.opengis.net/gml">
 <session sessionID="axxwe82737">
 <venue>
     <vc:vcard>
       <vc:fn><vc:text>Example Building</vc:text></vc:fn>
       <vc:adr>
         <vc:parameters>
           <vc:type><vc:text>work</vc:text></vc:type>
           <vc:label><vc:text>Example Building
   1 South Boston Street
   Boston, MA USA 02210</vc:text></vc:label>
         </pvc:arameters>
         <vc:pobox/>
         <vc:ext/>
         <vc:street>1 South Boston Street</vc:street>
         <vc:locality>Boston</vc:locality>
         <vc:region>MA</vc:region>
         <vc:code>02210</vc:code>
         <vc:country>USA</vc:country>
       </vc:adr>
     </vc:vcard>
     <owner>
       <vc:vcard>
         <vc:fn><text>Rober Builder</vc:text></vc:fn>
         <vc:n>
           <vc:surname>Builder</vc:surname>
           <vc:given>Robert</vc:given>
           <vc:additional/>
           <vc:prefix/>
           <vc:suffix/>
         </vc:n>
         <vc:adr>
           <vc:parameters>
             <vc:type><text>work</vc:text></vc:type>
             <vc:label><text>Rober Builder
   1 South Boston Street
   Boston, MA USA 02210</vc:text></vc:label>
           </vc:parameters>
           <vc:pobox/>
           <vc:ext/>
           <vc:street>1 South Boston Street</vc:street>
           <vc:locality>Boston</vc:locality>
           <vc:region>MA</vc:region>
           <vc:code>02210</vc:code>
           <vc:country>USA</vc:country>
         </vc:adr>
         <vc:tel>
           <vc:parameters>
             <vc:type>
               <vc:text>work</vc:text>
               <vc:text>voice</vc:text>
             </vc:type>
           </vc:parameters>
           <vc:uri>tel:+1-555-555-1212;ext=102</vc:uri>
         </vc:tel>
         <vc:email>
           <vc:parameters>
             <type><text>work</vc:text></vc:type>
           </vc:parameters>
           <vc:text>reober.builder@example.com</vc:text>
         </vc:email>
       </vc:vcard>
     </owner>
     <license>
       <license-type>unrestricted</license-type>
       <licenseExpiry>2012-10-29T14:33:58</licenseExpiry>
     </license>
  </venue>
  <device>
    <configuration>
      <id>00EFDA7200B004</id>
      <name>lumina</name>
      <type>smartphone</type>
      <model>900</model>
      <version>1.2</version>
    </configuration>
    <sensor>
      <configuration>
        <type>wifi</type>
        <id>ath0</id>
        <antenna>omni-directional</antenna>
        <chipset>aetheros</chipset>
        <manufacturer>newco</manufacturer>
        <capabilities>
          <standard>a,b,g,n</standard>
          <frequencyband>1-13</frequencyband>
        </capabilities>
      </configuration>
    </sensor>
    <sensor>
      <configuration>
        <type>gps</type>
        <id>gps3210</id>
        <antenna>combined</antenna>
        <chipset>qualcomm</chipset>
        <manufacturer>newco</manufacturer>
        <capabilities>
          <type>standard</type>
        </capabilities>
      </configuration>
    </sensor>
  </device>
  <survey>
   <survey-point>
     <groundtruth>
       <pidf:presence>
        <pidf:tuple id="abcd123456">
         <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>

802.11 WiFi Signal Scan Survey

9. Acknowledgements

This template was derived from an initial version written by Pekka Savola and contributed by him to the xml2rfc project. Thanks to Richard Barnes and Stéphane Terrenoir for initial reviews and valuable feedback.

10. IANA Considerations

This section creates a registry for Data License types [LicenseType] and registers the namesapces and schema defined in the Schemas [Schemas] secction.

All drafts are required to have an IANA considerations section (see the update of RFC 2434 [RFC5226] for a guide). If the draft does not require IANA to do anything, the section contains an explicit statement that this is the case (as above). If there are no requirements for IANA, the section will be removed during conversion into an RFC by the RFC Editor.

10.1. IANA Registry for Data License Types

This document establishes a new IANA registry for the for Data License types [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:

Data License name: the name of the data license
Brief Description: a brief description of the data license
URI: optional URI to the license definition

This section pre-registers 8 new 'licenseType' tokens associated with the 'licenseType'

unrestricted: allows for the use and unrestricted derivative products based on the data set

unrestricted: this license allows for the use and unrestricted derivative products based on the data set
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.
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.
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.
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.
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.
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.
private: this license is intended to provide full control over the ownership, usage, and derivative usage of the data. Any use of the data would be governed under a separate agreement between the owner and the party wishing to make use of the data. By default, no rights are granted for private data.

11. Schemas

This section provides a formal definition of the combined XML schema for encoding survey data.

12. Security Considerations

Location-related measurement data can be as privacy sensitive as location information.

Survey data is effectively equivalent to location information if the contextual knowledge necessary to generate one from the other is readily accessible. Even where contextual knowledge is difficult to acquire, there can be no assurance that an authorized recipient of the contextual knowledge is also authorized to receive location information.

In order to protect the privacy of the subject of location-related survey data, this implies that survey data is protected with a similar degree of protection as location information.

Survey Data Privacy Model

In general, survey data represents a smaller privacy risk than personal location information. It does however represent potential privacy risks especially with respect to venues which have security risks or wish to maintain control over the exposure of detailed location information.

No entity is permitted to redistribute survey data except as specified in the data license. The Device directs other entities in how survey data is used and retained.

13. References

13.1. Normative References

[RFC2119]	Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4119]	Peterson, J., "A Presence-based GEOPRIV Location Object Format", RFC 4119, December 2005.
[RFC5139]	Thomson, M. and J. Winterbottom, "Revised Civic Location Format for Presence Information Data Format Location Object (PIDF-LO)", RFC 5139, February 2008.
[RFC5491]	Winterbottom, J., Thomson, M. and H. Tschofenig, "GEOPRIV Presence Information Data Format Location Object (PIDF-LO) Usage Clarification, Considerations, and Recommendations", RFC 5491, March 2009.
[RFC5962]	Schulzrinne, H., Singh, V., Tschofenig, H. and M. Thomson, "Dynamic Extensions to the Presence Information Data Format Location Object (PIDF-LO)", RFC 5962, September 2010.
[RFC6351]	Perreault, S., "xCard: vCard XML Representation", RFC 6351, August 2011.
[I-D.ietf-geopriv-held-measurements]	Thomson, M and J Winterbottom, "Using Device-provided Location-Related Measurements in Location Configuration Protocols", Internet-Draft draft-ietf-geopriv-held-measurements-04, October 2011.
[I-D.ietf-geopriv-local-civic]	Winterbottom, J, Thomson, M, Barnes, R, Rosen, B and R George, "Specifying Civic Address Extensions in PIDF-LO", Internet-Draft draft-ietf-geopriv-local-civic-03, February 2012.
[I-D.ietf-geopriv-relative-location]	Thomson, M, Stanley, D, Rosen, B, Thomson, A and G Bajko, "Relative Location Representation", Internet-Draft draft-ietf-geopriv-relative-location-02, October 2011.

13.2. Informative References

, ", ", ", "

[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.

Author's Address

Kipp Jones Skyhook Wireless 34 Farnsworth Street Boston, 02210 US Phone: +1 (617) 234-9802 EMail: kjones@skyhookwireless.com