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

From: Brian Rosen ^lt;br@brianrosen.net>
Date: Mon Aug 13 2007 - 13:17:00 EDT

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]

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www1.ietf.org/mailman/listinfo/geopriv
Received on Mon, 13 Aug 2007 13:17:00 -0400

This archive was generated by hypermail 2.1.8 : Mon Aug 13 2007 - 13:19:07 EDT