Specifying a Circular Uncertainty Area Using DHCP

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.

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 .

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 . PIDF-LO Profile relies on geoshape requires all coordinates to be specified using WGS-84, consequently the coordinates used in this memo are specified using WGS-84. GML uses the ISO 19107 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 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 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 . 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.

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

The IANA assigned option number (TBD). The length of this option octets (18). 8 octets representing the the latitude of the central point of a circle, expressed as an double. 8 octets representing the the longitude of the central point of a circle, expressed as an double. a 16 bit unsigned integer expressing the radius of the circle in metres.

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.

The IANA assigned option number (TBD). The length of this option in octets (18). 8 octets representing the the latitude of the central point of a circle, expressed as an double. 8 octets representing the the longitude of the central point of a circle, expressed as an double. a 16 bit unsigned integer expressing the radius of the circle in metres.

PIDF-LO Profile describes how a circle is expressed in GML and included in a PIDF-LO . The latitude and longitude components of this encoding form the central point of the circle.

/ `b. .d' / `b. :: / :: :: C :: :: ^ :: `p. | .q' `p. Centre .q' `b. .d' `q.. ..p' ^q.........p^ ]]> The XML for the resulting circle is shown in (assuming the centre is represented as 42.5463 -73.2512) and the radius is 5 meters.

42.5463 -73.2512 5

DHCP

]]>

The security issues for this document are the same as for RFC3825 .

There are no specific IANA considerations for this document.

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.