RE: [Geopriv] HELD comment on responseTime parameter

From: Dawson, Martin ^lt;>
Date: Mon Jul 30 2007 - 18:44:39 EDT

The typical call flow for cellular has the MSC asking the location server for a low-delay response. It wants the result quickly, first and foremost, because it has to get on with routing the call (or if it does cell-based routing, so that a location is available to the ALI as soon as possible after the call is set up). Based on this low-delay requirement, the location server has to invoke an appropriate technology. When a PSAP bids for an updated location, the request makes its way through the network to the location server with a delay-tolerant QoS. This tells the location server that it can spend more time getting a more accurate location. In both cases, it is the client (the MSC or the PSAP) which informs the location server how long it is prepared to wait and, therefore, how long the location server can dedicate to the location determination process. None of this places an undue, or even surprising, demand on the client. The problem, in 3GPP, has been that the simple low-delay and delay-tolerant guidance do not allow the location server to be very sophisticated in its choice of technologies. Different PSAPs can have different policies with respect to how long they are prepared to wait. Cellular carriers currently are forced into a "one size fits all" when it comes to applying positioning methods to these PSAPs. A scalar response parameter would actually allow PSAPs to make their own judgements about performance trade-offs. Just using low-delay and delay-tolerant don't actually make things simpler - the location server has to be configured so that these correspond to some hard time-limit. The nice fuzziness has to be thrown out the window when it gets down to the hard facts of implementation. You may regard the voice of experience as a mere rhetorical appeal to authority but I'd also like to think that we are capable of learning from the experience gained in other domains to make sure our specifications are the best they can be. Cheers, Martin -----Original Message----- From: Henning Schulzrinne [] Sent: Tuesday, 31 July 2007 5:31 AM To: Stuard, Doug Cc: Subject: Re: [Geopriv] HELD comment on responseTime parameter As far as I understand our discussions here, HELD is used by the end system ("phone") or possibly a local (ISP-run) SIP proxy, not, in general, the PSAP. (We've had long discussions about authentication and privacy related to that, which I'd rather not repeat.) We seem to at least agree that it is useless for that end system client. It is also not clear how the timing and rebid are related. This is another problem with the timing model, as it seems to imply some kind of back-end state maintenance as well as an implicit method selection. If this is to be used by experts in the PSAP, shouldn't they just ask for the location determination method directly and avoid the rather indirect method of getting a specific location determination method by specifying the "right" time-out? If I ask at time 0 for location for terminal X, does this start some kind of background measurement process that I can sample later? (This is the re-bid model, in essence.) In other words, to take the GPS example, the short timeout request gives the initial, rough 2-satellite GPS fix, but it continues to run the GPS receiver, so that a later request provides the full N-satellite fix? If so, a "re-bid" is really a new request for the current location, i.e., another HELD request. It is not a "wait longer for answer" request. Thus, I fail to see how the "re-bid" in a PSAP has anything to do with timers. Henning Stuard, Doug wrote: > For commercial applications, I don't disagree, as the client (user) > generally has little idea about what a reasonable cut off (i.e., the "I > give up") time is for a given request, or what the trade-offs are. > That's like trying to decide if you should take one more pull on the > slots in Vegas. > > For emergency service applications however, the client ultimately is the > PSAP which IS knowledgeable about what a reasonable threshold is (the > famous 30 second window) and the accuracy that can be expected within > that threshold (This is where the "experience has shown" factor comes > in). In addition, if the threshold time is exceeded, a re-bid can > effectively extend it if needed (and need is frequently situational and > not automatic). (Well, maybe - currently a re-bid re-starts the location > process rather than extending it. Probably reasonable for tracking > moving targets - see below). > > "As soon as possible" thus translates to "quick and accurate enough for > proper call routing", while "As accurate as possible" translates to > "accurate enough for dispatch purposes - up to a point". Waiting > another 2 minutes to decrease uncertainty from 150 meters to 10 meters > is past the point of diminishing returns, in my view. > > While a client may specify "zero" at one end of the spectrum (and > actually get something in the order of seconds - certainly "pretty > quick" in human terms), I disagree that from a practical standpoint > "infinity" is the other end (whether in geological or human terms). > That would be the equivalent of "I'll call you back sometime". The > outside limit is of course situational, ranging from 30 seconds for > emergency services to perhaps 2 or 3 minutes (and certainly within the > length of the typical telephone call) for commercial applications ("All > agents are busy helping other customers. Your expected wait time > is..."). > > None of this applies to determining civic location, of course (it is > what it is), provided that validation, routing and display can be > provided for timely emergency dispatch. > > Doug > > >> -----Original Message----- >> From: Henning Schulzrinne [] >> Sent: Monday, July 30, 2007 1:14 PM >> To: Dawson, Martin >> Cc: >> Subject: Re: [Geopriv] HELD comment on responseTime parameter >> >> I think the basic disconnect is that I'm assuming that we should > design >> the protocol to be most useful to the client and that I cannot imagine >> how a client can usefully pick a time value beyond "immediately" >> (meaning within the 1-2 second post-dial delay margin available during >> a >> call setup) or "whenever" (within a reasonable time of, say, a minute >> or >> two). I know no client application that somehow can wait 10 seconds, >> but >> not 11 seconds, particularly if the answer it can get in 10 seconds is >> useless for its application. In that case, it has just "wasted" 10 >> seconds and has to guess whether trying again with 11 or 15 or 20 >> seconds will yield any improvement or whether this is pointless. >> >> Post-dial applications need answers immediately, and dispatch >> applications probably want updates, so that they can provide better >> estimates after they have started the dispatch process. (However, for >> dispatch, I'm having a hard time envisioning that this really matters. >> The realistic time frame to determine the nature of the emergency is >> probably on the same order, a few minutes, as the maximum probable >> location determination time, unless we're talking about asking the >> caller to get out their chronometer and sextant.) >> >> The pre-call case also has no natural time limit, beyond "as > accurately >> as possible". >> >> Since a client has no clue what the time-resolution function is, it >> essentially has to pick an arbitrary time value. It has no idea > whether >> there are steps in that time-resolution function, so that waiting a >> second longer gets much better accuracy. It has no idea whether asking >> again with a slightly longer interval will improve the result. >> >> I generally find "experience has shown" arguments of the >> argument-by-authority kind and thus not particularly helpful. We know >> that there are several discrete location resolutions that are useful, >> namely the "sufficient to do LoST routing" and "sufficient to do >> dispatch". A client doesn't need exactly N meters of accuracy. >> >> The likely outcome will be that clients will specify 0 and some >> approximation of infinity as values, with the danger that requests > will >> fail if 0 is taken as something other than "whatever you can do >> immediately". Or client implementors will "learn" that specifying 5 >> seconds will get reasonable results most of the time in the network >> they >> tested with. None of this is useful. >> >> I don't know of any incremental-resolution technique for civic >> locations, so I suspect it's more productive to focus on geo to keep >> the >> problem manageable. >> >> The basic model for protocol design is not to have to prove why >> something is NOT useful, but that a particular mechanism is the least >> complicated and most appropriate solution for a clearly stated >> requirement. I know of no requirement that says that a client has a >> specific time limit beyond the "immediate" value; we do know that >> clients have different rough accuracy requirements. >> >> Henning >> >> Dawson, Martin wrote: >>> I think the point is still being missed - and the assumption seems > to >> be >>> that this is a client-focussed parameter. It is not the client that >>> makes use of this information; it is the server. Particularly in >>> wireless access networks where a location server may have multiple >>> technologies available to it, there is a general need to trade off >>> response time and accuracy. Accept that there are "n" techniques and >>> that "n" can be more than two. The parameter allows the server to >>> provide an optimal accuracy in response to a location request by >> giving >>> it an understanding of how long the client is prepared to wait. >>> >>> It's no good assuming that a response now with some (asynchronous?) >>> update later is adequate. In scenarios where a device wants a >> location >>> value so it can send it to an application for immediate processing > by >>> that application, there is no use for "subsequent" values. That's > why >>> I'm puzzled by the request for "use cases" for this parameter - it's >>> applicable to every use case for location requests. The location >> server >>> can't assume anything about what is going to be useful to the client >>> "later". >>> >>> Not having a scalar response time criterion means that the server > can >>> never optimize the accuracy using the most suitable available >>> technologies. How does anyone propose that a HELD server select the >>> optimal positioning technology for a one-off request without some >>> understanding of how long the client is prepared to wait? >>> >>> Experience has shown that an accuracy requirement parameter is not > so >>> useful. Applications generally want the most accurate location they >> can >>> get within the timeframe that they are prepared to wait. The > accuracy >> is >>> actually part of the result - embodied in the provided uncertainty >>> information. There's no guarantee about how accurately an arbitrary >>> server can locate a target. Also, when it comes to civic location, >>> there's a semantic mismatch with respect to scalar accuracy. >>> >>> Cheers, >>> Martin >>> >> >> _______________________________________________ >> Geopriv mailing list >> >> > > ------------------------------------------------------------------------ ------------------------ > 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 ------------------------------------------------------------------------------------------------ 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
Received on Mon, 30 Jul 2007 17:44:39 -0500

This archive was generated by hypermail 2.1.8 : Mon Jul 30 2007 - 18:44:51 EDT