idnits 2.17.1 draft-ietf-geopriv-pdif-lo-profile-11.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1148. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1159. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1166. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1172. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC4119, but the abstract doesn't seem to directly say this. It does mention RFC4119 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year (Using the creation date from RFC4119, updated by this document, for RFC5378 checks: 2004-01-14) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 20, 2008) is 5881 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'GeoShape' Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Geopriv J. Winterbottom 3 Internet-Draft M. Thomson 4 Updates: 4119 (if approved) Andrew Corporation 5 Intended status: Standards Track H. Tschofenig 6 Expires: August 23, 2008 Nokia Siemens Networks 7 February 20, 2008 9 GEOPRIV PIDF-LO Usage Clarification, Considerations and Recommendations 10 draft-ietf-geopriv-pdif-lo-profile-11.txt 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on August 23, 2008. 37 Copyright Notice 39 Copyright (C) The IETF Trust (2008). 41 Abstract 43 The Presence Information Data Format Location Object (PIDF-LO) 44 specification provides a flexible and versatile means to represent 45 location information. There are, however, circumstances that arise 46 when information needs to be constrained in how it is represented. 47 In these circumstances the range of options that need to be 48 implemented are reduced. There is growing interest in being able to 49 use location information contained in a PIDF-LO for routing 50 applications. To allow successful interoperability between 51 applications, location information needs to be normative and more 52 tightly constrained than is currently specified in the RFC 4119 53 (PIDF-LO). This document makes recommendations on how to constrain, 54 represent and interpret locations in a PIDF-LO. It further 55 recommends a subset of GML that is mandatory to implement by 56 applications involved in location based routing. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 3. Using Location Information . . . . . . . . . . . . . . . . . . 6 63 3.1. Single Civic Location Information . . . . . . . . . . . . 9 64 3.2. Civic and Geospatial Location Information . . . . . . . . 9 65 3.3. Manual/Automatic Configuration of Location Information . . 10 66 3.4. Multiple Location Objects in a Single PIDF-LO . . . . . . 11 67 4. Geodetic Coordinate Representation . . . . . . . . . . . . . . 13 68 5. Geodetic Shape Representation . . . . . . . . . . . . . . . . 14 69 5.1. Polygon Restrictions . . . . . . . . . . . . . . . . . . . 15 70 5.2. Shape Examples . . . . . . . . . . . . . . . . . . . . . . 16 71 5.2.1. Point . . . . . . . . . . . . . . . . . . . . . . . . 16 72 5.2.2. Polygon . . . . . . . . . . . . . . . . . . . . . . . 17 73 5.2.3. Circle . . . . . . . . . . . . . . . . . . . . . . . . 19 74 5.2.4. Ellipse . . . . . . . . . . . . . . . . . . . . . . . 20 75 5.2.5. Arc Band . . . . . . . . . . . . . . . . . . . . . . . 21 76 5.2.6. Sphere . . . . . . . . . . . . . . . . . . . . . . . . 23 77 5.2.7. Ellipsoid . . . . . . . . . . . . . . . . . . . . . . 24 78 5.2.8. Prism . . . . . . . . . . . . . . . . . . . . . . . . 26 79 6. Security Considerations . . . . . . . . . . . . . . . . . . . 29 80 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 81 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 31 82 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32 83 9.1. Normative references . . . . . . . . . . . . . . . . . . . 32 84 9.2. Informative References . . . . . . . . . . . . . . . . . . 32 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33 86 Intellectual Property and Copyright Statements . . . . . . . . . . 34 88 1. Introduction 90 The Presence Information Data Format Location Object (PIDF-LO) 91 [RFC4119] is the recommended way of encoding location information and 92 associated privacy policies. Location information in a PIDF-LO may 93 be described in a geospatial manner based on a subset of GMLv3, or as 94 civic location information [I-D.ietf-geopriv-revised-civic-lo]. A 95 GML profile for expressing geodetic shapes in a PIDF-LO is described 96 in [GeoShape]. Uses for PIDF-LO are envisioned in the context of 97 numerous location based applications. This document makes 98 recommendations for formats and conventions to make interoperability 99 less problematic. 101 The PIDF-LO provides a general presence format for representing 102 location information, and permits specification of location 103 information relating to a whole range of aspects of a Target. The 104 general presence data model is described in [RFC4479] and caters for 105 a presence document to describe different aspects of the reachability 106 of a presentity. Continuing this approach, a presence document may 107 contain several GEOPRIV objects that specify different locations and 108 aspects of reachability relating to a presentity. This degree of 109 flexibility is important, and recommendations in this document make 110 no attempt to forbid the usage of a PIDF-LO in this manner. This 111 document provides a specific set of guidelines for building presence 112 documents when it is important to unambiguously convey exactly one 113 location. 115 2. Terminology 117 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 118 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 119 document are to be interpreted as described in [RFC2119]. 121 The definition for "Target" is taken from [RFC3693]. 123 In this document a "discrete location" is defined as a place, point, 124 area or volume in which a Target can be found. 126 The term "compound location" is used to describe location information 127 represented by a composite of both civic and geodetic information. 128 An example of compound location might be a geodetic polygon 129 describing the perimeter of a building and a civic element 130 representing the floor in the building. 132 The term "method" in this document refers to the mechanism used to 133 determine the location of a Target. This may be something employed 134 by a LIS, or by the Target itself. It specifically does not refer to 135 the LCP used to deliver location information either to the Target or 136 the Recipient. 138 The term "source" is used to refer to the LIS, node or device from 139 which a Recipient (Target or Third-Party) obtains location 140 information. 142 3. Using Location Information 144 The PIDF format provides for an unbounded number of , 145 , and elements. Each of these elements contains a 146 single element that may contain more than one 147 element as a child. Each element must contain at least the 148 following two child elements: element and element. One or more chunks of location information are 150 contained inside a element. 152 Hence, a single PIDF document may contain an arbitrary number of 153 location objects some or all of which may be contradictory or 154 complementary. Graphically, the structure of a PIDF-LO document can 155 be depicted as shown in Figure 1. 157 158 159 -- #1 160 161 -- #1 162 163 location chunk #1 164 location chunk #2 165 ... 166 location chunk #n 167 168 169 -- #2 170 -- #3 171 ... 172 -- #m 173 174 175 176 177 -- #1 178 179 location chunk #1 180 location chunk #2 181 ... 182 location chunk #n 183 184 185 -- #2 186 -- #3 187 ... 188 -- #m 189 191 192 193 194 -- #1 195 196 location chunk #1 197 location chunk #2 198 ... 199 location chunk #n 200 201 202 -- #2 203 -- #3 204 ... 205 -- #m 206 207 208 -- #2 209 -- #2 210 -- #2 211 ... 212 -- #o 213 215 Figure 1: Structure of a PIDF-LO Document 217 All of these potential sources and storage places for location lead 218 to confusion for the generators, conveyors and consumers of location 219 information. Practical experience within the United States National 220 Emergency Number Association (NENA) in trying to solve these 221 ambiguities led to a set of conventions being adopted. These rules 222 do not have any particular order, but should be followed by creators 223 and consumers of location information contained in a PIDF-LO to 224 ensure that a consistent interpretation of the data can be achieved. 226 Rule #1: A element MUST describe a discrete location. 228 Rule #2: Where a discrete location can be uniquely described in more 229 than one way, each location description SHOULD reside in a 230 separate , , or element. 232 Rule #3: Providing more than one element in a single 233 presence document (PIDF) MUST only be done if the locations refer 234 to the same place or are put into different element types. For 235 example, one location in a , a second location in a 236 element, and a third location in a element. 238 This may occur if a Target's location is determined using a 239 series of different techniques, or the Target wishes to 240 represent her location as well as the location of her PC. In 241 general avoid putting more than one location into a document 242 unless it makes sense to do so. 244 Rule #4: Providing more than one location chunk in a single 245 element SHOULD be avoided where possible. Rule #5 246 and Rule #6 provide further refinement. 248 Rule #5: When providing more than one location chunk in a single 249 element the locations MUST be provided by a common 250 source at the same time and by the same location determination 251 method. 253 Rule #6: Providing more than one location chunk in a single 254 element SHOULD only be used for representing 255 compound location referring to the same place. 257 For example, a geodetic location describing a point, and a 258 civic location indicating the floor in a building. 260 Rule #7: Where compound location is provided in a single element, the coarse location information MUST be provided 262 first. 264 For example, a geodetic location describing an area, and a 265 civic location indicating the floor should be represented with 266 the area first followed by the civic location. 268 Rule #8: Where a PIDF document contains more than one 269 element, the priority of interpretation is given to the first 270 element in the document containing a location. If no 271 element containing a location is present in the document, 272 then priority is given to the first element containing a 273 location. Locations contained in tuples SHOULD only be 274 used as a last resort. 276 Rule #9: Where multiple PIDF documents can be sent or received 277 together, say in a multi-part MIME body, and current location 278 information is required by the recipient, then document selection 279 SHOULD be based on document order, with the first document 280 considered first. 282 The following examples illustrate the application of these rules. 284 3.1. Single Civic Location Information 286 Jane is at a coffee shop on the ground floor of a large shopping 287 mall. Jane turns on her laptop and connects to the coffee-shop's 288 WiFi hotspot, Jane obtains a complete civic address for her current 289 location, for example using the DHCP civic mechanism defined in 290 [RFC4776]. A Location Object is constructed consisting of a single 291 PIDF document, with a single or element, a single 292 element, a single element, and a single location 293 chunk residing in the element. This document is 294 unambiguous, and should be interpreted consistently by receiving 295 nodes if sent over the network. 297 3.2. Civic and Geospatial Location Information 299 Mike is visiting his Seattle office and connects his laptop into the 300 Ethernet port in a spare cube. In this case location information is 301 geodetic location, with the altitude represented as a building floor 302 number. Mike's main location is the point specified by the geodetic 303 coordinates. Further, Mike is on the second floor of the building 304 located at these coordinates. Applying rules #6 and #7, the 305 resulting compound location information is shown in Figure 2. 307 308 314 315 316 317 318 319 -43.5723 153.21760 320 321 322 2 323 324 325 326 Wiremap 327 328 329 2007-06-22T20:57:29Z 330 mac:8asd7d7d70cf 331 332 334 Figure 2 336 3.3. Manual/Automatic Configuration of Location Information 338 Loraine has a predefined civic location stored in her laptop, since 339 she normally lives in Sydney, the address is for her Sydney-based 340 apartment. Loraine decides to visit sunny San Francisco, and when 341 she gets there she plugs in her laptop and makes a call. Loraine's 342 laptop receives a new location from the visited network in San 343 Francisco. As this system cannot be sure that the pre-existing, and 344 new location, both describe the same place, Loraine's computer 345 generates a new PIDF-LO and will use this to represent Loraine's 346 location. If Loraine's computer were to add the new location to her 347 existing PIDF location document (breaking rule #3), then the correct 348 information may still be interpreted by the Location Recipient 349 providing Loraine's system applies rule #9. In this case the 350 resulting order of location information in the PIDF document should 351 be San Francisco first, followed by Sydney. Since the information is 352 provided by different sources, rule #8 should also be applied and the 353 information placed in different tuples with the tuple containing the 354 San Francisco location first. 356 3.4. Multiple Location Objects in a Single PIDF-LO 358 Vanessa has her PC with her at the park, but due to a 359 misconfiguration, her PC reports her location as being in the office. 360 The resulting PIDF-LO will have a element showing the 361 location of Vanessa's PC as the park, and a element saying 362 that Vanessa is in her office. 364 365 372 373 374 375 376 377 -34.410649 150.87651 378 379 30 380 381 382 383 384 GPS 385 386 387 2007-06-22T20:57:29Z 388 mac:1234567890ab 389 390 391 392 393 394 395 AU 396 NSW 397 Wollongong 398 North Wollongong 399 400 FlindersStreet 401 Campbell Street 402 403 Gilligan's Island 405 Corner 406 Main Bank 407 2500 408 398 409 store 410 Private Box 15 411 412 413 414 Manual 415 416 417 2007-06-24T12:28:04Z 418 419 421 Figure 3 423 4. Geodetic Coordinate Representation 425 The geodetic examples provided in RFC 4119 [RFC4119] are illustrated 426 using the element, which uses the 427 element inside the element and this representation has 428 several drawbacks. Firstly, it has been deprecated in later versions 429 of GML (3.1 and beyond) making it inadvisable to use for new 430 applications. Secondly, the format of the coordinates type is opaque 431 and so can be difficult to parse and interpret to ensure consistent 432 results, as the same geodetic location can be expressed in a variety 433 of ways. The PIDF-LO Geodetic Shapes specification [GeoShape] 434 provides a specific GML profile for expressing commonly used shapes 435 using simple GML representations. The shapes defined in [GeoShape] 436 are the recommended shapes to ensure interoperability. 438 5. Geodetic Shape Representation 440 The cellular mobile world today makes extensive use of geodetic based 441 location information for emergency and other location-based 442 applications. Generally these locations are expressed as a point 443 (either in two or three dimensions) and an area or volume of 444 uncertainty around the point. In theory, the area or volume 445 represents a coverage in which the user has a relatively high 446 probability of being found, and the point is a convenient means of 447 defining the centroid for the area or volume. In practice, most 448 systems use the point as an absolute value and ignore the 449 uncertainty. It is difficult to determine if systems have been 450 implemented in this manner for simplicity, and even more difficult to 451 predict if uncertainty will play a more important role in the future. 452 An important decision is whether an uncertainty area should be 453 specified. 455 The PIDF-LO Geodetic Shapes specification [GeoShape] defines eight 456 shape types most of which are easily translated into shapes 457 definitions used in other applications and protocols, such as Open 458 Mobile Alliance (OMA) Mobile Location Protocol (MLP). For 459 completeness the shapes defined in [GeoShape] are listed below: 461 o Point (2d and 3d) 463 o Polygon (2d) 465 o Circle (2d) 467 o Ellipse (2d) 469 o Arc band (2d) 471 o Sphere (3d) 473 o Ellipsoid (3d) 475 o Prism (3d) 477 All above-listed shapes are mandatory to implement. 479 The GeoShape specification [GeoShape] also describes a standard set 480 of coordinate reference systems (CRS), unit of measure (UoM) and 481 conventions relating to lines and distances. The use of the WGS-84 482 coordinate reference system and the usage of EPSG-4326 (as identified 483 by the URN urn:ogc:def:crs:EPSG::4326) for two dimensional (2d) shape 484 representations and EPSG-4979 (as identified by the URN 485 urn:ogc:def:crs:EPSG::4979) for three dimensional (3d) volume 486 representations is mandated. Distance and heights are expressed in 487 meters using EPSG-9001 (as identified by the URN 488 urn:ogc:def:uom:EPSG::9001). Angular measures MUST use either 489 degrees or radians. Measures in degrees MUST be identified by the 490 URN urn:ogc:def:uom:EPSG::9102, measures in radians MUST be 491 identified by the URN urn:ogc:def:uom:EPSG::9101 493 Implementations MUST specify the CRS using the srsName attribute on 494 the outermost geometry element. The CRS MUST NOT be respecified or 495 changed for any sub-elements. The srsDimension attribute SHOULD be 496 omitted, since the number of dimensions in these CRSs is known. A 497 CRS MUST be specified using the above URN notation only; 498 implementations do not need to support user-defined CRSs. 500 It is RECOMMENDED that where uncertainty is included, a confidence of 501 95% is used. Specifying a convention for confidence enables better 502 use of uncertainty values. 504 5.1. Polygon Restrictions 506 The Polygon shape type defined in [GeoShape] intentionally does not 507 place any constraints on the number of vertices that may be included 508 to define the bounds of a polygon. This allows arbitrarily complex 509 shapes to be defined and conveyed in a PIDF-LO. However, where 510 location information is to be used in real-time processing 511 applications, such as location dependent routing, having arbitrarily 512 complex shapes consisting of tens or even hundreds of points could 513 result in significant performance impacts. To mitigate this risk it 514 is recommended that Polygon shapes be restricted to a maximum of 15 515 points (16 including the repeated point) when the location 516 information is intended for use in real-time applications. This 517 limit of 15 points is chosen to allow moderately complex shape 518 definitions while at the same time enabling interoperation with other 519 location transporting protocols such as those defined in 3GPP (see 520 [3GPP-TS-23_032]) and OMA where the 15 point limit is already 521 imposed. 523 The edges of a polygon are defined by the shortest path between two 524 points in space (not a geodesic curce). To avoid significant errors 525 arising from potential geodesic interpolation, the length between 526 adjacent vertices SHOULD be restricted to a maximum of 130km. More 527 information relating to this restriction is provided in [GeoShape]. 529 A connecting line SHALL NOT cross another connecting line of the same 530 Polygon. 532 Polygons SHOULD be defined with the upward normal pointing up. This 533 is accomplished by defining the vertices in a counter-clockwise 534 direction. 536 Points specified in a polygon MUST be coplanar and it is RECOMMENDED 537 that where points are specified in 3 dimensions that all points 538 maintain the same altitude. 540 5.2. Shape Examples 542 This section provides some examples of where some of the more complex 543 shapes are used, how they are determined, and how they are 544 represented in a PIDF-LO. Complete details on all of the GeoShape 545 types are provided in [GeoShape]. 547 5.2.1. Point 549 The point shape type is the simplest form of geodetic LI, which is 550 natively supported by GML. The gml:Point element is used when there 551 is no known uncertainty. A point also forms part of a number of 552 other geometries. A point may be specified using either WGS 84 553 (latitude, longitude) or WGS 84 (latitude, longitude, altitude). 554 Figure 4 shows a 2d point: 556 557 563 564 565 566 567 568 -34.407 150.883 569 570 571 572 Wiremap 573 574 575 2007-06-22T20:57:29Z 576 mac:1234567890ab 577 578 580 Figure 4 582 Figure 5 shows a 3d point: 584 585 590 591 592 593 594 596 -34.407 150.883 24.8 597 598 599 600 Wiremap 601 602 603 2007-06-22T20:57:29Z 604 mac:1234567890ab 605 606 608 Figure 5 610 5.2.2. Polygon 612 The polygon shape may be used to represent a building outline or 613 coverage area. The first and last points of the polygon have to be 614 the same. For example, looking at the hexagon in Figure 6 with 615 vertices, A, B, C, D, E, and F. The resulting polygon will be defined 616 with 7 points, with the first and last points both having the 617 coordinates of point A. 619 F--------------E 620 / \ 621 / \ 622 / \ 623 A D 624 \ / 625 \ / 626 \ / 627 B--------------C 629 Figure 6 631 632 636 637 638 639 640 641 642 643 43.311 -73.422 644 43.111 -73.322 645 43.111 -73.222 646 43.311 -73.122 647 43.411 -73.222 648 43.411 -73.322 649 43.311 -73.422 650 651 652 653 654 655 Wiremap 656 657 658 2007-06-22T20:57:29Z 659 660 662 Figure 7 664 In addition to the form shown in Figure 7 GML supports a posList 665 which provides a more compact representation for the coordinates of 666 the Polygon vertices than the discrete pos elements. The more 667 compact form is shown in Figure 8. Both forms are permitted. 669 670 674 675 676 677 678 679 680 681 682 43.311 -73.422 43.111 -73.322 683 43.111 -73.222 43.311 -73.122 684 43.411 -73.222 43.411 -73.322 685 43.311 -73.422 686 687 688 689 690 691 692 Wiremap 693 694 695 2007-06-22T20:57:29Z 696 697 699 Figure 8 701 5.2.3. Circle 703 The circular area is used for coordinates in two-dimensional CRSs to 704 describe uncertainty about a point. The definition is based on the 705 one-dimensional geometry in GML, gml:CircleByCenterPoint. The centre 706 point of a circular area is specified by using a two dimensional CRS; 707 in three dimensions, the orientation of the circle cannot be 708 specified correctly using this representation. A point with 709 uncertainty that is specified in three dimensions should use the 710 Sphere shape type. 712 713 718 719 720 721 722 723 42.5463 -73.2512 724 725 850.24 726 727 728 729 730 OTDOA 731 732 733 734 736 Figure 9 738 5.2.4. Ellipse 740 An elliptical area describes an ellipse in two dimensional space. 741 The ellipse is described by a center point, the length of its semi- 742 major and semi-minor axes, and the orientation of the semi-major 743 axis. Like the circular area (Circle), the ellipse MUST be specified 744 using the two dimensional CRS. 746 747 752 753 754 755 756 757 42.5463 -73.2512 758 759 1275 760 761 762 670 763 764 765 43.2 766 767 768 769 770 Device-Assisted_A-GPS 771 772 773 2007-06-22T20:57:29Z 774 775 777 Figure 10 779 The gml:pos element indicates the position of the center, or origin, 780 of the ellipse. The gs:semiMajorAxis and gs:semiMinorAxis elements 781 are the length of the semi-major and semi-minor axes respectively. 782 The gs:orientation element is the angle by which the semi-major axis 783 is rotated from the first axis of the CRS towards the second axis. 784 For WGS 84, the orientation indicates rotation from Northing to 785 Easting, which, if specified in degrees, is roughly equivalent to a 786 compass bearing (if magnetic north were the same as the WGS north 787 pole). Note: An ellipse with equal major and minor axis lengths is a 788 circle. 790 5.2.5. Arc Band 792 The arc band shape type is commonly generated in wireless systems 793 where timing advance or code offsets sequences are used to compensate 794 for distances between handsets and the access point. The arc band is 795 represented as two radii emanating from a central point, and two 796 angles which represent the starting angle and the opening angle of 797 the arc. In a cellular environment the central point is nominally 798 the location of the cell tower, the two radii are determined by the 799 extent of the timing advance, and the two angles are generally 800 provisioned information. 802 For example, Paul is using a cellular wireless device and is 7 timing 803 advance symbols away from the cell tower. For a GSM-based network 804 this would place Paul roughly between 3,594 meters and 4,148 meters 805 from the cell tower, providing the inner and outer radius values. If 806 the start angle is 20 degrees from north, and the opening angle is 807 120 degrees, an arc band representing Paul's location would look 808 similar to Figure 11. 810 N ^ ,.__ 811 | a(s) / `-. 812 | 20 / `-. 813 |--. / `. 814 | `/ \ 815 | /__ \ 816 | . `-. \ 817 | . `. \ 818 |. \ \ . 819 ---c-- a(o) -- | | --> 820 |. / 120 ' | E 821 | . / ' 822 | . / ; 823 .,' / 824 r(i)`. / 825 (3594m) `. / 826 `. ,' 827 `. ,' 828 r(o)`' 829 (4148m) 831 Figure 11 833 The resulting PIDF-LO is shown in Figure 12. 835 836 841 842 843 844 845 846 -43.5723 153.21760 847 848 3594 849 850 851 4148 852 853 854 20 855 856 857 20 858 859 860 861 862 TA-NMR 863 864 865 2007-06-22T20:57:29Z 866 867 869 Figure 12 871 An important note to make on the arc band is that the center point 872 used in the definition of the shape is not included in resulting 873 enclosed area, and that Target may be anywhere in the defined area of 874 the arc band. 876 5.2.6. Sphere 878 The sphere is a volume that provides the same information as a circle 879 in three dimensions. The sphere has to be specified using a three 880 dimensional CRS. Figure 13 shows the sphere shape, which is 881 identical to the circle example, except for the addition of an 882 altitude in the provided coordinates. 884 885 890 891 892 893 894 895 42.5463 -73.2512 26.3 896 897 850.24 898 899 900 901 902 Device-Based_A-GPS 903 904 905 906 908 Figure 13 910 5.2.7. Ellipsoid 912 The ellipsoid is the volume most commonly produced by GPS systems. 913 It is used extensively in navigation systems and wireless location 914 networks. The ellipsoid is constructed around a central point 915 specified in three dimensions, and three axies perpendicular to one 916 another are extended outwards from this point. These axies are 917 defined as the semi-major (M) axis, the semi-minor (m) axis, and the 918 vertical (v) axis respectively. An angle is used to express the 919 orientation of the ellipsoid. The orientation angle is measured in 920 degrees from north, and represents the direction of the semi-major 921 axis from the center point. 923 \ 924 _.-\""""^"""""-._ 925 .' \ | `. 926 / v m \ 927 | \ | | 928 | -c ----M---->| 929 | | 930 \ / 931 `._ _.' 932 `-...........-' 934 Figure 14 936 A PIDF-LO containing an ellipsoid appears as shown in Figure 15. 938 939 944 945 946 947 948 949 42.5463 -73.2512 26.3 950 951 7.7156 952 953 954 3.31 955 956 957 28.7 958 959 960 90 961 962 963 964 965 Hybrid_A-GPS 966 967 968 2007-06-22T20:57:29Z 969 970 972 Figure 15 974 5.2.8. Prism 976 A prism may be used to represent a section of a building or range of 977 floors of building. The prism extrudes a polygon by providing a 978 height element. It consists of a base made up of coplanar points 979 defined in 3 dimensions all at the same altitude. The prism is then 980 an extrusion from this base to the value specified in the height 981 element. If the height is negative, then the prism is extruded from 982 the top down, while a positive height extrudes from the bottom up. 983 The first and last points of the polygon have to be the same. 985 For example, looking at the cube in Figure 16. If the prism is 986 extruded from the bottom up, then the polygon forming the base of the 987 prism is defined with the points A, B, C, D, A. The height of the 988 prism is the distance between point A and point E in meters. 990 G-----F 991 /| /| 992 / | / | 993 H--+--E | 994 | C--|--B 995 | / | / 996 |/ |/ 997 D-----A 999 Figure 16 1001 The resulting PIDF-LO is shown in Figure 17. 1003 1004 1009 1010 1011 1012 1013 1014 1015 1016 1017 1018 1019 42.556844 -73.248157 36.6 1020 42.656844 -73.248157 36.6 1021 42.656844 -73.348157 36.6 1022 42.556844 -73.348157 36.6 1023 42.556844 -73.248157 36.6 1024 1025 1026 1027 1028 1029 1030 2.4 1031 1032 1033 1034 1035 Wiremap 1036 1037 1038 2007-06-22T20:57:29Z 1039 1040 1042 Figure 17 1044 6. Security Considerations 1046 The primary security considerations relate to how location 1047 information is conveyed and used, which are outside the scope of this 1048 document. This document is intended to serve only as a set of 1049 guidelines as to which elements MUST or SHOULD be implemented by 1050 systems wishing to perform location dependent routing. The 1051 ramification of such recommendations is that they extend to devices 1052 and clients that wish to make use of such services. 1054 7. IANA Considerations 1056 This document does not introduce any IANA considerations. 1058 8. Acknowledgments 1060 The authors would like to thank the GEOPRIV working group for their 1061 discussions in the context of PIDF-LO, in particular Carl Reed, Ron 1062 Lake, James Polk, Henning Schulzrinne, Jerome Grenier, Roger Marshall 1063 and Robert Sparks. Furthermore, we would like to thank Jon Peterson 1064 as the author of PIDF-LO and Nadine Abbott for her constructive 1065 comments in clarifying some aspects of the document. 1067 Thanks to Karen Navas for pointing out some emissions in the 1068 examples. 1070 9. References 1072 9.1. Normative references 1074 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1075 Requirement Levels", BCP 14, RFC 2119, March 1997. 1077 [RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object 1078 Format", RFC 4119, December 2005. 1080 [RFC4479] Rosenberg, J., "A Data Model for Presence", RFC 4479, 1081 July 2006. 1083 [GeoShape] 1084 Thomson, M. and C. Reed, "GML 3.1.1 PIDF-LO Shape 1085 Application Schema for use by the Internet Engineering 1086 Task Force (IETF)", Candidate OpenGIS Implementation 1087 Specification 06-142r1, Version: 1.0, April 2007. 1089 [I-D.ietf-geopriv-revised-civic-lo] 1090 Thomson, M. and J. Winterbottom, "Revised Civic Location 1091 Format for PIDF-LO", 1092 draft-ietf-geopriv-revised-civic-lo-07 (work in progress), 1093 December 2007. 1095 9.2. Informative References 1097 [RFC4776] Schulzrinne, H., "Dynamic Host Configuration Protocol 1098 (DHCPv4 and DHCPv6) Option for Civic Addresses 1099 Configuration Information", RFC 4776, November 2006. 1101 [RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and 1102 J. Polk, "Geopriv Requirements", RFC 3693, February 2004. 1104 [3GPP-TS-23_032] 1105 "3GPP TS 23.032 V6.0.0 3rd Generation Partnership Project; 1106 Technical Specification Group Code Network; Universal 1107 Geographic Area Description (GAD)". 1109 Authors' Addresses 1111 James Winterbottom 1112 Andrew Corporation 1113 Wollongong 1114 NSW Australia 1116 Email: james.winterbottom@andrew.com 1118 Martin Thomson 1119 Andrew Corporation 1120 Wollongong 1121 NSW Australia 1123 Email: martin.thomson@andrew.com 1125 Hannes Tschofenig 1126 Nokia Siemens Networks 1127 Otto-Hahn-Ring 6 1128 Munich, Bavaria 81739 1129 Germany 1131 Email: Hannes.Tschofenig@nsn.com 1132 URI: http://www.tschofenig.com 1134 Full Copyright Statement 1136 Copyright (C) The IETF Trust (2008). 1138 This document is subject to the rights, licenses and restrictions 1139 contained in BCP 78, and except as set forth therein, the authors 1140 retain all their rights. 1142 This document and the information contained herein are provided on an 1143 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1144 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1145 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1146 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1147 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1148 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1150 Intellectual Property 1152 The IETF takes no position regarding the validity or scope of any 1153 Intellectual Property Rights or other rights that might be claimed to 1154 pertain to the implementation or use of the technology described in 1155 this document or the extent to which any license under such rights 1156 might or might not be available; nor does it represent that it has 1157 made any independent effort to identify any such rights. Information 1158 on the procedures with respect to rights in RFC documents can be 1159 found in BCP 78 and BCP 79. 1161 Copies of IPR disclosures made to the IETF Secretariat and any 1162 assurances of licenses to be made available, or the result of an 1163 attempt made to obtain a general license or permission for the use of 1164 such proprietary rights by implementers or users of this 1165 specification can be obtained from the IETF on-line IPR repository at 1166 http://www.ietf.org/ipr. 1168 The IETF invites any interested party to bring to its attention any 1169 copyrights, patents or patent applications, or other proprietary 1170 rights that may cover technology that may be required to implement 1171 this standard. Please address the information to the IETF at 1172 ietf-ipr@ietf.org. 1174 Acknowledgment 1176 Funding for the RFC Editor function is provided by the IETF 1177 Administrative Support Activity (IASA).