TOC 
GeoprivH. Tschofenig
Internet-DraftNokia Siemens Networks
Intended status: Standards TrackJ. Winterbottom
Expires: August 21, 2008Andrew Corporation
 February 18, 2008


Specifying a Circular Uncertainty Area Using DHCP
draft-tschofenig-geopriv-dhcp-circle-00.txt

Status of this Memo

By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.

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

The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.

This Internet-Draft will expire on August 21, 2008.

Abstract

This document specifies how a circular area representing the location of device can be returned using DHCP. The document also shows how the data returned from DHCP can be encoded into GML for using in a PIDF-LO in an unambiguous or contentious manner.

This document is a contribution to the ongoing discussion on RFC 3825; it represents one possible solution to address the discussed issues.



Table of Contents

1.  Introduction
2.  Terminology
3.  Details and Rationale
    3.1.  DHCPv4 Option for a Circular Location
    3.2.  DHCPv6 Option for a LIS Address
4.  Expressing the Circle in GML
5.  Security Considerations
6.  IANA Considerations
7.  Acknowledgements
8.  Normative References
§  Authors' Addresses
§  Intellectual Property and Copyright Statements




 TOC 

1.  Introduction

Location provided by GPS device and like generally provide location information as a point with a degree of uncertainty. This uncertainty is more often than not expressed as an offset in metres from the central point, with the resulting location being a circle when expressed in 2 dimensions, and a sphere when expressed in 3 dimensions. This memo presupposes that locations have been measured, for example using a GPS, ahead of time and have subsequently been stored in a wiremap database. Associations between end-devices and location can be done using DHCP option 82 or other methods where appropriate.

This document omits an altitude representation based on the envisioned usage scenario.



 TOC 

2.  Terminology

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 [RFC2119] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).



 TOC 

3.  Details and Rationale

The intent of this specification is to provide a location to an end-device so that it can easily represent it as circle in GML in accordance with PIDF-LO Profile [I‑D.ietf‑geopriv‑pdif‑lo‑profile] (Winterbottom, J., Thomson, M., and H. Tschofenig, “GEOPRIV PIDF-LO Usage Clarification, Considerations and Recommendations,” November 2008.). PIDF-LO Profile relies on geoshape [geoshape] (Thomson, M. and C. Reed, “GML 3.1.1 PIDF-LO Shape Application Schema for use by the Internet Engineering Task Force (IETF),” April 2007.) requires all coordinates to be specified using WGS-84, consequently the coordinates used in this memo are specified using WGS-84.

GML [gml] (Cox, S., Daisey, P., Lake, R., Portele, C., and A. Whiteside, “Geographic information - Geography Markup Language (GML),” April 2004.) uses the ISO 19107 [ISO‑19107] (ISO, “Geographic information - Spatial Schema,” 5 2003.) definition of a point, and quotes this as being "0-dimensional geometric primitive, representing a position. NOTE The boundary of a point is the empty set." At some point however, it becomes necessary to express the coordinates that make up the location in bits and bytes. Since the intent is to use GML as the final representation, the encoding standards and limitations expressed by GML are used.

GML is an XML language [xml] (W3C, “XML Schema Part 2: Datatypes Second Edition,” October 2004.) for expressing location information, and XML defines mappings between its primative types and standard binary encodings. The GML point is made up of XML (xsd) doubles, and an XML double is expressed as an IEEE 754-1985 [IEEE‑754‑1985] (IEEE, “754-1985 IEEE Standard for Binary Floating-Point Arithmetic,” January 2003.) double-precision floating point number. This means that a latitude or longitude in GML is expressed as a 64 bit binary number, but in accordance with the previous definition is interpretted as being zero dimensional, without area.

The binary encodings provided in this memo express latitude and longitude values as 64 bit binary floating-point numbers, as defined in [IEEE‑754‑1985] (IEEE, “754-1985 IEEE Standard for Binary Floating-Point Arithmetic,” January 2003.). A radius is defined as a positive offset to this in metres, and is expressed as an unsigned 16 bit integer. This allows a circle with a radius in the order of 65.5km to be expressed without difficulty, and for a point with no specified uncertainty to be provided where the radius is set to zero.



 TOC 

3.1.  DHCPv4 Option for a Circular Location

This section defines a DHCP for IPv4 (DHCPv4) option for the point with radius of uncertainty.



 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  LOC-CIRCLE   |    Length     |         Latitude              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                     Latitude continued                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      Latitude Continued       |         Longitude             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                     Longitude continued                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      Longitude Continued      |           Radius              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 DHCPv4 Option 

LOC-CIRCLE:
The IANA assigned option number (TBD).
Length:
The length of this option octets (18).
Latitude:
8 octets representing the the latitude of the central point of a circle, expressed as an [IEEE‑754‑1985] (IEEE, “754-1985 IEEE Standard for Binary Floating-Point Arithmetic,” January 2003.) double.
Longitude:
8 octets representing the the longitude of the central point of a circle, expressed as an [IEEE‑754‑1985] (IEEE, “754-1985 IEEE Standard for Binary Floating-Point Arithmetic,” January 2003.) double.
Radius:
a 16 bit unsigned integer expressing the radius of the circle in metres.



 TOC 

3.2.  DHCPv6 Option for a LIS Address

This section defines a DHCP for IPv6 (DHCPv6) option for the point with radius of uncertainty. The DHCPv6 option for this parameter is similarly formatted to the DHCPv4 option.



 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         LOC-CIRCLE            |           Length              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           Latitude                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                     Latitude continued                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          Longitude                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                     Longitude continued                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             Radius            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 DHCPv6 Option 

LOC-CIRCLE:
The IANA assigned option number (TBD).
Length:
The length of this option in octets (18).
Latitude:
8 octets representing the the latitude of the central point of a circle, expressed as an [IEEE‑754‑1985] (IEEE, “754-1985 IEEE Standard for Binary Floating-Point Arithmetic,” January 2003.) double.
Longitude:
8 octets representing the the longitude of the central point of a circle, expressed as an [IEEE‑754‑1985] (IEEE, “754-1985 IEEE Standard for Binary Floating-Point Arithmetic,” January 2003.) double.
Radius:
a 16 bit unsigned integer expressing the radius of the circle in metres.



 TOC 

4.  Expressing the Circle in GML

PIDF-LO Profile [I‑D.ietf‑geopriv‑pdif‑lo‑profile] (Winterbottom, J., Thomson, M., and H. Tschofenig, “GEOPRIV PIDF-LO Usage Clarification, Considerations and Recommendations,” November 2008.) describes how a circle is expressed in GML and included in a PIDF-LO [RFC4119] (Peterson, J., “A Presence-based GEOPRIV Location Object Format,” December 2005.). The latitude and longitude components of this encoding form the central point of the circle.



       _d^^^^^^^^^b_
    .d''           ``b.
  .p'             /   `q.
 .d'    Radius-> /     `b.
.d'             /       `b.
::             /         ::
::           C           ::
::           ^           ::
`p.          |          .q'
 `p.      Centre      .q'
  `b.                .d'
    `q..          ..p'
      ^q.........p^

 Figure 1: Circle Representation 

The XML for the resulting circle is shown in Figure 2 (Resulting XML and PIDF-LO) (assuming the centre is represented as 42.5463 -73.2512) and the radius is 5 meters.



<?xml version="1.0" encoding="UTF-8"?>
<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:gs="http://www.opengis.net/pidflo/1.0"
 xmlns:gml="http://www.opengis.net/gml"
   entity="pres:circle@example.com">
  <tuple id="sg89ab1">
    <status>
      <gp:geopriv>
        <gp:location-info>
          <gs:Circle srsName="urn:ogc:def:crs:EPSG::4326">
               <gml:pos>
                  42.5463 -73.2512
               </gml:pos>
               <gml:radius uom="urn:ogc:def:uom:EPSG::9001">
                  5
               </gml:radius>
          </gs:Circle>
        </gp:location-info>
        <usage-rules/>
        <method>DHCP</method>
      </gp:geopriv>
    </status>
  </tuple>
</presence>

 Figure 2: Resulting XML and PIDF-LO 



 TOC 

5.  Security Considerations

The security issues for this document are the same as for RFC3825 [RFC3825] (Polk, J., Schnizlein, J., and M. Linsner, “Dynamic Host Configuration Protocol Option for Coordinate-based Location Configuration Information,” July 2004.).



 TOC 

6.  IANA Considerations

There are no specific IANA considerations for this document.



 TOC 

7.  Acknowledgements

The authors contribute this document to the ongoing discussion in the GEOPRIV working group. Still, the authors believe that it would be necessary to investigate the intended deployment use cases more in order to evaluate what additional location shapes are likely to be used and whether there is interest in using DHCP (or lower layer protocols developed by the IEEE or TIA) for conveying location information or whether there is more interest to use these protocols purely to discover a LIS and allow more flexibility with regard to the supported location shapes.



 TOC 

8. Normative References

[RFC2119] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” BCP 14, RFC 2119, March 1997 (TXT, HTML, XML).
[I-D.ietf-geopriv-pdif-lo-profile] Winterbottom, J., Thomson, M., and H. Tschofenig, “GEOPRIV PIDF-LO Usage Clarification, Considerations and Recommendations,” draft-ietf-geopriv-pdif-lo-profile-14 (work in progress), November 2008 (TXT).
[RFC4119] Peterson, J., “A Presence-based GEOPRIV Location Object Format,” RFC 4119, December 2005 (TXT).
[RFC3825] Polk, J., Schnizlein, J., and M. Linsner, “Dynamic Host Configuration Protocol Option for Coordinate-based Location Configuration Information,” RFC 3825, July 2004 (TXT).
[geoshape] Thomson, M. and C. Reed, “GML 3.1.1 PIDF-LO Shape Application Schema for use by the Internet Engineering Task Force (IETF),” Candidate OpenGIS Implementation Specification 06-142r1, Version: 1.0, April 2007.
[ISO-19107] ISO, “Geographic information - Spatial Schema,” ISO Standard 19107, First Edition, 5 2003.
[gml] Cox, S., Daisey, P., Lake, R., Portele, C., and A. Whiteside, “Geographic information - Geography Markup Language (GML),” OpenGIS 03-105r1, April 2004.
[xml] W3C, “XML Schema Part 2: Datatypes Second Edition,” October 2004.
[IEEE-754-1985] IEEE, “754-1985 IEEE Standard for Binary Floating-Point Arithmetic,” January 2003.


 TOC 

Authors' Addresses

  Hannes Tschofenig
  Nokia Siemens Networks
  Otto-Hahn-Ring 6
  Munich, Bavaria 81739
  Germany
Phone:  +49 89 636 40390
Email:  Hannes.Tschofenig@nsn.com
URI:  http://www.tschofenig.com
  
  James Winterbottom
  Andrew Corporation
  PO Box U40
  University of Wollongong, NSW 2500
  AU
Email:  james.winterbottom@andrew.com


 TOC 

Full Copyright Statement

Intellectual Property