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

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

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 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]" <[e-mail]>
Date: Tuesday, April 4, 2023 at 12:44 AM
To: Sri Gundavelli <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
Cc: "[e-mail]" <[e-mail]>, "Mark Grayson (mgrayson)" <[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]> Im Auftrag von Sri Gundavelli (sgundave)
Gesendet: Montag, 3. April 2023 16:56
An: Christer Holmberg <christer.holmberg=[e-mail]>; Brian Rosen <[e-mail]>
Cc: [e-mail]; Mark Grayson (mgrayson) <[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.

[cid:image001.png@01D966E1.A1D95570]

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>