RE: [Geopriv] The "cold start" myth and the general solution

From: Dawson, Martin ^lt;Martin.Dawson@andrew.com>
Date: Mon Aug 13 2007 - 18:25:04 EDT

Well - thanks for pulling my pristine new thread back to the previous topic... :) I don't think cold-start GPS is applicable to the discussion, particularly if it's autonomous GPS. We're talking about network provided location in the context of HELD. Note - I'm not saying autonomous GPS isn't a valid location technology. <br> "Suppose you were writing code for a possibly mobile handset that Supported location based calling. What is the value you put in your field? * You don't know if you are mobile * You don't know if there is a cold start issue * You don't know what the purpose for the location based call is What is the value, in seconds, that you recommend? How did you come up with it?" There's two approaches to answering that question from an implementer's perspective. One is to ask how long are you really prepared to wait for a response before you go into exception handling. The user "dials" a specific destination and, by whatever means, the device decides it's a destination that requires location-based routing. You've included the constraint that the device doesn't know the appropriate time to delay the call setup for individual destinations. This means it has to apply a common timeout. The timeout that you apply is going to be driven by the boundary conditions you apply. Do you want the device to wait as long as is reasonable because you *really* don't know how accurate the location needs to be for any one of the possible destinations, or do you set a lower value based on how long you think the user is really going to wait? If you decide the former, then I would suggest that a minute is enough time to expect an ultimate-accuracy answer. If you decide the latter then I would suggest 10 seconds - though that will depend on what sort of feedback the user has with respect to whether the device is in an auto-locate procedure and that the call is pending. If there's feedback then the implementer may decide this can be longer. The other approach, as an implementer who goes to the trouble of understanding the market, is to add some contextual knowledge about how long networks typically do take to return location information and to what accuracies. In addition, there'd be some research that correlates this with the typical requirements of location-based call routing demands. If you did that, you'd potentially come to the conclusion that given that the technology deployed in public networks is driven by the need to support emergency service with a fast-fix suitable for routing available in under five seconds and, similarly, this is actually all that any known location-based commercial call routing service needs. In that case, I would expect the implementer to set the timeout to 6 seconds. Most calls, in practice, will get the location back in under a second. If you have a very specific need for highly accurate location in your application, then the implementer needs to recognize that this could take anything up to a minute - given the state of the art. I would recommend that the implementer make sure that the necessary human factors are included to provide the user with sufficient feedback as to what is going on while that request is being processed. I would not recommend that the implementer try to treat this application as if it were one that *expects* location to be returned in two seconds. At no time, as an implementer, would I consider it sensible to build my application such that it waits forever. If the interface includes a function for the user to intervene (cancel the location procedure) then I'd set the timeout to something very large. Even then, based on the state of the art for public networks, I'd probably set it to only five minutes. If I have a very specialist application in a completely proprietary private network with an arcane location determination technology - for example, my HELD client is a nano-bot measuring quantum fluctuations over many hours, then I'd expect to apply my own domain knowledge to the question of defining the timeout (maybe 365 days or until my research budget expires). Cheers, Martin -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net] Sent: Tuesday, 14 August 2007 3:17 AM To: Dawson, Martin; 'GEOPRIV WG' Subject: RE: [Geopriv] The "cold start" myth and the general solution Cold Start is a one time startup which is the result, typically of GSP satellite acquisition. After cold start, updates come fast. The PC has no idea how long to wait. It doesn't know when an app will actually need location. It may be shortly after startup, it may be minutes, hours or days later. It doesn't know (and doesn't care) if it's mobile or not. It might be. The PC client is a good example because it's power profile is a lot difference from a handset. If it had a GPS, it would typically leave it on, even if no apps were using it. The ONLY app that I know of that it sensitive to cold start is the emergency call case. Most other apps tolerate start up fine, because the app just waits for cold start to be over, and then runs. Typical examples would be a navigation app. One that is not yet common, but would have a cold start issue would be location based calling other than emergency calls. Let's look at that. Suppose you were writing code for a possibly mobile handset that supported location based calling. What is the value you put in your field? * You don't know if you are mobile * You don't know if there is a cold start issue * You don't know what the purpose for the location based call is What is the value, in seconds, that you recommend? How did you come up with it? Brian. ________________________________________ From: Dawson, Martin [mailto:Martin.Dawson@andrew.com] Sent: Saturday, August 11, 2007 9:38 PM To: GEOPRIV WG Subject: [Geopriv] The "cold start" myth and the general solution Hi all, I thought it best to break this discussion topic onto a separate thread. The "cold start" approach was cited as an exemplar scenario in a recent post. This is where a computing device acquires its location once and then uses that for every location application until reboot or the device changes its network attachment. It was Brian R who used the scenario - which is fine - but I'd also like to acknowledge that Brian is the source of the very good use case where the device is attached to a LAN which is itself mobile. Brian talks about an RV driving down the interstate which has a LAN and which uses a wide area wireless Internet access (e.g. 3G, WiMAX) from a public provider. The mobile WiFI access point that Avis now rents out is another example, and WiFi LANs are also available on train services in those places lucky enough to have such facilities (I'm confident it will become commonplace in the short term). A device using an Ethernet cable or WiFi network adaptor has no way of knowing what the actual nature of the Internet connection is. It is wrong for a device which booted up and found itself attached to one these layer two services to *assume* that cold start was a valid approach. Yes, a desktop PC with an appropriately knowledgeable user could be configured to correctly make this assumption. This relies on the device obtaining the knowledge from an outside source (a user) but it's not inherently readily discoverable from the network. User configuration implies a default configuration. What is the safest default configuration for a HELD client? It is to assume that the device *could* be mobile and that it is best to request location at the time that it is needed. As I'm sure everyone appreciates, it's common for computers to operate in perpetuity on the default settings and, even if they are changed, it is common for settings to not be adjusted when circumstances change. Obtaining a cold-start location (or even periodically requesting a refresh) is not harmful in itself. Indeed, it is good to obtain and cache a "last known" location so that a given application can decide for itself whether it is happy to use that if an immediately updated result isn't available. However, even if it might not cause a problem in the 90% of DSL/cable connected static devices, it is not a good general approach - and the general approach of requesting location when it is needed covers the static situation anyway. Cheers, Martin    Martin Dawson Andrew Network Solutions Asia-Pacific Email: martin.dawson@andrew.com Phone: +61 2 42212992 Fax: +61 2 42212901 Mobile: +61 412 120300 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. ---------------------------------------------------------------------------- -------------------- 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] ------------------------------------------------------------------------------------------------ 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 Mon, 13 Aug 2007 17:25:04 -0500

This archive was generated by hypermail 2.1.8 : Mon Aug 13 2007 - 18:27:11 EDT