idnits 2.17.1 draft-marshall-ecrit-indoor-location-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 285 has weird spacing: '...d to be optim...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (March 1, 2015) is 3344 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) == Missing Reference: 'IETF RFC6280' is mentioned on line 467, but not defined == Unused Reference: 'RFC4119' is defined on line 748, but no explicit reference was found in the text == Unused Reference: 'RFC6280' is defined on line 751, but no explicit reference was found in the text == Unused Reference: 'RFC5222' is defined on line 758, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ECRIT R. Marshall 3 Internet-Draft TCS 4 Intended status: Standards Track M. Linsner 5 Expires: September 2, 2015 Cisco 6 D. Stanley 7 Aruba Networks 8 March 1, 2015 10 Indoor Location Mechanisms for Emergency Services 11 draft-marshall-ecrit-indoor-location-00 13 Abstract 15 The application of summoning emergency assistance by using a phone to 16 call 9-1-1 in North America has been ingrained in society for 40+ 17 years. A successful emergency response to a caller in need, is 18 dependent upon the responders receiving accurate location information 19 to effect timely action. Traditional wireline telephony is able to 20 utilize the location of the physical wires as a source of information 21 for caller location, whereas wireless technologies require more 22 exotic mechanisms to locate a 9-1-1 caller. 24 Mechanisms for locating a cellular caller dialing 9-1-1 is based on 25 20 year old technology, which was designed for outdoor environments, 26 and does not perform sufficiently when used to locate an emergency 27 caller from within a home or office building environment. 29 With growing trends in mobile cellular usage, large portions of 30 subscribers are relying solely on their mobile phones to make 31 emergency calls. Emergency response time suffers when that caller is 32 located indoors. 34 This document defines the problem statement and solutions for 35 expanding the current set of methods used to locate a cellular caller 36 to 9-1-1. The expansion of the methods includes connections to 37 services that are outside the normal administrative domain of the 38 cellular provider, hence both the privacy and security aspects of 39 connecting these systems are taken into consideration. 41 Status of This Memo 43 This Internet-Draft is submitted in full conformance with the 44 provisions of BCP 78 and BCP 79. 46 Internet-Drafts are working documents of the Internet Engineering 47 Task Force (IETF). Note that other groups may also distribute 48 working documents as Internet-Drafts. The list of current Internet- 49 Drafts is at http://datatracker.ietf.org/drafts/current/. 51 Internet-Drafts are draft documents valid for a maximum of six months 52 and may be updated, replaced, or obsoleted by other documents at any 53 time. It is inappropriate to use Internet-Drafts as reference 54 material or to cite them other than as "work in progress." 56 This Internet-Draft will expire on September 2, 2015. 58 Copyright Notice 60 Copyright (c) 2015 IETF Trust and the persons identified as the 61 document authors. All rights reserved. 63 This document is subject to BCP 78 and the IETF Trust's Legal 64 Provisions Relating to IETF Documents 65 (http://trustee.ietf.org/license-info) in effect on the date of 66 publication of this document. Please review these documents 67 carefully, as they describe your rights and restrictions with respect 68 to this document. Code Components extracted from this document must 69 include Simplified BSD License text as described in Section 4.e of 70 the Trust Legal Provisions and are provided without warranty as 71 described in the Simplified BSD License. 73 Table of Contents 75 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 76 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 77 3. Basic Assumptions for Indoor Location . . . . . . . . . . . . 6 78 4. Challenges with location indoors . . . . . . . . . . . . . . 8 79 5. Outdoor Location Technologies . . . . . . . . . . . . . . . . 8 80 6. Indoor Location Technologies . . . . . . . . . . . . . . . . 9 81 7. Type of Location Environment . . . . . . . . . . . . . . . . 9 82 8. Provisioned Location Database . . . . . . . . . . . . . . . . 10 83 9. Enterprise Provisioned Indoor Location . . . . . . . . . . . 10 84 10. Enterprise Measured Indoor Location . . . . . . . . . . . . . 11 85 11. Indoor Location for Residential . . . . . . . . . . . . . . . 11 86 12. Obtaining an Identifier . . . . . . . . . . . . . . . . . . . 12 87 13. Indoor Location Example Use Case . . . . . . . . . . . . . . 13 88 14. Security Considerations . . . . . . . . . . . . . . . . . . . 16 89 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 90 16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 91 17. Changes from Previous Versions . . . . . . . . . . . . . . . 17 92 17.1. Changes from draft- . . . . . . . . . . . . . . . . . . 17 93 18. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 94 18.1. Normative References . . . . . . . . . . . . . . . . . . 17 95 18.2. Informative References . . . . . . . . . . . . . . . . . 17 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 99 1. Introduction 101 Most of the current mechanisms for locating a cellular caller after 102 dialing 9-1-1 in the USA are based on 20 year old technology, and 103 which were designed to locate devices in outdoor environments. So 104 it's not surprising to find out that these mechanism do not always 105 perform very well when used to locate an emergency caller from within 106 a building or enclosed environment. The growing trend of mobile 107 device use for requesting emergency services includes more and more 108 emergency calls being made from inside a structure as well as 109 outside. At the same time, some mobile wireless subscribers are 110 removing their legacy wireline phone service from within their homes, 111 and relying solely on their mobile phones for all calls, including 112 those emergency calls. While replacement of wireline phones in 113 exchange for mobile wireless-only connectivity inside the home is not 114 ubitquitous, it is already apparent that as wireless signal coverage 115 indoors improves, an ever increasing number of emergency calls will 116 be initiated from mobile handsets while inside the home. 118 Emergency services wireless location technology when first deployed, 119 was implemented as either a network-based or handset-based 120 technology. Handset based implementation required special hardware 121 and/or software in the handset. Network based solutions required 122 additional equipment installed in the service provider's Radio Access 123 Network (RAN), but didn't typically rely on changes to the handset. 124 The methods and protocols used to utilize these technologies were 125 standardized, and for the most part, wholly contained within the 126 control of the mobile operators' networks, and were largely based on 127 standards developed by Telecommunications Industry Association (TIA), 128 3rd Generation Partnership Program (3GPP), and Open Mobile Alliance 129 (OMA). 131 Given recent regulatory activities and resultant voluntary carrier- 132 industry agreements around the advancement of indoor location 133 capabilities leveraging new location technologies, there is a need to 134 provide some background as well as a list of assumptions and 135 potential solutions to solve the indoor location challenge. While 136 development of an emergency location architecture and protocols might 137 be the primary focus for North America at the moment, there is also 138 an opportunity to inform a broader (global) audience as to the 139 problem space, since the challenges and benefits are not constrained. 141 Location information that gets used to dispatch emergency resources 142 to a caller in reporting an emergency, needs to be in the form of a 143 civic street address. Most emergency calls are routed to the 144 appropriate PSAP based on coarse, cell tower location, which is then 145 followed up with a dynamically measured geographic (i.e., "geo") 146 position estimate (referred to in North America as wireless Phase 2 147 location). This finer grain position information includes lattitude, 148 longitude, horizontal uncertainty (HUNC) and a probability 149 (confidence). Though the estimated position may be within a few 150 meters to several hundred meters of the caller's device, this updated 151 position data is not considered by emergency responders to be good 152 enough for direct dispatch since lat/lon coordinates are meaningless 153 without having the ability to plot the position onto a map, or to 154 associate the postion to a civic street address. 156 Even if geo position information could be accomodated within the 157 emergency center's dispatch system, it use doesn't solve indoor 158 mobile use. As a mobile caller moves indoors, traditional outdoor 159 measurment methods become more challenging. What public safety 160 entities require is a "dispatchable location" in the form of a civic 161 street address along with additional data elements, such as building 162 number, room, and floor that will allow emergency responders find the 163 caller. 165 A dispatchable location is intended as a more complete description of 166 the civic address from where the caller's device is initiating an 167 emergency call, often including additional data elements such as 168 building, floor, and room, etc. Dispatchable location specifically 169 introduces the z-axis location (i.e., vertical elevation or altitude) 170 component that may be conveyed as floor number or distance as 171 measured above some referenced plane, such as meters above ground or 172 sea level. Since there are many ways to describe elevation 173 information, it will be important to determine the best use when 174 displaying z-axis information. 176 Facilitating convergence between new indoor location methods and 177 existing emergency location methods will require architectural 178 changes to existing standards in order to utilize technologies and 179 methods that are outside the traditional wireless operators' 180 controls, but which will still need to be integrated into a wireless 181 emergency E9-1-1 call. 183 The structure of this document includes terminology, Section 2, 184 followed by a section listing basic assumptions Section 3, an example 185 architecture, Section 13, and security Section 14 and privacy 186 concerns that are involved in obtaining and using indoor location 187 information. 189 2. Terminology 191 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 192 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 193 document are to be interpreted as described in RFC 2119 [RFC2119] 195 The following terms are defined in this document: 197 Indoor Location: The type of location information indicative of an 198 end device that is determined from within specific location/ 199 structure, such as within a building. 201 Outdoor Location: A type of location that is determined 202 representative of a device that is under open sky conditions. 204 Dispatchable Location: A form of location, either civic or geo, that 205 is considered useful for the dispatching of emergency responders 206 by emergency service personnel. Note: Typically, dispatchable 207 location is used interchangeably with dispatchable address. 209 Dispatchable Address: This is a sub-type of dispatchable location in 210 general, and by example, may be considered to be "dispatchable" if 211 it is a civic address representing the location of a caller's 212 mobile phone inside a house, office building, or multi-story 213 apartment building, etc., as long as the address is sufficiently 214 descriptive of the apartment, unit, floor, etc., for emergency 215 response personnel to find the caller. 217 Dispatchable Position: This is a sub-type of dispatchable location, 218 and is generally considered less popular for dispatch purposes, 219 since responders typically require a street address. An outdoor 220 location technology that provides a position estimate producing a 221 Lat/Lon coordinate pair, or even 3D Lat/Lon/Alt coordinates, for 222 example, might not be considered dispatchable by emergency service 223 personnel, because responders may not have a way of rendering a 224 geographic position even though the coordinates presented might be 225 close to the actual position of the caller. 227 Network-based location: A target location that is determined by the 228 radio access network and back end systems without requiring any 229 separate interaction from the end device. 231 Handset-based location: A target location that is determined using 232 techniques that interact with the end device (target) that is 233 being located. That is, the end device plays a part in the 234 location determination process. 236 User-plane location: Location that is determined using direct data 237 interaction techniques between the end device (target) and a 238 location generator. 240 Control-plane location: Location that is determined based on data 241 interaction between the end device and the access or application 242 service provider (ASP) location determination equipment through a 243 managed data connection. 245 Enterprise location: Location information that is representative of 246 data produced from within a managed corporate data network. 247 Examples include an corporate WLAN within an office building, 248 hotel, warehouse, corporate campus etc. 250 Residential location: Location information representative of data 251 descriptive of a single-family home, multi-tenant apartment or 252 condominium, etc. 254 Routing location: Location information that is used for the purpose 255 of performing a location-based routing operation. This is usually 256 in reference to coarse location, such as a cell tower civic 257 address or representative lat/lon. 259 Dispatch location: The location information that is used to dispatch 260 emergency responder resources. This is typically a civic street 261 address. 263 Augmented Location: Location information that is delivered along 264 with the basic routing and/or dispatch location information. In 265 the case of delivering indoor location along with the normal 266 dispatch location, the indoor location information might be 267 considered augmented location. 269 Enhanced Location: Location information that is considered to be 270 finer-grained information than the coarse location used for 271 routing. This location information is traditionally in the form 272 of a geographic position estimate in either 2D (Lat/Lon) or 3D 273 (Lat/Lon/Alt). 275 3. Basic Assumptions for Indoor Location 277 A short list of assumptions that help define the need for indoor 278 location is listed as follows. 280 A1. Not all wireless calls need indoor location: Many wireless 281 calls will continue to be initiated outside. For these cases, 282 existing technologies and processes will continue to be used to 283 meet present regulatory requirements. 285 A2. No single indoor location technology is expected to be optimal 286 for every environment: 287 Several indoor location technologies exist, each having its own 288 particular set of strengths and weaknesses as to its effectivness 289 in locating a mobile device deep within a building or structure. 291 A3. Dispatchable location is defined by context: The idea of what 292 dispatchable location is inside one type of building (e.g., high- 293 rise apartment building) may be different for a different type of 294 structure. Also, some emergency response personnel may consider 295 location information as dispatchable depending on the environment 296 reported. For example, geo position information would likely be 297 considered dispatchable by a mountain rescue group or Coast Guard 298 personnel. 300 A4. Dispatchable location format: The type of location preferred 301 for use in dispatching emergency services by a PSAP is of civic 302 location form (ref. Dispatchable Address). Most PSAPs and 303 emergency responders are only equipped to handle dispatch 304 information of the form of civic street address, as compared to a 305 geo position (e.g., Lat/Lon). 307 A5. Heightened location components: A geographic position estimate 308 (geo coordinate set, etc.) that is calculated as having a maximum 309 horizontal uncertainty (error) of 50 meters or less, and a 310 vertical uncertainty of 3 meters, as referenced to a specified 311 standard geographic datum. 313 A6. Dispatchable location vertical component: Dispatchable location 314 includes an indication of vertical height or elevation descriptor 315 if reporting from a significantly elevated position within a 316 structure or building. For example, dispatching emergency 317 resources to a location representing a structure more than 2 318 floors in height is effective only if the floor number is 319 included. Other units of measurement, such as height above sea 320 level, the ground, or a specified datum are typically considered 321 insufficient for the purposes of dispatching responder resources. 323 A7. Indoor Location applicability: Dispatchable location is 324 applicable for mobile CMRS emergency calls initiated from an 325 indoor environment. 327 A8. Applicability of Indoor Location for SMS text-to-9-1-1: Indoor 328 location is not currently applicable for use with SMS text-to- 329 9-1-1, since it is currently not covered by any regulatory or 330 voluntary industry agreement. 332 A9. Z-axis data: The vertical component of dispatchable location 333 information may include a one or more various representations of 334 elevation data. These could include floor number or altitude in 335 meters above a specified geographic datum. 337 A10. Integration of vertical information: Mapping servers and 338 protocols (i.e., RFC5222) will need to be changed to support the 339 ability to perform mapping based on the included z-axis data, both 340 for call routing and for dispatching responder resources. 342 4. Challenges with location indoors 344 This document describes a few different technologies that are being 345 considered for obtaining accuracte location information from an 346 indoor environment. Regardless of which type of technology, whether 347 considered to be an outdoor technology or an indoor technology, when 348 indoors, both strive to achieve similar goals. 350 The existing location systems that determine location of E9-1-1 351 callers while outdoors have not proven as effective in determining 352 location when the caller's device is deep within a building, parking 353 garage, or other structure. And due to an increasing percentage of 354 emergency calls being made from inside a building using a mobile 355 phone, there is an increased need to be able to adequately locate and 356 dispatch appropriate emergency responder resources to the caller's 357 actual location. Achieving this feat for calls made indoors is much 358 more challenging than for those calls made outdoors, since the 359 location of the caller is not as obvious to response personnel. As a 360 result, new location solutions are needed in order to provide 361 improved indoor location to support E9-1-1 emergency calls. 363 (U.S.) Government regulatory test results have taken intitial steps 364 to qualify location technologies [CSRIC test bed], yet none of the 365 technologies tested at that time fully met the target requirement of 366 +/-50 meters across 3 different morphologies [ref. specific CSRIC III 367 results]. The follow on work of CSRIC IV broadened the list of 368 possible location technologies to be considered with regard to 369 achieving more accurate location. The list of candidate technologies 370 is divided into two main categories: namely, what this document 371 refers to as separate outdoor and indoor location technologies. 373 5. Outdoor Location Technologies 375 Outdoor location technologies are designed to effectively locate 376 target devices whether indoors or outdoors, with varying levels of 377 measured accuracy. These are location technologies that are 378 naturally deployed outside of any structures, and to a significant 379 extent are able to locate devices within some types of structures as 380 well, depending on the surrounding environment. Some of these 381 methods include the following: 383 A-GPS: Assisted Gloal Positioning System 385 A-GNSS: Assisted Global Navigational Satellite System 387 O-TDOA: Observed Time Difference Of Arrival 389 U-TDOA: Observed Time Difference Of Arrival 391 AFLT: Advanced Forward Link Trilateration 393 TBS: Terrestrial Beacon System 395 6. Indoor Location Technologies 397 Indoor location technologies are designed to effectively locate 398 target devices that are within an indoor environment, usually within 399 a building or structure for which traditional outdoor location 400 methods prove less than optimal, or completely ineffective. These 401 are location technologies that are deployed inside of a structure. 402 Some of these methods include the following: 404 WPS: Wi-Fi Positioning System 406 WLAN APs: Wi-Fi Local Area Network Access Points 408 BLE Beacons: Bluetooth Low Energy Beacons 410 Small Cells: Small Cells, possibly including microcells, picocells, 411 and femtocells 413 7. Type of Location Environment 415 Enterprise Enterprises are typically thought of as organizations 416 that deploy and manage their own data networks for the use of 417 their staff, students, and sometimes on behalf of their customers 418 or visitors. Examples would include corporations, big or small, 419 college campuses, government entities, etc. 421 Residential Scenarios that include individually deployed data 422 services to a person's place of residenc, we think of as 423 Residential. Examples of this include single-family, multi-family 424 homes, condominiums, and apartment complexes. 426 8. Provisioned Location Database 428 One technique to getting indoor location in a Wi-Fi or BLE laden 429 environment is to provision each Wi-Fi access point or BLE beacon 430 into a database along with a dispatchable location. If the specific 431 Wi-Fi AP(s) and/or BLE beacon(s) that the mobile "sees" can be 432 identified, then those identifiers can be used in a database query to 433 ask for the provisioned location. This database is referred to by 434 public safety as the National Emergency Address Database (NEAD) in 435 the carrier voluntary agreement [provide reference]. 437 Some challenges to this approach include, getting a complete civic 438 location that is representative of the actual address, maintaining 439 the database in terms of contents, and discovering the database 440 identifier (e.g., MAC address) to query in order to obtain the 441 dispatchable location. 443 The provided location database would need to contain record 444 identifiers and location data. The record key would be MAC address, 445 either a BSSID for a Wi-Fi access point, or UUID/Major/Minor MAC 446 address for a BLE beacon. The database could also contain actual 447 location data relating to a civic street address, along with 448 additional detail information. Alternatively, it may contain a URI 449 (pointer) to a different database that would contain the actual 450 dispatchable location data. 452 9. Enterprise Provisioned Indoor Location 454 There are a number of different approaches to determining an indoor 455 location within an enterprise business environment. For emergency 456 calls that can't be adequately located inside a building, there are 457 ways to leverage other location relevant methods to obtain indoor 458 location. 460 One technique to obtaining indoor location information within an 461 Enterprise context is to utilize the device location capabilities of 462 enterprise wireless local-area network (WLAN) systems where 463 available. The enterprise WLAN device location entities include Wi- 464 Fi Access Points that are surveyed and provisioned ahead of time into 465 a database for later retrieval. This database could be referred to 466 as a Location Information Server (LIS) as described in the Geopriv 467 Architecture document [IETF RFC6280]. The identifier used in the 468 enterprise WLAN location process is the IEEE 802.11 BSSID, otherwise 469 known as Media Access Control (MAC) address of the Wi-Fi Access 470 Point. 472 The location information that is manually input into a LIS is 473 retrieved based on a query and the MAC adderess referencing the Wi-Fi 474 AP or BLE beacon. This query could be direct from a client or from a 475 proxied query, as in the case above. This location is returned to 476 the querying entity and displayed at the PSAP. 478 10. Enterprise Measured Indoor Location 480 An enterprise WLAN LIS that is queried with the MAC address of the 481 target device via the HELD interface. The WLAN LIS recognizes the 482 identifier of the device as within its management domain and and 483 returns the associated dispatchable location, and optionally, a geo- 484 coordinate location along with a building floor plan showing the 485 target device's position on the map. 487 A key part of obtaining location from an Enterprise WLAN LIS is to 488 know which LIS to query. For this we use a WLAN LIS discovery 489 approach based on GIS polygons at the 911SSP. The 911SSP already 490 knows which cell site the emergency call came from. In this way, 491 discovery of which enterprise LIS to query could include a polygon- 492 overlay method to identify connected enterprises with WLANs that 493 reside within the same cell-sector as the caller (cell-sector is a 494 known entity by the cellular network at the time of a call). 496 As PSAPs move toward NG9-1-1, delivery of rich content such as 497 building floor plans is expected. Even during transition, PSAPs that 498 opt for pre-NG9-1-1 mechanisms to display additional location related 499 data can do so through available tools such as a browser display 500 client. 502 11. Indoor Location for Residential 504 Many single family structures, most notably those that are wood frame 505 construction offer limited obstruction to traditional outside 506 location methods, including A-GPS that is used for current E9-1-1 507 Phase 2 locations. However, even in moderately restrictive 508 environments A-GPS results may not always provide a very precise fix 509 (i.e., low horizontal uncertainty) with the position information, 510 making the resultant system provided search area considerably more 511 challenging than a more precise fix. Dispatchable location, in this 512 case, is intended to provide the civic street address of the home 513 from which the call is being made from, which affords emergency 514 responders with specific address to go to. 516 It is possible to get multiple location fixes from different system 517 for the same call. This additional information, including both civic 518 street address and geo position information can be used to provide a 519 higher degree of certainty that the information accurately represents 520 the caller's true location. Each of these location data types may or 521 may not be provided by the same location technology. 523 Like enterprise solutions that rely on Wi-Fi radio signals to 524 correlate or calculate location results, residential location 525 solutions exist that leverage Wi-Fi signals from one or more access 526 points or beacons within a residence. In the case of a residential 527 Wi-Fi access point, the civic street address of the residence may be 528 able to be provisioned ahead of time in order to provide at call time 529 during an emergency situation. The challenge to using this data is 530 the question of how it can be trusted. 532 Besides single family residential structures, a more challenging 533 residential environment includes that of a multi-floor, multi-tenant 534 apartment building that may not have consistent deployment of Wi-Fi 535 or Bluetooth beacons, and where A-GPS or other outside location 536 technologies may not be effective. 538 12. Obtaining an Identifier 540 In order to use a identifier that is designed to get indoor location, 541 it must first become available to the location functions that need to 542 use it within the network. Examples of identifiers include a MAC 543 address of a target mobile device, a BSSID of a Wi-Fi Access Point, 544 or a BLE UUID/Major/Minor identifier. There are several approaches 545 to consider in seeking to obtain an identifier. 547 Provisioned/Associated: If we know the identifier of a mobile 548 handset, AP, or BLE beacon ahead of time, then it can be mapped to 549 a mobile directory number. The call processing system then maps 550 the incoming Mobile Directory Number (MDN) to the stored MAC 551 address. The MAC address is then used to query the location 552 generator for location. While this approach may be okay for demo 553 purposes, it is not feasible for a working system. 555 Another method for discovery of a device location while indoors is 556 to gather 'beacon' identifiers the calling device can see and 557 reference a location database of known 'beacons'. The term 558 'beacon' in this context includes IEEE 802.11 access points (AP) 559 and/or a Bluetooth 4.0 Low-Energy Beacon (BLE). The beacon 560 identifiers gathered by the calling device would include: 562 Handset Provided In-band: When a handset makes an emergency call, it 563 is possible to enable the handset to scan and collect all the Wi- 564 Fi and BLE identifiers that it sees, along with other measurement 565 data and include those data with the emergency call. This 566 capability will be more easily integrated into packet based access 567 networks that use SIP, for example, than for legacy circuit- 568 switched access networks, which would require significant 569 standards modification. Some newer standards, such as OMA SUPL 570 (v2.0.2) protocol, support the return of these types of data 571 extensions. 573 Handset Provided Out-of-band: An application can be installed onto a 574 handset that can then be invoked from a direct IP connection from 575 a trusted 911SSP network once the emergency call is initiated. 576 The handset then scans and collects all the Wi-Fi and BLE 577 identifiers that it sees, along with other measurement data and 578 sends those data back to the trusted 911SSP to be matched up to 579 the ongoing emergency call. 581 13. Indoor Location Example Use Case 583 Indoor location information is shown as augmenting the existing 584 emergency location data that is delivered during the an emergency 585 call scenario. In this use case, a mobile operator recognizes a 586 caller on their network has dialed 9-1-1 and forwards the call to the 587 designated 9-1-1 system service provider (911SSP). The MAC address 588 of a close by Wi-Fi AP that happens to have it's location already 589 entered into a provisioned location database is discovered [hand 590 waiving here] and delivered to the 911SSP which then initiates a 591 query to the provisioned location database requesting the provisioned 592 dispatchable address. 594 Information +-----------------+ 595 |(1) |Internet | +---------+ 596 v |Access | | | 597 +-----------+ |Provider | | Mapping | 598 | | | (3) | | Service | 599 | Emergency |<--+-----------------+----------->| | 600 | Caller | | (2,a) +---------+---+ +---------+ 601 | |<--+------>| | | ^ 602 | | | | | | +-------+ | 603 +-----------+ | | LIS | | | AP/BLE| | 604 ^ +-------+---------+ | | Data | | 605 | | | | Store | | 606 | +-------------+ +-------+ | 607 | ^ ^ ^ | 608 | | | (c,e) | (d) | 609 | (5,a) | v v | 610 | | +----------------+ | 611 | | | Augmented | | 612 | | | Location | | 613 | | | Server | | 614 | +---------+-----------+ | | 615 | | | | | | | 616 | | | +----------------+ | 617 | | | ^ | ^ | 618 | | | |(b,f)| | (g) | 619 | | v v | | | 620 | | +------------+ | | | 621 | (4) | | | | | | 622 +------------+--->| ESRP |<--+----+------+ 623 | | | | | | (6) 624 | | +------------+ | | 625 | | ^ | v 626 | | (7) | | +----+--+ 627 | (8) | +------------>| | 628 +------------+----------------------->| PSAP | 629 | | | | 630 |Application/ | +----+--+ 631 |Voice | 632 |Service | 633 |Provider | 634 +---------------------+ 636 The diagram shows new interaction between the entities involved in 637 the call in order to get indoor location. There are a number of 638 different deployment models possible, so this document will provide a 639 single example only. 641 Even through the Application/Voice Service Provider could be the same 642 entity as the Internet Access Provider, this figure shows them as 643 separate boxes. It does however show that the Location Information 644 Server may be deployed within the Internet Access Provider's control, 645 or may be outside of it. 647 Likewise, the Augmented Location Server - useful for getting Indoor 648 Location information in some morphologies, could also be deployed 649 within the Application/Voice Service Provider, or without. There is 650 no requirement either way. Moreover, we consider but don't show the 651 enterprise or residential scenarios where end systems might act as 652 their own ASP/VSP. 654 Various interaction scenarios between the entities for emergency call 655 initiation and processing are described in [ref. RFC5012]. The 656 below description highlights only the augmented location interaction: 658 a. Coarse Location information might be available to the end host 659 directly, obtainable via the Internet Access Provider's LIS, or 660 retrievable by the ESRP during call routing. 662 b. During call routing, the ESRP may ask the Augmented Location 663 Server for additional location, namely Indoor Location either 664 because of call marking, or by some rule, in which case it 665 queries the Augmented Location Server. 667 c. The Augmented Location Server discovers the MAC address of the 668 device currently making an emergency call and maps it to the 669 device's existing MDN. The MAC address may be obtained through 670 user plane query techniques as implied here, or via some other 671 method [ref. section MAC-discovery-TBD]. 673 d. Having obtained the MAC address of the target device, the 674 Augmented Location Server uses it to perform a location query a 675 public Wi-Fi Access Point/Bluetooth beacon database. Note: 676 Enterprise WLAN query for Wi-Fi location not shown. 678 e. The resulting data returned from the Enterprise WLAN location 679 server or AP/BLE Data Store can be either of the type of civic 680 address or geographic position, either in 2D or 3D format. If 681 the returned information is geographic, it will either return a 682 measured, surveyed, or estimated coordinate set, including some 683 indication of error (uncertainty and confidence). If the ALS 684 returns a civic address, it will be in the form of a PIDF-LO, and 685 MUST indicate any elevation infomation, such as floor number, 686 especially important if the actual location where the call is 687 coming from is a multi-story building. 689 f. The ALS then makes this information available to the ESRP either 690 in by-value or by-reference format, supplying a generated URL if 691 by-reference. 693 g. The augmented indoor location gets sent to the PSAP, again by- 694 value or by-reference. If a URL is provided to the PSAP, the 695 PSAP will dereference the augmented location information and get 696 back the indoor location information by-value. 698 14. Security Considerations 700 There are two glaring security issues when locating a caller to 701 emergency services. 703 1. The privacy of the caller's location data is of the utmost 704 importance to protect. Hence, any mechanism for the discovery of 705 the caller's location and the transport of the discovered data 706 MUST be protected by strong authentication and encryption. Any 707 method or protocol that is unique to emergency calls that could 708 be identified by monitoring uncrypted wireless networks MUST NOT 709 be used. 711 2. It is the utmost importance to protect the owners of enterprise 712 WLANs. These networks are the lifeblood of communications within 713 a business entity. At the same time, enterprises have a strong 714 desire to protect human life for employees, visitors, and 715 customers while on enterprise property. Any connection to the 716 enterprise LIS from the cellular network must utilize strong 717 encryption and strong authentication. The nature of the 718 connection is very low traffic, hence it is advised to utilize a 719 keep-alive method and accounting method with alarming on each so 720 any failure in the connection can be rectified in a reasonable 721 timeframe. The privacy of location data must be protected and 722 only shared with the CMRS provider during an emergency call. In 723 the US, CMRS providers are constrained by policy to perform 724 device location queries only during a 9-1-1 call. The location 725 data must be protected from the discovery method to the PSAP, 726 requiring both data integrity and data security end-to-end. 728 15. IANA Considerations 730 There are currently no IANA considerations. 732 16. Acknowledgements 733 17. Changes from Previous Versions 735 17.1. Changes from draft- 737 o 739 o 741 18. References 743 18.1. Normative References 745 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 746 Requirement Levels", BCP 14, RFC 2119, March 1997. 748 [RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object 749 Format", RFC 4119, December 2005. 751 [RFC6280] Barnes, R., Lepinski, M., Cooper, A., Morris, J., 752 Tschofenig, H., and H. Schulzrinne, "An Architecture for 753 Location and Location Privacy in Internet Applications", 754 BCP 160, RFC 6280, July 2011. 756 18.2. Informative References 758 [RFC5222] Hardie, T., Newton, A., Schulzrinne, H., and H. 759 Tschofenig, "LoST: A Location-to-Service Translation 760 Protocol", RFC 5222, August 2008. 762 Authors' Addresses 764 Roger Marshall 765 TeleCommunication Systems, Inc. 766 2401 Elliott Avenue 767 2nd Floor 768 Seattle, WA 98121 769 US 771 Phone: +1 206 792 2424 772 Email: rmarshall@telecomsys.com 773 URI: http://www.telecomsys.com 774 Marc Linsner 775 Cisco Systems 776 Marco Island, FL 34145 777 US 779 Email: marc.linsner@cisco.com 780 URI: http://www.cisco.com 782 Dorothy Stanley 783 Aruba Networks 784 1322 Crossman Ave 785 Sunnyvale, CA 786 US 788 Phone: 630-363-1389 789 Email: dstanley@arubanetworks.com 790 URI: http://www.arubanetworks.com