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

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

Hi James,

My responses are inline, and I have nipped bits not of interest.

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

[AJW] The problem is that almost all end-points don't work like this.
They know the distance they have moved because they have the start and
end-locations.

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

[AJW] Not necessarily no, and if we are talking about inside then
certainly not. I think it very likely that I will have a NIC card in my
laptop that supports 802.16, much as I do for 802.11 today. I therefore
expect that card to be capable of measuring and reporting 802.16
scanning reports, I don't necessarily also expect it to have an A-GPS
chip in it, though it may. Since I must implement a pull for the
measurements (we agree to this below), why not simply always do this? 

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

[AJW] MSRs can only be combined with A-GPS measurements to arrive at
location in the LIS. You seem to be muddling what MSRs give you, and
where they can be used, and how they can be combined with other
measurements. 

A-GPS is one technology and it is totally independent of MSRs. Depending
on the information requested, A-GPS data can remain good for hours, or
using some extensions, even days. Subscribing to data that is good for
that long, over simply requesting it when needed seems a totally
unnecessary overhead and I remain totally unconvinced that you obtain
any economies of scale by subscribing for this information, in fact I
would argue you waste resources on the LIS with this approach. 
 
> 
> >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.

[AJW] But we are back to the old request response paradigm that we have
already had in the forum at least 3 times.

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

[AJW] Okay let me try again. The types of measurements you are talking
about are not free, they require the SS to specifically turn on and
engage with additional base stations. They don't do this all the time,
they do it as required because it is a significant drain on the battery
of the device. So there is a fundamental flaw in your logic here. The
device should only do this when the server asks it to do it, and that
should only be when an application requires that update. Subscription is
one way to do the timing, but it can equally well be done on an as needs
basis by the application polling for it, and this latter solution works
in all cases.

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

[AJW] I am suffering from Mondayitis, I am not sure what you are getting
at here.
 
> 
> >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.

[AJW] I guess I see the overhead of a subscription and associated
session as unwarranted when a poll will do everything you want.

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

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