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

Most of the current mechanisms for locating a cellular caller after dialing 9-1-1 in the USA are based on 20 year old technology, and which were designed to locate devices in outdoor environments. So it's not surprising to find out that these mechanism do not always perform very well when used to locate an emergency caller from within a building or enclosed environment. The growing trend of mobile device use for requesting emergency services includes more and more emergency calls being made from inside a structure as well as outside. At the same time, some mobile wireless subscribers are removing their legacy wireline phone service from within their homes, and relying solely on their mobile phones for all calls, including those emergency calls. While replacement of wireline phones in exchange for mobile wireless-only connectivity inside the home is not ubitquitous, it is already apparent that as wireless signal coverage indoors improves, an ever increasing number of emergency calls will be initiated from mobile handsets while inside the home.

Emergency services wireless location technology when first deployed, was implemented as either a network-based or handset-based technology. Handset based implementation required special hardware and/or software in the handset. Network based solutions required additional equipment installed in the service provider's Radio Access Network (RAN), but didn’t typically rely on changes to the handset. The methods and protocols used to utilize these technologies were standardized, and for the most part, wholly contained within the control of the mobile operators' networks, and were largely based on standards developed by Telecommunications Industry Association (TIA), 3rd Generation Partnership Program (3GPP), and Open Mobile Alliance (OMA).

Given recent regulatory activities and resultant voluntary carrier-industry agreements around the advancement of indoor location capabilities leveraging new location technologies, there is a need to provide some background as well as a list of assumptions and potential solutions to solve the indoor location challenge. While development of an emergency location architecture and protocols might be the primary focus for North America at the moment, there is also an opportunity to inform a broader (global) audience as to the problem space, since the challenges and benefits are not constrained.

Location information that gets used to dispatch emergency resources to a caller in reporting an emergency, needs to be in the form of a civic street address. Most emergency calls are routed to the appropriate PSAP based on coarse, cell tower location, which is then followed up with a dynamically measured geographic (i.e., "geo") position estimate (referred to in North America as wireless Phase 2 location). This finer grain position information includes lattitude, longitude, horizontal uncertainty (HUNC) and a probability (confidence). Though the estimated position may be within a few meters to several hundred meters of the caller's device, this updated position data is not considered by emergency responders to be good enough for direct dispatch since lat/lon coordinates are meaningless without having the ability to plot the position onto a map, or to associate the postion to a civic street address.

Even if geo position information could be accomodated within the emergency center's dispatch system, it use doesn't solve indoor mobile use. As a mobile caller moves indoors, traditional outdoor measurment methods become more challenging. What public safety entities require is a "dispatchable location" in the form of a civic street address along with additional data elements, such as building number, room, and floor that will allow emergency responders find the caller.

A dispatchable location is intended as a more complete description of the civic address from where the caller's device is initiating an emergency call, often including additional data elements such as building, floor, and room, etc. Dispatchable location specifically introduces the z-axis location (i.e., vertical elevation or altitude) component that may be conveyed as floor number or distance as measured above some referenced plane, such as meters above ground or sea level. Since there are many ways to describe elevation information, it will be important to determine the best use when displaying z-axis information.

Facilitating convergence between new indoor location methods and existing emergency location methods will require architectural changes to existing standards in order to utilize technologies and methods that are outside the traditional wireless operators' controls, but which will still need to be integrated into a wireless emergency E9-1-1 call.

The structure of this document includes terminology, Section 2, followed by a section listing basic assumptions Section 3, an example architecture, Section 13, and security Section 14 and privacy concerns that are involved in obtaining and using indoor location information.

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

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

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



   Information    +-----------------+
       |(1)       |Internet         |            +---------+
       v          |Access           |            |         |
  +-----------+   |Provider         |            | Mapping |
  |           |   | (3)             |            | Service |
  | Emergency |<--+-----------------+----------->|         |
  | Caller    |   | (2,a) +---------+---+        +---------+
  |           |<--+------>|         |   |             ^
  |           |   |       |         |   |  +-------+  |
  +-----------+   |       |     LIS |   |  | AP/BLE|  |
       ^          +-------+---------+   |  | Data  |  |
       |                  |             |  | Store |  |
       |                  +-------------+  +-------+  |
       |                      ^     ^          ^      |
       |                      |     | (c,e)    | (d)  |
       |                (5,a) |     v          v      |
       |                      |  +----------------+   |      
       |                      |  |    Augmented   |   |
       |                      |  |    Location    |   |
       |                      |  |    Server      |   |
       |            +---------+-----------+       |   |
       |            |         |  |        |       |   |
       |            |         |  +----------------+   |
       |            |         |     ^     |    ^      |
       |            |         |     |(b,f)|    | (g)  |
       |            |         v     v     |    |      |
       |            |    +------------+   |    |      |
       |  (4)       |    |            |   |    |      |
       +------------+--->|    ESRP    |<--+----+------+
       |            |    |            |   |    |   (6)
       |            |    +------------+   |    | 
       |            |          ^          |    v
       |            |      (7) |          |  +----+--+
       |    (8)     |          +------------>|       |
       +------------+----------------------->| PSAP  |
                    |                     |  |       |
                    |Application/         |  +----+--+
                    |Voice                |
                    |Service              |
                    |Provider             |
                    +---------------------+

The diagram shows new interaction between the entities involved in the call in order to get indoor location. There are a number of different deployment models possible, so this document will provide a single example only.

Even through the Application/Voice Service Provider could be the same entity as the Internet Access Provider, this figure shows them as separate boxes. It does however show that the Location Information Server may be deployed within the Internet Access Provider's control, or may be outside of it.

Likewise, the Augmented Location Server - useful for getting Indoor Location information in some morphologies, could also be deployed within the Application/Voice Service Provider, or without. There is no requirement either way. Moreover, we consider but don't show the enterprise or residential scenarios where end systems might act as their own ASP/VSP.

Various interaction scenarios between the entities for emergency call initiation and processing are described in [ref. RFC5012]. The below description highlights only the augmented location interaction:

  1. 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.
  2. 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.
  3. 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].
  4. 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.
  5. 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.
  6. 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.
  7. 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

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 US Phone: +1 206 792 2424 EMail: rmarshall@telecomsys.com URI: http://www.telecomsys.com
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