Re: [Geopriv] Confused about draft-polk-geopriv-pidf-lo-4-agps-00.txt

["Winterbottom, James" <[e-mail]>]

Hi James,

I don't understand the point of your option 3.
In your lead up to the options you indicate that the end-point doesn't
do the location determination, it does the measurement processing. In
options 1 and 2 this is fine. 

In option 3 however you have the end-point knowing how far it has moved,
and hence can know where it is. Why in this case would it report
measurements?

The other things that bothers me a bit with this approach is that in
WiMAX you will, in quite a number of cases, requires quite a few
measurement sets from the Target in order to do the location
determination, and the Target won't know ahead of time how many to
provide. Doing this with a subscription is going to be hard unless you
plan on timestamping all measurements since the last time you reported
and sending the whole lot to the LIS for consumption. At this point the
LIS will need to work out which ones to throw away, and which ones to
keep. The problem with this is two fold, information overload to the
LIS, and excessive battery drain on the Target. The latter problem comes
into play because making mobile scanning reports is not even close to
free.

A far better approach, is to go with option 2. Let the server poll when
it requires location, so measurement collection occurs when needed. If
the server doesn't get enough measurements, then it polls again until
such time as it either gives up, or gets what it needs.

Even if you go with option 3, you will still need to support option 2 in
order to ensure that the LIS can obtain sufficient measurements to
determine the location of the Target.

Cheers
James
  

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On
Behalf
> Of James M. Polk
> Sent: Wednesday, 23 July 2008 4:56 AM
> To: Hannes Tschofenig
> Cc: [e-mail]; Tschofenig,Hannes (NSN - FI/Espoo)
> Subject: Re: [Geopriv] Confused about
draft-polk-geopriv-pidf-lo-4-agps-
> 00.txt
> 
> At 12:47 AM 7/18/2008, Hannes Tschofenig wrote:
> >You mentioned the presence event package vs. the location event
> >package: When trying to implement some of the features we couldn't
> >figure out how to accomplish the semantic with SIP presence. Maybe a
> >lack of misunderstanding on how SIP presence works or maybe a real
> >issue. Don't know yet.
> >
> >
> >I don't understand your persistent connection requirement.
> 
> take my triangulation draft for a second, because it is easier to
> explain this one;
> 
> imagine an endpoint that sees multiple radio signals over a
> navigational system, be this a set of GPS satellites, or cell towers,
> or WiMAX towers.
> 
> The endpoint has this positioning information of each of the sources
> it can see (direction, angle, time, source identifier, etc), but in
> some very real cases, the endpoint isn't the one that runs the
> location determination algorithm, a location server (of some form)
> does this calculation.
> 
> Option#1 - The endpoint could send the server this information every
> single instance it moves, taking the bandwidth necessary to send this
> information to this server
> 
> or
> 
> Option#2 - this server could ask for a poll from the endpoint,
> attempting to either guess when the endpoint moves or just requesting
> an update a some interval in time
> 
> or
> 
> Option#3 - the location server could subscribe to the endpoint, state
> in that subscription what constitutes movement (i.e., defines it),
> and asked that the endpoint give an initial location plus an update
> every time it moves at least as far as the server said to look
> for.  This could be the server clearly defining to the endpoint "I
> don't want an update unless either 3 minutes passes, or you've moved
> more than 50 feet since the last update to me".
> 
> To me, it's clear that Option#3 is the most efficient, and requires
> the least amount of state at the server (because it is passively
> waiting for an answer whenever it has told the endpoint to update, it
> is not actively running timers - other for how long the subscription
is
> for).
> 
> This is a persistent connection, as mentioned in both drafts, and in
> my messages on this list.
> 
> 
> >James M. Polk wrote:
> >>At 02:03 PM 7/17/2008, Tschofenig, Hannes (NSN - FI/Espoo) wrote:
> >>>have you been missing years of discussions around L7 LCPs? Henning
even
> >>>had a proposal to use SIP, see
> >>>http://tools.ietf.org/html/draft-schulzrinne-geopriv-locationref-00
> >>>
> >>>Based on the decisions in Prague the group decided to go for HELD
and
> >>>there was no need seen to create yet another LCP. Adding yet
another
> >>>protocol does not make deployment a lot simpler...
> >>
> >>hmmm, let's see...
> >>
> >>A decision in Prague means I should know better than to bring it up
> >>now.  That's interesting in a group that repeatedly DOESN'T follow
> >>it's own consensus (if it doesn't suit them or a particular author).
> >>
> >>Case in point (and just one example of this) is from IETF 69
> >>(that's less than 1 year ago), the WG decided "Presence" was the
> >>only event package to be used for location.
> >>
> >>That didn't James Winterbottom and Martin Thomson from writing a
> >>new SIP event package for THIS IETF proposing a new event package
> >>for location, nor did it stop the GEOPRV Secretary (Richard Barnes)
> >>from strongly suggesting and backing the idea of this new event
> >>package to another SDO last week.
> >>
> >>Seriously, if the Geopriv Secretary cannot follow his own WG's
> >>consensuses, how can we blame authors from following consensuses of
> >>the WG (i.e., James W and Martin).
> >>
> >>Or did everyone NOT pay attention to that consensus when it was
> >>taken but me (the author of the Conveyance document that is
> >>stipulating the event package to be used)?
> >>
> >>BTW -- regarding SIP and doing LCP-like things -- there is a new
> >>requirement from another SDO (which I mention by name in the agps
> >>and triangulation IDs) for persistent connections which look an
> >>awful lot like a subscription-based dialog -- something HTTP cannot
> >>do, nor can DHCP.  These IDs are suggesting we revisit the SIP as
> >>an LCP *because* of this new requirement, and that's the only
> >>reason these docs were written.
> >>
> >>I guess the INTRO needs to be clearer in both IDs as to this
> >>requirement. I'll fix that in the next rev of both.
> >>
> >>>Ciao
> >>>Hannes
> >>
> >>_______________________________________________
> >>Geopriv mailing list
> >>[e-mail]
> >>https://www.ietf.org/mailman/listinfo/geopriv
> 
> _______________________________________________
> Geopriv mailing list
> [e-mail]
> https://www.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
[e-mail]
https://www.ietf.org/mailman/listinfo/geopriv