Re: [Ecrit] Comments on Framework Draft

["Edge, Stephen" <[e-mail]>]

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:[e-mail]]
Sent: Wednesday, March 04, 2009 7:56 PM
To: Edge, Stephen; [e-mail]
Cc: ECRIT
Subject: RE: [Ecrit] Comments on Framework Draft

Hi Stephen,

A few errors and clarifications.

Cheers
James

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of Edge, Stephen
Sent: Wednesday, 4 March 2009 4:32 PM
To: [e-mail]
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.

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.

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.

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

Perhaps I have misunderstood what you were trying to say.

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

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.

[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: [e-mail] [mailto:[e-mail]]
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
> -----Original Message-----
> From: Thomson, Martin [mailto:[e-mail]]
> Sent: Thursday, February 26, 2009 9:45 PM
> To: Edge, Stephen; Richard Barnes
> Cc: ECRIT
> Subject: RE: [Ecrit] Comments on Framework Draft
>
> 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
>
>
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]] 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
>> -----Original Message-----
>> From: Richard Barnes [mailto:[e-mail]]
>> Sent: Wednesday, February 25, 2009 6:30 PM
>> To: Edge, Stephen
>> Cc: Brian Rosen; 'ECRIT'
>> Subject: Re: [Ecrit] Comments on Framework Draft
>>
>> Hi Stephen,
>>
>> I'm a little confused by the scope of what you're asking.  The
>> framework
>> and phonebcp documents exist in order to describe the ECRIT solution:
>> They say, in effect, "SIP emergency calling works if all parties behave
>> as specified in these documents."
>>
>> As I understand what you're saying (and I'm by no means an expert in
>> 3GPP), 3GPP specifies that one or more elements of this system behave
>> differently.  This simply means that 3GPP networks aren't complying
>> with
>> these specs.  Just like there's no disclaimer in RFC 791 (IPv4) that
>> says "this doesn't work on X.25 networks", it's not clear to me that an
>> analogous disclaimer is called for here.
>>
>> I presume there are similar documents describing how emergency calling
>> works in 3GPP networks.  Do they include notes saying that the 3GPP
>> solution doesn't work in the broader Internet?
>>
>> --Richard
>>
>>
>>
>>
>>
>> Edge, Stephen wrote:
>> > Brian
>> >
>> > First of all apologies for the likely lateness of this reply - I
>> actually wrote it on 19 February in a 3GPP SA2 meeting in Budapest but
>> it seems unlikely that my VPN, Outlook server and WiFi access
>> capability will cooperate together to get it sent until I return to the
>> office mid-next week.
>> >
>> > Anyhow thanks for your comments. There have actually been a number of
>> conference calls between IETF and 3GPP participants over the last
>> couple of years at which common features like support of IP emergency
>> calls were discussed and these could have been good forum for
>> participants on either side to have raised the kinds of issues you
>> elaborate on below. Given that seems not so far to have happened, it
>> could still be possible in future such calls.
>> >
>> > But the issues we are raising are not directly to do with further
>> aligning the 2 solutions or with the lack of this in the past. We are
>> simply pointing out that the solutions are currently different and that
>> from a cellular wireless perspective, the Ecrit solution is not seen as
>> suitable in all respects (for support of IP emergency calls originating
>> from such access types). That is not just our point of view. 3GPP2 sent
>> a liaison to Ecrit some months ago pointing out the same issues.
>> >
>> > So we are proposing that the Ecrit framework and phoneBCP spec.s
>> include a statement acknowledging this - e.g. by referencing the
>> alternative 3GPP/3GPP2 solution and indicating the IP access types for
>> which the Ecrit solution will work without limitation (or equivalently
>> the access types where limitations are not ruled out).
>> >
>> > We are not proposing further modification and extension of the Ecrit
>> solution - just pointing out that this would be needed (as with the
>> 3GPP/3GPP2 solution) to fully cover all types of access.
>> >
>> > Kind Regards
>> >
>> > Stephen
>> > -----Original Message-----
>> > From: Brian Rosen [mailto:[e-mail]]
>> > Sent: Wednesday, February 18, 2009 8:07 PM
>> > To: Edge, Stephen; 'ECRIT'
>> > Subject: RE: [Ecrit] Comments on Framework Draft
>> >
>> > I have bit my tongue on this one for a long time.
>> >
>> > Stephen, with respect, please go talk to 3GPP management and ask them
>> why
>> > there has been no participation in the ecrit effort despite multiple
>> YEARS
>> > of begging them to get involved.  To put it frankly, 3GPP is quite
>> willing
>> > to bully IETF into doing its work on its schedule, but cannot be
>> bothered to
>> > get work done it knows it will eventually have to do when the IETF
>> asks it
>> > to do so.
>> >
>> > 3GPP understands the mess that is being created by not participating.
>> They
>> > know full well that when they finally get around to dealing with PS
>> > terminated emergency calls, that there will be a lot of resistance to
>> > changing fully specified and implemented standards to more closely
>> align
>> > with 3GPP standards.  I expect you will have several interworking
>> functions
>> > to define and build.
>> >
>> > So, politely, please go away, we're finishing work we dearly wanted
>> you all
>> > to be involved with for years, but you refused to do anything.  It's
>> too
>> > late for this rev.
>> >
>> > Now, having said that, there are quite a few people who have
>> participated in
>> > the IETF work who are IMS aware and I believe that despite your
>> fears,
>> > everything you need is in the specs.  The mechanisms we have defined
>> provide
>> > the ability for the network to insert location, recognize and mark
>> emergency
>> > calls, and route on behalf of endpoints.  An E-CSCF could quite
>> > straightforwardly provide a SIP call towards an ecrit compatible
>> PSAP.  The
>> > only not-quite-nice interwork would be from SUPL to HELD (or SIP),
>> but it's
>> > pretty easy to do that.  I'll also note that we have tried to get OMA
>> and
>> > IETF to cooperate on location protocols, but we have been
>> spectacularly
>> > unsuccessful at that effort also.
>> >
>> > Brian
>> >
>> >
>> >
>> >> -----Original Message-----
>> >> From: [e-mail] [mailto:[e-mail]] 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 capabilis 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
>> >> [e-mail]
>> >> https://www.ietf.org/mailman/listinfo/ecrit
>> >
>> > _______________________________________________
>> > Ecrit mailing list
>> > [e-mail]
>> > https://www.ietf.org/mailman/listinfo/ecrit
>> >
>> _______________________________________________
>> Ecrit mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/ecrit
>
> ------------------------------------------------------------------------------------------------
> 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]
> _______________________________________________
> Ecrit mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ecrit
>

_______________________________________________
Ecrit mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ecrit



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