Re: [Ecrit] Comments on Framework Draft

["Winterbottom, James" <[e-mail]>]

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.

 

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.

 

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

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

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