Re: [Geopriv] Confused about draft-polk-geopriv-pidf-lo-4-agps-00.txt
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Geopriv] Confused about draft-polk-geopriv-pidf-lo-4-agps-00.txt
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: geopriv-bounces at ietf.org [mailto:geopriv-bounces at ietf.org] On
Behalf
> Of James M. Polk
> Sent: Wednesday, 23 July 2008 4:56 AM
> To: Hannes Tschofenig
> Cc: geopriv at ietf.org; 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
> >>Geopriv at ietf.org
> >>https://www.ietf.org/mailman/listinfo/geopriv
>
> _______________________________________________
> Geopriv mailing list
> Geopriv at ietf.org
> 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
Geopriv at ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.
