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

["James M. Polk" <[e-mail]>]

James

At 07:02 PM 7/22/2008, Winterbottom, James wrote:
>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?

in option #3 I state that the endpoint understands that at least one 
of its measurements is different by at least a set amount it was told 
to in the subscription. This doesn't mean the endpoint does the 
calculation to determine where it is.


>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.

In the WiMAX example, it will more likely be the case that 
triangulation isn't used from the server, but A-GPS is used. In that 
case, the endpoint initiates the subscription, providing the A-GPS 
information to the server and asking that it provide back enough 
information that the endpoint can determine where it is (with the aid 
of knowing what the on-board) GPS knows.  Do you see this to be the 
more likely case in WiMAX?

>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.

If the LIS is only providing the get-over-the-hump information to the 
endpoint, the endpoint does its own calculation, in the A-GPS example, correct?


>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.

With A-GPS, this can occur because the endpoint is in charge of the 
subscription, it can update its subscription as it sees fit, in the 
process, getting updates from the LIS when it needs it.

With A-GPS, I see the SUBSCRIBE going from the endpoint to the LIS 
(that means the NOTIFYs go from the LIS to the endpoint, with the 
endpoint knowing it needs
more information, and sending a new SUBSCRIBE within the same dialog).

With triangulation, the reverse is clearly more advantageous - which 
has the LIS subscribing to the endpoint, wanting to understand (get a 
NOTIFY) every time the endpoint detects it has moved.  Now, this 
realistically can have 100 updates a second - because one or more 
measurements changed, so the LIS needs to clarify what constitues 
"movement", by defining how much 1 or any measurement changes since 
the last update before sending a new NOTIFY with "hey, I just crossed 
the magic number of fractions of a degree (or feet or meters), here's 
a new measurement of all the signals I can see".  This method has the 
LIS doing the location determination of the endpoint, which doesn't 
know its own location throughout this set of transactions.

If in another, separate transaction, perhaps an LCP, sent the 
endpoint its LbyR, then all the endpoint does is either dereference 
that locationURI or hand out the LbyR to inform another entity where it is.

The Rulemaker exchange between the endpoint and the LIS (or Location 
Service - meaning this could be only to a Presence server) occurs 
through another transaction, most likely, and this occurs once, or 
anytime the rules change.  In the case that ihis is to a Presence 
server, the rules and the locationURI (or PIDF-LO if there has been a 
dereference already) would be sent in a SIP PUBLISH 
transaction.  This PUBLISH could have the AAA token in it, allowing 
the Presence server to interact with the LIS to have authorization to 
dereference the locationURI, so it has this information when asked by 
a watcher (that is, if the wartcher is authorized to get this information).

These are all separate transactions because they are doing separate things.


>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.

I agree, but I believe strongly that these two options (2 and 3) are 
separate transactions, be that independent subscriptions, if these 
need to overlap in time.

James


>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