Subject: [Ecrit] LoST

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 10 Jul 2007 21:58:12 +0200

Hi all,

during the WGLC we have received a number of comments. Then, we delayed 
the completion of the work because of the location hiding discussions.

Now, you can find the latest version of the document at:
http://www.tschofenig.priv.at/svn/draft-ietf-ecrit-lost/draft-ietf-ecrit-lost-06.txt

We have also updated the DHCP-based LoST discovery draft (based on the 
comments we received from the DHC working group). The document can be 
found here: 
http://www.tschofenig.priv.at/svn/draft-tschofenig-dhc-lost-discovery/draft-ietf-ecrit-dhc-lost-discovery-02.txt

Now, here is the unfortunate news: It seems that we did not submit the 
LoST draft :-(
Everyone was assuming that someone else is going to submit it.

Ciao
Hannes

PS: James has recently sent a number of comments. Some of them got 
reflected in the document (namely the editorial onces). Others got 
intentionally postponed since we discussed them already in the past.

_______________________________________________
Ecrit mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ecrit

---

From: "Winterbottom, James" <[email-masked]>
Date: Wed, 11 Jul 2007 01:00:36 -0500

Hi Hannes,

What exactly do you mean by postponed?

Cheers
James

> -----Original Message-----
> From: Hannes Tschofenig [mailto:[email-masked]]
> Sent: Wednesday, 11 July 2007 5:58 AM
> To: ECRIT
> Subject: [Ecrit] LoST
> 
> Hi all,
> 
http://www.tschofenig.com/svn/draft-ietf-ecrit-lost/draft-ietf-ecrit-los
t-
> 06.txt
http://www.tschofenig.com/svn/draft-tschofenig-dhc-lost-discovery/draft-
> ietf-ecrit-dhc-lost-discovery-02.txt
> 

------------------------------------------------------------------------------------------------
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: Hannes Tschofenig <[email-masked]>
Date: Wed, 11 Jul 2007 08:57:50 +0200

Hi James,

let me pick a concrete example: LoST server discovery.
Currently, we have specified the usage of DHCP and DNS. Only the former 
allows to discover the LoST server in the access network. I am, however, 
aware of the work on HELD discovery, see 
http://tools.ietf.org/wg/geopriv/draft-thomson-geopriv-lis-discovery-01.txt, 
that aims to discover a HELD server in the access network using DNS 
mechanisms.

Now, even though the current LoST draft does not describe how to 
discover a LoST server using DNS in the access network that can be 
extended later when the above document is generalized (which I think 
would be a good idea).

Does that make sense to you?

Ciao
Hannes

Winterbottom, James wrote:
>> during the WGLC we have received a number of comments. Then, we
>>     
> delayed
>   
> http://www.tschofenig.priv.at/svn/draft-ietf-ecrit-lost/draft-ietf-ecrit-los
> t-
>   
>> 06.txt
>>
> http://www.tschofenig.priv.at/svn/draft-tschofenig-dhc-lost-discovery/draft-
>

---

From: "Winterbottom, James" <[email-masked]>
Date: Wed, 11 Jul 2007 03:43:33 -0500

Hi Hannes,

That makes perfect sense.

The issue that I am most concerned about is the limitation in the shape
representation in the basic location profile. As it currently stands I
cannot use standard GPS related shapes, my end-point has to interpret
location and put into a profile. This is incompatible with a large
number of solutions deployed today on which many deployments will be
based, at least initially. I strongly urge this WG to reconsider this
restriction and include circle, and ellipse at a minimum.

Cheers
James

> Sent: Wednesday, 11 July 2007 4:58 PM
> To: Winterbottom, James
> Cc: ECRIT
> Subject: Re: [Ecrit] LoST
> 
> Hi James,
> 
> >> intentionally postponed since we discussed them already in the
past.
------------------------------------------------------------------------
> ------------------------
------------------------------------------------------------------------
> ------------------------

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 11 Jul 2007 10:55:27 +0200

Hi James,

> restriction and include circle, and ellipse at a minimum.
Some time back we also discussed this issue and the conclusion was the 
following:
* Let us build a mechanism in there to have a mechanism to extend the 
location shapes.
* Let us specify simple location shapes first.

I know that there is this limitation with geodetic shapes and a separate 
location profile would be needed to address GPS and the cellular world.
On the cellular aspect we also had a discussion with the 3GPP. There 
they are currently not using LoST at the end point since they are 
focusing on a different architecture (see 
http://tools.ietf.org/html/draft-tschofenig-ecrit-architecture-overview-00). 
Even if they would use LoST at the end point they most likely want to 
hide the location information of the end point or to make use of 
information like cell ids (as recorded in the issue tracker a while ago: 
http://www.tschofenig.priv.at:8080/lost/issue16).

Now, everything boils down to the question of GPS. Since GPS produces 
data in a format that is not PIDF-LO alike we can already assume that 
the end host has to understand the format. It can now encode it in 
different ways. In previous discussions a couple of us wanted to add a 
polygon as a location profile to the LoST document since it would also 
address the location hiding requirement. Since this issue came also up 
in the location hiding context we postpone this topic entirely.

Hence, it is up to us to come up with a location profile that supports
* a circle
* an ellipse
* a polygon,
* a combination of the above
* cell-ids
if we think there is a need todo so.

Ciao
Hannes

>> Currently, we have specified the usage of DHCP and DNS. Only the
>>     
> former
>   
>> allows to discover the LoST server in the access network. I am,
>>     
> however,
>   
>>>> the completion of the work because of the location hiding
>>>>         
> discussions.
>   
>>>> We have also updated the DHCP-based LoST discovery draft (based on
>>>>         
> the
>   
>>>> comments we received from the DHC working group). The document can
>>>>         
> be
>   
>>>> found here:
>>>>
>>>>
>>>>         
>>>> Now, here is the unfortunate news: It seems that we did not submit
>>>>         
> the
>   
>>>> LoST draft :-(
>>>> intentionally postponed since we discussed them already in the
>>>>         
> past.
>

---

From: "Winterbottom, James" <[email-masked]>
Date: Wed, 11 Jul 2007 04:04:35 -0500

Hi Hannes,

The concern I have is that GPS is not only cellular.
It is being used in WiFI and will be used from the get go in WiMAX.
The only profiles that will be mandatory to support are those in the
basic LoST specification, so the decision is generally unacceptable from
a deployment perspective.

I don't agree with the assessment below either.
I can easily see that LIS could provide a PIDF-LO to me that I have
provided satellite pseudo-ranges for. So again I remain unconvinced by
this debate. It is far simpler to interpret the ellipse and circle types
than a polygon, and to be frank from an end-point or measure location
perspective far more likely to be provided.

> Sent: Wednesday, 11 July 2007 6:55 PM
> To: Winterbottom, James
> Cc: ECRIT
http://tools.ietf.org/html/draft-tschofenig-ecrit-architecture-overview-
> 00).
http://tools.ietf.org/wg/geopriv/draft-thomson-geopriv-lis-discovery-
> >> 01.txt,

---

From: "Dawson, Martin" <[email-masked]>
Date: Wed, 11 Jul 2007 04:22:56 -0500

Hi Hannes,

This seems a bit bogged down in the here and now... A LIS for almost any
access technology, with or without GPS, could produce a geo-shape as a
consequence of the location-determination technique it employs. What
3GPP may be thinking now doesn't seem particularly pertinent.

There's already a pdif-lo-profile draft ([sic] is the spelling ever
going to get corrected btw or is a title immutable?) that states what
shapes should be used and defines what the LIS clients can expect to
receive.

While I accept that a LoST implementor could add support for that
profile, as long as it is optional to do so, the client cannot be sure
that anything other than a point will be supported. This adds the dual
issue of making the client always convert to a point form and/or
eliminating the prospect of LoST servers being able to do more
sophisticated routing based on weighted coverage by uncertainty.

Rather than invite the compatibility issue at a later date, wouldn't it
be more prudent just to add the requirement now?

Cheers,
Martin

-----Original Message-----
From: Hannes Tschofenig [mailto:[email-masked]] 
Sent: Wednesday, 11 July 2007 6:55 PM
To: Winterbottom, James
Cc: ECRIT
Subject: Re: [Ecrit] LoST

Hi James,

Ciao
Hannes

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 11 Jul 2007 11:26:01 +0200

Hi James,

> The concern I have is that GPS is not only cellular.
I know that GPS has nothing todo with cellular systems.
I haven't said that.

> a deployment perspective.
You can also define extensions that a mandatory to implement in another 
document.

> I don't agree with the assessment below either.
With with point in particular?

> provided satellite pseudo-ranges for.
Let's assume the GPS that is being used today. There is no PIDF-LO in use.

>  So again I remain unconvinced by
That's fine since we don't have a polygon in the LoST document either.

Ciao
Hanes

>>> The issue that I am most concerned about is the limitation in the
>>>       
> shape
>   
>>> representation in the basic location profile. As it currently stands
>>>       
> I
>   
>>> cannot use standard GPS related shapes, my end-point has to
>>>       
> interpret
>   
>>> based, at least initially. I strongly urge this WG to reconsider
>>>       
> this
>   
>> I know that there is this limitation with geodetic shapes and a
>>     
> separate
>   
>> location profile would be needed to address GPS and the cellular
>>     
> world.
>   
>> information like cell ids (as recorded in the issue tracker a while
>>     
> ago:
>   
>>>> extended later when the above document is generalized (which I
>>>>         
> think
>   
>>>> would be a good idea).
>>>>
>>>>>> We have also updated the DHCP-based LoST discovery draft (based
>>>>>>             
> on
>   
>>> the
>>>
>>>       
>>>>>> comments we received from the DHC working group). The document
>>>>>>             
> can
>   
>>> be
>>>
>>>       
>>>>>> found here:
>>>>>>
>>>>>>
>>>>>>
>>>>>>             
>>>>>> Now, here is the unfortunate news: It seems that we did not
>>>>>>             
> submit
>   
>>> the
>>>
>>>       
>>>>>> LoST draft :-(
>>>>>> PS: James has recently sent a number of comments. Some of them
>>>>>>             
> got
>   
>>>>>> reflected in the document (namely the editorial onces). Others
>>>>>>             
> got
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 11 Jul 2007 11:32:30 +0200

Hi Martin,

> 3GPP may be thinking now doesn't seem particularly pertinent.
True. A LCS (this is the correct terminology now) can indeed produce a 
PIDF-LO with the Geo-Shapes format.

When you use a GPS receiver today (and probably for a long time) then it 
does not produce a format in XML format since there is just no LCP 
involved.

> shapes should be used and defines what the LIS clients can expect to
We decided not to change the file name. When the document gets published 
as RFC then the filename does not matter anway.
Btw, we recognized the wrong spelling with version -04 or so.

> that anything other than a point will be supported.
A new document can also say that the new location profile is mandatory 
to implement. Do you think that will be a problem?

>  This adds the dual
No doubt that we could add an additional location profile right now.

I am just repeating what we agreed earlier in the working group on this 
particular issue. If the working group now thinks that this is a problem 
then we should re-consider it. I just want to open-up previously closed 
or postponed issues too quickly.

Ciao
Hannes

---

From: "Dawson, Martin" <[email-masked]>
Date: Wed, 11 Jul 2007 04:41:14 -0500

Thanks Hannes,

Yes, I'm suggesting that since the profile spec is about to go RFC, that
the LoST spec might just as well reference it so we have a consistent
ecology of specs. I think that having a subsequent spec make the profile
mandatory would only be an issue if it came after LoST was implemented.
On the other hand, if we assume it will happen before LoST is
implemented, then why not just include the requirement now.

With respect to GPS - a LIS (LCS, whatever) could utilize any suitable
protocol, including SUPL, to do GPS interactions with the client - it
still casts the result as a PIDF-LO in the response. I'm not really
thinking of the situation where the device does a GPS fix or gets it
from some other non-PIDF-LO source. In that case, I'd certainly agree
that the device may as well transcode it into the basic form. I'm not
really concerned about that situation.

Cheers,
Martin

-----Original Message-----
From: Hannes Tschofenig [mailto:[email-masked]] 
Sent: Wednesday, 11 July 2007 7:33 PM
To: Dawson, Martin
Cc: Winterbottom, James; ECRIT
Subject: Re: [Ecrit] LoST

Hi Martin,

Ciao
Hannes

I

separate
world.

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 11 Jul 2007 11:54:38 +0200

Hi Martin,

> implemented, then why not just include the requirement now.
I would like to let the group decide.

> really concerned about that situation.
I know about this feature in SUPL.
Still, do most GPS devices today use SUPL?

Ciao
Hannes

>> This seems a bit bogged down in the here and now... A LIS for almost
>>     
> any
>   
>> Rather than invite the compatibility issue at a later date, wouldn't
>>     
> it
>

---

From: "Dawson, Martin" <[email-masked]>
Date: Wed, 11 Jul 2007 05:06:40 -0500

Hi again,

Certainly - let the group decide... just casting my vote/opinion.

I don't know why it matters how many GPS devices use SUPL... I'm just
saying that a LIS will return a geo-shape for whatever reason. It may
not even use GPS; it might be serving a WiMAX access and be using signal
timing and base station location to determine the location/shape. The
device doesn't know or care. The point is that if the LIS is using the
PIDF-LO profile requirements to select a shape to provide, the device
might end up with one that the LoST server doesn't support unless LoST
is specified as also supporting at least these shapes.

If the question was just btw - I'd have to say that most GPS devices
don't use SUPL... I think most GPS devices are autonomous at this stage.

Cheers,
Martin

-----Original Message-----
From: Hannes Tschofenig [mailto:[email-masked]] 
Sent: Wednesday, 11 July 2007 7:55 PM
To: Dawson, Martin
Cc: Winterbottom, James; ECRIT
Subject: Re: [Ecrit] LoST

Hi Martin,

Ciao
Hannes

interpret
this

>> http://www.tschofenig.com:8080/lost/issue16).
>>

think
on
can
submit
got
got

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 11 Jul 2007 12:58:52 +0200

Hi Martin,

the question of the shape support is a question of deployment environments.

For (most) WLANs / DSL / PacketCable environments civic location is 
probably the best choice. There are certainly some WLANs (moving train, 
bus, plane, ship, etc.) where civic location information does not make a 
lot of sense but there a lot depends on the way how the WLAN is 
connected to another network.

For Wimax environment it depends on whether you talk about the work in 
the Wimax Forum or about the deployment of IEEE 802.16/802.16e networks 
in general. For the Wimax Forum no decision has been made with regard to 
the usage of specific protocols, as far as I know. For IEEE 802.16 again 
civic location is g good choice since it is essentially a replacement 
for DSL access. With IEEE 802.16e I could imagine that location hiding 
is again an important property for them.

For 3GPP / 3GPP we are talking about an environment where location 
hiding is probably most appropriate (when it comes to the information 
that is made available to the end host). That's what we learned in 
previous discussions.

For GPS usage at the end host only you are certainly right that circles 
& ellipse is a good choice. The big question is here:
* is it a big issue to translate them to a point
* does it introduce big error rates
Please also note that we are talking about emergency call routing in the 
context of LoST and not about dispatch. To approximate a circle with a 
radius of 3 meters with a point might not be a big problem.

Does this classification make sense to you?

This raises a related question: What location shapes would you introduce 
to LoST now that really require to be there (and where it cannot wait a 
little longer)?

Ciao
Hannes

Dawson, Martin wrote:
>> Yes, I'm suggesting that since the profile spec is about to go RFC,
>>     
> that
>   
>> ecology of specs. I think that having a subsequent spec make the
>>     
> profile
>   
>> mandatory would only be an issue if it came after LoST was
>>     
> implemented.
>   
>>> access technology, with or without GPS, could produce a geo-shape as
>>>       
> a
>   
>> When you use a GPS receiver today (and probably for a long time) then
>>     
> it
>   
>> We decided not to change the file name. When the document gets
>>     
> published
>   
>>> profile, as long as it is optional to do so, the client cannot be
>>>       
> sure
>   
>> I am just repeating what we agreed earlier in the working group on
>>     
> this 
>   
>> particular issue. If the working group now thinks that this is a
>>     
> problem
>   
>> then we should re-consider it. I just want to open-up previously
>>     
> closed 
>   
>>> Some time back we also discussed this issue and the conclusion was
>>>       
> the
>   
>>>     
>>>       
>>   
>>     
>>> following:
>>> different ways. In previous discussions a couple of us wanted to add
>>>       
> a
>   
>>>     
>>>       
>>   
>>     
>>> polygon as a location profile to the LoST document since it would
>>>       
> also
>   
>>>     
>>>       
>>   
>>     
>>> address the location hiding requirement. Since this issue came also
>>>       
> up
>   
>>>     
>>>       
>>   
>>     
>>> Hence, it is up to us to come up with a location profile that
>>>       
> supports
>   
>>> * a circle
>>> * an ellipse
>>> * a polygon,

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 11 Jul 2007 08:53:49 -0400

Three quick comments:

As far as I know, GPS devices produce a point plus (small)  
uncertainty, e.g., in the common NMEA output format (http://vancouver- 
webpages.com/peter/nmeafaq.txt). The uncertainty is so small and  
tends to fluctuate so much that including it in location mapping is  
pretty pointless, and it's probably of dubious value even for  
dispatch. (When I went geocaching recently with my kids, uncertainty  
on a modern SiRF-based device was around 18 - 25', under dense tree  
cover.)

That said, I think the complexity of including circles, arc band and  
ellipse is minimal. In all cases, the description includes a center  
point, which the LoST machinery could easily use to do the actual  
lookup. Thus, the additional complexity is mainly parsing these XML  
structures, which strikes me as not a big deal.

What gets complex is if a LoST resolver is forced to map shapes to  
multiple branches of the tree, what we have discussed in the past as  
the "forking" problem. For example, if a geo shape straddles the  
boundary between the US and Canada, you really don't want the LoST  
resolver gather results from both trees, decide how long it needs to  
wait for one or the other, and other issues. This requires  
significantly more protocol work, creates additional error conditions  
and increases implementation complexity.

A third point relates more to HELD than LoST: It's probably a good  
idea to be able to request a specific location profile, in the same  
spirit as in LoST, so that if newer, complex shapes can be  
accommodated easily in the future. We can then decide whether to  
define a LoST-like profile for HELD that only includes the current  
geo shapes, without endangering interoperability.

In summary: I'm not opposed to including the three additional shapes,  
as long as it is clear that the LoST server MAY use the center point  
for mapping.

Henning

On Jul 11, 2007, at 6:58 AM, Hannes Tschofenig wrote:

>
> For GPS usage at the end host only you are certainly right that  
> circles & ellipse is a good choice. The big question is here:
> Please also note that we are talking about emergency call routing  
> in the context of LoST and not about dispatch. To approximate a  
> circle with a radius of 3 meters with a point might not be a big  
> problem.
>

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 11 Jul 2007 09:23:28 -0400

On Jul 11, 2007, at 2:57 AM, Hannes Tschofenig wrote:

> think would be a good idea).

This isn't quite true; this is currently defined in Section 4 of  
LoST-06.

The sentence

Clients learn the LoST server's host name by means beyond the scope  
of this specification, such as SIP configuration and DHCP.

should probably be made a tad more precise. Copying from draft-ietf- 
sipping-config-framework:

--- begin ---

LoST servers may be operated by the local access network, a voice  
service provider and other parties. If not manually pre-configured, a  
LoST client discovers one or more LoST resolvers first in the local  
access network, then those provided by the VSP and then elsewhere. It  
attempts to access the resolvers in that order.

Clients that support DHCP MUST attempt to obtain the local IP network  
domain during the DHCP process described in
[RFC2132] and [RFC4704].

Clients using SIP first consult their local SIP configuration  
information. If that does not contain LoST resolver information, they  
extract the LoST host name as the 'hostname' portion of the address- 
of-record (AoR). If only a numeric IP address is provided in the AoR,  
the client MAY attempt to perform a reverse DNS lookup on that address.

Other discovery mechanisms may be defined in the future.

--- end ---

I think it would be a good idea to add this paragraph or two at the  
end of Section 4, as it allows for interoperable implementations.

Henning

---

From: "Dawson, Martin" <[email-masked]>
Date: Wed, 11 Jul 2007 09:04:47 -0500

Hi Hannes,

The pidf-lo-profile spec, as far as I know, is inclusive of the shapes
defined for 3G. This makes it a comprehensive set as far existing LCS
infrastructure is concerned (I'm using LCS in its existing 3GPP context
here - not as a simile for LIS). This makes it the safest set to require
LoST support for. I really don't think there's any point in trying to
analyse the current, or anticipate the future, status-quo other than
that. Technology is emerging all over the place.

I agree with Henning; it's not necessary to require the LoST server to
actually utilize the shapes - that's an internal procedure. It's only
the external semantics that I'm concerned about as far as compatibility
issues go.

Cheers,
Martin

-----Original Message-----
From: Hannes Tschofenig [mailto:[email-masked]] 
Sent: Wednesday, 11 July 2007 8:59 PM
To: Dawson, Martin
Cc: Winterbottom, James; ECRIT
Subject: Re: [Ecrit] LoST

Hi Martin,

the question of the shape support is a question of deployment
environments.

Ciao
Hannes

---

From: "Winterbottom, James" <[email-masked]>
Date: Wed, 11 Jul 2007 18:05:03 -0500

Hi Hannes,

> That's fine since we don't have a polygon in the LoST document either.

[AJW] Really? What is section 12.3 for then?

Cheers

James

---

From: "Winterbottom, James" <[email-masked]>
Date: Wed, 11 Jul 2007 19:40:41 -0500

Hi Henning,

Comments inline.

> From: Henning Schulzrinne [mailto:[email-masked]]
> Sent: Wednesday, 11 July 2007 10:54 PM
> To: Hannes Tschofenig
> Cc: ECRIT
[AJW] This can be larger if the device is cold-started and/or receives
assistance data. From handset-based phone testing we have done in the
past, 30 metre averages are not atypical.

> structures, which strikes me as not a big deal.

[AJW] Agreed.

> and increases implementation complexity.
[AJW] Agreed, I am happy for the internals of a LoST server to stay
internal. If people want to opt for complex GIS systems to manage
boundary cases then that is a matter of choice. I would like the option
of passing the geoshape to the LoST server however. 
 
> geo shapes, without endangering interoperability.

[AJW] let me think on this one a bit. We can talk in Chicago if you
like.

> as long as it is clear that the LoST server MAY use the center point

[AJW] Agreed.

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 12 Jul 2007 08:39:22 +0200

Hi all,

James and Henning have stated their opinion regarding the extension of 
location profiles.
It would be good to hear other opinions as well.

Ciao
Hannes

---

From: Ted Hardie <[email-masked]>
Date: Thu, 12 Jul 2007 10:03:20 -0700

>past, 30 metre averages are not atypical.

How does receiving assistance data fit into this?  Do you mean in the
case where there are few satellites visible to the device?  If so,
I think that is the aspect of operation which should be highlighted,
not the use of assistance data.

Has the handset testing data you've done on this been released?  Is
it available for the WG to review?

>> as long as it is clear that the LoST server MAY use the center point

This sounds like a reasonable compromise to me.
			regards,
				Ted

---

From: "Winterbottom, James" <[email-masked]>
Date: Thu, 12 Jul 2007 16:47:24 -0500

Ted,

This is probably a little off topic now. I shall answer as best I can
here and if you are interested in further discussion in Chicago we can
do that.

My experience with GPS systems has been that the amount of error gets
less the longer the thing is on. I am certainly not a GPS expert (though
we do have some in our office). Many of the handheld GPS systems sold
now contain differential GPS technology and almost all GPS systems in
cellular devices do not. With the former providing considerably accuracy
improvements over the latter.

If I have a mobile system that is cold-started and I give it assistance
data it will try and get a fix ASAP, indeed in most situations it has a
very strict time in which it needs to provide a location or it needn't
bother. The number of satellites that the handset can see certainly
enters into the equation, I know for example that there is a minimum
number (4 I think), but I don't know how much better the location gets
if you have more than that, or how much longer it takes to get
measurements with more satellites. Certainly handset implementations
vary from set to set for MS-Based solutions and so the location results
vary also. Carriers prefer consistency in this area and this is one
reason that some cellular providers are moving towards MS-Assisted
solutions.

I don't know if this particular handset data has been released, but I
can ask. I doubt that the handset vendor's name will have been released
however.

There may also be public submissions that have been made in general by
network operators opting for GPS as their wireless Phase II compliance
method.

Cheers
James

> From: Ted Hardie [mailto:[email-masked]]
> Sent: Friday, 13 July 2007 3:03 AM
> To: Winterbottom, James; Henning Schulzrinne; Hannes Tschofenig
> Cc: ECRIT
> Subject: RE: [Ecrit] LoST
>