RE: [Geopriv] Resolving a design philosophy tension

From: Winterbottom, James ^lt;James.Winterbottom@andrew.com>
Date: Tue Aug 14 2007 - 19:28:36 EDT

Brian, How do arrive at proposal for number 4? This is more handwaving than I have seen in any proposal given thus far. I see a "where am I down town app" being very useful. It certainly needs better location than ASAP, and does not require AGAP in almost all cases. This application gets the location of the device in 2 to 5 second, then renders that location on to a city map for the user to look at. Alternatively, the user fires the provided location to a webapp, and gets back a map of the local services they are interested in. I would certainly wait 2-5 seconds for location in this situation also, and possibly the same time again to render it. Both of these services need better that a 10km radius of serving cell, but may work fine with a 50m to 500m location determination technique that is not AGAP. I can add to that that I would have paid for and used such a service in Prague, and probably would in other places too. We are talking about how to address these things in HELD, discussing continuous tracking applications and subscription services is unhelpful since I think we have all agreed, more than once, that there are more efficient ways to do subscription and tracking. That is not to say that these applications are not important, they are just not relevant to this discussion now. I would prefer not to include application service-type in the location request for several reasons. Firstly I don't believe that there is a finite set of service types, and when you do this you compartmentalize applications which may not fit well in any of the "pre-configured" services agreed to. Secondly, you need a service qualifier and some other qualifier, which simply adds more complexity that can be achieved with only one parameter, time. Before we arrived at this proposal in HELD we spent a lot of time looking at what current implementations did, and essentially what ended up being default behaviour. Servers don't know what applications are going to be deployed in their networks, and clients don't need to know what determination techniques are available, if the application can qualify its request no other negotiation is required. Since something is better than nothing, the lowest common denominator for negotiation is time. Regards James > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Wednesday, 15 August 2007 8:42 AM > To: Stuard, Doug; 'Ted Hardie'; geopriv@ietf.org > Subject: RE: [Geopriv] Resolving a design philosophy tension > > I started writing a direct reply to Ted's latest, but this came in first, > so > I'll take off from here. > > I think that in order to deal with this reasonably, we're going to have to > have a bunch of use cases. I think dealing with abstract applications are > getting us confused. It's not enough to use the "best fit"/"best basis", > we > need to figure out much more thoroughly what we need. If we agree on a > set > of use cases, we can compare mechanisms to the use cases. > > Here are the ones I think we ought to build the mechanisms around: > 1. Emergency call. This is pretty well known. The parameters are > actually > fixed, there is no client variability, but the client would need to tell > the > server it was an emergency call if we actually leave it fixed > > 2. Non emergency location based call. This is like an emergency call in > nearly every respect except that the timing isn't really fixed. It could > be > exactly the same if it made sense. Nearly all the cases have exactly the > same needs: a quick non-very-accurate location for call routing, and an > accurate location for dispatch. It's the same for Pizza Hut as it is for > a > PSAP. > > 3. Navigation/Tracking. This is a continuous update. It's not at all > clear > if this is a good HELD application. The cold start doesn't matter. > > 4. Some kind of one shot "I am here" thing, more or less what the geo-tag > in > HTML is aimed at. You might get some kind of personalized-to-location > content. This is a human reaction time thing, but pretty short trigger; > you > wouldn't, for example, wait 2 seconds for this. The accuracy requirement > is > hard to state, and may depend on exactly what is being personalized. > Interestingly, if you used HELD to get location, and something like the > geo-tag to give it to a web server, then the HELD client doesn't know what > it's being used for. In this case, the client is clueless. > > 5. A subscription mechanism. Think of a tornado alert, but for where your > daughter is instead of where you are. You want what LoST gives you: a URI > to subscribe to, and a polygon representing the boundary where the URI is > still good. This is tracking, but you have a start up. I suspect the > cold > start doesn't matter; wait a minute or 3 and the app still works. It's > not > the same as 4) above because the subscription, which is the initial > location > isn't tied to user reaction time. > > That's my initial list. Let's get some more before we analyze. Need apps > with different characteristics with respect to time/accuracy than these. > > Brian > > > > > -----Original Message----- > > From: Stuard, Doug [mailto:Doug.Stuard@andrew.com] > > Sent: Tuesday, August 14, 2007 5:36 PM > > To: Brian Rosen; Ted Hardie; geopriv@ietf.org > > Subject: RE: [Geopriv] Resolving a design philosophy tension > > > > As I read Ted's post concerning "best basis" and "best fit" I was > > thinking "but most cases are a blend of the two!" ... and then Ted said > > essentially the same thing. I disagree with Brian in that I think the > > client absolutely should define its requirements, while the server > > determines the appropriate response (rather than forcing the client > > choose from a laundry list). It is not necessary (nor desirable) for > > the client to understand the server's technology selection process > > (which indeed can be quite complex, often involving time and situation > > dependencies as well as initial coarse location). > > > > While my carefully crafted comments have perhaps been somewhat taken > > over by events, I'll offer them here for what they're worth... > > > > > > The client knows his application and hence the associated the time > > and/or accuracy constraints. The server knows what positioning > > technologies are available in at a given time in a given area and their > > associated accuracy/time characteristics, and is thus in the best > > position to make the decision as to which technology (or technologies) > > to invoke given the constraints imposed by the client. It is not up to > > the client to educate the server on the nuances of its application, > > likewise it is not up to the server to educate the client on the > > subtleties of time /accuracy tradeoffs and available location > > technologies. > > > > While there is at least tacit agreement that at least a two-tiered > > approach is called for, I think we need to be more flexible than that. > > What seems to be the issue is how what requirements are specified and by > > which entity. > > > > CALL ROUTING: This is the "give me the best you've got, but give it to > > me fast" scenario, and is driven primarily by the emergency use case, > > but, as Martin pointed out, is applicable to a number of commercial > > location-based routing applications as well. > > > > The decision as to how fast is required is up to the client, and it is > > the client that is best able to determine if the returned > > location/accuracy is sufficient for his needs. For its part, the server > > is obligated to return something within the specified time limit, even > > if at a gross level of accuracy (the estimate of which should be part of > > the response), and it is the server that is best able to make the > > decision as to what the best method to do that is. > > > > The key element in determining permissible wait time for call routing is > > allowable call setup time/post-dial delay (ultimately, human factors > > related). This is the driving force behind the "quick-fix" option > > available in some wireless location systems, where a window in the order > > of 3-5 seconds is typical (note that in practical implementations, a > > quick fix is only judged to be useful/valid if its associated > > uncertainty is less than would be expected for cell/sector or other > > default response). (BTW, I would hazard to guess that the quoted 30% > > misroute figure quoted is based on cell/sector based routing, where > > there is an inherent high degree of inaccuracy associated with sector > > coverage areas as they relate to PSAP boundaries. If Quick-Fix (with a > > max uncertainty limit) were in use, I would expect misroutes to be > > reduced significantly). > > > > ACCURACY: While some have argued that time is not a factor, practical > > implementations dictate that it is. Few applications would be willing > > to wait 30 minutes for the "best available" location estimate unless it > > first had a useable estimate prior to that. While this implies an > > accuracy target, an upper limit on time is still an element. > > > > Going back to the above example, if after receiving the response from > > the server, the client needs still better data, he can issue a follow-on > > request with a longer window (if it is still time-sensitive, given that > > he already has a preliminary estimate), or if absolute accuracy is > > required, he could specify an open-ended accuracy requirement and wait > > until the cows come home or he gives up. > > > > RECOMMENDATION: What this boils down to (and what I believe Ted was also > > saying) is to include both an (optional) time parameter specifying the > > maximum time permitted for a response, as well as an (also optional) > > desired accuracy parameter. In combination these provide the > > flexibility inherent in the "best basis" approach, while not burdening > > systems and applications with various "best fit" detritus for which > > these elements are not required. > > > > The inclusion of accuracy and/or time parameters in a client request > > would then result in the following response types: > > > > 1) No stated requirement - Best achievable accuracy, no time limit > > (Open ended - Response provided at convergence or on receipt of "that's > > enough!" command). > > 2) Time limit only - Best achievable accuracy within specified time > > limit. > > 3) Accuracy requirement only - Provide response when specified > > accuracy reached, no time limit. > > 4) Both time and accuracy - Provide response when specified > > accuracy is reached or time limit expires, whichever comes first. > > > > In all cases, an accuracy estimate should be included in the response. > > This will allow the client to decide if further requests are necessary > > based on the situation/application. > > > > In implementation, case 4 would be "first on wins". You either achieve > > your required accuracy within the time limit specified in the client > > request, or you take the best that the server can provide when the clock > > runs out. If you then need additional time, you can re-issue the > > request, either without the time parameter or with a longer time window. > > > > Case 1 (and perhaps 3) is the equivalent of the "Accuracy" case, while > > case 2 (with an arbitrarily short time value)is the "ASAP" case. In > > today's wireless E9-1-1 implementations, cases 2 and 4 are most > > prevalent. You need the ability to specify time and/or accuracy > > requirements. Trying to force all cases into either an "ASAP" or a > > "AGAP" model is IMHO a glass slipper that just won't fit. > > > > Doug > > > > > > _____________________________________________ > > > > > -----Original Message----- > > > From: Ted Hardie [mailto:hardie@qualcomm.com] > > > Sent: Tuesday, August 14, 2007 12:53 PM > > > To: geopriv@ietf.org > > > Subject: [Geopriv] Resolving a design philosophy tension > > > > > <<snip>> > > > > > > Many protocol efforts are a blend of these two approaches; > > > there are few that are really completely one or the other. > > > > <<snip>> > > > > > > > On this particular issue, I do see two primitives: desired accuracy > > > and > > > client wait time. Having one expressed without the other does imply a > > > default > > > (Give me the location ($DEFAULT="best available) within 20 seconds) > > and > > > (Give me 1m accuracy within ($DEFAULT="forever" ), and those defaults > > > may look silly in particular application contexts. But that does not > > > mean > > > they are not useful primitives in any context, and they clearly are > > > separable. > > > > > > > _____________________________________________ > > > > > > > -----Original Message----- > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > Sent: Tuesday, August 14, 2007 1:55 PM > > > To: 'Ted Hardie'; geopriv@ietf.org > > > Subject: RE: [Geopriv] Resolving a design philosophy tension > > > > > > > > > I think the problem we are having is that the Andrew folks think that > > > the > > > client has the model that drives the protocol and the server should > > > adapt to > > > the needs of the client. I think that the server is the one with the > > > real > > > constraints and the client should adapt to the capability of the > > > server. > > > I don't think clients have hard rules. I think they have a "it > > > depends" > > > view of the time/accuracy tradeoff. > > ------------------------------------------------------------------------ > -- > > ---------------------- > > 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@ietf.org > 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]

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www1.ietf.org/mailman/listinfo/geopriv
Received on Tue, 14 Aug 2007 18:28:36 -0500

This archive was generated by hypermail 2.1.8 : Tue Aug 14 2007 - 19:30:34 EDT