Subject: RE: [Geopriv] ResponseTime

From: [email-masked]
Date: Tue, 28 Aug 2007 11:23:40 -0400

Hmmm ....  This is tending towards more complicated, not less.   (Noting 
esp the proposal for possibly 3 parameters.) 

James wrote:
> Given my description of profiling above, would people be prepared to 
accept the following:
> 
> 1) No responseTime provided, you get AGAP, however long that takes.
> 2) responseTime = 0, you get ASAP
> 3) responseTime >0, you get best in time provided.
> 
> If people want other things, then they can profile those in HELD 
extensions.
> This meets Peter’s previous concern, if he wants minimal wired-client 
support, his HELD client says responseTime=0.
 
Actually, in a wired case where location is actually known virtually 
instantaneously, I would expect the client would include no ReponseTime 
parameter at all. 

How about a different compromise?  Since it *seems* to be the case that 
ResponseTime is primarily a concern for mobile devices (particularly 
cellular), how about it the parameter is an extension, but mobile devices 
(or ones which might be mobile, such as soft clients), by their nature, 
need to implement it.  This is predicated on others in cellular space also 
agreeing that ResponseTime is actually needed there.  (I am not a cellular 
expert, but also note most responses are coming from what Robert rightly 
termed "just the folks that were active in the discussion earlier" ;-)

-- Peter

"Winterbottom, James" <[email-masked]>
27.08.07 21:50
 
        To:     "Roger Marshall" <[email-masked]>, "Stuard, 
Doug" <[email-masked]>, "Dawson, Martin" 
<[email-masked]>, "Stark, Barbara" <[email-masked]>, 
<[email-masked]>, "Robert Sparks" <[email-masked]>
        cc:     "GEOPRIV" <[email-masked]>
        Subject:        RE: [Geopriv] ResponseTime

I don’t believe that time vs accuracy can be profiled well in this 
fashion.
You don’t actually know in many cases how accurate the result is going to 
be until you have started the location calculation.
 
Take cell-based location for example; I can go from femtocells with a few 
metre uncertainty to CDMA boomer cells with 200km radius.
Both fall in the 0 or sub-second time category, they could also fall into 
all of the categories you describe below for accuracy.
 
So I can have 0 : 2
And a 0 : 200,000
 
Since no device knows the kind of cell it is attached to every device is 
going to pick the first one,  2 metre accuracy in no time, and some are 
going to be sorely disappointed. If you specified a wait time of two 
seconds only, then those connected to a femtocell are happy, they have 
almost no wait time. Those connected to the boomer cell wait 2 seconds and 
get a 50 metre accuracy result. Since they were prepared to wait anyway, 
they are happy too, because 50m is way better than 200km.
 
The reality is that specifying the accuracy component becomes moot once 
you know how long the application is prepared to wait. The same is not 
true in the reverse direction. Indeed there is no general accuracy to 
wait-time profile that can be provided ahead of time, for any given 
wireless network this is a non-deterministic problem.
 
The LIS will pick the most accurate determination technique available in 
the time requested, and input to this decision may actually be acquired at 
the time the request is received. For example if you are connected to a 
femtocell then I am probably not going to bother to invoke anything else, 
if you are connected to a standard cell then I might. The point and type 
of access is important to the LIS here for determination, but it is likely 
completely unknown to the end-point and in many cases can’t be known.
 
Providing a time addresses these concerns in a deterministic manner that 
will work across all networks since the time is what the application is 
tolerant to, and the worst case is known. 
 
I have a need for a responseTime parameter. I am prepared to accept that 
others only want ASAP, and that others still claim they will want AGAP. I 
remain sceptical about the last one because this is normally qualified 
with a comment such as “within a reasonable time frame”. However, just 
because I can’t see it, doesn’t make it so.
 
Given my description of profiling above, would people be prepared to 
accept the following:
 
1) No responseTime provided, you get AGAP, however long that takes.
2) responseTime = 0, you get ASAP
3) responseTime >0, you get best in time provided.
 
If people want other things, then they can profile those in HELD 
extensions.
This meets Peter’s previous concern, if he wants minimal wired-client 
support, his HELD client says responseTime=0.
 
Cheers
James

From: Roger Marshall [mailto:[email-masked]] 
Sent: Tuesday, 28 August 2007 7:21 AM
To: Stuard, Doug; Dawson, Martin; Stark, Barbara; 
[email-masked]; Robert Sparks
Cc: GEOPRIV
Subject: RE: [Geopriv] ResponseTime
 
What about using two independents, or even three variables? 
 
Timing and Uncertainty are two variables that could, (if implemented 
rightly among the elements which determine location), provide additional 
control, as well as allow the server to choose among different back-end 
determination technologies, as Robert mentioned in this thread.
 
Examples of:
0 : 0 (means give me whatever location you have asap)
0 : 50 (means provide location which is reported as being within a radius 
of 50m asap)
30 : 50 (means provide a location inside a radius of 50m within 60 
seconds)
 
Coupling what is also done (by some vendors) within Wireless/CS domains 
today, you could add a third variable, though a 'confidence' parameter is 
still somewhat misunderstood (and certainly mis-applied), so most might 
want to set this third value to a constant for now:
 
30 : 50 : 95 (give me the location with a 50m or less tolerance, 
determined within 30 seconds with a confidence of at least 95%)
 
-roger marshall.

From: Stuard, Doug [mailto:[email-masked]] 
Sent: Monday, August 27, 2007 2:13 PM
To: Dawson, Martin; Stark, Barbara; [email-masked]; Robert 
Sparks
Cc: GEOPRIV
Subject: RE: [Geopriv] ResponseTime
Given the practical limits stated, option i) is good
Option ii) as stated seems too open ended.  If restated to “as accurate as 
you can get it within the stated time limit”, I think virtually all 
realistic use cases are covered.
 
In practice, a number of techniques converge within 20 seconds or so, so 
you could either wait until the stated time limit, or until (reasonable) 
convergence is achieved. 
 
Doug

From: Dawson, Martin [mailto:[email-masked]] 
Sent: Monday, August 27, 2007 4:46 PM
To: Stark, Barbara; [email-masked]; Robert Sparks
Cc: GEOPRIV
Subject: RE: [Geopriv] ResponseTime
 
The semantics of response time are “most accurate you can get within this 
time”.
 
I think I’ve seen both defaults proposed. That is, the absence of the 
response time parameter can be:
 
i)              As fast as possible at whatever accuracy that results in.
ii)             Take as long as you like until you think it’s as accurate 
as you can get it.
 
Given there are technologies that could see incremental (and diminishingly 
small) improvements in accuracy for every iteration/measurement – even if 
it went on all day – the LIS would have to apply its own interpretation of 
“accurate as you can get it” but that’s an invisible judgement as far as 
the client is concerned.
 
Obviously both defaults can’t apply. To me, logically, a response time of 
zero would mean as fast as possible (since zero can only have theoretical 
significance so it might as well have a special interpretation). That 
would leave option ii) as the default semantic.
 
Cheers,
Martin

From: Stark, Barbara [mailto:[email-masked]] 
Sent: Tuesday, 28 August 2007 6:30 AM
To: [email-masked]; Robert Sparks
Cc: GEOPRIV
Subject: RE: [Geopriv] ResponseTime
 
I think there is a need for a device to be able to ask for a "ASAP" vs. 
"accurate" response for location to be used when requesting emergency 
services. If it were totally optional, and not using it means "ASAP", then 
how does a device request "accurate"? I was suggesting using a default 
value, like 60 seconds (but hopefully recommended by phonebcp) to mean 
"accurate".
Barbara

From: [email-masked] [mailto:[email-masked]] 
Sent: Monday, August 27, 2007 2:39 PM
To: Robert Sparks
Cc: GEOPRIV
Subject: Re: [Geopriv] ResponseTime

Hi, 

> ... need to hear from more of the group than 
> just the folks that were active in the discussion earlier in the month 

I have stayed mostly out of the debate thus far, so here goes.   

I would support response time parameter ONLY as an optional extension. 
This for the following reasons: 

o I do not see value in it for the most part; I expect most applications 
(including ECS) simply don't need it or it would bring fairly minimal 
value added.   (I can certainly see some special cases / applications 
where it might be helpful, hence do see value as optional extension for 
those.)   

o It seems very difficult to make such a parameter specific enough to get 
the proposed value out of it in any consistent way, 

o MOST IMPORTANT I desperately want endpoints needing to support HELD for 
ECS purposes to have an absolutely ruthlessly simple subset of the 
functionality that they must implement.  The subset must be both small 
(footprint) and very easy to implement correctly.  Endpoints that want to 
do more than ECS can add to the simple subset by using extended options, 
but those that do only the ECS part need to be very constrained.  The 
value added bar needs to be set very high for the core subset.  The value 
of response time parameter in ECS does not make that grade for me.   

Just to be clear on that last point, I'm not all that concerned about the 
protocol itself (pretty easy) but more so about the implications to the 
rest of the implementation: What to do if response does not come back in 
requested time ... what to do if not at requested accuracy .. what if .. 
what if ....  And also I have the general concern of "feature creep", of 
which this is one potential example.   

-- Peter 
. 

Robert Sparks <[email-masked]> 
27.08.07 12:05 
 
        To:        GEOPRIV <[email-masked]> 
        cc:         
        Subject:        [Geopriv] ResponseTime

All -

Lets push to close on the responseTime question.

To do this, I'm going to need to hear from more of the group than 
just the folks that were active in the discussion earlier in the month.

So far, I've seen a good argument that a server can have different 
technologies available for determining location and would benefit 
from knowing something about how long a client is willing to wait in 
order to choose which one to focus on. There has been a question 
about an implicit time/accuracy tradeoff here and a suggestion that 
we should explore a more explicit separation of indicating those things.

I've also seen a good argument that it is unclear how a client 
implementation is going to provide values that would be useful to the 
server. Without more clarity around this point, I see discomfort from 
several people that the proposed mechanism is an opportunity for 
"Unintended Consequences" to rear its head.

On rereading the threads, I strongly suspect that there are a set of 
assumptions going into arguing for this parameter that haven't been 
made explicit yet, and I'd like to try a round of teasing those out 
to see if it closes the gap in the discussion.

Lets start with these two statements (which I _think_ the folks 
pushing for the parameter are assuming are true - correct what I have 
wrong please):

1) The clients will provide a useful indication of responseTime from 
the server's point of view.
2) Different clients (or different applications at the same client) 
will provide different enough values to make the same server choose 
different location technologies in servicing the query.

I can see the parameter helping a system work as long as the service 
has some way to tell the client what to ask for (and I recognize that 
means the client has to know what service it's invoking).

James  (or anyone else who has deployed or is developing a deployment 
of something like this) - do you expect to have some influence in a 
deployment over what the clients include in this parameter? Are you 
expecting to have a relationship with the vendors providing clients 
that lets you hand them values to hardcode,
or give you a configuration interface you can use as a service 
provider? Or are you expecting that to be entirely outside your control?

RjS

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

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

------------------------------------------------------------------------------------------------
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]
 
The information contained in this message may be privileged and/or 
confidential. If you are not the intended recipient, or responsible for 
delivering this message to the intended recipient, any review, forwarding, 
dissemination, distribution or copying of this communication or any 
attachment(s) is strictly prohibited. If you have received this message in 
error, please so notify the sender immediately, and delete it and all 
attachments from your computer and network.

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

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

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 28 Aug 2007 12:56:02 -0400

The simplest mechanism, if we’re starting at mechanism, is just the state of
one bit: “roughly now, at roughly whatever accuracy you can do, suitable for
routing” or “accurate, in a reasonable time, suitable for
display/dispatch/computation”, where the interpretation of “roughly” and
“reasonable” is up to the server.  "Reasonable" is also limited by HTTP and
other transport timeouts.

The extension is then the parameters, and I think you need more than one,
and I think you need a way for the server to tell the client what it could
do as well as a event notification/call back mechanism when the delay is
more than a couple of seconds.

I think we could progress the draft with a single bit, and have extensions,
later, for more.  I think most apps will do fine with that bit, and the ones
that need more, can have more.

That is the central question to me: is a single scalar so much more useful
than the bit that it should be in the base protocol?  I think the answer is
no.  You have a time/accuracy tradeoff and specifying time with no knowledge
of what the curve(s) looks like is inadequate.

The question after that is how much mechanism is useful for the next step? I
think that it's more than one scalar, it’s two or three, with a way for the
server to inform the client, and an event/call back mechanism.  I think that
could be written up in 3-4 pages of text, and it wouldn't be all that hard
to agree on the parameters and mechanisms if we agreed on the principles.

Brian

________________________________________
From: [email-masked] [mailto:[email-masked]] 
Sent: Tuesday, August 28, 2007 11:24 AM
To: Winterbottom, James
Cc: GEOPRIV; Dawson, Martin
Subject: RE: [Geopriv] ResponseTime

Hmmm ....  This is tending towards more complicated, not less.   (Noting esp
the proposal for possibly 3 parameters.)   

extensions. 

How about a different compromise?  Since it *seems* to be the case that
ResponseTime is primarily a concern for mobile devices (particularly
cellular), how about it the parameter is an extension, but mobile devices
(or ones which might be mobile, such as soft clients), by their nature, need
to implement it.  This is predicated on others in cellular space also
agreeing that ResponseTime is actually needed there.  (I am not a cellular
expert, but also note most responses are coming from what Robert rightly
termed "just the folks that were active in the discussion earlier" ;-) 

-- Peter 

        To:        "Roger Marshall" <[email-masked]>, "Stuard,
Doug" <[email-masked]>, "Dawson, Martin" <[email-masked]>,
"Stark, Barbara" <[email-masked]>, <[email-masked]>, "Robert
Sparks" <[email-masked]> 

I don’t believe that time vs accuracy can be profiled well in this fashion. 
You don’t actually know in many cases how accurate the result is going to be
until you have started the location calculation. 

So I can have 0 : 2 
And a 0 : 200,000 
  
Since no device knows the kind of cell it is attached to every device is
going to pick the first one,  2 metre accuracy in no time, and some are
going to be sorely disappointed. If you specified a wait time of two seconds
only, then those connected to a femtocell are happy, they have almost no
wait time. Those connected to the boomer cell wait 2 seconds and get a 50
metre accuracy result. Since they were prepared to wait anyway, they are
happy too, because 50m is way better than 200km. 
  
The reality is that specifying the accuracy component becomes moot once you
know how long the application is prepared to wait. The same is not true in
the reverse direction. Indeed there is no general accuracy to wait-time
profile that can be provided ahead of time, for any given wireless network
this is a non-deterministic problem. 
  
The LIS will pick the most accurate determination technique available in the
time requested, and input to this decision may actually be acquired at the
time the request is received. For example if you are connected to a
femtocell then I am probably not going to bother to invoke anything else, if
you are connected to a standard cell then I might. The point and type of
access is important to the LIS here for determination, but it is likely
completely unknown to the end-point and in many cases can’t be known. 

I have a need for a responseTime parameter. I am prepared to accept that
others only want ASAP, and that others still claim they will want AGAP. I
remain sceptical about the last one because this is normally qualified with
a comment such as “within a reasonable time frame”. However, just because I
can’t see it, doesn’t make it so. 
  
Given my description of profiling above, would people be prepared to accept
the following: 

If people want other things, then they can profile those in HELD extensions.

Cheers 
James 

________________________________________

  
Timing and Uncertainty are two variables that could, (if implemented rightly
among the elements which determine location), provide additional control, as
well as allow the server to choose among different back-end determination
technologies, as Robert mentioned in this thread. 
  
Examples of: 
0 : 0 (means give me whatever location you have asap) 
0 : 50 (means provide location which is reported as being within a radius of
50m asap) 
30 : 50 (means provide a location inside a radius of 50m within 60 seconds) 
  
Coupling what is also done (by some vendors) within Wireless/CS domains
today, you could add a third variable, though a 'confidence' parameter is
still somewhat misunderstood (and certainly mis-applied), so most might want
to set this third value to a constant for now: 
  
30 : 50 : 95 (give me the location with a 50m or less tolerance, determined
within 30 seconds with a confidence of at least 95%) 
  
-roger marshall. 

________________________________________

In practice, a number of techniques converge within 20 seconds or so, so you
could either wait until the stated time limit, or until (reasonable)
convergence is achieved. 
  
Doug 

  
  
i)              As fast as possible at whatever accuracy that results in. 
ii)             Take as long as you like until you think it’s as accurate as
you can get it. 
  
Given there are technologies that could see incremental (and diminishingly
small) improvements in accuracy for every iteration/measurement – even if it
went on all day – the LIS would have to apply its own interpretation of
“accurate as you can get it” but that’s an invisible judgement as far as the
client is concerned. 
  
Obviously both defaults can’t apply. To me, logically, a response time of
zero would mean as fast as possible (since zero can only have theoretical
significance so it might as well have a special interpretation). That would
leave option ii) as the default semantic. 
  
Cheers, 
Martin 

________________________________________

________________________________________

Hi, 

I would support response time parameter ONLY as an optional extension.  This
for the following reasons: 

o I do not see value in it for the most part; I expect most applications
(including ECS) simply don't need it or it would bring fairly minimal value
added.   (I can certainly see some special cases / applications where it
might be helpful, hence do see value as optional extension for those.)   

o MOST IMPORTANT I desperately want endpoints needing to support HELD for
ECS purposes to have an absolutely ruthlessly simple subset of the
functionality that they must implement.  The subset must be both small
(footprint) and very easy to implement correctly.  Endpoints that want to do
more than ECS can add to the simple subset by using extended options, but
those that do only the ECS part need to be very constrained.  The value
added bar needs to be set very high for the core subset.  The value of
response time parameter in ECS does not make that grade for me.   

Just to be clear on that last point, I'm not all that concerned about the
protocol itself (pretty easy) but more so about the implications to the rest
of the implementation: What to do if response does not come back in
requested time ... what to do if not at requested accuracy .. what if ..
what if ....  And also I have the general concern of "feature creep", of
which this is one potential example.   

-- Peter 
. 

All -

RjS

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

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

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

---

From: "Stuard, Doug" <[email-masked]>
Date: Tue, 28 Aug 2007 13:20:12 -0400

Using only two optional parameters:  (Time and Accuracy), I think all request cases can be addressed, and fairly simply:

1)      No time or accuracy specified:  “No location required” (inclusion of either optional parameter would require a location response). 

a.       It was suggested that this case might mean “AGAP, no time limit”, but how is “AGAP” determined? – there has to be some point at which calculations stop and a result is reported, either a time limit or an accuracy threshold or convergence (cases 2 and 6 below))

2)      No time specified, accuracy specified:  However long it takes to achieve the specified accuracy.

3)      Time=0, no accuracy specified:  ASAP with whatever accuracy is available*

4)      Time=0, accuracy specified: ASAP so long as specified accuracy met, otherwise fail.

a.       This case may be of limited usefulness.

5)      Time >0, no accuracy specified: AGAP within the specified time limit*

6)      Time >0, accuracy specified: AGAP within the time limit or until specified accuracy is achieved, whichever comes first.

*In cases where there is no accuracy specification (3&5), the accuracy should be included in the result if available. It may be included in the others as well.

Most database based responses would either be of type 1 (civic) or type 3 (fixed geo).

Emergency call routing would be based on a Type 3 request or a Type 5 with an appropriate time limit

Also, the definition of “accuracy” needs to be addressed.  For calculated accuracy as in wireless, the uncertainty at a specified confidence (90% is often mentioned) might be appropriate.

Doug

From: [email-masked] [mailto:[email-masked]] 
Sent: Tuesday, August 28, 2007 11:24 AM
To: Winterbottom, James
Cc: Stark, Barbara; Stuard, Doug; GEOPRIV; Dawson, Martin; Robert Sparks; Roger Marshall
Subject: RE: [Geopriv] ResponseTime

Hmmm ....  This is tending towards more complicated, not less.   (Noting esp the proposal for possibly 3 parameters.)   

James wrote: 
> Given my description of profiling above, would people be prepared to accept the following: 
> 
> This meets Peter’s previous concern, if he wants minimal wired-client support, his HELD client says responseTime=0. 
  
Actually, in a wired case where location is actually known virtually instantaneously, I would expect the client would include no ReponseTime parameter at all.   

How about a different compromise?  Since it *seems* to be the case that ResponseTime is primarily a concern for mobile devices (particularly cellular), how about it the parameter is an extension, but mobile devices (or ones which might be mobile, such as soft clients), by their nature, need to implement it.  This is predicated on others in cellular space also agreeing that ResponseTime is actually needed there.  (I am not a cellular expert, but also note most responses are coming from what Robert rightly termed "just the folks that were active in the discussion earlier" ;-) 

-- Peter

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 28 Aug 2007 13:48:36 -0400

Generally, I think this is getting there.  I think you want a way for the
server to tell the client what kinds of time/accuracy tradeoffs it can make.
Something simple would be fine.  I just want to see some way to represent
the time/accuracy curve(s), recognizing that they are non linear,
discontinuous and not completely controlled.  If the server always gives you
an answer within 100m in 30 seconds, no matter what you ask for, I'd like
the client to know that.  I'm not looking for the whole curve, just the
shape and dimensions.

Recognize that you described this as all gated on time, but you could have
described it based on accuracy and come out the same; there is a
time/accuracy tradeoff, it's non-linear, and you can hold one constant and
vary the other. 

Also need a mechanism to cope with time longer than a few seconds.

I agree that we need confidence.  I dearly would love to specify 90% and
leave it at that.  I fear we cannot.   Normally, this is something you get
back from the server, not an input parameter.

Brian

  _____  

From: Stuard, Doug [mailto:[email-masked]] 
Sent: Tuesday, August 28, 2007 1:20 PM
To: [email-masked]; Winterbottom, James
Cc: GEOPRIV; Dawson, Martin
Subject: RE: [Geopriv] ResponseTime

Using only two optional parameters:  (Time and Accuracy), I think all
request cases can be addressed, and fairly simply:

1)   No time or accuracy specified:  "No location required" (inclusion of
either optional parameter would require a location response). 

a.   It was suggested that this case might mean "AGAP, no time limit", but
how is "AGAP" determined? - there has to be some point at which calculations
stop and a result is reported, either a time limit or an accuracy threshold
or convergence (cases 2 and 6 below))

2)   No time specified, accuracy specified:  However long it takes to
achieve the specified accuracy.

3)   Time=0, no accuracy specified:  ASAP with whatever accuracy is
available*

4)   Time=0, accuracy specified: ASAP so long as specified accuracy met,
otherwise fail.

6)   Time >0, accuracy specified: AGAP within the time limit or until
specified accuracy is achieved, whichever comes first.

*In cases where there is no accuracy specification (3&5), the accuracy
should be included in the result if available. It may be included in the
others as well.

Most database based responses would either be of type 1 (civic) or type 3
(fixed geo).

Emergency call routing would be based on a Type 3 request or a Type 5 with
an appropriate time limit

Also, the definition of "accuracy" needs to be addressed.  For calculated
accuracy as in wireless, the uncertainty at a specified confidence (90% is
often mentioned) might be appropriate.

Doug

From: [email-masked] [mailto:[email-masked]] 
Sent: Tuesday, August 28, 2007 11:24 AM
To: Winterbottom, James
Cc: Stark, Barbara; Stuard, Doug; GEOPRIV; Dawson, Martin; Robert Sparks;
Roger Marshall
Subject: RE: [Geopriv] ResponseTime

extensions. 
> This meets Peter's previous concern, if he wants minimal wired-client

-- Peter

---

From: "Stuard, Doug" <[email-masked]>
Date: Tue, 28 Aug 2007 14:29:29 -0400

See embedded comments.

Doug

From: Brian Rosen [mailto:[email-masked]] 
Sent: Tuesday, August 28, 2007 1:49 PM
To: Stuard, Doug; [email-masked]; Winterbottom, James
Cc: 'GEOPRIV'; Dawson, Martin
Subject: RE: [Geopriv] ResponseTime

Generally, I think this is getting there.  I think you want a way for
the server to tell the client what kinds of time/accuracy tradeoffs it
can make.  Something simple would be fine.  I just want to see some way
to represent the time/accuracy curve(s), recognizing that they are non
linear, discontinuous and not completely controlled.  If the server
always gives you an answer within 100m in 30 seconds, no matter what you
ask for, I'd like the client to know that.  I'm not looking for the
whole curve, just the shape and dimensions.

[Stuard, Doug] The fact that the time/accuracy tradeoff is non-linear
and often discontinuous is irrelevant, as it cannot be known a priori by
the client OR by the server (except in a general way).  IMO the actual
shape of the curve matters little to the client.  Time and accuracy
thresholds are the key items that matter.  A client/application should
specify what it wants/needs, regardless of the server's apparent
intransigence. The client then must have a mechanism for dealing with a
response that is not entirely what it asked for (don't we all?). 

Recognize that you described this as all gated on time, but you could
have described it based on accuracy and come out the same;

[Stuard, Doug] Perhaps, but people are impatient, and the concept of
"good enough" is usually limited by "not soon enough" (Case 5)

 there is a time/accuracy tradeoff, it's non-linear, and you can hold
one constant and vary the other. 

[Stuard, Doug] This is in essence what you are doing with Case 5
(time>0, no accuracy specified), and Case 2 (accuracy specified, no time
limit).  You can do it either way.

[Stuard, Doug] Agreed

I agree that we need confidence.  I dearly would love to specify 90% and
leave it at that.  I fear we cannot.   Normally, this is something you
get back from the server, not an input parameter.

[Stuard, Doug] I would think the client/application would like to assume
a "standard" (there's that word again!) value.  Perhaps this would be
set at the server.  We don't need to replicate the current E9-1-1
confidence/uncertainty conundrum.  People understand uncertainty, but
confidence is often lost on them.  Better to settle on a reasonably good
but achievable confidence value (e.g., 90%, or whatever makes sense for
the application) then to leave it open.

Brian

________________________________

1)      No time or accuracy specified:  "No location required"
(inclusion of either optional parameter would require a location
response). 

a.       It was suggested that this case might mean "AGAP, no time
limit", but how is "AGAP" determined? - there has to be some point at
which calculations stop and a result is reported, either a time limit or
an accuracy threshold or convergence (cases 2 and 6 below))

4)      Time=0, accuracy specified: ASAP so long as specified accuracy
met, otherwise fail.

5)      Time >0, no accuracy specified: AGAP within the specified time
limit*

Most database based responses would either be of type 1 (civic) or type
3 (fixed geo).

Emergency call routing would be based on a Type 3 request or a Type 5
with an appropriate time limit

Also, the definition of "accuracy" needs to be addressed.  For
calculated accuracy as in wireless, the uncertainty at a specified
confidence (90% is often mentioned) might be appropriate.

Doug

From: [email-masked] [mailto:[email-masked]] 
Sent: Tuesday, August 28, 2007 11:24 AM
To: Winterbottom, James
Cc: Stark, Barbara; Stuard, Doug; GEOPRIV; Dawson, Martin; Robert
Sparks; Roger Marshall
Subject: RE: [Geopriv] ResponseTime

extensions. 

How about a different compromise?  Since it *seems* to be the case that
ResponseTime is primarily a concern for mobile devices (particularly
cellular), how about it the parameter is an extension, but mobile
devices (or ones which might be mobile, such as soft clients), by their
nature, need to implement it.  This is predicated on others in cellular
space also agreeing that ResponseTime is actually needed there.  (I am
not a cellular expert, but also note most responses are coming from what
Robert rightly termed "just the folks that were active in the discussion
earlier" ;-) 

-- Peter 

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

---

From: "Roger Marshall" <[email-masked]>
Date: Tue, 28 Aug 2007 11:50:15 -0700

I agree with Peter's notion of a compromise, though I'd suggest that
for:
 
-- civic location, only a single parameter is provided to denote 'asap'
vs. 'agap within t seconds', as a value, and
-- geo location, we punt for now and entertain more complex solutions in
the future, via extensions.
 
-roger marshall

	From: Stuard, Doug [mailto:[email-masked]] 
	Sent: Tuesday, August 28, 2007 11:29 AM
	To: Brian Rosen; [email-masked]; Winterbottom,
James
	Cc: GEOPRIV; Dawson, Martin
	Subject: RE: [Geopriv] ResponseTime

	See embedded comments.

	Doug

	To: Stuard, Doug; [email-masked]; Winterbottom,

	Generally, I think this is getting there.  I think you want a
way for the server to tell the client what kinds of time/accuracy
tradeoffs it can make.  Something simple would be fine.  I just want to
see some way to represent the time/accuracy curve(s), recognizing that
they are non linear, discontinuous and not completely controlled.  If
the server always gives you an answer within 100m in 30 seconds, no
matter what you ask for, I'd like the client to know that.  I'm not
looking for the whole curve, just the shape and dimensions.

	[Stuard, Doug] The fact that the time/accuracy tradeoff is
non-linear and often discontinuous is irrelevant, as it cannot be known
a priori by the client OR by the server (except in a general way).  IMO
the actual shape of the curve matters little to the client.  Time and
accuracy thresholds are the key items that matter.  A client/application
should specify what it wants/needs, regardless of the server's apparent
intransigence. The client then must have a mechanism for dealing with a
response that is not entirely what it asked for (don't we all?). 

	Recognize that you described this as all gated on time, but you
could have described it based on accuracy and come out the same;

	[Stuard, Doug] Perhaps, but people are impatient, and the
concept of "good enough" is usually limited by "not soon enough" (Case
5)

	 there is a time/accuracy tradeoff, it's non-linear, and you can
hold one constant and vary the other. 

	Also need a mechanism to cope with time longer than a few
seconds.

	[Stuard, Doug] Agreed

	I agree that we need confidence.  I dearly would love to specify
90% and leave it at that.  I fear we cannot.   Normally, this is
something you get back from the server, not an input parameter.

	[Stuard, Doug] I would think the client/application would like
to assume a "standard" (there's that word again!) value.  Perhaps this
would be set at the server.  We don't need to replicate the current
E9-1-1 confidence/uncertainty conundrum.  People understand uncertainty,
but confidence is often lost on them.  Better to settle on a reasonably
good but achievable confidence value (e.g., 90%, or whatever makes sense
for the application) then to leave it open.

	Brian

	Using only two optional parameters:  (Time and Accuracy), I
think all request cases can be addressed, and fairly simply:

	a.       It was suggested that this case might mean "AGAP, no
time limit", but how is "AGAP" determined? - there has to be some point
at which calculations stop and a result is reported, either a time limit
or an accuracy threshold or convergence (cases 2 and 6 below))

	2)      No time specified, accuracy specified:  However long it
takes to achieve the specified accuracy.

	3)      Time=0, no accuracy specified:  ASAP with whatever
accuracy is available*

	4)      Time=0, accuracy specified: ASAP so long as specified
accuracy met, otherwise fail.

	5)      Time >0, no accuracy specified: AGAP within the
specified time limit*

	6)      Time >0, accuracy specified: AGAP within the time limit
or until specified accuracy is achieved, whichever comes first.

	*In cases where there is no accuracy specification (3&5), the
accuracy should be included in the result if available. It may be
included in the others as well.

	Most database based responses would either be of type 1 (civic)
or type 3 (fixed geo).

	Emergency call routing would be based on a Type 3 request or a
Type 5 with an appropriate time limit

	Doug

	From: [email-masked]
[mailto:[email-masked]] 
	Sent: Tuesday, August 28, 2007 11:24 AM
	To: Winterbottom, James
	Cc: Stark, Barbara; Stuard, Doug; GEOPRIV; Dawson, Martin;
Robert Sparks; Roger Marshall
	Subject: RE: [Geopriv] ResponseTime

	Hmmm ....  This is tending towards more complicated, not less.
(Noting esp the proposal for possibly 3 parameters.)   
	
	James wrote: 
	> This meets Peter's previous concern, if he wants minimal
wired-client support, his HELD client says responseTime=0. 
	  
	Actually, in a wired case where location is actually known
virtually instantaneously, I would expect the client would include no
ReponseTime parameter at all.   
	
	How about a different compromise?  Since it *seems* to be the
case that ResponseTime is primarily a concern for mobile devices
(particularly cellular), how about it the parameter is an extension, but
mobile devices (or ones which might be mobile, such as soft clients), by
their nature, need to implement it.  This is predicated on others in
cellular space also agreeing that ResponseTime is actually needed there.
(I am not a cellular expert, but also note most responses are coming
from what Robert rightly termed "just the folks that were active in the
discussion earlier" ;-) 
	
	-- Peter 

The information contained in this message may be privileged and/or confidential. If you are not the intended recipient, or responsible for delivering this message to the intended recipient, any review, forwarding, dissemination, distribution or copying of this communication or any attachment(s) is strictly prohibited. If you have received this message in error, please so notify the sender immediately, and delete it and all attachments from your computer and network.

---

From: "Winterbottom, James" <[email-masked]>
Date: Tue, 28 Aug 2007 13:58:14 -0500

AGAP within t seconds is what we have now!

It has been shown quite clearly how this stuff can't be profiled before
hand except through response time.

Why punt when there is absolutely no need to do so?

 

From: Roger Marshall [mailto:[email-masked]] 
Sent: Wednesday, 29 August 2007 4:50 AM
To: Stuard, Doug; Brian Rosen; [email-masked];
Winterbottom, James
Cc: GEOPRIV; Dawson, Martin
Subject: RE: [Geopriv] ResponseTime

-roger marshall

	See embedded comments.

	Doug

	[Stuard, Doug] Agreed

	Brian

	Doug

	

	
	
	-- Peter 

	 

The information contained in this message may be privileged and/or
confidential. If you are not the intended recipient, or responsible for
delivering this message to the intended recipient, any review,
forwarding, dissemination, distribution or copying of this communication
or any attachment(s) is strictly prohibited. If you have received this
message in error, please so notify the sender immediately, and delete it
and all attachments from your computer and network.

---

From: "Stuard, Doug" <[email-masked]>
Date: Tue, 28 Aug 2007 14:58:58 -0400

What is the nature of the time/accuracy tradeoff for civic location?  In
2 seconds I can give you the state, in 10 the county and in 30 the city?

Doug

Sent: Tuesday, August 28, 2007 2:50 PM

-roger marshall

	See embedded comments.

	Doug

	[Stuard, Doug] Agreed

	Brian

	Doug

	

	
	
	-- Peter

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 28 Aug 2007 15:04:32 -0400

In line

  _____  

From: Stuard, Doug [mailto:[email-masked]] 
Sent: Tuesday, August 28, 2007 2:29 PM
To: Brian Rosen; [email-masked]; Winterbottom, James
Cc: GEOPRIV; Dawson, Martin
Subject: RE: [Geopriv] ResponseTime

See embedded comments.

Doug

[Stuard, Doug] The fact that the time/accuracy tradeoff is non-linear and
often discontinuous is irrelevant, as it cannot be known a priori by the
client OR by the server (except in a general way).  IMO the actual shape of
the curve matters little to the client.  Time and accuracy thresholds are
the key items that matter.  A client/application should specify what it
wants/needs, regardless of the server's apparent intransigence. The client
then must have a mechanism for dealing with a response that is not entirely
what it asked for (don't we all?). 

<br>The server knows what the curves look like.   It's not precise (this
much accuracy in this much time), but they know the shape.  I believe in
apps that adapt to reality, rather than assuming the server can always do
what the client wants.  The client wants infinite accuracy in zero time.  It
will put up with less, but it wants to know what it has to work with.  This
is a big stumbling block: you-all seem to think it's way too complicated for
a poor little app to understand, so give big daddy server your absolute drop
dead limits and big daddy will do the best it can.  I don't believe in big
daddy.  My apps can make use of whatever information you can give me.  You
all think there are finite limits that apps drop dead after.  There aren't;
all the numbers are arbitrary, and without any information they are really
arbitrary.

Recognize that you described this as all gated on time, but you could have
described it based on accuracy and come out the same;

[Stuard, Doug] Perhaps, but people are impatient, and the concept of "good
enough" is usually limited by "not soon enough" (Case 5)

 there is a time/accuracy tradeoff, it's non-linear, and you can hold one
constant and vary the other. 

[Stuard, Doug] This is in essence what you are doing with Case 5 (time>0, no
accuracy specified), and Case 2 (accuracy specified, no time limit).  You
can do it either way.

[Stuard, Doug] Agreed

[Stuard, Doug] I would think the client/application would like to assume a
"standard" (there's that word again!) value.  Perhaps this would be set at
the server.  We don't need to replicate the current E9-1-1
confidence/uncertainty conundrum.  People understand uncertainty, but
confidence is often lost on them.  Better to settle on a reasonably good but
achievable confidence value (e.g., 90%, or whatever makes sense for the
application) then to leave it open.

<br>Hey, I like it; if you can get everyone to agree, 90% is a good number!

Brian

  _____  

a.       It was suggested that this case might mean "AGAP, no time limit",
but how is "AGAP" determined? - there has to be some point at which
calculations stop and a result is reported, either a time limit or an
accuracy threshold or convergence (cases 2 and 6 below))

Doug

extensions. 

-- Peter

---

From: "Roger Marshall" <[email-masked]>
Date: Tue, 28 Aug 2007 12:10:41 -0700

Latency isn't always measured in the time it takes for a location server
to look up a row, but also, for example, for parlayed responses.
 
Some of the problems which exist today in the Wireless/CS space, not
accounted for here include:
 
-- "fast fix" vs. "normal fix", though the former could be construed as
a 'good enough' - even though it wouldn't always be the case (think
border conditions).
-- specification of different shape types with a 'given' confidence
(i.e., no input of client choice as to 67, 90, 95%, etc.)
 
A different approach is to return a set of coefficients to a
standardized formula (one already exists), with client input of
confidence level.  This covers all rotational shape types.  It doesn't
cover polygons.
 
-roger marshall. 

	From: Stuard, Doug [mailto:[email-masked]] 
	Sent: Tuesday, August 28, 2007 11:59 AM
	To: Roger Marshall; Brian Rosen; [email-masked];
Winterbottom, James
	Cc: GEOPRIV; Dawson, Martin
	Subject: RE: [Geopriv] ResponseTime

	What is the nature of the time/accuracy tradeoff for civic
location?  In 2 seconds I can give you the state, in 10 the county and
in 30 the city?

	Doug

	I agree with Peter's notion of a compromise, though I'd suggest
that for:

	-- civic location, only a single parameter is provided to denote
'asap' vs. 'agap within t seconds', as a value, and

	-- geo location, we punt for now and entertain more complex
solutions in the future, via extensions.

	-roger marshall

		To: Brian Rosen; [email-masked];

		See embedded comments.

		Doug

		To: Stuard, Doug; [email-masked];

		Generally, I think this is getting there.  I think you
want a way for the server to tell the client what kinds of time/accuracy
tradeoffs it can make.  Something simple would be fine.  I just want to
see some way to represent the time/accuracy curve(s), recognizing that
they are non linear, discontinuous and not completely controlled.  If
the server always gives you an answer within 100m in 30 seconds, no
matter what you ask for, I'd like the client to know that.  I'm not
looking for the whole curve, just the shape and dimensions.

		[Stuard, Doug] The fact that the time/accuracy tradeoff
is non-linear and often discontinuous is irrelevant, as it cannot be
known a priori by the client OR by the server (except in a general way).
IMO the actual shape of the curve matters little to the client.  Time
and accuracy thresholds are the key items that matter.  A
client/application should specify what it wants/needs, regardless of the
server's apparent intransigence. The client then must have a mechanism
for dealing with a response that is not entirely what it asked for
(don't we all?). 

		Recognize that you described this as all gated on time,
but you could have described it based on accuracy and come out the same;

		[Stuard, Doug] Perhaps, but people are impatient, and
the concept of "good enough" is usually limited by "not soon enough"
(Case 5)

		 there is a time/accuracy tradeoff, it's non-linear, and
you can hold one constant and vary the other. 

		[Stuard, Doug] This is in essence what you are doing
with Case 5 (time>0, no accuracy specified), and Case 2 (accuracy
specified, no time limit).  You can do it either way.

		Also need a mechanism to cope with time longer than a
few seconds.

		[Stuard, Doug] Agreed

		I agree that we need confidence.  I dearly would love to
specify 90% and leave it at that.  I fear we cannot.   Normally, this is
something you get back from the server, not an input parameter.

		[Stuard, Doug] I would think the client/application
would like to assume a "standard" (there's that word again!) value.
Perhaps this would be set at the server.  We don't need to replicate the
current E9-1-1 confidence/uncertainty conundrum.  People understand
uncertainty, but confidence is often lost on them.  Better to settle on
a reasonably good but achievable confidence value (e.g., 90%, or
whatever makes sense for the application) then to leave it open.

		Brian

		Using only two optional parameters:  (Time and
Accuracy), I think all request cases can be addressed, and fairly
simply:

		1)      No time or accuracy specified:  "No location
required" (inclusion of either optional parameter would require a
location response). 

		a.       It was suggested that this case might mean
"AGAP, no time limit", but how is "AGAP" determined? - there has to be
some point at which calculations stop and a result is reported, either a
time limit or an accuracy threshold or convergence (cases 2 and 6
below))

		2)      No time specified, accuracy specified:  However
long it takes to achieve the specified accuracy.

		3)      Time=0, no accuracy specified:  ASAP with
whatever accuracy is available*

		4)      Time=0, accuracy specified: ASAP so long as
specified accuracy met, otherwise fail.

		6)      Time >0, accuracy specified: AGAP within the
time limit or until specified accuracy is achieved, whichever comes
first.

		*In cases where there is no accuracy specification
(3&5), the accuracy should be included in the result if available. It
may be included in the others as well.

		Most database based responses would either be of type 1
(civic) or type 3 (fixed geo).

		Emergency call routing would be based on a Type 3
request or a Type 5 with an appropriate time limit

		Also, the definition of "accuracy" needs to be
addressed.  For calculated accuracy as in wireless, the uncertainty at a
specified confidence (90% is often mentioned) might be appropriate.

		Doug

		From: [email-masked]
[mailto:[email-masked]] 
		Sent: Tuesday, August 28, 2007 11:24 AM
		To: Winterbottom, James
		Cc: Stark, Barbara; Stuard, Doug; GEOPRIV; Dawson,
Martin; Robert Sparks; Roger Marshall
		Subject: RE: [Geopriv] ResponseTime

		Hmmm ....  This is tending towards more complicated, not
less.   (Noting esp the proposal for possibly 3 parameters.)   
		
		James wrote: 
		> This meets Peter's previous concern, if he wants
minimal wired-client support, his HELD client says responseTime=0. 
		  
		Actually, in a wired case where location is actually
known virtually instantaneously, I would expect the client would include
no ReponseTime parameter at all.   
		
		How about a different compromise?  Since it *seems* to
be the case that ResponseTime is primarily a concern for mobile devices
(particularly cellular), how about it the parameter is an extension, but
mobile devices (or ones which might be mobile, such as soft clients), by
their nature, need to implement it.  This is predicated on others in
cellular space also agreeing that ResponseTime is actually needed there.
(I am not a cellular expert, but also note most responses are coming
from what Robert rightly termed "just the folks that were active in the
discussion earlier" ;-) 
		
		-- Peter 

		 

	The information contained in this message may be privileged
and/or confidential. If you are not the intended recipient, or
responsible for delivering this message to the intended recipient, any
review, forwarding, dissemination, distribution or copying of this
communication or any attachment(s) is strictly prohibited. If you have
received this message in error, please so notify the sender immediately,
and delete it and all attachments from your computer and network.

---

From: "Stark, Barbara" <[email-masked]>
Date: Tue, 28 Aug 2007 15:29:51 -0400

I have a related question which I'd like to understand the answer to
before I can agree as to whether default behavior is to provide ASAP or
AGAP.
 
If a device asks for AGAP, and the server is set to only provide LbyR,
is the reference sent right away? I assume the server wouldn't even
start trying to figure out a LbyV until something tries to dereference.
Would responseTime have any meaning at all if the server only returns
references in response to HELD queries?
 
Barbara

*****

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

---

From: "Winterbottom, James" <[email-masked]>
Date: Tue, 28 Aug 2007 14:33:21 -0500

Yes, AGAP for a location URI provides an immediate response.

The request would be for the reference, not for what the reference may
point to when it is actually dereferenced.

Cheers

James

From: Stark, Barbara [mailto:[email-masked]] 
Sent: Wednesday, 29 August 2007 5:30 AM
To: Winterbottom, James; Roger Marshall; Stuard, Doug; Brian Rosen;
[email-masked]
Cc: GEOPRIV; Dawson, Martin
Subject: RE: [Geopriv] ResponseTime -- when reference is returned

Barbara

*****

material from all computers. GA625

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 28 Aug 2007 15:35:10 -0400

That would certainly be my interpretation.  

Brian

  _____  

Sent: Tuesday, August 28, 2007 3:30 PM

I have a related question which I'd like to understand the answer to before
I can agree as to whether default behavior is to provide ASAP or AGAP.

If a device asks for AGAP, and the server is set to only provide LbyR, is
the reference sent right away? I assume the server wouldn't even start
trying to figure out a LbyV until something tries to dereference. Would
responseTime have any meaning at all if the server only returns references
in response to HELD queries?

Barbara

*****

computers. GA625

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 28 Aug 2007 15:45:19 -0400

James pointed out to be that PIDF-LO profile actually does say use 67%.
While I'd much prefer 90 or 95%, a single standardized value beats any set
of values hands down.

Brian

  _____  

From: Brian Rosen [mailto:[email-masked]] 
Sent: Tuesday, August 28, 2007 3:05 PM
To: 'Stuard, Doug'; [email-masked]; 'Winterbottom, James'
Cc: 'GEOPRIV'; 'Dawson, Martin'
Subject: RE: [Geopriv] ResponseTime

In line

  _____  

See embedded comments.

Doug

[Stuard, Doug] Agreed

Brian

  _____  

Doug

extensions. 

-- Peter

---

From: "Roger Marshall" <[email-masked]>
Date: Tue, 28 Aug 2007 12:46:10 -0700

Keep in mind that if the 'location URI' were returned immediately, there
would be no claim as to whether it was backed up by an actual location
data - rather only an attempt at location fix.  On the other hand, if a
server only returns a location URI once the location is successfully
determined, then there is some implied 'quality' to the location URI.
Immediate return of a loc. uri tells you little, the location fix
attempt could have errored out, in which case the loc uri points to an
error, or worse, points to nothing.  Of course you could try to
dereference right away - after receiving a fresh loc uri, but you'd
better wait x number of seconds, 'cause these things take time.
 
-roger marshall.

	From: Winterbottom, James [mailto:[email-masked]]

	Sent: Tuesday, August 28, 2007 12:33 PM
	To: Stark, Barbara; Roger Marshall; Stuard, Doug; Brian Rosen;
[email-masked]
	Cc: GEOPRIV; Dawson, Martin
	Subject: RE: [Geopriv] ResponseTime -- when reference is
returned

	The request would be for the reference, not for what the
reference may point to when it is actually dereferenced.

	Cheers

	James

	From: Stark, Barbara [mailto:[email-masked]] 
	Sent: Wednesday, 29 August 2007 5:30 AM
	To: Winterbottom, James; Roger Marshall; Stuard, Doug; Brian
Rosen; [email-masked]
	Cc: GEOPRIV; Dawson, Martin
	Subject: RE: [Geopriv] ResponseTime -- when reference is
returned

	I have a related question which I'd like to understand the
answer to before I can agree as to whether default behavior is to
provide ASAP or AGAP.

	If a device asks for AGAP, and the server is set to only provide
LbyR, is the reference sent right away? I assume the server wouldn't
even start trying to figure out a LbyV until something tries to
dereference. Would responseTime have any meaning at all if the server
only returns references in response to HELD queries?

	Barbara

	*****

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

---

From: "Roger Marshall" <[email-masked]>
Date: Tue, 28 Aug 2007 12:53:02 -0700

This gets to the nagging problem of how good is 'good enough'?
Determining elements can certainly provide position, based on input of
67% confidence, but they can also do better.  If you're willing to wait
a few more seconds, they can churn out a more accurate result based on a
90 or 95% input value.  In fact, maybe they'll have to use 95% to get
the level of precision that some regulatory agency will ask for someday.
By providing confidence value as an input to these mechanisms, you can
achieve location hiding (to some degree) as well.
 
-roger marshall.

	From: Brian Rosen [mailto:[email-masked]] 
	Sent: Tuesday, August 28, 2007 12:45 PM
	To: 'Stuard, Doug'; [email-masked]; 'Winterbottom,
James'
	Cc: 'GEOPRIV'; 'Dawson, Martin'
	Subject: RE: [Geopriv] ResponseTime

	James pointed out to be that PIDF-LO profile actually does say
use 67%.  While I'd much prefer 90 or 95%, a single standardized value
beats any set of values hands down.

	Brian

	To: 'Stuard, Doug'; [email-masked]; 'Winterbottom,
James'

	In line

	See embedded comments.

	Doug

	<br>The server knows what the curves look like.   It's not
precise (this much accuracy in this much time), but they know the shape.
I believe in apps that adapt to reality, rather than assuming the server
can always do what the client wants.  The client wants infinite accuracy
in zero time.  It will put up with less, but it wants to know what it
has to work with.  This is a big stumbling block: you-all seem to think
it's way too complicated for a poor little app to understand, so give
big daddy server your absolute drop dead limits and big daddy will do
the best it can.  I don't believe in big daddy.  My apps can make use of
whatever information you can give me.  You all think there are finite
limits that apps drop dead after.  There aren't; all the numbers are
arbitrary, and without any information they are really arbitrary.

	[Stuard, Doug] Agreed

	<br>Hey, I like it; if you can get everyone to agree, 90% is a
good number!

	Brian

	Doug

	

	
	
	-- Peter

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 28 Aug 2007 16:01:24 -0400

Okay, but what are you proposing?

Having a standardized value is so much more useful than the absolute number.
Generally, every user I ever talked to was unable to use confidence unless
all sources gave them the same confidence.  If they varied, then they were
forced to ignore it; nothing they could think of doing: displaying,
calculating, dispatching, routing. could change based on the value of
confidence.

If you have the same value, then at least you can compare two locations from
different sources and they mean the same thing.  You still can't use
confidence for displaying, calculating, dispatching or routing.

  _____  

From: Roger Marshall [mailto:[email-masked]] 
Sent: Tuesday, August 28, 2007 3:53 PM
To: Brian Rosen; Stuard, Doug; [email-masked]; Winterbottom,
James
Cc: GEOPRIV; Dawson, Martin
Subject: RE: [Geopriv] ResponseTime

This gets to the nagging problem of how good is 'good enough'?  Determining
elements can certainly provide position, based on input of 67% confidence,
but they can also do better.  If you're willing to wait a few more seconds,
they can churn out a more accurate result based on a 90 or 95% input value.
In fact, maybe they'll have to use 95% to get the level of precision that
some regulatory agency will ask for someday.  By providing confidence value
as an input to these mechanisms, you can achieve location hiding (to some
degree) as well.

-roger marshall.

  _____  

Brian

  _____  

In line

  _____  

See embedded comments.

Doug

[Stuard, Doug] Agreed

Brian

  _____  

Doug

extensions. 

-- Peter

---

From: "Stark, Barbara" <[email-masked]>
Date: Tue, 28 Aug 2007 16:19:57 -0400

Since a location URI needs to be able to live for awhile, I think it
makes no sense for the server to start the location fixing process until
a dereference is attempted. There's no knowledge as to whether the
dereference attempt will happen now or in an hour.
 
But I am curious as to whether the reference will be noted as an "AGAP
or "ASAP" reference, or will a device be able to add some sort of 
"?response=ASAP" or "?response=AGAP" to the end of the reference.
Barbara

From: Roger Marshall [mailto:[email-masked]] 
Sent: Tuesday, August 28, 2007 3:46 PM
To: Winterbottom, James; Stark, Barbara; Stuard, Doug; Brian Rosen;
[email-masked]
Cc: GEOPRIV; Dawson, Martin
Subject: RE: [Geopriv] ResponseTime -- when reference is returned

-roger marshall.

	Cheers

	James

	Barbara

	*****

---

From: "Stuard, Doug" <[email-masked]>
Date: Tue, 28 Aug 2007 16:25:12 -0400

ESIF (based on PSAP input) has recommended that confidence values NOT be
displayed for this reason, as well as the fact that, even if consistent,
the concept would only add confusion to call takers.  As it stands
today, a call taker may know that, in general,  200 meter uncertainty
from wireless carrier A is equivalent to 150 meter uncertainty from
wireless carrier B.  If there were a common underlying confidence value
(note: the value itself would still not be displayed), then such "rules
of thumb" would be unnecessary, and uncertainly in all cases would have
a common basis.

Doug

From: Brian Rosen [mailto:[email-masked]] 
Sent: Tuesday, August 28, 2007 4:01 PM
To: 'Roger Marshall'; Stuard, Doug; [email-masked];
Winterbottom, James
Cc: 'GEOPRIV'; Dawson, Martin
Subject: RE: [Geopriv] ResponseTime

Having a standardized value is so much more useful than the absolute
number.  Generally, every user I ever talked to was unable to use
confidence unless all sources gave them the same confidence.  If they
varied, then they were forced to ignore it; nothing they could think of
doing: displaying, calculating, dispatching, routing... could change
based on the value of confidence.

If you have the same value, then at least you can compare two locations
from different sources and they mean the same thing.  You still can't
use confidence for displaying, calculating, dispatching or routing.

To: Brian Rosen; Stuard, Doug; [email-masked];

-roger marshall.

	Brian

---

From: "Roger Marshall" <[email-masked]>
Date: Tue, 28 Aug 2007 13:50:39 -0700

One way to reduce complexity (may not sound like it at first) is to:
 
-- program: one standardized function (produces 7 coefficients from a
couple of inputs) to describe any common shape
-- input: a combination of confidence, uncertainty (max), and timing
(max) as input variables
-- output: the 7 coefficients, plug them in and present the
location/shape
 
The client gets to control everything through input variables, whether
it's an end device, middlebox, or PSAP client.
One client (e.g., the end-device) can use a low time, a low confidence
to get routing information, gets the coefficients - and the PSAP client
reuses the conveyed coeff's along with their 'standard' 95% confidence
input value.
 
-roger marshall. 

	From: Brian Rosen [mailto:[email-masked]] 
	Sent: Tuesday, August 28, 2007 1:01 PM
	To: Roger Marshall; 'Stuard, Doug'; [email-masked];
'Winterbottom, James'
	Cc: 'GEOPRIV'; 'Dawson, Martin'
	Subject: RE: [Geopriv] ResponseTime

	Having a standardized value is so much more useful than the
absolute number.  Generally, every user I ever talked to was unable to
use confidence unless all sources gave them the same confidence.  If
they varied, then they were forced to ignore it; nothing they could
think of doing: displaying, calculating, dispatching, routing... could
change based on the value of confidence.

	If you have the same value, then at least you can compare two
locations from different sources and they mean the same thing.  You
still can't use confidence for displaying, calculating, dispatching or
routing.

	-roger marshall.

		To: 'Stuard, Doug'; [email-masked];
'Winterbottom, James'

		James pointed out to be that PIDF-LO profile actually
does say use 67%.  While I'd much prefer 90 or 95%, a single
standardized value beats any set of values hands down.

		Brian

		To: 'Stuard, Doug'; [email-masked];
'Winterbottom, James'

		In line

		See embedded comments.

		Doug

		<br>The server knows what the curves look like.   It's
not precise (this much accuracy in this much time), but they know the
shape.  I believe in apps that adapt to reality, rather than assuming
the server can always do what the client wants.  The client wants
infinite accuracy in zero time.  It will put up with less, but it wants
to know what it has to work with.  This is a big stumbling block:
you-all seem to think it's way too complicated for a poor little app to
understand, so give big daddy server your absolute drop dead limits and
big daddy will do the best it can.  I don't believe in big daddy.  My
apps can make use of whatever information you can give me.  You all
think there are finite limits that apps drop dead after.  There aren't;
all the numbers are arbitrary, and without any information they are
really arbitrary.

		[Stuard, Doug] Agreed

		<br>Hey, I like it; if you can get everyone to agree,
90% is a good number!

		Brian

		Doug

		

		
		
		-- Peter

---

From: "Dawson, Martin" <[email-masked]>
Date: Tue, 28 Aug 2007 15:52:27 -0500

If the choice - as you seem to be suggesting - is between one bit (inadequate in my estimation) and a full blown profiling, multi-parameter, request and backoff with reference mechanism (overblown, overcomplicated, and impractical in my estimation) then I still haven't got the functionality that I require (a simple scalar response time).

Why can't I have this optional parameter in the base spec? What is the semantic difference between this and an optional extension? A client doesn't have to use base spec option and, with respect to this parameter, a LIS can choose to ignore it. Why can't we just have it in the base spec now? Where's the spirit of compromise? The scalar parameter with the default semantics I described cover your requirements as well as meet mine. What's the obsession with limiting communication to a single bit?

Also - I don't understand the implication that it can be pre-judged whether a client needs response time or not. The suggestion seems to be that this is "only a wireless problem" - but that doesn't mean it's not a consideration for every client implementation. If I'm implementing an application on a laptop, how do I know whether it is going to be on a wireless access or not. I can't even use the network adaptor as any guide - as has been mentioned, the physical network connection doesn't actually indicate the nature of the Internet access (ref the RV/LAN scenario).

Cheers,
Martin

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Wednesday, 29 August 2007 2:56 AM
To: [email-masked]; Winterbottom, James
Cc: 'GEOPRIV'; Dawson, Martin
Subject: RE: [Geopriv] ResponseTime

The simplest mechanism, if we're starting at mechanism, is just the state of
one bit: "roughly now, at roughly whatever accuracy you can do, suitable for
routing" or "accurate, in a reasonable time, suitable for
display/dispatch/computation", where the interpretation of "roughly" and
"reasonable" is up to the server.  "Reasonable" is also limited by HTTP and
other transport timeouts.

think that it's more than one scalar, it's two or three, with a way for the

Brian

extensions. 

-- Peter 

I don't believe that time vs accuracy can be profiled well in this fashion. 
You don't actually know in many cases how accurate the result is going to be
until you have started the location calculation. 

So I can have 0 : 2 
And a 0 : 200,000 

  
completely unknown to the end-point and in many cases can't be known. 

I have a need for a responseTime parameter. I am prepared to accept that
others only want ASAP, and that others still claim they will want AGAP. I
remain sceptical about the last one because this is normally qualified with
a comment such as "within a reasonable time frame". However, just because I
can't see it, doesn't make it so. 

  

Cheers 
James 

  

Examples of: 

  
-roger marshall. 

From: Stuard, Doug [mailto:[email-masked]] 
Sent: Monday, August 27, 2007 2:13 PM
To: Dawson, Martin; Stark, Barbara; [email-masked]; Robert
Sparks
Cc: GEOPRIV
Subject: RE: [Geopriv] ResponseTime 
Given the practical limits stated, option i) is good 
Option ii) as stated seems too open ended.  If restated to "as accurate as
you can get it within the stated time limit", I think virtually all
realistic use cases are covered. 

Doug 

The semantics of response time are "most accurate you can get within this
time". 
  
I think I've seen both defaults proposed. That is, the absence of the
response time parameter can be: 
  
i)              As fast as possible at whatever accuracy that results in. 
ii)             Take as long as you like until you think it's as accurate as
you can get it. 
  
Given there are technologies that could see incremental (and diminishingly
small) improvements in accuracy for every iteration/measurement - even if it
went on all day - the LIS would have to apply its own interpretation of
"accurate as you can get it" but that's an invisible judgement as far as the
client is concerned. 
  
Obviously both defaults can't apply. To me, logically, a response time of
zero would mean as fast as possible (since zero can only have theoretical
significance so it might as well have a special interpretation). That would
leave option ii) as the default semantic. 
  
Cheers, 
Martin 

  

Hi, 

-- Peter 
. 

All -

RjS

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 28 Aug 2007 16:53:04 -0400

I just asked my NENA experts.  They said "90%, not 67%".  1/3 error is not
acceptable.  1/10 is acceptable.

I've discussed this with a couple of real engineering experts a few times.
I'm not sure I really "get" the underlying issues, but I think I understand
that it's a completely arbitrary number.  You can, with anyone's equipment,
calculate uncertainty at any confidence value you want.  In many, but not
all systems, you can convert from one uncertainty value at confidence X to
another uncertainty value at confidence Y with math.  If my understanding is
correct, there is no engineering reason not to set the confidence (remember
it's SHOULD) to 90%.  Of course, NENA would like 95%.

If my understanding is wrong, I sure would like to be educated, either with
everyone else on the list or privately.

Doug, if you were designing a PSAP workstation, and you had uncertainty at
65%, and then someone came along and told you it was being changed to 90%,
what would you change?

            Would you display something different?

            Would you calculate something different?

            Would you train the operator differently?

I know that the folks who go out in the field and verify accuracy WOULD use
the value, but I don't think a call taker, with the very best equipment,
would see, hear, taste, or act differently if the confidence value changed.
The folks who verify accuracy would, the call takers would not.

Just for fun, although there is an obvious display difference you can show
with varying uncertainty (say a circle instead of a point), my sources say
there is NOTHING WHATSOEVER that can be done with the data other than have
the nice display.  They don't change interaction with the caller, the
responder or the dispatcher in any way if it's 10M 100M or 1000M.  They take
the point as a point and dispatch to the closest street address to that
point.  They don't change who is sent, when they are sent, or what they are
told.  These are not stupid people.  Uncertainty is something they
understand, and care a lot about, but they can't actually USE it to help a
call taker, dispatcher or responder.  Again, the verification people use it
as it is intended to be used.

I'm told that the same is true of navigation apps: uncertainty and
confidence are used in the spec sheet, but never enter into the product
design.

I have never been told of any app that ever used confidence or uncertainty
other than using uncertainty in a display, and even then, most users turn
the function off.

Brian

  _____  

From: Stuard, Doug [mailto:[email-masked]] 
Sent: Tuesday, August 28, 2007 4:25 PM
To: Brian Rosen; Roger Marshall; [email-masked]; Winterbottom,
James
Cc: GEOPRIV; Dawson, Martin
Subject: RE: [Geopriv] ResponseTime

ESIF (based on PSAP input) has recommended that confidence values NOT be
displayed for this reason, as well as the fact that, even if consistent, the
concept would only add confusion to call takers.  As it stands today, a call
taker may know that, in general,  200 meter uncertainty from wireless
carrier A is equivalent to 150 meter uncertainty from wireless carrier B.
If there were a common underlying confidence value (note: the value itself
would still not be displayed), then such "rules of thumb" would be
unnecessary, and uncertainly in all cases would have a common basis.

Doug

  _____  

-roger marshall.

  _____  

Brian

---

From: "Dawson, Martin" <[email-masked]>
Date: Tue, 28 Aug 2007 15:57:37 -0500

I really don't see how this meets the "keep it simple" test. I'd argue
that a simple scalar response time parameter is simple. I couldn't agree
that returning accuracy/time tradeoff curves is at all simple. It's also
impractical.

As soon as you put an accuracy requirement in, you have to define
semantics for that requirement not being met. The server can always meet
a response time requirement (if it wants). But what should the server do
if the accuracy requirement isn't met? Should it return a specific error
code or should it return the location it was able to determine and let
the application choose?

Cheers,

Martin

Sent: Wednesday, 29 August 2007 3:49 AM

Recognize that you described this as all gated on time, but you could
have described it based on accuracy and come out the same; there is a
time/accuracy tradeoff, it's non-linear, and you can hold one constant
and vary the other. 

Brian

1)   No time or accuracy specified:  "No location required" (inclusion
of either optional parameter would require a location response). 

Doug

extensions. 

-- Peter

---

From: "Dawson, Martin" <[email-masked]>
Date: Tue, 28 Aug 2007 16:17:47 -0500

I absolutely agree and, if you accept the fact that clients really can't
assume anything about the nature of the network that they are in,
clients cannot assume that they are not mobile so shouldn't expect that
a reference is going to have a "pre-cooked" value by the time it is
dereferenced.

The dereferencing protocol needs to support the same semantics as the
location by value request. Needless to say, I think it needs to support
a scalar response time option as well.

Cheers,

Martin

From: Stark, Barbara [mailto:[email-masked]] 
Sent: Wednesday, 29 August 2007 6:20 AM
To: Roger Marshall; Winterbottom, James; Stuard, Doug; Brian Rosen;
[email-masked]
Cc: GEOPRIV; Dawson, Martin
Subject: RE: [Geopriv] ResponseTime -- when reference is returned

Barbara

-roger marshall.

	Cheers

	James

	Barbara

	*****

---

From: "Winterbottom, James" <[email-masked]>
Date: Tue, 28 Aug 2007 16:21:45 -0500

Well, if you use HELD as the dereference protocol then you have some
options.

In fact you have, contexts aside, the same options as the end-point that
can also use HELD.

Barbara

-roger marshall.

	Cheers

	James

	Barbara

	*****

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 28 Aug 2007 17:26:59 -0400

It's an opinion: we're short on facts.
I think the simplest base (one bit, time or accuracy) is okay.
I think the extension is not as simple as you want it to be because the
problem is not as simple as you wish it to be.  You can, with any of the
proposed extensions, simulate your single scalar.

I agree that it is very hard to know when any device or any app will be
mobile or not.

Brian

> Sent: Tuesday, August 28, 2007 4:52 PM
> If the choice - as you seem to be suggesting - is between one bit
> (inadequate in my estimation) and a full blown profiling, multi-parameter,
> request and backoff with reference mechanism (overblown, overcomplicated,
> and impractical in my estimation) then I still haven't got the
> functionality that I require (a simple scalar response time).
> 
> Why can't I have this optional parameter in the base spec? What is the
> semantic difference between this and an optional extension? A client
> doesn't have to use base spec option and, with respect to this parameter,
> a LIS can choose to ignore it. Why can't we just have it in the base spec
> now? Where's the spirit of compromise? The scalar parameter with the
> default semantics I described cover your requirements as well as meet
> mine. What's the obsession with limiting communication to a single bit?
> 
> Also - I don't understand the implication that it can be pre-judged
> whether a client needs response time or not. The suggestion seems to be
> that this is "only a wireless problem" - but that doesn't mean it's not a
> consideration for every client implementation. If I'm implementing an
> application on a laptop, how do I know whether it is going to be on a
> wireless access or not. I can't even use the network adaptor as any guide
> - as has been mentioned, the physical network connection doesn't actually
> indicate the nature of the Internet access (ref the RV/LAN scenario).
> 
> Cheers,
> Martin
> 
> need
> <[email-masked]>,
> seconds
> you
> the
> if
> with
> accept
> rightly
> of
> want
> determined
> you
> would
> value
> do
> rest
> use

---

From: "Stuard, Doug" <[email-masked]>
Date: Tue, 28 Aug 2007 17:37:29 -0400

Imbedded

Doug

From: Brian Rosen [mailto:[email-masked]] 
Sent: Tuesday, August 28, 2007 4:53 PM
To: Stuard, Doug; 'Roger Marshall'; [email-masked];
Winterbottom, James
Cc: 'GEOPRIV'; Dawson, Martin
Subject: RE: [Geopriv] ResponseTime

I just asked my NENA experts.  They said "90%, not 67%".  1/3 error is
not acceptable.  1/10 is acceptable.

[Stuard, Doug] 67% is based on the minimum confidence value of the FCC
E9-1-1 mandate.  As stated, it is a statistical measure over a large
sample.  Overlooked is the fact that, when applied to a single location
estimate, it means something entirely different. In our system, both the
67% and 95% confidence values are  logged to aid in analysis for
accuracy certification. 

If my understanding is wrong, I sure would like to be educated, either
with everyone else on the list or privately.

Doug, if you were designing a PSAP workstation, and you had uncertainty
at 65%, and then someone came along and told you it was being changed to
90%, what would you change?

[Stuard, Doug] 

You mean confidence...(I know, it's been a long day <G>...With a change
in confidence, only the reported confidence would change, there would be
no change in the PSAP display (confidence not being displayed in either
case).  The uncertainty would continue to be displayed (although with
the higher confidence value, the average uncertainty would increase ...
not something a carrier wants to see).  

If a standard of 90% were introduced, I would have the PDE vendor (or
MLC) calculate (and report)  the uncertainty at the new confidence level
(We have been able to do this for some time on our UTDOA product,
although the default confidence value reported with each fix has
remained at 67%).  

As to operator training, your PSAP contacts would be a better source,
but I would surmise  that with a consistent  underlying confidence
value, training would not have to address the apparent accuracy
"discrepancies" between carriers. Actual decision criteria and dispatch
actions would likely not change, as you pointed out below.

I know that the folks who go out in the field and verify accuracy WOULD
use the value, but I don't think a call taker, with the very best
equipment, would see, hear, taste, or act differently if the confidence
value changed.  The folks who verify accuracy would, the call takers
would not.

Just for fun, although there is an obvious display difference you can
show with varying uncertainty (say a circle instead of a point), my
sources say there is NOTHING WHATSOEVER that can be done with the data
other than have the nice display.  They don't change interaction with
the caller, the responder or the dispatcher in any way if it's 10M 100M
or 1000M.  They take the point as a point and dispatch to the closest
street address to that point.  They don't change who is sent, when they
are sent, or what they are told.  These are not stupid people.
Uncertainty is something they understand, and care a lot about, but they
can't actually USE it to help a call taker, dispatcher or responder.
Again, the verification people use it as it is intended to be used.

[Stuard, Doug] 

Are you saying that, absent other location identification data (caller
input, for example), if the uncertainly is reported as 1 km that they
would dispatch assets using the same criteria as if the uncertainty were
50m?  Not saying that that might not be the case, but it only points out
a lack of confidence (get it?<G>) in the capabilities of the system.  I
would think that order of magnitude differences such as this would
fundamentally change how the call taker handles the call.

I have never been told of any app that ever used confidence or
uncertainty other than using uncertainty in a display, and even then,
most users turn the function off.

[Stuard, Doug] 

Perhaps because, up to now, and due to a lack of consistent application,
it hasn't fulfilled its potential.

Brian

To: Brian Rosen; Roger Marshall; [email-masked];

Doug

-roger marshall.

---

From: "Winterbottom, James" <[email-masked]>
Date: Tue, 28 Aug 2007 16:38:45 -0500

But, a responseTime is equally applicable to civic as it is for geodetic.
The same cannot be said for the accuracy component where the accuracy is specified as a simply metre value.

I would like to see accuracy as an extension largely because the vast majority of location servers today have the strict QoS on horizontal accuracy function disabled, and leave the determination of the quality of the location up to the application.

Cheers
James

> Sent: Wednesday, 29 August 2007 7:27 AM
> To: Dawson, Martin; [email-masked]; Winterbottom, James
> Cc: 'GEOPRIV'
> > The simplest mechanism, if we're starting at mechanism, is just the
> state
> > of
> > The question after that is how much mechanism is useful for the next
> step?
> > I
> devices
> > You don't actually know in many cases how accurate the result is going
> to
> > be
> > a comment such as "within a reasonable time frame". However, just
> because
> > I
> > among the elements which determine location), provide additional
> control,
> > as
> > ii)             Take as long as you like until you think it's as
> accurate
> > as
> > you can get it.
> >
> > small) improvements in accuracy for every iteration/measurement - even
> if
> > it
> --
> > --
> --
> > --
> --
> > --
> --
> > --
> forwarding,
> --
> > --
> --
> > --
> --
> > ----------------------
> --
> > ----------------------

---

From: "Roger Marshall" <[email-masked]>
Date: Tue, 28 Aug 2007 14:28:40 -0700

Martin:
Nope, I would say the opposite, that "Uncertainty", (not accuracy), goes
up when Confidence goes up, since I take confidence as std. dev. when
67% & 95%.

	From: Dawson, Martin [mailto:[email-masked]] 
	Sent: Tuesday, August 28, 2007 2:15 PM
	To: Roger Marshall; Brian Rosen; Stuard, Doug;
[email-masked]; Winterbottom, James
	Cc: GEOPRIV
	Subject: RE: [Geopriv] ResponseTime

	Ummm... this highlights the sort of confusion that arises around
the concept of confidence. I've re-read this a couple of times and I'm
pretty sure Roger is saying that accuracy increases with confidence.
This is not the case.

	Generally, the higher the confidence associated with a location
fix, the larger the uncertainty provided for that fix will be. A cell
based fix will respond in the same amount of time whether it is
providing 67% confidence or 95% confidence. It's just that it will
report a larger area of uncertainty for the latter (yes, the latter).

	A 67% confidence says that 1 out of 3 location fixes will result
in the target actually being somewhere outside the area of uncertainty
provided with the result. The only way to increase the confidence - e.g.
90% where only 1 out of 10 fixes see the target falling outside the area
of uncertainty - is to increase the uncertainty that is reported for
that location fix. There's no such thing as confidence associated with a
point (unless you assume a value of uncertainty associated with the
point). If anything, the confidence associated with a point is likely to
mathematically approach zero.

	So - if we all standardised on 67% confidence, we will get
smaller areas of uncertainty reported to our applications - but the
application semantics will need to cope with the 33% of targets that are
anywhere but within the area of uncertainty. If we standardised on 95%
confidence then our applications would have to deal with larger areas of
uncertainty with application semantics that manage the 1 out of 20
targets that could be anywhere but within that reported area. I think
PSAPs are still wrestling with this concept.

	Cheers,

	Martin

	Sent: Wednesday, 29 August 2007 5:53 AM

	-roger marshall.

		Brian

		In line

		See embedded comments.

		Doug

		[Stuard, Doug] Agreed

		Brian

		Doug

		

		
		
		-- Peter

---

From: "Roger Marshall" <[email-masked]>
Date: Tue, 28 Aug 2007 14:38:49 -0700

Hey there Martin:
There is such a system in use today, and what I can do is offer to
provide a more detailed explanation in text of how this works, which
would provide a better basis for discussion.
 
-roger marshall.

	Sent: Tuesday, August 28, 2007 2:21 PM

	Hi Roger,

	Can you provide an example of a real system that generates these
7 coefficients? That is, what is being measured and how does this
resolve into the discrete coefficients and what are the significance of
these coefficients?

	I'm trying to understand where you're coming from but it's a
little too cryptic for me at the moment.

	Cheers,

	Martin

	Sent: Wednesday, 29 August 2007 6:51 AM

	One way to reduce complexity (may not sound like it at first) is
to:

	-- program: one standardized function (produces 7 coefficients
from a couple of inputs) to describe any common shape

	-- input: a combination of confidence, uncertainty (max), and
timing (max) as input variables

	The client gets to control everything through input variables,
whether it's an end device, middlebox, or PSAP client.

	One client (e.g., the end-device) can use a low time, a low
confidence to get routing information, gets the coefficients - and the
PSAP client reuses the conveyed coeff's along with their 'standard' 95%
confidence input value.

	-roger marshall. 

		From: Brian Rosen [mailto:[email-masked]] 
		Sent: Tuesday, August 28, 2007 1:01 PM
		To: Roger Marshall; 'Stuard, Doug';
[email-masked]; 'Winterbottom, James'
		Cc: 'GEOPRIV'; 'Dawson, Martin'
		Subject: RE: [Geopriv] ResponseTime

		Having a standardized value is so much more useful than
the absolute number.  Generally, every user I ever talked to was unable
to use confidence unless all sources gave them the same confidence.  If
they varied, then they were forced to ignore it; nothing they could
think of doing: displaying, calculating, dispatching, routing... could
change based on the value of confidence.

		If you have the same value, then at least you can
compare two locations from different sources and they mean the same
thing.  You still can't use confidence for displaying, calculating,
dispatching or routing.

		To: Brian Rosen; Stuard, Doug;

		This gets to the nagging problem of how good is 'good
enough'?  Determining elements can certainly provide position, based on
input of 67% confidence, but they can also do better.  If you're willing
to wait a few more seconds, they can churn out a more accurate result
based on a 90 or 95% input value.  In fact, maybe they'll have to use
95% to get the level of precision that some regulatory agency will ask
for someday.  By providing confidence value as an input to these
mechanisms, you can achieve location hiding (to some degree) as well.

		-roger marshall.

			James pointed out to be that PIDF-LO profile
actually does say use 67%.  While I'd much prefer 90 or 95%, a single
standardized value beats any set of values hands down.

			Brian

			In line

			From: Stuard, Doug
[mailto:[email-masked]] 

			See embedded comments.

			Doug

			Generally, I think this is getting there.  I
think you want a way for the server to tell the client what kinds of
time/accuracy tradeoffs it can make.  Something simple would be fine.  I
just want to see some way to represent the time/accuracy curve(s),
recognizing that they are non linear, discontinuous and not completely
controlled.  If the server always gives you an answer within 100m in 30
seconds, no matter what you ask for, I'd like the client to know that.
I'm not looking for the whole curve, just the shape and dimensions.

			[Stuard, Doug] The fact that the time/accuracy
tradeoff is non-linear and often discontinuous is irrelevant, as it
cannot be known a priori by the client OR by the server (except in a
general way).  IMO the actual shape of the curve matters little to the
client.  Time and accuracy thresholds are the key items that matter.  A
client/application should specify what it wants/needs, regardless of the
server's apparent intransigence. The client then must have a mechanism
for dealing with a response that is not entirely what it asked for
(don't we all?). 

			<br>The server knows what the curves look like.
It's not precise (this much accuracy in this much time), but they know
the shape.  I believe in apps that adapt to reality, rather than
assuming the server can always do what the client wants.  The client
wants infinite accuracy in zero time.  It will put up with less, but it
wants to know what it has to work with.  This is a big stumbling block:
you-all seem to think it's way too complicated for a poor little app to
understand, so give big daddy server your absolute drop dead limits and
big daddy will do the best it can.  I don't believe in big daddy.  My
apps can make use of whatever information you can give me.  You all
think there are finite limits that apps drop dead after.  There aren't;
all the numbers are arbitrary, and without any information they are
really arbitrary.

			Recognize that you described this as all gated
on time, but you could have described it based on accuracy and come out
the same;

			[Stuard, Doug] Perhaps, but people are
impatient, and the concept of "good enough" is usually limited by "not
soon enough" (Case 5)

			 there is a time/accuracy tradeoff, it's
non-linear, and you can hold one constant and vary the other. 

			[Stuard, Doug] This is in essence what you are
doing with Case 5 (time>0, no accuracy specified), and Case 2 (accuracy
specified, no time limit).  You can do it either way.

			Also need a mechanism to cope with time longer
than a few seconds.

			[Stuard, Doug] Agreed

			I agree that we need confidence.  I dearly would
love to specify 90% and leave it at that.  I fear we cannot.   Normally,
this is something you get back from the server, not an input parameter.

			[Stuard, Doug] I would think the
client/application would like to assume a "standard" (there's that word
again!) value.  Perhaps this would be set at the server.  We don't need
to replicate the current E9-1-1 confidence/uncertainty conundrum.
People understand uncertainty, but confidence is often lost on them.
Better to settle on a reasonably good but achievable confidence value
(e.g., 90%, or whatever makes sense for the application) then to leave
it open.

			<br>Hey, I like it; if you can get everyone to
agree, 90% is a good number!

			Brian

			From: Stuard, Doug
[mailto:[email-masked]] 
			Sent: Tuesday, August 28, 2007 1:20 PM
			To: [email-masked]; Winterbottom,
James
			Cc: GEOPRIV; Dawson, Martin
			Subject: RE: [Geopriv] ResponseTime

			1)      No time or accuracy specified:  "No
location required" (inclusion of either optional parameter would require
a location response). 

			a.       It was suggested that this case might
mean "AGAP, no time limit", but how is "AGAP" determined? - there has to
be some point at which calculations stop and a result is reported,
either a time limit or an accuracy threshold or convergence (cases 2 and
6 below))

			2)      No time specified, accuracy specified:
However long it takes to achieve the specified accuracy.

			3)      Time=0, no accuracy specified:  ASAP
with whatever accuracy is available*

			4)      Time=0, accuracy specified: ASAP so long
as specified accuracy met, otherwise fail.

			5)      Time >0, no accuracy specified: AGAP
within the specified time limit*

			6)      Time >0, accuracy specified: AGAP within
the time limit or until specified accuracy is achieved, whichever comes
first.

			*In cases where there is no accuracy
specification (3&5), the accuracy should be included in the result if
available. It may be included in the others as well.

			Most database based responses would either be of
type 1 (civic) or type 3 (fixed geo).

			Emergency call routing would be based on a Type
3 request or a Type 5 with an appropriate time limit

			Doug

			From: [email-masked]
[mailto:[email-masked]] 
			Sent: Tuesday, August 28, 2007 11:24 AM
			To: Winterbottom, James
			Cc: Stark, Barbara; Stuard, Doug; GEOPRIV;
Dawson, Martin; Robert Sparks; Roger Marshall
			Subject: RE: [Geopriv] ResponseTime

			Hmmm ....  This is tending towards more
complicated, not less.   (Noting esp the proposal for possibly 3
parameters.)   
			
			James wrote: 
			> Given my description of profiling above, would
people be prepared to accept the following: 
			> This meets Peter's previous concern, if he
wants minimal wired-client support, his HELD client says responseTime=0.

			Actually, in a wired case where location is
actually known virtually instantaneously, I would expect the client
would include no ReponseTime parameter at all.   
			
			How about a different compromise?  Since it
*seems* to be the case that ResponseTime is primarily a concern for
mobile devices (particularly cellular), how about it the parameter is an
extension, but mobile devices (or ones which might be mobile, such as
soft clients), by their nature, need to implement it.  This is
predicated on others in cellular space also agreeing that ResponseTime
is actually needed there.  (I am not a cellular expert, but also note
most responses are coming from what Robert rightly termed "just the
folks that were active in the discussion earlier" ;-) 
			
			-- Peter 

			 

		 

		The information contained in this message may be
privileged and/or confidential. If you are not the intended recipient,
or responsible for delivering this message to the intended recipient,
any review, forwarding, dissemination, distribution or copying of this
communication or any attachment(s) is strictly prohibited. If you have
received this message in error, please so notify the sender immediately,
and delete it and all attachments from your computer and network.

---

From: "Roger Marshall" <[email-masked]>
Date: Tue, 28 Aug 2007 14:28:40 -0700

Martin:

	Cheers,

	Martin

	-roger marshall.

		Brian

		In line

		See embedded comments.

		Doug

		[Stuard, Doug] Agreed

		Brian

		Doug

		

		
		
		-- Peter

---

From: "Roger Marshall" <[email-masked]>
Date: Tue, 28 Aug 2007 14:38:49 -0700

Hey there Martin:
 
-roger marshall.

	Hi Roger,

	Cheers,

	Martin

	-roger marshall. 

		

		-roger marshall.

			Brian

			In line

			From: Stuard, Doug

			See embedded comments.

			Doug

			[Stuard, Doug] Agreed

			Brian

			From: Stuard, Doug

			Doug

			

			
			
			-- Peter

---

From: "Dawson, Martin" <[email-masked]>
Date: Tue, 28 Aug 2007 16:14:50 -0500

Ummm... this highlights the sort of confusion that arises around the
concept of confidence. I've re-read this a couple of times and I'm
pretty sure Roger is saying that accuracy increases with confidence.
This is not the case.

Generally, the higher the confidence associated with a location fix, the
larger the uncertainty provided for that fix will be. A cell based fix
will respond in the same amount of time whether it is providing 67%
confidence or 95% confidence. It's just that it will report a larger
area of uncertainty for the latter (yes, the latter).

A 67% confidence says that 1 out of 3 location fixes will result in the
target actually being somewhere outside the area of uncertainty provided
with the result. The only way to increase the confidence - e.g. 90%
where only 1 out of 10 fixes see the target falling outside the area of
uncertainty - is to increase the uncertainty that is reported for that
location fix. There's no such thing as confidence associated with a
point (unless you assume a value of uncertainty associated with the
point). If anything, the confidence associated with a point is likely to
mathematically approach zero.

So - if we all standardised on 67% confidence, we will get smaller areas
of uncertainty reported to our applications - but the application
semantics will need to cope with the 33% of targets that are anywhere
but within the area of uncertainty. If we standardised on 95% confidence
then our applications would have to deal with larger areas of
uncertainty with application semantics that manage the 1 out of 20
targets that could be anywhere but within that reported area. I think
PSAPs are still wrestling with this concept.

Cheers,

Martin

-roger marshall.

	Brian

	In line

	See embedded comments.

	Doug

	[Stuard, Doug] Agreed

	Brian

	Doug

	

	
	
	-- Peter 

	 

 

------------------------------------------------------------------------------------------------
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]
Ummm... this highlights the sort of confusion that arises around the
concept of confidence. I've re-read this a couple of times and I'm
pretty sure Roger is saying that accuracy increases with confidence.
This is not the case.

Generally, the higher the confidence associated with a location fix, the
larger the uncertainty provided for that fix will be. A cell based fix
will respond in the same amount of t-size:11.0pt;font-family:Calibri;color:#1F497D'>Emergency call
routing would be based on a Type 3 request or a Type 5 with an appropriate time
limit<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color="#1f497d" face=Calibri><span lang=EN-US
style='font-size:11.0pt;font-family:Calibri;color:#1F497D'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal><font size=2 color="#1f497d" face=Calibri><span lang=EN-US
style='font-size:11.0pt;font-family:Calibri;color:#1F497D'>Also, the definition
of &#8220;accuracy&#8221; needs to be addressed.&nbsp; For calculated accuracy
as in wireless, the uncertainty at a specified confidence (90% is often
mentioned) might be appropriate.<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color="#1f497d" face=Calibri><span lang=EN-US
style='font-size:11.0pt;font-family:Calibri;color:#1F497D'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal><font size=2 color="#1f497d" face=Arial><span lang=EN-US
style='font-size:10.0pt;font-family:Arial;color:#1F497D'>Doug<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color="#1f497d" face=Calibri><span lang=EN-US
style='font-size:11.0pt;font-family:Calibri;color:#1F497D'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal><font size=2 color="#1f497d" face=Calibri><span lang=EN-US
style='font-size:11.0pt;font-family:Calibri;color:#1F497D'><o:p>&nbsp;</o:p></span></font></p>

<div style='border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm 4.0pt'>

<div>

<div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm'>

<p class=MsoNormal><b><font size=2 face=Tahoma><span lang=EN-US
style='font-size:10.0pt;font-family:Tahoma;font-weight:bold'>From:</span></font></b><font
size=2 face=Tahoma><span lang=EN-US style='font-size:10.0pt;font-family:Tahoma'>
[email-masked] [mailto:[email-masked]] <br>
<b><span style='font-weight:bold'>Sent:</span></b> Tuesday, August 28, 2007
11:24 AM<br>
<b><span style='font-weight:bold'>To:</span></b> Winterbottom, James<br>
<b><span style='font-weight:bold'>Cc:</span></b> Stark, Barbara; <st1:PersonName
w:st="on">Stuard, Doug</st1:PersonName>; GEOPRIV; Dawson, Martin; Robert
Sparks; Roger Marshall<br>
<b><span style='font-weight:bold'>Subject:</span></b> RE: [Geopriv]
ResponseTime<o:p></o:p></span></font></p>

</div>

</div>

<p class=MsoNormal><font size=3 face="Times New Roman"><span lang=EN-US
style='font-size:12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal style='margin-bottom:12.0pt'><font size=3
face="Times New Roman"><span lang=EN-US style='font-size:12.0pt'><br>
</span></font><font size=2 face=Arial><span lang=EN-US style='font-size:10.0pt;
font-family:Arial'>Hmmm .... &nbsp;This is tending towards more complicated,
not less. &nbsp; (Noting esp the proposal for possibly 3 parameters.) &nbsp; </span></font><span
lang=EN-US><br>
<br>
</span><font size=2 face=Arial><span lang=EN-US style='font-size:10.0pt;
font-family:Arial'>James wrote:</span></font><span lang=EN-US> <br>
</span><font size=2 color=navy face=Arial><span lang=EN-US style='font-size:
10.0pt;font-family:Arial;color:navy'>&gt; Given my description of profiling
above, would people be prepared to accept the following:</span></font><span
lang=EN-US> <br>
</span><font size=2 color=navy face=Arial><span lang=EN-US style='font-size:
10.0pt;font-family:Arial;color:navy'>&gt; </span></font><span lang=EN-US><br>
</span><font size=2 color=navy face=3ime whether it is providing 67%
confidence or 95% confidence. It's just that it will report a larger
area of uncertainty for the latter (yes, the latter).

A 67% confidence says that 1 out of 3 location fixes will result in the
target actually being somewhere outside the area of uncertainty provided
with the result. The only way to increase the confidence - e.g. 90%
where only 1 out of 10 fixes see the target falling outside the area of
uncertainty - is to increase the uncertainty that is reported for that
location fix. There's no such thing as confidence associated with a
point (unless you assume a value of uncertainty associated with the
point). If anything, the confidence associated with a point is likely to
mathematically approach zero.

So - if we all standardised on 67% confidence, we will get smaller areas
of uncertainty reported to our applications - but the application
semantics will need to cope with the 33% of targets that are anywhere
but within the area of uncertainty. If we standardised on 95% confidence
then our applications would have to deal with larger areas of
uncertainty with application semantics that manage the 1 out of 20
targets that could be anywhere but within that reported area. I think
PSAPs are still wrestling with this concept.

Cheers,

Martin

-roger marshall.

	Brian

	In line

	See embedded comments.

	Doug

	From: Brian Rosen [mailto:[email-masked]] 
	Sent: Tuesday, August 28, 2DArial><span lang=EN-US style='font-size:
10.0pt;font-family:Arial;color:navy'>&gt; 1) No responseTime provided, you get AGAP,
however long that takes.</span></font><span lang=EN-US> <br>
</span><font size=2 color=navy face=Arial><span lang=EN-US style='font-size:
10.0pt;font-family:Arial;color:navy'>&gt; 2) responseTime = 0, you get ASAP</span></font><span
lang=EN-US> <br>
</span><font size=2 color=navy face=Arial><span lang=EN-US style='font-size:
10.0pt;font-family:Arial;color:navy'>&gt; 3) responseTime &gt;0, you get best
in time provided.</span></font><span lang=EN-US> <br>
</span><font size=2 color=navy face=Arial><span lang=EN-US style='font-size:
10.0pt;font-family:Arial;color:navy'>&gt; &nbsp;</span></font><span lang=EN-US>
<br>
</span><font size=2 color=navy face=Arial><span lang=EN-US style='font-size:
10.0pt;font-family:Arial;color:navy'>&gt; If people want other things, then
they can profile those in HELD extensions.</span></font><span lang=EN-US> <br>
</span><font size=2 color=navy face=Arial><span lang=EN-US style='font-size:
10.0pt;font-family:Arial;color:navy'>&gt; This meets Peter&#8217;s previous
concern, if he wants minimal wired-client support, his HELD client says
responseTime=0.</span></font><span lang=EN-US> <br>
</span><font size=2 face=Arial><span lang=EN-US style='font-size:10.0pt;
font-family:Arial'>&nbsp;</span></font><span lang=EN-US> <br>
</span><font size=2 face=Arial><span lang=EN-US style='font-size:10.0pt;
font-family:Arial'>Actually, in a wired case where location is actually known
virtually instantaneously, I would expect the client would include no
ReponseTime parameter at all. &nbsp;</span></font><span lang=EN-US> <br>
<br>
</span><font size=2 face=Arial><span lang=EN-US style='font-size:10.0pt;
font-family:Arial'>How about a different compromise? &nbsp;Since it *seems* to
be the case that ResponseTime is primarily a concern for mobile devices
(particularly cellular), how about it the parameter is an extension, but mobile
devices (or ones which might be mobile, such as soft clients), by their nature,
need to implement it. &nbsp;This is predicated on others in cellular space also
agreeing that ResponseTime is actually needed there. &nbsp;(I am not a cellular
expert, but also note most responses are coming from what Robert rightly termed
&quot;</span></font><font size=2 face="Courier New"><span lang=EN-US
style='font-size:10.0pt;font-family:"Courier New"'>just the folks that were
active in the discussion earlier</span></font><font size=2 face=Arial><span
lang=EN-US style='font-size:10.0pt;font-family:Arial'>&quot; ;-)</span></font><span
lang=EN-US> <br>
<br>
</span><font size=2 face=Arial><span lang=EN-US style='font-size:10.0pt;
font-family:Arial'>-- Peter</span></font><span lang=EN-US> <o:p></o:p></span></p>

</div>

<p class=MsoNormal style='margin-bottom:12.0pt'><font size=3
face="Times New Roman"><span lang=EN-US style='font-size:12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<table class=MsoNormalTable border=0 cellpadding=0 bgcolor=white
 style='background:white'>
 <tr>
  <td style='padding:.75pt .75pt .75pt .75pt'>
  <p class=MsoNormal><font size=3 color=black face="Times New Roman"><span
  style='font-size:12.0pt;color:black'><br>
  ------------------------------------------------------------------------------------------------<br>
  This&nbsp;message&nbsp;is&nbsp;for&nbsp;the&nbsp;designated&nbsp;recipient&nbsp;only&nbsp;and&nbsp;may<br>
  contain&nbsp;privileged,&nbsp;proprietary,&nbsp;or&nbsp;otherwise&nbsp;private&nbsp;information.&nbsp007 1:49 PM
	To: Stuard, Doug; [email-masked]; Winterbottom,
James
	Cc: 'GEOPRIV'; Dawson, Martin
	Subject: RE: [Geopriv] ResponseTime

	[Stuard, Doug] Agreed

	<br>Hey, I like it; if you c;&nbsp;<br>
  If&nbsp;you&nbsp;have&nbsp;received&nbsp;it&nbsp;in&nbsp;error,&nbsp;please&nbsp;notify&nbsp;the&nbsp;sender<br>
  immediately&nbsp;and&nbsp;delete&nbsp;the&nbsp;original.&nbsp;&nbsp;Any&nbsp;unauthorized&nbsp;use&nbsp;of<br>
  this&nbsp;email&nbsp;is&nbsp;prohibited.<br>
  ------------------------------------------------------------------------------------------------<br>
  [mf2]<o:p></o:p></span></font></p>
  </td>
 </tr>
</table>

<p class=MsoNormal><font size=3 face="Times New Roman"><span lang=EN-US
style='font-size:12.0pt'><o:p>&nbsp;</o:p></span></font></p>

</div>

</div>

<p class=MsoNormal style='margin-bottom:12.0pt'><font size=3
face="Times New Roman"><span lang=EN-US style='font-size:12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<table class=MsoNormalTable border=0 cellpadding=0 bgcolor=white
 style='background:white'>
 <tr>
  <td style='padding:.75pt .75pt .75pt .75pt'>
  <p class=MsoNormal><font size=3 color=black face="Times New Roman"><span
  style='font-size:12.0pt;color:black'><br>
  ------------------------------------------------------------------------------------------------<br>
  This&nbsp;message&nbsp;is&nbsp;for&nbsp;the&nbsp;designated&nbsp;recipient&nbsp;only&nbsp;and&nbsp;may<br>
  contain&nbsp;privileged,&nbsp;proprietary,&nbsp;or&nbsp;otherwise&nbsp;private&nbsp;information.&nbsp;&nbsp;<br>
  If&nbsp;you&nbsp;have&nbsp;received&nbsp;it&nbsp;in&nbsp;error,&nbsp;please&nbsp;notify&nbsp;the&nbsp;sender<br>
  immediately&nbsp;and&nbsp;delete&nbsp;the&nbsp;original.&nbsp;&nbsp;Any&nbsp;unauthorized&nbsp;use&nbsp;of<br>
  this&nbsp;email&nbsp;is&nbsp;prohibited.<br>
  ------------------------------------------------------------------------------------------------<br>
  [mf2]<o:p></o:p></span></font></p>
  </td>
 </tr>
</table>

<p class=MsoNormal><font size=3 face="Times New Roman"><span lang=EN-US
style='font-size:12.0pt'><o:p>&nbsp;</o:p></span></font></p>

</div>

</div>

</blockquote>

<p><font size=2 face=Arial><span lang=EN-US style='font-size:10.0pt;font-family:
Arial'>&nbsp;</span></font><span lang=EN-US><o:p></o:p></span></p>

<p><font size=2 face=Arial><span lang=EN-US style='font-size:10.0pt;font-family:
Arial'>The information contained in this message may be privileged and/or
confidential. If you are not the intended recipient, or responsible for
delivering this message to the intended recipient, any review, forwarding,
dissemination, distribution or copying of this communication or any
attachment(s) is strictly prohibited. If you have received this message in
error, please so notify the sender immediately, and delete it and all
attachments from your computer and network.</span></font><span lang=EN-US><o:p></o:p></span></p>

<p><font size=2 face=Arial><span lang=EN-US style='font-size:10.0pt;font-family:
Arial'>&nbsp;</span></font><span lang=EN-US><o:p></o:p></span></p>

</div>

<br><br><table bgcolor=white style="color:black"><tr><td><br>------------------------------------------------------------------------------------------------<br>
This&nbsp;message&nbsp;is&nbsp;for&nbsp;the&nbsp;designated&nbsp;recipient&nbsp;only&nbsp;and&nbsp;may<br>
contain&nbsp;privileged,&nbsp;proprietary,&nbsp;or&nbsp;otherwise&nbsp;private&nbsp;information.&nbsp;&nbsp;<br>
If&nbsp;you&nbsp;have&nbsp;received&nbsp;it&nbsp;in&nbsp;error,&nbsp;please&nbsp;notify&nbsp;the&nbsp;sender<br>
immediately&nbsp;and&nbsp;delete&nbsp;the&nbsp;original.&nbsp;&nbsp;Any&nbsp;unauthorized&nbsp;use&nbsp;of<br>
this&nbsp;email&nbsp;is&nbsp;prohibited.<br>
-------------------an get everyone to agree, 90% is a
good number!

	Brian

	Doug

	

	
	How about a different compromise?  Since it *seems* to be the
case that ResponseTime is primarily a concern for mobile devices
(particularly cellular), how about it the parameter is-----------------------------------------------------------------------------<br>
[mf2]</td></tr></table></body>

</html>

---

From: "Dawson, Martin" <[email-masked]>
Date: Tue, 28 Aug 2007 16:20:50 -0500

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 28 Aug 2007 17:37:59 -0400

Actually, PSAPs are not wrestling with this concept at all.  They have
looked into the situation thoroughly.  They understand confidence and
uncertainty.  They understand what it means.   They understand how
measurements they make can be interpreted in light of the values.  

They will not accept a 1 out of 3 measurement reports in error; they would
prefer 95% confidence and then discuss the uncertainty.  I think they will
accept 90% today, but they want 95%.   The confidence factor is something
they understand they can simplify out of the picture for every purpose
except validation if it's constant and high.  They tried to do that; it was
the carriers who disagreed (and, as I understand it, I was not there) it
would have worked if "rough consensus" was the way disagreements were
handled.

So, everyone understands there are two variables.  Everyone understands that
confidence is very real.  However, they understand that it can be made less
of a variable for use if everyone uses the same high value.  If everyone
used the same very low value (say 30%), the uncertainty numbers would tend
to look better.   They want the other way: high uncertainty, high
confidence.  There is no wrestling involved.

Brian

  _____  

From: Dawson, Martin [mailto:[email-masked]] 
Sent: Tuesday, August 28, 2007 5:15 PM
To: Roger Marshall; Brian Rosen; Stuard, Doug; [email-masked];
Winterbottom, James
Cc: GEOPRIV
Subject: RE: [Geopriv] ResponseTime

Ummm. this highlights the sort of confusion that arises around the concept
of confidence. I've re-read this a couple of times and I'm pretty sure Roger
is saying that accuracy increases with confidence. This is not the case.

Generally, the higher the confidence associated with a location fix, the
larger the uncertainty provided for that fix will be. A cell based fix will
respond in the same amount of time whether it is providing 67% confidence or
95% confidence. It's just that it will report a larger area of uncertainty
for the latter (yes, the latter).

A 67% confidence says that 1 out of 3 location fixes will result in the
target actually being somewhere outside the area of uncertainty provided
with the result. The only way to increase the confidence - e.g. 90% where
only 1 out of 10 fixes see the target falling outside the area of
uncertainty - is to increase the uncertainty that is reported for that
location fix. There's no such thing as confidence associated with a point
(unless you assume a value of uncertainty associated with the point). If
anything, the confidence associated with a point is likely to mathematically
approach zero.

So - if we all standardised on 67% confidence, we will get smaller areas of
uncertainty reported to our applications - but the application semantics
will need to cope with the 33% of targets that are anywhere but within the
area of uncertainty. If we standardised on 95% confidence then our
applications would have to deal with larger areas of uncertainty with
application semantics that manage the 1 out of 20 targets that could be
anywhere but within that reported area. I think PSAPs are still wrestling
with this concept.

Cheers,

Martin

  _____  

-roger marshall.

  _____  

Brian

  _____  

In line

  _____  

See embedded comments.

Doug

[Stuard, Doug] Agreed

Brian

  _____  

Doug

extensions. 

-- Peter

---

From: "Dawson, Martin" <[email-masked]>
Date: Tue, 28 Aug 2007 16:59:06 -0500

I don't quite get that... on the one hand the message is that
uncertainty should be provided at 90% but, on the other hand, the
message is that uncertainty is not even considered or used. Typically a
location with an ellipse of uncertainty will have the same center. The
ellipse will just be bigger for greater confidence. If all that's looked
at is the center, then why does it matter what the confidence is?

I think PSAPs are only just learning how to use geodetic location
information. Procedures haven't really started to be optimized yet. If
you get an area of uncertainty at 90% confidence, then the correct
interpretation is that there is a 90% chance of the caller being
somewhere within that area. No one point within that area is more likely
than any other point in that area; in particular, there is nothing
special about the center. However every point in the area is nine times
more likely to be correct than every point outside that area. So - if I
was asking my caller for observations pertaining to their location
(nature of the structures, landscape etc) then I'd be best advised to
look for a correlation with their observations with GIS information
pertaining to the geography within that area of uncertainty. I certainly
shouldn't be focussing my attention on the center of the uncertainty and
I should probably give 90% of my attention to all the points within the
area of uncertainty at least initially before looking outside that area.
Procedurally, the same sort of thinking should apply to a structured
on-the-ground search for dispatch based on the area of uncertainty
returned. Your opinion below doesn't resonate well with the opinion that
there isn't "wrestling" going on. What's the rationale for dispatching
to the "point"?

For a real-world application of uncertainty, the routing problem should
be considered. If I have an area of uncertainty at 90% confidence
overlaid on three routing area borders, then I have a better chance of
getting the routing right if I pick the route that most of the area of
uncertainty lies within. This is particularly emphasised where the
center of the uncertainty may actually lie in the route that only has a
tiny fraction of the area of uncertainty overlaid on it. E.g. given the
following area of uncertainty at 90% confidence, which is the best
destination zone to route to?

Cheers,

Martin

 

Sent: Wednesday, 29 August 2007 6:53 AM

I've discussed this with a couple of real engineering experts a few
times.  I'm not sure I really "get" the underlying issues, but I think I
understand that it's a completely arbitrary number.  You can, with
anyone's equipment, calculate uncertainty at any confidence value you
want.  In many, but not all systems, you can convert from one
uncertainty value at confidence X to another uncertainty value at
confidence Y with math.  If my understanding is correct, there is no
engineering reason not to set the confidence (remember it's SHOULD) to
90%.  Of course, NENA would like 95%.

Brian

Doug

---

From: "Dawson, Martin" <[email-masked]>
Date: Tue, 28 Aug 2007 16:53:38 -0500

I'm not short on facts. I see applications that want the best accuracy for the time they are prepared to wait every day. I need the parameter today. You haven't really said how its existence disadvantages you. You'll have to do more than say it's not as simple as I wish it to be - give me some real information.

Cheers,
Martin

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Wednesday, 29 August 2007 7:27 AM
To: Dawson, Martin; [email-masked]; Winterbottom, James
Cc: 'GEOPRIV'
Subject: RE: [Geopriv] ResponseTime

Brian

---

From: "Dawson, Martin" <[email-masked]>
Date: Tue, 28 Aug 2007 17:19:16 -0500

OK - if you assume that "accuracy" is just the complement of
"uncertainty". I'd actually suggest that a single location fix (of a
single accuracy) can be expressed in arbitrary combinations of
uncertainty and confidence. That is, accuracy is communicated (fully) as
a combination of uncertainty and confidence and is not a synonym for
either of these terms. Specifying a different confidence as the input to
the location request won't necessarily change the accuracy of the
result.

Cheers,

Martin 

From: Roger Marshall [mailto:[email-masked]] 
Sent: Wednesday, 29 August 2007 7:29 AM
To: Dawson, Martin; Brian Rosen; Stuard, Doug;
[email-masked]; Winterbottom, James
Cc: GEOPRIV
Subject: RE: [Geopriv] ResponseTime

Martin:

	

	Cheers,

	Martin

	-roger marshall.

		Brian

---

From: "Dawson, Martin" <[email-masked]>
Date: Tue, 28 Aug 2007 17:20:24 -0500

Yes thanks!

Sent: Wednesday, 29 August 2007 7:39 AM

Hey there Martin:

-roger marshall.

	Hi Roger,

	Cheers,

	Martin

	-roger marshall. 

		

		-roger marshall.

			Brian

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 28 Aug 2007 18:39:40 -0400

Martin

I've spent a bunch of time on this trying to understand what is going on.
You might try doing the same.

There certainly are people out there in PSAP land who don't understand what
confidence and uncertainty mean: they tie them together in "error".
However, you will note that EVERYONE says the same thing: "within 100M 95%
of the time" for example.  That is confidence and uncertainty.  They really
do get it.

They ignore confidence completely in the app.  They mostly ignore
uncertainty.  That's the truth.  For the folks who really understand these
things, it's not ignorance; they don't have anything useful they can do with
the information.

Every caller is questioned about location the same way; they don't change
their questions based on uncertainty.  Is probably is more due to the fact
that there is less variation in emergency calling because there are
government mandates, but the reality is they ignore it.  There isn't any
wrestling because they all do it the same way.  There isn't a request for
feature enhancements on their CPE or CAD system vendor's list.  They have a
single standard (well, it's two standards) and that's the end of the story.
Again, they really truly understand what the values mean.  They don't see
any way to actually use them.

Worse, I talked to some commercial LBS app vendors and THEY IGNORE THE VALUE
TOO.  I have yet to find anyone that uses confidence.  The only use I have
seen for uncertainty is display, and as I said, most people turn it off.

I actually agree with you on routing.  At the moment, we're in the minority.
Given a choice, most KNOWLEDGEABLE people would still choose the center
point and route on that.  I have some hope we can use uncertainty in
routing.  I have no hope for any use for confidence.  Note that if I change
confidence to a higher value, likely I will expand the size of your circle.
That would change routing of course, but the confidence VALUE is completely
ignored; only the uncertainty is useful.  Of course, for routing, I do in
fact want a high confidence, and the consequent higher uncertainty.  If I
choose a route based on a really small uncertainty, but it's wrong half the
time, I don't do very well, do I?

Brian

  _____  

From: Dawson, Martin [mailto:[email-masked]] 
Sent: Tuesday, August 28, 2007 5:59 PM
To: Brian Rosen; Stuard, Doug; Roger Marshall; [email-masked];
Winterbottom, James
Cc: GEOPRIV
Subject: RE: [Geopriv] ResponseTime

I don't quite get that. on the one hand the message is that uncertainty
should be provided at 90% but, on the other hand, the message is that
uncertainty is not even considered or used. Typically a location with an
ellipse of uncertainty will have the same center. The ellipse will just be
bigger for greater confidence. If all that's looked at is the center, then
why does it matter what the confidence is?

I think PSAPs are only just learning how to use geodetic location
information. Procedures haven't really started to be optimized yet. If you
get an area of uncertainty at 90% confidence, then the correct
interpretation is that there is a 90% chance of the caller being somewhere
within that area. No one point within that area is more likely than any
other point in that area; in particular, there is nothing special about the
center. However every point in the area is nine times more likely to be
correct than every point outside that area. So - if I was asking my caller
for observations pertaining to their location (nature of the structures,
landscape etc) then I'd be best advised to look for a correlation with their
observations with GIS information pertaining to the geography within that
area of uncertainty. I certainly shouldn't be focussing my attention on the
center of the uncertainty and I should probably give 90% of my attention to
all the points within the area of uncertainty at least initially before
looking outside that area. Procedurally, the same sort of thinking should
apply to a structured on-the-ground search for dispatch based on the area of
uncertainty returned. Your opinion below doesn't resonate well with the
opinion that there isn't "wrestling" going on. What's the rationale for
dispatching to the "point"?

For a real-world application of uncertainty, the routing problem should be
considered. If I have an area of uncertainty at 90% confidence overlaid on
three routing area borders, then I have a better chance of getting the
routing right if I pick the route that most of the area of uncertainty lies
within. This is particularly emphasised where the center of the uncertainty
may actually lie in the route that only has a tiny fraction of the area of
uncertainty overlaid on it. E.g. given the following area of uncertainty at
90% confidence, which is the best destination zone to route to?

Cheers,

Martin

---

From: "Dawson, Martin" <[email-masked]>
Date: Tue, 28 Aug 2007 18:05:31 -0500

Nope - but better than just using the point. Nice to agree on something.

Gee - I didn't realize I wasn't trying to understand. Maybe you're
saying that experience is relevant in making a decision? Hard to tell.

Anyhow, I still think that the use of geo-location will become more
sophisticated over time. You might not call it "wrestling" - gosh, it's
a metaphor, I didn't think it had a terribly specific interpretation. I
very much doubt that the procedures, understanding, and infrastructure
associated with reported location is now cast in stone.

Cheers,

Martin

From: Brian Rosen [mailto:[email-masked]] 
Sent: Wednesday, 29 August 2007 8:40 AM
To: Dawson, Martin; Stuard, Doug; 'Roger Marshall';
[email-masked]; Winterbottom, James
Cc: 'GEOPRIV'
Subject: RE: [Geopriv] ResponseTime

Martin

I've spent a bunch of time on this trying to understand what is going
on.  You might try doing the same.

There certainly are people out there in PSAP land who don't understand
what confidence and uncertainty mean: they tie them together in "error".
However, you will note that EVERYONE says the same thing: "within 100M
95% of the time" for example.  That is confidence and uncertainty.  They
really do get it.

They ignore confidence completely in the app.  They mostly ignore
uncertainty.  That's the truth.  For the folks who really understand
these things, it's not ignorance; they don't have anything useful they
can do with the information.

Every caller is questioned about location the same way; they don't
change their questions based on uncertainty.  Is probably is more due to
the fact that there is less variation in emergency calling because there
are government mandates, but the reality is they ignore it.  There isn't
any wrestling because they all do it the same way.  There isn't a
request for feature enhancements on their CPE or CAD system vendor's
list.  They have a single standard (well, it's two standards) and that's
the end of the story.  Again, they really truly understand what the
values mean.  They don't see any way to actually use them.

Worse, I talked to some commercial LBS app vendors and THEY IGNORE THE
VALUE TOO.  I have yet to find anyone that uses confidence.  The only
use I have seen for uncertainty is display, and as I said, most people
turn it off.

I actually agree with you on routing.  At the moment, we're in the
minority.  Given a choice, most KNOWLEDGEABLE people would still choose
the center point and route on that.  I have some hope we can use
uncertainty in routing.  I have no hope for any use for confidence.
Note that if I change confidence to a higher value, likely I will expand
the size of your circle.  That would change routing of course, but the
confidence VALUE is completely ignored; only the uncertainty is useful.
Of course, for routing, I do in fact want a high confidence, and the
consequent higher uncertainty.  If I choose a route based on a really
small uncertainty, but it's wrong half the time, I don't do very well,
do I?

Brian

To: Brian Rosen; Stuard, Doug; Roger Marshall;

Cheers,

Martin

---

From: "Stuard, Doug" <[email-masked]>
Date: Wed, 29 Aug 2007 09:57:06 -0400

In practice, "uncertainty" is usually taken to mean "accuracy",
although, as pointed out, accuracy is really a combination of
uncertainty and confidence.  Given that most folks (and I'm talking
about call takers, not system administrators) think "accuracy" and not
the uncertainty/confidence continuum, confidence is worse than of no
use, it is confusing,  so it is either not provided or is suppressed.
Nevertheless, the reported "accuracy" (uncertainty) should be based on
an underlying common confidence value (even if it is not displayed or
otherwise used).

While it may be true that accuracy/uncertainty is not used TODAY by
individual service providers, do we want to ensure that it can NEVER be
used???  As familiarity with geolocation concepts grows, and as more
automated systems are deployed (i.e., those that understand the
confidence/uncertainty tradeoff and plot big (or little) circles on
maps), greater use of the information can be expected.  

Or maybe not.

The point I'm trying to make (and to get back to the original subject)
is that by providing optional time and "accuracy" values (actually,
uncertainty at some a commonly agreed to confidence level), with defined
meanings similar to those I suggested earlier, the flexibility to adapt
to a wide range of applications (emergency and otherwise) and
technological advances can be accommodated going forward.

All we need is an agreement as to what the confidence level should be
(oh, and world peace, too).

Doug

.

Sent: Tuesday, August 28, 2007 6:40 PM

Martin

Brian

---

From: "Stuard, Doug" <[email-masked]>
Date: Wed, 29 Aug 2007 10:19:55 -0400

The point I'm trying to make (and to get back to the original subject)
is that by providing optional time and "accuracy" values (actually,
uncertainty at some a commonly agreed to confidence level

[Stuard, Doug] 

If it were deemed necessary to support different confidence values,
perhaps confidence could be third optional parameter.  If not included,
a default of 90% (just a wild stab) would be assumed.

(Ducks and covers)

Doug

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 30 Aug 2007 10:11:00 -0400

The point has been made before, but it probably bears repeating.  
There are at least two kinds of uncertainty/accuracy specifications,  
namely for a particular technology and for a particular point.

Take a technology that produces a 100 m accuracy with 90% confidence.  
Taken naively, this implies that every point is somewhere in a circle  
with diameter 100 m.

Unfortunately, this error is not the same everywhere. Some locations  
will presumably see a much larger error, possibly with non-zero mean  
error. For example, if a timing error is absolute (+/- 1 ns), it  
affects short distances much more than longer ones. Or multipath  
makes a particular location always seem further away than it really is.

Thus, you could easily get a situation where the location for a  
particular place is *always* outside that circle, even though the  
technology, on average, performs as advertised. I don't know if  
anybody has studied this problem in detail to see how much this  
matters in practice.

http://www.comsoc.org/pci/private/2000/oct/bulusu.html shows an  
example of this. ("The localization error is lowest at the position  
corresponding to the centroid of the region and increases toward the  
edges of the region.")

http://www.gmat.unsw.edu.au/snap/publications/lib_etal2005d.pdf
http://www.ieee-infocom.org/2004/Papers/55_5.PDF
also show behavior like that.

Btw, http://www.locatemodelcities.org/documents/ 
LOCATE_Final_Report.pdf is of some relevance here. In particular, it  
contains definitions for terms.

Henning

On Aug 29, 2007, at 9:57 AM, Stuard, Doug wrote:

> In practice, “uncertainty” is usually taken to mean “accuracy”,  
> uncertainty and confidence.  Given that most folks (and I’m talking  
> about call takers, not system administrators) think “accuracy” and  
> not the uncertainty/confidence continuum, confidence is worse than  
> of no use, it is confusing,  so it is either not provided or is  
> suppressed.  Nevertheless, the reported “accuracy” (uncertainty)  
> should be based on an underlying common confidence value (even if  
> it is not displayed or otherwise used).
>
>
>
> individual service providers, do we want to ensure that it can  
> NEVER be used???  As familiarity with geolocation concepts grows,  
> and as more automated systems are deployed (i.e., those that  
> understand the confidence/uncertainty tradeoff and plot big (or  
> little) circles on maps), greater use of the information can be  
> expected.
>
>
>
> Or maybe not.
>
>
>
> The point I’m trying to make (and to get back to the original  
> subject) is that by providing optional time and “accuracy” values  
> (actually, uncertainty at some a commonly agreed to confidence  
> level), with defined meanings similar to those I suggested earlier,  
> the flexibility to adapt to a wide range of applications (emergency  
> and otherwise) and technological advances can be accommodated going  
> forward.
>
>
>
> All we need is an agreement as to what the confidence level should  
> be (oh, and world peace, too).
>
>

---

From: "Dawson, Martin" <[email-masked]>
Date: Thu, 30 Aug 2007 09:59:45 -0500

Yes - accuracy for systems is generally a statistical metric. Most
obviously for wireless systems but even for wireline systems - there's
an error that results from bad data in things like wiremaps. There's no
established paradigm for communicating "accuracy" in the latter
environment however.

All applications, that are optimally implemented (I want to say "all
decent applications"), need to consider the possibility that the
determined location is not correct. What this involves depends on the
nature of the application. It might decide it's OK to completely ignore
this characteristic of the location service, it might use a GUI and
display a disclaimer/warning, or it might have a sophisticated dialog
for doing sanity checks and resolving ambiguities with the user... or it
might address the issue through completely manual procedures that are
part of the overall application space but not solved by the software.

Making a blind assumption about the accuracy or wilfully ignoring
additional information like uncertainty boundaries without considering
the implications is a sign of a "non-optimal" application.

Cheers,
Martin

-----Original Message-----
From: Henning Schulzrinne [mailto:[email-masked]] 
Sent: Friday, 31 August 2007 12:11 AM
To: Stuard, Doug
Cc: GEOPRIV WG
Subject: Re: [Geopriv] ResponseTime

Henning

On Aug 29, 2007, at 9:57 AM, Stuard, Doug wrote:

> about call takers, not system administrators) think "accuracy" and  
> suppressed.  Nevertheless, the reported "accuracy" (uncertainty)  
> The point I'm trying to make (and to get back to the original  
> subject) is that by providing optional time and "accuracy" values