Subject: Re: [Ecrit] Comments on Framework Draft

From: "Winterbottom, James" <[email-masked]>
Date: Sun, 1 Mar 2009 23:04:22 -0600

Hi Stephen,

I have the distinct impression that we are never going to agree on this
subject, I would however like to point out some statements in text below
that are either misleading, or at least able to be interpreted in an
alternative manner than that which is provided.

Please inline.

Cheers

James

-----Original Message-----
From: Edge, Stephen [mailto:[email-masked]] 
Sent: Friday, 27 February 2009 4:38 PM
To: Winterbottom, James; Brian Rosen; ECRIT
Subject: RE: [Ecrit] Comments on Framework Draft

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.

[AJW] Let's agree to disagree on this point, it is a stated requirement
in TS23.167 (requirement 2 under section 4.1) that "Emergency services
are independent from the IP-CAN with respect to the detection and
routing of emergency sessions. The emergency services shall be possible
over at least a cellular access network, a fixed broadband access,
I-WLAN access and a nomadic access."

I think, therefore that the solution is actually perfectly valid, the
3GPP network is the IPCAN and it must allow independent detection and
routing of the emergency call. This requirement falls short of what some
legislative bodies are now considering the duty of the IPCAN to be, but
it is still a good start.

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.

[AJW] This is true for ECRIT in that LoST servers are not widely
deployed and publically available. However there are certainly NENA i2
deployments being tested (not sure if they are actually live yet) where
the  originating call includes a PIDF-LO in the body with the call, and
the VSP in conjunction with a VPC can route the emergency call to the
correct PSAP. I fully expect this to happen in cases where the Internet
pipe is 3G so let's agree that this is not hypothetical. 

I am aware of two countries that are currently in the process or about
to begin the process of legislating Internet access providers to make
location available for the purpose of routing emergency Internet calls.
It will be interesting to see what impact this legislation has on 3G
data only devices and associated network operators, presumably they will
need to comply with the Internet access provider legislation or stop
providing, I think that it is more likely that they will comply.

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.

[AJW] Martin, Brian and possibly Richard have already described a
serious flaw in this line of thinking. Namely that if I have a 3G
Internet router, any device behind that router has absolutely no
visibility that it needs to talk to a different VSP, the solution you
are proposing almost suggests therefore that the wireless router
requires E-CSCF functionality in it and that it can detect when a device
in the home network is making an emergency call. This is very intrusive
and certainly not backward compatible with the legacy devices already
deployed. 

 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.

[AJW] Any device behind a home 3G router will have no visibility of the
connected cell-id. Cell-ID is also of almost no use to anyone but the
operator of the access network, so including this in a call to a VSP
that knows nothing about EVDO, let along a specific access provider
seems almost as big a stretch as universal SUPL roaming. Why not simply
make the location available to the caller using the mechanisms described
in GeoPriv? Once this is done you have ECRIT, i2, or i3 and they will
just work! 

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.

[AJW] The argument again is that device may not know about the
underlying dependency between access and service and in a number of
circumstances it absolutely will not know. The device might be able to
learn the address of the local ES-Proxy, but if you are going to employ
that solution why not just employ an option to discover the LIS and the
LoST server?

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

[AJW] Let's agree to disagree on this point. The 3GPP access behind the
router is the Internet access provider and will likely have to provide
location to the device. We have got pretty good LIS discovery mechanisms
described in Geopriv that address most major concerns, so actually I
believe that ECRIT and NENA i2 will work quite well.

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.

[AJW] I think you will find that the WiMAX forum disagrees you with on a
number of these points. And I have absolutely no doubt that with the 1.5
version of WiMAX I can support a fully mobile IP network using the ECRIT
emergency calling architecture. 

I am not sure that I understand what you mean by "no explicit cellular
location capability", perhaps you can explain. Certainly using a
protocol such as HELD I can an awful lot and it all remains local so it
doesn't require a world in a database to support roaming such as is
required in some protocols that we will not mention here...;)

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

[AJW] You are right that NENA i2 is not a global standard, but it is
being tailored for deployment in at least 3 countries at I am aware of,
and forms the basis for discussion in a number of others.

I agree that circuit mode devices will be around for a many years to
come, I am less convinced that they will remain the norm, and with data
only devices increasing in popularity I see the need to hand-over in the
way you describe as unnecessary. Indeed I see it as a technological
mismatch, equivalent to being able to hand-over my GSM call to a CDMA
network; Without a special, purpose-built device I can't do it. Delivery
of calls from VoIP to circuit switched PSTN and vice versa is common
place today from any number of voice service providers and this is the
mode of operation we should be discussing.  

Kind Regards

Stephen

------------------------------------------------------------------------------------------------
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: "Brian Rosen" <[email-masked]>
Date: Mon, 2 Mar 2009 11:23:03 -0500

I’m also certain we’re not going to converge, but let me step up a level and
observe that there is a fundamental flaw with the current cellular emergency
call architecture: The assumption that the access network always provides
emergency calling services, which is also related to the assumption that the
home and visited networks have a contractual relationship.  

This is flawed even for 3GPP IMS networks that are fixed.  They assume
"nomadic" services that are provided by the home network, including
emergency calling, and where there may not be a relationship between the
access network and the calling network.  It's also true of services that a
cellular network does not provide, but does provide the raw packet access.
AOL/MSN/Yahoo Instant Messaging for example, or Skype.

The ecrit architecture does not make this assumption.  

When the home network provides emergency services, then you may have to get
location from the access network, and send it via the home network.  The
device is the customer of both the access network and the calling network,
which is why the ecrit architecture works, and the current IMS architecture
does not.

Brian

From: Winterbottom, James [mailto:[email-masked]] 
Sent: Monday, March 02, 2009 12:04 AM
To: Edge, Stephen; Brian Rosen; ECRIT
Subject: RE: [Ecrit] Comments on Framework Draft

Hi Stephen,

Please inline.

Cheers
James

-----Original Message-----
From: Edge, Stephen [mailto:[email-masked]] 
Sent: Friday, 27 February 2009 4:38 PM
To: Winterbottom, James; Brian Rosen; ECRIT
Subject: RE: [Ecrit] Comments on Framework Draft

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.

[AJW] Let’s agree to disagree on this point, it is a stated requirement in
TS23.167 (requirement 2 under section 4.1) that “Emergency services are
independent from the IP-CAN with respect to the detection and routing of
emergency sessions. The emergency services shall be possible over at least a
cellular access network, a fixed broadband access, I-WLAN access and a
nomadic access.”
I think, therefore that the solution is actually perfectly valid, the 3GPP
network is the IPCAN and it must allow independent detection and routing of
the emergency call. This requirement falls short of what some legislative
bodies are now considering the duty of the IPCAN to be, but it is still a
good start.

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.

[AJW] This is true for ECRIT in that LoST servers are not widely deployed
and publically available. However there are certainly NENA i2 deployments
being tested (not sure if they are actually live yet) where the  originating
call includes a PIDF-LO in the body with the call, and the VSP in
conjunction with a VPC can route the emergency call to the correct PSAP. I
fully expect this to happen in cases where the Internet pipe is 3G so let’s
agree that this is not hypothetical. 

I am aware of two countries that are currently in the process or about to
begin the process of legislating Internet access providers to make location
available for the purpose of routing emergency Internet calls. It will be
interesting to see what impact this legislation has on 3G data only devices
and associated network operators, presumably they will need to comply with
the Internet access provider legislation or stop providing, I think that it
is more likely that they will comply.

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.

[AJW] Martin, Brian and possibly Richard have already described a serious
flaw in this line of thinking. Namely that if I have a 3G Internet router,
any device behind that router has absolutely no visibility that it needs to
talk to a different VSP, the solution you are proposing almost suggests
therefore that the wireless router requires E-CSCF functionality in it and
that it can detect when a device in the home network is making an emergency
call. This is very intrusive and certainly not backward compatible with the
legacy devices already deployed. 

 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.

[AJW] Any device behind a home 3G router will have no visibility of the
connected cell-id. Cell-ID is also of almost no use to anyone but the
operator of the access network, so including this in a call to a VSP that
knows nothing about EVDO, let along a specific access provider seems almost
as big a stretch as universal SUPL roaming. Why not simply make the location
available to the caller using the mechanisms described in GeoPriv? Once this
is done you have ECRIT, i2, or i3 and they will just work! 

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.

[AJW] The argument again is that device may not know about the underlying
dependency between access and service and in a number of circumstances it
absolutely will not know. The device might be able to learn the address of
the local ES-Proxy, but if you are going to employ that solution why not
just employ an option to discover the LIS and the LoST server?

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

[AJW] Let’s agree to disagree on this point. The 3GPP access behind the
router is the Internet access provider and will likely have to provide
location to the device. We have got pretty good LIS discovery mechanisms
described in Geopriv that address most major concerns, so actually I believe
that ECRIT and NENA i2 will work quite well.

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.

I am not sure that I understand what you mean by “no explicit cellular
location capability”, perhaps you can explain. Certainly using a protocol
such as HELD I can an awful lot and it all remains local so it doesn’t
require a world in a database to support roaming such as is required in some
protocols that we will not mention here…;)

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

[AJW] You are right that NENA i2 is not a global standard, but it is being
tailored for deployment in at least 3 countries at I am aware of, and forms
the basis for discussion in a number of others.

I agree that circuit mode devices will be around for a many years to come, I
am less convinced that they will remain the norm, and with data only devices
increasing in popularity I see the need to hand-over in the way you describe
as unnecessary. Indeed I see it as a technological mismatch, equivalent to
being able to hand-over my GSM call to a CDMA network; Without a special,
purpose-built device I can’t do it. Delivery of calls from VoIP to circuit
switched PSTN and vice versa is common place today from any number of voice
service providers and this is the mode of operation we should be discussing.

Kind Regards

Stephen

----------------------------------------------------------------------------
--------------------
----------------------------------------------------------------------------
--------------------
[mf2]

---

From: "Edge, Stephen" <[email-masked]>
Date: Tue, 3 Mar 2009 21:31:40 -0800

Brian

Thanks for these well considered responses. Below I am providing on an item by item basis, and taking into account your responses, a few more reasons why the current Ecrit solution is unsuitable - or, if you prefer, less suitable than the 3GPP/3GPP2 solution - for cellular networks.

1. Access to PSTN capable PSAPs
Assuming that the best available solution for this currently is the ongoing NENA i2 standard (as you comment), then there are problems with providing location for dispatch (initial and updated location). For example, the latest i2.5 draft I have (December 2008) says that the VPC to LIS v3 interface is being deprecated (thus not available), although this is the interface that the VPC would use to query location from the LIS. Also I don't see any inclusion of accurate positioning support - e.g. using A-GPS. Further, interworking with the circuit mode side for UA access (as opposed to PSAP access) seems to be out of scope. So at best, this standard is incomplete (i.e. not yet suitable for cellular networks). However, I agree that there is some overlap between i2.5 and the 3GPP/3GPP2 solution.

2. Handover between different IP access networks including different types of access network
One of the issues here would be change of LIS across different networks while avoiding impacts to both IP and PSTN capable PSAPs (i.e. handover must be transparent to PSAPs within the limitations imposed by SIP or some J-STD-036 type of circuit mode solution). The problem gets more difficult when handover to/from circuit mode access networks is considered. So far, 3GPP/3GPP2 has not yet agreed on a solution although there are proposals and we expect some resolution soon. On the Ecrit and NENA sides, I see much less progress.

3. Handover to/from circuit mode networks
We agree here at least on the out of scope aspect. I suppose I can accept that it is not customary to point this out in IETF standards. But I hope you can see that this is an issue for cellular networks most of which will have extensive circuit mode coverage for a long time to come.

4. Location for cellular access (and the requirement to support LCPs that will be useless for cellular access)
The issue is not so much the LCP itself but the capability to support accurate positioning - e.g. using A-GPS, AFLT, OTDOA, enhanced cell ID etc. None of those methods seem to be supported as part of DHCP or HELD right now. So some modification of the LCP related requirements or of the LCPs seems needed.

5. 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)
Endpoint based location when spread over millions (billions, planet-wide) of terminals will consume significant network and terminal resources. A typical terminal is generally idle and interacts with the network very sparingly to update the network with its current location (e.g. current cluster of potential serving cells). Performing network assisted periodic location fixes and LoST queries would add significantly to network load. Performing periodic location fixes in the terminal (e.g. using GPS) and estimating when a PSAP boundary may have been crossed would add to terminal load (e.g. thus battery drain). Optimizations would be possible of course - e.g. based on observing nearby cell IDs - but they will add to terminal complexity and testing costs. I agree that the Ecrit solution does allow for proxies to do this but here the solution also becomes incomplete because there seem no details of how this would work - e.g. what location solutions would then be used.

6. Support of unauthenticated users and users who can be authenticated but are not permitted access/VSP service except for emergency calls
I think the Ecrit solution and you both assume that this has already been resolved somehow at the access level and therefore the various procedures in Ecrit can still be used. Maybe that is valid. However, there are still problems that are not covered in the Ecrit drafts but need to be resolved including (a) obtaining IP access (e.g. via a WLAN, cellular network, cable link) when not a valid subscriber, (b) obtaining access to the VSP and (c) ensuring only emergency related services are provided (e.g. and not free Internet and location access). These and additional problems (e.g. UA identification) would have to be solved, maybe on a per access basis, and then ensured to be compatible with the rest of the Ecrit solution. A significant part of the 3GPP/3GPP2 solution is concerned with this aspect and it has delayed completion of the solution for the more normal case of valid subscriber access due to such compatibility issues.

Kind Regards

Stephen
-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, February 27, 2009 6:53 AM
To: Edge, Stephen
Cc: Thomson, Martin; Richard Barnes; 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
problem areas:
>   - 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
> types of access network
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.
>   - location for cellular access (and the requirement to support LCPs that
> 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.
>
> 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
> From: Thomson, Martin [mailto:[email-masked]]
> Sent: Thursday, February 26, 2009 9:45 PM
> To: Edge, Stephen; Richard Barnes
> Cc: ECRIT
> 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
>
>
>> From: [email-masked] [mailto:[email-masked]] On Behalf
>> Of Edge, Stephen
>> Sent: Friday, 27 February 2009 3:30 PM
>> To: Richard Barnes
>> Cc: 'ECRIT'
>> Subject: Re: [Ecrit] Comments on Framework Draft
>>
>> 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
>> 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
>> > From: Brian Rosen [mailto:[email-masked]]
>> > Sent: Wednesday, February 18, 2009 8:07 PM
>> > To: Edge, Stephen; 'ECRIT'
>> > 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
>> >
>> >
>> >
>> >> 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
>> >
>> _______________________________________________
>> 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: Wed, 4 Mar 2009 18:20:14 -0800

Barbara and others

Thanks for the comments.

When I look at the PhoneBCP I see that both HELD and DHCP are mandatory for the device whereas at least one of these is mandatory for the AN. While I can also see that SUPL is not ruled out (though it is not mentioned or referenced), it appears to have been displaced by the HELD and DHCP requirements. On the other hand, many cellular networks have already deployed or are in the process of deploying SUPL and I am not aware of any that have deployed an accurate location capability using HELD or DHCP. So I would like to know how you see the current requirements as being suitable - after all, they imply at the very least additional development and deployment on the part of network and device vendors and network operators, whereas if SUPL was one of the defined LCPs, that additional development and deployment might be mostly avoided. This question would not be applicable with some additional scope limitation and so I had not previously raised it. But it is certainly applicable in the context of the global scope that is being claimed by some responders.

Kind Regards

Stephen
-----Original Message-----
From: Stark, Barbara [mailto:[email-masked]]
Sent: Friday, February 27, 2009 8:28 AM
To: [email-masked]; Edge, Stephen
Cc: ECRIT
Subject: RE: [Ecrit] Comments on Framework Draft

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

Behalf
>> >> PS  this being sent on 2/4/09 at 11:50pm PST
------------------------------------------------------------------------
------------------------
> 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

---

From: "Winterbottom, James" <[email-masked]>
Date: Wed, 4 Mar 2009 21:01:30 -0600

Hi Stephen,

SUPL has one very huge disadvantage, it mandates the use of a home SLP.
SUPL roaming between carriers is basically unimplementable. The
mechanisms required to support an H-SLP determining the V-SLP address
are deliberately left out of scope by OMA, and large numbers of
companies are busily putting IPR on the ways in which this can occur.
There are no large-scale deployments of RLP that I am aware of, and this
is a clear indicator of how bad the currently proposed architecture is.

All this means that for SUPL to be deployable on a large scale any H-SLP
simply has to have the entire world in a database. This is abundantly
evident when you look at systems like the global Nokia solution. I think
that this is mammoth task to maintain for general cell coverage, on a
global basis when you include W-LAN and femto-cells it is quite simply
ridiculous.

The result is that SUPL is next to useless as a solution for anything
other than providing basic-cell location or assistance data for GPS. It
is not local in the same sense that an LCP is. All of the other
determination mechanisms that you described in your previous email
simply don't work in SUPL to any reasonable degree, and I would argue
don't work at all once the device in a foreign network.

Cheers
James 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Edge, Stephen
Sent: Thursday, 5 March 2009 1:20 PM
To: Stark, Barbara; [email-masked]
Cc: ECRIT
Subject: Re: [Ecrit] Comments on Framework Draft

Barbara and others

Thanks for the comments.

When I look at the PhoneBCP I see that both HELD and DHCP are mandatory
for the device whereas at least one of these is mandatory for the AN.
While I can also see that SUPL is not ruled out (though it is not
mentioned or referenced), it appears to have been displaced by the HELD
and DHCP requirements. On the other hand, many cellular networks have
already deployed or are in the process of deploying SUPL and I am not
aware of any that have deployed an accurate location capability using
HELD or DHCP. So I would like to know how you see the current
requirements as being suitable - after all, they imply at the very least
additional development and deployment on the part of network and device
vendors and network operators, whereas if SUPL was one of the defined
LCPs, that additional development and deployment might be mostly
avoided. This question would not be applicable with some additional
scope limitation and so I had not previously raised it. But it is
certainly applicable in 
 the context of the global scope that is being claimed by some
responders.

Kind Regards

Stephen

-----Original Message-----

Stephen

Brian

Behalf

*****

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

---

From: "Edge, Stephen" <[email-masked]>
Date: Wed, 4 Mar 2009 19:54:51 -0800

Hi James

Thanks for these comments.

I assume you recall that SUPL would use an E-SLP located in the serving 3GPP/3GPP2 network in case of combined access and VSP support. There are then no roaming or global database issues as all location is supported within the serving network. Recall that you are claiming that the current Ecrit solution minus SUPL is suitable for this case which will be by far the most common one for emergency calls made via cellular networks. So I still ask you to justify why mandating support for DHCP and HELD and not including SUPL is a suitable solution.

For other scenarios not involving cellular access or where the cellular carrier is used only as an ISP, SUPL can still be suitable. For example, it is not true that a worldwide detailed database would be needed (e.g. containing the cell IDs of networks). A-GPS and A-GNSS can work quite well using fairly coarse location information (e.g. country or network identification) to seed assistance data and such coarse location information can be obtained by a number of means (e.g. IP address, country/network portions of a cell ID, previous location estimate).

Kind Regards

Stephen
-----Original Message-----
From: Winterbottom, James [mailto:[email-masked]]
Sent: Wednesday, March 04, 2009 7:02 PM
To: Edge, Stephen; Stark, Barbara; [email-masked]
Cc: ECRIT
Subject: RE: [Ecrit] Comments on Framework Draft

Hi Stephen,

Cheers
James

-----Original Message-----

Barbara and others

Thanks for the comments.

Kind Regards

Stephen

-----Original Message-----

Stephen

Brian

Behalf

*****

---

From: <[email-masked]>
Date: Thu, 5 Mar 2009 07:06:56 +0100

Stephen,

Thanks for pointing out these issues. If you look at the previous versions of phoneBCP, you'll also see LLDP (which was developed for fixed environment, like switches) on the list of mandatory LCPs. It took 2 years (!) to take that out from there, so in that sense there is some progress towards writing a more realistic set of requirements.

When it was requested to add SUPPL to the list, or to at least mention that SUPPL is the one which is currently mostly used for positioning (what an impertinent request it was to add to a document intended to describe BEST Current Practices, the protocols which are currently in use), the argument against it was that SUPPL requires the existence of a subscription, while the internet is subscription free.

Meanwhile people refused to take a look at the applicability of a DHCP based positioning method in today's world, where everything tends to be mobile.

An HTTP based protocol like HELD has the potential to offer solution for many, but not all of the use cases, as it can deliver location related measurement information to location servers. The cases when HELD does not work is when positioning is done using network based positioning methods involving control plane, like U-TDOA or AFLT. But then again, these are the positioning technologies which are currently used in indoor environments where (A-)GPS does not work. Perhaps this is the reason why they are not mentioned in a Best Current Practice document ...

- Gabor

  >From: [email-masked] [mailto:[email-masked]] On Behalf Of
  >ext Edge, Stephen
  >Sent: Wednesday, March 04, 2009 6:20 PM
  >LCPs, that additional development and deployment might be mostly avoided.
  >This question would not be applicable with some additional scope
  >limitation and so I had not previously raised it. But it is certainly
  >applicable in

---

From: "Winterbottom, James" <[email-masked]>
Date: Thu, 5 Mar 2009 18:44:15 +1100

Gabor,

You absolutey and totally wrong about HELD and control-plane. If  
anything, native HELD is best suited to control-plane location. Indeed  
in WiMAX it is the only means to invoke control-plane location.

Cheers James

Sent from my iPhone

On 05/03/2009, at 5:07 PM, "[email-masked]" <[email-masked] 
 > wrote:

> Stephen,
>
> Thanks for pointing out these issues. If you look at the previous  
> versions of phoneBCP, you'll also see LLDP (which was developed for  
> fixed environment, like switches) on the list of mandatory LCPs. It  
> took 2 years (!) to take that out from there, so in that sense there  
> is some progress towards writing a more realistic set of requirements.
>
> When it was requested to add SUPPL to the list, or to at least  
> mention that SUPPL is the one which is currently mostly used for  
> positioning (what an impertinent request it was to add to a document  
> intended to describe BEST Current Practices, the protocols which are  
> currently in use), the argument against it was that SUPPL requires  
> the existence of a subscription, while the internet is subscription  
> free.
>
> Meanwhile people refused to take a look at the applicability of a  
> DHCP based positioning method in today's world, where everything  
> tends to be mobile.
>
> An HTTP based protocol like HELD has the potential to offer solution  
> for many, but not all of the use cases, as it can deliver location  
> related measurement information to location servers. The cases when  
> HELD does not work is when positioning is done using network based  
> positioning methods involving control plane, like U-TDOA or AFLT.  
> But then again, these are the positioning technologies which are  
> currently used in indoor environments where (A-)GPS does not work.  
> Perhaps this is the reason why they are not mentioned in a Best  
> Current Practice document ...
>
> - Gabor
>
>
>> Behalf Of
>> avoided.
>>> The 3GPP/3GPP2 solution has a defined restricted applicability  
>>> (mainly
>> to
>>> 3GPP/3GPP2 access networks where the serving network also acts as  
>>> the
>> VSP)
>>> The Ecrit solution seems to claim global applicability to all  
>>> types of
>> IP
>>> national SDO will not help the user who encounters such problems.  
>>> But
>> 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
>>> is flawed and the solution is not going to work for cellular  
>>> services.
>> We
>>>> says "this doesn't work on X.25 networks", it's not clear to me  
>>>> that
>> an
>>>> from a cellular wireless perspective, the Ecrit solution is not  
>>>> seen
>> as
>> --- 
>> ---------------------------------------------------------------------
>> ------------------------
>> --- 
>> ---------------------------------------------------------------------
>> ------------------------
>>> [mf2]

---

From: <[email-masked]>
Date: Thu, 5 Mar 2009 09:25:53 +0100

Oh, I forgot about the abundance of deployed wimax networks. Huge mistake, indeed.

- gabor

  >From: ext Winterbottom, James [mailto:[email-masked]]
  >Sent: Wednesday, March 04, 2009 11:44 PM
  >To: Bajko Gabor (Nokia-CIC/MtView)
  >Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]

---

From: "Winterbottom, James" <[email-masked]>
Date: Thu, 5 Mar 2009 03:55:09 -0600

There are certainly more WiMAX networks deployed at this point than LTE networks... ;P

But that aside, the experimental HELD location networks we have deployed at the last 3 or so IETF meetings have all been control-plane and not user-plane from a location determination perspective.

Cheers
James

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Thu 3/5/2009 2:25 AM
To: Winterbottom, James
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: RE: [Ecrit] Comments on Framework Draft

- gabor

---

From: "Winterbottom, James" <[email-masked]>
Date: Wed, 4 Mar 2009 21:55:31 -0600

Hi Stephen,

A few errors and clarifications.

Cheers

James

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Edge, Stephen
Sent: Wednesday, 4 March 2009 4:32 PM
To: [email-masked]
Cc: ECRIT
Subject: Re: [Ecrit] Comments on Framework Draft

Brian

Thanks for these well considered responses. Below I am providing on an
item by item basis, and taking into account your responses, a few more
reasons why the current Ecrit solution is unsuitable - or, if you
prefer, less suitable than the 3GPP/3GPP2 solution - for cellular
networks.

Assuming that the best available solution for this currently is the
ongoing NENA i2 standard (as you comment), then there are problems with
providing location for dispatch (initial and updated location). For
example, the latest i2.5 draft I have (December 2008) says that the VPC
to LIS v3 interface is being deprecated (thus not available), although
this is the interface that the VPC would use to query location from the
LIS. 

[AJW] The V3 interface is not being deprecated, what is being deprecated
is the old V3 schema and the rationale for that is that it makes more
sense to re-use HELD
(http://tools.ietf.org/html/draft-winterbottom-geopriv-deref-protocol-03
) an SIP for dereference protocols rather than reinventing the wheel.

Also I don't see any inclusion of accurate positioning support - e.g.
using A-GPS. Further, interworking with the circuit mode side for UA
access (as opposed to PSAP access) seems to be out of scope. So at best,
this standard is incomplete (i.e. not yet suitable for cellular
networks). However, I agree that there is some overlap between i2.5 and
the 3GPP/3GPP2 solution.

[AJW] i2 does not preclude the measurements being provided by the Target
device, or being requested of the Target device by the LIS. There are a
slew of contributions that show how this can easily be done using HELD.

2. Handover between different IP access networks including different
types of access network

One of the issues here would be change of LIS across different networks
while avoiding impacts to both IP and PSTN capable PSAPs (i.e. handover
must be transparent to PSAPs within the limitations imposed by SIP or
some J-STD-036 type of circuit mode solution). The problem gets more
difficult when handover to/from circuit mode access networks is
considered. So far, 3GPP/3GPP2 has not yet agreed on a solution although
there are proposals and we expect some resolution soon. On the Ecrit and
NENA sides, I see much less progress.

We agree here at least on the out of scope aspect. I suppose I can
accept that it is not customary to point this out in IETF standards. But
I hope you can see that this is an issue for cellular networks most of
which will have extensive circuit mode coverage for a long time to come.

4. Location for cellular access (and the requirement to support LCPs
that will be useless for cellular access)

The issue is not so much the LCP itself but the capability to support
accurate positioning - e.g. using A-GPS, AFLT, OTDOA, enhanced cell ID
etc. None of those methods seem to be supported as part of DHCP or HELD
right now. So some modification of the LCP related requirements or of
the LCPs seems needed.

[AJW] I will stress that a number of these methods are network
determination methods and are dependent on the location node accessing
these measurements from directly from the RAN. In such cases anyone of
the LCPs described is just as capable of obtaining these as any specific
3G location node. For example, a device could launch a HELD request to
the LIS, and the LIS could request timing advance measurements from the
network, or use SRI/PSL to contact and SMLC. The determination
procedures are transparent and are equally applicable to an LCP as they
are to 3GPP specific procedures.

Let's take a bit of a look at Target provided measurements. If my
HELD-enable device were to include let's say relative delay measurements
to the LIS in an access network, then the LIS can easily use these,
since the LIS knows the locations of all the associated basestations.
Now let's compare this to 3GPP user-plane, where the SET would provide
this information back to a home-SLP, if the SET is roaming what use are
these measurements? There are two options for using them, neither of
which is overly satisfactory. The H-SLP can have a database containing
every single base station on earth, and can attempt to use them in that
fashion, certainly some vendors are taking that approach, but it is
hardly workable in the long term. Or, the H-SLP can find the SLP in the
visited network and ask it to do the work for it. Certainly SUPL defines
a protocol to support the quest procedures for this, but is very
conveniently puts out of scope how the H-SLP determines the correct
V-SLP to contact. Indeed once you move to W-LAN this problem becomes
intractable.

Device provided network measurements are only relevant in that access
network and this point is sadly missed by the 3GPP adopted user-plane
solution. 

 To see how some of plan to address you concerns of LCP provided
measurements please see:

*          draft-thomson-geopriv-held-measurements
<http://tools.ietf.org/html/draft-thomson-geopriv-held-measurements> 

*          draft-thomson-geopriv-held-grip
<http://tools.ietf.org/html/draft-thomson-geopriv-held-grip> 

*          draft-thomson-geopriv-held-capabilities
<http://tools.ietf.org/html/draft-thomson-geopriv-held-capabilities> 

*           

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

Endpoint based location when spread over millions (billions,
planet-wide) of terminals will consume significant network and terminal
resources.

[AJW] Perhaps, but using an LCP this is local traffic, in contrast with
SUPL ALL communication goes back to the H-SLP and this can be a long way
away when the device is roaming.

A typical terminal is generally idle and interacts with the network very
sparingly to update the network with its current location (e.g. current
cluster of potential serving cells). 

[AJW] A location URI means that unless the device changes access
networks that it does not need to perform this update at all. When the
device does change access networks, it acquires a new location URI.

Performing network assisted periodic location fixes and LoST queries
would add significantly to network load. Performing periodic location
fixes in the terminal (e.g. using GPS) and estimating when a PSAP
boundary may have been crossed would add to terminal load (e.g. thus
battery drain). 

[AJW] In the mobile case I would perform these operations at call time,
and I certainly wouldn't do a GPS fix as a rough location fix will be
quite adequate for purposes of obtaining a routing URI. In this case I
could send a HELD request the LIS with a responseTime=emergencyRouting.
The LIS can invoke techniques for enhanced cell etc is that falls into
criteria set by the local jurisdiction, the device can then do the lost
lookup using eh resulting location. It is certainly no less efficient
for the device to do these operations than it is for the network to do
them on behalf of the device, and it may be more efficient because these
are local services. Ultimately the bandwidth is the same or less using
the ECRIT proposal for call routing.

Optimizations would be possible of course - e.g. based on observing
nearby cell IDs - but they will add to terminal complexity and testing
costs. I agree that the Ecrit solution does allow for proxies to do this
but here the solution also becomes incomplete because there seem no
details of how this would work - e.g. what location solutions would then
be used.

[AJW] I am sorry I don't understand this comment. If we look at almost
any cellular technology that I am aware of the device is already aware
of neighbouring cells, it has to be as part of the general hand-over
procedures. In GSM this information is included in signal strength
information already passed from the handset to the network. In WiMAX
this is done using relative delay measurements. Pick your network type,
there are equivalents. Nothing special needs to be done to the device to
use them. Any network that supports a control-plane location
architecture provides native messaging for getting access to these
measurements. This is handled in the LIS and is totally transparent to
the device, the device see normal network procedures taking place.

Perhaps I have misunderstood what you were trying to say.

6. Support of unauthenticated users and users who can be authenticated
but are not permitted access/VSP service except for emergency calls

I think the Ecrit solution and you both assume that this has already
been resolved somehow at the access level and therefore the various
procedures in Ecrit can still be used. Maybe that is valid. However,
there are still problems that are not covered in the Ecrit drafts but
need to be resolved including (a) obtaining IP access (e.g. via a WLAN,
cellular network, cable link) when not a valid subscriber, (b) obtaining
access to the VSP and (c) ensuring only emergency related services are
provided (e.g. and not free Internet and location access). These and
additional problems (e.g. UA identification) would have to be solved,
maybe on a per access basis, and then ensured to be compatible with the
rest of the Ecrit solution. A significant part of the 3GPP/3GPP2
solution is concerned with this aspect and it has delayed completion of
the solution for the more normal case of valid subscriber access due to
such compatibility issues.

[AJW] Unauthenticated access is an interesting animal, and as you point
out in an IP world this has several different levels on which it
operates. There are a few points on this that should be considered
however, and fist and foremost perhaps is the growing number of
countries at that are disabling this functionality!

Another point of interest is that in cellular this is already
technologically challenged when it comes to this function; devices that
use different physical characteristic from the carrier network cannot be
accommodated by this service even if they both have 3GPP cores.

Private IP networks are very common, almost very house has one, and a
very large number have wireless LANs. Conversely there are very few
private cellular networks. So I am not sure that a direct comparison can
be made here, certainly I don't intend to let just anyone on to private
home LAN just because they claim they want to make an emergency call, it
is tantamount to my simply placing a T-200 phone on my letterbox along
with a sign that says emergency only.

There are thoughts on how to address some of these issues in ECRIT, and
you will have to forgive me but I haven't had time to address them in a
draft yet, I do hope to in the not too distant future.

Kind Regards

Stephen

-----Original Message-----

To: Edge, Stephen

Stephen

are ecrit compliant.

documents.

Brian

Behalf

Ecrit mailing list

[email-masked]

---

From: "Winterbottom, James" <[email-masked]>
Date: Wed, 4 Mar 2009 22:13:06 -0600

Hi Stephen,

Thankyou for you comments.

A few in response inline.

Cheers

James

-----Original Message-----
From: Edge, Stephen [mailto:[email-masked]] 
Sent: Thursday, 5 March 2009 2:55 PM
To: Winterbottom, James; Stark, Barbara; [email-masked]
Cc: ECRIT
Subject: RE: [Ecrit] Comments on Framework Draft

Hi James

I assume you recall that SUPL would use an E-SLP located in the serving
3GPP/3GPP2 network in case of combined access and VSP support. There are
then no roaming or global database issues as all location is supported
within the serving network. 

[AJW] You are quite correct, the E-SLP is the node that would be used.
Just to point out though that there are no SETs currently that support
the large number of E-SLP certificates required to make this solution
workable, since the SET is not allowed to respond to an SLP that it
cannot authenticate. I certainly think it remains to be seen is the
currently proposed E-SLP trust model is workable on a large scale.

Recall that you are claiming that the current Ecrit solution minus SUPL
is suitable for this case which will be by far the most common one for
emergency calls made via cellular networks. So I still ask you to
justify why mandating support for DHCP and HELD and not including SUPL
is a suitable solution.

[AJW] There are no SUPL 2.0 deployments at this stage, and SUPL 1.0 is
not suitable for emergency services. So nobody is making SUPL emergency
calls at this stage. I do however know of i2 and i3/ECRIT trials that
are currently in progress where devices are obtaining location
information from a LIS.

For other scenarios not involving cellular access or where the cellular
carrier is used only as an ISP, SUPL can still be suitable. For example,
it is not true that a worldwide detailed database would be needed (e.g.
containing the cell IDs of networks). A-GPS and A-GNSS can work quite
well using fairly coarse location information (e.g. country or network
identification) to seed assistance data and such coarse location
information can be obtained by a number of means (e.g. IP address,
country/network portions of a cell ID, previous location estimate).

[AJW] This can work outside quite well I agree, although I am not aware
of devices being able to converge on a location fast enough so that it
can be used at call time to assist with routing. I think that you will
also agree that using coarse-level assistance data to requires
significantly more power usage by the mobile than it were simply
provided with acquisition assistance. This latter information cannot be
provided without a finer-grained seed location as a reference point.

Kind Regards

Stephen

-----Original Message-----

Cc: ECRIT

Hi Stephen,

ridiculous.

Cheers

James

-----Original Message-----

Of Edge, Stephen

Cc: ECRIT

Barbara and others

Thanks for the comments.

certainly applicable in

responders.

Kind Regards

Stephen

-----Original Message-----

Cc: ECRIT

aren't stupid.

Barbara

-----Original Message-----

Of [email-masked]

To: Edge, Stephen

Cc: ECRIT

Stephen

as

and

in

It

to

emergency

to

do

SIP

>   - location for cellular access (and the requirement to support LCPs

that

phone

the

insertion

>   - endpoint based location and routing for cellular access (issues

here

and

are ecrit compliant.

>   - support of unauthenticated users and users who can be

authenticated

on

documents.

mobile

We

which

Brian

> The 3GPP/3GPP2 solution has a defined restricted applicability (mainly

to

> 3GPP/3GPP2 access networks where the serving network also acts as the

VSP)

> 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

> 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

>   - location for cellular access (and the requirement to support LCPs

that

>   - endpoint based location and routing for cellular access (issues

here

>   - support of unauthenticated users and users who can be

authenticated

> national SDO will not help the user who encounters such problems. But

it

> 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

> develops are for Internet devices.  That assumption probably need not

be

> 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

> 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

> 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

Behalf

>> calling works if all parties behave as specified in these (IETF

Ecrit)

>> providers and VSPs (not much good if some opt for another solution)

and

>> would to a large degree (and possibly completely) address our

concerns.

>> weeks) to cover the following access types: GPRS (UTRAN WCDMA),

I-WLAN,

>> They say, in effect, "SIP emergency calling works if all parties

behave

>> says "this doesn't work on X.25 networks", it's not clear to me that

an

>> I presume there are similar documents describing how emergency

calling

>> actually wrote it on 19 February in a 3GPP SA2 meeting in Budapest

but

>> capability will cooperate together to get it sent until I return to

the

>> > Anyhow thanks for your comments. There have actually been a number

of

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

>> alternative 3GPP/3GPP2 solution and indicating the IP access types

for

>> which the Ecrit solution will work without limitation (or

equivalently

>> > We are not proposing further modification and extension of the

Ecrit

>> > Stephen, with respect, please go talk to 3GPP management and ask

them

>> > there has been no participation in the ecrit effort despite

multiple

>> > 3GPP understands the mess that is being created by not

participating.

>> > terminated emergency calls, that there will be a lot of resistance

to

>> > to be involved with for years, but you refused to do anything.

It's

>> > everything you need is in the specs.  The mechanisms we have

defined

>> > pretty easy to do that.  I'll also note that we have tried to get

OMA

>> >> draft-ietf-ecrit-framework-07 is (as we see it) a mostly

informative

>> >> When we evaluated this with respect to support of wireless

cellular

>> >> certain portions of the draft exhibited one or more of the

following

>> >> emergency access by 3GPP, 3GPP2 and OMA. This is a plain

difference

>> >> solution and could be resolved through support of both solutions

by

>> >> access network and VSP) or could be resolved by supporting only

one

>> >> solution. To acknowledge this category, the framework document

could

>> >> reference the applicable wireless standards and point out that

these

>> >> other portions missing from the draft that would be needed to

fully

>> >> receipt of local dial strings; (b) restriction of LCPs to

protocols

>> >> are not applicable to (not defined for) cellular access; and (c)

the

>> >> terminal loading consequences and failure to support non-IP

capable

>> >> support of existing non-IP capable PSAPs besides increasing

terminal

>> >> capable PSAPs as already mentioned (e.g. to support E911 phase 2

in

>> >> a network only to place an emergency call with ensuing

restrictions

>> >> possible interworking between the current wireless network

solutions

>> >> solution are expected to be incorporated into wireless networks

now

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

------------------------

------------------------

Ecrit mailing list

[email-masked]

*****

 

Ecrit mailing list

[email-masked]

[mf2]

---

From: <[email-masked]>
Date: Thu, 5 Mar 2009 23:14:04 +0100

Who talked about LTE?
The point is, that cellular networks provide connectivity to internet, and they'll be around for many years to come.
And in those networks A-GPS combined with U-TDOA/AFLT is the positioning technology in use today, which is unlikely to be replaced in the near future as there is no better alternative around. I always found it unprofessional to not even mention these, but instead mandate dhcp, which has a very limited applicability.

- gabor

  >ext Winterbottom, James
  >Sent: Thursday, March 05, 2009 1:55 AM
  >Cc: [email-masked]
  >But that aside, the experimental HELD location networks we have deployed
  >at the last 3 or so IETF meetings have all been control-plane and not
  >user-plane from a location determination perspective.
  >
  >Cheers
  >James
  >
  >
  >
  >  >----------------------------------------------------------------------
  >---
  >  >-----------------------
  >  >----------------------------------------------------------------------
  >---
  >  >-----------------------
  >  >[mf2]
  >
  >
  >

---

From: "Winterbottom, James" <[email-masked]>
Date: Thu, 5 Mar 2009 16:18:30 -0600

Hi Gabor,

You are confusing issues.
A-GPS, U-TDOA and AFLT are all location determination techniques.
And while DHCP can be used to assist with location determination, when
you refer to it as an LCP, it is a location acquisition protocol, that
is, it is being used to hand the determined location to the Target
device requesting it.

A-GPS, U-TDOA and AFLT say nothing about how the location is provided
from the GMLC/MPC to the Target.

Cheers
James

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Friday, 6 March 2009 9:14 AM
To: Winterbottom, James
Cc: [email-masked]
Subject: RE: [Ecrit] Comments on Framework Draft

Who talked about LTE?
The point is, that cellular networks provide connectivity to internet,
and they'll be around for many years to come.
And in those networks A-GPS combined with U-TDOA/AFLT is the positioning
technology in use today, which is unlikely to be replaced in the near
future as there is no better alternative around. I always found it
unprofessional to not even mention these, but instead mandate dhcp,
which has a very limited applicability.

- gabor

Behalf Of
  >There are certainly more WiMAX networks deployed at this point than
LTE
  >networks... ;P
  >  >>> for the device whereas at least one of these is mandatory for
the
  >AN.
  >  >>> mentioned or referenced), it appears to have been displaced by
the
  >  >>> HELD
  >  >>> and DHCP requirements. On the other hand, many cellular
networks
  >have
  >  >>> already deployed or are in the process of deploying SUPL and I
am
  >  >>> requirements as being suitable - after all, they imply at the
very
  >  >>> least
  >  >>> additional development and deployment on the part of network
and
  >  >>> device
  >  >>> Thank you Brian. This is well said [except you left out the
fact
  >  >>> mechanisms, such as GPS, SUPL, or other methods, and doesn't
insist
  >  >>> artificially limit or define scope, or to state the obvious
(e.g.,
  >  >>> doesn't apply). We understand the role and scope of the IETF,
and
  >  >>> 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
  >  >>> mandate within the scope of their network or jurisdiction.
Again,
  >we
  >  >>> solutions that are explicitly designed for private IP networks
as
  >  >>> well
  >  >>> it should be no surprise that the ecrit solution does not cater
to
  >CS
  >  >>> general, and most private IP networks that can be
interconnected to
  >  >>> to existing CS connected PSAPs.  As you know, CS interconnects
are
  >  >>> very
  >  >>> 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
  >  >>> call as it is a SIP emergency call, and there are no statements
in
  >  >>> any
  >  >>>>  - location for cellular access (and the requirement to
support
  >LCPs
  >  >>> Since cellular is a mobile network, the access network would
pass
  >  >>> several times, cellular networks support raw data packet
services
  >  >>> upon
  >  >>> example is a large recreational vehicle traveling down a road
with
  >a
  >  >>> 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
  >  >>> implement interworking between cellular-specific location
protocols
  >  >>> The "load" of using DHCP or HELD to get location and querying
LoST
  >is
  >  >>> authentication, although where it is possible, it's desirable
so as
  >  >>> Mechanisms for specific network authentication mechanisms are
out
  >of
  >  >>> scope, and, like SIP basic calling, are not usually mentioned
in
  >IETF
  >  >>> networks.  It's true that it doesn't do it the way 3GPP
currently
  >  >>> thinks
  >  >>>>  - location for cellular access (and the requirement to
support
  >LCPs
  >  >>>> Stating that some of these cases are out of scope or
referencing
  >  >>>> their existence in one form or another because that would
allow
  >  >>>> better
  >  >>>> The IETF might occasionally make the assumption that the
standards
  >  >>>> of all the constraints.  You're suggesting that - as a result
-
  >  >>>> disagree.  The solution is a basis for emergency calling in
_any_
  >  >>>>> documents" to some degree highlights the problems we are
raising.
  >  >>>>> like IP capable PSAPs, global IP access (no islands of
circuit
  >mode
  >  >>>>> access for example), universal support of this solution by
all
  >  >>>>> make them unsuitable (we believe) for cellular wireless
networks.
  >  >>>>> If
  >  >>>>> You are right in assuming another set of specifications for
the
  >  >>>>> 3GPP
  >  >>>>> contribution S2-090752 which will become part of 23.167 in a
few
  >  >>>>> more
  >  >>>>> (LTE). So there is a restriction and arbitrary internet
access is
  >  >>>>> 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
  >  >>>>> these specs.  Just like there's no disclaimer in RFC 791
(IPv4)
  >  >>>>> works in 3GPP networks.  Do they include notes saying that
the
  >3GPP
  >  >>>>> capability will cooperate together to get it sent until I
return
  >  >>>>> participants on either side to have raised the kinds of
issues
  >you
  >  >>>>> elaborate on below. Given that seems not so far to have
happened,
  >  >>>>> aligning the 2 solutions or with the lack of this in the
past. We
  >  >>>>> are
  >  >>>>> simply pointing out that the solutions are currently
different
  >  >>>>> solution - just pointing out that this would be needed (as
with
  >  >>>>>> get work done it knows it will eventually have to do when
the
  >IETF
  >  >>>>>> know full well that when they finally get around to dealing
with
  >  >>>>>> PS
  >  >>>>>> the ability for the network to insert location, recognize
and
  >mark
  >  >>>>>> pretty easy to do that.  I'll also note that we have tried
to
  >get
  >  >>>>>>> or Femto cells integrated into a cellular network), we
found
  >  >>>>>>>    (C) Already part of wireless standards or potentially
part
  >of
  >  >>>>>>> future standards
  >  >>>>>>>
  >  >>>>>>> (A) refers to all portions of the draft framework that
differ
  >  >>>>>>> from
  >  >>>>>>> terminals (with each solution being used according to the
type
  >  >>>>>>> (B) refers to portions of the draft that would be
unsuitable
  >  >>>>>>> on endpoint derivation of location, performance of Lost
query
  >  >>>>>>> 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
  >  >>>>>>> load and possibly interfering with optimum maintenance of
the
  >RF
  >  >>>>>>> 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
  >  >>>>>>> (f) no allowance for limited access modes wherein a
terminal
  >may
  >  >>>>>>> either significant changes to the framework document could
be
  >  >>>>>>> made
  >  >>>>>>> Category (C) comprises concepts and capabilities in the
draft
  >  >>>>>>> versus for dispatch, cellular positioning methods. Examples
of
  >  >>>>>>> presence of this category could be acknowledged by
following
  >the
  >  >>>>>>> disclaimer for (B) with a statement that certain portions
of
  >  >>>>>>> PS  this being sent on 2/4/09 at 11:50pm PST
-------------------------------------------------------------------
  >--
-------------------------------------------------------------------
  >--
  >  >>> 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
  >  >>> you received this in error, please contact the sender and
delete
 
>-----------------------------------------------------------------------
--
 
>-----------------------------------------------------------------------
--

---

From: "Edge, Stephen" <[email-masked]>
Date: Thu, 5 Mar 2009 19:09:10 -0800

Hi James

Thanks for the further responses for which I have added some more of my own below. Please note in particular that SUPL 1.0 is widely deployed and can be used (and is being used by one carrier) for emergency call support for home users and that SUPL 2.0 while not yet deployed is entering its IOP phase that will validate both the standard and particular server and terminal implementations (later this year) after which we expect that deployments will swiftly follow.

Echoing what Gabor has said, would you say that this is not a current practice? And if so, where is the LCP suitable for IP emergency calls that is being used more widely by cellular carriers?

Kind Regards

Stephen
________________________________________
From: Winterbottom, James [mailto:[email-masked]]
Sent: Wednesday, March 04, 2009 8:13 PM
To: Edge, Stephen; Stark, Barbara; [email-masked]
Cc: ECRIT
Subject: RE: [Ecrit] Comments on Framework Draft

Hi Stephen,

Cheers
James

-----Original Message-----
From: Edge, Stephen [mailto:[email-masked]]
Sent: Thursday, 5 March 2009 2:55 PM
To: Winterbottom, James; Stark, Barbara; [email-masked]
Cc: ECRIT
Subject: RE: [Ecrit] Comments on Framework Draft

Hi James

I assume you recall that SUPL would use an E-SLP located in the serving 3GPP/3GPP2 network in case of combined access and VSP support. There are then no roaming or global database issues as all location is supported within the serving network.

[AJW] You are quite correct, the E-SLP is the node that would be used. Just to point out though that there are no SETs currently that support the large number of E-SLP certificates required to make this solution workable, since the SET is not allowed to respond to an SLP that it cannot authenticate. I certainly think it remains to be seen is the currently proposed E-SLP trust model is workable on a large scale.

[SE] SUPL 2.0 is not yet deployed so naturally there are no SETs commercially available yet with this capability. But IOP testing is planned to occur shortly and then may be seen to be workable.

Recall that you are claiming that the current Ecrit solution minus SUPL is suitable for this case which will be by far the most common one for emergency calls made via cellular networks. So I still ask you to justify why mandating support for DHCP and HELD and not including SUPL is a suitable solution.

[AJW] There are no SUPL 2.0 deployments at this stage, and SUPL 1.0 is not suitable for emergency services. So nobody is making SUPL emergency calls at this stage. I do however know of i2 and i3/ECRIT trials that are currently in progress where devices are obtaining location information from a LIS.

[SE] Actually there is one Asian WCDMA carrier using SUPL 1.0 to obtain location for emergency calls from home users in the circuit domain. This is not a trial but for real. Furthermore, a number of 3GPP and 3GPP2 carriers are planning for SUPL 2.0 deployment.

[AJW] This can work outside quite well I agree, although I am not aware of devices being able to converge on a location fast enough so that it can be used at call time to assist with routing. I think that you will also agree that using coarse-level assistance data to requires significantly more power usage by the mobile than it were simply provided with acquisition assistance. This latter information cannot be provided without a finer-grained seed location as a reference point.

[SE] yes you are right that with the present versions of the 3GPP/3GPP2 solution and SUPL any location would most probably be used for dispatch and not routing. The mobile power use should not be factor given the rarity and importance of an emergency call - which means location should be obtainable in most outdoor scenarios and some indoor ones. Note that with a coarse location estimate with a possible error of say <=1500 miles and an approximate time estimate with an error of say <=3 seconds, it is possible to determine satellites in view and a small Doppler search window that will improve satellite acquisition well beyond what can be achieved in standalone mode or where time is completely unknown.

Kind Regards

Stephen
-----Original Message-----
From: Winterbottom, James [mailto:[email-masked]]
Sent: Wednesday, March 04, 2009 7:02 PM
To: Edge, Stephen; Stark, Barbara; [email-masked]
Cc: ECRIT
Subject: RE: [Ecrit] Comments on Framework Draft

Hi Stephen,

Cheers
James

-----Original Message-----

Barbara and others

Thanks for the comments.

Kind Regards

Stephen

-----Original Message-----

Stephen

that
here
authenticated

Brian

to
VSP)
IP
the
that at
inapplicable to
that
here
authenticated
it
Ecrit
by
(or
that
be
it
of
not
really.
voice
ignorance
choice
We
Behalf
Ecrit)
and
concerns.
I-WLAN,
behave
an
calling
but
the
of
that
as
originating
sent
for
equivalently
Ecrit
them
multiple
participating.
to
It's
defined
OMA
informative
cellular
following
difference
by
one
could
these
fully
protocols
the
capable
terminal
in
restrictions
solutions
now
to
the
wording

*****

---

From: "Dawson, Martin" <[email-masked]>
Date: Thu, 5 Mar 2009 21:47:25 -0600

Gabor,

I believe your first point was that HELD isn't suited to control plane.
Prior to your sarcasm about the state of WiMAX deployment, James' point
was simply that HELD is very well suited to control plane implementation
and the WiMAX specification is evidence of that.

A HELD-capable LIS is associated with the access network and can avail
itself of any measurements that the access network has available. It's
control plane because it doesn't rely on the measurements coming via the
device (i.e. user plane). HELD allows for measurements obtained via the
control plane and those from the device (user plane).

Your criticism certainly applies to SUPL - but not to HELD.

SUPL does not fit in with the ECRIT model because it is not a service
which can be discovered and used in the network and, also, it cannot
deliver location by reference and nor can it deliver location in civic
address form.

You can make SUPL work for emergency calls with a great deal of trouble.
OMA added emergency service support in SUPL 2.0. The "E-SLP" that
Stephen previously referred to being the case in point. However, the
model of use is for the SLP to initiate the location procedure with the
SET. It is an NI-LR mode query originated from the E-SLP and it is up to
the SET to deal with the fact that it is getting an unsolicited SUPL
INIT message from a previously unknown SLP.

Apart from the obvious fact that an arbitrary VoIP service can't know
anything about E-SLPs in an arbitrary access network, or the fact that
the ECRIT model doesn't require a VSP to be involved at all, there is
the simple fact that having the location platform initiate the location
procedure is actually the opposite of what ECRIT describes for the
emergency procedure. Nothing to do with a lack of professionalism I'm
afraid.

Cheers,
Martin

-----Original Message-----
Of [email-masked]

Who talked about LTE?

- gabor

Behalf Of
LTE
the
the
networks
am
very
and
fact
insist
(e.g.,
and
architectures
useful
bodies
Again,
as
to
interconnected to
are
i2
networks,
the
the
in
support
pass
services
with
call,
aware
protocols
LoST
so as
out
in
currently
support
referencing
allow
standards
-
_any_
raising.
circuit
all
networks.
the
few
access is
expert
system
(IPv4)
the
return
issues
happened,
past. We
different
with
the
with
and
to
found
part
differ
type
unsuitable
query
and
the
network
the
non-
phase
terminal
be
draft
of
following
of
proprietary,
or
information
delete
 
--
 
--

---

From: "Dawson, Martin" <[email-masked]>
Date: Fri, 6 Mar 2009 00:56:21 -0600

There must be a word for the situation where everybody is talking about
something but everybody knows the real subject is something else and
what that real subject is. Suggestions welcome.

Anyway, working on the basis that this whole thing isn't just about
getting a "sound bite" added to the framework document that can be
misappropriated for years to come to confuse the cellular industry into
thinking ECRIT is not relevant to them, let's look at each of Stephen's
topic areas below.

A fundamental tenet of the argument is that, somehow, cellular is
"special" and should be left to its "special" devices compared to every
other Internet access technology. This, after all, is why we have IMS.
It might have seemed reasonable ten years ago to define the core service
architecture to accompany the new "Packet Service" mode of networking.
In these days of Web 2.0, AJAX, Ruby on Rails, Flash, Silverlight, SOA,
Azure... etc. against which IMS seems very.... "stodgy" it is reasonable
to ask the question why such a monolithic and cellular-legacy service
model is required. Nevertheless - 3GPP is entitled to do what 3GPP does.
Actually I'm pretty sure you won't find references to IMS in Web 2.0
texts saying "of course cellular operators also use IMS as an
application framework."

Now - how specific are the "special" cases that are outlined below to
cellular?:

1. Access to PSTN capable PSAPs
Not specific to cellular. If a jurisdiction has PSTN capable PSAPs then
VoIP calls originating from any form of access have to deal with that
fact. The answer is fairly obvious - there has to be a media gateway
behind the PSAP URI. And it might not just be a PSTN PSAP, there could
be dedicated circuits to selective routers or, even, CAMA trunks
involved. The manner in which this is done really does need to be spelt
out by the jurisdiction; it can't be otherwise even if there are fairly
common conventions. NENA looks after stating how this is done for the
US. It's not up to 3GPP nor the IETF to tell jurisdictions how emergency
calls that originate on Internet access get bridged into the legacy PSAP
infrastructure. No more so than it was 3GPP's job to prescribe that E2+
had to be the PSAP/ALI to GMLC interface protocol used for CS E9-1-1
calls.

2. Handover between different IP access networks
Not specific to cellular. There can be handover between WiFi and
Ethernet, WiFi and WiMAX and so forth. Now - what we're really talking
about here is a more fundamental capability related to mobile IP. 3GPP
definitely has a very nice role to play in prescribing how this
access-mobility occurs across the access technologies that 3GPP defines
and supports. Since the ECRIT emergency model concerns itself from the
IP layer up, it is quite possible for it to work very transparently to
such mobility occurring beneath the surface. And, of course, any such
nicely integrated access technologies would offer a nicely integrated
LIS solution to ensure that the location service remains contiguous and
consistent. It seems to me that it's quite bad engineering to couple the
manner in which this is done to a specific IP service such as emergency
calling. Can't help it if 3GPP do that - but it doesn't obviate the
option of ECRIT being applied in the more elegant way.

3. Handover to/from circuit mode networks
I'll give you this one... to an extent. Obviously the IETF doesn't think
this is in the least bit relevant to them. On the other, in theory, a
VoIP connection established on any form of IP access could be handed
over to some other form of circuit access - e.g. DSL to ISDN. The issue,
of course, is just how realistic these scenarios are. If you accept that
the PSTN is going to go away (and I certainly do) then you also
acknowledge that this is a transitional issue. You can argue that the
PSTN is still going to be around for years to come (and I also agree
with that) but that doesn't mean you have to create a specific mechanism
to handover between circuit and packet for emergency services.

I'm interested in just what it is that 3GPP have defined for this. I
look at the current 23.167 specification and, I admit, it doesn't leap
out at me. The stage 2 description has always struck me as kind of
vague. The diagram concerning location information handling, for
example, has the dotted boxes with non-prescriptive steps saying
"procedure to obtain location" done here. It always kind of reminds me
of that old cartoon with the engineers looking at the complex flow chart
with the "a miracle happens here" box in the middle. I'm thinking of a
call originated on IP. Let's say the E-CSCF invokes the E-SLP to do a
SUPL NI-LR (assuming one manifestation of the dotted box in the diagram)
and the resultant location is used to determine the correct MGCF route
to deliver the call. Perhaps the PSAP supports an MLP interface to the
LRF and can ask it for location updates - kicking off a SUPL NI-LR
again. Now - the device "roams" to a bit of the network that can only
support circuit service? What exactly happens? Does it initiate another
call via the MSC? How does that interact with the existing emergency
service semantics in the MSC? Obviously it wants to initiate a whole new
call - and initiate control plane location determination so it can
report an initial location to the GMLC. Is that GMLC the same node as
the LRF? How does it deal with the fact that it's now got two pieces of
state for what in theory is the same call? Or is it - given the MSC
can't know about the PS call in progress? What has 3GPP actually defined
for this?

I am certainly interested in the mechanics of how this is all
accomplished and done reliably. ITRW (the one you and I live in) 3G
operators commonly force emergency calls onto the GERAN just because
that's lower risk since GSM emergency calling is well established and
things like UTDOA infrastructure are available on that access. This is
quite the opposite tendency of looking to have seamless real time
migration between access technologies on emergency calls (let alone
seamless migration between PS and CS!). What carriers are planning to do
this with emergency calls if you can say?

4. Location for cellular access.
Certainly not specific to cellular access. Every technology has a need
for accurate location determination. Wired technologies also, most
appropriately, need the location to be provided in civic address form;
something that the nominated LCPs are very good at. You're partly
confusing the role of the LCP protocol with that of the server. You can
send a very simple HELD request to a LIS to ask for location; it's
incredibly simple to do; that's why HELD client implementations keep
popping up from different sources. The complex stuff happens on the
server side. A LIS receiving such a request can invoke all manner of
control plane mechanisms (for the confused - "control plane" is not an
antonym of "IP"; it just means interaction occurs between network
elements and not over the traffic channel with the device). For example,
the LIS might do UTDOA. Now, I suspect you realize this and carefully
chose examples of technologies that involve measurements taken by the
device. Fortunately this is not precluded by HELD either; I believe
James has already pointed you at the material for this.

Finally, since "cellular (=3GPP)" is clearly your one true interest
here, the good news is that cellular networks already have terrific
infrastructure and control plane mechanisms in place for location
determination. This includes the UE peer signalling for AGPS, OTDOA and
so forth. All a LIS in a 3GPP network has to do is provide the semantics
of the LCP to the device and emergency network clients and to invoke
that existing control plane infrastructure at the back end. It's
certainly a lower cost and more robust alternative than building SUPL
infrastructure in parallel to that control plane capability which
already exists to support CS emergency calls anyway.

5. Endpoint based location and routing
Nothing cellular specific about this one. Same thing applies to WiFi and
WiMAX and wired technologies too. The old "network loading" furphy is
often rolled out for these sorts of discussions; presumably it's
attractive because it sounds "technical" but doesn't really warrant
proper quantification and justification. Gosh "billions" of devices -
how can we even consider having so many devices doing... "stuff"? It
does prompt me to ask the question "what part of the term 'broadband'
don't you understand?" I'm going to take a wild stab and suggest that a
device being used to make an emergency call probably isn't "idle".
Further, with respect to the general IETF location service model, I'm
going to suggest that a device that wants to ask for its location isn't
idle either. Even further, I'm going to suggest that a LIS servicing a
location dereference can have enough integration with the access network
to have the device paged and for location procedures to proceed (i.e.
just like a control plane MT-LR or a SUPL NI-LR - though the latter is
an ill-defined proposition with respect to arbitrary access types).

Actually your commentary on this section strongly suggests to me that
you don't actually understand how an ECRIT emergency call procedure
works. You've certainly tried to characterize all this LoST and PSAP
boundary stuff that's going on as a big deal. It isn't and there's
certainly no more going on from either a device or network perspective
than there would be to provide the same functionality via a control
plane or SUPL approach. If you'd like an offline overview of how an
ECRIT emergency call is made, let me know; it would be my pleasure.

6. Support of unauthenticated users
Definitely not a cellular specific issue; every access technology has to
ask itself about this. Actually every regulator in every jurisdiction
has to ask themselves about this too - and hopefully they can avoid the
mistake of thinking one form of public access technology is "special"
compared to others as well. That would mitigate the risk of them coming
up with inconsistent and confusing legislation.

ECRIT is based on IP - so the key first step to getting an
ECRIT-compliant emergency call underway is for the device to have IP
access. In 3GPP parlance, you'd say it needs to have a network context.
A good example of providing ECRIT-compliant emergency calling to
unauthenticated devices is WiFi hotspots. Hotspots typically provide
free layer 2 connectivity and an IP context in the first instance.
Device traffic is "port-trapped" to the Hotspots' web site (and maybe a
smattering of public Internet websites as well). The firewall isn't
opened up until the user "authenticates"; the valid token very often
taking the form of a credit card number and expiry date. So -what would
a Hotspot need to do to provide "unauthenticated" emergency access? All
it needs to do is to ensure that unauthenticated devices, in addition to
having access to the portal web page, also have access to a LIS, a LoST
server and to the PSAP URI(s) which service the location of that
hotspot. That's it; sure there's no emergency call proxy via a third
party VSP - but that's not necessary (I'm actually against it anyway)
but it could be accommodated with some tweaks on the approach described.

Now - what would a 3GPP network need to do to support an ECRIT-compliant
unauthenticated emergency calling facility? You could probably describe
it better than me - but I dare say it would involve allowing the device
to establish an emergency IP context (something which I believe is
required by 23.167 anyway - otherwise how would the UE be able to tell
the P-CSCF it wants to do an emergency call?). Having permitted the
creation of the emergency context, the 3GPP network would similarly just
need to constrain the device's access to the LIS, LoST, and the PSAP
URI(s) for the corresponding location. Obviously 3GPP have decided to
define a different way of doing things and that's par for the course.
It's 3GPP's prerogative to continue to act as if there is something
special about cellular and that there's good reason for it to look
different to both IP devices and the emergency network. It's not true -
but that's never stopped the silo thinking before. And that puts me in
mind of that scene from Python's Holy Grail movie. 3GPP guarding the
bridge to "cellular land" - "None shall pass..." - It'll end much the
same way as well.

Cheers,
Martin
-----Original Message-----

Brian

1. Access to PSTN capable PSAPs
Assuming that the best available solution for this currently is the
ongoing NENA i2 standard (as you comment), then there are problems with
providing location for dispatch (initial and updated location). For
example, the latest i2.5 draft I have (December 2008) says that the VPC
to LIS v3 interface is being deprecated (thus not available), although
this is the interface that the VPC would use to query location from the
LIS. Also I don't see any inclusion of accurate positioning support -
e.g. using A-GPS. Further, interworking with the circuit mode side for
UA access (as opposed to PSAP access) seems to be out of scope. So at
best, this standard is incomplete (i.e. not yet suitable for cellular
networks). However, I agree that there is some overlap between i2.5 and
the 3GPP/3GPP2 solution.

5. 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)
Endpoint based location when spread over millions (billions,
planet-wide) of terminals will consume significant network and terminal
resources. A typical terminal is generally idle and interacts with the
network very sparingly to update the network with its current location
(e.g. current cluster of potential serving cells). Performing network
assisted periodic location fixes and LoST queries would add
significantly to network load. Performing periodic location fixes in the
terminal (e.g. using GPS) and estimating when a PSAP boundary may have
been crossed would add to terminal load (e.g. thus battery drain).
Optimizations would be possible of course - e.g. based on observing
nearby cell IDs - but they will add to terminal complexity and testing
costs. I agree that the Ecrit solution does allow for proxies to do this
but here the solution also becomes incomplete because there seem no
details of how this would work - e.g. what location solutions would then
be used.

Kind Regards

Stephen
-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, February 27, 2009 6:53 AM
To: Edge, Stephen
Cc: Thomson, Martin; Richard Barnes; ECRIT
Subject: Re: [Ecrit] Comments on Framework Draft

Stephen

that
here
authenticated

Brian

to
VSP)
IP
the
that at
inapplicable to
that
here
authenticated
it
Ecrit
by
(or
that
be
it
of
not
really.
voice
ignorance
choice
We
Behalf
Ecrit)
and
concerns.
I-WLAN,
behave
an
calling
but
the
of
that
as
originating
sent
for
equivalently
Ecrit
them
multiple
participating.
to
It's
defined
OMA
informative
cellular
following
difference
by
one
could
these
fully
protocols
the
capable
terminal
in
restrictions
solutions
now
to
the
wording

---

From: "Edge, Stephen" <[email-masked]>
Date: Thu, 5 Mar 2009 23:18:43 -0800

Hi James

Thanks for the comments and sorry for the delay in responding. I was having a hard time deciding whether and how to respond to your detailed comments on this particular scenario.

But this is rather a corner case from a 3GPP/3GPP2 operator perspective. The vast majority of devices that access cellular networks should in the future have 3GPP/3GPP2 IMS capability if they support VoIP and will thus likely support the 3GPP/3GPP2 VoIP emergency solution. The case of a non-3GPP/3GPP2 VoIP capable terminal accessing a VSP via a separate 3GPP/3GGP2 data card, modem or router should account for only a small fraction of all users. So 3GPP/3GPP2 has designed a solution for the normal case and has not yet addressed this more abnormal one. To address the latter, some extension of the 3GPP/3GPP2 solution would be needed which I was attempting to arrive at below - but not successfully since you do raise some good points. So to avoid more ado, I will concede the 3GPP/3GPP2 solution in its current form is not suitable for this particular case and that Ecrit is more suitable.

That, however, does not change our original contention because for the vast majority of cases where the device is fully 3GPP/3GPP2 capable, the 3GPP/3GPP2 VoIP emergency call solution should work fine whereas the Ecrit solution suffers from all the disadvantages I mentioned before.

In other words, supporting a more abnormal cellular user case (though I would agree not a trivial or invalid one) does not by itself turn a solution into one suitable for the normal case. To become suitable for the normal case, Ecrit too would need some extensions. 

Kind Regards

Stephen
Sent: Sunday, March 01, 2009 9:04 PM

Hi Stephen,

I have the distinct impression that we are never going to agree on this subject, I would however like to point out some statements in text below that are either misleading, or at least able to be interpreted in an alternative manner than that which is provided.

Please inline.

Cheers
James

-----Original Message-----
From: Edge, Stephen [mailto:[email-masked]] 
Sent: Friday, 27 February 2009 4:38 PM
To: Winterbottom, James; Brian Rosen; ECRIT
Subject: RE: [Ecrit] Comments on Framework Draft

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.

[AJW] Let's agree to disagree on this point, it is a stated requirement in TS23.167 (requirement 2 under section 4.1) that "Emergency services are independent from the IP-CAN with respect to the detection and routing of emergency sessions. The emergency services shall be possible over at least a cellular access network, a fixed broadband access, I-WLAN access and a nomadic access."
I think, therefore that the solution is actually perfectly valid, the 3GPP network is the IPCAN and it must allow independent detection and routing of the emergency call. This requirement falls short of what some legislative bodies are now considering the duty of the IPCAN to be, but it is still a good start.

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.

[AJW] This is true for ECRIT in that LoST servers are not widely deployed and publically available. However there are certainly NENA i2 deployments being tested (not sure if they are actually live yet) where the  originating call includes a PIDF-LO in the body with the call, and the VSP in conjunction with a VPC can route the emergency call to the correct PSAP. I fully expect this to happen in cases where the Internet pipe is 3G so let's agree that this is not hypothetical. 

I am aware of two countries that are currently in the process or about to begin the process of legislating Internet access providers to make location available for the purpose of routing emergency Internet calls. It will be interesting to see what impact this legislation has on 3G data only devices and associated network operators, presumably they will need to comply with the Internet access provider legislation or stop providing, I think that it is more likely that they will comply.

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.

[AJW] Martin, Brian and possibly Richard have already described a serious flaw in this line of thinking. Namely that if I have a 3G Internet router, any device behind that router has absolutely no visibility that it needs to talk to a different VSP, the solution you are proposing almost suggests therefore that the wireless router requires E-CSCF functionality in it and that it can detect when a device in the home network is making an emergency call. This is very intrusive and certainly not backward compatible with the legacy devices already deployed. 

 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.

[AJW] Any device behind a home 3G router will have no visibility of the connected cell-id. Cell-ID is also of almost no use to anyone but the operator of the access network, so including this in a call to a VSP that knows nothing about EVDO, let along a specific access provider seems almost as big a stretch as universal SUPL roaming. Why not simply make the location available to the caller using the mechanisms described in GeoPriv? Once this is done you have ECRIT, i2, or i3 and they will just work! 

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.

[AJW] The argument again is that device may not know about the underlying dependency between access and service and in a number of circumstances it absolutely will not know. The device might be able to learn the address of the local ES-Proxy, but if you are going to employ that solution why not just employ an option to discover the LIS and the LoST server?

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

[AJW] Let's agree to disagree on this point. The 3GPP access behind the router is the Internet access provider and will likely have to provide location to the device. We have got pretty good LIS discovery mechanisms described in Geopriv that address most major concerns, so actually I believe that ECRIT and NENA i2 will work quite well.

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.

[AJW] I think you will find that the WiMAX forum disagrees you with on a number of these points. And I have absolutely no doubt that with the 1.5 version of WiMAX I can support a fully mobile IP network using the ECRIT emergency calling architecture. 

I am not sure that I understand what you mean by "no explicit cellular location capability", perhaps you can explain. Certainly using a protocol such as HELD I can an awful lot and it all remains local so it doesn't require a world in a database to support roaming such as is required in some protocols that we will not mention here.;)

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

[AJW] You are right that NENA i2 is not a global standard, but it is being tailored for deployment in at least 3 countries at I am aware of, and forms the basis for discussion in a number of others.

I agree that circuit mode devices will be around for a many years to come, I am less convinced that they will remain the norm, and with data only devices increasing in popularity I see the need to hand-over in the way you describe as unnecessary. Indeed I see it as a technological mismatch, equivalent to being able to hand-over my GSM call to a CDMA network; Without a special, purpose-built device I can't do it. Delivery of calls from VoIP to circuit switched PSTN and vice versa is common place today from any number of voice service providers and this is the mode of operation we should be discussing.  

Kind Regards

Stephen

---

From: "Stark, Barbara" <[email-masked]>
Date: Fri, 6 Mar 2009 11:44:27 -0500

Personally, I consider a "3GPP access network" and cellular networks in
general to be "closed" networks. That is, 3GPP is able to define the
requirements of a "3GPP access network", and the devices that connect to
3GPP access networks. 3GPP is doing a wonderful job at providing these
requirements, together with SDOs like OMA that provide the actual SUPL
and similar protocol standards. 

I'm not worried about 3GPP access networks, and I'm not looking to the
IETF to provide an end-to-end architecture for how they work and what
devices need to do that connect to them. It is 3GPP's job to define
requirements for a 3GPP access network, and not IETF's job.

My interest in phonebcp has absolutely zero to do with 3GPP access
networks and the devices that connect to them. My interest is that we
need to have an architecture defined for "open" access networks, such
that if regulators ever decide that they want to do regulation to
achieve the goals of NENA i3 for all of these SIP calls riding over the
Internet (and going over DSL access networks), there would be things
written that would be acceptable solutions that would meet the
objectives, without causing extraordinary pain to *wireline* service
providers or consumers. Given that this is what I want phonebcp for, and
given that SUPL has zero deployment or real applicability in DSL
networks, statements about SUPL support in the context of phonebcp are
meaningless and irrelevant to me. They're like a "don't care" or "no op"
statement. SUPL is not an appropriate solution for the devices I want
phonebcp to deal with. SUPL is completely appropriate for 3GPP devices,
and, thankfully, I have 3GPP to provide the 3GPP architecture and
requirements. I don't need or want the IETF to provide a 3GPP
architecture for me. 

However, I do recognize that if a 3GPP handset with a data connection
were able to get its location via SUPL or directly from GPS, that it
could have a VPN set up to an Internet Voice Service Provider, and the
access network would have no ability to control what happened inside
this VPN. If there were a LoST server that the handset could find and
get emergency dialing and routing info, it could provide its location to
that VSP and mark calls as emergency calls and provide appropriate
routing info. IETF has provided the tools to make this work, and
sufficient explanation in phonebcp so that I understand how to make this
work, if I had to. Therefore, I am sufficiently satisfied that the IETF
docs would not need be overhauled if it became necessary to support this
scenario. That doesn't mean that I need or want the IETF to specifically
describe how to do this scenario. In fact, I'd really rather they
didn't.

With that said, if I look at phonebcp from an unemotional and objective
stand-point and ask "Is there anything, technically, that would prevent
me from doing phonebcp in a cellular environment?", the answer is no. If
I, individually, had gobs of money to spend on creating my very own
*non*-3GPP-compliant access network that used GSM as an underlying
access technology, on my private Caribbean island (since I have gobs of
money, I think I could swing the island), there is absolutely no
technical reason why I couldn't have that network support phonebcp. And
pay for my own developers to create the handsets to connect to it. 

That is, there is absolutely no technical reason why phonebcp could not
be used for a device with a GSM radio. Therefore, to say that such a
restriction exists would be inaccurate. The reason that phonebcp *won't*
be applied to the GSM side of such devices, is because nobody *intends*
to apply phonebcp to them. It is *not* IETF's job to say that a BCP
doesn't apply to certain entities or devices because those entities and
manufacturers don't want it to apply. That's just plain ludicrous. If we
in the industry don't want it to apply, we don't apply it! It's
incredibly simple not to implement an IETF RFC. I can not implement IETF
RFCs in my sleep, with both hands tied behind my back. In fact, there
are lots and lots of IETF RFCs that I'm not implementing, right now, as
I type.

There are only two reasons I could think of for someone trying to force
such a statement ("this doesn't apply to 3GPP access networks because
people involved in 3GPP access networks don't want it to apply" -- we
already have a working solution -- and by the way I think you need to
acknowledge that solution) into an IETF document. Either they're really
worried that someone is a complete moron and is going to think that just
because the IETF wrote this that it does apply to 3GPP networks, or they
want to shove it in the face of the IETF people that, "nah, nah, you
can't make me do it and I want to have you put it in writing that you
can't make me; ooh, I pwned you!" So which is it. Do you think we're all
morons, or are you trying to pwn these guys?

I feel like I'm watching a Dr. Phil episode. One side says "I want you
to admit that it's technically possible to use this on cell networks"
and the other side says "No, I won't admit that, but I want you to admit
that you can't make me implement this, and to acknowledge that I already
have a solution" so the first side says "No way, I won't admit that".
And the question Dr. Phil would ask is "Do you want to be right, or do
you want to be happy?" You're actually both right. There, does that make
you happy?

Anyway, I'm done with this debate. You won't hear from me anymore on it.
Barbara

-----Original Message-----
From: Edge, Stephen [mailto:[email-masked]] 
Sent: Wednesday, March 04, 2009 9:20 PM
To: Stark, Barbara; [email-masked]
Cc: ECRIT
Subject: RE: [Ecrit] Comments on Framework Draft

Barbara and others

Thanks for the comments.

certainly applicable in the context of the global scope that is being
claimed by some responders.

Kind Regards

Stephen

-----Original Message-----

Stephen

that
here
authenticated

Brian

to
VSP)
IP
the
that at
inapplicable to
that
here
authenticated
it
Ecrit
by
(or
that
be
it
of
not
really.
voice
ignorance
choice
We
Behalf
Ecrit)
and
concerns.
I-WLAN,
behave
an
calling
but
the
of
that
as
originating
sent
for
equivalently
Ecrit
them
multiple
participating.
to
It's
defined
OMA
informative
cellular
following
difference
by
one
could
these
fully
protocols
the
capable
terminal
in
restrictions
solutions
now
to
the
wording

*****

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 6 Mar 2009 09:58:06 -0500

Stephen

I admire your willingness to keep pushing, despite lack of progress.  I
think we're pretty close to the "agree to disagree" stage, but let me sum up
where I think we are and could go

1. There is a fundamental difference between the ecrit architecture and 3GPP
architecture when applied to mobile networks, and that fundamental
difference is edge intelligence vs network intelligence.  This is a very old
argument, with lots of history, and we're not likely to actually converge on
one way or the other in the large sense.  

We are both prisoners of our past.  Your architecture for emergency calls
looks a whole lot like the current emergency call architecture in mobile
networks today, and it works, within the limits it was designed for anyway.
Our bias towards edge intelligence is very old, and tends to always work.
We're constantly hearing that limits on compute power and bandwidth are
arguments for more network intelligence, but decades of experience suggests
that isn't a very good argument, albeit simplicity is always a virtue and
compression is often helpful.  Network intelligence tends to be an business
argument instead of a technical argument.

2. The IETF architecture would work in an IMS mobile network.  It would be
straightforward to deploy, for example, HELD in the network, and have the
endpoints follow the current text in -phonebcp.  Of course, 3GPP would have
to do work to deal with specifics like unitialized devices, handoffs, etc.
Gateways could be deployed to convert from PS to CS for CS connected PSAPs.
I even suspect you could make handoffs back and forth between CS and PS
work, although the solution would be 3GPP specific.

3. The 3GPP architecture doesn't work where there is no relationship between
the access network and the calling network including the case where the only
service the 3GPP network provides is raw packet access.  It doesn't really
work for fixed IMS networks that permit arbitrary nomadic access.  

4. Although the IETF documents are biased towards edge intelligence, the
specifications actually permit the network to determine a call is an
emergency call, obtain the location from the network, add it to the
signaling, route the call and send it to a PSAP.  

5. There is admittedly some conflict in our docs on what we call "Location
Configuration Protocols".  I would like us to keep in mind that an LCP is
"give me MY location" and not "give me HIS location".   Specifically, where
you have a case in which the access network can completely specify the
endpoints, and refuse service if the endpoint doesn't meet its standards,
then broad insistence on DHCP and HELD in all endpoints doesn't make sense:
the network can insist on any LCP, and all devices would have to implement
it.  We used to have some text that said that, but it was removed because of
the data card in the router problem.  There is another solution to that
problem: interwork the network's LCP to DHCP/HELD, but consensus was to just
take the exception to the list of LCPs out.  I will point out that the data
card in the router problem pretty much obviates the ability of the network
to insert location: it could with services it provides, but it also has to
provide one of the standard LCPs for the router to pass through.  It seems
really silly to deploy two solutions when one works always and the other
works only mostly.  It's not beyond the realm of possibility to have SUPL
added to the list of protocols.  There are issues with that, but they could
be addressed.  However, see below. The latest set of changes to -phonebcp on
the list of protocols was explicitly designed to include SUPL support in
devices connected to networks that support it.  It was the same change that
removed LLDP-MED from the all-devices-support list.

7. Emergency calling solutions are filled with complexity to handle cases
that rarely occur. It's a fact of life: emergency calling ALWAYS has to
work.  Of course we strive to keep simple things simple and complex things
possible, but rare events driving architecture in emergency calling is
nothing new.

Finally, we've said before, and I believe the offer stands (although I'm not
empowered to definitively say it):
The IETF is desirous of making 3GPP and IETF standards for emergency calling
more harmonious with each other.  To do so, it is willing to negotiate, and
in some circumstances to change its standards, provided that 3GPP is willing
to do the same.  The areas we would like to discuss include how location is
obtained for routing and delivered to a PSAP, what the representation for
location (geo and civic, value and reference) is, how emergency calls are
recognized and routed and the specifics of the SIP signaling to accomplish
the above.  The IETF and 3GPP have strived to not have conflicts in each
other's standards, and emergency calling should not be different.  

3GPP has explicitly decided NOT to enter such discussions and negotiations
at this time.

In the absence of official discussions and negotiations, I think our
documents are complete, and accurate.  There are no protocol police, and the
IETF is well aware that many vendors and network operators openly ignore
parts of its standards.  

Brian

-----Original Message-----
From: Edge, Stephen [mailto:[email-masked]] 
Sent: Friday, March 06, 2009 2:19 AM
To: Winterbottom, James; Brian Rosen; ECRIT
Subject: RE: [Ecrit] Comments on Framework Draft

Hi James

Thanks for the comments and sorry for the delay in responding. I was having
a hard time deciding whether and how to respond to your detailed comments on
this particular scenario.

But this is rather a corner case from a 3GPP/3GPP2 operator perspective. The
vast majority of devices that access cellular networks should in the future
have 3GPP/3GPP2 IMS capability if they support VoIP and will thus likely
support the 3GPP/3GPP2 VoIP emergency solution. The case of a non-3GPP/3GPP2
VoIP capable terminal accessing a VSP via a separate 3GPP/3GGP2 data card,
modem or router should account for only a small fraction of all users. So
3GPP/3GPP2 has designed a solution for the normal case and has not yet
addressed this more abnormal one. To address the latter, some extension of
the 3GPP/3GPP2 solution would be needed which I was attempting to arrive at
below - but not successfully since you do raise some good points. So to
avoid more ado, I will concede the 3GPP/3GPP2 solution in its current form
is not suitable for this particular case and that Ecrit is more suitable.

That, however, does not change our original contention because for the vast
majority of cases where the device is fully 3GPP/3GPP2 capable, the
3GPP/3GPP2 VoIP emergency call solution should work fine whereas the Ecrit
solution suffers from all the disadvantages I mentioned before.

In other words, supporting a more abnormal cellular user case (though I
would agree not a trivial or invalid one) does not by itself turn a solution
into one suitable for the normal case. To become suitable for the normal
case, Ecrit too would need some extensions. 

Kind Regards

Stephen

Hi Stephen,

Please inline.

Cheers
James

-----Original Message-----
From: Edge, Stephen [mailto:[email-masked]] 
Sent: Friday, 27 February 2009 4:38 PM
To: Winterbottom, James; Brian Rosen; ECRIT
Subject: RE: [Ecrit] Comments on Framework Draft

Hi James

[AJW] Let's agree to disagree on this point, it is a stated requirement in
TS23.167 (requirement 2 under section 4.1) that "Emergency services are
independent from the IP-CAN with respect to the detection and routing of
emergency sessions. The emergency services shall be possible over at least a
cellular access network, a fixed broadband access, I-WLAN access and a
nomadic access."
I think, therefore that the solution is actually perfectly valid, the 3GPP
network is the IPCAN and it must allow independent detection and routing of
the emergency call. This requirement falls short of what some legislative
bodies are now considering the duty of the IPCAN to be, but it is still a
good start.

fully expect this to happen in cases where the Internet pipe is 3G so let's

I am not sure that I understand what you mean by "no explicit cellular
location capability", perhaps you can explain. Certainly using a protocol
such as HELD I can an awful lot and it all remains local so it doesn't
require a world in a database to support roaming such as is required in some
protocols that we will not mention here.;)

purpose-built device I can't do it. Delivery of calls from VoIP to circuit

Kind Regards

Stephen

---

From: Ted Hardie <[email-masked]>
Date: Fri, 6 Mar 2009 10:43:46 -0800

At 6:58 AM -0800 3/6/09, Brian Rosen wrote:
>to do the same. 

Uh, Brian, on what basis do you speak for the IETF in this manner?  The
willingness of the IETF to "negotiate" sounds more like the attitude of
a sovereign power (or at least an SDO with serious turf issues) than a
technical body striving to do the right thing.

>The areas we would like to discuss include how location is

Individuals with experience in this realm have spoken about the issue
in the past and are raising the issue again.  Given that the IETF has historically
said that the *best* way for progress to occur was to have technical
contributors contribute, I find this "send me a liaison statement and we'll
talk" attitude baffling and inappropriate.

As for "agreeing to disagree", that's what I heard Stephen asking for
all along; a statement in the document that described its applicability.
I found your description of the end-to-end networks with edge intelligence
both appropriate and accurate for the ECRIT case.  Why not include that,
along with a note saying that network architectures which rely upon
network support/command/control do not work using this set of technologies
and aren't expected to develop in that direction?   Not including some
statement of applicability here seems more like an attempt to control the
outcome by ignoring reality than anything else, and I don't believe
that's appropriate.

>IETF is well aware that many vendors and network operators openly ignore

This sounds extraordinarily like you believe that all vendors and network
operators *should* be following IETF standards and that the wise, benevolent
IETF is saddened by the wayward behavior of these naughty children.

This is a technical body, trying to write specs that work in the real world.
It is not divinely inspired, though I have written enough howlers into my own
documents to wish it were.  Having Stephen request we recognize the
existence of other models in a BCP document for a process that we all
agree *must work the maximum out of time* seems either a good idea
or harmless.  Do we really not have the humility to manage that?

				Ted

>-----

---

From: "Edge, Stephen" <[email-masked]>
Date: Fri, 6 Mar 2009 18:26:08 -0800

Hi Brian

Thanks for these comments. I have been responding generally slower than you and other Ecrit participants have been sending and need to catch up. I will try to do so by being brief where possible.

Our basic thesis is that Ecrit is not suitable in its current form for cellular networks. If it will help, we can qualify what that includes - e.g. mobile devices that support the full 3GPP or 3GPP2 protocol stacks across the radio interface - and thus exclude less normal cases that James and I were discussing.

I have not seen any good arguments yet that refute this main proposition. For example, even if WiMax endorses the Ecrit solution and decides to make use of it, it may in the end prove the point we are making rather than yours. Why? Because unless WiMax complies with nearly all the SHALLs in the PhoneBCP and most of the SHOULDs, it would not be compliant but only use Ecrit as a basis. (By contrast, 3GPP and 3GPP2 implementations are expected to comply with all SHALLs and most SHOULDs in 3GPP/3GGP2 spec.s.)

In your comments below, you are off on a tangent concerning which solution may have the widest applicability. That is not what we are concerned with. E.G. I can agree for the sake of argument (and to save a lot of time) that Ecrit has a brilliant solution for all scenarios barring those I have identified above. And our original contention would then still remain.

Kind Regards

Stephen
-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Monday, March 02, 2009 8:23 AM
To: 'Winterbottom, James'; Edge, Stephen; 'ECRIT'
Subject: RE: [Ecrit] Comments on Framework Draft

I'm also certain we're not going to converge, but let me step up a level and

Brian

Hi Stephen,

Please inline.

Cheers
James

-----Original Message-----
From: Edge, Stephen [mailto:[email-masked]] 
Sent: Friday, 27 February 2009 4:38 PM
To: Winterbottom, James; Brian Rosen; ECRIT
Subject: RE: [Ecrit] Comments on Framework Draft

Hi James

Kind Regards

Stephen

---

From: "Edge, Stephen" <[email-masked]>
Date: Fri, 6 Mar 2009 19:27:16 -0800

Hi James

Thanks for the comments for which I have embedded some responses below. In every case, I feel sure that my original point remains sustained.

Kind Regards

Stephen
________________________________________
From: Winterbottom, James [mailto:[email-masked]]
Sent: Wednesday, March 04, 2009 7:56 PM
To: Edge, Stephen; [email-masked]
Cc: ECRIT
Subject: RE: [Ecrit] Comments on Framework Draft

Hi Stephen,

Cheers
James

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Edge, Stephen
Sent: Wednesday, 4 March 2009 4:32 PM
To: [email-masked]
Cc: ECRIT
Subject: Re: [Ecrit] Comments on Framework Draft

Brian

1. Access to PSTN capable PSAPs
Assuming that the best available solution for this currently is the ongoing NENA i2 standard (as you comment), then there are problems with providing location for dispatch (initial and updated location). For example, the latest i2.5 draft I have (December 2008) says that the VPC to LIS v3 interface is being deprecated (thus not available), although this is the interface that the VPC would use to query location from the LIS.

[AJW] The V3 interface is not being deprecated, what is being deprecated is the old V3 schema and the rationale for that is that it makes more sense to re-use HELD (http://tools.ietf.org/html/draft-winterbottom-geopriv-deref-protocol-03) an SIP for dereference protocols rather than reinventing the wheel.

[SE] Okay (got it!)

Also I don't see any inclusion of accurate positioning support - e.g. using A-GPS. Further, interworking with the circuit mode side for UA access (as opposed to PSAP access) seems to be out of scope. So at best, this standard is incomplete (i.e. not yet suitable for cellular networks). However, I agree that there is some overlap between i2.5 and the 3GPP/3GPP2 solution.

[AJW] i2 does not preclude the measurements being provided by the Target device, or being requested of the Target device by the LIS. There are a slew of contributions that show how this can easily be done using HELD.

[SE] I think this is mostly or entirely in drafts - right? I don't think any of them deal with 3GPP/3GPP2 interworking - e.g. LIS to RNC, LIS to eNodeB etc. That represents future work and uncertainty (e.g. concerning complexity, feasibility, performance). Also I am not sure how complete the positioning support you refer to really is - e.g. in terms of supporting A-GNSS and the various terrestrial OTDOA methods.

[AJW] I will stress that a number of these methods are network determination methods and are dependent on the location node accessing these measurements from directly from the RAN. In such cases anyone of the LCPs described is just as capable of obtaining these as any specific 3G location node. For example, a device could launch a HELD request to the LIS, and the LIS could request timing advance measurements from the network, or use SRI/PSL to contact and SMLC. The determination procedures are transparent and are equally applicable to an LCP as they are to 3GPP specific procedures.

Let's take a bit of a look at Target provided measurements. If my HELD-enable device were to include let's say relative delay measurements to the LIS in an access network, then the LIS can easily use these, since the LIS knows the locations of all the associated basestations. Now let's compare this to 3GPP user-plane, where the SET would provide this information back to a home-SLP, if the SET is roaming what use are these measurements? There are two options for using them, neither of which is overly satisfactory. The H-SLP can have a database containing every single base station on earth, and can attempt to use them in that fashion, certainly some vendors are taking that approach, but it is hardly workable in the long term. Or, the H-SLP can find the SLP in the visited network and ask it to do the work for it. Certainly SUPL defines a protocol to support the quest procedures for this, but is very conveniently puts out of scope how the H-SLP determines the correct V-SLP to contact. Indeed once you move to W-LAN this problem becomes intractable.

Device provided network measurements are only relevant in that access network and this point is sadly missed by the 3GPP adopted user-plane solution.

 To see how some of plan to address you concerns of LCP provided measurements please see:
* draft-thomson-geopriv-held-measurements
* draft-thomson-geopriv-held-grip
* draft-thomson-geopriv-held-capabilities
*

[SE] Repeat my previous comment above about additional standardization needed and associated uncertainties. Regarding SUPL, I thought we had now agreed that once an emergency call has been initiated, it will be an E-SLP in the serving network rather than an H-SLP in the home network that would be involved in roaming cases. The E-SLP can initiate positioning for both routing and dispatch and make use of RAN related measurements. Moreover, for HSPA and LTE access, there are (or will be later this year) alternative control plane solutions. Note that I am suggesting using SUPL (or any other method) to obtain location in advance of an emergency call.

5. 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)
Endpoint based location when spread over millions (billions, planet-wide) of terminals will consume significant network and terminal resources.

[AJW] Perhaps, but using an LCP this is local traffic, in contrast with SUPL ALL communication goes back to the H-SLP and this can be a long way away when the device is roaming.

[SE] SUPL will not be used to pre-obtain location for a later emergency call. It will generally be used only after an emergency call has been initiated and will be invoked by an E-SLP.

A typical terminal is generally idle and interacts with the network very sparingly to update the network with its current location (e.g. current cluster of potential serving cells).

[AJW] A location URI means that unless the device changes access networks that it does not need to perform this update at all. When the device does change access networks, it acquires a new location URI.

[SE] a location URI does not help a device determine when it may have crossed a PSAP boundary. So if you want a mobile device to know the PSAP in advance of an emergency call, a lot of location determination seems needed.

Performing network assisted periodic location fixes and LoST queries would add significantly to network load. Performing periodic location fixes in the terminal (e.g. using GPS) and estimating when a PSAP boundary may have been crossed would add to terminal load (e.g. thus battery drain).

[AJW] In the mobile case I would perform these operations at call time, and I certainly wouldn't do a GPS fix as a rough location fix will be quite adequate for purposes of obtaining a routing URI. In this case I could send a HELD request the LIS with a responseTime=emergencyRouting. The LIS can invoke techniques for enhanced cell etc is that falls into criteria set by the local jurisdiction, the device can then do the lost lookup using eh resulting location. It is certainly no less efficient for the device to do these operations than it is for the network to do them on behalf of the device, and it may be more efficient because these are local services. Ultimately the bandwidth is the same or less using the ECRIT proposal for call routing.

[SE] The above is a more reasonable approach. However, the phoneBCP says: "ED-31/INT-24 For devices which roam, refresh of location information SHOULD be more frequent, with the frequency related to the mobility of the device and the ability of the access network to support the refresh operation.  If the device can detect that it has moved, for example when it changes access points, the device SHOULD refresh its location". Do you agree that maybe this part of the phoneBCP is not suitable?

Optimizations would be possible of course - e.g. based on observing nearby cell IDs - but they will add to terminal complexity and testing costs. I agree that the Ecrit solution does allow for proxies to do this but here the solution also becomes incomplete because there seem no details of how this would work - e.g. what location solutions would then be used.

[AJW] I am sorry I don't understand this comment. If we look at almost any cellular technology that I am aware of the device is already aware of neighbouring cells, it has to be as part of the general hand-over procedures. In GSM this information is included in signal strength information already passed from the handset to the network. In WiMAX this is done using relative delay measurements. Pick your network type, there are equivalents. Nothing special needs to be done to the device to use them. Any network that supports a control-plane location architecture provides native messaging for getting access to these measurements. This is handled in the LIS and is totally transparent to the device, the device see normal network procedures taking place.

[SE] yes you are right that cell ID based methods will obtain location faster and more simply. But I was referring to use of visible cell IDs within a terminal as an optimization to determine location changes without network interaction which is something not currently supported (thus new impacts).

[AJW] Unauthenticated access is an interesting animal, and as you point out in an IP world this has several different levels on which it operates. There are a few points on this that should be considered however, and fist and foremost perhaps is the growing number of countries at that are disabling this functionality!

Another point of interest is that in cellular this is already technologically challenged when it comes to this function; devices that use different physical characteristic from the carrier network cannot be accommodated by this service even if they both have 3GPP cores.

Private IP networks are very common, almost very house has one, and a very large number have wireless LANs. Conversely there are very few private cellular networks. So I am not sure that a direct comparison can be made here, certainly I don't intend to let just anyone on to private home LAN just because they claim they want to make an emergency call, it is tantamount to my simply placing a T-200 phone on my letterbox along with a sign that says emergency only.

There are thoughts on how to address some of these issues in ECRIT, and you will have to forgive me but I haven't had time to address them in a draft yet, I do hope to in the not too distant future.

[SE] we think some countries will continue to require support of unauthenticated emergency access and, in particular, do not want to take the risk of excluding support for it. Thus, we see this as a necessary part of any (suitable) solution.

Kind Regards

Stephen
-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, February 27, 2009 6:53 AM
To: Edge, Stephen
Cc: Thomson, Martin; Richard Barnes; ECRIT
Subject: Re: [Ecrit] Comments on Framework Draft

Stephen

Brian

>> >> Category (C) comprises concepts and capabilis in the draft that
>> are

---

From: "Edge, Stephen" <[email-masked]>
Date: Fri, 6 Mar 2009 20:27:10 -0800

Hi Martin

I am trying to clear my Ecrit related backlog and now I have got to this message which I am answering even though not strictly addressed to me. (Hopefully Gabor will not mind.)

Outside the 3GPP/3GPP2 "walled garden" (or 3GPP/3GPP2 "side of the wall"), your comments make some sense. SUPL is not suitable right now as an LCP for all emergency calls (e.g. for roamers as well as homers) if by LCP you mean a protocol enabling a device to obtain (configure) its own location in advance of an emergency call and in some cases immediately after an emergency call is invoked.

But inside the walled garden (on the other side of the wall), an LCP is not needed because the 3GPP/3GPP2 serving network can obtain location after an emergency call is initiated using SUPL or a control plane solution. Further note that any fully 3GPP/3GPP2 capable device can assume this since it can be a requirement on the 3GPP/3GPP2 network side (therefore no need for any discovery).

Now recall we are supposed to be discussing whether or not the Ecrit solution is globally suitable which means inside as well as outside of the walled garden (on both sides of the wall). If the Ecrit solution remains unchanged, then it suffers from all the drawbacks I already mentioned and have further elaborated on. However, it could be changed to become more suitable and one of the changes might be to relax the definition of what constitutes an LCP such that SUPL can be included. This would improve suitability for 3GPP/3GPP2 networks because it would avoid additional implementation for those that will anyway be supporting SUPL. For the less normal case of access to a 3GPP/3GPP2 network as an ISP (rather than as a VSP), something new would be needed but that might also involve SUPL - e.g. support of SUPL in an 3GPP/3GPP2 capable router which would enable a VSP E-SLP to obtain location for dispatch and possibly for routing.

Kind Regards

Stephen
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Dawson, Martin
Sent: Thursday, March 05, 2009 7:47 PM
To: [email-masked]; Winterbottom, James
Cc: [email-masked]
Subject: Re: [Ecrit] Comments on Framework Draft

Gabor,

Cheers,
Martin

-----Original Message-----

Who talked about LTE?

- gabor

Behalf Of
LTE
the
the
networks
am
very
and
fact
insist
(e.g.,
and
architectures
useful
bodies
Again,
as
to
interconnected to
are
i2
networks,
the
the
in
support
pass
services
with
call,
aware
protocols
LoST
so as
out
in
currently
support
referencing
allow
standards
-
_any_
raising.
circuit
all
networks.
the
few
access is
expert
system
(IPv4)
the
return
issues
happened,
past. We
different
with
the
with
and
to
found
part
differ
type
unsuitable
query
and
the
network
the
non-
phase
terminal
be
draft
of
following
of
proprietary,
or
information
delete

--

--

---

From: "Dawson, Martin" <[email-masked]>
Date: Sun, 8 Mar 2009 20:48:21 -0500

Sticking with the pretence that this discussion can be taken at face
value...

I found your comments puzzling Stephen. Juxtapose the following:

" SUPL is not suitable right now as an LCP..."

" But inside the walled garden (on the other side of the wall), an LCP
is not needed..."

"If the Ecrit solution remains unchanged, then it suffers from all the
drawbacks I already mentioned... However, it could be changed to become
more suitable [by relaxing] the definition of what constitutes an LCP
such that SUPL can be included."

I not only find the logic non-compelling, I can't find the logic. I can
spot an apparent contradiction or two.

Cheers,
Martin

-----Original Message-----
From: Edge, Stephen [mailto:[email-masked]] 
Sent: Saturday, 7 March 2009 3:27 PM
To: Dawson, Martin; [email-masked]; Winterbottom, James
Cc: [email-masked]
Subject: RE: [Ecrit] Comments on Framework Draft

Hi Martin

I am trying to clear my Ecrit related backlog and now I have got to this
message which I am answering even though not strictly addressed to me.
(Hopefully Gabor will not mind.)

Outside the 3GPP/3GPP2 "walled garden" (or 3GPP/3GPP2 "side of the
wall"), your comments make some sense. SUPL is not suitable right now as
an LCP for all emergency calls (e.g. for roamers as well as homers) if
by LCP you mean a protocol enabling a device to obtain (configure) its
own location in advance of an emergency call and in some cases
immediately after an emergency call is invoked.

But inside the walled garden (on the other side of the wall), an LCP is
not needed because the 3GPP/3GPP2 serving network can obtain location
after an emergency call is initiated using SUPL or a control plane
solution. Further note that any fully 3GPP/3GPP2 capable device can
assume this since it can be a requirement on the 3GPP/3GPP2 network side
(therefore no need for any discovery).

Now recall we are supposed to be discussing whether or not the Ecrit
solution is globally suitable which means inside as well as outside of
the walled garden (on both sides of the wall). If the Ecrit solution
remains unchanged, then it suffers from all the drawbacks I already
mentioned and have further elaborated on. However, it could be changed
to become more suitable and one of the changes might be to relax the
definition of what constitutes an LCP such that SUPL can be included.
This would improve suitability for 3GPP/3GPP2 networks because it would
avoid additional implementation for those that will anyway be supporting
SUPL. For the less normal case of access to a 3GPP/3GPP2 network as an
ISP (rather than as a VSP), something new would be needed but that might
also involve SUPL - e.g. support of SUPL in an 3GPP/3GPP2 capable router
which would enable a VSP E-SLP to obtain location for dispatch and
possibly for routing.

Kind Regards

Stephen
-----Original Message-----
Of Dawson, Martin

Gabor,

Cheers,
Martin

-----Original Message-----

Who talked about LTE?

- gabor

Behalf Of
LTE
the
the
networks
am
very
and
fact
insist
(e.g.,
and
architectures
useful
bodies
Again,
as
to
interconnected to
are
i2
networks,
the
the
in
support
pass
services
with
call,
aware
protocols
LoST
so as
out
in
currently
support
referencing
allow
standards
-
_any_
raising.
circuit
all
networks.
the
few
access is
expert
system
(IPv4)
the
return
issues
happened,
past. We
different
with
the
with
and
to
found
part
differ
type
unsuitable
query
and
the
network
the
non-
phase
terminal
be
draft
of
following
of
proprietary,
or
information
delete

--

--

---

From: "Dawson, Martin" <[email-masked]>
Date: Sun, 8 Mar 2009 20:56:28 -0500

I've already said why I think it would be quite a bad idea to put such a
comment in PhoneBCP - never mind that it would be not appropriate and
would beg the question of why every other alternative approach to
emergency communication architectures shouldn't also be cited.

If you think it is simply not a big deal to include the comment then
presumably you also think it's not a big deal not to include the
comment.

Cheers,
Martin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Ted Hardie
Sent: Saturday, 7 March 2009 5:44 AM
To: Brian Rosen; Edge, Stephen; Winterbottom, James; 'ECRIT'
Subject: Re: [Ecrit] Comments on Framework Draft

Individuals with experience in this realm have spoken about the issue
in the past and are raising the issue again.  Given that the IETF has
historically
said that the *best* way for progress to occur was to have technical
contributors contribute, I find this "send me a liaison statement and
we'll
talk" attitude baffling and inappropriate.

As for "agreeing to disagree", that's what I heard Stephen asking for
all along; a statement in the document that described its applicability.
I found your description of the end-to-end networks with edge
intelligence
both appropriate and accurate for the ECRIT case.  Why not include that,
along with a note saying that network architectures which rely upon
network support/command/control do not work using this set of
technologies
and aren't expected to develop in that direction?   Not including some
statement of applicability here seems more like an attempt to control
the
outcome by ignoring reality than anything else, and I don't believe
that's appropriate.

>IETF is well aware that many vendors and network operators openly
ignore

This sounds extraordinarily like you believe that all vendors and
network
operators *should* be following IETF standards and that the wise,
benevolent
IETF is saddened by the wayward behavior of these naughty children.

This is a technical body, trying to write specs that work in the real
world.
It is not divinely inspired, though I have written enough howlers into
my own
documents to wish it were.  Having Stephen request we recognize the
existence of other models in a BCP document for a process that we all
agree *must work the maximum out of time* seems either a good idea
or harmless.  Do we really not have the humility to manage that?

				Ted

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 9 Mar 2009 09:08:04 -0400

Ted

>empowered to definitively say it):

Then, there was an explicit effort to arrange a meeting with the relevant
3GPP and IETF people for the express purpose of seeing if we could move the
two sets of standards closer together.  That did not happen.  That is what I
was referring to.  I believe, although I am not able to speak for the IETF
that we are still interested.

Discussions and negotiations are not liaisons.  It was indeed talk: face to
face meetings, that was proposed.  3GPP and IETF have done this in other
areas in the past.

I tried to argue that the ecrit architecture IS applicable to mobile
networks such as 3GPP networks.  The standards permit network insertion of
location, and network routing (LoST query).  I believe is the most
appropriate architecture for IMS-like systems.  Given the market direction
of increasingly having the end device knowing its own location for various
location based applications, with a large number of them not directly tied
to the network operator (and thus being in the position that the endpoint
tells the application where it is), I think they will eventually get there.
Consider AOL/MSN/Yahoo IM.  Just what part of the current IMS architecture
is applicable to an emergency IM from AOL?  Or Skype, or whatever Apple
calls their iChat client in an iPhone when it eventually appears.  The
handset has to get it's location, and either run LoST itself, or the app
server runs LoST for it.  That's ecrit, and no amount of bashing what is
currently written for emergency calls in IMS is applicable.  The handset
could use SUPL as an LCP, and the latest change to -phonebcp covers that.

I'm reluctant to say that ecrit is not applicable to 3GPP/IMS.  We indeed
are going forward, knowing that 3GPP is unlikely to adopt the ecrit model
any time soon.  I think we often write a spec, believing it is the best
solution, but knowing it is unlikely that some (or many) existing networks
are likely to adopt it, at least right away.  The document purports to be
the BEST current practice, not the only practice.

Every BCP and every IETF standard could have a statement that says "Various
large networks may have their own solutions to the problem described, the
IETF hereby acknowledges that there are other ways to solve the problem".  I
don't think that helps much.

Brian

-----Original Message-----
From: Ted Hardie [mailto:[email-masked]] 
Sent: Friday, March 06, 2009 1:44 PM
To: Brian Rosen; Edge, Stephen; 'Winterbottom, James'; 'ECRIT'
Subject: Re: [Ecrit] Comments on Framework Draft

It is not divinely inspired, though I have written enough howlers into my
own

				Ted

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Mon, 9 Mar 2009 22:45:55 +0100

I've had this one sitting in my inbox for a while now thinking I ought to reply.

The answer to your specific use case is:

1)	If the VPN connection is at the IP level, then the mobile operator takes no responsibility for emergency calls made over that IP connection, and it is ip to the corporate network to deal with any emergency calls in an appropriate manner.

2)	If the relationship to the corporate network is created at the SIP level, e.g. via some form of business trunking arrangement, then it becomes the responsibility of the local proxy provider to handle emergency calls. In this case, the business trunking documents I am familiar with essentially say, make the emergency call as if you were a public network user (rather than as a corporate network user), and then the rules specified by 3GPP apply. Note that this is exactly the same thinking as when a 3GPP operator configures their roaming users to use a home network proxy rather than a local one, and then tells them to reregister if they want to make an emergency call, these things are all handled automatically within an IMS terminal.

regards

Keith

> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Winterbottom, James
> Sent: Thursday, February 26, 2009 4:48 AM
> 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
> 
> 
> 
> Sent: Thursday, 26 February 2009 1:11 PM
> To: Brian Rosen; 'ECRIT'
> 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
> 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.
> 
> 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.
> 
> 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
> 
>   
> 
> > From: [email-masked] 
> [mailto:[email-masked]] On Behalf 
> > Of Edge, Stephen
> > calls made over IP capable facilities to IP capable PSAPs. 
> It appears 
> > intended to cover all types of access network - including 
> fixed line, 
> > throughout the draft).
> > access and WiFi access associated with a cellular operator 
> (e.g. WLAN 
> differ from the 
> difference of 
> > 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
> > 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.
> > 
> 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 
> > routing versus for dispatch, cellular positioning methods. 
> Examples of 
> > the latter include use of location references and dereferencing and 
> > (in 3GPP, 3GPP2 and OMA) and the solution described in this 
> draft. The 
> > group may now deem fit to include.
> > 
> > Kind Regards
> > 
> > Stephen Edge (Qualcomm 3GPP SA2 participant), Kirk 
> Burroughs (Qualcomm

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Mon, 9 Mar 2009 22:46:33 +0100

That is making the assumption that IETF does not get sued when you try it on an phone connected to a 3GPP network and it fails to deliver it to a PSAP.

3GPP operators's have no responsibility to deliver an IETF solution to their end users. If IETF claims it should work, then they have to make it work, or else be sued.

Keith

> On Behalf Of Thomson, Martin
> Sent: Friday, February 27, 2009 5:45 AM
> There's benefit in knowing the limitations of a framework,
> and every architecture makes certain assumptions.  Let's
> examine them though...
>
> 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
>
>
> raising. The
> all access
> > 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.
> >
> the 3GPP
> > 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
> > framework and phonebcp documents exist in order to describe
> the ECRIT
> > solution:
> > behave as specified in these documents."
> >
> expert in
> system behave
> > 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.
> >
> > the office mid-next week.
> > >
> happened, it
> past. We are
> > 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.
> > >
> > > to changing fully specified and implemented standards to more
> > > closely
> > align
> > >> informative description of how terminals and networks should
> > >> support emergency calls made over IP capable facilities to IP
> > >> capable PSAPs. It
> > appears
> found that
> differ from
> > >> could reference the applicable wireless standards and point out
> > >> that these are valid alternatives for wireless cellular
> based access.
> > >>
> query and
> > >> the requirement that a terminal or at least a LIS will
> update the
> > >> PSAP whenever location changes. (a) is impractical due
> to network
> > >> 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
> phase 2 in
> draft that
> > >> solutions (in 3GPP, 3GPP2 and OMA) and the solution
> described in this draft.
> > The
> > >> wording for any disclaimer/applicability statement that
> the Ecrit
> > >> working
> > group

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Tue, 10 Mar 2009 00:01:02 +0200

>1)	If the VPN connection is at the IP level, then the 
>mobile operator takes no responsibility for emergency calls 
>made over that IP connection, and it is ip to the corporate 
>network to deal with any emergency calls in an appropriate manner.

No responsibility? What about location information that comes from the
access?

---

From: "Edge, Stephen" <[email-masked]>
Date: Mon, 9 Mar 2009 18:23:23 -0700

Hi Martin

Thanks for theses further comments - which I agree introduce a new twist to this discussion.

Your main assertion seems to be that most of the general points I raised are not matters for Ecrit to resolve and standardize but instead represent problems to be resolved for the particular AN (either by an SDO associated with the AN by or by some national SDO like NENA in the case of PSAP access). The list of such issues seems to be:

1. Access to PSTN capable PSAPs
2. Handover between different IP access networks
3. Handover to/from circuit mode networks
4. Location for cellular access
6. Support of unauthenticated users (and users in limited service state)

If I am generally right in this assumption, my first question is whether this is just your particular opinion or if this represents the view of Ecrit generally. E.G. is there any danger that Ecrit (or some other IETF group) might reclaim one or more of the above - perhaps after others SDOs (like 3GPP) have produced their own solutions? If you are all quite certain that this will not happen, or at least certain of this for some subset of the above, it would very much help to include a statement on this in the phoneBCP and/or framework drafts so there is no ambiguity.

My next comment is that solving the above for each type of AN probably represents most of difficulty in producing a comprehensive solution. For example, handover after a location URI has been obtained from a LIS will be problematic for continuing location (since the previous and now wrong LIS may receive the next location request). Similarly access and handover to restricted areas (cells or networks a user is not normally allowed to use) is problematic particularly if normal IP connectivity is assumed. Further, use of HELD with a control plane location solution is highly problematic for any 3GPP network because the current architecture and procedures are not able to support location requests initiated solely from a location server (like an SMLC or SAS) where there no prior interaction with the RAN and CN. Further to that, control plane solutions cannot often obtain location accurately enough for dispatch and need to incorporate terminal based positioning using say A-GPS which can lead to a user plane solution like SUPL. I could add other problem areas if you believe this list is exhaustive. Now I am not saying that these problem areas cannot be solved - 3GPP and 3GPP2 have in fact solved most of them (and should complete this by the end of this year) in the context of the 3GPP/3GPP2 solution. But your position now seems to be that any SDO must solve them subject to the various restrictions and requirements imposed by the Ecrit phoneBCP and Framework drafts. Can you confirm that this is so?

Kind Regards

Stephen
-----Original Message-----
From: Dawson, Martin [mailto:[email-masked]]
Sent: Thursday, March 05, 2009 10:56 PM
To: Edge, Stephen; [email-masked]
Cc: ECRIT
Subject: RE: [Ecrit] Comments on Framework Draft

Cheers,
Martin
-----Original Message-----

Brian

Kind Regards

Stephen
-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, February 27, 2009 6:53 AM
To: Edge, Stephen
Cc: Thomson, Martin; Richard Barnes; ECRIT
Subject: Re: [Ecrit] Comments on Framework Draft

Stephen

that
here
authenticated

Brian

to
VSP)
IP
the
that at
inapplicable to
that
here
authenticated
it
Ecrit
by
(or
that
be
it
of
not
really.
voice
ignorance
choice
We
Behalf
Ecrit)
and
concerns.
I-WLAN,
behave
an
calling
but
the
of
that
as
originating
sent
for
equivalently
Ecrit
them
multiple
participating.
to
It's
defined
OMA
informative
cellular
following
difference
by
one
could
these
fully
protocols
the
capable
terminal
in
restrictions
solutions
now
to
the
wording

---

From: "Dawson, Martin" <[email-masked]>
Date: Mon, 9 Mar 2009 21:28:06 -0500

Hi Stephen,

No - I'd say you've gotten hold of the wrong end of the stick; at least
in terms of the conclusion you're trying to drive.

What I'm saying is that none of the issues you brought up are specific
to cellular and that, further, a properly engineered access - whether it
is multi-technology or not - will support an ECRIT methodology
transparently.

To use an analogy, a DNS service in an access network can be similarly
affected by many of the types of considerations you raise. Nevertheless,
a DNS service can be quite transparently provided to clients running on
attached hosts, and without having to change their behaviour just
because it's a 3G network, despite this fact. By the same token, it
would hardly be appropriate for a DNS specification to start talking
about the sorts of things an access implementer might need to do to
achieve this.

Certainly, and ultimately, it's up to 3G network implementers whether
they want to support a general Internet emergency architecture (so that,
for example, an emergency client on a laptop with a 3G modem can work
just as well on that network as it would attached to a residential
Ethernet connection, or that an emergency calling client on a PSP could
work just as well on a 3G WiFi router as it would when attached to WiFi
hotspot). 

Alternatively, if the network implementer just wants to support a 3GPP
specific model for emergency calling that pre-supposes an IMS
subscription and which is targeted at conventional notions of handsets
then they also have the choice of following those context-limited
specifications of 3GPP.

There's no doubt, however, that the needs of the latter can be met by
implementing the infrastructure required for the former but the converse
is not true. You are quite correct to *not* say that the "problems" you
identify below can't be solved. They most certainly can - and it's
barely true to say that they are problematic. They are no more so than
any engineering challenge. If you don't think this sort of challenge
hasn't applied to cellular emergency services, despite 3GPP
specifications, then you must not have been involved in any
implementation.

You would be right to infer from my discourse that I think 3GPP could do
a much better, and more helpful, job of documenting how the ECRIT
emergency model should be supported. But they don't have to (and
certainly don't appear to be inclined to) for network implementers to be
able to do it anyway.

I see your tack here, now, is to try and get an alternative statement in
the framework - that could perhaps be used to make the argument that the
IETF doesn't know how ECRIT can be implemented in 3G networks. That
would be a misrepresentation of the point that these considerations are
out of scope and, as for the DNS example, it wouldn't be appropriate
anyway.

I don't presume to speak for the IETF. I think you know how it's
organized and that nobody can guarantee that somebody isn't going to
post some new proposal or other for a work item. Actually, you couldn't
get that kind of "we'll never venture to specify X" statement out of
3GPP either.

Cheers,
Martin

-----Original Message-----
From: Edge, Stephen [mailto:[email-masked]] 
Sent: Tuesday, 10 March 2009 12:23 PM
To: Dawson, Martin; [email-masked]
Cc: ECRIT
Subject: RE: [Ecrit] Comments on Framework Draft

Hi Martin

Thanks for theses further comments - which I agree introduce a new twist
to this discussion.

Your main assertion seems to be that most of the general points I raised
are not matters for Ecrit to resolve and standardize but instead
represent problems to be resolved for the particular AN (either by an
SDO associated with the AN by or by some national SDO like NENA in the
case of PSAP access). The list of such issues seems to be:

If I am generally right in this assumption, my first question is whether
this is just your particular opinion or if this represents the view of
Ecrit generally. E.G. is there any danger that Ecrit (or some other IETF
group) might reclaim one or more of the above - perhaps after others
SDOs (like 3GPP) have produced their own solutions? If you are all quite
certain that this will not happen, or at least certain of this for some
subset of the above, it would very much help to include a statement on
this in the phoneBCP and/or framework drafts so there is no ambiguity.

My next comment is that solving the above for each type of AN probably
represents most of difficulty in producing a comprehensive solution. For
example, handover after a location URI has been obtained from a LIS will
be problematic for continuing location (since the previous and now wrong
LIS may receive the next location request). Similarly access and
handover to restricted areas (cells or networks a user is not normally
allowed to use) is problematic particularly if normal IP connectivity is
assumed. Further, use of HELD with a control plane location solution is
highly problematic for any 3GPP network because the current architecture
and procedures are not able to support location requests initiated
solely from a location server (like an SMLC or SAS) where there no prior
interaction with the RAN and CN. Further to that, control plane
solutions cannot often obtain location accurately enough for dispatch
and need to incorporate terminal based positioning using say A-GPS which
can lead to a user plane solution like SUPL. I could add other problem
areas if you believe this list is exhaustive. Now I am not saying that
these problem areas cannot be solved - 3GPP and 3GPP2 have in fact
solved most of them (and should complete this by the end of this year)
in the context of the 3GPP/3GPP2 solution. But your position now seems
to be that any SDO must solve them subject to the various restrictions
and requirements imposed by the Ecrit phoneBCP and Framework drafts. Can
you confirm that this is so?

Kind Regards

Stephen
-----Original Message-----
From: Dawson, Martin [mailto:[email-masked]]
Sent: Thursday, March 05, 2009 10:56 PM
To: Edge, Stephen; [email-masked]
Cc: ECRIT
Subject: RE: [Ecrit] Comments on Framework Draft

Cheers,
Martin
-----Original Message-----

Brian

Kind Regards

Stephen
-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, February 27, 2009 6:53 AM
To: Edge, Stephen
Cc: Thomson, Martin; Richard Barnes; ECRIT
Subject: Re: [Ecrit] Comments on Framework Draft

Stephen

that
here
authenticated

Brian

to
VSP)
IP
the
that at
inapplicable to
that
here
authenticated
it
Ecrit
by
(or
that
be
it
of
not
really.
voice
ignorance
choice
We
Behalf
Ecrit)
and
concerns.
I-WLAN,
behave
an
calling
but
the
of
that
as
originating
sent
for
equivalently
Ecrit
them
multiple
participating.
to
It's
defined
OMA
informative
cellular
following
difference
by
one
could
these
fully
protocols
the
capable
terminal
in
restrictions
solutions
now
to
the
wording

---

From: "Edge, Stephen" <[email-masked]>
Date: Mon, 9 Mar 2009 19:39:16 -0700

Martin

Your earlier comments implied to me that you thought that problems 1, 2, 3, 4 and 6 were not the responsibility of Ecrit but that of individual SDOs associated with particular AN types or, in the case of PSTN capable PSAP access, some national SDO like NENA. Can you clarify whether that is true and, if not, who would or might standardize solutions for these?

Kind Regards

Stephen
-----Original Message-----
From: Dawson, Martin [mailto:[email-masked]]
Sent: Monday, March 09, 2009 7:28 PM
To: Edge, Stephen; [email-masked]
Cc: ECRIT
Subject: RE: [Ecrit] Comments on Framework Draft

Hi Stephen,

Cheers,
Martin

-----Original Message-----
From: Edge, Stephen [mailto:[email-masked]]
Sent: Tuesday, 10 March 2009 12:23 PM
To: Dawson, Martin; [email-masked]
Cc: ECRIT
Subject: RE: [Ecrit] Comments on Framework Draft

Hi Martin

Kind Regards

Stephen
-----Original Message-----
From: Dawson, Martin [mailto:[email-masked]]
Sent: Thursday, March 05, 2009 10:56 PM
To: Edge, Stephen; [email-masked]
Cc: ECRIT
Subject: RE: [Ecrit] Comments on Framework Draft

Cheers,
Martin
-----Original Message-----

Brian

Kind Regards

Stephen
-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, February 27, 2009 6:53 AM
To: Edge, Stephen
Cc: Thomson, Martin; Richard Barnes; ECRIT
Subject: Re: [Ecrit] Comments on Framework Draft

Stephen

that
here
authenticated

Brian

to
VSP)
IP
the
that at
inapplicable to
that
here
authenticated
it
Ecrit
by
(or
that
be
it
of
not
really.
voice
ignorance
choice
We
Behalf
Ecrit)
and
concerns.
I-WLAN,
behave
an
calling
but
the
of
that
as
originating
sent
for
equivalently
Ecrit
them
multiple
participating.
to
It's
defined
OMA
informative
cellular
following
difference
by
one
could
these
fully
protocols
the
capable
terminal
in
restrictions
solutions
now
to
the
wording

---

From: "Dawson, Martin" <[email-masked]>
Date: Mon, 9 Mar 2009 22:11:51 -0500

Hi Stephen,

Some things - like the exact manner in which the IP core should deliver
calls to a circuit service PSAP are clearly not within 3GPP's scope and,
if anyone is going to make such a specification, it should be the
appropriate body within the PSAP jurisdiction (e.g. NENA).
Alternatively, the problem is addressed on a PSAP by PSAP basis. Some
things, like how to do seamless mobile IP between the different access
technologies 3GPP considers to be in its remit so that ECRIT emergency
calls are supported seamlessly *could* be specified by 3GPP *if they
wanted to*. If 3GPP doesn't want to do it, then solutions can be
designed anyway. So - no - I wasn't implying that these organizations
have a responsibility to specify solutions to these things; but there
are some things which they could appropriately take on the specification
of - given a desire to be proactive.

Any organization (or individuals) could choose to document "standard"
approaches to doing these things. I actually challenge the implication
that 3GPP has documented how all these things are dealt with - even in
the narrow context of IMS emergency calling.

Alternatively, and to the extent that solutions can be built using
existing standard interfaces and configurations of network elements in
appropriate ways, then explicit standardization is not an imperative.

These are generally true comments. I don't particularly like stating
truisms but ultimately that's all you're driving at. Hence the
observation that the goal of the discussion is likely something other
than face value. It certainly wouldn't have been worth the effort if it
was.

Cheers,
Martin

-----Original Message-----
From: Edge, Stephen [mailto:[email-masked]] 
Sent: Tuesday, 10 March 2009 1:39 PM
To: Dawson, Martin; [email-masked]
Cc: ECRIT
Subject: RE: [Ecrit] Comments on Framework Draft

Martin

Your earlier comments implied to me that you thought that problems 1, 2,
3, 4 and 6 were not the responsibility of Ecrit but that of individual
SDOs associated with particular AN types or, in the case of PSTN capable
PSAP access, some national SDO like NENA. Can you clarify whether that
is true and, if not, who would or might standardize solutions for these?

Kind Regards

Stephen
-----Original Message-----
From: Dawson, Martin [mailto:[email-masked]]
Sent: Monday, March 09, 2009 7:28 PM
To: Edge, Stephen; [email-masked]
Cc: ECRIT
Subject: RE: [Ecrit] Comments on Framework Draft

Hi Stephen,

Cheers,
Martin

-----Original Message-----
From: Edge, Stephen [mailto:[email-masked]]
Sent: Tuesday, 10 March 2009 12:23 PM
To: Dawson, Martin; [email-masked]
Cc: ECRIT
Subject: RE: [Ecrit] Comments on Framework Draft

Hi Martin

Kind Regards

Stephen
-----Original Message-----
From: Dawson, Martin [mailto:[email-masked]]
Sent: Thursday, March 05, 2009 10:56 PM
To: Edge, Stephen; [email-masked]
Cc: ECRIT
Subject: RE: [Ecrit] Comments on Framework Draft

Cheers,
Martin
-----Original Message-----

Brian

Kind Regards

Stephen
-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, February 27, 2009 6:53 AM
To: Edge, Stephen
Cc: Thomson, Martin; Richard Barnes; ECRIT
Subject: Re: [Ecrit] Comments on Framework Draft

Stephen

that
here
authenticated

Brian

to
VSP)
IP
the
that at
inapplicable to
that
here
authenticated
it
Ecrit
by
(or
that
be
it
of
not
really.
voice
ignorance
choice
We
Behalf
Ecrit)
and
concerns.
I-WLAN,
behave
an
calling
but
the
of
that
as
originating
sent
for
equivalently
Ecrit
them
multiple
participating.
to
It's
defined
OMA
informative
cellular
following
difference
by
one
could
these
fully
protocols
the
capable
terminal
in
restrictions
solutions
now
to
the
wording

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 10 Mar 2009 09:48:02 -0400

Stephen

In today's emergency services systems, the PSAPs are PSTN connected, and
every country is different.  To use ecrit within a country, it probably
would take some nation-specific standardization to get ecrit originated
calls into a legacy PSAP. 

The expectation, which is supported by some evidence, is that as PSAPs move
to become IP connected, they will follow international standards, such as
ecrit.  Certainly, in North America, that will be true; IP connected PSAPs
will assume ecrit standards in the interface between the origination network
and the Emergency Services IP network (ESInet).  Regardless of what 3GPP
does, the interface into North American ESInets will be ecrit based.  This
should not be any burden on IMS systems; in NENA, we've spent some
considerable time making sure the current standards can be met by E-CSCFs
without introducing any other changes in 3GPP networks.  In fact, we've put
some work into making sure we can use an IMS network as an ESInet.

In the transition between CS and PS connected PSAPs, there will be some need
for nation-specific standards; we all start from different places, even if
we end up in the same place.  It may be that some of your concerns are
handled in that transition phase.

1. Access to PSTN capable PSAPs: is nation specific, and must be defined by
that nation.  This is unfortunate, but unavoidable.  Clearly there is a
gateway, which is the target of the LoST PSAP URI, but what happens on the
PSTN side of the gateway is very specific to the details of the emergency
system in a country at this time.  I don't think 3GPP can do much here
either, for the same reason.

2. Handover between different IP access networks: There are two aspects
here, the actual call origination, and the effect after the call is
established if the access network changes.  Generally, most of the
discussion in ecrit is on the session establishment, and that would take
place in one network; most systems don't actually allow handoff while doing
session establishment (often, if the session establishment is in progress,
handoff is either delayed, or the call attempt is dropped and retried after
the handoff).  There are small sections on mid call behavior, and on call
termination in our docs.  Most IETF protocols for IP handoff either have no
visibility to SIP, or require renegotiation of IP addresses, neither of
which would result in text in -framework or -phonebcp.  Thus, I'm not sure
there is any work needed for IP handoff, but if there is, I think we'd
welcome text.

3. Handover to/from circuit mode networks.  Again, this is a
mid-call/session termination issue, and not a session establishment issue,
and again, is not likely to have much effect on the documents at hand.  NENA
is working on North American specific legacy call origination (where the
origination is CS, and thus North American specific), which would put a
gateway between the CS origination network and the PS ESInet.  I'm not aware
of any IETF documents that discuss this in non-emergency calls, and we seem
to be okay.  I don't think there is any text needed in ecrit, given that.

4. Location for cellular access: we have covered that extensively in this
discussion.  Ecrit would permit the use of SUPL within the origination
network, although you have the router with the data card problem.  I will
tell you that NENA's standards would require that the E-CSCF interwork SUPL
to HELD, but that is not a big deal. 

5. Endpoint based routing: as has been pointed out, ecrit permits network
routing
 
6. Support of unauthenticated users (and users in limited service state):
This one might well be 3GPP specific, because 3GPP has a very specific
emergency registration process.  I doubt that other access networks would
want to copy the 3GPP mechanism.  There is some text in -framework on
unauthenticated access.  I don't see the IETF standardizing an emergency
registration mechanism, but you might propose it and see what happens.  I
think most networks either just allow an emergency call with no
registration, allow a registration but restrict what calls can be
made/received, or don't support emergency calls from non registered devices.

Brian

-----Original Message-----
From: Edge, Stephen [mailto:[email-masked]] 
Sent: Monday, March 09, 2009 9:23 PM
To: Dawson, Martin; [email-masked]
Cc: ECRIT
Subject: RE: [Ecrit] Comments on Framework Draft

Hi Martin

Thanks for theses further comments - which I agree introduce a new twist to
this discussion.

Your main assertion seems to be that most of the general points I raised are
not matters for Ecrit to resolve and standardize but instead represent
problems to be resolved for the particular AN (either by an SDO associated
with the AN by or by some national SDO like NENA in the case of PSAP
access). The list of such issues seems to be:

If I am generally right in this assumption, my first question is whether
this is just your particular opinion or if this represents the view of Ecrit
generally. E.G. is there any danger that Ecrit (or some other IETF group)
might reclaim one or more of the above - perhaps after others SDOs (like
3GPP) have produced their own solutions? If you are all quite certain that
this will not happen, or at least certain of this for some subset of the
above, it would very much help to include a statement on this in the
phoneBCP and/or framework drafts so there is no ambiguity.

My next comment is that solving the above for each type of AN probably
represents most of difficulty in producing a comprehensive solution. For
example, handover after a location URI has been obtained from a LIS will be
problematic for continuing location (since the previous and now wrong LIS
may receive the next location request). Similarly access and handover to
restricted areas (cells or networks a user is not normally allowed to use)
is problematic particularly if normal IP connectivity is assumed. Further,
use of HELD with a control plane location solution is highly problematic for
any 3GPP network because the current architecture and procedures are not
able to support location requests initiated solely from a location server
(like an SMLC or SAS) where there no prior interaction with the RAN and CN.
Further to that, control plane solutions cannot often obtain location
accurately enough for dispatch and need to incorporate terminal based
positioning using say A-GPS which can lead to a user plane solution like
SUPL. I could add other problem areas if you believe this list is
exhaustive. Now I am not saying that these problem areas cannot be solved -
3GPP and 3GPP2 have in fact solved most of them (and should complete this by
the end of this year) in the context of the 3GPP/3GPP2 solution. But your
position now seems to be that any SDO must solve them subject to the various
restrictions and requirements imposed by the Ecrit phoneBCP and Framework
drafts. Can you confirm that this is so?

Kind Regards

Stephen
-----Original Message-----
From: Dawson, Martin [mailto:[email-masked]]
Sent: Thursday, March 05, 2009 10:56 PM
To: Edge, Stephen; [email-masked]
Cc: ECRIT
Subject: RE: [Ecrit] Comments on Framework Draft

Cheers,
Martin
-----Original Message-----

Brian

Kind Regards

Stephen
-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, February 27, 2009 6:53 AM
To: Edge, Stephen
Cc: Thomson, Martin; Richard Barnes; ECRIT
Subject: Re: [Ecrit] Comments on Framework Draft

Stephen

that
here
authenticated

Brian

to
VSP)
IP
the
that at
inapplicable to
that
here
authenticated
it
Ecrit
by
(or
that
be
it
of
not
really.
voice
ignorance
choice
We
Behalf
Ecrit)
and
concerns.
I-WLAN,
behave
an
calling
but
the
of
that
as
originating
sent
for
equivalently
Ecrit
them
multiple
participating.
to
It's
defined
OMA
informative
cellular
following
difference
by
one
could
these
fully
protocols
the
capable
terminal
in
restrictions
solutions
now
to
the
wording

---

From: "Edge, Stephen" <[email-masked]>
Date: Tue, 10 Mar 2009 23:22:51 -0700

Brian

Thanks for these comments. I am rather slow at answering but this one seemed worth putting at the head of my backlog.

Both you and Martin seem to agree that most of the general objections I raised (points 1, 2, 3, 4 and 6) are not Ecrit specific issues but instead concern (or at least can concern) 3GPP/3GPP2 in the case of 3GPP/3GPP2 cellular access and (for 1) national SDOs like NENA. This does not diminish the size of the problems but just transplants them elsewhere. As a matter of fact, 3GPP/3GPP2 is already solving them for the PP solution and potentially could do the same in the case of Ecrit.

But your additional comments on the similarity of the 2 solutions suggests a possible resolution to the original issue we raised at the beginning of this discussion. This would be to adapt the phoneBCP and Framework spec.s so that the PP solution emerges as a legitimate solution for direct PP cellular access when the ED supports the full PP protocol stack. It would mean changing a number of requirements (e.g. adding more options) but need not involve sacrificing effective support for the other non-PP cases.

To put things more clearly, any device that is accessing a PP network and is aware of that would have the option of employing the current PP solution. A device that is accessing a PP network indirectly (e.g. via a router) would need to be enabled to discover that - e.g. through DHCP. This would enable inclusion of information (e.g. PP network identity) to the VSP to support subsequent location using possibly SUPL or HELD.

Such an approach ought to answer the issues we raised and solve the one that you have namely arriving at a globally suitable and agreeable solution for all access types.

Most likely, the detailed changes to the Framework and BCP would take some time to work out and agree but if we are to avoid 2 apparently conflicting solutions, could be the best way forward.

Kind Regards

Stephen
-----Original Message-----
From: Brian Rosen [mailto:[email-masked]]
Sent: Tuesday, March 10, 2009 6:48 AM
To: Edge, Stephen; 'Dawson, Martin'
Cc: 'ECRIT'
Subject: RE: [Ecrit] Comments on Framework Draft

Stephen

Brian

-----Original Message-----
From: Edge, Stephen [mailto:[email-masked]]
Sent: Monday, March 09, 2009 9:23 PM
To: Dawson, Martin; [email-masked]
Cc: ECRIT
Subject: RE: [Ecrit] Comments on Framework Draft

Hi Martin

Kind Regards

Stephen
-----Original Message-----
From: Dawson, Martin [mailto:[email-masked]]
Sent: Thursday, March 05, 2009 10:56 PM
To: Edge, Stephen; [email-masked]
Cc: ECRIT
Subject: RE: [Ecrit] Comments on Framework Draft

Cheers,
Martin
-----Original Message-----

Brian

Kind Regards

Stephen
-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, February 27, 2009 6:53 AM
To: Edge, Stephen
Cc: Thomson, Martin; Richard Barnes; ECRIT
Subject: Re: [Ecrit] Comments on Framework Draft

Stephen

that
here
authenticated

Brian

to
VSP)
IP
the
that at
inapplicable to
that
here
authenticated
it
Ecrit
by
(or
that
be
it
of
not
really.
voice
ignorance
choice
We
Behalf
Ecrit)
and
concerns.
I-WLAN,
behave
an
calling
but
the
of
that
as
originating
sent
for
equivalently
Ecrit
them
multiple
participating.
to
It's
defined
OMA
informative
cellular
following
difference
by
one
could
these
fully
protocols
the
capable
terminal
in
restrictions
solutions
now
to
the
wording