RE: [Geopriv] coming to terms on location by reference

Greetings,

I've been watching the discussion regarding LbyR and was curious if the
following has been discussed or might be covered in some way with LbyV:

It seems to me that there might well be situations involving mobile VoIP
handsets where location is determined by GPS, angle of arrival, time
difference of arrival, or some other kind of radio-location technique.
In today's network, some of this type of radio-location is done solely
in the handset (e.g.: GPS) and some depends upon some assistance from a
network element (e.g.: PDE in the wireless context.) The point is that
location in this context is often expensive both from a
"processing-cycle" perspective, a "battery life" perspective, and a
"time to locate" perspective. Our experience with cellular and phase 2
is that it is often the case that the handset does not know its location
at the time the 9-1-1 call is made. It seems likely that for some
fraction of highly mobile VoIP devices, location technology similar to
that used for wireless today might be employed and location might not be
available at the time the call is placed. Best-guess routing is used
with cellular to get the caller to the correct PSAP based on cell site,
but the caller's actual location might not be known until some time has
passed, thus making it of no use for routing purposes. There are also
rare cases where the caller might have terminated the call but the PSAP
still needs to locate the caller. Consider the case where the battery
is nearly done and the caller disconnects to conserve battery power.
So, it seems to me that location by reference supports the real-world
use case typically seen today in cellular where the phone is passive in
its location determination and, if involved at all, is "assisted" by a
network element (e.g.: assisted GPS.) For other location technologies
(e.g.: angle of arrival, time difference of arrival, etc.) the phone is
not involved in any way in the act of location.

Please excuse this intrusion if this matter has already been discussed,
but I would urge you to consider technical implementations where the
calling device is really just a cell phone that happens to be working
over a VoIP wireless network of one kind or another. It seems very
likely that cellular carriers will want to employ (if possible) whatever
location technology was chosen for locating the phone when it is
operating in the cellular network. Today, that cellular position
determination entity (PDE) is passed a reference to the device requiring
locating.

Regards,

Larry Ciesla

-----Original Message-----
From: Marc Linsner [mailto:mlinsner@cisco.com]
Sent: Friday, September 15, 2006 5:22 PM
To: 'Winterbottom, James'
Cc: 'GEOPRIV'
Subject: RE: [Geopriv] coming to terms on location by reference

Within NENA, LbyR was accepted due to the advertising, by a few, of what
it
will deliver. Such advertising is the true FUD. This community has
reviewed that advertising and categorized it properly. Sorry NENA, you
were
told something that is not possible to deliver.

-Marc-

> -----Original Message-----
> From: Winterbottom, James [mailto:James.Winterbottom@andrew.com]
> Sent: Friday, September 15, 2006 5:59 PM
> To: Marc Linsner; Dawson, Martin
> Cc: GEOPRIV
> Subject: RE: [Geopriv] coming to terms on location by reference
>
> Marc,
>
> You are a number of colleagues in this discussion were the
> ONLY opponents to LbR in NENA and you lost that argument
> handsomely. At that point it was made clear by the same
> league of individuals that they would not let LbR fly in the
> IETF. So far I have only seen the same misinformed FUD being
> thrown around, and the same people opposing it.
> Please come back with something that is constructive.
>
> Cheers
> James
>
>
>
> > -----Original Message-----
> > From: Marc Linsner [mailto:mlinsner@cisco.com]
> > Sent: Saturday, 16 September 2006 1:08 AM
> > To: Dawson, Martin
> > Cc: 'GEOPRIV'
> > Subject: RE: [Geopriv] coming to terms on location by reference
> >
> > Martin,
> >
> > Why did i2 promise LbyR functionality prior to IETF review,
> if in fact
> > NENA was dependent on IETF for such a mechanism?
> >
> > Promises YOU made in i2 does not force consensus in GeoPriv.
> >
> > Btw, I do believe there is middle ground on LbyR!
> >
> > -marc-
> >
> > > -----Original Message-----
> > > From: Dawson, Martin [mailto:Martin.Dawson@andrew.com]
> > > Sent: Friday, September 15, 2006 10:43 AM
> > > To: Brian Rosen; Hannes Tschofenig
> > > Cc: GEOPRIV; Thomson, Martin; Henning Schulzrinne
> > > Subject: RE: [Geopriv] coming to terms on location by reference
> > >
> > > Feel free to take the suggestion to i2.5; it's a noble
> cause and I'm
> > > sure the ensuing discussion will be interesting. I believe your
> > > proposal is eminently complex, fraught with implementation
> > > difficulties, and will meet with considerable resistance
> from both
> > > VSPs and the vendors of soft switch products. I think you'd be
> > > better off waiting for i3 where the peer signaling relationship
> > > between the PSAP and the terminal can be capitalized on.
> > >
> > > In the mean time, i2 is in the process of implementation
> so having
> > > the IETF not helping will only likely make the IETF not
> relevant to
> > > its development which will ultimately make the ability of
> the IETF
> > > to contribute to further evolution that much more
> difficult. A great
> > > pity.
> > > The location reference mechanism will need to be supported, by
> > > wireless LIS operators at least, one way or the other.
> > >
> > > Cheers,
> > > Martin
> > >
> > > > -----Original Message-----
> > > > From: Brian Rosen [mailto:br@brianrosen.net]
> > > > Sent: Friday, 15 September 2006 10:00 PM
> > > > To: Dawson, Martin; 'Hannes Tschofenig'
> > > > Cc: Thomson, Martin; 'Henning Schulzrinne'; 'GEOPRIV'
> > > > Subject: RE: [Geopriv] coming to terms on location by reference
> > > >
> > > > > Why is there any relevance to whether the PSAP request is
> > > initiated
> > > by
> > > > > the CPE automatically or by an operator clicking a button
> > > on a CPE
> > > > > screen. It seems about as relevant as the DHCP point.
> > > > At first blush, it seems that there is value in making a direct
> path
> > > from
> > > > the LIS to the VPC (where the VPC is the watcher), rather
> > > than looping
> > > > through the endpoint. However, when you look at the actual
> > > use case,
> > > I
> > > > think there is little value. The reason is that the
> frequency of
> > > update
> > > > is
> > > > very low, so low that any optimization seems pretty worthless.
> > > >
> > > > The FIRST location operation is MORE complex (the endpoint gets
> the
> > > > reference from the LCP, sends it to the VPC, the VPC
> > > exchanges it for
> > > > location with the LIS). The second operation would, if
> there was
> a
> > > direct
> > > > connection, be more efficient (VPC to LIS). Average them
> > > for two dips
> > > and
> > > > it's a wash. But 2 dips IS the usual case.
> > > >
> > > > They both work. There is no functionality difference
> except that
> in
> > > the
> > > > LbyR you need an extra interface and path.
> > > >
> > > > i2 is a lousy use case for LbyR
> > > >
> > > > >
> > > > > And a VPC does not have a call. If you're referring to a
> > > combo proxy
> > > and
> > > > > VPC, then you are relying on some proprietary functionality to
> get
> > > the
> > > > > request from the VPC component supporting the E2
> > > interface and back
> > > to
> > > > > the proxy component. You are throwing up your hands
> and saying -
> > > well do
> > > > > something proprietary then rather then use something eminently
> > > suitable
> > > > > like location by reference.
> > > > I'm saying that every VPC I know of has the proxy. If you like,
> > > suggest
> > > > an
> > > > update interface between the VPC and the proxy in the
> i2.5 effort,
> > > I'll
> > > > support that. All of the VPC interfaces are NENA developed.
> > > >
> > > > >
> > > > > Now, is the service bureau proxy that you're really
> referring to
> > > going
> > > > > to establish the subscribe directly to the device
> itself, or is
> it
> > > going
> > > > > to have to go back via the VoIP call server? If it does
> > > it directly
> > > to
> > > > > the device then you've just introduced all the concerns
> > > that you had
> > > > > over third parties being able to get location via a reference.
> How
> > > is
> > > > > the device supposed to know who this proxy is? If it goes back
> via
> > > the
> > > > > VSP call server, then you're now also asking the VSP
> to support
> > > some,
> > > > > currently unspecified, additional functionality for
> this update
> > > process.
> > > > > And what if the VSP is Skype? They also need to invent a
> location
> > > query
> > > > > protocol on top of everything else?
> > > > I'm asking that the VPC reInvite back towards the
> endpoint, which
> > > means it
> > > > goes through the VSP (this means the VPC proxy acts as a B2BUA,
> but
> > > most
> > > > of
> > > > them do this anyway for other reasons). The VSP does
> not need to
> > > support
> > > > anything but reInvite.
> > > >
> > > > >
> > > > > You were involved in the i2 WG Brian, you know we
> discussed all
> > > these
> > > > > sorts of options and dismissed them because we were
> > > looking for the
> > > > > minimal impact on the various participants in VoIP
> (in the real
> > > world).
> > > > > It seems somewhat disingenuous in another forum to be pushing
> > > > > impractical solutions now that i2 is published and in the
> > > process of
> > > > > implementation.
> > > > Mobility was not well thought out. ALL we did is to
> decline to do
> > > > anything that would preclude supporting mobility. The word
> > > "mobile"
> > > > as used in this context appears once in the i2 document,
> describing
> > > > one use of the V3 interface. My solution is eminently
> practical.
> > > >
> > > > >
> > > > > It's just occurred to me that the reference to DHCP may have
> been
> > > > > somewhat Freudian. Are all of these gymnastics driven by the
> > > prospect
> > > > > that DHCP doesn't support a location reference mechanism?
> > > > No, it's just that you would think using DHCP as an LCP for
> > > a mobile
> > > > device is ludicrous. In this use case, it is not. You
> might have
> > > > other use cases where it would be, but not this one.
> > > >
> > > > I'm happy to support a location reference mechanism for
> DHCP if we
> > > decide
> > > > that is a good thing.
> > > >
> > > > Brian
> > > >
> > >
> > > --------------------------------------------------------------
> > > ----------------------------------
> > > 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@ietf.org
> > > https://www1.ietf.org/mailman/listinfo/geopriv
> >
> > _______________________________________________
> > Geopriv mailing list
> > Geopriv@ietf.org
> > https://www1.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@ietf.org
> https://www1.ietf.org/mailman/listinfo/geopriv

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www1.ietf.org/mailman/listinfo/geopriv

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www1.ietf.org/mailman/listinfo/geopriv
Received on Tue, 19 Sep 2006 14:00:00 -0500