﻿<?xml version="1.0"?>
<?xml-stylesheet type='text/xsl'
  href='rfc2629.xslt' ?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
  <!ENTITY rfc2119 PUBLIC '' 
    'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>  
  <!ENTITY rfc5222 PUBLIC '' 
    'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5222.xml'>
  <!ENTITY rfc6280 PUBLIC '' 
    'http://xml.resource.org/public/rfc/bibxml/reference.RFC.6280.xml'>
    ]>
    
<?rfc toc="yes"?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="no" ?>

<rfc category="std" ipr="trust200902" docName="draft-marshall-ecrit-indoor-location-00">

<front>

<title abbrev="Indoor Location for Emergency">Indoor Location Mechanisms for Emergency Services</title>
    <author initials="R." surname="Marshall" fullname="Roger Marshall" >
      <organization abbrev="TCS">TeleCommunication Systems, Inc.</organization>
      <address>
        <postal>
          <street>2401 Elliott Avenue</street>
          <street>2nd Floor</street>
          <city>Seattle</city>
          <region>WA</region>
          <code>98121</code>
          <country>US</country>
        </postal>
        <phone>+1 206 792 2424</phone>
        <email>rmarshall@telecomsys.com</email>
        <uri>http://www.telecomsys.com</uri>
      </address>
    </author> 
    <author initials="M." surname="Linsner" fullname="Marc Linsner" >
      <organization abbrev="Cisco">Cisco Systems</organization>
      <address>
        <postal>
          <street></street>
          <street></street>
          <city>Marco Island</city>
          <region>FL</region>
          <code>34145</code>
          <country>US</country>
        </postal>
        <phone></phone>
        <email>marc.linsner@cisco.com</email>
        <uri>http://www.cisco.com</uri>
      </address>
    </author>
    <author initials="D." surname="Stanley" fullname="Dorothy Stanley" >
      <organization abbrev="">Aruba Networks</organization>
      <address>
        <postal>
          <street>1322 Crossman Ave</street>
          <city>Sunnyvale</city>
          <region>CA</region>
          <code></code>
          <country>US</country>
        </postal>
        <phone>630-363-1389</phone>
        <email>dstanley@arubanetworks.com</email>
        <uri>http://www.arubanetworks.com</uri>
      </address>
    </author>
    
<date year="2015"/>
<area>RAI</area>
<workgroup>ECRIT</workgroup>
<keyword>Internet-Draft</keyword>
<keyword></keyword>
<keyword>indoor location emergency indoors dispatchable location civic 
address wi-fi wifi ble bluetooth beacon</keyword>

<note title="Abstract">

<t>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.</t>

<t>
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.
</t>
 
<t>
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.
</t>
 
<t>
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.
</t>

</note>

</front>
<middle>

<section title="Introduction">

<t>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.
</t>

<t>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).
</t>

<t>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.
</t>

<t>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.
</t>

<t>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.
</t>

<t>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.
</t>

<t>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.
</t>

<t>The structure of this document includes terminology, 
<xref target="terminology"/>, followed by a section listing basic assumptions 
<xref target="assumptions"/>, an 
example architecture, <xref target="architecture"/>, and security 
<xref target="security"/> and privacy concerns that are involved in obtaining and 
using indoor location information.
</t>

</section>
<section anchor="terminology" title="Terminology">

<t>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 
<xref target="RFC2119">RFC 2119</xref></t>
      
<t>The following terms are defined in this document:</t>

<t><list style="hanging">

<t hangText="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.
</t>

<t hangText="Outdoor Location:"> A type of location that is determined 
representative of a device that is under open sky conditions.
</t>

<t hangText="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.
</t>

<t hangText="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.
</t>

<t hangText="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.
</t>

<t hangText="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.
</t>

<t hangText="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.
</t>

<t hangText="User-plane location:"> Location that is determined using direct data 
interaction techniques between the end device (target) and a location generator.
</t>

<t hangText="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.  
</t>

<t hangText="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.
</t>

<t hangText="Residential location:"> Location information representative of data 
descriptive of a single-family home, multi-tenant apartment or condominium, etc.
</t>

<t hangText="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.
</t>

<t hangText="Dispatch location:"> The location information that is used to 
dispatch emergency responder resources.  This is typically a civic street 
address.
</t>

<t hangText="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.
</t>

<t hangText="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). 
</t>

</list></t>
</section>
<section anchor="assumptions" title="Basic Assumptions for Indoor Location">

<t>A short list of assumptions that help define the need for indoor location is 
listed as follows.</t>

<t><list style="hanging">

<t hangText="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.
</t>

<t hangText="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.
</t>

<t hangText="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.
</t>

<t hangText="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).
</t>

<t hangText="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.
</t>

<t hangText="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.
</t>

<t hangText="A7.  Indoor Location applicability:"> Dispatchable location 
is applicable for mobile CMRS emergency calls initiated from an indoor 
environment.
</t>

<t hangText="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.
</t>

<t hangText="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.
</t>

<t hangText="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.
</t>

</list></t>
</section>
<section anchor="challenges" title="Challenges with location indoors">

<t>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.
</t>

<t>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.
</t>

<t>(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.
</t>

</section>
<section anchor="outdoor" title="Outdoor Location Technologies">

<t>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:</t>

<t><list style="hanging">

<t hangText="A-GPS:"> Assisted Gloal Positioning System</t>
<t hangText="A-GNSS:"> Assisted Global Navigational Satellite System</t>
<t hangText="O-TDOA:"> Observed Time Difference Of Arrival</t>
<t hangText="U-TDOA:"> Observed Time Difference Of Arrival</t>
<t hangText="AFLT:"> Advanced Forward Link Trilateration</t>
<t hangText="TBS:"> Terrestrial Beacon System</t>


</list></t>
</section>
<section anchor="indoor" title="Indoor Location Technologies">

<t>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:
</t>

<t><list style="hanging">

<t hangText="WPS:"> Wi-Fi Positioning System</t>
<t hangText="WLAN APs:"> Wi-Fi Local Area Network Access Points</t>
<t hangText="BLE Beacons:"> Bluetooth Low Energy Beacons</t>
<t hangText="Small Cells:"> Small Cells, possibly including microcells, 
picocells, and femtocells</t>

</list></t>
</section>
<section anchor="environment" title="Type of Location Environment">

<t><list style="hanging">

<t hangText="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.
</t>
<t hangText="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.</t>

</list></t>
</section>
<section anchor="provisioned-database" title="Provisioned Location Database">

<t>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].
</t>

<t>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.
</t>

<t>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.
</t>

</section>
<section anchor="enterprise-provisioned" title="Enterprise Provisioned Indoor Location">

<t>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.</t>

<t>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.
</t>

<t>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.
</t>

</section>
<section anchor="enterprise-measured" title="Enterprise Measured Indoor Location">

<t>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.
</t>

<t>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).</t>

<t>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.
</t>

</section>
<section anchor="residential" title="Indoor Location for Residential">

<t>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.</t>

<t>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.
</t>

<t>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.
</t>

<t>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.</t>

</section>
<section anchor="identifier" title="Obtaining an Identifier">

<t>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.</t>

<t><list style="hanging">

<t hangText="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.
</t>

<t>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:</t>

<t hangText="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 (v2.0.2) protocol, 
support the return of these types of data extensions.
</t>

<t hangText="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.
</t>

</list></t>
</section>
<section anchor="architecture" title="Indoor Location Example Use Case">

<t>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.</t>

<figure>
<artwork>

<![CDATA[
   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             |
                    +---------------------+
]]>
</artwork>
</figure>

<t>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.
</t>

<t>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.
</t>

<t>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.
 </t>

<t>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:</t>

<t><list style='letters'>

<t>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.
</t>

<t>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.
</t>

<t>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].
</t>

<t>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.
</t>

<t>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.</t>

<t>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.</t>

<t>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.</t>

</list></t>
</section>
<section anchor="security" title="Security Considerations">

<t>There are two glaring security issues when locating a caller to emergency services.
</t>

<t><list style='numbers'>

<t>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.
</t>

<t>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.
</t>

</list></t>
</section>
<section anchor="iana" title="IANA Considerations">

<t>There are currently no IANA considerations.</t>
 
</section>

<!-- **************************************************************************************** -->

<section title="Acknowledgements">

<t></t>

</section>

<!-- **************************************************************************************** -->

    <section title="Changes from Previous Versions">
     <section title="Changes from draft-">
        <t>
        <list style="symbols">
            <t></t>
            <t></t>
        </list>
        </t>
      </section>
    </section>

<!-- **************************************************************************************** -->

</middle>
<back>

<references title="Normative References">
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.6280.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.4119.xml"?>
</references>

<references title="Informative References">
&rfc5222;
</references>

</back>
</rfc>
