RE: [Geopriv] Response time use cases (was: HELDcommentonresponseTime parameter)

Date: Sat Aug 11 2007 - 06:49:43 EDT

I have not been able to follow all the discussions on the mailing list
but am aware "use cases" for a ResponseTime parameter are being sought.
Here's my example for emergency call handling.

As many will know, for UK emergency call handling, 999/112 calls from
all over the UK are initially answered in a stage 1 PSAP, which then
routes the call using location information, while at the same time
asking caller which type of service they want (Fire, Police, Ambulance
or Coastguard - the stage 2 PSAPs). For this routing process we need
location as quickly as possible so as not to hold-up the call, but we
have about 5 seconds for "as quickly as possible" to work.

The call is then onward connected to stage 2 PSAPs who answer it
(hopefully within 10 seconds) and then start to question caller and
pinpoint the incident location.

At this point the stage 2 PSAP call-taker really wants the most accurate
location possible displayed on their screen, though as they continue to
speak with caller for some time (around 2 minutes would be typical) they
can usefully accept location information throughout this time, though
clearly best to have it at outset. Within next 8 - 20 minutes the
ambulance will be expected on site (UK targets). Call-takers obviously
cannot wait indefinitley for a location and will question caller to
establish it using whatever they have been provided with automatically.
[This timeline would be extended for a caller unable to speak, with
call-takers prepared to wait longer for a precise location (but not
indefinitely before trying other ways to find caller if there was major

What I'm trying to say is that a client making location requests from a
LIS (probably an "on behalf of" (OBO) enquiry for early implementations)
and using that location to (i) route and (ii) provide location to stage
2 PSAP does have at least a couple of time limits it works with. One
could set these as (i) within 0 - 5 seconds for routing ii) within 15 -
60 seconds for pinpointing, then send 2 simultaneous queries to LIS with
different time limits in case there are different mechanisms that allow
a more precise location to be derived if you wait longer. The OBO
client uses and forwards first location but would also forward second
location if one received of higher accuracy in a time within which it's
most useful. The obvious case is cell ID (+ timing advance) available
quickly and some form of assisted GPS available after around 20 seconds
or so (I believe). However I suspect that as access network location
techniques for different set-ups are established not all will be
instant, eg position within a campus (university LIS) useful to stage 2
PSAP, may take longer than knowing what town or county in which the
campus is situated (public network LIS)which is sufficient for Stage 1

I hesitate to write at this point (I'll have no email access now for 2
weeks holiday, when I'm not allowed to log-on!) as there may be
questions or comments. I'll apologise now for lack of response from me regards

-----Original Message-----
From: Henning Schulzrinne []
Sent: 10 August 2007 21:07
To: Stuard, Doug
Subject: Re: [Geopriv] Response time use cases (was:
HELDcommentonresponseTime parameter)

Currently, there is no way to specify the accuracy in the HELD document,
so I'm confused by your comment. As I've mentioned, I have no objection
to such an accuracy specification and have made an accuracy suggestion
earlier, although I agree with others that it has its own set of issues.

As I mentioned in that earlier post, only the accuracy requirement
matters. If I say "I need 100m accuracy for dispatch", I mean it - and
timing out earlier doesn't help me. (Subject to the 30s-style system
engineering restrictions that Brian has mentioned.)

In all emergency calling cases, after all, I want data as quickly as
possible. If all I need is county-level accuracy for routing, I'm not
interested in waiting some additional seconds, since these seconds just
delay the response. If I was happy with a lower accuracy, I would have
specified it - and probably issued two queries, one low- res to get the
ambulance rolling in the right direction and one "agap", to find the

If such a more elaborate accuracy specification turns out to be useful,
I think it should be pursued as a separate extension draft, rather than
having some half-baked solution that merely causes complexity and
interoperability problems. As an extension draft, it can be
appropriately scoped, labeled experimental as opposed to standards track
or whatever the working group considers most appropriate.

As Brian, Ted and I continue to point out, we cannot think of a useful
client time constraint that isn't completely arbitrary, beyond the
"asap" value. No real-life, verifiable example of an application that
has such time-only per-invocation constraints has been identified. (We
all agree that providers of location information will likely be subject
to upper-bound engineering constraints that they have to satisfy in
order not to get into trouble with regulators and first responders.)

Also, a remark on "average" patience: At least in phone services,
abandonment percentages tend to be exponentially distributed, i.e., some
people are very impatient, others wait forever. Thus, this tends to be
not terribly helpful even if it could be experimentally determined.


On Aug 8, 2007, at 5:19 PM, Stuard, Doug wrote:

> I think specifying some value of "when" is often more important than
> specifying some value of "good".
> Knowledge of the server's time-accuracy curve is IMHO irrelevant.
> It is
> what it is (or "are" where there are multiple location methods
> available). The client has his own time-accuracy tolerance curve
> based
> on his application, which should govern ("The customer is always
> right"). While accuracy is important, the key element is always time.
> The client request would, in effect say: "I would like 10 meter
> accuracy, and am prepared to wait up to a minute to get it. If not
> achieved by that time, give me the best you've got". (I haven't seen
> anyone say "I need x meters accuracy, and I am willing to wait however
> long it takes until that is achieved."...there's always a time limit,
> even if implicit).
> If the server can provide the requested 10 meter accuracy in 15
> seconds,
> it's done. If not, it keeps working up to the one minute limit, then
> provides its "best effort" response (possible including its accuracy
> estimate).
> For an emergency request for routing purposes (i.e., a "quick
> fix"), the
> initial request would be something like: "I would like 500 meter or
> better accuracy, and am prepared to wait no more than 3 seconds to get
> it. If not achieved by that time, give me an 'unable to locate' or a
> 'use default routing' message". (Alternately, it could be of the form:
> "I need a location and associated accuracy estimate within 3 seconds
> with whatever accuracy you can provide. If not achieved by that time,
> give me an 'unable to locate' or a 'use default routing' message").
> Doug
>> -----Original Message-----
>> From: Ted Hardie []
>> Sent: Wednesday, August 08, 2007 1:55 PM
>> To: Dawson, Martin; Brian Rosen; Lisa Dusseault; Mary Barnes
>> Cc:; Henning Schulzrinne
>> Subject: RE: [Geopriv] Response time use cases (was: HELD
>> commentonresponseTime parameter)
>> (snip)
>> At one side, we have a willingness for two times: now and "when you
>> have
>> a good answer" (for some value of good).
>> -----Original Message-----
>> From: Henning Schulzrinne []
>> Sent: Tuesday, August 07, 2007 9:59 AM
>> To: Dawson, Martin
>> Subject: Re: [Geopriv] HELD comment on responseTime parameter
>> As I believe Brian and I have explained, the client should be able to
>> request "asap" and "agap" ("as good as possible"). If I understood
>> Rohan correctly, he also alluded to a similar type of distinction in
>> the world of medical labs.
>> As Brian noted, no useful location determination system has arbitrary
>> time constraints, measured in hours. As I've tried to explain, since
>> the client has no idea what the server's time-accuracy curve is,
>> providing a time parameter is meaningless to the client.
> ----------------------------------------------------------------------

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

Geopriv mailing list

Geopriv mailing list
Received on Sat, 11 Aug 2007 11:49:43 +0100

This archive was generated by hypermail 2.1.8 : Sat Aug 11 2007 - 06:51:41 EDT