Subject: [Geopriv] draft-hdesinen-geopriv-pidflo-extn-00.txt

From: "Edge, Stephen" <[email-masked]>
Date: Wed, 19 Jul 2006 23:20:23 -0700

Hi All

Regarding the draft proposal for Location capabilities extension to
pidf-lo
(http://www.ietf.org/internet-drafts/draft-hdesinen-geopriv-pidflo-extn-
00.txt) which was discussed at the last Geopriv meeting, I understand
that there was some confusion concerning justification for the intended
applications. As a participant (though not main author) for this draft,
maybe I can add some enlightenment (or at least reduce the confusion).

The application that instigated this (as was probably already clear) is
the support of VoIP emergency calls in regions where precise routing to
a specific PSAP is needed and/or the ability to provide precise location
to the PSAP - requirements that both apply to circuit mode E911 calls in
the US and are expected to apply to VoIP.

In order to obtain the location of a wireless attached device (e.g.
using IEEE WLAN, 3GPP2 HRPD, 3GPP HSDPA) where bearer service is IP
based, various so called user plane solutions have been developed in OMA
(SUPL), 3GPP2 (X.S0024) and in a proprietary manner (e.g. Qualcomm V1/V2
solution). These operate using TCP/IP signaling between the device and a
location server in the home network (e.g. 3GPP or 3GPP2 home network).
Normally there would be no problem in knowing that the device supports
say SUPL or X.S0024 or V1/V2 because this could be configured in the
server. But in an emergency call situation, the call needs to be
supported in the serving/visited network (at least this is what 3GPP has
decided) which has no knowledge of the device capabilities. Of course,
the visited network server could send a location request to the home
network but this would incur potential penalties of delay, cost (for
inter-operator billing) and a higher risk of failure due to inclusion of
extra network elements and signaling. Even worse, it does not solve the
problem, because the visited network has no idea whether the home
network will be able to locate the device using a user plane solution.
In certain cases - e.g. 3GPP HSDPA access - it may also be possible to
employ a so called control plane solution in which all signaling
interaction is supported by entities within the wireless network using
network signaling interfaces. In that case, any request to the home
network would be sent back again to visited network which then has to
manage the actual positioning procedure (using a control plane solution)
- i.e. a hairpin.

The result of all this is that location should be performed by the
visited network without assistance or participation from the home
network. This solution type has now been agreed by OMA LOC and 3GPP,
which brings back the problem of knowing the device capabilities - i.e.
which location solution to try (with time being a significant or
critical factor).

Our draft proposal provides one apparently simple and straightforward
solution - include the device location capabilities (supported position
solutions and position methods) as an optional extension to the pidf-lo.
The device will typically send a pidf-lo anyway when it has some
location information available at the time an emergency call is
originated and it can send a pidf-lo without location information but
with its capabilities in other cases. A major benefit of this proposal
is that it can be technology independent since it is valid for any type
of access (including wireline as well as wireless). Another benefit is
that it may be relatively easy to implement - due to extending an
existing object rather than requiring a new one.

Concerning the issue of mixing location information (e.g. geographic
coordinates) with location capability information in the same object,
justification would be that (for emergency calls at least) both sets of
information are intended for the same entity - namely the location
server in the visited network that will route the call and interact
later with the PSAP (directly or indirectly) to provide subsequent
location updates. In cases other than emergency calls where location
information needs to be sent to some client entity and location
capabilities to a different server entity, either the server could
remove the location capabilities or perhaps 2 distinct pidf-lo objects
could be sent.

It would be useful to know whether our current proposal is now seen to
have any possible merit or whether we need to consider some other
alternative. In the latter case, we would need something that will work
for emergency calls and ideally will be as simple (or not much more
complex) than our current proposal.

Thanks in advance for any replies.

Kind Regards

Stephen

_______________________________________________
Geopriv mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/geopriv

---

From: Andrew Newton <[email-masked]>
Date: Thu, 20 Jul 2006 10:20:50 -0400

> existing object rather than requiring a new one.

Stephen, thanks for the clarification.  To summarize, this is really 
about assistance for location acquisition via the network, right?  If 
true, I think the issue brought up at the meeting is that this is not 
location information but information intended to help acquire location 
information.  While it could be argued that this should be put into the 
location acquisition protocol, I personally think this working group 
crossed the fine line on this when it allowed <method> into PIDF-LO, 
which is also not location information but information about how the 
location was acquired.

BTW: the example in your draft contains both location information and 
the lc: elements.

-andy

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 20 Jul 2006 18:11:19 -0400

I have read this draft and don't understand its value, especially in the
emergency call case.

The IETF big picture for emergency call is:
1. Access network gives location to endpoint (by value or by reference) via
an acquisition protocol
2. Initial Location (used for routing) is carried from endpoint to routing
proxy to PSAP via SIP Location
3. Endpoint either determines route by itself via LoST, or first hop proxy
does it using SIP Location
4. PSAP, if needed, subscribes to presence of caller for location updates

If there is some disagreement with this, I direct you to ecrit where you can
raise issues with this approach, which is documented in
draft-rosen-ecrit-emergency-framework-00.

So, this draft proposes two kinds of info:
* What location determination mechanisms might exist (as opposed to what a
PIDF-LO was created from, which does exist)
* What location protocols not used either for what we would call location
acquisition (access network to endpoint), conveyance (endpoint to proxy or
endpoint to PSAP) or location update (PSAP to presence server) might be
available

The first is not of interest to routing entities or PSAPs.  Routing entities
don't know squat about how you got location, and don't care.  You give them
what you got, and they route based on that.  We've been around this a lot,
and it comes down to the endpoint gets ONE location, and that's what you use
to route.  The farther you get from the source of the location info, the
less you know, or care about how it's done.  PSAPs are like that too.  They
would like the most accurate location they can get, but generally, they
don't have time, or expertise, to be choosing between A-GPS and A-FLT, if
there actually was a network that offered a choice.

The second is outside the whole architecture.  All of the listed protocols
aren't used between the entities we deal with.  The LIS might use them to
get the location it passes to the endpoint via an acquisition protocol, or
it might use them when an update request is made, but no one receiving a
PIDF-LO knows or cares about that.  So, no recipient of a PIDF-LO needs to
know what the access network implements internally (we all agree, it’s the
access network, which would be the "visited" network for a mobile phone
network).

Brian

________________________________________
From: Edge, Stephen [mailto:[email-masked]] 
Sent: Thursday, July 20, 2006 2:20 AM
To: [email-masked]
Subject: [Geopriv] draft-hdesinen-geopriv-pidflo-extn-00.txt

Hi All
 
Regarding the draft proposal for Location capabilities extension to pidf-lo
(http://www.ietf.org/internet-drafts/draft-hdesinen-geopriv-pidflo-extn-00.t
xt) which was discussed at the last Geopriv meeting, I understand that there
was some confusion concerning justification for the intended applications.
As a participant (though not main author) for this draft, maybe I can add
some enlightenment (or at least reduce the confusion).
 
The application that instigated this (as was probably already clear) is the
support of VoIP emergency calls in regions where precise routing to a
specific PSAP is needed and/or the ability to provide precise location to
the PSAP – requirements that both apply to circuit mode E911 calls in the US
and are expected to apply to VoIP.
 
In order to obtain the location of a wireless attached device (e.g. using
IEEE WLAN, 3GPP2 HRPD, 3GPP HSDPA) where bearer service is IP based, various
so called user plane solutions have been developed in OMA (SUPL), 3GPP2
(X.S0024) and in a proprietary manner (e.g. Qualcomm V1/V2 solution). These
operate using TCP/IP signaling between the device and a location server in
the home network (e.g. 3GPP or 3GPP2 home network). Normally there would be
no problem in knowing that the device supports say SUPL or X.S0024 or V1/V2
because this could be configured in the server. But in an emergency call
situation, the call needs to be supported in the serving/visited network (at
least this is what 3GPP has decided) which has no knowledge of the device
capabilities. Of course, the visited network server could send a location
request to the home network but this would incur potential penalties of
delay, cost (for inter-operator billing) and a higher risk of failure due to
inclusion of extra network elements and signaling. Even worse, it does not
solve the problem, because the visited network has no idea whether the home
network will be able to locate the device using a user plane solution. In
certain cases – e.g. 3GPP HSDPA access – it may also be possible to employ a
so called control plane solution in which all signaling interaction is
supported by entities within the wireless network using network signaling
interfaces. In that case, any request to the home network would be sent back
again to visited network which then has to manage the actual positioning
procedure (using a control plane solution) – i.e. a hairpin.
 
The result of all this is that location should be performed by the visited
network without assistance or participation from the home network. This
solution type has now been agreed by OMA LOC and 3GPP, which brings back the
problem of knowing the device capabilities – i.e. which location solution to
try (with time being a significant or critical factor).
 
Our draft proposal provides one apparently simple and straightforward
solution – include the device location capabilities (supported position
solutions and position methods) as an optional extension to the pidf-lo. The
device will typically send a pidf-lo anyway when it has some location
information available at the time an emergency call is originated and it can
send a pidf-lo without location information but with its capabilities in
other cases. A major benefit of this proposal is that it can be technology
independent since it is valid for any type of access (including wireline as
well as wireless). Another benefit is that it may be relatively easy to
implement – due to extending an existing object rather than requiring a new
one.
 
Concerning the issue of mixing location information (e.g. geographic
coordinates) with location capability information in the same object,
justification would be that (for emergency calls at least) both sets of
information are intended for the same entity – namely the location server in
the visited network that will route the call and interact later with the
PSAP (directly or indirectly) to provide subsequent location updates. In
cases other than emergency calls where location information needs to be sent
to some client entity and location capabilities to a different server
entity, either the server could remove the location capabilities or perhaps
2 distinct pidf-lo objects could be sent.
 
It would be useful to know whether our current proposal is now seen to have
any possible merit or whether we need to consider some other alternative. In
the latter case, we would need something that will work for emergency calls
and ideally will be as simple (or not much more complex) than our current
proposal.

Kind Regards
 
Stephen

---

From: Andrew Newton <[email-masked]>
Date: Thu, 20 Jul 2006 20:41:01 -0400

On Jul 20, 2006, at 6:11 PM, Brian Rosen wrote:

> don't know squat about how you got location, and don't care.

Don't care?  I would think they care very much.

Perhaps location acquisition protocol in the sense we've been  
thinking of it with DHCP and L7 is not what this is about.  Imagine  
the following scenario:

1) UAC sends PIDF-LO w/ A-GPS position solution to visited-network  
proxy (VNP).
2) VNP asks visited-network radio (VNR) tower to assist (because A- 
GPS is specified).
3) VNR responds with x,y,z geo.
4) VNP conducts LoST query with geo from VNR
5) VNP routes call based on LoST results.

-andy

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 20 Jul 2006 21:08:14 -0400

No they don't care HOW you got location, they just want you to tell them
where you are so they can route it.  They won't have any different behavior
if the location you sent was determined by A-GPS or by TDOA.  PSAPs care
about things like confidence, but not about mechanism.

Then, why is it interesting that the PIDF-LO has A-GPS in it?  The visited
network knows that already.  It also knows what protocols are supported.
The scenario you present is entirely within the visited network, and the
protocol is between the VNR and the VNP, which is within one domain, and can
use any protocol it likes.  Conveying choices via the PIDF isn't helping
anyone.  There has to be a use case where the VNP doesn't know what protocol
it needs to use to contact the VNR.  I don't think such a case exists.

Brian

> -----Original Message-----
> From: Andrew Newton [mailto:[email-masked]]
> Sent: Thursday, July 20, 2006 8:41 PM
> To: Brian Rosen
> Cc: 'Edge, Stephen'; [email-masked]
> Subject: Re: [Geopriv] draft-hdesinen-geopriv-pidflo-extn-00.txt
> 
>