Geopriv J. Winterbottom Internet-Draft M. Thomson Expires: November 3, 2006 Andrew Corporation H. Tschofenig Siemens May 2, 2006 GEOPRIV PIDF-LO Usage Clarification, Considerations and Recommendations draft-ietf-geopriv-pdif-lo-profile-04.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 November 3, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract The Presence Information Data Format Location Object (PIDF-LO) specification provides a flexible and versatile means to represent location information. There are, however, circumstances that arise when information needs to be constrained in how it is represented so that the number of options that need to be implemented in order to make use of it are reduced. There is growing interest in being able Winterbottom, et al. Expires November 3, 2006 [Page 1] Internet-Draft GEOPRIV PIDF-LO Profile May 2006 to use location information contained in a PIDF-LO for routing applications. To allow successfully interoperability between applications, location information needs to be normative and more tightly constrained than is currently specified in the PIDF-LO. This document makes recommendations on how to constrain, represent and interpret locations in a PIDF-LO. It further recommends a subset of GML that MUST be implemented by applications involved in location based routing. Table of Contents 1. CHANGES SINCE LAST TIME . . . . . . . . . . . . . . . . . . . 3 1.1. 04 changes . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. 03 changes . . . . . . . . . . . . . . . . . . . . . . . . 3 1.3. 01 changes . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Using Location Information . . . . . . . . . . . . . . . . . . 7 4.1. Single Civic Location Information . . . . . . . . . . . . 8 4.2. Civic and Geospatial Location Information . . . . . . . . 9 4.3. Manual/Automatic Configuration of Location Information . . 12 5. Geodetic Coordinate Representation . . . . . . . . . . . . . . 13 6. Geodetic Shape Representation . . . . . . . . . . . . . . . . 14 6.1. Polygon Restriction . . . . . . . . . . . . . . . . . . . 15 6.2. Emergency Shape Representations . . . . . . . . . . . . . 15 7. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 16 8. Security Considerations . . . . . . . . . . . . . . . . . . . 17 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 11.1. Normative references . . . . . . . . . . . . . . . . . . . 20 11.2. Informative References . . . . . . . . . . . . . . . . . . 20 Appendix A. Uncertainty in The RFC-3825 LCI Representation . . . 21 A.1. Conversion From LCI Form . . . . . . . . . . . . . . . . . 21 A.2. Conversion To LCI Form . . . . . . . . . . . . . . . . . . 22 A.2.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . 22 A.2.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . 23 A.3. Problem . . . . . . . . . . . . . . . . . . . . . . . . . 23 A.4. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . 23 Appendix B. Creating a PIDF-LO from DHCP Geo Encoded Data . . . . 25 B.1. Latitude and Longitude . . . . . . . . . . . . . . . . . . 25 B.2. Altitude . . . . . . . . . . . . . . . . . . . . . . . . . 27 B.3. Generating the PIDF-LO . . . . . . . . . . . . . . . . . . 27 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 32 Intellectual Property and Copyright Statements . . . . . . . . . . 33 Winterbottom, et al. Expires November 3, 2006 [Page 2] Internet-Draft GEOPRIV PIDF-LO Profile May 2006 1. CHANGES SINCE LAST TIME [[This section is informational only and will be removed before the final version.]] 1.1. 04 changes Added a section to recommend restricting Polygon to 16 points for routing and other real-time applications. Added section detailing caution when selecting shapes for emergency routing. Modified the recommendations section to include the two above additions. Added a second appendix detailing problems with expressing uncertainty using LCI. 1.2. 03 changes Removed some shape definitions, ellipses, arcbands. Removed OMA shape definition comparisons. Modified examples to use new civicAddr draft data. Made extensive references to the GeoShape Draft. 1.3. 01 changes minor changes to the abstract. Minor changes to the introduction. Added and appendix to take implementers through how to create a PIDF-LO from data received using DHCP option 123 as defined in [3]. Rectified examples to use position and pos rather than location and point. Corrected example 3 so that it does not violate SIP rules. Added addition geopriv elements to the status component of the figure in "Using Location Information" to more accurately reflect the cardinality issues. Revised text in section Geodetic Coordinate Representation. Removed Winterbottom, et al. Expires November 3, 2006 [Page 3] Internet-Draft GEOPRIV PIDF-LO Profile May 2006 last example as this was addressed with the change to position and pos in previous examples. Winterbottom, et al. Expires November 3, 2006 [Page 4] Internet-Draft GEOPRIV PIDF-LO Profile May 2006 2. Introduction The Presence Information Data Format Location Object (PIDF-LO) [2] is the IETF recommended way of encoding location information and associated privacy policies. Location information in a PIDF-LO may be described in a geospatial manner based on a subset of GMLv3, or as civic location information [5]. A GML profile for expressing geodetic shapes in a PIDF-LO is described in [6].Uses for PIDF-LO are envisioned in the context of numerous location based applications. This document makes recommendations for formats and conventions to make interoperability less problematic. Winterbottom, et al. Expires November 3, 2006 [Page 5] Internet-Draft GEOPRIV PIDF-LO Profile May 2006 3. 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 [1]. In this document a "discrete location" is defined as a location that can be found based on the information used to describe it. It is not necessarily a single point in space, but may be an area or volume depending on what is being defined and the required precision. Winterbottom, et al. Expires November 3, 2006 [Page 6] Internet-Draft GEOPRIV PIDF-LO Profile May 2006 4. Using Location Information The PIDF format provides for an unbounded number of tuples. The geopriv element resides inside the status component of a tuple, hence a single PIDF document may contain an arbitrary number of location objects some or all of which may be contradictory or complementary. The actual location information is contained inside a element, and there may be one or more actual locations described inside the element. Graphically, the structure of the PIDF/PIDF-LO can be depicted as follows: PIDF document tuple 1 status geopriv location-info civicAddress location usage-rules geopriv 2 geopriv 3 . . . tuple 2 tuple 3 All of these potential sources and storage places for location lead to confusion for the generators, conveyors and users of location information. Practical experience within the United States National Emergency Number Association (NENA) in trying to solve these ambiguities led the following conventions being adopted: Rule #1: A geopriv element MUST describe a discrete location. Rule #2: Where a discrete location can be uniquely described in more than one way, each location description SHOULD reside in a separate tuple. Winterbottom, et al. Expires November 3, 2006 [Page 7] Internet-Draft GEOPRIV PIDF-LO Profile May 2006 Rule #3: Providing more than one location in a single presence document (PIDF) MUST only be done if all objects describe the same location. Rule #4: Providing more than one location in a single element SHOULD be avoided where possible. Rule #5: When providing more than one location in a single element the locations MUST be provided by a common source. Rule #6: Providing more than one location in a single element SHOULD only be done if they form a complex to describe the same location. For example, a geodetic location describing a point, and a civic location indicating the floor in a building. Rule #7: Where a location complex is provided in a single element, the macro locations MUST be provided first. For example, a geodetic location describing an area, and a civic location indicating the floor MUST be represented with the area first followed by the civic location. Rule #8: Where a PIDF document contains more than one tuple containing a status element with a geopriv location element , the priority of tuples SHOULD be based on tuple position within the PIDF document. That is to say, the tuple with the highest priority location occurs earliest in the PIDF document. Initial priority SHOULD be determined by the originating UA, the final priority MAY be determined by a proxy along the way, or the UAS. Rule #9: Where multiple PIDF documents are contained within a single request, document selection SHOULD be based on document order. The following examples illustrate the application of these rules. 4.1. Single Civic Location Information Jane is at a coffee shop on the ground floor of a large shopping mall. Jane turns on her laptop and connects to the coffee-shop's WiFi hotspot, Jane obtains a complete civic address for her current location, for example using the DHCP Civic mechanism defined in [4]. A Location Object is constructed consisting of a single PIDF document, with a single geopriv tuple, and a single location residing Winterbottom, et al. Expires November 3, 2006 [Page 8] Internet-Draft GEOPRIV PIDF-LO Profile May 2006 in the element. This document is unambiguous, and should be interpreted consitently by receiving nodes if sent over the network. 4.2. Civic and Geospatial Location Information Mike is visiting his Seattle office and connects his laptop into the Ethernet port in a spare cube. Mike's computer receives a location over DHCP as defined in RFC-3825 [3]. In this case the location is a geodetic location, with the altitude represented as a building floor number. This is constructed by Mike's computer into the following PIDF document: Winterbottom, et al. Expires November 3, 2006 [Page 9] Internet-Draft GEOPRIV PIDF-LO Profile May 2006 2 2006-01-30T20:57:29Z 37.775 -122.4194 37.555 -122.4194 37.555 -122.4264 37.775 -122.4264 37.775 -122.4194 2006-01-30T20:57:29Z The constructed PIDF document contains two geopriv elements each in a separate PIDF tuple, the first being a civic address made up of only floor, the second containing the provided geodetic information. If the location is required for routing purposes, which information is Winterbottom, et al. Expires November 3, 2006 [Page 10] Internet-Draft GEOPRIV PIDF-LO Profile May 2006 used? Applying rule #8, we will likely fail, or at a minimum need to fall back to the second tuple describing the geodetic location, a route described by floor only is not precise enough in the normal case to permit route selection. If rule #6 and #7 are applied, then the revised PIDF-LO document creates a complex as shown below. 37.775 -122.4194 37.555 -122.4194 37.555 -122.4264 37.775 -122.4264 37.775 -122.4194 2 2003-06-22T20:57:29Z It is now clear that the main location of user is inside the rectangle bounded by the geodetic coordinates specified. Further that the user is on the second floor of the building located at these coordinates. Winterbottom, et al. Expires November 3, 2006 [Page 11] Internet-Draft GEOPRIV PIDF-LO Profile May 2006 4.3. Manual/Automatic Configuration of Location Information Loraine has a predefined civic location stored in her laptop, since she normally lives in Sydney, the address in her address is for her Sydney-based apartment. Loraine decides to visit sunny San Francisco, and when she gets there she plugs in her laptop and makes a call. Loraine's laptop receives a new location from the visited network in San Francisco. As this system cannot be sure that the pre-existing and new location describe the same place, Loraine's computer generates a new PIDF-LO and will use this to represent Loraine's location. If Loraine's computer were to add the new location to her existing PIDF location document (breaking rule #3), then the correct information may still be interpreted by location recipient providing Loraine's system applies rule #9. In this case the resulting order of location information in the PIDF document should be San Francisco first, followed by Sydney. Since the information is provided by different sources, rule #8 should also be applied and the information placed in different tuples with San Francisco first. Winterbottom, et al. Expires November 3, 2006 [Page 12] Internet-Draft GEOPRIV PIDF-LO Profile May 2006 5. Geodetic Coordinate Representation The geodetic examples provided in RFC-4119 [2] are illustrated using the gml:location element which uses the gml:coordinates elements (inside the gml:Point element) and this representation has several drawbacks. Firstly, it has been deprecated in later versions of GML (3.1 and beyond) making it inadvisable to use for new applications. Secondly, the format of the coordinates type is opaque and so can be difficult to parse and interpret to ensure consistent results, as the same geodetic location can be expressed in a variety of ways. The PIDF-LO Geodetic Shapes specification [6] provides a specific GML profile for expressing commonly used shapes using simple GML representations. The shapes defined in [6] are the recommended shapes to ensure interoperability between location based applications. Winterbottom, et al. Expires November 3, 2006 [Page 13] Internet-Draft GEOPRIV PIDF-LO Profile May 2006 6. Geodetic Shape Representation The cellular mobile world today makes extensive use of geodetic based location information for emergency and other location-based applications. Generally these locations are expressed as a point (either in two or three dimensions) and an area or volume of uncertainty around the point. In theory, the area or volume represents a coverage in which the user has a relatively high probability of being found, and the point is a convenient means of defining the centroid for the area or volume. In practice, most systems use the point as an absolute value and ignore the uncertainty. It is difficult to determine if systems have been implement in this manner for simplicity, and even more difficult to predict if uncertainty will play a more important role in the future. An important decision is whether an uncertainty area should be specified. The PIDF-LO Geodetic Shapes specification [6] defines eight shape types most of which are easily translated in shapes definitions used in other applications and protocol, such as Open Mobile Alliance (OMA) Mobile Location Protocol (MLP). For completeness the shape defined in [6] are listed below: o Point (2d or 3d) o Polygon (2d) o Circle (2d) o Ellipse (2d) o Arc band (2d) o Sphere (3d circle) o Ellipsoid (3d) o Prism (3d polygon) The GeoShape specification [6] also describes a standard set of coordinate reference systems (CRS), unit of measure and conventions relating to lines and distances. GeoShape mandates the use the WGS-84 Coordinate reference system and restricts usage to EPSG-4326 for two dimensional (2d) shape representations and EPSG-4979 for three dimensional (3d) volume representations. Distance and heights are expressed in metres using EPSG-9001. Winterbottom, et al. Expires November 3, 2006 [Page 14] Internet-Draft GEOPRIV PIDF-LO Profile May 2006 6.1. Polygon Restriction The Polygon shape type defined in [6] intentionally does not place any constraints on the number of points that may be included to define the bounds of the Polygon. This allows arbitrarily complex shapes to be defined and conveyed in a PIDF-LO. However where location information is to be used in real-time processing applications, such as location dependent routing, having arbitrarily complex shapes consisting of tens or even hundreds of points may result in significant performance impacts. To mitigate this risk it is recommended that Polygons be restricted to a maximum of 16 points when the location information is intended for use in real-time applications. This limit of 16 points is chosen to allow moderately complex shape definitions while at the same time enabling interworking with other location transporting protocols such as those defined in 3GPP ([7]) and OMA where the 16 point limit is already imposed. 6.2. Emergency Shape Representations In some parts of the world cellular networks constraints are placed on the shape types that can be used to represent the location of an emergency caller. These restrictions, while to some extend are artificial, may pose significant interoperability problems in emergency networks were they to be unilaterally lifted. The largest impact likely being on PSAP CPE where multiple communication networks report emergency data. Wholesale swap-out or upgrading of this equipment is deemed to be complex and costly and has resulted in a number of countries, most notably the United States, to adopt migratory standards towards emergency IP telephony support. Where these migratory standards are implemented restrictions on acceptable geodetic shape types to represent the location of an emergency caller may exist and MUST be adhered to. Conversion from one shape type to another should be avoided to eliminate the introduction of errors in reported location. In North America the migratory VoIP emergency services standard (i2) implicitly imposes the restriction ([10]) that the geodetic shape be constrained to a point, point and uncertain circle, point with altitude and uncertainty circle. These shapes can be easily represented using the GeoShape specification and map to Point, Circle and Sphere respectively. Winterbottom, et al. Expires November 3, 2006 [Page 15] Internet-Draft GEOPRIV PIDF-LO Profile May 2006 7. Recommendations As a summary this document gives a few recommendations on the usage of location information in PIDF-LO. Nine rules specified in Section 4 give guidelines on the ambiguity of PIDF-LO with regard to the occurrence of multiple locations. It is recommend that only the shape types and shape representations described in [6] be used to express geodetic locations for exchange between general applications. By standardizing geodetic data representation interoperability issues are mitigated. It is recommended that Polygons be restricted to a maximum of 16 points when used in location-dependent routing and other real-time applications to mitigate possible performance issues. This allows for interoperability with other location protocols where this restriction applies. Geodetic location may require restricted shape definitions in regions where migratory emergency IP telephony implementations are deployed. Where the acceptable shape types are not understood restrictions to Point, Circle and Sphere representations should be used to accommodate most existing deployments. Conversions from one geodetic shape type to another should be avoided where data is considered critical and the introduction of errors considered unacceptable. If Geodetic information is to be provided via DHCP, then a minimum resolution of 20 bits SHOULD be specified for both the Latitude and Longitude fields to achieve sub 100 metre precision. Where only two dimensional objects are required polygons SHOULD be used to express the enclosed area. Where 3 dimensions are required a rectangular prism SHOULD be used. Winterbottom, et al. Expires November 3, 2006 [Page 16] Internet-Draft GEOPRIV PIDF-LO Profile May 2006 8. Security Considerations The primary security considerations relate to how location information is conveyed and used, which are outside the scope of this document. This document is intended to serve only as a set of guidelines as to which elements MUST or SHOULD be implemented by systems wishing to perform location dependent routing. The ramification of such recommendations is that they extend to devices and clients that wish to make use of such services. Winterbottom, et al. Expires November 3, 2006 [Page 17] Internet-Draft GEOPRIV PIDF-LO Profile May 2006 9. IANA Considerations This document does not introduce any IANA considerations. Winterbottom, et al. Expires November 3, 2006 [Page 18] Internet-Draft GEOPRIV PIDF-LO Profile May 2006 10. Acknowledgments The authors would like to thank the GEOPRIV working group for their discussions in the context of PIDF-LO, in particular Carl Reed, Ron Lake, James Polk and Henning Schulzrinne. Furthermore, we would like to thank Jon Peterson as the author of PIDF-LO and Nadine Abbott for her constructive comments in clarifying some aspects of the document. Winterbottom, et al. Expires November 3, 2006 [Page 19] Internet-Draft GEOPRIV PIDF-LO Profile May 2006 11. References 11.1. Normative references [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", March 1997. [2] Peterson, J., "A Presence-based GEOPRIV Location Object Format", RFC 4119, December 2005. [3] Polk, J., Schnizlein, J., and M. Linsner, "Dynamic Host Configuration Protocol Option for Coordinate-based Location Configuration Information", RFC 3825, July 2004. [4] Schulzrinne, H., "Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration Information", draft-ietf-geopriv-dhcp-civil-09 (work in progress), January 2006. [5] Thomson, M. and J. Winterbottom, "Revised Civic Location Format for PIDF-LO", draft-ietf-geopriv-revised-civic-lo-02 (work in progress), April 2006. [6] Thomson, M., "draft-thomson-geopriv-geo-shape, Geodetic Shapes for the Representation of Uncertainty in PIDF-LO", January 2006. 11.2. Informative References [7] "3GPP TS 23.032 V6.0.0 3rd Generation Partnership Project; Technical Specification Group Code Network; Universal Geographic Area Description (GAD)". [8] Schulzrinne, H., "A Document Format for Expressing Privacy Preferences", draft-ietf-geopriv-common-policy-09 (work in progress), April 2006. [9] "TR-45 J-STD-036-AD-2 Enhanced Wireless 9-1-1 Phase 2". [10] "NENA Standard for the Implementation of the Wireless Emergency Service Protocol E2 Interface". Winterbottom, et al. Expires November 3, 2006 [Page 20] Internet-Draft GEOPRIV PIDF-LO Profile May 2006 Appendix A. Uncertainty in The RFC-3825 LCI Representation This Appendix should be regarded as informative only and provides guidance on aspects concerning the interpretation of uncertainty as it applies to the binary geodetic LCI representation defined in RFC- 3825 [3]. No recommendation on the use or otherwise of LCI in applications is made. However the risks of introducing large errors into reported location when LCI is used to represent uncertainty are clearly explained. RFC-3825 [3] defines a binary geodetic representation referred to as LCI. The way that LCI represents uncertainty is through a resolution parameter that indicates how many binary digits of each axis are significant or accurate. This is explained in detail in [3] with a series of examples with a further example provided in Appendix B of this document. In short LCI describes a rectangular prism that is aligned along the north-south/east-west/up-down axes. A.1. Conversion From LCI Form From the example in RFC-3825, 38.89868 degrees is encoded into a 34bit twos-complement number: 000100110.1110011000001111111001000 The resolution value for this axis indicates how many of this bits are actually significant. A resolution of 18 indicates that the last 16 bits of the number could be either 1 or zero: 000100110.111001100xxxxxxxxxxxxxxxx To determine the uncertainty assume a range from the minimum possible value (all zeros for the last 16 bits) to the maximum (all ones): 000100110.1110011000000000000000000 to 000100110.1110011001111111111111111 This yields the range in the example to be between 38.8984375 degrees and 38.9003906 degrees (rounded to 7 decimal places). Winterbottom, et al. Expires November 3, 2006 [Page 21] Internet-Draft GEOPRIV PIDF-LO Profile May 2006 A.2. Conversion To LCI Form This involves converting the original shape to a rectangular prism. To do this determine the minimum and maximum values for each of the axes: latitude, longitude and altitude. This results in a slightly increased area, but the overall effect is minimal. +----------.....----------+ | _d^^^^^^^^^b_ | | .d''yyyyyyyyyyy``b. | | .p'yyyyyyyyyyyyyyyyy`q. | |.d'yyyyyyyyyyyyyyyyyyy`b.| .d'yyyyyyyyyyyyyyyyyyyyy`b. ::yyyyyyyyyyyyyyyyyyyyyyy:: :: ................... :: ::vvvvvvvvvvvvvvvvvvvvvvv:: `p.vvvvvvvvvvvvvvvvvvvvv.q' |`p.vvvvvvvvvvvvvvvvvvv.q'| | `b.vvvvvvvvvvvvvvvvv.d' | | `q..vvvvvvvvvv..p' <-+----Area Increase | ^q........p^ | +---------''''------------+ It's important to note the resulting area cannot be less that the starting area. This is because the starting area represents a set of points and the Target may reside at anyone of these points with equal probability. If the area is cropped there is a risk that the Target's position will be one of the discarded points yielding an incorrect result. In general the increases in area are minimal, for a circular area, as shown, the increase ratio is 4:pi; a square building will at most double the size of the area. A.2.1. Example 1 Looking at a random example from 32.98004 degrees to 32.98054397 degrees the approximate distance is 56 metres. Converting each value into a The 34-bit twos-complement number yields the following: 000100000.1111101011100011111001110 to 000100000.1111101100000100111011100 ^^^^^^^^^^^^^^^^^ To ensure that the encoded value represents the full range from the lowest to highest value, take the common stem as marked this above. Winterbottom, et al. Expires November 3, 2006 [Page 22] Internet-Draft GEOPRIV PIDF-LO Profile May 2006 There are 16 common bits between low and high. To check, convert the value back by making the last 18 bits either 0 or 1 as described earlier. This leads to a range from 32.9765625 degrees to 32.9843745 degrees, which is approximately 870 metres a significant increase over the original 56 metres. A.2.2. Example 2 Take the range from 31.9999985 degrees to 32.00000274 degrees, which is about 0.5 metres in distances ranging around 32 degrees. This results in the following binary values: 000011111.1111111111111111111001110 to 000100000.0000000000000000001011100 ^^^ Only 3 bits are common to both values which yields an encoded range from 0 to 64 degrees, or a distance of 3,500 kilometres. A.3. Problem The LCI encoding breaks when the uncertainty that is being represented causes a change in a relatively significant binary digit. This results in an expanded uncertainty, possibly very large, depending on which binary digit changes. In many cases the change will be in lower-order digits, which will result in a relatively small increase in uncertainty, but certain values will yield an almost useless location see Appendix A.2.2. This problem is exacerbated at the three zero points - the Greenwich Meridian, Equator and at the surface of the geoid (altitude). In these cases, if the input uncertainty spans the zero point, the resolution value ends up as zero; that is, it indicates that there is no useful information for that parameter. The original uncertainty has very little bearing on this problem - a small value can be increased to any value. More precise location determination technologies only reduce the probability of large problems occurring, although the nature of the encoding is such that any uncertainty can be greatly increased. A.4. Conclusion Uncertainty is a reality of location and important for a number of applications. LCI's limited form means that adapting existing uncertainty information, for example a circle as in Appendix A.2.2, Winterbottom, et al. Expires November 3, 2006 [Page 23] Internet-Draft GEOPRIV PIDF-LO Profile May 2006 results in a small error. The introduction of this small encoding error however is insignificant when compared to the error that can be introduced by the way that the resolution parameter is interpreted. Winterbottom, et al. Expires November 3, 2006 [Page 24] Internet-Draft GEOPRIV PIDF-LO Profile May 2006 Appendix B. Creating a PIDF-LO from DHCP Geo Encoded Data This appendix is informative only. RFC-3825 [3] describes a means by which an end-point may learn it location from information encoded into DHCP option 123. The following section describes how and end-point can take this information and represent it in a well formed PIDF-LO describing this geodetic location. The location information described in RFC-3825 consists of a latitude, longitude, altitude and datum. B.1. Latitude and Longitude The latitude and longitude values are represented in degrees and decimal degrees. Latitude values are positive if north of the equator, and negative if south of the equator. Similarly longitudinal values are positive if east of the Greenwich meridian, and negative if west of the Greenwich meridian. The latitude and longitude values are each 34 bit long fields consisting of a 9 bit integer component and a 25 bit fraction component, with negative numbers being represented in 2s complement notation. The latitude and longitude fields are each proceeded by a 6 bit resolution field, the LaRes for latitude, and the LoRes for longitude. The value in the LaRes field indicates the number of significant bits to interpret in the Latitude field, while the value in the LoRes field indicates the number of significant bits to interpret in the Longitude field. For example, if you are in Wollongong Australia which is located at 34 Degrees 25 minutes South and 150 degrees 32 minutes East this would translate to -34.41667, 150.53333 in decimal degrees. If these numbers are translated to their full 34 bit representations, then we arrive the following: Latitude = 111011101.1001010101010101000111010 Longitude = 0100101101000100010001000010100001 RFC-3825, uses the LaRes and LoRes values to specify a lower and upper boundary for location thereby specifying an area. The size of the area specified is directly related to the value specified in the LaRes and LoRes fields. Using the previous example, if LaRes is set 7, then lower latitude boundary can be calculated as -256+128+64+16+8+4, which is -36 Winterbottom, et al. Expires November 3, 2006 [Page 25] Internet-Draft GEOPRIV PIDF-LO Profile May 2006 degrees, the upper boundary then becomes -256+128+64+16+8+4+2+1 which is -35 degrees. LoRes may be used similarly for Longitude. So what level of precision is useful? Well, certain types of applications and regulations call for different levels of precision, and the required precision may vary depending on how the location was determined. For Cellular 911 calls in the United States, for example, if the network measures the location then the caller should be within 100 metres, while if the handset does the measurement then the location should be within 50 metres. Since DHCP is a network based mechanism we will benchmark off 100 metres (approximately 330 ft) which is still a large area. For simplicity we shall assume that we are defining a square, in which we are equally to appear anywhere. The greatest distance through this square is across the diagonal, so we make this 100 metres. +----------------------+ | _/| | _/ | | _/ | | _/ | | _/ | | 100_/ metres | | _/ | | _/ | | _/ | | _/ | |_/ | +----------------------+ The distance between the top and the bottom and the left and the right is the same, the area being a square, and this works out to be 70.7 metres. When expressed in decimal degrees, the third point after the decimal place represents about 100 metre precision, this equates to 10 binary places of fractional part. A 70 metre distance is required, so 11 fractional binary digits are necessary resulting in a total of 20 bits of precision. With -34.4167, 150.5333 encoded with 20 bits of precision for the LaRes and LoRes, the corners of the enclosing square are: Winterbottom, et al. Expires November 3, 2006 [Page 26] Internet-Draft GEOPRIV PIDF-LO Profile May 2006 Point 1 (-34.4170, 150.5332) Point 2 (-34.4170, 150.5337) Point 3 (-34.4165, 150.5332) Point 4 (-34.4165, 150.5337) B.2. Altitude The altitude elements define how the altitude is encoded and to what level of precision. The units for altitude are either metres, or floors, with the actual measurement being encoded in a similar manner to those for latitude and longitude, but with 22 bit integer, and 8 bit fractional components. B.3. Generating the PIDF-LO If altitude is not required, or is expressed in floors then a geodetic location expressed by a polygon SHOULD be used, with points expressed in a counter-clockwise direction. If the altitude is expressed in floors and is required, the altitude SHOULD be expressed as a civic floor number as part of the same element. In the example above the GML for the location would be expressed as follows: -34.4165 150.5332 -34.4170 150.5532 -34.4170 150.5537 -34.4165 150.5337 -34.4165 150.5332 If a floor number of say 3 were included, then the location-;info element would contain the above information and the following: 2 Winterbottom, et al. Expires November 3, 2006 [Page 27] Internet-Draft GEOPRIV PIDF-LO Profile May 2006 When altitude is expressed as an integer and fractional component, as with the latitude and longitude, it expresses a range which requires the prism form to be used. Care must be taken to ensure that the points are defined in a counter-clockwise direction to ensure that the upward normal points up. Extending the previous example to include an altitude expressed in metres rather than floors. AltRes is set to a value of 19, and the Altitude value is set to 34. Using similar techniques as shown in the latitude and longitude section, a range of altitudes between 32 metres and 40 metres is described. The prism would therefore be defined as follows: -34.4165 150.5332 32 -34.4170 150.5532 32 -34.4170 150.5537 32 -34.4165 150.5337 32 -34.4165 150.5332 32 8 The Method value SHOULD be set to DHCP. Note that this case, the DHCP is referring to the way in which location information was delivered to the IP-device, and not necessarily how the location was determined. The timestamp value SHOULD be set to the time that location was retrieved from the DHCP server. The client application MAY insert any usage rules that are pertinent to the user of the device and that comply with [8]. A guideline is that the any retention-expiry value SHOULD NOT exceed the current Winterbottom, et al. Expires November 3, 2006 [Page 28] Internet-Draft GEOPRIV PIDF-LO Profile May 2006 lease time. The Provided-By element SHOULD NOT be populated as this is not provided by the source of the location information. The 3 completed PIDF-LO representations are provided below, and represent a location without altitude, a location with a civic altitude, and a location represented as a 3 dimensional rectangular prism. -34.4165 150.5332 -34.4170 150.5532 -34.4170 150.5537 -34.4165 150.5337 -34.4165 150.5332 DHCP 2005-07-05T14:49:53+10:00 Winterbottom, et al. Expires November 3, 2006 [Page 29] Internet-Draft GEOPRIV PIDF-LO Profile May 2006 -34.4165 150.5332 -34.4170 150.5532 -34.4170 150.5537 -34.4165 150.5337 -34.4165 150.5332 2 DHCP 2005-07-05T14:49:53+10:00 Winterbottom, et al. Expires November 3, 2006 [Page 30] Internet-Draft GEOPRIV PIDF-LO Profile May 2006 -34.4165 150.5332 32 -34.4170 150.5532 32 -34.4170 150.5537 32 -34.4165 150.5337 32 -34.4165 150.5332 32 8 DHCP 2005-07-05T14:49:53+10:00 Winterbottom, et al. Expires November 3, 2006 [Page 31] Internet-Draft GEOPRIV PIDF-LO Profile May 2006 Authors' Addresses James Winterbottom Andrew Corporation Wollongong NSW Australia Email: james.winterbottom@andrew.com Martin Thomson Andrew Corporation Wollongong NSW Australia Email: martin.thomson@andrew.com Hannes Tschofenig Siemens Otto-Hahn-Ring 6 Munich, Bavaria 81739 Germany Email: Hannes.Tschofenig@siemens.com Winterbottom, et al. Expires November 3, 2006 [Page 32] Internet-Draft GEOPRIV PIDF-LO Profile May 2006 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Winterbottom, et al. Expires November 3, 2006 [Page 33]