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
Abstract
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.
Status of This Memo
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
Marshall, et al. Expires September 2, 2015 [Page 1]
Internet-Draft Indoor Location for Emergency March 2015
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 Notice
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Basic Assumptions for Indoor Location . . . . . . . . . . . . 6
4. Challenges with location indoors . . . . . . . . . . . . . . 8
5. Outdoor Location Technologies . . . . . . . . . . . . . . . . 8
6. Indoor Location Technologies . . . . . . . . . . . . . . . . 9
7. Type of Location Environment . . . . . . . . . . . . . . . . 9
8. Provisioned Location Database . . . . . . . . . . . . . . . . 10
9. Enterprise Provisioned Indoor Location . . . . . . . . . . . 10
10. Enterprise Measured Indoor Location . . . . . . . . . . . . . 11
11. Indoor Location for Residential . . . . . . . . . . . . . . . 11
12. Obtaining an Identifier . . . . . . . . . . . . . . . . . . . 12
13. Indoor Location Example Use Case . . . . . . . . . . . . . . 13
14. Security Considerations . . . . . . . . . . . . . . . . . . . 16
15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16
17. Changes from Previous Versions . . . . . . . . . . . . . . . 17
17.1. Changes from draft- . . . . . . . . . . . . . . . . . . 17
18. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
18.1. Normative References . . . . . . . . . . . . . . . . . . 17
18.2. Informative References . . . . . . . . . . . . . . . . . 17
Marshall, et al. Expires September 2, 2015 [Page 2]
Internet-Draft Indoor Location for Emergency March 2015
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction
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
Marshall, et al. Expires September 2, 2015 [Page 3]
Internet-Draft Indoor Location for Emergency March 2015
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.
Marshall, et al. Expires September 2, 2015 [Page 4]
Internet-Draft Indoor Location for Emergency March 2015
2. Terminology
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:
Indoor Location: The type of location information indicative of an
end device that is determined from within specific location/
structure, such as within a building.
Outdoor Location: A type of location that is determined
representative of a device that is under open sky conditions.
Dispatchable Location: A form of location, either civic or geo, that
is considered useful for the dispatching of emergency responders
by emergency service personnel. Note: Typically, dispatchable
location is used interchangeably with dispatchable address.
Dispatchable Address: This is a sub-type of dispatchable location in
general, and by example, may be considered to be "dispatchable" if
it is a civic address representing the location of a caller's
mobile phone inside a house, office building, or multi-story
apartment building, etc., as long as the address is sufficiently
descriptive of the apartment, unit, floor, etc., for emergency
response personnel to find the caller.
Dispatchable Position: This is a sub-type of dispatchable location,
and is generally considered less popular for dispatch purposes,
since responders typically require a street address. An outdoor
location technology that provides a position estimate producing a
Lat/Lon coordinate pair, or even 3D Lat/Lon/Alt coordinates, for
example, might not be considered dispatchable by emergency service
personnel, because responders may not have a way of rendering a
geographic position even though the coordinates presented might be
close to the actual position of the caller.
Network-based location: A target location that is determined by the
radio access network and back end systems without requiring any
separate interaction from the end device.
Handset-based location: A target location that is determined using
techniques that interact with the end device (target) that is
being located. That is, the end device plays a part in the
location determination process.
Marshall, et al. Expires September 2, 2015 [Page 5]
Internet-Draft Indoor Location for Emergency March 2015
User-plane location: Location that is determined using direct data
interaction techniques between the end device (target) and a
location generator.
Control-plane location: Location that is determined based on data
interaction between the end device and the access or application
service provider (ASP) location determination equipment through a
managed data connection.
Enterprise location: Location information that is representative of
data produced from within a managed corporate data network.
Examples include an corporate WLAN within an office building,
hotel, warehouse, corporate campus etc.
Residential location: Location information representative of data
descriptive of a single-family home, multi-tenant apartment or
condominium, etc.
Routing location: Location information that is used for the purpose
of performing a location-based routing operation. This is usually
in reference to coarse location, such as a cell tower civic
address or representative lat/lon.
Dispatch location: The location information that is used to dispatch
emergency responder resources. This is typically a civic street
address.
Augmented Location: Location information that is delivered along
with the basic routing and/or dispatch location information. In
the case of delivering indoor location along with the normal
dispatch location, the indoor location information might be
considered augmented location.
Enhanced Location: Location information that is considered to be
finer-grained information than the coarse location used for
routing. This location information is traditionally in the form
of a geographic position estimate in either 2D (Lat/Lon) or 3D
(Lat/Lon/Alt).
3. Basic Assumptions for Indoor Location
A short list of assumptions that help define the need for indoor
location is listed as follows.
A1. Not all wireless calls need indoor location: Many wireless
calls will continue to be initiated outside. For these cases,
existing technologies and processes will continue to be used to
meet present regulatory requirements.
Marshall, et al. Expires September 2, 2015 [Page 6]
Internet-Draft Indoor Location for Emergency March 2015
A2. No single indoor location technology is expected to be optimal
for every environment:
Several indoor location technologies exist, each having its own
particular set of strengths and weaknesses as to its effectivness
in locating a mobile device deep within a building or structure.
A3. Dispatchable location is defined by context: The idea of what
dispatchable location is inside one type of building (e.g., high-
rise apartment building) may be different for a different type of
structure. Also, some emergency response personnel may consider
location information as dispatchable depending on the environment
reported. For example, geo position information would likely be
considered dispatchable by a mountain rescue group or Coast Guard
personnel.
A4. Dispatchable location format: The type of location preferred
for use in dispatching emergency services by a PSAP is of civic
location form (ref. Dispatchable Address). Most PSAPs and
emergency responders are only equipped to handle dispatch
information of the form of civic street address, as compared to a
geo position (e.g., Lat/Lon).
A5. Heightened location components: A geographic position estimate
(geo coordinate set, etc.) that is calculated as having a maximum
horizontal uncertainty (error) of 50 meters or less, and a
vertical uncertainty of 3 meters, as referenced to a specified
standard geographic datum.
A6. Dispatchable location vertical component: Dispatchable location
includes an indication of vertical height or elevation descriptor
if reporting from a significantly elevated position within a
structure or building. For example, dispatching emergency
resources to a location representing a structure more than 2
floors in height is effective only if the floor number is
included. Other units of measurement, such as height above sea
level, the ground, or a specified datum are typically considered
insufficient for the purposes of dispatching responder resources.
A7. Indoor Location applicability: Dispatchable location is
applicable for mobile CMRS emergency calls initiated from an
indoor environment.
A8. Applicability of Indoor Location for SMS text-to-9-1-1: Indoor
location is not currently applicable for use with SMS text-to-
9-1-1, since it is currently not covered by any regulatory or
voluntary industry agreement.
Marshall, et al. Expires September 2, 2015 [Page 7]
Internet-Draft Indoor Location for Emergency March 2015
A9. Z-axis data: The vertical component of dispatchable location
information may include a one or more various representations of
elevation data. These could include floor number or altitude in
meters above a specified geographic datum.
A10. Integration of vertical information: Mapping servers and
protocols (i.e., RFC5222) will need to be changed to support the
ability to perform mapping based on the included z-axis data, both
for call routing and for dispatching responder resources.
4. Challenges with location indoors
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.
5. Outdoor 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
Marshall, et al. Expires September 2, 2015 [Page 8]
Internet-Draft Indoor Location for Emergency March 2015
well, depending on the surrounding environment. Some of these
methods include the following:
A-GPS: Assisted Gloal Positioning System
A-GNSS: Assisted Global Navigational Satellite System
O-TDOA: Observed Time Difference Of Arrival
U-TDOA: Observed Time Difference Of Arrival
AFLT: Advanced Forward Link Trilateration
TBS: Terrestrial Beacon System
6. Indoor Location Technologies
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:
WPS: Wi-Fi Positioning System
WLAN APs: Wi-Fi Local Area Network Access Points
BLE Beacons: Bluetooth Low Energy Beacons
Small Cells: Small Cells, possibly including microcells, picocells,
and femtocells
7. Type of Location Environment
Enterprise Enterprises are typically thought of as organizations
that deploy and manage their own data networks for the use of
their staff, students, and sometimes on behalf of their customers
or visitors. Examples would include corporations, big or small,
college campuses, government entities, etc.
Residential Scenarios that include individually deployed data
services to a person's place of residenc, we think of as
Residential. Examples of this include single-family, multi-family
homes, condominiums, and apartment complexes.
Marshall, et al. Expires September 2, 2015 [Page 9]
Internet-Draft Indoor Location for Emergency March 2015
8. Provisioned Location Database
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.
9. Enterprise Provisioned Indoor Location
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
Marshall, et al. Expires September 2, 2015 [Page 10]
Internet-Draft Indoor Location for Emergency March 2015
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.
10. Enterprise Measured Indoor Location
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.
11. Indoor Location for Residential
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.
Marshall, et al. Expires September 2, 2015 [Page 11]
Internet-Draft Indoor Location for Emergency March 2015
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.
12. Obtaining an Identifier
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.
Provisioned/Associated: If we know the identifier of a mobile
handset, AP, or BLE beacon ahead of time, then it can be mapped to
a mobile directory number. The call processing system then maps
the incoming Mobile Directory Number (MDN) to the stored MAC
address. The MAC address is then used to query the location
generator for location. While this approach may be okay for demo
purposes, it is not feasible for a working system.
Another method for discovery of a device location while indoors is
to gather 'beacon' identifiers the calling device can see and
reference a location database of known 'beacons'. The term
'beacon' in this context includes IEEE 802.11 access points (AP)
and/or a Bluetooth 4.0 Low-Energy Beacon (BLE). The beacon
identifiers gathered by the calling device would include:
Handset Provided In-band: When a handset makes an emergency call, it
is possible to enable the handset to scan and collect all the Wi-
Fi and BLE identifiers that it sees, along with other measurement
data and include those data with the emergency call. This
capability will be more easily integrated into packet based access
networks that use SIP, for example, than for legacy circuit-
switched access networks, which would require significant
standards modification. Some newer standards, such as OMA SUPL
Marshall, et al. Expires September 2, 2015 [Page 12]
Internet-Draft Indoor Location for Emergency March 2015
(v2.0.2) protocol, support the return of these types of data
extensions.
Handset Provided Out-of-band: An application can be installed onto a
handset that can then be invoked from a direct IP connection from
a trusted 911SSP network once the emergency call is initiated.
The handset then scans and collects all the Wi-Fi and BLE
identifiers that it sees, along with other measurement data and
sends those data back to the trusted 911SSP to be matched up to
the ongoing emergency call.
13. Indoor Location Example Use Case
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.
Marshall, et al. Expires September 2, 2015 [Page 13]
Internet-Draft Indoor Location for Emergency March 2015
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.
Marshall, et al. Expires September 2, 2015 [Page 14]
Internet-Draft Indoor Location for Emergency March 2015
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:
a. Coarse Location information might be available to the end host
directly, obtainable via the Internet Access Provider's LIS, or
retrievable by the ESRP during call routing.
b. During call routing, the ESRP may ask the Augmented Location
Server for additional location, namely Indoor Location either
because of call marking, or by some rule, in which case it
queries the Augmented Location Server.
c. The Augmented Location Server discovers the MAC address of the
device currently making an emergency call and maps it to the
device's existing MDN. The MAC address may be obtained through
user plane query techniques as implied here, or via some other
method [ref. section MAC-discovery-TBD].
d. Having obtained the MAC address of the target device, the
Augmented Location Server uses it to perform a location query a
public Wi-Fi Access Point/Bluetooth beacon database. Note:
Enterprise WLAN query for Wi-Fi location not shown.
e. The resulting data returned from the Enterprise WLAN location
server or AP/BLE Data Store can be either of the type of civic
address or geographic position, either in 2D or 3D format. If
the returned information is geographic, it will either return a
measured, surveyed, or estimated coordinate set, including some
indication of error (uncertainty and confidence). If the ALS
returns a civic address, it will be in the form of a PIDF-LO, and
MUST indicate any elevation infomation, such as floor number,
especially important if the actual location where the call is
coming from is a multi-story building.
Marshall, et al. Expires September 2, 2015 [Page 15]
Internet-Draft Indoor Location for Emergency March 2015
f. The ALS then makes this information available to the ESRP either
in by-value or by-reference format, supplying a generated URL if
by-reference.
g. The augmented indoor location gets sent to the PSAP, again by-
value or by-reference. If a URL is provided to the PSAP, the
PSAP will dereference the augmented location information and get
back the indoor location information by-value.
14. Security Considerations
There are two glaring security issues when locating a caller to
emergency services.
1. The privacy of the caller's location data is of the utmost
importance to protect. Hence, any mechanism for the discovery of
the caller's location and the transport of the discovered data
MUST be protected by strong authentication and encryption. Any
method or protocol that is unique to emergency calls that could
be identified by monitoring uncrypted wireless networks MUST NOT
be used.
2. It is the utmost importance to protect the owners of enterprise
WLANs. These networks are the lifeblood of communications within
a business entity. At the same time, enterprises have a strong
desire to protect human life for employees, visitors, and
customers while on enterprise property. Any connection to the
enterprise LIS from the cellular network must utilize strong
encryption and strong authentication. The nature of the
connection is very low traffic, hence it is advised to utilize a
keep-alive method and accounting method with alarming on each so
any failure in the connection can be rectified in a reasonable
timeframe. The privacy of location data must be protected and
only shared with the CMRS provider during an emergency call. In
the US, CMRS providers are constrained by policy to perform
device location queries only during a 9-1-1 call. The location
data must be protected from the discovery method to the PSAP,
requiring both data integrity and data security end-to-end.
15. IANA Considerations
There are currently no IANA considerations.
16. Acknowledgements
Marshall, et al. Expires September 2, 2015 [Page 16]
Internet-Draft Indoor Location for Emergency March 2015
17. Changes from Previous Versions
17.1. Changes from draft-
o
o
18. References
18.1. Normative References
[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.
18.2. Informative References
[RFC5222] Hardie, T., Newton, A., Schulzrinne, H., and H.
Tschofenig, "LoST: A Location-to-Service Translation
Protocol", RFC 5222, August 2008.
Authors' Addresses
Roger Marshall
TeleCommunication Systems, Inc.
2401 Elliott Avenue
2nd Floor
Seattle, WA 98121
US
Phone: +1 206 792 2424
Email: rmarshall@telecomsys.com
URI: http://www.telecomsys.com
Marshall, et al. Expires September 2, 2015 [Page 17]
Internet-Draft Indoor Location for Emergency March 2015
Marc Linsner
Cisco Systems
Marco Island, FL 34145
US
Email: marc.linsner@cisco.com
URI: http://www.cisco.com
Dorothy Stanley
Aruba Networks
1322 Crossman Ave
Sunnyvale, CA
US
Phone: 630-363-1389
Email: dstanley@arubanetworks.com
URI: http://www.arubanetworks.com
Marshall, et al. Expires September 2, 2015 [Page 18]