Re: [DMM] Emergency 911 Services over Wi-Fi

David Lake <d.lake@surrey.ac.uk> Wed, 29 March 2023 07:29 UTC

Return-Path: <d.lake@surrey.ac.uk>
X-Original-To: dmm@ietfa.amsl.com
Delivered-To: dmm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1E39C151B08 for <dmm@ietfa.amsl.com>; Wed, 29 Mar 2023 00:29:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=surrey.ac.uk
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aB7dAQIqPQKY for <dmm@ietfa.amsl.com>; Wed, 29 Mar 2023 00:29:13 -0700 (PDT)
Received: from EUR02-DB5-obe.outbound.protection.outlook.com (mail-db5eur02on20700.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe12::700]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACEE2C1516E2 for <dmm@ietf.org>; Wed, 29 Mar 2023 00:29:12 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=UrLtQ9EG/vGgjZJHDoxIvLEURM/trI86T870HA65ThUf4Pm9Bqv925U6IGlrRFTSofzXMi6zf473XVWVAqC3LMOnFY0vhRqB8cirXQDot0+iyiNDai662avS679pJDB7PbsxVamrZySfHpdytJbGvPhtg0HXOqNBd7dSLFgsfHJNVQIakmfl3Qyl2dxwA9GE6kyMShAA7+tcZ1Gpn/VCEnZZKLqz5rwgOw3XUhxgXbDig5kV3pQGgwLjut7ZxJ2FCiAsRVEhzVmvLfWtC8A3VSpdt+6UaZtKYZEtwpTnfYDafGfxyFer33BBvboEAjrY8POGQJZ6qaLmZNbpfYF5QQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=Ki6vCEC3EXHc7ZlQyGfanOrln6KIydEyd7lmlu2oytc=; b=Kbi7M6KcHyLWOn3EhP1UL6CT95ItjoI2Lp++PVUUtu+CNrwUj5Qk0xLlcuTfVxeORlTxf0scBmQQwYlKL1dZOkTW/faoNOQs4l42w5pJCkkKb085F/p2Qcz+gh0J8+ZccoHpMjYesAltb5+A2s0UtURR1mC+XrNB0j5vt6AkaOMAhMMCDIKIbjbMnDQRVypS1xzstx1VlohEA6mliBTGkgPpAvwTzmw+9mrivGzyYa1Um8JPu7FCb7+d5dKvYizSUL2KibwaQCsiLR0Zbq3TZxBNgbzVLB07l34851BROc5i1mGbWc7+iAMZSoR5Lr34sv3m5Ji+S25SxN/1RCurPA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=surrey.ac.uk; dmarc=pass action=none header.from=surrey.ac.uk; dkim=pass header.d=surrey.ac.uk; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=surrey.ac.uk; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Ki6vCEC3EXHc7ZlQyGfanOrln6KIydEyd7lmlu2oytc=; b=mVSNdioJA6jssHLg2k/FgQHrvUUh9+QLn4v8n+0O1z93GgLPAE22eyhmt/KAVtSXStEpRXPbPL2uNLFlqDQh98LMzlq3xt1ws3D7Kz9KJO740Ona4l1bazrtrV10R/W4r9X2qhPTK8yDUfRAhzP5ssBtO1+PPaYmyHmiKl+udUmOi9pZn8cZAiZy918I8Vzf72RHoRY6I7TjW51r7oWPgU7xVQWbIe8DbLaEZnq4mDWKY4Z3jtQYiGLp5J7l2Sf+KQWHTjgcxEVXsNd9F1VBa2tCDhfuM0Nzu/eRxyn2ida3bwyV5tIvE6YusuIfCJfDDr16Y8zCFFT7mwtgPZP4SA==
Received: from DBAPR06MB6855.eurprd06.prod.outlook.com (2603:10a6:10:1b2::13) by AS5PR06MB8889.eurprd06.prod.outlook.com (2603:10a6:20b:651::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6222.33; Wed, 29 Mar 2023 07:29:06 +0000
Received: from DBAPR06MB6855.eurprd06.prod.outlook.com ([fe80::e970:4032:a8d6:7dd9]) by DBAPR06MB6855.eurprd06.prod.outlook.com ([fe80::e970:4032:a8d6:7dd9%2]) with mapi id 15.20.6178.041; Wed, 29 Mar 2023 07:29:06 +0000
From: David Lake <d.lake@surrey.ac.uk>
To: "Sri Gundavelli (sgundave)" <sgundave=40cisco.com@dmarc.ietf.org>, "dmm@ietf.org" <dmm@ietf.org>
Thread-Topic: [DMM] Emergency 911 Services over Wi-Fi
Thread-Index: AQHZYd6fnAR8qYota06av1hdTaxiva8RVwkO
Date: Wed, 29 Mar 2023 07:28:52 +0000
Message-ID: <DBAPR06MB68554E5A6BFC73F52C6462A9B5899@DBAPR06MB6855.eurprd06.prod.outlook.com>
References: <6B14E232-2308-49F5-9168-33626D1920CA@cisco.com>
In-Reply-To: <6B14E232-2308-49F5-9168-33626D1920CA@cisco.com>
Accept-Language: en-GB, en-US
Content-Language: en-GB
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=surrey.ac.uk;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: DBAPR06MB6855:EE_|AS5PR06MB8889:EE_
x-ms-office365-filtering-correlation-id: d2f4fea2-2158-454d-774e-08db30274787
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: rDuSGAQpwxNBGn7KSb6ZK2pbr4YPmLUUL5UIslrdPJOt3870s6m1b72oaG36CCqDaPS3aMBSfb+FtDY1K1QQTt3se7BfhTp55CO1Gqy2Q2VeSuW97PEpEwkubV/uZnP+YWmdtBAxP8YB03Tmbae/ma3X33khTm3iv1Rp22jHeiCMEKrZnvZ9g7yB+xAkgqQurDXNGbc7CIn4Hqt/fugwFoFMi6x/a6WSe8ldt5Uu6E5DkeoSLxAcuS5MMxmtD+FWuPmuHh6x8Bz8k11qTXONOe5ZJU/h9mI5fboF8irmiA5HKU3s8xEckWe/Gku0N+3ngmVR7O6+0zTR9gyysT6panE3FUaUPvHvNjDMcgELxWTXlmyJRWJUpgh+ll8yjZZoNnsfhMLfykbg/nozfrH/+Z8jejaCFCXUKHMwgJhDC94yxb5y+cwVYqRQo5BgBs+7x+ZyD6TrdF779xf8T1KQtBU4WEdK+YpWOeIEkQap35BqwsIuY09l7HJLcfgGt4aTTly1KwDS60UH7N19DMaXdpXzuyGvawESKHdRZrYSaBWzx3/N5vi61fmYgbGazhznvw+C5GNqbZBTzqm7sMgzUPIf9eCCeN3UgDPRknQIACCTwIOP1OSqu1wJaxylDVr6
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DBAPR06MB6855.eurprd06.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230028)(4636009)(366004)(396003)(346002)(39860400002)(136003)(376002)(451199021)(316002)(786003)(9686003)(6666004)(122000001)(86362001)(5660300002)(52536014)(8936002)(110136005)(41320700001)(41300700001)(66556008)(64756008)(76116006)(91956017)(8676002)(66946007)(66476007)(66446008)(186003)(53546011)(33656002)(55016003)(99936003)(38100700002)(478600001)(83380400001)(38070700005)(2906002)(71200400001)(6506007)(7696005); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: hdS+jZu03Ea8YZFD/5pMlC57mH5ukxktTlRR1wvUDcGz1rAOpKG33AggHPYK6/dIujatyIsdS5StnmoWTnixfYQbGsoatUK9VIIxSsnIsEzcGftrNT4a451wpI16utDoOvn5VzSyQz6JYESy6N9+2NDljfW3Vp0uQ6u6fWz0I6fJkmwIlOdFsUzYXIeyPOk+1TnapLEyFL7TwRnsRtEvO8Ou1euqeHB24HWv/Y5mObOAp9C7B9NHUlRXhujmHqzdOA3Yv0rB9DENefFbUlFsKkZmr9Edfm73SI4VsFbsv2dpuz9M7m6AXoqyJ+odXSo5RVoPa8/B1uAxBGc7kHeuQHdaAoN4Ly+G+VrmywsxHpx23tyw42IHYpBVoHSIbgCUsazsNwk0dr5Z9apxENF/kxRyLalghGloAqoiqODmkDeaqnBtGmtuU6grTdn6Lq0WA4jVM7V7koQvk9Uvgps4QlAbyhWKS1JJLTd8Sz0hVpPJnCOg8lx1AYUvevgq88Qa0/Qo2HDfafNPP1RjyP1+MOVXwS2N4uwwflPsuhTWFLfy6Dh5w+kAf/ZVOzCKsEWufgI2vg/YoIAI8+DBZAIcWduxsoLbId/+Z+pqy7rY0QMRyYaeIp2szSFyLgRm583gL3CRR7iQRBGG4VIvMHFuCDTbHH8zCtEbpNXbdicdv6mqcmoZN3gwaCDBTIIrVcTJhrP3oo0haGTFF5NafHpraHJ4VeDZdvU50Iqet8CZNNw/wLiZgaZh1XDnW1RUyydnQc08OZhY3TQO1Y1QpO5ijR7Iw6oP5sxLlrT3NNIlJwaDCVmUJ+kincjljog+MEzHsHcGfI4nomp7PCgvddc+wEXgAPgz6gWueh2ekcHGjzsqBUOQu3yo7fQrXQFFr1/YTS9eqDDjwdX3zaO9exDr0O+GeJdlniVzs1rlN0qk6PSTFCMVwogBqH83KXCWs+BuHbq9fe0rZy27ruHfUsJkbokU/CxWCwQRkiybmtnKU099vT00My5y8TAHGt/uLHgP4Nra70fUYVrZdcENO2eXaZRACX640AW+kbrLczHagTs7KB/OKFqJgxfHaH0EFfV5y56x9Xc3cfxVTlA0gpsY+Yr8sYhNWaJEWqRy9d3w9dnrnTDgiyLGfs+coUaN1A8KvDC14aA/mwXIShXxwOJ4sKkb3Y1lA6Z9u+42aNPQ81uvrc0JIJg6JbZMsT/St5B4ukET2KnXMxsNNrG2owt/OouvlOwtCK4uPR6CKlO2HLOkIY3vNGa4bw/8P1A74nZP/4+Xwsj09bh/XN51mjWrJYcaJezukSwvbrz6+dtGFd+MnPXMqqBMN6eCj0UNhmpEYsF/aYOIi9dn50PDN4OGMmae8El5M42YNYb0R1k1SL9jaSFXNiZPN8zjnE/ZDbNLLij3+wl1BlJFFZqcqrcgfLfIT4ZSp8M4/iuUgCUVk8BnU/jL3S7jIcRBHQpzOfDnEMr2F0ex+G1J/bs5ziIQIEwCCDFa9ARl6rerVSrxi2WATEqQUKfB5CM+05Cn5SyDMVqnR6AvVx7iTdxGqlOgosfuUCTyE5Q43p3TO2UtzoErm5nfuGL5r62sOt2kZnC0UmHx+2KhMQZcwWH5uOgp/EKj0q0/yWl+bidoZ5D6a9s1NhccRChvgbAKF1nc8BYj
Content-Type: multipart/related; boundary="_004_DBAPR06MB68554E5A6BFC73F52C6462A9B5899DBAPR06MB6855eurp_"; type="multipart/alternative"
MIME-Version: 1.0
X-OriginatorOrg: surrey.ac.uk
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: DBAPR06MB6855.eurprd06.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: d2f4fea2-2158-454d-774e-08db30274787
X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Mar 2023 07:29:06.4662 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 6b902693-1074-40aa-9e21-d89446a2ebb5
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: OB8lt+Igs4F3bmPoWrSgHurbq8TReZNVi5Bp8aPlMiPgYVEvHj2GL7cPnax0RMVwg/24FsYd1w8FxPHh2Sqedw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS5PR06MB8889
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmm/gM8EFcoplL8EwuftQCySBSIFYUM>
Subject: Re: [DMM] Emergency 911 Services over Wi-Fi
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Distributed Mobility Management Working Group <dmm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dmm>, <mailto:dmm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dmm/>
List-Post: <mailto:dmm@ietf.org>
List-Help: <mailto:dmm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmm>, <mailto:dmm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 29 Mar 2023 07:29:17 -0000

Hi Sri

A few comments <DL> in-line </DL>.

David

From: Sri Gundavelli (sgundave) <sgundave=40cisco.com@dmarc.ietf.org>
Date: Wednesday, 29 March 2023 at 10:34
To: Lake, David (PG/R - Comp Sci & Elec Eng) <d.lake@surrey.ac.uk>, dmm@ietf.org <dmm@ietf.org>
Subject: Re: [DMM] Emergency 911 Services over Wi-Fi
Hi David,

Thanks a lot for the feedback. I agree with the two key problems you have identified.  It is indeed about network selection; it is about temporary access and also about using emergency service configuration for use with the default dialer.


  *   Network attachment.   The solution with a roaming WiFi partner is good but we should also consider the ability to extend the concept of an ‘Emergency Attach’ to LTE/5GNR without the need for credentials (or with well-known credentials). This is made much more complex in the case of incoming roamers where 2G/3G has sunset – for example, if I visit the US now, I can be in a position where I get LTE/5G data service through a roaming partner but no IMS access.   Many international carriers also limit ‘home’ ePDG (‘WiFi Calling’) access.

There is support for emergency attach without expired SIM, or no SIM. Those mechanisms are supported. The focus of CSRIC 8 group is how to make that call work over Wi-Fi; this can be for Wi-Fi only capable device, or a dual radio capable device. For the latter case, the answer is always ePDG call, but that goes with the assumption the device is able to authenticate to the access network. We are solving that basic connectivity problem with OpenRoaming. A device with no access credentials, just with an emergency passpoint profile can perform an attach and make that emergency call. As you also say, what IMS configuration should the device use in such scenario where there is no mobile operator, is the other issue.

<DL> Given the number of ‘2nd number’ applications out there (Swytch, Vyke, etc.) if you have a Wifi connection then you’ll have phone service; just not through the M(v)NO!   My conclusion is that it is the 3GPP/IMS architecture that is wrong and needs to be simplified/changed to disassociate the application (voice/text) from the data pipe…. </DL>


  *   No matter how I attach to an IP network, I should be able to access the upper-layer application (which is essentially a SIP dialler) and make a 911 call.   I can’t because the dialler currently relies on IMS registration which then takes me straight back to the issues with IMS access, IMS-to-IMS roaming, non-availability of VoWiFi (via ePDG), etc.  Location SHOULD be available via GPS from the end device or from the IP path of the packets (knowing the location of the attached AP/gNB).

Yes, completely agree. The dialer should be access agnostic. That may be the case, but this needs to be qualified. Perhaps device vendors should do some testing and make sure the device can use the obtained emergency service configuration and make the call over the available access.

<DL> See above!  What has astonished me being here in Japan is that in common with other UK (and possibly European) carriers, Vodafone UK don’t allow me to use WiFi Calling at-all when roaming instead forcing me to use their very expensive (and poor quality) roaming interconnect.  I’m even dropped to circuit-switched for voice calls despite having an LTE service.

But my iMessage, WhatsApp, Signal and Swytch services work perfectly over LTE or WiFi.

So the dialer today is absolutely NOT access-agnostic and I am told that is by-design in 3GPP as it is the fact that I am a) not on my home PLMN and b) not in the UK by IP address (and there is VPN detection as well) disables the WiFi Calling access on a per-carrier profile basis.

The problem is made worse because there is no interworking between these disparate applications for calls and texts which means that I can end up with many separate dialers that can reach/are reachable by their own user groups.

I think what we need to be doing is unifying the applications over a common protocol (which is IP) and then disaggregating the service to providing interoperability.  That solves E911 and so much more and starts to move us away from the 3GPP architecture for all applications.  SIP is exactly the thing to do that but not the combination of SIP+IMS.

Obviously the issue then is that VoLTE/VoNR is able to manipulate the OTA to provide a better grade-of-service but we should be able to steer packets from any of the rich-media apps through a dedicated bearer if we can get the transport network to provide us with APIs to do so.  In fact, there would be benefit in opening-up the transport APIs to enable ANY application to request a higher-grade of service determined by required QoE.

</DL>

Location is a complex topic. The device can always use GPS source, but in many indoor environments GPS signal may be blocked. Secondly, we need to prevent rogue calls with incorrect location. We solve the location issue using the OpenRoaming IDP-ANP signaling, and with the use of Secure Location Tag.

<DL> Not my area of expertise at all so I gracefully step away 😊 </DL>

Regards
Sri



From: dmm <dmm-bounces@ietf.org> on behalf of David Lake <d.lake=40surrey.ac.uk@dmarc.ietf.org>
Date: Sunday, March 26, 2023 at 7:06 PM
To: "dmm@ietf.org" <dmm@ietf.org>
Subject: [DMM] Emergency 911 Services over Wi-Fi

Sri

Thank you for the interesting presentation.

I think we have two problems:


  1.  Network attachment
  2.  E911 calling via the inbuilt dialler

Taking each of these in turn:


  1.  Network attachment.   The solution with a roaming WiFi partner is good but we should also consider the ability to extend the concept of an ‘Emergency Attach’ to LTE/5GNR without the need for credentials (or with well-known credentials). This is made much more complex in the case of incoming roamers where 2G/3G has sunset – for example, if I visit the US now, I can be in a position where I get LTE/5G data service through a roaming partner but no IMS access.   Many international carriers also limit ‘home’ ePDG (‘WiFi Calling’) access.


  1.  No matter how I attach to an IP network, I should be able to access the upper-layer application (which is essentially a SIP dialler) and make a 911 call.   I can’t because the dialler currently relies on IMS registration which then takes me straight back to the issues with IMS access, IMS-to-IMS roaming, non-availability of VoWiFi (via ePDG), etc.  Location SHOULD be available via GPS from the end device or from the IP path of the packets (knowing the location of the attached AP/gNB).


I see 2) as the major issue to solve but I think this is a subset of the wider issue of relying on the 3GPP architecture for a voice applications.   If I use a non-IMS voice application (e.g. WhatsApp, iMessage, second-number services such as Swytch, etc), then as long as I have IP connectivity, I have the ability to make an E911 call (or in fact any other call).   So surely the answer is to decouple the application from the network in some manner such that it doesn’t have to make an IMS registration specifically for E911/112/999 calls but instead uses generic SIP (maybe with default/well-known credentials)?

Best

David Lake

Tel: +44 (0)7711 736784
[Text  Description automatically generated with low confidence]
5G & 6G Innovation Centres
Institute for Communication Systems (ICS)
University of Surrey
Guildford
GU2 7XH