Subject: Re: [Ecrit] Comments on Framework Draft

From: "Edge, Stephen" <[email-masked]>
Date: Thu, 26 Feb 2009 20:30:14 -0800

Hi Richard

Thanks for the comments. Your statement below that "SIP emergency calling works if all parties behave as specified in these (IETF Ecrit) documents" to some degree highlights the problems we are raising. The documents do contain a number of implicit and explicit restrictions - like IP capable PSAPs, global IP access (no islands of circuit mode access for example), universal support of this solution by all access providers and VSPs (not much good if some opt for another solution) and end system oriented location and routing capability - which together make them unsuitable (we believe) for cellular wireless networks. If these restrictions and assumptions were all made explicit upfront, it would to a large degree (and possibly completely) address our concerns.  

You are right in assuming another set of specifications for the 3GPP and 3GPP2 solution. The applicability of this solution is explicitly defined in TS 23.167 (or more exactly in an already agreed CR in contribution S2-090752 which will become part of 23.167 in a few more weeks) to cover the following access types: GPRS (UTRAN WCDMA), I-WLAN, Fixed Broadband, CDMA2000 HRPD, EPS UTRAN (WCDMA) and EPS E-UTRAN (LTE). So there is a restriction and arbitrary internet access is not covered (yet) as I have stated before.

Kind Regards

Stephen
-----Original Message-----
From: Richard Barnes [mailto:[email-masked]] 
Sent: Wednesday, February 25, 2009 6:30 PM
To: Edge, Stephen
Cc: Brian Rosen; 'ECRIT'
Subject: Re: [Ecrit] Comments on Framework Draft

Hi Stephen,

I'm a little confused by the scope of what you're asking.  The framework 
and phonebcp documents exist in order to describe the ECRIT solution: 
They say, in effect, "SIP emergency calling works if all parties behave 
as specified in these documents."

As I understand what you're saying (and I'm by no means an expert in 
3GPP), 3GPP specifies that one or more elements of this system behave 
differently.  This simply means that 3GPP networks aren't complying with 
these specs.  Just like there's no disclaimer in RFC 791 (IPv4) that 
says "this doesn't work on X.25 networks", it's not clear to me that an 
analogous disclaimer is called for here.

I presume there are similar documents describing how emergency calling 
works in 3GPP networks.  Do they include notes saying that the 3GPP 
solution doesn't work in the broader Internet?

--Richard

Edge, Stephen wrote:
> Brian
> 
> First of all apologies for the likely lateness of this reply - I actually wrote it on 19 February in a 3GPP SA2 meeting in Budapest but it seems unlikely that my VPN, Outlook server and WiFi access capability will cooperate together to get it sent until I return to the office mid-next week.
> 
> Anyhow thanks for your comments. There have actually been a number of conference calls between IETF and 3GPP participants over the last couple of years at which common features like support of IP emergency calls were discussed and these could have been good forum for participants on either side to have raised the kinds of issues you elaborate on below. Given that seems not so far to have happened, it could still be possible in future such calls.
> 
> But the issues we are raising are not directly to do with further aligning the 2 solutions or with the lack of this in the past. We are simply pointing out that the solutions are currently different and that from a cellular wireless perspective, the Ecrit solution is not seen as suitable in all respects (for support of IP emergency calls originating from such access types). That is not just our point of view. 3GPP2 sent a liaison to Ecrit some months ago pointing out the same issues.
> 
> So we are proposing that the Ecrit framework and phoneBCP spec.s include a statement acknowledging this - e.g. by referencing the alternative 3GPP/3GPP2 solution and indicating the IP access types for which the Ecrit solution will work without limitation (or equivalently the access types where limitations are not ruled out).
> 
> We are not proposing further modification and extension of the Ecrit solution - just pointing out that this would be needed (as with the 3GPP/3GPP2 solution) to fully cover all types of access.
> 
> Kind Regards 
> 
> Stephen
> -----Original Message-----
> From: Brian Rosen [mailto:[email-masked]] 
> Sent: Wednesday, February 18, 2009 8:07 PM
> To: Edge, Stephen; 'ECRIT'
> Subject: RE: [Ecrit] Comments on Framework Draft
> 
> I have bit my tongue on this one for a long time.
> 
> Stephen, with respect, please go talk to 3GPP management and ask them  why
> there has been no participation in the ecrit effort despite multiple YEARS
> of begging them to get involved.  To put it frankly, 3GPP is quite willing
> to bully IETF into doing its work on its schedule, but cannot be bothered to
> get work done it knows it will eventually have to do when the IETF asks it
> to do so.
> 
> 3GPP understands the mess that is being created by not participating.  They
> know full well that when they finally get around to dealing with PS
> terminated emergency calls, that there will be a lot of resistance to
> changing fully specified and implemented standards to more closely align
> with 3GPP standards.  I expect you will have several interworking functions
> to define and build.
> 
> So, politely, please go away, we're finishing work we dearly wanted you all
> to be involved with for years, but you refused to do anything.  It's too
> late for this rev.
> 
> Now, having said that, there are quite a few people who have participated in
> the IETF work who are IMS aware and I believe that despite your fears,
> everything you need is in the specs.  The mechanisms we have defined provide
> the ability for the network to insert location, recognize and mark emergency
> calls, and route on behalf of endpoints.  An E-CSCF could quite
> straightforwardly provide a SIP call towards an ecrit compatible PSAP.  The
> only not-quite-nice interwork would be from SUPL to HELD (or SIP), but it's
> pretty easy to do that.  I'll also note that we have tried to get OMA and
> IETF to cooperate on location protocols, but we have been spectacularly
> unsuccessful at that effort also.
> 
> Brian
> 
>   
> 
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]] On Behalf
>> Of Edge, Stephen
>> Sent: Thursday, February 05, 2009 2:50 AM
>> To: 'ECRIT'
>> Subject: [Ecrit] Comments on Framework Draft
>>
>> All
>>
>> draft-ietf-ecrit-framework-07 is (as we see it) a mostly informative
>> description of how terminals and networks should support emergency
>> calls made over IP capable facilities to IP capable PSAPs. It appears
>> intended to cover all types of access network - including fixed line,
>> WiFi and cellular (e.g. examples involving each can be found throughout
>> the draft).
>>
>> When we evaluated this with respect to support of wireless cellular
>> access and WiFi access associated with a cellular operator (e.g. WLAN
>> or Femto cells integrated into a cellular network), we found that
>> certain portions of the draft exhibited one or more of the following
>> characteristics:
>>
>>     (A) Inconsistent with already standardized wireless solutions
>>
>>     (B) Inconsistent with essential wireless requirements and
>> conventions
>>
>>     (C) Already part of wireless standards or potentially part of
>> future standards
>>
>> (A) refers to all portions of the draft framework that differ from the
>> requirements and procedures currently standardized for wireless
>> emergency access by 3GPP, 3GPP2 and OMA. This is a plain difference of
>> solution and could be resolved through support of both solutions by
>> terminals (with each solution being used according to the type of
>> access network and VSP) or could be resolved by supporting only one
>> solution and accessing only the types of network supporting that
>> solution. To acknowledge this category, the framework document could
>> reference the applicable wireless standards and point out that these
>> are valid alternatives for wireless cellular based access.
>>
>> (B) refers to portions of the draft that would be unsuitable for
>> wireless networks even if no alternative solution existed together with
>> other portions missing from the draft that would be needed to fully
>> support wireless networks. Examples of the former include: (a) emphasis
>> on endpoint derivation of location, performance of Lost query and
>> receipt of local dial strings; (b) restriction of LCPs to protocols
>> that require terminal initiation (not allowing for network initiation
>> as far as we can tell) and that include two LCPs (DHCP and LLDP) that
>> are not applicable to (not defined for) cellular access; and (c) the
>> requirement that a terminal or at least a LIS will update the PSAP
>> whenever location changes. (a) is impractical due to network and
>> terminal loading consequences and failure to support non-IP capable
>> PSAPs; (b) makes location verification and updated location provision
>> to PSAPs difficult or impossible; while (c) is also incompatible with
>> support of existing non-IP capable PSAPs besides increasing terminal
>> load and possibly interfering with optimum maintenance of the RF
>> connection (e.g. if a terminal has to tune away from the serving base
>> station or WLAN periodically to make location measurements). Examples
>> of the latter include (d) absence of support for access to non-IP
>> capable PSAPs as already mentioned (e.g. to support E911 phase 2 in the
>> US); (e) no support for handover from the IP to the circuit domain when
>> a terminal loses (e.g. moves out of) RF coverage in the IP domain; and
>> (f) no allowance for limited access modes wherein a terminal may access
>> a network only to place an emergency call with ensuing restrictions on
>> (for example) location acquisition, PSAP callback and caller
>> verification and identification to the PSAP. To resolve this category
>> either significant changes to the framework document could be made or a
>> disclaimer/applicability statement could be added stating that support
>> of cellular wireless networks and their associated WLAN and Femto
>> access points is not covered.
>>
>> Category (C) comprises concepts and capabilities in the draft that are
>> either already part of the standardized solution for wireless networks
>> or that might be added at a later time. Examples of the former include
>> LoST, SIP location conveyance, general use of SIP, location for routing
>> versus for dispatch, cellular positioning methods. Examples of the
>> latter include use of location references and dereferencing and
>> possible interworking between the current wireless network solutions
>> (in 3GPP, 3GPP2 and OMA) and the solution described in this draft. The
>> presence of this category could be acknowledged by following the
>> disclaimer for (B) with a statement that certain portions of the
>> solution are expected to be incorporated into wireless networks now
>> and/or in the future.
>>
>> We hope that these comments will be seen to be a useful addition to
>> this review in the sense of enabling a more precise scoping for the
>> framework document and we are willing to assist in providing wording
>> for any disclaimer/applicability statement that the Ecrit working group
>> may now deem fit to include.
>>
>> Kind Regards
>>
>> Stephen Edge (Qualcomm 3GPP SA2 participant), Kirk Burroughs (Qualcomm
>> 3GPP2 TSG-X and TSG-C participant)
>>
>> PS  this being sent on 2/4/09 at 11:50pm PST
>>
>> _______________________________________________
>> Ecrit mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/ecrit
> 
> _______________________________________________
> Ecrit mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ecrit
>

---

From: "Edge, Stephen" <[email-masked]>
Date: Thu, 26 Feb 2009 21:38:22 -0800

Hi James

Thanks for these further comments and for this oft repeated example - namely use of a 3GPP or 3GPP2 IP access network to reach a non-3GPP/3GPP2 VSP. This is always being thrown up as a reason that the 3GPP/3GPP2 solution cannot even fully address its own calling scenarios. It is however incomplete for the following reasons.

First of all, I doubt that in this example either the Ecrit or 3GPP/3GPP2 solution would actually be possible now since neither are fully defined or fully implemented yet. Perhaps the VSP would provide some rudimentary E911 capability though probably not to the right PSAP. So the example is more hypothetical for future implementation in which case either solution might be considered.

Maybe you are aware that CDMA EvDO providers will be obligated by the FCC in the US to provide E911 capability assuming they are using licensed spectrum. So in this example, and in a few more years when the 3GPP/3GPP2 solution has been fully defined and implemented, the device in question would be able to access the CDMA EvDO network, assuming it recognized the dialed emergency number and supported the 3GPP/3GPP2 solution, and make an IP based E911 call directly via the serving EvDO network and not via its normal VSP. If it did not recognize the dialed emergency number or chose to use the normal VSP anyway but still supported the 3GPP/3GPP2 solution, then the VSP (e.g. based on receiving some access network related information from the device in the SIP INVITE such as an EvDO cell ID and possibly based on subscription information if needed to imply 3GPP/3GPP2 capability for the device) could send an error response back to the device (a SIP 380 response with an emergency indication) that would cause the device to redirect the call to the EvDO serving network. If the device did not support the 3GPP/3GPP2 solution, this would not work - but it seems unreasonable to treat non-support of a solution as a weakness since almost every solution is susceptible to this.

The above would not prevent the VSP from employing the Ecrit solution for other types of access not supporting the 3GPP/3GPP2 solution and the incremental cost to the VSP of supporting the 3GPP/3GPP2 solution (by means of the 380 response) ought to be small.

The one case I have omitted but which I assume you may specifically have in mind is where the device only supports IP data access and acts as a router on behalf of another end device (e.g. a laptop). In that case, I think both solutions would be severely handicapped. The Ecrit solution would have a hard time obtaining location (unless the end device already had an accurate location fix which it included in the SIP INVITE) and in routing to a PSTN capable PSAP (particularly one in another country). The 3GPP/3GPP2 solution - assuming the VSP supported it - might find location easier (e.g. if the router or end device supported SUPL since that would allow location for dispatch subsequent to call routing), but would find PSTN PSAP routing just as hard.

The parts of the Ecrit solution that appear unsuitable for cellular networks I have already elaborated on - e.g. endpoint oriented location and routing, no explicit cellular location capability, no explicit support for PSAPs accessed over the PSTN (the NENA i2 solution is not a global standard and seems impractical where a PSAP is very remote from the VSP), no consideration for handover to or from circuit mode access (which will remain the norm for many years) or even to/from other IP access networks.

Kind Regards

Stephen
-----Original Message-----
From: Winterbottom, James [mailto:[email-masked]]
Sent: Wednesday, February 25, 2009 8:48 PM
To: Edge, Stephen; Brian Rosen; ECRIT
Subject: RE: [Ecrit] Comments on Framework Draft

Hi Stephen,

It is a pity that you were not in the NENA location WG meeting in Orlando last week, as we had a very pertinent example put forward.

The example was a guy with a CDMA EVDO capable device, he is able to establish a VPN connection back into his corporate network and then make VoIP calls. The gentleman in question claims that he does this regularly. If he were to make an emergency call would it be following the ECRIT or 3GPP2 call flows?

The answer is that the call flow follows the ECRIT flow but the access is CDMA EVDO, clearly 3GPP2, and clearly cellular! Ipso facto ECRIT on cellular works!

I don't believe that anybody that understands the ECRIT architecture and has a notion of what products are being sold and used today can seriously suggest that the ECRIT architecture doesn't work for a cellular network. The fact that home routers with 3G Internet connections are being sold is an indicator that the 3G service is just another access to the Internet and that VoIP over 3G is being used and that ECRIT over 3G is quite possible.

Perhaps it would be pertinent at this time to ask precisely which bits of the ECRIT architecture you feel are unworkable in a 3GPP/2 network?

Cheers
James

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Edge, Stephen
Sent: Thursday, 26 February 2009 1:11 PM
To: Brian Rosen; 'ECRIT'
Subject: Re: [Ecrit] Comments on Framework Draft

Brian

Kind Regards

Stephen
-----Original Message-----
From: Brian Rosen [mailto:[email-masked]]
Sent: Wednesday, February 18, 2009 8:07 PM
To: Edge, Stephen; 'ECRIT'
Subject: RE: [Ecrit] Comments on Framework Draft

Brian

------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.
If you have received it in error, please notify the sender
immediately and delete the original.  Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]

---

From: "Thomson, Martin" <[email-masked]>
Date: Thu, 26 Feb 2009 23:44:37 -0600

There's benefit in knowing the limitations of a framework, and every architecture makes certain assumptions.  Let's examine them though...

The IETF might occasionally make the assumption that the standards it develops are for Internet devices.  That assumption probably need not be stated explicitly.

The ECRIT architecture relies on implementations of the protocols that it references.  That is not extraordinary.  A reliance on implementation of these protocols by endpoints, routing intermediaries and PSAPs should not need to be explained.

So the assumptions are:
 - the Internet
 - solutions are implemented and deployed
 - the end device is a key component

Only that last element is particularly novel ... or not that much really.    It's a design choice.  Unless you were thinking of trunking the voice elsewhere.

Of course, you're suggesting that the design choice was made in ignorance of all the constraints.  You're suggesting that - as a result - the choice is flawed and the solution is not going to work for cellular services.  We disagree.  The solution is a basis for emergency calling in _any_ IP network.

Cheers,
Martin

> Sent: Friday, 27 February 2009 3:30 PM
> To: Richard Barnes
> Cc: 'ECRIT'
> Thanks for the comments. Your statement below that "SIP emergency
> calling works if all parties behave as specified in these (IETF Ecrit)
> documents" to some degree highlights the problems we are raising. The
> documents do contain a number of implicit and explicit restrictions -
> like IP capable PSAPs, global IP access (no islands of circuit mode
> access for example), universal support of this solution by all access
> providers and VSPs (not much good if some opt for another solution) and
> end system oriented location and routing capability - which together
> make them unsuitable (we believe) for cellular wireless networks. If
> these restrictions and assumptions were all made explicit upfront, it
> would to a large degree (and possibly completely) address our concerns.
> 
> You are right in assuming another set of specifications for the 3GPP
> and 3GPP2 solution. The applicability of this solution is explicitly
> defined in TS 23.167 (or more exactly in an already agreed CR in
> contribution S2-090752 which will become part of 23.167 in a few more
> weeks) to cover the following access types: GPRS (UTRAN WCDMA), I-WLAN,
> Fixed Broadband, CDMA2000 HRPD, EPS UTRAN (WCDMA) and EPS E-UTRAN
> (LTE). So there is a restriction and arbitrary internet access is not
> covered (yet) as I have stated before.
> 
> Kind Regards
> 
> Stephen
> > First of all apologies for the likely lateness of this reply - I
> actually wrote it on 19 February in a 3GPP SA2 meeting in Budapest but
> it seems unlikely that my VPN, Outlook server and WiFi access
> capability will cooperate together to get it sent until I return to the
> office mid-next week.
> >
> > Anyhow thanks for your comments. There have actually been a number of
> conference calls between IETF and 3GPP participants over the last
> couple of years at which common features like support of IP emergency
> calls were discussed and these could have been good forum for
> participants on either side to have raised the kinds of issues you
> elaborate on below. Given that seems not so far to have happened, it
> could still be possible in future such calls.
> >
> > But the issues we are raising are not directly to do with further
> aligning the 2 solutions or with the lack of this in the past. We are
> simply pointing out that the solutions are currently different and that
> from a cellular wireless perspective, the Ecrit solution is not seen as
> suitable in all respects (for support of IP emergency calls originating
> from such access types). That is not just our point of view. 3GPP2 sent
> a liaison to Ecrit some months ago pointing out the same issues.
> >
> > So we are proposing that the Ecrit framework and phoneBCP spec.s
> include a statement acknowledging this - e.g. by referencing the
> alternative 3GPP/3GPP2 solution and indicating the IP access types for
> which the Ecrit solution will work without limitation (or equivalently
> the access types where limitations are not ruled out).
> >
> > We are not proposing further modification and extension of the Ecrit
> solution - just pointing out that this would be needed (as with the
> 3GPP/3GPP2 solution) to fully cover all types of access.
> >
> > Kind Regards
> >
> > Stephen

---

From: "Edge, Stephen" <[email-masked]>
Date: Thu, 26 Feb 2009 23:50:41 -0800

Martin

The 3GPP/3GPP2 solution has a defined restricted applicability (mainly to 3GPP/3GPP2 access networks where the serving network also acts as the VSP) and the specifications for it cover in detail all possible scenarios consistent with these restrictions so far as we are aware.

The Ecrit solution seems to claim global applicability to all types of IP access (and the more that is said about this from Ecrit participants the more this gets emphasized) but does not cover in detail all possible scenarios (in some cases does not cover in any detail) which means that at best the solution is incomplete and at worst intrinsically inapplicable to some unstated set of scenarios.

The missing, incomplete and problematic cases include the following:

  - access to PSTN capable PSAPs
  - handover between different IP access networks including different types of access network
  - handover to/from circuit mode networks
  - location for cellular access (and the requirement to support LCPs that will be useless for cellular access)
  - endpoint based location and routing for cellular access (issues here are network and device loading as well as device impacts and problems with PSTN capable PSAPs)
  - support of unauthenticated users and users who can be authenticated but are not permitted access/VSP service except for emergency calls

Stating that some of these cases are out of scope or referencing an incomplete and possibly questionable specification from some other national SDO will not help the user who encounters such problems. But it would certainly help network operators and implementers to acknowledge their existence in one form or another because that would allow better planning of deployments and would help focus attention on finding solutions (whether in IETF or elsewhere) for the missing cases.

Please note that despite these drawbacks, I will acknowledge that Ecrit does have a valuable solution that covers many scenarios not covered by 3GPP/3GPP2. It would be the delineation of these supported scenarios (or equivalently unsupported scenarios) in some applicability statement that would be particularly useful right now.

Kind Regards

Stephen
-----Original Message-----
From: Thomson, Martin [mailto:[email-masked]]
Sent: Thursday, February 26, 2009 9:45 PM
To: Edge, Stephen; Richard Barnes
Cc: ECRIT
Subject: RE: [Ecrit] Comments on Framework Draft

So the assumptions are:
 - the Internet

Cheers,
Martin

---

From: [email-masked]
Date: Fri, 27 Feb 2009 08:52:32 -0600 (CST)

Stephen

Like any standards organization, the IETF restricts it's scope. 
Generally, the scope is "the Internet", although we very often describe
solutions that are explicitly designed for private IP networks as well as
the Internet.  We don't write standards for circuit switched networks, and
it should be no surprise that the ecrit solution does not cater to CS
solutions.  Nevertheless, we often try to make sure that our solutions
harmonize reasonably well with existing solutions.

Indeed, the ecrit solution clains global applicability to the Internet in
general, and most private IP networks that can be interconnected to the
Internet or to other IP networks via gateways.  Looking at your list of
>   - access to PSTN capable PSAPs
This is out of scope for IETF.  NENA has active work on this subject.  It
seems straightforward to interwork ecrit compatible devices and networks
to existing CS connected PSAPs.  As you know, CS interconnects are very
nation-specific, so the NENA work may not have general applicability. 
However, it shows that it is possible to interwork.  The NENA i2 work is
also designed to take ecrit compatible devices and VSP networks, and
interwork them to the existing network.  The VSP would direct the call to
the VPC, which would provide the services it does now, using the device
provided location for routing.  This is important for smooth transition
from existing PSAPs and VSPs to "next generation" PSAPs and VSPs.
>   - handover between different IP access networks including different
In the ecrit solution, the access network the call is initiated on
provides all the facilities needed for the device to initiate an emergency
call.   The call starts traversing it's normal call path, and eventually
routes to the ESRP.  Handoffs between IP networks should be transparent to
this process, although we probably haven't done all the work we need to do
for handoffs where the IP address as seen by the terminating network
changes.  This would generally be true of all current SIP based work.
>   - handover to/from circuit mode networks
This would be out of scope for IETF.  It's as applicable to a simple SIP
call as it is a SIP emergency call, and there are no statements in any SIP
documents on that subject.
> will be useless for cellular access)
Location for cellular access networks has been considered carefully. 
Since cellular is a mobile network, the access network would pass the
device a Location-By-Reference URI, using either DHCP or HELD.  Either
protocol is suitable for cellular networks.  As we have pointed out
several times, cellular networks support raw data packet services upon
which many different kinds of networks can be constructed.  My usual
example is a large recreational vehicle traveling down a road with a
cellular data card plugged into a router to which a wired (Ethernet) phone
is connected.  That phone must be able to make an emergency call, and it
will get location from DHCP or HELD (or LLDP-MED).  It is not aware of the
cellular network, and doesn't know any cellular specific protocols. 
Cellular networks will have to support IETF location configuration
protocols unless they actively prohibit examples like this, or they
implement interworking between cellular-specific location protocols and
DHCP or HELD in the data card.  The ecrit standards permit proxy insertion
of location, but, as above, we don't think that works in all cases.
>   - endpoint based location and routing for cellular access (issues here
> are network and device loading as well as device impacts and problems
> with PSTN capable PSAPs)
The "load" of using DHCP or HELD to get location and querying LoST is
pretty modest.  The standards permit proxies to do this if the devices
don't.  As above, interwork functions to CS connected PSAPs is very
feasible, and as above, cellular networks will have to support access to
local LoST servers for devices that are connected to cellular networks and
are ecrit compliant.
>   - support of unauthenticated users and users who can be authenticated
> but are not permitted access/VSP service except for emergency calls
This is covered in the standards.  None of the processes are dependent on
authentication, although where it is possible, it's desirable so as to
minimize fraudulent emergency calls
Mechanisms for specific network authentication mechanisms are out of
scope, and, like SIP basic calling, are not usually mentioned in IETF
documents.

Stephen, we've tried pretty hard to make sure this works for 3G/4G mobile
networks.  It's true that it doesn't do it the way 3GPP currently thinks
it ought to work, but we claim they haven't thought through all the
issues.  While it would work, there are opportunities for improvement.  We
would be willing to do that if we could get the cooperation of 3GPP, which
we have tried, and failed, to do.

So, I think the documents do not need any qualification statements.

Brian

> Martin
>
> The 3GPP/3GPP2 solution has a defined restricted applicability (mainly to
> 3GPP/3GPP2 access networks where the serving network also acts as the VSP)
> and the specifications for it cover in detail all possible scenarios
> consistent with these restrictions so far as we are aware.
>
> The Ecrit solution seems to claim global applicability to all types of IP
> access (and the more that is said about this from Ecrit participants the
> more this gets emphasized) but does not cover in detail all possible
> scenarios (in some cases does not cover in any detail) which means that at
> best the solution is incomplete and at worst intrinsically inapplicable to
> some unstated set of scenarios.
>
>   - endpoint based location and routing for cellular access (issues here
> are network and device loading as well as device impacts and problems
> with PSTN capable PSAPs)
>   - support of unauthenticated users and users who can be authenticated
> but are not permitted access/VSP service except for emergency calls
>
> Stating that some of these cases are out of scope or referencing an
> incomplete and possibly questionable specification from some other
> national SDO will not help the user who encounters such problems. But it
> would certainly help network operators and implementers to acknowledge
> their existence in one form or another because that would allow better
> planning of deployments and would help focus attention on finding
> solutions (whether in IETF or elsewhere) for the missing cases.
>
> Please note that despite these drawbacks, I will acknowledge that Ecrit
> does have a valuable solution that covers many scenarios not covered by
> 3GPP/3GPP2. It would be the delineation of these supported scenarios (or
> equivalently unsupported scenarios) in some applicability statement that
> would be particularly useful right now.
>
> Kind Regards
>
> Stephen
> There's benefit in knowing the limitations of a framework, and every
> architecture makes certain assumptions.  Let's examine them though...
>
> The IETF might occasionally make the assumption that the standards it
> develops are for Internet devices.  That assumption probably need not be
> stated explicitly.
>
> The ECRIT architecture relies on implementations of the protocols that it
> references.  That is not extraordinary.  A reliance on implementation of
> these protocols by endpoints, routing intermediaries and PSAPs should not
> need to be explained.
>
> So the assumptions are:
>  - the Internet
> Only that last element is particularly novel ... or not that much really.
>   It's a design choice.  Unless you were thinking of trunking the voice
> elsewhere.
>
> Of course, you're suggesting that the design choice was made in ignorance
> of all the constraints.  You're suggesting that - as a result - the choice
> is flawed and the solution is not going to work for cellular services.  We
> disagree.  The solution is a basis for emergency calling in _any_ IP
> network.
>
> Cheers,
> Martin
>
>

---

From: "Stark, Barbara" <[email-masked]>
Date: Fri, 27 Feb 2009 11:28:10 -0500

Thank you Brian. This is well said [except you left out the fact that
ecrit also allows for devices to get their location through other
mechanisms, such as GPS, SUPL, or other methods, and doesn't insist that
the location be configured through DHCP or HELD].

I agree 100% that additional qualifications are unnecessary. Service
providers, vendors, national bodies dealing with emergency services, and
regulators aren't stupid. Please trust us to figure out for ourselves
when/where/how to apply a "standard". There is no need to try to
artificially limit or define scope, or to state the obvious (e.g., the
architecture applies where it applies, and doesn't apply where it
doesn't apply). We understand the role and scope of the IETF, and the
role and scope of 3GPP and 3GPP2. And all the other SDOs (and national
bodies and regulatory agencies). SDOs need to offer architectures that
apply within the area of applicability for that SDO, and are useful to
potential implementers, and leave it to the SPs, national bodies and
regulators to decide which architectures and standards to use or to
mandate within the scope of their network or jurisdiction. Again, we
aren't stupid.
Barbara

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of [email-masked]
Sent: Friday, February 27, 2009 9:53 AM
To: Edge, Stephen
Cc: ECRIT
Subject: Re: [Ecrit] Comments on Framework Draft

Stephen

Like any standards organization, the IETF restricts it's scope. 
Generally, the scope is "the Internet", although we very often describe
solutions that are explicitly designed for private IP networks as well
as
the Internet.  We don't write standards for circuit switched networks,
and
it should be no surprise that the ecrit solution does not cater to CS
solutions.  Nevertheless, we often try to make sure that our solutions
harmonize reasonably well with existing solutions.

Indeed, the ecrit solution clains global applicability to the Internet
in
general, and most private IP networks that can be interconnected to the
Internet or to other IP networks via gateways.  Looking at your list of
>   - access to PSTN capable PSAPs
This is out of scope for IETF.  NENA has active work on this subject.
It
interwork them to the existing network.  The VSP would direct the call
to
In the ecrit solution, the access network the call is initiated on
provides all the facilities needed for the device to initiate an
emergency
call.   The call starts traversing it's normal call path, and eventually
routes to the ESRP.  Handoffs between IP networks should be transparent
to
this process, although we probably haven't done all the work we need to
do
for handoffs where the IP address as seen by the terminating network
changes.  This would generally be true of all current SIP based work.
This would be out of scope for IETF.  It's as applicable to a simple SIP
call as it is a SIP emergency call, and there are no statements in any
SIP
documents on that subject.
>   - location for cellular access (and the requirement to support LCPs
that
> will be useless for cellular access)
cellular data card plugged into a router to which a wired (Ethernet)
phone
will get location from DHCP or HELD (or LLDP-MED).  It is not aware of
the
DHCP or HELD in the data card.  The ecrit standards permit proxy
insertion
local LoST servers for devices that are connected to cellular networks
and
are ecrit compliant.
> but are not permitted access/VSP service except for emergency calls
This is covered in the standards.  None of the processes are dependent
on

Stephen, we've tried pretty hard to make sure this works for 3G/4G
mobile
networks.  It's true that it doesn't do it the way 3GPP currently thinks
it ought to work, but we claim they haven't thought through all the
issues.  While it would work, there are opportunities for improvement.
We
would be willing to do that if we could get the cooperation of 3GPP,
which
we have tried, and failed, to do.

Brian

>   - location for cellular access (and the requirement to support LCPs
that
> will be useless for cellular access)
>> > Stephen, with respect, please go talk to 3GPP management and ask
them
>> why
>> > there has been no participation in the ecrit effort despite
multiple
>> YEARS
>> > 3GPP understands the mess that is being created by not
participating.
>> They
>> > to be involved with for years, but you refused to do anything.
It's
>> too
>> > everything you need is in the specs.  The mechanisms we have
defined
>> provide
>> > pretty easy to do that.  I'll also note that we have tried to get
OMA
>> and
>> >> emergency access by 3GPP, 3GPP2 and OMA. This is a plain
difference
>> of
>> >> capable PSAPs as already mentioned (e.g. to support E911 phase 2
in
>> the
>> >> a network only to place an emergency call with ensuing
restrictions
>> on
------------------------------------------------------------------------
------------------------
> this email is prohibited.
------------------------------------------------------------------------
------------------------

*****

The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA621