idnits 2.17.00 (12 Aug 2021) /tmp/idnits6706/draft-bajko-arcband-shape-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 60 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 06, 2009) is 4695 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: '3GPP23032' is defined on line 324, but no explicit reference was found in the text == Unused Reference: 'RFC2131' is defined on line 331, but no explicit reference was found in the text == Unused Reference: 'RFC2434' is defined on line 336, but no explicit reference was found in the text == Unused Reference: 'RFC3046' is defined on line 340, but no explicit reference was found in the text == Unused Reference: 'RFC3118' is defined on line 343, but no explicit reference was found in the text == Unused Reference: 'RFC3825' is defined on line 346, but no explicit reference was found in the text == Unused Reference: 'RFC4119' is defined on line 350, but no explicit reference was found in the text == Unused Reference: 'RFC5139' is defined on line 353, but no explicit reference was found in the text == Unused Reference: 'RFC5191' is defined on line 357, but no explicit reference was found in the text == Unused Reference: 'WGS84' is defined on line 366, but no explicit reference was found in the text == Unused Reference: 'RFC1712' is defined on line 371, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 3825 (Obsoleted by RFC 6225) Summary: 3 errors (**), 0 flaws (~~), 13 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 GEOPRIV WG Gabor Bajko 3 Internet Draft Nokia 4 Intended Status: Informational H. Tschofenig 5 Expires: January 05, 2010 Nokia Siemens Networks 6 July 06, 2009 8 Arcband Shape Binary Encoding 9 draft-bajko-arcband-shape-00.txt 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on January 05, 2010. 34 Copyright Notice 36 Copyright (c) 2009 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents in effect on the date of 41 publication of this document (http://trustee.ietf.org/license-info). 42 Please review these documents carefully, as they describe your rights 43 and restrictions with respect to this document. 45 Arc Band Binary Encoding July 05, 2009 47 Abstract 49 This document describes a binary encoding format for an arcband, 50 which is compatible with the binary encoding defined by 3GPP 51 [3GPP23.032], and which is widely used in today's cellular networks. 52 This encoding can additionally be used by a number of other 53 protocols, which demand a bandwidth efficient encoding of location 54 information, eg link layers like IEEE 802.11. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Conventions used in this document . . . . . . . . . . . . . . 4 60 3. Binary Arc Band Encoding . . . . . . . . . . . . . . . . . . . 5 61 4. Security Considerations . . . . . . . . . . . . . . . . . . . 9 62 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . .10 63 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .11 64 7. Normative References . . . . . . . . . . . . . . . . . . . .12 65 8. Informative References . . . . . . . . . . . . . . . . . . . 12 66 Appendix A. Example . . . . . . . . . . . . . . . . . . . . . . .14 67 Appendix B. Pseudocode . . . . . . . . . . . . . . . . . . . . 16 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . .. . 17 70 Arc Band Binary Encoding July 05, 2009 72 1. Introduction 74 This document describes a binary encoding format for an arcband 75 while RFC 5491 [RFC5491] describes the XML encoding of various 76 geolocation shapes, including an arcband, using the Geography Markup 77 Language (GML). 78 RFC3825bis specifies a binary encoding of location information by 79 approximating the area with a rectangle (in 2D) or a rectangular 80 prism (in 3D). Approximating a relatively small area, like the 81 coverage of an 802.11 access point with a rectangle is a good 82 approximation for convex areas including rectangles, circles, 83 ellipses or their 3D equivalents, but it can't describe an area with 84 a shape of an arch band. RFC5491 does define encoding in XML for 85 arch band, but link layer protocols where the Protocol Data Unit 86 field is limited, will find it difficult to transport an XML encoded 87 shape since that is a large piece of data. 88 The encoding described in this document is specified in 3GPP and 89 widely used in today's cellular networks. It is seen useful to 90 describe the encoding in an IETF document, so that can be used by a 91 number of other than cellular protocols, which demand a bandwidth 92 efficient encoding of location information, eg link layers like IEEE 93 802.11. 95 Having a binary encoding of an arch band available, enables a number 96 of uses cases, including the possibility for devices to measure and 97 communicate directly their location with the fixed station, using 98 the native link layer of the technology which was used to determine 99 the location. 101 2. Conventions used in this document 103 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 104 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 105 document are to be interpreted as described in [RFC2119]. 107 3. Arc Band 109 A location in the form of an archband can be the result of a device 110 using radio measurements to measure the distance from itself to a 111 fixed station, based on the time difference of arrival. If the time 112 difference of arrival could be measured with no uncertainty, the 113 resulting location would be a circle (in 2D) or the surface of a 114 sphere (in 3D). Since measuring with uncertainty of zero is 115 practically impossible, the resulting location would be an area 116 which is closer than a distance 'R+U' from the fixed station, and 117 further than a distance 'R': 119 Arc Band Binary Encoding July 05, 2009 121 __.......__ 122 _.-'' '-.. 123 ,-' '-. 124 ,' '. 125 ,' _....._ '\ 126 / \/ '' '' ` 127 / SD| _' '_ `. 128 / _' '_ \ 129 | , `\ | 130 | / \ | 131 | | O R | U | 132 | | .<---------->|<----->| 133 | | | .' 134 | \ / | 135 | \ / .' 136 \ \ / / 137 \ \ / ,' 138 ` '_ _' / 139 '. '_ _' ,' 140 '-. ....... _,' 141 '-._ _,-' 142 '`--......---' 143 SD is the sensing device 144 O is the origin of the circle 145 R is the radius of the inner circle 146 U is the uncertainty 148 When the fixed station is not omnidirectional, but radiates with an 149 angle a(o), then the resulting shape will be a partial arch band: 151 N ^ ,.__ 152 | a(s) / `-. 153 | / `-. 154 |--. / `. 155 | `/ \ 156 | /__ \ 157 | . `-. \ 158 | . `. \ 159 |. \ \ . 160 ---o-- a(o) -- | | --> 161 |< / ' | E 162 | . / ' 163 | . / ; 164 v,' / 165 r1 <. / 166 `. / 167 `. ,' 168 `. ,' 169 r2>' 171 Arc Band Binary Encoding July 05, 2009 173 A partial arch band is a shape characterised by the co-ordinates of 174 an ellipsoid point o (the origin), inner radius r1, uncertainty 175 radius r2, both radii being geodesic distances over the surface of 176 the ellipsoid, the offset angle (a(s)) between the first defining 177 radius of the ellipsoid arc and North, and the included angle (a(o)) 178 being the angle between the first and second defining radii. The 179 offset angle is within the range of 0 degree to 359,999... degree 180 while the included angle is within the range from 0,000...1 degree 181 to 360 degree. This is to be able to describe a full circle, 0 182 degree to 360 degree. 184 This shape-definition can also be used to describe a sector (inner 185 radius equal to zero), a circle (included angle equal to 360 degree) 186 and other circular shaped areas. The confidence level with which 187 the position of a target entity is included within the shape is also 188 included. 190 4. Encoding 192 7 6 5 4 3 2 1 0 193 +-+-+-+-+-+-+-+-+ 194 |S| Degrees | Octet 1 195 +-+-+-+-+-+-+-+-+ 196 | of | Octet 2 197 +-+-+-+-+-+-+-+-+ 198 | Latitude | Octet 3 199 +-+-+-+-+-+-+-+-+ 200 | Degrees | Octet 4 201 +-+-+-+-+-+-+-+-+ 202 | of | Octet 5 203 +-+-+-+-+-+-+-+-+ 204 | Longitude | Octet 6 205 +-+-+-+-+-+-+-+-+ 206 | Inner | Octet 7 207 +-+-+-+-+-+-+-+-+ 208 | Radius | Octet 8 209 +-+-+-+-+-+-+-+-+ 210 |R| Unc. Radius | Octet 9 211 +-+-+-+-+-+-+-+-+ 212 | Offset Angle | Octet 10 213 +-+-+-+-+-+-+-+-+ 214 | Included Angle| Octet 11 215 +-+-+-+-+-+-+-+-+ 216 |R| Confidence | Octet 12 217 +-+-+-+-+-+-+-+-+ 219 Legend: 221 R - Reserved. 223 S - Sign of latitude 224 Bit value 0: North 226 Arc Band Binary Encoding July 05, 2009 228 Bit value 1: South 230 Degrees of latitude: The latitude is coded with 24 bits: 1 bit of 231 sign and a number between 0 and 2^23-1 coded in binary on 23 bits. 232 The relation between the coded number N and the range of (absolute) 233 latitudes X it encodes is the following (X in degrees): 235 N <= (2^23 / 90) * X < N+1 237 except for N=2^23-1, for which the range is extended to include N+1. 239 Bit 1 of octet 4 is the low order bit 241 Degrees of longitude: The longitude, expressed in the range -180 242 degrees, +180 degrees, is coded as a number between -2^23 and 2^23- 243 1, coded in 2's complement binary on 24 bits. The relation between 244 the coded number N and the range of longitude X it encodes is the 245 following (X in degrees): 247 N <= (2^24 / 360) * X < N+1 249 Bit 1 of octet 7 is the low order bit. 251 Inner Radius: Inner radius is encoded in increments of 5 meters 252 using a 16 bit binary coded number N. The relation between the 253 number N and the range of radius r (in metres) it encodes is 254 described by the following equation: 256 5 N <= r < 5 (N+1) 258 Except for N=2^16-1 for which the range is extended to include all 259 greater values of r. This provides a true maximum radius of 327,675 260 meters. 262 Bit 8 of octet 7 is the high order bit. Bit 1 of octet 8 is the low 263 order bit. 265 Unc. Radius: A method of describing the uncertainty for latitude 266 and longitude has been sought which is both flexible (can cover wide 267 differences in range) and efficient. The proposed solution makes 268 use of a variation on the Binomial expansion. The uncertainty r, 269 expressed in metres, is mapped to a number K, with the following 270 formula: 272 r = C((1+x)^K - 1) 274 with C = 10 and x = 0,1. With 0 <= K <= 127, a suitably useful 275 range between 0 and 1800 kilometres is achieved for the uncertainty, 276 while still being able to code down to values as small as 1 metre. 277 The uncertainty can then be coded on 7 bits, as the binary encoding 278 of K. 280 Arc Band Binary Encoding July 05, 2009 282 Offset Angle and Included Angle: Offset angle and Included angle 283 are encoded in increments of 2 degrees using an 8 bit binary coded 284 number N in the range 0 to 179. The relation between the number N 285 and the range offset (ao) and included (ai) of angles (in degrees) 286 it encodes is described by the following equations: 288 Offset angle (ao): 2 N <= ao < 2 (N+1) 290 Accepted values for ao are within the range from 0 to 359,9...9 291 degrees. 293 Included angle (ai): 2 N < ai <= 2 (N+1) 295 Accepted values for ai are within the range from 0,0...1 to 360 296 degrees. 298 Confidence: The confidence by which the position of a target entity 299 is known to be within the shape description, (expressed as a 300 percentage) is directly mapped from the 7 bit binary number K, 301 except for K=0 which is used to indicate 'no information', and 100 < 302 K <= 128 which SHOULD NOT be used but MAY be interpreted as "no 303 information", if received. 305 5. Security Considerations 307 This document defines the binary encoding of an arcband but does not 308 describe the protocols that may be carrying it. No security issues 309 are raised by the format itself. When put into a protocol then the 310 typical communication security aspects and privacy considerations 311 have to be dealt with. 313 6. IANA considerations 315 7. Acknowledgements 317 To provide a maximum of compatibility with existing systems this 318 document re-uses the binary encoding of the arcband format defined 319 in the 3GPP TS 23.032 [3GPP-TS-23_032] specification. We would like 320 to thank the 3GPP for their work. 322 8. Normative References 324 [3GPP23032] "3GPP TS 23.032 V7.0.0 3rd Generation Partnership 325 Project; Technical Specification Group Code Network; 326 Universal Geographic Area Description (GAD)". 328 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 329 Requirement Levels", BCP 14, RFC 2119, March 1997. 331 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 332 2131, March 1997. 334 Arc Band Binary Encoding July 05, 2009 336 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 337 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 338 October 1998. 340 [RFC3046] Patrick, M., "DHCP Relay Agent Information Option", RFC 341 3046, January 2001. 343 [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP 344 Messages", RFC 3118, June 2001. 346 [RFC3825] Polk, J., Schnizlein, J., and M. Linsner, "Dynamic Host 347 Configuration Protocol Option for Coordinate-based 348 Location Configuration Information", RFC 3825, July 2004. 350 [RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object 351 Format", RFC 4119, December 2005. 353 [RFC5139] Thomson, M. and J. Winterbottom, "Revised Civic Location 354 Format for Presence Information Data Format Location 355 Object (PIDF-LO)", RFC 5139, February 2008. 357 [RFC5191] Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H., and A. 358 Yegin, "Protocol for Carrying Authentication for Network 359 Access (PANA)", RFC 5191, May 2008. 361 [RFC5491] Winterbottom, J., Thomson, M., and H. Tschofenig, 362 "GEOPRIV Presence Information Data Format Location Object 363 (PIDF-LO) Usage Clarification, Considerations, and 364 Recommendations", RFC 5491, March 2009. 366 [WGS84] "World Geodetic System 1984 (WGS 84), MIL-STD-2401, 367 http://www.wgs84.com/". 369 8. Informative References 371 [RFC1712] Farrell, C., Schulze, M., Pleitner, S., and D. Baldoni, 372 "DNS Encoding of Geographical Location", RFC 1712, 373 November 1994. 375 Arc Band Binary Encoding July 05, 2009 377 Appendix A. Example 379 This section provides an example with the corresponding GML 380 encoding. 382 For example, Paul is using a cellular wireless device and is 7 383 timing advance symbols away from the cell tower. For a GSM-based 384 network this would place Paul roughly between 3,594 meters and 4,148 385 meters from the cell tower, providing the inner and outer radius 386 values. If the start angle is 20 degrees from north, and the 387 opening angle is 120 degrees, an arc band representing Paul's 388 location would look similar to the figure below. 390 N ^ ,.__ 391 | a(s) / `-. 392 | 20 / `-. 393 |--. / `. 394 | `/ \ 395 | /__ \ 396 | . `-. \ 397 | . `. \ 398 |. \ \ . 399 ---o-- a(o) -- | | --> 400 |. / 120 ' | E 401 | . / ' 402 | . / ; 403 .,' / 404 r(i)`. / 405 (3594m) `. / 406 `. ,' 407 `. ,' 408 r(o)`' 409 (4148m) 411 412 418 419 420 421 422 423 424 -43.5723 153.21760 425 426 427 3594 429 Arc Band Binary Encoding July 05, 2009 431 432 433 4148 434 435 436 20 437 438 439 20 440 441 442 443 444 445 446 2003-06-22T20:57:29Z 447 448 450 Appendix B. Pseudocode 452 TBD: Code goes in here. 454 8. Author's Addresses 456 Gabor Bajko 457 gabor(dot)bajko(at)nokia(dot)com 459 Hannes Tschofenig 460 Nokia Siemens Networks 461 Otto-Hahn-Ring 6 462 Munich, Bavaria 81739 463 Germany 465 Email: Hannes.Tschofenig@nsn.com 466 URI: http://www.tschofenig.priv.at