| ECRIT | R. Marshall |
| Internet-Draft | TCS |
| Intended status: Standards Track | M. Linsner |
| Expires: September 2, 2015 | Cisco |
| D. Stanley | |
| Aruba Networks | |
| March 1, 2015 |
Indoor Location Mechanisms for Emergency Services
draft-marshall-ecrit-indoor-location-00
The application of summoning emergency assistance by using a phone to call 9-1-1 in North America has been ingrained in society for 40+ years. A successful emergency response to a caller in need, is dependent upon the responders receiving accurate location information to effect timely action. Traditional wireline telephony is able to utilize the location of the physical wires as a source of information for caller location, whereas wireless technologies require more exotic mechanisms to locate a 9-1-1 caller.
Mechanisms for locating a cellular caller dialing 9-1-1 is based on 20 year old technology, which was designed for outdoor environments, and does not perform sufficiently when used to locate an emergency caller from within a home or office building environment.
With growing trends in mobile cellular usage, large portions of subscribers are relying solely on their mobile phones to make emergency calls. Emergency response time suffers when that caller is located indoors.
This document defines the problem statement and solutions for expanding the current set of methods used to locate a cellular caller to 9-1-1. The expansion of the methods includes connections to services that are outside the normal administrative domain of the cellular provider, hence both the privacy and security aspects of connecting these systems are taken into consideration.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 2, 2015.
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
Most of the current mechanisms for locating a cellular caller after dialing 9-1-1 in the USA are based on 20 year old technology, and which were designed to locate devices in outdoor environments. So it's not surprising to find out that these mechanism do not always perform very well when used to locate an emergency caller from within a building or enclosed environment. The growing trend of mobile device use for requesting emergency services includes more and more emergency calls being made from inside a structure as well as outside. At the same time, some mobile wireless subscribers are removing their legacy wireline phone service from within their homes, and relying solely on their mobile phones for all calls, including those emergency calls. While replacement of wireline phones in exchange for mobile wireless-only connectivity inside the home is not ubitquitous, it is already apparent that as wireless signal coverage indoors improves, an ever increasing number of emergency calls will be initiated from mobile handsets while inside the home.
Emergency services wireless location technology when first deployed, was implemented as either a network-based or handset-based technology. Handset based implementation required special hardware and/or software in the handset. Network based solutions required additional equipment installed in the service provider's Radio Access Network (RAN), but didn’t typically rely on changes to the handset. The methods and protocols used to utilize these technologies were standardized, and for the most part, wholly contained within the control of the mobile operators' networks, and were largely based on standards developed by Telecommunications Industry Association (TIA), 3rd Generation Partnership Program (3GPP), and Open Mobile Alliance (OMA).
Given recent regulatory activities and resultant voluntary carrier-industry agreements around the advancement of indoor location capabilities leveraging new location technologies, there is a need to provide some background as well as a list of assumptions and potential solutions to solve the indoor location challenge. While development of an emergency location architecture and protocols might be the primary focus for North America at the moment, there is also an opportunity to inform a broader (global) audience as to the problem space, since the challenges and benefits are not constrained.
Location information that gets used to dispatch emergency resources to a caller in reporting an emergency, needs to be in the form of a civic street address. Most emergency calls are routed to the appropriate PSAP based on coarse, cell tower location, which is then followed up with a dynamically measured geographic (i.e., "geo") position estimate (referred to in North America as wireless Phase 2 location). This finer grain position information includes lattitude, longitude, horizontal uncertainty (HUNC) and a probability (confidence). Though the estimated position may be within a few meters to several hundred meters of the caller's device, this updated position data is not considered by emergency responders to be good enough for direct dispatch since lat/lon coordinates are meaningless without having the ability to plot the position onto a map, or to associate the postion to a civic street address.
Even if geo position information could be accomodated within the emergency center's dispatch system, it use doesn't solve indoor mobile use. As a mobile caller moves indoors, traditional outdoor measurment methods become more challenging. What public safety entities require is a "dispatchable location" in the form of a civic street address along with additional data elements, such as building number, room, and floor that will allow emergency responders find the caller.
A dispatchable location is intended as a more complete description of the civic address from where the caller's device is initiating an emergency call, often including additional data elements such as building, floor, and room, etc. Dispatchable location specifically introduces the z-axis location (i.e., vertical elevation or altitude) component that may be conveyed as floor number or distance as measured above some referenced plane, such as meters above ground or sea level. Since there are many ways to describe elevation information, it will be important to determine the best use when displaying z-axis information.
Facilitating convergence between new indoor location methods and existing emergency location methods will require architectural changes to existing standards in order to utilize technologies and methods that are outside the traditional wireless operators' controls, but which will still need to be integrated into a wireless emergency E9-1-1 call.
The structure of this document includes terminology, Section 2, followed by a section listing basic assumptions Section 3, an example architecture, Section 13, and security Section 14 and privacy concerns that are involved in obtaining and using indoor location information.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]
The following terms are defined in this document:
A short list of assumptions that help define the need for indoor location is listed as follows.
This document describes a few different technologies that are being considered for obtaining accuracte location information from an indoor environment. Regardless of which type of technology, whether considered to be an outdoor technology or an indoor technology, when indoors, both strive to achieve similar goals.
The existing location systems that determine location of E9-1-1 callers while outdoors have not proven as effective in determining location when the caller's device is deep within a building, parking garage, or other structure. And due to an increasing percentage of emergency calls being made from inside a building using a mobile phone, there is an increased need to be able to adequately locate and dispatch appropriate emergency responder resources to the caller's actual location. Achieving this feat for calls made indoors is much more challenging than for those calls made outdoors, since the location of the caller is not as obvious to response personnel. As a result, new location solutions are needed in order to provide improved indoor location to support E9-1-1 emergency calls.
(U.S.) Government regulatory test results have taken intitial steps to qualify location technologies [CSRIC test bed], yet none of the technologies tested at that time fully met the target requirement of +/-50 meters across 3 different morphologies [ref. specific CSRIC III results]. The follow on work of CSRIC IV broadened the list of possible location technologies to be considered with regard to achieving more accurate location. The list of candidate technologies is divided into two main categories: namely, what this document refers to as separate outdoor and indoor location technologies.
Outdoor location technologies are designed to effectively locate target devices whether indoors or outdoors, with varying levels of measured accuracy. These are location technologies that are naturally deployed outside of any structures, and to a significant extent are able to locate devices within some types of structures as well, depending on the surrounding environment. Some of these methods include the following:
Indoor location technologies are designed to effectively locate target devices that are within an indoor environment, usually within a building or structure for which traditional outdoor location methods prove less than optimal, or completely ineffective. These are location technologies that are deployed inside of a structure. Some of these methods include the following:
One technique to getting indoor location in a Wi-Fi or BLE laden environment is to provision each Wi-Fi access point or BLE beacon into a database along with a dispatchable location. If the specific Wi-Fi AP(s) and/or BLE beacon(s) that the mobile "sees" can be identified, then those identifiers can be used in a database query to ask for the provisioned location. This database is referred to by public safety as the National Emergency Address Database (NEAD) in the carrier voluntary agreement [provide reference].
Some challenges to this approach include, getting a complete civic location that is representative of the actual address, maintaining the database in terms of contents, and discovering the database identifier (e.g., MAC address) to query in order to obtain the dispatchable location.
The provided location database would need to contain record identifiers and location data. The record key would be MAC address, either a BSSID for a Wi-Fi access point, or UUID/Major/Minor MAC address for a BLE beacon. The database could also contain actual location data relating to a civic street address, along with additional detail information. Alternatively, it may contain a URI (pointer) to a different database that would contain the actual dispatchable location data.
There are a number of different approaches to determining an indoor location within an enterprise business environment. For emergency calls that can't be adequately located inside a building, there are ways to leverage other location relevant methods to obtain indoor location.
One technique to obtaining indoor location information within an Enterprise context is to utilize the device location capabilities of enterprise wireless local-area network (WLAN) systems where available. The enterprise WLAN device location entities include Wi-Fi Access Points that are surveyed and provisioned ahead of time into a database for later retrieval. This database could be referred to as a Location Information Server (LIS) as described in the Geopriv Architecture document [IETF RFC6280]. The identifier used in the enterprise WLAN location process is the IEEE 802.11 BSSID, otherwise known as Media Access Control (MAC) address of the Wi-Fi Access Point.
The location information that is manually input into a LIS is retrieved based on a query and the MAC adderess referencing the Wi-Fi AP or BLE beacon. This query could be direct from a client or from a proxied query, as in the case above. This location is returned to the querying entity and displayed at the PSAP.
An enterprise WLAN LIS that is queried with the MAC address of the target device via the HELD interface. The WLAN LIS recognizes the identifier of the device as within its management domain and and returns the associated dispatchable location, and optionally, a geo-coordinate location along with a building floor plan showing the target device's position on the map.
A key part of obtaining location from an Enterprise WLAN LIS is to know which LIS to query. For this we use a WLAN LIS discovery approach based on GIS polygons at the 911SSP. The 911SSP already knows which cell site the emergency call came from. In this way, discovery of which enterprise LIS to query could include a polygon-overlay method to identify connected enterprises with WLANs that reside within the same cell-sector as the caller (cell-sector is a known entity by the cellular network at the time of a call).
As PSAPs move toward NG9-1-1, delivery of rich content such as building floor plans is expected. Even during transition, PSAPs that opt for pre-NG9-1-1 mechanisms to display additional location related data can do so through available tools such as a browser display client.
Many single family structures, most notably those that are wood frame construction offer limited obstruction to traditional outside location methods, including A-GPS that is used for current E9-1-1 Phase 2 locations. However, even in moderately restrictive environments A-GPS results may not always provide a very precise fix (i.e., low horizontal uncertainty) with the position information, making the resultant system provided search area considerably more challenging than a more precise fix. Dispatchable location, in this case, is intended to provide the civic street address of the home from which the call is being made from, which affords emergency responders with specific address to go to.
It is possible to get multiple location fixes from different system for the same call. This additional information, including both civic street address and geo position information can be used to provide a higher degree of certainty that the information accurately represents the caller's true location. Each of these location data types may or may not be provided by the same location technology.
Like enterprise solutions that rely on Wi-Fi radio signals to correlate or calculate location results, residential location solutions exist that leverage Wi-Fi signals from one or more access points or beacons within a residence. In the case of a residential Wi-Fi access point, the civic street address of the residence may be able to be provisioned ahead of time in order to provide at call time during an emergency situation. The challenge to using this data is the question of how it can be trusted.
Besides single family residential structures, a more challenging residential environment includes that of a multi-floor, multi-tenant apartment building that may not have consistent deployment of Wi-Fi or Bluetooth beacons, and where A-GPS or other outside location technologies may not be effective.
In order to use a identifier that is designed to get indoor location, it must first become available to the location functions that need to use it within the network. Examples of identifiers include a MAC address of a target mobile device, a BSSID of a Wi-Fi Access Point, or a BLE UUID/Major/Minor identifier. There are several approaches to consider in seeking to obtain an identifier.
Indoor location information is shown as augmenting the existing emergency location data that is delivered during the an emergency call scenario. In this use case, a mobile operator recognizes a caller on their network has dialed 9-1-1 and forwards the call to the designated 9-1-1 system service provider (911SSP). The MAC address of a close by Wi-Fi AP that happens to have it's location already entered into a provisioned location database is discovered [hand waiving here] and delivered to the 911SSP which then initiates a query to the provisioned location database requesting the provisioned dispatchable address.
Information +-----------------+
|(1) |Internet | +---------+
v |Access | | |
+-----------+ |Provider | | Mapping |
| | | (3) | | Service |
| Emergency |<--+-----------------+----------->| |
| Caller | | (2,a) +---------+---+ +---------+
| |<--+------>| | | ^
| | | | | | +-------+ |
+-----------+ | | LIS | | | AP/BLE| |
^ +-------+---------+ | | Data | |
| | | | Store | |
| +-------------+ +-------+ |
| ^ ^ ^ |
| | | (c,e) | (d) |
| (5,a) | v v |
| | +----------------+ |
| | | Augmented | |
| | | Location | |
| | | Server | |
| +---------+-----------+ | |
| | | | | | |
| | | +----------------+ |
| | | ^ | ^ |
| | | |(b,f)| | (g) |
| | v v | | |
| | +------------+ | | |
| (4) | | | | | |
+------------+--->| ESRP |<--+----+------+
| | | | | | (6)
| | +------------+ | |
| | ^ | v
| | (7) | | +----+--+
| (8) | +------------>| |
+------------+----------------------->| PSAP |
| | | |
|Application/ | +----+--+
|Voice |
|Service |
|Provider |
+---------------------+
The diagram shows new interaction between the entities involved in the call in order to get indoor location. There are a number of different deployment models possible, so this document will provide a single example only.
Even through the Application/Voice Service Provider could be the same entity as the Internet Access Provider, this figure shows them as separate boxes. It does however show that the Location Information Server may be deployed within the Internet Access Provider's control, or may be outside of it.
Likewise, the Augmented Location Server - useful for getting Indoor Location information in some morphologies, could also be deployed within the Application/Voice Service Provider, or without. There is no requirement either way. Moreover, we consider but don't show the enterprise or residential scenarios where end systems might act as their own ASP/VSP.
Various interaction scenarios between the entities for emergency call initiation and processing are described in [ref. RFC5012]. The below description highlights only the augmented location interaction:
There are two glaring security issues when locating a caller to emergency services.
There are currently no IANA considerations.
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. |
| [RFC4119] | Peterson, J., "A Presence-based GEOPRIV Location Object Format", RFC 4119, December 2005. |
| [RFC6280] | Barnes, R., Lepinski, M., Cooper, A., Morris, J., Tschofenig, H. and H. Schulzrinne, "An Architecture for Location and Location Privacy in Internet Applications", BCP 160, RFC 6280, July 2011. |
| [RFC5222] | Hardie, T., Newton, A., Schulzrinne, H. and H. Tschofenig, "LoST: A Location-to-Service Translation Protocol", RFC 5222, August 2008. |