[Search] [txt|xml|pdfized|bibtex] [Tracker] [Email] [Nits]
Versions: 00                                                            
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


   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

   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

   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

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",
   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

   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

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

   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

   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

   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

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

   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

   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-



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

   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

   Email: marc.linsner@cisco.com
   URI:   http://www.cisco.com

   Dorothy Stanley
   Aruba Networks
   1322 Crossman Ave
   Sunnyvale, CA

   Phone: 630-363-1389
   Email: dstanley@arubanetworks.com
   URI:   http://www.arubanetworks.com

Marshall, et al.        Expires September 2, 2015              [Page 18]