Skip to main content

Emergency Communication Services over Wi-Fi Access Networks

Document Type Active Internet-Draft (individual)
Authors Sri Gundavelli , Mark Grayson
Last updated 2024-01-11
RFC stream (None)
Intended RFC status (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 July 2024                                    11 January 2024

      Emergency Communication Services over Wi-Fi Access Networks


   This document introduces an approach to enable emergency services
   over Wi-Fi access networks.  These services encompass emergency
   services such as 911 in North America, 112 in the European Union, and
   equivalent emergency services in other regulatory domains.  The
   proposed approach aims to provide a comprehensive solution for
   supporting emergency communication across different regions and
   regulatory frameworks.

   Leveraging the legal framework and infrastructure of the OpenRoaming
   federation, this proposal aims to extend emergency calling
   capabilities to the vast number of OpenRoaming Wi-Fi hotspots that
   have already been deployed.

   The approach addresses critical challenges related to emergency
   calling, including discovery and authentication procedures for
   accessing networks that support emergency services, emergency access
   credentials, the configuration of emergency voice services, accurate
   location determination of the emergency caller, and call spofing.

   By providing a comprehensive solution, this proposal ensures that
   emergency communication services can be seamlessly and effectively
   supported within the IEEE 802.11-based Wi-Fi ecosystem leveraging
   Passpoint Profiles.

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

Gundavelli & Grayson      Expires 14 July 2024                  [Page 1]
Internet-Draft      Emergency Communication Services        January 2024

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

Copyright Notice

   Copyright (c) 2024 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
   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  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Conventions and Terminology . . . . . . . . . . . . . . . . .   4
     2.1.  Conventions . . . . . . . . . . . . . . . . . . . . . . .   4
     2.2.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Emergency Service Architectures - Current Art . . . . . . . .   5
     3.1.  IETF Protocol Support . . . . . . . . . . . . . . . . . .   5
     3.2.  NG911 and NG112 Emergency Systems . . . . . . . . . . . .   6
     3.3.  3GPP Emergency Service Architecture . . . . . . . . . . .   7
   4.  Proposed Approach . . . . . . . . . . . . . . . . . . . . . .   8
     4.1.  Scenario Description  . . . . . . . . . . . . . . . . . .   8
     4.2.  Technical Architecture  . . . . . . . . . . . . . . . . .   9
   5.  Key Service Requirements  . . . . . . . . . . . . . . . . . .  11
   6.  Access Network Location . . . . . . . . . . . . . . . . . . .  12
   7.  WLAN Network Identification and Selection . . . . . . . . . .  12
   8.  Legal and Regulatory Requirements . . . . . . . . . . . . . .  13
   9.  Authentication on the emergency RCOI WLAN . . . . . . . . . .  13
   10. Authentication using the realm . . . .  13
   11. Emergency CSCF operation for end-users using
  credentials  . . . . . . . . . . .  14
   12. Emergency calling by OpenRoaming subscribers on MNOs  . . . .  14
   13. Call Flows  . . . . . . . . . . . . . . . . . . . . . . . . .  14
   14. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  18
   15. Security Considerations . . . . . . . . . . . . . . . . . . .  19
   16. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  19
   17. References  . . . . . . . . . . . . . . . . . . . . . . . . .  19

Gundavelli & Grayson      Expires 14 July 2024                  [Page 2]
Internet-Draft      Emergency Communication Services        January 2024

     17.1.  Normative References . . . . . . . . . . . . . . . . . .  19
     17.2.  Informative References . . . . . . . . . . . . . . . . .  20
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  21

1.  Introduction

   The Federal Communications Commission's (FCC) Communications
   Security, Reliability, and Interoperability Council (CSRIC) have
   completed a report that is currently under FCC review.  The report
   focuses on the utilization of Wi-Fi technology for accessing
   emergency 911 services in areas without mobile coverage.  It provides
   an overview of non-proprietary standards capable of facilitating 911
   services over Wi-Fi networks based on the IEEE 802.11 technology.
   Additionally, the report highlights the potential need for legal and
   regulatory adjustments to address concerns related to liability,
   privacy, and security when enabling public access to 911 services via

   The study looked at the technical feasibility and cost of:

   *  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

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

   These initiatives showcase the dedication of regulatory entities to
   enhance access to emergency services through Wi-Fi-based networks.
   It is important to note that these efforts are not limited to any one
   specific regulatory domain but represent a widespread trend.

   This document introduces an approach that aligns with ongoing efforts
   to enhance emergency communication services over unlicensed Wi-Fi
   access networks.  It proposes utilizing the OpenRoaming federation
   [I-D.tomas-openroaming] of Wi-Fi access providers and Identity
   Providers to facilitate the provision of emergency services.

Gundavelli & Grayson      Expires 14 July 2024                  [Page 3]
Internet-Draft      Emergency Communication Services        January 2024

   By leveraging a pre-configured emergency passpoint profile, any Wi-
   Fi-enabled device situated within the coverage area of an OpenRoaming
   hotspot that supports emergency services will have the capability to
   access the available emergency communication services provided in
   that region.

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

   OpenRoaming (OR)

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

   Identity Provider (IDP)

      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.

Gundavelli & Grayson      Expires 14 July 2024                  [Page 4]
Internet-Draft      Emergency Communication Services        January 2024

   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.


      Proxy Call Session Control Function.  P-CSCF is a specific 3GPP
      function ([TS23501]) defined in their IMS architecture.  It
      largely a 3GPP variant of the IETF SIP Proxy function [RFC3261].


      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.  Emergency Service Architectures - Current Art

3.1.  IETF Protocol Support

   The IETF has made significant contributions to the development of
   emergency architectures, which serve as the foundation for Next
   Generation 911 and 112 systems.  These efforts encompass a wide range
   of protocols and cover essential aspects, including location
   determination and other relevant elements.  The following key
   specifications highlight these contributions: [RFC4119], [RFC4676],
   [RFC5222], [RFC5985], [RFC6225], [RFC6442], [RFC6443] [RFC6881],
   [RFC7852], and [RFC8876],

Gundavelli & Grayson      Expires 14 July 2024                  [Page 5]
Internet-Draft      Emergency Communication Services        January 2024

   However, it is worth noting that a substantial portion of the work
   conducted by the IETF predates the current industry focus on roaming
   in Wi-Fi networks using Passpoint profiles and identity federation
   rameworks, as well as the infrastructure established by the
   OpenRoaming federation.  There is inherent value in standardizing
   emergency communication approaches that align with these newer
   industry developments around Wi-Fi roaming.

   The primary objective of these efforts is to enable individuals with
   Wi-Fi devices within the coverage area of an OpenRoaming hotspot to
   connect to the network without requiring specific access credentials.
   This allows them to make emergency calls seamlessly and without any
   barriers.  This can save lives!

3.2.  NG911 and NG112 Emergency Systems

   Next Generation 911 (NG911) is the new emergency communication system
   designed to enhance the effectiveness and efficiency of emergency
   services.  NG911 builds upon the existing 911 emergency response
   infrastructure by integrating newer capabilities.

   The implementation of the NG911 architecture is planned to occur in
   multiple phases.  The first phase focuses on enhancing the existing
   legacy 911 architecture.  Following this, a transitional phase will
   be implemented to gradually transition to the full-fledged NG911
   system.  Finally, the End State NG911 Service architecture will be
   established to provide the ultimate NG911 capabilities.

   NG911 leverages IP-based networks to transmit emergency
   communications, enabling seamless integration with various digital
   platforms and devices.  It enables individuals to contact emergency
   services not only through traditional phone calls but also through
   text messages, multimedia messages, and even real-time video
   streaming.  This provides greater flexibility for individuals with
   diverse communication preferences or accessibility needs.

   One of the significant advantages of NG911 is the ability to receive
   more detailed location information from callers.  Traditional 911
   systems rely on the location of the calling device or the cell tower
   used for the call, which can sometimes result in imprecise location
   data.  NG911 leverages Global Navigation Satellite Systems (GNSS) to
   obtain more accurate and reliable location information, allowing
   emergency services to respond more swiftly and precisely.

   NG911 architecture is based on IETF standards.  The SIP UA which is
   authenticated to the P-CSCF, creates a SIP INVITE that includes
   location information in the form of a Presence Information Data
   Format Location Object (PIDF-LO) in the body of the message.  The

Gundavelli & Grayson      Expires 14 July 2024                  [Page 6]
Internet-Draft      Emergency Communication Services        January 2024

   P-CSCF passes the SIP INVITE to the E-CSCF.  The E-CSCF passes the
   SIP INVITE message to the LRF to obtain location and routing
   information for the emergency call.  LRF will use the Location to
   Service Translation (LoST) protocol [RFC5222] to query the RDF.  The
   RDF will determine routing based on the routing location

   NG112 is the new emergency communication system designed to improve
   emergency services by integratung modern technologies and
   capabilities.  It is a European initiative that aims to enhance the
   existing emergency response infrastructure, building upon the legacy
   of the widely recognized emergency number, 112.  NG112 largely
   follows the NG911 architecture and is based on IETF standards.

3.3.  3GPP Emergency Service Architecture

   The 3rd Generation Partnership Project (3GPP) has developed an
   Emergency Service architecture that enables effective and reliable
   emergency communication services within cellular networks.  This
   architecture encompasses various components and protocols designed to
   ensure prompt emergency assistance.

   The essential component of the architecture is the Emergency Services
   (ES) functionality, which allows users to dial emergency numbers,
   such as 112 or 911, to access emergency services.  ES interfaces with
   the cellular network infrastructure to establish emergency calls and
   deliver them to the appropriate Public Safety Answering Point (PSAP)
   or emergency call center.

   Additionally, the architecture includes the Location Services (LCS)
   system, which enables accurate positioning of emergency callers.  LCS
   uses various positioning methods, including GPS, and network-based
   methods, to determine the caller's location and transmit it to the
   PSAP for effective emergency response.

   The 3GPP Emergency Service architecture also incorporates support for
   multimedia services, such as text messages, images, and videos,
   enabling individuals to provide additional information to emergency
   services during critical situations.

   Overall, the 3GPP Emergency Service architecture ensures that
   cellular networks have the necessary capabilities to handle emergency
   calls, deliver accurate location information, and support multimedia
   communication for effective emergency response and public safety.

Gundavelli & Grayson      Expires 14 July 2024                  [Page 7]
Internet-Draft      Emergency Communication Services        January 2024

4.  Proposed Approach

   WBA's OpenRoaming is a roaming federation service of Access Network
   Providers (ANPs) and Identity Providers (IDPs), enabling an automatic
   and secure Wi-Fi experience globally.  WBA OpenRoaming creates the
   framework to seamlessly connect devices to the access networks that
   are part of the federation.  For further insights into the
   architectural specifics of WBA's OpenRoaming, please refer to the
   document, [I-D.tomas-openroaming].

    ANP-1 --\                    _----_                     /-- IDP-1
             \     Access      _( Open )_      Identity    /
    ANP-2  ---<==  Network ---(  Roaming )---  Providers <==-- IDP-2
             /     Providers   (_      _)                  \
    ANP-3 --/                    '----'                     \-- IDP-3

                      Figure 1: OpenRoaming Federation

   The solution presented in this proposal utilizes the legal framework
   and core components of the OpenRoaming federation to extend emergency
   calling capabilities (e.g. 911/112) to tens of thousands of existing
   OpenRoaming hotspots operating on unlicensed Wi-Fi networks.  The
   following text explains the architectural framework of this approach.

4.1.  Scenario Description

   *  A Wi-Fi-enabled device equipped with a pre-installed emergency
      passpoint profile and located within the coverage area of an
      OpenRoaming hotspot.  The device does not have the access network
      credentials for that hotspot, other than the emergency passpoint

   *  The hotspot is configured to facilitate emergency communication
      services.  It advertises the emergency RCOI (Roaming Consortium
      Identifier) in the IEEE 802.11 beacon messages.

   *  When a user dials the emergency calling number designated for
      their regulatory domain (such as 911/112), their device initiates
      a search for Wi-Fi networks that support emergency services by
      comparing the RCOI field of the passpoint profile.  Upon finding a
      match, temporary access to the network is granted.  The user's
      location is relayed to the Identity Provider (IDP) by the access

Gundavelli & Grayson      Expires 14 July 2024                  [Page 8]
Internet-Draft      Emergency Communication Services        January 2024

   *  The device obtains the emergency service configuration from the
      IDP designated for the emergency realm, and specific to that

   *  User makes the emergency call registration.  User's location
      reported in the call signaling is cross correlated with the
      location reported by the access network.

   *  User's call is routed to the nearest PSAP.

4.2.  Technical Architecture

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

Gundavelli & Grayson      Expires 14 July 2024                  [Page 9]
Internet-Draft      Emergency Communication Services        January 2024

                      Figure 2: Technical Architecture

   The E-CSCF (Emergency Call Session Control Function) and P-CSCF
   (Proxy-Call Session Control Function) are well-defined functions
   within the IMS (IP Multimedia Subsystem) architecture as specified by
   3GPP.  These functions can be utilized for emergency calling
   purposes, or alternatively, they can be substituted with an IETF SIP
   Proxy [RFC3261], to support the necessary calling services.

   There will be a designated Identity Provider (IDP) and designated
   emergency calling services for supporting emergency calling service
   (e.g., 911/112).  The AAA server in the IDP supports the realm for
   that region (e.g. "") and the EMERGENCY-RCOI
   policies (i.e., for example an 911/112 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.

   The devices are pre-configured with a HotSpot2.0/Passpoint profile,
   which includes the emergency 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 services (e.g. 911/112).  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 communication 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 services when connected
   to access networks that are not part of the OpenRoaming federation.
   NOTE that this assumes that the device has basic internet

Gundavelli & Grayson      Expires 14 July 2024                 [Page 10]
Internet-Draft      Emergency Communication Services        January 2024

   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.

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

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

5.  Key Service Requirements

   An emergency call handling service shall be designated to handle Wi-
   Fi-enabled emergency calls (e.g. 911/112), along with an IDP function
   for the respective 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 and a common identity
   such as (e.g.) "".

Gundavelli & Grayson      Expires 14 July 2024                 [Page 11]
Internet-Draft      Emergency Communication Services        January 2024

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

7.  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 Emergency Communication service (e.g. 911/112).

Gundavelli & Grayson      Expires 14 July 2024                 [Page 12]
Internet-Draft      Emergency Communication Services        January 2024

8.  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 emergency service and allow provisions to indemnify ANPs
   against any liabilities resulting from emergency call failures.

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

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

Gundavelli & Grayson      Expires 14 July 2024                 [Page 13]
Internet-Draft      Emergency Communication Services        January 2024

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

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

13.  Call Flows

Gundavelli & Grayson      Expires 14 July 2024                 [Page 14]
Internet-Draft      Emergency Communication Services        January 2024

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

Gundavelli & Grayson      Expires 14 July 2024                 [Page 15]
Internet-Draft      Emergency Communication Services        January 2024

   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 Header.
   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 3: Emergency e911 Services over Wi-Fi Access

   Following is some additional text explaining above interactions.

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

   *  The device may be preconfigured with a generic Emergency SIP (non-
      IMS) Profile.

   *  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 services (e.g.
      911/112) will advertise the emergency RCOI in the 802.11 Beacon
      messages, and furthermore will respond to any ANQP queries on the
      supported services.

Gundavelli & Grayson      Expires 14 July 2024                 [Page 16]
Internet-Draft      Emergency Communication Services        January 2024

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

   *  Prior to including the access network reported Civic Location, the
      Identity Provider (IDP) has the option to conduct a location
      validation check.  If the reported location fails the validity
      test, the IDP can still add the location entry to the CLF.
      However, the entry can be flagged to indicate that the address did
      not pass the location validation test.

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

Gundavelli & Grayson      Expires 14 July 2024                 [Page 17]
Internet-Draft      Emergency Communication Services        January 2024

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

14.  IANA Considerations

   This document does not requires any IANA actions.

Gundavelli & Grayson      Expires 14 July 2024                 [Page 18]
Internet-Draft      Emergency Communication Services        January 2024

15.  Security Considerations

   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.

16.  Acknowledgements

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

   Special thanks to Brian Rosen for a through review and detailed
   comments and advice.  We also like to thanks Dale R.  Worley, Roland
   Jesske, and Christer Holmberg for all the discussions.

   Finally, we like to thank ART area director, Murray Kucherawy and
   DISPATCH working group chairs for facilating the discussions in the
   working group.

17.  References

17.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 July 2024                 [Page 19]
Internet-Draft      Emergency Communication Services        January 2024

17.2.  Informative References

              Tomas, B., Grayson, M., Canpolat, N., Cockrell, B. A., and
              S. Gundavelli, "WBA OpenRoaming Wireless Federation", Work
              in Progress, Internet-Draft, draft-tomas-openroaming-00,
              14 June 2023, <

   [RFC3261]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
              A., Peterson, J., Sparks, R., Handley, M., and E.
              Schooler, "SIP: Session Initiation Protocol", RFC 3261,
              DOI 10.17487/RFC3261, June 2002,

   [RFC4119]  Peterson, J., "A Presence-based GEOPRIV Location Object
              Format", RFC 4119, DOI 10.17487/RFC4119, December 2005,

   [RFC4676]  Schulzrinne, H., "Dynamic Host Configuration Protocol
              (DHCPv4 and DHCPv6) Option for Civic Addresses
              Configuration Information", RFC 4676,
              DOI 10.17487/RFC4676, October 2006,

   [RFC5222]  Hardie, T., Newton, A., Schulzrinne, H., and H.
              Tschofenig, "LoST: A Location-to-Service Translation
              Protocol", RFC 5222, DOI 10.17487/RFC5222, August 2008,

   [RFC5985]  Barnes, M., Ed., "HTTP-Enabled Location Delivery (HELD)",
              RFC 5985, DOI 10.17487/RFC5985, September 2010,

   [RFC6225]  Polk, J., Linsner, M., Thomson, M., and B. Aboba, Ed.,
              "Dynamic Host Configuration Protocol Options for
              Coordinate-Based Location Configuration Information",
              RFC 6225, DOI 10.17487/RFC6225, July 2011,

   [RFC6442]  Polk, J., Rosen, B., and J. Peterson, "Location Conveyance
              for the Session Initiation Protocol", RFC 6442,
              DOI 10.17487/RFC6442, December 2011,

Gundavelli & Grayson      Expires 14 July 2024                 [Page 20]
Internet-Draft      Emergency Communication Services        January 2024

   [RFC6443]  Rosen, B., Schulzrinne, H., Polk, J., and A. Newton,
              "Framework for Emergency Calling Using Internet
              Multimedia", RFC 6443, DOI 10.17487/RFC6443, December
              2011, <>.

   [RFC6881]  Rosen, B. and J. Polk, "Best Current Practice for
              Communications Services in Support of Emergency Calling",
              BCP 181, RFC 6881, DOI 10.17487/RFC6881, March 2013,

   [RFC7852]  Gellens, R., Rosen, B., Tschofenig, H., Marshall, R., and
              J. Winterbottom, "Additional Data Related to an Emergency
              Call", RFC 7852, DOI 10.17487/RFC7852, July 2016,

   [RFC8876]  Rosen, B., Schulzrinne, H., Tschofenig, H., and R.
              Gellens, "Non-interactive Emergency Calls", RFC 8876,
              DOI 10.17487/RFC8876, September 2020,

   [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 July 2024                 [Page 21]