Re: [Ecrit] [dispatch] New Version Notification for draft-gundavelli-dispatch-e911-wifi-00.txt

["Sri Gundavelli (sgundave)" <[e-mail]>]

Hi Brian,

Sure. Makes sense to me. Will add considerations around location types and validation considerations, also on CLF entry population. Will add some text.

Regards
Sri


From: Brian Rosen <[e-mail]>
Date: Monday, April 24, 2023 at 11:08 AM
To: Sri Gundavelli <[e-mail]>
Cc: "Mark Grayson (mgrayson)" <[e-mail]>, ECRIT <[e-mail]>
Subject: Re: [dispatch] New Version Notification for draft-gundavelli-dispatch-e911-wifi-00.txt

It is common to actually populate a location that fails the validation test into the database, because generally, incorrect location is better than no location, but the wording in the doc should state that only validated information shall be placed in the CLF.  Validation only applies to civic addresses, not geo.

The system revalidates location when it is received, so the call taker will know that the location was invalid.  That causes more questions to be asked and slows response, but as above, incomplete, or somewhat erroneous location is better than none, as long as we know that’s what it is.

Brian


On Apr 20, 2023, at 12:25 PM, Sri Gundavelli (sgundave) <[e-mail]> wrote:

Hi Brian,

Thanks for the larger context around emergency architecture evolution.

I fully agree any new technical proposal that we publish should be forwarding looking, and not be limited to legacy architectures.

Let’s review the technical issue on location issue, around “location validation”.  In the proposal we have when an emergency caller, using the emergency profiles attaches to the Wi-Fi hotspot, the location of the caller is reported by the access point to the IDP, which makes it into the CLF (Connectivity Location Function).

The location of the caller is populated dynamically. But here in the proposal we did not talk about the validity of the location. May be as you suggested we can certainly add steps where the IDP will perform a LVF check. Meaning, before we insert the location into the CLF (Secure Location Tag / Access Point Identifier: Civic Address or Geo-spatial coordinates), we can do a LVF check of the AP reported location.  If the check fails, the location entry can be tagged with a marking that it failed the check. When there is subsequent CLF check during the emergency call, the system will be aware that the address did not pass the LVF check. Thoughts on this?
Regards
Sri



From: Brian Rosen <[e-mail]>
Date: Wednesday, April 19, 2023 at 12:52 PM
To: Sri Gundavelli <[e-mail]>
Cc: "Mark Grayson (mgrayson)" <[e-mail]>, ECRIT <[e-mail]>
Subject: Re: [dispatch] New Version Notification for draft-gundavelli-dispatch-e911-wifi-00.txt

I appreciate that there are improvements in location accuracy in WiFi.  I was under the impression that much of the improvement was in software in or behind the device (that is, the OS) but if it’s actually in the WiFi network, that’s great.

The emergency calling system is in the midst of a major change.  In North America, the new system is known as NG9-1-1, in the EU, its NG112.  Many existing systems still use legacy mechanisms, and we’re roughly half way in the transition, or maybe less, depending on how you count, in the US.

NG911/NG112 is based on the IETF design described in RFC6881.   I don’t think it makes any sense to create a new IETF document that only works on the older systems.  You could describe backwards compatibility if you want, but the design should be geared towards the newer systems.

Even in older systems, where a user is entering a location into a website, that location is validated against a database maintained by the emergency call authorities before it is accepted into the database.  In the US and Canada, that older database was “MSAG”, Master Street Address Guide.   In the new one, it’s called “Location Validation Function” (LVF), which uses the LoST protocol to do the validation.  You are not allowed to send an unvalidated location either in older or newer systems.  The documentation you are looking at is the user level, and doesn’t show the back end validation that is occurring.  It’s literally been 40 years since validation was required.  The location configured in the AP, if it is to be sent in an emergency call, MUST be validated before use.

Brian






On Apr 19, 2023, at 12:01 PM, Sri Gundavelli (sgundave) <[e-mail]> wrote:

Hi Brian,

Thanks. We should have added reference to RFC 6881.

On the aspects around location configuration and reporting, the proposal does conform to the location requirements stated in section 6.2, RFC 6881.  We do require the WLAN network supporting emergency service to be able to provide the Civic and/or Geo-spatial coordinates of the access point / caller. We do understand it is not just translating RFC-4776 / RFC-6225 obtained from an egress router into RFC-5880 attributes, but the indicated location has to meet the local regulatory requirement.

The reported location is not any “nearest hotspot”, but it is either the location of the access point serving the device, or the location of the device (when the network is capable of supporting localization services).

There has been good amount of progress over the years in the Wi-Fi world around location tracking.  The ability for the access point to be able to track the location of the connected devices is a basic capability. Many indoor applications rely on indoor localization of the device.  The granularity of the reported location and confidence levels should meet most/any local regulatory requirement around location. Also, an AP operating 6 GHz Standard Power mode must be able to provide precise location before getting an AFC grant for spectrum resource, and this does include Z coordinates that you have talked about. With the elements reported from the AP to the IDP, the AP identifier, a secure location tag, and Civic/Geo-spatial coordinates, we should be able to meet these requirements.

I looked at the documentation of Carrier Wi-Fi calling in many operator websites, and in end points, that all require the user to enter the civic address before making the call. That is the deployed art. What we have is a network provided location; a trusted network node configured to support emergency services providing the location of the caller.

W.r.t the LoST reference, I would think the LoST work is still relevant in this context. The PSAP lookup for the reported location is something the backend system can leverage. This should not have any bearing on how the AP reports its location to the IDP, or how its configured.

Regards
Sri






From: Brian Rosen <[e-mail]>
Date: Tuesday, April 18, 2023 at 12:35 PM
To: Sri Gundavelli <[e-mail]>
Cc: "[e-mail]" <[e-mail]>, Christer Holmberg <[e-mail]>, "Mark Grayson (mgrayson)" <[e-mail]>, ECRIT <[e-mail]>
Subject: Re: [dispatch] New Version Notification for draft-gundavelli-dispatch-e911-wifi-00.txt

Generally speaking, supporting emergency calls is not trivial.  There is a bunch of code to do that, even assuming that the device is already some kind of phone.  Please look at RFC6881.  What is deployed doesn’t exactly follow 68881, but it’s close.

The location MUST be validated before use.  It’s not enough to just use the RFC4776 civic address elements: it has to be a location the 9-1-1 system recognizes as valid.  There is a protocol (LoST, RFC5222) and a profile of PIDF-LO (nation specific) that has to be used to construct and validate the address.  These days, you also need Z (floor).  Generally, nearest hotspot isn’t adequate, especially if it’s on the wrong floor.  I wouldn’t say it’s totally wrong to use the location of the nearest hotspot, but that would be a fallback when whatever you use to reasonably accurately estimate location fails.

We don’t use pANIs any more.  Also, that was US (or really US and Canada) specific.  There never was a “P-ANI” header.  We do use the SIP Geolocation header to carry the location.  The emergency system doesn’t “look up” a location any more.  The location is included in the signaling with the call.

Brian




On Apr 18, 2023, at 11:26 AM, Sri Gundavelli (sgundave) <[e-mail]> wrote:

Hi Brian,

The use-case is about the device in the vicinity of a Wi-Fi hotspot which support emergency passpoint profiles. The device with the emergency passpoint profile, but with no specific access credentials to that hotspot, should be able to discover the network, perform an attach and complete access authentication to the IDP associated with the emergency realm. This will enable to the device to have internet connectivity with limited access for making emergency calls.

Passpoint profiles are widely supported by the device eco-system and so the definition of a new profile should not require any new code/development on the device. The aspects around network discovery, selection and association will still be based on the elements in the profile. The emergency profile can be installed at the time of manufacturing (requires rule making from the local regulator), or installed by the enterprise IT.

Location of the emergency caller is an important element in the system. The access point configured to support emergency calling will have to be configured with the location of the access point. When a device is permitted to attach to the network using the emergency passpoint profile, the access point will report RFC-5580 location elements, AP identifier and/or the secure location tag in the RADIUS signaling to the IDP.

The IDP will update these location elements and associate them to the access point (AP identifier and/or the Secure Location Tag).  The device making the emergency call will include these elements in the SIP P-ANI header. The emergency calling system will be able to look up the location from the IDP by using the elements in the P-ANI header. This allows the network to validate the device reported location with a trusted access point reported location. The reporting element, which is the access point, is a trusted network element with the OpenRoaming federation issued certificates and this provides an additional layer of validation of the caller reported location. This approach eliminates rogue calls with incorrect location in the SIP signaling.


Regards
Sri








From: Brian Rosen <[e-mail]>
Date: Tuesday, April 18, 2023 at 5:30 AM
To: Sri Gundavelli <[e-mail]>
Cc: "[e-mail]" <[e-mail]>, Christer Holmberg <[e-mail]>, "Mark Grayson (mgrayson)" <[e-mail]>, ECRIT <[e-mail]>
Subject: Re: [dispatch] New Version Notification for draft-gundavelli-dispatch-e911-wifi-00.txt

I’m tempted to say “call me when the FCC does this”, but we’ll put that aside for now :)

This is the IETF, so when you say “FCC” you really need to say “the local regulator”.  You need to discuss how that actually works, especially when you are near borders.  you may have a hotspot connection in another country from the one that would provide emergency services,

Are you assuming Internet connectivity everywhere here, so that the device can contact the voice service provider?  You should probably say that.

This is a fair amount of code on a device that would only be used in this very specific circumstance.  Lots of testing/certification.  Any ideas of how that would be done?  What is the incentive/imperative for a device mfg to make this work?

Are you aware of the “dispatchable location” issues?  Your location has to be dispatchable.  How are you getting that?


Brian





On Apr 13, 2023, at 4:09 PM, Sri Gundavelli (sgundave) <[e-mail]> wrote:

Hi Brian,

On the second part of your question, few thoughts:

We are mainly targeting Wi-Fi hotspots supporting passpoint profiles. For example, taking the WBA’s OpenRoaming federation, there are identity providers, and access network providers, all part of the same roaming federation and with a legal framework between them. A user with a  given passpoint profile identifying a given RCOI (Roaming Consortium Id) will be able to latch on to any of the access network and complete access authentication.  IDP/RCOI policies are enforced on the session.

With the proposal, there will be IDP specific to the emergency realm and FCC will be the legal entity. FCC can authorize an MNO with the IMS network, or choose a voice service provider for supporting the emergency realm. When the user with emergency passpoint profile attaches to the hotspot support emergency profile, the authentication signaling from the Wi-Fi AP/hotspot will be terminated in the authentication server in the IDP, and the policies and configurations (including SIP service configuration)  associated with the emergency profile will be delivered to the device (IDP -> AN -> Device).  The device will complete SIP registration with the Proxy (obtained from the IDP).  So, to you question who is providing the SIP path, it is the entity designated by FCC and not the access network providing the voice services. The below diagram should provide some context of the environment.

The legal framework between ANP and IDP is an important aspect, as there will by now means to provide immunity to the ANP (with FCC as the IDP) against any call failures. We are thinking such legal provisions will improve the adoption of emergency calling by any access providers. This approach brings FCC into the equation; it helps promote the adoption.

You also talked about enterprise environment.  The above framework should technically work for enterprise use-case, including tele-worker use-cases. But as you point out we need to layout some considerations on the interconnect with the enterprise PBX and the emergency system. Some more thinking is needed here.



<image001.png>


Regards
Sri


From: Brian Rosen <[e-mail]>
Date: Thursday, April 13, 2023 at 10:12 AM
To: Sri Gundavelli <[e-mail]>
Cc: "[e-mail]" <[e-mail]>, Christer Holmberg <[e-mail]>, "Mark Grayson (mgrayson)" <[e-mail]>, ECRIT <[e-mail]>
Subject: Re: [dispatch] New Version Notification for draft-gundavelli-dispatch-e911-wifi-00.txt

The emergency services are firmly against so-called “unitialiized devices”.  They are stuck with the regulatory requirement that has been put on the providers of such devices to support emergency calls, but they would be strongly against expanding the scope of such devices: there are roughly no cases of real emergency calls using such devices, and many, many cases of false emergency calls that cannot be traced to the caller.  I would strongly suggest you don’t pursue such an expansion of that requirement.  It’s a bad idea, and it doesn’t do what proponent’s hoped it would do.  We have substantial real world experience.

You need a reliable identity that can be traced to a real person.  It’s never ironclad (pre-paid cellular for example), but it has to work most of the time.

I’m still confused who the entity that is providing the SIP path is supposed to be.  Are you expecting the WiFi access point owner to do that or some mobile network operator?  If it’s the WiFi AP owner, then they don’t have an interconnect in most cases: they might have a PBX on that network with a PSTN interconnect (like a SIP Trunk) that supports emergency calling, but that’s fairly far removed from the WiFi network and assuming they will allow a random WiFi user to connect to their AP, and then provide a SIP path to emergency services seems very far fetched to me.

But if it was some kind of mobile network operator, what relationship do they have with the enterprise that has the AP?

Callbacks require identity: see above

Brian







On Apr 13, 2023, at 11:25 AM, Sri Gundavelli (sgundave) <[e-mail]> wrote:

Hi Brian,

Thanks for the follow-up. These are very good comments. In the revised version, we will capture all these points.

On the requirement around interconnect to emergency network, we are thinking the FCC designated entity providing identity and voice services for the realm, “sos.fcc-authorized.org<http://sos.fcc-authorized.org/>” will be able to meet the requirements, and the interconnect will be similar to how any MNO’s IMS interconnect is realized today. We will analyze this and add some text.

On traceability comment, the current cellular systems allow emergency call from a device with an expired SIM subscription, or no SIM card. At least in some countries this is allowed. Most GSM phones allow calling of emergency numbers without a SIM card, 112, 911, 118, 000, 110, 08, and 999. Calling these numbers will force the device to use any available network. I need to check the call flow if there is exchange of IMEI, but AFAIK there is no traceability there. In the proposal we have we require the use of emergency passpoint profile, it is possible to signal device specific identifiers in the signaling, and that is one way to realize device traceability. We already have mechanisms for location traceability. But, this allows traceability to a device, not to a person. Mark may have some additional thoughts here.

On the call backs, once the device is able to perform SIP registration with the emergency SIP proxy, it will be possible to support the callbacks. Will analyze this in detail.

Regards
Sri







From: Brian Rosen <[e-mail]<mailto:[e-mail]>>
Date: Wednesday, April 12, 2023 at 4:36 PM
To: Sri Gundavelli <[e-mail]<mailto:[e-mail]>>
Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, Christer Holmberg <[e-mail]<mailto:[e-mail]>>, "Mark Grayson (mgrayson)" <[e-mail]<mailto:[e-mail]>>, ECRIT <[e-mail]<mailto:[e-mail]>>
Subject: Re: [dispatch] New Version Notification for draft-gundavelli-dispatch-e911-wifi-00.txt

<moving to ecrit>
Some entity has to connect to the emergency network (in North America and EU Next Gen systems, this is the “Emergency Services IP Network” or ESInet.  Although the standards say that calls must be accepted over the Internet, in practice all current implementations have direct interconnect between the originating service provider and the ESInet.  If it’s an IMS network operator, they have such connections, and would use their E-CSCF.  I think it’s pretty unlikely that they would support a non-IMS call path.  But there has to be some OSP.  It could be an enterprise, as long as the enterprise permitted access, had a reasonable authentication system tied to some kind of identity and a SIP proxy server.

The emergency authorities don’t like unauthenticated calling sources.  That is how we get swatting.  So your proposal has to describe what identity is, and how that’s traceable to a real person.  You also have to describe how we do call-backs to the caller.

Brian







On Apr 4, 2023, at 1:38 PM, Sri Gundavelli (sgundave) <[e-mail]<mailto:[e-mail]>> wrote:

HI Roland,

Thank you for your comment.

I agree,  if IMS is unavailable P-CSCF/E-CSCF will all be unavailable.  The key point is non-availability of the cellular network, for PDU creation and/or accessing emergency voice functions. This goes back to Christer’s comment suggesting to use non-IMS terminology.  We will work on that.

On your other comment, access to IMS for wired/wireline devices with IMS-only subscription is a possibility. But we still need to allow the device to connect to the available hotspot with no access-network credentials and be able to obtain the IMS configuration. The IMS network in question can be based of a generic IETF defined voice function, which can do call routing to the PSAP. If a MNO is willing to let their IMS network be available for wired and non-cellular devices, that is an option.

Once the device gets connectivity to the access network based on the special emergency passpoint profile, the access network can deliver the associated IMS/voice-service configuration options to the device. The realm that we are proposing sos.fcc-authorized.org<http://sos.fcc-authorized.org/> and associated IDP can be configured with the IMS/voice-service configuration. These IMS/voice-service functions can be from an MNO, or some other service provider that FCC will authorize.

These configuration options will be signaled from the IDP to the access network, and in turn will be delivered it to the device over DHCP/ND/802.11. The device can perform registration with those voice functions and can initiate the emergency call.

Regards
Sri




From: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Date: Tuesday, April 4, 2023 at 12:44 AM
To: Sri Gundavelli <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "Mark Grayson (mgrayson)" <[e-mail]<mailto:[e-mail]>>
Subject: AW: [dispatch] New Version Notification for draft-gundavelli-dispatch-e911-wifi-00.txt

Hi,
What does this mean that IMS is unavailable?
When IMS is unavailable also the Emergency service (E-CSCF) is unavailable.

Did you also discover the IMS Access possibilities with Digest, where you have an IMS Subscription w/o any RAN connectivity and only via wireline/WIFI?

Best Regards

Roland

Von: dispatch <[e-mail]<mailto:[e-mail]>> Im Auftrag von Sri Gundavelli (sgundave)
Gesendet: Montag, 3. April 2023 16:56
An: Christer Holmberg <christer.holmberg=[e-mail]<mailto:christer.holmberg=[e-mail]>>; Brian Rosen <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>; Mark Grayson (mgrayson) <[e-mail]<mailto:[e-mail]>>
Betreff: Re: [dispatch] New Version Notification for draft-gundavelli-dispatch-e911-wifi-00.txt

Hi Christer,

Yes, 3GPP does define the interworking architecture with Wi-Fi, where the UE can use Wi-Fi to reach 3GPP core network for PDU establishment. The scenario that we have and what FCC CSRIC 8 looked into is where H-PLMN/V-PLMN and IMS is unavailable. Also, the interworking procedures assume there is Wi-Fi access connectivity. The access network in question may not have any relation to the operator for the UE to perform SIM based authentication to the access network.

The UE may not even have a cellular modem or SIM/eSIM credentials. What are trying to enable is allow the device to use a special emergency passpoint profile for connecting to any of the available hotspots that support emergency calling services. The device may be Wi-Fi only or a dual-radio capable device. Furthermore, if I see the carrier documentation for Wi-Fi calling, it requires the user to configure a civic address prior making any emergency call, and which a caller in distress may never configure. We are addressing this issue, by allowing a trusted access network with the federation issued certificates to signal the location over RADIUS to the IDP/CLF, which the network can cross correlate with the reported location in the SIP signaling.

<image001.png>

Regards
Sri


From: Christer Holmberg <christer.holmberg=[e-mail]<mailto:christer.holmberg=[e-mail]>>
Date: Monday, April 3, 2023 at 3:21 AM
To: Sri Gundavelli <[e-mail]<mailto:[e-mail]>>, Brian Rosen <[e-mail]<mailto:[e-mail]>>
Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "Mark Grayson (mgrayson)" <[e-mail]<mailto:[e-mail]>>
Subject: RE: [dispatch] New Version Notification for draft-gundavelli-dispatch-e911-wifi-00.txt

Hi,

Note that 3GPP has defined emergency calls over WiFi, so please indicate how your draft relates to that work.

Regards,

Christer

From: dispatch <[e-mail]<mailto:[e-mail]>> On Behalf Of Sri Gundavelli (sgundave)
Sent: Saturday, 1 April 2023 4.53
To: Brian Rosen <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>; Mark Grayson (mgrayson) <[e-mail]<mailto:[e-mail]>>
Subject: Re: [dispatch] New Version Notification for draft-gundavelli-dispatch-e911-wifi-00.txt

Hi Brian,

Sure. Will move the discussion to ECRIT.

Thanks for the pointers to the LoST and PIDF-LO work. Will add some considerations on how devices capable of LoST can obtain location-specific service configuration.


  *   LoST also provides the mechanism to validate location (which you do at configuration time) to make sure the location you send is known by the emergency services.

Ok. We will analyze this. If the mechanisms around Location-validity also covers the cases around detecting rogue/compromised clients, beyond making sure the claimed civic address exists, it will be very useful know. Will add the considerations.


  *   The text has to say how the device uses the location it discovers to make a call (‘perform”), which is what RFC6881 describes.  There are some practical differences in how NG9-1-1 and NG1-1-2 actually work that has to be taken into consideration when looking at 6881.

Ok. Thanks for the pointers. Will add these considerations.


Regards
Sri

From: Brian Rosen <[e-mail]<mailto:[e-mail]>>
Date: Friday, March 31, 2023 at 11:05 AM
To: Sri Gundavelli <[e-mail]<mailto:[e-mail]>>
Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: Re: [dispatch] New Version Notification for draft-gundavelli-dispatch-e911-wifi-00.txt

I do think discussion on this draft should move to ecrit.

Obtaining the regulatory specific calling service configuration (including the numbers) is defined in LoST (RFC5222).
The location must be provided in PIDF-LO form (RFC4119 and its updates).  That is the form (at least the actual location information part) that you use to query the LoST server to get the configuration data and the form of the data you  send to the emergency services.
LoST also provides the mechanism to validate location (which you do at configuration time) to make sure the location you send is known by the emergency services.
The text has to say how the device uses the location it discovers to make a call (‘perform”), which is what RFC6881 describes.  There are some practical differences in how NG9-1-1 and NG1-1-2 actually work that has to be taken into consideration when looking at 6881.

Brian


On Mar 31, 2023, at 4:55 PM, Sri Gundavelli (sgundave) <[e-mail]<mailto:[e-mail]>> wrote:

Hi Brian,

Thanks a lot for reviewing the document. I agree, the document should provide the larger emergency calling context. The current art, the elements in the system, interfaces with the PSAPs and other touch points. We are familiar with the prior efforts in IETF and also standards bodies including 3GPP and around ATIS reports. Perhaps a discussion on how NG911/NG211 emergency service network are deployed will be useful. The document requires more work, and this is just a starting point.

The key technical objective for this work is around enabling a Wi-Fi capable device to be able to discover hotspots that support emergency calling, ability to perform a network attach, be able to obtain the regulatory-domain specific calling voice service configuration (including emergency calling numbers) and be able to perform the emergency call. The focus is also on how the network can obtain the location of the emergency caller and the mechanisms for detecting rogue device signaling incorrect location.  Finally, some considerations on the emergency passpoint profiles that are required to be present on the device. This work complements the prior IETF efforts on emergency support for greatly improving the access to emergency services. There are tens of thousands of Wi-Fi hotspots supporting Wi-Fi roaming based on passpoint standards. This approach allows the devices to be able to use any of those hotspots for making that emergency call.

On the choice of the draft title, we do understand the emergency calling numbers are specific to the regulatory domain in question and the proposed approach is not specific to any one regulatory domain. In that sense, we should have been bit more sensitive about this. We will modify the draft title to be generic and not specific to one regulatory domain.

Thanks a lot for the feedback.

Regards
Sri



On 3/31/23, 2:02 AM, "Brian Rosen" <[e-mail]<mailto:[e-mail]> <mailto:[e-mail]>> wrote:


I have read this draft.


It is totally lacking context of current and evolving standards in emergency calling, including:
1. Basic IETF emergency calling standards (/RFC4119/RFC5222/RFC5985/RFC6881)
2. NG911 and NG112 standards that are being deployed, which are based on the IETF standards
3. ETSI and ATIS standards that support the above


While I don’t know enough about WiFi or some of the 3GPP standards to comment on the technical approach in the doc, I am intimately familiar with what is deployed, and about to be deployed in emergency calling and this doc can’t begin to get considered until it deals with the issues associated with the IETF/NENA/EENA/ETSI/ATIS work.


As a really simple start, authors might consider that 9-1-1 is North America only, while the IETF is world-wide.


Brian









On Mar 27, 2023, at 12:35 AM, Sri Gundavelli (sgundave) <sgundave=[e-mail]<mailto:sgundave=[e-mail]> <mailto:[e-mail]>> wrote:

Dear All:

Attached is the link to the document on Supporting emergency 911 services over Wi-Fi. The attached document proposes an approach based on WBA's Wi-Fi OpenRoaming and uses many other elements which are already in standards.

We are looking for some technical feedback. We believe there is value in IETF identifying new methods for improving e911 service access.

Appreciate any feedback.

Regards
Sri



Name: draft-gundavelli-dispatch-e911-wifi
Revision: 00
Title: Emergency 911 Services over Wi-Fi
Document date: 2023-03-13
Group: Individual Submission
Pages: 15
URL: https://www.ietf.org/archive/id/draft-gundavelli-dispatch-e911-wifi-00.txt <https://www.ietf.org/archive/id/draft-gundavelli-dispatch-e911-wifi-00.txt> <https://www.ietf.org/archive/id/draft-gundavelli-dispatch-e911-wifi-00.txt> <https://www.ietf.org/archive/id/draft-gundavelli-dispatch-e911-wifi-00.txt&gt;>
Status: https://datatracker.ietf.org/doc/draft-gundavelli-dispatch-e911-wifi/ <https://datatracker.ietf.org/doc/draft-gundavelli-dispatch-e911-wifi/> <https://datatracker.ietf.org/doc/draft-gundavelli-dispatch-e911-wifi/> <https://datatracker.ietf.org/doc/draft-gundavelli-dispatch-e911-wifi/&gt;>
Htmlized: https://datatracker.ietf.org/doc/html/draft-gundavelli-dispatch-e911-wifi <https://datatracker.ietf.org/doc/html/draft-gundavelli-dispatch-e911-wifi> <https://datatracker.ietf.org/doc/html/draft-gundavelli-dispatch-e911-wifi> <https://datatracker.ietf.org/doc/html/draft-gundavelli-dispatch-e911-wifi&gt;>




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








The IETF Secretariat







_______________________________________________
dispatch mailing list
[e-mail]<mailto:[e-mail]> <mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/dispatch <https://www.ietf.org/mailman/listinfo/dispatch>