W3C home > Mailing lists > Public > public-geolocation@w3.org > July 2011

RE: Proximity alarm interface

From: Thomson, Martin <Martin.Thomson@commscope.com>
Date: Thu, 30 Jun 2011 07:11:56 +0800
To: Andrei Popescu <andreip@google.com>, Steve Block <steveblock@google.com>
CC: Doug Turner <doug.turner@gmail.com>, Anne van Kesteren <annevk@opera.com>, Lars Erik Bolstad <lbolstad@opera.com>, "public-geolocation@w3.org" <public-geolocation@w3.org>
Message-ID: <8B0A9FCBB9832F43971E38010638454F040B26CC47@SISPE7MB1.commscope.com>
On 2011-06-29 at 23:13:57, Andrei Popescu wrote:
> On Wed, Jun 29, 2011 at 12:03 PM, Steve Block <steveblock@google.com>
> wrote:
> >> Not sure I fully understand this: how would the UA know it got 
> >> close to the relevant location solely by looking at WiFi and CellIDs?
> > I guess an intial request to the server could return a set of 
> > interesting WiFi and Cell IDs. The device doesn't need to contact 
> > the server again until it sees one of these.
> >
> 
> Yep, that would work, assuming there is some service that provides the 
> reverse (lat, long, radius) -> (cellIDs, WiFi APs) mapping. And you'd 
> still have to be scanning for WiFi constantly, even if the device 
> would otherwise go to sleep.

That's not strictly true.  The device can sleep for longer without scanning if it discovers it is a long way from the area of interest. It can probably just hook into the normal cell handover mechanism for the most part and only start more intensive checking when it gets close.  Infrequent checking when it is further away, more frequent as it gets closer.

--Martin
Received on Friday, 1 July 2011 05:32:57 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:51:02 UTC