Skip to main content

Emergency 911 Services over Wi-Fi

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Active".
Authors Sri Gundavelli , Mark Grayson
Last updated 2023-03-13
RFC stream (None)
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
DISPATCH                                                   S. Gundavelli
Internet-Draft                                                M. Grayson
Intended status: Standards Track                                   Cisco
Expires: 14 September 2023                                 13 March 2023

                   Emergency 911 Services over Wi-Fi


   Proposed is an approach for supporting emergency 911 services over
   IEEE 802.11 based Wi-Fi access networks.  This approach leverages the
   legal framework and the building blocks of the OpenRoaming federation
   for extending emergency 911 calling support to already deployed tens
   of thousands of OpenRoaming Wi-Fi hotspots.  The proposal addresses
   the key issues in emergency calling, around discovery and
   authentication to access network supporting emergency services,
   emergency access credentials, location determination of the emergency
   caller, and delivering emergency voice service configuration to the
   device and call routing.

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

   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 14 September 2023.

Copyright Notice

   Copyright (c) 2023 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 (
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights

Gundavelli & Grayson    Expires 14 September 2023               [Page 1]
Internet-Draft           Emergency 911 Services               March 2023

   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Conventions and Terminology . . . . . . . . . . . . . . . . .   3
     2.1.  Conventions . . . . . . . . . . . . . . . . . . . . . . .   3
     2.2.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Overview  . . . . . . . . . . . . . . . . . . . . . . . . . .   4
   4.  Key Service Requirements  . . . . . . . . . . . . . . . . . .   7
   5.  Access Network Location . . . . . . . . . . . . . . . . . . .   7
   6.  WLAN Network Identification and Selection . . . . . . . . . .   8
   7.  Legal and Regulatory Requirements . . . . . . . . . . . . . .   8
   8.  Authentication on the emergency RCOI WLAN . . . . . . . . . .   9
   9.  Authentication using the realm . . . .   9
   10. Emergency CSCF operation for end-users using
  credentials  . . . . . . . . . . .   9
   11. Emergency calling by OpenRoaming subscribers on MNOs  . . . .  10
   12. Call Flows  . . . . . . . . . . . . . . . . . . . . . . . . .  10
   13. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  14
   14. Security Considerations . . . . . . . . . . . . . . . . . . .  14
   15. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  14
   16. References  . . . . . . . . . . . . . . . . . . . . . . . . .  14
     16.1.  Normative References . . . . . . . . . . . . . . . . . .  14
     16.2.  Informative References . . . . . . . . . . . . . . . . .  15
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  15

1.  Introduction

   The Federal Communications Commission's (FCC) Communications
   Security, Reliability, and Interoperability Council (CSRIC) is
   drafting a report to Congress regarding use of Wi-Fi technology to
   access emergency 911 services when there is no mobile coverage.  The
   report will likely detail non-proprietary standards that can support
   911 services over IEEE 802.11 based Wi-Fi access technology.
   Additional commentary suggests that legal and regulatory changes may
   be needed to address liability, privacy, and security concerns
   associated with providing public access to 911 over Wi-Fi.

   The study looked at the technical feasibility and cost of:

Gundavelli & Grayson    Expires 14 September 2023               [Page 2]
Internet-Draft           Emergency 911 Services               March 2023

   *  making telecommunications service provider-owned Wi-Fi access
      points, and other communications technologies operating on
      unlicensed spectrum, available to the general public for access to
      9-1-1 services, without requiring any login credentials, during
      times of emergency when mobile service is unavailable;

   *  the provision by non-telecommunications service provider-owned Wi-
      Fi access points of public access to 9-1-1 services during times
      of emergency when mobile service is unavailable; and

   *  ther alternative means of providing the public with access to
      9-1-1 services during times of emergency when mobile service is

   We have reviewed these requirements and proposed an approach
   leveraging the OpenRoaming federation of Wi-Fi access providers and
   Identity Providers for supporting emergency 911 services over
   unlicensed Wi-Fi access.

2.  Conventions and Terminology

2.1.  Conventions

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in RFC 2119 [RFC2119].

2.2.  Terminology

   All the mobility terms used in this document are to be interpreted as
   defined in the IETF and 3GPP specifications.  For convenience, the
   definitions for some of the terms are provided below.

   Subscription Permanent Identifier (SUPI))

      A globally unique 5G Subscription Permanent Identifier (SUPI) is
      allocated to each subscriber in the 5G System.  The SUPI value is
      provisioned in USIM and UDM/UDR function in 5G Core.  The
      structure of SUPI and its privacy is specified [TS23501]

   OpenRoaming (OR)

      A federation that provides the framework for connecting
      unprecedented footprint of millions of Wi-Fi hotspots with
      identity providers.

   Identity Provider (IDP)

Gundavelli & Grayson    Expires 14 September 2023               [Page 3]
Internet-Draft           Emergency 911 Services               March 2023

      An entity that manages identity credentials and policies for
      devices and provides authentications services.

   Access Network Provider (ANP)

      An entity providing internet connectivity services.

   Passpoint Profile

      Passpoint is a Wi-Fi Alliance (WFA) protocol that enables mobile
      devices to discover and authenticate to Wi-Fi hotspots that
      provide internet access.  Profile includes the user's credentials
      and the access network identifiers.

   Roaming Consortium Identifier (RCOI)

      It is a 3-octet, or a 5-octet value carried in the 802.11 beacon
      information element (IE).  It is also sent in the ANQP messages.
      RCOI identifies the groups or identity providers that are
      supported by the network.

   Connectivity Location Function (CLF)

      It maintains mappings between the endpoint's dynamically assigned
      IP address and its physical location.  An enhanced CLF maintains
      the mapping between the devices' access point identifier (BSSID)
      and the physical location.

   Public Safety Answering Point (PSAP)

      A PSAP is a facility where emergency calls are received under the
      responsibility of a public authority.

   Route Determination Function (RDF)

      It resolves a physical location, either a civic address or a geo-
      spatial address to the serving PSAP.


      Enhanced Call Session Control Function.  It takes the requests
      from P-CSCF (Proxy CSCF) and routes the emergency sessions to the
      PSAP based on CLF and RDF queries.

3.  Overview

   Following are the key aspects in this approach:

Gundavelli & Grayson    Expires 14 September 2023               [Page 4]
Internet-Draft           Emergency 911 Services               March 2023

              | IDP:      |
              |    +---+              +------+   |
              |    |CLF|--------------|E-CSCF|   |
              |    +---+  CLF Query   +------+   |
              |      |   for Location    |       |----><PSAP>
              |    +---+              +------+   |
              |    |AAA|              |P-CSCF|   |
              |    +---+              +------+   |
                     .        :          .
                    /|\       :         /|\
                     |        :          |
          _----_     |        :          |
        _( Open )_   |        :          |
   ----( Roaming )............:          |
        (_      _)   |        :          |
          '----'     |        :          |
                     |     _-----_       |
                     |   _(       )_     | P-Access-Network-Info
       RADIUS        |   (  Access )-    | SIP Header (RFC 3455)
     Attributes      |   -(_Network)-    | and RFC 7315 Defined
   (BSSID, Civic-Loc |     '-----'       | 3GPP Header for carrying
         SLT)        |        |          | BSSID and/or SLT
                     |        |          |
                    \|/       |          |
                     .      +----+       |
                            | AP |       |
                            +----+       |
                              :          |
                              :         \|/
                          | Device |

                      Figure 1: Technical Architecture

   There will be a designated Identity Provider (IDP) and designated
   emergency calling services for supporting emergency 911 service.  The
   AAA server in the IDP supports the realm ""
   and the policies for E-911-RCOI (i.e., an E911-specific HotSpot2.0
   Roaming Consortium or RCOI).  There will also be dedicated P/E-CSCF
   (Proxy/Emergency Call Services Control Function) for supporting
   emergency calling services.  DNS servers for the realm will be
   configured to enable ANPs to dynamically discover the designated
   IDP's AAA servers.

Gundavelli & Grayson    Expires 14 September 2023               [Page 5]
Internet-Draft           Emergency 911 Services               March 2023

   The devices are pre-configured with a HotSpot2.0/Passpoint profile,
   which includes the emergency RCOI (E-911-RCOI), and a common
   identity, e.g.,  Device eco-systems
   vendors can pre-configure this profile into every device at the time
   of manufacturing or push an updated profile using established
   carrier-bundle based provisioning.  This anonymous profile will be
   common for all devices.  This allows the device to discover Wi-Fi
   access networks that support emergency 911 services.  Furthermore,
   the SIP User Agent in the mobile device will be able to use P/E-CSCF
   configuration obtained from the Wi-Fi access network.

   Wi-Fi access networks that are part of the OpenRoaming federation and
   willing to support emergency 911 services will configure the
   emergency RCOI on their WLAN equipment.  WLAN OEM suppliers can
   augment existing OpenRoaming provisioning interfaces with emergency
   RCOI settings.  These networks allow any devices without access
   credentials to connect to the network for emergency calling.  The Wi-
   Fi access network will recover the realm from the identity and use
   DNS system to discover the designated IDP's AAA servers.

   OpenRoaming already requires access networks to provide their Civic
   Location and/or Geo-spatial coordinates in the IDP signaling
   messages.  The location information may be manually configured or can
   be obtained from a reliable source.  The device will also be able to
   discover emergency voice services (CSCF) and the related
   configuration from the access network or from a cloud entity.  This
   allows device to be able to use the emergency e911 services when
   connected to access networks that are not part of the OpenRoaming
   federation.  NOTE that this assumes that the device has basic
   internet connectivity and can initiate emergency calls without
   requiring emergency calling support from the access network.  The
   device can include location elements, obtained either from the access
   network or from a cloud function, and include them in the SIP
   signaling using the Geolocation header fields defined in RFC 6442.
   The E-CSCF function will retrieve the location elements from the
   signaling messages from the device.

   For supporting the architecture based on this approach, we need the
   following updates to the WBA OpenRoaming architecture.  Cisco has
   discussed such change request with WBA that includes:

   *  enhancement to WBA OpenRoaming technical framework to include use
      of emergency RCOI.

   *  enhancements to OpenRoaming templated legal terms for access
      network providers on use of emergency RCOI and associated
      requirements, e.g., related to use of existing defined RFC 5580
      location attributes.

Gundavelli & Grayson    Expires 14 September 2023               [Page 6]
Internet-Draft           Emergency 911 Services               March 2023

   *  updates to WBA WRIX offered-service VSA to include new string for
      "openroaming-emergency" service definition.

   *  definition of policies required to be enforced by ANP when filter-
      id attribute mirrors the "openroaming-emergency" tag.

4.  Key Service Requirements

   Emergency service considerations for supporting this emergency 911

   An emergency call handling service shall be designated to handle Wi-
   Fi-enabled 9-1-1 calls, along with an IDP function for the realm
   e.g., "", where an existing MNO cannot (non-
   provisioned device or MNO core is unavailable).  This should consider
   third-party providers such as IDPaaS/MNO/Voice Service Providers to
   host these services.

   Broadband service providers and HotSpot venue operators shall provide
   the Civic-Location and or the Geo-spatial coordinates of the venue,
   and the emergency voice service configuration to the device in the IP
   address configuration procedures.

   Consumer devices should be pre-configured by OEMs or through
   established carrier-bundle based provisioning with a HotSpot2.0/
   Passpoint profile, including the emergency RCOI (E-911-RCOI) and a
   common identity such as "".

5.  Access Network Location

   Location of the caller is a key element in the emergency-service
   workflow.  Emergency response centers must be able to determine the
   location of the caller before service is dispatched.  A caller may be
   too young, frightened or confused to provide the location of
   emergency, therefore automatic location determination by PSAP is an
   essential requirement.

   The device making the emergency call must be able to obtain the Civic
   and/or Geo-spatial coordinates for inclusion in SIP Registration
   messages.  Reliance on GPS is not an option for most indoor

   The WLANs supporting emergency 911 services should be capable of
   providing the Civic Location or the Geo-Spatial coordinates of the
   caller, or of the access point.  An OpenRoaming access point must be
   manually configured with the Civic and/or the Geo-Spatial coordinates
   or able to derive location through other means.  For example, an
   access point operating in 6 GHz Standard Power mode is required to

Gundavelli & Grayson    Expires 14 September 2023               [Page 7]
Internet-Draft           Emergency 911 Services               March 2023

   include its geo-location in the spectrum grant requests sent to the
   AFC.  In some environments, the access point can learn the location
   information from a connected ethernet switch, or from a broadband
   service provider network.  Furthermore, any access points supporting
   indoor localization services will be able to meet the location

   It is proposed to re-use the definition of location signaling in
   OpenRoaming, enabling the access point to provide the Civic address
   and/or the Geo-spatial coordinates of the device or of the access
   point to the IDP for CLF population.  A confidence-level indicator is
   also optionally included in the reported location-data, based on RFC
   7459 considerations.  This parameter is indicative of the
   uncertainity and the confidence level of the reported location.

6.  WLAN Network Identification and Selection

   The OpenRoaming federation makes extensive use of Passpoint specified
   Roaming Consortium Organization Identifiers (RCOIs) for defining
   polices that are supported by particular access network providers
   (ANPs) and those policies supported by individual identity providers
   (IDPs).  The supported RCOIs are provisioned in WLAN equipment by the
   ANPs and configured in the Passpoint profile of devices managed by
   IDPs.  Only when there is a match of RCOIs between WLAN and Passpoint
   profile will an authentication exchange be triggered.  It is proposed
   to define the use of an emergency-RCOI for use in the systems to
   support E911 only service.

7.  Legal and Regulatory Requirements

   The OpenRoaming federation has a foundation in a legal framework,
   whereby the Wireless Broadband Alliance (WBA) as the federation's
   policy authority is responsible for defining the framework under
   which the federation operates.  WBA defines the privacy policy that
   providers are required to comply with as well as end-user terms and
   conditions.  In addition, WBA defines the legal templated terms that
   are used between OpenRoaming brokers and OpenRoaming providers,
   defining immutable terms that all OpenRoaming providers need to agree
   to.  Finally, WBA agrees legal terms directly with OpenRoaming
   brokers, including terms that require OpenRoaming brokers to use the
   WBA templated terms in their agreements with providers.  It is
   proposed that these legal agreements be amended with terms that cover
   operation of E911 service and allow provisions to indemnify ANPs
   against any liabilities resulting from e911 call failures.

Gundavelli & Grayson    Expires 14 September 2023               [Page 8]
Internet-Draft           Emergency 911 Services               March 2023

8.  Authentication on the emergency RCOI WLAN

   The requirements include being able to support emergency calls for
   users without valid credentials to fully authenticate to the WLAN, in
   this case a credential that has been issued by a specific OpenRoaming
   IDP designated to support users without a full credential. 3GPP has
   defined an approach that uses a 3GPP defined vendor specific EAP
   method called EAP-3GPP-LimitedService for supporting devices without
   credentials.  However, this vendor specific EAP method is not widely
   supported.  Instead, this use-case leverages the well supported EAP-
   TTLS method with a common set of credentials used by all users
   wanting to access on the emergency-RCOI WLAN.  The EAP-Identity shall
   be specified as with common
   credentials being used in the inner method.

9.  Authentication using the realm

   OpenRoaming dynamically discovers the signaling peers used to
   authenticate end-users using DNS.  The same approaches are re-used by
   ANPs to discover the signaling systems used to support the EAP-server
   for the realm.  The EAP-server will use the
   common credentials to authenticate users without valid OpenRoaming
   credentials onto the WLAN.  OpenRoaming defines the RADIUS messages
   exchanged between ANP and IDP.  These include the "offered-service"
   vendor specific attribute as well as RFC 5580 defined location
   attributes.  It is proposed to define a new value for the offered
   service, e.g., "openroaming-emergency" to unambiguously indicate that
   the authentication has come from a WLAN configured with the emergency

10.  Emergency CSCF operation for end-users using

   Whereas 3GPP defines the E-CSCF as always operating in the access
   network, in this use-case the E-CSCF is a common function that can be
   leveraged by all OpenRoaming ANPs that have configured the emergency-
   RCOI.  This means that the E-CSCF isn't coupled to the access network
   by which it can recover network provided location information.
   Instead, in this use-case we leverage the existing OpenRoaming
   specifications that define the signaling of civic and geo-spatial
   location in the RADIUS exchange between ANP and IDP.  Unlike in
   cellular networks, users on WLAN systems will frequently be allocated
   private IP addresses.  This IP address information can be included in
   the RADIUS exchange between ANP and IDP, but because it will
   frequently represent a private address, it cannot be used to uniquely
   identify a user.  Instead, it is proposed to enhance the Connectivity
   Location Function (CLF) to allow querying based on Basic Service Set
   ID (BSSID) which represents the MAC address of the WLAN radio

Gundavelli & Grayson    Expires 14 September 2023               [Page 9]
Internet-Draft           Emergency 911 Services               March 2023

   interface that is serving a user, and optionally a Secure Location
   Tag (SLT) which the WLAN system will deliver it to the device.  The
   BSSID and/or the SLT will be included in the P-ANI SIP header sent by
   the device as well as being included in the ANP to IDP RADIUS
   signaling.  It's proposed that the definition of the IDP hosting the realm includes support for enhanced CLF
   capability that enables the IDP to be queried by an E-CSCF based on
   BSSID and/or SLT.  The IDP can then match the BSSID and/or SLT with
   that received in RADIUS messages originated from individual ANPs and
   return the corresponding location information to the E-CSCF.

11.  Emergency calling by OpenRoaming subscribers on MNOs

   End users who have been provisioned with a full OpenRoaming profile
   will successfully authenticate onto the OpenRoaming ANP using their
   standard profile and standard OpenRoaming RCOI.  As an OpenRoaming
   IDP, the MNO is able to similarly match the civic-location and/or
   geospatial location of authentication requests with the BSSID and/or
   the SLT signaled by the ANP.  The MNO operating the CSCF is able to
   recover the BSSID and/or the SLT from the P-ANI header and determine
   the location of their own users.

12.  Call Flows

  +---+      +---+       +----+      +---+      +---+     +----+  +----+
  |Dev|      |AP |       |DHCP|      |DNS|      |AAA|     |P/E |  |PSAP|
  +---+      +---+       +----+      +---+      +---+     |CSCF|  +----+
    |          |           |           |          |       +----+     |
    |          |           |           |          |         |        |
   <1>        <2>          |           |         <3>        |        |
    |          |           |           |          |         |        |
    |<---<4>-->|           |           |          |         |        |
    |<---<5>-->|           |           |          |         |        |
    |<---<6>-->|           |           |          |         |        |
    |          |<----------<7>-------->|          |         |        |
    |          |<----------<8>------------------->|         |        |
    |          |           <9>         |          |         |        |
    |<-----------<10>------|           |          |         |        |
    |          |           |           |          |         |        |
    |         <11>         |           |         <12>       |        |
    |          |           |           |          |         |        |
    |---<13>-->|----------------<14>------------->|         |        |
    |<--------------------------<15>------------->|         |        |
    |<---------|<---------------<16>--------------|         |        |
    |<---<17>->|           |           |          |         |        |
    |          |           |           |         <18>       |        |

Gundavelli & Grayson    Expires 14 September 2023              [Page 10]
Internet-Draft           Emergency 911 Services               March 2023

    |<--------------------------<19>--------------|-------->|        |
    |          |           |           |          |<--<20>--|        |
    |          |           |           |          |        <21>      |

1. Passpoint Profile with Emergency-RCOI,
2. Advertises E-RCOI on that BSSID, Civic & Geo-Location Attributes
   configured on the AP.
3. IDP & Voice Services for Emergency Calling. Possibly managed by FCC
   or WBA. Manages policies for E-RCOI\nand "" identities.
4. 802.11u with RCOI in Beacon IE
5. Attach to SSID matching the E-RCOI
6. Authentication Exchange (No credential validation)
7. Realm Lookup ( / IDP Discovery
8. TLS Tunnel Setup, Authentication ID federated issued certs
9. Generates location tag (SLT) based\non device indoor positioning, or
   location configuration of the AP
10. Delivery of SLT from AN over ANQP/AssocResp/DHCP/IPv6 ND
11. BSSID + SLT (optional) +  Location Attributes sent to IDP in the
    below RADIUS message exchange
12. E-CSCF FQDN and Emergency\nCalling numbers sent to AN in the below
    RADIUS message exchange
13. EAP-ID/Resp / 802.1x
14. EAP over RADUIUS (TLS)
15. EAP-TTLS with well-known credentials
16. EAP-Success
17. Delivers IMS Configuration over 802.11, DHCP, or IPv6 ND
18. Updates the local CLF to include BSSID and/or SLT to Location
19. SIP UA Registration includes BSSID and SLT (optional) in the P-ANI
20. CLF Query for Location Check using BSSID and/or SLT
21. Determination of PSAP based on query to RDF
22. Emergency Call Routed to PSAP with location

         Figure 2: Emergency e911 Services over Wi-Fi Access

   Following is some additional text explaining above interactions.

Gundavelli & Grayson    Expires 14 September 2023              [Page 11]
Internet-Draft           Emergency 911 Services               March 2023

   *  The device is pre-configured with the emergency passpoint profile,
      which includes the emergency RCOI, and a common identity,
      "".  This allows the device to discover
      access networks that support emergency 911 services.

   *  An 802.11 access network supporting EAP-based authentication
      method and is part of the OpenRoaming federation is either
      configured with the Civic-Location and/or the Geo Spatial
      coordinates of the access point or has the ability to derive
      location coordinates through other means.

   *  The access network for supporting emergency 911 services will
      advertise the emergency RCOI in the 802.11 Beacon messages, and
      furthermore will respond to any ANQP queries on the supported

   *  A device that is in coverage of a WLAN but without any valid
      conventional access-network credentials may use the UI interaction
      to trigger the selection of the profile containing the emergency
      RCOI.  The end user's selection of an emergency calling
      application, or interaction with the default phone application
      (e.g., by selecting the emergency call option in the UI or by
      dialing an emergency phone number) may trigger the selection of
      the Passport profile with the emergency RCOI, resulting in the
      device performing a network-attach for emergency-call access.

   *  The device will use the default identity, ""
      from passpoint profile in the initial authentication message
      exchange, allowing the access network to discover the AAA server /
      IDP for EAP authentication.

   *  The access network using the realm portion of the identity,
      "" will perform a DNS lookup the AAA server for the
      IDP supporting the emergency RCOI and the realm.

   *  The access network and the AAA server will establish a secure TLS
      tunnel for securing the 802.1x/EAP traffic between the device and
      the IDP.  The authentication of the peers will be based on the
      OpenRoaming federation issued X.509 certificates.

   *  The device will complete the EAP authentication using the common
      credentials from the emergency passpoint profile.  The 802.1x/EAP
      messages are tunneled as RADIUS messages between the access point
      and the AAA server.

   *  The access point will generate secure location tag (SLT) for the
      device.  The SLT will be delivered to the device over one of the
      protocols (ANQP/802.11/DHCP/IPv6 ND).  SLT is a tag representative

Gundavelli & Grayson    Expires 14 September 2023              [Page 12]
Internet-Draft           Emergency 911 Services               March 2023

      of the device' location.  In another variation, SLT can be a
      composite object composed of a signed location by the access
      network or a cloud function, along with the identifiers of the
      signing entity.  Functions such as E-CSCF will be able to verify
      the location by verifying the signature of the signing entity.

   *  The access point includes the BSSID of the access point in the
      Calling-Station-Id attribute (RFC 2865) and/or the SLT in a new
      attribute to be defined.

   *  The access point will also include the attributes for carrying the
      Civic Location and/or the Geo-Spatial coordinates of the access
      point (RFC 5580).

   *  The AAA server will send the IMS configuration (E-CSCF FQDN)
      supporting emergency call routing services to the access point.

   *  A success EAP transaction between the device and the AAA server
      will result in the AAA server sending EAP-SUCCESS to the device.

   *  The AAA server will update the local CLF function with the
      location of the access point, using BSSID and/or the SLT as
      location identifiers.

   *  The access point delivers the IMS configuration to the client over
      one of the interfaces (802.11/ANQP/DHCP/IPv6 ND).  ANP will apply
      policies which limits the usage of the network over emergency RCOI
      only for emergency calling.  Furthermore, the ANP will apply QoS
      policies on the emergency session for ensuring the call meets the
      SLA defined for the emergency service.  ANP will prioritize
      traffic and sessions on emergency RCOI over other RCOIs.

   *  The IMS client in the device performs registration with the
      emergency IMS system.  The UA inserts the P-Access-Network-Info
      header field in the SIP message using the 3GPP 24.229 defined
      fields.  It contains the BSSID of the access point (access-
      type="IEEE-802.11", wlan-node-id="BSSID", and optionally a secure-
      location-tag=SLT).  A new parameter, "secure-location-tag" will be

   *  The E-CSCF function uses the BSSID and/or the SLT from the P-ANI
      header for determination of the device's location.  It queries the
      CLF for retrieving the Civic and/or the Geo-spatial coordinates of
      the access point.  The E-CSCF function may query the RDF function
      for the PSAP destination address.

   *  The E-CSCF will route the emergency call to the nearest PSAP.

Gundavelli & Grayson    Expires 14 September 2023              [Page 13]
Internet-Draft           Emergency 911 Services               March 2023

13.  IANA Considerations

   This document does not requires any IANA actions.

14.  Security Considerations

   network access identifier [RFC7542]

   A rogue user or a compromised device may potentially trigger a volume
   of emergency calls, including calls spoofing the caller's real
   location.  The value set for the field, "i-wlan-node-id" in the PANI
   header can potentially be a false BSSID which maps to a different
   location in the CLF database.

   In this use-case, we eliminate this threat with the use of SLT
   (Secure Location Tag) that the network will generate dynamically and
   will provide it to the device for inclusion in emergency call

   A trusted OpenRoaming access network signals the same location tag
   along with the civic and/or geo-spatial coordinates to the IDP.  The
   CSCF function will retrieve the SLT from the call signaling from the
   device and will look up the civic location and/or geo-spatial
   coordinates of the device by querying the CLF database populated by
   the IDP.  SLT serves as an index to the real-location and the
   generated tag is valid for a short duration, thereby eliminating any
   replay attacks.

   A rogue user or a compromised device may also initiate a volume of
   emergency calls, including a valid caller's location.  This threat is
   not a new threat and exists even in today's emergency services
   supported over wireline and cellular architectures.

15.  Acknowledgements

   We had many discussions with the members of FCC CSRIC 8 WG and that
   feedback greatly us greatly in developing this proposal.

16.  References

16.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,

Gundavelli & Grayson    Expires 14 September 2023              [Page 14]
Internet-Draft           Emergency 911 Services               March 2023

   [RFC7542]  DeKok, A., "The Network Access Identifier", RFC 7542,
              DOI 10.17487/RFC7542, May 2015,

16.2.  Informative References

   [TS23501]  23.501, 3. T., "Numbering, addressing and identification",

Authors' Addresses

   Sri Gundavelli
   170 West Tasman Drive
   San Jose, CA 95134
   United States of America

   Mark Grayson
   11 New Square Park
   Bedfont Lakes
   United Kingdom

Gundavelli & Grayson    Expires 14 September 2023              [Page 15]