idnits 2.17.1 draft-ietf-geopriv-pdif-lo-profile-12.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 1126. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1137. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1144. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1150. 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 (September 12, 2008) is 5705 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: March 16, 2009 Nokia Siemens Networks 7 September 12, 2008 9 GEOPRIV PIDF-LO Usage Clarification, Considerations and Recommendations 10 draft-ietf-geopriv-pdif-lo-profile-12.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 March 16, 2009. 37 Abstract 39 The Presence Information Data Format Location Object (PIDF-LO) 40 specification provides a flexible and versatile means to represent 41 location information. There are, however, circumstances that arise 42 when information needs to be constrained in how it is represented. 43 In these circumstances the range of options that need to be 44 implemented are reduced. There is growing interest in being able to 45 use location information contained in a PIDF-LO for routing 46 applications. To allow successful interoperability between 47 applications, location information needs to be normative and more 48 tightly constrained than is currently specified in the RFC 4119 49 (PIDF-LO). This document makes recommendations on how to constrain, 50 represent and interpret locations in a PIDF-LO. It further 51 recommends a subset of GML that is mandatory to implement by 52 applications involved in location based routing. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 58 3. Using Location Information . . . . . . . . . . . . . . . . . . 6 59 3.1. Single Civic Location Information . . . . . . . . . . . . 9 60 3.2. Civic and Geospatial Location Information . . . . . . . . 9 61 3.3. Manual/Automatic Configuration of Location Information . . 10 62 3.4. Multiple Location Objects in a Single PIDF-LO . . . . . . 11 63 4. Geodetic Coordinate Representation . . . . . . . . . . . . . . 13 64 5. Geodetic Shape Representation . . . . . . . . . . . . . . . . 14 65 5.1. Polygon Restrictions . . . . . . . . . . . . . . . . . . . 15 66 5.2. Shape Examples . . . . . . . . . . . . . . . . . . . . . . 16 67 5.2.1. Point . . . . . . . . . . . . . . . . . . . . . . . . 16 68 5.2.2. Polygon . . . . . . . . . . . . . . . . . . . . . . . 17 69 5.2.3. Circle . . . . . . . . . . . . . . . . . . . . . . . . 19 70 5.2.4. Ellipse . . . . . . . . . . . . . . . . . . . . . . . 20 71 5.2.5. Arc Band . . . . . . . . . . . . . . . . . . . . . . . 21 72 5.2.6. Sphere . . . . . . . . . . . . . . . . . . . . . . . . 23 73 5.2.7. Ellipsoid . . . . . . . . . . . . . . . . . . . . . . 24 74 5.2.8. Prism . . . . . . . . . . . . . . . . . . . . . . . . 26 75 6. Security Considerations . . . . . . . . . . . . . . . . . . . 29 76 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 77 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 31 78 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32 79 9.1. Normative references . . . . . . . . . . . . . . . . . . . 32 80 9.2. Informative References . . . . . . . . . . . . . . . . . . 32 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33 82 Intellectual Property and Copyright Statements . . . . . . . . . . 34 84 1. Introduction 86 The Presence Information Data Format Location Object (PIDF-LO) 87 [RFC4119] is the recommended way of encoding location information and 88 associated privacy policies. Location information in a PIDF-LO may 89 be described in a geospatial manner based on a subset of GMLv3, or as 90 civic location information [RFC5139]. A GML profile for expressing 91 geodetic shapes in a PIDF-LO is described in [GeoShape]. Uses for 92 PIDF-LO are envisioned in the context of numerous location based 93 applications. This document makes recommendations for formats and 94 conventions to make interoperability less problematic. 96 The PIDF-LO provides a general presence format for representing 97 location information, and permits specification of location 98 information relating to a whole range of aspects of a Target. The 99 general presence data model is described in [RFC4479] and caters for 100 a presence document to describe different aspects of the reachability 101 of a presentity. Continuing this approach, a presence document may 102 contain several GEOPRIV objects that specify different locations and 103 aspects of reachability relating to a presentity. This degree of 104 flexibility is important, and recommendations in this document make 105 no attempt to forbid the usage of a PIDF-LO in this manner. This 106 document provides a specific set of guidelines for building presence 107 documents when it is important to unambiguously convey exactly one 108 location. 110 2. Terminology 112 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 113 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 114 document are to be interpreted as described in [RFC2119]. 116 The definition for "Target" is taken from [RFC3693]. 118 In this document a "discrete location" is defined as a place, point, 119 area or volume in which a Target can be found. 121 The term "compound location" is used to describe location information 122 represented by a composite of both civic and geodetic information. 123 An example of compound location might be a geodetic polygon 124 describing the perimeter of a building and a civic element 125 representing the floor in the building. 127 The term "method" in this document refers to the mechanism used to 128 determine the location of a Target. This may be something employed 129 by a LIS, or by the Target itself. It specifically does not refer to 130 the LCP used to deliver location information either to the Target or 131 the Recipient. 133 The term "source" is used to refer to the LIS, node or device from 134 which a Recipient (Target or Third-Party) obtains location 135 information. 137 3. Using Location Information 139 The PIDF format provides for an unbounded number of , 140 , and elements. Each of these elements contains a 141 single element that may contain more than one 142 element as a child. Each element must contain at least the 143 following two child elements: element and element. One or more chunks of location information are 145 contained inside a element. 147 Hence, a single PIDF document may contain an arbitrary number of 148 location objects some or all of which may be contradictory or 149 complementary. Graphically, the structure of a PIDF-LO document can 150 be depicted as shown in Figure 1. 152 153 154 -- #1 155 156 -- #1 157 158 location chunk #1 159 location chunk #2 160 ... 161 location chunk #n 162 163 164 -- #2 165 -- #3 166 ... 167 -- #m 168 169 170 171 -- #1 172 173 location chunk #1 174 location chunk #2 175 ... 176 location chunk #n 177 178 179 -- #2 180 -- #3 181 ... 182 -- #m 183 184 185 -- #1 186 187 location chunk #1 188 location chunk #2 189 ... 190 location chunk #n 191 192 193 -- #2 194 -- #3 195 ... 196 -- #m 197 198 -- #2 199 -- #2 200 -- #2 201 ... 202 -- #o 203 205 Figure 1: Structure of a PIDF-LO Document 207 All of these potential sources and storage places for location lead 208 to confusion for the generators, conveyors and consumers of location 209 information. Practical experience within the United States National 210 Emergency Number Association (NENA) in trying to solve these 211 ambiguities led to a set of conventions being adopted. These rules 212 do not have any particular order, but should be followed by creators 213 and consumers of location information contained in a PIDF-LO to 214 ensure that a consistent interpretation of the data can be achieved. 216 Rule #1: A element MUST describe a discrete location. 218 Rule #2: Where a discrete location can be uniquely described in more 219 than one way, each location description SHOULD reside in a 220 separate , , or element; only one geopriv 221 element per tuple. 223 Rule #3: Providing more than one element in a single 224 presence document (PIDF) MUST only be done if the locations refer 225 to the same place or are put into different element types. For 226 example, one location in a , a second location in a 227 element, and a third location in a element. 229 This may occur if a Target's location is determined using a 230 series of different techniques, or the Target wishes to 231 represent her location as well as the location of her PC. In 232 general avoid putting more than one location into a document 233 unless it makes sense to do so. 235 Rule #4: Providing more than one location chunk in a single 236 element SHOULD be avoided where possible. Rule #5 237 and Rule #6 provide further refinement. 239 Rule #5: When providing more than one location chunk in a single 240 element the locations MUST be provided by a common 241 source at the same time and by the same location determination 242 method. 244 Rule #6: Providing more than one location chunk in a single 245 element SHOULD only be used for representing 246 compound location referring to the same place. 248 For example, a geodetic location describing a point, and a 249 civic location indicating the floor in a building. 251 Rule #7: Where compound location is provided in a single element, the coarse location information MUST be provided 253 first. 255 For example, a geodetic location describing an area, and a 256 civic location indicating the floor should be represented with 257 the area first followed by the civic location. 259 Rule #8: Where a PIDF document contains more than one 260 element, the priority of interpretation is given to the first 261 element in the document containing a location. If no 262 element containing a location is present in the document, 263 then priority is given to the first element containing a 264 location. Locations contained in tuples SHOULD only be 265 used as a last resort. 267 Rule #9: Where multiple PIDF documents can be sent or received 268 together, say in a multi-part MIME body, and current location 269 information is required by the recipient, then document selection 270 SHOULD be based on document order, with the first document 271 considered first. 273 The following examples illustrate the application of these rules. 275 3.1. Single Civic Location Information 277 Jane is at a coffee shop on the ground floor of a large shopping 278 mall. Jane turns on her laptop and connects to the coffee-shop's 279 WiFi hotspot, Jane obtains a complete civic address for her current 280 location, for example using the DHCP civic mechanism defined in 281 [RFC4776]. A Location Object is constructed consisting of a single 282 PIDF document, with a single or element, a single 283 element, a single element, and a single location 284 chunk residing in the element. This document is 285 unambiguous, and should be interpreted consistently by receiving 286 nodes if sent over the network. 288 3.2. Civic and Geospatial Location Information 290 Mike is visiting his Seattle office and connects his laptop into the 291 Ethernet port in a spare cube. In this case location information is 292 geodetic location, with the altitude represented as a building floor 293 number. Mike's main location is the point specified by the geodetic 294 coordinates. Further, Mike is on the second floor of the building 295 located at these coordinates. Applying rules #6 and #7, the 296 resulting compound location information is shown in Figure 2. 298 299 305 306 307 308 309 -43.5723 153.21760 310 311 312 2 313 314 315 316 Wiremap 317 318 2007-06-22T20:57:29Z 319 mac:8a-sd-7d-7d-70-cf 320 321 323 Figure 2 325 3.3. Manual/Automatic Configuration of Location Information 327 Loraine has a predefined civic location stored in her laptop, since 328 she normally lives in Sydney, the address is for her Sydney-based 329 apartment. Loraine decides to visit sunny San Francisco, and when 330 she gets there she plugs in her laptop and makes a call. Loraine's 331 laptop receives a new location from the visited network in San 332 Francisco. As this system cannot be sure that the pre-existing, and 333 new location, both describe the same place, Loraine's computer 334 generates a new PIDF-LO and will use this to represent Loraine's 335 location. If Loraine's computer were to add the new location to her 336 existing PIDF location document (breaking rule #3), then the correct 337 information may still be interpreted by the Location Recipient 338 providing Loraine's system applies rule #9. In this case the 339 resulting order of location information in the PIDF document should 340 be San Francisco first, followed by Sydney. Since the information is 341 provided by different sources, rule #8 should also be applied and the 342 information placed in different tuples with the tuple containing the 343 San Francisco location first. 345 3.4. Multiple Location Objects in a Single PIDF-LO 347 Vanessa has her PC with her at the park, but due to a 348 misconfiguration, her PC reports her location as being in the office. 349 The resulting PIDF-LO will have a element showing the 350 location of Vanessa's PC as the park, and a element saying 351 that Vanessa is in her office. 353 354 361 362 363 364 365 -34.410649 150.87651 366 367 30 368 369 370 371 372 GPS 373 374 2007-06-22T20:57:29Z 375 mac:12-34-56-78-90-ab 376 377 378 379 380 381 AU 382 NSW 383 Wollongong 384 North Wollongong 385 FlindersStreet 386 Campbell Street 387 388 Gilligan's Island 389 390 Corner 391 Main Bank 392 2500 393 398 394 store 395 Private Box 15 396 397 398 399 Manual 400 401 2007-06-24T12:28:04Z 402 403 405 Figure 3 407 4. Geodetic Coordinate Representation 409 The geodetic examples provided in RFC 4119 [RFC4119] are illustrated 410 using the element, which uses the 411 element inside the element and this representation has 412 several drawbacks. Firstly, it has been deprecated in later versions 413 of GML (3.1 and beyond) making it inadvisable to use for new 414 applications. Secondly, the format of the coordinates type is opaque 415 and so can be difficult to parse and interpret to ensure consistent 416 results, as the same geodetic location can be expressed in a variety 417 of ways. The PIDF-LO Geodetic Shapes specification [GeoShape] 418 provides a specific GML profile for expressing commonly used shapes 419 using simple GML representations. The shapes defined in [GeoShape] 420 are the recommended shapes to ensure interoperability. 422 5. Geodetic Shape Representation 424 The cellular mobile world today makes extensive use of geodetic based 425 location information for emergency and other location-based 426 applications. Generally these locations are expressed as a point 427 (either in two or three dimensions) and an area or volume of 428 uncertainty around the point. In theory, the area or volume 429 represents a coverage in which the user has a relatively high 430 probability of being found, and the point is a convenient means of 431 defining the centroid for the area or volume. In practice, most 432 systems use the point as an absolute value and ignore the 433 uncertainty. It is difficult to determine if systems have been 434 implemented in this manner for simplicity, and even more difficult to 435 predict if uncertainty will play a more important role in the future. 436 An important decision is whether an uncertainty area should be 437 specified. 439 The PIDF-LO Geodetic Shapes specification [GeoShape] defines eight 440 shape types most of which are easily translated into shapes 441 definitions used in other applications and protocols, such as Open 442 Mobile Alliance (OMA) Mobile Location Protocol (MLP). For 443 completeness the shapes defined in [GeoShape] are listed below: 445 o Point (2d and 3d) 447 o Polygon (2d) 449 o Circle (2d) 451 o Ellipse (2d) 453 o Arc band (2d) 455 o Sphere (3d) 457 o Ellipsoid (3d) 459 o Prism (3d) 461 All above-listed shapes are mandatory to implement. 463 The GeoShape specification [GeoShape] also describes a standard set 464 of coordinate reference systems (CRS), unit of measure (UoM) and 465 conventions relating to lines and distances. The use of the WGS-84 466 coordinate reference system and the usage of EPSG-4326 (as identified 467 by the URN urn:ogc:def:crs:EPSG::4326) for two dimensional (2d) shape 468 representations and EPSG-4979 (as identified by the URN 469 urn:ogc:def:crs:EPSG::4979) for three dimensional (3d) volume 470 representations is mandated. Distance and heights are expressed in 471 meters using EPSG-9001 (as identified by the URN 472 urn:ogc:def:uom:EPSG::9001). Angular measures MUST use either 473 degrees or radians. Measures in degrees MUST be identified by the 474 URN urn:ogc:def:uom:EPSG::9102, measures in radians MUST be 475 identified by the URN urn:ogc:def:uom:EPSG::9101 477 Implementations MUST specify the CRS using the srsName attribute on 478 the outermost geometry element. The CRS MUST NOT be respecified or 479 changed for any sub-elements. The srsDimension attribute SHOULD be 480 omitted, since the number of dimensions in these CRSs is known. A 481 CRS MUST be specified using the above URN notation only; 482 implementations do not need to support user-defined CRSs. 484 It is RECOMMENDED that where uncertainty is included, a confidence of 485 95% is used. Specifying a convention for confidence enables better 486 use of uncertainty values. 488 5.1. Polygon Restrictions 490 The Polygon shape type defined in [GeoShape] intentionally does not 491 place any constraints on the number of vertices that may be included 492 to define the bounds of a polygon. This allows arbitrarily complex 493 shapes to be defined and conveyed in a PIDF-LO. However, where 494 location information is to be used in real-time processing 495 applications, such as location dependent routing, having arbitrarily 496 complex shapes consisting of tens or even hundreds of points could 497 result in significant performance impacts. To mitigate this risk it 498 is recommended that Polygon shapes be restricted to a maximum of 15 499 points (16 including the repeated point) when the location 500 information is intended for use in real-time applications. This 501 limit of 15 points is chosen to allow moderately complex shape 502 definitions while at the same time enabling interoperation with other 503 location transporting protocols such as those defined in 3GPP (see 504 [3GPP-TS-23_032]) and OMA where the 15 point limit is already 505 imposed. 507 The edges of a polygon are defined by the shortest path between two 508 points in space (not a geodesic curce). To avoid significant errors 509 arising from potential geodesic interpolation, the length between 510 adjacent vertices SHOULD be restricted to a maximum of 130km. More 511 information relating to this restriction is provided in [GeoShape]. 513 A connecting line SHALL NOT cross another connecting line of the same 514 Polygon. 516 Polygons SHOULD be defined with the upward normal pointing up. This 517 is accomplished by defining the vertices in a counter-clockwise 518 direction. 520 Points specified in a polygon MUST be coplanar and it is RECOMMENDED 521 that where points are specified in 3 dimensions that all points 522 maintain the same altitude. 524 5.2. Shape Examples 526 This section provides some examples of where some of the more complex 527 shapes are used, how they are determined, and how they are 528 represented in a PIDF-LO. Complete details on all of the GeoShape 529 types are provided in [GeoShape]. 531 5.2.1. Point 533 The point shape type is the simplest form of geodetic LI, which is 534 natively supported by GML. The gml:Point element is used when there 535 is no known uncertainty. A point also forms part of a number of 536 other geometries. A point may be specified using either WGS 84 537 (latitude, longitude) or WGS 84 (latitude, longitude, altitude). 538 Figure 4 shows a 2d point: 540 541 547 548 549 550 551 -34.407 150.883 552 553 554 555 Wiremap 556 557 2007-06-22T20:57:29Z 558 mac:12-34-56-78-90-ab 559 560 562 Figure 4 564 Figure 5 shows a 3d point: 566 567 572 573 574 575 577 -34.407 150.883 24.8 578 579 580 581 Wiremap 582 583 2007-06-22T20:57:29Z 584 mac:12-34-56-78-90-ab 585 586 588 Figure 5 590 5.2.2. Polygon 592 The polygon shape may be used to represent a building outline or 593 coverage area. The first and last points of the polygon have to be 594 the same. For example, looking at the hexagon in Figure 6 with 595 vertices, A, B, C, D, E, and F. The resulting polygon will be defined 596 with 7 points, with the first and last points both having the 597 coordinates of point A. 599 F--------------E 600 / \ 601 / \ 602 / \ 603 A D 604 \ / 605 \ / 606 \ / 607 B--------------C 609 Figure 6 611 612 616 617 618 619 620 621 622 623 43.311 -73.422 624 43.111 -73.322 625 43.111 -73.222 626 43.311 -73.122 627 43.411 -73.222 628 43.411 -73.322 629 43.311 -73.422 630 631 632 633 634 635 Wiremap 636 637 638 2007-06-22T20:57:29Z 639 640 642 Figure 7 644 In addition to the form shown in Figure 7 GML supports a posList 645 which provides a more compact representation for the coordinates of 646 the Polygon vertices than the discrete pos elements. The more 647 compact form is shown in Figure 8. Both forms are permitted. 649 650 654 655 656 657 658 659 660 661 662 43.311 -73.422 43.111 -73.322 663 43.111 -73.222 43.311 -73.122 664 43.411 -73.222 43.411 -73.322 665 43.311 -73.422 666 667 668 669 670 671 672 Wiremap 673 674 675 2007-06-22T20:57:29Z 676 677 679 Figure 8 681 5.2.3. Circle 683 The circular area is used for coordinates in two-dimensional CRSs to 684 describe uncertainty about a point. The definition is based on the 685 one-dimensional geometry in GML, gml:CircleByCenterPoint. The centre 686 point of a circular area is specified by using a two dimensional CRS; 687 in three dimensions, the orientation of the circle cannot be 688 specified correctly using this representation. A point with 689 uncertainty that is specified in three dimensions should use the 690 Sphere shape type. 692 693 698 699 700 701 702 703 42.5463 -73.2512 704 705 850.24 706 707 708 709 710 OTDOA 711 712 713 714 716 Figure 9 718 5.2.4. Ellipse 720 An elliptical area describes an ellipse in two dimensional space. 721 The ellipse is described by a center point, the length of its semi- 722 major and semi-minor axes, and the orientation of the semi-major 723 axis. Like the circular area (Circle), the ellipse MUST be specified 724 using the two dimensional CRS. 726 727 732 733 734 735 736 737 42.5463 -73.2512 738 739 1275 740 741 742 670 743 744 745 43.2 746 747 748 749 750 Device-Assisted_A-GPS 751 752 753 2007-06-22T20:57:29Z 754 755 757 Figure 10 759 The gml:pos element indicates the position of the center, or origin, 760 of the ellipse. The gs:semiMajorAxis and gs:semiMinorAxis elements 761 are the length of the semi-major and semi-minor axes respectively. 762 The gs:orientation element is the angle by which the semi-major axis 763 is rotated from the first axis of the CRS towards the second axis. 764 For WGS 84, the orientation indicates rotation from Northing to 765 Easting, which, if specified in degrees, is roughly equivalent to a 766 compass bearing (if magnetic north were the same as the WGS north 767 pole). Note: An ellipse with equal major and minor axis lengths is a 768 circle. 770 5.2.5. Arc Band 772 The arc band shape type is commonly generated in wireless systems 773 where timing advance or code offsets sequences are used to compensate 774 for distances between handsets and the access point. The arc band is 775 represented as two radii emanating from a central point, and two 776 angles which represent the starting angle and the opening angle of 777 the arc. In a cellular environment the central point is nominally 778 the location of the cell tower, the two radii are determined by the 779 extent of the timing advance, and the two angles are generally 780 provisioned information. 782 For example, Paul is using a cellular wireless device and is 7 timing 783 advance symbols away from the cell tower. For a GSM-based network 784 this would place Paul roughly between 3,594 meters and 4,148 meters 785 from the cell tower, providing the inner and outer radius values. If 786 the start angle is 20 degrees from north, and the opening angle is 787 120 degrees, an arc band representing Paul's location would look 788 similar to Figure 11. 790 N ^ ,.__ 791 | a(s) / `-. 792 | 20 / `-. 793 |--. / `. 794 | `/ \ 795 | /__ \ 796 | . `-. \ 797 | . `. \ 798 |. \ \ . 799 ---c-- a(o) -- | | --> 800 |. / 120 ' | E 801 | . / ' 802 | . / ; 803 .,' / 804 r(i)`. / 805 (3594m) `. / 806 `. ,' 807 `. ,' 808 r(o)`' 809 (4148m) 811 Figure 11 813 The resulting PIDF-LO is shown in Figure 12. 815 816 821 822 823 824 825 826 -43.5723 153.21760 827 828 3594 829 830 831 4148 832 833 834 20 835 836 837 20 838 839 840 841 842 TA-NMR 843 844 845 2007-06-22T20:57:29Z 846 847 849 Figure 12 851 An important note to make on the arc band is that the center point 852 used in the definition of the shape is not included in resulting 853 enclosed area, and that Target may be anywhere in the defined area of 854 the arc band. 856 5.2.6. Sphere 858 The sphere is a volume that provides the same information as a circle 859 in three dimensions. The sphere has to be specified using a three 860 dimensional CRS. Figure 13 shows the sphere shape, which is 861 identical to the circle example, except for the addition of an 862 altitude in the provided coordinates. 864 865 870 871 872 873 874 875 42.5463 -73.2512 26.3 876 877 850.24 878 879 880 881 882 Device-Based_A-GPS 883 884 885 886 888 Figure 13 890 5.2.7. Ellipsoid 892 The ellipsoid is the volume most commonly produced by GPS systems. 893 It is used extensively in navigation systems and wireless location 894 networks. The ellipsoid is constructed around a central point 895 specified in three dimensions, and three axies perpendicular to one 896 another are extended outwards from this point. These axies are 897 defined as the semi-major (M) axis, the semi-minor (m) axis, and the 898 vertical (v) axis respectively. An angle is used to express the 899 orientation of the ellipsoid. The orientation angle is measured in 900 degrees from north, and represents the direction of the semi-major 901 axis from the center point. 903 \ 904 _.-\""""^"""""-._ 905 .' \ | `. 906 / v m \ 907 | \ | | 908 | -c ----M---->| 909 | | 910 \ / 911 `._ _.' 912 `-...........-' 914 Figure 14 916 A PIDF-LO containing an ellipsoid appears as shown in Figure 15. 918 919 924 925 926 927 928 929 42.5463 -73.2512 26.3 930 931 7.7156 932 933 934 3.31 935 936 937 28.7 938 939 940 90 941 942 943 944 945 Hybrid_A-GPS 946 947 948 2007-06-22T20:57:29Z 949 950 952 Figure 15 954 5.2.8. Prism 956 A prism may be used to represent a section of a building or range of 957 floors of building. The prism extrudes a polygon by providing a 958 height element. It consists of a base made up of coplanar points 959 defined in 3 dimensions all at the same altitude. The prism is then 960 an extrusion from this base to the value specified in the height 961 element. If the height is negative, then the prism is extruded from 962 the top down, while a positive height extrudes from the bottom up. 963 The first and last points of the polygon have to be the same. 965 For example, looking at the cube in Figure 16. If the prism is 966 extruded from the bottom up, then the polygon forming the base of the 967 prism is defined with the points A, B, C, D, A. The height of the 968 prism is the distance between point A and point E in meters. 970 G-----F 971 /| /| 972 / | / | 973 H--+--E | 974 | C--|--B 975 | / | / 976 |/ |/ 977 D-----A 979 Figure 16 981 The resulting PIDF-LO is shown in Figure 17. 983 984 989 990 991 992 993 994 995 996 997 998 999 42.556844 -73.248157 36.6 1000 42.656844 -73.248157 36.6 1001 42.656844 -73.348157 36.6 1002 42.556844 -73.348157 36.6 1003 42.556844 -73.248157 36.6 1004 1005 1006 1007 1008 1009 1010 2.4 1011 1012 1013 1014 1015 Wiremap 1016 1017 1018 2007-06-22T20:57:29Z 1019 1020 1022 Figure 17 1024 6. Security Considerations 1026 The primary security considerations relate to how location 1027 information is conveyed and used, which are outside the scope of this 1028 document. This document is intended to serve only as a set of 1029 guidelines as to which elements MUST or SHOULD be implemented by 1030 systems wishing to perform location dependent routing. The 1031 ramification of such recommendations is that they extend to devices 1032 and clients that wish to make use of such services. 1034 7. IANA Considerations 1036 This document does not introduce any IANA considerations. 1038 8. Acknowledgments 1040 The authors would like to thank the GEOPRIV working group for their 1041 discussions in the context of PIDF-LO, in particular Carl Reed, Ron 1042 Lake, James Polk, Henning Schulzrinne, Jerome Grenier, Roger Marshall 1043 and Robert Sparks. Furthermore, we would like to thank Jon Peterson 1044 as the author of PIDF-LO and Nadine Abbott for her constructive 1045 comments in clarifying some aspects of the document. 1047 Thanks to Karen Navas for pointing out some emissions in the 1048 examples. 1050 9. References 1052 9.1. Normative references 1054 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1055 Requirement Levels", BCP 14, RFC 2119, March 1997. 1057 [RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object 1058 Format", RFC 4119, December 2005. 1060 [RFC4479] Rosenberg, J., "A Data Model for Presence", RFC 4479, 1061 July 2006. 1063 [GeoShape] 1064 Thomson, M. and C. Reed, "GML 3.1.1 PIDF-LO Shape 1065 Application Schema for use by the Internet Engineering 1066 Task Force (IETF)", Candidate OpenGIS Implementation 1067 Specification 06-142r1, Version: 1.0, April 2007. 1069 [RFC5139] Thomson, M. and J. Winterbottom, "Revised Civic Location 1070 Format for Presence Information Data Format Location 1071 Object (PIDF-LO)", RFC 5139, February 2008. 1073 9.2. Informative References 1075 [RFC4776] Schulzrinne, H., "Dynamic Host Configuration Protocol 1076 (DHCPv4 and DHCPv6) Option for Civic Addresses 1077 Configuration Information", RFC 4776, November 2006. 1079 [RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and 1080 J. Polk, "Geopriv Requirements", RFC 3693, February 2004. 1082 [3GPP-TS-23_032] 1083 "3GPP TS 23.032 V6.0.0 3rd Generation Partnership Project; 1084 Technical Specification Group Code Network; Universal 1085 Geographic Area Description (GAD)". 1087 Authors' Addresses 1089 James Winterbottom 1090 Andrew Corporation 1091 Wollongong 1092 NSW Australia 1094 Email: james.winterbottom@andrew.com 1096 Martin Thomson 1097 Andrew Corporation 1098 Wollongong 1099 NSW Australia 1101 Email: martin.thomson@andrew.com 1103 Hannes Tschofenig 1104 Nokia Siemens Networks 1105 Otto-Hahn-Ring 6 1106 Munich, Bavaria 81739 1107 Germany 1109 Email: Hannes.Tschofenig@nsn.com 1110 URI: http://www.tschofenig.com 1112 Full Copyright Statement 1114 Copyright (C) The IETF Trust (2008). 1116 This document is subject to the rights, licenses and restrictions 1117 contained in BCP 78, and except as set forth therein, the authors 1118 retain all their rights. 1120 This document and the information contained herein are provided on an 1121 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1122 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1123 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1124 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1125 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1126 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1128 Intellectual Property 1130 The IETF takes no position regarding the validity or scope of any 1131 Intellectual Property Rights or other rights that might be claimed to 1132 pertain to the implementation or use of the technology described in 1133 this document or the extent to which any license under such rights 1134 might or might not be available; nor does it represent that it has 1135 made any independent effort to identify any such rights. Information 1136 on the procedures with respect to rights in RFC documents can be 1137 found in BCP 78 and BCP 79. 1139 Copies of IPR disclosures made to the IETF Secretariat and any 1140 assurances of licenses to be made available, or the result of an 1141 attempt made to obtain a general license or permission for the use of 1142 such proprietary rights by implementers or users of this 1143 specification can be obtained from the IETF on-line IPR repository at 1144 http://www.ietf.org/ipr. 1146 The IETF invites any interested party to bring to its attention any 1147 copyrights, patents or patent applications, or other proprietary 1148 rights that may cover technology that may be required to implement 1149 this standard. Please address the information to the IETF at 1150 ietf-ipr@ietf.org.