Network Working Group D. Stanley Internet Draft Aruba Networks Intended status: Proposed Standard S. McCann Expires: April 19, 2010 Research in Motion Gabor Bajko Nokia Allan Thomson Cisco Systems October 19, 2009 Interior Location Extensions draft-stanley-geopriv-int-ext-00.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and 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 April 19, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Stanley, et al. Expires April 19, 2010 [Page 1] Internet-Draft INT Location Extensions October 2009 Abstract This document extends the definition of Interior Location defined in draft-rosen-geopriv-pidf-interior to include a set of registered elements that allow for the expression of relative location. The expression of relative location enables LAN technologies that have such capability to provide a more accurate location description than normally allowed using [RFC4776] [RFC5139]. By registering the elements described here, interoperability between applications and vendors is enabled. Table of Contents 1. Introduction.......................................................2 1.1. Requirements Notation..........................................3 1.2. Motivation for Interior Location...............................3 2. INT Elements.......................................................4 2.1. Measurement Uncertainty........................................4 2.2. Reference Location.............................................4 3. Shapes.............................................................5 3.1. Point........................................................5 3.2. Circle.......................................................6 3.3 Arcband.......................................................7 3.4. Polygon......................................................9 4. Security Considerations...........................................11 5. IANA Considerations...............................................11 5.1. INT Name Registry.............................................11 6. References........................................................12 6.1. Normative References..........................................12 7. Acknowledgments...................................................12 Authors' Addresses...................................................12 1. Introduction This extension to the definition of interior locations is a set of registered elements that provide a common method to express additional location information in the form of a relative location from a reference location. Stanley, et al. Expires April 19, 2010 [Page 2] Internet-Draft INT Location Extensions October 2009 The relative location information could be produced by LAN technologies and used in environments such as large campus networks, large public buildings, hot spots, etc. Using geodetic coordinates to describe the location of an entity has limitations that restrict its usability, especially in indoor environments. In these cases, describing the determined location of the entity using civic and relative addressing may be both more feasible and easier for human consumption than using geodetic coordinates. 1.1. Requirements Notation 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. 1.2. Motivation for Interior Location Current civic addressing [RFC4776],[RFC5139] is neither granular nor accurate enough to be able to describe an arbitrary indoor position of a network device with precision. This document proposes to extend civic addressing with a reference point, an offset and relative location from these points using shapes in the Cartesian coordinate system to describe the position of a network device. The data included within the relative position parameters is supplementary to, not exclusive of the existing civic location data expressed in PIDF- LO [RFC4119] and the DHCP Civic Location option [RFC4776] [RFC5139]. An example of this may be a 4-story campus building belonging to a company that has wireless LAN technology deployed throughout the building. The building has complete RF coverage and the wireless network architecture for the building can locate network devices within that building to within a few meters using RF measurements or other technologies. The supplementary data provided by relative location would enable a more granular location expression for a located device. In addition to "34 Some Street, Anytown, PA, USA, Building 10, Floor 4", a relative position "within X meters of the point which is 10 meters south and 15 meters east of the main elevator on Floor 4" is possible. Another example of this may be a popular wireless hotspot located at 234 N. Main St., Anytown, PA. USA. It is reasonable to expect that Stanley, et al. Expires April 19, 2010 [Page 3] Internet-Draft INT Location Extensions October 2009 234 N. Main St. covers a geographic area that encompasses several hundred square meters. The wireless network architecture for this hotspot could include several wireless infrastructure access points. The supplementary data provided via relative location would enable a more granular location expression. In addition to providing 234 N. Main St., Anytown, PA. USA, a relative position like "within X meters from the main entrance" could be added. 2. INT Elements Included in the interior relative location architecture below is a set of INT elements and corresponding attributes that are registered with the namespace to enable interoperability between various vendors and devices. Included are 4 shapes: point, circle, arcband, and polygon. Mixing the use of these registered INT elements with any quantity of local, or private, INT elements is allowed. Please note that all INT elements are supplementary to Civic location elements in PIDF-LO. The order in which these new elements appear in PIDF-LO is significant based on the text for each shape below. 2.1. Measurement Uncertainty When calculating a network device's location using the technology described above, there is an area of uncertainty associated with the measurement techniques. The method of expressing a calculated position and separately expressing the area of uncertainty has been debated as to its usefulness. Hence, there is no facility included here to allow the expression of an area of uncertainty separate from the shape. It is expected that the expressed shape will include the area of uncertainty, to yield a result that the device is contained within the shape to a 95% confidence level. 2.2. Reference Location Measurement from the reference is provided by using the labels of X, Y and Z. The east-west dimension is labeled X and north-south dimension is labeled Y. A positive Y value is considered north of the reference, a negative Y value south of the reference, a positive X value for east of the reference and a negative X value indicates west of the reference. The height value, Z, is optional. A positive Z value would indicate the height above the floor level at the reference whereas a negative Z value would indicate a height below the reference. The absence of a Z value indicates the shape is at the floor level of the reference or unknown. All position values are in meters. Stanley, et al. Expires April 19, 2010 [Page 4] Internet-Draft INT Location Extensions October 2009 3. Shapes The different shapes are described by first declaring a mandatory reference element, which is the starting location for the offset positions. Next is a mandatory declaration of the shape type, which includes point, circle, arcband, or polygon. Following the shape declaration element are the shape specific offset measurement elements as outlined below. 3.1. Point The point shape includes the reference, the shape type, and offset measurement values for X, Y, and optionally Z. See Figure 1. Front Door +25 +10 +10 (optional) +--------------------------------------x | SHAPE-OFFSET-X | | | | SHAPE-OFFSET-Y | | REF Figure 1 - Point Shape 3.1.1 Point Example An example of a point shape included in the whole of the civic location elements would be: US Florida Miami 8200 NW 41st Street 33166 4 400 Stanley, et al. Expires April 19, 2010 [Page 5] Internet-Draft INT Location Extensions October 2009 Front Door +25 +10 +10 3.2. Circle The circle shape includes the reference, shape type, offset measurement values for the X, Y, and optionally Z of the center point of the circle, and a radius value. See Figure 2. Front Door +34 -9 +5 (optional) 4 REF | | | | | SHAPE-OFFSET-Y _,...._ | ,-' `-. | ,' --,`. RADIUS | / ,'| \ | .' / '. | | ,' | +-----------------------------+---------x | SHAPE-OFFSET-X \ / \ / `. ,' `. ,' `--...--' Figure 2 - Circle Shape 3.2.2. Circle Example An example of a circle shape included in the whole of the civic location elements would be: Stanley, et al. Expires April 19, 2010 [Page 6] Internet-Draft INT Location Extensions October 2009 US Florida Miami 8200 NW st 41 Street 33166 4 400 Front Door +34 -9 +5 4 3.3 Arcband The arcband shape includes the reference, shape type, offset measurement value of the central point, the optional Z value, the inner and outer radius values, the start angle, and the opening angle. See Figure 3. Front Door +17 -2 +2 (optional) 8 18 329 82 Stanley, et al. Expires April 19, 2010 [Page 7] Internet-Draft INT Location Extensions October 2009 _,,..,--------....__ '' `--.. \ ``-. REF \ `-._ | \ `. | \ ;> | \ ,' | \ __......__ ,' | .-'' `--._ ,' | \ `. / OuterRadius | `. `.,' | SHAPE-OFFSET-Y | Opening ,' | | Angle ,' | `. / | | ,' | | ,' | Start `. ,' InnerRadius | Angle | / | | ,' +------------------------------------x SHAPE-OFFSET-X Figure 3 - Arcband Shape 3.3.1 Arcband Example An example of an arcband shape included in the whole of the civic location elements would be: US Florida Miami 8200 NW 41st Street 33166 4 400 Front Door Stanley, et al. Expires April 19, 2010 [Page 8] Internet-Draft INT Location Extensions October 2009 +17 -2 +2 8 18 329 82 3.4. Polygon The polygon shape includes the reference, the shape type, the number of polygon points, the offset measurement value for each point, optionally a calculated geo center point of the polygon, and the optional Z value. This example shows a single Z value for the entire shape. See Figure 4. Front Door 5 -18 -8 -20 -5 -25 -6 -25 -10 -20 -13 -18 -8 -10 (optional) -20 (optional) +10 (optional) Stanley, et al. Expires April 19, 2010 [Page 9] Internet-Draft INT Location Extensions October 2009 REF | | | | | SHAPE- | OFFSET-Y(A) | | | SHAPE-OFFSET-X(A) | _,.-------------------------------------+ SHAPE- _,,-' `. | OFFSET-Y(B) _,.-'' \ SHAPE-OFFSET-X(B) | '------------------\--------------------------------+ | \ | SHAPE- | `. | OFFSET-Y(C) | \ | | \ SHAPE-OFFSET-X(C) | | ;--------------------------+ SHAPE- | ,-' | OFFSET-Y(D) | ,' SHAPE-OFFSET-X(D) | ':----------------;----------------------------------+ `-. ,' | SHAPE- `. ,-' | OFFSET-Y(E) `-. ,' SHAPE-OFFSET-X(E) | '------------------------------------------+ Figure 4 - Polygon Shape 3.4.1 Polygon Example An example of a polygon shape included in the whole of the civic location elements would be: US Florida Miami 8200 NW 41st Street 33166 Stanley, et al. Expires April 19, 2010 [Page 10] Internet-Draft INT Location Extensions October 2009 4 400 Front Door 5 -18 -8 -20 -5 -25 -6 -25 -10 -20 -13 -18 -8 -10 -20 4. Security Considerations The XML representation described in this document is designed for inclusion in a PIDF-LO document. As such, it is subject to the same security considerations as are described in [RFC4119]. Considerations relating to the inclusion of this representation in other XML documents are outside the scope of this document. 5. IANA Considerations 5.1. INT Name Registry This document adds new values to the registry managed by IANA called "INT Names". The new values are listed below: Reference Point Circle Arcband Polygon SHAPE-OFFSET-X SHAPE-OFFSET-Y SHAPE-OFFSET-Z Radius InnerRadius Stanley, et al. Expires April 19, 2010 [Page 11] Internet-Draft INT Location Extensions October 2009 OuterRadius StartAngle Opening PolygonPoints SHAPE-GEOCENTER-X SHAPE-GEOCENTER-Y SHAPE-OFFSET-Z 6. References 6.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. [RFC4776] H. Schulzrinne, "DHCPv4 and DHCPv6 Option for Civic Addresses Configuration Information", RFC4776, November 2006. 7. Acknowledgments The authors would like to acknowledge James Polk and Marc Linsner for their contributions to this document. This document was prepared using 2-Word-v2.0.template.dot and "JavE" from http://www.jave.de without whom those radii would not have been. Authors' Addresses Dorothy Stanley Aruba Networks 1322 Crossman Ave Sunnyvale, CA 94089 USA Stanley, et al. Expires April 19, 2010 [Page 12] Internet-Draft INT Location Extensions October 2009 +1 630-363-1389 Email: dstanley@arubanetworks.com Stephen McCann Research in Motion 200 Bath Road Slough Berkshire, SL1 3XE, UK +44 1753 667099 Email: smccann@rim.com Gabor Bajko Nokia 323 Fairchild Drive Mountain View, CA, 94043 USA Email: gabor.bajko@nokia.com Allan Thomson Cisco Systems, Inc. 170 West Tasman Drive San Jose, California, 95134 USA Email: althomso@cisco.com Stanley, et al. Expires April 19, 2010 [Page 13]